НПЦ «ИНТЕЛТЕК ПЛЮС»

Особенности создания корпоративных информационных систем на основе ОСУБД ODB-Jupiter 4.0

Андреев А.М., Березкин Д.В., Самарев Р.С.

НПЦ «ИНТЕЛТЕК ПЛЮС»

Тезисы доклада.

Введение

Внедрение компьютерных технологий в производство и управление предприятиями становится все более насущной задачей. Для хранения электронных документов и эффективной организации поиска предназначены информационно-поисковые системы (ИПС).

Такие системы разрабатываются в “НПЦ ИНТЕЛТЕК ПЛЮС” на основе собственной объектной СУБД ODB-Jupiter. При разработке ОСУБД ставилось несколько целей: обработка неструктурированной информации, хранение документов сложной структуры, встроенная поддержка полнотекстового поиска, возможность расширения набора типов в СУБД. Одна из ключевых особенностей ODB-Jupiter заключается в том, что в ядро ОСУБД встроен модуль полнотекстового поиска, что позволило очень эффективно реализовать индексацию и поиск текстовых данных, сохраняемых в базе.

В ОСУБД ODB-Jupiter встроены мощные средства разграничения доступа к объектам.

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

ОСУБД ODB-Jupiter дает возможность создавать новые типы объектов для своих нужд и модифицировать существующие. Для создания новых типов используется специальная программа - редактор схемы данных, который позволяет создавать новые типы, а также определять между ними отношения наследования. Т.е. можно, создать тип некоторого общего документа, а затем создать нескольких более конкретных потомков.

Документ - основное понятие в ИПС, построенных на базе ODB-Jupiter. Документ это информационная единица, состоящая из обязательного раздела - смысловой части (текста), набора реквизитов, которые упрощают поиск, организацию и классификацию и необязательного - ссылок на другие документы.

ИПС, построенные на базе ODB-Jupiter, обладают мощными поисковыми возможностями. Поиск ведется как по каждому виду документа в отдельности, так и по нескольким типам сразу.

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

Однако поисковые возможности ИПС ODB-Jupiter не исчерпываются только формальным поиском. Для более эффективного поиска пользователю предлагается несложный язык запросов. ИПС ODB-Text позволяет при формировании запроса разделять слова (или группы слов) пробелами или запятыми. Наличие пробела означает, что поиск будет по «И», запятой - что поиск идет по «ИЛИ». Для правильной интерпретации сложного запроса можно использовать круглые скобки. При поиске по тексту документа пользователю предоставляются дополнительные возможности создания запроса. Помимо всех возможностей форНПЦ «ИНТЕЛТЕК ПЛЮС»

мального запроса по реквизитам здесь можно задаваться расстоянием между словами в тексте.

Возможность формулировки запросов на естественном языке - одна из ключевых поисковых возможностей ODB-Jupiter.

Особенности реализации сервера ОСУБД ОСУБД ODB-Jupiter имеет клиент-серверную архитектуру. Структура сервера приведена на рис 1. Особенностью ОСУБД ODB-Jupiter является то, что она ориентирована на построение информационно-поисковых систем, следствием чего является наличие встроенных средств поддержки Web-клиентов.

Сервер имеет 3 интерфейса, принимающих запросы по протоколу TCP\IP:

- интерфейс для обслуживания запросов от клиентов ОСУБД с полноценным доступом;

- интерфейс для обслуживания запросов от Web-клиентов (запросы от Web-сервера перенаправляются специально программой-переходником);

- интерфейс для подключения программы администрирования.

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

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

В функции диспетчера запросов входит журнализация всех операций, выполняемых сервером для выполнения запросов пользователей. Возможна журнализация действий пользователей на нескольких уровнях детализации:

- регистрация имени пользователя, IP-адреса, с которого поступило обращение;

- регистрация выполняемых типов операций (добавление, удаление, чтение, изменение, поиск и пр.);

- регистрация идентификатора объекта;

- применительно к ИПС – регистрация названия объекта.

Модуль доступа к хранилищам реализован таким образом, чтобы обеспечить полноценное функционирования сервера ОСУБД с любыми хранилищами, в т.ч. использующих для хранения данных другие СУБД. Это позволяет обеспечить высокий уровень надежности за счет применения журнализации и двухфазных транзакций не только в собственных храНПЦ «ИНТЕЛТЕК ПЛЮС»

нилищах, но и в том случае, когда применяемое внешнее хранилище (или внешняя БД) не имеют соответствующих средств.

Web-клиенты Программа Клиенты администрирования WEB-сервер Сервер ОСУБД ODB-Jupiter Сетевой Интерфейс интерфейс администратора Обработка Web-запросов Интерфейс Селектор БД Web-клиентов Обслуживание БД Контроль Логика ИПС Диспетчер запросов безопасности HTMLМодуль Обработчики адаптер поддержки запросов сх. данных Поддержка шаблонов Доступ к Индексатор хранилищам Сервер данных Хранилище Хранилище Сервер обеспечивает возможность работы одной БД с несколькими хранилищами.

Это позволяет для каждого типа объектов использовать своё хранилище, а также организовывать разные БД, имеющие пересекающийся набор объектов одного типа, например общее хранилище безопасности с объектами, определяющими права доступа пользователей, хранилище с метатипами и пр.

Хранилища сервера Хранилища сервера ОСУБД работают в отдельных процессах, взаимодействие сервера ОСУБД с которыми производится через интерфейс CORBA, что позволяет их размещать в т.ч. на отдельных вычислительных системах (ВС). Это позволяет рассматривать процесс хранилища (или несколько таких процессов на одной ВС) как отдельный сервер хранилищ.

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

Хранилища ОСУБД ODB-Jupiter обеспечивают возможность одновременного использования нескольких разделов. Причем, в процессе эксплуатации возможно добавление новых разделов. Это позволяет, например, при необходимости увеличения объема хранилища, подключать дополнительные дисковые накопители в качестве нового раздела. Хранилище производит оптимальное заполнение разделов, обеспечивает журнализацию изменений, а также автоматическое резервирование данных (в виде копии текущего состояния и копий журнала операций) по заданному расписанию. Хранилище использует 64-битную нумерацию объектов, что теоретически позволяет хранить до 264 объектов объемом до 2 ГБ каждый, подключив до 216 разделов. При этом, возможно использование разных хранилищ для разных типов объектов, что теоретически позволяет еще больше увеличить допустимый объем БД. Предусмотрены средства ручного администрирования хранилищ.

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

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

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

Специальные средства кэширования позволяют оптимальным образом использовать доступную ОЗУ для минимизации дисковых операций при типовых запросах сервера ОСУБД.

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

Каждый объект ОСУБД ODB-Jupiter имеет уникальный идентификатор, состоящий из: 32-битного номера хранилища, определяемого временем создания хранилища, строковым именем типа с максимальной длиной 255 символов и 32-битного малого идентификатора объекта, уникального в пределах своего типа и хранилища. Полный идентификатор объект получает в момент своего создания, сохраняя его в дальнейшем. Это позволяет выполнять перенос объектов из одной БД в другую с такой же схемой данных без опасения встретить другие объекты с таким же идентификатором, поскольку в другом хранилище даже при пересечении имени типа и малого идентификатора объекта, идентификатор хранилища при создании этих объектов будет другим. Следовательно, появляется возможность переноса объектов с учетом всех связей.

Каждый объект содержит запись о своей дате создания и дате модификации.

Сервер ОСУБД выполняет операции с объектами, основываясь на схеме данных.

Среди системных типов можно выделить следующие:

Register – тип, являющийся описателем других типов.

%Level, %Category, %Area, %Group, %User – типы для хранения объектов-описателей безопасности.

Для каждого нового типа создается объект типа “Register”, содержащий:

- имя типа и список его алиасов (применительно к ИПС отображаемое имя типа может отличаться от системного);

- список предков (множественное наследование разрешено, но конфликты имен должен устранять пользователь);

- уникальный номер типа в пределах схемы данных;

- список описателей реквизитов.

Описатель реквизита представляет собой следующую структуру:

- название реквизита;

- номер реквизита в типе, который не меняется при любых изменениях типа;

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

Администратору доступны следующие типы реквизитов:

- целое число со знаком 16 бит;

- целое число со знаком 32 бита;

- целое число со знаком 64 бита;

- вещественное число 16 бит;

- вещественное число 32 бита;

- строка без разбиения переменной длины;

- строка с разбиением переменной длины (при индексации каждое слово строки рассматривается как отдельный ключ);

- двоичные данные (до 2 ГБ);

- текст документа (отличается от строки иным режимом индексации и поиска).

Администратор имеет возможность изменения типов и набора реквизитов в том числе в процессе эксплуатации системы. Причем, сервер обеспечивает хранение объектов даже с такими реквизитами, которые не заданы схемой данных.

Администратор задает хранилища для хранения типов. На рис 4 приводится пример назначения типов.

Для каждого типа может быть задано свое хранилище или несколько типов хранится в одном хранилище. Кроме того, администратор может вообще не распределять типы по хранилищам, а задать для типа “Unknown” единственное хранилище. Тогда, модуль поддержки схемы данных будет направлять запросы рис. 3 Назначение типов хранилищам.

на обращения к хранилищам в соответствии с типом “Unknown”. Возможны любые комбинации с этим типом.

Разделение прав доступа Реализация разграничения прав доступа.

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

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

Таким образом, ОСУБД ODB-Jupiter реализует как дискреционную, так и мандатную модели безопасности.

Произвольный контроль.

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

- Чтение – вид доступа, связанный с операцией чтения объектов и с операцией получения результатов поиска.

- Изменение – вид доступа, связанный с операцией изменения объекта или с операцией создания объекта.

- Удаление – вид доступа, наличие которого позволяет выполнить операцию удаления объекта из системы.

- Изменение дескриптора безопасности объекта (ДБО) – вид доступа по изменению - Смена владельца – вид доступа, связанный с операцией назначения другого владельца объекта.

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

Принудительный контроль.

Реализация принудительного контроля доступа, соответствует мандатной модели безопасности. Как отмечалось, в дескрипторе безопасности объектов и в учетных записях пользователей имеются метки безопасности «чтения» и «записи», они ставятся в соответствие уровням безопасности, рассмотренным в мандатной модели безопасности. Метка имеет следующую структуру:

- Уровень секретности – элемент упорядоченного множества, такого как например:

несекретно, конфиденциально, секретно, совершенно секретно и т.д.

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

Доминирование меток Пусть имеется две метки: А и Б. Операция проверки доминирования позволяет осуществить мнимое отображение меток на элементы множества уровней безопасности L, характерное для модели безопасности Белла-ЛаПадулы, что в свою очередь дает возможность их сравнения. Указанное отображение приведено на рис. 3.