- •Тюменский государственный университет
- •Предисловие 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.6. Методы нормализации и денормализации отношений
Метод нормализации отношений (таблицы) – это процесс постепенного улучшения отношения (таблицы) путем последовательного перевода отношения (таблицы) из ненормализованной формы в первую, вторую, третью (иногда в четвертую и пятую) нормальные формы.
Проектирование таблиц можно начинать с построения концептуальной модели и определения состава атрибутов для каждого объекта. Затем все атрибуты можно объединить в одну исходную таблицу. Можно сразу, без построения концептуальной модели, сформировать исходную таблицу. Исходная таблица в дальнейшем нормализуется путем расщепления на взаимосвязанные новые таблицы. Таким образом, можно построить или уточнить существующую концептуальную модель базы.
Определение. Таблица находится не в нормализованной форме, если существует ячейка, в которой находится несколько значений.
Пример ненормализованной таблицы.
ИЗДЕЛИЯ (Код изделия, список деталей). Может встретиться изделие, которое содержит список из нескольких деталей.
Виды зависимостей между атрибутами
Атрибут (группа атрибутов) «В» функционально зависит от атрибута (группы атрибутов) «A», если каждому значению «A» соответствует одно значение «B». Такая зависимость изображается в виде A-->B (Табельный номер -->Фамилия сотрудника).
Если существует функциональная зависимость вида A-->B и B-->A, то имеет место функциональная взаимозависимость, которая изображается в виде A<-->B (Табельный номер <-->Номер паспорта сотрудника).
Частичная функциональная зависимость – это зависимость неключевого атрибута от части составного ключа, а не от всего ключа.
Полной функциональной зависимостью называется зависимость неключевого атрибута от всего ключа.
Атрибут «C» транзитивно зависит от атрибута «А», если выполняются условия A-->B и B-->C, но обратная зависимость отсутствует.
Многозначные зависимости вида 1:M, M:1, M:M между атрибутами
«A» и «B» изображаются в виде A-->>B, A<<--B и A<<-- >>B соответственно.
Первая нормальная форма (1НФ)
Определение. Таблица находится в первой нормальной форме, если в каждой ее ячейке находится не более одного значения.
Пример. Преобразуем таблицу «ИЗДЕЛИЯ» из предыдущего примера в таблицу вида: ИЗДЕЛИЯ (код изделия, деталь). Тогда, за счет дублирования кода изделия, в каждой строке в колонке «Деталь» будет стоять только одно значение – наименование кода детали. Новая таблица будет в первой нормальной форме.
Покажем процесс нормализации на следующей исходной таблице:
ВЫПУСК ИЗДЕЛИЙ (Код подразделения (KP), наименование подразделения (NP), код изделия (KI), наименование изделия (NI), код типа изделия (KTI), наименование типа изделия (NTI), дата выпуска (DVI), количество (KVI), себестоимость изделия (SI)). Ключевые атрибуты первичного ключа подчеркнуты. Эта таблица находится в первой нормальной форме.
Рассмотрим аномалии (недостатки) первой нормальной формы.
Избыточное дублирование данных. Все наименования будут дублироваться в каждой строке нашей таблицы.
Аномалия включения. Пока изделие не будет выпущено, информация о нем (проектируемом или ранее снятом с производства) будет отсутствовать в базе.
Аномалия удаления. Если изделие не выпускается в отчетный период, то информация об изделии исчезнет из базы.
Аномалия корректировки. Если меняется, например, название изделия, то нужно откорректировать наименование не в одной строке, а во всех строках таблицы, где оно встречается.
Для устранения этих недостатков продолжим процесс нормализации. Вторая нормальная форма (2НФ)
Определение. Таблица находится во второй нормальной форме, если она уже находится в первой нормальной форме, и все неключевые атрибуты целиком зависят от всего ключа, а не от отдельной его части.
Рассмотрим нашу таблицу на предмет выявления неключевых атрибутов, зависящих только от части ключа.
Атрибут «Наименование подразделения» зависит только от атрибута «Код подразделения» и не зависит от атрибутов «Код изделия» и «Дата выпуска». Поэтому его следует удалить из таблицы. Чтобы не потерять информацию о подразделении, создадим новую таблицу «ПОДРАЗДЕЛЕНИЯ» и в нее включим удаляемый атрибут «Наименование подразделения» вместе с ключевым атрибутом «Код подразделения» (иначе потеряется связь с таблицей «ВЫПУСК ИЗДЕЛИЙ») и получим таблицу вида:
ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование подразделения).
Атрибут «Наименование изделия» зависит только от атрибута «Код изделия» и не зависит от остальных ключевых атрибутов. Аналогично предыдущему случаю удалим его из таблицы в новую таблицу:
ИЗДЕЛИЯ (Код изделия, наименование изделия).
Атрибут «Код типа изделия» зависит только от атрибута «Код изделия» и не зависит от атрибутов «Код подразделения» и «Дата выпуска». Аналогично предыдущему случаю удалим его из таблицы, добавим в таблицу «ИЗДЕЛИЯ» и получим таблицу:
ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия).
Атрибут «Наименование типа изделия» зависит только от атрибута «Код изделия». Аналогично предыдущему случаю удалим его из таблицы и добавим в таблицу «ИЗДЕЛИЯ» и получим таблицу:
ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия, наименование типа изделия).
Атрибуты «Количество» и «Себестоимость изделия» зависят от всего ключа, поэтому оставим их в исходной таблице.
Таким образом, получим три таблицы:
ВЫПУСК ИЗДЕЛИЙ (Код подразделения, код изделия, дата выпуска, количество, себестоимость изделия).
ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование подразделения).
ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия, наименование типа изделия).
Очевидно, что все они находятся во второй нормальной форме.
Третья нормальная форма (3НФ)
Определение. Таблица находится в третьей нормальной форме, если она уже находится во второй нормальной форме, и все неключевые атрибуты взаимно функционально независимы.
Очевидно, что первые две таблицы удовлетворяют определению третьей нормальной формы. Рассмотрим таблицу «ИЗДЕЛИЯ».
Атрибут «Наименование типа изделия» функционально зависит от неключевого атрибута «Код типа изделия», поэтому его следует удалить (по определению третьей нормальной формы) из таблицы в новую:
ТИПЫ ИЗДЕЛИЙ (Код типа изделия, наименование типа изделия).
В результате получим модель базы данных из четырех таблиц в третьей нормальной форме (рисунок 3.2.6.1):
ВЫПУСК ИЗДЕЛИЙ (Код подразделения, код изделия, дата выпуска, количество, себестоимость изделия).
ПОДРАЗДЕЛЕНИЯ (Код подразделения, наименование подразделения).
ИЗДЕЛИЯ (Код изделия, наименование изделия, код типа изделия).
ТИПЫ ИЗДЕЛИЙ (Код типа изделия, наименование типа изделия).
Рисунок 3.2.6.1. Модель базы данных «Выпуск изделий»
Убедимся в исчезновении аномалий из первой нормальной формы.
Избыточное дублирование данных. Все наименования сохраняются в таблицах по одному разу без дублирования.
Аномалия включения. Хотя изделие еще не выпущено, но информацию о нем можно занести или сохранить в таблице «ИЗДЕЛИЯ».
Аномалия удаления. Если изделие не выпускается в отчетный период, то информация об изделии сохранится в таблице «ИЗДЕЛИЯ».
Аномалия корректировки. Если меняется название изделия, то нужно откорректировать наименование только в одной строке таблицы «ИЗДЕЛИЯ»..
Существуют еще несколько, редко используемых нормальных форм, которые связаны только с составными ключами.
Усиленная третья нормальная форма, или нормальная форма Бойса‑Кодда (НФБК)
Определение. Таблица находится в усиленной третьей нормальной форме, если она уже находится в третьей нормальной форме, и в ней отсутствуют функциональные зависимости ключевых атрибутов составного ключа от неключевых атрибутов.
Четвертая нормальная форма (4НФ)
Определение. Таблица находится в четвертой нормальной форме, если она уже находится в третьей нормальной форме, и в ней отсутствуют многозначные функциональные зависимости вида M:M между атрибутами.
Пример. Имеется таблица вида:
ПРЕПОДАВАТЕЛИ (Табельный номер преподавателя, предмет, группа).
Очевидно, что имеем многозначную функциональную зависимость между атрибутами «Предмет» и «Группа». Будем считать, что для каждой группы одним преподавателем читается один набор предметов. Существует аномалия: при добавлении новой группы нужно добавить несколько записей, по числу читаемых преподавателем предметов, что вызывает нежелательное дублирование значений атрибута «Предмет». Исключим многозначную функциональную зависимость путем переноса этих атрибутов в разные таблицы, разделяя исходную таблицу на две:
ПРЕПОДАВАТЕЛИ ПРЕДМЕТЫ (Табельный номер преподавателя, предмет).
ПРЕПОДАВАТЕЛИ ГРУППЫ (Табельный номер преподавателя, группа).
Пятую нормальную форму (5НФ) не будем рассматривать из‑за крайне редкого ее использования (она возможна при наличии трех и более объектов, связанных друг с другом отношением «многие-ко-многим»), тем более что она имеет недостатки.
Денормализация – процесс введения избыточности данных в таблицах (нарушения нормализации) в целях повышения производительности. Существуют нисходящая (копирование атрибута из родительского объекта в дочерний) и восходящая (копирование атрибута из дочернего в родительский объект в форме итога) денормализация.
Пример. Нормализованные таблицы «ПРЕПОДАВАТЕЛИ ПРЕДМЕТЫ» и «ПРЕПОДАВАТЕЛИ ГРУППЫ» из предыдущего примера можно объединить в исходную таблицу «ПРЕПОДАВАТЕЛИ». Хотя и имеет место дублирование данных, но работа с одной таблицей будет быстрее, чем с двумя нормализованными.
В реальном проектировании разработчик должен достигнуть компромисса между нормализацией (устранение избыточности) и денормализацией (увеличение производительности) таблиц.