Семантическое моделирование данных

Для моделирования предметных областей широкое распространение получили реляционные СУБД. Их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточно универсальна. Однако проектирование реляционной БД в терминах отношений часто представляет собой очень сложный и неудобный для проектировщика процесс.

При этом ограниченность реляционной модели данных проявляется в следующих аспектах:

· Модель не обеспечивает достаточных средств представления смыслового содержания данных. Семантика реальной предметной области должна независимым от модели способом отображаться в сознание проектировщика. В частности, это относится к проблеме представления ограничений целостности;

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

Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не обеспечивает каких-либо средств для представления этих зависимостей.

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

Потребности проектировщиков БД в более удобных и мощных средствах моделирования предметной области реализуются при использовании

= семантических моделей данных =

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

Главным назначением семантических моделей является обеспечение возможности выражения семантики данных.

Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования БД. При этом в терминах семантической модели производится концептуальная схема БД, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.

Менее часто реализуется автоматизированная компиляция концептуальной схемы в реляционную модель.

Известны два подхода:

· на основе явного представления концептуальной схемы как исходной информации для компилятора;

· построение интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.

Третья возможность, которая пока только выходит за пределы исследовательских и экспериментальных проектов, – это работа с БД в семантической модели, то есть СУБД, основанные на семантических моделях данных.

При этом снова рассматриваются два варианта:

· обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной схемы БД в реляционную схему);

· прямая реализация СУБД, основанная на какой-либо семантической модели данных.

Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых – более слабы).

Основные понятия модели «Entity - Relationship».

Семантическая модель данных Entity - Relationship – модель "Сущность - Связи" (ER-модель).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию БД (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.

В связи с наглядностью представления концептуальных схем БД ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных БД. Среди множества разновидностей ER-моделей наиболее развитая модель применяется в системе CASE (фирмы ORACLE).

Основными понятиями ER-модели являются:

«сущность – связь – атрибут».

Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа. Сущность «АЭРОПОРТ», с примерными объектами «Шереметьево» и «Хитроу», приведена на рис. 2.24.

	Рис. 2.24. Сущность – АЭРОПОРТ с примерными объектами: Шереметьево и Хитроу

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

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

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

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

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

Обязательный конец связи изображается сплошной, а необязательный – прерывистой линией.

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

В примере, изображенном на рис. 2.25, связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При этом конец сущности с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем "имеет" означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

	Устная трактовка изображенной диаграммы: · Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА; · Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.
		Рис. 2.25. Связь между сущностями

На следующем примере, приведённом на рис. 2.26, изображена рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой.

		Устная трактовка изображенной диаграммы: · Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА; · Каждый ЧЕЛОВЕК может являться отцом одного или более ЛЮДЕЙ ("ЧЕЛОВЕКОВ").
	Рис. 2.26. Рекурсивная связь, связывающая сущность ЧЕЛОВЕК

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

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

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

Нормальные формы ER-схем.

Как и в реляционных схемах БД, в ER-схемах вводится понятие нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем.

Приведем краткие и неформальные определения трёх первых нормальных форм:

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

· устраняются атрибуты, зависящие только от части уникального идентификатора, эта часть уникального идентификатора определяет отдельную сущность.

· устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

К числу более сложных элементов модели относятся следующие:

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

· Связи "many-to-many". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (наприме, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи "многие – со –

многими".

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

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

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

·

	Домен–множество всех возможных значений некоторого атрибута, столбец отношения в БД.

Эти и другие более сложные элементы модели данных "Сущность – Связи" делают ее существенно более мощной, но одновременно несколько усложняют ее использование. При реальном использовании ER-диаграмм для проектирования БД необходимо ознакомиться со всеми возможностями.

Разберем один из упомянутых элементов – подтип сущности.

Сущность может быть разделена на два или более взаимно исключающих подтипа. Каждый из них включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе «подтипизация» может продолжаться на более низких уровнях, но опыт показывает, что в большинстве случаев оказывается достаточно двух-трех уровней.

Сущность, на основе которой определяются подтипы, называется супертипом.Подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты приходится определять дополнительный подтип ПРОЧИЕ.

Пример – супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ – приведён на рис. 2.27.

Иногда удобно иметь два или более разных разбиения сущности на подтипы.

Например, сущность ЧЕЛОВЕК может быть разбита на подтипы по профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т. д.), а может –

по половому признаку (МУЖЧИНА, ЖЕНЩИНА).