Совет №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. ДОБАВЛЕНИЕ АБСОЛЮТНО НОВОГО ИСТОЧНИКА ДАННЫХ, ЗАТРАГИВАЮЩЕЕ
СУЩЕСТВУЮЗИЕ ИЗМЕРЕНИЯ, А ТАКЖЕ ДОБАВЛЯЮЩЕЕ НЕОЖИДАННЫЕ НОВЫЕ ИЗМЕРЕНИЯ.
Почти всегда новый источник данных имеет свою собственную гранулярность
и свои собственные измерения. Все вы многомерные дизайнеры знаете
ответ на эту задачу. Мы заводим новую таблицу фактов. Поскольку
никакие из существующих таблиц фактов и измерений остаются незатронутыми,
по определению, все существующие приложения будут продолжать работать.
Несмотря на то, что этот случай кажется почти тривиальным, смысл
здесь заключается в том, чтобы не допустить втискивания новых показателей
в существующие таблицы фактов. Одна таблица фактов всегда владеет
одним видом измерения показателей, которые имеют унифицированный
уровень детализации.
В этом совете была сделана попытка определить таксономию неожиданных
изменений в вашей среде с целью показать вам способы работы с ними
и определить те ситуации, в которых возможны элегантные изменения.
Поскольку переделка запросов и отчётов очень дорога и, возможно,
разрушительна для конечных пользователей, наша цель - оставаться
элегантными.
Ральф Кимбал
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS