Как мы обрабатываем столбец, который имеет одинаковое значение во всех записях таблицы?

Question

Предположим, что у меня есть таблица и для упрощения всех строк около Persons.
Так что предположим, что мы храним цвет человека. Теперь давайте сделаем упрощение, что у нас есть 1 миллион записей, а весь цвет белый (глупый пример, но, пожалуйста, со мной).
Теперь в этом случае white повторяется более 1 миллиона раз.
Теперь, если мы не можем изменить таблицу, например, white_person table так, как это происходит, означает ли это, что атрибут color и person имеют определенное отношение, которое
1) оправдывает повторяющийся атрибут в таблице?
2) оправдывает создание новой таблицы и рассматривает ее как отношение 1-N? Но формально, как бы определить этот тип отношений?

Answer 1

Теперь, если мы не можем изменить таблицу, например, white_person table Способ, которым он является, означает ли это, что цвет атрибута и лицо имеют определенное отношение, которое

1) оправдывает повторяющийся атрибут в таблице?

Повторяющийся атрибут имеет определенное значение в технологии баз данных. Он не означает, что вы можете найти несколько строк, имеющих одинаковое значение. (Вот что такое строки: для.) У вас нет повторяющегося атрибута.

2) оправдывает создание новой таблицы и рассматривает ее как отношение 1-N ? Но формально, как бы этот тип отношений определялся ?

Отношения 1-N будут идентифицированы функциональной зависимостью - вы найдете человека, цвет которого белый, а цвет - также fuschia. Сколько цветов может быть человек в вашей базе данных?

Answer 2

Если одно и то же значение повторяется в каждой строке, то из-за зависимости, которую вы действительно хотели моделировать, ∅ -> {color}, тогда таблица ваших лиц нарушает 2NF: определитель ∅ (пустой набор) является правильным подмножеством ключа. Изменения, необходимые для удовлетворения 2NF, заключались бы в том, чтобы удалить атрибут цвета в новую таблицу с ключом на ∅ (т. Е. Таблицу с одной строкой). Или вообще удалите атрибут из модели.

Обратите внимание, что зависимость никогда автоматически не подразумевается только из-за совпадения некоторых значений в таблице. В чем дело, какие бизнес-правила требуют, чтобы СУБД обеспечивала соблюдение и правильно ли поддерживала модель данных.

Я обсуждал аналогичный пример here.

Answer 3

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

Но я сомневаюсь, что вы можете сделать такое предположение.Чтобы снизить стоимость хранения много повторяющихся строк, отделите цвет к своей таблице с тонким surrogate key (скажем, байтом или 16-битным int), а затем ссылайтесь на него (через FOREIGN KEY) из «большой» таблицы. Таким образом, вы не повторяете строки, вы повторяете (тоньше) целые числа. Это не вопрос нормализации (оба варианта «нормализованы»), но и оптимизация физического дизайна.

Однако, если есть другой атрибут, функционально зависящий от цвета, то у вас обязательно должна быть отдельная таблица. В противном случае будет transitive functional dependencyПК -> цвет -> другой, нарушающий 3NF.

Например: