Как уже упоминалось
ранее, эти модели отражают совокупность объектов реального мира в виде графа
взаимосвязанных информационных объектов. В зависимости от типа графа выделяют
иерархическую или сетевую модели. Исторически эти модели появились раньше, и
в настоящий момент они используются реже, чем более современная реляционная
модель данных. Однако до сих пор существуют системы, работающие на основе этих
моделей, а одна из концепций развития объектно-ориентированных баз данных предполагает
объединение принципов сетевой модели с концепцией реляционной.
Иерархическая
модель данных является наиболее простой среди всех даталогических моделей.
Исторически она появилась первой среди всех даталогических моделей: именно эту
модель поддерживает первая из зарегистрированных промышленных СУБД IMS фирмы
IBM.
Появление
иерархической модели связано с тем, что в реальном мире очень многие связи соответствуют
иерархии, когда один объект выступает как родительский, а с ним может быть связано
множество подчиненных объектов. Иерархия проста и естественна в отображении
взаимосвязи между классами объектов.
Основными информационными единицами в иерархической модели являются: база данных (БД), сегмент и поле.
Например, если в задачах требуется
печатать в документах адрес клиента, но не требуется дополнительного анализа
полного адреса, то есть города, улицы, дома, квартиры, то мы можем принять весь
адрес за элемент данных, и он будет храниться полностью, а пользователь сможет
получить его только как полную строку символов из БД. Если же в наших задачах
существует анализ частей, составляющих адрес, например города, где расположен
клиент, то нам необходимо выделить город как отдельный элемент данных, только
в этом случае пользователь может получить
к нему доступ и выполнить, например, запрос на поиск всех клиентов, которые
проживают в конкретном городе, например в Париже. Однако если пользователю понадобится
и полный адрес клиента, то остальную информацию по адресу также необходимо хранить
в отдельном поле, которое может быть названо, например, Сокращенный адрес. В
этом случае для каждого клиента в БД хранится как Город, так и Сокращенный адрес.
Например, рассматривая тип сегмента, описывающий
сотрудника организации, мы должны выделить те характеристики сотрудника, которые
могут его однозначно идентифицировать в рамках БД предприятия. Если предположить,
что на предприятии могут работать однофамильцы, то, вероятно, наиболее надежным
будет идентифицировать сотрудника по его табельному номеру. Однако если мы будем
строить БД, содержащую описание множества граждан, например нашей страны, то,
скорее всего, нам придется в качестве ключа выбрать совокупность полей, отражающих
его паспортные данные.
В иерархической
модели сегменты объединяются в ориентированный древовидный граф. При этом полагают,
что направленные ребра графа отражают иерархические связи между сегментами:
каждому экземпляру сегмента, стоящему выше по иерархии и соединенному с данным
типом сегмента, соответствует несколько (множество) экземпляров данного (подчиненного)
типа сегмента. Тип сегмента, находящийся на более высоком уровне иерархии, называется
логически исходным по отношению к типам сегментов, соединенным с данным направленными
иерархическими ребрами, которые в свою очередь называются логически подчиненными
по отношению к этому типу сегмента. Иногда исходные сегменты называют сегментами-предками,
а подчиненные сегменты называют сегментами-потомками.
На концептуальном
уровне определяется понятие схемы БД в терминологии иерархической модели.
Каждая физическая БД удовлетворяет следующим иерархическим ограничениям:
Очень важно
понимать различие между сегментом и типом сегмента — оно такое же, как между
типом переменной и самой переменной: сегмент является экземпляром типа сегмента.
Например, у нас может быть тип сегмента Группа (Номер, Староста) и сегменты
этого типа, такие как (4305, Петров Ф. И.) или (383, Кустова Т. С.).
Между экземплярами
сегментов также существуют иерархические связи. Рассмотрим, например, иерархический
граф, представленный на рис. 3.2.
Каждый тип сегмента может иметь множество соответствующих ему экземпляров. Между экземплярами сегментов также существуют иерархические связи.
На рис. 3.3 представлены 2 экземпляра иерархического дерева.
Экземпляры-потомки
одного типа, связанные с одним экземпляром сегмента-предка, называют «близнецами».
Так, для нашего примера экземпляры b1, b2 и bЗ являются «близнецами»
, но экземпляр b4 подчинен другому экземпляру родительского сегмента, и он не
является «близнецом» по отношению к экземплярам b1, b2 и bЗ. Набор
всех экземпляров сегментов, подчиненных одному экземпляру корневого сегмента,
называется физической записью. Количество экземпляров-потомков может
быть разным для разных экземпляров родительских сегментов, поэтому в общем случае
физические записи имеют разную длину. Так, используя принцип линейной записи
иерархических графов, пример на рис 3.3 можно представить в виде двух записей:
Как видно
из нашего примера, физические записи в иерархической модели различаются по длине
и структуре.
В рамках
иерархической модели выделяют языковые средства описания данных (DDL, Data Definition
Language) и средства манипулирования данными (DML, Data Manipulation Language).
Каждая физическая
база описывается набором операторов, определяющих как ее логическую структуру,
так и структуру хранения БД. Описание начинается с оператора определения базы - DBD (Data Base
Definition):
DBD Name = <
имя БД>, ACCESS = < способ доступа>
Способ доступа определяет способ организации взаимосвязи физических записей.
Определено 5 способов доступа:
Далее идет
описание наборов данных, предназначенных для хранения БД:
DATA SET D01 = < имя оператора, определяющего хранимый набор данных>. DEVICE =< устройство хранения БД>, [OVFLW = < имя области переполнения>]
Так как физические записи имеют разную длину, то при модификации данных запись может увеличиться
и превысит исходную длину записи до модификации. В этом случае при определенных
методах хранения может понадобиться дополнительное пространство хранения, где
и будут размещены дополнительные данные. Это пространство и называется областью
переполнения.
После описания
всей физической БД идет описание типов сегментов, ее составляющих, в соответстшш
с иерархией. Описание сегментов всегда начинается с описания корневого сегмента.
Общая схема описания типа сегмента такова:
SEGM NAME =
< имя сегмента>. BYTES =< размер в байтах>.
FREQ = <средняя частота реализаций сегмента под одним исходным>
PARENT = <имя
родительского сегмента>
Параметр
FREQ определяет среднее количество экземпляров данного сегмента, связанных с
одним экземпляром родительского сегмента. Для корневого сегмента это число возможных
экземпляров корневого сегмента.
Для корневого
сегмента параметр PARENT равен 0 (нулю). Далее для каждого сегмента дается описание
полей:
FIELD NAME =
{(<имя поля> [. SEQ].{U M}) | <имя поля> }.
START = < номер байта, с которого начинается значения поля >,
BYTES = <размер поля в байтах>,
TYPE = {X |
Р | С}
Признак SEQ
— задается для ключевого поля, если экземпляры данного сегмента физически упорядочены
в соответствии со значениями данного поля.
Параметр
U задается, если значения ключевого поля уникальны для всех экземпляров данного
сегмента, М — в противном случае. Если поле является ключевым, то его описание
задается в круглых скобках, в противном случае имя поля задается без скобок.
Параметр TYPE определяет тип данных. Для ранних иерархических моделей были определены
только три типа данных: X — шестпадцатеричиый, Р —упакованный десятичный, С
— символьный.
Заканчивается
описание схемы вызовом процедуры генерации:
В системе
может быть несколько физических БД (ФБД), но каждая из них описывается отдельно
своим DBD и ей присваивается уникальное имя. Каждая ФБД содержит только один
корневой сегмент. Совокупность ФБД образует концептуальную модель данных.
При работе
с иерархической моделью каждая программа, пользователь или приложение определяет
свою внешнюю модель. Внешняя модель представляет собой совокупность поддеревьев
для физических баз данных, с которыми работает данный пользователь. Каждый подграф
внешней модели в обязательном порядке должен содержать корневой тип сегмента
соответствующей физической базы данных концептуальной модели.
Представление
внешней модели называется логической базой данных и определяется совокупностью
блоков связи данного приложения с физическими БД, входящими в концептуальную
схему БД. Блок связи — РСВ, program communication bloc — описывает связь
с одной физической БД по следующим правилам:
DBD NAME = <
имя логической БД (подсхемы)> , ACCESS = LOGICAL
DATA SET = LOGICAL.
SEGM NAME = <имя сегмента в подсхеме>,
PARENT =<имя родительского сегмента в подсхеме>,
SOURSE =(Имя
соответствующего сегмента ФБД. имя ФБД)
DBDGEN
FINISH
END
Совокупность
блоков РСВ образует полное внешнее представление данного приложения, называемое
«блоком спецификации программ» (PSB, program specification block).
Рассмотрим
пример иерархической БД.
Наша организация
занимается производством и продажей компьютеров, в рамках производства мы комплектуем
компьютеры из готовых деталей по индивидуальным заказам. У нас существует несколько
базовых моделей, которые мы продаем без предварительных заказов по наличию на
складе. В организации существуют несколько филиалов (рис. 3.4) и несколько складов,
на которых хранятся комплектующие. Нам необходимо вести учет продаваемой продукции.
Рис.
3.4. Физическая БД «Филиалы»
Какие задачи
нам надо решать в ходе разработки приложения?
Для того
чтобы можно было бы принимать заказы на индивидуальные модели, нам понадобится
информация о наличие конкретных деталей на складе, в этом случае нам необходимо
второе дерево — Склады (см. рис. 3.5).
Рис.
3.5. Физическая модель «Склады»
Для доступа
к базе данных у пользователя должна быть сформирована специальная среда окружения,
поддерживающая в явном виде имеющиеся навигационные операции. Для этого в ней
должны храниться:
Язык манипулирования
данными в иерархической модели поддерживает в явном виде навигационные операции.
Эти операции связаны с перемещением указателя, который определяет текущий экземпляр
конкретного сегмента.
Все операторы
в языке манипулирования данными можно разделить на 3 группы. Первую группу составляют
операторы поиска данных.
Синтаксис:
GET UNIQUE <имя
сегмента> WHERE <список поиска>;
список поиска
состоит из последовательности условий вида:
<имя сегмента>.<имя
поля>ОС <constant или имя другого поля данного сегмента или имя переменной>:
ОС — операция
сравнения;
условия могут
быть соединены логическими операциями И и ИЛИ {& , V}.
Назначение:
Получить
единственное значение.
Пример:
Найти типовую
модель стоимостью не более $600, которая существует не менее чем в 10 экземплярах.
GET UNIQUE ТИПОВЫЕ МОДЕЛИ
WHERE Типовые модели.Стоимость <= $600
AND Типовые модели,Количество
на складе >= 10
Данная команда
всегда ищет с начала БД и останавливается, найдя первый экземпляр сегмента,
удовлетворяющий условиям поиска.
Синтаксис:
GET NEXT <имя сегмента> WHERE <список аргументов поиска>
Назначение:
Получить следующий экземпляр сегмента для тех же условии.
Пример:
Напечатать
полный список заказов стоимостью не менее $500.
GET UNIQUE ИНДИВИДУАЛЬНЫЕ МОДЕЛИ
WHERE Индивидуальные модели.Стоимость >- $500
WHILE NOT EAIL
(пока не конец поиска) DO
PRINT № заказа.
Стоимость, Количество
GET NEXT ИНДИВИДУАЛЬНЫЕ МОДЕЛИ
END
Синтаксис:
GET NEXT <имя сегмента> WITHIN PARENT [ where <дополн.условия>]
Назначение:
Получить следующий для того же исходного.
Пример:
Получить
перечень винчестеров, имеющихся на складе номер 1, в количестве не менее 10
с объемом 10 Гбайт.
GET UNIQUE СКЛАД
WHERE Склад.Номер = 1
GET NEXT ИЗДЕЛИЕ WITHIN PARENT
WHERE Изделие.Наименование
= "Винчестер"
GET NEXT ХАРАКТЕРИСТИКИ
WITHIN PARENT
WHERE ХАРАКТЕРИСТИКИ.Параметр
= 10 AND
ХАРАКТЕРИСТИКИ.Единицы
Измерения = Гб AND
ХАРАКТЕРИСТИКИ.Величина
> 10
While Not Fail
(пока поиск не завершен) DO
Get Next Within
Parent
end
Синтаксис:
GET HOLD UNIQUE
<имя сегмента> WHERE <список поиска>
Синтаксис:
GET HOLD NEXT
[WHERE <дополнительные условия>]
Синтаксис:
GET HOLD NEXT
WITHIN PARENT [ where <дополн.условия>]
Операторы
модификации данных
Синтаксис:
DELETE
Эта команда
не имеет параметров. Почему? Потому что операции модификации действуют на экземпляр
сегмента, найденный командами поиска с удержанием. А он всегда единственный
текущий найденный и удерживаемый для модификации экземпляр конкретного сегмента.
Поэтому при выполнении команды удаления будет удален именно этот экземпляр сегмента.
Синтаксис:
UPDATE
Как же происходит
обновление, если мы и в этой команде не задаем никаких параметров. СУБД берет
данные из рабочей области пользователя, где в шаблонах записей соответствующих
внутренних переменных находятся значения полей каждого сегмента внешней модели,
с которой работает данный пользователь. Именно этими значениями и обновляется
текущий экземпляр сегмента. Значит, перед тем как выполнить операции модификации
UPDATE, необходимо присвоить соответствующим переменным новые значения.
Ввести новый
экземпляр сегмента.
INSERT <имя
сегмента>
Эта команда
позволяет ввести новый экземпляр сегмента, имя которого определено в параметре
команды. Если мы вводим данные в сегмент, который является подчиненным некоторому
родительскому экземпляру сегмента, то он будет внесен в БД и физически подключен
к тому экземпляру родительского сегмента, который в данный момент является текущим.
Как видим,
набор операций поиска и манипулирования данными в иерархической БД невелик,
но он вполне достаточен для получения доступа к любому экземпляру любого сегмента
БД. Однако следует отметить, что способ доступа, который применяется в данной
модели, связан с последовательным перемещением от одного экземпляра сегмента
к другому. Такой способ напоминает движение летательного аппарата или корабля
по заданным координатам и называется навигационным.
Стандарт
сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference
of Data System Languages), которая определила базовые понятия модели и формальный
язык описания.
Базовыми
объектами модели являются:
Агрегат данных
имеет имя, и в системе допустимо обращение к агрегату по имени. Агрегат типа
вектор соответствует линейному набору элементов данных. Например, агрегат Адрес
может быть представлен следующим образом:
Адрес |
|||
Город |
Улица |
дом |
квартира |
Агрегат типа
повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат
Зарплата соответствует типу повторяющаяся группа с числом повторений 12.
Зарплата |
|
Месяц |
Сумма |
|
|
Записью называется
совокупность агрегатов или элементов данных, моделирующая некоторый класс объектов
реального мира. Понятие записи соответствует понятию «сегмент» в
иерархической модели. Для записи, так же как и для сегмента, вводятся понятия
типа записи и экземпляра записи.
Следующим базовым понятием в сетевой модели является понятие «Набор».
Набор фактически
отражает иерархическую связь между двумя типами записей. Родительский тип записи
в данном наборе называется владельцем набора, а дочерний тип записи — членом
того же набора.
Для любых
двух типов записей может быть задано любое количество наборов, которые их связывают.
Фактически наличие подобных возможностей позволяет промоделировать отношение
«многие-ко-многим» между двумя объектами реального мира, что выгодно
отличает сетевую модель от иерархической. В рамках набора возможен последовательный
просмотр экземпляров членов набора, связанных с одним экземпляром владельца
набора.
Между двумя
типами записей может быть определено любое количество наборов: например, можно
построить два взаимосвязанных набора. Существенным ограничением набора является
то, что один и тот же тип записи не может быть одновременно владельцем и членом
набора.
В качестве
примера рассмотрим таблицу, на основе которой организуем два набора и определим
связь между ними:
Преподаватель |
Группа |
День недели |
№ пары |
Аудитория |
Дисциплина |
||
Иванов |
4306 |
Понедельник |
1 |
22-13 |
КИД |
||
Иванов |
4307 |
Понедельник |
2 |
22-13 |
КИД |
||
Карпова |
4307 |
Вторник |
2 |
22-14 |
БЗ и ЭС |
||
Карпова |
4309 |
Вторник |
4 |
22-14 |
БЗ и ЭС |
||
Карпова |
84305 |
Вторник |
1 |
22-14 |
БД |
||
Смирнов |
4306 |
Вторник |
3 |
23-07 |
ГВП |
||
Смирнов |
4309 |
Вторник |
4 |
23-07 |
ГВП |
||
Экземпляров
набора Ведет занятия будет 3 (по числу преподавателей), экземпляром набора Занимается
у будет 4 (по числу групп). На рис. 3.6 представлены взаимосвязи экземпляров
данных наборов.
Рис.
3.6. Пример взаимосвязи экземпляров двух наборов
Среди всех наборов выделяют специальный тип набора, называемый «Сингулярным набором», владельцем которого формально определена вся система. Сингулярный набор изображается в виде входящей стрелки, которая имеет собственно имя набора и имя члена набора, но у которой не определен тип записи «Владелец набора». Например, сингулярный набор М.
Сингулярные
наборы позволяют обеспечить доступ к экземплярам отдельных типов данных, поэтому
если в задаче алгоритм обработки информации предполагает обеспечение произвольного
доступа к некоторому типу записи, то для поддержки этой возможности необходимо
ввести соответствующий сингулярный набор.
В общем случае
сетевая база данных представляет совокупность взаимосвязанных наборов, которые
образуют на концептуальном уровне некоторый граф.
Язык описания
данных в сетевой модели имеет несколько разделов:
SCHEMA IS <Имя
БД>.
AREA NAME IS
<Имя физической области>.
RECORD NAME
IS <Имя записи (уникапьное)>
Для каждой
записи определяется способ размещения экземпляров записи данного типа:
LOCATION MODE
IS'{DIRECT (напрямую)
CALC <Имя
программы> USING <[Список пер.>]
DUPLICATE ARE
[NOT] ALLOWED
VIA <Имя на6ора> SET (рядом с записями владельца)
SYSTEM (решать
будет система)}
Каждый тип
записи должен быть приписан к некоторой физической области размещения:
WITHIN <Имя области размещения> AREA
После описания
записи в целом идет описание внутренней структуры:
<Имя уровня>
<Имя данного> <Шаблон> <Тип>
Номер уровня
определяет уровень вложенности при описании элементов и агрегатов данных. Первый
уровень — сама запись. Поэтому элементы или агрегаты данных имеют уровень начиная
со второго. Если данное соответствует агрегату, то любая его составляющая добавляет
один уровень вложенности.
Если агрегат
является вектором, то он описывается как <Номер уровня> <Имя агрегата>.<Номер
уровня> <Имя 1-й сост.> а если — повторяющейся группой, то следующим
образом:
<Номер уровня>
<Имя агрегата>.OCCURS <N> TIMES
где N — среднее
количество элементов в группе.
Описание
набора и порядка включения членов в него выглядит следующим образом:
SET NAME IS
<Имя набора>:
OWNER IS (<Имя
владельца> SYSTEM).
Далее указывается
порядок включения новых экземпляров члена данного набора в экземпляр набора:
ORDER PERMANENT
INSERTION IS {SORTED | NEXT | PREV | LAST FIRST}
После этого
описывается член набора с указанием способа включения и способа исключения экземпляра
— члена набора из экземпляра набора.
MEMBER IS <Имя
члена набора> {AUTOMATIC | MANUAL} {MANDATORY OPTIONAL} KEY IS (ACCENDING
| DESCENDING) <Имя элемента данных>
При автоматическом
включении каждый новый; экземпляр члена набора автоматически попадает в текущий
экземпляр набора в соответствии с заданным ранее Порядком включения. При ручном
способе экземпляр члена набора сначала попадает в БД, а только потом командой
CONNECT может быть включен в конкретный экземпляр набора.
Если задан
способ исключения MANDATORY, то экземпляр записи, исключаемый из набора, автоматически
исключается и из базы данных. Иначе просто разрываются связи.
Внешняя
модель при сетевой организации данных поддерживается путем описания части
общего связного графа.
Все операции
манипулирования данными в сетевой модели делятся на навигационные операции
и операции модификации.
Навигационные
операции осуществляют перемещение по БД путем прохождения по связям, которые
поддерживаются в схеме БД. В этом случае результатом является новый единичный
объект, который получает статус текущего объекта.
Операции
модификации осуществляют как добавление новых экземпляров отдельных типов записей,
так и экземпляров новых наборов, удаление экземпляров записей и наборов, модификацию
отдельных составляющих внутри конкретных экземпляров записей. Средства модификации
данных сведены в табл. 3.1:
Таблица
3.1. Операторы манипулирования данными в сетевой модели
Операция |
Назначение |
||
READY |
Обеспечение
доступа данного процесса или пользователя к БД (сходна по смыслу с
операцией открытия файла) |
||
FINISH |
Окончание работы
с БД |
||
FIND |
Группа операций,
устанавливающих указатель найденного объекта на текущий объект |
||
GET |
Передача найденного
объекта в рабочую область. Допустима только после FIND |
||
STORE |
Помещение в
БД записи, .сформированной в рабочей области |
||
CONNECT |
Включение текущей
записи в текущий экземпляр набора |
||
DISCONNECT |
Исключение текущей
записи из текущего экземпляра набора |
||
MODIFY |
Обновление текущей
записи данными из рабочей области пользователя |
||
ERASE |
Удаление экземпляра
текущей записи |
||
В рабочей
области пользователя хранятся шаблоны записей, программные переменные и три
типа указателей текущего состояния:
На рис. 3.7
представлена концептуальная модель торгово-посреднической организации.
Рис.
3.7. Схема БД «Торговая фирма»
При необходимости
возможно описание элементов данных, которые не принадлежат непосредственно данной
записи, но при ее обработке часто используются. Для этого используется тип VIRTUAL
с обязательным указанием источника данного элемента данных.
RECORD Цены
02 Цена TYPE
REAL
02 Товар VIRTUAL
SOURCE IS Товары.НаименованиеТовара
OF OWNER OF
Товар-Цены SET
Наиболее
интересна операция поиска (FIND), так как именно она отражает суть навигационных
методов, применяемых в сетевой модели. Всего существует семь типов операций
поиска:
FIND <Имя записи>
RECORD BY CALC KEY <Имя параметра>
FIND DUPLICATE <Имя
записи> RECORD BY CALC KEY
FIND OWNER OF CURRENT
<Имя набора> SET
FIND (FIRST | NEXT) <Имя
записи> RECORD IN CURRENT <Имя набора> SET
FIND [DUPLICATE] <Имя
записи> RECORD IN CURRENT <Имя набора> SET USING <Список полей>
FIND CURRENT OF <Имя
набора> SET
FIND CURRENT OF <Имя
записи> RECORD
Например,
алгоритм и программа печати заказов, сделанных Петровым, будут выглядеть так:
ФИО = "Петров" FIND Люди RECORD BY CALC KEY FIND FIRST Заказы RECORD IN CURRENT Люди-Заказы SET WHILE NOT FAIL DO FIND OWNER OF CURRENT Товары-Заказы SET GET Товары PRINT НаимТовара FIND NEXT Заказы RECORD IN CURRENT Люди-Заказы SET END