Первая нормальная форма - First normal form

Первая нормальная форма (1NF) является свойством связь в реляционная база данных. Отношение находится в первой нормальной форме тогда и только тогда, когда домен каждого атрибут содержит только атомный (неделимые) значения, и значение каждого атрибута содержит только одно значение из этого домена.[1] Первое определение термина в документе конференции 1971 г. Эдгар Кодд, определил отношение в первой нормальной форме, когда ни один из его доменов не имеет наборов в качестве элементов.[2]

Первая нормальная форма - это важное свойство отношения в реляционной базе данных. Нормализация базы данных - это процесс представления базы данных в терминах отношений в стандартных нормальных формах, где первая нормальная форма является минимальным требованием.

Первая нормальная форма обеспечивает соблюдение следующих критериев:[3]

Примеры

Следующие ниже сценарии сначала демонстрируют, как проект базы данных может нарушать первую нормальную форму, а затем следуют примеры, которые соответствуют.

Конструкции, нарушающие 1НФ

Ниже представлена ​​таблица, в которой хранятся имена и номера телефонов клиентов. Однако одно требование - сохранить несколько номера телефонов некоторых клиентов. Самый простой способ удовлетворить это требование - разрешить столбцу «Номер телефона» в любой строке содержать более одного значения:

Покупатель
Пользовательский ИДИмяФамилияНомер телефона
123ПуджаСингх555-861-2025, 192-122-1111
456СанЧжан(555) 403-1659 доб. 53; 182-929-2929
789ДжонДоу555-808-9633

Столбец телефонных номеров содержит несколько телефонных номеров в одном значении. Например, в первой строке два телефонных номера, разделенных запятой. Значения столбца не атомный: его можно разделить на два числа. Это нарушает первую нормальную форму.

Очевидное решение - ввести больше столбцов:

Покупатель
Пользовательский ИДИмяФамилияНомер телефона1Номер телефона2
123ПуджаСингх555-861-2025192-122-1111
456СанЧжан(555) 403-1659 доб. 53182-929-2929
789ДжонДоу555-808-9633

Технически эта таблица не нарушает требования, чтобы значения были атомарными. Однако неформально два столбца телефонных номеров по-прежнему образуют «повторяющуюся группу»: они повторяют то, что концептуально является одним и тем же атрибутом, а именно телефонным номером. Был введен произвольный и, следовательно, бессмысленный порядок: почему 555-861-2025 помещается в столбец Номер телефона1, а не в столбец Номер телефона2? Нет причин, по которым у клиентов не может быть более двух телефонных номеров, поэтому сколько телефонных номеровN столбцы там должны быть? Невозможно найти телефонный номер без поиска в произвольном количестве столбцов. Добавление дополнительного телефонного номера может потребовать реорганизации таблицы путем добавления нового столбца, а не просто добавления новой строки (кортежа). (Нулевое значение для номера телефона 2 для клиента 789 также является проблемой.)

Конструкции, соответствующие требованиям 1NF

Чтобы привести модель к первой нормальной форме, мы разбили строки, которые мы использовали для хранения информации о нашем телефонном номере, на «атомарные» (то есть неделимые) объекты: отдельные телефонные номера. И мы гарантируем, что ни одна строка не содержит более одного телефонного номера.

Покупатель
Пользовательский ИДИмяФамилияНомер телефона
123ПуджаСингх555-861-2025
123ПуджаСингх192-122-1111
456СанЧжан182-929-2929
456СанЧжан(555) 403-1659 доб. 53
789ДжонДоу555-808-9633

Обратите внимание, что «ID» больше не является уникальным в этом решении с дублированными клиентами. Чтобы однозначно идентифицировать строку, нам нужно использовать комбинацию (ID, Номер телефона). Значение комбинации уникально, хотя каждый столбец отдельно содержит повторяющиеся значения. Возможность однозначно идентифицировать строку (кортеж) является требованием 1NF.

В альтернативном дизайне используются две таблицы:

