48386 (Проектирование РБД "Санатория" с помощью инструментария AllFusion ERwin Data Modeler)

Министерство образования и науки РФ

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

Отчёт

по курсовой работе

по курсу: «Проектирование АСОИУ»

на тему:

«Проектирование РБД “Санатория” с помощью инструментария AllFusion ERwin Data Modeler »

Выполнили

Проверила:

2007

1. Цель работы:

Изучение возможностей AllFusion ERwin Data Modeler, проектирование реляционной БД на основе методологии IDEF1x.

2. Методология проектирования:

ERwin Data Modeler поддерживает нотации проектирования данных IDEF1х, IE и Dimensional.

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

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

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности.

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

Отдел нескольких Сотрудников

Самолет нескольких Пассажиров.

Сотрудник разные Отчеты.

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

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

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта СОТРУДНИК содержит поле "Уникальный идентификатор сотрудника", в области данных находятся поля "Имя сотрудника", "Адрес сотрудника", "Телефон сотрудника" и т.д.

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

3. Возможности инструментария проектирования:

AllFusion ERwin Data Modeler (ранее: ERwin) позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Создав наглядную модель базы данных, можно оптимизировать структуру БД и добиться её полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость её разработки.

Руководители проектов могут с помощью ERwin Data Modeler тщательно задокументировать структуру БД, получить отчеты презентационного качества и обеспечить эффективное управление проектом, используя среду для совместного проектирования AllFusion Model Manager (ранее: ModelMart).

Поскольку ERwin Data Modeler поддерживает работу с БД на физическом уровне, учитывая особенности каждой конкретной СУБД, администраторы БД могут с его помощью максимально повысить производительность информационной системы. Разработчики с помощью ERwin Data Modeler могут сначала, используя визуальные средства, описать схему БД, а затем автоматически сгенерировать файлы данных для выбранной реляционной СУБД (прямое проектирование). Автоматически генерируются также триггеры, обеспечивающие ссылочную целостность БД. ERwin Data Modeler поддерживает нотации проектирования данных IDEF1х, IE и Dimensional.

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

ERwin Data Modeler позволяет по уже существующим файлам БД восстанавливать логическую структуру данных. Это называется обратным проектированием. Оно позволяет, во-первых, переносить структуру БД (но не данные!) из одной СУБД в другую и, во-вторых, исследовать старые проекты. Этот процесс наиболее распространен при переходе с одной технологии на другую (с файл-сервер на клиент-сервер), а также при смене сервера БД. На основе модели данных предоставляется возможность создавать отчеты, которые позволяют существенно упростить процесс документирования технического проекта.

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

Основные характеристики AllFusion ERwin Data Modeler

• Поддержка стандартной нотации IDEF1x для ER-диаграмм моделей данных, нотации IE и специальной нотации, предназначенной для проектирования хранилищ данных - Dimensional.

• Поддержка проектирования информационных хранилищ (на основе Red Brick и Teradata)

• Поддержка совместного проектирования (версия для ModelMart)

• Поддержка триггеров, хранимых процедур и шаблонов

• Развитые средства проверки корректности моделей данных Reverse Engineering (генерация модели данных на основе анализа существующей базы данных), включая восстановление связей по индексам

• Автоматическая генерация SQL DDL для создания баз данных

• Полная совместимость и поддержка 20-ти типов СУБД на основе прямого доступа к системному каталогу баз данных (отпадает потребность в использовании ODBC).

4. Описание предметной области:

В данной лабораторной работе в качестве предметной области выступает «Санаторий». Данные, которые необходимо хранить в базе данных:

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

• Информация о секторах, из которых состоят отделения санатория;

• Информация о рабочих местах;

• Сведения о сотрудниках, предоставляющих услуги в санатории;

• Функции, выполняемые сотрудниками;

• Информация об условиях проживания в санатории.

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

5. Сущности и атрибуты:

В данной лабораторной работе при проектировании БД «Санатория» используются следующие сущности с соответствующими атрибутами:

• Отделение;

  • Наименование;

  • Юридический адрес.

• Сектор;

  • Наименование.

• Рабочее место:

  • Наименование.

• Сотрудник;

  • Фамилия;

  • Имя;

  • Отчество;

  • Адрес;

  • Зарплата;

  • Год рождения;

  • № страхового полиса;

  • Дата приема на работу.

• Функция;

  • Наименование.

• Автотранспорт;

  • Гос.номер;

  • Марка;

  • Срок эксплуатации;

  • Техосмотр.

• Клиент;

  • Фамилия;

  • Имя;

  • Отчество;

  • Адрес;

  • № страхового полиса;

  • Год рождения.

• Путевка;

  • Период;

  • Стоимость;

  • Количество человек.

• Жил.комплекс.

  • № комнаты;

  • Мебель;

  • Площадь;

  • Количество койка-мест;

  • Условия.

• Предприятие-отправитель:

  • Наименование;

  • Юридический адрес;

  • № договора.

6. Связи между сущностями:

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

Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.

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

Неидентифицирующие связи отображаются пунктирной линией между объектами. Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности.

При проектировании БД Санатория определены следующие связи между сущностями:

• Отделение состоит из секторов (один-ко-многим);

• Отделение обслуживает клиентов (многие-ко-многим);

• Сектор состоит из рабочих мест (один-ко-многим);

• Рабочее место предоставляется сотруднику (один-ко-многим):

• Функции выполняется на рабочем месте (один-ко-многим);

• Автотранспорт принадлежит отделению (один-ко-многим);

• Клиент имеет путевку (один-ко-многим);

• Клиент работает на предприятии (один-ко-многим);

• Жил.комплекс предоставляется клиенту (один-ко-многим);

• Предприятие-отправитель предоставляет путевки (один-ко-многим);

Рис.1. Логический уровень проектирования БД

7. Переход на физический уровень. Процесс преобразования связи многие-ко-многим: