Лекция
Это окончание невероятной информации про метаданные в хранилищах данных.
...
font-family: "lucida grande", tahoma, verdana, arial, sans-serif; font-size: 12px;">
Исследователями в области проектирования ХД предлагаются и другие подходы к построению классификации, но при этом, как правило, используются названные выше два принципа.
Основные типы метаданных приведены на рис. 14.5.
Ведущие производители программного обеспечения в области складирования данных ведут жесткую конкурентную борьбу за лидерство. И выдвижение своих решений в качестве промышленного стандарта для систем этого класса является неотъемлемой составляющей этой борьбы.
В середине 1998 года корпорации IBM, Oracle, Unisys, Hyperion, SAS, Meta Integratiom и ряд других поставщиков программного обеспечения представили в организацию Object Management Group (OMG) спецификацию стандарта "Обмен общими метаданными хранилища данных" (Common Warehouse Metadata Interchange, CWMI). Во второй половине 1999 года корпорация Microsoft передала на рассмотрение в консорциум Meta Data Coalition (MDC) разработанный ею стандарт "Открытая информационная модель" (Open Information Model, OIM).
В 2000 году произошло слияние MDC и OMG, а спустя год, в начале февраля 2001 года, была опубликована первая версия спецификации "Общая метамодель хранилища данных" [67].
CWMI определяет интерфейсы, которые могут быть использованы для обмена метаданными между ХД и аналитическими приложениями с помощью инструментальных средств ХД, программно-аппаратных платформ и репозиториев метаданных в распределенных гетерогенных вычислительных средах.
CWMI основывается на трех основных стандартах:
Стандарт UML определяет язык объектно-ориентированного моделирования, который поддерживает ряд графических нотаций. Стандарт MOF определяет гибкие средства для определения модели метаданных и обеспечивает программные средства для хранения и доступа к метаданным в репозитории. Стандарт XMI определяет спецификации для обмена метаданными в формате стандарта XML. Использование этих стандартов не накладывает сильных ограничений при реализации модели метаданных в конкретных системах складирования данных.
Перечисленные выше стандарты формируют ядро архитектуры репозитория метаданных OMG, как показано на рис. 14.6.
Основные элементы общей метамодели хранилища данных (CWM) включают в себя:
Четырехуровневая архитектура метамоделирования аналогична общепринятой архитектуре моделирования, как показано в таблице 14.1.
| .Мета уровень | Уровень моделирования |
|---|---|
| M3 | Мета-метамодель / мета-мета-метаданные (Meta-Metamodel / Meta-meta-metadata). Например, MOF класс, атрибут, ассоциация |
| M2 | Метамодель / мета-метаданные (Metamodel/Meta-metadata). Например, UML класс, атрибут таблицы CWM, колонка |
| M1 | Модель / метаданные (Model/Metadata). Например, Покупатель: Тип_таблицы_покупатель: Колонка |
| M0 | Данные / объект (Data/Object). "ООО" ("Флинт") |
Стандарт расширяет базовую метамодель метамоделями для реляционных и многомерных данных, для преобразования функций OLAP и ХД, включая процессы и операции. Спецификацию CWM можно рассматривать как язык, предназначенный для определения моделей ХД. Спецификация CWM расширяет язык UML: каждый метакласс (metaclass) CWM наследуется непосредственно или косвенно из метаклассов UML. Так, метакласс "Реляционная Таблица" (Relational Table) CWM является непосредственным наследником Класса UML (UML Class), а "Реляционный Столбец" (Relational Column) — прямой потомок Атрибута UML (UML Attribute).
Таким образом, спецификация CWM определяет метамодель и для предметно-ориентированных метаданных, и для технических метаданных. Эта метамодель используется для обмена экземплярами метаданных между гетерогенным программным обеспечением, поставляемым различными производителями. Системы, поддерживающие метамодель CWM, обмениваются данными в форматах, которые согласуются с этой моделью.
Стандарт OMG "Средства метаобъекта" (Meta Object Facility, MOF) определяет общие интерфейсы и семантику для взаимодействующих метамоделей. Являясь подмножеством UML, он представляет собой пример мета-метамодели, или модели метамодели (подмножество). В сферу действия этого стандарта входит определение языка описания интерфейса (Interface Definition Language), который устанавливает правила управления моделями с помощью программных APIs. Все модели CWM выражаются на UML и реализуют семантику MOF.
Стандарт OMG "Обмен метаданными XML" (XML Metadata Interchange, XMI) устанавливает правила преобразования метамоделей MOF в XML. XMI непосредственно задействован в обмене метамоделями. Метамодели MOF транслируются в XML DTD, а модели — в XML-документы, которые согласуются со своими DTD.
Таким образом, стандарт CWM состоит из ряда составных метамоделей (суб-метамоделей), которые организованы в виде следующих 4 слоев: базовый слой (Foundation), источники данных (Resources), анализ (Analysis) и управление хранилищем (Management), как показано на рис. 14.7.
Базовый слой состоит из метамоделей, которые поддерживают моделирование таких различных элементов и сервисов, как типы данных, системное преобразование типов, абстрактные ключи и индексы, выражения, бизнес-информация и включения программного обеспечения, основанного на использовании компонентных объектов.
Слой источников данных предоставляет возможность моделировать существующие и новые источники данных, в том числе реляционные базы данных, ориентированные на запись базы данных (record oriented data-bases), а также XML- и основанные на объектах (object-based) источники данных.
Слой анализа предоставляет средства для моделирования сервисов информационного анализа, которые обычно используются в хранилище данных. Он определяет метамодель для преобразования данных, OLAP, визуализации информации и исследования данных (data mining).
Слой управления состоит из метамоделей, представляющих стандартные процессы и операции ХД, журнализации и планирования работ (например, ежедневной загрузки и выгрузки).
Набор метамоделей CWM является достаточным для моделирования всего ХД.
Когда требования к метаданным собраны и формализованы, можно приступать к разработке метамодели. На практике следовать требованиям стандарта часто бывает сложно. Причиной этого является дефицит времени и недопонимание важности проработки метамодели руководством компании, особенно когда компания создает ХД силами своего ИТ-подразделения. Руководство по проектированию и разработке метамодели CWM насчитывает более 700 страниц [68]. Как правило, менеджменту ИТ-подразделения трудно объяснить руководству компании, что для собственной разработки ХД необходимо либо взять новую штатную единицу, либо отправить своего специалиста на обучение.
Заказывает ли компания разработку ХД третьей компании или собирается проводить ее самостоятельно – можно выделить следующие способы создания метамодели.
Чтобы построить метамодель ХД вручную, необходимо собрать правильные определения сущностей, их атрибутов и взаимосвязей между сущностями. Для разработки такой метамодели может быть применено либо объектно-ориентированное моделирование, либо ER-моделирование.
Если для построения метамодели ХД проектировщик ориентируется на использование стандарта, то у него есть возможность задействовать либо спецификацию "Открытая информационная модель" (Open Information Model OIM), либо спецификацию "Общая метамодель хранилища данных" (Common Warehouse Meta-Model, CWM). CWM описывает обмен метаданными в системах складирования данных, управления знаниями и деловой осведомленности. OIM является набором спецификаций метаданных для использования в разработке приложений ХД. Обе спецификации основываются на промышленных стандартах, таких как UML, XML и SQL.
Выбор подхода к проектированию метаданных во многом определяется набором инструментальных средств проектировщика ХД и выбором несущей СУБД. Ясно, что разработанная вручную метамодель имеет важное преимущество: она, как правило, наиболее полно отражает представление метаданных компании. Но у такой модели есть большой недостаток — ее нужно сопровождать и поддерживать постоянно в актуальном состоянии, как правило, вручную. Модели, разработанные с учетом стандартов, учитывают большинство требований по представлению метаданных компании в ХД. Кроме того, они расширяемы и поддерживаются ведущими производителями средств разработки (Oracle, IBM, Microsoft).
Репозиторий метаданных ХД следует поддерживать при использовании любого метода проектирования метаданных. При этом важно выбрать для него архитектуру (централизованный он будет или распределенный) и способы поддержки его в актуальном состоянии (поскольку метаданные связывают между собой семантику всех компонент системы складирования данных).
Программные компоненты системы складирования данными через репозиторий обмениваются метаданными в процессе своей работы. Для организации обмена метаданными стандарт CWM позволяет детализировать архитектуру репозитория. При этом формат обмена метаданными есть XML-документ.
Пример использования AllFusion ERwin Data Modeler для создания и поддержки метамодели ХД подробно рассмотрен в [37]. Далее мы изучим вопрос, как можно построить модель метаданных вручную.
Обращаясь к изучению вопроса логического проектирования модели метаданных, мы преследуем цель разобраться в сути процесса представления метаданных в ХД и получить навыки построения модели метаданных, которые можно в дальнейшем применить для управления метаданными через репозитории метаданных, поставляемых производителями программного обеспечения для создания ХД.
В разделе "Логическая структура метаданных хранилища данных" мы рассмотрели примеры описания метаданных для различных объектов ХД. Мы будем использовать эти примеры при создании нашей модели метаданных.
Создадим сначала логическую модель данных для метаданных таблиц фактов. Она может быть такой, как на рис. 14.8.
Метаданные о таблице фактов целесообразно разместить в двух сущностях, одна из которых — "Таблицы фактов" — содержит практически не меняющуюся информацию о таблице фактов, а другая — "История загрузки" — содержит данные, которые меняются согласно параметру "Частота загрузки".
В сущность "Таблицы фактов" включена информация:
В сущность "История загрузки" включена информация:
Оставшиеся элементы метаописания таблицы фактов находятся с сущностью "Таблицы фактов" в отношении наследования. Для представления этих элементов метаописания на рисунке введены дополнительные сущности, которые мы будем моделировать далее.
Таблица фактов многомерной модели содержит данные о фактах и метриках. Построим соответствующий фрагмент модели метаданных ( рис. 14.9).
Сущности "Факты", "Метрики фактов", "Метрики" и "Поля схемы "звезда" представляют описание характеристик фактов. Сущности "Атрибуты" и "Домены атрибутов" представляют физические определения метрик фактов в ХД.
Заметим, что в сущности "Атрибуты" присутствует атрибут "Ключ измерения", поскольку эта сущность также должна описывать атрибуты измерений.
Рассмотрим моделирование метаданных измерений ( рис. 14.10).
Сущности "Измерения" и "Измерения и метрики" описывают измерения и их связи с метриками таблицы фактов. Сущность "Атрибуты" описывает атрибуты измерений.
Дополним разработанную модель метаданных для нашего примера информацией об источниках данных, как показано на рис. 14.11.
Источники данных для ХД описаны в сущностях "Источники данных", "Таблицы", "Колонки", "Загрузка данных" и "Правила преобразования".
Таким образом, мы построили логическую модель метаданных ХД для нашего примера из раздела "Логическая структура метаданных хранилища данных" настоящей лекции.
Заметим, что не все элементы описания метаданных были использованы при конструировании модели метаданных ХД. Это право проектировщика ХД, основанное на изучении требований к системе складирования данных.
Также обратим внимание на то, что была создана частная модель, которая не учитывает ряд требований, предъявляемых к модели метаданных. Как правило, при построении модели метаданных ХД должен быть учтен ряд обязательных элементов представления метаданных в модели, а именно:
Обратим внимание на то, что вопросам представления информации об информационной безопасности в этой лекции не было уделено никакого внимания. Как правило, программно-аппаратные решения в области обеспечения информационной безопасности носят конфиденциальный характер, и давать какие-либо общие рекомендации по их описанию в модели метаданных нецелесообразно. Это будет определяться руководителем ИТ-проекта создания ХД.
В настоящей лекции мы рассмотрели понятие метаданных как совокупности спецификаций и элементов данных, содержащих описание данных ИС и процессов их обработки. Были определены основные функции и дана классификация метаданных в ХД. Был дан краткий обзор спецификации "Общая метамодель хранилища данных".
На примере конкретного киоска данных было подробно показано, как формировать метаданные для модели, таблиц фактов, фактов, таблиц измерений и источников данных. Приведенное описание метаданных послужило основой для логического проектирования модели метаданных ХД.
Метаданные — это информация о данных, которая требуется для управления ХД, а управление метаданными — существенный компонент архитектуры хранения. К техническим метаданным относится вся информация, которая требуется для настройки и использования ХД. Предметно-ориентированных метаданных включают в себя бизнес-термины и определения данных ХД. Структурные метаданные – это описание объектов ХД и их характеристик. Метаданные процесса обработки данных — это информация, собранная во время работы ХД, такая как происхождение перенесенных и преобразованных данных; статус использования данных (активные, архивированные или удаленные); данные мониторинга, такие как статистика использования, сообщения об ошибках и результаты аудита.
Метаданные часто размещаются в репозитории, который позволяет совместное использование метаданных различными инструментами и процессами при проектировании, установке, применении, эксплуатации и администрировании ХД.
Исследование, описанное в статье про метаданные в хранилищах данных, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое метаданные в хранилищах данных и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Часть 1 Метаданные в хранилищах данных
Часть 2 Стандарты метаданных - Метаданные в хранилищах данных
Часть 3 Выбор метамодели при проектировании хранилища данных - Метаданные в хранилищах
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL