Wie würdet ihr die SQL-Tabelle konstruieren?

[mysqlfan]

Hallo!

Ich bin gerade dabei, eine MySQL-DB aufzubauen, die ähnlich dem Konzept einer International Movie Database (imdb.com) ist.

Zu einem bestimmten DVD-Titel sollen zahlreiche Informationen gefunden werden, unter anderem die mitwirkenden Schauspieler und welche Charaktere sie in dem Film darstellen.

Meine Überlegung:

Tabelle 1 dvd:
------------------------------
DVD_ID | Titel
100001 | Jurassic Park
------------------------------

Tabelle 2 actor:

------------------------------
Actor_ID | DVD_ID | Name
200001 | 100001 | Wayne Knight
------------------------------

Tabelle 3 character:

------------------------------
Character_ID | Actor_ID | Name
300001 | 200001 | Dennis Nedry
------------------------------

Probleme:
1. Jeder Character wird meist nur 1x gespielt und braucht dafür nicht unbedingt eine einzelne ID. Sprich: Es wird keine Suchabfragen geben, wie: Finde alle Filme, in denen Dennis Nedry vorkommt (gibt nur einen).

2. Ein Schauspieler spielt logischerweise in sehr vielen Filmen mit. D.h., die Verknüpfung Actor_ID | DVD_ID | Name muss mehrere DVD_IDs beinhalten.

Ich dachte mir vielleicht, das könnte so gehen:

Tabelle 1 dvd:
------------------------------
DVD_ID | Titel
100001 | Jurassic Park
100002 | Kung Fu Panda
------------------------------

Tabelle 2 actor:

------------------------------
Actor_ID | DVD_ID | Name
200001 | 100001, 100002 | Wayne Knight
------------------------------

Tabelle 3 character:

------------------------------
DVD_ID | Actor_ID | Character
100001 | 200001  | Dennis Nedry
100002 | 200001  | Gang Boss

-----------------------------

Damit könnte man zwar die Informationen verknüpfen und ausgeben, aber ich finde die Lösung irgendwie unpraktikabel bzw. unelegant.
Das Ding rechnet sich doch bei 50 Schauspielern zu Tode, oder?

Meine Frage: Wie würdet ihr diese Tabellen aufbauen?

IMDB hat es ja so gemacht, dass man jedem Character eine ID zuordnet, aber vermutlich nur deshalb, weil User dann dazu eine Rezension/Personenbeschreibung schreiben und die Figur bewerten können.

Generell:

Da ich noch nicht so viele DBs abgelegt habe und die meisten von denen auch nur aus einer oder zwei Tabellen bestanden, wie wäre es am geeignetsten: Ab wieviel Spalten sollte man eine eigene Tabelle aufbauen?

Zu der DVD sollen ja auch z.B. Director (Regisseur) und Writer (Drehbuchautor) gespeichert werden.

Ich persönlich hätte kein Problem damit, es in Tabelle 1 dazuzupacken.

Tabelle 1 dvd:
------------------------------
DVD_ID | Titel | director
100001 | Jurassic Park | Steven Spielberg
------------------------------

Die wichtigste Information: Finde alle Titel, die Steven Spielberg produziert hat, findet man ja damit auch.

Eigentlich sind eigenständige Tabellen ja nur dann wichtig, wenn man Zusatzinformationen wie director_birthdate oder sonstige persönlichen Daten verwalten will, oder?

Wäre super, wenn mir da ein paar gute Tipps gegeben werden. Schon mal allerbesten Dank im voraus.

[suit]

Tabelle 1 dvd:

DVD_ID | Titel
100001 | Jurassic Park
100002 | Kung Fu Panda

Tabelle 2 actor:

---

Actor_ID | DVD_ID | Name
200001 | 100001, 100002 | Wayne Knight

Tabelle 3 character:

---

DVD_ID | Actor_ID | Character
100001 | 200001  | Dennis Nedry
100002 | 200001  | Gang Boss

Hier fehlt dir mindestens eine Tabelle die Actor und DVD verbindet (n:m) - eine kommaseparierte Liste ist weniger schlau.

Zudem: die Tabellen solltest du nicht "DVD_"-irgendwas nennen, nenn sie "movie" oder so, es gibt schließlich Filme nicht nur auf DVDs.

Ebenfalls solltest du dir darüber gedanken machen, wenn ein Charakter von mehreren Schauspielern verkörpert wird (z.B: Darth Vader in der Original-Trilogie) oder wenn ein Schauschpieler mehrere Charaktäre in einem Film verkörpfert (z.B.  Eddie Murphy in Big Mamas Haus)

[Harlequin]

Yerf!

Tabelle 1 dvd:

DVD_ID | Titel
100001 | Jurassic Park

Passt.

Tabelle 2 actor:

---

Actor_ID | DVD_ID | Name
200001 | 100001 | Wayne Knight

Die DVD_ID fliegt hier ersatzlos raus.

Tabelle 3 character:

---

Character_ID | Actor_ID | Name
300001 | 200001 | Dennis Nedry

Eine Character_ID wird wie du schon bemerkt hast nicht unbedingt benötigt. Dafür muss hier noch die DVD_ID mit rein. Die Zuordnung von Actor und DVD läuft dann über die Character-Tabelle (n:m Beziehung)

Gruß,

Harlequin

[EKKi]

Mahlzeit mysqlfan,

Tabelle: Movie
ID     | Title
-------+--------------
100001 | Jurassic Park

Tabelle: Actor
ID   | Name
-----+-------------------------
4711 | Sir Richard Attenborough

Tabelle: Character
ID | Name
---+-----------------
42 | Dr. John Hammond

Tabelle: Role
ID | Movie_ID | Character_ID | Actor_ID
---+----------+--------------+---------
23 |   100001 |           42 |     4711

So kannst Du sicherstellen, dass:

1.) beliebige Schauspieler in beliebigen Filmen auch mehrere Charaktere spielen können

2.) beliebige Charaktere auch in mehreren Filmen vorkommen können - und dabei auch von unterschiedlichen Schauspielern gespielt werden können (ich denke dabei an Charaktere in Filmreihen z.B. "Anakin Skywalker" in "Star Wars")

Und vergiss wie bereits gesagt *GANZ SCHNELL* Bockmist wie "mehrere IDs Komma-separiert in einer Spalte speichern", sondern informiere Dich zum Thema Normalisierung!

MfG,
EKKi

[Harlequin]

Yerf!

2.) beliebige Charaktere auch in mehreren Filmen vorkommen können - und dabei auch von unterschiedlichen Schauspielern gespielt werden können (ich denke dabei an Charaktere in Filmreihen z.B. "Anakin Skywalker" in "Star Wars")

Ok, die Fälle gibts ja auch noch... von daher ist dein Ansatz mit den 4 Tabellen wohl besser.

Gruß,

Harlequin

[dedlfix]

Hi!

2.) beliebige Charaktere auch in mehreren Filmen vorkommen können - und dabei auch von unterschiedlichen Schauspielern gespielt werden können
Ok, die Fälle gibts ja auch noch... von daher ist dein Ansatz mit den 4 Tabellen wohl besser.

Und es gibt Mehrfachverfilmungen des selben Stoffes, so dass gleiche Figuren in unterschiedlichen Filmen von jeweils anderen Schauspielern gespielt wurden. Außerdem gibt es Filme, die aufgrund des eisernen Vorhangs mindestens zweimal synchronisiert und von jeweils anderen Stimmen gesprochen wurden, falls du auch noch Synchronsprecher festhalten willst. Ganz zu schweigen von Synchronisierungen für andere Sprachen.

Lo!

[EKKi]

Mahlzeit dedlfix,

Außerdem gibt es Filme, die aufgrund des eisernen Vorhangs mindestens zweimal synchronisiert und von jeweils anderen Stimmen gesprochen wurden, falls du auch noch Synchronsprecher festhalten willst. Ganz zu schweigen von Synchronisierungen für andere Sprachen.

Das könnte man dann (ausgehend von dem von mir skizzierten Modell) z.B. folgendermaßen lösen:

Tabelle: Dubbing
ID | Role_ID | Language_ID | Actor_ID
---+---------+-------------+---------
15 |      23 |           1 |      987

MfG,
EKKi

[mysqlfan]

Schon mal ganz herzlichen Dank allen für die guten Anregungen.

Ich merke schon, das wird alles andere als eine triviale Sache...wird viel Arbeit :-) .

[GrandmasterA]

...wird viel Arbeit :-) .

Was glaubst Du, wieviel Arbeit es erst macht, solche Tabellen mit Daten zu füllen... Ich persönlich sitz da bei mir seit 3 Jahren dran ^^

[mysqlfan]

...wird viel Arbeit :-) .

Was glaubst Du, wieviel Arbeit es erst macht, solche Tabellen mit Daten zu füllen... Ich persönlich sitz da bei mir seit 3 Jahren dran ^^

Aus dem Grund bin ich auch auf der Suche nach Möglichkeiten, zahlreiche Datensätze zu übernehmen.

Es gibt ja die IMDB in Form von Plain Text Daten.
Leider liegt die actors.list nur als Einzeldatei mit 540 MB vor, die sämtliche Editoren, die mir zur Verfügung stehen in die Knie zwingt.

Weiß jemand in dem Zusammenhang, wie ich eine 540 MB große .list-Datei verarbeiten kann?

[GrandmasterA]

Es gibt ja die IMDB in Form von Plain Text Daten.

Hast Du Dich auch hinreichend informiert, ob die IMDB die Nutzung dieser Dateien als öffentliche Internet-Datenbank erlaubt? Oder hast Du vor, die 15.000 US-Ocken pro Jahr dafür zu bezahlen?

[Kay]

Hallo mysqlfan,

wenn Du ein relationales Datenbankmodell benutzen willst, dann gehört auch eine Normalisierung dazu.

Kurzfassung hier

http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

http://de.wikipedia.org/wiki/Datenbankmodell

Einfach mal lernen sauber zu arbeiten !

Dann sollten sich auch alle Fragen wieviel Tabellen oder was in eine Tabelle gehört, geklärt haben.

Ob sich eine Datenbank zu Tode rechnet oder nicht, sollte egal sein solange die Anwortszeit stimmt. Priorität hat ein sauberes Datenmodell.

Kay

[Blubb]

Hallo,

Wäre super, wenn mir da ein paar gute Tipps gegeben werden. Schon mal allerbesten Dank im voraus.

versuch es als erstes mal mit Zettel und Stift, bevor du dich an SQL-Anweisungen wagst.

Was du brauchst ist eine Übersicht über deine Objekte, die Beziehungen dieser untereinander und die zugehörigen Kardinalitäten. Wenn du das hast, sprich: dein Modell mit deiner Anforderung übereinstimmt, dann bekommst du die primären Schlüssel und foreign keys fast geschenkt.

Grüße

[Ilja]

moin,

Wäre super, wenn mir da ein paar gute Tipps gegeben werden. Schon mal allerbesten Dank im voraus.

lass dich nicht von den verweisen auf die normalsierung verwirren. erstens versteht die kein anfänger und zweitens wenden selbst die meisten sql profis sie nicht richtig an. ich halte sie ganz einfach für überholt, da muss mal was neues her.

wichtig ist es sich bewußt zu sein, dass du deine welt modellierst, sprich datendesign ist also eine sehr spezifische sache. was für dich richtig ist, kann für andere falsch sein. der zweite knackpunkt ist zu entscheiden, wann ich daten voneinander trenne und wann ich sie zusammen fasse. das hat viel mit abhängikeiten und somit mit kontrolle zu tun. und nicht immer scheint der erste blick dabei der richtige zu sein.

ich gebe dir mal ein beispiel, du kannst zu den jeweiligen filmen die schauspieler festhalten die meisten würden dafür den schauspieler in eine tabelle "schauspieler" anlegen den film entsprechend in einer anderen tabelle "film" und dann durch fremdschlüssel sie miteinander verbinden, meistens durch eine zusätzliche beziehungstabelle. so kann ein schauspieler in mehreren filmen mitmachen und ein film mehrere schauspieler haben. hinzu kommen noch in der tabelle schauspieler vorname und nachname, etc. die frage ist nur, will ich das für meinen spezifischen fall auch so machen, reicht mir das, was passiert den, wenn sich jetzt der name eines schauspielers ändert, dann dreht der sich bei allen filmen mit, wo er mitgemacht hat. das kann gewolllt sein, es kann aber auch sinnvoll sein, die namen in der beizehungstabelle zu speichern, als sie den film gedreht hatten, der immer so schön am ende des films noch angezeigt wird.

du siehst, man muss genau hinschauen, was man haben will, es ist sehr individuell. der fehler, der viel zu oft gemacht wird ist, man sieht zwei dinge, die den gleichen inhalt haben und schreit sofort normaliserung, weil man glaubt redundanzrn zu haben. aber das gleiche muss nicht zwangsläufig auch das selbe sein und dieser unterschied ist sehr, sehr wichtig in bezug auf daten-modellierung...

Ilja

[EKKi]

Mahlzeit Ilja,

was passiert den, wenn sich jetzt der name eines schauspielers ändert, dann dreht der sich bei allen filmen mit, wo er mitgemacht hat. das kann gewolllt sein, es kann aber auch sinnvoll sein, die namen in der beizehungstabelle zu speichern, als sie den film gedreht hatten, der immer so schön am ende des films noch angezeigt wird.

Dann wäre aber der Name in der Beziehungstabelle falsch, da er in keinerlei logischen Abhängigkeit zum Film steht. Der Name ist eine Eigenschaft bzw. Attribut des Schauspielers - unabhängig vom Film ... allerhöchstens abhängig von der Zeit. Also:

Tabelle: Schauspieler
ID | Vorname
---+--------
42 | Verona

Tabelle: Nachname
ID | Schauspieler_ID | Datum_Bis  | Name
---+-----------------+------------+----------
 5 |              42 | 18.05.2004 | Feldbusch
23 |              42 |            | Pooth

Mit einem UNIQUE-Constraint auf die Spalten (Schauspieler_ID,Datum_Bis,Name) ...

:-)

MfG,
EKKi

[Harlequin]

Yerf!

Das wäre die saubere Lösung. Aber manchmal ist es tatsächlich besser Informtionen nicht zwanghaft in extra Tabellen auszulagern.

Aber wenn ihr Lust habt kann ich ja mal mein Datenmodell, an dem ich grad arbeite hier mal zur Diskussion stellen. Wird bestimmt lustig ;-)

Gruß,

Harlequin

[Ilja]

moin,

Dann wäre aber der Name in der Beziehungstabelle falsch, da er in keinerlei logischen Abhängigkeit zum Film steht. Der Name ist eine Eigenschaft bzw. Attribut des Schauspielers - unabhängig vom Film ... allerhöchstens abhängig von der Zeit.

das kann man so pauschal nicht sagen, ich wiederhole mich gerne, es ist fall spezifisch. vielleicht hat er ja zu bestimmten filmen unterschiedliche künstlernamen benutzt, die zur gleichen zeit gedreht wurden, whatever. man muss die daten so modellieren, wie sie für einem selbst passen. klar hat man dabei vorgaben aus der realen welt, aber auch dabei muss man sich immer überlegen, will ich es so haben. was mich halt oftmals stört, man sieht datensätze mit gleichen werten und ruft nur all zu gerne nach der normalisierung. und das ist einfach falsch, die gründe dafür sind andere, nämlich abhängikeiten und dateninhalte.

Ilja

[Harlequin]

Yerf!

was mich halt oftmals stört, man sieht datensätze mit gleichen werten und ruft nur all zu gerne nach der normalisierung. und das ist einfach falsch, die gründe dafür sind andere, nämlich abhängikeiten und dateninhalte.

Wobei das eigentlich kein Argument gegen Normalisierung ist, sondern eher ein Argument für eine sehr genau Betrachtung der Daten, ob sie *wirklich* gleich sind. Wenn das mal geklärt ist kann man problemlos die Normalisierung drauf anwenden, denn diese schreibt nirgendwo vor nicht gleiche Daten zusammenzufassen.

Gruß,

Harlequin

[Ilja]

moin,

Wobei das eigentlich kein Argument gegen Normalisierung ist, sondern eher ein Argument für eine sehr genau Betrachtung der Daten, ob sie *wirklich* gleich sind. Wenn das mal geklärt ist kann man problemlos die Normalisierung drauf anwenden, denn diese schreibt nirgendwo vor nicht gleiche Daten zusammenzufassen.

was aber nicht heißt, dass es keine argumente gegen normalierung gibt. grundsätzlich ist es ein analyse tool, sprich man braucht ein daten-design, um es bewerten zu können, mindestens die sogenannte 0. normalform. es ist also nichts, womit ich was auf den leeren papier entwickeln kann. hinzu kommt noch, dass es auf sprechenden schlüssel aufgebaut ist (bei künstlichen schlüsseln muss ich die bedeutung der jeweiligen tabelle nehmen), was ich in der praxis aber eher selten habe, es kann deine daten zusammenführen, die zusammen gehören...

Ilja