Справка по нормализации:

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

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

источник

2010-01-14 Melvin

Зависит от многих факторов: * Сколько строк, приблизительно? * делать много запросов, использовать это поле или многое пропустить? * Поле заполняется кем-то, заполняющим текстовое поле (могут ли конечные пользователи испортить его, набрав «офo» вместо «foo»?) * Возможно, клиентские приложения должны быть перезаписаны для изменения схемы? Мое первоначальное влечение - сказать, что у вас, вероятно, есть большая рыба, чтобы жарить, и можно было отключить этот рефакторинг. Тем не менее, это не огромный рефакторинг - вы могли бы профилировать его в обоих направлениях. – Jay

«Я реорганизую старую схему Oracle 10g». С тех пор, когда 10g стали * старыми *? Внезапно я чувствую себя древним. – APC

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

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

источник

2010-01-14 20:38:00

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

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

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

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

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

источник

2010-01-14 20:42:43

@Bill, как насчет в моем ответе, где другие значения в таблице поиска - это просто метаданные для значений поиска - делает ли это «создание» ситуации нормализации, где раньше не существовало? – Hogan

@Bill, также меняется ли ситуация, если справочная таблица ссылается более чем на одну основную таблицу? – Hogan

@Hogan: Если значения поиска имеют собственные собственные атрибуты, то сохранение их в основной таблице приведет к созданию повторяющихся групп, поэтому да, перемещение их в таблицу поиска поможет выполнить 3NF. Я не думаю, что это имеет значение в отношении * нормализации * как такового, что задействованы несколько ссылочных таблиц. Однако, похоже, хорошая идея сократить избыточность. –

Если вы хотите, чтобы нормализация нарушила его.

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

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

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

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

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

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

источник

2010-01-14 20:44:08 Hogan

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

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

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

источник

2010-01-14 23:18:12 Dan

Справка по нормализации:

ответ

Смежные вопросы