Суркова Н.Е., Остроух А.В. Методы проектирования ИС.-М.

-3-
ВВЕДЕНИЕ
Проектирование информационных систем (ИС) – логически сложная,
трудоемкая и длительная работа, требующая высокой квалификации
участвующих в ней специалистов. Однако до настоящего времени
проектирование ИС нередко выполняется на интуитивном уровне
неформализованными
методами,
искусства, практический
включающими
в
себя
элементы
опыт, экспертные оценки и дорогостоящие
экспериментальные проверки качества функционирования ИС. Кроме того,
в
процессе
создания
и
функционирования
ИС
информационные
потребности пользователей постоянно изменяются или уточняются, что
еще более усложняет разработку и сопровождение таких систем.
Широкое использование баз данных, создание большого набора
автоматизированных рабочих мест (АРМ) на базе языков 4-го поколения,
позволяющих с помощью генераторов запросов, отчетов, экранных форм,
диалога быстро разрабатывать удобные для пользователей приложения,
появление гибких локальных и глобальных вычислительных сетей
позволили
во
многом
пересмотреть
принципы
хозяйственной
деятельности, обеспечить оперативность коммуникации и интеграцию
участников бизнес-процессов, повысить качество принимаемых решений
на всех уровнях управления. К сожалению, кажущаяся простота систем
данных способствовала тому, что пользователи стали самостоятельно
создавать базы данных и приложения, не имея достаточных знаний о
методах проектирования эффективно работающих систем. Поэтому, один
раз возникнув, "кризис программного, обеспечения", или, как его еще
называют, "депрессия программного обеспечения",
поныне, что выражается
продолжается и
в том, что проекты растягивались на долгое
время или значительно превышали
сметы расходов, разработанный
продукт не обладал требуемыми функциональными возможностями,
-4производительность его была низка, качество получаемого программного
продукта не устраивало непосредственных потребителей.
Основанием для написания этого учебного пособия стал многолетний
опыт работы авторов по проектированию баз данных для создаваемого
программного обеспечения, а также по разрешению проблем (что
возможно далеко не всегда), вызванных несоответствием существующих
систем и предъявляемым к ним требованиям. Кроме того, занимаясь
преподавательской
работой,
авторы
столкнулись
с
аналогичными
проблемами, возникающими в совершенно иной пользовательской среде
— среде студентов. Поэтому основной целью стало создание учебного
пособия, в котором ясно и четко были бы изложены практические основы
разработки и использования технологий проектирования ИС,
выбора
методов и средств проектирования, основанных на использовании CASE
–технологии,
предназначенные
для
использования
как
профессиональными разработчиками, так и непрофессионалами.
Проектирование ИС включает в себя
разработку
прикладного
проектирование баз данных и
программного
обеспечения.
Наличие
универсальных СУБД, имеющих развитые функциональные возможности,
сводят задачу построения ИС к задаче проектирования базы данных и
выбора, на соответствующем этапе, той или иной типовой СУБД. Таким
образом, база данных является центральным элементом и основным
определяющим фактором при создании высокопроизводительных ИС. В
то
же
время,
тенденция
развития
современных
информационных
технологий определяют постоянное возрастание сложности приложений
ИС, усиления их роли в повышении качества ИС, увеличения срока ее
жизни.
Предложенная в этом учебном пособии методология работы с
реляционными Системами Управления Базами Данных (в дальнейшем —
СУБД), доминирующими в настоящее время в бизнес-приложениях,
-5успешно прошла проверку временем как в практической, так и в
академической среде. Проектирование баз данных состоит из трех фаз:
концептуальной, логической и физической. Первая фаза предусматривает
создание концептуальной модели данных, не зависящей от каких-либо
физических характеристик. Во второй фазе, назначение которой состоит в
создании логической модели данных, концептуальная модель подвергается
доработке посредством удаления элементов, которые не могут быть
реализованы в реляционных системах. В третьей фазе логическая модель
данных преобразуется в физический проект, предназначенный для
реализации в среде конкретной целевой СУБД. При этом анализируются
структуры хранения данных и методы доступа, необходимые для
эффективной работы с базой данных, размещенной на внешних
запоминающих устройствах.
Каждая из фаз предлагаемой методологии представлена в виде
последовательности
проектировщик
этапов.
будет
Предполагается,
выполнять
эти
этапы
что
неопытный
в
указанной
последовательности, придерживаясь приведенных рекомендаций. Более
опытному разработчику не так уж обязательно жестко придерживаться
данной методологии, ее скорее, следует использовать как некую основу
или контрольный перечень необходимых действий. Чтобы облегчить
читателю процесс изучения методологии и понимания некоторых важных
вопросов, в главах этого пособия дано подробное описание практического
примера
- проектирование информационной "Подготовка учебных
планов", предназначенного для того, чтобы читатель смог применить на
практике предложенную ему методологию.
-6-
1. СТРУКТУРА, КЛАССИФИКАЦИЯ И СОСТАВ
ИНФОРМАЦИОННЫХ СИСТЕМ
1.1. Понятие информационной системы
Информационная система (ИС) представляет собой совокупность
организационных, технических, программных и информационных средств,
объединенных в единую систему с целью сбора, хранения, обработки и
выдачи необходимой информации, предназначенной для выполнения
функций управления.
К ИС предъявляются следующие требования:
 полнота и достаточность информации для реализации функций
управления;
 своевременность предоставления информации;
 обеспечение необходимой степени достоверности информации в
зависимости от уровня управления;
 экономичность обработки информации, то есть затраты на
обработку данных не должны превышать получаемый эффект;
 адаптивность к изменяющимся информационным потребностям
пользователей.
Информационная система создается для конкретного объекта.
Эффективная информационная система принимает во внимание различия
между уровнями управления, сферами действия, а также внешними
обстоятельствами и дает каждому уровню управления только ту
информацию, которая ему необходима для эффективной реализации
функций управления.
Внедрение ИС производится с целью повышения эффективности
производственно-хозяйственной
принципиально
новых
деятельности
методов
фирмы
управления,
за
основанных
счет
на
-7моделировании деятельности специалистов фирмы при принятии решений
(методы
искусственного
интеллекта, экспертные
системы
и
т.п.),
использования современных средств телекоммуникаций (электронная
почта, телеконференции) и вычислительных сетей, а также сокращения
времени выполнения типовых операций по обработке различного рода
документации.
1.2. Классификация информационных систем
Все ИС можно классифицировать по степени автоматизации
обрабатываемой информации и по сфере применения (рис. 1.1).
Информационные
системы (ИС)
По степени автоматизации
обрабатываемой
информации
По сфере применения
Ручные
Системы поддержки
принятия решений
Автоматизированные
Системы
автоматизированного
проектирования
Автоматические
Системы
организационного
управления
Системы управления
технологическими
процессами
Рис. 1.1. Классификация информационных систем
-8В
зависимости
от
степени
автоматизации
обрабатываемой
информации ИС разделяются на:
 ручные;
 автоматизированные;
 автоматические.
Ручные ИС характеризуются тем, что все операции по обработке
данных выполняются человеком.
Автоматизированные ИС – часть функций (подсистем) управления
или обработки данных осуществляется
автоматически, а часть –
человеком.
Автоматические ИС – все функции управления и обработки данных
осуществляются
техническими
средствами
без
участия
человека
(например, автоматическое управление технологическими процессами).
По сфере применения можно выделить следующие классы ИС:
 системы поддержки принятия решений;
 системы автоматизированного проектирования;
 системы организационного управления;
 системы управления технологическими процессами.
Системы поддержки принятия решений предназначены для
автоматизации деятельности научных работников, анализа статистической
информации, управление экспериментом.
Системы автоматизированного проектирования предназначены
для автоматизации труда инженеров-проектировщиков и разработчиков
новой технологии. Основными задачами таких ИС являются:
 автоматизация
процесса
технологий их производства;
разработки
новых
изделий
и
-9 автоматизация инженерных расчетов (определение технических
параметров
изделий,
расходных
норм
–
трудовых,
материальных и т.д.);
 создание
графической
документации
(чертежей,
схем,
планировок);
 моделирование проектируемых объектов;
 создание управляющих программ для станков с программным
управлением.
Системы
организационного
управления
предназначены
для
автоматизации функций административного (управленческого) персонала.
К этому классу относятся ИС управления как промышленными
(предприятиями), так и непромышленными объектами (банки, биржи,
страховые компании, гостиницы и т.д.) и отдельными офисами (офисные
системы).
Системы
управления
технологическими
процессами
предназначены для автоматизации различных технологических процессов
(гибкие производственные процессы, металлургия, энергетика и т.п.).
1.3. Структура и состав информационной системы
Практически все рассмотренные разновидности независимо от сферы
их применения включают один и тот же набор компонентов (рис. 1.2):
 функциональные компоненты;
 компоненты системы обработки данных;
 организационные компоненты.
-10Информационная система
Функциональный
компонент
Компоненты
системы
обработки данных
(СОД)
Организационные
компоненты
(персонал)
Функциональные
подсистемы
(модули, бизнесприложения)
Информацонное
обеспечение
Новая
организационная
структура фирмы
Функциональные
задачи
Программное
обеспечение
Персонал
(штаты,
должностные
инструкции)
Модели и
алгоритмы
Техническое
обеспечение
Правовое
обеспечение
Лингвистическое
обеспечение
Рис. 1.2. Декомпозиция информационной системы
При этом под функцией управления понимается специальная
постоянная обязанность одного или нескольких лиц, выполнение которой
приводит к достижению определенного делового результата.
1.3.1. Функциональные компоненты ИС
Под функциональными компонентами понимается система функций
управления – полный набор (комплекс) взаимоувязанных во времени и
пространстве работ по управлению,
поставленных перед предприятием целей.
необходимых для достижения
-11Именно от того, как будет выполнено то или иное задание отдельным
работником, зависит успех в решении конечных задач фирмы в целом.
Таким
образом,
вся
сложнейшая
совокупность
управленческих
воздействий должна иметь своим конечным результатом доведение общих
задач, стоящих перед предприятием, до каждого конкретного исполнителя
независимо от его служебного положения. Естественно, приведенные
положения подчеркивают не только индивидуальный, но и групповой
характер функций управления, а деловой (практический) результат
получается не эпизодически, а постоянно.
Весь процесс управления фирмой сводится либо к линейному
(например, административному) руководству предприятием или его
структурным подразделением, либо к функциональному руководству
(например, материально-техническое обеспечение, бухгалтерский учет и т.
п.).
Поэтому
декомпозиция
информационной
системы
по
функциональному признаку (см. рис.1.2) включает в себя выделение ее
отдельных
частей,
(функциональными
называемых
модулями,
функциональными
бизнес-приложениями),
подсистемами
реализующих
систему функций управления. Функциональный признак определяет
назначение подсистемы, то есть то, для какой области деятельности она
предназначена и какие основные цели, задачи и функции она выполняет.
Функциональные подсистемы в существенной степени зависят от
предметной области (сферы применения) ИС.
Несмотря на различные сферы применения ИС, ряд функциональных
подсистем имеют одно и то же наименование (например, бухгалтерский
учет и отчетность), однако их внутреннее содержание для различных
объектов
значительно
отличается
друг
от
друга.
Специфические
особенности каждой функциональной подсистемы содержатся в так
называемых «функциональных задачах» подсистемы (см. рис. 1.2).
-12Обычно
управленческий
персонал
или
связывает
это
понятие
с
достижением определенных целей функции управления, или определяет
его как работу, которая должна быть выполнена определенным способом в
определенный период. Однако с появлением новых информационных
технологий понятие «задача» рассматривается шире — как законченный
комплекс обработки информации, обеспечивающий либо выдачу прямых
управляющих воздействий на ход производственного процесса, либо
выдачу необходимой информации для принятия решений управленческим
персоналом. Таким образом, задача должна рассматриваться как элемент
системы управления, а не как элемент системы обработки данных.
Выбор состава функциональных задач функциональных подсистем
управления осуществляется обычно с учетом основных фаз управления:
 планирования;
 учета, контроля и анализа;
 регулирования (исполнения).
Планирование - это управленческая функция, обеспечивающая
формирование планов, в соответствии с которыми будет организовано
функционирование объекта управления. Обычно выделяют перспективное
(5-10 лет), годовое (1 год) и оперативное (сутки, неделя, декада, месяц)
планирование.
Учет, контроль и анализ – это функции,
обеспечивающие
получение данных о состоянии управляемой системы за определенный
промежуток
фактического
времени;
определение
состояния
объекта
факта
и
управления
причины
от
ее
отклонений
планируемого
состояния, а также нахождения величин этого отклонения. Учет ведется по
показателям плана в выбранном диапазоне (горизонте) планирования
(оперативный, среднесрочный и т.д.).
Регулирование
(исполнение)
–
это
функция,
обеспечивающая
сравнение планируемых и фактических показателей функционирования
-13объекта
управления
и
реализацию
воздействий при наличии отклонений
необходимых
управляющих
от запланированных в заданном
диапазоне (отрезке).
Выбор и обоснование состава функциональных задач является одним
из важнейших элементов создания ИС. Отметим также, что именно задача
(функциональная подсистема) является объектом разработки, внедрения и
эксплуатации конечным пользователем.
Анализ функциональных задач показывает, что их практическая
реализация в условиях использования ИС многовариантна. Одна и та же
задача может быть решена (реализована) различными математическими
методами, моделями и алгоритмами (см. рис. 1.2). Иногда эту
функциональную подсистему называют подсистемой математического
обеспечения.
Среди множества вариантов реализации, как правило, имеется
наилучший, определяемый возможностями вычислительной системы и
системы обработки данных в целом.
В
современных
системах
автоматизации
проектирования
информационных систем этот компонент входит в состав так называемых
банков моделей и алгоритмов, из которых в процессе разработки
информационных
систем
выбираются
наиболее
эффективные
для
конкретного объекта управления.
1.3.2. Компоненты системы обработки данных
Система
обработки
данных
(СОД)
предназначена
для
информационного обслуживания специалистов разных органов управления
предприятия, принимающих управленческие решения.
Основная функция системы обработки данных — реализация типовых
операций обработки данных, каковыми являются:
-14 сбор, регистрация и перенос информации на машинные
носители;
 передача информации в места ее хранения и обработки;
 ввод информации в ЭВМ, контроль ввода и ее компоновка в
памяти компьютера;
 создание и ведение внутримашинной информационной базы;
 обработка информации на ЭВМ (накопление, сортировка,
корректировка,
выборка,
арифметическая
и
логическая
обработка) для решения функциональных задач системы
(подсистемы) управления объектом;
 вывод информации в виде табуляграмм, видеограмм, сигналов
для
прямого
управления
технологическими
процессами,
информации для связи с другими системами;
 организация, управление (администрирование) вычислительным
процессом (планирование, учет, контроль, анализ реализации
хода вычислений) в локальных и глобальных вычислительных
сетях.
Выделение типовых операций обработки данных позволило создать
специализированные программно-аппаратные комплексы, их реализующие
(различные периферийные устройства, оргтехнику, стандартные наборы
программ, в том числе пакеты прикладных программ — ППП, —
реализующих функциональные задачи ИС). Конфигурация аппаратных
комплексов
образует
так
называемую
топологию
системы.
СОД могут работать в трех основных режимах:
 пакетном;
 интерактивном;
 реальном масштабе времени.
вычислительной
-15Для пакетного режима характерно, что результаты обработки
выдаются пользователям после выполнения так называемых пакетов
заданий.
В качестве примера систем, работающих в пакетном режиме, можно
назвать системы статистической отчетности, налоговых инспекций,
расчетно-кассовых центров (РКЦ), банков и т.д. Недостатком такого
режима является обособленность пользователя от процесса обработки
информации, что снижает оперативность принятия управленческих
решений.
При интерактивном (диалоговом) режиме работы происходит обмен
сообщениями между пользователем и системой. Пользователь обдумывает
результаты запроса и принятые решения вводит в систему для дальнейшей
обработки. Типичными примерами диалоговых задач можно считать
многовариантные
задачи
использования
ресурсов
(трудовых,
материальных, финансовых).
Режим
реального
времени
используется
для
управления
быстропротекающими процессами, например, передачей и обработкой
банковской информации в глобальных международных сетях типа SWIFT,
и непрерывными технологическими процессами.
Практически все системы обработки данных информационных систем
независимо от сферы их применения включают один и тот же набор
составных частей (компонентов), называемых видами обеспечения (см.
рис. 1.2). Принято выделять информационное, программное, техническое,
правовое, лингвистическое обеспечение.
Информационное обеспечение - это совокупность методов и средств
по размещению и организации информации, включающих в себя системы
классификации и кодирования, унифицированные системы документации,
рационализации документооборота и форм документов, методов создания
внутримашинной информационной базы информационной системы. От
-16качества разработанного информационного обеспечения во многом
зависит достоверность и качество принимаемых управленческих решений.
Программное обеспечение — совокупность программных средств для
создания и эксплуатации СОД средствами вычислительной техники. В
состав программного обеспечения входят базовые (общесистемные) и
прикладные (специальные) программные продукты.
Базовые
программные
средства
служат
для
автоматизации
взаимодействия человека и компьютера, организации типовых процедур
обработки
технических
данных,
средств
представляет
собой
контроля
СОД.
и
диагностики
Прикладное
совокупность
функционирования
программное
обеспечение
программных
продуктов,
предназначенных для автоматизации решения функциональных задач
информационной
системы.
Они
могут
быть
разработаны
как
универсальные средства (текстовые редакторы, электронные таблицы,
системы управления базами данных) и как специализированные —
реализующие функциональные подсистемы (бизнес-процессы) объектов
различной природы (экономические, инженерные, технические и т. п.).
Техническое обеспечение представляет собой комплекс технических
средств, применяемых для функционирования системы обработки данных,
и включает в себя устройства, реализующие типовые операции обработки
данных как во вне ЭВМ (периферийные технические средства сбора,
регистрации, первичной обработки информации, оргтехника различного
назначения, средства телекоммуникации и связи), так и на ЭВМ различных
классов.
Правовое обеспечение представляет собой совокупность правовых
норм, регламентирующих создание и функционирование информационной
системы. Правовое обеспечение разработки информационной системы
включает нормативные акты договорных взаимоотношений между
заказчиком и разработчиком ИС, правовое регулирование отклонений.
-17Правовое обеспечение функционирования СОД включает: условия
придания юридической силы документам, полученным с применением
вычислительной техники; права, обязанности и ответственность персонала,
в том числе за своевременность и точность обработки информации;
правила пользования информацией и порядок разрешения споров по
поводу ее достоверности и др.
Лингвистическое обеспечение представляет собой совокупность
языковых средств, используемых на различных стадиях создания и
эксплуатации
СОД
для
повышения
эффективности
разработки
и
обеспечения общения человека и ЭВМ.
1.3.3. Организационные компоненты ИС
Под организационными компонентами ИС (см. рис. 1.2) понимается
совокупность методов и средств, позволяющих усовершенствовать
организационную
выполняемые
структуру
структурными
объектов
и
управленческие
подразделениями;
определить
функции,
штатное
расписание и численный состав каждого структурного подразделения;
разработать должностные инструкции персоналу управления в условиях
функционирования СОД.
Выделение
организационных
компонентов
в
самостоятельное
направление обусловливается особой значимостью человеческого фактора
(персонала) в успешном функционировании ИС. Прежде чем внедрять
дорогостоящую систему обработки данных, должна быть проведена
огромная работа по упорядочению и совершенствованию организационной
структуры объекта; в противном случае эффективность ИС будет низкой.
Главная
проблема
при
этом
заключается
в
выявлении
степени
соответствия существующих функции управления и организационной
структуры, реализующей эти функции и стратегию развития фирмы.
-18Средствами достижения цели — совершенствование организационных
структур — являются различные методы моделирования.
Внедрение
информационных
систем
способствует
совершенствованию организационных структур, так как предполагает
определение расчетной, то есть научно-обоснованной, численности
аппарата управления по структурным подразделениям с обязательным
решением таких проблем, как:
 достоверное отнесение каждого работника к соответствующему
структурному подразделению (отделу, бюро и т. д.);
 установление
четких
служебных
обязанностей
каждого
работника в пределах подразделения, в котором он работает.
При этом определение круга обязанностей предполагает, что
обязанности работников, занимающих ту или иную должность,
не зависят от конкретного лица, их исполняющего, и
совокупность совместных обязанностей должна гарантировать
их непротиворечивость и возможность достижения общего
результата;
 определение нормальной загрузки работника поручаемой ему
работой в течение дня и на календарный период;
 разработка должностных инструкций персонала в условиях
функционирования СОД, в частности в условиях аварийных
ситуаций.
1.4. Тенденции развития информационных систем
Эволюция информационных технологий настолько тесно связана с
развитием новых моделей корпоративного бизнеса, что эти процессы
нередко воспринимаются как единое целое. Стремление компаний
повысить эффективность ИС стимулирует появление более совершенных
-19аппаратных
и
программных
средств,
которые,
в
свою
очередь,
подталкивают пользователей к дальнейшей модернизации ИС. Разумеется,
эта
«кольцевая
гонка»
не
является
самоцелью:
благодаря
ей
предприниматели могут более адекватно реагировать на изменение
рыночной конъюнктуры и извлекать максимум прибыли при минимальном
риске.
Логика развития ИС в последние 30 лет наглядно демонстрирует
эффект маятника: централизованная модель обработки данных на базе
мэйнфреймов, доминировавшая до середины 80-х годов, всего за
несколько лет уступила свои позиции распределенной архитектуре
одноранговых локальных вычислительных сетей (ЛВС) персональных
компьютеров, но затем началось возвратное движение к централизации
ресурсов системы. Сегодня в центре внимания оказывается технология
«клиент-сервер», которая эффективно объединяет достоинства своих
предшественников.
Отличительные черты современных ИС, прежде всего иерархическая
организация, в которой централизованная обработка и единое управление
ресурсами ИС на верхнем уровне сочетается с распределенной обработкой
на нижнем, определяются синтезом решений, апробированных в системах
предыдущих поколений. Современные ИС аккумулируют следующие
основные особенности:
 полное использование потенциала настольных компьютеров и
среды распределенной обработки;
 модульное
построение
системы,
предполагающее
существование множества различных типов архитектурных
решений в рамках единого комплекса;
 экономия ресурсов системы (в самом широком понимании этого
термина) за счет централизации хранения и обработки данных
на верхних уровнях иерархии ИС;
-20 наличие эффективных централизованных средств сетевого и
системного администрирования (организации вычислительного
процесса), позволяющих осуществлять сквозной контроль за
функционированием сети и управление на всех уровнях
иерархии, а также обеспечивающих необходимую гибкость и
динамическое изменение конфигурации системы;
 резкое
снижение
так
называемых
«скрытых
затрат»
-
эксплуатационных расходов на содержание ИС, включающих
затраты, трудно выделяемые в явном виде, которые непросто
предусмотреть
в
бюджете
функционирования
сети,
организации
резервное
(поддержание
копирование
файлов
пользователей на удаленных серверах, настройка конфигурации
рабочих станций и подключение их в сеть, обеспечение защиты
данных, обновление версий программного обеспечения и т. д.).
Предполагается, что развитие ИС будет идти по пути одной из трех
моделей: большой, средней или малой (рис. 1.3).
Малая модель
Средняя модель
N
ЛС
ИУК
ИУК
ЛС
ИУК
Базовая
сеть
системы
ЛУК
Центральный узел
концентрации
ИУК
ИУК
ЛС
ПК
Большая модель
ЛС
ЛС
ЛУК
Локальный узел
концентрации
ЛС
ЛС
Подразделения предприятия
Рис. 1.3. Модели организации современных ИС
ЦУК
ЛУК
ЛУК
ЛС
ЛС
-21По логике данных моделей в структуре ИС должны существовать
один или несколько «информационных узлов концентрации» (ИУК),
каждый из которых объединяет аппаратные и программные средства,
предназначенные
для
эффективной
поддержки
работы
конечных
пользователей. С этой же целью в подобных узловых центрах системы
сосредоточивается специализированный персонал, выполняющий функции
системного администрирования, управления сетевыми ресурсами и
технической поддержки.
Конечные пользователи работают в среде локальных сетей, и их
индивидуальные приложения и данные максимально локализуются на
уровне станции клиентов.
Задействование ресурсов узла концентрации происходит только в
относительно редких случаях, например при обращении к корпоративной
базе данных или резервном копировании файлов.
Таким образом, перед нами ярко выраженная модель распределенной
обработки, дополненная новым элементом - узлом концентрации.
Подобную организацию ИС иногда называют централизованной сетью в
противовес децентрализованным сетям ИС третьего поколения.
Кроме
экономии
эксплуатационных
расходов,
модель
ИС
с
централизованной сетевой организацией имеет еще два преимущества:
 возможность эффективной реализации технологии клиентсервер;
 высокую адаптивность к требованиям пользователей за счет
широкого
спектра
вариантов
сочетания
аппаратных
и
программных средств, сосредоточенных в узле концентрации.
В качестве центральной вычислительной системы может быть
использован мэйнфрейм, UNIX-сервер, кластер рабочих станций или
суперкомпьютер.
-22Однако концентрация системы вокруг единственного сервера не
всегда является наилучшим решением.
Во-первых, существуют жесткие ограничения числа клиентов,
подключенных к серверу. Увеличение числа клиентов приводит к
замедлению реакции системы.
Во-вторых, от современных ИС требуется выполнение множества
разноплановых функций, начиная с традиционных бизнес-приложений
типа программ бухгалтерского учета и кончая задачами управления
предприятием в целом (например, оптимальное планирование запускавыпуска изделий или оценка коммерческого риска с использованием
систем искусственного интеллекта).
Естественно, что смешивать весь спектр подобных задач в одном
компьютере зачастую неэффективно, а попытки обойти указанные
ограничения за счет повышения вычислительной мощности центрального
компьютера (точнее, его производительности, пропускной способности
подсистемы ввода-вывода, объема оперативной памяти и т. п.) приводит к
резкому увеличению начальных расходов. Поэтому в большинстве случаев
наиболее рациональным решением представляется иерархическая модель
ИС,
организованная
в
соответствии
со
структурой
предприятия:
центральный сервер системы (центральный офис) - локальные серверы
(подразделения) станции-клиенты (персонал компании). Особенностью
большой модели является наличие сетей двух уровней: базовой сети,
связывающей
информационные
узлы
концентрации,
и
множества
локальных сетей, обеспечивающих пользователям взаимный обмен
данными и доступ к корпоративным ресурсам. Подключение локальных
серверов к центральному компьютеру системы выполняется через сетевые
шлюзы либо через соединение «канал-канал».
-23Основное отличие модели среднего уровня заключается в отсутствии
главного узла концентрации системы - его обязанности распределены
между локальными серверами.
Малая модель является составной частью средней и является «детской
болезнью» современной ИС, корни которой лежат в стремлении в
наибольшей степени сохранить прежние инвестиции в информатизацию
предприятия. Есть основания предполагать, что в течение трех-пяти лет
позиции ИС с более сложной организацией упрочатся. Это подтверждается
следующими обстоятельствами.
1.
Резкое увеличение числа клиентов ИС организаций любого
масштаба в ближайшие годы неизбежно приведет к тому, что центральный
сервер малой модели станет узким местом системы. Дело в том, что
каждый запрос станций-клиентов вызывает многократное увеличение
нагрузки на подсистему ввода-вывода сервера, причем не только со
стороны сетевых интерфейсов (на 1 байт запроса станции приходится от 5
до 7 байт ответного сообщения сервера), но и по каналам внешних
устройств (диски, принтеры и т.д.). Например, простейший запрос к
банковским данным сопровождается семью обращениями к дисковой
памяти. Таким образом, ограничителем ИС, организованной по типу малой
модели,
служит
подсистема
ввода-вывода
сервера,
пропускная
способность которой для всех классов компьютеров достигла зоны
насыщения. Это приведет в ближайшее время к интенсификации процесса
увеличения числа серверов в составе ИС. Для ИС на базе мэйнфреймов это
приведет
к
переходу
на
большую
модель;
а
сетевые
ИС,
сконцентрированные вокруг UNIX-серверов, ожидает трансформация в
среднюю модель.
2.
Сохранение преимущественной ориентации пользователей на
UNIX-серверы вызовет дальнейшее сохранение ИС, базирующихся
исключительно
на
мэйнфреймах.
Это
подтверждается
рыночной
-24стратегией ведущих производителей программного обеспечения, в первую
очередь фирм-разработчиков СУБД (Oracle, Informix, Sybase и др.),
прогнозирующих
резкое
увеличение
продаж
реля-ционных
СУБД,
функционирующих на UNIX-платформах. Однако замена мэйнфреймов на
UNIX-серверы по принципу «один-на-один» не является эквивалентной: в
общем случае для поддержки крупномасштабной ИС, с которой
справляются
мэйнфреймы
старших
моделей
класса
IBM
E/9021,
потребуется несколько UNIX-серверов. Это приведет в конечном итоге к
трансформации малой модели в среднюю или большую модель.
3.
Растущий авторитет технологии клиент-сервер (мировой объем
продаж ППП финансовых предложений на базе этой технологии ежегодно
увеличивается более чем на 50%) предполагает значительные подвижки в
структуре распределенных систем: во-первых, одноранговые сети и сети с
простейшим
файл-сервером
трансформируются
в
иерархические
структуры «станции-клиенты — сервер бизнес-приложении». Во-вторых,
возрастают требования к характеристикам сервера, который, помимо
управления файловой системой и процессами сетевой печати, а также
выполнения других функций администрирования, значительную часть
своих ресурсов и процессорного времени вынужден тратить на обработку
приложений пользователей. Это приведет к замедлению реакции системы
в случае неудачно выбранного сервера. Поэтому для реализации решений
типа клиент-сервер иерархические модели организации ИС с несколькими
информационными узлами концентрации более предпочтительны, чем
малая модель ИС.
4. Повышение интеллектуальности программных средств управления
бизнесом и распространение таких продуктов, как экспертные системы,
системы динамического анализа данных и т. п., способствует внедрению
многоуровневых иерархических ИС. Другими словами, в ближайшие пять
лет можно ожидать увеличения сложности программного обеспечения,
-25предназначенного для ИС масштаба предприятия, следствием чего станет
ужесточение требований к характеристикам серверов. Поэтому внедрение
бизнес-предложений
типа
клиент-сервер
будет
сопровождаться
укреплением позиций средней и большой моделей организации ИС.
Итак, имеются достаточно весомые аргументы в пользу того, что
подавляющая часть ИС предприятий среднего и крупного масштаба в
ближайшие годы будет
большой
моделей.
реорганизована
Единственным
с использованием средней и
ограничением
распространения
рассмотренной полновесной архитектуры современной ИС является
стоимость. Далеко не каждая компания средних размеров может позволить
себе затраты на организацию центрального узла системы. Малая модель
организации современной ИС быстрее всего пойдет по пути использования
в качестве центрального узла мощного UNIX-сервера и рабочих станций –
дешевых сетевых терминалов, что окажется в стоимостном выражении
привлекательным не только для небольших фирм малого бизнеса, но и как
организация
отдельных
фрагментов
иерархических
подсистемы операционного отделения банка.
ИС,
например,
-26-
2. ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ
СИСТЕМ
2.1. Модели жизненного цикла информационных систем
Понятие жизненного цикла (ЖЦ) ИС является одним из базовых в
программной инженерии. Жизненный цикл ИС определяется как период
времени,
который
начинается
с
момента
принятия
решения
о
необходимости создания ИС и заканчивается в момент его полного
изъятия
из
эксплуатации.
регламентирующим
состав
Основным
процессов
нормативным
жизненного
цикла,
международный стандарт ISO/IEC 12207: “Information
Software Life Cycle Processes”.
документом,
является
Technology –
ISO – International Organization for
Standardization – Международная организация по стандартизации, IEC –
International Electrotechnical Commission – Международная комиссия по
электротехнике. Данный стандарт определяет структуру жизненного
цикла, содержащую процессы, действия и задачи, которые должны быть
выполнены во время создания ИС.
На
рис.
2.1.
представлены
этапы
жизненного
цикла
ИС,
отображающие основные процессы проектирования. Процесс определяется
как совокупность взаимосвязанных действий, преобразующих некоторые
входные
данные
в
выходные.
Каждый
процесс
характеризуется
определенными задачами и методами их решения, исходными данными,
полученными от других процессов, и результатами.
-27-
Планирование разработки базы данных
Определение требований к системе
Сбор и анализ требований
пользователей
Проектирование
базы данных
Концептуальное кроектирование
Выбор целевой СУБД
Логическое проектирование
Разработка
приложений
Физическое проектирование
Создание прототипов
Реализация
Конвертирование и загрузка данных
Тестирование
Эксплуатация и сопровождение
Рис. 2.1. Жизненный цикл информационной системы
Взаимосвязи между процессами, соотношение их с этапами ЖЦ ИС
отображаются в модели ЖЦ. Под моделью ЖЦ ИС понимается структура,
определяющая последовательность выполнения и взаимосвязи процессов,
действий и задач на протяжении ЖЦ. Среди моделей ЖЦ можно выделить
следующие:
-28 каскадная (до 70-х годов);
 итерационная (70-80-е годы);
 спиральная (80-90-е годы).
Принципиальной
особенностью
каскадного
подхода
является
следующее: переход на следующий этап осуществляется только после
того, как будет полностью завершена работа на текущем этапе, и возвратов
на пройденные этапы не предусматривается. Каждый этап заканчивается
получением некоторых результатов, которые служат в качестве исходных
данных
для следующего этапа. Каждый этап завершается выпуском
полного комплекта документации, достаточной для того, чтобы разработка
могла быть продолжена другой командой разработчиков. Критерием
качества разработки при таком подходе является точность выполнения
спецификаций технического задания. При этом основное внимание
разработчиков сосредотачивается на достижении оптимальных значений
технических характеристик разрабатываемой ИС: производительности,
объема задаваемой памяти и др.
Преимущества применения каскадного способа заключается в
следующем:
 на каждой стадии формируется законченный набор проектной
документации,
отвечающей
критериям
полноты
и
согласованности;
 выполняемые в логичной последовательности стадии работ
позволяют планировать сроки завершения всех работ и
соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС,
для которых в самом начале разработки можно достаточно точно и полно
сформулировать все требования, с тем чтобы предоставить разработчикам
свободу реализовать их технически как можно лучше. В эту категорию
-29попадают
сложные
системы
с
большим
количеством
задач
вычислительного характера, системы реального времени и др.
В то же время этот подход обладает рядом недостатков, вызванных
прежде всего тем, что реальный процесс создания ИС никогда полностью
не укладывается в такую жесткую схему. Процесс создания ИС носит, как
правило, итерационный характер: результаты очередной стадии часто
вызывают изменения в проектных решениях,
выработанных на более
ранних стадиях. Таким образом, постоянно возникает потребность в
возврате к предыдущим стадиям и уточнении или пересмотре ранее
принятых решений.
Основным недостатком каскадного подхода являются существенное
запаздывание с получением результатов и, как следствие, достаточно
высокий риск создания системы, не удовлетворяющей изменившимся
потребностям пользователей. Практика показывает, что на начальной
стадии проекта полностью и точно сформулировать все требования к
будущей системе не удается. Это объясняется двумя причинами:
 пользователи не в состоянии сразу изложить все
свои
требования и не могут предвидеть, как они изменятся в ходе
разработки;
 за время разработки могут произойти изменения во внешней
среде, которые повлияют на требование к системе.
В рамках каскадного подхода требования к ИС фиксируются в виде
технического задания на все время ее создания, а согласование
получаемых результатов с пользователями производится только в точках,
планируемых после завершения каждой стадии (при этом возможна
корректировка результатов по замечаниям пользователей, если они не
затрагивают требования, изложенные в техническом задании). Таким
образом, пользователи могут внести существенные замечания только после
того, как работа над системой будет полностью завершена. В случае
-30неточного изложения требований или их изменения в течение длительного
периода
создания
ИС
пользователи
получают
систему,
не
удовлетворяющую их потребностям. В результате приходится начинать
новый проект, который может постигнуть та же участь.
Итерационная модель более реально отражает процесс создания ИС
– результаты очередного этапа часто вызывают изменения в проектных
решениях, выработанных на более ранних
этапах. Таким образом,
постоянно возникает потребность в возврате к предыдущим этапами
уточнении или пересмотре ранее принятых решений. Добавление циклов
обратной связи, предложенных в итерационной модели,
в
которых
осуществляются межэтапные корректировки, как это показано на рис. 2.1
обеспечивают большую надежность, хотя и увеличивают весь период
разработки.
В середине 80-х гг. была предложена спиральная модель жизненного
цикла, представленная на рис.2.2.
Ее принципиальной особенностью является следующее: ИС создается
не сразу, как в случае каскадного подхода, а по частям с использованием
метода прототипирования. Под прототипом понимается
действующий
программный компонент, реализующий отдельные функции и внешние
интерфейсы разрабатываемой ИС. Создание прототипов осуществляется в
несколько итераций, или витков спирали. Каждая итерация соответствует
созданию
фрагмента или версии ИС, на ней уточняются
цели и
характеристики проекта, оценивается качество полученных результатов и
планируются
работы следующей итерации. На каждой итерации
производится тщательная оценка риска превышения сроков и стоимости
проекта, чтобы определить необходимость выполнения
еще одной
итерации, степень полноты и точности понимания требований к системе на
начальной стадии, поскольку они уточняются на каждой итерации. Таким
образом, углубляются и последовательно конкретизируются
детали
-31проекта, и в результате выбирается обоснованный вариант, который
доводится до реализации.
Идентификация и
разрешение рисков,
оценка альтернатив
ти
пи
ро
то
П
ро
Ан
ал
из
ри
ск
а
ва
ни
е
Определение целей,
альтернатив и ограничений
Принципы
функционирования
Начало
Анализ
требований
Проектирование
Планирование следующей
итерации
Продукт
Кодирование и
тестирование
Кодирование и
тестирование
Разработка продукта
на очередной
итерации
Рис. 2.2. Спиральная модель жизненного цикла информационной системы
Разработка
итерациями
отражает
объективно
существующий
спиральный цикл создания системы. Неполное завершение работ на
каждой стадии позволяет переходить на следующий этап не дожидаясь
полного завершения работы на текущей. При итеративном способе
-32разработки недостающую работу можно будет выполнить на следующей
итерации. Главная же задача – как можно быстрее показать пользователям
системы работоспособный продукт, тем самым активизируя процесс
уточнения и дополнения требований.
Спиральная модель не исключает использования каскадного подхода
на завершающих стадиях проекта в тех случаях, когда требования к
системе оказываются полностью определенными.
Основная проблема спирального цикла – определение момента
перехода на следующую стадию. Для ее решения необходимо ввести
временные ограничения на каждую из стадий жизненного цикла. Переход
осуществляется
запланированная
в
соответствии
работа
с
закончена.
планом,
План
даже
если
составляется
на
не
вся
основе
статистических данных, полученных в предыдущих проектах, и личного
опыта разработчиков.
Одним из возможных подходов
к разработке
ИС
в
рамках
спиральной модели жизненного цикла является получивший широкое
распространение способ так называемой быстрой разработки приложений,
или RAD (Rapid Application Development). Подход RAD предусматривает
наличие трех составляющих:
 команды разработчиков (от 3 до 7 человек)
должны
представлять собой группу профессионалов, имеющих опыт в
проектировании,
программного
взаимодействовать
программировании
обеспечения,
с
и
тестировании
способных
конечными
хорошо
пользователями
и
трансформировать их предложения в рабочие прототипы,
выполняющих работы по проектированию отдельных подсистем
ПО.
Количество
обусловлено
управляемости коллективом;
требованием
максимальной
-33 короткого, но тщательно проработанного производственного
графика (до 3 месяцев);
 повторяющегося цикла, при котором разработчики по мере того,
как приложение начинает обретать форму, запрашивают и
реализуют в продукте требования, полученные в результате
взаимодействия с заказчиком.
Следует отметить, что подход RAD, как и любой другой не может
претендовать на универсальность. Он хорош в первую очередь
для
относительно небольших проектов, разрабатываемых для конкретного
заказчика.
Если
же
разрабатывается
крупномасштабная
система
(например, масштаба отрасли), которая не является законченным
продуктом, а представляет собой комплекс программных компонентов,
адаптируемых
к
управления базами
программно-аппаратным
данных
платформам,
системам
(СУБД), средствам телекоммуникации,
организационно-экономическим особенностям объектов внедрения и
интегрируемых с существующими разработками, то на первый план
выступают такие показатели проекта, как управляемость и качество,
которые могут войти в противоречие с простотой и скоростью разработки.
Для таких проектов необходимы высокий уровень планирования и жесткая
дисциплина проектирования, строгое следование заранее разработанным
протоколам и интерфейсам, что снижает скорость разработки.
Подход RAD не применим для построения сложных расчетных
программ, операционных систем или программ управления сложными
объектами в реальном масштабе времени, т.е. программ, содержащих
большой объем (сотни тысяч строк) уникального кода.
Не годится подход RAD и для приложений, в которых отсутствует
ярко выраженная интерфейсная часть, наглядно определяющая логику
работы
системы
(например,
приложений
реального
времени),
и
приложений, от которых зависит безопасность людей (например,
-34управление
самолетом
итеративный
подход
или
атомной
электростанцией),
предполагает, что
первые
так
несколько
как
версий
наверняка не будут полностью работоспособны, что в данном случае
исключается.
2.2.
Планирование разработки, определение требований
к ИС и анализ информационных потребностей пользователей
Планирование разработки ИС – это подготовительные действия,
позволяющие с максимально возможной эффективностью реализовать
этапы жизненного цикла ИС.
Планирование разработки ИС состоит в определении трех основных
компонентов:
 определение целей разработки;
 предварительная экономическая оценка проекта;
 построение плана-графика выполнения работ;
 создание и обучение совместной рабочей группы.
Планирование
разработки ИС должно быть связано с общей
стратегией построения ИС организации. Суть этой стратегии заключается
в решении таких основных задач, как:
 определение
бизнес-планов
и
целей
организации
с
последующим выделением ее потребностей в информационных
технологиях;
 оценка показателей уже существующих информационных
систем с целью выявления их сильных и слабых сторон;
 оценка
возможностей
технологий
преимущества.
для
использования
достижения
информационных
конкурентноспособного
-35Планирование разработки ИС также должно включать разработку
стандартов, которые определяют, как будет осуществляться сбор данных,
каким будет их формат, какая потребуется документация и как будет
выполняться проектирование и реализация приложений. Разработка и
сопровождение стандартов могут быть связаны с немалыми затратами
времени, причем на их первоначальное внедрение и следующее
сопровождение могут потребоваться значительные ресурсы. Однако четко
определенный набор стандартов позволяет создать хорошую основу для
последующего обучения персонала и организации контроля качества, а
также гарантировать выполнение работ по строго определенным образцам,
независимо от имеющихся у персонала навыков и опыта.
Например,
специальные правила могут определять, как присваиваются имена
элементам данных, описываемых в словаре данных, что, в свою очередь,
позволит предотвратить их избыточность и противоречивость. Кроме того,
необходимо
тщательно документировать
любые
существующие
юридические или внутренние требования к данным (например, о строгом
соблюдении их конфиденциальности и т.п.).
Определение требований к системе – это проведение обследования
деятельности автоматизируемого объекта (организации) для определения
диапазона действия и границ ИС, состава ее пользователей и областей
применения.
Этот этап, являющийся одним из важнейших, поскольку определяет
успех всего проекта, включает следующие шаги:
1. Предварительное выявление требований к будущей системе;
2. Определение перечня целевых функций организации;
3. Анализ распределения функций по подразделениям и сотрудникам;
4.
Выявление
функциональных
взаимодействий
между
подразделениями, информационных потоков внутри подразделений и
-36между ними, внешних по отношению к организации объектов и внешних
информационных взаимодействий;
5. Анализ существующих средств автоматизации деятельности
организации;
6.
Построение
моделей
деятельности
предусматривающее обработку материалов обследования
организации,
и построение
двух видов моделей:
 модели «как есть», отражающей существующее на момент
обследование положение дел в организации и позволяющий
понять, каким образом функционирует данная организация, а
так же выявить узкие места и сформулировать предложения по
улучшению ситуации;
 модели «как должно быть», отражающей представление о новых
технологиях работы организации.
Каждая из моделей включает в себя полную функциональную и
информационную модель деятельности организации, а также, в случае
необходимости, модель, описывающую динамику поведения организации.
Переход от модели «как есть» к модели «как должно быть» может
выполняться двумя способами:
 совершенствованием существующих технологий на основе их
эффективности;
 радикальным изменением технологий и перепроектирование
бизнес-процессов (реинжениринг бизнес-процессов).
Проектирование
ИС
основано
на
информации
о
той
части
организации, которая будет обслуживаться ИС. Необходимая для
проектирования ИС
информация может быть собрана следующими
способами:
посредством
опроса отдельных
сотрудников
предприятия,
особенно специалистов в наиболее важных областях ее деятельности;
-37 с помощью наблюдений за деятельностью предприятия;
 посредством изучения документов,
особенно тех,
которые
используют для сбора или представления информации;
 с помощью анкет, предназначенных для сбора информации у
широкого круга пользователей;
 за счет использования опыта проектирования других подобных
систем.
Требование - некоторая функция, которая должна быть включена в
создаваемую систему.
Собранная информация о каждой важной области применения ИС и
пользовательской группе должна включать следующие компоненты:
используемую и генерируемую документацию, подробные сведения о
выполняемых транзакциях, а также список требований с указанием их
приоритетов. На основании всей этой информации будут составлены
спецификации требований пользователей, возможно, в виде набора
документов, описывающих деятельность предприятия с разных точек
зрения.
Сбор и анализ требований является и предварительным этапом
концептуального
спецификации
проектирования
требований
базы
данных,
пользователей
в
ходе
анализируются
которого
с
целью
выяснения всех необходимых подробностей. Объем собранных данных
зависит от сути проблемы и действующих бизнес-правил организации.
Слишком тщательный анализ легко может привести к параличу
сверханализа (paralysis by analysis), а слишком поверхностный анализ — к
пустой трате времени и денежных средств на проведение работ по
реализации решения, которое окажется ошибочным в
результате
неправильной формулировки проблемы.
Собранная на этом этапе
структурирована
и
включать
информация
некоторые
может быть
неформальные
плохо
заявления
-38пользователей, которые впоследствии потребуется преобразовать и
представить в виде более четко сформулированных требований. Эта цель
достигается с помощью методов составления спецификаций требований, к
числу которых относятся, например:
 технология структурного анализа и проектирования (Structured
Analysis and Design — SAD),
 диаграммы потоков данных (Data Flow Diagrams — DFD),
 графики "вход-процесс-выход" (Hierarchical Input Process Output
— HIPO), дополненные соответствующей документацией.
Для получения гарантий того, что составленный набор требований
является полным
и непротиворечивым,
могут использоваться САSЕ-
инструменты, предназначенные для автоматизированного проектирования
и создания программ.
Определение набора требуемых функциональных возможностей ИС
является
критически
важным
действием,
поскольку
системы
с
неадекватной или неполной функциональностью будут лишь раздражать
пользователей, что может привести к частичному и малоэффективному
использованию ИС и даже к полному отказу от эксплуатации системы.
Однако чрезмерно увеличенный набор функциональных возможностей
также может стать источником проблем, поскольку вызовет существенное
усложнение системы и, как следствие, дополнительные затруднения в ее
реализации, сопровождении, использовании и обучении персонала.
2.3. Проектирование базы данных, выбор целевой СУБД
и проектирование пользовательского интерфейса
Проектирование базы данных – это процесс создания проекта базы
данных, предназначенной для поддержки функционирования предприятия
и способствующий достижению его целей.
-39Основными целями проектирования базы данных являются:
 представление данных и связей между ними, необходимых для
всех основных областей применения данного приложения и
любых существующих групп его пользователей;
 создание модели данных, способной поддерживать выполнение
любых требуемых транзакций обработки данных;
 разработка предварительного варианта проекта, структура
которого позволяет удовлетворить все основные требования,
предъявляемые к производительности системы — например, ко
времени реакции системы.
К сожалению, эти цели легко достижимы далеко не всегда, и в
некоторых случаях приходится идти на компромисс — например, для
достижения
приемлемого
уровня
производительности
системы.
Существует два основных подхода к проектированию систем баз данных:
"нисходящий"
и
"восходящий".
При
восходящем
подходе
работа
начинается с самого нижнего уровня — уровня определения атрибутов
(т.е. свойств сущностей), которые на основе анализа существующих между
ними связей группируются в отношения, представляющие типы сущностей
и связи между ними. Процесс нормализации представляет собой вариант
восходящего подхода при проектировании баз данных. Нормализация
предусматривает идентификацию требуемых атрибутов с последующим
созданием
из
них
нормализованных
таблиц,
основанных
на
функциональных зависимостях между этими атрибутами.
Восходящий подход лучше всего подходит для проектирования
простых баз данных с относительно небольшим количеством атрибутов.
Однако использование этого подхода существенно усложняется при
проектировании
установить
баз
среди
данных
которых
с
все
большим
количеством
существующие
атрибутов,
функциональные
зависимости довольно затруднительно. Поскольку концептуальная и
-40логическая модели данных для сложных баз данных могут содержать от
сотен до тысяч атрибутов, очень важно выбрать подход, который помог бы
упростить этап проектирования. Кроме того, на начальных стадиях
формулирования требований к данным в крупной базе данных может быть
трудно установить все атрибуты, которые должны быть включены в
модели данных.
Более подходящей стратегией проектирования сложных баз данных
является использование нисходящего подхода. Начинается этот подход с
разработки
моделей
данных,
которые
содержат
несколько
высокоуровневых сущностей и связей, затем работа продолжается в виде
серии нисходящих уточнений низкоуровневых сущностей, связей и
относящихся к ним атрибутов. Нисходящий подход демонстрируется в
концепции модели «сущность-связь». В этом случае работа начинается с
идентификации сущностей и связей между ними, интересующих данную
организацию в наибольшей степени.
Помимо этих подходов, для проектирования баз данных могут
применяться другие подходы, например, подход типа "изнутри наружу"
или "смешанная стратегия проектирования». Подход типа "изнутри
наружу" похож на восходящий подход, но отличается от него начальной
идентификацией
набора
основных
сущностей
с
последующим
расширением круга рассматриваемых сущностей, связей и атрибутов,
которые взаимодействуют с первоначально определенными сущностями. В
смешанной стратегии сначала восходящий и нисходящий подходы
используются для разных частей модели, после чего все подготовленные
фрагменты собираются в единое целое.
Концептуальное проектирование базы данных – это процесс
создания модели используемой на предприятии информации, не зависящей
от любых физических аспектов ее представления.
-41Первая фаза процесса проектирования базы данных называется
концептуальным проектированием базы данных. Она заключается в
создании концептуальной модели данных для анализируемой части
предприятия. Эта модель данных создается на основе информации,
записанной в спецификациях требований пользователей. Концептуальное
проектирование базы данных абсолютно не зависит от таких подробностей
ее реализации, как тип выбранной целевой СУБД, набор создаваемых
прикладных программ, используемые языки программирования, тип
выбранной вычислительной платформы, а также от любых других
особенностей физической реализации. При разработке концептуальная
модель данных постоянно подвергается тестированию и проверке на
соответствие требованиям пользователей. Созданная концептуальная
модель данных предприятия является источником информации для фазы
логического проектирования базы данных.
Логическое проектирование базы данных – это процесс создания
модели используемой на предприятии ин проектирование формации с
учетом выбранной модели организации данных, но базы данных
независимо от типа целевой СУБД и других физических аспектов
реализации.
Вторая фаза проектирования базы данных называется логическим
проектированием базы данных. Ее цель состоит в создании логической
модели данных для исследуемой части предприятия. Концептуальная
модель
данных,
созданная
на
предыдущем
этапе,
уточняется
и
преобразуется в логическую модель данных. Логическая модель данных
учитывает особенности выбранной модели организации данных в целевой
СУБД (например, реляционная или сетевая модель).
Если концептуальная модель данных не зависит от любых физических
аспектов реализации, то логическая модель данных создается на основе
выбранной модели организации данных целевой СУБД. Иначе говоря, на
-42этом этапе уже должно быть известно, какая СУБД будет использоваться в
качестве целевой — реляционная, сетевая, иерархическая или объектноориентированная. Однако на этом этапе игнорируется все остальные
аспекты выбранной СУБД — например, любые особенности физической
организации ее структур хранения данных и построения индексов.
В процессе разработки логическая модель данных постоянно
тестируется и проверяется на соответствие требованиям пользователей.
Для проверки корректности логической модели данных используется
метод нормализация. Нормализация гарантирует, что выведенные из
существующей
модели
данных
отношения
не
будут
обладать
избыточностью данных, способной вызвать аномалии обновления после их
физической реализации. Помимо всего прочего, логическая модель данных
должна обеспечивать поддержку всех необходимых пользователям
транзакций.
Построенная
логическая
модель
данных
является
источником
информации для этапа физического проектирования и обеспечивает
разработчика
физической
базы
данных
средствами
нахождения
компромиссов, необходимых для достижения поставленных целей, что
очень важно для эффективного проектирования. Логическая модель
данных также играет важную роль на этапе эксплуатации и сопровождения
уже готовой системы. При правильно организованном сопровождении
поддерживаемая в актуальном состоянии модель данных позволяет точно
и наглядно представить любые вносимые в базу данных изменения, а
также оценить их влияние на прикладные программы и использование
данных, уже имеющихся в базе.
Концептуальное и логическое проектирование — это итеративные
процессы, которые начинаются в определенный момент времени и
продолжаются в виде практически бесконечного ряда уточнений и
улучшений. Их следует рассматривать как некий процесс изучения. По
-43мере
углубления
разработчиками
понимания
принципов
работы
предприятия и смысла используемых данных, они выражают это
понимание в виде той или иной модели данных. Собранная информация, в
свою очередь, может потребовать внесения определенных изменений в
другие части создаваемого проекта.
Концептуальное и логическое проектирование базы данных —
важнейшие факторы общего успеха разрабатываемой системы. Если
созданный проект не является точным отражением методов работы и
структуры предприятия, то будет очень сложно, если вообще возможно,
определить все необходимые пользователям представления (внешние
схемы) или организовать поддержку целостности базы данных. Кроме
того, могут возникнуть трудности с физической реализацией базы данных
или обеспечением приемлемой производительности системы. В то же
время способность адаптации к изменениям является признаком удачно
спроектированной базы данных. Следовательно, всегда имеет смысл
потратить необходимые время и энергию на создание наилучшего из
возможных проектов.
Логическая модель, отражающая особенности представления о
функционировании
предприятия
одновременно
многих
типов
пользователей, называется глобальной логической моделью данных.
Существует два основных подхода к созданию глобальной логической
модели данных предприятия — это централизованный подход и подход на
основе интеграции представлений.
Централизованный подход – это слияние требований отдельных
пользователей, выраженных в
виде
различных
пользовательских
представлений, в единый набор требований всех пользователей, который
используется для создания глобальной логической модели данных.
При использовании первого подхода, который принято называть
централизованным, требования всех существующих типов пользователей в
-44отношении различных областей применения приложения объединяются с
образованием единого списка требований. Характерной особенностью
этого подхода является то, что списки требований составляются до
создания глобальной логической модели данных. Этот подход применим
только при условии, что описываемая база данных не слишком велика или
сложна.
Метод интеграции представлений – это слияние отдельных
локальных логических моделей данных, отражающих представления
различных групп пользователей, в единую глобальную логическую модель
данных.
При использовании второго подхода, который принято называть
методом интеграции представлений, осуществляется слияние отдельных
моделей
данных,
отражающих
представлениях
разных
групп
пользователей и называемых локальными логическими моделями данных,
в единую глобальную логическую модель данных всего предприятия. Этот
подход
более
управляем,
поскольку
вся
работа
предварительно
разделяется на более мелкие и легко контролируемые части. Трудности
обычно возникают лишь при попытках слияния локальных моделей
данных, созданных разными разработчиками, которые могут использовать
различные термины для одного и того же понятия или, наоборот,
связывать один и тот же термин с разными понятиями.
Физическое проектирование базы данных – это процесс создания
описания
реализации
базы
данных
на
вторичных
запоминающих
устройствах с указанием структур хранения и методов доступа,
используемых для организации эффективной обработки данных.
Физическое
проектирование
является
третьей
фазой
процесса
создания проекта базы данных, при выполнении которой проектировщик
принимает решения о способах реализации разрабатываемой базы данных.
Во время предыдущей фазы проектирования была определена логическая
-45структура базы данных (т.е. набор ее сущностей, связей и атрибутов). Хотя
эта структура не зависит от конкретной целевой СУБД, она создавалась с
учетом выбранной модели хранения данных, например реляционной,
сетевой
или
иерархической.
Однако,
приступая
к
физическому
проектированию базы данных, прежде всего, необходимо выбрать
конкретную
целевую
СУБД.
Поэтому
физическое
проектирование
неразрывно связано с конкретной СУБД. Между логическим и физическим
проектированием существует постоянная обратная связь, так как решения,
принимаемые на этапе физического проектирования с целью повышения
производительности системы, способны повлиять на структуру логической
модели данных.
Вообще, основной целью физического проектирования базы данных
является описание способа физической реализации логического проекта
базы данных. В случае реляционной модели данных под этим
подразумевается следующее:
 создание набора реляционных таблиц и ограничений для них на
основе информации, представленной в глобальной логической
модели данных;
 определение конкретных структур хранения данных и методов
доступа
к
ним,
обеспечивающих
оптимальную
производительность системы с базой данных;
 разработка средств защиты создаваемой системы.
В идеале, фазы концептуального и логического проектирования
больших систем следует отделять от фазы их физического проектирования.
На это есть несколько причин:
 они связаны с совершенно разными аспектами системы: что
делать и как делать;
 они выполняются в разное время, поскольку понять, что надо
сделать, следует прежде, чем решить, как это сделать;
-46 они требуют совершенно разных навыков и умений, которыми
обычно обладают разные люди.
Выбор целевой системы управления базой данных(СУБД) – это
выбор СУБД подходящего типа, предназначенной для поддержки
создаваемого приложения базы данных.
Если тип используемой СУБД еще не выбран, то наиболее
подходящим
местом
для
осуществления
такого
выбора
является
промежуточное положение между концептуальной и логической фазами
проектирования базы данных. Однако этот выбор можно осуществить и в
любой другой момент до начала логического проектирования, при
условии, что имеется вся необходимая информация о таких общих
требованиях к системе, как производительность, простота реорганизации,
уровень защищенности и ограничения целостности данных.
Цель данного этапа заключается в выборе системы, удовлетворяющей
как текущим, так и будущим требованиям организации, при оптимальном
уровне
затрат,
включающих
расходы
на
приобретение
СУБД
и
дополнительного аппаратного и программного обеспечения, а так же
расходы, связанные с переходом к новой системе и необходимостью
переобучения персонала.
Простейший
выполнение
подход
оценки
функциональные
к
того,
выбору
нужной
насколько
возможности
СУБД
предполагает
предоставляемые
удовлетворяют
СУБД
существующим
требованиям. Однако на практике обычно используются более сложные
методы. В процессе выбора новой СУБД разработчик должен убедиться в
том, что вся процедура хорошо спланирована, а выбранная система
действительно будет обладать достоинствами, способными принести
организации реальные выгоды.
Основными этапами процедуры выбора СУБД являются:
 определение области компетенции проводимого изучения;
-47 сокращение списка претендентов до двух-трех продуктов;
 оценка продуктов;
 проведение обоснованного выбора и подготовка отчета.
Разработка
приложений
–
это
проектирование
интерфейса
пользователя и прикладных программ, предназначенных для работы с
базой данных.
В жизненном цикле информационной системы проектирование базы
данных и приложений выполняется параллельно. В большинстве случаев
проектирование
проектирования
приложений
базы
нельзя
данных.
С
завершить
другой
до
стороны,
окончания
база
данных
предназначена для поддержки приложений, а потому между фазами
проектирования базы данных и проектирования приложений для этой базы
данных должен постоянно происходить обмен информацией.
Необходимо убедиться, что все функциональные возможности,
предусмотренные
в
спецификациях
обеспечиваются
интерфейсом
требований
пользователя
пользователей,
соответствующих
приложений. Это относится как к проектированию прикладных программ
доступа к информации в базе данных, так и к проектированию транзакций,
т.е. проектированию методов доступа к базе данных.
Помимо проектирования способов, с помощью которых пользователь
сможет
получить
возможностям,
доступ
следует
к
необходимым
также
ему
разработать
функциональным
соответствующий
пользовательский интерфейс приложений базы данных. Этот интерфейс
должен предоставлять необходимую пользователю информацию самым
удобным для него образом. При всей своей важности, проектирование
интерфейсов
пользователей
порой
просто
игнорируется
или
же
оставляется на самые поздние этапы разработки. Однако следует признать,
что пользовательские интерфейсы являются одним из важнейших
компонентов системы. Если интерфейс легко осваивается персоналом,
-48прост в использовании, интуитивно понятен и устойчив к ошибкам, то
пользователи легко научатся извлекать пользу из представленной в нем
информации. В то же время, если интерфейс лишен указанных качеств, то
работа с такой системой неизбежно будет сопровождаться теми или иными
проблемами.
2.4. Реализация проекта ИС
Прототип ИС — это рабочая модель ИС, которая обычно обладает
лишь
частью
требуемых
возможностей
и
не
обеспечивает
всей
функциональности готовой системы. Прототип ИС создается для того,
чтобы дать пользователям возможность опробовать его в работе и
определить, какие из функциональных средств системы отвечают своему
назначению, а какие — нет. В последнем случае пользователям
предлагается указать (если это возможно), какие улучшения или даже
совершенно новые функции желательно реализовать в данном приложении
базы данных. Таким образом, прототип представляет собой инструмент,
позволяющий
в
значительной
степени
прояснить
требования
пользователей как для самих пользователей, так и для разработчиков
системы, а также оценить гибкость разработанного проекта ИС. Основное
преимущество прототипов состоит в относительной дешевизне и быстроте
их создания. Схема этапов разработки прототипов показана на рис. 2.3.
-49-
Проектирование рабочей
модели
Отказ от приложений
Создание прототипа
Реализация
приложения
Принятие
решения
Использование и
тестирование прототипа
Переработка
приложения
Анализ результатов
использования
прототипа
Создание нового
прототипа
Рис. 2.3. Этапы разработки прототипа системы
В результате выполнения всех этапов проектирования (которые могут
включать или не включать создание прототипов) будет подготовлено все,
что необходимо для реализации базы данных и прикладных программ.
Реализация базы данных осуществляется посредством создания ее
описания на языке определения данных (DDL) целевой СУБД. Команды
DDL-языка компилируются и используются для создания схем и пустых
файлов базы данных. На этом же этапе определяются и все специфические
пользовательские представления.
Прикладные программы реализуются с помощью языков третьего или
четвертого поколения. Некоторые элементы этих прикладных программ
будут
представлять
собой
транзакции
обработки
базы
данных,
записываемые на языке манипулирования данными (DML) целевой СУБД
и вызываемые из программ на базовом языке программирования —
например, на Visual Basic, Delphi, С, C++, Java, Pascal. Кроме того, на этом
-50этапе создаются другие компоненты проекта приложения — например,
экраны меню, формы ввода данных и отчеты. Следует учитывать, что
многие существующие СУБД имеют свои собственные инструменты
разработки
четвертого
поколения,
позволяющие
быстро
создавать
приложения с помощью непроцедурных языков запросов, разнообразных
генераторов
отчетов,
генераторов
форм,
генераторов
графических
изображений и генераторов приложений.
На этом этапе реализуются также используемые приложением
средства защиты базы данных и поддержки ее целостности. Одни из них
описываются с помощью языка DDL целевой СУБД, а другие, возможно,
потребуется определить иными средствами — например, с помощью
дополнительных утилит СУБД или посредством создания прикладных
программ, реализующих требуемые функции.
Конвертирование и загрузка данных – это перенос любых
существующих данных в новую базу данных и модификация любых
существующих приложений с целью организации совместной работы с
новой ИС.
Этот этап выполняется только в том случае, если новая ИС заменяет
собой старую. В настоящее время любая СУБД имеет утилиту загрузки
уже существующих файлов в новую БД. Этой утилите обычно требуется
предоставить спецификацию файла-источника и целевой БД, после чего
она автоматически преобразует данные в нужный формат файлов новой
БД. Если только это возможно, разработчику следует преобразовать все
имеющиеся приложения старой системы для использования их в новой
системе. Всякий раз, когда требуется выполнить преобразование и
загрузку данных, этот процесс следует тщательно планировать с целью
обеспечения гладкого перехода системы в состояние полной готовности.
Тестирование - процесс выполнения прикладных программ с целью
поиска ошибок.
-51Прежде чем использовать новую систему на практике, ее следует
тщательно протестировать. Этого можно добиться путем разработки
продуманной стратегии тестирования с использованием реальных данных,
которая должна быть построена таким образом, чтобы весь процесс
тестирования
выполнялся
строго
последовательно
и
методически
правильно. Обратите внимание на то, что в нашем определении
тестирования не приведена распространенная точка зрения о том, что это
есть
процесс
демонстрации
отсутствия
ошибок.
На
самом
деле
тестирование вряд ли сможет продемонстрировать отсутствие ошибок в
программном обеспечении — скорее, наоборот, оно способно лишь
показать их наличие. Если тестирование проведено успешно, оно
обязательно вскроет имеющиеся ошибки в прикладных программах и,
возможно, в структурах базы данных. В качестве побочного результата
тестирование может лишь продемонстрировать, что база данных и
прикладные программы, по-видимому, работают в соответствии с их
спецификациями и при этом удовлетворяют существующим требованиям,
предъявляемым к производительности. Кроме того, сбор статистических
данных на стадии тестирования позволяет установить показатели
надежности и качества созданного программного обеспечения.
Как и при проектировании баз данных, пользователи новой системы
должны быть вовлечены в процесс ее тестирования. В идеале,
тестирование системы должно проводиться на отдельном комплекте
оборудования, но зачастую это просто невозможно. При использовании
реальных данных важно предварительно создать их резервные копии, на
случай их повреждения в результате ошибок. По завершении тестирования
процесс создания прикладной системы считается законченным и она
может быть передана пользователям в промышленную эксплуатацию.
-52Для оценки законченности и корректности выполнения проекта ИС
может использоваться несколько различных стратегий тестирования.
Основные из них перечислены ниже:
 нисходящее тестирование;
 восходящее тестирование;
 тестирование потоков;
 интенсивное тестирование.
Каждая из перечисленных выше стратегий тестирования обладает и
недостатками, и достоинствами. При тестировании больших систем
обычно используется набор из нескольких подобных стратегий. Разные
стратегии могут использоваться для разных частей системы и на разных
этапах общего процесса тестирования.
При
тестировании
системы
целесообразно
применить
последовательный подход. Иначе говоря, систему лучше тестировать не
как единое целое, образованное совокупностью всех ее модулей, а по
частям. Этот процесс следует продолжать до тех пор, пока все
протестированные модули не образуют полностью готовую систему.
Таким образом, при обнаружении ошибки проблема может быть
локализована
вплоть
до
последнего
добавленного
модуля
и
его
интерфейсов.
Нисходящее тестирование начинается на уровне подсистем с
модулями,
которые
представлены
заглушками,
т.е.
простыми
компонентами, имеющими такой же интерфейс, как модуль, но без
функционального кода. Каждый модуль низкого уровня представляется
заглушкой. В конечном итоге все программные компоненты заменяются
фактическим кодом и снова тестируются. Преимуществом этого подхода
является то, что ошибки проектирования могут быть обнаружены еще на
ранней стадии тестирования, что позволяет исключить дорогостоящие
работы по повторному проектированию и реализации. Кроме того, уже на
-53ранней стадии создания можно получить работающую систему, хотя и с
ограниченной
функциональностью,
способную
продемонстрировать
гибкость выбранной схемы. Недостатком этой стратегии тестирования
является необходимость создания многочисленных заглушек модулей для
моделирования низкоуровневых компонентов системы. Кроме того,
проверка выходных данных на более высоких уровнях системы может
быть затруднена, и система на самом деле не выдаст никаких выходных
данных, если не организовать их выдачу искусственным путем.
Восходящее
направлении
по
тестирование
выполняется
отношению
нисходящему.
к
в
противоположном
Оно
начинается
с
тестирования модулей на самых низких уровнях иерархии системы,
продолжается на более высоких и заканчивается на самом высоком уровне.
Преимущества
и
недостатки
при
этом
имеют
обратный
смысл
преимуществ и недостатков, которыми обладает стратегия нисходящего
тестирования.
Тестирование потоков — это стратегия тестирования систем,
работающих в реальном масштабе времени, которые обычно состоят из
большого количества взаимодействующих процессов, управляемых с
помощью прерываний. Эти системы довольно трудно тестируются,
поскольку взаимодействие
процессов
системы зависит от времени.
Стратегия тестирования потоков направлена на слежение за отдельными
процессами. При этом "поток" обработки каждого внешнего события
"проходит" через различные системные процессы. Данная стратегия
включает идентификацию и выполнение каждого возможного "потока"
обработки в системе. Однако выполнить исчерпывающее тестирование
потоков системы просто нереально из-за огромного количества возможных
комбинаций входных и выходных условий.
Некоторые системы создаются с целью работы в конкретных режимах
максимальной или минимальной нагрузки. Стратегия интенсивного
-54тестирования предназначена для проверки возможности системы
справляться с запланированной нагрузкой. Такое тестирование часто
включает серию тестов с постепенно возрастающей нагрузкой и
продолжается до тех пор, пока система не выйдет из строя. Эта стратегия
обладает двумя основными преимуществами: она проверяет поведение
системы, а также оказывает давление на систему, вызывая появление
сбоев, которые не могли бы быть обнаружены в обычных условиях
эксплуатации.
Эксплуатация и сопровождение – это наблюдение за системой и
поддержка
ее
нормального
функционирования
по
окончании
развертывания.
На предыдущих этапах
ИС была полностью реализована и
протестирована. Теперь система входит в последний этап своего
жизненного цикла, называемый эксплуатацией и сопровождением. Он
включает выполнение таких действий, как:
 контроль
производительности
производительность
может
системы.
падает ниже
потребоваться
Если
приемлемого уровня,
дополнительная
настройка
то
или
реорганизация базы данных;
 сопровождение и модернизация (в случае необходимости) ИС.
Новые требования включаются в приложение базы данных при
повторном выполнении предыдущих этапов жизненного цикла.
Как только ИС будет полностью готова к использованию, следует
организовать тщательный контроль за его функционированием — это
позволит убедиться, что производительность и другие эксплуатационные
показатели постоянно находятся на приемлемом уровне. Типичная СУБД
обычно предоставляет различные утилиты администрирования базы
данных,
включая
утилиты
загрузки
данных
и
контроля
за
функционированием системы. Подобные утилиты способны отслеживать
-55работу системы и предоставлять информацию о различных показателях,
таких как уровень использования базы данных, эффективность системы
блокировок (включая сведения о количестве имевших место взаимных
блокировок), а также выбираемые стратегии выполнения запросов.
Администратор базы данных (АБД) может использовать эту информацию
для настройки системы с целью повышения ее производительности
(например,
за счет создания дополнительных индексов),
ускорения
выполнения запросов, изменения структур хранения, объединения или
разбиения отдельных таблиц.
Процесс мониторинга должен поддерживаться на протяжении всей
жизни ИС, что позволит в любой момент времени провести эффективную
реорганизацию ИС с целью удовлетворения изменяющихся требований.
Подобные изменения предоставляют информацию о наиболее вероятной
эволюции системы и ресурсах, которые могут потребоваться в будущем.
Все это, вместе со сведениями о новых приложениях, предложенных для
реализации, позволяет АБД принимать активное участие в планировании
производственных мощностей и предоставлять руководству предприятия
сведения
о
необходимости
соответствующей
корректировки
существующих планов. Если в используемой СУБД нет некоторых нужных
утилит, то АБД придется либо разработать их самостоятельно, либо
приобрести
требуемые
дополнительные
инструменты
у
сторонних
разработчиков, если таковые имеются.
После введения новой ИС в эксплуатацию пользователи должны в
течение некоторого времени работать с новой и старой системами
параллельно. Это необходимо для подстраховки выполнения текущих
операций в случае возникновения непредвиденных проблем с новой
системой. Целесообразно также периодически проводить проверки
непротиворечивости состояния данных в двух системах. От старой
системы можно отказаться только тогда, когда обе системы достаточно
-56продолжительное время будут согласованно показывать одни и те же
результаты. Если замена старой системы новой будет выполнена слишком
поспешно,
результаты
подобной
замены
могут
оказаться
катастрофическими. Вопреки высказанному выше предположению, что
через некоторое время от старой системы можно будет отказаться, могут
возникать и такие ситуации, когда потребуется постоянно сопровождать
обе системы.
-57-
3. СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
ИС
3.1.
Понятие метода и технологии проектирования
Методы и инструментальные средства проектирования (CASEсредства) являются основой проекта любой ИС. Метод проектирования
представляет собой организованную совокупность процессов создания
ряда моделей, которые описывают различные аспекты разрабатываемой
системы с использованием четко определенной нотации.
В качестве концепций и теоретических основ метода проектирования
могут выступать структурный или объектно-ориентированный подход. В
качестве нотаций, используемых для построения моделей статистической
структуры и динамики поведения проектируемой системы обычно
используются графические диаграммы, поскольку они наиболее наглядны
и просты в восприятии (диаграммы потоков данных и диаграммы
«сущность-связь» для структурного подхода, диаграммы вариантов
использования, диаграммы классов и др. – для объектно-ориентированного
подхода).
Методы
реализуются
через
конкретные
технологии
и
поддерживающие их методики, стандарты и инструментальные средства,
которые обеспечивают выполнение процессов жизненного цикла ИС.
Технология проектирования ИС определяется как совокупность
технологических операций проектирования в их последовательности и
взаимосвязи, приводящая к разработке проекта ИС. Современная
технология проектирования должна обеспечивать:
 поддержку всех процессов жизненного цикла;
-58 гарантированное достижение целей разработки ИС в рамках
установленного
бюджета,
с
заданным
качеством
и
в
установленное время;
 возможность декомпозиции проекта на составные части,
разрабатываемые
группами
исполнителей
ограниченной
численности (3-7 человек), - с последующей интеграцией
составных частей;
 минимальное время получения работоспособной ИС. Речь идет
не о сроках готовности всей ИС, а о сроках реализации
отдельных подсистем.
Реализация ИС в целом в короткие сроки может потребовать
привлечения большого числа разработчиков. При этом эффект может
оказаться ниже, чем при реализации в более короткие сроки отдельных
подсистем меньшим числом разработчиков. Практика показывает, что
даже при наличии полностью завершенного проекта внедрение ИС
зачастую идет последовательно по отдельным подсистемам;
 независимость получаемых проектных решений от средств
реализации ИС (СУБД, операционных систем, языков и систем
программирования);
 поддержка
комплексом
согласованных
CASE-средств,
обеспечивающих автоматизацию процессов, выполняемых на
всех стадиях ЖЦ.
3.2. Сущность структурного подхода
Главной проблемой, которую приходится решать при создании
больших и сложных систем любой природы, в том числе и ИС является
проблема сложности Ни один разработчик не в состоянии выйти за
пределы человеческих возможностей и понять всю систему в целом.
-59Единственный эффективный подход к решению этой проблемы, который
выработало человечество за всю свою историю, заключается в построении
сложной системы из небольшого количества крупных частей, каждая из
которых, в свою очередь, строится из частей меньшего размера и т. д., до
тех пор, пока самые небольшие части можно будет строить из имеющегося
материала. Этот подход известен под самыми разными названиями, среди
них такие, как "разделяй и властвуй" (divide et impera), иерархическая
декомпозиция и др. По отношению к проектированию сложной системы
это означает, что ее
необходимо разделять (декомпозировать) на
небольшие подсистемы, каждую из которых можно разрабатывать
независимо от других. Это позволяет при разработке подсистемы любого
уровня держать в уме информацию только о ней, а не обо всех остальных
частях системы. Правильная декомпозиция является главным способом
преодоления
сложности
разработки
больших
систем.
Понятие
"правильная" по отношению к декомпозиции означает следующее:
 количество связей между отдельными подсистемами должно
быть минимальным;
 связность отдельных частей внутри каждой подсистемы должна
быть максимальной.
Структура системы должна быть таковой, чтобы все взаимодействия
между ее подсистемами укладывались в ограниченные, стандартные
рамки:
 каждая подсистема должна инкапсулировать свое содержимое
(скрывать его от других подсистем);
 каждая
подсистема
должна
иметь
четко
определенный
интерфейс с другими подсистемами.
Инкапсуляция
позволяет
рассматривать
структуру
каждой
подсистемы независимо от других подсистем. Интерфейсы позволяют
-60строить систему более высокого уровня, рассматривая каждую подсистему
как единое целое и игнорируя ее внутреннее устройство.
На сегодняшний день в программной инженерии существуют два
основных подхода к разработке ИС, принципиальное различие между
которыми обусловлено разными способами декомпозиции систем. Первый
подход называют функционально-модульным или структурным. В его
основу положен принцип функциональной декомпозиции, при которой
структура системы описывается в терминах иерархии ее функций и
передачи информации между отдельными функциональными элементами.
Второй,
объектно-ориентированный
подход
использует
объектную
декомпозицию. При этом структура системы описывается в терминах
объектов и связей между ними, а поведение системы описывается в
терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ИС заключается в
его декомпозиции (разбиении) на автоматизируемые функции: система
разбивается на функциональные подсистемы, которые, в свою очередь,
делятся на подфункции, те — на задачи и так далее до конкретных
процедур. При этом автоматизируемая система сохраняет
целостное
представление, в котором все составляющие компоненты взаимоувязаны.
При разработке системы "снизу
вверх", от отдельных задач ко всей
системе, целостность теряется, возникают проблемы при описании
информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода
базируются на ряде общих принципов. Базовыми принципами являются:
 принцип "разделяй и властвуй;
 принцип иерархического упорядочения — принцип организации
составных частей системы в иерархические древовидные
структуры с добавлением новых деталей на каждом уровне.
-61Выделение двух базовых принципов не означает, что остальные
принципы являются второстепенными, поскольку игнорирование любого
из них может привести к непредсказуемым последствиям (в том числе и к
провалу всего проекта). Основными из этих принципов являются:
 принцип абстрагирования — выделение существенных аспектов
системы и отвлечение от несущественных;
 принцип
непротиворечивости
—
обоснованность
и
согласованность элементов системы;
 принцип структурирования данных — данные должны быть
структурированы и иерархически организованы.
В структурном подходе используются в основном две группы
средств, описывающих функциональную структуру системы и отношения
между данными. Каждой группе средств соответствуют определенные
виды моделей (диаграмм), наиболее распространенными среди которых
являются:
· DFD (Data Flow Diagrams) — диаграммы потоков данных;
· SADT
(Structured
Analysis
and
Design
Technique
—
метод
структурного анализа и проектирования) — модели и соответствующие
функциональные диаграммы;
· ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".
Диаграммы потоков данных и диаграммы "сущность-связь" —
наиболее часто используемые в CASE-средствах виды моделей.
Конкретный вид перечисленных диаграмм и интерпретация их
конструкций зависят от стадии ЖЦ ИС.
На стадии формирования требований к ИС SADT-модели и DFD
используются для построения модели "как есть" и модели "как должно
быть", отражая, таким образом, существующую и предлагаемую структуру
бизнес-процессов
организации
и
взаимодействие
между
ними
(использование SADT-моделей, как правило, ограничивается только
-62данной стадией, поскольку они изначально не предназначались для
проектирования
ИС).
С
помощью
ERD
выполняется
описание
используемых в организации данных на концептуальном уровне, не
зависимом от средств реализации базы данных (СУБД).
На стадии проектирования
DFD используются для
описания
структуры проектируемой системы, при этом они могут уточняться,
расширяться и дополняться новыми конструкциями. Аналогично ERD
уточняются и дополняются новыми конструкциями, описывающими
представление данных на логическом уровне, пригодном для последующей
генерации схемы базы данных. Данные модели могут дополняться
диаграммами, отражающими системную архитектуру, структурные схемы
программ, иерархию экранных форм и меню и др.
Перечисленные модели в совокупности дают полное описание ИС
независимо от того, является ли система существующей или вновь
разрабатываемой. Состав диаграмм в каждом конкретном случае зависит
от сложности системы и необходимой полноты ее описания.
3.3. Метод функционального моделирования SADT
Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1973 г.
Данный метод успешно использовался в военных, промышленных и
коммерческих организациях США для решения широкого круга задач;
таких,
как
долгосрочное
и
стратегическое
планирование,
автоматизированное производство и проектирование, разработка ПО для
оборонных систем, управление финансами и материально-техническим
снабжением и др.
Метод SADT представляет собой совокупность правил и процедур,
предназначенных для построения функциональной модели объекта какойлибо предметной области. Функциональная модель SADT отображает
-63функциональную структуру объекта, т.е. производимые им действия и
связи между этими действиями. Основныe элементы этого метода
основываются на следующих концепциях:
 графическое представление блочного моделирования. Графика
