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

Определим понятие «проектирование» и выделим его этапы.

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

Д. Крёнке утверждает, что проектирование - операция, которая выделяет заданные атрибуты отношения [18].

Т.С. Карпова понимает под проектированием процесс последовательных переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели [14].

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

Следует отметить, что на стадии проектирования БД должна быть выполнена следующая работа [13]:

исследование предметной области автоматизации;

определение объектов и перечня их атрибутов, для каждого объекта должны выделены первичные ключи и реализована нормализация;

установление всех связей между объектами, построение схемы проекта со всеми объектами и связями;

выработка технологии обслуживания БД, т.е. определение порядка сбора, хранения данных в БД, частоты и формата ввода-вывода данных, правил работы всех групп пользователей;

выбор компьютера и инструментальных средств (конкретной СУБД) для реализации;

проверка корректности проекта - проект должен адекватно, на требуемом уровне детальности, отображать предметную область;

На стадии программной реализации необходимо выполнить следующее:

описать средствами СУБД и ввести в ПК схемы всех отношений;

разработать интерфейсы пользователей с БД разработать экранные формы для ввода и отображения данных, удобные экранные способов обращения и доступа к данным в БД, порядок ввода и обновления данных;

разработать программное обеспечение БД для всех приложений;

отладка БД;

провести тестирование системы и скорректировать технологию ее обслуживания;

составить необходимые инструкции по системе управления базами данных и обучить пользователей.

Кроме этого при проектировании БД необходимо обеспечить [13]:

защиту данных от разрушений при сбоях оборудования, от некорректных обновлений, и, если необходимо, от несанкционированного доступа;

выполнение ограничений на конфигурацию вычислительной системы, в первую очередь на ресурсы памяти;

простоту и удобство эксплуатации БД;

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

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

С учетом перечисленных выше требований рассмотрим основные этапы проектирования БД. Данные, используемые для описания предметной области можно представить в виде трехуровневой схемы (так называемая модель ANSI/SPARC) [12].

Рис. 16. Схема модели ANSI/SPARC

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

Т. Тиори, Дж. Фрай выделяют следующие основные этапы, на которые разбивается процесс проектирования базы данных [11]:

1. Концептуальное проектирование сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

обследование предметной области, изучение ее информационной структуры;

выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;

моделирование и интеграция всех представлений.

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

2. Логическое проектирование преобразование требований к данным в структуры данных. На выходе получаем СУБД ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

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

3. Физическое проектирование определение особенностей хранения данных, методов доступа и т.д.

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

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

Различие уровней представления данных на каждом этапе проектирования представлено в таблице 3 (приложение 1).

Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД).

Рассмотрим стадии создания БД согласно ГОСТу 34.601-90.

Стадии и этапы создания БД, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ (рис. 17).

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

Методология проектирования БД описывает процесс создания и сопровождения БД в виде жизненного цикла (ЖЦ). БД, представляя его как некоторую последовательность стадий и выполняемых на них процессов [9]. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ БД позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл БД можно представить как ряд событий, происходящих с системой в процессе ее создания и использования [9].

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

В настоящее время известны и используются определенные модели жизненного цикла [9].

1. Каскадная модель (рис. 18) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

2. Поэтапная модель с промежуточным контролем (рис. 19). Разработка БД ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

3. Спиральная модель (рис. 20). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

Рис. 19. Поэтапная модель с промежуточным контролем

Рис. 20. Спиральная модель ЖЦ БД

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

На данный момент используется большое количество подходов к проектированию БД. Важнейшими из подходов являются структурный (функциональный), объектно-ориентированный, и отдельно выделяют методология ARIS [30].

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

В качестве структурного анализа и проектирования, наиболее распространены следующие нотации:

- SADT. Для новых систем SADT (IDEF0) применяются для определения требований для разработки системы реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных взаимосвязанных диаграмм.

- DFD диаграммы поток данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации.

- IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.

- ER диаграммы «сущность-связь». Методология описания данных (IDEF1X).

Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации.

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

IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.

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

Объектно-ориентированный подход. В настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо.

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

Методология ARIS. Определяет принципы моделирования различных аспектов деятельности организаций, основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода.

К преимуществам методологии ARIS относят следующие:

- возможность рассматривать объект с разных точек зрения: при анализе деятельности каждому аспекту можно уделять достаточное внимание и только после детального изучения всех аспектов можно перейти к построению интегрированной модели, отражающей все существующие связи между подсистемами организации;

- богатство методов, позволяет моделировать широкий спектр систем;

- все модели и объекты создаются и хранятся в единой базе проекта, что обеспечивает построение интегрированной и целостной модели предметной области.

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

Выводы по первой главе

1. База данных представляет собой совокупность организованных сведений, в соответствии с поставленной целью (например, о конкретных объектах реального мира в какой-либо предметной области или ее разделе, которые хранятся в памяти ПК).

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

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

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

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

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

7. Анализ программ «Электронная медицинская карта» и «МедКарта» позволяет сделать вывод, что они не подходят и возникает необходимость в разработке собственной БД «Состояние здоровья учащихся», которая удовлетворяла бы всем потребностям школьного врача.

8. Существуют структурный (функциональный), объектно-ориентированный подходы и отдельно выделяют методология ARIS для проектирования БД. Наиболее оптимальным, на наш взгляд, является структурный (функциональный) подход, так как он наглядно отражает функциональную структуру объекта: производимые действия, связи между этими действиями.

Глава 2. Проектирование БД «Состояние здоровья учащихся» для МОУ СОШ №44 г. Нижнего Тагила Свердловской области

2.1 Описание предметной области