тест. LBD2_1 п. 1,2 любых 3 и любое 1. Практикум по дисциплине базы данных Лабораторная работа n 2 Построение концептуальной модели базы данных. Моделирование составных и концептуальных объектных множеств

• Название: Практикум по дисциплине базы данных Лабораторная работа n 2 Построение концептуальной модели базы данных. Моделирование составных и концептуальных объектных множеств
• Дата: 14.01.2023
• Размер: 0.52 Mb.
• Имя файла: LBD2_1 п. 1,2 любых 3 и любое 1.doc
• Тип: Практикум; #886513

ГОСУДАРСТВЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПО ВЫСШЕМУ ОБРАЗОВАНИЮ

Новосибирская государственная академия экономики и управления

ЛАБОРАТОРНЫЙ ПРАКТИКУМ ПО ДИСЦИПЛИНЕ

«БАЗЫ ДАННЫХ»
Лабораторная работа N 2
«Построение концептуальной модели базы данных.

Моделирование составных и концептуальных объектных множеств»

НОВОСИБИРСК 2000

1. ВВЕДЕНИЕ

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

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

2. 
   ПОСТРОЕНИЕ МОДЕЛИ ДАННЫХ
   

ДЛЯ СОСТАВНЫХ ОБЪЕКТОВ

2.1. Основные понятия

Хотя модели, созданные нами при помощи базовых приемов моделиро­вания (лабораторная работа №1), относительно просты, нетрудно убедиться в их возможностях и при­носимой ими пользе. Однако большинство проблем, с которыми мы в дейст­вительности сталкиваемся в бизнесе, значительно более сложны и часто тре­буют использования составных объектов, то есть отношений, рассматривае­мых как объектные множества, или отношений высокого порядка, в кото­рых участвуют три или более объектных множества.

Составной объект. Отношение, рассматриваемое как объектное множество.

Отношение высокого порядка. Отношение между тремя или более объектными множествами.

Отношение можно использовать как объектное множество. Например, мужчина и женщина, связанные собой отношением СОСТОИТ-В-БРАКЕ-С составляют семейную пару, которая сама по себе яв­ляется объектом. Будучи таковым, семейная пара может обладать собствен­ными атрибутами, такими как дата свадьбы, общий доход и адрес. Более того, она может участвовать в других отношениях, таких, как ВЛАДЕЕТ-АВТОМОБИЛЕМ или ЯВЛЯЮТСЯ-РОДИТЕЛЯМИ. Таким образом, отноше­ние СОСТОИТ-В-БРАКЕ-С можно рассматривать как объектное множество, элементами которого являются семейные пары.



Рис. 1. Отношение как объектное множество

Это относится ко всем отношениям. Отношения можно рассматривать как объекты, они могут обладать атрибутами и участвовать в других отно­шениях. Они называются составными объектными множествами. Графически мы обозначаем составное множество прямоуголь­ником, нарисованным вокруг отношения и участвующих в нем объектных множеств (рис. 1). Иногда для удобства мы будем давать составным объ­ектам объектные имена — существительные — дополнительно к имени от­ношения. Например, на рис. 1 СЕМЕЙНАЯ-ПАРА — имя объектного множества, данное отношению СОСТОИТ-В-БРАКЕ-С, Это разумно, если от­ношение используется в качестве объектного множества.

Если в отношениях, уча­ствуют два объектных множества, то такие отношения называются бинар­ными. Однако отношение может связывать три и более объектных множе­ства. Такие отношения высокого порядка называются n-арными отноше­ниями, где n обозначает число объектных множеств. Для упрощения терминологии будем называть 3-арные и 4-арные отношения трехсторонними и четырехсторонними.

Бинарное отношение. Отношение между двумя объектными множествами.

n-арное отношение. Отношение между n объектными множествами.

Проиллюстрируем эти понятия примером. Предположим, что Дик Грин­берг из International Product Distribution (IPD) хочет отслеживать продажи разных видов товаров по странам. Чтобы помочь ему, мы создаем объектное множество ТОВАР, объектное множество СТРАНА и устанавливаем отноше­ние ПРОДАН-В между ними (рис. 2).

Рис.2. Модель отслеживания продаж

Элемент множества ТОВАР, например, «средство для мытья посуды .№5» связан с элементом множества СТРАНА (например. Англия), если средство для мытья посуды №5 продано в Англии. Если мы рассмотрим отношение ПРОДАН-В как объектное множество, мы можем приписать ему атрибут КОЛИЧЕСТВО, отражающий количество каждого товара, проданное в каждой стране.

Обратите внимание, что атрибут КОЛИЧЕСТВО зависит и от товара, и от страны. То есть мы не можем определить значение количества только по товару или только по стране — нам нужно и то, и другое. Вот почему КОЛИЧЕСТВО — атрибут отношения между товаром и страной, а не страны или товара по отдельности. По этой причине модели на рис. 3 обе неправильны. В случае (б) модель не различает количества товара, про­данные в разных странах, а в случае (в) модель не различает товары, про­данные в стране.




Рис. 3. Неправильные модели отслеживания продаж
Модель на рис. 2 позволяет отслеживать продажи товара в стране. Однако предположим, что нам нужна более тонкая классификация продаж, чем дает модель. В частности, мы хотим записывать количество каждого товара, проданного в каждой стране в конкретный день. Тогда мы связываем ПРОДАН-В с объектом ДАТА и приписываем атрибут КОЛИЧЕСТВО этому новому отношению (рис. 4). Снова атрибут принад­лежит внешнему отношению, поскольку для определения количества требу­ется знать элементы всех трех множеств: ТОВАР, СТРАНА и ДАТА.



Рис. 4. Отслеживания продаж по стране и дате

На рис. 4. представлено решение этой задачи в виде двух бинарных отношений, первое из которых (ПРОДАН-В) используется как объектное множество во втором отношении ПРОДАН-ТОГДА-ТО.

Однако может ока­заться более удобным представить эту модель в виде одного трехстороннего отношения, как на рис. 5. Мы снова видим, что КОЛИЧЕСТВО - атри­бут отношения между всеми тремя объектными множествами.

Рис. 5. Отслеживание продаж по стране и дате (второй вариант)

Любое отношение высокого порядка можно разбить на последователь­ность вложенных бинарных отношений. Однако не все из них будут иметь для нас какой-либо «физический» смысл. Поэтому иногда при построении моделей данных мы будем пользоваться n-арными отношениями, так как их может оказаться легче связать с нашей реальной проблемой.

В соответствии с максимальными мощностями отношений высокого по­рядка мы предполагаем, что все бинарные отношения, составляющие отно­шение высокого порядка имеют тип много-ко-многим. Это допущение обычно верно на практике.

2.2. Концептуальная модель строительной компании Премьер

Строительная компания Премьер возводит различные здания. Для всех зданий требуются разнообразные материалы в различных количествах. На разных этапах проекта работают разные бригады. Например, есть бригады арматурщиков, каменщиков, штукатуров и т.д. Составляя график работ, фирма Премьер варьирует состав бригад. Рабочие назначаются в разные бри­гады в соответствии с квалификацией. Один рабочий может выполнять различные виды работы, например, плотника каменщика, поэтому его иногда включают в бригаду арматурщиков, иногда каменщиков. Численность бригад меняется в зависимости от размера здания и предъявляемых к нему требований. Следо­вательно, бригады составляются таким образом, как требуется для конкрет­ного здания. Кроме того, для каждой бригады, работающей на строительстве данного здания, назначается бригадир. Рабочий может возглавлять одну бригаду и работать в другой простым рабочим. Менеджер компании, хочет знать, кто из его рабочих в какую бригаду назна­чен на разных зданиях, какие материалы используются при возведении раз­ных зданий, а также график работ по каждому зданию. Разработаем концептуальную модель базы данных, которая может обеспечить нуж­ную информацию.

