Du skal skelne mellem attributter og entiteter. En enhed er en ting - normalt et substantiv. En egenskab er mere som et stykke beskrivende information. I databasejargon er entitet =tabel, attribut =felt/kolonne.
At have en separat tabel for visse ting, lad os bruge direktør, som et eksempel, kaldes normalisering. Selvom det kan være godt under nogle omstændigheder, kan det være unødvendigt i andre (da det generelt gør forespørgsler mere komplicerede - du skal deltage i alt - og det er langsommere).
I dette tilfælde er det unødvendigt at have en årstabel, da der ikke er andre attributter omkring et år, udover selve året, som du vil gemme. Det er bedre at denormalisere dette og gemme året i selve filmbordet.
Direktør er derimod anderledes. Måske vil du gemme instruktørens fornavn, efternavn, fødselsdato, dødsdato (hvis relevant) osv. Du ønsker naturligvis ikke at indtaste instruktørens fødselsdato, hver gang du går ind i en film, som denne person leder, så det giver mening at have en separat enhed for en direktør.
Selvom du ikke ønskede at gemme alle disse oplysninger om instruktøren (du vil bare have deres navn), er det nyttigt at have en separat tabel til det (og bruge en surrogatnøgle - jeg kommer til det om et sekund), fordi det forhindrer typografiske fejl og dubletter - hvis du har en persons navn stavet forkert eller indtastet anderledes (første, sidste vs sidste, første), så hvis du prøver at finde andre film, de har instrueret, vil du mislykkes.
Det er generelt en god idé at bruge en surrogatnøgle (primær nøgle) til tabeller. At matche et heltal er meget hurtigere end at matche en streng. Det giver dig også mulighed for frit at ændre navnet uden at bekymre dig om de fremmednøgler, der er gemt i andre tabeller (ID'et forbliver det samme, så du behøver ikke at gøre noget).
Du kan virkelig tage dette design ret langt, og det hele handler om at finde ud af, hvad du vil kunne opbevare i det.
For eksempel, i stedet for at have en enkelt instruktør pr. film, har nogle film flere instruktører.. så der ville være et mange-til-mange forhold mellem film og instruktører, så du skal bruge en tabel med f.eks.:
films_directors => **filmid, directorid**
Tager man det et skridt videre, er instruktører nogle gange også skuespillere og omvendt. Så i stedet for endda at have instruktør- og skuespillerborde, kunne du have et enkeltpersonsbord og slutte dig til det bord ved at bruge et rollebord. Rollebordet ville besidde forskellige stillinger - f.eks. instruktør, producer, stjerne, statist, greb, redaktør... og det ville mere ligne:
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
Du kan også have et rolle_detaljer-felt i tabellen film_mennesker, som kan indeholde ekstra information afhængigt af rollen (f.eks. navnet på den rolle, skuespilleren spiller).
Jeg viser også genre som et mange<>mange forhold, fordi en film muligvis er i flere genrer. Hvis du ikke ønskede dette, ville film i stedet for tabellen film_genre blot indeholde en genreid.
Når først dette er sat op, er det nemt at forespørge og finde alt, hvad en given person har gjort, eller alt, hvad en person har gjort som instruktør, eller alle, der nogensinde har instrueret en film, eller alle de personer, der er involveret i en bestemt film. Det kan blive ved og ved.