Файл: Базы данных - уч. пособие.pdf

4.1 Нормализация отношений

71

о том, что между атрибутами этого отношения имеется некоторая зависимость, хо-
тя она и не является ни функциональной, ни многозначной. Существующие в дан-
ном отношении зависимости называются зависимостями соединения.

Рис. 4.9 – Проекции отношения «Специальность студентов»

Рис. 4.10 – «Восстановленное» отношение «Специальность студентов»

Отношение R (X , Y ,. . ., Z) удовлетворяет зависимости соединения * (X , Y ,. . ., Z)

в том и только в том случае, когда R восстанавливается без потерь путем соедине-
ния своих проекций на X , Y ,. . ., Z. (X , Y ,. . ., Z) могут быть составными атрибута-
ми [1]. Зависимость соединения * (X , Y ,. . ., Z) называется тривиальной зависимо-
стью соединения, если выполняется одно из условий:

1) либо все множества атрибутов (X , Y ,. . ., Z) содержат потенциальный ключ

отношения R;

2) либо одно из множеств атрибутов совпадает со всем множеством атрибутов

отношения R.

Тогда получаем следующее определение.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Отношение R находится в пятой нормальной форме (нормаль-
ной форме проекции-соединения) в том и только в том случае,
когда любая зависимость соединения в R следует из существова-
ния некоторого возможного ключа в R [1].
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

Глава 4. Технология проектирования реляционных баз данных

Существует несколько более простых для понимания определений 5NF.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Отношение находится в 5NF тогда и только тогда, когда лю-
бая зависимость по соединению в нем определяется только его
возможными ключами.

Отношение R находится в пятой нормальной форме (5NF) то-
гда и только тогда, когда любая имеющаяся зависимость соеди-
нения является тривиальной.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Введем следующие имена составных атрибутов:

СГ = {Код студента, № группы};
СС = {Код студента, Код специальности};
ГС = {№ группы, Код специальности}.

Предположим, что в отношении «Студенты» существует зависимость соеди-

нения: * (СГ, СС, ГС). При определенных ограничениях предметной области эта
зависимость нетривиальна. Проведем декомпозицию нашего отношения в три но-
вых отношения, и выглядеть она будет следующим образом:

«Студенты-группы» («Код студента», «№ группы»);
«Студенты-специальности» («Код студента», «Код специальности»);
«Группы-специальности» («№ группы», «Код специальности»).

Получившиеся отношения свободны от нетривиальных зависимостей соедине-

ния и находятся в 5NF.

5NF — это последняя нормальная форма, которую можно получить путем де-

композиции отношения. На практике 5NF практически не используется.

4.1.7 Денормалилизация отношений

В некоторых случаях разработчики баз данных специально вносят различного

рода избыточности в БД, добиваясь тем самым повышения быстродействия при
выполнении запросов с ущербом для нормализации. Такой механизм получил на-
звание денормализации.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Денормализация — это процесс достижения компромиссов в нор-
мализованных отношениях посредством намеренного введения из-
быточности в целях увеличения производительности.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Фактически необходимость денормализации становится очевидной не в про-

цессе логического проектирования базы данных, а лишь на этапе создания пользо-
вательского приложения, а иногда и в ходе эксплуатации информационной систе-
мы. Например, разработчик может заметить, что добавление некоторых дополни-
тельных полей в таблицу БД позволяет значительно сократить время формирова-
ния некоторых отчетов.

4.1 Нормализация отношений

73

На рисунке 4.11 представлены два фрагмента схемы БД, содержащей две таб-

лицы — до и после денормализации.

Рис. 4.11 – Пример нисходящей денормализации

Здесь показана так называемая «нисходящая денормализация», когда в табли-

цу, содержащую внешний ключ, добавляется непосредственно атрибут, который
этот внешний ключ определяет (в нашем примере — ФИО покупателя). При та-
кой денормализации в случае выполнения запроса, в котором при формировании
данных по счетам необходимо выдать ФИО покупателя, мы избежим выполнения
операции соединения таблиц «Заказ» и «Покупатель».

На рисунке 4.12 приведен пример восходящей денормализации.

Рис. 4.12 – Пример восходящей денормализации

Здесь в таблицу «Заказ» добавляется поле, содержащее общую стоимость зака-

за. Тогда, в случае формирования некоторого итогового отчета, мы освобождаемся
от выполнения запроса на вычисление суммы всех позиций заказа.

74

Глава 4. Технология проектирования реляционных баз данных

При кажущейся простоте денормализации необходимо учитывать, что ее ис-

пользование приводит к явным избыточностям в хранении данных, а также мо-
жет привести к несогласованности информации при ведении базы данных — если
содержимое внешних ключей контролируется средствами СУБД, то контроль за
содержимым избыточных атрибутов возлагается на разработчика или на непосред-
ственного пользователя информационной системы.

4.2 Моделирование данных с помощью диаграмм
«сущность-связь»

4.2.1 Основные понятия модели «сущность-связь»

При проектировании информационных систем иногда трудно моделировать

предметную область на основе отношений. Реляционная модель в полной мере
не дает представления о семантике предметной области. Потребности проектиров-
щиков баз данных в более удобных и мощных средствах моделирования предмет-
ной области вызвали к жизни новое направление — проектирование семантических
моделей данных. Главным назначением семантических моделей является обеспе-
чение возможности выражения семантики данных [1].

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Семантическое моделирование представляет собой моделирова-
ние структуры данных, опираясь на смысл этих данных.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

На начальном этапе анализа предметной области и проектирования БД в идео-

логии семантической модели проектируется концептуальная модель предметной
области, которая затем преобразуется к физической модели и затем к схеме реля-
ционной БД. Этот процесс может выполняться как вручную, так и с помощью
различных программных средств. В результате этих преобразований на основе
семантической модели производится схема реляционной базы данных в третьей
нормальной форме с учетом специфики конкретной СУБД. Чем более разнородна
входная информация по структуре и содержанию, чем менее она унифицирована,
тем больше внимания необходимо уделять семантическому моделированию.

Мы будем рассматривать одну из разновидностей семантического моделиро-

вания, получившую в последние годы большую популярность среди проектиров-
щиков БД — модель «сущность-связь», или ER-модель (Entity-Relationship-model).
Методология ER-модели была разработана Ченом (Chen) в середине 70-х годов
XX века и получила дальнейшее развитие в работах Баркера. Идея моделирова-
ния предметной области заключается в возможности использования графических
диаграмм, включающих необходимые для описания предметной области сущности
и связи между ними. Благодаря простоте восприятия и наглядности представления
ER-модели нашли широкое применение в CASE-системах, обеспечивающих авто-
матизированное проектирование БД.

Необходимо отметить, что одна нотация представления ER-диаграмм может

несколько отличаться от другой. Однако термины и элементы, которыми опериру-

4.2 Моделирование данных с помощью диаграмм «сущность-связь»

75

ют при разработке модели, присутствуют всегда и несут идентичную смысловую
нагрузку. В настоящее время наиболее распространенной нотацией, используемой
в средствах автоматизированного проектирования, являются нотация Баркера (и ее
производные), а также нотация IDEF1X.

Мы будем рассматривать примеры, представленные в нотации, используемой

при создании концептуальной модели данных (Conceptual data model) в среде авто-
матизированного моделирования PowerDesigner — она представляет собой расши-
рение нотации Баркера — нотации Information engineering и Merise.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Заметим, что проектировщики могут самостоятельно настроить
в среде PowerDesigner варианты представления ER-диаграмм.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

В ER-модели используются понятия сущности предметной области, связей

между ними и атрибутов сущностей.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Сущность — это объект предметной области, элемент информа-
ционной системы или, другими словами, класс однотипных объек-
тов, информация о которых должна быть учтена в модели. В ER-
модели сущность представляется в виде прямоугольника, содер-
жащего имя сущности и наименования ее атрибутов.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Каждая сущность должна иметь имя, выраженное существительным в един-

ственном числе (Студент, Адрес, Сотрудник) (рис. 4.13).

Рис. 4.13 – Пример графического изображения сущности «Студент»

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Экземпляр сущности — это конкретный представитель данной
сущности.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Например, представителем сущности «Студент» может быть «Студент Иванов».

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Атрибут сущности — это именованная характеристика модели-
руемого сущностью объекта, являющаяся некоторым свойством
сущности. Наименование атрибута должно быть выражено су-
ществительным в единственном числе (возможно, с характери-
зующими прилагательными).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .