1

Я ищу конкретный пример отношения с составным первичным ключом. Основываясь на своих функциональных зависимостях, я знаю, что это в 1NF. При нормализации его до 3NF я столкнулся с ситуацией, с которой я еще не сталкивался. Я выполнил шаги для всех частичных зависимостей и транзитивных зависимостей, но последний шаг нормализации к 3NF требует создания отношения, содержащего первичный ключ и все непервичные атрибуты, зависящие от него.Нормализация Теория Необходимое объяснение

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

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

+0

В заметках класса, однако я мог бы неправильно истолковать что-то, поскольку я просто изучаю большую часть этого материала. – Gary

+0

Возможный дубликат [Нормальные формы - 2-й и 3-й - это различие только составных клавиш? нетривиальная зависимость?] (http://stackoverflow.com/questions/27474203/normal-forms-2nd-vs-3rd-is-the-difference-just-composite-keys-non-trivial-d) – philipxy

+0

Понял. Я свободно говорю о них. Я знаю разницу между первичными и составными ключами – Gary

ответ

1

Совершенно законно иметь отношение, состоящее из составного ключа и других атрибутов. Это не только теоретически справедливо, но и происходит в реальном мире.

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

+0

Спасибо !!! Это гораздо более ясное решение. Я очень ценю это – Gary

+0

Я забыл упомянуть о другом использовании для такого отношения. Он может использоваться как среднее отношение в трех направлениях. –

1

FDs (функциональные зависимости) не имеют ничего общего с 1NF, независимо от того, какое из значений для «1NF» вы используете. Так что непонятно, что вы пытаетесь сказать о 1NF. Отношение по определению имеет значение для каждого атрибута каждого кортежа. Вещь как отношение с чем-то как «список значений» для некоторой части как атрибут некоторой части как кортеж не является отношением так CKS (ключи кандидатов) & ФД не применяются. Если вы определяете отношение «1NF» как одно без определенных типов данных (because of some fuzzy application-dependent received wisdom about "atomicity", or in Codd's sense of having no relation-valued attributes), то удовлетворение не зависит от того, сохраняются ли FD в дизайне с этим типом данных. (Более того, если «нормализованная» «атомарная» -записанная версия такой «не-1NF» «неатомной» -списанной конструкции удовлетворяет FD, то оригинал имеет определенное ограничение , но это не ограничение FD .)

FD, которые не являются частичными, заполнены. Единственными частичными FD, которые имеют значение на пути к 2NF & 3NF, являются частичные FDs атрибутов non-prime для CK. Когда они ушли, у вас есть 2NF. (От «следуют шаги для всех частичных зависимостей и транзитивных зависимостей», похоже, ваш план состоит в том, чтобы разложить на 2NF, а затем на 3NF.) Частичные зависимости просто не упоминаются в определении 3NF, для которого требуется 2NF. Кроме того, определения для 3NF и общий алгоритм для установки отношения в 3NF просто не используют частичные зависимости.

Также могут быть и другие частичные FD. Они просто не имеют значения. В частности, все ФД атрибутов на правильных суперклассах являются частичными. Просто следуйте определениям, чтобы определить, какая нормальная форма (ы) есть отношение, и следуйте алгоритмам для установления отношения в нормальную форму. Это касается всех определений и алгоритмов. There is no point in worrying about every property you notice that it might be "bad".

PS Вы не должны устанавливать связь в 3NF, сначала помещая его в 2NF. Это может исключить некоторые хорошие 3NF-разложения оригинала из найденных. Используйте алгоритм для 3NF. (Обычный для 3NF фактически генерирует разложения в немного более сильном EKNF (Обычная форма элементарного ключа)).

+0

Я не согласен. Если в таблице есть значение, которое НЕ функционально зависит от ключа, таблица не находится в 1NF. Это трудно сделать, в реальной жизни. Тем не менее, существует множество дизайнеров, столкнувшихся с ситуацией, когда первичный ключ таблицы определяет не одно значение, а список значений. Например, если ключ - studentId, а список - это список курсов, на которые студент зарегистрирован. Некоторые люди хотят поместить список курсов в один столбец с значениями, разделенными запятой. Это на самом деле является нарушением 1NF, хотя это выглядит не так. –

+0

«FD» - технический термин, и вы злоупотребляете (т. Е. Не используете) его, когда говорите «определяет список значений». Отношение по определению имеет значение для каждого атрибута каждого кортежа. Вещь с «списком значений» для некоторой вещи, подобной атрибуту некоторой вещи, такой как кортеж, не является отношением, поэтому CKs & FDs не применяются. Если вы определяете «отношение 1NF» как отношение без определенных типов данных из-за некоторой нечеткой полученной мудрости о «атомарности», удовлетворенность не зависит от того, придерживаются ли FD в дизайне с этим типом данных. (Пожалуйста, определите «1NF».) (См. Мой отредактированный ответ.) – philipxy

+0

PS The CKs * являются следствием FD *. Каждое отношение имеет CK. «Значение в таблице, которая НЕ функционально зависит от ключа», не может произойти. В любом случае «ключ» есть что-то в * отношении *, как и FK. У вас может быть дизайн, который не является отношением, поэтому (по любому определению, которое вы выбираете для «1NF») это не «отношение 1NF», но тогда это были не CKs & FDs, которые являются проблемой, потому что CKs & FDs являются в * отношениях *. У вас могут быть вещи *, как * CK или FD в виду, включая вещи * как * отношения (но не). Это не отношения, CK или FD. – philipxy

Смежные вопросы