Однородные и неоднородные РБД

Рассмотрим случай однородных локальных БД (σº1). В этом случае чаще всего говорят о реляционных БД. Однако даже при выполнении всех сделанных ранее предположений имеются затруднения.

Пусть имеет место строгое соответствие MSi • σ = ψ • Msj. При переходе к произвольной модели Мk (рис. 11.7) из-за ψ ¹ 1 должно быть Msi • σ = ψ • Msk Если сохранить ψ (что желательно), то семантика ЯОД М, должна быть очень богатой.

Рис. 11.7. Соотношение локальных баз данных

Это условие выполнить трудно, поэтому действуют иначе. Изменяют функцию ψ для ЯОД и для ЯМД путем построения в ODBC соответствующих (попарных) драйверов. С позиций языков полезно использование стандартного языка SQL, многочисленные диалекты которого хорошо "понимают" друг друга. Поскольку разновидностей однотипных СУБД немного (для реляционных БД это обычно Paradox, dBASE, FoxPro, BTrieve, Access, Oracle), то немного и используемых в ODBC драйверов, что служит серьезным аргументом в пользу данного направления.

Рассматриваемая процедура существенно усложняется для случая разных моделей данных (σ ¹ 1).

Построение неоднородных РБД возможно двумя способами.

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

2. Создается единый стандартный пользовательский интерфейс и стандартная внутренняя форма запроса: одна схема РБД, но каждому типу локальных БД должен соответствовать свой тип преобразователя схемы в общую форму (n типов преобразования для n локальных СУБД). Пользователь должен в этом случае изучить новую схему – сетевой стандарт. Оба способа имеют свои достоинства и недостатки.

В общем случае возникает необходимость в построении промежуточной, универсальной, виртуальной модели данных [14, 15], для реализации которой можно использовать, например, реляционную модель.

Сложность здесь не только, как отмечалось ранее, в необходимости богатства семантики ЯОД и ЯМД. Действительно, коммутативные диаграммы операторов ЯМД предполагают сохранение инвариантности в Mi логических зависимостей данных, имеющих место в Mj Напрямую этому требованию семантика исходных операторов не удовлетворяет: разным внутренним моделям М. будут соответствовать различные требования к семантике модели Мj, в том числе и для состава функционального полного набора операций. Отобразить произвольную модель Мi в Мj. без изменения семантики данных и операций над ними в Mi не представляется возможным.

Тогда в общем случае и следует строить (рис. 11.8) промежуточную модель Мj, такую чтобы Мj = ядроМj + Mji, где модель Мji. отображает логические зависимости, присутствующие в Мi. Назовем Мji. интерпретацией Мi в Мj: она имеет все свойства моделей данных.

При конструировании Мji полезно использовать следующие принципы.

1. Ориентация на начальные типы данных Mj при построении в ML более сложных типов, отражающих зависимости в Мi, при этом основой Мji. является М.-ядро.

2. Совмещение синтаксиса множества операторов Оji ЯМД Mji с синтаксисом множества операторов Оj путем изменения семантики.

3. Ядро Mj должно обладать максимальным разнообразием первичных типов данных с минимумом ограничений.

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

В этом случае процедура преобразования может иметь такую последовательность:

1) определяются начальная М. и целевая (конечная) М. модели данных;

2) отображается ЯОД Mi в Мj при инъективных операторах ψ: Вi → Вj и проверяется коммутативность диаграмм описания схем;

3) расширяется модель Мj до Мji, включая выбор схем аксиом σji, определения семантики множества операторов Оji, расширения Мji модели Мj и формальной проверки логической и операторной полноты;

Рис. 11.8. Преобразование данных различных моделей

4) строятся отображения ЯОД Мi в ЯОД Мji, ЯМД Мi в ЯМД Mji, включая проверку коммутативности диаграмм отображения схем и операторов.

Истинность системы аксиом должна быть инвариантна к изменениям, осуществляемым оператором ЯМД в Мji. Аксиома аji Î Мji является инвариантом модели данных М. по отношению к операторам Оji, если из истинности ajI(R), где R – реализация составного типа данных, на котором определяется а., следует истинность ajI(ojI(R)/R) для любого ojI Î OjI и произвольной R. Такая система аксиом должна быть логически и операторно полна.

Перечисленным требованиям расширяемой модели удовлетворяют ER-диаграммы [39] и реляционные модели [14, 15]. В последнем случае язык логики предикатов может служить основой построения аксиоматических типов данных.

Как показал опыт работ [39] и особенно [14, 15], универсальная модель достаточно объемна и сложна, а требование универсальности (в частности, для включаемых моделей бинарных отношений, семантических сетей, фреймов) излишне жестко и в практике необходимо редко.

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

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

При описании реляционной БД используем стандартный вариант языка SQL, полагая, что все нестандартности могут быть устранены путем использования приложения ODBC.

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

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

А. Вся сетевая МД считается совокупностью элементов-пар записей владелец – член [10], а структура записей предполагается простой (без агрегатов), без обратных связей.

Б. В структуре записей разрешаются агрегаты, структура наборов иерархическая и не имеет циклов [14, 15). Фактически идет преобразование системы наборов в систему таблиц (файлов).

Напомним важнейшие характеристики (табл. 11.5), определяющие структуру сетевой МД.

Таблица 11.5

Команды сетевой МД

Размещение	Пояснение	Отключение	Включение
CALC <ключ>	Кэширование	MANDATORY – обязательное уничтожение	AUTOMATIC – автоматическое
VIA <имя> SF.T	Хранение записей рядом
DIRECT	Работа программиста
SYSTEM	По умолчанию, сингулярные записи	OPTIONAL – необязательное уничтожение, передача	MANUAL – ручное, от SYSTEM
INDEX	Используется редко	SYSTEM

♦ А. Рассмотрим отдельно [10] две процедуры преобразования: сетевая – реляционная МД, реляционная – сетевая МД. В [10] такое преобразование (без операций) названо трансляцией.

Обозначим через N и R записи и отношения в сетевой и реляционной БД соответственно. Проделаем следующие действия.

1. Для любого типа записи Ni определим такое отношение:

а) Ri содержит один атрибут для любого элемента данных Ni;

б) если Ni имеет ключ, то ключ Ri соответствует ключу Ni, иначе – ключ Ri соответствует ключу БД N., который появляется в Ri как явный атрибут.

2. Для любой связи Lij, где Ni – запись-владелец, Nj – запись- член, определим реляционное ограничение и изменим существующее отношение так, чтобы:

а) ключ Ni появился как внешний ключ в Ri;

б) ввести ограничения в зависимости от типа членства.

Пусть X – внешний ключ (foreign key) FK(R.) отношения Ri в отношении Rj. Это ограничение обозначим FCij. Ключ X может быть и не определен (запись сетевой МД передается системе). Это факт обозначим NFC...

Результат преобразования сетевой модели в реляционную показан в табл. 11.6 для четырех случаев: 1) MANDATORY AUTOMATIC (МА); 2) MANDATORY MANUAL (ММ); 3) OPTIONAL AUTOMATIC (OA); 4) OPTIONAL MANUAL (OM).

Из табл. 11.6 видно, что преобразование возможно не для всех случаев.

Таблица 11.6

Преобразование сетевой МД в реляционную

MANDATORY AUTOMATIC	mandatory MANUAL	OPTIONAL AUTOMATIC	OPTIONAL MANUAL
Добавить FCij. 1. Кортеж отношения R, включается только при существовании кортежа отношения R. со значениями ключа, соответствующего значению FK(Ri) в добавляемом кортеже R j	Добавить NFCij. 1. Кортеж отношения Ri включается только при существовании кортежа отношения Ri со значениями ключа, соответствующего значению FK(R) в добавляемом кортеже Rj	Добавить NFCij. 1. Кортеж отношения Ri включается только при существовании кортежа отношения Ri со значениями ключа, соответствующего значению FK(Ri) в добавляемом кортеже Rj: значение FK(Ri) может быть нс определено
2. При удалении кортежа Ri необходимо удалить все кортежи Rj где FK(Ri) равно значению в удаляемом отношении Ri:	2. При удалении кортежа R. необходимо удалить все кортежи Ri, где FK(Ri) равно значению в удаляемом отношении Ri	2. При удалении кортежа Ri необходимо удалить все кортежи Ri, где FK(Ri) равно значению в удаляемом отношении Ri, а значение FK(Ri) должно быть заменено на "не определено"	2. При удалении кортежа R. необходимо удалил, псе кортежи Rj, тле FK(Ri) равно значению в удаляемом отношении Rj, а значение FK(Ri) должно быть заменено на "не определено"
3. При обновлении кортежа Ri значение FK(Ri) нс может заменяться на значение, которое нс соответствует ключу какого-либо кортежа R.	3. При обновлении кортежа Ri значение FK(Ri) не может заменяться на значение, которое не соответствует ключу какою-либо кортежа Ri

Преобразование реляционной модели в сетевую модель ведется по следующим правилам.

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

Пусть имеются реляционная схема р = {R1, ..., Rn}, первичные ключи любого отношения и считается, что функциональные типы связей представлены внешними ключами, а тип М:N отдельным отношением связи.

Тогда процедура перехода может иметь такой вид.

1. С помощью первичных ключей выявить все отношения "связи" и получить множество отношений а.

2. Для любого отношения Ri в р – α:

а) сформировать тип связи N1 с ключом, соответствующим первичному ключу Ri, при этом имя отношения становится именем типа записи, атрибуты отношения – элементами данных в типе записи;

б) для любого подмножества атрибутов (исключая первичный ключ в Ri), если это подмножество представляет собой в Ri первичный ключ, принадлежащий р – α (подмножество является внешним ключом), добавить связь Lij между типами записи Ni, соответствующей Ri, и Nj, соответствующей Rj, где внешний ключ есть первичный ключ.

При этом К становится типом записи-члена, а N – записи- владельиа. Удалить атрибуты, соответствующие ключу Rj из Nj.

3. Присвоить связи Lij уникальное имя и установить для связи тип членства:

а) сформировать тип записи Ni аналогично пункту 2а;

б) добавить по одной связи между типом записи N., соответствующим Ri, и любому из n других типов записей, участвовавших в связи, что определяется внешним ключом в Ri; Ni – общий тип записи-члена, а записи n – записи-владельцы в добавляемых связях (обычно n = 2).

Из табл. 11.6 следует, что преобразование возможно не для всех режимов сетевой базы данных.

♦ Б. В этом случае имеет место взаимооднозначность преобразования, поэтому рассмотрим только отображение сетевой МД в реляционную.

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

При многократном "вхождении" таблиц в работах [14, 15] предлагается использовать понятие "селекторный путь ("вхождения")". В этом случае преобразование может иметь несколько вариантов.

Преобразование реляционной модели данных в объектно-реляционную не представляет самостоятельного интереса.

Для гибридной разновидности ОРБД используется реляционная модель данных. Преобразование в расширенную реляционную модель равносильно переходу к объектно-ориентированной модели данных.

Преобразование реляционной МД в объектно-ориентированную МД характеризуется многовариантностью, поскольку одну и ту же задачу можно решить с использованием однородных или неоднородных (см. гл. 9) структур данных. Даже при использовании только неоднородных структур возможны разные варианты (ROW, ROW TYPE, их комбинации).

Преобразование объектно-ориентированной модели данных в реляционную похоже на переход от сетевой МД (при нелинейной структуре таблиц) к реляционной модели данных. Здесь фактически по-прежнему удобно использовать понятие "селекторный путь".