1.2.1. Принципы построения модели IDEF0

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT"M.:Meтaтexнoлoгия, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").

Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

• Почему этот процесс должен быть замоделирован?

• Что должна показывать модель?

• Что может получить читатель?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties (рис. 1.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.

Рис. 1.3. Диалог задания свойств модели

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

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

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

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

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Report/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 1.4).

Рис. 1.4. Отчет по модели

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

Модель может содержать четыре типа диаграмм:

• контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

• диаграммы декомпозиции;

• диаграммы дерева узлов;

• диаграммы только для экспозиции (FEO).

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

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

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

 

1.2.2. Работы (Activity)

Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Изготовление детали", "Прием заказа" и т.д.). Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 1.5).

Рис. 1.6. Редактор задания свойств работы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. 1.6).

Рис. 1.5. Пример контекстной диаграммы

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

Возникает диалог Activity Box Count (рис. 1.7), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 1.8). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис. 1.7. Диалог Activity Box Count

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

на палитре инструментов, а затем по свободному месту на диаграмме.

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

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

Рис. 1.8. Пример диаграммы декомпозиции

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 1.9 работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции.

Рис. 1.9. Пример декомпозируемых работ

 

1.2.3. Стрелки (Arrow)

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

В IDEF0 различают пять типов стрелок:

Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1.5 - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1.5 стрелки "Задание"и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1.5 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1.5 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

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

Для внесения граничной стрелки входа следует:

• щелкнуть по кнопке с символом стрелки

в палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

• щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

• вернуться в палитру инструментов и выбрать опцию редактирования стрелки

• щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 1.10. Диалог IDEF0 Arrow Properties

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 1.11).

Рис. 1.11. Фрагмент диаграммы декомпозиции с ICOM -кодами (I1, С1 и С2)

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию Show ICOM codes на закладке Presentation диалога Model Properties (меню Edit/Model Properties).

Рис. 1.12. Словарь стрелок

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

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

Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

Рис. 1.13. Пример несвязанных стрелок

На рис. 1.13 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы "Изготовление изделия" (см. рис. 1.5). Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.

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

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

Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей (например, на рис. 1.14 стрелка "Детали" связывает работы "Изготовление деталей" и "Сборка изделия").

Рис. 1.14. Связь по входу

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. 1.15 стрелка "Чертеж" связывает работы "Создание чертежа детали" и "Изготовление детали"), при этом чертеж не претерпевает изменений в процессе изготовления деталей.

Рис. 1.15. Связь по управлению

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 1.16 стрелка "Дрек" связывает работы "Переработка сырья" и "Контроль качества", при этом выявленный на контроле брак направляется на вторичную переработку.

Рис. 1.16. Обратная связь по входу

Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации", рис. 1.17). Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса. На рис. 1.17 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы "Контроль качества"

Рис. 1.17. Обратная связь по управлению

Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. 1.18).

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

Рис. 1.18. Связь выход-механизм

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

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

Рис. 1.19. Пример именования разветвляющейся стрелки

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

Рис. 1.20. Другой пример именования разветвляющейся стрелки

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку (рис. 1.21).

Рис. 1.21. Пример неверного именования разветвляющейся стрелки

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

Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 1.22).

Рис. 1.22. Неразрешенная (unresolved) стрелка

Для их "перетаскивания" наверх нужно сначала выбрать кнопку

на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 1.23).

Рис. 1.23. Диалог Border Arrow Editor

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце (рис. 1.24).

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

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

Рис. 1.24. Типы тоннелирования стрелок

 

1.2.4. Нумерация работ и диаграмм

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер АО. Работы i декомпозиции АО имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Имеются незначительные варианты нумерации, которые i можно настроить в закладке Presentation диалога Model Properties (меню Edit/Model Properties).

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, Al, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - C-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

 

1.2.5. Диаграммы дерева узлов и FEO

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

Рис. 1.25. Диаграмма дерева узлов

Для создания диаграммы дерева узлов следует выбрать в меню пункт Insert/Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition (рис. 1.26).

Рис. 1.26. Диалог настройки диаграммы дерева узлов

В диалоге Node Tree Definition следует указать глубину дерева - Number of Levels (по умолчанию 3) и корень дерева (по умолчанию - родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выключить опцию Bullet Last Level. При создании дерева узлов следует указать имя диаграммы, поскольку, если в нескольких диаграммах в качестве корня на дереве узлов использовать одну и ту же работу, все эти диаграммы получат одинаковый номер (номер узла + постфикс N, например AON) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Insert/FEO Diagram. В возникающем диалоге Create New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы (рис. 1.27).

Рис. 1.27. Диалог создания FEO-диаграммы

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

 

1.2.6. Каркас диаграммы

На рис. 1.28 показан типичный пример диаграммы декомпозиции с граничными рамками, которые называются каркасом диаграммы.

Рис. 1.28. Пример диаграммы декомпозиции с каркасом

Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.

Смысл элементов каркаса приведен в табл. 1.2 и 1.3.

Таблица 1.2. Поля заголовка каркаса (слева направо)

Таблица 1.3. Поля подвала каркаса (слева направо)

Значения полей каркаса задаются в диалоге Diagram Properties (меню Edit/Diagram Properties) - рис. 1.29.

Рис. 1.29. Диалог Diagram Properties

 

1.2.7. Слияние и расщепление моделей

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

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

Обе сливаемые модели должны быть открыты в Bpwin.

Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели (рис. 1.30).

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

Имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать (рис. 1.30).

Модель-источник должна иметь по крайней мере одну диаграмму декомпозиции.

Рис. 1.30. Условия слияния моделей

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

Рис. 1.31. Стрелка вызова работы "Сборка изделия" модели-цели

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

Рис. 1.32. Диалог Continue with merge?

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

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

Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова, причем ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.

Рис. 1.33. Вид моделей в Model Explorer после слияния. Выделены модель-источник, и присоединенная ветвь модели-цели

 

1.2.8. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пресекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил BPwin поддерживает автоматически, выполнение других следует обеспечить вручную.

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

Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.

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

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

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

Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwip не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую, ветвь обратно ко входу работы-источника и, наконец, удалить старую ветвь стрелки выхода (рис. 1.34).

Рис. 1.34. Пример обратной циклической связи

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

Рис. 1.35. Минимизация пересечений и поворотов стрелок

Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм (рис. 1.36).

Рис. 1.36. Пример правильного (справа) и неправильного (слева) расположения работ при изображении связи по входу

 

1.2.9. Проведение экспертизы

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

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

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

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

Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы в разделе Notes зачеркнуть цифру, соответствующую номеру замечания (рис. 1.37).

Рис. 1.37. Внесение замечаний в диаграмму

После рецензирования папки возвращаются библиотекарю. Библиотекарь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору.

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

Если это необходимо, проводится дополнительная экспертиза у того же или у другого эксперта.

После прохождения нескольких циклов число замечаний обычно уменьшается и диаграмма становится стабильной. В процессе изменения диаграмма может менять свой статус, который должен быть отражен в каркасе (см. табл. 1.2). Когда автор считает, что диаграмма уже достаточно проработана и достигла уровня "Recommended", он пересылает ее на утверждение в комитет технического контроля, где она проходит окончательную экспертизу. После внесения замечаний и окончательных изменений диаграмма (или набор диаграмм) окончательно утверждается, получает статус "Publication" и может быть распечатана и распространена среди участников проекта.

 

1.5.1. Диаграммы потоков данных (Data Flow Diagramming)

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

функции обработки информации (работы);

документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;

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

таблицы для хранения документов (хранилище данных, data store).

В Bpwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count “кликнуть” по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

– добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;

– добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;

– ссылка на другую страницу. В отличие от IDEF0 инструмент offpage reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

Рис. 1.49. Пример диаграммы DFD

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities) (рис. 1.49).

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

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

Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рис. 1.50).

Рис. 1.50. Внешняя сущность

Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 1.51).

Рис. 1.51. Хранилище данных

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

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

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

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

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

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

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

Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта -это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

 

1.5.2. Метод описания процессов IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

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

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style:

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

Отношения (Relational Link)

- пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

Потоки объектов (Object Flow)

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

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

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

Рис. 1.52. Временная диаграмма выполнения работ

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка - (добавить в диа-1рамму перекресток -Junction) в палитре инструментов. В диалоге Junction Type Editor необходимо указать тип перекрестка.

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

Таблица 1.4. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.53). Для внесения объекта ссылки служит кнопка

-(добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Рис. 1.53. Объект ссылки

При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки. Типы объектов ссылок приведены в табл. 1.5.

Таблица 1.5. Типы объектов ссылок

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.54).

Рис. 1.54. Номер единицы работы (VOW)

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

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

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

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

Таблица 1.6. Диапазоны номеров работ

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

Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия (рис. 1.55). Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEF0 изображаются зеленым цветом, IDEF3 - желтым, DFD - синим.

Рис. 1.55. Представление смешанной модели в окне Model Explorer

 

1.5.3. Имитационное моделирование

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

Рис. 1.56. Пример имитационной модели

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

Рис. 1.57. Фрагмент диаграммы IDEF3, соответствующий имитационной модели с рис. 1.56

Имитационная модель включает следующие основные элементы:

Источники и цели (Bourses и Destinations). Источники - это элементы, от которых в модель поступает информация или объекты. По смыслу они близки к понятиям "внешняя ссылка" на DFD-диаграМмах или "объект ссылки" на диаграммах IDEF3. Скорость поступления данных или объектов от источника обычно задается статистической функцией. Цель - это устройство для приема информации или объектов.

Очереди (Queues). Понятие очереди близко к понятию хранилища данных на DFD-диаграммах - это место, где объекты ожидают обработки. Времена обработки объектов (производительность) в разных работах могут быть разными (например, "Загрузка из бункера", "Наполнение", "Закупорка", см. рис. 1.56, 1.57). В результате перед некоторыми работами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь может быть похожа на стек - пришедшие последними в очередь объекты первыми отправляются на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может быть последовательная обработка, когда первыми на дальнейшую обработку отправляются объекты, пришедшие первыми (FIFO: first -in-first-out). Могут быть заданы и более сложные алгоритмы обработки очереди.

Оборудование (Facilities). Оборудование - это аналог работ в модели процессов. В имитационной модели может быть задана производительность оборудования.

BPwin не имеет собственных инструментов, позволяющих создавать имитационные модели, однако можно экспортировать модель IDEF3 в специализированное средство создания таких моделей - BPSimulator 3.0 (производитель - Systems Modeling Corporation, http://www.sm.com).

Для экспорта модели в BPSimulator необходимо настроить ODBC-источник и подготовить модель к экспорту. Для подготовки модели необходимо настроить свойства, определяемые пользователем UDP, специально включенные в BPwin для целей экспорта. Соответствующие UDP описаны в файле sinudps.bpl, который находится в директории samples/bpsim и является шаблоном модели, предназначенной для экспорта. Для использования этих свойств необходимо слить словари модели - шаблона sinudps.bpl и текущей модели. Задание соответствующих UDP (диалог IDEF3 Activity Properties, закладка UDP Values, см. рис. 1.58) позволяет автоматически установить значения и свойства объектов имитационной модели в BPSimulator.

Рис. 1.58. Диалог задания свойств, определяемых пользователем для экспорта в BPSimulator

Для экспорта модели IDEF3 в BPSimulator следует выбрать меню File/Export/в BPSimulator. Экспорт осуществляется через файл MS Excel (.xls). Для импорта данных в BPSimulator необходимо открыть новую модель и импортировать соответствующий файл.

 

2.1.1. Физическая и логическая модель данных

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

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать. Процессы прямого и обратного проектирования будут рассмотрены ниже.

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

Рис. 2.1. Переключение между логической и физической моделью

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

 

2.1.2. Интерфейс ERwin. Уровни отображения модели

Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен. В дальнейшем будет описан интерфейс версии Erwin 3.5.2. Рассмотрим кратко основные функции ERwin по отображению модели, а также панель и палитру инструментов. Более подробно элементы интерфейса будут рассмотрены в последующих главах. Элементы панели инструментов описаны в табл. 2.1.

Таблица 2.1. Основная панель инструментов

Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне (рис. 2.2) палитра инструментов имеет:

1. Слева направо, верхний ряд:

кнопку указателя (режим мыши) - в этом режиме можно установить фокус на каком-либо объекте модели;

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

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

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

2. Слева направо, нижний ряд:

кнопку перенесения атрибутов внутри сущностей и между ними. Атрибуты могут быть перемещены способом drag&drop;

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

Рис. 2.2. Палитра инструментов на логическом уровне

На физическом уровне (рис. 2.3) палитра инструментов имеет:

вместо кнопки категорий (третья справа кнопка в верхнем ряду) кнопку внесения представлений (view);

вместо кнопки связи "многие-ко-многим" (третья справа кнопка в нижнем ряду) кнопку связей представлений.

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях. Методология IE, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности. Переключение между нотациями можно сделать в закладке Methodology диалога Preferences (меню Option/Preferences) (рис. 2.4). В дальнейшем будет использоваться нотация IDEF1X.

Рис. 2.3. Палитра инструментов на физическом уровне

Рис. 2.4. Переключение между нотациями

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

Таблица 2.2. Уровни отображения модели

Установка цвета и шрифта. Установить шрифт и цвет объектов в ERwin можно несколькими способами. Во-первых, для установки цвета и шрифта объекта служит панель инструментов Font and Color Toolbar, которая располагается под основной панелью. Значение каждого элемента приведено в табл. 2.3.

Таблица 2.3. Панель инструментов Font and Color Toolbar

Для редактирования шрифта и цвета конкретного объекта следует, щелкнув правой кнопкой мыши по сущности или связи и выбрав из всплывающего меню пункт Object Font/Color, вызвать диалог Font/Color Editor, в котором определяются имя, описание и комментарии сущности. Диалог Font/Color Editor имеет три закладки, в которых можно выбрать шрифт и установить его размер, стиль и цвет (закладка Text), установить цвет заливки (закладка Fill, только для сущностей) и цвет линий (закладка Entity Outline, только для сущностей).

Имеется возможность изменить шрифт и цвет для всех объектов модели или для какой-либо отдельной категории объектов. Для этого служит диалог All Default Font/Color Editor (пункт меню Option/Default Font/Color). Каждая закладка на диалоге (рис. 2.5) позволяет редактировать шрифт и цвет для определенной категории объектов:

All Fonts - все объекты модели;

Entity Name - имена сущностей и таблиц;

Entity Definition - определение сущностей и таблиц (показываются на уровне определений, см. табл. 2.2);

Relationship - связи, включая имя и обозначение мощности;

Subtype - иерархия категорий, включая дискриминатор категории;

Text Block Text - текстовые блоки;

Page Number - номер страницы при печати диаграммы;

Owned Entity Attributes - атрибуты и колонки, за исключением атрибутов и колонок внешних ключей;

Foreign Key - атрибуты и колонки внешних ключей;

Background Color - цвет фона диаграммы;

Entity Line - линии, которыми прорисовываются сущности и таблицы;

Entity Fill - заливка сущностей и таблиц;

Subtype Fill - заливка символов, обозначающих категории.

Рис. 2.5. Диалог АН Default Font/Color Editor

Иногда при работе Erwin3.X под операционной системой Windows NT в модели "расплываются" надписи - названия сущностей, атрибутов и комментариев. Эта ошибка связана с некорректной настройкой регистров Windows.

Имеется два способа борьбы с расплывающимися надписями при работе с Erwin3.X под NT:

1. При работе использовать заранее подготовленный шаблон. Для этого следует создать новый проект (НЕ ВКЛЮЧАЯ В НЕГО НОВЫЕ СУЩНОСТИ), установить шрифты, работающие корректно при прямом внесении сущностей (подбираются экспериментально), - Option/default font/color/All Fonts/All Objects и сохранить модель как шаблон - File/SaveAs/Files of Type/ERwin Template. При Reverse Engineering в качестве шаблона необходимо выбрать не стандартный шаблон, а вновь созданный.

2. Редактирование регистров NT. В разделе

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/WindowsNT/CurrentWersion/FontMapper

следует установить 204-ю таблицу - DEFAULT 0X000000cc (204).

В разделе

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/WindowsNT/CurrentWersion/FontSubstitutes

следует для всех стандартных шрифтов установить ссылку на 204-ю таблицу, например:

Arial,0 "Arial,204"

 

2.1.3. Подмножества модели и сохраняемые отображения

При создании реальных моделей данных количество сущностей и атрибутов может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели (Subject Area), в которые можно включить тематически общие сущности. В подмножество модели может входить произвольный набор сущностей, связей и текстовых комментариев. Для создания, удаления или редактирования подмножеств модели нужно вызвать диалог Subject Area Editor (меню Edit/Subject Area), в котором указывается имя подмножества и входящие в нее сущности (рис. 2 6) Все изменения, сделанные в любой Subject Area, автоматически отображаются на общей модели. Одна и та же сущность может входить в несколько Subject Area.

Рис. 2.6. Диалог Subject Area Editor

По умолчанию исходная модель получает имя Main Subject Area. При создании нового подмножества следует в диалоге Subject Area Editor указать ее имя и список входящих в него объектов. Для включения сущности в Subject Area нужно выбрать ее в левом списке диалога и щелкнуть по кнопке . Сущность можно переместить в Subject Area вместе со всеми связанными с ней сущностями. Для этого следует воспользоваться кнопкой , причем можно задать уровень взаимосвязи (рис. 2.7) как для сущностей-потомков (Descedants), так и для сущностей-предков (Ancestors).

Рис. 2.7. Диалог задания уровня перемещения сущностей

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

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

Хранимое отображение (Stored Display) - представление подмножества модели, отображающее специфический аспект структуры данных. Одна Subject Area может включать в себя несколько хранимых отображений. В хранимое отображение входят те же самые сущности и связи, что и в Subject Area, но они могут по-разному располагаться на экране, иметь разные уровни (см: табл. 2.2), различный масштаб и цвет объектов или фона.

Для создания хранимого отображения служит диалог Stored Display Editor (меню Edit/Stored Display).

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

При создании Subject Area в нее могут не входить либо родительская, либо дочерняя сущность. По умолчанию связи с сущностями, которые не вошли в Subject Area ("висящие связи"), не показываются. Для отображения таких связей следует включить опцию Show Dangling Relationship в закладке General диалога Stored Display Editor (рис. 2.8).

Хранимое отображение позволяет отобразить линии связей не только ортогональными, но и диагональными. Для представления связей диагональными линиями следует в закладке General выбрать опцию Diagonal (по умолчанию установлена опция Orthogonal).

Рис. 2.8. Диалог Stored Display Editor

Для переключения между хранимыми отображениями служат закладки в нижней части диаграммы (рис. 2.9).

Рис. 2.9. Переключение между хранимыми отображениями

 

2.2.1. Уровни логической модели

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

диаграмма сущность-связь (Entity Relationship Diagram, ERD);

модель данных, основанная на ключах (Key Based model, KB);

полная атрибутивная модель (Fully Attributed model, FA).

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

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

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

 

2.2.2. Сущности м атрибуты

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

Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address.

Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели - переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) "кликнуть" по кнопке сущности на панели инструментов (ERwin Toolbox) , затем "кликнуть" по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности (рис. 2.10).

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В прежних версиях ERwin закладкам Note2 и Note3 соответствовали окна Query и Sample.

Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).

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

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

Рис. 2.10. Диалог Entity Editor

Закладка Note 3 позволяет вводить примеры данных для сущности (в произвольной форме).

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

, в появившемся диалоге ERwin Icon Editor щелкнуть по кнопке Import и выбрать соответствующий файл формата bmp. После выбора иконки она отображается в закладке Icon диалога Entity Editor (рис. 2.11).

Рис. 2.11. Закладка Icon диалога Entity Editor

Использование свойств, определяемых пользователем (UDP), аналогично их использованию в BPwin (см. гл. 1.4). Для определения UDP служит диалог User-Defined Property Editor (вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и внести имя, тип данных, значение по умолчанию и определение.

ERwin поддерживает для UDP шести типов данных:

Date. Дата. Используется формат MM/DD/YY. Для выбора значения даты можно использовать контекстный календарь;

Int. Целое число;

Real. Действительное число;

Text. Строка (ASCII);

List. Список. При задании списка в диалоге User-Defined Property Editor значения следует разделять запятой, значение по умолчанию выделяется символом "~" (рис. 2.12);

Command. Команда - выполняемая строка. На рис. 2.11 свойство Document имеет тип Command.

Рис. 2.12. Диалог User-Defined Property Editor

Значение свойств, определяемых пользователем, задается в закладке UDP диалога Entity Editor. Если присвоить сущности значение свойства Document "D:\MSOffice97\Office\WINWORD.EXE part3.doc" (рис. 2.13), то из закладки можно редактировать документ part3 (кнопка “…” в строке таблицы UDP).

Рис. 2.13. Закладка UDP диалога Entity Editor

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

Рис. 2.14. Диалог Attribute Editor

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

Рис. 2.15. Диалог New Attribute

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

Закладка Definition позволяет записывать определения отдельных атрибутов. Определения атрибутов можно также сгенерировать как часть схемы (CREATE COMMENT on entity_name.attribute_name). Закладка Note позволяет добавлять замечания об одном или нескольких атрибутах сущности, которые не вошли в определения. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User-Defined Property Editor как свойства атрибутов.

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

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

Рис. 2.16. Диалог Erwin Icon Editor

Каждому домену соответствует стандартная иконка, однако можно импортировать и дополнительные изображения. Кнопка “…” справа от списка выбора Icon вызывает диалог ERwin Icon Editor (рис. 2.16), щелкнув по кнопке Import можно добавить в список необходимую иконку.

Рис. 2.17. Отображение сущности на уровне атрибутов с включенной опцией Attribute Icon

Для отображения иконки атрибута следует выбрать в контекстном меню пункт Display Options/Entities и в каскадном меню включить опцию Attribute Icon. Малая иконка будет показана слева от имени атрибута на уровне атрибутов отображения модели. Как видно из рис. 2.17, имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже - неключевые атрибуты.

Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т. е. не содержать множественных значений. Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута Erwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/2, затем Комментарш/3 и т. д.

Рис. 2.18. Диалог Unique Name Option

На практике такое переименование не всегда удобно, поэтому существует возможность отменить эту опцию. В диалоге Unique Name Option (меню Option/Unique Name) (рис. 2.18) можно задать следующие режимы именования атрибутов:

Allow - позволить внесение одинаковых имен;

Rename - переименовывать атрибуты (по умолчанию);

Ask - запрашивать возможные действия каждый раз при внесении одноименных атрибутов. ERwin будет показывать на экране окно-диалог Edit Unique Name каждый раз, когда вводится неуникальное имя сущности или атрибута. В диалоге Edit Unique Name можно ввести другое имя или разрешить дублирование. При этом новое имя не проверяется на уникальность;

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

Каждый атрибут должен быть определен (закладка Definition), при этом следует избегать циклических определений, например когда термин 1 определяется через термин 2, термин 2 - через термин 3, а термин 3 в свою очередь - через термин 1 (рис. 2.19).

Рис. 2.19. Циклическое определение атрибутов

Иногда определение атрибута легче дать через описание области значений. Например, оценка школьника - это число, принимающее значения 2, 3, 4 и 5.

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

При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

 

2.2.3. Связи

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 2.20). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:

Каждый КЛИЕНТ <размещает> ЗАКАЗы;

Каждый ЗАКАЗ <выполняется> СОТРУДНИКом.

Рис. 2.20. Имя связи - Relationship Verb Phrases

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

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

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 2.21). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 2.21 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).

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

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

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

Рис. 2.22. Неидентифицирующая связь

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

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

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

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

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

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

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

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

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

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

Различают четыре типа мощности (рис. 2.24):

общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;

символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

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

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

Рис. 2.23. Диалог Relationship Editor

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

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child так и Child-to-Parent.

Рис. 2.24. Обозначения мощности

Тип связи (идентифицирующая/неидентифицирующая). Для неидентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис. 2.22).

Рис. 2.25. Закладка Rolename/RI Actions диалога Relationship Editor

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

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

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

Рис. 2.26. Имена ролей внешних ключей

В примере, приведенном на рис. 2.26, в сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя "Где работает", которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute (рис. 2.25). Полное имя показывается как функциональное имя и базовое имя, разделенные точкой (см. рис. 2.26).

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

Рис. 2.27. Случай обязательности имен ролей

Другим примером обязательности присвоения имен ролей являются рекурсивные связи (иногда их называют "рыболовный крючок" - fish hook), когда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 2.26 сущность Сотрудник содержит атрибут первичного ключа Табельный номер. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на руководителя сотрудника следует создать рекурсивную связь (на рис. 2.26 связь руководит/подчиняется) и присвоить имя роли ("Руководитель"). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева подчиненности должен быть корень - сотрудник, который никому не подчиняется в рамках данной организации.

Связь руководит/подчиняется на рис. 2.26 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчиненный имеет только одного руководителя (рис. 2.28).

Иерархическая рекурсия Сетевая рекурсия

Рис. 2.28. Подчиненность экземпляров сущности в иерархической и сетевой рекурсии

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

Рис. 2.29. Пример реализации сетевой рекурсии

На рис. 2.29 рассмотрен пример реализации сетевой рекурсии. Структура моделирует родственные отношения между членами семьи любой сложности. Атрибут Тип отношения может принимать значения "отец-сын", "мать-дочь", "дед-внук", "свекровь-невестка", "тесть-зять" и т. д. Поскольку родственное отношение связывает всегда двух людей, от сущности Родственник к. сущности Родственное отношение установлены две идентифицирующие связи с именами ролей "Старший" и "Младший". Каждый член семьи может быть в родственных отношениях с любым другим членом семьи, более того, одну и ту же пару родственников могут связывать разные типы родственных отношений.

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более - только имя роли. На рис. 2.30 изображена структура данных, которая содержит сущность Команда, сущность Игрок, в которой хранится информация об игроках каждой команды, и сущность Гол, содержащая информацию и голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли "В какой команде играет".

Рис. 2.30. Миграция имен ролей

На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).

Правила ссылочной целостности (referential integrity, RI) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генерации схемы БД на основе опций логической модели, задаваемых в закладке Rolename/RI Actions, будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE). На рис. 2.30 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок (для удаления команды сначала нужно удалить всех игроков), либо сразу удалять вместе с командой всех ее игроков. Такие правила удаления называются "ограничение" и "каскад" (Parent RESTRICT и Parent CASCADE, см. рис. 2.25). Заметим, что сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки команды и все голы, которые они забивали. Выполнение команды на удаление одной строки реально может привести к удалению тысячи строк в БД, поэтому использовать правило удаления каскадом следует с осторожностью. В том случае, если установлено правило ограничения удаления, при попытке выполнить удаление команды, в которой есть хотя бы один игрок, сервер реляционной СУБД возвратит ошибку.

На рис. 2.26 установлена необязательная неидентифицирующая связь между сущностями Отдел и Сотрудник. Экземпляр сущности Сотрудник может существовать без ссылки на отдел (атрибут внешнего ключа Где работает. Номер отдела может принимать значение NULL). В этом случае возможно установление правила установки в нуль - SET NULL. При удалении отдела атрибут внешнего ключа сущности Сотрудник - Где работает. Номер отдела примет значение NULL. Это означает, что при удалении отдела сотрудник остается работать в организации не будучи приписан к какому-либо отделу и информация о нем сохраняется.

Возможна установка еще двух правил удаления (если таковые поддерживаются СУБД):

SET DEFAULT - при удалении атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении команды игроки могут быть переведены в другую команду.

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

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

Задать мощность связи между сущностями Команда и Игрок, равную "One or more" - 1 или более (тип Р). Предполагается, что установлена идентифицирующая связь.

Присвоить действие RI-триггера "Parent Insert-CASCADE" для того, чтобы при создании новой строки в таблице Команда автоматически создавалась хотя бы одна строка в дочерней таблице Игрок.

Присвоить связи действие RI-триггера "Parent Delete-CASCADE" для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись.

ERwin автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию (приведены в табл. 2.4), могут быть изменены в редакторе Referential Integrity Default, который вызывается, если щелкнуть по кнопке RI Defaults диалога Target Server (меню Server/Target Server).

Таблица 2.4. Значения RI, присваиваемые в ERwin no умолчанию, а также возможные оежимы для каждого типа связи

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

Рис. 2.31. Связь многие-ко-многим

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

Связь многие-ко-многим должна именоваться двумя фразами - в обе стороны (в примере "принимает/лечится"). Это облегчает чтение диаграммы. Связь на рис. 2.31 следует читать Вран <принимает> Пациент" а , Пациент <лечится> у Врач" а .

При переходе к физическому уровню ERwin автоматически преобразует связь многие-ко-многим, добавляя новую таблицу и устанавливая две новые связи один-ко-многим от старых к новой таблице (рис. 2.32, сверху). При 'этом имя новой таблице присваивается автоматически как “Имя1 Имя2".

Рис. 2.32. Иллюстрация автоматического разрешения связи многие-ко-многим на уровне физической модели

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

Рис. 2.33. Дополнение модели при разрешении связи многие-ко-многим на уровне физической модели

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

 

2.2.4. Типы сущностей и иерархия наследования

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

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

Рис. 2.34. Пример характеристической сущности "Хобби "

Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является Visit на рис. 2.33.

Именующая - частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Примером именующей сущности является Doctor_Patient на рис. 2.32.

Категориальная - дочерняя сущность в иерархии наследования.

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

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

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

Рис. 2.35. Иерархия наследования. Неполная категория

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

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

Рис. 2.36. Иерархия наследования. Полная категория

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

Рис. 2.37. Иерархия наследования. Комбинация полной и неполной категорий

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

установить курсор на кнопке в палитре инструментов и нажать левую кнопку мыши;

щелкнуть сначала по родовому предку, а затем по потомку;

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

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship (рис. 2.38) можно указать атрибут - дискриминатор категории (список Discriminator Attribute Choice) и тип категории - полная/неполная (радиокнопки Complete/Incomplete).

Рис. 2.38. Диалог Subtype Relationship

Рассмотрим возможные стадии построения иерархии наследования. Определение сущностей с общими (по определению) атрибутами. Предположим, в процессе проектирования созданы сущности Постоянный сотрудник и Совместитель (рис. 2.39). Можно заметить, что часть атрибутов у этих сущностей (Фамилия, Имя, Отчество, Дата рождения, Должность) имеет одинаковый смысл.

Рис. 2.39. Сущности с общими по смыслу атрибутами

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

Создание неполной структуры категорий. Создается категориальная связь от новой сущности - родового предка к старым сущностям - потомкам. Новая сущность дополняется атрибутом-дискриминатором категории (Тип) (см. рис. 2.35).

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

Рис. 2.40. Дополнительная сущность с общими по смыслу атрибутами

Общие атрибуты переносятся в родового предка и категория преобразуется в полную (признак полной категории устанавливается в диалоге Subtype Relationship). Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущности - потомки Постоянный сотрудник и Совместитель.

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

 

2.2.5. Ключи

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

Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рис. 2.33). При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме неключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов).

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

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

Рассмотрим кандидатов на первичный ключ сущности Сотрудник (рис. 2.41).

Здесь можно выделить следующие потенциальные ключи:

1. Табельный номер,

2. Номер паспорта;

3. Фамилия + Имя + Отчество.

Рис. 2.41. Определение первичного ключа для сущности "Сотрудник"

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

Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки.

Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.

При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В примере ключи № 1 и 2 предпочтительней ключа № 3.

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

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

Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные - альтернативными ключами. Альтернативный ключ (Alternate Key) - это потенциальный ключ, не ставший первичным. ERwin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс.

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

Создать альтернативные ключи и инверсионные входы можно в закладке Key Group диалога Attribute Editor (рис. 2.42). Если щелкнуть по кнопке !!!, расположенной в правой верхней части закладки, вызывается диалог Key Group Editor (рис. 2.43). В верхней части диалога находится список ключей, в нижней - список атрибутов, доступных для включения в состав ключа (слева), и список ключевых атрибутов. Каждый вновь созданный ключ должен иметь хотя бы один атрибут. Для включения атрибута в состав ключа следует выделить его в левом списке и щелкнуть по кнопке !!!

Рис. 2.42. Закладка Key Group диалога Attribute Editor

Рис. 2.43. Диалог Key Group Editor

Для создания нового ключа следует щелкнуть по кнопке New. Появляется диалог New Key Group (рис. 2.44). Имя нового ключа присваивается автоматически ("Alternate Key N" для альтернативного ключа и "Inversion Entry N" для инверсионного входа, где N - порядковый номер ключа).

Рис. 2.44. Диалог New Key Group

Каждому ключу соответствует индекс, имя которого также присваивается автоматически ("XAKNENTITY" для альтернативного ключа и " XIENENTITY" для инверсионного входа, где N - порядковый номер ключа, ENTITY - имя сущности). Имена ключа и индекса при желании можно изменить вручную.

Рис. 2.45. Сущность "Сотрудник" с отображением ключей

На диаграмме атрибуты альтернативных ключей обозначаются как (AKn.m), где n - порядковый номер ключа, m - порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (AKn.m) ставится после каждого. На рис. 2.45 атрибуты Фамилия, Имя, Отчество и Дата рождения входят в альтернативный ключ № 1 (АК1), Номер паспорта составляет альтернативный ключ № 2 (АК2). Инверсионные входы обозначаются как (IEn.m), где n - порядковый номер входа, m -порядковый номер атрибута. Инверсионный вход IE1 (атрибут Должность) позволяет выбрать всех сотрудников, занимающих одинаковую должность, IE2 (атрибуты Город и Улица) - всех сотрудников, живущих на одной улице, IE3 (атрибут Номер комнаты) - всех сотрудников, работающих в одной комнате, a IE4 (атрибут Дата рождения) - всех сотрудников, родившихся в один день. Если один атрибут входит в состав нескольких ключей, ключи перечисляются в скобках через запятую (атрибут Дата рождения входит в состав АК1 и IE4). По умолчанию номера альтернативных ключей и инверсионных входов рядом с именем атрибута на диаграмме не показываются. Для отображения номера следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Alternate Key Designator (AK).

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связь образует ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени (см. рис. 2.45). Атрибут внешнего ключа Где работает. Номер отдела ("Где работает" - имя роли) является атрибутом первичного ключа (РК) в сущности Отдел.

