2.7.2. Основные этапы проектирования базы данных

Есть все основания называть рассматриваемую методологию проектирования классической: для указанных методов разработаны полные, целостные методические системы, для большинства методов предложены формализованные модели: эти модели – или, по крайней мере, их итоговые выразительные возможности – нашли реальное применение в практике проектирования. Использовалась дисциплина т.н. структурного анализа при проектном подходе "сверху вниз". Структурность связывается с использованием иерархических структур для детализации данных и функций и соответствующих достаточно "жестких" проектных процедур. Проектная схема получила название "каскадной" (рис. 2.16).

Этап 1. Формулирование и анализ требований

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

Этап 2. Концептуальное проектирование

Этап концептуального проектирования связан с описанием и синтезом разнообразных концептуальных требований пользователей в первоначальный проект баз данных. Результатом этого этапа является высокоуровневое представление информационных требований, например, с помощью диаграмм "сущность-связь" (Entity-Relationship Diagrams, ER-диаграммы), которые мы рассмотрим в дальнейшем. Основу ER-диаграммы составляет набор сущностей ("сущность" в данном случае – синоним понятия "объект"), который представляет или моделирует определенную совокупность сведений, специфицированную в требованиях. Сущности могут быть описаны атрибутами, позволяющими д етализировать свойства сущности. Один или несколько атрибутов могут служить идентификатором (ключевой атрибут) для обозначения отдельных экземпляров сущности. Связи между сущностями отображают функциональные аспекты информации, представленной сущностями.

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

1. определение сущностей;

2. определение атрибутов сущностей;

3. идентификация ключевых атрибутов сущностей;

4. определение связей между сущностями.

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

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

Этап 2. Проектирование реализации

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

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

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

• время ввода-вывода – время, затрачиваемое на выборку данных с внешней памяти в оперативную, включая время передачи данных;

• время доступа – промежуток времени между выдачей команды, содержащей обращение к некоторым данным, и фактическим получением данных для обработки;

• время отклика – промежуток времени между вводом запроса к базе данных в компьютере и завершением обработки запроса с представлением результатов.

Этап 4. Физическое проектирование

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

• Проектирование формата хранимых записей. Сюда включаются все виды представления и сжатия данных в хранимых записях. Сюда же относится распределение элементов данных записи по различным участкам физической памяти в зависимости от размеров и характеристик их использования.

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

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

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