- •Тюменский государственный университет
- •Предисловие 7 методические материалы 9
- •Теоретические материалы 27 Глава 1. Методология разработки и стандартизации 27
- •Глава 2. Создание модели процессов в bpWin 95
- •Глава 3. Создание модели данных в erWin 121
- •Предисловие
- •Методические материалы Рабочая программа дисциплины Пояснительная записка
- •Содержание дисциплины
- •Рекомендации по самостоятельной работе Календарно-тематический план самостоятельной работы
- •Методические рекомендации по отдельным видам самостоятельной работы
- •Указания по самостоятельному изучению теоретической части дисциплины
- •Указания по выполнению контрольной работы
- •Указания по выполнению курсовой работы
- •Указания к промежуточной аттестации с применением балльно-рейтинговой системы оценки знаний
- •1.1.2. Классы программ
- •1.1.3. Архитектура программных средств
- •1.2. Стандартизация жизненного цикла программных средств
- •1.2.1. Уровни стандартизации
- •1.2.2. Основные модели жизненного цикла
- •1.2.2.1. Каскадная модель
- •1.2.2.2. Каскадная модель с промежуточным контролем
- •1.2.2.3. Модель разработки программных средств на основе ранее созданных компонентов
- •1.2.2.4. Эволюционная модель
- •1.2.2.5. Модель пошаговой разработки программных средств
- •1.2.2.6. Спиральная модель
- •1.2.2.7. Спиральная модель с ограничением версий
- •1.2.3. Структурное программирование
- •1.2.4. Организация человеко-машинного интерфейса
- •1.2.4.1. Принципы разработки
- •2. Учет возможностей аппаратных и программных средств разработчика и пользователя.
- •1.2.4.2. Рекомендации разработчику
- •1.3. Оценка стоимости и планирование разработки программных средств
- •1.3.1. Оценка стоимости разработки
- •1.3.2. Планирование разработки
- •1.4. Качество программных средств
- •1.4.1. Стандарты качества
- •1.4.2. Основные показатели качества
- •1.4.3. Методы достижения качества
- •1.4.4. Сертификация и аттестация
- •1.4.5. Конфигурационное управление версиями
- •1.4.6. Регламентирование тестирования для обеспечения качества
- •1.4.6.1. Цели и этапы тестирования программ
- •1.4.6.2. Основные тестируемые элементы
- •1.4.6.3. Восходящее и нисходящее тестирование
- •1.5. Методология быстрой разработки приложений (rad)
- •1.6. Структурный подход к проектированию информационных систем
- •1.6.1. Сущность структурного подхода
- •1.6.2. Моделирование потоков данных (бизнес-процессов) dfd
- •Отчет о продажах
- •1.6.3. Функциональное моделирование sadt (idef0)
- •1.6.3.1. Состав функциональной модели
- •1.6.3.2. Иерархия диаграмм
- •1.6.4. Моделирование данных
- •1.6.4.1. Основные понятия
- •1.6.4.2. Методология idef1
- •1.7. Общая характеристика и классификация case-средств
- •1. Компонентный состав:
- •2. Функциональная полнота:
- •3. Степень зависимости от субд:
- •4. Тип используемой модели:
- •1.8. Интеллектуализация вычислительных систем
- •1.9. Рынок программных продуктов
- •Структура рынка программных продуктов и услуг
- •1.10. Классификация систем защиты программных средств
- •1.10.1. Методы установки
- •1.10.2. Методы защиты
- •1.10.3. Принципы функционирования
- •1.10.4. Показатели оценки систем защиты
- •В опросы для контроля
- •Глава 2. Создание модели процессов в bpWin
- •2.1. Среда разработки
- •2.2. Функциональная модель (idef0)
- •2.2.1. Принципы построения модели
- •2.2.2. Работы
- •2.2.3. Стрелки
- •2.2.4. Нумерация работ и диаграмм
- •2.2.5. Диаграммы дерева узлов и экспозиций (feo)
- •2.2.6. Слияние моделей
- •2.2.7. Разделение моделей
- •2.2.8. Отчеты по модели
- •2.2.9. Экспертиза и согласование модели
- •2.3. Оценка модели
- •2.3.1. Стоимостной анализ (abc)
- •2.3.2. Анализ свойств, определенных пользователем (udp)
- •2.4. Дополнительные модели
- •2.4.1. Диаграммы потоков данных (dfd)
- •2.4.2. Диаграммы информационных процессов (idef3)
- •2.4.3. Имитационное моделирование
- •Вопросы для контроля
- •Глава 3. Создание модели данных в erWin
- •3.1. Отображение модели данных
- •3.1.1. Модели представления данных
- •3.1.2. Среда разработки
- •3.1.3. Подмодели и сохраняемые отображения
- •3.2. Создание логической модели данных
- •3.2.1. Уровни логической модели
- •3.2.2. Сущности и атрибуты
- •3.2.3. Связи
- •3.2.4. Типы сущностей и иерархия наследования (супертипы, подтипы)
- •3.2.5. Ключи
- •3.2.6. Методы нормализации и денормализации отношений
- •3.2.7. Домены
- •3.3. Создание физической модели данных
- •3.3.1. Уровни физической модели
- •3.3.2. Выбор субд
- •3.3.3. Таблицы и представления
- •3.3.4. Правила проверки значений и значения по умолчанию
- •3.3.5. Индексы
- •3.3.6. Объекты физической памяти
- •3.3.7. Триггеры и хранимые процедуры
- •3.3.8. Хранилища данных
- •3.3.9. Определение размера базы данных
- •3.3.10. Прямое и обратное проектирование
- •3.4. Создание отчетов в erWin
- •3.5. Связывание моделей процессов и модели данных
- •3.5.1. Экспорт данных из erWin в bpWin
- •3.5.2. Создание сущностей и атрибутов bpWin и их экспорт в erWin
- •В опросы для контроля
- •Глава 4. Генератор отчетов rptWin
- •4.1. Создание нового отчета
- •4.2. Среда конструктора отчетов
- •4.3. Размещение объектов отчета
- •4.4. Группировка и сортировка данных отчета
- •4.5. Изменение файла данных отчета
- •4.6. Изменение свойств отчета
- •4.7. Формирование формул
- •4.8. Пример формирования отчета
- •В опросы для контроля
- •Заключение
- •Практикум
- •Задания для контроля Тесты для самоконтроля
- •Ключи к тестам для самоконтроля
- •Пример выполнения контрольной работы
- •Темы контрольных и курсовых работ
- •1. Учет успеваемости студентов.
- •2. Учет обмена валюты.
- •3. Учет объектов строительства.
- •4. Учет выдачи и возврата книг.
- •5. Учет авиапассажиров.
- •6. Учет производства сельскохозяйственных культур.
- •7. Учет выпуска изделий.
- •8. Учет платежей налогов.
- •9. Учет поставок товаров.
- •10. Учет сбросов отравляющих веществ в окружающую среду.
- •11. Учет уволившихся с предприятия.
- •12. Учет призеров Олимпийских игр.
- •14. Учет участников олимпиады.
- •15. Учет проданных товаров.
- •16. Учет малых предприятий.
- •17. Учет больных в больнице.
- •18. Учет движения общественного транспорта.
- •19. Учет дорожно-транспортных происшествий.
- •20. Учет платежных поручений в банке.
- •21. Учет договоров займа.
- •22. Учет проданных ценных бумаг.
- •23. Учет кадров.
- •24. Учет очередников на получение жилья.
- •25. Учет исполнительской дисциплины.
- •26. Учет книг в библиотеке.
- •27. Учет переселенцев.
- •28. Учет успеваемости школьников.
- •29. Учет нарушителей трудовой дисциплины на предприятии.
- •30. Учет вакцинации населения.
- •Вопросы для подготовки к экзамену
- •Список источников информации
- •Приложения Приложение 1. Стандарты Приложение 1.1. Международный стандарт жизненного цикла
- •1. Процесс приобретения
- •2. Разработка системы и программного средства
- •3. Эксплуатация системы и программного средства
- •4. Сопровождение и развитие системы и программного средства
- •5. Управление проектом и обеспечение качества системы и программного средства
- •6. Интегральные процессы поддержки разработки программных средств
- •Приложение 1.2. Стандарты качества
- •Приложение 1.3. Стандарты по тестированию программ
- •Приложение 1.4. Государственные стандарты рф
- •Приложение 1.5. Единая система программной документации (гост 19)
- •2. Эскизный проект
- •3. Технический проект
- •4. Рабочий проект
- •5. Внедрение
- •Приложение 1.6. Автоматизированные системы управления (гост 24)
- •Приложение 1.7. Автоматизированные системы (гост 34)
- •Приложение 2. Список макрокоманд erWin
- •Приложение 3. Список макрокоманд erWin
3.2.3. Связи
Имя связи между объектами (глагол или глагольная фраза) по умолчанию не показывается на диаграмме; для ее отображения нужно выполнить команду Relationship Display/Verb Phrase из контекстного меню диаграммы. В IDEF1X различаются зависимые и независимые сущности.
Для создания связи следует щелкнуть на кнопке связи, затем – по родительской и дочерней сущности.
И дентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Экземпляр дочерней сущности (изображается прямоугольником со скругленными углами) не может существовать без родительского экземпляра. Первичный ключ автоматически переносится (мигрирует) в дочернюю сущность в состав ее первичного ключа и помечается в круглых скобках символами FK (рисунок 3.2.3.1).
Рисунок 3.2.3.1. Идентифицирующая связь между сущностями
Неидентифицирующая связь устанавливается между независимыми сущностями и оставляет дочернюю сущность независимой: экземпляр дочерней сущности может существовать без родительского экземпляра.
Первичный ключ автоматически переносится (мигрирует) в дочернюю сущность в состав неключевых атрибутов и помечается в круглых скобках символами FK (рисунок 3.2.3.2). Сотрудник может работать самостоятельно, не числясь в каком-либо подразделении.
Р иc. 3.2.3.2. Неидентифицирующая связь между сущностями
Редактирование связи реализуется командой Relationship Properties из контекстного меню линии связи (рисунок 3.2.3.3).
Рисунок 3.2.3.3. Окно настройки свойств связи
Рассмотрим основные свойства и страницы связи.
Cardinality – мощность связи (отношение числа экземпляров родительской сущности к числу экземпляров дочерней): ни одного (Zero), один (One), более одного (More), указанное число (Exactly). Мощность связи между сущностями по умолчанию не показывается на диаграмме, и для ее отображения нужно выполнить команду Relationship Display/Cardinality из контекстного меню диаграммы.
Ver Phase – имя связи от родительской к дочерней сущности (Parent‑to‑Child), и наоборот, для связи «многие‑ко‑многим» (Child‑to‑Parent).
Relationship Type – идентифицирующая/неиндентифицирующая связь (Identifying/Non‑Identifying).
Null – обязательная/необязательная связь (No Nulls/Nulls Allowed). Необязательная неидентифицирующая связь помечается прозрачным ромбиком со стороны родительской сущности (рисунок 3.2.3.2).
Definition – на странице задается полное определение связи для возможности ссылки на эту связь.
R olename – на странице в поле Rolename задается имя роли (функциональное имя – синоним атрибута) внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности (рисунок 3.2.3.4).
Риc. 3.2.3.4. Страница имен ролей
По умолчанию в списке атрибутов показывается только имя роли. Если выполнить команду Entity Display/Rolename/Attribute из контекстного меню диаграммы, то будет показываться полное имя в виде:
<имя роли>.<базовое имя атрибута> (рисунок 3.2.3.5).
Имена ролей обязательны, если несколько атрибутов имеют одинаковую область значений, но разный смысл (рисунок 3.2.3.5).
Рисунок 3.2.3.5. Пример обязательности имен ролей
Рекурсивная связь (одна и та же сущность одновременно является и родительской, и дочерней) требует присвоения имен ролей (рисунок 3.2.3.6).
Рисунок 3.2.3.6. Пример иерархической рекурсивной связи
Связь вида Руководит/Подчиняется, позволяющая хранить древовидную иерархию подчиненности сотрудников, называется иерархической рекурсией.
С етевая рекурсия (рисунок 3.2.3.7) предполагает отношение «многие‑ко‑многим». Для разрешения такой связи создается новая сущность.
Рисунок 3.2.3.7. Пример сетевой рекурсивной связи
Правила ссылочной целостности устанавливаются на странице RI Actions (рисунок 3.2.3.8).
Рисунок 3.2.3.8. Установка правил ссылочной целостности связи
Контроль целостности связей осуществляется автоматически СУБД согласно правилам, которые устанавливаются при проектировании БД.
Правила задаются следующими параметрами.
CASCADE/RESTRICT – разрешает/запрещает каскадные операции.
Ввод данных. Если добавляется новая запись в дочерний объект, для которого отсутствует запись из родительского объекта, то такой ввод может быть заблокирован (CASCADE).
Пример. Блокировка ввода записи дочернего объекта «СОТРУДНИК», если указывается значение атрибута «Код подразделения», отсутствующего в родительском объекте «ПОДРАЗДЕЛЕНИЕ».
Корректировка данных. Если корректируется поле связи родительского объекта, то автоматически меняются поля связей соответствующих записей дочернего объекта (CASCADE) или корректировку нужно заблокировать (RESTRICT).
Пример. После изменения в родительском объекте «ПОДРАЗДЕЛЕНИЕ» значения атрибута «Код подразделения» с 2 на 202 автоматически изменятся в дочернем объекте «СОТРУДНИК» все записи со значением атрибута «Код подразделения», равным 2, на новое значение 202 (все сотрудники из подразделения с кодом 2 переведутся в подразделение с новым кодом 202). Если такой перевод не может быть реальным, то можно установить правило блокировки корректировки, что не позволит изменить код подразделения в объекте «ПОДРАЗДЕЛЕНИЕ» на новое значение, если есть сотрудники в данном подразделении.
Удаление записей. Если удаляется запись родительского объекта, то автоматически удаляются все соответствующие записи дочернего объекта (CASCADE) или удаление нужно заблокировать (RESTRICT).
Пример. После удаления в родительском объекте «ПОДРАЗДЕЛЕНИЕ» записи со значением атрибута «Код подразделения», равным 201, автоматически удаляются в дочернем объекте «СОТРУДНИК» все записи со значением атрибута «Код подразделения», равным 201 (все сотрудники из подразделения с кодом 201 увольняются). Если такого расформирования подразделения не может быть, то устанавливают правило блокировки каскадного удаления записей. Это не позволит удалить запись с кодом подразделения в объекте «ПОДРАЗДЕЛЕНИЕ», равным значению 201 (сначала нужно удалить все записи из объекта «СОТРУДНИК» со значением атрибута «Код подразделения», равным 201, а затем удалить запись в родительском объекте «ПОДРАЗДЕЛЕНИЕ» со значением атрибута «Код подразделения», равным 201).
NONE – отмена контроля ссылочной целостности. Значение внешнего ключа не меняется при соответствующих операциях (для дочерних записей могут отсутствовать родительские записи).
SET NULL/DEFAULT – при удалении родительской записи значения внешних ключей в дочерних записях примут значения NULL/умалчиваемые (дочерние записи будут автономными/переподчинены другой родительской записи со значением ключа, равным умалчиваемому значению).
Эти правила можно отобразить в диаграмме командой Format/Relationship Display/Referential Integrity.
Связь «многие‑ко‑многим» допускается только на логическом уровне.
Р ассмотрим пример такой связи (рисунок 3.2.3.9).
Рисунок 3.2.3.9. Связь «многие‑ко‑многим»
При переходе к физическому уровню командой Create Accosiation Table из контекстного меню этой связи она преобразуется в две связи «один‑ко‑многим» к новой созданной таблице-связке (рисунок 3.2.3.10) .
Рисунок 3.2.3.10. Связь «многие‑ко‑многим» на физическом уровне
Имя этой сущности можно изменить, например на Визит. Первичные ключи мигрируют в эту сущность. Первичный ключ этой сущности можно дополнить, например, датой визита пациента (рисунок 3.2.3.11).
Внесенные изменения на физическом уровне не изменяют представление на логическом уровне (рисунок 3.2.3.9).
Рисунок 3.2.3.11. Дополнение физической модели со связью «многие‑ко‑многим»