
- •Методы и средства проектирования информационных систем
- •Предисловие
- •1. Теоретические основы систем управления
- •1.1. Основные понятия
- •1.2. Классификация систем
- •1.3. Структура системы управления
- •2. Основы создания информационной системы предприятия
- •2.1. Методологии и средства разработки ис
- •2.2. Жизненный цикл ис
- •2.3. Структурный анализ
- •3. Разработка консалтинговых проектов
- •3. 1. Цели и основные этапы разработки консалтинговых проектов
- •3.2. Проведение обследования деятельности предприятия
- •3.2.1. Методика и этапы обследования
- •3.2.2. Организация сбора и первичной обработки данных
- •3.3. Построение моделей
- •3.4. Разработка системного проекта
- •3.5. Разработка предложений по автоматизации
- •3.6. Техническое проектирование
- •4. Структурные методы моделирования систем управления
- •4.1. Методология функционального моделирования idef0 (sadt)
- •4.1.1. Sadt-модели
- •4.1.2. Синтаксис и применение диаграмм
- •4.1.3. Синтаксис моделей и работа с ними
- •4.1.4. Процесс моделирования
- •4.2. Методология построения реляционных структур idef1x.
- •4.3. Диаграммы потоков данных (Data Flow Diagramming)
- •4.4. Метод описания процессов idef3
- •4.5. Описание нотации aris eEpc.
- •5. Анализ и реорганизация бизнес-процессов
- •5.2. Анализ структуры процессов в соответствии с iso 9000 - стандартом на качество проектирования, разработки, изготовления и послепродажного обслуживания
- •5.4. Ключевые моменты реорганизации деятельности предприятия
- •6. Создание модели процессов в bPwin
- •6.1. Инструментальная среда bPwin
- •6.2. Каркас диаграммы
- •6.3. Слияние и расщепление моделей
- •6.4. Создание отчетов в bPwin
- •6.5. Стоимостной анализ и свойства, определяемые пользователем
- •6.6. Диаграммы dfd и Workflow (idef3)
- •7. Создание модели данных с помощью eRwin
- •7.1. Отображение модели данных в eRwin
- •7.1.1. Физическая и логическая модели данных
- •7.1.2. Подмножества модели и сохраняемые отображения
- •7.2. Создание логической модели данных
- •7.2.1. Уровни логической модели
- •7.2.2. Сущности и атрибуты
- •7.2.3. Связи
- •7.2.4. Типы сущностей и иерархия наследования
- •7.2.5. Ключи
- •7.2.6. Домены
- •7.3. Создание физической модели данных
- •7.3.1. Уровни физической модели
- •7.3.2. Выбор сервера
- •7.3.3. Таблицы, колонки и представления (view)
- •7.3.4. Правила валидации и значения по умолчанию
- •7.3.5. Индексы
- •7.3.6. Задание объектов физической памяти
- •7.3.7. Триггеры и хранимые процедуры
- •7.3.8. Проектирование хранилищ данных
- •7.3.9. Вычисление размера бд
- •7.3.10. Прямое и обратное проектирование
- •8. Объектно-ориентированный подход
- •8.1. Основные принципы
- •8.3. Обзор диаграммных техник uml
- •8.4. Пакеты как средство работы с большими проектами
- •8.5. Диаграммы классов и объектов
- •8.5.1. Классы
- •8.5.2. Интерфейсы
- •8.5.3 Отношения между классами
- •8.5.4 Пример диаграммы классов
- •8.6. Диаграммы использования
- •8.7. Диаграммы последовательностей
- •8.8. Диаграммы сотрудничества
- •8.9. Диаграммы состояний
- •8.10. Диаграммы действий
- •8.11. Диаграммы реализации
- •9. Унифицированный процесс разработки и uml
- •9.2. Фазы унифицированного процесса и диаграммы uml
- •10. Объектно-ориентированное case средство Rational Rose
- •10.1. Состав и основные возможности
- •10.2. Этапы проектирования
- •Литература
- •Содержание.
7.3.6. Задание объектов физической памяти
ERwin поддерживает объекты физической памяти для нескольких СУБД. Все объекты создаются в модели при обратном проектировании, однако объекты INFORMIX, SQL Server и SYBASE не создаются при прямом проектировании.
Для создания и редактирования объектов физической памяти в ERwin используется редактор Physical Object (меню Server/Physical Object). Вид этого редактора зависит от выбранной СУБД.
7.3.7. Триггеры и хранимые процедуры
Триггеры и хранимые процедуры - это именованные блоки кода SQL, которые заранее откомпилированы и хранятся на сервере для того, чтобы быстро производить выполнение запросов, валидацию данных и выполнять другие часто вызываемые функции.
Хранение и выполнение кода на сервере позволяет создавать код только один раз, а не в каждом приложении, работающем с БД, что экономит время при написании и сопровождении программ. При этом гарантируется, что целостность данных и бизнес-правила поддерживаются независимо от того, какое именно клиентское приложение обращается к данным. Триггеры и хранимые процедуры не требуется пересылать по сети из клиентского приложения, что значительно снижает сетевой трафик.
Хранимой процедурой называется именованный набор предварительно откомпилированных команд SQL, который может вызываться из клиентского приложения или из другой хранимой процедуры.
Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при отработке команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере.
Триггер ссылочной целостности - особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности (RI-триггер) сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной (измененной, удаленной) строки. По умолчанию ERwin генерирует триггеры, дублирующие декларативную ссылочную целостность.
Для генерации триггеров ERwin использует механизм шаблонов - специальных скриптов, использующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые Erwin, по умолчанию можно изменять, кроме того, можно переопределить как триггеры для конкретной связи, так и шаблоны во всей модели в целом.
Шаблоны триггеров ссылочной целостности связываются с сущностями в зависимости от типа связи и роли сущности в этой связи. Тип связи и роль сущности определяют, какое правило ссылочной целостности будет по умолчанию дополнено шаблоном триггера. Связи могут быть: идентифицирующими, неидентифицирующими (nulls allowed), неидентифицирующими (no nulls), связями подтипа.
Сущность в связи может быть родительская (Parent) или дочерняя (Child). Если сущность является родительской в данной связи, то ERwin присваивает ей шаблон триггера для родительской сущности. Если сущность является дочерней в данной связи, то ERwin присваивает ей шаблон триггера для дочерней сущности. Код триггера, который генерируется шаблоном триггера для родительской сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в родительской таблице связи. Код триггера, который генерируется шаблоном триггера для дочерней сущности, указывает СУБД, что нужно делать при вставке, изменении или удалении строки в дочерней таблице связи.
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, которые вызывают диалоги, предназначенные для создания и редактирования пользовательских триггеров и шаблонов триггеров ссылочной целостности .
Для создания триггера служит редактор Table Trigger Editor (вызывается кнопкой Table Trigger диалога Table Trigger Viewer).