Открытая информационная модель репозитариев Microsoft

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

Патрик Кросс, Саид Раими,SQL Server Magazine OnLine/RE, #02/2000

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

Усилия созданной рабочей группы увенчались выпуском Открытой информационной модели (OIM - Open Information Model), которая содержит определения более 300 типов объектов и взаимоотношений между ними. Это было важным начинанием, ведь рабочей группе необходимо было ясно определить и описать в документации каждый тип объекта, его обязательные характеристики и отношения. Поскольку информационная модель определяет метаданные в терминах типов объектов, очевидным решением было использование подходящей методологии объектного моделирования. В качестве языка, пригодного как для написания документации, так и для обсуждения информационной модели, группа выбрала UML (Unified Modeling Language). Теперь и сама OIM превратилась во всеобщий язык описания информации в репозитариях.

В июле 1999 корпорация Microsoft передала право собственности на OIM коалиции MDC (Meta Data Coalition), независимой организации, призванной создавать общие стандарты по обмену информацией о системах (метаданными). По мере развития первоначальной модели коалиция MDC намерена поддерживать производителей программных средств и помогать им использовать OIM в своих разработках. MDC опубликовала форматы XML (Extensible Markup Language) для применения в качестве метода обмена данными между различными инструментальными средствами, использующими OIM. Этот стандарт облегчает ввод и вывод данных в репозитарий Microsoft и инструментальные средства других производителей, заметно снижая сложность соответствующих процедур.

В настоящий момент корпорацией Microsoft и ее партнерами принята к применению версия OIM 1.0, проект следующей версии 1.1 был представлен в ноябре 1999. Приводимые ниже примеры и описания взяты из модели 1.1. Чтобы эти примеры смогли функционировать, им необходима версия 3 Microsoft Repository, которая входит в состав SQL Server 2000. Предыдущая версия 2 не поддерживает наследуемые коллекции и свойства, которые широко используются в OIM.

Open Information Model охватывает многие области, включая:

• анализ и проектирование UML и его расширений, групповых элементов, общих типов данных и моделей <Сущность-связь>;
• объекты и их компоненты;
• базы и хранилища данных: схемы реляционных баз данных, преобразования данных, схемы OLAP, схемы баз данных с ориентацией на записи, схемы XML, определения отчетов;
• проектирование бизнеса: цели, правила и процессы; организационные элементы;
• управление знаниями: описания знаний и семантические определения.

С точки зрения перспектив развития хранилищ данных наиболее важными моделями являются схемы реляционных баз данных, преобразований данных и схемы OLAP. Любую модель можно загрузить с сайта Meta Data Coalition в сети Web в виде файла .mdl, а затем просмотреть ее при помощи Visual Modeler или Rational Rose.

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

Схема реляционной базы данных

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

Обычно наполнение схемы реляционных баз данных SQL Server производится сканером OLE DB, поставляемым в составе SQL Server 7.0. На схеме 1 показаны базовые компоненты поиска и обновления информации о реляционной базе данных. Источник данных, DataSource в OIM соответствует серверу в терминологии SQL Server (обычно приводится имя компьютера). Для других СУБД в качестве источника данных подставляется то имя, которое возвращает поставщик OLE DB. Как правило, это имя источника данных. В каждом источнике данных развернуты каталоги, DeployedCatalogs, (или базы данных в терминах SQL Server). Чтобы попасть в каталоги из источника данных, необходимо следовать коллекции DeployedCatalogs. Каталоги содержат схемы, доступ к которым осуществляется через коллекцию Schemas. Она содержит таблицы, достичь которых можно при помощи коллекции Tables. Затем следуют столбцы таблиц, ColumnSet, к которым можно попасть через наследуемую коллекцию Columns. Так как OIM базируется на стандарте UML, интерфейсы могут наследовать свойства других интерфейсов в соответствии с концепцией наследования, принятой в объектном моделировании и UML. Она заключается в том, что интерфейс приобретает все свойства и отношения, существующие в наследуемом интерфейсе. Так, таблицы Tables наследуют все свойства набора столбцов ColumnSet, содержащего коллекцию Columns. Тип данных столбца ищется в коллекции DataType.

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

Модель преобразования данных

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

