Первая нормальная форма (1NF) устанавливает основные правила для организованной базы данных:
- Устранение дублирующих столбцов из одной таблицы.
- Создайте отдельные таблицы для каждой группы связанных данных и определите каждую строку с уникальным столбцом (первичный ключ).
Что означают эти правила при рассмотрении практического дизайна базы данных? На самом деле это довольно просто.
Устранение дублирования
Первое правило диктует, что мы не должны дублировать данные в одной строке таблицы. Внутри сообщества базы данных эта концепция называется атомарностью таблицы. Таблицы, соответствующие этому правилу, называются атомарными. Давайте рассмотрим этот принцип с классическим примером: таблица в базе данных о людских ресурсах, в которой хранятся подчиненные менеджеру отношения. Для целей нашего примера мы навяжем бизнес-правило, что каждый менеджер может иметь одного или нескольких подчиненных, в то время как каждый подчиненный может иметь только одного менеджера.
Интуитивно, создавая список или электронную таблицу для отслеживания этой информации, мы можем создать таблицу со следующими полями:
- Менеджер
- Subordinate1
- Subordinate2
- Subordinate3
- Подчиненный4
Однако вспомните первое правило, наложенное 1NF: устраните дублирующие столбцы из одной таблицы. Очевидно, что столбцы Subordinate1-Subordinate4 являются дублирующими. Потратьте время и подумайте о проблемах, связанных с этим сценарием. Если у менеджера только один подчиненный, столбцы Subordinate2-Subordinate4 просто теряют пространство для хранения (ценный товар базы данных). Кроме того, представьте себе случай, когда у менеджера уже есть 4 подчиненных - что произойдет, если она возьмет другого сотрудника? Вся структура таблицы потребует модификации.
На данный момент вторая яркая идея обычно возникает у новичков базы данных: мы не хотим иметь более одного столбца, и мы хотим обеспечить гибкое хранение данных. Попробуем что-то вроде этого:
- Менеджер
- Подчиненные
И поле Subordinates будет содержать несколько записей в форме «Mary, Bill, Joe».
Это решение ближе, но оно также не соответствует значению. Столбец подчиненных по-прежнему является дублирующим и неатомным. Что происходит, когда нам нужно добавить или удалить подчиненного? Нам нужно прочитать и написать все содержимое таблицы. Это не очень важно в этой ситуации, но что, если у одного менеджера было сто сотрудников? Кроме того, это усложняет процесс выбора данных из базы данных в будущих запросах.
Вот таблица, которая удовлетворяет первому правилу 1NF:
- Менеджер
- подчиненный
В этом случае каждый подчиненный имеет одну запись, но менеджеры могут иметь несколько записей.
Определите первичный ключ
Теперь, как насчет второго правила: идентифицируйте каждую строку с уникальным столбцом или набором столбцов (первичный ключ). Вы можете взглянуть на таблицу выше и предложить использовать подчиненный столбец в качестве первичного ключа. Фактически, подчиненный столбец является хорошим кандидатом для первичного ключа из-за того, что в наших бизнес-правилах указано, что каждый подчиненный может иметь только одного менеджера. Однако данные, которые мы выбрали для хранения в нашей таблице, делают это менее идеальным решением. Что произойдет, если мы найм другого сотрудника по имени Джим? Как мы храним его подчиненное менеджеру в базе данных?
Лучше всего использовать поистине уникальный идентификатор (например, идентификатор сотрудника) в качестве первичного ключа. Наш финальный стол будет выглядеть так:
- ID менеджера
- Подчиненный идентификатор
Теперь наша таблица в первой нормальной форме! Помимо этого, есть варианты для размещения вашей базы данных во второй нормальной форме, а также в третьей нормальной форме, если вы в восторге от еще большей организации.
