Цель лекции: Изучить понятие метаданных хранилища данных и их функции. Рассмотреть классификацию метаданных. Разработать логическую модель метаданных для учебного примера.
Изучив материал настоящей лекции, вы будете знать:
и научитесь
Определение Метаданные - это «данные о данных», вносит более путаницы в толкование термина «Метаданные» (metadata), чем поясняет его смысл. Образное определение, метаданные - это «тень данных», принадлежащее Б. Инмону и понятное ИТ - специалистам по ХД, также не вносит большей ясности.
Метаданные есть в любой ИС с БД, будь то OLTP система, система бизнес-аналитики или корпоративный портал. Чтобы осознать этот факт, нужно вспомнить о том, что любая ИС реализует «вопрос - ответное» отношение на конечном алфавите. Метаданные позволяют пользователям понять, на какие вопросы может отвечать данная ИС. По своему сыслу, метаданные - это совокупность спецификаций и данных, которая в целом дает ответы на вопросы, какова степень охвата предметной области в ИС, какие данные в ней представлены, какова архитектура системы и т.д.
Метаданные содержат семантическую интерпретацию или толкование содержания элементов данных, циркулирующих в ИС. Но это далеко не все. В метаданные включается также описание вычислительной среды, предметных областей, информационной безопасности и многое другое, что непосредственно влияет на эффективность использования ИС, в первую очередь, конечными пользователями и разработчиками.
Далее под метаданными будет пониматься совокупность элементов данных и спецификаций, содержащих описание данных ИС и процессов их обработки.
Неоднозначность толкования термина «Метаданные» определяется тем обстоятельством, что последние должны удовлетворить технические и семантические потребности всех групп пользователей ИС. Каждая группа пользователей имеет свои требования к метаданным.
Руководство компании (основные пользователи информационных систем руководителей) хочет знать, что оно может получить от системы, как быстро оно получить ответ на интересующий вопрос, и, желательно, в терминах понятных лицам, принимающим решения. Руководство организации не имеет времени, да и не понимает, зачем ему (что совершенно правильно, поскольку руководство организации решает стратегические и тактические задачи организации, а не профессиональные задачи реализации автоматизированных информационных систем), изучать объемные инструкции по эксплуатации ИС.
Специалисты организации, например, пользователи бухгалтерских систем, хотят, чтобы такая система «разговаривала на их профессиональном языке», вплоть до того, что разработчики таких систем (как, например, 1С-бухгалтерия) оснащают свои системы специальным, формальным языком, понятным бухгалтерам. Следует заметить, что бухгалтера вряд ли будут основательно изучать SQL.
Аналитиков компании занимают более сложные вопросы, в частности, о происхождении и достоверности данных. Руководство организации требует от них информации для поддержки принятия обоснованных решений. Цена ошибки может быть велика: значительные убытки или сорванные контракты.
Разработчиков приложений интересует информация о модели данных ИС для создания или внедрения дополнительных бизнес - приложений. Они хотят знать, что находится в таблицах БД системы и в каком формате.
Отображение столь многообразных интересов в метаданных порождает большое число элементов, которые составляют метаданные. Проектирование и разработка метаданных являются одной из самых сложных и трудоемких задач проектирования и разработки ИС.
Разработку метаданных можно отнести к ИТ - дисциплине, которую называют управление данными. Решение задач управления данными часто возлагается на администраторов данных, которых не следует путать с администраторами БД и компьютерных сетей.
Нужно отметить, что некоторые принципы управления данными в ХД и БД OLTP систем имеют существенные отличия. Так, например, характерный для OLTP систем принцип, состоящий в том, что существует только одно правильно отображающее семантику определение данных в системе, не является верным ХД. Это связано с различными временными горизонтами данных в системах, основанных на ХД.
При проектировании метаданных задача состоит в:
Весь этот комплекс вопросов, которые должны быть решены при проектировании метаданных, требует тщательной их проработки еще на начальных стадиях проектирования. Проектирование ХД должно начинаться с проектирования метаданных и должно заканчиваться им же.
Роль метаданных для ХД значительно важнее, чем в системах операционной обработки данных. Если в системах операционной обработки данных интерфейс системы является настроенным на бизнес - процедуры обработки данных конкретными специалистами и понятным им после обучения, то интерфейс систем складирования данных конструируется таким образом, чтобы помимо всего прочего отвечать на не предопределенные вопросы (ad hoc). Такие вопросы формулируются в терминах предметной области и бизнес - процессов и специалистами, для которых ИТ технологии не являются основной профессией: аналитиками, менеджерами среднего и высшего уровня.
Таким образом, одним из главных аспектов использования метаданных в ХД является их предметная ориентация. Основные вопросы, на которые должны ответить метаданные - это какие данные представлены в системе, и как их получить в нужном для анализа данных виде.
Первой основной функцией метаданных в ХД является представление соответствия данных источников и данных ХД. Это описание представляет собой фиксацию взаимосвязи атрибутов данных источника и атрибутов данных ХД, правила преобразования первых во вторые, изменение в наименовании данных, их физических характеристиках и т. д. Такая информация позволяет идентифицировать источники данных для ХД, правильность данных в ХД и их корректность.
Вторая основная функция метаданных в ХД является управление данными во времени. Время жизни данных в ХД, как правило, 5 - 10 лет, а то и более. А для систем операционной обработки данных время жизни данных - это от нескольких дней до нескольких месяцев. Затем данные архивируются в случае необходимости.
Таким образом, временной горизонт данных в ХД гораздо больше и это обстоятельство изменяет коренным образом некоторые принципы управления данными. Например, в системах операционной обработки данных в одно и то же время существует только одно корректное определение данных. Для ХД это не так.
Структура данных (схема или модель данных) в системах операционной обработки данных меняется во времени, т.е. данные в таких системах в разное время имеют различные формы представления. Хронология таких изменений должна быть зафиксирована в ХД.
Таким образом, в ХД в одно и то же время может существовать несколько схем данных, отвечающих различным периодам эволюции источников данных. Запись о таких структурных изменениях сохраняется в метаданных ХД. На основании таких записей аналитики получают ответы на вопросы, какими данными и за какие периоды они располагают.
Третья, и немаловажная функция метаданных в ХД, - это поддержка версионности. Эта функция тесно связана с управлением данными с большим временным горизонтом. Метаданные должны отражать изменения внутренней структуры данных источников, и, следовательно, должны сами изменяться, для того чтобы обеспечить непрерывность истории изменения структуры данных ХД.
Таким образом, поддержка версионности метаданных позволяет в каждый момент времени в прошлом обеспечить правильное описание модели данных, а аналитики получают возможность знать, какие данные, когда и как попали в ХД.
Четвертая основная функция метаданных в ХД, это интерпретация данных в терминах бизнес - пользователей. Метаданные должны поддерживать в запросах понятную для пользователя терминологию, независимо от того, какие правила наименования атрибутов были использованы проектировщиком ХД.
Пятая основная функция метаданных - это обеспечение открытости (доступности другим информационным системам) системы складирования данных для ее интеграции с другими аналитическими системами организации. Опрос метаданных ХД другой системой позволяет последней выяснить структуру данных ХД и поддерживать обмен данными между системами. На Рис. 7.1. просуммированы основные функции метаданных для ХД.
Рис. 7.1. Основные функции метаданных для хранилищ данных
Остановимся на перечне тех элементов или компонентов метаданных, которые обязательно должны присутствовать в ХД. Базовые компоненты метаданных ХД не сильно отличаются от базовых компонент систем операционной обработки данных. Это описание таблиц, их атрибутов, ключей и т .д.. Существенное отличие для ХД - поддержка версионности метаданных. Базовые компоненты говорят нам, какие данные сохраняются в ХД.
Следующая, характерная для ХД, группа компонентов метаданных - это описание преобразований. Как правило, описание преобразований данных для ХД включает в себя:
Компоненты преобразования говорят нам о том, как данные в ХД были получены. Немаловажным компонентом метаданных ХД является история поступления в него данных. Компонент метаданных - история экстрагирования (поступления) данных, говорит нам о том, когда данные поступили в ХД, а также позволяет судить о полноте представления данных в ХД. Для проведения анализа данных такая информация является очень важной, поскольку на ее основе формируются утверждения пользователей о корректности анализа данных и надежности его результатов.
Информация о синонимах или терминологические соответствия понятий - это еще один компонент метаданных ХД. Он включает в себя альтернативные наименования (алиасы) для данных ХД. Такая информация, как правило, делает ХД более "дружелюбным" для пользователей.
Следующим важным компонентом метаданных является информация о состояниях и статистики использования данных ХД. Эта информация составляет основу для оптимизации производительности ХД. К такой информации относятся данные о числе строк в таблицах, скорости роста таблиц, статистических профиль использования таблиц (среднее и максимальное число запросов на день), статистика архивирования и удаления данных, индексирование таблиц, частота использования индексов в запросах и т.п.
Еще одним компонентом метаданных ХД являются алгоритмы агрегации и суммирования данных, критерии выборки из источников, правила преобразования данных источников перед загрузкой в ХД, описание взаимосвязей между объектами ХД, их кардинальность и т.п. Такая информация играет важную роль при проведении анализа данных и часто требуется аналитиками для решения вопросов надежности результатов анализа.
Информация о том, кто отвечает за содержание и актуальность различных источников данных составляет еще один компонент метаданных. Эта информация важна для группы сопровождения ХД, и позволяет организационно решать вопросы качества, точности и надежности данных в ХД.
Часто в метаданные включаются компоненты, описывающие шаблоны доступа к данным (когда и как данные мигрировали на другой уровень хранения). Они используются также для оптимизации физического потока данных в ХД и для оптимизации производительности.
Алгоритмы обработки данных в ХД используют информацию об объектах внешних систем, так называемые, таблицы расширения (таблицы кодировок и электронных справочников). В этом случае, в метаданных ХД необходимо фиксировать описание таких таблиц и историю их изменения, поскольку в случае изменения кодов необходимо провести соответствующие изменения в обработке данных ХД, чтобы не потерять исторические связи в данных.
Из сказанного выше ясно, что проектирование метаданных ХД является достаточно сложной и креативной задачей для проектировщика ХД, решение которой требует часто литературного мастерства, знания предметной области ХД и очень много времени. На Рис. 7.2 приведены основные элементы метаданных для ХД.
Рис. 7.2. Основные элементы метаданных для хранилищ данных
Рассмотрим, как можно описать метаданные на примере киоска данных, предназначенного для анализа продаж некоторой гипотетической компании. Предположим, что компания занимается производством и реализацией своей продукции. Киоск данных используется аналитиками компании для детального изучения взаимосвязи расходов и доходов компании от реализации продукции и подготовки отчетности о продажах для руководства.
Допустим, что наша гипотетическая компания открыла сеть точек продаж (склады розничной и оптовой торговли) и организовала сеть магазинов, т.е. сделала расширение своей деятельности. Руководство компании хочет оценить эффективность сделанного расширения и иметь более подробную информацию о зависимости между продажами и производством по затратам и доходам.
Далее допустим, что компания выпускает около 200 видов (моделей) некоторой продукции. Каждый продукт имеет базовый набор комплектующих компонент. Дополнительные комплектующие компоненты используются для создания специфической модели продукта. Рыночная политика компании строится таким образом, что число выпускаемых моделей остается постоянным. Это означает, что количество новых моделей приблизительно равно количество моделей, снятых с производства.
Для каждой модели каждого продукта в зависимости от спроса применяется гибкая система скидок. Как правило, размер скидки для покупателей больших партий продукции определяет заведующий складом розничной продажи.
Когда принято решение приостановить производство продукции данной модели, информация о ней сохранятся в БД компании в течение 6 месяцев после того, когда вся оставшаяся продукция будет реализована или списана. Данные о продукции удаляются в тот момент, когда удаляются данные о последней модели этой продукции.
Компания поддерживает два способа реализации продукции: через магазин оптовой торговли и через магазин розничной торговли. Магазин оптовой торговли продает товар только оптовым покупателям. Покупатель считается оптовым, если он покупает более 20 партий товара в год. Оптовый покупатель может предоставлять счет либо непосредственно в магазин оптовой торговли, либо по факсу в центральный офис компании. Любой покупатель может покупать в нескольких магазинах компании.
Магазин розничной торговли продает за наличный расчет. Не зависимо от предоставления скидок, цена товара меняется. Хотя на каждую продажу продукции оформляется счет, компания не ведет учет покупателей для розничной продажи.
Киоск данных нашей компании предназначен для решения задач анализа показателей расхода и дохода. Типовые запросы, на которые система должна давать ответы, следующие:
Источником данных для киоска данных является фрагмент БД системы операционной обработки данных компании. Одна из возможных структур данных киоска данных, полученная в результате проектирования, приведена на рис. 7.3.
Рис. 7.3. Многомерная модель киоска данных для анализа продаж компании
Рассмотрим описание метаданных для такого киоска данных. Отметим, что приведенное описание является примером одного из возможных подходов, его нельзя считать полным и законченным.
В этом разделе приводятся логические схемы метаданных для ХД для взятого нами примера. Пример не претендует на полноту, но дает ясное представление о подходах к описанию метаданных.
Логическая структура модели метаданных таблицы фактов ХД может быть следующей:
Имя: Продажа (Sale)
Определение: Факт содержит данные о продаже для каждого заказа, который был зафиксирован в оперативной системе обработки заказов для каждого склада розничной и оптовой торговли.
Альтернативное имя: Нет
Частота загрузки: Ежедневно
Статистика загрузки данных:
Статистика использования данных:
Правила архивирования данных: Данные будут архивироваться по истечению 36 месяцев на ежемесячной основе.
Статистика архивирования:
Правила удаления данных: Данные будут удаляться по истечению 48 месяцев на ежемесячной основе.
Статистика удаления:
Качество данных: Допускаются ошибки персонала при комплектовании заказов. Однако записи, представленные в БД, являются точными.
Точность данных: Метрики этого факта являются на 100% точными, поскольку представляют уже осуществленные продажи.
Грануированность измерения Время: Метрики данного факта представляют продажу данного товара по данному заказу.
Ключевое поле: Ключом для факта продажи является комбинация ключей измерений: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).
Метод генерирования ключа: Временная часть ключа есть просто дата продажи товара. Ключ товара, ключ производителя, ключ продавца и ключ покупателя выбирается из справочников оперативной БД компании.
Источники:
Метрики: Общая стоимость (Total cost), Общая прибыль (Total revenue), Общее количество продаж (Total quantity sold) и Скидка (Discount amount)
Измерения: Customer (Покупатель), Manufacture (Производитель), Продукт (Product) , Продавец (Seller) и Время (Time)
Сотрудник, ответственный за данные: Директор завода производителя
Логическую структуру метаданных для измерений приведем на примере измерений Покупатель и Время. Она может быть следующими.
Для измерения Покупатель
Имя: Покупатель (Customer)
Определение: Покупатель - это любое физическое или юридическое лицо, которое приобретает продукцию компании. Покупатель может приобретать товары в нескольких точках продаж компании.
Альтернативное имя: нет
Иерархия измерения: Данные по этому измерению могут суммироваться на двух уровнях. Первый уровень суммирования (нижний) есть адрес отгрузки товара покупателю. Данные по каждому адресу юридического лица могут быть позднее просуммированы по каждому покупателю.
Правила изменения: Адреса отгрузки товара по каждому юридическому лицу вставляются как новые строки в измерение. Изменение существующих адресов покупателей выполняется обновлением непосредственно в таблице измерения.
Частота загрузки: Ежедневно
Статистика загрузки:
Статистика использования:
Правила архивации: Данные этого измерения не архивируются.
Статистика архивации:
Правила удаления: Покупатели, которые не приобретали продукцию компании в течение последних 5-ти лет, удаляются из таблицы измерения на ежемесячной основе.
Статистика удаления:
Качество данных: Когда новый покупатель добавляется в измерение, выполняется поиск чтобы определить, не было ли продаж товара данному покупателю по другому адресу. Независимо от того, были ли такие продажи, покупатель с новым адресом отгрузки товара вставляется как новая строка.
Точность данных: Допускается 5% неточность в определении связей между покупателем и его адресами отгрузки.
Ключ измерения: Сгенерированное системой число, которое идентифицирует покупателя.
Метод генерации ключа: Когда запись о покупателе копируется из подающей системы, выполняется проверка на присутствие покупателя в ХД. Если такого покупателя нет в ХД, новый идентификатор генерируется и запись вставляется в измерение.
Источники:
Атрибуты:
Факты: Продажа (Sale)
Метрики: Общая стоимость (Total cost), Общая прибыль (Total revenue), Общее количество продаж (Total quantity sold) и Скидка (Discount amount)
Ответственный за поставку данных: Вице-президент по продажам и маркетингу
Для измерения Время
Имя: Время (Time)
Определение: Измерение Время содержит моменты времени, когда компания фиксирует данные о продажах.
Альтернативное имя: Нет
Иерархия измерения: Наименьший уровень суммирования данных есть день. Данные для этого дня могут быть просуммированы либо за неделю, либо за месяц.
Правила изменения: Записи вставляются в измерение один раз за текущий год. Никакие обновления в этом измерении не допускаются.
Частота загрузки: По мере необходимости
Статистика загрузки:
Статистика использования:
Правила архивации: Данные этого измерения не архивируются.
Правила удаления: По истечению 5 лет данные будут удаляться на ежегодной основе.
Статистика удаления:
Качество данных: Никаких ошибок в данных этого измерения не предполагается.
Точность данных: Данные этого измерения всегда точны.
Ключ измерения: Ключ измерения Время есть дата в формате ГГГГММДД.
Метод генерации ключа: Дата, представленная в строке, используется как значение ключа.
Источник:
Атрибуты:
Факты: Продажа (Sale)
Метрики: Общая стоимость (Total cost), Общая прибыль (Total revenue), Общее количество продаж (Тotal quantity sold) и Скидки (Discount amount)
Ответственный сотрудник: Администратор ХД
Логическую структуру метаданных для метрик дадим на примере метрик «Общая стоимость», «Общая прибыль» и «Общее количество продаж». Она может быть следующей:
Имя: Общие издержки (Total Cost)
Определение: Это есть стоимость всех компонент, используемых для создания данного вида (модели) продукции, которая была продана
Альтернативное имя: нет
Тип данных: Числовой
Домен: 0.01 - 9999999.99
Правила вычисления значения: Общие издержки равны произведению стоимости единицы товара (модели) на количество проданных моделей.
Статистика использования:
Качество данных: Эта метрика формируется только исходя из стоимости комплектующих деталей на момент продажи данного вида товара. Никакие другие виды издержек на производство товара не учитываются.
Точность данных: Предполагается, что разброс значений в стоимости комплектующих деталей данного вида товара составляет ± 0.5%.
Факты: Продажа (Sale)
Измерения: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).
Имя: Общая стоимость (Total Revenue)
Определение: Общая стоимость равен произведению проданных единиц товара на отпускную цену этого товара на момент продажи.
Тип данных: Числовой
Домен: 0.01 - 999999999.
Правила вычисления значения: Общая стоимость есть произведение отпускной цены модели товара на количество проданного товара.
Статистика использования:
Качество данных: Эта метрика представляет количество проданных единиц товара.
Точность данных: С точки зрения построения трендов продаж и шаблонов поведения покупателей высокая точность данных не требуется.
Факты: Продажа (Sale)
Измерения: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).
Имя: Общее количество продаж (Total Quantity Sold)
Определение: Это есть число проданных единиц товара.
Тип данных: Числовой
Домен: 1 - 9999999.
Правила вычисления значения: Это значение берется непосредственно из графы количество для каждой позиции счета.
Статистика использования:
Качество данных: Это поле представляет только количество проданного товара.
Точность данных: С точки зрения построения трендов продаж и шаблонов поведения покупателей высокая точность данных не требуется.
Факты: Продажа (Sale)
Измерения: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).
Логическая структура метаданных источников может быть следующей (на примере описания таблиц Счет из подающей системы):
Имя таблицы: Счет (Order)
Метод извлечения данных: В исходной таблице выбираются записи с законченными на текущую дату операциями для добавления в ХД.
График извлечения данных: Ежедневно по завершению рабочего дня.
Статистика извлечения данных:
В следующем разделе мы рассмотрим, как используются инструментальные CASE-средства при проектировании модели метаданных.
Любая стандартизация начинается с построения классификации объектов, для которого разрабатывается стандарт. Стандарт в области метаданных не является исключением из этого правила. Второй аспект разработки любого промышленного стандарта - это учет предложений ведущих производителей. И третий момент - это концепция, которая позволяет связать разрабатываемый стандарт с уже действующими в данной предметной области стандартами.
Предметом обсуждения этого раздела является спецификация «Общая метамодель хранилища данных» (Common Warehouse Metamodel, CWM), которая является одним из стандартов, использующих XML-технологии. Этот стандарт описывает обмен метаданными в ИС, использующих технологии ХД, системах бизнес-аналитики (Business Intelligence) и системах управления знаниями (Knowledge Management).
Как следует из обсуждения метаданных в предыдущих разделах, на очень высоком уровне метаданные могут быть разделены на две категории: разделяемые метаданные (Shared meta data) и уникальные метаданные (Unique meta data).
Элементы разделяемых метаданных необходимы для точного определения объектов и их семантики для ХД в целом. Так, определение объекта «Покупатель» в нашем примере выше должно быть согласованным и для источников, и для ХД, т.е. иметь одинаковый смысл в рамках ИС масштаба организации. Уникальные метаданные описывают уникальные объекты системы, например атрибуты измерений или фактов.
Другой подход к построению классификации метаданных - это разделить элементы метаданных по их функциональному назначению:
Предметно-ориентированные метаданные содержат определения сущностей предметной области в терминах пользователей, логические отображения между данными на различных уровнях их представления в системе, описания словаря ХД, как БД.
Примером предметно-ориентированных метаданных может служить описание какого-либо атрибута сущности предметной области ХД, как вес проданного или закупленного товара. Рассмотрим пример на Рис. 7.4.
Рис. 7.4. Предметно-ориентированные метаданные: одно имя, одинаковый смысл, различные единицы измерения
В двух киосках данных системы складирования данных имеются две таблицы фактов «Счета покупок» и «Счета продаж». Каждый киоск отвечает за определенное направление деятельности организации. В обеих таблицах имеет атрибут с именем «Вес». Семантический смысл этого атрибута в обоих случаях одинаков: вес товара. Однако в одном киоске данных может использоваться единица измерения веса Кг, а в другом - Центнер.
Cтруктурные метаданные содержат описание структуры различных объектов данных. Они используются при реализации схем навигации для представления данных пользователям. Например, объект данных «Книга» состоит из элементов «Название», «Автор», «Содержание», «Предисловие», «Глав с тестом». Каждая глава имеет «Заголовок» и, возможно, ряд «Подзаголовков».
Технические метаданные содержат определения и данные о физических объектах ХД. Это определения наименований таблиц и их колонок, ограничений, правил физических преобразований данных и т.п. Например, формат и длина поля «Имя покупателя» есть строка переменной длины до 100 символов.
Метаданные процесса обработки данных содержат информацию, связанную с процессом обработки данных, такую, как статистика загрузки, расписание загрузки данных и т.п.
Исследователями в области проектирования ХД предлагаются и другие подходы к построению классификации, но при этом, как правило, используются перечисленные выше два принципа.
Основные типы метаданных приведены на Рис. 7.5.
Рис. 7.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 года, была опубликована первая версия спецификации «Общая метамодель хранилища данных».
CWMI определяет интерфейсы, которые могут быть использованы для обмена метаданными между ХД и аналитическими приложениями с помощью инструментальных средств ХД, программно-аппаратных платформ и репозиториев метаданных в распределенных гетерогенных вычислительных средах.
CWMI основывается на трех основных стандартах:
Стандарт UML определяет язык объектно-ориентированного моделирования, который поддерживает ряд графических нотаций. Стандарт MOF определяет гибкие средства для определения модели метаданных, и обеспечивает программные средства для хранения и доступа к метаданным в репозитории. Стандарт XMI определяет спецификации для обмена метаданными в формате стандарта XML. Использование этих стандартов не накладывает сильных ограничений при реализации модели метаданных в конкретных системах складирования данных.
Перечисленные выше стандарты формируют ядро архитектуры репозитория метаданных OMG, как показано на Рис. 7.6.
Рис. 7.6. Ядро архитектуры репозитория метаданных OMG
Основные элементы Общей метамодели хранилища данных (CWM) включают в себя:
Четырехуровневая архитектура метамоделирования аналогична общепринятой архитектуре моделирования, как показано ниже.
Архитектура метамоделирования
Стандарт расширяет базовую метамодель метамоделями для реляционных и многомерных данных, для преобразования, функций 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), как показано на Рис. 7.7.
Базовый слой состоит из метамоделей, которые поддерживают моделирование таких различных элементов и сервисов, как типы данных, системное преобразование типов, абстрактные ключи и индексы, выражения, бизнес-информация и включения программного обеспечения, основанного на использовании компонентных объектов.
Слой источников данных предоставляет возможность моделировать существующие и новые источники данных, в том числе реляционные базы данных, ориентированные на запись базы данных (record oriented databases), а также XML- и основанные на объектах (object-based) источники данных.
Слой анализа предоставляет средства для моделирования сервисов информационного анализа, которые обычно используются в Хранилище данных. Он определяет метамодель для преобразования данных, OLAP, визуализации информации и исследования данных (data mining).
Слой управления состоит из метамоделей, представляющих стандартные процессы и операции ХД, журнализации и планирования работ (например, ежедневной загрузки и выгрузки).
Набор метамоделей CWM является достаточным для моделирования всего ХД.
Рис. 7.7. Четыре уровня модели CWM
Когда требования к метаданным собраны и формализованы, можно приступать к разработке метамодели. На практике следовать требованиям стандарта часто бывает сложно. Причиной этого является дефицит времен и недопонимание важности проработки метамодели руководством компании, особенно, когда компания создает ХД силами своего ИТ подразделения. Руководство по проектированию и разработки метамодели CWM насчитывает более 700 страниц. Менеджменту ИТ подразделения трудно объяснить руководству компании, что для собственной разработки ХД необходимо либо взять новую штатную единицу, либо отправить своего специалиста на обучение.
Заказывает ли компания разработку ХД третьей компании или собирается проводить ее самостоятельно, можно выделить следующие способы создания метамодели:
Чтобы построить метамодель ХД вручную необходимо собрать правильные определения сущностей, их атрибутов и взаимосвязей между сущностями. Для разработки такой метамодели может быть использовано либо объектно-ориентированное моделирование, либо ER- моделирование.
Если для построения метамодели ХД проектировщик ориентируется на использование стандарта, то у него есть возможность либо использовать спецификацию «Открытая информационная модель» (Open Information Model OIM), либо спецификацию «Общая метамодель хранилища данных» (Common Warehouse Meta-Model, CWM). CWM описывает обмен метаданными в системах складирования данных, управления знаниями и деловой осведомленности. OIM является набором спецификаций метаданных для использования в разработке приложений ХД. Обе спецификации основываются на промышленных стандартах таких, как UML, XML и SQL.
Выбор подхода к проектированию метаданных во многом определяется набором инструментальных средств проектировщика ХД и выбором несущей СУБД. Ясно, что разработанная вручную метамодель имеет важное преимущество: она наиболее полно отражает представление метаданных компании. Но у такой модели есть большой недостаток - ее нужно сопровождать и поддерживать постоянно в актуальном состоянии вручную. Модели, разработанные с учетом стандартов, учитывают большинство требований по представлению метаданных компании в ХД. Кроме того, они расширяемы и поддерживаются ведущими производителями средств разработки (Oracle, IBM, Microsoft).
Репозиторий метаданных ХД следует поддерживать при использовании любого метода проектирования метаданных. При этом важно выбрать для него архитектуру (централизованный или распределенный) и способы поддержки его в актуальном состоянии (поскольку метаданные связывают между собой семантику всех компонент системы складирования данных).
Программные компоненты системы складирования данными через репозиторий обмениваются метаданными в процессе своей работы. Для организации обмена метаданными стандарт CWM позволяет детализировать архитектуру репозитория. При этом формат обмена метаданными есть XML документ.
Обращаясь к изучению вопроса логического проектирования модели метаданных, мы преследуем цель разобраться в сути процесса представления метаданных в ХД и выработать навыки построения модели метаданных, которые можно в дальнейшем применить для управления метаданными через репозитории метаданных, поставляемых производителями программного обеспечения для создания ХД.
Выше мы рассмотрели примеры описания метаданных для различных объектов ХД. Будем использовать эти примеры при создании нашей логической модели метаданных.
Создадим сначала логическую модель данных для метаданных таблиц фактов. Она может быть такой, как на Рис. 7.8.
Рис. 7.8. Модель метаданных для таблицы фактов
Метаданные о таблице фактов целесообразно разместить в двух сущностях, одна из которых «Таблицы фактов» содержит практически не меняющуюся информацию о таблице фактов, а другая «История загрузки» содержит данные, которые меняются согласно параметру «Частота загрузки».
В сущность «Таблицы фактов» включена информация:
В сущность «История загрузки» включена информация:
Оставшиеся элементы метаописания таблицы фактов находятся с сущностью «Таблицы фактов» в отношении наследования. Для представления этих элементов метаописания на рисунке введены дополнительные сущности, которые мы будем моделировать далее.
Таблица фактов многомерной модели содержит данные о фактах и метриках. Построим соответствующий фрагмент модели метаданных (Рис. 7.9).
Рис. 7.9. Модель метаданных для метрик таблицы фактов
Сущности «Факты», «Метрики фактов», «Метрики» и «Поля семы звезда» представляют описание характеристик фактов. Сущности «Атрибуты» и «Домены атрибутов» представляют физические определения метрик фактов в ХД.
В сущности «Атрибуты» присутствует атрибут «Ключ измерения», поскольку эта сущность также должна описывать атрибуты измерений.
Рассмотрим моделирование метаданных измерений (Рис. 7.10).
Рис. 7.10. Модель метаданных для таблиц измерений
Сущности «Измерения» и «Измерения и метрики» описывают измерения и их связи с метриками таблицы фактов. Сущность «Атрибуты» описывает атрибуты измерений.
Дополним разработанную модель метаданных для нашего примера информацией об источниках данных, как показано на Рис. 7.11.
Рис. 7.11. Модель метаданных для источников данных
Источники данных для ХД описаны в сущностях «Источники данных», «Таблицы», «Колонки», «Загрузка данных» и «Правила преобразования».
Таким образом, построена логическая модель метаданных ХД для нашего примера.
Заметим, что не все элементы описания метаданных были использованы при конструировании модели метаданных ХД. Это право проектировщика ХД, основанное на изучении требований к системе складирования данных.
Так же обратим внимание на то, что была создана частная модель, которая не учитывает ряд требований предъявляемых к модели метаданных. Как правило, при построении модели метаданных ХД должны быть учтены ряд обязательных элементов представления метаданных в модели, а именно:
Обратим внимание на то, что вопросам представления информации об информационной безопасности в этой лекции не было уделено никакого внимания. Как правило, программно-аппаратные решения в области обеспечения информационной безопасности носят конфиденциальный характер, и давать какие-либо общие рекомендации по их описанию в модели метаданных. Это будет определяться руководителем ИТ - проекта создания ХД.
В настоящей лекции мы рассмотрели понятие метаданных, как совокупности спецификаций и элементов данных, содержащих описание данных ИС и процессов их обработки. Были определены основные функции и дана классификация метаданных в ХД. Был дан краткий обзор спецификация «Общая метамодель хранилища данных».
На примере конкретного киоска данных было подробно показано, как формировать метаданные для модели, таблиц фактов, фактов, таблиц измерений и источников данных. Приведенное описание метаданных послужило основой для логического проектирования модели метаданных ХД.
Метаданные - это информация о данных, которая требуется для управления ХД, а управление метаданными - существенный компонент архитектуры хранения. К техническим метаданным относится вся информация, которая требуется для настройки и использования ХД. Предметно-ориентированные метаданные включают в себя бизнес - термины и определения данных ХД. Структурные метаданные - это описание объектов ХД и их характеристик. Метаданные процесса обработки данных - это информация, собранная во время работы ХД, такая как происхождение перенесенных и преобразованных данных; статус использования данных (активные, архивированные или удаленные); данные мониторинга, такие как статистика использования, сообщения об ошибках и результаты аудита.
Метаданные часто размещаются в репозитории, который позволяет совместно использовать метаданные различными инструментами и процессами при проектировании, установке, использовании, эксплуатации и администрирования ХД.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.