Совет №26
Добавляем измерение аудита для отслеживания истории загрузки и степени
достоверности
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Всякий раз, когда мы строим таблицу фактов, содержащую измерение
величин нашего бизнеса, мы окружаем её "всем, о чём мы достоверно
знаем". В многомерной модели это всё-что-мы-знаем упаковывается
во множество измерений. Физически мы помещаем в нашу таблицу фактов
внешние ключи, по одному на измерение, и соединяем эти внешние ключи
с соответствующими первичными ключами каждого измерения. Внутри
каждого измерения (таких как продукт или клиент) содержится многословное
множество сильно связанных текстовых описаний, представляющих индивидуальных
членов измерения (таких как отдельный продукт или клиент).
Мы можем расширить этот подход проектирования нашей таблицы фактов,
основанный на всём, что мы знаем, включив фрагменты метаданных,
о которых известно, что они верны в момент создания отдельной строки
таблицы фактов. Например, когда мы создаём запись таблицы фактов,
мы должны знать такие вещи, как:
какая система является источником данных о фактах (несколько
описаний, в случае если источников несколько)
какая версия программного обеспечения извлечения данных использовалась
для создания записи
какая версия логики отнесения (если она использовалась) использовалась
для создания записи
что обозначает запись "не определено" - значение поля
неизвестно, невозможно, повреждено или ещё недоступно
был ли какой-то факт изменён после окончательной загрузки, и
если это так, то почему?
содержит ли запись факты, значения которых выходят за интервал
двух, трёх или четырёх стандартных отклонений от среднего значения
или, что эквивалентно, за границы доверительных интервалов, рассчитанных
какими-либо другими статистическими методами.
Первые три элемента описывают происхождение (источник) записи
таблицы фактов. Другими словами, откуда взялись данные? Три последних
элемента описывают степень нашей уверенности в качестве данных этой
записи таблицы фактов.
Как только мы начнём думать в этой манере, мы можем выдать длинный
список элементов метаданных, описывающих происхождение данных и
степень доверия к качеству данных. Но для целей данного совета мы
остановимся только на этих шести. Более тщательно проработанный
список можно найти в обсуждении измерений аудита в книге The
Data Warehouse Lifecycle Toolkit.
Хотя эти шесть показателей можно закодировать различными способами,
я предпочитаю кодирование текстом. В конечном счете, мы собираемся
накладывать условия на значения этих различных атрибутов аудита,
и мы хотим, чтобы пользовательские интерфейсы и надписи в отчётах
показывали понятный текст. Таким образом, возможно версия программного
обеспечения для извлечения данных (элемент №2) будет записана как
"Informatica release 6.4, Revenue extract v. 5.5.6". Элемент
№5 может содержать величины наподобие "не изменялось"
или "изменилось вследствие пересчёта".
Наиболее эффективным способом добавления информации об истории
загрузки и уровне доверия к таблице фактов - это создание единого
внешнего ключа Аудит в таблице фактов. Четырёхбайтного целочисленного
ключа более чем достаточно, поскольку соответствующее измерение
Аудит может иметь до 4 миллиардов записей. Нам не нужно так много!
Мы строим измерение Аудит как простое измерение с семью полями:
Audit Key (первичный ключ, 4 байта, целочисленный)
Source System (текстовый)
Extract Software (текстовый)
Allocation Logic (текстовый)
Value Status (текстовый)
Altered Status (текстовый)
Out of Bounds Status (текстовый)
В нашем бэкофисном процессе ETL (extract-transform-load) мы отслеживаем
все эти показатели и готовим их к моменту, когда таблица фактов
окончательно собирается. Если все шесть полей аудита уже существуют
в таблице измерения Аудит, мы выбираем соответствующий первичный
ключ из измерения Аудит и используем его в качестве вешнего ключа
в таблице фактов. Если для нашей строки таблицы фактов отсутствует
применимая строка таблицы измерения Аудит, мы создаём новую строку
и, добавив единицу к максимальному значению ключевого поля, используем
эту величину в качестве ключа новой записи измерения Аудит. Это
стандартная процедура создания суррогатных ключей. Далее мы продолжаем
как в первом случае. Таким образом, мы строим измерение Аудит за
период времени.
Заметьте, что если мы ежедневно загружаем большое количество записей,
почти все записи будут иметь одно и то же значение внешнего ключа
аудита, поскольку, очевидно, почти все записи будут "нормальными".
Мы можем изменить обработку, описанную в предыдущем абзаце, чтобы
извлечь из этого выгоду путём кэширования ключа аудита "нормальной"
записи и пропуская шаг его поиска для всех нормальных записей.
Теперь, когда мы построили измерение аудита, как мы будем его использовать?
Великолепие этого дизайна заключается в том, что метаданные истории
загрузки и степени доверия стали теперь обычными данными, и их можно
опрашивать и анализировать нарду с другими более знакомыми измерениями.
Существует два основных подхода к украшению ваших запросов и отчётов
показателями измерения аудита.
Подход "бедняка" заключается в добавлении желаемых атрибутов
аудита непосредственно к списку Select SQL-запроса. Другими словами,
простой запрос вида
Теперь ваш отчёт будет плодить дополнительную строку каждый раз
при возникновении аномальных условий на данные. Вы получите значение
количества строк, которое позволит вам оценить насколько плохо состояние
данных. Заметьте, что до того, как мы занялись проектированием,
в ваш отчёт тихо попадали значения с кодом НА (null), поскольку
функция SUM игнорирует значения null.
Подход "богатого" заключается в выполнении полноценных
запросов drill across, производящих отдельные столбцы (а не отдельные
строки) с более сложными показателями истории или качества. Например,
наш простой запрос о сумме продаж может быть приукрашен таким образом,
что будет отображать следующие столбцы в отчёте:
PRODUCT>>SUM(SALES)>>PERCENT OF DATA FROM OLD SOURCE
SYSTEM>>PERCENT OF DATA CORRUPTED
И так далее. Такие инструменты, как Cognos, Business Objects и
Microstrategy способны выполнить такие отчёты drill across, используя
"многопроходный SQL".
Мне будет интересно узнать о ваших вариантах проектирования, когда
вы конвертируете метаданные в данные и делаете из них измерение.
Пишите мне по адресу
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS