Universe и jBase: "multivalued" СУБД.

Илья Шабаев (АРК)

Историческая справка

История группы современных Multivalue СУБД идет от системы PICK

В середине шестидесятых Дик Пик и Дан Нелсон (Dick Pick , Don Nelson) по заказу военного ведомства США разработали систему управления военными запасами, предоставлявшую пользователям возможность делать запросы на естественном языке.

Проект получил название GIRLS (Generalized Information Retrieval Language and System).

В дальнейшем это привело к созданию коммерческой версии системы. Все права на эту систему получил Дик Пик. Она включала в себя функции операционной системы, СУБД, и средств разработки. Система была написана на псевдо-ассемблере и транслировалась в исполняемые коды машин. Благодаря такой возможности OS PICK портирована более чем на 50 типов платформ в течение почти 20 лет.

Удивительно, что за эти 20 лет система практически не изменялась. Впрочем, по тогдашним временам в OS PICK были реализованы передовые технологии: виртуальная память, естественный язык запросов, произвольная длина данных в структуре СУБД, (переменная длина записи и произвольная структура), язык BASIC с расширениями, ориентированными на обработку данных и другие. Но самое главное это то из-за чего весь класс СУБД теперь именуется "Multivalue" - это возможность хранить и обрабатывать множество значений внутри поля записи данных.

Из-за того что компания PICK Systems долгое время не развивала систему, выпуская OS PICK в стандарте R83, многочисленные лицензиаты компании начали самостоятельно вносить усовершенствования в систему такие как вторичные индексы, журналирование транзакций, языки 4GL. Кроме "клонов PICK" появились также СУБД реализующие PICK модель данных но работающие под другими операционными системами UNIX, MSDOS, Windows NT. Всего было выдано около 20 лицензий различным компаниям которые выпускали подобные СУБД. В начале 90-х Pick Systems сделала то же самое - выпустила продукт Advanced Pick, который функционировал как СУБД под UNIX.

Сейчас, основными игроками на рынке PICK-подобных СУБД являются следующие компании:

Raining Data - бывшая Pick Systems	D3 Native Pick mv.BASE
IBM	U2 (UniVerse & UniData)
JBASE	jBASE

Об основных продуктах этих фирм (D3, UniVerse, jBASE) далее и пойдет речь в этой статье.

Архитектура Систем

Архитектурные различия СУБД D3, UniVerse, jBASE таковы:

Сервер D3 представляет собой виртуальную машину баз данных, все основные процессоры которой написаны на псевдо-ассемблере. Все пользовательские процессы обращаются с запросами к серверу базы данных, который управляет виртуальной памятью и дисковым пространством.

Подобную архитектуру используют СУБД ORACLE, INFORMIX. Она предоставляет широкие возможности для оптимизации запросов, реализации многонитевой архитектуры для поддержания многопроцессорной архитектуры и т.п. Для хранения данных операционной системой выделяется только некое дисковое пространство (Raw Disk) и оперативная память. Все управление выделением / освобождением памяти, сборкой мусора и другими подобными процессам занимается сервер базы данных.

Серверы jBASE и UniVerse все подобные функции отдают операционной системе под которой они функционируют, оставляя за собой функции выполнения запросов и обработки данных. Более того, фактически все запросы выполняет сам пользовательский процесс, оставляя серверу базы данных функции арбитра системных и пользовательских блокировок. Таким образом, для вызова пользовательского процесса система не выделят первоначально больших ресурсов, производится только регистрация процесса в разделяемой памяти. Такая архитектура легковесных процессов, несмотря на кажущиеся недостатки, имеет большое количество преимуществ. Возможность построения распределенных систем в кластерах, естественная масштабируемость в SMP и MPP архитектурах, простота использования в WEB технологиях, позволила разработчикам этих СУБД сконцентрировать свое внимание на функциональности систем и получить значительный выигрыш на рынке Multivalue систем.

Особенности Multivalue СУБД

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

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

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

Ну а как насчет управления отношениями в реляционных базах данных? Основной механизм создания отношений - объединение. Здесь возникают три главные проблемы. Во-первых, большинство людей не понимает, что из себя представляет объединение. Более того, поскольку базы данных должны быть нормализованы, то работа с реальными представлениями часто требует многочисленных объединений. Очень сложно, объяснить людям, которые далеки от технических наук, как соединить 15 или 20 таблиц для представления данных. И часто, в процессе создания объединения, результурующее представление работает неэффективно, иными словами, медленно.

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

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

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

Не первая нормальная форма NF2

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

При том, что таблицы, строки и колонки так удобно отражают наше мышление, почему же они стали само-ограничивающими для более крупных приложений? В основе проблемы лежат три вопроса:

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

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

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

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

Многие методологии проектирования данных позволяют определять многозначные поля и затем удалять в процессе нормализации. При этом таблицы преобразуются в первую нормальную форму или 1NF. Однако удаление многозначных полей не всегда способствует улучшению прикладных программ. В случаях, когда обычная форма доступа к полю подразумевает обращение ко всем его значениям, базе данных 1NF придется проделать операцию соединения (Join) каждый раз, когда нужно получить соответствующие значения, хранящиеся в другой таблице. Совершенно очевидно, что в подобной ситуации хранение значений физически в многозначных полях может обеспечить более эффективный доступ к информации.

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

ORDER

INVNO	CUSTNO	GOODS	QTY
0373	8723	Пиво	3
0373	8723	Вобла	2
8374	8232	Лимонад	1
8374	8232	Пиво	6
8374	8232	Вафли	2
7364	8723	Йогурт	1

Рис. 1a. Представление данных в 1-й номальной форме (1NF)

ORDER INVNO CUSTNO 0373 8723 8374 8232 7364 8723

ORDER ITEMS INVNO GOODS QTY 0373 Пиво 3 0373 Вобла 2 8374 Лимонад 1 8374 Пиво 6 8374 Вафли 2 7364 Йогурт 1

Рис. 1б. Дальнейшая нормализация (2NF)

ORDER

INVNO	CUSTNO	GOODS	QTY
0373	8723	Пиво	3
		Вобла	2
8374	8232	Лимонад	1
		Пиво	6
		Вафли	2
7364	8723	Йогурт	1

Рис. 1в. Структура хранения данных в jBASE NFNF (NF2)

Рисунок 1. Структуры хранения данных с многозначными полями в jBASE и в традиционных системах. Так как в jBASE можно создавать многозначные поля переменной длины, все заказы могут храниться в одной таблице. При этом для хранения нужно меньше места и при обработке не требуется объединять данные, что повышает эффективность хранения данных.

О таблицах, содержащих многозначные поля, говорят, что они находятся в непервой нормальной форме, или NF2 (Non First Normal Form). Как было замечено ранее, при условии, что используемые поля подчиняются определенным правилам, позволяющим обращаться с ними, как с таблицами, встроенными в другие таблицы, форма NF2 не нарушает принципы реляционной алгебры. Более того, такая информация полностью доступна, так как расширенные операторы, которые работают с таблицами NF2, позволяют извлекать встроенные таблицы и рассматривать данные как информацию, поступившую из таблиц 1NF. И все же во многих случаях форма 1NF будет скорее исключением, а не правилом. В большинстве случаев гораздо более эффективно осуществлять доступ к многозначным полям одновременно с остальными данными, зная, что их всегда можно извлечь и рассматривать как отдельную таблицу в тех случаях, когда это может понадобиться.

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

Многозначные поля и ассоциации не могут вкладываться друг в друга. Расширение синтаксиса SQL позволяет осуществлять доступ к множественным полям как расширение реляционной модели, но, конечно, можно применять также стандартные и другой язык запросов jBASE - jQL. В целом многозначность полей является очень полезным свойством при создании коммерческих приложений, где информация нередко представлена в виде списков предметов.

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

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

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

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

Вложенные таблицы

Использование вложенных таблиц полностью отражает основную задачу реляционной модели - обеспечение пользователя простой логической структурой данных. Фактически, вложенные таблицы еще более упрощают логическое предcтавление данных и являются естественным расширением реляционной модели. Расширение реляционной базы данных предлагаемое фирмой IBM позволяет использовать вложенные таблицы как атрибуты с множественными значениями и связанные группы таких атрибутов. Для создания таблицы показанной на рис 1в может быть использовано следующее SQL предложение:

CREATE TABLE ORDER 
  	(INVNO INT NOT NULL PRIMARY KEY,
  	CUSTNO INT,
  	GOODS CHAR(25) MULTIVALUED NOT NULL,
  	QTY INT MULTIVALUED,
  	ASSOC PHONES (GOODS, QTY));

В данном случае атрибуты с множественными значениями определяются словом MULTIVALUED, а связанные группы - словом ASSOC. Конечно, если необходимо представление данных в первой нормальнй форме, Ardent предоставляет механизм для динамической нормализации данных (в процессе запросов). Для данной цели в SQL синтаксис расширен ключевым словом UNNEST.

Вложенные реляционные отношения

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

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

Другие возможности использования Multivalue СУБД

Возможность построения нереляционных моделей данных на основе Multivalue СУБД нашла реализацию в построении хранилищ данных. Так фирма IBM предлагает продукт под названием MITS, который реализует хранилище данных на базе СУБД UniVerse. Это полноценный инструмент для построения систем принятия решений, реализующий Hypercub в качестве сервера хранилища включает также набор инструментов для построения, администрирования и управления хранилищем и набор средств Business Intelligence и интерфейсов для других OLAP средств.

Другим брендом в области хранилищ данных является продукт ETL DataStage фирмы Ascential Software, который реализован также на базе СУБД UniVerse и использует ее мощные возможности обработки данных для построения хранилищ данных из различных источников данных.

Илья Шабаев
ARK Commersal
ila@ipmce.ru