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

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

В рамках иерархической модели выделяют языковые средства описания данных (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 =, [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. Физическая модель «Склады»


yazikovie-sredstva-podmeni-ponyatij.html
yazikovie-znaniya-i-naviki-polzovaniya-imi.html
    PR.RU™