Access2003Лекция2ERметодЧ1 (1109540), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

Правила генерации таблиц по ER-диаграмме

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

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

П усть в нашем примере между сущностями ЗАКАЗ и ТОВАР выявлена такая связь:

Тогда в базе данных будет только одна таблица, отображающая свойства этих сущностей:

Продажи

Номер заказа	Дата заказа	Клиент	Менеджер	Название	Цена	Дата доставки	Фактически доставлено
1	15.03.02	Орлов А.С.	Иванов И. И.	«Конфеты»	185	18.03.02	18.03.02
2	10.09.03	Станов О.Т.	Сидоров В. П.	«Торт Сказка»	162	15.09.03	17.09.03
…	…	…	…	…	…	…	…

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

П усть в нашем примере между сущностями ЗАКАЗ и ТОВАР выявлена такая связь:

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

Заказ

Товар

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

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

Замечание: в этом случае определяющим фактором является класс принадлежности n-связной сущности; класс принадлежности 1-связной сущности на конечный результат не влияет.

Правило 1: Если класс принадлежности n-связной сущности является обязательным, то достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того. Ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Правило 2: Если класс принадлежности n-связной сущности не является обязательным, то необходимо формирование трех таблиц – по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному ключу от каждой сущности.

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

Правило 1: В этом случае вне зависимости от класса принадлежности каждой сущности потребуется три таблицы: по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному ключу от каждой сущности.

ER-диаграмма базы данных офиса продаж.

К лиент – Заказ

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

М енеджер – Заказ

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

З аказ – Товар

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

М ы видим, что в этом случае связь «многие-ко-многим». Следовательно, требуется промежуточный объект для реализации такой связи. Назовем его Состав заказа.

Т овар – Единица измерения

10

Характеристики

Список файлов лекций