Я пытаюсь получить окончательную версию того, что такое First Normal Form. Все, что я читаю, немного отличается.

Многие авторитеты, такие как Дата, говорят, что по определению отношение всегда находится в Первой нормальной форме, в то время как другие дают список требований. Это означает, что для 1NF существует от нуля до многих требований.

Я полагаю, что разница между таблицами и отношениями: таблицы могут быть полным беспорядком, в то время как отношения следуют определенным ограничениям. Таким образом, тот факт, что отношение представлено в виде таблицы в SQL, создает некоторую путаницу.

Я сосредотачиваюсь конкретно на 1NF, поскольку это касается баз данных SQL. Вопрос в том, какие свойства необходимы для того, чтобы таблица находилась в первой нормальной форме.

---

Многие авторитеты полагают, что если таблица представляет отношение , то оно уже в 1NF. Это толкает определение 1NF обратно к определению отношения.

Вот некоторые свойства таблицы в 1NF:

• Порядок столбцов незначителен [1]
• Порядок строк незначителен
• Все строки имеют одинаковую длину (т. Е. Данные строк соответствуют заголовкам столбцов)
• Дублированных строк нет (это можно гарантировать с помощью суррогатного первичного ключа, но сам PK не требуется)
• Там нет повторяющихся столбцов
• Каждый столбец содержит одно значение (атомарное)

[1] Технически атрибуты неупорядочены, но в таблице данные строки должны быть в том же порядке, что и заголовки столбцов. Однако фактический заказ незначителен.

По нескольким данным :

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

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

Что касается повторяющихся столбцов, то столбец с плохим дизайном имеет почти повторяющиеся столбцы, такие как phone1и phone2т. Д. В общем, повторяющиеся данные указывают на необходимость дополнительной связанной таблицы.

Зависимость

Между строками не должно быть никаких отношений, кроме того, что они соответствуют тем же заголовкам.

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

Вопрос заключается в следующем: сколько из вышеперечисленного содержится в определении 1NF? Бит независимых строк также входит в это?

предварительный

Определение нормальной формы (которая из презентации «дальнейшей нормализации базы данных Relational Model» в 1971 известен как первой нормальной форме ) и по определению реляционной парадигмы сама по себе была опубликована в 1970 году в научной работе , что при условии сильной основа для практики администрирования баз данных, то есть, «Реляционная модель данных для больших Shared банков данных» (RM для краткости) , созданный доктором Е. Ф. Кодда , который является получателем премии Тьюринга и полномочия в отношении реляционной базы.

Да, по поводу текста доктора Кодда имеется множество объяснений, толкований, изложения, отклонений и мнений, но я лично предпочитаю придерживаться первоисточника и настоятельно рекомендую вам проанализировать его самостоятельно, чтобы вы могли сделать свои собственные выводы.

Я, конечно, не понимаю РМ во всей его полноте, но то, что я понимаю, позволяет мне оценить его превосходство, видение, намерение и масштаб, и хотя спустя десятилетия можно заметить, что у него есть несколько незначительных неточностей, они не уменьшают, в любом случае, его гениальность и элегантность. В своей области РМ уникальным образом выдержала испытание временем и не имеет себе равных.

Подчеркивание вышеупомянутых неточностей было бы - использование благотворительного термина - несправедливым, потому что, видя его со значительного расстояния, этот оригинальный материал требовал нескольких доработок и расширений, да, но основная часть работы была непоколебима от очень концепция (и, действительно, доктор Кодд сделал большинство - если не все - таких усовершенствований и дополнений сам).

Я продолжаю перечитывать РМ постоянно, чтобы усилить мое понимание этого исключительного источника знаний (и мое уважение к нему растет с каждым перечитыванием); цель - встать на плечи гигантов.

Отношения и таблицы

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

RM естественно содержит качества, которые должна иметь таблица, чтобы определить, изображает ли она на самом деле отношение, но я предложу здесь неформальное и простенькое толкование о них (еще одно, да!):

• У него должно быть имя (каждое конкретное отношение в структуре базы данных должно отличаться от остальных).
• Каждый из его рядов должен изображать ровно один кортеж соответствующего отношения.
• Порядок ее строк не имеет значения вообще.
• Каждый из его столбцов должен иметь имя, которое обозначает значение ровно одного домена соответствующего отношения, и упомянутое имя должно отличаться от имен остальных столбцов таблицы (столбец должен иметь уникальное различие и должен содержать особое значение и, да, роль, которую играют разработчик базы данных и бизнес-эксперты, чтобы определить каждую значимую область с точностью, имеет первостепенное значение)
• Порядок его столбцов не имеет никакого значения.
• Все его строки должны иметь одинаковое количество столбцов.
• Он должен иметь как минимум один столбец или одну комбинацию столбцов, которые однозначно идентифицируют каждый из кортежей, изображенных через строки; таким образом, все строки должны быть разными (да, это подчеркивает важность того, чтобы был объявлен хотя бы один KEY, и когда есть два или более KEY, один должен быть определен как PRIMARY на основании прагматических соображений, тогда как остальные могут быть считается альтернативным, но да, перед принятием решения каждый из КЛЮЧЕЙ был «кандидатом» на определение ПЕРВИЧНОГО).

Наличие таблицы, которая на самом деле представляет отношение, является критически важным, поскольку, когда она подвергается манипуляциям с операциями реляционного вида, в результате получается таблица, которая представляет отношение. Таким образом, поведение указанной таблицы предсказуемо .

Атомные домены (столбцы)

В первых разделах РМ доктор Кодд представляет несколько примеров отношений, чтобы представить некоторые понятия; Итак, чтобы понять значение атомного домена , давайте начнем со следующей выдержки из RM, в которой подробно описаны некоторые важные моменты:

До сих пор мы обсуждали примеры отношений, которые определены на простых доменах - доменах, элементы которых имеют атомарные (неразложимые) значения. Неатомарные значения могут обсуждаться в рамках отношений. Таким образом, некоторые домены могут иметь отношения как элементы. Эти отношения, в свою очередь, могут быть определены в непростых областях и т. Д.

Таким образом, можно сказать, что каждое из вышеупомянутых пояснительных отношений соответствует одному из двух видов, например, вида A или B :

• Вид A группирует только отношения (таблицы), структурированные с доменами (столбцами), которые содержат исключительно простые значения в каждом из своих кортежей (строк), т. Е. Такие домены (столбцы) не содержат отношений (таблиц) в качестве значений, которые в этот контекст означает, что значения являются атомарными, потому что они не могут быть последовательно разложены в новые отношения (таблицы). Следовательно, отношения этого класса являются теми, которые нормированы , т.е. они соответствуют 1NF, их форма желательна.

• Вид B исключительно интегрируется отношениями (таблицами), которые имеют один или несколько доменов (столбцов), которые содержат отношения как значения в каждом соответствующем кортеже (строке), и это означает, что указанные значения неатомичны, так как они могут быть впоследствии разбиты на новые отношения (таблицы), т. е. они разложимы . Таким образом, отношения такого рода являются ненормализованными, то есть они нарушают 1НФ, они находятся в нежелательной форме.

нормализация

Доктор Кодд вводит раздел о нормализации в РМ следующим параграфом:

Отношение, домены которого все простые, может быть представлено в хранилище двумерным однородным по столбцам массивом типа, который обсуждался выше. Некоторая более сложная структура данных необходима для связи с одним или несколькими непростыми доменами. По этой причине (и другим, которые будут приведены ниже) возможность исключения непростых доменов, кажется, заслуживает изучения! На самом деле существует очень простая процедура исключения, которую мы будем называть нормализацией.

Затем он продолжает показывать:

1. Группа отношений, где один ненормализован (у него есть области, которые содержат отношения как значения, т. Е. Они неатомичны; т. Е. Они не просты)

2. Группа отношений, которые являются нормализованными (то есть те, которые были разложены; то есть те, у которых домены, имеющие отношение к отношениям, были разбиты на простые, что означает, что они являются атомарными)

А затем он описывает процедуру получения нормализованных отношений из ненормализованных.

В этом отношении отношения, которые он использовал, чтобы проиллюстрировать упражнение по нормализации, и само описание упражнения вполне ясны, и я рекомендую еще раз проанализировать их самостоятельно (и я также надеюсь, что это побудит некоторых читателей заняться текстом).

Успешно он указывает:

Возможны дальнейшие операции нормализующего вида. Они не обсуждаются в этой статье.

И упомянутые операции, то есть вторая и третья нормальная форма (2NF и 3NF), на самом деле подробно описаны в «Дальнейшей нормализации реляционной модели базы данных» и, как упоминалось выше, после представления (и последующей печати и публикации) этого документа. , то оригинальная нормальная форма стала известна как первой нормальной формой.

Как заметил практик, наличие ненормализованных отношений (таблиц) вносит (почти всегда ненужный) свертку в реализации RDB.

Отношение, удовлетворяющее 1NF, облегчает определение ограничений и операций с данными, которые могут быть реализованы с помощью подъязыка данных, который является менее сложным, чем тот, который требуется для ненормализованных отношений (таблиц), как указывает д-р Кодд в следующих строках:

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

[...]

Универсальность подъязыка данных заключается в его описательной способности (а не в вычислительной способности).

Недоумение

С моей точки зрения, возникло недоумение из-за (а) вышеупомянутого избытка толкований, объяснений и т. Д. Относительно 1НФ и самого РМ, а также из-за (б) дальнейших попыток переопределить 1НФ того состояния, которое имеет отношения с доменами, которые содержат значения, которые, в свою очередь, являются отношениями, соответствующими 1NF, если они представляют собой одно отдельное значение для каждого соответствующего кортежа.

Мой взгляд на другие ваши очки

Между строками не должно быть никаких отношений, кроме того, что они соответствуют тем же заголовкам.

Я не уверен, правильно ли я понимаю намерение этого утверждения, но, помимо соответствия тем же заголовкам, должна быть связь между (кортежами) строк отношения (таблицы), поскольку каждая из них должна быть утверждением о конкретное вхождение конкретного типа объекта (определенного в контексте бизнес-контекста интереса), которое должно представлять отношение (таблица).

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

