Du måste göra en skillnad mellan attribut och enheter. En entitet är en sak - vanligtvis ett substantiv. Ett attribut är mer som en del av beskrivande information. I databasjargong, entitet =tabell, attribut =fält/kolumn.
Att ha en separat tabell för vissa saker, låt oss använda direktör, som ett exempel, kallas normalisering. Även om det kan vara bra under vissa omständigheter, kan det vara onödigt i andra (eftersom det i allmänhet gör frågor mer komplicerade - du måste gå med i allt - och det är långsammare).
I det här fallet är det onödigt att ha en årstabell, eftersom det inte finns några andra attribut om ett år, förutom själva året, som du skulle lagra. Det är bättre att avnormalisera detta och lagra årtalet i själva filmbordet.
Regissör, å andra sidan, är annorlunda. Du kanske vill lagra regissörens förnamn, efternamn, födelsedatum, dödsdatum (om tillämpligt), etc. Du vill uppenbarligen inte ange regissörens födelsedatum varje gång du går in i en film som den här personen leder, så det är vettigt att ha en separat enhet för en styrelse.
Även om du inte vill lagra all denna information om regissören (du vill bara ha deras namn), är det användbart att ha en separat tabell för det (och använda en surrogatnyckel - jag kommer till det om en sekund) eftersom det förhindrar typografiska fel och dubbletter - om du har någons namn felstavat eller angett på ett annat sätt (först, sist vs sist, först), så kommer du att misslyckas om du försöker hitta andra filmer de har regisserat.
Att använda en surrogatnyckel (primärnyckel) för tabeller är generellt sett en bra idé. Att matcha ett heltal är mycket snabbare än att matcha en sträng. Det låter dig också fritt byta namn, utan att oroa dig för främmande nycklar som lagras i andra tabeller (ID:t förblir detsamma, så du behöver inte göra någonting).
Du kan verkligen ta den här designen ganska långt, och allt handlar om att komma på vad du vill kunna lagra i den.
Till exempel, snarare än att ha en enskild regissör per film, har vissa filmer flera regissörer... så det skulle finnas ett många-till-många-förhållande mellan filmer och regissörer, så du skulle behöva en tabell med t.ex.:
films_directors => **filmid, directorid**
För att ta det ett steg längre, ibland är regissörer också skådespelare, och vice versa. Så istället för att ens ha regissörs- och skådespelarebord, kan du ha ett bord för en person och gå med i det bordet och använda ett rollbord. Rollbordet skulle ha olika positioner - t.ex. regissör, producent, stjärna, statist, grepp, redaktör... och det skulle se ut mer som:
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 också ha ett role_details-fält i filmen_people-tabellen, som kan innehålla extra information beroende på rollen (t.ex. namnet på rollen som skådespelaren spelar).
Jag visar också genre som ett många<>många förhållande, eftersom en film är möjlig i flera genrer. Om du inte ville ha det här, istället för tabellen film_genre, skulle filmer bara innehålla en genreid.
När detta väl har ställts in är det lätt att fråga och hitta allt en viss person har gjort, eller allt en person har gjort som regissör, eller alla som någonsin har regisserat en film, eller alla personer som är involverade i en specifik film. Det kan fortsätta och fortsätta.