У меня есть отношение, состоящее из следующих атрибутов:

Employee: Emp_Id(Primary Key), Name, E_mail, Phone_Number, Date_Of_Joining, Address

Я предполагаю, что у двух людей могут быть одинаковые Name или Address, но не одинаковые идентификаторы E_mail или Phone_Number (< em> т.е. они должны быть уникальными ).

Итак, согласно тому, что я знаю, чтобы нормализовать таблицу; Мне нужно разделить информацию E-mail и Phone_Number в отдельную таблицу (для 3NF):

Из 3NF:

Третья нормальная форма (3NF) - это нормальная форма, используемая при нормализации базы данных. 3NF был первоначально определен Э. Ф. Коддом в 1971 г. [2] Определение Кодда гласит, что таблица находится в 3НФ тогда и только тогда, когда выполняются оба следующих условия:

  • Отношение R (таблица) находится во второй нормальной форме (2NF)
  • Каждый непростой Атрибут R нетранзитивно зависит от каждого ключа R.

Итак, я делю основную таблицу на эти результирующие таблицы:

E_Mail Information: E_Mail_Id(Primary Key), E_Mail Address, ...

Contact/Phone Number Information: Phone_Id(Primary Key), Phone_Number, ...

(Новое) Employee: Emp_Id(Primary Key), Name, E_mail_Id(foreign key), Phone_Number_Id(foreign key), Date_Of_Joining, Address

Мои вопросы

  1. Не разделяя отношения, как указано выше, для достижения 3NF, могли бы мы просто оставить Employee как есть, не столкнувшись с проблемами ( этот вопрос является только конкретным к примеру, который я описал выше )?

  2. Даже после разделения таблицы у нас могут быть значения, которые, несмотря на то, что они являются внешними ключами, уникальны (из-за взаимно-однозначного отношения) и, следовательно, могут рассматриваться как ключи-кандидаты в (Новом) отношении Employee, которые являются E_mail_Id и Phone_Number_Id. Так не нарушат ли они 3НФ?

0
Zaid Khan 1 Ноя 2018 в 18:55

1 ответ

Лучший ответ

Повторяя свои предположения

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

У вас есть схема отношения:

Employee : Emp_Id, Name, E_mail, Phone_Number, Date_Of_Joining, Address

И для целей этого вопроса вы указываете, что:

  1. У каждого сотрудника есть один уникальный адрес электронной почты.
  2. У каждого сотрудника есть уникальный номер телефона.

Таким образом, у вас есть три основных атрибута (в обозначениях Кодда) или три ключа-кандидата для этой схемы:

  1. Emp_Id
  2. E_mail
  3. Phone_number

Учитывая идентификатор сотрудника, сотрудник определяется однозначно; по номеру телефона однозначно определяется сотрудник; учитывая адрес электронной почты, сотрудник определяется однозначно.

Схема ваших отношений находится в 3NF

Если то, что указано выше, является правильной интерпретацией схемы отношения, то ваше замечание о том, что «мне нужно разделить информацию E-mail и Phone_Number в отдельную таблицу (для 3NF)» неверно. Нет необходимости их разделять.

При указанных условиях ваша схема отношений уже находится в 3NF; действительно, он также находится в BCNF (нормальной форме Бойса-Кодда). Отношение находится в 2NF и нет транзитивных зависимостей.

Ответ на вопрос 1

Да, вы можете оставить стол как есть, потому что он уже находится в 3NF.

Ответ на вопрос 2

Нет - потому что 3NF не требует единого ключа кандидата, который, по вашему мнению, необходим. Кроме того, нет особого требования хранить идентификатор электронной почты в основной таблице; таблица адресов электронной почты будет иметь первичный ключ, который является идентификатором сотрудника, и не требует номера идентификатора электронной почты, поскольку адреса электронной почты уникальны для сотрудника (в соответствии с правилами взаимодействия для этого вопроса). Аналогично для телефонных номеров.


На практике у сотрудника может быть несколько адресов электронной почты и несколько номеров телефонов, даже для личного пользования (отдельно от корпоративного адреса электронной почты и корпоративного номера телефона). В этих условиях у вас будет «непустой список адресов электронной почты» и «непустой список телефонных номеров» для конкретного сотрудника, а затем вам потребуются отдельные таблицы для их записи. Номер телефона будет первичным ключом таблицы информации о телефоне, а идентификатор сотрудника будет FK в таблице телефонных номеров; адрес электронной почты будет первичным ключом таблицы электронной почты, а идентификатор сотрудника будет FK в таблице адресов электронной почты.

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

2
Jonathan Leffler 1 Ноя 2018 в 16:38