Лекция АИС

Рис. .8. Фрагмент концептуальной информационной модели

В концептуальной модели выделены следующие логические блоки данных:

нормативно-справочная информация;

информация об участках дороги;

задание на расчет;

ведомости допускаемых скоростей;

проект Приказа «Н» (на рис. .8 не показан);

Формы № 1, 1а и 2 (на рис. .8 не показан).

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

.4. Логическое проектирование с использованием методологии IDEF1X

Цель логического проектирования – развить концептуальное представление БД с учетом принимаемой модели БД (иерархической, сетевой, реляционной и т. д.).

Примем в качестве модели реляционную БД в третьей нормальной форме (набор нормализованных отношений с кратностью связей 1:N). Поэтому необходимо будет проверить концептуальную модель с помощью методов нормализации и контроля выполнения транзакций [1, 20, 21]. Транзакция – одно действие или их последовательность, выполняемых как единое целое одним или несколькими пользователями (прикладными программами) с целью осуществления доступа к БД и изменению ее содержимого.

1. Удаление и проверка элементов, не отвечающих принятой модели данных. 1.1. Удаление связей N:M.

Если в концептуальной модели присутствуют связи N:M, то их следует устранить путем определения промежуточной сущности. Связь N:M заменяется двумя связями типа 1:M, устанавливаемыми со вновь созданной сущностью (рис. .9).

11

Рис. .9. Замена связи N:M

1.2. Удаление связей с атрибутами.

Связи с атрибутами должны быть преобразованы в сущности.

Вразработанной концептуальной модели существовала связь N:M («Раздельные пункты» : «Пути»), которая имела собственные атрибуты. После устранения связь N:M, ее атрибуты перешли в сущность «Раздельные пункты на пути» (см. рис. .9, неключевые атрибуты).

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

1.3. Удаление сложных связей (со степенью участия более 2).

Сложную связь заменяют необходимым количеством бинарных связей 1:N со вновь созданной сущностью, которая и показывает эту связь.

12

Рис. .11. Удаление многозначных атрибутов

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

1.6. Удаление избыточных связей.

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

Рис. .12. Избыточные связи

Вприведенном примере одну из связей «Руководит» можно смело удалить (лучше между «Руководителем филиала» и «Сотрудником»).

1.. Перепроверка связей 1:1.

Впроцессе определения сущностей могли быть созданы сущности, которые на самом деле являются одной. В этом случае их следует объединить. Например, в приведенном выше примере (рис. 46) сущности «Филиал» и «Руководитель филиала» лучше объединить.

Вто же время не всегда можно выполнить такое объединение (рис. .13).

14

Рис. .13. Связи 1:1

Офисный пакет состоит из строго определенного набора компонентов, причем каждый из них характеризуется большим количеством атрибутов. Кроме этого, некоторые компоненты могут отсутствовать в офисном пакете (например, почтовый клиент) или они не входят в его состав (выступают в качестве самостоятельного продукта). В описанных случаях рекомендуется не объединять сущности.

2. Проверка модели с помощью правил нормализации.

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

Ниже приводятся краткие сведения из теории нормализации.

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

Функциональная зависимость определяется следующим образом. Пусть A и B – произвольные наборы атрибутов отношения. Тогда B функционально зависит от A (A → B), в том и только в том случае, если каждому значению A соответствует в точности одно значение B. Левая часть функциональной зависимости (A) называется детерминантом, а правая (B) –зависимой частью. В частности, в отношении А может быть первичным ключом, а B – набором неключевых атрибутов, так как одному значению первичного ключа в точности соответствует одно значение набора неключевых атрибутов.

Если в БД отсутствуют нежелательные функциональные зависимости, то это обеспечивает минимальную избыточность данных, что в свою очередь ведет к уменьшению объема памяти, необходимой для хранения данных. Процесс устранения таких зависимостей получил название нормализация. Она выполняется в виде последовательности тестов для некоторого отношения (таблицы, сущности) с целью проверки его соответствия ( или несоответствия) набору ограничений для заданной нормальной формы.

Процесс нормализации впервые был предложен Э.Ф. Коддом в 192 г. Сначала было предложено три вида нормальных форм (1NF, 2NF и 3NF). Затем Р. Бойсом и Э.Ф. Коддом (194 г.) было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальная форма Бойса–Кодда (BCNF). Вслед за BCNF появились определения четвертой (4NF) и пятой (5NF или PJNF) нормальных форм (Р. Фагин, 19 и 199 г.). На практике нормальные формы более высоких порядков используются крайне редко. При проектировании БД, как правило, ограничиваются третьей нормальной формой, что позволяет предотвратить возможное возникновение избыточности данных и аномалии обновлений.

