Правила создания перекрестков. Примеры неправильных перекрестков
На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов, необходимо соблюдать следующие правила:
Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ". Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ-2 и 3. Такой сценарий не может реализоваться.
Неверное
размещение перекрестков. Перекресток
для слияния "И" не может следовать
за перекрестком для разветвления "ИЛИ"
Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ".
Неверное
размещение перекрестков. Перекресток
для слияния "И" не может следовать
за перекрестком для разветвления типа
исключающего "ИЛИ"
Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.
Неверное
размещение перекрестков. Перекресток
для слияния типа исключающего "ИЛИ"
не может следовать
Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Основные принципы нотации информационного проектирования IDEF1X. Логическая и физическая модели данных. Смысловые примитивы. Сущности. Атрибуты. Связи.
Нотация idef1x как средство построения модели данных
Для проектирования информационной модели бизнес-процессов используется методология IDEF1X Метод моделирования, который поддерживает графическое описание:
логических конструкций данных, используя сущности, атрибуты и связи сущностей;
физических конструкций данных специфицированных на применение в конкретной СУБД используя трансформацию сущностей в таблицы; атрибуты в свойства и характеристики; связи в таблицы и связи.
Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты базы данных могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики баз данных нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логический и физический уровни позволяет решить эту проблему. На физическом уровне объекты базы данных могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
