Нормализация базы данных: первая нормальная форма

Эти два простых правила помогут нормализовать вашу базу данных.

Первая нормальная форма (1NF) устанавливает основные правила для организованной базы данных:

  • Удалите дублирующие столбцы из одной таблицы.
  • Создайте отдельные таблицы для каждой группы связанных данных и идентифицируйте каждую строку уникальным столбцом (первичным ключом).

Что означают эти правила при рассмотрении практического дизайна базы данных? Это на самом деле довольно просто.

Устранить дублирование

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

Интуитивно понятно, что при создании списка или электронной таблицы для отслеживания этой информации мы можем создать таблицу со следующими полями:

  • Менеджер
  • Subordinate1
  • Subordinate2
  • Subordinate3
  • Подчиненный4

Однако напомним первое правило, наложенное 1NF: исключить дублирующиеся столбцы из той же таблицы. Очевидно, что столбцы Subordinate1-Subordinate4 являются дублирующими. Найдите минутку и обдумайте проблемы, возникающие в связи с этим сценарием. Если у менеджера есть только один подчиненный, столбцы Subordinate2-Subordinate4 – это просто потраченное впустую пространство хранения (драгоценный товар базы данных). Кроме того, представьте себе случай, когда у менеджера уже есть 4 подчиненных – что произойдет, если она возьмет другого сотрудника? Вся структура таблицы потребует изменения.

На этом этапе новичкам в базе данных обычно приходит вторая яркая идея: мы не хотим иметь более одного столбца и хотим обеспечить гибкий объем хранения данных. Давайте попробуем что-то вроде этого:

  • Менеджер
  • Подчиненные

А поле «Подчиненные» будет содержать несколько записей в форме «Мэри, Билл, Джо».

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

Вот таблица, которая удовлетворяет первому правилу 1NF:

  • Менеджер
  • подчиненный

В этом случае каждый подчиненный имеет одну запись, но у менеджеров может быть несколько записей.

Определите первичный ключ

Теперь о втором правиле: идентифицируйте каждую строку с уникальным столбцом или набором столбцов (первичный ключ). Вы можете взглянуть на таблицу выше и предложить использовать подчиненный столбец в качестве первичного ключа. Фактически, подчиненный столбец является хорошим кандидатом на первичный ключ из-за того, что в наших бизнес-правилах указано, что у каждого подчиненного может быть только один руководитель. Однако данные, которые мы выбрали для хранения в нашей таблице, делают это решение далеко не идеальным. Что произойдет, если мы наймем другого сотрудника по имени Джим? Как мы храним его отношения менеджера и подчиненного в базе данных?

Лучше всего использовать действительно уникальный идентификатор (например, идентификатор сотрудника) в качестве первичного ключа. Наш финальный стол будет выглядеть так:

  • Идентификатор менеджера
  • Подчиненный ID

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

Оцените статью
Solutics.ru
Добавить комментарий