Создание диаграмм «сущность – связь»

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

Рисунок 14- Логическая концептуальная модель данных , соответствующая DFD -диаграмме для функционального блока «Подобрать индивидуальную программу для клиентов»

Рисунок 15- Логическая концептуальная модель данных , соответствующая DFD -диаграмме для функционального блока «Оформить абонемент»

 

Рисунок 15- Логическая концептуальная модель данных , соответствующая DFD -диаграмме для функционального блока «Произвести учет клиентов»

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

После создания логических концептуальных моделей, следует определить между ними требования для поддержки целостности данных. Их назначение состоит в поддержании постоянной внутрен­ней согласованности информации, которая будет храниться в проектируемой базе данных. Рассмотрим пять типов требований поддержки целостности:

• обязательные данные;

• ограничения для доменов атрибутов;

• целостность сущностей;

• ссылочная целостность;

• требования данного предприятия.

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

Целостность сущностей. Первичный ключ любой сущности не может содержать пустого значения. Напри­мер, каждая строка сущности «Клиенты» должна содержать уникальное значение атри­бута первичного ключа. В данном случае это – атрибут «Код клиента».

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

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

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

Неидентифицирующие отношения.

Примером неидентифицирующих отношений является связь между сущностями «Должности» и «Сотрудники», изображенной на рисунке 16.

Рисунок 16 –Пример неидентифицирующего отношения

Определим для связи между ними правила ссылочной целостности. Обратимся к рисунку 17.

Рисунок 17 – Правила ссылочной целостности для неидентифицирующих отношений

Поясним правила ссылочной целостности на примере связи между сущностями «Должности» и «Сотрудники». Сущность «Должность» является родительской, сущность «Сотрудники» является дочерней.

При удалении записи из дочерней сущности «Сотрудники» никаких ограничений не накладывается и никаких нарушений правил ссылочной целостности не происходит (правило None).

При вставке новой записи в дочернюю сущность «Сотрудники» необходимо, чтобы новое значение атрибута внешнего ключа «Код должности» обязательно присутствовало в одной из строк сущности «Должности» (правило Restrict).

При изменении записи в дочерней сущности «Сотрудники» необходимо, чтобы измененное значение атрибута внешнего ключа «Код должности» обязательно присутствовало в одной из строк сущности «Должности» (правило Resrtict).

При удалении записи из родительской сущности «Должности» будет проведена проверка на наличие записей в сущности «Сотрудники», внешний ключ которых ссылался на удаляемую строку, и, если такие записи буут найдены, то удаление запрещено  (правило Resrtict)

При вставке новой записи в родительскую сущность «Должности» никаких ограничений не накладывается и никаких нарушений правил ссылочной целостности не происходит (правило None).

При изменении записи первичного ключа в строке родительской сущности «Должности» приведёт к обновлению внешнего ключа во всех связанных с этой записью строках в сущности «Сотрудники»(правило Cascade).

Идентифицирующие отношения.

Примером идентифицирующих отношений является связь между сущностями «Время посещения занятий» и «Абонементы», изображенной на рисунке 18.

Рисунок 18 –Пример идентифицирующего отношения

Определим для связи между ними правила ссылочной целостности. Обратимся к рисунку 19.

 

Рисунок 19 – Правила ссылочной целостности для идентифицирующих отношений

Поясним правила ссылочной целостности на примере связи между сущностями «Время посещения занятий» и «Абонементы». Сущность Абонементы» является родительской, сущность «Время посещения занятий» является дочерней.

При удалении записи из дочерней сущности «Время посещения занятий» никаких ограничений не накладывается и никаких нарушений правил ссылочной целостности не происходит (правило None).

При вставке новой записи в дочернюю сущность ««Время посещения занятий» необходимо, чтобы новое значение атрибута внешнего ключа «Код абонемента» обязательно присутствовало в одной из строк сущности «Абонементы» (правило Restrict).

При изменении записи в дочерней сущности «Время посещения занятий» необходимо, чтобы измененное значение атрибута внешнего ключа «Код абонемента» обязательно присутствовало в одной из строк сущности «Абонементы» (правило Resrtict).

При удалении записи из родительской сущности «Абонементы» операция будет запрещена при наличии в дочерней сущности «Время посещения занятий» строк, ссылающихся на удаляемую строку родительской сущности (правило Restrict).

При вставке новой записи в родительскую сущность «Абонементы» никаких ограничений не накладывается и никаких нарушений правил ссылочной целостности не происходит (правило None).

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

Аналогичные правила ссылочной целостности наложим на все остальные сущности.

⇐ Предыдущая12345678Следующая ⇒

Поделиться: