[mysql] Frage zur Struktur einer FilmDB

[Peter Plastik]

Hallo zusammen!

Ich habe vor, eine Datenbank all meiner Filme mit den dazugehörigen Informationen zu erstellen. Gibt es zwar alles schon im Internet, aber es geht mir primär darum, die SQL Befehle zu lernen und richtig damit umzugehen. Allerdings bin ich mir noch nicht ganz sicher, wie die Struktur aussehen sollte.

Bis jetzt habe ich drei Tabellen:

1.Film (film_id(PK),titel,orig_titel,jahr,land,format,sprache,beschreibung,cover)
2.Darsteller (actor_id(PK),Name,Vorname)
3.spielt_in (film_id,actor_id) primary key (film_id,actor_id)

Nun überlege ich wie ich am Besten den Regiesseur miteinbringen könnte. Zunächst bin ich davon ausgegangen, dass jeder Film genau einen Regiesseur hat und wollte dessen namen einfach als VarChar unter dem Attribut "Regie" in der Tabelle Film speichern. Alledings bin ich jetzt schon auf mehrere Filme gestoßen, die zwei oder sogar drei Regiesseure hatten.

Also hab ich ja quasi nur zwei Möglichkeiten:

Entweder ich mach es genau wie mit den Darstellern (also eigene Tabelle fürs Entity Regiesseur und eine Beziehungstabelle "führt_Regie") oder ich verletzte die Bedingung dass Attribute atomar sein müssen und füge halt mehrere Regisseure als Wert in das Attribut "Regie" in der Tabelle Film ein. Das dürfte, da ja die meißten Filme eh nur einen Regiesseur haben, nicht allzu häufig vorkommen, wirkt aber doch irgendwie gemurkst finde ich. Insbesondere bei den Abfragen könnte ja dann der eine oder andere Regisseur mal verloren gehen. Würde also gerne mal wissen wie das die Leute sehen, die sich schon ein wenig besser mit Datenbanken auskennen, bin leider noch blutiger Anfänger ;-)

Das selbe Problem exisiert in dieser DB nochmal mit dem Attribut Sprache. Die meißten Filme, die ich habe, sind zwar in Deutsch, allerdings auch einige DVDs dabei mit mehreren Sprachen. Was mach ich hier?

Schonmal Danke im voraus!

Peter

 

[hpvw]

Hey, super, endlich mal jemand, der mit einer vernünftigen DB-Struktur beginnt.
Bekanntlich führen viele Wege nach Rom, auch viele normalisierte DB-Strukturen gibt es, die einen Sachverhalt richtig abbilden. Daher will ich in erster Linie ein paar Ideen in den Raum schmeißen.

Ich sehe im Wesentlichen zwei Wege:
1.
Du verallgemeinerst die Darstellertabelle zu eine Personentabelle.
Die Verknüpfungstabelle nennst Du um in "wirkt_in_film_mit".
Dazu schaffst Du Dir eine Mitwirkungsarttabelle an, in der Du die verschiedenen Arten, an denen man bei einem Film mitwirken kann, einträgst, also Regisseur, Darsteller, Drehbuchautor und was Du jetzt oder später noch alles gerne hättest.

Tabelle "ArtDesMitwirkens":
ID INT
Art CHAR
evtl. weitere Attribute, wie Relavanz der Art, um Suchergebnisse nach Wichtigkeit zu sortieren, zum Beipiel.

Tabelle "wirkt_in_film_mit":
FilmID
PersonID
ArtDesMitwirkensID

Diese Art hat den Vorteil, dass Du ohne Änderungen an der Datenbankstruktur, schnell die Möglichkeiten der Datenbank erweitern kannst.
Desweiteren ist ein Vorteil, dass Du in Deinen Skripten/Anwendungsprogrammen nichts ändern musst, wenn Du weitere Arten der Mitwirkung hinzufügst und extrem dynamische Such- und Auswahlkriterien definieren kannst, ohne Deine Abfragen anzupassen.

2.
Du änderst Deine Darstellertabelle in eine Personentabelle und machst für jede Art der Verknüpfung eine eigene Tabelle. Das hätte den Vorteil, dass Du bei bestimmten Arten von "Mitwirken" besondere Zusatzattribute einfügen kannst, wie zum Beispiel die Rolle, die ein Darsteller spielt.

Eventuell könnte man die beiden Wege (die nur zwei von vermutlich vielen sind) verbinden, indem man zum Beipiel ein nicht näher spezifiertes Zusatzattribut bei der Mitwirkungsart einführt, aber damit verliert man wieder einen Teil der Dynamik und des "nicht-anpassen-müssen" der Anwendungssoftware, da die Anwendungssoftware wissen muss, was das Zusatzattribut für eine bestimmte Mitwirkungsart bedeuted. An der letzten Formulierung sieht man aber auch, dass man es auf die Spitze treiben kann, und die Bedeutung des Zusatzattributs in der Mitwirkungsarttabelle definieren kann. Damit bleibt es nur noch eine Frage der Darstellung, die man evtl. anpassen müsste. Man kann dann aber für jede bezüglich der Darstellung nicht spezifizierte Mitwirkungsart eine Standartdarstellung implementieren, die zumindest die Informationen preisgibt.

Auf jeden Fall halte ich es für sinnvoll (im Sinne der Normalisierung), aus der Darstellertabelle eine Personentabelle zu machen, da viele Darsteller auch in dem ein oder anderen Film Regie geführt haben.

Mit den Sprachen (oder auch Genres und ähnliches) solltest Du es machen, wie man es immer (siehe Deine jetzige Darstellerstruktur) mit n:m-Bezihungen macht. Für jede Entität eine Tabelle und eine weitere zur Verknüpfung (für_film_verfügbare_sprachen) der einen Entität (Film) mit der anderen Entität (Sprache).

Ich hoffe, ich konnte Dir ein paar Anregungen geben.

Gruß hpvw

PS: Erschrick nicht, normalisierte Datenbanken haben es so an sich, dass sie aus endlos vielen Tabellen bestehen, die bei den Abfragen mit etlichen JOIN's verknüpft werden. Mein bislang längstes Query geht über ca. 60 Zeilen (ca. 20 Zeichen pro Zeile) und verknüpft 12 Tabellen, dabei kommt der WHERE-Teil zur Suche, falls einschränkende Kriterien greifen sollen, noch dynamisch hinzu. Aber Du willst die DB ja auch haben, um SQL-Befehle zu üben. Dafür ist eine Struktur mit vielen n:m-Beziehungen hervorragend geeignet, nur aufgeben darfst Du nicht.

EDIT: Habe jetzt erst das mit dem blutigen Anfänger gelesen, dafür machst Du es aber schon besser, als viele andere, die mit völlig "unnormalen" Tabellen aufs Parkett treten. Falls Du ihn noch nicht kennst: Mein Lieblingslink

 

[Peter Plastik]

Super vielen Dank für die ausführliche Antwort! Werd es wohl nach Alternative 1.) machen, da ich so ja wirklich jeden, der in irgendeiner Form mit einem Film zu tun hat, unterbringen kann. Hatte eigentlich nur an Darsteller und Regiesseure gedacht und das hätte wohl ein paar Problemchen später bei eventuellen Erweiterungen des einbezogenenen Personenkreises gegeben.

Blutiger Anfänger bin ich deshalb, weil ich noch nie irgendwas mit Datenbanken zu tun gehabt hatte vorher. Wahrscheinlich hätte ich sql für nen Instant Messanger gehalten wenn man mich danach gefragt hätte ;-)
Allerdings bin ich schon mit einigen theoretischen Dingen vertraut wie dem Relationenmodell und ANSI/SPARC Architekturmodell hab ich auch schon mal was von gehört ;-) Das mit den Normalformen hab ich in etwa auch kapiert (zumindest bis zur 3.) Denke aber das sollte keine Probleme bereiten, da ich ja nicht sonderlich viele funktionale Abhängigkeiten zu beachten habe.

Die Tabelle Film müsste doch eigentlich schon von vornerein in 3NF sein oder? 2te sowieso weil kein zusammengesetzer Primärschlüssel und 3te dann weil keine transitiven Abhängigkeiten bestehen?

 

[hpvw]

Blutiger Anfänger bin ich deshalb, weil ich noch nie irgendwas mit Datenbanken zu tun gehabt hatte vorher. Wahrscheinlich hätte ich sql für nen Instant Messanger gehalten wenn man mich danach gefragt hätte ;-)
Allerdings bin ich schon mit einigen theoretischen Dingen vertraut wie dem Relationenmodell und ANSI/SPARC Architekturmodell hab ich auch schon mal was von gehört ;-) Das mit den Normalformen hab ich in etwa auch kapiert (zumindest bis zur 3.) Denke aber das sollte keine Probleme bereiten, da ich ja nicht sonderlich viele funktionale Abhängigkeiten zu beachten habe.

Dann muss ich ja mal sagen, dass Du genau richtig angefangen hast, erst die wichtigen Konzepte und dann die Implemetierung. Die dritte NF reicht wohl in der Regel für private Anwendungen.

Die Tabelle Film müsste doch eigentlich schon von vornerein in 3NF sein oder? 2te sowieso weil kein zusammengesetzer Primärschlüssel und 3te dann weil keine transitiven Abhängigkeiten bestehen?

Jein, Sprache ist IMHO nicht in der ersten NF. Da es mehrere Sprachen geben kann, ist das Attribut nicht atomar.
Transitive Abhängigkeiten sehe ich auch nicht.
Zusammengesetzte Primärschlüssel wiedersprechen nicht der ersten bis dritten Normalform.

Ich hatte gestern Abend lange Weile und Interesse, daher habe ich mal eine etwas extreme Film-DB gestaltet, falls es Dich interessiert, findest Du sie im Anhang.
Ein paar Anmerkungen dazu:
Fassung sind z.B. verschiedene DVDs, die herausgegeben wurden oder die Kinofassung oder verschiedene Schnitte.
Unter Medium verstehe ich sowas, wie DVD, VHS o.ä.
Unter FSK, wohl klar, die Altersfreigabe.
Unter Schnittbeschreibung Dinge, wie Kinofassung, directors-cut, Fernsehschnitt, uncut.
Unter Audioformat sind Sachen, wie Dolby Surround 5.1, Stereo etc zu verstehen.
Mitwirkungsart habe ich im ersten Post beschrieben.
Genre ist wohl klar, Action, Komödie, Thriller etc.
So wie ich mir den Inhalt vorstelle ist die DB in der dritten NF, aber ich mag etwas übersehen haben.
BCNF ist natürlich durch die künstlich eingeführten IDs verletzt, aber damit lebe ich, wegen der Vereinfachung für die Anwendungssoftware, mit eindeutigen Zahlen umgehen zu können.
Verletzung der vierte NF sehe ich nicht prinzipiell (außer, dass sie nicht BCNF genügt), ließe sich aber sicher bei Mitwirkungsart konstruieren.
Mehr als die vierte NF war bei uns nie Thema und Weitergehendes wurde mit dem Kommentar "irgendwann wird's esoterisch" abgetan.
Zugegeben verstehe ich auch nicht ganz, was der Wikipedia-Artikel bei der fünften NF meint.
Für esoterische Hirnverwindungen kannst Du ja mal dem Link (auch über Wikipedia hingekommen) folgen, allerdings bin ich danach um ein paar Verwicklungen im Hirn reicher, aber verstanden habe ich es trotzdem nicht so ganz.
Das einzige, wobei ich mir sicher bin ist, dass die fünfte NF extrem aufwendig zu überprüfen ist.

Gruß hpvw

EDIT: Mir fällt gerade auf, eine Tabelle fehlt noch:
Bonusmaterial
-ID INT (Primary Key)
-FassungID INT
-Bonustitel CHAR
-Bonusbeschreibung TEXT

Außerdem könnte man bei Fassung noch das Attribut Dauer (Filmdauer in Minuten) anfügen und bei Film, das Jahr in dem gedreht wurde und bei der Fassung, das Datum der Erstausstrahlund/des Erscheinungsdatums beim Händler/das Erstaustrahlungs-/Aufnahmedatum bei Fernsehfassungen. Die Bedeutung des Datums könnte wie bei der Mitwirkungsart oder noch etwas komplizierter implementiert werden.

Außerdem ließen sich noch mit einer weiteren Tabelle Vorgänger- und Nachfolger-Beziehungen der Filme implementieren (Matrix - Matrix Reloaded - Matrix Revolutions) oder auch Verwandschafts-/Beziehungsverhältnisse der Personen, alles mit dem Zweck für Hintergrundinformationen.