в какой связи idef1x проставляется ромб на стороне предка

Проектирование баз данных с использованием методологии IDEF1X

Стандарт, описывающий методологию проектирования IDEF1X, был разработан в США в 1993 г. Он уточняет предшествующую версию

IDEF1 и является частью семейства стандартов IDEF (от англ. Integration Definition Methodology), к которому также относятся стандарты на методологию функционального моделирования систем IDEF0, моделирования динамически изменяющихся систем IDEF2 и ряд других.

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

Поддерживающие IDEF1X программные средства, такие как ERwin Data Modeler, позволяют построить независимую от СУБД логическую модель БД и по ней создать физическую модель для реализации в среде конкретной СУБД. При этом появляется возможность уже на ранних этапах проектирования системы (при построении логической модели) согласовать описание предметной области: выделить объекты, их взаимосвязи, атрибуты, описывающие отдельные характеристики. При необходимости для одной согласованной логической модели можно создать физические модели для разных СУБД. Например, ERwin Data Modeler v. 9 в версии Community Edition поддерживает создание физических моделей для СУБД IBM DB2, Microsoft SQL Server, MySQL, Oracle Database, Sybase Adaptive Server Enterprise и ODBC-совместимых (от англ. Open Database Connectivity) СУБД.

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

Разделение на логическую и физическую модель БД имеет ряд преимуществ и с точки зрения документирования разрабатываемого решения. В силу ряда причин, таких как накладываемые СУБД ограничения на длину имен таблиц и столбцов, ограниченная поддержка национальных алфавитов в именах объектов БД, многие разработчики предпочитают использовать для таблиц и столбцов короткие имена, отображаемые латиницей. Например, столбец с идентификатором рабочей станции может называться «Wstld». Такие CASE-средства, как ERwin, позволяют при создании логической модели БД использовать понятные читаемые названия, а в физической модели БД – заменить их на короткие технические обозначения. С точки зрения документирования решений полезной является и возможность добавления комментариев и заметок в процессе работы над моделью.

При создании модели БД описывают сущности, их атрибуты и связи между сущностями [11–13]. Терминология IDEF1X очень близка ктерминологии, используемой в других методиках моделирования БД. Сущность (англ. Entity) является представлением множества реальных или абстрактных объектов (явлений, событий и т.п.), относимых к одному типу: они обладают одинаковым набором характеристик и могут участвовать в однотипных связях с другими сущностями. Конкретный объект из подобного множества будет называться экземпляром. Экземпляры должны отличаться один от другого. Сущности именуются существительным в единственном числе, например «Компьютер». Также стандарт IDEF1X допускает в имени указание уникального в рамках модели БД номера сущности, например «Компьютер/1». Обратите внимание, что в приведенном примере «1» – это номер сущности, а не ее экземпляра.

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

Связь (англ. relationship) описывает логическое отношение между двумя сущностями или между экземплярами одной сущности. При моделировании БД связь принято именовать глаголом или глагольной фразой.

Рассмотрим пример, иллюстрирующий использование различных типов сущностей и связей, определяемых нотацией IDEF1X. Пусть требуется разработать БД для хранения информации о компьютерной системе предприятия. С помощью программы ERwin Data Modeler начнем создавать логическую модель. Компьютеры имеют уникальные инвентарные номера и имена, причем для одного компьютера может быть использовано несколько дополнительных имен (псевдонимов). Например, компьютер servl.corp.ru может иметь псевдонимы mycorp.net и ftp.mycorp.net. Компьютеры размещены в помещениях организации, на них установлено ПО. Фрагмент логической модели БД представлен на рис. 6.4.

Рис. 6.4. Фрагмент логической модели базы данных в нотации IDEF1X

Сущности в IDEF1X изображаются с помощью прямоугольника, над которым указывается его название, а в верхней части над чертой перечисляются атрибуты, входящие в первичный ключ. Сущности могут быть независимыми (англ. Identifier-Independent Entity) и зависимыми (англ. Identifier-Dependent Entity). Отличие заключается в том, что для существования экземпляра зависимой сущности необходима его связь с экземпляром сущности, от которой он зависит. Зависимые сущности изображаются прямоугольником со скругленными краями. В примере, приведенном на рис. 6.4, имеются независимая сущность «Компьютер» и зависящая от нее сущность «Псевдоним компьютера». Это означает, что псевдоним не может существовать без указания компьютера, для которого он задан.

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

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

Рассмотрим вторую связь типа «один-ко-многим» представленную на диаграмме (рис. 6.4). Это связь между двумя независимыми сущностями «Помещение» и «Компьютер». В терминологии IDEF1X такая связь будет являться неидентифицирующей (англ. Non-identifying Relationship). Она изображается на диаграмме пунктирной линией с черным кружком со стороны дочерней сущности. В данном случае мы считаем, что для компьютера может быть определено не более одного помещения и могут существовать компьютеры, для которых помещение не задано. С точки зрения проектирования реляционной БД это означает, что в таблице «Компьютер» для внешнего ключа «Номер помещения» допустимо значение NULL. На диаграмме это изображается пустым ромбом со стороны родительской сущности (рис. 6.4). Такая связь называется опциональной, или необязательной (англ. optional non-identifying relationship) [11]. Если ромба нет, это означает обязательное участие подчиненной сущности в данной связи, что реализуется ограничением NOT NULL для соответствующего внешнего ключа (подробнее об ограничениях, определяемых при создании таблиц реляционной БД, см. гл. 7). В IDEF1X такая связь называется обязательной неидентифицирующей связью (англ. mandatory non-identifying relationship).

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

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

Реляционная модель в явном виде не поддерживает связи типа «многие-ко-многим». При проектировании БД в среде ERwin, при переходе от логической модели БД к физической, связь «многие-ко-многим» автоматически преобразуется: создается зависимая сущность, для которой определяются две связи «один-ко-многим». На рис. 6.5 изображен фрагмент физической модели БД, построенной для логической модели, представленной на рис. 6.4. Еще раз хочется обратить внимание, что ERwin позволяет давать различные имена соответствующим объектам физической и логической модели. Поэтому сущностям «Компьютер» и «Программное обеспечение» в физической модели на рис. 6.5 соответствуют таблицы «Computer» и «Software»; переименованы были и столбцы таблиц. Автоматически созданная таблица «Computer_Software», имя которой было сгенерировано на основе имен родительских таблиц, получила составной первичный ключ, включающий первичные ключи исходных таблиц. Таким образом, миграция ключей в данном случае произошла на уровне физической модели.

Рис. 6.5. Преобразование связи «многие-ко-многим» в физической модели

Прежде чем продолжить описание типов связей, определенных нотацией IDEF1X, рассмотрим уровни представления модели БД, предлагаемые ERwin Data Modeler. Надо отметить, что данное разделение уровней не определяется в IDEF1X, но в целом характерно для CASE-средств проектирования БД, поддерживающих эту методологию.

В соответствии с идеологией нисходящего проектирования разработчики ERwin ввели несколько промежуточных уровней моделирования [14]. Для логической модели определяются следующие формы представления.

Диаграмма «сущность – связь» (англ. Entity-Relationship Diagram, ERD) включает основные сущности, выявленные в предметной области, и связи между ними. Атрибуты не указываются. Диаграммы не перегружены деталями и могут использоваться для обсуждения структуры проектируемой базы в целом. Пример подобной диаграммы представлен на рис. 6.6.

Рис. 6.6. Диаграмма «сущность – связь»

Рис. 6.7. Представления модели БД, основанной на ключах

Модель базы данных, основанная на ключах (англ. key-based), является более подробной, включает все сущности, их ключи, а также связи. В интерфейсе ERwin Data Modeler при работе с моделью можно переключиться на представление, использующее только первичные ключи (англ. primary key display level, рис. 6.7, а) или первичные и внешние ключи (англ. keys display level, рис. 6.7, б).

Нижний уровень для логической модели – полная атрибутивная модель (англ. fully-attributed, FA), включающая все сущности, их атрибуты и связи. Структура проектируемой БД должна быть приведена в соответствие третьей нормальной форме. В качестве примера может выступать модель, изображенная на рис. 6.4, при условии, что все необходимые объекты предметной области, их связи и характеристики представлены на диаграмме.

Для физической модели определены два уровня:

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

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

Рассматриваемая нотация при необходимости позволяет указать мощность связи (англ. cardinality) – количество экземпляров подчиненной сущности, которые могут быть связаны с экземпляром родительской сущности. Мощность может задаваться для связи типа «один-ко-многим», как идентифицирующей, так и неидентифицирующей. Могут быть определены следующие варианты:

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

Задать мощность связи в ERwin можно в окне свойств (пункт «Properties» контекстного меню, открывающегося при щелчке правой клавишей мыши на изображении связи). Нужно отметить, что при настройках по умолчанию ERwin не отображает на диаграмме название и мощность связи. Если нужно включить отображение мотцности связи на диаграмме, надо щелчком правой клавиши мыши на свободном месте поля диаграммы вызвать контекстное меню, в нем выбрать пункт «Properties» и на вкладке «Relationship» отметить опцию «Display Relationship Cardinality». Если нужно отобразить на диаграмме название связи, на той же вкладке надо отметить опцию «Display Logical Relationship Name».

Правила изображения мощности связи

Источник

Основы методологии IDEF1X

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «AS IS», тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

Концепция и семантика IDEF1X

Сущности в IDEF1X и их атрибуты.

Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X может быть сущность «СОТРУДНИК», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, приведенном на рис. 1, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связи между сущностями

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

Отдел нескольких Сотрудников

Самолет нескольких Пассажиров.

Сотрудник разные Отчеты.

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

Идентификация сущностей. Представление о ключах.

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. На рис.2 приведен пример IDEF1X диаграммы. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта СОТРУДНИК содержит поле «Уникальный идентификатор сотрудника», в области данных находятся поля «Имя сотрудника», «Адрес сотрудника», «Телефон сотрудника» и т.д.

При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: «Как можно идентифицировать уникальную запись?». Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в IDEF1X всегда имеют ключевую область и, поэтому в каждой сущности должны быть определены ключевые атрибуты.

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

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

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

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

Классификация сущностей в IDEF1X. Зависимые и независимые сущности.

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

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

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

Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАПРОС, используемый для отслеживания запросов покупателей, и ПОЗИЦИЯ ЗАПРОСА, который отслеживает отдельные элементы в ЗАПРОСе. Связь между этими двумя сущностями может быть выражена в виде ЗАПРОС один или несколько ПОЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зависит от существования ЗАКАЗА.

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

Типы связей между сущностями. Идентифицирующие и неидентифицирующие связи.

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

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

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

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

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

Источник

В какой связи idef1x проставляется ромб на стороне предка

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

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

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

Обозначения сущностей:

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

Обозначения связей:

Обозначение кардинальности связей:

Кроме того, в IDEF1X вводится понятие “отношение категоризации”, по смыслу эквивалентное рассмотренной нами иерархической связи. Отношение полной категоризации (сущности-категории составляют полное множество потомков родительской сущности) обозначается:

Также может существовать отношение неполной категоризации (сущности-категории составляют неполное множество потомков общей сущности):

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

Для обозначения отношения категоризации вводится элемент «дуга»:

Источник