Sie müssen zwischen Attributen und Entitäten unterscheiden. Eine Entität ist eine Sache – normalerweise ein Substantiv. Ein Attribut ist eher eine beschreibende Information. Im Datenbankjargon ist Entität =Tabelle, Attribut =Feld/Spalte.
Eine separate Tabelle für bestimmte Dinge zu haben, verwenden wir beispielsweise den Direktor, wird als Normalisieren bezeichnet. Während es unter manchen Umständen gut sein kann, kann es unter anderen unnötig sein (da es im Allgemeinen Abfragen komplizierter macht – Sie müssen alles verbinden – und es langsamer ist).
In diesem Fall ist es unnötig, eine Jahrestabelle zu haben, da es außer dem Jahr selbst keine anderen Attribute zu einem Jahr gibt, die Sie speichern würden. Es ist besser, dies zu denormalisieren und das Jahr in der Filmtabelle selbst zu speichern.
Der Regisseur hingegen ist anders. Vielleicht möchten Sie den Vornamen, den Nachnamen, das Geburtsdatum, das Todesdatum (falls zutreffend) usw. des Regisseurs speichern. Natürlich möchten Sie nicht jedes Mal das Geburtsdatum des Regisseurs eingeben, wenn Sie einen Film mit dieser Person eingeben leitet, daher ist es sinnvoll, eine separate Einheit für einen Direktor zu haben.
Selbst wenn Sie nicht alle diese Informationen über den Regisseur speichern wollten (Sie möchten nur seinen Namen), ist es nützlich, eine separate Tabelle dafür zu haben (und einen Ersatzschlüssel zu verwenden - dazu komme ich gleich). verhindert typografische Fehler und Duplikate - wenn Sie den Namen einer Person falsch geschrieben oder anders eingegeben haben (erster, letzter vs. letzter, erster), werden Sie scheitern, wenn Sie versuchen, andere Filme zu finden, bei denen sie Regie geführt haben.
Die Verwendung eines Ersatzschlüssels (Primärschlüssel) für Tabellen ist im Allgemeinen eine gute Idee. Das Abgleichen einer Ganzzahl ist viel schneller als das Abgleichen einer Zeichenfolge. Außerdem können Sie den Namen frei ändern, ohne sich Gedanken über die in anderen Tabellen gespeicherten Fremdschlüssel machen zu müssen (die ID bleibt gleich, Sie müssen also nichts tun).
Sie können dieses Design wirklich ziemlich weit bringen, und es geht nur darum, herauszufinden, was Sie darin speichern können.
Beispielsweise haben einige Filme nicht nur einen Regisseur pro Film, sondern mehrere Regisseure. Es gäbe also eine Viele-zu-Viele-Beziehung zwischen Filmen und Regisseuren, also bräuchten Sie eine Tabelle mit zB:
films_directors => **filmid, directorid**
Um noch einen Schritt weiter zu gehen:Manchmal sind Regisseure auch Schauspieler und umgekehrt. Anstatt also Regisseur- und Schauspielertabellen zu haben, könnten Sie eine Einzelpersonentabelle haben und diese Tabelle mit einer Rollentabelle verbinden. Die Rollentabelle würde verschiedene Positionen enthalten - zB Regisseur, Produzent, Star, Statist, Griff, Redakteur... und es würde eher so aussehen:
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
Möglicherweise haben Sie auch ein role_details-Feld in der film_people-Tabelle, das je nach Rolle zusätzliche Informationen enthalten kann (z. B. den Namen der Rolle, die der Schauspieler spielt).
Ich zeige das Genre auch als viele<>viele Beziehung, weil es möglich ist, dass ein Film in mehreren Genres ist. Wenn Sie dies nicht möchten, enthalten Filme anstelle der Tabelle film_genre nur eine Genreid.
Sobald dies eingerichtet ist, ist es einfach, alles abzufragen und zu finden, was eine bestimmte Person getan hat, oder alles, was eine Person als Regisseur getan hat, oder alle, die jemals bei einem Film Regie geführt haben, oder alle Personen, die an einem bestimmten Film beteiligt waren. Es kann immer weiter gehen.
