Моделирование информационного обеспечения (метод IDEF1) Составитель: Шаповалова С.В.

Оглавление 1. Моделирование информационного обеспечения Моделирование информационного обеспечения 2. Создание модели данных в инструментальном средстве ERwin Создание модели данных в инструментальном средстве ERwin 3. Документирование модели Документирование модели 4. Масштабирование модели Масштабирование модели 5. Интерфейс ERwin. Уровни отображения модели Интерфейс ERwin. Уровни отображения модели 6. Создание логической модели данных Создание логической модели данных 7. Ключи Ключи 8. Нормализация данных Нормализация данных 9. Домен Домен 10. Создание физической модели данных Создание физической модели данных

11. Правила валидации и значения по умолчанию Правила валидации и значения по умолчанию 12. Индексы Индексы 13. Триггеры и хранимые процедуры Триггеры и хранимые процедуры 14. Проектирование хранилищ данных Проектирование хранилищ данных 15. Вычисление размера БДВычисление размера БД 16. Прямое и обратное проектирование Прямое и обратное проектирование 17. Генерация кода клиентской части с помощью ERwin Генерация кода клиентской части с помощью ERwin 18. Генерация кода в Visual Basic Генерация кода в Visual Basic 19. Создание отчетов Создание отчетов 20. Генерация словарей Генерация словарей 21.Литература Литература

Моделирование информационного обеспечения (метод IDEF1) Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI. Метод Баркера основан на нотации, предложенной автором, и используется в case-средстве Oracle Designer. Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе метода IDEFI создана его новая версия метод IDEFIX.

IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF). В методе IDEFIX сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности

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

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

Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью- родителем, то связь называется идентифицирующей, в противном случае неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка. Мощность связей может принимать следующие значения: N ноль, один или более, Z ноль или один, Р один или более. По умолчанию мощность связей принимается равной N.

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

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

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

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

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

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

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

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

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

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

Различают три уровня логической модели, отличающихся по глубине представления информации о данных: –диаграмма сущность-связь (Entity Relationship Diagram, ERD); –модель данных, основанная на ключах (Key Based model, KB); –полная атрибутивная модель (Fully Attributed model, FA).

Преключиться между ними можно кликнув по любому месту диаграммы, не занятому объектами модели и выбрав в появившемся меню пункт Display Level. На уровне атрибутов атрибуты альтернативного ключа помечаются номером (AKm.n), где m - номер ключа, n - номер атрибута в ключе. Инверсионные ключи помечаются номером (IEm.n). В дальнейшем при генерации БД на атрибутах альтернативных ключей могут быть сгенерированы уникальные индексы, на атрибутах инверсионного ключа - неуникальные. Атрибуты первичного ключа отображаются выше горизонтальной линии - прочие атрибуты - ниже

Уровни отображения модели

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

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

Интерфейс ERwin. Уровни отображения модели Интерфейс выполнен в стиле Windows- приложений. Каждому уровню отображения модели соответствует своя палитра инструментов. На логическом уровне палитра инструментов имеет следующие кнопки: –кнопку указателя (режим мыши) в этом режиме можно установить фокус на каком- либо объекте модели; –кнопку внесения сущности;

–кнопку категории (категория, или категориальная связь, специальный тип связи между сущностями, которая будет рассмотрена ниже); –кнопку внесения текстового блока; –кнопку перенесения атрибутов внутри сущностей и между ними; –кнопки создания связей: идентифицирующую, "многие-ко-многим" и неидентифицирующую.

Основная панель инструментов

Панель инструментов на логическом уровне Категория Сущность Режим выделения Связь

На физическом уровне палитра инструментов имеет: –вместо кнопки категорий кнопку внесения представлений (view); –вместо кнопки связи "многие-ко-многим" кнопку связей представлений. Для создания моделей данных в ERwin можно использовать две нотации: IDEFIX и IE (Information Engineering). В дальнейшем будет рассматриваться нотация IDEFIX.

Переключение между нотациями Представление Таблица Выделение Связь Панель инструментов на физическом уровне

Выбор уровней отображения диаграммы

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

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

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

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

Диалог Entities В диалоге Entity Editor определяются имя, описание и комментарии сущности. Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition.

Закладки Note, Note 2, Note 3, UDP служат для внесения дополнительных комментариев и определений к сущности. В закладке Icon каждой сущности можно поставить в соответствие изображение (файл bmp), которое будет отображатся в режиме просмотра модели на уровне иконок.

Каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом (primary key). Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Согласно синтаксису IDEFIX имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его.

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

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

Для атрибутов первичного ключа в закладке Key Group диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key. При определении первичного ключа может быть рассмотрено несколько наборов атрибутов. Такие наборы называются потенциальными ключами (candidate key). Например, если рассматривается сущность "Сотрудник", такими наборами могут быть: –Имя, Фамилия, Отчество, Дата рождения –Номер паспорта –Табельный номер –Отдел

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

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

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

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

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

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

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

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

Мощность связей (Cardinality) – отношение числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа связи: -одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности (не помечается каким-либо символом); -символом Р – когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение); -символом Z – когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); -цифрой – случай точного соответствия (одному экземпляру родительской сущности соответствует заданное число экземпляров дочерней сущности).

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

В появившемся диалоге можно задать: Мощность (cardinality) связи - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Verb Phrase - фраза, характеризующая отношение между родительской и дочерней сущностями. Тип связи (идентифицирующая / не идентифицирующая). Описание связи. Правила ссылочной целостности (будут сгенерированы при генерации схемы БД).

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

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

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

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

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

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

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

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

Для моделирования категорий служит кнопка в палитре инструментов.

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

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

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

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

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

Создание физической модели данных Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели: –трансформационную модель; –модель СУБД.

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

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

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

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

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

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

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

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

Для редактирования шаблонов триггеров используется редактор Trigger Template Editor (для его вызова следует кликнуть правой кнопкой по таблице и выбрать пункт Trigger в появившемся меню). Диалоги Trigger Template Editor и ERwin Template Toolbox

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

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

Для генерации клиентской части во-первых, необходимо выбрать язык программирования (меню Client/ Target Client..., можно выбрать Visual Basic либо Power Builder), затем на физическом уровне для каждой колонки необходимо указать свойства - тип визуального представления (style), код валидации и начальное значение (для задания свойств следует кликнуть по таблице правой кнопкой мыши, в контекстном меню выбрать VB Extended Att). Каждое из этих свойств можно предварительно описать в соответствующем редакторе.

Редактор стиля

После задания свойств для каждой колонки следует сохранить модель. Техника генерации приложения зависит от конкретной среды программирования. Рассмотрим в качестве примера MS Visual Basic 5.0. В среде Visual Basic 5.0 следует выбрать в меню Add- Ins / ERwin / Form Wizard. В диалоге следует указать имя файла модели, таблицы (возможно построение формы по родительской и нескольким дочерним таблицам) и колонки, которые будут отображены в форме. В результате будет сгенерировано приложение, которое может быть откомпилировано и выполнено без дополнительного редактирования.

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

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

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

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

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

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

Для экспорта модели данных из ERwin'а в BPwin необходимо в ERwin'е открыть модель, войти в меню File, выбрать опцию Bpwin / Export, выбрать имя файла *.eax и нажать OK. Появится сообщение «Export Successful». Затем в BPwin'е нужно открыть желаемую модель процесса, выбрать из меню File / Import / Erwin (EAX)..., выбрать имя файла и нажать OK. Появится протокол импорта. Нужно закрыть диалог протокола и в следующем диалоге кликнуть по кнопке Accept Changes. Теперь можно связать сущности и атрибуты со стрелками.

Правой кнопкой нужно кликнуть по стрелке и выбрать в контекстном меню Arrow Data. Появляется диалог Arrow Data Editor.

В нем необходимо указать сущности и атрибут(ы), связанные со стрелкой и кликнуть по кнопке OK, чтобы сохранить изменения. Если в процессе связывания стрелок с объектами модели данных окажется, что каких либо сущностей или атрибутов не хватает, их можно добавить (меню Edit / Entity/Attribute Dictionary), а затем экспортировать в ERwin (в BPwin'е меню File / Export / ERwin(BPX), в ERwin'е меню BPwin / Import). Т.к. работы могут воздействовать на данные. Для документирования такого воздействия необходимо кликнуть правой кнопкой мыши по желаемой работе и выбрать Data Usage Editor.

В появившемся диалоге Data Usage Editor нужно в верхнем списке кликнуть по имени стрелки, с которой были связаны сущности и атрибуты. В нижнем левом окне появится список связанных сущностей. Если выбрать сущность, то, во-первых, в правом окне появится список соответствующих атрибутов, во- вторых, в центре открываются окна выбора CRUD (Create, Retrieve, Update, Delete). Если кликнуть по атрибуту, то значение окон выбора меняется на IRUN (Insert, Retrieve, Update, Nullify).

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

Стрелки выхода могут быть обновлены (если им соответствуют данные стрелок входа) или созданы (Create). Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Report / Data Usage Report). Arrow NameEntity Name C _R _U _D Attribute Name I _R_ U_ N Детали Часть R U D Вес части R U N R U D Количество R U N R U D Название части R U R U D Номер части R

Групповая разработка моделей данных и моделей процессов с помощью Logic Works Model Mart ModelMart является системой групповой разработки крупных проектов, которая интегрирует инструментальные средства системных аналитиков и разработчиков БД. Одной из проблем, возникающей при многопользовательской работе с моделями, является разграничение прав доступа.

Т.к. ModelMart является специализированным хранилищем моделей, помимо разграничения прав доступа на уровне модели возможно регулирование прав на уровне отдельных элементов модели. Для управления правами доступа в состав ModelMart включена утилита ModelMart Security Manager. Для начала работы необходимо установить сеанс связи с ModelMart, нажав кнопку (из дополнительной линейки инструментов ModelMart среды ERWin'а или BPWin'а) и набрать имя и пароль пользователя в появившемся диалоге.

После успешного входа становится доступной кнопка, которая вызывает диалог Security Manager. ModelMart Security Manager - диалог формирования групп пользователей

В окне диалога Security Manager можно задать группу пользователей и права каждой группы (кнопка Profile...) на создание, редактирование и удаление библиотек и моделей. В случае работы с моделями данных в ERWin'е можно также задать права на создание, редактирование и удаление для предметных областей (Subject Area) и сущностей. Нажав на кнопку Users..., можно вызвать диалог внесения новых пользователей ModelMart, которых необходимо предварительно завести как пользователей БД (в примере - Oracle).

Users in ModelMart- диалог внесения новых пользователей

Не все пользователи БД могут быть пользователями ModelMart, но все пользователи ModelMart должны быть пользователями БД. ModelMart Security Profile Manager - диалог задания прав группам пользователей

Затем можно внести пользователей ModelMart в ту или иную группу пользователей ModelMart (пользователь SYSTEM внесен в группу Administrator, пользователь SCOTT- в группу Architect). Если в течение жизненного цикла разработки проекта роль проектировщика меняется, администратор ModelMart может менять права доступа без изменения его прав как пользователя БД, что дает возможность гибкого управления проектами.

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

Для создания новой модели в ModelMart, добавления, открытия и сохранения модели служат кнопки. Создать или сохранить модель можно только в составе какой-либо библиотеки. При открытии модели возникает диалог Open ModelMart Diagramm, в котором можно указать опции блокировки модели.

Открытие модели в режиме Read Only означает, что измененную модель нельзя будет сохранить в репозитории. В режиме Locked модель блокируется и другие пользователи не смогут изменить модель. В режиме Unlocked все пользователи могут открыть и изменить модель. При попытке сохранить модель, измененную и сохраненную другим пользователем во время сеанса работы возникает диалог - Intelligent Conflict Resolution, показывающий различия текущей и имеющейся в репозитории моделей.

