базы данных Нормализация цепочки

Question

У меня есть несколько таблица формирования цепочки, как это:

table1

product_id SERIAL NOT NULL, 
name varchar, 

таблица2 (отдельно от table1, так как же имя продукта, но может быть другой цвет)

table2_id 
product_id integer, 
color varchar, 
FOREIGN KEY (product_id) REFERENCES table1 (product_id) ON DELETE CASCADE 

Таблица3 (отдельный из таблица2 т.к. такой же товар цвет но бывает другой размер)

table3_id 
table2_id integer, 
size varchar, 
FOREIGN KEY (table2_id) REFERENCES table2 (table2_id) ON DELETE CASCADE 

например, данные о продукте может быть

a chair (name) - red (color) - 100cm(size) 
a chair (name) - red (color) - 200cm(size) 
b chair (name) - green (color) - 100cm(size) 
b chair (name) - green (color) - 200cm(size) 
c chair (name) - black (color) - s(size) 
c chair (name) - black (color) - m(size) 
d chair (name) - black (color) - null(size) 
e chair (name) - gold (color) - big(size) 
e chair (name) - gold (color) - small(size) 

если следовать нормализация удалить дубликат, так что я разделить их как 3 таблицы, но я не уверен, цепочки, как этот правильной или нет

Answer 1

Да, это хорошо, но, возможно, модель должна быть что-то вроде:

product -<product_variant>- product_size 

        V 
        | 
      product_colour 

Answer 2

Это вторая версия same question вы представили. Ответ тот же.

Продукт является сущностью. Размер и цвет являются атрибутами.

В таблице содержатся объекты. Каждая сущность представлена ​​строкой. Поля каждой строки являются атрибутами каждого объекта. Вы не создаете новую таблицу каждый раз, когда вам нужно добавить атрибут к сущности. Это затрудняет работу с реляционными базами данных.

Answer 3

Похоже, что вы считаете, что вам нужен идентификатор каждый раз, когда данный подзадача значения появляется более одного раза в таблице. То есть вы пытаетесь удалить «дубликаты», которые не нужно удалять. Одно и то же значение, появляющееся более одного раза, не является «дубликатом» в смысле нормировки и не обязательно является плохим. Также ни одно использование нескольких таблиц и идентификаторов не является нормализацией. (Я уже пытался решить это определение таблицы «Цепочка» антишаблон here.)

От this answer:

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

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

Или от that answer's link :

Это не имеет никакого отношения к нормализации. Нормализация никогда не создает новые имена столбцов. «Я не хочу, чтобы« Nintendo »дублировался, ошибочно.По сути, нет ничего неправильного со значениями, появляющимися во многих местах. См. Ответы от sqlvogel & себя here.

«Резервирование» не относится к значениям, появляющимся в нескольких местах. Речь идет о нескольких строках, в которых говорится о приложении. При использовании такого дизайна существуют две основные проблемы: говорить о некоторых вещах, связанных с несколькими строками (в то время как нормализованная версия включает только одну строку); и нет никакого способа сказать только одну из вещей за раз (с которой может помочь нормализация). Если вы создадите два разных независимых утверждения о Nintendo, вам понадобятся две таблицы и Nintendo, упомянутые в каждом из них. Строки Re, содержащие заявления о приложении, см. this. (И искать другие ответы на «утверждение» или «критерий» таблицы). Нормализация помогает, потому что она заменяет таблицы, строки которых содержат элементы формы «... И ...» другими таблицами, в которых указано «...» отдельно. См. this и this. (Обычно ошибочно считается, что включение или включение исключает несколько похожих столбцов, избегая столбцов, значения которых имеют повторяющуюся структуру и/или заменяют строки идентификаторами, но хотя это могут быть хорошие дизайнерские идеи, они не нормализуются .)

От my answer at that answer's first link:

Если SUBJECT_MODULE это строки, где «[SUBJECT_NAME] имеет [MODULE_N AME], идентифицированный [MODULE_ID] ", и у субъекта может быть более одного модуля, а затем где-то у вас должно быть есть несколько упоминаний об этом предмете (возможно, через его название) с упоминаниями разных модулей (возможно, по имени или id). Это не предполагает избыточности.