блоков и дуг SADT-диаграммы отображает функцию в виде
блока, а интерфейсы входа-выхода представляются дугами,
соответственно входящими в блок и выходящими из него.
Взаимодействие блоков друг с другом описывается посредством
интерфейсных дуг, выражающих "ограничения", которые, в
свою очередь, определяют, когда и каким образом функции
выполняются и управляются;
 строгость и точность. Выполнение правил SADT требует
достаточной строгости и точности, не накладывая в то же время
чрезмерных ограничений на действия аналитика. Правила SADT
включают: ограничение количества блоков на каждом уровне
декомпозиции (правило 3-6 блоков), связность диаграмм
(номера
блоков),
уникальность
меток
и
наименований
(отсутствие повторяющихся имен), синтаксические правила для
графики (блоков и дуг), разделение входов и управлений
(правило определения роли данных);
 отделение организации от функции, т.е. исключение влияния
административной структуры организации на функциональную
модель.
Метод SADT может использоваться для моделирования самых
разнообразных
систем
и
определения
требований
и
функций
с
последующей разработкой информационной системы, удовлетворяющей
этим требованиям и реализующей эти функции. В существующих системах
метод SADT может применяться для анализа функций, выполняемых
-64системой,
и
указания
механизмов,
посредством
которых
они
осуществляются.
Результатом применения метода SADT является модель, которая
состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки
друг на друга. Диаграммы — главные компоненты модели, все функции
организации и интерфейсы на них представлены как блоки и дуги
соответственно. Место соединения дуги с блоком определяет тип
интерфейса. Управляющая информация входит в блок сверху, в то время
как входная информация, которая подвергается обработке, показана с
левой стороны блока, а результаты (выход) показаны с правой стороны.
Механизм
(человек
или
автоматизированная
система),
который
осуществляет операцию, представляется дугой, входящей в блок снизу
(рис.).
Одной из наиболее важных особенностей метода SADT является
постепенное введение все больших уровней детализации по мере создания
диаграмм, отображающих модель. Каждый компонент модели может быть
декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует
«внутреннее строение» блока на родительской диаграмме.
3.4. Построение иерархии диаграмм
Построение SADT-модели начинается с представления всей системы
в виде простейшего компонента – одного блока и дуг, изображающих
интерфейсы с функциями вне системы. Поскольку единственный блок
отражает систему как единое целое, имя, указанное в блоке, является
общим. Это верно и для интерфейсных дуг – они также соответствуют
полному набору внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля,
детализируется на другой диаграмме с помощью нескольких блоков,
-65соединенных интерфейсными дугами. Эти блоки определяют основные
подфункции исходной функции. Данная декомпозиция выявляет полный
набор подфункций, каждая из которых показана
как блок, границы
которого определены интерфейсными дугами. Каждая из этих подфункций
может быть декомпозирована подобным образом в целях большей
детализации.
Во всех случаях каждая подфункция может содержать только те
элементы, которые входят в исходную функцию. Кроме того, модель не
может опустить какие-либо элементы, т.е. родительский блок и его
интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, из
него не может быть ничего удалено.
Диаграмма
функций
представляет
собой
серию
диаграмм
с
сопроводительной документацией, разбивающих сложный объект на
составные части, которые изображены в виде блоков. Детали каждого из
основных блоков показаны в виде блоков на других диаграммах. Каждая
детальная диаграмма является декомпозицией блока из диаграммы
предыдущего
уровня.
На
каждом
шаге
декомпозиции
диаграмма
предыдущего уровня называется родительской для более детальной
диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего
уровня, являются точно теми же самыми, что и дуги, входящие в
диаграмму нижнего уровня и выходящие из нее, потому что блок и
диаграмма изображают одну и ту же часть системы.
Некоторые дуги присоединены к блокам диаграмм обоими концами,
у других же один конец остается неприсоединенным. Неприсоединенные
концы должны соответствовать дугам на исходной диаграмме. Все
граничные дуги должны продолжаться на родительской диаграмме, чтобы
она была полной и непротиворечивой.
-66На SADT-диаграммах не указаны явно ни последовательность, ни
время.
Обратные
связи,
итерации,
перекрывающиеся процессы
продолжающиеся
процессы
и
(по времени) функции могут быть
изображены с помощью дуг. Обратные связи могут выступать в виде
комментариев, замечаний, исправлений и т.д.
Как было отмечено, механизмы (дуги с нижней стороны) показывают
средства, с помощью которых осуществляется выполнение функций.
Механизм может быть человеком, компьютером или любым другим
устройством, которое помогает выполнять данную функцию.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы
может быть описан диаграммой нижнего уровня, которая, в свою очередь,
может быть далее детализована с помощью необходимого числа диаграмм.
Таким образом формируется иерархия диаграмм.
Для того, чтобы указать положение любого блока или диаграммы в
иерархии, используют номера диаграмм.
Одним из важных моментов при моделировании бизнес-процессов
организации с помощью метода SADT является точная согласованность
типов связей между функциями. Описание типов связей представлена в
таблице 3.1.
-67Таблица 3.1.
Типы связей
Уровень Тип
значимос связи
ти
0
Случа
йная
1
Логиче
ская
2
Време
нная
3
Проце
дурная
4
Комму
никаци
онная
5
После
довате
льная
6
Функц
иональ
ная
Характеристика типа связи
Для функций
Для данных
Незначительна или полностью отсутствует
Функции одного и того же
множества или типа, но
функциональных
отношений между ними не
обнаружено
Функции связаны
во
времени или включаются
параллельно
Функции выполняются в
одной части цикла или
процесса
Функции используют одни
и те же входные данные
и/или
производят
одинаковые
выходные
данные
Функции
выполняют
последовательные
преобразования одних и тех
же данных
Функции объединены для
выполнения одной функции
Случайная
Данные одного и того же
множества или типа, но
функциональных
отношений между ними не
обнаружено
Данные, используемые в
одном
временном
интервале
Данные, используемые во
время одной и той же фазы
или итерации
Данные,
на
которые
действует одна и та же
деятельность
Данные,
преобразуемые
последовательными
функциями
Данные связаны
функцией
одной
3.5. Моделирование потоков данных
Диаграммы потоков данных (DFD) являются основным средством
моделирования функциональных требований к проектируемой системе. С
их
помощью
эти
требования
представляются
в
виде
иерархии
функциональных компонентов (процессов), связанных потоками данных.
-68Главная цель такого представления — продемонстрировать, как каждый
процесс преобразует свои входные данные в выходные, а также выявить
отношения между этими процессами.
Для построения DFD традиционно используются две различные
нотации, соответствующие методам Йордана и Гейна - Сэрсона. Эти
нотации
незначительно
изображением
символов.
отличаются
Далее
друг
при
от
друга
построении
графическим
примеров
будет
использоваться нотация Гейна - Сэрсона.
В соответствии с данными методами модель системы определяется
как иерархия диаграмм потоков данных, описывающих асинхронный
процесс преобразования информации от ее ввода в систему до выдачи
пользователю. Диаграммы верхних уровней иерархии (контекстные
диаграммы) определяют основные процессы или подсистемы с внешними
входами и выходами. Они детализируются при помощи диаграмм нижнего
уровня. Такая декомпозиция продолжается, создавая многоуровневую
иерархию диаграмм, до тех пор, пока не будет достигнут уровень
декомпозиции, на котором процессы становятся элементарными и
детализировать их далее невозможно.
Источники
информации
(внешние
сущности)
порождают
информационные потоки (потоки данных), переносящие информацию к
подсистемам
или
процессам.
Те,
в
свою
очередь,
преобразуют
информацию и порождают новые потоки, которые переносят информацию
к другим процессам или подсистемам, накопителям данных или внешним
сущностям — потребителям информации.
3.5.1. Состав диаграмм потоков данных
Основными компонентами диаграмм потоков данных являются:
 внешние сущности;
-69 системы и подсистемы;
 процессы;
 накопители данных;
 потоки данных.
Внешняя сущность представляет собой материальный объект или
физическое лицо, представляющие собой источник или приемник
информации, например заказчики, персонал, поставщики, клиенты, склад.
Определение некоторого объекта или системы в качестве внешней
сущности указывает на то, что они находятся за пределами границ
анализируемой системы. В процессе анализа некоторые внешние сущности
могут быть перенесены внутрь диаграммы анализируемой системы, если
это необходимо, или, наоборот, часть процессов может быть вынесена за
пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом, расположенным как бы
над диаграммой и бросающим на нее тень для того, чтобы можно было
выделить этот символ среди других обозначений.
При построении модели сложной ИС она может быть представлена в
самом общем виде на так называемой контекстной диаграмме в виде одной
системы как единого целого либо может быть декомпозирована на ряд
подсистем.
Номер подсистемы служит для ее идентификации. В поле имени
вводится наименование подсистемы в виде предложения с подлежащим и
соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных
в выходные в соответствии с определенным алгоритмом. Физически
процесс может быть реализован различными способами: это может быть
подразделение организации (отдел), выполняющее обработку входных
документов и выпуск отчетов, программа, аппаратно реализованное
логическое устройство и т. д.
-70Номер процесса служит для его идентификации. В поле имени
вводится наименование процесса в виде предложения с активным
недвусмысленным
глаголом
в
неопределенной
форме
(вычислить,
рассчитать, проверить, определить, создать, получить), за которым
следуют существительные в винительном падеже, например: "Ввести
сведения о налогоплательщиках", "Выдать информацию о текущих
расходах", "Проверить поступление денег".
Использование таких глаголов, как "обработать", "модернизировать"
или "отредактировать", означает недостаточно глубокое понимание
данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое
подразделение организации, программа или аппаратное устройство
выполняет данный процесс.
Накопитель данных — это абстрактное устройство для хранения
информации, которую можно в любой момент поместить в накопитель и
через некоторое время извлечь, причем способы помещения и извлечения
могут быть любыми.
Накопитель данных может быть реализован физически в виде
микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на
магнитном носителе и т. д. Накопитель данных на диаграмме потоков
данных идентифицируется буквой "D" и произвольным числом. Имя
накопителя выбирается из соображения наибольшей информативности для
проектировщика.
Накопитель данных в общем случае является прообразом будущей
базы данных, и описание хранящихся в нем данных должно быть увязано с
информационной моделью (ERD).
Поток
данных
определяет
информацию,
передаваемую
через
некоторое соединение от источника к приемнику. Реальный поток данных
может быть информацией, передаваемой по кабелю между двумя
-71устройствами, пересылаемыми по почте письмами, магнитными лентами
или дискетами, переносимыми с одного компьютера на другой, и т. д.
Поток данных на диаграмме изображается линией, оканчивающейся
стрелкой, которая показывает направление потока. Каждый поток данных
имеет имя, отражающее его содержание.
3.5.2. Построение иерархии потоков данных
Главная цель построения иерархии DFD заключается в том, чтобы
сделать требования к системе ясными и понятными на каждом уровне
детализации, а также разбить эти требования на части с точно
определенными отношениями между ними. Для достижения этого
целесообразно пользоваться следующими рекомендациями:
 размещать на каждой диаграмме от 3 до 6—7 процессов.
Верхняя граница соответствует человеческим возможностям
одновременного восприятия и понимания структуры сложной
системы с множеством внутренних связей, нижняя граница
выбрана по соображениям здравого смысла: нет необходимости
детализировать процесс диаграммой, содержащей всего один
процесс или два;
 не загромождать диаграммы не существенными на данном
уровне деталями;
 декомпозицию потоков данных осуществлять параллельно с
декомпозицией процессов. Эти две работы должны выполняться
одновременно, а не одна после завершения другой;
 выбирать ясные, отражающие суть дела имена процессов и
потоков, при этом стараться не использовать аббревиатуры.
Первым шагом при построении иерархии DFD является построение
контекстных диаграмм. Обычно при проектировании относительно
-72простых систем строится единственная контекстная диаграмма со
звездообразной топологией, в центре которой находится так называемый
главный
процесс,
информации,
соединенный
посредством
с
которых
приемниками
и
с
взаимодействуют
системой
источниками
пользователи и другие внешние системы. Перед построением контекстной
DFD
необходимо
сущности),
проанализировать
оказывающие
влияние
на
внешние
события
функционирование
(внешние
системы.
Количество потоков на контекстной диаграмме должно быть по
возможности небольшим, поскольку каждый из них может быть в
дальнейшем разбит на несколько потоков на следующих уровнях
диаграммы.
Для проверки контекстной диаграммы можно составить список
событий. Список событий должен состоять из описаний действий внешних
сущностей (событий) и соответствующих реакций системы на события.
Каждое событие должно соответствовать одному (или более) потоку
данных: входные потоки интерпретируются как воздействия, а выходные
потоки — как реакции системы на входные потоки.
Если для сложной системы ограничиться единственной контекстной
диаграммой, то она будет содержать слишком большое количество
источников и приемников информации, которые трудно расположить на
листе бумаги нормального формата, и, кроме того, единственный главный
процесс не раскрывает структуры такой системы. Признаками сложности
(в смысле контекста) могут быть: наличие большого количества внешних
сущностей
(десять
и
более),
распределенная
природа
системы,
многофункциональность системы с уже сложившейся или выявленной
группировкой функций в отдельные подсистемы.
Для сложных систем строится иерархия контекстных диаграмм. При
этом контекстная диаграмма верхнего уровня содержит не единственный
главный процесс, а набор подсистем, соединенных потоками данных.
-73Контекстные диаграммы следующего уровня детализируют контекст и
структуру подсистем.
Иерархия
контекстных
диаграмм
определяет
взаимодействие
основных функциональных подсистем как между собой, так и с внешними
входными и выходными потоками данных и внешними объектами
(источниками и приемниками информации), с которыми взаимодействует
система.
Разработка
контекстных
диаграмм
решает
проблему
строгого
определения функциональной структуры ИС на самой ранней стадии ее
проектирования, что особенно важно для сложных многофункциональных
систем, в создании которых участвуют разные организации и коллективы
разработчиков.
После построения контекстных диаграмм полученную модель следует
проверить на полноту исходных данных об объектах системы и
изолированность объектов (отсутствие информационных связей с другими
объектами).
Для
каждой
подсистемы,
присутствующей
на
контекстных
диаграммах, выполняется ее детализация при помощи DFD. Это можно
сделать путем построения диаграммы для каждого события. Каждое
событие представляется в виде процесса с соответствующими входными и
выходными потоками, накопителями данных, внешними сущностями и
ссылки на другие процессы для описания связей между этим процессом и
его окружением. Затем все построенные диаграммы сводятся в одну
диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован
при помощи DFD или (если процесс элементарный) спецификации. При
детализации должны выполняться следующие правила:
 правило балансировки — при детализации подсистемы или
процесса детализирующая диаграмма в качестве внешних
-74источников или приемников данных может иметь только те
компоненты
(подсистемы,
процессы,
внешние
сущности,
накопители данных), с которыми имеют информационную связь
детализируемые подсистема или процесс на родительской
диаграмме;
 правило нумерации - при детализации процессов должна
поддерживаться
их
иерархическая
нумерация.
Например,
процессы, детализирующие процесс с номером 12, получают
номера 12.1, 12.2, 12.3 и т. д.
Спецификация процесса должна формулировать его основные
функции таким образом, чтобы в дальнейшем специалист, выполняющий
реализацию
проекта,
смог
выполнить
их
или
разработать
соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение
о завершении детализации процесса и использовании спецификации
принимается аналитиком исходя из следующих критериев:
 наличия у процесса относительно небольшого количества
входных и выходных потоков данных (2-3 потока);
 возможности описания преобразования данных процессом в
виде последовательного алгоритма;
 выполнения процессом единственной логической функции
преобразования входной информации в выходную;
 возможности
описания
логики
процесса
при
помощи
спецификации небольшого объема (не более 20 — 30 строк).
Спецификации должны удовлетворять следующим требованиям:
 для каждого процесса нижнего уровня должна существовать
одна и только одна спецификация;
 спецификация должна определять способ преобразования
входных потоков в выходные;
-75 нет необходимости (по крайней мере на стадии формирования
требований)
определять
метод
реализации
этого
преобразования;
 спецификация должна стремиться к ограничению избыточности
— не следует переопределять то, что уже было определено на
диаграмме;
 набор конструкций для построения спецификации должен быть
простым и понятным.
Фактически спецификации представляют собой описания алгоритмов
задач, выполняемых процессами. Спецификации содержат номер и/или
имя процесса, списки входных и выходных данных и тело (описание)
процесса,
являющееся
спецификацией
алгоритма
или
операции,
трансформирующей входные потоки данных в выходные. Известно
большое количество разнообразных методов, позволяющих описать тело
процесса. Соответствующие этим методам языки могут варьироваться от
структурированного естественного языка или псевдокода до визуальных
языков проектирования.
Структурированный
естественный
язык
применяется
для
читабельного, достаточно строгого описания спецификаций процессов. Он
представляет
собой
разумное
сочетание
строгости
языка
программирования и читабельности естественного языка и состоит из
подмножества
слов,
организованных
в
определенные
логические
структуры, арифметических выражений и диаграмм.
В состав языка входят следующие основные символы:
 глаголы, ориентированные на действие и применяемые к
объектам;
 термины,
определенные
на
любой
стадии
проекта
(например, задачи, процедуры, символы данных и т. п.);
 предлоги и союзы, используемые в логических отношениях;
ИС
-76 общеупотребительные
математические,
физические
и
технические термины;
 арифметические уравнения;
 таблицы, диаграммы, графы и т. п.;
 комментарии.
К управляющим структурам языка относятся последовательная
конструкция, конструкция выбора и итерация (цикл).
При использовании структурированного естественного языка приняты
следующие соглашения:
 логика
процесса
последовательных
выражается
конструкций,
в
виде
конструкций
комбинации
выбора
и
итераций;
 глаголы должны быть активными, недвусмысленными и
ориентированными на целевое действие (заполнить, вычислить,
извлечь, а не модернизировать, обработать);
 логика
процесса
должна
быть
выражена
четко
и
недвусмысленно.
При построении иерархии DFD переходить к детализации процессов
следует только после определения содержания всех потоков и накопителей
данных, которое описывается с помощью структур данных. Для каждого
потока данных формируется список всех его элементов данных, затем
элементы данных объединяются в структуры данных, соответствующие
более крупным объектам данных (например, строкам документов или
объектам предметной области). Каждый объект должен состоять из
элементов, являющихся его атрибутами. Структуры данных могут
содержать альтернативы, условные вхождения и итерации. Условное
вхождение показывает, что данный компонент может отсутствовать в
структуре (например, структура "данные о страховании" для объекта
"служащий"). Альтернатива означает, что в структуру может входить один
-77из перечисленных элементов. Итерация предусматривает вхождение
любого числа элементов в указанном диапазоне (например, элемент "имя
ребенка" для объекта "служащий"). Для каждого элемента данных может
указываться его тип (непрерывные или дискретные данные). Для
непрерывных данных могут указываться единица измерения (кг, см и т. п.),
диапазон значений, точность представления и форма физического
кодирования. Для дискретных данных может указываться таблица
допустимых значений.
После построения законченной модели системы ее необходимо
верифицировать (проверить на полноту и согласованность). В полной
модели все ее объекты (подсистемы, процессы, потоки данных) должны
быть
подробно
описаны
и
детализированы.
Выявленные
недетализированные объекты следует детализировать, вернувшись на
предыдущие шаги разработки. В согласованной модели для всех потоков
данных и накопителей данных должно выполняться правило сохранения
информации: все поступающие куда-либо данные должны быть считаны, а
все считываемые данные должны быть записаны.
3.6. Сравнительный анализ SADT-моделей и диаграмм
потоков данных
Как уже отмечалось, практически во всех методах структурного
подхода (структурного анализа) на стадии формирования требований к ИС
используются две группы средств моделирования:
 диаграммы,
иллюстрирующие
функции,
которые
система
должна выполнять, и связи между этими функциями - DFD или
SADT (IDEFO);
 диаграммы, моделирующие данные и их отношения (ERD).
-78Таким
образом,
разновидностями
наиболее
структурного
существенное
анализа
различие
заключается
в
между
средствах
функционального моделирования. С этой точки зрения все разновидности
структурного анализа могут быть разбиты на две группы — использующие
DFD
(в
различных
нотациях)
и
использующие
SADT-модели.
Соотношение применения этих двух разновидностей структурного анализа
в существующих CASE-средствах составляет 90% для DFD и 10% для
SADT. Вероятно, соотношение такого же порядка справедливо и для
распространенности рассматриваемых моделей на практике.
Сравнительный
анализ
этих
двух
разновидностей
методов
структурного анализа проводится по следующим параметрам:
 адекватность средств решаемым задачам;
 согласованность с другими средствами структурного анализа;
 интеграция с последующими стадиями ЖЦ ИС (прежде всего со
стадией проектирования).
Адекватность средств решаемым задачам. Модели SADT (IDEFO)
традиционно используются для моделирования организационных систем.
С другой стороны, не существует никаких принципиальных ограничений
на использование DFD в качестве средства построения статических
моделей деятельности организаций. Следует отметить, что метод SADT
успешно работает только при описании хорошо специфицированных и
стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому
он и принят в США в качестве типового. Например, в Министерстве
обороны США десятки лет существуют четкие должностные инструкции и
методики, которые жестко регламентируют деятельность подразделений,
делают е.» высокотехнологичной и ориентированной на бизнес-процесс. В
российской действительности с ее слабой типизацией бизнес-процессов, их
стихийным появлением и развитием разумнее ориентироваться на модели,
основанные на потоковых диаграммах.
-79Если же речь идет не о системах вообще, а об ИС, то здесь DFD вне
конкуренции. Практически любой класс систем успешно моделируется при
помощи DFD-ориентированных методов. SADT-диаграммы оказываются
значительно менее выразительными и удобными при моделировании ИС.
Так, дуги в SADT жестко типизированы (вход, выход, управление,
механизм). В то же время применительно к ИС стирается смысловое
различие между входами и выходами, с одной стороны, и управлениями и
механизмами, с другой - входы, выходы и управления являются потоками
данных и правилами их преобразования. Анализ системы с помощью
потоков данных и процессов, их преобразующих, является более
прозрачным и недвусмысленным.
Более того, в SADT вообще отсутствуют выразительные средства для
моделирования особенностей ИС. DFD же с самого начала создавались как
средство проектирования информационных систем (SADT - как средство
моделирования систем вообще) и имеют более богатый набор элементов,
адекватно отражающих специфику таких систем (например, хранилища
данных являются прообразами файлов или баз данных, внешние сущности
отражают взаимодействие моделируемой системы с внешним миром).
Наличие в DFD спецификаций процессов нижнего уровня позволяет
преодолеть логическую незавершенность SADT (а именно обрыв модели
на некотором достаточно низком уровне, когда дальнейшая ее детализация
становится
бессмысленной) и
построить
полную
функциональную
спецификацию разрабатываемой системы.
Согласованность с другими средствами структурного анализа.
Главным достоинством любых моделей является возможность их
интеграции с моделями других типов. В данном случае речь идет о
согласованности функциональных моделей со средствами моделирования
данных. Согласование SADT-модели с ERD практически невозможно или
носит искусственный характер. В свою очередь, DFD и ERD взаимно
-80дополняют друг друга и являются согласованными, поскольку в DFD
присутствует описание структур данных, непосредственно используемое
для построения ERD.
Интеграция
с
последующими
стадиями
ЖЦ
ИС.
Важная
характеристика модели — ее совместимость с моделями последующих
стадий ЖЦ (прежде всего стадии проектирования, непосредственно
следующей за стадией формирования требований и опирающейся на ее
результаты).
DFD могут быть легко преобразованы в модели проектируемой
системы.
Более
того,
известен
ряд
алгоритмов
автоматического
преобразования иерархии DFD в структурные карты различных видов, что
обеспечивает логичный и безболезненный переход от формирования
требований к проектированию системы. С другой стороны, формальные
методы преобразования SADT-диаграмм в проектные решения ИС
отсутствуют.
В заключение необходимо отметить, что одним из основных
критериев выбора того или иного метода является степень владения им со
стороны консультанта или аналитика, грамотность выражения своих
мыслей на языке моделирования, В противном случае в моделях,
построенных с использованием любого метода, будет невозможно
разобраться.
-81-
4. МЕТОДИКА ПРОЕКТИРОВАНИЯ ИС
4.1. Концепции ER-модели
Основные концепции модели "сущность-связь" включают типы
сущностей, типы связей и атрибуты.
4.1.1 Типы сущностей
Типы сущностей - объекты или концепция, которые характеризуются
на данном предприятии как имеющие независимое существование.
Основной концепцией ER-моделирования является тип сущности
(entity type), который представляет множество объектов реального мира с
одинаковыми свойствами. Тип сущности характеризуются независимым
существованием и может быть объектом с физическим (или реальным)
существованием или объектом с концептуальным или абстрактным)
существованием. Обратите внимание на то, что в данный момент можно
дать только рабочее определение типа сущности, поскольку для них пока
не существует строгого формального определения. Это значит, что разные
разработчики могут выделять разные сущности.
Сущность – это экземпляр типа сущности, который может быть
идентифицирован уникальным образом.
Каждый уникально идентифицируемый экземпляр типа сущности
называется просто сущностью. Будем использоваться только термины
"сущность" и "тип сущности". Однако термин "сущность" будет
использоваться и в более общем смысле, там, где этот смысл очевиден.
Каждый тип сущности идентифицируется именем и списком свойств.
База данных обычно содержит много разных типов сущностей.
Слабый тип сущности - тип сущности, существование которого
зависит от какого-то другого типа сущности.
-82Сильный тип – это тип сущности, существование которого не
зависит от какого-то другого типа сущности.
Слабый тип сущности зависит от существования другой сущности.
Слабые сущности иногда называют дочерними (child), зависимыми
(dependent) или подчиненными (subordinate), а сильные - родительскими
(parent), сущностями-владельцами(owner) или доминантными(dominant).
Каждый сильный тип сущности изображается в виде прямоугольника
с именем сущности внутри него, а каждый слабый тип сущности - в виде
прямоугольника с двойным контуром. На рис. 2.1 показан пример
представления на диаграммах сильных (Staff и Branch) и слабых (Next of
Kin) типов сущностей.
Staff
Next_Of_Kin
Branch
Рис. 2.1. Представление на ER-диаграмме сильных (Staff и Branch) и
слабых (Next_of_Kin) типов сущностей
2.1.2. Атрибуты
Атрибут - свойство типа сущности или типа связи.
Отдельные свойства сущностей называются атрибутами. Например,
сущность Branch (Отделение компании) может быть описана номером
отделения (Branch_No), адресом (Address), номером телефона (Tel_No) и
номером факса (Fax_No). Атрибуты сущности содержат значения,
описывающие каждую сущность. Значения атрибутов представляют
основную часть сведений, сохраняемых в базе данных.
Связь, которая соединяет две сущности, также может иметь атрибуты,
аналогичные атрибутам типа сущности.
-83Домен
атрибута – это набор значений, которые могут быть
присвоены атрибуту.
Каждый атрибут связан с набором значений, который называется
доменом. Домен определяет все потенциальные значения, которые могут
быть присвоены атрибуту. Например, количество комнат в объекте
недвижимости может варьироваться от одной до пятнадцати для каждого
экземпляра этой сущности. Следовательно, набор допустимых значений
для атрибута "количество комнат" (Rooms) сущности Property for Rent
можно определить как набор целых чисел от 1 до 15.
Различные атрибуты могут совместно использовать один и тот же
домен. Например, атрибуты адреса (Address) сотрудников компании
(сущность Staff) и владельцев объектов недвижимости (сущность Owner)
могут совместно использовать один и тот же домен всех возможных
адресов.
Домены
также
могут
представлять
собой
комбинацию,
состоящую из нескольких других доменов. Например, домен даты
рождения (DOB) сущности Staff состоит из таких подчиненных доменов,
как день, месяц и год.
Домен атрибута имени FName определить труднее, потому что он
состоит из множества всех возможных имен. Очевидно, что это - текстовая
строка, но она может состоять не только из букв, но также из дефисов или
других специальных символов. Полностью разработанная модель данных
включает домены каждого атрибута, присутствующего в ER-модели.
Атрибуты
делятся на простые и составные, однозначные и
многозначные, а также производные.
Простой атрибут - это атрибут, состоящий из одного компонента с
независимым существованием.
Простые атрибуты не могут быть разделены на более мелкие
компоненты. Примерами простых атрибутов являются атрибут пола (Sex)
-84или зарплаты (Salary) работника. Простые атрибуты иногда называют
атомарными.
Составной атрибут – это атрибут, состоящий из нескольких
компонентов,
каждый
из
которых
характеризуется
независимым
существованием.
Некоторые атрибуты могут быть разделены на более мелкие
компоненты, которые характеризуются независимым существованием.
Например, атрибут адреса (Address) сущности, представляющей отделение
компании, (Branch) со значением '163 Main St, Partick, Glasgow, Gil 9QX'
может быть разбит на отдельные атрибуты улицы (Street) со значением
'163 Main St', района (Area) со значением 'Partick', города (City) со
значением 'Glasgow' и почтового индекса (Postcode) со значением 'Gil
9QX'.
Решение о моделировании атрибута Address в виде простого атрибута
или разбиении его на атрибуты Street, Area, City и Postcode зависит от того,
как рассматривается атрибут Address в пользовательском представлении как единое целое или как набор отдельных компонентов.
Однозначный
атрибут – это атрибут, который содержит одно
значение для одной сущности.
Большинство атрибутов типов сущностей являются однозначными
для каждого отдельного экземпляра этой сущности. Например, сущность
Branch всегда имеет единственное значение в атрибуте номера отделения
компании (Branch_No), например 'ВЗ'. Поэтому атрибут Branch No
является однозначным.
Многозначный атрибут – это атрибут, который содержит несколько
значений для одной сущности.
Некоторые атрибуты могут иметь несколько значений для одной
сущности пример, сущность Branch может иметь несколько значений для
атрибута номер телефона отделения компании (Tel No), например: '0171-
-85886-1212' и '0171-886-1233. Следовательно, атрибут Tel No в этом случае
будет многозначным. Многозначный атрибут допускает присутствие
определенного количества значений (возможно, в заданных пределах максимальном и минимальном количестве). Например, атрибут Tel No
отделения компании может иметь от одного до десяти значений. Иными
словами, любое отделение компании должно иметь минимум один номер
телефона и максимум десять собственных телефонных номеров.
Производный
атрибут – это атрибут, который представляет
значение, производное от значения связанного с ним атрибута или
некоторого
множества
атрибутов,
принадлежащих
некоторому
(не
обязательно данному) типу сущности.
Некоторые атрибуты могут быть связаны с определенной сущностью.
Например, возраст сотрудника (Age) является величиной, производной от
его даты рождения (DOB), и поэтому атрибуты Age и DOB являются
связанными. Причем атрибут Age является производным атрибутом,
значение которого вычисляется на основании значений атрибута DOB.
В некоторых случаях значение атрибута является производным от
многих сущностей одного и того же типа сущности. Например, атрибут
общего количества сотрудников отделения компании (Total Staff)
сущности типа Staff (Работник) может быть вычислен на основе подсчета
количества сущностей Staff.
Производные
атрибуты
могут
также
вычисляться
на
основе
нескольких взаимосвязанных атрибутов различных сущностей. Например,
рассмотрим
атрибут
Deposit
(Задаток)
сущности
Rental_Agreement
(Договор на аренду). Значение задатка связано с договором аренды
(сущность Rental_Agreement) и вычисляется как удвоенная месячная плата
за аренду данного объекта недвижимости. Следовательно, значение
атрибута Deposit сущности Rental Agreement вычисляется на основе
атрибута Rent (Арендная плата) сущности Rental Agreement.
-86Под ключом подразумевается элемент данных, который позволяет
уникально идентифицировать отдельные экземпляры некоторого типа
сущности. Рассмотрим более строгое определение ключа.
Потенциальный ключ – это атрибут или набор атрибутов, который
уникально идентифицирует отдельные экземпляры типа сущности.
Потенциальный ключ - это один или несколько атрибутов, значения
которого уникальным образом идентифицируют каждый экземпляр
сущности
данного
типа.
Например,
номер
отделения
компании
(Branch_No) является потенциальным ключом типа сущности Branch,
поскольку он содержит разные значения для каждой отдельной сущности
Branch. Потенциальный ключ должен содержать значения, которые
уникальны для каждого отдельного экземпляра сущности данного типа.
Например, каждое отделение компании обладает уникальным номером
(например, 'ВЗ'), и не существует отделений с одинаковыми номерами.
Первичный
ключ – это потенциальный ключ, который выбран в
качестве первичного ключа.
Тип сущности может иметь несколько потенциальных ключей.
Например,
каждый
сотрудник
может
иметь
уникальный
номер
социального страхования NIN (National_Insurance_Number), а также
уникальный
личный
(табельный)
номер
Staff_No,
присваиваемый
сотрудникам этой организации. Таким образом, сущность Staff обладает
двумя потенциальными ключами, каждый из которых может быть выбран
в качестве первичного ключа.
Выбор первичного ключа сущности осуществляется исходя из
соображений суммарной длины атрибутов, минимального количества
атрибутов я ключе, а также наличия гарантий уникальности его значений в
текущий момент времени и в обозримом будущем. В частности, личный
номер сотрудника (например, 'SG14') меньше по размеру, а потому
предпочтительнее, чем номер социального страхования (например,
-87'WL220658D').
Следовательно,
первичным
ключом
сущности
Staff
целесообразно выбрать именно атрибут Staff No, а атрибут NIN в этом
случае будет называться альтернативным ключом.
Составной ключ – это потенциальный ключ, который состоит из двух
или больше атрибутов.
В некоторых случаях ключ сущности состоит из нескольких
атрибутов, значения которых, взятые вместе, а не по отдельности,
уникальны для каждого экземпляра сущности. Например, сущность Advert
(Рекламное объявление) обладает следующими атрибутами Property No,
Newspaper Name. Date_Advert и Cost. Многие объекты недвижимости
одновременно рекламируются во многих газетах. Для уникальной
идентификации каждого рекламного объявления необходимо использовать
значения Property No (Номер объекта недвижимости), Newspaper Name
(Название газеты) и Date Advert (Дата рекламного объявления). Таким
образом, сущность Advert (Рекламное объявление) обладает составным
первичным ключом, состоящим из атрибутов Property No, Newspaper Name
и Date Advert.
На
диаграммах
атрибуты
изображаются
в
виде
эллипсов,
присоединенных линией к соответствующей сущности и помеченных
именем атрибута. На рис. 4.2 показаны атрибуты, связанные с сущностями
Staff, Branch и Next_of Kin.
Эллипс окружен пунктирным контуром, если атрибут является
производным, и двойным контуром, если атрибут является многозначным.
Как следует из рис. 4.2, атрибут Total Staff (Общее количество
сотрудников) сущности Staff является производным, а атрибут Tel No
(Номер телефона) сущности Branch - многозначным.
Если
атрибут
является
составным,
его
атрибуты-компоненты
изображаются в виде присоединенных к нему эллипсов. На рис. 4.2
показано, что атрибут Name сущности Staff является составным атрибутом,
-88состоящим из атрибута имени (Fname) и атрибута фамилии (Lname). Кроме
того, атрибут Address сущности Branch также являете" составным
атрибутом, состоящим из атрибутов Street, Area, City и Postcode.
LName
FName
Name
Address
Tel_No
DOB
Position
Staff
Sex
NIN
Staff_No
Total_Staff
Salary
Area
Street
Address
NName
Next_Of_Kin
Relationship
City
Postcode
Address
Branch
Tel_No
Branch_No
Tel_No
Fax_No
Рис. 4.2. Диаграммное представление сущностей Staff, Branch и
Next_of_Kin и их атрибутов
Имя атрибута, который является первичным ключом данного типа
сущности, подчеркивается. Как следует из рис. 4.2, первичным ключом
сущности Staff является атрибут номера сотрудника Staff No, а первичным
ключом сущности Branch - атрибут номера отделения компании Branch No.
Первичный ключ для слабой сущности Next of Kin нельзя определить до
тех пор, пока не будут установлены ограничения для связи между
сущностью Next of Kin и ее родительской сущностью Staff. Как часть
слабой сущности, первичный ключ сущности Next of Kin будет частично
или полностью производным от сущности Staff.
-894.1.3. Типы связей
Тип связи – это осмысленная ассоциация между сущностями разных
типов.
Тип связи (relationship type) является набором ассоциаций между
двумя (или больше) типами сущностей-участников. Каждому типу связи
присваивается имя, которое можно описывать его функцию. Например,
сущность Owner (Владелец) связана с сущностью Property_for_Rent
(Объект недвижимости) посредством связи Owns (владеет).
Как и в случае сущностей, здесь следует различать понятия "связь" и
"тип связи".
Связь – это ассоциация между сущностями, включающая по одной
сущности из каждого участвующего в связи типа сущности.
Каждый уникально идентифицируемый экземпляр типа связи мы
будем называть просто связью. Связи указывают на отдельные экземпляры
сущностей, объединяемые ими. Другие авторы называют это понятие
экземпляром связи (relationship occurrence или relationship instance). В
данной главе используются только термины "тип связи" и "связь". Как и
при описании понятия "сущность", термин "связь" может использоваться в
более общем смысле, там, где этот смысл очевиден.
-90Значения
Атрибуты Экземпляры Экземпляры
сущности
сущности
Branch
isAllocated
Экземпляры
сущности
Staff
Атрибуты
Staff_No
B3
163 MAin St,
Glasgow
Branch_No
Address
0141-339-2178
Tel_No
Branch_No
Address
01224-67125
Tel_No
SG37
Address
81 George St,
Glasgow
DOB
10-Nov-60
Staff_No
B7
16 Argyll St,
Aberdeen
Значения
SG14
Address
63 Ashby St,
Glasgow
DOB
24-Mar-58
Staff_No
SA9
Address
2 Elm Pl,
Aberdeen
DOB
19-Feb-70
Рис. 4.3. Модель семантической сети, которая иллюстрирует отдельные
элементы связи IsAllocated
Связь IsAllocated (Приписан к) указывает на взаимосвязь между
сущностями Branch и Staff, а каждый отдельный экземпляр связи
IsAllocated связывает одну сущность Branch с одной сущностью Staff. На
отдельные элементы связи IsAllocated представлены на диаграмме (рис.
4.3), которая называется семантической сетью. Семантическая сеть
является объектной диаграммой, в которой символ представляет сущности,
а символ " - связи.
Для упрощения диаграммы семантической сети на рис. 4.4 показаны
только некоторые атрибуты сущностей Branch и Staff. Так, здесь показаны
только три атрибута типа сущности Branch - Branch_No - Address и Tel No,
и три атрибута для сущности Staff - Staff No, Address и DOB. Причем
каждый атрибут содержит значение из связанного с ним домена (например,
значение атрибута Branch No сущности b1 типа Branch равно 'В3').
-91Staf f_No
Staf f
RelatedTo
IsAllocated
Branch_No
Next_Of _Kin
Branch
Рис. 4.4. Представление на ER-диаграмме сущностей Branch, Staff,
Next_Of_Kin, связей между ними и атрибутов, которые являются
первичными ключами
На диаграмме показаны три связи (r1, r2 и r3), которые описывают
взаимосвязь сущностей Branch и Staff. Эти связи представлены линиями,
соединяющие каждую сущность Branch с каждой сущностью Staff.
Например, связь r1 изображает взаимосвязь сущностей b1 типа Branch и s1
типа Staff. Если вся корпоративная структура была бы представлена с
помощью семантических сетей, то из-за избыточной степени детализации
ее было бы трудно понять. Связи между сущностями корпорации можно
представить в более простой форме - в виде ER-модели. Пример
высокоуровневого представления связи концепций ER-моделирования
показан на рис. 4.4.
Каждая связь изображается в виде ромбика с указанным на нем
именем связи. Ромбик имеет двойной контур, если связь соединяет слабую
сущность с сильной сущностью, от которой эта слабая сущность зависит.
На рис. 4.4 взаимосвязь между сущностями Branch и Staff представлена с
помощью связи IsAllocated, а между сущностями Next_of Kin и Staff - с
помощью связи RelatedTo. Связь RelatedTo показана в виде ромбика с
-92двойным контуром, указывающим на то, что она установлена между
слабой (Next of Kin) и сильной (Staff) сущностями.
Для снижения уровня детализации на отдельной ER-диаграмме часто
указываются только те атрибуты, которые представляют первичные ключи
изображенных
сущностей,
а
в
некоторых
случаях
атрибуты
не
отображаются совсем. Например, не рис. 4.4 представлены только те
атрибуты, которые являются первичными ключами сущностей, а именно:
Staff No и Branch No.
Степень связи
Количество сущностей, которые охвачены данной
связью.
Охваченные некоторой связью сущности называются участниками
этой связи. Количество участников некоторой связи называется степенью
(degree) этой связи. Следовательно, степень связи указывает на количество
типов сущностей, охваченных данной связью. Связь со степенью два
называется бинарной (binary). Примером бинарной связи является связь
Owns с двумя участниками: Owner и Property for_Rent. Ее ER-диаграмма
показана на рис. 4.5.
Связь со степенью три называется тернарной (ternary). Примером
такой связи является связь SetsUp с тремя участниками: Client, Staff и
Interview. Назначение этой связи состоит в представлении ситуации, когда
сотрудник отвечает за организацию интервью с клиентом. Диаграмма
тернарной связи SetsUp показала на рис. 4.6.
Связь со степенью четыре называется кватернарной (quaternary).
Примером кватернарной связи является связь Arranges с четырьмя
сущностями-участниками: Buyer (Покупатель), Solicitor (Доверенное
лицо), Financial Institution (Финансовый орган) и Bid (Предложение). Эта
связь представляет ситуацию, когда покупатель с помощью доверенного
лица и при поддержке финансового органа выражает свое намерение
-93приобрести объект недвижимости. Диаграмма кватернарной связи Arranges
показана на рис. 4.7.
Owner
Owns
Property_For_Rent
Рис. 4.5. Пример бинарной связи Owns.
Staf f
Client
SetsUp
Interv iew
Рис. 4.6 Пример тернарной связи SetsUp.
Solititor
Buy er
Arranges
Financial_
Institution
Bid
Рис. 4.7 Пример квартернарной связи Arranges.
Рекурсивная связь – это связь, в которой одни и те же сущности
участвуют несколько раз и в разных ролях.
Рассмотрим рекурсивную связь Supervises, которая представляет
взаимосвязь персонала с управляющим, который также входит в состав
персонала. Иначе говоря, сущность Staff дважды участвует в связи
Supervises: первый раз - в качестве управляющего, а второй - в качество
-94сотрудника, которым управляют. Рекурсивные связи иногда называются
унарными (unary).
Связям могут присваиваться ролевые имена - для указания назначения
каждой сущности - участницы данной связи. Ролевые имена имеют
большое значение в рекурсивных связях (при определении функций
каждого участника). На Рис 5.9 показан пример использования ролевых
имен в рекурсивной связи Supersvises. Первое участие сущности Staff
получило название Инспектор (Supervisor), а второе Подчиненный
(Supervisee).
Supervises
Staf f
Рис. 4.8. Пример рекурсивной связи Supervises с ролевыми именами
Инспектор и Подчиненный.
Ролевые имена могут также использоваться, когда две сущности
связаны несколькими связями. Например, сущности Staff и Branch связаны
двумя различными связями - Manages и IsAllocated. Как показано на рис.
4.9, использование ролевых имен существенно проясняет назначение
каждой связи. Например, в случае когда, сущность Staff связана с
сущностью Branch связью Manages, сотрудник (сущность Staff) с ролевым
именем Руководитель (Manager) управляет (связь Manages) отделением
компании с ролевым именем Отделение компании (Branch Office).
Аналогично, когда сущность Branch связана с сущностью Staff связью
IsAllocated, то сотрудник с ролевым именем Работник (Member of Staff)
является приписанным к отделению компании с ролевым именем
Отделение компании (Branch Office).
-95-
Manages
Staf f
Branch
IsAllocated
Рис. 4.9. Пример сущностей, связанных двумя различными связями
Manages и IsAllocated, с указанием ролевых имен
Ролевые имена обычно не требуются, если функции сущностей участниц данной связи определены недвусмысленно.
4.1.4. Атрибуты связей
Атрибуты, описанные в разделе 4.1.2, могут также принадлежать
связям. Рассмотрим в качестве примера связь Views между сущностями
Client и Property for Rent. Допустим, что требуется фиксировать дату
просмотра
объекта
недвижимости
клиентом,
а
также
записывать
комментарии, сделанные клиентом в ходе осмотра этой недвижимости.
Данная информация скорее относится к связи Views, чем к сущности Client
или Property for Rent. Как показано на рис. 4.10, для хранения этих
сведений
связи
Views
присваиваются
атрибуты
Date_View
(Дата
атрибутов
может
просмотра) и Comments (Комментарии).
Наличие
у
свидетельствовать
связи
о
одного
том,
что
или
эта
нескольких
связь
скрывает
некоторую
неопределенную сущность. Например, наличие атрибутов Date View и
Comments у связи Views может свидетельствовать о наличии некоторой
сущности с именем Viewing (Просмотр).
-96Client_No
Data_View
Client
Comments
Views
Property_No
Property _f or_Rent
Рис. 4.10. Пример связи Views с атрибутами Date_View и Comments.
2.2. Структурные ограничения
Рассмотрим теперь ограничения, которые могут накладываться на
сущности - участницы некоторой связи. По сути, они являются
отражением определенных требований реального мира. Примерами таких
ограничений являются требования, чтобы объект недвижимости имел
владельца и в каждом отделении компании был некоторый персонал.
Основными двумя типами накладываемых на связи ограничений являются
ее кардинальность (cardinality) и степень участия (participation).
2.2.1. Показатель кардинальности
Показатель кардинальности. Описывает количество возможных связей
для каждой из сущностей-участниц. Наиболее распространенными
являются бинарные связи с показателями кардинальности "один к одному"
(1:1), "один ко многим" (1:М) и "многие ко многим" (M:N). Показатели
кардинальности связей между сущностями определяются прежде всего
производственными правилами, установленными на данном предприятии.
Правила, определяющие показатели кардинальности, называются бизнесправилами (business rules) организации. Важной частью моделирования
процессов функционирования предприятия является выделение и учет всех
(без исключения) существующих в нем бизнес-правил. К сожалению, не
-97все существующие типы бизнес-правил могут быть представлены с
помощью ER-модели. Примером подобного бизнес-правила является
распоряжение о том, что любой сотрудник получает дополнительный
выходной день за каждый отработанный в данной корпорации год.
Рассмотрим
бинарную
связь
Manages,
существующую
между
сущностями Staff и Branch. На рис. 4.11 эта связь представлена с помощью
семантической сетевой модели (см. раздел 4.1.3). Обратите внимание на то,
что в этом разделе для упрощения на семантических сетевых моделях
показаны
только
некоторые
из
атрибутов,
связанных
с
каждой
представленной сущностью.
Значения
Атрибуты Экземпляры Экземпляры Экземпляры
сущности
связи
сущности
Staff
Manages
Branch
SG5
Staff_No
Susan Brand
Name
Manager
Position
SG37
Staff_No
Атрибуты
Branch_No
Address
Tel_No
Ann Beech
Name
Senior Assistant
Position
SL41
Staff_No
Branch_No
John White
Name
Address
Manager
Position
Tel_No
Значения
B3
163 Main St,
Glasgow
0141-339-2178
B5
22 Deer Rd,
London
0132-664-8543
Рис. 4.11. Семантическая сетевая модель связи Manages между
сущностями Staff и Branch
На семантической сетевой модели, представленной на рис. 4.11,
отображены отдельные экземпляры связи Manages между сущностями
Staff и Branch. Например, сотрудница с именем 'Susan Brand' (s1) является
менеджером ('Manager') отделения компании с номером 'В3' (b1),
расположенным в Глазго ('Glasgow'), а сотрудник с именем 'John White'
-98(b3) - менеджером ('Manager') отделения компании с номером 'B5' (b2),
расположенным в Лондоне ('London').
Кроме того, из рис. 4.11 видно, что сотрудница с именем 'Ann Beech'
(s2) не является менеджером, а потому она не охвачена связью Manages.
Однако при определении показателя кардинальности некоторой связи
следует учитывать только те сущности, которые охватываются данной
связью. Вовлечение сущности в данную связь называется степенью
участия сущности.
Из семантической сетевой модели связи Manages следует, что одна
сущность типа Staff (менеджер) связана с единственной сущностью типа
Branch (Отделение компании). Поэтому связь Manages является связью
типа "один к одному" (1:1). Иначе говоря, показатель кардинальности
связи Manages равен 1:1. Кардинальность этой связи подтверждается
бизнес-правилом, которое его представляет.
ER-диаграмма связи Manages между сущностями Staff и Branch
показана на рис. 4.12. Как правило, участники каждой связи на ERдиаграмме соединяются линиями с метками 1, М или N, определяющими
показатель кардинальности этой связи.
Staff_No
Staf f
Branch_No
Manages
Branch
Рис. 4.12. ER-модель связи Manages между сущностями Staff и Branch.
Рассмотрим бинарную связь Oversees между сущностями Staff и
Property for Rent. На рис. 4.13 эта связь представлена в виде семантической
сетевой модели.
-99На этой диаграмме показаны отдельные экземпляры связи Oversees
между сущностями Staff и Property_for_Rent. Например, сотрудница с
именем 'Ann Beech' (s2) отвечает за два объекта недвижимости,
расположенных в городе Глазго, с номерами 'PG21' (р1) и 'PG36' (р2), а
сотрудница с именем 'Mary Howe' (s3) - за один объект недвижимости с
номером 'РА14' (р3), расположенный в городе Абердин. Сотрудница с
именем 'Susan Brand' (s1) не вовлечена в эту связь. Как уже упоминалось
выше, при определении соотношения кардинальности учитываются только
те сущности, которые вовлечены в эту связь. Следует отметить, что одна
сущность типа Staff может быть связана с одной или более сущностями
типа Ргорerty_for_Rent. Следовательно, связь Oversees, с точки зрения
сущности Staff, является связью типа "один ко многим" (1:М).
Значения
Экземпляры
Атрибуты Экземпляры Экземпляры
сущности
сущности
связи
Property_For
Staff
Oversees
_Rent
SG5
Staff_No
Susan Brand
Name
Manager
Position
Атрибуты
Property_No
Address
Type
SG37
Staff_No
Property_No
Address
Значения
PG21
163 Main St,
Glasgow
House
PG36
2 Manor Rd,
Glasgow
Ann Beech
Name
Senior Assistant
Position
SL41
Staff_No
Property_No
PA14
John White
Name
Address
Manager
Position
16 Holhead,
Aberdeen
Type
Type
House
Рис. 4.13. Семантическая сетевая модель связи Oversees между
сущностями Staff и Property_for_Rent
Если рассмотреть связь Oversees с противоположной стороны, то
можно заметить, что с объектами недвижимости в городе Глазго с
номерами 'PG21' (р1) и 'PG36' (р2) работает сотрудница с именем 'Ann
-100Beech' (s2), а с объектом недвижимости в городе Абердин с номером 'РА14'
(р3) - сотрудница с именем 'Mary Howe' (s3). Следует отметить, что одна
сущность типа Property for Rent связана с одной сущностью типа Staff.
Поэтому связь Oversees, с точки зрения сущности Property for Rent,
является связью типа "один к одному" (1:1).
Итак, с точки зрения сущности Staff, связь Oversees является связью
типа 1:М, а с точки зрения сущности Property for Rent - связью типа 1:1.
Однако на ER-диаграммах ее следует представлять с наиболее высоким из
всех существующих показателем кардинальности, т.е. с точки зрения связи
Oversees. Иначе говоря, для связи Oversees показатель кардинальности мы
принимаем равным 1:М. ER-диаграмма связи Oversees между сущностями
Staff и Property for Rent представлена на рис. 4.14. Кардинальность этой
связи подтверждается бизнес-правилом, на основе которого она была
представлена.
Staff_No
Staf f
Property_No
1
Oversees
M
Property _f or_Rent
Рис. 4.14. ER-модель связи Manages между сущностями Staff и Branch
Рассмотрим бинарную связь Advertises между сущностями Newspaper
и Property for Rent. На рис. 4.15 эта связь представлена в виде
семантической сетевой модели.
-101Значения
Glasgow Daily
12 Byres Rd,
Glasgow
Jin McRoberts
Экземпляры
Атрибуты Экземпляры Экземпляры
сущности
сущности
связи
Property_For
Newspaper
Advertises
_Rent
Атрибуты
Значения
Name
Address
Contact
Property_No
Address
Type
PG21
163 Main St,
Glasgow
House
The West News
Name
Property_No
11 Nile St,
Glasgow
Address
Address
Janet Stone
Contact
Aberdeen Express
123 Red Rd,
Aberdeen
Name
Property_No
PA14
Address
Address
16 Holhead,
Aberdeen
Jim Johnson
Contact
PG36
2 Manor Rd,
Glasgow
Type
Type
House
Рис. 4.15. Семантическая сетевая модель связи Advertises между
сущностями Newspaper и Property_for_Rent
На этой сетевой модели показаны отдельные экземпляры связи
Advertises между сущностями Newspaper и Property_for_Rent. Например, в
газете 'Glasgow Daily' (n1) рекламируются два объекта недвижимости с
номерами 'PG21' (p1) и 'PG36' (р2), а в газете 'Aberdeen Express' (n3) - один
объект недвижимости с номером 'РА14' (р3). Можно заметить, что одна
сущность типа Newspaper может быть связана с одной или больше
сущностями типа Property for Rent. Следовательно, связь Advertises, с
точки зрения сущности Newspaper, является связью типа "один ко многим"
(1:М).
Если рассмотреть связь Advertises с противоположной стороны, то
можно заметить, что объект недвижимости с номером 'PG36' (р2)
рекламируется в газетах 'Glasgow Daily' (n1) и 'The West News' (n2).
Отсюда следует, что одна сущность типа Property for Rent может быть
связана с одной или больше сущностями типа Newspaper. Поэтому связь
-102Advertises, с точки зрения сущности Property_for_Rent, также является
связью "один ко многим" (1:М).
Итак, связь Advertises является связью типа 1:М и с точки зрения
сущности Newspaper, и с точки зрения сущности Property_for_Rent. Она
представлена в виде двух связей типа "один ко многим" (1:М), которые
вместе образуют связь типа "многие ко многим" (M:N). Иначе говоря,
показатель кардинальности связи Advertises равен M:N. ER-диаграмма
связи Advertises между сущностями Newspaper и Property_for_Rent
представлена на рис. 4.16. Кардинальность этой связи подтверждается
бизнес-правилом, на основе которого она была представлена.
Newspaper_
Name
Newspaper
Property_No
M
Advertises
N
Property _f or_Rent
Рис. 4.16. ER-модель связи Manages между сущностями Staff и Branch
2.2.2. Степень участия
Степень
участия. Определяет, зависит ли существование некоторой
сущности от участия в связи некоторой другой сущности.
Существует два варианта участия сущности в связи: полное (total) и
частичное
(partial).
Степень
участия
является
полной,
если
для
существования некоторой сущности требуется существование другой
сущности, связанной с ней определенной связью. В противном случае
степень участия является частичной. Например, в случае связи IsAllocated
между сущностями Branch и Staff участие сущности Branch в этой связи
является полным, поскольку каждое отделение компании имеет некоторый
персонал. Однако, поскольку некоторые работники (например, торговые
-103агенты) не относятся ни к какому конкретному отделению компании, то
участие сущности Staff в связи IsAllocated является частичным.
На рис. 4.17 эти ограничения представлены в схематическом виде на
примере связи IsAllocated между сущностями Branch и Staff. Полную
степень участия иногда называют обязательным участием (mandatory), а
частичную - необязательным (optional). Участники связи с полным
участием соединяется со значком связи двойной линией, а участники связи
с частичным участием - одинарной линией.
Branch_No
Branch
Staff_No
1
IsAllocated
M
Staf f
Рис. 4.17. Степень участия сторон в связи IsAllocated между сущностями
Branch и Staff
Допустимо использование и альтернативного варианта обозначений
структурных ограничений, накладываемых на некоторую связь, который
предусматривает отображение максимальных (Мах) и минимальных (Min)
значений
в
виде
надписи
(Min,
Max)
над
линией
соединения,
обозначающей участие сущности в данной связи. Например, на рис. 4.18
эти обозначения применены в отношении связи IsAllocated между
сущностями Branch и Staff. Подобная система обозначений полезна тем,
что иногда позволяет отобразить больше информации о степени участия
сторон для данной связи. Например, обозначение (5, N) между сущностью
Branch и связью IsAllocated
(см. рис. 4.18) указывает, что о каждом
отделении компании работает, по крайней мере, 5 сотрудников (Min = 5), а
максимальное их количество не ограничено (Мах = N). Аналогично,
обозначение (0, 1) между сущностью Staff и связью IsAllocated указывает,
-104что сотрудник не обязательно работает в каком-то из отделений компании
(Min = 0), но работать одновременно в нескольких отделениях он не может
(Мах = 1). Такую информацию нельзя получить только на основе
показателя кардинальности.
Branch_No
Branch
Staff_No
(5,N)
IsAllocated
(0,1)
Staf f
Рис. 4.18. Ограничения участия сторон для связи IsAllocated между
сущностями Branch и Staff представлены с использованием
альтернативной системы обозначений (Min, Max)
4.3. Проблемы ER-моделирования
В этом разделе рассматриваются некоторые проблемы, которые могут
иметь место при разработке концептуальной модели данных. Эти
проблемы, которые принято называть ловушками соединения (connection
trap), обычно возникают вследствие неправильной интерпретации смысла
некоторых связей. Мы рассмотрим два основных типа ловушек
соединения: ловушку разветвления (fan trap) и ловушку разрыва (chasm
trap), а также укажем способы идентификации и устранения этих проблем
в создаваемых ER-моделях. Здесь, однако, следует отметить, что очень
важно всегда проверять модель данных на наличие потенциальных
ловушек соединения, поскольку в одних случаях это может иметь лишь
незначительные последствия, тогда как в других - для устранения ловушек
может потребоваться выполнить перестройку всей концептуальной
модели.
-105В общем случае для выявления ловушек соединения необходимо
гарантировать, что смысл каждой связи четко и ясно определен. При
недостаточном понимании сути установленных связей можно построить
модель, которая не будет являться истинным представлением реального
мира.
4.3.1. Ловушки разветвления
Ловушка разветвления имеет место в том случае, когда модель
отображает связь между типами сущностей, но путь между отдельными
сущностями этого типа определен неоднозначно.
Ловушка разветвления возникает в случае, когда две или больше
связей типа 1:М разветвляются из одной сущности. Потенциальная
ловушка разветвления показана на рис. 4.19, на котором две связи типа
1:М (IsAllocated и Operates) выходят из одной и той же сущности Division.
Рассмотрев показанную на рис. 4.19 ER-модель, можно сделать вывод,
что один отдел (Division) может быть представлен сразу в нескольких
отделениях компании (Branch) и в нем может работать многочисленный
штат сотрудников. Проблемы начинаются при попытках выяснить, в каком
отделении компании работает каждый из сотрудников отдела. Для
исследования этой проблемы рассмотрим показанную на рис. 4.19 ERмодель на уровне отдельных сущностей, для чего представим ее в виде
семантической сетевой модели - (рис. 4.20).
С помощью семантической сетевой модели попробуем ответить на
такой вопрос: "В каком отделении компании работает сотрудник с
номером 'SG37'?". К сожалению, на этот вопрос нельзя дать ответ,
используя
только
данную
структуру.
Из
семантической
модели,
показанной на рис. 4.20, можно сделать вывод, что этот сотрудник
работает в отделении 'ВЗ' или 'В7'. Неспособность дать точный ответ на
-106поставленный вопрос является результатом ловушки разветвления,
связанной с неправильной интерпретацией связей между сущностями Staff,
Division и Branch. Устранить эту проблему можно путем перестройки ERмодели для представления правильного взаимодействия между этими
сущностями - так, как показано на рис. 4.21.
Division
1
1
IsAllocated
Operates
M
M
Staf f
Branch
Рис. 4.19. Пример ловушки разветвления.
Экземпляры
сущности
Staff
Экземпляры
связи
IsAllocated
SG37
r1
Экземпляры
сущности
Division
Экземпляры
связи
Operates
Экземпляры
сущности
Branch
r4
B3
r5
B7
r6
B5
D1
SA9
r2
D2
SL21
r3
Рис. 4.20. Семантическая сетевая модель ER-модели,
показанной на рис. 4.19.
-107Branch
M
1
Operates
IsAllocated
1
M
Division
Staf f
Рис. 4.21. Пример преобразования представленной на рис. 5.20 ER-модели
с целью устранения ловушки разветвления.
Экземпляры
сущности
Division
Экземпляры
связи
Operates
Экземпляры
сущности
Branch
Экземпляры
связи
IsAllocated
Экземпляры
сущности
Staff
r1
B3
r4
SG37
r2
B7
r5
SA9
r3
B5
r6
SL21
D1
D2
Рис. 4.22. Семантическая сетевая модель ER-модели,
представленной на рис. 4.21.
2.3.2. Ловушки разрыва
Ловушка разрыва появляется в том случае, когда в модели
предполагается наличие связи между типами сущностей, но не существует
пути между отдельными сущностями этих типов.
Ловушка разрыва может возникнуть при наличии связи с частичным
участием, образующей часть пути между связанными сущностями. На рис.
4.23 потенциальная ловушка разрыва показана на примере связей между
сущностями Branch, Staff и Property_for_Rent. Рассмотрев представленную
-108ER-модель, можно сделать вывод, что одно отделение компании имеет
много сотрудников, которые работают со сдаваемыми в аренду объектами.
Однако, не все сотрудники непосредственно работают с объектами, а
также не все сдаваемые в аренду объекты недвижимости в каждый
конкретный момент находятся в ведении кого-либо из работников
компании. В данном случае проблема возникает, когда необходимо
выяснить, какие объекты недвижимости приписаны к тому или иному
отделению компании. Для исследования этой проблемы рассмотрим
представленную на рис. 4.23 ER-модель на уровне семантической сетевой
модели, показанной на рис. 4.24.
Staf f
M
1
IsAllocated
Oversees
1
M
Branch
Property_f or_Rent
Рис. 4.23. Пример ловушки разрыва
Экземпляры
сущности
Branch
Экземпляры
связи
IsAllocated
Экземпляры
сущности
Staff
Экземпляры
связи
Oversees
Экземпляры
сущности
Property_for_Rent
B3
r1
SG37
r4
PG36
B7
r2
SA9
B5
r3
SL21
PA14
r5
PL94
Рис. 4.24. Семантическая сетевая модель ER-модели, представленной на
рис. 4.23
-109-
С помощью этой семантической сетевой модели попробуем ответить
на следующий вопрос: "Какое отделение компании отвечает за работу с
объектом под номером 'РА14'?". К сожалению, на данный вопрос нельзя
дать ответ, поскольку этот объект в текущий момент не связан ни с одним
из сотрудников, работающих в каком-либо из отделений компании.
Неспособность дать ответ на заданный вопрос рассматривается как утрата
информации (поскольку известно, что объект недвижимости должен быть
приписан к какому-то отделению компании), в результате которой и
возникает ловушка разрыва. Частичное участие сущностей Staff и Property
for Rent в связи Oversees означает, что некоторые объекты недвижимости
не могут быть связаны с отделением компании посредством сотрудников.
Следовательно,
для
разрешения
этой
проблемы
следует
ввести
отсутствующую связь Has между сущностями Branch и Property for Rent.
ER-диаграмма, показанная на рис. 4.25, отображает истинные связи между
этими сущностями. Такая структура гарантирует, что нам всегда будут
известны объекты недвижимости, связанные с каждым отделением
компании, включая объекты недвижимости, которые в данный момент не
поручены никому из сотрудников организации. Если теперь исследовать
эту структуру на уровне отдельных сущностей (так, как показано на рис.
4.26), то станет ясно, что мы можем дать ответ на поставленный выше
вопрос: объект недвижимости с номером 'РА14' приписан к отделению
компании с номером 'В7'.
-110Staff
M
1
IsAllocated
Oversees
1
M
1
Branch
M
Has
Property_for_Rent
Рис. 4.25. ER-диаграмма, представленная на рис. 4.25, после переработки
после устранения ловушки разрыва
Экземпляры
сущности
Branch
Экземпляры
связи
IsAllocated
Экземпляры
сущности
Staff
Экземпляры
связи
Oversees
Экземпляры
сущности
Property_for_Rent
B3
r1
SG37
r4
PG36
B7
r2
SA9
B5
r3
SL21
PA14
r5
PL94
Экземпляры
связи
Has
r6
r7
r8
Рис. 4.26. Семантическая сетевая модель ER-модели, представленной на
рис. 4.25
-111-
4.4. EER-модель
Рассмотренных выше понятий ER-моделирования вполне достаточно
для представления большинства схем баз данных в традиционных
административно-управленческих приложениях. Однако, начиная с 80-х
годов, стали быстро распространяться многие новые типы приложений баз
данных - например, инструменты автоматизированного проектирования
(Computer Aided Design - CAD), инструменты автоматизированной
подготовки производства (Computer Aided Manufacturing
- САМ),
инструменты автоматизированного проектирования и создания программ
(Computer
Aided
Software
Engineering
-
CASE),
мультимедийные
приложения. Эти типы приложений предъявляют к базам данным более
строгие требования, чем традиционные административно-управленческие
приложения. Поэтому основных понятий ER-моделирования оказалось
недостаточно для удовлетворения новых требований, выдвигаемых все
более усложнявшимися приложениями. Подобная ситуация стимулировала
разработку дополнительных концепций семантического моделирования.
Предлагались разные семантические модели данных, причем некоторые из
них были успешно включены в исходную ER-модель. Такая ER-модель,
дополненная новыми семантическими концепциями, получила название
расширенной ER-модели (или EER-модели (Enhanced ER)).
EER-модель
дополнительные
включает
концепции
все
концепции
ER-модели
специализации/генерализации
плюс
и
категоризации. В этом разделе описываются эти новые понятия, а также
иллюстрируется способы их представления в EER-моделях.
Концепции специализации/генерализации и категоризации связаны с
близкими им понятиями типов сущностей, называемых суперклассами и
-112подклассами, а также с процессом наследования атрибутов. Этот раздел
начинается с краткого вводного описания этих родственных понятий.
4.4.1. Суперклассы и подклассы типов сущностей
Как уже обсуждалось в предыдущем разделе, тип сущности - это
множество сущностей одного типа, например Staff, Branch или Property for
Rent.
Суперкласс – это тип сущности, включающий разные подклассы,
которые необходимо представить в модели данных.
Подкласс является типом сущности, который исполняет отдельную
роль, а также является членом суперкласса.
В некоторых случаях тип сущности может иметь несколько разных
подклассов. Например, для типа сущности Staff отдельные экземпляры
этой сущности можно классифицировать как подтипы Manager, Secretary и
Sales Personnel. Иначе говоря, сущность Staff можно рассматривать как
суперкласс для подклассов Manager, Secretary и Sales Personnel. Связь
между суперклассом и любым его подклассом называется связью
"суперкласс/подкласс". Например, связь Staff/Manager является связью
типа "суперкласс/подкласс".
Каждый член подкласса является членом суперкласса. Другими
словами, член подкласса является сущностью суперкласса и в то же время
играет собственную отдельную роль. Связь между суперклассом и
подклассом относится к типу "один к одному" (1:1). Некоторые
суперклассы могут содержать перекрывающиеся подклассы. Например,
сотрудник может быть одновременно менеджером (Manager) и торговым
агентом (Sales_Personnel). В этом примере подклассы Manager и Sales
Personnel являются перекрывающимися подклассами суперкласса Staff.
Однако не каждый член суперкласса обязательно должен быть членом
-113какого-либо подкласса - например, это могут быть рядовые сотрудники, не
играющие какой-либо особой роли в организации.
Суперклассы и подклассы могут использоваться с целью исключения
описания различных типов персонала с (возможно) разными атрибутами
внутри одной сущности. Например, торговые агенты (Sales Personnel)
могут иметь особые атрибуты Car Allowance (Компенсация транспортных
расходов), Sales Area (Район сбыта) и т.д. Если все атрибуты сотрудников
и особые атрибуты для выполнения отдельных работ будут описаны в
одной сущности Staff, то это может привести к появлению большого
количества неопределенных значений (NULL) атрибутов, описывающих
отдельные виды работ. Очевидно, что подкласс Sales_Personnel имеет
указанные общие атрибуты со сведениями о других сотрудниках например, таких как Staff_No, Name, Address и DOB. Однако именно не
используемые совместно атрибуты могут вызывать проблемы при
представлении сведений обо всех сотрудниках с помощью одной
сущности. Можно также показать связи, которые имеются только для
отдельных групп работников (подклассов), но не для всех сотрудников в
целом. Так, подкласс Sales Personnel может иметь отдельные связи,
которые не подходят для всех сотрудников, например связь Де-guires
(Требует) между сущностями Sales Personnel и Car (Автомобиль).
Существует
две
причины
введения
понятий
суперклассов
и
подклассов в ER-модель. Во-первых, это позволяет избежать повторного
описания сходных понятий, что сэкономит время проектировщика и
повысит читабельность ER-диаграмм. Во-вторых, при проектировании в
базы данных включается больше семантической информации в форме,
более привычной для многих людей. Например, в утверждениях
"менеджер ЯВЛЯЕТСЯ сотрудником" и "квартира ЯВЛЯЕТСЯ типом
собственности"
в очень
семантическая информация.
краткой
форме
содержится
значительная
-1144.4.2. Наследование атрибутов
Как упоминалось выше, сущность в подклассе представляет тот же
объект реального мира, что и ее суперкласс, и может обладать атрибутами,
как связанными с суперклассом, так и специфическими для данного
подкласса. Например, подкласс Sales_Personnel обладает всеми атрибутами
суперкласса Staff (т.е. атрибутами Staff_No, Name, Address и DOB), а также
специфическими атрибутами подкласса Sales_Personnel (т.е. атрибутами
Car Allowance и Sales Area).
Подкласс также является сущностью, а потому может иметь свои
собственные подклассы. Сущность, ее подклассы, подклассы данных
подклассов и так далее - все это называется иерархией типа (type
hierarchy). Иерархии типов могут иметь разные названия: иерархия
специализации (specialization hierarchy) - например, подкласс Manager
является специализацией суперкласса Staff; иерархия генерализации
(generalization
hierarchy)
-
например,
суперкласс
Staff
является
генерализацией подкласса Manager; иерархия принадлежности (IS-A
hierarchy) - например, менеджер (подкласс Manager) является сотрудником
(принадлежит суперклассу Staff). В следующих разделах процессы
специализации и генерализации описываются более подробно.
4.4.3. Специализация
Специализация
–
это
процесс
увеличения
различий
между
отдельными членами типа сущности за счет выделения их отличительных
характеристик.
Специализация
представляет
собой
нисходящий
подход
к
определению множества суперклассов и связанных с ними подклассов.
Множество подклассов определяется на основе некоторых отличительных
характеристик отдельных сущностей суперкласса. При выявлении набора
-115подклассов некоторого типа сущности выполняется также выделение
специфических
для
каждого
подкласса
атрибутов
(в
случае
необходимости), а также выделение любых связей, существующих между
каждым подклассом и другими типами сущностей или подклассами (также
в случае необходимости).
LName
FName
Address
Name
Branch
1
IsAllocated
M
Staff
DOB
Staff_No
1
o
Manages
1
Manager
Bonus
Secretary
Typing_
Speed
Sales_
Personnel
Sales_
Area
Car_
Allowance
Рис. 4.27. Специализация сущности Staff по подклассам на основе
служебных ролей
Рассмотрим,
например,
процедуру
специализации,
в
которой
идентифицируется множество подклассов суперкласса Staff, включая
подклассы Manager, Secretary и Sales Personnel. Ее можно представить
схематически - в виде EER-диаграммы, показанной на рис. 4.27. Обратите
внимание, что суперкласс Staff и его подклассы, которые также являются
типами сущностей, здесь обозначены прямоугольниками. Подклассы
специализации соединяются линиями с кружком, который, в свою очередь,
-116соединяется с суперклассом. Символ принадлежности множеству на
каждой линии, соединяющей подкласс с кружком, указывает направление
связи "подкласс/суперкласс" (например, Manager с Staff). Символ " " в
кружке
специализации
обозначает
накладываемое
на
связь
"подкласс/суперкласс" ограничение.
Специфические для каждого подкласса атрибуты непосредственно
соединяются линиями с прямоугольником, обозначающим этот подкласс.
Например, на рис. 4.27 атрибуты Car Allowance и Sales_Area связаны
только с подклассом Sales Personnel, a это означает, что они не могут быть
применены к подклассу Manager или Secretary. Аналогичным образом
выделены атрибуты, специфические для подклассов Manager (атрибут
Bonus) и Secretary (атрибут Typing Speed),
Обратите внимание на то, что на ERR-диаграмме могут быть указаны
связи, которые применимы только к отдельным подклассам. Например,
подкласс Manager связан с сущностью Branch посредством связи Manages,
в то время как сущность Staff связана с сущностью Branch посредством
связи IsAllocated (см. рис. 4.27).
Для одной и той же сущности можно выделить несколько
независимых специализаций, основываясь на разных ее характеристиках.
Например, в другой специализации сущности Staff могут быть выделены
подклассы Full Time Permanent (Постоянный работник) и Part_Time
Temporary (Временный работник), отличающиеся типом установленного с
данным работником соглашения о найме. Обе специализации типа
сущности Staff на подклассы служебных ролей и подклассы вида
установленного соглашения о найме показаны на рис. 4.28.
На этом рисунке также показаны атрибуты, которые специфичны для
подклассов Full_Time_Permanent (Salary_Scale и Holiday Allowance) и
Part_Time_Temporary (Hourly_Rate). Символ d в кружке специализации
представляет ограничение, накладываемое на связь "суперкласс/подкласс".
-117Подкласс также может иметь свои собственные подклассы, которые
образуют иную иерархию специализаций. Как показано на рис. 4.29,
сущность Sales_Trainee является подклассом двух подклассов Sales
Personnel и Trainee. Подкласс с несколькими суперклассами называется
совместно используемым подклассом (shared subclass). Иначе говоря, член
совместно используемого подкласса Sales Trainee одновременно должен
быть членом подклассов Sales Personnel и Trainee. В результате атрибуты
подкласса Sales Personnel (Sales Area и Car Allowance) и подкласса Trainee
(Start Date) наследуются подклассом Sales Trainee, который также обладает
своим собственным дополнительным атрибутом Sales Target. Подобный
процесс называется множественным наследованием (multiple inheritance).
LName
FName
Address
Name
Branch
1
IsAllocated
M
Staff
DOB
Staff_No
1
o
Manages
d
1
Manager
Bonus
Secretary
Typing_
Speed
Sales_
Personnel
Sales_
Area
Full_Time_
Permanent
Car_
Allowance
Salary_
Scale
Part_Time_
Temporary
Holiday_
Allowance
Hourly_
Rate
Рис. 4.28. Специализация сущности Staff на подклассы служебных ролей и
подклассы вида установленного соглашения о найме
-118LName
FName
Name
Address
DOB
Staff
Staff_No
o
Manager
Secretary
Trainee
Sales_
Personnel
Sales_
Trainee
Start_
Date
Bonus
Typing_
Speed
Sales_
Area
Car_
Allowance
Sales
Target
Рис. 4.29. Пример совместно используемого подкласса Sales_Trainee
(множественное наследование)
2.4.4. Генерализация
Генерализация – это процесс сведения различий между сущностями к
минимуму путем выделения их общих характеристик.
Генерализация представляет собой восходящий подход, который
позволяет создать обобщенный суперкласс на основе различных исходных
подклассов.
Процесс
генерализации
можно
рассматривать
как
противоположный процессу специализации. Давайте, рассмотрим модель,
в которой Manager, Secretary и Sales Personnel представлены как отдельные
типы сущностей. Применение метода генерализации к этим сущностям
заключается в поиске любых сходств между ними, т.е. выделении их
общих атрибутов и связей. Как упоминалось выше, эти сущности
совместно используют атрибуты, общие для всех сотрудников компании.
-119Поэтому
сущности
Manager,
Secretary
и
Sales
Personnel
можно
рассматривать как подклассы обобщенного суперкласса Staff, что и
показано на рис. 4.27.
4.4.5. Ограничения, накладываемые на процедуры специализации
и генерализации
В этом разделе мы рассмотрим ограничения, которые могут быть
наложены на процедуры специализации и генерализации. Здесь мы
обсудим возможные ограничения только в отношении специализации,
однако эти же соображения в равной степени применимы и к процедуре
генерализации.
Первое
ограничение
называется
ограничением
непересечеиия (disjoint constraint). Оно гласит, что если подклассы
некоторой специализации не пересекаются, то каждая отдельная сущность
может быть членом только одного из подклассов данной специализации.
Для
представления
непересекающейся
(disjoint)
специализации
используется символ "d", который располагается в центре кружка,
соединяющего подклассы данного суперкласса. Например, показанные на
рис. 4.28 подклассы видов принятых соглашений о найме (Full Time
Permanent и Part Time Temporary) являются непересекающимися. Этот
значит, что сотрудник может установить с компанией либо соглашение о
полной постоянной занятости, либо соглашение о частичной временной
занятости.
Если подклассы специализации пересекаются, в таком случае
сущность
может
специализации.
быть
Для
членом
представления
сразу
нескольких
пересекающейся
подклассов
(nondisjoint)
специализации используется символ "о", который располагается в центре
кружка, соединяющего подклассы данного суперкласса. Например,
показанные на рис. 4.28 подклассы специализации служебных ролей
-120(Manager, Secretary, Sales Personnel) являются пересекающимися. В данном
примере это значит, что сотрудник может быть одновременно и
менеджером (т.е. членом подкласса Manager), и торговым агентом (т.е.
членом подкласса Sales_Personnel).
Второе ограничение специализации называется ограничением участия
(participation constraint), оно может быть полным или частичным.
Специализация с полным участием означает, что каждая сущность
суперкласса должна быть членом подкласса этой специализации. Для
обозначения
полного
участия
между
суперклассом
и
кружком
специализации проводят двойную линию. Например, на рис. 4.28
специализация типов соглашений о найме характеризуется полным
участием, при котором каждый сотрудник компании должен установить с
ней соглашение о полной постоянной или частичной временной занятости.
Специализация с частичным участием означает, что сущность не
обязательно должна быть членом любого подкласса этой специализации.
Для обозначения частичного участия между суперклассом и кружком
специализации проводят одинарную линию. Например, на рис. 4.28
специализация служебных ролей характеризуется частичным участием,
при котором сотрудник не обязательно должен выполнять одну
дополнительных служебных ролей - менеджера (т.е. быть членом
подкласса), секретаря (т.е. быть членом подкласса Secretary) или торгового
агента (т.е. быть членом подкласса Sales_Pereonnel).
Ограничения
пересечения
и
участия
для
специализации
и
генерализации отличаются. Их принято делить на следующие четыре
категории: непересекающиеся полные, непересекающиеся частичные,
пересекающиеся полные и пересекающиеся частичные.
-1214.4.6. Категоризация
Категоризация – это моделирование одного подкласса со связью,
которая охватывает несколько разных суперклассов.
Каждая
используемые
связь
"суперкласс/подкласс"
подклассы)
иерархии
(включая
совместно
специализации/генерализации
обладает единственным и отличным от других суперклассом. Например,
совместно используемый подкласс Sales_Trainee (см. рис. 4.29) имеет две
разные связи типа "суперкласс/подкласс", каждая из которых включает
единственный суперкласс. Однако в некоторых ситуациях может
потребоваться смоделировать связь "суперкласс/подкласс", включающую
сразу несколько разных суперклассов. В этом случае создаваемый
подкласс будет называться категорией (category) (Elmasri, 1994).
Например, на рис. 4.30 показаны две категории Property Owner и
Property. Категория Property_Owner связана с двумя суперклассами с
разными типами сущности, а именно с Person и Business. Категория
Property связана с двумя другими, но также различными суперклассами, а
именно с Property_for_Sale и Property_for_Rent. Линия, соединяющая
подкласс-категорию с кружком категоризации, помечается символом
принадлежности множеству, а в кружок категоризации помещается символ
объединения.
Подкласс категории обладает выборочным наследованием (selective
inheritance). Это означает, что каждый экземпляр сущности категории
наследует атрибуты только одного суперкласса. Например, на рис. 5.31
каждая сущность типа Property Owner может наследовать атрибуты только
суперкласса Parson (Name, Address и Tel No) или только суперкласса
Business (BName, BAddress, Tel No и Fax No).
-122Name
Address
BName
Tel_No
BAddress
Selling
Price
Closing
Date
Rent
Tel_No
Person
Business
Fax_No
Property_
For_Sale
Property_
For_Rent
U
U
1
Property
M
Owns
Property
Address
Property_
No
Type
Рис. 4.30. Категории Property_Owner и Property
Как
и
операция
специализации/генерализации,
операция
категоризации может быть дополнительно детализирована с учетом
полного или частичного участия сторон. При полном участии каждый
экземпляр всех суперклассов должен быть представлен в данной
категории, что обозначается двойной линией, соединяющей подкласскатегорию с кружком категоризации. При частичном участии это
ограничение
устраняется
и
всем
экземплярам
всех
суперклассов
присутствовать в данной категории не обязательно, что обозначается
одинарной
линией,
соединяющей
подкласс-категорию
с
кружком
категоризации. Например, категория Property_Owner характеризуется
частичным участием, так как не все экземпляры суперклассов Person и
Business должны быть представлены в этой категории. В то же время
категория Property характеризуется полным участием, поскольку каждый
член суперклассов Property_for_Sale и Property_for_Rent является членом
этой категории.
-123Selling
Price
Closing
Date
Rent
Property_
For_Sale
Property_
For_Rent
d
Property
Property_
No
Address
Type
Рис. 4.31. Пример специализации/генерализации сущности Property
Если категория характеризуется полным участием (например, как
категория Property), то существует возможность представления сущностей
с
помощью
операций
специализации/генерализации.
Хотя
выбор
конкретного используемого варианта остается за разработчиком, тем не
менее операции специализации/генерализации целесообразнее применять
для представления сущностей одного типа, чтобы они могли совместно
использовать наибольшее количество атрибутов, включая первичный
ключ. Таким образом, представление сущности Property_0wner выгоднее
сохранять в виде категории, а представление сущности Property
эффективнее
осуществлять
с
помощью
специализации/генерализации - как показано на рис. 4.31.
средств
-124-
5. ПРИМЕР ПРОЕКТИРОВАНИЯ ИС
«ПОДГОТОВКА УЧЕБНЫХ ПЛАНОВ»
Высшее учебное заведение (ВУЗ) имеет иерархическую структуру,
основными подразделениями которой являются деканаты, кафедры и
учебно-методический отдел. Одной из основных задач деканатов является
составление и формирование рабочих учебных планов специальностей, а
учебно - методического отдела - распределение нагрузки для кафедр
института. Осуществлять планирование учебного процесса на практике в
масштабах всего ВУЗа очень сложно, особенно если этот процесс
производится вручную, без использования соответствующих программно аппаратных средств. Поэтому возникает необходимость в разработке
автоматизированной
информационной
системы
(АИС)
"Подготовка
учебных планов", которая позволит облегчить работу сотрудников
деканата и учебно-методического отдела института.
5.1. Описание предметной области
Основным документом, регулирующим работу ВУЗа, является
рабочий учебный план по заданной специальности. В утверждении и
корректировке каждого учебного плана принимают участие следующие
подразделения ВУЗа: ректорат, деканат, учебно-методический отдел,
кафедры. Опишем подробнее этапы создания учебного плана. Деканату
предоставляется примерный учебный план для данной конкретной
специальности. Этот план предусматривает обязательный объем занятий
студентов, который дифференцируется по видам учебной нагрузки и
утверждается на пять лет. В соответствии с этим планом деканат
составляет рабочий план для данной
специальности на учебный год.
После составления рабочих учебных планов для всех специальностей
-125всеми деканатами учебный отдел института осуществляет распределение
нагрузки
по кафедрам. В зависимости от специализации кафедры,
контингента студентов, видов учебной нагрузки студентов по различным
специальностям формируется годовой объем работы кафедры. На основе
рабочих учебных планов печатаются экзаменационная ведомость, зачетная
ведомость, ведомость к курсовому проекту, приложения к диплому
выпускника.
Составляет из
учебного плана
Деканат
Составляет на
основе
рабочего
учебного
плана
Экзаменационная
ведомость
Контролирует
успеваемость
Составляет
приложение
к диплому
Студент
Зачетная
ведомость
Обрабатывается
Учебно методический
отдел
Составляет из
рабочих учебных
планов
Ведомость для
курсового проекта
Заполняются
Определяет объем
рабочей нагрузки
кафедры
Рабочий
учебный план
Выписки
Кафедра
Обрабатывается
Рис. 5.1. Этапы создания и использования рабочего учебного плана
Так как составление рабочего учебного плана очень трудоемкий
процесс, появилась необходимость в создании автоматизированной
информационной системы, которая поможет за более короткий период
времени составлять и обрабатывать
рабочие учебные планы для
специальностей. АИС "Подготовка учебных планов" создавалась с
-126использованием Access XP и
на основе нормативно-справочной
информации, в состав которой входят:
 cписок специальностей;
 cписок направлений;
 cписок кафедр института;
 cписок факультетов института;
 cписок групп;
 cписок студентов;
 eчебный план специальности.
С помощью АИС "Подготовка учебных планов" деканаты будут
создавать рабочие учебные планы.
На основе созданного рабочего учебного плана сотрудники деканата
перед сессией составляют экзаменационные, зачетные ведомости и
ведомости для курсового проекта для данной специальности, на данном
курсе, на данный семестр.
После заполнения ведомостей деканат обрабатывает информацию
об успеваемости каждого студента. В дальнейшем следующей задачей
разработчиков АИС "Подготовка учебных планов" будет создание
электронной учебной карточки студента, в которую каждый год будет
заносится рабочий учебный план, составленный с помощью АИС
"Подготовка учебных планов", и в соответствии с этим рабочим учебным
планом на текущий учебный год, на данный курс, в данном семестре будет
заносится информация об успеваемости студента. Таким образом будет
контролироваться успеваемость студента. После окончания обучения
студента на основе его электронной карточки будет составляться
приложение к диплому выпускника.
После составления рабочего учебного плана на основе нормативно справочной информации, сотрудники учебно-методического отдела с
помощью АИС "Подготовка учебных планов" смогут составлять выписки
-127для кафедр, которые необходимы для определения объема рабочей
нагрузки кафедры на учебный год.
Зачетная ведомость
(по дисцип.)
Экзаменационная
ведомость
(по дисцип.)
Ведомость по
курсовому проекту
(по дисцип.)
Нормативно справочная
информация
АИС
"Подготовка
учебных
планов"
Контроль
успеваемост
и
Объем рабочей
нагрузки кафедры
на учебный год
Приложение
к диплому
выпускника
Рис. 5.2. Функции АИС "Подготовка учебных планов"
Одним из основных документов, на основе которого составляется
рабочий учебный план является учебный план. В учебном плане
содержится следующая информация:
 название направления;
 название специальности;
 шифр дисциплины;
 наименование дисциплины;
 трудоемкость по стандарту для каждой дисциплины;
 количество аудиторных занятий для каждой дисциплины;
 количество часов для самостоятельной
подготовки
каждой дисциплины;
 распределение часов по семестрам для каждой дисциплины;
 форма контроля для каждой дисциплины;
для
-128 среднее количество недель в семестре.
В шифр дисциплины входит следующая кодировка:
XXX.Y.RR.FF.PP
XXX:
ГСЭ - общие гуманитарные и социально - экономические дисциплины
ЕН - общие математические и естественно - научные дисциплины
ОПД - общепрофессиональные дисциплины
СД - специальные дисциплины
Y:
Ф - федеральный компонент
Р - региональный компонент
В - дисциплина по выбору
RR,FF,PP - номера дисциплины
Рабочий учебный план, который содержит следующую информацию:
 название направления;
 название специальности;
 учебный год;
 форма обучения;
 шифр дисциплины;
 название дисциплины;
 шифр кафедры, которая читает данную дисциплину;
 номер курса;
 номер семестра;
 количество недель в семестре;
 количество лекционных занятий в неделю;
 количество практический занятий в неделю;
 количество лабораторных занятий в неделю;
 количество индивидуальных занятий в неделю;
-129 наличие экзамена;
 наличие зачета;
 наличие курсовой работы;
 наличие курсового проекта.
После утверждения проректором по учебной работе рабочего
учебного плана, учебный отдел института составляет выписки из рабочих
учебных планов для каждой кафедры на учебный год.
Выписка содержит в себе следующую информацию:
 название учебной дисциплины, на каком курсе и какой
специальности читается;
 сведение о контингенте студентов на данном курсе и
специальности:
 количество потоков;
 количество групп в составе потока;
 общее количество студентов на потоке.
Распределение часов для каждой дисциплины по видам занятий на
осенний и весенний семестры учебного года:
 лекционные занятия;
 практические занятия,
 лабораторные занятия;
 индивидуальные занятия.
Сведения о формах контроля по каждой дисциплине для каждой
специальности по семестрам:
 зачет;
 экзамен;
 курсовая работа;
 курсовой проект.
-130На основе составленного рабочего учебного плана перед сессией
составляются экзаменационные и зачетные ведомости.
Экзаменационная, зачетная ведомости, а также ведомость к
курсовому проекту содержат в себе следующую информацию:
 название дисциплины;
 ФИО преподавателя;
 название группы;
 список группы.
5.2. Анализ информационных требований пользователя
Указанный процесс определения может быть представлен с помощью
некоторой методики, позволяющей систематизировать процесс выделения
информационных потребностей, получить конечную информацию для
построения EER-диаграмм.
Суть методики заключается в разбиении предметной области
проектируемой системы на отдельные подзадачи, решаемые пользователем
в рамках системы. Разбиение производится в иерархическом порядке,
начиная
с
выделения
независимых
приложений,
которые
затем
разбиваются на функции.
Приложение
-
совокупность
взаимосвязанных
процессов,
информация о которых может быть достаточно точно определена
экспертом (хорошо знающий данную область).
Таблица 5.1.
Состав приложений предметной области
№
Название
приложений
Подготовка
1.
учебных
планов
Код
Описание
TeachPlan
Обработка
информации
предметной
области
"Подготовка учебных планов"
-131Следующим шагом является выделение функций по каждому из
приложений.
Функция - конкретный взаимосвязанный процесс по обработке
данных. Как правило, описание функций есть рекурсивный процесс можно выделить несколько уровней функций и представить в виде дерева
иерархию функций.
Процесс деления происходит до тех пор, пока не приходит простая
функция - задача. Для каждого уровня составляется описание. Как
правило, количество уровней не превышает трех. Для функций низшего
уровня или задач в таблицу добавляется колонка - "тип задачи". Задачи
могут быть либо регламентные, либо оперативные.
Таблица 5.2.
Состав функций приложений "Подготовка учебных планов"
№
Название
функции
1.1.
Данные
о
факультете
1.2.
Данные о
направлении
1.3.
Данные
о
специальности
1.4.
Данные
о
кафедре
1.5.
Данные
о
группе
1.6.
Данные
о
студенте
1.7.
Данные
об
учебном плане
1.8
Данные
о
рабочем
учебном плане
Код
Приоритет
Частота
Описание
Faculty
Н
5/год
Napravlen Н
5/год
Обработка данных
о факультете
Обработка данных о
направлении
Обработка данных
о специальности
Обработка данных о
кафедре
Обработка данных о
группе
Обработка данных о
студенте
Обработка данных
об учебном плане
Обработка данных о
рабочем
учебном
плане
Special
Н
10/год
Chafed
Н
10/год
Group
С
1/месяц
Student
С
1/месяц
T_Plan
С
1/месяц
W_Plan
В
5/месяц
-132Таблица 5.3.
Подфункции функции 1.1
№
Название
функ.
Ввод
1.1.1. данных о
факультет
Запросы
по
1.1.2. факультет
у
Код
Приор
итет
I_Faculty Н
Q_Facult
y
С
Частот
а
1/год
1/меся
ц
Описание
Вид
задачи
Ввод данных
о факультете
Р
Обработка
основных
О
запросов по
данным
о
факультете
Список полей документа для подфункции 1.1.1 "Ввод данных о
факультете":
Номер факультета;
Сокращенное название;
Название факультета;
ФИО декана факультета.
Таблица 5.4.
Список основных запросов для подфункции 1.1.2
№
запроса
1.1.2.1.
1.1.2.2.
Содержание запроса
Просмотр списка всех зарегистрированных факультетов, с
указанием кода, полного названия и сокращенного названия, ФИО
декана факультета
По названию факультета получить список специальностей,
принадлежащих данному факультету
-133Таблица 5.5.
Подфункции функции 1.2
№
функ
ции
1.2.1.
1.2.2.
Название
Ввод
данных о
направлен
ии
Запросы
по
направлен
ию
Код
Приор Частота
итет
I_Naprav
l
Н
1/год
Q_Napra
vl
С
1/месяц
Описание
Вид задачи
Ввод
данных
о Р
направлени
и
Обработка
основных
О
запросов по
данным о
направлени
и
Список полей документа для подфункции 1.2.1:
"Ввод данных о направлении"
Шифр направления обучения;
Название направления.
Таблица 5.6.
Список основных запросов для подфункции 1.2.2
№
запроса
1.2.2.1.
1.2.2.2.
1.2.2.3.
Содержание запроса
Просмотр списка всех зарегистрированных направлений обучения
с указанием шифра и полного названия направления
По названию направления получить список специальностей,
принадлежащих данному направлению (с указанием кода и
полного названия специальностей)
Просмотр списка направлений, по которым ведется подготовка в
институте, с соответствующими специальностями
-134Таблица 5.7.
Подфункции функции 1.3
№
функ
ции
1.3.1
1.3.2
Название
Код
Прио Частота
ритет
Ввод
данных о I_Special Н
специальн
ости
Запросы
по
Q_Special С
специальн
ости
1/год
1/месяц
Описание
Вид задачи
Ввод данных
о
Р
специальнос
ти
Обработка
основных
О
запросов по
данным
о
специальнос
ти
Список полей документа для подфункции 1.3.1 "Ввод данных о
специальности":
Номер факультета;
Форма обучения;
Сокращенное название;
Название специальности;
Код специальности 1;
Код специальности 2;
Код специальности 3;
Шифр направления, к которому принадлежит специальность
-135Таблица 5.8.
Список основных запросов для подфункции 1.3.2
№
запроса
Содержание запроса
Просмотр списка всех зарегистрированных специальностей с
указанием кода, полного названия и сокращенного названия
Получение информации о том, какие занятия предусмотрены для
конкретной специальности по заданной дисциплине в заданном
семестре с указанием количества часов
По названию специальности определить какому направлению
принадлежит данная специальность в заданном учебном году
По названию специальности получить рабочий учебный план за
указанный учебный год
1.3.2.1.
1.3.2.2.
1.3.2.3.
1.3.2.4.
Таблица 5.9.
Подфункции функции 1.4
№
функ
ции
1.4.1.
1.4.2.
Название
Код
Ввод
данных о I_Chafed
кафедре
Запросы
по
Q_Chafed
кафедре
Приор Частота
итет
Н
1/год
С
1/месяц
Описание
Вид задачи
Ввод
данных о Р
кафедре
Обработка
основных О
запросов
по данным
о кафедре
Список полей документа для подфункции 1.4.1. "Ввод данных о
кафедре":
Код кафедры;
Название кафедры;
ФИО зав. кафедры.
-136Таблица 5.10.
Список основных запросов для подфункции 1.4.2
№
запроса
1.4.2.1.
1.4.2.2.
1.4.2.3.
Содержание запроса
Просмотр списка всех зарегистрированных кафедр с указанием
кода и полного названия
По названию кафедры получить список дисциплин, читаемых
данной кафедры в заданном году (с указанием шифра и полного
названия дисциплин)
По названию кафедры получить выписку из рабочих планов
специальностей за указанный учебный год
Таблица 5.11.
Подфункции функции 1.5
№
функ.
1.5.1.
1.5.2.
Название
Код
Ввод
данных о I_Group
группе
Запросы
по
Q_Group
данным о
группе
Прио Частота
рите
т
С
1/месяц
С
1/месяц
Описание
Ввод
данных
о Р
группе
Обработка
основных
О
запросов по
данным о
группе
Список полей документа для подфункции 1.5.1:
"Ввод данных о группе"
Номер курса;
Форма обучения;
Аббревиатура специальности;
Номер группы;
Код специальности 1;
Код специальности 2;
Код специальности 3;
Вид задачи
-137Аббревиатура факультета;
Количество студентов в группе;
Номер зачетной книжки старосты группы.
Таблица 5.12.
Список основных запросов для подфункции 1.5.2
№
запроса
1.5.2.1.
Содержание запроса
Просмотр списка всех зарегистрированных групп
По шифру группы получить список студентов, учащихся в
данной группе
1.5.2.2.
Таблица 5.13.
Подфункции функции 1.6
№
функ
ции
1.6.1.
1.6.2.
Название
Код
Приори
тет
Ввод
данных о I_Student С
студенте
Запросы
по
Q_Student С
данным о
студенте
Частот Описание
а
1/меся
ц
1/меся
ц
Вид задачи
Ввод
данных о Р
студенте
Обработка
основных
О
запросов
по данным
о студенте
Список полей документа для подфункции 1.6.1 "Ввод данных о
студенте":
Номер зачетной книжки;
Фамилия;
Имя;
Отчество;
Номер курса;
Форма обучения;
Аббревиатура специальности;
-138Номер группы;
Аббревиатура факультета;
Код специальности 1;
Код специальности 2;
Код специальности 3.
Таблица 5.14.
Список основных запросов для подфункции 1.6.2
№
запроса
1.6.2.1.
1.6.2.2.
Содержание запроса
Просмотр данных о студенте
По фамилии студента определить на каком факультете, на какой
специальности, в какой группе обучается студент
Таблица 5.15.
Подфункции функции 1.7
№
функ.
1.7.1.
1.7.2.
Название
Код
Ввод
данных об I_TP
учебном
плане
Запросы
по
Q_TP
учебному
плану
Прио Частота
рите
т
Н
1/год
С
2/месяц
Описание
Вид задачи
Ввод
данных об Р
учебном
плане
Обработка
основных
О
запросов по
данным об
учебному
плану
Список полей документа для подфункции 1.7.1. "Ввод данных об
учебном плане":
Внутренний номер дисциплины;
Форма обучения;
Код специальности 1;
Код специальности 2;
-139Код специальности 3;
Код дисциплины1;
Код дисциплины2;
Номер дисциплины1;
Номер дисциплины 2;
Номер дисциплины 3;
Название дисциплины;
Трудоемкость по стандарту;
Количество часов аудиторных занятий;
Количество часов самостоятельной работы;
Количество часов для данной дисциплины в семестре;
Наличие экзамена, зачета, курсовой работы, курсового проекта для
данной дисциплины в семестре;
Таблица 5.16.
Список основных запросов для подфункции 1.7.2
№
запроса
1.7.2.1.
Содержание запроса
Составление рабочего учебного плана на основе данного учебного
плана
-140Таблица 5.17.
Подфункции функции 1.8.
№
функ
ции
1.8.1.
1.8.2.
Название
Код
Ввод
данных о I_WP
рабочем
учебном
плане
Запросы
по
Q_WP
рабочему
учебному
плану
Приор Частота
итет
С
В
2/год
1/день
Описание
Вид
задачи
Ввод данных
о
рабочем Р
учебном
плане
Обработка
основных
О
запросов по
данным
о
рабочем
учебном
плане
Список полей документа для подфункции 1.8.1. "Ввод данных о
рабочем учебном плане":
Внутренний номер дисциплины;
Код дисциплины 1;
Код дисциплины 2;
Номер дисциплины 1;
Номер дисциплины 2;
Номер дисциплины 3;
Шифр направления;
Код специальности 1;
Код специальности 2;
Код специальности 3;
Форма обучения;
Номер курса;
Номер семестра;
Количество недель в семестре;
-141Название дисциплины;
Шифр кафедры;
Количество лекционных занятий в неделю;
Количество практический занятий в неделю;
Количество лабораторных занятий в неделю;
Количество индивидуальных занятий в неделю;
Наличие экзамена;
Наличие зачета;
Наличие курсовой работы;
Наличие курсового проекта.
Таблица 5.18.
Список основных запросов для подфункции 1.8.2
№
запроса
1.8.2.1.
Содержание запроса
Корректировка рабочего учебного плана
5.3. Описание абстрактных объектов данных
Факультет (функция 1.1)
Номер факультета
Название факультета
Сокращенное название
ФИО декана факультета
C2
С75
С4
С30
Направление (функция 1.2)
Шифр
Название
С6
С55
-142Специальность (функция 1.3)
Номер факультета
Форма обучения
Название специальности (сокращенное)
Название специальности (полное)
Код специальности (часть 1)
Код специальности (часть 2)
Код специальности (часть 3)
Шифр направления
С2
С1
С4
С140
С4
С2
С2
С6
Кафедра (функция 1.4)
Код кафедры
Название
ФИО зав. кафедры
С2
С46
С40
Группа (функция 1.5)
Номер курса
Форма обучения
Аббревиатура специальности
Номер группы
Код специальности 1
Код специальности 2
Код специальности 3
Аббревиатура факультета
Количество студентов в группе
Номер зачетной книжки старосты
С1
С1
С4
С1
С4
С2
С2
С4
N2
С6
-143Студент (функция 1.6)
Номер зачетной книжки
Фамилия
Имя
Отчество
Номер курса
Форма обучения
Аббревиатура специальности
Номер группы
Аббревиатура факультета
С6
С25
С14
С18
С1
С1
С4
С1
С4
Код специальности 1
Код специальности 2
Код специальности 3
С4
С2
С2
Учебный план (функция 1.7)
Внутренний номер дисциплины
Форма обучения
Код специальности 1
Код специальности 2
Код специальности 3
Код дисциплины 1
Код дисциплины 2
Номер дисциплины 1
Номер дисциплины 2
Номер дисциплины 3
Название дисциплины
Трудоемкость по стандарту
Количество часов аудиторных занятий
Количество часов индивидуальных занятий
Количество часов для данной дисциплины в
семестре
Наличие экзамена, зачета, курсовой работы,
курсового проекта для данной дисциплины в
семестре.
N5
C1
C4
C2
C2
C3
C1
C2
C2
C2
C140
N4
N4
N4
N2
C2
-144Рабочий учебный план (функция 1.8)
Внутренний номер дисциплины
Форма обучения
Шифр направления
Код специальности 1
Код специальности 2
Код специальности 3
Номер курса
Номер семестра
Количество недель в семестре
Код дисциплины 1
Код дисциплины 2
Номер дисциплины 1
Номер дисциплины 2
Номер дисциплины 3
Название дисциплины
Шифр кафедры
Количество лекционных занятий в неделю
Количество практических занятий в неделю
Количество лабораторных занятий в неделю
Количество индивидуальных занятий в неделю
Наличие экзамена
Наличие зачета
Наличие курсовой работы
Наличие курсового проекта
N5
С1
C6
C4
C2
C2
N1
N2
N2
C3
C1
C2
C2
C2
C140
C2
N3
N3
N3
N3
L1
L1
L1
L1
Дисциплина (функция 1.9)
Внутренний номер дисциплины
Код дисциплины 1
Код дисциплины 2
Наименование
Шифр кафедры
С5
С3
С1
С140
С2
Код специальности 1
Код специальности 2
Код специальности 3
Код дисциплины 1
Код дисциплины 2
Название дисциплины
Номер дисциплины 1
Номер дисциплины 2
Номер дисциплины 3
Трудоёмкость по стандарту
Количество часов аудиторных занятий
Количество часов самостоятельной работы
Количество часов для данной дисциплины в семестре
Форма контроля для данной дисциплины в семестре
С2
С2
С3
С1
С140
С2
С2
С2
N4
N4
N4
N2
C2
Форма обучения
С1
С4
Внутренний номер дисциплины
С5
-145-
5.4. Описание локальных взглядов пользователей и
разработка концептуальной модели данных
На основании описанных выше функций можно построить ЕА-модели
(модели "объект-атрибут"), т.е. определить элементарные агрегаты данных
(объекты), имеющие одинаковые свойства.
Специальность
Дисциплина
1,1
Семестр
*,1
*,1
Учебный план
Учебный план
Рис. 5.1. Обработка данных об учебном плане
-146Составляется
Составляют
Состав
ляется
Рабочий учебный план
1,1
Р
а
б
о
ч
и
й
у
ч
е
б
н
ы
й
п
л
а
н
Учебный план
1,*
Внутренний номер дисциплины
С5
Шифр направления
С6
Код специальности 1
С4
Код специальности 2
С2
Код специальности 3
С2
Форма обучения
С1
Номер курса
N1
Номер семестра
N2
Количество недель в семестре
N2
Код дисциплины 1
C3
Код дисциплины 2
С1
Номер дисциплины 1
Номер дисциплины 2
Номер дисциплины 3
С2
С2
С2
Название дисциплины
С140
Шифр кафедры
С2
Количество лекционных занятий в неделю
N3
Количество практических занятий в неделю
N3
Количество лабораторных занятий в неделю
N3
Количество индивидуальных занятий в неделю
N3
Наличие экзамена
L1
Наличие зачета
L1
Курсового проекта
L1
Курсовой работы
L1
Рис. 5.2. Обработка данных о рабочем учебном плане
-147Номер факультета
Ф
а
к
у
л
ь
т
е
т
С2
Название факультета
С75
Сокращенное название
С4
ФИО декана факультета
С30
Рис. 5.3. Обработка данных о факультете
Н
а
п
р
а
в
л
е
н
и
е
Шифр_направления
С6
Название направления
Специальность
1,1
1,1
Е
1,1
Учебный план
1,1
С55
Е
1,*
Факультет
1,*
Е
1,*
Направление
Е
1,1
Рабочий учебный план
Рис. 5.4. Обработка данных о направлении
-148-
С
п
е
ц
и
а
л
ь
н
о
с
т
ь
Номер факультета
С2
Форма обучения
С1
Название специальности
С140
Аббревиатура специальности
С4
Код специальности 1
С4
Код специальности 2
С2
Код специальности 3
С2
Шифр направления
С6
Рис. 5.5. Обработка данных о специальности
Кафедра
К
а
ф
е
д
р
а
Обучает
1,*
ОбучаетО
Обучается
1,*
Код_кафедры
С2
Название кафедры
С46
ФИО зав. кафедры
С40
Рис. 5.6. Обработка данных о кафедре
Специальность
-149-
Обучается
Студент
Обуча
ется
1,1
Учится
Учится
Специальность
1,*
1,1
Учитс
я
Обучается
1,*
Группа
С
т
у
д
е
н
т
Номер зачетной книжки
С6
Фамилия
С25
Имя
С14
Отчество
С18
Номер курса
С1
Форма обучения
С1
Аббревиатура специальности
С4
Номер группы
С1
Код специальности 1
С4
Код специальности 2
С2
Кож специальности 3
С2
Аббревиатура факультета
С4
Рис. 5.7. Обработка данных о студенте
-150Г
р
у
п
п
а
Номер курса
С1
Форма обучения
С1
Аббревиатура специальности
С4
Номер группы
С1
Код специальности 1
С4
Код специальности 2
С2
Код специальности 3
С2
Аббревиатура факультета
С4
Количество студентов в группе
N2
Номе зачетной книжки старосты
С6
Рис. 5.8. Обработка данных о группе
Дисциплина
Обучает
Преподаётся
Д-К
1,1
1,*
Кафедра
Внутренний номер дисциплины
Код дисциплины 1
Код дисциплины 2
Наименование
Шифр кафедры
C5
C3
C1
C140
C2
Дисциплина
Рис. 5.9. Обработка данных о дисциплине
-151Эта система локальных представлений в виде модели "объектатрибут" является исходной информацией для построения EER-диаграмм и
концептуальной схемы.
Дальнейшим шагом является построение концептуальной схемы
данных (рис. 5.10)
в виде модели "объект-связь" (EER-модели на
локальном уровне), на основе анализа и последовательного объединения
моделей "объект-атрибут".
Дисциплина
1,1
Преподаёт
ся
1,*
Кафедра
Факультет
1,*
1,*
Е
Обуча
ет
1,*
Учится
Студент
Обучается
1,1
Обуча
ется
1,1 Учится
1,* Обучается
Группа
Учится
Специальность
1,*
1,* 1,1
Е
1,*
Направление
Обучается
1,1
1,1
Учитс
я
Обучает
Е
Е
1,1
1,1
Рабочий учебный план
Составляется 1,1
Состав
ляется
Составляют 1,*
Учебный план
Рис. 5.10. EER-диаграмма АИС "Подготовка учебных планов"
-152-
5.5. Отображение концептуальной модели в реляционную
схему данных
Реляционная модель данных является однородной и состоит из
множества отношений. Каждому отношению может быть сопоставлена
некоторая таблица. Каждая таблица, следовательно, и каждое отношение
имеет имя. По имени отношения различаются между собой.
Структура
таблицы
определяется
составом
колонок
таблицы.
Смысловое значение каждой колонки фиксируется в верхней части
таблицы с помощью символьного имени, которое называется атрибутом
отношения. На уровне отношений описываются соответствующие объекты
со своими свойствами из концептуальной схемы. В силу однородности
реляционной модели данных и объекты и связи модели "объект-связь"
соответствуют отношению. Каждый абстрактный объект представляется в
таблице строкой значения. При этом, для каждого атрибута в каждой
строке появляется ровно одно значение. Отношение не может иметь
одинаковых строк, т.к. полностью одинаковые значения - это один и тот же
информационный объект, записанный дважды. Поэтому вводится понятие
ключа.
Ключ - совокупность атрибутов, однозначно выделяющая одну строку
от другой. Ключ является ограничением, накладываемым на реляционную
схему, и неотъемлемым свойством данных. В схеме отношения, кроме
того, могут присутствовать внешние ключи - это ключ одного отношения,
присутствующий в качестве атрибута (неключевого) данного отношения.
Подобными ключами моделируются связи в реляционной схеме, т.к. связь
в реляционной модели неявная, осуществляется по совпадению значений
соответствующих атрибутов.
Каждый атрибут описывает свойства объекта и неявно связан с
некоторым доменом. Как правило, в реальных реляционных СУБД состав
-153доменов
встроен
в
систему
и
является
ограниченным.
Домены
семантически неразличимы.
При отображении ER-диаграмм в реляционную схему пользуются
следующей
методологией:
в
ER-диаграммах
выделяются
типовые
фрагменты (объекты и отношения), а отображения осуществляются по
определенным правилам.
При построении реляционной схемы следует помнить, что:
1)
реляционная
схема
должна
соответствовать
исходной
семантической модели;
2) реляционная схема должна быть высокопроизводительна и удобна
в использовании.
На основе вышесказанного получаем следующее отображение:
Рис. 5.11. Реляционная схема данных
-154-
5.6. Выбор целевой СУБД и реализация АИС
"Подготовка учебных планов"
В качестве целевой СУБД была выбрана Access. В базу данных под
управлением СУБД Access могут входить разнородные объекты. Как
правило, база данных состоит из достаточно большого числа таких
объектов. Список объектов структурирован по категориям (типам)
объектов. Для того чтобы увидеть список объектов некоторого типа,
следует нажать в окне банка кнопку с соответствующей пиктограммой.
Различают следующие типы объектов (и кнопки в окне банка данных):
• Таблица (Table) - набор записей базы данных удобно представлять в
виде таблицы. В этих записях (строках таблицы), состоящих из отдельных
полей, хранится информация и составляющая, собственно, содержание
базы данных.
• Запрос (Query) - запрос можно представить себе как точку зрения на
данные, включённые в таблицу. Запросы служат для селекции или
фильтрации набора данных. Они позволяют выбрать из базы только
необходимую информацию, т.е. ту, которая соответствует определённому
критерию (условию) и нужна для решения конкретной задачи.
• Форма (Form) - формуляр представляет собой бланк, подлежащий
заполнению, или маску, накладываемую на набор данных. Бланк-формуляр
позволяет упростить процесс заполнения банка данными, благодаря чему
появляется возможность поручить ввод информации персоналу невысокой
квалификации. Маска-формуляр позволяет ограничить объём информации,
доступной пользователю, обращающемуся к банку. Речь здесь идёт о
блокировании индикации служебных или засекреченных полей.
• Отчёт (Report) - как правило, выбранная из банка информация
должна быть представлена в виде распечатки - отчёта, оформленного
соответствующим образом. Доступные способы оформления информации
-155в отчётах Access весьма разнообразны и эффективно используют
технологические возможности как оболочки Windows, так и современных
лазерных принтеров.
• Макрокоманда (Macro) – при обработке больших объёмов данных
часто приходится выполнять длинные последовательности действий.
Любые действия могут быть оформлены как макрокоманды. Вызов
макрокоманды
приводит
к
выполнению
соответствующую
данной
макрокоманде последовательность действий. Применение макрокоманд
позволяет
автоматизировать
процессы
заполнения
базы,
выбора
информации и т.д.
• Модуль (Module) - при решении достаточно сложных задач
пользователь очень скоро столкнётся с ограничениями технологии
построения директивных макро-команд. Для преодоления возникших
трудностей
можно
попробовать
написать
собственную
процедуру
обработки информации на языке Access Basic (диалекте языка Visual
Basic). Такая процедура оформляется как модуль. Окно банка данных для
нашего банка данных (Clinic) представлено на рис.
Таблицы являются одним из основных объектов при работе с Access,
на их базе осуществляется построение всех других элементов, таких как
формуляры, запросы и отчёты. В таблице собираются данные по
конкретной теме, например, вся информация о пациентах больницы.
Каждый блок данных (строка) таблицы пациентов содержит информацию
об определённом пациенте. Информация эта может быть неоднородна, и
поэтому блок состоит из нескольких разнотипных полей, содержащих
сведения о фамилии пациента, его домашнем адресе, телефоне и т.д.
Access-база данных может состоять из нескольких таблиц, в каждой из
которых хранится информация на одну тему.
-156Заранее определив какие поля и в какой последовательности должна
содержать таблица мы приступаем к их объявлению. Имена полей
вводятся друг под другом в колонку Field Name (Имя поля). Затем для
каждого поля в колонке Data Type (тип данных) следует установить тип
хранимых в нём данных. В Access предусмотрены следующие типы полей:
Text - Сохраняет цепочку алфавитно-цифровых символов (не более
255 символов).
Memo - Сохраняет текст, длина которого может быть до 32000
символов.
Number - Сохраняет числовые значения (целые или десятичные
числа).
Date/Time - Сохраняет дату и время.
Currency - Сохраняет числа в денежном формате.
Counter - Сохраняет уникальное значение, которое в каждом новом
блоке данных
Access автоматически увеличивает на 1.
Yes/No - Сохраняет логические значения (истинно.ложно).
OLE-Object - Сохраняет OLE-объекты и иллюстрации.
Для того чтобы сделать таблицы понятными непосвящённым, для
каждого поля таблицы можно ввести описание (комментарий) в колонку
Description. Но наличие (или отсутствие) комментария никак не влияет на
корректность спецификации таблицы.
Задание таких характеристик как размер поля, формат и т.д.
выполняется в нижней части окна проектирования.
Каждое поле обладает индивидуальными свойствами, по которым
можно
установить,
как
должны
сохраняться,
индицироваться
и
обрабатываться данные. Набор свойств, присущих полю, зависит от
выбранного типа данных поля.
Характеристики полей:
-157Field Size - определяет максимальную длину текстового или
числового полей.
Format - устанавливает формат индикации данных в формуляре и
запросе.
- определяет количество разрядов справа от
Decimal Places
десятичного знака.
Caption - содержит надпись, которая выводится рядом с полем в
формуляре или отчёте.
Default Value - содержит значение, которое при создании блока
данных
автоматически
вводится
в
качестве
предустановки
в
соответствующее поле.
Validation Rule - описание правила, которое ограничивает множество
доступных для этого поля значений.
Validation Text - каждому правилу отбора допустимых значений
соответствует сообщение о нарушении. Оно выдаётся на экран, когда
пользователь пытается ввести данные, которые не соответствуют правилу
отбора.
Indexed - определяет простые индексы для ускорения процессов
поиска; поле первичного ключа индексируется автоматически.
Прежде чем сохранить спецификацию и приступить к заполнению
пустой таблицы конкретными данными, необходимо определить поле
первичного ключа.
Основным
элементом
приложения
создания/редактирования учебных планов:
является
форма
-158-
Рис. 5.12. Форма «Учебный план»
При создании нового учебного плана используется следующая форма,
в которой выбираются его атрибуты:
Рис. 5.13. Форма для создания нового учебного плана
Для открытия и редактирования существующего учебного плана
необходимо выбрать имя файла из списка в следующей форме:
-159-
Рис. 5.13. Форма для открытия и редактирования существующего учебного
плана
-160-
ЗАКЛЮЧЕНИЕ
Использование предложенной методики проектирования систем баз
данных позволяет автоматизировать решение основных задач этапа
концептуального проектирования баз данных, а также снизить их
размерность.
Проведенный
анализ
существующих
концептуальных
моделей
данных различных классов показал целесообразность использования для
целей концептуального проектирования баз данных моделей типа “объект связь” с n-арными связями и атрибутами для объектов и связей.
Разработанные концептуальная модель данных и язык ее определения
дают возможность описывать предметные области сложной структуры и
адекватно специфицировать множество метаданных, достаточных для
процесса концептуального проектирования систем баз данных.
В настоящем учебном пособии были решены следующие задачи:
1. Подробно изучена предметная область (планирование учебного
процесса
на
практике
в
масштабах
ВУЗа,
характерные
особенности).
2. Проведен анализ информационных требований пользователей
(четко определен состав приложений).
3. Разработана концептуальная схема.
4. Разработана реляционная схема БД и описана методика ее
проектирования.
5. Реализованы на практике в СУБД Access некоторые элементы
пользовательского интерфейса.
-161-
СПИСОК ЛИТЕРАТУРЫ
1. Ацкопян А.Х., Бояров О.Д., Левенчук А.И. Автоматизация
концептуального проектирования баз данных СМ ЭВМ на основе
формализации знаний о предметной области // УС и М. - 1987. - № 3. С. 85 - 87.
2. Ашимов А.А., Тунеев У.А. Планирование работ при разработке
программных комплексов // Программирование. - 1987. - № 3. - С. 71 78.
3. Бойко В.В., Савинков В.М. Проектирование информационной базы
автоматизированной
системы
на
основе
СУБД:
Практическое
руководство. - М.: Финансы и статистика, 1982. - 174 с.
4. Брутян Х.К., Мкртчян Л.В. Об одном методе интеграции баз
данных // Техническая кибернетика. - 1985. - № 5. -С. 29 - 34.
5.
Вишняков
В.А.,
Герман
О.В.
Модель
распределения
информационно-связанных задач в системах проектирования и
управления // Автоматика и вычислительная техника. - 1983. - № 1. С. 14 - 18.
6. Гуд. И.Дж. Ботрилогия ботриологии // Классификация и кластер. М.: Мир, 1980. - С. 66 - 82.
7. Дюран Б., Одел П. Кластерный анализ. - М.: Статистика, 1977. - 128
с.
8. Ерема-Еременко А.А., Минховский С.Д. Модель и язык описания
предметной области // Банки данных: Тез. докл. 2 Всесоюз. конф.
Секция З. Методы и системы проектирования баз данных. - Ташкент,
1983. - С. 20 - 22.
9. Зайцев Н.Г., Завадский П.И., Еремеев Л.Г. Автоматизация
структурной декомпозиции информационной базы АСУ на основе
модульной технологии // УС и М. - 1985. - № 2. - С. 16 - 21.
-16210. Замулин А.В. Типы данных в языках программирования и базах
данных. - Новосибирск: Наука. Сиб. отд - ние, 1987. - 150 с.
11. Интерактивная разработка информационных систем / Геловани
В.А., Безруков Д.И., Братков В.Г. и др. // Техническая кибернетика. 1986. - № 2. - С. 48 - 70.
12.
Инфологическая
модель
в
системе
автоматизированного
проектирования баз данных: концепции построения и реализация /
Вейнеров О.М., Савинков В.М., Жадан Н.В., Казаров М.С. //
Прикладная информатика, 1987. - Вып. 2. - С. 59 - 75.
13. Калиниченко Л.А. Методы и средства интеграции неоднородных
баз данных. - М.: Наука, 1983. - 424 с.
14. Крахт В.А., Росталу Э.П. Проектирование баз данных на основе
реляционно - решетчатой
концептуальной модели предметной
области // УС и М. - 1981. - № 4. -С. 22 -28.
15. Кухаренко Б.Г., Чиронов В.В. Об одной проблеме проектирования
логической
структуры
единой
информационной
базы
//
Программирование. - 1984. - № 4 - С. 72 - 76.
16. Леон - Хонг Б., Плагман Б. Системы словарей-справочников
данных. - М.: Финансы и статистика, 1986. - 311 с.
17. Мартин Дж. Планирование развития автоматизированных систем.
- М.: Финансы и статистика, 1984. - 196 с.
18. Мейер Д. Теория реляционных баз данных. - М.: Мир, 1987. - 608
с.
19. Нечеткие множества в моделях управления и искуственного
интеллекта. - М.: Наука, 1986. - 312 с.
20. Попов Э. В. Экспертные системы. -М.: Наука, 1987. - 288 с.
21. Ринкс Д.Б. Эвристический подход к обобщенному календарному
планированию производства с использованием лингвистических
переменных: Методология и применение // Нечеткие множества и
-163теория возможностей. Последние достижения. - М.: Радио и связь,
1986. - С. 349-370.
22. Савинков В.М., Вейнерв О.М., Казаров М.С. Основные концепции
автоматизации
проектирования
баз
данных
//
прикладная
информатика. - М.: Финансы и статистика, 1982. - Вып. 1. - С.30-41.
23. Сергиенко И.В. Математические модели и методы решения задач
дискретной оптимизации. - Киев: Наукова думка, 1988. - 471 с.
24. Сергиенко И.В., Капшицкая М.Ф. Модели и методы решения на
ЭВМ комбинаторных задач оптимизации. - Киев: Наукова думка,
1982. - 287 с.
25. Сергиенко И.В., Лебедев Т.Т., Рощин В.А. Приближенные методы
решения задач оптимизации. - Киев: Наукова думка, 1980. - 285 с.
26. Соломон Г. Зависящие от данных методы кластер-анализа //
Классификация и кластер. - М.: Мир, 1980. - С. 129 - 147.
27.
Стогний
А.А.,
Азаров
С.С.,
Барсуков
Я.И.
Построение
концептуальной модели системы управления предметной области //
УС и М. - 1988 - № 3. - С. 60 - 67.
28. Тиори Т., Фрай Дж. Проектирование структур баз данных: в 2-х
кн. Кн. 1 . Пер. с англ.-М.: Мир, 1985. - 287 с.
29. Филиппов В.Н. Теоретико - множественный подход к моделям
данных // Банки данных : Материалы 3 Всесоюз. конф. - Таллин. 1985.
-С. 16-25.
30. Хаббард Дж. Автоматизированное проектирование баз данных. М.: Мир, 1984. - 296 с.
31. Цаленко М.Ш. Семантические и математические модели баз
данных. - М.: ВИНИТИ, 1985. - 208 с.
32. Цикритзис Д. , Лоховски Ф. Модели данных. - М.: Финансы и
статистика, 1985. -344 с.
-16433. Abrial I.R. Data semantics // Data Base Management/
-
Amsterdam:North - Holland, 1974. - P. 1 - 59.
35. ANSI/X3/SPARC DBMS framework. Report of the study group on
DBMS // Inf. Syst. - 1978. - v. 3 - N 3.
36. Ashworth C. Structured system anallysis and design method (SSADM)
// Information and Software technology. - 1988. - v.30.- N 3. - P.153-163.
37. Atzeni D., Carboni E. INCOD ( A system for interactive conceptual
design ) revisited after the implementation of a prototypen // Entity Relationship Approach to Information modelling and Analysis. Amsterdam: North-Holland, 1983. - P. 449-464.
38. Batini C., Lenzerini M., Navathe S.B. A Comparative analysis of
Methodologies for Database Shema
Integration // ACM Computing
Survies. - 1986. - V.18.-N4. -P.332-364.
39. Biller H., Neuhold E.I. Semantics of data base: the semantics of data
models // Inf. Syst.- 1978. - V.3.-N3.-P. 351-386.
40. Borgida A., Mylopolus I., Wong H.K.T. Generalization/Specialization
as a Basis for Software Specification // On Conceptual Modelling. - Berlin:
Springer - Verlag, 1984.- P.87-117.
41. Bravaco R.R., Yadav S.B. A Methodology to model the dynamic
structure of an organization // Inf. Syst. - 1985.- V.10.-N3. -P.299-317.
42. Brodie M.L. On the development of Data Models // On Conceptual
Modelling.- Berlin: Springer - Verlag, 1984. - P.19-47.
43. Brodie M.L., Silva E. Active and Passive Component Modelling: ACM
/ PCM // Information Systems design methodologies: a comparative review
- Amsterdam: North-Holland, 1982. - P.41-92.
44. Burns R.N., Dennis A.R. Selecting the Appropriate application
development methodology // Data Base. - 1985. - V.17.- N1.-P.19-23.
45. Chen P.P. Application of the entity - relationship model // Lect. Notes
in comp. Sci. - 1982. - V.132.-P.87-113.
-16546. Chen P.P. Preliminary framework for Entity -Relationship models //
Entity - Relationship Approach to Systems Analysis and Design. Amsterdam: North-Holland, 1981. - P. 103 - 119.
47. Chen Q. A Rule-Based object/task Modelling approach // SIGMOD
Record.- 1986. - V.5.-N2.-P.72-83.
48. Chiang T.C., Beryeron R.I. A data base management system with an
ER conceptual model // Entity-Relationship Approach to System Analysis
and Design. - Amsterdam: North-Holland, 1981.-P.467-476.
49. Codd E.F. Extenting the data base relational model to capture more
meaning // ACM Trans. on Database Systems. - 1979.- V.4.-N4.-P.397 434.
50.Comadeikis S.S., Kanellakis D.C., Spyratos N. Partition Semantics for
Relation // The Jornal of Computer and System Sceinces.-1986.-V.33.-N2.P.203-233.
51. Comparision of analysis techniques for information Requirment
determination / Yadav S.B., Bravaco R.R., Chatfield A.T., Rajkumar T.M.
// Comm. ACM.-1988.- V.31.-N9.-P. 1090-1097.
52. Conners T. Equivalence of Vievs by Query Capacity // Journal of
Computer and System Sciences. - 1986.- V.33.-N2.- P.234-274.
53. Dawson K.S., Parker L.M.P. From Entity-Relationship Diagrams to
Forth Normal Form: A Pictorial Aid to Analysis // Computer Journal. 1988. - V.31.-N3.-P.258 - 268.
54. Emberton J., Mann R. Methodology for effective informstion system
planning // Information and Software Technology. - 1988.-V.30.-N4.P.244-249.
55. Elmasri R., Weeldreyer J., Hevnel A. The category concept: An
extention to the entity-relationship model // Data and Knowledge
Engineering. -1985.-V.1.-N1.-P.75-116.
-16656. Ellis V. A Refined model for definition os System requariments // Data
Base Jornual.-1982.-V.2.-N.3.-P.2-9.
57. Feldman D., Miller P. Entity Modell Clustering: Structuring a Data
Model by Abstraction // The Computer Journal. - 1986.-V.29.-N4.-P.348361.
58. Fitzgerald G., Stokes N., Wood J.R.G. Feature Analysis of
Contemporary Information Systems Methodologies // The Computer
Journal. -1985. - V.28.-N3.-P.223-230.
59. Hammer M., McLeod D. Database Description wich SDM: A Semantic
Database Model // ACM Trans. on Database Systems. - 1981.-V.6.-N3.P.351-386.
60. Implementation of a Compiler for a Semantic Data Model: Experiences
with Taxis / Nixon B., Chang L., Lauzon D., Borgida A. // SIGMOD
Record. -1987.- V.6.- N3.-P.118-131.
61. Information System Mrthodologies.- Britain: Wiely, 1983.- 128 p.
62. ISO TC 97/SC5/W63 N 095. Concepts and terminology for the
concrptual schema and information base, 1982.
63. Jajodia S., Ng P.A., Sprinsteel F.N. The Problem Equivalence for
Entity-Relationship Diagrams // IEEE Trans. on Software Eng.-1983.V.SE-9.-N5.-P254-282.
64. Kerner D.V. Business Information Characterization Study // Data base.
-1979. - V. 10. -N1.-P.10-17.
65. King R., McLeod B. A unified Model and Methodology for Conceptual
Data Base Design // On Conceptual Modelling. - Berlin: Springer - Verlag,
1984. - P. 315 - 327.
66. Knuth E., Halasz F. SDLA System Description and Logical Analysis //
Information sysnem design methodologies: a comporative review. Amsterdam: North-Holand, 1982.- P.143-172.
-16767. Macdonald I.G., Palmer I.R. System Development in a Sared Data
Enviroment the D2S2 Methodology // Information system design
methodologies: a comporative review.- Amsterdam: North-Holland, 1982.P.235-285.
68. Mannino P. A Presentation and Comparision of Four Information
System Development Mrthodologies // Software engeneering Notes. 1987.-V.12.-N2. -P.26-29.
69. Marti R.W. Integrating Dtabase and Program Description using an ERData Dictionary // Entity-Relationship Approach to Software Engeneering.Amsterdam: North-Holland, 1983.-P.377-391.
70. Ng A., Paul J.F. A Formal definition of entity-relationship Model //
Entity-Relationship Approach to System Analysis and Design. Amsterdam: North-Holland, 1981.-P.211-230.
71. Parker M.M. Enterprise Information analysis Costbenefit analiysis and
the data-management system // IBM Syst. Journal - 1982.- V.21.-N1.P.1008-1023.
72. Parrelo B., Overbeek R., Lusk E. The design of entity-relationship
modells for general ladger systems // Data and Knowledge Engeneering. 1985.-V.1.- N1.-P.155-180.
73. Reiter R. Towards a Logical Reconstruction of Relational Database
Teory // On Conceptual Modelling.- Berlin: Springer-Verlag, 1984.-P.191238.
74. Sacco G.M. The fact model: a semantic data model for complex
database // Inf. Syst. -1988. V.13.-N1.-P.1-12.
75. Sacamoto J.G., Ball F.W. Supporting Business Systems Planning
Studies with the DB/DC Data Dictionary // IBM Syst. Journal. - 1982.V.21.- N1.-P.54-80.
76. Senco M.E. A query-maintenance Business Systems Planning Studies
with the DB/DC Data Dictionary // Inf Syst. -1980.-V.5.-N3.-P.257-272.
-16877. Smith J.M., Smith D.C.P. Principles of data base Conceptual design //
Lect. Notes in Comp Sci. - 1982.-V. 132.-P.114-146.
78. Tiechoew D., Macasovic P., Hershey E.A. Application of the EntityRelationship Approach to Information Processing System Modelling //
Entity-Relationship
Approach
to
System
Analysis
and
Design.-
Amsterdam: North-Holland, 1981.- P.15-38.
79. Vertheijen G.M.A., Van Bekkum J. NIAM: Information Analysis
Method // Information System design methodologies: a comparative
review.- Amstredam: North-Holland, 1982.-P.537-590.
80. Weber N.W. An extended entity-relationship Model and its use on a
defense project // Entity-Relationship Approach to Information Modelling
and Analysis.-Amsterdam: North-Holland, 1983.-P.173-194.
81. Zhao L., Roberts S.A. An Object - Oriented Data Model for Data
Modelling, Implementation and Access // The Computer Journal.-1988.V.31.-N2.- P.116-124.
-169-
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .................................................................................................. 3
1. Структура, классификация и состав информационных систем ......... 6
1.1. Понятие информационной системы ............................................... 6
1.2. Классификация информационных систем ..................................... 7
1.3. Структура и состав информационной системы ............................ 9
1.3.1. Функциональные компоненты ИС ........................................ 10
1.3.2. Компоненты системы обработки данных ............................. 13
1.3.3. Организационные компоненты ИС ....................................... 17
1.4. Тенденции развития информационных систем .......................... 18
2. Жизненный цикл информационных систем ....................................... 26
2.1. Модели жизненного цикла информационных систем ............. 26
2.2.
Планирование разработки, определение требований к ИС и
анализ информационных потребностей пользователей ............................ 34
2.3. Проектирование базы данных, выбор целевой СУБД и
проектирование пользовательского интерфейса ....................................... 38
2.4. Реализация проекта ИС ................................................................. 48
3. Структурный подход к проектированию ИС ..................................... 57
3.1.
Понятие метода и технологии проектирования ..................... 57
3.2. Сущность структурного подхода ................................................. 58
3.3. Метод функционального моделирования SADT ........................ 62
3.4. Построение иерархии диаграмм .................................................. 64
3.5. Моделирование потоков данных .................................................. 67
3.5.1. Состав диаграмм потоков данных ......................................... 68
3.5.2. Построение иерархии потоков данных ................................. 71
3.6. Сравнительный анализ SADT-моделей и диаграмм потоков
данных ............................................................................................................ 77
4. Методика проектирования ИС............................................................. 81
-1704.1. Концепции ER-модели .................................................................. 81
4.1.1 Типы сущностей ....................................................................... 81
2.1.2. Атрибуты.................................................................................. 82
4.1.3. Типы связей ............................................................................. 89
4.1.4. Атрибуты связей ..................................................................... 95
2.2. Структурные ограничения ............................................................ 96
2.2.1. Показатель кардинальности ................................................... 96
2.2.2. Степень участия ........................................................................ 102
4.3. Проблемы ER-моделирования .................................................... 104
4.3.1. Ловушки разветвления ......................................................... 105
2.3.2. Ловушки разрыва .................................................................. 107
4.4. EER-модель ................................................................................... 111
4.4.1. Суперклассы и подклассы типов сущностей ..................... 112
4.4.2. Наследование атрибутов ...................................................... 114
4.4.3. Специализация ...................................................................... 114
2.4.4. Генерализация ....................................................................... 118
4.4.5. Ограничения, накладываемые на процедуры специализации
и генерализации ....................................................................................... 119
4.4.6. Категоризация ....................................................................... 121
5. Пример проектирования ИС «Подготовка учебных планов» ....... 124
5.1. Описание предметной области ................................................... 124
5.2. Анализ информационных требований пользователя ............... 130
5.3. Описание абстрактных объектов данных .................................. 141
5.4. Описание локальных взглядов пользователей и разработка
концептуальной модели данных ................................................................ 145
5.5. Отображение концептуальной модели в реляционную схему
данных .......................................................................................................... 152
5.6. Выбор целевой СУБД и реализация АИС "Подготовка учебных
планов" ......................................................................................................... 154
-171Заключение .............................................................................................. 160
СПИСОК ЛИТЕРАТУРЫ ...................................................................... 161