Лабораторная работа № 2 Создание концептуальной и логической модели.

Цель работы: изучить основы концептуального проектирования и освоить способ реализации проекта в виде логические модели в среде ErWin.

Теоретические сведения.

Процесс проектирования базы данных принято разделять на три основные фазы:

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

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

• физическое проектирование – создание описания конкретной реализации базы данных (с помощью выбранной СУБД): описание структуры хранения данных и методов доступа.

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

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

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

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

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

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

• специализация или генерализация топов сущностей (необязательный этап),

• создание диаграммы «сущность-связь»,

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

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

Более детально рассмотрим процесс логического проектирования.

Структурные ограничения

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

Для идентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL.

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

Рис.2.4. Имя ролей внешних ключей.

В сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя «Где работает», которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута следует в контекстном меню для диаграммы выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute.

Примером обязательности присвоения имен ролей являются рекурсивные связи («рыболовный крючок» - fish hook), когда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. Сущность Сотрудник содержит атрибут первичного ключа Табельный номер. Чтобы сослаться на руководителя сотрудника следует создать рекурсивную связь (руководит/подчиняется) и присвоить имя роли («Руководитель»). Рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии – у дерева подчиненности должен быть корень – сотрудник, который никому не подчиняется в рамках данной организации. Такой вид рекурсивной связи называется иерархической рекурсией и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчиненный имеет только одного руководителя. Существует также другой вид рекурсии – сетевая рекурсия. Например, когда руководитель имеет множество подчиненных и подчиненный может иметь множество руководителей. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи многие-ко-многим. Разрешение связи многие-ко-многим будет описана в следующих разделах.

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

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

Рис. 2.5. Случай обязательности имен ролей

Пример реализации сетевой рекурсии. Структура моделирует родственные отношения между членами семьи любой сложности.

Атрибут Тип отношения может принимать значения «отец-сын», «мать-дочь», «дед-внук», «свекровь-невестка», «тесть-зять» и т.д. Поскольку родственные отношения связывают всегда двух людей, от сущности Родственник к сущности Родственные отношения установлены две идентифицирующие связи с именами ролей «Старший» и «Младший». Каждый член семьи может быть в родственных отношениях с любым другим членом семьи, более того, одну и ту же пару родственников могут связывать разные типы родственных отношений.

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более только имя роли.

Рис. 2.6. Миграция имен ролей.

Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли «В какой команде играет». На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).

Правила ссылочной целостности (referential integrity, RI) – логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генерации схемы БД на основе опций логической модели, задаваемых во вкладке Rolename/RI Actions, будут сгенерированы правила ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE). В предыдущем примере Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок (для удаления команды сначала нужно удалить всех играков), либо сразу удалить вместе с командой всех ее играков. Такие правила удаления называются «ограничение» и «каскад» (Parent RESTRICT и Parent CASCADE). Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки команды и все голы, которые они забивали.

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

Рис. 2.7. Связь многие-ко-многим.

При переходе к физическому уровню Erwin автоматически преобразует связь многие-ко-многим, добавляя новую таблицу и устанавливая две новые связи один-ко-многим от старых к новой таблице. Новой таблице автоматически присваивается имя «Имя1_Имя2».

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

Рис. 2.8. Дополнение модели при разрешении связи многие-ко-многим.