Je moet onderscheid maken tussen attributen en entiteiten. Een entiteit is een ding - meestal een zelfstandig naamwoord. Een attribuut is meer een stuk beschrijvende informatie. In databasejargon, entiteit =tabel, attribuut =veld/kolom.
Het hebben van een aparte tabel voor bepaalde dingen, laten we director gebruiken, als voorbeeld, wordt normaliseren genoemd. Hoewel het in sommige omstandigheden goed kan zijn, kan het in andere niet nodig zijn (omdat het over het algemeen vragen ingewikkelder maakt - je moet alles samenvoegen - en het is langzamer).
In dit geval is het hebben van een jaartabel niet nodig, aangezien er geen andere attributen over een jaar zijn, behalve het jaar zelf, die u zou opslaan. Het is beter om dit te denormaliseren en het jaartal op te slaan in de filmtabel zelf.
Regisseur daarentegen is anders. Misschien wilt u de voornaam, achternaam, geboortedatum, overlijdensdatum (indien van toepassing) enz. van de regisseur opslaan. U wilt natuurlijk niet de geboortedatum van de regisseur invoeren telkens wanneer u een film invoert die deze persoon regisseert, dus is het logisch om een aparte entiteit voor een bestuurder te hebben.
Zelfs als je niet al deze informatie over de regisseur wilt opslaan (je wilt gewoon hun naam), is het handig om er een aparte tabel voor te hebben (en een surrogaatsleutel te gebruiken - daar kom ik zo op terug) omdat het voorkomt typografische fouten en duplicaten - als je iemands naam verkeerd hebt gespeld of anders hebt ingevoerd (eerste, laatste versus laatste, eerste), dan zal je falen als je andere films probeert te vinden die ze hebben geregisseerd.
Het gebruik van een surrogaatsleutel (primaire sleutel) voor tabellen is over het algemeen een goed idee. Het matchen van een geheel getal is veel sneller dan het matchen van een string. Het stelt je ook in staat om de naam vrij te wijzigen, zonder je zorgen te maken over de externe sleutels die in andere tabellen zijn opgeslagen (de ID blijft hetzelfde, dus je hoeft niets te doen).
Je kunt met dit ontwerp echt heel ver gaan, en het is allemaal een kwestie van uitzoeken wat je erin wilt kunnen opslaan.
In plaats van bijvoorbeeld één regisseur per film te hebben, hebben sommige films meerdere regisseurs. Er zou dus een veel-op-veel-relatie zijn tussen films en regisseurs, dus je hebt een tabel nodig met bijvoorbeeld:
films_directors => **filmid, directorid**
Als we nog een stap verder gaan, zijn regisseurs soms ook acteurs en omgekeerd. Dus in plaats van zelfs regisseurs- en acteurstafels te hebben, zou je een tafel voor één persoon kunnen hebben en aan die tafel kunnen deelnemen door een rollentabel te gebruiken. De rollentafel zou verschillende posities innemen - bijvoorbeeld regisseur, producer, ster, figurant, grip, editor... en het zou er meer uitzien als:
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
Mogelijk hebt u ook een veld role_details in de tabel film_people, dat extra informatie kan bevatten, afhankelijk van de rol (bijv. de naam van de rol die de acteur speelt).
Ik laat genre ook zien als een veel<>veel-relatie, omdat een film mogelijk in meerdere genres zit. Als je dit niet wilde, dan zouden films in plaats van de film_genre-tabel gewoon een genre-id bevatten.
Als dit eenmaal is ingesteld, is het gemakkelijk om alles op te zoeken en te vinden wat een bepaalde persoon heeft gedaan, of alles wat iemand heeft gedaan als regisseur, of iedereen die ooit een film heeft geregisseerd, of alle mensen die bij één specifieke film betrokken zijn. Het kan maar doorgaan.