Методология физического проектирования реляционных баз данных

Физ. Проектир-е явл-ся заключительным этапом проектирования БД. Если при лог. Проектировании разраб-к сосредоточен на том, что надо делать, то при физ. проект. ищется способ, как это сделать. Т.к. СУБД достаточно сильно отличается др. от др. своими ф-ными возм-тями, то физ. проект. ориентируется на конкретную СУБД. При проект. БД все 3 этапа м/д очень тесно связаны и м/д ними есть обратная связь. Например, на этапе физ. проект. с целью повышения производительности системы принято реш. реорганиз., стр-ры данных. Это в свою очередь потребует изменения лог. схемы.

Этапом физ. проект. БД соот. след. задачи (в общей схеме проектир-я БД они соответ-т этапу 4-7). Этап 4 – это перенос глоб. лог. модели в среду целевой СУБД. На этом этапе реш-ся вопрос проект-я таблиц и реализ. бизнес-прав. Предпр-я в среде целевой СУБД. Этап 5 – проектир-е физ-го представления БД. Сюда отн-тся след. задачи: анализ транзакции, выбор файловой стр-ры, опр-ние вторичных индексов, анализ необх-сти контроля избыточности данных, опре-ния требований к дисковой памяти. Этап 6 – разработка мех-ов защиты. Сюда отн-ся вопрос разработки польз-ких представлений и опр-ния прав доступа к данным. Этап 7 – орг-ция мониторинга и настройка функц-ния си-мы.

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

Некоторые СУБД (SQL Server, Oracle) позволяют использовать триггеры. Триггеры наз. Действие, связанное с событием вызванное изменением в содержании таблиц. Вызов триггеров происходит при обновлении, вставке и удалении данных. Для создания триггера используется команда CreateTrigger(). Триггеры используются часто для организации или расширения ссылочной целостности данных, для реализации сложных бизнес правил. Чаще всего обновл. инфу в системе организации в соот. с определенными бизнес правилами предприятия. Ограничения, необходимые при обновлении инфы как правила заносятся в sql-операторы либо задаются в команде CreateTrigger() при создании триггера. Если в использовании СУБД отсутствует поддержка реализации тех или иных бизнес правил, они д/б учтены при разраб-ке приложения.

Организация эффективного хранилища данных. Существует несколько показателей, позволяющие оценить достигнутую эффективность:

1)пропускная способность транзакции. Хар-т какое кол-во транзакций м/б обработано за заданный промежуток времени;

2)время ответа - это временной промежуток, необходимый для выполнения транзакции;

3)дисковая память – V дискового пространства, необходимое для реал-и файлов БД.

Т.к. БД является корпоративным ресурсом предпр-я, важна разраб-ка мех-ов защиты БД. Каждая конкретная СУБД предлаг свой н-р средств защиты. Им-ся общие аспекты этой проблемы: 1) разраб-ка пользов-х представлений; 2) опред-е правил доступа.

В автономн СУБД представл-я созд-ся для удобства и упроще-я запросов к БД, т.е. орг-я запросов не связанных с мех-ми защиты. В многопольз-х СУБД представл-я использ как средства определения стр-ры БД и орг-я защиты. Один из способов орг-ции защиты – это использование средств ограничения доступа, кот. предоставляет язык SQL.

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