3-я нормальная форма в порядке для баз данных?

Question

Должен ли я всегда стремиться к четвертой нормальной форме при проектировании баз данных?

Мне кажется, что третья нормальная форма ближе к моей бизнес-области.

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

Стоит ли вместо этого помещать идентификаторы автоинкрементов везде?Я не вижу смысла сразу, и это сильно усложняет код.

Answer 1

Как правило, цель вашей базы данных - как минимум в нормальной форме Бойса-Кодда или в идеале в пятой нормальной форме. Рассматривайте 3NF только в тех случаях, когда есть зависимости, которые важно сохранить, которые иначе не были бы удовлетворены 5NF.

4NF не имеет никакого отношения к тому, используете ли вы varchar или целые числа в своих ключах, и я не уверен, почему вы, кажется, думаете, что это так.

Answer 2

Требуется несколько недель, чтобы научиться нормализовать данные. Чтобы понять, когда игнорировать правила нормализации, требуются месяцы, может даже годы. Конечно, если вы игнорируете правила нормализации, будут последствия. Если вы тщательно изучите нормализацию, вы будете знать, что последствия есть.

Иногда последствия несоблюдения заданной нормальной формы незначительны по сравнению с преимуществом следования некоторому другому шаблону проектирования. Например, при создании базы данных OLAP или хранилища данных схема «звезда» или «снежинка» часто оказывается более продуктивной, чем полностью нормализованная.

Для баз данных OLTP я бы стремился к нормальной форме Бойса-Кодда и просто имел дело с любыми аномалиями модификации, которые появляются из-за отклонения от 4-й или 5-й нормальной формы. Но это действительно зависит от случая.

Answer 3

Пока ваш вопрос касается 4NF, ваша конкретная ситуация - нет. Использование поля VARCHAR в качестве первичного ключа не является неправильным , если оно относительно небольшое, я бы предпочел использовать это, а не суррогатный ключ.

Возвращаясь к 4NF - из примера Википедии , кажется, что это то, что в большинстве случаев просто естественным образом встало бы на свои места. Конечно, не может быть больно стремиться к 4NF - в то же время денормализация имеет свое место.

Answer 4

Вы разрешаете своим пользователям редактировать номера деталей? Если это так, это хороший аргумент против использования его в качестве первичного ключа. Как общее правило, PK не должны редактироваться пользователем, потому что репликация измененного PK через БД может стать довольно дорогой.

Кроме того, разве две части не должны иметь одинаковый номер или две активные части не могут иметь одинаковый номер? Если это последнее, вам нужно вести достаточно длинную историю, чтобы в итоге вы могли получить два одинаковых номера детали?

Answer 5

зависит от базы данных; используя поля varchar, поскольку ваш PK тратит пространство в хранилище БД и индексы в MySQL (например). Наличие таблицы и уникального целочисленного идентификатора для ваших номеров деталей может показаться менее чистым, но такие вещи иногда необходимы в условиях производительности.

(И, кроме того, он позволяет обновлять номер продукта, если это необходимо, в одном месте, хотя я подозреваю, что это вряд ли возможно в вашей бизнес-логике.)