Приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие посты
Приложения

34 лучших бесплатных программных инструмента для резервного копирования

Приложения

Лучшие онлайн-инструменты для встреч

Приложения

11 лучших бесплатных почтовых аккаунтов

Приложения

7 бесплатных языков программирования для обучения детей кодированию