Реляционная база данных – это упорядоченная информация, связанная между собой определёнными отношениями. Логически такая база данных представлена в виде таблиц, в которых и лежит вся эта информация. Нормализация – это процесс удаления избыточных данных. Нормализация – это метод проектирования базы данных, который позволяет привести базу данных к минимальной избыточности.
Избыточность данных – это когда одни и те же данные хранятся в базе в нескольких местах, именно это и приводит к аномалиям. Избыточность данных создает предпосылки для появления различных аномалий, снижает производительность, и делает управление данными не гибким и не очень удобным. Т.е., нормализация нужна для: Устранения аномалий Повышения производительности Повышения удобства управления данными
Идентификатор предмета Наименование предмета Материал 1 Стул Металл 2 Стол Массив дерева 3 Кровать ЛДСП 4 Шкаф Массив дерева 5 Комод ЛДСП
Идентификатор предмета Наименование предмета Материал 1 Стул Металл 2 Стол Натуральное дерево 3 Кровать ЛДСП 4 Шкаф Массив дерева 5 Комод ЛДСП
Идентификатор предмета Наименование предмета Материал 1 Стул Металл 2 Стол Натуральное дерево 3 Кровать ЛДСП 4 Шкаф Массив дерева 5 Комод ЛДСП 6 Тумба Дерево При этом Натуральное дерево, Массив дерева и Дерево это все еще один материал. Просто изменения вносили разные люди.
ID предмета Наименование ID материала 1 Стул 2 2 Стол 1 3 Кровать 3 4 Шкаф 1 5 Комод 3 ID материала Материал 1 Массив дерева 2 Металл 3 ЛДСП
Нормальная форма базы данных – это набор правил и критериев, которым должна отвечать база данных. Каждая следующая нормальная форма содержит более строгие правила и критерии, тем самым приводя базу данных к определённой нормальной форме мы устраняем определённый набор аномалий. Чем выше нормальная форма, тем меньше аномалий в базе будет. Процесс нормализации – это последовательный процесс приведения базы данных к эталонному виду, т.е. переход от одной нормальной формы к следующей.
Первая нормальная форма (1NF) Вторая нормальная форма (2NF) Третья нормальная форма (3NF) Четвертая нормальная форма (4NF) Пятая нормальная форма (5NF)
Ненормализованная форма или нулевая нормальная форма (UNF) Нормальная форма Бойса -Кодда (BCNF) Доменно-ключевая нормальная форма (DKNF) Шестая нормальная форма (6NF)
Ненормализованная форма или нулевая нормальная форма (UNF) Первая нормальная форма (1NF) Вторая нормальная форма (2NF) Третья нормальная форма (3NF) Нормальная форма Бойса -Кодда (BCNF) Четвертая нормальная форма (4NF) Пятая нормальная форма (5NF) Доменно-ключевая нормальная форма (DKNF) Шестая нормальная форма (6NF) Если БД находится в какой-либо НФ, она находится и во всех предыдущих!
Требование первой нормальной формы (1NF) заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы. Таким образом, чтобы база данных находилась в 1 нормальной форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы: В таблице не должно быть дублирующих строк В каждой ячейке таблицы хранится атомарное значение (одно не составное значение) В столбце хранятся данные одного типа Отсутствуют массивы и списки в любом виде
Строки, столбцы и ячейки в таблицах необходимо использовать строго по назначению. Назначение строк – хранить данные Назначение столбцов – хранить структурную информацию Назначение ячеек – хранить атомарное значение
Сотрудник Контакт Иванов И.И. 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), необходимо чтобы ее таблицы удовлетворяли следующим требованиям: Таблица должна находиться в первой нормальной форме Таблица должна иметь ключ Все неключевые столбцы таблицы должны зависеть от полного ключа ( в случае если он составной ) Если ключ составной, т.е. состоит из нескольких столбцов, то все остальные неключевые столбцы должны зависеть от всего ключа, т.е. от всех столбцов в этом ключе. Если какой-то атрибут (столбец) зависит только от одного столбца в ключе, значит, база данных не находится во второй нормальной форме. Иными словами, в таблице не должно быть данных, которые можно получить, зная только половину ключа, т.е. только один столбец из составного ключа.
Таблица должна иметь правильный ключ, по которому можно идентифицировать каждую строку.
ФИО Должность Подразделение Описание подразделения Иванов И.И. Программист Отдел разработки Разработка и сопровождение приложений и сайтов Сергеев С.С. Бухгалтер Бухгалтерия Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности John Smith Продавец Отдел реализации Организация сбыта продукции Таблица сотрудников в первой нормальной форме.
Табельный номер ФИО Должность Подразделение Описание подразделения 1 Иванов И.И. Программист Отдел разработки Разработка и сопровождение приложений и сайтов 2 Сергеев С.С. Бухгалтер Бухгалтерия Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности 3 John Smith Продавец Отдел реализации Организация сбыта продукции Таблица сотрудников во второй нормальной форме с простым первичным ключом.
Если первичный ключ простой (не составной, т.е. состоящий из одного столбца), второе требование, которое предъявляется к таблицам для перехода во вторую нормальную форму, выполнять не требуется, так как оно относится только к таблицам, у которых первичный ключ составной.
Название проекта Участник Должность Срок проекта (мес.) Внедрение приложения Иванов И.И. Программист 8 Внедрение приложения Сергеев С.С. Бухгалтер 8 Внедрение приложения John Smith Менеджер 8 Открытие нового магазина Сергеев С.С. Бухгалтер 12 Открытие нового магазина John Smith Менеджер 12 Таблица проектов организации в первой нормальной форме.
Название проекта Участник Должность Срок проекта (мес.) Внедрение приложения Иванов И.И. Программист 8 Внедрение приложения Сергеев С.С. Бухгалтер 8 Внедрение приложения John Smith Менеджер 8 Открытие нового магазина Сергеев С.С. Бухгалтер 12 Открытие нового магазина John Smith Менеджер 12 Таблица проектов организации. Внедрен составной первичный ключ.
Так как первичный ключ составной, необходимо проверить еще и второе требование, которое гласит, что «Все неключевые столбцы таблицы должны зависеть от полного ключа». Другими словами, остальные столбцы, которые не входят в первичный ключ, должны зависеть от всего первичного ключа, т.е. от всех столбцов, а не от какого-то одного. Чтобы это проверить, можно задать себе несколько вопросов. Можем ли мы определить «Должность», зная только название проекта? Нет. Для этого необходимо знать и участника. Значит, пока все хорошо. Идем дальше и проверяем другую часть ключа. Можем ли мы определить «Должность» зная только участника? Да, можем. Значит первичный ключ плохой, и требование второй нормальной формы не выполняется.
Что делать в этом случае? Выполнить декомпозицию. Декомпозиция – это процесс разбиения одного отношения (таблицы) на несколько.
Проекты ID проекта Название проекта Срок проекта (мес.) 1 Внедрение приложения 8 2 Открытие нового магазина 12 Участники ID участника Участник Должность 1 Иванов И.И. Программист 2 Сергеев С.С. Бухгалтер 3 John Smith Менеджер Связь проектов и участников этих проектов ID проекта ID участника 1 1 1 2 1 3 2 2 2 3
Требование третьей нормальной формы (3NF) заключается в том, чтобы в таблицах отсутствовала транзитивная зависимость. Транзитивная зависимость – это когда неключевые столбцы зависят от значений других неключевых столбцов.
Таблица должна содержать правильные неключевые столбцы.
Табельный номер ФИО Должность Подразделение Описание подразделения 1 Иванов И.И. Программист Отдел разработки Разработка и сопровождение приложений и сайтов 2 Сергеев С.С. Бухгалтер Бухгалтерия Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности 3 John Smith Продавец Отдел реализации Организация сбыта продукции Таблица сотрудников во второй нормальной форме.
Столбец «Описание подразделения» не зависит напрямую от первичного ключа. Мы это выяснили, когда задали себе один вопрос «Каким образом описание подразделения связано с сотрудником?». Ответ: «Атрибут описание подразделения содержит детальные сведения того подразделения, в котором работает сотрудник». Решение: декомпозиция на 2 таблицы.
Табельный номер ФИО Должность Подразделение 1 Иванов И.И. Программист 1 2 Сергеев С.С. Бухгалтер 2 3 John Smith Продавец 3 Таблица сотрудников в третьей нормальной форме.
Идентификатор подразделения Подразделение Описание подразделения 1 Отдел разработки Разработка и сопровождение приложений и сайтов 2 Бухгалтерия Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности 3 Отдел реализации Организация сбыта продукции Таблица подразделений в третьей нормальной форме.
Требования нормальной формы Бойса -Кодда следующие: Таблица должна находиться в третьей нормальной форме. Здесь все как обычно, т.е. как и у всех остальных нормальных форм, первое требование заключается в том, чтобы таблица находилась в предыдущей нормальной форме, в данном случае в третьей нормальной форме; Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов. Отсюда следует, что требования нормальной формы Бойса -Кодда предъявляются только к таблицам, у которых первичный ключ составно й. Таблицы, у которых первичный ключ простой, и они находятся в третьей нормальной форме, автоматически находятся и в нормальной форме Бойса -Кодда.
Часть составного первичного ключа не должна зависеть от неключевого столбца.
Проект Направление Куратор 1 Разработка Иванов И.И. 1 Бухгалтерия Сергеев С.С. 2 Разработка Иванов И.И. 2 Бухгалтерия Петров П.П. 2 Реализация John Smith 3 Разработка Андреев А.А. При этом по описанию предметной области курировать проект может только человек, чья профессия совпадает с направлением. Таблица проектов и кураторов в 3 НФ.
Идентификатор куратора ФИО Направление 1 Иванов И.И. Разработка 2 Сергеев С.С. Бухгалтерия 3 Петров П.П. Бухгалтерия 4 John Smith Реализация 5 Андреев А.А. Разработка Таблица кураторов.
Проект Идентификатор куратора 1 1 1 2 2 1 2 3 2 4 3 5 Таблица связи кураторов и проектов.