Подобно модели OLAP модель преобразования использует подмодели, в которых хранятся объекты, характерные для модулей преобразования DTS (Data Transformation Services). Заполнение модели преобразования происходит автоматически, когда модули записываются в репозитарий.

На схеме 2 показано, как можно проделать путь в обратном направлении: от завершающего элемента цепочки, столбца хранилища данных, к исходному столбцу системы-источника. В рассматриваемом случае для понимания того, как работает данная модель, чрезвычайно важно правильно представлять себе процесс наследования. Объект ModelElement является одним из базовых объектов в модели UML. Большинство остальных объектов прямо или косвенно наследуют его свойства. В приведенной модели основными объектами, которые наследуют его свойства, являются столбец Column, таблица Table и поле записи Field. Все они выступают в роли либо источника, либо получателя данных в основной массе преобразований. В приведенной модели эти объекты не показаны явным образом, поскольку цепочки наследования очень длинны. В начале цепочки находится объект ModelElement, который представляет столбец хранилища данных. Коллекция SupplierDependency приводит к набору TransformableObjectSet. Этот набор представляет собой множество объектов, которые являются либо источниками, либо получателями данных в выполняемом преобразовании. Переход через коллекцию TargetOf приводит к тем преобразованиям, для которых этот столбец выступает в роли получателя результатов трансформации. Возвращение к набору TransformableObjectSet через коллекцию Source позволяет получить исходный набор для данного преобразования. Для нахождения исходных объектов (при использовании DTS ими являются столбцы) следует обратиться к коллекции TransformObjects.

Описанный процесс несколько труден для восприятия, но сложность модели позволяет с ее помощью описывать все сценарии и коды, применяемые в процессах преобразования и очистки данных. Они широко используются во многих инструментальных средствах для работы с хранилищами данных. В качестве примера того, как проводить навигацию по данной модели, рассмотрим код VB, приведенный в листинге 1. Он начинает работу со столбца хранилища данных roWHCol, затем возвращается к набору TransformableObjectSet на стороне хранилища данных (roWHTransObjSet). После этого он переходит в обратном направлении к самому преобразованию (roTransform), а от него движется к набору TransformableObjectSet на стороне источника информации (roSrcTransObjSet). Завершающий шаг - присоединение столбцов (в roSrcCol) к исходному набору преобразуемых объектов.

Схема OLAP

Многие пользователи, работающие с хранилищами, получают доступ к данным через многомерные кубы OLAP. На схеме 3 изображена модель OLAP, для нее первичными элементами являются сервер OLAPServer, каталог Catalog, куб Cube, размерность Dimension, иерархия размерностей DimHierarchy и показатель Measure. Сервер соответствует компьютеру, на котором установлена служба OLAP. На сервере функционирует база данных OLAPDatabase, доступ к которой осуществляется через коллекцию DeployedDatabases. Каталоги содержат коллекцию многомерных кубов Cubes. Обратиться к их показателям (мерам) можно через наследуемую коллекцию Measures на объекте Store. Размерности хранятся в коллекции Dimensions базы данных. От кубов нетрудно перейти к размерностям, на которых они построены, однако эти объекты являются частью подмодели служб OLAP. В результате такого разделения могут возникнуть проблемы с предоставлением конечным пользователям полной информации о доступных размерностях. Однако большинство клиентских инструментальных средств извлекают информацию о доступных размерностях из кубов, поэтому следует воспользоваться данными кубов для фильтрования нужных наборов из списков базы данных.

Другая модель более низкого уровня (модель служб OLAP корпорации Microsoft), которая наследует данные от модели OLAP, хранит информацию, характерную для служб OLAP. Она содержит все объекты, которые не вошли в общую модель OLAP.

Об авторах:

Патрик Кросс (pcross@dwsoft.com) является одним из основателей и членом совета директоров компании DWsoft, а также MVP по Microsoft Repository. Последние три года он работал в тесном контакте с Microsoft над созданием репозитария Microsoft Repository. Саид Раими, Ph. D. (srahimi@dwsoft.com) является одним из основателей и техническим директором компании DWSoft. Он обладает более чем 20-летним опытом работы в области создания репозитариев, словарей данных, систем управления базами данных, инструментария CASE и средств проектирования информационных систем.