Файл: Практикум по дисциплине базы данных Лабораторная работа n 2 Построение концептуальной модели базы данных. Моделирование составных и концептуальных объектных множеств.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.05.2024
Просмотров: 30
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
У новой формы есть два преимущества:
1. Поскольку Цена единицы товара является функцией заказанного товара, сумму можно автоматически вычислить, используя Количество и Цену единицы товара. В старой форме эти вычисления производились вручную.
2. Поскольку Количество указывается отдельно, его можно использовать в вычислениях как внутри самой формы, так и при определении общего заказанного количества того или иного товара за определенный промежуток времени. Такие подсчеты могут быть нужны для ответа на подобные вопросы:
Сколько блокнотов мы использовали за последний год?
На рис. 11 представлена модель данных, выведенная из новой формы заказа.
Рис. 11. Модель данных для расширенной формы заказа
Обратите внимание, что мы создали составной объект из отношения между объектами ТОВАР и ЗАКАЗ. КОЛИЧЕСТВО и СУММА являются атрибутами составного объекта, поскольку они зависят и от объекта ТОВАР, и от объекта ЗАКАЗ.
Так, количество — это число единиц товара, включенных в конкретный заказ. СУММА — это вычисляемый атрибут, который относится к паре ТОВАР и ЗАКАЗ, как и КОЛИЧЕСТВО.
Обратите также внимание, что ОПИСАНИЕ, ИНВЕНТАРНЫЙ № и ЦЕНА ЕДИНИЦЫ ТОВАРА является атрибутами только ТОВАР, поскольку они зависят только от ТОВАР, а не ЗАКАЗ. ОПИСАНИЕ в новой модели имеет не такое значение, как в прежней модели, поскольку в прежней модели ОПИСАНИЕ включало количество заданного товара.
На рис. 12 представлен расширенный вариант счета Консультационной Службы Мэнуоринг. Обратите внимание, что счет разделен на Работу консультанта и Другие расходы.
Рис.12 . Расширенный счет Консультационной Службы
В новой версии счета мы показываем Вид деятельности и Часы вместо Описания исходной формы. ОПИСАНИЕ было полем свободного формата, в которое пользователь мог записать любую информацию описательного характера, которую сочтет подходящей.
Вид деятельности и Часы имеют значительно более точные значения. Вид деятельности может содержать только один из нескольких заранее определенных видов деятельности (таких, как системный анализ, программирование или обучение пользователей), которыми могут заниматься консультанты.
Часы, разумеется, имеют числовое значение. При таком подходе к системе значительно проще подсчитать общее количество часов, в течение которых каждый консультант выполнял ту или иную работу для каждого клиента.
Модель данных для такого счета представлена на рис. 13. Мы создали составной объект из отношения между объектами КОНСУЛЬТАНТ и ВИД ДЕЯТЕЛЬНОСТИ, а также из отношения между этим составным объектом и объектом ПРОЕКТ.
Рис. 13. Модель данных для расширенного счета
Атрибуты ЧАСЫ и КОЛИЧЕСТВО относятся к большему составному множеству, поскольку они зависят и от консультанта, и от вида деятельности, и от проекта. Так, атрибут ЧАСЫ говорит нам, как долго данный консультант занимался данным видом деятельности при выполнении данного проекта.
Обратите внимание, что атрибут СТАВКА относится непосредственно к объектному множеству КОНСУЛЬТАНТ, так как его значение зависит только от консультанта. Это означает, что Мэнуоринг платит каждому консультанту фиксированную сумму в час независимо от вида деятельности, которую он в этот раз выполняет. Это отражено на рис. 12, из которого видно, что ставка Родригеса всегда составляет 60 долларов в час.
КОЛИЧЕСТВО обозначает оплату конкретного вида деятельности данного консультанта при работе над проектом. Она вычисляется путем умножения ставки из атрибута СТАВКА данного консультанта на количество часов из атрибута ЧАСЫ соответствующих консультанта, вида деятельности и проекта.
В начале главы мы видели, что Джоан Мэнуоринг заинтересована в системе, связывающей консультантов» их деятельность и клиентов, чтобы мы могли получать информацию об отношениях между ними. На рис. 13 представлена необходимая модель данных. Данные, поддерживаемые этой моделью, позволяют создавать большее количество отчетов, два из которых представлены на рис. 14 и 15.
Отчет о деятельности консультантов на рис. 14 показывает, сколько часов каждый консультант занимался каждым видом деятельности на протяжении последнего года. Например, Четмен 900 часов занимался программированием, 600 часов обучал пользователей и 450 занимался в офисе работой, на оплату которой нельзя выставить счет клиентам.
Рис 14. Первый отчет, используемый Консультационной Службой
Отчет консультант-клиент на рис. 15 показывает, сколько часов каждый консультант работал для каждого клиента.
Рис 15. Второй отчет, используемый Консультационной Службой
Модель данных на рис. 13 можно использовать для создания множества аналогичных отчетов. Например, можно создать отчет, отражающий, каким именно видом деятельности каждый консультант занимался для каждого клиента и в каком проекте. Разумеется, в него также можно включить количество времени, затраченного на выполнение каждой работы. Другой отчет может отражать средний процент затрат времени на каждый вид деятельности при выполнении проектов. Например, если результаты отчета покажут, что в среднем системный анализ занял только 5 процентов времени исполнения проекта, то может возникнуть идея проведения дополнительного обучения консультантов системному анализу.
Составные отношения и отношения высокого порядка - мощные средства, часто применяющиеся при моделировании сложных проблем бизнеса. В действительности почти каждая проблема бизнеса достаточно сложна и требует применения подобных методов.
-
МОДЕЛИРОВАНИЕ КОНЦЕПТУАЛЬНЫХ И ФИЗИЧЕСКИХ ОБЪЕКТОВ
3.1. Основные понятия
Хотя составные объекты и отношения высокого порядка являются очень полезными средствами решения широкого круга проблем моделирования данных, есть некоторые проблемы, достаточно сложные аспекты, которых вполне можно решить базовыми методами.
В этом пункте мы рассмотрим проблемы, которые возникают из-за двусмысленности нашего повседневного языка. Вы увидите, что как только мы поймем и разделим понятия, вовлеченные в такие двусмысленности, мы сможем решить проблемы моделирования данных, просто определив подходящие объектные множества. В этом случае мы сможем использовать составные объекты и другие методы для внесения дополнительных конструкций в модели данных.
В предыдущем пункте мы упомянули несколько примеров концептуальных объектных множеств. Например, ТИП МАТЕРИАЛА и ТИП БРИГАДЫ строительной компании Премьер были примерами концептуальных объектных множеств, поскольку их элементы соответствовали типам предметов, а не конкретным физическим представителям этих типов. Типом материала будет словосочетание «доска 2х4х10 дюймов», а не конкретная такая доска. Типом бригады будет слово «кровельщики» или «электрики», тогда как конкретная бригада будет «кровельщики здания на Мэйн стрит, 320».
Концептуальное объектное множество. Объектное множество, элементами которого являются абстрактные понятия.
Физическое объектное множество. Объектное множество, элементами которого являются физические предметы.
Часто важно различать концептуальные объектные множества и физические объектные множества, которые им соответствуют, поскольку в одной и той же модели данных может оказаться необходимым представлять оба типа объектов. Мы проиллюстрируем это следующим примером.
3.2. Библиотечная проблема
Студент звонит в библиотеку и спрашивает:
СТУДЕНТ: У вас есть «Записки Пиквикского клуба» Диккенса? БИБЛИОТЕКАРЬ (вводит запрос в компьютерный каталог): Нет.
С: А «Холодный дом»?
Б (вводит второй запрос): Нет.
С: А сколько всего у вас книг Диккенса?
Б (вводит третий запрос): Двенадцать.
С: Действительно? А какие?
Б: У нас есть «Повесть о двух городах», копия 1, «Повесть о двух городах», копия 2, «Повесть о двух городах», копия 3, и так далее до копии номер 12.
С: Но это же одна и та же книга! У вас не двенадцать книг Диккенса, а только одна.
Б: Нет, не одна и та же. Одна из них - издательства Signet Classic, другая - перевод на немецкий, третья - на французский, четвертая - сокращенный вариант и так далее.
С: Да, но на самом деле это одна и та же книга. Независимо от того, как она издана, это все равно «Повесть о двух городах». На самом деле у вас только одна книга Диккенса.
Этот диалог, взятый из работы Кента (Kent, 1978), никогда не мог состояться, поскольку ни один библиотекарь не станет так отвечать. Однако он служит нам для того чтобы указать на серьезную проблему естественного языка, которым люди пользуются при обычном общении. Что в этом примере подразумевается под книгой? Без долгих раздумий и вне контекста нашего диалога мы могли бы сказать, что «книга - это книга», и в таком использовании слова не было бы двусмысленности. Однако студент и библиотекарь подразумевают под книгой разные вещи.
Один смысл слова «книга» (в котором его употребляет студент) - нечто концептуальное, имеющее множество разных физических версий. Таким образом, для студента «Повесть о двух городах» - это в самом деле одна и та же книга, независимо от инвентарного номера, независимо от того, на английском она или на французском языке, полное это издание или сокращенное.
Библиотекарь же употребляет слово «книга» (по крайней мере, сначала) в другом смысле: книга - это нечто физическое, что мы можем подержать в руках, пролистать и положить на полку. Библиотеке необходимо вести учет всех
физических книг, которые в ней есть, независимо от того, первая это копия данной концептуальной книги или двенадцатая.
Иногда мы будем различать эти два смысла, называя физические книги копиями или томами. Таким образом, мы можем спросить: «Сколько томов содержит библиотека?» Но как аналитики, опрашивающие пользователей, мы должны понимать, что люди часто не соблюдают такие соглашения. Они просто говорят «книга», иногда имея в виду «концептуальную книгу», а иногда — «физическую книгу». При проектировании базы данных мы должны иметь возможность различать эти значения. В некоторых случаях пользователи будут ссылаться на концептуальный объект, который является абстрактной или обобщенной версией объекта. В других случаях пользователи будут ссылаться на физический объект, или конкретный элемент концептуального объекта. Если мы хотим, чтобы наша база данных удовлетворяла потребностям всех пользователей, то мы должны зафиксировать различие между концептуальными и физическими объектами.
Нам также может потребоваться зафиксировать и другие тонкие различия. В споре между студентом и библиотекарем библиотекарь в конце концов признал, что между физической и концептуальной книгой есть разница, однако он считает, что книги концептуально различны, если они вышли в разных изданиях. Так, для него «Повесть о двух городах» издательства Signet Classic и ее сокращенное издание — разные концептуальные книги. При этом студент настаивает на том, что издание не имеет значения и в концептуальном плане книга остается той же самой независимо от издания.
Разумеется, обе точки зрения обоснованы. Поскольку мы создаем базу данных, нам не нужно выяснять, кто из спорщиков «прав». Нам лишь нужно решить, на какие вопросы пользователи будут требовать ответов от системы. После того как мы выяснили, какая информация нужна, мы можем решать, как моделировать данные. В идеальном варианте мы хотели бы удовлетворить сторонников всех точек зрения, включая и студента, и библиотекаря.
3.3 Проектирование модели данных для библиотеки
На этапе определения требований ЖЦБД мы как аналитики должны опрашивать пользователей, чтобы выяснить их требования к базе данных. На этом этапе очень важно правильно определить объекты и отношения, являющиеся естественной частью ежедневной деятельности пользователей. Так, если между значениями различных терминов естественным образом возникают тонкие различия, мы должны суметь определить их, чтобы точно смоделировать отношения.