ER -диаграммы

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

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Путевки

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждой путевке соответствует ее оплата (оплат может быть и несколько, если путевка, например, продана в кредит).

Каждый тур может иметь несколько сезонов.

Путевка продается на один сезон одного тура.

Эти объекты и отношения могут быть представлены ER- диаграммой, как показано на рис 2.

Рис. 2. ER-диаграмма для приложения БД менеджера турфирмы

Объекты, атрибуты и ключи

Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта - это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.

Таблица 2. Объекты и атрибуты БД

Объект	Туристы	Путевки	Туры	Сезоны	Оплаты
			Название	Дата начала	Дата оплаты
				Дата конца
	Отчество		Информация
Атрибуты

Следует обратить внимание, что несколько элементов отсутствуют. Опущена регистрационная информация, упомянутая в функциональной спецификации. Как ее учесть, вы подумаете самостоятельно и доработаете предложенный пример. Но более важно то, что пока отсутствуют атрибуты, необходимые для связи объектов друг с другом. Эти элементы данных в ER-модели не представляются, так как не являются, собственно, «натуральными» атрибутами объектов. Они обрабатываются по-другому и будут учтены в реляционной модели данных.

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

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

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

Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 3).

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

Таблица 3. Объекты и атрибуты БД с расширенными кодовыми полями

Объект	Туристы	Путевки	Туры	Сезоны	Оплаты
Атрибуты	Код туриста	Код путевки		Код сезона	Код оплаты
		Код туриста	Название	Дата начала	Дата оплаты
		Код сезона		Дата конца
	Отчество		Информация		Код путевки

Нормализация

Функциональные зависимости проявляются, когда значение одного атрибута может быть определено из значения другого атрибута. Атрибут, который может быть определен, называется функционально зависимым от атрибута, который является детерминантом. Следовательно, по определению, все неключевые (без ключа) атрибуты будут функционально зависеть от первичного ключа в каждом отношении (так как первичный ключ уникально определяет каждую строку). Когда один атрибут отношения уникально не определяет другой атрибут, но ограничивает его набором предопределенных значений, это называется многозначной зависимостью. Частичная зависимость имеет место, когда атрибут отношения функционально зависит от одного атрибута составного ключа. Транзитивные зависимости наблюдаются, когда неключевой атрибут функционально зависит от одного или нескольких других неключевых атрибутов в отношении.

Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).

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

2. Вторая нормальная форма (2НФ) создается тогда, когда удалены все частичные зависимости из отношений БД. Если в отношениях не имеется никаких составных ключей, то этот уровень нормализации легко достигается.

3. Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.

4. Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.

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

Обратите внимание, что они существуют только относительно различных видов зависимостей атрибутов БД. Есть зависимости - нужно стоить НФ БД, нет зависимостей - БД и так находится в НФ. Но последний вариант практически не встречается в реальных приложениях.

Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?

Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.

Рис. 3. Пример транзитивной зависимости

Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.

Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа - «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» - внешним.

Логическая модель – графическое представление структуры базы данных с учетом принимаемой модели данных (иерархической, сетевой, реляционной и т.д.), независимое от конечной реализации базы данных и аппаратной платформы. Иными словами, онапоказывает, ЧТО хранится в базе данных (объекты предметной области, их атрибуты и связи между ними), но не отвечает на вопрос КАК (рис. 1).

Описание предметной области:

Оптовый заводск ой склад

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

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

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

Поставщики переходят в разряд постоянных, если они совершили поставок на сумму свыше 1 000 000 рублей в год.

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

Рис. 1. Логическая модель базы данных в нотации IDEF1X

Методология IDEF1 X – один из подходов к моделированию данных, основанный на концепции "сущность – связь" (Entity – Relationship ), предложенной Питером Ченом в 1976 г.

Таблица 2.1. Основные элементы нотации IDEF1X
Сущность (Entity)	Графическое изображение
Независимая сущность	Наименование Уникальный идентификатор Атрибуты
Зависимая сущность	Атрибуты
Связь (Relationship)	Графическое изображение
Неидентифицирующая связь
Идентифицирующая связь
Связь «Многие ко многим»
Наследование (обобщение) Неполное	Родительск.

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

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

Методология IDEF1X ориентирована на проектирование реляционных моделей баз данных. В основе реляционной модели лежит понятие нормализованного отношения (таблицы). При этом сущности предметной области отображаются в таблицы базы данных (рис. 2), обладающие следующими свойствами:

Рис.
2. Таблица реляционной базы данных

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

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

уникальность (не может быть строк с одинаковым ключом);

неизбыточность (удаление любого атрибута из ключа лишает его свойства уникальности).

Реляционная база данных − это множество связанных между собой отношений. Связи задаются с помощью вторичных ключей (Foreign key – FK), т.е. атрибутов, которые в других отношениях являются первичными ключами (Primary key – PK).

Основные ограничения целостности реляционной модели:

атрибуты из первичного ключа не могут принимать неопределенное значение (целостность объектов);

вторичные ключи не могут принимать значения, которых нет среди значений первичных ключей связанной таблицы: если отношение R2 имеет среди своих атрибутов какой-то внешний ключ (FK), который соответствует первичному ключу (PK) отношения R1, то каждое значение FK должно быть равно одному из значений PK.

Создание Логической модели БД в Visio

Чтобы создать Логическую модель базы данных в Visio2013, выберите Категорию шаблонов «Программы и базы данных», а в ней шаблон «Схема модели базы данных» (рис. 2.3)	Рис. 2.3. Шаблон «Схема модели базы данных»
Прежде, чем приступить к созданию Логической модели, зайдите на вкладку «База данных» и в «Показать параметры» выставьте следующие настройки (рис. 2.4-2.6).	Рис. 2.4.Параметры документа (вкладка «Общие»)
Рис. 2.6.Параметры документа (вкладка «Отношение»)	Рис. 2.5.Параметры документа (вкладка «Таблица»)
Чтобы создать Сущность «Деталь», перетащите стереотип Сущность с панели инструментов на экран (рис. 2.7).	Рис. 2.7.Создание Сущности
Задайтеимяновой Сущности в свойствах в нижней части экрана (рис. 2.8).	Рис. 2.8.Свойства Сущности («Определение»)
Затем на вкладке Столбцы создайте атрибуты Сущности, отметьте уникальный идентификатор (первичный ключ) галочкой в столбце PK и нажмите кнопку «ОК» (рис. 2.9).	Рис. 2.9.Свойства Сущности («Столбцы»)
Аналогично создайте вторую сущность, например «Материал». Чтобы создать связь между ними, перетащите стереотип «Отношение» точкой на изображение класса «Деталь», т.к. из каждого материала изготавливается ноль, одна или несколько деталей. Затем второй конец связи перетащите на изображение класса «Материал» (рис. 2.10). Внешний ключ «Код материала (FK)» автоматически появится в составе атрибутов сущности «Деталь». Незакрашенный ромб со стороны Материала означает, что материал может быть не указан. Чтобы убрать ромб, откройте свойства сущности «Деталь» и поставьте этому атрибуту галочку в столбце «Обязательное».	Рис. 2.10.Свойства отношения («Определение»)

Задание : постройтелогическую модель базы данных в соответствии с описанием предметной области из вашего варианта задания.

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

Логические модели представления знаний реализуются средствами логики предикатов.

Предикатом называется функция, принимающая два значения (истина или ложь) и предназначенная для выражения свойств объектов или связей между ними. Выражение, в котором утверждается или отрицается наличие каких-либо свойств у объекта, называется высказыванием . Константы служат для именования объектов предметной области. Логические предложения или высказывания образуют атомарные формулы . Интерпретация предиката - это множество всех допустимых связываний переменных с константами. Связывание представляет собой под­становку констант вместо переменных. Предикат считается обще­зна­чи­мым, если он истинен во всех возможных интерпретациях. Говорят, что выска­зывание логически следует из заданных посылок, если оно истинно всег­да, когда истинны посылки.

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

ДАТЬ (МИХАИЛ, ВЛАДИМИРУ, КНИГУ);

