Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

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

Лекция



Это продолжение увлекательной статьи про метаданные в хранилищах данных.

...

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

Источники

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

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

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

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

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

Логическую структуру метаданных для измерений приведем на примере измерений "Покупатель" и "Время". Она может быть следующей.

Для измерения "Покупатель"

Имя: Покупатель (Customer).

Определение: Покупатель — это любое физическое или юридическое лицо, которое приобретает продукцию компании. Покупатель может приобретать товары в нескольких точках продаж компании.

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

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

Правила изменения: Адреса отгрузки товара по каждому юридическому лицу вставляются как новые строки в измерение. Изменение существующих адресов покупателей выполняется обновлением непосредственно в таблице измерения.

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

Статистика загрузки

  • Последняя дата загрузки.
  • Количество загруженных строк.

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

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

Правила архивации: Данные этого измерения не архивируются.

Статистика архивации:

  • Дата последней архивации.

Правила удаления: Покупатели, которые не приобретали продукцию компании в течение последних 5-ти лет, удаляются из таблицы измерения на ежемесячной основе.

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

  • Дата последнего обновления.

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

Точность данных: Допускается пятипроцентная неточность в определении связей между покупателем и его адресами отгрузки.

Ключ измерения: Сгенерированное системой число, которое идентифицирует покупателя.

Метод генерации ключа: Когда запись о покупателе копируется из подающей системы, выполняется проверка на присутствие покупателя в ХД. Если такого покупателя нет в ХД, новый идентификатор генерируется и запись вставляется в измерение.

Источники

  • Имя (Name): Таблица "Покупатель" (Customer).
  • Правила преобразования: Строки из таблицы "Покупатель" подающей системы копируются ежедневно.
  • Критерий выборки: Выбираются только новые или модифицированные на текущую дату строки.
  • Имя: Таблица "Адреса покупателей" (Customer Location).
  • Правила преобразования: Строки из таблицы "Адреса покупателей" копируются ежедневно в таблицу измерения. Для существующих адресов покупателей адрес отгрузки обновляется. Для новых адресов покупателей ключ генерируется и записи вставляются.
  • Критерий выборки: Выбираются только те записи, которые на текущую дату были обновлены или добавлены.

Атрибуты

  • Имя: Идентификатор покупателя (Customer Key)
  • Определение: Это есть произвольно выбранное число, гарантирующее уникальность каждого покупателя и его адреса.
  • Правила изменения: После вставки в измерение значение этого атрибута никогда не изменяется.
  • Тип данных: Числовой.
  • Домен: 1 - 999999999
  • Правила вычисления значения: Сгенерированный системой ключ.
  • Источник: Генерируется системой.
  • Имя: Наименование (Name).
  • Определение: Наименование, под которым покупатель известен компании.
  • Правило изменения: При изменении наименования покупателя оно обновляется для всего этого измерения.
  • Тип данных: Символьный.
  • Домен: Допустимая строка символов.
  • Правила вычисления значения: Для того чтобы различать покупателей из разных организаций с одинаковым названием, к названию организации будет добавляться число.
  • Источник: Поле "Наименование" (Name) из таблицы покупателей (Customer) подающей системы.
  • Имя: Адрес отгрузки (Ship-to Address).
  • Определение: Для юридических лиц — это адрес, по которому отгружается товар. Допускается, что одно юридическое лицо может иметь несколько адресов отгрузки. Для физических лиц и розничных покупателей это поле не поддерживается. Таким образом, для таких покупателей в таблице измерения поддерживается только одна запись.
  • Правила изменения: При изменении адреса отгрузки выполняется обновление этого значения в измерении.
  • Тип данных: Символьный.
  • Домен: Запись адреса в допустимом формате.
  • Правила вычисления значения: Адрес отгрузки копируется из таблицы источника.
  • Источник: Поле "Адрес отгрузки" (Ship-to Address) из таблицы "Адреса покупателей" (Customer Location) подающей системы.

Факты: Продажа (Sale).

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

Ответственный за поставку данных: Вице-президент по продажам и маркетингу.

