Общая схема логического (концептуального) проектирования
Напомним, что мы рассматриваем концептуальную схему как результат представления инфологической модели предметной области в терминах инструментария (концептуальной модели данных) конкретной СУБД.
На этапе логического проектирования разрабатывается логическая структура БД, соответствующая логической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных, поддерживаемых данной СУБД.
Общая структура процесса логического проектирования (включая этап инфологического проектирования) представлена схемой на рис.11.
На основании этой схемы можно определить следующие основные этапы процесса концептуального проектирования.
Этап 1. Обзор предметной области
Определение целей создания информационной системы.
Определение специфических требований к БД, вытекающих из этих целей и/или сформулированных персоналом.
Этап 2.
Определение (идентификация) сущностей (объектов).
Определение атрибутов сущностей.
Идентификация ключевых атрибутов сущностей.
Определение связей между сущностями.
Формирование инфологической модели.
Формирование и анализ требований (инфологическое проектирование)
Выбор СУБД
Проектирование реализации
Рис.11. Структура процесса концептуального проектирования
Этап 3. Проектирование реализации
Преобразование инфологической схемы в концептуальную.
Установка (формулировка) ограничений целостности.
Обеспечение средств защиты.
Разработка (проектирование) приложений.
Несколько комментариев к схеме.
К обследованию ПО:
Ясно, что инфологическое описание ориентировано на некоторую идеальную среду реализации, то есть отражает, что заказчик хочет отразить в информационной системе, но не как эти желания будут отражены.
Идентификация ключевых атрибутов сущностей – это процесс выделения, так называемых, ключей логических записей БД, среди которых различают первичные и вторичные ключи (неключевые атрибуты).
Первичный ключ – это атрибут (или совокупность атрибутов), значение которого единственным (уникальным) образом идентифицирует экземпляр записи во множестве однотипных записей. Примеры первичных ключей:
номер_зачетной_книжки типа записи СТУДЕНТ (пример простого первичного ключа, состоящего из одного атрибута),
номер_рейса + дата_вылета типа записи СВЕДЕНИЯ_О_РЕЙСАХ (пример составного первичного ключа, образованного несколькими атрибутами); знак “+” здесь означает операцию конкатенации.
Вторичный ключ идентифицирует не уникальный экземпляр записи, а все экземпляры, имеющие определенные свойства. Например, все студенты, закончившие сессию без троек.
К выбору СУБД:
Каждая конкретная среда реализации имеет внешние ограничения, из которых можно выделить:
технические, определяемые конфигурацией вычислительной системы, параметрами функционирования ее компонентов, надежностью их работы и т.д.,
программные, определяемые операционной системой и языками программирования,
организационные, определяемые сроками разработки, имеющимися кадровыми ресурсами, возможностями переподготовки специалистов и т.д.
Моделирование БД здесь предполагает преобразование инфологической схемы (модели) в концептуальную схему (модель) БД, поддерживаемую СУБД. Очевидно, что искомое преобразование может быть реализовано средствами нескольких СУБД-претендентов, способных функционировать в рамках сформулированных внешних ограничений. Если получено несколько приемлемых моделей БД, они подлежат сравнительному анализу. Если приемлемых моделей не оказалось, необходимо либо скорректировать требования к информационной системе, либо начать разработку собственной СУБД.
Сравнительный анализ моделей БД производится путем оценки целого ряда факторов, из которых упомянем следующие:
требуемые объемы основной и дисковой памяти,
трудоемкость разработки программных средств окружения СУБД,
трудоемкость реализации приложений,
затраты на обучение персонала,
стоимость эксплуатации системы,
возможность совмещения разработки БД с ранее выполненными программными продуктами, прогнозируемые сроки реализации.
К проектированию реализаций:
Конструирование концептуальной схемы БД предполагает окончательное уточнение всех параметров логической организации БД и формирование ее описания на языке описания данных выбранной СУБД, то есть преобразование инфологической модели в концептуальную схему.
Уточнение (детализация) концептуальной схемы на основе выявленных дополнительных требований прикладных программ.
Установка (формулировка) ограничений целостности. Данный шаг предполагает выработку правил, которые будут устанавливать и поддерживать целостность данных. Будучи определенными, такие правила поддерживаются либо автоматически (в клиент-серверных СУБД) сервером баз данных; либо их поддержку приходится возлагать на пользовательское приложение (в локальных СУБД). Эти правила включают:
определение типа данных,
создание полей, опирающихся на домены,
установка значений по умолчанию,
определение ограничений целостности,
определение проверочных условий.
Обеспечение защиты предполагает решение вопросов надежности данных и, при необходимости, сохранения секретности информации. Для этого необходимо определить:
кто будет иметь права (и какие) на использование базы данных,
кто будет иметь права на модификацию, вставку и удаление данных,
нужно ли делать различие в правах доступа,
каким образом обеспечить общий режим защиты информации,
и т.п.
Разработка (проектирование) приложений.
На рис.12. представлена общая схема процесса проектирования, учитывающая этап физического проектирования, организацию информационных потоков и совокупность внешних требований.
Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам "физической" БД. Принятые на этом этапе решения оказывают определяющее влияние на производительность системы. Более подробно вопросы физического проектирования будут рассмотрены в разделе 8.
В заключение отметим, что фактически проектирование БД имеет итерационный характер. В процессе функционирования системы становится возможным изменение ее реальных характеристик, выявление "узких" мест. И если система не отвечает предъявляемым к ней требованиям, то обычно она подвергается реорганизации, т.е. модификации первоначально созданного проекта.