Применима ли нормализация в 3NF к схеме, состоящей из нескольких ключей-кандидатов?

Question

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

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

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

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

С 3NF :

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

• Отношение 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. Даже после разделения таблицы у нас могут быть значения, которые, несмотря на то, что внешние ключи являются уникальными (из-за отношения «один к одному»), и, следовательно, могут рассматриваться как ключи-кандидаты в (New) Employee отношении, которые E_mail_Id и Phone_Number_Id. Так не нарушат ли они 3НФ?

Answer 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 (при некоторых разумных предположениях относительно того, как списки могут быть представлены). И критерий «непустой» потребует тщательного применения.