Статьи / Основные принципы метода Кимбалла

29.10.2018 г., перевод статьи Joy Mundy

Большинство рекомендаций в методе Кимбалла для проектирования, разработки и развертывания системы DW/BI состоит именно в этом: руководство. Есть сотни или тысячи правил во многих книгах Kimball Group, и я признаю, что на протяжении десятилетий нарушала многие из них, сталкиваясь с противоречивыми целями или неприятными политическими реалиями.

Размерная модель – это ключевое преимущество

Метод Кимбалла, описанный во втором издании книги «Инструментарий жизненного цикла данных», ориентирован на размерную модель. Принципы размерного моделирования являются наиболее известным вкладом Ральфа Кимбалла и Kimball Group в мир бизнес-аналитики. Наше внимание сосредоточено на этом, потому что хорошая размерная модель абсолютно необходима для успеха вашего предприятия DW/BI. Если вы правильно подберете модель и правильно произведете ее интеграцию, все остальное – просто.

Размерное моделирование – это групповая деятельность

Даже лучший специалист по размерному моделированию создаст плохую размерную модель, если он работает в одиночку. Многомерное моделирование – это не просто групповое действие, а групповое действие, в котором должно участвовать сообщество бизнес-пользователей. За прошедшие годы мы бесчисленное количество раз отказывались от консалтинговых запросов на разработку модели без учета бизнеса. Или, что еще хуже, боролись за мучительные проекты, когда обещанное участие бизнес-пользователей так и не состоялось.

Это, несомненно, важнейшее требование пользовательского сообщества. Наш процесс проектирования обычно занимает 50-60 часов в течение 4-6 недель (или более, в зависимости от сложности проекта). Люди, участие которых необходимо в проектных сессиях, чрезвычайно важны для получения положительного результата. Но если их не убедить вложить время и энергию, полученная система в итоге не сможет работать эффективно.

Размерная модель самая лучшая спецификация для системы DW/BI

Большинство клиентов, с которыми я работаю, не имеют письменной спецификации для системы DW/BI и документа, осмысленно отражающего реальность. Наиболее распространенный формат спецификации включает в себя огромные списки того, что пользователи хотят фильтровать и детализировать, а также требование того, чтобы все 2000 существующих отчетов поддерживались новой системой. Если все, что мы сделали с нашей новой системой DW/BI, – это реплатформинг существующей консолидированной отчетности, мы потерпели неудачу.

Мы просим бизнес-пользователей в конце процесса проектирования подумать об аналитических выводах, которые они недавно сделали или хотели бы сделать из информации в текущей области разработки. Мы хотим, чтобы они сказали: «Да, эта модель соответствует нашим потребностям». В то же время ИТ-специалисты в команде наблюдают за обсуждением источников данных, трансформаций и других технических деталей. Мы просим их подтвердить «Да, мы можем заполнить эту модель данных». Составление проекта размерной модели – это значимая и действенная спецификация требований.

Размерная модель должна повысить ценность после реструктуризации

Некоторые из наиболее ценных улучшений, которые можно реализовать в системе DW/BI – это добавление улучшенных дескрипторов и групп к часто используемым данным. Тем не менее, эти возможности часто упускаются командой разработчиков. Я даже сталкивалась с командами с явной политикой не добавлять ничего, кроме того, что находится в исходной системе.

Примеры полезных дополнений модели данных:

Предоставление пользователям возможности фильтровать редко используемые коды транзакций;
Предоставление удобных столбцов сортировки для выбора списков и отчетов;
Предварительное вычисление диапазонов, таких как возрастные диапазоны или критерии качества сделки;
Поддержка отличных или более глубоких иерархий, чем управление в исходных системах, таких как маркетинг и производственные точки измерения продукта.

Системы управления основными данными – это отличная возможность улучшить результат

Устранение дублирования является одной из самых сложных задач, стоящих перед командой проектировщиков хранилища данных. С самых первых дней команда разработчиков изо всех сил пыталась разработать ETL процессы, которые устраняли бы дублирование таких сущностей, как «клиент».

Растущая популярность и функциональность технологий и программ управления основными данными (MDM) обеспечивает гораздо лучшее решение, чем в потоке ETL. И не только потому, что это сложнее! Ритм процесса ETL, выполняющийся в автоматическом режиме, без возможности внесения мгновенных корректировок, принципиально расходится с процессом дедупликации. Независимо от того, насколько превосходны наши инструменты, насколько хорош ваш код, насколько полны наши бизнес-правила, автоматизированный процесс дедупликации не может достичь 100% точности. Именно человек должен принимать решение в сомнительных случаях. Такой подход работает намного лучше. Ответственное отношение к работе в течение всего рабочего дня, а не ожидание загрузки ETL, поможет обеспечить самый высокий результат.

Простая система MDM может использоваться для создания элементов данных с добавленной стоимостью, описанных ранее в этой рекомендации по проектированию. Иерархии измерений известны своей несовершенной структурой, особенно если они получены с рабочих столов пользователей. Средства MDM предоставляют простую платформу для управления этой информацией.

Не игнорируйте реляционное хранилище данных

Проектирование и заполнение корпоративного хранилища данных – трудоемкий и сложный процесс. Многие хотят пропустить этот шаг. На протяжении 23 с лишним лет моей карьеры в области хранения данных я наблюдала огромное количество технологических попыток упростить процесс. Начиная с создания уровня BI непосредственно в системе транзакций и заканчивая так называемыми виртуальными хранилищами данных, все возвращались обратно к текущему варианту сценария построения инструментов визуализации.

Как я уже говорила ранее, используйте инструменты визуализации данных, но избегайте анархии, просто скажите ей «нет»! Если вы полностью не контролируете все исходные данные, вы должны оставить ETL в инструменте ETL, оставить хранилище данных и управление ими в реляционной системе баз данных и позволить инструментам BI заниматься тем, что они делают лучше всего: отличные визуализации и пользовательский интерфейс.

Все ради бизнеса

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

Жду с нетерпением

Мне невероятно повезло, что я была частью Kimball Group в течение последних двенадцати лет. Для меня было честью работать не только с Ральфом, Марджи, Бобом и Уорреном, но и с сотнями студентов, клиентов и коллег, у которых я многому научилась. Я очень довольна тем, чего мы достигли вместе, и счастлива, потому что у меня есть то, что я считаю лучшей работой в мире.

Я чувствую себя особенно благословенной по сравнению с Уорреном, чья смерть в 2014 году от рака мозга глубоко затронула меня и всю Kimball Group. В 2016 году я буду вспоминать Уоррена и его страсть к фитнесу, совершив поездку на велосипеде по всей территории Соединенных Штатов. Моей целью будет сбор средств для исследования рака мозга. Я была бы польщена, если бы вы посетили наш блог, в котором будет вестись хроника этого путешествия (https://itinerantphilosopher.wordpress.com) и благодарна, если вы рассмотрите возможность пожертвования на наши усилия по сбору средств на исследования рака мозга.