Я не знаю, правильно ли я интерпретирую значение этого утверждения, но на самом деле, и в соответствии с моим ответом на предыдущий аспект, между доменами (столбцами) отношения (таблицы) также должна быть связь Именно поэтому это отношение (существенная структура реляционной модели и конкретной реализации RDB).

В качестве примера приведем гипотетическое соотношение (таблица)

• Salary (PersonNumber, EffectiveDate, Amount)

кортеж (ряд)

• Salary (x, y, z)

передал бы смысл

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Следовательно, каждый кортеж (строка) Salaryотношения (таблицы) должен вписываться в структуру утверждения, показанного выше, и разница будет заключаться в замене значений соответствующего домена (столбца), но должна существовать связь между (a) все Salaryдомены (столбцы), а также между (b) все их соответствующие значения по отношению к каждому кортежу (строке); такие отношения это обязательно.

Более высокие нормальные формы (2NF и 3NF) полезны для избавления от функциональных зависимостей между доменами (столбцами) отношения (таблицы), они помогают избежать нежелательных соединений между доменами (столбцами), поскольку указанные нежелательные соединения позволяют вводить аномалии обновления , И 2NF, и 3NF полезны для проверки правильности структуры отношений (таблиц) в определенной реализации RDB.

Иллюстрация Возьмем текстовую строку, которая содержит типичный адрес в США:

"123 Cornhusk Rd., South Succotash, NY 12345"

Написание запроса для поиска всех жителей Корнскус-Роуд или конкретного жителя города Южный Суккоташ или штата Нью-Йорк было бы непростой задачей. Особенно, когда у вас есть следующие строки в данных:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Каждый из них указывает один и тот же фактический адрес (и это даже не учитывает вероятные орфографические ошибки, такие как «Succatash»), но написание алгоритма для их успешного сравнения - это то, что я НЕ хотел бы посвятить моим последним оставшимся годам на этой Земле.

Введите первую нормальную форму. Я не буду вдаваться в подробности того, как это делается, просто рассмотрим общую форму, как видно из большинства баз данных:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Это не полная нормализация. Например, вы могли бы дополнительно разделить Street на StreetNum и StreetName, но этого достаточно для простой иллюстрации, и на самом деле речь идет о том, насколько процесс нормализации проводится в реальной жизни. По-прежнему существует небольшая проблема с поиском всех жителей Дороги Cornhusk, но если вы искали на Стрите подстроку «Cornhusk», и где-то оказался город под названием Cornhusk, по крайней мере, это не вызовет путаницы.

Проблема с определением, данным в Date и др., Заключается в том, что они не могут заглянуть внутрь фрагмента данных и рассмотреть смысл этих данных. Не то чтобы я их особенно обвинял, это может быть довольно сложно.

Поэтому мы должны взять «строку символов» и превратить ее в «адрес». Но придумать всеобъемлющее определение адреса не так просто, как кажется. Особенно при работе с адресами в более чем одной стране.

Сначала мы исправим контекст. Ничто не имеет значения без контекста. Наш контекст здесь адрес . В этом контексте мы можем видеть части данных, которые имеют определенные значения, такие как улица , город и т. Д. Каждому значению мы присваиваем отдельное поле.

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

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

Думайте о 1NF как о введении в математическую концепцию отношений, а не о конкретной структуре данных или фиксированном наборе правил. Математические структуры, такие как отношения, могут быть представлены по-разному - таблицы являются лишь одним из наиболее удобных способов. При использовании таблиц существуют ограничения, обеспечивающие четкое представление их предполагаемых отношений и то, что операции с таблицами являются логически обоснованными по отношению к представленным отношениям.

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

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

Зависимости строк, такие как многозначные, не нарушают 1NF, но, как и зависимости между столбцами, являются предметом высших нормальных форм. Почти повторяющиеся столбцы, такие как phone1, phone2и т. Д., Также не нарушают 1NF, даже если они имеют плохой дизайн.

Определение и объяснение из википедии о 1NF, я думаю , что это очень хорошо. - Жоаноло

Расширение на одно предложение в статье Википедии:

В качестве телефонных номеров текст не является атомным

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

Вопрос о том, была ли соблюдена первая нормальная форма, имеет ли смысл ее дальнейшее разрушение. Смысл 1NF заключается в обеспечении доступа ко всем данным с помощью ключей. Но если вещь, которую вы получаете через доступ с ключами, имеет субструктуру, то у вас нет доступа с ключами к этой субструктуре. - Уолтер Митти

«1NF» используется для обозначения множества разных вещей , многие из которых являются одновременно бессмысленными и распространенными. Смотрите мой ответ на «Нормализация в системе управления базами данных» , включая ее ссылки. Одним из них является мой ответ на вопрос «Что такое атомарность в DBMS?» . (Оба в переполнении стека.) - philipxy

---

_{Ответ сообщества Wiki создан из комментариев, оставленных на вопрос}