Как составить информационно логическую модель

Построение информационно-логической модели предметной области

Процесс разработки
информационно-логической модели (ИЛМ
ПО) является творческим и трудно поддается
формализации. Для построения ИЛМ
необходимо знание предметной области
ее семантики, понимание логических
взаимосвязей ее информации. С другой
стороны необходимо опираться на
теоретические основы моделей данных,
поддерживаемых в СУБД. Построение
информационно-логической модели
разделяется на два основных этапа –
выделение информационных объектов и
определение связей между ними.

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

Выделение информационных объектов

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

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

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

Правила выделения информационных объектов

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

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

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

Далее необходимо
выполнить следующие действия:

I. Установить
функциональные зависимости между
реквизитамина основе описания ПО
и выявления роли реквизитов в структуре
информации документа.

Таблица 1.

Функциональные
зависимости реквизитов справочника
Товаров

Документ	Наименование реквизита	Имя реквизита	Функциональные зависимости
Справочник товаров	Код товара Наименование Цена за единицу Единица измерения	KODT NAIM CENA EI

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

Для каждого
описательного реквизита определяется,
от какого реквизита он зависит. В случае
если такая зависимость имеется, проводится
линия связи от данного реквизита к тому
реквизиту (ключевому), от которого он
зависит, и указывается стрелка к
зависимому реквизиту (см. табл..1).

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

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

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

Таблица.2.
Соответствие описательных и ключевых
реквизитов

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

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

Описание выявленных
информационных объектов предметной
области целесообразно представить в
виде таблицы 3.

Таблица 3. Описание
информационных объектов ПО

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

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

Соседние файлы в папке Лекции. Все темы!

• #
• #
• #
• #
• #
• #
• #

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

Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты – прилагательными или модификаторами, взаимосвязи – глаголами.

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

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

ERD-диаграммы

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

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

Рис. 6.1. Пример ERD-диаграммы,

Определение сущностей и атрибутов

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

На рис. 6.2 показана ERD-диаграмма, включающая в себя атрибуты сущностей.

Рис. 6.2. ERD-диаграмма с атрибутами

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

• команда включает много игроков,
• самолет перевозит много пассажиров,
• продавец продает много продуктов.

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

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

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

Проверка адекватности логической модели

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

Самолет перевозит пассажиров. Много пассажиров перевозятся одним самолетом.

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

Рис. 6.3. Пример логической модели со взаимосвязью

Модель данных, основанная на ключах

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

Выбор первичного ключа

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

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

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

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

Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы – это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

Пример

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

Таблица 6.1. Атрибуты сущности «Студент»

Атрибут	Описание
Номер	Уникальный номер для идентификации пользователя
Ф.И.О.	Фамилия, имя и отчество пользователя
Пароль	Пароль для доступа в систему
Возраст	Возраст студента
Пол	Пол студента
Характеристика	Memo-поле с общей характеристикой пользователя
E-mail	Адреса электронной почты
Телефон	Номера телефонов студента (домашний, рабочий)
Опыт работы	Специальности и опыт работы студента по каждой из них
Специальность	Специальность, получаемая студентом при окончании учебного заведения
Специализация	Направление специальности, по которому обучается студент
Иностранный язык	Список иностранных языков и уровень владения ими
Тестирование	Список тестов и отметки о их прохождении
Экспертная оценка	Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам	Список сданных предметов с оценками

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

Таблица 6.2. Атрибуты сущности «Опыт работы»

Атрибут	Описание
Специальность	Название специальности, по которой у студента есть опыт работы

Опыт	Опыт работы по данной специальности в годах
Место работы	Наименование предприятия, где приобретался опыт

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Атрибут	Описание
Язык	Название иностранного языка, которым владеет студент
Уровень владения	Численная оценка уровня владения иностранным языком

Таблица 6.4. Атрибуты сущности «Тестирование»

Атрибут	Описание
Название	Название теста, который прошел студент
Описание	Содержит краткое описание теста
Оценка	Оценка, которую получил студент в результате прохождения теста

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Атрибут	Описание
Дисциплина	Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя	Ф.И.О. преподавателя, который оценивал студента
Оценка	Экспертная оценку преподавателя
Атрибут	Описание
Предмет	Название предмета, экзамен по которому сдавался
Оценка	Полученная оценка

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рис. 6.4. ERD-диаграмма БД студентов

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

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

Таблица 6.7. Типы атрибутов

Атрибут	Тип
Номер	Number
Ф.И.О.	String
Пароль	String
Возраст	Number
Атрибут	Тип
Пол	String
Характеристика	String
E-mail	String
Специальность	String
Специализация	String
Опыт	Number
Место работы	String
Язык	String
Уровень владения	Number
Название	String
Описание	String
Оценка	Number
Дисциплина	String
Ф.И.О. преподавателя	String
Предмет	String

Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.

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

Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами

Контрольные вопросы

1. Назовите основные части ERD-диаграммы.
2. Цель ERD-диаграммы.
3. Что является основным компонентом реляционных БД?
4. Что называется сущностью?
5. Сформулируйте принцип именования сущностей.
6. Что показывает взаимосвязь между сущностями?
7. Назовите типы логических взаимосвязей.
8. Каким образом отображаются логические взаимосвязи?
9. Опишите механизм проверки адекватности логической модели.
10. Что называется первичным ключом?
11. Назовите принципы, согласно которым формируется первичный ключ.
12. Что называется альтернативным ключом?
13. Что называется инверсионным входом?
14. В каком случае образуются внешние ключи?

Содержание отчета

1. Тема, цель работы.
2. ERD-диаграмма БД Служба занятости с атрибутами и ключами.
3. Выводы по работе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Модель должна читаться по схеме:

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

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

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

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

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

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

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

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

Рекомендации по разработке

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Автор:

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

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

EPAM Systems