3nf функциональная зависимость в примере вики

Я прочитал вики о 3nf https://en.wikipedia.org/wiki/Third_normal_form

это пример, который дают вики

Tournament Winners
Tournament              Year    Winner          Winner Date of Birth
Indiana Invitational    1998    Al Fredrickson  21 July 1975
Cleveland Open          1999    Bob Albertson   28 September 1968
Des Moines Masters      1999    Al Fredrickson  21 July 1975
Indiana Invitational    1999    Chip Masterson  14 March 1977

это сказать, что the non-prime attribute Winner Date of Birth is transitively dependent on the candidate key {Tournament, Year} via the non-prime attribute Winner

Я думаю, что функциональная зависимость заключается в том, что

for two row X1 , X2 if X1.col1 = X2.col1 and 
X1.col2 = X2.col2, then col1 -> col2

Я не могу понять, что Победитель Дата рождения-> Победитель (может быть, кто-то с тем же днем ​​рождения и тем же именем?) И победитель может -> кандидатный ключ {Турнир, Год}, учитывая имя победителя Аль Фредриксона, это может быть Indiana Invitational 1998 или Де Мойн Мастерс 1999)

Итак, как же он приходит к выводу?

Источник

3 ответа

Решение

Неформально функциональная зависимость означает, что одно значение на левой стороне не может создавать несколько значений на правой стороне, даже если левая сторона существует более чем в одной строке. 1

Так, в примере из Википедии есть функциональная зависимость Winner -> Winner Date of Birth просто потому, что один и тот же победитель не может иметь разные даты рождения, даже если он / она существует в нескольких рядах (потому что он / она выиграл несколько турниров).

Поскольку...

  • {Tournament, Year} -> Winner (поскольку в одном турнире не может быть нескольких победителей)
  • а также Winner -> Winner Date of Birth (как объяснено выше)
  • и не Winner -> {Tournament, Year} (так как один человек может выиграть несколько турниров)

... тогда по определению существует транзитивная зависимость.

Я не могу понять, что Победитель Дата рождения-> Победитель (может быть, кто-то с тем же днем ​​рождения и тем же именем?)

Вы изменили направление. Функциональная зависимость не "от" единственного значения, а "к нему". Следовательно Winner -> Winner Date of Birth, но не Winner Date of Birth -> Winner,

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

1 Что соответствует математической концепции "функции". Независимо от того, сколько раз вы "вызываете" функцию (т.е. сколько строк содержат левую часть fd), она всегда дает один и тот же "результат" (правая сторона fd). Если бы он мог давать несколько результатов, он не был бы функцией, это было бы "отношением".

Источник

Что делать, если заявка для одного победителя с другой датой рождения? Тогда можно как их предотвратить?

С базы

Поскольку в каждой строке таблицы необходимо указать, кто выиграл конкретный турнир в определенном году, составной ключ {Tournament, Year} представляет собой минимальный набор атрибутов, гарантирующих уникальную идентификацию строки. То есть {Tournament, Year} является ключом-кандидатом для таблицы.

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

Даже если мы подумаем о дублировании дат рождения (для победителей), мы можем разделить эту таблицу в другой таблице и сохранить {победитель, дата рождения победителя}, чтобы предотвратить дублирование, как показано в вики.

ссылка

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

Вот почему для предотвращения дублирования необходимо создать еще одну таблицу.

Источник

Из того, что я понимаю:
Для любого {Турнира, Года} у вас есть только один победитель. У каждого победителя есть только одна дата рождения. Вики утверждают, что это может привести к уязвимости:
Предположим, вы ввели новую строку: {"Глупый турнир", "2013", "Аль Фредриксон", "21 июля 2012"} - вы ввели неверную дату рождения!
Если вы сохраните другую таблицу {WinnerID, WinnerBithday}, вы предотвратите это.

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