русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

Лекция Разработка ER-диаграммы для анализируемой предметной области


Дата добавления: 2015-07-09; просмотров: 3202; Нарушение авторских прав


Содержание лекции:методы разработки ER-диаграмм.

 

Цель лекции:разработать ER-диаграммы для анализируемой предметной области.

 

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

Выделим основные объектные множества. Прежде всего, существует объектное множество КНИГИ, каждая книга имеет уникальный шифр, который является ее ключом, и ряд атрибутов, которые взяты из описания предметной области. Множество экземпляров множества определяет множество книг, которые хранятся в библиотеке. Каждый экземпляр множества КНИГИ соответствует не конкретной книге, стоящей на полке, а описанию некоторой книги, которое дается обычно в предметном каталоге библиотеке. Каждая книга может присутствовать в нескольких экземплярах, и это как раз те конкретные книги, которые стоят на полках библиотеки. Для того чтобы отразить это, мы должны ввести объектное множество ЭКЗЕМПЛЯРЫ, которая будет содержать описания всех экземпляров книг, которые хранятся в библиотеке. Каждый экземпляр сущности ЭКЗЕМПЛЯРЫ соответствует конкретной книге на полке. Каждый экземпляр имеет уникальный инвентарный номер, однозначно определяющий конкретную книгу. Кроме того, каждый экземпляр книги может находиться либо в библиотеке, либо на руках у некоторого читателя, и в последнем случае для данного экземпляра указываются дополнительно дата взятия книги читателем и дата предполагаемого возврата книги. Напомним, что связи бывают обязательныеифакультативные. Если объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами объектов существует обязательная связь. Иначе связь является факультативной.



Между сущностями КНИГИ и ЭКЗЕМПЛЯРЫ существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь «один-ко-многим». При этом если в библиотеке нет ни одного экземпляра данной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности КНИГИ, то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности ЭКЗЕМПЛЯРЫ, то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны ЭКЗЕМПЛЯРЫ связь тоже обязательная.

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

Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями ЧИТАТЕЛИ и ЭКЗЕМПЛЯРЫ. А почему не между сущностями ЧИТАТЕЛИ и КНИГИ? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями ЭКЗЕМПЛЯРЫ и КНИГИ, и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями ЧИТАТЕЛИ и ЭКЗЕМПЛЯРЫ установлена связь «один-ко-многим», и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

Теперь надо отразить последний объект, который связан с системным каталогом. Системный каталог содержит перечень всех областей знаний, сведения по которым содержатся в библиотечных книгах. Обычно с системного каталога в библиотеке начинается поиск нужных книг, если неизвтны ихесаем их авторы и названия. Название области знаний может быть длинным и состоять из нескольких слов, поэтому для моделирования системного каталога мы введем объектное множество СИСТЕМНЫЙ_КАТАЛОГ с двумя атрибутами: «Код области знаний» и «Название области знаний». Атрибут «Код области знаний» будет ключевым атрибутом сущности.

Из описания предметной области нам известно, что каждая книга может содержать сведения из нескольких областей знаний, а также в библиотеке может присутствовать множество книг, относящихся к одной и той же области знаний, поэтому нам необходимо установить между СИСТЕМНЫЙ_КАТАЛОГ и КНИГИ связь «многие-ко-многим», обязательную с двух сторон. Действительно, в системном каталоге не должно присутствовать такой области знаний, сведения по которой не представлены ни в одной книге нашей библиотеки, противное было бы бессмысленно. И обратно, каждая книга должна быть отнесена к одной или нескольким областям знаний для того, чтобы читатель мог ее быстрее найти. Это отношение формирует составное объектное множество, для удобства таким отношениям иногда дают объектные имена – существительные (дополнительно к имени отношения). Назовем это множество СВЕДЕНИЯ. Графически составное множество обозначается прямоугольником, нарисованным вокруг отношения и участвующих в нем объектных множеств (рисунок 7.1).

Рисунок 7.1 - Концептуальная модель предметной области «Библиотека»

Спроектируем концептуальную модель системы, предназначенной для хранения информации издательской компании (предметная область описана в лекции 4). Разработку модели начнем с выделения основных сущностей.

Прежде всего, существует объектное множество КНИГИ, каждая книга имеет ряд атрибутов, которые взяты из описания предметной области. Для представления в разрабатываемой системе авторов вводим для этого объектное множество АВТОРЫ, каждый экземпляр которой будет соответствовать конкретному автору (атрибуты тоже приведены в описании предметной области). Надо отметить, что здесь идет речь об уже написанных, готовых к изданию книгах. Каждая книга имеет вполне определенный список авторов (или автора). Можно принять, что между объектами КНИГИ и АВТОРЫ будет связь «один-ко-многим»: у каждой книги определенный список авторов, каждая группа авторов (каждый автор) может написать не одну книгу. Но, в общем случае эта связь мощности «много-ко-многим». В этом случае это отношение может составлять составное объектное множество КНИГИ_ ГОТОВЫЕ_ К_ ИЗДАНИЮ. У этого множества могут быть свои атрибуты, например, такие: тираж, цена, дата выхода.

