Какую нормальную форму гарантирует диаграмма ER?

Всякий раз, когда для базы данных рисуется правильная диаграмма ER, а затем сопоставляется с реляционной схемой, мне сообщают, что она гарантирует 3NF,

Это утверждение верно?

Если нет, может кто-нибудь привести мне контрпример.

Также, скажите, пожалуйста, можно ли строго соблюдать любую нормальную форму, когда реляционная схема отображается на идеальной диаграмме ER?

Источник

3 ответа

Решение

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

Терри Хэлпин разработал формальный метод проектирования базы данных, который гарантирует реляционную схему, удовлетворяющую 5-й нормальной форме (см. Orm.net). Он использует подход Object Role Modeling, а не ER моделирование.

Источник

Диаграмма просто показывает, какие сущности и атрибуты у вас есть и как сущности связаны друг с другом. Ваши атрибуты могут нарушать нормальные формы. Диаграмма ER - это просто представление, она не применяет никаких правил.

Нет ничего о представлении модели на диаграмме ER, которая подразумевает удовлетворение 3NF.

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

Источник

Давайте посмотрим пример (в оракуле):

CREATE TABLE STUDENT (
  ID INTEGER PRIMARY KEY,
  NAME VARCHAR2(64) NOT NULL,
  RESIDENCE_STREET VARCHAR2(64),
  RESIDENCE_CITY VARCHAR2(64),
  RESIDENCE_PROVINCE VARCHAR2(64),
  RESIDENCE_POSTALCODE NUMBER(8)
);

В некоторых странах почтовый код использует префиксы для определения региона или провинции, поэтому RESIDENCE_PROVINCE имеет функциональную зависимость от RESIDENCE_POSTALCODE. Но RESIDENCE_POSTALCODE является непростым атрибутом. Тогда этот простой и распространенный пример является "легальным", и его нет в 3NF.

Источник
Другие вопросы по тегам