Первая нормальная форма (1NF) базы данных
Приветствую Вас на сайте Info-Comp.ru! Сегодня мы с Вами поговорим о первой нормальной форме базы данных, в частности Вы узнаете, какие требования предъявляются к таблицам, чтобы база данных находилась в первой нормальной форме, и для наглядности мы, конечно же, рассмотрим пример.
Перед тем как переходить к процессу приведения таблиц базы данных к первой нормальной форме, необходимо чтобы эти таблицы соблюдали базовые принципы реляционной теории, подробнее об этом мы говорили в материале, который посвящен нулевой нормальной форме (UNF) или, как ее еще называют, – ненормализованной форме.
После того как таблицы приведены к правильному табличному виду, мы можем начинать процесс нормализации.
Требования первой нормальной формы (1NF)
Требование первой нормальной формы (1NF) очень простое и оно заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы.
Таким образом, чтобы база данных находилась в 1 нормальной форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы:
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.
Пример приведения таблицы к первой нормальной форме
Следующая таблица не находится даже в первой нормальной форме, так как у нас есть дублирующие строки (John Smith), а в некоторых ячейках хранятся списки значений (каждый номер телефона — это одно значение).
Таблица сотрудников в ненормализованном виде.
| Сотрудник | Контакт |
| Иванов И.И. | 123-456-789, 987-654-321 |
| Сергеев С.С. | Рабочий телефон 555-666-777, Домашний телефон 777-888-999 |
| John Smith | 123-456-789 |
| John Smith | 123-456-789 |
Чтобы привести эту таблицу к первой нормальной форме, необходимо удалить дублирующие строки, в ячейках хранить один номер телефона, а не список, а тип телефона (домашний или рабочий) вынести в отдельный столбец, так как столбцы хранят структурную информацию.
Таблица сотрудников в первой нормальной форме.
| Сотрудник | Телефон | Тип телефона |
| Иванов И.И. | 123-456-789 | |
| Иванов И.И. | 987-654-321 | |
| Сергеев С.С. | 555-666-777 | Рабочий телефон |
| Сергеев С.С. | 777-888-999 | Домашний телефон |
| John Smith | 123-456-789 |
Таким образом, главное правило первой нормальной формы звучит следующим образом
Строки, столбцы и ячейки в таблицах необходимо использовать строго по назначению.
Т.е. если ячейка таблицы по реляционной теории должна хранить одно атомарное значение, не нужно записывать в ячейку какой-то список значений или составное значение. Также не нужно создавать строки, которые уже есть в таблице и хранить в столбце значения разных типов данных.
На основе всего вышеизложенного можно сделать следующий вывод.
Если таблица создана с соблюдением всех реляционных принципов, значит, она уже находится в первой нормальной форме, таким образом, по сути абсолютно все реляционные таблицы находятся в первой нормальной форме. Если таблица создана без учета реляционных принципов, значит эта таблица не является реляционной.
После того как мы привели таблицы базы данных к первой нормальной форме, мы можем переходить к приведению таблиц до второй нормальной формы (2NF). Описание, требования и пример приведения таблиц до второй нормальной формы мы рассмотрим в следующем материале.
На сегодня это все, надеюсь, материал был Вам полезен, пока!
Нормализация отношений. Первая и вторая нормальные формы
Предисловие
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Любому специалисту, по роду своей деятельности так или иначе связанному с проектированием реляционных баз данных, полезно понимать и уметь осуществить нормализацию отношений. И этим постом хотелось бы начать небольшую серию публикаций, посвящённых нормальным формам, имеющую целью дать тем читателям Хабрахабра, которые по различным обстоятельствам ещё не освоили эту тему, возможность легко заполнить этот пробел в знаниях.
Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе. Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами. Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) 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НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
Требования нормальных форм базы данных
Приветствую всех посетителей сайта Info-Comp.ru! В этом материале представлен общий перечень всех требований каждой нормальной формы базы данных.
Описание нормальных форм базы данных
Ранее мы с Вами очень подробно и с примерами рассмотрели нормализацию базы данных и все нормальные формы базы данных, материала получилось очень много, поэтому для каждой нормальной формы на сайте представлена отдельная статья, однако за счет такого объема информации достаточно трудно ориентироваться в предъявляемых требованиях той или иной нормальной формы и видеть общую картину.
Именно поэтому я решил сформировать итоговый материал по нормальным формам базы данных, в котором кратко перечислю все требования каждой нормальной формы.
Если Вас интересует более детальное описание нормальных форм с примерами, то вот список статей, которые я упоминал:
Требования нормальных форм базы данных
Ну а сейчас давайте кратко рассмотрим требования всех нормальных форм базы данных.
Ненормализованная форма или нулевая нормальная форма (UNF)
Строки в таблицах не должны быть пронумерованы, т.е. порядок строк не имеет значения, так же как не имеет значения порядок столбцов.
Первая нормальная форма (1NF)
Вторая нормальная форма (2NF)
Третья нормальная форма (3NF)
Нормальная форма Бойса-Кодда (BCNF)
Четвертая нормальная форма (4NF)
Пятая нормальная форма (5NF)
Доменно-ключевая нормальная форма (DKNF)
Ограничение домена – это ограничение, предписывающее использование для определенного атрибута значений только из некоторого заданного домена (набора значений).
Ограничение ключа – это ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов представляет собой потенциальный ключ.
Шестая нормальная форма (6NF)
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней язык SQL рассматривается как стандарт, чтобы после прочтения данной книги можно было работать с языком SQL в любой системе управления базами данных.
На сегодня это все, надеюсь, материал был Вам полезен, пока!
Требования первой нормальной формы рбд
В основе реляционных баз данных лежит строгий математический аппарат, хорошо формализованные принципы создания баз данных и управления ими.
Все данные в реляционной базе данных хранится в однородных таблицах. Термин «однородный» означает, что в одной таблице все строки имеют одинаковую структуру. От правильности проектирования таблиц зависит простота эксплуатации созданной базы данных, возможность её развития в дальнейшем. Для получения «правильных» таблиц используется процесс нормализации.
В процессе нормализации данные группируются в таблицы, представляющие классы объектов и их взаимодействие.
Цели, которые преследуются при построении наиболее эффективной структуры данных:
Теория нормализации отношений работает с 5 нормальными формами таблиц. Каждая последующая форма должна отвечать требованиям предыдущих плюс некоторые дополнительные требования.
Первая нормальная форма (1НФ)
Таблица, находящаяся в первой нормальной форме должна отвечать следующим требованиям :
Для приведения к 1НФ можно использовать следующий алгоритм:
Пример. Пусть дана однотабличная БД
Поскольку один клиент может в течении одного дня сделать несколько заказов, таблица может содержать одинаковые строки. На один и тот же товар может поступить несколько заказов, и наконец, фирма производитель может поставлять несколько товаров. Таблица может содержать следующие данные:
1. Добавим в таблицу поле Номер заказа, что позволит однозначно идентифицировать каждый из заказов.
2. Таблица содержит три группы повторяющихся полей:
Вынесем их в отдельную таблицу Клиенты
Вынесем их в отдельную таблицу Товары
Вынесем их в отдельную таблицу Производители
3. В таблицу Клиенты добавим новое поле Номер клиента, которое будет однозначно идентифицировать каждую запись таблицы.
4. Т.к. связь между таблицами происходит по совпадающим полям, добавим в таблицу Заказы поля Номер клиента и Номер товара, а в таблицу Товары поле Номер производителя для организации связи.
Требования первой нормальной формы рбд
Итогом применения первой формы должно стать наличие для одного атрибута сущности только одного столбца в таблице, который при этом должен содержать скалярное значение.
Есть два похода к переходу к ненормализованной таблицы к первой нормальной форме. Первый способ называется выравниванием или flattaning. Он предполагает декомпозицию строки с повторяющимися группами данных, при котором для каждой повторяющейся группы создается своя строка. Полученная в результате таблица будет содержать атомарные значения для каждого из атрибутов. Хотя в то же время этот подход увеличит избыточность данных.
Второй подход предполагает, что один атрибут или группа атрибутов назначаются ключом ненормализованной таблицы, а затем повторяющиеся группы удаляются из таблицы и помещаются в отдельную таблицу вместе с копиями ключа из исходной таблицы.
Рассмотрим применение нормализации на примере. Пусть у нас есть система, которая описывается следующей информацией:
Вначале определим ненормализованную таблицу StudentCourses, которая содержит всю эту информацию:
Для каждого студента определен уникальный идентификатор StudentId, а также атрибут Name (имя), Emails (все электронные адреса), Course1 /Course2(курс), Date1/Date2 (дата поступления), Teacher1/Teacher2 (преподаватель). Также чтобы различать преподавателей (так как теоретически могут быть преподаватели с одной и той же фамилией), добавлен атрибут TeacherId1/TeacherId2. Для курсов такой идентификатор не требуется, так как в нашем случае название курса уникально.
Поскольку Том записан сразу на два курса, то несколько атрибутов пришлось дублировать. Но что будет, когда Том в стремлении получить никому не нужные сертификаты запишется еще на десяток курсов?
Эта таблица представляет прекрасный пример отклонения от первой нормальной формы. В первую очередь мы видим группу повторяющихся атрибутов, которые представляют данные по одному курсу: Course, Date, TeacherId, Teacher. Эти атрибуты представляют повторяющуюся группу, которую можно условно назвать StudentCourse.
StudentCourse = (Course, Date, TeacherId, Teacher)
Для избавления от первой повторяющейся группы атрибутов применим первый подход: создадим для каждой повторяющейся группы отдельную строку.
| StudentId | Name | Emails | CourseId | Course | Date | TeacherId | Teacher |
| 1 | Том | 1 | Математика | 11/06/2017 | 1 | Смит | |
| 1 | Том | 2 | JavaScript | 14/06/2017 | 2 | Адамс | |
| 2 | Сэм | sam@gmail.com sam@hotmail.com | 3 | Алгоритмы | 12/06/2017 | 2 | Адамс |
| 3 | Боб | 1 | Математика | 13/06/2017 | 1 | Смит |
| StudentId | |
| sam@gmail.com | 2 |
| sam@hotmail.com | 2 |
Так как электронный адрес в принципе уникален, то его можно сделать первичным ключом.
| StudentId | Name | CourseId | Course | Date | TeacherId | Teacher |
| 1 | Том | 1 | Математика | 11/06/2017 | 1 | Смит |
| 1 | Том | 2 | JavaScript | 14/06/2017 | 2 | Адамс |
| 2 | Сэм | 3 | Алгоритмы | 12/06/2017 | 2 | Адамс |
| 3 | Боб | 1 | Математика | 13/06/2017 | 1 | Смит |
Теперь у нас нет повторяющихся столбцов, но увеличилась избыточность данных, так как для студента Том определено уже две строки в таблице, и соответственно Id повторяется. Но тем не менее 1-я нормальная форма применена.
В принципе можно отметить, что если повторяющиеся группы содержат уникальные значения для каждой строки таблицы (как в случае с электронными адресами), то мы имеем дело с потенциальной связью один ко многим. Если же повторяющиеся группы содержат неуникальные значения, которые могут иметь разные строки таблицы (как в случае с атрибутами курсов), то это скрывается потенциальная связь многие ко многим.