книги / Структурный подход к организации баз данных

ю

Рис. 8.13. а) Две физические базы данных с логической взаимосвязью между их сегмен­ тами; б) Логическое представление показан­ ных выше физических баз данных с логиче­ ской взаимосвязью.

и логически исходный (ЬР). На рис. 8.15 показаны два возможных логи­ ческих представления, т. е. представления прикладного программиста о ба­ зе данных. Имеет место полная избыточность данных, хранимых в показан­ ных на рис. 8.14 сегментах В и Э баз данных. Для сохранения целостности Жданных прикладной программист должен обеспечить обновление любой части сегмента О, если обновляется идентичная часть сегмента В, и наобо­ рот. Выполнение этой функции может быть возложено на 1М5 путем введе­ ния логической взаимосвязи второго типа, называемой физически парной двунаправленной логической взаимосвязью.

Фи з и ч е с к и п а р н а я д в у н а п р а в л е н н а я л о г и ч е с к а я в з а и м о с в я з ь . Между сегментами В и О устанавливается взаимосвязь или они делаются «физически парными» (рис. 8.16). По-прежнему имеет место избыточность данных, хранимых в сегментах В и О. Основное различие между двумя однонаправленными логическими взаимосвязями (рис. 8Л4) и физически парной двунаправленной логической взаимо­ связью (рис. 8.16) состоит в том, что во втором случае 1М5 автоматически обновляет сегмент О при обновлении сегмента В, и наоборот. При этом используются указатели физически порожденный первый (РСР), физи-

Модель данных 1

Рис. 8.16. Две физические базы данных с физически парной двунаправленной логической взаимосвязью. Сегменты В и О — физически парные. Если обновляется сегмент В, 1М5 автоматически обновляет сегмент О, и наоборот

чески подобный прямой (РТР), физически исходный (РР), логически исходный (ЬР) и указатель пары (для парных сегментов В и Э) и обеспечиваются те же два возможных представления прикладного программиста о базе данных (рис. 8.15). Существует третий способ реализации логических представлений, который позволяет устранить избыточность данных, хранимых в сегментах В и О, и избежать допол­ нительных расходов на обновление одного из сегментов при обновлении другого,— установление виртуально парной двунаправленной логической взаимосвязи.

В и р т у а л ь н о п а р н а я д в у н а п р а в л е н н а я л о г и ч е с к а я в з а и м о с в я з ь . Чтобы устранить избыточность данных, хранимых в сегментах В и О, в качестве физического сегмента можно представить лишь один из них. На рис. 8.17 в базе данных физически представлен сегмент В. Применяются следующие указатели: физически порожденный первый (РСР), физически подобный следующим (РТЫ), физически ис­ ходный (РР), логически исходный (ЬР), логически порожденный первый (ЬСР) и логически подобный прямой (ЬТР). Указатель пары исчез, поскольку сегмент физически отсутствует, т. е. сегмент Э «виртуально» парный сегменту В. Два возможных логических представления приклад­ ного программиста о базе данных те же, что и на рис. 8.15.

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

Модель донных 1

Рис. 8.17. Две физические базы данных с виртуально парной двунаправленной логической взаимосвязью. Сегмент В физически присутствует в базе данных, сегмент Э — виртуальный

Правила установления логических взаимосвязей

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

2.Корневой сегмент логической базы данных должен также яв­ ляться корневым сегментом физической базы данных (кроме случая

вторичного индексирования).

3.Для логически порожденного сегмента может быть определен только один логически исходный.

4.Корневой сегмент физической базы данных может быть логически

исходным, но не логически порожденным.

5. Логически порожденный сегмент не может быть логически исходным.

6.Логически порожденный сегмент не может быть физически ис­ ходным для логически порожденного сегмента (рис. 8.18).

7.Логически порожденный сегмент может иметь физически порож­ денный (рис. 8.18).

8.При формировании логического представления с использованием логической взаимосвязи возможно пересечение физической иерархии, т. е. физически исходный логически исходного сегмента может выступать в логическом представлении в роли порожденного у сцепленного сегмента (логически порожденный и логически исходный, рис. 8.18а и 8.19).

9.Физически порожденный логически исходного сегмента может вы­ ступать в логическом представлении в роли порожденного у сцепленного

сегмента (логически порожденный и логически исходный, рис. 8.19).

Рис. 8.18а. Две физические базы данных с логической взаимосвязью. Сегмент Э — физи­ чески исходный для логически исходного сег­ мента Е. Сегмент Р — физически порожден­ ный логически исходным сегментом Е

СегментЦ

подчинен

сегментам Си Е

Рис. 8.19. Логическое представление двух физи­ ческих баз данных с логической взаимо­ связью (рис. 8.18а)

10. При построении логических представлений логические взаимосвязи могут пересекаться.

На рис. 8.20 приводится перечень логических представлений.

Физическая Физическая

Логическая Пазаданных

СЕГ1

СЕГ2 СЕГО

СЕГ1 СЕГЗ

СЕГ2 СЕГЗ СЕГ4 СЕГ1

Рис. 8.20. Возможные логические представления

Методы доступа внутренней и внешней моделей 1М5/У5 Методы доступа внутренней модели:

•физический последовательный (Н5АМ);

•индексно-последовательный (Н15АМ, НШАМ);

•произвольный (НОАМ);

•инвертированный (вторичный индекс).

Методы доступа внешней модели:

•логический последовательный (Н5АМ, Н15АМ, НШАМ);

•по физической иерархии ц по модифицированной логическими взаимо­ связями иерархии:

кфизически порожденному (первому, последнему),

кфизически подобному (вперед, назад),

кфизически исходному,

клогически порожденному (первому, последнему),

клогически подобному (вперед, назад),

клогически исходному,

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

Как отмечалось в § 4.5, на формирование современных концепций баз данных значительное влияние оказали работы ассоциации КОДАСИЛ и ее комитетов (в основном РГБД). При построении сетевых систем основополагающие концепции спецификаций КОДАСИЛ могут рас­ сматриваться как типовые. С помощью сетевых моделей данных построено множество СУБД, например, система Ш 5/П фирмы Нопеу^еИ, система ШМ8 фирмы СиШпапе, система ОВМ8-10/20 фирмы ЭЕС для машин ОЕС8У8ТЕМ-10 и ОЕС8У8ТЕМ-20, система ОВМ8-11 фирмы ЭЕС для машины РЭР 11/70 и система ОМ8 1100 фирмы ишуас. Большая часть перечисленных систем соответствует спецификациям КОДАСИЛ. Ниже мы рассмотрим некоторые варианты реализации предложенной РГБД КОДАСИЛ модели данных.

8.2.1.Рабочая группа по базам данных КОДАСИЛ

Как отмечалось в гл. 4, основным конструктивным блоком сетевой модели данных является тип набора. Тип набора состоит из типа записивладельца и одного или более типов записи-члена. Правила формирова­ ния типа набора таковы:

1.Тип набора включает только один тип записи-владельца.

2.Тип набора может содержать один или более тип записи-члена.

3.Один и тот же тип записи не может одновременно являться владельцем и членом одного и того же типа набора.

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

Методы доступа внутренней модели

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

1.САБС (вычисление);

2.01КЕСТ;

3.У1А 8ЕТ;

4.8У8ТЕМ (по умолчанию);

5.1ШЕХ.

РГБД определен синтаксис предложений для назначения способа размещения записей данного типа:

1. САГС

КЕС01Ш ЫАМЕ 15 имя-записи ШСАТ1СЖ МОРЕ 15 САЬС процедура У5ШО элемент-данных, элемент данных,...

Полям «имя записи», «процедура» и «элемент данных» должны быть присвоены соответствующие значения. САЬС — сокращение от САБСПБАТЮЫ (ВЫЧИСЛЕНИЕ). Если запись помещается в базу данных, ее ключ в этой базе данных вычисляется после сцепления значений элементов данных, определенных вслед за 118ШО в предложении БОСАТКЖ МСЮЕ.

В отчете РГБД под способом размещения САБС подразумевается хеширование. Может использоваться алгоритм хеширования, задаваемый

«процедурой», или, если она не определена, по умолчанию предостав­ ляемый СУБД.

Чтобы выяснить, как процедура САЬС «определяет», где разместить

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

При выборе способа размещения САЬС необходимо также опреде­ лить, как будут обрабатываться одинаковые значения ключей. АБД дол­ жен уточнить, допускается или запрещается наличие одинаковых значе­ ний первичного ключа. Возможно, при хранении записей желательно до­ пустить наличие одинаковых экземпляров одного и того же значения клю'ча, например, если в качестве первичного ключа выбирается ФА­ МИЛИЯ. Если первичным ключом служит НОМЕР СТРАХОВОГО ПО­ ЛИСА, наличие одинаковых экземпляров одного и того же .значения ключа может оказаться нежелательным. Эту проблему должны решать программист и АБД, однако СУБД может осуществить редактирование дубликатов. Синтаксис предложения, определяющего порядок обработки одинаковых ключей, имеет вид:

ШСАТ1СЖ МСЮЕ 15 САЦС процедура 115ШО элемент-данных, элемент-данных,

Г N01 1 ОУРЫСАТЕЗ АКЕ РШ5Т АЕЬОШЕО

ЬАЗТ _

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

2. РЩЕСТ

НЕСОНО ЫАМЕ 15 имя-записи

( им.я-данных-базы данных 1 )

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

образом, способ размещения ОЩЕСТ может быть более «прямым», чем способ САБС.

Предусматриваются две альтернативы при задании ключевых эле­ ментов данных: имя-данных-базы-данных 1 и элемент-данных 1. Если специфицируется элемент-данных 1, он должен определяться как ОАТА-ВАЗЕ-КЕУ, например элемент-данных 1 ТУРЕ Г5 ОАТА-ВАЗЕ- КЕУ.

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

1. Значения ключей верны, поскольку они еще не используются.

2.Значения ключей неверны и, возможно, уже используются.

3.Значения ключей отсутствуют.

В первых двух случаях программист пытается принять непосред­ ственное участие в размещении записи. В третьем случае он может не заботиться о физическом запоминании записи. Третий вариант экви­ валентен способу размещения 5У5ТЕМ (по умолчанию), рассматривае­ мому ниже.

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

Способ размещения ОЩЕСТ представляет большой интерес, по­ скольку он обеспечивает наиболее быстрый доступ к записи и требует минимума памяти для хранения ключей базы данных. Следует, однако, иметь в виду, что преимущества передачи функций управления данными СУБД могут компенсировать потери времени или памяти, обусловленные ее применением. В качестве примера рассмотрим систему Е)ВМ5-10/20 фирмы ОЕС. Выигрыш в памяти, получаемый за счет способа размещения ОЩЕСТ, весьма незначителен. При наличии взаимосвязи «один к двум» (т. е. один владелец и два члена) способ размещения ОЩЕСТ для ключей использует два слова. В случае определения взаимосвязи через набор (см. ниже способ размещения У1А ЗЕТ) требу­ ется четыре слова. Если же имеется взаимосвязь «один к пятнадцати», то способу размещения ОЩЕСТ необходимо 15 слов. Набор займет 17 слов и т. д. Поэтому выигрыш в памяти можно в расчет не при­ нимать.

При способе ОЩЕСТ обращение к каждой записи часто требует выполнения одной операции ввода-вывода. При структуре «один к двум», например, возможно, придется обратиться к владельцу, к члену, а затем — ко второму члену. Таким образом, выполняются три операции вводавывода. При правильном группировании У1А ЗЕТ достаточно обратиться к владельцу, не обращаясь к членам. В этом случае потребуется вы­