Зависимая сущность может иметь один и тот же внешний ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибут внешнего ключа в зависимой сущности только один раз. Хотя в закладке Key Group диалога Attribute Editor этот атрибут будет входить в два внешних ключа, на диаграмме он показывается только один раз. Это комбинирование или объединение идентичных атрибутов называется унификацией.

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

Рис. 2.46. Унификация атрибута

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

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

 

2.2.6. Нормализация данных

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

первая нормальная форма (1NF);

вторая нормальная форма (2NF);

третья нормальная форма (3NF);

нормальная форма Бойса - Кодда (усиленная 3NF);

четвертая нормальная форма (4NF);

пятая нормальная форма (5NF).

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

Для углубленного изучения нормализации следует рекомендовать книгу К. Дж. Дейта "Введение в системы баз данных" (Киев;М.:Диалектика, 1998).

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

Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение А в Е связало с ним точно одно значение В в Е, т. е. А однозначно определяет В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

Рис. 2.47. Ненормализованная сущность "Сотрудник"

На рис. 2.47 в сущности Сотрудник значение атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Табельный номер. Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность; если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть.

Рассмотрим нормальные формы.

Первая нормальная форма (1NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. несколько значений для каждого экземпляра. На рис, 2 47 атрибуты Телефон и Хобби являются нарушением первой нормальной формы. Что будет, если у сотрудника несколько рабочих телефонов? Запись значения колонки через разделитель, например "124-56-78, 124-56-79, 124-56-90" или "Аквалангист, мотоциклист, шахматист", приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. д. и т. п. Сущность, приведенная на рис. 2.48, не является решением проблемы. Что будет, если у сотрудника появится четвертый телефон или третье хобби? Эту информацию будет негде хранить.

Рис. 2.48. Еще один пример ненормализованной сущности

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

Для приведения сущности к первой нормальной форме следует:

разделить сложные атрибуты на атомарные,

создать новую сущность,

перенести в нее все "повторяющиеся" атрибуты,

выбрать возможный ключ для нового РК (или создать новый РК).

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

На рис. 2.49 показана сущность Сотрудник, приведенная к первой нормальной форме.

Рис. 2.49. Сущность "Сотрудник", приведенная к первой нормальной форме

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

Рис. 2.50. Сущность "Проект"

Предположим, сущность Проект содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта (рис. 2.50). Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута Табельный номер руководителя, но вовсе не от Наименования проекта. Другими словами, имеется зависимость только от части ключа.

Для приведения сущности ко второй нормальной форме следует:

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

поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность;

установить идентифицирующую связь от прежней сущности к новой (рис. 2.51).

Рис. 2.51. Сущность "Проект", приведенная ко второй нормальной форме

Вторая нормальная форма позволяет избежать следующих аномалий при выполнении операций:

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

Вставка (INSERT). Невозможно ввести данные о сотруднике, если он в данный момент не руководит проектами.

Удаление (DELETE). Если сотрудник временно прекращает руководство проектами, данные о нем теряются.

На рис. 2.51 показана сущность Проект, приведенная ко второй нормальной форме.

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

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

Для приведения сущности ко второй нормальной форме следует:

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

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

установить неидентифицирующую связь от новой сущности к старой (рис. 2.52).

Рис. 2.52. Сущность "Сотрудник", приведенная к третьей нормальной форме

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

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

Вставка (INSERT). Невозможно ввести данные об окладе, соответствующем должности, если в данный момент нет сотрудника, занимающего эту должность.

Удаление (DELETE). В случае удаления из таблицы сотрудника, занимающего уникальную должность, данные об окладе теряются.

Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 2.53 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Рис. 2.53. Иллюстрация четвертой нормальной формы

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

Денормализация. В результате нормализации все взаимосвязи данных становятся правильно определены, исключаются аномалии при оперировании с данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Рассмотрим примеры на рис. 2.47 и 2.52. Для получения полной информации о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице (см. рис. 2.47). После приведения структуры данных к третьей нормальной форме (рис. 2.52) информация о сотруднике содержится уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу БД необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много. раз превосходить время выполнения запроса к одной таблице, другими словами, в приведенном примере общая производительность ИС в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.

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

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

Рис. 2.54. Пример денормализации

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

Заметим, что приведенный пример следует воспринимать исключительно как иллюстрацию, а не как руководство к действию.

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

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

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

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

Таблицы, колонки, домены и индексы можно создавать только на уровне физической модели (опция Physical Only, см. 2.3). Например, на уровне только физической модели может быть создана колонка Оклад таблицы Сотрудник, см. рис. 2.54.

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

 

2.2.7. Домены

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

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

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

Для создания домена в логической модели служит диалог Domain Dictionary Editor, (рис. 2.55). Его можно вызвать из меню Edit/Domain Dictionary по кнопке, расположенной в верхней левой части закладки General диалога Attribute Editor (см. рис. 2.14). Для создания нового домена в диалоге Domain Dictionary Editor следует:

Рис. 2.55. Диалог Domain Dictionary Editor

щелкнуть по кнопке New. Появляется диалог New Domain (рис. 2.56);

выбрать родительский домен из списка Domain Parent. Новый домен можно создать на основе уже созданного пользователем домена либо на основе изначально существующего. По умолчанию ERwin имеет четыре предопределенных домена (String, Number, Blob, Datetime). Новый домен наследует все свойства родительского домена. Эти свойства в дальнейшем можно переопределить;

набрать имя домена в поле Logical Name. Можно также указать имя домена на физическом уровне в поле Physical Name. Если физическое имя не указано, по умолчанию оно принимает значение логического имени;

щелкнуть по кнопке ОК.

В диалоге Domain Dictionary Editor можно связать домен и иконкой, с которой он будет отображаться в списке доменов (Domain Icon), и иконкой, с которой атрибут, определенный на домене, будет отображаться в модели (Icon Inherited by Attribite).

Рис. 2.56. Диалог New Domain

Каждый домен может быть описан в закладке Definition, снабжен комментарием в закладке Note или свойством, определенным пользователем в закладке UDP.

Рис. 2.57. Создание нового атрибута с помощью диалога Independent Attribute Browser

ERwin имеет специальный инструмент, который значительно облегчает создание новых атрибутов в модели, используя описание доменов, -Independent Attribute Browser. Этот диалог вызывается (и скрывается) по горячему ключу CTRL+B. С его помощью можно выбрать в списке домен и по методу drag&drop перенести его в какую-либо сущность. В ней будет создан новый атрибут с именем, которое следует задать в окне Name Inherited by Attribite диалога Domain Dictionary Editor. Если значение поля не задано, по умолчанию принимается имя домена. На рис. 2.57 для домена "Возраст" значение этого поля было "Атрибут Возраст". В дальнейшем в случае необходимости имя атрибута .можно изменить.

Рис. 2.58. Диалог Domain Dictionary Editor на физическом уровне

На физическом уровне диалог Domain Dictionary Editor позволяет редактировать физические свойства домена. На рис. 2.58 показана закладка ORACLE. Имя этой закладки зависит от выбранного сервера БД. На ней можно задать конкретный тип данных, соответствующих домену, правила присвоения NULL-значений, правила валидации (правила проверки допустимых значений) и задания значения по умолчанию. Правила валидации и значения по умолчанию должны быть предварительно описаны и именованы так, как это описано в 2.3.4 (на рис. 2.58 для домена "Возраст" заданы соответственно правило валидации "Проверка_возраста" и значение по умолчанию "Возраст по умолчанию"). Для вызова диалогов редактирования правил валидации и значений по умолчанию служат кнопки “…” справа от соответствующего списка выбора (Valid и Default).

Рассмотрим функции других закладок диалога Domain Dictionary Editor:

General (рис. 2.59). Задание родительского домена (Domain Parent) и имени, присваиваемого колонке при ее создании с помощью Independent Column Browser. С помощью опции Physical Only домен можно определить только на уровне физической модели.

Comment. Внесение комментария к атрибуту.

UDP. Свойства, определяемые пользователем.

Visual Basic - PowerBuilder. Задание специальных свойств домена для кодогенерации клиентского приложения.

Рис. 2.59. Закладка General диалога Domain Dictionary Editor

Домены могут быть использованы при генерации схемы БД для создания типов, определяемых пользователем для тех СУБД, которые поддерживают такие конструкции (DB2, Rdb, Inteibase, SQL Anywhere, SQL Server и SYBASE). Типы, определяемые пользователем, представляют собой синонимы существующих в БД типов, создаваемых для удобства работы с данными.

При выборе соответствующего сервера на закладке General появляется флажок:

Distinct Types - для DB2/CS и DB2/UDB;

Domains - для Rdb и Inteibase;

User Datatypes - для SQL Anywhere, SQL Server и SYBASE.

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

 

2.3.1. Уровни физической модели

Различают два уровня физической модели:

трансформационная модель (Transformation Model);

модель СУБД (DBMS Model).

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам БД лучше представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям к ИС.

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

 

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

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

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

Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Тип данных можно выбрать в раскрывающемся списке Default Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером. Установка правил ссылочной целостности по умолчанию была рассмотрена в 2.2.3.

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

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

Рис. 2.60. Диалог Target Server

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

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

Имена таблиц и колонок по умолчанию будут сгенерированы на основе имен сущностей и атрибутов логической модели. Если в имени сущности или атрибута встречается пробел, он будет заменен на символ "_".

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

Рис. 2.61. Диалог Globally Reset DBMS Property

 

2.3.3. Таблицы, колонки и представления (view)

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

ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы или колонки по умолчанию все пробелы автоматически преобразуются в символы подчеркивания, а длина имени обрезается до максимальной длины, допустимой для выбранной СУБД. Все изменения, сделанные в Table Editor или Column Editor, не отражаются на именах сущностей и атрибутов, поскольку информация на логическом и физическом уровнях в ERwin хранится отдельно.

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

Рис. 2.62. Диалог Table Editor

Окно Name служит для задания имени текущей таблицы. Окно Owner позволяет внести имя владельца таблицы, отличное от имени пользователя, производящего генерацию схемы БД. Окно выбора Physical Only служит для создания объектов только на физическом уровне. Если выбрана опция Generate, при генерации схемы БД будет выполняться команда CREATE TABLE. Кнопка DB Sync служит для немедленной синхронизации модели с системным каталогом БД.

Диалог Table Editor содержит следующие закладки:

Dimensional. Доступна только на уровне моделирования хранилищ данных (Dimensional Modeling) и будет рассмотрена ниже.

Comment. Внесение комментария к таблице.

Volumetrics. Служит для оценки размера БД.

Physical Props. Позволяет задать физические свойства таблицы.

Partitions. Служит для задания значений разделения. Доступна только для Oracle 8.x.

UDP. Задание свойств, определяемых пользователем.

Validation. Задание правил валидации.

Synonym. Задание синонимов таблицы (если сервер таковые поддерживает).

Stored Procedure. Связывание с таблицей хранимых процедур.

Pre & Post Script. Создание скриптов (наборов команд), которые будут выполняться до и после создания таблицы при генерации схемы БД.

PowerBuilder. Задание расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder.

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

По умолчанию ERwin присваивает режимы нулевых значений всем неключевым колонкам, исходя из значений по умолчанию, устанавливаемых в редакторе Target Server. Для колонок первичного ключа и альтернативных ключей .устанавливается режим NOT NULL. Режим NOT NULL не присваивается автоматически инверсионным входам (Inversion Entry).

Рис. 2.63. Диалог Column Editor

Внешне диалог Column Editor напоминает диалог Attribute Editor (см. рис. 2.14). В правой части диалога находятся закладки:

General. Позволяет присвоить колонку определенному домену, создать колонку только на физическом уровне и включить ее в состав первичного ключа.

Закладка, соответствующая выбранной СУБД (на рис. 2.63 и 2.64 -ORACLE). Имя закладки устанавливается автоматически соответствующей выбранной СУБД. Позволяет задать тип данных, опцию NULL, правила валидации и значение по умолчанию. Правила валидации и значение по умолчанию должны быть описаны и именованы предварительно соответственно в диалогах Validation Rule Editor и Default/Initial Eritor. Для вызова этих диалогов служат кнопки !!! справа от соответствующих раскрывающихся списков. Для СУБД Access, AS/400, PROGRESS и Teradata создаются дополнительные закладки для задания свойств.

Рис. 2.64. Закладка СУБД диалога Column Editor

Comment. Служит для внесения комментария к каждой колонке.

UDP. Задание свойств, определяемых пользователем.

Data Source. Доступна только при моделировании хранилищ данных (см. ниже).

Index. Служит для включения колонки в состав индексов.

Visual Basic и PowerBuilder. Задание расширенных атрибутов для генерации кода клиентского приложения.

В левой части диалога содержится упорядоченный список колонок таблицы. Кнопки “ ”, “ ” предназначены для перемещения колонки в списке на позицию вверх и вниз. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления колонки. При помощи кнопки Reset можно переустановить свойства колонки, заданные вручную, на значения по умолчанию. Кнопка DB Sync позволяет запустить процесс синхронизации модели с системным каталогом БД.

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

Рис. 2.65. Диалог Migrate Column Property

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

Представления (view), или, как их иногда называют, временные или производные таблицы, представляют собой объекты БД, данные в которых не хранятся постоянно, как в таблице, а формируются динамически при обращении к представлению. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц. Применение представлений позволяет разработчику БД обеспечить каждому пользователю или группе пользователей свой взгляд на данные, что решает проблемы простоты использования и безопасности данных. ERwin имеет специальные инструменты для создания и редактирования представлений. Палитра инструментов на физическом уровне (см. рис. 2.3) содержит кнопки внесения представлений и установления связей между таблицами и представлениями. Для внесения представления нужно щелкнуть по кнопке в палитре инструментов, затем по свободному месту диаграммы. По умолчанию представление получает номер V_n, где n - уникальный порядковый номер представления. Для установления связи нужно щелкнуть по кнопке затем по родительской таблице и, наконец, по представлению (рис. 2.66). Связи с представлениями и прямоугольники представлений показываются на диаграмме пунктирными линиями.

Рис. 2.66. Создание представления

Для редактирования представления служит диалог View Editor (рис. 2.67). Для его вызова следует щелкнуть правой кнопкой мыши по представлению и выбрать в меню пункт View Editor.

Рис. 2.67. Диалог View Editor

Раскрывающийся список View позволяет выбрать для редактирования любое представление модели. Окно Name служит для редактирования имени, а Owner-владельца представления.

Диалог View Editor имеет следующие закладки:

Select (рис. 2.67). Имеет два списка: в правом отображаются колонки представления, в левом - колонки доступные для включения в представление. Кнопка New Expression позволяет задать выражение в качестве выходного столбца. Например, для представления V_43 на рис. 2.66 в качестве колонок созданы City и выражение с именем "Количество_клиен-тов_в_городе", которое представляет собой агрегативную функцию, подсчитывающую количество строк, Count(*). По умолчанию при создании связи ERwin включает в представление все колонки родительских таблиц.

From. Позволяет выбрать родительские таблицы представления. По умолчанию включаются таблицы, с которыми связано представление. Каждой таблице можно задать синоним (поле Alias), который будет использоваться при создании SQL-команды создания представления.

Where. Закладка содержит три поля - Where, Group By и Having. На основе этой информации Erwin генерирует SQL-команду создания представления, причем на основе содержания этих полей генерируются предложения SQL-запроса. Для представления V_43 в поле Where содержатся значения "Соип1гу='Россия"', Group By - "City", Having - "Count(*)>2". В результате представление будет содержать информацию о количестве клиентов в российских городах, при условии, что количество клиентов в этих городах больше двух.

SQL. Закладка содержит поле, в котором отображается SQL-запрос создания представления и окно выбора User-Defined SQL. По умолчанию опция User-Defined SQL выключена, и SQL-запрос генерируется автоматически на основе информации, занесенной в закладках Select, From и Where. Запрос можно задать вручную, включив эту опцию, но в этом случае список полей и связи представления на диаграмме отображаться не будут. Для представления V_42 на рис. 2.66 SQL-запрос будет выглядеть так:

"CREATE VIEW V_42 (CustomerName, CustomerAddress, City, OrderAmount, OrderDate,

OrderShipDate)AS

SELECT DISTINCT CUSTOMER.CustomerName, CUSTOMER.CustomerAddress, CUSTOMER.City,

ORDER.OrderAmount, ORDER.OrderDate, ORDER.OrderShipDate

FROM CUSTOMER, ORDER",

а для V_43 - так:

"CREATE VIEW V_43 (City, CustomerCount) AS

SELECT CUSTOMER.City, Countf)

FROM CUSTOMER

WHERE Country= Россия'

GROUP BY City

HAVING Count(*)>2"

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

Stored Procedure позволяет связать с представлением хранимые процедуры.

Pre and Post Script позволяет связать с представлением команды, выполняемые до и после генерации представления.

PowerBuflder служит для внесения расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder.

UDP позволяет связать с представлением свойства, определяемые пользователем.

Для редактирования свойств колонок представления служит редактор View Column Editor (рис. 2.68). Для его вызова следует щелкнуть правой кнопкой мыши по представлению и выбрать в меню пункт View Column Editor.

Рис. 2.68. Диалог View Column Editor

Редактор содержит следующие закладки:

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

Select. Так же как в диалоге View Editor (закладка Select, кнопка New Expression), здесь можно создать выражение (в том числе включающее аг-регативные функции) для колонки.

AS/400 или Access. Используются для задания специфических свойств колонок представлений в AS/400 или Access.

Comment содержит комментарий для каждой колонки.

UDP позволяет связать с колонкой свойства, определяемые пользователем.

Data Source. Позволяет связать источник данных с колонкой при проектировании хранилищ данных.

PowerBuilder или Visual Basic. Служит для внесения расширенных атрибутов для генерации кода клиентского приложения на PowerBuilder или Visual Basic.

 

2.3.4. Правила валидации и значения по умолчанию

ERwin поддерживает правила валидации для колонок, а также значение, присваеваемое колонкам по умолчанию. Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. Значение по умолчанию - значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию (если выбранная СУБД поддерживает домены).

Если щелкнуть по кнопке “…”, расположенной справа от раскрывающегося списка Valid (см. рис. 2.64), появляется диалог Validation Rule Editor (рис. 2.69), который служит для задания правил валидации. В нем можно задать максимальное и минимальное значение и тип валидации (где проверять - на сервере или в клиентском приложении).

Например, в таблице CUSTOMER значение, вводимое в колонку. Age, должно быть больше 18, но меньше 180. Для описания этого правила можно создать правило валидации с именем "Проверка_возраста", которое содержит выражение: Age BETWEEN 18 AND 180. Использование этого правила валидации гарантирует, что диапазон вводимых значений будет от 18 до 180. СУБД выдаст сообщение об ошибке, если вводимый возраст находится вне границ заданного диапазона.

В верхней части редактора Validation Rule содержится список всех существующих правил валидации. Для создания нового правила валидации следует щелкнуть по кнопке New, ввести имя правила в поле Name диалога New Validation и щелкнуть по кнопке ОК. После этого можно ввести выражение для правила валидации. Поля Min и Мах служат для задания нижней и верхней границы диапазона значения.

Рис. 2.69. Диалог Validation Rule Editor

Кнопка Valid Value вызывает редактор Valid Value (рис. 2.70). Редактор Valid Value позволяет создавать список всех допустимых значений, которые можно хранить в колонке, и связать его с правилом валидации. Например если в таблице CUSTOMER имеется колонка Category, то можно задать список допустимых значений для соответствующей колонки, который может содержать значения "Местный", "Иногородний" и "Иностранный".

Раскрывающийся список в верхней части редактора Valid Value содержит все правила, валидации. Чтобы ввести новое значение в список допустимых значений, нужно щелкнуть по кнопке New и ввести значение. Если включить опцию Copy (окно выбора в верхней части редактора), новому правилу будет присвоен список допустимых значений или диапазон, связанный с имеющимся правилом валидации. В нижнем окне диалога Valid Value можно ввести определение для каждого значения. Чтобы изменить имеющееся значение, нужно щелкнуть по кнопке Update. Для удаления значения служит кнопка Delete. Изменить порядок значений в списке можно либо пользуясь методом drag&drop, либо при помощи кнопки Sort. В последнем случае значения будут отсортированы по возрастанию.

При выходе из редактора Valid Value (кнопка OK) ERwin автоматически изменяет правило валидации, используя введенные допустимые значения, например "%AttFieldName IN ('Местный', 'Иногородний', 'Иностранный')".'

Кнопка Set Expr диалога Validation Rule Editor позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений.

По умолчанию ERwin создает выражение - команду языка СУБД, используя значения, связанные с правилом валидации, и разделяя значения запятыми (например, С, D, М). В некоторых случаях правила синтаксиса СУБД требуют, чтобы каждое значение в команде заключалось в одинарные кавычки ('С', 'D', 'М'). Чтобы автоматически заключить каждое значение в одинарные кавычки, нужно включить опцию Quote.

Рис. 2.70. Диалог Valid Value Editor

Диалог Validation Rule Editor содержит также две закладки, в которых отображается текст правил валидации, генерируемый ERwin на сервере и для клиентского приложения (рис. 2.71).

На рис. 2.70 в качестве клиента выбран PowerBuilder. На закладке отображается текст правила валидации Client expression, текст ошибки РВ Error Msg, тип значения РВ Type и кнопка генерации кода клиентской части РВ Sync.

Рис. 2.71. Закладка PowerBuilder диалога Validation Rule Editor

Редактор Default/Initial Editor (рис. 2.72) позволяет создать значение, которое автоматически, по умолчанию, присваивается колонке. Для вызова редактора служит кнопка “…” справа от раскрывающегося списка Default диалога Column Editor (см. рис. 2.64). Например, дате приема сотрудника может быть присвоено значение по умолчанию "сегодняшнее число", т. е. автоматически задается, что все новые сотрудники зачисляются в день ввода информации о них в БД.

Рис. 2.72. Диалог Default/Initial Editor

Для создания нового значения по умолчанию следует щелкнуть по кнопке New, ввести имя правила в поле Name диалога New Default и щелкнуть по кнопке ОК. В окне Default Name показывается список всех имен значений по умолчанию. Колонка Type в этом списке отображает тип значения - присваивать его на клиентской части и/или на сервере. Для удаления и переименования значения служат соответственно кнопки Delete и Rename.

Поля Client и Server служат для внесения значения для клиентской части и сервера.

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

 

2.3.5. Индексы

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

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

Например, если необходимо найти клиента по имени (рис. 2.73), можно создать индекс по колонке CustomerName таблицы CUSTOMER. В индексе имена клиентов будут отсортированы в алфавитном порядке. Для имени индекс будет содержать ссылку, указывающую, в каком месте таблицы хранится эта строка.

Рис. 2.73

Для поиска клиента серверу направляется запрос с критерием поиска (CusfomerName ="Иванов"). При выполнении запроса СУБД просматривает индекс, вместо того чтобы просматривать по порядку все строки таблицы CUSTOMER, Поскольку значения в индексе хранятся в определенном порядке, просматривать нужно гораздо меньший объем данных, что значительно уменьшает время выполнения запроса. Индекс можно создать для всех колонок таблицы, по которым часто производится поиск.

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

При создании индекса на основе ключа ERwin вводит в его состав все колонки ключа. Например, если в сущности CUSTOMER (рис. 2.73) три атрибута назначены как АК1, ERwin автоматически создает индекс и включает в него все три атрибута (CustomerName, Region, City}. Следовательно, на уровне логической модели можно неявно создать индекс, включая колонки в состав альтернативных ключей и инверсионных входов.

ERwin автоматически генерирует имя индекса, созданного на основе ключа по принципу "X" + имя ключа + имя таблицы (физическое имя таблицы, а не логическое имя сущности!), где имя ключа "РК" для первичного ключа, "IFn" - для внешнего, "AKn" - для альтернативного, "IEn" -для инверсионного входа. Например, по умолчанию при создании таблицы CUSTOMER (см. рис. 2.70) будут созданы индексы XPKCUSTOMER (первичный ключ, в состав войдет колонка CustomerID), XAK1CUSTOMER (альтернативный ключ, колонки CusfomerName, Region, City), XIE1CUSTOMER (инверсионный вход 1, колонка Region) и XIE2CUSTOMER (инверсионный вход 2, колонка CustomerAddress).

Изменить характеристики существующего индекса или создать новый можно в редакторе Index Editor (рис. 2.74). Для его вызова следует щелкнуть правой кнопкой мыши по таблице и выбрать во -всплывающем меню пункт Index.

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

Рис. 2.74. Диалог Index Editor

ERwin создает индексы, которые могут содержать либо повторяющиеся, либо только уникальные значения. При создании нового уникального индекса (кнопка NewH, диалог New Index, рис. 2.75) следует включить опцию Unique, для создания индекса с неповторяющимися значениями опцию следует выключить. Если на основе колонки создается уникальный индекс, то при попытке вставить запись с неуникальным (повторяющимся) значением сервер выдаст ошибку и значение не будет вставлено. Например, уникальный индекс в таблице CUSTOMER, построенный на колонке QistomerName, предотвратит от внесения двух строк с информацией об одном и том же клиенте.

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

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

Рис. 2.75. Диалог New Index

По умолчанию ERwin автоматически сохраняет значена . в порядке возрастания (значения сортируются по алфавиту от A до Z, а числа от 0 до 9). Если нужно изменить порядок сортировки для колонки и выбранная СУБД поддерживает режим сортировки по убыванию, следует выбрать колонку и включить опцию DESC (см. рис. 2.74).

Редактор Index Editor содержит следующие закладки:

Members - позволяет включить колонки в состав индекса;

Comment - содержит комментарий для каждого индекса;

UDP - позволяет связать с индексом свойства, определяемые пользователем

закладка, соответствующая выбранной СУБД (на рис 2.76 ORACLE) задает свойства индекса, специфические для выбранной СУБД.

Рис. 2.76. Закладка ORACLE диалога Index Editor

При создании индекса для СУБД ORACLE, SYBASE или SQL Server можно выбирать, в каком объекте физической памяти (создание и редактирование объектов физической памяти рассмотрено в 2.2.6) будет храниться индекс, и изменять параметры хранения. В табл. 2.5 представлены некоторые параметры объектов физической памяти, доступные в закладке, соответствующей выбранной СУБД диалога Index Editor для ORACLE, SYBASE и SQL.

Таблица 2.5. Параметры объектов физической памяти

Некоторые СУБД поддерживают кластеризованные и кластеризованные хешированные индексы. ERwin позволяет создать такие индексы для DB2/MVS, DB2/390, HiRDB, INFORMIX, MS Access, MS SQL Server, SYBASE и SQLBase. Для того чтобы сделать индекс кластеризованным, нужно включить опцию CLUSTER в закладке, соответствующей выбранной СУБД. Кластеризованный индекс - это специальная техника индексирования, при которой данные в таблице физически располагаются в индексированном порядке. Использование кластеризованного индекса значительно ускоряет выполнение запросов по индексированной колонке. Например, можно создать кластеризованный индекс в таблице CUSTOMER по колонке City. Информация о всех клиентах из одного города будет физически располагаться на диске рядом, что значительно повысит скорость выполнения запроса, который делает выборку всех клиентов из какого-то определенного города.

Поскольку данные физически расположены в индексированном порядке, для каждой таблицы может существовать только один кластеризованный индекс. Если СУБД поддерживает использование кластеризованного индекса, то ERwin автоматически создает индекс первичного ключа кластеризованным. При создании кластеризованного индекса не по первичному ключу ERwin автоматически снимает кластеризацию с индекса по первичному ключу. Для СУБД SQLBase (CENTURA) ERwin позволяет создать кластеризованный хешированный индекс (clustered hashed index). Хеширование -альтернативный способ хранения данных в заранее заданном порядке с целью ускорения поиска, но физически это более сложно, чем простое сохранение строк в алфавитном порядке или в соответствии с числовыми значениями.

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

 

2.3.6. Задание объектов физической памяти

ERwin поддерживает объекты физической памяти для нескольких СУБД (табл. 2.6). Все объекты создаются в модели при обратном проектировании однако объекты INFORMIX, SQL Server и SYBASE не создаются при пря-' мом проектировании.

Таблица 2.6. Поддержка ERwin объектов сЬизчческой памяти

Для создания и редактирования объектов физической памяти в ERwin используется редактор Physical Object (меню Server/Physical Object). Вид этого редактора зависит от выбранной СУБД. В качестве примера рассмотрим создание и редактирование объектов физической памяти для ORACLE (рис. 2.77).

Рис. 2.77. Диалог ORACLE Physical Object Editor

Диалог ORACLE Physical Object Editor имеет три закладки:

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

Список TABLESPACE в верхней части закладки показывает все табличные пространства в БД. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления табличных пространств. При нажатии кнопки New возникает диалог New TABLESPACE, в котором следует задать имя табличного пространства. Свойства табличного пространства задаются в диалоге ORACLE Physical Object Editor. Данные в табличных пространствах доступны, когда области находятся в оперативном режиме (online), и недоступны, когда они находятся в автономном режиме (offline). Окно выбора OFFLINE показывает состояние доступности табличного пространства. Для перевода табличного пространства в offline следует включить опцию, в online - выключить.

Окно выбора TEMPORARY позволяет указать, что табличное пространство будет применяться только для хранения временных объектов, например сегментов, используемых при выполнении запросов с сортировкой (предложение ORDER BY). Эта опция доступна только для ORACLE 7.3.

Поля INITIAL и NEXT позволяют задать размер начального и следующего экстента в байтах.

Параметр PCTINCREASE указывает, на сколько процентов этот экстент может быть больше предыдущего по размеру.

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

MAXEXTENTS - максимальное число экстентов, которое можно связать с таблицей, индексом или кластером табличного пространства.

ROLLBACK SEGMENT (сегмент отката). Сегмент отката - это зарезервированный объем пространства, который используется для хранения "снимка" данных в том виде, в котором они находились до выполнения транзакции. Если транзакция не завершилась, все изменения данных откатываются и образ данных, хранящийся в сегменте отката, восстанавливается. Для создания или изменения сегмента отката у пользователя должна быть привилегия CREATE ROLLBACK SEGMENT.

Список ROLLBACK SEGMENT показывает все доступные для редактирования сегменты отката. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления сегментов отката. При нажатии кнопки New возникает диалог New ROLLBACK SEBMENT, в котором задается имя сегмента отката.

Раскрывающийся список TABLESPACE позволяет связать сегмент отката с табличным пространством.

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

Поля INITIAL и NEXT задают размер начального и следующего экстента в байтах.

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

MINEXTENTS - минимальное число экстентов, которое можно связать с сегментом отката.

MAXEXTENTS - максимальное число экстентов, которое можно связать с сегментом отката.

DATABASE Database (база данных). База данных - это зарезервированный объем памяти для одного или более устройств хранения, которые используются для хранения данных и определений объектов БД, например таблиц и индексов. Для создания БД у пользователя должна быть привилегия DBA.

Список DATABASE в верхней части закладки показывает все БД сервера. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления БД. При нажатии кнопки New возникает диалог New DATABASE, в котором следует задать имя БД. Свойства БД задаются в диалоге ORACLE Physical Object Editor.

Список LOGFILE показывает имена всех log-файлов (журналов регистрации) в БД. Справа от списка находятся поля для ввода параметров log-файлов:

MAXLOGFILES - максимальное число log-файлов, которые можно создать для БД (допустимый диапазон значений 2-56).

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

MAXLOGMEMS - максимальное число членов в каждой log-группе (поддерживается Oracle? и более поздними версиями).

Список DATAFILE показывает имена всех файлов данных в БД. Поле MAXDATAFILES позволяет задать максимальное количество файлов в БД.

Поле выбора CONTROL FILE REUSE служит для задания статуса повторного использования управляющего файла. Включенная опция позволяет Oracle переписать информацию в управляющих файлах, определенных в параметре INIT.ORA CONTROL_FILES. Выключенная опция запрещает Oracle повторно использовать управляющие файлы.

ARCHIVE LOG - состояние автоматического архивирования. Разрешает автоматическое архивирование информации log, используемой при восстановлении.

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

MAXINSTANCES - максимальное число экземпляров, для которых одновременно может быть установлена БД (допустимый диапазон значений 1-255).

CHARACTER SET - набор символов, используемый БД. Все данные в колонках типов CHAR, VARCHAR2, LONG хранятся в заданном наборе символов. После того как БД создана, набор символов не может быть изменен.

Кнопка DB Sync позволяет сгенерировать объекты физической памяти в системном каталоге СУБД сразу после их создания в диалоге Physical Object Editor.

 

2.3.7. Триггеры и хранимые процедуры

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

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

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

Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере.

Триггер ссылочной целостности - особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности (RI-триггер) сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной (измененной, удаленной) строки. По умолчанию ERwin генерирует триггеры, дублирующие декларативную ссылочную целостность (см. 2.2.3). Например, если удаляется клиент из таблицы CUSTOMER (см. рис. 2.73), то в зависимости от установленных правил ссылочной целостности могут быть сгенерированы RI-триггеры, которые будут воздействовать на соответствующие удаляемому клиенту заказы из таблицы ORDER. Команда DELETE может быть обработана следующими способами:

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

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

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

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

Шаблоны триггеров ссылочной целостности связываются с сущностями в зависимости от типа связи и роли сущности в этой связи. Тип связи и роль сущности определяют, какое правило ссылочной целостности будет по умолчанию дополнено шаблоном триггера. Связи могут быть: идентифицирующими, неидентифицирующими (nulls allowed), неидентифицирующими (no nulls), связями подтипа.

Сущность в связи может быть родительская (Parent) или дочерняя (Child). Если сущность является родительской в данной связи, то ERwin присваивает ей шаблон триггера для родительской сущности. Если сущность является дочерней в данной связи, то ERwin присваивает ей шаблон триггера для дочерней сущности. Код триггера, который генерируется шаблоном триггера для родительской сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в родительской таблице связи. Код триггера, который генерируется шаблоном триггера для дочерней сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в дочерней таблице связи.

