35

Методические указания к лабораторной работе №4 по дисциплине «Базы данных и информационные системы» (№1 - осенний семестр)

на тему

«Изучение основных принципов проектирования РБД

с помощью инструментального CASE-средства ERWIN»

4.1 Цель работы

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

4.2 Методические указания

4.2.1 Общие сведения

Система ERwin – это программное средство из категории т.н. CASE (Computer-Aided Software Engineering)-систем для моделирования и проектирования баз данных (БД).

Система ERwin поддерживает процесс проектирования модели данных, генерацию схемы БД на языке SQL для целевой системы управления базы данных (СУБД). Такими СУБД могут быть ORACLE, Informix, InterBase, Ingres, Sybase, DB/2 IBM, Microsoft SQL Server, Progress, Access и некоторые др. Система Erwin позволяет также проводить реинжиниринг (reengineering) существующей БД.

Сама аббревиатура названия системы - ERwin – указывает на то, что в основу ее функционирования положено представление о ER (Entity-Relationalship)-модели данных или модели «сущность-связь». Основным объектом работы пользователя системы являются модели данных в виде ER-диаграмм.

4.2.2 Назначение системы

Применение системы ERwin существенно повышает эффективность разработки информационных систем. Среди основных преимуществ его использования можно назвать:

• повышение скорости разработки за счет мощного редактора ER-диаграмм, автоматической генерации схемы БД, автоматической подготовки документации;

• возможность легко вносить изменения в модель данных при разработке и расширении системы;

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

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

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

4.2.3 Основная функциональность системы и технология ее использования

Модели данных в классической теории БД

Концептуальный уровень представляет собой абстрактный взгляд на данные. На этом уровне данные представляются так, как они выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Концептуальная модель данных является универсальной и никак не связана с конкретной реализацией СУБД. На этом этапе разработки должно быть выполнено следующее:

• определение типов сущностей;

• определение типов связей;

• определение атрибутов и связывание их с типами сущностей и связей;

• определение доменов атрибутов;

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

• обоснование необходимости использования понятий расширенного модели­рования (необязательный этап);

• проверка модели на отсутствие избыточности;

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

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

• устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап), например, устранение связей «многие ко многим», т.к. они не могут быть представлены непосредственно в реляционной модели;

• определение набора отношений исходя из структуры логической модели данных;

• проверка отношений с помощью правил нормализации;

• проверка соответствия отношений требованиям пользовательских транзак­ций;

• определение требований поддержки целостности данных.

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

Модели данных в ERwin

Система ERwin имеет два уровня представления модели – логическая модель (logical model) и физическая модель (physical model).

Прим. С точки зрения классической теории моделирования данных в СУБД логическая модель системы ERwin представляет собой т.н. КОНЦЕПТУАЛЬНЫЙ уровень описания данных (Conceptual level), а также включает некоторые элементы классического ЛОГИЧЕСКОГО уровня (Logical level), а именно, позволяет проводить логическое моделирования по приведению концептуальной модели к реляционной модели (например, проводить нормализацию сущностей), а физическая модель системы ERwin включает в себя т.н. классический ЛОГИЧЕСКИЙ уровень (на этом уровне можно также проводить нормализацию, а также при переходе к этой модели Erwin автоматически решает проблему связей «многие-ко-многим», которые не поддерживаются реляционными СУБД) и элементы классического ФИЗИЧЕСКОГО уровня (Physical level ) (учитываются типы данных, и другие особенности целевой СУБД).

Таблица 4.х – Соответствие между моделями данных в Erwin и моделями классического проектирования БД

Модели в классической теории БД	Концептуальная модель	Логическая модель		Физическая модель
Модели в Erwin	Логическая модель		Физическая модель

На основе логической модели Erwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Еrwin также способен по содержимому системного каталога или SQL-скрипту воссоздать логическую модель данных, этот процесс называется Reverse Engineering.