Жизненный цикл базы данных

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

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

В общем случае выделяют следующие этапы проектирования баз данных

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели.

3. Выбор и обоснование СУБД.

4. Датологическое или логическое проектирование БД, т.е. описание БД в терминах принятой датологической модели данных.

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

Рис. 8. Этапы проектирования БД

Анализ предметной области

В общем случае существуют два подхода к выбору состава и структуры предметной области:

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

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

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

Анализ предметной области целесообразно разбить на три фазы:

1. анализ концептуальных требований и информационных потребностей;

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

3. построение концептуальной модели предметной области и проектирование концептуальной схемы БД.

На этапе анализа концептуальных требований и информационных потребностей необходимо решить следующие задачи.

• Анализ требований пользователей к БД (концептуальных требований), которые представляют собой список запросов с указанием их интенсивности и объемов данных. Эти сведения разработчики получают в диалоге с будущими пользователями БД. Здесь же выясняются требования к вводу, обновлению и корректировке информации. Требования пользователей уточняются и дополняются при анализе имеющихся и перспективных приложений.

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

• Выявление перспективных задач (перспективных приложений).

• Документирование результатов анализа.

По результатам системного анализа предметной области строится модель "AS - IS" её деятельности (деятельности объекта автоматизации). Модель "AS - IS" может быть представлена в виде:

• словесного описания;

• произвольного графа информационных потоков;

• диаграммы потоков данных (DFD);

• последовательности различных видов UML - диаграмм

• и т.д.

Разработчик базы данных должен выполнить анализ модели "AS - IS" и выявить недостатки в процессах обработки информации, существующие на объекте автоматизации, для устранения которых будет создаваться база данных.

Инфологическое моделирование

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

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

• Какие типы связей между информационными объектами?

• Какое имя можно присвоить каждому типу связей?

• Каковы возможные типы связей, которые могут быть использованы впоследствии?

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

• Какова область значений для числовых характеристик?

• Каковы функциональные зависимости между характеристиками одного информационного объекта?

• Какой тип отображения соответствует каждому типу связей?

Построение инфологической модели предметной области

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

При агрегации объединяются информационные объекты (элементы данных) в один в соответствии с семантическими связями между объектами.

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

Выбор и обоснование конкретной СУБД

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

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

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

После определения информационных объектов предметной области и их свойств необходимо ответить на ряд вопросов:

• На какие таблицы можно разбить данные, подлежащие хранению в БД?

• Какое имя можно присвоить каждой таблице?

• Какие наиболее интересные характеристики (с точки зрения пользователя) можно выделить?

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

• имя (как правило, его дают «говорящим» о той информации, которая будет содержаться в ней),

• все возможные ключи (первичные и вторичные),

• для файлов - таблиц некоторых СУБД, например Clarion 5.5, определяются префиксы.

После того как спроектированы таблицы базы данных, выполняется их нормализация. Если все перечисленные действия для проектируемой базы данных выполнены, то можно построить её датологическую модель. Это можно выполнить вручную с помощью чертёжных инструментов, средствами редактора MS Word или какой - либо специальной утилиты, или CASE - технологии (case - средства ERwin Computer Associates).

Физическое проектирование БД

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