Ниже приведен текст шаблона триггера, соответствующего правилу ссылочной целостности ON PARENT DELETE RESTRICT.

/* ERwin Builtin %Datetime 7

/* %Parent %VerbPhrase %Child ON PARENT DELETE RESTRICT */ select count(*) into numrows

from %Child

where

/* %%JoinFKPK(%Child,:%%Old; ="," and") */

%JoinFKPK(%Child,:%Old," ="," and");

if (numrows > 0) then

raise_application_error(

-20001,

'Cannot DELETE %Parent because %Child exists.'

);

end if;

При генерации схемы СУБД для Oracle 7.2 будет сгенерирован триггер:

create trigger tD_CUSTOMER after DELETE on CUSTOMER for each row

- ERwin Builtin Tue Jan 26 21:55:13 1999

-DELETE trigger on CUSTOMER declare numrows INTEGER;

begin

/* ERwin Builtin Tue Jan 26 21:55:131999 7

/* CUSTOMER размещает ORDER ON PARENT DELETE RESTRICT */

select countf*) into numrows

from ORDER

where

/* %JoinFKPK(ORDER,:%Old," ="," and") */

ORDER.CustomerlD = :old.CustomerlD;

if (numrows > 0)

then

raise_application_error(

-20001,

'Cannot DELETE CUSTOMER because ORDER exists.'

):

end if;

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

ERwin позволяет переопределить триггер, устанавливаемый по умолчанию, тремя способами:

Переопределение типа ссылочной целостности. Для каждой комбинации правил ссылочной целостности (например, Parent-Delete RESTRICT) ERwin позволяет создать переопределенный шаблон и использовать этот шаблон вместо шаблона, применяемого по умолчанию, для всех связей диаграммы, которым был присвоен этот тип правила ссылочной целостности. Используя в качестве основы встроенный код шаблона, можно изменить шаблоны ссылочной целостности во всей модели, изменяя коды триггера только в одном месте. Вновь определяемые шаблоны будут использоваться вместо стандартных шаблонов, если при генерации схемы включена опция RI Type Override.

Переопределение шаблона триггера для связи. Можно переопределить шаблон, задаваемый по умолчанию, для какой-то конкретной связи. Для этого используется диалог Relationship Template Editor, в котором можно описать шаблоны Relationship Override, применяемые вместо стандартных шаблонов (а также вместо шаблонов RI Type Override, если они есть). Шаблоны Relationship Override будут использоваться вместо стандартных шаблонов, если при генерации схемы включена опция Relationship Override.

Переопределение шаблона триггера для сущности. ERwin позволяет создавать собственные триггеры Entity Override для любой сущности в модели. Шаблоны Entity Override используются вместо стандартных шаблонов, а также вместо шаблонов RI Type Override и Relationship Override, если при генерации схемы включена опция Entity Override.

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

Для редактирования триггера следует щелкнуть правой кнопкой мыши по таблице и выбрать во всплывающем меню пункт Trigger. Появляется диалог Table Trigger Viewer, в нижней части которого имеется две кнопки -Table Trigger и Trigger Template, которые вызывают диалоги, предназначенные для создания и редактирования пользовательских триггеров и шаблонов триггеров ссылочной целостности (рис. 2.78).

Рис. 2.78. Диалог Table Trigger Viewer

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

Рис. 2.79. Таблицы CUSTOMER и SECURITY

Для создания триггера служит редактор Table Trigger Editor (вызывается кнопкой Table Trigger диалога Table Trigger Viewer) (рис. 2.80).

Рис. 2.80. Диалог Table Trigger Editor

Раскрывающийся список Table позволяет выбрать таблицу, на которой будет создан триггер. На рис. 2.80 это таблица CUSTOMER.

В списке Trigger отображается имя триггера (SecurWrite). Если имя не задано, ERwin генерирует триггеры ссылочной целостности по умолчанию. Кнопки New, Rename и Delete служат соответственно для внесения нового триггера в список, переименования и удаления триггера из списка.

Группа окон выбора Trigger On позволяет задать тип триггера - при каком событии триггер будет запускаться - при удалении Delete, вставке Insert или обновлении Update-строки таблицы. При выборе любого события ERwin автоматически формирует текст шаблона соответствующего триггера ссылочной целостности. Опции Before и After позволяют задать время выполнения триггера - до или после SQL-команд INSERT, UPDATE или DELETE. В примере на рис. 2.80 создается триггер, выполняемый до команды обновления UPDATE для колонки CustomerName таблицы CUSTOMER.

Опции Table и Row (поддерживается ORACLE 7.x, SQLBase V6, Watcom V4 и AS/400 V3) показывают, каким образом будет выполняться триггер. При генерации в текст триггера будут соответственно включены предложения "FOR EACH TABLE" или "FOR EACH ROW".

Old - ссылка на прежнее значение при обновлении поля, New - ссылка на новое значение при обновлении таблицы. В тексте шаблона триггера используется макрос %RefClause, при генерации текста триггера по шаблону включается предложение REFERENCES. В примере для нового значения установлено имя "newl", для старого - "oldl".

В списке в нижней части диалога показываются имена родительской таблицы (Parent), дочерней таблицы (Child), имя связи (Verb Phrase) и правило ссылочной целостности (Integrity Rule) в случае, если редактируется триггер ссылочной целостности.

В окне Template Code можно ввести код шаблона триггера. Код шаблона триггера, соответствующий бизнес-правилу рассматриваемого примера (создан на основе шаблона триггера ссылочной целостности), приведен ниже:

create trigger %TriggerName

%Fire %Actions(" or")

on %TableName

%RefClause

%Scope

/* ERwin Builtin %Datetime */ /* default body for %TriggerName */ begin

Insert into Security (OldName.NewName, UserUpdate, UpdateDate) values (:old1.CustomerName,:new1,CustomerName, User, Sysdate);

end;

/

В окне Expanded Code отображается код триггера (на языке выбранного сервера, в примере - Oracle 7.2), автоматически генерируемого по шаблону:

create trigger SecurWrite BEFORE UPDATE OF

CustomerName

on CUSTOMER

REFERENCING OLD AS old1 NEW AS new1

for each row

