Цель нормализации
Нормализация — метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой организации.
Нормализация часто выполняется в виде последовательности тестов для некоторого отношения с целью проверки его соответствия (или несоответствия) требованиям заданной нормальной формы.
Процесс нормализации является формальным методом, который позволяет идентифицировать отношения на основе их первичных ключей (или потенциальных ключей, как в случае НФБК) и функциональных зависимостей, существующих между их атрибутов. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления.
Основная цель проектирования реляционной базы данных заключается в группировании атрибутов и отношения так, чтобы минимизировать избыточность данных и таким образом сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц.
Пример приведения таблицы к первой нормальной форме
Следующая таблица не находится даже в первой нормальной форме, так как у нас есть дублирующие строки (John Smith), а в некоторых ячейках хранятся списки значений (каждый номер телефона — это одно значение).
Таблица сотрудников в ненормализованном виде.
| Сотрудник | Контакт |
| Иванов И.И. | 123-456-789, 987-654-321 |
| Сергеев С.С. | Рабочий телефон 555-666-777, Домашний телефон 777-888-999 |
| John Smith | 123-456-789 |
| John Smith | 123-456-789 |
Чтобы привести эту таблицу к первой нормальной форме, необходимо удалить дублирующие строки, в ячейках хранить один номер телефона, а не список, а тип телефона (домашний или рабочий) вынести в отдельный столбец, так как столбцы хранят структурную информацию.
Таблица сотрудников в первой нормальной форме.
| Сотрудник | Телефон | Тип телефона |
| Иванов И.И. | 123-456-789 | |
| Иванов И.И. | 987-654-321 | |
| Сергеев С.С. | 555-666-777 | Рабочий телефон |
| Сергеев С.С. | 777-888-999 | Домашний телефон |
| John Smith | 123-456-789 |
Таким образом, главное правило первой нормальной формы звучит следующим образом
- Назначение строк – хранить данные
- Назначение столбцов – хранить структурную информацию
- Назначение ячеек – хранить атомарное значение
Т.е. если ячейка таблицы по реляционной теории должна хранить одно атомарное значение, не нужно записывать в ячейку какой-то список значений или составное значение. Также не нужно создавать строки, которые уже есть в таблице и хранить в столбце значения разных типов данных.
На основе всего вышеизложенного можно сделать следующий вывод.
Если таблица создана с соблюдением всех реляционных принципов, значит, она уже находится в первой нормальной форме, таким образом, по сути абсолютно все реляционные таблицы находятся в первой нормальной форме. Если таблица создана без учета реляционных принципов, значит эта таблица не является реляционной.
После того как мы привели таблицы базы данных к первой нормальной форме, мы можем переходить к приведению таблиц до второй нормальной формы (2NF). Описание, требования и пример приведения таблиц до второй нормальной формы мы рассмотрим в следующем материале.
На сегодня это все, надеюсь, материал был Вам полезен, пока!
Нравится320Не нравится8
Кейс «Задание на разработку»
Рассмотрим ситуацию постановки задачи СВОЕМУ программисту. Т.е. пишем техническое задание не для клиента, а своему, такому же раздолбаю, который сидит в соседнем отделе и носит гордое имя «программист». Ах, у Вас он даже в офис не ходит? Дома работает? Что ж, скайп нам в руки. А у Вас? Вы вообще его лично никогда не видели? Значит ситуация сложнее.
И ведь он, поганец такой, требует, чтоб ему дали конкретную работу. И не грузили всякой ерундой и не лили воду на мельницу.
В идеале, было бы вообще замечательно, если бы можно было бы из технического задания, которое мы подготовили для клиента, нарезать небольшие задания и раздавать их разным исполнителям. А затем в проджекте галочки об исполнении ставить.
Но ведь нет, на практике же приходится давать устные пояснения по каждому пункту. Объяснять, что имелось в виду вот в этом предложении ТЗ в тот момент, когда его формулировал для клиента.
Вот и предлагаю способ сохранить нервы себе и уверенность в Вас со стороны программиста.
1 стартмани
45
Комплексный графический механизм для руководителя на базе СКД
Предлагаемый механизм был реализован под собственные нужды. Демонстрирует возможности использования механизма СКД при графической интерпретации бизнес-процессов на предприятии. Особенностью данного механизма является универсальность, т.е. с помощью этого отчета можно отобразить множество различных показателей, используя произвольные отборы, измерения, периоды, типы графиков и т.д. Эксплуатация данной системы в течение полугода на холдинге показала, что графическое отображение бизнес-процессов способствует более быстрому принятию необходимых управленческих решений.
Механизм реализован с использованием справочника «Произвольные отчеты», который был адаптирован в УТ из КА (такой же механизм существует и в УПП), изначально для запуска инструмента «Монитор эффективности».
1 стартмани
33
Нормальные формы.
Правила нормализации, применяемые к таблице, уменьшают проблемные области, «поднимая» таблицы на более высокий уровень согласованности данных, особенно в процессе добавления, обновления и удаления записей. Первая нормальная форма (1NF) — является первым правилом, вторая — вторым и тд. Давайте рассмотрим эти правила подробнее.
Первая нормальная форма (1NF)
Первая нормальная форма основана на атомарности значений полей в таблице. Имеется ввиду, что в поле должна храниться только какая-либо одна сущность. Например, в представленной ниже таблице к записи о сотруднике «привязано» несколько телефонных номеров. Это результат ошибок в проектировании.
Вместо этого, мы должны разместить данные в таблице следующим образом:
В результате мы получили много записей со значением NULL, более того, мы не можем добавить другой номер телефона. Лучше разделим эту таблицу на 2, так, как показано ниже.
Вторая нормальная форма (2NF)
Вторая нормальная форма основана на идее полной функциональной зависимости, при условии, что таблица находится в первой нормальной форме (1NF). Сейчас нужно удалить все не ключевые значения, которые не имеют полной зависимости от значения первичного ключа. Например:
В таблице выше, существуют следующие зависимости:
{SSN} → {EMPLOYEE_NAME}{SSN} → {PROJ_HOURS}
Также,
{PROJECT_NO} → {PROJECT_NAME}{PROJECT_NO} → {PROJECT_HOURS}
Это грубое нарушение 2NF, потому что значение полей PROJECT_HOURS и PROJECT_NAME в каждой записи функционально зависимы от PROJECT_NO. Кроме того, EMPLOYEE_NAME и PROJ_HOURS однозначно определяются значением поля SSN. Чтобы привести данные к 2NF в данном случае мы можем «разложить» таблицу EMPLOYEE_PROJECT на несколько таблиц:
Третья нормальная форма (3NF)
Чтобы привести таблицу в третью нормальную форму (3NF), она должна находится во второй нормальной форме (2NF) и, самое главное, не должна содержать данные с транзитивными зависимостями. Транзитивная зависимость — это случай, когда X→Y, Y→Z, X→Z. Это значит, что любое не ключевое поле не должно быть зависимо от поля, которое не является первичным ключом таблицы. Например:
Здесь, существуют зависимости:
{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}
{SSN} → {DEPT_NAME}
{SSN} → {DEPT_ADDRESS}
Однако, аномальной является следующая зависимость:
{DEPT_NAME} → {DEPT_ADDRESS}
потому что DEPT_NAME не является ключом. Мы можем устранить эту проблему, разделив таблицу на 2 таблицы.
Нормальная форма Бойса-Кодда (BCNF)
В большинстве случаев, BCNF — это эквивалент 3NF. Правда эта форма строже, чем третья нормальная форма. Любая таблица, находящаяся в BCNF, находится в 3NF, но не наоборот.
BCNF — это нетривиальная функциональная зависимость X→Y в которой X, находящийся в ее левой части, является первичным ключом.
Давайте разберемся в этом на примере нескольких таблиц. Некоторые из них находятся одновременно и в 3NF и в BCNF, другие же находятся в3NF, но не в BCNF.
{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}
В таблице EMPLOYEE первичным ключом является поле SSN. Это нетривиальная функциональная зависимость, таблицы EMPLOYEE, в левой части которой находится атрибут SSN. Так как SSN является первичным ключом, функциональная зависимость не нарушает условий BCNF.
{PROJECT_NO} → {PROJECT_NAME}
{PROJECT_NO} → {PROJECT_DURATION}
Таблица PROJECT также находится в BCNF.
{DEPT_NO, SSN} → {PROJECT_NO, DURATION}
{PROJECT_NO} → {DURATION, DEPT_NO}
Однако, PROJECT_INFO не находится в BCNF, потому что PROJECT_NO не является первичным ключом. Не может быть пары строк, представляющих 2 разных SSN, работающих в том же PROJECT_NO и DEPT_NO. Например:
Функциональная зависимость PROJECT_NO → DURATION нетривиальна. Таким образом, таблица не удовлетворяет определению BCNF. Мы можем устранить эту проблему, если перепроектируем эту таблицу таким образом, чтобы все полученные в результате таблицы приняли BCNF. Например:
Нормализация базы данных
Нормализация базы данных – это рекомендации по проектированию.
Преимущества нормализованной базы данных:
- Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.
- Целостность данных. Избежание потерь или искажения информации в базе данных.
- Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.
- Благоприятные предпосылки к росту базы.
Как привести базу данных к нормальной форме?
Для приведения базы к нормальной форме необходимо выполнить следующие действия:
- Постараться объединить данные в группы.
- Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.
Существует 3 нормальные формы базы данных:
- Первая нормальная форма
В одной ячейке одно значение. Исключение тип данных SET
Таблица представляет сущность которая в ней размещена (например клиенты, заказы и т.д.) Причём в каждой таблице имеется уникальное поле (первичный ключ) например id и каждая таблица состоит из наименьшего количества полей.
В примере №1. Представлена не удачная структура таблицы, где в поле languages указано перечисление.
В примере №2 тоже не верная структура таблицы для поля languages.
Правильная структура таблиц для решения данной задачи:
Таблица языков программирования
Таблица связей между пользователями и языками программирования
Вторая нормальная формаДля второй нормальной формы требуется первая нормальная форма.
Поля с не первичным ключом не должны быть зависимы от первичного ключа.
В примере №4 мы видим дублирование некоторых марок автомобилей (Данные избыточны). Требуется сделать разделение на несколько таблиц как в примере №3. На первый взгляд создание новых таблиц кажется более затратным чем реализация в примере №4, но это только до тех пор когда таблица состоит всего из нескольких строк.
Правильная структура таблиц для решения данной задачи:Третья нормальная формаТребуется вторая нормальная форма. Согласно третьей нормальной форме данные не должны храниться в таблице, которые могут быть получены из не ключевых полей.
Таблица цен и цен с НДС
Так как цену с НДС можно получить из поля price, то данную задачу нужно переложить на язык программирования.
28 декабря 2017 /
Типы данных в MySQL
Основные операции SQL
Ilya Web developer
«Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.» Martin Golding
Первая нормальная форма
Определение 1
Простой атрибут – атрибут, который имеет атомарные (неделимые) значения.
Определение 2
Атомарность – это степень детализации и структурирования информации в базе данных.
Глубину структурирования определяет практическая необходимость при работе с данными. Можно привести пример глубины структурирования адреса. Весь адрес с указанием города, улицы, дома, квартиры можно хранить в одном поле. Этот атрибут является атомарным, если не нужно выполнять операции над отдельными улицами или городами, иначе данный атрибут не будет атомарным и нужно его далее разбивать на отдельные атрибуты с указанием города, улицы, дома, квартиры.
Определение 3
Сложный атрибут – атрибут, который получен в результате соединения нескольких атомарных атрибутов, определенных на одном или разных доменах.
Сложный атрибут также называют вектором или агрегатом данных.
Определение 4
Отношение находится в первой нормальной форме (1NF) при атомарности значений всех его атрибутов.
Иначе говоря, значениями в домене каждого атрибута отношения не могут быть ни списки, ни множества сложных или простых значений.
Пример 1
Рассмотрим пример.
База данных отдела кадров организации должна хранить информацию о служащих, которую можно представить с помощью отношения
При рассмотрении данного отношения можно определить, что атрибуты ДЕТИ и ИСТОРИЯ_РАБОТЫ – сложные, к тому же атрибут ИСТОРИЯ_РАБОТЫ содержит сложный атрибут ИСТОРИЯ_ЗАРПЛАТЫ.
Названные сложные атрибуты имеют следующий вид:
Связь названных сложных атрибутов показана на рисунке 3:
Чтобы привести исходное отношение СЛУЖАЩИЙ к первой нормальной форме нужно разбить его на 4 отношения, которые представлены на рисунке 4:
Синей рамкой выделен первичный ключ каждого отношения, шрифтом синего цвета набраны названия внешних ключей
Обратим внимание, что для представления функциональных зависимостей, которые существуют в исходном отношении, служат именно внешние ключи. Линиями со стрелками обозначены существующие функциональные зависимости
Е.Ф.Кодд описал алгоритм нормализации следующим образом:
- В отношении, которое находится на верху дерева (рисунок 1), нужно взять его первичный ключ, и расширить каждое непосредственно подчиненное отношение с помощью вставки домена или их комбинации данного первичного ключа.
- Каждое расширенное отношение имеет первичный ключ, который состоит из первичного ключа этого отношения до расширения и первичного ключа родительского отношения.
- Далее из родительского отношения нужно вычеркнуть все непростые домены, удалить верхний узел дерева. Такую процедуру нужно повторить для каждого из оставшихся поддеревьев.
Пример 2
Рассмотрим еще один пример, в котором таблица не соответствует первой нормальной форме.
Значением атрибута № здания является множество зданий, в которых выполняется работа данным человеком.
Пусть необходимо получить список работников, которые отделывают здание 312. Получить такую информацию довольно сложно, поскольку идентификатор необходимого значения спрятан в середине множества в кортеже. Реляционная таблица РАБОТНИК не соответствует первой нормальной форме, поскольку значения атрибута № здания не атомарны. Но таблица на рисунке 4 имеет первую нормальную форму, поскольку необходимое значение (номер конкретного здания) можно выбрать с помощью простой ссылки на имя атрибута № здания.
Нормализация базы данных
Нормализация базы данных – это рекомендации по проектированию.
Преимущества нормализованной базы данных:
- Возможность существенно упростить выборки. Получение данных из базы относительно простыми запросами.
- Целостность данных. Избежание потерь или искажения информации в базе данных.
- Отсутствие избыточности. Данные в таблице не дублируются, что существенно снижает её размер.
- Благоприятные предпосылки к росту базы.
Как привести базу данных к нормальной форме?
Для приведения базы к нормальной форме необходимо выполнить следующие действия:
- Постараться объединить данные в группы.
- Найти логические связи между этими группами данных. Для установки связей связываемые поля должны быть одного типа и таблица формата InnoDB.
Существует 3 нормальные формы базы данных:
-
Первая нормальная форма
Таблица представляет сущность которая в ней размещена (например клиенты, заказы и т.д.) Причём в каждой таблице имеется уникальное поле (первичный ключ) например id и каждая таблица состоит из наименьшего количества полей.
Пример №1:id name languages 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript В примере №1. Представлена не удачная структура таблицы, где в поле languages указано перечисление.
Пример №2:id name languages1 languages2 languages3 1 Иван Java C++ PHP 2 Пётр PHP JavaScript NULL 3 Михаил C# JavaScript NULL
В примере №2 тоже не верная структура таблицы для поля languages.
Правильная структура таблиц для решения данной задачи:
Пример №3:
Таблица пользователей
id name languages 1 Иван Java, C++, PHP 2 Пётр PHP, JavaScript 3 Михаил C#, JavaScript Таблица языков программирования
id language 1 Java 2 PHP 3 C# 4 JavaScript 5 Java Таблица связей между пользователями и языками программирования
id language_id user_id 1 2 1 2 1 1 3 5 1 4 1 2 -
Вторая нормальная форма
Для второй нормальной формы требуется первая нормальная форма.Пример №4:
id make model 1 bmw X5 2 bmw X6 3 audi A4 4 audi Q5 5 toyota corolla В примере №4 мы видим дублирование некоторых марок автомобилей (Данные избыточны). Требуется сделать разделение на несколько таблиц как в примере №3. На первый взгляд создание новых таблиц кажется более затратным чем реализация в примере №4, но это только до тех пор когда таблица состоит всего из нескольких строк.
Правильная структура таблиц для решения данной задачи: -
Третья нормальная форма
Требуется вторая нормальная форма.
Согласно третьей нормальной форме данные не должны храниться в таблице, которые могут быть получены из не ключевых полей.Пример №5:
Таблица цен и цен с НДС
id price price_nds 1 1100 1243 2 950 1074 Так как цену с НДС можно получить из поля price, то данную задачу нужно переложить на язык программирования.
Правила нормализации на примерах
Первая нормальная форма (1НФ)
Согласно правилам, все атрибуты в такой таблице должны быть простыми, все сохраняемые данные на пересечении столбцов и строк — содержать лишь скалярные значения. Также не должно быть повторяющихся строк.
Для примера возьмем таблицу с автомобилями:
Обратите внимание на нарушение нормализации в моделях BMW — в одной ячейке находится перечень из трех элементов: M5, X5M, M1, то есть можно говорить об отсутствии атомарности. После преобразования в 1НФ таблица меняет вид:
Вторая нормальная форма (2НФ)
Отношения будут соответствовать 2НФ, если сама БД находится в 1НФ, а каждый столбец, который не является ключом, зависит от первичного ключа.
Рассмотрим очередную таблицу:
Она в 1НФ, но не во 2НФ. Стоимость авто зависит от модели и производителя. Размер скидки зависит от производителя, поэтому функциональная зависимость от первичного ключа является неполной. Исправить это можно, выполнив декомпозицию на 2 отношения, где неключевые атрибуты будут зависеть от первичного ключа.
Третья нормальная форма (3НФ)
Таблица должна находиться во 2НФ, плюс любой столбец, который не является ключом, должен зависеть лишь от первичного ключа.
В таблице в отношении атрибут первичным ключом является «Модель». Так как собственные телефоны у автомашин отсутствуют, телефон зависит только от магазина.
В результате можно говорить о наличии в связях следующих функциональных зависимостей:
Зависимость «Модель → Телефон» — транзитивна, поэтому отношение не находится в 3НФ.
Разделив исходное отношение, можно получить 2 отношения, и они уже будут находиться в 3НФ:
Остальные виды соотношений и правил, можно посмотреть по ссылкам ниже:
— https://ru.wikipedia.org/wiki/Нормальная_форма;
— https://habr.com/ru/post/254773/.
P. S. Очень надеемся, что теперь у вас сложилось представление о том, что такое нормализация базы данных. Если же вы хотите освоить работу с БД на профессиональном уровне, добро пожаловать на курсы OTUS!
.
Образец технического задания на организацию склада адресного хранения
При составлении данного образа технического задания не преследовалась цель создать его по ГОСТу и в соответствии с авторитетными нормативными требованиями.
Этот образец технического задания составлен, по большей части, для руководства компании — людей, которым надо управлять компанией и не нужно глубоко погружаться в тонкости процессов разработки.
Преследовалась цель: ознакомить и согласовать с руководством основные принципы реализации проекта. И чтобы предложить руководителю компании доступным и понятным для него языком путь реализации проекта.
На мой взгляд,
данный образец может быть полезен тем, кто составляет описания и задания на разработку и внедрение, работая на стороне Заказчика.
Входящие требования для разработки технического задания:
— Учет номенклатуры на адресном складе в разрезе занимаемого в ячейке (объема) не ведется.
— Предполагается работа с оборудованием (терминалами сбора данных) под только в режиме «Off-Line» или без оборудования в неавтоматизированном режиме.
— Склад адресного хранения должен быть универсальным и доступным для применения в учете в других регионах.
1 стартмани
24
Вторая нормальная форма
Описание 2НФ
Отношение находится во второй нормальной форме тогда и только тогда, когда отношение находится в первой нормальной форме и нет неключевых* атрибутов, зависящих от части сложного ключа. Если потенциальный ключ отношения является простым, то отношение автоматически находится во второй нормальной форме.
Для того, что бы устранить зависимость атрибутов от части сложного ключа, нужно произвести декомпозицию отношения на несколько отношений. При этом те атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение.
В нашем случает у таблицы сотрудники_отделы_проекты имеется сложный(составной) ключ {Н_СОТР, Н_ПРО}. От части ключа Н_СОТР зависят неключевые атрибуты ФАМ, Н_ОТД, ТЕЛ. От части ключа Н_ПРО зависит неключевой атрибут ПРОЕКТ. А вот атрибут Н_ЗАДАН зависит от всего составного ключа, так как сотрудник может выполнять одно задание в одном проекте (см. описание предметной области).
Вывод: отношение сотрудники_отделы_проекты декомпозируем на три отношения — сотрудники_отделы(справочник), проекты(справочник), задания(регистр сведений).
 |
| Отношение сотрудники_отделы |
 |
| Отношение проекты |
 |
| Отношение задания |
Отношения, полученный в результате декомпозиции, находятся во второй нормальной форме. Отношения сотрудники_отделы и проекты имеют простые ключ, следовательно они автоматически находятся в 2НФ. Отношение задания имеет сложный ключ, но единственный неключевой атрибут Н_ЗАДАН зависит от всего ключа {Н_СОТР, Н_ПРО} (надеюсь вы сами поняли какие будут измерения и ресурсы у этого Р/С).
*неключевой атрибут — это атрибут, не входящий в состав никакого потенциального ключа
Приведение к 2НФ
Если в некоторых отношения обнаружена зависмость атрибутов от части сложного ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа. В исходном отношении остаются все ключевые атрибуты.
То есть из отношения сотрудники_отделы_проекты выделили два отношения сотрудники_отделы и проекты, а исходное отношение стало отношением задания.
Пятая нормальная форма
Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.
Такая вот теория… Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:).
Ссылки
- ↑ Codd, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации ACM. Классика. 13 (6): 377–87. п. 380-381
- ↑ Codd, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации ACM. Классика. 13 (6): 377–87.
- ↑ Codd, EF (1971). Дальнейшая нормализация реляционной модели. Курантский симпозиум по информатике 6 в системах баз данных под редакцией Растина, Р.
- ↑ Codd, EF (1970). «Реляционная модель данных для больших общих банков данных». Коммуникации ACM. Классика. 13 (6): 377–87. п. 381
- Кодд, Э. Ф. Реляционная модель для управления базами данных версии 2 (Аддисон-Уэсли, 1990).
- Кодд, Э. Ф. Реляционная модель для управления базами данных, версия 2 (Аддисон-Уэсли, 1990), стр. 6.
- Дарвен, Хью. «Атрибуты со значением отношения; или встанет ли настоящая первая нормальная форма?», В CJ Date и Hugh Darwen, Relational Database Writings 1989–1991 (Addison-Wesley, 1992).
-
Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Дата в базе данных: записи 2000–2006 гг . Апресс. п. 108. ISBN 978-1-4842-2029-0.
« или много лет, — пишет Дэйт, — я был сбит с толку, как и все остальные. Что еще хуже, я сделал все возможное (худшее?), Чтобы распространить эту путаницу через мои письма, семинары и другие презентации ».
- Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Дата в базе данных: записи 2000–2006 гг . Апресс. п. 112. ISBN 978-1-4842-2029-0.
- Дата, CJ (6 ноября 2015 г.). SQL и теория отношений: как писать точный код SQL . O’Reilly Media. С. 50–. ISBN 978-1-4919-4115-7. Проверено 31 октября 2018 года .
- Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Дата в базе данных: записи 2000–2006 гг . Апресс. С. 127–128. ISBN 978-1-4842-2029-0.
-
Дата, CJ (2009). «Приложение А.2». SQL и теория отношений . О’Рейли.
Кодд впервые определил реляционную модель в 1969 году и не вводил нули до 1979 года.
-
Date, CJ (14 октября 1985 г.). «Действительно ли ваша СУБД реляционная?». Компьютерный мир .
Нулевые значения … в полностью реляционной СУБД для систематического представления недостающей и неприменимой информации, независимо от типа данных.
(третье из 12 правил Кодда) - Дата, CJ (2007). Что на самом деле означает первая нормальная форма . Дата в базе данных: записи 2000–2006 гг . Апресс. С. 121–126. ISBN 978-1-4842-2029-0.
