Пусть есть три множества A, B \subset A, C \subset A. Пересечение B и C мало или пустое множество. Если есть несовпадающие атрибуты в B и C, отсутствующие в A, то необходимо три отношения: A, B, C. То есть 3 отдельные таблицы УчастникиФильма, Актёры, Режиссёры - лучший вариант.

Триггерман, я описал общепринятый подход. Если Вы сохраните одну таблицу, то у Вас будет огромное количество null-значений, больше, чем данных. Такой подход применяют только для большого числа сильно пересекающихся множеств. Актёры и режиссёры - это, очевидно, не тот случай.

Триггерман
Вот в этой таблице будет огромное количество null-значений ???
Таблица_Участник_Фильма ( id_Film, id_Person, id_Position )

(id_Position это типа "актёр", "режиссер", "оператор", "сценарист", ... )

Здесь не будет ни одной строки, в которой встретится null.


Разумеется, нет. Уже в двух постах написал, что имею в виду. У Вас есть таблица Таблица_Человек. В ней атрибуты A1, ..., AM - общие у актёра и режиссёра. B1, ..., BN - атрибуты, которые есть у актёра, но нет у режиссёра. C1, ..., CK - атрибуты, которые есть у режиссёра, но нет у актёра. Например, A1 - это фамилия, A2 - имя, B1 - роль актёра в фильме (этого атрибута нет у режиссёров).

Для одной таблицы: (ID, A1, ..., AM, B1, ..., BN, C1, ..., CK). Для режиссёра будет (ID, A1, ..., AM, null, ..., null, C1, ..., CK). Для актёра будет (ID, A1, ..., AM, B1, ..., BN, null, ..., null). Для этой ситуации, в которой есть атрибуты B1, ..., BN и C1, ..., CK, разбиение одной Вашей таблицы Таблица_Человек на три Таблица_Человек, Таблица_Актёр, Таблица_Режиссёр целесообразно. Если таких атрибутов нет (только Name), то нецелесообразно. Что я и написал уже в первом посте.