2.2. Проектирование информационно-логической модели базы данных

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

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

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

Создание ИС на основе методологии концептуального проектирования предполагает четыре этапа проектирования:

• сбор и анализ информационных потребностей пользователей и системный анализ предметной области;

• построение концептуальной (понятийной) модели предметной области;

• создание концептуальной модели базы данных;

• разработку системы с помощью инструментальных средств выбранной СУБД.

Заключительный этап проектирования тесно связан с возможностями инструментальных средств конкретных СУБД.

Данный этап в свою очередь разбивают на следующие шаги:

• логическое проектирование БД;

• физическое проектирование БД;

• реализация приложений.

В данном пункте мы рассмотрим этапы построения информационно-логической модели базы данных «……».

2.2.1. Проектирование концептуальной модели бд

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

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

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

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

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

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

Диаграмма прецендентов

Построение концептуальной модели БД начнем с диаграммы прецендентов.

Первым шагом при описании функциональности системы является моделирование требований к ней.

Целями анализа и моделирования требований являются:

• достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;

• достижение лучшего понимания разработчиками поведения ПС;

• ограничение системной функциональности;

• создание базиса для планирования разработки проекта;

• определение пользовательского интерфейса.

Для достижения этих целей используются диаграммы вариантов использования UML (Use case diagrams, диаграммы прецендентов).

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

Актер – это кто-то (или что-то) внешний по отношению к компьютерной системе, кто взаимодействует с ней.

На UML диаграммах пиктограммы прецедента и актера обычно располагаются рядом. В совокупности они могут описывать внешнюю границу компьютерной системы.

Диаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и взаимодействий между ними. В каждой системе обычно есть главная диаграмма прецедентов, которая описывает внешнюю границу системы и основные внешние функции (внешнее поведение) системы

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

Для АИС «…..» главная диаграмма прецендентов показана на рисунке 1.

Рис.1. Диаграмма прецендентов АИС «…»

Рассмотрим эту диаграмму подробнее. Она описывает внешнюю границу системы регистрации курсов. Внешняя граница АИС состоит из четырех актеров и семи прецендентов (use cases). Актеры имеют имена Преподаватель, Студент, Регистратор, Система оплаты. Имена Преподаватель и Студент обозначают всех преподавателей и всех студентов Университета. Система оплаты – это бухгалтерская система. Физически прецеденты реализуются как внешние рабочие места АИС, оснащенные дисплеями и средствами печати.

Концептуальная диаграмма

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

Рис.2. Концептуальная диаграмма АИС «….»

Этот фрагмент концептуальной схемы базы данных может быть построен в виде диаграммы классов, которая показана ниже (рис. 5).

Диаграмма действий

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

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

В нашем случае получаем следующую диаграмму действий (рис.3).

Рис.3 Диаграмма действий АИС «….»

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