Методология физического проектирования БД

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

1. Перенос глобальной логической модели в среду СУБД

1.1 проектирование таблиц БД в среде СУБД;

1.2 реализация бизнес правил предприятия в среде СУБД;

2. Проектирование физического представления БД в среде СУБД

2.1 анализ транзакций;

2.2 выбор файловой структуры;

2.3 определение вторичных индексов;

2.4 анализ необходимости ведения контроля избыточности функций;

3. Определения требований к дисковой памяти защиты БД

3.1 разработка пользовательских представлений;

3.2 определение прав доступа к функциям;

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

Требования отношений в такую форму, которая может быть реализована в выбранной СУБД. При этом следует учитывать моменты:

1. Поддерживает ли система определение первичных, вторичных, альтернативных ключей

2. Допускает ли СУБД определение обязательных данных

3. Поддерживается ли определение доменов

4. Допускаются ли определения бизнес-правил предприятия

5. Способ определения таблиц БД.

Эффективное хранение данных.

Имеется ряд показателей, которые позволяют определить оценку достигнутой эффективности:

1. Пропускная способность транзакции. Этот показатель позволяет определить какое количество транзакций может быть отработано за данный промежуток времени.

2. Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции.

3. Дисковая память. Характеризует объем дискового пространства для размещения БД.

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

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

Рекомендуется выбирать основные группы.

Пример: БД организации деятельности по продаже аренде объектов недвижимости.

А – ввод подробных сведений о сотруднике.

В – составление списка сдавших в аренду объектов недвижимости, за которые отвечает каждый работник из указанного отделения.

С – назначение сотрудника ответственным за несколько сданных в аренду объектов. При условии: если сотрудник отвечает менее чем за 10 объектов.

D – составление списка сдаваемых в аренду объектов закрепленных за отделением компании.

Персонал 1500 человек, которые закреплены за 50 отделений компании, в каждом работает по 30 человек. Наличие ER-диаграммы. Необходимо среднюю и максимальную кратности каждой из связей отношения.

Устанавливается способ доступа к каждому из отношения. Для этого фиксируется тип этого доступа:

I – ставка

R – чтение

D – удаление

U – обновление

Точка входа – имя атрибута нужного для получения доступа.

Необходимо знать такие транзакции, которые вызывают сканирование нескольких записей. Такие транзакции помечаются *.

C – информация о сотруднике

B – отделение

A – вставка нового сотрудника

Д – составление списка.

Результаты выполнения транзакции В

активность	День недели	Промежуток	Частота вызова в час
Пиковая средняя	Последняя среда	9-^00-10-^00 14-^00-16-^00

отношение	К отношению	атрибуты	Тип доступа	Частота вызова в час
-------	отделение	Адрес №_отделения	R(E) R	8-20

Продолжение результатов транзакции В

Отношение	К отношению	атрибуты	Тип доступа	Частота вызова в час
отделение	сотрудник	№_отделения №_сотрудника фамилия Имя	R(E)* R R R	8-20
сотрудник	Объект недвижимости	№_отделения №_объекта адрес	R(E)^+ R R	48-200

R-чтение

Вторичный индекс создается командой CREATR INDEX. Вторичные индексы несут дополнительные нагрузки при работе, которые возникают по следующим причинам:

1. При добавлении таблиц новой записи необходимо выполнить добавление записей в каждый вторичный индекс.

2. При обновлении записи основной таблицы требуется обновление ее и во вторичных индексов.

3. Для размещения вторичных индексов требуется дополнительное дисковое пространство.

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

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

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

Если принимается решение о денормализации отношений, следует учитывать следующие моменты:

1. Денормализация усложняет реализацию БД.

2. Денормализация снижает гибкость системы.

3. Денормализация ускоряет выборку данных, но снижается скорость обновления данных

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

Иногда денормализация называется оптимизация исполнения.

Т.к. БД является корпоративным ресурсом, встает проблема защиты данных. Любая СУБД предлагает свой набор средств защиты, который отличен от другой СУБД. Существуют общие механизмы защиты:

1. Разработка пользовательских представлений;

2. Определение прав доступа к данным.

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

В многопользовательской среде представления используются как средство определения структуры БД и организации защиты информации.

Представления создаются с помощью языка SQL. Например, необходимо создать представление для получения подробных сведений о персонале отделения с NB3.

CREATE VIEW Comp-B3

AS SELECT sno, fname, lname, adress, phono, position, sex

FROM Сотрудник

WHERE sno=’B3’;

Создание такого представления позволяет каждому сотруднику подразделения получить информацию о составе отделения, в то время как руководитель отделениябудет иметь доступ к таблице «Сотрудник», в которой дополнительно содержится информация об окладах, премиях. Эта информация будет не доступна другим сотрудникам отделения.

Когда пользователь создает представления, он становится владельцем этого представления, но это не значит, что он получает целый набор прав к этому представлению.

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

GRANT ALL PRIVILEGES ON Сотрудник

TO Manager

WITH GRANT OPTION;

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

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

Считается необходимым выполнить систему настройки БД, для этого чтобы достичь преимущества в БД:

1. устранить необходимость приобретение дополнительного оборудования;

2. снизить требование оборудования;

3. обеспечить лучшее время ответа системы;

4. повысить уровень производительности системы;

5. повышение психологического комфорта пользователей.

Дата добавления: 2015-05-09