Методички по лабам ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / ПБД_метод к лабам_часть 1_v03 [2022-2023]

Определение связей

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

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

Наиболее характерными типами связей между сущностями являются:

–связи типа «часть – целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;

–классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);

–производственные связи (например, «начальник–подчиненный»);

–функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.

Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.

Связь характеризуется следующим набором параметров:

–именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;

–кратностью (кардинальность, мощность): показывает, какое количество экземпляров одной сущности определяется экземпляром другой. В ER-модели выделяют следующие типы связей (табл. 1):

o Связь 1:1 предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

o При связи 1:М одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В, но каждый экземпляр объекта В связан не более, чем с одним экземпляром объекта А. Объект А определяется как главный объект, а объект В как

подчиненный.

oСвязь М:М предполагает, что в каждый момент времени одному экземпляру информационного объекта А

21

соответствует любое количество экземпляров объекта В и наоборот.

Таблица 5

Изображение типов связей между объектами

–типом: идентифицирующая (атрибуты одной сущности, называемые внешним ключом, входят в состав дочерней и служат для идентификации ее экземпляров, т.е. входят в ее первичный ключ) и неидентифицирующая (внешний ключ имеется в дочерней сущности, но не входит в состав первичного ключа);

–обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и введенные значения должны совпадать со значениями атрибутов первичного ключа какого-либо экземпляра родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенные значения не совпадают со значениями атрибутов первичного ключа ни одного экземпляра родительской сущности);

–степенью участия – количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т.е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Группа» включает «Студентов». В то же время по степени участия возможны следующие типы связей:

oунарная (рекурсивная) – сущность может быть связана сама с собой. Например, в таблице «Работники» могут быть записи и по подчиненным, и по их начальникам. Тогда возможна связь «начальник» – «подчиненный», определенная на одной таблице;

oтернарная – связывает три сущности. Например, «Студент» на «Сессии» получил «Оценку по дисциплине»;

oкватернарная и т.д.

22

В ER-модели степень участия может быть только унарной или бинарной. Связи большей степени приводятся к бинарному виду.

Примечание:

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

2.1.3 Оптимизация инфологической модели на базе нормализации

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

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

Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма БД. Общее назначение процесса нормализации заключается в следующем:

−исключение некоторых типов избыточности;

−устранение некоторых аномалий обновления;

−разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

−упрощение процедуры применения необходимых ограничений целостности.

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

Существует несколько поэтапных нормальных форм БД:

23

Первая нормальная форма (1NF): отношение находится в первой нормальной форме, если все его атрибуты являются атомарными, т.е. состоящими из неделимых значений.

Другими словами, элемент является атомарным, если его нельзя разделить на части, которые могут использовать в таблице независимо друг от друга. Понятие атомарности является условным: будем считать значение атомарным, если оно не используется по частям

Пример не 1NF таблицы:

Таблица 6

Исходное отношение КНИГА

В этом примере Отношение КНИГИ содержит сложные атрибуты Авторы и Редакторы. Для приведения к 1НФ требуется сделать ключ отношения составным – атрибуты ISBN, Автор и Редактор.

Таблица 7

Первая нормальная форма

24

Вот, теперь эта таблица соответствует первой нормальной форме. Методы приведения к 1NF:

−Устраните повторяющиеся группы в отдельных таблицах (одинаковые строки).

−Создайте отдельную таблицу для каждого набора связанных данных.

−Идентифицируйте каждый набор связанных данных с помощью первичного ключа (добавить уникальный id для каждой строки)

Примечание:

В реальных БД сложные атрибуты разбиваются на простые, если:

−этого требует внешнее представление данных;

−в запросах поиск может осуществляться по отдельной части атрибута.

Вторая нормальная форма (2NF): отношение находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.

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

Ключом отношения КНИГА является комбинация полей (ISBN + Автор + Редактор). Все поля, не входящие в состав ключа, зависят только от идентификатора книги. Поэтому отношение должно быть разбито на два: КНИГА и КНИГА–АВТОР–РЕДАКТОР. Эти отношения связаны по внешнему ключу, которым является поле ISBN.

25

Таблица 9

КНИГА-АВТОР-РЕДАКТОР (2НФ)

Методы приведения к 2NF:

−Создайте отдельные таблицы для наборов значений, относящихся к нескольким записям.

−Свяжите эти таблицы с помощью внешнего ключа (в рассмотренном примере – это поле ISBN).

Третья нормальная форма (3NF): отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится во 2NF, и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R.

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

Для отношения КНИГА атрибут Название рубрики зависит от атрибута УДК, а не от ключа (хотя название рубрики, естественно, соответствует её шифру). Поэтому для приведения отношения к 3НФ нужно выделить из него ещё одно отношение РУБРИКАТОР.

Таблица 10

Отношение КНИГА, приведённое к 3НФ

26

Таблица 11

Отношение РУБРИКАТОР (3НФ)

УДК Название рубрики

681.3ПО ВТ

32.97ВТ

001.8Информатика

На практике, совершенствовать таблицы заканчивают на этом этапе (приведя их в третью нормальную форму).

Методы приведения к 3NF:

− Удаление полей не зависящих от ключа

Нормальная форма Бойса-Кодда (BCNF) Эта форма почти то же самое, что и третья. С одним небольшим дополнительным условием.

Основные критерии:

−Таблица находится в третьей нормальной форме

−В таблице должен быть только один потенциальный первичный ключ

Другими словами, в таблице должен быть только один первичный ключ и не должно быть других потенциальных вариантов (например, набор неключевых полей это таблицы).

Методы приведения к BCNF:

− Вынести в отдельную таблицу потенциальные первичные ключи.

Четвертая нормальная форма (4НФ)

Для отношения КНИГА–АВТОР–РЕДАКТОР атрибуты Автор и Редактор

зависит образуют две многозначные зависимости от первичного ключа, и при этом значения этих атрибутов не зависят друг от друга. Поэтому для приведения отношения к 4НФ нужно разбить его на два отношения

КНИГА–АВТОР и КНИГА–РЕДАКТОР.

27

Таблица 12

Отношение КНИГА–АВТОР (4НФ)

Таблица 13

Отношение КНИГА–РЕДАКТОР (4НФ)

2.2Пример построения инфологической модели

В разделе 1.3 приведено краткое описание предметной области.

2.2.1Пример построения концептуальной схемы

На следующем рисунке показан фрагмент концептуальной модели для БД bookiz (Рис. 5).

Выделим базовые сущности этой предметной области. Без учета финансовой информации список сущностей будет следующим:

−АВТОРЫ. Атрибуты авторов – ФИО, ИНН (индивидуальный номер налогоплательщика), паспортные данные, домашний адрес, телефоны. Для авторов необходимо хранить сведения о написанных книгах.

−КНИГИ. Атрибуты книги – авторы, название, тираж, дата выхода, цена одного экземпляра, общие затраты на издание, авторский гонорар.

28

−СОТРУДНИКИ КОМПАНИИ. Атрибуты сотрудников – ФИО, табельный номер, пол, дата рождения, паспортные данные, ИНН, должность, оклад, домашний адрес и телефоны. Для редакторов необходимо хранить сведения о редактируемых книгах; для менеджеров – сведения о подписанных контрактах.

−ЗАКАЗ. Атрибуты заказа – номер заказа, заказчик, адрес заказчика, дата поступления, дата выполнения, книга, количество.

Рис. 5. Концептуальная модель

2.2.2Пример построения логической схемы БД

Проанализируем и дополним построенную концептуальную модель БД. Между сущностями существует связь многие-ко-многим. Для ее преобразования были добавлены дополнительные таблицы:

29

– Авторы–Книги: эта сущность определена для устранения связи многие-ко-многим между авторами и книгами т.к. у одного автора может быть несколько книг.

Книги–Редакторы: эта сущность включена в диаграмму для устранения связи многие-ко-многим между редакторами и книгами, т.к. каждую книгу может редактировать множество редакторов и каждый редактор может редактировать множество книг.

– Детализация заказа: эта сущность определена для устранения связи многие-ко-многим между заказами и книгами т.к. в одном заказе может быть множество книг. Также в этой сущности добавлен атрибут Количество для обозначения количества книг.

Теперь проверим полученную модель на соответствие требованиям нормализации.

1 Нормальная форма: в сущностях Авторы и Сотрудники соответствующие атрибуты ФИО разбиты на три атрибута Фамилия + Имя + Отчество.

Что касается атрибута Паспортные данные в данных сущностях, то, учитывая специфику предметной области, разбивать данный атрибут на атрибуты Номер паспорта (уникальный), Дата выдачи и Кем выдан, нецелесообразно. Поэтому атрибут Паспортные данные считаем атомарным.

2 Нормальная форма:

В нашем случае составные первичные ключи имеют отношения Детализация заказа, Авторы–Книги и Книги–Редакторы. Не ключевые атрибуты этих отношений функционально полно зависят от первичных ключей.

3 Нормальная форма:

Всущности Книги атрибут Авторский гонорар зависит не от ISBN книги,

аот совокупности атрибутов ISBN + idАвторы (т.е. авторам, написавшим книгу, может полагаться разный гонорар в зависимости от вклада при написании книги). Поэтому атрибут Гонорар переносим в сущность Авто-

ры–Книги.

В отношении Сотрудники атрибут Оклад зависит от атрибута Должность. Поступим с этой транзитивной зависимостью следующим образом: создадим новое отношение Должность, перенесём в него атрибуты Должность и Оклад и введём суррогатный первичный ключ idДолжность. Связь с сущностью Сотрудники осуществляем по атрибуту idДолжность.

Окончательная логическая модель, соответствующая третьей нормальной форме, приведена на Рис. 6. В качестве инструмента построения использован программный продукт draw.io.

30