Пример 2.2

(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов);

2. Тринарные связи

(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

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

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

Полностью язык ER-диаграмм состоит из следующих элементов:

Элементы языка ER-диаграмм

2.3.2. Язык инфологического моделирования (ЯИМ) "Сущность-связь". Классификация сущностей.

Настал момент разобраться в терминологии. К.Дейт [3?] определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

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

В рассмотренных ранее примерах стержни – это "Студент", "Группа", "Мужчины", "Врач", "Брак" (из примера 2.3) и другие, названия которых помещены в прямоугольники.

На ЯИМ стержневые сущности представляются предложениями вида:

СУЩНОСТЬ (атрибут_1, атрибут_2,..., атрибут_n)

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

В рассмотренном выше примере 2.2 сущности ВРАЧ и ПАЦИЕНТ можно описать на ЯИМ следующим образом:

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия,

Имя, Отчество, Адрес, Дата рождения, Пол)

В базе данных ПАНСИОН стержневые сущности:

ВИД_БЛЮД, ОСНОВЫ, ТРАПЕЗЫ, ГОРОДА, ОТДЫХАЮЩИЕ, ПРОДУКТЫ

Пример 2.3. Брак. В странах, где допускаются лишь традиционные браки, отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности:

Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа,

Отчество_мужа, Дата_рождения_мужа, Фамилия_жены,

..., Дата_регистрации, Место_регистрации,...),

Соответствующая ER-диаграмма:

Если связь между сущностями имеет атрибуты, то она называется ассоциацией.

2. Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

На ЯИМ ассоциация обозначается следующим образом:

АССОЦИАЦИЯ [СУЩНОСТЬ N1, СУЩНОСТЬ N2,...]

(атрибут_1, атрибут_2,..., атрибут_n)

Здесь N – степень связи, а атрибуты, входящие в ключ, должны быть выделены с помощью подчеркивания или жирным шрифтом.

Например, взаимоотношения врачей и пациентов из примера 2.2 можно отобразить следующим образом:

Лечащий_врач [Врач 1, Пациент M]

(Номер_врача, Регистрационный_номер)

Консультант [Врач M,Пациент N]

(Номер_врача, Регистрационный_номер).

В базе данных ПАНСИОН ассоциации:

МЕНЮ, ВЫБРАНО, СОСТАВ, ПОСТАВКИ.

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

Сотрудники (Табельный_номер, Фамилия, Имя,...).

Использование, рассмотренной в примере 2.3, сущности "Брак" нецелесообразно: в "Сотрудники" уже есть фамилии, имена, отчества супругов. Поэтому создадим ассоциацию

Брак [Сотрудник 1, Сотрудник 1]

(Табельный_номер_мужа, Табельный_номер_жены,

Номер_свидетельства,...),

связывающую между собой определенные экземпляры сущности "Сотрудники". ER – диаграмма:

Ассоциации рассматриваются как полноправные сущности:

1) они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

2) могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации "Брак" из примера 2.4 содержат ключевые атрибуты "Табельный номер мужа", "Табельный номер жены", а также уточняющие атрибуты "Номер свидетельства", "Дата регистрации", "Место_регистрации", "Номер записи в книгу ЗАГС" и т.д.

3. Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности.

Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2,...)

{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.

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

В базе данных ПАНСИОН характеристики:

РЕЦЕПТЫ, НАЛИЧИЕ.

Пример 2.5. БРАК. Теперь рассмотрим ситуацию, когда отдел ЗАГС расположен в стране, допускающей многоженство. Если для регистрации браков использовать сущность "Брак" примера 2.3, то будут дублироваться сведения о мужьях, имеющих несколько жен (см. табл. 2.1).

Таблица 2.1

Номер свидетельства	Фамилия мужа	...	Фамилия жены	...
	Петухов	...	Курочкина	...
	Петухов	...	Пеструшкина	...
…	…	...	…	...
	Иванов	...	Свинюшкина	...
	Иванов	...	Хавронина	...
...	...	...	...	...

Дублирование можно исключить созданием дополнительной сущности "Мужья"

Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения)

и заменой сущности "Брак" характеристикой со ссылкой на соответствующее описание в сущности "Мужья".

Брак (Номер свидетельства, Код_М, Фамилия жены,...,

Дата регистрации,...){Мужья}.

ER-диаграмма связи этих сущностей:

пример их экземпляров:

Таблица 2.2

Код_М	Фамилия	…
	Петухов	…
…	…	…
	Иванов	…
...	...	...

Таблица 2.3

Номер свидетельства	Код_М	Фамилия жены	…
		Курочкина	…
		Пеструшкина	…
…	…	…	…
		Свинюшкина	…
		Хаврония	…
...	...	...	...

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

Характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж, рецепт ….

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

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

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

Например Картотека фильмов, где есть характеристика – содержание фильма. Оно может быть неизвестно составителю картотеки.

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

Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2,...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ]

Здесь атрибуты, входящие в ключ, должны быть выделены с помощью подчеркивания или жирным шрифтом.

Рассмотрим пример, связанный с зачислением сотрудников в различные отделы организации. Здесь возможны 2 варианта:

1. Если сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел, можно создать описание на ЯИМ с ассоциацией Зачисление:

Отделы (Номер отдела, Название отдела,...)

Служащие (Табельный номер, Фамилия,...)

Зачисление [Отделы M, Служащие N]

(Номер отдела, Табельный номер, Дата зачисления).

2. Если каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением Служащие:

Отделы (Номер отдела, Название отдела,...)

Служащие (Табельный номер, Фамилия,..., Номер отдела, Дата зачисления)[Отделы]

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

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

Например, в базе данных ПАНСИОН обозначающими сущностями будут:

БЛЮДА, ПОСТАВЩИКИ.

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

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

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

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

2.3.2. Язык инфологического моделирования "Таблица-связь".

Для наиболее распространенных реляционных баз данных можно предложить язык инфологического моделирования "Таблица-связь", пример использования которого приведен на рис. ниже.

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

2.4. Пример построения инфологической модели базы данных "Питание"

1) Анализ предметной области

В БД должна храниться информация о блюдах, рецептах, их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов. Информация будет использоваться поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.

1. Лобио по грузински Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, рейган (базилик) и довести до готовности. Затем запечь в духовке. Фасоль стручковая (свежая или консервированная) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725.

Пример кулинарного рецепта

2) Инфологическая модель данных:

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

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

2. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.

3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.

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

· стержни Блюда, Продукты и Города;

· ассоциации Состав (связывает Блюда с Продуктами) и Поставки (связывает Поставщиков с Продуктами);

· обозначение Блюда и Поставщики;

· характеристики Рецепты и Расход.

3) ER-диаграмма модели:

Инфологическая модель базы данных "Питание", построенная с помощью языка ER-диаграмм

4) Модель на языке ЯИМ:

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

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

5) Инфологическая модель базы данных "Питание", построенная с помощью языка "Таблицы-связи":

2. Операции агрегации, обобщения, ассоциации над единицами информации, их отображение в E-R – моделях.

Базовые отношения, изображаемые на диаграммах классов:

· Отношение ассоциации (association relationship)

· Отношение обобщения (generalization relationship)

· Отношение агрегации (aggregation relationship)

· Отношение композиции (composition relationship)

Определение отношений между классами: ассоциация, обобщение, агрегация, композиция, направление ассоциации, абстрактные классы и методы, параметризованные классы, связывание классов, обозначение связывания.

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

Обобщением называют такое отношение между классами, при котором любой объект одного класса обязательно является также и объектом другого класса, называемого в данном контексте супертипом. Так, если некоторый конкретный студент является объектом подтипа Студент первого курса супертипа Студент, то тот же самый студент является объектом указанного супертипа. Следовательно, все, что известно об объектах супертипа (ассоциации, атрибуты, операции), касается и объектов подтипа. На диаграмме классов обобщение обозначают линией с треугольной стрелкой на конце, подходящей к супертипу.