Метаданные в хранилищах данных

Состав метаданных в хранилище данных

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

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

Следующая, характерная для ХД, группа компонентов метаданных — описание преобразований. Как правило, описание преобразований данных для ХД включает в себя:

• идентификацию полей источников данных;
• соответствие между атрибутами сущностей источников данных и атрибутами объектов ХД;
• преобразования атрибутов;
• физические характеристики преобразований;
• преобразования таблиц кодировки и ссылочных таблиц;
• изменения наименований (соответствие имен источников и объектов ХД);
• изменение ключевых атрибутов;
• значение полей по умолчанию;
• логика (алгоритмы) формирования данных ХД из нескольких источников (приоритетность источников);
• алгоритмы трансформации данных и т. д.

Компоненты преобразования говорят нам о том, как данные в ХД были получены.

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

Информация о синонимах, или терминологические соответствия понятий, — это еще один компонент метаданных ХД. Он включает в себя альтернативные наименования (алиасы) для данных ХД. Такая информация, как правило, делает ХД более "дружелюбным" для пользователей.

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

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

Информация о том, кто отвечает за содержание и актуальность различных источников данных, составляет еще один компонент метаданных. Эта информация важна для группы сопровождения ХД и позволяет организационно решать вопросы качества, точности и надежности данных в ХД.

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

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

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

Из сказанного выше ясно, что проектирование метаданных ХД является достаточно сложной и креативной задачей для проектировщика ХД, решение которой требует часто литературного мастерства, знания предметной области ХД и много времени.

На рис. 14.2 приведены основные элементы метаданных для ХД.

Рис. 14.2. Основные элементы метаданных для хранилищ данных

Пример представления метаданных для хранилища данных

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

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

Далее допустим, что компания выпускает около 200 видов (моделей) некоторой продукции. Каждый продукт имеет базовый набор комплектующих компонентов. Дополнительные комплектующие компоненты используются для создания специфической модели продукта. Рыночная политика компании строится таким образом, что число выпускаемых моделей остается постоянным. Это означает, что количество новых моделей приблизительно равно количеству моделей, снятых с производства.

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

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

Компания поддерживает два способа реализации продукции: через магазин оптовой торговли и через магазин розничной торговли. Магазин оптовой торговли продает товар только оптовым покупателям. Покупатель считается оптовым, если он покупает более 20 партий товара в год. Оптовый покупатель может предоставлять счет либо непосредственно в магазин оптовой торговли, либо по факсу в центральный офис компании. Любой покупатель может покупать в нескольких магазинах компании.

Магазин розничной торговли продает за наличный расчет. Независимо от предоставления скидок, цена товара меняется. Хотя на каждую продажу продукции оформляется счет, компания не ведет учет покупателей в розничной продаже.

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

1. Какова величина общих издержек и общей прибыли по каждой модели товара, проданной сегодня, и просуммированной по точкам продажи, типу точки продажи, по региону и по складам оптовой торговли?
2. Какова величина общих издержек и общей прибыли для каждой модели товара, проданной сегодня, и просуммированной по заводам и по регионам?
3. Какой процент моделей получил скидки и какие из моделей были проданы по факту со скидкой (в процентах) в магазинах розничной продажи – для всех продаж на этой неделе? В этом месяце?
4. Для каждой модели товара, проданной в текущем месяце, определить, какой был процент продаж с розничной торговли, с оптовой торговли по безналичному расчету, с оптовой торговли с продавцами.
5. Какие модели и какого типа не продавались в течение последнего месяца? В течение последней недели?
6. Какие пять моделей, проданных за последний месяц, принесли наибольшую прибыль? По продажам за квартал? По всем продажам?

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

увеличить изображение
Рис. 14.3. Многомерная модель киоска данных для анализа продаж компании

Рассмотрим описание метаданных для такого киоска данных. Отметим, что приведенное описание является примером одного из возможных подходов, его нельзя считать полным и законченным.

Логическая структура метаданных хранилища данных

Логическая структура метаданных модели

В этом разделе приводятся логические схемы метаданных для ХД для взятого нами примера. Пример не претендует на полноту, но дает ясное представление о подходах к описанию метаданных.

Логическая структура модели метаданных может быть следующей.

Логическая структура метаданных фактов

Логическая структура метаданных фактов может быть следующей.

Имя: Продажа (Sale).

Определение: Этот факт содержит данные о продаже для каждого заказа, который был зафиксирован в оперативной системе обработки заказов для каждого склада розничной и оптовой торговли.

Альтернативное имя: Нет.

Частота загрузки: Ежедневно.

Статистика загрузки данных

• Дата последней загрузки.
• Число загруженных строк.

Статистика использования данных

• Среднее число запросов в день.
• Среднее число выбранных записей на запрос.
• Среднее время выполнения запроса.
• Максимальное число запросов в день.
• Максимальное число выбранных записей в запросе.
• Максимальное время выполнения запроса.

Правила архивирования данных: Данные будут архивироваться по истечении 36-ти месяцев на ежемесячной основе.

Статистика архивирования:

• Последняя дата архивации.

Правила удаления данных: Данные будут удаляться по истечении 48-ми месяцев на ежемесячной основе.

Статистика удаления:

• Последняя дата удаления.

Качество данных: Допускаются ошибки персонала при комплектовании заказов. Однако записи, представленные в БД, являются точными.

Точность данных: Метрики этого факта являются на 100% точными, поскольку представляют уже осуществленные продажи.

Гранулированность измерения "Время": Метрики данного факта представляют продажу данного товара по данному заказу.

Ключевое поле. Ключом для факта продажи является комбинация ключей измерений: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).

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

Источники

• Наименование: Таблица заказов (Order Table).
• Правила преобразования: Строки из таблицы заказов копируются в таблицу фактов продаж на ежедневной основе.
• Критерий выборки данных: Выбираются строки, для которых заказ был завершен на текущую дату.
• Наименование: Измерение "Продукт" (Product Dimension).
• Правила вычисления значения: Измерение "Продукт" используется для вычисления стоимости модели, проданной в конкретном заказе. Заводская стоимость единицы товара сравнивается с закупочной или отпускной ценой, чтобы определить, была ли дана скидка. Если скидка имела место, то вычисляется ее размер.
• Критерий выборки: Перед вставкой строки в таблицу фактов обрабатываются данные о товаре.

Метрики: Общая стоимость (Total cost), Общая прибыль (Total revenue), Общее количество продаж (Total quantity sold) и Скидка (Discount amount).

Измерения: Customer (Покупатель), Manufacture (Производитель), Продукт (Product) , Продавец (Seller) и Время (Time).

Сотрудник, ответственный за данные: Директор завода-производителя.