СУБД Ника

Осенью 1995 года российская фирма Cognitive Technologies выпустила систему архивации документов "Евфрат", сочетающую в себе функции OCR и базы данных. Эта система позволяет содержать отсканированные и распознанные документы в определенном порядке, а также производить поиск по ряду признаков. Для организации хранения и поиска документов разработчики Cognitive Technologies использовали СУБД "НИКА", созданную по большей части в Институте Системного Анализа РАН (до 1992 г. - ВНИИСИ) в возглавляемой профессором Николаем Евгеньевичем Емельяновым лаборатории банков данных.

СУБД "НИКА" создавалась в течение последних пяти лет коллективом единомышленников, имеющим двадцатилетний стаж разработки СУБД. Идеологически "НИКА" является наследницей СУБД "ИНЕС", работавшей на больших машинах серии ЕС ЭВМ - она использует сетевую модель данных, построенную на базе иерархической модели.

Первая промышленная версия ИНЕС появилась в 79 г., а в 82 г. у ИНЕС насчитывалось уже около тысячи пользователей. В 80-х годах наряду еще с пятью-шестью другими СУБД, работавшими на машинах серии ЕС, СУБД ИНЕС была довольно популярна в СССР. Эти пять-шесть СУБД являлись в основном адаптированными или, говоря современным языком, взломанными западными СУБД. Так, ОКА была адаптированной IMS фирмы IBM, а ДИСОД - адаптированным ADABAS'ом. Взлом СУБД производился на уровне исполняемых модулей и по большей части заключался в замене английских текстовых строк (сообщений, названий) на русские. Английская документация также подвергалась своеобразному взлому - ее переводили, перетасовывая в переводе абзацы и главы так, чтобы получившийся текст формально нельзя было признать тождественным исходному. Хотя адаптацией занимались целые институты, полученные таким образом продукты по качеству сильно уступали оригиналам. (Я вовсе не хочу порицать программистов, занимавшихся адаптацией или принизить их труд. Всякому, кто знаком с программированием, понятно, что разобраться в чужой программе и внести в исполняемые модули необходимые изменения так, чтобы программа не утратила работоспособности, - долгая, тяжелая, кропотливая работа. По всей видимости, решения об адаптации принимались не самими специалистами, а, как это часто бывало в советские времена, спускались откуда-то сверху.) Программисты, которым по распоряжению начальства устанавливали, скажем, ДИСОД, старались всякими правдами и неправдани достать натуральный ADABAS и неизуродованную документацию. О технической поддержке в таких условиях, разумеется, не могло быть и речи. ИНЕС очень выигрывала на этом фоне, поскольку являлась оригинальной отечественной разработкой, и поддерживалась авторами в тех формах, которые были тогда приняты. Конкурирующие с ИНЕС СУБД были либо иерархическими (ОКА, она же IMS), либо сетевыми (ДИСОД, он же ADABAS, СЕТЬ, она же IDMS). Поэтому сетевая СУБД ИНЕС вовсе не выглядела "белой вороной", как НИКА сегодня, когда болшинство СУБД используют реляционную модель. Примечательно, что еще в 80-х годах в СУБД ИНЕС были реализованы элементы визуального программирования. Дерево, описывающее структуру БД, можно было нарисовать в специальном редакторе, используя некоторые символы. В ИНЕС имелось также средство, функционально аналогичное современным генераторам отчетов, таким, как ReportSmith или Crystal Reports. Это средство позволяло по нарисованному на экране алфавитно-цифрового терминала макету (бланку) получить соответствующим образом распечатанные данные из БД.

Согласно принятой в ИНЕС, а затем и в НИКЕ модели, данные организуются в дерево, которое может быть "оплетено" сетью ссылок (указателей). При этом различаются Дерево Описания Данных (ДОД), в котором хранится информация о структуре БД, и Дерево Данных (ДД), в котором хранятся сами данные.

ДОД строится из нескольких базовых типов (int, float, text, date, time и др. ), объединяемых при помощи двух конструкторов - массива и структуры. Также, как в некоторых языках программирования, (в С/C++ или в Pascal) структуры могут быть элементами массива, а массивы - элементами структуры. В описании данных допускается рекурсия, что позволяет удобно моделировать иерархические взаимосвязи с произвольным количеством уровней. Поскольку древовидная структура в чистом виде существенно ограничивает возможности построения БД, вводится специальный тип данных, ссылка на значение, посредством которой можно привязать к некоторому узлу ДД данные, расположенные в других узлах. Кроме ссылок на значение бывают еще ссылки на шаблон, не соответствующие никакому типу данных, и выполняющие примерно ту же функцию, что вызовы процедур в программе. С их помощью в некотором узле ДОД можно "процитировать" описанный ранее фрагмент этого же ДОД. Именно этот прием и позволяет делать рекурсивные описания данных. ДОД принято изображать в виде схемы, состоящей из специальных соединенных между собой значков (рис. 1).

На рис 2. приведен упрощенный фрагмент ДОД, задающего структуру БД системы "Евфрат".

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

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

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

В XBase системах подобный результат достигается применением команд SET ORDER или SET FILTER. Подсхема, называемая "разузлование", (рис. 5) хорошо подходит для хранения информации об объектах, состоящих из объектов того же типа, что и они сами.

Детали могут состоять из других деталей, регионы (ср. с примером выше) - включать в себя другие регионы и т. п. Классификатор (рис. 6) отличается от разузлования тем, что в нем вместо ссылки на значение используется ссылка на шаблон. Это типичный случай рекурсии в описании данных.

Конечно, нет в мире совершенства. За богатство возможностей, предоставляемых разработчику сетевой моделью данных, приходится платить сроками, трудоемкостью и дороговизной разработки самой СУБД. В этом смысле условия советского НИИ были исключительно благоприятны для появления таких систем, как "ИНЭС" и "НИКА". Сотрудники НИИ не старались поскорее получить прибыль от своей работы, ибо такое попросту не предусматривалось советским строем, и могли годами развивать идеи, которые считали красивыми и правильными, не боясь падения курса акций или банкротства. "НИКА", правда, была создана уже после развала социалистического строя, но, так сказать, научная база для нее накапливалась именно в социалистические времена. Может быть поэтому на российском рынке практически отсутствуют западные продукты, аналогичные "НИКЕ". Исключение составляет довольно популярная СУБД db_VISTA фирмы Raima Corporation. В этой СУБД сетевая модель данных основывается на реляционной. В db_VISTA данные хранятся в таблицах, состоящих из записей, причем записи из одной таблицы могут "владеть" записями из другой (или той же самой) таблицы. Скажем, записи из таблицы "Области" могут владеть записями из таблицы "Районы". Множество записей из одной таблицы, подчиненных некоторой записи, образуют своего рода "подтаблицу", называемую в терминах db_VISTA набором. Такая модель данных отличается от реляционной тем, что, во-первых, для установления отношения не требуется специально вводить в подчиненные записи служебные поля (такие, как "ID Области" в предыдущем примере), и, во-вторых, логикой обращения к БД. В реляционных СУБД в каждой таблице есть свой курсор и между таблицами можно переключаться, а в db_VISTA на всю БД есть один единственный курсор, который можно переставлять из одной таблицы в другую, перемещать в пределах одной таблицы, в пределах одного набора, а также переставлять с записи-владельца на элемент набора или наоборот. По сути дела, db_VISTA - это реляционная СУБД, о которой предлагается думать, как о сетевой. Собственно, для любой реляционной СУБД можно написать надстройку, эмулирующую сетевую модель данных. В отличие от db_VISTA, "НИКА" принципиально незаписеориентированна. Данные представляются в виде сети объектов, в которой каждый объект, вообще говоря, может жить своей отдельной жизнью. Так, "НИКА" позволяет готовому приложению (вернемся к случаю с районами и областями) добавить в структуру, содержащую информацию о Тамбовской области, специфичное только для этого объекта поле "Поголовье_волков", причем все остальные структуры из массива "Области" не претерпят абсолютно никаких изменений.

Что же представляет собой "НИКА" как программный продукт? В стандартную поставку входят

Кроме того, доступно несколько созданных на базе СУБД "НИКА" пакетов, поставляемых отдельно, в частности система "МАГИС", способная автоматически генерировать информационно-поисковые системы по макетам входных и выходных форм.

Существуют версии СУБД "НИКА" для MS-DOS и для Windows. В сетевой версии предусмотрена программа, разграничивающая доступ нескольких пользователей к БД, и ряд библиотечных функций, предназначенных для написания серверной и клиентской частей приложения.

Определенно, в жизни "НИКИ" произошло важное событие. Ранее эта СУБД использовалась в основном самими разработчиками при реализации масштабных проектов (один из них - информационная система Исторического музея). Еще пользователями "НИКИ" становились крупные предприятия и ведомства, информационные системы которых были основаны на СУБД "ИНЕС" (характерный случай - информационная система, применяемая в секретариате первого зам. министра обороны РФ для управления государственным оборонным заказом). Теперь же "НИКА" впервые была использована для изготовления массового продукта, т. е. в промышленных масштабах. Трудно сказать, займет "НИКА" после этого различимый на диаграмме сектор рынка СУБД или нет, но, во всяком случае, нереляционная СУБД - это само по себе интересно.

Знаете ли Вы, что "тёмная материя" - такая же фикция, как черная кошка в темной комнате. Это не физическая реальность, но фокус, подмена.
Реально идет речь о том, что релятивистские формулы не соответствуют астрономическим наблюдениям, давая на порядок и более меньшую массу и меньшую энергию. Отсюда сделан фокуснический вывод, что есть "темная материя" и "темная энергия", но не вывод, что релятивистские формулы не соответствуют реалиям. Подробнее читайте в FAQ по эфирной физике.