Моделирование систем баз данных

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

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

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

Для построения отношений по бинарным связям типа 1:n существуют следующие правила:

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

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

Если  степень бинарной связи равна  m:n. то для хранения данных необходимо три отношения вне зависимости от классов принадлежностей сущностей: по одному для каждой сущности и одно для связи. Последнее в качестве свежих атрибутов имеет ключ каждой сущности. В случае трехсторонней связи (триарные отношения) необходимо использовать четыре отношения. Аналогично, когда связь n-сторонняя, требуется n+1 предварительное отношение.

Изложенный  алгоритм перехода от ER-модели к реляционным  структурам данных является одним из наиболее полных. Его использование  позволяет получить как минимум  правильные решения по составу таблиц любой реляционной базы данных.

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

 

Моделирование баз данных в IDEF1

Как уже говорилось выше, достоинством IDEF1-методологии проектирования данных является наличие CASE-средства (пакет IDEF1X), позволяющего строить модели уровней сущностей и вести глоссарии [13, 14]. Система автоматизированного моделирования CASE IDEF1X позволяет получить модель предметной области, которая не является в чистом виде инфологической. Эта модель может считаться как инфологической, так и реляционной физической моделью базы данных. С точки зрения процесса проектирования базы данных, главной особенностью методологии CASE IDEF1X является то, что в ней нет отдельно выраженных этапов инфологического и физического проектирования. Пользователь строит модель предметной области, которая в конце концов может считаться и инфологической и физической.

Для того, чтобы IDEF1Х-модель могла использоваться в качестве физической, необходимо чтобы она была полностью специфицированной. Это означает, что из нее должны быть удалены так называемые "неспецифицированные" отношения. ''Неспецифицированными'' являются отношения 1:1 и m:n. Они разрешены на ранних этапах проектирования, а затем должны быть удалены или преобразованы с помощью дополнительных сущностей и связей.

Отношение 1:1 может быть удалено, а  связанные им сущности - объединены в одну, ключом которой должен стать любой из ключей объединенных сущностей. Для отношений m:n необходимо ввести в модель искусственную сущность и связать ее отношениями n:1 с существующими.

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

- каждая сущность соответствует  отдельной таблице базы данных;

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

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

- все  атрибуты, имеющие описатель FK, являются внешними ключами.

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

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

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

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

Необходимо  отметить, что алгоритм проектирования структур данных в IDEF1X довольно слабый и реализует очень узкий круг отношений, называемых специфическими. Из-за того, что круг специфических отношений довольно мал, проектировщику больших систем практически всегда приходится делать дополнительные действия по преобразованию IDEFlX-модели. Эти действия ведут к увеличению трудоемкости процесса проектирования. Систему, подобную IDEF, которая по существу дает рекомендации по проектированию, имеет смысл применять тогда, когда этих рекомендаций не одна, а несколько. Но, как и все, рассмотренные нами системы автоматизированного проектирования, IDEF1X предлагает только один вариант решений по структурам данных.

назад | содержание | далее

4.1. Современные CASE-средства  

 

Мы рассмотрели несколько различных  методик ER-моделирования. В таблице 2 сравниваются классы ER-моделей по характеристикам, описывающим возможность  их применения в реальных проектах.

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

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

Из-за этого использование неавтоматизированных моделей затруднено. При разработке систем обработки данных больших информационных систем предпочтительнее все-таки использовать средства автоматизации проектирования.

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

 

Таблица 2 - Характеристики основных методологий ER-моделирования

Наименования характеристик	Чен	Джексон	Диго	IDEF
1. Количество видов  сущностей	1	1	3	2
2. Количество видов  отношений по числу входящих экземпляров	3	3	3	2
3. Возможность указания  отношений	-	+	-	+
4. Наличие n-арных отношений	+	+	-	-
5. Возможность отображения отношений "род-вид"	-	-	+	-
6. Наличие альтернативных  отношений	-	-	-	-
7. Вид физической модели, для которой предложены алгоритмы  преобразования	сетевая	реляционная	сетевая реляционная  на инд. файлах	реляционная
8. Наличие средств  автоматизации	-	-	-	+
9. Отражение на диаграмме  атрибутов	+	-	+	+
10. Выделение на диаграмме  ключей	-	-	+	+

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

Ранее были рассмотрены несколько  алгоритмов перехода от инфологической модели к физической. Часть из этих алгоритмов ручные, часть - автоматизированные.

Алгоритмы перехода Чена, Джексона и практически всех CASE-средств дают только один вариант физической модели по конкретной инфологической. Модель Диго дает несколько вариантов, но они носят рекомендательный характер и не всегда ясно какое из них применять.

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

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

CASE-IDEF1X предлагает реляционную физическую модель вместе с инфологической, которая должна содержать только специфицированные отношения. Круг специфицированных отношений довольно узок. Приведение модели к "специфицированному'' виду лежит в компетенции проектировщика. Это затрудняет применение IDEF1X при проектировании больших информационных систем. Кроме того, решения, предложенные IDEF1X практически невозможно использовать на стадиях программирования или описания ограничений целостности.

Таким образом, возникает необходимость использования CASE-средств, которые будут лишены вышеперечисленных недостатков. Далее будет произведен анализ CASE-средств.

CASE-технология - это не только методология,  но и инструментарий. Сейчас на  рынке существует огромное количество CASE-пакетов. Все CASE-средства делятся на типы, категории и уровни [2-4]. 

 

Классификация CASE-средств

I. Классификация  по типам отражает функциональную ориентацию CASE-средств в технологическом процессе.

1. Анализ  и проектирование. Средства этой  группы используются для создания  спецификаций системы и ее  проектирования: они поддерживают  широко известные методологии  проектирования. К таким средствам относятся: The Developer (Asyst Technologies), Design Generator (Computer Sciences). Pose (Computer Systems Advises). Analisi/ Designer (Jour- don)...

2. Проектирование  баз данных и файлов. Средства  обеспечивают логическое моделирование данных, генерацию схем БД и описание форматов файлов: PowerDesigner, Idef/Leverage (D.Appleton), Chen Toolkit (CTien & Associates). Case+Designer (Orale)...

3. Программирование. Средства поддерживают шаги программирования  и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: Cobol 2/ Workbench (Miero Focus), Decase (DEC), Netron/Cap (Netron)...