Концептуальное проектирование БД

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

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

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

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

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

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

Нагрузка на пути доступа, точки входа процессов в концептуальную структуру и другие результаты согласования фиксируются в матрицах разных типов, объединенных общим названием «данные — процессы». Строки матриц соответствуют структурным элементам, а столбцы — процессам. Матрицы являются важным источником информации для проектных решений двух следующих этапов стадии ПРОЕКТ.

Логическое проектирование

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

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

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

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

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

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

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