1NF. Отношение находится в 1NF, если на пересечении каждого столбца и строки находятся только элементарные (атомарные, неделимые) значения атрибутов.

Степень неделимости (атомарности), т. е. решение о том, следует разбивать неатомарный атрибут на атомарные или оставить его псевдоатомарным, определяется проектировщиком БД исходя из конкретных условий. Если при обработке таблиц нет необходимости различать атомарные составляющие псевдоатомарного атрибута, то его можно не делить (например, атрибуты «Фамилия, имя, отчество», «Адрес» и т. д.).

15

Рис. .15. Устранение транзитивной зависимости

BCNF. Отношение находится в BCNF, если оно находится в 3NF и каждый детерминант отношения является его возможным ключом.

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

Например, таблица «Поставка деталей» характеризуется набором атрибутов {ID поставщика, Наименование поставщика, ID детали, Количество деталей}, потенциальные ключи – {ID поставщика, ID детали} и {Наименование поставщика, ID детали}. Подразумевается, что не может быть двух поставщиков с одним наименованием. Атрибут «ID поставщика» характеризуется полной функциональной зависимостью от атрибута «Наименование поставщика» и наоборот. Чтобы устранить эту нежелательную зависимость, следует один из этих ключей принять в качестве первичного и добавить новую таблицу, куда вынести два указанных атрибута (рис. .16).

17

Рис. .16. Приведения отношения к BCNF

Отличие BCNF от 2NF заключается в том, что выносимый в отдельную таблицу атрибут («Наименование поставщика») входит в состав потенциального ключа, а не является простым неключевым атрибутом («ФИО студента» и «№ группы» на рис. .14).

4NF. Отношение находится в 4NF в том и только в том случае, если в нем отсутствуют нетривиальные многозначные зависимости.

Нетривиальная многозначная зависимость. В отношении с атрибутами А, В и С существует нетривиальная многозначная зависимость, если для каждого значения атрибута А имеется набор значений атрибута В (A −>> B) и набор значений атрибута С (A −>> С), но между атрибутами В и С нет зависимостей.

Например, таблица «Экзамены» характеризуется набором атрибутов {Номер группы, Номер зачетной книжки, Дисциплина}, первичный ключ – весь набор атрибутов. В данной таблице имеется две многозначные зависимости: номер группы определяет список студентов, которые в ней учатся (Номер группы −>> Номер зачетной книжки), и номеру группы соответствует список дисциплин учебного плана, по которым требуется сдавать экзамены (Номер группы −>> Дисциплина). В то же время между номером зачетной книжки и дисциплиной зависимость отсутствует. Для приведения таблицы к 4NF требуется разбить ее на две (рис. .1).

18

Рис. .1. Приведения отношения к 4NF

5NF (нормальная форма проекции соединения, PJNF). Отношение находится в 5NF, если в нем нет зависимостей соединения.

Зависимость соединения. В отношении с атрибутами А, В и С существует зависимость соединения, если для каждого значения атрибута А имеется набор значений атрибута В (A −>> B) и набор значений атрибута С (A −>> С), а также существует многозначная зависимость между атрибутами В и С (В −>> С или С −>> B).

Например, таблица «Дисциплины» характеризуется набором атрибутов {Кафедра, Преподаватель, Дисциплины}, первичный ключ – весь набор атрибутов. В данной таблице имеется несколько многозначных зависимостей: на кафедре работает несколько преподавателей (Кафедра −>> Преподаватель), кафедра ведет несколько дисциплин учебного плана (Кафедра −>> Дисциплина), преподаватель может вести несколько дисциплин (Преподаватель −>> Дисциплина) и, наоборот, одну дисциплину могут вести разные преподаватели (Дисциплина −>> Преподаватель). Для устранения зависимости соединения следует разбить исходную таблицу на три (рис. .18).

19

Рис. .18. Приведения отношения к 5NF

3. Проверка выполнения транзакций.

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

изменение наименования раздельного пункта;

удаление задания на расчет;

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

4. Определение требований поддержки целостности данных.

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

данных.

К этим ограничениям относятся:

обязательные данные – атрибуты, которые всегда должны содержать одно из допустимых значений (NOT NULL). Например, поворот кривой (влево или вправо) должен быть обязательно задан. Обязательными также являются все атрибуты, входящие в первичный ключ сущности;

домены – наборы допустимых значений для атрибута. Например, радиус кривой должен быть положительным числом не более 4 цифр или поворот кривой может принимать одно из двух допустимых значений – «Л» (влево) или «П» (вправо);

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

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

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

o аналогичное требование выдвигается при обновлении внешнего ключа в дочерней сущности;

20