Открытую модель можно перевести в режим Locked, нажав кнопку. Кнопка вызывает диалог ModelMart Merge Manager, который служит для слияния моделей. В зависимости от настройки, слияние может быть проведено в одну из существующих, либо во вновь создаваемую диаграмму. Обновление загруженной диаграммы можно осуществить кликнув по кнопке. Список изменений, сделанных в поцессе работы с моделью, показывается в диалоге Review Changes (вызывается кнопкой ).

Диалог Review Changes Хранимые в репозитории модели можно сравнивать (кнопка ). В диалоге Version Manager следует выбрать сравниваемые версии и кликнуть по кнопке Diff.

В появившемся диалоге Version Differences отображается список отличий версий. В репозитории ModelMart реализована функциональность синхронизации моделей процессов и моделей данных, которая ранее была реализована в ERWin'е и BPWin'е путем экспорта и импорта через файлы.bpx -.eax (см. предыдущую статью). Для синхронизации моделей необходимо кликнуть по кнопке.

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

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

При проектировании хранилищ данных необходимо выполнять следующие требования: –хранилище должно иметь понятную для пользователей структуру данных; –должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально); –должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений SQL в традиционных реляционных СУБД; –должна обеспечиваться поддержка сложных запросов SQL, требующих обработки миллионов записей.

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

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

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

Вычисление размера БД ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Расчет строится на основе следующих параметров: -начальное количество строк; -максимальное количество строк; -прирост количества строк в месяц. Результаты расчетов сводятся в отчет.

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

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

Генерация кода клиентской части с помощью ERwin ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения, которые будут отображать информацию, хранящуюся в соответствующей колонке.

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

Генерация кода в Visual Basic ERwin поддерживает генерацию кода в Visual Basic. Источником информации при генерации форм служит модель ERwin. С помощью ERwin можно одновременно описывать как клиентскую часть (объекты, отображающие данные на экране), так и сервер БД (процедуры и триггеры), тем самым оптимально распределяя функциональность ИС между клиентской и серверной частью. Компонент ERwin Form Wizard автоматически проектирует формы с дочерними объектами – кнопками, списками, полями, радиокнопками и т. д., используя расширенные атрибуты.

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

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

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

Литература 1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем М: «Финансы и статистика», Проектирование информационных систем М: «Компьютер Пресс», 9, Колтунова Е. Требования к информационной системе и модели жизненного цикла Требования к информационной системе и модели жизненного цикла 4. Автоматизированные Системы Стадии создания. ГОСТ Комплекс стандартов на автоматизированные системы ИПК издательство стандартов ISO/IEC 12207: Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК, Thiele D. Life cycle management using life cycle process standards. Abstract. Life cycle management using life cycle process standards. Abstract. 8. Козленко Л. Проектирование информационных систем. Проектирование информационных систем.

9.Clegg, Dai and Richard Barker Case Method Fast-track: A RAD Approach Adison-Wesley, Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем М.: Финансы и статистика, Построение и совершенствование систем управления.Построение и совершенствование систем управления. 12. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление М.: ИНФРА-М, Основы организационного бизнеса ( , Эмитент. Существенные факторы, события, действия) 14. Кондратьев В.В., Краснова В.Б. Модульная программа для менеджеров. Реструктуризация управления компанией М.: Инфра-М, Калянов Г.Н. Теория и практика реорганизации бизнес-процессов М.: СИНТЕГ, Калянов Г.Н. Структурный системный анализ М.: Лори, 1996

17. Калянов Г.Н. Структурный системный анализ М.: Лори, Марка Д.А., Мак Гоуэн К. SADT методология структурного анализа и проектирования М.: Метатехнология, Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии М.: Финансы и статистика, Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», ГОСТ Единая система классификации и кодирования технико- экономической информации М.: Изд. стандартов, Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, Буч Г. Объектно-ориентированное проектирование с примерами применения М.: Конкорд, Нейбург Э. Д., Максимчук Р.А. Проектирование баз данных с помощью UML М.: Издательский дом «Вильямс», 2002