Хранилища Данных (Data Warehouse) - это архитектура построения корпоративных информационных систем, получившая развитие вследствие желания конечных пользователей иметь непосредственный единообразный доступ к необходимым им данным, источники происхождения которых организационно и территориально распределены, а анализ которых может способствовать принятию решений [10]. Билл Инмон, автор концепции Хранилищ Данных, определил их как "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления", призванные выступать в роли "единого и единственного источника истины", обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений [1]. Ричард Хакаторн, другой основоположник этой концепции, писал, что цель Хранилищ Данных - обеспечить для организации "единый образ существующей реальности" [2].

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

По мнению авторов, наиболее адекватно информационные сущности описываются с помощью иерархии объектов. Не случайно именно иерархическое представление принято в моделировании для анализа структуры сложных систем. В свое время такой подход был успешно реализован в отечественной СУБД ИНЕС [3], а сегодня используется в СУБД Datacom/DB компании Applied Data Research, Inc. (ADR) и Adabas компании Software AG [4], а также в некоторых постреляционных СУБД. В данных системах логическое представление информации в виде иерархической модели соответствует физическому методу хранения данных. Однако, по многим причинам, практически всегда кажется более предпочтительным вести Хранилище Данных с помощью серверов реляционных СУБД: во-первых, в настоящее время ряд ведущих производителей этих серверов (Informix, Oracle, Sybase и др.) значительно вырвались вперед по сравнению со своими конкурентами по уровню производительности машин баз данных; во-вторых, Хранилища Данных практически всегда создаются в качестве настройки над множеством существующих систем обработки данных (СОД) [5], которые производят обслуживание проблемно-ориентированнных (ведомственных) реляционных баз данных с помощью унаследованных систем (legacy systems); наконец, язык SQL для реляционной модели является единственным языком манипулирования данными, имеющим общепринятый мировой стандарт. Поэтому в своей работе авторы стремились к тому, чтобы, оставаясь на реляционной платформе, воспользоваться преимуществами иерархического и сетевого подхода в процессах семантического моделирования структуры Хранилища Данных и навигации по находящимся там информационным объектам.

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

Если рассматривать Хранилище Данных как логическую конструкцию, то метаданные - это внешнее представление Хранилища. Без наличия актуальных, максимально полных и легко понимаемых пользователем метаданных Хранилище Данных превращается в обычный, но очень дорогостоящий архив. В настоящее время стандарт метаданных только разрабатывается [7], однако де-факто общепринятыми являются следующие типы метаданных [6]:

• Навигационные метаданные, которые можно назвать "данными о данных", помогают конечным пользователям, выполняющим запросы к Хранилищу Данных. Этот тип метаданных, также называемый семантическими метаданными, обеспечивает конечному пользователю возможность восприятия информации Хранилища в виде понятных ему категорий и составляющих их элементов.
• Управляющие метаданные облегчают процесс извлечения, преобразования, перемещения и загрузки (так называемый ETML-процес). Этот слой метаданных используется разработчиками, когда данные собираются в Хранилище Данных из различных источников (СОД). Данный тип метаданных идентифицирует расположение исходных данных и их формат, а также содержит логику, необходимую для преобразования исходных данных в формат Хранилища и согласование данных различных источников. Этот тип метаданных важен ещё и потому, что процесс обновления Хранилища из внешних источников должен производиться автоматически по заранее заданному регламенту, поэтому на этапе формирования этих метаданных требуется учитывать способы разрешения большого количества потенциально возможных коллизий.
• Реляционные метаданные - это традиционные метаданные, используемые администратором базы данных, чтобы поддерживать реляционную структуру БД в целостном и непротиворечивом состоянии.

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

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

Описания Хранилища Данных семантическими моделями, входящими в состав метаданных, выполняется администратором системы. При этом метаданные одного Хранилища Данных могут включать теоретически неограниченное количество концептуальных представлений, что объясняется различными потребностями в получении информации отдельных категорий пользователей [9].

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

