1NF: Повторяющиеся группы, каковы они?

Ответ 1

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

Символьная строка - это простое значение, хотя оно составлено из компонентов, а именно символов. Временная метка проста, даже если она состоит из даты и времени, каждая из которых состоит из таких предметов, как год, месяц и т.д.

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

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

Почему он использовал термин "нормализация". Ну, вот что он ехал, ИМО. Для любого определенного набора требований к информации существует набор реляционных моделей, которые все адекватно выражают эти требования. Члены этого набора можно рассматривать как "эквивалентные" в этом смысле. Можно выработать правило для выбора одного члена этого набора и называть его "нормальным" представлением всего набора. Правило Кодд придумало то, что стало правилом 1NF: никаких подзаговоров.

Еще одно место, где понятие "нормализованное" пришло раньше в вычислениях, было числом с плавающей запятой. Числа 0,1 и 1е-1 представляют одинаковое число, и существует бесчисленное множество способов представления этого же числа. Одно из них можно назвать "нормированным" представлением. Как только (двоичные) числа с плавающей запятой начали поддерживаться в наборах инструкций на компьютере, существовал способ "нормализовать" двоичное число с плавающей запятой таким образом, чтобы мантисса всегда находилась между половиной и одной, если только число был равен нулю. Не важно понимать эти детали. Я имею в виду, что термин "нормализованный" уже был частью компьютерного жаргона в 1970 году, когда Кодд написал свою статью.

Более крупный вопрос, ИМО, "что плохого в нарушении 1NF? Почему важна 1NF?"

Ответ на этот вопрос состоит из двух частей: одна связана с логической моделью, и она связана с физической реализацией первой реляционной СУБД, которая возникла не раньше 1978.

В логической модели желательно сказать, что указание кортежа (путем предоставления значения ключа) и указание атрибута (по имени) должно быть достаточной информацией для привязки значения, заданного к одному значению, на уровень детализации, с которым сталкивается СУБД. Ранняя литература называла этот "ключ доступа ко всем данным".

В физической модели важно избегать выполнения всего сканирования таблицы, чтобы выполнить простой поиск всех вхождений простого значения. Индекс должен сделать трюк в нескольких чтениях диска, а не миллионы дисков для чтения таблицы. Насколько мне известно, никакая СУБД никогда не создавала индекс для отдельных значений, заключенных в CSV-текст, хранящийся в столбце. И Кодд, несомненно, хотел избежать необходимости в таком индексе, когда должна была быть построена первая реляционная СУБД.

Это последний пункт, который возвращает меня к "теоретическому практическому" девизу, который был так полезен для меня. Дизайнеры баз данных Neophyte приходят сюда постоянно, спрашивая, почему не было бы "более эффективным" хранить список кодов курса в таблице учеников, вместо того чтобы прибегать к "сложности" создания таблицы соединений с двумя внешними ключами, studentId и courseId. Ответ, который убеждает неофита, обычно связан с выполнением сканирования таблиц и связанной задержкой для операций, которые хорошая СУБД будет делать с помощью индекса, при условии создания соответствующего индекса. ИМО, что я думаю, что Кодд тоже ехал.

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

(извините, это так долго.)

Ответ 2

Повторяющаяся группа представляет собой многозначную конструкцию в таблице базы данных: атрибут, который не имеет единого значения, но состоит из нескольких значений, к которым обычно обращаются позиционный индекс, а не по имени. Codd original First Normal Form eschewed tables с повторяющимися группами в пользу отношений, состоящих только из однозначных атрибутов. Большинство современных СУБД не допускают многозначных атрибутов, поэтому этот запрет не имеет особого значения.

Позднее Кодд пересмотрел/перефразировал свое определение 1NF, заявив, что он исключил атрибуты, связанные с отношением (обратите внимание, что он никогда не называл атрибуты, связанные с отношением "повторяющиеся группы" - отношения совсем другое). Запрет на атрибуты, связанные с отношением (RVAs), является более противоречивым, чем исходное определение 1NF. Отношение в принципе является значением и может быть доступно, как и любое другое единственное значение. Для "очевидных" причин ясности и простоты RVAs обычно можно избежать. Но не обязательно следует, что их всегда следует избегать. Поскольку RVAs являются одиночными значениями (в отличие от повторяющихся групп), они могут подвергаться реляционным операциям, как и другие другие одиночные значения. Сказать, что отношение должно состоять из любого однозначного атрибута, кроме отношения, представляется излишне ограничительным и немного произвольным.

Возьмем пример простого (неориентированного, без петли, не кратного) графа. Предположим, что граф представлен в relvar с кортежем для каждого ребра, с атрибутами lt, rt для идентификации узлов:

G {lt,rt}

Граф представлен значением отношения G. Теперь предположим, что нам нужно смоделировать произвольный набор таких графов в реляционной базе данных. Очевидно, что один граф должен отличаться от другого, поскольку он состоит из другого набора узлов и ребер, но разные графики могут также иметь некоторые узлы и ребра в общем. Не является наиболее естественным представлением (возможно, единственным возможным представлением) нового отношения, состоящего из значений графа - то есть значений отношения того же типа, что и G?

Graphs { G {lt,rt} }

Этот атрибут Graphs имеет один атрибут G, который является атрибутом отношения с заголовком {lt, rt}. Если мы хотим избежать RVA любой ценой, то возможной альтернативой могло бы стать расширение нашего исходного G relvar путем добавления нового атрибута для определения графика чем-то другим, кроме его узлов и ребер.

Gnam {graphname,lt,rt}

Это может быть полезным решением, но почему это должно быть решением под 1NF? Было бы очень неудобно придумывать новый атрибут только для представления базы данных, если такой атрибут не существует в реальности, которую мы пытаемся моделировать. Процедура нормализации обычно не требует, чтобы новые атрибуты были изобретены для удовлетворения любой нормальной формы. Если RVAs понимаются как исключаемые 1NF, то представляется, что нормализация в качестве процедуры проектирования может быть "нарушена" - наше графическое представление действительно не может быть нормализовано; только альтернативная форма Gnam может быть успешно нормализована. Я согласен с тем, что RVAs, вероятно, нежелательны в большинстве случаев. Я менее убежден, что это хорошая идея, чтобы интерпретировать 1NF как исключение их вообще.

Чтобы повторить, RVAs - это не то же самое, что повторяющиеся группы.

Ответ 3

Отношение представляет собой набор n-кортежей, где j-й атрибут каждого n-набора берется из j-й области отношения.

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

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

например. вы можете определить домен StringUpper (10), который состоит между 0 и 10 символами между значениями A и Z. Среди операций, которые могут выполняться над значением в этом домене, является SubString (Start, End), который извлекает символы, начинающиеся с Начало и окончание в конце.

Домен может быть "сколь угодно сложным", например, MPEG-4 или PortableNetworkGraphic; необходимо просто убедиться, что любое значение, назначенное атрибуту, определенному для такого домена, действительно находится в наборе разрешенных значений для этого домена, например. является допустимым MPEG-4. Значения в этих доменах могут иметь конкретные операции, которые могут выполняться на них, например. Воспроизведение или просмотр.

Домен может содержать то, что некоторые могут рассматривать повторяющиеся группы, например. вы можете определить домен ListStringUpper (10), который состоит из 0 или более элементов, где каждый элемент состоит из 0 и 10 символов между значениями A и Z. Среди операций, которые могут выполняться для значения в этом домене, является GetElement (Index), который извлекает элемент Indexth в списке. (Обратите внимание, что это не слишком отличается от строки, которая представляет собой список символов)

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

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