Помощь нормализации

Question

Я реорганизую старую схему Oracle 10g, чтобы попытаться ввести некоторую нормализацию. В одной из больших таблиц есть текстовое поле, которое имеет максимум 10-15 возможных значений. На мой взгляд, это поле является примером ненужного дублирования данных и должно быть извлечено в отдельную таблицу.

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

Answer 1

Вы можете сэкономить место, извлекая столбец в отдельную таблицу.Это называется справочная таблица .Это может дать вам несколько других преимуществ:

• Вы можете объявить ограничение внешнего ключа для таблицы поиска, так что вы можете положиться на столбец в основной таблице, никогда не имея никакого другого значениячем 10-15 значений, которые вы хотите.

• Легко запросить краткий список всех допустимых значений, запросив таблицу поиска.Это может быть быстрее, чем использовать SELECT DISTINCT в столбце основной таблицы.Он также возвращает значения, которые разрешены, но в настоящее время не используются в основной таблице.

• Если изменить значение в таблице поиска, оно автоматически применяется ко всем строкам в основной таблице, которыессылаться на него.

Однако создание таблицы поиска с одним столбцом не является строго нормализацией .Вы просто заменяете одно значение другим.Атрибут в основной таблице либо уже поддерживает нормальную форму, либо нет.

Использование суррогатных ключей (вместо естественных ключей) также не имеет ничего общего с нормализацией.Многие люди допускают эту ошибку.

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

Answer 2

Если вы хотите нормализации, разбейте ее.

Я думаю об этих типах данных в БД как об эквиваленте enums в C, C ++, C #. В основном вы кладете их в таблицу в качестве документации.

У меня часто есть столбцы идентификатора, имени, описания и аудита для них (например, изменено, изменено, создано, активно, создано), поле описания используется редко.

Пример (некоторые могут сказать, что их больше, чем просто 2)

Gender
ID  Name   Audit Columns...
1   Male
2   Female

Тогда в ваших контактах будет столбец GenderID, который будет ссылаться на него.

Конечно, вам не "нужен" стол. У вас может быть где-то внешняя документация, в которой говорится 1 = мужчина, 2 = женщина - но я думаю, что эти таблицы служат для документирования системы.

Answer 3

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

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

Редактировать: одна вещь. Если есть вероятность, что одно из этих значений «флага», вероятно, будет в будущем заменено другим значением другим значением, это будет еще одна веская причина для создания таблицы.

Answer 4

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

Делись и наслаждайся.