Контрольные вопросы 5.3

1. Какие правила для преобразования слабых сущностей вы знаете? Преобразуйте рис. 5.5и приведите пример данных.

2. При преобразовании слабых сущностей, что становится их новым первичным ключом?

3. Как следует преобразовывать многозначные атрибуты в слабой сущности? Обсудите.

Итоги главы

В этой главе рассматривалось понятие "слабой сущности". Были дополнены грамматика для описания слабой сущности и методологияER-проектирования. Так же были разработаны правила для преобразования слабых сущностей в реляционную базу данных. Такое понятие слабой сущности определено вChen-модели, но оно может трактоваться по-другому в других моделях построенияER-диаграмм.

Упражнения Главы 5. Упражнение 5.1

Изобразите ER-диаграмму (используя Chen-модель) для базы данных, которая должна содержать следующую информацию: имя служащего, номер служащего, адрес служащего, профессиональное качества. Служащий может иметь более, чем одну профессию. Затем включите в диаграмму: уровень профессионального качества, дата проверки профессионального качества (если проверено), и дата начала использования профессионального качества. Укажите слабые сущности в этой базе данных. Преобразуйте ER-диаграмму в реляционную базу данных.

Упражнение 5.2

Создайте ER-диаграмму (используя Chen-модель) для видов спорта и игроки. Атрибуты ВИДА СПОРТА: название, тип, командный или некомандный. Атрибуты ИГРОКОВ: имя, личный номер, дата рождения. Игроки могут принимать участие в нескольких видах спорта. Какая сущность (сущности) по вашему являются слабыми? Нарисуйте ER-диаграмму и преобразуйте ее в реляционную базу данных.

Упражнение 5.3

Каким образом обычно идентифицируются слабые сущности?

Упражнение 5.4

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

Список литературы

Chen, P.P. "The Entity Relationship Model — Toward a Unified View of Data," ACM TODS 1, No. 1, March 1976.

Connolly, T., Begg, C., and Strachan, A. Database Systems, A Practical Approach to Design, Implementation, and Management, Addison-Wesley, Harlow, England, 1998.

Elmasri, R. and Navathe, S.B. Fundamentals of Database Systems, 3^rd ed., Addison-Wesley, Reading, MA, 2000.

Ramakrishnan, R. and Gehrke, J. Database Management Systems, 3^rd ed., McGraw-Hill, New York, 2003.

Учебный пример: Западно-Флоридский торговый

комплекс (продолжение)

В предыдущих главах, в которых мы выбрали первичные сущности, определили их атрибуты и установили связи для этого учебного примера, а затем преобразовали их в реляционную базу данных (с некоторыми примерами данных). В главе 4 мы также наложили структурные ограничения на связи подкорректировали некоторые преобразования. Затем мы рассмотрели шаг 7, который гласит:

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

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

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

В Главе 3мы определили, что отдел является многозначным атрибутом сущности МАГАЗИН (то есть, один магазин имел много отделов). Но после рассмотрения дополнительных спецификаций (выше), можно увидеть, что ОТДЕЛ должен быть сущностью, поскольку требуется хранить информацию об ОТДЕЛЕ. Также выясняется, что необходимо хранить информацию еще об одной сущности – СЛУЖАЩИЙ. Таким образом, вышеуказанная спецификация добавляет две новых сущности: ОТДЕЛ и СЛУЖАЩИЙ.

Сначала выберем сущность ОТДЕЛ и повторим Шаг 2: