Методология IDEF1Х и программный продукт ERWin. Карпычев В.Ю.

Создание диаграммы IDEF1X в среде AllFusion ERwin Data Modeler

Методология IDEF1Х и программный продукт ERWin. Карпычев В.Ю.
⇐ ПредыдущаяСтр 6 из 9Следующая ⇒

Рассмотрим в качестве предметной области предприятие, в структуре которого имеются отделы, и спроектируем БД для хранения сведений о служащих, работающих в отделах, и их детях. Основные сущности будут следующие: СОТРУДНИК, ОТДЕЛ, РЕБЕНОК.

1. Для создания новой модели запустите Erwin, выберете File à New. В результате появится диалоговое окно, представленное на рис. 1.26.

рис. 1.26. Диалоговое окно создания новой модели

В данном окне установите переключатель на Logical/Physical. Это будет означать, что в данном примере будет создана как логическая модель данных, так и соответствующая ей физическая модель данных для СУБД Access.

2. Для создания сущности кликните на значок на панели инструментов. Задайте имя сущности: СОТРУДНИК.

3. Для определения атрибутов щелкните правой кнопкой мыши по сущности и выберете в контекстном меню пункт Attributes. Появится диалоговое окно, представленное на рис. 1.27.

рис. 1.27. Диалоговое окно редактирования атрибутов сущности

Щелкните по кнопке New… для создания нового атрибута.

В появившемся диалоговом окне укажите тип данных (Number), имя атрибута для отображения на логической модели (Attribute Name: Табельный номер), название колонки для отображения на физической модели (Column Name: EmpID). Далее для сущности СОТРУДНИК создайте еще атрибуты согласно данным, приведенным в Таблица 1.6.

Таблица 1.6

Структура сущности СОТРУДНИК

Имя атрибута Название колонки Тип данных
Табельный номер EmpID Number
Фамилия Familyname String
Имя Name String
Дата рождения Birthday Datetime
Адрес Address String
Пол Gender String

4. В качестве первичного ключа укажите Табельный номер (рис. 1.28).

рис. 1.28. Определение первичного ключа

Результат выполнения данного этапа представлен на рис. 1.29.

рис. 1.29.сущность СОТРУДНИК

По аналогии создайте сущности ОТДЕЛ и РЕБЕНОК согласно данным, представленным в Таблица 1.7 и Таблица 1.8.

Таблица 1.7

Структура сущности ОТДЕЛ

Имя атрибута Название колонки Тип данных
Номер отдела DepID Number
Название отдела DepName String

Таблица 1.8

Структура сущности РЕБЕНОК

Имя атрибута Название колонки Тип данных
Код ребенка ChildID Number
Имя ребенка ChildName String
Дата рождения ребенка ChildDate Datetime

После создания сущностей необходимо задать связи между ними.

5.Сущности СОТРУДНИК и ОТДЕЛ будут связаны неидентифицирующей связью «один-ко-многим» (в данном примере в одном отделе работает несколько сотрудников, но каждый сотрудник числится только в одном отделе).

Для этого необходимо щелкнуть по кнопке на панели инструментов, далее кликнуть мышкой по сущности ОТДЕЛ (сторона «один»), а затем по сущности СОТРУДНИК (сторона «многим»).

В сущности СОТРУДНИК появился новый атрибут Номер отдела, который является внешним ключом.

Несмотря на то, что каждый служащий “подчинен” отделу, он идентифицируется своим табельным номером независимо от отдела, в котором работает. Так как при установлении неидентифицирующей связи, первичный ключ сущности ОТДЕЛ мигрирует в состав непервичных атрибутов сущности СОТРУДНИК. Независимая сущность изображается в виде прямоугольного блока, внутри которого указан список атрибутов.

6.Сущности СОТРУДНИК и РЕБЕНОК будут связаны идентифицирующей связью «один-ко-многим». Для этого необходимо щелкнуть по кнопке на панели инструментов, далее кликнуть мышкой по сущности СОТРУДНИК (сторона «один»), а затем по сущности РЕБЕНОК (сторона «многим»).

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

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

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

рис. 1.30. Результат создания связей между сущностями

Согласно медологии IDEF1X необходимо задать имена связей между сущностям. Связи именуются глаголами. В нашем случае связи будут именоваться следующим образом:

· СОТРУДНИК имеет РЕБЕНКА,

· РЕБЕНОК принадлежит СОТРУДНИКУ,

· ОТДЕЛ состоит из СОТРУДНИКОВ,

· СОТРУДНИКИ принадлежат ОТДЕЛУ.

Для задания имени связи необходимо вызвать контекстное меню связи и выбрать пункт Relationship Properties. Появится диалоговое окно, представленное на рис. 1.31.