На рис. 6 представлено отношение между зданиями и материалами. Объектное множество ЗДАНИЕ содержит элементы, соответствующие зда­ниям. Объектное множество ТИП МАТЕРИАЛА представляет типы материа­лов, например, «доска 2х4х10 дюймов» или «гвозди №10». Мощность отно­шения между множествами ЗДАНИЕ и ТИП МАТЕРИАЛА указывает, что для каждого здания требуется несколько типов материалов и каждый тип материалов используется в нескольких зданиях. Обратите внимание, что атрибут АДРЕС относится только к множеству ЗДАНИЕ. АДРЕС может ис­пользоваться в качестве ключа для идентификации конкретного здания.



Рис. 6. Моделирование отношений между зданиями и материалами
Прямоугольник вокруг отношения ТРЕБУЕТ показывает, что мы хотим рассматривать отношение как составное объектное множество. Затем мы придаем этому объектному множеству атрибут КОЛИЧЕСТВО. Элементами этого объектного множества являются пары: здание и тип материала. Так, например, элементом множества ТРЕБУЕТ может быть пара, составленная из здания на Пятой стрит, 610, и доски 2х4х10 дюймов. Этой паре затем приписывается количество — например, 500 штук — в котором такие доски требуются для строительства данного здания.

Важно отметить, что в этом примере объектное множество ТИП МАТЕРИАЛА представляет собой скорее концептуальный, чем физический объект. Это означает, что каждый элемент множества ТИП МАТЕРИАЛА обозначает тип материала, а не физический «кусок» материала. Такое поня­тие концептуального объекта, противопоставляемого физическому объекту, часто применяется в концептуальном моделировании данных. В некоторых случаях требуется моделировать отдельные объектные множества для физи­ческих объектов.

Концептуальный объект. Объект, обозначающий тип вещей.

Физический объект. Объект, обозначающий реальный физический предмет.

Теперь мы покажем, как отразить формирование бригад и назначение рабочих и бригадиров. На рис. 7 представлено отношение между объект­ными множествами ТИП БРИГАДЫ и ЗДАНИЕ. ТИП БРИГАДЫ — еще один пример концептуального объектного множества; то есть элементы множества ТИП БРИГАДЫ соответствуют не конкретным бригадам, а ти­пам бригад, таким как бригада арматурщиков или бригада каменщиков.


Рис. 7. Модель формирования бригад

От­ношение между зданием и типом бригады представляет конкретную бригаду - бригаду, назначенную выполнять на данном здании данный тип работ. Таким образом, мы можем рассматривать это отношение как объект. Назовем его БРИГАДА.


Рис. 8. Назначение рабочих в бригады

Для каждой бригады как элемента объектного множества БРИГАДА вы­бираются дни работы. Например, бригаде штукатуров требуется несколько дней для того чтобы оштукатурить данное здание. Таким образом, у нас есть отношение мощности много-ко-многим, РАБОТАЕТ-ТОГДА-ТО, между объ­ектами БРИГАДА и ДАТА.

На рис. 8 представлено распределение рабочих и бригадиров по бри­гадам. Обратите внимание, что отношение ЯВЛЯЕТСЯ-БРИГАДИРОМ имеет мощность один-ко-многим. Это связано с тем, что у бригады может быть только один бригадир, при этом один и тот же человек может возглавлять несколько бригад.

На рис. 9 представлена объединенная диаграмма, представляющая полную модель данных для строительной компании.


Рис.9. Модель данных для строительной компании

2.3. Концептуальная модель Консультационной Службы Мэнуоринг

В лабораторной работе № 1 мы создавали модель данных для Консультационной Службы Мэнуоринг. Использованные тогда формы были упрощены, чтобы к ним можно было применить базовые принципы моделирования данных.

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



Рис. 10. Расширенная версия формы заказа Консультационной Службы

На рис. 10 представлен расширенный вариант формы заказа Консуль­тационной Службы Мэнуоринг. Данная форма содержит новые поля: Описание то­вара, Количество, Цена единицы товара, Сумма. В исходной форме зака­занное количество товара содержалось в поле Описание товара, тогда как в новой форме ему соответствует отдельное поле, Поля Цена единицы товара в исходной форме не было вовсе. Цена в исходной форме совпадала с суммой новой формы.

У новой формы есть два преимущества:

1. Поскольку Цена единицы товара является функцией заказанного товара, сумму можно автоматически вычислить, используя Количество и Цену единицы товара. В старой форме эти вычисления производились вручную.

2. Поскольку Количество указывается отдельно, его можно использовать в вычислениях как внутри самой формы, так и при определении общего заказанного количества того или иного товара за определенный промежуток времени. Такие подсчеты могут быть нужны для ответа на подобные вопросы:

Сколько блокнотов мы использовали за последний год?

На рис. 11 представлена модель данных, выведенная из новой формы заказа.



Рис. 11. Модель данных для расширенной формы заказа

Обратите внимание, что мы создали составной объект из отношения между объектами ТОВАР и ЗАКАЗ. КОЛИЧЕСТВО и СУММА являются ат­рибутами составного объекта, поскольку они зависят и от объекта ТОВАР, и от объекта ЗАКАЗ.

Так, количество — это число единиц товара, включенных в конкретный заказ. СУММА — это вычисляемый атрибут, который относится к паре ТОВАР и ЗАКАЗ, как и КОЛИЧЕСТВО.

Обратите также внимание, что ОПИСАНИЕ, ИНВЕНТАРНЫЙ № и ЦЕНА ЕДИНИЦЫ ТОВАРА является атрибутами только ТОВАР, поскольку они зависят только от ТОВАР, а не ЗАКАЗ. ОПИСАНИЕ в новой модели имеет не такое значение, как в прежней модели, поскольку в прежней модели ОПИСАНИЕ включало количество заданного товара.

На рис. 12 представлен расширенный вариант счета Консультационной Службы Мэнуоринг. Обратите внимание, что счет разделен на Работу консультанта и Другие расходы.



Рис.12 . Расширенный счет Консультационной Службы
В новой версии счета мы показываем Вид деятельности и Часы вместо Описания исходной формы. ОПИСАНИЕ было полем свободного формата, в которое пользователь мог записать любую информацию описательного характера, которую сочтет подходящей.

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

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

Модель данных для такого счета представлена на рис. 13. Мы создали составной объект из отношения между объектами КОНСУЛЬТАНТ и ВИД ДЕЯТЕЛЬНОСТИ, а также из отношения между этим составным объектом и объектом ПРОЕКТ.


Рис. 13. Модель данных для расширенного счета
Атрибуты ЧАСЫ и КОЛИЧЕСТВО относятся к большему составному множеству, поскольку они зависят и от консультанта, и от вида деятельности, и от проекта. Так, атрибут ЧАСЫ говорит нам, как долго данный консультант занимался данным видом деятельности при выполнении данного проекта.

Обратите внимание, что атрибут СТАВКА относится непосредственно к объектному множеству КОНСУЛЬТАНТ, так как его значение зависит только от консультанта. Это означает, что Мэнуоринг платит каждому консультанту фиксированную сумму в час независимо от вида деятельности, которую он в этот раз выполняет. Это отражено на рис. 12, из которого видно, что ставка Родригеса всегда составляет 60 долларов в час.

КОЛИЧЕСТВО обозначает оплату конкретного вида деятельности данного консультанта при работе над проектом. Она вычисляется путем умножения ставки из атрибута СТАВКА данного консультанта на количество часов из атрибута ЧАСЫ соответствующих консультанта, вида деятельности и проекта.

В начале главы мы видели, что Джоан Мэнуоринг заинтересована в сис­теме, связывающей консультантов» их деятельность и клиентов, чтобы мы могли получать информацию об отношениях между ними. На рис. 13 представлена необходимая модель данных. Данные, поддерживаемые этой моделью, позволяют создавать большее количество отчетов, два из которых представлены на рис. 14 и 15.

Отчет о деятельности консультантов на рис. 14 показывает, сколько часов каждый консультант занимался каждым видом деятельности на про­тяжении последнего года. Например, Четмен 900 часов занимался програм­мированием, 600 часов обучал пользователей и 450 занимался в офисе рабо­той, на оплату которой нельзя выставить счет клиентам.


Рис 14. Первый отчет, используемый Консультационной Службой

Отчет консультант-клиент на рис. 15 показывает, сколько часов каждый консультант рабо­тал для каждого клиента.



Рис 15. Второй отчет, используемый Консультационной Службой
Модель данных на рис. 13 можно использовать для создания множе­ства аналогичных отчетов. Например, можно создать отчет, отражающий, каким именно видом деятельности каждый консультант занимался для каж­дого клиента и в каком проекте. Разумеется, в него также можно включить количество времени, затраченного на выполнение каждой работы. Другой отчет может отражать средний процент затрат времени на каждый вид деятельности при выполнении проектов. Например, если результаты отчета по­кажут, что в среднем системный анализ занял только 5 процентов времени исполнения проекта, то может возникнуть идея проведения дополнительного обучения консультантов системному анализу.

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

2. 
   МОДЕЛИРОВАНИЕ КОНЦЕПТУАЛЬНЫХ И ФИЗИЧЕСКИХ ОБЪЕКТОВ
   

3.1. Основные понятия

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

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

В предыдущем пункте мы упомянули несколько примеров концепту­альных объектных множеств. Например, ТИП МАТЕРИАЛА и ТИП БРИГАДЫ строительной компании Премьер были примерами концептуаль­ных объектных множеств, поскольку их элементы соответствовали типам предметов, а не конкретным физическим представителям этих типов. Типом материала будет словосочетание «доска 2х4х10 дюймов», а не конкретная такая доска. Типом бригады будет слово «кровельщики» или «электрики», тогда как конкретная бригада будет «кровельщики здания на Мэйн стрит, 320».

Концептуальное объектное множество. Объектное множество, элементами которого являются абстрактные понятия.

Физическое объектное множество. Объектное множество, элементами кото­рого являются физические предметы.

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

3.2. Библиотечная проблема

Студент звонит в библиотеку и спрашивает:

СТУДЕНТ: У вас есть «Записки Пиквикского клуба» Диккенса? БИБЛИОТЕКАРЬ (вводит запрос в компьютерный каталог): Нет.

С: А «Холодный дом»?

Б (вводит второй запрос): Нет.

С: А сколько всего у вас книг Диккенса?

Б (вводит третий запрос): Двенадцать.

С: Действительно? А какие?

Б: У нас есть «Повесть о двух городах», копия 1, «Повесть о двух городах», копия 2, «Повесть о двух городах», копия 3, и так далее до копии номер 12.

С: Но это же одна и та же книга! У вас не двенадцать книг Диккенса, а только одна.

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

С: Да, но на самом деле это одна и та же книга. Независимо от того, как она издана, это все равно «Повесть о двух городах». На самом деле у вас только одна книга Диккенса.

Этот диалог, взятый из работы Кента (Kent, 1978), никогда не мог со­стояться, поскольку ни один библиотекарь не станет так отвечать. Однако он служит нам для того чтобы указать на серьезную проблему естественного языка, которым люди пользуются при обычном общении. Что в этом при­мере подразумевается под книгой? Без долгих раздумий и вне контекста на­шего диалога мы могли бы сказать, что «книга - это книга», и в таком ис­пользовании слова не было бы двусмысленности. Однако студент и библио­текарь подразумевают под книгой разные вещи.

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

Библиотекарь же употребляет слово «книга» (по крайней мере, сначала) в другом смысле: книга - это нечто физическое, что мы можем подержать в руках, пролис­тать и положить на полку. Библиотеке необходимо вести учет всех физиче­ских книг, которые в ней есть, независимо от того, первая это копия данной концептуальной книги или двенадцатая.

