Бизнес-модель этапа проектирования
Решая профессиональную задачу создания физической модели данных - учет влияния транзакций, - проектировщик базы данных стремиться создать такую физическую модель данных, которая, по его мнению, давала бы наибольшую производительность обработки запросов базы данных. На практике, особенно при создании и разработке новых баз данных, такая задача вряд ли может быть решена полностью. Ясно, что для ее решения необходимо иметь список всех запросов к базе данных, их частоте и объеме выборок по каждому, что в принципе невозможно. Поэтому проектировщики базы данных на основе анализа исходной документации и опросов потенциальных пользователей пытаются систематизировать транзакции к базе данных, оценить кардинальность таблиц в целом и отдельных колонок в частности. На основе таких оценок проектировщик базы данных пытается определить критические транзакции и настроить структуры таблиц, задействованных в таких транзакциях, на достижение, с его точки зрения, максимальной производительности. При этом он выдвигает гипотезы о применимости того или иного способа повышения производительности обработки запросов и умозрительно проверяет их. Далее он принимает решение о применении наиболее подходящего, с его точки зрения, способа увеличения производительности запросов.
Следует понимать, что задача обеспечения высокой производительности базы данных - это задача, которую постоянно решает администратор базы данных в процессе ее эксплуатации. На этом этапе проектирования базы данных проектировщик, по мере возможности, готовит успешное решение этой задачи. Эта этап является очень ответственным в физическом проектировании базы данных, поэтому следует соблюдать при решении этой задачи разумный прагматизм и документировать свои решения. Должно действовать эмпирическое правило: если проектировщик базы данных не имеет достаточно данных для надежного решения задачи повышения производительности базы данных, то решение этой задачи должно быть передано администратору базы данных.
На этом этапе проектирования физической модели реляционной базы данных проектировщик базы данных:
- исходя из требований к характеру обработки данных, определяет тип приложения базы данных;
- по имеющимся требованиям и описаниям выполняет систематизацию и описание по возможности всех транзакций к базе данных;
- отталкиваясь от исходной документации, определяет возможные размеры таблиц, а если это невозможно, делает предположения об их возможном размере;
- исходя из фактических размеров таблиц и требований к производительности выполнения транзакций, определяет критические транзакции;
- для каждой критической транзакции необходимо оценить кардинальность каждой колонки, задействованной в транзакции и, по возможности, кардинальность выборки;
- далее, рассматривая в первую очередь критические транзакции и таблицы, которые в них участвуют, проектировщик базы данных принимает субъективные решения по изменению структуры таблиц внутренней схемы базы данных, исходя из тех механизмов, которые ему предоставляет конкретная СУБД;
- по завершении изменения структур таблиц проектировщик базы данных документирует эти изменения, приводя обоснование своих решений для администратора базы данных.
В результате проектировщик базы данных создает физическую модель базы данных, которая учитывает характер обработки данных в базе данных, выраженный через учет влияния транзакций.
Перейдем теперь к построению бизнес-модели этапа проектирования физической модели реляционной базы данных: учет влияния транзакций. Из сказанного в предыдущих разделах настоящей лекции понятен следующий алгоритм действий:
Определение основного типа приложения базы данных Документирование и описание транзакций Определение критических транзакций Для каждой критической транзакции: Определение таблиц транзакции Определение способа повышения производительности Денормализация таблицы? Разбиение таблицы? Секционирование таблицы? Кластеризация таблицы? Построение дополнительных индексов? Изменение структуры внутренней схемы базы данных Документирование изменений Для каждой таблицы базы данных Выбор индексов Определение транзакций таблицы Определение кардинальности таблиц Определение кардинальности колонок Определение индексов Изменение внутренней схемы
На рис. 3.9 ниже представлена модель бизнес- процессов стадии проектирования физической модели базы данных с учетом влияния транзакций. На рис. рис. 3.10 - декомпозиция работы по индексированию базовой таблицы.
Рис. 3.9. Декомпозиция этапа проектирования - создание первой итерации физической модели базы данных: внутренняя схема
Рис. 3.10. Декомпозиция работы по индексированию базовой таблицы
Следует еще раз отметить субъективный характер принятия решений проектировщиком базы данных из-за отсутствия во многих случаях точных сведений о характере выполнения транзакций в системе. Большинство решений принимается на основе эвристических правил и личного опыта проектировщика. Метод работы проектировщика базы данных сводится к изменению структуры объектов базы данных на основе перебора возможных способов повышения производительности, их сопоставления и обоснованного выбора подходящего решения.
На этом мы заканчиваем рассмотрение задач проектировщика базы данных по созданию физической модели реляционной базы данных с учетом влияния транзакций. Главная цель этого этапа - видоизменить последовательность команд SQL для создания объектов хранения данных с учетом влияния транзакций на производительность базы данных.
