Modellierung meiner Datenbank

[Sophus]

Auf der Fahrt von der Uni nach Hause habe ich unterwegs noch einmal darüber nachgedacht. Du hast Recht, es ist wirklich besser mit INNER JOIN zu arbeiten. Dies würde die Bedeutung der Datenbank näher kommen und die Performance meines Programms wesentlich gering halten. Denn mein Programm gilt ja als Client, der Befehle an den MySQL-Server gibt, der wiederum die Befehle an die entsprechende Datenbank weiterleitet. Ich hatte wohl nicht so richtig darüber nachgedacht. Wobei bei einer 1:n-Beziehung man doch getrost auf einem INNER JOIN-Statement verzichten könnte oder? Nehmen wir man die Tabellen Geschlecht und Person. Die IDs der jeweiligen Geschlechter liegen als Fremdschlüssel (Geschlecht_ID) in der Tabelle Person. In diesem Fall würde ich einfach die Spalte auslesen, in der der Fremdschlüssel liegt, und mit diesem Schlüssel einfach in der Tabelle Geschlecht danach suchen. Aber bei einer Verknüpfungstabelle ist es wohl etwas komplexer.

Bezüglich der Beziehungen. Das mit den Verknüpfungstabellen sind in der Tat implizite Beziehungen. Aber vergleichen mit dem Schaubild, in welcher man auch grafisch Beziehungen bei Access definieren und strukturieren kann, betrachtete ich meinen Entwurf als »beziehungsfrei«.

Mich würde gerade interessieren, wie bei meinem jetzigen Entwurf die INNER JOINS aussehen mögen. Jedoch denke ist, ist es didaktisch (schließlich will ich ja auch noch was lernen ) erst einmal besser, wenn man die Datenbank komplett strukturiert. Hinterher kann ich euch dann ja mit den SQL-Statements nerven, wenn ihr mich bis dahin nicht schon auf eine einsame Insel verbannt habt

 

[Hony%]

Nehmen wir man die Tabellen Geschlecht und Person.

SELECT *
FROM Person
INNER JOIN Geschlecht
ON Person.Geschlecht_ID = Geschlecht.Geschlecht_ID

Das ist notwendig um bei einer Abfrage der Person auch gleich das Geschlecht in Textform mit auszugeben. Bei einer n:m Beziehung (Verknüpfungstabelle) sind zwei JOINs notwendig. Von kompliziert würde ich da noch lange nicht reden.

Der entscheidende Unterschied ist ganz einfach. Mit einem sauberen Design lassen sich Abfragen meistens so gestalten, dass nur eine einzige notwendig ist. Ohne JOINs benötigst du unter Umständen 10 oder 20 Abfragen. Wenn jede Abfrage nur eine Zehntelsekunde dauert wird die Ping-Pong-Methode 1-2 Sekunden Gesamtlaufzeit benötigen während die einzelne Abfrage mit JOIN gefühlt sofort fertig ist.

Aber vergleichen mit dem Schaubild, in welcher man auch grafisch Beziehungen bei Access definieren und strukturieren kann

Das ist nur Darstellung. Wenn grüne Äpfel eindeutig Äpfel sind. Sind rote Äpfel dann keine?

 

[Sophus]

Der entscheidende Unterschied ist ganz einfach. Mit einem sauberen Design lassen sich Abfragen meistens so gestalten, dass nur eine einzige notwendig ist. Ohne JOINs benötigst du unter Umständen 10 oder 20 Abfragen. Wenn jede Abfrage nur eine Zehntelsekunde dauert wird die Ping-Pong-Methode 1-2 Sekunden Gesamtlaufzeit benötigen während die einzelne Abfrage mit JOIN gefühlt sofort fertig ist.

Dann würde ich sagen, lass uns die Datenbank weiter sauber strukturieren, und mit den SQL-Statements verlegen wir dann auf später Hast du was zu meinem Beispiel noch anzumerken, in welcher ich Rolle und Funktion noch hinzugezogen habe? Damit ich das Thema "Person" abschließen kann.

 

[Hony%]

Hast du was zu meinem Beispiel noch anzumerken, in welcher ich Rolle und Funktion noch hinzugezogen habe?

Das Beispiel des Verrückten Professors ist ungeeignet um eine Zwischentabelle zu rechtfertigen. Die Person_ID kann problemlos bei den Rollen gespeichert werden. Richtig ist ist die Zwischentabelle trotzdem. In Das Kabinett des Doktor Parnassus wird die Rolle des Tony vom verstorbenen Heath Ledger sowie Jonny Depp, Jud Law und Colin Farrell gespielt. Also 4 Schauspieler für eine Rolle.

