Иерархическая субд

Главное о базах данных

• Чаще все­го базы дан­ных напо­ми­на­ют таб­ли­цы: в них одно­му пара­мет­ру соот­вет­ству­ет один набор дан­ных. Напри­мер, один кли­ент — одно имя, один теле­фон, один адрес.
• Такие «таб­лич­ные» базы дан­ных назы­ва­ют­ся реляционными.
• Что­бы стро­ить слож­ные свя­зи, раз­ные таб­ли­цы в реля­ци­он­ных базах мож­но свя­зы­вать меж­ду собой: ста­вить ссылки.
• Реля­ци­он­ная база — не един­ствен­ный спо­соб хра­не­ния дан­ных. Есть ситу­а­ции, когда нам нуж­на боль­шая гиб­кость в хранении.
• Быва­ют сете­вые базы дан­ных: когда нуж­но хра­нить мно­го свя­зей меж­ду мно­же­ством объ­ек­тов. Напри­мер, ката­лог филь­мов: в одном филь­ме может участ­во­вать мно­го чело­век, а каж­дый из них может участ­во­вать во мно­же­стве фильмов.
• Быва­ют иерар­хи­че­ские базы, или «дере­вья». При­мер — наша фай­ло­вая система.
• Какую выбрать базу — зави­сит от зада­чи. Одна база не луч­ше дру­гой, но они могут быть более или менее под­хо­дя­щи­ми для опре­де­лён­ных задач.

Текст и иллю­стра­ции:Миша Поля­нин
Редак­тор:Мак­сим Ильяхов
Кор­рек­тор:Ира Михе­е­ва
Иллю­стра­тор:Даня Бер­ков­ский
Вёрст­ка:Маша Дро­но­ва
Достав­ка:Олег Веш­кур­цев
Что-то дела­ет рука­ми:Паша Федо­ров
Во сла­ву:Прак­ти­ку­ма

Иерархические

Иерар­хия — это когда есть выше­сто­я­щий, а есть его под­чи­нён­ные, кто ниже. У них могут быть свои под­чи­нён­ные и так далее. Мы уже каса­лись такой моде­ли, когда гово­ри­ли про дере­вья и бустинг.

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

Вид­но, что на дис­ке C: есть мно­го папок: Dropbox, eSupport, GDrive и все те, кото­рые не поме­сти­лись на экране.

Внут­ри пап­ки GDrive есть ###_Inbox и #_Альбатрос, а внут­ри #_Альбатроса — десят­ки дру­гих папок. Если мы посмот­рим на скрин­шот, то уви­дим, то долж­ност­ная инструк­ция бух­гал­те­ра лежит с осталь­ны­ми фай­ла­ми внут­ри пап­ки Долж­ност­ные и охра­на тру­да, кото­рая лежит внут­ри пап­ки Инструкции.

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

Проектирование баз данных

Проектирование — самая трудная задача при работе с данными. Оно заключается не только в том, чтобы создать таблицу, указав наименование столбцов и тип данных. Это гораздо более сложный процесс, требующий специализированных знаний и умений. Говоря о типах баз данных в столбцах, подразумевается, например, способ их записи, который бывает символьный (строковый), числовой, календарный, NULL.

Основная сложность заключается в том, что мощность наших компьютеров ограничена. И пока данных мало, таблиц и строк тоже немного, поэтому машина обрабатывает информацию достаточно быстро. Но с течением времени информации становится всё больше, что может стать причиной снижения быстродействия. Работа машины будет замедляться, времени на обработку запросов потребуется всё больше. Добавить новую запись в таблицу не станет проблемой для реляционной СУБД, а вот выборка данных может превратиться в весьма ресурсоёмкую операцию. Хотя, многое будет зависеть и от настроек СУБД.

Основные понятия

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.

Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей.

К каждой записи базы данных существует только один (иерархический) путь от корневой записи.

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

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

Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.

• Атрибут (элемент данных) — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
• Запись — именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов
• Групповое отношение — иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.

6) Хранилища данных и модели их представления

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

Основные модели представления данных в хранилищах данных:

• 1. Реляционная
• 2. Многомерная
• 3. Гибридная
• 4. Виртуальная

Реляционная модель хранилищ данных

В основе реляционных хранилищ данных лежит разделение данных на две группы – измерения и факты.
Измерения – это категориальные атрибуты, наименования и свойства объектов, участвующих в некотором бизнес-процессе.
Примеры измерений: наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т. д.Измерения качественно описывают исследуемый бизнес-процесс.Факты – это непрерывные по своему характеру данные (могут принимать бесконечное множество значений).
Примеры фактов: цена товара или изделия, их количество, сумма продаж или закупок, зарплата сотрудников, сумма кредита и т. д.
Факты количественно описывают бизнес-процесс.

рис Схема построения реляционного хранилища данных «звезда»

Центральной является таблица фактов (Fact table), с которой связаны таблицы измерений (Dimension tables).

Преимущества схемы «звезда»:

• простота и логическая прозрачность модели
• более простая процедура пополнения измерений, поскольку
• приходится работать только с одной таблицей

Недостатки схемы «звезда»:

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

Рис Схема построения реляционного хранилища данных «снежинка» (модификация схемы «звезда»)

Основное функциональное отличие схемы «снежинка» от схемы «звезда» – это возможность работы с иерархическими уровнями, определяющими
степень детализации данных.Преимущества схемы «снежинка»:

• она ближе к представлению данных в многомерной модели
• процедура загрузки из РХД в многомерные структуры более
• эффективна и проста, поскольку загрузка производится из отдельных таблиц
• намного ниже вероятность появления ошибок, несоответствия данных
• большая, по сравнению со схемой «звезда», компактность
• представления данных, поскольку все значения измерений упоминаются только один раз

Недостатки схемы «снежинка»:

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

Преимущества реляционных хранилищ данных:

• Практически неограниченный объем хранимых данных
• Поскольку реляционные СУБД лежат в основе построения многих систем оперативной обработки (OLTP), которые обычно являются главными источниками данных для ХД, использование реляционной модели позволяет упростить процедуру загрузки и интеграции данных в хранилище
• При добавлении новых измерений данных нет необходимости выполнять сложную физическую реорганизацию хранилища, в отличие, например, от многомерных ХД
• Обеспечиваются высокий уровень защиты данных и широкие возможности разграничения прав доступа

Главный недостаток реляционных хранилищ данных:

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

Ключи в БД

Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

Суррогатный ключ — это дополнительное поле в БД. Обычно это уникальный id (порядковый номер записи), хотя принцип может быть и другой, главное — уникальность.

Вносим первичные ключи в наши таблицы:

Заметьте, что каждая запись в таблице уникальна. Осталось лишь установить соответствие между сообщениями и темами, используя первичные ключи. Добавляем в таблицу с сообщениями ещё одно поле:

Теперь становится ясно, что сообщение id=2 относится к теме «О рыбалке» (id=4), которая создана Васей, а остальные принадлежат теме «О рыбалке», созданной Кириллом (id=1). Такое поле будет называться внешний ключ (FK, foreign key). При этом каждое значение данного поля сопоставляется с каким-либо первичным ключом из таблицы «Темы». В результате устанавливается однозначное соответствие между темами и сообщениями.

Ещё момент: допустим, добавляется новый пользователь по имени Вася.

Как узнать, какой же из «Васей» оставил сообщение? Для этого поля «Автор» в наших таблицах «Сообщения» и «Темы» мы тоже сделаем внешними ключами:

Итак, наша база данных фактически готова. Схематично она выглядит так:

В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

Сетевая модель данных

Стандарт
сетевой модели впервые был определен в 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. Пример взаимосвязи экземпляров двух наборов

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

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

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

§3.3. Иерархическая модель данных§3.4. Сетевая модель данных

Иерархическая базы данных «Доменная система имен»

Еще одним примером иерархической базы данных является доменная система имен подключенных к Интернету компьютеров. На верхнем уровне находится табличная база данных, содержащая перечень доменов верхнего уровня (всего 269 домена), из которых 12 — административные, а остальные 257 — географические. Наиболее многочисленным доменом (данные на январь 2008 года) является административный домен net (около 190 миллионов серверов), а некоторых доменах (например, в географическом домене zr) до сих пор не зарегистрировано ни одного сервера.

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

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

Рис. 3.3. Иерархическая база данных Доменная система имен

База данных «Доменная система имен» должна содержать записи обо всех компьютерах, подключенных к Интернету, т. е. более 500 миллионов записей. Размещение такой огромной базы данных на одном компьютере сделало бы поиск информации очень медленным и неэффективным. Решение этой проблемы было найдено путем размещения отдельных составных частей базы данных на различных DNS- серверах. Таким образом, иерархическая база данных «Доменная система имен» является распределенной базой данных.

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

Сначала наш запрос, содержащий доменное имя сервера www.microsoft.com, будет оправлен на DNS-сервер нашего провайдера, который переадресует его на DNS-сервер самого верхнего уровня базы данных. В таблице первого уровня будет найден интересующий нас домен сот и запрос будет адресован на DNS-сервер второго уровня, который содержит перечень доменов второго уровня, зарегистрированных в домене сот.

В таблице второго уровня будет найден домен microsoft и запрос будет переадресован на DNS-сервер третьего уровня. В таблице третьего уровня будет найдена запись, соответствующая доменному имени, содержавшемуся в запросе. Поиск информации в базе данных «Доменная система имен» будет завершен и начнется поиск компьютера в сети по его IР-адресу.

Следующая страница §3.3. Иерархические базы данных. Контрольные вопросы

Cкачать материалы урока

Операторы поиска данных

Синтаксис:

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

Назначение:

Получить
следующий для того же исходного.

Пример:

Получить
перечень винчестеров, имеющихся на складе номер 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

7 многомерная модель

В основе многомерного представления данных лежит их разделение на две группы – измерения и факты
Многомерная модель данных реализуется с помощью многомерных кубов

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

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

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

В ячейке 1 будут располагаться факты, относящиеся к продаже цемента ООО «Спецстрой» 3 ноября, в ячейке 2 – к продаже плит ЗАО « » 6
ноября, а в ячейке 3 – к продаже плит ООО «Спецстрой» 4 ноября.

Рис Многомерный взгляд на измерения Дата, Товар и Покупатель

Выделенный сегмент будет содержать информацию о том, сколько плит, на какую сумму и по какой цене приобрела фирма ЗАО «Строитель» 3 ноября.

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

Преимущества многомерного подхода:

• Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД
• Возможности построения аналитических использующей МХД, более широки запросов
• В некоторых случаях использование многомерной значительно уменьшить продолжительность поиска в выполнение аналитических запросов практически в времени к системе, модели позволяет МХД, обеспечивая режиме реального

Недостатки использования многомерной модели:

• Для ее реализации требуется больший объем памяти
• Многомерная структура труднее поддается модификации

Системы, поддерживающие многомерную модель данных:
Essbase, Media Multi-matrix, Oracle Express Server, Cache.
Многие программные продукты позволяют одновременно работать с
многомерными и с реляционными БД.

Пример модели

Рассмотрим следующую модель данных предприятия (смотреть рисунок ниже): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.

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

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры : заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК(НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. (b)).

Из этого примера видны недостатки иерархических БД:

• Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.
• Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ — дочерней (рис. (c)). Таким образом, мы опять вынуждены дублировать информацию.

Язык описания данных иерархической модели

В рамках
иерархической модели выделяют языковые средства описания данных (DDL, Data Definition
Language) и средства манипулирования данными (DML, Data Manipulation Language).

Каждая физическая
база описывается набором операторов, определяющих как ее логическую структуру,
так и структуру хранения БД. Описание начинается с оператора определения базы — DBD (Data Base
Definition):

DBD Name = <
имя БД>, ACCESS = < способ доступа>

Способ доступа
определяет способ организации взаимосвязи физических записей.

Определено 5 способов доступа:

HSAM
—
hierarchical sequential access method (иерархически
последовательный метод),

HISAM
—
hierarchical index sequential access method
(иерархически индексно-последовательный метод),

EDAM
—
hierarchical direct access method (иерархически прямой метод),

HID AM
—
hierarchical index direct access method (иерархически индексно-прямой метод),

INDEX
—
индексный метод.

Далее идет
описание наборов данных, предназначенных для хранения БД:

DATA SET D01 = < имя оператора, определяющего хранимый набор данных>.
DEVICE =< устройство хранения БД>, 

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

После описания
всей физической БД идет описание типов сегментов, ее составляющих, в соответстшш
с иерархией. Описание сегментов всегда начинается с описания корневого сегмента.
Общая схема описания типа сегмента такова:

SEGM NAME =
< имя сегмента>. BYTES =< размер в байтах>.

FREQ = <средняя
частота реализаций сегмента под одним исходным>

PARENT = <имя
родительского сегмента>

Параметр
FREQ определяет среднее количество экземпляров данного сегмента, связанных с
одним экземпляром родительского сегмента. Для корневого сегмента это число возможных
экземпляров корневого сегмента.

Для корневого
сегмента параметр PARENT равен 0 (нулю). Далее для каждого сегмента дается описание
полей:

FIELD NAME =
{(<имя поля> .{U M}) | <имя поля> }.

START = <
номер байта, с которого начинается значения поля >,

BYTES = <размер
поля в байтах>,

TYPE = {X |
Р | С}

Признак SEQ
— задается для ключевого поля, если экземпляры данного сегмента физически упорядочены
в соответствии со значениями данного поля.

Параметр
U задается, если значения ключевого поля уникальны для всех экземпляров данного
сегмента, М — в противном случае. Если поле является ключевым, то его описание
задается в круглых скобках, в противном случае имя поля задается без скобок.
Параметр TYPE определяет тип данных. Для ранних иерархических моделей были определены
только три типа данных: X — шестпадцатеричиый, Р —упакованный десятичный, С
— символьный.

Заканчивается
описание схемы вызовом процедуры генерации:

• DBDGEN — указывает
  на конец последовательности управляющих операторов описания БД;
• FINISH — устанавливает
  ненулевой код завершения при обнаружении ошибки;
• END — конец.

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