Как 5NF работает с оригинальной таблицей с ID Column - PullRequest
Новая
       60

Как 5NF работает с оригинальной таблицей с ID Column

0 голосов
/ 23 сентября 2019

Когда я изучал нормальные формы, я столкнулся с интересной проблемой, но нигде не смог найти ответ, потому что большинство примеров, которые я видел, не используют столбцы Id, они используют типичный шаблон «Поставщик, Производитель, Потребитель».Предположим, у меня есть таблица под названием customer со следующей схемой: 

Customer(ID: int [PK], Name: varchar(100), Address: varchar(100), Picture: varchar(100));

Если бы я нормализовал эту табличную форму к 5NF, я думаю, что это выглядело бы так: 

CustomerName(Id:int [PK], Name: varchar(100)); 

CustomerAddress(Id:int [PK], Address: varchar(100)); 

CustomerPicture(Id:int [PK], Address: varchar(100));

Сейчасэто удовлетворяет 5NF, потому что я могу объединить эти таблицы в исходную таблицу без потери данных, но так ли это на самом деле?Это просто кажется мне глупым, потому что, если бы я хотел получить всю информацию о клиенте, мне пришлось бы написать запрос с несколькими объединениями, а объединения были бы дорогостоящими, с точки зрения производительности.Правильно ли я разложил эту таблицу?Я чувствую, что, возможно, что-то пропустил.

1 Ответ

1 голос
/ 25 сентября 2019

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

Допустим, у вас есть переменная отношения, Customer, с атрибутами: id, имя, адрес, фотография.Учитывая следующую функциональную зависимость:

{id} → {имя, адрес, изображение}

Если единственными зависимостями соединения, удовлетворяемыми Заказчиком, являются те, которые подразумеваются вышеупомянутым FD, то мы можем заключить, что idявляется единственным потенциальным ключом Клиента, и этот Клиент удовлетворяет 5NF, потому что все его JD подразумеваются ключами.

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

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

...