какие виды ключей должна содержать модель idef1x основанная на ключах
Какие виды ключей должна содержать модель idef1x основанная на ключах
Глоссарий IDEF1X
Авторские соглашения (author conventions)
Специальные приемы и стандарты, вырабатываемые разработчиком для улучшения представления и использования модели. Авторские соглашения должны не противоречить никаким методологическим правилам.
Альтернативный ключ (alternate key)
Ключ, не являющийся первичным ключом сущности.
Атрибут (attribute)
Характеристика или элемент данных, описывающие что-либо в сущности. Атрибуту присваивается специфическое имя, обозначающее его смысл (например, цвет волос) и значение (например, коричневый)
Булево ограничение (boolean constraint)
Условие ограничения на экземпляры сущностей-потомков в кратных отношениях с одной и той же родительской сущностью. Оператор «AND» означает, что родительская сущность должна обладать экземплярами сущности-потомка во всех отношениях. Оператор «OR» означает, что родительская сущность должна обладать экземплярами сущности-потомка хотя бы в одном из отношений. Оператор «XOR» означает, что родительская сущность может обладать экземплярами сущности-потомка не более чем в одном из отношений.
Внешний ключ (foreign key)
Атрибуты, появляющиеся в зависимой сущности и являющиеся также первичным ключом другой сущности (сущности-родителя или общей сущности).
Диаграмма сущности (entity diagramm)
Диаграмма, изображающая «основную» сущность и все сущности, прямо связанные с основной сущностью.
Зависимость от идентификатора (identifier dependency)
Ограничение между двумя сущностями, требующее, чтобы внешний ключ в зависимой сущности был ее первичным ключом (или его частью). Зависимость от идентификатора является более сильной формой зависимости существования.
Зависимость существования (existence dependency)
Значение атрибута (attribute value)
Конкретное значение, даваемое атрибуту (например, атрибут: цвет волос; значение атрибута: коричневый).
Имя роли (role name)
Имя, присваиваемое внешнему ключу, появляющемуся более одного раза в сущности.
Имя отношения (relationship name)
Определение в виде предложения, которое отражает значение отношения между двумя сущностями, показанными на той диаграмме, где приводится это имя.
Источник (source)
Сущность-категория (category entity)
Сущность, образцы которой являются подмножеством экземпляров другой сущности, представляющей тот же самый предмет реального мира. Все атрибуты общей сущности относятся также к сущности-категории. Например, «штатный служащий» является сущностью-категорией общей сущности «служащий».
Ключ (key)
Атрибут или комбинация атрибутов сущности, чьи значения однозначно идентифицируют каждый экземпляр сущности.
Комитет рецензирования и одобрения (acceptance review committee)
Элемент функциональной организации процесса создания моделей, ответственный за руководство и арбитражные решения по моделированию, а также за принятие конечного решения по завершенному продукту (т.е. за принятие модели).
Миграция ключа (key migration)
Процесс перемещения первичного ключа родительской или общей сущности в сущность-потомок или сущность-категорию из соответствующего отношения.
Мигрирующий атрибут (migrated attribute)
То же самое, что и наследуемый атрибут.
Мигрирующий ключ (key, migrated)
То же самое, что и внешний ключ.
Менеджер проекта (project manager)
Один из членов коллектива разработчиков, ответственный за административное управление процессом моделирования. В его обязанности входят: укомплектование штата разработчиков, установление области действия и целей, председательствование на заседаниях комитета рецензирования и одобрения и т.п.
Мощность отношении (relationship cardinality)
Количество экземпляров сущности, которые могут быть ассоциированы с любым из других экземпляров в отношении (см. ограничение мощности).
Наследуемый атрибут (inherited attribute)
Атрибут, являющийся первичным ключом (или частью первичного ключа) другой сущности. Он мигрирует из этой сущности через отношение между сущностями.. Называется также мигрирующим атрибутом.
Неспецифическое отношение (nonspecific relationship)
Отношение, в котором нельзя сказать определенно относительно сущности, зависит ли она от другой сущности. Примерами таких отношений являются отношения «много ко многому» и «ноль или один ко многому».
Нормализация (normalization)
Процесс детализации и перегруппировки атрибутов в сущностях в соответствии с нормальными формами, делающий смысл данных более ясным.
Нормальные формы (normal forms)
условия, отражающие степень детализации в идентификации сущностей и определяющие размещение атрибутов в сущностях модели данных. Каждая следующая нормальная форма отражает последовательно более жесткий контроль за отношениями между атрибутами сущности.
Ограничение (constraint)
Утверждение, целью которого является точная спецификация значений данных.
Ограничение мощности (cardinality constraint)
Ограничение числа появлений сущности-потомка, которая может быть связана с родительской сущностью.
Ограничение существования (existence constraint)
Условие, при котором одной сущности не может существовать, если не существует экземпляр другой связанной с ней сущности.
Область (domain)
Множество допустимых значений. Область может определяться типом данных (например, целое число, дата, деньги) и может включать ограничения на значения (например, больше нуля; от 2 до 12; 17 символов; одно из чисел 2, 5, 10, 16). Одна и та же область может быть областью определения для нескольких атрибутов.
Отношения (relationship)
Логическая ассоциация между сущностями.
Принадлежащий атрибут (owned attribute)
Атрибут, который не наследуется. Принадлежность определяется относительно сущности. Атрибут может принадлежать только одной сущности.
Проверка правильности (validation)
Мероприятие, приводящее к консенсусу экспертов, обладающих данными о модели. Модель считается «верной», если большинство экспертов согласилось с тем, что модель правильно и полностью представляет интересующую сферу.
План сбора данных (data collection plan)
План установления объектов (например, функций, отделов, персонала), которые являются источниками материала, используемого для разработки модели.
Первичный ключ (primary key)
Ключ сущности, выбранный для миграции через все отношения, в которых данная сущность участвует в качестве родительской или общей сущности.
Популяция атрибута (attribute population)
То, чем определяется принадлежность классов атрибутов.
Разработчик (автор) (modeler (author))
Один из членов коллектива, разрабатывающего модель, который отвечает за выбор данных, обучение и тренинг, запись модели и управление моделью в процессе ее разработки. Разработчик является экспертом по IDEF1X-методологии моделирования.
Роль атрибута (attribute role)
Описывает функцию, выполняемую атрибутом в описании сущности, включая функции наследуемости (мигрируемости), принадлежности первичного ключа, альтернативного ключа.
Семантика (semantics)
Смысл слов и предложений в языке или в конструкциях модели. Сравните с синтаксисом.
Сложный ключ (compound кеу)
То же самое, что и составной ключ.
Синтаксис (syntax)
Грамматика. Множество правил для формирования осмысленных фраз и предложений из словарных слов. Сравните с семантикой.
Специфическое отношение (specific relationship)
Отношение, в котором существование одной сущности зависит от существования другой.
Составной ключ (кеу, composite)
Ключ, состоящий из более чем одного атрибута.
Стадия 0 (Phase Zero)
Начальные действия при моделировании, во время которых устанавливается контекст, т.е. определение проекта, план сбора данных, авторские соглашения, стандарты и т.п.
Стадия 1 (Phase One)
Второй этап моделирования, во время которого идентифицируются и определяются сущности.
Стадия 2 (Phase Two)
Третий этап моделирования, во время которого идентифицируются и определяются отношения.
Стадия 3 (Phase Three)
Четвертый этап разработки модели, во время которого идентифицируются и определяются ключи.
Стадия 4 (Phase Four)
Пятый этап разработки модели, во время которого идентифицируются и определяются «неключевые» атрибуты.
Схема (schema)
Определение структуры данных.
Сущность (entity)
Совокупность похожих объектов/экземпляров (людей, мест, предметов, событий), которая именуется общим существительным, обладает ключом (однозначно идентифицирующим каждый экземпляр) и имеет один или несколько атрибутов (описывающих каждый экземпляр).
Утверждение (assertion)
Утверждение, устанавливающее условие, которое должно быть истинным.
Функциональная зависимость (functional dependency)
Ограничение между двумя атрибутами, указывающее на то, что значение одного атрибута определяется значением второго.
Цикл IDEF-папки (IDEF kit cycle)
Регулярный обмен частями модели во время ее разработки между разработчиком и читателями/экспертами/рецензентами, целью которого является определение и исправление ошибок, пропусков и искажений.
Экземпляр сущности (entity instance)
Проявление именованной сущности. Может быть специфически идентифицирован значением своего ключа. После определения экземпляра сущности значения всех других атрибутов этого экземпляра являются также известными.
Один из членов коллектива разработчиков, специализирующийся на анализе некоторой конкретной функции промышленного предприятия и ответственный за обеспечение критических комментариев относительно разрабатываемой модели.
Элемент ключа (member key)
Атрибут, являющийся частью составного ключа.
Акроним, означающий «только для экспозиции» (For Exposition Only). Это средство, с помощью которого модель обеспечивается сопроводительной и пояснительной информацией с использованием некоторого набора чертежей, текстов и т.п.
IDEF1X-модель (IDEF1X model)
Графическое представление данных в среде. Отражает основную структуру и отношения данных. Результат применения расширенного языка определений ICAM к моделированию информации/данных (IDEF1X).
Методология IDEF1X
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 книги.
Отношения
Рис. 5.4. Примеры отношений используют нотацию IE системы ERwin, в которой «коровьи копыта» или «трезубцы» отображают многие стороны отношений.
Физические модели
Существует два уровня физических моделей: трансформационная модель и модель СУБД. Физические модели содержат информацию, необходимую системным разработчикам для понимания механизма реализации
логической модели в СУБД.
Трансформационная модель
Целью трансформационной модели является предоставление информации администратору БД для создания эффективной структуры хранения, включающей в себя записи, формирующие БД. Трансформационная модель должна помочь-разработчикам выбрать структуру хранения данных и реализовать систему доступа к ним.
Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:
Модель СУБД
Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД.
Преимущества от использования CASE-средства ERWin
Первым преимуществом является использование формируемый средством документов, на основании которых производится проектирование БД и приложений, обеспечивающих доступ к БД. На основании этих документов производится формулирование системных требований к проектируемой БД.
Вторым преимуществом является возможность создания диаграмм структуры БД, позволяющих автоматически решать вопросы, связанные с сохранением ее целостности.
Третье преимущество заключается в независимости логической модели от используемой СУБД, что позволяет применять универсальные методы для ее экспорта в конкретные СУБД.
Кроме того, ERWin предоставляет возможность формирования большого числа отчетов, отражающих текущее состояние процесса проектирования БД.
Инструментарий ERWin
При запуске ERWin появляется основная панель инструментов и палитра инструментов (табл. 5.1).
Таблица 5.1. Основная панель инструментов ERWin
Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне панель инструментов выглядит следующим образом (рис. 5.5).
Рис. 5.5. Палитра инструментов на логическом уровне
1. Слева направо, верхний ряд:
раз по свободному пространству на модели. Повторный щелчок приведет к внесению в модель еще одной новой сущности. Для редактирования сущностей или других объектов модели необходимо перейти в режим указателя.
2. Слева направо, нижний ряд:
На физическом уровне палитра инструментов имеет следующий вид (рис. 2.6).
Рис. 5.6. Палитра инструментов на физическом уровне
Контрольные вопросы
Какие виды ключей должна содержать модель idef1x основанная на ключах
Основы методологии 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 диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.
Классификация сущностей в IDEF1X. Зависимые и независимые сущности.
При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. В примере на рис.1 сущность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ. В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.
Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела.
Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАПРОС, используемый для отслеживания запросов покупателей, и ПОЗИЦИЯ ЗАПРОСА, который отслеживает отдельные элементы в ЗАПРОСе. Связь между этими двумя сущностями может быть выражена в виде ЗАПРОС один или несколько ПОЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зависит от существования ЗАКАЗА.
Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущность ОТДЕЛ можно считать независимой. В IDEF1X независимые сущности представлены в виде прямоугольников.
Типы связей между сущностями. Идентифицирующие и неидентифицирующие связи.
В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можете создать идентифицирующую связь между родительской и дочерней сущность.
Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.
Неидентифицирующие связи отображаются пунктирной линией между объектами. Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности.
Тем не менее, взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.
Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком ER.
Дополнительную информацию Вы можете получить в компании Interface Ltd.