Базы данныхИнтернетКомпьютерыОперационные системыПрограммированиеСетиСвязьРазное
Поиск по сайту:
Подпишись на рассылку:

Назад в раздел

CASE. Структурный системный анализ.


ГЛАВА 5. ДИАГРАММЫ "СУЩНОСТЬ-СВЯЗЬ"
-----------------------------------

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

Данная нотация была введена Ченом (Chen) и получила дальнейшее
развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый
набор средств моделирования данных, включая ERD, диаграммы атрибутов,
диаграммы декомпозиции. Эти диаграммные техники используются для
проектирования реляционных баз данных.

Сущности, отношения и связи в нотации Чена
---------------------------------------------------------------------
Сущность представляет собой множество экземпляров реальных или
абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.),
обладающих общими атрибутами или характеристиками. Любой объект системы
может быть представлен только одной сущностью, которая должна быть
уникально идентифицирована. При этом имя сущности должно отражать тип или
класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не
ВНУКОВО).

Отношение в самом общем виде представляет собой связь между двумя и
более сущностями. Именование отношения осуществляется с помощью
грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

Символы ERD, соответствующие сущностям и отношениям, приведены на
рис. 5.1.

Рис. 5,1: Символы ERD в нотации Чена

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

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

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

Значение связи характеризует ее тип и, как правило, выбирается из
следующего множества:

{"0 или 1", "0 или более", "1", "1 или более", "p:q" (диапазон)}.

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

1) 1*1 (один-к-одному). Отношения данного типа используются, как
правило, на верхних уровнях иерархии модели данных, а на нижних
уровнях встречаются сравнительно редко.

2) 1*n (один-к-многим). Отношения данного типа являются наиболее
часто используемыми.

3) n*m (многие-к-многим). Отношения данного типа обычно используются
на ранних этапах проектирования с целью прояснения ситуации. В
дальнейшем каждое из таких отношений должно быть преобразовано в
комбинацию отношений типов 1 и 2 (возможно, с добавлением
вспомогательных ассоциативных сущностей и с введением новых
отношений).

На рис.5.2 приведена диаграмма "сущность-связь", демонстрирующая
отношения между объектами банковской системы. Согласно этой диаграмме
каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый
КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и
одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности
одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни
кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ только один зависимый от
нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ.

Рис. 5.2: ER-диаграмма в нотации Чена

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

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

Пример диаграммы атрибутов, детализирующей сущность КРЕДИТНАЯ КАРТА
(см. рис. 5.2) приведен на рис. 5.3.

Рис. 5.3: Диаграмма атрибутов

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

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

Рис. 5.4: Диаграмма категоризации

Существуют 4 возможных типа дискриминатора (рис.5.5):

Рис. 5.5: Типы дискриминаторов

1) Полное и обязательное вхождение Е/М (exclusive/mandatory) -
сущность должна быть одной и только одной из следуемых категорий.
Для примера на рис. 5.4 это означает, что ПРЕПОДАВАТЕЛЕМ является
ФИЗИК, или ХИМИК, или МАТЕМАТИК.

2) Полное и необязательное вхождение Е/О (exclusive/optional) -
сущность может быть одной и только одной из следуемых категорий.
Это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или
МАТЕМАТИК, или преподаватель какой-либо другой дисциплины
(например, ИСТОРИК).

3) Неполное и обязательное вхождение 1/М (inclusive/mandatory) -
сущность должна быть по крайней мере одной из следуемых категорий.
Это предполагает в дополнение к 1) задавать следующую ситуацию:
ПРЕПОДАВАТЕЛЕМ является одновременно и ФИЗИК, и ХИМИК.

4) Неполное и необязательное вхождение I/O (inclusive/optional) -
сущность может быть по крайней мере одной из следуемых категорий.
В дополнение к 2) ПРЕПОДАВАТЕЛЕМ является преподаватель какой-либо
другой дисциплины (например, ИСТОРИК).

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

В нотации Баркера используется только один тип диаграмм - ERD.
Сущность на ERD представляется прямоугольником любого размера, содержащим
внутри себя имя сущности, список имен атрибутов (возможно, неполный) и
указатели ключевых атрибутов (знак "#" перед именем атрибута).

Все связи являются бинарными и представляют собой линии с двумя
концами (соединяющими сущности), для которых должно быть определено имя,
степень множественности (один или много объектов участвуют в связи) и
степень обязательности (т.е. обязательная или необязательная связь между
сущностями). Для множественной связи линия присоединяется к прямоугольнику
сущности в трех точках, а для одиночной связи - в одной точке. При
обязательной связи рисуется непрерывная линия до середины связи, при
необязательной - пунктирная линия. На рис. 5.6 приведен фрагмент ERD для
банковской задачи в нотации Баркера.

Рис. 5.6: Нотация Баркера

Читается связь отдельно для каждого конца, показывая, как сущность
КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом
необходимо учитывать степень обязательности выбранного конца связи, для
этой цели используются слова "должен (быть)" или "может (быть)". Так,
диаграмма, приведенная на рис. 5.6, читается следующим образом:

Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ или

Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ только одному КЛИЕНТУ.

Понятия категория и общая сущность заменяются Баркером на
эквивалентные понятия подтипа и супертипа, соответственно.

Построение модели
---------------------------------------------------------------------
Разработка ERD включает следующие основные этапы:

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

2. Идентификация отношений между сущностями и указание типов
отношений.

3. Разрешение неспецифических отношений (отношений n*m).

Этап 1 является определяющим при построении модели. Его исходной
информацией служит содержимое хранилищ данных, определяемое входящими и
выходящими в/из него потоками данных. На рис. 5.7 приведен фрагмент
диаграммы потоков данных, моделирующей деятельность бухгалтерии
предприятия. Его единственное хранилище ДАННЫЕ О ПЕРСОНАЛЕ должно
содержать информацию о всех сотрудниках: их имена, адреса, должности,
оклады и т.п.

Рис. 5.7: Деятельность бухгалтерии

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

ВХОДНЫЕ ВЫХОДНЫЕ

СТРУКТУРЫ СТРУКТУРЫ

ДАННЫХ ДАННЫХ

вновь_нанятые адрес_служащего

дата_найма фамилия

фамилия адрес

таб_номер

адрес подробности_з/пл

должность
начальная_з/пл

уволенные
фамилия
таб_номер

фамилия
таб_номер
текущая_з/пл

изменение_адреса
фамилия
таб_номер
старый_адрес
новый_адрес

история_занятости
фамилия
таб_номер
дата_найма
история_карьеры *
должность
дата_изменения
история_з/пл *

з/пл
изменение_з/пл
фамилия
таб_номер
старая_з/пл
новая_з/пл
дата_изменения

Сравнивая входные и выходные структуры, отметим следующие моменты:

¦ Поле АДРЕС хранит текущий адрес сотрудника, а структура
ИЗМЕНЕНИЕ_АДРЕСА хранит и старый адрес, что не является
необходимым, исходя из выходных потоков.

¦ ИСТОРИЯ_З/ПЛ, наоборот, требует перечень всех окладов сотрудника,
поэтому необходимо иметь набор, состоящий из пар (З/ПЛ, ДАТА), а не
просто СТАРАЯ_З/ПЛ и НОВАЯ_З/ПЛ (как во входном потоке).

¦ Аналогичная ситуация и с ИСТОРИЕИ_КАРЬЕРЫ. Отметим, что на
диаграмме вообще отсутствует поток, определяющий изменения в
должности, то есть обнаружено серьезное упущение в функциональной
модели.

¦ Отметим, что изменение в ДОЛЖНОСТИ обычно (но не всегда)
соответствует изменению в З/ПЛ.

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

фамилия

таб_номер

адрес

текущая_з/пл

дата_найма

история_карьеры *

должность

дата_изменения

история_з/пл *

з/пл

дата_изменения

На следующем шаге осуществляется упрощение схемы за счет устранения
избыточности. Действительно, ТЕКУЩАЯ_3/ПЛ всегда является последней
записью в ИСТОРИИ_З/ПЛ, а ДАТА_НАЙМА содержится в разделах ИСТОРИЯ_З/ПЛ и
ИСТОРИЯ_КАРЬЕРЫ. Кроме того, несколько дат в последних разделах одни и те
же, поэтому целесообразно создать на их основе структуру
ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ и вводить в нее данные при изменении ДОЛЖНОСТИ и/или
З/ПЛ.

фамилия

таб_номер

адрес

история_з/пл_карьеры *

з/пл

должность

дата_измемения

Следующий шаг - упрощение схемы при помощи нормализации (удаления
повторяющихся групп). Единственным способом нормализации является
расщепление данной схемы на две, являющиеся более простыми. Первая схема
содержит ФАМИЛИЮ и АДРЕС (которые, как правило, не меняются), вторая -
каждое изменение З/ПЛ и ДОЛЖНОСТИ. Кроме того, каждая схема должна
содержать ТАБ_НОМЕР - единственный элемент данных, уникально
идентифицирующий каждого сотрудника.

Для идентификации сущностей осталось определить ключевые атрибуты.
Для первой схемы ключевым атрибутом является ТАБ_НОМЕР, для второй -
ключом является конкатенация атрибутов ТАБ_НОМЕР и ДАТА_ИЗМЕНЕНИЯ
(рис.5.8), т.к. для каждого сотрудника возможно несколько записей в схеме
ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ.

Рис. 5.8: Сущности модели

Концепции и методы нормализации были разработаны Коддом (Codd),
установившим существование трех типов нормализованных схем, названных в
порядке уменьшения сложности первой, второй и третьей нормальной формой
(соответственно, 1НФ, 2НФ и 3НФ). Рассмотрим, как преобразовывать схемы к
наиболее простой 3НФ. При этом будем представлять схемы в общепринятом
виде, например, для сущностей, приведенных на рис.5.8, имеем:

история_з/пл_карьеры ( таб_номер, дата_изменения.
должность, з/пл)

сотрудник(таб_номер, фамилия, адрес)

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

заказ_на_книгу ( имя_заказчика, дата_заказа, ISBN,
название, автор, количество, цена, сумма_заказа)

Согласно Кодду, любая нормализованная схема (схема без повторяющихся
групп) автоматически находится в 1НФ независимо от того, насколько сложен
ее ключ и какая взаимосвязь может существовать между ее элементами.

Отметим, что в последней схеме атрибуты НАЗВАНИЕ, АВТОР, ЦЕНА могут
быть идентифицированы частью ключа (а именно, ISBN), тогда как атрибут
КОЛИЧЕСТВО зависит от всего ключа (соответственно, полная и частичная
функциональная зависимость от ключа). По определению схема находится в 2НФ
если все ее неключевые атрибуты полностью функционально зависят от ключа.
После избавления от частичной функциональной зависимости последняя схема
будет выглядеть следующим образом:

заказ_на_книгу ( имя заказчика дата_заказа, ISBN.
количество, сумма_заказа)

книга ( ISBN, автор, название, цена)

Заметим, что возможно упростить ситуацию и дальше: атрибуты
КОЛИЧЕСТВО и СУММА_ЗАКАЗА являются взаимно-зависимыми. По определению
схема находится в 3НФ если она находится в 2НФ и никакой из неключевых
атрибутов не является зависимым ни от какого Другого неключевого атрибута.
Поскольку в нашем примере атрибут СУММА_ЗАКАЗА фактически является
избыточным, для получения 3НФ его можно просто удалить.

Иногда для построения 3НФ необходимо выразить зависимость между
неключевыми атрибутами в виде отдельной схемы. Так для сотрудников,
работающих по различным проектам, возможна следующая схема:

сотрудник ( таб_номер, телефон, почасовая_оплата,
N_проекта, дата_окончания)

Очевидно, что данная схема находится в 2НФ. Однако N_ПРОЕКТА и
ДАТА_ОКОНЧАНИЯ являются зависимыми атрибутами. После расщепления схемы
получим 3НФ:

участник_проекта ( таб_номер, телефон, почасовая_оплата,
N_проекта)

проект (N_проекта, дата_окончания)

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

В заключение зафиксируем алгоритм приведения ненормализованных схем в
третью нормальную форму (рис. 5.9).

Ненормализованная схема:

1. Расщепить схему на схемы без - повторяющихся групп.

2. Объявить один или более атрибутов главным ключом (самый малый
ключ.

L--> 1НФ:

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

2. Если это не так, расщепить схему.

L--> 2НФ:

1. Проверить, что все неключевые атрибуты являются
взаимно-независимыми.

2. Исключить избыточные атрибуты или расщепить схему.

L--> 3НФ.

Рис. 5.9: Алгоритм приведения в 3НФ

Этап 2 служит для выявления и определения отношений между сущностями,
а также для идентификации типов отношений. На данном этапе некоторые
отношения могут быть неспецифическими (n*m - многие ко многим). Такие
отношения потребуют дальнейшей детализации на этапе 3.

Определение отношений включает выявление связей, для этого отношение
должно быть проверено в обоих направлениях следующим образом: выбирается
экземпляр одной из сущностей и определяется, сколько различных экземпляров
второй сущности может быть с ним связано, и наоборот. Для примера на рис.
5.8 рассмотрим отношение между сущностями СОТРУДНИК и
ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ. У отдельного сотрудника должность и/или зарплата
может меняться ноль, один или много раз, порождая соответствующее число
экземпляров сущности ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ. С другой стороны, каждый
экземпляр сущности ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ соответствует только одному
конкретному сотруднику. Поэтому между этими двумя сущностями имеется
отношение типа 1*n (один ко многим) со связью "один" на конце отношения у
сущности СОТРУДНИК и со связью "ноль, один или много" на конце у сущности
ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ.

Этап 3 предназначен для разрешения неспецифических (многие ко многим)
отношений. Для этого каждое неспецифическое отношение преобразуется в два
специфических отношения с введением новых (а именно, ассоциативных)
сущностей. Рассмотрим пример на рис. 5.10.

Рис. 5.10: Разрешение неспецифического отношения

Неспецифическое отношение на рис 5.10 указывает, что СТУДЕНТ может
изучать много ПРЕДМЕТОВ, а ПРЕДМЕТ может изучаться многими СТУДЕНТАМИ.
Однако мы не можем определить, какой СТУДЕНТ изучает какой ПРЕДМЕТ, пока
не введем для разрешения этого неспецифического отношения третью
(ассоциативную) сущность ИЗУЧЕНИЕ_ПРЕДМЕТА. Каждый экземпляр введенной
сущности связан с одним СТУДЕНТОМ и с одним ПРЕДМЕТОМ.

Таким образом ассоциативные сущности по своей природе являются
представлениями пар реальных объектов и обычно появляются на этапе 3.



  • Главная
  • Новости
  • Новинки
  • Скрипты
  • Форум
  • Ссылки
  • О сайте




  • Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
     Copyright © 2001-2024
    Реклама на сайте