Разработка физической модели бд

Физическая модель данных находится на еще более низком уровне. Она описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно (в курсовом проекте, по умолчанию, используется реляционная СУБД MS Access. Однако её можно заменить любой выбранной СУБД по согласованию с преподавателем). Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, кортежи становятся строками. Для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Проект БД в виде её логической схемы переносится в память компьютера с помощью выбранной СУБД. В результате получают так называемую физическую модель БД, которая тесно связана с организацией хранения данных на физических носителях информации. Одной и той же логической модели может соответствовать несколько разных физических моделей, каждая из которых отличается своей конкретной СУБД.
Основная проблема, которую решает СУБД на этой стадии - организация рациональной структуры хранения данных и методов доступа к ним. Реализация физического хранения информации выполняется механизмами СУБД. Дополнительно здесь же решаются вопросы эффективного выполнения запросов к БД, для чего строятся некоторые вспомогательные структуры, например, индексы.
Процедура создания физической модели БД предполагает выполнение следующих действий:
С помощью выбранной СУБД создаём файл БД с заданным именем. Здесь будут храниться все объекты базы данных (таблицы, запросы, отчеты и т.д.).
Описываем структуру таблицы для каждого объекта ПрО (сущности из БД), а также определяем типы данных для каждого столбца.
Связываем все таблицы между собой, в результате выстраиваем схему данных, являющуюся аналогом логической модели БД.
Посредством шагов 1 - 3 осуществляется информационное моделирование ПрО. По завершению п.3 у вас основная задача решена: создана информационная модель ПрО в виде БД. Она, как всякая модель, нуждается в оценке качества, поскольку проведён завершающий этап. (прежде чем выполнять п.4, результаты выполнения п.3 необходимо представить преподавателю!)
Наполняем таблицы конкретной информацией путём ввода записей.
Конструируем дополнительные объекты БД (запросы, формы, отчёты и т.д.), которые нацелены на удовлетворение всех информационных потребностей.
На рис.35-37 представлены варианты реализации физической модели БД (рис.36,37) на основе логической модели (рис.35).
Рис. 35. Логическая модель базы данных
Рис. 36. Физическая модель базы данных: реализация наследования через миграцию предка в потомков
Рис. 37. Физическая модель базы данных: реализация наследования через замену иерархии идентифицирующими связями
Требования, предъявляемые к физической модели
Адекватность базы данных предметной области.
Легкость разработки и сопровождения базы данных.
Скорость выполнения операций изменения данных (вставка, обновление, удаление кортежей).
Скорость выполнения операций выборки данных.
Поскольку физическая модель базы данных является завершением важнейшей первой части курсовой работы, перед заполнением информацией БД, рассмотрим требования, предъявляемые к физической модели более детально.
1

. Адекватность базы данных предметной области
Под адекватностью понимают соответствие результатов моделирования реальному объекту. Это означает, что должны выполняться следующие условия:
Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных.
Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Для проверки адекватности, БД «проигрывают» на различных сценариях. В частности, проверяют, удается ли создать запросы для получения нужных заказчику сведений. Насколько полно и верно отображаются в отчетах текущие данные и ожидаемые итоги?
Следует отметить, что современные СУБД располагают встроенными инструментами по совершенствованию качества БД. Например, в Microsoft Access существуют:
мастер анализа таблиц, который позволяет оценить структуру таблицы, предложить подходящие новые структуры и связи, а также разделить таблицу на новые связанные таблицы, если это имеет смысл;
анализатор быстродействия, который дает рекомендации по улучшению этого показателя по результатам исследования структуры БД.
При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных? При этом опять-таки решения, принятые на уровне логического моделирования, определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД.
2. Легкость разработки и сопровождения базы данных
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных