20. Физические модели

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

К вопросам организации данных относятся:

·   выбор типа записи – единицы обмена в операциях ввода-вывода;

·   выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

·   выбор способа адресации и метода доступа к записям.

Стадия физического проектирования БД в общем случае включает:

·   выбор способа организации БД;

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

·   описание отображения концептуальной схемы во внутреннюю.

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

·   выбор схемы размещения данных (разделение по файлам или тип RAID-массива);

·   определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).

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

20. Case-средства разработки баз данных

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. Ктаким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:

·   число и перечень поддерживаемых целевых СУБД;

·   поддержку распределенных БД;

·   поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.);

·   построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

·   автоматизируемые функции проектирования и степень их автоматизации;

·   качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);

·   надежность работы;

·   документирование проекта;

·   открытость системы (возможность стыковки с другими средствами);

·   удобство графического редактора;

·   количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);

·   возможность автоматической оценки объема памяти для проектируемой БД;

·   возможность автоматической генерации процедур;

·   наличие средств моделирования хранилищ данных;

·   требования к ресурсам компьютера;

·   операционную среду;

·   стоимость системы.

CASE-средства показывают модель с разной степенью детализации:

·     только обозначения сущностей и связей между ними;

·     сущности + ключи;

·     сущности + ключи + внешние ключи;

·     сущности + все атрибуты.

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

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

Еще одним критерием сравнения СASE-средств является степень проверки правильности построенных моделей. Ни одна система автоматизации проектирования не может гарантировать соответствия построенной концептуальной модели реалиям предметной области. Это определяется только квалификацией разработчиков, их пониманием предметной области и умением отобразить ее в модели.

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

Многие CASE-средства этим позволяют задавать в модели ограничения целостности и генерируют программы (триггеры, хранимые процедуры), проверяющие эти ограничения при эксплуатации БД. Кроме того, CASE-средства могут генерировать программы ведения БД.

Многие CASE-средства позволяют экспортировать модели в другие системы и, наоборот, импортировать их из других систем.