Modellierung meiner Datenbank

[Sophus]

Bedenke, dass später die Serie hinzukommt. Für die Daten, die vom Film zu trennen sind, werden auch Tabellen angelegt.

 

[Distrilec]

Ist das gut oder schlecht? Ich meine, die PKs und FKs sind ja nun mal Bestandteil einer jeden gut strukturierten Datenbank?

Das ist nicht schlecht... Aber wer als Hobby hier ein paar technische Fragen beantwortet hat wohl nicht immer Lust mehrere Stunden ein geeignetes Datenmodell zu erstellen ^^
Sollte wohl verstädnlich sein

Du würdest den FK von der Tabelle FilmAllgemein in die Tabellen Person_Rolle und Person_Funktion hinterlegen? Ich wär beinahe dazu übergegangen und hätte noch zwei weitere Zwischentabellen zwischen den Zwischentabellen Person_Rolle und Person_Funktion erstellt. So das es am Ende eine Zwischen-Zwischentabelle wär. Aber das wäre zu viel des Guten und würde den Sinn der Datenbank gänzlich verfehlen oder?

Richtig wäre eine zusätzliche Tabelle... Aber man kann es mMn auch übertreiben mit der Normalisierung. Ist aber nur meine Meinung und das könnte theoretisch später auch zu einem Problem werden, wenn dein Modell noch mehr Daten beinhaltet. Mir fällt derzeit nur kein konkretes Beispiel ein ^^

 

[Sophus]

Worum geht es? Ich möchte eine Beziehung zwischen dem Film und der Person herstellen. So, was ist im Schaubild passiert? Ich habe womöglich einige Regeln radikal gebrochen und ihr wünscht euch, mich von der Teppichkante schubsen zu können, damit ich für diesen Regelbruch sterben muss :-P Kleiner Scherz am Rande.

Schauen wir uns zunächst einmal die beiden uns mittlerweile bekannten Zwischentabellen an: Person_Funktion und Person_Rolle. Hier sehen wir, dass ich diese eben genannten Zwischentabellen modifiziert habe, und zwar wurden hier »künstliche« IDs hinzugefügt - Person_Funktion_ID und Person_Rolle_ID. Warum? Ich wusste mir sonst nicht anders zu helfen. Mein Anliegen war ja, eine sogenannte Zwischen-Zwischentabelle anzulegen - Person_Funktion_FilmAllgemein und Person_Rolle_FilmAllgemein. Auf diesem Wege möchte ich eine Beziehung zwischen der Tabelle FilmAllgemein und Person_Funktion sowieso Person_Rolle aufbauen. Und damit solch eine Beziehung zustande kommen kann, wurden eben »künstliche« IDs in den beiden Zwischentabellen Person_Funktion und Person_Rolle als Notlösung eingeschoben. Mit diesen »künstliche« IDs kann ich dann eine Beziehung über den Zwischen-Zwischentabellen (Person_Funktion_FilmAllgemein und Person_Rolle_FilmAllgemein) zu der Tabelle FilmAllgemein herstellen.

Jetzt bin ich auf eure Kritik und Vorschläge gespannt.

Euer Sophus

 

[Sophus]

Ist mein Fehler im oben genannten Beispiel so gravierend, dass ihr euch zurückgezogen habt? :-P

 

[Distrilec]

Was spricht denn dagegen ?


(Bitte schenkt meinen Paint-Künsten keine Beachtung )

 

[Sophus]

Zunächst einmal finde ich deine »Paint-Kunst« ziemlich gut. Du hast dadurch wesentlich schnell was ausgesagt und wesentlich mehr Zeilen gespart. Ich liebe visuelle Darstellungen.

