Musisz odróżnić atrybuty od bytów. Byt to rzecz – zwykle rzeczownik. Atrybut bardziej przypomina opis informacji. W żargonie bazy danych encja =tabela, atrybut =pole/kolumna.
Posiadanie osobnej tabeli dla pewnych rzeczy, użyjmy jako przykładu reżysera, nazywa się normalizacją. Choć w niektórych okolicznościach może być dobry, w innych może być niepotrzebny (ponieważ generalnie komplikuje zapytania - musisz wszystko połączyć - i jest wolniejszy).
W takim przypadku posiadanie tabeli roku jest niepotrzebne, ponieważ nie ma innych atrybutów dotyczących roku, poza samym rokiem, które można by przechowywać. Lepiej to zdenormalizować i przechowywać rok w samej tabeli filmów.
Z drugiej strony reżyser jest inny. Być może zechcesz zapisać imię reżysera, nazwisko, datę urodzenia, datę śmierci (jeśli dotyczy) itp. Oczywiście nie chcesz wpisywać daty urodzenia reżysera za każdym razem, gdy wprowadzasz film, w którym ta osoba kieruje, więc warto mieć osobny podmiot dla dyrektora.
Nawet jeśli nie chciałeś przechowywać wszystkich tych informacji o dyrektorze (chcesz tylko jego nazwisko), posiadanie dla niej osobnej tabeli (i użycie klucza zastępczego - do tego dojdę za sekundę) jest przydatne, ponieważ zapobiega błędom typograficznym i duplikatom - jeśli czyjeś nazwisko zostało napisane błędnie lub wpisane inaczej (pierwszy, ostatni vs ostatni, pierwszy), to jeśli spróbujesz znaleźć inne filmy, które wyreżyserował, nie powiedzie się.
Używanie klucza zastępczego (klucza podstawowego) dla tabel jest ogólnie dobrym pomysłem. Dopasowanie liczby całkowitej jest znacznie szybsze niż dopasowanie ciągu. Pozwala także dowolnie zmieniać nazwę, bez obaw o klucze obce przechowywane w innych tabelach (identyfikator pozostaje taki sam, więc nie musisz nic robić).
Naprawdę możesz posunąć ten projekt dość daleko i wszystko jest kwestią ustalenia, co chcesz w nim przechowywać.
Na przykład, zamiast mieć jednego reżysera w jednym filmie, niektóre filmy mają wielu reżyserów... więc istniałaby relacja „wielu do wielu” między filmami a reżyserami, więc potrzebna byłaby tabela z np.:
films_directors => **filmid, directorid**
Idąc krok dalej, czasami reżyserzy są także aktorami i vice versa. Więc zamiast mieć nawet stoły reżysera i aktora, możesz mieć stół dla jednej osoby i dołączyć do niego, używając tabeli ról. Tabela ról miałaby różne stanowiska - np. reżysera, producenta, gwiazdy, statysty, chwytu, montażysty... i wyglądałby bardziej następująco:
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
Możesz również mieć pole role_details w tabeli film_people, które może zawierać dodatkowe informacje w zależności od roli (np. nazwę roli, którą gra aktor).
Pokazuję też związek gatunkowy jako wiele<>wielu, ponieważ możliwe, że film jest w wielu gatunkach. Gdybyś tego nie chciał, zamiast tabeli film_genre, filmy zawierałyby po prostu identyfikator gatunku.
Po skonfigurowaniu łatwo jest zapytać i znaleźć wszystko, co zrobiła dana osoba, lub wszystko, co dana osoba zrobiła jako reżyser, lub każdy, kto kiedykolwiek wyreżyserował film, lub wszystkie osoby zaangażowane w jeden konkretny film. To może trwać i trwać.
