4. Проектирование логической и физической структуры информационной системы.

4.1. Логическая структура ис и проектирование реализации.

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

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

Рассмотрим основные проблемы, решение которых требуется на этапе проектирования реализации. На рис. 4.1. приведена диаграмма входных и выходных данных этапа проектирования реализации.

Исходными данными являются:

1. СУБД-независимая схема, как основной результат концептуального проектирования.

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

3. Количественная оценка объема БД и частоты выполнения приложений (клиентских программ).

4. Непротиворечивость – правила поддержания взаимной непротиворечивости элементов данных, ограничения на дублирование и обновление данных.

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

6. Характеристики СУБД – правила задания СУБД-ориентированных логических схем и подсхем, а также синтаксиса программ.

7. Вычислительные средства – ограничения на конфигурацию и объем аппаратного и системного программного обеспечения.

Результатом проектирования реализации должны являться:

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

2. Подсхемы – т.е. такая структура СУБД-ориенированной БД, которая совместима с представлениями клиентов и требованиями безопасности.

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

4. Руководство по проектированию программ – рекомендации для разработчиков программ по выбору путей доступа к данным, основанные на анализе характеристик предложенной структуры.

5. Руководство по эксплуатации БД – необходимые сведения для администратора ИС и ее пользователей.

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

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

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

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

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