1. Один к одному (1:1). Рассматриваемый атрибут является простым реквизитом вышестоящего по иерархии атрибута. Пример - полное наименование организации по отношению к ее уникальному регистрационному номеру в справочнике юридических лиц.
2. Многие к одному (M:1). Рассматриваемый атрибут может быть элементом некоторого справочника, однозначно соответствующим экземпляру вышестоящего атрибута. Пример - связь между описанием административно-территориального образования (код ОКАТО), в котором находится организация, и уникальным кодом этой организации; территория может включать, теоретически, неограниченное множество организаций, но местом расположения организации может быть лишь одна территория; при этом атрибут "территория" описывает организацию.
3. Один ко многим (1:M). Экземпляру вышестоящего атрибута может соответствовать неопределенное количество экземпляров рассматриваемого атрибута, но экземпляр рассматриваемого атрибута связан только с одним экземпляром вышестоящего. Пример - связь множества банковских счетов с одним владельцем - юридическим лицом; при этом "банковский счет" является множественным атрибутом, характеризующим организацию.
4. Многие ко многим (M:N). Рассматриваемый и вышестоящий атрибут связаны множественным отношением, что позволяет экземпляру одного из них соответствовать произвольному множеству экземпляров другого. Пример - список юридических лиц и список возможных учредителей; каждое юридическое лицо может создаваться несколькими учредителями, а каждый учредитель может принимать участие в создании ряда юридических лиц.

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

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

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

Предлагаемый авторами подход позволяет избежать такой статичности. Идея заключается в том, что каждый смысловой атрибут может быть объявлен как потенциально корневой, даже если он является промежуточной вершиной основного дерева. Для каждой такой вершины может быть автоматически получена альтернативная иерархия атрибутов, в которой подграф, расположенный ниже вершины, останется без изменений, а остальная часть дерева будет инвертирована. Поскольку каждая связь, как уже говорилось выше, определяется типом отношения (1:1, 1:М, M:1, M:N), при инверсии подграфа тип каждой входящей в него ветви меняется на противоположный. Таким образом, из одного основного дерева может быть порождено множество альтернативных иерархий - лес. Тем самым достигается множественность возможных точек входа в модель, то есть поли-иерархический взгляд на единое Хранилище Данных.

Реализация обработки Хранилища Данных через построенную модель (поиск информационных объектов, модификация и ввод информации) реализована в корпоративной информационно-поисковой системе ИнфоВизор-Реестр. Данный подход позволяет организовать формирование любого нерегламентированного запроса к Хранилищу Данных, а следовательно и гибкий поиск и модификацию в любой области Хранилища. Дело в том, что одно логическое дерево атрибутов не позволяет описать все виды возможных запросов пользователя к информационной модели. Искусственно выделив один из атрибутов в качестве корневого объекта иерархии, мы ограничиваем целевую часть запросов экземплярами этого атрибута. Так, в рассмотренном в списке типов отношений примере корневым атрибутом можно объявить уникальный регистрационный номер юридического лица. Но в этом случае любой поиск - по территории, банковским счетам, учредителям и так далее - всегда будет ориентирован на нахождение соответствующих критериям запроса экземпляров самих организаций (например - найти все организации, наименования которых включают слово "научный", находятся на территории города N, владеют хотя бы одним счетом в банке X и имеют учредителя Y). Переориентация целевой части запросов на другой атрибут возможна только при наличии альтернативной иерархии с корневой вершиной, соответствующей этому атрибуту (в рассмотренном примере - территории, банковскому счету, учредителю и так далее).

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

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

Задача построения иерархических моделей над структурой реляционного Хранилища Данных возлагается на систему ИнфоВизор-Администратор, в функции которой, помимо формирования метаданных, входит контроль целостности Хранилища Данных, управление доступом и так далее.

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

Список литературы

1. W. H. Inmon. Building The Data Warehouse (Second Edition). - NY, NY: John Wiley. - 1993.
2. D. Hackathorn. Reinventing Enterprise Systems Via Data Warehousing. - Washington, DC: The Data Warehousing Institute Annual Conference, 1995.
3. Н. Е. Емельянов. Введение в СУБД ИНЕС. - М.: Наука, 1988.
4. Л. Л. Винокуров, Д. В. Леонтьев, А. Ф. Гершельман. СУБД ADABAS - основа универсального сервера баз данных // СУБД. - 1997. - №2. - С. 36-40.
5. А. А. Сахаров. Концепции построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 1996. - №4. - С. 55-70.
6. J. Hurwitz. The Evolution of Metadata // DBMS. - 1997. - Vol. 10, №8. - Р. 12-15.
7. М. Леон. Соревнование стандартов на метаданные // ComputerWorld-Россия. - 1996. - №41. - С. 23.
8. R. Sherman. Metadata: The Missing Link // DBMS. - 1997. - Vol. 10, №9. - Р. 73-75.
9. J. Tyo. Каждому пользователю - свое представление данных // ComputerWeek-Москва. - 1996. - №38. - С. 32-33.
10. N. Raden. Данные, Данные и только данные // ComputerWeek-Москва. - 1996. - №8. - С. 28.