Лекция
Это продолжение увлекательной статьи про метаданные в хранилищах данных.
...
Ключ товара, ключ производителя, ключ продавца и ключ покупателя выбирается из справочников оперативной БД компании.
Источники
Метрики: Общая стоимость (Total cost), Общая прибыль (Total revenue), Общее количество продаж (Total quantity sold) и Скидка (Discount amount).
Измерения: Customer (Покупатель), Manufacture (Производитель), Продукт (Product) , Продавец (Seller) и Время (Time).
Сотрудник, ответственный за данные: Директор завода-производителя.
Логическую структуру метаданных для измерений приведем на примере измерений "Покупатель" и "Время". Она может быть следующей.
Для измерения "Покупатель"
Имя: Покупатель (Customer).
Определение: Покупатель — это любое физическое или юридическое лицо, которое приобретает продукцию компании. Покупатель может приобретать товары в нескольких точках продаж компании.
Альтернативное имя: нет.
Иерархия измерения: Данные по этому измерению могут суммироваться на двух уровнях. Первый уровень суммирования (нижний) есть адрес отгрузки товара покупателю. Данные по каждому адресу юридического лица могут быть позднее просуммированы по каждому покупателю.
Правила изменения: Адреса отгрузки товара по каждому юридическому лицу вставляются как новые строки в измерение. Изменение существующих адресов покупателей выполняется обновлением непосредственно в таблице измерения.
Частота загрузки: Ежедневно.
Статистика загрузки
Статистика использования
Правила архивации: Данные этого измерения не архивируются.
Статистика архивации:
Правила удаления: Покупатели, которые не приобретали продукцию компании в течение последних 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
Правила вычисления значения: Общие издержки равны произведению стоимости единицы товара (модели) на количество проданных моделей.
Статистика использования
Качество данных: Эта метрика формируется только исходя из стоимости комплектующих деталей на момент продажи данного вида товара. Никакие другие виды издержек на производство товара не учитываются.
Точность данных: Предполагается, что разброс значений в стоимости комплектующих деталей данного вида товара составляет +/- .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).
Метод извлечения данных: В исходной таблице выбираются записи с законченными на текущую дату операциями для добавления в ХД.
График извлечения данных: Ежедневно по завершении рабочего дня.
Статистика извлечения данных
Как правило, любая стандартизация начинается с построения классификации объектов, для которого разрабатывается стандарт. Стандарт в области метаданных не является исключением из этого правила. Второй аспект разработки любого промышленного стандарта — это учет предложений ведущих производителей. И третий момент — концепция, которая позволяет связать разрабатываемый стандарт с уже действующими в данной предметной области стандартами.
Предметом обсуждения этого раздела будет спецификация "Общая метамодель хранилища данных" (Common Warehouse Metamodel, CWM), которая является одним из стандартов [66], использующих XML-технологии. Этот стандарт описывает обмен метаданными в информационных системах, применяющих технологии ХД, а также в системах деловой осведомленности (Business Intelligence) и системах управления знаниями (Knowledge Management).
Как следует из нашего обсуждения метаданных в предыдущих разделах, на очень высоком уровне метаданные могут быть разделены на две категории: разделяемые метаданные (Shared meta data) и уникальные метаданные (Unique meta data).
Элементы разделяемых метаданные необходимы для точного определения объектов и их семантики для ХД в целом. Так, определение объекта "Покупатель" в нашем примере выше должно быть согласованным и для источников, и для ХД, т.е. иметь одинаковый смысл в рамках информационных систем масштаба организации. Уникальные метаданные описывают уникальные объекты системы, например, атрибуты измерений или фактов.
Другой подход к построению классификации метаданных — разделение элементов метаданных по их функциональному назначению:
Предметно-ориентированные метаданные содержат определения сущностей предметной области в терминах пользователей, логические отображения между данными на различных уровнях их представления в системе, описания словаря ХД, например БД.
Примером предметно-ориентированных метаданных может служить описание какого-либо атрибута сущности предметной области ХД, как то: вес проданного или закупленного товара. Рассмотрим пример на рис. 14.4.
В двух киосках данных системы складирования данных имеются две таблицы фактов: "Счета покупок" и "Счета продаж". Каждый киоск отвечает за определенное направление деятельности организации. В обеих таблицах имеется атрибут с именем "Вес". Семантический смысл этого атрибута в обоих случаях одинаков: вес товара. Однако в одном киоске данных может использоваться единица измерения веса "кг", а в другом - "центнер".
Cтруктурные метаданные содержат описание структуры различных объектов данных. Они используются при реализации схем навигации для представления данных пользователям. Например, объект данных "Книга" состоит из элементов "Название", "Автор", "Содержание", "Предисловие", "Глава с тестом". Каждая глава имеет "Заголовок" и, возможно, ряд "Подзаголовков".
Технические метаданные содержат определения и данные о физических объектах ХД. Это определения наименований таблиц и их колонок, ограничений, правил физических преобразований данных и т.п. Например, формат и длина поля "Имя покупателя" есть строка переменной длины до 100 символов.
Метаданные процесса обработки данных содержат информацию, связанную с процессом обработки данных, такую как статистика загрузки, расписание загрузки данных и т.п.
продолжение следует...
Часть 1 Метаданные в хранилищах данных
Часть 2 Стандарты метаданных - Метаданные в хранилищах данных
Часть 3 Выбор метамодели при проектировании хранилища данных - Метаданные в хранилищах
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL