Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

Первая нормальная форма ( 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

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

Атомарность [ править ]

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

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

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

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

Таблицы 1NF как представления отношений [ править ]

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

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

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

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

Дальнейшее чтение [ править ]

  • Дата, CJ, & Lorentzos, N., & Darwen, H. (2002). Временные данные и реляционная модель (1-е изд.). Морган Кауфманн. ISBN 1-55860-855-9 . 
  • Дата, CJ (1999), Введение в системы баз данных (8-е изд.). Эддисон-Уэсли Лонгман. ISBN 0-321-19784-4 . 
  • Кент, W. (1983) Простое руководство по пяти нормальным формам в теории реляционных баз данных , Связь ACM, т. 26. С. 120–125.
  • Кодд, EF (1970). Реляционная модель данных для. Большие общие банки данных. Исследовательская лаборатория IBM, Сан-Хосе, Калифорния.
  • Кодд, EF (1971). Дальнейшая нормализация реляционной модели. Курантский симпозиум по информатике 6 в системах баз данных под редакцией Растина, Р.