В работе по изданию определенной книги участвуют сотрудники компании, которые представляются объектным множеством СОТРУДНИКИ с соответствующими атрибутами. Сотрудниками могут быть редакторы книг или менеджеры, оформляющие контракты на издание книги. Функции у этих групп сотрудников разные. Поэтому, введем конкретизацию множества СОТРУДНИКИ - МЕНЕДЖЕРЫ и РЕДАКТОРЫ. Каждую книгу редактирует определенная группа редакторов (несколько редакторов), и эта группа может работать с несколькими книгами: отношение множеств «много-ко-многим». Это отношение можно назвать РЕДАКТИРОВАНИЕ - новое объектное множество например, с такими атрибутами: дата начала, дата окончания. Каждая группа авторов (или отдельный автор) могут подписывать контракты на издание нескольких книг. Менеджеры тоже работают со множеством авторов. Поэтому отношение между множествами АВТОРЫ и МЕНЕДЖЕРЫ будет иметь мощность «много-ко-многим», это отношение составляет новое объектное множество КОНТРАКТЫ (атрибуты контракта – номер, дата подписания, авторский гонорар).

Основной деятельностью компании является выполнение заказов на издание тех или иных книг: в объекте «Заказчики» хранится информация о заказчиках (название заказчика, адрес заказчика, телефоны). Заказчики могут заказать не одну книгу, и каждая книга может быть куплена многими заказчиками: отношение между ЗАКАЗЧИКИ и КНИГИ – «много-ко-многим», оно определяет объектное множество ЗАКАЗЫ (атрибуты - дата поступления заказа, дата его выполнения, стоимость заказа). Вариант ER–диаграммы модели издательской компании приведен на рисунке. 7.1. Чтобы не загромождать диаграмму, составные объектные множества и атрибуты не приведены.

Рисунок 7.2 - ER–диаграмма модели издательской компании

 

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

Лекция. Примеры концептуального моделирования

Содержание лекции:примеры концептуального проектирования баз данных.

Цель лекции:изучить на примерах методы разработки концептуальных схем баз данных.

 

Как уже отмечалось, отношения можно рассматривать как объекты, в этом случае они называются составными объектными множествами. Большинство проблем бизнеса требуют использования составных объектов. Ранее в примерах во всех отношениях участвовали два объектных множества (бинарные отношения). Однако отношение может связывать три и более объектных множеств (n-арные отношения). Проиллюстрируем это понятие примером.

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

Создадим концептуальную модель данных компании. У компании есть клиенты, торговые агенты, товары, производители этих товаров. Выделим следующие объекты: ТОВАР, КЛИЕНТ, ТОРГОВЫЙ_АГЕНТ, ПРОИЗВОДИТЕЛЬ. Установим подходящие отношения между ними, как показано на рисунке 8.1:

Предположим, что нужно отслеживать количество каждого товара, проданного каждому клиенту. Мы должны приписать атрибут КОЛИЧЕСТВО одному из объектов. Если это будет атрибут объекта ТОВАР, то мы не сможем различать количество товара, проданного различным клиентам, если же атрибут присвоить объекту КЛИЕНТ, то не сможем различать товары, проданные клиенту. Поэтому, КОЛИЧЕСТВО – атрибут отношения между товаром и клиентом, а не товара или клиента в отдельности. Итак, отношение «продан_кому» само является объектным множеством или составным объектом, которому и приписывается атрибут КОЛИЧЕСТВО (рисунок 8.2).

 
 

 

 


Рисунок 8.2 - Правильная модель отображения количества продаж

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

     
   
*

 

 
*

 

 
     

 


Рисунок 8.3 - Полная модель отслеживания продаж

Для иллюстрации еще одного понятия в концептуальном моделировании, рассмотрим следующий пример. Строительная компания возводит различные здания. Для всех зданий требуются разнообразные материалы в различных количествах. На разных этапах проекта работают разные бригады (арматурщиков, каменщиков, штукатуров и т.д.). При составлении графика работы фирма варьирует состав бригад. Рабочие назначаются в различные бригады в соответствии с квалификацией. Бригады составляются таким образом, как требуется для конкретного здания. Для каждой бригады назначается бригадир. Рабочий может возглавлять одну бригаду и работать в другой простым рабочим. Создадим концептуальную модель данных, которая может обеспечить нужной информацией владельца компании. На рисунке 8.4 представлено отношение между зданиями и материалами.

 

 

 

 

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

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

Теперь покажем формирование бригад и назначение рабочих и бригадиров. Еще один пример концептуального объектного множества – ТИП_БРИГАДЫ – это не конкретные бригады, а типы бригад (бригада арматурщиков, каменщиков и т.д.). Отношение между зданием и типом бригады представляет конкретную бригаду, назначенную выполнять на данном здании данный тип работ. Это отношение будем рассматривать как объект, назовем его БРИГАДА.

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

Далее представлено распределение рабочих и бригадиров по бригадам. Отношение «является_бригадиром» имеет мощность «один-ко-многим» т.к. у бригады один бригадир, но один человек может возглавлять несколько бригад.

 

 

Рисунок 8.5 – Модель формирования бригад и бригадиров

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

 

 

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

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



<== предыдущая лекция | следующая лекция ==>
Графическое представление концептуальной модели | Три базовые модели данных


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 1.403 сек.