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