Ю. А. Григорьев, Г. И. Ревунков - Банки данных

2. Модели данных

Рис. 2.3. Пример преобразования связи М\М

Большое влияние на развитие сетевой модели данных и соответст­ вующих СУБД оказали предложения РГБД — Рабочей группы по базам данных (DBTG — Data Base Task Group) Ассоциации по языкам систем обработки данных — КОДАСИЛ. Эта модель считается наиболее развитой сетевой МД. Она постоянно развивается, совершенствуются средства фор­ мальной спецификации элементов модели, исследуются аспекты возможной стандартизации.

Основные типы структур модели Кодасил: элемент данных, агрегат, запись, набор, БД (см. § 2.3).

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

В основе создания структур БД лежат следующие композиционные правила:

•БД может содержать любое количество типов записей и типов наборов;

•между двумя типами записей может быть определено любое количе­ ство типов наборов;

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

Модель реализует только связи 1:1, 1:М, М:1, причем набор нельзя описывать атрибутами — это внутренние ограничения модели. В случае необходимости представления связей типа М:М вводят вспомогательный тип записи и две связи — \\MwM\\ (рис. 2.3).

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

60

2.4. Иерархическая и сетевая модели данных

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

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

Описание схемы БД, выполненное на ЯОД КОДАСИЛ состоит из че­ тырех статей.

1. Статья схемы. Состоит из одного предложения SCHEMA NAME IS имя-схемы.

2. Одна или несколько статей областей. Область — это поименован­ ный раздел адресуемого пространства памяти, в котором выполняется раз­ мещение экземпляров записей БД. Каждая область разбита на страницы. Записи приписываются к области независимо от их участия в наборах. При разделении БД на области появляется возможность распределять БД по раз­ личным запоминающим устройствам. Однако, если АБД не желает по ка­ ким-либо причинам использовать концепцию областей, то назначается одна область для всей БД. Для каждой области статья состоит из предложения:

AREA NAME IS имя-области.

3. Одна или несколько статей записей. Число статей определяется числом типов записей. Статья записи начинается предложением

RECORD NAME IS имя-записи.

Затем задается способ выбора страницы области для записи:

Вариант DIRECT указывают, если номер страницы области для раз­ мещения записи будет поступать из программы, т.е. программист сам управляет размещением экземпляров записей в БД.

Вариант CALC задают, если предполагается, что при помещении эк­ земпляра записи в БД специальная процедура по значению calc-элемента вычисляет значение ключа БД — адрес размещения этого экземпляра запи­ си в БД. Если в качестве ключа указывается первичный ключ записи, то следует указать фрагмент DUBLICATES ARE NOT ALLOWED. Если ука­ зывается другой элемент данных записи и он может иметь повторяющиеся значения (например, фамилия сотрудника отдела), то указывается фрагмент DUBLICATES ARE ALLOWED.

61

2. Модели данных

Вариант VIA SET задают, если необходимо, чтобы помещаемая в БД запись оказалась физически по-возможности ближе к тому экземпляру на­ бора, в который она должна быть включена.

Вариант SYSTEM задают, если не предполагается использовать рас­ смотренные выше варианты и размещение экземпляра записи отдается на усмотрение системы.

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

WITHIN имя-области AREA.

тип записи приписывается к некоторой области БД.

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

номер-уровня имя-данного.

Если описываемое данное является элементом данных, то указывается его шаблон:

номер-уровня имя-данного; PICTURE IS шаблон. Например:

02 Номер телефона; PICTURE IS 9 9 9 ^ 9 ^ 9 .

Шаблон — это средство для описания формата значений элемента данных. Цифра 9 означает, что в данной позиции допускается любая деся­ тичная цифра. X— что может содержаться любой символ. А — буквенный символ; символ «.» — десятичная точка. Если символ шаблона повторяется несколько раз, то можно использовать yкaзateль числа повторений:

02 фамилия; PICTURE IS Х(35)

Для элемента данных вместо PICTURE IS шаблон можно указывать следующими типами данных: BINARY; DECIMAL; FIXED; FLOAT; TYPE IS REAL; COMPLEX; BIT; CHARACTER; DATA-BASE-KEY.

Если описываемое данное — повторяющаяся группа, то его описание должно заканчиваться фразой:

OCCURS количество-повторений TIMES.

4. Статья набора. Описание каждого набора, представленного в схеме БД, выполняется следующими предложениями:

SET NAME IS имя-набора ;

62

Фраза OWNER IS задает тип записи-владельца; фраза ORDER IS — способ включения экземпляров записей-членов в экземпляры описываемого типа набора.

Предложение MEMBER IS описывает запись-член набора. Различают AUTOMATIC (автоматический) и MANUAL (ручной) способы включения экземпляра записи-члена в набор при выполнении оператора ЯМД STORE (поместить). При ручном способе включения экземпляр записи помещается в БД, но в набор не включается. При автоматическом способе включения одновременно с вводом в БД экземпляр записи подключается и к набору. Выборка экземпляра набора для автоматического включения в него поме­ щаемой в БД записи выполняется СУБД по индикатору текущей записи соответствующего типа набора, обрабатываемого в программе (индикатор указывает либо на владельца, либо на одного из членов экземпляра набора заданного типа). Кроме того, в модели имеется возможность указания для автоматического способа включения записей условия выбора (селекции) экземпляра набора.

С помощью фрагмента MANDATORY (ОБЯЗАТЕЛЬНЫЙ) или OPTIONAL (НЕОБЯЗАТЕЛЬНЫЙ) определяется вид исключения экземп­ ляра записи из экземпляра набора. Если членство в наборе объявлено для записи-члена как обязательное — MANDATORY, то экземпляр записичлена при удалении из набора удаляется из БД. При необязательном членст­ ве в наборе экземпляр записи-члена при удалении из набора отсоединяется от соответствующего экземпляра набора, но остается в БД.

Фрагмент ASCENDING/DESCENDING задают в случае использова­ ния варианта SORTER предложения ORDERS. С его помощью указывается также ключ сортировки (упорядочения) набора.

На рис. 2.4 приведен пример описания схемы БД, диаграмма которой представлена на рис. 2.5.

В модели РГБД КОДАСИЛ внешний уровень реализуется введением понятия подсхемы (ПС). Концепция подсхемы реализует «взгляд» на БД

63

2. Модели данных

SCHEMA NAME IS Данные по отделу. AREA NAME IS A.

RECODER NAME IS Отдел;

LOCATION MODE IS CALC USING Номер отдела DUPLICATES ARE NOT ALLOWED;

WITHIN A AREA.

02 Номер отдела ; TYPE IS CHARACTER 2.

02 Название отдела ; TYPE IS CHARACTER 25.

02 Бюджет ; TYPE IS CHARACTER 5.

02 Лаборатория: OCCURS 10 TIMES.

03 Номер лаборатории ; TYPE IS CHARACTER 5.

03 Название ; TYPE IS CHARACTER 25. RECODER NAME IS Проект ;

LOCATION MODE IS CALC USING Номер проекта DUPLICATES ARE NOT ALLOWED;

WITHIN A AREA.

02 Номер проекта ; TYPE IS CHARACTER 3.

02 Название проекта ; TYPE IS CHARACTER 50.

02 Дата окончания ; TYPE IS CHARACTER 10. RECODER NAME IS Сотрудник ;

LOCATION MODE IS CALC USING Табельньгй номер DUPLICATED ARE NOT ALLOWED;

WITHIN A AREA.

02 Табельный номер ; TYPE IS CHARACTER 6.

02 Фамилия имя отчество ; TYPE IS CHARACTER 50.

02 Год рождения ; TYPE IS CYARACTER 4.

02 Должность ; TYPE IS CHARACTER 20. SET NAME IS Работает в отделе ;

OWNER IS Отдел ;

ORDER IS PERMANENT INSERTION IS SORTED; MEMBER IS Сотрудник AUTOMATIC MANDATORY;

KEY IS ASCENDING Табельный номер. SET NAME IS Выполняется в отделе;

OWNER IS Отдел;

ORDER IS PERMANENT INSERTION IS SORTED; MEMBER IS Проект AUTOMATIC MANDATORY;

KEY IS ASCENDING Номер проекта. SET NAME IS Система отдел;

OWNER IS SISTEM;

ORDER IS PERMANENT INSERTION IS IS SORTED; MEMBER IS Отдел AUTOMATIC MANDATORY;

KEY IS ASCENDING Номер отдела.

Рис. 2.4. Пример описания схемы БД

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

64

2.4. Иерархическая и сетевая модели данных

^Выполняется в отделе

/Проект

Рис. 2.5. Пример графической диаграммы БД

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

С одной стороны, ЯОД ПС предназначен для спецификации в ПС элементов схемы БД, которые требуются ПП, составляемой на некото­ ром алгоритмическом языке. А с другой стороны, он должен отражать внутреннюю структуру записи, принятую в используемом алгоритмиче­ ском языке. Поэтому говорят о ЯОД ПС КОБОЛа, ЯОД ПС ПЛ/1 и т.д. Система управления БД должна быть обеспечена соответствующими трансляторами ЯОД подсхем.

В каждой программе в соответствии с используемой ПС резервируется рабочая область оперативной памяти. Каждый тип записи, объявленный в ПС, имеет в этой области свой участок — область записи. В эти области будут считываться экземпляры записей из БД для последующей обработки командами программы либо программа должна в них подготавливать данные для после­ дующего вывода в БД операторами ЯМД. Обращение к данным, находящимся в рабочей области, выполняется по именам, объявленным в ПС.

65

2.Модели данных

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

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

Возможны и другие отличия, часть которых определяется возможно­ стями конкретной СУБД.

При выполнении программы каждому процессу назначаются индика­ торы текущего состояния. Количество назначаемых индикаторов (текущих программы) определяется ПС программы. Состав «текущих» программы следующий:

•текущая запись процесса — один экземпляр для выполняемой про­ граммы;

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

•текущая запись в типе записи — один экземпляр для каждого типа записи в подсхеме;

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

Например, если ПС включает два типа набора, три типа записи и две области, то процессу, который использует эту ПС, будет назначено 8 инди­ каторов текущего состояния:

1 (процесса) + 1 x 2 (по типам наборов) + 1 x 3 (по типам записей) +

+1 x 2 (по количеству областей) = 8.

Вначале выполнения программы все индикаторы имеют нулевое зна­ чение. Установку требуемых значений индикаторов (значением индикатора является ключ БД некоторой записи, т.е. адрес этой записи) программист может выполнить оператором FIND (найти) или STORE (поместить) ЯМД. Установленное значение может далее использоваться в программе другими операторами ЯМД.

Кроме индикаторов текущего состояния вводятся так называемые ре­ гистры БД, через которые резидентный модуль СУБД сообщает программе об успешном или аварийном выполнении оператора ЯМД. Регистры БД могут быть, например, следующие:

СОСТОЯНИЕ БАЗЫ ДАННЫХ; ИМЯ ОБЛАСТИ БАЗЫ ДАННЫХ;

66

2.4. Иерархическая и сетевая модели данных

ИМЯ НАБОРА БАЗЫ ДАННЫХ; ИМЯ ЗАПИСИ БАЗЫ ДАННЫХ.

Рассмотрим основные операторы модели, с помощью которых осу­ ществляется манипулирование данными модели. Запись является основной единицей обмена данными между процессом и БД в модели.

Оператор READY (ГОТОВНОСТЬ). Этот оператор в программе вы­ полняет открытие области БД, к которой планируется обращение. По смыс­ лу этот оператор соответствует оператору открытия файла (OPEN) в тради­ ционных файловых системах.

Оператор FINISH (ЗАКОНЧИТЬ РАБОТУ). Оператор выполняет за­ крытие области (областей) БД, которые были открыты в программе, и по­ этому должен быть последним выполняемым ЯМД-оператором в програм­ ме. По своему смыслу оператор аналогичен оператору закрытия файлов (CLOSE) в файловых системах.

Оператор FIND (НАЙТИ). Этот оператор выполняет поиск записи в БД, поэтому он является основным оператором модели. Он также определя­ ет место расположения существующего в БД экземпляра записей, который удовлетворяет заданным условиям поиска, и назначает этот экземпляр запи­ си «текущей записью процесса». При этом также выполняется обновление соответствующих индикаторов текущего состояния: типа записи, области и всех наборов, участником которых является найденный экземпляр записи. Для реализации различных вариантов поиска существует несколько форма­ тов оператора FIND. Возможен поиск записи по значению CALC-ключа записи. Можно выполнять позиционный поиск в заданном наборе или об­ ласти — найти следующую, предыдущую, первую или последнюю запись. Также можно выполнить поиск записи-владельца текущего экземпляра на­ бора указанного типа.

При неуспешном выполнении оператора FIND система вырабатывает соответствующий код исключительного состояния для его последующего анализа в программе.

Оператор GET (ПОЛУЧИТЬ). Оператор осуществляет выборку теку­ щей записи процесса.

Оператор STORE (ЗАПОМНИТЬ). Перед выполнением оператора STORE программист должен сформировать данные, которые требуется поместить в БД, в соответствующей области записи рабочей области программы.

Оператор MODIFY (ИЗМЕНИТЬ). Оператор обновляет текущую за­ пись процесса.

Оператор ERASE (СТЕРЕТЬ). С помощью этого оператора из БД уда­ ляется экземпляр-запись, соответствующий индикатору текущей записи процесса. Перед его выполнением требуется предварительно оператором FIND определить наличие соответствующего экземпляра записи в БД. Од­ нако, если удаляемая запись является записью-владельцем некоторого не-

67

2. Модели данных

пустого набора, то удаление не выполняется, а вырабатывается код соответ­ ствующего исключительного состояния.

Чтобы удалить запись-владелец непустого набора, в операторе ERASE специфицируется одно из следующих слов:

ALL PERMANENT SELECTIVE.

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

При указании варианта PERMANENT удаляется текущая запись про­ цесса. Все связанные с нею наборы разрушаются. При этом обязательные члены наборов удаляются из БД.

Вариант SELECTIVE аналогичен предыдущему, но при этом из БД также удаляются необязательные члены разрушенных наборов, которые не являются одновременно членами других наборов.

Оператор CONNECT (ПРИСОЕДИНЯТЬ). Оператор выполняет вклю­ чение текущей записи процесса в набор.

Оператор DISCONNECT (ОТДЕЛИТЬ). Оператор выполняет исклю­ чение текущей записи процесса из набора, но при этом она остается в БД.

Кроме рассмотренных основных операторов в состав ЯМД модели КОДАСИЛ входят следующие операторы:

ACCEPT — для пересылки значений индикаторов текущего состояния в определенные пользователем элементы данных;

KEEP — для блокирования записи при попытке ее обновления парал­ лельным процессом;

FREE — для отмены действия оператора KEEP;

ORDER — для выполнения упорядочения записей-членов текущего экземпляра указанного типа набора;

IF — для проверки, в какой тип набора и в каком качестве входит найденная запись.

Существуют и другие вспомогательные операторы. Как следует из рас­ смотренных операторов ЯМД, особую роль в программе играет индикатор те­ кущей записи процесса. Именно этот индикатор во многих операторах ЯМД указывает резидентному модулю СУБД на конкретный экземпляр записи в БД, над которым следует выполнить определяемое оператором действие.

Например, в программе встретился оператор ERASE имя-записи,

при этом в БД, с которой работает программа, имеется, например, 20 000 экземпляров записей указанного типа. Для указания системе именно того

68

2.5. Реляционная модель данных

экземпляра записи этого типа, который подлежит удалению, и используется индикатор текущей записи процесса. В этот индикатор программист должен предварительно оператором FIND поместить значение ключа БД удаляемо­ го экземпляра записи.

Индикатор текущей записи в типе набора используется обычно для выбора конкретного экземпляра набора. Например, в программе использо­ ван следующий оператор ЯМД:

CONNECT имя записи ТО имя набора.

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

Существуют варианты операторов FIND и STORE, которые не изме­ няют значения некоторых индикаторов текущего состояния (кроме индика­ тора текущей записи процесса), что расширяет логические возможности программиста при составлении программ.

Выполнение операторов ЯМД может завершиться неудачно по цело­ му ряду причин. Поэтому в программе необходим анализ результатов вы­ полнения операторов ЯМД. При неуспешном выполнении этих операторов в программе должны быть предусмотрены определенные действия.

2.5. Реляционная модель данных

Реляционный подход в настоящее время представляет наиболее раз­ витую идеологию построения БД и БЗ. Реляционная модель данных была предложена в начале 70-х годов американским ученым Э.Ф. Коддом, за что в 1981 г. он был удостоен премии Тьюринга Американской ассоциации по вычислительной технике.

Структура данных. В основе реляционной модели лежит понятие «отношение», представляющее собой подмножество декартова произведе­ ния доменов. Домен — некоторое множество элементов (например, множе­ ство целых чисел или множество допустимых значений, которые может принимать объект по некоторому свойству и т.п.).

Декартовым произведением доменов D\, Di, >>. , Dk является выраже­ ние вида

69