Основы проектирования реляционных баз данных. Учебное пособие


Классификация сущностей - часть 3


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

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

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

1. Лобио по грузински

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

Фасоль стручковая (свежая или консервированная) 200,

Лук зеленый 40, Масло сливочное 30, Зелень 10.

Выход 210. Калорий 725.

Рис. 2.3. Пример кулинарного рецепта

С помощью указанных пользователей выделены следующие объекты и характеристики проектируемой базы:

  1. Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: номер блюда (например, из книги кулинарных рецептов), название блюда, вид блюда (закуска, суп, горячее и т.п.), рецепт (технология приготовления блюда), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо.
  2. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.
  3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.

Анализ объектов позволяет выделить:

  • стержни Блюда, Продукты и Города;
  • ассоциации Состав (связывает Блюда с Продуктами) и

Поставки (связывает Поставщиков с Продуктами);

  • обозначение Поставщики;
  • характеристики Рецепты и Расход.

ER-диаграмма модели показана на рис. 2.4. а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид) Продукты (ПР, Продукт, Калорийность) Поставщики (ПОС, Город, Поставщик) [Город] Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г)) Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг)) Города (Город, Страна) Рецепты (БЛ, Рецепт) {Блюда} Расход (БЛ, Дата_Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Рис. 2.4. Инфологическая модель базы данных "Питание"

[] [] []




Начало  Назад  Вперед