Серии советов популяризатора технологий хранилищ данных Ральфа Кимбалла
Совет №01. Руководство по проектированию выразительной витрины данных для анализа журнала посещаемости веб-сайта
Журнал посещаемости веб-сайта - это набор записей о событиях, происходящих во время просмотра страниц веб-сайта, который собирает веб-сервер. Исходные данные содержат запись каждого щелчка мышью посетителя сайта, который веб-сервер способен зарегистрировать. Журнал посещаемости содержит беспрецедентно подробную информацию о каждом движении посетителя веб-сайта.
Размер журнала посещаемости огромен. Даже коммерческие серверы со средней загруженностью могут ежедневно генерировать до 100 миллионов записей о событиях на страницах сайта. Мы должны уменьшить количество данных до управляемых размеров для проведения наиболее важных видов анализа. В этом совете мы поищем способ НЕ выйти за пределы 100 миллионов записей, вместе с этим сохранив приемлемый уровень детализации для анализа поведения посетителей веб-сайта.
В исходных данных журнала посещаемости содержатся подсказки к интересным измерениям (dimension), включая следующие: календарный день, время суток, посетитель, запрошенный объект страницы, ссылающийся контекст (на какой странице содержалась ссылка на текущую страницу), а также действие (получение объекта с сервера, либо отправка объекта на сервер).
Рекомендуемая степень детализации таблицы фактов для анализа поведения посетителя:
Одна запись таблицы фактов = Одна сессия посетителя
Если в среднем каждая сессия состоит из 20 событий, то количество записей таблицы фактов сократится до 5 миллионов в день, что сравнимо с опытом построения хранилища данных (DWH) для сети розничной торговли среднего размера.
Рекомендуемые измерения для данной таблицы фактов:
- День веб-сервера (календарная дата как её фиксирует веб-сервер)
- Время веб-сервера (начало сессии как количество секунд, прошедших с полночи на часах веб-сервера)
- День посетителя (календарная дата с точки зрения посетителя сайта)
- Время пользователя (начало сессии как количество секунд, прошедших с полночи на часах посетителя)
- Посетитель (обобщённое понятие “Посетитель” для анонимных посетителей, уникальное генерируемое системой имя для незарегистрированных посетителей, принявших cookie и реальное имя для зарегистрированных посетителей)
- Стартовая страница (идентификатор первой страницы данной сессии: страница, привлёкшая посетителя из другого места в web)
- Последняя страница (идентификатор последней страницы данной сессии: может быть “убийцей” сессии)
- Ссылающийся контекст (URL страницы, с которой посетитель попал на сайт, если известен)
- Диагностика сессии (простое описание характера сессии)
Рекомендуемые числовые факты (fact):
- Количество посещённых страниц
- Общее время пребывания на сайте (некоторая оценка, поскольку мы не можем знать реальные действия посетителя)
Эта модель может стать очень мощной базой для оценки поведения посетителя веб-сайта. Наиболее важное измерение - “Диагностика сессии”. Вы должны разработать сложный процесс преобразования и загрузки данных для создания хорошей диагностики сессий из последовательностей детальных событий на страницах сайта.
Для продолжения знакомства с данным предметом можно ознакомиться со статьёй из архива журнала Intelligent Enterprise (к сожалению, адрес, указанный в оригинале, не существует - прим. перев.)
Ещё одна статья появится в журнале Intelligent Enterprise в январе 2000 года. В ней более подробно будут рассмотрены измерения “Страница” и “Диагностика Сессии”.
Комментарии к совету №1
Я получил ряд интересных комментариев по поводу первого совета, который рекомендовал многомерную модель (multidimensional model) для сбора данных о посещаемости веб-сайта. Несколько человек спросили меня о том, почему я рекомендовал детализацию таблицы фактов на уровне завершённой сессии, в то время как в статье в журнале Intelligent Enterprise от 5 января 1999 года рекомендуется выбрать уровень детализации в одно событие на странице. Эти люди спрашивали меня, не изменил ли я своего мнения.
Нет, я не изменил своего мнения, но я лучше понимаю проблему. Существует, по крайней мере, три уровня детализации, на которых можно представлять данные о посещаемости веб-сайта.
- Запись в таблице фактов = отдельное событие на странице. Этот уровень, описанный в статье в журнале IE, может предоставить детальные карты и траектории каждого посещения сайта, если вы сохраняете каждую запись. Но для сайтов с очень высокой загрузкой это составит очень большой объём данных. Вы потратите всё своё время и деньги, собирая и сохраняя данные, а не анализируя их. Несколько человек рассказали мне о том, что статистические методы могут на тестовых выборках в 1% от всего объёма данных достаточно достоверно описать характер использования сайтов, что может помочь в принятии важных решений о том, как сайт используется, даже если в выборке не присутствует информация обо всех посетителях. Мне очень нравится это предложение. Вам, возможно, потребуется консультация опытного специалиста в области статистики для проведения репрезентативной выборки ваших данных.
- Запись таблицы фактов = одна законченная сессия посетителя. Это уровень детализации, описанный в рекомендации №1. В этом случае вы можете реалистично собрать информацию обо всех посетителях, несмотря на то, что вы не видите полную траекторию их навигации по вашему сайту. Но вы можете провести широкий демографический анализ, а также анализ эффективности вашего сайта. Помните, что в Вашем распоряжении есть информация о стартовой и последней страницах, а также измерение “Диагностика сессии”.
- Запись таблицы фактов = страница сайта за календарный день. Этот уровень детализации является одним из похожих на него уровней агрегации, которые могут пригодиться для оценки общей картины посещаемости отдельных частей вашего сайта. Очевидно, что преимуществом данного уровня детализации является сильно сокращённый объём данных, но, как и в случае с любой агрегированной таблицей фактов, вы подавляете некоторые измерения, описывающие поведение, такие как “Посетитель” и “Диагностика сессии”.
Совет №02. Множественные временные отметки
Наиболее частый вопрос, который мне задают в аудитории или по электронной почте, это вопрос о том, как обрабатывать множественные временные отметки в таблице фактов. Несмотря на то что правильный и немедленный ответ звучит как “сделайте каждую временную отметку измерением Время”, стоит внимательно описать этот подход, поскольку он хорошо иллюстрирует целый набор современных приёмов проектирования хранилищ данных, которые я выделю БОЛЬШИМИ БУКВАМИ.
Во-первых, выберите БАЗОВУЮ СТЕПЕНЬ ДЕТАЛИЗАЦИИ вашей таблицы фактов. Любая таблица фактов, которую я когда-либо проектировал, была либо на уровне транзакции (transaction grain), периодического снимка (periodic snapshot grain) или аккумулирующего снимка (accumulating snapshot grain). В этой статье вы сможете познакомиться с другими базовыми степенями детализации. Когда вы поймёте базовую степень детализации, вы сможете оценить, каков смысл и уместность множественных временных отметок по отношению к этой степени детализации. Множественные временные отметки наиболее часто встречаются на уровне аккумулирующего снимка данных, когда запись в таблице фактов описывает, например, полную историю строки заказа. Множественные временные отметки могут представлять
- Оригинальную дату размещения заказа
- Желаемую дату доставки товара
- Реальную дату отгрузки
- Реальную дату доставки
- Дату возврата
Во-вторых, для приведённого выше примера со строкой заказа создайте пять РОЛЕЙ для одного измерения Время. Ознакомьтесь со статьёй, в которой обсуждаются роли. Это означает пять полей в таблице фактов, каждое из которых является хорошим внешним ключом, связанным с измерением. Единое измерение Время “предоставляется” таблице фактов через пять представлений, которые семантически изолируют каждый экземпляр измерения Время друг от друга, так как они должны быть изолированы.
В-третьих, убедитесь в том, что внешние ключи в таблице фактов представляют собой правильные СУРРОГАТНЫЕ КЛЮЧИ. Другими словами, они должны иметь не тип даты/времени SQL, а быть бессмысленными целыми числами. Сопротивляйтесь любому искушению вложить какой-либо смысл или порядок сортировки в эти ключи! Для более близкого знакомства с проблемой суррогатных ключей ознакомьтесь со статьями “Суррогатные ключи. Контролируйте идентификаторы строк формированием суррогатных ключей в хранилищах данных” и “Суррогатные ключи. Конвейерная обработка суррогатных ключей“. Если вы внимательно присмотритесь к нашему примеру со строкой заказа, то вы согласитесь с тем, что некоторые из временных отметок должны иметь значения “неизвестно” или “событие ещё не произошло”. Это одна из классических причин использования суррогатных ключей.
Если ваши временные отметки имеют точность на уровне минут или секунд, то вы должны отделить календарный день от времени суток и разнести их по разным измерениям. Мы обсудим варианты проектирования подобных временных отметок в будущих выпусках советов разработчику.
Совет №03. Концентрируйтесь на бизнес-процессах, а не на бизнес-подразделениях!
Одним из господствующих заблуждений в нашей отрасли является то, что витрины данных определяются бизнес-подразделениями. Мы видели бесчисленное множество диаграмм архитектуры хранилищ данных с прямоугольниками с названиями “Витрина данных управления маркетинга”, “Витрина данных управления продаж” и “Витрина данных финансового управления”. После сбора и анализа потребностей бизнеса всех этих трёх организаций, вы бы неизбежно узнали, что все они хотят иметь одну и ту же базовую информацию, такую как информация о заказах. Вместо разработки витрины данных (data mart) для управления маркетинга, включающей данные о заказах, и витрины данных для управления продаж, включающей данные о тех же самых заказах, вам следует построить одну витрину данных с детальной информацией о заказах и дать к ней доступ сотрудникам различных подразделений.
Концентрация на бизнес-процессах, а не на бизнес-подразделениях позволит вам более экономно предоставлять информацию в масштабах организации. Если вы создадите витрины данных, привязанные к подразделениям, вы будете дублировать данные. Независимо от того, является ли источником оперативная система или хранилище данных, множественные потоки данных в витрины данных неизбежно приведут к несогласованности в данных. Самый лучший способ обеспечения согласованности - опубликовать данные единожды. Единый процесс публикации также сокращает усилия по разработке процедур выгрузки, преобразования и загрузки данных, накладные расходы на сопровождение, и снижает требования к дисковой подсистеме.
Мы понимаем, что построить ориентированные на процессы витрины данных при традиционном принципе финансирования по подразделениям может оказаться непросто. Вы можете продвигать концепцию ориентации на процессы, проведя тщательный анализ излишних расходов, связанных с разработкой и поддержкой одних и тех же (или почти одних и тех же) больших таблиц фактов в нескольких витринах данных. Даже если между подразделениями возведены стены, руководство часто рассматривает возможности экономии средств.
Каким же образом определить ключевые бизнес-процессы вашей организации? Первый шаг - выслушать ваших бизнес-пользователей. Показатели производительности, анализу которых они уделяют так много внимания, являются результатом бизнес-процессов. По мере того как вы будете собирать требования, вам следует также исследовать информационные источники. На самом деле, наиболее простым началом будет создание витрин данных на основе оперативных систем. После того как вы определили витрины данных в терминах бизнес-процессов и систем-источников, вы можете концентрироваться на витринах, интегрирующих данные, порождаемые разными бизнес-процессами, такие как цепочка поставок или все составляющие прибыльности или удовлетворённости клиентов. Мы рекомендуем приступать к этим более сложным (хотя и очень полезным) витринам, ориентированным на несколько процессов, на вторичных фазах внедрения.
Естественно, нет ничего удивительного в том, что вам будет необходимо использовать согласованные измерения в нескольких витринах данных. Также мы настоятельно рекомендуем составить матрицу Data Warehouse Bus до того, как вы будете разрабатывать генеральную стратегию построения витрин данных. Только не допускайте в вашей матрице строк с названиями “Управление маркетинга”, “Управление продаж” и “Финансовое управление”.
Совет №04. Исключительно быстрое управление сложными измерениями “Клиент”
Многие разработчики хранилищ данных должны иметь дело с трудными измерениями “Клиент”, которые одновременно и широкие, и глубокие. Измерение “Клиент” может иметь 100 или более описательных атрибутов и содержать миллионы строк. Иногда “клиенты” - это владельцы полисов медицинского страхования, в других случаях это - владельцы транспортных средств. Но проблемы проектирования при этом одинаковые.
Часто в таких ситуациях хранилище данных получает полностью обновлённую копию измерения “Клиент” с периодичностью, до одного раза в день. Естественно, идеальной ситуацией было бы, если бы в хранилище поступали только “дельты” (изменённые данные), но в большинстве случаев хранилище данных должно находить изменившиеся записи путём тщательного просмотра всего файла. Этот процесс сравнения вчерашних записей с сегодняшними для каждой записи в поисках изменений является очень запутанным и медленным.
Вот метод, который выполняет шаг сравнения с ослепительной скоростью и предоставляет дополнительный бонус в виде более простой программы преобразования и загрузки данных. Этот метод основан на простом коде CRC, который вычисляется для каждой записи (не для каждого поля) во входящем файле с информацией о клиентах. Больше о CRC через мгновение. Вот шаги, которые необходимо запрограммировать:
- Прочитайте каждую запись сегодняшнего файла с информацией о клиентах и рассчитайте величину CRC для неё.
- Сравните это значение CRC со значением CRC для этой же записи, которое вы рассчитали вчера и сохранили. Вам нужно будет выполнить сопоставление записей на основе естественных ключей оперативной системы (идентификатора клиента) для того чтобы убедиться в том, что вы сравниваете правильные записи.
- Если коды CRC совпадают, можете быть уверены в том, что все сто полей двух записей полностью совпадают. ВАМ НЕ НАДО СРАВНИВАТЬ КАЖДОЕ ПОЛЕ ПО ОТДЕЛЬНОСТИ.
- Если коды CRC отличаются, вы можете немедленно создавать новый суррогатный ключ (surrogate key) и помещать обновлённую запись в измерение “Клиент” вашего хранилища. Это медленно изменяющееся измерение типа 2 (SCD2). Более основательная версия программы могла бы произвести поиск во всех ста полях для принятия решения о дальнейших действиях. Может быть, значения некоторых полей приведут к необходимости переписать запись в таблице измерения хранилища, что будет в случае SCD типа 1 (SCD1).
Если вы никогда не слышали о кодах CRC, не унывайте: ваш программист процедур загрузки данных знает, что это такое. CRC - это сокращение для Cyclic Redundancy Checksum. Это математическая методика создания уникального кода для каждой входной записи. Алгоритм вычисления кода CRC можно реализовать с помощью языков программирования Basic или C. Большинство вводных курсов по программированию описывают алгоритм построения кода CRC. Обратитесь также к поисковой системе Google с поиском по ключевым словам “CRC code” или “checksum utility”.
Совет №05. Суррогатные ключи для измерения “Время”
Ежедневно я получаю несколько вопросов, касающихся проектирования хранилищ данных. Поскольку многие из них являются серьёзными и интересными, я пытаюсь на них ответить. Но если получается так, что они являются домашними заданиями преподавателей колледжа, я вежливо отказываю!
А вот и вопрос:
Консультант, работавший недавно у нас, предложил измерение (dimension) “Время”, которое отличается от тех, которые разрабатываете Вы.
Структура его измерения “Время” была следующей:
Key |
varchar2(8) |
StartDate |
date или date/tme |
EndDate |
date или date/tme |
Примерные данные выглядели следующим образом:
Key |
StartDate |
EndDate |
xmas99 |
25Nov99 |
06Jan00 |
1qrtr99 |
01Jan99 |
31Mar00 |
01Jan00 |
01Jan00 |
01Jan00 |
Как Вы смотрите на подобную структуру измерения “Время”? Для какого типа сценария/бизнеса Вы сочли бы это хорошей, имеющей право на существование альтернативой?
Вот как я ответил:
Я не думаю, что мне нравится такое измерение “Время”, если вообще это можно назвать измерением. Я ожидаю, что измерение “Время” будет описывать временной контекст величины, выраженной в виде значения в таблице фактов. В терминах базы данных это означает, что в каждой записи таблицы фактов должен быть внешний ключ (foreign key) со значением времени, который указывает на определённую запись в измерении “Время”.
Для простоты разработки приложения очень важно иметь единую степень детализации в каждой таблице фактов. Другими словами, все записи таблицы фактов должны представлять значения, измеренные, например, на уровне дня, недели или месяца.
В предложенном Вами измерении “Время” есть записи с различным уровнем детализации, которые отражают перекрывающиеся интервалы времени. Если у вас есть запись с величиной, измеренной в определённую дату, а записи этого “измерения Время” перекрываются, то какую из записей вы выберите в качестве ссылки для конкретной записи в таблице фактов?
В таблице фактов с единым уровнем детализации вы можете использовать соответствующее измерение “Время” для простых ограничений нескольких различных временных интервалов. Таблица измерения “Время” с записями для каждого отдельного дня является очень гибкой, поскольку в этой таблице вы можете одновременно представить все полезные группировки времени, о которых вы только можете подумать.
Типичная таблица измерения “Время” со степенью детализации на уровне дня и с перспективой использования в США (а с некоторыми модификациями и в России - прим. перев.) могла бы иметь следующую структуру:
- Ключ_времени (суррогатный ключ (surrogate key); простые целые числа от 0 до N)
- Тип_времени (Нормальное; Неприменимо; Ещё_не_произошло; Повреждено)
- Метка_времени_SQL (временнАя отметка длиной 8 байт для Тип=Нормальное иначе Null)
- Номер_дня_в_месяце (1..31)
- Номер_дня_в_году (1..366)
- Номер_дня_в_эпохе (положительное или отрицательное число)
- Номер_недели_в_году (1..53)
- Номер_недели_в_эпохе (положительное или отрицательное число)
- Номер_месяца_в_году (1..12)
- Номер_месяца_в_эпохе (положительное или отрицательное число)
- Название_месяца (может быть получено из поля Метка_времени_SQL)
- Год (может быть получен из поля Метка_времени_SQL)
- Квартал (1 кв. .. 4 кв.)
- Полугодие (1, 2)
- Финансовый_период (названия или числа в зависимости от вашего финансового подразделения)
- Государственный_праздник (Новый год, День независимости, День благодарения, Рождество)
- Рабочий_день (Д, Н)
- Уикенд (Д, Н)
- Сезон_продаж (зимняя распродажа, назад в школу, Рождественский сезон)
- Бедствие (ураган Хьюго, землетрясение)
В этой таблице вы создаёте по одной записи для каждого дня в году и записываете в каждое поле (описанное выше) значения, относящиеся к этому дню. Все специальные поля, предназначенные для навигации, такие как Финансовый_период и Сезон_продаж, дают вам возможность произвольно определять любые промежутки времени. Например, вы можете ввести условие Сезон_продаж=”Назад в школу” и автоматически получить все дни с 15 августа по 10 сентября.
В предложенном Вами дизайне Вы показываете ключи таблицы измерения “Время” со значениями, подобными “xmas99″ и “1qtr99″. Это - интеллектуальные ключи. Интеллектуальные ключи по нескольким причинам представляют опасность в таблице измерения хранилища данных. Процесс генерации таких ключей становится заложником синтаксических правил их формирования. Существует искушение писать приложения и пользовательские интерфейсы, которые сделают эти ключи видимыми для кого-то. Но, если есть значение “1qtr99″, гарантируете ли Вы, что имеется также и “2qtr99″? И что вы будете делать, в случае если вам понадобится отразить ситуацию, когда временная отметка должна иметь значение “Неприменимо”?
Мы обсудили присвоение суррогатных ключей в других форумах, но мы действительно имеем в виду то, что говорим здесь: ключи измерения “Время” не должны иметь значения для приложения. Они представляют собой целые числа, над которыми нельзя производить вычисления.
Дополнение к совету №5: суррогатные ключи для измерения “Время”
Мне хотелось бы поделиться с вами некоторыми полезными комментариями, которые я получил по поводу совета №5, в котором я описал предпочтительную структуру измерения “Время” и сказал, что первичным ключом (primary key) в этом измерении должно быть целое число, а не настоящая временная отметка.
Несколько человек, которые в остальном согласились с этим подходом, сказали, тем не менее, что может оказаться полезным присвоение суррогатным ключам измерения “Время” корректного порядка в соответствии с датами в каждой записи таблицы измерения. Это позволяет провести физическое секционирование (partitioning) любой таблицы фактов на основе значений суррогатного ключа времени. Физическое секционирование большой таблицы фактов по времени является очень естественным подходом в любом случае, поскольку он позволяет элегантно удалить устаревшие записи, а также проиндексировать вновь поступившие записи, не затрагивая оставшейся части таблицы фактов, если вы используете возможности секционирования, предоставляемые вашей СУБД.
Также, поскольку я по случаю как-то упомянул о том, что Microsoft SQL Server является единственной СУБД класса high end, не поддерживающей физическое секционирование таблиц, я был рад узнать, что в SQL Server 2000 секционирование таблиц является штатным средством.
Совет №06. Показываем связь между измерениями
Один из вопросов, который мне часто задают, это вопрос “Как можно представить связь между измерениями (dimension), не обращаясь к таблице фактов?” Часто разработчик задаёт следующий вопрос: “Могу ли я создать маленькую таблицу связи со всего двумя ключами измерений, а затем соединить ЭТУ таблицу с таблицей фактов?”
Естественно, в классической многомерной модели у нас имеется всего два варианта. Либо оба измерения моделируются независимо, а затем ключи этих измерений сводятся вместе ТОЛЬКО в таблице фактов, либо эти два измерения объединяются в одно единое супер-измерение с одним ключом. Так, когда же разработчику выбрать отдельные измерения, а когда их объединять?
Чтобы быть более конкретными давайте предположим, что два измерения это “Продукт” и “Рынок” в системе для предприятия розничной торговли. Предположим, представляющая для нас интерес таблица фактов хранит записи о продажах “Продуктов” на различных “Рынках” во времени. Наше стремление отразить связь между измерениями “Продукт” и “Рынок” основано на подозрении, что “Продукты очень сильно связаны с Рынками в нашем бизнесе”. Это предложение является ключом всего вопрос проектирования.
Если продукты чрезвычайно сильно связаны с рынками, то между измерениями “Продукт” и “Рынок” может быть связь один-к-одному или многие-к-одному. В этом случае объединение двух измерений имеет большой смысл. Размер результирующего измерения будет равен всего лишь размеру большего из измерений. Навигация (просмотр комбинаций значений) в пределах объединённого измерения была бы полезной и быстрой. Обнаружились бы интересные закономерности.
Но очень редко между продуктами и рынками существует такая замечательная связь. В дело вмешиваются как минимум три фактора, заставляющие нас разделить эти измерения.
- Отношения один-к-одному и многие-к-одному могут быть буквально неверными. Мы можем быть вынуждены признать, что отношение на самом деле является отношением многие-ко-многим. Когда большинство продуктов продаётся на большинстве рынков, становится очевидным, что нам нужно два измерения, поскольку в противном случае наше объединённое измерение становится громадным и начинает быть похожим на декартово произведение двух первоначальных измерений. Навигация не позволяет найти ничего интересного.
- Если отношение между продуктами и рынками изменяется с течением времени или испытывает влияние со стороны четвёртого измерения, такого как Продвижение, то мы должны признать, что объединённое измерение представляет собой некоторое подобие таблицы фактов!
- Между продуктами и рынками существуют другие отношения помимо розничных продаж. Каждый бизнес-процесс, включающий продукты и рынки будет иметь свою собственную таблицу фактов. Хорошими кандидатами являются Продвижение, Реклама, Дистрибуция и Производство. Создание объединённого измерения Продукт-Рынок исключительно вокруг розничных продаж сделало бы невозможным выражение этих оставшихся процессов.
Смысл этого совета заключается в том, чтобы побудить вас визуализировать отношения между сущностями, которые вы выбираете в качестве измерений. Когда между сущностями существует фиксированная, не зависящая от времени сильно коррелированная связь, их следует моделировать как одно измерение. В большинстве оставшихся случаев ваш дизайн будет проще и компактнее, если вы выделите эти сущности в отдельные измерения.
Не избегайте таблиц фактов! Таблицы фактов исключительно эффективны. Они содержат только ключи измерений и фактические показатели и только те комбинации измерений, которые имеют место в конкретном процессе. Так что, когда вы соберётесь отразить связь между двумя измерениями, помните о том, что таблица фактов была создана в точности для этой цели.
Совет №07. Возвращение вашего хранилища данных назад на рельсы
Весь прошлый год мы постоянно наблюдали за картиной развивающихся хранилищ данных. Несмотря на значительные усилия и финансирования, некоторые хранилища данных сбились с курса. Проектные группы (или их пользователи) не удовлетворены результатами проекта по созданию хранилища данных - данные слишком сбивают с толку, они несогласованны, запросы выполняются слишком медленно и т.д. Разработчики поглотили все бестселлеры и статьи в периодических изданиях по хранилищам данных, но всё ещё не уверены в том, как же выправить ситуацию (исключая побег с корабля и поиски новой работы).
Если это звучит знакомо, выполните следующий тест для определения, не подрывают ли ваше хранилище данных четыре ведущих обвиняемых. Внимательно рассмотрите каждый вопрос, для того чтобы честно покритиковать ситуацию с вашим хранилищем. С точки зрения корректирующих действий мы рекомендуем вам, если возможно, браться за эти фундаментальные дела последовательно.
1. Собрали ли вы заранее требования бизнес-пользователей для каждой итерации хранилища данных и соразмерили внедрение хранилища с их наивысшими приоритетами?
Это - одна из наиболее широко распространённых проблем созревающих хранилищ данных. Где-то в пути, может быть слишком сфокусированном на данных или на технологии, проект потерял из виду истинную цель - служить потребностям бизнес-пользователей.
Как проектная группа вы должны всегда концентрироваться на прибыли пользователей. Если действия проектной группы не приносят выгоды бизнес-пользователям, хранилище данных продолжит свой дрейф. Если вы активно не вовлечены во внедрение решений для поддержки ключевых требований и приоритетов бизнеса, почему бы этому не происходить? Пересмотрите свои планы для определения наиболее критичных потребностей пользователей и концентрации на их решении.
2. Разработали ли Вы матрицу шины хранилища данных (DW Bus Matrix)?
Матрица является одним из наиболее мощных инструментов проектной группы по созданию хранилища данных. Используйте её для внесения ясности в свои мысли, передачи информации и критических моментах соответствия, разработки общей стратегии использования данных, а также для оценки вашего прогресса по сравнению с долгосрочными планами. Если вы не знакомы с Матрицей, обратитесь к статье Ральфа в журнале Intelligent Enterprise от 12/7/99.
3. Согласовано ли с руководством использование стандартных согласованных измерений (conformed dimensions)?
Согласованные измерения абсолютно необходимы для выживания хранилища данных в долгосрочной перспективе. Мы находим, что многие проектные группы неохотно принимают социально-политические проблемы определения согласованных измерений. Откровенно говоря, проектной группе по созданию хранилища данных очень сложно самостоятельно установить и развивать согласованные измерения. Тем не менее, проектная группа не должна игнорировать эту проблему и ждать когда он сама собой решится. Вам понадобится поддержка руководством согласованных измерений для помощи в преодолении организационных трудностей, присущих процессу.
4. Предоставили ли вы пользователям атомарные данные (atomic data) в многомерных моделях?
Часто причиной коррекции курса хранилища данных служат недостатки данных - это или неправильные данные, или неправильно структурированные, или непродуманно агрегированные. Концентрация на требованиях бизнеса поможет определить необходимые данные, следующим шагом необходимо предоставить атомарные данные в многомерном виде. К сожалению, очень трудно элегантно перейти от хаоса в данных к такой нирване. В большинстве случаев наилучшим вариантом будет повторное внедрение. Проектные группы иногда прибегают к менее радикальному на вид подходу использования существующего болота, однако в долгосрочной перспективе затраты неизбежно оказываются более высокими. Часто степень детализации существующих данных препятствует использованию этой альтернативы из-за непродуманного агрегирования.
Подводя итоги, скажем, что если ваше хранилище данных сбилось с курса, оно магически не вернётся назад. Вам нужно будет пересмотреть основные принципы хранилищ данных. Слушайте пользователей, чтобы определить вашу цель, получите карту, проложите маршрут, а затем соблюдайте правила дорожного движения, чтобы поставить ваше хранилище назад на рельсы.
Совет №08. Совершенное разделение истории с помощью медленно изменяющегося измерения типа 2
Подход медленно изменяющегося измерения типа 2 (SCD2) является другим видом разделения. Вы можете назвать это логическим разделением истории. В подходе типа 2 каждый раз, когда нам встречается изменение записи в таблице измерения, мы создаём новую запись и добавляем её в существующую таблицу измерения. Примером такого изменения может быть изменение описания продукта, когда что-то меняется в продукте, например, тип упаковки, а код продукта (например, штрих-код) не изменяется. Как хранители хранилища данных мы дали обет тщательно отслеживать историю, поэтому мы должны следить как за новым описанием продукта, так и за старым.
Тип 2 медленно изменяющегося измерения (SCD) требует специальной обработки ключа измерения, в нашем примере ключа измерения “Продукт”. Мы должны присвоить обобщённый ключ, поскольку мы не можем использовать в качестве ключа складской номер. Это порождает целую дискуссию об анонимных суррогатных ключах (surrogate key), которая интенсивно обсуждалась ранее. Обратитесь к статьям “Суррогатные ключи. Контролируйте идентификаторы строк формированием суррогатных ключей в хранилищах данных” и “Суррогатные ключи. Конвейерная обработка суррогатных ключей”, в которых обсуждаются проблемы суррогатных ключей.
Остановитесь и поразмыслите немного о том, как вы использовали ключ измерения до того момента, когда вы добавляете новую запись в таблицу измерения как это описано выше. До сегодняшнего дня вы использовали “старый” суррогатный ключ, когда бы вы ни создавали новую запись в таблице фактов, описывающую действия с продуктами.
Сегодня происходят две вещи. Во-первых, мы полагаем, что изменения в типе упаковки продукта вступают в действие для новых данных фактической таблицы, которые мы получаем сегодня. Во-вторых, это означает, что после того, как мы создаём новую запись в таблице измерения с новым суррогатным ключом, мы используем этот суррогатный ключ во всех новых сегодняшних записях в таблице фактов.
МЫ НЕ ВОЗВРАЩАЕМСЯ К ПРЕДЫДУЩИМ ЗАПИСЯМ ТАБЛИЦЫ ФАКТОВ, ДЛЯ ТОГО ЧТОБЫ ИЗМЕНИТЬ КЛЮЧ ПРОДУКТА.
Старая запись о продукте в таблице измерения всё ещё корректно указывает на все предыдущие исторические данные, а новая запись о продукте в таблице измерения будет теперь указывать на все записи, начиная с сегодняшнего дня, пока у нас снова не возникнет необходимость внести ещё одно изменение по типу 2.
Вот что мы имеем в виду, когда говорим, что медленно изменяющееся измерение совершенно разделяет историю. Если вы визуализируете это, вы по-настоящему поймёте этот приём проектирования.
Заметьте, что когда вы вводите ограничение на какое-либо поле в измерении, например, на название продукта, которое не затрагивается изменением типа упаковки, вы автоматически выбираете как старые, так и новые записи таблицы измерения, а также вы автоматически присоединяетесь ко всей истории продукта в таблице фактов. И только в случае, когда вы делаете ограничение или группировку по типу упаковки, SQL спокойно делит историю на два режима.
Здесь обсуждается суть подхода типа 2. Подход типа 2 может быть усовершенствован и сделан более мощным путём соответствующего размещения временных отметок в измерении, но эти временные отметки являются дополнительными “удобствами”, которые не требуются для базового деления истории. Обратитесь к статье по адресу http://www.dbmsmag.com/9802d05.html чтобы познакомиться с одним приложением медленно изменяющегося измерения с временными отметками.
Совет №09. Обработка медленно изменяющихся измерений во время начальной загрузки данных: прагматичный компромисс
Совет прошлого месяца ясно определил приём медленно изменяющихся измерений типа 2 и использование суррогатных ключей. В этом месяце мы имеем дело с неприятной проблемой обработки медленно изменяющихся измерений во время начальной загрузки новой предметной области в хранилище. Это происходит, когда вы вводите новый показатель (факт) в существующее хранилище данных. Такие измерения как “Продукт”, “Клиент” и “Время” уже, возможно, определены и имеют богатую историю, отражая многие “медленные изменения”.
Для начала я опишу обычную процедуру ETL (извлечение, преобразование, загрузка), которая должна происходить каждую ночь:
Сначала обрабатываются измерения, любые новые записи из системы-источника вставляются в таблицы измерений, и им присваиваются следующий по порядку суррогатный ключ. Обнаруживаются существующие записи в таблице измерений, изменившиеся с момента последней загрузки хранилища и определяется характер их изменения. На основе того, какие поля изменились, политика поддержки медленно меняющихся измерений повлияет на то, будет ли текущая запись деструктивно обновлена с потерей старых значений (тип 1), или должна быть создана новая запись для того же естественного ключа, и для неё должен быть сгенерирован суррогатный ключ (тип 2).
После этих запутанных сравнений и решений по поводу каждого из измерений наступает время загрузки фактов. Здесь скорость является сутью процесса. Естественные ключи должны быть отброшены и как можно быстрее заменены на правильные суррогатные ключи. В идеале мы хотим воспользоваться преимуществом операций подстановки, выполняемых в памяти, которые предлагает большинство инструментов класса ETL. Небольшие таблицы подстановки для каждого измерения, которые транслируют естественные ключи в суррогатные, строятся из таблиц измерений в СУБД хранилища при помощи операторов, подобных приведённым ниже:
SELECT customer_ID, max(customer_key) from customer
group by customer
или
SELECT customer_id, customer_key from customer
where current=’Y’
После выполнения этих операторов таблицы подстановки будут содержать суррогатные ключи, которые подходят к новым фактам, и будут поддерживать быструю подстановку с помощью алгоритма хеширования.
Однако простого и эффективного метода подстановки будет недостаточно, если мы загружаем в эту первую загрузку большое количество исторических фактов. Например, представьте ситуацию, когда мы выполняем начальную загрузку транзакций за период в два года, и мы “благословлены” иметь двухлетнюю историю изменений записей о клиентах. Эти двое могли никогда раньше не встречаться в одном отчёте, но нам необходимо их точно сопоставить в этой новой витрине данных и совершенным образом разбить историю.
Операция подстановки для измерения должна будет содержать исторические суррогатные ключи для всех изменений деталей о клиенте, произошедших за эти два года. Простая хеш-подстановка, подобная оператору SQL:
select customer_key from customer_lookup CL
where CL.customer_ID=factfile.customer_id
должна быть замена на
select customer_key from customer_lookup CL
where CL.customer_ID=factfile.customer_id and factfile.transaction_date between CL.effective_date and CL.end_date
Логика выборки за определённый временной интервал, которая здесь необходима, замедлит обработку нескольких сотен миллионов строк с фактами с десятью подобными измерениями до скорости передвижения ползком. Вдобавок к этому, у вас теперь в наличие две различных процедуры загрузки таблицы фактов. Если вам и удастся дождаться до конца процедуры начальной загрузки, вам нужно будет выбросить её и построить, отладить и сопровождать более простую версию, которая с этого момента будет инкрементально обновлять таблицу фактов.
Представляя что-то вроде компромисса, ответ на эту задачу обладает умиляющей простотой. Не разрабатывайте сложную пакетную процедуру загрузки, постройте только процедуру инкрементального обновления! Этот метод предоставляет более правдивую версию прошлого, чем простое присоединение всех исторических фактов к текущим записям таблиц измерений, а также даёт клятву впредь медленно изменяться, что часто является стратегией, применяющейся при столкновении с пакетной начальной загрузкой. Вот, что я вам предлагаю делать:
Возьмите ваши данные за два года и разбейте процедуру загрузки на сто четыре задачи, каждая из которых будет загружать транзакции за одну неделю, и запустите эти задачи одну за другой. Начните каждую задачу с загрузки истории изменения измерений, относящуюся только к той неделе, то есть когда effective_date деталей измерения меньше либо равна минимальной дате транзакции. В то время как это означает немного дополнительной логики в шагах обработки измерений, процедуру загрузки фактов можно оставить неизменной. Я могу это делать, поскольку простые таблицы подстановки содержат максимальные значения суррогатных ключей, применимые для загружаемого периода. Вы просто выполнили 104 процедуры инкрементального обновления. Компромисс заключается в том, что некоторые фактические записи будут присоединены к записям таблицы измерений, устаревшим максимум на неделю. В большинстве случаев это приведёт к незначительным ошибкам, поскольку измерения изменяются медленно.
Совет №10. Правильные ли у вас данные?
Общей проблемой загрузки хранилища данных является проверка правильности данных. Является ли хранилище точным образом производственной системы? Прошла ли до конца сегодняшняя утренняя загрузка? Могли ли повредиться некоторые значения?
Не существует единого метода оценки правильности загрузки данных, поскольку источники данных очень разнообразны. Если вы выгружаете неизменённый образ данных из производственной системы, сохраняя первоначальный уровень детализации, то вы, возможно, можете выполнить “отчёт по контрольным суммам” на производственной системе с выводом итоговых данных на текущий момент, а затем повторить тот же самый отчёт на данных хранилища. В этом случае вы “знаете” ответ заранее, и два результата должны сойтись с точностью до последней цифры после запятой.
Но более типичной является ситуация, когда нет известных базовых данных. Может быть, вы каждую ночь получаете данные о розничных продажах из 600 магазинов. Естественно, вы можете выполнить подсчёт общей суммы по отчётам из магазинов, однако, как же оценить то, что данные “наверное, правильные”?
Давайте, используя пример с 600 магазинами, посмотрим на суммарные данные по продажам каждого отдела каждого магазина за каждое утро, и зададимся вопросом, являются ли цифры, полученные сегодня утром “разумными”. Мы примем решение о том, то сегодняшние данные об общей сумме продаж являются разумными, если они попадают в пределы трёх стандартных отклонений от средних суммарных продаж за предыдущие периоды того же самого отдела в том же магазине. Уф. Статистика. Но, подождите: всё не так уж плохо. Мы выбираем три стандартных отклонения, поскольку в случае “нормального” распределения 99% значений лежат в пределах 3 стандартных отклонений выше или ниже среднего значения.
Я опишу процесс словами. После этого я приведу несколько операторов SQL. Если вы хотите уловить основной смысл, прочитайте только описание.
Для того чтобы сделать так, чтобы процесс выполнялся быстро, необходимо избежать просмотра полной истории старых данных при подсчёте стандартного отклонения. Вы можете избежать просмотра всей истории, если будете накапливать данные по каждому отделу каждого магазина в специальной таблице, которая будут использоваться только на этапе проверки правильности данных. Вам нужно хранить количество дней, за которое собираются данные, объём продаж на каждый день (для каждого отдела каждого магазина) и сумму КОРНЯ КВАДРАТНОГО объёма продаж на каждый день (для каждого отдела каждого магазина). Это всё можно было бы хранить в отдельной маленькой таблице. Степень детализации этой таблицы - отдел магазина, а три числовых поля КОЛИЧЕСТВО ДНЕЙ, ОБЪЁМ ПРОДАЖ и КОРЕНЬ КВАДРАТНЫЙ ОБЪЁМА ПРОДАЖ являются атрибутами типа 1, которые каждый день обновляются путём полной перезаписи содержимого. Вы можете обновить все три поля, просто прибавив значения за следующий день к уже имеющимся значениям. Таким образом, если у вас 600 магазинов и по 20 отделов в каждом из них, в этой таблице будет 12000 строк, и она не будет расти со временем. В каждой строке таблицы также хранятся названия магазинов и названия отделов.
Теперь, используя эту аккумулирующую таблицу отделов, вы смотрите на 12000 итоговых сумм по отделам, которые вы загрузили сегодня утром, и выбрасываете из них те, которые лежат за пределами трёх стандартных отклонений от средней величины.
Вы можете принять решение проанализировать отдельные необычные величины, если их не очень много, или можете отвергнуть все загруженные данные, если увидите, что количество величин, отклонившихся от среднего значения объёма продаж более чем на три стандартных отклонения, превышает определённый порог.
Если данные, загруженные сегодняшним утром, прошли проверку, то вы даёте к ним доступ вашим конечным пользователям, а затем обновляете аккумулирующую таблицу отделов чтобы приготовиться к завтрашней загрузке.
Вот фрагменты не протестированных операторов SQL, которые могут сработать. Помните, что стандартное отклонение равно корню квадратному из дисперсии. Дисперсия же равна сумме квадратов разности между каждым значением выборки и средним значением всей выборки, делённой на N-1, где N - количество дней, за которые мы собрали данные. К сожалению, эта формулировка заставляет нас обратиться ко всей истории продаж, что, хотя и возможно, делает вычисления непривлекательными. Но, если же мы отслеживаем значения СУММА ОБЪЁМА ПРОДАЖ и СУММА КОРНЯ КВАДРАТНОГО ОБЪЁМА ПРОДАЖ, мы можем записать дисперсию как (1/(N-1))*(SUM_SQUARE_SALES -(1/N)*SUM_SALES*SUM_SALES). Проверьте мои выкладки.
Итак, если мы обозначим нашу формулу для вычисления дисперсии как VAR, то наша проверка правильности будет выглядеть следующим образом:
SELECT s.storename, p.departmentname, sum(f.sales)
FROM fact f, store s, product p, time t, accumulatingdept a
WHERE
(сначала соединяем таблицы…)
f.storekey =s.storekey and
f.productkey =p.productkey and
f.timekey =t.timekey and
s.storename =a.storename and
p.departmentname =a.departmentname and
(затем ограничиваем время сегодняшним днём для того, чтобы получить только что загруженные данные…)
t.full_date =#July 13,2000#and
(наконец, вводим ограничение на стандартное отклонение…)
HAVING
ABS(sum(f.sales)-(1/a.N)*a.SUM_SALES)>3*SQRT(a.VAR)
где мы раскрываем формулу для вычисления значения VAR до выражения, приведённого в предыдущем объяснении, и используем префикс “a.” перед N, SUM_SALES и SUM_SQUARE_SALES. Мы предположили, что отделы представляют группы продуктов и, следовательно, доступны как свёртки вдоль измерения “Продукт”.
Украшением для этой схемы могло бы послужить выполнение двух запросов: один для вычисления объёмов продаж, ПРЕВЫШАЮЩИХ средний объём более чем на три стандартных отклонения, и второй - для вычисления значений, которые МЕНЬШЕ чем средний объём более чем на три стандартных отклонения. Может быть, для этих двух ситуаций существуют разные объяснения. Это также поможет избавиться от функции ABS, если ваш диалект SQL не поддерживает её в предложении HAVING.
Если у вас обычно день ото дня наблюдаются значительные флуктуации объёма продаж (например, понедельник и вторник - очень медленные в сравнении с субботой), вы можете добавить значение ДЕНЬ_НЕДЕЛИ к аккумулирующей таблице отделов и ввести ограничение на день. Таким образом, вы не примешиваете обычные дневные флуктуации к нашему тесту стандартного отклонения.
Совет №11. Точный подсчёт количества элементов измерения
Любая таблица измерения с богатым набором описательных атрибутов часто становится непосредственным объектом запросов, независимо от таблиц фактов. Например, мы ежедневно выполняем различные запросы к таблице Клиент для ответов на вопросы, сколько у нас клиентов по типу платежа, региону, полу, тарифному плану. Простой подсчёт записей в статическом измерении достаточно очевиден, однако наша жизнь становится значительно интереснее, когда мы пытаемся выполнить тот же самый подсчёт, но уже в медленно изменяющемся измерении.
Подсчёт элементов медленно изменяющегося измерения
Проблема состоит в том, чтобы не насчитать больше, чем есть. В таблице медленно изменяющегося измерения “Клиент” у нас будет несколько записей для каждого клиента, поэтому простой запрос на подсчёт количества клиентов в определённом регионе возвратит завышенное количество для всех клиентов, данные о которых изменялись (и, соответственно, имеется несколько записей). Кто-то, возможно, склонится к тому, чтобы выполнить подсчёт путём операции COUNT DISTINCT над ключами, уникально идентифицирующими клиентов в оперативной системе, если они доступны. Здесь проблема заключается в том, что если атрибут, по которому вы проводите подсчёт уникальных значений, изменился, как в случае изменения статуса клиента, вы всё же рискуете сделать ошибку, поскольку ключ клиента может быть уникальным в пределах штата. Нам нужен способ ограничения медленно изменяющегося измерения до одной записи на каждого клиента. Мы можем это сделать, если наиболее свежая запись для каждого клиента в таблице измерения будет содержать признак “текущая запись”. Это позволит нам выполнять подсчёт наиболее актуальных состояний клиентов. Вы даже можете создать отдельную таблицу, представление или предопределённый запрос, который будет возвращать записи о клиентах, имеющие только статус “текущая запись”, что позволит их корректно подсчитывать.
Подсчёт за промежутки времени
Подсчёт текущего количества элементов измерения очень полезен, однако реальную сноровку нужно демонстрировать при подсчёте на определённую дату из всей истории. Понимание того, как величины изменяются со временем, является одной из задач хранилища данных. Знание того, что на данный момент у нас 2311 клиентов полезно, а возможность сравнить эту величину с количеством клиентов год назад - ещё полезнее. Чтобы проводить исторические подсчёты подобного рода, вам понадобится медленно изменяющееся измерение. Например, чтобы подсчитать количество клиентов на конец 1999 года вы могли бы воспользоваться фильтром Row_Begin_Date<=’12/31/1999′ AND Row_End_Date>=’12/31/1999′ (выбор операций сравнения зависит от того, как вы установили ваши даты начала и окончания). В этом примере мы предположили, что когда в таблице измерения изменяется запись о клиенте, значение поля row_end_date первой записи на один день меньше значения поля row_begin_date второй записи, а наличия нескольких изменений в день не допускаются.
Если вы, действительно, хотите проявить воображение, то вместо прямого ограничения полей таблицы измерения “Клиент”, вы можете использовать всю мощь таблицы измерения “Период” для предоставления требуемой даты или даже нескольких дат. Используйте для этого те же самые операции сравнения для того, чтобы создать два соединения по неравенству с использованием поля Date вашей таблицы Period и полями Row_Begin_Date и Row_End_Date вашей таблицы измерения “Клиент”. Затем введите ограничение на значение поля Date таблицы Period, чтобы оно было равно требуемой дате. При этом вы сможете включить поле Date в результат выборки, чтобы увидеть, к какой дате относится искомое количество клиентов. Для того чтобы одним запросом посчитать количество для более, чем одной даты, например, для последнего дня каждого года, уберите ограничение на поле Date таблицы Period, и добавьте ограничение Month_End_Flag=’y’. Оператор SQL выглядел бы следующим образом:
SELECT Period.Date, Customer.State, COUNT(Customer.Customer_Key)
FROM Customer, Period
WHERE Customer.Row_Begin_Date <=Period.Date
AND Customer.Row_End_Date >=Period.Date
AND Period.Month_End_Flag =’y’
Заметьте, что такой тип соединения по неравенству между таблицей Period и таблицей измерения может представлять трудности для ядра СУБД при больших размерах измерений. В нашем случае, мы построили битовые индексы (bitmapped indexes) по обоим полям с датами и получили неплохую производительность.
Ясно, что запросы такого рода не так тривиально построить, и мы бы посоветовали вам оградить ваших пользователей от подобной гимнастики с запросами. На самом деле, если запросы на подсчёт количества значений определённых атрибутов является нормальной практикой, может иметь смысл построение суммарной таблицы фактов, хранящей значение количества для любой существующей комбинации атрибутов за любой день. Тогда мы опять возвращаемся к простой многомерной модели, в которой каждый атрибут является измерением, а таблица фактов имеет, по крайней мере, одно поле, хранящее значение количества клиентов, сгруппированное по комбинациям значений атрибутов и по дням.
Совет №12. Точный подсчёт с многомерным дополнением
В предыдущем совете мы вели речь о выполнении точного подсчёта количества элементов измерения (dimension). Мы можем даже прибавить ценность к этим процедурам подсчёта, если добавим отдельную таблицу с дополнительными атрибутами, которая пересекается с таблицей измерения.
Недавно мы загрузили простой пример такой дополнительной таблицы, которая отображает почтовые индексы на Маркетинговые Регионы (Media Market Area). Нашим ребятам из Управления Маркетинга было интересно посмотреть, каково распределение доли наших клиентов по маркетинговым регионам в сравнении со всем остальным населением.
Другими словами, мы хотим знать, в каких регионах наши позиции сильны, а в каких - не очень. Если эти дополнительные данные окажутся ценными для организации, мы продолжим их использование и добавим их в качестве дополнительных атрибутов к измерению “Клиент”. Но для начала мы хотим выполнить несколько запросов, чтобы убедиться в том, что эти затраты оправдаются.
Чтобы выполнить эти запросы, мы соединяем дополнительную таблицу с таблицей, хранящей информацию о клиентах, и выполняем подсчёт клиентов для каждого маркетингового региона. Однако мы должны быть внимательными, поскольку эти два набора данных не пересекаются на 100%. В таблице маркетинговых регионов есть почтовые индексы, для которых нет соответствующих записей о клиентах, и есть записи о клиентах, которым не соответствует ни один почтовый индекс маркетинговых кодов. Внутреннее соединение приведёт к тому, что мы недосчитаемся записей из обеих таблиц. Для иллюстрации этого можно использовать следующие две таблицы:
Media Market Area |
Current Customer |
|||
Zip |
MMA |
Customer Key |
Zip |
|
94025 |
SF-Oak-SJ |
27 |
94303 |
|
94303 |
SF-Oak-SJ |
33 |
94025 |
|
97112 |
Humboldt |
47 |
24116 |
|
98043 |
Humboldt |
53 |
97112 |
|
00142 |
Gloucester |
55 |
94025 |
Если мы хотим увидеть, сколько клиентов у нас в каждом маркетинговом регионе, внутреннее соединение даст нам следующий результат:
MMA |
Count(Customer_Key) |
Humboldt |
1 |
SF-Oak-SJ |
3 |
Внутреннее соединение является соединением “по равенству”. Поскольку для почтового индекса 24166 нет эквивалентного маркетингового региона, запрос недосчитывает наших подписчиков, возвращая четырёх клиентов, вместо пяти. Мы также теряем информацию с другой стороны соединения, поскольку в результате запроса отсутствуют данные о регионах, в которых у нас нет клиентов (например, Gloucester). Переписав запрос с использованием полного внешнего соединения, мы получим следующий результат:
MMA |
Count(Customer_Key) |
NULL |
1 |
Gloucester |
0 |
Humboldt |
1 |
SF-Oak-SJ |
3 |
Теперь мы посчитали всех пятерых клиентов и увидели, что в регионе Gloucester они отсутствуют. Мы могли бы использовать функцию IFNULL для замены значения NULL на более дружественные значения, например, “неизвестный регион”. Заметьте, то, что вы считаете, сильно влияет на результаты. В нашем случае мы считали значения столбца Customer_Key. Если бы мы заменили это на count(*), мы могли бы в результате получить 7, поскольку * означает подсчёт всех строк, а полный результат состоит из семи строк. Если бы мы стали считать количество значений столбца MMA_to_Zipcode.Zip_Code, мы насчитали бы 6 значений, поскольку значение 94025 встречается два раза.
При использовании внешних соединений надо проявлять осторожность, можно легко разрушить логику, введя ограничение на одну из участвующих в соединении таблиц. Ограничение вида Customer_Age<25 привело бы к отчёту с абсолютно идентичной структурой и заголовками, но с меньшим количеством клиентов. Отчёт будет сбивать с толку, если явно не проставить названия.
Мы обнаружили, что комбинирование выражения CASE с функцией SUM является отличной хитростью, позволяющей выполнять в один проход подсчёт строк различных подмножеств полных результирующих наборов данных с обеих сторон полного внешнего соединения. Используя те же самые данные, что и в примерах выше, мы могли бы создать запрос, который возвратит нам полное количество записей для всех трёх областей набора данных. В операторе SELECT вы бы написали:
Sum(case when Media_Market_Area.Zip IS NULL then 1 else 0 end) AS Customer_Count_with_No_MMA,
Sum(case when count(customer_key)=0 then 1 else 0 end) as MMA_Count_with_No_Customers,
Sum(case when not(Media_Market_Area.Zip IS NULL or count(customer_key)=0) then 1 else 0 end as Count_MMAs_with_Customers)
Это даёт вам три столбца: количество клиентов, для которых отсутствуют маркетинговые регионы, количество маркетинговых регионов, в которых у нас нет клиентов, а также сумму для имеющихся совпадений. В сущности, ограничения встроены внутрь выражений CASE, поэтому они не ограничивают результатов внешнего соединения.
Совет №13. Использование таблицы фактов в качестве таблицы измерения
Существует три различных типа таблиц фактов. Степень детализации таблицы фактов может быть на уровне отдельной транзакции, где запись таблицы фактов описывает определённый момент времени. Степень детализации может также быть на уровне периодического снимка данных, представляющего промежуток времени заранее известной продолжительности, например, неделя или месяц. Или, наконец, степень детализации может быть на уровне аккумулирующего снимка, представляющего всю историю чего-либо вплоть до сегодняшнего дня. Я подробно обсудил эти три типа в статье, опубликованной в журнале IE, которую вы можете найти здесь (к сожалению, ссылка перестала рабоать - прим. пер.).
Первый тип таблицы фактов, мгновенная транзакция, может предоставить нам возможность зарегистрировать описание чего-нибудь в определённый момент времени. Предположим, у нас есть серия транзакций по клиентской информации в вашем банковском счёте. Другими словами, сотрудник банка периодически выполняет изменения информации о вашем имени, адресе, номере телефона, классификации клиента, кредитном рейтинге, риск-рейтинге и других описательных параметров. Таблица фактов с детализацией на уровне транзакции, которая регистрирует эти транзакции, могла бы выглядеть следующим образом:
Cust Info Transaction Date (FK) |
внешний ключ |
Account (SK) |
суррогатный ключ |
Responsible Agent (FK) |
внешний ключ |
Cust Info Transaction Type (FK) |
внешний ключ |
Account Number |
“ключ” в банковской системе |
Name |
текстовые факты |
Address (несколько полей) |
текстовые факты |
Phone Number |
текстовые факты |
Customer Classification |
текстовые факты |
Credit Rating |
неаддитивный числовой факт |
Risk Rating |
неаддитивный числовой факт |
…другие атрибуты клиента |
Это - типичный дизайн таблицы фактов, в которой “показатели”, регистрируемые транзакциями с информацией о клиентах, являются изменениями, происходящими с текстовыми значениями, такими как имя, адрес и другими текстовыми полями, перечисленными выше. Такая таблица фактов стирает различия между таблицей фактов и таблицей измерения, поскольку эта таблица фактов наполняется дискретными текстовыми значениями и неаддитивными числовыми величинами, которые нельзя суммировать, но можно использовать для наложения фильтров в запросах пользователей.
Три из четырёх ключевых полей этой таблицы фактов являются простыми внешними ключами, соединяющимися с обычными таблицами измерений. Они включают дату транзакции, ответственного сотрудника, и название самой транзакции. Номер счёта из банковской системы не используется для соединения с другими таблицами, а является идентификатором данного счёта клиента банка.
Остался только суррогатный ключ счёта. Другими словами, это просто последовательно возрастающее число, уникально определяющее транзакции, выполняющиеся над этим счётом. НО, есть одна тонкая деталь, которая является секретом всего этого дизайна. Этот суррогатный ключ счёта, соответственно, уникально представляет этот снимок информации о счёте на момент транзакции с информацией о клиенте, а также продолжает точно описывать счёт до тех пор пока в некоторый произвольный момент времени в будущем не произойдёт следующая транзакция с информацией о клиенте.
Таким образом, чтобы укоротить всю эту историю, мы можем использовать суррогатный ключ счёта так, как будто это ключ типичного медленно изменяющегося измерения типа 2, и мы можем помещать этот ключ в любую ДРУГУЮ таблицу фактов, описывающую поведение счёта. Например, представим, что мы также собираем информацию об обычных транзакциях со счетами, таких как депозиты и снятие наличных. Будем называть их “балансовыми транзакциями” чтобы отличать их от транзакций с информацией о клиентах. Таблица фактов балансовых транзакций будет выглядеть следующим образом:
Balance Transaction Date (FK) |
внешний ключ |
Balance Transaction Time of Day (FK) |
внешний ключ |
Account (SK) |
суррогатный ключ |
Location (FK) |
внешний ключ |
Balance Transaction Type (FK) |
внешний ключ |
amount |
аддитивный факт |
instant balance |
полуаддитивный факт |
Когда мы строим записи для этой таблицы фактов балансовых транзакций, мы внимательно изучаем нашу таблицу фактов транзакций с информацией о клиентах и выбираем соответствующий суррогатный ключ. Обычно, когда мы обрабатываем сегодняшние записи, мы используем наиболее свежий суррогатный ключ для данного счёта. В таком случае этот дизайн отлично соединяет каждую балансовую транзакцию с соответствующим профилем счёта, описанным в нашей первой таблице фактов. Или, может быть, это - таблица измерения???
Надеюсь, это заставило вас подумать. Я написал статью в журнал DBMS о базах данных для подразделений по работе с персоналом, при проектировании которых используются подобные приёмы. Вы можете найти эту статью по адресу http://dbmsmag.com/9802d05.html. Обратитесь также к разделу “Time Stamping Changes in a Large Dimension” в книге The Data Warehouse Lifecycle Toolkit, страница 233. Присылайте свои вопросы и комментарии, и я посвящу следующий выпуск ответам на них.
Совет №14. Отчётность по балансам на произвольные даты по транзакционной таблице фактов
Совет №13 показал, как присоединить таблицу медленно изменяющегося измерения (таблица банковских счетов) к быстро изменяющейся транзакционной таблице (транзакции по счетам). Мы увидели, что медленно изменяющееся измерение само по себе очень похоже на таблицу фактов, поскольку описывает транзакции, изменяющие профиль счетов.
В этом выпуске советов мы переключим наше внимание на большую таблицу фактов, хранящую записи обо всех транзакциях по банковским счетам. Давайте в целях обсуждения сведём эту таблицу фактов до действительно простой конструкции:
Date Key (FK)
Account Key (FK)
Transaction Type Key (FK)
Transaction Sequence Number
Final Flag
Amount
Balance
Вот, что содержат поля:
Date Key |
суррогатный ключ, указывающий на измерение время с детализацией на уровне дня; |
Account Key |
суррогатный ключ, указывающий на таблицу с данными о счетах; |
Transaction Type Key |
суррогатный ключ, указывающий на маленькую таблицу, хранящую допустимые типы транзакций; |
Transaction Sequence Number |
постоянно возрастающая последовательность чисел, существующая на протяжении существования счёта; |
Final Flag |
TRUE, если это - последняя транзакция на данный день, FALSE в противном случае; |
Amount |
сумма транзакции; |
Balance |
результирующий баланс счёта после окончания транзакции. |
Как и в случае с любой транзакционной таблицей фактов, эта таблица содержит запись только в случае, если была выполнена транзакция. Если счёт был нетронутым в течение двух недель, скажем с 1 по 14 октября, для этого счёта в этот промежуток времени будет НОЛЬ записей в таблице фактов. Но предположим, мы хотим знать все балансы счетов на 5 октября.
В этом случае нам нужно искать наиболее свежую предыдущую запись в таблице фактов для каждого счёта на требуемую дату или раньше.
Вот протестированный оператор SQL, который выполняет этот трюк:
SELECT a.acctnum,f.balance
FROM fact f,account a
WHERE f.account_key =a.account_key
AND f..nal_.ag ='True '
AND f.date_key =
(SELECT MAX(g.date_key)
FROM fact g
WHERE g.account_key =f.account_key
AND g.date_key IN
(SELECT t.date_key
FROM time t
WHERE t.fulldate <='October 5,2000 '))
После изучения этого оператора SQL у вас, вероятно, возникнет несколько вопросов!
Вопрос 1. РАЛЬФ, как Вы можете использовать суррогатный ключ измерения время в качестве основы для ограничения??? Вся идея суррогатных ключей заключается в отсутствии в них семантики.
Ответ 1. Да, за исключением суррогатных ключей измерения “время”, представляющих набор целых чисел от 1 до N. По совершенно другой причине мы уже ввели предсказуемый порядок в суррогатные ключи времени. Нам нужна упорядоченность суррогатных ключей времени для того, чтобы можно было осуществить физическое секционирование этой большой таблицы фактов на основе этого ключа. Это замечательным образом разбивает таблицу на сегменты, так что у нас появляется возможность выполнения дискретных административных действий над определёнными диапазонами времени, например перемещение на устройства резервного копирования, или удаление и повторное создание индексов. Это измерение “время” является ЕДИНСТВЕННЫМ измерением, в суррогатных ключах которого присутствует логика, и на которые мы осмеливаемся накладывать ограничения. Мы используем этот порядок в приведённом выше фрагменте SQL, когда ищем наиболее близкую к концу дня транзакцию.
Вопрос 2. Зачем нужно было ввергать себя в проблемы, связываясь с таблицей времени, когда можно было наложить ограничения на обычную временную отметку в таблице фактов?
Ответ 2. Введение временной отметки вместо суррогатного ключа приводит к ряду проблем, которые мы решили с помощью суррогатных ключей. А именно: пустые даты, неприменимые даты, и даты вида “ещё не произошло”. Все эти вопросы мы уже обсуждали в других местах. Однако более важно, что обнажённая дата в таблице фактов не позволяет накладывать реалистичные сложные ограничения. Что если вместо 5 октября нам нужно было посчитать балансы на “3 квартал федеральной резервной отчётной даты”, чем бы она ни являлась? В этом случае SQL-запрос, приведённый выше, практически не претерпевает изменений. Просто замените последнюю строку соответствующим ограничением на таблицу измерения “время” для получения даты этого календарного события.
Вопрос 3. Не является ли эта конструкция очень чувствительной к вставке транзакций в таблицу фактов “задним числом”?
Ответ 3. Хороший вопрос. Эта таблица фактов должна быть ПОЛНОЙ и ТОЧНОЙ. Каждая транзакция по счёту должна присутствовать в ней, иначе будет невозможно посчитать нарастающий баланс. Естественно, опоздавшие записи о транзакциях потребовали бы очистки с точки вставки для данного счёта и изменения всех балансов и всех номеров транзакций. Заметьте, что в нашей дискуссии мы явно не использовали номер транзакции, хотя что-то необходимо предусмотреть в этом дизайне для того, чтобы надёжно воспроизвести реальную последовательность транзакций и иметь основу для ключа таблицы фактов (account_key + date_key + sequence_number). Мне нравится последовательный номер, а не время суток, поскольку разность между последовательными номерами является корректным показателем активности счёта.
Совет №15. Комбинирование приёмов обработки медленно изменяющихся измерений
Аббревиатура SCD является ключевой в профессиональном жаргоне разработчика многомерных моделей. Многие из вас уже знают, что она означает slowly changing dimension (медленно изменяющееся измерение). Существует несколько хорошо описанных приёмов обработки атрибутов медленно изменяющихся измерений. Говоря коротко, при использовании приёма SCD1 значение атрибута заменяется на новое, уничтожая исторические значения атрибута. Например, когда изменяется упаковка определённого продукта, значение атрибута “упаковка” заменяется новым значением. Применение типа 2 предполагает вставку в таблицу измерения новой записи с новыми значениями атрибутов. Исторические записи таблицы фактов продолжают ссылаться на записи со старым ключом измерения и данными о старой упаковке, начиная с определённого момента, строки таблицы фактов будут ссылаться на записи с новым ключом и данными о новой упаковке, таким образом, идеально разделяя историю. Наконец, использование типа 3 предполагает, что к записи таблицы измерения добавляются новые атрибуты для поддержки одновременного хранения данных о двух типах упаковки - может быть, данных о текущей упаковке и о предыдущей или о текущей и самой первой.
Мой опыт свидетельствует о том, разработчиков хранилищ данных очень часто просят сохранить исторические атрибуты, при этом, оставляя возможность выполнять отчёты по историческим данным в разрезе текущих значений атрибутов. Ни один из стандартных приёмов SCD не позволяет достичь этого независимо. Однако, объединяя приёмы, вы можете элегантно предоставить эту возможность в ваших многомерных моделях.
Мы начнём с использования рабочей лошадки SCD, типа 2, для захвата изменений значений атрибутов. Когда изменится тип упаковки продукта, мы добавим в таблицу измерения новую запись с новым суррогатным ключом. Затем украсим таблицу измерения дополнительными атрибутами для отражения текущего типа упаковки. В наиболее свежей записи таблицы измерения для данного продукта значение атрибута “текущая упаковка” будет идентичным значению исторически точному атрибуту “как было”. Во всех предыдущих строках таблицы измерения значение атрибута “текущая упаковка” для данного продукта будет заменено на новое для отражения текущего состояния мира. Если мы желаем посмотреть на исторические факты с точки зрения текущей структуры упаковки, мы наложим фильтры или произведём группировку на основе текущих атрибутов. Если мы наложим фильтры или произведём группировку на основе атрибутов “как было”, мы увидим факты с точки зрения того, какова была упаковка в тот момент времени.
Мы описали гибридный приём, который комбинирует три фундаментальных приёма обработки медленно изменяющихся измерений. Мы создаём новые строки для захвата изменений (тип 2), добавляем атрибуты для отражения альтернативного взгляда на мир (тип 3), которые переписываются для всех предыдущих строк измерения для данного продукта (тип 1). Как недавно предложил один студент, может быть нам нужно назвать это типом 6 (2+3+1)
Совет №16. Измерения с горячей заменой
Критерий №18 списка критериев Dimensionally Friendly даёт определение “измерения с горячей заменой” - измерения, имеющего две или более альтернативных версий. Если измерение является измерением с горячей заменой, для выполнения запроса можно выбрать любую альтернативную версию измерения.
Существует ряд ситуаций, когда альтернативные версии измерений могут оказаться очень полезными. Вот три интересные ситуации:
1) Инвестиционный банк предоставляет доступ своим клиентам к большой таблице фактов, которая ежедневно в течение нескольких лет отслеживает акции и облигации. Измерение “инвестиция” в этой таблице фактов предоставляет информацию о каждой акции и облигации. Но это измерение “инвестиция” настраивается персонально для каждого клиента, получающего доступ к таблице фактов. Таким образом, каждый клиент имеет возможность описывать и группировать инвестиции интересными персональными способами. Различные версии измерения могут полностью отличаться друг от друга, что может заключаться в несовместимых названиях атрибутов и в наличии различных иерархических схем. Все клиенты используют одну и ту же таблицу фактов (поэтому её нужно хранить всего в одном месте), но каждый клиент использует свою таблицу измерения “инвестиция” в качестве основы для анализа колебаний котировок акций и облигаций. С точки зрения сервера баз данных, клиенты постоянно выполняют горячую замену измерения “инвестиция” с каждым очередным запросом.
2) Розничный банк создаёт одну большую таблицу фактов, которая хранит остатки по счетам на конец месяца банковских счетов всех типов, включая расчётные, сберегательные, пластиковые, заёмные, депозитные сертификаты и другие. Это классический пример “гетерогенных продуктов”, поскольку детальные описания этих типов счетов ужасно отличаются друг от друга. Нее существует единого шаблона описания, который смог бы помочь управлять сложностями всех этих типов счетов. Поэтому мы строим упрощённое измерение “счёт”, которое бы однообразно подходить ко всем счетам. Мы используем это измерение, когда занимаемся анализом перекрёстных продаж и оцениваем общий портфель клиента. Но когда мы заостряем своё внимание на определённом типе счетов (например, на закладных), мы переключаемся на значительно более широкое (больше полей) измерение, которое содержит атрибуты, касающиеся исключительно закладных. Мы можем это делать, когда мы уверены в том, что сузили область анализа до одного типа счетов. Если у наc 0 продуктовых линеек, то у нас 21 измерение “счёт”: одно упрощённое измерение, описывающее все счета, и 20 расширенных измерений, каждое из которых описывает совокупность похожих счетов.
3) Производственная компания желает предоставить доступ к таблице фактов, описывающей отгрузки, своим торговым партнёрам, но нуждается в разграничении доступа к информации о заказах партнёров между ними. В данном случае каждый партнёр получает свою версию измерения “партнёр” только с названием своей компании. Все остальные партнёры как “ДРУГОЙ”. В дополнение к этому обязательное поле с весовым коэффициентом в таблице измерения устанавливается в 1 для данного партнёра и в 0 - для остальных. Этот весовой коэффициент умножается на все факты в таблице фактов. Таким образом, одна таблица фактов отгрузок может безопасно использоваться для поддержки конкурирующих торговых партнёров.
Горячая замена измерений прямолинейна в стандартных реляционных базах данных, поскольку соединения между таблицами можно задавать во время запроса. Однако если требуется контролировать ссылочную целостность между таблицами измерений и таблицей фактов, то каждая из таблиц измерений должна содержать полный набор ключей, а, следовательно, и полный набор записей. В этом случае, если таблица измерения с горячей заменой используется для разграничения доступа (как в примерах 2 и 3), то записи, доступ к которым должен быть ограничен, должны содержать фиктивные или пустые значения.
Совет №17. Наполняем вспомогательные таблицы иерархий
Совет этого месяца является продолжением статьи Ральфа, опубликованной в сентябре 1988 года под названием Help for Hierarchies, которая посвящена иерархическим структурам переменной глубины, которые наиболее часто представляются в реляционных базах данных рекурсивными отношениями, известными иногда под названиями “свиные уши” или “рыболовные крючки”.
Ниже следует определение измерения “компания”, которое содержит рекурсивное отношение между внешним ключом PARENT_KEY и первичным ключом COMPANY_KEY
Create table COMPANY (
COMPANY_KEY INTEGER NOT NULL,
COMPANY_NAME VARCHAR2(50),
PARENT_KEY INTEGER);
В то время как эта структура является эффективной для хранения информации об организационных структурах, по ней невозможно осуществлять навигацию или агрегировать факты вдоль этих иерархий с помощью непроцедурных операторов SQL, которые способны генерировать коммерческие генераторы запросов. Статья Ральфа описывает вспомогательную таблицу, похожую на приведённую ниже, которая содержит одну запись для каждой отдельной связи, исходящей из каждой компании в организационном дереве к себе или к любой подчинённой структуре, что решает проблему.
Create table COMPANY_STRUCTURE (
PARENT_KEY INTEGER NOT NULL,
SUBSIDIARY_KEY INTEGER NOT NULL,
SUBSIDIARY_LEVEL INTEGER NOT NULL,
SEQUENCE_NUMBER INTEGER NOT NULL,
LOWEST_FLAG CHAR(1),
LOWEST_FLAG CHAR(1),
HIGHEST_FLAG VARCHAR2(50),
SUBSIDIARY_COMPANY VARCHAR2(50));
Последние два столбца в этом примере, которые денормализуют названия компаний в эту таблицу, строго говоря, не являются необходимыми, однако добавлены с тем, чтобы облегчить понимание того, что будет происходить дальше. Следующая хранимая процедура на PL/SQL демонстрирует возможный способ наполнения этой таблицы “иерархического взрыва” из таблицы COMPANY, хранящейся в СУБД Oracle:
CREATE or Replace procedure COMPANY_EXPLOSION_SP as
CURSOR Get_Roots is
select COMPANY_KEY ROOT_KEY,
decode(PARENT_KEY,NULL,'Y ','N ')HIGHEST_FLAG,
COMPANY_NAME ROOT_COMPANY
from COMPANY;
BEGIN
For Roots in Get_Roots
LOOP
insert into COMPANY_STRUCTURE
(PARENT_KEY,
SUBSIDIARY_KEY,
SUBSIDIARY_LEVEL,
SEQUENCE_NUMBER,
LOWEST_FLAG,
HIGHEST_FLAG,
PARENT_COMPANY,
SUBSIDIARY_COMPANY)
select
roots.ROOT_KEY,
COMPANY_KEY,
LEVEL -1,
ROWNUM,
'N ',
roots.HIGHEST_FLAG,
roots.ROOT_COMPANY,
COMPANY_NAME
from COMPANY
Start with COMPANY_KEY =roots.ROOT_KEY
connect by prior COMPANY_KEY =PARENT_KEY;
END LOOP;
update COMPANY_STRUCTURE
SET LOWEST_FLAG ='Y '
where not exists (select *from COMPANY
where PARENT_KEY =COMPANY_STRUCTURE.SUBSIDIARY_KEY);
COMMIT;
END;/*of procedure */
Это решение использует преимущество расширения CONNECT BY СУБД Oracle для прохода по каждому из деревьев в данных. В то время как конструкция CONNECT BY очень полезна в этой процедуре, она не может быть использована инструментом генерации запросов. Если инструмент был бы способен сгенерировать такой оператор для исследования рекурсивных отношений, он не сможет в том же самом операторе выполнить соединение с таблицей фактов. Если бы даже Oracle снял это немного деспотичное ограничение, производительность при выполнении запроса была бы далеко не самой хорошей.
Следующие данные о фиктивной компании помогут вам понять таблицу COMPANY_STRUCTURE и процедуру COMPANY_EXPLOSION_SP:
/*column order is Company_key,Company_name,Parent_key */
insert into company values (100,'Microsoft ',NULL);
insert into company values (101,'Software ',100);
insert into company values (102,'Consulting ',101);
insert into company values (103,'Products ',101);
insert into company values (104,'Of .ce ',103);
insert into company values (105,'Visio ',104);
insert into company values (106,'Visio Europe ',105);
insert into company values (107,'Back Of .ce ',103);
insert into company values (108,'SQL Server ',107);
insert into company values (109,'OLAP Services ',108);
insert into company values (110,'DTS ',108);
insert into company values (111,'Repository ',108);
insert into company values (112,'Developer Tools ',103);
insert into company values (113,'Windows ',103);
insert into company values (114,'Entertainment ',103);
insert into company values (115,'Games ',114);
insert into company values (116,'Multimedia ',114);
insert into company values (117,'Education ',101);
insert into company values (118,'Online Services ',100);
insert into company values (119,'WebTV ',118);
insert into company values (120,'MSN ',118);
insert into company values (121,'MSN.co.uk ',120);
insert into company values (122,'Hotmail.com ',120);
insert into company values (123,'MSNBC ',120);
insert into company values (124,'MSNBC Online ',123);
insert into company values (125,'Expedia ',120);
insert into company values (126,'Expedia.co.uk ',125);
/*End example data */
Процедура возьмёт 27 записей из таблицы COMPANY и создаст 110 записей в таблице COMPANY_STRUCTURE, представляющих одно большое дерево (Microsoft) с 27 узлами и 26 более мелкими деревьями. Вы можете обнаружить, что в случае больших наборов данных производительность можно поднять путём создания пары конкатенированных индексов по столбцам, по которым происходит соединение. В данном примере по столбцам COMPANY_KEY, PARENT_KEY и PARENT_KEY, COMPANY_KEY.
Если вы хотите визуализировать древовидную структуру в текстовом виде, следующий запрос отображает список подчинённых организаций Microsoft с отступами:
select LPAD(' ',3*(SUBSIDIARY_LEVEL))||SUBSIDIARY_COMPANY from
COMPANY_STRUCTURE order by SEQUENCE_NUMBER where parent_key =100
Поле SEQUENCE_NUMBER было добавлено ещё в оригинальной статье, оно нумерует узлы снизу вверх и справа налево. Оно позволяет хранить корректные узлы уровня 2 под соответствующими им узлами уровня 1.
Для создания графической версии дерева организационной структуры обратите внимание на продукт VISIO 2000 Enterprise Edition, в котором имеется мастер создания схем организационных структур на основе данных из базы данных или текстовых файлов. С помощью программы на VBA, представления над таблицей COMPANY STRUCTURE и таблицы фактов он может автоматизировать генерацию той страницы HTML, которая вам нужна.
Я был бы признателен, если бы кто-нибудь мог прислать мне процедуры для DB2 UDB и Microsoft SQL Server, которые давали бы те же самые результаты. Более эффективные реализации для Oracle также представляют интерес. Лучшие примеры получат оценку и будут включены в будущую колонку журнала Intelligent Enterprise.
Совет №18. Рассматриваем всерьёз метафору о публикации
В этом выпуске я хочу поделиться перспективой, которую я рассматриваю очень серьёзно, и которая в некоторой степени является основой всей моей работы в области хранилищ данных. Это - метафора публикации. Давайте рассмотрим следующий сценарий.
Представьте, что вас попросили взять ответственность за высококачественный журнал. Вас назначили главным редактором и дали широкие полномочия по управлению содержанием, стилем и доставкой этого журнала.
Если вы подойдёте к этой ответственности с умом, на мой взгляд, вам следует сделать следующие 12 вещей:
- определить демографический состав ваших читателей
- узнать, что хотят видеть читатели в таком журнале
- определить “лучших” читателей, которые будут возобновлять подписку и покупать рекламируемые в журнале продукты
-
найти новых потенциальных читателей и проинформировать их о журнале
выбрать наиболее подходящее для читателей наполнение - принять решение о выборе макета, приятного для читателей
- придерживаться стандартов написания и редактирования и принять последовательный презентационный стиль
- постоянно отслеживать точность статей и заявления рекламодателей
-
поддерживать доверие читателей
создать хорошую сеть писателей и корреспондентов - привлечь рекламодателей и обеспечивать прибыльность журнала
- следить, чтобы хозяева были довольны
Если вы будете выполнять всё это хорошо, я думаю, вы будете замечательным главным редактором! И наоборот, просмотрите список ещё раз и представьте, что произойдёт, если вы пропустите хоть один пункт. В конечном счёте, ваш журнал будет иметь проблемы.
В то время как эти зоны ответственности могут выглядеть очевидными, приведём несколько сомнительных пунктов, выполнение которых не должны стать целью:
- стройте журнал на основе технологии конкретного печатного станка
- вложите максимум энергии менеджеров на оперативную эффективность работы печатного станка
- используйте сложный высокотехнический стиль изложения, который многие читатели могут не понять
- используйте запутанный и перегруженный стиль макета, который создаёт трудности чтения и навигации
Урок в случае публикации журнала состоит в том, что весь смысл игры заключается в эффективном обслуживании читателей. Если ваш журнал будет построен на обслуживании ваших читателей, то ваш журнал, вероятно, будет успешным.
Смысл этой метафоры, конечно же, заключается в проведении параллели между обычным издателем и руководителем проекта по созданию хранилища данных.
Я убеждён в том, что корректным описанием работы руководителя проекта по созданию хранилища данных является “публиковать правильные данные”. Ваша главная ответственность заключается в обслуживании ваших читателей, которыми являются конечные пользователи. В то время как вы, конечно же, будете использовать определённую технологию для создания хранилища данных, технология является в самом лучшем случае лишь средством. Технология и приёмы, которыми вы пользуетесь при построении вашего хранилища данных не должны быть в списке 12 самых важных вещей, но технологии и приёмы станут намного более очевидными если вашей конечной целью станет эффективная публикация правильных данных.
Давайте переделаем 12 областей ответственности издателя журнала в области ответственности, связанные с хранилищами данных:
- понимайте ваших пользователей из разных бизнес-областей
- определите решения, которые хотят принимать конечные пользователи на основе данных из хранилища
- найдите “лучших” пользователей, принимающих эффективные решения с помощью хранилища данных
- ищите новых потенциальных пользователей и рассказывайте им о хранилище данных
- выберите наиболее эффективное действующее подмножество данных для загрузки в хранилище, извлечённое из громадного множества возможных данных вашей организации
- делайте экраны и интерфейсы конечных пользователей ГОРАЗДО проще и больше на основе шаблонов, приближая содержимое экранов к профилям мыслительной активности ваших конечных пользователей
- убедитесь в том, что ваши данные точны, что им можно доверять, и что они именуются централизованно в соответствии с корпоративными нормами
- постоянно следите за точностью данных и содержимым отчётов
- поддерживайте доверие со стороны конечных пользователей
- постоянно ищите новые источники данных и постоянно адаптируйте хранилище данных к изменяющимся профилям данных и требованиям к отчётам
- возьмите на себя часть ответственности за решения, принимаемые конечными пользователями на основе данных хранилища, и используйте эти успехи для обоснования расходов на персонал, программное и аппаратное обеспечение
- поддерживайте счастливыми ваших конечных пользователей, руководителей конечных пользователей и вашего начальника
Если вы хорошо справитесь со всеми этими областями ответственности, я думаю, вы будете отличным руководителем проекта по созданию хранилища данных! И напротив, пройдитесь сверху вниз по списку и представьте, что случится, если вы пропустите хотя бы один элемент. В конечном счёте, у вашего хранилища будут серьёзные проблемы.
Я призываю вас сопоставить этот взгляд на обязанности руководителя проектом по созданию хранилища данных с описанием ваших должностных обязанностей. Очень высоки шансы того, что список, приведённый выше, гораздо сильнее ориентирован на конечного пользователя и задачи бизнеса и может даже не напоминать описания должности в области информационных технологий. Но, по моему мнению, это то, что делает эту работу интересной. Пишите мне, чтобы сообщить свою реакцию.
Совет №19. Корректная репликация измерений
Секрет построения распределённого хранилища данных кроется в использовании согласованных измерений. В распределённом хранилище данных многие различные источники показателей поддерживаются различными подразделениями. Эти показатели обычно представляются в “таблицах фактов”. Одно подразделение может измерять результаты производства товаров, а другое может измерять остатки товаров на складе. Третье подразделение может измерять продажи отдельных товаров, а четвёртое - комментарии и жалобы о товарах. Очевидно, что все эти подразделения имеют общую заинтересованность в “товарах”. Мы можем построить распределённое хранилище данных, если мы сможем заставить все эти четыре подразделения договориться об определении товаров.
На самом деле, нужно сказать об этом сильнее. Мы сможем построить распределённое хранилище данных, если все эти четыре подразделения будут использовать согласованные измерения. А в действительности эти подразделения должны согласовать все остальные измерения, которые они используют совместно, например, время и клиенты. Но в нашей дискуссии мы остановимся только на измерении товар.
Наиболее простой способ согласования измерения товар - это использование во всех четырёх подразделениях одну и ту же идентичную таблицу измерения. Одни и те же ключи, одни и те же атрибуты, всё одинаковое. Каждое из четырёх подразделений, конечно же, должны преобразовать внутренние ключи записей о товарах, в своих таблицах фактов в общедоступные суррогатные ключи, использующиеся в согласованной таблице измерения товар. Я описал этот конвейер суррогатных ключей в статье Суррогатные ключи. Конвейерная обработка суррогатных ключей.
Более сложный способ использования согласованного измерения товар состоит в том, чтобы позволить одному из подразделений использовать подмножество таблицы измерения товар. Предположим, что некоторое подразделение вводит информацию о товарах на уровне марки товара, а не на уровне отдельных товаров. Для такого подразделения будет приемлемым использование сокращённой версии измерения товар с информацией только на уровне марки. Естественно, это приведёт к тому, что при операции drill across придётся искать таблицы фактов, агрегированные на самом низком общем уровне агрегации измерения товар, который в этом случае будет уровнем марки товара, а не отдельным товаром.
Реальным преимуществом использования согласованных измерений является возможность выполнения операции drill across к другим витринам данных (таблицам фактов). Если вы сможете наложить ограничения и выполнить группировку на основе одних и тех же характеристик в различных витринах данных, вы сможете сравнить показатели из разных выборок на основе заголовков столбцов из таблицы измерения товар. Так что в одном отчёте вы сможете показать объёмы производства товара, его складские запасы, а также объём продаж на очень детальном уровне, а если вы перейдёте на уровень марки, вы сможете добавить количество жалоб на качество товара.
Операция drill across является концептуальным шагом в использовании распределённого хранилища данных и способом избежания его централизации.
Но администрирование согласованных измерений требует соблюдения специальной дисциплины. Организации требуется “орган власти над измерением”, в данном случае, царь товаров. Орган власти над измерением отвечает за поддержку измерения товар и его успешную репликацию всем клиентам витрин данных, которые используют в своих таблицах фактов информацию о товарах. Нам нужно всерьёз принимать задачу репликации измерения и его согласованного использования.
Это было бы катастрофой, если бы собирали данные для отчёта из нескольких витрин данных, одна часть которых использовала бы вчерашнюю версию данных о товарах, а другая - сегодняшнюю. Результаты оказались бы коварно обманчивыми.
Заголовки строк не означали бы одного и того же при попытке согласовать определения атрибутов. Например, если бы менеджер категорий изменил определение одной из категорий товаров, результаты отчётов, построенные на основе этих несинхронизированных заголовков строк, были бы неверными. И это в порядке вещей, что менеджеры категорий вправе изменять названия категорий и многие другие атрибуты измерения товар.
Подобная проблема возникает, когда какая-нибудь витрина данных использует агрегатный навигатор, который автоматически заменяет сжатую таблицу измерения товар и соответствующую сжатую таблицу фактов в момент, когда пользователь формирует запрос. Например, если пользователь запрашивает информацию о “доле” определённого товара в категории товаров, мы обычно выполняем два запроса к таблице фактов, а затем выполняем операцию деления для вычисления доли. Но второй запрос просто выбирает данные об общих продажах всей категории, и является отличным кандидатом на использование агрегированной таблицы.
Мораль этой истории заключается в том, что если орган, контролирующий измерение, выпустил новую таблицу измерения товар, то все агрегированные таблицы, на которые влияют сделанные изменения, должны быть подстроены. Если какие-то товары нижнего уровня иерархии были перемещены из одной категории в другую, то изменяется не только таблица товаров, но и любая таблица фактов на уровне категорий должна быть подстроена.
Мы можем суммировать две области ответственности для корректной репликации измерений:
1) Все клиентские витрины данных должны внедрить реплицируемое измерение одновременно с тем, чтобы при выполнении пользователями любой операции drill across использовался согласованный набор атрибутов измерения
и
2) Все клиентские витрины данных должны удалить агрегаты, на которые влияют изменения измерений, и предоставлять доступ конечным пользователям к этим агрегатам только после того, как они полностью согласованы с базовыми таблицами фактов и с новой логикой вычисления агрегированных показателей.
Тема репликации измерений является критерием №9 в моём списке критерием дружественности многомерным моделям. Как Microsoft, так и Cognos прислали детальные ответы на все двадцать критериев, которые делают их “системами, дружественным многомерным моделям”. Проверьте, что они сделали для репликации измерений. Мы ожидаем, что другие производители оценят свои системы, используя эти двадцать критериев. Вы можете найти полный список критериев и ответы производителей по адресу http://www.ralphkimball.com/html/dimension.html (ссылка не работает - прим. пер.).
Если вы являетесь конечным пользователем и хотите оценить всю вашу систему, которая может состоять из продуктов нескольких производителей, обратитесь, пожалуйста, ко мне. Мне будет интересно поместить такие оценки на сайт.
Совет №20. Разреженные факты и факты с коротким жизненным циклом
Таблицы фактов сроятся на основе числовых показателей. Когда выполняется измерение значения показателя, порождается запись в таблице фактов. Показатель может быть суммой продажи, суммой транзакции, нарастающим балансом в конце месяца, объёмом производства продукта, или даже классическим лабораторным измерением. Если мы одновременно снимаем значения нескольких показателей, мы можем поместить их все в одну и ту же запись таблицы фактов.
Мы окружаем показатели всеми вещами, которые нам известны в момент измерения их значений. Помимо времени мы часто имеем информацию о таких вещах, как клиент, продукт, рыночные условия, сотрудник, статус, поставщик, а также о многих других сущностях, зависящих от процесса, поставляющего нам значения показателей.
Мы упаковываем все вещи, о которых мы знаем, в записи таблицы измерений, сопровождаемые текстом, и соединяем факты с измерениями с помощью отношений внешний ключ / первичный ключ.
Это приводит к классической организации таблицы фактов (показанной здесь для N измерений и двух фактов с названиями Dollars и Units):
dimkey1 (FK)
dimkey2 (FK)
dimkey3 (FK)
...
dimkeyN (FK)
Dollars
Units
Поля Dollars и Units зарезервированы для соответствующих показателей. Этот дизайн содержит явные предположения о том, что:
- эти два показателя обычно оба присутствуют,
- эти показатели являются единственными показателями данного процесса
-
существует большое количество событий с измерением величин показателей, другими словами, есть смысл посвятить эту таблицу с фиксированным форматом специально этим показателям.
Но что произойдёт, если все три этих предположения окажутся несправедливыми? Это часто случается при слежении за сложными финансовыми инвестициями, где каждый инструмент инвестирования имеет индивидуальные параметры. Это также случается в процессах промышленного производства где циклы загрузки коротки и каждый тип цикла имеет массу специальных показателей. Я, наконец, в клинических и медицинских лабораториях выполняются измерения сотен показателей, ни одно из которых не происходит часто. Все три этих примера можно охарактеризовать как “разреженные” факты.
Вы не можете просто расширить структуру классической таблицы фактов для обработки разреженных фактов. У вас получился бы неработоспособный список фактических полей, большинство из которых было бы не заполнено во отдельно взятой строке.
Решением является добавление специального “измерения фактов” и сокращение списка действительных числовых фактов до одного поля AMOUNT (количество):
dimkey1 (FK)
dimkey2 (FK)
dimkey3 (FK)
...
dimkeyN (FK)
factkey (FK) <== дополнительное измерение
Amount
“Измерение фактов” описывает значение поля Amount. Оно содержит то, что раньше было названием поля факта, а также единицу измерения и любые ограничения аддитивности. Например, если показатель похож на остаток (баланс), он может быть полностью аддитивным вдоль всех измерений кроме измерения ВРЕМЯ. Но если это полноценный факт класса интенсивности, например, температура, то он является полностью неаддитивным. Агрегирование неаддитивного показателя требует использования функции среднего, а не суммы.
Этот подход является элегантным, поскольку он очень гибок. Вы добавляете новые типы показателей путём простого добавления новых записей в измерение фактов, а не путём изменения структуры таблицы. Вы также избавляетесь ото всех значений NULL классического дизайна, поскольку записи существуют только в случае существования показателей.
Однако есть ряд существенных компромиссов. У вас может получиться ОЧЕНЬ БОЛЬШОЕ количество записей. Если какое-то из ваших измерений даёт 10 значений показателей, у вас получится 10 новых записей в отличие от одной в случае классического дизайна.
Для случаев с очень разреженными фактами это является отличным компромиссом. Но по мере роста плотности фактов в многомерном пространстве, которое вы сконструировали, вы начинаете наполнять вселенную записями. В какой-то момент вам придётся вернуться к классическому формату.
Этот подход также делает приложения более сложными. Совместное использование двух величин, полученных в результате одного измерения, более сложно, так как теперь вам требуется извлекать уже две записи. SQL делает это неудобным, поскольку SQL любит манипуляции ВНУТРИ строки, а не между строками. Вам также следует проявлять осторожность, чтобы не смешивать в расчётах несовместимые типы показателей, поскольку все числовые значения хранятся в единственном поле Amount.
Но все эти компромиссы оправданы, если вы живёте в мире финансовых инвестиций, промышленного производства или медицины.
Совет №21. Объявляем уровень детализации
Наиболее важный этап многомерного моделирования (multidimensional modeling) - это объявление уровня детализации таблицы фактов. Объявление уровня детализации означает ТОЧНОЕ определение того, что представляют собой записи таблицы фактов. Помните, что запись таблицы фактов регистрирует измерение величин. Примеры объявлений включают:
- отдельный товар в чеке клиента розничного магазина, зарегистрированный сканирующим устройством (POS)
- отдельная операция по страховому полису
- строка счёта, полученного от доктора
- отдельный посадочный талон, используемый пассажиром авиарейса
Когда вы делаете такое объявление уровня детализации, вы можете очень точно обсудить то, какие измерения (dimension) возможны, а какие - нет. Например, строка счёта от доктора (пример №3), возможно, будет иметь следующие измерения:
Дата (обращения)
Доктор (может называться “предоставитель услуги”)
Пациент
Процедура
Первичный диагноз
Местоположение (предполагается, кабинет доктора)
Организация, выставляющая счёт (организация, в которой работает доктор)
Ответственная сторона (либо пациент, либо его законный представитель)
Основной плательщик (часто страховой план)
Вторичный плательщик (может быть, страховой план супруга или супруги ответственной стороны) и, возможно, другие измерения.
Если вы следили за этим примером, я надеюсь, вы заметили некоторые мощные эффекты объявления уровня детализации. Во-первых, вы можете очень точно визуализировать многомерность отношения доктор-счёт-строка счёта. Мы также можем обсудить источники в стиле ответов Да/Нет на предмет возможности присоединения к этим данным измерений. Например, мы, возможно, исключим “результат лечения” из этого примера, поскольку большинство медицинских данных не привязываются ни к каким категориям результатов. НО, обычная “модель данных” визитов к доктору в стиле диаграммы “сущность-связь” (ER-diagram) вполне может включать результат лечения. В конечном счёте, в абстрактном смысле каждое лечение имеет какой-то результат, не правда ли???
Дисциплина настаивания на объявлении уровня детализации в начале разработки многомерной модели (multidimensional model) предостерегает нас от ошибки такого характера. Модель оплачиваемых визитов к доктору, включающая результат лечения, выглядела бы как многомерная модель, но она была бы нереализуемой.
Это моё главное возражение против многих современных предложений “стандартных схем” в книгах и на компакт-дисках. Поскольку они не придерживаются дисциплины уровня детализации, они часто объединяют сущности (entity), которые не существуют вместе в реальных источниках данных (source system).
Второе главное понимание объявления уровня детализации доктор-счёт-строка счёта - это то, что этот атомарный уровень детализации порождает множество измерений! Выше мы перечислили 10 измерений, а те из вас, которые являются экспертами в части автоматизации выставления счетов за медицинские услуги, возможно знают о ещё нескольких. Очень интересно осознавать, что чем на более детальном уровне измеряются показатели (чем более атомарна запись таблицы фактов), тем больше вещей вы знаете наверняка. И, как следствие, больше измерений! Это ещё одно объяснение того факта, что атомарные данные выдерживают натиск “атак непредвиденными запросами (ad hoc query)” со стороны конечных пользователей. Атомарные данные (atomic data) имеют наибольшее количество измерений и могут быть ограничены и агрегированы любым способом, который позволяет источник данных. Атомарные данные идеально подходят для многомерного моделирования.
Все объявления уровня детализации, перечисленные в начале этого совета, представляют самые детальные из возможных уровней детализации соответствующих источников данных. Измеряемые показатели являются “атомарными” и не могут быть далее детализированы. Но вполне возможно объявить более высокие уровни детализации для каждого из этих источников данных, которые будут представлять агрегаты атомарных данных (aggregate data):
- все продажи отдельного продукта в отдельном магазине за день
- суммарные обороты по страховым полисам за месяц по направлениям бизнеса
- итоговые суммы за месяц счетов по видам лечения и диагнозам
- количество пассажиров и другие показатели удовлетворённости полётами за месяц по отдельным маршрутам
Эти более высокие уровни агрегации почти всегда будут иметь меньшее количество и менее крупные измерения. Наш пример с доктором может в конечном счёте привести к следующим измерениям:
- Месяц
- Доктор
- Процедура
- Диагноз
Было бы нежелательным включать в агрегированную таблицу фактов все исходные измерения атомарных данных потому что обычно у вас будет очень мало возможностей агрегирования!
Поскольку полезные агрегации обязательно сжимают и убирают измерения, это приводит к осознанию того, что эти агрегированные данные следует использовать вместе с базовыми детальными данными, потому что агрегированные данные имеют меньше деталей о измерениях. Некоторых авторов это смущает, и после объявления того, что витрины данных (data mart) должны обязательно состоять из агрегированных данных, они критикуют витрины данных за то, что они “ожидают вопрос о бизнесе”. Всё это непонимание уходит когда агрегированные данные предоставляются ВМЕСТЕ с атомарными данными, из которых они производятся.
Наиболее важным результатом объявления уровня детализации таблицы фактов является установка отправной точки дискуссии об измерениях. Но объявление уровня детализации также позволяет вам прояснить ситуацию с измеряемыми числовыми показателями. Проще говоря, факты должны соответствовать уровню детализации. В нашем примере с доктором наиболее очевидным измеряемым фактом была бы “сумма по счёту”. Возможны также другие факты, относящиеся к специфическим видам лечения, полученным определёнными пациентами. Но “полезные” факты наподобие нарастающей итоговой суммы (running total), выставленной в счетах данному пациенту за все виды лечения не соответствуют уровню детализации. Когда фактические записи произвольным образом комбинируются генератором отчётов, эти не соответствующие уровню детализации факты приводят к бессмысленным бесполезным результатам. Их нужно оставить за пределами дизайна. Вычисляйте такие агрегированные показатели с помощью вашего приложения.
Подводя итог, старайтесь проектировать ваши многомерные модели в следующем порядке:
- примите решение об источниках данных
- объявите уровень детализации таблицы фактов (предпочтительно, на самом детальном уровне)
- добавьте измерения для “всего, что вы знаете” об этом уровне детализации
- добавьте числовые факты для данного уровня детализации
Совет №22. Измерения КЛИЕНТ переменной глубины
Измерение КЛИЕНТ, возможно, одно из самых сложных в хранилище данных. В большой организации измерение КЛИЕНТ может быть
- огромным с миллионами записей
- широким с десятками атрибутов
- медленно изменяющимися, но иногда и быстро изменяющимися
Но это ещё не всё: в самых больших измерениях КЛИЕНТ часто присутствуют две категории клиентов, которые я называю Посетитель и Клиент.
Посетитель анонимен. Мы можем видеть их многократно, но мы не знаем их имён и не имеем других сведений о них. В случае веб-сайта всё, что мы имеем - это файл cookie, который говорит об их возвращении. В розничной торговле Посетитель выполняет анонимную транзакцию. Может быть, у нас есть номер кредитной карты или простой клубной карты, но мы предполагаем, что о Посетителе у нас нет никакой демографической информации.
Клиент, в противоположность, надёжно нами зарегистрирован. Мы знаем имя, адрес клиента, а также располагаем всей информацией, которую он нам предоставил, или которую мы приобрели от третьих лиц. У нас есть адрес доставки, история платежей и, возможно, кредитная история каждого Клиента.
Давайте предположим, что на самом детальном уровне нашего набора данных 80% записей таблицы фактов вовлекают Посетителей, а 20% - Клиентов. Давайте также предположим, что накапливаем простые показатели поведения, состоящие только из свежести (когда мы последний раз их видели), частоты (сколько раз мы их видели) и интенсивность (сколько денег мы на них заработали). Таким образом, этот простой дизайн включает только три показателя, характеризующие Посетителя.
С другой стороны, давайте предположим, что у нас есть 50 атрибутов/показателей, характеризующих Клиента, которые охватывают все компоненты расположения, платёжного поведения, кредитного поведения, непосредственно полученные демографические атрибуты и демографические атрибуты, приобретённые у третьих сторон.
Давайте сделаем несколько довольно специфических предположений в целях ясного дизайна. Позже мы сможем их несколько ослабить…
Во-первых, давайте объединим посетителей и клиентов в одно логическое измерение под названием Покупатель. Настоящему физическому Посетителю/Клиенту мы дадим уникальный постоянный идентификатор покупателя, но ключ таблицы мы сделаем суррогатным чтобы иметь возможность отслеживать изменения измерения ПОКУПАТЕЛЬ, происходящие со временем. Логически, наше измерение выглядит следующим образом:
*** атрибуты для Посетителей и Клиентов
Суррогатный ключ Покупателя <== простое целое число, возрастающее с каждым изменением
Shopper ID <== постоянный фиксированный идентификатор для каждого физического покупателя
Recency Date <== дата последнего визита, тип 1: перезаписывается
Frequency <== количество визитов, тип 1: переписывается
Intensity <== общее количество бизнеса, например, продано итого в долларах, тип 1
*** атрибуты только для Клиентов:
5 атрибутов имени <== имя, отчество, фамилия, пол, обращение
10 атрибутов размещения <== компоненты адреса
5 атрибутов платёжного поведения
5 атрибутов кредитного поведения
10 прямых демографических атрибутов
15 приобретённых демографических атрибутов
Одно сильное предположение, которое мы сделали здесь, заключается во включении информации о свежести, частоте и интенсивности в атрибуты измерения, а не в качестве фактов, а также том, что мы постоянно переписываем их по мере изменения (медленно изменяющееся измерение типа 1). Это предположение делает наше измерение Покупатель очень мощным. Мы можем выполнять классическую сегментацию покупателей на основе измерения без навигации по таблице фактов в сложном приложении. Смотрите обсуждение сегментации по свежести-частоте-интенсивности в моей книге Webhouse Toolkit начиная со страницы 73.
Если мы предположим, что многие из последних 50 атрибутов Клиентов являются текстовыми, мы получим запись размером 500 или более байт. Предположим, у нас 20 миллионов Покупателей (16 миллионов Посетителей и 4 миллиона зарегистрированных Клиентов). Очевидно, мы обеспокоены тем, что в 80% наших записей 50 последних атрибутов не содержат данных! В 10-гигабайтном измерении это привлекает наше внимание. Это явный случай когда, в зависимости от базы данных, мы можем захотеть ввести снежинку.
В базах данных с переменным размером записи, наподобие Oracle, мы можем просто построить одно измерение ПОКУПАТЕЛЬ со всеми перечисленными выше атрибутами, не принимая в расчёт проблему с пустыми полями. Большинство записей о покупателях, которые являются просто Посетителями, останутся узкими, поскольку в этих базах данных пустые поля не занимают места на диске.
Но в базах данных с фиксированным размером записей мы, возможно, не хотим мириться с пустыми полями для всех Посетителей, поэтому мы разбиваем измерение на базовое измерение и вспомогательное измерение:
Базовое:
Суррогатный ключ Покупателя <== простое целое число, возрастающее с каждым изменением
Shopper ID <== постоянный фиксированный идентификатор для каждого физического покупателя
Recency Date <== дата последнего визита, тип 1: перезаписывается
Frequency <== количество визитов, тип 1: переписывается
Intensity
Суррогатный ключ Клиента <== новое поле для связи со снежинкой
Снежинка:
Суррогатный ключ Клиента <== соответствие 1:1 с теми покупателями, которые являются Клиентами
5 атрибутов имени
10 атрибутов размещения
5 атрибутов платёжного поведения
5 атрибутов кредитного поведения
10 прямых демографических атрибутов
15 приобретённых демографических атрибутов
В базе данных с фиксированным размером строк, используя наше предыдущее предположения, базовое измерение ПОКУПАТЕЛЬ будет 20 миллионов x 25 байт = 500 МБ, а измерение-снежинка 4 миллиона x 475 байт = 1.9 ГБ. Мы сэкономили 8 гигабайт.
Если ваш генератор отчётов настаивает на классической схеме “звезда” без снежинок, спрячьте снежинку посредством представления.
Совет №24. Разрабатываем измерения в многонациональном хранилище данных
Если вы занимаетесь многонациональным хранилищем данных, вы можете столкнуться с проблемой представления содержания хранилища данных на ряде различных языков. Какие части хранилища нуждаются в переводе? Где хранить версии на разных языках? Как вы обращаетесь с открытостью, когда нужно добавлять версии на новых языках?
При построении истинно многонационального хранилища данных встречается много проблем проектирования. Я попытался осветить их в книге Data Webhouse Toolkit, так что в этом совете мы сконцентрируемся только на том, как представить конечным пользователем результаты “с возможностью переключения языков” и не будем обсуждать:
- валюты
- разделительные знаки
- часовые пояса
- разбор имён и адресов
- представления телефонных номеров
Нашей целью будет свободное переключение между представлениями в расширяющемся множестве языков, как для непредвиденных запросов, так и для стандартных отчётов. Мы также хотим выполнять операцию drill across в распределённом многонациональном хранилище данных, построенном на согласованных измерениях.
Очевидно, что основное наше внимание должно быть сосредоточено на наших измерениях. Измерения являются репозиториями практически всей текстовой информации наших хранилищ данных. Измерения хранят подписи, иерархии, и описания наших данных. Измерения управляют содержимым интерфейсов пользователя и предоставляют содержимое заголовков строк и столбцов всех наших отчётов.
Прямолинейный подход заключается в предоставлении полных переведённых копий каждого измерения на каждый поддерживаемый язык. Другими словами, если у нас есть измерение ПРОДУКТ, изначально описанное на английском языке, а мы хотим иметь немецкую и французскую версии, мы копируем английское измерение строка за строкой и столбец в столбец, сохраняя ключи и цифровые индикаторы, переводя при этом все текстовые атрибуты.
Но мы должны быть внимательными. Чтобы сохранить интерфейс пользователя и окончательные результаты английской версии, как немецкая, так и французская версия измерения ПРОДУКТ должны буду сохранить те же самые
- отношения 1-к-1 и многие-к-1, а также
- логику группировки как для не предопределенных отчётов, так и для построения агрегатов.
Явно понимаемые отношения 1-к-1 и многие-к-1 должны быть определённо усилены моделью сущность-связь в области перегрузки. Это легко осуществить. Но затем возникает тонкая проблема при переводе, которая заключается в том, чтобы не перевести два разных английских названия атрибута одним и тем же словом на немецком или французском языках. Например, если английские слова ’scarlet’ и ‘crimson’ переведены на немецкий одним и тем же словом ‘rot’, некоторые суммарные данные в отчётах будут отличаться в английской и немецкой версиях. Поэтому нам нужен дополнительный шаг ETL, который будет проверять, что мы не перевели два разных английских слова одинаково.
Большим преимуществом такого дизайна является масштабируемость, так как мы всегда можем добавить новый иностранный язык без изменения структуры таблиц и повторной загрузки базы данных.
Мы можем позволить французским или немецким пользователям осуществлять операцию drill across к далеко заброшенному распределённому хранилищу данных, если мы РЕПЛИЦИРУЕМ переведённые версии измерений во все удалённые витрины данных. Помните о том, что когда мы осуществляем операцию drill across к распределённым витринам данных, мы выполняем основные запросы удалённо. Именно поэтому переведённые измерения должны располагаться в каждой целевой базе данных.
Когда французский или немецкий пользователь запускает запрос drill across, каждая удалённая витрина данных должна использовать правильные переведённые измерения. Они будут достаточно легко обработаны первоначальным французским/немецким приложением, которое формулирует запрос. Заметьте, что каждая удалённая база данных должна поддерживать “измерения с горячей заменой”, которые позволяют выполнять это переключение измерений от запроса к запросу по мере поступления запросов на разных языках. В реляционной среде это достаточно просто, но может быть нелегко в среде OLAP.
Хотя мы многое сделали с помощью этого дизайна, включая масштабируемый подход к внедрению распределённого многоязычного хранилища данных, у нас всё ещё есть неразрешённые проблемы, которые являются откровенно серьёзными:
- мы не можем легко сохранять порядок сортировки в разных языковых версиях одного отчёта. Естественно, мы не можем отсортировать переведённые атрибуты в том же порядке, что и на основном языке. Если требуется сохранить порядок сортировки, то нам понадобится гибридное измерение, как с основным языком, так и со вторым, чтобы запрос SQL производил сортировку на основном языке, но результаты показывал на втором языке как не отсортированные строки. Это громоздко и приводит к измерениям вдвое большего размера, но, возможно будет работать.
- если основной язык - английский, мы, возможно, обнаружим, что почти во всех остальных языках длина переведённого текста будет больше, чем длина текста на английском. Не спрашивайте меня, почему. Но это представляет проблемы при форматировании пользовательских интерфейсов и отчётов.
- наконец, если наш набор языков выходит за рамки английского и основных европейских языков, то даже расширенного набора восьмибитных символов кодировки ASCII будет недостаточно. Все участвующие витрины данных должны будут поддерживать 16-битную кодировку UNICODE. Помните, что наш дизайн требует, чтобы переведённые измерения находились на целевых машинах.
Совет №25. Разработка многомерных моделей для приложений родитель-потомок
Отношение родитель-потомок является одной из основных фундаментальных структур в мире бизнеса. Счёт (предок) может иметь строки (потомки). Другие очевидные примеры помимо счетов включают заказы, накладные, страховые полисы и чеки в розничных магазинах. Фактически, любой документ бизнеса со встроенными повторяющимися группами подходит под определение приложения родитель-потомок, особенно когда встроенные строки содержат интересные числовые данные, такие как денежные суммы или количество в штуках.
Приложения родитель-потомок представляют крайний интерес для хранилищ данных, поскольку большинство управляющих документов на перевод денег и товара (или услуг) из одного места в другое принимают форму родитель-потомок.
Но источники данных вида родитель-потомок наподобие счетов представляют классическую дилемму проектирования. Некоторые данные доступны только на родительском уровне, а другие - только на уровне потомков. Нам нужны две таблицы фактов в нашей многомерной модели, или можно обойтись одной? И что делать с данными, доступными только на родительском уровне, если мы хотим иметь возможность детализации до уровня потомка?
Давайте представим типичный счёт на продажу продуктов. Счёт создаётся для нашей компании торговым агентом и направляется определённому клиенту. Каждая строка счёта представляет отдельный продукт, продаваемый клиенту.
Данные родительского уровня включают следующее:
дата счёта (измерение)
торговый агент (измерение)
клиент (измерение)
условия платежа (измерение)
номер счёта (вырожденное измерение, см. ниже)
чистая цена за позицию (аддитивный факт)
общая сумма скидки уровня счёта (аддитивный факт)
общая стоимость доставки (аддитивный факт)
общая сумма налогов (аддитивный факт)
общий итог (аддитивный факт)
Данные уровня потомка включают следующее:
Продукт (измерение)
Рекламная акция (измерение)
Количество единиц продукта (аддитивный факт)
Цена единицы продукта (см. ниже)
Цена позиции (количество умножить на цену) (аддитивный факт)
Скидка рекламной акции на этот определённый продукт (см. ниже)
Итоговая чистая цена (количество х(цена за единицу -скидка)) (аддитивный факт), а также “контекст” всего счёта (четыре измерения выше).
При заданных условиях на измерения и факты может показаться, что мы всё сделали. У нас есть две красивых таблицы фактов. Родительская таблица фактов счетов имеет 4 измерения и 5 фактов, а дочерня таблица фактов строк счёта имеет 6 измерений и 3 факта.
Но наш дизайн неудачен. Мы не можем вычислить объём бизнеса в разрезе продуктов! Если мы зададим фильтр на определённый продукт, мы не будем знать что делать со скидками, ценой доставки и налогами уровня счёта. Все верхнеуровневые точки зрения на наш бизнес в разрезе клиентов, торговых агентов и рекламных акций будут вынуждены пропускать продуктовое измерение. В большинстве предприятий это недопустимо. Существует единственный способ решения этой проблемы. Вы должны взять данные уровня счёта и разнести их ниже на уровень строки счёта. Да, в таком разнесении есть некоторые противоречия, и, да, вы должны принять несколько произвольных решений, но альтернативой является невозможность анализа бизнеса в разрезе продуктов.
Мы заменим две таблицы фактов одной таблицей фактов, у которой уровнем детализации будет строка счёта. Другими словами, мы последовательно опустимся на наиболее детальный уровень потомка в процессе разработки многомерной модели предок-потомок.
Вспомните нашу дискуссию о выборе степени детализации (совет №21), где говорилось, что мы можем “украсить” величину всем, что мы о ней знаем в момент её измерения. Таким образом, наша таблица уровня отдельной строки счёта имеет следующие измерения:
- Дата выставления счёта (измерение)
- Торговый агент (измерение)
- Клиент (измерение)
- Условия платежа (измерение)
- Продукт (измерение)
- Рекламная акция (измерение)
Что нам делать с номером счёта? Он, несомненно, представляет собой одну величину, даже на уровне строки счёта, но мы уже “выставили” всё, что мы знаем о счёте в наших четырёх первых измерениях. Мы должны оставить номер счёта в модели, но нам не нужно делать из него измерение, потому что это измерение будет пустым. Мы называем это “вырожденным измерением”.
- Номер счёта (вырожденное измерение)
Теперь наши факты для этой таблицы фактов строк счёта будут включать:
- Количество единиц продукта (аддитивный факт)
- Цена позиции (количество единиц х цена) (аддитивный факт)
- Итоговая чистая цена (количество х (цена за единицу - скидка)) (аддитивный факт)
- Разнесённые с уровня счёта скидки (аддитивный факт)
- Разнесённая стоимость доставки (аддитивный факт)
- Разнесённая сумма налогов (аддитивный факт)
Мы не включаем цену продуктов или суммы скидок как физические факты, поскольку мы всегда можем разделить итоговые суммы на количество единиц товара в нашем генераторе отчётов для получения этих неаддитивных величин.
Мы можем мгновенно восстановить точные цифры уровня счета, просто складывая все строки с определённым номером счёта. Нам не нужна отдельная родительская таблица фактов для счёта, потому что это всего лишь проста агрегация нашей более детальной таблицы фактов. Мы нисколько не скомпрометировали итоговые суммы уровня счёта, произведя их разнесение до уровня строк счёта.
И, что самое лучшее, мы можем теперь легко посчитать объём бизнеса на самых высоких уровнях, делая деление по продуктам и включая разнесённые величины для получения полной картины наших чистых доходов.
Метод спуска на уровень строки счёта и построения единой детальной таблицы фактов находится сердце моделирования хранилищ данных. Он является хорошим методом выполнения наших обещаний “исследовать предприятие во всех разрезах”.
Совет №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-запроса. Другими словами, простой запрос вида
SELECT PRODUCT, SUM(SALES)
вы усиливаете до следующего:
SELECT PRODUCT, VALUE_STATUS, SUM(SALES), COUNT(*).
Теперь ваш отчёт будет плодить дополнительную строку каждый раз при возникновении аномальных условий на данные. Вы получите значение количества строк, которое позволит вам оценить насколько плохо состояние данных. Заметьте, что до того, как мы занялись проектированием, в ваш отчёт тихо попадали значения с кодом НА (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”.
Совет №27. Находимся в режиме off-line как можно меньше
В этом совете мы опишем набор методов, которые будут работать для всех основных реляционных СУБД, поддерживающих секционирование (partitioning). Точные детали администрирования при секционировании изменяются от одной СУБД к другой, однако вы будете знать, какие задавать вопросы.
Секция в СУБД - это физический сегмент таблицы. Несмотря на то, то с токи зрения приложения таблица имеет одно название, секционированной таблицей можно управлять так, как будто она состоит из отдельных физических файлов. В этом совете я предполагаю, что ваши возможности секционирования включают:
- перемещение секции, но не всей таблицы, на новое устройство хранения данных
- переведение секции, но не всей таблицы в off-line
- удаление и пересоздание любого индекса на секции, но не на всей таблице
- добавление, удаление и модификация записей в пределах обозначенной секции
- переименование секции
- замена секции альтернативной копией этой же секции
Ваша СУБД позволяет секционировать таблицу на основе задаваемого вами порядка сортировки. Если вы добавляете данные ежедневно, вам нужно секционировать ваши таблицы фактов на основе ключевого поля, содержащего информацию о дате. В других советах я указывал, что, если вы используете суррогатные (целочисленные) ключи, то вам нужно сделать так, чтобы суррогатные ключи в вашей таблице измерения дат были назначены в порядке естественной сортировки соответствующих им дат. При таком раскладе, если вы отсортируете вашу таблицу фактов по суррогатному ключу даты, все самые свежие записи сгруппируются в одну секцию.
Если ваша таблица фактов называется FACT, вам также понадобится не проиндексированная таблица LOADFACT. На самом деле, на всех последующих шагах мы говорим только о самой свежей секции, а не обо всей таблице фактов! Вот шаги, позволяющие сократить пребывание в режиме off-line. Мы идём в off-line на шаге 4 и возвращамся назад в on-line на шаге 7.
- Загрузите ваши вчерашние данные в секцию LOADFACT. Выполните проверку качества данных.
- После окончания загрузки сделайте копию LOADFACT и назовите её COPYLOADFACT.
- Постройте индексы по таблице LOADFACT.
- Переведите FACT в off-line (на самом деле, только наиболее свежую секцию).
- Переименуйте наиболее свежую секцию FACT в SAVEFACT.
- Переименуйте LOADFACT (секцию) в самую свежую секцию FACT.
- Переведите FACT в on-line.
- Теперь проведите чистку путём переименования COPYLOADFACT в новую LOADFACT. Вы можете продолжить загонять новые входящие данные в эту новую секцию LOADFACT.
- Если всё в порядке, можно удалить SAVEFACT.
Таким образом, мы уменьшили интервал пребывания в состоянии off-line всего к двум оставшимся операциям в шагах 5 и 6. Почти наверняка, эти операции переименования будут быстрее, если физический размер наиболее свежей секции мал, насколько это возможно.
Не вызывает вопросов то, что этот сценарий является идеализированной целью. Ваше хранилище данных будет иметь дополнительные сложности. Основные сложности, о которых вам придётся подумать это:
- ограничения на размер секции вашей СУБД
- необходимость загрузить старые, несвежие данные в вашу таблицу фактов, что сорвет предположение о «свежести»
- обработка соответствующих агрегированных таблиц фактов
Совет №28. Предотвращение катастрофических сбоев в хранилищах данных
Трагические события 11 сентября заставили нас всех пересмотреть наши возможности и приоритеты. Мы считали, что наши большие, важные здания и компьютеры, действительно, защищены просто потому, что они настолько большие и важные. Этот миф был развеян. Если что и является наиболее уязвимым, то это – эти типы зданий и компьютеров.
Опустошительное нападение на нашу инфраструктуру также было совершено в то время, когда хранилища данных большинства компаний были переведены в промышленный статус. Хранилища данных на данный момент управляют взаимодействием с клиентами и предоставляют в режиме почти реального времени статус заказов, доставки и платежей, и достаточно часто являются единственным местом сбора информации о прибыльности продуктов или клиентов. Хранилища данных стали обязательной частью многих наших предприятий.
Можно ли выполнить более качественную работу по защите наших хранилищ данных? Существует ли разновидность хранилищ данных, которые действительно защищены и менее уязвимы для последствий катастроф?
Катастрофические события
Разрушение здания – террористическая атака может уничтожить или серьезно повредить здания пожаром или затоплением. В этом крайнем случае вся инфраструктура может быть уничтожена, включая подвалы и административные сооружения.
Спланированный инсайдером саботаж – события 11 сентября показали, что тактика терроризма включает проникновение в наши системы через внедрение своих опытных сотрудников на ключевые точки контроля. Оказавшись на такой точке контроля, террорист может физически и логически уничтожить систему.
Кибератака – не будет новостью, что хакеры могут взломать защиту системы и причинить значительный ущерб. Такие события должны ликвидировать любое оставшееся наивным предположение, что подобные вторжения безобидны или даже «конструктивны», потому что выявляют дыры безопасности в наших системах. Среди наших врагов есть обученные компьютерные пользователи, которые активно пытаются получить доступ к информации, изменить информацию или отключить наши системы.
Точечные повреждения (предумышленные или нет) – последняя широкая категория катастрофических событий происходит от чрезмерной подверженности точечным повреждениям, вызванных предумышленными, или непредумышленными действиями. Если повреждение одного аппаратного узла, узла коммуникационной линии или одного человека приводит хранилище данных в неработоспособное состояние на большой период времени, то мы имеем проблемы с архитектурой.
Противостояние катастрофическим последствиям
Распределенная архитектура – наиболее эффективное и мощное средство предотвращения катастрофических последствий для хранилищ данных - это сильно распределенная архитектура. «Корпоративные хранилища данных» должны состоять из нескольких компьютеров, операционных систем, технологий баз данных, аналитических приложений, путях коммуникаций, территорий, нескольких смен персонала и процессов непрерывного копирования данных. Физически компьютеры должны располагаться в далеко расположенных друг от друга местах, идеальный случай – в разных концах страны или мира. Развертывание аппаратного обеспечения со многими независимыми узлами значительно уменьшает уязвимость хранилищ данных от саботажа, и точечных сбоев. Внедрение хранилищ данных одновременно на нескольких операционных системах (например, Linux, Unix, и NT) сильно снижает уязвимость хранилищ данных от червей, атак с помощью социальной инженерии и хакеров, использующих специфические уязвимости.
Параллельные пути коммуникации – даже распределенное хранилище данных может быть уязвимо, если оно зависит от слишком малого количества путей коммуникации. К счастью, Интернет это сложная коммуникационная сеть, которая сильно распараллелена и непрерывно подстраивается под постоянно изменяющуюся топологию. Интернет локально уязвим, если ключевые центры коммутации (там, где наиболее производительные веб-серверы подключены прямо к Интернет-каналам) подвергаются атаке. Каждая локальная команда хранилища данных должна иметь план для переключения на сеть Интернет в случае, когда локальный коммутационный центр рушится. Предоставление дополнительных мультирежимных путей доступа, таких как выделенные линии и спутниковые каналы от ваших зданий к сети Интернет также уменьшает уязвимость.
Расширение сетей хранения данных (СХД) – СХД это обычно комбинация высокопроизводительных дисковых накопителей и устройств резервного копирования, соединенных посредствам технологии высокоскоростных оптоволоконных каналов. Выгодно отличаясь от файл-сервера, кластерные дисковые накопители представляют модульный интерфейс для компьютеров, подключенных к СХД, что делает накопители доступными для подключения к системной плате каждого компьютера. СХД предоставляет как минимум три огромные возможности для больших хранилищ данных. Одна физическая СХД может быть протянута на 10 километров. Это значит что дисковые накопители, архивные системы и устройства резервирования могут быть расположены в разных зданиях на достаточно большом расстоянии. Во-вторых, резервирование и копирование может быть выполнено на скоростях диск-диск на всей СХД. И в третьих, когда все диски СХД будут объединенным ресурсом, различные приложения могут быть сконфигурированы для параллельного доступа к данным. Что наиболее существенно для «read-only» сред.
Ежедневное резервирование на носители, хранящиеся в надёжном месте - мы знаем об этом годы, но теперь пришло время рассмотреть всё это более серьезно. Не имеет значение то, какие другие средства защиты используются, но ничто другое не предоставляет защиты надёжнее, чем хранение физических носителей в безопасном месте.
Стратегически размещённые шлюзы фильтрации пакетов – необходимо изолировать ключевые серверы наших хранилищ данных таким образом, чтобы они не были прямо доступны из локальных сетей, используемых в зданиях организации. В типичной конфигурации сервер приложений составляет запросы, пересылаемые на отдельный сервер баз данных. Если сервер баз данных изолирован шлюзом фильтрации пакетов, то он может быть сконфигурирован только на прием пакетов внешнего мира приходящих с разрешенных серверов приложений. Это значит, что все другие формы доступа или запрещены или они должны быть локально подключены к серверу баз данных после шлюза. Таким образом, администратор баз данных с системными привилегиями должен иметь свой терминал, физически присоединенный к такой внутренней сети, при которой его администраторские действия и пароли вводятся в безопасном режиме и не могут быть определены перехватчиками пакетов из обычной сети здания.
Аутентификация и доступ на основе ролей – хранилищам данных наиболее просто навредить при наличии многих слишком разных путей доступа к ним, и если безопасность не контролируется централизовано. Заметьте, что я не говорю централизованно расположены, а использую понятие – централизованно контролируемы. Соответствующим решением может быть сервер LDAP (Lightweight Directory Access Protocol), контролирующий весь доступ к хранилищам данных вне шлюза. Сервер LDAP позволяет аутентифицировать всех пользователей в однообразном порядке, не обращая внимания на нахождение пользователя внутри здания или доступа с удаленного расположения. После однократной аутентификации сервер директорий сопоставляет пользователя с именованной ролью. Затем сервер приложений решает на уровне экрана, какую информацию пользователь будет видеть в зависимости от его роли. Так как хранилища данных растут до тысяч пользователей и сотен различных ролей, то преимущества такой архитектуры становятся весьма значительными.
Существует довольно много работы, которую мы можем выполнить для укрепления наших хранилищ данных. В последние несколько лет наши хранилища данных стали слишком критическими для функционирования наших организаций, чтобы оставаться настолько открытыми. Для нас прозвучал сигнал к пробуждению.
Совет №29. Грациозные модификации существующих таблиц фактов и измерений
Несмотря на наилучшие планы и хорошие намерения, разработчик хранилища данных должен часто сталкиваться с проблемой добавления новых типов данных или изменения отношений между данными, после того как хранилище данных создано и эксплуатируется. В идеальном мире нам хотелось бы, чтобы такие модификации были “грациозными”, то есть такими, чтобы существующие приложения генерации отчётов продолжали бы своё существование без необходимости их перекодирования.
Очевидно, существуют некоторые изменения, которые невозможно проделать грациозно. Если источник данных перестаёт быть доступным и для него не существует совместимой замены, то приложения, зависящие от этого источника, перестанут работать.
Но можем ли мы описать класс ситуаций, когда изменения в нашем окружении можно обрабатывать грациозно?
Предсказуемая симметрия наших многомерных моделей приходит нам на выручку. Многомерные модели способны вбирать в себя значительные изменения в исходных данных и наших предположениях, на основе которых мы выполняли проектирование, не делая непригодными наши существующие приложения. Давайте составим максимальный список этих изменений, начиная с наиболее простых.
1. НОВЫЕ АТРИБУТЫ ИЗМЕРЕНИЙ. Если, например, мы обнаруживаем новые текстовые описания продукта или клиента, мы добавляем эти атрибуты к измерению как новые поля. Все существующие приложения будут явными для новых атрибутов, и будут продолжать функционировать. Большинство интерфейсов пользователя должны обратить внимание на новые атрибуты во время работы над запросами. Концептуально, список атрибутов, доступных для наложения условий и группировки, должен отображаться в инструменте построения запросов или генерации отчётов посредством запросов в форме SELECT COLUMN_NAME FROM SYS_TABLES WHERE TABLE_NAME=’PRODUCT’. Этот тип пользовательского интерфейса постепенно “приспособится” после добавления в схему новых атрибутов измерения. В среде медленно изменяющегося измерения (SCD), где поддерживаются версии слегка изменяющихся версий измерения, необходимо проявлять осторожность, чтобы точно присвоить значения новым атрибутам для разных версий записей таблицы измерения. Если значения новых атрибутов доступны только после определённого момента времени, то в качестве значения атрибута для старых записей таблицы измерения необходимо использовать значение “недоступно”, или его эквивалент.
2. НОВЫЕ ТИПЫ ИЗМЕРЯЕМЫХ ФАКТОВ. Аналогично, если становятся доступными новые измеряемые факты, мы можем грациозно добавить их в таблицу фактов. Простейший случай - когда новые факты становятся доступными для тех же самых событий и той же самой степени детализации, что и у существующих фактов. В этом случае таблица фактов изменяется путём добавления в неё новых полей для фактов, а затем в них записываются фактические значения. В идеальном случае для добавления к существующей таблице фактов новых ролей можно использовать оператор ALTER TABLE. Если это невозможно, то нужно создать ещё одну таблицу фактов с новыми полями и скопировать в неё записи из первой. Для действительно гигантских таблиц фактов можно делать копирование большими блоками, чтобы не хранить всю гигантскую таблицу полностью в двух экземплярах. Если новые факты становятся доступными только начиная с определённого момента и дальше в будущем, необходимо записать пустые значения в предыдущие записи таблицы фактов. Новые приложения, использующие новые факты, должны вести себя разумно, даже если они встретят пустые записи. Пользователям необходимо сообщить о том, что новые факты доступны только с определённого момента.
Более сложная ситуация получается, если новые недоступны во время события замера старых фактов, или если новые факты имеют другую степень детализации. Если новые факты нельзя распространить на первоначальную степень детализации таблицы фактов, существует большая вероятность того, что новые факты принадлежат своей собственной таблице фактов. Смешивание степени детализации или смешивание несовместимых видов величин в одной таблице фактов почти всегда является ошибкой. Если вы в такой ситуации, вам нужно найти инструмент, способный генерировать многопроходный SQL, способный делать выборку из нескольких таблиц фактов в ответ на запрос пользователя. Такие инструменты, как Cognos, Business Objects и Microstrategy способны управляться с многопроходным SQL.
3. НОВЫЕ ИЗМЕРЕНИЯ. Новое измерение можно добавить к существующей таблице фактов путём добавления нового поля, являющегося внешним ключом, и заполнения его значениями первичного ключа нового измерения. Например, можно добавить измерение погода к таблице фактов розничных продаж, если в наличии имеется источник, описывающий погоду, например, в каждом месте, где располагаются магазины, за каждый день. Заметьте, что мы не изменяем степени детализации таблицы фактов. Если информация о погоде доступна только начиная с какого-то момента времени, то значение внешнего ключа для предыдущих моментов должны указывать на запись в таблице измерения ПОГОДА, поле описания которой содержит строку “информация о погоде недоступна”.
4. ИЗМЕРЕНИЯ, КОТОРЫЕ СТАНОВЯТСЯ БОЛЕЕ ДЕТАЛЬНЫМИ. Иногда желательно увеличить степень детализации измерения. Например, таблицу фактов розничных продаж с измерением МАГАЗИН можно было бы изменить с целью замены измерения МАГАЗИН на измерение КАССА. Если у нас 100 магазинов, в каждом из которых в среднем около 10 касс, то новое измерение КАССА будет иметь 1000. Все атрибуты магазина, присутствовавшие в первоначальном измерении, будут включены в измерение КАССА, поскольку кассы отлично соответствуют магазинам в отношении многие-к-1. Атрибуты магазина также можно моделировать физически с помощью консольной таблицы измерения вида “снежинка”, присоединённой к таблице измерения КАССА. Заметьте, что когда мы увеличиваем степень детализации измерения МАГАЗИН-КАССА, мы должны увеличить степень детализации таблицы фактов. В нашем примере таблица фактов становится в 10 раз больше. Вероятно, не существует другого решения, как только удалить таблицу фактов и построить её заново. Несмотря на то, что это измерение большое и сложное, оно элегантно! Все существующие приложения останутся незатронутыми. Все итоговые данные по магазинам останутся неизменными, а все запросы будут возвращать те же самые результаты. Скорость работы может упасть из-за увеличения количества записей в таблице фактов, но весьма вероятно, что мы, всё равно, построим агрегированную таблицу уровня магазина! В первоначальном виде это была бы таблица фактов, теперь же она будет анонимной агрегированной таблицей.
5. ДОБАВЛЕНИЕ ЯВНОЙ ИЕРАРХИИ, СВЯЗЫВАЮЩЕЙ ДВА ИЗМЕРЕНИЯ. Например, в страховании у нас может быть измерения полис и клиент. Если каждый полис относится строго к одному клиенту, тогда полис является дочерним элементом клиента. Однако мы, скорее всего, не включили бы информацию о клиентов измерение полис, потому что измерение клиент, несомненно, будет одним из основных самостоятельных измерений, которое будет соединено со множеством таблиц фактов, во множестве случаев при этом измерение полис не будет иметь смысла. Несмотря на эту потребность разделения измерений, некоторые разработчики добавляют полезный ключ CustomerPolicy к некоторым таблицам фактов, где новое измерение CustomerPolicy является комбинацией измерений клиент и полис. Это измерение содержит комбинации клиентов и полисов. К нему можно в любое время надёжно адресовать запросы для исследования этого отношения вне зависимости от наличия какой-либо таблицы фактов. Добавление ключа этого нового комбинированного измерения порождает те же проблемы администрирования, как и в случае добавления нового измерения, что описано в пункте 3 выше. Поскольку это просто новое измерение, оно проходит тест на элегантность.
6. ДОБАВЛЕНИЕ АБСОЛЮТНО НОВОГО ИСТОЧНИКА ДАННЫХ, ЗАТРАГИВАЮЩЕЕ СУЩЕСТВУЮЩИЕ ИЗМЕРЕНИЯ, А ТАКЖЕ ДОБАВЛЯЮЩЕЕ НЕОЖИДАННЫЕ НОВЫЕ ИЗМЕРЕНИЯ. Почти всегда новый источник данных имеет свою собственную гранулярность и свои собственные измерения. Все вы многомерные дизайнеры знаете ответ на эту задачу. Мы заводим новую таблицу фактов. Поскольку никакие из существующих таблиц фактов и измерений остаются незатронутыми, по определению, все существующие приложения будут продолжать работать. Несмотря на то, что этот случай кажется почти тривиальным, смысл здесь заключается в том, чтобы не допустить втискивания новых показателей в существующие таблицы фактов. Одна таблица фактов всегда владеет одним видом измерения показателей, которые имеют унифицированный уровень детализации.
Совет №30. Посадите ваши таблицы фактов на диету
В середине 90х годов, когда ещё не было Интернета, выяснилось, что, в конечном счёте, может наступить взрыв данных. В то время мы учились как сохранять информацию о каждом телефонном звонке, каждом товаре, выбитом в кассовом чеке, каждой транзакции с ценными бумагами, проведённой на Уолл Стрит и о каждом страховом случае в гигантских страховых компаниях. Действительно, правда, что мы не хранили длинные временные ряды этих данных в наших хранилищах данных, но у нас было чувство, что мы, возможно, достигли физического лимита детальности данных. Возможно, мы, наконец, нашли истинные «атомы» данных.
Да, это представление, было, очевидно, неверным. Теперь мы знаем, что не существует предела количества данных, которые мы можем собирать. Каждое измерение величины может быть заменено на целый ряд более детальных измерений величин. В среде web, в web-журналах мы можем видеть каждое движение, совершённое посетителем ДО совершения им покупки товара. Мы уже заменили единственную запись о покупке товара десятком или сотней записей, отслеживающих поведение. Самая большая неприятность заключается в том, что наши специалисты по маркетингу любят эти записи, отслеживающие поведение, и хотят выполнять над ними разнообразные виды анализа.
Подождите немного до того момента, когда системы GPS будут встроены в наши автомобили, кредитные карты и телефоны. Каждый человек, в конечном счете, мог бы генерировать одну или более записей каждую секунду 24 часа в сутки!
Хотя мы не можем остановить эту лавину данных, мы должны попытаться управлять ею, в противном случае мы будем тратить слишком много денег на дисковые системы. Многие наши текущие планы по росту объёмов данных основаны на быстрых оценках. Во многих случаях эти оценки чересчур завышены по сравнению с нашими реальными потребностями. Решением может стать покупка слишком большого количества дисков, или отмена планов по анализу доступных данных.
В мире многомерного моделирования нетрудно видеть, что обвиняемым всегда является таблица фактов. В таблице фактов хранятся записи о частых замерах величин, характеризующих наш бизнес. Таблица фактов окружена на порядок меньшими по размерам таблицами измерений. Даже гигантская таблица измерения КЛИЕНТ, содержащая миллионы записей, будет меньше, чем самая большая таблица фактов.
Фанатично уделяя внимание проектированию наших таблиц фактов, мы можем сделать их значительно более стройными. Вот руководство к действию:
- Замените все естественные внешние ключи самыми маленькими возможными целочисленными (суррогатными) ключами.
- Как часть п. 1, замените все поля типа дата/время на целочисленные суррогатные ключи.
- Объедините связанные измерения в одно измерение, где это возможно.
- Сгруппируйте крошечные измерения с низкой кардинальностью в одно измерение, даже если они и не связаны.
- Уберите все текстовые поля из таблицы фактов. Сделайте их измерениями. В особенности поля с комментариями.
- Где возможно, замените все длинные целые числа и числа с плавающей точкой на масштабированные целые.
В качестве примера, предположим, что мы работаем в большой телефонной компании, обрабатывающей 300 миллионов телефонных звонков в день. Мы могли бы легко оценить потребности в дисковом пространстве, необходимом для хранения данных за период в три года на основе следующих предположений:
Date/Time = 8 byte date-time stamp
Calling Party Phone Number = 10 byte string
Called Party Phone Number = 15 byte string (для обработки международных номеров)
Local Provider Entity = 10 byte string
Long Distance Provider Entity = 10 byte string
Added Value Service Provider Entity = 10 byte string
Dialing Status = 5 byte string (100 возможных величин)
Termination Status = 5 byte string (100 возможных величин)
Duration fact = 4 byte integer
Rated Charge fact = 8 byte float
При таком дизайне каждая запись о звонке занимает 85 байт. Хранение этих сырых данных без индексов потребует 27,9 терабайт. В предположение, что данные приходят непрерывным потоком, нам нужно будет добавлять по 776 гигабайт дискового пространства каждый месяц для хранения только сырых данных! Очевидно, в записи, приведённой выше, присутствует избыточный жир. Давайте-ка до конца закрутим гайки и посмотрим, что мы можем из неё выжать. Используя приведённые выше рекомендации, мы можем закодировать ту же самую информацию следующим образом:
Date = 2 byte tiny integer
Time of Day = 2 byte tiny integer
Calling Party Phone Number = 4 byte integer surrogate key
Called Party Phone Number = 4 byte integer surrogate key
Local Provider Business Entity = 2 byte tiny integer surrogate key
Long Distance Provider Entity = 2 byte tiny integer surrogate key
Added Value Service Provider = 2 byte tiny integer surrogate key
Status = 2 byte tiny integer surrogate key (комбинация Dialing и Termination)
Duration fact = 4 byte integer
Rated Charge fact = 4 byte scaled integer
Мы сделали несколько предположений относительно типов данных, поддерживаемых вашей СУБД. Мы предположили, что для хранения ключей измерений достаточно двухбайтных целых чисел в диапазоне от 0 до 65535.
При этом дизайне пространство, необходимое для хранения сырых данных в нашей таблице фактов составит 9,2 терабайт, экономия достигает 67%! Ежемесячный рост данных при этом составит 256 гигабайт.
Совет №31. Проектируем партицию реального времени
(выдержка из статьи, которая должна была появиться в журнале Intelligent Enterprise)
Несмотря на то, что временной разрыв между промышленными транзакционными системами и хранилищами данных сократился в большинстве случаев до 24 часов, ненасытные маркетинговые пользователи требуют, чтобы хранилище данных наполнялось данными в режиме реального времени.
Большинство разработчиков хранилищ данных скептически относятся к возможностям ускорения существующих ETL-процессов (extract transform load) с 24-часового цикла до цикла в 15 минут. Разработчики хранилищ данных отвечают на это требование созданием партиции реального времени рядом с обычным статическим хранилищем данных.
Требования к партиции реального времени
Для достижения целей создания отчётов в режиме реального времени мы строим отдельную партицию, которая физически и административно отделена от обычных статических таблиц хранилища данных. Партиция реального времени фактически является отдельной таблицей, подчиняющейся особым правилам обновления и особым правилам построения запросов.
Партиция реального времени в идеале должна подчиняться следующим требованиям. Она должна:
- регистрировать все события, происходящие с момента последней загрузки статического хранилища данных
- насколько возможно иметь ту же степень детализации, что и таблицы фактов хранилища
- быть настолько легко проиндексированной, что входящие данные могут постоянно заводиться в неё
-
поддерживать высокую производительность при выполнении запросов
В мире многомерного моделирования существует три основных типа таблиц фактов: транзакционная таблица, периодические снимки и аккумулирующие снимки. Наша партиция реального времени имеет различную структуру, соответствующую каждому из этих типов.
Транзакционная партиция реального времени
Если таблица фактов статического хранилища данных объявлена на уровне транзакций, то она содержит ровно по одной записи для каждой отдельной транзакции в системах-источниках, начиная с самого начала «зарегистрированной истории». Партиция реального времени имеет абсолютно такую же структуру, что и соответствующая статическая таблица фактов. Она содержит только транзакции, произошедшие с полуночи, когда мы выполнили регулярную загрузку таблиц хранилища данных. Партиция реального времени практически не должна иметь индексов, поскольку нам нужно иметь постоянно «открытое окно» для загрузки. Мы избегаем построения агрегатов на этой таблице, поскольку мы желаем применить минималистский подход в отношении администрирования в течение дня.
Мы присоединяем нашу партицию реального времени к нашим существующим приложениям посредством выполнения операции drill across из статической таблицы фактов к партиции реального времени. Агрегации временных рядов (например, все продажи за текущий месяц) потребуют выполнения идентичных запросов к двум таблицам с последующим сложением результатов.
В сравнительно большой системе в области розничной торговли, где выполняется порядка 10 миллионов транзакций в день, статическая таблица фактов будет довольно большой. Предположив, что каждая запись о транзакции занимает 40 байт (7 измерений плюс 3 факта, всё упаковано в поля по 4 байта), мы будем собирать по 400 МБ данных ежедневно. В течение года это составит около 150 ГБ сырых данных. Такая таблица фактов будет сильно проиндексирована, и будет поддерживаться агрегированными таблицами. Но ежедневная порция в 400 МБ (партиция реального времени) могла бы размещаться в оперативной памяти. Забудьте про индексы, возможно, за исключением индекса B-Tree на первичном ключе для поддержки операций вставки! Забудьте про агрегаты!
Наша партиция реального времени может больше склоняться к обеспечению быстрой загрузки, при этом обеспечивая высокую производительность выполнения запросов.
Партиция реального времени периодических снимков
Если статическая таблица фактов хранилища данных имеет периодический уровень детализации (скажем, месяц), то партиция реального времени может выглядеть как текущий скользящий месяц. Предположим, что мы – большой розничный банк с 15 миллионами счетов.
Статическая таблица фактов имеет степень детализации счёт/месяц. Временной ряд из 36 месяцев будет состоять из 540 миллионов значений таблицы фактов. И снова, эта таблица будет сильно проиндексирована и будет поддерживаться агрегатами с тем, чтобы обеспечивать высокую производительность. Партиция реального времени, с другой стороны, это текущие данные текущего месяца, обновляемые ежедневно в течение месяца. Полуаддитивные балансы и полностью аддитивные факты обновляются с необходимой для выполнения отчётов частотой. В розничном банке «базовая» таблица фактов, содержащая информацию обо всех счетах, будет, скорее всего, достаточно узкой, и, возможно, будет содержать 4 измерения и 4 факта, что даёт партицию реального времени размером в 480 МБ. И опять, партиция реального времени может быть размещена в оперативной памяти.
Операция drill across из статической таблицы фактов к партиции реального времени будет иметь логику, немного отличную от логики в случае с транзакционной таблицей фактов. Несмотря на то, что тренды по балансам и другим мерам интенсивности можно строить напрямую на двух таблицах, аддитивные итоги, накапливаемые в течение текущего периода, возможно, придётся спроецировать вперёд до эквивалента всего месяца с тем, чтобы результаты не выглядели аномально.
Наконец, мы надеемся, что в последний день месяца данные из партиции реального времени можно будет перегрузить в статическое хранилище данных на место самого последнего месяца, и начать процесс снова с пустой партиции реального времени.
Партиция реального времени аккумулирующих снимков
Аккумулирующие снимки используются для процессов с коротким жизненным циклом, наподобие размещения заказов и выполнения отгрузок. Для каждой позиции заказа или накладной создают запись. В главной таблице фактов эта запись постоянно обновляется по мере наступления событий. Мы создаём запись для позиции, когда заказ впервые размещается, затем мы обновляем её, когда товар отгружается, в момент произведения оплаты, или в момент возврата. Таблицы фактов аккумулирующих снимков содержат внешние ключи, представляющие даты наступления каждого из этих событий.
В данном случае называть главную таблицу хранилища данных «статической» будет неправильным, поскольку это единственный вид таблиц фактов, которые постоянно, зачастую многократно, обновляются. Но, давайте предположим, что с целью повышения производительности запросов эти обновления происходят только в то время, когда пользователи не подключены к системе. В этом случае партиция реального времени будет состоять только из строк для тех позиций, которые обновлялись сегодня. В конце дня записи в партиции реального времени будут являться в точности новыми версиями записей, которые нужно будет записать в главную таблицу фактов посредством вставки новых записей или заменой существующих записей с теми же первичными ключами.
Во многих ситуациях с заказами и поставками количество строк в партиции реального времени будет значительно меньше, чем в двух предыдущих примерах. Например, крупнейший в США производитель корма для собак и кошек обрабатывает около 60 000 счетов в месяц. Каждый счёт может иметь до 20 позиций. Если позиция счёта имеет нормальную продолжительность жизни в два месяца и обновляется в течение этого интервала пять раз, то мы увидим около 7500 позиций, создаваемых и обновляемых в течение среднего рабочего дня. Даже в случае достаточно широкой записи размером в 80 байт, типичной для таблиц фактов счетов, наша партиция реального времени будет содержать всего 600 КБ данных. Этот объём, очевидно, поместится в оперативную память. Забудьте об индексах и агрегатах для этой партиции реального времени.
Запросы к аккумулирующим снимкам с партицией реального времени должны выбирать соответствующие строки, как из главной таблицы фактов, так и из партиции, и могут либо выполнять операцию drill across между двумя таблицами посредством короткого внешнего соединения по идентичным заголовкам строк, либо выполнять объединение строк из двух таблиц, представляя статическую картину, обогащённую дополнительными строками, представляющими важные сегодняшние события.
В этой статье я описал то, что я считаю сильным бизнес-сценарием для удовлетворения новых требований к анализу в реальном времени посредством специально разработанных, но, тем не менее, уже знакомых, расширений наших существующих таблиц фактов. Если вы удалите почти все индексы и агрегаты у этих таблиц, и разместите их в оперативной памяти, вы должны получить высокую производительность обновления и ответов на запросы, которая вам требуется.
Совет №32. Выполняем работу на этапе извлечения данных
Наша миссия дизайнеров хранилища данных заключается в наиболее эффективной публикации данных. Это означает перевод данных в формат и в схему, наиболее лёгкие для использования конечными пользователями и разработчиками приложений.
В бэк-офисе нашего хранилища данных мы должны противостоять нашим естественным минималистским тенденциям, когда мы готовим данные для потребления конечными пользователями и разработчиками приложений. Во многих важных случаях мы должны взвешенно искать компромисс между:
- возрастающей бэк-офисной обработкой и
- возрастающими требованиями к фронт-офисному пространству для хранения
- взамен на:
- симметричные предсказуемые схемы, доступные для понимания конечными пользователями,
- меньшую сложность приложений и
- улучшенную производительность запросов и отчётов.
Поиск этих компромиссов должен быть явной целью проектирования для архитектора хранилища данных. Хороший архитектор хранилища данных будет сопротивляться порыву возложить на пользователей и разработчиков приложений дополнительный анализ и манипулирование таблицами. Опасайтесь поставщиков, предлагающих сложные схемы! Но, естественно, эти компромиссы должны быть выбраны благоразумно и без крайностей. Давайте посмотрим на несколько ситуаций, где мы выполняем достаточное количество работы на этапе извлечения данных, чтобы, действительно, почувствовать большую разницу. Мы также попытаемся очертить некоторые границы с тем, чтобы не перестараться и не испортить окончательный результат. Мы начнём с нескольких достаточно узких примеров, и постепенно расширим наши рамки.
Моделирование событий в нескольких часовых поясах
Практически все измеряемые величины записываются в наше хранилище данных с одной или несколькими временными отметками. Иногда они представляют собой просто календарные даты, но всё больше мы начинаем записывать и время с точностью до минут и секунд. Помимо этого, наши предприятия, как правило, работают в нескольких часовых поясах, в Соединённых Штатах, Европе или Азии, или по всему миру. В таких случаях перед нами предстаёт естественная диллема. Либо мы стандартизуем все наши временные отметки и приводим их к единому хорошо определённому часовому поясу, или мы приводим все наши временные отметки к местному времени возникновения события. Если мы хотим выполнять преобразование из GMT к местному времени, возможно, нам нужно выяснить в каком часовом поясе был сделан замер, и применить простое смещение. К сожалению, это не работает. Фактически, это замечательным образом приводит к провалу. Правила международных часовых поясов ужасно запутаны. Существует более 500 различных географических областей со своими собственными правилами образования часовых поясов. Мораль истории такова: не проводите вычислений часовых поясов в вашем приложении, добавьте лучше дополнительный внешний ключ со ссылкой на временную отметку везде, где у вас есть существующая временная отметка, и сохраните ОБА времени в ваших данных – стандартное и местное. Другими словами, проведите эту работу во время извлечения данных, и поступитесь небольшим количеством дискового пространства.
Многословные календарные измерения
Все таблицы фактов многомерных хранилищ данных должны остерегаться присутствия явных календарных дат в пользу целочисленных внешних ключей, ссылающихся на многословные календарные измерения. Эта рекомендация основана не на тупом следовании концепции консистентности многомерного дизайна, а на осознании того, что календари сложны, а приложениям необходима помощь в навигации. Например, «родные» для SQL временные отметки не определяют, является ли день последним днём месяца. При использовании правильного календарного измерения последний день месяца можно определить как булев флаг, упрощая при этом приложения. Только вообразите себе написание запроса на основе простой даты SQL, который должен выполнить ограничение по последним дням каждого месяца. Это пример того, как добавление механизма к явному календарному измерению упрощает запросы и ускоряет обработку за счёт избавления от сложного SQL.
Ведение книг в нескольких валютах
Случай с часовыми поясами, рассмотренный в первом примере, часто повторяется в похожей проблеме моделирования транзакций в нескольких валютах. И снова, у нас возможность выбора из двух равноправных законных вариантов. Если транзакция случилась в определённой валюте (скажем, в швейцарских франках), мы, очевидно, хотим сохранить в точности эту информацию. Но если у нас неразбериха с валютами, то довольно сложно просуммировать результаты и получить международный итог. Снова мы применяем похожий подход, расширяя каждую денежную величину до двух полей – значения в местной валюте и значения в стандартной валюте. В данном случае нам также необходимо добавить измерение Валюта к каждой таблице фактов для того, чтобы безошибочно определить местную валюту. Место совершения транзакции не является надёжным индикатором типа местной валюты.
Противопоставление единиц измерения в продуктовой цепочке
Многие из нас думают, что метрики продуктовой цепочки достаточно просты, и не имеют сложности, присущей, например, финансам. Тогда проведите некоторое время с людьми из производства, сбытовиками и розничными торговцами, каждый из которых говорит об одних и тех же продуктах в одной и той же цепочке. Люди с производства хотят видеть всё в машинах и палетах. Сбытовики хотят всё видеть в количестве отгрузок. Розничные торговцы заинтересованы только в количестве сосканированных единиц. Так, что же вам поместить в разные таблицы фактов, чтобы все были счастливы? НЕПРАВИЛЬНЫЙ ответ заключается в публикации каждого факта в своей локальной единице измерения и перекладывании на приложение работы по поиску правильных коэффициентов для перевода в таблицах измерений продуктов! Да, теоретически всё это возможно, но эта архитектура даёт неразумную нагрузку на последний шаг обработки, где живут конечные пользователи и разработчики приложений. Вместо этого представьте все измеряемые факты в единой стандартной единице измерения, а затем в самой таблице фактов разместите коэффициенты преобразования во все необходимые единицы измерения. Таким образом, приложения, запрашивающие данные о цепочке, в любом случае будут иметь непротиворечивый способ конвертации всех числовых значений в характерные для конечного пользователя единицы измерения.
Физическое завершение дизайна прибылей и убытков (P&L)
Таблица фактов прибылей и убытков является очень мощной, поскольку предоставляет все компоненты доходов и расходов (возможно) с низким уровнем детализации. После предоставления этого замечательного уровня детальности проектировщики иногда компрометируют свой дизайн, не предоставляя всех промежуточных уровней P&L. Например, чистая прибыль вычисляется путём вычитания расходов из чистых доходов. Эта чистая прибыль должна быть явным полем в данных, даже если она равна алгебраической сумме других полей в той же самой записи. Было бы, действительно, очень жаль, если бы пользователь или разработчик приложения запутался бы на последнем шаге, и рассчитал бы чистую прибыль неправильно.
Гетерогенные продукты
В финансовых отраслях, таких как банки и страхование часто возникает характерный конфликт между необходимостью видеть все счета в едином представлении «домохозяйства» клиента, и необходимостью видеть детальные атрибуты и метрики каждого типа счёта. В большом розничном банке может быть 25 бизнес-направлений и более 200 специальных метрик, относящихся ко всем различным типам счетов. Вы просто не можете создать гигантскую таблицу фактов и гигантскую таблицу измерения, которые могут вместить все гетерогенные продукты. Решение заключается в публикации данных дважды. Сначала создайте единую базовую таблицу фактов всего с четырьмя или пятью метриками, такими как остаток, которые будут общими для всех типов счетов. Затем опубликуйте данные вторично с отдельными таблицами фактов и таблицами измерений для каждого из 25 бизнес-направлений. Хотя это может показаться расточительным, поскольку гигантская таблица фактов фактически публикуется дважды, это предоставляет разделить приложения для «домохозяйств» и бизнес-направлений.
Агрегаты в целом
Агрегаты похожи на индексы: они представляют собой специальные структуры данных для повышения производительности. Агрегаты являются значительным отвлекающим фактором в бэк-офисной обработке. Они потребляют процессорные ресурсы, добавляют сложности к ETL, а также потребляют массу дискового пространства. НО, агрегаты остаются единственным мощным инструментом в арсенале проектировщика хранилищ данных, позволяющим эффективно поднять производительность.
Многомерное моделирование в целом
Теперь я надеюсь, что стал очевидным факт, что наиболее частый компромисс бэк-офисной обработки, использующийся для пользы конечного пользователя – это практика многомерного моделирования. Многомерная модель – это вторая нормальная форма от модели в третьей (или высшей) нормальной форме. Схлопывание снежинок и других сложных структур моделей более высших нормальных форм в характерные плоские таблицы измерений делает дизайны простыми, симметричными и понимаемыми. Более того, поставщики СУБД смогли сфокусировать свои алгоритмы обработки на этом хорошо понимаемом примере, чтобы заставить многомерные модели работать действительно быстро. В противоположность другим техникам, рассмотренным в этом совете, подход многомерного моделирования можно применять практически во всех горизонтальных и вертикальных приложениях.
Совет №33. Использование метрик CRM в качестве поведенческих тегов
Давайте опишем простой классический пример присвоения поведенческих тегов сложным шаблонам микро-транзакций, порождаемых нашими процессами взаимодействия с клиентами, например, звонками контактного центра, посещениями веб-сайта, системами доставки, а также платёжными системами. Мы воспользуемся нашими стандартными методами отчётности для хранилища данных чтобы просуммировать три метрики, описывающие поведение клиента: свежесть (recency), частота (frequency), и интенсивность (intensity). Свежесть – это мера того, как давно мы взаимодействовали с клиентом. Давайте взглянем широко, и посчитаем все транзакции, порождаемые процессами взаимодействия с клиентами, упомянутыми выше. Действительное значение метрики свежести – это количество дней, прошедших с момента последнего контакта с клиентом.
Подобным образом, частота – это мера того, как часто мы взаимодействовали с клиентом, опять-таки в широком понимании всех процессов взаимодействия с клиентом. И, наконец, интенсивность – это числовая величина, характеризующая то, насколько продуктивным было взаимодействие. Наиболее очевидным показателем интенсивности является сумма, потраченная на покупки, но, мы можем думать, что общее количество веб-страниц, которые посетил клиент – это тоже хороший показатель интенсивности.
Все метрики RFI (recency, frequency, intensity) можно подразделить на различные метрики для каждого процесса взаимодействия с клиентом, но мы сохраним этот пример простым.
Теперь посчитаем для каждого клиента их метрики RFI для скользящего периода времени, такого как последний месяц. В результате получится три числа. Можно вообразить отображение результатов RFI в виде трёхмерного куба с осями Recency, Frequency, и Intensity.
Теперь обратимся к нашим коллегам по data mining и попросим их найти естественные кластеры в этом кубе. В действительности, нам не нужны все числовые результаты: нам нужны поведенческие кластеры, которые, которые будут иметь смысл для нашего департамента маркетинга. После запуска алгоритма кластеризации средства data mining, мы найдём, например, что существует восемь кластеров клиентов. После изучения того, в каких местах нашего RFI-куба находятся центроиды кластеров, мы сможем дать поведенческие описания каждому из восьми поведенческих кластеров:
A: Высокодоходные постоянные клиенты, хороший кредит, малое количество возвратов товара
B: Высокодоходные постоянные клиенты, хороший кредит, но большое количество возвратов товара
C: Новые клиенты, кредитной истории нет
D: Непостоянный клиент, хороший кредит
E: Непостоянный клиент, плохой кредит
F: Бывший хороший клиент, в последнее время не появлялся
G: Любитель часто поглазеть на витрины, в основном, непродуктивный
H: Прочие
Мы можем рассматривать теги от A до H как текстовые факты, суммирующие поведение клиентов. В хранилищах данных небольшое количество текстовых фактов, но эти поведенческие теги, похоже, представляют собой хороший пример. Можно разработать временной ряд поведенческих тегов для клиента – каждый месяц по одному измерению.
Василий Пупкин: C C C D D A A A B B
Что можно сказать об этом временном ряде? Мы успешно преобразовали Василия Пупкина из нового клиента в непостоянного клиента, а далее в очень желательного высокодоходного постоянного клиента. Но в последние месяцы мы замечаем, что Василий проявляет склонность к возврату товаров. Это недавнее поведение не только порождает издержки, но и заставляет нас беспокоиться о том, что Василий может разочароваться в наших товарах и в конечном счёте попасть в поведенческую категорию F!
Этот небольшой временной ряд достаточно хорошо открывает нам глаза. Как же нам структурировать наше хранилище данных, чтобы иметь возможность выкачивать такие отчёты? И как нам накладывать интересные ограничения на клиентов, чтобы видеть только тех, которые за последнее время переместились из кластера A в кластер B?
Мы можем моделировать этот временной ряд текстовых поведенческих тегов несколькими различными способами. Каждый подход обеспечивает наличие идентичной информации, но они значительно отличаются по лёгкости использования. Давайте предположим, что мы генерируем по одному новому поведенческому тегу ежемесячно для каждого клиента. Вот эти три способа:
- Запись в таблице фактов для каждого клиента в каждый месяц, поведенческий тег моделируется как текстовый факт.
- Медленно изменяющееся измерение Клиент (Type 2), поведенческий тег выступает в качестве атрибута (поля). Ежемесячно для каждого клиента создаётся новая запись в таблице измерения. Такое же количество новых записей ежемесячно, как и в случае №1.
- Одна запись о клиенте в таблице измерения с временным рядом из поведенческих тегов за 24 месяца, хранящимся в 24 атрибутах.
Как способ 1, так и способ 2 имеют проблему, заключающуюся в том, что каждый новый поведенческий тег для каждого клиента хранится в различных записях. Несмотря на то, что простой подсчёт будет работать хорошо в обоих этих случаях, сравнения и ограничения будет делать трудно. Например, поиск клиентов, перешедших из кластера A в кластер B в последнем периоде, был бы затруднён в реляционной базе, поскольку не существует простого способа применить a «ограничение с широко расставленными ногами» на две записи сразу.
В этом примере на нас сильно влияет предсказуемая периодичность данных. Каждый клиент профилируется ежемесячно. Поэтому, даже если поведенческий тег является разновидностью текстового факта, вырисовывается, что выбор дизайна номер является довольно эффективным. Помещение временного ряда из поведенческих тегов в каждую запись о клиенте имеет три больших преимущества. Во-первых, значительно сокращается количество генерируемых записей, поскольку новый поведенческий тег сам по себе не генерирует новой записи. Во вторых, сложные ограничения выполнить достаточно просто, поскольку соответствующие поля находятся в одной и той же записи. И, в-третьих, мы можем легко ассоциировать сложные ограничения с нашим полным портфелем клиентских таблиц фактов посредством простого соединения с таблицей измерения Клиент.
Конечно же, моделирование временного ряда как набора полей измерения Клиент имеет недостаток в том, что как только у вас закончатся ваши 24 поля, вам, возможно, понадобится изменить таблицу измерения, чтобы добавить туда новые поля. Но в сегодняшней быстро изменяющейся среде, вам, возможно, понадобится вносить и другие изменения в это же самое время! По крайней мере, этот изменение является «элегантным», поскольку не влияет на существующие приложения.
Мы преуспели в усушке терабайтов транзакционных поведенческих данных в простой набор тегов с помощью наших коллег по технологиям data mining. Далее мы упаковали теги в очень компактный и полезный формат, который поддерживает наши высокоуровневые цели – лёгкость использования и лёгкость разработки приложений. Теперь мы готовы выкачивать различные виды интересного поведенческого анализа для наших конечных пользователей из подразделения маркетинга.
Совет №34: Вам не нужно КХД
КХД (EDW) расшифровывается как корпоративное хранилище данных, но, более того, это название подхода проектирования. Подход КХД отличается материально от подхода Архитектуры Шины Хранилища Данных (DW Bus Architecture). КХД заключает в себе ряд связанных тем, каждую из которых нужно индивидуально противопоставить подходу Шины ХД. Возможно, будет полезно на момент отделить логические вопросы от физических.
Логически оба подхода пропагандируют согласованный набор определений, рационализирующих различные источники данных (source system), разбросанные по организации. В случае Шины ХД, согласованный набор определений принимает специфическую форму согласованных измерений (conformed dimensions) и согласованных фактов (conformed facts). В подходе КХД согласованность кажется более бесформенной. Вы должны принять на веру, что если у вас будет единая сильно нормализованная ER-модель всей корпоративной информации, то вы будете знать, как согласованно администрировать сотни или тысячи таблиц. Но, в отсутствие должной точности, можно привести доводы в пользу того, что оба подхода пока согласуются друг с другом. Оба подхода стремятся применить унифицирующую связь ко всем распределённым источникам данных.
Побочной проблемой корпоративной модели данных КХД является то, что часто эти модели являются идеализированными информационными моделями, а не реальными моделями источников данных. Несмотря на то, что создание идеализированной модели полезно, я видел ряд этих больших диаграмм, которые никогда не наполняются. Я также написал ряд статей в попытке пролить свет на соответствующие заявления о том, что большие нормализованные модели инкапсулируют «бизнес-правила» организации. В самом лучшем случае, нормализованные модели реализуют НЕКОТОРЫЕ из правил ДАННЫХ (в основном, отношения многие-к-1), и почти НИЧЕГО из того, что эксперт по бизнес-процедурам назвал бизнес-правилами. Наименования путей соединения таблиц на ER-диаграмме (ER-diagram) редко, если когда-либо вообще, переносится в код бэк-офисных ETL-процессов или фронт-офисных инструментов построения запросов и генерации отчётов.
Даже если мы достигли слабого соглашения относительно того, что оба подхода имеют одну и ту же цель согласованного представления данных организации, как только мы погружаемся в проблемы физического дизайна (physical database design) и внедрения, различия между подходами КХД и шиной ХД начинают бросаться в глаза.
Как многие из вас знают, согласованные измерения и согласованные факты принимают специфические формы в архитектуре Шины ХД. Согласованные измерения – это измерения (dimension), у которых есть общие поля, и соответствующие домены (domain) значений этих полей одинаковы. Это даёт гарантию, что вы сможете выполнять отдельные запросы по удалённым таблицам фактов, присоединённым к этим измерениям, и сможете слить столбцы в финальный результат. Конечно же, это операция drill across. Я довольно много писал о шагах, требующихся для администрирования согласованных измерений и согласованных фактов в среде распределённых хранилищ данных (distributed DW). Я никогда не видел сравнимого набора специфических рекомендаций в подходе КХД. Я нахожу это интересным, поскольку даже в физически централизованном КХД вы должны хранить данные в физически отдельных табличных пространствах (table space), а это требует прохождения через ту же логику, что и при репликации (replication) согласованных измерений. Но, я никогда не видел системного описания подобных процедур у сторонников подхода КХД. Какие таблицы нужно синхронно реплицировать между табличными пространствами и когда? Процедуры Шины ХД описывают это очень детально.
Плоская природа таблиц измерений во 2НФ (2NF) при дизайне Шины ХД позволяет нам администрировать естественную изменчивость измерения предсказуемым способом (SCD1, SCD2, SCD3).
И снова, в сильно нормализованном мире КХД я никогда не видел описание того, как создать эквивалент медленно изменяющихся измерений. Но, вероятно, это потребует обширного использования временных отметок во всех сущностях (entity) вместе с большими, нежели чем при многомерном моделировании (multidimensional modeling), усилиями по администрированию ключей. Между прочим, подход к суррогатным ключам (surrogate key), который я описал для администрирования медленно изменяющихся измерений (slowly changing dimensions), вообще говоря, не имеет ничего общего с многомерным моделированием. В КХД корневая таблица превращённого в снежинку «измерения» должна будет подвергаться тому же администрированию ключей в том же объёме (с использованием либо суррогатного ключа, либо сочетания естественного ключа (natural key) и даты) с тем же самым количеством повторяющихся записей, как и при отслеживании тех же медленных изменений в версии Шины ХД.
Плоская природа таблиц измерений во 2НФ при дизайне Шины ХД позволяет использовать системный подход при определении агрегатов (aggregate data), единственного наиболее мощного и эффективного по затратам метода повышения производительности большого хранилища данных. Наука приёмов многомерной агрегации тесно связана с использованием согласованных измерений. «Съёжившиеся» измерения агрегированной таблицы фактов являются отлично согласованными подмножествами базовых измерений в архитектуре Шины ХД. Подход КХД, опять же, не имеет системного и документированного подхода к обработке агрегатов в нормализованной среде, или в предоставлении руководства для инструментов генерации запросов или разработчикам отчётов относительно того, как использовать агрегаты. Эта проблема связана с операцией drill down, описанной ниже.
Архитектура КХД является как логически, так и физически централизованной, что похоже на плановую экономику. Может, это звучит несправедливо, но, на мой взгляд, этот подход имеет ту же едва различимую, но фатальную проблему, что и плановая экономика. Вначале всё звучит замечательно, и идеалистические аргументы трудно опровергать до начала проекта. Но проблема заключается в том, что полностью централизованный подход предполагает наличие идеальной информации “a priori” и идеального принятия решений впоследствии. Несомненно, что это было одной из основных причин упадка плановых экономик. Архитектура Шины ХД поощряет непрерывно эволюционирующий дизайн, удовлетворяющий специфическим критериям «грациозной модификации» схем данных, оставляющей существующие приложения (analytical application) в работоспособном состоянии. Симметрия подхода многомерного проектирования Шины ХД позволяет нам вычленить в точности те места, куда могут быть добавлены новые или изменившиеся данные для сохранения этого грациозного характера.
Наиболее важно, что ключевым предположением, на котором основано большинство архитектур КХД, это то, что КХД «высвобождает» витрины данных (data mart). Эти витрины данных часто описываются как «построенные для ответа на бизнес-вопрос». Практически всегда это проистекает из неуместной или преждевременной агрегации. Если витрина данных содержит только агрегированные данные, то, естественно, будет ряд бизнес-вопросов, на которые будет невозможно ответить. Эти вопросы часто запрашивают не одну атомарную запись, а точный срез больших объёмов данных. Окончательное неработающее предположение КХД это то, что если пользователи хотят задавать какие-то из этих точных вопросов, они должны покинуть агрегированную многомерную витрину данных и опуститься в атомарные данные (atomic data) в 3НФ (3NF), располагающиеся в бэк-офисе. В этой точке зрения, на мой взгляд, неправильно ВСЁ. Все усилия, которые мы приложили при разработке Шины ХД идут прахом при использовании этой гибридной архитектуры: погружение в детали через согласованные измерения к атомарным данным; унифицированный подход к кодированию медленно изменяющихся измерений; использование повышающих производительность агрегатов; и праведность сохранения промежуточной области бэк-офиса от выполнения запросов.
Совет №35. Моделирование промежутков времени
В последние два года я вижу повышенный спрос к приложениям, которым необходимо задавать вопросы о промежутках времени. Кто-то хорошо сказал «каждая запись в моей таблице фактов является эпизодом постоянной величины в регионе времени». Промежутки времени могут начинаться и заканчиваться в произвольные моменты времени. В некоторых случаях промежутки времени соединяются вместе и формируют непрерывную цепь, в других случаях промежутки времени изолированы, а в худших случаях они накладываются друг на друга произвольным образом. Но, каждый промежуток времени представляется в базе данных одной записью. Чтобы легче визуализировать эти вариации, давайте представим, что у нас есть база данных, заполненная атомарными транзакциями, такими как внесение и снятие денег с банковских счетов. Мы также включим транзакции по открытию и закрытию счетов. Каждая транзакция явным образом определяет эпизод постоянной величины в регионе времени. Внесение или снятие определяют новую величину остатка по счёту, который будет действительным до момента следующей транзакции. Этот период времени может составлять от нескольких секунд до нескольких месяцев. Транзакция открытия счёта определяет статус счёта как постоянно открытого в течение промежутка времени до транзакции по закрытию счёта.
Перед тем, как мы предложим дизайн базы данных, давайте вспомним некоторые вопросы о промежутках времени, которые мы хотим задавать. Начнём с того, что ограничим наши вопросы до уровня индивидуальных дней, а не до частей дней, таких как минуты и секунды. Мы вернёмся к минутам и секундам в конце. Лёгкие вопросы, на которые нам всегда удавалось хорошо отвечать, включают:
- Показать все транзакции, которые произошли в течение определённого промежутка времени.
- Определить, была ли произведена выбранная транзакции в течение определённого промежутка времени.
- Определить промежутки времени, используя сложные возможности навигации по календарю, включая времена года, фискальные периоды, номера дней, номера недель, дни выплаты зарплаты и праздничные дни.
Для этих случаев всё, что нам нужно – это одна временная отметка в записи таблицы фактов транзакций. Первый вопрос выбирает все транзакции, временная отметка которых попадает в интервал, заданный в запросе пользователя. Второй вопрос выбирает временную отметку выбранной транзакции и производит её сравнение с интервалом. Третий набор вопросов заменяет простую временную отметку измерением календарной даты, заполненным большим количеством полезных календарных атрибутов. Это измерение даты соединяется с таблицей фактов стандартным соединением внешний ключ – первичный ключ. Это всё – ванильный многомерный дизайн, который требует всего лишь одного ключа времени в записи таблицы фактов для представления требующейся временной отметки. Пока неплохо.
Кстати, при использовании сложной навигации по календарю, запросы становятся гораздо легче, если многословное календарное измерение включает маркеры первого и последнего дня для каждого определённого промежутка времени, например «последний день квартала». Это поле будет иметь значение «N» для всех дней, кроме последнего дня кварталов. Последний день в этом специальном поле будет иметь значение «Y». Эти маркеры позволяют легко задавать в запросах сложные промежутки времени бизнеса. Заметьте, что использование многословного календарного измерения означает, что приложению не нужно обращаться к временной отметке в таблице фактов.
Следующая умеренно сложная категория запросов к интервалам времени включает следующие:
- Показать каждого, кто был клиентом в какой-то определённый промежуток времени.
- Показать последнюю транзакцию заданного клиента в каком-то промежутке времени.
- Показать остаток на счёте в произвольно выбранный момент времени.
Мы продолжим основываться на упрощающем предположении о том, что все промежутки времени основаны на календарных днях, а не на минутах и секундах. На все эти вопросы можно ответить с помощью дизайна с одной временной отметкой, который был описан выше, но этот подход требует сложных и неэффективных запросов. Например, для того, чтобы ответить на последний вопрос, нам понадобилось бы выполнить поиск по множеству транзакций по счёту и найти последнюю транзакцию на заданный момент времени или до него. В SQL это был бы коррелированный подзапросом, встроенный в окружающий его запрос. Он не только, вероятно, будет медленно выполняться, но такой SQL не всегда можно сгенерировать с помощью инструментов конечного пользователя.
Для ответов на все эти вопросы о промежутках времени средней сложности мы коренным образом упрощаем приложения путём размещения в каждой записи таблицы фактов двух временных отметок, обозначающих начало и конец промежутка времени, определяемого транзакцией.
С помощью этого дизайна с двумя временными отметками мы легко побеждаем три вопроса, приведённых в примере выше:
1. Найти все транзакции открытия счёта, дата начала которых совпадает или предшествует времени окончания заданного промежутка времени. 2. Найти транзакцию, дата начала которой совпадает или предшествует дате окончания заданного периода времени, и дата окончания которой совпадает или выходит за рамки окончания заданного временного периода. 3. Найти транзакцию, дата начала которой совпадает или предшествует произвольному моменту времени, и дата окончания которой совпадает или находится в будущем относительно произвольного момента времени.
Во всех этих случаях SQL использует простую конструкцию BETWEEN. Синтаксическая конструкция «значение между значением двух полей» является допустимой в SQL. Я узнал об этом недавно.
Когда мы используем подход с двумя временными отметками, мы должны честно признать один недостаток. Практически во всех ситуациях мы должны навестить каждую запись таблицы фактов дважды. Один раз, когда мы вставляем её (с открытой временной отметкой времени окончания), и ещё раз, когда происходит следующая транзакция, которая определяет реальную временную отметку окончания. Где-то в будущем временная отметка с открытым временем завершения, возможно, будет полезна – приложениям не придётся путешествовать по значениям null при попытке выполнения операции BETWEEN.
Мы оставили самые сложные вопросы до конца: промежутки времени с точностью до секунды. В этом случае мы задаём те же основные вопросы, что и в двух первых разделах, но мы увеличиваем точность границ промежутков времени до ближайшей секунды. В этом случае мы поместим те же самые две временные отметки в запись таблицы фактов, но мы должны отказаться от нашей связи с надёжным измерением Время. Обе наши временные отметки должны быть стандартными временными отметками РСУБД. Мы должны делать это, так как обычно мы не можем создать единого измерения Время, включающего все минуты и секунды за значительный промежуток времени. Разделение временной отметки на компоненту дня и секунды внутри дня сделало бы ужасной логику операции BETWEEN. Так что, для этих сверхточных периодов времени мы принимаем ограничения семантики даты/времени в SQL и отказываемся от возможности указывать времена года или фискальные периоды с точностью до секунды.
Если вы действительно крепкий орешек, вы могли бы рассмотреть помещение четырёх временных отметок в каждой записи таблицы фактов, если ваши периоды времени определяются с точностью до секунды. Первые две были бы временными отметками РСУБД, как это описано в предыдущем абзаце. Но третья и четвёртая были бы внешними ключами со значением (только) календарных дней, ссылающимися на многословное календарное измерение, как это описано в первых двух разделах этой статьи. Таким образом, вы можете получить свой пирог, а также съесть его. Вы можете производить поиск сверхточных промежутков времени, но вы также можете задавать вопросы вида «Покажите мне все случаи перебоев с электричеством, которые произошли в праздничные дни».
Совет №36. Быть или не быть (централизации)
В отличие от Шекспира и некоторых «экспертов» по хранилищам данных, для нас в этом НЕТ вопроса.
В этой статье мы обсудим проблемы, с которыми сталкиваются «взрослеющие» витрины/хранилища данных. В то время как некоторые организации только начинают интересоваться хранилищами данных, другие уже достаточно долго используют их. По мере становления отрасли, причины основных проблем, связанных с хранилищами данных, эволюционируют. В последнее время централизация позиционируется как некий волшебный эликсир. Утверждается, что централизация способна превратить разрозненные витрины данных в «золото» путем уменьшения затрат и увеличения производительности. Хотя централизация и может привести к более эффективной эксплуатации, она, по сути, не решает более важных проблем интеграции и согласованности данных.
Если ваше хранилище данных создавалось в отсутствие общей стратегии, то, вероятнее всего, вам приходится иметь дело с многочисленными независимыми наборами данных со следующими характеристиками:
- Множественные нескоординированные извлечения данных из одного и того же источника
- Множественные вариации одной и той же информации с несогласованными правилами именования и бизнес-правилами
- Множественные отчеты, показывающие различные результаты
Некоторые аналитики порочат репутацию витрин данных, списывая на этот подход возникновение всей массы проблем. Это грубое обобщение не отражает всей пользы, которую множество организаций получили от своих хорошо спроектированных витрин данных. Проблемы, которые мы перечислили выше, являются результатом отсутствующей, плохо определенной, либо неправильно выполняемой стратегии. И поэтому эти проблемы могут существовать при любом архитектурном подходе, включая корпоративное хранилище данных, архитектуру hub-and-spoke и распределенные/интегрированные витрины.
Мы все согласны, что изолированные наборы аналитических данных гарантируют дополнительные заботы. Очевидно, что они неэффективны и неспособны решить основные задачи бизнеса, возлагаемые на хранилища данных. Отдельные базы данных проще создавать, но без общей интеграционной стратегии они являются тупиками, и увековечивают несовместимые отражения деятельности компании. Простое перемещение этих предательских островков данных в централизованную систему не окажется панацеей от всех бед, если при этом вы проигнорируете основную проблему: интегрированность и согласованность данных. Централизация без решения этих проблем сродни борьбе с симптомами болезни, нежели с самой болезнью. Проще вообще не поднимать вопрос об интеграции и согласованию данных в связи с сопутствующими политическими и организационными трудностями, но решение этих вопросов позволит получить основной выигрыш для бизнеса от использования хранилища данных. Это сложная работа, но выигрыш для бизнеса стоит того. В терминах многомерного моделирования, решение заключается в концентрации усилий на создании шины хранилища данных и согласованных измерениях и фактах.
Как мы уже рассказывали, шина хранилища данных – это инструмент для описания общей стратегии интеграции данных в корпоративном хранилище данных. Она является каркасом для интеграции аналитической информации в компании. Шина хранилища данных определяется с помощью матрицы шины (как Ральф писал в статье для Intelligent Enterprise). Строки матрицы представляют основные бизнес-процессы в компании, а в столбцах представлены общие, согласованные измерения.
Согласованные измерения являются средствами единообразного описания основных характеристик бизнеса. Они являются точками соприкосновения между различными бизнес-процессами организации. Могут быть разумные причины не использовать согласованные измерения. К примеру, в том случае, если компания является многопрофильной корпорацией, продающей уникальные товары уникальным клиентам через уникальные каналы сбыта. Тем не менее, для большинства компаний ключом к интеграции разрозненных данных являются организационные меры по созданию согласованных измерений и повсеместному их использованию в хранилище, вне зависимости от того являются ли данные централизованными или распределенными физически.
Как мы уже предупреждали, централизация без интеграции только подольет масла в огонь существующих проблем. Руководство может быть уверенно, что покупка нового сервера, на котором разместятся мириады существующих витрин и хранилищ, повысит эффективность эксплуатации. В зависимости от суммы, которую готовы потратить на централизованную аппаратную платформу, это действительно может положительно повлиять на производительность систем. Однако этот выигрыш для IT крайне незначителен в сравнении с теми преимуществами, которые может иметь для бизнеса интеграция данных. Централизация без интеграции данных и семантической целостности уведет бизнес в сторону от решения основной проблемы. Несогласованные данные все так же будут препятствовать правильному принятию управленческих решений.
Все мы знаем, что переход на архитектуру с использованием шины хранилища данных требует силы воли и привлечения дефицитных специалистов. Никто не говорит, что это просто. Некоторые аналитики даже утверждают, что это невозможно. Тем не менее, опыт наших клиентов подтверждает обратное.
Мы обрисовали типичные задачи, возникающие при миграции разрозненных систем на шину хранилища данных и конформные измерения. Так как в каждой организации набор систем варьируется, то этот список задач необходимо скорректировать для отражения вашей ситуации.
- Задокументируйте существующие витрины/хранилища данных в вашей организации, отмечая перекрывающиеся данные.
- Проведите укрупненную оценку основных неудовлетворенных бизнес-требований.
- Соберитесь с основными заинтересованными лицами для разработки предварительной матрицы шины хранилища данных.
- Выделите специалиста или рабочую группу по ведению каждого измерения, которое должно быть согласованным.
- Спроектируйте согласованные измерения путем слияния атрибутов и/или согласования атрибутов измерения из существующих разрозненных систем. В реальности, это сложная задача договориться по всем атрибутам, но не позвольте этому остановить всю работу.
- Добейтесь договорённости о согласованных измерениях в масштабе всей организации.
- Разработайте план по инкрементальному переходу на согласованные измерения.
Разработка шины хранилища данных и конформных измерений позволит создать в вашей организации хранилище данных, которое является интегрированным, согласованным, понятным и эффективным. Вы сможете легко добавлять новые витрины, будучи уверенным, что они синтегрируются с существующими данными. Вместо борьбы с рассогласованными данными, вы улучшите процедуры принятия решений в вашей организации с помощью согласованных интегрированных данных.
Совет №37. Моделирование конвейера с помощью накопительного снимка
В журнале Intelligent Enterprise, в статье «Фундаментальные уровни гранулярности» я описал три различных типа гранулярности, к которым, похоже, сводятся все таблицы фактов. Помните, что таблица фактов является местом, где мы храним показатели, являющиеся результатом определенного бизнес-процесса. Таблицы измерений окружают и описывают эти показатели.
Помните также, что уровень гранулярности таблицы фактов – это точное определение того, что представляет собой запись таблицы фактов. Совершенно точно, первичный ключ таблицы фактов является уровнем гранулярности, но часто самым понятным определением уровня гранулярности является бизнес-понятие, нежели технический список внешних ключей. Для примера, уровень гранулярности таблицы фактов, представляющей процесс принятия заказа может быть «строка позиции в заказе», тогда как техническое описание ключа для этой таблицы может быть «номер накладной/ продукт/ рекламная акция». Все те тысячи таблиц фактов, которые я видел и изучал, разделяются на три фундаментальных уровня гранулярности:
- Транзакционный уровень (TRANSACTION), представляющий точку в пространстве и времени.
- Уровень периодического снимка (PERIODIC SNAPSHOT), представляющий регулярные промежутки времени, один за другим
- Уровень накопительного снимка (ACCUMULATING SNAPSHOT), представляющий всю историю сущности
Уровень накопительного снимка необычен по ряду причин. В отличие от других уровней гранулярности, накопительный снимок обычно имеет ряд временных измерений, представляющих определенные шаги имевшие место в жизни «накапливаемой сущности». Например, заказ является:
- созданным
- подтвержденным
- отгруженным
- доставленным
- оплаченным и, возможно
- возвращенным
Таким образом, разработка таблицы фактов накопительного снимка заказов может быть начата с шести временных ключей, все являются внешними ключами, ссылающимися на представления, основанные на одной таблице измерения со значениями-датами. Эти шесть представлений называются «ролями» таблицы дат, и они являются семантическими независимыми, как если бы были отдельными физическими таблицами, так как мы определили их как отдельные представления.
Другим необычным аспектом таблицы фактов накопительного снимка является то, что мы изменяем одну и ту же запись каждый раз, физически изменяя внешние ключи и измеряемый факт, по мере того как (обычно короткая) жизнь сущности обрастает подробностями. Процесс заказов – это классический пример.
Теперь, когда мы вспомнили о важных вопросах разработки таблицы фактов накопительного снимка, давайте применим эту технику к конвейерному процессу. Мы будем использовать конвейер поступления студентов, но те из вас кто заинтересован в конвейере продаж, смогут легко применить эту конструкцию к своей ситуации.
В случае отслеживании поступающих, абитуриенты проходят через стандартный набор препятствий или контрольных точек. Мы заинтересованы в отслеживании не менее 15 шагов процесса, включающих
- получение результатов предварительного теста
- запрос информации (через веб или другим способом)
- отправка информации
- прохождение интервью
- посещение кампуса
- получение заявления
- получение копии
- получение результатов теста
- получение рекомендаций
- первое прохождение приемной комиссии
- рассмотрение заявления для финансовой помощи
- финальное решение приемной комиссии
- студент принят
- студент допущен
- студент зачислен.
В каждый момент времени руководителям приемной комиссии и департамента по зачислению интересно, сколько абитуриентов находится на каждой стадии процесса. Это во многом похоже на воронку, где большое число соискателей входят в «трубу», и только небольшое число доходит до конца. Руководители также хотят анализировать пул абитуриентов по множеству характеристик. В примере с приемной комиссией мы можем быть уверены, что существует очень богатое измерение «Абитуриент» наполненное интересной демографической информацией.
Уровнем гранулярности накопительного снимка является одна строка на каждого соискателя. Так как это накопительный снимок, мы исправляем и обновляем уникальную запись каждого соискателя в таблице фактов, как только пройден один из шагов конвейера.
Ключевой компонент схемы – это набор 15 численных фактов, каждый из которых принимает значение 0 или 1, отражая прохождение соискателем одного из 15 шагов описанных выше. Хотя технически эти 15 фактов 0/1 могут быть сведены к 15 датам, дополнительные численные факты делают приложение элегантным и легким в использовании в практически любом средстве отчетности.
В качестве дополнительного бонуса мы введем 4 числовых аддитивных факта, представляющих «лаги» или временные задержки между определенными важными шагами в процессе. Они включают:
Информация запрошена ==> Задержка отправки
Заявка подана ==> Задержка выполнения
Заявка подана ==> Задержка финального решения
Финальное решение ==> Задержка принятия или отклонения
Эти факты задержек хороши как для выявления застрявших заявок, так и как помощь руководителям для оптимизации процесса путем выявления узких мест.
В итоге финальная схема нашей таблицы фактов выглядит так:
Идентификатор даты получение результатов предварительного теста (FK)
Идентификатор даты запроса информации (FK)
Идентификатор даты отправки информации (FK)
Идентификатор даты проведения собеседования (FK)
Идентификатор даты посещения кампуса (FK)
Идентификатор даты представление заявления (FK)
Идентификатор даты получения копии (FK)
Идентификатор даты получения результатов теста (FK)
Идентификатор даты получения рекомендаций (FK)
Идентификатор даты первого прохождения приемной комиссии (FK)
Идентификатор даты рассмотрения для финансовой помощи (FK)
Идентификатор даты принятия финального решения (FK)
Идентификатор даты получения абитуриентом решения (FK)
Идентификатор даты допуска абитуриента (FK)
Идентификатор даты зачисления абитуриента (FK)
Идентификатор абитуриента (FK)
Идентификатор решения комиссии (FK)
Количество принятых результатов предварительного теста
Количество запросов информации
Количество отправок информации
Задержка между запросом и отправкой информации
Количество пройденных интервью
Количество визитов в кампус
Количество представленных заявлений
Количество полученных копий
Количество полученных результатов теста
Количество полученных рекомендаций
Количество выполненных заявлений
Задержка между представлением и исполнением заявления
Количество первых прохождений приемной комиссии
Количество рассмотрений для финансовой помощи
Количество финальных решений
Задержка между представлением заявления и принятием финального решения
Количество принятых
Количество отклоненных
Задержка между принятием финального решения и принятием/отклонением
Количество допущенных
Количество зачисленных
Интересный дизайн! Представьте, как легко будет рассчитать состояние конвейера в любой момент времени. Хотя записи, очевидно, являются широкими, это не особенно большая таблица. Если вы – большой государственный университет со 100’000 абитуриентов, у вас будет только около 100’000 записей в год. Представим что все 17 внешних ключей это 4-х байтовые целые числа (хорошие суррогатные ключи), и 21 количество и задержки являются маленькими 2-х байтовыми целыми числами. Записи нашей таблицы фактов тогда будут шириной 17 x 4 + 21 x 2 = 110 байт. Это даёт около 11 МБ данных в год в этой таблице фактов. Проверьте мои расчёты. На самом деле, это – типичный результат для таблиц фактов накопительного снимка. Они однозначно наименьшие, из трёх типов.
Совет №38. Аналитическое приложение? Что это такое!?
Аналитические приложения становятся горячей темой для обсуждения в сообществе, занимающемся хранилищами данных. Использование аналитических приложений сулит прямую выгоду организациям, которые уже сделали большие инвестиции в инфраструктуру, а также в навыки и умения в области хранилищ данных. Но что мы имеем в виду, когда говорим «аналитическое приложение»? И каковы последние тенденции в бизнесе, которые привели ко всей этой шумихе вокруг аналитических приложений?
В своей простейшей форме, аналитическое приложение является не более чем то, что большинство практиков хранилищ данных пытались делать в течение последних двух десятков лет с системами поддержки принятия решений. Эти люди сказали бы, что аналитическое приложение – это повторяемый, управляемый процесс анализа эффективности ведения бизнеса. Я бы добавил две другие характеристики к этому определению – «совместный» и «приносит прямую выгоду бизнесу». Примерами аналитических приложений являются оценка эффективности исполнения поставщиками заказов, анализ выгодности клиента, и анализ линейки продуктов, находящихся в разработке. Каждое из этих аналитических приложений сводит воедино элементы бизнес-требований, непосредственные процессы принятия решений и данные. Приложение затем позволяет нам понять факторы, влияющие на эффективность ведения бизнеса, и позитивно воздействовать на производственную деятельность.
Поэтому основной движущей силой процесса принятия аналитических приложений остается требование реализации метода «управления посредством цифр». Но аналитические приложения стали больше внедряться за последний год. Ряд обстоятельств подлил масла в огонь интереса к аналитическим приложениям, включая:
- Все более расширяющееся использование бизнесом пакетов приложений ERP (SAP, Oracle, PeopleSoft, Lawson, Great Plains), CRM (Siebel, Clarify, Onyx), и инструментов управления цепочкой поставки (i2, Manugistics). Это привело к стандартизации многих бизнес-процессов. Данные пакеты служат источником стандартных, сравнительно чистых и доступных данных об операционной деятельности предприятия.
- Распространяющееся признание многомерного моделирования как совершенного, расширяемого метода дисциплины хранилищ данных, который ставит во главу угла пользователя.
- Появление стандартизованных многомерных моделей для таких бизнес-процессов, как финансы, управление персоналом, дистрибуция, производство, продажи, сервисное обслуживание, маркетинг. Они, на самом деле, являются заранее подготовленными наборами аналитических приложений, предназначенных для групп конечных пользователей.
- Поставка такими производителями, как Acta, Cognos, Informatica, PeopleSoft и SAP, уже готового мэппинга данных «источник - целевая система» для ведущих пакетов программ автоматизации бизнеса, что ведет к снижению затрат времени и ресурсов, необходимых для извлечения и преобразования данных из этих пакетов и загрузки их в стандартизованные многомерные модели.
- Усилия таких организаций, как FASB, SCOR, APICS по стандартизации целого ряда показателей эффективности ведения бизнеса. Что, в свою очередь, способствует появлению типовых, заранее подготовленных отчетов.
- Усиливающаяся однородность рынка средств генерации запросов и отчетов, а также растущая способность этих инструментов использовать преимущества многомерных моделей. Многие из этих средств предлагают расширенные возможности ТОЛЬКО в том случае, если схема данных является многомерной.
- Требования, накладываемые т.н. «расширенным предприятием» (не только сама организация, но и ее клиенты, и поставщики) к доступу к ключевым показателям деятельности как средству достижения конкурентного преимущества.
- Растущее понимание со стороны подразделений хранилищ данных того, что для достижения реальных результатов мы должны обращать внимание не только на извлечение и организацию данных. Управление посредством цифр означает нечто большее, чем просто взгляд на них.
Так что будем надеяться, что мы сможем увидеть все эти факторы в работе над повышением степени принятия и «боеспособности» аналитических приложений. Но для того, чтобы воспользоваться этими тенденциями, необходимо понимание взаимосвязи между аналитическим приложением и следующими вещами: профилем и предпочтениями пользователей приложения, процессами принятия решений, а также данными и требованиями к многомерным моделям.
Мы пришли к заключению, что следующий подход поможет нам свести все это воедино:
- Начните с чёткого определения и ясного понимания задачи, выполняемой аналитическим приложением, включая её связь со стратегическими инициативами организации и финансовыми факторами.
- Поместите аналитическое приложение в контекст управляемого процесса принятия решений, который предназначен для того, чтобы вывести пользователей за рамки элементарного менеджмента и оперативной отчетности так, чтобы они использовали аналитическое приложение для непосредственного принятия решений.
- Зафиксируйте требования пользователей, их профили использования, а также предпочтения, включая роли, обязанности и ожидания.
- Определите данные и установите требования к модели (факты, метрики, измерения, атрибуты, гранулярность, и стратегия агрегации), необходимые для поддержания процесса структурированного принятия решений.
- Сравните функциональный набор и возможности пакетов аналитических приложений разных производителей для того, чтобы выяснить, какие из них удовлетворяют правилу 80-20 как в части ETL, так и в части отчетности. В идеальном случае 80% ваших потребностей должны удовлетворяться без использования дополнительной разработки, а реализация оставшихся 20% может быть «элегантно» добавлена к функциональному набору пакета при помощи дополнительной разработки.
Совет №39. Шинная архитектура для аналитических приложений
В нашем предыдущем совете мы исследовали основные факторы, приведшие к нынешнему ажиотажу вокруг аналитических приложений. Одним из них является широкое признание многомерного моделирования как зрелого метода дисциплины хранилищ данных, который ставит во главу угла требования бизнеса. Многомерные модели создают благоприятные условия для аналитических исследований, предоставляя высокопроизводительное и легкое в использовании окружение, которое позволяет идентифицировать отклонения от обычных значений показателей эффективности ведения бизнеса, а также причины их возникновения.
Существуют два дополнительных требования по эффективной поддержке аналитических приложений, предъявляемых к архитектуре хранилища данных.
Во-первых, шинная архитектура и согласованные размерности, которые создают условия для ее реализации, должны лежать в основе архитектуры хранилищ данных. В недавней книге Марджи и Ральфа, “The Data Warehouse Toolkit 2nd Edition”, дается следующее определение шинной архитектуры: «архитектура для области представления хранилища данных, основывающаяся на согласованных размерностях и фактах. В случае несоблюдения шинной архитектуры витрина данных представляет собой замкнутое, автономное приложение». Чтобы узнать больше о шинной архитектуре и согласованных размерностях, смотрите статью Ральфа в одном из номеров журнала Intelligent Enterprise за 1999 год.
Вспомните, что мы выступаем за создание многомерных моделей, которые сфокусированы на бизнес-процессах (например, заказы, поставки, складские запасы, платежи), а не на подразделениях предприятия (отделы продаж, маркетинга, производство или бухгалтерия). Шинная архитектура хранилищ данных и согласованные размерности являются необходимыми условиями для аналитических приложений, потому что наиболее интересные и полезные приложения требуют объединения метрик от нескольких бизнес-процессов.
Например, для анализа ценности клиента за период времени, в течение которого он остается с нами (т.е. текущей стоимости вероятных доходов, полученных от клиента в будущем), потребуются данные: по заказам (чтобы определить приносимый им доход и маржу), дебиторской задолженности (чтобы определить затраты на сбор этой задолженности), процессу продаж (чтобы определить себестоимость продаж), поставкам (чтобы определить производственные затраты, что особенно важно для бизнеса, который занимается производством под заказ), логистике (чтобы определить затраты на дистрибуцию), и вызовам сервисной службы (чтобы определить расходы на сервис и поддержку).
Ключевые метрики по каждому из этих бизнес-процессов будут храниться в раздельных многомерных моделях. Шинная архитектура предоставляет нам возможность перемещаться между моделями различных процессов для получения полного представления о клиенте. В инструменте генерации запросов мы используем многопроходный SQL для того, чтобы выполнить это перемещение. Подобная интеграция данных от различных бизнес-процессов была бы очень трудной, если бы не было шинной архитектуры, использующей согласованные размерности.
Во-вторых, часто для поддержки аналитических приложений необходимо использование консолидированных витрин данных. Консолидированная витрина данных представляет собой интегрированный набор многомерных моделей, каждая из которых ориентирована на отдельный бизнес-процесс. Она объединяет необходимые данные по многим бизнес-процессам и может быть использована несколькими аналитическими приложениями. Например, в консолидированную витрину, применяемую для анализа выгодности клиента, могут собираться данные по заказам, выставлению счетов, предложениям, сервисному обслуживанию. С этой витриной будут работать аналитические приложения, занимающиеся анализом оттока клиентов, эффективности промо-акций, и перекрестных продаж продуктов.
Легкость в использовании и производительность являются главными факторами, обеспечивающим успех консолидированным витринам данных. Нельзя рассчитывать на то, что можно сделать из бизнес-пользователей экспертов по многопроходному SQL, заставить их быть зависимыми от специалистов ИТ, или вынудить пользователей «соединять данные на экране» их ПК для интеграции данных от нескольких изолированных витрин.
К сожалению, многие средства генерации запросов и отчетов не предоставляют адекватной поддержки возможности “drill across” между несколькими витринами данных, каждая из которых ориентирована на свой бизнес-процесс. Консолидированная витрина данных, обеспечивая единое аналитическое представление (единственная схема «звезда»), упрощает работу пользователей, обуславливает высокую производительность. Консолидированные витрины поддерживаются большинством инструментов генерации запросов и отчетов. В известном смысле, они являются следующим шагом в эволюции хранилищ данных, знаменуя уход от изолированных витрин с согласованными размерностями. Преимуществом консолидированных витрин является то, что в случае их использования не требуется применение многопроходного SQL (вся информация сосредоточена в одной таблице фактов), а их недостатком – необходимость затрат и задержек, связанных с созданием консолидированных таблиц, содержащих данные из исходных изолированных витрин.
Переход от нынешней архитектуры к той, что может поддерживать аналитические приложения завтрашнего дня, можно считать естественным этапом эволюции хранилищ данных. Данный переход требует следования хорошо известным и документированным концепциям многомерного моделирования, таким как шинная архитектура, согласованные размерности и консолидированные витрины данных.
В случае отсутствия надлежащей архитектуры доступ и анализ данных от нескольких бизнес-процессов, требуемый для поддержки аналитических приложений, которые приносят большую пользу бизнесу, становится почти безнадежным делом.
Совет №40. Структура аналитического приложения
Развитая среда аналитических приложений должна создавать такие условия пользователю, которые позволяют ему выйти за рамки стандартных отчетов. Данная среда должна «зряче» направлять пользователя в ходе анализа возникшей ситуации, в конечном счете, помогая ему принять глубокое и обдуманное решение. Целями такого цикла развития аналитического приложения являются:
- Активное «ведение» бизнес-пользователей за рамки простой отчетности
- Выявление и распознавание исключительных ситуаций (т.е. таких, в которых показатели эффективности ведения бизнеса отклонились от обычных значений)
- Сбор и фиксация передового опыта по принятию решений для каждой исключительной ситуации
- Распределение полученного передового опыта или интеллектуального капитала по всей организации
Мы разбиваем весь процесс на 5 отдельных этапов:
Этап 1: ПУБЛИКАЦИЯ ОТЧЕТОВ – предоставление стандартных оперативных и управленческих отчетов о текущем состоянии бизнеса
Этап 2: ИДЕНТИФИКАЦИЯ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ – выявление ситуаций, в которых показатели эффективности ведения бизнеса отклонились от обычных значений, как в большую, так и в меньшую сторону, для того, чтобы сосредоточить на них внимание
Этап 3: ОПРЕДЕЛЕНИЕ ПРИЧИН – на этом этапе предпринимается попытка понять основные причины, приведшие к возникновению выявленных исключительных ситуаций
4. МОДЕЛИРОВАНИЕ АЛЬТЕРНАТИВ – данный этап предоставляет основу для оценки различных альтернатив возможному решению
5. ОТСЛЕЖИВАНИЕ ДЕЙСТВИЙ – на данном этапе производится оценка эффективности рекомендуемых действий, и решения передаются обратно в оперативные системы управления и хранилище данных (на Этапе 1 отчеты создаются на основе информации в хранилище данных), таким образом замыкая контур обратной связи.
Давайте чуть более подробно рассмотрим каждый из этих этапов для того, чтобы понять те цели, которые ставятся на каждом из них, и то влияние, которое они оказывает на архитектуру хранилища данных.
Этап 1: ПУБЛИКАЦИЯ ОТЧЕТОВ. Стандартные оперативные и управленческие отчеты являются отправной точкой цикла развития аналитического приложения. Эти отчеты отображают текущие результаты по сравнению с планом или результатами предыдущих периодов и предоставляют собой «табель успеваемости» бизнеса (например, «Доля рынка увеличилась на 2 пункта, но прибыль упала на 10%»)
Требования к хранилищу данных на этом этапе направлены на улучшение уровня представления и включают в себя возможность реализации таких способов представления информации, как панели отображения различных показателей (dashboards), порталы, панели презентации ключевых показателей эффективности (scorecards). В то время как многие проекты по внедрению хранилищ данных успешно справляются с задачей предоставления отчетов, они не идут дальше Этапа 1: ПУБЛИКАЦИЯ ОТЧЕТОВ и провозглашают успех.
Этап 2: ИДЕНТИФИКАЦИЯ ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ. Данный этап является фазой анализа, на которой задаются вопросы типа «в чем дело?» или «где у нас проблемы?». На этом этапе происходит определение случаев отклонений от нормальных значений показателей, а также выявление возможностей. Большинство менеджеров просят подразделения хранилищ данных воспроизвести набор отчетов в хранилище данных, в то время как в действительности они хотят, чтобы части отчетов, которые требуют внимания, были помечены маркером или при помощи желтых стикеров.
Данная стадия является крайне важной: ее задача - не дать пользователям утонуть в потоке данных и помочь им заострить внимание на тех возможностях, которые предлагают наибольшую отдачу.
Этот этап подразумевает использование новых возможностей, например, вещательных серверов, которые по срабатыванию определенных «триггеров» рассылают оповещения на предпочтительные для пользователей устройства, а также применение инструментов визуализации, которые имеют в своем арсенале различные методы изобретательного и творческого отображения данных, например, в виде линий трендов, географических карт или кластеров.
Этап 3: ОПРЕДЕЛЕНИЕ ПРИЧИН. На этом этапе предпринимается попытка понять основные причины, приведшие к возникновению выявленных исключительных ситуаций. Ключом к разгадке является идентификация достоверных связей и взаимодействий между переменными, которые приводят к появлению «ненормальных» значений производственных показателей.
Задача успешной поддержки усилий пользователей на этом этапе потребует включения в архитектуру хранилища дополнительных программных приложений, таких, как инструменты статистического анализа и/или средства data mining (например, поиск ассоциаций, упорядочивание, классификация и сегментация) для получения количественной оценки причинно-следственных связей.
Этап 4: МОДЕЛИРОВАНИЕ АЛЬТЕРНАТИВ. На этом этапе мы полагаемся на причинно-следственные связи для построения моделей, которые будут использованы для оценки альтернативных решений.
Возможность проводить анализ типа «что, если» и моделирование для диапазона потенциальных решений считаются конечной целью типичного цикла развития аналитического приложения. Мы надеемся дать успешный ответ на такие стратегические вопросы, как, например, «что произойдет с моей долей рынка, доходом и количеством проданных единиц продукции, если мои цены будут отличаться больше, чем на 10% от цен моих двух самых больших конкурентов?». Или «если я добьюсь 5%-ной точности прогноза продаж вместо обычных 10%, как это скажется на стоимости моих складских запасов?» На этом этапе нашей архитектуре хранилища данных потребуется умение обслуживать дополнительные технологии оценки моделей, включая инструменты статистического анализа и алгоритмы data mining такие, как, например, анализ чувствительности, моделирование по методу Монте-Карло, и методы оптимизации (целевой поиск).
Этап 5: ОТСЛЕЖИВАНИЕ ДЕЙСТВИЙ. На этом этапе отслеживается результативность решений, рекомендованных на предыдущем этапе. В идеальном случае, мы сможем задействовать процесс обратной связи и сообщать рекомендованные действия обратно оперативной системе управления. Следует сохранять и анализировать данные об эффективности решений с целью проведения постоянной подстройки процесса анализа, бизнес-правил и моделей.
Этап 5 накладывает дополнительные требования на нашу архитектуру хранилищ данных. Нам потребуется запустить в работу эффективную обратную связь с оперативными системами управления и хранилищем данных. Мы также рекомендуем дополнить существующие многомерные модели новыми элементами или создать специальные витрины для данных управления эффективностью ведения бизнеса. Цель - регистрация и отслеживание результатов конкретных решений для того, чтобы было бы возможно определять то, какие решения сработали, а какие нет. Появляются новые технологии, применимые в этой области, например, вещательные серверы, которые не только будут доставлять оповещения, но и вскоре позволят пользователям реагировать на них при помощи рекомендуемого действия с того устройства, которое они предпочтут: например, электронная почта, КПК, мобильные телефоны.
Совет №41. Погружаемся в более детальную матрицу шины хранилища данных
Многие из вас уже знакомы с тем, какую важную роль играют шина хранилища данных (the data warehouse bus architecture) и матрица шины при построении витрин данных. Статья Ральфа в Intelligent Enterprise еще раз подчеркивает важность использования шины хранилища данных. Матрица шины определяет ключевые бизнес-процессы организации и связанные с ними измерения. Бизнес-процессы (обычно соответствующие основным системам-источникам) перечислены в строках матрицы, а измерения представлены столбцами. Затем ячейки матрицы помечаются для указания того, какие измерения применяются к каким процессам.
В одном документе команда разработчиков получает инструмент для общего планирования хранилища данных, определения общих измерений, координации усилий отдельных команд разработчиков, и донесения мысли о важности совместно используемых измерений для всех и каждого в организации. Мы твердо уверены в том, что составление матрицы хранилища данных – это первая задача, которую нужно выполнить после выяснения бизнес-требований.
Матрица шины дает общее представление о «кусочках пазла», из которых складывается презентационный уровень хранилища данных, а также об основных связях между этими кусочками. Но часто полезно наполнять матрицу детальной информацией по мере реализации каждой строки. Возможно, для представления результатов одного бизнес-процесса потребуется комбинация транзакционных таблиц фактов, накопительных и периодических снимков. Или требуется несколько таблиц фактов, как для детальных, так и для агрегированных данных, или для более глубокого анализа в случае использования набора различных инструментов.
Мы можем видоизменить нашу матрицу таким образом, чтобы одна строка представляла одну таблицу фактов (или один куб) относящийся к бизнес-процессу. Как только мы определили таблицу фактов, мы можем дополнить матрицу столбцами с указанием гранулярности таблицы и относящихся к ней показателей (реальных, вычисляемых или предполагаемых). Вместо простого указания используемых в каждой таблице фактов измерений, мы можем указать уровень детализации измерений (в колонке, соответствующей измерению «товар» указать уровень «бренд» или «категория»).
Получающаяся в итоге матрица, «украшенная» новыми деталями, служит путеводителем по множеству таблиц фактов вашего хранилища. Хотя многие из нас изначально предрасположены к усложнению и большому количеству деталей, мы советуем начинать с более простой, общей матрицы, а затем погружаться в детали по мере реализации. Наконец для тех, кто поддерживает готовое хранилище данных, детальная матрица является полезным инструментом для документирования текущего состояния сформировавшегося хранилища.
Совет №42. Комбинирование периодических снимков и накопительных снимков
Принято считать, что периодический снимок (periodic snapshot) и накопительный снимок (accumulating snapshot) являются двумя различными подходами, между которыми нужно выбирать, моделируя таблицу фактов. Напомним, что периодический снимок (к примеру, ежемесячный снимок состояния банковского счета) – это таблица фактов, хранящая информацию о чем-то произошедшем в течение повторяющегося предсказуемого периода времени. Записи в периодическом снимке появляются каждый отчетный период (например, месяц) в течение всего времени, когда существует измеряемый объект (счет). Периодические снимки подходят для длительных процессов, растягивающихся на несколько отчетных периодов.
Накопительные снимки, в свою очередь, подходят для коротких процессов, имеющих конкретные даты начала и окончания, как, например, выполнение заказа. В случае с заказами мы обычно создаем запись в таблице для каждого пункта заказа, а затем обновляем строку каждый раз по мере того, как заказ обрабатывается. Накопительный снимок по определению является снимком самого актуального состояния чего-либо, и поэтому значения измерений и показатели со временем обычно изменяются.
Простейшая реализация накопительного снимка не дает вам информации о промежуточных точках в истории. Вот как минимум три способа сохранить информацию об этих промежуточных состояниях.
Фиксируйте состояние накопительных снимков в регулярные интервалы времени, такие, как конец месяца. Эти периодические снимки следует хранить в отдельной таблице фактов, чтобы не усложнять приложения, работающие с этими данными. Забавно, но в итоге мы получаем тот же результат, когда пытаемся дополнить уже имеющийся периодический снимок таблицей с данными на текущий момент времени, но это другая история. Зафиксированные снимки напоминают работу с медленно меняющимися измерениями 2го типа. Как и с любыми периодическими снимками, хорошая новость состоит в том, что теперь у вас есть запись для каждого заказа каждый месяц, когда этот заказ был в работе. Плохая новость состоит в том, что вы видите эти снимки только на конец месяца.
Фиксируйте состояние накопительного снимка и сохраняйте запись в отдельную таблицу только в том случае, когда прошло изменение заказа. Таким способом мы сохраним всю историю заказа. В этом случае мы получим такое же число строк, как и в следующем пункте.
Создайте таблицу фактов для заказов на уровне отдельных транзакций. Добавьте в таблицу фактов измерение «Тип транзакции» для описания каждого изменения заказа. Такой способ является наиболее общим, так как позволяет видеть все, что происходило с заказом. Но будьте осторожны: некоторые транзакции становятся со временем неаддитивными. К примеру, если один пункт заказа отменен, и два новых пункта добавлены заказ, то потребуется достаточно сложное вычисление для правильного вычисления состояния заказа на произвольный момент в прошлом. Поэтому вариант 2 может быть наилучшим, если требуется видеть на любой момент времени состояние всего заказа в целом.
Совет №43. Работа со значениями NULL в многомерном моделировании
Большинство реляционных СУБД поддерживают использование значения NULL для представления отсутствующих данных. NULL сбивает с толку как разработчиков хранилищ данных, так и пользователей, потому что СУБД обрабатывает отсутствующие значения иначе, нежели нули и пустые строки, хотя NULL и очень похожи на последние. В этом совете исследуются три основных области, в которых мы сталкиваемся с отсутствующими значениями в исходных данных, и даются рекомендации по действиям в каждой ситуации.
NULL во внешних ключах таблицы фактов. Мы сталкиваемся с такой ситуацией в источниках данных по нескольким причинам: значение может быть не известно в момент извлечения данных, либо неприменимо к извлекаемым фактам, либо попросту отсутствовать из-за какой-либо ошибки в источнике. Очевидно, что если мы просто поместим NULL в колонку таблицы фактов, объявленную как внешний ключ, то мы нарушим ссылочную целостность, потому что в реляционных СУБД обычно NULL не равен сам себе.
В первом случае, особенно часто возникающем при использовании накопительных снимков (accumulating snapshot), некоторые колонки отслеживают события, которые еще не произошли. Например, в накопительном снимке заказов может быть строка, соответствующая заказу, полученному 31го числа, но отгружен заказ будет только в следующем месяце. И когда строка будет вставлена в таблицу, значение столбца «Дата отгрузки» еще будет неизвестно. В этом случае столбец «Дата отгрузки» является внешним ключом, ссылающимся на таблицу дат. Но если при этом мы просто вставим в колонку значение NULL, то соединение между таблицами не будет работать так, как этого ожидает пользователь. Из любого отчета, использующего связь измерения дат и столбца «Дата отгрузки», пропадут строки в которых «Дата отгрузки» равна NULL. Большинство пользователей нервничают, когда исчезают данные. Поэтому мы рекомендуем использовать вместо NULL суррогатный ключ, который ссылается не специальную запись в таблице дат с описанием вроде «Дата еще не доступна».
Бывают ситуации, когда внешний ключ неприменим к конкретным фактам. Например, «Рекламная кампания» является внешним ключом в таблице фактов, но не каждая запись ссылается на «Рекламную кампанию». Опять же, мы советуем добавить с измерения отдельную запись вида «Не проводилась рекламная кампания»
NULL в значениях показателей. В этом случае NULL имеет два возможных смысла. Либо значение отсутствует, либо исходная система не смогла измерить факт. В любом случае мы обычно просто оставляем значение NULL, так как в большинстве СУБД значение NULL обрабатывается корректно в агрегатных функциях типа SUM, MAX, MIN, COUNT и AVG. Замена NULL на ноль исказит результат вычисления этих функций.
NULL в атрибутах измерений. Обычно мы сталкиваемся со значениями NULL в атрибутах по двум причинам. Возможно, что еще не все значения атрибутов были извлечены, поэтому мы имеем неизвестные значения в течение какого-то периода времени. Или могут быть атрибуты, которые имеют смысл только для подмножества элементов измерения. В любом случае мы советуем поступать одинаково. Значения NULL в этих атрибутах нежелательны и затруднительны для конечных пользователей, так как они приведут к пустым ячейкам в отчетах и выпадающих списках, и потребуют специальных синтаксических конструкций для обработки. Вместо этого мы рекомендуем заменять NULL на осмысленную строку вида «Неизвестно» или «Не предусмотрено».
Имейте в виду, что инструменты для data mining по-разному обрабатывают NULL. Если подготавливаемые вами данные будут использоваться для data mining, то возможно вам придется приложить дополнительные усилия, помимо выполнения предложенных рекомендаций.
Совет №44. Не полагайтесь слишком сильно на метаданные вашего инструмента для доступа к данным
Сегодняшние инструменты класса business intelligence предоставляют сильный набор метаданных для поддержки широкого спектра возможностей, такие как замена меток, предопределённые расчёты и навигация по агрегатам. Это полезные функции для вашего бизнес-сообщества. Но мы должны взвешенно использовать функции, которые предоставляют нам инструменты. Слишком часто команды разработчиков выбирают короткие пути и полагаются на метаданные инструментов доступа к данным для решения задач, которые лучше решаются с помощью наших многомерных моделей. Конечный результат – это бизнес-правила, которые становятся встроенными в метаданные инструмента, а не в наши схемы данных. Мы также наблюдаем случаи, когда команды разработчиков используют метаданные инструментов для предоставления справочников кодов и описания индикаторов в неверном стремлении к сокращению своих схем данных.
Наибольший недостаток этих коротких путей – это зависимость от метаданных инструментов конечного пользователя для хранения бизнес-правил. Если для внедрения бизнес-правил мы полагаемся на метаданные инструмента, то каждый пользователь должен будет получать доступ к данным через «поддерживаемый» инструмент для того, чтобы гарантировать, что бизнес-пользователи получат «корректные» данные. Пользователи, которые хотят, или которым нужно использовать другой метод доступа, должны воссоздавать бизнес-правила, похороненные в метаданных инструмента, чтобы быть уверенными в том, что они получат корректные результаты.
Как разработчики хранилищ данных мы должны противостоять ситуациям, когда бизнес-пользователи могут увидеть разные результаты в зависимости от используемых ими инструментов. Вне зависимости от того, как они получают доступ к данным, пользователи должны видеть те же высококачественные согласованные данные.
Вы можете думать «Хорошо, тогда мы заставим всех пользователей получать доступ к данным через поддерживаемый нами инструмент». Однако этот подход неизбежно провалится. Есть ряд причин, почему кто-то может захотеть получить доступ к данным каким-то другим способом в обход поддерживаемого инструмента и, соответственно, в обход бизнес-правил, поддерживаемых его метаданными. Эти сценарии могут отсутствовать в вашей организации в момент, когда вы разрабатываете вашу схему, но, будьте уверены, что какой-либо из них точно всплывёт на вашем веку:
- Специалист IT (может быть, вы сами) может выбрать доступ через SQL, выполняемый прямо поверх хранилища данных, для того, чтобы ответить на сложный вопрос, или выполнить аудит данных.
- Ваша организация может разрабатывать аналитические приложения, основанные на запросах SQL к хранилищу данных, разработанных своими силами.
- Инструменты статистического моделирования и/или инструменты data mining могут иметь необходимость в прямом доступе к данным хранилища.
- Продвинутый пользователь, вооружённый Microsoft Access (или другим неподдерживаемым инструментом), может получить доступ к хранилищу данных.
- Может возникнуть необходимость в дополнении хранилища данных многомерными «кубами», наполняемыми непосредственно из хранилища данных.
- Ваша организация может выбрать другой инструмент для конечных пользователей на замену существующему.
Ничего из упомянутого выше не следует употреблять в качестве аргументов против использования возможностей вашего инструмента доступа к данным. Напротив, ключевым моментом является то, что если у нас возникают сомнения, или мы поставлены перед выбором, мы предпочитаем выбрать такой дизайн, который помещает возможность настолько близко к данным, насколько это возможно, чтобы гарантировать наличие возможности для как можно более широкой аудитории.
Совет №45. Приёмы моделирования интеллектуального капитала
Одна из больших трудностей во внедрении аналитики - это то, что результирующий интеллектуальный капитал хоронится в инструментах, которые используются для построения аналитики. Как только интеллектуальный капитал замыкается внутри одного из таких инструментов, становится трудно делиться логикой принятия решений с пользователями, которые могут использовать другие инструменты business intelligence, инструменты для выполнения запросов и генерации отчётов.
Я определяю интеллектуальный капитал как лучшие практики организации в одной из хорошо определённых действий бизнеса. Например, какой способ является наилучшим для анализа ввода нового расширения линейки продуктов, такого как новый компонент зубной пасты на рынке товаров народного потребления? Это включает не только данные и показатели, но и стандарт нормальной производительности, включая «базовый показатель». Любые значения производительности за пределами 2 или 3 стандартных отклонений от базового показателя будет рассматриваться как исключение. Дальше я бы попробовал понять, какие из ключевых показателей (таких, как соотношение с ценами конкурентов, сквозные продажи, количество и качество поддержки розницы, любые показатели нехватки товара на складе или показатели дистрибуции, остатки, распродажи, купоны) находились за пределами приемлемых рекомендованных значений.
Успешные организации учатся, как встраивать интеллектуальный капитал в дизайн своих хранилищ данных, используя общие приёмы многомерного моделирования, вместо того, чтобы запирать его в инструментах. Эти организации также используют преимущества 5-шагового аналитического жизненного цикла в процессе сбора бизнес-требований (публикация отчётов, идентификация исключений, определение влияющих факторов, моделирование альтернатив и отслеживание действий) для того, чтобы выманить свои требования к интеллектуальному капиталу.
На первом этапе, этапе публикации отчётов, построение основы интеллектуального капитала начинается с того, что вы убеждаетесь в том, что у вас существуют «правильные» данные с «правильной» степенью детализации. Этот этап является критическим для построения основы хранилища данных со стандартными метриками, согласованными измерениями, общими атрибутами и наиболее атомарной степенью детализации для поддержки общего для всей организации словаря. Приёмы многомерного моделирования, полезные на этапе публикации отчётов, включают именованные иерархии, которые поддерживают стандартную отчётность о «состоянии бизнеса», а также партиции реального времени для поддержки отчётов в режиме реального времени.
На этапе исключений интеллектуальный капитал проявляется в богатстве и надёжности таблиц измерений. К примеру, допустим, что вы пытаетесь определить специфические сущности бизнеса, которые вызывают проблемы с производительностью. Приёмы многомерного моделирования, такие как drill down до атомарных данных, а также drill across при поддержке шинной архитектуры, позволяют пользователям идентифицировать те области бизнеса, которые являются источниками исключительной производительности.
На этапе определения влияющих факторов такие методы многомерного моделирования, как консолидированные витрины и накопительные снимки помогают понять причины исключительной производительности. Например, давайте предположим, что мы пытаемся понять причины задержек в таких процессах, как обработка претензий или отслеживание заказов. Можно было бы построить приложение с использованием инструментов анализа данных для извлечения ключевых дат и расчёта временных промежутков. Но, вместо этого мы бы порекомендовали встроить эту логику непосредственно в хранилище данных, используя приём накопительных снимков, так что пользователи смогут видеть конвейер обработки в одном простом формате базы данных, вне зависимости от инструмента, который они используют.
На этапах оценки альтернатив и отслеживания действий приёмы многомерного моделирования, такие как мини-измерения, играют роль при сборе и применении аналитических результатов. Например, давайте предположим, что ваш аналитический процесс вычисляет показатель склонности клиента к повторным покупкам, дополнительным покупкам, к покупке товаров с частной маркой, к мошенничествам с кредитными картами, к посещениям веб-сайта, ответам на электронные письма, а также склонности к отказу от продуктов и услуг компании. Мы можем хотеть отслеживать динамику изменения этих показателей со временем для того, чтобы проанализировать влияние маркетинговых программ на эти показатели. Мы можем облегчить задачу отслеживания и совместного использования этого интеллектуального капитала, встроив эти показатели в дизайн хранилища данных при помощи мини-измерений, вместо того, чтобы хоронить их в непредсказуемых местах схемы. Мы также можем использовать такие архитектурные приёмы, как горячий кэш для быстрого предоставления результатов в среде операционной работы, таким образом «замыкая аналитический цикл».
Существует много практических приёмов многомерного моделирования, которые можно использовать для того, чтобы встроить интеллектуальный капитал, являющийся результатом аналитического жизненного цикла, в дизайн хранилища данных вместо того, чтобы запирать его в инструментах, использующихся для построения аналитики. Это драматически улучшает возможности организации по сбору, совместному и повторному использованию её интеллектуального капитала.
Совет №46. Еще один взгляд на вырожденные измерения
На семинарах по многомерному моделированию нас часто спрашивают о вырожденных измерениях (degenerate dimensions). Вырожденные измерения вводят в замешательство, так как они не похожи на обычные измерения. Полезно вспомнить, что согласно определению, данному в словаре Уэбстера, «вырожденный» обозначает: 1) отклоняющийся от нормы, или 2) математически более простой.
Вырожденное измерение выглядит как ключ в таблице фактов, но по этому ключу не производится соединение с таблицей, потому что все интересующие нас атрибуты помещаются в другие измерения. Иногда вырожденные измерения называют текстовыми фактами, тем не менее, они не являются фактами, так как ключ таблицы фактов обычно состоит из вырожденного измерения и дополнительных внешних ключей.
Вырожденные измерения часто встречаются в таблицах фактов, созданных на уровне отдельных транзакций. Обычно вырожденными измерениями являются идентификаторы, присваиваемые учетными системами: номера заказов, билетов, транзакций по кредитным картам, чеков и т.п. Вырожденные измерения являются естественными ключами «родителей», соответствующих детальным записям.
Хотя по вырожденному измерению не производится соединения с таблицей, содержащей дополнительные атрибуты, вырожденное измерение может быть полезно для группировки родственных записей в таблице фактов. Например, в розничной торговле номер чека группирует все товары, купленные в одной корзине. В здравоохранении вырожденные измерения могут использоваться для группировки фактов, относящихся к одному курсу лечения или нахождению в больнице.
Часто мы встречаем несколько вырожденных измерений в одной таблице фактов. Например, в страховании таблица фактов с позициями требований о возмещении обычно содержит в качестве вырожденных измерений номер требования и номер полиса. Таблица фактов по отгрузкам пожжет содержать номер заказа и номер товарной накладной.
Вырожденные измерения также служат для поддержания связи с учетными системами. Они могут быть очень полезны на этапе разработки ETL для связи записей таблицы фактов с записями в учетных системах в целях тестирования или проверки целостности.
Мы, как правило, не используем суррогатных ключей для вырожденных измерений. Обычно значения этих измерений уникальны и имеют разумные размеры, применение суррогатных ключей неоправданно. Однако если идентификатор учетной системы является длинной строкой, то суррогатный ключ может помочь сэкономить значительное пространство, особенно в случае таблиц фактов с большим числом записей. Также суррогатный ключ необходим, если идентификатор учетной системы не уникален. Конечно, если вы используете суррогатный ключ, то измерение уже не является вырожденным.
При рецензировании дизайна мы иногда находим таблицы измерений, растущие пропорционально таблицам фактов. При добавлении записей в таблицу фактов, добавляются записи и в измерение, часто даже в таком же или близком количестве. Такая ситуация должна служить для вас тревожным сигналом. Часто измерение, увеличивающееся с той же скоростью, что и таблица фактов, является незамеченным на этапе проектирования вырожденным измерением.
Совет №47. Связь между стратегическими бизнес-инициативами и бизнес-процессами
Один из вопросов, на который я часто отвечаю, не задумываясь, это вопрос «какова связь между стратегической бизнес-инициативой организации (то, на чём сфокусирован бизнес) и бизнес-процессом (который является основой построения хранилища данных)?»
Стратегические бизнес-инициативы – это возглавляемые высшим руководством планы масштаба организации по получению значительных, непреодолимых и различимых финансовых или конкурентных преимуществ. Стратегическая бизнес-инициатива обычно имеет измеримую финансовую цель и срок реализации от 12 до 18 месяцев. Понимание стратегических бизнес-инициатив организации является отправной точкой для проекта по построению аналитических приложений, так как оно гарантирует, что аналитический проект приводит к созданию чего-то ценного для бизнес-сообщества.
Между тем, бизнес-процесс является самым нижним уровнем деятельности бизнеса, например, оформление заказов, доставка, выставление счетов, получение платежей, обработка сервисных звонков и претензий. Мы особо заинтересованы в показателях, проистекающих из этих бизнес-процессов, поскольку они поддерживают разнообразные виды аналитики. Например, бизнес-процессом могут быть транзакции розничных продаж на кассовых аппаратах. Отталкиваясь от этого базового бизнес-процесса и результирующих данных, мы могли бы погрузиться во множество видов анализа, например, оценка результатов промо-акций, анализ потребительской корзины, анализ эффективности директ-маркетинга, анализ ценообразования и анализ конкурентов. Данные бизнес-процессов – это основа, на которой мы строим хранилище данных.
Таким образом, бизнес концентрируется на стратегических бизнес-инициативах, а команда хранилища данных/ аналитики – на бизнес-процессах. Не является ли это причиной громадного разрыва? На самом деле, нет. Частью работы по сбору бизнес-требований команды хранилища данных/ аналитики должно быть разбиение или декомпозиция стратегических бизнес-инициатив на поддерживающие их бизнес-процессы.
Представьте себе матрицу из строк и столбцов, в которой заголовками строк являются бизнес-процессы (так же, как и в матрице архитектуры шины корпоративного хранилища данных), а заголовками столбцов являются стратегические бизнес-инициативы. Отметки в точках пересечения строк и столбцов указывают на необходимость данных, порождаемых бизнес-процессом для поддержки стратегических бизнес-инициатив. Вместо создания путаницы интеграция стратегических бизнес-инициатив и бизнес-процессов вносит больше ясности относительно того, когда начинать аналитический процесс и почему. Эта матрица поддерживает проверенный внедренческий подход построения вашего хранилища данных по одному бизнес-процессу за один приём, уменьшая время внедрения и исключая избыточность данных, вместе с этим, создавая основу, необходимую для поддержки тех инициатив, которые бизнес признаёт важными.
Совет №48. Наводим порядок с помощью «мусорных» измерений
При проектировании многомерных моделей мы часто сталкиваемся с различными индикаторами или флагами, не являющимися атрибутами основных измерений. Обычно эти несвязанные атрибуты достаточно важны, и мы не можем их просто проигнорировать или исключить. Проектировщики иногда трактуют их как текстовые факты, либо загромождают модель множеством маленьких измерений. Третий, менее очевидный, но более предпочтительный способ заключается в том, чтобы использовать «мусорное» измерение (junk dimension) для хранения этих флагов и индикаторов.
Мусорное измерение весьма удобно для группировки флагов и индикаторов, особенно в случае значительной корреляции между их значениями. Преимущества от использования мусорных измерений следующие:
- Обеспечивается логичное, интуитивно понятное хранение соотносящихся друг с другом атрибутов в рамках многомерной модели.
- Упрощается дизайн, в котором излишнее количество измерений. Например, в таблице фактов пять и более индикаторов можно свернуть в один 4-байтный суррогатный ключ.
- Обеспечивается маленькая и быстрая точка входа для запросов, в сравнении с накладыванием ограничений напрямую на атрибуты в таблице фактов. Правда, если ваша СУБД поддерживает индексы на основе битовых карт, то это потенциальное преимущество для вас неважно.
Интересным применением для мусорных измерений является хранение контекста транзакции. Наши согласованные измерения хранят основные, наиболее интересные атрибуты, но при этом с большой вероятностью существуют атрибуты транзакции, которые неизвестны до момента её обработки. К примеру, компания, страхующая здоровье, хочет хранить контекст для каждого требования о страховом возмещении. Гранулярность бизнес-процесса в данном случае такая - одна строка для каждого пункта в требовании. Из-за большой сложности индустрии здравоохранения, похожие требования о страховом возмещении могут обрабатываться абсолютно разным способом. Может потребоваться спроектировать несколько мусорных измерений для описания того, как требование было рассмотрено, оплачено, о договорных отношениях с медицинскими учреждениями на момент выплаты страхового возмещения и т.п.
Существует два подхода к созданию мусорных измерений. Можно заполнить измерение заранее: каждая допустимая уникальная комбинация атрибутов генерирует строку в таблице мусорного измерения. Другой подход заключается в создании записей в измерении на лету, по ходу ETL-процесса. Как только встречается новая комбинация атрибутов, сразу в таблицу измерения вставляется запись с новым суррогатным ключом.
Если максимальное число возможных строк в мусорном измерении невелико, то вероятно лучше создать эти строки заранее. С другой стороны, если общее число строк в мусорном измерении достаточно большое, предпочтительнее создавать новые записи по мере необходимости. Одно из мусорных измерений, которое я недавно наблюдал, работая в сфере здравоохранения, имело порядка триллиона теоретически возможных строк, в то время как реально использовались лишь десятки тысяч. Очевидно, что в данном случае нет никакого смысла создавать все теоретически возможные записи заранее. Если число строк в вашем мусорном измерении приближается или превышает число строк в таблице фактов, то вам нужно пересмотреть дизайн.
Так как мусорное измерение включает в себя все допустимые комбинации атрибутов, то в нем автоматически отслеживаются изменения в атрибутах измерения. Таким образом, для мусорных измерений не нужно применять стратегии, которые мы применяем для медленно меняющихся измерений.
Совет №49. Со скамьи
В последнем номере журнала Intelligent Enterprise от 17 сентября опубликована статья под названием The Bottom-Up Misnomer. Мы с Ральфом написали эту статью несколько месяцев назад. Пока она проходила по издательскому конвейеру, отраслевое новостное письмо ещё сильнее подогрело дискуссию подход «снизу вверх» против подхода «сверху вниз». Похоже, многие чувствуют, что они могут объяснить подход Кимбалла. К сожалению, иногда они распространяют непонимание и продолжают затуманивать проблемы. Хоть мы точно и не являемся экспертным источником детального объяснения подхода корпоративной информационной фабрики (corporate information factory – CIF), мы чувствуем ответственность в том, чтобы внести ясность относительно наших методов, а не наблюдать со стороны.
Когда мы писали книгу The Data Warehouse Lifecycle Toolkit, мы назвали наш подход Многомерный Жизненный Цикл Бизнеса (Business Dimensional Lifecycle). Оглядываясь назад, нам, возможно, следовало бы просто назвать его подходом Кимбалkа, как предложил наш издатель. Вместо этого мы выбрали название Business Dimensional Lifecycle, потому что оно усиливало наши базовые принципы относительно успешных хранилищ данных, основанные на нашем коллективном опыте с середины 1980-х.
1) В первую очередь, вам нужно концентрироваться на бизнесе. Если вы не способствуете лучшему принятию решений, то вам не следует инвестировать ресурсы в хранилища данных и business intelligence. Концентрация на бизнесе НЕ предполагает, что мы одобряем разработку изолированных репозиториев данных для решения определённых бизнес-требований уровня подразделений. Ваш один глаз должен смотреть на требования бизнеса, в то время как другой должен концентрироваться на более широких проблемах интеграции корпоративных данных и их согласованности.
2) Аналитические данные должны предоставляться в виде многомерных моделей для обеспечения лёгкости использования и производительности при выполнении запросов. Мы рекомендуем, чтобы в многомерном виде было доступно большинство атомарных данных, чтобы их можно было «распиливать в любую сторону». Как только вы начинаете ограничивать многомерную модель суммированной информацией, вы ограничиваете свои возможности по ответам на вопросы, для которых требуются детальные данные.
3) По мере того, как хранилище данных будет постоянно развиваться, каждая итерация должна рассматриваться как жизненный цикл проекта, состоящего из предсказуемых действий с конечными датами начала и окончания. Где-то на наш подход нас навесили ярлык «подход снизу вверх». Возможно, этот термин был использован в силу того, что мы очень сильно ориентируемся на бизнес. К сожалению, этот ярлык не отражает того, что мы очень сильно рекомендуем разрабатывать матрицу шины корпоративного хранилища данных для сбора информации о связях между ключевыми бизнес-процессами/ событиями и ключевыми описательными измерениями ДО ТОГО КАК начнётся разработка.
И наконец, мы верим, что согласованные измерения (которые логически определяются в матрице шины, а затем физически усиливаются посредством стейджингового процесса) являются абсолютно критическими для согласованности и интеграции данных. Они предоставляют непротиворечивые названия, бизнес-правила/ определения и домены, которые используются повторно по мере того, как мы строим новые таблицы фактов для интеграции и захвата результатов дополнительных бизнес-процессов/ событий.
Совет №50. Бесфактовая таблица фактов? Звучит как «китовая креветка»?
Бесфактовая таблица фактов кажется оксюмороном, как китовая креветка. Как у вас может быть таблица фактов, которая не содержит ни одного факта? Мы обсуждали основы бесфактовых таблиц фактов несколько раз в наших книгах и статьях. В этом совете разработчику мы используем бесфактовую таблицу фактов для дополнения наших стратегий медленно меняющихся измерений.
Как вы возможно помните, бесфактовая таблица фактов фиксирует связи многие-ко-многим между измерениями, но не содержит численных или текстовых фактов. Они часто используются для записи событий и дополнительной информации. Типичные примеры бесфактовых таблиц фактов включают:
- Выявление акций продвижения продукта (для определения продвигаемых продуктов которые не продаются)
- Ведение посещаемости студентов или событий регистрации
- Ведение страховых случаев
- Определение перечней строений, услуг, оборудования для госпиталя или университета
В сегодняшнем совете разработчику, представьте, что мы разрабатываем схему для крупной компании потребительского сектора (выберите вашу любимую потребительскую отрасль – авиаперевозки, страхование, кредитные карты, банковская, коммуникации или интернет-магазин). Компания ведет бизнес с десятками миллионов клиентов. В дополнение к типичным требованиям в виде транзакционной схемы для отслеживания поведения клиента и периодического снимка для определения тенденций, нашим бизнес-партнерам необходима возможность просмотреть точный профиль клиента (включающий десятки атрибутов) в любой момент времени. Постоянные читатели могут помнить рассуждения Ральфа о похожей ситуации в совете №13. Он наметил технику, кода измерение само фиксирует события изменения профиля как медленно меняющееся измерение Тип 2 (SCD2), вместо того чтобы создавать таблицу фактов для захвата транзакций по профилю. Как бы ни было, мы не сможем использовать технику совета №13 для текущего сценария, дающего большие объемы данных (миллионы клиентских строк) и потенциально высокую изменчивость (десятков атрибутов).
Давайте представим, что мы разрабатываем основное клиентское измерение (с атрибутами SCD2 как минимум) вместе с четырьмя «мини» измерениями для ведения изменений кредитных атрибутов клиента, его предпочтений, маркетинговой сегментации/предрасположенностей и клиентской географии. Пять внешних ключей входят таблицу фактов уровня транзакции, так же как и в месячный снимок. Эти внешние ключи представляют «состояние» клиента, когда строка факта загружена. Пока все неплохо, но нам по-прежнему нужно поддерживать отображение профиля клиента в произвольный момент времени. Мы рассматриваем использование другой таблицы фактов периодического снимка, загружаемой ежедневно для каждого клиента, фиксирующая в момент времени связи между клиентским измерением и связанными мини-измерениями. Это приводит к загрузке десятков миллионов снимков каждую ночь, за несколько лет исторических данных. Мы быстро делаем расчеты и предпочитаем рассмотреть другие варианты.
В этот момент вы думаете: «Это отлично, но как насчет китовой креветки?». Мы можем использовать бесфактовую таблицу фактов для фиксации во времени связей между клиентским измерением и мини-измерениями. Мы загружаем строку факта в бесфактовую таблицу каждый раз, когда происходит изменение Типа 2 в базовом клиентском измерении или меняется связь между базовым измерением и мини-измерениями. Эта бесфактовая таблица фактов содержит внешние ключи к базовому клиентскому измерению и каждому из четырех мини-измерений для загруженной строки. Затем мы украсим эту конструкцию двумя датами, начала и окончания, для определения профиля клиента в произвольный момент времени. Мы также можем добавить простое измерение для обозначения текущего профиля клиента, в дополнение к измерению «причина изменения» для указания причины, приведшей к загрузке новой строки в бесфактовую таблицу фактов.
Совет №51. Последние размышления о таблицах измерения Время
Практически каждая таблица фактов имеет один или более внешних ключей, связанных с измерением Время. Показатели определены в точные моменты времени и большинство показателей со временем повторяются.
Наиболее общим и полезным измерением Время является календарь с уровнем гранулярности в один день. Это измерение имеет удивительно много атрибутов. Только некоторые из этих атрибутов (такие как имя месяца и год) могут быть получены непосредственно из SQL-выражения типа date-time. Праздники, рабочие дни, фискальные периоды, номера недель, индикатор последнего дня месяца и другие навигационные атрибуты должны быть встроены в календарное измерение и вся навигация по датам должна быть реализована в приложениях при помощи атрибутов измерения. Календарное измерение имеет несколько весьма необычных свойств. Это – одно из немногих измерений, которое полностью определено в начале проекта по хранилищу данных. У него также нет источника в общепринятом смысле. Лучший способ создать календарное измерение – это потратить полдня с электронной таблицей и построить его вручную. Десять лет по дням это меньше 4000 строк.
Каждое календарное измерение нуждается в атрибуте типа Дата и в атрибуте Полная Дата. Эти два поля составляют естественный ключ таблицы измерения. Атрибут типа Дата почти всегда имеет значение «дата», но также должна существовать, по крайней мере, одна запись, отражающая специальную ситуацию, когда дата неприменима, испорчена или пока не введена. Этот внешний ключ, ссылающийся на таблицу фактов, в этих случаях должен указывать на значение «не дата» в календарной таблице дат! Вам требуется, по крайней мере, одна такая специальная запись, но вы можете счесть нужным разделить несколько таких необычных ситуаций. Для неприменимой даты Тип Дата принимает значение «неприменимо» или «NA». Атрибут Полная Дата является полным реляционным значением даты и принимает пустое значение в специальных случаях описанных выше. Помните, что внешний ключ в таблице фактов не может быть пустым, так как это нарушает требование ссылочной целостности.
В идеальном случае, первичный ключ календарной даты должен быть бессмысленным суррогатным ключом, но многие команды разработчиков ETL не могут противостоять желанию сделать этот ключ читаемой последовательностью, как например 20040718 будет значить 18 июля 2007-го года. Как бы то ни было, как с любым интеллектуальным ключом, несколько специальных записей заставит разработчика совершать трюки. Например, интеллектуальный ключ для несуществующей даты может быть каким-нибудь бессмысленным значением вроде 99999999, и приложения, что пытаются интерпретировать значение ключа напрямую, без использования таблицы измерения, должны всегда тестироваться с этим значением, так как оно не является действительной датой.
В некоторых таблицах фактов время фиксируется на уровне детальнее календарной даты, вплоть до минут или даже секунд. Не всегда построить измерение время с каждой минутой и секундой каждого представленного дня. В году более 31 миллиона секунд! Мы хотим сохранить мощное календарное измерение и одновременно поддерживать точечные запросы к минутам или секундам. Мы можем также пожелать рассчитывать очень точные интервалы путем сравнения точного времени в двух записях таблицы фактов. По этим причинам мы рекомендуем добавить в таблицу фактов как внешний ключ календарного измерения, так и полную даты и время в формате SQL timestamp. Компонент точного времени «день» остается как внешний ключ – ссылка на наше знакомое календарное измерение. Мы также встроили полную дату и время SQL timestamp непосредственно в таблицу фактов для всех запросов, требующих большой точности. Смотрите на это как на особый вид факта, не измерение. В таком интересном случае бесполезно создавать измерение с компонентами в виде минут или секунд точной временной отметки, так как при использовании отдельных измерений «день» и «время дня» расчет временных интервалов по записям таблиц фактов становится слишком беспорядочным. В предыдущих книгах мы рекомендовали создавать такое измерение с минутами или секундами в виде смещения от полуночи каждого дня, но теперь нам стало понятно, что получающиеся приложения становятся слишком сложными, особенно при попытке рассчитать промежутки времени. Также, в отличие от календарного измерения, получается некоторое количество описательных атрибутов для определенной минуты или секунды внутри дня.
Если на предприятии существуют хорошо определенные атрибуты для интервалов внутри дня, например, смены или рекламные паузы, в схему может быть добавлено дополнительное измерение «время дня», определенное как минуты (или даже секунды) прошедшие с полуночи. Таким образом, это измерение может иметь или 1440 записей для минут или 86400 записей для секунд. Наличие такого измерения «время дня» не отменяет необходимость в точной дате и времени SQL timestamp, описанной выше.
Совет №53. Украшения измерения
При разработке многомерных моделей мы стараемся создать надежный набор таблиц измерений, украшенных богатым набором описывающих атрибутов. Чем больше необходимых атрибутов мы добавим в измерение, тем больше возможностей будет у пользователей по-новому взглянуть на бизнес. Это особенно важно при создании измерения вокруг клиента.
Мы призываем вас вкладывать в многомерные модели интеллектуальный потенциал. Вместо того чтобы применять бизнес-правила к данным на уровне приложений (часто Excel), группировки и сводные данные, необходимые бизнесу, должны захватываться на уровне данных, так чтобы они были целостными и свободно доступными всем аналитикам, независимо от их инструментов. Конечно, это делает необходимым понимание того, что бизнес делает с данными сверх того, что было зафиксировано в оперативном источнике. Как бы то ни было, хранилище данных приносит пользу только при этом понимании и добавлении в него производных атрибутов и метрик.
Иногда, по мере того как мы добавляем аналитические признаки в клиентское измерение, мы становимся жертвами нашего собственного успеха. Бизнес неминуемо желает отслеживать изменения всех этих интересных атрибутов. Представляя, что клиентское измерение имеет миллионы строк, нам необходимо прибегнуть к мини-измерениям, чтобы фиксировать изменения клиентского измерения. Наш старый знакомый, медленно меняющееся измерение типа 2, не будет так эффективен из-за большого числа дополнительных сопровождающих строк.
Техника мини-измерений использует отдельные измерения для часто меняющихся атрибутов. Мы можем создать мини-измерение для атрибутов демографии клиента, таких как аренда дома, наличие детей или уровень дохода. Измерение будет содержать строку для каждой уникальной комбинации этих атрибутов, встреченной в данных. Статические и редко меняющиеся атрибуты будут храниться в нашем большом исходном клиентском измерении. Таблица фактов фиксирует связь исходного клиентского измерения и демографического мини-измерения с помощью загруженных строк.
Для организаций, работающих с клиентскими данными, весьма необычно создавать последовательность связанных мини-измерений. Финансовая организация может иметь мини-измерения для клиентских оценок, статусов просрочек, поведенческой сегментации и атрибутов кредитных бюро. Соответствующие мини-измерения связаны с исходным клиентским измерением через внешние ключи в строках таблицы фактов. Мини-измерения эффективно фиксирует изменения, а также предоставляют меньшую точку входа в таблицу фактов. Они особенно полезны в случаях, когда анализ не требует детальности уровня клиента.
Пользователи часто хотят анализировать клиентов без анализа показателей в таблице фактов, особенно когда сравнивают количество клиентов по значениям определенного атрибута. Часто бывает полезным включить текущие суррогатные ключи к мини-измерениям в исходном клиентском измерении, чтобы поддержать такой анализ без необходимости выполнять соединение с таблицей фактов. Простое или материализованное представление даёт полную картину текущего состояния клиентского измерения. В таком случае, воздержитесь от попытки фиксировать суррогатные ключи мини-измерения как атрибуты медленно меняющегося измерения типа 2. Это вернет вас в самое начало, к выходящему из под контроля клиентскому измерению, к слишком частым изменениям типа 2.
Другим украшением измерений является добавление агрегированных показателей производительности в клиентское измерение, таких как итоговый чистый объем закупок в прошлом году. Пока мы обычно рассматриваем показатели производительности как факты в таблице фактов (и они, определенно, должны быть там!), мы распространяем их в измерении для выделения и ограничения, а не для использования в численных подсчетах. Бизнес-пользователи будут признательны за включение этих показателей для анализа. Конечно, распространение этих атрибутов в нашу таблицу измерения наложит дополнительные требования на систему обработки данных. Мы должны гарантировать точность и целостность этих агрегированных атрибутов.
Альтернативным и/или комплементарным подходом к хранению текущих агрегированных показателей производительности является группировка агрегированных значений в группы или сегменты, такие как определение клиента по кредитной карте как заемщика или вкладчика. Скорее всего, это в этом больше пользы для анализа, чем в текущих агрегированных значениях, и имеется дополнительное преимущество в обеспечении целостного определения сегментов во всей организации. Этот подход работает особенно хорошо в комбинации с техникой мини-измерений.
Совет №54. Реализация двух перспектив: исторической и текущей
Как и многое в нашей жизни, перемены неизбежны в атрибутах измерения. Большинство читателей Советов Разработчику хорошо знакомы с тремя базовыми техниками медленно меняющихся измерений (SCD):
Тип 1: Переписать атрибут заново.
Тип 2: Добавить еще одну запись в измерение
Тип 3: Добавить еще один атрибут
Когда изменяются атрибуты измерения нам часто необходимо сохранить исторически точные значения, а также обеспечить возможность накопления исторических фактов на базе текущих характеристик. Потребность в этой возможности растет вместе с развитием аналитического сообщества. Двадцать лет назад аналитикам хватало таблиц с измерениями, которые обновлялись (переписывались) ежедневно, с использованием текущих атрибутов. Потом маятник качнулся в сторону точной и полной фиксации всех изменений с помощью SCD Тип 2. Теперь все больше людей хотят не только приготовить пирог (или стейк), а также и съесть его.
Несколько лет назад мы обсуждали комбинированный подход поддержки такой функциональности в Совете №15. Комбинирование приёмов обработки медленно изменяющихся измерений. В том Совете мы создавали строки Типа 2 для сохранения изменений исторического атрибута, в сочетании с одним или более дополнительными «текущими» атрибутами Типа 3 в каждой строке. Атрибут Типа 3 переписывается (как в случае Типа 1) для текущей и всех предыдущих строк Типа 2, так что аналитики могут выполнять запросы как к исторически точным атрибутам, так и к текущим значениям. Большая гибкость обеспечивается комбинированным подходом к SCD, хотя и ценой дополнительной сложности.
Физически, эти техника может быть реализована созданием таблицы измерений с двумя колонками (исторической «как было» и текущей) для каждого атрибута, требующего такой гибкости. В качестве альтернативного варианта, вы можете держать текущие значения всех атрибутов в отдельной таблице, соединяемой по естественному ключу с измерением (например Employee ID), вместо суррогатного ключа измерения. Отдельная таблица содержит всего одну строку текущих данных для каждого естественного ключа таблицы измерения; значения переписываются при каждом изменении. Наверняка тот же естественный ключ возникнет в строках измерения Типа 2 с уникальными суррогатными ключами. Для легкости использования основное измерение и отдельная таблица текущих значений могут быть объединены в представлении, в случае если это не несет серьезного ущерба производительности.
Если вам необходимо обеспечить фиксацию сотен текущих и исторических атрибутов в большой таблице измерения, техника описанная выше будет трудноприменима. В такой ситуации вам лучше рассмотреть включение в таблицу фактов естественного ключа измерения в качестве дополнительного внешнего ключа. Теперь у вас есть две схожие, но довольно различные таблицы измерения, ассоциированные с таблицей фактов. Во-первых, суррогатный ключ измерения соединяется с обычным измерением с исторически точными данными Типа 2. Эти атрибуты фильтруют или группируют факты по значениям атрибута в момент загрузки данных факта. Во-вторых, естественный ключ измерения (или статическая ссылка) соединяется с таблицей измерения только с текущими значениями Типа 1. Чтобы снизить риск введение пользователя в заблуждение, имена колонок в этой таблице должны начинаться с “current” (текущий). Эти атрибуты измерения используются для агрегации или фильтрации фактов по текущим значениям, независимо от значений в момент загрузки строки факта.
Вот всех ситуациях, описанных в этом Совете Разработчику, результаты запроса могут значительно отличаться в зависимости от того, какая таблица измерения использовалась для ограничения или группировки. Разные результаты допустимы, так как задавались разные вопросы. Как бы то ни было, эта возможность, допускающая ошибку или неверную интерпретацию, часто предоставляется только пользователям, понимающим описанную разницу.
Совет №55. Изучаем текстовые факты
В этом совете мы возвращаемся к рассмотрению фундаментального понятия, которое ставит в тупик многих разработчиков многомерных моделей – текстовых фактов (также называемых индикаторами, атрибутами фактов, примечаниями).
Некоторые из вас могут справедливо заметить, что фраза «текстовый факт» является оксюмороном. Тем не менее, мы часто получаем вопросы от наших клиентов или студентов о полях с индикаторами или заметками, которые вроде бы должны находиться в таблице фактов, но при этом не являются показателями, ключами измерений или вырожденными измерениями (см. Совет №46).
Обычно мы не рекомендуем моделировать эти так называемые текстовые факты в таблице фактов, а советуем попытаться найти им подходящие место в таблицах измерений. Вам не следует загромождать таблицу фактов несколькими описательными атрибутами по 20-40 байт каждый. С другой стороны, если вы вставляете в таблицу фактов короткие коды, то не нужно забывать создать таблицу, в которой для каждого кода приводится расшифровка (даже если вы абсолютно уверены, что ВСЕ и так уже давно знают все коды).
Первый вопрос, который вы должны себе задать о потенциальном текстовом факте – не следует ли поместить его в таблицу измерения? К примеру, тип клиента наверняка имеет одно единственное значение для определенного клиента, и поэтому его следует хранить как атрибут в таблице клиентов.
Если же мы не можем аккуратно встроить потенциальные текстовые факты атрибутами в измерения, то их следует сделать отдельными измерениями или отдельными атрибутами в «мусорном» измерении. Достаточно просто создать небольшие таблицы измерений, присваивающие суррогатные ключи типам платежей или транзакций, а затем использовать эти ключи в таблице фактов. Если в результате получается слишком много небольших измерений, то следует подумать об использовании «мусорного» измерения. Мы обсуждали мусорные измерения в совете №48. Есть несколько соображений, которые следует иметь в виду, принимая решения использовать ли отдельные измерения или собрать их атрибуты в мусорное измерение.
- Количество внешних ключей в таблице фактов. Если у вас около 20 внешних ключей, то возможно неплохо было бы схлопнуть часть из них.
- Количество строк в мусорном измерении. Помните, что теоретически возможное число уникальных комбинаций всех атрибутов может значительно превышать число реально встречающихся комбинаций. Желательно иметь не больше 100000 строк в мусорном измерении.
- Уместность и логичность комбинирования атрибутов. Не собьем ли мы с толку пользователя, если поместим практически никак не связанные по смыслу атрибуты в одну таблицу?
Наконец, как нам поступить в том случае, когда предполагаемый «факт» является текстовым полем свободной формы, таким как 240-байтный комментарий? Профилирование этого поля, разбор и кодирование значений сделало бы это поле наиболее полезным для аналитики. Но это всегда проще сказать, чем сделать.
Наш опыт показывает, что если поле, действительно, является текстом в свободной форме, то оно редко нужно для аналитики. Обычно эти комментарии нужны только для проведения время от времени детального исследования подозрительных транзакций. В такой ситуации лучше всего поместить эти текстовые поля в отдельное измерение, чем нагружать каждую строку в таблице фактов.
Совет №56. Многомерное моделирование для Microsoft Analysis Services
За последние несколько лет растущее количество наших студентов и клиентов спрашивали нас о Microsoft SQL Server 2000 Analysis Services (AS). Analysis Services, как серверный OLAP продукт, очень хорошо вписывается в технологию многомерного моделирования, которую в течение длительного времени развивает Kimball Group. Но подходит ли он идеально? Существуют ли вещи, которые Вам нужно знать, если вы проектируете многомерную модель данных, которая будет доступна из куба Analysis Services? Конечно, существуют!
Первая и наиболее сильная связь между кубом Analysis Services и реляционной многомерной моделью – это то, что куб должен быть построен из реляционной многомерной модели. Реляционный многомерный источник может быть в любой реляционной СУБД, хотя выгрузка данных из некоторых СУБД выполняется лучше, чем из других.
Многомерная модель на реляционной платформе и в кубе Analysis Services имеют измерения и факты, обе любят суррогатные ключи; обе отмечают важность использование хорошо продуманных иерархий, чтобы поддерживать навигацию по многомерным данным. Согласованные измерения в терминологии Кимбала называются разделяемыми измерениями в Analysis Services. Более развитые техники, как мусорные измерения (junk dimensions), ролевые измерения и бесфактовые таблицы фактов легко переносятся.
Наиболее важным различием между многомерным миром на реляционной платформе и Analysis Services OLAP- это поведение измерений. Чем более Вы знакомы с реляционными измерениями, тем более причудливыми Вы найдете измерения Analysis Services. Проблема в том, что на первый взгляд они выглядят похоже, но фактически ведут себя совершенно по разному. Рассмотрим реляционное измерение, например, клиент. Обычно оно становится в кубе несколькими, похожими на измерениями структурами. Каждый атрибут или иерархия по которым Вы хотите вести анализ должны иметь в кубе свое собственное измерение. Например, если Вы хотите сравнить продажи по полу или географическому региону, Вам нужны в кубе измерение пол и иерархия измерения география, в то время как в реляционной многомерной структуре они могут быть частью измерения Клиент.
В только что описанном примере Вам не нужно менять реляционную модель. В Analysis Services, Вы бы определили географическую иерархию в измерении Клиент. Вы сначала создали атрибут Пол как member property измерения Клиент и затем преобразовали его в виртуальное измерение. Это преобразование достаточно просто произвести, требуется только несколько кликов мыши, но это кажется странным и лишним для тех, кто глубоко разбирается с поведением реляционной модели. Microsoft осознал это и анонсировал, что в следующей версии Analysis Services измерения будут вести себя в большей степени как реляционные.
Мы коротко обобщим некоторые другие отличия и сходства, которые Вы можете встретить при работе с Analysis Services.
Что хорошо:
- Обычно измерениями родитель-потомок легче управлять и выполнять запросы, если они находятся в Analysis Services, по сравнению с реляционными измерениями. В реляционном измерении Вам понадобится перемещаться по иерархии используя таблицу с описанием связей. В Analysis Services, Вы просто моделируете реляционное измерение со структурой родитель-потомок и создаете измерение типа «parent-child».
- Analysis Services хранит все измерения в памяти, поэтому желательно ограничивать общее количество members по всем измерениям в пределах 5-7 миллионов на 32-х битной платформе. Вы можете увеличить это число в случае доступности 64-х битных систем приемлемой стоимости, но похоже, что усилия того не стоят.
- Вы можете определить многомерное выражение для того, чтобы вычислить все что угодно на любом уровне куба. Наглядный пример – это вычисление, определяющее складские остатки полуаддитивными по отношению ко времени. Обратной стороной является необходимость поиска и правильной реализации сложного выражения.
- Для инкрементального процессинга куба необходимо определить новые строки, которые нужно добавить к таблице фактов. Маркировка записей таблицы фактов с измерением для аудита или другими метаданными позволяет выделять их для инкрементального процессинга куба.
- SCD тип 2 легко реализуется в Analysis Services.
- Измерения Analysis Services могут быть построены из схем звезда или снежинка. Когда выполняются запросы к Analysis Services, не имеет большого значения, как именно структурированы таблицы измерений в реляционной части, хотя звезда, в общем случае, легче для сопровождения. Конечно, если запросы выполняются непосредственно к реляционной многомерной модели, то обычно звезда обеспечивает большую простоту и скорость выполнения запросов, чем снежинка. Например, прогнозные данные на уровне бренда потребуют и измерения на уровне бренда, в то время как фактические данные могут быть на уровне учетной единицы (SKU).
Что не очень хорошо:
- SCD тип 1 могут вызвать трудности, если измененная колонка является частью иерархии измерения. Если измененный атрибут является просто member property или вирутальным измерением, то это не проблема. Проблема возникает с восстановлением истории иерархического атрибута являются агрегаты. Analysis Services сталкивается с абсолютно такой же проблемой, как если бы Вы управляли агрегатами в реляционной базе данных. Хотя есть некоторые способы, которые обсуждаются в приведенном ниже Performance Guide.
- Измерения многие-ко-многим в Analysis Services 2000 ограниченные. Мы видели многих испытывающих разные способы, чтобы заставить их работать, но ни один из них не стал привлекательным на практике.
- Нет способа изменить строку фактов в кубе Analysis Services, вы может перестроить целиком куб. При небольших объемах данных Выможете перестроить куб целиком. При больших объемах, Вы могли бы изолировать изменяемые строк в партиции (вероятно в партиции за последние 30 дней) и полностью перестроить только эту партицию. Партиции требуют дорогой редакции Enterprise Edition.
Совет №57. Ранние факты
При создании хранилищ данных обычно предполагается, что измеряемые процессы (факты) появляется в хранилище тогда же, когда и контекст этих процессов (измерения). Если у нас есть и факты, и актуальные состояния измерений, то мы можем позволить себе некоторую роскошь: сначала вычислить нужные суррогатные ключи измерений, а затем использовать эти актуальные ключи при вставке записей в таблицу фактов.
При обработке измерений существует три варианта действий:
- Если объект (к примеру, Клиент) является новым членом измерения, то мы генерируем для него новый суррогатный ключ.
- Если объект является ИЗМЕНИВШИМСЯ вариантом Клиента, то мы используем технику медленно меняющихся измерений 2го типа: присваиваем Клиенту новый суррогатный ключ и сохраняем изменившееся описание клиента отдельной записью в таблицу измерения.
- Наконец, если Клиент уже является членом нашего измерения, и при этом его описание не изменялось, то мы просто используем ключ, который у нас уже имеется для этого Клиента.
В течение нескольких последних лет мы используем специальную модификацию этих процедур для работы с Запаздывающими Фактами (Late Arriving Facts), то есть с фактами, появляющимися в хранилище с большой задержкой. Это неприятная ситуация, так как нам необходимо просматривать всю историю измерения, чтобы найти записи, которые были актуальны на определенный момент в прошлом. Почитайте на эту тему статью Backward in Time.
Если бывают Запаздывающие Факты, то возможны ли Ранние Факты (Early Arriving Facts)? Как это может произойти? Бывают ли ситуации, в которых это действительно важно?
Ранние факты имеют место тогда, когда значения показателей появляются в хранилище раньше, чем их полное описание. Другими словами, состояния измерений в течение некоторого времени неизвестны или неоднозначны. Если наше хранилище обновляется с задержкой один или несколько дней, то мы обычно можем просто подождать появления правильных измерений. К примеру, описание нового клиента может приходить отдельным информационным поток с задержкой несколько часов. Мы можем просто подождать разрешения зависимости.
Но если мы строим хранилище данных реального времени, и должны сделать факт видимым уже СЕЙЧАС, хотя еще и не знаем полного его описания, то возникает интересный выбор. Пересмотрим наши действия по обработке измерений, используя в качестве проблемного измерения тех же Клиентов.
- Если натуральный ключ клиента распознается как уже существующий в измерении, то мы предварительно используем суррогатный ключ этой уже существующей, наиболее свежей версии записи о Клиенте. При этом мы должны быть готовыми к тому, что спустя некоторое время мы получим измененное описание этого Клиента. В таком случае мы
- добавляем в измерение новую запись с новым суррогатным ключом, а затем меняем значения внешних ключей в таблице фактов.
- Наконец, если мы уверены, что Клиент является новым членом нашего измерения, то мы создаем новую запись в измерении с новым суррогатным ключом, и заполняем все атрибуты заглушками (временными неопределенными значениями). Позже, когда мы получаем более полное описание клиента, мы возвращаемся к этой записи и просто обновляем (по типу SCD1) значения атрибутов. В этом случае нам, как минимум, не требуется модифицировать ключи в таблице фактов.
Невозможно избежать временного периода, когда измерение «не совсем правильные». Но эти шаги позволяют минимизировать влияние неизбежных обновлений ключей и атрибутов. Если ранние факты находятся в «горячей партиции», закрепленной в оперативной памяти, то агрегированные таблицы не нужны. Только когда «горячая партиция» перегружается в статичную часть хранилища данных (и когда уже известны правильные связи фактов и измерений), тогда требуется перестраивать агрегаты.
Совет №58. Портал BI (также известный как веб-сайт хранилища данных)
Успех хранилищ данных (DWH) и систем бизнес аналитики зависит от того, приносят они пользу организации или нет. Очевидно, что для извлечения выгоды, люди должны использовать IT-инфраструктуру компании. Так как портал BI является основной (а часто и единственной) точкой взаимодействия, команда BI должна обеспечить его позитивное восприятие.
Слишком часто домашняя страница портала BI сфокусирована на истории хранилища данных, текущем состоянии процесса загрузки (ETL), или на том, кто составляет команду, обслуживающую его. Это интересные вопросы, но чаще всего пользователи BI ищут другую информацию. Портал BI - это интерфейс пользователя к хранилищу данных. Он должен разрабатываться исходя, в первую очередь, из потребностей сообщества пользователей. Вот два базовых понятия веб-дизайна, помогающие при разработке портала: плотность и структура.
Плотность
Человеческий разум может принимать невероятные объемы информации. Человеческий глаз может распознавать изображения с разрешением около 530 пикселей на дюйм с расстояния 20 дюймов (Р. Н. Кларк). Сравните это с жалкими 72 пикселями на дюйм обычного дисплея компьютера. Наш мозг быстро обрабатывает информацию обращая внимание на важные элементы. Эта комбинация остроты зрения и умственных возможностей позволила нашим предкам выжить под воздействиям целого ряда угроз; от хищников в самом начале развития до ножа в стычке в баре. Браузер является платформой с настолько низким разрешением, что мы должны использовать его осторожно и эффективно насколько это возможно. Это означает что мы должны максимально заполнить страницы портала BI информацией, но мы не можем просто загрузить сотни не упорядоченных описаний и ссылок.
Структура
Наш мозг может удерживать всю эту информацию только если она дополнена организующей структурой. Так как основной причиной визита пользователей на портал BI является поиск информации, значительная часть домашней страницы должна быть посвящена осмысленной категоризации стандартных отчетов (canned report). Вообще, мы пришли к выводу, что лучший способ организации портала BI – вокруг основных бизнес-процессов (business process) компании. Категории бизнес-процессов позволяют посетителю быстро сделать выбор. Внутри каждой категории расположены детальные подкатегории, позволяющие быстро пройти домашнюю страницу, чтобы найти интересующую информацию.
Например, веб-сайт хранилища данных университета на своей домашней странице может содержать следующие категории отчетов (бизнес-процессов):
- Прием
- Выпуск
- Сотрудники
- Учебный процесс
- Финансы
- Гранты
Каждая из них может ссылаться на другую страницу с дополнительными описаниями и ссылками на отчеты. Мы можем повысить плотность информации, вытащив некоторые подкатегории на домашнюю страницу:
- Прием: Статистика заявлений, Предложения и одобрения, Финансовая помощь
- Сотрудники: Общая численность, Страховка и отпуск, Компенсационная дискриминация
- Учебный процесс: Регистрация, Преподаватели и курсы, Степени и специализации
Повышение плотности таким способом помогает определить каждую категорию и детализировать пути навигации перед тем как пользователь должен перейти на следующую страницу. Одним из способов протестировать домашнюю страницу вашего портала является измерение доли видимой страницы (развернутый на весь экран браузер, монитор среднего размера), выделенной для предоставления пользователям доступа к информации. Эта доля должна быть по крайней мере 50%. Некоторые дизайнеры считают целью значение в 90%.
Больше структуры
Категории помогают упорядочить контент, но веб-сайту также нужна физическая структура. Чтобы облегчить пользователям навигацию, необходимо чтобы веб-сайт имел стандартный внешний вид (обычно, общий стиль компании).
Больше контента
Не смотря на то, что основной задачей портала является предоставление стандартных отчетов, он должен предлагать значительно больше, чем просто отчеты. В дополнение к категориям и спискам отчетов мы должны предоставить доступ ко всему спектру инструментов и информации, в том числе:
- Инструмент поиска, индексирующий каждый отчет, документ и страницу портала BI
- Браузер метаданных (metadata browser)
- Онлайн-курсы, руководства, примеры отчетов и страницы помощи
- Форма запроса помощи и контактная информация
- Статусы, предупреждения, опросы, инсталляция и прочая административная информация
- Возможно новостная/дискуссионная группа, ориентированная на поддержку
- Персонализация, дающая пользователям возможности сохранять отчеты или ссылки на своей собственной странице
Этой информации следует располагаться в нижнем правом углу, наименее ценном месте на экране (по крайней мере, в русском и английском языках, где читают слева направо и сверху вниз).
Создание эффективного портала BI - это значительная работа, но именно она ведет к повышению ценности хранилища для работы компании. Каждое слово, заголовок, описание, функция и ссылка на портале должны быть связаны с содержимым хранилища или системы BI. Обзор и тестирование дизайна портала должно проводится с будущими пользователями, они должны находить определенные отчеты и другую информацию. Убедитесь в том, что вы не создаете слабое звено.
Совет №59. Удивительная польза профилирования данных
Профилирование данных это серая лошадка технологий хранилищ данных. Мне кажется что большинство из нас думает о профилировании данных, как о чем-то, что вы делаете после того как была построена система ETL. В этом представлении, профилирование отыскивает небольшие аномалии, что могут потребовать очистки перед загрузкой данных в промышленную среду. Обнаружение этих аномалий перед переходом в промышленную среду должно предохранить команду разработчиков хранилища данных от маленьких сюрпризов.
В последние годы, при работе над новой книгой об ETL с Joe Caserta я глубоко погружался в детали ETL процессов, необходимых для построения хранилища данных. Возможно самым большим откровением было открытие степени недооценки профилирования данных в типичном проекте по созданию хранилища.
Что такое профилирование данных?
Профилирование данных это
систематический упреждающий анализ данных систем-источников
, начиная от подсчета байтов и проверки количества элементов до самого глубокого анализа соответствия данных высокоуровневым целям хранилища данных.
Практики профилирования данных разделяют анализ на последовательность проверок, начиная с отдельных полей и заканчивая всеми таблицами базы данных. Отдельные поля проверяются на соответствие содержимого определениям базового типа данных и домена. Особенно полезно оценить количество строк содержащих пустое значение (NULL) или нарушающих определение домена. Например, если определение домена это «телефонный номер», то текстовые записи четко иллюстрируют проблему. Лучшие инструменты профилирования данных подсчитывают, сортируют и отображают записи нарушающие определения типа данных и домена.
Двигаясь от единичных полей, профилирование данных описывает связи, обнаруженные между полями одной таблицы. Поля реализующие ключ таблицы могут быть отображены, вместе с высокоуровневыми отношениями один-ко-многим, реализующими иерархии. Проверка того что дожно быть ключом особенно важна, так как нарушения (дубликаты значений ключа) являются или серьезной ошибкой или отражают бизнес-правило, которое не было учтено при разработке ETL.
Отношения между таблицами также проверяются на шаге профилирования данных, включая предполагаемые отношения внешний ключ – первичный ключ и наличие родителей без потомков.
Наконец, профилирование данных может быть специально настроено для проверки сложных и уникальных бизнес-правил, таких как проверка выполнения всех условий для одобрения финансирования серьезных действий на рынке ценных бумаг.
Надеюсь что по мере того как я описывал возможности профилирования данных вы представили себе этот процесс как нечто в самом начале проекта, где профилирование может значительно помочь разработке и сократить время. В сущности, я пришел к выводу что профилирование данных должно быть обязательным «следующим шагом», после сбора бизнес-требований, в каждом проекте по созданию хранилища данных. В ходе моего последнего исследования ETL я пришел к следующему списку того, что может быть сделано с помощью профилирования:
- Общее решение «Продолжать – Не продолжать» для всего проекта! Профилирование может обнаружить что данные, от которых зависит проект, просто не содержат информации на базе которой могут приниматься планируемые решения. Значение такого результата трудно переоценить, несмотря на сопряженные разочарования.
- Проблемы с качеством данных в системах-источниках, которые должны быть решены (внесением изменений в источники) до продолжения проекта. Несмотря на немного меньший драматизм чем отмена всего проекта, эти изменения являются огромной внешней зависимостью, которой нужно уметь управлять чтобы достичь успеха с хранилищем данных.
- Проблемы с качеством данных, которые могут быть решены в ETL процессе, после того как данные были извлечены из источников. Понимание этих проблем влияет на логику трансформаций в ETL и на механиз обработки исключений. Эти проблемы также являются подсказкой в оценке времени, ежедневно требуемого для ручной обработки и исправления ошибок.
- Непредвиденные бизнес-правила, иерархические структуры, отношения внешний ключ – первичный ключ. Понимание данных на детальном уровне предостережет от серьезных проблем в разработанной ETL системе.
Наконец, важным достоинством (о котором, возможно, лучше умолчать при разговоре с руководством) профилирования является тот факт, что команда внедренцев выглядит как будто они знают что делают. Корректно предсказывая сложности с качеством данных, команда избегает неприятных (для карьеры) сюрпризов при нахождении БОЛЬШИХ проблем в самом конце проекта.
Совет №60. Большие перемены, происходящие в BI
На проходившей на прошлой неделе (речь идет о конференции, состоявшейся в начале октября 2004 г. – прим. переводчика) конференции Business Intelligence Perspectives, проводимой журналом Computerworld в Палм Спрингс, две интересные темы были наиболее заметными, тем самым дав сигнал о том, что в сфере business intelligence (BI) происходят большие перемены.
1. Соблюдение требований регуляторов является своеобразной «путевкой в жизнь» для BI
Ряд докладчиков был изумлен тем фактом, что новые требования регулирующих органов по раскрытию финансовой информации, особенно положения закона Сарбейнса-Оксли, привели к тому, что компании стали охотнее тратить деньги на модернизацию своих систем BI. Как сказал один из них: «Все, что вы должны сделать, это упомянуть о соблюдении требований регуляторов, и предложение о выделении средств получает одобрение». Но большинство докладчиков одновременно выразили озабоченность по поводу того факта, что никто не знает, что на самом деле понимается под этими «требованиями о соответствии». Не только они не расписаны в конкретных технических терминах технологии баз данных, но и появляется ощущение, что вопрос реального воздействия, которое эти требования оказывают, будет дебатироваться в судах, причем отделам ИТ придется защищать свои методы как надежные и «ответственные с коммерческой точки зрения».
Очевидно, что большинство отделов ИТ, заинтересованных в соблюдении требований регуляторов, будут заниматься перестраховкой. И, конечно же, закон Сарбейнса-Оксли не является единственным в своем роде. Существует, в зависимости от того, каким бизнесом вы занимаетесь, наверное, целое множество перекрывающих друг друга положений о раскрытии финансовой информации, выдвигающих сходные требования.
Подход, который можно считать безопасным с точки зрения соблюдения большинства требований о соответствии, включал бы в себя возможность:
- Прослеживать происхождение каждой выходной метрики и ключевого показателя производительности, появляющихся в любом отчете
- Прослеживать влияние любого первоначального или промежуточного элемента данных на конечный отчет
- Доказать то, что входные данные не были изменены
- Доказать тот факт, что выходные метрики и ключевые показатели производительности получены на основе исходных данных при помощи документированных преобразований
- Документировать все преобразования, сделанные как в прошлом, так и настоящем
- Перезапускать все старые процессы ETL (возможно)
- Регистрировать и отображать все случаи доступа к выбранным данным, как пользователей, так и для целей администрирования (возможно)
Этот список является материалом для исследования для еще десяти Советов!
2. Анализ последовательности действий для систем BI подобен покорению горы Эверест
Некоторые из самых интересных и пугающих примеров, приведенных на конференции, описывали случаи «прочесывания» огромных баз данных для получения ответа на вопросы, которые ставит поведение клиентов. Andreas Weigend, профессор университета Стэнфорда, бывший Chief Scientist в компании Amazon, рассказал об исследовании, проведенном в Amazon, цель которого заключалась в нахождении задержки (в днях) между моментом времени, когда клиент первый раз нажал на ссылку, ведущую к товару, и тем моментом, когда он в конце концов купил его. Это задача необычайной трудности. Поскольку большинство нажатий не приводят к покупке, вам приходится ждать до тех пор, пока покупка не совершена, и затем возвращаться назад (часы, дни, недели) и находить в океане записей о посещении сайта то самое первое нажатие, произведенное клиентом на ссылку о товаре.
Потенциальный объем данных, который организации вроде Amazon хотят просматривать, просто ошеломляет. Компания Amazon хранит каждый случай демонстрации ссылки в своих исторических данных. Демонстрация ссылки – это присутствие ссылки на отображаемой странице. Это не означает, что пользователь нажал на ссылку. Amazon сохраняет терабайты таких данных каждый день!
Хранение демонстраций ссылок – это только начало «всемирного потопа» данных, который по-настоящему случится тогда, когда тэги RFID будут помещены на каждую единицу товара. В этом случае, не только объем данных приводит в ужас, но и сами данные часто сохраняются на различных серверах, каждый из которых служит «дверью» в различные территориальные подразделения компании, географические пункты и периоды времени. Эти проблемы выдвигают на повестку дня вопрос: а является ли реляционная модель и язык SQL адекватными средствами, способными справиться с ними. Тем не менее, произвольные вопросы, которые люди хотят задавать этим данным, требуют того же типа доступа, который так успешно обеспечивался реляционными базами данных для гораздо меньших источников данных.
Эти два больших сдвига в BI имеют различный характер. Первый (соблюдение требований регуляторов) подобен балласту, и второй (анализ поведения) подобен воздушному шару. Но, по моему мнению, они оба реальны и долговечны. Они не оставят нас без работы.
Совет №61. Оперируем всеми датами
Достаточно часто мы встречаем несколько десятков различных дат, представляющих важную информацию для бизнеса, и каждая из этих дат должна быть включена в многомерную модель. Например, в финансовой организации мы имеем дело с датой внесения вклада, датой снятия со счета, датой выписки чека, датой обработки чека, датой открытия счета, датой выпуска карты, датой представления продукта, датой начала рекламной кампании, датой рождения клиента, датой начала действия записи, датой загрузки записи, отчетным месяцем и т.д.
В первую очередь необходимо знать, что не все даты создаются и обрабатываются одинаково. В основном даты хранятся в таблицах фактов как внешние ключи на измерение «Дата». Большая часть оставшихся дат становятся атрибутами прочих других измерений. Наконец, некоторые даты добавляются в модель для поддержки ETL или возможностей аудита.
Представим, что в нашей финансовой организации проектируется таблица фактов для транзакций по текущем счетам, таких как взносы на счет, выписывание чеков, снятие денег в банкомате. Каждая строка в таблице фактов соединена с измерениями «Тип транзакции» и «Дата транзакции». Чем является дата с точки зрения бизнеса (датой выписки чека, внесения средств на счет, или снятия средств в банкомате) определяется типом транзакции. В этом примере мы не будем включать в таблицу фактов три разных даты, так как только одна имеет смысл для каждой транзакции.
В других ситуациях одна строка таблицы фактов может определяться двумя различными датами, такими как дата проведения транзакции и дата вставки записи о транзакции. В этом случае обе даты будут сохранены как уникальные внешние ключи на измерения. Мы должны создать одну физическую таблицу с датами, и представления (views) для логических ролей, в которых может выступать дата.
Предположим теперь, что наш клиент решил «обобщить» свою таблицу фактов таким образом, чтобы она содержала транзакции разных бизнес-процессов. В такой «обобщенной» модели увеличивается число внешних ключей на таблицу дат, в которую также добавляется значение «Не применимо». В нашем примере с финансовой компанией будем считать, что в таблицу фактов сводятся транзакции по текущим счетам, депозитам, кредитным картам и ипотечным кредитам.
Все записи в этой таблице фактов представляют транзакции в обобщенном виде, но рождаются в результате разных процессов. Мы являемся сторонниками проектирования на основе бизнес процессов и, как правило, на каждый бизнес-процесс создаем отдельную таблицу фактов. Выписка чека весьма отличается от погашения задолженности по кредиту. Эти два процесса имеют различные показатели и размерности, что приводит к отдельным таблицам фактов, каждая со своими уникально именованными датами.
Очевидно, что мы также включаем измерение дат в периодический снимок для определения того, к какому периоду относится запись, например, снимок за месяц. Это суженное подмножество измерения дат, согласованное с нашим основным измерением.
Многие важные с точки зрения бизнеса даты включаются как атрибуты в таблицы измерений. Дата открытия счета является атрибутом справочника счетов. Аналогичным образом дата рождения клиента, дата выпуска продукта в продажу и дата начала рекламной кампании принадлежат, соответственно, измерениям «Клиент», «Продукт» и «Рекламная кампания».
Если даты являются атрибутами измерений, мы должны продумать, каким образом они будут использоваться в анализе. Достаточно ли просто знать дату открытия счета, или нужно дополнительно иметь атрибуты с годом открытия счета, месяцем открытия счета и месяцем/годом? Эти дополнительные атрибуты значительно расширяют возможности пользователя по составлению интересных запросов путем группировки по году и/или месяцу открытия счета.
Для наиболее широких возможностей анализа на базе атрибутов с датами в этих измерениях вам следует использовать измерение «Дата». При этом, вы включаете в атрибуты измерений не сами даты, а суррогатные ключи из измерения «Дата», а затем создаете представление измерения «Дата» с правильными бизнес-наименованиями всех атрибутов. Эта техника открывает нам для анализа все богатство атрибутов основного измерения «Дата». Следует иметь в виду, что слишком интенсивное использование этой техники может пойти в ущерб простоте работы и производительности системы. Следите также за тем, чтобы все даты в атрибутах ваших измерений попадали в интервал дат, хранимый в измерении «Дата».
Существуют дополнительные даты, необходимые команде разработчиков для управления ETL-процессом и поддержки аудита. Атрибуты с началом срока действия записи, окончанием срока действия записи, датой вставки и датой последнего обновления должны включаться в каждую таблицу измерения. Хотя эти даты и не нужны для анализа конечным пользователям, для разработчиков хранилища данных они являются бесценными.
Совет №62. Дополнительные иерархии
Пользователи часто хотят видеть данные, сгруппированные различным образом. В простейшем случае одно подразделение (к примеру, маркетинговый департамент) имеет свою иерархию клиентов, а другое подразделение (к примеру, отдел продаж) хочет видеть другую иерархию. Если все действительно настолько просто, то имеет смысл включить обе иерархии в измерение «Клиент» и назвать их правильным образом. К сожалению, большее число иерархий, встроенных прямо в измерение, сделает его малопригодным для использования.
Необходимость более гибкой реализации дополнительных иерархий возникает тогда, когда несколько подразделений хотят видеть данные по-своему, причем в нескольких разных вариациях. В таком случае необходимо поработать с пользователями и определить наиболее распространенную группировку данных. Эта группировка станет стандартной иерархией используемой по умолчанию, и будет встроена прямо в основную таблицу измерения. Также можно поступить еще с несколькими наиболее широко используемыми иерархиями для простоты работы пользователей.
Для поддержки дополнительных иерархий создается отдельная таблица, с помощью которой пользователь может сгруппировать данные по любой из имеющихся иерархий. На рисунке показан пример такой промежуточной таблицы (bridge table) CustomerRegionHierarchy для группировки по географическому положению.
Каждая иерархия в промежуточной таблице должна быть полной, т.е. начинаться с того уровня базового измерения, к которому присоединена промежуточная таблица, и заканчиваться самым верхним уровнем. К примеру, таблица CustomerRegionHierarchy соединена с уровнем State. Конечно, можно начать и с более детального уровня, такого как ZipPostalCode, но это приведет к увеличению таблицы и может не дать никаких преимуществ. С другой стороны, если есть четкое требование по созданию альтернативных группировок почтовых индексов, то таблица с дополнительными иерархиями естественно должна начинаться с уровня ZipPostalCode.
Для упрощения анализа и создания отчетов промежуточная таблица должна содержать описание и стандартной иерархии. Стандартная иерархия становится используемой по умолчанию во всех предварительно настроенных отчетах, но пользователю представляется возможность переключиться на другую иерархию. Отдельная таблица Hierarchy с одной строкой на каждую иерархию упрощает поддержку системы, но визуально усложняет дизайн. При необходимости можно провести денормализацию и объединить Hierarchy и CustomerRegionHierarchy.
Таблица CustomerRegionHierarchy должна использовать только в предварительно настроенных отчетах, либо опытными пользователями. Если не ограничить HierarchyName единственным значением, то в результате соединения таблиц Customer и CustomerRegionHierarchy каждый клиент будет посчитан несколько раз. Каждый отчет, в котором используются дополнительные иерархии, должен использовать стандартную иерархию по умолчанию, и позволять выбирать дополнительные иерархии строго по одной.
Дополнительные иерархии - хороший пример дополнительных преимуществ хранилищ данных. Такие индивидуальные группировки данных широко используются пользователями, но определения этих группировок не централизованы и не формализованы. Обычно они хранятся где-нибудь в электронных таблицах на компьютерах пользователей.
Совет №63. Строим систему захвата изменений данных
ETL-поток начинается с передачи из источника (source system) в хранилище (DHW) свежей порции данных. Почти в любом хранилище требуется передавать только данные, изменившиеся с момента предыдущей загрузки. Полное обновление таблиц фактов (fact) и измерений (dimension) обычно нежелательно.
Вычленение в источнике только новых данных называется «захват изменившахся данных» (changed data capture) и часто сокращается до CDC в архитектурных диаграммах. Идея CDC кажется достаточно простой: передавать данные, которые изменились с момента последней загрузки. Но создать хорошую систему CDC не так просто, как кажется.
Вот основные цели создания системы CDC:
- Вычленение изменившихся данных для проведения выборочной обработки вместо полного обновления.
- Захват всех изменений исходных данных (вставки, удаления, обновления), включая изменения, выполненные через нестандартные интерфейсы.
- Пометка измененных данных кодами для возможности отличить исправления ошибок от реальных обновлений.
- Расширение набора метаданных для отслеживания соответствия стандартам.
- Захват изменившихся данных как можно проще, желательно до передачи данных пакетом в хранилище.
Первый шаг при создании системы CDC – это обнаружение изменений. Существует четыре основных способа для обнаружения изменений:
-
Колонки аудита.
В большинстве случаев системы-источники (source system) содержат колонки аудита. Эти колонки добавляются к каждой таблице и содержат дату и время вставки и последнего обновления. Значения этих колонок обычно заполняются с помощью триггеров, запускающихся автоматически при вставке или изменении записи. Иногда, по причинам, связанным с производительностью, значения заполняются конечными приложениями, а не триггерами (trigger) СУБД. В случае, если эти колонки заполняются любым способом, кроме триггеров, следует уделить особое внимание вопросу их достоверности. Следует проанализировать и протестировать каждую колонку, чтобы убедиться, является ли она надежным индикатором изменившейся записи. Если вы встречаете в этой колонке пустые значения, то следует поискать другой способ обнаружения изменений. Типична ситуация, препятствующая использованию колонок аудита в системе ETL: значение колонок генерируются конечными приложениями, но администраторы БД (DBA) запускают служебные скрипты, модифицирующие записи. Если это ваш случай, то вы рискуете время от времени пропускать изменившиеся данные при инкрементальных загрузках.
-
Анализ журнальных файлов.
Способ заключается в периодическом копировании журналов повторного выполнения (redo log) базы данных и разборе этих журналов с целью выделить транзакции, влияющие на интересующие вас таблицы. Можно также в постоянном режиме «опрашивать» журналы и обрабатывать транзакции «на лету». Анализ журнальных файлов является, наверное, самым малоприятным способом. Нередко журнальные файлы переполняются, что блокирует дальнейшие транзакции. Когда такое случается в промышленной транзакционной системе, рефлекторной реакцией ответственного администратора БД является очистка журналов, чтобы бизнес мог продолжать работать. Но при очистке журналов теряется информация о транзакциях. Если вы перебрали все варианты, и анализ журналов оказался единственным подходящим, то следует убедить администратора БД создать для вас специальный журнал транзакций.
-
Выборки по времени.
Выборка по времени подразумевает, что вы выбираете все записи, у которых дата вставки или последней модификации равна sysdate-1, подразумевая, что вы выбираете все «вчерашние» записи. Звучит отлично, верно? Неверно! Загрузка записей, основанная только на дате, является частой ошибкой всех начинающих разработчиков ETL. Этот процесс ужасно ненадежен. Загрузки, основанные на временной метке (timestamp), дублируют записи в случае перезапуска процесса загрузки из-за сбоя. Это значит, что в случае любого сбоя требуется ручное вмешательство для очистки. При этом, если ночная загрузка оканчивается сбоем и пропускается день, существует риск, что пропущенный день так никогда и не попадет в хранилище.
-
Полное сравнение.
При полном сравнении сохраняется полный снимок БД на вчерашний день, и сравнивается по каждой записи с сегодняшней БД для поиска каждого изменения. Хорошая новость заключается в том, что это наиболее общий способ – вы гарантированно найдете все изменения. Очевидная плохая новость состоит в том, что в большинстве случаев этот способ очень ресурсоемкий. Если вам требуется провести полное сравнение, то попытайтесь сделать его на системе-источнике, чтобы не вытаскивать всю БД в среду ETL. Проработайте также вопрос о применении контрольных сумм (CRC) для быстрого выяснения того, изменилась или нет сложная запись.
Этот совет указывает лишь на каплю проблем, окружающих CDC. Для более глубокого изучения вопроса я могу предложить следующее. Во-первых, вы можете почитать новую книгу The Data Warehouse ETL Toolkit, которую я написал совместно с Joe Caserta, для более детального рассмотрения каждого из описанных выше вариантов. Во-вторых, вы можете посетить мои семинары для архитекторов систем ETL.
Совет №64. Избегайте изоляции подразделения DW/BI
Наверное, это просто совпадение, но в последнее время несколько человек задали мне схожий вопрос: «Следует ли командам хранилищ данных (DW) или business intelligence (BI) собирать требования от бизнеса?». Честно говоря, у меня волосы встают дыбом от такой постановки вопроса. Я обеспокоена тем фактом, что слишком много организаций чересчур обособили свои подразделения DW/BI.
Конечно, до некоторой степени это разграничение является естественным, особенно когда ресурсы, отведенные на DW/BI, растут по мере расширения инфраструктуры, создавая очевидные проблемы с нормой управляемости (наиболее простое определение этого термина: количество прямых подчинённых у одного менеджера - прим. переводчика). Также разделение труда позволяет специализацию. Если провести аналогию между инфраструктурой DW/BI и рестораном, то можно сказать, что некоторые члены команды чрезвычайно искусны в приготовлении блюд на кухне, в то время как другие очень заботливы и внимательны по отношению к клиентам, обеспечивая тем самым их повторный визит. Существует, насколько можно ожидать, немного официантов, которым вдруг следует облачиться в одеяния шеф-повара, и наоборот.
Несмотря на распределение обязанностей, кухня и зал ресторана тесно связаны между собой. Никто из них не может успешно существовать сам по себе. Даже самым лучшим поварам требуется хорошо обученная, хорошо смазанная «машина» в виде зала ресторана, а самые привлекательные залы нуждаются в разнообразной и качественной еде, создаваемой на кухне. Только такой, полный набор может доставить приятные ощущения от похода в ресторан (и поддержать финансовую устойчивость самого ресторана). Вот почему шеф-повар часто собирает вместе официантов перед периодами наибольшего потока посетителей для того, чтобы «сверить позиции» и дать наставления.
Мы заметили, что в мире DW/BI некоторые команды следуют изоляционистскому подходу. Особенности культуры организации и реалии отношений внутри её ещё больше усложняют жизнь. Могут существовать кухня и зал, но между ними может не быть створчатой двери. Это как если бы существовало окно (выше уровня глаз), через которое принимаются заказы и выдаются приготовленные блюда, но две команды специалистов при этом не общаются или не сотрудничают между собой. При таком сценарии вы получаете модели, которые не могут быть заполнены данными приемлемым образом. Или модели данных, которые либо не отвечают интересам «посетителей» и/или не позволяют им эффективно использовать свои инструменты. Или же инструменты «посетителей» перегружены работой или обладают низкой производительностью потому, что они выполняют еще раз ту работу, которая могла бы быть сделана один раз на кухне, и результаты которой могли стать достоянием всей организации. В худшем случае, стена становится настолько неприступной, что столовая BI использует другую кухню (или же создает свою собственную) для приготовления блюд.
Хранилище данных должно служить основанием для эффективной бизнес-аналитики (business intelligence). Слишком много людей направили свои усилия на что-то одно, забывая при этом о другом. Безусловно, вы можете создать хранилище данных, не заботясь о бизнес-аналитике, и наоборот, но долго так продолжаться не может. Изоляционизм не может служить примером здорового подхода к созданию и поддержанию инфраструктуры DW/BI. Даже если вы находитесь в рамках другой структуры подчинения, общение и сотрудничество просто необходимы.
Совет №65. Документируйте ETL-систему
Независимо от того, используете ли вы для ETL специализированные инструменты, или разрабатываете своими руками, ETL-система является таким же программным обеспечением, как и любое другое, и должна быть документирована. По мере развития самого хранилища данных, ETL-система развивается с ним в ногу. Вы и ваши коллеги должны иметь возможность быстро разобраться как в архитектуре системы, так и в мельчайших деталях.
Существует распространенный миф, что ETL-инструменты самодокументируются. Это верно только в сравнении с самописными системами. Не верьте этому! Всегда нужно проектировать архитектуру ETL-системы. И всегда нужно документировать эту систему. Да, нужно писать документ.
Первым делом при разработке легко сопровождаемой ETL-системы нужно остановиться и задуматься о том, что вы делаете. Как вы может разбить системы на модули? Как эти модули вместе сложатся в единый поток? Разрабатывайте систему таким образом, чтобы каждой таблице в хранилище соответствовал отдельный пакет, поток, модуль (в общем, то, как это называется в используемом вами инструменте). Напишите документ, описывающий общий подход – хотя бы несколько страниц и один-два скриншота.
Спроектируйте шаблон модуля и сгруппируйте похожие действия. Шаблон должен ясно определять, какие элементы используются для извлечений, трансформаций, поиска по справочникам, приведений к общему виду, обработок изменений в справочниках, и загрузок в целевые таблицы. Затем задокументируйте шаблон самым скрупулезным образом, используя скриншоты. Документация должна фокусироваться на том, что делается, а не на деталях того, как делается каждый шаг.
Далее, по шаблону постройте модули для каждого измерения и таблицы фактов. Если ваш ETL-инструмент позволяет задавать расположение отдельных элементов, то делайте все модули выглядящими одинаково. Тогда можно посмотреть в верхнюю левую часть, и будет легче понять витиеватую логику в середине. Модули для каждой таблицы-измерения должны выглядеть действительно похожими друг на друга; то же самое и для модулей таблиц фактов. Документация для каждой таблицы должна концентрировать внимание на отличиях от шаблона. Не повторяйте детали, уделяйте внимание только важным моментам. Приправьте ETL-систему комментариями, если инструмент позволяет это сделать.
Наконец, ваш ETL-инструмент может поддерживать в некотором виде самодокументирование. Используйте эту функциональность. Но так как в результат обычно либо откровенно слабый (например, набор скриншотов), либо наоборот слишком детальный (перечень значений всех свойств всех объектов), то рассматривайте это лишь как дополнение к нормальной документации. Наш опыт показывает, что обычно это не очень полезно.
Совет №66. Паралич при проектировании
Многие команды разработчиков излишне рьяно берутся за дело. Они принимаются за разработку раньше, чем потратят достаточно времени и сил на проектирование модели данных, составление исчерпывающего набора бизнес-правил, планирование процедур загрузки. Они устремляются вперед на всех парах, а в результате получают в хранилище неверные или неполные данные, переделывают свою работу, и доставляют сами себе хлопоты.
У других команд противоположные проблемы. Они являются приверженцами тщательной предварительной проработки всех критичных задач. Они нацелены на качество, полноту и согласованность данных. Тем не менее, эти команды часто увязают в вопросах, которые должны были быть решены уже давным-давно. Как правило, это тупиковое положение становится очевидным в самый неподходящий момент: когда сроки уже поджимают, а решения, которые должны быть уже приняты и находиться в стадии реализации, остаются непринятыми.
Самые серьезные проблемы сопряжены со сложным выбором, и среди членов команды есть несогласные даже с самыми удачными решениями. Простые проблемы уже давно решены, а вот с более сложными задачами все не так легко. Кроме продолжительного времени, затрачиваемого на исследования, профилирование данных, обсуждение архитектуры и неформальных разговоров, ничто не делает команду хотя бы на шаг ближе к принятию правильного решения. Проект застревает на перекрестке, и не может сдвинуться ни в каком направлении. В этот момент страх одолевает всеми членами команды. Давление нарастает.
Один полезный способ, помогающий двигаться вперед, заключается в привлечении арбитра - авторитетного человека не из проектной команды. После выявления самых сложных вопросов назначается совещание с участием арбитра и других заинтересованных лиц. Все участники совещания должны быть согласны с тем, что решение по вопросу должно быть принято на совещании. Арбитр ограничивает время обсуждения каждого вопроса. В последний раз обсуждаются все за и против, и если не удается придти к консенсусу между членами команды, то окончательное решение принимает арбитр.
Другой подход - отложить неразрешенные вопросы на потом, чтобы вернуться к ним после дополнительного исследования и обсуждения, и нахождения правильного решения. Недостатком этого подхода является то, что не всегда бизнес-требования позволяют отложить проблему; иногда это оказывается просто попыткой оттянуть неминуемое, причем без каких-либо плюсов.
Существует тонкий баланс между планированием и разработкой. Цель – найти приемлемые решения (не обязательно самые лучшие), так чтобы можно было перейти от планирования к разработке. Хотя могут еще оставаться моменты, которые можно было бы обдумать дополнительно, разработка часто оказывается более эффективной в нахождении проблемных мест, чем любое количество обсуждений. В сущности, для многих действительно сложных проблем правильное решение может быть получено только путем проб и ошибок.
Очевидно, что мы не защищаем бессистемный подход к созданию хранилищ данных. Но надо признать, что иногда требуется быть прагматичным и двигаться вперед, приняв неидеальное решение (которое, возможно, придется переделывать), чтобы достичь поставленных целей.
Совет №67. Поддерживаем обратные указатели на оперативные системы-источники
Наши хранилища данных все больше и больше направлены на отслеживание детальных транзакций клиентов в почти реальном времени. Как указывает Patricia Seybold в своей замечательной книге Customers.com (Time Business, 1998), управление взаимоотношениями с клиентами означает наличие доступа к данным от всех процессов в организации, которые имеют дело с ними.
Хранение детальной информации обо всех процессах, которые взаимодействуют с клиентами, вкупе с обеспечением в то же самое время единого представления о них является интересной задачей для архитектора ETL. Предположим, перед нами типичный сложный бизнес, ориентированный на клиента, который имеет пятнадцать или более систем, взаимодействующих с клиентом, включая продажи в магазинах и через Интернет, поставки, платежи, кредитование, контракты на послепродажную поддержку, звонки в сервисную службу, а также различные формы маркетинговых коммуникаций. Многие из этих приложений создают свой собственный естественный ключ для каждого клиента, и некоторые из них не очень хорошо справляются с задачей отбраковки дубликатов записей, относящихся к одному и тому же клиенту. Может не существовать надежной единой системы идентификации клиентов, используемой для всех приложений, имеющих дело с ними.
Перед архитектором ETL встает непростая задача удаления дубликатов записей о клиенте, приходящих из каждой системы-источника, сопоставления клиентов по всем системам, сохранения жизни лучшим и наиболее надежным группам описательных атрибутов, тщательно отобранных из каждой системы. Я описываю подробности процесса удаления дубликатов, сопоставления и сохранения жизни в подсистеме ETL #8 в моих лекциях и книге по ETL.
Проблема для архитектора ETL заключается в том, что даже после того, как идеальная целевая единственная запись о клиенте будет получена, конечный пользователь-аналитик может быть не в состоянии проследить путь назад из хранилища данных к набору интересующих его транзакций клиента, содержащихся в одной из систем-источников. Шаги по удалению дубликатов и «сохранению жизни», выполняемые при подготовке конечных очищенных основных клиентских данных, могут вносить в имена, адреса и атрибуты клиентов малозаметные изменения, которые разрывают связь между хранилищем данных и исходными «грязными» транзакциями в системах-источниках.
В последнее время сообщество пользователей стало требовать, чтобы вся детальная информация об операциях, совершаемых клиентами, была доступна в хранилище данных. Это означает, что нам надо каким-то образом перенести все «родные» идентификаторы клиента из источников в целевое измерение с основными клиентскими данными. Более того, если в системе-источнике имелись записи-двойники для того же самого клиента (которые мы найдем и удалим на этапе ETL), нам нужно также перенести все дублирующиеся идентификаторы из источников в измерение с основными клиентскими данными. Только при помощи хранения и поддержания полного набора обратных указателей на исходные идентификаторы клиента мы сможем обеспечить тот уровень возможностей по обратному отслеживанию (из хранилища в источники), который требуют конечные пользователи.
Я рекомендую создание таблицы - единого справочника, которая будет хранить все исходные идентификаторы клиента. Эта таблица содержит следующие поля:
- Data Warehouse Natural Customer Key
- Source System Name (название системы-источника)
- Source System Customer ID (идентификатор клиента в системе-источнике)
Data Warehouse Natural Customer Key – это специальный естественный ключ, созданный хранилищем данных! Нам потребуется подобный постоянный, неизменяемый ключ в измерении с основными клиентскими данными для того, чтобы мы могли однозначно определять версии медленно меняющегося измерения типа 2 для данного клиента.
К этой таблице можно обращаться напрямую, ограничиваясь в запросе по полю Data Warehouse Natural Customer Key (в условии where), или при помощи операции соединения (join) по этому полю с измерением, содержащим основные клиентские данные. В обоих случаях в результате выполнения запроса в поле Source System Customer ID будет содержаться полный список обратных указателей (т.е. исходных идентификаторов в системах-источниках).
Этот дизайн имеет то преимущество, что при помощи простой вставки строк в нашу маленькую таблицу-справочник мы можем справляться со случаями беспорядочного дублирования идентификаторов клиентов в системах-источниках, а также с ситуацией появления нового источника данных в различные моменты времени в будущем.
Совет №69. Идентифицируем бизнес-процессы
Читатели, следующие подходу Кимбала, легко могут перечислить 4 ключевых решения, принимаемых при проектировании многомерной модели: определить бизнес-процесс, гранулярность, измерения и показатели. По правде говоря, разработчики часто спотыкаются уже на первом шаге. Они прикладывают значительные усилия для ясного формулирования бизнес-процесса, потому что сам по себе этот термин меняет значение в зависимости от контекста. Поскольку определение бизнес-процесса является первым кирпичом в фундаменте правильной многомерной модели, то хотелось бы устранить все неясности в нашем определении этого понятия.
В первую очередь обсудим, чем бизнес-процесс не является. В многомерном моделировании понятие бизнес-процесса не относится к конкретному структурному подразделению компании, к организации или функции. Так же это не относится к конкретному отчету или специфическому виду анализа.
Для разработчика многомерных моделей бизнес-процесс – это событие или действие, генерирующее некоторые показатели. Эти показатели описывают функционирование и эффективность предприятия. Бизнес-аналитики хотят тщательно исследовать и оценивать эти показатели, сочетая различные фильтры и ограничения бесконечным, кажется, числом способов. Наша задача, как проектировщиков, предоставить эти показатели в структуре, легкой для понимания и эффективной при произвольных непредсказуемых запросах.
При идентификации бизнес-процессов часто проявляются их похожие характеристики и шаблоны.
- Бизнес-процессы обычно поддерживаются учетными системами. К примеру, выставление счетов выполняется в биллинговой системе; аналогичная ситуация с закупками, заказами, поставками.
- Бизнес-процесс генерирует либо собирает уникальные показатели со своей гранулярностью и набором измерений, используемые для оценки работы организации. Иногда показатели являются прямым результатом бизнес-процессов, в других случаях они могут являться производными. Но в любом случае, бизнес-процесс предоставляет метрики, используемые при различных видах анализа. К примеру, бизнес-процесс продаж является основной во множестве отчетов, таких как анализ по клиентам, эффективность торговых представителей и так далее.
- Бизнес-процессы часто описываются как отглагольные существительные, а измерения бизнес-процесса выражены существительными, связанными с помощью частиц «кто», «что», «где», «когда», «зачем» и «как». К примеру, результаты бизнес-процесса «выставление счетов» будут анализироваться по дате, клиенту, услуге/продукту и так далее.
- Бизнес-процессы обычно инициируются неким вводом, а заканчиваются неким результатом, который необходимо отследить. К примеру, принятый заказ является вводом для процесса обработки заказов, и заканчивается продажей и связанными с продажами метриками. В этом случае бизнес-процессом является обработка заказов; вы создадите таблицу фактов с номером заказа в качестве вырожденного измерения, а также с сумой и количеством заказа в качестве показателей. Попытайтесь представить себе весь поток в целом, начиная со входа в бизнес-процесс, и заканчивая результирующими метриками. В большинстве организаций существуют последовательные бизнес-процессы, результат одного процесса становится входными данными для следующего. В терминах многомерного моделирования набор этих бизнес-процессов превратится в набор таблиц фактов.
- Аналитики часто хотят переходить от одного бизнес-процесса к другому (drill across), изучая результаты первого вместе с результатами второго. Такие переходы вполне жизнеспособны, если общие для бизнес-процессов измерения являются согласованными.
Определение основных бизнес-процессов критически важно для создания прочного каркаса многомерных моделей. Простейший способ определить эти процессы – послушать бизнес-пользователей. Как процессы генерируют наиболее интересные метрики? В то же время необходимо реально оценивать существующие источники данных и возможность предоставить пользователю данные, которые он так желает увидеть.
И последнее… Это даже не обсуждается, что вечно популярные дэшбороды НЕ являются бизнес-процессами: они представляют информацию из множества отдельных бизнес-процессов.
Совет №70. Моделирование ваших данных для Microsoft SQL Server 2005
Как многие из вас Warren Thornthwaite и я работали с пререлизами Microsoft SQL Server 2005. Мы также добавляли последние штрихи в нашу новую книгу - The Microsoft Data Warehouse Toolkit ( Wiley, December 2005). Одна из задач, с которой мы столкнулись во время создания книги и во время консультирования наших клиентов, использующих SQL сервер, это стоит ли реализовывать ваше хранилище данных на платформе Microsoft на реляционной СУБД, на Analysis Services или на обоих? Ответ - в большинстве случаев на обоих.
Поскольку в течение многих лет создавались реляционные хранилища данных, очевидно, что это возможно. Microsoft добавил интересную функциональность в многомерную СУБД Analysis Services 2005, что по крайней мере в теории, делает возможным создать многомерную базу данных непосредственно из транзакционной системы, минуя реляционное хранилище данных. Но действительно ли это хорошая идея? Прежде чем ответить на это вопрос, я собираюсь привести аргументы, что в любом случае архитектура хранилища данных на платформе Microsoft должна включать Analysis Services. Для успешного выполнения нерегламентированных запросов, даже к упрошенной многомерной модели, вам необходим пользовательский слой, который упрощает навигацию, выполняет сложные вычисления, управляет выбором агрегатов и осуществляет контроль разграничения прав доступа. Многие годы при этом использовались реляционные технологии, такие как view и клиентские инструменты для генерации запросов. Многомерная СУБД, такая как Analysis Services, предоставляет привлекательную альтернативу благодаря следующим возможностям:
- Пользовательский слой метаданных
- Сложная аналитика, сохраненная в базе данных
- Более мощный аналитический язык MDX по сравнению с SQL
- Производительность запросов
- Управление агрегатами
- Развитая модель безопасности
- Серверная архитектура, что важно для масштабируемости, производительности и единству метаданных для всех клиентских инструментов
Хотя Analysis Services стал популярным компонентом SQL Server 2000, все еще были препятствия для использования Analysis Services:
- Масштабируемость
- Избыточность данных
- Изменение существующих пользовательских приложений
На наш взгляд, только третье препятствие является наиболее часто встречающимся. Беспокойства о машстабируемости и дублирования данных были эффективно разрешены с выходом SQL Server 2005 и не должны препятствовать подавляющему большинству внедрений получать реальные преимущества от хранилища данных и системы поддержки принятия решений построенных на базе Analysis Services.
Если я убедил Вас, что Analysis Services является важной частью архитектуры вашего хранилища данных на платформе Microsoft, вашим следующим вопросом может быть: зачем нужно хранить многомерные данные в реляционной СУБД? От вас этого не требуется: Microsoft предоставляет несколько механизмов для загрузки данных в кубы Analysis Services непосредственно из немногомерных источников данных. Зачем пускаться в затраты и трудности создания реляционной системы в дополнение к Analysis Services? Вот почему:
- Согласование измерений и фактов. В гипотетическом, простом примере Вы могли бы согласовать данные по ходу загрузки в Analysis Services. В реальной жизни, Вам необходимо модифицировать и удалять некоторые данные в процессе ETL, и Вы на самом деле захотите делать это в реляционной базе данных.
- Восстановление после сбоев. Инструменты и знания для организации восстановления реляционной СУБД лучше, чем для Analysis Services, хотя средства управления были значительно улучшены в новой версии.
- Комфорт. Администраторы и продвинутые пользователи хорошо знакомы с SQL и реляционными СУБД и могут яростно сопротивляться устранению реляционного слоя.
- Гибкость запросов. Если Вы хотите модифицировать базу данных Analysis Services, то обычно необходимо повторно развернуть и наполнить значительную часть базы данных.
- Будущая гибкость. Идея устранения реляционного хранилища данных и заполнения базы данных Analysis Services непосредственно из транзакционной системы может выглядеть элегантной. Однако, если Вы выберете эту архитектуру, Вы поплывете на корабле Microsoft с невозвращаемым билетом.
Существует несколько сценариев, в которых наилучшим решением будет миновать реляционную систему хранения реляционных данных. Правда это крайние случаи, о которых я напишу в следующих советах разработчикам. Большинство из нас чаще всего должны планировать хранить и управлять многомерными данными в реляционной СУБД и использовать ее для наполнения Analysis Services. Думайте о слое Analysis Services преимущественно как о метаданных для многомерной системы с промежуточным кэшем – аналогичным по идее реляционным индексам – который значительно увеличивает производительность запросов.
Совет №71. Игра в имена
Проблема именования полей возникает всякий раз, когда приходится строить многомерную модель. Именование действительно непростое дело: разные люди понимают под одними и теми же словами разные вещи, как, например, «доход» (revenue), или наоборот – используют разные наименования для одного и того же объекта или понятия, например «продажи» (sales). Это в природе человека: большинство из нас не хочет отказываться от того, что понятно и привычно, и переучиваться на нечто новое. Задачу определения имен в модели решает, как правило, «стюард данных» (data steward). Если именно Вам выпало разбираться с этим политическим кошмаром, может оказаться полезным изложенный далее подход из трех шагов. Первые два обычно делаем до того, как знакомить с моделью бизнес-пользователей. Третий – после того, как бизнес-пользователи уже увидели и осознали модель.
Шаг 1 – Подготовка
Начните с развития в себе умения находить точные, емкие и уникальные наименования для элементов данных. Изучите соглашения о назначении имен, применяемые в вашей организации (и команде). Посмотрите, какие наименования таблиц и колонок используются в разных системах. Если соглашений о назначении имен нет – самое время их разработать. Обычно применяется подход, при котором имя колонки формируется из трёх частей:
[ПервичноеСлово]_[НольИлиБольшеКвалификаторов]_[КлассифицирующееСлово]
Первичное слово – это основное, категоризирующее понятие, которое зачастую соотносится с названием исходной сущности, содержащей эту колонку. В отдельных случаях квалификаторы вовсе не требуются. Например, поле в таблице фактов Sales, обозначающее объем продаж в долларах, так и назовем: Sales_Dollar_Amount. В Итернете вы найдете самые разнообразные соглашения о назначении имен. Для начала можно посмотреть здесь:
- https://dwr.ais.columbia.edu/info/Data%20Naming%20Standards.html
- http://www.ss64.com/orasyntax/naming.html
Шаг 2 - Формирование исходного набора имен
В процессе построения модели, совместно с командой, отвечающей за ее разработку (включающей одного-двух представителей «от бизнеса»), составьте предварительный вариант именования полей и подумайте над обоснованием. Когда модель будет практически готова, соберитесь снова и обсудите, насколько теперь наименования в ней правильны и уместны (этот прием полезен также и на следующем шаге).
Помимо общих совещаний, для обсуждения наименований следует также встречаться по отдельности с основными заинтересованными сторонами. Это обычно ключевые бизнес-пользователи, а также старшие менеджеры, которые могут иметь на этот счет собственную точку зрения. Если они предпочитают иные названия полей, нежели те, которые вы предлагаете – постарайтесь понять, почему. Помогите им как можно более четко определить элементы данных, задавайте вопросы о том, что именно тот или иной термин означает в их понимании. Возможно, не хватает квалификаторов или классифицирующих слов для прояснения и уточнения смысла? Например, аналитик по продажам интересуется показателем (числом) «Продажи». Но оказывается, что на самом деле это не просто продажи, а объем продаж, связанных с комиссионным вознаграждением (Sales_Comissionable_Amount). А это совсем не то же самое, что брутто-продажи (Sales_Gross_Amount) или чистый объем продаж (Sales_Net_Amount).
Полученный в результате набор имен вносится в текущую версию модели данных. Отдельно отслеживайте и фиксируйте альтернативные наименования колонок и аргументы в их пользу. В дальнейшем это поможет в обосновании окончательного списка названий.
Шаг 3 - Достижение согласия
Наконец у вас есть полный, выверенный набор наименований, а ключевые пользователи уже ознакомились с моделью данных. Теперь соберите всех заинтересованных участников процесса в зале для совещаний как минимум на полдня (а, возможно, и больше – если полей в модели достаточно много, или народ склонен к дискуссиям). Начните с обобщенной, высокоуровневой модели, и пройдитесь по всем полям, таблица за таблицей. К этому моменту было уже достаточно итераций и обсуждений модели и наименований, множество вопросов решено, а оставшиеся – понятны всем присутствующим. Цель встречи – достичь соглашения по финальной, окончательной версии набора имен. Как правило, это означает, что оставшиеся в меньшинстве будут вынуждены принять волю большинства и распрощаться с любимыми наименованиями отдельных полей. Просто удивительно, насколько этот процесс может быть эмоциональным! Ведь имена в данном случае представляют наше видение бизнеса, и люди всеми силами стараются, чтобы имена эти были «правильными». Не выпускайте их из помещения, пока не договорятся (если это, конечно, вообще возможно). Ведь, если собирать их еще раз, снова будет потрачена масса времени на повторное изложение всевозможных аргументов. После того, как согласие, наконец, достигнуто, и получен окончательный набор наименований, задокументируйте его самым тщательным образом и передайте проектировщикам для внесения в финальную версию модели данных.
Совет №72. Дешифровщик бизнес-процессов
В совете № 69 «Идентифицируем бизнес-процессы» Мардж Росс разъяснила, как важно идентифицировать бизнес-процессы организации при построении модели хранилища данных, и дала рекомендации о том, как это сделать. Теперь углубимся в некоторые детали.
Фокус на бизнес-процессах критически важен для успешной реализации решения в области хранилищ/BI по методу Кимбалла. Бизнес-процессы – это строительные блоки хранилища данных, создаваемого на основе многомерной модели. Мы предлагаем разрабатывать хранилище последовательно, итерационно, захватывая по бизнес-процессу за шаг. Вы спросите: что такого волшебного в бизнес-процессах? Как их выявление поможет нам в моделировании? Ответ заключается в том, что, правильная идентификация бизнес-процессов «запускает» весь процесс проектирования многомерной модели. Я не раскрою особого секрета, если скажу, что каждый бизнес-процесс порождает по крайней мере одну таблицу фактов, поэтому идентификация бизнес-процессов существенным образом определяет и то, какие таблицы фактов мы построим.
Вполне обычной является ситуация, когда один бизнес-процесс порождает две и более таблицы фактов. Чаще всего это происходит, если процесс затрагивает разные объекты (продукты), которые могут рассматриваться как подтипы одного супер-типа. В этом случае будет порождено несколько схожих, но отдельных таблиц фактов. Вот хороший пример из области медицинского страхования. Бизнес-процесс, связанный с выплатами по требованиям возмещения, может быть отражен в трех отдельных таблицах фактов: оплата расходов на амбулаторное обслуживание (посещения врача), расходов на пребывание в стационаре, а также расходов на оплату лекарственных препаратов.
Следствием некорректного определения бизнес-процессов становятся модели данных, которые никогда не будут реализованы, или (что еще хуже) – таблицы фактов на неподходящем, недопустимом уровне детальности. Если учесть, сколько уже написано нами на эту тему, излишне говорить (хотя вы не найдете этого в некоторых недавних аналитических обзорах), что мы поддерживаем реализацию хранилищ на основе многомерной модели, с максимально возможным уровнем детальности данных.
Хорошей проверкой на то, насколько корректно вы идентифицировали бизнес-процессы, станет описание гранулярности таблицы фактов. Если вы можете лаконично и четко определить детальный уровень фактов – вы и ваша модель в порядке. И напротив, если есть неясности касательно уровня детальности каждой записи в таблице фактов – вам еще есть над чем поработать. Скорее всего, вы смешали в одной таблице более одного бизнес-процесса. Отступите на шаг назад и внимательно посмотрите, где тот дополнительный бизнес-процесс, который нужно учесть в вашей модели.
Лучший способ понять бизнес-процессы – это слушать требования пользователей. К сожалению, когда эти требования излагаются, они не принимают сами собой форму описания бизнес-процессов. Пользователи лишь сообщают нам (в своей терминологии) потребности относительно анализа информации: какие виды анализа им нужны, и какие решения они хотели бы принимать на их основе. Если продолжить пример из области медицины, актуарии могут запросить анализ оценки страховой премии, отчеты по тенденциям применения и треугольники претензий, на которые они опираются в своей работе. Казалось бы, что здесь намекает на бизнес-процессы? Но в том-то и суть: изучив аналитические потребности пользователей, декомпозировать их до соответствующих бизнес-процессов. Это означает копнуть несколько глубже, понять данные и учетные системы, над которыми строится аналитика. Дальнейшее исследование в нашем примере в конце концов показывает, что все три аналитических задачи решаются на основе данных бизнес-процесса выплаты по требованиям страхового возмещения.
В некоторых случаях для расшифровки аналитических потребностей приходится приложить серьезные усилия. Ведь зачастую наиболее ценные для бизнес-пользователей возможности анализа связаны с несколькими бизнес-процессами. К сожалению, далеко не всегда очевидно, что задействовано более одного процесса. И в этом случае декодирование - гораздо более сложное дело, так как придется декомпозировать аналитическую задачу до уникальных типов и источников необходимых данных. Возвращаясь к нашему примеру, андеррайтер может запросить анализ коэффициента убыточности для принятия решений по возобновлению страхования. Если углубиться в детали, мы поймем, что анализ убыточности основан на сравнении суммы страховой премии с суммой затрат, связанных с требованием возмещения убытков, и по сути – на определении таким образом отношения между доходами и расходами. Тут уже задействуются два бизнес-процесса: выплата страхового возмещения и начисление страховой премии.
Поразмыслив над этим советом, вы поймете, как подойти к построению корпоративных информационных панелей. Информационная панель не относится к отдельному бизнес-процессу. Это скорее механизм отображения результатов множества (если не всех) бизнес-процессов компании. К сожалению, создание информационных панелей все еще нередко представляется (и принимается) командами хранилищ данных/BI как частная аналитическая задача.
Поговорим о так называемой БАЗЕ - *Медленно меняющиеся измерения (Slowly Changing Dimensions)* - ЭсКаДэ - это детище методолгии Кимбалла.
по сути это таблицы, в которых некоторые атрибуты могут изменить свои значения по истечении некоторого периода времени, причем частота таких изменений является небольшой.
Интересно это с точки зрения организации версионирования данных в вашей таблице.
SCD 0
данные после первого попадания в таблицу далее никогда не изменяются. Нужен лишь как нулевая точка отсчета для методологии SCD. По сути, вообще не SCD.
SCD 1
это обычная перезапись старых данных новыми. В чистом виде этот метод тоже не содержит версионности и используется лишь там, где история фактически не нужна
SCD 2
для каждой версии создается отдельная запись в таблице с добавлением поля-ключевого атрибута данной версии.
SCD 3
В самой записи содержатся дополнительные поля для предыдущих значений атрибута. При получении новых данных, старые данные перезаписываются текущими значениями.
SCD 4
История изменений содержится в отдельной таблице измерении: основная таблица всегда перезаписывается текущими данными с перенесением старых данных в другую таблицу. Обычно этот тип используют для аудита изменений или создания архивных таблиц.
SCD 5
Методика SCD 5 основана на мини-измерении SCD 4 путем внедрения ключа мини-измерения «текущий профиль» в базовое измерение, которое перезаписывается как атрибут SCD 1. Поэтому в общем то SCD 5 (4+1), это позволяет получить доступ к назначенным в данный момент значениям мини-измерения вместе с другими значениями базового измерения без привязки через таблицу фактов.
SCD 6
Комбинация 1, 2 и 3 методов и предназначен для ситуаций, которые они не учитывают или для большего удобства работы с данными.
SCD 7
это другой способ достижения того же, что и SCD 6, где вы поддерживаете версию значений SCD 1 отдельно от версии значений SCD 2. Часто версия SCD 1 создается с использованием представления SCD 2. Имея оба ключа в факте, вы можете узнать, как обстояли дела на момент факта, а также как все обстояло на основе текущих версий измерений. Это позволяет избежать необходимости обновлять старые значения в соответствии с текущим состоянием.