Aber nun eine Frage. Ist es unwichtig in welcher Reihenfolge die Schlüssel in einer Zwischentabelle abgelegt werden? Zum Beispiel bei der Tabelle Person_Rolle ist der Schlüssel FilmAllgemein_ID an letzter Stelle. Ich nach meiner Überlegung würde ihn an erster Stelle setzten, denn ich denke mir so, ich will vom Film XYZ (FilmAllgemein_ID) die Person XYZ (Person_ID) und die dazugehörige Rolle XYZ (Rolle_ID). Und dann fiel mir noch was auf: Wenn wir es auf deine Weise machen, dann sind die Schlüssel in den Zwischentabellen wieder PK, richtig? Ich bin nur etwas verwirrt, weil du die Schlüssel der FilmAllgemein_ID als FK deklariert hast. In meiner Art und Weise habe ich sie nur deshalb als FK deklariert, weil ich ja eine »künstliche ID« erzeugt habe.

Aber ich habe eine allgemeine Frage an dich. Was spricht gegen meine Variante? Verstehe mich nicht falsch. Ich frage dich nicht, weil ich deine Kompetenz in Frage stelle, sondern, weil ich neugierig bin und auch was aus meinen Fehlern lernen will.

 

[Distrilec]

Zunächst einmal finde ich deine »Paint-Kunst« ziemlich gut. Du hast dadurch wesentlich schnell was ausgesagt und wesentlich mehr Zeilen gespart. Ich liebe visuelle Darstellungen.

Aber nun eine Frage. Ist es unwichtig in welcher Reihenfolge die Schlüssel in einer Zwischentabelle abgelegt werden? Zum Beispiel bei der Tabelle Person_Rolle ist der Schlüssel FilmAllgemein_ID an letzter Stelle. Ich nach meiner Überlegung würde ihn an erster Stelle setzten, denn ich denke mir so, ich will vom Film XYZ (FilmAllgemein_ID) die Person XYZ (Person_ID) und die dazugehörige Rolle XYZ (Rolle_ID). Und dann fiel mir noch was auf: Wenn wir es auf deine Weise machen, dann sind die Schlüssel in den Zwischentabellen wieder PK, richtig? Ich bin nur etwas verwirrt, weil du die Schlüssel der FilmAllgemein_ID als FK deklariert hast. In meiner Art und Weise habe ich sie nur deshalb als FK deklariert, weil ich ja eine »künstliche ID« erzeugt habe.

Ja, du hättest dann eine Tabelle voller FK... Was spricht dagegen ?
Kannst dann ja einfach den PK so über die FKs legen {Person_ID, Rolle_ID, FilmAllgemein_ID} und schon hast du dir eine künstliche ID gespart ^^
Die Reihenfolge spielt dabei keine Rolle, der PK muss einen Datensatz ja nur eindeutig beschreiben... Vollkommen wurscht ob die ID am Anfang oder Ende steht

Aber ich habe eine allgemeine Frage an dich. Was spricht gegen meine Variante? Verstehe mich nicht falsch. Ich frage dich nicht, weil ich deine Kompetenz in Frage stelle, sondern, weil ich neugierig bin und auch was aus meinen Fehlern lernen will.

Weniger Tabellen = Weniger Joins = Weniger komplexe Abfragen = Weniger Arbeit

 

[Sophus]

Ja, du hättest dann eine Tabelle voller FK... Was spricht dagegen ?
Kannst dann ja einfach den PK so über die FKs legen {Person_ID, Rolle_ID, FilmAllgemein_ID} und schon hast du dir eine künstliche ID gespart ^^

Ich habe an Sich nichts gegen FK oder PK. Die Datenbank weißt ja sowieso nicht ab wann ein Schlüssel PK oder FK ist. Mir ist es nur aufgefallen, weil in den Zwischentabellen Person_Rolle und Person_Funktion alle Schlüssel als PK deklariert wurden, und bei dir nun alle auf einmal FK sind. Da kam ich etwas ins Stolpern. Nochmal zum Mitschreiben, es ist ganz gleich, ob ich sie nun als PK oder FK deklariere? Ich möchte ja, dass man am Ende noch durchsteigt, denn es kommen noch allerhand Tabellen hinzu

 

[Distrilec]

