3. п*т (многие-ко-многим). Например, в таком отношении друг к др находятся сущности "Поставщик" и "Товар":

Поставщик(номер поставщика, название, ИНН, адрес, ...) Товар(номер товара, название, сорт, ...)

Поайс(номер поставщика. номер товара, количество, цена, ...)

Следует отметить, что для реализации отношения данного типа необходима дополнительная ассоциативная сущность (таблица "Прайс").

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

4.4. Категоризация сущностей

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

В качестве примера общей сущности можно привести сущность "Контрагент", которую необходимо расщепить на сущности-категории "Юридическое лицо" и "Физическое лицо":

Контрагент(номер контрагента. тип, название, фактический адрес, ...) Юридическое лииоЫомер контрагента. ИНН, юридический адрес, ...) Физическое лииоЫомер контрагента. ФИО, паспорт, адрес прописки, ...)

Следует отметить, что, во-первых, в таблицах "Юридическое лицо" и "Физическое лицо" в качестве первичного ключа используется первичный ключ из таблицы "Контрагент", в таких случаях говорят, что первичный ключ из таблицы "Контрагент" мигрировал в таблицы "Юридическое лицо" и "Физическое лицо". Во-вторых, в таблицу "Контрагент" специально добавлено поле "Тип", по значению которого сразу можно определить в какой из таблиц-категорий искать дополнительные данные о данном контрагенте. Если такого поля не будет, то для

4.6. Условные обозначения, применяемые при проектировании РБД

Условные обозначения приведены в транскрипции ER (Entity Relation - связи сущностей). На практике могут использоваться и другие обозначения.

Следует отметить, что набор допустимых типов данных зависит от используемой СУБД.

1. Ключи:

рк - первичный ключ; fk - внешний ключ;

ак - альтернативный ключ.

2.Типы полей и их размер:

Здесь ПУ - символ правила удаления: R - ограниченное (англ, "restricted"); С - каскадное (англ, "cascade"). Необходимо отметить, что стрелки, обозначающие связи между таблицами, следует направлять от таблицы с внешним ключом к таблице с первичным ключом.

4.7. Примеры проектов РБД

Проект РБД "Поставки" приведен на рис. 7. Проект РБД "Клиенты" приведен на рис. 8.

Рис. 7. Проект реляционной базы данных "Поставки"

Рис. 8. Проект реляционной базы данных "Клиенты"

Упражнения

1.В п. 2.3 сформулированы два правила удаления. Как вы думаете, существуют ли еще правила удаления, не нарушающие целостность РБД?

2.В п. 4.4. приведен пример категоризации сущности "Контрагент":

Контрагент(номер контрагента, тип, название, фактический адрес, ...) Юридическое лииоЫомер контрагента, ИНН, юридический адрес, ...) Физическое лиио(номео контрагента. ФИО, паспорт, адрес прописки, ...)

Как вы думаете, можно ли в качестве названия контрагента использовать фамилию и инициалы физического лица? Будет ли это нарушением принципа нормализации? Ускорит ли это выборку информации о контрагентах из базы данных?

Отношение многие-ко-многим между деталями и цветами представлено таблицей "Цвет детали" Для таблиц "Цвет" и "Цвет детали", а также "Деталь" и "Цвет детали" используются ограниченные правила удаления. Как вы думаете, какие проблемы могут возникнуть у пользователя при работе с таким справочником, если правила удалений оставить без изменений? Как, на ваш взгляд, стоило бы изменить правила удаления?

7. Известно, что структура какого-либо предприятия может быть представлена в виде дерева с заранее неизвестным количеством уровней вложенности: завод состоит из цехов и служб, цеха в свою очередь состоят из участков, а службы - из отделов, участки и отделы разбиваются на еще более мелкие структурные подразделения и т.д. Создайте проект РБД, которая позволит хранить подобную структуру.

8. Используя условные обозначения из п. 4.6., создайте проекты РБД по следующим темам:

1)детский сад;

2)расписание учебных занятий;

3)библиотека;

4)продовольственный магазин;

5)справочник автомобильных дорог;

6)отдел кадров;

7)технологический процесс;

8)бухгалтерия;

9)сберегательный банк;

10)ценные бумаги;

11)железнодорожная касса;

12)расписание авиарейсов;

13)бюджет предприятия;

14)склад товаров;

15)истории болезней пациентов;

16)атлас государств и городов мира;

17)телевизионная программа;

18)план проведения олимпийских игр;

19)устройство персонального компьютера; 20) косметический салон.

Проект должен содержать не менее 5 таблиц. В каждой таблице должны

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