Иерархическая и сетевая модели – две наиболее распространенные логические модели баз данных. Они достаточно просты и используются в большинстве современных СУБД. Основной вклад в разработку названных типов логических моделей и соответствующих им ЯОД и ЯМД внесла КОДАСИЛ – Ассоциация по языкам систем обработки данных.

Главный результат деятельности КОДАСИЛ – разработка теории СУБД с сетевой и, как частный случай, иерархической моделью данных. Поэтому оба названных типа логической модели базы данных рассмотрим так, как они представляются в теории КОДАСИЛ. В рамках этой теории специфицированы три языка – язык описания данных схемы, язык описания данных подсхемы и язык манипулирования данными. О назначении таких языков в СУБД говорилось в предыдущих лекциях.

В предложениях КОДАСИЛ язык манипулирования данными (ЯМД) включен в состав языка программирования КОБОЛ. В виде расширения декларативных средств этого языка реализованы также и языки описания данных (ЯОД) схемы и данных подсхемы.

Прежде чем говорить непосредственно об иерархической и сетевой моделях базы данных, остановимся на понятии "тип записи" и "тип набора". В соответствии с терминологией, тип записи – поименованная совокупность полей данных, каждое из которых может быть простым или составным (т.е. состоящим из нескольких подполей). Тип набора – поименованное иерархическое отношение (или взаимосвязь) между двумя или более типами записей, имеющее двухуровневую древовидную структуру. Такое отношение называют "один ко многим" и обозначается 1:М.

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

На рис.8.3 приведен пример типа набора, представленного в графической форме в виде диаграммы Бахмана. На такой диаграмме каждый прямоугольник представляет собой тип записи (с именем типа записи внутри прямоугольника), а разветвленная стрелка – отношение "один ко многим" между типами записи.

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

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

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

На рис.8.4 в форме диаграммы Бахмана приведен пример простой иерархической модели БД.

Эта модель содержит 10 разных типов записи УЧЕБНАЯ_ДИСЦИПЛИНА, АУДИТОРИЯ, ПРЕПОДАВАТЕЛЬ, РАБОЧАЯ_ПРОГРАММА, КВАЛИФИКАЦИЯ, УЧЕБНЫЙ_ПЛАН, ЛЕКЦИЯ, КУРСОВАЯ_РАБОТА, ЛАБОРАЬОРНАЯ_РАБОТА, ПРАКТИЧЕСКИЕ_ЗАНЯТИЯ и четыре типа набора ЭЛЕМЕНТЫ_УЧЕБНОЙ_ДИСЦИПЛИНЫ, КВАЛИФИКАЦИЯ_ПРЕПОДАВАТЕЛЯ, ЭЛЕМЕНТЫ_ПРОГРАММЫ, ЭЛЕМЕНТЫ_ПЛАНА. Все связи между типами записи в нашем примере соответствуют отношениям "один ко многим" или, как частный случай, "один к одному".

Из трех основных применяемых в настоящее время моделей БД иерархическая модель наиболее проста с точки зрения ее понимания, описания организации и применения. Не случайно поэтому в первые СУБД нередко закладывалась иерархическая модель БД. Однако в иерархических моделях получение ответов на некоторые запросы пользователей требует выполнения большого числа операций. Например, в БД, схема которой приведена на рис.8.4, выполнение запроса о лабораторных работах по всем учебным дисциплинам требует просмотра всех записей ЛАБОРАТОРНАЯ_РАБОТА, имеющихся в базе данных.

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

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

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

Для устранения возникшей трудности в базу данных введены вспомогательный, или промежуточный, тип записи ИЗУЧЕНИЕ и два типа набора СТУДЕНТ_ИЗУЧЕНИЕ и СЕМЕСТР_ИЗУЧЕНИЕ. При этом каждая запись СТУДЕНТ является записью-владельцем в экземпляре набора СТУДЕНТ_ИЗУЧЕНИЕ, содержащем запись ИЗУЧЕНИЕ по каждому семестру. В то же время каждая из этих ИЗУЧЕНИЕ – член в экземпляре набора СЕМЕСТР_ИЗУЧЕНИЕ с записью-владельцем СЕМЕСТР, содержащей сведения о том семестре, который проходит студент, соответствующий содержимому записи СТУДЕНТ. Поскольку запись-член может быть найдена по заданной записи-владельцу и наоборот, то учебные дисциплины, изучаемые тем или иным студентом, могут быть определены по записям-владельцам тех записей-членов СЕМЕСТР, которые, в свою очередь, являются владельцами для записей-членов ИЗУЧЕНИЕ. Прохождение семестра студентом определяется при этом через посредство записей ИЗУЧЕНИЕ, которые связаны как с записями СТУДЕНТ, так и с записями СЕМЕСТР.

Описанная взаимосвязь между разными типами записи для конкретных экземпляров записей иллюстрируется на рис.8.5. Для простоты в типе записи СТУДЕНТ указано лишь поле, содержащее фамилию и инициалы студента, а в типе записи ИЗУЧЕНИЕ – поле со значением оценки по соответствующей дисциплине. Связи между типами записи в наборе СЕМЕСТР_ИЗУЧЕНИЕ обозначены штриховыми стрелками, а в остальных двух наборах – сплошными стрелками.

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

Полное описание логической базы данных в КОДАСИЛ на ЯОД, т.е. схема, состоит из некоторого числа статей. Различают четыре типа статей: статью схемы, статью области, статью записи и статью набора. Статья набора не обязательна, т.е. в простейшем случае логическая БД может состоять только из типов записи.

Статья схемы состоит из одного предложения ЯОД и предназначена для именования схемы (в одной СУБД можно организовать несколько разных схем).

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

Статья записи предназначена для спецификации типа записи. Число статей записи равно числу разных типов записи.

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

При описании БД используются ключевые слова ЯОД и имена, выбранные разработчиком описываемой схемы (как правило, администратором базы данных). В ЯОД КОДАСИЛ ключевые слова – слова английского языка. Имена областей, типов записи, типов набора и полей записей – слова русского языка.

Результат деятельности КОДАСИЛ – создание языка манипулирования данными (ЯМД). ЯМД КОДАСИЛ не является самостоятельным языком, а "погружен" в язык программирования КОБОЛ. Предложения ЯМД КОДАСИЛ строятся на основе языковых элементов КОБОЛа. Прикладная программа, предназначенная для выполнения в сетевой СУБД, записывается в виде обычной программы на языке КОБОЛ с добавлением необходимых предложений ЯМД. Так как предложения ЯМД "не понятны" для транслятора языка КОБОЛ, то предварительно прикладная программа подвергается предтрансляции, в результате которой получается текст, состоящий только из предложений языка КОБОЛ. Этот текст затем подается на вход транслятора языка КОБОЛ и обрабатывается как обычная кобольная программа на этом языке.

При выполнении прикладной программы (ПП) СУБД организует рабочую область пользователя (РОП) для этой программы, играющей роль буфера между ПП и БД. Каждому типу записи, описанному в подсхеме, назначается определенное место в РОП, причем обращение к записи осуществляется по имени соответствующего типа записи. Если, например, требуется прочитать некоторый экземпляр записи (по команде GET), то ее копия в формате, определяемом типом этой записи в подсхеме, пересылается в РОП. Наоборот, запись, подлежащая пересылке в базу данных, сначала формируется в РОП, а затем передается в БД командой STORE. Кроме названных двух команд, в ЯОД КОДАСИЛ имеются и другие команды манипулирования данными, в частности, команды: INSERT – включить запись в один или несколько наборов, RENAME – удалить запись из одного или нескольких наборов, MODIFY - изменить содержимое полей записи или перевести ее в другой набор и т.д.

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