Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами поговорим о нормализации базы данных, узнаем, что это такое, какие нормальные формы базы данных существуют и зачем вообще проводить нормализацию базы данных.
Постоянные посетители данного сайта знают, что я здесь публикую достаточно много различных материалов, связанных с языком SQL и системами управления базами данных, однако статей, связанных с теорией баз данных, на текущий момент, к сожалению, нет, поэтому я решил это исправить, и начать цикл статей, посвященных теории баз данных.
Начну я с нормализации баз данных. В этом материале мы поговорим в целом о процессе нормализации, узнаем, зачем проводить нормализацию базы данных, что такое нормальная форма базы данных, а также какие нормальные формы существуют. В следующих материалах я подробно и с примерами расскажу про каждую нормальную форму.
Реляционная база данных
В целом под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных и воспользоваться ей, однако если говорить в контексте SQL, то речь будет идти, конечно, о реляционных базах данных, а что же это такое?
Реляционная база данных – это упорядоченная информация, связанная между собой определёнными отношениями.
Логически такая база данных представлена в виде таблиц, в которых и лежит вся эта информация.
Примечание! Если Вас интересует язык SQL, рекомендую пройти мой онлайн-курс по основам SQL, который ориентирован на изучение SQL как стандарта, таким образом, Вы сможете работать в любой системе управления базами данных. Курс включает много практики: онлайн-тестирование, задания и многое другое.
Нормализация баз данных
В реляционных базах данных есть такое понятия, как «Нормализация».
Нормализация – это процесс удаления избыточных данных.
Также нормализацию можно рассматривать и с позиции проектирования базы данных, в таком случае мы можем сформулировать определение нормализации следующим образом.
Нормализация – это метод проектирования базы данных, который позволяет привести базу данных к минимальной избыточности.
Избыточность устраняется, как правило, за счёт декомпозиции отношений (таблиц), т.е. разбиения одной таблицы на несколько.
Зачем нормализовать базу данных?
У Вас может возникнуть вопрос – а зачем вообще нормализовать базу данных и бороться с этой избыточностью?
Дело в том, что избыточность данных создает предпосылки для появления различных аномалий, снижает производительность, и делает управление данными не гибким и не очень удобным. Отсюда можно сделать вывод, что нормализация нужна для:
- Устранения аномалий
- Повышения производительности
- Повышения удобства управления данными
Теперь давайте поговорим о самой избыточности данных, что же это такое.
Избыточность данных – это когда одни и те же данные хранятся в базе в нескольких местах, именно это и приводит к аномалиям.
Так как в этом случае необходимо добавлять, изменять или удалять одни и те же данные в нескольких местах. Например, если не выполнить операцию в каком-нибудь одном месте, то возникает ситуация, когда одни данные не соответствуют вроде как точно таким же данным в другом месте.
Давайте рассмотрим пример. Допустим, у нас есть следующая таблица, она хранит информацию о предметах мебели, в частности наименование предмета и материал, из которого изготовлен этот предмет.
| Идентификатор предмета | Наименование предмета | Материал |
| 1 | Стул | Металл |
| 2 | Стол | Массив дерева |
| 3 | Кровать | ЛДСП |
| 4 | Шкаф | Массив дерева |
| 5 | Комод | ЛДСП |
А теперь допустим, что у нас возникла необходимость подкорректировать название материала, вместо «Массив дерева» нужно написать «Натуральное дерево», и чтобы это сделать нам необходимо внести изменения сразу в несколько строк, так как предметов, изготовленных из массива дерева, несколько, а именно 2: стол и шкаф.
А теперь представьте, что по каким-то причинам мы внесли изменения только в одну строку, в итоге в нашей таблице будет и «Массив дерева», и «Натуральное дерево».
| Идентификатор предмета | Наименование предмета | Материал |
| 1 | Стул | Металл |
| 2 | Стол | Натуральное дерево |
| 3 | Кровать | ЛДСП |
| 4 | Шкаф | Массив дерева |
| 5 | Комод | ЛДСП |
Какое из этих названий будет правильным? А если представить, что мы можем внести еще какое-то новое значение при добавлении новых записей, например, просто «Дерево».
В этом случае в нашей таблице в скором времени будет и «Массив дерева», и «Натуральное дерево», и просто «Дерево», и вообще, что угодно, ведь это просто текст.
| Идентификатор предмета | Наименование предмета | Материал |
| 1 | Стул | Металл |
| 2 | Стол | Натуральное дерево |
| 3 | Кровать | ЛДСП |
| 4 | Шкаф | Массив дерева |
| 5 | Комод | ЛДСП |
| 6 | Тумба | Дерево |
Однако по своей сути это один и тот же материал, мы просто решили или подкорректировать его название, или ошиблись при добавлении новой записи.
Это и есть аномалия, когда одни данные в одном месте не соответствуют вроде как точно таким же данным в другом месте.
Это всего лишь один вид аномалии, однако в процессе добавления, изменения и удаления данных может возникать много других противоречивых ситуаций, т.е. аномалий.
При этом, обязательно стоит отметить, что в нашей таблице всего 5 записей, а теперь представьте, что их миллион!
Заметка! Как создать таблицу в PostgreSQL с помощью pgAdmin 4.
Именно поэтому мы должны устранять избыточность данных в базе, т.е. проводить так называемую нормализацию базы данных.
В данном конкретном случае мы должны название материала, из которого изготовлены предметы мебели, вынести в отдельную таблицу, а в таблице с предметами сделать всего лишь ссылку на нужный материал, тем самым, соотнеся эту ссылку с исходной записью, мы будем понимать, из какого материала сделан тот или иной предмет.
Предметы мебели.
| Идентификатор предмета | Наименование предмета | Идентификатор материала |
| 1 | Стул | 2 |
| 2 | Стол | 1 |
| 3 | Кровать | 3 |
| 4 | Шкаф | 1 |
| 5 | Комод | 3 |
Материалы, из которых изготовлены предметы мебели.
| Идентификатор материала | Материал |
| 1 | Массив дерева |
| 2 | Металл |
| 3 | ЛДСП |
В этом случае когда нам потребуется изменить название материала, мы будем вносить изменение только в одном месте, т.е. править только одну строку.
Таким образом, представляя материалы в виде отдельной сущности и создавая для нее отдельную таблицу, мы устраняем описанную выше аномалию.
Другими словами, каждая сущность должна храниться отдельно, а в случае необходимости использования этой сущности в другой таблице на нее делается всего лишь ссылка, т.е. выстраивается связь.
Нормальные формы базы данных
В целом процесс нормализации базы данных выглядит следующим образом: мы, следуя определённым правилам и соблюдая определенные требования, проектируем таблицы в базе данных.
При этом все эти правила и требования можно сгруппировать в несколько наборов, и если спроектировать базу данных с соблюдением всех правил и требований, которые включаются в тот или иной набор, то база данных будет находиться в определённом состоянии, т.е. форме, и такая форма называется нормальная форма базы данных.
Иными словами, следуя определённым правилам и соблюдая определенные требования мы приводим базу данных к определенной нормальной форме.
Нормальная форма базы данных – это набор правил и критериев, которым должна отвечать база данных.
Каждая следующая нормальная форма содержит более строгие правила и критерии, тем самым приводя базу данных к определённой нормальной форме мы устраняем определённый набор аномалий.
Отсюда можно сделать вывод, что чем выше нормальная форма, тем меньше аномалий в базе будет.
Процесс нормализации – это последовательный процесс приведения базы данных к эталонному виду, т.е. переход от одной нормальной формы к следующей.
Иными словами, процесс перехода от одной нормальной формы к следующей – это усовершенствование базы данных. Так как если база данных находится в какой-то определённой нормальной форме – это означает, что в базе данных отсутствует определенный вид аномалий.
Существует 5 основных нормальных форм базы данных:
- Первая нормальная форма (1NF)
- Вторая нормальная форма (2NF)
- Третья нормальная форма (3NF)
- Четвертая нормальная форма (4NF)
- Пятая нормальная форма (5NF)
Однако выделяют еще дополнительные нормальные формы:
- Ненормализованная форма или нулевая нормальная форма (UNF)
- Нормальная форма Бойса-Кодда (BCNF)
- Доменно-ключевая нормальная форма (DKNF)
- Шестая нормальная форма (6NF)
Заметка! Установка и настройка PostgreSQL на Windows 10.
Если объединить оба этих списка и упорядочить нормальные формы от менее нормализованной до самой нормализованной, т.е. начиная с формы, при которой база данных по своей сути не является нормализованной, и заканчивая самой строгой нормальной формой, то мы получим следующий перечень:
- Ненормализованная форма или нулевая нормальная форма (UNF)
- Первая нормальная форма (1NF)
- Вторая нормальная форма (2NF)
- Третья нормальная форма (3NF)
- Нормальная форма Бойса-Кодда (BCNF)
- Четвертая нормальная форма (4NF)
- Пятая нормальная форма (5NF)
- Доменно-ключевая нормальная форма (DKNF)
- Шестая нормальная форма (6NF)
- База данных считается нормализованной, если она находится как минимум в третьей нормальной форме (3NF).
- В реальном мире нормализация до третьей нормальной формы (3NF) является обычной, стандартной практикой, так как 3NF устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство ее использования не снижается, что нельзя сказать о всех последующих формах.
- Ситуации, при которых требуется нормализовать базу данных до четвертой нормальной формы (4NF), в реальном мире встречаются достаточно редко.
Заметка! Если Вас интересует язык SQL, рекомендую почитать мою книгу «SQL код», которая ориентирована на изучение SQL как стандарта, после прочтения книги Вы сможете писать SQL запросы в любой системе управления базами данных.
Если говорить о всех последующих нормальных формах (5NF, DKNF, 6NF), то в реальной жизни трудно даже представить ситуации, при которых потребуется нормализовать базу данных до этих форм.
Иными словами, 5NF, DKNF, 6NF – это в большей степени теоретические нормальные формы, немного отстраненные от реального мира.
Стоит отметить, что приведение базы данных к какой-то конкретной нормальной форме, обязательно требует, чтобы эта база данных уже находилась в предыдущей нормальной форме.
Другими словами, если Вы хотите нормализовать базу данных до третьей нормальной формы, то база уже должна находиться во второй нормальной форме, т.е.
нельзя нормализовать базу данных до третьей формы, если она еще не нормализована до второй.
Описание нормальных форм базы данных
В следующих статьях представлено подробное описание каждой нормальной формы и приведены примеры.
Опрос. Какой операционной системой Вы пользуетесь?
На сегодня это все, надеюсь, материал был Вам полезен и интересен, пока!
Описание нормализации базы данных — Office
- Статья
- 05/16/2022
- Чтение занимает 5 мин
- Применяется к: Microsoft Office Access 2007, Microsoft Office Access 2003
Оригинальный номер базы знаний: 283878
В данной статье, ориентированной на начинающих, объясняется терминология нормализации баз данных. Понимание этой терминологии помогает вести разговор об архитектуре и проектировании реляционных баз данных.
Описание нормализации
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных.
Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах.
Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше.
Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме».
Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме».
Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы.
Как и в случае со многими другими формальными правилами и спецификациями, обеспечить полное соответствие реальным ситуациям не всегда возможно.
Как правило, для выполнения нормализации приходится создавать дополнительные таблицы, и некоторые клиенты считают это нежелательным.
Собираясь нарушить одно из первых трех правил нормализации, убедитесь в том, что в приложении учтены все связанные с этим проблемы, такие как избыточность данных и несогласованные зависимости.
В описаниях ниже приведены соответствующие примеры.
Первая нормальная форма
- Устраните повторяющиеся группы в отдельных таблицах.
- Создайте отдельную таблицу для каждого набора связанных данных.
- Идентифицируйте каждый набор связанных данных с помощью первичного ключа.
Не используйте несколько полей в одной таблице для хранения похожих данных.
Например, для слежения за товаром, который закупается у двух разных поставщиков, можно создать запись с полями, определяющими код первого поставщика и код второго поставщика.
Что произойдет при добавлении третьего поставщика? Добавление третьего поля нежелательно, так как для этого нужно изменять программу и таблицу, поэтому данный способ плохо адаптируется к динамическому изменению числа поставщиков. Вместо этого можно поместить все сведения о поставщиках в отдельную таблицу Vendors (поставщики) и связать товары с поставщиками с помощью кодов товаров или поставщиков с товарами с помощью кодов поставщиков.
Вторая нормальная форма
- Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.
- Свяжите эти таблицы с помощью внешнего ключа.
Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо).
Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections.
Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.
Третья нормальная форма
- Устраните поля, не зависящие от ключа.
Значения, входящие в запись и не являющиеся частью ключа этой записи, не принадлежат таблице. Если содержимое группы полей может относиться более чем к одной записи в таблице, попробуйте поместить эти поля в отдельную таблицу.
Например, в таблицу Employee Recruitment (наем сотрудников) можно включить адрес кандидата и название университета, в котором он получил образование. Однако для организации групповой почтовой рассылки необходим полный список университетов.
Если сведения об университетах будут храниться в таблице Candidates, составить список университетов при отсутствии кандидатов не получится.
Таким образом, создайте вместо этого отдельную таблицу Universities и свяжите ее с таблицей Candidates при помощи ключа — кода университета.
ИСКЛЮЧЕНИЕ: выполнять нормализацию баз данных до третьей нормальной формы теоретически желательно, но не всегда практично.
Например, для устранения всех возможных зависимостей между полями таблицы Customers придется создать отдельные таблицы для хранения сведений о городах, почтовых индексах, торговых представителях, категориях клиентов и любых других сведений, которые могут дублироваться в нескольких записях.
С теоретической точки зрения нормализация желательна. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.
Выполнять нормализацию до третьей нормальной формы может быть целесообразно только для часто изменяемых данных. Если при этом сохранятся зависимые поля, спроектируйте приложение так, чтобы при изменении одного из этих полей пользователь должен был проверить все связанные поля.
Другие формы нормализации
Кроме описанных нормальных форм, существует четвертая нормальная форма, которую также называют нормальной формой Бойса-Кодда (BCNF), и пятая нормальная форма, но на практике они применяются редко. Несоблюдение этих правил может привести к ухудшению архитектуры базы данных, но на функциональности это сказаться не должно.
Нормализация таблицы примеров
Ниже приведен пример нормализации таблицы с вымышленными данными о студентах.
-
Таблица до нормализации:
Student#
Advisor
Adv-Room
Class1
Class2
Class3
1022 Петров 412 101-07 143-01 159-02 4123 Иванов 216 101-07 143-01 179-04 -
Первая нормальная форма: нет повторяющихся групп
Таблицы должны иметь только два измерения. Так как один студент изучает несколько курсов, эти курсы следует указать в отдельной таблице. Наличие полей Class1, Class2 и Class3 в приведенных выше записях свидетельствует о неудачном проектировании таблицы.
Электронные таблицы часто включают третье измерение, но в таблицах баз данных оно использоваться не должно.
Рассмотреть эту проблему можно также с помощью отношения «один — множество», тогда совет можно сформулировать следующим образом: не включайте в одну таблицу элементы, представляющие обе стороны данного отношения.
Вместо этого создайте другую таблицу в первой нормальной форме, устранив повторяющуюся группу (Class#):
Student#
Advisor
Adv-Room
Class#
1022 Петров 412 101-07 1022 Петров 412 143-01 1022 Петров 412 159-02 4123 Иванов 216 101-07 4123 Иванов 216 143-01 4123 Иванов 216 179-04 -
Вторая нормальная форма: устранение избыточных данных
Обратите внимание на то, что в приведенной выше таблице каждое значение Student# сопоставлено с несколькими значениями Class#. Значения Class# функционально не зависят от значений Student# (первичный ключ), а это означает, что данное отношение не нормализовано до второй нормальной формы.
В следующей таблице представлена вторая нормальная форма:
Таблица Students:
Student#
Advisor
Adv-Room
1022 Петров 412 4123 Иванов 216 Таблица Registration:
Student#
Class#
1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 -
- Третья нормальная форма: устранение данных, не зависящих от ключа
- В последнем примере значения Adv-Room (номер кабинета научного руководителя) функционально зависят от атрибута Advisor. Решить эту проблему можно, переместив данный атрибут из таблицы Students в таблицу Faculty (факультет):
- Таблица Students:
Student#
Advisor
1022 Петров 4123 Иванов Таблица Faculty:
Имя
Room
Dept
Петров 412 42 Иванов 216 42
Процесс нормализации отношения заключается в — Мастерок
Нормализация — это формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей, как в случае НФБК) и существующих функциональных зависимостей.
Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся база данных могла быть нормализована до желаемой степени нормализации.
Если некоторое требование не удовлетворяется, то нарушающее данное требование отношение должно быть декомпозировано на отношения, каждое из которых (в отдельности) удовлетворяет всем требованиям нормализации.
Зачастую нормализация осуществляется в несколько последовательно выполняющихся этапов, каждый из которых соответствует некоторой нормальной форме, обладающей известными свойствами. В ходе нормализации формат отношений становится все более строгим и менее уязвимым по отношению к аномалиям обновления.
При работе с реляционной моделью данных важно понимать, что только удовлетворение требований первой нормальной формы (1НФ) обязательно для создания отношений приемлемого качества. Все остальные формы могут использоваться по желанию проектировщиков.
Однако, для того чтобы избежать аномалий обновления, нормализацию рекомендуется выполнять как минимум до ЗНФ.
На рисунке 6 показана схема процесса нормализации и продемонстрирована взаимосвязь между разными нормальными формами. Видно, что одни 1НФ-отношения могут находиться во 2НФ, другие 2НФ-отношения — в ЗНФ и т.д.
Ненормализованная форма (ННФ) – таблица, содержащая одну или несколько повторяющихся групп данных.
Первая нормальная форма (1НФ) – отношение, в котором на пересечении каждой строки и каждого столбца содержится только одно значение.
Процесс нормализации начинается с преобразования данных из формата источника (например, из формата стандартной формы ввода данных) в формат таблицы со строками и столбцами. На исходном этапе таблица находится в ненормализованной форме (ННФ) и часто называется ненормализованной таблицей.
Для преобразования ненормализованной таблицы в первую нормальную форму (1НФ) в исходной таблице следует найти и устранить все повторяющиеся группы данных. Повторяющейся группой называется группа, состоящая из одного и более атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута таблицы.
Существует два подхода исключения повторяющихся групп из ненормализованных таблиц.
Впервом подходе повторяющиеся группы устраняются путем ввода соответствующих данных в пустые столбцы строк с повторяющимися данными. Иначе говоря, пустые места при этом заполняются дубликатами неповторяющихся данных. Этот подход часто называют «выравниванием» («flattening») таблицы. Полученная в результате этих действий таблица, которая теперь будет называться отношением, содержит атомарные (или единственные) значения на пересечении каждой строки с каждым столбцом, а потому находится в первой нормальной форме. В результате такого подхода в полученное отношение вносится некоторая избыточность данных, которая в ходе дальнейшей нормализации будет устранена.
Во втором подходе один атрибут или группа атрибутов назначаются ключом ненормализованной таблицы, а затем повторяющиеся группы изымаются и помещаются в отдельные отношения вместе с копиями ключа исходной таблицы. Далее в новых отношениях устанавливаются первичные ключи.
Иногда ненормализованные отношения могут содержать одну или несколько повторяющихся групп внутри повторяющихся групп первого порядка. В таких случаях данный прием применяется до тех пор, пока повторяющихся групп совсем не останется.
Полученный набор отношений будет находиться в первой нормальной форме только тогда, когда ни в одном из них не будет повторяющихся групп атрибутов.
Хотя оба этих подхода одинаково корректны, следует отметить, что при использовании второго подхода полученные отношения находятся как минимум в 1НФ и обладают меньшей избыточностью данных. При выборе первого подхода выровненное 1НФ-отношение декомпозируется в ходе дальнейшей нормализации на те же отношения, которые могли бы быть получены с помощью второго подхода.
Предисловие
Нормализация отношений (таблиц) — одна из основополагающих частей теории реляционных баз данных.
Нормализация имеет своей целью избавиться от избыточности в отношениях и модифицировать их структуру таким образом, чтобы процесс работы с ними не был обременён различными посторонними сложностями.
При игнорировании такого подхода эффективность проектирования стремительно снижается, что вкупе с прочими подобными вольностями может привести к критическим последствиям.
Любому специалисту, по роду своей деятельности так или иначе связанному с проектированием реляционных баз данных, полезно понимать и уметь осуществить нормализацию отношений.
И этим постом хотелось бы начать небольшую серию публикаций, посвящённых нормальным формам, имеющую целью дать тем читателям Хабрахабра, которые по различным обстоятельствам ещё не освоили эту тему, возможность легко заполнить этот пробел в знаниях.
Статья не имеет своей целью подробное и точное изложение принципов нормализациии, поскольку это, очевидно, невозможно в рамках блога в силу больших объёмов информации, необходимых для публикации при таком подходе.
Кроме этого, для такой цели существует большое количество литературы, написанной прекрасными специалистами.
Моя же задача, как я считаю, заключается в том, чтобы популярно продемонстрировать и объяснить основные принципы.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы. Домен атрибута — множество допустимых значений, которые может принимать атрибут. Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица). Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей. Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y.
Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: -> .
Читать также: Вакуумсоздающие установки со стабилизацией давления вакуума
Первая нормальная форма
Отношение находится в первой нормальной форме (сокращённо 1НФ), если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя разделить на более простые атрибуты, которые соответствуют каким-то другим свойствам описываемой сущности.
Будем называть исходное отношение основным, а значение неатомарного атрибута — подчинённым.
Для того, чтобы нормализовать исходное отношение, атрибуты которого неатомарны, необходимо объединить схемы основного и подчинённого отношений. Кроме того, если, например, таблица, соответствующая ненормализованному отношению уже содержится в БД и заполнена информацией, задача усложняется тем, что значение неатомарного атрибута может в свою очередь содержать несколько кортежей.
Следует пояснить сказанное на примере. Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.
| Код сотрудника | ФИО | Должность | Проекты |
| 1 | Иванов Иван Иванович | Программист |
Нормализация отношений реляционных баз данных
При создании базы данных следует определить количество таблиц (отношений) БД и их атрибутный состав, который должен быть рациональным. Суть рациональности заключается в минимизации дублирования данных и упрощении процедуры их обработки и обновления.
Классическая технология создания реляционных БД связана с теорией нормализации, которая позволяет улучшить характеристики БД и основана на анализе функциональной зависимости между атрибутами отношений.
Процесс нормализации заключается в разложении (декомпозиции) исходных отношений БД на более простые отношения. Каждая ступень этого процесса приводит схему отношений в последовательные нормальные формы.
Для каждой ступени нормализации имеются наборы ограничений, которым должны удовлетворять отношения БД. Нормализация позволяет удалить из таблиц базы избыточную неключевую информацию.
При этом можно выделить следующую последовательность нормальных форм:
- • первая нормальная форма (1 N.1*);
- • вторая нормальная форма (2ИР);
- • третья нормальная форма (ЭТУ/);
- • нормальная форма Бойса—Кодда (ВСИР)',
- • четвертая нормальная форма (4 ИР);
- • пятая нормальная форма, или нормальная форма проекции- соединения (5Л^или В//ИР).
Основные свойства нормальных форм состоят в том, что каждая следующая нормальная форма лучше предыдущей и при переходе к следующей нормальной форме свойства предыдущих сохраняются.
Первая нормальная форма (1НФ). Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (атомарные или неделимые). Примеры
- 1. Отношение Товар = (Код товара[1]: Название; Цвет; Вес; Цена_за_единицу) находится в 1НФ, так как все атрибуты в данном отношении являются простыми.
- 2. Отношение Сотрудник = (Таб номер: ФИОсотрудника; Дата рождения; Дети) не находится в 1НФ, так как атрибуты «ФИО сотрудника», «Дата_рождения», «Дети» могут быть сложными:
- • атрибут «ФИО_сотрудника» содержит три части — фамилию, имя и отчество сотрудника фирмы, поэтому должен быть разбит на три атомарных атрибута, каждый из которых может использоваться самостоятельно;
- • атрибут «Дата_рождения», как и атрибут «ФИО_сотрудника», не является атомарным, поскольку включает в себя три понятия — «Год», «Месяц» и «День». Однако в БД существуют типы данных — Date и Date Time, которые позволяют выполнять над датами специальные операции, например, — = . В связи с этим атрибуты дат в базах данных считаются атомарными;
- • атрибут «Дети» также является сложным, так как может содержать сведения об имени ребенка и его дату рождения.
- Для приведения отношения Сотрудник к 1НФ необходимо декомпозировать его на следующие два отношения:
- Сотрудник = ГГаб номер: Фамилия; Имя; Отчество; Дата_рож- дения)
- Дети = Паб номер: Имя ребенка: Дата_рождения_ребенка)
- При этом связь между этими отношениями осуществляется через ключевое поле «Таб_номер», тип связи «один к одному».
Вторая нормальная форма (2НФ). Вторая нормальная форма к требованию атомарности атрибутов добавляет еще одно — каждый неключевой атрибут должен функционально полно зависеть от первичного ключа (не должен зависеть от части составного ключа).
Отношение находится во второй нормальной форме, если оно удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Примеры
- 1. Отношение Товар = (Код товара: Название; Цвет; Вес; Цена_ за единицу) находится в 1НФ и во 2НФ одновременно, так как все атрибуты в данном отношении однозначно определены и функционально зависят от ключа «Код_товара».
- 2. Отношение Заказанное изделие = (Номер заказа: Код изделия: Название_изделия; Цена; Количество) не находится во 2НФ, так как атрибут «Количество» зависит от составного ключа (Номер заказа и Код изделия), а атрибуты «Название_изделия» и «Цена» зависят только от части составного ключа «Код_изделия».
- Для приведения отношения Заказанное изделие к 2НФ необходимо декомпозировать его на следующие два отношения:
- Заказанное_изделие = (Номер заказа: Код изделия: Количество)
- Изделие = (Код изделия: Название_изделия; Цена)
- Связь между этими отношениями осуществляется через ключевое поле «Код_изделия».
Третья нормальная форма (ЗНФ) подразумевает атомарность и функционально полную зависимость атрибутов каждой сущности от ее первичного ключа. Кроме того, между неключевыми атрибутами сущности должны отсутствовать транзитивные зависимости, т.е. они должны быть взаимно независимы.
Отношение находится в ЗНФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Поясним понятие транзитивной зависимости.
Имеем отношение О с атрибутами А, В, С. Если С зависит от В, а В, в свою очередь, зависит от А, то считается, что С транзитивно зависит от А (рис. 2.13).
Преобразование в ЗНФ состоит в декомпозиции исходного отношения на два отношения (рис. 2.14).
Пример
Отношение Сотрудник = (Таб номер: Фамилия; Должность; Оклад; Дата_зачисления; Дата_увольнения) не находится в ЗНФ, так
Рис. 2.13. Транзитивная зависимость
Рис. 2.14. Декомпозиция отношения
как атрибуты «Должность» и «Оклад» находятся в транзитивной зависимости.
В этом случае несколько человек могут работать в одной и той же должности и, следовательно, при изменении должностного оклада необходимо менять данные в каждой записи.
Также если имеются уникальные должности, то при увольнении сотрудника потеряется информация об окладе по этой должности. Кроме того, сотрудник может переходить с одной должности на другую.
- Для приведения отношения Сотрудник к ЗНФ необходимо декомпозировать его на следующие отношения:
- Сотрудник = (Таб номер: Фамилия)
- Должность = (Код должности: Должность; Оклад)
- Должностные_перемещения = (Таб номер: Код должности:
- Датазачисления; Дата_увольнения)
- Отношение Сотрудник Отношение Должность
Связь между отношениями Сотрудник и Должностные перемещения осуществляется через ключевое поле «Таб_номер», между отношениями Должость и Должностные_перемещения — через ключевое поле «Код_должности».
Нормальная форма Бойса—Кодда (НФБК). Отношение находится в нормальной форме Бойса—Кодда, если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.
- Пример
- Пусть в БД требуется хранить данные о поставке товара некоторыми поставщиками, причем номер поставщика и его наименование являются уникальными. Таким образом, имеем следующее отношение:
- Поставка товаров = (Код_поставщика; Наименование по- ставщика; Код_товара; Количество)
- Данное отношение содержит два потенциальных составных ключа: [Код_поставщика; Код_товара] и [Наименованиепо- ставщика; Код_товара].
Отношение Поставка_товаров находится во 2НФ, так как не содержит неключевых атрибутов, зависящих от части сложного ключа. Также это отношение находится в ЗНФ, поскольку не содержит зависимых друг от друга неключевых атрибутов, так как неключевой атрибут всего один — количество.
- Рассматриваемое отношение содержит избыточные данные, так как при изменении сведений о наименовании поставщика (или коде поставщика) необходимо это наименование (код) изменять во всех записях, где оно встречается.
- Для устранения избыточности требуется декомпозировать отношение Поставка_товаров на два отношения:
- Поставщики = (Код поставщика: Наименование поставщика)
- Поставка = (Код поставщика: Код товара: Количество)
- Приведенная декомпозиция не является единственно возможной. Можно выделить следующие отношения:
- Поставщики = (Код поставщика: Наименование поставщика)
- Поставка = (Наименование поставщика: Код товара: Количество)
- Обычно при моделировании БД нормализацию на этом заканчивают, так как дальнейшая декомпозиция отношений замедляет обработку данных.
Четвертая нормальная форма (4НФ). Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости, не являющиеся функциональными зависимостями.
- Поясним данное определение на примере.
- Пример
- Пусть в БД требуется хранить данные об абитуриентах, поступающих в академию. При этом следует учитывать, что:
- • каждый абитуриент имеет право сдавать экзамены в несколько институтов одновременно;
- • каждый институт имеет свой список сдаваемых предметов;
- • один и тот же предмет может сдаваться в нескольких институтах;
- • абитуриент обязан сдавать весь список предметов в указанный институт.
- Таким образом, имеем следующее отношение:
- Поступающие_в_академию = (Абитуриент; Институт; Предмет)
- В данном отношении имеются трудности обновления, связанные с тем, что дублируются фамилии абитуриентов, наименования институтов и наименования предметов. Однако это легко устраняется стандартным способом — вынесением всех наименований в отдельные отношения, оставляя в исходном отношении только соответствующие номера:
- Поступающие_в_академию = (Код_абитуриента; Кодинсти- тута; Код_предмета)
- Абитуриенты = (Код_абитуриента; Абитуриент)
- Институты = (Код_института; Институт)
- Предметы = (Код_предмета; Предмет)
- Однако в модифицированном отношении Поступающие_в_ака- демию имеются трудности обновления, возникающие при попытке вставить или удалить записи.
- Например, при добавлении (или удалении) абитуриента в отношение Поступающие_в_академию требуется добавить (или удалить) несколько записей в соответствии со списком сдаваемых предметов.
- Таким образом, вставка (удаление) записей не может быть выполнена независимо от других записей отношения.
Устранение указанных трудностей декомпозицией отношения Поступающие_в_академию на основе функциональных зависимостей невозможно, так как это отношение не содержит функциональных зависимостей. Данное отношение не имеет неключевых атрибутов, все атрибуты этого отношения входят в составной ключ. Зависимость атрибутов составного ключа называется многозначной зависимостью.
- В рассматриваемом отношении можно выделить следующие многозначные зависимости:
- Код_института > >Код_абитуриента
- Код_института >> Код_предмета
- В связи с тем что отношение Поступающие_в_академию содержит многозначные зависимости, оно не находится в 4НФ. Для приведения данного отношения к 4НФ его следует декомпозировать на следующие отношения:
- Институты-Абитуриенты = (Институт; Абитуриент)
- Институты-Предметы = (Институт; Предмет)
- Следует отметить, что полученные отношения не имеют неключевых атрибутов, в них нет функциональных зависимостей.
Пятая нормальная форма (5НФ). Отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в нем определяется только его возможными ключами.
Суть зависимости по соединению заключается в следующем. Если все атрибуты отношения являются ключевыми, то при нормализации такого отношения бывают случаи, когда его можно декомпозировать не на два, а на три и более отношения. Такую зависимость между атрибутами составного ключа называют зависимостью по соединению.
Знание основных свойств и возможностей модели данных и соответствующих СУБД необходимы для качественного проектирования баз данных.
Загрузка...