Иногда мы будем различать эти два смысла, называя физические книги копиями или томами. Таким образом, мы можем спросить: «Сколько томов содержит библиотека?» Но как аналитики, опрашивающие пользователей, мы должны понимать, что люди часто не соблюдают такие соглашения. Они просто говорят «книга», иногда имея в виду «концептуальную книгу», а иногда — «физическую книгу». При проектировании базы данных мы должны иметь возможность различать эти значения. В некоторых случаях пользователи будут ссылаться на концептуальный объект, который явля­ется абстрактной или обобщенной версией объекта. В других случаях поль­зователи будут ссылаться на физический объект, или конкретный элемент концептуального объекта. Если мы хотим, чтобы наша база данных удовлетворяла потребностям всех пользователей, то мы должны зафиксировать раз­личие между концептуальными и физическими объектами.

Нам также может потребоваться зафиксировать и другие тонкие разли­чия. В споре между студентом и библиотекарем библиотекарь в конце кон­цов признал, что между физической и концептуальной книгой есть разница, однако он считает, что книги концептуально различны, если они вышли в разных изданиях. Так, для него «Повесть о двух городах» издательства Signet Classic и ее сокращенное издание — разные концептуальные книги. При этом студент настаивает на том, что издание не имеет значения и в концептуальном плане книга остается той же самой независимо от издания.

Разумеется, обе точки зрения обоснованы. Поскольку мы создаем базу данных, нам не нужно выяснять, кто из спорщиков «прав». Нам лишь нужно решить, на какие вопросы пользователи будут требовать ответов от системы. После того как мы выяснили, какая информация нужна, мы мо­жем решать, как моделировать данные. В идеальном варианте мы хотели бы удовлетворить сторонников всех точек зрения, включая и студента, и биб­лиотекаря.

3.3 Проектирование модели данных для библиотеки

На этапе определения требований ЖЦБД мы как аналитики должны оп­рашивать пользователей, чтобы выяснить их требования к базе данных. На этом этапе очень важно правильно определить объекты и отношения, яв­ляющиеся естественной частью ежедневной деятельности пользователей. Так, если между значениями различных терминов естественным образом возникают тонкие различия, мы должны суметь определить их, чтобы точно смоделировать отношения.

Создавая модель данных для библиотеки, остановимся не следующих примерных вопросах: Сколько в библиотеке книг Чарлза Диккенса? Сколько в библиотеке разных книг издательства 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. Примеры интеграции данных
Объединение представлений данных в базу данных большой организации - это сложная проблема, требующая анализа объектных множеств, атрибутов и отношений представлений данных аналитиками и пользователями, которые лучше всего знакомы с этими представлениями данных.

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

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

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

5. ЗАДАНИЕ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ

В процессе выполнения самостоятельной работы по изучаемой теме необходимо выполнить три задания:

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

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

2. Для нижеприведенных задач создать концептуальные модели данных, состоящие из объектных множеств, отношений, атрибутов и т.д. Эти модели должны давать ответы на вопросы, подобные данным. При необходимости используйте составные объекты и отношения высокого порядка. Укажите мощности.

1. 
   Сколько королей Пруссии носили имя Фредерик? В какие годы они жили и в какие годы правили? Управляли ли они на протяжении своей жизни какими-либо еще странами? Управлялись ли в XVII веке какие-либо европейские страны женщинами? Если да, то, какие?
   
2. 
   Правил ли дед Марии-Антуанетты какой-либо страной? Какой и ко­гда? Кто была ее мать? Были ли случаи, когда правители двух раз­ных стран женились между собой? Сколько детей Генриха VIII стали королями Англии? Кто были их матери?
   

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

1. 
   Авиакомпания хочет получать ответы на подобные вопросы о своих самолетах: «Сколько посадочных мест в Боинге 727? Сколько у него двигателей? Какой средний возраст Боингов 727 нашего авиапарка? Кто главный механик, ответственный за обслуживание самолета но­мер 1388? Какая компания создала этот самолет?»
   

b. Администрация в большом городе должна отслеживать имеющееся у нее компьютерное оборудование. Она также хочет получать ответы на вопросы о моделях компьютеров. Создайте модель данных, отвечающую на следующие вопросы: «Какой максимальный объем памяти возможен у IBM PC? У PC-XT и РС-АТ? Каков максимальный объем памяти у Macintosh II? У кого из наших служащих в кабинете есть IBM PC? У кого стоит компьютер с серийным номером 4538842?»