Создание модели данных с помощью ERWin

Введение

 

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

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

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

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

SADT (Structured Analysis and Design Technique). Согласно SADT модель разрабатывается поэтапно. Сначала описывается деятельность предприятия в целом. Затем выполняется декомпозиция, в процессе которой рассматриваются все более и более мелкие аспекты работы предприятия, вплоть до каждого рабочего места. В созданной модели учитываются все информационные потоки, сопровождающие каждый аспект деятельности предприятия.

DFD (Data Flow Diagrams) – модели и диаграммы потоков данных.

ERD (Entity-Relationship Diagrams) – диаграммы сущность-связь.

На основании этих методологий разработаны стандарты моделирования бизнес-процессов IDEF0, DFD, IDEF3.

 Аббревиатура IDEF означает метод интегрального определения – Integrated DEFinition.

Любая информационная система предусматривает наличие базы данных, хранящей информацию, сопровождающую все бизнес-процессы. Разработан стандарт проектирования модели данных информационных систем - IDEF 1 X.

Фирмой PLATINUM technology созданы инструментальные средства, поддерживающие эти стандарты. Пакет BPWin, основанный на стандартах IDEF0, DFD и IDEF3, используют в процессе обследования предприятия для построения функциональной модели бизнес процессов. Анализ модели, выполняемый с помощью BPWin, позволяет изучить и улучшить структуру предприятия. Этот инструмент используют в основном системные аналитики и специалисты по внедрению информационных систем.

Пакет ERWin использует стандарт IDEF1X и предназначен для другого круга задач и специалистов другого профиля – это система проектирования БД.

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

 

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

 

CАSE - средства - Computer-Aided Software/System Engineering.

Design/IDEF

 

Создание модели данных с помощью ERWin

 

Интерфейс ERwin

 

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

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

Окно ERwin имеет типичный вид для всех приложений Windows.

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

Entity view – уровень сущностей;

Attribute view – уровень атрибутов;

Definition view – уровень определений.

Помимо основной панели инструментов в окне должна присутствовать так наз. палитра инструментов – ERwin Toolbox. Вид палитры инструментов зависит от уровня отображения.

На логическом уровне здесь расположены следующие кнопки:

 

 

Кнопка указателя мыши- Select - позволяет выбрать из палитры нужный объект.

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

Кнопка категории - Complete sub - category – позволяет установить так наз. категориальную связь между сущностями. Суть этой связи рассмотрим ниже.

Кнопка внесения текстового блока – Text – позволяет вносить текстовый комментарий в любую часть графической модели.

Кнопка перенесения атрибутов внутри сущности - Attribute manipulation – позволяет перемещать атрибуты внутри сущности способом drag&drop.

Три кнопки позволяют устанавливать связи – relationship - между сущностями. Можно установить идентифицирующую связь (1:М), связь М:М и не идентифицирующую связь (не определенную).

На физическом уровне вместо кнопки категорий на палитре инструментов присутствует кнопка внесения представлений (view table), а вместо кнопки связи М:М расположена кнопка связей представлений (view relationship).

Для создания моделей (логической и физической) в ERwin можно использовать две нотации (два стандарта) - IDEF 1 X и IE (Information Engineering).

Переключение между нотациями можно сделать на вкладке Methodology диалогового окна Preferences (меню Option / Preferences). Мы будем использовать нотацию IDEF 1 X.

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

ERwin позволяет связать с сущностью большую и малую иконки. При переключении на уровень иконок показывается большая иконка. Для отображения малой иконки следует выбрать в контекстном меню пункт Display Options / Entities и в каскадном меню включить опцию Entity Icon. Малая иконка будет показана слева от имени сущности на всех уровнях отображения модели.

Установить нужные цвет и шрифт любого объекта, текста, связи можно с помощью панели инструментов Форматирования, которая располагается под основной панелью. Можно также пользоваться пунктом Object Font / Color контекстного меню объекта.

 

Создание ключей

Для атрибутов первичного ключа на вкладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key. Список атрибутов разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже – не ключевые атрибуты. Первичный ключ может быть составным.

Некоторые сущности могут иметь несколько атрибутов, претендующих на роль первичного ключа или так наз. потенциальные ключи. В таком случае в качестве первичного выбирается тот атрибут, который наиболее полно удовлетворять всем требованиям, предъявляемым к первичному ключу реляционной модели (уникальность, компактность, отсутствие нулевых значений, неизменность в течение всего времени существования сущности). Остальные потенциальные ключи можно определить как альтернативные (Alternate Kay). По этим атрибутам будет сгенерирован уникальный индекс. На диаграмме атрибуты альтернативных ключей обозначаются АК n, m, где n – порядковый номер ключа, m – порядковый номер атрибута в ключе.

Некоторые из не ключевых атрибутов сущности могут часто использоваться для доступа к записям и для повышения производительности системы полезно по ним создать неуникальные индексы. С этой целью такие атрибуты надо определить как инверсные входы (Inversion Entries). Инверсные входы обозначаются IE n, m, где n – порядковый номер входа, m – порядковый номер атрибута.

Поскольку каждый из ключей может состоять из одного или нескольких атрибутов, в ERwin принят термин "Ключевая группа". Создать несколько разновидностей ключей, т.е. ключевых групп, можно на вкладке Kay Group диалога Attribute Editor. Кнопка с многоточием, расположенная в правой верхней части вкладки вызывает окно Kay Group Editor. В верхней части окна находится список ключей, в котором вначале присутствует только одна строка для первичного ключа. В нижней части слева находится список атрибутов сущности.

Для создания новых ключевых групп надо кнопкой New вызвать диалог New Kay Group. Тип ключевой группы задается кнопками Alternate Kay или Inversion Entry.  Каждая новь созданная ключевая группа должна содержать хотя бы один атрибут. Для включения атрибутов в состав ключевой группы надо в верхней части окна выделить ключевую группу, а в нижней части окна выделить нужный атрибут и с помощью кнопки перенести его в правую часть окна.

Теперь в окне Attribute Editor можно увидеть список всех атрибутов сущности с пометкой о вхождении каждого атрибута в ту или иную ключевую группу.

По умолчанию альтернативные ключи и инверсионные входы на диаграмме не помечаются. Для их отображения надо из контекстного меню диаграммы (на пустом месте) для пункта Display Options / Entities отметить пункт Alternate Key Designator.

Внешние ключи (Foreign Key) создаются ERWin автоматически при установлении связей.

 

Создание связей

На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую cвязь один-ко-многим. В палите инструментов каждому типу связи соответствует своя кнопка.

Идентифицирующая связь устанавливается между родительской и дочерней (зависимой) сущностями. Зависимая сущность изображается на диаграмме прямоугольником со скругленными углами. При установлении такой связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности и помечаются как внешний ключ (FK). Эта операция называется миграцией атрибутов. Каждый экземпляр дочерней сущности должен иметь родителя, поэтому при генерации схемы БД атрибуты первичного ключа получат признак NOT NULL.

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

Связь М:М возможна только в логической модели. При переходе к физическому уровню автоматически создается связующая сущность. При этом первичные ключи связываемых сущностей мигрируют в связующую сущность, образуя в ней первичный ключ. В соответствии с логикой предметной области в связующую сущность часто приходится добавлять новые атрибуты. Например, для связи между сущностями ВРАЧ и ПАЦИЕНТ в связующую сущность на физическом уровне потребуется добавить дату визита. В логической схеме этот атрибут не отобразится.

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

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

 

Редактирование связей

Для редактирования свойств связи надо из контекстного меню связи выбрать пункт Relationship Editor. Откроется окно редактора связи с таким же именем. Рассмотрим состав этого окна.

На вкладке General можно задать мощность, имя |и тип связи.

Каждая связь должна именоваться глаголом или глагольной формой. Например:

               размещает            выполняется

КЛИЕНТ                · ЗАКАЗ ·            СОТРУДНИК

 

Имя связи указывается в окне Verb Phrase.

Для связи один-ко-многим идентифицирующей или не идентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent - to - Child). Для связи М:М следует указать еще имя связи Child - to – Parent. Например:

 

                принимает

ВРАЧ ·                                  · ПАЦИЕНТ

                лечится у

 

По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню диаграммы (правая кнопка на любом свободном месте) выбрать пункт Display Options / Relationship и затем включить опцию Verb Phrase.

Мощность связи (Cardinality) обозначает отношение числа экземпляров родительской сущности к числу экземпляров дочерней и устанавливается с помощью флажков.

Флажок Zero, One or More определяет общий случай, когда у одного родителя может быть любое число потомков, включая 0. На диаграмме такая связь никак не обозначается.

Флажок One or More – исключает нулевое значение. На диаграмме обозначается символом Р.

Символом Z – флажок Zero or One - помечается случай, когда одному родителю соответствуют 0 или 1 экземпляр потомков.

Флажок Exactly позволяет задать точное количество потомков одного родителя.

По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения символа мощности на диаграмме следует в контекстном меню диаграммы выбрать пункт Display Options / Relationship и включить опцию Cardinality.

Опция Relationship Type позволяет установить флажок типа связи Identifying (идентифицирующая) или Non - Identifying (не идентифицирующая). Не идентифицирующая связь может быть обязательной (флажок No Null) или необязательной (флажок Nulls Allowed). В первом случае при генерации схемы БД атрибут внешнего ключа получит признак, не позволяющий принимать ему нулевого значения, несмотря на то, что внешний ключ не входит в состав первичного ключа дочерней сущности. В случае необязательной связи внешний ключ сможет принимать нулевое значение. Необязательная не идентифицирующая связь помечается на диаграмме прозрачным ромбиком со стороны родительской сущности.

На вкладке Definition редактора связи можно дать более полное определение связи для того, чтобы позже можно было на него ссылаться.

На вкладке Rolename / RI Actions можно задать имя роли и правила ссылочной целостности.

Имя роли (функциональное имя) – это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Например, пусть две сущности ОТДЕЛ (Номер отдела, Наименование отдела) и СОТРУДНИК (Табельный номер, Номер отдела (FK), Фамилия, …) связаны отношением 1:М. Внешнему ключу Номер отдела можно присвоить функциональное имя Где работает. Тогда полное имя внешнего ключа сущности СОТРУДНИК будет Где работает. Номер отдела. По умолчанию в списке атрибутов на диаграмме показывается только имя роли. Полное имя отобразится, если в пункте Display Option / Entities контекстного меню диаграммы включить опцию Rolename / Attribute.

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

Рассмотрим ситуацию, возникающую при обмене валюты, когда одна валюта обменивается на другую валюту. Пусть в БД определены две сущности: ВАЛЮТА и ПРОДАЖА ВАЛЮТЫ.

ВАЛЮТА                                              ПРОДАЖА ВАЛЮТЫ

                                      продается

Номер    Имя валюты  валюты

В1        Тугрик В2        Лира

·

Проданная.(FK) Купленная.(FK) Номер валюты. Номер валюты. В1                                   В2 В2                                    В1

 

 

·

 

                                     покупается

 

Здесь сущности ВАЛЮТА и ПРОДАЖА ВАЛЮТЫ связаны дважды и первичный ключ - Номер валюты должен дважды мигрировать в сущность ПРОДАЖА ВАЛЮТЫ. Поскольку одинаковые имена атрибутов в одной сущности не допустимы и, кроме того, эти атрибуты имеют разный смысл, необходимо для каждого из них задать функциональное имя.

 

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

ОТДЕЛ (Номер отдела, Наименование отдела)

СОТРУДНИК (Табельный номер, Где работает. Номер отдела (FK), Руководитель. Табельный номер (FK)).

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

 вкладке Rolename / RI Actions редактора связи в полях окна RI Actions устанавливаются также правила ссылочной целостности, т.е. правила выполнения операций добавления, удаления и корректировки данных. На основании опций, установленных в логической модели, при генерации схемы данных будут сгенерированы триггеры, обеспечивающие заданные установки. Триггеры представляют собой программы, выполняемые всякий раз при выполнении операций Insert, Update или Delete. В ERwin по умолчанию установлены определенные правила ссылочной целостности, которыми можно пользоваться.

 

Нормализация сущностей

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

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

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

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

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

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

ERwin имеет следующую функциональность для поддержки денормализации:

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

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

 

Диаграмму модели можно вывести на принтер с помощью диалога Print Model кнопки Печать или команды меню File / Print. Здесь можно увидеть расположение графических объектов, выводимых на печать. Кнопки Print All Pages или Print Selected Pages позволяют распечатать все страницы модели или только выделенные страницы. Можно установить масштаб и установить параметры печати (кнопка Page Setup).

 

Выбор сервера

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

Для выбора СУБД служит редактор Target Server (меню Server / Target Server). Здесь надо щелкнуть по соответствующей кнопке рядом с именем СУБД.

Тип данных можно выбрать в раскрывающемся списке Default Datatype. Он содержит типы данных, поддерживаемые выбранным сервером. Этот тип будет по умолчанию присваиваться каждому полю таблицы.

Группа кнопок Default Non - Key Null Option позволяет разрешить ил запретить значения NULL для не ключевых полей.

Окно выбора Allow special chars in names позволяет разрешить или запретить использование специальных символов и пробелов в именах таблиц для тех СУБД, которые поддерживают использование специальных символов.

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

Кнопка Reset Names вызывает диалог Globally Reset DBMS Property, который позволяет заменить все имена таблиц, связей, индексов, столбцов и соответствующих свойств, заданных вручную, на значения по умолчанию.

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

При смене СУБД ERwin предлагает автоматически преобразовать тип данных, связанный с каждым атрибутом, на ближайший, доступный для новой СУБД. Для автоматического преобразования следует в ответ на запрос нажать Yes.

 

Введение

 

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

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

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

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

SADT (Structured Analysis and Design Technique). Согласно SADT модель разрабатывается поэтапно. Сначала описывается деятельность предприятия в целом. Затем выполняется декомпозиция, в процессе которой рассматриваются все более и более мелкие аспекты работы предприятия, вплоть до каждого рабочего места. В созданной модели учитываются все информационные потоки, сопровождающие каждый аспект деятельности предприятия.

DFD (Data Flow Diagrams) – модели и диаграммы потоков данных.

ERD (Entity-Relationship Diagrams) – диаграммы сущность-связь.

На основании этих методологий разработаны стандарты моделирования бизнес-процессов IDEF0, DFD, IDEF3.

 Аббревиатура IDEF означает метод интегрального определения – Integrated DEFinition.

Любая информационная система предусматривает наличие базы данных, хранящей информацию, сопровождающую все бизнес-процессы. Разработан стандарт проектирования модели данных информационных систем - IDEF 1 X.

Фирмой PLATINUM technology созданы инструментальные средства, поддерживающие эти стандарты. Пакет BPWin, основанный на стандартах IDEF0, DFD и IDEF3, используют в процессе обследования предприятия для построения функциональной модели бизнес процессов. Анализ модели, выполняемый с помощью BPWin, позволяет изучить и улучшить структуру предприятия. Этот инструмент используют в основном системные аналитики и специалисты по внедрению информационных систем.

Пакет ERWin использует стандарт IDEF1X и предназначен для другого круга задач и специалистов другого профиля – это система проектирования БД.

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

 

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

 

CАSE - средства - Computer-Aided Software/System Engineering.

Design/IDEF

 

Создание модели данных с помощью ERWin