Файл: Практикум по дисциплине базы данных Лабораторная работа n 2 Построение концептуальной модели базы данных. Моделирование составных и концептуальных объектных множеств.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.05.2024
Просмотров: 29
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Создавая модель данных для библиотеки, остановимся не следующих примерных вопросах: Сколько в библиотеке книг Чарлза Диккенса? Сколько в библиотеке разных книг издательства Signet Classic? Сколько книг в библиотеке второго издания?
Сколько в библиотеке копий книги «Гордость и предубеждение»?
Из этих вопросов мы получаем три типа «книг»: Концептуальная книга, Издание концептуальной книги, Физическая книга.
Из первых двух мы сконструируем два объектных множества и отношение (рис. 16).
Рис. 16. Предварительное решение библиотечной проблемы
Обратите внимание на минимальную и максимальную мощности отношения со стороны объекта КОНЦЕПТУАЛЬНАЯ-КНИГА. Эти мощности показывают, что объектное множество КОНЦЕПТУАЛЬНАЯ-КНИГА-ИЗДАНИЕ зависимо от объектного множества КОНЦЕПТУАЛЬНАЯ-КНИГА. Это означает, что каждая конпептуальная-книга-издание представляет собой издание одной и только одной концептуальной книги.
Зависимое объектное множество. Объектное множество, каждый элемент которого должен быть связан хотя бы с одним элементом другого объектного множества.
Хотя такое решение отвечает на некоторые вопросы, оно совершенно не помогает нам ответить на вопрос типа
Сколько в библиотеке разных книг издательства Signet Classic?
Проблема заключается во множестве КОНЦЕПТУАЛЬНАЯ-КНИГА-ИЗДАНИЕ. Поскольку каждый элемент этого множества — издание конкретной книги, то мы не можем отследить одинаковые издания разных книг. Дополнительная проблема состоит в том, что наше множество КОНЦЕПТУАЛЬНАЯ-КНИГА-ИЗДАНИЕ должно содержать значительно больше элементов, чем это на самом деле необходимо.
Рис. 17. Более удачное решение библиотечной проблемы
На рис. 17 представлено более удачное решение. В этом случае ИЗДАНИЕ — независимое объектное множество, существующее само по себе. Поскольку каждая концептуальная книга может иметь несколько изданий, ИЗДАНИЕ не может быть атрибутом объекта КОНЦЕПТУАЛЬНАЯ-КНИГА. Таким образом, отношение между объектами КОНЦЕПТУАЛЬНАЯ-КНИГА и ИЗДАНИЕ имеет мощность много-ко-многим. С помощью этой модели на вопрос об изданиях можно ответить, а ненужных повторов концептуальных изданий не будет. Например, издательство Signet Classic встречается в объектном множестве EDITION только один раз, тогда как в предыдущей модели оно повторялось дважды в объектном множестве КОНЦЕП-ТУАЛЬНАЯ-КНИГА-ИЗДАНИЕ на рис. 16: «Оливер Твист изд-во Signet Classic» и «Давид Копперфильд изд-во Signet Classic». Поскольку издательство Signet Classic выпускает множество книг, наш новый подход избавляет нас от множества возможных повторений.
Воспользовавшись рис. 17, мы можем добавить к нашей модели понятие «физической книги» (рис. 18). Элемент множества ФИЗИЧЕ-СКАЯ-КНИГА представляет том, который можно пометить инвентарным номером и который может быть выдан только одному человеку за раз. В нашем примере мы считаем, что инвентарный номер содержит всю информацию, необходимую для идентификации конкретной физической книги. Таким образом, внешний ключ для каждой физической книги — это ее инвентарный номер или номер физической идентификации, по которому ее можно отслеживать при инвентарном учете. Инвентарный номер может содержать такую информацию, как номер копии, позволяющий отличать одну копию данной концептуальной книги от другой.
Рис. 18. Третье решение библиотечной проблемы
Обратите внимание, что отношение СОДЕРЖИТСЯ-В на рис. 18 имеет мощность один-ко-многим. Такая мощность подразумевает, что данная комбинация книга-издание может содержаться в нескольких физических книгах. Это соответствует нашему представлению о реальности. Но эта мощность также означает, что данная физическая книга может содержать только одну комбинацию книга-издание. Верно ли это?
Рассмотрим книгу, содержащую сборник произведений Джейн Остин. Такая книга содержит несколько концептуальных книг, хотя мы можем сказать, что все они имеют одно и то же издание. Все эти концептуальные книги содержатся в одной и той же физической книге, как показано на рис. 19.
Рис. 19. Пример сборника
Поскольку такая ситуация не является необычной, в целях точности мы должны изменить мощность на рис. 18 с один-ко-многим на много-ко-многим (рис. 20). Таким образом, одна физическая книга может быть связана с несколькими концептуальными книгами.
Рис. 20. Исправленное решение библиотечной проблемы
Наша модель данных все еще весьма ограничена. Если пользователям библиотеки нужно идентифицировать язык, на котором издана книга, нам может понадобиться выделить язык в отдельный объект. Язык может быть атрибутом комбинации книга-издание (в предположении, что одно издание книги может быть только на одном языке), или же отдельным объектным множеством, находящемся в отношении много-ко-многим с книгой-изданием. В этом случае данное издание может содержать произведения на итальянском, французском, испанском, английском и т.д. На рис. 21 ЯЗЫК представлен как отдельный объект, связанный отношением ИЗДАНА-НА-ЯЗЫКЕ с составным множеством ИМЕЕТ-ИЗДАНИЕ. Физическая книга будет связана с элементом составного множества ИЗДАНА-НА-ЯЗЫКЕ, включающего концептуальную книгу, издание и язык.
Рис. 21. Язык как отдельный объект в решении библиотечной проблемы
Различие между концептуальными книгами и физическими книгами является ключевым при решении этой проблемы. Что еще более важно, различие концептуального и физического полезно при решении многих сходных задач моделирования данных. Вы встретитесь с ним во множестве различных ситуаций в бизнесе. Любой случай, когда слово употребляется в нескольких значениях, является потенциальной проблемой. Определяя отдельные объектные множества для каждого значения многозначного термина и соответствующие отношения между ними, мы можем сконструировать модель данных, которая обеспечит пользователей всей необходимой информацией. Мы поясним это на дополнительных примерах.
3.4. Концептуальные объекты для Консультационной Службы Мэнуоринг
На протяжении нескольких лет компания Мэнуоринг создавала различные прикладные компьютерные системы для своих клиентов. Поработав с множеством разных клиентов, работники фирмы обнаружили, что у клиентов часто возникают одни и те же потребности, и что для их нужд можно использовать одно и то же базовое программное обеспечение.
Например, Статтену требуется система подсчета причитающихся сумм, система подсчета сумм, подлежащих оплате, и система расчета стоимости. Сандерману нужна система подсчета сумм, подлежащих оплате, система расчета стоимости и система начисления зарплаты. Создав обобщенные системы подсчета причитающихся сумм, сумм, подлежащих оплате, расчета стоимости, инвентарного учета, начисления зарплаты и т.д., фирма Мэнуоринг может удовлетворить потребности многих клиентов за меньшую цену. Отсюда возникла идея создания базовых систем в каждой из этих областей.
На рис. 22а представлена модель данных, отражающая отношения между базовыми системами и клиентскими системами на их основе.
Рис. 22. Модели данных о концептуальных и физических системах
Базовые системы имеют номер версии для различия версий системы. Например, первая версия системы подсчета причитающихся сумм может иметь номер версии 1.0. Вторая и третья версии могут иметь номера 1.1 и 2.0 соответственно. Поскольку каждая базовая система может иметь несколько версий, а каждый номер версии может относиться ко многим базовым системам, мощность отношения между объектами БАЗОВАЯ СИСТЕМА и НОМЕР ВЕРСИИ — много-ко-многим.
Каждая клиентская система связана с базовой системой (системами), на основе которых она создана. Кроме того, поскольку клиент всегда получает конкретную версию базовой системы, то клиентская система связана и с базовой системой, и с номером версии, что выражается отношением ВКЛЮЧЕНА-В между объектом КЛИЕНТСКАЯ-СИСТЕМА и составным объектом БАЗОВАЯ СИСТЕМА — НОМЕР ВЕРСИИ.
Отношение ВКЛЮЧЕНА-В имеет мощность много-ко-многим, поскольку данная клиентская система может быть создана на основе нескольких комбинаций базовая-система/номер-версии, а каждое сочетание базовая-система/номер-версии может входить в несколько клиентских систем.
На рис. 226 представлены примеры данных в такой модели. Система, созданная для клиента Статтена, представлена точкой под прямоугольником КЛИЕНТСКАЯ-СИСТЕМА. Эта система основана на системе подсчета причитающихся сумм, версия 2.0, поэтому на диаграмме она связана с парой (подсчет причитающихся сумм, 2.0). Если бы система Статтена включала версии других базовых систем, она была связана также и с ними.
Эта модель данных иллюстрирует различие концептуального и физического. Объектное множество БАЗОВАЯ СИСТЕМА — это концептуальное объектное множество, а КЛИЕНТСКАЯ-СИСТЕМА — физическое объектное множество. На самом деле этот пример очень похож на библиотечный, рассмотренный ранее. Если вы сравните рисунки 22а и рис. 20, то обнаружите следующие соответствия:
КОНЦЕПТУАЛЬНАЯ КНИГА -------------------БАЗОВАЯ СИСТЕМАИЗДАНИЕ ------------------------------НОМЕР ВЕРСИИ
ФИЗИЧЕСКАЯ КНИГА ----------------------------КЛИЕНТСКАЯ СИСТЕМА
Цель этого примера, как и предыдущего, — проиллюстрировать двусмысленность естественного языка, используемого для описания требований пользователей базы данных. Для того чтобы убедиться в полноте и точности нашей модели данных, мы должны тщательно проанализировать обстоятельства ее применения и виды информации, необходимой пользователям системы.
4. ОБЪЕДИНЕНИЕ ПРЕДСТАВЛЕНИЙ ДАННЫХ
Во всех примерах, рассмотренных в последних трех главах, общим было то, что мы пытались создать одну модель, удовлетворяющую потребности всех пользователей, с которыми мы работаем.
В большой организации такой упрощенный подход невозможен, и проект базы данных потребует от групп аналитиков, работающих с разными группами пользователей, создания разных моделей данных. Для того чтобы создать единую, целостную базу данных, эти представления данных необходимо интегрировать в единую модель данных.
Представление данных. Определение ограниченной части базы данных.
В качестве примера рассмотрим две модели данных Консультационной Службы Мэнуоринг и посмотрим, как их можно интегрировать в единую модель данных. Наш подход будет основан на попытке максимального сохранения каждого представления данных в его исходном виде и связывания объектных множеств из разных представлений данных, создав между ними новые отношения.
Рассмотрим рисунки 13 и 22а. На рис. 13 мы видим объект КЛИЕНТ с атрибутом ИМЯ, а на рис. 22а есть объект КЛИЕНТСКАЯ СИСТЕМА с атрибутом ИМЯ КЛИЕНТА.
Поскольку атрибут ИМЯ КЛИЕНТА с рис. 22а и атрибут ИМЯ с рис. 13 представляют один и тот же атрибут, в объединенной модели один из них нужно опустить как избыточный. Возможным решением будет связать объекты КЛИЕНТСКАЯ СИСТЕМА и КЛИЕНТ и опустить атрибут ИМЯ КЛИЕНТА, как показано на рис. 23а.
Однако в этом решении не учитываются другие части рис. 13. Например, клиентские системы являются результатом работы над проектами. Поэтому разумно связать объектное множество КЛИЕНТСКАЯ СИСТЕМА с объектным множеством ПРОЕКТ, как показано на рис. 236.
Отношение СОЗДАНА-В-РЕЗУЛЬТАТЕ отражает тот факт, что каждая система создана в результате серии проектов, каждый из которых выполнялся для одного и того же клиента.
Таким образом, мы можем перейти от клиентской системы через проекты, выполненные для ее установки, к клиенту, для которого эти проекты исполнялись. Это решение объединяет два представления данных в общую целостную модель данных, которую мы искали.
Рис. 23. Примеры интеграции данных
Объединение представлений данных в базу данных большой организации - это сложная проблема, требующая анализа объектных множеств, атрибутов и отношений представлений данных аналитиками и пользователями, которые лучше всего знакомы с этими представлениями данных.
Мы привели простой пример, иллюстрирующий основные идеи. В реальной ситуации бизнеса интеграция представлений данных в некоторых случаях получается, а в некоторых - нет.
Как мы отмечали ранее, из-за сложности проектирования базы данных некоторые организации решают не создавать общую корпоративную базу данных для всех информационных нужд. Выбирая такой подход, они избегают некоторых наиболее сложных аспектов интеграции представлений данных.