Логическое проектирование
На этом этапе создается схема данных с привязкой к конкретной модели данных, например, реляционной, иерархической, или сетевой.
Создадим схему реляционной БД. Для этого будем использовать CASE-средство Erwin Data Modeler.
Эта схема – всё ещё ER-модель, она содержит только логические данные, без какой-либо физической структуры. Однако теперь для каждой сущности определены первичные (находятся в верхней части каждой сущности, отделены чертой) и внешние (отметка FK) ключи. Для каждого атрибута может быть указан тип данных, пока довольно абстрактный – текст, число, без указания типа конкретной СУБД.
Отношения 1:М на схеме отображаются в виде линий, связывающих первичный и внешний ключи (например, связь «Команды.ID команды – Игроки.ID команды (FK)). Отношение М:М представлено в виде новой сущности – «Покупка».
Физическое проектирование
Физическое проектирование – создание схемы базы данных для конкретной СУБД. Появляются ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Общая структура схемы практически не меняется.
Физическая схема – это уже схема реальной БД. Сущности превращаются в таблицы, атрибуты – в поля таблиц. ERwin позволяет транслировать созданную схему на сервер выбранной СУБД.
Нормализация базы данных
Нормализация – приведение БД к правилам, которые помогают сохранить её целостность и удалить избыточные данные. Правила называют также нормальными формами. Всего известно 8 нормальных форм.
Первая нормальная форма (1NF)
Вторая нормальная форма (2NF)
Третья нормальная форма (3NF)
Нормальная форма Бойса-Кодда (BCNF)
Четвертая нормальная форма (4NF)
Первая нормальная форма (5NF)
Доменно-ключевая нормальная форма (DKNF)
Шестая нормальная форма (6NF)
Наиболее часто базы данных приводят к третьей нормальной форме. Дело в том, что с каждой новой НФ увеличивается количество атрибутов и таблиц в БД, в итоге – возрастает сложность запросов и уменьшается скорость работы. Существует такое понятие, как денормализация – это приведение структуры базы данных в состояние, не соответствующее критериям нормализации, с целью увеличения её производительности.
Рассмотрим подробно первые три нормальные формы.
Первая нормальная форма.
Все атрибуты должны быть атомарны, т.е. каждое поле каждой записи должно содержать неделимое значение (при любом делении атрибут теряет смысл).
Не должно быть повторяющихся атрибутов.
Каждая таблица должна содержать первичный ключ.
Рассмотрим таблицу «Библиотека». В ней хранятся данные о читателях библиотеки. Что делать, если понадобится поиск по фамилии? Неатомарные значения можно разбивать программно, однако удобнее сделать это сразу в БД. Также каждый читатель может иметь несколько номеров телефонов (сколько – заранее не известно), этот атрибут следует перенести в отдельную сущность. Приведём БД к 1НФ.
Вторая нормальная форма. Выполняется первая нормальная форма; неключевые поля должны зависеть от всего первичного ключа таблицы.
При выдаче каждой новой книги в таблице «Библиотека» приходится полностью дублировать данные о читателе, который её взял. Чтобы избежать избыточности данных, разобьём сущность «Библиотека» на 2 сущности – «Читатели» и «Выдача книг».
Обратите внимание на сущность «Выдача книг». Название книги зависит от кода книги, но не зависит от кода читателя и даты выдачи. В итоге название книги будет повторяться для каждой новой выдачи книги разным читателям. Перенесем атрибут «Название книги» в отдельную сущность «Книги».
Ключ таблицы «Книги» является подмножеством ключа таблицы «Учет книг».
Третья нормальная форма. Выполняется вторая нормальная форма; атрибуты не зависят ни от чего, кроме первичного ключа.
В сущности «Читатели» почтовый индекс зависит от названия города, в котором живет читатель, название города – от кода читателя. Появляется транзитивная зависимость «Почтовый индекс» - «Город» - «Читатель». Для разных читателей город может повторяться, значит, будет повторяться и индекс, информация станет избыточной. При этом, если не введено название города, нельзя ввести в БД почтовый индекс.
Перенесем индекс и название города в отдельную сущность «Города».
В результате всех преобразований и приведения к 3НФ в БД «Библиотека» вместо одной сущности появилось пять.
3НФ можно описать следующим образом:
Каждый атрибут таблицы зависит от ключа, от всего ключа, ни от чего, кроме ключа.