/* ERwin Builtin Tue Jan 26 21:24:371999 7

/* default body for SecurWrite 7

begin

Insert into Security (OldName.NewName, UserUpdate, UpdateDate)

values (:old1.CustomerName,:new1.CustomerName, User, Sysdate);

end;

/

Ниже приведен текст SQL-команд и результат их выполнения (выполнены при помощи Oracle SQVPlus), иллюстрирующих работу триггера.

SQL> insert into CUSTOMER (CustomerlD, CustomerName) values (20/lvanov');

1 row created.

SQL> update CUSTOMER set CuslomerName='Petrov' where CustomerlD=20;

1 row updated.

SQL> select* from SECURITY;

UPDATEDATE OLDNAME NEWNAME USERUPDATE

–––––––––––––––––––––––––––––––––––––––––––––––––––––––

27-JAN-99 Ivanov Petrov SCOTT

Любое изменение имени клиента в таблице CUSTOMER фиксируется в таблице SECURITY, причем регистрируется прежнее значение имени, новое значение, дата изменения и имя пользователя, производившего изменения.

Кнопка Toolbox диалога Table Trigger Editor вызывает редактор ERwin Trigger Toolbox, который значительно облегчает создание текста шаблона триггера (рис. 2.81).

Рис. 2.81. Диалог ERwin Template Toolbox

Template Toolbox содержит три секции: слева расположены списки, содержащие макросы для таблиц, связей, колонок, ограничений и макросы общего назначения. Все макросы начинаются с символа %. Список макросов приведен в приложении. Если выделить макрос в каком-либо списке, в окне Description отобразится синтаксис макроса и пример его использования для связи между таблицами, показанными в правой секции редактора. Таблицы и связи, показываемые в правой части редактора, взяты из примера, содержащегося в файле MOVIES. ER1, который находится в директории Models.

Для включения макроса в текст шаблона достаточно дважды щелкнуть левой клавишей мыши по соответствующему макросу в одном из списков. Макрос включается в текст шаблона в окне Template Code диалога Table Trigger Editor.

Для изменения шаблона триггера ссылочной целостности (переопределение типа ссылочной целостности) служит редактор Trigger Template Editor (рис. 2.82).

Рис. 2.82. Диалог Trigger Template Editor

Для изменения шаблона нужно выделить тип триггера в списке, который находится в верхней части редактора, после чего щелкнуть по кнопке Detach ->, чтобы отсоединить тот шаблон, который связан с выбранным триггером. В списке Built-in Template или User Override нужно выбрать шаблон, который следует связать с выбранным триггером. Выделив имя шаблона, нужно щелкнуть по кнопке Attach над списком. ERwin свяжет выбранный шаблон с триггером и покажет его текст в окне Template Code. Для отмены связывания следует щелкнуть по кнопке <- Rebind. Для создания нового собственного шаблона надо задать его имя в окне Template Name и с помощью Trigger Toolbox (кнопка Trigger Toolbox”) создать текст шаблона триггера. Кнопка Add добавит новый шаблон в список User Override.

Для переопределения шаблона триггера для связи следует правой кнопкой мыши щелкнуть по связи и во всплывающем меню выбрать пункт Relationship Template Editor. Появляется диалог Relationship Template Editor (рис. 2.83). Создание шаблона триггера и связывание его с определенным правилом ссылочной целостности аналогично созданию и связыванию шаблона в диалоге Trigger Template Editor.

Рис. 2.83. Диалог Relationship Template Editor

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

ERwin не имеет встроенных шаблонов хранимых процедур, которые можно было бы использовать как основу при создании новой хранимой процедуры. Для создания или редактирования хранимой процедуры следует щелкнуть правой кнопкой мыши по таблице и выбрать в каскадном меню пункт Table Editor/Stored Procedure. Появляется закладка Stored Procedure диалога Table Editor (рис. 2.84).

Рис. 2.84. Закладка Stored Procedure диалога Table Editor

Список Attached SP Template содержит имена процедур, связанных с редактируемой таблицей. Список Unattached SP Template содержит имена процедур, которые могут быть связаны с таблицей. Кнопки <-Attach и Detach-> служат для связывания и открепления процедуры от таблицы.

Кнопка SP Template вызывает диалог, в котором можно просмотреть и отредактировать код процедуры, включающий SQL-команды и макросы ERwin, Код процедуры показывается в окне SP Expansion, код шаблона - в окне SP Template. На рис. 2.84 в окне SP Template показан код шаблона процедуры с одним возвращаемым параметром, содержащим количество строк текущей таблицы (синтаксис Oracle 7.2).

В окне SP Template можно непосредственно вводить выражения SQL (при условии соблюдения синтаксиса выбранной СУБД). В редакторе SP Template для внесения в текст шаблона макросов можно воспользоваться редактором ERwin Template Toolbox.

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

Для создания хранимой процедуры на уровне схемы или для связывания хранимой процедуры с моделью нужно выбрать пункт меню Server/Schema Property. Вызывается редактор Schema Properties (рис. 2.85).

Рис. 2.85. Редактор Schema Properties

Редактор Schema Properties позволяет просматривать все хранимые процедуры, а также скрипты "до и после генерации схемы", которые связаны со схемой. Список Attached SP Template содержит имена процедур, связанных с моделью, список Unattached SP Template содержит имена процедур, которые могут быть связаны с моделью. Кнопки <-Attach и Detach-> служат для связывания и открепления процедуры от модели.

Для создания нового шаблона процедуры следует щелкнуть по кнопке Schema SP Template... и в редакторе Stored Procedure Template с помощью ERwin Template Toolbox создать текст процедуры.

Скрипты "до и после генерации". Скриптами "до и после генерации" (pre&post scripts schema-generation) называются скрипты SQL, которые ERwin выполняет до или сразу же после генерации таблиц или схемы в целом (pre&post schema-generation). Например, при прямом проектировании БД из модели ERwin может выполнить скрипт "до генерации схемы", который удаляет старую БД и создает новую до того, как начать генерацию таблиц и индексов.

Скрипты уровня таблиц могут быть созданы в закладке Pre&Post Script диалога Table Editor.

Скрипты уровня схемы связаны с моделью так же, как и хранимые процедуры. Скрипты уровня схемы определяются в закладке Pre&Post Script редактора Schema Properties (рис. 2.86). Создание скриптов аналогично созданию хранимых процедур.

Рис. 2.86. Закладка Pre&Post Script диалога Schema Properties

Для создания текста скриптов служат редакторы Table Template Editor и Schema Template Editor. Опция Generation Option позволяет задать тип скрипта - будет ли он выполнен до или после генерации таблицы или схемы. При создании текста скрипта так же, как и при создании текста хранимых процедур, может быть использован ERwin Template Toolbox.

 

2.3.8. Проектирование хранилищ данных

Хранилища данных (Data Warehouse) предназначены для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров. Хранилища данных разгружают промышленные БД, и тем самым позволяют пользователям более эффективно и быстро извлекать необходимую информацию. К проектированию хранилищ данных предъявляются следующие требования:

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

Должны быть выделены статические данные, которые модифицируются по расписанию: ежедневно, еженедельно, ежеквартально;

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

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

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

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

Схема "звезда" обычно содержит одну большую таблицу, называемую таблицей факта (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенные с таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней. Схема "звезда" может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности. Консольные таблицы являются родительскими, таблицы размерности - дочерними.

В размерной модели иконка показывает роль таблицы в схеме "звезда":

Прежде чем создать БД со схемой типа звезды, необходимо проанализировать бизнес-правила предметной области с целью выяснения центрального вопроса, ответ на который наиболее важен. Все прочие вопросы должны быть объединены вокруг этого основного вопроса, и моделирование должно начинаться с этого основного вопроса. Данные, необходимые для ответа на этот вопрос, должны быть помещены в центральную таблицу модели - таблицу факта. Например, если необходимо создавать отчеты об общей сумме дохода от продаж за определенный период как по типу товара, так и по продавцам, следует разрабатывать модель так, чтобы каждая запись в таблице факта представляла сумму продаж, осуществленных тем или иным продавцом, с указанием доходов по каждому покупателю и типов проданных товаров (рис. 2.87). В примере таблица факта содержит суммарные данные о продажах (SALE), а таблицы размерности содержат данные о заказчике и заказах (CUSTOMER), продуктах (PRODUCT), продавцах (SALESPEOPLE) и периодах времени (TIME).

Рис. 2.87. Схема звезда

Таблица факта является центральной таблицей в схеме "звезда". Она может состоять из миллионов строк и содержать суммирующие или фактические данные, которые могут помочь ответить на требуемые вопросы. Она соединяет данные, которые хранились бы во многих таблицах традиционных реляционных БД. Таблица факта и таблицы размерности связаны идентифицирующими связями, при этом первичные ключи таблицы размерности мигрируют в таблицу факта в качестве внешних ключей. В размерной модели направления связей явно не показываются - они определяются типом таблиц. Первичный ключ таблицы факта целиком состоит из первичных ключей всех таблиц размерности. В примере (таблица факта SALE) первичный ключ составлен из четырех внешних ключей: Customer ID, SalespeopleID, TimeID и ProductID.

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

В примере на рис. 2.87 таблица SALE - таблица факта; CUSTOMER, TIME, SALESPEOPLE и PRODUCT - таблицы размерности, которые позволяют быстро извлекать информацию о том, кто и когда сделал покупку, какой продавец и на какую сумму продал и какие именно товары были проданы.

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

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

Если денормализованная таблица размерности получается слишком большой, при этом к части колонок запросы делаются чаще, чем к остальным, целесообразно для повышения эффективности разбить одиночную таблицу размерности на две отдельные таблицы размерности. Две полученные таблицы можно связать неидентифицирующей связью. В примере на рис. 2.87 таблица размерности PRODUCT'содержит как информацию о конкретном товаре, так и информацию о типах товаров. Если запросы, связанные с типами товаров, делаются чаще, чем по отдельным товарам, можно создать новую таблицу PRODUCT_TYPE и перенести в нее информацию о типах (рис. 2.89). В этом случае за счет того, что колонки, к которым наиболее часто обращаются запросы, переносятся в новую таблицу, уменьшается время выполнения запроса.

Рис. 2.89. Нормализация таблиц размерности

ERwin поддерживает методологию размерного моделирования благодаря использованию специальной нотации для физической модели -Dimensional. Наиболее простой способ перейти к нотации Dimensional -при создании новой модели (меню File/New) в диалоге ERwin Teamplate

Selection выбрать из списка предлагаемых шаблонов DIMENSION (рис. 2.90).

В шаблоне DIMENSION сделаны все необходимые для поддержки нотации размерного моделирования настройки, которые, впрочем, можно

установить вручную, преобразовав обычную диаграмму в размерную модель:

Рис. 2.90. Выбор шаблона DIMENSION

Для физического уровня выбрана методология DM (Dimensional Modeling). Эта опция устанавливается в закладке Methodology диалога Preferences (меню Option/Preferences), рис. 2.91. При этом показываются иконки размерности для таблиц. В списке выбора в левой части панели инструментов физический уровень показывается как Dimensional и изменяется вид палитры инструментов на физическом уровне (рис. 2.92).

Рис. 2.91. Выбор нотации DM

Установлена опция отображения связей диагональными линиями (Orthogonal). (Устанавливается в группе Relationship lines закладки General диалога Stored Display Editor, меню Edit/Stored Display.)

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

Рис. 2.92. Палитра инструментов размерной модели

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

таблица факта не является в связи дочерней (рис. 2.93);

консольная таблица не является в связи родительской;

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

Рис. 2.93. Предупреждение о нарушении синтаксиса

Для внесения новой таблицы в модель можно воспользоваться кнопкой в палитре инструментов. В диалоге описания свойств таблицы Table Editor появляется новая закладка Dimensional, в которой задаются специфические свойства таблицы в размерной модели (рис. 2.94):

Роль таблицы в схеме (Dimensional Modeling Role). По умолчанию Erwin автоматически определяет роль таблицы на основании созданных связей (таблица факта, размерности или консольная). Таблица без связей определяется как таблица размерности, таблица факта не может быть родительской в связи, таблица размерности может быть родительской по отношению к таблице факта, консольная таблица может быть родительской по отношению к таблице размерности. Для задания роли таблицы вручную необходимо выключить опцию Calculate Automatically.

Рис. 2.94. Закладка Dimensional диалога Table Editor

Тип таблицы размерности (Dimension Type). Каждая таблица размерности может содержать неизменяемые либо редко изменяемые данные (slowly changing dimensions). Поскольку хранилище данных имеет ненормализованную структуру, редактирование таблиц размерности может привести к коллизиям. Для того чтобы избежать противоречий при хранении данных, ERwin позволяет задать тип редко изменяемых данных, который отличается способом редактирования данных:

Перезаписывание старых данных новыми. При этом старые данные теряются.

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

Запись новых данных в дополнительном поле той же самой записи. В этом случае сохраняется первоначальное и последнее новое значение. Все промежуточные данные теряются.

Правила хранения данных (Data Warehouse Rules). Для каждой таблицы можно задать шесть типов правил манипулирования данными: обновление (Refresh), дополнение (Append), резервное копирование (Backup), восстановление (Recovery), архивирование (Archiving) и очистка (Purge). Для задания правила следуем выбрать имя правила из соответствующего списка выбора. Каждое правило должно быть предварительно описано в диалоге Data Warehouse Rule Editor (меню Edit/Data Warehouse Rule) (рис. 2.95).

Список в верхней части диалога показывает все описанные правила. Для каждого правила должно быть задано имя, тип, определение. Например, определение правила дополнения данных может включать частоту и время дополнения (ежедневно, в конце рабочего дня), продолжительность операции и т. д. Связать правила с определенной таблицей можно не только с помощью диалога Table Editor, но и непосредственно из Data Warehouse Rule Editor (закладка Attachment).

Рис. 2.95. Диалог Data Warehouse Rule Editor

При проектировании хранилища данных важно определить источник данных (для каждой колонки), метод, которым исходные данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище данных. Хранилище данных может объединять информацию из текстовых файлов и многих БД, как реляционных, так и нереляционных, в единую систему поддержки принятия решений. Чтобы поддерживать регулярные обновления и проверки качества данных, необходимо знать источник для каждой колонки в хранилище данных. Для документирования информации об источниках данных используется редактор Data Warehouse Source Editor (рис. 2.96).

Рис. 2.96. Диалог Data Warehouse Source Editor

Внести новый источник можно щелкнув по кнопке WS в списке источников. Имена таблиц и колонок источников данных могут быть импортированы как из БД, так и из других моделей ERwin (закладка Detail, кнопка Import). Каждому источнику может быть задано имя и определение.

В закладке Data Source редактора Column Editor (рис. 2.97) можно внести информацию об использовании источников данных для каждой колонки в таблице. В поле Transform Comment вносится дополнительная информация о переносе данных из источника в хранилище данных.

Рис. 2.97. Диалог Column Editor

Для выбора источника данных следует щелкнуть по кнопке Д| в правой верхней части закладки Data Source. Появляется диалог Data Warehouse Source Selector (рис. 2.98), в окне Available Sources которого показываются все предварительно описанные источники. Для выбора источника следует выбрать в списке необходимую колонку и щелкнуть по кнопке Select.

 

2.3.9. Вычисление размера БД

ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Для расчета размеров физических объектов служит диалог Volumetrics Editor (рис. 2.99), который вызывается из меню Edit/Volumetrics...

Редактор Volumetrics Editor имеет три закладки - Settings, Report и Parameters:

Settings. Служит для задания основных параметров, на основе которых вычисляется размер БД:

В группе Table Row Counts для выделенной в левом списке Table таблицы задается начальное количество строк (Initial), максимальное количество строк (Мах) и прирост количества строк в месяц (Grow By). Если параметры Мах и Grow By используются одновременно, рост размера таблицы прекращается по достижении максимального размера.

Рис. 2.98. Диалог Data Warehouse Source Selector

Те же самые параметры можно задать для каждой таблицы в закладке Volumetrics редактора Table Editor. Сразу после задания параметров Initial, Мах и Grow By в группе Sizing Estimates, расположенной в левом нижнем углу диалога, показывается средний размер строки, начальный размер таблицы и индексов.

Таблица Column Properties позволяет задать свойства колонок таблицы. Имена колонок, их тип и размер (allocated) не редактируются. Можно изменять ширину поля Avg Width (для тех типов данных, для которых это допускается) и параметр Pet NULL (средний ожидаемый процент строк, в которых текущее поле принимает значение NULL). ERwin автоматически определяет в зависимости от выбранной СУБД, какие поля таблицы Column Properties могут изменяться.

Группа Include Indexes позволяет учесть или игнорировать индексы, создаваемые на внешних (FK, Foreign Key), первичных (РК, Primary Key), альтернативных (АК, Alternate Key) ключах или инверсионных входах (IE, Inverse Entry) при расчете размера БД.

Рис. 2.99. Диалог Volumetrics Editor

Группа Storage позволяет задать объект физической памяти, в котором будет храниться выбранная таблица. Если объект физической памяти не описан, его можно определить в редакторе Physical Object Editor (вызывается кнопкой “…”)

Report. В ней отображаются результаты расчета размера БД (рис. 2.100). Группа Options позволяет выбрать тип объектов, по которым проводится расчет, Time - временной диапазон (начальное состояние или определенное время после начала эксплуатации).

Результирующий отчет можно направить в диалог генерации отчетов -Report Browser.

Parameters. Служит для задания дополнительных параметров, используемых для расчета размера БД:

TableFactor. Этот фактор показывает накладные расходы на хранение таблицы в БД. Например, значение TableFactor = 2 увеличит размер таблиц вдвое.

IndexFactor показывает накладные расходы на хранение индекса в БД. Например, значение IndexFactor = 1 увеличит размер индекса с 1 М до 1,5М.

Рис. 2.100. Закладка Report диалога Volumetrics Editor

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

BlobFactor и BlobBlockSize используются для пересчета Blob-колонок, хранящихся физически вне таблицы.

BytesPerChar используется для задания количества байт, необходимых для хранения одного символа строкового типа. Для ASCII - это 1, для других кодировок значение может быть больше 1, например для UNICODE - 2.

LogPercent используется для вычисления размеров log-файлов БД. LogPercent = 100 увеличивает БД вдвое.

 

2.3.10. Прямое и обратное проектирование

Процесс генерации физической схемы БД из логической модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации логической модели из физической БД называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования имеющейся БД. После того как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры БД для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Для генерации системного каталога БД следует выбрать пункт меню Tasks/Forward Engineer/Schema Generation или нажать кнопку на панели инструментов. Появляется диалог Schema Generation (рис. 2.101).

Рис. 2.101. Диалог Schema Generation

Диалог Schema Generation имеет три закладки:

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

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

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

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

Рис. 2.102. Диалог Schema Generation Preview

Кнопка Print предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS или SQL текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера.

Рис. 2.103. Диалог связи с БД

Кнопка Generate запускает процесс генерации схемы. Возникает диалог связи с БД (рис. 2.103), устанавливается сеанс связи с сервером и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema (рис. 2.104).

Рис. 2.104. Диалог Generate Database Schema

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure. Это означает, что при первой же ошибке выполнение скрипта прекращается. Щелкнув по кнопке Continue можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop It Failure скрипт будет выполняться, несмотря на встречающиеся ошибки.

Для выполнения обратного проектирования следует выбрать пункт меню Tasks/Reverse Engineer.

При этом возникает диалог ERwin Template Selection (рис. 2.105), в котором нужно выбрать шаблон диаграммы, затем диалог выбора СУБД и, наконец, диалог задания опций обратного проектирования Reverse Engineer - Set Options (рис. 2.106).

Рис. 2.105. Диалог ERwin Template Selection

В диалоге Reverse Engineer - Set Options можно задать следующие опции:

Группа Reverse Engineer From позволяет задать источник обратного проектирования - БД или SQL(DDL)-CKpHnT. При помощи кнопки Browse можно выбрать текстовый файл, содержащий SQL-скрипт.

Группа Items to Reverse Engineer позволяет задать объекты БД, на основе которых будет создана модель. При помощи списка выбора Option Set, a также кнопок New, Update и Delete можно создавать и редактировать именованные конфигурации объектов БД, которые могут быть использованы многократно при других сеансах обратного проектирования.

Группа Reverse Engineer (доступна только при обратном проектировании из БД) позволяет включить в модель системные объекты (окно выбора System Objects) и установить фильтр на извлекаемые таблицы по их владельцу.

Установка опции Primary Keys в группе Infer означает, что ERwin будет генерировать первичные ключи на основе анализа индексов. Если включена опция Relations, ERwin будет устанавливать связи на основе имен колонок первичного ключа или индексов. Эти опции имеют смысл, только если связи не прописаны явно.

Группа Case Conversion позволяет задать опции конвертации регистра при создании логических и физических имен модели.

Рис. 2.106. Диалог Reverse Engineer - Set Options

Опция Import View Base Tables указывает, что ERwin будет устанавливать связи между представлениями и таблицами. Если опция выключена или SQL-команда создания представления содержит сложные конструкции (например, агрегативные функции), колонки представления импортируются как определяемые пользователем.

После установки необходимых опций можно щелкнуть по кнопке Next, после чего появляется диалог связи с БД (см. рис. 2.103), устанавливается сеанс связи с сервером и начинается процесс обратного проектирования, во время которого показывается статус процесса в диалоге Reverse Engineer-Status. В результате процесса создается новая модель данных.

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

Для синхронизации системного каталога БД и текущей модели следует выбрать пункт меню Tasks/Complete Compare или нажать кнопку на панели инструментов. Возникает диалог Complete Compare - Set Options, который во многом похож на описанный выше диалог Reverse Engineer - Set Options. Разница заключается в том, что в отличие от обратного проектирования сравнивать текущую модель можно не только с БД или SQL-скриптом, но и с другой моделью ERwin, хранящейся в файле или репози-тории ModelMart.

После нажатия на кнопку Next диалога Complete Compare - Set Options возникает диалог связи с БД (см. рис. 2.103), устанавливается сеанс связи с сервером и в диалоге Complete Compare - Resolve Differences показывается текущее состояние модели (слева) и системного каталога СУБД (справа) (рис. 2.107).

Рис. 2.107. Диалог Complete Compare - Resolve Differences

В правой части диалога находятся кнопки, позволяющие задать режим синхронизации для каждого объекта модели или БД:

– экспорт объекта из модели в БД;

– импорт объекта из БД в модель;

– игнорирование различия между моделью и БД (по умолчанию принимается для всех объектов);

– удаление объекта из БД.

Кнопки Match и UnMatch позволяют связать объекты модели и БД, имеющие разные имена. Например, в модели ERwin таблице CUSTOMER соответствует таблица CUST в БД. По умолчанию ERwin определяет, что это разные объекты, хотя по смыслу это одно и то же. Для того чтобы ERwin правильно провел синхронизацию, необходимо вручную связать эти две таблицы. Для связывания таблиц необходимо щелкнуть по кнопке Match, затем по таблице модели (левый список) и, наконец, по таблице БД (правый список). Кнопка UnMatch служит для отмены связывания таблиц.

Линейка индикаторов между списками показывает установленную опцию синхронизации объектов.

Кнопка Report, позволяет сгенерировать отчет о синхронизации, кнопка Preview вызывает диалог Preview SQL Commands, в котором показывается SQL-скрипт, выполняемый для проведения синхронизации.

После щелчка по кнопке Next возникает диалог Complete Compare -Import Changes, в котором можно задать дополнительные опции синхронизации, касающиеся модификации модели (рис. 2.108).

Группа Case Conversion of Logical Names позволяет задать регистр имен создаваемых в модели объектов.

Группа If Table to Import Exists in Model позволяет задать опции генерации схемы в случае, если таблица уже существует в модели. Может быть использована существующая таблица (Use Existing Table) либо создана дублирующая (Create Duplicate Table).

Опции Primary Keys, Relations и Import Base Tables имеют то же назначение, что и соответствующие опции диалога Reverse Engineer - Set Options (см. выше).

Рис. 2.108. Диалог Complete Compare - Import Changes

Кнопка Start Import служит для запуска процесса импорта объектов в модель из БД, SQL(DDL)-скрипт, диаграммы из репозитория ModelMart или файла ER1/ERX. В процессе импорта ERwin показывает сообщения об успешном или неуспешном завершении выполнения импорта для каждого объекта.

 

2.4.1. Расширенные атрибуты

ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения (в том числе визуальных), которые будут отображать информацию, хранящуюся в соответствующей колонке. Эта информация записывается в файле модели. На основе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код может быть немедленно откомпилирован и выполнен без дополнительного ручного кодирования.

Каждой колонке в модели ERwin можно задать предварительно описанные и именованные свойства:

правила валидации (проверки значений);

начальные значения, устанавливаемые по умолчанию;

стиль визуального объекта (например, поле ввода, радиокнопка и т.д.);

формат изображения.

Для описания каждого свойства ERwin содержит соответствующие редакторы. Редакторы Validation Rule Editor для задания правил валидации и редактор Default/Initial Editor для задания начальных значений были описаны в 2.3.4.

Для описания стиля визуального объекта служит диалог Edit Style Editor. Этот диалог различается в зависимости от выбранного клиента. На рис. 2.109 показан вид диалога в случае Power Builder. В левой части диалога располагается группа радиокнопок, соответствующая визуальным объектам, например полю ввода (Edit), окну выбора (Check Box) и др. При щелчке по одной из кнопок в центральной части диалога появляются поля для задания свойств соответствующего объекта.

Радиокнопка Edit mask позволяет задать маску ввода данных, например (@@@)-@@@-@@@@ для номера телефона.

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

Для редактирования форматов служит диалог Display Format Editor (рис. 2.110).

В окне Format Name отображается список всех предварительно созданных форматов. Поле PowerBuilder/Visual Basic Display Format служит для описания маски ввода данных. С помощью комбинированного списка Type можно выбрать тип данных (string, number, date, time или datetime).

Кнопки New, Rename и Delete служат для создания, переименования и удаления формата.

С помощью кнопки РВ Sync (только для PowerBuilder) можно синхронизировать форматы модели ERwin со словарем PowerBuilder.

Рис. 2.110. Диалог Display Format Editor

 

2.4.2. Генерация кода в Visual Basic

ERwin поддерживает генерацию кода для MS Visual Basic версий 4.0 и 5.0. В качестве источника информации при генерации форм служит модель ERwin. Использование ERwin позволяет одновременно описывать как клиентскую часть (объекты, отображающие данные на экране), так и сервер БД (процедуры и триггеры), тем самым оптимально распределяя функциональность ИС между клиентской и серверной частью. Компонент ERwin Form Wizard автоматически проектирует формы с дочерними объектами -кнопками, списками, полями, радиокнопками и т. д., используя расширенные атрибуты.

Совместное использование ERwin и Visual Basic может значительно сократить жизненный цикл разработки ИС, поскольку для каждой задачи используется наиболее эффективный инструмент. Visual Basic может быть использован для проектирования визуального интерфейса, а ERwin - для разработки логической и физической модели данных с последующей генерацией системного каталога сервера. Если БД уже существует, то с помощью ERwin можно провести обратное проектирование (reverse engineering),

полученную модель дополнить расширенными атрибутами и сгенерировать клиентское приложение.

Для генерации клиентской части в диалоге Target Client (меню Client/ Target Client) необходимо выбрать среду программирования - Visual Basic либо Power Builder (рис. 2.111).

Рис. 2.111. Диалог Target Client

Если в качестве клиента выбран Visual Basic, в диалоге Column Editor появляются две закладки для задания расширенных атрибутов (рис. 2.112).

Рис. 2.112. Закладки Visual Basic диалога Column Editor

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

Help ID - поле для контекстного номера объекта, который используется при создании контекстной помощи (HelpContextID).

Опция Read Only должна быть включена, если объект на экранной форме не должен редактироваться.

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

Включенная опция Required указывает, что пользователь обязательно должен внести данные в соответствующее поле. Если данные не будут введены, Visual Basic выдаст предупреждение.

Empty Is Null - опция указывает, что пустое поле будет восприниматься как NULL-значение.

Visible - если опция выключена, Visual Basic создает невидимый объект. Tag - текст комментария к объекту. При генерации кода не используется.

Prompt - текст, который появляется в status bar, если на объекте установлен фокус.

Во второй закладке (на рисунке справа) можно задать шрифт, цвет, метку (Label) и заголовок (Header) объекта. Поле Accel служит для описания комбинации клавиш быстрой установки фокуса на объект.

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

В среде Visual Basic 5.0 необходимо создать новый проект Visual Basic и подключить к нему два внешних файла CONST40.BAS и ERWIN40.BAS, расположенных в каталоге ERwin. Затем следует выбрать в меню Add-Ins/ERwin/Form Wizard. В появляющихся затем диалогах (для перехода к последующему служит кнопка Next, к предыдущему - Back) нужно последовательно указать имя файла модели, родительской и дочерних таблиц (возможно построение формы по родительской и нескольким дочерним таблицам) и колонок, которые будут отображены в сгенерированной форме (рис. 2.113), Затем нужно установить стиль отображения таблиц - свободный (freeform), в виде полей или табличный (grid).

После нажатия на кнопку ОК будет сгенерировано приложение, которое может быть откомпилировано и выполнено без дополнительного редактирования.

Сгенерированная экранная форма (рис. 2.114) помимо элементов отображения информации БД будет содержать управляющие кнопки New, Update, Delete, Close и навигатор для перемещения по строкам. Если полученную форму сделать главной формой проекта, то при запуске приложения возникнет диалог связи с БД. При успешном соединении (через ODBC) будет загружена информация из БД.

 

2.4.3. Генерация кода в Power Builder

В отличие от Visual Basic код приложения для PowerBuilder генерируется непосредственно из среды ERwin. При выборе клиента (в диалоге Target Client, меню Client/Target Client) необходимо указать среду разработки -PowerBuilder, ее версию (4.0, 5.0 или 6.0) и библиотеку Power Builder (поле PBL file), в которой будет размещен сгенерированный код (рис. 2.115). Для работы с PowerBuilder ERwin создает в БД служебные таблицы (словарь PowerBuilder, PB Catalog), в которых хранится информация о расширенных атрибутах. В поле PB Catalog Owner необходимо указать имя пользователя БД - владельца таблиц.

Рис. 2.115. Диалог Target Client - выбор Power Builder

В диалоге Column Editor появляются две закладки Power Builder для задания расширенных атрибутов (рис. 2.116).

Рис. 2.116. Закладки Power Builder диалога Column Editor

В первой закладке (на рисунке слева) комбинированные списки Style, FK Style Valid и Initial служат соответственно для задания колонке предварительно описанных и именованных стиля (FK Style - для задания стиля колонке внешнего ключа), правила валидации и начального значения. Комбинированный список Justify позволяет задать выравнивание текста объекта, Case - возможность отображения текста в разных регистрах (допустимые значения - Any, UPPER и lower). В полях Height и Width можно задать высоту и ширину объекта.

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

В диалоге Table Editor появляется закладка Power Builder (рис. 2.117), где можно задать шрифт для текстовых объектов будущей экранной формы.

Рис. 2.117. Закладка Power Builder диалога Table Editor

Поле PBL File применяется для описания пути к библиотеке PowerBuilder, в которой будет создан объект DataWindow. Кнопка облегчает поиск необходимого PBL-файла. В поле Comment можно внести необходимые примечания, относящиеся к таблице.

Кнопка РВ Sync (на рис. 2.117 не показана) служит для синхронизации модели ERwin и словаря PowerBuilder. Настройка опций синхронизации проводится в диалоге ERwin/PowerBuilder Synchronization (меню Client/PB sync Option).

На основе информации расширенных атрибутов ERwin генерирует в библиотеке PowerBuilder объект DataWindow. Поскольку при генерации используются динамические библиотеки PowerBuilder, в AUTUEXEC.BAT должен быть указан путь к каталогу PowerBuilder.

Для генерации DataWindow может быть использовано два способа: генерация нескольких DataWindow и генерация одного DataWindow по одной таблице. В первом случае следует выбрать пункт меню Client/Create DW. В диалоге DataWindow Wizard (рис. 2.118) нужно таблицы, на основе которых будет проводиться генерация, из левого списка перенести в правый. Для каждой таблицы будет сгенерирован отдельный объект DataWindow.

В группе Presentation Style можно задать стиль отображения DataWindow:

FreeForm - свободный, в виде полей;

Grid - табличный, с разделением линиями;

Tabular - табличный, со специальным разделением.

Имя DataWindow будет состоять из префикса, задаваемого в поле DataWindow Name Prefix, и имени таблицы.

Рис. 2.118. Диалог DataWindow Wizard

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

Created dw_CUSTOMER

Generation Completed -1 DataWindows Created

Во втором случае нужно щелкнуть по кнопке Create DW закладки Power Builder диалога Table Editor (см. рис. 2.117).

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

Рис. 2.119. Вид диалога DataWindow Wizard при генерации DataWindow no одной таблице

 

2.5.1. Интерфейс Report Browser

Для генерации отчетов в ERwin имеется эффективный и простой в использовании инструмент - Report Browser. Он позволяет выполнять предопределенные отчеты (объединенные по типам), сохранять результаты их выполнения, создавать собственные отчеты, печатать и экспортировать их в распространенные форматы. Каждый отчет может быть настроен индивидуально, данные в нем могут быть отсортированы и отфильтрованы.

Диалог Report Browser вызывается кнопкой в панели инструментов ERwin. Его внешний вид показан на рис. 2.120.

Рис. 2.120. Диалог Report Browser

Диалог Report Browser имеет собственное меню и панель инструментов. Назначение кнопок панели инструментов показано в табл. 2.7.

Таблица 2.7. Кнопки панети инструментов Report browser

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

- папка;

- отчет;

- редактируемый отчет;

- результирующий набор данных;

- представление.

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

Иконка результирующего набора будет также добавлена в дерево отчетов.

В левом нижнем окне Report Browser отображается комментарий к отчету (вносится в диалоге ERwin Report Editor, см. ниже).

В нижней части диалога содержится дополнительная панель инструментов для управления деревом отчетов (табл. 2.8).

Таблица 2.8. Кнопки нижней панели инструментов Report Browser

 

2.5.2 Создание нового отчета

Для создания нового отчета следует выбрать пункт меню File/New

ERwin Report или щелкнуть по кнопке на панели инструментов. Появляется диалог ERwin Report Editor (рис. 2.121).

В поле Name следует внести имя отчета. Категория отчета (Category) указывает на тип объектов модели, по которым будет создаваться отчет (атрибуты, сущности, домены, связи и т. д.).

Закладки Definition и Note служат соответственно для внесения определения и комментария к отчету.

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

Кроме списка закладка содержит следующие элементы управления:

группу Options - позволяет выбрать режим отображения элементов в списке - показывать все возможные или только выбранные;

Collapse All - сворачивает все папки списка;

Clear All - отменяет все предварительно выбранные опции;

Show Selected - раскрывает папки с выбранными опциями.

После щелчка по кнопке ОК отчет будет добавлен в список отчетов диалога Report Browser. Для выполнения отчета нужно либо дважды щелкнуть по его имени в списке, либо щелкнуть по кнопке в палитре инструментов.

Рис. 2.121. Диалог ERwin Report Editor

Существующий отчет, в том числе предопределенный, тоже можно изменить с помощью редактора, если в списке щелкнуть правой кнопкой мыши по имени отчета и выбрать во всплывающем меню пункт Edit ERwin Report.

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

Для редактирования результирующего набора данных следует в списке щелкнуть правой кнопкой мыши по имени набора и выбрать во всплывающем меню пункт Edit report format. В появляющемся диалоге Report Format можно изменить сортировку данных, очередность колонок, сделать колонку невидимой, задать ее стиль.

Для экспорта результирующего набора данных следует в списке щелкнуть правой кнопкой мыши по имени набора и выбрать во всплывающем меню пункт Export result set. Допустимые форматы экспорта:

CSV - текстовый файл;

HTLM;

DDE - экспорт в MS Word или MS Excel;

RPTwin - экспорт в специализированный генератор отчетов.

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

 

2.6.1. Генерация словаря ERwin

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

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

Для создания словаря необходимо сделать следующие шаги:

открыть файл метамодели ERWMETA.ER1 (меню File/Open), который находится в подкаталоге Models основного каталога ERwin;

выбрать Schema в качестве Subject Area;

выбрать СУБД (меню Server/Target Server). ERwin поддерживает генерацию словаря на .DBF-файлах (но при этом сохраняется только одна версия диаграммы) и на всех реляционных СУБД, кроме AS/400, Ingres/OpenIngres, Interbase, Paradox, Rdb и Red Brick;

в меню Tasks выбрать Forward Engineering/Schema Generation;

в диалоге Schema Generation установить опции

DROP TABLE

CREATE TABLE

Table Post-Script

щелкнуть по кнопке Generate.

В результате в БД будут созданы все таблицы словаря ERwin.

 

2.6.2. Использование словаря ERwin

Для сохранения и манипулирования моделями в словаре ERwin используется менеджер словаря - Dictionary Manager (рис. 2.122).

В верхней части словаря находится список Diagram Name, который содержит имена моделей, номер версии, пользователя, дату последнего изменения и количество сущностей. Список отсутствует, если в качестве БД словаря используется Clipper, dBASE или FoxPro.

Кнопки Connect и Disconnect позволяют соответственно установить и закончить сеанс связи с БД.

Рис. 2.122. Диалог Dictionary Manager

Менеджер словаря имеет две ключевые функции: загрузку модели и выгрузку модели из словаря.

Для загрузки модели в словарь необходимо открыть файл модели в ERwin и вызвать менеджер словаря. Автоматически устанавливается сеанс связи с БД (возникает диалог связи с БД, в котором необходимо указать имя и пароль пользователя), затем возникает диалог Dictionary Manager.

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

Рис. 2.123. Диалог Check-in Diagram

Кнопка History менеджера словаря вызывает диалог Version History, который служит для просмотра всех версий модели, сохраненных в словаре. С помощью Version History можно изменить примечания каждой версии, удалить или выгрузить из словаря любую версию модели. Эта возможность отсутствует, если в качестве БД словаря используется Clipper, dBASE или FoxPro.

Для выгрузки модели из словаря следует выбрать требуемую модель в списке менеджера словаря и щелкнуть по кнопке Check-out. Возникает диалог Check-out Diagram. Модель можно выгрузить из словаря в двух режимах - только для чтения и для чтения/записи. Окно выбора Read Only позволяет указать, что модель выгружается только для чтения. Открыть модель может как пользователь БД, который загрузил модель в словарь, так и другой пользователь. Если модель выгружает другой пользователь, по умолчанию устанавливается режим Read Only, однако эту опцию можно переопределить.

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

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

4. Групповая разработка моделей данных и моделей процессов с помощью PLATINUM Model Mart *

4.1. Инсталляция ModelMart *

4.2. Администрирование ModelMart *

4.3. Использование репозотория ModelMart *

 

5.1.1. Создание нового отчета

RPTwin является специализированным генераторам отчетов, который позволяет создавать качественные отчеты по моделям процессов и данных. RPTwin входит в поставку как BPwin, так и ERwin. Функциональность RPTwin позволяет создавать не просто отчеты презентационного качества, что само по себе очень важно. Включение в RPTwin более 40 функций позволяет производить сложную обработку данных, получая при этом результат, который невозможно получить средствами ERwin или BPwin. Например, при оценке функциональной модели BPwin можно использовать средства стоимостного анализа (АВС) и свойства, определяемые пользователем (UDP) (см. гл. 1). По умолчанию общая стоимость процесса вычисляется как сумма стоимостей работ декомпозиции. В отличие от стоимостного анализа BPwin не может производить подсчет суммарного значения свойства UDP. Экспорт отчета по UDP в RPTwin позволяет создать отчет, включающий в себя сложную обработку данных, в том числе подсчет суммирующего значения UDP, среднего значения, максимального значения и т. д. и т. п.

После создания отчета в ERwin или BPwin и выбора RPTwin в качестве формата (Report Format) возникает диалог сохранения данных отчета, где необходимо указать имя файла. Все отчеты RPTwin создаются на основе файла данных отчета, который имеет расширение LWD. Запускается RPTwin и возникает диалог New Report (рис. 5.1). Новый отчет можно создать и непосредственно из среды RPTwin (меню File/New), при создании следует указать имя файла данных отчета (LWD).

Рис. 5.1. Диалог New Report

В диалоге New Report можно выбрать тип создаваемого отчета.

1. Quick Reports - создание простейших отчетов.

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

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

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

2. Guided Reports - при выборе отчета Guided Reports возникает диалог Guided Report (рис. 5.2), в котором, начиная с простого отчета, можно шаг за шагом создать отчет с сортировкой, группировкой и сложным форматированием данных.

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

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

Рис. 5.2. Диалог Guided Report

 

5.1.2. Инструментальная среда RPTwin

После выбора типа отчета в диалоге New Report и задания необходимых опций отчет создается автоматически. Ниже будет описан интерфейс версии 3.02.

В окне RPTwin показывается окно DataSet Columns и шаблон отчета (рис. 5.3).

Рис. 5.3. Шаблон отчета

Шаблон отчета включает несколько секций:

Report Header - печатается единожцы в начале отчета. В примере на рис. 5.3 в этой секции расположены текстовое поле "Отчет по стрелкам" и дата отчета;

Page Header - печатается в верхней части каждой страницы. В примере на рис. 5.3 в этой секции расположены текстовые поля - заголовки колонок;

Group Header - печатается в начале каждой группы. В примере отчет сгруппирован по имени стрелки. Секция Group Header содержит текстовое поле Arrow Name и поле данных - имя стрелки (Arrow Name);

Detail - печатается для каждой строчки набора данных (файл .LWD). В примере содержит поля набора данных отчета по стрелкам;

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

Page Footer - печатается в нижней части каждой страницы. Может, например, содержать номер страницы;

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

В секциях отчета могут располагаться следующие элементы:

Data Fields - поля, отображающие данные из.Ь\УО-файла;

Text Fields - используются для внесения в отчет поясняющего текста;

Formula Fields - вычисляемые поля;

Special Fields - специальные поля, например время, номер страницы, номер записи и т. д.;

OLE объекты (Object Link and Embedding) - специальные объекты (обычно графические, связываемые с OLE-серверами (PC Paintbrush, MS Excel, MS Word и т. д.).

В верхней части окна RPTwin располагается панель инструментов. Функциональность панели инструментов доступна из основного меню RPTwin и показана в таб.5.1.

Таблица 5.1. Описание элементов управления основной панели инструментов RPTwin

RPTwin имеет также палитру инструментов (ToolBox). Назначение кнопок палитры инструментов приведено в табл. 5.2.

Таблица 5.2. Описание элементов управления палитры инструментов

DataSet Columns (см. рис. 5.3) показывает список полей набора данных из LWD-файла. Эти поля могут быть включены в отчет при помощи техники drag&drop. Список DataSet Columns можно перемещать по рабочему пространству отчета, можно скрыть его или вновь сделать видимым (пункт меню View/DataSet Columns List).

 

5.2.1. Вставка и форматирование объектов отчета

Созданный в диалоге New Report отчет может быть изменен - в него могут быть добавлены новые объекты, свойства существующих объектов могут быть изменены.

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

простое поле данных (Simple Data Field) представляет собой колонку набора данных (фaйл.LWD). В режиме дизайна отображается именем колонки набора данных, например ENTITY NAME или ATTRIBUTE NAME;

специальное поле (Special Function) показывает дату (Date) и время (Time) выполнения отчета, номер страницы (Page Number), номер строки (Record Number) и общее количество строк (Record Count);

формула (Formula) позволяет производить сложные вычисления и обработку данных. (Создание и использование формул будет рассмотрено в гл. 5.3.)

Поля могут быть включены в любую секцию отчета. Простые поля можно включить в отчет просто "перетаскивая" их (drag&drop) из окна DataSet Columns List в соответствующую секцию.

Для включения специального поля можно воспользоваться палитрой инструментов (см. табл. 5.2) или меню Insert/Special Field. Специальное поле должно быть включено в строго определенную секцию отчета. Так, например, номер страницы может быть включен в Page Header или в Page Footer, общее количество строк (Record Count) - в Group Footer, Page Footer или Report Footer.

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

Возникает диалог Data Field Properties (рис. 5.4), в котором можно изменить следующие свойства поля:

имя поля (поле ввода Name);

координаты поля в отчете и его размеры (Position, Height и Width). Изменить координаты поля можно также просто, "перетащив" поле по рабочему пространству отчета, "зацепив" его мышью. Изменить размеры поля можно также непосредственно в рабочем пространстве отчета. Для этого следует щелкнуть по полю. Появятся габаритные указатели поля !!!!!!!!!!!!!!!. "Зацепив" мышью такой указатель, можно увеличить или уменьшить размер поля. Опция Can be squeezed up if no data особенно важна для вертикальных отчетов. Если она включена, то строка, не содержащая данных, не будет печататься. Ширина поля может быть установлена фиксированной (значение Fixed Width в комбинированном списке справа от поля Width), может автоматически устанавливаться по ширине поля данных (Adjust Width to Data) или максимально возможной - до следующего поля справа или правой границы отчета (Expand Right to Margin or Next Item);

Рис. 5.4. Диалог Data Field Properties

расположение длинного поля в несколько строчек (Word Wrap);

рамки поля (Borders);

фон поля (Patterns);

кроме того, можно скрыть поле, если повторяются его значения (опция Suppress группы Repeating Values). Если при включенной опции Suppress включена также опция Redisplay after Group, значение поля печатается один раз в начале каждой группы, даже если оно является повторяющимся. Если включена опция Redisplay after Page, значение поля печатается один раз в начале каждой страницы.

Текстовые поля (Text Field) могут использоваться в отчете для заголовков, подписей и другой поясняющей информации. Они могут содержать буквы, цифры и специальные символы. Для вставки текстового поля можно воспользоваться кнопкой !!! в палитре инструментов или меню Insert/Text Field.

При внесении поля или при его редактировании (для редактирования свойств текстового поля следует щелкнуть правой кнопкой мыши по полю и выбрать во всплывающем меню пункт Text Field Properties) возникает диалог Text Field Properties (рис. 5.5), в котором можно внести текст поля (Text), имя (Name), изменить рамки (Borders), его размеры и расположение на отчете.

Для удаления поля следует щелкнуть по нему левой кнопкой мыши и нажать на клавишу Delete на клавиатуре.

Рис. 5.5. Диалог Text Field Properties

Помимо текстовых или специальных полей в отчет могут быть включены OLE-объекты. Для вставки текстового поля можно воспользоваться кнопкой !!! в палитре инструментов или меню Insert/OLE Object. При внесении OLE-объекта возникает диалог Вставка объекта (Insert Object), рис. 5.6, в котором следует указать либо тип вновь создаваемого объекта, либо имя файла, содержащего объект. Если вставляется существующий объект, он будет добавлен в секцию отчета, если новый - вызовется соответствующее приложение для создания объекта.

Рис. 5.6. Диалог "Вставка объекта'

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

Некоторые OLE-объекты могут быть преобразованы в другой тип. Для преобразования типа объекта следует щелкнуть по нему правой кнопкой мыши и выбрать во всплывающем меню пункт Объект/Преобразовать (Object/Convert). В появившемся диалоге Преобразование (Convert) следует указать новый тип объекта и щелкнуть по кнопке ОК.

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

 

5.2.2. Группировка и сортировка данных отчета

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

Для установления сортировки и группировки следует выбрать пункт меню Layout/Sorting and Grouping. Появляется диалог Sorting/Grouping (рис. 5.7).

Рис. 5. 7. Диалог Sorting/Grouping

В левом списке диалога (DataSet Columns) содержатся имена всех полей набора данных, в правом (Sort/Group On) - список полей, по которым производится сортировка или группировка.

Для установки сортировки по полю необходимо выбрать его в левом списке и щелкнуть по кнопке Add>. Затем следует выбрать опцию Sort Only и установить порядок сортировки - по возрастанию (Ascending) или по убыванию (Descending). Опция Case Sensitive устанавливает режим сортировки - учитывать ли при сортировке регистр данных.

Для установки группировки по полю необходимо выбрать его в левом списке и щелкнуть по кнопке Add>. Затем следует выбрать опцию Group and Sort и установить порядок сортировки. Группы сортируются автоматически - нельзя установить группировку по полю без сортировки. Опции with Header и with Footer (установлены по умолчанию) включают в отчет секции Group Header и Group Footer.

RPTwin позволяет установить сортировку и группировку по вычисляемому значению. Для создания вычисляемого значения следует щелкнуть по кнопке Sort/Group on Calculated Value и в появившемся диалоге Formula Editor набрать текст формулы (например, "LTrim ({Arrow Name})"). Синтаксис формул будет рассмотрен в гл. 5.3. Созданная формула автоматически добавляется в правый список диалога Sorting/Grouping.

 

5.2.3. Изменение файла данных отчета

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

Для этого необходимо выбрать пункт меню Options/Current DataSet. Появляется диалог Current DataSet (рис. 5.8), который содержит два поля ввода - DataSet Currently In Use By This Report и DataSet Linked To This Report. Поле DataSet Currently In Use By This Report показывает файл данных, который используется в отчете. В поле DataSet Linked To This Report показывается файл, который сохраняется вместе с отчетом. Обычно в обоих полях показывается один и тот же файл.

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

Рис. 5.8. Диалог Current DataSet

Если необходимо изменить файл данных для его постоянного использования в дальнейшем, следует указать его имя в нижнем поле и щелкнуть по кнопке Link. Указанный файл данных (*.LWD) будет связан с текущим файлом шаблона отчета (*.LWR). По умолчанию указывается полное имя файла (путь+имя), которое запоминается в шаблоне отчета. Если не указывать путь (кнопка No Path), то шаблон отчета не привязывается к конкретному месту на диске. В этом случае RPTwin сначала ищет файл данных в каталоге по умолчанию (DATASETS), затем в каталоге, в котором содержится файл шаблона отчета, затем в текущем каталоге.

 

5.2.4. Изменение свойств отчета

RPTwin позволяет изменять свойства как уже созданного отчета, так и новых отчетов. Свойства существующего отчета редактируются в диалогах Current Layout и Page Layout. Так, рассматриваемые ниже свойства Show Text Borders, Add Names to New Data Fields, Snap Objects To Grid, Show Grid, Measurement Units, Number Formats и Enable Case Sensitive Sort для уже созданного отчета можно изменить в диалоге Current Layout (меню Options/Current Layout).

Те же самые свойства для вновь создаваемых отчетов редактируются в диалоге Page Layout (рис. 5.9).

Опция Default Data Format позволяет задать форматирование полей отчета по умолчанию. Отдельно задается формат для полей разных типов:

Datetime, Date, Time, Number, Money. Форматирование каждого поля в уже созданном отчете можно изменить в диалоге Data Field Properties (см. рис. 5.4).

По умолчанию RPTwin создает многоколоночный отчет, разбивая его по ширине, в случае необходимости - на несколько страниц. Если включить опцию Fit All Columns on One Page, то колонки будут сжаты так, чтобы уместить отчет по ширине на одной странице.

Рис. 5.9. Диалог Current DaiaSet

В группе Margins устанавливается ширина поля отчета всантиметрах или дюймах (Units).

Если опция Show Text Borders включена, все текстовые поля отчета заключаются в рамки.

При включенной опции Add Names to New Data Fields новые поля вносятся в отчет вместе с текстовым полем - именем колонки в файле данных.

Snap Objects To Grid позволяет жестко связать поля с координатной сеткой.

Show Grid - показывает координатную сетку.

В группе Number Formats задается формат числовых полей - разделители, символ валюты и др.

Опция Enable Case Sensitive Sort позволяет учитывать при сортировке различия в регистре.

 

5.3.1. Создание формул RPTwin

RPTwin позволяет преобразовать в формулу любое поле данных. Для этого в диалоге Data Field Properties (см. рис. 5.4) следует щелкнуть по кнопке Formula Editor. Возникает диалог Formula Editor (рис. 5.10).

Рис.5.10. Диалог Formula Editor

По умолчанию в верхнем поле диалога (Formula:) отображается имя текущего поля данных отчета. В это поле следует внести текст создаваемой формулы. В левом списке диалога DataSet Columns содержится список колонок файла данных отчета, в правом (Functions) - список функций RPTwin. В нижнем списке (Operators) содержится список операторов. Для внесения колонки, функции или оператора в текст формулы следует дважды щелкнуть по соответствующей строчке списка. Группа кнопок Edit облегчает редактирование текста формулы. Текст формулы должен удовлетворять требованиям синтаксиса формул RPTwin. Если формула содержит ошибку, то при закрытии диалога Formula Editor (кнопка OK) возникнет диалог PLATINUM RPTwin с сообщением об ошибке.

Рассмотрим синтаксические правила формул RPTwin.

Имена колонок. Имена колонок не должны начинаться с цифры и не должны содержать специальных символов (пробел, символ оператора и т. д.). Имя колонки в примере на рис. 5.10 содержит пробел, что является ошибкой. Для использования имен колонок, содержащих специальные символы, их следует заключить в фигурные скобки. Имена полей, не содержащие специальных символов, можно использовать без скобок. Имя "Arrow Dest. Type" - неверное, имена "{Arrow Dest. Type}" и "Name" - не содержат ошибки. Если имя колонки содержит пробелы в начале или конце строки, эти пробелы должны быть заключены в фигурные скобки - "{ Name}" (два пробела в начале имени) или "{Name }" (два пробела в конце имени).

Операторы. RPTwin поддерживает три типа операторов:

арифметические: сложение +, вычитание -, умножение *, деление /;

текстовый оператор конкатенации &;

операторы сравнения, использующиеся в предикате конструкции If (<=, <, =, >=,>);

логические операторы (is in, contains, and, or, not, is null, is not null).

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

Оператор конкатенации позволяет сложить значения текстовых полей. При создании формул, оперирующих с текстом, следует учитывать, что строковые константы заключаются в двойные кавычки. Так, если значение поля Arrow Dest. - "Брак", а поля Arrow Name - "Output", то результатом выполнения формулы "{Arrow Dest.}&" "&{ Arrow Name}" будет "Брак Output".

Типы данных. При выполнении действий над данными необходимо соблюдать правила соответствия типов. Если создать формулу ""Arrow" + 1.0", то RPTwin выдаст сообщение об ошибке несоответствия типов - текст не может быть сложен с числом. RPTwin различает пять типов данных:

Number;

Text;

Date;

Time;

Datetime.

Если возвращаемое значение формулы - строка, то в некоторых случаях при несоответствии типов RPTwin не выдает ошибки, а конвертирует операнды в соответствующий тип. Например, выражение "3&5" будет выполнено без ошибки. Число 3 конвертируется в строку "З", 5 - в "5", результатом выполнения формулы будет строка "35".

Если возвращаемое значение имеет тип Time, в качестве операнда можно использовать Datetime. Если возвращаемое значение имеет тип Datetime, в качестве операнда можно использовать Time, при этом в качестве даты используется 1 января 0001 года.

Арифметические операторы могут использоваться только с числами. Если возвращаемое значение - число, автоматически конвертация типов не производится. Для конвертации типов в этом случае следует явно использовать функции конвертации (см. табл. 5.3).

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

 

5.3.2. Функции RPTwin

Функции RPTwin позволяют производить сложные вычисления и обработку данных отчета. Так же как и операторы, функции возвращают значение определенного типа. Для внесения функции в формулу можно дважды щелкнуть по функции в списке Functions диалога Formula Editor.

Агрегативные функции позволяют производить вычисления по нескольким строкам отчета. Некоторые функции (Sum, Avg, Min, Max, Count) выполняются контекстно, т. е. возвращают результат в зависимости от той секции отчета, в которой находятся. Например, если функция Sum(number) находится в секции Group Footer, она возвращает сумму, вычисленную по группе, если в Page Footer - то по странице. Другие агрегативные функции (GroupAvg GroupSum, GroupMin, GroupMax, GroupCount, ReportAvg, ReportCount, ReportMax, ReportMin, ReportSum) возвращают значение независимо от их расположения в отчете. Даже если функция ReportSum (number) находится в секции Group Footer, она возвращает сумму, вычисленную по всему отчету. Агрегативные функции группы, такие, как GroupAvg, вычисляют значения независимо от того, в какой секции текущей группы они расположены. Если такая функция располагается, например, в секции Report Footer, она вычисляет агрегативное значение по всему отчету.

RPTwin является двухпроходным (Two-Pass, другой термин - Look-Ahead) генератором отчетов. Это означает, что отчет выполняется в два этапа. На первом этапе просматриваются все данные и вычисляются значения функций. На втором этапе происходит непосредственно процесс печати или вывода на экран в режиме предварительного просмотра. Поэтому значения агрегативных функций Sum, Avg, Min, Мах, Count будут вычисляться одинаково, независимо от того, расположены ли они в секции Footer или Header.

Полный список функций RPTwin (версии 3.02) приведен в табл. 5.3.

Таблица 5.3. Функции RPTwin

 

5.3.3. Использование формул RPTwin

Рассмотрим построение отчета RPTwin по модели процессов, изображенной на рис. 5.11. Модель описывает процесс изготовления изделия и имеет три уровня декомпозиции. В ней описаны следующие свойства, определяемые пользователем (UDP):

уровень декомпозиции (Integer List, допустимые значения в модели;

потребление электроэнергии, кВт-ч (Real Number);

потребление воды, т (Real Number).

Контекстной работе ("Изготовление изделия") присвоено значение UDP "Уровень декомпозиции", равное 0, работам на диаграмме декомпозиции контекста -1 и работам на диаграммах декомпозиции нижнего уровня -2. Значения свойств "Потребление электроэнергии, кВт-ч" и "Потребление воды, т" присвоены только работам на диаграммах декомпозиции нижнего уровня.

Создание UDP в BPwin и присвоение значений работам подробно описано в 1.4.

Рис. 5.11. Дерево узлов модели процессов

Непосредственно в среде BPwin невозможно оценить количество ресурсов (электроэнергия и вода), необходимых для производства изделия, поскольку невозможно производить арифметические операции с UDP. В отчете Diagram Object Report, фрагмент которого приведен на рис. 5.12, можно получить только список работ с указанием их UDP, но невозможно отфильтровать работы и произвести расчеты суммарных значений необходимых для производства изделия ресурсов.

Рис. 5.12. Отчет по UDP (Diagram Object Report), полученный средствами BPwin

Создать отчет со сложной обработкой данных возможно только средствами- RPTwin. Для создания такого отчета необходимо в диалоге настройки отчета Diagram Object Report (см. рис. 1.48) в качестве формата отчета указать RPTwin, после чего щелкнуть по кнопке Report. В появившемся диалоге сохранения файла следует указать имя файла данных отчета (.LWD). После этого автоматически запускается RPTwin и появляется диалог New Report. В диалоге New Report в качестве типа создаваемого отчета следует указать Columnar. Создается шаблон отчета, включающий в себя все колонки файла набора данных отчета (рис. 5.13).

Рис. 5.13. Шаблон отчета "Ресурсы, необходимые для изготовления изделия "

Фрагмент отчета (режим предварительного просмотра) представлен на рис. 5.14.

Ресурсы, необходимые для изготовления изделия

Рис. 5.14. Отчет "Ресурсы, необходимые для изготовления изделия"

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

Поскольку UDP, определяющие потребление ресурсов, заданы только для работ нижнего уровня декомпозиции, можно оставить в отчете только эти работы. Для установки фильтра в среде RPTwin нужно выбрать пункт меню Options/Filter. В диалоге Filter (рис. 5.15) следует выбрать опцию Include и щелкнуть по кнопке Formula Editor.

Рис. 5.15. Диалог Filter

В диалоге Formula Editor нужно создать формулу

{Уровень декомпозиции}=2

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

Теперь можно удалить из отчета поле и заголовок "Уровень декомпозиции".

Сгруппируем работы по уровню энергопотребления. Для этого следует выбрать пункт меню Layout/Sorting and Grouping. Будем считать, что работы, имеющие значение UDP "Потребление электроэнергии, кВт-ч" больше 10, относятся к высокому уровню энергопотребления, от 5 до 10 - к среднему и менее 5 - к низкому. В файле данных отчета нет колонки, непосредственно указывающей на уровень энергопотребления, поэтому следует провести группировку по вычисляемому значению. Для создания вычисляемого значения в диалоге Sorting/Grouping следует щелкнуть по кнопке Sort/Group on Calculated Value и в появившемся диалоге Formula Editor набрать текст формулы:

If {Потребление электроэнергии, кВт-ч} >10 Then "Высокие энергозатраты" Else If {Потребление электроэнергии, кВт-ч}< 5

Then "Низкие энергозатраты" Else "Средние энергозатраты"

В шаблоне отчета создаются две новые секции - Group Header и Group Footer.

В секцию Group Header поместим формулу

If {Потребление электроэнергии, квт-ч.) >10 Then "Высокие энергозатраты" Else If {Потребление электроэнергии, квт-ч.} <5 Then "Низкие энергозатраты" Else "Средние энергозатраты"

В секцию Group Footer поместим формулы с агрегативными функциями:

"Итоговое потребление воды работ с " & (If (Потребление электроэнергии, квт-ч.1 >10 Then "высоким" Else If {Потребление электроэнергии, квт-ч.) <5 Then "низким" Else "средним") &" энергопотреблением - " &GroupSum ({Потребление воды, т.})&", т."

и

"Итоговое потребление электроэнергии работе " & (If (Потребление электроэнергии, квт-ч.1 >10 Then "высоким" Else If (Потребление электроэнергии, квт-ч.) <5 Then "низким" Else "средним") & энергопотреблением - " &GroupSum ({Потребление электроэнергии, квт-ч.})&", квт-ч."

В секции Report Footer расположим формулы

"Итоговое потребление электроэнергии " SReportSum ((Потребление электроэнергии, квт-ч.})&", квт-ч."

и

"Итоговое потребление воды " &ReportSum ({Потребление воды, т.})&", т."

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

Рис. 5.16. Итоговый отчет по потреблению ресурсов