Первая нормальная форма
Первая нормальная форма ( 1NF ) является свойством отношения в реляционной базе данных . Отношение находится в первой нормальной форме тогда и только тогда, когда ни одна атрибутивная область не содержит отношений в качестве элементов. [1] Или, более неформально, ни один столбец таблицы не может иметь таблицы в качестве значений. Нормализация базы данных — это процесс представления базы данных в терминах отношений в стандартных нормальных формах, где первая норма является минимальным требованием. SQL-92 не поддерживает создание или использование столбцов с табличными значениями, а это означает, что при использовании только «традиционных функций реляционных баз данных» (за исключением расширений, даже если они были позже стандартизированы), большинство реляционных баз данных по необходимости будут находиться в первой нормальной форме. Системы баз данных, которые не требуют первой нормальной формы, часто называют системами NoSQL . Новые стандарты SQL, такие как SQL:1999, начали разрешать так называемые неатомарные типы, которые включают составные типы . Даже более новые версии, такие как SQL:2016, поддерживают JSON .
Обзор
[ редактировать ]В иерархической базе данных запись может содержать наборы дочерних записей, известных как повторяющиеся группы или атрибуты с табличными значениями. Если такая модель данных представлена в виде отношений, повторяющаяся группа будет атрибутом, значение которого само по себе является отношением. Первая нормальная форма устраняет вложенные отношения, превращая их в отдельные отношения «верхнего уровня», связанные с родительской строкой через внешние ключи, а не через прямое включение.
Целью этой нормализации является повышение гибкости и независимости данных , а также упрощение языка данных. Это также открывает возможности для дальнейшей нормализации, которая устраняет избыточность и аномалии.
Большинство систем управления реляционными базами данных не поддерживают вложенные записи, поэтому по умолчанию таблицы находятся в первой нормальной форме. В частности, SQL не имеет никаких средств для создания или использования вложенных таблиц. Поэтому нормализация к первой нормальной форме будет необходимым шагом при перемещении данных из иерархической базы данных в реляционную базу данных.
Обоснование
[ редактировать ]Обоснование нормализации до 1NF: [2]
- Позволяет представлять, хранить и обмениваться реляционными данными в виде обычных двумерных массивов. Поддержка вложенных отношений потребует более сложных структур данных.
- Упрощает язык данных, поскольку любой элемент данных можно идентифицировать только по имени отношения, имени атрибута и ключу. Для поддержки вложенных отношений потребуется более сложный язык с поддержкой иерархических путей к данным для обращения к вложенным элементам данных.
- Представление отношений с использованием внешних ключей является более гибким, поскольку иерархическая модель может представлять только отношения «один ко многим» .
- Поскольку поиск элементов данных не связан напрямую с иерархией «родители-потомки», база данных более устойчива к структурным изменениям с течением времени.
- Делает возможным дальнейшие уровни нормализации, которые устраняют избыточность данных и аномалии.
Недостатки и критика
[ редактировать ]- Ухудшение производительности для некоторых операций. В иерархической модели вложенные записи физически хранятся после родительской записи, что означает, что все поддерево можно получить за одну операцию чтения. В форме 1NF потребуется операция соединения для каждого типа записи, что может быть дорогостоящим, особенно для сложных деревьев. По этой причине базы данных документов избегают 1NF.
- Объектно-ориентированные языки представляют состояние времени выполнения в виде деревьев или ориентированных графов объектов, связанных указателями или ссылками. Это не совсем соответствует реляционной базе данных 1NF. Эту проблему иногда называют несоответствием объектно-реляционного импеданса , и которую библиотеки объектно-реляционного преобразователя (ORM) пытаются преодолеть.
- 1NF интерпретируется как не допускающий использования сложных типов данных для значений. Однако это остается открытым для интерпретации, и CJDate утверждает, что значения могут быть сколь угодно сложными объектами. [ нужна ссылка ]
История
[ редактировать ]Первая нормальная форма была введена в 1970 году Эдгаром Ф. Коддом в статье «Реляционная модель данных для больших общих банков данных» , хотя первоначально она называлась просто «Нормальная форма». Она была переименована в «Первую нормальную форму», когда в 1971 году в статье « Дальнейшая нормализация реляционной модели» были введены дополнительные нормальные формы . [3]
Примеры
[ редактировать ]Следующие сценарии сначала иллюстрируют, как конструкция базы данных может нарушать первую нормальную форму, а затем следуют примеры, которые соответствуют этому требованию.
Проекты, нарушающие 1NF
[ редактировать ]Эта таблица транзакций клиентов по кредитным картам не соответствует первой нормальной форме:
| Клиент | Идентификатор клиента | Транзакции | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Авраам | 1 |
| ||||||||||||
| Исаак | 2 |
| ||||||||||||
| Джейкоб | 3 |
|
Каждому клиенту соответствует «повторяющаяся группа» транзакций. Такая конструкция может быть представлена в иерархической базе данных , но не в базе данных SQL, поскольку SQL не поддерживает вложенные таблицы.
Автоматизированная оценка любого запроса, касающегося транзакций клиентов, обычно включает два этапа:
- Распаковка групп транзакций одной или нескольких клиентов, позволяющая исследовать отдельные транзакции в группе, и
- Получение результата запроса по результатам первого этапа
Например, чтобы узнать денежную сумму всех транзакций, произошедших в октябре 2003 года для всех клиентов, системе необходимо знать, что она должна сначала распаковать группу «Транзакции» каждого клиента, а затем суммировать суммы всех полученных таким образом транзакций. где Дата сделки приходится на октябрь 2003 года.
Одним из важных открытий Кодда было то, что структурную сложность можно уменьшить. Уменьшенная структурная сложность дает пользователям, приложениям и СУБД больше возможностей и гибкости для формулирования и оценки запросов. Более нормализованный эквивалент приведенной выше структуры может выглядеть так:
Конструкции, соответствующие 1NF
[ редактировать ]Чтобы привести модель к первой нормальной форме, мы можем провести нормализацию. Нормализация (к первой нормальной форме) — это процесс, в котором атрибуты с непростыми областями извлекаются для разделения автономных отношений. Извлеченные отношения дополняются внешними ключами, ссылающимися на первичный ключ отношения, которое их содержит. Этот процесс можно рекурсивно применять к сложным доменам, вложенным на несколько уровней. [4]
В этом примере идентификатор клиента является первичным ключом содержащих отношений и поэтому будет добавлен в качестве внешнего ключа к новому отношению:
| Клиент | Идентификатор клиента |
|---|---|
| Авраам | 1 |
| Исаак | 2 |
| Джейкоб | 3 |
| Идентификатор клиента | Идентификатор транзакции | Дата | Количество |
|---|---|---|---|
| 1 | 12890 | 2003-10-14 | −87 |
| 1 | 12904 | 2003-10-15 | −50 |
| 2 | 12898 | 2003-10-14 | −21 |
| 3 | 12907 | 2003-10-15 | −18 |
| 3 | 14920 | 2003-11-20 | −70 |
| 3 | 15003 | 2003-11-27 | −60 |
В измененной структуре первичным ключом является {Идентификатор клиента} в первом отношении и {Идентификатор клиента, Идентификатор транзакции} во втором отношении.
Теперь каждая строка представляет собой отдельную транзакцию по кредитной карте, и СУБД может получить интересующий ответ, просто найдя все строки, дата которых приходится на октябрь, и суммируя их суммы. Структура данных помещает все значения в равные условия, предоставляя каждое из них непосредственно СУБД, поэтому потенциально каждое из них может напрямую участвовать в запросах; тогда как в предыдущей ситуации некоторые значения были встроены в структуры более низкого уровня, с которыми приходилось обращаться особым образом. Соответственно, нормализованная конструкция пригодна для обработки запросов общего назначения, а ненормализованная — нет.
Стоит отметить, что данная конструкция отвечает дополнительным требованиям для второй и третьей нормальной формы .
атомарность
[ редактировать ]Определение 1NF, данное Эдгаром Ф. Коддом, ссылается на концепцию «атомарности». Кодд утверждает, что «значения в доменах, в которых определено каждое отношение, должны быть атомарными по отношению к СУБД ». [5] Кодд определяет атомарное значение как значение, которое «не может быть разложено СУБД на более мелкие части (за исключением некоторых специальных функций)». [6] это означает, что столбец не должен быть разделен на части, содержащие более одного типа данных, так что значение одной части для СУБД зависит от другой части того же столбца.
Хью Дарвен и Крис Дейт предположили, что концепция Кодда «атомарной ценности» двусмысленна и что эта двусмысленность привела к широко распространенной путанице в том, как следует понимать 1NF. [7] [8] В частности, проблематично понятие «значения, которое невозможно разложить», поскольку оно, по-видимому, подразумевает, что лишь немногие типы данных, если таковые имеются, являются атомарными:
- Строка символов, казалось бы, не является атомарной, поскольку СУБД обычно предоставляет операторы для ее разложения на подстроки.
- Число с фиксированной точкой, казалось бы, не является атомарным, поскольку СУБД обычно предоставляет операторам возможность разложить его на целые и дробные компоненты.
- ISBN , казалось бы, не является атомарным, поскольку он включает в себя язык и идентификатор издателя.
Дэйт предполагает, что «понятие атомарности не имеет абсолютного значения »: [9] [10] значение может считаться атомарным для некоторых целей, но может рассматриваться как совокупность более базовых элементов для других целей. Если эта позиция принята, 1NF не может быть определен со ссылкой на атомарность. Столбцы любого мыслимого типа данных (от строковых и числовых типов до типов массивов и типов таблиц) тогда приемлемы в таблице 1NF, хотя, возможно, не всегда желательно; например, может оказаться более желательным разделить столбец «Имя клиента» на два отдельных столбца: «Имя» и «Фамилия».
Таблицы 1NF как представление отношений
[ редактировать ]Согласно определению Дейта, таблица находится в первой нормальной форме тогда и только тогда, когда она « изоморфна некоторому отношению», что означает, в частности, что она удовлетворяет следующим пяти условиям: [11]
- Строки не упорядочены сверху вниз.
- Столбцы не упорядочены слева направо.
- Повторяющихся строк нет.
- Каждое пересечение строки и столбца содержит ровно одно значение из применимого домена (и ничего больше).
- Все столбцы являются обычными (т. е. строки не имеют скрытых компонентов, таких как идентификаторы строк, идентификаторы объектов или скрытые метки времени).
Нарушение любого из этих условий будет означать, что таблица не является строго реляционной и, следовательно, не находится в первой нормальной форме.
Примеры таблиц (или представлений ), которые не соответствуют этому определению первой нормальной формы:
- Таблица, в которой отсутствует ограничение уникального ключа. Такая таблица сможет содержать повторяющиеся строки, что нарушает условие 3.
- Представление, определение которого требует, чтобы результаты возвращались в определенном порядке, поэтому порядок строк является внутренним и значимым аспектом представления. (Такие представления невозможно создать с помощью SQL , соответствующего стандарту SQL:2003 .) Это нарушает условие 1. Кортежи в истинных отношениях не упорядочены друг относительно друга.
- Таблица с хотя бы одним атрибутом, допускающим значение NULL . Атрибут, допускающий значение NULL, нарушает условие 4, которое требует, чтобы каждый столбец содержал ровно одно значение из домена своего столбца. Этот аспект условия 4 является спорным. Это знаменует собой важный отход от Коддом более позднего видения реляционной модели , [12] в котором явно предусмотрено наличие нулей. [13] Первая нормальная форма, как ее определил Крис Дейт, допускает атрибуты, имеющие отношение значения (таблицы внутри таблиц). Дейт утверждает, что атрибуты со значением отношения, с помощью которых столбец внутри таблицы может содержать таблицу, полезны в редких случаях. [14]
Ссылки
[ редактировать ]- ^ Кодд, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации АКМ. Классика. 13 (6): 377–87. п. 380-381
- ^ Кодд, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации АКМ. Классика. 13 (6): 377–87.
- ^ Кодд, EF (1971). Дальнейшая нормализация реляционной модели. Симпозиум Courant по информатике 6 «Системы баз данных» под редакцией Растина Р.
- ^ Кодд, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации АКМ. Классика. 13 (6): 377–87. п. 381
- ^ Кодд, Э.Ф. Реляционная модель для управления базами данных, версия 2 (Аддисон-Уэсли, 1990).
- ^ Кодд, Э.Ф. Реляционная модель для управления базами данных, версия 2 (Аддисон-Уэсли, 1990), стр. 6.
- ^ Дарвен, Хью. «Атрибуты, значимые по отношению; или, выстоит ли настоящая первая нормальная форма?», в CJ Date и Хью Дарвене, Сочинения по реляционным базам данных, 1989–1991 (Addison-Wesley, 1992).
- ^ Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Апресс. п. 108. ИСБН 978-1-4842-2029-0 .
«В течение многих лет, — пишет Дэйт, — я был в таком же замешательстве, как и все остальные. Что еще хуже, я сделал все возможное (худшее?), чтобы распространить эту путаницу через свои статьи, семинары и другие презентации».
{{cite book}}:|work=игнорируется ( помогите ) - ^ Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Апресс. п. 112. ИСБН 978-1-4842-2029-0 .
{{cite book}}:|work=игнорируется ( помогите ) - ^ Дата, CJ (6 ноября 2015 г.). SQL и реляционная теория: как писать точный код SQL . О'Рейли Медиа. стр. 50–. ISBN 978-1-4919-4115-7 . Проверено 31 октября 2018 г.
- ^ Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Апресс. стр. 127–128. ISBN 978-1-4842-2029-0 .
{{cite book}}:|work=игнорируется ( помогите ) - ^ Дата, CJ (2009). «Приложение А.2». SQL и реляционная теория . О'Рейли.
Кодд впервые определил реляционную модель в 1969 году и не вводил значения NULL до 1979 года.
- ^ Дэйт, CJ (14 октября 1985 г.). «Действительно ли ваша СУБД реляционная?». Компьютерный мир .
Нулевые значения... [должны поддерживаться] в полностью реляционной СУБД для систематического представления недостающей и неприменимой информации, независимо от типа данных.
(третье из 12 правил Кодда) - ^ Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Апресс. стр. 121–126. ISBN 978-1-4842-2029-0 .
{{cite book}}:|work=игнорируется ( помогите )
Дальнейшее чтение
[ редактировать ]- Дэйт, СиДжей, Лоренцос Н. и Дарвен Х. (2002). Временные данные и реляционная модель (1-е изд.). Морган Кауфманн. ISBN 1-55860-855-9 .
- Дэйт, CJ (1999), Введение в системы баз данных (8-е изд.). Эддисон-Уэсли Лонгман. ISBN 0-321-19784-4 .
- Кент, В. (1983) Простое руководство по пяти нормальным формам в теории реляционных баз данных , Communications of the ACM, vol. 26, стр. 120–125.
- Кодд, Э.Ф. (1970). Реляционная модель данных для. Большие общие банки данных. Исследовательская лаборатория IBM, Сан-Хосе, Калифорния.
- Кодд, Э.Ф. (1971). Дальнейшая нормализация реляционной модели. Симпозиум Courant по информатике 6 «Системы баз данных» под редакцией Растина Р.