Проверьте BCNF в базе данных фильмов?

Question

Я немного смущен, как проверить BCNF в диаграмме базы данных. Я видел несколько видеороликов YouTube о том, что такое нормализация базы данных (1NF, 2NF ...), но когда придет время применить эти правила к моему проекту, я знаю, что делать.

My ER diagram for a movie database

диаграмма ER для Postgre SQL код:

CREATE TABLE People ( 
    birth_date DATE NOT NULL, 
    last_name CHAR(30) NOT NULL, 
    name CHAR(30) NOT NULL, 
    person_id INTEGER NOT NULL, 
PRIMARY KEY (person_id)); 

CREATE TABLE Roles ( 
    role_id INTEGER NOT NULL, 
    role_name CHAR(30) NOT NULL, 
PRIMARY KEY (role_id)); 

CREATE TABLE genre ( 
    genre_id INTEGER NOT NULL, 
    genre_name INTEGER NOT NULL, 
PRIMARY KEY (genre_id)); 

CREATE TABLE Movies ( 
    movie_id INTEGER NOT NULL, 
    title CHAR(30) NOT NULL, 
    rating REAL NOT NULL, 
    release_date DATE NOT NULL, 
PRIMARY KEY (movie_id)); 

CREATE TABLE film_people ( 
    role_id INTEGER NOT NULL, 
    person_id INTEGER NOT NULL, 
    movie_id INTEGER NOT NULL, 
    FK1_movie_id INTEGER NOT NULL, 
    FK2_person_id INTEGER NOT NULL, 
    FK3_role_id INTEGER NOT NULL, 
PRIMARY KEY (FK1_movie_id, FK2_person_id, FK3_role_id), 
UNIQUE (role_id), 
UNIQUE (person_id), 
UNIQUE (movie_id)); 

CREATE TABLE film_genre ( 
    movie_id INTEGER NOT NULL, 
    genre_id INTEGER NOT NULL, 
    FK1_movie_id INTEGER NOT NULL, 
    FK2_genre_id INTEGER NOT NULL, 
PRIMARY KEY (FK1_movie_id, FK2_genre_id), 
UNIQUE (movie_id), 
UNIQUE (genre_id)); 

ALTER TABLE film_people ADD FOREIGN KEY (FK1_movie_id) REFERENCES Movies (movie_id) ON DELETE CASCADE ON UPDATE CASCADE; 

ALTER TABLE film_people ADD FOREIGN KEY (FK2_person_id) REFERENCES People (person_id) ON DELETE CASCADE ON UPDATE CASCADE; 

ALTER TABLE film_people ADD FOREIGN KEY (FK3_role_id) REFERENCES Roles (role_id) ON DELETE CASCADE ON UPDATE CASCADE; 

ALTER TABLE film_genre ADD FOREIGN KEY (FK1_movie_id) REFERENCES Movies (movie_id) ON DELETE CASCADE ON UPDATE CASCADE; 

ALTER TABLE film_genre ADD FOREIGN KEY (FK2_genre_id) REFERENCES genre (genre_id) ON DELETE CASCADE ON UPDATE CASCADE; 

Основной источник для проектирования баз данных фильма: How to design a movie database?

Итак, на данной диаграмме ER, моя цель состоит в том, чтобы найти функциональные зависимости и применять нормализацию BCNF.

Любая помощь приветствуется!

Answer 1

Модель Entity-Relationship скорее концептуальная модель, чем логическая модель. Он добавляет семантику, которая делает ее более знакомой людям, не обученным в формальной логике, ограничивая ее подмножеством реляционной модели и создавая разумно нормированные отношения. Обычно мы не имеем дело с нормализацией на уровне ER - сущности и отношения разрабатываются только с одним основным ключом, а все остальное зависит от этих ключей, нет никаких обозначений для обозначения альтернативных ключей-кандидатов или частичных или транзитивных функциональных зависимостей. Кроме того, дополнительная семантика ER является препятствием при нормализации - логического значения при попытке сохранить разницу между наборами сущностей и наборами значений или между отношениями сущностей и отношениями отношений нет.

Нормализация лучше проверяется и применяется после преобразования вашей модели ER в реляционную модель. Под этим я подразумеваю преобразование каждого объекта и каждого отношения в отдельное отношение и перечисление их функциональных зависимостей и ключей-кандидатов. Они могут быть в основном получены непосредственно из модели ER, но следите за скрытыми естественными ключами (особенно когда вы использовали суррогатный ключ), ищите зависимости между не-ключевыми атрибутами (особенно, если вы использовали композитные атрибуты EER) и следите для нарушений 4NF из многозначных зависимостей, если вы использовали многозначные атрибуты EER.

Вы можете нарисовать реляционные диаграммы, которые состоят из окна для каждого столбца и стрелки между полями для указания зависимостей. Я предпочитаю просто вводить текст в тексте, например.

genre: genre_id -> genre_name 
movies: movie_id -> title, release_date, rating 
film_genre: movie_id, genre_id ->() 

Пустые круглые скобки в последней строке должны указывать, что в этом отношении нет неключевых атрибутов. Важно попытаться идентифицировать ВСЕ ключи-кандидаты и зависимости, которые хранятся для нормализации правильно, не просто предполагайте, что модель ER верна или завершена. После того, как вы перечислите все ваши кандидатные ключи и функциональные зависимости, вы можете работать с обычными формами, чтобы проверить их.

BTW, ваши отношения отношений не реализованы правильно в вашей физической модели/SQL. Они должны быть:

CREATE TABLE film_people ( 
    role_id INTEGER NOT NULL, 
    person_id INTEGER NOT NULL, 
    movie_id INTEGER NOT NULL, 
    PRIMARY KEY (movie_id, person_id, role_id), 
    FOREIGN KEY (movie_id) REFERENCES Movies (movie_id) ON DELETE CASCADE ON UPDATE CASCADE, 
    FOREIGN KEY (person_id) REFERENCES People (person_id) ON DELETE CASCADE ON UPDATE CASCADE, 
    FOREIGN KEY (role_id) REFERENCES Roles (role_id) ON DELETE CASCADE ON UPDATE CASCADE 
); 

CREATE TABLE film_genre ( 
    movie_id INTEGER NOT NULL, 
    genre_id INTEGER NOT NULL, 
    PRIMARY KEY (movie_id, genre_id), 
    FOREIGN KEY (movie_id) REFERENCES Movies (movie_id) ON DELETE CASCADE ON UPDATE CASCADE, 
    FOREIGN KEY (genre_id) REFERENCES genre (genre_id) ON DELETE CASCADE ON UPDATE CASCADE 
); 

Я удалил дублированные столбцы, например. movie_id и FK1_movie_id. Возможно, они были созданы из-за включения ключевых атрибутов в ваши отношения на диаграмме ER? Обычно мы понимаем, что ключ отношения сочетается с ключами сущностей, которые участвуют в отношениях, поэтому мы не укажем его на диаграмме.

Я также удалил уникальные ограничения для каждого из столбцов. Подумайте об этом - есть ли в каждом фильме только одна роль? Может ли каждый человек играть только одну роль в своей жизни?Можно ли выполнять каждую роль только один раз? Каждый фильм принадлежит только одному жанру? Есть ли в каждом жанре только один фильм? Эти ограничения не имели смысла.

Кроме того, на вашей диаграмме индикаторы мощности (0,N) не имеют смысла. 0 обычно указывает дополнительные компоненты связи. Можно ли записать экземпляр film_genre без movie_id и/или genre_id? Нет, для каждого экземпляра отношения требуются оба объекта. Обычно ассоциации ER считаются безусловными, если не указано, поэтому единственная мощность, которую я когда-либо указывал, равна 1, когда объект в зависимой связи зависит, а не является частью ключа. Для дополнительных ассоциаций я использую пунктирные линии.

Обратно к вопросу о связи film_people, здесь может быть нарушение BCNF в зависимости от того, как вы интерпретируете ситуацию. Существуют ли скрытые перекрывающиеся ключи кандидата? Например, оба являются (movie_id, person_id) и (movie_id, role_id) уникальными? Другими словами, может ли человек играть только одну роль в фильме, и может ли только один человек играть каждую роль в фильме? Подумайте об (movie_id, role_id) и (role_id, person_id) таким же образом.

Наконец, также подумайте о своих ON DELETE CASCADE статьях. Если вы удалите человека, он также удалит связанные роли из фильмов. Если вы удалите роль, она удалит связь человека с фильмом. Это верно?