Для измерения "Время"

Имя: Время (Time).

Определение: Измерение "Время" содержит моменты времени, когда компания фиксирует данные о продажах.

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

Иерархия измерения: Наименьший уровень суммирования данных есть день. Данные для этого дня могут быть просуммированы либо за неделю, либо за месяц.

Правила изменения: Записи вставляются в измерение один раз за текущий год. Никакие обновления в этом измерении не допускаются.

Частота загрузки: По мере необходимости.

Статистика загрузки

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

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

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

Правила архивации: Данные этого измерения не архивируются.

Правила удаления: По истечении 5-ти лет данные будут удаляться на ежегодной основе.

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

  • Дата последнего удаления

Качество данных: Никаких ошибок в данных этого измерения не предполагается.

Точность данных: Данные этого измерения всегда точны.

Ключ измерения: Ключ измерения "Время" есть дата в формате ГГГГММДД.

Метод генерации ключа: Дата, представленная в строке, используется как значение ключа.

Источник

  • Имя: Календарь, поддерживаемый администратором.
  • Правила преобразования: Все строки календаря вставляются один раз в год.
  • Критерий выборки: Все строки выбираются.

Атрибуты

  • Имя: Идентификатор (Time_ID).
  • Определение: Это есть дата в формате ГГГГММДД.
  • Альтернативное имя: нет.
  • Правила изменения: После вставки значение этого поля никогда не изменяется.
  • Тип данных: Числовой.
  • Домен: допустимое знание для даты.
  • Правила вычисления значения: Дата есть копия значения источника.
  • Источник: Числовое значение даты из календаря.
  • Имя: Месяц (Month).
  • Определение: Номер месяца в году.
  • Альтернативное имя: нет.
  • Правила изменения: После вставки значение этого поля никогда не изменяется.
  • Тип данных: Числовой.
  • Домен: 1-12.
  • Правила вычисления значения: Значение копируется из источника.
  • Источник: Номер месяца в году из календаря.
  • Имя: Неделя (Week).
  • Определение: Номер месяца в году.
  • Альтернативное имя: нет.
  • Правила изменения: После вставки значение этого поля никогда не изменяется.
  • Тип данных: Числовой.
  • Домен: 1-52.
  • Правила вычисления значения: Значение копируется из источника.
  • Источник: Номер недели в году из календаря.

Факты: Продажа (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).

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

Другой подход к построению классификации метаданных — разделение элементов метаданных по их функциональному назначению:

  • предметно-ориентированные метаданные (Business meta data);
  • структурные метаданные (Structural metadata);
  • технические метаданные (Technical meta data);
  • метаданные процесса обработки данных (Process meta data).

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

Примером предметно-ориентированных метаданных может служить описание какого-либо атрибута сущности предметной области ХД, как то: вес проданного или закупленного товара. Рассмотрим пример на рис. 14.4.

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

Рис. 14.4. Предметно-ориентированные метаданные: одно имя, одинаковый смысл, различные единицы измерения

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

Cтруктурные метаданные содержат описание структуры различных объектов данных. Они используются при реализации схем навигации для представления данных пользователям. Например, объект данных "Книга" состоит из элементов "Название", "Автор", "Содержание", "Предисловие", "Глава с тестом". Каждая глава имеет "Заголовок" и, возможно, ряд "Подзаголовков".

Технические метаданные содержат определения и данные о физических объектах ХД. Это определения наименований таблиц и их колонок, ограничений, правил физических преобразований данных и т.п. Например, формат и длина поля "Имя покупателя" есть строка переменной длины до 100 символов.

Метаданные процесса обработки данных содержат информацию, связанную с процессом обработки данных, такую как статистика загрузки, расписание загрузки данных и т.п.

продолжение следует...

Продолжение:


Часть 1 Метаданные в хранилищах данных
Часть 2 Стандарты метаданных - Метаданные в хранилищах данных
Часть 3 Выбор метамодели при проектировании хранилища данных - Метаданные в хранилищах

создано: 2021-03-13
обновлено: 2021-03-13
54



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Поделиться:

Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей

Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL