Методические указания для курсового проектирования по дисциплине “

Федеральное агентство по образованию РФ

Сочинский институт экономики и информационных

технологий

Коваленко В.В.

РЕАЛИЗАЦИЯ
IDEF
0-,
IDEF
1
X
-МЕТОДОЛОГИЙ СРЕДСТВАМИ ПАКЕТА

AllFusion Modeling Suite

Методические указания

для курсового проектирования по дисциплине

“Проектирование информационных систем”

Сочи 2008

СОДЕРЖАНИЕ

1. Общие сведения о технологии проектирования ИС.....................3

2. Технология проектирования на базе комплекса российских стандартов ГОСТ 34.......................................................................................6

3. Построение функциональной модели ИС......................................8

3.1. Методология IDEF0…………………………..………...8

3.2. Стоимостный анализ (Activity Based Costing, ABC)....14

4. Построение ER-диаграммы..………………………......…....….....16

4.1. Общие сведения о методологии IDEF1X …...…..….16

4.2. Отношения категоризации.....................………….....…19

4.3. Синтаксис атрибутов и ключей...……………………...22

4.4. Процедуры моделирования ER-диаграммы.……....….24

5. IDEF1X-методология в пакете ERwin.............................................28

5.1.Создание сущностей и связей ER-диаграммы в ERwin.30

5.2. Интеграция IDEF0- и IDEF1X-моделей и связывание объектов модели данных со стрелками и работами.....................................33

5.3. Генерация базы данных физического уровня в среде СУБД Access....................................................................................................43

6. Порядок выполнения работ в курсовом проекте по проектированию информационных систем..................................................49

6.1. Формирование требований к ИС....................................50

6.2. Разработка концепции ИС...............................................51

6.3. Техническое задание........................................................55

6.4. Технический проект.........................................................57

Литература.............................................................................................. 60

Приложение №1. Организационная диаграмма и Swim Lane diagram .............................................................................................................. 61

Приложение №2. Функциональная модель “AS IS” управления городом......................................................................................... 64

Приложение №3. Функциональная модель “ТО ВЕ ”

управления городом.........................................................................................67

1. Общие сведения о технологии проектирования ИС

Технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой информационной системы (ИС). Каждая технология поддерживается конкретными стандартами, методиками и инструментальными средствами, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ).

Технология проектирования определяется как совокупность трех составляющих: пошаговой процедуры

, определяющей последовательность технологических операций проектирования; критериев и правил

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

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

Технология проектирования, разработки и сопровождения ИС
должна удовлетворять следующим требованиям:

- поддерживать полный ЖЦ ИС;

- обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

- обеспечивать возможность выполнения крупных проектов в виде подсистем;

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

- обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, ОС, языков программирования);

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

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

- стандарты проектирования;

- стандарты оформления проектной документации;

- стандарты пользовательского интерфейса.

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

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

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

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

Существует несколько моделей ЖЦ ИС, которые отличаются различным количеством этапов и их содержанием: каскадная, спиралевидная, непрерывной разработки, быстрого прототипирования fast track и др. Выбор модели определяется сложностью ИС, ее масштабом, желанием заказчика и т.д. Каждая из ведущих фирм разработчиков CASE-средств и СУБД име-ют свой набор моделей ЖЦ, этапы которых обеспечиваются программным инструментарием.

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

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

Основной недостаток этой модели ЖЦ в том, что реальный процесс создания ИС никогда полностью не укладывается в такую жесткую схему: «Все работы должны выполняться на каждом этапе сразу и за один раз».

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

Для преодоления этих проблем была предложена спиральная (спиралевидная)

модель ЖЦ (рис. 1), которая делает основной упор на начальные этапы ЖЦ: анализ и проектирование.

Рис. 1. Спиральная модель ЖЦ ИС

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

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

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

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

2. Технология проектирования на базе комплекса российских стандартов ГОСТ 34

В ГОСТе 34.601-90 «Автоматизированные системы. Стадии создания» определяются стадии и этапы создания ИС (рис. 2).

Рис. 2. Этапы жизненного цикла ИС

1. Формирование требований:

- обследование объекта и обоснование необходимости создания ИС;

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

2. Разработка концепции АС:

- изучение объекта (модель «AS IS» (как есть));

- разработка вариантов концепции ИС и выбор варианта (модели «TO BE» (как должно быть));

- оформление отчета о выполненных работах.

3. Техническое задание:

- разработка и утверждение ТЗ.

4. Эскизный проект:

- разработка предварительных проектных решений по системе и ее ча-стям (определяются функции ИС, функции подсистем; состав комплексов задач и интерфейсов; концепция БД, ее укрупненная структура; функции СУБД; состав вычислительной системы; функции и параметры основных аппаратных средств);

- разработка документации на ИС.

5. Технический проект:

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

граммному обеспечению);

- разработка документации на АС (полное описание совокупности принятых проектных решений и достаточного для дальнейшего выполнения работ по созданию ИС (ГОСТ 34.201)).

6. Рабочая документация:

- разработка рабочей документации на систему и ее части (для обеспе-чения работы по вводу ИС в эксплуатацию, а также для поддержания уров-ня эксплуатационных характеристик системы (ГОСТ 34.201));

- разработка или адаптация (покупных) программ.

7. Ввод в действие:

- подготовка объекта автоматизации к вводу ИС в действие (организационная подготовка);

- подготовка персонала;

- строительно-монтажные работы;

- пуско-наладочные работы (автономная наладка технических и программных средств, загрузка информации в БД; комплексная наладка всех средств системы);

- проведение предварительных испытаний;

- проведение опытной эксплуатации;

- проведение приемочных испытаний.

8. Сопровождение АС:

- выполнение гарантийных обязательств;

- анализ функционирования ИС, ее модификация и выпуск новых вер-сий.

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

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

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

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

Проектирование и разработка сложных ИС может быть выполнена с применением программных инструментариев СУБД Oracle: функциональ-ная модель
может быть построена с помощью Process Modeller, Function Hierarchy Diagrammer; база данных
логического уровня – с помощью Entity Relationship Diagrammer; пользовательский интерфейс
– на основе языка 4-го поколения Oracle Forms и программные модули
на языке 3-го поколения PL/SQL.

Для проектирования и разработки простых ИС, в том числе и для учебных целей, удобно использовать более простые программные инструментарии. Обычно в этих случаях применяют пакет BPwin для построения всего комплекта диаграмм для описания функционального
наполнения предметной области: организационная диаграмма, диаграммы плавательных дорожек и интегрированная иерархическая функциональная модель на основе методологий IDEF0, IDEF3, DFD.

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

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

3. Построение функциональной модели ИС

3.1. Методология IDEF0

Для построения функциональных моделей обычно используется методология IDEF0, которая хорошо представлена в пакетах Design/IDEF и BPwin (All Fusion Process Modeler 4.1) [3].

Методология IDEF0, более известная как методология SADT (Structure Analysis and Design Technique) предназначена для представления функ-ций системы и анализа требований к системам. Она является одной из самых известных и широко используемых методологий проектирования ИС.

Построение IDEF0-моделей в среде этих двух пакетов практически не отличается, но в BPwin возможно построение интегрированных функциональных моделей, объединяющих три вида методологий: IDEF0, IDEF3 и Data Flow Diagramm (диаграмм потоков данных, DFD).

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

Первый принцип системного анализа

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

Второй принцип

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

Выявление в объекте функционально самостоятельных составных час-тей (третий принцип)

предполагает выяснение того, кто и что делает в организации.

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

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

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

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

Диаграммы являются главными компонентами модели.

Основными элементами диаграмм являются функциональные блоки и дуги, которые представляются соответственно прямоугольниками и стрел-

ками.

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

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

В IDEF0 используется четыре типа дуг: входные (INPUT), управления (CONTROL), выходные (OUTPUT) и механизма (MECHANIZM), представ-ляющие собой ICOM-объекты (аббревиатура из первых букв английских названий дуг). В качестве иллюстрации приведем контекстную диаграмму функциональной модели кардиологического терапевтического отделения (рис. 3).

Рис. 3. Контекстная диаграмма методологии IDEF0

Входы (INPUT) - это материалы или информация, которые используются или преобразуются функциональным блоком для получения результата. Они входят в функциональный блок слева. Допускается отсутствие входных дуг.

Управление (CONTROL) - это правила, стратегии, процедуры или стандарты, которыми руководствуется функциональный блок. Дуги управления входят в функциональный блок сверху. Должна быть обязательно хотя бы одна дуга.

Механизмы (MECHANIZM) - это ресурсы, которые выполняют работу в функциональном блоке (персонал, станки, транспорт и т.д.). Эти дуги входят в функциональный блок снизу. По усмотрению системного аналитика дуги механизма могут не отображаться на диаграмме.

Дуги механизмов или управления могут быть входами других блоков.

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

Контекстная диаграмма является верхним уровнем иерархии функци-ональной модели и представляет собой наиболее обобщенную схему функционирования предметной области.

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

Рис. 4. Окно выбора методологий и количества блоков декомпозиции.

Щелкнув по клавише ОК, получают диаграмму декомпозиции первого уровня, которая содержит: выбранное выше количество блоков и ICOM-коды, то есть названия всех дуг контекстной модели. Необходимо дать названия блокам, подсоединить к ним по смыслу ICOM-объекты и построить требуемые соединительные (внутренние) дуги, присвоив им названия (рис. 5).

Если ICOM-объекты не используются на каком-либо уровне иерархии, то дуги, соединяющие эти объекты, можно поместить в туннель. Причем если в туннель помещен конец дуги (конец дуги помещается в квадратные скобки), то дуга и соответствующий ей ICOM-объект отсутствует на диаграмме-родителе. Если в туннель помещено начало дуги, то дуга и соответствующий ей ICOM-объект отсутствуют на диаграмме-потомке (дуга ВРАЧ на рис. 3).

Рис. 5. IDEF0-диаграмма второго уровня иерархии

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

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

При удалении объекта его необходимо выделить, а затем нажать на клавишу <Delete>.

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

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

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

Для редактирования имен объектов необходимо с ним совместить курсор, с помощью ПКМ вызвать контекстное меню и воспользоваться командой Name.

Для удаления какой-либо из диаграмм, ее необходимо открыть, выполнить команду Edit/Delete diagram и щелкнуть по кнопке Delete. Другой вариант удаления – выполнить команду Diagram / Diagram manager.

Для сохранения модели требуется выполнить команду File/Save. Если модель сохраняется впервые, то при выполнении этой команды откроется окно диалога Save Diagram As. В разделе “Имя файла” надо набрать на клавиатуре имя файла (рекомендуется давать имя файла латинскими буквами) и нажать <OK>.

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

Рис. 6. Дерево узлов

Иерархия IDEF0-модели может быть представлена в виде дерева узлов. Для этого необходимо воспользоваться командой Node Tree diagrams в навигаторе, запускающей Мастер построения диаграммы (Node Tree Wizard), который позволяет задать необходимые опции для выбора нужного типа диаграммы.

3.2.
Стоимостный
анализ
(Activity Based Costing, ABC)

BPwin предоставляет аналитику инструмент для оценки модели – сто-имостный анализ, основанный на работах (Activity Based Costing, ABC),с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC при-меняется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности пред-

приятия (Business Process Reengineering, BPR).

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

Рис. 7. Настройка единиц измерения валюты и времени

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Model/Model Properties), вкладка ABC Units (рис. 7).

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Dictionary (меню Dictionary / Cost Center (рис. 8). Каждому центру затрат следует дать подробное описание в окне Definition. Для отдельной модели задается один набор функциональных центров.

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции нижнего уровня) следует щелкнуть ПКМ по работе и на всплывающем меню выбрать Costs (рис. 9). Во вкладке Costs диалога Activity Properties указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т.е. задается стоимость каждой работы по каждой статье расхода.

Рис. 8. Диалог Cost Center Dictionary

Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions (в окне Activity Properties), подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх.

Рис. 9. Задание стоимости работ в диалоге Activity Cost

4. Построение ER-диаграммы

4.1. Общие сведения о методологии
IDEF
1
X

Методология IDEF1X представляет собой семантическое моделирование данных и применяется для построения информационной модели в виде ER-диаграммы (рис. 10), которая представляет структуру информации, необходимой для поддержания функции производственной системы или среды.

Основными конструкциями ER-диаграммы являются:

1. Предметы (сущности), к которым относятся данные. Они изобража-ются блоками.

2. Отношения между этими предметами, которые изображаются с по-мощью линий, соединяющих эти блоки.

3. Характеристики этих предметов, изображаемые именами атрибутов внутри блоков.

Рис. 10. ER-диаграмма

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

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

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

Независимая сущность рисуется прямоугольником. Зависимая сущность рисуется прямоугольником с закругленными углами.

Каждой сущности присваиваются уникальное имя, которое помещается над блоком.

Имя является грамматическим оборотом существительного в единственном числе (у существительного могут быть прилагательные и предлоги).

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

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

Правила, связанные с сущностями:

1. Каждая сущность должна иметь уникальное имя.

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

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

4. Каждая сущность может обладать любым количеством отношений с другими сущностями модели.

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

Отношениe родитель-потомок – это связь между сущностями, при которой одна сущность, называемая родительской, и может быть связана с произвольным (в том числе и нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком. Каждый экземпляр сущности-потомка связан в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности потомка может существовать только при наличии сущности-родителя.

Отношение связи может дополнительно определяться с помощью указания мощности отношения. Мощность отношения определяет, какое количество экземпляров сущности-потомков может существовать для каждого экземпляра сущности-родителя.

Существует четыре типа мощности отношения:

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

- каждый экземпляр сущности-родителя может иметь не менее одного связанного с ним экземпляра сущности-потомка (P);

- каждый экземпляр сущности-родителя может иметь не более одного связанного с ним экземпляра сущности-потомка (Z);

- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка (N).

Отношения связи отображаются линией с точкой на конце у сущности-потомка. Рядом с этой линией указывается мощность отношения (P, Z или N).

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

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

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

Правила отношений:

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

2. Экземпляр сущности-родителя может быть связан с любым числом (0 и более) экземпляров сущности-потомка, в зависимости от указанной мощности отношения.

3. В идентифицирующем отношении сущность-потомок всегда является зависимой от идентификатора сущностью.

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

4.2. Отношения категоризации

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

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

Рис. 11. Фрагмент ER-диаграммы с отношением полной категоризации

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

Допускается существование неполного множества категорий. Например, если существует экземпляр общей сущности, не связанный ни с одним экземпляром сущности-категории, то такое отношение называется отношением неполной категоризации.

При наличии между сущностями отношений категоризации в экземп-

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

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

Отношение категоризации не именуется, но может звучать как “может быть”.

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

Правила отношений категоризации

1. Сущность-категория может иметь только одну общую сущность.

2. Сущность-категория может быть общей сущностью.

3. Атрибуты первичного ключа общей сущности и сущности-катего-рии должны совпадать.

4. Все экземпляры сущности-категории имеют одно и то же значение дискриминатора.

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

Рис.12. Пример неспецифического отношения

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

Рис. 13. Пример введения сущности-пересечения

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

4.3. Синтаксис атрибутов и ключей

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

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

Правила атрибутов:

1. Сущность может обладать любым количеством атрибутов.

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

сущности-родителя или общей сущности.

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

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

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

Правило первичных и альтернативных ключей

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

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

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

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

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

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

Если все атрибуты первичного ключа родителя наследуются в качестве части первичного ключа сущности-потомка, то отношение называется идентифицирующим.

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

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

В некоторых случаях сущность-потомок может иметь несколько отно-шений с одной и той же сущностью-родителем.

Первичные ключи сущности-родителя в этом случае появляются в сущности-потомке в качестве наследуемых атрибутов для каждого отноше

ния.

Внешний ключ помещается внутри блока сущности как наследуемый атрибут с буквами (FK) - Foreign Key (рис. 10).

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

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

Имена атрибутов являются грамматическими оборотами существительного.

Правила внешних ключей

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

2. Первичный ключ общей сущности должен наследоваться в качестве внешнего ключа для каждой сущности-категории.

3. Каждое присвоенное наследуемому атрибуту имя роли должно быть уникальное.

4.4. Процедуры моделирования
ER-диаграммы

Сам процесс моделирования разбивается на пять стадий.

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

Стадия 2 – идентифицируются и определяются сущности.

Стадия 3 – идентифицируются и определяются соотношения между сущностями.

Стадия 4 – идентифицируются и определяются ключи.

Стадия 5 – идентифицируются и определяются неключевые атрибуты.

Стадия 1 – начало работы над проектом

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

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

План моделирования служит основой для распределения задания и оценки расходов на моделирование.

Стадия 2 - определение сущностей

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

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

1. Может ли она быть описана, т.е. обладает какими-либо характерными особенностями?

2. Существует ли более одного экземпляра этой сущности?

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

4. Называет или описывает это что-либо? Если этот ответ положительный, то это скорее атрибут, чем сущность.

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

В качестве примера можно привести существительные, используемые для описания модели на рис. 38: комитет, МУП, заявка, сводная заявка
, наименование товара, цена, адрес, руководитель, поставщик
, сотрудник
, образование, должность, дата заявки, реквизиты банка и др. Выделенные жирным шрифтом слова соответствуют требованиям, указанным в пп.1-4. Оставшиеся слова можно использовать в качестве атрибутов.

На четвертом этапе некоторые сущности из этого списка могут быть исключены и добавлены новые.

Стадия 3 - определение отношений

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

Первым шагом на второй стадии является выявление отношений между элементами различных сущностей, для чего строится матрица отношений в виде таблицы (рис.14).

Студент	Предмет	Лектор	Аудитория	Классные занятия
Студент
Предмет
Лектор
Аудитория
Классные занятия

Рис. 14. Матрица “сущность-отношение”

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

Не следует устанавливать чрезмерное количество отношений между сущностями. Следует иметь в виду, что с помощью этой матрицы вы описываете модель в терминах отношений “родитель-потомок”.

Следующим шагом является определение выявленных отношений, которые включают следующие компоненты:

1. Указание зависимостей.

2. Имя отношения.

3. Комментарии к отношениям.

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

Стадия 4 - определение ключей

Цели стадии:

1. Детализация неспецифических отношений.

2. Определение ключевых атрибутов для каждой сущности.

3. Перемещение первичных ключей на установление внешних ключей.

На стадии 4 требуется избавиться от всех неспецифических отношений и включать появляющиеся при этом новые сущности и отношения в матрицу "сущность/отношение" (стадия 3).

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

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

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

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

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

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

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

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

Проверка правильности ключей и отношений

Идентификация и миграция ключей подчиняются следующим правилам:

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

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

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

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

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

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

Стадия 5 - определение атрибутов

Стадия 5 завершается стадией разработки модели и включает в себя:

1. Установление принадлежности атрибутов к сущности.

2. Определение не ключевых атрибутов.

3. Проверку правильности и детализацию структур данных.

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

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

Затем необходимо произвести определение атрибутов, которое включают в себя имя атрибута, определение атрибута, синонимы атрибута.

Имя атрибута должно быть уникальным.

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

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

5. IDEF1X-методология в пакете ERwin

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

После построения логического уровня можно выбрать необходимую СУБД и создать физический уровень модели, в которой содержится информация обо всех объектах базы данных (таблицах, колонках, индексах, процедурах и т.п.). Для одного логического уровня можно построить несколько разных физических уровней для различных СУБД (Oracle, Informix, Sybase, Ingress и т.д.).

ERwin позволяет создавать модели трех типов: логическую (Logical
),

физическую (Phisical
) и модель, имеющую как логический, так и физический уровни (Logical
/
Phisical
), пакет Design/IDEF- модель логического уровня. При создании новой модели в диалоге Create
Model
можно выбрать тип новой модели. Рекомендуется выбирать тип модели (Logical
/
Phisical
), так как при генерации базы данных физического уровня потребуется физический тип модели.

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

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

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

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

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

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

5.1. Создание сущностей и связей
ER
-диаграммы в
ERwin

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

Построение модели данных предполагает определение сущностей и атрибутов, т.е. необходимо определить, какая информация будет храниться в конкретной сущности и в конкретном атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели) щелкнуть на кнопке сущности Ей на панели инструментов, затем щелкнуть на том месте диаграммы, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity
Properties
, можно вызвать диалог Entities
, в котором определяются имя, описание и комментарии сущности (рис. 15).

Рис. 15. Диалог Entities

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

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

Для атрибутов первичного ключа во вкладке General
диалога Attributes
необходимо сделать пометку в окне выбора Primary
Key
.

Вкладка Definition
позволяет записывать определения отдельных атрибутов.

Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. При помощи списка выбора Icon
во вкладке General
можно связать иконку с атрибутом.

Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Рис. 16. Диалог Attributes

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

Домен может быть создан на основе другого домена и наследовать все свойства домена-прародителя. По умолчанию ERwin имеет четыре предопределенных домена: String
,
Number
,
Blob
,
Datetime
.
Создать домен мож-но во вкладке Domains окна Model
Explorer
.

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

Рис. 17. Диалоговое окно для построения связей

Для создания новой связи следует:

· установить курсор на нужной кнопке (идентифицирующая или неидентифицирующая связь) в палитре инструментов и нажать левую кнопку мыши;

· щелкнуть сначала по родительской, а затем по дочерней сущности.

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

В палитре инструментов кнопка соответствует идентифицирующей связи, кнопка - связи "многие ко многим" и кнопка соответствуют неидентифицирующей связи.

Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать в контекстном меню пункт Relationship
Properties
.

Во вкладке General появившегося диалога можно задать мощность, имя и тип связи (рис. 17).

5.2. Интеграция
IDEF0- и
IDEF1
X-моделей и связывание объектов модели данных со стрелками и работами

BPwin позволяет связывать модели данных (ER-диаграммы) с

Рис. 18. Модель данных, открытая в ERwin

функциональными моделями, определяя при этом влияние работ (функциональных блоков) на данные и позволяя создавать спецификации на права доступа к данным для каждого процесса [3].

Первым шагом связывания модели данных и функциональной модели является экспорт данных из ERwin в BPwin. Для этого используем способ импорта через файлы формата .ЕАХ - .ВРХ
.

Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель (рис. 18) и выбрать пункт меню File/Export/BPwin. В появившемся диалоге Select BPwin Export File необходимо выбрать каталог, вставить имя создаваемого файла экспорта с расширением *.еах и нажать “Сохранить”. Затем в BPwin нужно открыть модель процессов (рис. 19) и выбрать в меню пункт File/Import/ERwin (EAX). Затем в диалоге Open выбрать имя файла с расширением *.еах и нажать “Открыть”.

Рис. 19. Функциональная IDEF0-модель

Появится диалог Import Differences Preview, в котором показывается протокол импорта (рис. 20). Для внесения данных в модель процессов следует щелкнуть по кнопке Accept. Кнопка Cancel отменяет импорт.

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

) функциональной модели (рис. 19) и выбрать в контекстном меню Arrow Data.

Появляется вкладка Arrow Data диалога Arrow Properties (рис. 21).

Рис. 20. Диалог Import Differences Preview

Рис. 21. Вкладка Arrow Data диалога Arrow Property для стрелки ценники

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

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

В появившемся диалоге Data
Usage
Editor
(рис. 22) в виде иерархического списка показываются все функциональные блоки модели (учет продаж, учет товара), стрелки (ценники, накладная в торговый зал, накладная поставщика и др.), которые касаются блоков, сущности (
prodavec
,
tovar
,
zakaz
)
и атрибуты (fio
,
cena
,
nazv
и др.), которые были связаны со стрелками. Для задания ассоциации достаточно щелкнуть по окну в иерархическом списке.

Рис. 22. Диалог BPwin Data Usage Editor

Для сущностей задается ассоциация CRUD
(Create, Read, Update, Delete), для атрибутов - IRUN
(Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN - это правила использования сущностей и атрибутов работами, т. е. то, что могут делать работы с входящими или исходящими данными. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразует в выход или потребляет. Такие данные могут быть обновлены (Update) или прочитаны (Read), но не могут быть созданы (Create, Insert) или удалены (Delete, Nullify). Данные, связанные со стрелками выхода, могут быть обновлены (если им соответствуют данные стрелок входа), удалены (Delete, Nullify) или созданы (Create, Insert). Для стрелок управления и механизма ассоциации не устанавливаются.

Результат связывания объектов модели процессов можно отобразить в отчете Data
Usage
Report
(Tools
/
Reports
/
Data
Usage
Report
) (рис. 23).

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

В окне Standarts
Reports
можно установить пять видов отчетов, указать их формат (в группе Report
Format
) и задать состав полей и их порядок следования в отчете.

На рисунке 23 установлены опции отчета, показанного на рис. 26 (вид отчета – Activity
Entity
Attribute
Association
). Этот вариант отчета позволяет определить, какие атрибуты сущностей задействованы в стрелках.

На рисунках 24, 25 приведены другие установки опций в окне Data
Usage
Report
.

Рис. 24. Отчет о связях функциональных блоков с сущностями и атрибутами.

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

Рис. 26. Отчет о связях стрелок с сущностями и атрибутами.

Анализов отчетов (рис. 26) и диалоговых окон (рис. 21) позволяет определить те атрибуты, которые не используются
во входных и выходных документах, а, следовательно, являются лишними, если в них не планируется хранение каких либо вычисляемых при эксплуатации данных.

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

Если в процессе связывания стрелок с объектами модели данных окажется, что каких-либо сущностей или атрибутов не хватает, их можно добавить прямо в BPwin с помощью команды Model
/
Entity
/
Attribute
Editor
(
рис. 27), а затем экспортировать в ERwin.

Рис. 27. Пример добавления атрибута data_izgot в сущность tovar

Если в модель данных были внесены изменения, то для ее экспорта из BPwin следует выбрать команду File
/
Export
/
ERwin
(ВРХ)
и указать имя нового файл, в который будет "выгружена" информация об измененной информационной модели.

В ERwin следует выбрать меню File
/
Import
/
BPwin
и в диалоге ERwin Open File указать файл ВРХ, в который была "выгружена" информация о модели. Возникает диалог ERwin
/
BPwin
Import
, в котором отображаются сущности и атрибуты, имеющиеся в ВРХ-файле, но отсутствующие в модели ERwin

После щелчка по кнопке Import
запускается процесс импорта ВРХ-файла и получаем сущность tovar
с новым атрибутом data
_
izgot
(рис. 28).

Если будет импортироваться вновь созданная сущность, то она не бу-

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

Рис. 28. Модифицированная в BPwin ER-диаграмма

5.3. Генерация базы данных физического уровня в среде СУБД
Access

Подготовка к генерации базы данных физического уровня начинается с создания пустой БД в среде той СУБД, куда планируется генерировать ER-диаграмму. Для этого надо запустить СУБД Access, выполнить команду на создание новой БД, присвоить ей имя и сохранить (рис. 29).

Рис. 29. Пустая БД с именем test
_
db
в СУБД Access

Рис. 30. Физическая модель БД в ERwin

Затем открываем ER-диаграмму в среде ERwin и с помощью списка выбора в стандартной панели инструментов производим переключение между логической и физической моделью (рис.30). При переключении, если физической модели еще не существует, она будет создана автоматически. Теперь надо выбрать СУБД, в которой будем производить генерацию БД физического уровня. Для этого следует выполнить команду DATABASE
/
Choose
database
, в появившемся диалоговом окне (рис. 31) выбрать интересующую СУБД Access и щелкнуть по кнопке <ОК>.

Рис. 31. Диалог выбора СУБД (сервера)

Рис. 32. Диалог присоединения к СУБД Access

Для у
становления соединения БД из ERwin c целевой СУБД Access необходимо выполнить команду DATABASE
/
Database
connection
. В появившемся диалоговом окне (рис.32) необходимо указать путь к БД в СУБД Access, вписать имя admin
и нажать кнопку Connect
. Для генерации БД физического уровня в среде СУБД Access необходимо выполнить команду TOOLS
/
Forward
Engineering
/
Schema
Generation
.
В результате получаем диалог генерации схемы БД (рис. 33), который имеет 3 закладки:

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

Во вкладке Summary
отображаются все опции, заданные во вкладке Options
. Список опций в Summary
можно редактировать так же, как и в Options
.

Comment
.
Позволяет внести комментарий для каждого набора опций.

Каждый набор опций может быть именован (окно Option Set, кнопки New, Rename и Delete) и использован многократно.

Кнопка Preview
вызывает диалог Schema
Generation
Preview
, в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД (рис. 34).

Рис. 33. Диалог генерации схемы БД

' CREATE
TABLE "
prodavec"

Set ERwinTableDef = ERwinDatabase.CreateTableDef("prodavec")

Set ERwinField = ERwinTableDef.CreateField("IDprod", DB_LONG)