декомпозиция функциональных зависимостей базы данных - PullRequest
Новая
       22

декомпозиция функциональных зависимостей базы данных

1 голос
/ 17 ноября 2011

Таблица - Персона {ID, Имя, Возраст, Линия1, Город, Штат, Zip}

FD set

1) ID -> каждый другой атрибут, такой как PK

2) Я не могу определить, является ли 

 zip -> {Line1, City, State} or.. 

{Line1, City, State} -> zip?  

[both of these are candidate keys I guess]

В любом случае, он становится транзитивной зависимостью, поскольку

ID -> Zip -> другой адрес (или ID ->адрес связан -> почтовый индекс).

Нарушает 3NF (транзитивная зависимость).

Не могли бы вы объяснить, как мне разложить данное отношение, и что становится PK в другом отношении, содержащем связанный адрес.

Ответы [ 2 ]

1 голос
/ 17 ноября 2011

Предполагая, что {Line1, City, State} -> {Zip} и {Zip} -> {City, State}, следующая декомпозиция будет в 3NF: 

Person {ID, Name, Age, Line1, Zip} (key= {ID})
Address {City, State, Zip} (keys = {City, State} and {Zip])

На практике это может оказаться бесполезным, поскольку данные реальных адресов часто противоречивы или отсутствуют части. Реальный вопрос в том, какие зависимости вы действительно хотите применить в своей базе данных. Вот почему упражнения, которые зависят от определения зависимостей только из списка имен атрибутов, являются настолько субъективными. Единственный способ дать окончательный ответ - начать с набора зависимостей, которым вы хотите, чтобы схема удовлетворяла.

1 голос
/ 17 ноября 2011

Если вы знаете (Line1, City, State), вы можете определить zip.Итак, 

{Line1, City, State} -> zip

Не наоборот.Поскольку один и тот же почтовый индекс может содержать несколько значений Line1 для одного и того же города и штата (например, разные номера домов на одной улице).

Для 3NF отношения могут быть

  • Person {ID, Имя, Возраст, Линия1, Город, Штат}
  • Адрес {Линия1, Город, Штат, Zip}

Из практических соображений это выглядит избыточно и тратит пространство в таблицах базы данных.

...