Лекция 9. Физическое проектирование базы данных

Оборудование для хранения данных. Устройства прямого доступа. Иерархия устройств хранения данных. Наборы данных. Понятие файловой системы. Способы организации файловых систем. Записеориентированные файловые системы и файлы прямого доступа. Потокоориентированные файловые системы. Многотомные файлы. Иерархические файловые системы. Понятие тэга файла. Журналирование в файловых системах.

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

Физическое проектирование – создание схемы базы данных на конкретной системе управления базами данных. На этапе физического проектирования учитывается специфика конкретной системы управления базами данных.

Специфика конкретной системы управления базами данных может включать в себя: 1) ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п.; 2) поддерживаемые методы управления дисковой памятью, разделения баз данных по файлам и устройствам, доступа к данным и т.д. ; 3) создание индексов и т.д.

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

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

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

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

Основными структурами хранения данных во внешней памяти ЭВМ являются: последовательное размещения физических записей; последовательное размещение физических записей с упорядочением по ключу; размещение физических записей в виде списковой структуры; использование индексов (индексирование); бинарное дерево (В-дерево); размещение записей с использованием хэширования; комбинированные структуры хранения

Процедуры физического проектирования

Цель этапа физического проектирования - описание конкретной реализации базы данных, размещаемой во внешней памяти компьютера. Это описание структуры хранения данных и эффективных методов доступа к данным базы. При логическом проектировании отвечают на вопрос - что надо сделать, а при физическом - выбирается способ, как это сделать.

Основные процедуры физического проектирования: выбор конкретной реляционной системы управления базами данных, проектирование таблиц базы данных и связей между ними, реализация бизнес-правил, разработка стратегии защиты базы данных, организация мониторинга функционирования базы данных и ее настройка.

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

Проектирование таблиц базы данных и связей между ними средствами выбранной системы управления базами данных (с учетом ограничений и возможностей выбранной системы управления базами данных), в частности определение: 1) имени таблиц; 2) списка простых атрибутов (в т.ч. имени атрибута, принимаемого по умолчанию значение атрибута (необязательно), допустимость значения NULL для данного атрибута); 3) определение первичного ключа и (если таковые существуют) альтернативных внешних ключей; 4) список производных атрибутов и описание способов их вычисления; 5) определение требований ссылочной целостности для любых внешних ключей.

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

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

Основные способы реализации бизнес-правил: применение возможностей языка SQL, применение триггеров, реализация непосредственно в приложении.

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

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

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

Индексы необходимо создавать в случае, когда по столбцу или группе столбцов: 1) часто производится поиск при работе с базой данных; 2) часто строятся объединения таблиц; 3) часто производится сортировка.

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

В случае нескольких индексов, по которым можно осуществить поиск, выбирается для использования тот, у которого выше показатель полезности индекса (selectivity). Показатель полезности индекса рассчитывается как число различающихся значений индексных полей внутри индекса, отнесенное к среднему количеству записей. Для участия в выполнении запроса выбираются индексы с максимальным уровнем полезности. Такие индексы обеспечивают более быстрый поиск. Максимальным индексом полезности обладают уникальные индексы, т.е. индексы, построенные по определениям первичных и уникальных ключей.

В некоторых случаях оптимизатор сервера базы данных не может корректно определить полезность индекса. В решения этой проблемы в диалектах языка SQL существуют способы принудительного использования того или иного индекса при выполнении запроса. Также в некоторых системах управления базами данных существует возможность принудительно установить частоту обновления индекса.

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

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

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

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

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

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

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

Подробное изложение теоретических вопросов, затронутых в первой лекции, можно найти в литературе [1,3,5,6]. Практические аспекты этих вопросов можно отыскать в работах [2,4].

Знания следует самостоятельно проверить путем ответов на контрольные вопросы (список контрольных вопросов приведен в Методических рекомендациях по самостоятельному изучению дисциплины «Базы данных», которые являются неотъемлемой частью учебно-методического комплекса дисциплины «Базы данных»).