Нормализация базы данных
 | Эта статья требует внимания эксперта по базам данных . смотрите на странице обсуждения Подробности ( март 2018 г. ) |
Нормализация базы данных — это процесс структурирования реляционной базы данных в соответствии с рядом так называемых нормальных форм с целью уменьшения избыточности данных и улучшения целостности данных . Впервые он был предложен британским учёным-компьютерщиком Эдгаром Ф. Коддом как часть его реляционной модели .
Нормализация влечет за собой организацию столбцов (атрибутов) и таблиц (отношений) базы данных, чтобы гарантировать, что их зависимости должным образом реализуются ограничениями целостности базы данных. Это достигается путем применения некоторых формальных правил либо посредством процесса синтеза (создание новой конструкции базы данных), либо декомпозиции (улучшение существующей конструкции базы данных).
Цели [ править ]
Основная цель первой нормальной формы, определенной Коддом в 1970 году, заключалась в том, чтобы позволить запрашивать данные и манипулировать ими с использованием «универсального подъязыка данных», основанного на логике первого порядка . [1] Примером такого языка является SQL , хотя Кодд считал его серьезно ошибочным. [2]
Цели нормализации за пределами 1NF (первой нормальной формы) были сформулированы Коддом как:
- Освободить коллекцию отношений от нежелательных зависимостей вставки, обновления и удаления.
- Уменьшить необходимость реструктуризации набора отношений по мере введения новых типов данных и тем самым увеличить срок жизни прикладных программ.
- Сделать реляционную модель более информативной для пользователей.
- Сделать сбор отношений нейтральным по отношению к статистике запросов, поскольку эта статистика может меняться с течением времени.
- Э. Ф. Кодд, «Дальнейшая нормализация реляционной модели базы данных» [3]
При попытке изменить (обновить, вставить или удалить) отношение в отношениях, которые не были достаточно нормализованы, могут возникнуть следующие нежелательные побочные эффекты:
- Аномалия вставки
- Бывают обстоятельства, при которых определенные факты вообще не могут быть зафиксированы. Например, каждая запись в отношении «Преподаватели и их курсы» может содержать идентификатор факультета, название факультета, дату приема на работу преподавателя и код курса. Таким образом, можно записать сведения о любом преподавателе, который преподает хотя бы один курс, но о вновь нанятом преподавателе, которому еще не назначено преподавать какие-либо курсы, нельзя записать, кроме как путем установки для кода курса значения null .
- Обновить аномалию
- Одна и та же информация может быть выражена в нескольких строках; поэтому обновления отношения могут привести к логическим несоответствиям. Например, каждая запись в отношении «Навыки сотрудников» может содержать идентификатор сотрудника, адрес сотрудника и навык; таким образом, изменение адреса конкретного сотрудника может потребоваться применить к нескольким записям (по одной для каждого навыка). Если обновление успешно только частично — адрес сотрудника обновляется в некоторых записях, но не в других — тогда отношение остается в несогласованном состоянии. В частности, отношение дает противоречивые ответы на вопрос о том, каков адрес этого конкретного сотрудника.
- Аномалия удаления
- При определенных обстоятельствах удаление данных, представляющих определенные факты, требует удаления данных, представляющих совершенно другие факты. Отношение «Преподаватели и их курсы», описанное в предыдущем примере, страдает от этого типа аномалии, поскольку, если преподаватель временно перестает быть назначенным на какие-либо курсы, последняя из записей, в которых указан этот преподаватель, должна быть фактически удалена. также удаление преподавателя, если в поле «Код курса» не установлено нулевое значение.
Минимизируйте редизайн при расширении структуры базы данных [ править ]
Полностью нормализованная база данных позволяет расширять ее структуру для размещения новых типов данных без слишком сильного изменения существующей структуры. В результате приложения, взаимодействующие с базой данных, страдают минимально.
Нормализованные отношения и отношения между одним нормализованным отношением и другим отражают концепции реального мира и их взаимосвязи.
Нормальные формы [ править ]
Кодд ввел концепцию нормализации и то, что сейчас известно как первая нормальная форма (1НФ) в 1970 году. [4] В 1971 году Кодд определил вторую нормальную форму (2НФ) и третью нормальную форму (3НФ). [5] а Кодд и Рэймонд Ф. Бойс определили нормальную форму Бойса-Кодда (BCNF) в 1974 году. [6]
Неофициально отношение реляционной базы данных часто называют «нормализованным», если оно соответствует третьей нормальной форме. [7] Большинство отношений 3NF не содержат аномалий вставки, обновления и удаления.
Нормальные формы (от наименее нормализованной до наиболее нормализованной):
- UNF: Ненормализованная форма
- 1НФ: первая нормальная форма
- 2НФ: Вторая нормальная форма.
- 3НФ: Третья нормальная форма.
- EKNF: элементарная ключевая нормальная форма.
- BCNF: нормальная форма Бойса-Кодда.
- 4НФ: Четвертая нормальная форма
- ETNF: нормальная форма эссенциального кортежа.
- 5NF: Пятая нормальная форма.
- DKNF: нормальная форма доменного ключа.
- 6НФ: шестая нормальная форма.
| Ограничение (неофициальное описание в скобках) | ФНФ (1970) | 1НФ (1970) | 2НФ (1971) | 3НФ (1971) | ЕКНФ (1982) | BCNF (1974) | 4НФ (1977) | ЭТНФ (2012) | 5НФ (1979) | ДКНФ (1981) | 6НФ (2003) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Уникальные строки (без повторяющихся записей) [4] |  |  | | | | | | | | | |
| Скалярные столбцы (столбцы не могут содержать отношения или составные значения) [5] |  | | | | | | | | | | |
| Каждый неосновной атрибут имеет полную функциональную зависимость от каждого ключа-кандидата (атрибуты зависят от в целом ). каждого ключа [5] | | | | | | | | | | | |
| Каждая нетривиальная функциональная зависимость либо начинается с суперключа , либо заканчивается основным атрибутом (атрибуты зависят только от ключей-кандидатов). [5] | | | | | | | | | | | |
| Каждая нетривиальная функциональная зависимость либо начинается с суперключа, либо заканчивается элементарным простым атрибутом (более строгая форма 3NF). | | | | | | | | | | | — |
| Каждая нетривиальная функциональная зависимость начинается с суперключа (более строгая форма 3NF). | | | | | | | | | | | — |
| Каждая нетривиальная многозначная зависимость начинается с суперключа. | | | | | | | | | | | — |
| Каждая зависимость соединения имеет компонент суперключа. [8] | | | | | | | | | | | — |
| Каждая зависимость соединения имеет только компоненты суперключа. | | | | | | | | | | | — |
| Каждое ограничение является следствием ограничений предметной области и ключевых ограничений. | | | | | | | | | | | |
| Каждая зависимость соединения тривиальна | | | | | | | | | | | |
Пример пошаговой нормализации [ править ]
Нормализация — это метод проектирования базы данных, который используется для приведения таблицы реляционной базы данных к более высокой нормальной форме. [9] Этот процесс является прогрессивным, и более высокий уровень нормализации базы данных не может быть достигнут, если не будут достигнуты предыдущие уровни. [10]
Это означает, что, имея данные в ненормализованной форме (наименее нормализованной) и стремясь достичь наивысшего уровня нормализации, первым шагом будет обеспечение соответствия первой нормальной форме , вторым шагом будет обеспечение второй нормальной формы удовлетворения , и так далее в указанном выше порядке, пока данные не будут соответствовать шестой нормальной форме .
Однако стоит отметить, что нормальные формы за пределами 4NF представляют в основном академический интерес, поскольку проблемы, для решения которых они существуют, редко проявляются на практике. [11]
Данные в следующем примере были намеренно созданы так, чтобы противоречить большинству нормальных форм. На практике часто можно пропустить некоторые этапы нормализации, поскольку данные в некоторой степени уже нормализованы. Фиксация нарушения одной нормальной формы также часто фиксирует нарушение более высокой нормальной формы. В примере для нормализации на каждом этапе выбиралась одна таблица, а это означает, что в конце некоторые таблицы могут быть недостаточно нормализованы.
Исходные данные [ править ]
Пусть существует таблица базы данных со следующей структурой: [10]
| Заголовок | Автор | Национальность автора | Формат | Цена | Предмет | Страницы | Толщина | Издатель | Страна издателя | Идентификатор жанра | Название жанра | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | Чад Рассел | Американский | Твердый переплет | 49.99 |
| 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
В этом примере предполагается, что у каждой книги есть только один автор.
Таблица, соответствующая реляционной модели, имеет первичный ключ , который однозначно идентифицирует строку. Две книги могут иметь одинаковое название, но ISBN однозначно идентифицирует книгу, поэтому его можно использовать в качестве первичного ключа:
| ISBN | Заголовок | Автор | Национальность автора | Формат | Цена | Предмет | Страницы | Толщина | Издатель | Страна издателя | Идентификатор жанра | Название жанра | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | Начало проектирования и оптимизации базы данных MySQL | Чад Рассел | Американский | Твердый переплет | 49.99 |
| 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
Удовлетворение 1NF [ править ]
В первой нормальной форме каждое поле содержит одно значение. Поле не может содержать набор значений или вложенную запись.
Субъект содержит набор значений субъекта, то есть он не соответствует.
Для решения проблемы субъекты выделены в отдельную таблицу «Тема» : [10]
| ISBN | Заголовок | Автор | Национальность автора | Формат | Цена | Страницы | Толщина | Издатель | Страна издателя | Идентификатор жанра | Название жанра |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | Начало проектирования и оптимизации базы данных MySQL | Чад Рассел | Американский | Твердый переплет | 49.99 | 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
| ISBN | Имя субъекта |
|---|---|
| 1590593324 | MySQL |
| 1590593324 | База данных |
| 1590593324 | Дизайн |
В теме ISBN и является внешним ключом: он ссылается на первичный ключ в книге делает связь между этими двумя таблицами явной.
Вместо одной таблицы в ненормализованной форме теперь имеются две таблицы, соответствующие 1НФ.
Удовлетворение 2NF [ править ]
В приведенной ниже таблице «Книга» есть составной ключ { Title, Format} (обозначен подчеркиванием), который не удовлетворяет 2NF, если какое-то подмножество этого ключа является определяющим. На этом этапе нашего проекта ключ не является первичным ключом , поэтому он называется ключом-кандидатом . Рассмотрим следующую таблицу:
| Заголовок | Формат | Автор | Национальность автора | Цена | Страницы | Толщина | Издатель | Страна издателя | Идентификатор жанра | Название жанра |
|---|---|---|---|---|---|---|---|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | Твердый переплет | Чад Рассел | Американский | 49.99 | 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
| Начало проектирования и оптимизации базы данных MySQL | Электронная книга | Чад Рассел | Американский | 22.34 | 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
| Реляционная модель управления базами данных: версия 2 | Электронная книга | EFCodd | Британский | 13.88 | 538 | Толстый | Аддисон-Уэсли | олень | 2 | Популярная наука |
| Реляционная модель управления базами данных: версия 2 | Мягкая обложка | EFCodd | Британский | 39.99 | 538 | Толстый | Аддисон-Уэсли | олень | 2 | Популярная наука |
Все атрибуты, не являющиеся частью потенциального ключа, зависят от Title , но только Price также зависит от Format . Чтобы соответствовать 2NF и удалять дубликаты, каждый атрибут ключа, не являющегося кандидатом, должен зависеть от всего ключа-кандидата, а не только от его части.
Чтобы нормализовать эту таблицу, сделайте {Title} (простым) потенциальным ключом (первичным ключом), чтобы каждый атрибут ключа, не являющегося кандидатом, зависел от всего потенциального ключа, и удалите Price в отдельную таблицу, чтобы ее зависимость от Format могла сохраниться:
| Заголовок | Автор | Национальность автора | Страницы | Толщина | Издатель | Страна издателя | Идентификатор жанра | Название жанра |
|---|---|---|---|---|---|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | Чад Рассел | Американский | 520 | Толстый | Торопиться | олень | 1 | Учебное пособие |
| Реляционная модель управления базами данных: версия 2 | EFCodd | Британский | 538 | Толстый | Аддисон-Уэсли | олень | 2 | Популярная наука |
| Заголовок | Формат | Цена |
|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | Твердый переплет | 49.99 |
| Начало проектирования и оптимизации базы данных MySQL | Электронная книга | 22.34 |
| Реляционная модель управления базами данных: версия 2 | Электронная книга | 13.88 |
| Реляционная модель управления базами данных: версия 2 | Мягкая обложка | 39.99 |
Теперь таблицы Book и Price соответствуют 2NF .
Удовлетворение 3NF [ править ]
Таблица Book по-прежнему имеет транзитивную функциональную зависимость ({Author Nationality} зависит от {Author}, который зависит от {Title}). Аналогичные нарушения существуют для издателя ({Страна издателя} зависит от {Publisher}, который зависит от {Title}) и жанра ({Genre Name} зависит от {Genre ID}, который зависит от {Title}). Следовательно, таблица Book не находится в 3NF. Чтобы реализовать это в 3NF, давайте воспользуемся следующей структурой таблицы, тем самым устранив транзитивные функциональные зависимости, разместив {Национальность автора}, {Страна издателя} и {Название жанра} в соответствующих таблицах:
| Заголовок | Автор | Страницы | Толщина | Издатель | Идентификатор жанра |
|---|---|---|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | Чад Рассел | 520 | Толстый | Торопиться | 1 |
| Реляционная модель управления базами данных: версия 2 | EFCodd | 538 | Толстый | Аддисон-Уэсли | 2 |
|
| Автор | Национальность автора |
|---|---|
| Чад Рассел | Американский |
| EFCodd | Британский |
| Издатель | Страна |
|---|---|
| Торопиться | олень |
| Аддисон-Уэсли | олень |
| Идентификатор жанра | Имя |
|---|---|
| 1 | Учебное пособие |
| 2 | Популярная наука |
Удовлетворение EKNF [ править ]
Элементарная ключевая нормальная форма (EKNF) находится строго между 3NF и BCNF и мало обсуждается в литературе. Он предназначен «уловить основные качества как 3NF, так и BCNF», избегая при этом проблем обоих (а именно, того, что 3NF «слишком снисходителен», а BCNF «склонен к вычислительной сложности»). Поскольку он редко упоминается в литературе, в этот пример он не включен.
Удовлетворение 4NF [ править ]
Предположим, что база данных принадлежит франчайзинговому книжному продавцу, у которого есть несколько франчайзи, владеющих магазинами в разных местах. Поэтому ритейлер решил добавить таблицу, содержащую данные о наличии книг в разных точках:
| Идентификатор франчайзи | Заголовок | Расположение |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Флорида |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 1 | Реляционная модель управления базами данных: версия 2 | Калифорния |
| 1 | Реляционная модель управления базами данных: версия 2 | Флорида |
| 1 | Реляционная модель управления базами данных: версия 2 | Техас |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Флорида |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 2 | Реляционная модель управления базами данных: версия 2 | Калифорния |
| 2 | Реляционная модель управления базами данных: версия 2 | Флорида |
| 2 | Реляционная модель управления базами данных: версия 2 | Техас |
| 3 | Начало проектирования и оптимизации базы данных MySQL | Техас |
Поскольку эта структура таблицы состоит из составного первичного ключа , она не содержит никаких неключевых атрибутов и уже находится в BCNF (и, следовательно, также удовлетворяет всем предыдущим нормальным формам ). Однако если предположить, что все доступные книги предлагаются в каждой области, название не привязано однозначно к определенному местоположению , и поэтому таблица не удовлетворяет 4NF .
Это означает, что для удовлетворения четвертой нормальной формы эту таблицу также необходимо разложить:
|
|
Теперь каждая запись однозначно идентифицируется суперключом , поэтому 4NF удовлетворяется .
Удовлетворение ETNF [ править ]
Предположим, франчайзи также могут заказывать книги у разных поставщиков. Пусть на отношение также наложено следующее ограничение:
- Если определенный поставщик предоставляет определенное название
- и право собственности передается франчайзи
- и франчайзи поставляется поставщиком ,
- затем поставщик передает право франчайзи собственности . [12]
| Идентификатор поставщика | Заголовок | Идентификатор франчайзи |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | 1 |
| 2 | Реляционная модель управления базами данных: версия 2 | 2 |
| 3 | Изучение SQL | 3 |
Эта таблица находится в 4NF , но идентификатор поставщика равен объединению ее проекций: {{Идентификатор поставщика, Название}, {Название, Идентификатор франчайзи}, {Идентификатор франчайзи, Идентификатор поставщика}}. Ни один компонент этой зависимости соединения не является суперключом (единственным суперключом является весь заголовок), поэтому таблица не удовлетворяет ETNF и может быть дополнительно декомпозирована: [12]
|
|
|
Разложение обеспечивает соответствие ETNF.
Удовлетворение 5NF [ править ]
Чтобы обнаружить таблицу, не удовлетворяющую 5NF , обычно необходимо тщательно изучить данные. Предположим, что таблица из примера 4NF имеет небольшие изменения в данных, и давайте проверим, удовлетворяет ли она 5NF :
| Идентификатор франчайзи | Заголовок | Расположение |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Изучение SQL | Калифорния |
| 1 | Реляционная модель управления базами данных: версия 2 | Техас |
| 2 | Реляционная модель управления базами данных: версия 2 | Калифорния |
Разложение этой таблицы уменьшает избыточность, в результате чего получаются следующие две таблицы:
|
|
Запрос, объединяющий эти таблицы, вернет следующие данные:
| Идентификатор франчайзи | Заголовок | Расположение |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Изучение SQL | Калифорния |
| 1 | Реляционная модель управления базами данных: версия 2 | Калифорния |
| 1 | Реляционная модель управления базами данных: версия 2 | Техас |
| 1 | Изучение SQL | Техас |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 2 | Реляционная модель управления базами данных: версия 2 | Калифорния |
JOIN возвращает на три строки больше, чем следовало бы; добавление еще одной таблицы для пояснения связи приводит к появлению трех отдельных таблиц:
|
|
|
Что теперь вернет JOIN? На самом деле объединить эти три таблицы невозможно. Это означает, что невозможно разложить Франчайзи-Книга-Местоположение без потери данных, поэтому таблица уже удовлетворяет 5NF .
CJ Date утверждал, что только база данных в 5NF действительно «нормализована». [13]
DKNF Удовлетворение
Давайте посмотрим на таблицу Book из предыдущих примеров и посмотрим, удовлетворяет ли она нормальной форме ключа домена :
| Заголовок | Страницы | Толщина | Идентификатор жанра | Идентификатор издателя |
|---|---|---|---|---|
| Начало проектирования и оптимизации базы данных MySQL | 520 | Толстый | 1 | 1 |
| Реляционная модель управления базами данных: версия 2 | 538 | Толстый | 2 | 2 |
| Изучение SQL | 338 | Стройный | 1 | 3 |
| Рецепты SQL | 636 | Толстый | 1 | 3 |
Логично, что толщина определяется количеством страниц. Это означает, что это зависит от страниц , которые не являются ключом. Давайте приведем пример соглашения, согласно которому книга объемом до 350 страниц считается «тонкой», а книга объемом более 350 страниц — «толстой».
Технически это соглашение является ограничением, но оно не является ни ограничением предметной области, ни ограничением ключа; поэтому мы не можем полагаться на ограничения домена и ключевые ограничения для сохранения целостности данных.
Другими словами — ничто не мешает нам поставить, например, «Толстый» для книги всего в 50 страниц — и это делает таблицу нарушением DKNF .
Чтобы решить эту проблему, создается таблица, содержащая перечисление, определяющее толщину , и этот столбец удаляется из исходной таблицы:
|
|
Таким образом, нарушение целостности домена устранено, и таблица находится в DKNF .
Удовлетворение 6NF [ править ]
Простое и интуитивно понятное определение шестой нормальной формы состоит в том, что «таблица находится в 6NF , когда строка содержит первичный ключ и не более одного другого атрибута» . [14]
Это означает, например, таблицу Publisher , созданную при создании 1NF :
| Идентификатор издателя | Имя | Страна |
|---|---|---|
| 1 | Торопиться | олень |
необходимо дополнительно разложить на две таблицы:
|
|
Очевидным недостатком 6NF является увеличение количества таблиц, необходимых для представления информации об одном объекте. Если таблица в 5NF имеет один столбец первичного ключа и N атрибутов, для представления той же информации в 6NF потребуется N таблиц; обновления нескольких полей в одной концептуальной записи потребуют обновления нескольких таблиц; а вставка и удаление аналогичным образом потребуют операций в нескольких таблицах. По этой причине в базах данных, предназначенных для обслуживания онлайн-обработки транзакций (OLTP), не следует использовать 6NF.
Однако в хранилищах данных , которые не допускают интерактивных обновлений и специализируются на быстрых запросах к большим объемам данных, некоторые СУБД используют внутреннее представление 6NF, известное как столбчатое хранилище данных . В ситуациях, когда количество уникальных значений столбца намного меньше количества строк в таблице, столбцово-ориентированное хранилище позволяет значительно сэкономить пространство за счет сжатия данных. Столбчатое хранилище также позволяет быстро выполнять запросы диапазона (например, показывать все записи, в которых конкретный столбец находится между X и Y или меньше X).
Однако во всех этих случаях разработчику базы данных не нужно вручную выполнять нормализацию 6NF, создавая отдельные таблицы. Некоторые СУБД, специализирующиеся на хранении данных, например Sybase IQ , по умолчанию используют столбчатое хранилище, но проектировщик по-прежнему видит только одну таблицу с несколькими столбцами. Другие СУБД, такие как Microsoft SQL Server 2012 и более поздние версии, позволяют указать «индекс хранилища столбцов» для конкретной таблицы. [15]
См. также [ править ]
Примечания и ссылки [ править ]
- ^ «Принятие реляционной модели данных ... позволяет разработать универсальный подязык данных, основанный на прикладном исчислении предикатов. Исчисления предикатов первого порядка достаточно, если набор отношений находится в нормальной форме. Такой язык станет эталоном лингвистической мощи для всех других предлагаемых языков данных и сам по себе станет сильным кандидатом для встраивания (с соответствующей синтаксической модификацией) в различные основные языки (программные, командные или проблемно-ориентированные)». Кодд, «Реляционная модель данных для больших общих банков данных». Архивировано 12 июня 2007 г., в Wayback Machine , стр. 381
- ^ Кодд, Э.Ф. Глава 23, «Серьезные недостатки SQL», в книге «Реляционная модель управления базами данных: версия 2 ». Аддисон-Уэсли (1990), стр. 371–389.
- ^ Кодд, EF «Дальнейшая нормализация реляционной модели базы данных», стр. 34
- ^ Перейти обратно: а б Кодд, Э.Ф. (июнь 1970 г.). «Реляционная модель данных для больших общих банков данных» . Коммуникации АКМ . 13 (6): 377–387. дои : 10.1145/362384.362685 . S2CID 207549016 .
- ^ Перейти обратно: а б с д Кодд, Э. Ф. «Дальнейшая нормализация реляционной модели базы данных». (Представлено на 6-м симпозиуме Courant по компьютерным наукам, «Системы баз данных», Нью-Йорк, 24–25 мая 1971 г.) Отчет об исследовании IBM RJ909 (31 августа 1971 г.). Переиздано в Рэндалле Дж. Растине (ред.), Системы баз данных: Courant Computer Science Symposium Series 6 . Прентис-Холл, 1972 год.
- ^ Кодд, Э.Ф. «Недавние исследования систем реляционных баз данных». Отчет IBM об исследовании RJ1385 (23 апреля 1974 г.). Переиздано в Proc. Конгресс 1974 г. (Стокгольм, Швеция, 1974 г.), Нью-Йорк: Северная Голландия (1974 г.).
- ^ Дата, CJ (1999). Введение в системы баз данных . Аддисон-Уэсли. п. 290.
- ^ Дарвен, Хью; Дата, СиДжей; Феджин, Рональд (2012). «Обычная форма предотвращения избыточных кортежей в реляционных базах данных» (PDF) . Материалы 15-й Международной конференции по теории баз данных . Совместная конференция EDBT/ICDT 2012 . Серия сборников статей Международной конференции ACM. Ассоциация вычислительной техники . п. 114. дои : 10.1145/2274576.2274589 . ISBN 978-1-4503-0791-8 . OCLC 802369023 . Архивировано (PDF) из оригинала 6 марта 2016 г. Проверено 22 мая 2018 г.
- ^ Кумар, Кунал; Азад, Словакия (октябрь 2017 г.). «Шаблон проектирования нормализации базы данных». 2017 4-я Международная конференция секции IEEE Уттар-Прадеш по электротехнике, компьютерам и электронике (UPCON) . IEEE. стр. 318–322. дои : 10.1109/upcon.2017.8251067 . ISBN 9781538630044 . S2CID 24491594 .
- ^ Перейти обратно: а б с «Нормализация базы данных в MySQL: четыре быстрых и простых шага» . ComputerWeekly.com . Архивировано из оригинала 30 августа 2017 года . Проверено 23 марта 2021 г.
- ^ «Нормализация баз данных: 5-я нормальная форма и далее» . База знаний MariaDB . Проверено 23 января 2019 г.
- ^ Перейти обратно: а б Дата, CJ (21 декабря 2015 г.). Новый словарь реляционных баз данных: термины, концепции и примеры . «О'Рейли Медиа, Инк.». п. 138. ИСБН 9781491951699 .
- ^ Дата, CJ (21 декабря 2015 г.). Новый словарь реляционных баз данных: термины, концепции и примеры . «О'Рейли Медиа, Инк.». п. 163. ИСБН 9781491951699 .
- ^ «Нормализация — хотелось бы понять 6NF на примере» . Переполнение стека . Проверено 23 января 2019 г.
- ^ Корпорация Microsoft. Индексы Columnstore: обзор. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview . По состоянию на 23 марта 2020 г.
Дальнейшее чтение [ править ]
- Дэйт, CJ (1999), Введение в системы баз данных (8-е изд.). Эддисон-Уэсли Лонгман. ISBN 0-321-19784-4 .
- Кент, В. (1983) Простое руководство по пяти нормальным формам в теории реляционных баз данных , Communications of the ACM, vol. 26, стр. 120–125.
- Х.-Ж. Шек, П. Пистор Структуры данных для интегрированной системы управления базами данных и информационного поиска
Внешние ссылки [ править ]
- Кент, Уильям (февраль 1983 г.). «Простое руководство по пяти нормальным формам в теории реляционных баз данных» . Коммуникации АКМ . 26 (2): 120–125. дои : 10.1145/358024.358054 . S2CID 9195704 .
- Основы нормализации базы данных. Архивировано 5 февраля 2007 г. в Wayback Machine (About.com). Майком Чапплом
- Введение в нормализацию базы данных. Архивировано 28 сентября 2011 г. на Wayback Machine . Часть 2. Архивировано 8 июля 2011 г. на Wayback Machine.
- Введение в нормализацию базы данных Майка Хиллера.
- Учебное пособие по первым трем нормальным формам Фреда Коулсона.
- Описание основ нормализации базы данных от Microsoft
- Нормализация в СУБД Чайтаньи (beginnersbook.com)
- Пошаговое руководство по нормализации базы данных
- ETNF - Существенная нормальная форма кортежа. Архивировано 6 марта 2016 г. на Wayback Machine.
