Моделирование локальных представлений
Локальное представление (ЛП) – соответствует отдельному внешнему приложению (функциональной задаче либо отдельному пользователю). Для каждого ЛП формулируются сущности, о которых должна накапливаться информация. В отдельном локальном представлении используют шесть-семь типов сущностей.
При объединении моделей ЛП формируются новые конструкции. Они образуются введением понятий более высокого уровня по отношению к понятиям ЛП. Вводимые конструкции должны обеспечивать непротиворечивые представления данных. Обычно используются бинарные объединения (рис. 4.3).
Используются три основополагающие концепции объединения:
1) идентичность (два и более элементов модели идентичны, если имеют одинаковое семантическое (смысловое) значение);
2) агрегация (агрегация позволяет рассматривать связь между элементами модели, как новый объект);
- в одном ЛП объект определён как единое целое, в других определены его составные части;
- объект не определён как единое целое, его составные части определены в разных ЛП;
- объект определен в разных ЛП, но составы его в разных ЛП различны.
3) обобщение (обобщение – это абстракция данных, трактующая класс различных подобных типов объектов как один поименованный обобщенный тип объекта).
Рис. 4.3. Модель результирующего представления
Фаза, последующая за логическим проектированием, называется фазой физического проектирования. При логическом проектировании не принимаются во внимание специфические функциональные возможности целевой базы данных и прикладных программ, однако учитываются особенности выбранной модели хранения данных. Результатом логического проектирования являются глобальная логическая модель данных и комплект описывающей ее сопроводительной документации. В совокупности эти результаты являются исходной информацией для фазы физического проектирования базы данных и предоставляют ее разработчику все необходимое для принятия решений, направленных на достижение максимальной эффективности создаваемого проекта.
Образно говоря, при логическом проектировании разработчик сосредоточивается на том, что надо сделать, тогда как при физическом проектировании он ищет способ, как это сделать.
Методология физического проектирования баз данных включает четыре основных этапа:
1. Разработка таблиц базы данных и установка необходимых ограничений целостности данных.
2. Выбор схемы хранения данных и определение методов доступа к таблицам базы данных.
Как правило, каждая СУБД предоставляет несколько альтернативных вариантов схемы хранения данных. С точки зрения пользователя организация внутренней структуры хранения помещенных в таблицы данных должна быть совершенно прозрачна – пользователь должен иметь возможность получать доступ к любой таблице и отдельным ее строкам без необходимости указания способа хранения этих данных. Это означает, что СУБД должна обеспечивать полную независимость физического хранения данных от их логической организации. Только в этом случае внесение изменений в физическую организацию базы данных не окажет никакого влияния на работу пользователей. Отображение логической модели данных на структуру их физической организации определяется внутренней схемой базы данных.
3. Проектирование системы защиты базы данных от несанкционированного доступа. Сюда относится принятие решений о методах реализации каждой локальной логической модели данных, а также о мерах контроля доступа к отдельным таблицам базы.
4. Организация процессов мониторинга созданной системы, задача которого состоит в выявлении и устранении любых проблем, связанных с производительностью приложений и вытекающих из особенностей реализации проекта. Здесь же осуществляется реализация новых и изменяющихся требований.
Контрольные вопросы
1. Перечислите общие принципы построения концептуальной модели предметной области.
2. Охарактеризуйте основные компоненты инфологической модели.
3. Как строится модель «сущность-связь»?
4. Что такое локальное представление и как оно формируется?
5. В чем заключается методология физического проектирования баз данных?