Что объединяет повторяющиеся наборы информации о строках в новые объекты, вызываемые при нормализации базы данных?

Question

Я немного запутался в некоторой части нормализации базы данных и думал, что попрошу StackOverflow:

Представьте, что у вас есть следующие отношения, которые связывают продукты с цветами. Обратите внимание, что в продуктах 1 и 2 используются одинаковые цвета (синий и зеленый).

Product_Color       Color 
+-------------+-------------+  +-------------+-------------+ 
| Product* | Color*  |  | ColorId* | Name  | 
+-------------+-------------+  +-------------+-------------+ 
| 1   | 1   |  | 1   | Blue  | 
| 1   | 2   |  | 2   | Green  | 
| 2   | 1   |  +-------------+-------------+ 
| 2   | 2   | 
+-------------+-------------+ 

Если я создаю два новых отношений, ColorSet и ColorSet_Color, я могу показать ту же информацию, соединив 4 отношения друг с другом.

Product_ColorSet:     ColorSet_Color:    
+-------------+-------------+  +-------------+-------------+ 
| Product* | ColorSetId* |  | ColorSetId* | ColorId* | 
+---------------------------+  +-------------+-------------+ 
| 1   | 1   |  | 1   | 1   | 
| 2   | 1   |  | 1   | 2   | 
+-------------+-------------+  +---------- --+-------------+ 

ColorSet:       Color: 
+-------------+     +-------------+-------------+ 
| ColorSetId* |     | ColorId* | Name  | 
+-------------+     +-------------+-------------+ 
| 1   |     | 1   | Blue  | 
| 2   |     | 2   | Green  | 
+-------------+     +----------[--+-------------+ 

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

Что такое техническое имя для этой операции в контексте нормализации базы данных? Я явно удаляю избыточную информацию, даже если созданная мной сущность фактически не существует, а скорее случайная вероятность того, что существует много перекрытий. Что конкретно меняю, делая это?

Кроме того, похоже, что я мог бы произвольно сделать это для большинства объектов. Меня озадачивает то, что Product_Color и Color уже находятся в 6-й нормальной форме, когда мы начали упражнение (правильно?).

Answer 1

Вы внедряете «surrogate key» (или идентификатор) для имени/идентифицировать наборов цветов, что продукты приходят в. Альтернатива, как правило, считаются «natural key» (или идентификатор). (Хотя разные люди используют эти термины по-разному подробно. Например, некоторые могут использовать только «суррогат», когда имя/идентификатор постоянно назначается референтом и/или является единственным именем/идентификатором его референта и/или он виден только с базой данных & а не приложение. Например, некоторые говорят, что внешне видимое системное генерируемое произвольное имя/идентификатор, такое как идентификационный номер драйвера, является суррогатным и естественным.)

Суррогатные ключи часто называются «бессмысленными (идентификаторами)». Это отражает путаное мышление. Все имена, не генерируемые априорной схемой именования, являются «бессмысленными» &. «Николас» не «имел в виду» вас, пока не был выбран; будучи избранным, он «означает» вас. Это для любое имя/идентификатор. Таким образом, «бессмысленный»/«значащий» не является полезным различием. Суррогатное имя/идентификатор в системе - это только тот, который был выбран после запуска системы. То, что называется «значимым» [sic] в системе, было бы названо «бессмысленным» [sic] при назначении в любой системе, существовавшей до этого (поскольку назначение было после , было начато).

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

Иногда люди думают, что если один и тот же подзадача значений может появляться более одного раза в наборе столбцов или таблице, то эти значения надстроек должны быть заменены идентификаторами, которые являются FKs, в новую таблицу, которая отображает значения id для значений подзаголовков , (Может быть, даже для столбцов с одним столбцом, т. Е. Когда одно значение появляется более одного раза в столбце или таблице.) Они думают, что множественные появления значений подземелья «избыточны» или что только идентификаторы могут повторяться, не будучи «избыточными». (Дизайн id рассматривается как своего рода сжатие данных оригинала.) Они могут подумать, что это часть нормализации. None of this is so.

Это не избыточность, которую вы должны потрудиться при помощи дизайна стола. Если вы знаете варианты реализации своих таблиц с помощью СУБД и, вы знаете шаблоны использования вашего приложения и, вы знаете, что оригинал явно и значимо хуже, чем какой-либо вариант, который оказывается «менее избыточным» (и почему бы не «более избыточный» вариант быть лучше?) затем вы должны сообщить СУБД, какой вариант вы хотите для своего дизайна, не меняя схему, если можете. (Обычно это делается с помощью индексов и/или представлений.) Например, индексирование исходного Product_Color на ColorId приводит к практически той же структуре в реализации, которую вы создали вручную во втором дизайне, но автоматически сгенерировали и управляли. (Вы можете ввести суррогаты для других причин, например, для замены несколько столбцов внешних ключей на более кратком, хотя и более туманно оценены и ограничены из них.)

варианты Re: Ваш новый дизайн будут использовать больше операций (например, соединение и прогнозы) в тексте запроса и (для типичных реализаций СУБД) исполнение, чем оригинал (например, для запроса исходной таблицы), но меньше в другом месте (например, при копировании цвета одного продукта в другой). Так снова это все о компромиссы из несколько «перспективы».

Фактически у вас есть в другом смысле введено избыточность с суррогатами. Есть дополнительные столбцы, содержащие кучу значений id, которые еще не находятся в оригинале, но записывают одни и те же ситуации. Вы также обременяли пользователя дизайном с большим количеством имен и указаний. Суррогатный дизайн, безусловно, имеет много «избыточной информации» в этой «перспективе» по сравнению с оригиналом.

Даже ваш стартовый дизайн, вероятно, ввел суррогаты, а именно цветные идентификаторы цветных имен. (Если идентификаторы цвета добавили «информацию», то есть «проинформировали» вас за пределами только их ассоциированных имен, то они не были бы суррогатами и были бы необходимы.) Т.е., если идентификаторы цвета выбраны произвольно, тогда вы можете просто:

Product_Color 
+-------------+-------------+ 
| Product* | ColorName* | 
+-------------+-------------+ 
| 1   | Blue  | 
| 1   | Green  | 
| 2   | Blue  | 
| 2   | Green  | 
+-------------+-------------+ 

У вас должна быть причина, чтобы ввести идентификаторы цвета, и в этом случае идентификаторы продуктов, а не существующие уже существующие ключи. Можете ли вы обосновать несколько таблиц, имен и указаний против одного?