25.04.02 Простота и сложность проектирования баз данных с помощью eRwin

© Владимир Тарзанов

• ВВЕДЕНИЕ

• ТИПЫ СВЯЗЕЙ

• ОТКУДА ПОЯВЛЯЕТСЯ ИДЕНТИФИКАЦИЯ

• МНОГОЛИКОСТЬ СВЯЗЕЙ

Введение

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

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

ERwin - это не просто средство проектирования, но и инструмент разработки, способный автоматически создавать таблицы и генерировать тысячи строк текста хранимых процедур и триггеров для всех популярных СУБД. Революционнаятехнология Complete - Compare (Завершить-Сравнить) позволяет организовать итеративную разработку, поддерживая постоянную согласованность модели и базы данных. Благодаря интеграции с популярными средами разработки программ, ERwin позволяет ускорить создание приложений для обработки данных.

ERwin может масштабироваться путем интеграции с продуктом PLATINUM ModelMart. Эта мощная система управления моделями позволяет проектировщикам баз данных, разработчикам приложений и пользователям коллективно работать с информацией о моделях ERwin. Благодаря возможностям разбиения на фрагменты, а также совместного и многократного использования моделей, может быть повышена эффективность моделирования и обеспечено соблюдение корпоративных стандартов.

И это далеко не полный перечень всех достоинств программного продукта.

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

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

Типы связей

В стандарте IDEF1X определены типы связей, показанные в табл.1.

Таблица 1

Типы связей стандарта idef1x

	Идентифицирующая связь
	Неидентифицирующая связь
	Рекурсивная связь
	Связь типа “многие-ко-многим”
	Связь супертипа с подтипами

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

Откуда появляется идентификация

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

Рассмотрим простой пример. Пусть имеется сущность СТУДЕНТ, показанная на рис.1.

Рис. 1. Сущность СТУДЕНТ

Из классической теории реляционных баз данных вспомним, что для обеспечения целостности данных и исключения появления различного рода аномалий необходимо, чтобы каждое отношение находилось, как минимум в третьей нормальной форме (3НФ). При этом 3НФ предполагает нетранзитивную зависимость неключевых атрибутов от первичного ключа. В случае с сущностью СТУДЕНТ такие зависимости имеются (например, НОМЕР ЗАЧЕТНОЙ КНИЖКИ НОМЕР ГРУППЫНОМЕР ФАКУЛЬТЕТА). Известно, что для устранения таких зависимостей необходимо выполнить операцию проекции на атрибуты, которые служат причиной этих зависимостей. Результатом проекции отношения на соответствующие атрибуты (согласно реляционной алгебре) является также отношение, как показано на рис. 2.

 

                                                                       А)                                                                                 Б)

Рис. 2. Результаты проекции отношения СТУДЕНТ

Проверив образовавшиеся сущности СТУДЕНТ и ГРУППА на нормальность можно убедиться, что сущность ГРУППА не находится в 3НФ. Следовательно, необходима следующая проекция, которая приведет к появлению другой независимой сущности, например, СПЕЦИАЛЬНОСТЬ.

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

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

Многоликость связей

Особого внимания заслуживают также типы связей “мноие-ко-многим” и супертипа с подтипами.

Стандарт EDEF1X допускает присутствие в модели обоих типов связей. Однако без их разрешения физическая база данных будет далека от оптимальной. Здесь следует отметить, что ERwin предоставляет возможность выбора способа разрешения этих связей, особенно для связей типа СУПЕРТИП-ПОДТИПЫ.

Стандартным разрешением связи “многие-ко-многим” является механизм, показанный на рис. 3.

 

Рис. 3. Разрешение связи "многие-ко-многим"

Из рис.3 видно, что если Е/1 и Е/2 отвечают условиям нормальности, то и сущность Е/2_Е/1 также нормальна.

Если в схеме базы данных присутствуют подтипы, то для разрешения таких связей предусмотрено два способа:

• все подтипы составляют одну сущность;

• для каждого подтипа отдельная сущность,

как показано на рис. 4.

Рис. 4. Разрешение связи СУПЕРТИП-ПОДТИПЫ

Насколько каждое из предложенных разрешений оптимально можно судить только исходя из содержания сущностей Е/1, Е/2 и Е/3. Однако при преобразовании логической модели в физическую базу данных очевидны формальные преимущества и недостатки каждого разрешения, которые сведены в табл.2.

Таблица 2