Лекция
Привет, Вы узнаете о том , что такое метаданные в хранилищах данных, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое метаданные в хранилищах данных , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.
К сожалению, часто встречающееся на страницах компьютерной литературы определение метаданных — это "данные о данных" — более вносит путаницу в толкование термина " метаданных " (metadata), чем поясняет его смысл. Образное определение " Метаданные — это "тень данных", принадлежащее Б. Инмону и понятное ИТ-специалистам по ХД, также не вносит большой ясности.
Давайте попробуем уточнить смысл термина " метаданные ". метаданные есть в любой ИС с БД, будь то OLTP-система, система складирования данных или корпоративный портал. Чтобы осознать этот факт, нужно вспомнить о том, что любая ИС реализует "вопросно-ответное" отношение на конечном алфавите [62]. Метаданные позволяют пользователям понять, на какие вопросы может отвечать данная ИС.
С технической точки зрения метаданные — это совокупность спецификаций и данных, которая в целом дает ответы на вопросы, какова степень охвата предметной области в ИС, какие данные в ней представлены, какова архитектура системы и т.д.
В частности, метаданные содержат семантическую интерпретацию или толкование содержания элементов данных, циркулирующих в ИС. Но это далеко не все. В метаданные включается также описание вычислительной среды, предметных областей, информационной безопасности и многое другое, что непосредственно влияет на эффективность использования ИС, в первую очередь, конечными пользователями и разработчиками.
Далее под метаданными будет пониматься совокупность элементов данных и спецификаций, содержащих описание данных ИС и процессов их обработки.
Неоднозначность толкования термина " метаданные " определяется тем обстоятельством, что последние должны удовлетворить технические и семантические потребности всех групп пользователей ИС. Каждая группа пользователей имеет свои требования к метаданным.
Так, руководство компании (основные пользователи информационных систем руководителей) хочет знать, что оно может получить от системы, как быстро оно получит ответ на интересующий вопрос, и желательно – в терминах, понятных лицам, которые принимают решения. Руководство организации не имеет времени, да и не понимает, зачем ему изучать объемные инструкции по эксплуатации ИС (что совершенно правильно, поскольку руководство организации решает стратегические и тактические задачи организации, а не профессиональные задачи реализации автоматизированных информационных систем).
В то же время специалисты организации, например пользователи бухгалтерских систем, хотят, чтобы такая система "разговаривала" на их профессиональном языке, вплоть до того, что разработчики таких систем (как, например, 1С-бухгалтерия) оснащают свои системы специальным, формальным языком, понятным бухгалтерам. Следует заметить, что бухгалтеры вряд ли будут основательно изучать SQL.
Аналитиков компании занимают более сложные вопросы, в частности, о происхождении и достоверности данных. Руководство организации требует от них информации для поддержки принятия обоснованных решений. Цена ошибки может быть велика: значительные убытки или сорванные контракты.
Разработчиков приложений интересует информация о модели данных ИС для создания или внедрения дополнительных бизнес-приложений. Они хотят знать, что находится в таблицах БД системы и в каком формате.
Отображение столь многообразных интересов в метаданных порождает большое число элементов, которые составляют метаданные. Проектирование и разработка метаданных являются одной из самых сложных и трудоемких задач проектирования и разработки ИС.
Разработку метаданных можно отнести к ИТ-дисциплине, которую называют "управление данными". Решение задач управления данными часто возлагается на администраторов данных, которых не следует путать с администраторами БД и компьютерных сетей.
Нужно отметить, что некоторые принципы управления данными в ХД и БД OLTP-систем имеют существенные отличия. Так, например, характерный для OLTP-систем принцип, состоящий в том, что существует только одно правильно отображающее семантику определение данных в системе, не является верным для ХД. Это связано с различными временными горизонтами данных в системах, основанных на ХД.
При проектировании метаданных задача проектировщика ХД состоит в:
Весь этот комплекс вопросов, которые должен решить проектировщик ХД при проектировании метаданных, требует от него достаточно тщательной их проработки еще на начальных стадиях проектирования. Проектирование ХД должно начинаться с проектирования метаданных и заканчиваться им же.
Рассмотрим основные функции метаданных и их состав, характерный для ХД.
Роль метаданных для ХД значительно важнее, чем в системах операционной обработки данных. Если в системах операционной обработки данных интерфейс системы настроен на бизнес-процедуры обработки данных конкретными специалистами и понятен им после специального обучения, то интерфейс систем складирования данных конструируется таким образом, чтобы помимо всего прочего отвечать на непредопределенные вопросы (ad hoc). Как правило, такие вопросы формулируются в терминах предметной области и бизнес-процессов, к тому же специалистами, для которых ИТ-технологии не являются основной профессией: аналитиками, менеджерами среднего и высшего уровня.
Таким образом, одним из главных аспектов использования метаданных в ХД является их предметная ориентация. Основные вопросы, на которые должны ответить метаданные, — это какие данные представлены в системе и как их получить в нужном для анализа данных виде.
Первой основной функцией метаданных в ХД является представление соответствия данных источников и данных ХД. Как правило, это описание представляет собой фиксацию взаимосвязи атрибутов данных источника и атрибутов данных ХД, правила преобразования первых во вторые, изменение в наименовании данных, в их физических характеристиках и т. д.
Такая информация позволяет идентифицировать источники данных для ХД, правильность данных в ХД и их корректность.
Вторая основная функция метаданных в ХД — управление данными во времени. Время жизни данных в ХД, как правило, 5-10 лет, а то и более. А для систем операционной обработки данных время жизни данных — от нескольких дней до нескольких месяцев. Затем данные архивируются в случае необходимости.
Таким образом, временной горизонт данных в ХД гораздо больше, и это обстоятельство изменяет коренным образом некоторые принципы управления данными. Например, в системах операционной обработки данных в одно и то же время существует только одно корректное определение данных. Для ХД это не так.
Структура данных (схема или модель данных) в системах операционной обработки данных меняется во времени, т.е. данные в таких системах в разное время имеют различные формы представления. Хронология таких изменений должна быть зафиксирована в ХД.
Таким образом, в ХД в одно и то же время может существовать несколько схем данных, отвечающих различным периодам эволюции источников данных. Запись о таких структурных изменениях сохраняется в метаданных ХД. На основании записей аналитики получают ответы на вопросы, какими данными и за какие периоды они располагают.
Третья, и немаловажная, функция метаданных в ХД — это поддержка версионности. Эта функция тесно связана с управлением данными с большим временным горизонтом. Метаданные должны отражать изменения внутренней структуры данных источников и, следовательно, должны сами изменяться, для того чтобы обеспечить непрерывность истории изменения структуры данных ХД.
Таким образом, поддержка версионности метаданных позволяет в каждый момент времени в прошлом обеспечить правильное описание модели данных, а аналитики получают возможность знать, какие данные, когда и как попали в ХД.
Четвертая основная функция метаданных в ХД — это интерпретация данных в терминах бизнес-пользователей. Метаданные должны поддерживать в запросах понятную для пользователя терминологию, независимо от того, какие правила наименования атрибутов были использованы проектировщиком ХД.
Пятая основная функция метаданных — обеспечение открытости (доступности другим информационным системам) системы складирования данных для ее интеграции с другими аналитическими системами организации. Опрос метаданных ХД другой системой позволяет последней выяснить структуру данных ХД и поддерживать обмен данными между системами.
На рис. 14.1 просуммированы основные функции метаданных для ХД.
Рис. 14.1. Основные функции метаданных для хранилищ данных
В настоящее время нет строго определенных требований к составу метаданных информационных систем, в том числе использующих ХД. О предлагаемых стандартах метаданных, и в частности для ХД, мы поговорим несколько позже. Сейчас остановимся на перечне тех элементов или компонентов метаданных, которые обязательно должны присутствовать в ХД.
Базовые компоненты метаданных ХД не сильно отличаются от базовых компонент систем операционной обработки данных. Это описание таблиц, их атрибутов, ключей и т.д. Существенное отличие для ХД — поддержка версионности метаданных. Базовые компоненты говорят нам, какие данные сохраняются в ХД.
Следующая, характерная для ХД, группа компонентов метаданных — описание преобразований. Как правило, описание преобразований данных для ХД включает в себя:
Компоненты преобразования говорят нам о том, как данные в ХД были получены.
Немаловажным компонентом метаданных ХД является история поступления в него данных. Компонент метаданных — история экстрагирования данных — говорит нам о том, когда данные поступили в ХД, а также позволяет судить о полноте представления данных в ХД. Для проведения анализа данных такая информация является очень важной, поскольку на ее основе формируются утверждения пользователей о корректности анализа данных и надежности его результатов.
Информация о синонимах, или терминологические соответствия понятий, — это еще один компонент метаданных ХД. Он включает в себя альтернативные наименования (алиасы) для данных ХД. Такая информация, как правило, делает ХД более "дружелюбным" для пользователей.
Следующим важным компонентом метаданных является информация о состояниях и статистике использования данных ХД. Эта информация составляет основу для оптимизации производительности ХД, и к ней относятся данные о числе строк в таблицах, скорости роста таблиц, статистический профиль использования таблиц (среднее и максимальное число запросов на день), статистика архивирования и удаления данных, индексирование таблиц, частота использования индексов в запросах и т.п.
Еще одним компонентом метаданных ХД являются алгоритмы агрегации и суммирования данных, критерии выборки из источников, правила преобразования данных источников перед загрузкой в ХД, описание взаимосвязей между объектами ХД, их кардинальность и т.п. Такая информация играет важную роль при проведении анализа данных и часто требуется аналитикам для решения вопросов надежности результатов анализа.
Информация о том, кто отвечает за содержание и актуальность различных источников данных, составляет еще один компонент метаданных. Эта информация важна для группы сопровождения ХД и позволяет организационно решать вопросы качества, точности и надежности данных в ХД.
Часто в метаданные включаются компоненты, описывающие шаблоны доступа к данным (когда и как данные мигрировали на другой уровень хранения). Они используются также для оптимизации физического потока данных в ХД и для оптимизации производительности.
Иногда алгоритмы обработки данных в ХД используют информацию об объектах внешних систем — так называемые таблицы расширения (таблицы кодировок и электронных справочников). В этом случае в метаданных ХД необходимо фиксировать описание таких таблиц и историю их изменения, поскольку в случае изменения кодов необходимо провести соответствующие изменения в обработке данных ХД, чтобы не потерять исторические связи в данных.
Часто проектировщики ХД включают в состав метаданных дополнительную информацию, важную с их точки зрения.
Из сказанного выше ясно, что проектирование метаданных ХД является достаточно сложной и креативной задачей для проектировщика ХД, решение которой требует часто литературного мастерства, знания предметной области ХД и много времени.
На рис. 14.2 приведены основные элементы метаданных для ХД.
Рассмотрим, как можно описать метаданные на примере киоска данных, предназначенного для анализа продаж некоторой гипотетической компании. Предположим, что компания занимается производством и реализацией своей продукции. Киоск данных используется аналитиками компании для детального изучения взаимосвязи расходов и доходов компании от реализации продукции и подготовки отчетности о продажах для руководства.
Допустим, что наша гипотетическая компания открыла сеть точек продаж (склады розничной и оптовой торговли) и организовала сеть магазинов, т.е. расширила свою деятельность. Руководство компании хочет оценить эффективность сделанного расширения и иметь более подробную информацию о зависимости между продажами и производством по затратам и доходам.
Далее допустим, что компания выпускает около 200 видов (моделей) некоторой продукции. Каждый продукт имеет базовый набор комплектующих компонентов. Дополнительные комплектующие компоненты используются для создания специфической модели продукта. Рыночная политика компании строится таким образом, что число выпускаемых моделей остается постоянным. Это означает, что количество новых моделей приблизительно равно количеству моделей, снятых с производства.
Для каждой модели каждого продукта в зависимости от спроса применяется гибкая система скидок. Как правило, размер скидки для покупателей больших партий продукции определяет заведующий складом розничной продажи.
Когда принято решение приостановить производство продукции данной модели, информация о ней сохранятся в БД компании в течение 6 месяцев после того, когда вся оставшаяся продукция будет реализована или списана. Данные о продукции удаляются в тот момент, когда удаляются данные о последней модели этой продукции.
Компания поддерживает два способа реализации продукции: через магазин оптовой торговли и через магазин розничной торговли. Магазин оптовой торговли продает товар только оптовым покупателям. Покупатель считается оптовым, если он покупает более 20 партий товара в год. Оптовый покупатель может предоставлять счет либо непосредственно в магазин оптовой торговли, либо по факсу в центральный офис компании. Любой покупатель может покупать в нескольких магазинах компании.
Магазин розничной торговли продает за наличный расчет. Независимо от предоставления скидок, цена товара меняется. Хотя на каждую продажу продукции оформляется счет, компания не ведет учет покупателей в розничной продаже.
Киоск данных нашей компании предназначен для решения задач анализа показателей расхода и дохода. Типовые запросы, на которые система должна давать ответы, следующие.
Источником данных для киоска данных является фрагмент БД системы операционной обработки данных компании. Одна из возможных структур данных киоска данных, полученная в результате проектирования, приведена на рис. рис. 14.3.
Рассмотрим описание метаданных для такого киоска данных. Отметим, что приведенное описание является примером одного из возможных подходов, его нельзя считать полным и законченным.
В этом разделе приводятся логические схемы метаданных для ХД для взятого нами примера. Пример не претендует на полноту, но дает ясное представление о подходах к описанию метаданных.
Логическая структура модели метаданных может быть следующей.
| Имя: | Продажи (Sales). |
| Определение: | Модель метаданных содержит метаописание данных о продажах компании для каждого вида продукции, в соответствии с каждым оплаченным счетом, на ежедневной основе. |
| Назначение: | Назначением данной модели является предоставление аналитикам и руководству компании возможностей для анализа продаж. |
| Ответственное лицо за корректность данных: | Региональный менеджер по продажам. |
| Измерения: | Customer (Покупатель), Manufacture (Производитель), Продукт (Product), Продавец (Seller) и Время (Time). |
| Факты: | Продажа (Sale). |
| Метрики: | Общие издержки (Total cost), Общий доход (Total revenue), Общее количество продаж (Total quantity sold) и Скидка (Discount amount). |
Логическая структура метаданных фактов может быть следующей.
Имя: Продажа (Sale).
Определение: Этот факт содержит данные о продаже для каждого заказа, который был зафиксирован в оперативной системе обработки заказов для каждого склада розничной и оптовой торговли.
Альтернативное имя: Нет.
Частота загрузки: Ежедневно.
Статистика загрузки данных
Статистика использования данных
Правила архивирования данных: Данные будут архивироваться по истечении 36-ти месяцев на ежемесячной основе.
Статистика архивирования:
Правила удаления данных: Данные будут удаляться по истечении 48-ми месяцев на ежемесячной основе.
Статистика удаления:
Качество данных: Допускаются ошибки персонала при комплектовании заказов. Об этом говорит сайт https://intellect.icu . Однако записи, представленные в БД, являются точными.
Точность данных: Метрики этого факта являются на 100% точными, поскольку представляют уже осуществленные продажи.
Гранулированность измерения "Время": Метрики данного факта представляют продажу данного товара по данному заказу.
Ключевое поле. Ключом для факта продажи является комбинация ключей измерений: Покупатель (Customer), Производитель (Manufacture), Продукт (Product), Продавец (Seller) и Время (Time).
Метод генерирования ключа: Временная часть ключа есть просто дата продажи товара.
продолжение следует...
Часть 1 Метаданные в хранилищах данных
Часть 2 Стандарты метаданных - Метаданные в хранилищах данных
Часть 3 Выбор метамодели при проектировании хранилища данных - Метаданные в хранилищах
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL