Моделирование информационных процессов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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