Ansonsten sehe ich da im Moment keine Probleme.

 

[Sophus]

Na ja, mit dem Film »Der verrückte Professor« wollte ich nur verdeutlichen, dass man Randsituationen nicht auslassen sollte. In diesem Fall wäre es eher hinderlich, wenn bei diesem Film die Zwischentabelle fehlen würde, oder? Oder meinst du trotzdem, dass es problemlos wäre?

 

[Hony%]

Der Prof braucht keine Zwischentabelle da du ja Eddy ja bei mehreren Rollen eintragen kannst.

 

[Sophus]

Inwiefern wäre diese Zwischentabelle trotzdem richtig? Basiert die Aussage auf rein theoretischem Grundgedanke? Oder sehe ich da auch einen tatsächlichen Nutzen?

 

[Hony%]

Das Beispiel habe ich doch schon geliefert. In »Das Kabinett des Doktor Parnassus« wird EINE Rolle von VIER unterschiedlichen Darstellern gespielt. Daher besteht zwischen Darsteller und Rolle eine n:m Beziehung. Und n:m Beziehungen lassen sich nur mit Zwischentabelle abbilden.

 

[Sophus]

Oh, entschuldige. Ich hatte das mit deinem Beispiel zu flüchtig gelesen und gar nicht kapiert. Unter diesen Unterständen ist es schon logisch.

 

[Sophus]

Im nächsten Schritt wenden wir uns der Film-Komponenten zu. Jedoch stecke ich einer Denk-Schleife, und frage mich die ganze Zeit, wie ich dies bewältigen soll, daher wird mein Schaubild nicht vollständig sein und bräuchte da mal euren Rat. Hier das Schaubild:

Auf der rechten Seite des Bildes sehen wir nun die Tabelle FilmAllgemein. Zunächst meine Erklärung: Mit FilmAllgemein meine ich einfach, dass dort Informationen gespeichert werden, unabhängig welche Filmfassung es ist. Wir kennen es bei Horrorfilmen zu gut. Von einem Film gibt es eine FSK16, dann FSK18 und dann noch Indiziert. Vor diesem Hintergrund gibt es dann unterschiedliche Laufzeiten, Veröffentlichungs-Zeiten etc. Aber in dieser Tabelle soll Informationen gespeichert werden, die zunächst einmal mit den unterschiedlichen Fassungen nichts zu tun haben - quasi eine Einheits-Information.

Wenn euch diesbezüglich noch was einfällt, was man noch allgemein zum Film abspeichern könnte, dann immer her damit

Nun zu meinem Problem. Wie ihr seht, habe ich noch keine Beziehung zu der Tabelle FilmAllgemein hergestellt. Nun frage ich mich, ob ich hierbei eine weitere Zwischentabelle erstellen soll, die wiederum mit den Zwischentabellen Person_Funktion und Person_Rolle in Beziehung stehen? Oder soll der primäre Schlüssel FilmAllgemein_ID als Fremdschlüssel in den jeweiligen Zwischentabellen Person_Funktion und Person_Rolle hinterlegt werden?

 

[Sophus]

Hallo Leute, ich hoffe ihr hattet alle tolle Weihnachtstage und ihr seid super ins neue Jahr gerutscht? Habt ihr schon eine Idee zu meinem Problem?

 

[akretschmer]

Hallo Leute, ich hoffe ihr hattet alle tolle Weihnachtstage und ihr seid super ins neue Jahr gerutscht?

Ja.

Habt ihr schon eine Idee zu meinem Problem?

tl;dr.

Sorry, der Thread ist mir zu komplex geworden.

 

[Sophus]

Woran hapert es? Vielleicht kann ich dir ja eine schnelle Einführung geben, damit du auf dem aktuellen Stand bist.

 

[Distrilec]

Ich glaube es liegt an derzeit 10 Tabellen voll mit PKs, FKs etc. (Tendenz steigend)

Zum Thema:
Ein FK zur Tabelle FilmAllgemein in den Tabellen Person_Rolle und Person_Funktion sollte ausreichen.
Wobei ich bei Person_Rolle fast schon eher zur Tabelle Rolle tendieren würde... Oder kann eine Rolle in mehreren Filmen vorkommen ?

 

[Sophus]

Ich glaube es liegt an derzeit 10 Tabellen voll mit PKs, FKs etc. (Tendenz steigend)

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

Zum Thema:
Ein FK zur Tabelle FilmAllgemein in den Tabellen Person_Rolle und Person_Funktion sollte ausreichen.
Wobei ich bei Person_Rolle fast schon eher zur Tabelle Rolle tendieren würde... Oder kann eine Rolle in mehreren Filmen vorkommen ?

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?