($x) (ЭЛЕМЕНТ (x, СОБЫТИЕ-ДАТЬ) ? ИСТОЧНИК (x, МИХАИЛ) ? АДРЕСАТ? (x, ВЛАДИМИР) ОБЪЕКТ(x, КНИГА).

Здесь описаны два способа записи одного факта: «Михаил дал книгу Владимиру».

Логический вывод осуществляется с помощью силлогизма (если из A следует B, а из B следует C, то из A следует C).

В общем случае в основе логических моделей лежит понятие формальной теории , задаваемой четверкой:

S = ,

где B - счетное множество базовых символов (алфавит) теории S;

F - подмножество выражений теории S, называемые формулами теории (под выражениями понимаются конечные последовательности базовых символов теории S);

A - выделенное множество формул, называемые аксиомами теории S, то есть множество априорных формул;

R - конечное множество отношений {r 1 , …, r n } между формулами, называемые правилами вывода .

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

Покажем метод резолюций.

В методе используется несколько понятий и теорем.

Понятие тавтологии , логической формулы, значением которой будет «истина» при любых значениях входящих в них атомов. Обозначается?, читается как «общезначимо» или «всегда истинно».

Теорема 1. А?В тогда и только тогда, когда?А В.

Теорема 2. А1, А2, ..., Аn ? В тогда и только тогда, когда? (A1?A2?A3?…?An) В.

Символ? читается как «верно, что» или «можно вывести».

В основе метода лежит доказательство тавтологии

? (X ? A) ?(Y ? ? A)?(X ? Y ) .

Теоремы 1 и 2 позволяют записать это правило в следующем виде:

(X ? A), (Y ? ? A) ? (X ? Y ),

что дает основания утверждать: из посылок и можно вывести .

В процессе логического вывода с применением правила резолюции выполняются следующие шаги.

1. Устраняются операции эквивалентности и импликации:

2. Операция отрицания продвигается внутрь формул с помощью законов де Моргана:

3. Логические формулы приводятся к дизъюнктивной форме: .

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

Предположим, нужно доказать, что если истинны соотношения и , то можно вывести формулу . Для этого нужно выполнить следующие шаги.

1.Приведение посылок к дизъюнктивной форме:
, , .

2.Построение отрицания выводимого заключения . Полученная конъюнкция справедлива, когда и одновременно истинны.

3.Применение правила резолюции:

(противоречие или «пустой дизъюнкт»).

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

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

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

Алгоритм унификации предикатных логических формул включает следующие шаги.

После выполнения всех шагов описанного алгоритма унификации можно применять правило резолюции, Обычно при этом осуществляется отрицание выводимого заключения, и алгоритм вывода можно кратко описать следующим образом: Если задано несколько аксиом (теория Тh) и предстоит сделать заключение о том, выводима ли некоторая формула Р из аксиом теории Тh, строится отрицание Р и добавляется к Тh, при этом получают новую теорию Тh1. После приведения и аксиом теории к системе дизъюнктов можно построить конъюнкцию и аксиом теории Тh. При этом существует возможность выводить из исходных дизъюнктов дизъюнкты - следствия. Если Р выводимо из аксиом теории Тh, то в процессе вывода можно получить некоторый дизъюнкт Q, состоящий из одной литеры, и противоположный ему дизъюнкт . Это противоречие свидетельствует о том, что Р выводимо из аксиом Тh. Вообще говоря, существует множество стратегий доказательства, нами рассмотрена лишь одна из возможных - нисходящая.

Пример: представим средствами логики предикатов следующий текст:

«Если студент умеет хорошо программировать, то он может стать специалистом в области прикладной информатики».

«Если студент хорошо сдал экзамен по информационным системам, значит, он умеет хорошо программировать».

Представим этот текст средствами логики предикатов первого порядка. Введем обозначения: X - переменная для обозначения студента; хорошо - константа, соответствующая уровню квалификации; Р(Х) - предикат, выражающий возможность субъекта X стать специалистом по прикладной информатике; Q (Х, хорошо) - предикат, обозначающий умение субъекта X программировать с оценкой хорошо ; R (Х, хорошо) - предикат, задающий связь студента X с экзаменационной оценкой по информационным системам.

Теперь построим множество правильно построенных формул:

Q(Х, хорошо) .

R (Х, хорошо) Q (Х, хорошо).

Дополним полученную теорию конкретным фактом
R (иванов, хорошо) .

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

Доказательство

1. Выполним преобразование исходных формул теории в целях приведения к дизъюнктивной форме:

(Х, хорошо) Р(Х);

(Х,хорошо) (Х,хорошо);

R (иванов , хорошо).

2. Добавим к имеющимся аксиомам отрицание выводимого заключения

(иванов).

3. Построим конъюнкцию дизъюнктов

(Х, хорошо) Р(Х) ? ? P (иванов, хорошо) ? ? Q (иванов, хорошо), заменяя переменную X на константу иванов .

Результат применения правила резолюции называют резольвентой . В данном случае резольвентой является (иванов).

4. Построим конъюнкцию дизъюнктов с использованием резольвенты, полученной на шаге 3:

(Х, хорошо) (Х, хорошо) (иванов, хорошо) (иванов, хорошо).

5. Запишем конъюнкцию полученной резольвенты с последним дизъюнктом теории:

(иванов, хорошо) (иванов, хорошо) (противоречие).

Следовательно, факт Р(иванов ) выводим из аксиом данной теории.

Для определения порядка применения аксиом в процессе вывода существуют следующие эвристические правила:

1. На первом шаге вывода используется отрицание выводимого заключения.
2. В каждом последующем шаге вывода участвует резольвента, полученная на предыдущем шаге.

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

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

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

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

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

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

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

■ в отношении нет одинаковых кортежей;

■ кортежи не упорядочены;

■ атрибуты не упорядочены и различаются по наименованиям;

■ все значения атрибутов атомарные.

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

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

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

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

Множество атрибутов X называется детерминантом функциональной зависимости , а множество атрибутов У – зависимой частью.

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

Функциональная зависимость атрибутов отношения напоминает понятие зависимости в математике. Функциональная зависимость в математике – это тройка объектов X, Y и f , где Х множество, представляющее область определения функции, Y – множество значений, а f – правило, согласно которому каждому элементу ставится в соответствие один и только один элемент В противоположность этому в отношениях значение зависимого атрибута может принимать различные непредсказуемые значения в различных состояниях БД, соответствующих различным состояниям предметной области. Например, изменение сотрудником фамилии при вступлении в законный брак приведет к тому, что при том же значении детерминанта, скажем табельного номера, значение зависимого аргумента будет другим.

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

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

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

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

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится в 2НФ и все неключевые атрибуты взаимно независимы.

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

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

Алгоритм разработки включает в себя три этапа.

Этап I. Приведение к 1НФ. Здесь необходимо определить и задать отношения, отображающие понятия предметной области. Все отношения автоматически находятся в 1НФ.

Этап II. Приведение к 2НФ. Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то следует провести их декомпозицию следующим образом: атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение вместе с этой частью ключа, а в исходном отношении остаются все ключевые атрибуты.

. Ключ– сложный ключ.

– зависимость всех атрибутов от ключа отношения;

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

– оставшаяся часть исходного отношения;

– новое отношение.

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

образуют отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости.

Пусть, например, исходное отношение –. К – ключ.

Тогда функциональные зависимости имеют следующий вид:

После декомпозиции отношения получим:

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

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

Поэтому для того, чтобы создать качественную ИС, не достаточно понять бизнес-процессы и потребности Заказчика. Важно понимать, какой именно информацией система должна управлять. А для этого нужно знать, какие объекты попадают в предметную область проектируемой ИС и какие логические связи между ними существуют. Для формирования такого понимания используются логические модели предметной области.

Что иллюстрирует логическая модель

Целью построения логической модели является получение графического представления логической структуры исследуемой предметной области.

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

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

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

Пример: Заказ пиццы

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

Основные требования

Основные требования к содержанию модели

1. Логическая модель должна отображать все сущности и связи, значимые для той цели, ради которой мы ее рисуем.

2. Все объекты модели (и сущности, и связи) должны быть именованы. Именование сущностей и связей должно выполняться в терминах предметной области.

3. Для связей должна быть указана кратность (один — многие).

4. Для каждой связи должно быть указано направление чтения.

Пример: на модель добавлены наименования связей, их размерности и направление чтения.

5. Для сущностей должны быть указаны как минимум основные атрибуты.

Пример: для сущностей указаны основные атрибуты

Основные требования к качеству модели:

<Сущность 1> — <отношение / влияние> — <Сущность 2>.

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

Клиент может существовать без заказа. Однако заказ невозможно зарегистрировать без указания клиента. Один клиент может оформить неограниченное количество заказов

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

2. Модель должна быть структурирована, сущности должны быть сгруппированы по логическому смыслу.

3. Крайне желательно избегать пересечения связей.

4. Расположение объектов модели должно быть таким, чтобы ее удобно было читать.

Есть одно наблюдение — если на модель смотреть приятно, то скорее всего она выполнена качественно.

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

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

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

• Необходимо определить границы моделирования — какую часть исследуемой предметной области модель должна охватить.

Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи.

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

• Разработка логической модели должна начинаться в момент начала исследования предметной области и заканчиваться тогда, когда завершается выполнение задачи. Это едва ли не единственный артефакт, который разрабатывается на протяжении всего анализа предметной области и определения требований к системе.

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

• В ходе анализа осуществляется выявление и отображение на модели сущностей и связей.

Логическую модель надо строить так, чтобы сущности назывались именами существительными, связи — глаголами, а чтение диаграммы рождало бы пусть и корявые, но предложения, описывающие то, что происходит в предметной области. Если этого удалось добиться, то модель вышла замечательная. Если не удалось такое, то разработчику модели еще есть над чем поработать.

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

Заключение

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

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

Сергей Калинов

Ведущий бизнес-аналитик

18 Февраля, 2015