3.2.2. Межзаписная структура

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

Иерархические модели. В классических иерархических моделях имеется один файл, который является входом в структуру (корень де­рева). Остальные файлы связаны друг с другом таким образом, что каждый из них, за исключением корневой вершины, имеет ровно одну исходную вершину («родитель») и любое число подчиненных вер­шин («детей»). Между записью файла-родителя и записями порож­денного файла имеется отношение 1:М (как частный случай может быть и отношение 1:1). Имеются и другие разновидности иерархи­ческих моделей, но они менее распространены.

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

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

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

Реляционные модели. В таких моделях используется своеобраз­ная терминология, но это не меняет сущности модели. Часто даже в рамках одной модели в разных СУБД используется разная термино­логия. Так, на логическом уровне элемент чаще всего называют атри­бутом; кроме того, для него используются термины «колонка», «столбец», «поле». Совокупность атрибутов образует строку (синонимич­ные термины - «ряд», «запись», «кортеж»). Совокупность строк об­разует отношение («таблицу», «файл базы данных»). Понятие базы данных как множества отношений поддерживается далеко не всеми реляционными СУБД (т.е. при создании БД описываются отдельные отношения (файлы, таблицы), а для всей базы данных как самостоя­тельной информационной единицы никакого описания не предусмот­рено). Однако следует отметить, что в последнее время новые версии даже тех настольных СУБД, которые раньше не поддерживали поня­тие БД, сейчас его включают.

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

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

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

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

В случае если СУБД поддерживает концепцию ключа, при нали­чии нескольких вероятных ключей один из них выбирается и описы­вается как первичный, остальные — как альтернативные (обычно для этих целей используется либо уникальный индекс, либо описатель UNIQUE при определении таблицы).

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

Если какая-либо таблица содержит внешний ключ, то она логи­чески связана с таблицей, содержащей соответствующий первичный ключ; эта связь имеет характер «один ко многим» (таблица, содержа­щая внешний ключ, находится на стороне «много» в этой связи). В част­ном случае это может быть связь 1:1. Связь М:М в реляционной базе данных непосредственно не поддерживается.

По сути, понятия «родитель» - «ребенок» в иерархических мо­делях, «файл-владелец» - «файл-член» в сетевых моделях и связь «ключ» - «внешний ключ» в реляционных моделях передают одно и то же явление — наличие связи 1 :М между записями соответствую­щих файлов.

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

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

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