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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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