Access2003Лекция2ERметодЧ1 (Электронные лекции)

Лекция 2.

Рассмотрим основные понятия теории проектирования баз данных на примере построения базы данных офиса продаж какого-либо товара.

Прежде всего, опишем существующее положение дел, то есть произведем описание предметной области.

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

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

Одним из инструментов, получившим широкое распространение, представления данных, независимого от реализующего его программного обеспечения, является модель «сущность – связь» (entitle – relationship model, ER – model), которая используется для анализа предметной области.

Модель «сущность – связь» основывается на некой информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными, используемыми в системе. Модель «сущность – связь» представляется в графическом виде и называется диаграммой «сущность – связь». На ней представлены все выявленные сущности предметной области и указаны взаимосвязи между ними. Она показывает, как вероятнее всего будет выглядеть база данных, какие данные в ней храниться, что будет делать система, но не говорит как. Диаграмма «сущность – связь» должна быть независима от применяемой технологии и может быть реализована при помощи любой СУБД.

Метод «сущность – связь» (ER – метод).

Дадим определения понятиям, использующимися в этом методе.

Сущность – есть отдельный объект предметной области (человек, место, вещь, понятие, событие), которое нужно представить в базе данных.

Этот объект должен иметь экземпляры - конкретные представители данной сущности, отличающиеся друг от друга и допускающие однозначную идентификацию. Сущность – как правило, существительное; связь чаще выражается глаголом.

Связь – это некоторая ассоциация между двумя сущностями.

Атрибут – это свойство сущности.

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

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

Для примера возьмем две сущности из нашей задачи, пусть это будут Заказ и Товар.

В нашем примере в качестве ключевого атрибута сущности ЗАКАЗ было решено взять номер, а в качестве ключевого атрибута сущности ТОВАР взять её название. Первое решение заведомо не является бесспорным: каждый менеджер может вести собственную нумерацию заказов (тогда атрибут Номер теряет уникальность и не может быть использован в качестве ключа). В принципе, допустимо появление товаров с одинаковыми названиями.

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

Если окажется, что ни один содержательный атрибут не может быть использован как ключевой, то существует (по меньшей мере) два способа решения этой проблемы:

• подобрать набор атрибутов, значения которых будут уникальными для каждого экземпляра сущности;

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

Связь между двумя сущностями может быть представлена графически в виде ER-диаграммы:

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

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

Связь ОДИН-К-ОДНОМУ:

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

Если все экземпляры сущности должны участвовать в связи, то участие называется обязательным, и изображается на ER-диаграмме кружком, помещенным в блок, изображающий сущность (при словесной формулировке такой связи обычно используется глагол «должен»):

В этой диаграмме отражено правило: «каждый заказ должен иметь товар, причем только один, и каждый товар должен принадлежать только одному заказу», т.е. в базе данных не будет информации о товарах, не принадлежащих ни одному заказу, а также информации о заказах, которые не имеют товар.

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

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

Для сущностей ЗАКАЗ - ТОВАР возможны еще два типа связи один-к-одному, отражающих два оставшихся варианта обязательности включения экземпляров:

1

1

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

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

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

Связь ОДИН-КО -МНОГИМ:

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

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

С ледующая диаграмма отражает связь один-ко-многим сущностей ЗАКАЗ – ТОВАР, где экземпляры обеих сущностей вступают в обязательную связь:

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

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

Д ля сущностей ЗАКАЗ - ТОВАР возможны еще два типа связи один-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

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

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

Аналогично анализируются и фиксируются все варианты связи один-ко-многим сущностей ТОВАР - ЗАКАЗ (с учетом обязательности / необязательности участия в связи всех экземпляров этих сущностей).

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

Связь МНОГИЕ-КО -МНОГИМ:

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

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

С ледующая диаграмма отражает связь многие-ко-многим сущностей ЗАКАЗ – ТОВАР, где экземпляры обеих сущностей вступают в обязательную связь:

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

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

Для сущностей ЗАКАЗ – ТОВАР возможны еще два типа связи многие-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

« Каждый товар может содержаться в нескольких заказах; каждый заказ может содержать несколько товаров (но должен содержать хотя бы один)», т.е. в базе данных не будет информации о заказах, которые не содержат ни одного товара, но допускается хранить информацию о товарах, которые еще никто не заказывал.