Инфологическое моделирование предметной области
Разработка инфологической модели выполняется после описания предметной области в текстовом виде, аналогично тому, как функциональную модель начинают строить после формулирования цели и основных процессов также в виде текста на начальном этапе проекта автоматизации.
Инфологическая модель должна включать формализованное описание предметной области, не связанное с характеристиками и особенностями конкретной информационной среды – системы управления базами данных (СУБД). Выбор типа СУБД является отдельной задачей.
Следует отметить, что ранние теоретико-графовые модели были ориентированы на отображение семантики предметной области, и в явном виде определяли иерархические связи между объектами.
Общая теория реляционных баз данных, общая реляционная модель данных справедливы для принципиального анализа реляционных баз данных, но общая модель не позволяет отобразить семантику, то есть смысл предметной области. Поэтому технические реализации реляционных баз разрабатываются в конкретных проектах на основе инфологической модели.
Инфологическая модель «сущность-связь», или «Entity Relationship» (ER-модель) актуальна для проектирования, так как представляет семантику предметной области, она является стандартом «de facto» при инфологическом моделировании реляционных баз данных.
Ряд CASE-средств и архитектурных модулей генерации моделей информационных систем содержат инструментарий для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования ER-модели базы данных в даталогическую модель, соответствующую конкретной СУБД.
Также CASE-системы имеют развитые средства документирования процесса разработки БД.
Автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений, как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта.
Несмотря на тот факт, что не существует единой общепринятой системы обозначений для ER-модели и различные CASE-системы используют разные графические нотации, синтаксис и семантика диаграмм моделирования аналогичны, поэтому не этот аспект является причиной затруднений и ошибок при проектировании.
Основные погрешности проектирования связаны, как правило, со сложностями выделения и формализации процессов и/или с отсутствием в среде моделирования возможности автоматической проверки целостности диаграмм.
2.2. Сущность, атрибут, связь. Графическое представление характеристик связи
Хотя терминология нотации IDEF1X практически совпадает с терминологией нотации IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих нотаций.
Сущность в IDEF1X описывает совокупность или набор экземпляров, похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности.
Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира.
В отличие от этого в нотации IDEF1 сущность представляет собой абстрактный набор информационных отображений реального мира.
Например, сущность "СОТРУДНИК" в нотации IDEF1X представляет собой любого из сотрудников предприятия, а один из сотрудников, Иванов Петр Сергеевич, является конкретной реализацией этой сущности.
В примере, приведенном на рис. 1, каждый экземпляр сущности «СОТРУДНИК» содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X-модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.
Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой.
Ниже приведены примеры связи между сущностями:
Отдел <состоит из> нескольких Сотрудников
Самолет <перевозит> нескольких Пассажиров.
Сотрудник <пишет> разные Отчеты.
Во всех перечисленных примерах взаимосвязи между сущностями соответствуют схеме один ко многим. Это означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая - дочерней.
В приведенных примерах глаголы заключены в угловые скобки. Связи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией.
На рис. 5 представлена диаграмма связи между сущностями «Сотрудник» и «Отдел».
Отношение «многие ко многим» используется на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей, и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах. Иногда отношение «многие ко многим» на ранних стадиях моделирования идентифицируется неправильно, на самом деле представляя два или несколько случаев отношений «один-ко-многим» между связанными сущностями.
В случае необходимости хранения дополнительных сведений о связи «многие-ко-многим», например, даты или комментария, такая связь должна быть заменена дополнительной сущностью, содержащей эти сведения.
Отношение «многие ко многим» может скрыть другие правила или ограничения, поэтому такое отношение должно быть полностью исследовано на одном из этапов моделирования.
Таким образом, сущность представляет собой класс однотипных объектов, информация о которых должна быть учтена в модели. Соответственно, сущность может быть зависима или независима от идентификаторов.
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Экземпляр сущности - это конкретный представитель данной сущности. Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь свойства, уникальные для каждого экземпляра этой сущности.
Каждая сущность в модели изображается в виде прямоугольника с наименованием: описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника.
На рис.6 приведен пример IDEF1X-диаграммы. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных.
Рис. 5. Диаграмма связи.
Рис. 6. Пример IDEF1X-диаграммы.
Ключевая область объекта СОТРУДНИК содержит поле "Уникальный идентификатор сотрудника", в области данных находятся поля "Имя сотрудника", "Адрес сотрудника", "Телефон сотрудника" и т.д.
Ключевая область содержит первичный ключ для сущности. Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Атрибуты первичного ключа располагаются над линией в ключевой области.
Неключевой атрибут - это атрибут, который не был выбран ключевым. Неключевые атрибуты располагаются на модели в области данных.
При создании сущности в IDEF1X-модели одним из главных вопросов является способ идентификации уникальной записи. Уникальная идентификация каждой записи необходима для того, чтобы правильно создать логическую модель данных. Для сущности в нотации IDEF1X должны быть определены ключевые атрибуты.
Выбор первичного ключа для сущности является важным моментом разработки модели. В качестве первичных ключей могут быть использованы несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей.
Например, для того, чтобы корректно использовать сущность «СОТРУДНИК» в IDEF1X-модели данных необходимо иметь возможность уникально идентифицировать записи. Правила, по которым выбирается первичный ключ из списка предполагаемых ключей устанавливают, что атрибуты и группы атрибутов должны:
уникальным образом идентифицировать экземпляр сущности.
не использовать NULL значений.
не изменяться со временем.
Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.
Ключ должен быть короткими, что удобно для индексирования и получения данных.
Если нужно использовать ключ, являющийся комбинацией ключей из других сущностей, то каждая из частей ключа должна соответствовать приведенным правилам.
Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем пример выбора первичного ключа для сущности "СОТРУДНИК":
Атрибут "ID сотрудника" является потенциальным ключом, так как он уникален для всех экземпляров сущности «СОТРУДНИК».
Атрибут "Имя сотрудника" не очень подходит для потенциального ключа, так как среди служащих на предприятии может быть, к примеру, два человека с одинаковой фамилией.
Атрибут "Номер страхового полиса сотрудника" является уникальным, но сотрудник в принципе может не иметь полиса.
Комбинация атрибутов "имя сотрудника" и "дата рождения сотрудника" может оказаться удачной и стать искомым потенциальным ключом.
После проведенного анализа можно назвать два потенциальных ключа - первый "Номер сотрудника" и комбинация, включающая поля "имя сотрудника" и "Дата рождения сотрудника". Так как атрибут "Номер сотрудника" имеет самые короткие и уникальные значения, то он лучше других подходит для первичного ключа.
При выборе первичного ключа для сущности, разработчики модели часто используют дополнительный (суррогатный) ключ, т.е. произвольный номер, который уникальным образом определяет запись в сущности. Атрибут "Номер сотрудника" является примером суррогатного ключа.
Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что является коротким и быстрее всего идентифицирует экземпляры в объекте. Кроме того, суррогатные ключи могут автоматически генерироваться системой так, чтобы нумерация была сплошной, т.е. без пропусков.
Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы.
Если сущности в IDEF1X-диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь.
Передаваемые атрибуты называются мигрирующими.
При разработке модели встречаются сущности, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.
Рис. 7. Пример графического изображения связи между сущностями.
Рис. 8. Типы связей.
Рис. 9. Модальность связи.
Рис. 10. Вариант диаграммы для сбытового подразделения.
В примере на рис.5 сущность «СОТРУДНИК» является зависимой сущностью потому, что его идентификация зависит от сущности «ОТДЕЛ». В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.
Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность «СОТРУДНИК» принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела.
Напротив, существуют ситуации, в которых одна сущность зависит от существования другой сущности.
Рассмотрим две сущности: «ЗАПРОС», используемый для отслеживания запросов покупателей, и «ПОЗИЦИЯ ЗАПРОСА», который отслеживает отдельные элементы в сущности «ЗАПРОС». Связь между этими двумя сущностями может быть выражена в следующем виде:
ЗАПРОС <содержит> один или несколько ПОЗИЦИЙ ЗАПРОСА.
В этом случае «ПОЗИЦИЯ ЗАПРОСА» зависит от существования «ЗАПРОСА».
Сущности, не зависящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущность «ОТДЕЛ» является независимой. В IDEF1X независимые сущности представлены в виде прямоугольников.
Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:
каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей.
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".
Графически связь изображается линией, соединяющей две сущности (см рис.7).
Каждая связь имеет два конца и одно или два наименования. Наименование выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Связь может принадлежать к одному из следующих типов:
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.
Связь типа многие-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи многие-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Условные обозначения для связи каждого типа приведены на рис.8.
Каждая связь может характеризоваться одной из следующих модальностей связи.
Модальность "может" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность "должен" означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Кроме того, связь может иметь разную модальность с разных концов (рис. 9).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 7 читается так:
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".