- •Построение модели данных для составных объектов
- •2.2. Концептуальная модель строительной компании Премьер
- •2.3. Концептуальная модель Консультационной Службы Мэнуоринг
- •Моделирование концептуальных и физических объектов
- •3.1. Основные понятия
- •3.2. Библиотечная проблема
- •3.3 Проектирование модели данных для библиотеки
- •3.4. Концептуальные объекты для Консультационной Службы Мэнуоринг
- •4. Объединение представлений данных
- •5. Задание для самостоятельной работы
- •3. Воспользуйтесь концептуальными и физическими объектными множествами при создании моделей данных для следующих задач:
4. Объединение представлений данных
Во всех примерах, рассмотренных в последних трех главах, общим было то, что мы пытались создать одну модель, удовлетворяющую потребности всех пользователей, с которыми мы работаем.
В большой организации такой упрощенный подход невозможен, и проект базы данных потребует от групп аналитиков, работающих с разными группами пользователей, создания разных моделей данных. Для того чтобы создать единую, целостную базу данных, эти представления данных необходимо интегрировать в единую модель данных.
Представление данных. Определение ограниченной части базы данных.
В качестве примера рассмотрим две модели данных Консультационной Службы Мэнуоринг и посмотрим, как их можно интегрировать в единую модель данных. Наш подход будет основан на попытке максимального сохранения каждого представления данных в его исходном виде и связывания объектных множеств из разных представлений данных, создав между ними новые отношения.
Рассмотрим рисунки 13 и 22а. На рис. 13 мы видим объект КЛИЕНТ с атрибутом ИМЯ, а на рис. 22а есть объект КЛИЕНТСКАЯ СИСТЕМА с атрибутом ИМЯ КЛИЕНТА.
Поскольку атрибут ИМЯ КЛИЕНТА с рис. 22а и атрибут ИМЯ с рис. 13 представляют один и тот же атрибут, в объединенной модели один из них нужно опустить как избыточный. Возможным решением будет связать объекты КЛИЕНТСКАЯ СИСТЕМА и КЛИЕНТ и опустить атрибут ИМЯ КЛИЕНТА, как показано на рис. 23а.
Однако в этом решении не учитываются другие части рис. 13. Например, клиентские системы являются результатом работы над проектами. Поэтому разумно связать объектное множество КЛИЕНТСКАЯ СИСТЕМА с объектным множеством ПРОЕКТ, как показано на рис. 236.
Отношение СОЗДАНА-В-РЕЗУЛЬТАТЕ отражает тот факт, что каждая система создана в результате серии проектов, каждый из которых выполнялся для одного и того же клиента.
Таким образом, мы можем перейти от клиентской системы через проекты, выполненные для ее установки, к клиенту, для которого эти проекты исполнялись. Это решение объединяет два представления данных в общую целостную модель данных, которую мы искали.
Рис. 23. Примеры интеграции данных
Объединение представлений данных в базу данных большой организации - это сложная проблема, требующая анализа объектных множеств, атрибутов и отношений представлений данных аналитиками и пользователями, которые лучше всего знакомы с этими представлениями данных.
Мы привели простой пример, иллюстрирующий основные идеи. В реальной ситуации бизнеса интеграция представлений данных в некоторых случаях получается, а в некоторых - нет.
Как мы отмечали ранее, из-за сложности проектирования базы данных некоторые организации решают не создавать общую корпоративную базу данных для всех информационных нужд. Выбирая такой подход, они избегают некоторых наиболее сложных аспектов интеграции представлений данных.
Конечно, меньшие базы данных будут, в свою очередь, состоять из наборов пользовательских представлений данных, и проектирование каждой из них потребует объединения данных.