Ich habe an Sich nichts gegen FK oder PK. Die Datenbank weißt ja sowieso nicht ab wann ein Schlüssel PK oder FK ist. Mir ist es nur aufgefallen, weil in den Zwischentabellen Person_Rolle und Person_Funktion alle Schlüssel als PK deklariert wurden, und bei dir nun alle auf einmal FK sind. Da kam ich etwas ins Stolpern. Nochmal zum Mitschreiben, es ist ganz gleich, ob ich sie nun als PK oder FK deklariere? Ich möchte ja, dass man am Ende noch durchsteigt, denn es kommen noch allerhand Tabellen hinzu

Das ist definitiv nicht egal!

FK bedeutet ja soviel wie: Ein Schlüssel der einen Datensatz in einer ANDEREN Tabelle eindeutig definiert.
PK bedeutet soviel wie: Ein Schlüssel der einen Datensatz in DIESER Tabelle eindeutig definiert.

In meinem Beispiel nehmen wir 3 FKs und diese werden dann zum PK der neuen Tabelle

Edit: Habe grade gesehen... Ich hätte vllt. noch ein PK constraint drunter bauen sollen ^^

 

[akretschmer]

Die Datenbank weißt ja sowieso nicht ab wann ein Schlüssel PK oder FK ist.

Schmarrn.

test=*# create table master (id int primary key);
CREATE TABLE
test=*# create table slave1 (fk int references master);
CREATE TABLE
test=*# create table slave2 (fk int references master);
CREATE TABLE
test=*# \d master
  Table "public.master"
 Column |  Type  | Modifiers
--------+---------+-----------
 id  | integer | not null
Indexes:
  "master_pkey" PRIMARY KEY, btree (id)
Referenced by:
  TABLE "slave1" CONSTRAINT "slave1_fk_fkey" FOREIGN KEY (fk) REFERENCES master(id)
  TABLE "slave2" CONSTRAINT "slave2_fk_fkey" FOREIGN KEY (fk) REFERENCES master(id)

test=*#

Beachte die den letzten Teil der Ausgabe: die DB weiß ganz genau, welche Tabellen via FK auf den PK der Tabelle master verweisen. Also zumindest PostgreSQL weiß darüber Bescheid und nutzt dieses Wissen auch, um u. a. auch das DB-Schema konsistent zu halten:

test=*# drop table master;
ERROR:  cannot drop table master because other objects depend on it
DETAIL:  constraint slave1_fk_fkey on table slave1 depends on table master
  constraint slave2_fk_fkey on table slave2 depends on table master
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT:  drop table master;
ERROR:  cannot drop table master because other objects depend on it
DETAIL:  constraint slave1_fk_fkey on table slave1 depends on table master
constraint slave2_fk_fkey on table slave2 depends on table master
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
test=*#

 

[Sophus]

Hallo Leute,
damit ihr versteht, weshalb ich etwas verwirrt bin, habe ich ein etwas älteres Bild in unserem Thread rausgesucht, was wir schon thematisch abgehandelt haben:

In der Zwischentabelle Nationalität_Person sind die Schlüssel alle als PK deklariert, und in den Zwischentabellen Person_Funktion und Person_Rolle ebenfalls als PK.

Und jetzt?

 

[Distrilec]

@Sophus Das Image funktioniert nicht...

 

[Sophus]

Komisch, also bei mir funktioniert es. Habe meinen Eintrag eben nochmal bearbeitet. Ansonsten findest du das Bild hier in diesem Thread auf Seite 4 Beitrag 7, das ist mein Beitrag auf dieser Seite.

 

[Distrilec]

Ja, also sogesehen ist das beides... Ein FK in die jeweilige Tabelle und ein PK für diese Tabelle... Insofern ist das schon richtig.

 

[Sophus]

Um Missverständnisse as dem Weg zu räumen. Was du nun in den aktuellen Zwischentabellen (Person_Rolle und Person_Funktion) als FK deklariert hattest ist jetzt nun doch PK oder beides, PK und FK?