Совместное использование idef0, DFD и idef3

При решении практических задач построения функциональных моделей, предназначенных как для проектирования ИС, так и для анализа некоторых процессов, обычно используются несколько методов. Если говорить о рассмотренных выше подходах, то наибольшее распространение получила трехступенчатая схема разработки и представления функциональных моделей. Внешний (концептуальный) уровень создается с помощью IDEF0. На этом этапе определяются базовые функции, основные передаваемые и используемые объекты (как информационные, так и материальные). Дальнейшая детализация производится с помощью средств DFD. На этом уровне большее внимание уделяется структуре передаваемых и хранимых данных, топологии сети информационного обмена. Детальная спецификация состава и порядка выполнения отдельных функций производится с помощью IDEF3. Если разрабатываемая модель предназначена для нужд проектирования и разработки ИС, то вместо IDEF3 часто используют такие визуальные средства спецификации передач управления как блок-схемы и FLOW-формы (см. ниже).

В качестве CASE-средства, поддерживающего создание гибридных моделей IDEF0+DFD+IDEF3, можно указать пакет BPWin (текущее официальное наименование AllFusion Process Modeler).

Раздел 4. Моделирование данных

Цель моделирования данных состоит в обеспечении разработчика ИС схемой базы данных (БД). Схема может состоять из одной или нескольких моделей данных.

Наиболее распространенным способом моделирования данных является подход с использованием диаграмм «сущность-связь» (Entity Relationship Diagrams, ERD), ориентированных на разработку реляционных БД.

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

IDEF1X

Метод IDEF1X первоначально был разработан для Министерства обороны США и ныне широко используется как в государственных учреждениях, так и в частных фирмах США. Метод отличается ясной и недвусмысленной графической нотацией.

Основными элементами диаграмм сущность-связь являются:

- сущности;

- свойства сущностей (атрибуты);

- отношения (связи) между сущностями.

В общем случае разработка модели по IDEF1X включает следующие шаги:

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

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

3. выявляются и описываются основные отношения; основные сущности и отношения отображаются на так называемой концептуальном – наименее детальном – уровне модели;

4. раскрываются нестандартные отношения (типа «многие ко многим»), определяются ключевые и наиболее важные с функциональной точки зрения атрибуты сущностей; данная информация отображается на логическом уровне модели (или, в терминах IDEF1X, "key-based view");

5. полностью определяются все атрибуты сущностей, все элементы модели получают непротиворечивые физические имена; получаемый в результате физический уровень модели (в терминах IDEF1X "fully attributed view") может быть отображен в РБД с точно соответствующей ему структурой.

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

Сущность

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

Отдельное свойство объекта выражает атрибут. Сущность включает определение одного и более атрибутов.

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

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

Если рассматривать эти элементы с точки зрения конечной РБД, то сущности соответствует таблица, экземпляру сущности – строка, атрибуту – колонка таблицы.

Основные свойства сущности:

1. наличие уникального имени и одинаковой семантики (смысла) во всей модели, т.е., например, сущность «Чек» должна иметь одинаковый смысл на всех диаграммах модели – описание информационного объекта, хранящего параметры кассового чека;

2. наличие одного или нескольких атрибутов;

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

4. сущность может иметь любое количество отношений с другими сущностями.

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

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

1. концептуальный:

2. логический:

3. физический:

Более детальное рассмотрение свойств сущности требует определения понятия «связь» и дается ниже.

Атрибут

Атрибут (attribute) — любая характеристика сущности, значимая для рассматриваемой проблемной области и предназначенная для квалификации, идентификации, классификации количественной оценки характеристики или выражения состояния сущности.

Экземпляр атрибута — это значение атрибута. С позиции конечного представления в РБД атрибуту соответствует колонка таблицы.

Атрибуты бывают обязательными и необязательными. Если атрибут необязателен, то он может принимать неопределенное значение (NULL).

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

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

Необязательные атрибуты помечаются буквой “O” (optional). Например, пусть атрибут "Телефон" не является обязательным, тогда:

Если, кроме первичного ключа, для сущности можно указать еще несколько атрибутов (групп атрибутов), уникально определяющих экземпляр сущности, то такие атрибуты называются альтернативными ключами. Альтернативные ключи помечаются аббревиатурой AK (от alternate key):

Основные свойства атрибута:

1. принадлежит только одной сущности;

2. имеет уникальное имя в пределах своей сущности;

3. первичный ключ не может принимать неопределенные значения;

4. атрибут принимает одно конкретное значение для каждого экземпляра сущности.

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

Связь (отношение)

Связь (отношение, relationship) — поименованная ассоциация между двумя сущностями, определяющая некоторое логическое соотношение между сущностями.

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

На уровне конечной БД связи соответствует ограничение целостности.

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

В зависимости от характера связи, соединяющей сущности, в IDEF1X выделяются зависимые и независимые сущности. С этой точки зрения связи делятся на идентифицирующие и неидентифицирующие.

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

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

В случае связи «один ко многим» экземпляру родительской сущности соответствует произвольное, в том числе нулевое, количество экземпляров потомков, а экземпляр сущности-потомка ассоциирован с одним экземпляром родительской сущности:

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

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

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

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

Все мигрировавшие атрибуты помечаются аббревиатурой FK (foreign key). Например, из отображения сущности "Игрок" видно, что атрибут "Наименование" является внешним ключом.

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

Наименование внешнего ключа его должно соответствовать его наименованию в родительской или родовой сущности, либо необходимо использовать так называемое ролевое имя (role name). Ролевое имя отражает отношение между дочерней и родительской сущностью с точки зрения дочерней. Пример использования ролевого имени:

Ролевое имя логически обратно наименованию связи, которое формируется с точки зрения родителя.

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

Например:

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

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

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

       Пример:

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

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

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

В IDEF1X определено 4 типа мощности:

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

2. одному экземпляру родительской сущности соответствует более нуля экземпляров дочерней; помечается символом P (positive — положительное количество);

3. одному экземпляру родительской сущности соответствует ноль или один экземпляр дочерней; помечается символом Z (zero — возможен ноль);

4. одному экземпляру родительской сущности всегда соответствует заданное количество экземпляров дочерней; помечается соответствующим числом, равным количеству экземпляров дочерней сущности;

5. одному экземпляру родительской сущности всегда соответствует от min до max экземпляров дочерней; помечается через диапазон min…max;

Типы зависимых сущностей

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

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

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

3. именующая — ­ частный случай ассоциативной сущности, не имеющей своих собственных атрибутов, т.е. все атрибуты являются внешними ключами, мигрировавшими из родительских сущностей;

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

Связь типа "наследование"

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

Иерархия наследования — тип отношения сущностей, разделяющих общие атрибуты. Если ряд сущностей имеют одинаковые по смыслу атрибуты, то эти атрибуты можно выделить в отдельную обобщенную сущность, или родовую сущность (generic — родовой, общий). Специфические для каждой исходной сущности атрибуты располагаются в сущностях-потомках, или категориальных сущностях (category entity).

Таким образом, с точки зрения наследования сущности делятся на родовые сущности и сущности-потомки (категориальные сущности).

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

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

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

Здесь "Сотрудник" — родовая сущность, "Постоянный сотрудник" и "Совместитель" — категориальные сущности. Дискриминатором является атрибут "Тип". Дискриминатор указан рядом со знаком категориальных отношений, представляющим собой окружность, подчеркнутую линией со стороны категориальных сущностей:

Категориальные сущности образуют иерархию категорий (наследования). В оригинале используется термин "cluster" — "группа", "гроздь".

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

Тип иерархии указывается через вид знака иерархии:

неполная
полная

Свойства наследования:

1. категориальная сущность может иметь только одну родовую сущность;

2. категориальная сущность может быть родовой в другом категориальном отношении;

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

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

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

6. в иерархиях наследования не может быть циклов;

7. дискриминатор в полной иерархии не может принимать неопределенное значение;

8. категориальная сущность всегда является зависимой.

Пример вложенных иерархий:

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

Неопределенная связь (non-specific)

IDEF1X поддерживает неопределенные связи (non-specific) между сущностями, или, в соответствии с более распространенной терминологией, связи типа "многие ко многим". Под определенной связью понимаются отношения типа "один ко многим" и наследование, рассмотренные выше.

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

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

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

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

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

На логическом уровне связь "многие ко многим" может быть разрешена следующим образом:

Нормализация данных

В данном пункте даются самые общие понятия о нормализации данных.

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

Положительные эффекты от нормализации:

1. сокращение размера конечной БД;

2. уменьшение возможностей возникновения аномалий в процессе эксплуатации БД или их устранение.

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

Отрицательные эффекты:

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

2. усложнение запросов.

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

1. первая НФ (1NF);

2. вторая НФ (2NF);

3. третья НФ (3NF);

4. НФ Бойса-Кодда (BCNF);

5. четвертая НФ (4NF);

6. пятая НФ (5NF).

Наиболее слабые требования к структуре предъявляются в первой НФ, наиболее жесткие — в пятой. Следует заметить, что далеко не любую модель в принципе можно представить в пятой НФ.

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

В таблицы дана краткая характеристика рассматриваемых нормальных форм.

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

Необходимые определения.

Функциональная зависимость: атрибут A сущности E находится в функциональной зависимости от атрибута B сущности E, если значение B однозначно определяет A. Иначе говоря, существует некоторая функция f, так что A = f (B). Можно назвать A атрибутом-функцией, B — атрибутом-аргументом. Замечание. Из существования A = f(B) в общем случае не следует существование B = g(A).

Полная функциональная зависимость: атрибут A сущности E находится в полной функциональной зависимости от набора атрибутов B₁, B₂, …, B_n сущности E, если A функционально зависит от B₁, B₂, …, B_n, но не зависит функционально ни от какого подмножества из B₁, B₂, …, B_n.

Первая НФ

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

Например:

Здесь пара атрибутов "Телефон 1" и "Телефон 2" являются явным нарушением первой НФ, поскольку описывают, фактически, одну и ту же характеристику. С другой стороны, продемонстрированный "экстенсивный" подход к описанию характеристик сущности не решает проблему, или решает на короткий срок и в рамках узкой предметной области. Действительно, если у какого-то студента наберется десяток любимых занятий, то придется либо добавлять еще 7 атрибутов в сущность, либо вводе данных в систему принудительно отсекать все списки хобби размером более 3 элементов. Очевидно, что такой подход в общем случае не правилен.

Для приведения сущности к первой НФ необходимо:

1. выделить атрибуты, действительно характеризующие разные признаки сущности;

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

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

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

Для приведенного примера:

 

Вторая НФ

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

Пример:

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

Для приведения сущности, удовлетворяющей первой НФ, ко второй НФ необходимо:

1. найти атрибуты, которые зависят только от части первичного ключа;

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

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

В случае сущности "Курс" модификация будет такой:

Третья НФ

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

Пусть в уже использовавшейся для иллюстрации сущности "Курс" имеется также атрибут "Факультет":

Если считать, что каждая кафедра приписана только к одному факультету, то в данной сущности имеется аномалия не только с точки зрения второй НФ, но и третьей НФ.

Последовательность шагов для приведения сущности от второй НФ к третьей:

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

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

3. задать неидентифицирующую связь между новыми сущностями и исходной; при этом новые сущности являются родительскими.

В соответствии с таким алгоритмов получается следующая структура: