Описание основ нормализации базы данных
Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.
Исходный номер КБ: 283878
В этой статье объясняется терминология нормализации баз данных для начинающих. Базовое понимание этой терминологии полезно при обсуждении разработки реляционной базы данных.
Описание нормализации
Нормализация — это процесс организации данных в базе данных. Это включает создание таблиц и установление связей между этими таблицами в соответствии с правилами, предназначенными как для защиты данных, так и для того, чтобы сделать базу данных более гибкой за счет устранения избыточности и непоследовательной зависимости.
Избыточные данные пустая трата дискового пространства и создает проблемы с обслуживанием. Если данные, которые существуют в нескольких местах, должны быть изменены, данные должны быть изменены точно так же во всех расположениях. Изменение адреса клиента гораздо проще реализовать, если эти данные хранятся только в таблице Клиентов и нигде в базе данных.
Что такое «непоследовательная зависимость»? Хотя пользователю интуитивно понятно искать в таблице Клиенты адрес конкретного клиента, не имеет смысла искать там зарплату сотрудника, который вызывает этого клиента. Заработная плата сотрудника связана с сотрудником или зависит от него, и поэтому его следует перенаселять в таблицу «Сотрудники». Несовместимые зависимости могут затруднить доступ к данным, так как путь к поиску данных может быть пропущен или нарушен.
Существует несколько правил нормализации базы данных. Каждое правило называется «нормальной формой». Если первое правило соблюдается, база данных, как сообщается, находится в «первой нормальной форме». Если соблюдаются первые три правила, база данных рассматривается как «третья нормальная форма». Хотя возможны другие уровни нормализации, третья нормальная форма считается наивысшим уровнем, необходимым для большинства приложений.
Как и во многих формальных правилах и спецификациях, сценарии реального мира не всегда позволяют обеспечить идеальное соответствие требованиям. Как правило, для нормализации требуются дополнительные таблицы, и некоторые клиенты считают это громоздким. Если вы решите нарушить одно из первых трех правил нормализации, убедитесь, что ваше приложение предвосхищает возможные проблемы, такие как избыточные данные и несовместимые зависимости.
Ниже описаны примеры.
Первая нормальная форма
Не используйте несколько полей в одной таблице для хранения аналогичных данных. Например, для отслеживания элемента инвентаризации, который может приходить из двух возможных источников, запись инвентаризации может содержать поля для кода поставщика 1 и кода поставщика 2.
Что происходит при добавлении третьего поставщика? Добавление поля не является ответом; она требует изменений программы и таблицы и не позволяет плавно разместить динамическое число поставщиков. Вместо этого поместите всю информацию поставщика в отдельную таблицу под названием Поставщики, а затем увязыв инвентаризацию с поставщиками с ключом номера элемента, или поставщики для инвентаризации с ключом кода поставщика.
Вторая нормальная форма
Записи не должны зависеть от чего-либо, кроме основного ключа таблицы (сложный ключ, если это необходимо). Например, рассмотрим адрес клиента в системе учета. Адрес необходим в таблице Клиенты, а также таблицами «Заказы», «Доставка», «Счета-фактуры», «Отчеты о счетах» и «Коллекции». Вместо того, чтобы хранить адрес клиента как отдельную запись в каждой из этих таблиц, храните его в одном месте, в таблице Клиенты или в отдельной таблице Адресов.
Третья нормальная форма
Значения в записи, которая не входит в ключ этой записи, не относятся к таблице. В общем, в любое время содержимое группы полей может применяться к более чем одной записи в таблице, рассмотрите возможность размещения этих полей в отдельной таблице.
Например, в таблице набора сотрудников может быть включено имя и адрес университета кандидата. Но для групповой рассылки необходим полный список университетов. Если сведения о университетах хранятся в таблице Candidates, нет возможности перечислять университеты без текущих кандидатов. Создайте отдельную таблицу университетов и привяжете ее к таблице Кандидаты с ключом кода университета.
ИСКЛЮЧЕНИЕ: применение третьей обычной формы, хотя теоретически желательно, не всегда является практическим. Если у вас есть таблица Клиентов и вы хотите устранить все возможные зависимости между полями, необходимо создать отдельные таблицы для городов, почтовых индексов, представителей продаж, классов клиентов и любого другого фактора, который может быть дублирован в нескольких записях. В теории, нормализация стоит очистки. Однако многие небольшие таблицы могут ухудшать производительность или превышать возможности открытого файла и памяти.
Возможно, более целесообразно применять третью нормальную форму только к данным, которые часто меняются. Если остаются некоторые зависимые поля, спроектировать приложение, чтобы потребовать от пользователя проверить все связанные поля при их смене.
Другие формы нормализации
Четвертая нормальная форма, также называемая «Обычная форма Бойс Кодд» (BCNF), и пятая нормальная форма существуют, но редко рассматриваются в практическом дизайне. Игнорирование этих правил может привести к менее совершенному дизайну базы данных, но не должно влиять на функциональные возможности.
Нормализация таблицы примеров
Эти действия демонстрируют процесс нормализации фиктивной студенческой таблицы.
| Student # | Советник | Adv-Room | Класс 1 | Class2 | Class3 |
|---|---|---|---|---|---|
| 1022 | Джонс | 412 | 101-07 | 143-01 | 159-02 |
| 4123 | Smith | 216 | 101-07 | 143-01 | 179-04 |
Первая нормальная форма: нет повторяюющихся групп
Таблицы должны иметь только два измерения. Так как у одного учащегося несколько классов, эти классы должны быть указаны в отдельной таблице. Поля Class1, Class2 и Class3 в вышеуказанных записях указывают на проблемы с дизайном.
Таблицы часто используют третье измерение, но таблицы не должны. Другой способ взглянуть на эту проблему — это отношение между одним и большим количеством, не помещая одну сторону и множество сторон в одну таблицу. Вместо этого создайте другую таблицу в первой обычной форме, устранив группу повторяющихся (Класс#), как показано ниже:
| Student # | Советник | Adv-Room | Класс # |
|---|---|---|---|
| 1022 | Джонс | 412 | 101-07 |
| 1022 | Джонс | 412 | 143-01 |
| 1022 | Джонс | 412 | 159-02 |
| 4123 | Smith | 216 | 101-07 |
| 4123 | Smith | 216 | 143-01 |
| 4123 | Smith | 216 | 179-04 |
Вторая нормальная форма: устранение избыточных данных
Обратите внимание на несколько значений Класса#для каждого значения Student# в вышеуказанной таблице. Класс# функционально не зависит от student# (основной ключ), поэтому эта связь не находится во второй нормальной форме.
В следующих таблицах демонстрируется вторая нормальная форма:
| Student # | Советник | Adv-Room |
|---|---|---|
| 1022 | Джонс | 412 |
| 4123 | Smith | 216 |
| Student # | Класс # |
|---|---|
| 1022 | 101-07 |
| 1022 | 143-01 |
| 1022 | 159-02 |
| 4123 | 101-07 |
| 4123 | 143-01 |
| 4123 | 179-04 |
Третья нормальная форма: устранение данных, не зависящих от ключа
В последнем примере Adv-Room (номер офиса советника) функционально зависит от атрибута Advisor. Решение заключается в том, чтобы переместить этот атрибут из таблицы Студенты в таблицу факультета, как показано ниже:
Вторая нормальная форма (в терминологии SQL)
Поскольку первый пост уже сорвал крышу нескольким хабражителям вообще и пошатнул карму мне в частности, решил написать перевод статьи в терминах языка SQL. Будет полезно мне и, возможно, не только мне. Вообще с детских лет я стремлюсь приземлять теорию к практике с помощью различных средств, среди которых был и алкоголь, и, мне кажется бесполезно тратить время на изучение чегото, к чему нельзя придумать пример из реальной жизни.
Забавно лишь, что вся эта белиберда под катом родилась в уме Кодда еще до возникновения SQL как языка, а теперь вот в терминах SQL все подавай…
Что же такое вторая нормальная форма или 2NF? Так чтоб трехлетний ребенок действительно понял…
Для начала разберемся в целях, которые преследует нормализация. Под катом нету терминов дискретки…
Цель приведения к первой нормальной форме (1NF) — дать возможность использовать условия WHERE при выборке данных запросом SELECT. Поскольку все значения колонки имеют одинаковый и определенный заранее тип, их можно сравнивать между собой и с константами.
Например, если в таблице ’Family’ есть колонка ’Kids’ типа VARCHAR, мы можем легко сравнить две строки ’Вася’ и ’Аня’ и определить их лексикографический порядок, например оператором >
| Family | Kids |
|---|---|
| Ивановы | Вася |
| Петровы | Аня |
Если в какой то строчке в поле ’Дети’ указано ’Ваня, Саша’, мы уже не можем однозначно определить порядок деток. Сравнивать строки ’Вася’ и ’Ваня, Саша’ бессмысленно в данной ситуации. поскольку первое — это строка, а второе — уже список. Допустим мы хотим найти всех детей на букву ‘C’.
| Family | Kids |
|---|---|
| Ивановы | Вася |
| Петровы | Аня |
| Сидоровы | Ваня, Саша |
не отработает в данной ситуации как нужно и не найдет Сашу, поскольку LIKE не умеет парсить списки, извлекать значения и трактовать их как аргументы для сравнения с шаблоном. ’Ваня, Саша’ в данном случае неатомарное значение типа список строк. Чтобы научить SQL работать с такими данными, нужно либо расширить язык, либо упростить модель до 1NF. Декомпозиция до 1NF достигается разбиением составного значения на атомарные:
| Family | Kids |
|---|---|
| Ивановы | Вася |
| Петровы | Аня |
| Сидоровы | Ваня |
| Сидоровы | Саша |
То есть первая НФ имеет дело, со структурой значений колонок.
Вторая (и третья, но не о ней сегодня) НФ имеет дело уже с ключами и зависимостями между колонками таблицы. Перечислим ее цели с пояснениями.
Например, у нас есть таблица
| ID | CD_name | Artist |
|---|---|---|
| 10 | Six Degrees Of Inner Turbulence | Dream Theater |
| 20 | Metropolis, pt. 2: Scenes From A Memory | Dream Theater |
| 30 | Master of Puppets | Dream Theater |
, где первичным ключом является ID. Эта схема находится во 2NF, поскольку колонка Artist, которая не входит в ключ определяется только ключом целиком.
Таблица находится во 2NF если любая неключевая колонка определяется только целым ключом и не может быть определена его частью
Вообще ставить вопрос о несоответствии 2NF можно только в случае если в таблице есть составные ключи. Таблицы с простыми ключами, как в примере всегда имеют 2NF. Указанная таблица есть как раз пример такого случая, так как в ней оба ключа (а это ID и естественный ключ CD_name) простые, и частей у них нет.
Несоответствие 2NF рассмотрим на таблице
| Artist | CD_name | Track | Lyrics |
|---|---|---|---|
| Dream Theater | Six Degrees Of Inner Turbulence | Misunderstood | Petrucci |
| Dream Theater | Metropolis, pt. 2: Scenes From A Memory | Overture 1928 | (instrumental) |
| Dream Theater | Master of Puppets | Battery | Неtfield |
| Metallica | Master of Puppets | Battery | Неtfield |
| Ensiferum | Tale of Revenge | Battery | Неtfield |
Одна и та же песня может входить в несколько дисков, также теоретически возможны одноименные альбомы с одноименными песнями у разных групп, например трибьюты. Поэтому ключом будет . При этом значение колонки Lyrics, обозначающий автора слов, однозначно определяется из колонок , которые есть частью ключа. Это и есть нарушение 2NF.
Следствием этого есть избыточность значений в колонке Lyrics для каждого диска в который входит песня. В сфере музыки эти значения не меняются, но в других доменных областях неосторожное изменение таких избыточных данных может привести к противоречивому состоянию БД, когда обновлены будут не все значения. Это пример аномалии модификации.
Другим следствием есть то, что песни, которые еще не выпущены на СД-дисках, а просто транслированы по радио или выпущены на других носителях, не подходят под указанную схему данных. Соответственно мы не сможем добавить новую песню в базу данных пока она не будет выпущена на СД. Это пример аномалии вставки.
Аналогично если мы захотим удалить какой-либо диск из базы данных, мы будем вынуждены потерять информацию об авторах всех песен, которые входят только в этот диск, поскольку в данной модели нет возможности представить информацию об авторе, если песня не входит в какой-либо СД. Например желание удалить диск Six Degrees Of Inner Turbulence приведет к тому, что автор песни Misunderstood будет утерян, что непростительно. Это пример аномалии удаления.
Чтобы избежать подобных аномалий и убрать избыточность, нам нужно разделить таблицу, то есть провести ее декомпозицию на две:
| Artist | CD_name | Track |
|---|---|---|
| Dream Theater | Six Degrees Of Inner Turbulence | Misunderstood |
| Dream Theater | Metropolis, pt. 2: Scenes From A Memory | Overture 1928 |
| Dream Theater | Master of Puppets | Battery |
| Metallica | Master of Puppets | Battery |
| Ensiferum | Tale of Revenge | Battery |
| Artist | Track | Lyrics |
|---|---|---|
| Dream Theater | Misunderstood | Petrucci |
| Dream Theater | Overture 1928 | (instrumental) |
| Metallica | Battery | Неtfield |
В реальной базе для построения запросов нужно еще ввести смысловые связи между таблицами, например, свзать их с помощью foreign key, но для нашего примера достаточно понимать что эти таблицы связаны по смыслу.
Обе таблицы имеют 2NF, первая — поскольку у нее все колонки входят в ключ, а вторая — поскольку Lyrics определяется по ключу и не определяется однозначно по любой из колонок Artist или Track.
Про склад наверное не буду, устал таблички набирать в хтмл 
Вот собственно и все.
Надеюсь вот щас было понятно, я же пошел разбираться с 3NF!
Нормализация отношений. Первая и вторая нормальные формы
Предисловие
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Любому специалисту, по роду своей деятельности так или иначе связанному с проектированием реляционных баз данных, полезно понимать и уметь осуществить нормализацию отношений. И этим постом хотелось бы начать небольшую серию публикаций, посвящённых нормальным формам, имеющую целью дать тем читателям Хабрахабра, которые по различным обстоятельствам ещё не освоили эту тему, возможность легко заполнить этот пробел в знаниях.
Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе. Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами. Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение:
Первая нормальная форма
Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности.
Будем называть исходное отношение основным, а значение неатомарного атрибута — подчинённым.
Для того, чтобы нормализовать исходное отношение, атрибуты которого неатомарны, необходимо объединить схемы основного и подчинённого отношений. Кроме того, если, например, таблица, соответствующая ненормализованному отношению уже содержится в БД и заполнена информацией, задача усложняется тем, что значение неатомарного атрибута может в свою очередь содержать несколько кортежей.
Следует пояснить сказанное на примере. Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.
| Код сотрудника | ФИО | Должность | Проекты |
| 1 | Иванов Иван Иванович | Программист | ID: 123; Название: Система управления паровым котлом; Дата сдачи: 30.09.2011 ID: 231; Название: ПС для контроля и оповещения о превышениях ПДК различных газов в помещении; Дата сдачи: 30.11.2011 ID: 321; Название: Модуль распознавания лиц для защитной системы; Дата сдачи: 01.12.2011 |
Легко заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение этого атрибута для сотрудника Иван Иванович Иванов содержит несколько кортежей — информацию о трёх проектах.
Примечание: с некоторой точки зрения атрибут «ФИО» можно также считать неатомарным и в таком случае его также следует разделить на более простые, как «Фамилия», «Имя», «Отчество».
Результат будет выглядеть так:
| Код сотрудника | ФИО | Должность | Код проекта | Название | Дата сдачи |
| 1 | Иванов Иван Иванович | Программист | 123 | Система управления паровым котлом | 30.09.2011 |
| 1 | Иванов Иван Иванович | Программист | 231 | ПС для контроля и оповещения о превышениях ПДК различных газов в помещении | 30.11.2011 |
| 1 | Иванов Иван Иванович | Программист | 321 | Модуль распознавания лиц для защитной системы | 01.12.2011 |
Вторая нормальная форма
Ясно, что отношение, находящееся в 1НФ, также может обладать избыточностью. Для её устранения предназначена вторая нормальная форма. Но прежде чем приступить к её описанию, сначала следует выявить недостатки первой.
Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.
| Код поставщика | Город | Статус города | Код товара | Количество |
| 1 | Москва | 20 | 1 | 300 |
| 1 | Москва | 20 | 2 | 400 |
| 1 | Москва | 20 | 3 | 100 |
| 2 | Ярославль | 10 | 4 | 200 |
| 3 | Ставрополь | 30 | 5 | 300 |
| 3 | Ставрополь | 30 | 6 | 400 |
| 4 | Псков | 15 | 7 | 100 |
Заранее известно, что в этом отношении содержатся следующие функциональные зависимости:
< <Код поставщика, Код товара>-> < Количество>,
<Код поставщика>-> <Город>,
<Код поставщика>-> <Статус>,
<Город>-> <Статус>>
Такое разбиение устранило аномалии, описанные выше: можно добавить информацию о поставщике, который ещё не поставлял товар, удалить информацию о поставке без удаления информации о поставщике, а также легко обновить информацию в случае если поставщик переехал в другой город.
Теперь можно сформулировать определение второй нормальной формы, до которого, скорее всего, читатель уже смог догадаться самостоятельно: отношение находится во второй нормальной форме (сокращённо 2НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
Вторая нормальная форма (2NF) базы данных
Всем привет! Сегодня мы с Вами подробно рассмотрим вторую нормальную форму (2NF) базы данных, в частности Вы узнаете, какие требования предъявляются к таблицам, чтобы база данных находилась во второй нормальной форме, и для наглядности мы как всегда рассмотрим несколько примеров.
Перед тем как переходить к процессу приведения таблиц базы данных до второй нормальной формы, необходимо чтобы эти таблицы уже находились в первой нормальной форме, подробно процесс приведения таблиц базы данных до первой нормальной формы, а также все требования, предъявляемые к первой нормальной форме, мы рассматривали в предыдущей статье – первая нормальная форма (1NF).
После того как таблицы базы данных находятся в первой нормальной форме, мы можем начинать приводить базу данных ко второй нормальной форме и рассматривать соответствующие требования.
Требования второй нормальной формы (2NF)
Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:
Ключ – это столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга, т.е. ключ идентифицирует каждую строку таблицы. По ключу мы можем обратиться к конкретной строке данных в таблице.
Если ключ составной, т.е. состоит из нескольких столбцов, то все остальные неключевые столбцы должны зависеть от всего ключа, т.е. от всех столбцов в этом ключе. Если какой-то атрибут (столбец) зависит только от одного столбца в ключе, значит, база данных не находится во второй нормальной форме.
Иными словами, в таблице не должно быть данных, которые можно получить, зная только половину ключа, т.е. только один столбец из составного ключа.
Главное правило второй нормальной формы (2NF) звучит следующим образом
Таблица должна иметь правильный ключ, по которому можно идентифицировать каждую строку.
Пример приведения таблицы ко второй нормальной форме
Представим, что нам нужно хранить список сотрудников организации, и для этого мы создали следующую таблицу.
Таблица сотрудников в первой нормальной форме.
| ФИО | Должность | Подразделение | Описание подразделения |
| Иванов И.И. | Программист | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| Сергеев С.С. | Бухгалтер | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| John Smith | Продавец | Отдел реализации | Организация сбыта продукции |
Мы видим, что она удовлетворяет условиям первой нормальной формы, т.е. в ней нет дублирующих строк и все значения атомарны.
Теперь мы можем начать процесс нормализации этой таблицы до второй нормальной формы.
Что для этого нам нужно сделать? Нам нужно внедрить первичный ключ.
Поработав немного с предметной областью, мы выясняем, что в этой организации каждому сотруднику присваивается уникальный табельный номер, который никогда не будет изменен.
Поэтому очевидно, что для таблицы, которая будет хранить список сотрудников, первичным ключом может выступать табельный номер, зная который мы можем четко идентифицировать каждого сотрудника, т.е. каждую строку нашей таблицы. Если бы такого табельного номера у нас не было или в рамках организации он мог повторяться (например, сотрудник уволился, и спустя время его номер присвоили новому сотруднику), то для первичного ключа мы могли бы создать искусственный ключ с целочисленным типом данных, который автоматически увеличивался бы в случае добавления новых записей в таблицу. Тем самым мы бы точно также четко идентифицировали каждую строку в таблице.
Таким образом, чтобы привести эту таблицу ко второй нормальной форме, мы должны добавить в нее еще один атрибут, т.е. столбец с табельным номером.
Таблица сотрудников во второй нормальной форме с простым первичным ключом.
| Табельный номер | ФИО | Должность | Подразделение | Описание подразделения |
| 1 | Иванов И.И. | Программист | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| 2 | Сергеев С.С. | Бухгалтер | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| 3 | John Smith | Продавец | Отдел реализации | Организация сбыта продукции |
В результате, так как наш первичный ключ является простым, а не составным, наша таблица автоматически переходит во вторую нормальную форму.
Иными словами, если первичный ключ простой (не составной, т.е. состоящий из одного столбца), второе требование, которое предъявляется к таблицам для перехода во вторую нормальную форму, выполнять не требуется, так как оно относится только к таблицам, у которых первичный ключ составной.
Пример приведения таблицы ко второй нормальной форме (первичный ключ составной)
А теперь давайте рассмотрим другую ситуацию, в которой первичный ключ у нас будет составным.
Представим, что наша организация выполняет несколько проектов, в которых может быть задействовано несколько участников, и нам необходимо хранить информацию об этих проектах. В частности мы хотим знать, кто участвует в каждом из проектов, продолжительность этого проекта, ну и возможно какие-то другие сведения. При этом мы понимаем, что отдельно взятый сотрудник может участвовать в нескольких проектах.
Для хранения таких данных мы создали следующую таблицу.
Таблица проектов организации в первой нормальной форме.
| Название проекта | Участник | Должность | Срок проекта (мес.) |
| Внедрение приложения | Иванов И.И. | Программист | 8 |
| Внедрение приложения | Сергеев С.С. | Бухгалтер | 8 |
| Внедрение приложения | John Smith | Менеджер | 8 |
| Открытие нового магазина | Сергеев С.С. | Бухгалтер | 12 |
| Открытие нового магазина | John Smith | Менеджер | 12 |
Как видим, она в первой нормальной форме, значит, мы можем пытаться приводить ее ко второй нормальной форме.
Как Вы помните, чтобы привести таблицу ко второй нормальной форме, необходимо определить для нее первичный ключ.
Посмотрев на эту таблицу, мы понимаем, что четко идентифицировать каждую строку мы можем только с помощью комбинации столбцов, например, «Название проекта» + «Участник», иными словами, зная «Название проекта» и «Участника», мы можем четко определить конкретную запись в таблице, т.е. каждое сочетание значений этих столбцов является уникальным.
Таким образом, мы определили первичный ключ и он у нас составной, т.е. состоящий их двух столбцов.
Таблица проектов организации. Внедрен составной первичный ключ.
| Название проекта | Участник | Должность | Срок проекта (мес.) |
| Внедрение приложения | Иванов И.И. | Программист | 8 |
| Внедрение приложения | Сергеев С.С. | Бухгалтер | 8 |
| Внедрение приложения | John Smith | Менеджер | 8 |
| Открытие нового магазина | Сергеев С.С. | Бухгалтер | 12 |
| Открытие нового магазина | John Smith | Менеджер | 12 |
Так как первичный ключ составной, нам необходимо проверить еще и второе требование, которое гласит, что «Все неключевые столбцы таблицы должны зависеть от полного ключа».
Другими словами, остальные столбцы, которые не входят в первичный ключ, должны зависеть от всего первичного ключа, т.е. от всех столбцов, а не от какого-то одного.
Чтобы это проверить, мы можем задать себе несколько вопросов.
Можем ли мы определить «Должность», зная только название проекта? Нет. Для этого нам необходимо знать и участника. Значит, пока все хорошо, по этой части ключа мы не можем четко определить значение неключевого столбца. Идем дальше и проверяем другую часть ключа.
Можем ли мы определить «Должность» зная только участника? Да, можем. Значит наш первичный ключ плохой, и требование второй нормальной формы не выполняется.
Что делать в этом случае?
В этом случае мы будем выполнять действие, которое выполняется, наверное, в 99% случаев на протяжении всего процесса нормализации базы данных – это декомпозиция.
Декомпозиция – это процесс разбиения одного отношения (таблицы) на несколько.
Чтобы декомпозировать нашу таблицу и привести базу данных к нормализованной форме, мы должны создать следующие таблицы.
| Идентификатор проекта | Название проекта | Срок проекта (мес.) |
| 1 | Внедрение приложения | 8 |
| 2 | Открытие нового магазина | 12 |
| Идентификатор участника | Участник | Должность |
| 1 | Иванов И.И. | Программист |
| 2 | Сергеев С.С. | Бухгалтер |
| 3 | John Smith | Менеджер |
Связь проектов и участников этих проектов.
| Идентификатор проекта | Идентификатор участника |
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
| 2 | 2 |
| 2 | 3 |
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.
Мы создали 3 таблицы:
После того как мы привели таблицы базы данных ко второй нормальной форме, мы можем переходить к приведению таблиц до третьей нормальной формы (3NF). Описание, требования и пример приведения таблиц до третьей нормальной формы мы рассмотрим в следующем материале.
На сегодня это все, надеюсь, материал был Вам полезен, пока!