属性とエンティティを区別する必要があります。実体は物であり、通常は名詞です。属性は、情報を説明する部分のようなものです。データベースの専門用語では、エンティティ=テーブル、属性=フィールド/列。
特定のもののために別のテーブルを持っているので、例として、ディレクターを使用してみましょう。これは正規化と呼ばれます。状況によっては良い場合もありますが、他の状況では不要な場合もあります（通常、クエリがより複雑になり、すべてを結合する必要があり、速度が低下します）。
この場合、年自体以外に保存する年に関する属性がないため、年テーブルを作成する必要はありません。これを非正規化し、年をフィルムテーブル自体に保存することをお勧めします。
一方、監督は違います。おそらく、監督の名、姓、生年月日、死亡日（該当する場合）などを保存する必要があります。この人物の映画を入力するたびに、監督の生年月日を入力したくないことは明らかです。指示するので、ディレクター用に別のエンティティを用意するのは理にかなっています。
ディレクターに関するこのすべての情報を保存したくない場合でも（名前だけが必要です）、別のテーブルを用意する（そして代理キーを使用する-すぐにわかります）ので便利です。活版印刷のエラーや重複を防ぎます-誰かの名前のつづりが間違っていたり、入力方法が異なっていたり（最初、最後と最後、最初）、その人が監督した他の映画を見つけようとすると失敗します。
テーブルに代理キー（主キー）を使用することは、一般的に良い考えです。整数の照合は、文字列の照合よりもはるかに高速です。また、他のテーブルに格納されている外部キーを気にすることなく、名前を自由に変更できます（IDは同じままなので、何もする必要はありません）。
あなたは本当にこのデザインをかなり遠くまで持って行くことができます、そしてそれはあなたがそれに何を保存できるようにしたいのかを理解することのすべての問題です。
たとえば、映画ごとに1人の監督がいるのではなく、複数の監督がいる映画もあります。したがって、映画と監督の間には多対多の関係があるため、次のようなテーブルが必要になります。
films_directors => **filmid, directorid**
さらに一歩進んで、時には監督が俳優でもあり、その逆もあります。したがって、ディレクターとアクターのテーブルを作成するのではなく、1人のテーブルを作成し、そのテーブルを結合してロールテーブルを使用することができます。役割テーブルは、さまざまな役職を保持します。たとえば、監督、プロデューサー、スター、エクストラ、グリップ、編集者などです。次のようになります。
films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**
また、film_peopleテーブルにrole_detailsフィールドがある場合があります。このフィールドには、役割に応じて追加情報が含まれる場合があります（たとえば、俳優が演じているパートの名前）。
また、映画には複数のジャンルがある可能性があるため、ジャンルを多くの<>多くの関係として示しています。これが必要ない場合は、film_genreテーブルの代わりに、フィルムにgenreidが含まれるだけです。
これを設定すると、特定の人物が行ったすべてのこと、またはある人物が監督として行ったすべてのこと、映画を監督したことのあるすべての人、または1つの特定の映画に関係するすべての人を簡単に照会して見つけることができます。それは何度も続くことができます。