Иерархическая модель данных

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

В рамках
иерархической модели выделяют языковые средства описания данных (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 и ей присваивается уникальное имя. Каждая ФБД содержит только один
корневой сегмент. Совокупность ФБД образует концептуальную модель данных.

Объектно-ориентированные субд

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

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

Структура

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

инкапсуляция — каждый объект обладает некоторым внутренним состоянием (хранит внутри себя запись данных), а также набором методов — процедур, с помощью которых (и только таким образом) можно получить доступ к данным, определяющим внутреннее состояние объекта, или изменить их. Таким образом, объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира;

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

полиморфизм — различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы.

Целостность данных

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

автоматическое поддержание отношений наследования возможность объявить некоторые поля данных и методы объекта как «скрытые», не видимые для других объектов; такие поля и методы используются только методами самого объекта создание процедур контроля целостности внутри объекта

Средства манипулирования данными

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

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

В то же время, ОО-модели присущ и ряд недостатков:

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

вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами — расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

Структура реляционной модели данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархическая модель.

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

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

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60–х годов. В начале 70–х годов была предложена реляционная модель данных.

Использование модели данных при работе с БД неизбежно по нескольким причинам. Во–первых, модель дает общий язык пользователям, работающим с данными. Во–вторых, модель может обеспечить предсказуемость результатов работы с данными. Становится возможным объяснить пользователю, почему он получил конкретный результат при просмотре или изменении данных, и наоборот, работающий с базой может предвидеть, какого сорта он получит результат.

Заболели и отстали по какому-то предмету? Не можете справиться сами? Не беда! Теперь есть уникальный сайт, на котором можно подобрать репетитора в любом районе —  Заходите! Ваш репетитор ждет Вас!

Иерархическая модель данных

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

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

Объекты, связанные иерархическими отношениями, образуют ориентированный граф.

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

Язык описания
данных в сетевой модели имеет несколько разделов:

• описание базы данных
  — области размещения;
• описания записей —
  элементов и агрегатов (каждого в отдельности);
• описания наборов (каждого
  в отдельности).

SCHEMA IS <Имя
БД>.

AREA NAME IS
<Имя физической области>.

RECORD NAME
IS <Имя записи (уникапьное)>

Для каждой
записи определяется способ размещения экземпляров записи данного типа:

LOCATION MODE
IS'{DIRECT (напрямую)

CALC <Имя
программы> USING <

DUPLICATE ARE
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, то экземпляр записи, исключаемый из набора, автоматически
исключается и из базы данных. Иначе просто разрываются связи.

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

История

Иерархическая структура была разработана IBM в 1960-х годах и использовалась в ранних СУБД для мэйнфреймов . Отношения записей образуют древовидную модель. Эта структура проста, но негибка, поскольку отношения ограничиваются отношениями «один ко многим». Система IBM Information Management (IMS) и RDM Mobile являются примерами иерархической системы баз данных с несколькими иерархий над теми же данными. RDM Mobile — это недавно разработанная встроенная база данных для мобильной компьютерной системы.

Иерархическая модель данных потеряли тракция Кодда «s реляционную модель стала стандартом де — факто используется практически во всех системах управления базами данных господствующих. Реализация иерархической модели в реляционной базе данных впервые обсуждалась в опубликованной форме в 1992 году (см. Также модель вложенных множеств ). Схемы иерархической организации данных вновь появились с появлением XML в конце 1990-х (см. Также базу данных XML ). Иерархическая структура сегодня используется в основном для хранения географической информации и файловых систем.

В настоящее время иерархические базы данных по-прежнему широко используются, особенно в приложениях, требующих очень высокой производительности и доступности, таких как банковское дело и телекоммуникации. Одна из наиболее широко используемых коммерческих иерархических баз данных — IMS. Другой пример использования иерархических баз данных реестра Windows в Microsoft Windows операционных систем.

Примеры иерархических данных, представленных в виде реляционных таблиц

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

Таблица EmpNo Имя Фамилия Номер отдела 100 Альмухтар Хан 10-л 101 Гаурав Сони 10-л 102 Сиддхартха Сони 20-Б 103 Сиддхант Сони 20-Б

Таблица Серийный номер Тип Пользователь EmpNo 3009734-4 Компьютер 100 3-23-283742 Монитор 100 2-22-723423 Монитор 100 232342 Принтер 100

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

Рассмотрим следующую структуру:

EmpNo	Обозначение	Отчеты
10	Директор
20	Старший менеджер	10
30	Машинистка	20
40	Программист	20

В этом «дочерний» тот же тип, что и «родитель». В иерархии указано, что EmpNo 10 является начальником из 20, а 30 и 40 каждый отчет до 20 представлен столбцом «ReportsTo». В терминах реляционных баз данных столбец ReportsTo — это внешний ключ, ссылающийся на столбец EmpNo. Если бы «дочерний» тип данных был другим, он находился бы в другой таблице, но по-прежнему существовал бы внешний ключ, ссылающийся на столбец EmpNo таблицы сотрудников.

Эта простая модель, широко известная как модель списка смежности, была представлена ​​д-ром Эдгаром Ф. Коддом после того, как появились первые критические замечания о том, что реляционная модель не может моделировать иерархические данные. Однако эта модель является лишь частным случаем общего списка смежности для графа.

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

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

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

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

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

Сетевые

В отли­чие от реля­ци­он­ных баз, в сете­вых меж­ду таб­ли­ца­ми и запи­ся­ми может быть несколь­ко раз­ных свя­зей, каж­дая из кото­рый отве­ча­ет за что-то своё.

Если мы возь­мём базу дан­ных с сай­та Кино­по­ис­ка, то она может выгля­деть так:

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

Напри­мер, вы посмот­ре­ли «Нача­ло» Кри­сто­фе­ра Нола­на и вам понра­вил­ся этот фильм. Когда вы перей­дё­те к спис­ку филь­мов, кото­рые он ещё снял, база на сай­те сде­ла­ет так:

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

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

Операторы поиска данных с возможностью модификации

1. Найти и удержать единственный
   экземпляр сегмента. Эта операция подобна первой операции поиска GET UNIQUE,
   единственным отличием этой операции является то, что после выполнения этой
   операции пал найденным экземпляром сегмента допустимы операции модификации
   (изменения) данных.

Синтаксис:

GET HOLD UNIQUE
<имя сегмента> WHERE <список поиска>

1. Найти и удержать следующий
   с теми же условиями поиска. Аналогично операции 4 эта операция дублирует вторую
   операции поиска GET NEXT с возможностью выполнения последующей модификации
   данных.

Синтаксис:

GET HOLD NEXT

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

Синтаксис:

GET HOLD NEXT
WITHIN PARENT

Операторы
модификации данных

1. Удалить : Это первая
   из трех операций модификации.

Синтаксис:

DELETE

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

1. Обновить

Синтаксис:

UPDATE

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

Ввести новый
экземпляр сегмента.

INSERT <имя
сегмента>

Эта команда
позволяет ввести новый экземпляр сегмента, имя которого определено в параметре
команды. Если мы вводим данные в сегмент, который является подчиненным некоторому
родительскому экземпляру сегмента, то он будет внесен в БД и физически подключен
к тому экземпляру родительского сегмента, который в данный момент является текущим.

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