3.2.4 Перенос глобальной логической модели данных в среду целевой субд

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

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

Для каждого атрибута в словаре данных должна присутствовать следующая информация:определение его доменов, включающее указание типа данных, размерность внутреннего представления атрибута и любые требуемые ограничения на допустимые значения;принимаемое по умолчанию значение атрибута (необязательно);допустимость значения NULL для данного атрибута.

Принятие решения о способе реализации основных отношений (зависит от типа выбранной СУБД). Документальноеоформлениепроектаосновных отношений;

2) разработка способов получения производных данных. Необходимо определить, должен ли производный атрибут храниться в базе данных или вычисляться каждый раз, когда в нем возникает необходимость. Проектировщик должен рассчитать следующее:дополнительные затраты на хранение производных данных и поддержание их согласованности с реальными данными, на основе которых они вычисляются;затраты на вычисление производных данных, если их вычисление выполняется по мере необходимости.

Документирование проекта представления производных данных, с описанием причин выбора предложенного проекта;

3) проектирование ограничений предметной области для целевой СУБД.Документирование проекта ограничений предметной области с указанием причин выбора данного варианта из нескольких возможных.

3.2.5 Физическое проектирование базы данных

Определение оптимальной файловой организации для хранения основных отношений, а также индексов, необходимых для достижения приемлемой производительности.

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

Для достижения производительности системы необходимо знать, каким образом взаимодействуют между собой и влияют на производительность системы следующие компоненты аппаратных средств: оперативная память; процессор; дисковый ввод-вывод; сеть.

Действия, которые должны быть выполнены на этом этапе:

1) анализ транзакций. Определение функциональных характеристик транзакций, которые будут выполняться в проектируемой базе данных, и выделение наиболее важных из них.

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

Для выделения областей, которые с наибольшей вероятностью могут явиться источником проблем, необходимо выполнить перечисленные ниже действия:

а) подготовка схемы соответствия путей выполнения транзакций и отношений;

Таблица 3.12 – Соответствие транзакций и отношений

Транзакция	Назначение	Представление
(A)
(B)

Таблица 3.13 - Матрица соответствия транзакций и отношений

Транзакция/отношение	(А)	(В)
	I R U D	I R U D
	X	X
	Х	XXX

I — вставка; R — чтение (выборка); U — обновление; D — удаление,

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

в) анализ интенсивности доступа к данным в некоторых из транзакций, использующих эти отношения. Для каждой транзакции необходимо выяснить следующее: отношения и атрибуты, к которым осуществляется доступ в процессе выполнения транзакции, а также тип доступа (вставка, удаление, обновление или выборка данных);

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

3) определение индексов. Определение того, будет ли добавление индексов способствовать повышению производительности системы.

Основные издержки, связанные с применением дополнительных индексов:

а) ввод индексной записи в каждый дополнительный индекс при вставкестроки в отношение;

б) обновление дополнительного индекса при обновлении соответствующей строки в отношении;

в) увеличение потребности в дисковом пространстве в связи с необходимостью хранения дополнительного индекса;

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

Рекомендации по выбору списка требований к индексам:

а) не создавать индекс на небольших отношениях. Может оказаться более эффективным поиск в отношении, данные которого хранятся в оперативной памяти, чем хранить дополнительную индексную структуру;

б) следует создавать индекс на первичном ключе отношения, если он не применяется в качестве ключа файловой структуры;

в) ввести дополнительный индекс на внешнем ключе, если с его помощью часто происходит доступ к отношению (в некоторых СУБД индексы на внешних ключах создаются автоматически);

г) ввести дополнительные индексы на всех атрибутах, которые часто применяются в качестве дополнительного ключа;

д) ввести дополнительные индексы на атрибутах, которые часто применяются в следующих конструкциях: критерии выборки или соединения; конструкции ORDER BY; конструкции GROOP BY; другие операции, требующие сортировки (такие как UNION и DISTINCT);

е) ввести дополнительные индексы на атрибутах, применяемых во встроенных функциях агрегирования, наряду со всеми атрибутами, используемыми для этих встроенных функций;

и) необходимо вводить дополнительный индекс на всех атрибутах, которые могут привести к созданию плана, предусматривающего применение только индексов;

к) не индексировать атрибут или отношение, которые часто обновляются;

л) не индексировать атрибут, если в запросах с использованием этого атрибута обычно происходит выборка значительной части (например, 25%) строк кортежей в отношении. В таком случае может оказаться более эффективным поиск во всем отношении, чем поиск с использованием индекса;

м) не индексировать атрибуты, которые состоят из длинных символьных строк;

н) если в критериях поиска предусмотрено несколько предикатов и одно из этих условий содержит конструкцию OR, а в самом условии не применяется индекс и не предусматривается сортировка, то добавление индексов для других атрибутов не позволяет повысить скорость выполнения такого запроса, поскольку все равно потребуется последовательный поиск в отношении. Если предикаты в конструкции WHERE соединены с помощью оператора AND, индексы могут применяться для оптимизации запроса.

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

Таблица 3.14 – Информация о взаимосвязи между основными таблицами и

транзакциями

Таблица	Транзакция	Назначение	Частота (транзакций в сутки)

Таблица 3.15 – Дополнительные индексы, созданные с учетом транзакций

Таблица	Индекс

5) определение требований к дисковой памяти. Оценка объема дискового пространства, необходимого для размещения базы данных.

3.2.6 Проектирование пользовательских представлений

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

3.2.7 Разработка механизмов защиты

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

3.2.8 Анализ необходимости введения контролируемой избыточности данных

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

3.2.9 Текущий контроль и настройка операционной системы

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

3.3 Выбор целевой СУБД

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

Основные этапы процедуры выбора СУБД:

1. определение предметной области;

2. сокращение списка выбора до двух-трех продуктов;

3. оценка продуктов;

4. проведение обоснованного выбора и подготовка отчета.

Таблица 3.16 - Рекомендуемые параметры оценки СУБД

Определение данных	Физические параметры
Расширенная поддержка первичных ключей	Предусмотренные файловые структуры
Определение внешних ключей	Поддержка определения файловых структур
Предусмотренные типы данных	Простота реорганизации
Расширяемость типов данных	Средства индексирования
Определение доменов	Поля/записи с переменной длиной
Простота реструктуризации	Сжатие данных
Продолжение таблицы 3.16
Определение данных	Физические параметры
Средства поддержки целостности данных	Возможности шифрования
Реализация механизма представлений	Требования к памяти
Поддержка словаря данных	Требования к устройствам хранения данных
Независимость от данных
Тип базовой модели организации данных
Поддержка расширения схемы
Доступность	Обработка транзакций
Язык запросов: совместимость со стандартами	Процедуры резервного копирования и восстановления
Интерфейс для других систем	Поддержка контрольных точек
Интерфейс для языков третьего поколения	Средства ведения системного журнала
Многопользовательский доступ	Поддерживаемый уровень детализации параллельности
Защита базы данных:	Возможные стратегии разрешения тупиковых ситуаций
управление доступом к данным;
поддержка механизма авторизации
	Поддержка усовершенствованных моделей управлений транзакциями
	Параллельная обработка запросов
Утилиты	Средства разработки
Измерение производительности	Инструменты, использующие языки четвертого и пятого поколений
Настройка производительности базы данных	CASE-инструменты
Инструменты загрузки/выгрузки данных	Инструменты для работы с оконным интерфейсом
Контроль активности пользователей	Поддержка хранимых процедур, триггеров и правил
Поддержка процедур администрирования базы данных	Инструментальные средства разработки дляWeb
Другие параметры
Способность к модернизации	Взаимодействие с другими СУБД и прочими системами
Устойчивое экономическое положение производителя СУБД	Поддержка работы в Internet
База пользователей	Утилиты репликации
Обучение и поддержка пользователей	Возможности распределенной работы
Качество и полнота документации	Переносимость
Требуемая операционная система	Требуемое аппаратное обеспечение
Стоимость	Поддержка работы в сети
Оперативная справочная система	Объектно-ориентированные свойства
Используемые стандарты	Поддержка двух- или трехуровневой архитектуры "клиент/сервер"
Продолжение таблицы 3.16
Определение данных	Физические параметры
Управление версиями	Производительность
Расширенная оптимизация запросов	Пропускная способность при обработке транзакций
Масштабируемость	Максимальное количество одновременно работающих пользователей
Поддержка аналитическихинструментальныхсредств	Поддержка языка XML