2.3. Проблемы проектирования субд - ориентировного концептуального представления данных

Как было сказано в разделе 2.1 на данном этапе определяется модель описания данных и проектируется ориентированное на нее концептуальное представление. При этом возможно использование двух подходов.

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

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

Для описания данных на логическом уровне используются три “замечательные” модели данных: сетевая, иерархическая и реляционная (рис.6).

Сетевая модель данных . В основе сетевой модели лежит понятие сети, изображаемой в виде плоского ориентированного графа, в узлах которого размещаются сущности, а связи между ними изображаются дугами. В сетевой модели могут быть реализованы все типы связей, в том числе и М:М. Это значит, что каждый исходный узел сети может иметь несколько порожденных узлов -”сыновей”, а каждый порожденный - несколько исходных узлов -”отцов”. Такие сложные сети затрудняют организацию данных и управление ими и обычно заменяются более простыми, не сложнее 1:М или М:1. В настоящее время известны различные способы упрощения сложных связей в сети [2],[5], наиболее распространенным из которых является введение составных атрибутов. Например, как будет подробнее описано в примере 3, упрощение сложной связи между сущностями ПОСТАВЩИК и ДЕТАЛЬ (см. рис.1) с первичными ключами НОМЕР_ПОСТАВЩИКА (PN) и НОМЕР_ДЕТАЛИ (DN) соответственно достигается введением новой сущности ПОСТАВКА с составным первичным ключом PN+DN.

Иерархическая модель данных представляется в виде иерархии - “леса” независимых деревьев. Деревья реализуют связи, не сложнее 1:М. Это значит, что каждый исходный узел дерева может иметь несколько порожденных узлов, а каждый порожденный узел - только один исходный. Поскольку иерархия является частным случаем сети, можно легко показать, что сетевая модель может быть сведена к иерархической введением избыточности в данные (рис.7).

Реляционная модель описывает данные в виде одного или нескольких отношений или таблиц (relation).

Отношение R можно определить как множество кортежей, каждый из которых представляет собой вектор-строку v = (v₁, v₂, ... , v_k) отношения R. Элементы v_I кортежа v выбираются из определенных доменов, v_I  D_I .

Каждый домен D_I представляет собой некоторое множество значений. Так, доменами могут быть множества целых или действительных чисел, цепочек символов заданной длины, множество значений { 0,1} и пр.

Все кортежи отношения R имеют одинаковую длину k , которая называется арностью отношения.

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

Список имен атрибутов отношения называется схемой отношения. Так, отношение по имени R с атрибутами A₁, A₂, ... , A_k ,будем записывать в виде схемы: R(A₁, A₂, ... , A_k) или R = A₁, A₂, ... , A_k или R = A₁ . . . A_k .

Совокупность схем отношений, используемых для представления реляционной модели данных, называется схемой реляционной БД, а текущие значения этих отношений (экземпляры схем отношений) - реляционной БД.

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

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

Какую модель выбрать? Рассмотрим достоинства и недостатки каждой из них на качественном уровне для простого примера реальных данных.

Пример 3. Дадим реализацию концептуальной схемы данных, полученной в примере 2, в виде трех “замечательных” моделей данных [1].

Реляционная реализация может быть дана, по крайней мере, двумя способами:

1) в виде одного отношения

Postavka (PN, PIM , ST , GOROD , DN , DIM , ZVET , KOL )

П1 Иванов 20 Москва Д1 болт синий 10

П1 Иванов 20 Москва Д2 гайка красная 10

П2 Петров 40 Самара Д1 болт синий 30

П2 Петров 40 Самара Д2 гайка красная 40

П3 Кротов 10 Москва Д2 гайка красная 20

2) в виде трех отношений

Post ( PN , PIM , ST , GOROD), Det ( DN , DIM , ZVET ), Post_det(PN, DN, KOL)

П1 Иванов 20 Москва Д1 болт синий П1 Д1 10

П2 Петров 40 Самара Д2 гайка красная П1 Д2 10

П3 Кротов 10 Москва П2 Д1 30

П2 Д2 40

П3 Д2 20

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

Сеть Дерево Таблицы

A A ABDR

ABE

  ACD

B C B C ACE

ACM

ACN

D E M N D E D E M N

A,B,C,D -

избыточные

элементы

R R

избыточные элементы

Рис.7. Трансформация моделей данных

Иерархическая реализация может быть дана в виде “леса” из двух деревьев, сетевая - в виде сети, связующим элементом в которой является значение атрибута KOL (рис.8).

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

• способ реализации симметричных запросов;

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

Способ реализации симметричных запросов . Будем называть симметричными запросы вида:

1) DN?  PN = “П2”

2) PN?  DN = “Д1”

Для реляционной реализации ответы на оба запроса могут быть получены по одному алгоритму, а именно:

сканируя строки отношения Post_det , выделяем те, которые удовлетворяют условию запроса ( PN = “П2” для первого и DN = “Д1” для второго), и читаем значения результирующих атрибутов (DN для первого и PN для второго запроса). Таким образом, можно говорить о симметричном способе реализации симметричных запросов для реляционной модели данных.

В иерархической модели запрос 2 реализуется очень просто. Для получения ответа на него надо найти дерево, в корневой вершине которого находится деталь DN = “Д1” и прочитать все концевые вершины этого дерева. Запрос 1 реализуется гораздо сложнее, так как ответ на него может быть получен только после прочтения концевых вершин всех деревьев. В худшем случае это может привести к просмотру всей БД.

В сетевой модели оба запроса реализуются почти симметрично. Рассмотрим для примера процедуру получения ответа на запрос 1. От поставщика П2 идем по дуге к количеству 30. Далее по верхней дуге от количества 30 находим деталь Д1. Теперь по нижней дуге от количества 30 идем к количеству 40, по вехней дуге - от 40 к 20 и по вехней дуге находим деталь Д2. Получаем ответ: Д1 и Д2. Аналогично находим ответ на запрос 2.