Você tem que fazer uma distinção entre atributos e entidades. Uma entidade é uma coisa - geralmente um substantivo. Um atributo é mais como um pedaço de informação descritiva. No jargão de banco de dados, entidade =tabela, atributo =campo/coluna.
Tendo uma tabela separada para certas coisas, vamos usar o director, como exemplo, é chamado de normalização. Embora possa ser bom em algumas circunstâncias, pode ser desnecessário em outras (pois geralmente torna as consultas mais complicadas - você tem que juntar tudo - e é mais lento).
Nesse caso, ter uma tabela de ano é desnecessário, pois não há outros atributos sobre um ano, além do próprio ano, que você armazenaria. É melhor desnormalizar isso e armazenar o ano na própria tabela de filmes.
O diretor, por outro lado, é diferente. Talvez você queira armazenar o nome e sobrenome do diretor, data de nascimento, data de falecimento (se aplicável), etc. dirige, por isso faz sentido ter uma entidade separada para um diretor.
Mesmo que você não queira armazenar todas essas informações sobre o diretor (você só quer o nome dele), ter uma tabela separada para isso (e usar uma chave substituta - chegarei a isso em um segundo) é útil porque evita erros tipográficos e duplicatas - se você tiver o nome de alguém escrito errado ou digitado de forma diferente (primeiro, último vs último, primeiro), então, se você tentar encontrar outros filmes que eles dirigiram, você falhará.
Usar uma chave substituta (chave primária) para tabelas geralmente é uma boa ideia. A correspondência de um inteiro é muito mais rápida do que a correspondência de uma string. Ele também permite que você altere o nome livremente, sem se preocupar com as chaves estrangeiras armazenadas em outras tabelas (o ID permanece o mesmo, então você não precisa fazer nada).
Você pode realmente levar esse design bem longe, e é tudo uma questão de descobrir o que você deseja armazenar nele.
Por exemplo, em vez de ter um único diretor por filme, alguns filmes têm vários diretores... então haveria uma relação muitos-para-muitos entre filmes e diretores, então você precisaria de uma tabela com, por exemplo:
films_directors => **filmid, directorid**
Dando um passo adiante, às vezes os diretores também são atores e vice-versa. Então, em vez de ter tabelas de diretores e atores, você pode ter uma tabela de uma única pessoa e unir essa tabela usando uma tabela de funções. A tabela de funções teria várias posições - por exemplo, diretor, produtor, estrela, figurante, pega, editor... e ficaria mais parecida com:
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
Você também pode ter um campo role_details na tabela film_people, que pode conter informações extras dependendo do papel (por exemplo, o nome do papel que o ator está interpretando).
Também estou mostrando o gênero como uma relação de muitos<>muitos, porque é possível que um filme esteja em vários gêneros. Se você não quisesse isso, em vez da tabela film_genre, os filmes conteriam apenas um genericid.
Uma vez configurado, é fácil consultar e encontrar tudo o que uma determinada pessoa fez, ou tudo que uma pessoa fez como diretor, ou todos que já dirigiram um filme, ou todas as pessoas envolvidas com um filme específico. Pode continuar e continuar.
