Методические указания по выполнению лабораторной работы №1
«Изучение CASE-средства ERwin»
1. Теоретическое введение.
Один из первых вопросов, возникающих перед программистом при создании приложения, использующего базы данных, это создание модели этой базы данных или проектирование. CASE-средство Erwin позволяет просто и эффективно решить этот вопрос. При изучении данного CASE-средства необходимо познакомится с методологией IDEF1X, на которой основана разработка с помощью Erwin.
1.1. Методология IDEF1X
IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.
Существует несколько очевидных причин, по которым IDEF1X не следует применять в случае построения не реляционных систем. Во-первых, IDEF1X требует от проектировщика определить ключевые атрибуты, для того чтобы отличить одну сущность от другой, в то время как объектно-ориентированные системы не требуют задания ключевых ключей, в целях идентификации объектов. Во-вторых, в тех случаях, когда более чем один атрибут является однозначно идентифицирующим сущность, проектировщик должен определить один из этих атрибутов первичным ключом, а все остальные вторичными. И, таким образом, построенная проектировщиком IDEF1X-модель и переданная для окончательной реализации программисту является некорректной для применения методов объектно-ориентированной реализации, и предназначена для построения реляционной системы. Так как в данной работе строится реляционная модель базы данных, то, очевидно, что данная методология подходит для этого.
1.2. Сущности в IDEF1X и их атрибуты.
Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. В IDEF1X модели свойства сущности называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.
Рассмотрим простейший пример: сущность «Сотрудник» - сотрудник какой-либо организации. Атрибутами для него (свойства сущности) будут являться: фамилия, имя, отчество, дата рождения, должность. На Erwin данная сущность будет иметь вид:
1.3. Связи между сущностями
Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой.
Схема один ко многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая - дочерней. Связи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией.
Отношения многие ко многим обычно используются на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах. Так как отношения многие ко многим могут скрыть другие бизнес правила или ограничения, они должны быть полностью исследованы на одном из этапов моделирования. Например, иногда отношение многие ко многим на ранних стадиях моделирования идентифицируется неправильно, на самом деле представляя два или несколько случаев отношений один-ко-многим между связанными сущностями. Или, в случае необходимости хранения дополнительных сведений о связи многие-ко-многим, например, даты или комментария, такая связь должна быть заменена дополнительной сущностью, содержащей эти сведения. При моделировании необходимо быть уверенным в том, что все отношения многие ко многим будут подробно обсуждены на более поздних стадиях моделирования для обеспечения правильного моделирования отношений. Пример связей между сущностями приведем после знакомства с понятием идентификации сущностей.
1.4. Идентификация сущностей. Представление о ключах.
Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены не ключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных.
Ключевая область содержит первичный ключ для сущности. Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Атрибуты первичного ключа располагаются над линией в ключевой области. Как следует из названия, не ключевой атрибут - это атрибут, который не был выбран ключевым. Не ключевые атрибуты располагаются под чертой, в области данных.
При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: "Как можно идентифицировать уникальную запись?". Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Сущности в IDEF1X всегда имеют ключевую область и, поэтому в каждой сущности должны быть определены ключевые атрибуты.
Выбор первичного ключа для сущности является очень важным шагом, и требует большого внимания. В качестве первичных ключей могут быть использованы несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей.
Правила, по которым выбирается первичный ключ из списка предполагаемых ключей, очень строги, однако могут быть применены ко всем типам баз данных и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:
· Уникальным образом идентифицировать экземпляр сущности.
· Не использовать NULL значений.
· Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.
· Быть как можно более короткими для использования индексирования и получения данных. Если нужно использовать ключ, являющийся комбинацией ключей из других сущностей, нужно убедиться в том, что каждая из частей ключа соответствует правилам.
При выборе первичного ключа для сущности, разработчики модели часто используют дополнительный (суррогатный) ключ, т. е. произвольный номер, который уникальным образом определяет запись в сущности. Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы.
Как видим в нашей сущности нет первичного ключа, так как не одно из полей не является уникальным, и даже вся совокупность атрибутов может не быть уникальной внутри большой фирмы. Поэтому целесообразно ввести дополнительное числовое поле, которое будет уникально идентифицировать экземпляр сущности. Назовем это поле «Код» и укажем, что оно является первичным ключом:
Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.
В качестве примера добавим сущность «Адрес» сотрудника, которая будет связана с сущностью «Сотрудник» через код сотрудника. Для этого создадим сущность «Адрес» с атрибутами: город, улица, дом, квартира. Затем построим идентифицирующую связь от сущности «Сотрудник» к «Адрес». В итоге получим две связанные сущности:
1.5. Классификация сущностей в IDEF1X. Зависимые и независимые сущности.
При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.
Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Напротив, существуют ситуации, в которых сущность зависит от существования другой сущности.
Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В IDEF1X независимые сущности представлены в виде прямоугольников.
1.6. Типы связей между сущностями. Идентифицирующие и не идентифицирующие связи. Мощность связи.
В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можно создать идентифицирующую связь между родительской и дочерней сущность.
Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.
Не идентифицирующие связи, являющиеся уникальными для IDEF1X, также связывают родительскую сущность с дочерней. Не идентифицирующие связи используются для отображения другого типа передачи атрибутов внешних ключей - передача в область данных дочерней сущности (под линией).
Не идентифицирующие связи отображаются пунктирной линией между объектами. Так как переданные ключи в не идентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости.
Тем не менее, взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.
Также важное значение имеет так называемая мощность связи, которая служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности:
- одному экземпляру родительской сущности соответствует 0, 1 или много экземпляров дочерней сущности;
- одному экземпляру родительской сущности соответствует 1 или много экземпляров дочерней сущности (обозначается символом P);
- одному экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности (символ Z);
- указывается точное значение данного соответствия (обозначается данным числом).
Указать данные параметры можно, открыв свойства связи. В нашем случае:
1.7. Ссылочная целостность.
Правила ссылочной целостности определяют, что делать при вставке, изменении или удалении дочерней или родительской сущности. В базе данных данные правила будут реализованы с помощью триггеров – программ, которые выполняются при выполнении команд вставки, замены или удаления (INSERT, UPDATE, DELETE).
Для идентифицирующих связей возможны следующие правила:
- RESTRICT – ограничение (в нашем случае: если мы поставим ограничение на сущность «Сотрудник», то мы не сможем удалить ее, пока не удалим все записи из сущности «Адрес», связанные с данной записью).
- CASCADE – каскад (в данном случае с удалением записи из сущности «Сотрудник» будут удалены все связанные с данной записи из таблицы «Адрес»).
- NONE – ничего не делать.
Для не идентифицирующих связей также возможны следующие правила:
- SET NULL – установить значение «NULL», т. е. при удалении сотрудника в таблице «Адрес» в качестве значения внешнего ключа будет установлено значение «NULL».
- SET DEFAULT – устанавливается значение по умолчанию.
Данные правила можно установить в свойствах связи во вкладке «Rl Actions»:
1.8. Объединение сущностей.
В Erwin существует особый тип связи, использующийся для объединения сущностей, имеющих общие атрибуты. Например, сотрудники, работающие полный рабочий день, и сотрудники, работающие на определенную ставку, могут быть объединены в одну сущность сотрудник следующим образом:
У сотрудников, работающих по совместительству, появляется дополнительный атрибут «Ставка».
1.9. Физическая модель.
Пока мы рассматривали так называемую логическую модель базы данных, которая связана с предметной областью, но не имеет отношения к конкретной СУБД. Для связи с СУБД необходимо создать физическую модель базы данных, для которой следует указать ту СУБД, которую предполагается использовать. Для всех атрибутов необходимо определить тип и размер данных. Erwin позволит сделать выбор из типов, поддерживаемых целевой СУБД. Также необходимо ввести названия всех сущностей и атрибутов английскими буквами, т. к. эти названия будут использованы в качестве имен таблиц и колонок в базе данных. В нашем случае получим следующую физическую модель базы данных:
На этом закончим рассмотрение теоретической части и перейдем к практической.
2. Практическая часть.
В качестве практической части рассмотрим создание модели базы данных для предметной области: «Фирма, занимающаяся сдачей в аренду жилья».
2.1. Логическая модель.
Для начала рассмотрим предметную область и выделим сущности данной предметной области:
- «Отделение фирмы»: Код, название, почтовый индекс, город, адрес (улица, дом, квартира), телефон, факс.
- «Сотрудник»: Код, фамилия, имя, адрес, город, зарплата, дата рождения, телефон, пол, тип (внутренний сотрудник, работает с клиентами), должность (для внутренних сотрудников). Сущность «Сотрудник» является дочерней для сущности «Отделение фирмы».
- «Собственник объекта»: код, фамилия, имя, город, адрес, телефон. Собственник – лицо, владеющее объектом аренды.
- «Объект аренды»: Код, город, адрес, число комнат, стоимость, тип.
- «Арендатор»: Код, фамилия, имя, телефон.
Рассмотрим получившуюся логическую модель:
2.2. Физическая модель.
Перейдем к физической модели базы данных:
2.3. Задание.
Необходимо выбрать предметную область и разработать для нее с помощью CASE-средства Erwin модель базы данных (логическую и физическую). В качестве целевой СУБД выбрать FoxPro.
Обязательные требования:
- наличие в модели не менее 7 связанных таблиц;
- наличие всех типов связи (идентифицирующие и не идентифицирующие);
- наличие всех видов мощностей связи;
- наличие объединяющей связи;
- реализация ссылочной целостности;
- наличие комментариев к сущностям, связям; задание имен для связей; задание имен для внешних ключей в дочерних сущностях;
- наличие подробного отчета, отражающего все аспекты данной работы.