Имя Клиента
Пользовательский ИДИмяФамилия
123ПуджаСингх
456СанЧжан
789ДжонДоу
Номер телефона клиента
ID телефонного номераПользовательский ИДНомер телефона
1123555-861-2025
2123192-122-1111
3456(555) 403-1659 доб. 53
4456182-929-2929
5789555-808-9633

В этом дизайне столбцы не содержат более одного телефонного номера. Вместо этого каждая ссылка «Клиент-телефонный номер» отображается в отдельной строке. С помощью Пользовательский ИД как ключ один ко многим существует связь между именем и числовыми таблицами. Строка в "родительской" таблице, Имя Клиента, может быть связан со многими строками телефонных номеров в "дочерней" таблице, Номер телефона клиента, но каждый номер телефона принадлежит одному и только одному клиенту. (В «реальном» мире это было бы не лучшим предположением.) Стоит отметить, что эта конструкция отвечает дополнительным требованиям для второй и третья нормальная форма.

Атомарность

Эдгар Ф. Кодд Определение 1NF ссылается на понятие «атомарность». Кодд заявляет, что «значения в областях, в которых определяется каждое отношение, должны быть атомарными по отношению к СУБД."[4] Кодд определяет атомарное значение как такое, которое «СУБД не может разложить на более мелкие части (за исключением некоторых специальных функций)»[5] это означает, что столбец не должен быть разделен на части с более чем одним типом данных в нем, так что значение одной части для СУБД зависит от другой части того же столбца.

Хью Дарвен и Крис Дата предположили, что концепция Кодда «атомарной ценности» неоднозначна, и что эта двусмысленность привела к широко распространенной путанице в отношении того, как следует понимать 1НФ.[6][7] В частности, понятие «значение, которое не может быть разложено» является проблематичным, поскольку оно, казалось бы, подразумевает, что немногие типы данных, если они вообще есть, являются атомарными:

  • Строка символов может показаться не атомарной, поскольку СУБД обычно предоставляет операторы для ее разложения на подстроки.
  • Число с фиксированной запятой может показаться не атомарным, поскольку СУБД обычно предоставляет операторы для его разложения на целые и дробные компоненты.
  • An ISBN Казалось бы, не атомарно, так как включает в себя язык и идентификатор издателя.

Дейт предполагает, что «понятие атомарности не имеет абсолютного значения":[8][9] значение может считаться атомарным для некоторых целей, но может рассматриваться как совокупность более основных элементов для других целей. Если эта позиция принята, 1НФ не может быть определена со ссылкой на атомарность. Столбцы любого мыслимого типа данных (от строковых и числовых типов до множество типы и типы таблиц) тогда приемлемы в таблице 1NF - хотя, возможно, не всегда желательно; например, может быть более желательно разделить столбец «Имя клиента» на два отдельных столбца: «Имя» и «Фамилия».

Таблицы 1НФ как представления отношений

Согласно определению Дейта, таблица находится в первой нормальной форме тогда и только тогда, когда она "изоморфный к некоторому отношению ", что, в частности, означает, что оно удовлетворяет следующим пяти условиям:[10]

  1. Порядок строк сверху вниз отсутствует.
  2. Порядок расположения столбцов слева направо отсутствует.
  3. Нет повторяющихся строк.
  4. Каждое пересечение строки и столбца содержит ровно одно значение из применимого домена (и ничего больше).
  5. Все столбцы обычные [т.е. строки не имеют скрытых компонентов, таких как идентификаторы строк, идентификаторы объектов или скрытые отметки времени].

Нарушение любого из этих условий будет означать, что таблица не является строго реляционной и, следовательно, не находится в первой нормальной форме.

Примеры таблиц (или взгляды ), которые не соответствуют этому определению первой нормальной формы:

  • Таблица, в которой отсутствует ограничение уникального ключа. Такая таблица сможет вместить повторяющиеся строки в нарушение условия 3.
  • Представление, определение которого требует, чтобы результаты возвращались в определенном порядке, так что упорядочение строк является внутренним и значимым аспектом представления. (Такие представления не могут быть созданы с помощью SQL что соответствует SQL: 2003 стандарт.) Это нарушает условие 1. кортежи в истинных отношениях не упорядочены по отношению друг к другу.
  • Стол хотя бы с одним обнуляемый атрибут. Атрибут, допускающий значение NULL, будет нарушать условие 4, которое требует, чтобы каждый столбец содержал ровно одно значение из домена его столбца. Этот аспект условия 4 является спорным. Это знаменует собой важный отход от Codd более позднее видение реляционная модель,[11] в котором явно предусмотрены нули.[12] Первая нормальная форма, как определено Крисом Дейтом, допускает атрибуты со значением отношения (таблицы в таблицах). Дэйт утверждает, что атрибуты со значением отношения, с помощью которых столбец в таблице может содержать таблицу, полезны в редких случаях.[13]

Смотрите также

Для других обычных форм см. Панель навигации внизу страницы.

Рекомендации

  1. ^ Эльмасри, Рамез; Навате, Шамкант Б. (Июль 2003 г.). Основы систем баз данных (Четвертое изд.). Пирсон. п. 315. ISBN  0321204484. В нем указано, что домен атрибута должен включать только атомный (простой, неделимый) значения и что значение любого атрибута в кортеже должно быть единственное значение из домена этого атрибута.
  2. ^ Кодд, Э.Ф. (Октябрь 1972 г.). Дальнейшая нормализация реляционной модели базы данных. Системы баз данных. Институт Куранта: Прентис-Холл. ISBN  013196741X. Отношение находится в первая нормальная форма если у него есть свойство, что ни один из его доменов не имеет элементов, которые сами являются наборами.
  3. ^ Ватт, Эдриенн; Eng, Нельсон (2014). Дизайн базы данных (2-е изд.). Виктория, Британская Колумбия: BCcampus.
  4. ^ Кодд, Э.Ф. Реляционная модель для управления базами данных версии 2 (Аддисон-Уэсли, 1990).
  5. ^ Кодд, Э.Ф. Реляционная модель для управления базами данных версии 2 (Аддисон-Уэсли, 1990), стр. 6.
  6. ^ Дарвен, Хью. «Атрибуты со значением отношения; или, встанет ли настоящая первая нормальная форма?», В К. Дж. Дате и Хью Дарвене, Записи о реляционных базах данных 1989-1991 гг. (Аддисон-Уэсли, 1992).
  7. ^ Дата, К. Дж. (2007). Что на самом деле означает первая нормальная форма. Дата в базе данных: записи 2000–2006 гг.. Апресс. п. 108. ISBN  978-1-4842-2029-0. «[F] или много лет, - пишет Дейт, - я был сбит с толку, как и все остальные. Что еще хуже, я сделал все возможное (худшее?), Чтобы распространить эту путаницу через мои письма, семинары и другие презентации ».
  8. ^ Дата, К. Дж. (2007). Что на самом деле означает первая нормальная форма. Дата в базе данных: записи 2000–2006 гг.. Апресс. п. 112. ISBN  978-1-4842-2029-0.
  9. ^ Дата, К. Дж. (6 ноября 2015 г.). SQL и теория отношений: как писать точный код SQL. O'Reilly Media. С. 50–. ISBN  978-1-4919-4115-7. Получено 31 октября 2018.
  10. ^ Дата, К. Дж. (2007). Что на самом деле означает первая нормальная форма. Дата в базе данных: записи 2000–2006 гг.. Апресс. С. 127–128. ISBN  978-1-4842-2029-0.
  11. ^ Дата, К. Дж. (2009). «Приложение А.2». SQL и теория отношений. О'Рейли. Кодд впервые определил реляционную модель в 1969 году и не вводил нули до 1979 года.
  12. ^ Дата, К. Дж. (14 октября 1985 г.). «Действительно ли ваша СУБД реляционная?». Computerworld. Нулевые значения ... [должны поддерживаться] в полностью реляционной СУБД для систематического представления недостающей и неприменимой информации, независимо от типа данных. (третье из 12 правил Кодда)
  13. ^ Дата, К. Дж. (2007). Что на самом деле означает первая нормальная форма. Дата в базе данных: записи 2000–2006 гг.. Апресс. С. 121–126. ISBN  978-1-4842-2029-0.

дальнейшее чтение