В появившемся диалоговом окне, находясь во вкладке General, в области Verb Phrase вводятся имена связи в обоих направлениях.

В данном примере для связи СОТРУДНИК-РЕБЕНОК в поле Parent-to-Child указываем имя имеет, а в поле Child-to-Parent – принадлежит.

рис. 1.31.Диалоговое окно Relationship

Аналогичным образом задаем имена для связи СОТРУДНИК-ОТДЕЛ.

По умолчанию имя связи на диаграмме не показывается. Для отображения имени связи следует в контекстном меню поля диаграммы выбрать пункт меню Relationship Display и затем щелкнуть Verb Phraze. Результат представлен на рис. 1.32.

рис. 1.32. Логическая модель данных с именованным связями

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

рис. 1.33.Физическая модель данных

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

Задание правил валидации и значений по умолчанию

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

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

рис. 1.34.Диалоговое окно для создания правил валидации

Источник: https://lektsia.com/3xefb.html

Методология IDEF1X — BPWIN

Методология IDEF1Х и программный продукт ERWin. Карпычев В.Ю.

  • изучить методологию IDEF1X,
  • изучить уровни методологии IDEF1X,
  • освоить инструментарий ERWin.

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

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

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

Как и многие другие инструментальные средства, ERwin следует использовать тому, кто понимает, для чего именно этот инструмент предназначен, и кто способен использовать его наиболее продуктивно.

Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

Верхний уровень состоит из Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах). Диаграмма сущность-связь определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области.

Нижний уровень состоит из Transformation Model (Трансформационная модель) и Fully Attributed (Полная атрибутивная модель). Трансформационная модель содержит всю информацию для реализации проекта, который может быть частью общей информационной системы и описывать предметную область.

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

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

Логические модели

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

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

Три уровня моделей, объединяющие в себе логические модели, состоят из Entity Relationship Diagram (Диаграмма сущность-связь), the Key-Based (Модель данных, основанная на ключах) Model и the Fully Attributed model (Полная атрибутивная модель).

Рис. 5.1. Уровни методологии IDEF1X

1.1. Диаграмма сущность-связь

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

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

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

1.3. Полная атрибутивная модель

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

1.4 Компоненты логической модели данных

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

Сущности

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

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

Сущности для ясности и обеспечения целостности обозначаются существительными в единственном числе, например, Потребитель (CUSTOMER) а не Потребители (CUSTOMERS).

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

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

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

Рис. 5.2. Пример использования ERwin для отображения сущностей в простейшей форме.

Атрибуты

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

Рисунок 2.3 иллюстрирует несколько примеров атрибутов.

Рис. 5.3. В качестве атрибутов могут выступать дата рождения клиента, модель автомобиля или код ISBN книги.

Отношения

Отношения представляют взаимосвязи между объектами, о которых корпорация заинтересована хранить данные. Отношения выражаются глаголами или глагольными фразами, которые описывают взаимосвязь. На рис. 2.4 приведено несколько примеров отношений, представленных в нотации IE (Information Engineering — информационная инженерия) системы ERwin.

Рис. 5.4. Примеры отношений используют нотацию IE системы ERwin, в которой «коровьи копыта» или «трезубцы» отображают многие стороны отношений.

Физические модели

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

логической модели в СУБД.

Трансформационная модель

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

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

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

Модель СУБД

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

Преимущества от использования CASE-средства ERWin

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

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

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

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

Инструментарий ERWin

При запуске ERWin появляется основная панель инструментов и палитра инструментов (табл. 5.1).

Таблица 5.1. Основная панель инструментов ERWin

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

Рис. 5.5. Палитра инструментов на логическом уровне

1. Слева направо, верхний ряд:

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

Источник: https://itteach.ru/bpwin/metodologiya-idef1x

Использование методик моделирования данных IDEF1X и IE в программном средстве AllFusion ERwin Data Modeler компании Computer Associates

Методология IDEF1Х и программный продукт ERWin. Карпычев В.Ю.

Вы находитесь на страницах старой версии сайта.
Переходите на новую версию Interface.Ru

© А. Козодаев

Рассмотрены две методики моделирования данных, используемых в программном средстве AllFusion ERwin Data Modeler.Показано, что методики IDEF1X и IE имеют больше сходств, чем различий.

Введение

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

Чтобы снизить риск совершения критических ошибок следует использовать специальные программные средства моделирования данных. К таким средствам относится AllFusion ERwin Data Modeler (далее — Erwin).

Одной из особенностей этого программного продукта является поддержка двух методик моделирования данных:

  • IDEF1X
  • IE (Information Engineering)

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

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

Сходства методик моделирования данных IDEF1X и IE

Обе методики моделирования данных основываются на диаграмме сущность-связь, которая была предложена в 1976 году сотрудником корпорации IBM Питером Ченом.

Рисунок 1. Диаграмма сущность-связь, предложенная П. Ченом

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

Она включает в себя два графических элемента:

  • сущность
    Сущность (entity) — это «предмет», который может быть идентифицирован некоторым способом, отличающим его от других «предметов» (определение Питера Чена). Каждая сущность обладает набором атрибутов. Атрибут — отдельная характеристика сущности.

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

  • связь
    Связь (relationship) — это логическая ассоциация, устанавливаемая между сущностями, которая представляет бизнес-правило или ограничение. С момента создания графическое представление диаграммы сущность-связь, которое предложил Питер Чен, изменялось и представления обеих рассматриваемых методик отличаются от представления предложенного Питером Ченом.

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

Рисунок 2. Отображение сущности.

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

Связи отображаются как линии между сущностями. В зависимости от роли в связи сущность может быть родительской или дочерней. В методике IDEF1X у дочерней сущности на связи присутствует точка, в методике IE вместо точки используется 'птичья лапка' (crow's foot).

Каждая связь имеет глагольную фразу, которая характеризует связь. Глагольная фраза читается по следующей формуле = название родительской сущности + глагольная фраза + название дочерней сущности.

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

Существует два типа сущностей:

  • зависимая сущность. Для определения экземпляра такой сущности необходимо сослаться на экземпляр независимой сущности, с которой связана зависимая сущность. Пример: сущности — заказ и позиция заказа.

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

  • независимая сущность. Для определения экземпляра сущности нет необходимости ссылаться на другие сущности. Пример: сущности — заказ и позиция заказа.

    Для определения заказа (сущности) нет необходимости ссылаться на позиции этого заказа (другие сущности).

Существует несколько видов связей:

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

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

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

Рисунок 3. Идентифицирующая связь (методика IDEF1X)

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

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

Рисунок 4. Неидентифицирующая связь (методика IDEF1X).

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

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

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

Рисунок 5. Связь многие-ко-многим (методика IDEF1X).

  • иерархическая. Указывает на связь сущности саму на себя.

Рисунок 6. Иерархическая связь (методика IDEF1X).

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

Различия методик моделирования IDEF1X и IE

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

В методике IDEF1X мощность отображается следующим образом:

Рисунок 7. Методика IDEF1X — экземпляру родительской сущности могут соответствовать 0,1 или много экземпляров дочерней сущности.

Рисунок 8. Методика IDEF1X — экземпляру родительской сущности могут соответствовать 1 или много экземпляров дочерней сущности (буква P у дочерней сущности).

Рисунок 9. Методика IDEF1X — экземпляру родительской сущности могут соответствовать 0 или 1 экземпляров дочерней сущности (буква Z у дочерней сущности).

Рисунок 10. Методика IDEF1X — экземпляру родительской сущности соответствует в точности 5 экземпляров дочерней сущности (цифра 5 у дочерней сущности).

В методике IE мощность связи отображается следующим образом:

Рисунок 11. Методика IE — экземпляру родительской сущности могут соответствовать 0,1 или много экземпляров дочерней сущности.

Рисунок 12. Методика IE — экземпляру родительской сущности могут соответствовать 1 или много экземпляров дочерней сущности.

Рисунок 13. Методика IE — экземпляру родительской сущности могут соответствовать 0 или 1 экземпляров дочерней сущности.

Рисунок 14. Методика IE — экземпляру родительской сущности соответствует в точности 5 экземпляров дочерней сущности (цифра 5 у дочерней сущности).

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

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

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

Рисунок 15. Связь типа иерархия категорий в методике IDEF1X.

В нотации IDEF1X иерархия категорий может быть двух типов — полная и неполная.

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

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

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

Рисунок 16. Виды иерархии категорий в методике IDEF1X.

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

Рисунок 17. Иерархия категорий в методике IE.

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

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

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

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

Примечание: в методике IE все иерархии категорий считаются полными.

Рисунок 18. Типы иерархии категорий в методике IE

Заключение

AllFusion ERwin Data Modeler не ограничивает разработчика в том, какую методику моделирования данных использовать. Это возможно благодаря поддержке двух методик моделирования данных: методики IDEF1X и методики IE. Различий между ними немного, но их нужно понимать для успешного использования выбранной методики в процессе моделирования данных.

Дополнительная информация

Обсудить на форуме Computer Associates

Источник: http://www.interface.ru/ca/MethodsDM_ERwin.htm

Biz-books
Добавить комментарий