Первая нормальная форма
Переменная отношения находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.
В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение.
Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1NF. В соответствии с определением К. Дж. Дейта для такого случая, таблица нормализована (эквивалентно — находится в первой нормальной форме) тогда и только тогда, когда она является прямым и верным представлением некоторого отношения. Конкретнее, рассматриваемая таблица должна удовлетворять следующим пяти условиям:
- Нет упорядочивания строк сверху-вниз (другими словами, порядок строк не несет в себе никакой информации).
- Нет упорядочивания столбцов слева-направо (другими словами, порядок столбцов не несет в себе никакой информации).
- Нет повторяющихся строк.
- Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего).
- Все столбцы являются обычными [1] .
«Обычность» всех столбцов таблицы означает, что в таблице нет «скрытых» компонентов, которые могут быть доступны только в вызове некоторого специального оператора взамен ссылок на имена регулярных столбцов, или которые приводят к побочным эффектам для строк или таблиц при вызове стандартных операторов. Таким образом, например, строки не имеют идентификаторов кроме обычных значений потенциальных ключей (без скрытых «идентификаторов строк» или «идентификаторов объектов»). Они также не имеют скрытых временных меток [1] .
Пример
Исходная ненормализованная (то есть не являющаяся правильным представлением некоторого отношения) таблица:
| Сотрудник | Номер телефона |
|---|---|
| Иванов И. И. | 283-56-82 390-57-34 |
| Петров П. П. | 708-62-34 |
Таблица, приведённая к 1NF (являющаяся правильным представлением некоторого отношения):
| Сотрудник | Номер телефона |
|---|---|
| Иванов И. И. | 283-56-82 |
| Иванов И. И. | 390-57-34 |
| Петров П. П. | 708-62-34 |
Атомарность атрибутов
Вопрос об атомарности атрибутов решается на основе семантики данных, то есть их смыслового значения. Атрибут атомарен, если его значение теряет смысл при любом разбиении на части или переупорядочивании. Следовательно, если какой-либо способ разбиения на части не лишает атрибут смысла, то атрибут неатомарен.
Одно и то же значение может быть атомарным или неатомарным в зависимости от смысла этого значения. Например, значение «4286» является
- атомарным, если его смысл — «пин-код кредитной карты» (при разбиении на части или переупорядочивании смысл теряется)
- неатомарным, если его смысл — «набор цифр» (при разбиении на части или переупорядочивании смысл не теряется)
Хорошим способом принятия решения о необходимости разбиения атрибута на части является вопрос: «будут ли части атрибута использоваться по отдельности?». Если да, то атрибут следует разделить (но так, чтобы сохранились осмысленные части атрибута). Далее необходимо снова задаться тем же вопросом для новой структуры и так до тех пор, пока не останется атрибутов, допускающих разбиение.
Примеры неатомарного атрибута, часто встречающиеся на практике: составные поля в виде строки идентификаторов, разделённых, скажем, запятыми: 100, 32, 168, 1045.
Исходное назначение 1NF
Исходное назначение 1NF, которую предложил Э. Ф. Кодд в статье «Реляционная модель данных для больших совместно используемых банков данных» [2] («A Relational Model of Data for Large Shared Data Banks» [3] ), вообще не было связано с борьбой с аномалиями или избыточностью. Кодд предложил использовать «простые домены» (simple domains) только для облегчения будущей программной реализации, а именно:
- для облегчения хранения отношений в виде двумерных массивов
Отношение, все домены которого являются простыми, может быть представлено при хранении двухмерным массивом с однородными столбцами.
Оригинальный текст (англ.)
A relation whose domains are all simple can be represented in storage by a two-dimensional column-homogeneous array.
- для облегчения передачи данных в гетерогенных системах
Простота представления отношений массивами, осуществимая в случае приведения всех отношений в нормальную форму, предоставляет преимущества не только при хранении, но также при передаче больших объёмов данных между системами, использующими во многом отличные представления данных.
Оригинальный текст (англ.)
The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of the data.
Примечания
- ↑ 12 С. J. Date. What First Normal Form Really Means //С. J. Date. Date on database: Writings 2000—2006, Apress, 2006, ISBN 978-1-59059-746-0
- ↑Е. Ф. Кодд. Реляционная модель данных для больших совместно используемых банков данных (перевод М. Р. Когаловского)
- ↑ Codd, E.F. (1970). «A Relational Model of Data for Large Shared Data Banks». Communications of the ACM13 (6): 377–387. DOI:10.1145/362384.362685.
Литература
- Когаловский М.Р. Энциклопедия технологий баз данных. — М .: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4
- Кузнецов С. Д. Основы баз данных. — 2-е изд. — М .: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2
- Дейт К. Дж.Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М .: Вильямс, 2005. — 1328 с. — ISBN 5-8459-0788-8 (рус.) 0-321-19784-4 (англ.)
- Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М .: Вильямс, 2003. — 1436 с. — ISBN 0-201-70857-4
- Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. — ISBN 5-8459-0384-X
- C. J. Date Date on Database: Writings 2000–2006. — Apress, 2006. — 566 с. — ISBN 978-1-59059-746-0, 1-59059-746-X
- Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
- Проставив сноски, внести более точные указания на источники.
- Реляционная модель данных
- Теоретические основы баз данных
Wikimedia Foundation . 2010 .
- Первая мировая война на Средиземном море
- Первая палатализация
Полезное
Смотреть что такое «Первая нормальная форма» в других словарях:
- Нормальная форма Бойса — Кодда — (англ. Boyce Codd normal form; сокращённо BCNF) одна из возможных нормальных форм отношения в реляционной модели данных. Иногда нормальную форму Бойса Кодда называют усиленной третьей нормальной формой, поскольку она во всех отношениях… … Википедия
- Нормальная форма Бойса — Кодда (англ. Boyce Codd normal form; сокращённо BCNF) одна из возможных нормальных форм отношения в реляционной модели данных. Иногда нормальную форму Бойса Кодда называют усиленной третьей нормальной формой, поскольку она во всех… … Википедия
- Нормальная форма — У этого термина существуют и другие значения, см. Нормальная форма (значения). Нормальная форма свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным… … Википедия
- Нормальная форма базы данных — Третья нормальная форма (3NF) одна из возможных нормальных форм таблицы реляционной базы данных. Третья нормальная форма является достаточной при решении большинства практических задач, и процесс проектирования реляционной базы данных, как… … Википедия
- Нормальная форма Бойса—Кодда — Основная статья: Нормальная форма Нормальная форма Бойса Кодда (BCNF) одна из возможных нормальных форм таблицы реляционной базы данных. Это модификация третьей нормальной формы (в некоторых источниках именно 3NF называется формой Бойса Кодда).… … Википедия
- Нормальная форма Бойса-Кодда — Основная статья: Нормальная форма Нормальная форма Бойса Кодда (BCNF) одна из возможных нормальных форм таблицы реляционной базы данных. Это модификация третьей нормальной формы (в некоторых источниках именно 3NF называется формой Бойса Кодда).… … Википедия
- Третья нормальная форма — (англ. Third normal form; сокращённо 3NF) одна из возможных нормальных форм отношения реляционной базы данных. 3NF была изначально сформулирована Э. Ф. Коддом в 1971 году. Содержание 1 Определение … Википедия
- Вторая нормальная форма — Основная статья: Нормальная форма Вторая нормальная форма (англ. Second normal form; сокращённо 2NF) одна из возможных нормальных форм таблицы реляционной базы данных. Содержание 1 Определение 2 Пример … Википедия
- Пятая нормальная форма — Основная статья: Нормальная форма Пятая нормальная форма (5NF) одна из возможных нормальных форм отношения реляционной базы данных. Содержание 1 Определение 1.1 Декомпозиция без потерь … Википедия
- Четвертая нормальная форма — Основная статья: Нормальная форма Четвёртая нормальная форма (4NF) одна из возможных нормальных форм таблицы реляционной базы данных. Определение Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных… … Википедия
- Обратная связь: Техподдержка, Реклама на сайте
- �� Путешествия
Экспорт словарей на сайты, сделанные на PHP,
WordPress, MODx.
- Пометить текст и поделитьсяИскать в этом же словареИскать синонимы
- Искать во всех словарях
- Искать в переводах
- Искать в ИнтернетеИскать в этой же категории
Нормальные формы: первая и вторая
Первая и вторая нормальные формы разработаны Эдгаром Коддом и являются достаточно «самоочевидными». Самоочевидность заключается в том, что отношения в первой и второй нормальной формах обладают интуитивно понятными базовыми свойствами, которые логично требовать от отношений, используемых в рамках баз данных.
Первая нормальная форма
Первая нормальная форма эквивилентна отношению в строгом смысле этого слова. Каждый из данных критериев отвечает за запрет конструкций определенного вида.
Запрещенные конструкции
Повторяющиеся группы
| CourseId | Lecturer | Phone (1) | Phone (2) |
|---|---|---|---|
| 1 | Корнеев Г. А. | 111-11-11 | |
| 2 | Киракозов А. Х. | 222-22-22 | 333-33-33 |
| 3 | Кудряшов Б. Д. | 444-44-44 | 555-55-55 |
| 4 | Сегаль А. С. | 666-66-66 |
В отношениях такого вида сложно обеспечивать консистентность данных. Рассмотрим пример выше. Первая возникающая проблема заключается в том, что при появлении преподавателя с более, чем двумя телефонами, придется изменять целиком структуру отношения. Вторая проблема – на выполнение запроса «проверить, что никакие два преподавателя не имеют одинаковый телефон» и других запросов, аналогичных данному, потребуется экспоненциальное от количества полей с данными о телефонах время.
Неатомарные атрибуты
| CourseId | Lecturer | Phones |
|---|---|---|
| 1 | Корнеев Г. А. | 111-11-11 |
| 2 | Киракозов А. Х. | 222-22-22 |
| 333-33-33 | ||
| 3 | Кудряшов Б. Д. | 444-44-44 |
| 555-55-55 | ||
| 4 | Сегаль А. С. | 666-66-66 |
Потенциальным решением проблемы повторяющихся групп является группировка атрибутов по смыслу. На примере показано, как несколько телефонов из прошлого отношения были сгруппированы в единый атрибут, что позволяет не изменять структуру отношения в зависимости от максимального количества телефонов у одного человека. Однако проблема большого времени работы проверки корректности данных все еще остается.
Отсутствие ключа
Отношение без ключа формально не является отношением. Отсутствие ключа говорит о повторяющихся записях, а отношения рассматриваются как подмножества декартового произведения других множеств, что в явном виде запрещает повторы.
Приведение в 1НФ
Для того, чтобы привести произвольное отношение [math]R[/math] в 1НФ, достаточно:
- Рассмотреть все наборы атрибутов, имеющих одинаковый смысл
- Для каждого фиксированного значения оставшихся атрибутов сделать по записи на каждое значение выбранных:
- рассмотрим повторяющиеся атрибуты [math]A_1, \ldots, A_k[/math]
- рассмотрим оставшиеся атрибуты [math]B_1, \ldots, B_n[/math]
- построим такое отношение [math]T[/math] на атрибутах [math]B_1, \ldots, B_n, A[/math] , что [math]\ \in T \Longleftrightarrow \ \in \pi_R \land a \in \bigcup\limits_^k \pi_R[/math]
- Аналогичную процедуру повторить для всех неатомарных атрибутов
Отношение, использованое в примерах выше, после приведения в 1НФ будет выглядеть как
| CourseId | Lecturer | Phone |
|---|---|---|
| 1 | Корнеев Г. А. | 111-11-11 |
| 2 | Киракозов А. Х. | 222-22-22 |
| 2 | Киракозов А. Х. | 333-33-33 |
| 3 | Кудряшов Б. Д. | 444-44-44 |
| 3 | Кудряшов Б. Д. | 555-55-55 |
| 4 | Сегаль А. С. | 666-66-66 |
Аномалии
Переход в 1НФ не уменьшает выразительную способность «разрешенных» отношений, но при этом исправляет только самые простые аномалии, поэтому в отношениях в 1НФ, не приведенных хотя бы во 2НФ, могут возникать аномалии более сложного вида.
| Определение: |
| Аномалия вставки – зависимость возможности записать обладающие собственным независимым смыслом данные от наличия другой связанной информации. |
В рассмотренном выше примере невозможно записать информацию о телефоне конкретного преподавателя, если он не читает ни один курс (таким образом, возможность записать [math]\mathrm[/math] для конкретного [math]\mathrm[/math] зависит от наличия соответствующего [math]\mathrm[/math] , хотя напрямую они не зависят друг от друга).
| Определение: |
| Аномалия удаления – невозможность удалить часть данных, не удалив никакую связанную с ней информацию. |
В рассмотренном выше, опять же, примере невозможно удалить информацию о том, что конкретный преподаватель читает конкретный курс, не потеряв его номер телефона (как и в случае с аномалией вставки, возможность хранить [math]\mathrm[/math] зависит от существования соответствующего [math]\mathrm[/math] ).
| Определение: |
| Аномалия изменения – ситуация, в которой частичное изменение данных нарушает целостность базы данных. |
В рассмотренном примере если один преподаватель ведет один курс и имеет два телефона, при изменении [math]\mathrm[/math] в одной из соответствующих ему записей будет невозможно восстановить какой курс на самом деле ведет преподаватель (записи с разными [math]\mathrm[/math] , но одинаковыми [math]\mathrm[/math] и [math]\mathrm[/math] , должны всегда поддерживаться в таком же состоянии).
Вторая нормальная форма
Вторая нормальная форма позволяет избавиться от некоторых аномалий, возникающих в отношениях в 1НФ.
Запрещенные конструкции
Во 2НФ запрещено, чтобы какие-либо атрибуты функционально зависели от части ключа. Рассмотрим следующий пример, уже приведенный в 1НФ:
| CourseId | Year | Lecturer | Exam |
|---|---|---|---|
| 1 | 2020 | Корнеев Г. А. | yes |
| 2 | 2019 | Киракозов А. Х. | no |
| 2 | 2020 | Киракозов А. Х. | no |
| 3 | 2019 | Левина А. Б. | yes |
| 3 | 2020 | Чепурной А. И. | yes |
В данном отношении можно выделить следующие функциональные зависимости: [math]\mathrm \rightarrow \mathrm[/math] (наличие экзамена зависит только от предмета) и [math]\mathrm, \mathrm \rightarrow \mathrm[/math] (каждый год только один преподаватель читает конкретный предмет). Таким образом, ключ в данном отношении – [math]\mathrm, \mathrm[/math] , но при этом [math]\mathrm[/math] зависит только от части ключа.
Отношения в 1НФ имеют аномалии вставки и удаления (нельзя хранить информацию про экзамен, не зная лектора) и изменения (можно изменить информацию про экзамен по предмету только для одного года). От этих аномалий можно избавиться, если убрать функциональные зависимости от части ключа.
Приведение во 2НФ
Отношение в 1НФ приводится к 2НФ декомпозицией по «мешающим» функциональным зависимостям. На примере выше такая зависимость только одна – [math]\mathrm \rightarrow \mathrm[/math] .
| Определение: |
| Декомпозиция отношения [math]R[/math] , состоящего из наборов атрибутов [math]A, B, C[/math] , по функциональной зависимости [math]A \rightarrow B[/math] – пара отношений [math]\pi_ R[/math] и [math]\pi_ R[/math] . |
Декомпозиция рассмотренного примера по «лишней» функциональной зависимости дает следующий результат:
| CourseId | Year | Lecturer |
|---|---|---|
| 1 | 2020 | Корнеев Г. А. |
| 2 | 2019 | Киракозов А. Х. |
| 2 | 2020 | Киракозов А. Х. |
| 3 | 2019 | Левина А. Б. |
| 3 | 2020 | Чепурной А. И. |
| CourseId | Exam |
|---|---|
| 1 | yes |
| 2 | no |
| 3 | yes |
После данной декомпозиции, как можно заметить, информация об экзамене по предмету и информация о преподавателе по предмету в конкретный год стали независимыми. Это значит, что больше нет аномалий, свойственных 1НФ: вставка, удаление и изменение данных не затрагивают не связанную с ними напрямую информацию.
Аномалии
Аномалия, свойственная 2НФ, возникает, когда какой-то атрибут зависит от ключа транзитивно через множество неключевых атрибутов. Рассмотрим следующий пример:
| CourseId | Year | Lecturer | Phone |
|---|---|---|---|
| 1 | 2020 | Корнеев Г. А. | 111-11-11 |
| 2 | 2019 | Киракозов А. Х. | 222-22-22 |
| 2 | 2020 | Киракозов А. Х. | 222-22-22 |
| 3 | 2019 | Левина А. Б. | 333-33-33 |
| 3 | 2020 | Чепурной А. И. | 444-44-44 |
В нем есть две базовые функциональные зависимости: [math]\mathrm, \mathrm \rightarrow \mathrm[/math] и [math]\mathrm \rightarrow \mathrm[/math] . Несмотря на то, что данное отношение находится во 2НФ, в нем все еще имеют место все три аномалии 1НФ – аномалии вставки, удаления и изменения (информация о телефонах и о преподавании никак не разделена). Для исправления аномалий 2НФ отношение переводят в третью нормальную форму и выше.
Нормализация отношений. Первая и вторая нормальные формы
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных. Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями. При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Любому специалисту, по роду своей деятельности так или иначе связанному с проектированием реляционных баз данных, полезно понимать и уметь осуществить нормализацию отношений. И этим постом хотелось бы начать небольшую серию публикаций, посвящённых нормальным формам, имеющую целью дать тем читателям Хабрахабра, которые по различным обстоятельствам ещё не освоили эту тему, возможность легко заполнить этот пробел в знаниях.
Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе. Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами. Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) 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НФ) тогда и только тогда, когда оно находится в первой нормальной форме и каждый его неключевой атрибут неприводимо зависим от первичного ключа.
Литература
Для более глубокого и основательного изучения рассмотренной темы, рекомендуется книга «Введение в системы баз данных» Криса Дж. Дейта, на основе материалов которой и была написана данная статья.
- реляционные базы данных
- нормализация отношений
- нормальные формы
- первая нормальная форма
- 1НФ
- вторая нормальная форма
- 2НФ
Первая нормальная форма — Основы реляционных баз данных
Чтобы облегчить считываемость информации в таблице, программисты приводят данные, которые представлены в реляционной модели, к нормальной форме. В этом уроке мы узнаем, что это за форма, а также разберем ее первый уровень.
Нормальная форма
Возьмем для примера интернет-магазин, в котором продается электроника. Когда пользователь делает заказ, в базу данных заносится запись об этом. В нее входит вся необходимая информация: данные пользователя, какой товар он купил, сколько он стоил и адрес доставки. Затем эти данные используются всеми подразделениями интернет-магазина — от бухгалтеров до службы доставки.
Таблица order_items
| first_name | last_name | address | item | price |
|---|---|---|---|---|
| Сергей | Иванов | Москва, ул. Промышленная | утюг | 15.00 |
| Иван | Петров | Самара, ул. Энгельса | кофеварка | 5000.00 |
| Виктор | Сидоров | Омск, ул. Дворцовая | утюг, телевизор | 1000.00, 6500.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
В первой строке последнего столбца цена указана в долларах, в остальных записях — это рубли. Последняя запись повторяет предыдущую, потому что этот заказ выполнил тот же человек, но сделал это в другое время.
В этой табличке много повторяющейся информации. Приведем ее к правильной структуре с точки зрения реляционной модели. Для этого приведем данные к нормальной форме — это требования, которые минимизируют избыточность данных, потенциально приводящих к логическим ошибкам.
Всего существует шесть нормальных форм, которые включают определенные требования. С каждым следующим уровнем требования все жестче, так как включают в себя предыдущие уровни.
В рамках курса мы разберем три нормальные формы. В этом уроке познакомимся с первой.
Первая нормальная форма
Первая нормальная форма сводится к трем правилам:
- Каждая ячейка таблицы может хранить только одно значение
- Все данные в одной колонке могут быть только одного типа
- Каждая запись в таблице должна однозначно отличаться от других записей
Разберем каждое правило подробнее.
Каждая ячейка – одно значение
Вернемся к примеру выше. У одной записи поля item и price содержат два значения через запятую. У такого способа организации данных много недостатков. Например, пропадает возможность делать обычную выборку по условиям:
-- Как найти записи о всех проданных утюгах? SELECT * FROM order_items WHERE item = "?"; Другая проблема связана с типами данных. Поле price в таблице order_items имеет числовой тип (numeric). Если мы захотим хранить там более одного значения, то тип превратится в строковый, а все данные станут обычными строками.
При такой организации невозможно проверить корректность данных и формат числа. Становится проблематично выполнить агрегирующие запросы, например, считать выручку за определенный месяц одним запросом.
Чтобы избавиться от перечислений в ячейках, можно создать новые записи:
| first_name | last_name | address | item | price |
|---|---|---|---|---|
| Сергей | Иванов | Москва, ул. Промышленная | утюг | 15.00 |
| Иван | Петров | Самара, ул. Энгельса | кофеварка | 5000.00 |
| Виктор | Сидоров | Омск, ул. Дворцовая | утюг | 1000.00 |
| Виктор | Сидоров | Омск, ул. Дворцовая | телевизор | 6500.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
Теперь на одной строке находится информация только по одному товару. Так мы избавились от перечислений в поле, что позволит выполнять агрегирующие запросы, а также не будет путаницы с типами данных.
Данные одного типа
Снова вернемся к таблице. Верхняя запись в ней содержит цену в долларах, хотя все остальные цены указаны в рублях. Технически база никак не укажет на это. И доллары, и рубли представлены числами, но с точки зрения программы у этих чисел разная природа.
Разные данные в рамках одного поля тоже не дают выполнить агрегирующие запросы, например, поиск сумм, максимального, минимального. Еще усложняется обработка данных на уровне кода. В коде придется каким-то образом понимать, что из себя представляют данные.
Вот еще несколько примеров с похожей ситуацией:
- Хранение даты свадьбы в поле «день рождения»
- Хранение номера телефона вместо адреса в поле «адрес»
Исправленная версия таблицы:
| first_name | last_name | address | item | price |
|---|---|---|---|---|
| Сергей | Иванов | Москва, ул. Промышленная | утюг | 1000.00 |
| Иван | Петров | Самара, ул. Энгельса | кофеварка | 5000.00 |
| Виктор | Сидоров | Омск, ул. Дворцовая | утюг | 1000.00 |
| Виктор | Сидоров | Омск, ул. Дворцовая | телевизор | 6500.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
Мы сконвертировали цену утюга в первой строке из долларов в рубли. Теперь у данных в поле price один тип. Так программе будет легче выполнять агрегирующие запросы.
Уникальные записи
Последние две записи в таблице выглядят идентично, хотя это два разных заказа. Их сделал один человек, но в разное время:
| first_name | last_name | address | item | price |
|---|---|---|---|---|
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
| Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
Реляционная модель требует от нас уникальности каждой записи. Иначе нельзя понять, что к чему относится и с какой записью нужно работать при изменениях. Можно начать править не то и потерять важную информацию. При этом мы не можем полагаться на порядок данных внутри таблицы, так как он не гарантирован.
Реализовать уникальность можно несколькими способами, например, добавить новое поле с датой заказа, которое сделает запись уникальной. Этот способ не очень надежный и не очень удобный в работе. Придется постоянно анализировать весь набор полей.
Лучше добавить первичный ключ (PRIMARY KEY) — поле или набор полей, которые содержат уникальное значение для каждой записи. Первичный ключ не может меняться, его значение однозначно определяет любую запись в таблице.
Разберем два вида первичного ключа:
- Естественный — когда используются значения из окружающего мира, например, email, ФИО или паспортные данные. При этом нужно убедиться, что ключ не будет повторяться. Такие первичные ключи используют редко из-за их ненадежности. Часто они не уникальны и могут изменяться или повторяться. Например, номер паспорта меняется при смене документа
- Суррогатный — когда используются автоматически генерируемые уникальные значения. Такой ключ поддерживается любой базой данных «из коробки». Иногда это просто числа, а иногда — сложные число-буквенные строки или хеши
Добавим в нашу таблицу первичный ключ:
| id | first_name | last_name | address | item | price |
|---|---|---|---|---|---|
| 8 | Сергей | Иванов | Москва, ул. Промышленная | утюг | 1000.00 |
| 2 | Иван | Петров | Самара, ул. Энгельса | кофеварка | 5000.00 |
| 7 | Виктор | Сидоров | Омск, ул. Дворцовая | утюг | 1000.00 |
| 4 | Виктор | Сидоров | Омск, ул. Дворцовая | телевизор | 6500.00 |
| 9 | Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
| 6 | Сергей | Иванов | Москва, ул. Матросова | ноутбук | 20000.00 |
Первичный ключ принято создавать первым полем с названием id. Для первичного ключа обязательно указывать PRIMARY KEY в описании таблицы:
-- Первичный ключ только один на таблицу CREATE TABLE products ( id bigint PRIMARY KEY, first_name varchar(255), last_name varchar(255), address varchar(255), item varchar(255), price numeric -- специальный тип данных, который подходит под работу с деньгами. Обеспечивает высокую точность при расчетах. ); Такой ключ все еще нужно формировать самостоятельно, но теперь база данных сама следит за уникальностью. При попытке создать запись с повторяющимися первичными ключами возникнет ошибка.
Выводы
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно
- 130 курсов, 2000+ часов теории
- 1000 практических заданий в браузере
- 360 000 студентов
Наши выпускники работают в компаниях: