Лекция 6. Сетевые и иерархические базы данных

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

Сначала описывается логическая структура модели данных (МД), затем – процессы использования построенной БД с помощью предложенного Э.Ф. Коддом языка Альфа [9] и, наконец, процедура программного описания (создания и использования) БД. Поскольку Альфа-описание указанных моделей данных не отличается от Альфа-описания реляционной модели данных, оно опущено.

Логическая структура сетевой БД

При различных способах реализации сетевых моделей [1 –11] наибольшее распространение получила модель КОДАСИЛ (CODASYL Conference on DAta SYstems Language – Ассоциация по языкам систем обработки данных), предложенная Рабочей группой по базам данных (DBTG – DataBase Task Group). Эта модель считается наиболее развитой сетевой моделью данных, постоянно развивается, поддерживается и сопровождается, являясь как бы стандартом.

Ассоциация КОДАСИЛ образовалась в 1959 г., а Рабочая группа БД, начиная с 1969 г., выпускала спецификации. Основы сетевой модели были заложены в 1971 г. Комитетом по ЯОД. Вместо Рабочей группы БД стала работать Рабочая группа языков БД, начавшая с расширения КОБОЛа. Серьезные результаты были получены в 1973 г. В отчетах группы была описана сетевая модель данных, фактически мало изменившаяся с тех пор. Основная цель КОДАСИЛ – создание иерархической модели, позволяющей описывать отношения М : М, т. е. уменьшить недостатки иерархической модели.

Разрабатывались и соответствующие СУБД: DMS (корпорации UNIVAC), IDMS (Cullinane), DBMS (DEC), IDS (Honeywell). В настоящее время широко известна db_Vista, работающая на персональных компьютерах в DOS и Windows.

Структурными элементами сетевой модели данных КОДАСИЛ являются элемент данных, агрегат данных и запись (рис. 6.1, а), которым присваиваются имена.

Элемент данных (ЭД) – наименьшая поименованная единица данных (аналог поля в файловых системах), с помощью которой осуществляется построение всех остальных структур. Примеры элементов данных: "Табельный номер", "Шифр детали", "Год рождения". Имя элемента данных используется для его идентификации в схеме структуры данных более высокого уровня. Значение элемента данных может быть числовым (целым, вещественным), нечисловым (символьным, логическим). В некоторых приложениях может использоваться "неопределенное" значение элемента данных и это значит, что значение соответствующего свойства объекта не определено в БД.

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

Рис. 6.1. Структурные элементы сетевой БД

Различают агрегаты типа "вектор" и типа "повторяющаяся группа". Агрегат, повторяющаяся компонента которого является простым элементом данных, называется "вектором". Например агрегат "Заработная плата", в котором экземпляр элемента данных может повторяться до 12 раз (за каждый месяц года). Агрегат, повторяющаяся компонента которого представлена совокупностью данных, называется повторяющейся группой. В повторяющуюся группу могут входить отдельные элементы данных, векторы, агрегаты или повторяющиеся группы. На рис. 6.1, г представлен агрегат "Заказ на покупку", имеющий в своем составе повторяющуюся группу "Партия товара".

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

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

Записи являются фактически простейшими структурными элементами, через которые осуществляются связи: элементом связи служит набор.

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

Структуры БД строятся на основании следующих основных композиционных правил.

1. База данных может содержать любое количество типов записей и типов наборов.

2. Между двумя типами записи может быть определено любое количество типов наборов.

3. Тип записи может быть владельцем и одновременно членом нескольких типов наборов.

Допускается добавление новой записи в качестве экземпляра владельца, если запись-член отсутствует.

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

Наборы могут быть нескольких разновидностей.

1. С одними и теми же типами записей, но разными типами наборов.

Рис. 6.2. Сингулярный набор

2. Наборы из трех и более записей, в том числе с обратной связью.

3. Сингулярный набор (только один экземпляр). У такого набора нет естественного владельца и в качестве его выступает система (рис. 6.2). В дальнейшем такие наборы могут приобрести запись-владельца.

Количество объявляемых сингулярных наборов произвольно. Один и тот же тип записи может быть объявлен членом сингулярного набора и одновременно владельцем либо членом других наборов.

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

Рис. 6.3. Многочленный набор

"Монография". Экземпляр некоторого типа многочленного набора включает в себя один экземпляр записи-владельца и все связанные с ним экземпляры записей-членов заданных типов. В конкретных СУБД концепция многочленного набора может быть не реализована.

В сетевой БД возможны следующие способы доступа:

• последовательный просмотр записей основного файла;

• просмотр всех записей зависимого файла, связанного с конкретной записью основного файла;

• прямой поиск записи основного файла по ее ключу (точка доступа).

Отметим, что если запись используется для представления сущности, то набор – для представления связей между рассматриваемыми сущностями.

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

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

В модели КОДЛСИЛ основным внутренним ограничением целостности является функциональность связей, т. е. с помощью наборов можно реализовать непосредственно связи типа 1:1, 1:М, М:1. В модели это первое внутреннее ограничение выражается утверждением: в конкретном экземпляре набора экземпляр записи- члена набора может иметь не более одного экземпляра записи-владельца набора. Следовательно, число экземпляров набора некоторого типа в точности равно числу экземпляров записей-владельцев этого типа набора в БД. При этом экземпляр набора может быть и пустым, т. е. состоять из экземпляра записи-владельца (экземпляры записей-членов могут отсутствовать в некоторые моменты времени при функционировании системы).

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

Функциональный характер реализуемых связей не позволяет непосредственно представлять в модели тип "многие ко многим". Для представления связи типа М:N вводят вспомогательный тип записи и две функциональные связи типа 1:М (см. рис. 4.7).