DATA SCIENCE
Лучшие книги о науке
о данных
R a l p h
K i m b a l l
M a r g y
R o s s
THE DATA
WAREHOUSE
TOOLKIT
THE DEFINITIVE GUIDE
TO DIMENSIONAL MODELING
3RD EDITION
Р а л ь ф
К и м б а л л
М а р д ж и
Р о с с
ИНСТРУМЕНТАРИЙ
ХРАНЕНИЯ
И АНАЛИЗА ДАННЫХ
ПОЛНОЕ РУКОВОДСТВО
ПО РАЗМЕРНОМУ МОДЕЛИРОВАНИЮ
УДК 004.6
ББК 32.973.2-018.2
К40
The Data Warehouse Toolkit: The Definitive Guide to
Dimensional Modeling, 3rd edition
Ralph Kimball and Margy Ross
Copyright © 2013 by Ralph Kimball and Margy Ross
All rights reserved. This translation published under license with the original
publisher John Wiley and Sons, Inc. via Igor Korzhenevskiy
of Alexander Korzhenevski Agency.
Wiley and the Wiley logo are trademarks or registered trademarks of John
Wiley & Sons, Inc. and/or its affi liates, in the United States and other countries,
and may not be used without written permission.
All other trademarks are the property of their respective owners. John Wiley & Sons,
Inc. is not associated with any product or vendor mentioned in this book.
К40
Кимбалл, Ральф.
Инструментарий хранения и анализа данных : полное руководство по размерному моделированию / Ральф Кимбалл, Марджи
Росс ; [перевод с английского М. А. Райтмана]. — Москва : Эксмо,
2024. — 656 с. — (Data Science. Лучшие книги о науке о данных).
ISBN 978-5-04-108040-2
Сегодня тысячи компаний собирают и сохраняют большие данные о поведении своих клиентов, ассортименте, производственном процессе и других
немаловажных для бизнеса вещах. Однако, чтобы принимать обоснованные
решения на основе этих данных, недостаточно их просто собрать – нужно
правильно их обработать и провести грамотный анализ. Благодаря этой книге
вы освоите все необходимые инструменты для хранения и анализа большого
количества данных, научитесь правильно управлять ими и извлекать полезную
информацию для развития бизнеса.
УДК 004.6
ББК 32.973.2-018.2
ISBN 978-5-04-108040-2
© Райтман М.А., перевод на русский язык, 2024
© Оформление. ООО «Издательство «Эксмо», 2024
Оглавление
Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Для кого эта книга . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Структура книги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Глава 1. Хранение данных, анализ данных и основы размерного
моделирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Глава 2. Обзор методов размерного моделирования Кимбалла . . . 27
Глава 3. Розничные продажи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Глава 4. Склад . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Глава 5. Закупки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Глава 6. Управление заказами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Глава 7. Бухгалтерский учет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Глава 8. Управление взаимоотношениями с клиентами . . . . . . . . . 28
Глава 9. Управление персоналом . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Глава 10. Финансовые услуги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Глава 11. Телекоммуникации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Глава 12. Транспортировка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Глава 13. Образование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Глава 14. Здравоохранение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Глава 15. Электронная коммерция . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Глава 16. Страхование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Глава 17. Обзор жизненного цикла Кимбалла . . . . . . . . . . . . . . . . . 30
Глава 18. Процессы и задачи размерного моделирования . . . . . . . 30
Глава 19. Подсистемы и методы ETL . . . . . . . . . . . . . . . . . . . . . . . . . 30
Глава 20. Задачи и процессы разработки и проектирования
систем ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Глава 21. Аналитика больших данных . . . . . . . . . . . . . . . . . . . . . . . . . 31
Веб-сайты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6
Оглавление
1
Хранение данных, анализ данных и основы размерного
моделирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Различные миры сбора и анализа данных . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Цели хранения и анализа данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Сравнение обязанностей менеджеров DW/BI
с издательским бизнесом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Введение в размерное моделирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Схема «звезда» против кубов OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Таблицы фактов для измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Таблицы измерений для описательного контекста . . . . . . . . . . . . . 47
Факты и измерения, объединенные в схему «звезда» . . . . . . . . . . 50
DW/BI-архитектура Кимбалла . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Операционные исходные системы . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Система извлечения, преобразования и загрузки . . . . . . . . . . . . . . 54
Область представления для поддержки анализа данных . . . . . . . 56
Приложения по анализу данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Архитектура Кимбалла и метафора ресторана . . . . . . . . . . . . . . . . 58
Альтернативные архитектуры DW/BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Независимая архитектура Data Mart («Витрина данных») . . . . . . . . 62
Веерная архитектура корпоративной информационной
фабрики Инмона . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Гибридная веерная и кимбалловская архитектура . . . . . . . . . . . . . 66
Мифы о размерном моделировании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Миф 1: размерные модели только для сводных данных . . . . . . . . . 67
Миф 2: размерные модели для отделов, а не для предприятий
в целом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Миф 3: размерные модели не масштабируемы . . . . . . . . . . . . . . . 68
Миф 4: размерные модели только для заранее определенного
использования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Миф 5: размерные модели не интегрируемы . . . . . . . . . . . . . . . . . 69
Еще больше причин мыслить многомерно . . . . . . . . . . . . . . . . . . . . . . . . . 69
Соглашения Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2
Обзор методов размерного моделирования Кимбалла . . . . . . 73
Основные концепции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Соберите бизнес-требования и реалии данных . . . . . . . . . . . . . . . . . 74
Совместные рабочие сессии по пространственному
моделированию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Оглавление
7
Четырехэтапный процесс размерного проектирования . . . . . . . . . 75
Бизнес-процессы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Зернистость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Измерения для описательного контекста . . . . . . . . . . . . . . . . . . . . . . 76
Факты для измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Схема «звезда» и кубы OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Стабильные расширения размерных моделей . . . . . . . . . . . . . . . . . 78
Основные методы работы с таблицами фактов . . . . . . . . . . . . . . . . . . . . 79
Структура таблиц фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Аддитивные, полуаддитивные и неаддитивные факты . . . . . . . . . . 79
Пустые значения (Null) в таблицах фактов . . . . . . . . . . . . . . . . . . . . 80
Согласованные факты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Таблицы фактов транзакций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Таблицы фактов периодических моментальных снимков . . . . . . . . 81
Накопительные таблицы фактов моментальных снимков . . . . . . 82
Таблицы фактов без показателей . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Агрегированные таблицы фактов, или кубы OLAP . . . . . . . . . . . . . 83
Консолидированные таблицы фактов . . . . . . . . . . . . . . . . . . . . . . . . 84
Основные методы работы с таблицами измерений . . . . . . . . . . . . . . . . . 84
Структура таблицы измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Суррогатные ключи измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Натуральные, стойкие и сверхнатуральные ключи . . . . . . . . . . . . 85
Детализация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Вырожденные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Денормализованные плоские измерения . . . . . . . . . . . . . . . . . . . . . . 87
Несколько иерархий в измерениях . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Флаги и индикаторы как текстовые атрибуты . . . . . . . . . . . . . . . . . . 87
Пустые атрибуты в измерениях . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Измерение «Календарная дата» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Важные ролевые изменения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Мусорные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Измерения в виде «снежинки» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Измерения с внешней опорой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Интеграция через согласованные измерения . . . . . . . . . . . . . . . . . . . . . . . 90
Согласованные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Сжатые измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Копаем вширь . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Цепочка значений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Архитектура шины корпоративного хранилища данных . . . . . . . . 92
8
Оглавление
Матрица шины корпоративного хранилища данных . . . . . . . . . . . 93
Подробная матрица шины реализации . . . . . . . . . . . . . . . . . . . . . . . 93
Матрица возможностей/заинтересованных сторон . . . . . . . . . . . . 94
Работа с атрибутами медленно изменяющегося измерения . . . . . . . . 94
Тип 0: сохранение оригинала . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Тип 1: перезапись . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Тип 2: добавление новой строки . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Тип 3: добавление нового атрибута . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Тип 4: добавление мини-измерения . . . . . . . . . . . . . . . . . . . . . . . . . 96
Тип 5: добавление мини-измерения и внешней опоры типа 1 . . . 96
Тип 6: добавление атрибута типа 1 к измерению типа 2 . . . . . . . . . 97
Тип 7: двойные измерения типа 1 и типа 2 . . . . . . . . . . . . . . . . . . . . . 97
Работа с иерархиями измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Позиционные иерархии с фиксированной глубиной . . . . . . . . . . . 98
Иерархии с пропущенными уровнями / иерархии
переменной глубины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Неровные иерархии/иерархии переменной глубины
с соединительными таблицами иерархии . . . . . . . . . . . . . . . . . . . . 99
Рваные иерархии/иерархии переменной глубины
с атрибутами пути . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Продвинутые методы работы с таблицами фактов . . . . . . . . . . . . . . . . 100
Суррогатные ключи таблицы фактов . . . . . . . . . . . . . . . . . . . . . . . 100
Таблицы-«сороконожки» с фактами . . . . . . . . . . . . . . . . . . . . . . . . 100
Числовые значения как атрибуты или факты . . . . . . . . . . . . . . . . . 101
Факты о задержке/продолжительности . . . . . . . . . . . . . . . . . . . . . . 101
Заголовок/строка в таблице фактов . . . . . . . . . . . . . . . . . . . . . . . . . 102
Выделенные факты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Таблицы фактов прибылей и убытков с выделением фактов . . . 102
Факты разных валют . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Факты с множественными единицами измерения . . . . . . . . . . . . . 103
Факты текущего года (Year-to-date) . . . . . . . . . . . . . . . . . . . . . . . . . 104
Многопроходный SQL, чтобы избежать объединения
таблиц «факт — факт» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Отслеживание промежутка времени в таблицах фактов . . . . . . 104
Факты, появляющиеся с опозданием . . . . . . . . . . . . . . . . . . . . . . . 105
Расширенные методы работы с измерениями . . . . . . . . . . . . . . . . . . . . . 105
Соединения таблиц «измерение — измерение» . . . . . . . . . . . . . . 105
Многозначные измерения и соединительные таблицы . . . . . . . . 106
Многозначные соединительные таблицы, меняющиеся
во времени . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Оглавление
9
Временной ряд тега поведения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Исследовательские группы изучения поведения . . . . . . . . . . . . . . 107
Агрегированные факты как атрибуты измерения . . . . . . . . . . . . . . 107
Динамические диапазоны значений . . . . . . . . . . . . . . . . . . . . . . . . 108
Измерение «Текстовые комментарии» . . . . . . . . . . . . . . . . . . . . . . 108
Несколько часовых поясов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Измерения типа «Показатель» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Измерения «Шаг» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Измерения с возможностью горячей замены . . . . . . . . . . . . . . . . . 110
Абстрактные общие измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Измерения «Аудит» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Измерения, прибывающие с опозданием . . . . . . . . . . . . . . . . . . . . . 111
Схемы специального назначения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Схемы супертипа и подтипа для гетерогенных продуктов . . . . . . 112
Таблицы фактов в реальном времени . . . . . . . . . . . . . . . . . . . . . . . . 112
Схемы событий ошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3
Розничные продажи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Четырехэтапный процесс размерного проектирования . . . . . . . . . . . 116
Шаг 1: выбор бизнес-процесса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Шаг 2: объявление зернистости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Шаг 3: определение измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Шаг 4: определение фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Пример использования в розничной торговле . . . . . . . . . . . . . . . . . . . . . 119
Шаг 1: выбор бизнес-процесса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Шаг 2: объявление зернистости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Шаг 3: определение измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Шаг 4: определение фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Подробная информация о таблице измерений . . . . . . . . . . . . . . . . . . . . 127
Измерение «Дата» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Измерение «Продукт» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Измерение «Магазин» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Измерение «Промоакция» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Прочие измерения розничных продаж . . . . . . . . . . . . . . . . . . . . . . . 142
Вырожденные измерения для номеров транзакций . . . . . . . . . . . . 143
Розничная схема в действии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Расширяемость схемы розничных продаж . . . . . . . . . . . . . . . . . . . . . . . . 145
Таблицы фактов без метрик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10
Оглавление
Ключи таблиц измерений и фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Суррогатные ключи таблицы измерений . . . . . . . . . . . . . . . . . . . . 148
Натуральные, стойкие и сверхнатуральные ключи . . . . . . . . . . . . 151
Суррогатные ключи вырожденного измерения . . . . . . . . . . . . . . . 152
Умные ключи измерения «Дата» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Суррогатные ключи таблицы фактов . . . . . . . . . . . . . . . . . . . . . . . . 153
Сопротивление стремлению к нормализации . . . . . . . . . . . . . . . . . . . . . 155
Схемы «снежинки» с нормализованными измерениями . . . . . . . . 155
Внешняя опора . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Таблицы фактов «сороконожка» со «слишком большим
количеством измерений» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4
Склад . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Введение в цепочку ценности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Модели инвентаризации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Периодический моментальный снимок инвентаризации . . . . . . . 165
Полуаддитивные факты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Расширенные сведения о запасах . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Операции с запасами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Накопительный моментальный снимок запасов . . . . . . . . . . . . . . . . . . . 171
Типы таблиц фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Таблицы фактов транзакций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Таблицы фактов периодических снимков . . . . . . . . . . . . . . . . . . . . 173
Накопительные таблицы фактов моментальных снимков . . . . . . 174
Задержки между этапами и количество этапов . . . . . . . . . . . . . . . 175
Накопление обновлений снимков и кубов OLAP . . . . . . . . . . . . . . . 175
Дополнительные типы таблиц фактов . . . . . . . . . . . . . . . . . . . . . . . 175
Интеграция цепочки ценности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Архитектура шины хранилища корпоративных данных . . . . . . . . . . . 177
Понимание архитектуры шины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Матрица шины корпоративного хранилища данных . . . . . . . . . . . 179
Согласованные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Горизонтальный анализ таблицы фактов . . . . . . . . . . . . . . . . . . . . . 185
Идентичные согласованные измерения . . . . . . . . . . . . . . . . . . . . . 186
Сжатие согласованного измерения с подмножеством
атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Сжатие согласованного измерения с подмножеством строк . . . . 187
Сжатые согласованные размеры на матрице шины . . . . . . . . . . . . 189
Оглавление
11
Ограниченная согласованность . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Важность управления данными и ответственности за данные . . . . 191
Согласованные измерения и движение к Agile . . . . . . . . . . . . . . . . 193
Согласованные факты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5
Закупки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Закупки: практический пример . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Закупочные операции и матрица шины . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Одна или много таблиц фактов транзакций . . . . . . . . . . . . . . . . . . 199
Дополнительный моментальный снимок закупок . . . . . . . . . . . . 203
Основные сведения о медленно меняющихся измерениях . . . . . . . . 204
Тип 0: сохранение оригинала . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Тип 1: перезапись . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Тип 2: добавление новой строки . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Тип 3: добавление нового атрибута . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Тип 4: добавление мини-измерения . . . . . . . . . . . . . . . . . . . . . . . . 214
Гибридные методы медленно изменяющихся измерений . . . . . . . . . 217
Тип 5: добавление мини-измерения и внешней опоры типа 1 . . . 218
Тип 6: добавление атрибута типа 1 к измерению типа 2 . . . . . . . 219
Тип 7: Двойные измерения типа 1 и типа 2 . . . . . . . . . . . . . . . . . . . 220
Тип 7 для незапланированных отчетов «По состоянию на» . . . . . 222
Обобщение медленно меняющихся измерений . . . . . . . . . . . . . . . . . . . 223
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
6
Управление заказами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Матрица шины управления заказами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Транзакции по заказам . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Нормализация фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Ролевые измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Еще раз об измерении «Продукт» . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Измерение «Клиент» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Измерение «Сделка» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Вырожденное измерение для номера заказа . . . . . . . . . . . . . . . . 238
Мусорные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Паттерн заголовков/строк, которого следует избегать . . . . . . . . . 241
Несколько валют . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Факты о транзакциях с разной зернистостью . . . . . . . . . . . . . . . . 245
12
Оглавление
Еще один паттерн заголовка/строк, которого следует избегать 247
Операции по выставлению счета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Показатели уровня обслуживания в виде фактов, измерений
или того и другого . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Факты о прибылях и убытках . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Измерение «Аудит» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Накопление снимков для конвейера выполнения заказов . . . . . . . . . 256
Расчет задержек . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Несколько единиц измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
За пределами зеркала заднего вида . . . . . . . . . . . . . . . . . . . . . . . . . 261
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
7
Бухгалтерский учет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Тематическое исследование по бухгалтерскому
учету и матрица шин . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Данные Главной бухгалтерской книги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Периодический моментальный снимок
Главной бухгалтерской книги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
План счетов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Закрытие периода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Факты типа «С начала года и до сегодняшнего дня»
(year-to-date/YTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Пересмотр нескольких валют . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Транзакции журнала Главной бухгалтерской книги . . . . . . . . . . . 270
Несколько календарей финансового учета . . . . . . . . . . . . . . . . . . . 271
Детализация по многоуровневой иерархии . . . . . . . . . . . . . . . . . . 272
Финансовые отчеты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Процесс составления бюджета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Иерархии атрибутов измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Позиционные иерархии с фиксированной глубиной . . . . . . . . . . 278
Прерывающиеся иерархии переменной глубины . . . . . . . . . . . . . 279
Прерывающиеся иерархии переменной глубины . . . . . . . . . . . . . 280
Совместный доступ при прерывающейся иерархии . . . . . . . . . . 284
Неравномерная иерархия, изменяющаяся во времени . . . . . . . . 285
Изменение прерывающихся иерархий . . . . . . . . . . . . . . . . . . . . . . 285
Альтернативные подходы к моделированию прерывающейся
иерархии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Преимущества подхода с соединительной таблицей
для неравномерных иерархий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Оглавление
13
Консолидированные таблицы фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Роль OLAP и комплексных аналитических решений . . . . . . . . . . . . . . . 292
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
8
Управление взаимоотношениями с клиентами . . . . . . . . . . . . . . 295
Обзор CRM-системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Операционная и аналитическая CRM . . . . . . . . . . . . . . . . . . . . . . . . 298
Атрибуты измерения «Клиент» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Синтаксический анализ имени и адреса . . . . . . . . . . . . . . . . . . . . . 300
Некоторые соображения по поводу интернационализации
имен и адресов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Даты, ориентированные на клиента . . . . . . . . . . . . . . . . . . . . . . . . 306
Агрегированные факты как атрибуты измерений . . . . . . . . . . . . . 307
Взаимосвязь между интеллектуальным анализом данных
и системой DW/BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Различные счетчики в измерениях типа 2 . . . . . . . . . . . . . . . . . . . . 311
Выносное внешнее измерения для атрибутов
с низкой кардинальностью . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Соображения об иерархии клиентов . . . . . . . . . . . . . . . . . . . . . . . . . 313
Соединительные таблицы для многозначных измерений . . . . . . . . . 314
Соединительные таблицы для разреженных атрибутов . . . . . . . . 316
Соединительная таблица для нескольких контактов
с клиентами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Сложное поведение клиента . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Группы по изучению поведения для когорт . . . . . . . . . . . . . . . . . . . 318
Измерение «Шаг» для последовательного поведения . . . . . . . . . 320
Таблицы фактов временного интервала . . . . . . . . . . . . . . . . . . . . . . 321
Пометка таблиц фактов показателями удовлетворенности . . . . 324
Пометка таблиц фактов индикаторами ненормальных
сценариев . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Подходы к интеграции клиентских данных . . . . . . . . . . . . . . . . . . . . . . . 326
Управление основными данными при создании единого
измерения «Клиент» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Частичная согласованность нескольких
измерений «Клиент» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Избегание соединений таблицы фактов с таблицами
фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Проверка реальности с низкими задержками . . . . . . . . . . . . . . . . . . . . . 331
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
14
Оглавление
9
Управление персоналом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Отслеживание профиля сотрудников . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Точное время вступления в силу и истечения срока действия . . . 336
Отслеживание причин изменения параметров . . . . . . . . . . . . . . . 336
Изменения профиля как атрибуты типа 2 или события факта . . . 337
Периодический снимок численности персонала . . . . . . . . . . . . . . . . . . 338
Матрица шин для HR-процессов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Комплексные аналитические решения и модели данных . . . . . . . . . . 341
Рекурсивные иерархии сотрудников . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Отслеживание изменений на встроенном ключе менеджера . . . 344
Детализация иерархий управления: вверх и вниз . . . . . . . . . . . . . 344
Многозначные атрибуты ключевых навыков сотрудников . . . . . . . . . 346
Ключевые слова для навыков сотрудников . . . . . . . . . . . . . . . . . . 347
Текстовая строка для ключевого слова навыка . . . . . . . . . . . . . . . 348
Данные анкеты-опросника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Текстовые комментарии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
10 Финансовые услуги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Тематическое исследование банковского дела и матрица шин . . . . 354
Рассмотрение измерений для исключения «недостаточного
количества измерений» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Измерение «Домохозяйство» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Многозначные измерения и весовые коэффициенты . . . . . . . . . 360
Пересмотр мини-измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Добавление мини-измерений к соединительным таблицам . . . 364
Динамическая группировка значений в таблицах фактов . . . . . . 365
Схемы супертипов и подтипов для разнородных продуктов . . . . . . . 366
Супертипы и подтипы банковских продуктов
с общими фактами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Измерения с возможностью быстрой замены . . . . . . . . . . . . . . . . . . . . . 370
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
11
Телекоммуникации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Тематическое исследование телекоммуникаций и матрица шин . . . . 371
Общие соображения по рассмотрению и оценке проекта . . . . . . . . . 374
Сбалансируйте бизнес-требования и исходные реалии . . . . . . . . 374
Сосредоточьтесь на бизнес-процессах . . . . . . . . . . . . . . . . . . . . . . . 374
Оглавление
15
Зернистость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Единая зернистость фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Зернистость измерений и иерархии . . . . . . . . . . . . . . . . . . . . . . . . 376
Измерение «Дата» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Вырожденные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Суррогатные ключи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Расшифровки и описания в измерениях . . . . . . . . . . . . . . . . . . . . . 379
Приверженность согласованности . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Рекомендации по рассмотрению проекта . . . . . . . . . . . . . . . . . . . 380
Обсуждение эскизного проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Изменение существующих структур данных . . . . . . . . . . . . . . . . . . . . . . 385
Измерение «Географическое положение» . . . . . . . . . . . . . . . . . . . . . . . . 386
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
12 Транспортировка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Тематическое исследование авиакомпаний
и матрица шин для них . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Зернистость нескольких таблиц фактов . . . . . . . . . . . . . . . . . . . . . . 391
Объединение сегментов в поездки . . . . . . . . . . . . . . . . . . . . . . . . . 394
Таблицы связанных фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Расширения для других отраслей промышленности . . . . . . . . . . . . . . 396
Грузоотправитель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Туристические услуги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Объединение коррелированных измерений . . . . . . . . . . . . . . . . . . . . . . 398
Класс обслуживания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Пункты отправки и назначения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Дополнительные соображения о дате и времени . . . . . . . . . . . . . . . . . . 401
Календари для конкретных стран в качестве внешних
выносных измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Дата и время в нескольких часовых поясах . . . . . . . . . . . . . . . . . . 403
Краткое описание локализации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
13 Образование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Тематическое исследование университета и матрица шин . . . . . . . . 405
Таблицы фактов накопительных моментальных снимков . . . . . . . . 406
Конвейер кандидатов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Конвейер предложений по исследовательским грантам . . . . . . 410
16
Оглавление
Таблицы фактов без фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
События приема . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Регистрация на курсы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Использование объекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Посещаемость студентов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Увеличение образовательных аналитических возможностей . . . . . . 417
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
14 Здравоохранение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Тематическое исследование здравоохранения и матрица шин . . . . 419
Выставление счетов и платежей по претензиям . . . . . . . . . . . . . . . . . . . 423
Ролевое измерение «Дата» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Многозначные диагнозы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Супертипы и подтипы для запросов оплаты . . . . . . . . . . . . . . . . . 429
Электронные медицинские записи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Измерение «Тип измерения» для разреженных фактов . . . . . . . . . 431
Текстовые комментарии произвольной формы . . . . . . . . . . . . . . 432
Изображения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Использование инвентаря помещений, оборудования . . . . . . . . . . . . 433
Работа с ретроактивными изменениями . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
15 Электронная коммерция . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Источники данных для потока кликов . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Проблемы с данными из потоков кликов . . . . . . . . . . . . . . . . . . . . 438
Размерные модели потока кликов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Измерение «Событие» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Измерение «Сеанс» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Измерение «Направление» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Таблица фактов сеанса потока кликов . . . . . . . . . . . . . . . . . . . . . . 446
Таблица фактов события страницы потока кликов . . . . . . . . . . . 449
Измерение «Шаг» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Агрегированные таблицы фактов потока кликов . . . . . . . . . . . . . 452
Google Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Интеграция потока кликов в матрицу шин интернет-магазина . . . . . 454
Прибыльность по всем каналам, включая веб . . . . . . . . . . . . . . . . . . . . . 456
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Оглавление
17
16 Страхование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Изучение предметной области «Страхование» . . . . . . . . . . . . . . . . . . . . 462
Цепочка создания стоимости страхования . . . . . . . . . . . . . . . . . . . 463
Проект матрицы шины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Транзакции по страховому полису . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Ролевые измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Медленно меняющиеся измерения . . . . . . . . . . . . . . . . . . . . . . . . . 467
Мини-измерения для больших или быстро меняющихся
атрибутов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Многозначные атрибуты измерений . . . . . . . . . . . . . . . . . . . . . . . . 469
Числовые атрибуты как факты или измерения . . . . . . . . . . . . . . . 469
Вырожденные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Таблицы измерений с низкой кардинальностью . . . . . . . . . . . . . . 470
Измерение «Аудит» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Таблица фактов транзакций по полису . . . . . . . . . . . . . . . . . . . . . . 470
Гетерогенные продукты: супертипы и подтипы . . . . . . . . . . . . . . . 471
Дополнительная стратегия, накапливающая
моментальный снимок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Премиальный периодический страховых взносов . . . . . . . . . . . . . . . . . 473
Согласованные измерения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Согласованные факты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Факты о предоплате . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Пересмотр гетерогенных супертипов и подтипов . . . . . . . . . . . . 475
Пересмотр многозначных измерений . . . . . . . . . . . . . . . . . . . . . . . 476
Более подробная информация об изучении страховых случаев . . . 476
Обновленная матрица страховой шины . . . . . . . . . . . . . . . . . . . . . 477
Подробная матрица шины реализации . . . . . . . . . . . . . . . . . . . . . . 478
Операции с претензиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Транзакция в сравнении с мусорным измерением
«Профиль претензии» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Накопительный моментальный снимок для претензий . . . . . . . . . . . . 481
Накопление моментальных снимков для сложных рабочих
процессов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Накопительный моментальный снимок во времени . . . . . . . . . . . 483
Моментальный снимок вместо периодического . . . . . . . . . . . . . . 484
Консолидированный периодический снимок полисов/претензий . . 484
События без фактов, связанные с несчастными случаями . . . . . . . . . 485
Типичные ошибки размерного моделирования, которых
следует избегать . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
18
Оглавление
Ошибка 10: размещение текстовых атрибутов
в таблице фактов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Ошибка 9: ограничивать подробные дескрипторы
для экономии места . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Ошибка 8: разделение иерархий на несколько измерений . . . . . 487
Ошибка 7: игнорировать необходимость отслеживать
изменения измерений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Ошибка 6: решение всех проблем с производительностью
с помощью большего количества оборудования . . . . . . . . . . . . . 488
Ошибка 5: использование натуральных ключей
для соединения измерений и фактов . . . . . . . . . . . . . . . . . . . . . . . 489
Ошибка 4: пренебрежение декларированием и соблюдением
зернистости таблиц фактов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Ошибка 3: использовать отчет для разработки
размерной модели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Ошибка 2: ожидать, что пользователи будут запрашивать
нормализованные атомарные данные . . . . . . . . . . . . . . . . . . . . . . 490
Ошибка 1: терпеть неудачу при попытке построить
согласованные измерения и факты . . . . . . . . . . . . . . . . . . . . . . . . . 490
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
17 Обзор жизненного цикла хранилища данных
по Кимбаллу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Дорожная карта жизненного цикла . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Дорожная карта и верстовые столбы . . . . . . . . . . . . . . . . . . . . . . . 495
Мероприятия по запуску жизненного цикла . . . . . . . . . . . . . . . . . . . . . . 496
Планирование и управление программами/проектами . . . . . . . . 496
Определение бизнес-требований . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Отслеживание технологии жизненного цикла . . . . . . . . . . . . . . . . . . . . 508
Технический архитектурный дизайн . . . . . . . . . . . . . . . . . . . . . . . . 508
Выбор и установка продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Отслеживание данных жизненного цикла . . . . . . . . . . . . . . . . . . . . . . . . 513
Размерное моделирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Физический дизайн . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Проектирование и разработка ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Отслеживание приложений BI жизненного цикла . . . . . . . . . . . . . . . . 516
Спецификация приложения BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Разработка приложений BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Мероприятия по завершении жизненного цикла . . . . . . . . . . . . . . . . . . 517
Развертывание . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Оглавление
19
Поддержка и рост . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Распространенные подводные камни, которых
следует избегать . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
18 Процессы и задачи размерного моделирования . . . . . . . . . . . . 523
Обзор процесса моделирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Подготовка к процессу размерного моделирования . . . . . . . . . . . . . . . 525
Определение участников, особенно представителей бизнеса . . . . 525
Ознакомление с бизнес-требованиями . . . . . . . . . . . . . . . . . . . . . . 526
Использование инструмента моделирования . . . . . . . . . . . . . . . . 527
Использование инструмента профилирования данных . . . . . . . . 527
Использование или определение соглашения
об именовании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Координация календарей и помещений . . . . . . . . . . . . . . . . . . . . . 528
Разработка размерной модели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Достижение консенсуса по пузырьковой диаграмме
высокого уровня . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Разработка детальной размерной модели . . . . . . . . . . . . . . . . . . . . 531
Просмотр и подтверждение модели . . . . . . . . . . . . . . . . . . . . . . . . 535
Доработка проектной документации . . . . . . . . . . . . . . . . . . . . . . . 537
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
19 Подсистемы и методы ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Обобщение требований . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Потребности бизнеса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Соответствие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Качество данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Интеграция данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Задержка передачи данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Архивирование и происхождение . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Интерфейсы доставки BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Доступные навыки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Существующие на предприятии лицензии . . . . . . . . . . . . . . . . . . . 546
34 подсистемы ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Извлечение: получение данных в хранилище данных . . . . . . . . . . . . . 547
Подсистема 1: профилирование данных . . . . . . . . . . . . . . . . . . . . 547
Подсистема 2: изменение системы сбора данных . . . . . . . . . . . . 548
20
Оглавление
Подсистема 3: система извлечения . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Очистка и согласование данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Улучшение культуры и процессов качества данных . . . . . . . . . . . 553
Подсистема 4: система очистки данных . . . . . . . . . . . . . . . . . . . . . 555
Подсистема 5: схема событий ошибок . . . . . . . . . . . . . . . . . . . . . . 557
Подсистема 6: ассемблер измерений «Аудит» . . . . . . . . . . . . . . . . 559
Подсистема 7: система дедупликации . . . . . . . . . . . . . . . . . . . . . . 559
Подсистема 8: согласующая система . . . . . . . . . . . . . . . . . . . . . . . 560
Доставка данных: подготовка к презентации . . . . . . . . . . . . . . . . . . . . . . 562
Подсистема 9: управление медленно меняющимися
измерениями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Подсистема 10: генератор суррогатных ключей . . . . . . . . . . . . . . 569
Подсистема 11: менеджер иерархии . . . . . . . . . . . . . . . . . . . . . . . . 570
Подсистема 12: менеджер специальных измерений . . . . . . . . . . 570
Подсистема 13: составители таблиц фактов . . . . . . . . . . . . . . . . . 573
Подсистема 14: конвейер суррогатных ключей . . . . . . . . . . . . . . . 576
Подсистема 15: конструктор соединительных многозначных
параметров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Подсистема 16: обработчик данных с задержкой . . . . . . . . . . . . . 579
Подсистема 17: система управления измерениями . . . . . . . . . . . 580
Подсистема 18: система предоставления фактов . . . . . . . . . . . . . . 581
Подсистема 19: агрегатный конструктор . . . . . . . . . . . . . . . . . . . . 582
Подсистема 20: конструктор кубов OLAP . . . . . . . . . . . . . . . . . . . . 583
Подсистема 21: менеджер распространения данных . . . . . . . . . . 584
Управление средой ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Подсистема 22: планировщик заданий . . . . . . . . . . . . . . . . . . . . . . 585
Подсистема 23: система резервного копирования . . . . . . . . . . . . 587
Подсистема 24: восстановление и перезапуск системы . . . . . . . 589
Подсистема 25: система контроля версий . . . . . . . . . . . . . . . . . . . . 591
Подсистема 26: система миграции версий . . . . . . . . . . . . . . . . . . . . 591
Подсистема 27: монитор рабочего процесса . . . . . . . . . . . . . . . . . 592
Подсистема 28: система сортировки . . . . . . . . . . . . . . . . . . . . . . . . 593
Подсистема 29: анализатор происхождения и зависимостей . . . 594
Подсистема 30: система эскалации проблем . . . . . . . . . . . . . . . . 594
Подсистема 31: система распараллеливания/конвейеризации . . . 596
Подсистема 32: система безопасности . . . . . . . . . . . . . . . . . . . . . . 596
Подсистема 33: менеджер по соблюдению требований . . . . . . . 597
Подсистема 34: менеджер хранилища метаданных . . . . . . . . . . . 600
Выводы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Оглавление
21
20 Задачи и процессы разработки и проектирования
систем ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Обзор процесса ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Разработка плана ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Шаг 1: разработка плана высокого уровня . . . . . . . . . . . . . . . . . . . 602
Шаг 2: выбор инструмента ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Шаг 3: разработка стратегий по умолчанию . . . . . . . . . . . . . . . . . . 604
Шаг 4: детализация по целевой таблице . . . . . . . . . . . . . . . . . . . . 605
Разработка системы разовой загрузки исторических данных . . . . . . 608
Шаг 5. заполнение таблицы измерений историческими
данными . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Шаг 6: загрузка истории таблицы фактов . . . . . . . . . . . . . . . . . . . . . 614
Инкрементная обработка ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Шаг 7: инкрементная обработка таблицы измерений . . . . . . . . . 619
Шаг 8. инкрементная обработка таблицы фактов . . . . . . . . . . . . 622
Шаг 9: сводная таблица и загрузка OLAP . . . . . . . . . . . . . . . . . . . . 626
Шаг 10: эксплуатация и автоматизация системы ETL . . . . . . . . . . 627
Последствия обработки в реальном времени . . . . . . . . . . . . . . . . . . . . . 628
Рассмотрение в реальном времени . . . . . . . . . . . . . . . . . . . . . . . . . 628
Компромиссы в архитектуре реального времени . . . . . . . . . . . . . 630
Разделы данных в режиме реального времени на сервере
презентаций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
21 Аналитика Big data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Обзор больших данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Расширенная архитектура СУБД . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Архитектура MapReduce/Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Сравнение архитектур Big data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Рекомендуемые лучшие практики для Big data . . . . . . . . . . . . . . . . . . . . 641
Лучшие практики менеджмента Big data . . . . . . . . . . . . . . . . . . . . 642
Лучшие практики архитектуры Big data . . . . . . . . . . . . . . . . . . . . . 644
Лучшие практики моделирования Big data . . . . . . . . . . . . . . . . . . . 650
Лучшие практики управления Big data . . . . . . . . . . . . . . . . . . . . . . 654
Резюме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Благодарности
В
о-первых, спасибо сотням тысяч читателей наших книг серии «Инструментарий», посетителей наших курсов и участников наших консалтинговых
проектов. Вместе вы оказали глубоко положительное влияние на отрасль хранения и анализа данных. Поздравляем!
Наши коллеги из Kimball Group — Боб Бекер, Джой Манди и Уоррен Торнтуэйт — работали с нами, применяя методы, описанные в этой книге, буквально
тысячи раз в течение практически 30 лет совместной работы. Каждый метод был
исследован на практике в реальном мире. Мы ценим их вклад в эту книгу и обратную связь по ней, а также, что более важно, те годы, которые мы разделили
в качестве деловых партнеров с Джули Кимбалл.
Боб Элиот, наш исполнительный редактор в John Wiley & Sons, редактор проекта Морин Спирс, а также другие участники команды Wiley поддерживали этот
проект своими умениями и энтузиазмом. Как и всегда, было приятно работать
с ними.
Нашим семьям: спасибо вам за вашу безоговорочную поддержку в нашей
карьере. Супруги Джули Кимбалл и Скотт Росс, дети Сара Хейден Смит, Брайан Кимбалл и Кэти Росс — все оказали неоценимую поддержку в создании этой
книги.
Введение
О
трасль хранения данных (DW, Data Warehousing) и анализа данных (BI,
Business Intelligence) стала развиваться с момента публикации первого издания «Инструментарий хранилищ данных» Ральфа Кимбалла в 1996 г. Хотя
ранние крупные корпоративные последователи проложили путь, концепции
DW/BI с тех пор были охвачены организациями всех размеров. Отрасль создала
тысячи систем DW/BI. Объем данных продолжает расти, поскольку хранилища наполнены растущим количеством атомарных данных и обновляются со все
большей частотой. На протяжении нашей карьеры мы видели, что базы данных
растут с мегабайтов и гигабайтов до терабайтов и петабайтов, но все же основная
задача систем DW/BI остается на удивление постоянной.
Наша работа состоит в том, чтобы передать их бизнес-клиентам для помощи в принятии решений. Мы пришли к этой цели коллективно, бизнеспрофессионалы всегда и везде принимают лучшие решения и окупают свои инвестиции в системы DW/BI.
С момента, когда было опубликовано первое издание книги «Инструментарий хранилищ данных», размерное моделирование было принято в качестве основной техники для представления DW/BI. Практики и эксперты единогласно
признали, что представление данных должно быть основано на простоте, если вы
хотите иметь какие-либо шансы на успех. Простота — фундаментальный ключ,
который позволяет пользователям легко понимать базы данных и программное
обеспечение для эффективного использования баз данных. Последовательно
возвращаясь к перспективе, диктуемой бизнесом, и не компрометируя скорость
выполнения запросов и легкость понимания структур пользователями, вы устанавливаете последовательный дизайн, удовлетворяющий аналитическим нуждам
организации. Этот многомерно смоделированный фреймворк становится платформой BI. Основываясь на нашем опыте и ошеломительной обратной связи
многочисленных практиков из разных компаний, таких как вы, мы верим, что
размерное моделирование критически важно для успешной поддержки DW/BI.
Размерное моделирование также выступает в качестве ведущей архитектуры
для создания интегрированных систем DW/BI. Когда вы используете согласованные измерения и факты набора размерных моделей, вы имеете практичный
и предсказуемый фреймворк для пошагового создания комплексных систем
DW/BI, которые изначально распределены.
Введение
25
Учитывая, как много изменений произошло в нашей отрасли, основные методы размерного моделирования, опубликованные Ральфом Кимбаллом 17 лет
назад, претерпели проверку временем. Концепции, такие как согласованные
измерения, медленно меняющиеся измерения, разнородные продукты, таблицы фактов без метрик, а также матрица шины предприятия продолжают обсуждаться на симпозиумах по всему земному шару. Оригинальные понятия были
детализированы и расширены новыми дополнительными методами. Мы решили
опубликовать это третье издание оригинальной работы Кимбалла, так как чувствовали, что будет полезно суммировать наш коллективный опыт размерного
моделирования под общей обложкой. Каждый из нас концентрировался исключительно на поддержке принятия решений, хранилищах и анализе данных в течение более чем трех десятилетий. Мы хотим поделиться паттернами размерного
моделирования, которые неоднократно появлялись в ходе нашей карьеры. Книга
нагружена специфическими практическими рекомендациями по проектированию, основанными на реальных сценариях.
Цель этой книги состоит в том, чтобы предоставить универсальный магазин
для методов размерного моделирования. Соответственно своему названию книга
представляет собой набор инструментов, принципов и методов размерного проектирования. Мы стремимся удовлетворить потребности тех, кто только начинает знакомство с DW/BI, и описываем расширенные понятия для тех из вас, кто
уже давно знаком с DW/BI. Мы убеждены, что эта книга выделяется глубиной
освещения темы размерного моделирования. Это исчерпывающее руководство.
Для кого эта книга
Книга предназначена для разработчиков в сфере хранилищ и анализа данных,
инженеров и менеджеров. Кроме того, книгу найдут полезной аналитики данных
и люди, управляющие данными, активно взаимодействующие с DW/BI.
Даже если вы прямо не связаны с размерной моделью, мы считаем важным,
чтобы все члены команды проекта были знакомы с понятиями размерного моделирования. Размерная модель оказывает влияние на большинство аспектов
реализации DW/BI, начиная от перевода бизнес-требований через процессы извлечения, преобразования и загрузки (extract, transformation, load — ETL) и заканчивая открытием хранилища данных через приложения аналитики данных.
Из-за широкого спектра применения вы должны быть сведущими в размерном
моделировании независимо от того, за что именно вы ответственны — за управление проектом, анализ данных, архитектуру данных, проектирование баз данных, ETL, приложения BI или обучение и поддержку. Мы написали эту книгу
таким образом, что она доступна для широкой аудитории.
26
Введение
Те из вас, кто читал ранние издания этой книги, найдут некоторые уже знакомые тематические исследования, однако они были значительно обновлены и обогащены содержанием, включая примеры матриц шин предприятий почти для
каждого тематического исследования. Мы разработали краткие описания для
новых предметных областей, включая анализ больших данных.
Содержание этой книги техническое. Впервые мы обсудим размерное моделирование в контексте реляционных баз данных с нюансами для кубов аналитической обработки в реальном времени (OLAP — online analytical processing),
что отмечено в соответствующих случаях. Мы предполагаем, что вы имеете базовые понятия о реляционных базах данных, такие как таблицы, строки, ключи
и объединения таблиц (join). Поскольку мы будем обсуждать размерные модели
в нетрадиционном ключе, мы не станем углубляться в конкретные рекомендации
по физическому проектированию и настройке любых описываемых СУБД.
Структура книги
Книга организована вокруг серий кратких описаний или примеров. Мы считаем,
что разработка техник проектирования с помощью примеров — весьма эффективный способ, поскольку позволяет делиться реальным руководством и извлекать
выгоду из опыта реального мира. Хотя эти примеры не предназначены для того,
чтобы стать полномасштабными приложениями или решениями для отрасли, они
служат основой для обсуждения паттернов, появляющихся в размерном моделировании. По нашему опыту, зачастую легче уловить главные элементы метода разработки, если отступить от слишком знакомых сложностей собственного бизнеса.
Читатели предыдущих изданий благоприятно отозвались о таком подходе.
Предупреждаем вас, что мы отклоняемся от подхода учебных примеров в главе 2. Учитывая широкое промышленное принятие методов размерного моделирования, разработанных Kimball Group, мы составили официальный список наших методов наряду с краткими описаниями и указателями на более подробное
освещение и иллюстрации этих методов в последующих главах. Хотя эту главу
необязательно читать от начала и до конца, как другие, мы считаем, что эта центральная техническая глава может быть полезной ссылкой и может даже послужить профессиональным контрольным списком для разработчиков DW/BI.
За исключением главы 2 остальные части этой книги опираются друг на друга.
Мы начинаем с базовых понятий и представляем более расширенное содержание
по мере чтения. Главы следует читать по порядку каждому читателю. Например,
может быть сложно осмыслить главу 16, пока вы не прочтете предыдущие главы
о розничных продажах, закупках, управлении персоналом и управлении отношениями с клиентами.
Введение
27
Тот, кто читал предыдущее издание, может пропустить первые несколько глав.
Хотя некоторые ранние факты и изучение измерений могут быть вам знакомы,
мы бы не хотели, чтобы вы забегали слишком далеко вперед. Вы упустите новое
в фундаментальных понятиях, если пролистаете много.
ПРИМЕЧАНИЕ Книга наполнена подсказками (такими, как это примеча-
ние), списками ключевых понятий и указателями на главы, которые будут более
полезны и на которые будет легче ссылаться в будущем.
Глава 1. Хранение данных, анализ данных и основы
размерного моделирования
Книга начинается с основ хранения данных, анализа данных и размерного моделирования. Мы исследуем компоненты всей архитектуры DW/BI и устанавливаем основной словарь, который будет использоваться в книге. Будут развеяны
некоторые мифы и заблуждения о размерном моделировании.
Глава 2. Обзор методов размерного моделирования
Кимбалла
Эта глава описывает более 75 методов размерного моделирования и паттернов.
Этот официальный список методов Кимбалла включает указатели на последующие главы, где методы воплощены на примерах.
Глава 3. Розничные продажи
Розничные продажи — это классический пример, используемый для иллюстрирования размерного моделирования. Мы начинаем с классики, поскольку это то,
что все понимают. Надеемся, вам не понадобится глубоко задумываться об отрасли, поскольку мы хотим, чтобы вы сфокусировались на основных понятиях
размерного моделирования. Мы начнем с обсуждения четырехэтапного процесса разработки размерных моделей. Мы подробно изучим таблицы измерений,
включая измерение «Дата», которое будет регулярно повторно использоваться в книге. Мы также обсудим вырожденные измерения, понятие «снежинка»
и суррогатные ключи. Даже если вы не разрабатываете проект в сфере продаж,
эта глава важна, поскольку наполнена основными принципами.
Глава 4. Склад
Мы останемся в отрасли розничных продаж для изучения следующего примера, но обратим ваше внимание к другому бизнес-процессу. Эта глава представляет архитектуру шины предприятия по хранению данных и матрицу шины
28
Введение
с согласованными измерениями. Эти понятия очень важны для любого, кто
стремится к созданию интегрированной и расширяемой архитектуры DW/BI.
Мы также сравним три основных типа таблиц фактов: транзакционные таблицы,
таблицы фактов периодических моментальных снимков и таблицы фактов кумулятивных моментальных снимков.
Глава 5. Закупки
Эта глава укрепляет важность рассмотрения цепочки ценностей организации в процессе подготовки среды DW/BI. Мы также исследуем серии базовых
и расширенных методов обработки признаков медленно меняющихся измерений и будем основываться на изменениях типа 1 (перезапись), типа 2 (добавить
строку) и типа 3 (добавить столбец), когда будем представлять читателям тип 0
и типы с 4 по 7.
Глава 6. Управление заказами
В этом примере мы изучим бизнес-процессы, которые, как правило, реализуются
первыми в системах DW/BI, поскольку они предоставляют основные метрики
исполнения бизнеса — что мы продаем каждому клиенту и по какой цене? Мы
обсудим измерения, играющие множество ролей в этой схеме. Мы также исследуем наиболее частые проблемы, с которыми сталкиваются создатели моделей при
работе с информацией об управлении заказами, такими как соглашения об именовании заголовков/строк, множественные значения атрибутов или единицы
измерения и мусорные измерения с разными операционными индикаторами.
Глава 7. Бухгалтерский учет
Мы обсудим моделирование главной бухгалтерской книги для хранилищ данных в этой главе. Мы опишем соответствующую обработку фактов YTD (Yearto-date) и нескольких фискальных календарей, а также объединенные таблицы
данных, которые объединяют данные различных бизнес-процессов. Мы также
предоставим детальное руководство по иерархии признаков измерений, начиная
с простых денормализованных фиксированных глубоких иерархий и заканчивая
сопоставительными таблицами для навигации по более сложным рваным переменным глубоких иерархий.
Глава 8. Управление взаимоотношениями с клиентами
Многие системы DW/BI были построены на предпосылке, что вы должны лучше
понимать, чтобы обслужить своих клиентов. В этой главе рассматриваются измерение «Клиент», включая стандартизацию адреса и сопоставительные таблицы
Введение
29
для многозначных признаков измерений. Мы также описываем паттерны моделирования сложного поведения потребителей, такие как консолидация данных
клиентов из нескольких источников.
Глава 9. Управление персоналом
В этой главе рассматривается несколько уникальных аспектов моделей измерений «Управление персоналом», включая ситуацию, в которой таблица измерений начинает вести себя как таблица фактов. Мы обсуждаем комплексные аналитические решения, обработку рекурсивных иерархий управления и опросные
анкеты. Сравниваются несколько методов обработки многозначных атрибутов.
Глава 10. Финансовые услуги
В банковском примере рассматривается концепция схем супертипа и подтипа
для разнородных продуктов, в которых каждая сфера деятельности имеет уникальные описательные признаки и показатели эффективности. Очевидно, что
необходимость обрабатывать разнородные продукты неуникальна для финансовых услуг. Мы также обсуждаем сложные отношения между счетами, клиентами
и домашними хозяйствами.
Глава 11. Телекоммуникации
Эта глава структурирована несколько иначе, чтобы побудить вас критически мыслить при выполнении анализа архитектуры размерной модели. Начнем с размерного дизайна, который на первый взгляд выглядит правдоподобно. Сможете ли
вы найти проблемы? Кроме того, мы исследуем особенности географических измерений местоположения.
Глава 12. Транспортировка
В этом примере мы рассмотрим связанные таблицы фактов на разных уровнях
детализации, указывая на уникальные характеристики таблиц фактов, описывающих сегменты в путешествии или сети. Мы более детально рассмотрим измерения даты и времени, охватывая специфичные для страны календари и синхронизацию между несколькими часовыми поясами.
Глава 13. Образование
В этой главе мы рассмотрим несколько таблиц фактов без метрик. Кроме того, мы
исследуем таблицы фактов кумулятивных моментальных снимков для обработки
заявок студентов и заявок на гранты на исследования. В этой главе вы оцените
разнообразие бизнес-процессов в образовательном учреждении.
30
Введение
Глава 14. Здравоохранение
Некоторые из самых сложных моделей, с которыми мы когда-либо работали, относятся к сфере здравоохранения. Эта глава иллюстрирует обработку таких трудных случаев, включая использование соединительных таблиц для моделирования
множества диагнозов и поставщиков медицинских услуг, которые осуществляют
лечение пациентов.
Глава 15. Электронная коммерция
Эта глава фокусируется на нюансах веб-данных о потоке кликов, включая их
уникальные измерения. Мы также представляем измерение «Шаг», которое
используется для лучшего понимания любого процесса, состоящего из последовательных шагов.
Глава 16. Страхование
Последний пример объединяет многие паттерны, которые мы обсуждали ранее
в книге, в единый набор взаимосвязанных схем. Эту главу можно рассматривать
как главу, которая сводит все воедино, поскольку методы моделирования накладываются друг на друга.
Глава 17. Обзор жизненного цикла Кимбалла
Теперь, когда вам удобно разрабатывать размерные модели, мы предлагаем общий обзор действий, с которыми сталкиваются в течение срока службы типичного проекта DW/BI. Эта глава представляет собой краткий обзор второго издания
книги «Инструментарий хранилища данных», над которым мы работали в соавторстве с Бобом Беккером, Джой Манди и Уорреном Торнтуэйтом.
Глава 18. Процессы и задачи размерного моделирования
В этой главе изложены конкретные рекомендации по решению задач размерного моделирования в рамках жизненного цикла Кимбалла. Первые 16 глав этой
книги охватывают методы размерного моделирования и паттерны проектирования, здесь же описываются обязанности, инструкции и результаты деятельности
по проектированию размерного моделирования.
Глава 19. Подсистемы и методы ETL
Система извлечения, преобразования и загрузки потребляет непропорционально большую долю времени и усилий, необходимых для создания среды DW/BI.
Тщательное рассмотрение передового опыта выявило 34 подсистемы, найденные
в основе почти каждого хранилища данных. Эта глава начинается с требований
Введение
31
и ограничений, которые необходимо учитывать перед проектированием системы
ETL, а затем она описывает 34 подсистемы извлечения, очистки, согласования,
доставки и управления.
Глава 20. Задачи и процессы разработки
и проектирования систем ETL
Эта глава посвящена конкретным тактическим действиям и антипаттернам, связанным с проектированием и разработкой ETL. Она обязательна к прочтению
всем, кто отвечает за обязанности ETL.
Глава 21. Аналитика больших данных
В заключительной главе мы сосредоточимся на популярной теме больших данных (Big Data). Мы считаем, что большие данные — естественное продолжение
ваших обязанностей в области DW/BI. Мы начнем с обзора нескольких архитектурных альтернатив, в том числе MapReduce и Hadoop, и опишем, как эти
альтернативы могут сосуществовать с вашей текущей архитектурой DW/BI. Затем мы рассмотрим лучшие практики управления, архитектуры, моделирования
и управления большими данными.
Веб-сайты
Сайт Kimball Group наполнен дополнительными материалами и ресурсами для
моделирования:
1. Зарегистрируйтесь для получения советов Кимбалла по дизайну, чтобы получить практическое руководство по размерному моделированию и темам
DW/BI.
2. Получите доступ к архиву из более чем 300 советов и статей по архитектуре.
3. Узнайте о публичных и выездных занятиях в Университете Кимбалла по качественному, независимому от поставщиков обучению в соответствии с нашим опытом и публикациями.
4. Узнайте о консалтинговых услугах Kimball Group, чтобы использовать наш
многолетний опыт DW/BI.
5. Задайте вопросы другим осведомленным в измерении участникам на форуме Kimball.
32
Введение
Выводы
Цель этой книги — рассказать о принятых в индустрии и проверенных годами методах размерного моделирования и разработки, основанных на более чем
60-летнем опыте авторов и извлеченных уроках в реальной бизнес-среде. DW/
BI-системы должны основываться на потребностях бизнес-клиентов и поэтому
разрабатываться и представляться с простой размерной точки зрения. Мы уверены, что вы окажетесь на один гигантский шаг ближе к успеху в области DW/
BI, если купите это издание.
Теперь, когда вы знаете, куда направляетесь, пришло время погрузиться в детали. Мы начнем с учебника по DW/BI и размерному моделированию в главе 1,
чтобы убедиться, что все находятся на одной волне в отношении ключевых терминов и архитектурных концепций.
1
Э
Хранение
данных,
анализ данных
и основы
размерного
моделирования
та глава закладывает основу для следующих. Мы начнем изучение систем
хранения и анализа данных (data warehousing and business intelligence,
DW/BI) с перспективы высокого уровня. Вы можете быть разочарованы, узнав,
что мы не начинаем с технологий и инструментов, но прежде всего система
DW/BI должна учитывать потребности бизнеса. Сформулировав четкие потребности бизнеса, мы двинемся в обратном направлении через логический, а затем
физический дизайн наряду с решениями по поводу технологии и инструментов.
В этой главе мы закладываем основы понимания в отношении целей хранения и анализа данных, наблюдая при этом странное сходство между обязанностями менеджера DW/BI и издателя.
С этой высокоуровневой перспективы мы исследуем основные концепции
размерного моделирования и установим основной словарь. В этой главе мы обсудим основные компоненты DW/BI-архитектуры Кимбалла, а также сравним
альтернативные архитектурные подходы. К счастью, независимо от архитектуры
вашей системы, в ней всегда найдется место для размерного моделирования. Наконец, мы рассмотрим общие мифы о моделировании. К концу этой главы вы
поймете, что вам нужно быть наполовину администратором базы данных (DBA)
и наполовину бизнес-аналитиком (MBA) при работе с проектом DW/BI.
В главе 1 обсуждаются следующие понятия:
■ бизнес-ориентированные цели DW/BI;
■ основные понятия и словарь размерного моделирования, включая таблицы
фактов и измерений;
■ компоненты и принципы DW/BI архитектуры Кимбалла;
34
Глава 1
■ сравнение альтернативных архитектур DW/BI и роли размерного моделирования в каждой из них;
■ заблуждения о размерном моделировании.
Различные миры сбора и анализа данных
Один из важнейших активов любой организации — ее данные. Этот актив почти всегда используется для двух целей: ведение оперативного учета и принятие
аналитических решений. Проще говоря, операционные системы (OLTP) — это
то место, куда вы вводите данные, а система DW/BI — это то место, откуда вы
извлекаете данные.
Пользователи операционной системы крутят колеса организации. Они принимают заказы, регистрируют новых клиентов, отслеживают состояние оперативной
деятельности и регистрируют жалобы. Операционные системы оптимизированы
для быстрой обработки транзакций. Эти системы почти всегда имеют дело с записью одной транзакции за раз. Они предсказуемо выполняют одни и те же операционные задачи снова и снова, выполняя бизнес-процессы организации. С учетом
этого факта операционные системы обычно не поддерживают историю изменения
данных, а обновляют их, чтобы отразить наиболее актуальное состояние.
Пользователи DW/BI-систем, с другой стороны, наблюдают за показателями
организации, чтобы оценить производительность. Они подсчитывают новые заказы, сравнивают их с заказами прошлой недели и спрашивают, почему новые
клиенты зарегистрировались и на что они жаловались. Они беспокоятся, правильно ли выполняются рабочие процессы. Хотя им нужны подробные данные
для поддержки их постоянно меняющихся вопросов, пользователи DW/BI почти никогда не имеют дела с одной транзакцией за раз. Эти системы оптимизированы для высокопроизводительных запросов, поскольку вопросы пользователей часто требуют поиска и сжатия сотен или сотен тысяч транзакций в набор
ответов. Чтобы еще больше усложнить ситуацию, пользователи DW/BI-систем
обычно требуют сохранения исторического контекста для точной оценки эффективности работы организации с течением времени.
В первом издании «Инструментарий хранилища данных» Ральф Кимбалл
посвятил целую главу описанию дихотомии между мирами оперативной обработки и хранения данных. В настоящее время широко признано, что система
DW/BI имеет совершенно другие потребности, клиентов, структуры и ритмы, нежели операционные системы записи информации. К сожалению, мы все
еще сталкиваемся с так называемыми системами DW/BI, которые скорее просто копии операционных систем записи, хранящихся на отдельной аппаратной платформе. Хотя эти среды могут учитывать необходимость изолировать
Хранение данных, анализ данных и основы размерного моделирования
35
операционную и аналитическую среды по соображениям производительности,
они ничего не делают для устранения других внутренних различий между двумя
типами систем. Бизнес-клиенты не в восторге от удобства использования и производительности, предоставляемых этими псевдохранилищами данных. Такие
самозванцы оказывают плохую услугу DW/BI, потому что они не признают, что
у их клиентов потребности совершенно не такие, как у пользователей операционной системы.
Цели хранения и анализа данных
Прежде чем мы углубимся в детали размерного моделирования, полезно сосредоточиться на основных целях хранения и анализа данных. Цели легко можно сформулировать, прогулявшись по холлу любой организации и прислушавшись к менеджерам. Эти повторяющиеся темы существуют уже более трех десятилетий:
■ «Мы собираем тонны данных, но не можем получить к ним доступ»;
■ «Нам нужно сгруппировать и отфильтровать данные различными спосо-
бами»;
■ «Люди, принимающие важные для бизнеса решения (бизнес-клиенты),
должны иметь доступ к необходимой им информации»;
■ «Просто покажи мне, что важно»;
■ «Мы проводим целые собрания, где спорим, у кого верные цифры,
а не принимаем решения»;
■ «Мы хотим, чтобы люди использовали информацию для поддержки принятия решений на основе фактов».
Исходя из нашего опыта скажем: эти проблемы все еще настолько универсальны, что определяют основные требования к системе DW/BI. Теперь превратим эти предложения по управлению бизнесом в требования.
■ Система DW/BI должна сделать информацию доступной.
Содержание системы DW/BI должно быть понятным. Данные должны
быть интуитивно понятными и очевидными для бизнес-клиента, а не только для разработчика. Структуры и метки данных должны имитировать мыслительные процессы и словарь бизнес-клиентов. Бизнес-клиенты хотят разделять и объединять аналитические данные в бесконечных комбинациях.
Инструменты и приложения аналитики данных, обеспечивающие доступ
к данным, должны быть простыми и удобными в использовании. Они также должны возвращать результаты запроса пользователю с минимальным
36
Глава 1
временем ожидания. Мы можем обобщить это требование, сказав «просто
и быстро».
■ Система DW/BI должна представлять информацию последовательно.
Данные в системе DW/BI должны быть достоверными, тщательно собранными из различных источников, очищенными, проверенными на качество
и выпущенными только тогда, когда они пригодны для использования пользователем. Согласованность также подразумевает использование общих меток и определений для содержимого системы DW/BI, которые используются
в разных источниках данных. Если два показателя производительности имеют одинаковое имя, они должны означать одно и то же. И наоборот, если
две меры не означают одно и то же, они должны быть помечены по-разному.
■ Система DW/BI должна адаптироваться к изменениям.
Потребности пользователей, условия бизнеса, данные и технологии могут
меняться. Система DW/BI должна быть спроектирована так, чтобы корректно обрабатывать это неизбежное изменение и чтобы не превращать
в недействительные существующие данные или приложения. Существующие данные и приложения не должны изменяться или разрушаться, когда
бизнес-сообщество задает новые вопросы или когда новые данные добавляются в хранилище. Наконец, если необходимо изменить описательные
данные в системе DW/BI, вы должны соответствующим образом учесть
эти изменения и сделать их прозрачными для пользователей.
■ Система DW/BI должна предоставлять информацию своевременно.
Поскольку система DW/BI более интенсивно используется для принятия
оперативных решений, сырые данные, возможно, придется преобразовать
в полезную информацию за часы, минуты или даже секунды. Команда DW/
BI и бизнес-клиенты должны иметь реалистичные ожидания в отношении
того, что означает предоставление данных, когда у них мало времени для их
очистки или проверки.
■ Система DW/BI должна быть бастионом, защищающим информационные активы.
Информационные «жемчужины» организации помещаются в хранилище
данных. Как минимум это хранилище содержит информацию о том, что
и кому вы продаете, а также по какой цене — это потенциально опасные
детали в руках не тех людей. Система DW/BI должна эффективно контролировать доступ к конфиденциальной информации организации.
Хранение данных, анализ данных и основы размерного моделирования
37
■ Система DW/BI должна служить авторитетной и заслуживающей доверия основой для более эффективного принятия решений.
Хранилище данных должно иметь правильные данные для поддержки
принятия решений. Наиболее важные результаты работы системы DW/
BI — решения, которые принимаются на основе представленных аналитических данных. Эти решения обеспечивают влияние на бизнес и ценность,
придаваемую системе DW/BI. Первоначальное название, предшествующее
названию DW/BI, — по-прежнему лучшее описание того, что вы разрабатываете: система поддержки принятия решений.
■ Деловое сообщество должно принять систему DW/BI, чтобы считать
ее успешной.
Неважно, что вы создали элегантное решение, используя лучшие в своем роде продукты и платформы. Если бизнес-сообщество не принимает
эту DW/BI-среду и не использует ее активно, вы не прошли вступительный тест. В отличие от реализации операционной системы, где у бизнесклиентов нет выбора, кроме как использовать новую систему, использование DW/BI иногда необязательно. Бизнес-клиенты будут использовать
систему DW/BI, если это простой и быстрый источник полезной информации.
Хотя каждое требование в этом списке значимо, последние два наиболее важны и, к сожалению, часто игнорируются. Успешное хранение и анализ данных
требуют большего, чем быть звездным архитектором, техником, разработчиком
моделей или администратором базы данных. Благодаря инициативе DW/BI вы
одной ногой стоите в своей зоне комфорта информационных технологий (ИТ),
в то время как ваша другая нога находится в незнакомой среде деловых пользователей. Вы должны управлять обеими, модифицируя некоторые проверенные
навыки, чтобы приспособиться к уникальным требованиям DW/BI. Очевидно,
что вам нужно иметь недюжинный талант, чтобы вести себя так, как будто вы
гибрид DBA и MBA.
Сравнение обязанностей менеджеров DW/BI
с издательским бизнесом
Исходя из целей DW/BI давайте сравним обязанности менеджеров DW/BI
с обязанностями главного редактора. Как редактор высококачественного журнала, вы будете иметь широкие возможности по управлению содержанием, стилем
и доставкой журнала. Любой, кто занимает эту должность, занимается следующими видами деятельности:
38
Глава 1
■ Понимать читателей:
❒ определить их демографические характеристики;
❒ найти, что читатели хотят видеть в этом журнале;
❒ определить «лучших» читателей, которые обновят свои подписки и купят товары у рекламодателей журнала;
❒ найти потенциальных новых читателей и ознакомить их с журналом.
■ Убедиться, что журнал обращается к читателям:
❒ выбирать интересный и востребованный контент;
❒ принимать решения о макете и визуализации, чтобы максимизировать
удовольствие читателей;
❒ поддерживать высококачественные стандарты письма и редактирования, придерживаясь единого стиля представления;
❒ постоянно контролировать точность статей и претензий рекламодателей;
❒ адаптироваться к изменяющимся профилям читателей и обеспечить доступность новых материалов от писателей и участников.
■ Поддерживать публикации:
❒ привлекать рекламодателей и вести журнал с прибылью;
❒ публиковаться на регулярной основе;
❒ поддерживать доверие читателей;
❒ удовлетворять требования владельцев бизнеса.
Вы также можете определить пункты, которые должны быть нецелевыми для
главного редактора. Это может быть создание журнала на основе конкретной
технологии печати или использование энергии руководства исключительно для
повышения эффективности работы. Сюда отнесем навязывание технического
стиля письма, который читатели не могут легко понять, или создание запутанного, перегруженного макета, который трудно читать.
Если издательский бизнес построен на основе эффективного обслуживания
читателей, то журнал, вероятно, будет успешным. И наоборот: просмотрите список и представьте, что произойдет, если вы пропустите какой-либо элемент —
в конце концов у журнала начнутся серьезные проблемы.
Можно провести яркие параллели между обычным издателем и менеджером
DW/BI. Руководствуясь потребностями бизнеса, менеджеры DW/BI должны
публиковать данные, которые были собраны из различных источников и отредактированы для обеспечения качества и согласованности. Основная обязанность
заключается в обслуживании читателей, иначе известных как бизнес-клиенты.
Образ публикации подчеркивает необходимость сосредоточиться на ваших клиентах, а не просто фокусироваться на продуктах и процессах. Хотя вы используете технологию для доставки системы DW/BI, эта технология — в лучшем случае
Хранение данных, анализ данных и основы размерного моделирования
39
средство для достижения цели. Таким образом, технологии и методы, использованные для разработки системы, не должны прямо отражаться в ваших главных
должностных обязанностях.
Теперь измените обязанности издателя журнала на обязанности менеджера
DW/BI:
■ Понимать бизнес-клиентов:
❒ понимать свои должностные обязанности, цели и задачи;
❒ определять решения, которые бизнес-клиенты хотят принимать с помо-
щью системы DW/BI;
❒ определять «лучших» пользователей, которые принимают эффективные решения;
найти
потенциальных новых пользователей и ознакомить их с возмож❒
ностями системы DW/BI.
Предоставлять
бизнес-клиентам высококачественную, актуальную и до■
ступную информацию и аналитику:
❒ выбирать наиболее надежные и действенные данные для представления
в системе DW/BI, тщательно отобранные из множества возможных источников данных в вашей организации;
❒ сделать пользовательские интерфейсы и приложения простыми и управляемыми паттернами, явно согласованными с профилями когнитивной
обработки пользователей;
❒ убедиться, что данные точны и им можно доверять, последовательно
маркируя их по всему предприятию;
❒ постоянно контролировать точность данных и анализа;
❒ адаптироваться к изменяющимся профилям пользователей, требованиям и бизнес-приоритетам, а также обеспечивать доступность новых
источников данных.
Поддерживать
среду DW/BI:
■
❒ использовать часть кредита для бизнес-решений, принятых с использованием системы DW/BI, и использовать эти успехи, чтобы оправдать
расходы на персонал и текущие расходы;
❒ регулярно обновлять систему DW/BI;
❒ поддерживать доверие бизнес-клиентов;
❒ удовлетворять требования бизнес-клиентов, исполнительных спонсоров и ИТ-менеджмента.
Если вы хорошо справитесь со всеми этими обязанностями, вы станете отличным менеджером DW/BI! И наоборот: просмотрите список и представьте, что
40
Глава 1
произойдет, если вы пропустите какой-либо пункт — в итоге у среды начнутся
серьезные проблемы. Теперь сопоставьте этот взгляд на работу менеджера DW/
BI с собственным описанием работы. Скорее всего, предыдущий список больше
ориентирован на пользователей и бизнес-проблемы и может даже не походить
на работу в сфере ИТ. По нашему мнению, именно это делает хранение и анализ
данных интересными.
Введение в размерное моделирование
Теперь, когда вы понимаете цели системы DW/BI, давайте рассмотрим основы
размерного моделирования. Размерное моделирование широко признано в качестве предпочтительного метода представления аналитических данных, поскольку
оно одновременно учитывает два требования:
■ предоставлять данные, понятные бизнес-клиентам;
■ обеспечивать высокую производительность выполнения запросов.
Размерное моделирование — это давно разработанный метод, упрощающий работу с базами данных. В каждом случае в течение более пяти десятилетий ИТ-организации, консультанты и бизнес-клиенты естественным образом
стремились к простой размерной структуре, чтобы соответствовать фундаментальной потребности человека в простоте. Простота имеет решающее значение,
поскольку она гарантирует, что пользователи смогут легко понять данные, а также позволяет программному обеспечению быстро и эффективно осуществлять
навигацию и возвращать результаты.
Представьте себе руководителя, который описывает свой бизнес следующим
образом: «Мы продаем продукты на различных рынках и измеряем наши результаты с течением времени». Разработчики моделей внимательно прислушиваются к акценту на продукт, рынок и время. Большинство людей интуитивно
представляют такой бизнес как куб данных, грани которого обозначены как
«Продукт», «Рынок» и «Время». Представьте себе нарезку вдоль каждого
из этих измерений. Точки внутри куба — это места, где хранятся измерения, такие как объем продаж или прибыль для этой комбинации продукта, рынка и времени. Способность визуализировать что-то настолько абстрактное, как набор
данных, конкретным и осязаемым способом — секрет понятности. Если эта перспектива кажется слишком простой, хорошо! Модель данных, которая начинается с простого, имеет шанс остаться простой в конце проекта. Модель, которая
начинается сложнее, несомненно, будет слишком сложной в конце, что приведет
к снижению производительности выполнения запросов и сокращению количества бизнес-клиентов. Альберт Эйнштейн сформировал основную философию,
Хранение данных, анализ данных и основы размерного моделирования
41
управляющую размерным дизайном, когда сказал: «Все следует упрощать до тех
пор, пока это возможно, но не более того».
Хотя размерные модели часто создаются в системах управления реляционными базами данных, они довольно сильно отличаются от моделей третьей
нормальной формы (3NF), которые стремятся устранить избыточность данных.
Нормализованные структуры 3NF делят данные на множество отдельных объектов, каждый из которых становится реляционной таблицей. База данных заказов
на продажу может начинаться с записи для каждой строки заказа, но превращаться в сложную паутину в виде модели 3NF, возможно, состоящей из сотен нормализованных таблиц.
Промышленность иногда называет 3NF-модели моделями отношения сущностей (ER). Диаграммы отношений сущностей (ER-диаграммы или ERD) — это
чертежи, которые сообщают о взаимосвязях между таблицами. И 3NF-модели,
и размерные модели могут быть представлены в виде ER-диаграмм, поскольку состоят из объединенных реляционных таблиц. Ключевое различие между
3NF-моделями и размерными моделями заключается в степени нормализации.
Поскольку оба типа моделей могут быть представлены как ERD, мы не будем называть 3NF-модели ER-моделями. Вместо этого мы называем их нормализованными моделями, чтобы минимизировать путаницу.
Нормализованные структуры 3NF чрезвычайно полезны для оперативной
обработки, поскольку транзакция обновления или вставки затрагивает базу данных только в одном месте. Нормализованные модели, однако, слишком сложны
для запросов анализа данных. Пользователи не могут понимать, перемещаться
или помнить нормализованные модели, которые напоминают карту системы
автострад Лос-Анджелеса. Аналогичным образом большинство реляционных
СУБД не могут эффективно запрашивать нормализованную модель. Сложность
непредсказуемых запросов пользователей перегружает оптимизаторы базы данных, что приводит к катастрофическим результатам.
ПРИМЕЧАНИЕ Размерная модель содержит ту же информацию, что и нор-
мализованная модель, но упаковывает данные в формате, который обеспечивает понятность для пользователя, производительность запросов и устойчивость
к изменениям.
Схема «звезда» против кубов OLAP
Размерные модели, реализованные в реляционных СУБД, называются схемами типа «звезда» из-за их сходства со звездообразной структурой. Размерные
модели, реализованные в размерных средах баз данных, называются кубами
42
Глава 1
оперативной аналитической обработки (OLAP — online analytical processing),
как показано на рис. 1-1.
Если ваша среда DW/BI включает в себя схемы типа «звезда» или кубы
OLAP, она управляет концепциями измерений. И звезды, и кубы имеют общий
логический дизайн с узнаваемыми измерениями, однако физическая реализация
отличается.
Когда данные загружаются в куб OLAP, они сохраняются и индексируются
с использованием форматов и методов, разработанных для размерных данных.
Агрегирование или предварительно рассчитанные сводные таблицы часто создаются и управляются механизмом куба OLAP. Следовательно, кубы обеспечивают
превосходную производительность запросов благодаря предварительным расчетам, стратегиям индексации и другим способам оптимизации. Бизнес-клиенты
могут производить свертку и развертку, добавляя или удаляя атрибуты из своих
анализов с превосходной производительностью, не выполняя новых запросов.
Кубы OLAP также предоставляют более аналитически устойчивые функции, которые превосходят функции, доступные в SQL. Недостатком в том, что вы платите производительностью за эти возможности, особенно с большими наборами
данных.
Измерение
«Продукт»
Измерение
«Продукт»
Да
та
Факты
продаж
Рынок
Измерение
«Рынок»
Продукт
Рис. 1-1. Схема «звезда» в сравнении с кубом OLAP
К счастью, большинство рекомендаций в этой книге не зависят от платформы
размерных реляционных баз данных. Хотя возможности технологии OLAP постоянно совершенствуются, мы обычно рекомендуем загружать подробную атомарную информацию в схему типа «звезда», дополнительные кубы OLAP затем
заполняются из схемы типа «звезда». По этой причине большинство методов
размерного моделирования в этой книге сформулированы в терминах реляционной схемы «звезда».
Хранение данных, анализ данных и основы размерного моделирования
43
Соглашение об именовании при развертке OLAP
При развертывании данных в кубах OLAP необходимо учитывать некоторые
моменты:
1. Схема типа «звезда», размещенная в реляционной базе данных, — это
хорошая физическая основа для создания куба OLAP и обычно рассматривается как более стабильная основа для резервного копирования и восстановления.
2. Кубы OLAP традиционно отличались исключительными преимуществами
в производительности по сравнению с реляционными СУБД, но это различие стало менее важным благодаря достижениям в области компьютерного оборудования, такого как устройства и базы данных в памяти, а также в области программного обеспечения реляционных СУБД, такого как
столбчатые базы данных.
3. Структуры данных куба OLAP сильнее отличаются у разных поставщиков,
чем реляционные СУБД, поэтому подробные сведения о развертывании
часто зависят от того, какой поставщик OLAP выбран. Как правило, переносить приложения BI между различными инструментами OLAP сложнее,
чем переносить приложения BI на разные реляционные базы данных.
4. Кубы OLAP обычно предлагают более сложные параметры безопасности,
чем СУБД, например ограничивают доступ к подробным данным, но предоставляют более открытый доступ к сводным данным.
5. Кубы OLAP предлагают значительно более широкие возможности анализа, чем реляционные СУБД, которые обременены ограничениями SQL.
Это может быть основным оправданием использования продукта OLAP.
6. Кубы OLAP исправно поддерживают медленно меняющиеся измерения
типа изменения 2 (которые обсуждаются в главе 5), но кубы часто необходимо обрабатывать частично или полностью с использованием альтернативных техник медленно меняющихся измерений, когда данные перезаписываются.
7. Кубы OLAP стабильно поддерживают транзакционные таблицы фактов
и таблицы фактов периодических моментальных снимков, но не обрабатывают таблицы фактов кумулятивных моментальных снимков из-за ограничений на перезапись данных, описанных в предыдущем пункте.
8. Кубы OLAP обычно поддерживают сложные рваные иерархии неопределенной глубины, такие как организационные диаграммы или ведомости
материалов, с использованием собственного синтаксиса запросов, превосходящего по функциональным возможностям подходы, применяемые
в РСУБД.
44
Глава 1
9. Кубы OLAP могут накладывать детальные ограничения на структуру ключей измерений, которые реализуют более детальные иерархии по сравнению с реляционными базами данных.
10. Некоторые продукты OLAP не поддерживают размерные роли или псевдонимы, поэтому необходимо определять отдельные физические измерения.
Мы вернемся в мир размерного моделирования на реляционной платформе,
рассматривая два ключевых компонента схемы типа «звезда».
Таблицы фактов для измерений
Таблица фактов в размерной модели хранит измерения производительности, полученные в результате событий бизнес-процессов организации. Вы должны стараться хранить данные самых детальных измерений, возникающие в результате
бизнес-процесса, в одной размерной модели. Поскольку эти данные в подавляющем большинстве — самые большие наборы данных, их не следует реплицировать в нескольких местах для нескольких организационных функций по всему
предприятию. Предоставление бизнес-клиентам из нескольких организаций доступа к единому централизованному репозиторию для каждого набора данных
измерений обеспечивает использование согласованных данных по всему предприятию.
Термин «факт» представляет собой бизнес-измерение. Представьте себе, что
вы стоите на рынке, наблюдаете, как продаются продукты, и записываете количество единиц товара и объем продаж в долларах для каждого продукта в каждой
транзакции. Эти измерения регистрируются при сканировании продуктов в регистре, как показано на рис. 1-2.
Факты розничных продаж
Преобразуется в
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Ключ промоакции (FK)
Ключ клиента (FK)
Ключ сотрудника (FK)
Номер транзакции
Продажа в долларах
Количество проданного товара
Рис. 1-2. События измерения бизнес-процессов переводятся в таблицы фактов
Хранение данных, анализ данных и основы размерного моделирования
45
Каждая строка в таблице фактов соответствует событию измерения. Данные
в каждой строке представлены на определенном уровне детализации, называемом зернистостью, например одна строка на продукт, проданный в рамках транзакции продажи. Один из основных принципов размерного моделирования —
то, что все строки измерений в таблице фактов должны быть на одном уровне
зернистости. Дисциплина при создании таблиц фактов с одним уровнем детализации гарантирует, что измерения не будут необоснованно пересчитаны дважды.
ПРИМЕЧАНИЕ Идея, что событие измерения в физическом мире имеет
связь «один к одному» с одной строкой в соответствующей таблице фактов, —
базовый принцип размерного моделирования. Все остальное строится на этом
фундаменте.
Наиболее полезные факты — числовые и аддитивные, такие как объем продаж в долларах. В этой книге мы будем использовать доллары в качестве стандартной валюты, чтобы сделать примеры более ощутимыми, но вы можете заменить их на собственную валюту.
Аддитивность имеет решающее значение, поскольку приложения по анализу
данных редко извлекают всего одну строку таблицы фактов. Чаще они возвращают сотни, тысячи или даже миллионы строк фактов за раз, и самое полезное,
что можно сделать с таким количеством строк, — это сложить их. Независимо
от того, как пользователь разрезает данные на рис. 1-2, сумма продаж и сумма
в долларах равны действительной сумме. Вы увидите, что факты иногда являются
полуаддитивными или даже неаддитивными. Полуаддитивные факты, такие как
остатки на счетах, нельзя суммировать по временному измерению. Неаддитивные факты, такие как цены за единицу, никогда не могут быть прибавлены друг
к другу. Вы вынуждены использовать подсчеты и средние значения или выводить строки фактов по одному — непрактичное упражнение с таблицей фактов
из миллиарда строк.
Факты часто описываются как таблицы, имеющие непрерывные значения,
чтобы помогать отделять факты от размерных атрибутов. Факт продажи в долларах постоянно оценивается в этом примере, потому что он может принимать
практически любое значение в широком диапазоне. Как наблюдатель, вы должны
постоять на рынке и дождаться измерения, прежде чем вы поймете, каким будет
значение.
Теоретически возможно, чтобы измеряемый факт был текстовым, однако такое условие возникает редко. В большинстве случаев текстовое измерение представляет собой описание чего-либо и составляется из дискретного списка значений. Разработчик должен приложить все усилия, чтобы поместить текстовые
46
Глава 1
данные в измерения, где они могут более эффективно соотноситься с другими атрибутами текстового измерения и занимать гораздо меньше места. Вы не должны
хранить избыточную текстовую информацию в таблицах фактов. Если текст неуникален для каждой строки таблицы фактов, он принадлежит таблице измерений. Истинный текстовый факт встречается редко, потому что непредсказуемое
содержание текстового факта, такое как текстовый комментарий произвольной
формы, делает его практически невозможным для анализа.
Пример таблицы фактов на рис. 1-2: если для какого-либо продукта нет продаж, вы не помещаете в таблицу никаких строк. Важно, чтобы вы не пытались
заполнить таблицу фактов нулями, которые не представляют никакой активности, поскольку эти нули переполняют большинство таблиц фактов. Таблицы
фактов включают только истинную активность и, как правило, довольно скудны.
Несмотря на это, таблицы фактов обычно составляют 90% или более от общего пространства, занимаемого размерной моделью. Они имеют тенденцию быть
глубокими с точки зрения количества строк, но узкими с точки зрения количества столбцов. Учитывая их размер, вы должны быть осторожны с фактическим
использованием табличного пространства.
По мере развития примеров в этой книге вы увидите, что зернистость таблицы
фактов попадает в одну из трех категорий: транзакция, периодический моментальный снимок и кумулятивный моментальный снимок. Транзакционные таблицы
фактов наиболее распространены. Мы представим транзакционные таблицы фактов
в главе 3, а также периодические и кумулятивные моментальные снимки в главе 4.
Все таблицы фактов имеют два или более внешних ключа (см. обозначение
FK на рис. 1-2), которые связывают с первичными ключами таблиц измерений.
Например, ключ «Товар» в таблице фактов всегда совпадает с конкретным ключом «Товар» в таблице измерений «Товар». Когда все ключи в таблице фактов
правильно соответствуют их первичным ключам в соответствующих таблицах измерений, таблицы удовлетворяют ссылочной целостности. Вы получаете доступ
к таблице фактов через присоединенные к ней таблицы измерений.
Таблица фактов обычно имеет собственный первичный ключ, состоящий
из подмножества внешних ключей. Этот ключ часто называют составным ключом. Каждая таблица с составным ключом — это таблица фактов. Таблицы фактов выражают отношения «многие ко многим». Все остальные таблицы — это
таблицы измерений.
Обычно существует несколько измерений, которые вместе однозначно идентифицируют каждую строку таблицы фактов. После того как это подмножество
всего списка измерений было идентифицировано, остальные измерения принимают одно значение в контексте первичного ключа строки таблицы фактов. Другими словами, они всегда работают вместе.
Хранение данных, анализ данных и основы размерного моделирования
47
Таблицы измерений для описательного контекста
Таблицы измерений — неотъемлемое дополнение таблицы фактов. Таблицы измерений содержат текстовый контекст, связанный с событием измерения бизнес-процесса. Они описывают, «кто, что, где, когда, как и почему», связанные
с событием.
Как показано на рис. 1-3, таблицы измерений часто имеют много столбцов или
атрибутов. Их нередко бывает от 50 до 100, хотя некоторые таблицы измерений,
естественно, имеют только несколько атрибутов. Таблицы измерений, как правило,
имеют меньше строк, чем таблицы фактов, но могут быть широкими, со множеством больших текстовых столбцов. Каждое измерение определяется одним первичным ключом (см. обозначение PK на рис. 1-3), он служит основой для ссылочной целостности с любой данной таблицей фактов, к которой он присоединен.
Измерение продукта
Измерение «Товар» (PK)
Артикул (Натуральный ключ)
Описание продукта
Наименование бренда
Категория
Отдел
Тип упаковки
Размер упаковки
Индикатор абразивности
Вес
Единица измерения веса
Тип хранения
Тип срока годности
Ширина полки
Высота полки
Глубина полки
…
Рис. 1-3. Таблицы измерений содержат описательные характеристики
предметов бизнес-процессов
Атрибуты измерения служат основным источником ограничений запросов,
группировок и меток отчетов. В запросе или отчете атрибуты идентифицируются как слова. Например, когда пользователь хочет видеть продажи в долларах
по бренду, бренд должен быть доступен как атрибут измерения.
Атрибуты таблицы измерений играют жизненно важную роль в системе
DW/BI. Поскольку они источник практически всех ограничений и меток отчетов, атрибуты измерения имеют решающее значение, чтобы сделать систему
DW/BI удобной и понятной. Атрибуты должны состоять из реальных слов,
48
Глава 1
а не загадочных сокращений. Вы должны стремиться свести к минимуму использование кодов в таблицах измерений, заменив их более подробными текстовыми
атрибутами. Возможно, вы уже обучили бизнес-клиентов запоминать операционные коды, но в дальнейшем минимизируйте их зависимость от стикеров, прикрепленных к их монитору для перевода кода. Необходимо сделать стандартные
декодирования для операционных кодов доступными в качестве атрибутов измерения, чтобы обеспечить согласованную маркировку запросов, отчетов и приложений BI. Декодирование никогда не следует скрывать в отчетных приложениях,
где несогласованность неизбежна.
Иногда операционные коды или идентификаторы имеют легитимную значимость для пользователей или должны возвращаться в операционный мир. В этих
случаях коды должны отображаться как явные атрибуты измерения в дополнение к соответствующим удобным для пользователя текстовым дескрипторам.
Иногда в операционные коды встроен смысл. Например, первые две цифры могут обозначать направление деятельности, тогда как следующие две цифры могут
обозначать глобальный регион. Вместо того чтобы заставлять пользователей разбирать коды на части самостоятельно, извлеките встроенные конкатенированные
значения и представьте их пользователям в виде отдельных атрибутов измерения,
которые можно легко отфильтровать, сгруппировать или составить из них отчет.
Во многих отношениях хранилища данных настолько хороши, насколько хороши атрибуты измерения, а аналитическая сила среды DW/BI прямо пропорциональна качеству и глубине атрибутов измерения. Чем больше времени уходит
на предоставление атрибутов с подробной бизнес-терминологией, тем лучше.
Чем больше времени инвестировано на определение значений домена в столбце
атрибута, тем лучше. Чем больше времени потрачено на обеспечение качества
значений в столбце атрибута, тем лучше. Надежные атрибуты измерения обеспечивают надежные аналитические возможности срезов данных.
ПРИМЕЧАНИЕ Измерения обеспечивают точки входа в данные, а также ко-
нечные метки и группировки во всех отчетах, сделанных на основе DW/BI.
При обработке данных из операционного источника иногда неясно, к чему
относится числовой элемент данных — к атрибутам факта или измерениям. Вы
часто принимаете решение, спрашивая, является ли столбец измерением, которое принимает множество значений и участвует в вычислениях (что делает его
фактом), или дискретным описанием, которое более или менее постоянное и участвует в ограничениях и метках строк (что делает его размерным атрибутом).
Например, стандартная стоимость продукта выглядит как постоянный атрибут
продукта, но может изменяться так часто, что вы решите, что это больше похоже
Хранение данных, анализ данных и основы размерного моделирования
49
на измеряемый факт. Иногда вы не можете быть уверены в классификации. Элемент данных можно смоделировать любым способом (или обоими способами);
это прерогативой разработчика.
ПРИМЕЧАНИЕ Дилемма дизайнера — считать числовое количество фактом
или атрибутом измерения — редко бывает трудным решением. Как правило,
выражаемые в значениях числовые наблюдения — почти всегда факты, а дискретные числовые наблюдения, взятые из небольшого списка, — почти всегда
атрибуты измерения.
На рис. 1-4 показано, что таблицы измерений часто представляют иерархические отношения. Например, продукты сворачиваются в бренды, а затем в категории. Для каждой строки в измерении продукта следует сохранить соответствующее описание бренда и категории. Иерархическая описательная информация
хранится в духе простоты использования и производительности запросов. Вы
должны противостоять, возможно, привычному стремлению нормализовать данные, сохраняя только код бренда в измерении продукта и создавая отдельную
таблицу бренда, а также описание категории в отдельной таблице поиска категории. Эта нормализация называется «снежинкой». Таблицы измерений обычно
не соответствуют третьей нормальной форме и вообще не приведены к нормальной форме — содержат плоские отношения «многие к одному» в одной таблице
измерений. Поскольку таблицы измерений, как правило, геометрически меньше,
чем таблицы фактов, повышение эффективности хранения за счет нормализации
или «снежинки» практически не влияет на общий размер базы данных. Почти
во всех случаях вы должны отдавать предпочтение простоте и доступности данных, а не физическим размерам таблицы.
Ключ товара Описание товара
PowerAll 20 oz
1
PowerAll 32 oz
2
PowerAll 48 oz
3
PowerAll 64 oz
4
ZipAll 20 oz
5
ZipAll 32 oz
6
ZipAll 48 oz
7
Shiny 20 oz
8
Shiny 32 oz
9
ZipGlass 20 oz
10
ZipGlass 32 oz
11
Наименование бренда Категория
Универсальное чистящее средство
PowerClean
Универсальное чистящее средство
PowerClean
Универсальное чистящее средство
PowerClean
Универсальное чистящее средство
PowerClean
Универсальное чистящее средство
Zippy
Универсальное чистящее средство
Zippy
Универсальное чистящее средство
Zippy
Очиститель для стекла
Clean Fast
Очиститель для стекла
Clean Fast
Очиститель для стекла
Zippy
Очиститель для стекла
Zippy
Рис. 1-4. Выборка строк из таблицы измерений с денормализованными
иерархиями
50
Глава 1
Вопреки популярному фольклору Ральф Кимбалл не придумал термины
«факт» и «измерение». Как мы можем определить, термины «факт» и «измерение» возникли в результате совместного исследовательского проекта, проведенного корпорацией General Mills и Дартмутским университетом в 1960-х
годах. В 1970-х годах компании AC Nielsen и IRI последовательно использовали
эти термины для описания предложений объединенных данных и обратились
к размерным моделям, чтобы упростить представления своей аналитической информации. Они поняли, что их данные не будут использоваться, если они не будут представлены просто. Вероятно, правильно сказать, что ни один человек
не изобрел размерный подход. Это непреодолимая сила в разработке баз данных,
которая всегда возникает, когда разработчик выбирает понятность и производительность в качестве высших целей.
Факты и измерения, объединенные в схему «звезда»
Теперь, когда вы понимаете таблицы фактов и измерений, пришло время объединить строительные блоки в размерную модель, как показано на рис. 1-5. Каждый
бизнес-процесс представлен размерной моделью. Она состоит из таблицы фактов, содержащей числовые измерения события. Таблицу фактов окружают лучи
таблиц измерений — в них хранится текстовый контекст, который имел место
в момент возникновения события. Эту характерную структуру часто называют
соединением «звезда», термин относится к самому раннему периоду существования реляционных баз данных.
Факты розничных продаж
Измерение «Дата»
Измерение «Магазин»
Измерение «Покупатель»
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Ключ промоакции (FK)
Ключ клиента (FK)
Ключ сотрудника (FK)
Номер транзакции
Продажа в долларах
Количество проданного товара
Измерение «Товар»
Измерение «Промоакция»
Измерение «Продавец»
Рис. 1-5. Таблицы фактов и измерений в размерной модели
Первое, что следует отметить в размерной схеме, — это ее простота и симметрия. Очевидно, что бизнес-клиенты выигрывают от простоты, потому что
в таком случае данные легче понять и перемещаться по ним. Прелесть дизайна
на рис. 1-5 в том, что бизнес-клиенты хорошо его узнают. Мы наблюдали буквально сотни случаев, когда пользователи сразу соглашались, что размерная модель
Хранение данных, анализ данных и основы размерного моделирования
51
представляет их бизнес. Кроме того, уменьшенное количество таблиц и использование значимых бизнес-дескрипторов облегчают навигацию и снижают вероятность ошибок.
Простота размерной модели также имеет преимущества в производительности.
Оптимизаторы СУБД обрабатывают эти простые схемы с меньшим количеством соединений. Механизм СУБД может делать строгие предположения, что сначала следует ограничить сильно индексированные таблицы измерений, а затем штурмовать
таблицу фактов с помощью декартового произведения ключей таблицы измерений,
удовлетворяющих ограничениям пользователя. Удивительно, но при использовании
этого подхода оптимизатор может оценивать произвольное количество n соединений с таблицей фактов за один проход через индекс таблицы фактов.
Наконец, размерные модели стабильно расширяются и приспосабливаются
к изменениям. Предсказуемая структура размерной модели выдерживает неожиданные изменения в поведении пользователя. Каждое измерение эквивалентно
другому, все измерения — это симметрично равные точки входа в таблицу фактов. У размерной модели нет встроенного смещения относительно ожидаемых
шаблонов запросов. Нет никаких предпочтений для бизнес-вопросов, заданных
в этом месяце, по сравнению с вопросами, заданными в следующем месяце. Вы,
конечно, не хотите корректировать схемы, если бизнес-клиенты предлагают новые способы анализа своего бизнеса.
Эта книга неоднократно иллюстрирует, что наиболее зернистые или атомарные данные имеют наибольшую размерность. Атомарные данные, которые
не были агрегированы, наиболее выразительны, они должны быть основой для
каждой таблицы фактов, чтобы противостоять атакам бизнес-клиентов, когда
те выполняют неожиданные запросы. С помощью размерных моделей вы можете
добавить в схему совершенно новые измерения, если для каждой существующей
строки таблиц фактов определено одно значение этого измерения. Кроме того,
вы можете добавить новые факты в таблицу фактов, предполагая, что уровень
детализации соответствует существующей таблице. Вы можете дополнить существующие размерные таблицы новыми неожиданными атрибутами. В каждом
случае существующие таблицы можно изменить на месте, просто добавив новые
строки данных в таблицу или выполнив SQL-команду ALTER TABLE. Данные
не нужно будет перезагружать, и существующие приложения BI продолжит работу, отдавая правдивые результаты. Мы исследуем эту стабильную расширяемость
размерных моделей более подробно в главе 3.
Еще один способ подумать о дополнительном характере таблиц фактов и измерений — это увидеть их переведенными в отчет. Как показано на рис. 1-6, размерные атрибуты предоставляют фильтры отчета и маркировку, тогда как таблицы фактов предоставляют числовые значения отчета.
52
Глава 1
Измерение «Товар»
Ключ товара (PK)
Артикул (Естественный ключ)
Описание продукта
Тип упаковки
Размер упаковки
Наименование бренда
Категория
… и т. п.
Факты продаж
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
…
Номер транзакции
Продажа в долларах
Продано шт.
Измерение даты
Ключ даты (PK)
Дата
День недели
Месяц
Год
…и т. п.
Фильтр
Измерение магазина
Ключ магазина (PK)
Номер магазина
Наименование магазина
Штат магазина
Почтовый индекс
Район
Регион
… и т. п.
Группировать по
Группировать по
Сумма
Продажи в июне 2013
Район
Атертон
Атертон
Белмонт
Белмонт
Наименование бренда
PowerClean
Zippy
Clean Fast
Zippy
Продажа в долларах
2035
707
2330
527
Рис. 1-6. Размерные атрибуты и факты формируют простой отчет
Вы можете легко представить SQL-код, написанный (или, скорее всего, сгенерированный инструментом BI) для создания данного отчета:
SELECT
store.district_name,
product.brand,
sum(sales_facts.sales_dollars) AS "Sales Dollars"
FROM
store,
product,
date,
sales_facts
WHERE
date.month_name="January" AND
date.year=2013 AND
Хранение данных, анализ данных и основы размерного моделирования
53
store.store_key = sales_facts.store_key AND
product.product_key = sales_facts.product_key AND
date.date_key = sales_facts.date_key
GROUP BY
store.district_name,
product.brand
Если вы изучите этот фрагмент кода построчно, то увидите, что первые две
строки в операторе SELECT идентифицируют размерные атрибуты в отчете,
а затем агрегированное изменение из таблицы фактов. Предложение FROM идентифицирует все таблицы, задействованные в запросе. Первые две строки в предложении WHERE объявляют фильтр отчета, а остальные — соединения размерных таблиц и таблиц фактов. Наконец, предложение GROUP BY устанавливает
агрегирование в отчете.
DW/BI-архитектура Кимбалла
Давайте углубим ваше понимание систем DW/BI и основ размерного моделирования, исследуя компоненты среды DW/BI, основанные на архитектуре Кимбалла. Вам необходимо изучить стратегическую значимость каждого компонента,
чтобы не путать их роль и функции.
Как показано на рис. 1-7, в среде DW/BI необходимо учитывать четыре отдельных компонента: операционные исходные системы, системы ETL, область
представления данных и приложения анализа данных.
Операционные исходные системы
Исходные системы — это операционные системы записи, которые фиксируют
транзакции бизнеса. Представляйте, что исходные системы находятся вне хранилища данных, потому что вы практически не контролируете содержимое и формат данных в этих операционных системах. Основные приоритеты исходных систем — производительность и доступность обработки. Операционные запросы
к исходным системам — это специфические запросы, обращающиеся к одной
записи за раз. Такие запросы — часть обычного потока транзакций, они строго
ограничены в своих требованиях к операционной системе.
Можно с уверенностью предположить, что исходные системы не запрашиваются для извлечения ответов на общие вопросы неожиданными способами, как
это обычно происходит с системами DW/BI. Исходные системы хранят мало
исторических данных, хорошее хранилище данных может освободить исходные
системы от большой ответственности за представление прошлого. Во многих
54
Глава 1
случаях исходные системы — это приложения специального назначения без
какого-либо обязательства обмениваться общими данными, такими как «Продукт», «Клиент», «География» или «Календарь», с другими операционными
системами в организации. Разумеется, широко распространенная система планирования ресурсов предприятия (ERP) или операционная система управления
основными данными может помочь устранить эти недостатки.
Исходные
транзакции
Открытая
комната
Скрытая
комната
ETL-система:
* Преобразование
исходных данных
в целевые
* Согласованные
измерения
* Нормализация
необязательна
* Нет поддержки
пользовательских
запросов
Цели проектирования:
* Пропускная
способность
* Целостность
и последовательность
Область представления:
* Размерная (схема
«звезда» или куб OLAP)
* Атомарные и итоговые
данные
* Организована в соответствии
с бизнес-процессами
* Использует согласованные
измерения
Цели проектирования:
* Простота в использовании
* Исполнение запросов
ВI-приложения:
* Ad hoc запросы
* Стандартные отчеты
* Аналитические
приложения
* Глубинный анализ
данных и модели
Архитектура шины DW
предприятия
Рис. 1-7. Ключевые элементы DW/BI-архитектуры Кимбалла
Система извлечения, преобразования и загрузки
Система извлечения, преобразования и загрузки (extract, transformation and
load — ETL) среды DW/BI состоит из рабочей области, созданных экземпляров
структур данных и набора процессов. Система ETL — это все, что находится между операционными исходными системами и областью представления DW/BI.
Мы подробно расскажем об архитектуре систем ETL и связанных с ней методах
в главе 19, но мы хотим представить эту фундаментальную часть общей картины
системы DW/BI.
Извлечение — это первый шаг в процессе передачи данных в среду хранилища данных. Извлечение означает чтение и понимание исходных данных и копирование данных в систему ETL для дальнейшей манипуляции. Только начиная
с этой точки данные принадлежат хранилищу данных.
После того как данные будут извлечены в систему ETL, происходит множество потенциальных преобразований, таких как очистка данных (исправление орфографических ошибок, разрешение конфликтов домена, обработка
Хранение данных, анализ данных и основы размерного моделирования
55
отсутствующих элементов или перевод в стандартные форматы), объединение
данных из нескольких источников и дедупликация данных. Система ETL повышает ценность данных с помощью очистки и согласования, изменяя данные
и улучшая их. Кроме того, эти действия могут быть спроектированы для создания диагностических метаданных, что в итоге приведет к реинжинирингу бизнес-процессов с целью повышения качества данных в исходных системах с течением времени.
Завершающий этап процесса ETL — физическое структурирование и загрузка данных в целевые размерные модели области представления. Поскольку основная задача системы ETL — передать размерные таблицы и таблицы фактов
на этапе доставки, эти подсистемы имеют решающее значение. Многие из этих
определенных подсистем сосредоточены на обработке размерных таблиц, таких
как присвоение суррогатных ключей, поиск кода для предоставления соответствующих описаний, разбиение или объединение столбцов для представления
соответствующих значений данных или объединение базовых структур таблиц
третьей нормальной формы в расширенные денормализованные измерения. Напротив, таблицы фактов обычно велики и требуют много времени для загрузки,
но подготовка их для области представления проста. Когда таблицы измерений
и таблицы фактов в размерной модели обновлены, проиндексированы, снабжены соответствующими агрегатами, а качество данных обеспечено, бизнессообщество уведомляется о том, что новые данные опубликованы.
Все еще существуют сомнения в отрасли по поводу того, следует ли преобразовывать данные в системе ETL в физические нормализованные структуры перед
загрузкой вразмерные структуры области представления для запросов и отчетов.
В системе ETL обычно преобладают простые операции сортировки и последовательной обработки. Во многих случаях система ETL не основана на реляционных
технологиях, но вместо этого может полагаться на систему плоских файлов. После проверки данных на соответствие определенным бизнес-правилам в отношении «один к одному» и «многие к одному» может оказаться бессмысленным
окончательный шаг построения физической базы данных 3NF непосредственно
перед тем, как снова преобразовать данные в денормализованные структуры для
области представления BI.
Однако в некоторых случаях данные поступают на порог системы ETL в реляционном формате 3NF. В этих ситуациях разработчикам системы ETL может
быть более удобно выполнять задачи очистки и преобразования с использованием нормализованных структур. Хотя нормализованная база данных для обработки ETL приемлема, у нас есть некоторые оговорки относительно этого
подхода. Создание как нормализованных структур для ETL, так и размерных
структур для представления означает, что данные потенциально извлекаются,
56
Глава 1
преобразуются и загружаются дважды — один раз в нормализованную базу данных, а второй — при загрузке в размерную модель. Очевидно, что этот двухэтапный процесс требует больше времени и инвестиций для разработки, больше
времени для периодической загрузки или обновления данных, а также больше
места для хранения нескольких копий данных. В итоге это, как правило, приводит к большим трудозатратам, постоянной поддержке и увеличению бюджетов
на аппаратные платформы.
К сожалению, некоторые инициативы DW/BI с треском провалились, потому
что они сосредоточили всю свою энергию и ресурсы на построении нормализованных структур, а не на выделении времени на разработку области размерного
представления, которая поддерживает улучшенное принятие бизнес-решений.
Хотя согласованность данных в масштабах всего предприятия — основная цель
среды DW/BI, возможны более эффективные и менее затратные подходы, чем
физическое создание нормализованных таблиц в системе ETL, если эти структуры еще не существуют.
ПРИМЕЧАНИЕ Допускается создание нормализованной базы данных для
поддержки процессов ETL, но это не конечная цель. Нормализованные структуры должны быть недоступны для пользовательских запросов, потому что они
не удовлетворяют целям понятности и производительности.
Область представления для поддержки анализа данных
Область представления DW/BI представляет собой место, где данные организованы, хранятся и предоставляются для прямого запроса пользователям, создателям
отчетов и другим аналитическими приложениями BI. Поскольку система ETL должна работать «за кулисами», область представления — это все, что видит и чего
касается бизнес через свои инструменты доступа к данным и через приложения
BI. Первоначальным предварительным рабочим названием для первого издания
«Инструментарий хранилища данных» было «Извлечение данных». Это то, что
представляет собой область представления с ее размерными моделями.
У нас есть несколько убеждений об области представления. Прежде всего мы
настаиваем на том, чтобы данные были представлены, сохранены и доступны
в размерных схемах, таких как схема типа «звезда» или в OLAP-кубах. К счастью, отрасль достигла такого уровня, что размерное моделирование — наиболее
жизнеспособный метод доставки данных пользователям DW/BI.
Наш второй принцип области представления: она должна содержать подробные атомарные данные. Они необходимы, чтобы быть во всеоружии при
непредсказуемых пользовательских запросах. Хотя область представления также может содержать агрегированные данные, улучшающие производительность,
Хранение данных, анализ данных и основы размерного моделирования
57
недостаточно предоставить эти итоги без базовых детализированных данных
в размерной форме. Другими словами, совершенно недопустимо хранить только
сводные данные в размерных моделях, в то время как атомарные данные заперты
в нормализованных моделях. Непрактично ожидать, что пользователь детализирует данные размерной модели почти до самого низкого уровня, а затем потеряет выгоду от размерного представления на конечном этапе. Хотя пользователи
и приложения DW/BI могут нечасто просматривать индивидуальную позицию
в заказе, они могут быть очень заинтересованы информации о заказах на прошлую
неделю на товары определенного размера (или вида, типа упаковки либо производителя) для клиентов, которые впервые приобрели что-то в рамках последних
6 месяцев (или проживают в данном районе, или имеют определенные условия
кредитования). Наиболее детализированные данные должны быть доступны в области представления, чтобы пользователи могли задавать самые точные вопросы.
Поскольку требования пользователей непредсказуемы и постоянно меняются, вы
должны предоставить доступ к мельчайшим деталям.
Область представления данных должна быть структурирована вокруг событий измерения бизнес-процессов. Этот подход естественным образом согласуется
с операционными системами сбора исходных данных. Размерные модели должны
соответствовать физическим событиям сбора данных, они не должны быть предназначены только для доставки отчета дня. Бизнес-процессы предприятия выходят
за пределы организационных отделов и функций. Другими словами, вы должны
создать единую таблицу фактов для атомарных показателей продаж, а не заполнять
отдельные похожие, но немного отличающиеся базы данных, содержащие показатели продаж для групп по продажам, маркетингу, логистике и финансам.
Все размерные структуры должны быть построены с использованием общих
согласованных таблиц измерений. Это основа архитектуры шины хранилища данных предприятия, описанной в главе 4. Строгое следование архитектуре шины —
основная опора в области презентации. Без общих согласованных измерений
размерная модель становится отдельным приложением. Изолированные наборы
данных, которые не могут быть связаны друг с другом, — это проклятие развития
DW/BI, поскольку они сохраняют несовместимые представления о предприятии.
Если у вас есть надежда на создание надежной и интегрированной среды DW/BI,
вы должны следовать архитектуре шины предприятия. Когда размерные модели
разработаны с соответствующими таблицами измерений, их легко объединить
и использовать вместе. Область представления в решении DW/BI для крупного
предприятия в итоге состоит из десятков размерных моделей со множеством связанных с ними таблиц. Эти таблицы совместно используются в таблицах фактов.
Использование архитектуры шины — секрет создания распределенных систем
DW/BI. Когда архитектура шины используется в качестве платформы, вы можете
58
Глава 1
разрабатывать корпоративное хранилище данных гибким, децентрализованным,
соответствующим требованиям, итеративным образом.
ПРИМЕЧАНИЕ Данные в запрашиваемой области представления системы
DW/BI должны быть размерными, атомарными (дополненными агрегатами,
повышающими производительность), ориентированными на бизнес-процессы.
Они также должны соответствовать архитектуре шины хранилища данных предприятия. Данные не должны быть структурированы в соответствии с интерпретацией данных отдельными отделами.
Приложения по анализу данных
Последний основной компонент DW/BI-архитектуры Кимбалла — это приложение по анализу данных. Термин «BI-приложение» (BI — Business Intelligence)
в широком смысле относится к диапазону возможностей, предоставляемых бизнес-клиентам для использования области представления при принятии аналитических решений. По определению все приложения BI запрашивают данные
в области представления DW/BI. Запросы, очевидно, — это весь смысл использования данных для улучшения принятия решений.
BI-приложение может быть простым, как инструмент для специальных запросов, или сложным, как приложение для анализа данных или моделирования.
Специальные инструменты запросов, какими бы мощными они ни были, могут
быть поняты и эффективно использованы лишь небольшим процентом потенциальных пользователей бизнес-клиентов DW/BI. Большинство бизнес-клиентов,
вероятно, получат доступ к данным через предварительно созданные приложения и шаблоны. Параметры, управляющие таким типом доступа, не требуют
от пользователя непосредственного построения запросов. Некоторые из более
сложных приложений, такие как инструменты моделирования или прогнозирования, могут загружать результаты обратно в операционные исходные системы,
ETL-систему или область представления.
Архитектура Кимбалла и метафора ресторана
Одна из наших любимых метафор подчеркивает важность разделения всей среды
DW/BI на отдельные компоненты. В этом случае мы рассмотрим сходство между
рестораном и средой DW/BI.
ETL как кухня
Система ETL аналогична кухне ресторана. Такая кухня — это отдельный мир.
Талантливые повара берут продукты и превращают их в аппетитные, вкусные
блюда для посетителей ресторана. Но задолго до того, как коммерческая кухня
Хранение данных, анализ данных и основы размерного моделирования
59
вступит в строй, немало времени уходит на разработку плана рабочего пространства и компонентов.
Кухня организована с учетом нескольких дизайнерских задач. Во-первых,
план должен быть высокоэффективным. Менеджеры ресторанов хотят высокую
пропускную способность кухни. Когда ресторан переполнен и все голодны, нет
времени для бесполезных движений. Обеспечить постоянное качество на кухне
ресторана — вторая важная цель. Заведение обречено, если блюда, приготовленные на кухне, не всегда соответствуют ожиданиям. Чтобы добиться бесперебойного качества блюд, повара создают свои особые соусы прямо на кухне,
а не отправляют ингредиенты гостю на стол, где при их смешивании неизбежно возникнут отклонения во вкусе. Наконец, продукция кухни, то есть блюда,
доставляемые посетителям ресторана, также должны быть свежими. Вы не хотели бы, чтобы кто-то получил пищевое отравление после обеда в вашем ресторане. Следовательно, кухни спроектированы с учетом этого: компоненты салата
не режут на тех же поверхностях, где обрабатывается сырая курица.
Точно так же, как качество, последовательность и целостность — главные
факторы при проектировании кухни ресторана, важно постоянно заботиться
о повседневном управлении рестораном. Повара стремятся получить лучшее
сырье. Закупленные продукты должны соответствовать стандартам качества, их
безжалостно выбрасывают, если они не соответствуют минимальным стандартам.
Большинство изысканных ресторанов меняют свое меню в зависимости от наличия качественных ингредиентов.
Кухня ресторана укомплектована профессионалами, владеющими инструментами своего ремесла. Повара манипулируют острыми как бритва ножами с невероятной уверенностью и легкостью. Они готовят на мощном оборудовании
и работают вокруг чрезвычайно горячих поверхностей без происшествий.
Учитывая опасную обстановку, кухня закрыта для посетителей. На кухне происходят вещи, которые клиенты просто не должны видеть. Это небезопасно. Профессиональные повара, работающие с острыми ножами, не должны отвлекаться на запросы посетителей. Вы также не хотели бы, чтобы посетители, входящие в кухню,
окунули пальцы в соус, чтобы убедиться, хотят ли они заказать это блюдо. Чтобы
предотвратить эти вторжения, большинство ресторанов держат закрытой дверь, которая отделяет кухню от места, где подают еду. Даже рестораны с форматом открытой
кухни обычно имеют барьер, например невысокую стену из стекла, разделяющую две
зоны. Посетителей приглашают посмотреть, но они не могут пройти на кухню. Хотя
часть кухни в таких ресторанах видна, всегда есть секретные комнаты вне поля зрения, где происходит менее визуально привлекательная часть готовки.
Система ETL хранилища данных напоминает кухню ресторана. Исходные данные волшебным образом превращаются в значимую, презентабельную
60
Глава 1
информацию. Система ETL в секретном помещении должна быть спланирована
и спроектирована задолго до извлечения каких-либо данных из источника. Как
и кухня, система ETL предназначена для обеспечения пропускной способности.
Она должна эффективно преобразовывать исходные данные в целевую модель,
сводя к минимуму ненужные перемещения.
Очевидно, что система ETL также очень обеспокоена качеством данных,
целостностью и согласованностью. Входящие данные проверяются на приемлемое качество по мере их поступления. Условия постоянно контролируются для обеспечения высокой целостности выходных данных ETL. Бизнесправила для последовательного получения метрик, добавляющих ценность,
меняются квалифицированными специалистами в системе ETL один раз,
вместо того чтобы полагаться на каждого потребителя данных при их самостоятельной разработке. Да, это создает дополнительную нагрузку на команду ETL, но это помогает предоставить более качественный и согласованный
продукт клиентам DW/BI.
ПРИМЕЧАНИЕ Правильно спроектированная среда DW/BI заменяет рабо-
ту в приложениях BI открытой комнаты в пользу работы в системе ETL скрытой
комнаты. Работа в открытой комнате должна выполняться бизнес-клиентами
снова и снова, тогда как работа в скрытой комнате выполняется сотрудниками
ETL один раз.
Наконец, система ETL должна быть закрыта для бизнес-клиентов и разработчиков приложений BI. Точно так же, как вы не хотите, чтобы посетители ресторана бродили по кухне и, возможно, потребляли полуфабрикаты, вы не хотите,
чтобы специалисты, занятые ETL, отвлекались на непредсказуемые запросы
пользователей BI. Если пользователи получают доступ к промежуточным данным, пока идет подготовка данных, то последствия могут быть весьма неприятными. Как и в случае с ресторанной кухней, в системе ETL происходят действия,
которые клиенты DW/BI не должны видеть. Когда данные готовы и качество
проверено на предмет потребления пользователем, они попадают через дверь
в область представления DW/BI.
Представление и анализ данных в открытой кухне
Теперь обратите свое внимание на обеденный зал ресторана. Каковы основные
факторы, которые их отличают? Согласно рейтингам популярных ресторанов
и отзывам посетителей, они обычно оцениваются по четырем признакам:
■ еда (качество, вкус и внешний вид);
■ декор (привлекательная, удобная обстановка для посетителей);
Хранение данных, анализ данных и основы размерного моделирования
61
■ сервис (быстрая доставка еды, внимательный обслуживающий персонал
и еда, полученная в соответствии с заказом);
■ стоимость.
Большинство постоянных посетителей сосредотачиваются на качестве еды,
когда они оценивают варианты, куда пойти на ужин, и прежде всего оценивают,
хорошую ли еду подают в ресторане? Это основной результат работы всего персонала. Тем не менее факторы декора, обслуживания и стоимости также влияют
на общий обеденный опыт и учитываются при принятии решения, посетить ли
данное заведение.
Конечно, основной результат работы кухни DW/BI — данные в области
представления. Какие данные доступны? Как и ресторан, система DW/BI предоставляет «меню» для описания того, что доступно, через метаданные, опубликованные отчеты и параметризованные аналитические приложения. Пользователи
DW/BI ожидают согласованности и высокого качества данных. Данные в области представления должны быть надлежащим образом подготовлены и безопасны для использования.
Декор зоны представления должен быть организован для удобства посетителей. Он должен быть разработан на основе предпочтений BI-посетителей,
а не персонала разработчиков. Сервис также важен в системе DW/BI. Данные
должны быть незамедлительно доставлены в соответствии с заказом в форме,
привлекательной для бизнес-клиента или разработчика BI-приложений. Наконец, стоимость — значимый фактор для системы DW/BI. Персонал кухни может
придумывать изысканные, дорогие блюда, но если в этой ценовой категории нет
спроса, ресторан не выживет.
Если посетителям ресторана нравится их обеденный опыт, то для менеджера
ресторана все радужно. Зал всегда полон, иногда даже есть лист ожидания. Все
показатели эффективности менеджера ресторана многообещающие: множество
посетителей, оборот столов, ночная выручка и прибыль при низкой текучке кадров. Все выглядит так хорошо, что владелец ресторана рассматривает расширение бизнеса для обслуживания большего числа клиентов. С другой стороны, если
посетители ресторана недовольны, выручка быстро идет вниз. С ограниченным
числом посетителей ресторан не зарабатывает достаточно, чтобы покрыть свои
расходы, и персонал не получает чаевых. В относительно короткие сроки ресторан закрывается.
Менеджеры ресторанов часто заранее проверяют удовлетворенность своих
посетителей едой и обедом. Если клиент недоволен, они предпринимают немедленные действия, чтобы исправить ситуацию. Аналогичным образом менеджеры DW/BI должны активно отслеживать удовлетворенность продуктом. Вы
62
Глава 1
не можете позволить себе ждать, чтобы услышать жалобы. Часто люди покидают
ресторан, даже не озвучивая свои проблемы. Со временем менеджеры замечают,
что количество посетителей упало, но могут даже не знать почему.
Неизбежно прежние клиенты DW/BI найдут еще один «ресторан», который
лучше соответствует их потребностям и предпочтениям, и миллионы долларов,
вложенных в проектирование, создание и обслуживание системы DW/BI, пропадут зря. Конечно, вы можете предотвратить этот печальный конец: управляя
рестораном, убедитесь, что кухня правильно организована, а еда, декор, обслуживание и стоимость на должном уровне.
Альтернативные архитектуры DW/BI
Мы описали архитектуру Кимбалла, давайте теперь обсудим несколько других
архитектурных подходов к DW/BI. Мы быстро рассмотрим две доминирующие
альтернативы архитектуре Кимбалла, подчеркнув сходства и различия. Затем мы
завершим этот раздел, сосредоточившись на гибридном подходе, сочетающем
альтернативы.
К счастью, за последние несколько десятилетий различия между архитектурой
Кимбалла и альтернативами смягчились. Еще более удачно, что всегда есть место
для размерного моделирования независимо от ваших подходов к архитектуре.
Мы признаем, что организации успешно создавали системы DW/BI на основе подходов, отстаиваемых другими. Мы твердо верим: вместо того чтобы поощрять большее беспокойство по поводу наших философских разногласий, отрасли было бы гораздо лучше направлять свою энергию на то, чтобы обеспечить
широкое принятие бизнесом наших результатов DW/BI для более эффективных
и более обоснованных решений. Архитектура должна быть лишь средством достижения этой цели.
Независимая архитектура Data Mart («Витрина данных»)
При таком подходе аналитические данные развертываются на уровне отделов,
не заботясь о совместном использовании и интеграции информации в масштабах
всего предприятия, как показано на рис. 1-8. Как правило, каждый отдел определяет требования к данным из операционной системы источника. Отдел работает
с ИТ-специалистами или внешними консультантами над созданием базы данных,
которая отвечает его потребностям, отражает его бизнес-правила и предпочтительную маркировку. Работая изолированно, эта витрина данных отвечает аналитическим требованиям отдела.
Между тем другой отдел заинтересован в том же источнике данных. Многие
отделы крайне заинтересованы в одинаковых показателях производительности,
Хранение данных, анализ данных и основы размерного моделирования
63
связанных с основными событиями бизнес-процессов организации. Но поскольку этот отдел не имеет доступа к витрине данных, изначально созданной другим отделом, он самостоятельно идет по аналогичному пути, получая ресурсы
и создавая решение, которое содержит аналогичные, но немного отличающиеся
данные. Когда бизнес-клиенты из этих двух отделов обсуждают эффективность
организации на основе отчетов из своих соответствующих репозиториев, неудивительно, что ни один из результатов не совпадает из-за различий в бизнесправилах и маркировке.
Исходные
транзакции
Открытая
комната
Скрытая
комната
ETL
Витрина данных
для отдела № 1
ВI-приложения
для отдела № 1
Витрина данных
для отдела № 2
ВI-приложения
для отдела № 2
Витрина данных
для отдела № 3
ВI-приложения
для отдела № 3
ETL
ETL
ETL
ETL
Рис. 1-8. Упрощенная иллюстрация независимой архитектуры витрины данных
Эти автономные аналитические хранилища представляют собой архитектуру
DW/BI, которая, по сути, не спроектирована. Хотя ни один из лидеров отрасли не поддерживает такие независимые витрины данных, этот подход широко
распространен, особенно в крупных организациях. Он отражает то, как многие
организации финансируют ИТ-проекты, а также требует нулевого межорганизационного управления данными и их координации. Это путь наименьшего сопротивления для быстрого развития при относительно низких затратах, по крайней
мере в краткосрочной перспективе. Разумеется, многочисленные несогласованные извлечения данных из одних и тех же операционных источников и избыточное хранение аналитических данных в долгосрочной перспективе неэффективны
и расточительны. Без какой-либо точки зрения на уровне предприятия этот независимый подход приводит к множеству автономных точечных решений, которые
увековечивают несовместимые представления о работе организации, что приводит к ненужным организационным дебатам и согласованию данных.
64
Глава 1
Мы настоятельно не рекомендуем подход независимых витрин данных. Тем
не менее часто эти независимые витрины данных включали размерное моделирование, потому что они заинтересованы в предоставлении данных, которые бизнесу легко понять и которые быстро отвечают на запросы. Таким образом, наши
концепции размерного моделирования часто применяются в этой архитектуре,
несмотря на полное игнорирование некоторых основных принципов, таких как
сосредоточение внимания на хранении атомарных данных, построение на основе
бизнес-процессов вместо отделов и использование согласованных измерений для
согласованности и интеграции на уровне предприятия.
Веерная архитектура корпоративной информационной
фабрики Инмона
Подход веерной фабрики корпоративной информационной (CIF — Corporate
Information Factory) отстаивается Биллом Инмоном и другими участниками отрасли. Рис. 1-9 иллюстрирует упрощенную версию CIF, фокусируясь на основных элементах и концепциях, которые требуют обсуждения.
Исходные
транзакции
Скрытая комната
Открытая
комната
П
о
л
у
ч
е
н
и
е
д
а
н
н
ы
х
Хранилище данных
предприятия (EDW)
* Нормализованные
таблицы (3NF)
* Атомарные данные
* Доступно
для пользовательских
запросов
Д
о
с
т
а
в
к
а
д
а
н
н
ы
х
Витрины данных:
* Размерные
* Часто
суммируемые
* Зачастую
принадлежат
отделам
B
I
п
р
и
л
о
ж
е
н
и
я
Рис. 1-9. Упрощенная иллюстрация архитектуры веерной корпоративной
информационной фабрики
С помощью CIF данные извлекаются из исходных операционных систем
и обрабатываются через систему ETL, иногда называемую сбором данных. Атомарные данные, полученные в результате этой обработки, попадают в базу данных в третьей нормальной форме (3NF). Этот нормализованный атомарный
Хранение данных, анализ данных и основы размерного моделирования
65
репозиторий в архитектуре CIF называется корпоративным хранилищем данных
(Enterprise Data Warehouse, EDW). Хотя архитектура Кимбалла предполагает необязательную нормализацию для поддержки обработки ETL, нормализованное
хранилище EDW — обязательная конструкция в CIF. Как и подход Кимбалла,
CIF поддерживает координацию и интеграцию корпоративных данных. CIF
утверждает, что нормализованная EDW выполняет эту роль, в то время как архитектура Кимбалла подчеркивает важность шины предприятия с согласованными
измерениями.
ПРИМЕЧАНИЕ Процесс нормализации технически не говорит об интегра-
ции. Нормализация просто создает физические таблицы, которые реализуют
отношения «многие к одному». Интеграция, с другой стороны, требует устранения несоответствий, возникающих из отдельных источников. Отдельные несовместимые базы данных источников могут быть нормализованы до уровня
готовности без учета интеграции. Архитектура Кимбалла, основанная на согласованных измерениях, переворачивает эту логику и фокусируется на устранении
несоответствий данных без явной необходимости нормализации.
Организации, которые приняли подход CIF, часто предоставляют для бизнес-клиентов доступ непосредственно к хранилищу EDW, так как оно предоставляет данные высокого уровня детализации или своевременно доступные
данные. Однако последующие процессы доставки данных ETL также заполняют
нижестоящие среды отчетности и аналитики для поддержки бизнес-клиентов.
Хотя они часто имеют размерную структуру, результирующие аналитические
базы данных обычно отличаются от структур в области представления архитектуры Кимбалла тем, что они часто ориентированы на департаменты, а не организованы вокруг бизнес-процессов, и заполнены агрегированными данными
вместо атомарных деталей. Если процессы ETL доставки данных применяют
бизнес-правила, выходящие за рамки базового суммирования, такие как переименование столбцов в подразделениях или альтернативные вычисления, может быть сложно связать эти аналитические базы данных с атомарным хранилищем EDW.
ПРИМЕЧАНИЕ По нашему мнению, наиболее экстремальная форма архи-
тектуры с чистой CIF-архитектурой не работает как хранилище данных. Такая
архитектура блокирует элементарные данные в нормализованных структурах,
которые трудно запрашивать, и в то же время доставляет несовместимые витрины данных различным группам бизнес-клиентов. Но, прежде чем разочароваться в таком подходе, прочтите следующий раздел.
66
Глава 1
Гибридная веерная и кимбалловская архитектура
Окончательная архитектура, требующая обсуждения, — это объединение архитектур Кимбалла и CIF Инмона. Как показано на рис. 1-10, эта архитектура заполняет CIF-ориентированное EDW-хранилище, к которому полностью закрыт
доступа бизнес-клиентам для анализа и составления отчетов. Это всего лишь источник для заполнения области представления в кимбалловском стиле, данные
здесь размерные, атомарные (дополнены агрегатами), ориентированы на процессы и соответствуют архитектуре шины хранилища данных предприятия.
Некоторые сторонники этого смешанного подхода утверждают, что это
лучшее из обоих миров. Да, он сочетает в себе два подхода, ориентированных
на предприятия. Он может использовать уже существующие инвестиции в интегрированный репозиторий, одновременно решая проблемы производительности и удобства использования с помощью 3NF EDW-хранилищ путем выгрузки
запросов в область представления измерений. И поскольку конечный результат
для бизнес-клиентов и бизнес-приложений построен на основе принципов Кимбалла, кто может поспорить с этим подходом?
Открытая
комната
Скрытая
комната
Исходные
транзакции
ETL
Хранилище данных
предприятия (EDW)
* Нормализованные
таблицы (3NF)
* Атомарные данные
ETL
Область представления:
* Размерная (схема
«звезда» или куб OLAP)
* Атомарные и итоговые
данные
* Организована
бизнес-процессами
* Использует
согласованные
измерения
B
I
п
р
и
л
о
ж
е
н
и
я
Архитектура шины DW
предприятия
Рис. 1-10. Гибридная архитектура с 3NF-структурами и размерной области
представления Кимбалла
Если вы уже вложили средства в создание 3NF EDW-хранилища, но оно
не оправдывает ожиданий пользователей в отношении быстрой и гибкой отчетности и анализа, этот гибридный подход может подойти для вашей организации. Если вы начинаете с чистого листа, то на гибридный подход, вероятно, будет
потрачено больше времени и денег как во время разработки, так и в процессе
Хранение данных, анализ данных и основы размерного моделирования
67
эксплуатации, учитывая многочисленные перемещения данных и избыточное хранение атомарных деталей. Если у вас есть желание, осознанная потребность и, главное,
бюджет и организационное терпение, чтобы полностью нормализовать и создать
копию ваших данных, прежде чем загружать их в размерные структуры, которые хорошо спроектированы в соответствии с методами Кимбалла, сделайте это.
Мифы о размерном моделировании
Несмотря на широкое признание размерного моделирования, в отрасли сохраняются некоторые заблуждения. Эти ложные утверждения отвлекают, особенно когда
вы хотите привести свою команду в соответствие с общими передовыми методами.
Если люди в вашей организации постоянно критикуют размерное моделирование,
этот раздел должен быть в их списке рекомендуемого к прочтению, поскольку их
восприятие может быть омрачено этими распространенными заблуждениями.
Миф 1: размерные модели только для сводных данных
Этот первый миф — частая основная причина плохо разработанных размерных
моделей. Поскольку вы не можете предсказать все вопросы, задаваемые бизнесклиентами, вам необходимо предоставить им запрашиваемый доступ к самым
подробным данным, чтобы клиенты сами могли их развернуть в зависимости
от бизнес-вопроса. Данные с самым низким уровнем детализации практически
не подвержены неожиданностям или изменениям. Сводные данные должны дополнять детали исключительно для обеспечения повышенной производительности общих запросов, но не заменять детали.
Следствие этого первого мифа — еще один миф, утверждающий, что только
ограниченное количество исторических данных должно храниться в размерных
структурах. Ничто в размерной модели не запрещает хранить существенный
объем исторических данных. Объем истории, доступной в размерных моделях,
должен зависеть только от требований бизнеса.
Миф 2: размерные модели для отделов,
а не для предприятий в целом
Вместо того чтобы рисовать границы данных на основе организационных отделов, размерные модели должны быть организованы вокруг бизнес-процессов,
таких как заказы, счета-фактуры и сервисные вызовы. Многочисленные бизнесфункции часто нацелены на анализ одних и тех же показателей, полученных в результате одного бизнес-процесса. Следует избегать многократного извлечения
одних и тех же исходных данных, которые создают несколько несовместимых
аналитических баз данных.
68
Глава 1
Миф 3: размерные модели не масштабируемы
Размерные модели чрезвычайно масштабируемы. Таблицы фактов часто имеют миллиарды строк; мы встречали таблицы фактов, содержащие 2 триллиона
строк. Разработчики баз данных искренне поддерживают DW/BI и продолжают
включать в свои продукты возможности для оптимизации масштабируемости
и производительности размерных моделей. Как нормализованные, так и размерные модели содержат одинаковую информацию и взаимосвязи данных, логическое содержание идентично. Каждое отношение между данными, выраженное
в одной модели, может быть точно выражено в другой. Как нормализованные,
так и размерные модели могут отвечать на одни и те же вопросы, хотя и с различной сложностью.
Миф 4: размерные модели только для заранее
определенного использования
Размерные модели не следует разрабатывать, ориентируясь на заранее подготовленные отчеты или вопросы. Проектирование должно быть основано на процессах измерения. Очевидно, что важно учитывать требования к фильтрации и маркировке приложения BI. Но вам не стоит выполнять проектирование просто
для оформления красивых отчетов. Список параметров для этих отчетов будет
постоянно меняться, и размерная модель превратится в подвижную мишень.
Следствие этого мифа — еще один миф, состоящий в том, что размерные модели не реагируют на изменение потребностей бизнеса. Напротив, благодаря своей
симметрии размерные структуры чрезвычайно гибки и адаптируются к изменениям. Секрет гибкости заключается в создании таблиц фактов на самом детальном
уровне. Размерные модели, которые предоставляют только сводные данные, обязательно будут проблемными, и пользователи столкнутся с преградами в аналитике, когда попытаются детализировать данные, которых нет в сводных таблицах.
Разработчики также сталкиваются с преградами, потому что они не могут легко
приспособить новые измерения, атрибуты или факты к этим преждевременно
суммированным таблицам. Правильная отправная точка для ваших размерных
моделей состоит в том, чтобы выражать данные с наименьшей возможной детализацией для максимальной гибкости и расширяемости. Помните: когда вы заранее
предполагаете бизнес-вопрос, вы, скорее всего, предварительно суммируете данные, что в итоге может оказаться фатальными. Как говорит архитектор Мис ван
дер Роэ, «дьявол кроется в мелочах». Создание размерных моделей, заполненных
максимально подробными данными, обеспечивает максимальную гибкость и расширяемость. Предоставление чего-либо меньшего в ваших размерных моделях
подрывает основу, необходимую для надежной бизнес-аналитики.
Хранение данных, анализ данных и основы размерного моделирования
69
Миф 5: размерные модели не интегрируемы
Размерные модели, безусловно, могут быть интегрированы, если они соответствуют архитектуре шины хранилища данных предприятия. Соответствующие
измерения создаются и поддерживаются в виде централизованных, постоянных
основных данных в системе ETL, а затем повторно используются в размерных моделях, чтобы обеспечить интеграцию данных и семантическую согласованность.
Интеграция данных зависит от стандартизированных меток, значений и определений. Трудно достичь организационного консенсуса и затем внедрить соответствующие правила ETL, но у вас не будет легкого пути независимо от того, какие
модели вы используете — нормализованные или размерные.
Базы данных области представления, которые не придерживаются архитектуры шины с общими согласованными размерами, приводят к автономным решениям. Вы не можете считать размерное моделирование ответственным за неспособность организаций принять один из его фундаментальных принципов.
Еще больше причин мыслить многомерно
Большая часть этой книги посвящена размерному моделированию для проектирования баз данных в области представления DW/BI. Но концепции размерного
моделирования выходят за рамки проектирования простых и быстрых структур
данных. Вы должны мыслить измерениями на других критических этапах проекта DW/BI.
При сборе требований для инициативы DW/BI необходимо выслушать результаты, касающиеся бизнес-процессов, а затем обобщить их. Иногда командам
хочется сосредоточиться на наборе требуемых отчетов или индикаторов сводных
панелей мониторинга. Вместо этого вам следует постоянно спрашивать себя о событиях измерения бизнес-процессов, производящих отчет или метрики панели
мониторинга. При определении области действия проекта вы должны сосредоточиться на одном бизнес-процессе на проект, а не стремиться развернуть панель
мониторинга, которая охватывает несколько процессов за одну итерацию.
Хотя и крайне важно, чтобы команда DW/BI концентрировалась на бизнеспроцессах, не менее важно обеспечить управление ИТ и бизнесом на одной волне. В связи с исторической политикой финансирования ИТ бизнес может быть
лучше знаком с развертыванием данных в отделах. Вам необходимо изменить
свое мнение о развертывании DW/BI на перспективу процессов. При определении приоритетов возможностей и во время разработки дорожной карты DW/
BI бизнес-процессы — это единица работы. К счастью, бизнес-менеджмент
обычно использует этот подход, потому что он отражает их взгляды на ключевые
70
Глава 1
показатели эффективности. Кроме того, они были вынуждены мириться с несогласованностями и непрекращающимися дебатами, вызванными подходом
деления на отделы, поэтому они готовы к новой тактике. Работая с партнерамируководителями, оцените каждый бизнес-процесс с точки зрения прибыльности
и осуществимости, а затем приступайте к процессам с наивысшим результатом
и выполнимостью. Хотя расстановка приоритетов — это совместная с бизнесом
деятельность, ваше базовое понимание бизнес-процессов организации имеет
важное значение для ее эффективности и последующей деятельности.
Если вам поручено разрабатывать архитектуру данных системы DW/BI, вам
необходимо понять бизнес-процессы организации вместе со связанными основными данными. Основной результат для этого действия, то есть матрица шины
хранилища данных предприятия, будет полностью изучен в главе 4. Матрица также служит полезным инструментом для демонстрации потенциальных преимуществ более строгой платформы управления основными данными.
Программы обслуживания и управления данными должны в первую очередь
сосредоточиться на основных субъектах. В зависимости от отрасли список может
содержать дату, клиента, продукт, сотрудника, учреждение, поставщика, студента, преподавателя, учетную запись и т. д. Размышление о центральных субъектах,
используемых для описания бизнеса, может быть использовано для разработки
плана по управлению данными. Этот план должны возглавлять отраслевые эксперты из бизнес-сообщества. Установление обязанностей по управлению данными для этих субъектов — ключ к окончательному развертыванию измерений,
обеспечивающих согласованность и удовлетворяющих потребности бизнеса
в аналитической фильтрации, группировке и маркировке. Надежные измерения
превращаются в надежные системы DW/BI.
Как видите, фундаментальная мотивация для размерного моделирования
закладывается задолго до разработки схем типа «звезда» или OLAP-кубов.
Аналогичным образом размерная модель будет оставаться в фокусе внимания
во время последующей разработки системы ETL и приложений BI. Концепции
размерного моделирования связывают деловые и технические сообщества, когда они совместно разрабатывают конечные результаты DW/BI. Мы подробно
остановимся на этих идеях в главах 17 и 18, но нам хотелось высадить эти семена
понятий раньше, чтобы у них было время прорасти.
Соглашения Agile
В настоящее время в отрасли DW/BI наблюдается значительный интерес к гибкой методологии разработки Agile. Рискуя слишком упростить, можно сказать,
что вместо того, чтобы начинать гораздо более масштабный (и, следовательно,
Хранение данных, анализ данных и основы размерного моделирования
71
более рискованный) проект с результатами, ожидаемым через месяцы или годы,
методологии гибкой разработки сосредоточены на выполнении работ в разумных объемах, которые можно завершить в приемлемые сроки, измеряемые неделями. Звучит хорошо, не правда ли?
Многие из основных принципов гибких методологий согласуются с лучшими
практиками Кимбалла, включая следующие:
1. Сосредоточиться на обеспечении ценности предоставляемых данных. Это
была мантра Кимбалла на протяжении десятилетий.
2. Ценить сотрудничество между командой разработчиков и заинтересованными сторонами. Как и сторонники Agile, мы настоятельно рекомендуем
тесное сотрудничество с бизнесом.
3. Подчеркивать важность постоянного личного общения, обратную связь
и расстановку приоритетов с заинтересованными сторонами.
4. Быстро адаптироваться к неизбежно меняющимися требованиям.
5. Заниматься разработкой итеративно, поэтапно.
Хотя этот список убедителен, нередко этот подход критикуют, обвиняя в отсутствии планирования и архитектуры в сочетании с текущими проблемами
управления. Матрица шины хранилища данных предприятия — мощным инструментом для устранения этих недостатков. Матрица шины обеспечивает основу и генеральный план для гибкой разработки, а также определяет повторно
используемые общие описательные измерения, которые обеспечивают согласованность данных и сокращают время выхода на рынок. При правильном взаимодействии заинтересованных сторон бизнеса и ИТ матрицу шины хранилища
данных предприятия можно создать в относительно короткие сроки. Инкрементная разработка может создавать компоненты фреймворка до тех пор, пока
не будет доступна достаточная функциональность, а затем предоставлена бизнессообществу.
Некоторые клиенты и студенты жалуются, что, хотя они хотят предоставлять
последовательно определенные согласованные измерения в своих средах DW/BI,
это «просто невозможно». Они объясняют, что они сделали бы, если бы могли,
но с акцентом на технологии гибкой разработки «невозможно» потратить время на то, чтобы получить организационное соглашение на соответствие измерениям. Мы же утверждаем, что согласованные измерения обеспечивают гибкую
разработку DW/BI наряду с гибким принятием решений. По мере того как вы
расширяете портфолио согласованными измерениями, разработка начинает менять направление все быстрее и быстрее. Время выхода на рынок нового источника данных бизнес-процессов сокращается, поскольку разработчики повторно
72
Глава 1
используют существующие согласованные измерения. В конечном счете новая
разработка ETL фокусируется почти исключительно на предоставлении большего количества таблиц фактов, поскольку соответствующие размерные таблицы
уже находятся на полке, готовые к работе.
Без такой структуры, как матрица шины хранилища данных предприятия,
некоторые команды DW/BI оказались в ловушке использования гибких методов для создания аналитических или отчетных решений. В большинстве случаев
команда работала с небольшим набором пользователей, чтобы извлечь ограниченный набор исходных данных и сделать их доступными для решения уникальных проблем. В результате часто появляется отдельное хранилище данных, которое другие не могут использовать, или, что еще хуже, которое предоставляет
данные, не связанные с другой аналитической информацией организации. Мы
поощряем гибкость, когда это уместно, однако следует избегать создания изолированных наборов данных. Как и в большинстве случаев, умеренность и баланс
между крайностями почти всегда имеют смысл.
Выводы
В этой главе мы обсудили основные задачи систем DW/BI и основные концепции размерного моделирования. Мы сравнили архитектуру DW/BI Кимбалла
и несколько альтернатив. Мы закончили главу, выявив основные заблуждения, которые до сих пор сохраняются в отношении размерного моделирования, несмотря на его широкое признание в отрасли, и предложили вам мыслить не только
в области моделирования данных. В следующей главе вы быстро познакомитесь
с моделями и методами размерного моделирования, а затем начнете воплощать
эти концепции в жизнь в своем первом примере из главы 3.
2
Обзор методов
размерного
моделирования
Кимбалла
Е
ще в первом издании книги «Инструментарий хранилища данных» (Wiley,
1996) Kimball Group определила полный набор методов размерного моделирования данных. В первых двух изданиях этой книги мы чувствовали, что методы, которые необходимо объяснить, должны быть представлены через знакомые
примеры использования, взятые из различных отраслей. Хотя мы по-прежнему
считаем, что бизнес-кейсы — важный педагогический подход, методы стали настолько стандартизированными, что некоторые разработчики размерных моделей меняют логику на обратную: начинают с методики, а затем переходят к примерам использования для определения контекста. Все это хорошие новости!
Методы Кимбалла признаны лучшими в отрасли. В качестве доказательства
некоторые бывшие студенты Университета Кимбалла опубликовали собственные книги по размерному моделированию. Эти книги обычно точно объясняют
техники Кимбалла, но то, что эти издания не расширили существенно библиотеку техник и не предложили противоречивых рекомендаций, свидетельствует
об устойчивости наших методов.
Эта глава представляет собой официальный список методов размерного моделирования Кимбалла от изобретателей этих паттернов проектирования. Мы
не ожидаем, что вы прочитаете эту главу от начала до конца, но мы хотим, чтобы
эта глава была справочником по нашим методам. Для каждого метода мы включили указатели на последующие главы, где они объяснены, и иллюстрации мотивирующих вариантов использования.
Основные концепции
При любом размерном моделировании необходимо учитывать методы, описанные в этом разделе. Почти каждая глава в книге ссылается или иллюстрирует
концепции этого раздела.
74
Глава 2
Соберите бизнес-требования и реалии данных
Прежде чем приступить к пространственному моделированию, команде необходимо понять потребности бизнеса, а также реалии базовых исходных данных.
Вы раскрываете требования в ходе сессий с представителями бизнеса, чтобы
понять их цели на основе ключевых показателей эффективности, актуальных
бизнес-проблем, процессов принятия решений и вспомогательных аналитических потребностей. В то же время реальность данных раскрывается на встречах
с экспертами по исходным системам и при выполнении высокоуровневого профилирования данных. Такое профилирование позволяет оценить возможности
использования этих данных.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Глава 17. Обзор жизненного цикла Кимбалла, с. 493
Глава 18. Процессы и задачи размерного моделирования, с. 523
Глава 19. Подсистемы и методы ETL, с. 539
Совместные рабочие сессии по пространственному
моделированию
Пространственные модели следует разрабатывать в сотрудничестве с профильными экспертами и представителями бизнеса. Проектировщик модели данных — главный специалист проекта (или руководитель), но модель должна
создаваться через серию интерактивных интервью с представителями бизнеса.
Эти рабочие сессии — еще одна возможность уточнить бизнес-требования.
Размерные модели не должны разрабатываться изолированно людьми, которые не полностью понимают бизнес и его потребности; сотрудничество имеет
решающее значение!
Глава 3. Розничные продажи, с. 115
Глава 4. Склад, с. 163
Глава 18. Процессы и задачи размерного моделирования, с. 523
Обзор методов размерного моделирования Кимбалла
75
Четырехэтапный процесс размерного проектирования
Четыре ключевых решения, принимаемых при проектировании размерной модели, включают такие:
1. Выберите бизнес-процесс.
2. Объявите зернистость.
3. Определите измерения.
4. Определите факты.
Чтобы ответить на эти вопросы, нужно рассмотреть потребности бизнеса наряду с реалиями основных исходных данных во время рабочих сессий совместного моделирования. Следуя объявленным бизнес-процессам, зернистости, измерениям и фактам, группа разработчиков определяет имена таблиц и столбцов,
примеры значений домена и бизнес-правила. Представители управления бизнесданными должны участвовать в этой деятельности по детальному проектированию, чтобы обеспечить заинтересованность бизнеса.
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Глава 18. Процессы и задачи размерного моделирования, с. 523
Бизнес-процессы
Бизнес-процессы — это операционные действия, выполняемые вашей организацией, такие как принятие заказа, обработка страхового возмещения, регистрация
студентов для занятий или создание резервной копии всех учетных записей каждый месяц. События бизнес-процессов генерируют или фиксируют показатели
производительности, которые преобразуются в факты в таблице фактов. Большинство таблиц фактов сосредоточены на результатах одного бизнес-процесса.
Выбор процесса важен, потому что он определяет конкретную цель проекта и позволяет декларировать зернистость, измерения и факты. Каждый бизнес-процесс
соответствует строке в матрице шины корпоративного хранилища данных.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
76
Глава 2
Глава 17. Обзор жизненного цикла Кимбалла, с. 493
Глава 18. Процессы и задачи размерного моделирования, с. 523
Зернистость
Объявление зернистости — ключевой шаг в размерном проектировании. Зернистость точно определяет, что представляет собой одна строка таблицы фактов. Объявление зернистости — обязательная часть договора о дизайне. Перед
выбором измерений или фактов необходимо объявить зернистость, потому
что каждое возможное измерение или факт должны согласовываться с этим
параметром. Эта согласованность обеспечивает единообразие всех размерных
моделей, что имеет решающее значение для производительности и простоты
использования приложения бизнес-аналитики. Атомарная зернистость относится к самому низкому уровню, на котором данные собираются конкретным
бизнес-процессом. Мы настоятельно рекомендуем вам начать с сосредоточения
на атомарных данных, потому что они выдерживают атаку непредсказуемых
пользовательских запросов; сводные данные важны для увеличения производительности, но они предполагают общие вопросы бизнеса. Каждая предлагаемая зернистость таблицы фактов приводит к (физическому) созданию отдельной таблицы; разные зернистости не должны смешиваться в одной таблице
фактов.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 4. Склад, с. 163
Глава 6. Управление заказами, с. 225
Глава 11. Телекоммуникации, с. 371
Глава 12. Транспортировка, с. 389
Глава 18. Процессы и задачи размерного моделирования, с. 523
Измерения для описательного контекста
Измерения обеспечивают контекст «кто, что, где, когда, почему и как», окружающий событие бизнес-процесса. Таблицы измерений содержат описательные атрибуты, используемые приложениями бизнес-аналитики для фильтрации
Обзор методов размерного моделирования Кимбалла
77
и группировки фактов. Твердо помня зернистость таблицы фактов, можно идентифицировать все возможные измерения. По возможности измерение должно
быть однозначным, если оно связано с данной строкой фактов.
Таблицы измерений иногда называют «душой» хранилища данных, потому
что они содержат точки входа и описательные метки, которые позволяют использовать систему DW/BI для анализа бизнеса. Много усилий прилагается к управлению данными и разработке таблиц измерений, поскольку это движущие силы
пользовательского опыта бизнес-аналитики.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Глава 18. Процессы и задачи размерного моделирования, с. 523
Глава 19. Подсистемы и методы ETL, с. 539
Факты для измерений
Факты — это показатели, результат события бизнес-процесса. Почти всегда они
числовые. Одна строка таблицы фактов имеет однозначное отношение к событию измерения, как описано в зернистости таблицы фактов. Таким образом, таблица фактов соответствует физически наблюдаемому событию, а не требованиям
конкретного отчета. В таблице фактов допускаются только факты, соответствующие заявленной зернистости. Например, в розничных продажах количество проданного продукта и его расширенная цена — достоверные факты, в то время как
зарплата менеджера магазина не указывается.
Она для этой сделки розничных продаж просто не нужна.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 4. Склад, с. 163
Глава 18. Процессы и задачи размерного моделирования, с. 523
78
Глава 2
Схема «звезда» и кубы OLAP
Звездообразные схемы — это размерные структуры, реализуемые в системе управления реляционными базами данных (СУБД). Как правило, они состоят из таблиц фактов, имеющих отношение со связанными таблицами измерений при помощи отношения первичный/внешний ключ. Куб интерактивной аналитической
обработки (OLAP — online analytical processing) представляет собой размерную
структуру, реализованную в размерной базе данных; он может быть эквивалентен
по содержанию звездной схеме или быть производным реляционной схемы (более частый вариант). Куб OLAP содержит размерные атрибуты и факты, но доступ
к нему осуществляется через языки с более широкими аналитическими возможностями, чем SQL, например XMLA и MDX. Кубы OLAP включены в список
основных методов, потому что это частый заключительный шаг в развертывании
размерной системы DW/BI. Куб может существовать как агрегированная структура, основанная на более атомарной реляционной звездообразной схеме.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 5. Закупки, с. 197
Глава 6. Управление заказами, с. 225
Глава 7. Бухгалтерский учет, с. 263
Глава 9. Управление персоналом, с. 333
Глава 13. Образование, с. 405
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Стабильные расширения размерных моделей
Размерные модели устойчивы при изменении отношений данных. Все следующие изменения могут быть реализованы без изменения существующего запроса
или приложения бизнес-аналитики, а также без изменения результатов запроса.
1. Факты, соответствующие зернистости существующей таблицы фактов, могут быть добавлены путем создания новых столбцов.
2. Измерения могут быть добавлены к существующей таблице фактов путем
создания новых столбцов внешнего ключа. Предполагается, что они не изменят зернистость таблицы фактов.
Обзор методов размерного моделирования Кимбалла
79
3. Атрибуты могут быть добавлены в существующую таблицу измерений путем создания новых столбцов.
4. Зернистость таблицы фактов можно сделать более атомарной, добавив атрибуты в существующую таблицу измерений, а затем заново пересчитав
таблицу фактов на уровне зернистости, стараясь сохранить имена существующих столбцов в таблицах фактов и измерений.
Глава 3. Розничные продажи, с. 115
Основные методы работы с таблицами фактов
Методы, описанные в этом разделе, применимы ко всем таблицам фактов. Почти
в каждой главе есть иллюстрации таблиц фактов.
Структура таблиц фактов
Таблица фактов содержит числовые показатели, полученные в результате оперативного измерения в реальном мире. На самом низком уровне строка таблицы
фактов соответствует событию измерения и наоборот. Таким образом, фундаментальный дизайн таблицы фактов полностью основан на физической активности
и не зависит от любых отчетов, которые могут быть созданы. В дополнение к числовому показателю таблица фактов всегда содержит внешние ключи для каждого
из связанных с ним измерения, а также необязательные ключи вырожденных измерений и метки даты/времени. Таблицы фактов — основная цель вычислений
и динамических агрегаций, возникающих в результате запросов.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 5. Закупки, с. 197
Глава 6. Управление заказами, с. 225
Аддитивные, полуаддитивные и неаддитивные факты
Числовая мера в таблице фактов подразделяется на три категории. Наиболее
гибкие и полезные факты полностью аддитивные; аддитивные показатели могут быть суммированы по любому из измерений, связанных с таблицей фактов.
80
Глава 2
Полуаддитивные метрики могут быть суммированы по некоторым измерениям,
но не всем; так, балансовые суммы — распространенные полуаддитивными факты,
поскольку их можно суммировать по всем измерениям, кроме времени. Наконец,
некоторые показатели полностью неаддитивны, например коэффициенты. Хороший подход для неаддитивных фактов — по возможности хранить полностью аддитивные компоненты неаддитивных показателей и суммировать эти компоненты
в окончательный ответ, установленный до расчета окончательного неаддитивного
факта. Этот окончательный расчет часто делается в слое BI или OLAP-кубе.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 4. Склад, с. 163
Глава 7. Бухгалтерский учет, с. 263
Пустые значения (Null) в таблицах фактов
Отсутствующие результаты измерений ведут себя штатно в таблицах фактов.
Функции агрегирования (SUM, COUNT, MIN, MAX и AVG) корректно обрабатывают пустые факты. Тем не менее во внешних ключах таблицы факта следует
избегать пустых значений, поскольку эти значения автоматически приводят к нарушению референтной целостности. Вместо пустого внешнего ключа связанная
таблица измерений должна иметь строку по умолчанию (и суррогатный ключ),
представляющую неизвестное или неприменимое условие.
Глава 3. Розничные продажи, с. 115
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Согласованные факты
Если один и тот же показатель существует в отдельных таблицах фактов, необходимо позаботиться, чтобы технические определения фактов совпадали, если они
будут сравниваться или вычисляться совместно. Если определения отдельных
фактов согласованы, согласованные факты должны иметь идентичные названия;
но если они несовместимы, их следует назвать по-разному, чтобы предупредить
пользователей приложения для бизнес-аналитики.
Обзор методов размерного моделирования Кимбалла
81
Глава 4. Склад, с. 163
Глава 16. Страхование, с. 461
Таблицы фактов транзакций
Строка в таблице фактов транзакции соответствует событию измерения в определенной точке пространства и времени. Таблицы фактов транзакций атомарной
зернистости — это наиболее размерные и выразительные таблицы фактов; такая
надежная размерность позволяет максимально разрезать и разделить эти транзакции. Таблицы фактов транзакций могут быть плотными или разреженными, поскольку строки существуют только в том случае, если есть измерения. Эти таблицы
фактов всегда содержат внешний ключ для каждого связанного измерения, а также
могут содержать точные отметки времени и ключи вырожденных измерений. Измеренные числовые факты должны соответствовать зернистости транзакции.
Глава 3. Розничные продажи, с. 115
Глава 4. Склад, с. 163
Глава 5. Закупки, с. 197
Глава 6. Управление заказами, с. 225
Глава 7. Бухгалтерский учет, с. 263
Глава 11. Телекоммуникации, с. 371
Глава 12. Транспортировка, с. 389
Глава 14. Здравоохранение, с. 419
Глава 15. Электронная коммерция, с. 437
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Таблицы фактов периодических моментальных снимков
Строка в таблице фактов периодических снимков суммирует многие события
измерения, происходящие за стандартный период, например неделя или месяц.
Зернистость — это период, а не отдельная транзакция. Таблицы фактов периодических моментальных снимков часто содержат много фактов, потому что любое событие измерения, согласующееся с зернистостью таблицы фактов, допустимо. Эти
таблицы фактов имеют одинаковую плотность по своим внешним ключам, потому
что, даже если в течение периода не происходит никаких действий, в таблицу фактов обычно вставляется строка, содержащая ноль или NULL для каждого факта.
82
Глава 2
Глава 4. Склад, с. 163
Глава 7. Бухгалтерский учет, с. 263
Глава 9. Управление персоналом, с. 333
Глава 10. Финансовые услуги, с. 353
Глава 13. Образование, с. 405
Глава 14. Здравоохранение, с. 419
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Накопительные таблицы фактов моментальных снимков
Строка в накопительной таблице фактов моментального снимка суммирует события измерения, происходящие на предсказуемых шагах между началом и концом процесса. С помощью этого типа таблицы фактов можно смоделировать конвейерные или рабочие процессы, такие как выполнение заказов или обработка
заявок, которые имеют определенную начальную точку, стандартные промежуточные шаги и определенную конечную точку. В таблице фактов есть внешний
ключ даты для каждого критического шага процесса. Отдельная строка в накопительной таблице фактов моментальных снимков, соответствующая, например,
строке в заказе, изначально вставляется при создании строки заказа. По мере
продвижения конвейера строка накопительной таблицы фактов пересматривается и обновляется. Такое последовательное обновление строк накапливаемой
таблицы фактов снимков уникально среди трех типов таблиц фактов. В дополнение к внешним ключам даты, связанным с каждым критическим этапом процесса, накопительные таблицы фактов моментальных снимков содержат внешние
ключи для других измерений и, возможно, вырожденные измерения. Они часто
включают запаздывающие числовые измерения, соответствующие зернистости,
наряду со счетчиками завершения этапов.
Глава 4. Склад, с. 163
Глава 5. Закупки, с. 197
Глава 6. Управление заказами, с. 225
Глава 13. Образование, с. 405
Глава 14. Здравоохранение, с. 419
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Обзор методов размерного моделирования Кимбалла
83
Таблицы фактов без показателей
Хотя большинство событий измерения фиксируют числовые результаты, возможно, что событие просто регистрирует набор объектов измерения, собирающихся
в определенный момент времени. Например, событие ученика, посещающего
класс в данный день, может не иметь записанного числового факта, но строка
фактов с внешними ключами для календарного дня, ученика, учителя, местоположения и класса определена четко. Точно так же общение с клиентами — это
события, но связанные с ними метрики могут отсутствовать. Таблицы фактов без
показателей также можно использовать для анализа того, чего не произошло. Эти
запросы всегда состоят из двух частей: таблицы покрытия без метрик, содержащей все возможности событий, которые могут произойти, и таблицы действий,
содержащей события, которые действительно произошли. Когда активность вычитается из покрытия, результат — это набор событий, которых не было.
Глава 3. Розничные продажи, с. 115
Глава 6. Управление заказами, с. 225
Глава 13. Образование, с. 405
Глава 16. Страхование, с. 461
Агрегированные таблицы фактов, или кубы OLAP
Агрегированные таблицы фактов — это простые числовые свертки данных атомарной таблицы фактов, созданные исключительно для повышения производительности запросов. Эти сводные таблицы фактов должны быть доступны для
уровня бизнес-аналитики одновременно с атомарными таблицами фактов, чтобы инструменты бизнес-аналитики могли выбирать соответствующий уровень
агрегирования во время запроса. Этот процесс, известный как агрегированная
навигация, должен быть открытым, чтобы каждый создатель отчетов, инструмент
запросов и приложение бизнес-аналитики получали одинаковые преимущества
в производительности. Правильно спроектированный набор агрегатов должен
вести себя как индексы базы данных, которые ускоряют выполнение запросов,
но не обнаруживаются непосредственно приложениями бизнес-аналитики или
бизнес-пользователями. Агрегированные таблицы фактов содержат внешние
ключи для сжатых согласованных измерений, а также агрегированные факты, созданные путем суммирования показателей из большего количества атомарных
таблиц фактов. Наконец, агрегированные кубы OLAP с итоговыми показателями часто строятся так же, как и реляционные агрегаты, но кубы OLAP предназначены для непосредственного доступа бизнес-пользователей.
84
Глава 2
Глава 15. Электронная коммерция, с. 437
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Консолидированные таблицы фактов
Часто бывает удобно объединить факты из нескольких процессов в единую
консолидированную таблицу фактов, если они могут быть выражены в одной
и той же зернистости. Например, фактические продажи могут быть объединены
с прогнозами продаж в единую таблицу фактов, чтобы упростить и ускорить задачу анализа фактических данных в сравнении с прогнозами. Это будет выглядеть
выигрышно на фоне сборки приложения с использованием отдельных таблиц
фактов. Консолидированные таблицы фактов увеличивают нагрузку на обработку ETL, но облегчают аналитическую нагрузку на приложения BI. Их следует
использовать для построения метрик между процессами, которые часто анализируются вместе.
Глава 7. Бухгалтерский учет, с. 263
Глава 16. Страхование, с. 461
Основные методы работы
с таблицами измерений
Методы, описанные в этом разделе, применимы ко всем таблицам измерений.
Примеры таблиц измерений описываются в каждой главе.
Структура таблицы измерений
Каждая таблица измерения имеет один столбец первичного ключа. Этот первичный ключ внедряется как внешний ключ в любую связанную таблицу фактов, где описательный контекст строки измерения точно соответствует строке
таблицы фактов. Таблицы измерений — это обычно широкие, плоские денормализованные таблицы со множеством текстовых атрибутов низкой кардинальности. В то время как операционные коды и индикаторы можно рассматривать
как атрибуты, наиболее важные атрибуты измерений содержат подробные описания. Атрибуты таблицы измерений первые в очереди для создания фильтров
Обзор методов размерного моделирования Кимбалла
85
и группировки запросов из приложения бизнес-аналитики. Описательные метки
в отчетах — это обычно значения атрибутов таблиц измерений.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Суррогатные ключи измерений
В таблице измерений один столбец служит уникальным первичным ключом.
Этот первичный ключ не может быть натуральным ключом операционной системы, потому что при отслеживании изменений во времени для этого естественного ключа будет несколько строк измерений. Кроме того, натуральные ключи
для измерения могут быть созданы более чем одной исходной системой, и эти
естественные ключи могут быть несовместимыми или плохо управляемыми. Система DW/BI должна требовать управления первичными ключами всех измерений; вместо того чтобы использовать явные натуральные ключи или натуральные
ключи с добавленными датами, вам следует создать анонимные целочисленные
первичные ключи для каждого измерения. Эти суррогатные ключи измерения
представляют собой просто целые числа, назначаемые последовательно начиная со значения 1 каждый раз, когда требуется новый ключ. На измерение даты
не распространяется правило суррогатного ключа; это очень предсказуемое
и стабильное измерение может использовать более смысловой первичный ключ.
См. раздел «Измерения календарной даты».
Глава 3. Розничные продажи, с. 115
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Натуральные, стойкие и сверхнатуральные ключи
Натуральные ключи, созданные операционными исходными системами, подчиняются бизнес-правилам, которые не контролируются системой DW/BI. Например, номер сотрудника (натуральный ключ) может быть изменен, если сотрудник увольняется, а затем его повторно принимают на работу. Когда хранилище
86
Глава 2
данных хочет иметь единственный ключ для этого сотрудника, необходимо создать новый стойкий ключ, который будет постоянным и не изменится в этой
ситуации. Этот ключ иногда называют стойким сверхнатуральным ключом. Лучшие стойкие ключи имеют формат, не зависящий от исходного бизнес-процесса,
и поэтому должны быть просто целыми числами, назначаемыми в последовательности начиная с 1. В то время как несколько суррогатных ключей могут быть
связаны с сотрудником с течением времени по мере изменения его профиля, постоянный ключ никогда не меняется.
Глава 3. Розничные продажи, с. 115
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Глава 21. Аналитика больших данных, с. 637
Детализация
Детализация (drill down) — это наиболее фундаментальный способ анализа данных бизнес-пользователями. Детализация означает просто добавление заголовка
строки к существующему запросу; новый заголовок строки — это атрибут измерения, добавленный к выражению GROUP BY в запросе SQL. Этот атрибут
может поступать из любого измерения, прикрепленного к таблице фактов в запросе. Детализация не требует определения заранее заданных иерархий или путей детализации.
Глава 3. Розничные продажи, с. 115
Вырожденные измерения
Иногда определяется измерение, которое не имеет содержимого, кроме своего
первичного ключа. Например, если в чеке имеется несколько позиций, строки фактов позиции наследуют все внешние ключи описательных измерений
чека, а сам чек остается без уникального содержимого. Но номер чека остается
действительным ключом измерения для таблиц фактов на уровне отдельной
позиции. Это вырожденное измерение помещается в таблицу фактов с явным
подтверждением отсутствия связанной таблицы измерений. Вырожденные измерения чаще всего встречаются в таблицах фактов транзакций и накопительных снимков.
Обзор методов размерного моделирования Кимбалла
87
Глава 3. Розничные продажи, с. 115
Глава 6. Управление заказами, с. 225
Глава 11. Телекоммуникации, с. 371
Глава 16. Страхование, с. 461
Денормализованные плоские измерения
Вообще говоря, проектировщики размерных моделей данных должны противостоять побуждениям к нормализации, вызванным годами разработки операционных баз данных, и вместо этого денормализовать иерархии с фиксированной
глубиной типа «многие к одному» в отдельные атрибуты в плоской строке измерения. Денормализация измерений отражает две основные цели размерного
моделирования — простоту и скорость.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 3. Розничные продажи, с. 115
Несколько иерархий в измерениях
Многие измерения содержат более одной естественной иерархии. Например, измерения календарной даты могут иметь иерархию от дня к неделе до финансового периода, а также от месяца к году. Измерения, требующие большого количества местоположений, могут иметь несколько географических иерархий. Во всех этих случаях
отдельные иерархии могут стабильно сосуществовать в одной таблице измерений.
Глава 3. Розничные продажи, с. 115
Глава 19. Подсистемы и методы ETL, с. 539
Флаги и индикаторы как текстовые атрибуты
Загадочные аббревиатуры, метки «истина/ложь» и операционные индикаторы
следует дополнять в таблицах измерений полными текстовыми словами, которые
имеют смысл для пользователя. Коды операций со встроенным смыслом кода
должны быть разбиты, каждая часть кода должна быть помещена в отдельный
атрибут описательного измерения.
88
Глава 2
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Глава 16. Страхование, с. 461
Пустые атрибуты в измерениях
Атрибуты измерения с пустым значением возникают, когда строка измерения
не заполнена полностью или если есть атрибуты, которые не применяются ко всем
строкам измерения. В обоих случаях мы рекомендуем заменить пустое значение
описательной строкой, например, «Неизвестно» или «Неприменимо». Пустых
значений в атрибутах измерения следует избегать, потому что разные базы данных
обрабатывают группировку и ограничение на пустые значения по-разному.
Глава 3. Розничные продажи, с. 115
Измерение «Календарная дата»
Измерения «Календарная дата» прикреплены практически к каждой таблице
фактов, что позволяет перемещаться в таблице фактов по знакомым датам, месяцам, финансовым периодам и особым дням в календаре. Вы вряд ли захотите
вычислять Пасху в SQL — скорее вы захотите найти ее в измерении «Календарная дата». Измерение «Календарная дата» обычно имеет множество атрибутов,
описывающих такие характеристики, как номер недели, название месяца, финансовый период и индикатор национального праздника.
Для облегчения разделения первичный ключ измерения даты может быть более смысловым, например целым числом, представляющим ГГГГММДД, вместо
последовательно назначаемого суррогатного ключа. Однако в таблице измерения
дат требуется специальная строка для представления неизвестных или будущих
дат. Когда требуется дополнительная точность, в таблицу фактов можно добавить
отдельную отметку даты/времени. Отметка даты/времени не внешний ключ таблицы измерений, а отдельный столбец. Если бизнес-пользователи ограничивают
или группируют атрибуты времени дня, такие как группировка по частям дня
или номеру смены, то вы должны добавить отдельный внешний ключ измерения
времени дня в таблицу фактов.
Глава 3. Розничные продажи, с. 115
Обзор методов размерного моделирования Кимбалла
89
Глава 7. Бухгалтерский учет, с. 263
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 12. Транспортировка, с. 389
Глава 19. Подсистемы и методы ETL, с. 539
Важные ролевые изменения
На одно физическое измерение можно ссылаться несколько раз в таблице фактов, причем каждая ссылка связана с логически отдельной ролью для измерения.
Например, таблица фактов может иметь несколько дат, каждая из которых представлена внешним ключом для измерения «Дата». Каждый внешний ключ обязательно должен ссылаться на отдельное представление измерения даты, чтобы
ссылки были независимыми. Эти отдельные представления измерений (с уникальными именами столбцов атрибутов) называются ролями.
Глава 6. Управление заказами, с. 225
Глава 12. Транспортировка, с. 389
Глава 14. Здравоохранение, с. 419
Глава 16. Страхование, с. 461
Мусорные измерения
Транзакционные бизнес-процессы обычно производят множество разных,
имеющих небольшое значение флагов и индикаторов. Вместо того чтобы создавать отдельные измерения для каждого флага и атрибута, вы можете создать
одно мусорное измерение, объединив их. Это измерение, часто обозначаемое
в схеме как измерение профиля транзакции, необязательно должно быть декартовым произведением всех возможных значений атрибутов. Ему достаточно
содержать комбинацию значений, которые фактически встречаются в исходных
данных.
Глава 6. Управление заказами, с. 225
Глава 12. Транспортировка, с. 389
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
90
Глава 2
Измерения в виде «снежинки»
Когда иерархическая связь в таблице измерения нормализуется, атрибуты с низкой кардинальностью появляются как вторичные таблицы, связанные с базовой
таблицей измерения с помощью ключа. Когда этот процесс повторяется со всеми
иерархиями таблицы измерения, создается характерная многоуровневая структура, которая называется «снежинкой». Хотя «снежинки» точно представляют
иерархические данные, вам следует их избегать, потому что бизнес-пользователям
сложно понять «снежинки» и ориентироваться в них. Они также могут отрицательно повлиять на производительность запросов. Таблица измерений с плоскими денормализованными измерениями содержит точно такую же информацию,
что и измерения «снежинки».
Глава 3. Розничные продажи, с. 115
Глава 11. Телекоммуникации, с. 371
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Измерения с внешней опорой
Измерение может содержать ссылку на другую таблицу измерений. Например, измерение «Банковский счет» может ссылаться на отдельное измерение, представляющее
дату открытия счета. Эти вторичные привязки измерений называются измерениями
с внешней опорой. Они допустимы, но их следует использовать с осторожностью.
В большинстве случаев корреляции между измерениями следует перенести в таблицу
фактов, где оба измерения представлены как отдельные внешние ключи.
Глава 3. Розничные продажи, с. 115
Глава 5. Закупки, с. 197
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 12. Транспортировка, с. 389
Интеграция через согласованные измерения
Одним из значительных успехов подхода к размерному моделированию стало
определение простого, но действенного рецепта интеграции данных из различных бизнес-процессов.
Обзор методов размерного моделирования Кимбалла
91
Согласованные измерения
Таблицы измерений согласованы, когда у атрибутов в отдельных таблицах измерений одинаковые имена столбцов и содержимое домена. Информацию из отдельных таблиц фактов можно объединить в один отчет с помощью атрибутов
согласованных измерений, связанных с каждой таблицей фактов. Когда согласованный атрибут используется в качестве заголовка строки (то есть столбца
группировки в SQL-запросе), результаты из отдельных таблиц фактов могут
быть объединены по одним и тем же строкам в подробном отчете. В этом суть
интеграции в корпоративную систему DW/BI. Согласованные измерения, определенные один раз в сотрудничестве с представителями компании, которые занимаются управлением данных, повторно используются в таблицах фактов; они как
обеспечивают аналитическую согласованность, так и сокращают будущие затраты
на разработку, поскольку колесо не приходится изобретать заново.
Глава 4. Склад, с. 163
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 11. Телекоммуникации, с. 371
Глава 16. Страхование, с. 461
Глава 18. Процессы и задачи размерного моделирования, с. 523
Глава 19. Подсистемы и методы ETL, с. 539
Сжатые измерения
Сжатые измерения — это согласованные измерения, которые представляют собой
подмножество строк и/или столбцов базового измерения. При построении сводных таблиц фактов требуются сжатые измерения. Они также необходимы для бизнес-процессов, которые естественным образом собирают данные на более высоком
уровне детализации, например прогноз по месяцам и брендам (вместо более элементарных типа даты и продукта, связанных с данными о продажах). Другой случай согласованного подмножества измерений имеет место, когда два измерения находятся
на одном уровне детализации, но одно представляет только подмножество строк.
Глава 4. Склад, с. 163
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
92
Глава 2
Копаем вширь
Детализация (drill across) просто означает выполнение отдельных запросов
к двум или более таблицам фактов, в которых заголовки строк каждого запроса
состоят из идентичных согласованных атрибутов. Наборы ответов из двух запросов объединяются путем выполнения операции «сортировка — слияние» для
заголовков строк общих атрибутов измерений. Разработчики инструментов бизнес-аналитики называют эту функцию по-разному, в том числе сшивкой и многопроходным запросом.
Глава 4. Склад, с. 163
Цепочка значений
Цепочка значений определяет естественный поток основных бизнес-процессов
организации. Например, цепочка значений розничного продавца может идти
от закупок до складирования и далее до розничных продаж. Цепочка значений
в главной бухгалтерской книге может состоять из бюджетирования обязательств
по платежам. Операционные исходные системы обычно создают транзакции,
или моментальные снимки, на каждом этапе цепочки значений. Поскольку каждый процесс создает уникальные метрики в уникальные интервалы времени
с уникальной детализацией и размерностью, каждый процесс обычно порождает
по крайней мере одну атомарную таблицу фактов.
Глава 4. Склад, с. 163
Глава 7. Бухгалтерский учет, с. 263
Глава 16. Страхование, с. 461
Архитектура шины корпоративного хранилища данных
Архитектура шины корпоративного хранилища данных обеспечивает поэтапный
подход к построению корпоративной системы DW/BI. Эта архитектура разбивает процесс планирования DW/BI на управляемые части, сосредотачивается
на бизнес-процессах и обеспечивает интеграцию с помощью стандартизованных
согласованных измерений, которые повторно используются во всех процессах.
Они обеспечивают архитектурную структуру, а также декомпозицию программы, чтобы способствовать управляемым гибким реализациям, соответствующим строкам в матрице шины корпоративного хранилища данных. Архитектура
Обзор методов размерного моделирования Кимбалла
93
шины не зависит от технологии и платформы базы данных; могут участвовать
как реляционные БД, так и размерные структуры OLAP.
Глава 1. Хранение данных, анализ данных и основы размерного моделирования, с. 33
Глава 4. Склад, с. 163
Матрица шины корпоративного хранилища данных
Матрица шины корпоративного хранилища данных — важный инструмент для
проектирования и передачи архитектуры шины корпоративного хранилища данных. Строки матрицы — это бизнес-процессы, а столбцы — измерения. Затемненные ячейки матрицы показывают, что измерение не связано с конкретным
бизнес-процессом. Группа разработчиков просматривает каждую строку, чтобы
проверить, правильно ли определено измерение-кандидат для бизнес-процесса,
и каждый столбец, чтобы увидеть, где измерение должно согласовываться в нескольких бизнес-процессах. Помимо технических аспектов проектирования,
матрица шины используется в качестве входных данных для определения приоритетов проектов DW/BI с управлением бизнесом, поскольку команды должны
внедрять по одной строке матрицы за раз.
Глава 4. Склад, с. 163
Глава 5. Закупки, с. 197
Глава 6. Управление заказами, с. 225
Глава 7. Бухгалтерский учет, с. 263
Глава 9. Управление персоналом, с. 333
Глава 10. Финансовые услуги, с. 353
Глава 11. Телекоммуникации, с. 371
Глава 12. Транспортировка, с. 389
Глава 13. Образование, с. 405
Глава 14. Здравоохранение, с. 419
Глава 15. Электронная коммерция, с. 437
Глава 16. Страхование, с. 461
Подробная матрица шины реализации
Подробная матрица шины реализации — это более детальная матрица шины,
в которой каждая строка бизнес-процесса была расширена для отображения
94
Глава 2
конкретных таблиц фактов или кубов OLAP. На этом уровне детализации может
быть задокументировано точное изложение фактов и перечень фактов.
Глава 5. Закупки, с. 197
Глава 16. Страхование, с. 461
Матрица возможностей/заинтересованных сторон
После того как строки матрицы шины корпоративного хранилища данных были
идентифицированы, вы можете составить другую матрицу, заменив столбцы измерений бизнес-функциями, такими как маркетинг, продажи и финансы, а затем
закрасить ячейки матрицы, чтобы указать, какие бизнес-функции к каким строкам бизнес-процессов относятся. Матрица возможностей/заинтересованных
сторон помогает определить, какие бизнес-группы следует приглашать на сеансы
совместного проектирования для каждой строки, ориентированной на процесс.
Глава 4. Склад, с. 163
Работа с атрибутами медленно
изменяющегося измерения
В следующем разделе описываются фундаментальные подходы к работе с атрибутами медленно меняющегося измерения (SCD — slowly changing dimension).
Довольно часто в одной таблице измерений есть атрибуты, которые обрабатываются разными методами отслеживания изменений.
Тип 0: сохранение оригинала
При типе 0 значение атрибута никогда не изменяется, поэтому факты всегда группируются по этому исходному значению. Тип 0 подходит для любого атрибута
с пометкой «оригинал», например исходная кредитная оценка клиента или постоянный идентификатор. Это также применимо к большинству атрибутов в измерении даты.
Глава 5. Закупки, с. 197
Обзор методов размерного моделирования Кимбалла
95
Тип 1: перезапись
При типе 1 старое значение атрибута в строке измерения заменяется новым значением. Атрибуты типа 1 всегда отражают последнее присвоение, поэтому этот
метод уничтожает историю. Хотя этот подход прост в реализации и не создает
дополнительных строк измерений, вы должны быть осторожны и уверены в том,
что агрегированные таблицы фактов и кубы OLAP, затронутые этим изменением, пересчитаны.
Глава 5. Закупки, с. 197
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Тип 2: добавление новой строки
Изменения типа 2 добавляют новую строку в измерение с обновленными значениями атрибутов. Это требует обобщения первичного ключа измерения за пределами натурального или устойчивого ключа, поскольку потенциально может
быть несколько строк, описывающих каждый член. Когда для элемента измерения создается новая строка, назначается новый первичный суррогатный ключ.
Он используется в качестве внешнего ключа во всех таблицах фактов с момента
обновления до последующего изменения, создающего новый ключ измерения
и обновленную строку измерения. В строку измерения следует добавить минимум три дополнительных столбца с изменениями типа 2:
■ дата вступления в силу строки или отметка даты/времени;
■ срок действия строки или отметка даты/времени;
■ индикатор текущей строки.
Глава 5. Закупки, с. 197
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 9. Управление персоналом, с. 333
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
96
Глава 2
Тип 3: добавление нового атрибута
Изменения типа 3 добавляют новый атрибут в измерение, чтобы сохранить старое значение атрибута; новое значение перезаписывает основной атрибут, как
при изменении типа 1. Такое изменение типа 3 иногда называют альтернативной
реальностью. Бизнес-пользователь может группировать и фильтровать данные
фактов либо по текущему значению, либо по альтернативной реальности. Этот
метод медленно меняющегося измерения используется относительно нечасто.
Глава 5. Закупки, с. 197
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Тип 4: добавление мини-измерения
Метод типа 4 используется, когда группа атрибутов в измерении быстро изменяется и разделяется на мини-измерения. Эту ситуацию иногда называют быстро
меняющимся измерением-монстром. Часто используемые атрибуты в таблицах
измерений с многомиллионными строками — кандидаты на разработку миниизмерений, даже если они не изменяются часто. Мини-измерение типа 4 требует
собственного уникального первичного ключа; первичные ключи как базового
измерения, так и мини-измерения фиксируются в связанных таблицах фактов.
Глава 5. Закупки, с. 197
Глава 10. Финансовые услуги, с. 353
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Тип 5: добавление мини-измерения и внешней опоры типа 1
Техника типа 5 используется для точного сохранения исторических значений
атрибутов, а также для сообщения исторических фактов в соответствии с текущими значениями атрибутов. Тип 5 основан на мини-измерении типа 4: он тоже
встраивает ссылку текущего типа 1 на мини-измерение в базовое измерение. Это
обеспечивает доступ к назначенным в данный момент атрибутам мини-измерения вместе с другими атрибутами в базовом измерении без связывания через
таблицу фактов. По логике, вы можете представить базовое измерение и опору
мини-измерения в виде единой таблицы в области представления. Команда ETL
Обзор методов размерного моделирования Кимбалла
97
должна перезаписывать эту ссылку на мини-измерение типа 1 всякий раз, когда
изменяется текущее назначение мини-измерения.
Глава 5. Закупки, с. 197
Глава 19. Подсистемы и методы ETL, с. 539
Тип 6: добавление атрибута типа 1 к измерению типа 2
Как и тип 5, тип 6 также предоставляет как исторические, так и текущие значения
атрибутов измерения. Тип 6 основывается на методе типа 2, так же встраивая текущие версии тех же атрибутов типа 1 в строку измерения, так что строки фактов
могут быть отфильтрованы или сгруппированы либо по значению атрибута типа 2,
действующему на момент замеров, либо по текущему значению атрибута. В этом
случае атрибут типа 1 систематически перезаписывается во всех строках, связанных
с конкретным стойким ключом, всякий раз, когда атрибут обновляется.
Глава 5. Закупки, с. 197
Глава 19. Подсистемы и методы ETL, с. 539
Тип 7: двойные измерения типа 1 и типа 2
Тип 7 — это окончательный гибридный метод, используемый для поддержки отчетности «как было» и «как есть». К таблице фактов можно получить доступ
через измерение, смоделированное как измерение типа 1, показывающее только
последние значения атрибутов, или как измерение типа 2, показывающее правильные современные исторические профили. Одна и та же таблица измерений
позволяет использовать обе перспективы. И стойкий ключ, и первичный суррогатный ключ измерения помещаются в таблицу фактов. Для перспективы типа 1
индикатор текущей строки в измерении должен быть верным, а таблица фактов
присоединяется с помощью стойкого ключа. Для перспективы типа 2 значение
индикатора текущей строки неважно, и таблица фактов присоединяется через
суррогатный первичный ключ. Эти две перспективы будут развернуты как отдельные представления в приложении бизнес-аналитики.
Глава 5. Закупки, с. 197
Глава 19. Подсистемы и методы ETL, с. 539
98
Глава 2
Работа с иерархиями измерений
Иерархии измерений — обычное дело. В этом разделе описаны подходы к работе
с иерархиями начиная с самых простых концепций.
Позиционные иерархии с фиксированной глубиной
Иерархия фиксированной глубины — это серия отношений «многие к одному»,
таких как продукт к бренду, далее бренда к категории и далее категории к отделу.
Когда определена иерархия с фиксированной глубиной и для всех уровней иерархии согласованы имена, уровни иерархии должны отображаться как отдельные
позиционные атрибуты в таблице измерений. Иерархия с фиксированной глубиной, безусловно, наиболее проста для понимания и навигации при соблюдении
вышеуказанных критериев. Она также обеспечивает предсказуемую и быструю
производительность запросов. Когда иерархия не является последовательностью отношений «многие к одному» или количество уровней меняется так, что
уровни не имеют согласованных имен, необходимо использовать метод рваной
иерархии, описанный ниже.
Глава 3. Розничные продажи, с. 115
Глава 7. Бухгалтерский учет, с. 263
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Иерархии с пропущенными уровнями /
иерархии переменной глубины
Иерархии с пропущенными уровнями не имеют фиксированного количества
уровней, но диапазон их глубины невелик. Географические иерархии часто имеют глубину от трех до шести уровней. Вместо того чтобы использовать сложный
механизм для непредсказуемо изменяемых иерархий, вы можете принудительно
подогнать иерархии к позиционному дизайну с фиксированной глубиной, подогнав все атрибуты до максимальной глубины и заполнив отсутствующие уровни
по правилам бизнеса.
Глава 7. Бухгалтерский учет, с. 263
Обзор методов размерного моделирования Кимбалла
99
Неровные иерархии/иерархии переменной глубины
с соединительными таблицами иерархии
Неровные (рваные) иерархии неопределенной глубины сложно моделировать и запрашивать в реляционной базе данных. Хотя расширения SQL
и языки доступа к OLAP обеспечивают некоторую поддержку рекурсивных
родительско-дочерних отношений, эти подходы имеют ограничения. При
использовании расширений SQL альтернативные рваные иерархии не могут
быть заменены во время запроса, структуры совместного владения не поддерживаются, как и рваные иерархии, изменяющиеся во времени. Все эти
возражения можно преодолеть в реляционных базах данных, смоделировав
рваную иерархию с помощью специально построенной соединительной таблицы. Эта соединительная таблица содержит строку для каждого возможного
пути в рваной иерархии и позволяет выполнять все формы обхода иерархии
с помощью стандартного SQL вместо использования специальных языковых
расширений.
Глава 7. Бухгалтерский учет, с. 263
Глава 9. Управление персоналом, с. 333
Рваные иерархии/иерархии переменной глубины
с атрибутами пути
Использования соединительной таблицы для рваных иерархий переменной
глубины можно избежать, реализовав атрибут Pathstring (строка пути) в измерении. Для каждой строки в измерении атрибут Pathstring содержит специально закодированную текстовую строку. В этой строке содержится полное
описание пути от верхнего узла иерархии до узла, описываемого конкретной
строкой измерения. Многие из стандартных запросов анализа иерархии могут
затем обрабатываться стандартным SQL без использования расширений языка
SQL. Однако подход с использованием строк путей не позволяет быстро заменять альтернативные иерархии или иерархии совместного владения. Подход
с использованием строк путей также может быть уязвим для структурных изменений в рваной иерархии, которые могут вынудить изменять разметку путей
по всей иерархии.
Глава 7. Бухгалтерский учет, с. 263
100
Глава 2
Продвинутые методы работы
с таблицами фактов
Приемы в этом разделе относятся к менее распространенным паттернам таблиц
фактов.
Суррогатные ключи таблицы фактов
Суррогатные ключи используются для реализации первичных ключей почти всех
таблиц измерений. Кроме того, могут быть полезны суррогатные ключи фактов,
состоящие из одного столбца, хотя они и необязательны. Суррогатные ключи
таблицы фактов, которые не связаны с каким-либо измерением, назначаются последовательно во время процесса загрузки ETL. Их свойства:
1. Используются в качестве первичного ключа в одном столбце таблицы фактов.
2. Служат непосредственным идентификатором строки таблицы фактов без
навигации по нескольким измерениям для целей ETL.
3. Позволяют откатить или возобновить прерванный процесс загрузки.
4. Позволяют разбить операции обновления таблицы фактов на менее рискованные операции вставки и удаления.
Глава 3. Розничные продажи, с. 115
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Таблицы-«сороконожки» с фактами
Некоторые разработчики создают отдельные нормализованные измерения для
каждого уровня иерархии «многие к одному», например измерения «День»,
«Месяц», «Квартал» и «Год», а затем включают все эти внешние ключи в таблицу фактов. В результате получается таблица-«сороконожка» фактов с десятками иерархически связанных измерений. Таких таблиц фактов следует избегать.
Все эти фиксированные по глубине, иерархически связанные измерения «многие
к одному» должны быть свернуты обратно до их уникальных наименьших зернистостей, таких как «день» для упомянутого примера. Таблицы-«сороконожки»
фактов также возникают, когда разработчики встраивают многочисленные внешние ключи в отдельные таблицы измерений с низкой кардинальностью, а не создают мусорное измерение.
Обзор методов размерного моделирования Кимбалла
101
Глава 3. Розничные продажи, с. 115
Числовые значения как атрибуты или факты
Разработчики иногда сталкиваются с числовыми значениями, которые явно не попадают ни в категории атрибутов фактов, ни в категории измерений. Классический
пример — стандартная цена продукта по прейскуранту. Если числовое значение
используется в основном для расчетных целей, оно, вероятно, относится к таблице
фактов. Если стабильное числовое значение используется преимущественно для
фильтрации и группировки, его следует рассматривать как атрибут измерения; дискретные числовые значения могут быть дополнены атрибутами диапазона значений, к примеру, 0–50 долларов США. В некоторых случаях полезно моделировать
числовое значение как атрибут факта и измерения, например количественный показатель своевременной доставки и качественный текстовый дескриптор.
Глава 3. Розничные продажи, с. 115
Глава 6. Управление заказами, с. 225
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 16. Страхование, с. 461
Факты о задержке/продолжительности
Накопительные таблицы фактов моментальных снимков фиксируют несколько
этапов процесса; каждая из таблиц имеет внешний ключ даты и, возможно, отметку даты/времени. Бизнес-пользователи часто хотят анализировать задержки или продолжительность между этими этапами; иногда эти задержки — это
просто разница между датами, но в других случаях задержки основаны на более
сложных бизнес-правилах. Если в конвейере есть десятки шагов, могут быть сотни возможных задержек. Вместо того чтобы заставлять пользовательский запрос
вычислять каждое возможное отставание от меток даты/времени или внешних
ключей измерения даты, можно сохранить только одно временное отставание
для каждого шага, измеренного относительно начальной точки процесса. Затем
каждое возможное отставание между двумя шагами можно вычислить как простое вычитание между двумя задержками, хранящимися в таблице фактов.
Глава 6. Управление заказами, с. 225
Глава 16. Страхование, с. 461
102
Глава 2
Заголовок/строка в таблице фактов
Операционные системы транзакций часто состоят из строки заголовка транзакции, связанной с несколькими строками транзакции. При использовании схем
заголовков/строк (также известных как родительские/дочерние схемы) все внешние ключи измерения уровня заголовка и вырожденные измерения должны
быть включены в таблицу фактов на уровне строк.
Глава 6. Управление заказами, с. 225
Глава 12. Транспортировка, с. 389
Глава 15. Электронная коммерция, с. 437
Выделенные факты
В данных транзакции типа заголовок/строка довольно часто встречаются факты разной степени детализации, такие как стоимость перевозки (определяется на уровне
заголовка). Вы должны стремиться распределить факты заголовка до уровня строк
на основе правил, предоставляемых бизнесом, чтобы выделенные факты можно было
разделить и свести воедино по всем измерениям. Во многих случаях вы можете избежать создания таблицы фактов на уровне заголовка, если только такое агрегирование
не обеспечивает преимущества в производительности запросов.
Глава 6. Управление заказами, с. 225
Таблицы фактов прибылей и убытков с выделением
фактов
Таблицы фактов, раскрывающие полное уравнение прибыли, — один из самых
эффективных инструментов корпоративной системы DW/BI. Уравнение прибыли: (доход) — (затраты) = (прибыль). Таблицы фактов идеально реализуют уравнение прибыли на уровне транзакции с атомарным доходом и содержат множество компонентов затрат. Поскольку эти таблицы созданы на основе атомарной
зернистости, возможны многочисленные варианты выводов включая доходность
от клиента, прибыльность продукта, прибыльность продвижения, прибыльность
канала и другие. Однако эти таблицы фактов сложно построить, потому что компоненты затрат должны быть приведены из исходных источников к зернистости
таблицы фактов. Этот этап выделения — часто основная подсистема ETL и политически мотивированный шаг, требующий поддержки со стороны руководства
Обзор методов размерного моделирования Кимбалла
103
высокого уровня. По этим причинам таблицы фактов прибылей и убытков обычно
не рассматриваются на ранних этапах реализации программы DW/BI.
Глава 6. Управление заказами, с. 225
Глава 15. Электронная коммерция, с. 437
Факты разных валют
Таблицы фактов, в которых регистрируются финансовые операции в нескольких валютах, должны содержать пару столбцов для каждого финансового факта
в строке. Один столбец содержит факт, выраженный в истинной валюте транзакции, а другой — тот же факт, выраженный в единой стандартной валюте, которая
используется во всей таблице фактов. Значение в стандартной валюте вычисляется в процессе ETL в соответствии с утвержденным бизнес-правилом конвертации валюты. Эта таблица фактов также должна содержать ключ на измерение
«Валюта», чтобы определить истинную валюту транзакции.
Глава 6. Управление заказами, с. 225
Глава 7. Бухгалтерский учет, с. 263
Факты с множественными единицами измерения
Некоторые бизнес-процессы требуют одновременного изложения фактов в нескольких единицах измерения. Например, в зависимости от точки зрения бизнеспользователя цепочке поставок может потребоваться сообщать одни и те же факты,
но в палетах, отгрузочных ящиках, розничных ящиках или отдельных единицах
сканирования. Если таблица фактов содержит большое количество фактов, каждый
из которых должен быть выражен во всех единицах измерения, удобный метод —
сохранить факты в таблице один раз в согласованной стандартной единице измерения и одновременно сохранить преобразование: коэффициенты между стандартной мерой и всеми остальными. Эту таблицу фактов можно развернуть с помощью
представлений для каждой группы пользователей, используя соответствующий выбранный коэффициент преобразования. Коэффициенты преобразования должны
находиться в строке базовой таблицы фактов, чтобы обеспечить простое и правильное вычисление представления при минимальной сложности запроса.
Глава 6. Управление заказами, с. 225
104
Глава 2
Факты текущего года (Year-to-date)
Бизнес-пользователи часто запрашивают значения с начала года до текущей даты
(YTD, Year-to-date) в таблице фактов. Трудно возразить против такого запроса,
но запросы с начала года могут легко трансформироваться в «с начала финансового года до его закрытия» или «от начала финансового периода до настоящего
времени». Более надежный и расширяемый способ обработки таких разнообразных запросов — это вычисление метрик с начала года в приложениях бизнесаналитики или кубе OLAP, а не сохранение фактов начала года в таблице фактов.
Глава 7. Бухгалтерский учет, с. 263
Многопроходный SQL, чтобы избежать объединения
таблиц «факт — факт»
Приложение BI никогда не должно выдавать SQL, который соединяет две таблицы
фактов вместе по внешним ключам таблицы фактов. Невозможно контролировать
кардинальность набора ответов такого соединения в реляционной базе данных,
и инструмент BI будет возвращать неверные результаты. Например, если две таблицы фактов содержат данные о доставке продукта клиенту и возврате продукта
клиентам, эти две таблицы фактов не должны соединяться напрямую через внешние ключи клиента и продукта. Вместо этого следует использовать метод «копаем вширь» (drill across) по двум таблицам фактов, где наборы ответов из доставок
и возвратов создаются отдельно, а результаты объединяются по значениям атрибутов заголовка общей строки для получения правильного результата.
Глава 4. Склад, с. 163
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Отслеживание промежутка времени в таблицах фактов
Существует три основных зернистости таблицы фактов: транзакция, периодический моментальный снимок и накопительный моментальный снимок. В отдельных случаях полезно добавить дату вступления в силу строки, дату истечения
срока действия строки и индикатор актуальности строки в таблицу фактов, как
и в случае с медленно меняющимися измерениями типа 2, чтобы зафиксировать
временной интервал, когда строка фактов была эффективной. Хотя это необычный шаблон, он предназначен для таких сценариев, как медленное изменение
Обзор методов размерного моделирования Кимбалла
105
остатков запасов, когда частый периодический моментальный снимок будет загружать идентичные строки при формировании каждого снимка.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 16. Страхование, с. 461
Факты, появляющиеся с опозданием
Строка фактов поступает с опозданием, если последний контекст измерения для
новых строк фактов не соответствует входящей строке. Это происходит, когда
строка фактов задерживается. В этом случае необходимо выполнить поиск соответствующих измерений, чтобы найти ключи измерений, которые были эффективны, когда произошло событие измерения с опозданием.
Глава 14. Здравоохранение, с. 419
Глава 19. Подсистемы и методы ETL, с. 539
Расширенные методы работы с измерениями
Методы в этом разделе относятся к более сложным паттернам таблиц измерений.
Соединения таблиц «измерение — измерение»
Измерения могут содержать ссылки на другие измерения. Хотя эти отношения
могут быть смоделированы с помощью измерений с внешней опорой, в некоторых случаях наличие внешнего ключа к такому измерению в базовом измерении
может привести к взрывному росту базового измерения, поскольку изменения
типа 2 в измерении с внешней опорой приводят к изменениям типа 2 в базовом
измерении. Этого взрывного роста часто можно избежать, если понизить корреляцию между измерениями, поместив внешний ключ измерения-опоры в таблицу фактов, а не в базовое измерение. Это означает, что корреляцию между измерениями можно обнаружить только путем обхода таблицы фактов, но это может
быть приемлемо, особенно если таблица фактов представляет собой периодический моментальный снимок, где все ключи для всех измерений гарантированно
присутствуют для каждого отчетного периода.
Глава 6. Управление заказами, с. 225
106
Глава 2
Многозначные измерения и соединительные таблицы
В классической схеме измерений каждое измерение, прикрепленное к таблице фактов, имеет одно значение, соответствующее зернистости этой таблицы.
Но есть ряд ситуаций, в которых измерение имеет множество значений. Например, пациенту, получающему лечение, может быть одновременно поставлено несколько диагнозов. В этих случаях многозначное измерение должно быть
присоединено к таблице фактов с помощью ключа измерения группы из соединительной таблицы с одной строкой для каждого одновременного диагноза
в группе.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 9. Управление персоналом, с. 333
Глава 10. Финансовые услуги, с. 353
Глава 13. Образование, с. 405
Глава 14. Здравоохранение, с. 419
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Многозначные соединительные таблицы, меняющиеся
во времени
Многозначная соединительная таблица может быть основана на медленно меняющемся измерении типа 2. Например, соединительная таблица, которая реализует отношения «многие ко многим» между банковскими счетами и отдельными
клиентами, обычно должна быть основана на измерениях «Счет» и «Клиент»
типа 2. В этом случае, чтобы предотвратить неправильные связи между счетами
и клиентами, соединительная таблица должна включать метки даты/времени начала действия и истечения срока действия, а запрашивающее приложение должно ограничивать запрос в соединительную таблицу определенным моментом
времени для создания согласованного моментального снимка.
Глава 7. Бухгалтерский учет, с. 263
Глава 10. Финансовые услуги, с. 353
Обзор методов размерного моделирования Кимбалла
107
Временной ряд тега поведения
Почти весь текст в хранилище данных — это описательный текст в таблицах
измерений. Анализ кластера клиентов с интеллектуальным анализом данных
обычно приводит к появлению текстовых тегов поведения, которые часто идентифицируются на периодической основе. В этом случае измерения поведения
клиентов с течением времени становятся последовательностью этих поведенческих тегов; этот временной ряд должен храниться как позиционные атрибуты
в измерении «Клиент» вместе с необязательной текстовой строкой полной последовательности тегов. Теги поведения моделируются в позиционном дизайне,
потому что теги поведения — цель сложных одновременных запросов, а не числовых вычислений.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Исследовательские группы изучения поведения
Сложное поведение клиентов иногда можно обнаружить только путем длительного итеративного анализа. В этих случаях нецелесообразно встраивать анализ
поведения в каждое приложение бизнес-аналитики, которое хочет ограничить
всех членов измерения «Клиент», демонстрирующих сложное поведение. Однако результаты комплексного анализа поведения можно записать в простую таблицу, называемую исследовательской группой, состоящую только из устойчивых
ключей клиентов. Затем эту статическую таблицу можно использовать как своего
рода фильтр для любой схемы измерений с измерением «Клиент», ограничивая
столбец исследовательской группы постоянным ключом измерения клиента в целевой схеме во время запроса. Можно определить несколько исследовательских
групп и создать производные группы для изучения с пересечениями, объединениями и различиями множеств.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Агрегированные факты как атрибуты измерения
Бизнес-пользователи часто заинтересованы в ограничении измерения «Клиент»
на основе агрегированных показателей производительности, таких как фильтрация всех клиентов, которые потратили более определенной суммы в долларах
в течение прошлого года или, возможно, в течение жизни клиента. Выбранные
108
Глава 2
агрегированные факты могут быть помещены в измерение как цели для ограничения и как метки строк для отчетов. Эти показатели часто представлены в виде
диапазонов в таблице измерений. Атрибуты измерения, представляющие агрегированные метрики производительности, усложняют обработку ETL, но облегчают аналитическую нагрузку на уровне BI.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Динамические диапазоны значений
Отчет с динамическим диапазоном значений организуется в виде серии заголовков
строк отчета, которые определяют прогрессивный набор диапазонов переменного
размера целевого числового факта. Например, в обычном отчете о диапазоне значений в банке есть много строк с такими ярлыками, как «Баланс от 0 до 10 долларов», «Баланс от 10,01 до 25 долларов» и т. д. Этот вид отчета динамический,
потому что конкретные заголовки строк определяются во время запроса, а не во
время обработки ETL. Определения строк могут быть реализованы в таблице измерений малых диапазонов значений, которые объединяются с таблицей фактов
с помощью соединений «больше/меньше», либо же могут существовать только
в SQL-операторе CASE. Подход размерности диапазона значений, вероятно, более эффективен, особенно в столбчатой базе данных, потому что подход оператора
CASE включает почти неограниченное сканирование отношений таблицы фактов.
Глава 10. Финансовые услуги, с. 353
Измерение «Текстовые комментарии»
Вместо того чтобы рассматривать комментарии произвольной формы как текстовые метрики в таблице фактов, они должны храниться вне таблицы фактов в отдельном измерении «Комментарии» (или как атрибуты в измерении с одной строкой
на транзакцию, если кардинальность комментариев соответствует количеству уникальных транзакций) с соответствующим внешним ключом в таблице фактов.
Глава 9. Управление персоналом, с. 333
Глава 14. Здравоохранение, с. 419
Обзор методов размерного моделирования Кимбалла
109
Несколько часовых поясов
Чтобы фиксировать как универсальное стандартное время, так и местное время в приложениях с несколькими часовыми поясами, двойные внешние ключи
должны быть помещены в затронутые таблицы фактов, которые объединяются
с двумя ролевыми таблицами измерений дат (и, возможно, времени суток).
Глава 12. Транспортировка, с. 389
Глава 15. Электронная коммерция, с. 437
Измерения типа «Показатель»
Иногда, когда таблица фактов содержит длинный список фактов, который редко
заполняется в какой-либо отдельной строке, возникает соблазн создать измерение типа «Показатель», которое сворачивает строку таблицы фактов до единственного общего факта, идентифицируемого измерением типа «Показатель».
Обычно мы не рекомендуем такой подход. Хотя он удаляет все пустые столбцы фактов, он умножает размер таблицы фактов на среднее количество занятых
столбцов в каждой строке, что значительно усложняет вычисления внутри столбцов. Этот метод приемлем, когда количество потенциальных фактов чрезмерно
(исчисляется сотнями), но совсем немногие случаи применимы к такой строке
таблицы фактов.
Глава 6. Управление заказами, с. 225
Глава 14. Здравоохранение, с. 419
Измерения «Шаг»
Последовательные процессы, такие как события веб-страницы, обычно имеют
отдельную строку в таблице фактов транзакции для каждого шага процесса. Чтобы определить, где отдельный шаг вписывается в общий сеанс, используется измерение «Шаг», показывающее, какой номер шага представлен текущим шагом
и сколько еще шагов потребовалось для завершения.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 15. Электронная коммерция, с. 437
110
Глава 2
Измерения с возможностью горячей замены
Измерения с возможностью горячей замены используются, когда одна и та же
таблица фактов альтернативно соединяется с разными копиями одного и того же
измерения. Например, одна таблица фактов, содержащая котировки акций, может быть одновременно доступна нескольким отдельным инвесторам, и каждый
из них имеет собственные уникальные атрибуты, присваиваемые разным акциям.
Глава 10. Финансовые услуги, с. 353
Абстрактные общие измерения
Некоторых разработчиков моделей данных привлекают абстрактные общие измерения. Например, их схемы включают одно общее измерение местоположения,
а не встроенные географические атрибуты в измерениях «Магазин», «Склад»
и «Клиент». Точно так же их измерение «человек» включает в себя строки для
сотрудников, клиентов и контактов с поставщиками (потому что все они люди)
независимо от того, что для каждого типа собраны существенно разные атрибуты.
В размерных моделях следует избегать абстрактных общих измерений. Наборы атрибутов, связанные с каждым типом, часто различаются. Если атрибуты общие,
например, административные единицы, они должны иметь уникальные метки,
чтобы штат магазина от штата покупателя. Наконец, сведение всего разнообразия
местоположений, людей или продуктов в одно измерение неизменно приводит
к более крупной таблице измерений. Абстракция данных может быть подходящей
для операционной исходной системы или обработки ETL, но она отрицательно
влияет на производительность запросов и четкость в модели измерений.
Глава 9. Управление персоналом, с. 333
Глава 11. Телекоммуникации, с. 371
Измерения «Аудит»
Когда строка таблицы фактов создается в ETL, полезно создать измерение
«Аудит», содержащее известные на момент работы ETL-процессов метаданные. Строка простого измерения «Аудит» может содержать один или несколько основных показателей качества данных, возможно, полученных в результате
изучения схемы событий ошибок, в которой регистрируются нарушения качества данных, обнаруженные при обработке данных. Другие полезные атрибуты
Обзор методов размерного моделирования Кимбалла
111
измерения «Аудит» могут включать в себя переменные среды. Эти среды описывают версии кода ETL, используемые для создания строк фактов или отметок
времени выполнения процесса ETL. Переменные среды особенно полезны для
целей соответствия и аудита, поскольку они позволяют инструментам бизнесаналитики выполнять детализацию, чтобы определить, какие строки с помощью
каких версий программного обеспечения ETL были созданы.
Глава 6. Управление заказами, с. 225
Глава 16. Страхование, с. 461
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Измерения, прибывающие с опозданием
Иногда факты из операционного бизнес-процесса поступают за несколько минут,
часов, дней или недель до соответствующего контекста измерения. Например, в ситуации доставки данных в реальном времени может появиться строка истощения
запасов, показывающая натуральный ключ клиента, совершающего покупку определенного продукта. В системе ETL реального времени эта строка должна быть
записана на уровне BI, даже если личность клиента или продукта не может быть
немедленно определена. В этих случаях создаются строки специальных измерений
с неразрешенными натуральными ключами в качестве атрибутов.
Конечно, эти строки измерений должны содержать стандартные по умолчанию неизвестные значения для большинства описательных столбцов; предположительно, надлежащий контекст измерения последует из источника в более
позднее время. Когда этот контекст измерения в итоге предоставляется, строки
измерения обновляются с перезаписью типа 1. Позднее поступление данных измерения также происходит, когда в атрибуты измерения типа 2 вносятся ретроактивные изменения. В этом случае необходимо вставить новую строку в таблицу
измерений, а затем пересчитать связанные строки фактов.
Глава 14. Здравоохранение, с. 419
Глава 19. Подсистемы и методы ETL, с. 539
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
112
Глава 2
Схемы специального назначения
Следующие паттерны проектирования необходимы для очень специфических
случаев использования.
Схемы супертипа и подтипа для гетерогенных продуктов
Финансовые услуги и другие бизнесы часто предлагают широкий спектр продуктов в разрозненных сферах деятельности. Например, розничный банк может предлагать десятки типов счетов от текущих счетов до ипотечных кредитов
и бизнес-кредитов, но все это примеры счетов. Попытки построить единую консолидированную таблицу фактов с объединением всех возможных фактов, связанных с таблицами измерений со всеми возможными атрибутами всего разнообразия продуктов, потерпят неудачу, поскольку могут быть сотни несовместимых
фактов и атрибутов. Решение состоит в том, чтобы построить единую таблицу
фактов супертипа, в которой пересекаются факты из всех типов счетов (вместе
с таблицей измерений супертипа, содержащей общие атрибуты), а затем систематически создавать отдельные таблицы фактов (и связанные таблицы измерений)
для каждого из подтипов. Таблицы фактов супертипа и подтипа также называются основными и пользовательскими таблицами фактов.
Глава 10. Финансовые услуги, с. 353
Глава 14. Здравоохранение, с. 419
Глава 16. Страхование, с. 461
Таблицы фактов в реальном времени
Таблицы фактов в реальном времени необходимо обновлять чаще, чем более традиционное ночное обновление. Есть много методов для поддержки этого требования в зависимости от возможностей СУБД или куба OLAP, используемых для
окончательного развертывания на уровне отчетов BI. Например, «горячий раздел» может быть определен в таблице фактов, закрепленной в физической памяти.
На этом разделе намеренно не создаются агрегирование и индексы. Другие СУБД
или кубы OLAP могут поддерживать отложенное обновление, которое позволяет
существующим запросам завершиться, но затем выполняет обновления.
Глава 8. Управление взаимоотношениями с клиентами, с. 295
Глава 20. Задачи и процессы разработки и проектирования систем ETL,
с. 601
Обзор методов размерного моделирования Кимбалла
113
Схемы событий ошибок
Для управления качеством данных в хранилище данных требуется комплексная
система проверок или фильтров качества данных, которые тестируют данные
по мере их поступления из исходных систем в платформу BI. Когда модуль проверки качества данных обнаруживает ошибку, это событие записывается в специальной размерной схеме, которая доступна только во внутренней системе ETL.
Эта схема состоит из таблицы фактов событий ошибки, зернистость которой
представляет собой отдельное событие ошибки, и связанной таблицы фактов подробностей события ошибки, зернистость которой представляет собой каждый
столбец в каждой таблице, которая участвует в событии ошибки.
Глава 19. Подсистемы и методы ETL, с. 539
3
Л
Розничные
продажи
учший способ понять принципы размерного моделирования — это проработать серию реальных примеров. Визуализируя реальные кейсы, вы более
эффективно удерживаете в уме конкретные проблемы и решения, чем если бы они
были представлены абстрактно. В этой книге используются тематические исследования различных предприятий, чтобы помочь пройти через особенности вашей
собственной среды и закрепить передовой опыт размерного моделирования.
Чтобы изучить размерное моделирование, прочтите все главы в этой книге,
даже если вы не управляете розничным магазином или не работаете в телекоммуникационной компании. Главы не предназначены для использования в качестве полномасштабных решений для конкретной отрасли или бизнес-функции.
В каждой главе описывается набор паттернов размерного моделирования, которые встречаются практически в каждом виде бизнеса. Университеты, страховые
компании, банки и авиакомпании в равной степени нуждаются в методиках, разработанных в этой главе о розничной торговле. Кроме того, исследование чужого
бизнеса немного освежает голову. Когда вы имеете дело с данными вашей компании, слишком легко позволить историческим сложностям сбить вас с толку.
Выйдя за пределы своей организации, а затем вернувшись с хорошо понятым
принципом дизайна (или двумя), легче запомнить дух этих принципов по мере
того, как вы погружаетесь в сложные детали своего бизнеса.
В главе 3 обсуждаются следующие концепции:
■ четырехэтапный процесс создания размерных моделей;
■ зернистость таблицы фактов;
■ таблицы фактов транзакций;
■ аддитивные, неаддитивные и производные факты;
■ атрибуты измерения, включая индикаторы, числовые дескрипторы и множественные иерархии;
■ измерение «Календарная дата» плюс время дня;
■ причинно-следственные измерения, например продвижение по службе;
116
Глава 3
■ вырожденные измерения, такие как номер квитанции о транзакции;
■ пустые значения в размерной модели;
■ расширяемость размерной модели;
■ таблицы фактов без показателей;
■ суррогатные, натуральные и устойчивые ключи;
■ атрибуты измерений типа «снежинка»;
■ таблицы фактов «сороконожка» со «слишком большим количеством измерений».
Четырехэтапный процесс
размерного проектирования
На протяжении всей книги мы будем подходить к проектированию размерной
модели, последовательно рассматривая четыре шага, которые в следующих разделах обсуждаются более подробно.
Шаг 1: выбор бизнес-процесса
Бизнес-процесс — это низкоуровневая деятельность, выполняемая организацией, например принятие заказов, выставление счетов, получение платежей, обработка служебных звонков, регистрация студентов, выполнение медицинской
процедуры или обработка претензий. Чтобы определить бизнес-процессы вашей
организации, полезно знать несколько общих характеристик:
1. Бизнес-процессы часто выражаются как глаголы действий, поскольку они
представляют деятельности, которые выполняет бизнес. Сопутствующие
измерения дают описательный контекст, связанный с каждым событием
бизнес-процесса.
2. Бизнес-процессы, как правило, поддерживаются операционной системой,
такой как система выставления счетов или закупок.
3. Бизнес-процессы генерируют или производят ключевые показатели производительности. Иногда метрики — это прямой результат бизнес-процесса,
а иногда метрики — это производные. Аналитики неизменно хотят тщательно изучить и оценить эти показатели, казалось бы, безграничным сочетанием фильтров и ограничений.
4. Бизнес-процессы обычно начинаются со входных метрик и приводят к выходным метрикам. Во многих организациях существует ряд процессов,
в которых выходы из одного процесса становятся входами к следующему.
На языке разработчика размерной модели эта серия процессов приводит
к нескольким таблицам фактов.
Розничные продажи
117
Вы должны внимательно прислушиваться к бизнесу, чтобы определить бизнес-процессы организации, потому что бизнес-пользователи не могут легко ответить на вопрос: «Какой бизнес-процесс вас интересует?» Пользователи метрик
производительности хотят анализировать в системе DW/BI результаты событий
бизнес-процессов.
Иногда бизнес-пользователи говорят о стратегических бизнес-инициативах,
а не о процессах, связанных с бизнесом. Эти инициативы, как правило, — всеобъемлющие корпоративные планы, отстаиваемые исполнительным руководством для обеспечения конкурентных преимуществ. Чтобы привязать
бизнес-инициативу к бизнес-процессу, представляющему собой единицу работы размером с проект для команды DW/BI, необходимо разложить бизнесинициативу на базовые процессы. Это означает копать немного глубже, чтобы
понять данные и операционные системы, которые поддерживают аналитические
требования инициативы.
Также стоит отметить, что организационные отделы бизнеса или функции
не приравниваются к бизнес-процессам. Сосредоточив внимание на процессах,
а не на функциональных отделах, вы получите последовательную информацию
обо всей организации, затратив намного меньше сил. При проектировании размерной модели, основанной на отделах, данные с различными метками и значениями данных неизбежно дублируются. Лучший способ обеспечить согласованность — опубликовать данные один раз.
Шаг 2: объявление зернистости
Объявление зернистости означает точное указание того, что представляет собой
отдельная строка таблицы фактов. Зернистость передает уровень детализации,
связанный с показателями таблицы фактов. В нем содержится ответ на вопрос:
«Как вы описываете одну строку в таблице фактов?» Зернистость определяется физическими реалиями операционной системы, которая фиксирует события
бизнес-процесса.
Пример определения зернистости включает в себя:
■ одна строка на каждый продукт в операции по продаже клиенту;
■ одна строка на строку пункта в счете от врача;
■ одна строка на индивидуальный посадочный талон, отсканированный
у выхода на посадку в аэропорту;
■ одна строка на остаток каждого товара на складе;
■ одна строка на каждый банковский счет каждый месяц.
Эта зернистость выражена в терминах бизнеса. Возможно, вы ожидали, что
зернистость станет традиционной декларацией первичного ключа таблицы
118
Глава 3
фактов. Хотя зернистость в итоге эквивалентна первичному ключу, было бы
ошибкой перечислить набор измерений, а затем предположить, что этот список
и есть определение зернистости. По возможности вы должны выразить зернистость в терминах бизнеса.
Создатели размерных моделей иногда пытаются обойти этот, казалось бы, ненужный шаг четырехэтапного процесса проектирования. Пожалуйста, не надо
так делать. Объявление зернистости — критический шаг, к которому нельзя относиться легкомысленно. После отладки тысяч размерных моделей на протяжении многих лет я знаю, что наиболее частая ошибка — необъявление зернистости таблицы фактов в начале проектирования. Если зернистость не определена
четко, весь дизайн строится на зыбучих песках; дискуссии о возможных параметрах ходят по кругу, и ложные факты проникают в дизайн.
Неподходящая зернистость преследует реализацию DW/BI! Чрезвычайно
важно, чтобы все члены проектной группы достигли согласия в отношении детализации таблицы фактов. Определив ее, вы можете обнаружить в шагах 3 или 4
процесса проектирования, что зернистость была выбрана неверно. Это нормально, но тогда вы должны вернуться к шагу 2, определить зерно заново и повторить
шаги 3 и 4.
Шаг 3: определение измерений
Измерения — это ответ на вопрос: «Как деловые люди описывают данные,
полученные в результате событий измерения бизнес-процессов?» Вам нужно
украсить таблицы фактов набором измерений, представляющих все возможные
описания, которые берут на себя отдельные значения в контексте каждой метрики. Если вы четко определили зернистость, размеры, как правило, можно легко
определить, поскольку они представляют «кто, что, где, когда, почему и как»,
связанные с событием. Примеры распространенных измерений включают дату,
продукт, клиента, сотрудника и оборудование. При выборе каждого измерения
вы перечислите все дискретные текстовые атрибуты, которые конкретизируют
каждую таблицу измерений.
Шаг 4: определение фактов
Факты определяются ответом на вопрос: «Каков процесс измерения?» Бизнес-пользователи очень заинтересованы в анализе этих показателей производительности. Все факты в проекте должны быть верны зернистости, определяемой
в шаге 2. Факты, которые явно принадлежат к другой зернистости, должны быть
в отдельной таблице фактов. Типичные факты — это числовые величины, которую можно складывать, например количество заказов или сумма стоимости
в долларах.
Розничные продажи
119
Вы должны учитывать как требования ваших бизнес-пользователей, так
и реалии ваших исходных данных в тандеме, чтобы принимать решения относительно четырех шагов, как показано на рис. 3-1. Мы настоятельно рекомендуем вам не поддаваться искушению моделировать данные, глядя на исходные
данные в одиночку. Погрузиться в данные может быть менее пугающим, чем
интервью с представителем бизнеса; однако данные не заменят информацию
от бизнес-пользователей. К сожалению, многие организации пытались использовать этот подход, основанный на наименьшем сопротивлении, но без особого
успеха.
Бизнес-требования
Размерная модель
Бизнес-процессы
Зернистость
Измерения
Факты
Реалии данных
Рис. 3-1. Основной вклад в четырехэтапный процесс размерного
проектирования
Пример использования
в розничной торговле
Начнем с краткого описания розничного бизнеса, использованного в этом примере. Мы начинаем с этой отрасли просто потому, что она всем нам знакома.
Но паттерны, обсуждаемые в контексте этого тематического исследования, актуальны практически для каждой размерной модели независимо от отрасли.
Представьте, что вы работаете в штаб-квартире крупной сети продуктовых
магазинов. У компании 100 продуктовых магазинов в пяти штатах. В каждом магазине есть полный набор отделов, включая бакалейные товары, замороженные
продукты, молочные продукты, мясо, хлебобулочные изделия, средства для ухода
за полостью рта и косметические средства. В каждом магазине на полках находится примерно 60 000 отдельных товаров, называемых товарными позициями
(SKU — stock keeping units).
Данные собираются в нескольких местах продуктового магазина. Часть
из наиболее полезных данных собирается на кассах по мере того, как клиенты
покупают товары. Система терминалов (POS) сканирует штрихкоды продуктов
на кассовом аппарате, измеряя потребительский вынос у входной двери продуктового магазина, как показано на кассовом чеке на рис. 3-2. Другие данные собираются с черного хода магазина, где поставщики осуществляют доставку.
120
Глава 3
Allstar Grocery
Лун-стрит, 123
Зеленая прерия, Миннесота 55555
(952) 555–1212
Store: 0022
Cashier: 00245409/Alan
0030503347 Мультизерновые маффины
2,50
2120201195 Диетическая кола, 12 шт.
СКИДКА $0,50 с $5,49
4,99
0070806048 Зубная паста Sparkly
КУПОН $0,30 с $2,29
1,99
2840201912 Пакет соевого молока
3,19
ИТОГ
12,67
ПОЛУЧЕНО
НАЛИЧНЫМИ
12,67
КОЛИЧЕСТВО ТОВАРОВ:
Транзакция: 649
4
15.04.2013 10:56
Спасибо за покупку в Allstar
0064900220415201300245409
Рис. 3-2. Образец кассового чека
В продуктовом магазине менеджмент занимается логистикой заказов, хранением и продажей продуктов для максимального увеличения прибыли. В итоге
прибыль достигается за счет максимально возможной платы за каждый продукт,
снижения затрат на приобретение продукта и накладных расходов и в то же время привлечения как можно большего числа клиентов в условиях жесткой конкуренции. Некоторые из наиболее важных управленческих решений связаны
с ценообразованием и рекламными акциями. Как руководство магазина, так
и отдел маркетинга в штаб-квартире тратят много времени на корректировку цен
и рекламных акций. Промоакции в продуктовом магазине включают временное
снижение цен, рекламу в газетах и газетные вставки, специальные полки в продуктовом магазине и купоны. Самый прямой и эффективный способ увеличить
Розничные продажи
121
объем проданной продукции — резко снизить цену. Снижение цены на бумажные полотенца на 50 центов, особенно в сочетании с рекламой и выставлением упаковок на специальные полки, может привести к увеличению продаж бумажных полотенец в 10 раз. К сожалению, такое большое снижение цен обычно
не оправдано, потому что полотенца, вероятно, продаются в убыток. В результате
этих проблем наглядность всех форм продвижения — важная часть анализа работы продуктового магазина.
Теперь, когда мы описали наш бизнес-пример, мы приступим к проектированию размерной модели.
Шаг 1: выбор бизнес-процесса
Первый шаг в разработке — решение, какой бизнес-процесс моделировать, сочетая понимание бизнес-требований с пониманием имеющихся исходных данных.
ПРИМЕЧАНИЕ Первый проект DW/BI должен быть сфокусирован на биз-
нес-процессе, который как наиболее важен для бизнес-пользователей, так и наиболее осуществим. Осуществимость охватывает ряд соображений, включая доступность и качество данных, а также организационную готовность.
В нашем исследовании розничной торговли руководство хочет лучше понять
покупки клиентов, зафиксированные в POS-системе. Таким образом, бизнеспроцесс, который вы моделируете, — это транзакции розничных продаж через
кассовые терминалы. Эти данные позволяют бизнес-пользователям анализировать, какие продукты продаются в каких магазинах, в какие дни, на каких рекламных условиях и в каких транзакциях.
Шаг 2: объявление зернистости
После того как бизнес-процесс определен, команда разработчиков принимает
серьезное решение о степени зернистости. Какой уровень детализации данных
должен быть доступен в размерной модели?
Работа с данными на самом низком атомарном уровне имеет смысл по многим
причинам. Атомарные данные очень многомерны. Чем более подробные и атомарные показатели метрики фактов, тем больше вы знаете наверняка. Все, что вы
знаете наверняка, трансформируется в измерения. В этом отношении атомарные
данные идеально подходят для пространственного подхода.
Атомарные данные обеспечивают максимальную аналитическую гибкость,
поскольку их можно фильтровать и сворачивать всеми возможными способами. Атомарные данные в размерной модели готовы к атаке случайных запросов
со стороны бизнес-пользователей.
122
Глава 3
ПРИМЕЧАНИЕ Вам следует разрабатывать размерные модели, представляю-
щие наиболее подробную, атомарную информацию, полученную в ходе бизнеспроцесса.
Конечно, вы можете объявить более обобщенную зернистость, представляющую агрегирование атомарных данных. Однако, как только вы выбираете зернистость более высокого уровня, вы ограничиваете себя меньшим количеством
измерений и/или потенциально менее детализированными измерениями. Менее детализированная модель сразу становится уязвимой для неожиданных
запросов пользователей, которые опираются на детализацию. Пользователи
неизбежно сталкиваются с аналитической стеной, когда им не предоставляется
доступ к атомарным данным. Хотя агрегированные данные играют важную роль
для настройки производительности, они не заменяют предоставление пользователям доступа к деталям самого нижнего уровня; пользователи могут легко
суммировать атомарные данные, но неспособны извлечь детали из сводных данных. К сожалению, некоторые отраслевые эксперты по-прежнему недоумевают
по этому поводу. Они утверждают, что размерные модели подходят только для
обобщенных данных, а затем критикуют подход размерного моделирования
за его предполагаемую необходимость предвидеть бизнес-вопрос. Это недоразумение уходит, когда в размерной модели становятся доступны подробные
атомарные данные.
В нашем примере наиболее детализированные данные — это отдельный продукт в транзакции POS. Предполагается, что система POS объединяет все продажи для данного продукта в корзине покупок в одну позицию. Хотя пользователи,
вероятно, не заинтересованы в анализе отдельных элементов, связанных с конкретной транзакцией POS, вы не можете предсказать все способы, которыми они
захотят использовать эти данные. Например, они могут захотеть понять разницу
в продажах в понедельник и в воскресенье. Или оценить, стоит ли иметь в наличии так много отдельных размеров определенных брендов. Или понять, сколько
покупателей воспользовались скидкой 50 центов на шампунь. Или определить
влияние снижения продаж, когда активно продвигался конкурентоспособный
диетический газированный напиток. Хотя ни один из этих запросов не требует
данных из одной конкретной транзакции, это общие вопросы, требующие точного сечения подробных данных. Ни на один из этих вопросов нельзя было бы ответить, если бы вы решили предоставить доступ только к обобщенным данным.
ПРИМЕЧАНИЕ Система DW/BI почти всегда требует данных, выраженных
с наименьшей возможной зернистостью не потому, что запросы хотят видеть
отдельные строки, а потому, что запросы должны очень точно учитывать детали.
Розничные продажи
123
Шаг 3: определение измерений
После того как зернистость таблицы фактов выбрана, выбор измерений становится простым. Товар и транзакция, — это очевидно сразу. В рамках основных
измерений вы можете спросить, можно ли отнести другие измерения к измерениям POS, например дату продажи, магазин, в котором была совершена распродажа, рекламная акция, в рамках которой продается продукт, кассир, который
занимался продажей и, возможно, способ оплаты. Мы выражаем это как еще
один принцип дизайна.
ПРИМЕЧАНИЕ Тщательная формулировка зернистости определяет первич-
ную размерность таблицы фактов. Затем вы добавляете дополнительные измерения в таблицу фактов, если эти измерения естественным образом принимают только одно значение при каждой комбинации основных измерений. Если
дополнительное измерение нарушает зернистость, вызывая генерацию дополнительных строк фактов, измерение необходимо отбросить или пересмотреть
формулировку зернистости.
К делу относятся следующие описательные измерения: дата, продукт, магазин,
промоакция, кассир и способ оплаты. Кроме того, номер чека POS включен в качестве специального измерения, как описано в разделе «Вырожденные измерения для номеров транзакций» далее в этой главе.
Прежде чем дополнить таблицы измерений описательными атрибутами, давайте завершим последний шаг четырехэтапного процесса. На этом этапе проектирования не стоит допускать ситуацию, когда за деревьями вы не видите леса.
Шаг 4: определение фактов
Четвертый и последний шаг в разработке — это тщательное определение того,
какие факты появятся в таблице фактов. Опять же, объявление зернистости помогает вам принять это решение. Проще говоря, факты должны быть точными,
в нашем случае это отдельная позиция продукта в транзакции POS. При рассмотрении потенциальных фактов вы снова можете обнаружить, что необходимо
внести поправки либо в ваши предыдущие предположения о зернистости, либо
в выбор измерений.
Факты, собираемые POS-системой, включают объем продаж (например,
количество банок куриного супа с лапшой), обычные цены за единицу, скидки
и чистую оплату, а также расширенные скидки и суммы продаж в долларах. Сумма продаж в долларах равна количеству продаж, умноженному на чистую цену
за единицу. Аналогичным образом сумма расширенной скидки в долларах — это
124
Глава 3
объем продаж, умноженный на сумму скидки за единицу. Некоторые сложные
POS-системы также предоставляют стандартную стоимость продукта в долларах,
поставляемого продавцом в магазин. Предполагая, что этот факт о стоимости
легко доступен и не требует инициативы по оценке затрат и героических действий, вы можете включить расширенную сумму затрат в таблицу фактов. Таблица фактов начинает обретать форму на рис. 3-3.
Таблица фактов розничных продаж
Измерение «Дата»
Измерение «Магазин»
Измерение «Кассир»
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Ключ промоакции (FK)
Ключ кассира (FK)
Ключ способа оплаты (FK)
№ POS-транзакции (DD)
Количество продаж
Обычная цена за единицу
Цена со скидкой
Чистая цена за единицу
Сумма расширенной скидки в
долларах
Сумма расширенных продаж
в долларах
Сумма расширенных затрат
в долларах
Расширенная сумма валовой
прибыли в долларах
Измерение «Продукт»
Измерение «Промоакция»
Измерение «Метод оплаты»
Рис. 3-3. Измеряемые факты в схеме розничных продаж
Четыре факта (объем продаж и расширенная скидка, продажи и суммы в долларах) прекрасно аддитивно суммируются по всем измерениям. Вы можете безнаказанно разрезать таблицу фактов по атрибутам измерения, и каждая сумма
этих четырех фактов действительна и верна.
Производные факты
Вы можете вычислить валовую прибыль, вычтя сумму расширенных затрат в долларах из суммы расширенных продаж или дохода в долларах. Вычисленная валовая прибыль также прекрасно складывается по всем измерениям; вы можете рассчитать валовую прибыль любой комбинации продуктов, продаваемых в любом
наборе магазинов за любой набор дней. Разработчики размерных моделей иногда
сомневаются, должен ли рассчитанный производный факт храниться в базе данных. Как правило, мы рекомендуем хранить его физически. В нашем примере
расчет валовой прибыли прост, но его хранение означает, что он вычисляется
Розничные продажи
125
последовательно в процессе ETL, исключая возможные ошибки вычислений
пользователя. Стоимость неправильно представленной валовой прибыли перевешивает незначительные дополнительные затраты на хранение. Хранение также
гарантирует, что все пользователи и приложения для отчетности BI будут последовательно ссылаться на валовую прибыль.
Поскольку валовая прибыль может быть рассчитана из соседних данных
в пределах одной строки таблицы фактов, некоторые утверждают, что вы должны выполнить расчет в представлении, которое неотличимо от таблицы. Это
разумный подход, если все пользователи получают доступ к данным через представление, и ни один из пользователей с помощью специальных инструментов
запроса не может прокрасться мимо представления и получить доступ к таблице
напрямую. Представления — разумный способ минимизировать ошибку пользователя при экономии на хранении, но DBA не должен допускать никаких исключений для доступа к данным через представление. Аналогичным образом некоторые организации хотят выполнять расчеты в инструменте BI. Опять же, это
работает, если все пользователи получают доступ к данным с помощью общего
инструмента, что бывает редко, по нашему опыту. Однако иногда неаддитивные
метрики в отчете, такие как проценты или коэффициенты, должны быть вычислены в приложении BI, поскольку расчет не может быть предварительно произведен и сохранен в таблице фактов. OLAP кубы выигрывают в таких ситуациях.
Неаддитивные факты
Валовая маржа может быть рассчитана путем деления валовой прибыли на расширенный доход от продаж в долларах. Валовая маржа — неаддитивный факт,
поскольку она не может быть суммирована по любому измерению. Вы можете
рассчитать валовую маржу любого набора продуктов, магазинов или дней, не забывая суммировать доходы и затраты соответственно перед делением.
ПРИМЕЧАНИЕ Проценты и коэффициенты, такие как валовая маржа, —
это неаддитивные факты. Числитель и знаменатель должны храниться в таблице фактов. Соотношение может быть рассчитано в инструменте BI для любого
фрагмента таблицы фактов, только помните, что нужно рассчитывать соотношение сумм, а не сумму соотношений.
Цена единицы — еще один неаддитивный факт. В отличие от расширенных
сумм в таблице фактов, суммирование цены единицы в любом из измерений
приводит к бессмысленному, ничего не значащему числу. Рассмотрим простой
пример: вы продали один виджет по цене единицы $1,00 и четыре виджета
по цене единицы 50 центов каждый. Вы можете подвести итоги продаж, чтобы
126
Глава 3
определить, что пять виджетов были проданы. Точно так же вы можете подвести итоги продаж в долларовой сумме ($1,00 и $2,00), чтобы прийти к общей
сумме продаж $3,00. Тем не менее вы не можете суммировать цены единиц товара ($1,00 и 50 центов) и объявить, что общая цена единицы составляет $1,50.
Аналогичным образом вы не должны объявлять, что средняя цена единицы
составляет 75 центов. Правильно взвешенная средняя цена единицы должна
быть вычислена путем взятия общей суммы продаж ($3,00) и делением ее на общее количество (пять виджетов), то есть вы придете к средней цене единицы
в 60 центов. Вы никогда не придете к такому выводу, глядя на цену единицы для
каждой строки транзакции в изоляции. Чтобы проанализировать среднюю цену,
необходимо сложить цены продаж и объемы продаж, прежде чем разделить общий объем долларов на общее количество проданных товаров. К счастью, многие
инструменты BI выполняют эту функцию правильно.
Некоторые сомневаются в том, что неаддитивные факты должны физически
храниться в таблице фактов. Это законный вопрос, учитывая их ограниченную
аналитическую ценность помимо вывода отдельных значений в отчете или применения фильтра непосредственно на факт, что нетипично в обоих случаях. В некоторых ситуациях принципиально неаддитивные факты, такие как температура, предоставляются исходной системой. Эти неаддитивные факты могут быть усреднены
по многим записям, если бизнес-аналитики придут к выводу, что это имеет смысл.
Таблицы фактов транзакций
Наиболее распространены транзакционные бизнес-процессы. Таблицы фактов,
представляющие эти процессы, имеют несколько характеристик:
1. Зернистость таблиц фактов атомарных транзакций может быть кратко выражена в контексте транзакции, например, одна строка на транзакцию или
одна строка на строку транзакции.
2. Поскольку эти таблицы фактов записывают события транзакций, они зачастую заполнены довольно редко. В нашем примере мы, конечно, не будет
продавать каждый продукт в отдельной корзине.
3. Хотя таблицы фактов транзакций непредсказуемо заполняются и редко
имеют заполненными все атрибуты, они могут быть поистине огромными.
Большинство таблиц объемом в миллиарды и триллионы строк в хранилище данных — это таблицы фактов транзакций.
4. Таблицы фактов транзакций, как правило, имеют множество измерений.
5. Метрики, возникающие в результате транзакционных событий, обычно аддитивные, поскольку происходит их увеличение на количественную величину, а не новая фиксация метрики на единицу измерения.
Розничные продажи
127
На этом раннем этапе проектирования часто полезно оценить количество
строк в самой большой таблице — таблице фактов. В нашем примере, возможно,
будет достаточно разговора с экспертом по исходной системе, чтобы понять, какое количество продаж генерируется POS (Point of Sales) системой на периодической основе. Розничный трафик значительно колеблется изо дня в день, поэтому вы должны понимать течение разумного периода времени. Кроме того, можно
оценить количество строк, ежегодно добавленных в таблицу фактов, разделив годовой валовой доход сети на среднюю цену продажи товара. Если предположить,
что валовая выручка составляет $4 млрд в год и что цена товара на чеке клиента
составляет $2,00, можно подсчитать, что в год создается около 2 млрд строк транзакций. Это типичная инженерная оценка, которая на удивление приближает вас
к решениям по дизайну системы, и для этого даже не пришлось вставать из вашего кресла. Как разработчики, вы всегда должны задаваться вопросом, разумны ли
ваши расчеты.
Подробная информация о таблице измерений
Теперь, когда мы прошли через четырехэтапный процесс, давайте вернемся к таблицам измерений и сосредоточимся на заполнении их надежными атрибутами.
Измерение «Дата»
Измерение «Дата» — особое измерение, потому что оно единственное, которое
почти гарантированно присутствует в каждой размерной модели, ведь практически каждый бизнес-процесс фиксирует временные метки показателей производительности. Фактически дата — это обычно первое измерение в основной схеме
разделения базы данных, так что последовательные загрузки данных за интервал
времени помещаются на нетронутый раздел на диске.
Для читателей первого издания книги это измерение было названо измерением «Время». Однако на протяжении более десяти лет мы использовали измерение «Дата» для обозначения таблицы измерений, где зернистость составляет
1 день. Это помогает различать измерения «Дата» и «Время суток».
В отличие от большинства других измерений вы можете заранее построить
таблицу измерения «Дата». Вы можете поместить в таблицу строки, покрывающие даты настолько давние, как 10 или 20 лет назад, представляющие отдельные
дни, чтобы вы могли охватить историю, которую вы хранили, а также несколько
лет в будущем. Даже 20-летний срок — это всего лишь примерно 7300 строк,
то есть относительно небольшая таблица измерений. Для таблицы измерений
«Дата» в среде розничной торговли мы рекомендуем неполный список столбцов, показанный на рис. 3-4.
128
Глава 3
Измерение даты
Ключ даты (PK)
Дата
Полное описание даты
День недели
Номер дня в календарном месяце
Номер дня в календарном году
Номер дня в финансовом месяце
Номер дня в финансовом году
Индикатор последнего дня месяца
Дата окончания календарной недели
Номер календарной недели в году
Названия месяцев календаря
Календарный номер месяца в году
Календарный год — месяц (ГГГГ-ММ)
Календарный квартал
Календарный год — квартал
Календарный год
Финансовая неделя
Номер финансовой недели в году
Финансовый месяц
Номер финансового месяца в году
Финансовый год — месяц
Финансовый квартал
Финансовый год — квартал
Финансовое полугодие
Финансовый год
Индикатор праздника
Индикатор дня недели
Отметка даты SQL
…
Рис. 3-4. Таблица измерения «Дата»
Каждый столбец в таблице измерения даты определяется конкретным днем,
который представляет строка. Столбец дня недели содержит название дня, например понедельник (Monday). Этот столбец будет использоваться для создания
отчетов, в которых сравниваются дела в рабочие дни и выходные. Номер дня
в столбце календарного месяца начинается с 1 в начале каждого месяца и длится
до 28, 29, 30 или 31 в зависимости от месяца. Этот столбец полезен для сравнения одного и того же дня каждого месяца. Точно так же у вас может быть номер
месяца в году (1…12). Все эти целые числа поддерживают простую арифметику
дат в пределах года и месяца.
Для отчетности вы должны включать как длинные, так и сокращенные названия меток. Например, вам может понадобиться атрибут имени месяца
Розничные продажи
129
со значениями, такими как «январь» ( January). Кроме того, столбец «год — месяц» (ГГГГ-ММ) полезен в качестве заголовка столбца отчета. Вероятно, вам
также понадобится номер квартала (К1, …, К4), а также «год — квартал», например, 2013-К1. Вы должны включить аналогичные столбцы для финансовых
периодов, если они отличаются от календарных периодов. Примеры строк, содержащих несколько столбцов с датами, показаны на рис. 3-5.
Ключ
даты
Дата
20130101 01/01/2013
20130102 01/02/2013
20130103 01/03/2013
20130104 01/04/2013
20130105 01/05/2013
20130106 01/06/2013
20130107 01/07/2013
20130108 01/08/2013
Описание
полной даты
День
недели
Календ.
месяц
Календ.
квартал
1 января 2013
2 января 2013
3 января 2013
4 января 2013
5 января 2013
6 января 2013
7 января 2013
8 января 2013
Вторник
Среда
Четверг
Пятница
Суббота
Воскресенье
Понедельник
Вторник
Январь
Январь
Январь
Январь
Январь
Январь
Январь
Январь
К1
К1
К1
К1
К1
К1
К1
К1
Календ. Финансовый Индикатор Индикатор
год
год-месяц
праздника буднего дня
2013
2013
2013
2013
2013
2013
2013
2013
F2013-01
F2013-01
F2013-01
F2013-01
F2013-01
F2013-01
F2013-01
F2013-01
Празд.
Непразд.
Непразд.
Непразд.
Непразд.
Непразд.
Непразд.
Непразд.
Будний
Будний
Будний
Будний
Будний
Будний
Будний
Будний
Рис. 3-5. Строки образца измерения даты
ПРИМЕЧАНИЕ Пример измерения «Дата» дост упен на сайте
www.kimballgroup.com на вкладке Tools and Utilities под названием этой книги.
Некоторые разработчики тут останавливаются, чтобы спросить, зачем нужна явная таблица измерений даты. Они считают, что если ключ даты в таблице
фактов — это столбец типа даты, то любой запрос SQL может напрямую ограничить ключ даты таблицы фактов и использовать естественную семантику даты
SQL для фильтрации по месяцу или году, избегая при этом предположительно
дорогостоящего объединения таблиц. Это рассуждение не выдерживает критики по нескольким причинам. Так, если ваша реляционная база данных не может
обеспечить эффективное соединение с таблицей измерения даты, у вас большие
проблемы. Большинство оптимизаторов баз данных довольно эффективно выполняют запросы по размерным моделям; необязательно избегать операторов
join как чумы.
Поскольку средний бизнес-пользователь не разбирается в семантике дат SQL,
он не сможет написать запрос, группирующий данные по частям даты. Функции
даты SQL не поддерживают фильтрацию по таким атрибутам, как рабочие дни
недели по сравнению с выходными, праздниками, финансовые периоды или
времена года. Если предположить, что бизнесу необходимо разрезать данные
по этим нестандартным атрибутам даты, тогда явная таблица измерений даты
имеет важное значение. Логика календаря находится в таблице измерений,
а не в коде приложения.
130
Глава 3
ПРИМЕЧАНИЕ Для размерных моделей всегда требуется явная таблица из-
мерения «Дата». Есть много атрибутов даты, не поддерживаемых функцией
даты SQL, включая номера недель, финансовые периоды, сезоны, праздники
и выходные. Вместо того чтобы пытаться определить эти нестандартные календарные вычисления в запросе, вам следует искать их в таблице измерения
«Дата».
Флаги и индикаторы как текстовые атрибуты
Как и многие операционные флаги и индикаторы, индикатор выходного для измерения «Дата» представляет собой простой индикатор с двумя возможными
значениями. Поскольку атрибуты таблицы измерений служат в качестве меток
отчетов и значений в раскрывающихся списках фильтров запросов, этот индикатор должен быть заполнен значимыми значениями, такими как «Праздничный»
или «Будний», вместо загадочных Д/Н, 1/0 или Истина/Ложь. Как показано
на рис. 3-6, представьте себе отчет, в котором сравниваются продажи продукта
в праздничные и будние дни. Более значимые значения домена для этого индикатора переводятся в более значимый, не требующий пояснений отчет. Вместо того
чтобы декодировать флаги в понятные метки в приложении бизнес-аналитики,
мы предпочитаем хранить декодированные значения в базе данных постоянно
доступными для всех пользователей независимо от их среды отчетов или инструментов бизнес-аналитики.
Ежемесячные продажи
Ежемесячные продажи
Период:
Продукт:
Период:
Продукт:
Индикатор
праздника
Н
Д
июнь 2013
Baked Well Sourdough
Сумма продаж
в долларах
1009
6298
ИЛИ
Индикатор
праздника
июнь 2013
Baked Well Sourdough
Сумма продаж
в долларах
Праздничный
Непраздничный
6298
1009
Рис. 3-6. Примеры отчетов с загадочными и текстовыми индикаторами
Аналогичный аргумент верен для индикатора буднего дня, который имел бы
значение «Рабочий» или «Выходной». Субботам и воскресеньям, очевидно, будет присвоено значение выходных. Конечно, несколько атрибутов таблицы дат
могут быть фильтроваться совместно, поэтому вы можете легко сравнить выходные и праздничные дни с будними днями.
Розничные продажи
131
Атрибуты текущей и относительной даты
Большинство атрибутов измерения «Дата» не подлежат обновлению. 1 июня
2013 года всегда будет превращаться в июнь, второй квартал 2013 года. Однако к базовому измерению даты можно добавить атрибуты, которые будут меняться со временем, включая IsCurrentDay, IsCurrentMonth,
IsPrior60Days и т. д. Очевидно, что IsCurrentDay (текущая дата) нужно
обновлять каждый день; атрибут полезен для создания отчетов, которые всегда
запускаются на сегодняшний день. Следует учитывать один нюанс — это день,
к которому относится IsCurrentDay. Большинство хранилищ данных загружают данные ежедневно, поэтому IsCurrentDay будет относиться ко вчерашнему дню (или, точнее, к последнему загруженному дню). Вы также можете добавить атрибуты к измерению «Дата», уникальные для вашего корпоративного
календаря, например IsFiscalMonthEnd (конец финансового месяца).
Некоторые измерения «Дата» включают обновленные атрибуты запаздывания. Столбец дня задержки примет значение 0 для сегодняшнего дня, –1 для
вчерашнего, +1 для завтрашнего и т. д. Этот атрибут может быть вычисляемым
столбцом, а не физически сохраненным. Может быть полезно настроить аналогичные структуры для месяца, квартала и года. Многие инструменты бизнесаналитики включают в себя функции для выполнения расчетов за предыдущий
период, поэтому в этих столбцах с задержкой, может быть, нет необходимости.
Время дня как измерение или факт
Хотя дата и время объединяются в рабочую метку даты/времени, время дня
обычно отделяется от измерения даты, чтобы избежать увеличения количества
строк в измерении даты. Как отмечалось ранее, измерение «Дата» с 20-летней
историей содержит примерно 7300 строк. Если вы измените зернистость этого
измерения на одну строку в минуту в день, у вас будет более 10 миллионов строк,
чтобы вместить 1440 минут в день. Если вы отследите время до секунды, у вас
будет более 31 миллиона строк на год! Поскольку измерение «Дата», вероятно,
наиболее часто используемое при запросах измерение в схеме, оно должно быть
как можно меньшим и как можно более управляемым.
Если вы хотите отфильтровать или объединить периоды на основе суммированных групп частей дня, таких как активность в течение 15-минутных интервалов, часы, смены, обеденный перерыв или прайм-тайм, время дня будет рассматриваться как полноценная таблица измерений с одной строкой на дискретный
период времени, например одна строка в минуту в течение 24-часового периода.
В результате получается измерение с 1440 строками.
Если нет необходимости сводить или фильтровать группировки по времени
суток, время дня следует обрабатывать как простой факт даты/времени в таблице
132
Глава 3
фактов. Кстати, бизнес-пользователей часто больше интересуют временные задержки, такие как продолжительность транзакции, а не дискретное время начала и окончания. Запаздывание по времени можно легко вычислить, взяв разницу
между отметками даты и времени. Эти отметки даты/времени также позволяют
приложению определять временной интервал между двумя интересующими транзакциями, даже если эти транзакции существуют в разные дни, месяцы или годы.
Измерение «Продукт»
Измерение «Продукт» описывает каждый артикул в продуктовом магазине.
Хотя в обычном магазине может храниться 60 000 артикулов, при учете различных схем мерчандайзинга и продуктов, которые больше не продаются, измерение «Продукт» может иметь 300 000 или более строк. Измерение «Продукт»
почти всегда строится из операционного мастер-файла продуктов. Большинство
розничных продавцов администрируют свой мастер-файл продуктов в штабквартире и через определенные промежутки времени загружают подмножество
в POS-систему каждого магазина. Штаб-квартира отвечает за определение соответствующей мастер-записи продукта (и уникального номера SKU — артикула)
для каждого нового продукта.
Сглаживание иерархий «многие к одному»
Измерение «Продукт» представляет собой множество описательных атрибутов
каждой позиции (товара). Иерархия товаров — важная группа атрибутов. Обычно отдельные артикулы объединяются в бренды, бренды объединяются в категории, а категории объединяются в отделы. Каждый из них — это отношение
«многие к одному». Иерархия товаров и дополнительные атрибуты показаны
для подмножества товаров на рис. 3-7.
Ключ
продукта Описание товара
1
2
3
4
5
6
7
8
9
Свежий хлеб на закваске
Цельнозерновой батон
Цельнозерновой батон в нарезке
Мини-булочки с корицей
Ванильное диетическое, 2 кг
Легкое ореховое, 500 г
Шоколадное, 1 кг
Клубничное кремовое, 500 г
Сэндвич с мороженым
Описание Содержание
жиров
отдела
Описание
бренда
Описание
подкатегории
Описание
категории
Baked Well
Fluffy
Fluffy
Light
Coldpack
Freshlike
Frigid
Icy
Icy
Свежее
В упаковке
В упаковке
В упаковке
Мороженое
Мороженое
Мороженое
Мороженое
Новинки
Выпечка Пониженное
Хлеб
Выпечка Обычное
Хлеб
Выпечка Пониженное
Хлеб
Кондитерские изделия Выпечка Отсутствуют
Замороженные десерты Заморозка Отсутствуют
Замороженные десерты Заморозка Пониженное
Замороженные десерты Заморозка Обычное
Замороженные десерты Заморозка Обычное
Замороженные десерты Заморозка Обычное
Рис. 3-7. Образцы строк измерения продукта
Для каждого артикула четко определены все уровни иерархии товаров. Некоторые атрибуты, такие как описание SKU, уникальны. В этом случае в столбце
Розничные продажи
133
описания артикула 300 000 различных значений. С другой стороны, существует
только 50 различных значений атрибута отдела. Таким образом, в среднем есть
6000 повторений каждого уникального значения в атрибуте отдела. Это вполне
приемлемо! Вам не нужно выделять эти повторяющиеся значения во вторую нормализованную таблицу для экономии места. Помните, что требования к табличным пространствам измерений бледнеют по сравнению с требованиями к табличным пространствам фактов.
ПРИМЕЧАНИЕ Сохранение повторяющихся значений низкой кардинально-
сти в таблице первичных измерений — фундаментальный метод размерного моделирования. Нормализация этих значений в отдельные таблицы сводит на нет
основные цели простоты и производительности, как обсуждается в разделе
«Сопротивление требованиям нормализации» далее в этой главе.
Измерение продукта
Ключ продукта (PK)
Артикул (NK)
Описание товара
Описание бренда
Описание подкатегории
Описание категории
Номер отдела
Описание отдела
Описание типа упаковки
Размер упаковки
Содержание жиров
Тип диеты
Масса
Единица измерения веса
Вид хранения
Тип срока годности
Ширина полки
Высота полки
Глубина полки
...
Рис. 3-8. Таблица измерений продукта
Многие атрибуты в таблице измерения «Продукт» не входят в иерархию
товаров. Атрибут типа упаковки может иметь такие значения, как «Бутылка»,
«Пакет», «Коробка» или «Банка». Один артикул в любом отделе может иметь
одно из этих значений. Часто имеет смысл комбинировать ограничение для этого
атрибута с ограничением для атрибута иерархии товаров. Например, вы можете
134
Глава 3
посмотреть все артикулы в категории зерновых, упакованных в пакеты. Другими словами, вы можете просматривать атрибуты измерения независимо от того,
принадлежат ли они иерархии товаров. Таблицы измерений «Продукт» обычно
имеют более одной явной иерархии.
Рекомендуемое частичное измерение «Продукт» для размерной модели розничного продуктового магазина показано на рис. 3-8.
Атрибуты со встроенным значением
Часто рабочие коды продуктов, идентифицируемые в таблице измерений нотацией NK (Натуральный ключ) для натурального ключа, имеют встроенное
значение с различными частями кода, представляющими важные характеристики продукта. В этом случае составной атрибут должен сохраняться как
целиком в таблице измерений, так и разбитым на составные части, которые
обрабатываются как отдельные атрибуты. Например, если символы с пятого по девятый в операционном коде идентифицируют производителя, имя
производителя также должно быть включено в качестве атрибута таблицы
измерений.
Числовые значения как атрибуты или факты
Разработчики иногда сталкиваются с числовыми значениями, которые явно
не попадают ни в категории атрибутов фактов, ни в категории измерений. Классический пример — стандартная цена продукта. Это определенно числовое значение, поэтому первым делом нужно поместить его в таблицу фактов. Но обычно
стандартная цена меняется нечасто, в отличие от большинства фактов, которые
часто имеют новые значения при каждом новом измерении события.
Если числовое значение используется в основном для расчетных целей, оно,
вероятно, относится к таблице фактов. Поскольку стандартная цена неаддитивная, вы можете умножить ее на количество, чтобы получить расширенную сумму, которая будет аддитивной. В качестве альтернативы, если стандартная цена
используется в первую очередь для анализа отклонений цен, возможно, вместо
этого следует сохранить метрику отклонения в таблице фактов. Если стабильное
числовое значение используется преимущественно для фильтрации и группировки, его следует рассматривать как атрибут измерения «Продукт».
Иногда числовые значения служат как для вычислений, так и для функций
фильтрации/группировки. В этих случаях следует сохранить значение как в таблицах фактов, так и в таблицах измерений. Возможно, стандартная цена в таблице фактов представляет собой оценку во время транзакции продажи, тогда как
атрибут измерения помечен, чтобы указать, что это текущая стандартная цена.
Розничные продажи
135
ПРИМЕЧАНИЕ Элементы данных, которые используются как для вычисле-
ния фактов, так и для фильтрации, группировки и маркировки измерений, должны храниться в обоих местах, даже если умный программист мог бы написать
приложения, которые обращаются к этим элементам данных из одного места.
Важно, чтобы размерные модели были как можно более согласованными, а разработка приложений — предсказуемо простой. Данные, участвующие в расчетах, должны быть в таблице фактов, а данные, входящие в ограничения, группы
и метки, должны быть в таблицах измерений.
Детализация атрибутов измерения
В разумной таблице измерений «Продукт» может быть 50 или более описательных атрибутов. Каждый атрибут — богатый источник для фильтрации и построения меток заголовков строк. Детализация — это не что иное, как запрос
заголовка строки из измерения, который предоставляет дополнительную информацию.
Название
отдела
Сумма продаж
в долларах
Выпечка
Заморозка
12 331
31 776
Разбиение по имени бренда:
Название
отдела
Наименование
бренда
Выпечка
Выпечка
Выпечка
Заморозка
Заморозка
Заморозка
Заморозка
Заморозка
Baked Well
Fluffy
Light
Coldpack
Freshlike
Frigid
Icy
QuickFreeze
Сумма продаж
в долларах
3009
3024
6298
5321
10 476
7328
2184
6467
Или разбиение по содержанию жира:
Название
отдела
Выпечка
Выпечка
Выпечка
Заморозка
Заморозка
Заморозка
Содержание
жира
Отсутствуют
Пониженное
Обычное
Отсутствуют
Пониженное
Обычное
Сумма продаж
в долларах
6298
5027
1006
5321
10 476
15 979
Рис. 3-9. Детализация атрибутов измерения
136
Глава 3
Допустим, у вас есть простой отчет, в котором выводится общая сумма продаж в долларах по отделам. Как показано на рис. 3-9, если вы хотите развернуть
детали, вы можете перетащить любой другой атрибут, например бренд, из измерения «Продукт» в отчет рядом с отделом, и вы можете автоматически перейти
к следующему уровню детализации. Вы можете выполнить детализацию по атрибуту «жирность», даже если его нет в сводной иерархии товаров.
ПРИМЕЧАНИЕ Детализация размерной модели — это не что иное, как до-
бавление атрибутов заголовка строки из таблиц измерений. При свертывании
детализации удаляются заголовки строк. Вы можете развернуть или свернуть атрибуты из более чем одной явной иерархии с атрибутами, которые не являются
частью иерархии.
Измерение «Продукт» — обычное измерение во многих размерных моделях. Следует проявлять большую осторожность, чтобы заполнить это измерение
как можно большим количеством описательных атрибутов. Надежный и полный
набор атрибутов измерений превращается в надежные и полные возможности
анализа для бизнес-пользователей. Мы более подробно рассмотрим измерение
«Продукт» в главе 5, где мы также обсудим обработку изменений атрибутов
продукта.
Измерение «Магазин»
Измерение «Магазин» описывает каждый магазин в продуктовой сети. В отличие от мастер-файла продукта, который почти гарантированно будет доступен
в любом крупном продуктовом бизнесе, полного мастер-файла магазина может
не быть. POS-системы могут просто указывать номер магазина в записях транзакций. В этом случае проектные группы должны собрать необходимые компоненты измерения «Магазин» из нескольких операционных источников. Часто
в головном офисе есть отдел недвижимости сети магазинов, который помогает
определить подробный мастер-файл магазина.
Несколько иерархий в таблице измерений
Измерение «Магазин» — основной объект для исследования географических
измерений. Каждый магазин можно рассматривать как локацию. Вы можете
объединить магазины в группы до любого географического атрибута, такого как
почтовый индекс, округ или штат в США. Вопреки распространенному мнению,
структура городов и штатов в США не носит иерархический характер. Поскольку многие штаты имеют города с одинаковыми названиями, вы захотите включить атрибут «город — штат» в измерение «Магазин».
Розничные продажи
137
Скорее всего, магазины также образуют внутреннюю организационную
иерархию, состоящую из районов и регионов. Эти две разные иерархии магазинов легко представить в измерении, потому что и географическую, и организационную иерархию можно легко определить одной строкой.
ПРИМЕЧАНИЕ Представление нескольких иерархий в таблице измерений
встречается не так редко. Имена и значения атрибутов должны быть уникальными в нескольких иерархиях.
Рекомендуемая таблица измерений розничного магазина показана на рис. 3-10.
Измерение магазина
Ключ магазина (PK)
Номер магазина (NK)
Название магазина
Адрес магазина (улица)
Город
Страна
Город — штат
Штат
Почтовый индекс
Директор
Район
Регион
План помещения/здания
Тип обработки фотографий
Тип финансовой услуги
Площадь торгового зала
Общая площадь
Дата открытия
Дата последней реконструкции
...
Рис. 3-10. Таблица измерений магазина
План помещения, тип обработки фотографий и тип финансовых услуг — все
это короткие текстовые дескрипторы, описывающие конкретный магазин. Это
должны быть не односимвольные коды, а дескрипторы от 10 до 20 символов,
которые имеют смысл при просмотре в раскрывающемся списке фильтров или
использовании в качестве метки отчета.
Колонка, описывающая площадь торгового зала, — числовая и теоретически может быть суммирована в разных магазинах. У вас может возникнуть соблазн поместить ее в таблицу фактов. Однако очевидно, что это постоянный
атрибут магазина, который чаще используется как фильтр или метка, чем как
138
Глава 3
дополнительный элемент при суммировании. По этим причинам площадь торгового зала входит в таблицу измерения «Магазин».
Даты в таблицах измерений
Дата открытия и дата последней реконструкции в измерении магазина могут быть столбцами типа даты. Однако если пользователи хотят группировать
и фильтровать по нестандартным атрибутам календаря (например, финансовый
период даты открытия), то они обычно используют ключи, чтобы можно было
объединить эту таблицу с таблицей-копией измерения «Дата». Эти копии объявляются в SQL конструкцией представления и семантически отличаются от основного измерения «Дата». Объявление представления будет выглядеть следующим образом:
create view first_open_date (first_open_day_number,
first_open_month, …)
as select day_number, month, …
from date
Теперь система действует так, как будто есть физическая копия таблицы измерения даты с именем FIRST_OPEN_DATE. Ограничения в этой новой таблице
дат не имеют ничего общего с ограничениями на основное измерение даты, присоединенное к таблице фактов. Представление «Дата первого открытия» — допустимое опорное измерение для измерения «Магазин»; опорные измерения
будут описаны более подробно позже в этой главе. Обратите внимание, что мы
тщательно выбирали имена всем столбцам в представлении, чтобы их нельзя
было спутать со столбцами из основного измерения «Дата». Эти различные логические представления одного физического измерения даты — пример ролевого измерения, которое мы обсудим более подробно в главе 6.
Измерение «Промоакция»
Измерение «Промоакция» — потенциально наиболее интересное измерение
в схеме розничных продаж. Это измерение описывает условия промоакций, при
которых продается продукт. Условия промоакции включают временное снижение цен, демонстрацию в торговом зале, объявления в газетах и купоны. Это
измерение часто называют причинно-следственным, поскольку оно описывает
факторы, которые, как считается, вызывают изменение продаж продукции.
Бизнес-аналитики как в штаб-квартире, так и в магазинах заинтересованы
в определении, эффективна ли рекламная акция. Акции оцениваются по одному
или нескольким следующим факторам:
Розничные продажи
139
1. Наблюдается ли рост продаж продвигаемых товаров, называемый подъемом, в течение рекламного периода. Прирост можно измерить только
в том случае, если магазин может определить, какими были бы базовые
продажи продвигаемых товаров без этой акции. Базовые значения можно
оценить на основе предыдущей истории продаж и в некоторых случаях
с помощью сложных моделей.
2. Наблюдается ли падение продаж продуктов, участвующих в акции, непосредственно до или после рекламной акции, что отменило прирост продаж
во время рекламной акции (сдвиг во времени). Другими словами, перенесли ли вы продажи с продуктов с регулярными ценами на продукты с временно сниженными ценами?
3. Показали ли продвигаемые продукты прирост продаж, а другие продукты,
находящиеся поблизости на полке, — соответствующее снижение продаж
(каннибализация)?
4. Получили ли все продукты в продвигаемой категории продуктов чистый
общий прирост продаж с учетом периодов времени до, во время и после
акции (рост рынка)?
5. Была ли акция прибыльной? Обычно прибыль от продвижения определяется как дополнительный прирост прибыли продвигаемой категории
по сравнению с базовыми продажами с учетом сдвига во времени и каннибализации, а также затрат на продвижение.
Причинно-следственные условия, потенциально влияющие на продажу, необязательно отслеживаются непосредственно POS-системой. Система транзакций отслеживает снижение цен и скидки. Наличие купонов также обычно
фиксируется при транзакции, потому что покупатель либо предъявляет купоны
во время продажи, либо нет. Возможно, потребуется связать рекламу и условия
показа в магазине из других источников.
Различные возможные причинно-следственные условия сильно взаимосвязаны. Временное снижение цены обычно связано с рекламой и, возможно, выставлением в торговом зале. По этой причине имеет смысл создать одну строку
в измерении «Промоакция» для каждой существующей комбинации условий
продвижения. В течение года может быть 1000 объявлений, 5000 временных
снижений цен и 1000 выставленных товаров в торговом зале, но может быть
только 10 000 комбинаций этих трех условий, влияющих на любой конкретный
продукт. Например, в какой-то рекламной акции большинство магазинов будут
запускать все три механизма продвижения одновременно, но некоторые магазины могут не выставлять товар на видное место. В этом случае потребуются две
отдельные строки условий рекламной акции: одна для обычного снижения цены
140
Глава 3
плюс реклама плюс показ, а вторая — только для снижения цены плюс реклама.
Рекомендуемая таблица измерения «Промоакция» показана на рис. 3-11.
С чисто логической точки зрения вы можете записывать аналогичную информацию о рекламных акциях, разделив четыре причинных механизма (снижение цен, реклама, показы и купоны) на отдельные измерения, а не объединяя
их в одно. В итоге это решение — прерогатива разработчика. Доводы в пользу
сохранения вместе четырех измерений:
1. Если четыре причинных механизма сильно коррелированы, единое комбинированное измерение ненамного больше, чем любое из отдельных измерений.
2. Объединенное единое измерение можно эффективно просматривать, чтобы увидеть, как различные снижения цен, реклама, выставление на видное
место и купоны используются вместе. Однако этот вариант показывает
только возможные комбинации рекламных акций. Просмотр в таблице
измерения не показывает, какие магазины или продукты были затронуты
рекламной акцией; эта информация находится в таблице фактов.
Измерение промоакций
Ключ промоакции (PK)
Промокод
Наименование акции
Снижение стоимости
Тип рекламного носителя
Тип объявления
Тип расположения товара
Тип купона
Наименование СМИ
Провайдер медийной рекламы
Стоимость продвижения
Дата начала акции
Дата окончания акции
...
Рис. 3-11. Таблица измерения «Промоакция»
Аргументы в пользу разделения причинных механизмов на четыре отдельные
таблицы измерений:
1. Изолированные измерения могут быть более понятны бизнес-сообществу,
если пользователи будут рассматривать эти механизмы отдельно. Это будет
понятно во время собраний по поводу сбора бизнес-требований.
Розничные продажи
141
2. Администрирование отдельных измерений может быть более простым,
чем управление комбинированным измерением.
Имейте в виду, что между этими двумя вариантами нет разницы в содержании.
ПРИМЕЧАНИЕ Включение атрибута стоимости продвижения в измерение
«Промоакция» должно производиться с особой тщательностью. Этот атрибут
можно использовать для фильтрации и группировки. Однако эта стоимость не должна отображаться в таблице фактов транзакции POS, представляющей продажи
отдельного продукта, потому что она находится в неправильном масштабе; эта
стоимость должна находиться в таблице фактов, зернистость которой — акция.
Пустые внешние ключи, атрибуты и факты
Как правило, большинство транзакций по продаже включают продукты, которые
не участвуют в промоакции. Будем надеяться, что потребители не просто заполняют свою корзину товарами по акции; вы хотите, чтобы они заплатили полную
цену за некоторые продукты в корзине! Измерение «Промоакция» должно
включать строку с уникальным ключом, например 0 или –1, чтобы идентифицировать условие отсутствия продвижения и избежать пустого ключа продвижения в таблице фактов. Ссылочная целостность нарушается, если вы помещаете
NULL в столбец таблицы фактов, объявленный как внешний ключ для таблицы
измерения. В дополнение к сигналам нарушения ссылочной целостности пустые
ключи — источник большой путаницы для пользователей, потому что таблицы
не могут соединяться по пустым ключам.
Вы должны избегать пустых ключей в таблице фактов. Правильный дизайн включает строку в соответствующей таблице измерений, чтобы
указать, что измерение не применимо к данной мере.
ВНИМАНИЕ!
Иногда мы встречаем Null как значение атрибутов измерения. Обычно это
происходит, когда строка измерения не заполнена полностью или когда есть атрибуты, которые не применяются ко всем строкам измерения. В обоих случаях мы рекомендуем заменить пустое значение описательной строкой, например
«Неизвестно» или «Неприменимо». Пустые значения, по существу, исчезают
в раскрывающихся меню возможных значений атрибутов или в группах отчетов;
для их идентификации требуется специальный синтаксис. Если пользователи
суммируют факты путем группировки по полностью заполненному атрибуту
измерения, а затем, альтернативно, суммируют путем группировки по атрибуту
измерения с пустыми значениями, они получат разные результаты запроса. И вам
142
Глава 3
позвонят, потому что данные не выглядят правдоподобно. Вместо того чтобы
оставить атрибут пустым или заменить его на пробел или точку, лучше всего обозначить условие; пользователи могут намеренно принять решение об исключении неизвестного или неприменимого значения из их запроса. Стоит отметить,
что некоторые продукты OLAP запрещают пустые значения атрибутов, так что
это еще одна причина избегать их.
Наконец, мы также можем столкнуться с NULL в качестве метрик в таблице
фактов. Как правило, мы оставляем эти NULL, так что они должным образом
обрабатываются в функциях агрегирования, таких как SUM, MIN, MAX, COUNT
и AVG, которые правильно работают с NULL. Замена NULL на ноль неправильно исказила бы эти агрегированные расчеты.
Инструменты для сбора данных могут использовать различные методы отслеживания Null-значений. Возможно, при создании набора данных для конкретного наблюдения потребуется проделать дополнительную работу по преобразованию помимо вышеуказанных рекомендаций.
Прочие измерения розничных продаж
Любой описательный атрибут, который приобретает только одно значение в таблице фактов, — хороший кандидат для добавления в существующее измерение или
создания его собственного измерения. Решение, следует ли ассоциировать измерение с таблицей фактов, должно быть двоичным (да/нет), основанным на обьявленной зернистости таблицы фактов. Например, для каждой транзакции, вероятно,
идентифицируется кассир. Соответствующее измерение «Кассир», скорее всего,
будет содержать небольшое подмножество атрибутов, не являющихся персональными данными сотрудников. Как и измерение «Промоакция», измерение «Кассир», скорее всего, будет иметь строку No Cashier («Нет кассира») для транзакций, которые обрабатываются через кассы самообслуживания.
Для способа оплаты разворачивается более сложная ситуация. Возможно, магазин имеет жесткие правила и принимает только один способ оплаты за транзакцию. Это облегчило бы вашу жизнь как создателя размерной модели, потому
что вы прикрепили бы простое измерение «Способ оплаты» к схеме продаж,
которое, вероятно, включает описание способа оплаты наряду с, возможно, группировкой методов оплаты в либо в денежном эквиваленте, либо в типах кредитных платежей.
В реальной жизни методы оплаты часто представляют собой более сложный
сценарий. Если по одной POS-транзакции принимаются несколько способов
оплаты, то способ оплаты не принимает на себя одно значение в объявленной зернистости. Вместо того чтобы изменять объявленную зернистость на нечто неестественное, например одну строку за метод оплаты на продукт в POS-транзакции,
Розничные продажи
143
вы, скорее всего, зафиксируете метод оплаты в отдельной таблице фактов с детализацией либо в одной строке на транзакцию (тогда различные варианты способа
оплаты будут отображаться как отдельные факты), либо в одной строке на каждый метод оплаты за транзакцию (что потребует отдельного измерения «Способ
оплаты», чтобы связать их).
Вырожденные измерения для номеров транзакций
Таблица фактов розничных продаж включает номер транзакции POS на каждой
строке товара. В оперативной базе данных номер транзакции POS будет ключом
к записи заголовка транзакции, содержащей всю информацию, действительную
для транзакции в целом, такую как дата транзакции и идентификатор магазина.
Тем не менее в размерной модели вы уже извлекли эту интересную информацию заголовка в другие измерения. Номер транзакции POS по-прежнему полезен, поскольку он служит ключом к группировке для получения всех продуктов,
приобретенных в рамках одной корзины покупателя. Это также потенциально
позволяет создать обратную связь в операционную систему.
Хотя номер транзакции POS выглядит как ключ измерения в таблице фактов,
описательные элементы, которые в противном случае могли бы попасть в измерение «POS-транзакция», не существуют. Поскольку полученное измерение пусто, мы называем номер транзакции POS вырожденным измерением. Оно идентифицируется обозначением DD (Degenerate dimension) в терминах этой книги.
Натуральный операционный номер квитанции, такой как номер транзакции
POS, находится в таблице фактов сам по себе, не присоединяясь к таблице измерений. Вырожденные измерения очень распространены, когда зернистость таблицы фактов представлено одной транзакцией или строкой транзакции, потому
что такое измерение представляет собой уникальный идентификатор родителя.
Номера заказов, номера счетов и номера накладных почти всегда отображаются
как вырожденные измерения в размерной модели.
Вырожденные измерения часто играют роль поддержания целостности
первичного ключа таблицы фактов. В нашем примере основной ключ таблицы
фактов розничных продаж состоит из вырожденного номера транзакции POS
и ключа продукта, предполагая, что сканирование идентичных продуктов в рыночной корзине сгруппировано в единую строку.
ПРИМЕЧАНИЕ Оперативные номера управления транзакцией, такие как
номера заказов, номера счетов-фактур и номера накладных, обычно приводит
к пустым измерениям и представлены как вырожденные измерения в таблицах
фактов транзакций. Вырожденное измерение — это ключ измерения без соответствующей таблицы измерений.
144
Глава 3
Если по какой-либо причине один или несколько атрибутов законно оставлены после того, как все другие измерения были созданы и, кажется, принадлежат
этой сущности заголовка транзакции, вы просто создадите нормальную строку
измерения с соответствующим измерением для присоединения. Тем не менее измерение больше не будет вырожденным.
Розничная схема в действии
С помощью нашей схемы розничных точек продаж давайте проиллюстрируем,
как она будет использоваться в среде запросов. Бизнес-пользователь может быть
заинтересован в лучшем понимании еженедельного объема продаж в долларах
для закусок, которые продавались по промоакции в январе 2013 года для магазинов в районе Бостона. Как показано на рис. 3-12, можно поместить фильтр
запросов на месяц и год в измерении «Дата», район в измерении «Магазин»
и категорию в измерении «Продукт».
Измерение данных
Январь
2013
Ключ даты (PK)
Дата
День недели
Календарный месяц
Календарный квартал
Календарный год
…
Измерение «Магазин»
Бостон
Ключ магазина (PK)
Номер магазина (NK)
Название магазина
Район
Регион
…
Измерения «Кассир»
Ключ кассира (PK)
Идентификатор
сотрудника (NK)
Имя кассира
…
Таблица фактов розничных продаж
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Ключ промоакции (FK)
Ключ кассира (FK)
Ключ способа оплаты (FK)
№ POS-транзакции (DD)
Количество продаж
Обычная цена за единицу
Цена с скидкой
Чистая цена за единицу
Сумма расширенной скидки
в долларах
Сумма расширенных продаж
в долларах
Сумма расширенных затрат
в долларах
Расширенная сумма валовой
прибыли в долларах
Измерение «Продукт»
Ключ продукта (PK)
Артикул (NK)
Описание продукта
Описание бренда
Описание категории
…
Закуски
Измерение «Промоакция»
Ключ промоакции (PK)
Промокод (NK)
Наименование акции
Тип рекламного носителя
Дата начала акции
…
Измерение «Метод оплаты»
Ключ способа оплаты (PK)
Описание метода оплаты
Группа платежных методов
Рис. 3-12. Запрос схемы розничных продаж
Если инструмент запросов суммирует продажи в долларах, сгруппированные по дате окончания недели и промоакциям, результаты запроса SQL будут
похожи на те, что приведены ниже на рис. 3-13. Можно ясно видеть связь между размерной моделью и связанным с ней запросом. Высокое качество атрибутов измерения имеет решающее значение, поскольку атрибуты — это источник
Розничные продажи
145
фильтров запросов и меток отчетов. Если вы используете инструмент BI с большей функциональностью, результаты, скорее всего, будут отображаться в качестве связанного отчета со множеством вкладок. Такой отчет может быть более
привлекательным для бизнес-пользователей, чем колонки данных, полученных
в результате запроса SQL.
Календарная неделя
Дата завершения
Название акции
6 января 2013
13 января 2013
20 января 2013
27 января 2013
Без промоакций
Без промоакций
Продвижение Super Bowl
Продвижение Super Bowl
Название
отдела
6 января 2013
13 января 2013
20 января 2013
27 января 2013
Сумма расширенных
продаж в долларах
2647
4851
7248
13 798
Сумма расширенных
продаж в долларах
без промоакций
Сумма расширенных
продаж в долларах
с продвижением Super Bowl
2647
4851
0
0
0
0
7248
13 798
Рис. 3-13. Результаты запросов и отчет с несколькими вкладками
Расширяемость схемы розничных продаж
Давайте обратим наше внимание на расширение первоначального размерного
дизайна. Через несколько лет после внедрения схемы розничных продаж ретейлер реализует программу постоянных покупателей. Вместо того чтобы знать факт
«неопознанный покупатель приобрел 26 пунктов на кассовый чек», теперь вы
можете определить конкретного покупателя. Только представьте себе заинтересованность бизнес-пользователей в анализе моделей покупок по множеству географических, демографических, поведенческих и других дифференцированных
характеристик покупателей.
Обработка этой новой информации о частых покупателях относительно тривиальна. Вы создадите таблицу измерения «Постоянный покупатель» и добавите еще один внешний ключ в таблицу фактов. Поскольку вы не можете попросить
покупателей принести все свои старые кассовые чеки, чтобы сопоставить исторические данные по продажам с их новым номером покупателя, вы вставляете
вместо номера покупателя суррогатный ключ по умолчанию, соответствующий
строке измерения «До внедрения программы постоянных покупателей» во все
исторические строки таблицы фактов. Так как не у всех, кто делает покупки
в продуктовом магазине, будет карточка постоянного покупателя, вам также
146
Глава 3
следует включить строку «Покупатель не идентифицирован» в измерение «Покупатель». Как мы обсуждали ранее с измерением «Промоакция», в таблице
фактов не может быть пустого ключа постоянного покупателя.
Наша исходная схема стабильно расширяется, чтобы приспособиться к этому
новому измерению, в основном потому, что данные транзакции POS изначально моделировались на самом детальном уровне. Добавление измерений, применимых на этой степени детализации, не изменило существующие ключи или
факты измерений; все существующие приложения бизнес-аналитики продолжают работать без каких-либо изменений. Если бы зернистость была изначально
задекларирована как ежедневные розничные продажи (транзакции с разбивкой
по дням, магазинам, продуктам и акциям), а не детали строки транзакции, вы
не смогли бы учесть измерение «Постоянный покупатель». Преждевременное
суммирование, или агрегация, по своей сути ограничивает вашу способность
добавлять дополнительные измерения, потому что дополнительные измерения
часто не применяются к более высокой зернистости.
Предсказуемая симметрия размерных моделей позволяет им поглощать некоторые довольно существенные изменения в исходных данных и/или допущения
моделирования, не делая недействительными существующие приложения бизнес-аналитики, в том числе:
■ Новые атрибуты измерения.
Если вы обнаружите новые текстовые дескрипторы измерения, вы можете
добавить эти атрибуты как новые столбцы. Все существующие приложения
не будут обращать внимания на новые атрибуты и продолжат работу. Если
новые атрибуты доступны только после определенного момента, то в старых строках измерений следует указать значение «Недоступно» или его
эквивалент. Имейте в виду, что этот сценарий более сложен, если бизнеспользователи хотят отслеживать исторические изменения этого недавно
определенного атрибута. В этом случае обратите особое внимание на покрытие медленно меняющихся измерений в главе 5.
■ Новые измерения.
Как мы только что обсуждали, вы можете добавить измерение в существующую таблицу фактов, добавив новый столбец внешнего ключа и правильно
заполнив его значениями первичного ключа из нового измерения.
■ Новые измеряемые факты.
Если станут доступны новые измеряемые факты, вы можете аккуратно
добавить их в таблицу фактов. Самый простой случай — это когда новые
Розничные продажи
147
факты доступны в том же событии измерения и с той же степенью детализации, что и уже существующие. В этом случае таблица фактов изменяется
путем добавления новых столбцов, а значения заполняются в таблице. Если
новые факты доступны только с определенного момента, в старые строки
фактов необходимо поместить пустые значения. Более сложная ситуация
возникает, когда новые измеряемые факты естественным образом возникают в другой зернистости. Если новые факты не могут быть размещены или
назначены в исходной зернистости таблицы фактов, новые факты относятся к их собственной таблице фактов, потому что смешивать зернистость
в одной и той же таблице фактов — ошибка.
Таблицы фактов без метрик
Есть один важный вопрос, на который нельзя ответить с помощью предыдущей
схемы розничных продаж: какие товары продавались по акции, но так и не были
проданы? В таблице фактов продаж регистрируются только фактически проданные артикулы. Не существует строк таблицы фактов с пустыми фактами для артикулов, которые не были проданы, потому что это значительно увеличило бы таблицу фактов. В реляционном мире необходима информация о покрытии товаров
промоакциями или таблица фактов о событиях, чтобы ответить на вопрос о том,
чего не произошло. В этом примере ключами таблицы фактов покрытия промоакций будут дата, продукт, магазин и акция. Очевидно, это похоже на таблицу
фактов продаж, которую вы только что создали; однако зернистость была бы
существенно иной. В случае таблицы фактов покрытия промоакциями вы должны загружать по одной строке для каждого продвигаемого продукта в магазине
каждый день (или неделю, если розничная промоакция длится неделю) независимо от того, продан ли продукт. Эта таблица фактов позволяет вам увидеть
взаимосвязь между ключами, определенными для рекламной акции, независимо
от других событий, таких как фактические продажи продукта. Мы называем ее
таблицей фактов, не содержащей фактов, потому что в ней нет показателей метрик; она просто фиксирует взаимосвязь между задействованными ключами, как
показано на рис. 3-14. Чтобы облегчить подсчет, вы можете включить фиктивный
факт, такой как счетчик продвижения в этом примере, который всегда содержит
постоянное значение 1; это косметическое улучшение, которое позволяет приложению BI избежать подсчета одного из внешних ключей.
Чтобы определить, какие продукты были по акции, но не продавались, требуется двухэтапный процесс. Для начала вы должны сделать запрос в таблицу фактов без метрик, чтобы определить совокупность продуктов, которые участвовали
в акции в выбранный день. Затем вы определяете, какие продукты продаются,
148
Глава 3
из таблицы фактов продаж POS. Ответ на наш первоначальный вопрос — это
разница наборов между этими двумя списками продуктов. Если вы работаете
с данными в кубе OLAP, часто легче ответить на вопрос «что не произошло»,
потому что куб обычно содержит явные ячейки для отсутствия поведения.
Измерение «Дата»
Факты о рекламной акции
Ключ даты (PK)
Дата
День недели
Календарный месяц
Календарный квартал
Календарный год
…
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Ключ промоакции (FK)
Количество рекламных акций (= 1)
Измерение «Продукт»
Ключ продукта (PK)
Артикул (NK)
Описание товара
Описание бренда
Описание категории
…
Измерение «Магазин»
Измерение «Промоакция»
Ключ магазина (PK)
Номер магазина (NK)
Название магазина
Район
Регион
…
Ключ промоакции (PK)
Промокод (NK)
Наименование акции
Тип рекламного носителя
Дата начала акции
…
Рис. 3-14. Таблица фактов покрытия промоакции
Ключи таблиц измерений и фактов
Теперь, когда схемы разработаны, мы сосредоточимся на первичных ключах таблиц измерений и фактов, а также на других идентификаторах строк.
Суррогатные ключи таблицы измерений
Уникальный первичный ключ таблицы измерений должен быть суррогатным,
а не естественным, сформированным на основе идентификатора операционной
системы. Суррогатные ключи имеют множество других псевдонимов: бессмысленные, целочисленные, ненатуральные, искусственные и синтетические. Суррогатные ключи — это просто целые числа, которые назначаются последовательно
по мере необходимости для заполнения измерения. Первой строке продукта назначается суррогатный ключ продукта со значением 1, следующей строке продукта
назначается ключ продукта 2 и так далее. Фактическое значение суррогатного ключа не имеет никакого значения для бизнеса. Суррогатные ключи служат просто для
присоединения таблиц измерений к таблице фактов. В этой книге имена столбцов
с суффиксом Key определяются как первичный ключ (PK — primary key) или внешний ключ (FK — foreign key), при этом подразумевается, что они суррогатные.
Розничные продажи
149
Разработчики моделей иногда неохотно отказываются от натуральных ключей,
потому что они хотят ориентироваться в таблице фактов на основе операционного
кода, избегая при этом объединения с таблицей измерений. Они также не хотят терять встроенный смысл, который часто является частью натурального составного
ключа. Однако вам не следует полагаться на смысловые ключи измерений, потому
что любые сделанные вами предположения в итоге могут оказаться недействительными. Точно так же запросы и приложения доступа к данным не должны иметь
встроенной зависимости от ключей, потому что логика также будет уязвима. Даже
если натуральные ключи кажутся стабильными и лишенными смысла, не поддавайтесь соблазну использовать их в качестве первичного ключа таблицы измерений.
ПРИМЕЧАНИЕ Каждое соединение между таблицами измерений и фактов
в хранилище данных должно быть основано на бессмысленных целочисленных
суррогатных ключах. Следует избегать использования натурального ключа в качестве первичного ключа таблицы измерений.
Первоначально может быть быстрее реализовать размерную модель с использованием операционных натуральных ключей, но суррогатные ключи окупаются
в долгосрочной перспективе. Иногда мы думаем о них как о прививке от гриппа
для хранилища данных — подобно вакцинации, инициирование и администрирование суррогатных ключей немного болезненно, но в долгосрочной перспективе выгоды существенны, особенно с учетом снижения риска переделки в будущем. Вот несколько преимуществ:
■ Защищает хранилище данных от операционных изменений.
Суррогатные ключи позволяют команде хранилища данных поддерживать
контроль над средой DW/BI, а не подчиняться операционным правилам
для создания, обновления, удаления, повторного использования и повторного использования производственных кодов. Во многих организациях
исторические операционные коды, такие как неактивные номера счетов
или устаревшие коды продуктов, переназначаются после периода бездействия. Если номера счетов будут повторно использованы после 12 месяцев
бездействия, операционные системы ничего не упустят, потому что их бизнес-правила запрещают данным храниться так долго. Но система DW/BI
может хранить данные годами. Суррогатные ключи предоставляют складу
механизм для различения двух отдельных экземпляров одного и того же
номера операционного счета. Если вы полагаетесь исключительно на операционные коды, вы также можете быть уязвимы к совпадению ключей
в случае сбора или консолидации данных.
150
Глава 3
■ Интеграция нескольких систем-источников.
Суррогатные ключи позволяют группе хранилищ данных интегрировать
данные из нескольких операционных систем-источников, даже если им
не хватает согласованных исходных ключей, за счет использования таблицы
сопоставления перекрестных ссылок подсистемы для связывания нескольких натуральных ключей общим суррогатным.
■ Улучшение производительности.
Суррогатный ключ настолько мал, насколько мало целое число, в то же время
это гарантирует, что он будет комфортно учитывать ожидаемую в будущем
кардинальность (количество строк в измерении). Часто код операции представляет собой громоздкую строку буквенно-цифровых символов или даже
группу полей. Меньший суррогатный ключ преобразуется в меньшие таблицы фактов, меньшие индексы таблиц фактов и большее количество строк
таблицы фактов на операцию ввода-вывода блока. Обычно для обработки
большинства измерений достаточно 4-байтового целого числа. 4-байтовое
целое число — это одно целое число, а не четыре десятичных цифры. Он
имеет длину 32 бита и поэтому может обрабатывать примерно 2 миллиарда
положительных значений (2^32) или 4 миллиарда положительных и отрицательных значений (от –2^32 до +2^32). Этого более чем достаточно практически для любого измерения. Помните, что, если у вас есть большая таблица
фактов с 1 миллиардом строк данных, каждый байт в каждой строке таблицы
фактов преобразуется в еще один гигабайт памяти.
■ Обработка пустых или неизвестных условий.
Как упоминалось ранее, специальные значения суррогатных ключей используются для записи условий измерения, которые могут не иметь операционного кода, таких как условие «Нет промоакции» или анонимный покупатель. Вы можете назначить суррогатный ключ для их идентификации,
несмотря на отсутствие кода операции. Точно так же в таблицах фактов
иногда есть даты, которые еще предстоит определить. Не существует значения типа даты SQL для понятия «Дата, которая должна быть определена»
или «Дата неприменима».
■ Поддержка отслеживания изменения атрибутов измерения.
Один из основных методов обработки изменений атрибутов измерения
основан на использовании суррогатных ключей при обработке нескольких профилей для одного натурального ключа. На самом деле это одна
из самых важных причин использовать суррогатные ключи, которые мы
Розничные продажи
151
опишем в главе 5. Псевдосуррогатный ключ, созданный простым склеиванием естественного ключа с отметкой времени, опасен. Вам нужно избегать
множественных соединений между таблицами измерений и фактов, иногда
называемых двуствольными соединениями, из-за их неблагоприятного воздействия на производительность и простоту использования.
Конечно, требуются некоторые усилия для назначения и администрирования
суррогатных ключей, но это не так страшно, как многие думают. Вам необходимо
создать и поддерживать таблицу перекрестных ссылок в системе ETL, которая
будет использоваться для замены соответствующего суррогатного ключа в каждой строке таблицы фактов и измерений. Мы описываем процесс администрирования суррогатных ключей в главе 19.
Натуральные, стойкие и сверхнатуральные ключи
Как и суррогатные ключи, натуральные ключи, назначенные и используемые
операционными исходными системами, имеют другие имена, такие как бизнесключи, производственные и операционные ключи. На рисунках в книге они
обозначены нотацией NK (Натуральный ключ). Натуральный ключ часто моделируется как атрибут в таблице измерений. Если натуральный ключ поступает из нескольких источников, вы можете использовать символьный тип данных,
который добавит информацию об исходной системе, например SAP|43251 или
CRM|6539152. Если одна и та же сущность представлена в обеих операционных
исходных системах, то у вас, вероятно, будет два атрибута натурального ключа
в измерении, соответствующем обоим источникам. Функциональные натуральные ключи часто состоят из значимых составных частей, таких как производственное направление деятельности или страна происхождения; эти компоненты следует разделить и сделать доступными как отдельные атрибуты.
В таблице измерений с отслеживанием изменений атрибутов важно иметь
идентификатор, который однозначно и надежно определяет сущность измерения при изменении его атрибутов. Хотя может показаться, что операционный
натуральный ключ подходит для этих целей, иногда натуральный ключ изменяется из-за неожиданных событий в бизнесе (например, слияние организаций),
для обработки дублирующихся записей или интеграции данных из нескольких
источников. Если натуральные ключи измерения не полностью защищены и могут измениться с течением времени, системе ETL необходимо назначить постоянные долговечные идентификаторы, также известные как сверхнатуральные
ключи. Постоянный устойчивый сверхнатуральный ключ управляется системой
DW/BI и остается неизменным в течение всего срока службы системы. Как и суррогатный ключ измерения, это простое целое число, которое последовательно
152
Глава 3
назначается. И, подобно натуральным ключам, обсуждавшимся ранее, постоянный сверхнатуральный ключ обрабатывается как атрибут измерения; это не замена суррогатного первичного ключа таблицы измерений. В главе 19 также обсуждается ответственность системы ETL за эти надежные идентификаторы.
Суррогатные ключи вырожденного измерения
Хотя суррогатные ключи обычно не назначаются вырожденным измерениям,
необходимо оценивать каждую ситуацию, чтобы определить, нужны ли они.
Суррогатный ключ необходим, если контрольные номера транзакций не уникальны в разных местах или используются повторно. Например, POS-система
розничного продавца может не назначать уникальные номера транзакций в магазинах. Система может вернуться к нулю и повторно использовать предыдущие контрольные числа, когда будет достигнут максимум возможных значений.
Кроме того, контрольный номер транзакции может быть объемным 24-байтовым буквенно-цифровым столбцом. Наконец, в зависимости от возможностей
инструмента бизнес-аналитики вам может потребоваться назначить суррогатный
ключ (и создать связанную таблицу измерений) для детализации по номеру транзакции. Очевидно, что измерения контрольных чисел, смоделированные таким
образом с соответствующими таблицами измерений, больше не являются вырожденными.
Умные ключи измерения «Дата»
Как мы уже отмечали, измерение «Дата» имеет уникальные характеристики
и требования. Календарные даты фиксированы и заранее определены; вам никогда не придется беспокоиться об удалении дат или обработке новых, неожиданных дат в календаре. Благодаря их предсказуемости вы можете использовать
более интеллектуальный ключ для измерения даты.
Если последовательное целое число служит первичным ключом измерения
даты, оно должно быть присвоено в хронологическом порядке. Другими словами, 1 января первого года будет назначено значение суррогатного ключа 1, 2 января — суррогатный ключ 2, 1 февраля — суррогатный ключ 32 и так далее.
Чаще всего первичный ключ измерения даты представляет собой значимое
целое число в формате ГГГГММДД (YYYYMMDD). Ключ YYYYMMDD не предназначен для предоставления бизнес-пользователям и их приложениям бизнесаналитики, чтобы обойти применение измерения «Дата» и использовать только
таблицу фактов. Фильтрация по ключу YYYYMMDD таблицы фактов может отрицательно повлиять на удобство использования и производительность. Фильтрация и группировка атрибутов календаря должны выполняться в таблице измерений, а не в коде приложения BI.
Розничные продажи
153
Однако ключ ГГГГММДД полезен для разделения таблиц фактов. Разделение позволяет сегментировать таблицу на более мелкие таблицы под капотом.
Разделение большой таблицы фактов на основе даты эффективно, поскольку оно
позволяет аккуратно удалять старые данные и загружать и индексировать новые
данные в текущем разделе, не затрагивая остальную часть таблицы фактов. Это
сокращает время, необходимое для загрузки, резервного копирования, архивирования и ответа на запрос. Программно обновлять и поддерживать разделы
просто, если ключ даты — упорядоченное целое число: год увеличивается на 1
до желаемого количества лет, месяц увеличивается на 1 до 12 и т. д. Использование умного ключа YYYYMMDD дает преимущества суррогатного ключа, а также
преимущества более простого управления разделами.
Хотя целое число YYYYMMDD — наиболее распространенное обозначение
для ключей измерения даты, некоторые оптимизаторы реляционных баз данных
предпочитают использовать реальную дату для разделения. В этих случаях оптимизатор знает, что существует 31 значение между 1 марта и 1 апреля в отличие
от 100 значений между 20130301 и 20130401. Точно так же он понимает, что
между 1 декабря и 1 января существует 31 значение, в отличие от 8900 целых
значений между 20121201 и 20130101. Это знание может повлиять на стратегию
выполнения запросов, выбранную оптимизатором, и еще больше сократить время запроса. Если оптимизатор способен использовать в свою пользу функциональность и внутреннее устройство типа даты, это следует учитывать для ключа
даты. Если единственное обоснование для ключа типа даты — это упрощенное
администрирование для администратора базы данных, тогда вы можете чувствовать себя менее ограниченными в выборе.
При использовании более интеллектуальных ключей даты независимо
от того, назначаются ли они в хронологическом порядке или содержат столбец
с более определенным значением YYYYMMDD целочисленного типа или типа
«Дата», вам необходимо зарезервировать специальное значение ключа даты
для ситуации, в которой дата неизвестна при первоначальной загрузке строки
фактов.
Суррогатные ключи таблицы фактов
Хотя мы непреклонны в использовании суррогатных ключей для таблиц измерений, мы менее требовательны к суррогатным ключам для таблиц фактов. Суррогатные ключи таблицы фактов обычно имеют смысл только для обработки
ETL. Как мы уже упоминали, первичный ключ таблицы фактов обычно состоит
из подмножества внешних ключей таблицы и/или вырожденного измерения. Однако суррогатные ключи, состоящие из одного столбца, имеют некоторые интересные скрытые преимущества для таблиц фактов.
154
Глава 3
Как и его аналог для измерений, суррогатный ключ таблицы фактов представляет собой простое целое число, лишенное какого-либо бизнес-содержимого,
которое назначается последовательно по мере создания строк таблицы фактов.
Хотя суррогатный ключ таблицы фактов вряд ли обеспечит преимущества в производительности запросов, он имеет следующие преимущества:
■ Немедленная уникальная идентификация.
Одиночная строка таблицы фактов сразу идентифицируется ключом.
Во время обработки ETL можно идентифицировать конкретную строку
без навигации по нескольким измерениям.
■ Отмена или возобновление массовой загрузки.
Если загружается большое количество строк с последовательно назначенными суррогатными ключами и процесс останавливается до завершения,
администратор базы данных может точно определить, где процесс остановился, найдя максимальное значение ключа в таблице. Администратор
базы данных мог бы отменить полную загрузку, указав диапазон только что
загруженных ключей или, возможно, возобновить загрузку с точно установленной точки.
■ Замена обновлений вставками и удалениями.
Суррогатный ключ таблицы фактов становится настоящим физическим
ключом таблицы фактов. Ключ таблицы фактов больше не определяется
набором внешних ключей измерений, по крайней мере, когда дело касается СУБД. Таким образом, становится возможным заменить операцию
обновления таблицы фактов вставкой с последующим удалением. Первый шаг — размещение новой строки в базе данных со всеми теми же
внешними ключами, что и строка, которую она должна заменить. Теперь
это возможно, потому что принудительное применение ключа зависит
только от суррогатного ключа, а замещающая строка имеет новый суррогатный ключ. Затем, на втором шаге, удаляют исходную строку, тем самым
завершая обновление. Для большого набора обновлений эта последовательность более эффективна, чем набор настоящих операций обновления
(update). Вставки (insert) могут обрабатываться с возможностью отката
или возобновления вставок, как описано в предыдущем пункте. Эти
вставки не нужно защищать полноценным механизмом транзакций. Затем можно безопасно выполнить этап окончательного удаления, поскольку процесс вставки завершился.
Розничные продажи
155
■ Использование суррогатного ключа таблицы фактов в качестве родительского элемента в схеме «родитель — потомок».
Если одна таблица фактов содержит строки, которые являются родительскими для строк в таблице фактов с более низкой степенью детализации,
суррогатный ключ таблицы фактов в родительской таблице также отображается в дочерней таблице. Аргумент использования в этом случае суррогатного ключа таблицы фактов, а не натурального родительского ключа,
аналогичен аргументу для использования суррогатного ключа в таблицах
измерений. Натуральные ключи беспорядочны и непредсказуемы, тогда
как суррогатные ключи представляют собой чистые целые числа и назначаются системой ETL, а не исходной системой. Конечно, в дополнение
к включению суррогатного ключа родительской таблицы фактов, таблица
фактов более низкого уровня должна также включать внешние ключи родительского измерения, чтобы дочерние факты можно было разрезать без
обращения к суррогатному ключу родительской таблицы фактов. И, как мы
обсудим в главе 4, вы никогда не должны присоединять таблицы фактов
напрямую к другим таблицам фактов.
Сопротивление стремлению к нормализации
В этом разделе давайте прямо рассмотрим несколько естественных побуждений
и опровергнем их. Эти побуждения соблазняют разработчиков моделей, которые
пришли из более нормализованной среды. Мы сознательно нарушаем некоторые традиционные правила моделирования, потому что сосредоточены на предоставлении ценности за счет простоты использования и производительности,
а не на эффективности обработки транзакций.
Схемы «снежинки» с нормализованными измерениями
Плоские денормализованные таблицы измерений с повторяющимися текстовыми значениями заставляют разработчиков моделей данных чувствовать себя
некомфортно. Давайте еще раз вернемся к таблице параметров продукта нашего
тематического исследования. 300 000 продуктов объединены в 50 отдельных отделов. Вместо того чтобы дублировать 20-байтовое описание отдела в таблице
измерений продукта, разработчики моделей с опытом в нормализованных таблицах хотят сохранить 2-байтовый код отдела, а затем создать новое измерение
отдела для декодирования отдела. Фактически им было бы удобнее, если бы все
дескрипторы в исходной архитектуре были нормализованы в отдельные таблицы
измерений. Они утверждают, что такая конструкция экономит место, потому что
156
Глава 3
таблица измерений из 300 000 строк содержит только коды, а не длинные дескрипторы.
Кроме того, некоторые разработчики моделей утверждают, что более нормализованные таблицы измерений легче поддерживать. Если описание отдела изменится, им потребуется обновить только одно вхождение в измерении отдела,
а не 6000 повторений в исходном измерении продукта. Обслуживание — частый
аргумент приверженцев дисциплин нормализации, но все это происходит в системе ETL задолго до того, как данные будут загружены в схему измерений области представления.
Нормализация таблицы измерений называется «превращение в снежинку». Избыточные атрибуты удаляются из плоской денормализованной таблицы
измерений и помещаются в отдельные нормализованные таблицы измерений.
На рис. 3-15 показано частичное превращение измерения «Продукт» в третью
нормальную форму. Контраст между рис. 3-15 и рис. 3-8 разителен. Обилие таблиц
в схеме «снежинка» (даже в нашем упрощенном примере) ошеломляет. Представьте себе влияние на рис. 3-12, если бы все иерархии схемы были нормализованы.
Схема «снежинка» — законное продолжение размерной модели, однако мы
призываем вас противостоять этому побуждению, учитывая два основных фактора дизайна: простоту использования и производительность.
Измерение «Продукт»
Ключ продукта (PK)
Артикул (натуральный ключ)
Описание товара
Ключ бренда (FK)
Ключ типа упаковки (FK)
Содержание жиров
Масса
Единица измерения веса
Ключ типа хранилища (FK)
Ширина полки
Высота полки
Глубина полки
…
Измерение «Бренд»
Ключ бренда (FK)
Описание бренда
Ключ категории (FK)
Измерение «Категория»
Измерение «Отдел»
Ключ категории (PK)
Описание категории
Ключ отдела (FK)
Ключ отдела (PK)
Номер отдела
Описание отдела
Измерение «Тип упаковки»
Ключ типа упаковки (PK)
Описание типа упаковки
Измерение «Тип хранения»
Измерение «Срок годности»
Ключ типа хранилища (PK)
Описание типа хранилища
Ключ типа срока годности (FK)
Ключ типа срока годности (PK)
Описание срока годности
Рис. 3-15. Измерение продукта в схеме «снежинка»
Множество таблиц в «снежинке» значительно усложняют представление.
Бизнес-пользователи неизбежно столкнутся со сложностью; простота — одна
из основных целей размерной модели.
Большинство оптимизаторов баз данных также испытывают сложности
со схемой типа «снежинка». Многочисленные таблицы их соединения обычно
Розничные продажи
157
приводят к снижению производительности запросов. Сложность результирующих спецификаций соединений увеличивает шансы на то, что оптимизатор будет
сбит с толку и выберет плохую стратегию.
Экономия места на диске, связанная с таблицами измерений «снежинок»,
незначительна. Если вы замените 20-байтовое описание отдела в таблице аналитики продукта с 300 000 строками на 2-байтовый код, вы сэкономите колоссальные 5,4 МБ (300 000 × 18 байт); между тем у вас может быть таблица фактов
размером 10 ГБ! Таблицы измерений почти всегда геометрически меньше таблиц
фактов. Попытки нормализовать таблицы измерений для экономии места на диске — обычно пустая трата времени.
«Снежинка» негативно влияет на способность пользователей просматривать
информацию в пределах одного измерения. Просмотр часто включает фильтр
одного или нескольких атрибутов измерения и просмотр отдельных значений
другого атрибута при наличии этих ограничений. Просмотр позволяет пользователям понять взаимосвязь между значениями атрибутов измерения.
Очевидно, что нормализация измерения «Продукт» в схему типа «снежинка» сработает хорошо, если вам нужен просто список описаний категорий. Однако, если вы хотите увидеть все бренды в категории, вам необходимо
измерение «Бренд» и измерение «Категория». Если вы хотите также перечислить типы упаковок для каждого бренда в категории, вам придется просмотреть еще больше таблиц. SQL, необходимый для выполнения этих, казалось бы, простых запросов, сложен, а вы даже не коснулись других измерений
или таблиц фактов.
Наконец, «снежинка» отменяет использование битовых индексов. Битовые
индексы полезны при индексировании столбцов с низким числом значений, таких как атрибуты категории и отдела в таблице измерения «Продукт». Они значительно ускоряют выполнение запроса или фильтра для одного рассматриваемого столбца. Схема «снежинка» неизбежно будет мешать вашей способности
использовать эту технику улучшения производительности запросов.
ПРИМЕЧАНИЕ Иерархии фиксированной глубины должны быть плоски-
ми в таблицах измерений. Нормализованные таблицы измерений, образующие
«снежинку», ограничивают перекрестный просмотр атрибутов и не подразумевают использование битовых индексов. Экономия дискового пространства,
полученная в результате нормализации таблиц измерения, обычно составляет
менее одного процента от общего дискового пространства, необходимого для
общей схемы. Вы должны сознательно пожертвовать объемом дискового пространства, выделяемого под такие измерения в целях производительности
и простоты использования.
158
Глава 3
Создатели некоторых баз данных утверждают, что их платформа имеет лошадиные силы для выполнения запросов по полностью нормализованной размерной модели без вреда для производительности. Если вы можете достичь удовлетворительной производительности без физической денормализации таблиц
измерения, это нормально. Однако вы все равно захотите реализовать логическую размерную модель с денормализованными измерениями, чтобы представить легко понятную схему бизнес-пользователям и их приложениям BI.
В прошлом некоторые инструменты BI указывали на предпочтение схем
типа «снежинка»; их использование для удовлетворения индивидуальных требований инструмента BI приемлемо. Аналогично, если все данные доставляются
бизнес-пользователям через куб OLAP (где нормализованные измерения используются для заполнения куба, но никогда не видны пользователям), то схема «снежинка» приемлема. Однако в этих ситуациях необходимо учитывать
влияние на пользователей альтернативных инструментов BI и гибкость перехода
к альтернативам в будущем.
Внешняя опора
Хотя мы, как правило, не рекомендуем использование схемы «снежинка», возникают ситуации, в которых это допустимо, чтобы построить измерение — внешнюю опору с измерением, которое связано непосредственно с таблицей фактов,
как показано на рис. 3-16. В этом примере «однажды удаленная» внешняя опора — измерение даты, которое отходит, как луч снежинки, от основного измерения. Атрибуты даты внешней таблицы описательны и обозначены однозначно,
чтобы отличить их от других дат, связанных с бизнес-процессом. Атрибут даты
таблицы первичного измерения имеет смысл использовать, только если компания хочет отфильтровать и сгруппировать эту дату по нестандартным атрибутам
календаря, таким как финансовый период, индикатор рабочего дня или период
праздников. В противном случае вы могли бы просто рассматривать атрибут даты
как столбец стандартного типа даты в измерении «Продукт». Если используется выносная опора даты, следите за тем, чтобы даты выносной опоры попадали
в диапазон, хранящийся в стандартной таблице измерения «Дата».
Позже в книге вы встретите больше примеров внешних опор, например обработка демографических характеристик клиентов на уровне округа в главе 8.
Хотя внешние опоры могут сэкономить место и обеспечить единообразие
ссылок на одни и те же атрибуты, есть и недостатки. Они вводят больше соединений, что может отрицательно сказаться на производительности. Что еще более
важно, внешние опоры могут негативно повлиять на удобочитаемость для бизнес-пользователей и затруднить их возможность просматривать атрибуты в одном измерении.
Розничные продажи
159
Измерение «Продукт»
Ключ продукта (PK)
Артикул (NK)
Описание товара
Описание бренда
Описание подкатегории
Описание категории
Номер отдела
Описание отдела
Описание типа упаковки
Размер упаковки
Ключ даты введения продукта (FK)
...
Измерение «Дата появления продукта»
Ключ даты появления продукта (FK)
Дата появления продукта
Календарный месяц появления продукта
Календарный год появления продукта
Финансовый месяц появления продукта
Финансовый квартал появления продукта
Финансовый год введения продукта
Представление продукта
Индикатор праздничного периода
...
Рис. 3-16. Пример допустимой внешней опоры
Хотя выносные опоры допустимы, размерная модель не должна быть захламлена внешними опорами из-за потенциально негативного воздействия. Внешние опоры должны быть скорее исключением, чем правилом.
ВНИМАНИЕ!
Таблицы фактов «сороконожка» со «слишком большим
количеством измерений»
Таблица фактов в размерной схеме естественным образом сильно нормализована
и компактна. Невозможно дополнительно нормализовать чрезвычайно сложные
отношения «многие ко многим» между ключами в таблице фактов, поскольку
измерения не коррелируют друг с другом. Каждый магазин открыт каждый день.
Рано или поздно почти каждый товар продается по акции в большинстве или
во всех наших магазинах.
Интересно, что, хотя некоторые разработчики моделей испытывают дискомфорт с денормализованными таблицами измерений, они испытывают искушение денормализовать таблицу фактов. У них есть неконтролируемое стремление
нормализовать иерархии измерений, но они знают, что «снежинки» сильно
обескураживают, поэтому вместо этого они в итоге присоединяют нормализованные таблицы к таблице фактов. Вместо того чтобы иметь один внешний ключ
продукта в таблице фактов, они включают внешние ключи для часто анализируемых элементов в иерархии продуктов, таких как бренд, категория и отдел. Точно
так же ключ даты внезапно превращается в серию ключей, соединяющихся с отдельными таблицами измерений недели, месяца, квартала и года. Прежде чем
160
Глава 3
вы это поймете, ваша компактная таблица фактов превратится в неуправляемого
монстра, который соединяется буквально с десятками таблиц измерений. Мы
с любовью называем эти конструкции таблицами фактов — «сороконожками»,
потому что они, кажется, имеют почти 100 ног, как показано на рис. 3-17.
Факт розничных продаж через POS
Измерение «Дата»
Ключ даты (FK)
Измерение «Продукт»
Ключ недели (FK)
Измерение «Неделя»
Измерения «Месяц»
Ключ месяца (FK)
Ключ квартала (FK)
Измерение «Бренд»
Измерение «Категория»
Ключ года (FK)
Измерение «Квартал»
Ключ финансового года (FK)
Измерение «Отдел»
Ключ финансового месяца (FK)
Измерение «Год»
Измерение «Финансовый год»
Ключ продукта (FK)
Измерение «Тип упаковки»
Ключ бренда (FK)
Ключ категории (FK)
Измерение «Финансовый месяц»
Ключ отдела (FK)
Ключ типа упаковки (FK)
Ключ магазина (FK)
Измерение «Магазин»
Ключ страны магазина (FK)
Ключ штата магазина (FK)
Измерение «Страна магазина»
Измерение «Штат магазина»
Ключ региона магазина (FK)
Ключ плана этажа магазина (FK)
Измерение «Район магазина»
Измерение «Промоакция»
Ключ района магазина (FK)
Ключ промоакции (FK)
Параметр «Скидка рекламной акции»
Измерение «Тип рекламного носителя»
Ключ типа скидки акции(FK)
Измерение «Область магазина»
Измерение «План этажа магазина»
Ключ типа рекламного носителя (FK)
Номер транзакции POS (DD)
Количество продаж
Сумма расширенной скидки в долларах
Сумма расширенных продаж в долларах
Сумма расширенных затрат в долларах
Рис. 3-17. Таблицы фактов «сороконожка» со «слишком большим количеством
нормализованных измерений»
Даже несмотря на компактность, таблица фактов — гигант в размерной модели. Создание таблицы фактов со слишком большим количеством измерений
приводит к значительному увеличению требований к дисковому пространству
таблицы фактов. Хотя денормализованные таблицы измерений занимают дополнительное пространство, факт потребления табличного пространства таблицами
фактов вызывает беспокойство, поскольку это ваша самая большая таблица, она
больше остальных на несколько порядков. Невозможно эффективно проиндексировать громоздкий составной ключ, такой как в примере с «сороконожкой».
Многочисленные соединения — проблема как для удобства использования, так
и для производительности запросов.
Розничные продажи
161
Большинство бизнес-процессов можно представить в таблице фактов с помощью менее чем 20 измерений. Если дизайн имеет 25 или более измерений, вам
следует искать способы объединить коррелированные измерения в одно. Идеально коррелированные атрибуты, такие как уровни иерархии, а также атрибуты
с разумной статистической корреляцией, должны быть частью одного измерения. Комбинирование измерений — хорошее решение, когда полученное новое
измерение заметно меньше, чем декартово произведение отдельных измерений.
ПРИМЕЧАНИЕ Очень большое количество измерений обычно — признак
того, что несколько измерений не полностью независимы и они должны быть
объединены в одно измерение. Представление элементов единой иерархии
в виде отдельных измерений в таблице фактов — ошибка при моделировании
измерений.
Использование колоночных баз данных может снизить затраты на запросы
и хранение, связанные с конструкциями таблиц фактов — «сороконожек».
Вместо того чтобы хранить каждую строку таблицы, колоночная база данных
хранит каждый столбец таблицы как непрерывный объект, который полностью
проиндексирован для доступа. Хотя базовое физическое хранилище колоночное,
на уровне запроса таблица состоит из знакомых строк. Но при запросе с диска
фактически извлекаются только названные столбцы, а не вся строка, как в более
традиционной реляционной базе данных, ориентированной на строки. Колоночные базы данных гораздо более терпимы к только что описанным таблицам
фактов — «сороконожкам»; однако возможность просмотра иерархически связанных атрибутов измерений может быть недоступна.
Выводы
Эта глава была вашим первым опытом создания размерной модели. Независимо
от отрасли мы настоятельно рекомендуем четырехэтапный процесс проектирования размерных моделей. Помните, что особенно важно четко указать зернистость, связанную с размерной схемой. Загрузка таблицы фактов с атомарными
данными обеспечивает максимальную гибкость, поскольку данные можно суммировать во всех направлениях. Как только таблица фактов будет ограничена
более агрегированной информацией, вы столкнетесь с преградами, когда предположения агрегирования окажутся недействительными. Также чрезвычайно
важно заполнить таблицы измерений подробными, надежными описательными
атрибутами для аналитической фильтрации и маркировки.
162
Глава 3
В следующей главе мы останемся в сфере розничной торговли, чтобы обсудить методы измерения второго бизнес-процесса внутри организации, гарантируя, что ваши предыдущие усилия будут задействованы, избегая при этом сильно
локализованных и неприменимых в других компонентах решений.
4
Склад
В
главе 3 мы разработали размерную модель торговых операций в крупной
продуктовой сети. В этой главе мы остаемся в той же отрасли, но продвигаемся вверх по цепочке ценности, чтобы заняться инвентаризацией. Проекты,
разработанные в этой главе, применимы к широкому набору процессов инвентаризации как внутри, так и вне отрасли розничной торговли.
Что еще более важно, в этой главе подробно обсуждается архитектура шины
корпоративного хранилища данных. Архитектура шины необходима для создания интегрированной системы DW/BI. Она обеспечивает основу для планирования общей среды, даже если она будет создаваться постепенно. Мы подчеркнем
важность использования общих согласованных измерений и фактов в размерных
моделях и в заключение будем вдохновлять вас на принятие программы управления корпоративными данными.
В главе 4 обсуждаются следующие концепции:
■ представление организационных цепочек ценности с помощью серии размерных моделей;
■ полуаддитивные факты;
■ три типа таблиц фактов: периодические снимки, транзакции и накопительные снимки;
■ архитектура шины корпоративного хранилища данных и матрица шин;
■ матрица возможностей / заинтересованных сторон;
■ согласованные измерения и факты, их влияние на методы гибкой разработки;
■ важность управления данными.
Введение в цепочку ценности
У большинства организаций есть основная цепочка ценности ключевых бизнес-процессов. Цепочка ценности определяет естественное логическое течение
164
Глава 4
основной деятельности организации. Например, розничный продавец выдает
заказы на поставку производителям товаров. Товар доставляется на склад продавца, где хранится на складе. Затем его перевозят в отдельный магазин, где продукты снова остаются на складе до тех пор, пока потребитель не совершит покупку. На рис. 4-1 показан фрагмент цепочки ценности розничного продавца.
Очевидно, что продукты, полученные от производителей, которые доставляют
непосредственно в розничный магазин, обходят складские процессы.
Отправка заказа
на поставку
производителю
Получение
складской
поставки
Инвентаризация
продуктов
на складе
Получение
товара на склад
в розничном магазине
Инвентаризация
продуктов
в розничном магазине
Розничные
продажи
Рис. 4-1. Фрагмент цепочки ценности розничного продавца
Операционные исходные системы обычно создают транзакции, или моментальные снимки, на каждом этапе цепочки ценности. Основная цель большинства аналитических систем DW/BI — отслеживать результаты производительности этих ключевых процессов. Поскольку каждый процесс создает уникальные
метрики в уникальные интервалы времени с уникальной детализацией и размерностью, он обычно порождает по крайней мере одну атомарную таблицу фактов.
С этой стороны цепочка ценностей обеспечивает общее представление об общей архитектуре данных для корпоративной среды DW/BI. Мы посвятим больше времени этой теме в разделе «Интеграция цепочки ценности» далее в этой
главе.
Склад
165
Модели инвентаризации
А пока мы обсудим несколько дополнительных моделей инвентаризации. Первый —
это периодический моментальный снимок запасов, в котором уровни товарных запасов измеряются через регулярные промежутки времени и помещаются в виде отдельных строк в таблицу фактов. Эти строки периодических снимков появляются
с течением времени в виде серии слоев данных в размерной модели подобно тому,
как геологические слои представляют накопление отложений в течение длительных
периодов. Затем мы обсудим вторую модель инвентаризации, в которой регистрируется каждая транзакция, влияющая на уровень запасов при перемещении товаров
по складу. Наконец, в третьей модели мы опишем моментальный снимок накопления
запасов, где строка таблицы фактов вставляется для каждой поставки продукта, а затем строка обновляется по мере того, как продукт перемещается по складу. Каждая
модель рассказывает свою историю. Для некоторых аналитических требований могут быть подходящими одновременно две или даже все три модели.
Периодический моментальный снимок инвентаризации
Вернемся к нашему исследованию розничной торговли. Оптимизация запасов
в магазинах может иметь большое влияние на прибыльность сети. Обеспечение
того, чтобы нужный товар был в нужном магазине в нужное время, сводит к минимуму дефицит (когда товар отсутствует на полке в магазине) и снижает общие затраты на хранение. Розничный продавец хочет анализировать ежедневные
объемы запасов по продуктам и магазинам.
Пришло время снова запустить четырехэтапный процесс размерного проектирования. Бизнес-процесс, который мы хотим проанализировать, — это периодическое создание моментальных снимков запасов товаров на складах. Самый
элементарный уровень детализации, обеспечиваемый операционной системой
инвентаризации, — это ежедневная инвентаризация каждого продукта в каждом
магазине. Из такого объявления зернистости сразу вытекают следующие измерения: «Дата», «Продукт», «Магазин». Это часто случается с периодическими
таблицами фактов моментальных снимков, где вы не можете выразить детализацию в контексте транзакции, поэтому вместо этого требуется список измерений. В этом тематическом исследовании нет дополнительных описательных измерений на этой степени детализации. Измерения промоакций обычно связаны
с движением продукта, например, когда продукт заказан, получен или продан,
но не с запасами товара.
Самый простой взгляд на инвентаризацию включает только один факт: количество товара в наличии. Это приводит к исключительно чистой размерной
конструкции, как показано на рис. 4-2.
166
Глава 4
Измерение «Дата»
Ключ даты (PK)
...
Измерение «Магазин»
Факт моментального
снимка склада магазина
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Количество на складе
Измерение «Продукт»
Ключ продукта (PK)
Тип требований
к хранению
...
Ключ магазина (PK)
...
Рис. 4-2. Схема периодических снимков инвентаризации магазина
Таблица измерения даты в этом тематическом исследовании идентична таблице, разработанной в главе 3 для розничных продаж. Измерения «Продукт»
и «Магазин» могут быть дополнены другими атрибутами, которые будут полезны для анализа запасов. Например, измерение «Продукт» можно дополнить
столбцами «Минимальное количество для повторного заказа» или «Требования к хранению», если это постоянные и дискретные дескрипторы каждого
продукта. Если минимальное количество для повторного заказа варьируется для
продукта в зависимости от магазина, его нельзя включить в качестве атрибута
измерения «Продукт». В измерение «Магазин» вы можете включить атрибуты
для определения квадратных футов складских помещений, где хранятся замороженные и охлажденные продукты.
Даже такая простая схема, как на рис. 4-2, может быть очень полезной. Многочисленные выводы можно получить, если часто измерять уровни запасов для
множества продуктов во многих местах. Тем не менее эта таблица фактов периодических моментальных снимков сталкивается с серьезной проблемой, которая
не встречалась в таблице фактов транзакций по продажам в главе 3. Таблица фактов продаж была довольно разреженной, потому что вы не продаете абсолютно
все товары каждому покупателю. Склад, с другой стороны, генерирует плотные
таблицы моментальных снимков. Поскольку розничный торговец стремится избегать ситуаций отсутствия на складе товара, в таблице фактов может быть строка
для каждого продукта в каждом магазине каждый день. В этом случае вы должны
включить нулевые измерения отсутствия на складе в виде явных строк. Для продуктового ретейлера с 60 000 позиций, хранящихся в 100 магазинах, при каждой
загрузке таблицы фактов каждую ночь будет вставляться примерно 6 миллионов
строк (60 000 продуктов × 100 магазинов). Однако, поскольку ширина строки
составляет всего 14 байтов, таблица фактов будет увеличиваться только на 84 МБ
с каждой загрузкой данных.
Хотя объемы данных в этом случае управляемы, плотность некоторых периодических моментальных снимков может потребовать компромисса. Возможно,
наиболее очевидный — уменьшение частоты моментальных снимков с течением
Склад
167
времени. Может оказаться приемлемым сохранить инвентаризацию за последние
60 дней на ежедневном уровне, а затем вернуться к менее детализированным еженедельным снимкам для исторических данных. Таким образом, вместо хранения
1095 моментальных снимков в течение трехлетнего периода их общее количество может быть уменьшено до 208 снимков; 60 ежедневных и 148 еженедельных снимков должны храниться в двух отдельных таблицах фактов, учитывая их
уникальную периодичность.
Полуаддитивные факты
Мы подчеркнули важность аддитивности фактов в главе 3. В схеме моментального снимка склада количество в наличии может быть суммировано по продуктам или магазинам и привести к действительной сумме. Однако уровни запасов
не складываются по датам, потому что они представляют собой моментальные
снимки уровня или баланса в определенный момент времени. Поскольку уровни
запасов (и все формы бухгалтерских счетов) складываются по некоторым параметрам, но не по всем, мы называем их полуаддитивными фактами.
Полуаддитивный характер фактов об остатках запасов становится еще более
понятным, если вы подумаете об остатках на текущих счетах. Предположим, что
в понедельник у вас на счете 50 долларов. Во вторник баланс остается без изменений. В среду вы вносите еще 50 долларов, так что теперь баланс 100 долларов. До конца недели вы не производили никакой активности на своем счете. В пятницу вы не можете просто сложить дневные остатки в течение недели
и объявить, что конечный остаток равен 400 долларов (из расчета $50 + $50 +
$100 + $100 + $100). Самый полезный способ объединения остатков на счетах
и уровней запасов по датам — их усреднение (в результате получается средний
остаток в 80 долларов в примере выше). Вы, вероятно, встречали средний дневной баланс в ежемесячной сводке по счету от вашего банка.
ПРИМЕЧАНИЕ Все показатели, которые регистрируют статический уровень
(уровни запасов, остатки на финансовых счетах и показатели интенсивности, такие как комнатная температура), по своей природе неаддитивны по измерению
даты и, возможно, по другим измерениям. В этих случаях показатель может быть
агрегирован по датам путем усреднения значения по периоду времени.
К сожалению, вы не можете использовать функцию SQL AVG для вычисления среднего значения по периоду времени. Эта функция усредняет по всем
строкам, полученным запросом, а не только по количеству дат. Например, если
запрос запрашивал средний запас для кластера из трех продуктов в четырех магазинах за семь дат (например, средний ежедневный запас бренда в географическом
168
Глава 4
регионе в течение недели), функция SQL AVG разделит суммарный запас стоимость на 84 (3 товара × 4 магазина × 7 дат). Очевидно, что правильный ответ —
разделить суммарную стоимость запасов на 7, то есть на количество дневных периодов времени.
Продукты OLAP предоставляют возможность определять правила агрегирования внутри куба, поэтому полуаддитивные метрики, такие как баланс, менее
проблемно обрабатывать, если данные развертываются через кубы OLAP.
Расширенные сведения о запасах
Упрощенное представление в таблице фактов периодических снимков инвентаризации позволяет вам видеть временные ряды уровней остатков товаров на складе.
Для большей части анализа запасов одного количества в наличии недостаточно.
«Количество в наличии» необходимо использовать вместе с дополнительными
фактами для измерения скорости движения запасов и разработки других интересных показателей, таких как оборот товара и количество дней поставки.
Если в каждую строку фактов добавить проданное количество (или, что эквивалентно, количество, отгруженное для конкретного склада), можно было бы
рассчитать оборот и количество дней поставки. Для ежедневных снимков запасов дневной оборот рассчитывается делением проданного количества на количество в наличии. Для длительного периода времени, например года, оборот
представляет собой общее проданное количество, деленное на среднесуточное
количество в наличии. Количество дней поставки рассчитывается аналогичным
образом. За определенный промежуток времени количество дней поставки —
это конечное количество в наличии, деленное на среднее проданное количество.
Помимо проданного количества, аналитиков также интересует расширенная
стоимость запасов по себестоимости, а также цена товара при последней продаже. Первоначальный периодический снимок изображен на рис. 4-3.
Измерение «Дата»
Ключ даты (PK)
...
Измерение «Магазин»
Ключ магазина (PK)
...
Факт моментального
снимка склада магазина
Ключ даты (FK)
Ключ продукта (FK)
Ключ магазина (FK)
Количество на складе
Продано (шт.)
Стоимость запасов в долларах
по себестоимости
Стоимость запасов в долларах
по последней цене продажи
Измерение «Продукт»
Ключ продукта (PK)
...
Рис. 4-3. Улучшенный периодический снимок остатков товара
Склад
169
Обратите внимание, что количество в наличии полуаддитивное, но все
остальные метрики в расширенном периодическом снимке полностью аддитивны. Количество проданного (шт.) увеличено до ежедневной детализации снимка.
Столбцы оценки — расширенные, аддитивные количества. В некоторых схемах
периодических моментальных снимков инвентаризации полезно хранить начальный баланс, изменение запасов или дельту вместе с конечным балансом. В этом
сценарии балансы снова полуаддитивные, тогда как дельты полностью аддитивны по всем измерениям.
Периодический моментальный снимок — это наиболее распространенная
схема для инвентаризации. Мы кратко обсудим две альтернативные точки зрения, которые дополняют только что созданный моментальный снимок остатков
запасов. Для изменения темпа, вместо того чтобы описывать эти модели в контексте запасов розничного магазина, мы продвинемся вверх по цепочке ценности, чтобы обсудить запасы, расположенные на складах.
Операции с запасами
Второй способ моделирования бизнес-процесса инвентаризации — записывать
каждую транзакцию, которая влияет на запасы. Инвентаризационные операции
на складе могут включать следующее:
1. Получите товар.
2. Поместите продукт в отсек для осмотра.
3. Выпустите продукт из отсека для осмотра.
4. Верните продукт поставщику из-за неудачной проверки.
5. Поместите продукт в корзину.
6. Возьмите продукт из корзины.
7. Упакуйте товар для отгрузки.
8. Отправьте товар покупателю.
9. Получить товар от покупателя.
10. Верните продукт на склад из возврата клиента.
11. Удалите товар из списка инвентаризации.
Каждая складская транзакция определяет дату, продукт, склад, поставщика,
тип транзакции и, в большинстве случаев, единственную сумму, представляющую
влияние на количество запасов, вызванное транзакцией. Предположим, что зернистость таблицы фактов составляет одну строку на транзакцию инвентаризации; тогда результирующая схема проиллюстрирована на рис. 4-4.
170
Глава 4
Факт транзакции на складе
Измерение «Дата»
Измерение «Склад»
Ключ склада (FK)
Номер склада (NK)
Название склада
Адрес склада
Город склада
Город — штат склада
Штат склада
Почтовый индекс склада
Зона склада
Общая площадь склада, метры
...
Ключ даты (FK)
Ключ продукта (FK)
Ключ склада (FK)
Ключ типа инвентаризационной
операции (FK)
Номер инвентарной операции (DD)
Сумма складской операции
в долларах
Измерение «Продукт»
Измерение «Тип складской операции»
Ключ типа инвентаризационной
операции (FK)
Тип инвентаризационной
операции Описание
Тип инвентаризационной
операции Группа
Рис. 4-4. Модель транзакции складских запасов
Хотя таблица фактов транзакций проста, она содержит подробную информацию, отражающую индивидуальные манипуляции с запасами. Таблица фактов
транзакций полезна для измерения частоты и времени определенных типов транзакций, чтобы ответить на вопросы, которые оставались без ответа при использовании менее детализированного периодического снимка.
Даже в этом случае непрактично использовать таблицу фактов транзакций
в качестве единственной основы для анализа складских показателей. Хотя теоретически возможно восстановить точную позицию запасов в любой момент,
пройдя все возможные транзакции вперед из известной позиции запасов, это
слишком громоздко и непрактично для сложных аналитических вопросов, которые охватывают даты, продукты, склады или поставщиков.
ПРИМЕЧАНИЕ Помните, что жизнь — это не только транзакции. Некото-
рые формы таблицы моментальных снимков, чтобы дать более общее представление о процессе, часто дополняют таблицу фактов транзакции.
Прежде чем оставить таблицу фактов транзакций, наш пример предполагает, что каждый тип транзакции, положительно или отрицательно влияющий
на уровни запасов, имеет постоянную размерность: дату, продукт, склад, поставщика и тип транзакции. Мы понимаем, что некоторые типы транзакций могут
иметь различную размерность в реальном мире. Например, грузоотправитель
может быть связан со складскими накладными и отгрузками; информация о клиенте, вероятно, связана с отгрузкой и возвратом покупателя. Если размерность
транзакций варьируется в зависимости от события, то следует разработать серию
связанных таблиц фактов, а не собирать все складские транзакции в одной таблице фактов.
Склад
171
ПРИМЕЧАНИЕ Если метрики имеют различную естественную зернистость
или размерность, они, вероятно, результат отдельных процессов, которые следует моделировать как отдельные таблицы фактов.
Накопительный моментальный снимок запасов
Последняя модель инвентаризации — это моментальный снимок с накоплением. Таблицы фактов накопительных снимков используются для процессов,
у которых есть определенное начало, определенный конец и идентифицируемые
промежуточные этапы. В этой модели запасов одна строка помещается в таблицу фактов, когда конкретный продукт поступает на склад. Размещение продукта
отслеживается в этой единственной строке фактов, пока он не покинет склад.
В этом примере модель накопительных моментальных снимков возможна только
в том случае, если вы можете надежно отличить продукты, полученные в одной
отгрузке, от продуктов, полученных позже; это также уместно, если вы отслеживаете движение продукта по серийному номеру продукта или номеру партии.
Теперь предположим, что уровни запасов для партии продукта отражают серию
четко определенных событий или этапы по мере ее прохождения по складу, таких как
получение, проверка, размещение на складе и отгрузка. Как показано на рис. 4-5, таблица фактов моментального снимка инвентаризации с множеством дат и фактов сильно отличается от транзакционной (периодической) схемы моментальных снимков.
Накопительные факты накладных
Измерение «Дата получения»
Номер товарной квитанции (DD)
Ключ даты получения (FK)
Измерение «Дата проверки»
Ключ даты проверки (FK)
Ключ даты размещения (FK)
Измерение «Дата размещения»
Ключ даты первоначальной отгрузки (FK)
Ключ даты последней отгрузки (FK)
Измерение
«Дата первоначальной отгрузки»
Ключ продукта (FK)
Измерение
«Дата последней отгрузки»
Ключ поставщика (FK)
Измерение «Продукт»
Ключ склада (FK)
Измерение «Склад»
Полученное количество
Количество проверено
Количество, возвращенное поставщику
Количество в корзине
Количество отправлено клиенту
Количество, возвращенное клиентом
Количество, возвращенное на склад
Количество поврежденных
Задержка между поступлением и проверкой
Задержка от поступления до добавления в корзину
Задержка от поступления до первой отгрузки
Задержка от начальной до последней отгрузки
Рис. 4-5. Накопительный моментальный снимок запасов
Измерение «Поставщик»
Глава 4
172
Накопительная таблица фактов моментальных снимков предоставляет обновленный статус партии по мере ее прохождения через стандартные этапы,
представленные несколькими внешними ключами с датой. Каждая строка таблицы фактов накопительного моментального снимка многократно обновляется
до тех пор, пока продукты, полученные в партии, не будут полностью исчерпаны
на складе, как показано на рис. 4-6.
Строка с фактами вставлена при получении товара:
Номер Ключ даты Ключ даты Ключ даты
Ключ
чека
получения проверки
размещения продукта
101
20130101
0
0
Полученное
количество
1
100
Задержка между
поступлением
и проверкой
Задержка
от поступления
до добавления
в корзину
Задержка
от поступления
до добавления
в корзину
Строка фактов обновляется при проверке партии:
Номер Ключ даты
чека
получения
101
20130101
Ключ даты
проверки
Ключ даты
размещения
Ключ
продукта
Полученное
количество
Задержка между
поступлением
и проверкой
20130103
0
1
100
2
Строка фактов обновляется, когда партия помещается в корзину:
Номер Ключ даты
чека
получения
101
20130101
Ключ даты
проверки
Ключ даты
размещения
Ключ
продукта
Полученное
количество
Задержка между
поступлением
и проверкой
Задержка
от поступления
до добавления
в корзину
20130103
20130104
1
100
2
3
Рис. 4-6. Эволюция накопленной строки фактов моментального снимка
Типы таблиц фактов
Транзакция
Периодический снимок
Накопительные снимки
Периодичность
Дискретный момент
транзакции во времени
Повторяющиеся снимки
через регулярные
предсказуемые интервалы
Неопределенный промежуток
времени между этапами
рабочего процесса
Зернистость
1 строка на транзакцию
или строку транзакции
1 строка за период снимка
плюс другие измерения
1 строка на рабочий процесс
Измерение
«Дата»
Дата операции
Дата снимка
Факты
Производительность
транзакции
Суммарная производительность Производительность процесса
за временной интервал
Множественные даты
ключевых этапов конвейера
Плотность
Разреженный или плотный, Предсказуемо плотная
таблицы фактов в зависимости от активности
Разреженный или плотный,
в зависимости от производительности процесса
Никаких обновлений,
Никаких обновлений,
Обновления
таблицы фактов кроме исправления ошибок кроме исправления ошибок
Обновляется при возникновении активности конвейера
Рис. 4-7. Сравнение типов таблиц фактов
Существует всего три основных типа таблиц фактов: транзакция, периодический
моментальный снимок и накопительный моментальный снимок. Удивительно,
Склад
173
но эта простая закономерность действительна независимо от отрасли. Все три
типа служат своей полезной цели; вам часто требуются две дополнительные таблицы фактов, чтобы получить полное представление о бизнесе, однако управление и ритм работы с тремя таблицами фактов сильно различаются. На рис. 4-7
сравниваются эти три варианта.
Таблицы фактов транзакций
Самый фундаментальный взгляд на бизнес-операции — на уровне отдельной
операции или транзакции. Эти таблицы фактов представляют событие, которое
произошло в определенный момент времени. Строка существует в таблице фактов для данного покупателя или продукта только в том случае, если произошло
событие транзакции. И наоборот, конкретный покупатель или продукт, скорее
всего, связан с несколькими строками в таблице фактов, так как мы надеемся, что
покупатель или продукт участвует более чем в одной транзакции.
Данные транзакции легко вписываются в размерную структуру. Данные атомарных транзакций — это наиболее естественно размерные данные, позволяющие анализировать поведение с максимальной детализацией. После того как
транзакция была размещена в таблице фактов, вы, как правило, не посещаете ее
повторно.
Убедившись в прелести подробнейшей детализации транзакций, вы можете
подумать, что все, что вам нужно, — это большой и быстрый сервер для обработки подробных мелочей транзакций, и ваша работа окончена. К сожалению, даже
с данными на уровне транзакций есть вопросы бизнеса, на которые не получится
ответить, используя только эти детали. Как указывалось ранее, вы не можете выжить только за счет транзакций.
Таблицы фактов периодических снимков
Периодические снимки состояния необходимы, чтобы видеть совокупную производительность бизнеса через регулярные предсказуемые промежутки времени.
В отличие от таблицы фактов транзакции, где строка загружается для каждого
возникновения события, с периодическим снимком вы запечатлеваете (отсюда
и терминология фотоснимков) активность в конце дня, недели или месяца, а затем другой снимок в конце дня, недели или месяца в конце следующего периода
и так далее. Периодические снимки последовательно помещаются в таблицу фактов. Таблица фактов периодических снимков — часто единственное место, где
можно легко получить регулярное предсказуемое представление о долгосрочных
тенденциях производительности.
Когда транзакции приравниваются к небольшим частям доходов, вы можете
легко перейти от отдельных транзакций к ежедневному снимку, просто суммируя
174
Глава 4
транзакции. В этой ситуации периодический снимок представляет собой совокупность транзакционной активности, имевшей место в течение определенного
периода; вы создадите снимок, только если это необходимо по соображениям
производительности. В этом случае дизайн таблицы моментальных снимков тесно связан с дизайном сопутствующей таблицы транзакций. Эти таблицы фактов
имеют много общих таблиц измерений; снимок обычно имеет меньше измерений в целом. И наоборот, в обобщенной периодической таблице моментальных
снимков обычно больше фактов, чем в таблице транзакций, потому что любая
активность в указанный период важна для метрики в периодическом моментальном снимке.
Однако во многих компаниях детали транзакций нелегко обобщить для
представления показателей эффективности управления. Как вы видели в этом
тематическом исследовании инвентаризации, сканирование транзакций потребует чрезвычайно много времени, а логика, необходимая для интерпретации
влияния различных видов транзакций на уровни запасов, может быть ужасно
сложной, если предположить, что у вас даже есть доступ к необходимой исторической информации. Периодический снимок снова приходит на помощь, чтобы
предоставить руководству быстрое и гибкое представление об уровнях запасов.
Будем надеяться, что данные для этой схемы моментального снимка поступают
непосредственно из операционной системы, которая обрабатывает эти сложные вычисления. В противном случае система ETL должна также реализовать
эту сложную логику, чтобы правильно интерпретировать влияние каждого типа
транзакции.
Накопительные таблицы фактов моментальных снимков
И, наконец, не менее важный третий тип таблиц фактов — накопительный снимок. Хотя, возможно, он используется не так часто, как два других типа таблиц
фактов, накопительные снимки могут быть очень полезными. Накопительные
моментальные снимки представляют процессы, которые имеют определенное
начало и определенный конец вместе со стандартным набором промежуточных
шагов. Накопление снимков наиболее удобно, когда бизнес-пользователи хотят
выполнить анализ рабочего процесса или конвейера.
Накапливаемые моментальные снимки всегда имеют несколько внешних
ключей с датой, представляющих предсказуемые основные события или этапы
процесса; иногда есть дополнительный столбец даты, который указывает, когда
строка снимка последний раз обновлялась. Как мы обсудим в главе 6, каждая
из этих дат поддерживается с помощью ролевых измерений «Дата». Поскольку
большая часть этих дат неизвестна при первой загрузке строки фактов, для неопределенных дат используется суррогатный ключ даты по умолчанию.
Склад
175
Задержки между этапами и количество этапов
Поскольку накопительные моментальные снимки часто представляют эффективность и прошедшее время рабочего процесса или конвейера, таблица фактов обычно содержит показатели, представляющие длительность или отставание между
ключевыми этапами. Было бы сложно ответить на вопросы о продолжительности,
используя таблицу фактов транзакции, потому что вам нужно было бы сопоставить
строки для расчета промежутков времени. Иногда метрики запаздывания — это
просто необработанная разница между датами этапов или отметками даты/времени. В других ситуациях расчет отставания усложняется за счет учета рабочих
и праздничных дней. Таблицы фактов накопления моментальных снимков иногда
включают счетчики завершения этапов, которые принимают значения 0 или 1.
Наконец, накопленные снимки часто имеет внешний ключ к измерению статуса,
которое обновляется, чтобы отразить последний статус конвейера.
Накопление обновлений снимков и кубов OLAP
В отличие от других типов таблиц фактов вы намеренно пересматриваете накопленные строки таблицы фактов моментального снимка, чтобы обновить их. В отличие от периодического снимка, в котором сохраняются предыдущие снимки,
накопительный снимок просто отражает актуальный статус и показатели. При
использовании накопительных моментальных снимков не предпринимаются попытки приспособиться к сложным сценариям, которые возникают нечасто. Анализ этих крайних случаев всегда можно выполнить с помощью таблицы фактов
транзакции.
Стоит отметить, что накопление моментальных снимков обычно проблематично для кубов OLAP. Поскольку обновления накапливаемого моментального
снимка приводят к изменению как фактов, так и внешних ключей измерения,
большую часть куба потребуется повторно обработать с обновлениями этих моментальных снимков, если только строка фактов не загружается только после завершения этапа конвейера.
Дополнительные типы таблиц фактов
Иногда накапливающиеся и периодические моментальные снимки работают
вместе, например, когда вы постепенно создаете ежемесячный моментальный
снимок, добавляя эффект ежедневных транзакций к скользящему накапливающемуся моментальному снимку, а также сохраняете исторические данные за 36 месяцев в периодическом моментальном снимке. В идеале, когда наступает последний
день месяца, моментальный снимок с накоплением просто становится новым
обычным месяцем во временном ряду, а на следующий день запускается новый
снимок с накоплением. Транзакции и снимки — это инь и ян пространственного
176
Глава 4
дизайна. Таблицы фактов транзакций и сопутствующих моментальных снимков,
используемые вместе, дают полное представление о бизнесе. Оба необходимы,
потому что часто нет простого способа объединить эти две противоположные
точки зрения в одной таблице фактов. Хотя существует некоторая теоретическая
избыточность данных между таблицами транзакций и таблицами моментальных
снимков, вы не должны возражать против такой избыточности, потому что ваша
миссия как создателей DW/BI — публиковать данные, чтобы организация могла
их эффективно анализировать. Эти отдельные типы таблиц фактов предоставляют разные точки зрения на одну и ту же историю. Удивительно, но для описания
всех случаев использования в данной книге достаточно этих трех типов таблиц.
Интеграция цепочки ценности
Теперь, когда мы завершили проектирование трех моделей для склада, давайте
вернемся к нашему предыдущему обсуждению цепочки ценности розничного
продавца. Как бизнес, так и ИТ-организации обычно заинтересованы в интеграции цепочки ценностей. Управляющим бизнесом необходимо анализировать
бизнес-процессы, чтобы лучше оценивать производительность. Например, многочисленные проекты DW/BI нацелены на лучшее понимание поведения клиентов с точки зрения сквозной перспективы. Очевидно, для этого требуется способность последовательно просматривать информацию о клиентах в различных
процессах, таких как расценки, заказы, выставление счетов, платежи и обслуживание клиентов. Точно так же организации хотят анализировать свои продукты
в разных процессах или своих сотрудников, студентов, поставщиков и т. д.
ИТ-менеджеры признают, что интеграция необходима для выполнения договоренностей, связанных с хранением данных и бизнес-аналитикой. Многие
считают своей основной обязанностью управление информационными активами организации. Они знают, что не выполняют свои обязанности, если позволяют разрастаться автономным неинтегрированным базам данных. Помимо
удовлетворения потребностей бизнеса, ИТ также выигрывают от интеграции,
поскольку она позволяет организации лучше использовать ограниченные ресурсы и повышать эффективность за счет повторного использования компонентов.
К счастью, руководители высшего звена, которые обычно больше всего заинтересованы в интеграции, также обладают необходимым организационным влиянием и экономическими рычагами, чтобы это произошло. Если они не придают
большого значения интеграции, вы столкнетесь с гораздо более серьезной организационной проблемой, или, проще говоря, ваш проект интеграции, вероятно,
потерпит неудачу. Менеджер DW/BI не должен полностью отвечать за достижение организационного консенсуса для интеграции по всей цепочке ценностей.
Склад
177
Политическая поддержка высшего руководства важна; она снимает с крючка менеджера DW/BI и перекладывает бремя на плечи высшего руководства, где оно
и должно быть.
В главах 3 и 4 мы смоделировали данные нескольких процессов цепочки ценности розничного продавца. Хотя отдельные таблицы фактов в отдельных схемах
измерений представляют данные каждого процесса, модели имеют несколько
общих бизнес-измерений: «Дата», «Продукт» и «Магазин». Мы логически
представили это разделение измерений на рис. 4-8. Использование общих измерений абсолютно необходимо для проектирования размерных моделей, которые
можно интегрировать.
Измерение «Магазин»
Измерение «Дата»
Факты транзакций
розничных продаж
Факты снимков запасов
розничного магазина
Измерение «Промоакция»
Измерение «Продукт»
Измерение «Склад»
Факты транзакций склада
Рис. 4-8. Совместное использование измерений между бизнес-процессами
Архитектура шины хранилища
корпоративных данных
Очевидно, что создание корпоративной системы DW/BI за одну гигантскую попытку — это слишком сложно, но построение ее в виде отдельных частей подрывает главную цель — согласованность. Для долгосрочного успеха DW/BI вам
необходимо использовать продуманный, поэтапный подход к созданию корпоративного хранилища данных. Мы придерживаемся подхода, который называется
«архитектура шины корпоративного хранилища данных».
Понимание архитектуры шины
Вопреки распространенному мнению, слово «шина» (Bus) — это не сокращение от слова «бизнес» (business); это старый термин из электроэнергетики, который сейчас используется в компьютерной индустрии. Шина — это обычная
структура, к которой все подключается и от которой все получает энергию. Шина
в компьютере — это стандартная спецификация интерфейса, которая позволяет
подключать дисковод, DVD или любое количество других специализированных
карт или устройств. Благодаря стандарту шины компьютера эти периферийные
178
Глава 4
устройства работают вместе и сосуществуют с пользой, даже если они были произведены в разное время разными поставщиками.
ПРИМЕЧАНИЕ Если определить стандартный интерфейс шины для среды
DW/BI, отдельные размерные модели могут быть реализованы разными группами в разное время. Отдельные предметные области бизнес-процессов соединяются и успешно сосуществуют, если соответствуют стандарту.
Если вы вернетесь к диаграмме цепочки ценности на рис. 4-1, вы можете
представить себе множество бизнес-процессов, подключенных к шине корпоративного хранилища данных, как показано на рис. 4-9. В итоге все процессы
цепочки ценности организации создают семейство размерных моделей, которые
имеют полный набор общих, согласованных измерений.
Заказы
Товары в наличии
Продажи
Дата
Продукт
Магазин
Акция
Склад
Поставщик
Отправитель
Рис. 4-9. Шина корпоративного хранилища данных с общими измерениями
Архитектура шины корпоративного хранилища данных обеспечивает рациональный подход к декомпозиции задачи планирования корпоративного
DW/BI. Главный набор стандартизованных измерений и фактов имеет единообразную интерпретацию во всей компании. Это устанавливает архитектурный
фреймворк. Затем вы можете заняться реализацией отдельных ориентированных
на один процесс размерных моделей, при этом каждая реализация будет строго
соответствовать архитектуре. По мере того как становятся доступными отдельные модели, они складываются вместе, как кусочки пазла. В какой-то момент
появится достаточно размерных моделей, чтобы оправдать разработку интегрированной корпоративной среды DW/BI. Архитектура шины позволяет менеджерам DW/BI получить лучшее из обоих миров.
Склад
179
У них есть архитектурный фреймворк, определяющий общий дизайн, но проблема была разделена на небольшие фрагменты, соответствующие бизнес-процессам,
которые могут быть реализованы в реалистичные сроки. Отдельные команды разработчиков следуют архитектуре, работая достаточно независимо и асинхронно.
Архитектура шины не зависит от технологий и платформ баз данных. Все
разновидности реляционных и основанных на OLAP размерных моделей могут
быть полноправными участниками шины корпоративного хранилища данных,
если они спроектированы с учетом согласованных измерений и фактов. Системы
DW/BI неизбежно состоят из отдельных узлов с разными операционными системами и системами управления базами данных. Разработанные согласованно, они
имеют общую архитектуру согласованных измерений и фактов, что позволяет
объединить их в единое целое.
Матрица шины корпоративного хранилища данных
Мы рекомендуем использовать матрицу шины корпоративного хранилища
данных для документирования и передачи архитектуры шины, как показано
на рис. 4-10. Некоторые называют матрицу шины матрицей соответствия или
матрицей событий, но это просто синонимы этой фундаментальной концепции
Кимбалла, впервые представленной в 1990-х годах.
X
X
X
Инвентаризация склада
X
X
X
Получить заказы на товары из магазина
X
X
X
Товары в наличии
X
X
X
Розничные продажи
X
X
X
Прогноз розничных продаж
X
X
X
Отслеживание розничной рекламы
X
X
X
X
Возврат клиентов
X
X
X
X
Возврат поставщику
X
X
X
Регистрация постоянных покупателей
X
Акци
Мага
ник
Получать складские поставки
Сотр
уд
X
зчик
X
Зака
Скла
д
X
я
Прод
укт
Выпустить заказы на закупку
зин
БИЗНЕС-ПРОЦЕССЫ
Дата
ОБЩИЕ ИЗМЕРЕНИЯ
X
X
X
X
X
X
X
X
X
X
X
X
Рис. 4-10. Пример матрицы шины корпоративного хранилища данных для
розничного продавца
180
Глава 4
При работе в табличной форме бизнес-процессы организации представлены
в виде строк матрицы. Важно помнить, что вы определяете бизнес-процессы,
а не бизнес-подразделения организации. Строки матрицы преобразуются в размерные модели, представляющие основные виды деятельности и события организации, которые часто можно распознать по их операционному источнику.
Когда пришло время заняться проектом разработки DW/BI, начните с одной
строки матрицы бизнес-процессов, потому что это минимизирует риск подписаться на чрезмерно амбициозную реализацию. Большая часть риска реализации состоит в том, что ведется работа над слишком большим количеством бизнес-процессов одновременно. Сосредоточение внимания на результатах одного
процесса, часто поддерживаемого одной базовой системой источников, снижает
риск вложения в ETL.
После перечисления отдельных бизнес-процессов вы иногда определяете
более сложные консолидированные процессы. Хотя размерные модели, которые пересекают несколько процессов, могут быть чрезвычайно полезными как
с точки зрения производительности запросов, так и с точки зрения простоты
использования, их, как правило, труднее реализовать, поскольку усилия ETL растут с каждым дополнительным основным источником данных, интегрированным в одну размерную модель. Мудрым решением будет сосредоточиться на отдельных процессах в качестве строительных блоков, прежде чем решать задачу
консолидации. Прибыльность — классический пример консолидированного
процесса, в котором отдельные факторы доходов и затрат объединяются из различных процессов, чтобы обеспечить полное представление о прибыльности.
Хотя разработка модели измерения прибыльности — захватывающая задача,
это, безусловно, не первая размерная модель, которую вы должны попытаться реализовать. Очень легко потерпеть неудачу, пытаясь соотнести все доходы
и стоимость компонентов.
Колонки матрицы шины представляют общие измерения предприятия. Часто
полезно создать список основных измерений перед заполнением матрицы, чтобы
оценить, следует ли ассоциировать какое-либо измерение с бизнес-процессом.
Количество строк матрицы и столбцов шины варьируется в зависимости от организации. Для многих матрица удивительно квадратная с примерно 25–50 рядами и сопоставимым количеством столбцов. В других отраслях, таких как страхование, столбцов, как правило, больше, чем строк.
После того как основные процессы и измерения определены, вы закрашиваете или отмечаете крестом ячейки матрицы, чтобы указать, какие столбцы связаны
с каждой строкой. Вуаля! Сразу можно увидеть логические отношения и взаимодействие между соответствующими измерениями организации и ключевыми
бизнес-процессами.
Склад
181
Использование нескольких матриц
Создание корпоративной матрицы хранилища данных — один из наиболее важных результатов реализации DW/BI. Это гибридный ресурс, который служит
нескольким целям, включая планирование архитектуры, проектирование баз
данных, координацию управления данными, оценку проектов и организационную коммуникацию.
Хотя определить строки и столбцы относительно просто, матрица корпоративной шины определяет общую архитектуру данных для системы DW/BI. Матрица предоставляет общую картину независимо от базы данных или выбранной
технологии.
Столбцы матрицы отвечают непосредственно требованиям управления основными данными и интеграции данных. Поскольку основные измерения, участвующие в размерных моделях, определяются людьми, ответственными за управление данными, и создаются командой DW/BI, вы можете представить себе их
использование в разных процессах, а не проектировать в вакууме на основе потребностей одного процесса или, что еще хуже, одного подразделения. Общие
измерения обеспечивают мощный интеграционный клей, позволяя бизнесу детализировать различные процессы.
Каждый проект внедрения, ориентированный на бизнес-процесс, постепенно выстраивает общую архитектуру. Несколько групп разработчиков могут работать над компонентами матрицы независимо и асинхронно, а вы можете быть
уверены, что эти компоненты будут работать друг с другом. Менеджеры проектов
могут просматривать строки процесса, чтобы сразу увидеть размерность каждой
размерной модели. Это полезно, поскольку они оценивают масштаб усилий, необходимых для проекта. Проект, ориентированный на бизнес-процесс с меньшим количеством измерений, обычно требует меньше усилий, особенно если
фундаментальные измерения уже находятся на своем месте.
Матрица позволяет эффективно общаться между группами управления данными и DW/BI. Что еще более важно, вы можете использовать матрицу для
передачи информации на более высокие уровни организации и за ее пределы.
Матрица — краткий, лаконичный, как конспект, результат, который визуально
передает общий план. ИТ-менеджменту необходимо понять перспективу, чтобы
координировать действия различных проектных групп и противостоять организационному желанию быстро развертывать решения для одного подразделения.
ИТ-менеджмент также должен гарантировать, что распределенные команды разработчиков DW/BI придерживаются шины архитектуры. Бизнес-менеджменту
необходимо оценить и общий план, если вы хотите, чтобы они понимали стадию развертывания DW/BI по бизнес-процессам. Кроме того, матрица иллюстрирует важность выявления экспертов из бизнеса, которые будут служить
182
Глава 4
консультантами в области управления данными для общих измерений. Благодаря
своей простоте матрица может эффективно использоваться для общения с разработчиками, архитекторами, создателями моделей и менеджерами проектов,
а также с высшими руководителями ИТ и бизнеса.
Матрица возможностей / заинтересованных сторон
Можно составить другую матрицу, которая использует те же строки бизнеспроцессов, но заменяет столбцы измерения бизнес-функциями, такими как мерчандайзинг, маркетинг, операции магазина и финансы. Исходя из требований
каждой функции ячейки матрицы заштрихованы, чтобы указать, какие бизнесфункции в каких бизнес-процессах (и проектах) заинтересованы, как показано
на рис. 4-11 в вариации матрицы возможностей / заинтересованных сторон.
Она также определяет, какие группы должны быть приглашены для обсуждения
детальных требований, размерного моделирования и спецификации BI-приложений после того, как строка, ориентированная на процесс, будет поставлена
в очередь как проект.
Логи
стик
а
Фина
X
X
X
X
Получать складские поставки
X
X
X
X
Инвентаризация склада
X
X
X
X
Получить заказы на товары из магазина
X
X
X
X
Товары в наличии
X
X
X
X
X
Розничные продажи
X
X
X
X
X
Прогноз розничных продаж
X
X
X
X
X
Отслеживание розничной рекламы
X
X
X
X
X
Возврат клиентов
X
X
X
X
Возврат поставщику
X
X
X
Регистрация постоянных покупателей
X
X
нсы
Опер
а
мага ции
зина
Выпустить заказы на закупку
Марк
етин
г
БИЗНЕС-ПРОЦЕССЫ
Мерч
анда
йзин
г
АКЦИОНЕРЫ
X
X
Рис. 4-11. Матрица возможностей/заинтересованных сторон
Общие ошибки матрицы шины
При составлении матрицы шины люди иногда спорят об уровне детализации,
выраженным каждой строкой, что приводит к следующим ошибкам:
Склад
183
■ Ориентированные на подразделения, или охватывающие чрезмерно
большой объем строки.
Строки матрицы не должны соответствовать департаментам на организационной диаграмме корпорации, представляющих функциональные группы. Некоторые отделы могут быть ответственны или остро заинтересованы в одном бизнес-процессе, но строки матрицы не должны выглядеть как
список прямых подчиненных генерального директора.
■ Ориентированные на отчеты, или слишком узко определенные строки.
С другой стороны, матрица шины не должна напоминать список запрошенных отчетов. Единый бизнес-процесс поддерживает многочисленные
анализы; строка матрицы должна ссылаться на бизнес-процесс, а не на производные отчеты или аналитику.
При определении столбцов матрицы архитекторы естественным образом попадают в аналогичные ловушки определения столбцов, которые либо слишком
широки, либо слишком узки.
■ Чрезмерно обобщенные столбцы.
Столбец «человек» в матрице шины может относиться к широкому кругу
людей от внутренних сотрудников до внешних поставщиков и контактов
с клиентами. Поскольку между этими популяциями практически нет перекрытия, это добавляет путаницы, если свалить их в единое измерение.
Точно так же нецелесообразно помещать внутренние и внешние адреса,
относящиеся к корпоративным объектам, адресам сотрудников и сайтам
клиентов, в общий столбец местоположения в матрице.
■ Отдельные столбцы для каждого уровня иерархии.
Столбцы матрицы шины должны относиться к измерениям на самом детальном уровне. Некоторые строки бизнес-процессов могут потребовать
агрегированную версию подробного измерения, например метрики моментального снимка запасов на еженедельном уровне. Вместо создания
отдельных столбцов матрицы для каждого уровня иерархии календаря используйте один столбец для дат. Чтобы выразить уровни детализации выше
ежедневного зерна, вы можете обозначить детализацию внутри матричной
ячейки; в качестве альтернативы можно подразделить столбец даты, чтобы указать иерархический уровень, связанный с каждой строкой бизнеспроцесса. Важно сохранить общую идентификацию общих измерений,
развернутых на различных уровнях детализации. Некоторые отраслевые
184
Глава 4
эксперты выступают за матрицы, которые рассматривают атрибут каждой
таблицы измерений как отдельную независимую колонку; это разрушает
концепцию измерений и приводит к совершенно неуправляемой матрице.
Изменение существующих моделей в соответствии
с матрицей шины
Недопустимо создавать отдельные размерные модели, которые игнорируют
фреймворк, связывающие их вместе. Изолированные, независимые размерные модели хуже, чем просто потерянная возможность для анализа. Они обеспечивают
доступ к несогласованным в рамках организации отчетам и еще больше закрепляют использование отчетов, которые нельзя сравнивать друг с другом. Независимые
размерные модели сами по себе становятся устаревшими реализациями; своим существованием они блокируют развитие согласованной среды DW/BI.
Так что произойдет, если вы не начинаете с чистого листа? Возможно, несколько размерных моделей были построены без учета архитектуры, использующей эти измерения. Можете ли вы сохранить ваши процессы и преобразовать их в шину архитектуры? Чтобы ответить на этот вопрос, вы должны начать
с честной оценки существующих неинтегрированных размерных структур. Как
правило, это влечет за собой встречи с отдельными группами (включая скрытые
псевдо-ИТ-группы в бизнес-организациях) для определения разрыва между текущей средой и целью организации. После того как разрыв понятен, необходимо разработать дополнительный план преобразования автономных размерных
моделей в архитектуру предприятия. План должен быть внутренне поддержан.
Старшие сотрудники ИТ и бизнес-менеджмент должны понимать текущее состояние хаоса данных, риски, которые влечет статус-кво, а также преимущества
движения вперед в соответствии с вашим планом игры. Руководство также должно понимать, что преобразование потребует значительных затрат по поддержке, ресурсам и финансированию.
Если существующая размерная модель имеет здравый дизайн, возможно, вы
можете сопоставить существующее измерение со стандартизированной версией. Исходная таблица измерений будет перестроена с помощью перекрестной
сопоставительной таблицы. Аналогичным образом таблицу фактов необходимо
будет переработать для замены исходных ключей измерения на соответствующие
ключи согласованного измерения. Конечно, если исходные и согласованные таблицы измерений содержат различные атрибуты, переработка уже существующих
приложений и запросов BI неизбежна.
Более типично, что существующие размерные модели изобилуют ошибками размерного моделирования, выходящими за рамки отсутствия соблюдения
Склад
185
стандартизированных измерений. В некоторых случаях размерная модель процессов изживает свой срок службы. Изолированные размерные модели часто
строятся для определенной функциональной области. Когда другие пытаются
использовать эти данные, они обычно обнаруживают, что размерная модель была
реализована на неподходящем уровне детализации и что ключевые измерения
отсутствуют. Усилия, необходимые для модернизации этих размерных моделей
в архитектуре корпоративной DW/BI, могут превысить усилия, направленные
на то, чтобы начать все с нуля. Как бы трудно это ни было признать, изолированные размерные модели процессов часто приходится отключать и перестраивать
в рамках правильной архитектуры шины.
Согласованные измерения
Теперь, когда вы понимаете важность архитектуры корпоративной шины, давайте дальше исследуем стандартизированные согласованные измерения, которые
служат краеугольным камнем шины, поскольку они используются в таблицах
фактов бизнес-процессов. Согласованные измерения имеют множество других
псевдонимов: общие (common) измерения, основные измерения, ссылочные
измерения и совместно используемые (shared) измерения. Согласованные измерения должны быть построены один раз в системе ETL, а затем реплицированы либо логически, либо физически во всей корпоративной среде DW/BI. При
создании чрезвычайно важно, чтобы команды разработчиков системы DW/BI
взяли на себя обязательство использовать эти измерения. Это политическое решение имеет решающее значение для обеспечения функционирования корпоративной системы DW/BI; за их использованием должен следить ИТ-директор
организации.
Горизонтальный анализ таблицы фактов
В дополнение к согласованности и возможности повторного использования согласованные измерения позволяют объединить измерения производительности
различных бизнес-процессов в одном отчете, как показано на рис. 4-12. Вы можете использовать многопроходный SQL для запроса каждой размерной модели
отдельно, а затем выполнить внешнее соединение результатов запроса на основе
общего атрибута измерения, такого как название продукта на рис. 4-12. Полное
внешнее соединение обеспечивает включение всех строк в объединенный отчет,
даже если они появляются только в одном наборе результатов запроса. Эта связь,
часто называемая горизонтальным анализом, проста, если значения атрибутов
таблицы измерений идентичны.
186
Глава 4
Описание продукта
Кол-во открытых заказов
Свежий хлеб на закваске
Цельнозерновой батон
Цельнозерновой батон в нарезке
Кол-во на складе Кол-во проданного
1201
1472
846
935
801
513
1042
922
368
Рис. 4-12. Детализация таблиц фактов с согласованными атрибутами измерений
Горизонтальная детализация поддерживается многими продуктами и платформами бизнес-аналитики. Их реализации различаются в зависимости от того,
объединяются ли результаты во временные таблицы, сервер приложений или отчет. Поставщики также используют разные термины для описания этого метода,
в том числе многопроходные запросы, множественный выбор, многофакторные
или стыковые запросы. Поскольку метрики из разных таблиц фактов объединяются в запросе горизонтальной детализации, часто любые перекрестные вычисления необходимо выполнять в приложении бизнес-аналитики после того, как
были возвращены отдельные согласованные результаты.
Согласованные измерения бывают разных видов, как описано в следующих
разделах.
Идентичные согласованные измерения
На самом базовом уровне согласованные измерения означают одно и то же со всеми возможными таблицами фактов, к которым они присоединены. Таблица измерения «Дата», связанная с фактами продаж, идентична таблице измерения
даты, связанной с фактами запасов. Идентичные согласованные измерения имеют
согласованные ключи измерений, имена столбцов атрибутов, определения атрибутов и значения атрибутов (которые преобразуются в согласованные метки отчетов
и группы). Атрибуты измерения не согласуются, если они называются «Месяц»
в одном измерении и «Название месяца» в другом; аналогичным образом они
не согласуются, если значение атрибута «июль» в одном измерении и «ИЮЛЬ»
в другом. Идентичные согласованные измерения в двух моделях могут быть одной и той же физической таблицей в базе данных. Однако, учитывая типичную
сложность технической среды системы DW/BI с несколькими платформами баз
данных, более вероятно, что измерение создается один раз в системе ETL, а затем
синхронно дублируется в каждой размерной модели. В любом случае согласованные измерения «Дата» в обеих размерных моделях имеют одинаковое количество
строк, одинаковые ключевые значения, одинаковые метки атрибутов, одинаковые
определения данных атрибутов и одинаковые значения атрибутов. Имена столбцов атрибутов должны иметь однозначные обозначения по всем измерениям.
Большинство согласованных измерений определяются естественным образом на максимально возможном уровне детализации. Зернистостью измерения
Склад
187
«Продукт» будет отдельный продукт; зернистостью измерения «Дата» будет
отдельный день. Однако иногда измерения на одном уровне зернистости не полностью согласованы. Например, для анализа запасов могут потребоваться атрибуты продукта и магазина, но они не подходят для анализа данных о розничных
продажах. Таблицы измерений по-прежнему согласованы, если ключи и общие
столбцы идентичны, но дополнительные атрибуты, используемые схемой инвентаризации, не согласованы. Горизонтальный анализ процессов с использованием
этих дополнительных атрибутов физически невозможен.
Сжатие согласованного измерения
с подмножеством атрибутов
Измерения также согласованы, если они содержат подмножество атрибутов
из более детального измерения. Сжатые сводные измерения требуются, когда
таблица фактов фиксирует показатели производительности на более высоком
уровне детализации, чем атомарное базовое измерение. Это было бы так, если бы
у вас был еженедельный снимок остатков запасов в дополнение к ежедневному
снимку. В других ситуациях факты генерируются другим бизнес-процессом
на более высоком уровне детализации. Например, процесс розничных продаж
собирает данные на уровне элементарного продукта, тогда как прогнозирование
генерирует данные на уровне бренда. Невозможно использовать одну таблицу
измерения «Продукт» для двух схем бизнес-процессов, поскольку степень их
детализации различается. Измерения «Продукт» и «Бренд» по-прежнему согласованы, если атрибуты таблицы брендов являются строгим подмножеством
атрибутов атомарной таблицы продуктов. Атрибуты, общие как для подробных,
так и для сводных таблиц измерений, такие как описания бренда и категории,
должны быть помечены, определены и оценены одинаково в обеих таблицах, как
показано на рис. 4-13. Однако первичные ключи подробной таблицы и сводной
таблицы измерений независимы.
ПРИМЕЧАНИЕ Сжатые измерения соответствуют базовому атомарному из-
мерению, если атрибуты являются строгим подмножеством атрибутов атомарного измерения.
Сжатие согласованного измерения
с подмножеством строк
Другой случай согласованного подмножества измерений имеет место, когда два
измерения находятся на одном уровне детализации, но одно представляет подмножество строк другого. Например, измерение «Корпоративный продукт» содержит строки для полного портфеля продуктов по нескольким разрозненным
188
Глава 4
направлениям бизнеса, как показано на рис. 4-14. Аналитики в отдельных компаниях могут захотеть просмотреть только свою часть корпоративного измерения,
ограниченную строками продуктов для своего бизнеса. При использовании подмножества строк они не загромождаются всем набором продуктов корпорации.
Конечно, таблица фактов, присоединенная к этому подмножеству измерения,
должна быть ограничена одним и тем же подмножеством продуктов. Если пользователь попытается использовать сжатое измерение подмножества при доступе
к таблице фактов, состоящей из полного набора продуктов, он может столкнуться с неожиданными результатами запроса, поскольку будет нарушена ссылочная
целостность. Вы должны осознавать потенциальную возможность неправильных
запросов со стороны пользователя или ошибки при использовании подмножества строк измерения. Мы более подробно остановимся на подмножествах измерений, когда будем обсуждать измерения супертипа и подтипа в главе 10.
Измерение «Продукт»
Ключ продукта (PK)
Описание товара
Артикул (натуральный ключ)
Описание бренда
Описание подкатегории
Описание категории
Описание отдела
Описание типа упаковки
Размер упаковки
Содержание жиров
Тип диеты
Масса
Единица измерения массы
...
Измерение «Бренд»
Соответствует
Ключ бренда (FK)
Описание бренда
Описание подкатегории
Описание категории
Описание отдела
Измерение «Дата»
Ключ даты (PK)
Дата
Полное описание даты
День недели
Число дня в месяце
Названия месяца в календаре
Номер календарного месяца
Календарь ГГГГ-ММ
Календарный год
Финансовая неделя
Финансовый месяц
...
Измерения «Месяц»
Соответствует
Рис. 4-13. Согласованные сжатые измерения
Ключ месяца (PK)
Названия месяца в календаре
Номер календарного месяца
Календарь ГГГГ-ММ
Календарный год
Склад
189
Измерение
корпоративного продукта
Бытовая
техника
Одежда
Детализация требует общих согласованных атрибутов.
Рис. 4-14. Согласование подмножеств измерений с одинаковой степенью
детализации
Согласованные измерения даты и месяца — уникальный пример подмножества измерений как строк, так и столбцов. Очевидно, вы не можете просто использовать одну и ту же таблицу измерения даты для ежедневных и ежемесячных
таблиц фактов из-за разницы в степени детализации. Однако измерение месяца
может состоять из строк таблицы ежедневных дат на конец месяца за исключением всех столбцов, которые не применяются при ежемесячной гранулярности,
таких как индикатор дня недели / выходного дня, дата окончания недели, индикатор праздничного дня, номер дня в пределах года и другие. Иногда индикатор
конца месяца в измерении ежедневной даты используется для облегчения создания таблицы измерения этого месяца.
Сжатые согласованные размеры на матрице шины
Матрица шины определяет повторное использование общих измерений в бизнеспроцессах. Обычно заштрихованные ячейки матрицы указывают на то, что атомарное измерение связано с данным процессом. Когда задействованы сжатые сводные
или измерения-подмножества, вы хотите усилить их согласованность атомарными
измерениями. Следовательно, вы не хотите создавать новый, не связанный ни с чем
столбец в матрице шины. Вместо этого есть два жизнеспособных подхода к представлению сжатых измерений в матрице, как показано на рис. 4-15:
1. Отметьте ячейку для атомарного измерения, но затем в текстовом виде
задокументируйте детализацию сжатия или подмножества строк внутри
ячейки.
Глава 4
190
2. Разделите столбец измерения, чтобы указать общие детали сжатия или
подмножества, такие как день и месяц, если процессы собирают данные
на обоих уровнях.
Дата
Дата
День
Выпустить заказы на закупку
X
X
Получить заказы на товары из магазина
X
Склад
X
X
Розничные продажи
X
X
Прогноз розничных продаж на месяц
X
Месяц
ИЛИ
Месяц
X
X
Рис. 4-15. Альтернативы для определения сжатых измерений на матрице шины
Ограниченная согласованность
Теперь, когда мы закончили проповедь о важности согласованных измерений,
мы обсудим ситуацию, в которой может быть нереалистично или нецелесообразно создавать согласованные измерения для организации. Если у конгломерата есть
дочерние компании, охватывающие самые разные отрасли, возможно, нет смысла
пытаться интегрироваться. Если у каждого направления бизнеса есть уникальные
клиенты и уникальные продукты и нет никакого интереса к кросс-продажам между
линиями производства, возможно, нет смысла пытаться создать корпоративную
архитектуру, потому что это не имеет решающего значения для бизнеса. Готовность
искать общее определение продукта, клиента или других основных параметров —
главная лакмусовая бумажка для организации, теоретически намеревающейся
построить корпоративную систему DW/BI. Если организация не желает согласовывать общие определения, ей не следует пытаться создать корпоративную среду
DW/BI. Было бы лучше построить отдельные автономные хранилища данных для
каждой дочерней компании. Но тогда не жалуйтесь, когда кто-то попросит «производительность всего предприятия», не следуя этой логике.
Хотя организациям может быть сложно объединить данные по разным направлениям бизнеса, обычно конечная цель — некоторая степень интеграции.
Не говорите, что это невозможно, — начните путь к согласованности. Возможно,
есть несколько атрибутов, которые можно согласовать в разных сферах деятельности. Даже если это просто описание продукта, категория и атрибут направления деятельности, общие для всех предприятий, этот подход с использованием
наименьшего общего знаменателя — все же шаг в правильном направлении. Вам
не нужно заставлять всех соглашаться со всем, что связано с измерением, прежде
чем продолжить.
Склад
191
Важность управления данными и ответственности
за данные
Мы расхвалили важность согласованных измерений, но мы также должны признать ключевую проблему: достижение корпоративного консенсуса в отношении
имен и содержимого атрибутов измерений (и обработки изменений содержимого, которые мы обсудим в главе 5). Во многих организациях бизнес-правила
и определения данных традиционно устанавливаются на уровне отделов. Последствия этого часто встречающегося отсутствия управления данными и контроля — это повсеместные разрозненные хранилища данных в отделах, которые
увековечивают похожие, но немного разные версии истины. Бизнес-менеджмент
и ИТ-менеджеры должны признать важность устранения этого недостатка, если
у вас есть шанс навести порядок в хаосе; если руководство не хочет проводить
изменения, проект никогда не достигнет своих целей.
Как только высшее руководство признает проблемы и возможности управления данными, необходимо определить ресурсы и возглавить процесс. ИТ часто
испытывает искушение попытаться возглавить атаку. Их разочаровывают изолированные проекты, когда они воссоздают данные по всей организации и потребляют бесчисленные ИТ-ресурсы и внешние ресурсы и в то же время предлагают
несовместимые решения, которые в итоге только увеличивают сложность архитектуры данных организации при значительных затратах. Хотя ИТ-отдел может
облегчить определение согласованных измерений, такое решение редко бывает
успешным в качестве единственного движущего элемента, даже если это временное назначение. ИТ-отделам просто не хватает организационных полномочий,
чтобы все происходило как надо.
Управление, ориентированное на бизнес
Чтобы повысить вероятность одобрения бизнесом, отраслевые эксперты из бизнеса должны возглавить инициативу. Руководство программой межорганизационного управления не для слабонервных. Управленцы, определенные руководством бизнеса, должны иметь следующие характеристики:
■ уважение в организации;
■ широкие знания о деятельности предприятия;
■ способность сбалансировать потребности организации с требованиями
отдела;
■ влияние и авторитет, чтобы бросить вызов статус-кво и обеспечить соблюдение правил;
■ сильные коммуникативные навыки;
■ дипломатические навыки ведения переговоров и достижения консенсуса.
192
Глава 4
Ясно, что не все подходят для этой работы! Обычно те, кто возглавляет программу корпоративного управления, высоко ценятся и пользуются спросом.
Требуются релевантные навыки, опыт и уверенность, чтобы рационализировать
различные бизнес-точки зрения и стимулировать разработку общих справочных
данных, а также необходимые организационные компромиссы. На протяжении
многих лет некоторые критиковали согласованные измерения как слишком сложные. Да, трудно заставить людей из разных уголков бизнеса прийти к соглашению
об общих именах, определениях и значениях атрибутов, но в этом суть единых
интегрированных данных. Если каждый требует собственных ярлыков и бизнесправил, у вас нет шансов выполнить обещания по установлению единственной
версии истины. Программа управления данными имеет решающее значение для
содействия культурному сдвигу от типичной изолированной среды, в которой
каждый отдел сохраняет контроль над своими данными и аналитикой, к той, где
информация распространяется и используется в рамках всей организации.
Цели управления
Одна из ключевых целей функции управления данными — достичь согласия
по определениям данных, меткам и значениям домена, чтобы все говорили на одном языке. В противном случае одни и те же слова могут описывать разные вещи;
разные слова могут описывать одно и то же; и одна и та же величина может иметь
разное значение. Установление общих основных данных (Master Data) — часто
политический вопрос; проблемы носят скорее культурный и геополитический,
чем технический характер. Определение основных описательных согласованных
измерений требует усилий. Но когда все согласовано, последующие усилия DW/
BI могут повысить эффективность работы как для обеспечения согласованности,
так и для сокращения времени цикла реализации.
Помимо определения и содержания данных, функция управления данными
также устанавливает правила и ответственность за качество и точность данных,
а также за обеспечение безопасности данных и контроль доступа.
Исторически команды DW/BI создавали «рецепты» для согласованных
измерений и управляли очисткой данных и интеграционными сопоставительными матрицами в системе ETL; операционные системы были ориентированы
на сбор точных показателей производительности, но зачастую прилагалось мало
усилий для обеспечения согласованных общих справочных данных. Системы
планирования ресурсов предприятия (ERP — Enterprise resource planning) обещали заполнить этот пробел, но многие организации по-прежнему полагаются
на отдельные, лучшие в своем классе точечные решения для удовлетворения требований ниши. В последнее время решения для оперативного управления основными данными (MDM–Master data management) позволили удовлетворить
Склад
193
потребность в централизованных основных данных в источнике, где фиксируются транзакции. Хотя технологии могут способствовать интеграции данных, они
не решают проблемы. Надежная функция управления данными — необходимая
предпосылка для согласования информации независимо от технического подхода.
Согласованные измерения и движение к Agile
Некоторые сетуют на то, что, хотя они хотят производить и совместно использовать определенные основные согласованные измерения в своих средах DW/
BI, это «просто невыполнимо». Они объясняют, что сделали бы, если бы могли,
но с учетом того, что высшее руководство сосредоточено на использовании методов гибкой разработки, невозможно найти время, чтобы достичь организационного согласия по согласованным измерениям. Вы можете перевернуть этот аргумент с ног на голову, поставив под сомнение то, что согласованные измерения
обеспечивают гибкую разработку DW/BI наряду с гибким принятием решений
(Agile).
Согласованные измерения позволяют создавать и поддерживать таблицу измерений один раз, а не повторно создавать немного отличающиеся версии в течение каждого цикла разработки. Повторное использование согласованных измерений в проектах — это то, где вы получаете рычаги для более гибкой разработки
DW/BI. По мере того как вы наполняете портфель основных согласованных измерений, разработка идет все быстрее и быстрее. Время выхода на рынок нового
источника данных бизнес-процесса сокращается, поскольку разработчики повторно используют существующие согласованные измерения. В итоге разработка
нового ETL сосредоточена почти исключительно на предоставлении большего
количества таблиц фактов, потому что соответствующие таблицы измерений уже
у вас в кармане и готовы к использованию.
Определение согласованного измерения требует организационного консенсуса и приверженности идеологии управлению данными. Но вам не нужно заставлять всех соглашаться по каждому атрибуту в каждой таблице измерений.
Как минимум вы должны определить подмножество атрибутов, которые имеют
значение для всего предприятия. Эти описательные характеристики, на которые
обычно ссылаются, становятся стартовым набором согласованных атрибутов,
обеспечивающих сквозную интеграцию. Даже всего один атрибут, например
категория корпоративного продукта, — жизнеспособная отправной точкой для
усилий по интеграции. Со временем вы можете итеративно расширять эту минимальную отправную точку, добавляя атрибуты. Такая итеративная работа над
измерениями может вестись в течение архитектурных Agile-спринтов. Когда результаты серии спринтов объединяются и обеспечивают достаточную ценность,
они превращаются в релиз для бизнес-пользователей.
194
Глава 4
Если вам не удастся сосредоточиться на согласованных измерениях, потому
что вы работаете над задачами, которые надо было закончить вчера, хранилища
аналитических данных отделов, вероятно, будут иметь несовместимые категории
и ярлыки. Еще больше беспокоит то, что наборы данных могут выглядеть так, как
будто их можно сравнивать и интегрировать по сходным меткам, но базовые бизнес-правила могут немного отличаться. Бизнес-пользователи тратят чрезмерно
много времени, пытаясь согласовать и устранить эти несоответствия, что отрицательно сказывается на их способности быстро принимать решения.
Старшие ИТ-менеджеры, которые требуют применение гибких методов разработки систем, должны оказывать еще большее организационное давление вместе со своими коллегами по бизнесу для разработки согласованных измерений,
если они заинтересованы как в долгосрочной эффективности разработки, так
и в долгосрочной эффективности принятия решений на предприятии.
Согласованные факты
До сих пор мы рассматривали центральную задачу создания согласованных измерений для связывания размерных моделей вместе. Это 95 или более процентов усилий
по архитектуре данных. Остальные 5 процентов уходят на установление согласованных определений фактов. Выручка, прибыль, стандартные цены и затраты, показатели качества и удовлетворенности клиентов, а также другие ключевые показатели
эффективности (KPI) — это факты, которые также должны согласовываться. Если
факты существуют более чем в одной размерной модели, лежащие в основе определения и уравнения для этих фактов должны быть одинаковыми, чтобы их можно
назвать одним и тем же словом. Если они обозначены одинаково, они должны быть
определены в одном и том же размерном контексте и с одинаковыми единицами
измерения от размерной модели к размерной модели. Например, если несколько
бизнес-процессов сообщают о доходах, эти отдельные показатели доходов можно
складывать и сравнивать только в том случае, если они имеют одинаковые финансовые определения. Если есть различия в определениях, важно, чтобы таблицы фактов
о доходах имели различные и однозначные соответствующие имена.
ПРИМЕЧАНИЕ Вы должны соблюдать дисциплину в своей практике имено-
вания данных. Если невозможно точно согласовать факт, вы должны дать разные
названия различным интерпретациям, чтобы бизнес-пользователи не объединяли эти несовместимые факты в расчетах.
Иногда факт имеет естественную единицу измерения в одной таблице фактов
и другую естественную единицу измерения в другой таблице фактов. Например,
Склад
195
путь продукта по цепочке создания ценности в розничной торговле лучше всего
измерять в отгрузочных ящиках на складе, но в отсканированных единицах в магазине. Даже если бы все аспекты размерности были правильно учтены, было бы
трудно использовать эти две несовместимые единицы измерения в одном сквозном отчете. Обычное решение проблемы такого рода — направить пользователя к коэффициенту преобразования, скрытому в таблице параметров продукта,
и надеяться, что пользователь сможет найти этот коэффициент и правильно его
использовать. Это недопустимо как из-за накладных расходов, так и из-за уязвимости к ошибкам. Правильным решением будет вычисление и хранение фактов
в обеих единицах измерения, чтобы отчет мог легко скользить по цепочке ценностей, выбирая сопоставимые факты. В главе 6 больше рассказывается об использовании нескольких единиц измерения.
Выводы
В этой главе мы разработали размерные модели для трех дополняющих друг друга моделей хранения данных инвентаризации. Периодический моментальный
снимок — хороший выбор для долгосрочных сценариев постоянно пополняемых запасов. Накапливаемый моментальный снимок — хороший выбор для ситуаций с конечным конвейером инвентаризации с определенным началом и концом. Наконец, для большинства анализов запасов на складе потребуется схема
транзакций, дополняющая эти модели моментальных снимков.
Мы представили ключевые концепции, относящиеся к архитектуре и матрице шины корпоративного хранилища данных. Каждый бизнес-процесс цепочки
ценности, поддерживаемый исходной системой, преобразуется в строку в матрице шины, а в итоге — в размерную модель. Строки матрицы имеют удивительное
количество стандартизированных, согласованных измерений. Разработка и соблюдение архитектуры шины предприятия — абсолютная необходимость, если
вы намереваетесь построить систему DW/BI, состоящую из интегрированного
набора размерных моделей.
5
Закупки
В
этой главе мы исследуем процессы закупок. Эта тема имеет очевидную межотраслевую привлекательность, поскольку применима к любой организации,
которая приобретает продукты или услуги для пользования или перепродажи.
Помимо разработки нескольких моделей закупок, в этой главе подробно
рассматриваются методы обработки изменений значений атрибутов таблицы
измерений. Хотя описательные атрибуты в таблицах измерений относительно
статичны, они могут изменяться со временем. Продуктовые линейки реструктурируются, что приводит к изменению иерархии продуктов. Клиенты перемещаются, что приводит к изменению географической информации. Мы опишем
несколько подходов к этим неизбежным изменениям таблицы измерений. Последователи методов Кимбалла узнают техники типа 1, 2 и 3. Продолжая эту
традицию, мы расширили линейку техник медленно меняющихся измерений
типами 0, 4, 5, 6 и 7.
В главе 5 обсуждаются следующие концепции:
■ фрагмент матрицы шины для процессов закупок;
■ смешанные и отдельные схемы транзакций;
■ методы для медленно изменяющихся измерения типов от 0 до 7, охватывающие как базовые, так и расширенные гибридные сценарии.
Закупки: практический пример
До сих пор мы изучали процессы продаж потребителям и инвентаризации в цепочке ценности розничного продавца. Мы объяснили важность создания архитектуры шины корпоративного хранилища данных, в которой согласованные измерения используются в таблицах фактов, ориентированных на процессы. В этой
главе мы расширим эти концепции по мере продвижения по цепочке ценности
вверх к процессам закупок у поставщиков.
198
Глава 5
Для многих компаний закупки — критически важный вид деятельности.
Очевидно, что для розничных продавцов и дистрибьюторов важна эффективная
закупка продуктов по разумной цене для перепродажи. Закупки также имеют
серьезное влияние на прибыль любой организации, которая приобретает продукцию в качестве сырья для производства. Возможности значительной экономии затрат связаны с сокращением числа поставщиков и заключением соглашений с более предпочтительными из них.
Планирование спроса способствует эффективному управлению материалами.
После прогнозирования спроса цель закупок состоит в поиске соответствующих
материалов или продуктов для их приобретения самым экономически выгодным
способом. Закупки включают в себя широкий спектр действий от заключения
контрактов до выпуска заявок на закупку до отслеживания поступлений и утверждения платежей. Следующий список дает вам лучшее представление об общих
аналитических требованиях закупок организации:
■ Какие материалы или продукты покупаются чаще всего? Сколько поставщи-
ков поставляют эту продукцию? По каким ценам? Если посмотреть на спрос
в масштабах всего предприятия (а не в одном месте), есть ли возможности
для переговоров о выгодных ценах путем объединения поставщиков, использования единого поставщика или осуществления гарантированных покупок?
■ Покупают ли ваши сотрудники у предпочитаемых поставщиков или обходят соглашения с поставщиками ради индивидуальной выгоды?
■ Получаете ли вы договорные цены от своих поставщиков или существует
разница в закупочной цене и цене в контракте с поставщиком?
■ Как работают ваши поставщики? Какова надежность продавца? Своевременная доставка? Несвоевременные поставки? Процент возвратов? Уровень брака на основе проверки квитанции?
Закупочные операции и матрица шины
Когда вы начинаете работать с четырехэтапным процессом размерного проектирования, вы определяете, что закупки — это бизнес-процесс, который нужно моделировать. Изучая этот процесс, вы наблюдаете множество операций по закупкам,
таких как заявки на покупку, заказы на закупку, уведомления об отгрузке, квитанции
и платежи. Аналогично подходу, использованному в главе 4, вы можете изначально
разработать таблицу фактов с зернистостью одной строки для каждой закупочной
операции с датой операции, продуктом, поставщиком, условиями контракта и типом закупочной операции в качестве ключевых измерений. Количество закупочных
операций и сумма в долларах — это факты. Полученный дизайн показан на рис. 5-1.
Закупки
199
Таблица фактов транзакций
по закупкам
Измерение «Дата»
Измерение «Поставщик»
Ключ поставщика (PK)
Наименование поставщика
Адрес поставщика
Город поставщика
Город-штат поставщика
Почтовый индекс
поставщика
Штат-регион поставщика
Страна поставщика
Статус поставщика
Флаг меньшинства владения
продавцом
Компания-учредитель
поставщика
...
Ключ даты закупочной операции (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ условий контракта (FK)
Ключ типа закупочной операции (FK)
Номер контракта (DD)
Количество операция по закупке
Сумма закупочной операции
в долларах
Измерение «Продукт»
Измерение «Условия договора»
Ключ условий контракта (PK)
Описание условий контракта
Условия договора
Измерение «Тип закупочной операции»
Ключ типа закупочной операции (PK)
Описание типа закупочной операции
Тип категории закупочной операции
Рис. 5-1. Таблица фактов закупок с несколькими типами транзакций
Если вы работаете с одним и тем же розничным продуктовым магазином из
предыдущих тематических примеров, дата транзакции и измерения «Продукт»
будут такими же согласованными измерениями, которые были первоначально разработаны в главе 3. Если вы работаете с производственными закупками, сырьевая
продукция, скорее всего, находится в отдельной таблице измерения «Сырье»,
а не включается в измерение «Продукт» для продаваемых продуктов. Поставщик,
условия контракта и измерение «Тип операции закупки» новые для этой схемы.
Измерение «Поставщик» содержит по одной строке для каждого поставщика
вместе с интересными описательными атрибутами для поддержки различных анализов поставщиков. Измерение «Условия контракта» содержит по одной строке
для каждого обобщенного набора согласованных условий аналогично измерению
«Промоакция» в главе 3. Измерение «Тип закупочной операции» позволяет
группировать или фильтровать по типам операций, например заказам на поставку. Номер контракта — это вырожденное измерение; его можно использовать для
определения объема бизнеса, проводимого по каждому заключенному контракту.
Одна или много таблиц фактов транзакций
Изучая первоначальную схему закупок с бизнес-пользователями, вы узнаете несколько новых деталей. Так, бизнес-пользователи по-разному описывают различные закупочные операции. Бизнес рассматривает заказы на покупку, уведомления об отгрузке, складские квитанции и платежи поставщикам как отдельные
и уникальные процессы.
200
Глава 5
Информация о многих закупочных операциях приходит из разных исходных
систем. Существует система закупок, которая предоставляет заявки на покупку и заказы на закупку, складская система, которая предоставляет уведомления
об отгрузке и складские квитанции, а также система кредиторской задолженности, которая имеет дело с платежами поставщикам.
Далее вы обнаруживаете, что несколько типов транзакций имеют разную размерность. Например, полученные скидки применимы к платежам поставщикам,
но не к другим типам транзакций. Точно так же имя сотрудника, получившего
товар на складе, относится к квитанциям, но не имеет смысла в другом месте.
Существует также множество интересных контрольных номеров, таких как
номера заказов на покупку и платежных чеков, которые создаются на различных
этапах конвейера закупок. Эти контрольные числа — прекрасные кандидаты
на вырожденные измерения. Для определенных типов транзакций может применяться более одного контрольного номера.
Разбирая эти новые детали, вы приходите к этапу, когда вам нужно оформить
некоторые архитектурные решения. Следует ли вам создать смешанную таблицу фактов транзакций с измерением типа транзакции, чтобы просматривать все
транзакции закупок вместе, или вы создаете отдельные таблицы фактов для каждого типа транзакции? Это обычная архитектурная задача, которая возникает
во многих транзакционных ситуациях, а не только при закупках.
Как разработчикам размерных моделей вам необходимо принимать проектные решения на основе глубокого понимания бизнес-требований, сопоставленных с реалиями исходных данных. Не существует простой формулы для
однозначного определения, следует ли использовать одну таблицу фактов или
несколько. Одна таблица фактов может быть наиболее подходящим решением
в некоторых ситуациях, тогда как несколько таблиц больше подходят в других.
Столкнувшись с необходимостью принять такое дизайнерское решение, следующие соображения помогают разобраться в вариантах:
■ Каковы требования пользователей к аналитике?
Цель состоит в том, чтобы упростить работу за счет представления данных
в наиболее эффективной форме для бизнес-пользователей. Как бизнеспользователи чаще всего будут анализировать эти данные? Какой подход
наиболее естественным образом соответствует их бизнес-ориентированной
перспективе?
■ Действительно ли существует несколько уникальных бизнес-процессов?
В примере с закупками кажется, что покупка продуктов (заказы на поставку) сильно отличается от получения продуктов (квитанций). Наличие
Закупки
201
отдельных контрольных номеров для каждого шага процесса указывает
на то, что вы имеете дело с отдельными процессами. В этой ситуации вы бы
склонились к отдельным таблицам фактов. Напротив, в примере с инвентаризацией в главе 4 различные операции инвентаризации были частью
единого процесса, что привело к созданию общей таблицы фактов.
■ Собирают ли различные системы-источники метрики с уникальной детализацией?
В этом тематическом исследовании есть три отдельных исходных системы:
закупка, складирование и кредиторская задолженность. Это предполагает
отдельные таблицы фактов.
■ Какова размерность фактов?
В этом примере с закупками несколько измерений применимы к одним
типам операций, но не применимы к другим. Это снова приведет вас к отдельным таблицам фактов.
Бизнес-процессы
Атомарная зернистость Метрики
Дата
Прод
укт
Пост
авщи
к
Усло
вия к
онтр
акта
Сотр
удни
к
Скла
д
Пере
возчи
к
Простой способ учесть эти компромиссы — составить матрицу шины. Как
показано на рис. 5-2, вы можете включить два дополнительных столбца, определяющих атомарную зернистость и метрики для каждой строки. Эти улучшения
матрицы делают ее более похожей на подробную матрицу шины реализации, которую мы обсудим в главе 16.
Заявки на закупку
1 строка на строку заявки
Количество шт. в заявке и цена
X
X
X
X
X
Заказы
1 строка на строку заказа
Количество заказов на поставку и цены
X
X
X
X
X
X
X
Уведомления
о доставке
1 строка на строчку
уведомления об отгрузке
Отгруженное количество
X
X
X
X
X
X
Складские накладные
1 строка на строку чека
Полученное количество
X
X
X
X
X
X
Счета поставщика
1 строка на строку
счета-фактуры
Количество счетов-фактур и цены
X
X
X
X
X
X
Платежи
поставщикам
1 строка на платеж
Счет-фактура, скидки и чистые
платежи в долларах
X
X
X
X
X
Рис. 5-2. Примеры строк матрицы шины для процессов закупок
На основе матрицы шины для этого гипотетического исследования будет реализовано несколько таблиц фактов транзакций, как показано на рис. 5-3.
202
Глава 5
Измерение «Дата»
Измерение «Поставщик»
Измерение «Сотрудник»
Измерение «Перевозчик»
Факт заявки на закупку
Ключ даты заявки на закупку (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ условий контракта (FK)
Ключ сотрудника, создавшего запрос (FK)
Номер контракта (DD)
Номер заявки на покупку
Количество в заявке на закупку
Сумма заявки на закупку в долларах
Факт заказа на закупку
Ключ даты заказа на закупку (FK)
Дата запроса (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ условий контракта (FK)
Ключ склада (FK)
Ключ перевозчика (FK)
ключ сотрудника, сделавшего заказ (FK)
Ключ агента по закупкам (FK)
Номер контракта (DD)
Номер заявки на покупку
Номер заказа на покупку
Количество в заказе на закупку
Сумма заказа на закупку в долларах
Уведомление о доставке
Ключ даты уведомления об отправке (FK)
Ключ предполагаемой даты прибытия (FK)
Дата запроса (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ склада (FK)
Ключ перевозчика (FK)
Ключ сотрудника, сделавшего заказ (FK)
Номер заказа на покупку
Номер уведомления о доставке (DD)
Отгруженное количество
Факт складских накладных
Ключ даты складской накладной (FK)
Дата запроса (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ склада (FK)
Ключ перевозчика (FK)
Ключ сотрудника, сделавшего заказ (FK)
Ключ сотрудника, получившего заказ (FK)
Номер заказа на покупку
Номер уведомления о доставке (DD)
Номер складской накладной (DD)
Полученное количество
Факт оплаты поставщикам
Ключ даты платежа поставщику (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ склада (FK)
Ключ условий контракта (FK)
Номер контракта (DD)
Номер платежного чека (DD)
Сумма счета поставщика в долларах
Сумма скидки поставщика в долларах
Сумма чистого платежа поставщику в долларах
Рис. 5-3. Несколько таблиц фактов для процессов закупок
Измерение «Продукт»
Измерение «Условия продукта»
Измерение «Склад»
Закупки
203
В этом примере есть отдельные таблицы фактов для заявок на покупку, заказов на покупку, уведомлений об отгрузке, складских накладных и платежей поставщикам. Это решение было принято по нескольким причинам:
■ пользователи рассматривают эти действия как отдельные бизнес-процессы;
■ данные поступают из разных исходных систем;
■ существует уникальная размерность для различных типов транзакций.
Несколько таблиц фактов позволяют использовать более подробные и описательные измерения и атрибуты. Подход с единой таблицей фактов потребовал бы обобщенной маркировки для некоторых измерений. Например, дата заказа на поставку и дата получения, вероятно, были бы обобщены просто на дату
транзакции. Точно так же агент по закупкам и принимающий менеджер станут
сотрудниками. Это обобщение снижает удобочитаемость получаемой размерной
модели. Кроме того, с отдельными таблицами фактов при переходе от заявок
на покупку к платежам таблицы фактов наследуют измерения из предыдущих
шагов.
Для управления и администрирования нескольких таблиц фактов может
потребоваться больше времени, поскольку вы получите больше таблиц для загрузки, индексации и агрегирования. Некоторые утверждают, что такой подход
увеличивает сложность процессов ETL, однако фактически это может упростить
работу с ETL. Загрузка операционных данных из отдельных исходных систем
в отдельные таблицы фактов, вероятно, потребует менее сложной обработки
ETL, чем попытка интегрировать данные из нескольких источников в единую
таблицу фактов.
Дополнительный моментальный снимок закупок
Помимо принятия решения о нескольких таблицах фактов закупок, вам может
также потребоваться разработка таблицы фактов моментального снимка, чтобы
полностью удовлетворить потребности бизнеса. Как было предложено в главе 4,
накопительный снимок процессов, как рис. 5-4, который пересекает процессы,
был бы чрезвычайно полезен, если бизнес заинтересован в отслеживании движения продукта по мере его прохождения по конвейеру закупок (включая продолжительность каждого этапа). Помните, что накапливающийся моментальный
снимок предназначен для моделирования процессов с четко определенными этапами. Если процесс представляет собой непрерывный поток, который никогда
не заканчивается, он не будет хорошим кандидатом для накопительного моментального снимка.
204
Глава 5
Факты о процессе закупок
Измерение «Дата заказа»
Измерение «Дата
складского поступления»
Измерение
«Дата платежа поставщику»
Измерение «Поставщик»
Измерение «Сотрудник»
Измерений «Перевозчик»
Ключ даты заказа на закупку (FK)
Дата запроса (FK)
Ключ даты складской накладной (FK)
Ключ даты счета-фактуры
поставщика (FK)
Ключ даты платежа поставщику (FK)
Ключ продукта (FK)
Ключ поставщика (FK)
Ключ условий контракта (FK)
Ключ сотрудника, сделавшего
заказ (FK)
Ключ склада (FK)
Ключ перевозчика (FK)
Номер контракта (DD)
Номер заказа на покупку
Номер складской накладной (DD)
Номер счета поставщика (DD)
Номер платежного чека (DD)
Количество в заказе на закупку
Сумма заказа на закупку в долларах
Отгруженное количество
Полученное количество
Сумма счета поставщика в долларах
Сумма скидки поставщика
в долларах
Сумма чистого платежа поставщику
в долларах
Задержка заявки на покупку
Задержка даты получения заказа
Запрошено от даты получения
Задержка от поступления до даты
платежа
Задержка от выставления счета
до даты платежа
Измерение «Дата запроса товаров»
Измерение «Дата выставления
счета поставщику»
Измерение «Продукт»
Измерение «Условия договора»
Измерение «Склад»
Рис. 5-4. Схема накопительных моментальных снимков конвейера закупок
Основные сведения о медленно
меняющихся измерениях
До сих пор мы притворялись, что измерения не зависят от времени. К сожалению,
в реальном мире это не так. Хотя атрибуты таблицы измерений относительно
статичны, они не фиксируются навсегда; значения атрибутов со временем меняются, хотя и довольно медленно. Проектировщики измерений должны активно
работать с бизнес-представителями организации по управлению данными, чтобы
определить подходящую стратегию обработки изменений. Вы не должны сразу
делать вывод, что бизнес не заботится об изменениях измерений только потому,
что это не было упомянуто во время сбора требований. Хотя ИТ-специалисты
Закупки
205
могут предположить, что точное отслеживание изменений не требуется, бизнес-пользователи могут предположить, что система DW/BI позволит им увидеть влияние каждого изменения значения атрибута. Очевидно, лучше подумать
об этом раньше, чем позже.
ПРИМЕЧАНИЕ Бизнес-представители компании по управлению данными
и координирующей роли должны активно участвовать в принятии решений,
касающихся обработки медленно меняющихся атрибутов измерения. ИТ-специалистам не следует принимать решения самостоятельно.
Когда требуется отслеживание изменений, может возникнуть соблазн поместить каждый изменяющийся атрибут в таблицу фактов исходя из предположения, что таблицы измерений статичны. Это недопустимо и нереально. Вместо
этого вам нужны стратегии для работы с медленно меняющимися атрибутами в таблицах измерений. С тех пор как в 1995 году Ральф Кимбалл впервые
представил понятие медленно меняющихся измерений, некоторые ИТ-профессионалы в нескончаемом поиске сокращений назвали их SCD (Slowly changing
dimensions). Аббревиатура прижилась.
Для каждого атрибута таблицы измерений необходимо указать стратегию
обработки изменений. Другими словами, когда значение атрибута изменяется
в операционном мире, как вы отреагируете на изменение в вашей размерной модели? В следующих разделах мы опишем несколько основных методов работы
с изменениями атрибутов — от простых к сложным. Возможно, вам придется
использовать комбинацию этих методов в одной таблице измерений.
Последователи метода Кимбалла, вероятно, уже знакомы с SCD типов 1, 2 и 3.
Поскольку понятность — часть нашей мантры, мы иногда хотели бы дать этим
методам более описательные названия, например «перезапись». Но по прошествии почти двух десятилетий «типовые числа» стали неотъемлемой частью жаргона DW/BI. Как вы увидите в следующих разделах, мы решили расширить тему,
присвоив новые номера типов SCD методам, которые были описаны, но менее
точно помечены в прошлом; мы надеемся, что присвоение конкретных номеров
облегчит общение между членами команды.
Тип 0: сохранение оригинала
Раньше этому методу не присваивали номер типа, но он используется с самого начала SCD. При типе 0 значение атрибута никогда не изменяется, поэтому факты
всегда группируются по этому исходному значению. Тип 0 подходит для любого
атрибута с пометкой «оригинал», такого как исходный кредитный рейтинг клиента. Это также применимо к большинству атрибутов в измерении даты.
Глава 5
206
Как мы настойчиво утверждали в главе 3, не стоит полагаться на натуральный
операционный ключ, необходимо создать суррогатный ключ в качестве первичного. Хотя мы понизили роль натурального ключа до обычного атрибута измерения, он все же имеет особое значение. Если предположить, что он устойчивый, он
останется неприкосновенным. Постоянные надежные ключи — всегда атрибуты
типа 0. Если не указано иное, на протяжении всего обсуждения SCD в этой главе
предполагается, что постоянный сверхнатуральный ключ остается постоянным,
как описано в главе 3.
Тип 1: перезапись
Реакция на изменение атрибута типа 1 — перезапись старого значения атрибута
в строке измерения и замена его на текущее значение; атрибут всегда отражает
последнее присвоение.
Предположим, вы работаете в розничном магазине электроники, где товары скапливаются в отделах розничного магазина. Один из товаров — программа IntelliKidz.
Существующая строка в таблице параметров продукта для IntelliKidz выглядит как
верхняя половина рис. 5-5. Конечно, в измерении «Товар» могут быть дополнительные описательные атрибуты, но мы сократили список атрибутов для ясности.
Исходная строка в измерении «Товар»:
Ключ
товара
Описание Название
подразделения
Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Education
Обновленная строка в измерении «Товар»:
Ключ
товара
Описание Название
подразделения
Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Strategy
Рис. 5-5. Пример строк SCD типа 1
Предположим, новый специалист по мерчандайзингу решает, что программное обеспечение IntelliKidz следует переместить из отдела образования в отдел
стратегии 1 февраля 2013 года для увеличения продаж. При ответе типа 1 вы
просто обновите существующую строку в таблице измерений новым описанием
отдела, как показано в обновленной строке на рис. 5-5.
В этом случае при смене отдела IntelliKidz все измерения или ключи таблицы фактов остались прежними. Строки таблицы фактов по-прежнему ссылаются на ключ продукта 12345 независимо от местоположения IntelliKidz в отделе.
Когда продажи резко увеличиваются после перехода в отдел стратегии, у вас нет
информации, чтобы объяснить улучшение производительности, поскольку как
Закупки
207
исторические, так и более свежие факты выглядят так, как будто IntelliKidz всегда
находился в разделе стратегий.
Реакция типа 1 — это самый простой способ изменения атрибутов измерения. В таблице измерений вы просто заменяете существующее значение текущим
назначением. Таблица фактов осталась нетронутой. Проблема с реакцией типа 1
заключается в том, что вы теряете всю историю изменений атрибутов. Поскольку перезапись стирает исторические значения атрибутов, вы остаетесь только
со значениями атрибутов в том виде, в каком они существуют сегодня. Ответ
типа 1 подходит, если изменение атрибута — незначительная коррекция. Он
также может быть уместен, если нет смысла сохранять старое описание. Однако слишком часто команды DW/BI используют ответ типа 1 по умолчанию для
работы с медленно изменяющимися измерениями и в итоге полностью теряют
данные, если бизнесу необходимо точно отслеживать исторические изменения.
После того как вы внедрите тип 1, в будущем будет сложно изменить курс.
ПРИМЕЧАНИЕ Изменение типа 1 легко реализовать, но он не поддерживает
историю предыдущих значений атрибутов.
Прежде чем мы оставим тему изменений типа 1, предупреждаем, что одни
и те же приложения бизнес-аналитики могут давать разные результаты до и после изменения атрибута типа 1. Когда происходит перезапись типа 1 атрибута
измерения, строки фактов связываются с новым описательным контекстом. Бизнес-пользователи, которые объединили продажи по отделам 31 января, получат
другие итоговые данные по отделам, если они запустят тот же отчет 1 февраля
после перезаписи типа 1.
Есть еще одна загвоздка, о которой легко забыть. При ответе типа 1 на перемещение IntelliKidz любые ранее существовавшие агрегации, основанные
на значении отдела, необходимо перестроить. Агрегированные сводные данные
должны по-прежнему связываться с подробными атомарными данными, и теперь
выясняется, что IntelliKidz всегда включается в отдел стратегии.
Наконец, если размерная модель развертывается через куб OLAP, а атрибут
типа 1 — иерархический атрибут объединения, как отдел продукта в нашем примере, куб, вероятно, потребуется повторно обработать при изменении атрибута.
Как минимум, аналогично реляционной среде, агрегаты производительности
куба должны быть пересчитаны.
Хотя изменения типа 1 кажутся наиболее легкими
для реализации, помните, что они делают недействительными реляционные
таблицы и кубы OLAP, которые агрегировали данные по затронутому атрибуту.
ПРЕДУПРЕЖДЕНИЕ
208
Глава 5
Тип 2: добавление новой строки
В главе 1 мы заявили, что одна из целей системы DW/BI — правильное представление истории. Реакция типа 2 — преобладающий метод поддержки этого
требования, когда дело доходит до медленно меняющихся атрибутов измерения.
При использовании подхода типа 2, когда 1 февраля 2013 г. был изменен отдел IntelliKidz, для IntelliKidz была вставлена новая строка измерения продукта,
отражающая новое значение атрибута отдела. Для IntelliKidz есть две строки
в измерении «Товар», как показано на рис. 5-6. Каждая строка содержит версию
профиля атрибутов IntelliKidz, которая действовала в течение определенного периода времени.
Исходная строка в измерении «Товар»:
Описание
Ключ
товара Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Название
подразделения
Education
…
…
Дата
вступления
в силу
2012-01-01
Дата
окончания
Индикатор
текущей
строки
9999-12-31
Current
Дата
окончания
Индикатор
текущей
строки
2013-01-31
9999-12-31
Expired
Current
Строки в измерении «Товар» после переназначения отдела:
Ключ
товара Артикул (NK)
12345 ABC922-Z
25984 ABC922-Z
Описание
товара
IntelliKidz
IntelliKidz
Название
подразделения
Education
Strategy
...
...
...
Дата
вступления
в силу
2012-01-01
2013-02-01
Рис. 5-6. Пример строк SCD типа 2
При изменении типа 2 таблица фактов снова остается нетронутой; вы не возвращаетесь к строкам таблицы исторических фактов для изменения ключа продукта. В таблице фактов строки для IntelliKidz до 1 февраля 2013 г. будут ссылаться на ключ товара 12345, указывая на товар в отделе образования. После
1 февраля новые строки фактов IntelliKidz будут иметь ключ товара 25984, отражающий переход в отдел стратегий. Вот почему мы говорим, что ответы типа 2
идеально разделяют, или сегментируют, историю, чтобы учесть изменение. Отчеты, обобщающие факты до 1 февраля, выглядят одинаково независимо от того,
был ли отчет создан до или после изменения типа 2.
Мы хотим подчеркнуть, что сообщаемые результаты могут отличаться в зависимости от того, обрабатываются ли изменения атрибутов как тип 1 или тип 2.
Предположим, что в январе 2013 года розничный продавец электроники продал
программное обеспечение IntelliKidz на 500 долларов, а в феврале 2013 года —
на 100 долларов. Если атрибут «отдел» относится к типу 1, в результатах запроса, сообщающего о продажах за январь и февраль, будет указано 600 долларов
в разделе «Стратегия». И наоборот, если атрибут названия отдела относится
Закупки
209
к типу 2, объем продаж будет указан как 500 долларов для отдела образования
и 100 долларов для отдела стратегии.
В отличие от подхода типа 1, при использовании метода типа 2 нет необходимости повторно посещать уже существующие таблицы агрегации. Точно так же
кубы OLAP не нуждаются в повторной обработке, если иерархические атрибуты
обрабатываются как тип 2.
Если вы фильтруете по атрибуту «Отдел», два профиля товара различаются. Если вы фильтруете описание продукта, запрос автоматически выбирает обе
строки измерения продукта IntelliKidz и автоматически присоединяется к таблице фактов для получения полной истории товара. Если вам нужно правильно подсчитать количество товаров, вы должны просто использовать атрибут
натурального ключа SKU (артикул) в качестве основы для отдельного подсчета,
а не суррогатный ключ; столбец натурального ключа становится связующим звеном, удерживающим вместе отдельные строки типа 2 для одного товара.
ПРИМЕЧАНИЕ Ответ типа 2 — это основная рабочая лошадка для точного
отслеживания медленно меняющихся атрибутов измерения. Он чрезвычайно
эффективен, потому что новая строка измерения автоматически разбивает историю в таблице фактов.
Тип 2 — самый безопасный способ, если компания не совсем уверена в бизнесправилах SCD для атрибута. Как мы обсудим в разделах «Тип 6: добавление атрибута типа 1 к измерению типа 2» и «Тип 7: объединение измерения типа 1 и типа 2»
далее в этой главе, вы можете создать иллюзию перезаписи (тип 1), когда атрибут был
обработан с ответом типа 2. Обратное неверно. Если вы относитесь к атрибуту как
к типу 1, возврат к типу 2 задним числом требует значительных усилий для создания
новых строк измерений и последующего изменения ключей таблицы фактов.
Срок действия и истечения срока действия, тип 2
Если таблица измерений включает атрибуты типа 2, вы должны включить несколько административных столбцов в каждую строку, как показано на рис. 5-6.
Даты вступления в силу и истечения срока действия относятся к моменту, когда
значения атрибутов строки становятся действительными или недействительными. Даты вступления в силу и истечения срока действия или отметки даты/
времени необходимы в системе ETL, поскольку ей необходимо знать, какой
суррогатный ключ действителен при загрузке строк исторических фактов. Даты
вступления в силу и истечения срока действия поддерживают точное временное сечение измерения; однако нет необходимости фильтровать эти даты в таблице измерений, чтобы получить правильный ответ из таблицы фактов. Дата
210
Глава 5
вступления в силу строки — это первая дата, когда описательный профиль становится действительным. Когда в таблицу измерений впервые загружается новый
продукт, дата истечения срока действия устанавливается на 31 декабря 9999 года.
Чтобы избежать пустых значений в дате истечения срока действия, вы можете
использовать команду BETWEEN для поиска строк измерения, которые действовали на определенную дату.
Когда к измерению добавляется новая строка профиля продукта, чтобы зафиксировать изменение атрибута типа 2, срок действия предыдущей строки истекает. Обычно мы предлагаем, чтобы дата окончания в старой строке предшествовала дате вступления в силу новой строки, не оставляя промежутков между
датами вступления в силу и истечения срока действия. Определение «предшествует» зависит от зернистости отслеживаемых изменений. Обычно даты вступления в силу и истечения срока представляют собой изменения, происходящие
в течение дня; если вы отслеживаете более детальные изменения, вы должны вместо даты использовать метку даты/времени. В этом случае вы можете применить
другие бизнес-правила, например установить дату истечения срока действия
строки, точно равную дате вступления в силу следующей строки. Это потребует
такой логики, как ограничения «>= даты вступления в силу и < дата истечения
срока», что делает невозможным использование BETWEEN.
Некоторые спорят, что достаточно одной даты вступления в силу, но это затрудняет поиск строки измерения с последней датой вступления в силу, которая меньше или равна фильтру даты. Сохранение явной второй даты упрощает
обработку запроса. Точно так же индикатор текущей строки — это еще один
полезный атрибут административного измерения, позволяющий быстро отфильтровать запросы только текущие профили продуктов.
Ответ типа 2 на медленно меняющиеся измерения требует использования
суррогатных ключей, но вы все равно их используете, верно? Вы, конечно, не можете использовать операционный натуральный ключ, потому что существует несколько версий профиля для одного и того же натурального ключа. Недостаточно использовать натуральный ключ с двумя или тремя цифрами версии, потому
что вы будете уязвимы для всего списка потенциальных операционных проблем,
обсуждаемых в главе 3. Точно так же не рекомендуется добавлять дату вступления в силу к первичному ключу таблицы измерений, чтобы однозначно идентифицировать каждую версию. При ответе типа 2 вы создаете новую строку измерения с новым первичным ключом, чтобы однозначно идентифицировать новый
профиль продукта. Этот первичный ключ из одного столбца устанавливает связь
между таблицами фактов и измерений для заданного набора характеристик продукта. Нет необходимости создавать запутанное вторичное соединение на основе дат вступления в силу или истечения срока действия строки измерения.
Закупки
211
Мы понимаем, что некоторых из вас может беспокоить администрирование
суррогатных ключей для поддержки изменений типа 2. В главах 19 и 20 мы более подробно обсудим управление суррогатными ключами и внесение изменений
типа 2.
Добавление атрибута типа 1 к измерению типа 2
Нередко встречается смешение нескольких техник медленно меняющихся измерений в одном измерении. Когда в измерении используются и тип 1, и тип 2,
иногда изменение атрибута типа 1 требует обновления нескольких строк измерения. Предположим, что таблица измерений включает дату выпуска продукта.
Если этот атрибут изменяется с использованием логики типа 1 после того, как
происходит изменение типа 2 другого атрибута, дату введения, вероятно, следует
обновить в обеих версиях профиля IntelliKidz, как показано на рис. 5-7.
Люди, ответственные за управление данными, должны участвовать в определении бизнес-правил ETL в подобных сценариях. Хотя группа DW/BI может
способствовать обсуждению правильной обработки обновлений, окончательное
решение должны принимать люди со стороны бизнеса, ответственные за управление данными, а не команда DW/BI.
Исходная строка в измерении «Продукт»:
Название
Ключ
Артикул Описание подразде- Дата
продукта (NK)
товара
ления
выпуска
12345
ABC922-Z
IntelliKidz
Education
2012-12-15
…
Индикатор
Дата
Дата
текущей
вступления окончания
в силу
срока действия строки
…
2012-01-01
9999-12-31
Current
Rows in Product dimension following type 2 change to Department Name and type 1 change to Introduction Date:
Артикул
Ключ
продукта (NK)
12345
25984
ABC922-Z
ABC922-Z
Описание
товара
Название
подразде- Дата
выпуска
ления
…
Индикатор
Дата
Дата
текущей
вступления окончания
в силу
срока действия строки
IntelliKidz
IntelliKidz
Education
Strategy
...
...
2012-01-01
2013-02-01
2012-01-01
2012-01-01
2013-01-31
9999-12-31
Expired
Current
Рис. 5-7. Обновления типа 1 в измерении с образцами строк атрибутов типа 2
Тип 3: добавление нового атрибута
Так как изменения измерений типа 2 разделяет историю, она не позволяет
вам связать новое значение атрибута со старой историей фактов или наоборот.
В ответе типа 2, когда вы фильтруете атрибут отдела по значению «Стратегия»,
вы видите только факты IntelliKidz за период после 1 февраля 2013 года. В большинстве случаев это именно то, что вам нужно.
Однако иногда вам нужно увидеть данные фактов, как будто изменение никогда
не происходило. Чаще всего это происходит при реорганизации отдела продаж.
212
Глава 5
Границы могут быть перерисованы, но некоторые пользователи по-прежнему
хотят иметь возможность суммировать последние продажи для предыдущих
границ, просто чтобы посмотреть, как бы они поступили при старой организационной структуре. В течение нескольких переходных месяцев может возникнуть необходимость в отслеживании истории новых областей и, наоборот,
в отслеживании новых фактических данных с точки зрения границ старых областей. Ответ типа 2 не поддерживает это требование, и тут тип 3 приходит
на помощь.
В нашем примере программного обеспечения предположим, что имеет место
бизнес-потребность отслеживать как новые, так и предыдущие значения атрибута отдела в течение периода времени, близкого к изменению 1 февраля. При
ответе типа 3 вы не создаете новую строку измерения, а скорее добавляете новый столбец, чтобы зафиксировать изменение атрибута, как показано на рис. 5-8.
Вы должны изменить таблицу измерения «Продукт», чтобы добавить атрибут
предыдущего отдела, и заполнить этот новый столбец существующим значением
отдела («Образование»). Исходный атрибут отдела рассматривается как тип 1,
которое вы перезаписываете, чтобы отразить текущее значение («Стратегия»).
Все существующие отчеты и запросы немедленно переключаются на новое описание отдела, но вы все равно можете сообщить о старом значении отдела, запросив атрибут предыдущего отдела.
Исходная строка в измерении продукта:
Ключ
продукта
Описание
Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Название
подразделения
Education
Обновленная строка в измерении «Продукт»:
Ключ
продукта
Описание
Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Название
Название
предыдущего
подразделения подразделения
Strategy
Education
Рис. 5-8. Пример строк SCD типа 3
Не заблуждайтесь, думая, что большее значение типа, связанное с типом 3,
указывает на то, что это предпочтительный подход; методы не представлены
в последовательности от плохого к хорошему. Откровенно говоря, тип 3 используется нечасто. Это уместно, когда есть острая необходимость одновременно
поддержать два взгляда на мир. Тип 3 отличается от типа 2, поскольку пара текущих и предшествующих значений атрибутов одновременно считается истинной.
Закупки
213
ПРИМЕЧАНИЕ Техника медленно меняющихся измерений типа 3 позволяет
вам видеть новые и исторические данные фактов либо по новым, либо по предыдущим значениям атрибутов, иногда называемым альтернативными реальностями.
Тип 3 бесполезен для атрибутов, которые меняются непредсказуемо, например для штата клиента. Нет никакой пользы в сообщении фактов, основанных
на предыдущем атрибуте штата, который отражает изменение 10 дней назад для
одних клиентов или 10 лет назад для других. Эти непредсказуемые изменения
обычно лучше всего обрабатываются типом 2.
Тип 3 наиболее подходит, когда есть существенное изменение, затрагивающее многие строки в таблице измерений, например реорганизация отдела продаж или линейки продуктов. Эти массовые изменения — главные кандидаты,
потому что бизнес-пользователи часто хотят иметь возможность анализировать
показатели производительности, используя значения либо до, либо после реорганизации иерархии в течение определенного периода. При изменениях типа 3
предыдущий столбец должен быть назван так, чтобы отчетливо представить ранее измененную группировку, например отдел 2012 года или отдел до слияния.
Эти имена столбцов обеспечивают ясность, но на уровне BI могут возникать нежелательные колебания.
Наконец, если атрибут типа 3 представляет иерархический уровень сведений
в измерении, то, как обсуждалось с типом 1, обновление типа 3 и дополнительный столбец, вероятно, вызовут повторную обработку кубов OLAP.
Несколько атрибутов типа 3
Если атрибут измерения изменяется с предсказуемым ритмом, иногда бизнесу
необходимо суммировать показатели производительности на основе любого
из исторических значений атрибута. Представьте, что линейка продуктов переклассифицируется в начале каждого года, и бизнес хочет взглянуть на исторические факты за несколько лет на основе назначения отдела на текущий или любой
предыдущий год.
В этом случае мы воспользуемся преимуществом регулярного, предсказуемого характера этих изменений, обобщив подход типа 3 к серии атрибутов измерения типа 3, как показано на рис. 5-9. В каждой строке измерения есть атрибут
текущего отдела, который перезаписывается, а также атрибуты для каждого года,
например отдел 2012 года. Бизнес-пользователи могут объединять факты с любыми значениями отдела. Если бы продукт появился в 2013 году, атрибуты отдела
для 2012 и 2011 годов содержали бы значения «Неприменимо».
214
Глава 5
Обновленная строка в измерении «Продукт»:
Ключ
продукта
Описание
Артикул (NK) товара
12345 ABC922-Z
IntelliKidz
Текущее
название
отдела
Название
отдела
2012
Название
отдела
2011
Strategy
Education
Not Applicable
Рис. 5-9. Таблица измерений с несколькими атрибутами SCD типа 3
Столбец с самым последним назначением должен быть обозначен как «текущий отдел». Этот атрибут будет использоваться чаще всего; вы не хотите изменять существующие запросы и отчеты в следующем году. При переназначении
отделов в январе 2014 года вы должны изменить таблицу, добавив атрибут отдела
2013 года, заполнить этот столбец текущими значениями отдела, а затем перезаписать текущий атрибут назначением отдела 2014 года.
Тип 4: добавление мини-измерения
До сих пор мы сосредоточились на медленно меняющихся изменениях таблиц
измерений. Что происходит, когда скорость изменения увеличивается, особенно
в большой таблице измерений с многомиллионными строками? Большие измерения создают две проблемы, требующие особого отношения. Размер этих измерений может отрицательно сказаться на производительности операции просмотра
данных и фильтрации запросов. Кроме того, наш проверенный метод отслеживания изменений типа 2 непривлекателен, потому что мы не хотим добавлять
больше строк в измерение, в котором уже есть миллионы строк, особенно если
изменения происходят часто.
К счастью, на помощь приходит один метод, позволяющий решить проблемы как с производительностью запросов, так и с отслеживанием изменений.
Решение состоит в том, чтобы выделить часто анализируемые или часто изменяющиеся атрибуты в отдельное измерение, называемое мини-измерением.
Например, вы можете создать мини-измерение для группы более изменчивых
демографических атрибутов клиентов, таких как возраст, частота покупок
и уровень дохода, предполагая, что эти столбцы широко используются и изменения этих атрибутов важны для бизнеса. В мини-измерении будет одна строка
для каждой уникальной комбинации возраста, частоты покупок и уровня дохода, встречающейся в данных, а не одна строка для каждого покупателя. При
таком подходе мини-измерение становится набором демографических профилей. Хотя количество строк в измерении клиента может исчисляться миллионами, количество строк мини-измерения должно быть значительно меньше. Вы
оставляете более постоянные атрибуты в исходной многомиллионной таблице
клиентов.
Закупки
215
Примерные строки для демографического мини-измерения показаны
на рис. 5-10. При создании мини-измерения непрерывно изменяющиеся атрибуты, такие как доход, преобразуются в линейные диапазоны. Другими словами,
атрибуты в мини-измерении обычно вынуждены принимать относительно небольшое количество дискретных значений. Хотя так вы ограничены в использовании набора заранее определенных значений, это резко сокращает количество
комбинаций в мини-измерении. Если вы сохранили доход на определенном уровне в долларах и центах в мини-измерении в сочетании с другими демографическими атрибутами, вы могли бы получить столько же строк в мини-измерении,
сколько и в самом измерении клиента. Использование диапазонов, вероятно, —
наиболее значительный компромисс, связанным с техникой мини-измерений.
Хотя группировка фактов из нескольких значений диапазонов жизнеспособна,
переход на более узкие диапазоны (например, 30 000–34 999 долларов США)
в более позднее время затруднен. Если пользователи настаивают на доступе
к определенному значению необработанных данных, например к счету кредитного бюро, который обновляется ежемесячно, его следует включить в таблицу
фактов в дополнение к значению, хранящемуся в диапазонном атрибуте в миниизмерении. В главе 10 мы обсудим динамические диапазоны значений фактов;
однако такие запросы намного менее эффективны, чем фильтрация диапазона
значений в таблице мини-измерения.
Оценка
Демографические Возрастная частоты
группа
покупок
данные
1
2
3
4
5
6
...
142
143
144
...
21–25
21–25
21–25
21–25
21–25
21–25
...
26–30
26–30
26–30
...
Low
Medium
High
Low
Medium
High
...
Low
Medium
High
...
Уровень
дохода
<$30 000
<$30 000
<$30 000
$30 000–39 999
$30 000–39 999
$30 000–39 999
...
<$30 000
<$30 000
<$30 000
...
Рис. 5-10. SCD тип 4: пример строк мини-измерения
Каждый раз, когда создается строка таблицы фактов, включаются два внешних ключа, связанных с клиентом: ключ измерения «Клиент» и ключ демографических данных мини-измерения, действующий во время события,
как показано на рис. 5-11. Мини-измерение обеспечивает преимущества
216
Глава 5
в производительности, предоставляя меньшую точку доступа к фактам. Запросы
могут избежать использования огромной таблицы измерения «Клиент», если
атрибуты из этой таблицы не используются в качестве меток отчета или для
фильтрации.
Измерение «Клиент»
Ключ клиента (PK)
Идентификатор клиента (NK)
Имя клиента
Адрес клиента
Город — штат заказчика
Штат клиента
Почтовый индекс клиента
Дата рождения клиента
Таблица фактов
Ключ даты (FK)
Ключ клиента (FK)
Ключ демографических
данных (FK)
Больше FK …
Факты …
Измерение «Демографические параметры»
Ключ демографических данных (PK)
Возрастная группа
Оценка частоты покупок
Уровень дохода
Рис. 5-11. Тип 4: мини-измерение с измерением «Клиент»
Когда ключ мини-измерения участвует в качестве внешнего ключа в таблице
фактов, еще одно преимущество в том, что таблица фактов фиксирует изменения
демографического профиля. Предположим, мы ежемесячно загружаем данные
в таблицу фактов периодического снимка. Вернемся к нашему образцу строк демографического мини-измерения на рис. 5-10: если бы одному из наших клиентов, Джону Смиту, было 25 лет с низкой оценкой частоты покупок и доходом
в 25 000 долларов, вы бы начали с присвоения демографического ключа 1 при загрузке таблицы фактов. Если у Джона день рождения через несколько недель и ему
исполняется 26 лет, вы должны назначить демографический ключ 142 при следующей загрузке таблицы фактов; ключ демографических данных в более ранних
строках таблицы фактов Джона не будет изменен. Таким образом, таблица фактов
отслеживает изменение возраста. Вы продолжите назначать демографический ключ
142 при загрузке таблицы фактов, пока не произойдет еще одно изменение в демографическом профиле Джона. Если через несколько месяцев Джон получит повышение до 32 000 долларов, новый ключ демографических данных будет отражен
в следующей загрузке таблицы фактов. Опять же, предыдущие строки остались бы
без изменений. Кубы OLAP также легко вмещают мини-измерения 4-го типа.
Измерения «Клиент» в некоторой степени уникальны тем, что атрибуты клиентов часто запрашиваются независимо от таблицы фактов. Например,
пользователи могут захотеть узнать, сколько клиентов проживает в округе Дейд
по возрастным группам, для сегментации и составления профилей. Вместо того
чтобы выполнять какой-либо анализ, объединяющий данные о клиентах и демографические данные, связанные через таблицу фактов, последнее значение демографического ключа также может существовать как внешний ключ в таблице
Закупки
217
измерения клиентов. Далее мы опишем этот демографическое внешнее измерение клиентов как SCD типа 5 в следующем разделе.
Нельзя допускать, чтобы измерение «Демографические атрибуты» было
слишком большим. Если у вас есть пять демографических атрибутов, каждый
из которых имеет 10 возможных значений, тогда в демографическом измерении
может быть 100 000 (10^5) строк. Это разумный верхний предел количества
строк в мини-измерении, если вы заранее определите все возможные комбинации. Альтернативный подход ETL заключается в построении только тех строк
мини-измерения, которые действительно встречаются в данных. Однако, безусловно, бывают случаи, когда даже этот подход не помогает, и вам нужно поддерживать более пяти демографических атрибутов с 10 значениями каждый. Мы
обсудим использование нескольких мини-измерений, связанных с одной таблицей фактов, в главе 10.
Изменения демографического профиля иногда происходят без какого-то бизнес-события, например, когда профиль клиента обновляется в отсутствие сделки
купли-продажи. Если бизнес требует точного профилирования на определенный
момент времени, дополнительная таблица фактов с датами вступления в силу
и истечения срока может фиксировать каждое изменение отношений между измерением «Клиент» и «Демографические атрибуты».
Гибридные методы медленно
изменяющихся измерений
В этом заключительном разделе мы обсудим гибридные подходы, сочетающие
основные методы SCD. Разработчики иногда влюбляются в эти гибриды, потому что они, кажется, предлагают лучшее из всех миров. Однако за большую
аналитическую гибкость часто приходится расплачиваться большей сложностью.
Хотя ИТ-специалисты могут быть впечатлены элегантной гибкостью, бизнеспользователей также может легко отпугнуть сложность. Вам не следует использовать эти варианты, если компания не согласна с тем, что они необходимы для
выполнения их требований.
Эти гибридные подходы наиболее уместны, если вас попросили сохранить
исторически точный атрибут измерения, связанный с событием факта, одновременно поддерживая возможность сообщать исторические факты в соответствии
с текущими значениями атрибутов. Базовые методы медленно изменяющихся
измерений сами по себе не позволяют выполнить это требование.
Мы начнем с рассмотрения техники, сочетающей тип 4 с выносной опорой
типа 1; поскольку 4 + 1 = 5, мы называем это «тип 5». Далее мы опишем тип 6,
который объединяет типы с 1 по 3 для одного атрибута измерения; он удачно
218
Глава 5
назван типом 6, потому что 2 + 3 + 1 или 2 × 3 × 1 равно 6. Наконец, мы закончим типом 7, который как раз оказывается следующим доступным порядковым
номером; этот ярлык не имеет никакого математического значения.
Тип 5: добавление мини-измерения
и внешней опоры типа 1
Вернемся к мини-измерению типа 4. Особенность этого метода — добавление текущего ключа мини-измерения в качестве атрибута в первичном измерении. Эта
ключевая ссылка мини-измерения представляет собой атрибут типа 1, который
перезаписывается при каждом изменении профиля. Вы не захотите отслеживать
этот атрибут как тип 2, потому что тогда вы будете фиксировать неустойчивые
изменения в многомиллионном измерении, и предотвращение этого взрывного
роста было одной из исходных мотиваций для типа 4.
Техника типа 5 полезна, если вам нужен текущий счетчик профилей при отсутствии показателей таблицы фактов или если вы хотите свести исторические факты
на основе текущего профиля клиента. По логике, вы можете представить базовое
измерение и опору мини-измерения в виде единой таблицы в области презентации, как показано на рис. 5-12. Чтобы свести к минимуму путаницу пользователя
и его потенциальные ошибки, текущие атрибуты в этом ролевом измерении должны иметь отдельные имена столбцов, которые их различают, например текущий
возрастной диапазон. Даже с уникальной маркировкой помните, что предоставление пользователям двух путей доступа к демографическим данным — либо через
мини-измерение, либо через внешнюю опору — может обеспечить большую функциональность и сложность, чем некоторые могут себе позволить.
Просмотр измерения
«Демографические данные»
Измерение «Текущие
демографические данные»
Текущий демографический
ключ (PK)
Текущий возрастной диапазон
Текущая частота покупок
Текущий уровень дохода
Измерение «Клиент»
Ключ клиента (PK)
Идентификатор клиента (NK)
Имя клиента
…
Текущий демографический
ключ (FK)
Таблица фактов
Ключ даты (FK)
Ключ клиента (FK)
Ключ демографических
данных (FK)
Другие FK …
Факты
Измерение
«Демографические данные»
Ключ демографических
данных (PK)
Возрастная группа
Оценка частоты покупок
Уровень дохода
Логическое представление для инструментов бизнес-аналитики:
Измерение «Клиент»
Ключ клиента (PK)
Идентификатор клиента (NK)
Имя клиента
…
Текущий возрастной диапазон
Текущая частота покупок
Текущий уровень дохода
Таблица фактов
Ключ даты (FK)
Ключ клиента (FK)
Ключ демографических
данных (FK)
Другие FK …
Факты
Измерение
«Демографические данные»
Ключ демографических
данных (PK)
Возрастная группа
Оценка частоты покупок
Уровень дохода
Рис. 5-12. Тип 4: мини-измерение с внешней опорой типа 1 в измерении клиента
Закупки
219
ПРИМЕЧАНИЕ Терминология мини-измерения типа 4 относится к случаям,
когда ключ демографических данных — часть составного ключа таблицы фактов.
Если демографический ключ — это внешний ключ в измерении клиента, он называется внешней опорой.
Тип 6: добавление атрибута типа 1 к измерению типа 2
Вернемся к измерению «Товар» розничного магазина продажи электроники.
С типом 6 у вас будет по два атрибута отдела в каждой строке. Столбец текущего
отдела представляет текущее назначение; столбец исторического отдела — это
атрибут типа 2, представляющий исторически точное значение отдела.
Когда было представлено программное обеспечение IntelliKidz, строка измерения «Товар» выглядела бы как первый сценарий на рис. 5-13.
Исходная строка в измерении «Товар»:
Ключ
Артикул
«Товар» (NK)
Описание
товара
Название
Текущее
исторического название
отдела
отдела
…
Дата
Дата
Индикатор
вступления окончания
текущей
в силу
срока действия строки
12345 ABC922-Z
IntelliKidz
Education
…
2012-01-01 9999-12-31
Education
Current
Строки в измерении «Товар» после первого переназначения отдела:
Ключ
Артикул
«Товар» (NK)
Описание
товара
Название
Текущее
исторического название
отдела
отдела
…
Дата
Дата
Индикатор
вступления окончания
текущей
в силу
срока действия строки
12345 ABC922-Z
IntelliKidz
Education
Strategy
...
2012-01-01
2013-01-31
Expired
25984 ABC922-Z
IntelliKidz
Strategy
Strategy
...
2013-02-01 9999-12-31
Current
…
Дата
Дата
Индикатор
вступления окончания
текущей
в силу
срока действия строки
Строки в измерении «Товар» после второго переназначения отдела:
Ключ
Артикул
«Товар» (NK)
Описание
товара
Название
Текущее
исторического название
отдела
отдела
12345 ABC922-Z
IntelliKidz
Education
Critical Thinking ...
2012-01-01
2013-01-31
Expired
25984 ABC922-Z
IntelliKidz
Strategy
Critical Thinking ...
2013-02-01 2013-06-30
Expired
31726 ABC922-Z
IntelliKidz
Critical Thinking Critical Thinking ...
2013-07-01 9999-12-31
Current
Рис. 5-13. Пример строк SCD типа 6
Когда отделы реструктуризируются и IntelliKidz перемещается в отдел стратегии, вы должны использовать ответ типа 2, чтобы зафиксировать изменение атрибута путем создания новой строки. В этой новой строке измерения IntelliKidz
«Текущее название отдела» будет идентично историческому отделу. Для всех
предыдущих экземпляров строк измерений IntelliKidz атрибут «Текущее название отдела» будет перезаписан, чтобы отразить текущую структуру. Обе строки
IntelliKidz идентифицируют отдел стратегии как текущий отдел (см. второй сценарий на рис. 5-13).
220
Глава 5
Таким образом, вы можете использовать исторический атрибут для группировки фактов на основе значения атрибута, действовавшего на момент возникновения фактов. Между тем текущий атрибут объединяет все исторические данные
о фактах для обоих ключей продукта 12345 и 25984 в текущее назначение отдела. Если бы IntelliKidz затем был переведен в отдел программного обеспечения
Critical Thinking, таблица товаров выглядела бы как заключительный набор строк
на рис. 5-13. Текущий столбец группирует все факты по текущему назначению,
тогда как исторический столбец точно сохраняет исторические назначения и соответственно сегментирует факты.
При таком гибридном подходе вы создаете новую строку для фиксации изменения (тип 2) и добавляете новый столбец для отслеживания текущего назначения (тип 3), где последующие изменения обрабатываются как ответ типа 1. Инженер технологической компании предложил называть этот комбинированный
подход типом 6, потому что сумма и произведение 1, 2 и 3 равны 6.
Опять же, хотя этот метод может быть естественным образом привлекательным для некоторых, важно всегда учитывать точку зрения бизнес-пользователей,
поскольку вы стремитесь достичь разумного баланса между гибкостью и сложностью. Вы можете ограничить доступ к столбцам для некоторых пользователей,
чтобы они не были перегружены выбором.
Тип 7: Двойные измерения типа 1 и типа 2
Когда мы впервые описали тип 6, кто-то спросил, будет ли эта техника подходящей для поддержки как текущих, так и исторических данных для 150 атрибутов
в большой таблице измерений. Этот вопрос вернул нас к самым азам дизайна
медленно меняющихся измерений.
В этом финальном гибридном методе натуральный ключ измерения (при
условии, что он долговечен) включается как внешний ключ таблицы фактов
в дополнение к суррогатному ключу для отслеживания типа 2, как показано
на рис. 5-14. Если натуральный ключ громоздкий или когда-либо переназначается, вам следует вместо этого использовать отдельный устойчивый сверхнатуральный ключ. Измерение типа 2 содержит исторически точные атрибуты для фильтрации и группировки на основе значений, действующих, когда
произошло событие факта. Устойчивый ключ присоединяется к измерению
только с текущими значениями типа 1. Опять же, названия столбцов в этой
таблице должны начинаться со слова «текущий», чтобы снизить риск путаницы для пользователей. Эти атрибуты измерения можно использовать для
обобщения или фильтрации фактов на основе текущего профиля независимо от значений атрибутов, действующих на момент возникновения события
факта.
Закупки
Измерение «Продукт»
Ключ продукта (PK)
Устойчивый ключ продукта (DK)
Описание товара
Название отдела
…
Дата вступления в силу
Дата окончания срока действия
Индикатор текущей строки
Таблица фактов
Ключ даты (FK)
Ключ продукта (FK)
Устойчивый ключ
продукта (FK)
Другие FK …
Факты
221
Просмотр измерения продукта
(где индикатор текущей
строки = Cuttent)
Измерение «Продукт:
текущие значения»
Устойчивый ключ
продукта (PK)
Текущее описание продукта
Текущее название отдела
Рис. 5-14. Тип 7 с двойными внешними ключами для двойных таблиц размеров
типа 1 и типа 2
Этот подход обеспечивает те же функциональные возможности, что и тип 6.
Хотя ответ типа 6 порождает больше столбцов атрибутов в одной таблицеизмерении, этот подход основан на двух внешних ключах в таблице фактов.
Тип 7 неизменно требует меньше усилий для ETL, потому что таблица текущих
значений атрибутов типа 1 может быть легко доставлена через представление,
построенное на таблице измерений типа 2, ограниченное самыми последними
версиями профилей. Дополнительные затраты на этот последний метод — это
еще один столбец в таблице фактов; однако запросы, основанные на текущих значениях атрибутов, будут фильтроваться в таблице измерений меньшего размера,
чем описано ранее для типа 6.
Представление измерения продукта
Таблица фактов
Измерение «Продукт»
Ключ продукта (PK)
Устойчивый ключ продукта (PK)
Описание товара
Название отдела
…
Дата вступления в силу
Дата окончания срока действия
Индикатор текущей строки
Ключ даты (FK)
Ключ продукта (FK)
Другие FK …
Факты
Измерение «Текущие значения
атрибутов продукта»
Ключ продукта (PK)
Устойчивый ключ продукта (PK)
Текущее описание продукта
Текущее название отдела
...
Рис. 5-15. Вариант типа 7 с одним суррогатным ключом для двойных таблиц
измерений типа 1 и типа 2
Конечно, вы можете избежать сохранения устойчивого ключа в таблице фактов, присоединив представление типа 1, содержащее текущие атрибуты, к постоянному ключу в самой таблице измерений типа 2. Однако в этом случае запросы,
222
Глава 5
которые интересуются только текущими сводными данными, должны будут
пройти от внешнего измерения типа 1 через более объемное измерение типа 2,
прежде чем окончательно достичь фактов, что, вероятно, отрицательно повлияет
на производительность запроса для текущей отчетности.
Вариант этого двойного подхода к таблицам измерений типа 1 и типа 2 снова основан на представлении текущих атрибутов типа 1. Однако в этом случае
представление связывает текущие значения атрибутов со всеми строками типа 2
устойчивого ключа, как показано на рис. 5-15.
Обе таблицы измерений на рис. 5-15 имеют одинаковое количество строк,
но их содержимое различается, как показано на рис. 5-16.
Строки в измерении «Продукт»:
Устойчивый
ключ
Описание
продукта (PK) товара
Название
отдела
...
Дата
Дата
Индикатор
вступления окончания
текущей
в силу
срока действия строки
12345
ABC922-Z
12345
IntelliKidz
Education
...
2012-01-01
2013-01-31
Expired
25984
ABC922-Z
12345
IntelliKidz
Strategy
...
2013-02-01
2013-06-30
Expired
31726
ABC922-Z
12345
IntelliKidz
Critical Thinking ...
2013-07-01
9999-12-31
Current
Ключ
Артикул
продукта (NK)
Строки в текущем представлении измерения «Продукт»:
Артикул
Ключ
продукта (NK)
Устойчивый
Текущее
ключ
описание
продукта (PK) продукта
Текущее
название
отдела
...
12345
ABC922-Z
12345
IntelliKidz
Critical Thinking ...
25984
ABC922-Z
12345
IntelliKidz
Critical Thinking ...
31726
ABC922-Z
12345
IntelliKidz
Critical Thinking ...
Рис. 5-16. Вариант строк для SCD типа 7
Тип 7 для незапланированных отчетов «По состоянию на»
Наконец, хотя это случается редко, вас могут попросить свернуть исторические
факты на основе любого конкретного профиля на определенный момент времени
в дополнение к отчетам по значениям атрибутов, действовавшим, когда произошло событие факта, или по текущим значениям атрибута. Например, возможно,
бизнес хочет посчитать исторические метрики за три года на основе иерархии,
действовавшей на 1 декабря прошлого года. В этом случае вы можете использовать оба ключа измерения в таблице фактов в своих интересах.
Первый фильтр в строке измерения типа 2 по дате вступления в силу и дате
истечения срока действия, чтобы найти строки, действовавшие на 1 декабря
прошлого года. С помощью этого ограничения идентифицируется одна строка
для каждого устойчивого ключа в измерении типа 2. Затем присоедините этот
Закупки
223
отфильтрованный набор по устойчивому ключу в таблице фактов, чтобы объединить все факты на основе значений атрибутов на определенный момент времени.
Это как если бы вы определяли значение слова «текущий» на лету. Очевидно,
вы должны фильтровать строки по датам вступления в силу и истечения срока
действия, иначе у вас будет несколько строк типа 2 для каждого устойчивого ключа. Наконец, показывайте эту возможность только ограниченной, высоко аналитической аудитории; такая аналитика не для слабонервных.
Обобщение медленно меняющихся измерений
Мы обобщили методы отслеживания изменений атрибутов измерения
на рис. 5-17. В таблице показано влияние каждого метода медленно меняющегося измерения на анализ показателей производительности в таблице фактов.
Тип SCD Действие таблицы измерений
Влияние на анализ фактов
Тип 0
Нет изменений в значении атрибута
Факты, связанные с исходным значением
атрибута
Тип 1
Заменить значение атрибута
Факты, связанные с текущим значением
атрибута
Тип 2
Добавить новую строку измерения для
профиля с новым значением атрибута
Факты, связанные со значением атрибута,
действующим на момент наступления
факта
Тип 3
Добавить новый столбец, чтобы сохранить Факты, связанные как с текущими, так
текущее и предыдущее значения атрибута и с предыдущими альтернативными значениями атрибутов
Тип 4
Добавить мини-таблицу измерений, содер- Факты, связанные с быстро меняющимися
жащую быстро меняющиеся атрибуты
атрибутами, действуют, когда они происходят
Тип 5
Добавить мини-измерение типа 4 вместе
с перезаписанным ключом мини-измерения типа 1 в базовом измерении
Тип 6
Добавить перезаписываемые атрибуты
Факты, связанные с действующим значетипа 1 в строку измерения типа 2 и переза- нием атрибута, когда он произошел, плюс
писать все предыдущие строки измерения текущие значения
Тип 7
Добавить строку измерения типа 2 с новым значением атрибута, а также представление, ограниченное текущими строками и/или значениями атрибутов
Факты, связанные с быстро меняющимися
атрибутами, действующими на момент
возникновения факта, плюс текущие быстро меняющиеся значения атрибутов
Факты, связанные с действующим значением атрибута, когда он произошел, плюс
текущие значения
Рис. 5-17. Краткое описание методов медленно меняющихся измерений
224
Глава 5
Выводы
В этой главе мы обсудили несколько подходов к обработке данных о закупках.
Эффективное управление закупочной деятельностью может иметь большое
влияние на чистую прибыль организации.
Мы также представили методы работы с изменениями в значениях атрибутов
измерения. Ответы на медленно меняющиеся измерения варьируются от бездействия (тип 0) и перезаписи значения (тип 1) до сложных гибридных подходов (типы 5–7), которые сочетают методы для поддержки требований как для
сохранения исторических атрибутов, так и для отчетов по текущим значениям
атрибутов. Вам, несомненно, придется перечитать этот раздел, когда вы будете
рассматривать стратегии медленно меняющихся атрибутов измерений для вашей
системы DW/BI.
6
У
Управление
заказами
правление заказами состоит из нескольких критически важных бизнеспроцессов, включая обработку заказов, отгрузок и выставление счетов. Эти
процессы порождают метрики, такие как объем продаж и выручка по счетам. Такие метрики — ключевые показатели эффективности для любой организации,
которая продает продукты или услуги другим лицам. Фактически эти базовые
метрики настолько важны, что команды DW/BI выбирают для первоначального
внедрения один из процессов управления заказами. Очевидно, что темы в этом
тематическом исследовании выходят за рамки отраслевых границ.
В этой главе мы рассмотрим несколько различных транзакций управления
заказами, включая общие характеристики и сложности, возникающие при размерном моделировании этих транзакций. Мы продолжим развивать концепцию
накапливающего моментального снимка для анализа конвейера выполнения заказа от первоначального заказа до выставления счета.
В главе 6 обсуждаются следующие концепции:
■ фрагмент матрицы шины для процессов управления заказами;
■ схема транзакции заказов;
■ рекомендации по нормализации таблицы фактов;
■ ролевые изменения;
■ рекомендации по измерению доставки / выставления счета клиенту;
■ факторы, определяющие, одно или несколько измерений требуется;
■ мусорные измерения для разных флагов и индикаторов по сравнению
с альтернативными вариантами;
■ подробнее о вырожденных измерениях;
■ несколько валют и единиц измерения;
■ обработка фактов с разной степенью детализации;
■ шаблоны, которых следует избегать для заголовков транзакций и их детализирующих строк;
Глава 6
226
■ схема транзакции выставления счетов с указанием фактов прибыли и убыт-
ков;
■ измерения «Аудит»;
■ количественные показатели и качественные дескрипторы производительности уровня обслуживания;
■ конвейер выполнения заказа как схема накопления снимков;
■ расчет задержек.
Матрица шины управления заказами
чик
Дата
Заказ
Прод
укт
Торго
пред вый
стави
тель
Сдел
ка
Скла
д
Поста
вщик
Функция управления заказами состоит из серии бизнес-процессов. В наиболее
упрощенной форме вы можете представить себе подмножество матрицы шины
корпоративного хранилища данных, которое похоже на рис. 6-1.
Квота
X
X
X
X
X
Заказ
X
X
X
X
X
Доставка заказчику
X
X
X
X
X
X
X
Выставление счетов за отгрузку
X
X
X
X
X
X
X
Получение платежей
X
X
Возврат клиентов
X
X
X
X
X
X
X
X
Рис. 6-1. Фрагмент матрицы шины для процессов управления заказами
Как описано в предыдущих главах, матрица шины точно соответствует цепочке ценности организации. В этой главе мы сосредоточимся на строках заказа
и счетах в матрице. Мы также опишем накапливающую таблицу фактов моментальных снимков для оценки производительности на нескольких этапах общего
процесса выполнения заказа.
Транзакции по заказам
Естественная детализация таблицы фактов транзакции заказа — это одна строка
для каждой позиции в заказе. Измерения, связанные с бизнес-процессом заказов, — это дата заказа, запрашиваемая дата отправки, продукт, клиент, торговый
Управление заказами
227
представитель и сделка. Факты включают количество товара в заказе и суммы
в долларах заказа брутто, скидку и сумму нетто (равную сумме брутто за вычетом
скидки). Полученная схема будет похожа на рис. 6-2.
Измерение «Дата заказа»
Измерение «Запрошенная
дата отправки»
Измерение «Торговый
представитель»
Факт транзакции строки заказа
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Номер заказа (DD)
Номер строки заказа (DD)
Количество строки заказа
Общая сумма в долларах по строке заказа
Общая скидка в долларах по строке заказа
Общая прибыли в долларах по строке заказа
Измерение «Клиент»
Измерение «Продукт»
Измерение «Сделка»
Рис. 6-2. Таблица фактов транзакции заказа
Нормализация фактов
Вместо того чтобы хранить список фактов, показанный на рис. 6-2, некоторые
разработчики хотят дополнительно нормализовать таблицу фактов, чтобы в ней
была единая общая сумма фактов вместе с измерением, определяющим тип показателя. В этом сценарии детализация таблицы фактов — одна строка на показатель по строке заказа вместо более естественной одной строки на событие
по строке заказа. Измерение «Тип показателя» будет указывать, является ли
факт суммой заказа брутто, суммой скидки по заказу или каким-либо другим
показателем. Этот метод может иметь смысл, когда набор фактов чрезвычайно
длинный, но заполняется для данной строки фактов разреженно, и никакие вычисления между фактами не производятся. Вы можете использовать этот метод
для работы с данными тестирования качества производства, где факты сильно
различаются в зависимости от проведенного теста.
Однако, как правило, вы должны сопротивляться желанию нормализовать
таблицу фактов таким образом. Факты обычно достаточно плотно заполняются
в одной строке таблицы. Если бы в схеме транзакции заказа вы нормализовали
факты, вы бы умножили количество строк в таблице фактов на количество типов фактов. Предположим, что вы начали с 10 миллионов строк таблицы фактов
строк заказа, каждая из которых содержит шесть внешних ключей и четыре факта. Если бы строки фактов были нормализованы, вы бы получили 40 миллионов строк фактов, каждая с семью ключами и одним фактом. Кроме того, если
между фактами выполняется какая-либо арифметическая функция (например,
сумма скидки в процентах от суммы заказа брутто), гораздо проще, если факты
228
Глава 6
находятся в одной строке в реляционной звездообразной схеме, потому что SQL
затрудняет вычисление отношения или разницы между фактами в разных строках. В главе 14 мы рассмотрим ситуацию, когда измерение «Тип показателя»
имеет больше смысла. Этот паттерн также более уместен, если основная платформа, поддерживающая приложения бизнес-аналитики, — это куб OLAP; куб
позволяет выполнять вычисления, которые разрезают куб по любому измерению
независимо от того, дата ли это, продукт, клиент или тип меры.
Ролевые измерения
К настоящему времени вы знаете, что нужно ожидать измерения «Дата» в каждой
таблице фактов, потому что вы всегда смотрите на измерение производительности
с течением времени. В таблице фактов транзакции основной столбец даты — это дата
транзакции, например дата заказа. Иногда вы обнаруживаете другие даты, связанные
с каждой транзакцией, например запрошенную дату отправки заказа. Каждая из дат
должна быть внешним ключом в таблице фактов, как показано на рис. 6-3.
Однако вы не можете просто присоединить эти два внешних ключа к одной
и той же таблице измерения даты. SQL интерпретирует это двустороннее одновременное соединение как требующее, чтобы обе даты были идентичными, что
маловероятно.
Измерение «Дата заказа»
Измерение «Дата»
Ключ даты
Дата
День недели
Месяц
Квартал
…
Ключ даты заказа
Дата заказа
День недели заказа
Месяц заказа
Квартал заказа
…
Измерение
«Запрошенная дата доставки»
Ключ запрошенной даты отгрузки
Запрошенная дата отгрузки
Запрошенный день недели доставки
Запрошенный месяц доставки
Запрошенный квартал доставки
…
Факт транзакции строки заказа
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Номер заказа (DD)
Номер строки заказа (DD)
Количество в заказе
Общая сумма в долларах по строке заказа
Общая скидка в долларах по строке заказа
Общая прибыли в долларах по строке заказа
Логические представления, или псевдонимы
одного физического измерения даты
Рис. 6-3. Ролевые измерения
Даже если вы не можете буквально сделать соединение с одной таблицей измерения «Дата», вы можете создать и администрировать единую таблицу физического измерения «Дата». Затем вы создаете иллюзию двух независимых
Управление заказами
229
измерений «Дата» с помощью представлений (псевдонимов). Будьте осторожны, чтобы однозначно пометить столбцы в каждом из представлений (псевдонимов). Например, атрибут месяца заказа должен иметь уникальную метку,
чтобы отличать его от запрашиваемого месяца доставки. Если вы не установите
уникальные имена столбцов, вы не сможете отличить столбцы друг от друга при
включении обоих в отчет.
Как мы кратко описали в главе 3, мы бы определили дату заказа и запрошенную дату доставки заказа следующим образом:
create view order_date
(order_date_key, order_day_of_week, order_month, …)
as select date_key, day_of_week, month, … from date
и
create view req_ship_date
(req_ship_date_key, req_ship_day_of_week, req_ship_month, …)
as select date_key, day_of_week, month, … from date
В качестве альтернативы SQL поддерживает концепцию псевдонимов. Многие инструменты бизнес-аналитики также позволяют использовать псевдонимы
на своем семантическом уровне. Однако мы предостерегаем от этого подхода,
если в организации используется несколько инструментов бизнес-аналитики,
а также прямой доступ на основе SQL.
Независимо от подхода к реализации теперь у вас есть два уникальных логических измерения «Дата», которые можно использовать, как если бы они были
независимыми, с совершенно не связанными ограничениями. Это называется ролью, потому что измерение «Дата» одновременно выполняет разные роли в одной таблице фактов. Вы увидите дополнительные примеры ролевых измерений,
разбросанные по всей этой книге.
ПРИМЕЧАНИЕ Роли в размерной модели появляются, когда одно измерение
одновременно появляется несколько раз в одной и той же таблице фактов. Базовое измерение может существовать как одна физическая таблица, но каждая
из ролей должна быть представлена инструментам бизнес-аналитики в виде отдельно помеченного представления.
Стоит отметить, что некоторые продукты OLAP не поддерживают несколько
ролей одного и того же измерения; в этом сценарии вам нужно будет создать два
230
Глава 6
отдельных измерения для двух ролей. Кроме того, некоторые продукты OLAP,
которые позволяют использовать несколько ролей, не позволяют переименовывать атрибуты для каждой роли. В конце концов, среды OLAP могут быть завалены множеством отдельных измерений, которые рассматриваются просто как
роли в реляционной звездообразной схеме.
Для обработки нескольких дат некоторые дизайнеры хотят создать единую
таблицу дат с ключом для каждой уникальной даты заказа и запрошенной комбинации дат отгрузки. Этот подход не выдерживает критики по нескольким причинам. Во-первых, чистая и простая таблица дат каждого дня с примерно 365
строками в год увеличилась бы в размерах, если бы ей нужно было обрабатывать
все комбинации дат. Во-вторых, комбинированная таблица дат больше не будет
соответствовать другим часто используемым ежедневным, еженедельным и ежемесячным измерениям даты.
Роли и матрица шины
Дата
Наиболее распространенный метод документирования ролевых измерений
в матрице шины — это указать несколько ролей в одной ячейке, как показано
на рис. 6-4. Мы использовали аналогичный подход в главе 4. Этот метод особенно подходит для измерения «Дата» в матрице шины, учитывая его многочисленные логические роли. В качестве альтернативы, если количество ролей ограничено
и они часто повторно используются в разных процессах, вы можете создать вложенные столбцы в одном согласованном столбце измерения в матрице.
Квота
Дата квоты
Заказ
Дата заказа
Запрошенная дата отгрузки
Доставка заказчику
Дата поставки
Выставление счетов за отгрузку
Дата счета-фактуры
Получение платежей
Квитанция платежа
Возврат клиентов
Дата возврата
Рис. 6-4. Передача ролевых измерений в матрицу шины
Еще раз об измерении «Продукт»
Каждый из представленных до сих пор примеров из практики включал в себя измерение «Продукт». Измерение «Продукт» — одна из самых распространенных
Управление заказами
231
и наиболее важных таблиц измерений. Оно описывает полный перечень продуктов, продаваемых компанией. Во многих случаях количество продуктов
в перечне оказывается на удивление большим, по крайней мере, с точки зрения
стороннего наблюдателя. Например, популярный американский производитель
кормов для собак и кошек отслеживает более 25 000 вариантов своей продукции,
включая розничные продукты, с которыми каждый (или каждая собака и кошка)
знаком, а также многочисленные специализированные продукты, продаваемые
через коммерческие и ветеринарные каналы. Некоторые производители товаров
длительного пользования, например оконные компании, продают миллионы изделий уникальной конфигурации.
Большинство таблиц измерения «Продукт» имеют следующие характеристики:
■ Множество подробных описательных столбцов.
Для производителей нет ничего необычного в том, чтобы поддерживать
100 или более описаний продуктов, которые они продают. Атрибуты таблицы измерений естественным образом описывают строку измерения,
не изменяются из-за влияния другого измерения и практически постоянны во времени, хотя некоторые атрибуты со временем медленно меняются.
■ Одна или несколько иерархий атрибутов плюс неиерархические атри-
буты.
Продукты обычно объединяются в соответствии с несколькими определенными иерархиями. Иерархические данные с фиксированной глубиной
типа «многие к одному» должны быть представлены в единой сглаженной
денормализованной таблице измерения «Продукт». Вы должны воздерживаться от создания нормализованных подтаблиц в виде «снежинки»;
затраты на более сложное представление и более низкую производительность просмотра внутри измерений перевешивают выгоды от минимальной экономии места. Таблицы измерения «Продукт» могут содержать
тысячи записей. При таком большом количестве строк не очень полезно
запрашивать раскрывающийся список описаний продуктов. Важно иметь
возможность отфильтровать данные на основе одного атрибута, например
аромата, а затем на основе другого атрибута, например типа упаковки, прежде чем пытаться отобразить описания продуктов. Любые атрибуты независимо от того, принадлежат ли они к одной иерархии, должны свободно
использоваться для просмотра и детализации вверх или вниз. Многие атрибуты измерения «Продукт» — это автономные атрибуты с небольшим
количеством возможных значений.
232
Глава 6
Существование операционной основной записи продукта помогает создавать и поддерживать измерение «Продукт», но для преобразования рабочего
мастер-файла в таблицу измерений необходимо выполнить ряд преобразований
и административных шагов, включая следующие:
1. Соотнесите операционный код продукта с суррогатным ключом. Как мы
обсуждали в главе 3, этот не имеющий бизнес-смысла суррогатный первичный ключ необходим, чтобы избежать хаоса, вызванного повторным
использованием операционного кода продукта с течением времени. Также может потребоваться объединить информацию о продукте, полученную из разных операционных систем. Наконец, как вы только что узнали
из главы 5, при закупке суррогатный ключ необходим для отслеживания
изменений 2-го типа атрибута продукта.
2. Добавьте описательные значения атрибутов, чтобы дополнить или заменить операционные коды. Вы не должны принимать оправдание, что
бизнес-пользователи знакомы с рабочими кодами. Единственная причина,
по которой бизнес-пользователи знакомы с кодами, заключается в том,
что они были вынуждены их использовать! Столбцы в измерении «Продукт» — единственный источник фильтрации запроса и меток отчета,
поэтому содержимое должно быть понятным. Загадочные аббревиатуры
так же плохи, как и прямые числовые коды; их также следует дополнить
или заменить читаемым текстом. Несколько сокращенных кодов в одном
столбце следует развернуть и разделить на отдельные атрибуты.
3. Проверка качества значений атрибутов, чтобы убедиться в отсутствии
орфографических ошибок, недопустимых значений или множественных вариаций. Приложения и отчеты BI полагаются на точное содержание
атрибутов измерения. SQL создаст отдельную строку в отчете, если значение атрибута каким-либо образом изменится из-за тривиальных различий
в пунктуации или написании. Вы должны убедиться, что значения атрибутов полностью заполнены, поскольку отсутствующие значения легко могут
привести к неправильной интерпретации. Неполные или плохо управляемые атрибуты текстовых измерений приводят к неполным или плохо подготовленным отчетам.
4. Задокументируйте определения, интерпретации и происхождение атрибутов в метаданных. Помните, что метаданные аналогичны энциклопедии DW/BI. Вы должны проявлять бдительность при заполнении и поддержании репозитория метаданных.
Управление заказами
233
Измерение «Клиент»
Измерение «Клиент» содержит по одной строке для каждого отдельного местоположения, в которое вы отправляете продукт. Таблицы измерений «Клиент»
могут варьироваться от умеренных (тысячи строк) до очень больших (миллионы
строк) в зависимости от характера бизнеса. Типичное измерение «Клиент» показано на рис. 6-5.
Измерение «Клиент»
Ключ клиента (PK)
Идентификатор клиента (натуральный ключ)
Имя клиента
Адрес доставки
Город клиента
Страна клиента
Штат — город клиента
Штат клиента
Почтовый индекс клиента
Регион почтового индекса клиента
Почтовое отделение клиента
Имя клиента, указанное в банковском счете
Адрес клиента, указанный в банковском счете
Название организации клиента
Название компании клиента
Кредитный рейтинг заказчика
Рис. 6-5. Образец измерения «Клиент»
В измерении «Клиент» обычно сосуществуют несколько независимых иерархий. Естественная географическая иерархия четко определяется местоположением доставки. Поскольку место доставки — это точка в пространстве, любое
количество географических иерархий может быть определено путем вложения
более обширных географических объектов вокруг точки. В Соединенных Штатах обычная географическая иерархия — это город, округ и штат. Часто бывает
полезно включить атрибут «город — штат», потому что одно и то же название
города существует в нескольких штатах. Почтовый индекс указывает на вторичную географическую разбивку. Первая цифра почтового индекса идентифицирует географический регион США (например, 0 для северо-востока и 9 для некоторых западных штатов), тогда как следующие три цифры почтового индекса
идентифицируют почтовое отделение.
Хотя эти географические характеристики могут фиксироваться в единой
системе управления основными данными, вам следует встраивать атрибуты
234
Глава 6
в соответствующие измерения, а не полагаться на абстрактное, общее измерение
географии/местоположения, которое включает одну строку для каждой точки
в пространстве независимо от измерения. Подробнее об этом мы поговорим
в главе 11.
Другая распространенная иерархия — организационная иерархия клиента,
если предполагается, что клиент — юридическое лицо. Для каждого адреса доставки у вас может быть компания — получатель счета и материнская корпорация клиента. Для каждой строки в измерении «Клиент» четко определены как
физическая география, так и организационная принадлежность, даже несмотря
на то что иерархии складываются по-разному.
ПРИМЕЧАНИЕ Это естественное и обычное явление, особенно для ориен-
тированных на клиента измерений, когда измерение одновременно поддерживает несколько независимых иерархий. Иерархии могут иметь разное количество
уровней. Детализация каждой из этих иерархий должна поддерживаться в размерной модели.
Внимательный читатель может быть обеспокоен предположением, что несколько адресов доставки сводятся к одному владельцу счета в связи «многие
к одному». Реальный мир может быть не таким ясным и простым. Всегда есть
несколько исключений, связанных с адресами получателя, которые связаны с более чем одним владельцем счета. Очевидно, это нарушает простые иерархические
отношения, представленные на рис. 6-5. Если это случается редко, было бы разумно обобщить измерение «Клиент» так, чтобы зернистость измерения представляла собой каждую уникальную комбинацию «Адрес доставки». В этом сценарии, если есть два набора информации о владельце счета, связанные с данным
местоположением получателя, тогда в измерении будет две строки, по одной для
каждой комбинации. С другой стороны, если многие получатели связаны с множеством владельцев счетов в устойчивой взаимосвязи «многие ко многим»,
то адреса доставки и владельцы счетов, вероятно, должны обрабатываться как отдельные измерения, которые связаны между собой в таблице фактов. При любом
подходе сохраняется ровно одинаковая информация. Мы уделим больше времени организационным иерархиям, включая обработку рекурсивных отношений
переменной глубины, в главе 7.
Сравнение одиночных и нескольких таблиц измерений
Другой потенциальной иерархией в измерении «Клиент» может быть сбытовая организация производителя. Разработчики иногда задаются вопросом, следует ли моделировать атрибуты сбытовой организации как отдельное измерение
Управление заказами
235
или добавлять в измерение клиента. Если торговые представители тесно связаны
с клиентами в отношениях «один к одному» или «многие к одному», объединение атрибутов сбытовой организации с атрибутами клиента в одном измерении — жизнеспособный подход. Результирующее измерение равно бóльшему
из двух измерений. Отношения между отделами продаж и клиентами можно эффективно просматривать в одном измерении, не просматривая таблицу фактов.
Однако иногда отношения между сбытовой организацией и покупателем
сложнее. Необходимо учитывать следующие факторы:
1. Не является ли отношение «один к одному» или «многие к одному»
на самом деле «многие ко многим»? Как мы обсуждали ранее, если отношение «многие ко многим» — исключительное условие, то у вас все равно
может возникнуть соблазн объединить атрибуты торгового представителя
в измерение «Клиент», зная, что для обработки этих редких типов «многие ко многим» необходимы несколько суррогатных ключей. Однако, если
отношение «многие ко многим» — норма, вы должны рассматривать торгового представителя и клиента как отдельные измерения.
2. Меняются ли отношения между торговым представителем и клиентами со временем или под влиянием другого измерения? Если это так, вы,
вероятно, создадите отдельные измерения для торгового представителя
и клиента.
3. Не слишком ли велико измерение клиента? Если есть миллионы строк
о клиентах, вы с большей вероятностью будете рассматривать торгового
представителя как отдельное измерение, а не проводить анализ всего торгового представителя через объемное измерение клиента.
4. Рассматриваются ли торговые представители и клиенты отдельно в других таблицах фактов? Опять же, вы, вероятно, оставите измерения независимыми. Создание единого измерения клиента с атрибутами торгового
представителя исключительно на основе данных о заказах может сбить
с толку пользователей, когда они анализируют другие процессы с участием
торговых представителей.
5. Считает ли компания торгового представителя и клиента отдельными
вещами? Этот фактор может быть трудно различить и невозможно определить количественно. Но нет смысла объединять два критических измерения в одном смешанном измерении, если это противоречит перспективам
бизнеса.
Когда сущности имеют фиксированные, не зависящие от времени, сильно
коррелированные отношения, их следует моделировать как одно измерение.
236
Глава 6
В большинстве других случаев дизайн, вероятно, будет более простым и управляемым, если объекты разделены на два измерения (при этом следует помнить
об общих принципах, касающихся слишком большого количества измерений).
Если вы уже определили 25 измерений в своей схеме, вам следует подумать
об объединении измерений, если это возможно.
Когда измерения разделены, некоторые разработчики хотят создать небольшую таблицу с двумя ключами измерений, чтобы показать корреляцию без использования таблицы фактов заказа. Во многих сценариях эта двумерная таблица
не нужна. Нет причин избегать таблицы фактов для ответа на запрос о взаимосвязи. Таблицы фактов невероятно эффективны, потому что они содержат только
ключи измерений и показатели, а также иногда вырожденное измерение. Таблица фактов создается специально для представления корреляций и отношений
«многие ко многим» между измерениями. Как мы обсуждали в главе 5, вы можете зафиксировать назначенного в данный момент торгового представителя клиента, включив соответствующие дескрипторы в качестве атрибутов типа 1. В качестве альтернативы вы можете использовать технику медленно меняющегося
измерения (SCD) типа 5, встраивая внешний ключ типа 1 во внешнее измерение
торгового представителя в рамках измерения клиента; текущие значения могут
быть представлены так, как если бы они были указаны в измерении «Клиент»
через создание представления.
Таблица фактов без фактов для назначений клиентов/
представителей
Прежде чем мы оставим тему назначения торговых представителей клиентам,
пользователи BI системы иногда хотят иметь возможность проанализировать
сложное назначение торговых представителей клиентам с течением времени,
даже если никаких действий с заказами не произошло. В этом случае вы можете
построить таблицу фактов, не содержащую фактов, как показано на рис. 6-6, чтобы зафиксировать охват торговых представителей. Таблица охвата предоставит
полную карту исторических назначений торговых представителей клиентам, даже
если некоторые из назначений никогда не приводили к продаже. Эта не имеющая фактов таблица фактов содержит двойные ключи для даты вступления в силу
и для даты истечения срока действия каждого назначения. Дата истечения срока в текущей строке назначения представителя будет ссылаться на специальную
строку измерения даты, которая идентифицирует будущую неопределенную дату.
Вы можете сравнить таблицу фактов назначений с таблицей фактов транзакций заказа, чтобы определить назначения представителей, которые еще не привели к заказу. Вы могли бы сделать это, используя возможности SQL для выполнения заданных операций (например, выбрав всех представителей в таблице
Управление заказами
237
покрытия и вычтя всех представителей в таблице заказов) или написав коррелирующий подзапрос.
Измерение «Дата» (представления для 2 ролей)
Измерение «Торговый представитель»
Измерение «Клиент»
Факт о назначении клиенту представителя
Ключ даты вступления в силу (FK)
Ключ даты истечения срока назначения (FK)
Ключ торгового представителя (FK)
Ключ клиента (FK)
Счетчик назначения клиентов (= 1)
Рис. 6-6. Таблица фактов без фактов для назначения торговых представителей
клиентам
Измерение «Сделка»
Измерение «Сделка» аналогично измерению «Промоакция» из главы 3. Измерение «Сделка» описывает стимулы, предлагаемые клиентам, которые теоретически влияют на желание клиентов покупать продукты. Это измерение также
иногда называют контрактом. Как показано на рис. 6-7, измерение «Сделка»
описывает полную комбинацию условий, скидки и надбавок, относящихся к конкретной позиции заказа.
Измерение сделки
Ключ сделки (PK)
Идентификатор сделки (NK)
Описание предложения
Условия сделки
Условия типа сделки
Описание скидки
Описание типа скидки
Описание специального предложения
Описание типа специального предложения
Показатель местного бюджета
Рис. 6-7. Пример измерения сделки
Проблемы, с которыми вы столкнулись в измерении «Промоакция», возникают и в этом измерении «Сделка». Если условия, скидки и стимулы взаимосвязаны, имеет смысл объединить их в единое измерение «Сделка». Если условия,
скидки и стимулы совершенно не коррелированы и вы в итоге генерируете декартово произведение этих факторов в измерении, вероятно, имеет смысл разделить измерение сделки на отдельные компоненты. Опять же, это не проблема
238
Глава 6
получения или потери информации, потому что схема содержит одинаковую информацию в обоих случаях. Вопросы удобства пользователя и сложности администрирования определяют, следует ли представлять эти факторы сделки в виде
нескольких измерений. В очень большой таблице фактов, состоящей из сотен
миллионов или миллиардов строк, желание уменьшить количество ключей в составном ключе таблицы фактов способствует тому, что атрибуты сделки рассматриваются как единое измерение, предполагая, что это согласуется со взглядами
бизнес-пользователей. Конечно, любое измерение сделки меньше 100 000 строк
будет обрабатываться спокойно при такой архитектуре.
Вырожденное измерение для номера заказа
Каждая строка позиции в таблице фактов заказа включает номер заказа как вырожденное измерение. В отличие от оперативной базы данных заголовка/строки или родительской/дочерней базы данных, номер заказа в размерной модели
обычно не привязан к заголовку таблицы заказа. Вы можете вынести все интересные детали из заголовка заказа в отдельное измерение, например «Дата заказа»
и «Дата отгрузки клиенту». Номер заказа по-прежнему полезен по нескольким
причинам. Он позволяет сгруппировать отдельные позиции в заказе и ответить
на вопрос типа «Какое среднее количество позиций в заказе?» Номер заказа
иногда используется для обратной связи хранилища данных с операционным миром. Он также может играть роль в первичном ключе таблицы фактов. Поскольку порядковый номер находится в таблице фактов без присоединения к таблице
измерений, это вырожденное измерение.
ПРИМЕЧАНИЕ Вырожденные измерения обычно зарезервированы для
идентификаторов операционных транзакций. Их не следует использовать в качестве предлога для вставки загадочных кодов в таблицу фактов без присоединения к таблицам измерений для описательного декодирования.
Хотя, вероятно, у процесса сохранения номера строки транзакции заказа
нет аналитического предназначения, он может быть включен в таблицу фактов
в качестве второго вырожденного измерения, учитывая его потенциальную роль
в первичном ключе, а также связь с операционной системой записи. В этом случае первичным ключом для таблицы фактов позиции будет номер заказа и номер
строки.
Иногда элементы данных принадлежат самому заказу и не попадают естественным образом в другие таблицы измерений. В этой ситуации порядковый
номер больше не является вырожденным измерением — он представляет собой
стандартное измерение с собственным суррогатным ключом и атрибутами.
Управление заказами
239
Тем не менее дизайнеры с большим опытом работы не должны поддаваться
побуждению просто выгружать традиционную информацию заголовка заказа
в измерение заказа. Почти во всех случаях информация заголовка принадлежит
другим аналитическим измерениям, которые могут быть связаны с таблицей фактов с зернистостью уровня отдельной записи, а не просто отбрасываться в измерение, которое очень похоже на запись заголовка оперативного заказа.
Мусорные измерения
При моделировании сложных транзакционных исходных данных вы часто
сталкиваетесь с рядом различных индикаторов и флагов, которые содержат небольшой диапазон дискретных значений. У вас есть несколько довольно непривлекательных вариантов обработки этих флагов и индикаторов низкой кардинальности:
1. Игнорируйте эти флаги и индикаторы. Вы можете задать обязательный
вопрос заинтересованным лицам об устранении различных флагов, потому что они кажутся довольно незначительными, но это предложение часто
быстро отклоняется, потому что кому-то они иногда нужны. Если индикаторы непонятны или непоследовательно заполнены, возможно, их следует
исключить.
2. Оставьте флаги и индикаторы в строке фактов как есть. Вы не хотите
хранить неразборчивые загадочные индикаторы в таблице фактов. Точно
так же вы не хотите хранить громоздкие дескрипторы в строке фактов, которые могут вызвать тревожный рост таблицы. Было бы позором оставлять
в строке несколько текстовых индикаторов.
3. Сделайте каждый флаг и индикатор отдельным измерением. Добавление отдельных внешних ключей в таблицу фактов допустимо, если результирующее количество внешних ключей все еще разумно (не более 20 или
около того). Однако, если список внешних ключей уже велик, вам следует
избегать добавления лишнего беспорядка в таблицу фактов.
4. Сохраните флаги и индикаторы в измерении «Заголовок заказа». Вместо того чтобы рассматривать порядковый номер как вырожденное измерение, вы можете сделать его обычным измерением с флагами и индикаторами
низкой кардинальности в качестве атрибутов. Хотя этот подход точно представляет отношения данных, он не рекомендуется. Почему — описано ниже.
Подходящий альтернативный подход к работе с этими флагами и индикаторами — их тщательное изучение, а затем их помещение в одно или несколько мусорных измерений. Мусорные измерения сродни ящику для мелких предметов
240
Глава 6
на вашей кухне. Такой ящик — это свалка для разных предметов домашнего
обихода, таких как резинки, скрепки, батарейки и скотч. Хотя, возможно, будет
проще найти резинки, если для них выделена отдельная полка в кухонном ящике,
у вас недостаточно места для хранения всего для этого в разных ящиках. Кроме
того, у вас недостаточно случайных резинок и они не нужны вам настолько часто,
чтобы гарантировать выделение отдельного места для их хранения.
Ящик для мелочей обеспечивает удобный доступ, сохраняя при этом место
для хранения наиболее важных и часто используемых блюд и столового серебра.
В мире размерного моделирования название «мусорное измерение» зарезервировано для профессионалов DW/BI. Обычно мы называем мусорное измерение
индикатором транзакции или измерением профиля транзакции при разговоре
с бизнес-пользователями.
ПРИМЕЧАНИЕ Мусорное измерение — это группа флагов и индикаторов
с низкой кардинальностью. Создавая мусорное измерение, вы удаляете флаги
из таблицы фактов и помещаете их в полезную размерную структуру.
Если одно мусорное измерение имеет 10 индикаторов с двумя значениями,
например, «Наличные» или «Кредитная карта» как способ оплаты, то будет
максимум 1024 (2^10) строк. Наверное, неинтересно просматривать эти флаги
в измерении, потому что каждый флаг может встречаться с любым другим. Тем
не менее мусорное измерение — полезное хранилище для фильтрации или отчетности по этим флагам. Таблица фактов будет иметь единственный небольшой
суррогатный ключ для мусорного измерения.
С другой стороны, если у вас есть сильно некоррелированные атрибуты, которые принимают более многочисленные значения, может не иметь смысла объединять их в одно ненужное измерение. К сожалению, это решение не совсем
шаблонное. Если у вас есть пять индикаторов, и каждый принимает только три
значения, одно мусорное измерение — лучший путь для этих атрибутов, поскольку измерение имеет только 243 (3^5) возможных строк. Однако, если каждый из пяти некоррелированных индикаторов имеет 100 возможных значений,
мы бы предложили создать отдельные измерения, потому что сейчас существует
100 миллионов (100^5) возможных комбинаций.
На рис. 6-8 показаны образцы строк из измерения «Индикатор заказа».
Тонкость, связанная с мусорными измерениями, заключается в выборе, следует ли вам заранее создавать строки для полного декартова произведения всех
комбинаций или делать это для комбинаций по мере их обнаружения в данных.
Ответ зависит от того, сколько возможных комбинаций вы ожидаете и какое их
максимальное количество может быть. Обычно, когда количество теоретических
Управление заказами
241
комбинаций велико и вы не ожидаете встретить их все, вы создаете строку мусорного измерения во время извлечения всякий раз, когда вы сталкиваетесь с новой
комбинацией флагов или индикаторов.
Теперь, когда объяснены мусорные измерения, сравните их с обработкой флагов и индикаторов как атрибутов в измерении заголовка заказа. Если вы хотите
проанализировать факты заказа, где тип заказа — входящий (см. «Строки мусорного измерения» на рис. 6-8), таблица фактов будет ограничена так, чтобы
ключ индикатора заказа был равен 1, 2, 5, 6, 9, 10 и, вероятно, несколько других.
С другой стороны, если бы эти атрибуты были сохранены в измерении заголовка
заказа, ограничением для таблицы фактов был бы огромный список всех номеров
заказов с типом входящего заказа.
Ключ
индикатора
заказа
Описание типа
платежа
Группа типа
платежа
Тип заказа
Индикатор процентов
за кредит
1
Наличные
Наличные
Входящий
С комиссией
2
Наличные
Наличные
Входящий
Без комиссии
3
Наличные
Наличные
Исходящий
С комиссией
4
Наличные
Наличные
Исходящий
Без комиссии
5
Visa
В кредит
Входящий
С комиссией
6
Visa
В кредит
Входящий
Без комиссии
7
Visa
В кредит
Исходящий
С комиссией
8
Visa
В кредит
Исходящий
Без комиссии
9
MasterCard
В кредит
Входящий
С комиссией
10
MasterCard
В кредит
Входящий
Без комиссии
11
MasterCard
В кредит
Исходящий
Без комиссии
12
MasterCard
В кредит
Исходящий
С комиссией
Рис. 6-8. Примерные строки мусорного измерения «Индикатор заказа»
Паттерн заголовков/строк, которого следует избегать
При размерном моделировании данных заголовков/строк следует избегать двух
распространенных ошибок проектирования. К сожалению, оба этих паттерна
по-прежнему точно представляют отношения данных, поэтому они не выделяются, как одинокое дерево в степи. Возможно, в равной степени неудачно то,
что оба шаблона часто кажутся более удобными разработчикам моделей данных
и членам команды ETL, обладающим значительным опытом обработки транзакций, чем шаблоны, которые мы предлагаем. Здесь мы обсудим первую распространенную ошибку; вторая рассматривается в разделе «Другой шаблон заголовков/строк, которого следует избегать».
На рис. 6-9 показан шаблон моделирования заголовков/строк, который
мы часто наблюдаем при рассмотрении проекта. В этом примере заголовок
242
Глава 6
операционного заказа виртуально воспроизводится в размерной модели как
измерение. Измерение «Заголовок транзакции» содержит все данные из его
операционного эквивалента. Естественный ключ к этому измерению — номер
заказа. Зернистость таблицы фактов — одна строка для каждой позиции заказа,
но с ней не связано много измерений, поскольку наиболее описательный контекст встроен в измерение «Заголовок заказа».
Хотя этот дизайн точно отображает отношение заголовка/строк, есть очевидные недостатки. Измерение «Заголовок заказа», вероятно, очень велико,
особенно по сравнению с самой таблицей фактов. Если в заказе обычно пять
позиций, размер измерения на 20% больше таблицы фактов; между размером
таблицы фактов и связанными с ней измерениями должна быть разница на несколько порядков. Кроме того, таблицы измерений обычно растут с меньшей
скоростью, чем таблицы фактов. При таком дизайне вы добавляете одну строку
в таблицу измерений и в среднем по пять строк в таблицу фактов для каждого
нового заказа. Любой анализ интересных характеристик заказа, таких как клиент,
торговый представитель или задействованная сделка, должен пройти через эту
большую таблицу измерений.
Измерение «Заголовок заказа»
Номер заказа (PK)
Дата заказа
Месяц заказа
…
Запрошенная дата доставки
Запрошенный месяц доставки
…
ID клиента
Имя клиента
…
Номер торгового представителя
Торговый представитель
…
ID сделки
Описание сделки
...
Транзакционная таблица-факт строк заказа
Номер заказа (FK)
Ключ продукта (FK)
Номер строки заказа (DD)
Количество по строке заказа
Общая сумма в долларах по строке
расширенного заказа
Общая скидка в долларах по строке
расширенного заказа
Общая прибыль в долларах по строке
расширенного заказа
Измерение «Продукт»
Одна строка на заголовок заказа
Одна строка на заголовок заказа
Рис. 6-9. Паттерн, которого следует избегать: создание заголовка транзакции
как измерения
Управление заказами
243
Несколько валют
Предположим, вы отслеживаете заказы крупной транснациональной компании
в США с офисами продаж по всему миру. Вы можете фиксировать транзакции
заказов более чем в 15 различных валютах. Вы, конечно, не захотите включать
столбцы в таблицу фактов для каждой валюты.
Факт транзакции строки заказа
Измерение «Местная валюта»
Ключ местной валюты (PK)
Местная валюта
Аббревиатура для местной валюты
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Ключ измерения местной валюты (FK)
Номер заказа (DD)
Номер строки заказа (DD)
Количество строк заказа
Общая сумма в долларах по строке заказа (USD)
Общая скидка в долларах по строке заказа
Чистая сумма в долларах по строке заказа (USD)
Общая сумма в местной валюте по строке заказа
Общая скидка в местной валюте по строке заказа
Чистая сумма строки заказа в местной валюте
Рис. 6-10. Показатели в нескольких валютах в таблице фактов
Наиболее распространенное аналитическое требование состоит в том, чтобы транзакции по заказам выражались как в местной валюте транзакции, так
и в стандартизированной корпоративной валюте (в нашем примере это доллары
США). Чтобы удовлетворить эту потребность, каждый факт заказа будет заменен парой фактов — один для соответствующей местной валюты, а другой для
эквивалентной стандартной корпоративной валюты, как показано на рис. 6-10.
Обменный курс валют, используемый для построения каждой строки фактов
с двойными показателями, будет зависеть от требований бизнеса. Это может
быть курс на момент получения заказа, курс на конец дня или какой-то другой
курс, основанный на определенных бизнес-правилах. Этот метод сохранит транзакционные метрики, а также позволит легко перевести все транзакции в корпоративную валюту без сложного кода для создания отчетов. Показатели в стандартной валюте будут полностью аддитивными. Показатели в местной валюте
будут аддитивными только для одной указанной валюты; в противном случае
вы попытаетесь суммировать японскую иену, тайский бат и британский фунт
244
Глава 6
стерлингов. Вы также должны дополнить таблицу фактов измерением «Валюта», чтобы определить тип валюты, связанный с фактами местной денежной единицы; измерение «Валюта» необходимо, даже если страна транзакции известна
из других источников, поскольку местоположение не всегда указывает, какая валюта была использована.
Этот метод может быть расширен для поддержки других относительно распространенных примеров. Если офисы продаж компании объединяются в несколько региональных центров, вы можете дополнить таблицу фактов третьим
набором показателей, представляющих суммы транзакций, конвертированные
в соответствующую региональную валюту. Точно так же столбцы таблицы фактов
могут представлять валюты для отгрузки или выставления счета-фактуры клиенту,
или валюты котировки и отгрузки в том виде, в каком они указаны и отправлены.
В каждом из сценариев таблица фактов может физически содержать полный
набор показателей в одной валюте вместе с соответствующими курсами конвертации для этой строки. Вместо того чтобы обременять бизнес-пользователей
надлежащим умножением или делением на фиксированный курс, экстраполяция
внутри строки должна выполняться за кулисами; все приложения для составления отчетов будут получать доступ к фактам через этот логический уровень.
Иногда требования к мультивалютной поддержке сложнее, чем только что
описано. Возможно, вам потребуется разрешить менеджеру в любой стране видеть объем заказов в любой валюте. В этом случае вы можете дополнить первоначальный план еще одной таблицей фактов конвертации валют, как показано
на рис. 6-11. Измерения в этой таблице фактов представляют валюты, а не страны, потому что отношения между валютами и странами не «один к одному».
Более общие потребности местного торгового представителя и управления продажами в штаб-квартире будут удовлетворены простым запросом таблицы фактов заказов, но те, у кого менее предсказуемые требования, будут использовать
таблицу конвертации валют в специально созданном запросе. Навигация по таблице конвертации валют, очевидно, сложнее, чем использование преобразованных показателей в таблице фактов заказов.
Факт конвертации валюты
Ключ даты конвертации (FK)
Ключ исходной валюты (FK)
Ключ валюты назначения (FK)
Обменный курс между исходной и целевой валютой
Обменный курс между целевой и исходной валютой
Рис. 6-11. Отслеживание нескольких валют
с ежедневной таблицей фактов обмена валют
Управление заказами
245
В каждой строке таблицы фактов конвертации валюты сумма, выраженная
в местной валюте, абсолютно точная, поскольку в этот день произошла продажа в этой валюте. Эквивалентная стоимость в долларах США будет основана
на курсе конвертации в доллары США на этот день. Таблица обменных курсов
содержит комбинации соответствующих обменных курсов валют в обоих направлениях, поскольку курсы покупки и продажи двух валют не равны. Маловероятно, что эта таблица фактов преобразования должна включать полное декартово
произведение всех возможных комбинаций валют. Хотя во всем мире существует
около 100 уникальных валют, в этой таблице фактов валют не обязательно должно быть 10 000 строк каждый день, поскольку не существует значимого рынка
для каждой возможной пары. Точно так же все теоретические комбинации, вероятно, излишни для бизнес-пользователей.
Использование таблицы конвертации валют может также потребоваться для
поддержки потребности бизнеса в нескольких курсах, таких как курс закрытия
месяца или конца квартала, который может быть определен только спустя долгое
время после того, как транзакции были загружены в таблицу фактов заказов.
Факты о транзакциях с разной зернистостью
В операционных данных заголовка/строк довольно часто встречаются факты разной степени детализации. При заказе может взиматься плата за доставку, которая распространяется на весь заказ. Первой реакцией разработчика должна быть
попытка свести все факты к самому низкому уровню, как показано на рис. 6-12.
Эта процедура в общем называется распределением (allocating). Распределение
фактов родительского заказа на уровень дочерней позиции в заказе имеет решающее значение, если вы хотите иметь возможность разрезать и складывать все
факты заказа по всем измерениям, включая продукт.
К сожалению, распределение фактов уровня заголовка до уровня позиции
может повлечь за собой политические дебаты. Замечательно, если весь вопрос
о распределении решается финансовым отделом, а не командой DW/BI. Получение организационного соглашения о правилах распределения — часто спорный и сложный процесс. Команда DW/BI не должна отвлекаться и задерживать
проект из-за неизбежные организационных переговоров. К счастью, во многих
компаниях уже осознали необходимость рационального распределения стоимости пересылки между позициями в заказе. Специалист, независимый от проекта
DW/BI, уже мог установить меры калькуляции затрат на основе видов деятельности. Это просто еще одно название для распределения.
Если стоимость доставки и другие факты уровня заголовка не могут быть
успешно распределены, они должны быть представлены в сводной таблице для
всего заказа. Мы явно предпочитаем подход распределения, если это возможно,
246
Глава 6
потому что отдельная таблица фактов более высокого уровня имеет некоторые
проблемы с удобством использования. Без распределения вы не можете исследовать факты заголовка по продуктам, потому что продукт не входит в зернистость
таблицы фактов заголовка. Если вам удастся распределить факты до самого нижнего уровня, проблема исчезнет.
Факт транзакции заголовка заказа
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Номер заказа (PK)
Распределено
Стоимость доставки заказа, сумма
в долларах
Факт транзакции строки заказа
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Номер заказа (DD)
Номер строки заказа (DD)
Количество строк заказа
Общая сумма в долларах по строке заказа
Общая скидка в долларах по строке заказа
Общая прибыль в долларах по строке заказа
Распределенные расходы по доставке строки
заказа, сумма в долларах
Рис. 6-12. Распределение фактов заголовка по позициям
Не следует смешивать детализацию фактов, такие как
заголовок заказа и факты строк заказа, в одной таблице фактов. Вместо этого
либо распределите факты более высокого уровня на более подробный уровень,
либо создайте две отдельные таблицы фактов для обработки фактов с разной
степенью детализации. Распределение — предпочтительный подход.
ПРЕДУПРЕЖДЕНИЕ
Оптимально, чтобы бизнес-распорядители данных достигли консенсуса
на уровне предприятия по правилам распределения. Но иногда организации отказываются найти общее решение. Например, финансовый отдел может захотеть
распределить стоимость перевозки заказа, взимаемый на основе расширенной
суммы заказа брутто по каждой строке. Между тем логистическая группа хочет,
чтобы расходы на перевозку распределялись в зависимости от веса продукции.
В этом случае у вас будет два способа распределения стоимости доставки для
каждой строки таблицы фактов строк заказа; уникально рассчитанные метрики
также будут иметь уникальные метки. Очевидно, предпочтительнее согласовать
единую стандартную схему распределения.
Команды дизайнеров иногда пытаются разработать альтернативные методы
обработки фактов заголовка/строк с разной степенью детализации:
Управление заказами
247
1. Повторение факта нераспределенного заголовка в каждой строке. Такой подход чреват опасностью, учитывая риск завышения суммы, указанной в заголовке заказа, когда она суммируется по каждой строке.
2. Сохранение нераспределенной суммы в первой или последней строке
транзакции. Эта тактика устраняет риск неправильной суммы, но если
первая или последняя строки исключены из результатов запроса из-за
ограничения фильтра для измерения «Продукт», оказывается, что с этой
транзакцией не связано никаких фактов заголовка заказа.
3. Настройка специального ключа продукта для факта заголовка. Команды, использующие этот подход, иногда снова используют существующий
столбец фактов строк. Например, если ключ продукта = 99999, то метрика
заказа брутто — это факт заголовка, как и стоимость отправки. Размерные
модели должны быть простыми и удобочитаемыми. Вы не захотите встраивать сложности, требующие, чтобы бизнес-пользователь носил волшебное
кольцо-декодер для успешной навигации по размерной модели.
Еще один паттерн заголовка/строк,
которого следует избегать
Факт транзакции заголовка заказа
Измерение «Дата заказа»
Измерение «Запрошенная
дата отправки»
Измерение «Сделка»
Ключ даты заказа (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ клиента (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Номер заказа (PK)
Общая сумма в долларах по строке заказа
Общая скидка в долларах по строке заказа
Чистая сумма в долларах по строке заказа
Стоимость доставки заказа, сумма
в долларах
Измерение «Клиент»
Измерение
«Торговый представитель»
Факт транзакции строки заказа
Номер заказа (FK)
Номер строки заказа (DD)
Ключ продукта (FK)
Количество строк заказа
Общая сумма в долларах по строке
расширенного заказа
Общая скидка в долларах по строке
расширенного заказа
Общая прибыль в долларах по строке
расширенного заказа
Измерение «Продукт»
Рис. 6-13. Паттерн, которого следует избегать: отсутствие наследования
размерности заголовка в фактах по отдельным позициям
248
Глава 6
Второй шаблон заголовка/строк, которого следует избегать, показан
на рис. 6-13. В этом примере заголовок заказа рассматривается не как монолитное измерение, а как таблица фактов. Описательная информация, связанная с заголовком, сгруппирована по измерениям, относящимся к факту заказа. Таблица
фактов по отдельным позициям (идентичная по структуре и детализации, как
первая диаграмма) присоединяется к факту заголовка на основе номера заказа.
Опять же, этот дизайн точно отражает родительские/дочерние отношения
заголовка заказа и позиций, но все же есть недостатки. Каждый раз, когда пользователь хочет разрезать факты позиций заказа по любому из атрибутов заголовка,
большая таблица фактов заголовка должна быть связана с еще большей таблицей
фактов строки.
Операции по выставлению счета
В производственной компании выставление счетов-фактур обычно происходит
при отправке продукции с вашего предприятия клиенту. Представьте отгрузки
на погрузочной платформе, когда коробки с продуктом помещаются в грузовик,
предназначенный для определенного адреса клиента. Счет-фактура, связанная
с отгрузкой, создается в это время. Счет-фактура содержит несколько позиций, каждая из которых соответствует определенному отгружаемому продукту.
С каждой позицией связаны различные цены, скидки и надбавки. Также доступна расширенная сумма нетто для каждой позиции.
Хотя вы не показываете это в счете-фактуре покупателю, ряд других интересных фактов потенциально известен о каждом продукте во время отгрузки.
Вы наверняка знаете прейскурантные цены. Также могут быть доступны затраты
на производство и дистрибуцию. Таким образом, вы много знаете о состоянии
вашего бизнеса на момент выставления счетов клиентам.
В таблице фактов счета вы можете увидеть все продукты компании, клиентов,
контракты и сделки, скидки и надбавки вне счета, выручку, сгенерированную
клиентами, переменные и фиксированные затраты, связанные с производством
и доставкой продуктов (если таковые имеются), оставшиеся деньги после доставки продукта (доход) и показатели удовлетворенности клиентов, такие как
своевременная отгрузка.
ПРИМЕЧАНИЕ Для любой компании, которая отправляет продукты клиен-
там или выставляет счета клиентам за оказанные услуги, оптимальная точка для
начала проекта DW/BI — счета. Мы часто называем выставление счетов наиболее могущественными данными, поскольку они объединяют клиентов компании, продукты и компоненты прибыльности.
Управление заказами
249
Вы должны выбрать степень детализации таблицы фактов счета-фактуры, чтобы она была отдельной строкой счета-фактуры. Образец таблицы фактов, связанных с отгрузкой от производителя, показан на рис. 6-14.
Как и ожидалось, таблица фактов счета-фактуры содержит ряд измерений,
описанных ранее в этой главе. Согласованная таблица измерения «Дата»
снова будет играть несколько ролей в таблице фактов. Измерения «Клиент»,
«Продукт» и «Сделка» также будут согласованы, поэтому вы можете детализировать таблицы фактов, используя общие атрибуты. Если с каждой строкой
счета-фактуры связан один номер заказа, он будет включен в качестве второго
вырожденного измерения.
Факт транзакции строки накладной на отгрузку
Измерение «Дата»
(представления для 3 ролей)
Измерение «Продукт»
Измерение «Сделка»
Измерение
«Грузоотправитель»
Ключ даты счета-фактуры (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ фактической даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Ключ склада (FK)
Ключ грузоотправителя (FK)
Ключ уровня обслуживания (FK)
Номер счета (DD)
Номер строки счета (DD)
Количество строк счета-фактуры
Общая сумма в долларах в счете
Сумма надбавки по строке счета в долларах
Общая скидка в долларах по строке счета
Чистая сумма в долларах в счете
Фиксированная стоимость производителя
в долларах по строке счета
Переменная стоимость производителя в долларах
по строке счета
Стоимость хранения в долларах по строке счета
Стоимость распространения в долларах
по строке счета
Сумма взноса в строку счета в долларах
Счетчик своевременности отгрузки
Отставание от фактического времени отгрузки
Измерение «Клиент»
Измерение
«Торговый представитель»
Измерение «Склад»
Измерение
«Уровень обслуживания»
Рис. 6-14. Таблица фактов накладной отгрузки
Таблица фактов накладной отгрузки также содержит некоторые интересные
новые измерения. Измерение «Склад» содержит по одной строке для каждого
местоположения склада производителя. Это относительно простое измерение
с именем, адресом, контактным лицом и типом хранилища. Атрибуты чем-то напоминают измерение «Магазин» из главы 3. Измерение «Грузоотправитель»
250
Глава 6
описывает метод и перевозчика, с помощью которых продукт был доставлен
от производителя к покупателю.
Показатели уровня обслуживания в виде фактов,
измерений или того и другого
Таблица фактов на рис. 6-14 включает несколько критических дат, предназначенных для определения уровня обслуживания при доставке. Все эти даты
известны, когда выставляется счет. Предоставление нескольких дат событий
в таблице фактов с соответствующими ролевыми измерениями дат позволяет
бизнес-пользователям фильтровать, группировать и строить тренды по любой
из этих дат. Но иногда бизнес-требования более замысловаты.
Вы можете включить дополнительный счетчик своевременности в таблицу
фактов, который устанавливается на ноль или единицу в зависимости от того,
была ли позиция доставлена вовремя. Точно так же вы можете включить показатели задержки, представляющие количество дней, положительное или отрицательное, между запрошенной и фактической датами отгрузки. Как описано ниже
в этой главе, расчет задержки может быть более сложным, чем простая разница
между датами.
В дополнение к количественным показателям услуг вы также можете включить качественную оценку производительности, добавив либо новое измерение,
либо больше столбцов к мусорному измерению. В любом случае значения атрибутов могут выглядеть, как показано на рис. 6-15.
Ключ уровня
Описание уровня
обслуживания обслуживания
1
2
3
4
5
6
7
8
9
Вовремя
Вовремя
На 1 день раньше
Раньше
На 2 дня раньше
Раньше
На 3 дня раньше
Раньше
> чем на 3 дня раньше
Группа уровня
обслуживания
Слишком рано…
На 1 день позже
Опоздание
На 2 дня позже
Опоздание
На 3 дня позже
Опоздание
> чем на 3 дня позже
Слишком поздно
Рис. 6-15. Примеры дескрипторов качественного уровня обслуживания
Если бизнес-пользователи внимательно следят за показателями уровня обслуживания в строке счета-фактуры, вы можете воспользоваться всеми только что
описанными шаблонами, поскольку количественные показатели с качественным
текстом дают разные точки зрения на одни и те же показания.
Управление заказами
251
Факты о прибылях и убытках
Если ваша организация занимается подсчетом затрат на основе видов деятельности или внедрила надежную систему планирования ресурсов предприятия
(ERP), вы, возможно, сможете определить многие дополнительные доходы и расходы, связанные с доставкой готовой продукции заказчику. Традиционно эти
доходы и расходы располагаются последовательно от верхней строки, которая
представляет собой стоимость продуктов без скидки, отправленных покупателю, до нижней строки, которая представляет собой деньги, оставшиеся после
скидок, надбавок и затрат. Этот список доходов и расходов называется отчетом
о прибылях и убытках (P&L). Обычно вы не пытаетесь довести это до полного
представления о прибыли компании, включая общие и административные расходы. По этой причине нижняя строка отчета о прибылях и убытках называется
вкладом. Учитывая, что каждая строка в таблице фактов счета-фактуры представляет собой отдельную позицию в счете-фактуре, элементы отчета о прибылях
и убытках, показанные на рис. 6-14, имеют следующие толкования:
■ Отгруженное количество. Количество отправок продукта в определен-
ной позиции. Использование нескольких эквивалентных величин с разными единицами измерения обсуждается в разделе «Несколько единиц
измерения».
■ Расширенная сумма брутто. Также известна как расширенная прейскурантная цена, потому что это количество отгруженного товара, умноженное на цену за единицу. Эта и все последующие долларовые значения
представляют собой расширенные суммы или, другими словами, удельные
ставки, умноженные на отгруженное количество. Эта постоянность в аддитивных значениях упрощает большинство приложений для доступа
к данным и создания отчетов. Бизнес-пользователь относительно редко запрашивает цену за единицу из одной строки таблицы фактов. Когда пользователь хочет получить среднюю цену из многих строк, сначала складываются расширенные цены, а затем результат делится на сумму количеств.
■ Размер дополнительных надбавок. Сумма, вычитаемая из общей суммы
строки счета-фактуры для скидок, связанных со сделкой. Надбавки описаны в дополнительном измерении «Сделка». Сумму надбавки часто называют надбавкой вне счета. Фактический счет-фактура может иметь несколько надбавок для данной позиции; в этом упрощенном примере надбавки
объединены вместе. Если квоты необходимо отслеживать отдельно и потенциально существует много одновременных надбавок по конкретной
позиции, таблица фактов подробных данных по квотам может дополнить
таблицу фактов строки счета-фактуры, выступая в качестве детализации
252
Глава 6
для получения подробной информации об общей сумме надбавки в строке
счета-фактуры таблицы фактов.
■ Размер скидки. Сумма за вычетом скидки за объем или срок оплаты. Описания
скидок находятся в измерении «Сделка». Как обсуждалось ранее в отношении измерения «Сделка», решение о совместном описании надбавок и типов
скидок — прерогатива разработчика. Это имеет смысл сделать, если надбавки
и скидки коррелированы и бизнес-пользователи хотят просматривать измерение «Сделка», чтобы изучить отношения между надбавками и скидками.
Все надбавки и скидки в этой таблице фактов представлены на уровне
отдельных позиций. Как обсуждалось ранее, некоторые надбавки и скидки
могут быть рассчитаны оперативно на уровне счета-фактуры, а не на уровне отдельной позиции. Следует приложить усилия, чтобы распределить
их по позиции. Отчет о прибылях и убытках в счете-фактуре, который
не включает измерение «Продукт», серьезно ограничивает вашу способность представлять значимые срезы бизнесу.
■ Расширенная сумма нетто. Сумма, которую покупатель должен заплатить
за эту позицию до налогообложения. Он равен сумме счета-фактуры брутто за вычетом надбавок и скидок.
Факты, описанные до сих пор, вероятно, будут отображены клиенту в документе счета-фактуры. Следующие ниже суммы затрат, приводящие к зачислению
в чистую прибыль, предназначены только для внутреннего потребления.
■ Фиксированная стоимость производства. Сумма, определяемая произ-
водством как пропорциональная фиксированная стоимость производства
продукта, указанного в строке счета-фактуры.
■ Переменные производственные затраты. Сумма, определяемая производством как переменная производственная стоимость продукта в строке
счета-фактуры. Эта сумма может в большей или меньшей степени зависеть
от активности, отражая фактическое место и время производственного
цикла, в результате которого был произведен продукт, отправляемый покупателю. И наоборот, это число может быть стандартным значением, установленным комитетом. Если производственные затраты или любые другие
затраты на хранение и распространение — средние значения, подробные
отчеты о прибылях и убытках могут стать бессмысленными. Система DW/
BI может пролить свет на эту проблему и ускорить внедрение методов калькуляции затрат на основе видов деятельности.
■ Стоимость хранения. Стоимость хранения, указанная в строке счетафактуры, перед отправкой заказчику.
Управление заказами
253
■ Стоимость доставки. Стоимость транспортировки от места производства
до места отгрузки отражается в строке счета-фактуры. Эта стоимость известна тем, что не зависит от активности. Стоимость доставки может включать стоимость доставки до клиента, если ее оплачивает компания, или может быть представлена отдельной строкой в отчете о прибылях и убытках.
■ Сумма взноса. Расширенная счет-фактура за вычетом всех только что обсужденных затрат. Это не истинная чистая прибыль компании в целом, поскольку общие и административные расходы и другие финансовые корректировки не производились, но, однако, это важно. В этом столбце иногда
есть альтернативные метки, например маржа, в зависимости от культуры
компании.
Вы должны сделать шаг назад и полюбоваться только что построенной надежной размерной моделью. Вы составили подробный отчет о прибылях и убытках
своего бизнеса, в котором показаны все элементы доходов и расходов, основанные на деятельности. У вас есть полное уравнение прибыльности. Что делает этот
дизайн настолько привлекательным, так это то, что представление о прибылях
и убытках находится внутри обширной размерной структуры, включающей даты,
клиентов, продукты и причинные факторы. Вы хотите видеть прибыльность
по клиенту? Просто отфильтруйте и сгруппируйте по измерению «Клиент»
и внесите в отчет компоненты прибылей и убытков. Вы хотите видеть рентабельность продукта? Вы хотите видеть прибыльность сделки? Все эти анализы одинаково просты и имеют одинаковую аналитическую форму в приложениях бизнесаналитики. В некоторой степени иронично, но мы рекомендуем вам не создавать
эту размерную модель слишком рано в вашей карьере, потому что вы получите
повышение и не сможете больше работать напрямую с системами DW/BI!
Кое-что важное о прибыльности
Мы должны сбалансировать последний абзац более трезвым замечанием и внести несколько предостерегающих замечаний. Само собой разумеется, что большинство бизнес-пользователей, вероятно, очень заинтересованы в детализированных данных о прибылях и убытках, которые можно объединить для анализа
прибыльности клиентов и продукта. Реальность такова, что составить подробный отчет о прибылях и убытках часто легче сказать, чем сделать. Проблемы
возникают с фактами стоимости. Даже при продвинутых реализациях ERP довольно часто бывает невозможно зафиксировать факты затрат на этом атомарном
уровне детализации. Вы столкнетесь со сложным процессом сопоставления или
распределения исходных данных о расходах до уровня строки счета-фактуры. Более того, каждый вид затрат может потребовать отдельного извлечения данных
254
Глава 6
из исходной системы. Десять фактов о стоимости могут означать 10 различных
программ извлечения и преобразования. Прежде чем подписаться на невыполнимую миссию, обязательно выполните детальную оценку того, что доступно
и извлекаемо из исходных систем. Вы, конечно же, не хотите, чтобы команда
DW/BI была обременена приведением организации к консенсусу в отношении
расчета затрат на основе действий в качестве побочного проекта, помимо управления рядом других проектов. Если позволяет время и терпение организации,
прибыльность часто рассматривается как консолидированная размерная модель
после того, как компоненты доходов и затрат были получены и доставлены отдельно бизнес-пользователям в среде DW/BI.
Измерение «Аудит»
Как уже упоминалось, схема строки счета-фактуры на рис. 6-14 — одна из самых
эффективных, поскольку она дает подробный обзор клиентов, продуктов, доходов, затрат и итоговой прибыли в одной схеме. Во время построения строк для
этой таблицы фактов создается множество интересных секретных метаданных,
включая индикаторы качества данных, необычные требования к обработке и номера версий среды, которые определяют, как данные были обработаны во время
ETL. Хотя эти метаданные часто представляют интерес для разработчиков ETL
и ИТ-менеджмента, бывают случаи, когда они могут быть интересны и бизнеспользователям. Например, бизнес-пользователи могут спросить следующее:
■ Насколько я могу быть уверен в этих отчетных цифрах?
■ Были ли обнаружены аномальные значения при обработке этих исходных
данных?
■ Какая версия логики распределения затрат использовалась при расчете затрат?
■ Какая версия правил конвертации иностранной валюты использовалась
при расчете выручки?
На такие вопросы часто трудно ответить, потому что требуемые метаданные
недоступны. Однако, если вы ожидаете появления таких вопросов, вы можете
включить измерение «Аудит» в любую таблицу фактов, чтобы раскрыть контекст метаданных, который был истинным при построении строк таблицы фактов. На рис. 6-16 показан пример измерения «Аудит».
Измерение «Аудит» добавляется в таблицу фактов путем включения внешнего ключа измерения «Аудит». Само это измерение содержит метаданные, возникающие при обработке строк таблицы фактов. Лучше всего начать со скромной
архитектуры измерения «Аудит», как показано на рис. 6-16, чтобы не допустить
Управление заказами
255
чрезмерного усложнения обработки ETL и ограничить количество возможных
строк этого измерения. Первые три атрибута (индикатор качества, индикатор
выхода за границы и флаг скорректированной суммы) берутся из специальной
таблицы обработки ETL, называемой таблицей событий ошибок, которая обсуждается в главе 19. Распределение затрат и версии иностранной валюты — это
переменные среды, которые должны быть доступны в таблице состояний подсистемы ETL.
Факт транзакции строки накладной на отгрузку
Измерение «Дата»
(представления для 3 ролей)
Измерение «Продукт»
Измерение «Сделка»
Измерение «Грузоотправитель»
Измерение «Аудит»
Ключ аудита (PK)
Качественный показатель
Индикатор выхода за границы
Флаг скорректированной суммы
Версия распределения затрат
Версия иностранной валюты
Ключ даты счета-фактуры (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ фактической даты отгрузки (FK)
Ключ клиента (FK)
Ключ продукта (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Ключ склада (FK)
Ключ грузоотправителя (FK)
Ключ уровня обслуживания (FK)
Ключ аудита (FK)
Номер счета (DD)
Номер строки счета (DD)
Количество строк счета-фактуры
Общая сумма в долларах в счете
…
Измерение «Клиент»
Измерение
«Торговый представитель»
Измерение «Склад»
Измерение
«Уровень обслуживания»
Рис. 6-16. Пример измерения аудита, включенного в таблицу фактов счета
Стандартный отчет:
Продукт
Склад
Количество строк
счета-фактуры
Axon
Axon
East
West
1438
2249
Расширенная
строка счета-фактуры
Общая сумма
235 000
480 000
Инструментальный отчет (с добавленным индикатором выхода за границы):
Продукт
Склад
Индикатор
выхода
за границы
Axon
Axon
Axon
Axon
East
East
West
West
Abnormal
Normal
Abnormal
Normal
Количество
строк
счета-фактуры
Расширенная
строка счета-фактуры
Общая сумма
14
1424
675
1574
2350
232 650
144 000
336 000
Рис. 6-17. Атрибут измерения аудита включен в стандартный отчет
256
Глава 6
Взяв на вооружение измерение «Аудит», можно выполнять несколько полезных
запросов. Вы можете взять утренний отчет по счету и спросить, были ли какие-либо
из указанных чисел основаны на показателях, выходящих за пределы допустимого.
Поскольку измерение «Аудит» теперь обычное измерение, вы можете просто добавить индикатор выхода за границы в свой стандартный отчет. В итоговом инструментальном отчете, показанном на рис. 6-17, вы видите несколько строк, показывающих
нормальные и аномальные результаты за пределами допустимого диапазона.
Накопление снимков для конвейера
выполнения заказов
Управление заказами можно рассматривать как конвейер, особенно в производстве, основанном на заказах, как показано на рис. 6-18. Клиенты размещают заказ,
который ожидает в очереди, пока он не будет передан в производство для сборки.
Изготовленная продукция помещается в запас готовой продукции, а затем отправляется покупателям, и выставляется счет-фактура. Уникальные транзакции генерируются на каждом шаге конвейера. До сих пор мы рассматривали каждую из этих
конвейерных операций как отдельную таблицу фактов транзакции. Это позволяет
дополнить подробные факты, генерируемые каждым процессом, наибольшим количеством подробных измерений, а также изолировать анализ производительности одного бизнес-процесса, что часто именно то, чего хотят бизнес-пользователи.
Заказы
Очередь
на выполнение
Выпустить
в производство
Склад
готовой
родукции
Отгрузка
Выставление
счета
Рис. 6-18. Схема конвейера выполнения заказа
Однако бывают случаи, когда бизнес-пользователи хотят проанализировать
весь конвейер выполнения заказа. Они хотят лучше понимать скорость движения продукта или то, как быстро продукты перемещаются по конвейеру. Таблица
накопительных фактов моментального снимка обеспечивает такую перспективу
бизнеса, как показано на рис. 6-19. Она позволяет вам видеть обновленный статус и в итоге окончательное расположение каждого заказа.
Накопительный моментальный снимок дополняет перспективы альтернативных схем конвейера. Если вы заинтересованы в понимании количества продукта,
проходящего через конвейер, например, количества заказанного, произведенного или отгруженного товара, схемы транзакций отслеживают каждое из основных
событий конвейера. Периодические моментальные снимки позволят получить
Управление заказами
257
представление о количестве продукта, находящегося в конвейере, например о запасах незавершенных заказов, готовой продукции или о количестве продукта,
проходящего через шаг процесса в течение заранее определенного интервала. Накопительный снимок помогает лучше понять текущее состояние заказа, а также
скорость движения продукта, чтобы определить узкие места и неэффективность
процесса. Если вы фиксируете производительность только в таблицах фактов событий транзакций, было бы чрезвычайно сложно рассчитать среднее количество
дней, на которое нужно перемещаться между контрольными точками.
Накопительный факт выполнения заказов
Измерение «Дата»
(представления
для 9 ролей)
Измерение «Клиент»
Измерение «Сделка»
Измерение «Склад»
Ключ даты заказа (FK)
Ключ даты отставания (FK)
Ключ даты выпуска к производству (FK)
Ключ даты размещения готовой продукции (FK)
Ключ запрошенной даты отгрузки (FK)
Ключ запланированной даты отгрузки (FK)
Ключ фактической даты отгрузки (FK)
Ключ даты прибытия (FK)
Ключ даты счета-фактуры (FK)
Ключ продукта (FK)
Ключ клиента (FK)
Ключ торгового представителя (FK)
Ключ сделки (FK)
Ключ производственного объекта (FK)
Ключ склада (FK)
Ключ грузоотправителя (FK)
Номер заказа (DD)
Номер строки заказа (DD)
Номер счета (DD)
Количество в заказе
Общая прибыль в долларах по строке заказа
Количество товара, направленного
на производство
Количество товара, завершившего производство
Количество товара, не завершившего
производство
Количество готовой продукции в запасах
Разрешено продавать количество
Объем отгрузки
Количество повреждений отгрузки
Количество возврата клиента
Количество строк счета-фактуры
Чистая сумма в долларах в счете
Задержка отдачи заказа на производство
Задержка передачи заказа с производства
на склад
Задержка передачи товара со склада на отгрузку
Задержка от заказа до отгрузки
Измерение «Продукт»
Измерение
«Торговый представитель»
Измерение
«Производственное
помещение»
Измерение
«Грузоотправитель»
Рис. 6-19. Накопительная таблица фактов моментального снимка
выполнения заказа
258
Глава 6
Накопительный моментальный снимок выглядит не так, как таблицы фактов
транзакций, разработанные до сих пор в этой главе. Ожидается повторное использование согласованных измерений, но количество столбцов даты и фактов
больше. Каждая дата представляет собой важную веху на пути реализации заказа.
Даты обрабатываются как ролевые измерения путем создания физически различных таблиц или логически различных представлений. В измерении «Дата» должна быть строка «Неизвестно» или «Подлежит определению», поскольку многие из этих дат таблицы фактов неизвестны при первоначальной загрузке строки
конвейера. Очевидно, вам не нужно объявлять все столбцы даты в первичном
ключе таблицы фактов.
Фундаментальное различие между накоплением снимков состояния и другими таблицами фактов состоит в том, что вы можете повторно посещать и обновлять существующие строки таблицы фактов по мере поступления дополнительной информации. Зернистость накопительной таблицы фактов моментального
снимка на рис. 6-19 представляет собой одну строку для каждой позиции заказа.
Однако, в отличие от таблицы фактов транзакции заказа, показанной на рис. 6-2,
с той же степенью детализации, накапливаемые строки фактов моментального
снимка изменяются, пока заказ перемещается по конвейеру, поскольку на каждом этапе цикла собирается больше информации.
ПРИМЕЧАНИЕ Таблицы фактов для накопления моментальных снимков
обычно имеют несколько дат, представляющих основные этапы процесса. Однако этот факт не означает, что это накопительный моментальный снимок. Основное отличие накопительного моментального снимка в том, что вы пересматриваете строки фактов по мере возникновения деятельности.
Метод накопления моментальных снимков особенно полезен, когда продукт,
движущийся по конвейеру, однозначно идентифицируется, например автомобиль с идентификационным номером, электронное оборудование с серийным
номером, лабораторные образцы с идентификационным номером или партии
производственного процесса с идентификационным номером. Накопительный
снимок помогает понять пропускную способность и выход продукции. Если
детализация накопительного моментального снимка соответствует серийному номеру или номеру партии, вы можете увидеть расположение конкретного
продукта по мере его продвижения по конвейеру производства и тестирования.
Накопительный моментальный снимок наиболее естественно сочетается с кратковременными процессами с определенным началом и концом. Долгоживущие
процессы, такие как банковские счета, обычно лучше моделируются с помощью
периодических таблиц фактов моментальных снимков.
Управление заказами
259
Накопление снимков и измерения типа 2
Накопление снимков показывает последнее состояние рабочего потока или конвейера. Если измерения, связанные с накопительным моментальным снимком,
содержат атрибуты типа 2, таблица фактов должна быть обновлена для ссылки
на последний ключ суррогатного измерения для активных конвейеров. Когда
одна строка конвейера таблицы фактов завершена, эта строка обычно не пересматривается, чтобы отразить будущие изменения типа 2.
Расчет задержек
Длинный список столбцов с датами фиксирует промежутки времени, в течение
которых заказ обрабатывается в конвейере выполнения. Числовая разница между любыми двумя из этих дат — это число, которое можно с пользой усреднить
по всем измерениям. Эти расчеты отставания по датам представляют собой основные показатели эффективности выполнения. Вы можете построить представление на этой таблице фактов, которое вычислит большое количество этих разниц дат и представит их так, как если бы они были сохранены в базовой таблице.
Эти столбцы представления могут включать такие показатели, как разность дат
от заказа к выпуску продукции, отставание от выпуска продукции к складированию продукции и разность от заказа к отгрузке, в зависимости от периодов дат,
отслеживаемых организацией.
Вместо того чтобы вычислять простую разницу между двумя датами с помощью представления, система ETL может вычислять прошедшее время, которое
включает в себя больше информации, например, задержки, измеренные в рабочих днях, которые учитывают выходные и праздничные дни, а не просто количество дней между датами этапов. Метрики запаздывания также могут быть рассчитаны системой ETL на более низком уровне детализации (например, количество
часов или минут между контрольными событиями на основе рабочих временных
меток) для краткосрочных и тщательно отслеживаемых процессов.
Несколько единиц измерения
Иногда разные функциональные организации в рамках бизнеса хотят видеть одни
и те же показатели производительности, выраженные в разных единицах измерения. Например, менеджеры по производству могут захотеть увидеть поток продукции с точки зрения поддонов или транспортных ящиков. С другой стороны,
менеджеры по продажам и маркетингу могут захотеть увидеть количество в розничных ящиках, единицах сканирования (торговых упаковках) или эквивалентных
потребительских единицах (например, отдельных банках газировки).
У разработчиков возникает соблазн спрятать коэффициенты пересчета единиц
измерения, такие как коэффициент коробки поставки, в измерении «Продукт».
260
Глава 6
Затем бизнес-пользователи должны соответствующим образом умножить (или
разделить?) количество товаров в заказе на коэффициент пересчета. Очевидно,
что такой подход накладывает на пользователей дополнительную нагрузку, помимо того, что он подвержен ошибкам вычислений. Ситуация еще более усложняется, потому что коэффициенты преобразования могут меняться со временем,
поэтому пользователям также необходимо будет определить, какой коэффициент
применим в конкретный момент.
Вместо того чтобы рисковать ошибиться при вычислении эквивалентных величин, помещая коэффициенты пересчета в таблицу измерений, их следует хранить
в таблице фактов. Предположим, что в таблице фактов конвейера заказов у вас есть
10 основных фундаментальных количественных фактов в дополнение к пяти единицам измерения. Если вы физически храните все факты, выраженные в разных
единицах измерения, вы получите 50 (10 × 5) фактов в каждой строке фактов. Вместо этого вы можете пойти на компромисс, построив базовую физическую строку
с 10 фактами количества и 4 коэффициентами преобразования единиц измерения. Вам нужно всего четыре коэффициента преобразования, а не пять, потому
что основные факты уже выражены в одной из единиц измерения. Физический
дизайн теперь имеет 14 фактов, связанных с количеством (10 + 4), как показано
на рис. 6-20. Благодаря такому дизайну вы можете увидеть производительность
по всей цепочке создания ценности на основе различных единиц измерения.
Накопительный факт выполнения заказов
Ключи даты (FK)
Ключ продукта (FK)
Другие ключи FK …
Количество отгрузочных ящиков для заказа
Количество ящиков отгрузки товара с производства
Количество ящиков отгрузки товара с производства, прошедших контроль
Количество ящиков отгрузки товара с производства, не прошедших контроль
Финальное количество ящиков отгрузки товара с производства
Имеет право продавать ящики для отгрузки
Количество ящиков для отгрузки
Количество поврежденных ящиков для отгрузки
Количество отправлений, возвращаемых клиентом
Количество отгруженных ящиков по счету-фактуре
Коэффициент преобразования поддонов
Коэффициент конверсии розничных ящиков
Коэффициент преобразования единиц сканирования
Коэффициент преобразования приравненных единиц потребления
Рис. 6-20. Таблица физических фактов, поддерживающая несколько единиц
измерения с коэффициентами пересчета
Управление заказами
261
ПРИМЕЧАНИЕ Объединение всех фактов и коэффициентов преобразова-
ния в одну строку таблицы фактов обеспечивает наиболее надежную гарантию
того, что эти коэффициенты будут использоваться правильно. Преобразованные
факты отображаются пользователю в виде представлений (View).
Конечно, вы можете доставить эту таблицу фактов бизнес-пользователям
с помощью одного или нескольких представлений. Дополнительные вычисления,
связанные с умножением количеств на коэффициенты преобразования, незначительны; внутристрочные вычисления очень высокоэффективны. Наиболее полное представление может отображать все 50 фактов, выраженных в каждой единице измерения, но представление можно упростить, чтобы отображать только
подмножество количеств в единицах измерения, относящихся к пользователю.
Очевидно, что каждая единица измерения показателей должна иметь уникальную маркировку.
Наконец, еще одно побочно преимущество хранения этих факторов в таблице фактов в том, что это снижает нагрузку на таблицу измерения «Продукт»,
заставляющую создавать новые строки продукта, чтобы отразить незначительные
изменения коэффициента преобразования. Эти факторы, особенно если они постоянно меняются с течением времени, больше похожи на факты, чем на атрибуты измерений.
За пределами зеркала заднего вида
Многое из того, что мы обсуждали в этой главе, сосредоточено на эффективных
способах анализа исторической эффективности движения продукта по конвейеру. Люди иногда называют их показателями зеркала заднего вида, потому что они позволяют вам оглянуться и увидеть, где вы были. Как напоминает
брокерская индустрия, прошлые результаты не гарантия результатов будущих.
Многие организации хотят дополнить эти исторические показатели производительности фактами из других процессов, чтобы помочь спрогнозировать то,
что их ждет впереди. Например, вместо того чтобы сосредотачиваться на конвейере во время получения заказа, организации анализируют ключевые факторы, влияющие на получение заказа. В организации продаж такие факторы, как
поисковая или запросы на квоты, могут быть экстраполированы, чтобы обеспечить наглядность ожидаемого объема заказов. Многие организации лучше
справляются со сбором информации о показателях «зеркала заднего вида»,
чем с выявлением первичных индикаторов. По мере того как эти индикаторы
фиксируются, их можно аккуратно добавить в среду DW/BI. Это просто несколько строк в матрице шины корпоративного хранилища данных, имеющих
общие измерения.
262
Глава 6
Выводы
В этой главе был рассмотрен длинный список тем в контексте процесса управления заказами. Множественные аспекты обсуждались по нескольким направлениям: множественные ссылки на одно и то же измерение в таблице фактов (ролевые измерения), несколько эквивалентных единиц измерения и несколько валют.
Мы исследовали несколько распространенных проблем, с которыми сталкиваются при моделировании данных транзакции заголовка/строк, включая факты
на разных уровнях детализации и мусорные измерения, а также шаблоны проектирования, которых следует избегать. Мы также изучили богатый набор фактов,
связанных с транзакциями по счетам. Наконец, конвейер выполнения заказов
продемонстрировал возможности накопительных таблиц фактов моментальных
снимков, где вы можете видеть обновленный статус конкретного продукта или
заказа по мере его продвижения по конечному конвейеру.
7
Ф
Бухгалтерский
учет
инансовый анализ включает в себя различные бухгалтерские приложения,
такие как «Главная бухгалтерская книга», подробные вспомогательные
книги по закупкам и кредитной задолженности, выставлению счетов и дебетовой задолженности, а также по основным активам. Поскольку ранее мы уже рассматривали заказы на покупку и счета-фактуры, в этой главе мы сосредоточимся
на главной бухгалтерской книге. Учитывая необходимость точной обработки финансовых отчетов компании, Главные бухгалтерские книги были одним из первых приложений, которые были компьютеризированы несколько десятилетий
назад. Возможно, даже некоторые из вас все еще ведут свой бизнес по системе
учета 20-летней давности. В этой главе мы обсудим данные, собранные Главной
бухгалтерской книгой — как с точки зрения журнала записи внутренних транзакций, так и с точки зрения показателей на конец отчетного периода. Мы также
поговорим о процессе составления бюджета.
В главе 7 обсуждаются следующие концепции:
■ фрагмент матрицы шины для процессов учета;
■ периодические снимки Главной бухгалтерской книги и проводки журнала;
■ план счетов;
■ закрытие периода;
■ факты за прошедший год;
■ несколько календарей финансового учета;
■ детализация по иерархии при наличии нескольких бухгалтерских книг;
■ цепочка составления бюджета и связанные с ней процессы;
■ иерархии позиций с фиксированной глубиной;
■ прерывающиеся иерархии переменной глубины;
■ полностью нефиксированные иерархии неопределенной глубины (с использованием таблицы соединений и альтернативных методов моделирования);
■ совместное владение данными в нефиксированной иерархии;
264
Глава 7
■ нефиксированные иерархии с изменениями во времени;
■ сводные таблицы фактов, объединяющие показатели из нескольких бизнеспроцессов;
■ роль OLAP и комплексных аналитических финансовых решений.
Тематическое исследование
по бухгалтерскому учету и матрица шин
Поскольку сфера финансов была одной из первых, где стали применяться новые
технологии, неудивительно, что ранние нововведения для поддержки принятия
решений были сосредоточены на анализе финансовых данных. Финансовые аналитики — одни из самых грамотных специалистов в области обработки данных
и одни из тех, кто лучше всего разбирается в электронных таблицах. Часто их
отчеты рассылаются на всю компанию или используется многими другими сотрудниками организации. Менеджерам всех уровней необходим своевременный
доступ к ключевым финансовым показателям. В дополнение к получению стандартных отчетов им необходима способность анализировать тренды производительности, отклонения и аномалии с относительно высокой скоростью и минимальными усилиями.
Как и во многих операционных системах-источниках, данные в Главной бухгалтерской книге, скорее всего, разбросаны по сотням таблиц. Для получения
доступа к финансовым данным и/или создания специальных отчетов может потребоваться волшебная карта для навигации по целому лабиринту экранов. Это
противоречит цели многих организаций, заключающейся в том, чтобы возложить финансовую ответственность и подотчетность на линейных руководителей.
Система DW/BI может предоставить единый источник полезной и понятной финансовой информации, гарантируя, что все работают с одними и теми же
данными с помощью общих определений и общих инструментов. Аудитория получателей финансовых данных довольно разнообразна во многих организациях
начиная от аналитиков и заканчивая операционными менеджерами и руководителями. Для каждой группы необходимо определить, какое подмножество корпоративных финансовых данных необходимо, в каком формате и с какой периодичностью. Аналитики и менеджеры хотят просматривать информацию на высоком
уровне, а затем переходить к записям журнала для получения более подробной
информации. Для руководителей финансовые данные из системы DW/BI часто
используются в их визуализированных сводных отчетах или системе показателей ключевых показателей эффективности. Вооруженные прямым доступом
к информации, менеджеры могут получить ответы на вопросы с бóльшим успехом, чем когда их заставляют работать через посредника. Между тем финансовый
Бухгалтерский учет
265
Расче
тный
счет
Орган
X
X
X
X
Мгновенное состояние
бухгалтерской книги
X
X
X
X
Бюджет
X
X
X
X
X
Обязательства
X
X
X
X
X
X
Платежи
X
X
X
X
X
X
Разница в фактическом бюджете
X
X
X
X
изаци
Проф
опла иль
ты
Бухга
книгалтерская
Основные транзакции
в бухгалтерской книге
я
Дата
Стать
я бюд
жета
Проф
обяза иль
тельс
тв
отдел может обратить свое внимание на распространение информации и анализ
добавленной стоимости, а не на создание отчетов.
Улучшенный доступ к данным бухгалтерского учета позволяет сосредоточиться на возможностях лучшего управления рисками, оптимизации операций
и определения потенциальной экономии средств. Хотя это оказывает влияние
на всю организацию, многие предприятия сосредотачивают первоначальное
внедрение DW/BI на стратегических возможностях получения дохода. Следовательно, бухгалтерские данные часто не относятся к первой предметной области,
которой занимается команда DW/BI. Учитывая их опыт работы с технологиями,
финансовый отдел часто уже творил чудеса с электронными таблицами и настольными базами данных для создания обходных аналитических решений, возможно,
к своему скорому краху, поскольку эти несовершенные промежуточные решения,
вероятно, не пройдут испытания на прочность.
На рис. 7-1 показана выдержка из матрицы шины организации, ориентированная на бухгалтерский учет. Измерения, связанные с процессами учета, такие
как «Счет в бухгалтерской книге» или «Статьи расходов» организации, часто
используются исключительно этими процессами, в отличие от основных измерений типа «Клиент», «Продукт» и «Сотрудник», которые многократно используются во многих различных бизнес-процессах.
X
Рис. 7-1. Строки матрицы шины для процессов учета
Данные Главной бухгалтерской книги
Главная бухгалтерская книга (ГБК) — это основная финансовая система, которая
объединяет подробную информацию, собранную во вспомогательных книгах или
отдельных системах для покупок, кредитной задолженности (сколько вы должны
266
Глава 7
другим) и дебетовой задолженности (сколько другие должны вам). По мере того
как мы будем работать над базовым дизайном для финансовых данных, вы обнаружите необходимость в двух дополнительных схемах с таблицами периодических моментальных снимков и таблицами фактов для этих транзакций.
Периодический моментальный снимок Главной
бухгалтерской книги
Мы начнем нашу работу с моментальных снимков счетов Главной бухгалтерской
книги в конце каждого финансового периода (или месяца, если финансовые отчетные периоды совпадают с календарными месяцами). Возвращаясь к нашему
четырехэтапному процессу разработки размерных моделей (см. главу 3), бизнеспроцесс — это и есть Главная бухгалтерская книга. За зернистость здесь принимается одна строка за отчетный период для наиболее детализированного уровня
плана счетов Главной бухгалтерской книги.
План счетов
Краеугольный камень Главной бухгалтерской книги — план счетов. План счетов
бухгалтерской книги — высшее воплощение смыслового ключа, поскольку он
обычно состоит из ряда идентификаторов. Например, первый набор цифр может
идентифицировать счет, тип счета (например, актив, обязательство, собственный капитал, доход или расходы) и другие сводные данные счета. Иногда смысл
встроен в схему нумерации счетов. Например, номера счетов от 1000 до 1999
могут быть счетами активов, в то время как номера счетов от 2000 до 2999 могут
указывать на обязательства. Очевидно, что в хранилище данных вы бы включили
«тип счета» в качестве атрибута измерения, а не заставляли пользователей фильтровать первую цифру номера счета.
План счетов, скорее всего, связывает статьи расходов организации со счетами.
Как правило, атрибуты организации обеспечивают полный доступ, например,
от статьи затрат к отделу и подразделению. Если корпоративная Главная бухгалтерская книга объединяет данные по нескольким подразделениям, в плане счетов
также будет указано подразделение или дочерняя компания.
Очевидно, что планы счетов варьируются от организации к организации.
Они часто чрезвычайно сложны, поскольку связаны с сотнями или даже тысячами статей расходов в крупных организациях. В этом небольшом примере план
счетов естественным образом распадается на два измерения. Одно представляет
счета в Главной бухгалтерской книге, в то время как другое представляет сводную
структуру организации.
Сводная структура организации может представлять собой иерархию фиксированной глубины, которая будет обрабатываться как отдельные иерархические
Бухгалтерский учет
267
атрибуты в измерении «Статья расходов». Если иерархия организации нефиксированная с несбалансированной структурой свертки, вам понадобятся более
мощные методы для иерархии с переменной глубиной, описанные в разделе
«Нормальный перевод».
Если вам поручено создать всеобъемлющую Главную бухгалтерскую книгу,
охватывающую несколько организаций в системе DW/BI, вы должны попытаться согласовать план счетов, чтобы типы счетов означали одно и то же в разных
организациях. На уровне данных это означает, что измерение «Счет» содержит
тщательно определенные имена счетов. «Капитальные затраты» и «Канцелярские принадлежности» должны иметь одинаковое финансовое значение для всех
организаций. Конечно, этот вид согласованного измерения имеет старое и знакомое название в финансовых кругах: «Единый план счетов».
ГБК иногда отслеживает финансовые результаты для нескольких наборов книг
или вспомогательных книг для поддержки различных требований, таких как налогообложение или отчетность для регулирующих органов. Вы можете рассматривать их как отдельное измерение, потому что это фундаментальный фильтр,
но мы просим внимательно прочитать предостережение в следующем разделе.
Закрытие периода
В конце каждого отчетного периода финансовая организация несет ответственность за окончательную оценку финансовых результатов, чтобы они могли быть
официально представлены как внутри организации, так и за ее пределами. Обычно в конце каждого периода требуется несколько дней, чтобы выверить и сбалансировать бухгалтерские книги, прежде чем они могут быть закрыты с официальной печатью, будучи одобренными финансовым отделом. С этого момента
фокус внимания переключается с финансов на отчетность и интерпретацию результатов. Часто выпускаются бесчисленные отчеты, и каждый месяц возникает
необходимость отвечать на различные варианты одних и тех же вопросов.
Финансовые аналитики постоянно стремятся оптимизировать процессы закрытия отчетного периода, сверки и отчетности по результатам Главной бухгалтерской книги. Хотя операционные системы Главной бухгалтерской книги часто
поддерживают эти необходимые возможности, они могут быть громоздкими,
особенно если вы имеете дело с устаревшей бухгалтерской книгой. В этой главе основное внимание уделяется простому анализу финансовых результатов закрытия периода, а не облегчению его закрытия. Однако во многих организациях
предварительные балансы главной книги загружаются в систему DW/BI, используя возможности области представления DW/BI, чтобы найти иголки в стоге
сена главной бухгалтерской книги, а затем внести соответствующие оперативные
корректировки до окончания периода.
268
Глава 7
Примерная схема на рис. 7-2 показывает остатки на счетах в Главной бухгалтерской книге в конце каждого отчетного периода, что может оказаться весьма
полезным для многих видов финансового анализа, таких как ранжирование счетов, динамика трендов и сравнение периодов.
Измерение
«Отчетный период»
Таблица фактов
бухгалтерской книги
Измерение
«Бухгалтерская книга»
Ключ отчетного периода (PK)
Номер отчетного периода
Описание отчетного периода
Фискальный отчетного
периода
Ключ отчетного периода (FK)
Ключ бухгалтерской книги (FK)
Ключ счета (FK)
Ключ организации (FK)
Остаток на балансе на конец
периода
Сумма дебита периода
Сумма кредита периода
Чистое изменение в сумме
за период
Ключ бухгалтерской книги (PK)
Название бухгалтерской книги
Измерение «Счет»
Ключ счета (PK)
Название счета
Категория счета
Тип счета
Измерение «Организация»
Ключ организации (PK)
Наименования статьи расхода
Номер статьи расхода
Наименование подразделения
Номер подразделения
Наименование отдела
Наименование бизнес-юнита
Наименование компании
Рис. 7-2. Пример главной книги
На данный момент мы просто представляем актуальные факты бухгалтерской
книги на схеме рис. 7-2; мы углубим наше представление при обсуждении данных бюджета в разделе «Нормальный перевод». В этой таблице сумма баланса — полуаддитивный факт. Хотя баланс не отражает финансовую активность,
мы включаем этот факт в разработку, потому что он очень полезен. В противном
случае вам нужно было бы вернуться к началу времени, чтобы рассчитать точный
баланс на конец периода.
Измерение «Бухгалтерская книга»– это удобное
и интуитивно понятное измерение, которое позволяет хранить несколько бухгалтерских книг в одной таблице фактов. Однако каждый запрос, обращающийся к этой таблице фактов, должен ограничивать измерение Главной книги одним значением (например, «Окончательно утвержденная внутренняя главная
книга»), иначе запросы будут дважды подсчитывать значения из различных бухгалтерских книг в этой таблице. Лучший способ развертывания этой схемы —
предоставить бизнес-пользователям отдельные представления с предварительно
ограниченным набором параметров Главной книги.
ПРЕДУПРЕЖДЕНИЕ
Два наиболее важных измерения в предлагаемой модели главной книги —
модели и «Организация». Измерение «Счет» выведено из единого плана
Бухгалтерский учет
269
счетов на предприятии. Измерение «Организация» описывает объекты финансовой отчетности на предприятии. К сожалению, эти два важнейших измерения почти никогда не соответствуют операционным измерениям, таким как
«Клиент», «Продукт», «Услуга» и «Обьект». Это приводит к характерному,
но неизбежному разочарованию бизнес-пользователей, к примеру, «ГБК не привязана к моим оперативным отчетам». Лучше всего мягко объяснить это бизнес-пользователям в процессе собеседования, а не обещать исправить что-либо,
потому что это проблема сидит глубоко, в базовых данных.
Факты типа «С начала года и до сегодняшнего дня»
(year-to-date/YTD)
У разработчиков часто возникает соблазн хранить «К сегодняшнему дню»
(to-date) столбцы в таблицах фактов. Они считают, что было бы полезно
хранить аддитивные суммы «с начала квартала и до сегодняшнего дня»
или «с начала года и до сегодняшнего дня» в каждой строке фактов, чтобы
не нужно было их вычислять. Помните, что числовые факты должны соответствовать зернистости. To-date факты часто не соответствуют зернистости
и чреваты некоторыми опасностями. Когда строки фактов запрашиваются и суммируются произвольным образом, эти факты, не соответствующие
зернистости, приводят к бессмысленным, завышенным результатам. Их следует исключить из реляционной схемы и вместо этого рассчитать в приложении BI. Стоит отметить, что кубы OLAP более корректно обрабатывают
«To-date» показатели.
ПРИМЕЧАНИЕ В целом итоговые данные «К сегодняшнему дню» (to-date)
должны быть рассчитаны, а не сохранены в таблице фактов.
Пересмотр нескольких валют
Если Главная бухгалтерская книга объединяет данные, которые были записаны
в нескольких валютах, вы будете обрабатывать их так же, как мы обсуждали в главе 6. При работе с финансовыми данными обычно требуется представлять факты как в местной валюте, так и в стандартизированной корпоративной валюте.
В этом случае каждая строка таблицы фактов будет представлять один набор фактических сумм, выраженных в местной валюте, и отдельный набор фактических
сумм в той же строке, выраженных в эквивалентной корпоративной валюте. Это
позволяет вам легко обобщать факты в общей корпоративной валюте, не оставляя никаких неоднозначностей для приложений BI. Конечно, вы также должны
добавить измерение «Валюта» в качестве внешнего ключа в таблицу фактов,
чтобы определить тип местной валюты.
270
Глава 7
Транзакции журнала Главной бухгалтерской книги
В то время как моментальный снимок отчета на конец периода охватывает множество финансовых анализов, многим пользователям необходимо углубиться в детали. Если аномалия выявлена на уровне сводных данных, аналитики хотят просмотреть подробные транзакции, чтобы разобраться в проблеме. Другим необходим
доступ к деталям, поскольку суммированные ежемесячные балансы могут скрывать
большие различия на детальном уровне транзакций. Опять же, вы можете дополнить периодический снимок подробной схемой транзакций записи в журнале. Конечно, субрегистраторы кредитной и дебетовой задолженности могут содержать
транзакции с постепенно снижающимися уровнями детализации, которые будут
отражены в отдельных таблицах фактов с дополнительной размерностью.
Структура таблицы фактов теперь составляет одну строку для каждой транзакции записи в журнале главной бухгалтерской книги. Проводка записи в журнале идентифицирует основной счет и соответствующую сумму дебета или
кредита. Как показано на рис. 7-3, несколько измерений из последней схемы
используются повторно, включая учетную запись и организацию. Если главная
книга отслеживает несколько наборов книг, вы также должны включить измерение «Книга». Обычно вы фиксируете транзакции записи в журнале по дате
проводки транзакции, поэтому в этой схеме используйте таблицу данных с ежедневной детализацией. В зависимости от бизнес-правил, связанных с исходными
данными, вам может потребоваться второе ролевое измерение «Дата», чтобы
отличать дату учета от даты вступления бухгалтерского учета в силу.
Таблица фактов записи
в журнал бухгалтерской книги
Измерение «Дата»
Измерение «Счет»
Измерение «Индикатор
дебита и кредита»
Ключ индикатора дебита
и кредита (PK)
Описание индикатора дебита
и кредита
Ключ даты записи (FK)
Эффективная дата/время
записи в журнал
Ключ бухгалтерской книги (FK)
Ключ счета (FK)
Ключ организации (FK)
Ключ индикатора дебита
и кредита (FK)
Номер записи в журнале (DD)
Количество записей в журнале
Измерение
«Бухгалтерская книга»
Измерение «Организация»
Рис. 7-3. Операции ввода данных в Главной бухгалтерской книге
Номер записи в журнале, скорее всего, — вырожденное измерение, не связанное с соответствующей таблицей атрибутов. Если номера записей журнала
Бухгалтерский учет
271
из источника упорядочены, то это вырожденное измерение можно использовать
для упорядочения записей журнала, поскольку измерение «Календарная дата»
в этой таблице фактов слишком неточное, чтобы обеспечить такую сортировку.
Если номера записей журнала с трудом поддерживают сортировку, то в таблицу
фактов необходимо добавить метку даты/времени вступления в силу всех изменений. В зависимости от исходных данных у вас может быть указан тип транзакции записи в журнале и даже описание. В этой ситуации вам следует создать
отдельное измерение профиля транзакции записи журнала (не показано). Если
описания представляют собой не просто текст произвольной формы, то в этом
измерении будет значительно меньше строк, чем в таблице фактов, в которой
будет по одной строке на строку записи в журнале. Указанный номер записи
в журнале по-прежнему будет рассматриваться как вырожденный. Каждая строка
в таблице фактов записи журнала идентифицируется либо как кредит, либо как
дебет. Индикатор дебет/кредит принимает два и только два значения.
Несколько календарей финансового учета
На рис. 7-3 данные собраны по дате публикации, но пользователи могут также захотеть суммировать данные по периоду финансового учета. К сожалению,
финансовые отчетные периоды часто не совпадают со стандартными месяцами
григорианского календаря. Например, у компании может быть 13 4-недельных
отчетных периодов в финансовом году, который начинается 1 сентября, вместо
12 месячных периодов, начинающихся 1 января. Если вы имеете дело с одним
финансовым календарем, то каждый день в году соответствует одному календарному месяцу, а также одному финансовому отчетному периоду. Учитывая эти
взаимосвязи, календарные и отчетные периоды — просто иерархические атрибуты в измерении «Дата». Таблица измерения «Дата» будет одновременно соответствовать таблице измерений календарного месяца, а также таблице измерений
финансового отчетного периода.
В других ситуациях вы можете иметь дело с несколькими календарями финансовой отчетности, которые различаются в зависимости от дочерней компании или направления деятельности. Если количество уникальных финансовых
календарей — фиксированное небольшое число, то вы можете включить каждый
набор атрибутов финансового календаря с уникальными метками в одно измерение «Дата». Эта строка в измерении «Дата» будет идентифицирована как
относящаяся к отчетному периоду 1 для дочерней компании A, но к отчетному
периоду 7 для дочерней компании B.
В более сложной ситуации с большим количеством различных финансовых
календарей вы можете определить официальный корпоративный финансовый
календарь в измерении «Дата». Затем у вас есть несколько вариантов для работы
272
Глава 7
финансовых календарей, специфичных для дочерних компаний. Наиболее распространенный подход заключается в создании выносного измерения «Дата»
с составным ключом, состоящим из даты и вспомогательных ключей. В этой
таблице будет по одной строке на каждый день для каждой дочерней компании.
Атрибуты в этом внешнем измерении будут состоять из финансовых группировок, таких как дата окончания финансовой недели и дата окончания финансового периода. Вам понадобится механизм для фильтрации данных по конкретным
дочерним компаниям в этом внешнем измерении. Выполнение этого с помощью
представления позволит представить выносное измерение так, как если бы оно
логически было частью таблицы измерения «Дата».
Второй подход к решению календарей, специфичных для дочерних компаний, заключается в создании отдельных физических измерений «Дата» для каждого дочернего календаря с использованием общего набора суррогатных ключей даты. Этот вариант, скорее всего, был бы использован, если бы фактические
данные были децентрализованы дочерними компаниями. В зависимости от возможностей инструмента BI может быть проще выполнить фильтрацию на вспомогательной выносном измерении, как описано в варианте 1, либо обеспечить
использование соответствующей таблицы физических измерений «Дата» для
конкретного подразделения (вариант 2). Наконец, вы можете выделить другой
внешний ключ в таблице фактов для дополнительной таблицы измерений за финансовый период. Количество строк в этой таблице будет равно количеству финансовых периодов (примерно 36 за 3 года), умноженному на количество уникальных календарей. Этот подход упрощает доступ пользователей, но создает
дополнительную нагрузку на систему ETL, поскольку в процессе преобразования необходимо вставить соответствующий ключ финансового периода.
Детализация по многоуровневой иерархии
Очень крупные предприятия или государственные учреждения могут иметь несколько бухгалтерских книг, расположенных в восходящей иерархии, возможно,
по предприятиям, подразделениям и департаментам. На самом низком уровне
записи книги отдела могут быть объединены для объединения в одну запись книги подразделения. Затем записи бухгалтерской книги подразделения могут быть
консолидированы на уровне предприятия. Это было бы особенно характерно для
периодических снимков зернистости этих бухгалтерских книг. Один из способов
моделирования этой иерархии — введение суррогатного ключа таблицы фактов
родительского снимка в таблицу фактов, как показано на рис. 7-4. В этом случае,
поскольку вы определяете связь «родитель — потомок» между строками, вы добавляете явный суррогатный ключ таблицы фактов, числовой одностолбцовый
идентификатор, увеличивающийся по мере добавления строк в таблицу фактов.
Бухгалтерский учет
273
Таблица фактов бухгалтерской книги
Измерение
«Отчетный период»
Измерение «Счет»
Суррогатный ключ таблицы фактов (PK)
Ключ периода отчетности (FK)
Ключ бухгалтерской книги (FK)
Ключ счета (FK)
Ключ организации (FK)
Ключ родительского снимка (снапшота) (FK)
Остаток на балансе на конец периода
Дебит периода
Сумма кредита периода
Чистое изменение в сумме за период
Измерение
«Бухгалтерская книга»
Измерение
«Организация»
Рис. 7-4. Пример детализации по нескольким бухгалтерским книгам
Вы можете использовать суррогатный ключ родительского снимка для детализации в вашей многослойной Главной книге. Предположим, что вы обнаружили большую сумму «Поездки» на верхнем уровне бухгалтерской книги. Вы
берете суррогатный ключ для этой записи высокого уровня, а затем извлекаете
все записи, чей родительский ключ равен этому ключу. Это открывает записи
на следующем более низком уровне, которые вносят вклад в исходную запись
высокого уровня, представляющую интерес. SQL будет выглядеть примерно
так:
Select * from GL_Fact where Parent_Snapshot_key =
(select fact_table_surrogate_key from GL_Fact f, Account a
where <joins> and a.Account = 'Travel' and f.Amount > 1000)
Финансовые отчеты
Одна из основных функций системы Главной бухгалтерской книги — подготовка
официальных финансовых отчетов организации, таких как бухгалтерский баланс
и отчет о прибылях и убытках. Операционная система обычно подготавливает
эти отчеты. Нежелательно, чтобы система DW/BI попытается заменить отчеты,
опубликованные операционными финансовыми системами.
Однако группы DW/BI иногда создают дополнительные агрегированные
данные, которые обеспечивают упрощенный доступ к информации отчета, которая может быть более широко распространена по всей организации. Атрибуты
в схеме финансовой отчетности будут включать отчетный период и статьи расходов. Вместо того чтобы просматривать данные на уровне счетов Главной книги,
фактические данные будут агрегированы и помечены соответствующим номером
строки финансовой отчетности и меткой. Таким образом, менеджеры смогут
легко просматривать тенденции производительности для конкретной строки
финансового отчета с течением времени для своей организации. Аналогичным
274
Глава 7
образом ключевые показатели эффективности и финансовые коэффициенты могут быть доступны на том же уровне детализации.
Процесс составления бюджета
Большинство современных систем Главной бухгалтерской книги включают возможность интеграции бюджетных данных в Главную книгу. Однако, если в ГК
отсутствует эта возможность либо она не была реализована, вам необходимо
предоставить альтернативный механизм для поддержки составления бюджета
и сопоставления отклонений.
В большинстве организаций составление бюджета можно рассматривать как
серию событий. Перед началом финансового года каждый менеджер по закупкам
обычно создает бюджет с разбивкой по статьям бюджета, который затем утверждается. На самом деле составление бюджета редко бывает просто мероприятием раз в год. Бюджеты становятся более динамичными, поскольку в течение
года в них вносятся корректировки, отражающие изменения в условиях ведения бизнеса или реалии фактических расходов по сравнению с первоначальным
бюджетом. Менеджеры хотят видеть текущее состояние бюджета, а также то, как
бюджет был изменен с момента первой утвержденной версии. По мере развития
года принимаются обязательства по расходованию предусмотренных в бюджете
средств. Наконец, платежи обрабатываются.
Как разработчик размерного моделирования вы можете просматривать цепочку составления бюджета в виде серии таблиц фактов, как показано на рис. 7-5.
Эта цепочка состоит из таблицы фактов бюджета, таблицы фактов обязательств
и таблицы фактов платежей, где существует логический поток, который начинается с определения бюджета для каждой организации и каждого счета. Затем
в течение операционного периода принимаются обязательства по бюджетам
и, наконец, производятся платежи по этим обязательствам.
Мы начнем с таблицы бюджетных фактов. Для статьи бюджета расходов каждая строка определяет, сколько организации в компании разрешено тратить в течение определенного периода и на какие цели. Аналогично, если позиция отражает прогноз доходов, который является просто еще одним вариантом бюджета,
в нем будет указано, сколько организация намеревается заработать и из какого
источника в течение определенного периода.
Вы могли бы дополнительно определить зернистость как текущее состояние
каждой позиции в каждом бюджете каждый месяц. Хотя это и будет выглядеть
привычно (потому что оно похоже на отчет руководства), это плохой выбор в качестве зернистости для таблицы фактов. Факты в таком «отчете о состоянии»
представляют собой все полуаддитивные балансы, а не полностью аддитивные
Бухгалтерский учет
275
факты. Кроме того, такая выборка затрудняет определение того, насколько сильные произошли изменения с предыдущего месяца или квартала, потому что вы
должны получить строки из нескольких периодов времени, а затем вычесть их
друг из друга. Наконец, эта выборка потребует, чтобы таблица фактов содержала
много повторяющихся строк, если в последующие месяцы для данной позиции
ничего не меняется.
Таблица фактов бюджета
Измерение «Месяц»
Измерение «Счет»
Измерение «Месяц»
Измерение «Счет»
Измерение «Обязательство»
Ключ обязательств (PK)
Описание обязательств
Сторона обязательств
Измерение «Месяц»
Измерение «Счет»
Измерение «Обязательство»
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Сумма в бюджете
Таблица фактов
обязательств
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Ключ обязательств (FK)
Сумма по обязательствам
Таблица фактов
платежей
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Ключ обязательств (FK)
Ключ платежа (FK)
Сумма платежа
Измерение «Организация»
Измерение «Бюджет»
Ключ бюджета (PK)
Название бюджета
Версия бюджета
Дата утверждения бюджета
Измерение «Организация»
Измерение «Бюджет»
Измерение «Организация»
Измерение «Бюджет»
Измерение «Платеж»
Ключ платежа (PK)
Описание платежа
Сторона платежа
Рис. 7-5. Цепочка бюджетных процессов
На самом деле зернистость, которая вам нужна, — это чистые изменения
в бюджетах на конкретные статьи затрат, произошедшее в течение месяца. Хотя
этого достаточно для целей бюджетной отчетности, бухгалтерам в итоге необходимо привязать статью бюджета к конкретному затронутому счету Главной книги, поэтому вы также перейдете на уровень подсчета ГК.
276
Глава 7
Учитывая вышесказанное, соответствующие измерения бюджета будут включать месяц вступления в силу, статьи расходов организации, бюджетную статью
и бухгалтерский счет, как показано на рис. 7-6. «Организация» идентична измерению, использованному ранее с данными Главной книги. Измерение «Счет»
также уже использовалось. Единственная сложность, связанная с измерением
«Счет», заключается в том, что иногда одна бюджетная статья влияет более чем
на один финансовый счет. В этом случае вам необходимо будет распределить бюджетную строку по отдельным счетам ГК. Поскольку структура таблицы бюджетных фактов относится к бухгалтерскому учету, одна строка бюджета для статьи
расходов может быть представлена в виде нескольких строк в таблице фактов.
Измерение
«Дата вступления в силу»
Ключ эффективной даты
бюджета (PK)
Месяц эффективной даты
бюджета
Год эффективной даты
бюджета
…
Измерение «Счет»
Таблица фактов бюджета
Измерение «Статья бюджета»
Ключ эффективной даты
бюджета (FK)
Ключ бюджетной статьи (FK)
Ключ счета (FK)
Ключ организации (FK)
Сумма в бюджете
Ключ бюджетной статьи (PK)
Название бюджета
Версия бюджета
Описание статьи бюджета
Год бюджета
Описание подкатегории статьи
бюджета
Описание категории статьи
бюджета
Измерение «Организация»
Рис. 7-6. Схема бюджета
Статья бюджета определяет цель предлагаемых расходов, таких как заработная плата сотрудников или служебные принадлежности. Обычно существует
несколько уровней категорий обобщения, связанных с бюджетной статьей. Все
статьи бюджета могут иметь разное количество уровней в иерархии обобщения,
например, когда у некоторых есть только сводная категория, но нет подкатегории. В этом случае вы можете заполнить атрибуты измерения, повторив название
категории в столбце подкатегории, чтобы избежать свертывания позиций в подкатегорию «Неприменимо». В измерении «Бюджетная статья» также будет
указан бюджетный год и/или версия бюджета.
Месяц вступления в силу — это месяц, в течение которого публикуются изменения бюджета. Первые записи за данный бюджетный год будут показывать
фактический месяц, когда бюджет будет впервые утвержден. Если бюджет обновляется или изменяется по мере начала бюджетного года, то месяцы вступления
в силу будут приходиться на бюджетный год. Если вы не корректируете бюджет
в течение года, то единственными записями будут первые, когда бюджет будет
Бухгалтерский учет
277
первоначально утвержден. Это то, что имеется в виду, когда зернистость определена как чистый прирост. Очень важно, чтобы вы осознали этот момент, иначе вы
не поймете содержания таблицы бюджетных фактов и способов ее использования.
Иногда бюджеты составляются в виде годовых планов расходов; в других случаях они разбиты по месяцам или кварталам. На рис. 7-6 предполагается, что
бюджет представляет собой годовую сумму, при этом бюджетный год указан
в измерении «Бюджетная статья». Если вам нужно выразить данные бюджета по месяцам расходов, вам потребуется включить вторую таблицу измерения
«Месяц», которая играет роль месяца расходов.
Таблица фактов бюджета содержит один факт суммы бюджета, он полностью
аддитивный. Если вы составляете бюджет для многонациональной организации,
сумма бюджета может быть помечена ожидаемым коэффициентом пересчета валют для целей планирования. Если сумма бюджета для этой бюджетной строки
и счета изменяется в течение года, в таблицу бюджетных фактов добавляется дополнительная строка, представляющая чистое изменение (net change). Например, если первоначальный бюджет составлял 200 000 долларов, у вас может быть
еще одна строка в июне для увеличения на 40 000 долларов, а затем еще одна в октябре для отрицательных 25 000 долларов, когда вы затянете пояс в конце года.
Когда начинается бюджетный год, менеджеры берут на себя обязательства
расходовать бюджет с помощью заказов на закупку, заказов на выполнение работ
или других форм контрактов. Менеджеры остро заинтересованы в мониторинге
своих обязательств и сравнении их с годовым бюджетом для управления своими
расходами. Мы можем представить себе вторую таблицу фактов для обязательств
(см. рис. 7-5), которая содержит те же измерения в дополнение к измерениям,
определяющим конкретный документ об обязательствах (заказ на поставку, заказ на выполнение работ или контракт) и сторону, принимающую обязательства.
В этом случае фактом будет зафиксированная сумма.
Наконец, платежи производятся по мере перечисления средств стороне, указанной в обязательстве. С практической точки зрения, когда обязательство принято, денег в бюджете больше нет. Но финансовый отдел заинтересован во взаимосвязи между обязательствами и платежами, поскольку он управляет средствами
компании. Параметры, связанные с таблицей фактов платежей, будут включать измерения таблицы фактов обязательств, параметр платежей для определения типа
платежа, а также получателя платежа, которому фактически он был произведен.
В соответствии с бюджетной цепочкой, показанной на рис. 7-5, список измерений
расширяется по мере перехода от бюджета к обязательствам по платежам.
С помощью этого дизайна вы можете создать ряд интересных разработок.
Чтобы просмотреть текущую бюджетную сумму по отделам и позициям, вы можете ограничить все даты до настоящего времени, добавив суммы по отделам
278
Глава 7
и позициям. Поскольку главное — это чистые изменения позиций, суммирование всех записей с течением времени делает совершенно правильные вещи.
В итоге вы получаете текущую утвержденную сумму бюджета и именно те позиции в данных отделах, у которых есть бюджет.
Чтобы запросить все изменения в бюджете по различным статьям, просто
ограничьтесь одним месяцем. Вы получите данные только о тех позициях, в которых произошли изменения в течение месяца.
Чтобы сравнить текущие обязательства с текущим бюджетом, отдельно сложите суммы обязательств и суммы бюджета с начала времени до текущей даты (или
любой интересующей даты). Затем объедините два набора ответов в заголовках
строк. Это стандартная горизонтальная детализация (drill-across), использующее
многопроходный SQL. Аналогичным образом вы могли бы детализировать обязательства и платежи.
Иерархии атрибутов измерений
Хотя вариант использования бюджетной цепочки, описанный в этой главе, достаточно прост, он содержит ряд иерархий, а также ряд вариантов для разработчика. Помните, что иерархия определяется рядом отношений «многие к одному».
Скорее всего, у вас есть по крайней мере четыре иерархии: уровни календаря,
уровни счетов, географические уровни и уровни организации.
Позиционные иерархии с фиксированной глубиной
В бюджетной цепочке уровни календаря представляют собой знакомые фиксированные по глубине позиционные иерархии. Как следует из названия, иерархия
фиксированных позиций имеет фиксированный набор уровней, все со значимыми метками. Думайте об этих уровнях как о свертках (roll-up). Одной календарной иерархией может быть «день ➪ финансовый период ➪ год». Другим
может быть «день ➪ месяц ➪ год». Эти две иерархии могут отличаться, если
нет простой взаимосвязи между финансовыми периодами и месяцами. Например, в некоторых организациях существуют финансовые периоды 5–4–4, когда
за 5-недельным периодом следуют два 4-недельных. Одно измерение «Календарная дата» может удобно представлять эти две иерархии одновременно в наборах
параллельных атрибутов, поскольку зернистость измерения «Дата» — отдельный день.
Измерение «Счет» также может иметь фиксированную иерархию «многие
к одному», такую как счета исполнительного уровня, уровня директора и уровня
менеджера. Основой измерения — счет уровня менеджера, но подробные счета
на самом низком уровне сводятся к уровням директора и руководителя.
Бухгалтерский учет
279
В иерархии с фиксированной позицией важно, чтобы каждый уровень имел
определенное имя. Таким образом, бизнес-пользователь знает, как ограничить
и интерпретировать каждый уровень.
Избегайте фиксированных позиционных иерархий
с абстрактными названиями, такими как «Уровень 1», «Уровень 2» и так далее. Это простой способ избежать правильного моделирования прерывающейся
иерархии. Когда уровни имеют абстрактные имена, бизнес-пользователь не может знать, как применить ограничение или что означают в отчете значения атрибутов на этих уровнях. Если иерархия с пропущенными уровнями пытается
спрятаться в иерархии фиксированных позиций с абстрактными именами, отдельные уровни, по сути, бессмысленны.
ПРЕДУПРЕЖДЕНИЕ
Простое
местоположение
Ключ местоположения (PK)
Среднее
местоположение
Ключ местоположения (PK)
Сложное
местоположение
Ключ местоположения (PK)
Адрес+
Адрес+
Адрес+
Город
Город
Город
Город
Город
Район
Город
Зона
Область
Штат
Штат
Штат
Страна
Страна
Страна
...
...
...
Рис. 7-7. Значения выборочных данных существуют одновременно в одном
измерении местоположения, содержащем простые, промежуточные
и сложные иерархии
Прерывающиеся иерархии переменной глубины
Географические иерархии представляют интересную проблему. На рис. 7-7 показаны три возможности. Простое местоположение имеет четыре уровня: адрес,
город, штат и страна. Местоположение средней сложности добавляет уровень
зоны, а местоположение комплекса добавляет уровни района и зоны. Если вам
нужно представить все три типа местоположений в единой географической
иерархии, у вас есть иерархия переменной глубины. Вы можете комбинировать
все три типа, если готовы пойти на компромисс. Для среднего местоположения,
в котором отсутствует понятие района, вы можете перенести название города
в атрибут района. Для простого местоположения, в котором нет понятия района или зоны, вы можете распространить название города на оба этих атрибута.
Глава 7
280
Бизнес-представителя отдела управления данными могут вместо этого принять
решение о распространении меток вверх или даже заполнить пустые уровни надписью «Неприменимо». Представителям бизнеса необходимо визуализировать
соответствующие значения меток строк в отчете, если атрибут сгруппирован.
Независимо от применяемых бизнес-правил у вас есть преимущество в четком
позиционном дизайне с именами атрибутов, которые имеют разумный смысл
во всех трех географических регионах. Ключ к этому компромиссу — узкий диапазон географических иерархий, варьирующийся от четырех до шести уровней.
Если бы данные варьировались от четырех уровней до восьми, десяти или даже
больше, этот компромисс не сработал бы. Помните, что имена атрибутов должны
иметь смысл.
Прерывающиеся иерархии переменной глубины
В случае использования бюджета организационная структура — отличный пример прерывающейся иерархии неопределенной глубины. В этой главе мы часто
называем иерархическую структуру «деревом», а отдельные организации в этом
дереве — «узлами». Представьте, что ваше предприятие состоит из 13 организаций со сводной структурой, показанной на рис. 7-8. Каждая из этих организаций
имеет собственный бюджет, обязательства и платежи.
1
2
3
7
4
5
8
6
9
13
10
11
12
Рис. 7-8. Сводная структура организации
Для отдельной организации вы можете запросить конкретный бюджет для
счета с помощью простой операции соединения таблицы измерений с таблицей
фактов организации, как показано на рис. 7-9. Но вы также хотите распределить
бюджет по частям дерева или даже по всему дереву. Рис. 7-9 не содержит информации об организационном накоплении.
Бухгалтерский учет
Измерение «Организация»
Ключ организации (PK)
Наименование организации
...
281
Таблица фактов бухгалтерской книги
Ключ даты внесения записи (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ транзакции (FK)
Ключ бухгалтерской книги (FK)
ID транзакции (DD)
Сумма
Баланс
Рис. 7-9. Измерения, присоединенные к таблице фактов
Классический способ представления древовидной структуры «родитель —
потомок» заключается в размещении рекурсивных указателей в измерении «Организация» от каждой строки к ее родителю, как показано на рис. 7-10. Первоначальное определение SQL не предусматривало способа оценки этих рекурсивных
указателей. Oracle реализовала функцию CONNECT BY, которая обходила эти
указатели в нисходящем порядке начиная с родительского узла высокого уровня
в дереве и постепенно перечисляла все дочерние узлы на более низких уровнях,
пока дерево не было исчерпано. Но проблема с Oracle CONNECT BY и другими
более общими подходами, такими как рекурсивные общие табличные выражения
SQL Server, заключается в том, что представление дерева связано с атрибутами организации, поскольку эти подходы зависят от рекурсивного указателя, встроенного
в данные. Нецелесообразно переключаться с одной структуры свертки на другую,
поскольку многие рекурсивные указатели должны быть деструктивно изменены.
Также нецелесообразно поддерживать организации в качестве медленно изменяющихся атрибутов измерения типа 2, поскольку изменение ключа для узла высокого
уровня приведет к изменению ключевых изменений в нижней части дерева.
Измерение «Организация»
Рекурсивный
указатель
Ключ организации (PK)
Наименование организации
…
Ключ родительской организации (FK)
Рис. 7-10. Классический рекурсивный пример дизайна «родитель — потомок»
Решение проблемы представления произвольных структур свертки состоит
в создании особого вида соединительной таблицы, которая не зависит от таблицы первичных измерений и содержит всю информацию о свертке. Зернистость
этой соединительной таблицы — каждый путь в дереве от родителя ко всем
282
Глава 7
дочерним элементам ниже этого родителя, как показано на рис. 7-11. Первый
столбец в соединительной таблице — первичный ключ родительского элемента,
а второй столбец — первичный ключ дочернего элемента. Строка должна быть
построена от каждого возможного родителя к каждому возможному потомку,
включая строку, которая соединяет родителя с самим собой.
Примеры строк соединительной таблицы
связей организаций для рис. 7-8:
Соединительная
таблица организаций
Ключ родительской
организации (FK)
Ключ дочерней
организации (FK)
Глубина от родителя
Флаг самой верхней
организации
Флаг самой низкой
по иерархии организации
Флаг
Ключ
Ключ
самой
родительской
дочерней
Глубина
верхней
организации организации от родителя организации
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
3
4
4
4
5
6
7
7
7
7
7
7
7
8
9
9
9
9
9
10
10
10
11
12
13
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
3
4
5
6
5
6
7
8
9
10
11
12
13
8
9
10
11
12
13
10
11
12
11
12
13
0
1
2
2
3
3
1
2
2
3
4
4
3
0
1
1
2
2
0
0
1
1
0
0
0
1
1
2
3
3
2
0
0
1
2
2
1
0
1
1
0
0
0
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
ЛОЖЬ
Флаг
самой
низкой
по иерархии
организации
ЛОЖЬ
ЛОЖЬ
ИСТИНА
ЛОЖЬ
ИСТИНА
ИСТИНА
ЛОЖЬ
ИСТИНА
ЛОЖЬ
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ИСТИНА
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ИСТИНА
ЛОЖЬ
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ЛОЖЬ
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
ИСТИНА
Рис. 7-11. Примеры строк соединительной таблицы связей организаций
Бухгалтерский учет
283
Пример дерева, изображенный на рис. 7-8, приводит к 43 строкам на рис. 7-11.
Существует 13 путей от узла № 1, 5 путей от узла № 2, один путь от узла № 3 к самому себе и так далее.
Самый высокий родительский флаг в соединительной таблице означает, что
конкретный путь исходит от главного родителя в дереве. Самый низкий дочерний флаг означает, что конкретный путь заканчивается в «листовом узле» дерева.
Измерение
«Организация»
Соединительная таблица
организаций
Таблица фактов
бухгалтерской книги
Ключ организации (PK)
Наименование организации
...
Ключ родительской
организации (FK)
Ключ дочерней
организации (FK)
Глубина от родителя
Флаг самой верхней
организации
Флаг самой низкой
по иерархии организации
Ключ даты внесения
записи (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ профиля
транзакции (FK)
Ключ версии бухгалтерской
книги (FK)
ID транзакции (DD)
Сумма
Баланс
Рис. 7-12. Присоединение соединительной таблицы организации
к таблице фактов
Если вы ограничите таблицу измерения «Организация» одной строкой, вы
можете соединить таблицу измерений с соединительной таблицей и далее с таблицей фактов, как показано на рис. 7-12. Например, если вы ограничите таблицу
организации узлом номер 1 и просто извлечете дополнительный факт из таблицы
фактов, вы получите 13 обращений к таблице фактов, которая проходит по всему дереву за один запрос. Если выполнить тот же запрос, ограничив значением
true флаг наименьшего дочернего элемента таблицы карт, то вы получите только
аддитивный факт из шести конечных узлов — чисел 3, 5, 6, 8, 10, и 11. Опять же,
этот ответ был вычислен без обхода дерева во время запроса!
ПРИМЕЧАНИЕ Обратите внимание на статью «Построение иерархических
соединительных таблиц» (доступна на сайте www.kimballgroup.com на вкладке
Tools and Utilities под названием этой книги), где приведен пример кода для построения иерархической соединительной таблицы, описанной в этом разделе.
Вы должны быть осторожны при использовании соединительной таблицы,
чтобы ограничить измерение «Организация» одной строкой, иначе вы рискуете просчитаться с количеством детей и внуков в дереве. Например, если вместо
284
Глава 7
ограничения, такого как «Номер организации узла = 1», вы ограничите «Местоположение организации узла = Калифорния», у вас возникнет эта проблема.
В этом случае вам необходимо создать пользовательский запрос, а не простое
соединение, со следующим ограничением:
GLfact.orgkey in (select distinct bridge.childkey
from innerorgdim, bridge
where innerorgdim.state = 'California' and
innerorgdim.orgkey = bridge.parentkey)
Совместный доступ при прерывающейся иерархии
Можно установить частичный или совместный доступ к таблице, как это показано на рис. 7-13. Например, предположим, что узел 10 на 50% принадлежит узлу
6 и на 50% принадлежит узлу 11. В этом случае любой бюджет, обязательство
или платеж, отнесенные к узлу 10, направляются вверх через узел 6 с 50-процентным взвешиванием, а также вверх через узел 11 с 50-процентным взвешиванием. Теперь вам нужно добавить дополнительные строки пути к исходным
43 строкам, чтобы обеспечить подключение узла 10 к узлу 6 и его родителям.
Все соответствующие строки пути, заканчивающиеся узлом 10, теперь требуют
50-процентного взвешивания в столбце процент владения в соединительной таблице. В других строках пути, не заканчивающихся на узле 10, столбец процента
владения не изменен.
Измерение
«Организация»
Соединительная
таблица организаций
Таблица фактов
бухгалтерской книги
Ключ организации (PK)
Наименование организации
...
Ключ родительской
организации (FK)
Ключ дочерней
организации (FK)
Глубина от родителя
Флаг самой верхней
организации
Флаг самой низкой
по иерархии организации
Процент владения
Ключ даты внесения
записи (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ профиля
транзакции (FK)
Ключ версии бухгалтерской
книги (FK)
ID транзакции (DD)
Сумма
Баланс
Рис. 7-13. Соединительная таблица для совместного доступа
при прерывающейся иерархии
Бухгалтерский учет
285
Неравномерная иерархия, изменяющаяся во времени
Соединительная таблица прерывающейся иерархии может отображать изменяющееся ранжирование с добавлением двух меток даты/времени, как показано
на рис. 7-14. Когда этот узел больше не является дочерним узлом другого узла,
дата/время вступления в силу окончания старой связи должны быть установлены на дату/время изменения, а новые строки пути вставлены в соединительную
таблицу с правильной датой/временем вступления в силу.
Измерение
«Организация»
Соединительная
таблица организаций
Таблица фактов
бухгалтерской книги
Ключ организации (PK)
Наименование организации
...
Ключ родительской
организации (FK)
Ключ дочерней
организации (FK)
Глубина от родителя
Флаг самой верхней
организации
Флаг самой низкой
по иерархии организации
Дата/время вступления
в силу
Дата/время окончания
действительности строки
Ключ даты внесения
записи (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ профиля
транзакции (FK)
Ключ версии бухгалтерской
книги (FK)
ID транзакции (DD)
Сумма
Баланс
Рис. 7-14. Соединительная таблица для изменяющихся во времени
неравномерных иерархий
При использовании соединительной таблицы
на рис. 7-14 запрос всегда должен ограничиваться одной датой/временем, чтобы
«заморозить» соединительную таблицу до единого согласованного представления иерархии. Неспособность ограничить таким образом в противном случае
приведет к тому, что будет выбрано несколько путей, которые не могут существовать одновременно.
ПРЕДУПРЕЖДЕНИЕ
Изменение прерывающихся иерархий
Соединительная таблица организации может быть легко изменена. Предположим, вы хотите переместить узлы 4, 5 и 6 из их исходного отчета о местоположении до узла 2 в новый отчет о местоположении до узла 9, как показано
на рис. 7-15. В статическом случае, когда соединительная таблица отражает только текущую структуру свертки, вы просто удаляете пути более высокого уровня
Глава 7
286
в дереве, указывающие на группу узлов 4, 5 и 6. Затем вы присоединяете узлы 4,
5 и 6 к родительским узлам 1, 7 и 9. Вот статический SQL:
Delete from Org_Map where child_org in (4, 5,6) and
parent_org not in (4,5,6)
Insert into Org_Map (parent_org, child_org)
select parent_org, 4 from Org_Map where parent_org in (1, 7, 9)
Insert into Org_Map (parent_org, child_org)
select parent_org, 5 from Org_Map where parent_org in (1, 7, 9)
Insert into Org_Map (parent_org, child_org)
select parent_org, 6 from Org_Map where parent_org in (1, 7, 9)
1
2
3
7
8
9
13
10
11
12
4
5
6
Рис. 7-15. Изменения в организационной структуре рис. 7-8
В случае изменения времени, когда соединительная таблица содержит пару
меток даты/времени, логика аналогична. Вы можете найти пути более высокого
уровня в дереве, указывающие на группу узлов 4, 5 и 6, и установить их конечную
дату вступления в силу либо время на момент изменения. Затем вы присоединяете узлы 4, 5 и 6 к родительским узлам 1, 7 и 9 с соответствующей датой/временем.
Вот изменяющийся во времени SQL:
Update Org_Map set end_eff_date = #December 31, 2012#
where child_org in (4, 5,6) and parent_org not in (4,5,6)
and #Jan 1, 2013# between begin_eff_date and end_eff_date
Insert into Org_Map
(parent_org, child_org, begin_eff_date, end_eff_date)
values (1, 4, #Jan 1, 2013#, #Dec 31, 9999#)
Бухгалтерский учет
287
Insert into Org_Map
(parent_org, child_org, begin_eff_date, end_eff_date)
values (7, 4, #Jan 1, 2013#, #Dec 31, 9999#)
Insert into Org_Map
(parent_org, child_org, begin_eff_date, end_eff_date)
values (9, 4, #Jan 1, 2013#, #Dec 31, 9999#)
Identical insert statements for nodes 5 and 6 …
Этот простой способ изменения соединительной таблицы позволяет избежать кошмарных сценариев при изменении других типов иерархических моделей. В соединительной таблице затрагиваются только пути, непосредственно
участвующие в изменении. Все остальные пути нетронуты. В большинстве других схем с умными метками узлов изменение древовидной структуры может повлиять на многие или даже все узлы дерева, как показано в следующем разделе.
Альтернативные подходы к моделированию
прерывающейся иерархии
В дополнение к использованию рекурсивных указателей в измерении «Организация» существует по крайней мере два других способа моделирования
прерывающейся иерархии, оба с использованием интеллектуальных столбцов,
размещенных в измерении «Организация». У этих схем есть два недостатка
по сравнению с подходом соединительной таблицы. Во-первых, определение
иерархии привязано к измерению и не может быть легко заменено. Во-вторых,
обе эти схемы уязвимы для катастрофических случаев с повторной маркировкой,
при которой большая часть дерева должна быть повторно помечена из-за одного
небольшого изменения. Учебники, подобные этому, обычно показывают крошечный пример, но вам нужно действовать осторожно, если в вашем дереве тысячи
узлов.
Одна схема добавляет атрибут строки пути в таблицу измерения «Организация», как показано на рис. 7-16. Значения атрибута pathstring отображаются внутри каждого узла. В этом сценарии нет соединительной таблицы.
На каждом уровне строка пути начинается с полной строки пути родителя, а затем добавляет буквы A, B, C и так далее слева направо под этим родителем. Последний символ «+», если у узла есть дочерние элементы, и точка, если у узла нет
дочерних элементов. По дереву можно перемещаться, используя подстановочные
знаки в ограничениях для строки пути, например:
■ A* извлекает все дерево, где звездочка — подстановочный знак переменной длины;
Глава 7
288
■ *. извлекает только конечные узлы;
■ ?+ извлекает самый верхний узел, где знак вопроса представляет собой односимвольный подстановочный знак.
A+
AA+
AAA.
AB+
AAB+
AABA.
ABA.
AABB.
ABB+
ABBA+
ABBAA.
ABBB.
ABBAB.
Рис. 7-16. Альтернативный дизайн прерывающейся
иерархии с использованием атрибута строки пути
Подход pathstring довольно чувствителен к неточностям и нововведениям при повторной маркировке, вызванной изменениями в организации; если
где-то в дереве вставлен новый узел, все узлы справа от этого узла под одним
и тем же родителем должны быть повторно помечены.
1,26
2,11
3,4
12,25
5,10
6,7
13,14
8,9
15,24
16,21
17,18
22,23
19,20
Рис. 7-17. Альтернативный дизайн неравномерной
иерархии с использованием модифицированного
подхода в обход дерева предварительных заказов
Бухгалтерский учет
289
Другая аналогичная схема, известная компьютерным ученым как модифицированный подход обработки предварительно упорядоченного дерева, нумерует дерево, как показано на рис. 7-17. У каждого узла есть пара чисел, которые
идентифицируют все узлы ниже этой точки. Все дерево можно перечислить, используя номера узлов в самом верхнем узле. Если значения в каждом узле имеют
имена слева и справа, то все узлы в дереве примеров можно найти с ограничением «Слева от 1 до 26». Конечные узлы можно найти там, где слева и справа отличаются на 1, что означает, что дочерних элементов нет. Этот подход еще более
уязвим для неточностей с повторной маркировкой, чем подход с использованием строки пути, поскольку все дерево должно быть тщательно пронумеровано
в последовательности сверху вниз и слева направо. Любое изменение дерева приводит к тому, что вся остальная часть дерева справа будет помечена заново.
Преимущества подхода с соединительной таблицей
для неравномерных иерархий
Хотя соединительная таблица требует больше работы по настройке ETL и больше работы при выполнении запросов, она обеспечивает исключительную гибкость для анализа неравномерных иерархий неопределенной глубины. В частности, соединительная таблица позволяет реализовать:
■ альтернативные структуры свертывания данных, которые будут выбраны
во время запроса;
■ свертки совместного доступа;
■ изменяющиеся во времени неравномерные иерархии;
■ ограниченное воздействие, когда узлы подвергаются изменениям типа 2
с медленно меняющимися параметрами (SCD);
■ ограниченное воздействие при изменении древовидной структуры.
Вы можете использовать соединительную таблицу иерархии организации для
извлечения факта из всех трех таблиц фактов в бюджетной цепочке. На рис. 7-18
показано, как соединительная таблица может подключаться к трем таблицам фактов бюджетной цепочки. Это позволило бы составить подробный отчет, например, найти все бюджеты поездок, обязательства и платежи, произведенные всеми
нижними конечными узлами в сложной организационной структуре.
290
Глава 7
Таблица
фактов бюджета
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Сумма в бюджете
Измерение
«Организация»
Таблица
фактов обязательств
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Ключ обязательств (FK)
Сумма по обязательствам
Измерение
«Организация»
Соединительная
таблица организаций
Измерение
«Организация»
Ключ родительской
организации (FK)
Ключ дочерней
организации (FK)
Глубина от родителя
Флаг самой верхней
организации
Флаг самой низкой
по иерархии организации
Ключ организации
Номер учетного центра
Наименования учетного
центра
...
Таблица
фактов платежей
Ключ месяца (FK)
Ключ организации (FK)
Ключ счета (FK)
Ключ бюджета (FK)
Ключ обязательств (FK)
Ключ платежа (FK)
Сумма платежа
Измерение
«Организация»
Рис. 7-18. Детализация и свертывание цепочки бюджета
Консолидированные таблицы фактов
В последнем разделе мы обсуждали сравнение показателей, генерируемых отдельными бизнес-процессами, путем детализации таблиц фактов, таких как бюджет и обязательства. Если этот тип детального анализа чрезвычайно распространен в сообществе пользователей, вероятно, имеет смысл создать единую таблицу
фактов, которая объединяет показатели один раз, вместо того чтобы полагаться
на бизнес-пользователей или их приложения для создания отчетов BI для объединения наборов результатов, особенно с учетом присущих им проблем, связанных со сложностью, точностью, возможностями инструмента, и производительностью.
Чаще всего бизнес-менеджеры заинтересованы в сравнении фактических
отклонений от бюджета. На этом этапе вы можете предположить, что годовые
бюджеты и/или прогнозы были разбиты по отчетным периодам. На рис. 7-19
показаны фактические и бюджетные суммы, а также разница (которая является
расчетной разницей) по общим параметрам.
Бухгалтерский учет
291
Таблица фактов
отклонения от бюджета
Измерение «Отчетный период»
Измерение «Организация»
Ключ периода отчетности (FK)
Ключ счета (FK)
Ключ организации (FK)
Фактическая сумма за отчетный
период
Сумма в бюджете за отчетный
период
Изменение суммы за отчетный
период
Измерение «Счет»
Рис. 7-19. Сводная таблица фактических данных по сравнению с бюджетом
Опять же, в многонациональной организации вы, скорее всего, увидите фактические суммы как в местной, так и в эквивалентной стандартной валюте исходя из действующего курса конвертации. Кроме того, вы можете конвертировать
фактические результаты на основе запланированного коэффициента пересчета
валют. Учитывая непредсказуемый характер колебаний валютных курсов, полезно отслеживать производительность на основе как эффективных, так и запланированных курсов конвертации. Таким образом, удаленные менеджеры не наказываются за изменения валютного курса вне их контроля. Аналогичным образом
финансовые учреждения могут лучше понять общую картину влияния неожиданных колебаний конвертации валют на годовой план организации.
Таблицы фактов, которые объединяют показатели из нескольких бизнеспроцессов с общей степенью детализации, называются консолидированными
таблицами фактов. Хотя консолидированные таблицы фактов могут быть полезны как с точки зрения производительности, так и с точки зрения удобства
использования, они часто представляют собой компромисс в отношении размерности, поскольку объединяют факты по «наименьшему общему знаменателю» размерности. Один из потенциальных рисков, связанных с консолидированными таблицами фактов, заключается в том, что проектные группы иногда
основывают проекты исключительно на детализации консолидированной таблицы, не удовлетворяя при этом требованиям пользователей, которые требуют
возможности углубляться в более детальные данные. Эти схемы сталкиваются
с серьезными проблемами, если проектные группы пытаются добиться однозначного соответствия для объединения данных с разной степенью детализации или
размерности.
ПРИМЕЧАНИЕ Когда факты из нескольких бизнес-процессов объединяют-
ся в консолидированную таблицу фактов, они должны соответствовать одному
и тому же уровню детализации и размерности. Поскольку отдельные факты
292
Глава 7
редко естественным образом совпадают с обычной зернистостью, вы вынуждены исключать или объединять некоторые измерения для поддержки однозначного соответствия, сохраняя при этом атомарные данные в отдельных таблицах фактов. Проектные группы не должны создавать искусственные факты или измерения
в попытке принудительно объединить разнородные фактические данные.
Роль OLAP и комплексных
аналитических решений
Обсуждая финансовые размерные модели в контексте реляционных баз данных,
стоит отметить, что поставщики размерных OLAP уже давно играют определенную роль в этой области. Продукты OLAP широко используются для приложений финансовой отчетности, составления бюджета и консолидации. Реляционные размерные модели часто служат основой для финансовых кубов OLAP.
Кубы OLAP могут обеспечить высокую производительность запросов, что имеет
решающее значение для использования управленцами. Объемы данных, особенно для балансов Главной книги или агрегированных финансовых отчетов, обычно не превышают практических ограничений по размеру размерного продукта.
OLAP хорошо подходит для обработки сложных организационных сводных данных, а также сложных вычислений, включая манипуляции между строками. Большинство поставщиков OLAP предоставляют финансовые возможности, такие
как финансовые функции (например, чистая приведенная стоимость или совокупный рост), надлежащая обработка данных финансовой отчетности (в ожидаемом последовательном порядке, например, доходы до расходов) и надлежащая
обработка дебетов и кредитов в зависимости от типа счета, а также более продвинутые функции, такие как финансовая консолидация. Кубы OLAP часто также легко поддерживают сложные модели безопасности, такие как ограничение
доступа к подробным данным, обеспечивая при этом более открытый доступ
к сводным показателям.
Учитывая стандартный характер обработки Главной книги, покупка пакета
программного обеспечения Главной книги, а не попытка создать его с нуля, была
популярным способом в течение многих лет. Почти все операционные пакеты
также предлагают дополнительное аналитическое решение, иногда в партнерстве
с поставщиком OLAP. Во многих случаях спланированные решения, основанные на накопленном опыте поставщика, — надежный способ быстро запустить
финансовое внедрение DW/BI с потенциально сниженными затратами и рисками. Аналитические решения часто содержат инструменты для извлечения и обработки оперативных данных, а также инструменты для анализа и интерпретации. Однако при использовании комплексных решений необходимо соблюдать
Бухгалтерский учет
293
осторожность, чтобы избежать внедрения узкоспециализированных решений.
Вы можете легко получить отдельные аналитические решения в области финансов, CRM, управления персоналом и ERP от множества разных поставщиков,
ни одно из которых не интегрируется с внутренними данными других. Вам необходимо согласовать измерения во всей среде DW/BI независимо от того, создаете ли вы решение или внедряете пакеты программного обеспечения. Комплексные аналитические решения могут ускорить реализацию DW/BI; однако
они не устраняют необходимость в согласовании измерений. Большинство организаций неизбежно полагаются на комбинацию создания, покупки и интеграции
программных продуктов для получения комплексного решения.
Выводы
В этой главе мы сосредоточились главным образом на финансовых данных в Главной бухгалтерской книге как с точки зрения периодических снимков, так и с точки зрения операций записи в журнале. Мы обсудили решение общих проблем
с данными ГК, включая операции с разными валютами, наличие нескольких финансовых календарей, несбалансированные организационные структуры и необходимость вычисления значений «с начала периода и до сегодняшнего дня».
Мы использовали знакомую сводную структуру организации, чтобы показать,
как моделировать сложные неравномерные иерархии неопределенной глубины.
Мы ввели специальную соединительную для этих иерархий и сравнили этот подход с другими.
Мы исследовали серию событий в цепочке процессов составления бюджета.
Мы описали использование детализации «чистого изменения» в этой ситуации
вместо создания моментальных снимков итоговых данных бюджета. Мы также
обсудили концепцию консолидированных таблиц фактов, которые объединяют
результаты отдельных бизнес-процессов, когда они часто анализируются вместе.
Наконец, мы обсудили естественное применение продуктов OLAP для финансового анализа. Мы также подчеркнули важность интеграции аналитических
пакетов в общую среду DW/BI за счет использования согласованных измерений.
8
З
Управление
взаимоотношениями
с клиентами
адолго до того, как появилось модное слово «управление взаимоотношениями с клиентами» (CRM), организации проектировали и внедряли ориентированные на клиента размерные модели, чтобы лучше понять поведение своей
аудитории. На протяжении десятилетий эти модели использовались для ответа
на запросы руководства о том, какие клиенты были взяты в работу, кто ответил
и каков был масштаб их ответа. Бизнес-ценность понимания всего спектра взаимодействий и транзакций клиентов вывела CRM на первое место в чартах. CRM
включает в себя не только знакомых нам жильцов домов и коммерческих клиентов, но также граждан, пациентов, студентов и многие другие категории людей
и организаций, чье поведение и предпочтения важны для бизнеса. CRM — это
критически важная бизнес-стратегия, которую многие считают необходимой для
выживания организации.
В этой главе мы начнем с обзора CRM, включая ее операционные и аналитические функции. Затем мы представим базовый дизайн измерения «Клиент»,
включая общие атрибуты, такие как даты, атрибуты сегментации, повторяющиеся роли контактов и агрегированные факты. Мы обсудим анализ имени и адреса
клиента, а также международные соображения. Мы напомним вам о проблемах
моделирования сложных иерархий, когда мы описываем различные виды иерархий клиентов.
В главе 8 рассматриваются следующие концепции:
■ обзор CRM-системы;
■ анализ имени и адреса клиента, включая международные особенности;
■ обработка дат, агрегированных фактов, атрибутов и оценок поведения сегментации в измерении «Клиент»;
■ внешние измерения для атрибутов низкой кардинальности;
■ соединительные таблицы для разреженных атрибутов, а также компромиссы между соединительными таблицами и позиционным дизайном;
■ соединительные таблицы для нескольких контактов с клиентами;
296
Глава 8
■ группы по изучению поведения для определения групп потребителей;
■ измерение «Шаг» для анализа последовательного поведения клиентов;
■ таблицы сведений о временных интервалах с датами вступления в силу
и истечения срока действия;
■ добавление таблиц фактов с разными измерениями для удовлетворительных или ненормальных сценариев;
■ интеграция данных клиентов с помощью управления основными данными
или частичного соответствия во время последующей обработки ETL;
■ предупреждения о соединениях таблиц «факт к факту»;
■ проверка реальности в режиме реального времени, требования к низкой
задержке.
Поскольку проблемы и способы моделирования, ориентированные на клиента, представленные в этой главе актуальны для разных отраслей и функциональных областей, мы не включили в наш обзор сведения о работе с матрицей шин.
Обзор CRM-системы
Независимо от отрасли организации перешли на концепцию CRM. Они вскочили на подножку последнего вагона уходящего поезда в попытке перейти от ориентации на продукт, к ориентации на потребности клиентов. Хотя всеобъемлющие термины, такие как управление взаимоотношениями с клиентами, иногда
кажутся двусмысленными и/или чрезмерно амбициозными, предпосылка, стоящая за CRM, не так сложна. Она основана на простом понятии, что чем лучше
вы знаете своих клиентов, тем лучше сможете поддерживать с ними долгосрочные и ценные отношения. Цель CRM — максимизировать отношения с вашими клиентами на протяжении всей их жизни. Это предполагает сосредоточение
всех аспектов бизнеса начиная с маркетинга, продаж, операций и обслуживания
на установлении и поддержании взаимовыгодных отношений с клиентами. Для
этого организация должна разработать единое, интегрированное представление
о каждом клиенте.
CRM обещает значительную отдачу организациям, которые ее используют,
как для увеличения доходов, так и для повышения операционной эффективности. Переход на ориентированную на клиента перспективу может привести
к повышению эффективности продаж и скорости закрытия сделок, росту выручки, повышению производительности продаж при снижении затрат, повышению
рентабельности продаж для клиентов, повышению удовлетворенности клиентов
и увеличению удержания клиентов. В конечном счете каждая организация хочет
иметь более лояльных, более прибыльных клиентов. Поскольку для привлечения
Управление взаимоотношениями с клиентами
297
новых клиентов часто требуются значительные инвестиции, вы не можете позволить, чтобы те, кто приносит прибыль, уходили.
Во многих организациях интерес к данным о клиенте меняется в зависимости от бизнес-подразделения продуктовой линейки, бизнес-функции и/или географического положения. Каждая группа может использовать разные данные
о клиентах разными способами с разными результатами. Очевидно, что переход
от существующих изолированных структур к более интегрированной перспективе требует организационной приверженности. CRM подобен динамитной
шашке, которая разрушает стены бункера. Для достижения эффективности
требуется правильная интеграция бизнес-процессов, персонал и эффективные
технологии.
За последнее десятилетие бурный рост социальных сетей, технологий отслеживания местоположения, мониторинга использования сети, мультимедийных
приложений и сенсорных сетей предоставил океан данных о поведении клиентов, которые даже предприятия на Мейн-стрит признают полезными для понимания. Хотя бóльшая часть этих данных находится за пределами зоны комфорта
реляционных баз данных, новые методы больших данных могут вернуть эти данные в область DW/BI. В главе 21 обсуждаются лучшие методы внедрения этого
нового вида Big data в среду DW/BI. Но если оставить в стороне чисто технологические проблемы, то реальная идея заключается в необходимости глубокой
интеграции. Вы должны решить задачу интеграции до 100 источников данных,
ориентированных на клиентов, большинство из которых внешние. Эти источники данных имеют разную зернистость, имеют несовместимые атрибуты клиента
и не находятся под вашим контролем. Есть вопросы?
Поскольку человеческой природе свойственно сопротивляться изменениям,
неудивительно, что проблемы, связанные с людьми, часто бросают вызов внедрению CRM. CRM предполагает совершенно новые способы взаимодействия
с клиентами и часто влечет за собой радикальные изменения в каналах продаж.
CRM требует новых информационных потоков, основанных на полном сборе
данных о «точках соприкосновения» с клиентом и их распространении. Часто
организационные структуры и системы стимулирования труда претерпевают
кардинальные изменения.
В главе 17 мы подчеркнем важность поддержки инициативы DW/BI как
со стороны высшего руководства бизнеса, так и со стороны ИТ-руководства. Этот
совет также применим к внедрению CRM благодаря его кросс-функциональной
направленности. CRM требует четкого бизнес-видения. Без бизнес-стратегии,
доверия пользователей и разрешения на изменение CRM обречено на провал.
Ни ИТ, ни бизнес-сообщество не могут успешно внедрить CRM самостоятельно; CRM требует совместной поддержки.
298
Глава 8
Операционная и аналитическая CRM
Можно сказать, что CRM страдает синдромом раздвоения личности, поскольку
ей необходимо удовлетворять как операционным, так и аналитическим требованиям. Эффективная CRM основана на сборе данных при каждом взаимодействии с клиентом, а затем на использовании этого объема данных с помощью
анализа.
На операционном фронте CRM требует синхронизации процессов, ориентированных на клиента. Часто операционные системы необходимо либо
обновлять, либо дополнять для координации продаж, маркетинга, операций
и обслуживания. Подумайте обо всех взаимодействиях с клиентами, которые
происходят во время покупки и использования продукта или услуги начиная
с первоначального контакта с потенциальным клиентом, формирования предложения, транзакции покупки, выполнения, транзакции оплаты и текущего
обслуживания клиентов. Вместо того чтобы думать об этих процессах как о независимых подразделениях (или о нескольких подразделениях, различающихся
в зависимости от линейки продуктов), подход CRM заключается в интеграции
этих действий с клиентами. Ключевые показатели и характеристики клиентов
собираются в каждой точке контакта и становятся доступными для других.
Поскольку данные создаются на операционной стороне уравнения CRM,
вам, очевидно, необходимо хранить и анализировать историю их изменений, полученную в результате взаимодействия с клиентами и транзакционных систем.
Звучит знакомо, не так ли? Система DW/BI лежит в основе CRM. Она служит
хранилищем для сбора и интеграции широкого спектра информации о клиентах, содержащейся в операционных системах, а также из внешних источников.
Хранилище данных — это основа, которая поддерживает панорамный 360-градусный обзор ваших клиентов.
Аналитическая CRM становится возможной за счет точных, интегрированных и доступных данных о клиентах в системе DW/BI. Вы можете измерить эффективность решений, принятых в прошлом, чтобы оптимизировать будущие
взаимодействия. Данные о клиентах могут быть использованы, чтобы эффективнее выявить возможности для увеличения прямых и перекрестных продаж,
выявления неэффективности, формирования спроса и повышения удержания.
Кроме того, исторические интегрированные данные могут быть использованы
для создания моделей или оценок, которые замыкают цикл возврата в операционный мир. Вспомнив основные компоненты среды DW/BI из главы 1, вы можете представить, что результаты модели будут перенесены туда, где отношения
управляются оперативно (например, представитель, кол-центр или сайт), как показано на рис. 8-1. Результаты модели могут быть преобразованы в конкретную
упреждающую или реактивную тактику, рекомендуемую для очередной точки
Управление взаимоотношениями с клиентами
299
контакта с клиентом, такую как соответствующее предложение следующего продукта или меры в борьбе с оттоком клиентов. Результаты модели также сохраняются в среде DW/BI для последующего анализа.
Интеграция
(ETL)
Сбор
(системы
с открытым
исходным кодом)
Модель
(приложения
бизнес-аналитики)
Хранение
(представление
данных)
Анализ
и отчетность
(приложения
бизнес-аналитики)
Рис. 8-1. Аналитическая CRM с замкнутым циклом
В других ситуациях информация должна поступать обратно на оперативный
сайт или в системы кол-центра в режиме реального времени. В этом случае замкнутый цикл намного более плотный, чем на рис. 8-1, потому что это вопрос
сбора и хранения, а в дальнейшем обратной связи с системой сбора. Современные операционные процессы должны сочетать текущее представление с историческим представлением, чтобы лицо, принимающее решения, могло, например,
решить, предоставлять ли кредит клиенту в режиме реального времени, учитывая историю жизни клиента. Но в целом требования к интеграции для операционной CRM не столь далекоидущие, как для аналитической CRM.
Очевидно, что по мере того как организация становится все более ориентированной на клиента, то же самое должна делать и система DW/BI. CRM
неизбежно приведет к изменениям в хранилище данных. Среды DW/BI будут развиваться еще быстрее по мере того, как вы будете собирать все больше
300
Глава 8
и больше информации о своих клиентах. Процессы ETL будут усложняться
по мере сопоставления и интеграции данных из нескольких источников. Главное, что потребность в согласованном измерении «Клиент» становится еще
более важной.
Атрибуты измерения «Клиент»
Согласованное измерение «Клиент» — критический элемент эффективной
CRM. Хорошо поддерживаемое, хорошо развернутое, согласованное описание
данных клиента — краеугольный камень надежного анализа CRM.
Измерение «Клиент», как правило, — наиболее сложное измерение для любой системы DW/BI. В крупной организации аналитика клиента может быть
чрезвычайно глубокой (со многими миллионами строк), чрезвычайно широкой
(с десятками или даже сотнями атрибутов) и иногда подверженной быстрым изменениям. Крупнейшие розничные торговцы, компании, выпускающие кредитные карты, и государственные учреждения имеют гигантские таблицы клиентов,
размер которых превышает 100 миллионов строк. Чтобы еще больше усложнить
ситуацию, аналитика клиента часто представляет собой объединение данных
из множества внутренних и внешних исходных систем.
В следующем разделе мы сосредоточимся на многочисленных соображениях
по проектированию измерения «Клиент». Мы начнем с анализа имени, адреса
и других общих атрибутов клиента, включая охват внешних измерений, а затем
перейдем к другим интересным атрибутам. Конечно, список атрибутов клиента,
как правило, довольно длинный. Чем больше описательной информации вы соберете о своих клиентах, тем надежнее будет их характеристика и тем интереснее
будет анализ.
Синтаксический анализ имени и адреса
Независимо от того, имеете ли вы дело с отдельными людьми или коммерческими
организациями, обычно фиксируются атрибуты имени и адреса клиентов. Оперативная обработка информации об имени и адресе обычно слишком упрощена,
чтобы быть очень полезной в системе DW/BI. Многие разработчики считают,
что либеральный дизайн столбцов общего назначения для имен и адресов, таких
как Имя-1 — Имя-3 и Адрес-1 — Адрес-6, может справиться с любой ситуацией.
К сожалению, эти сводные колонки практически бесполезны, когда дело доходит
до лучшего понимания и сегментации клиентской базы. Разработка столбцов
«Имя» и «Местоположение» в общем виде может фактически способствовать
возникновению проблем с качеством данных. Рассмотрим примерный дизайн
на рис. 8-2 с колонками общего назначения.
Управление взаимоотношениями с клиентами
301
Колонка
Значение примера данных
Мисс А. Джен Смит
Имя
123 Main Rd, North West, Ste 100A
Адрес 1
PO Box 2348
Address 2
Kensington
Город
Ark.
Штат
88887-2348
Почтовый индекс
Телефонный номер 888-555-3333 x776 main, 555-4444 fax
Рис. 8-2. Пример данных об имени/адресе клиента в слишком общих столбцах
В этом дизайне столбец «имя» слишком ограничен. Не существует согласованного механизма обработки приветствий, титулов или суффиксов. Вы не можете определить, как зовут этого человека или как к нему следует обращаться
в персональном приветствии. Если вы посмотрите на дополнительные примеры
данных из этой операционной системы, вы потенциально обнаружите несколько клиентов, перечисленных в одном атрибуте имени. Вы также можете найти
дополнительную описательную информацию в столбце имя, такую как «Доверенность», «Доверенное лицо» или UGMA («Закон о едином дарении несовершеннолетним»).
В атрибутах примера адреса в разных местах используются несогласованные
сокращения. В столбцах адресов может быть достаточно места для любого адреса, но в столбцах нет той дисциплины, которая могла бы гарантировать соответствие правилам почтового ведомства или поддерживать сопоставление адресов
и идентификацию широты/долготы.
Вместо использования нескольких столбцов общего назначения атрибуты
имени и местоположения следует разбить на как можно большее количество элементарных частей. В процессе извлечения необходимо выполнить значительный
синтаксический анализ исходных имен и адресов. После анализа атрибутов их
можно стандартизировать. Например, Rd станет «дорогой», а Ste — «отельным номером». Атрибуты также могут быть проверены, например, проверка
правильности почтового индекса и соответствующей комбинации штатов. К счастью, на рынке имеются средства очистки и очистки данных об именах и адресах,
которые помогают в анализе, стандартизации и проверке.
Примерный набор атрибутов имени и местоположения для физических лиц
в Соединенных Штатах показан на рис. 8-3. Каждый атрибут заполнен образцами
данных, чтобы сделать дизайн более понятным, но ни один реальный экземпляр,
к сожалению, не будет выглядеть так идеально. Конечно, бизнес-представители
по управлению данными должны участвовать в определении аналитической ценности этих проанализированных элементов данных в измерении «Клиент».
302
Глава 8
Колонка
Обращение
Неформальное имя
Формальное приветствие
Первое и второе имя
Фамилия
Суффикс
Национальность
Должность
Номер улицы
Название улицы
Тип улицы
Направление улицы
Город
Район
Второй район
Штат
Регион
Страна
Континент
Почтовый код
Второй почтовый код
Тип почтового кода
Код страны номера телефона компании
Код области номера телефона компании
Номер телефона компании
Добавочный номер
Номер страны мобильного номера телефона
Код области номера мобильного телефона
Номер мобильного телефона
E-mail
Веб-сайт
Тип публичного ключа аутентификации
Центр сертификации
Уникальный личный идентификатор
Пример значения данных
Мисс
Джейн
Мисс Смит
Р. Джейн
Смит
Мл.
Англичанка
Адвокат
123
Main
Road
Северо-Запад
Кенсингтон
Корнуолл
Беркшир
Арканзас
Юг
Соединенные Штаты
Северная Америка
88887
2348
Соединенные Штаты
1
888
5553333
776
1
509
5554444
RJSmith@ABCGenIntl.com
www.ABCGenIntl.com
X.509
Verisign
7346531
Рис. 8-3. Образец данных об имени/адресе клиента с проанализированными
элементами имени и адреса
Коммерческие клиенты обычно имеют несколько адресов, таких как физические адреса и адреса доставки; каждый из этих адресов будет следовать той же
логике, что и структура адресов, показанная на рис. 8-3.
Управление взаимоотношениями с клиентами
303
Некоторые соображения по поводу
интернационализации имен и адресов
Международное отображение и печатная продукция обычно требуют представления иностранных символов, включая не только акцентированные символы западноевропейских алфавитов, но также кириллицу, арабский, японский, китайский и десятки других менее знакомых систем письма. Важно понимать, что это
не проблема шрифта. Это проблема с набором символов. Шрифт — это просто
изображение художником набора символов. Существуют сотни шрифтов, доступных для стандартного английского языка, но стандартный английский имеет относительно небольшой набор символов, которого достаточно для любого
пользователя, если вы не профессиональный типограф. Этот небольшой набор
символов обычно кодируется в американском стандартном коде обмена информацией (ASCII), который представляет собой 8-битную кодировку, содержащую
максимум 255 возможных символов. Только приблизительно 100 из этих 255 символов имеют стандартную интерпретацию, которую можно вызвать с обычной
английской клавиатуры, но этого обычно достаточно для англоговорящих пользователей компьютеров. Должно быть ясно, что ASCII крайне неадекватен для
представления тысяч символов, необходимых для неанглийских систем письма.
Международная организация системных архитекторов, Консорциум Unicode,
определила стандарт, известный как Unicode, для представления символов и алфавитов почти во всех языках и культурах мира. С их работами можно ознакомиться в интернете по адресу https://home.unicode.org/. Стандарт Unicode
версии 6.2.0 определил конкретные интерпретации для 110 182 возможных
символов и теперь охватывает основные письменные языки Америки, Европы,
Ближнего Востока, Африки, Индии, Азии и Тихого Океана. Юникод — это основа, которую вы должны использовать для адресации международных наборов
символов. Но важно понимать, что внедрение решений Unicode выполняется
на базовых уровнях ваших систем. Так, операционная система должна быть совместимой с Unicodecompliant. К счастью, последние версии всех основных операционных систем совместимы с Юникодом. Выше операционной системы все
устройства, которые захватывают, хранят, передают и печатают символы, должны
соответствовать стандарту Unicode. Вспомогательные средства хранилища данных должны соответствовать стандарту Unicode, включая пакеты сортировки,
языки программирования и автоматизированные пакеты ETL. Наконец, приложения DW/BI, включая механизмы баз данных, серверы приложений BI и их
средства создания отчетов и запросов, веб-серверы и браузеры, должны соответствовать стандарту Unicode. Архитектор DW/BI должен не только общаться
с поставщиками каждого пакета в конвейере данных, но и постоянно проводить
304
Глава 8
различные сквозные тесты. Запишите некоторые имена и адреса с помощью символов юникода на экранах сбора данных одного из устаревших приложений и отправьте их через систему. Попросите их вывести итоговый отчет или итоговое
окно браузера из системы DW/BI и посмотрите, присутствуют ли специальные
символы. Этот простой тест устранит бóльшую часть путаницы в ваших данных.
Обратите внимание: даже когда вы это делаете, один и тот же символ, такой как
a-умлаут, сортируется по-разному в разных странах, таких как Норвегия и Германия. Хотя вы не можете исследовать абсолютно все вариации в международных
последовательностях сопоставления, по крайней мере и норвежцы, и немцы согласятся, что воспроизводимый символ останется а-умлаутом.
Географические атрибуты клиентов усложняются, если вы имеете дело с клиентами из нескольких стран. Даже если у вас нет международных клиентов, вам
может потребоваться указать международные имена и адреса где-нибудь в системе DW/BI для международных поставщиков и записей персонала отдела
кадров.
ПРИМЕЧАНИЕ Обратите внимание, что измерение «Клиент» иногда вклю-
чает атрибут полного адресного блока. Это специально созданный столбец, в котором собран почтовый адрес для клиента, включая почтовую станцию, почтовый индекс и другие атрибуты, необходимые для удовлетворения требований
почтовых служб. Этот атрибут полезен для международных местоположений,
где адреса имеют местные особенности.
Международные цели DW/BI
После перехода на Unicode foundation вам необходимо учитывать следующие
цели, помимо требований к синтаксическому анализу имен и адресов, рассмотренных ранее:
■ Универсальность и последовательность.
Как говорится, пусти козу в огород. Если вы собираетесь разработать систему для международного использования, вы захотите, чтобы она работала по всему миру. Вам нужно тщательно подумать, должны ли инструменты
BI создавать переведенные версии отчетов на многих языках.
Может возникнуть соблазн предоставить переведенные версии измерений для каждого языка, но переведенные измерения порождают некоторые более изощренные проблемы;
❒ Последовательность сортировки будет отличаться, поэтому либо отчеты будут отсортированы по-разному, либо все отчеты, кроме отчетов
на «корневом» языке, будут отображаться несортированными.
Управление взаимоотношениями с клиентами
305
❒ Если количество атрибутов не будет точно сохранено на разных языках,
то либо итоговые значения групп не будут одинаковыми в отчетах, либо
некоторые группы на разных языках будут содержать дублированные заголовки строк, которые выглядят как ошибки. Чтобы избежать худшей
из этих проблем, вам следует перевести измерения после запуска отчета; сначала отчет должен быть подготовлен на одном корневом языке,
а затем текст отчета должен быть переведен на предполагаемые целевые
языки.
❒ Все сообщения и подсказки инструмента BI должны быть переведены
в интересах бизнес-пользователей. Этот процесс известен как локализация и более подробно обсуждается в главе 12.
■ Сквозное качество данных и последующая совместимость.
Хранилище данных не может быть единственным этапом в конвейере данных, который заботится о целостности международных имен и адресов.
Правильный дизайн требует поддержки начиная с первого шага записи
имени и адреса через этапы очистки и хранения данных и заканчивая заключительными этапами выполнения географического и демографического анализа и вывода отчетов.
■ Культурологическая корректность.
Во многих случаях иностранные клиенты и партнеры увидят результаты
вашей системы DW/BI в той или иной форме. Если мы не понимаем, что
из записанного имя, а что фамилия, и если вы не понимаете, как обращаться к человеку, вы рискуете оскорбить его или, по крайней мере, выглядеть
глупо. Если в выходных данных неправильно расставлены знаки препинания или есть иные ошибки, ваши иностранные клиенты и партнеры пожалеют, что имеют дело с вами, а не с местной компанией.
■ Ответы клиентам в реальном времени.
Системы DW/BI могут играть оперативную роль, поддерживая системы
реагирования на запросы клиентов в режиме реального времени. Представитель службы поддержки клиентов может ответить на телефонный звонок,
и у него может быть 5 секунд или меньше, чтобы дождаться появления приветствия на экране, которое хранилище данных рекомендует использовать
в разговоре с клиентом. Приветствие может включать правильное приветствие и верное название должности и имени клиента. Это приветствие
представляет собой отличное использование кеша горячих ответов, который содержит предварительно рассчитанные ответы для каждого клиента.
306
Глава 8
■ Другие виды адресов.
Мы находимся в разгаре революции в области коммуникации и сетевого
взаимодействия. Если вы разрабатываете систему идентификации международных имен и адресов, вы должны предусмотреть необходимость хранения электронных имен, токенов безопасности и интернет-адресов.
Как и в случае с международными адресами, телефонные номера должны быть
представлены по-разному в зависимости от того, откуда исходит телефонный
звонок. Вам необходимо предоставить атрибуты для представления полной последовательности набора номера за рубежом, полной последовательности набора номера внутри страны и последовательности местного набора. К сожалению,
полные последовательности набора иностранных номеров различаются в зависимости от страны происхождения.
Даты, ориентированные на клиента
Данные о клиентах часто содержат даты, такие как дата первой покупки, дата последней покупки и дата рождения. Хотя эти даты изначально могут быть столбцами типа даты SQL, если вы хотите суммировать эти даты по вашим уникальным
атрибутам календаря, таким как сезоны, кварталы и финансовые периоды, их следует изменить на ссылки внешнего ключа на измерение «Дата». Вы должны быть
осторожны, чтобы все такие даты попадали в диапазон измерения корпоративных
дат. Эти роли измерения даты объявляются как семантически различные представления, такие как таблица измерения «Дата первой покупки» с уникальными метками столбцов. Система ведет себя так, как если бы существовала другая физическая таблица дат. Ограничения для любой из этих таблиц не имеют ничего общего
с ограничениями для основной таблицы измерений «Дата». Эта конструкция, как
показано на рис. 8-4, пример выносного измерения, которое обсуждается в разделе
«Выносное внешнее измерение для атрибутов с низкой кардинальностью».
Измерение «Дата первой покупки»
Ключ даты первой покупки (PK)
Дата первой покупки
Месяц первой покупки
Год первой покупки
Финансовый месяц первой покупки
Финансовый квартал первой покупки
Финансовый год первой покупки
Время года первой покупки
…
Измерение «Клиент»
Ключ клиента (PK)
ID клиента (естественный ключ)
Обращение к клиенту
Первое имя клиента
Фамилия клиента
Город клиента
Штат клиента
…
Ключ даты первой покупки (FK)
Рис. 8-4. Выносные измерения для даты
Таблица фактов
Ключ даты транзакции (FK)
Ключ клиента (FK)
Другие ключи …
Факты…
Управление взаимоотношениями с клиентами
307
Агрегированные факты как атрибуты измерений
Бизнес-пользователи часто заинтересованы в фильтровании измерения «Клиент» на основе агрегированных показателей эффективности, таких как фильтрация всех клиентов, которые потратили более определенной суммы в долларах
в течение прошлого года. Или, что еще хуже, возможно, они хотят фильтровать
данные, основываясь на том, сколько клиент купил за всю свою жизнь. Предоставление агрегированных фактов в качестве атрибутов измерения, несомненно, понравится бизнес-пользователям. Они могли бы выдать запрос для идентификации
всех клиентов, удовлетворяющих критериям расходов, а затем выдать другой запрос фактов для анализа поведения для этого подмножества измерений клиентов.
Но вместо всего этого вы можете сохранить агрегированный факт в качестве атрибута измерения. Это позволяет бизнес-пользователям просто ограничивать атрибут расходов точно так же, как они могли бы ограничить географический атрибут.
Эти атрибуты предназначены для ограничения и маркировки; они не должны использоваться в числовых вычислениях. Хотя хранение этих атрибутов обеспечивает удобство использования запросов и преимущества в производительности, основная нагрузка ложится на процессы ETL за кулисами, чтобы гарантировать, что
все измерения точные, актуальные и соответствуют фактическим строкам фактов.
Эти атрибуты могут потребовать значительных затрат вашего времени и внимания. Если вы решите включить некоторые агрегированные факты в качестве атрибутов конкретных параметров, обязательно сосредоточьтесь на тех, которые будут
часто использоваться. Также стремитесь свести к минимуму частоту обновления
этих атрибутов. Например, атрибут для расходов за прошлый год потребует гораздо меньшего обслуживания, чем атрибут, обеспечивающий поведение с начала
года. Вместо того чтобы сохранять атрибуты вплоть до определенной стоимости
в долларах, их иногда заменяют (или дополняют) более значимыми описательными значениями, такими как «Высокий расход», как обсуждается в следующем
разделе. Эти описательные значения сводят к минимуму вашу уязвимость, связанную с тем, что числовые атрибуты могут не привязываться к соответствующим
таблицам фактов. Кроме того, они гарантируют, что все пользователи имеют согласованное определение, например, для крупных трат, вместо того чтобы прибегать к собственным индивидуальным бизнес-правилам.
Атрибуты сегментации и оценки
Некоторые из наиболее важных атрибутов в характеристиках клиента — это
классификация сегментации. Очевидно, что эти атрибуты сильно различаются
в зависимости от бизнес-контекста. Для отдельного клиента они могут включать:
■ пол;
■ этническую принадлежность;
308
Глава 8
■ классификацию по возрасту или другим этапам жизни;
■ доход или другие классификации образа жизни;
■ статус (например, новый, активный, неактивный и закрытый);
■ ссылающийся источник;
■ сегмент рынка, специфичный для бизнеса (например, предпочтительный
идентификатор клиента).
Аналогичным образом многие организации оценивают своих клиентов,
чтобы охарактеризовать их. Статистические модели сегментации обычно генерируют эти оценки, которые группируют клиентов различными способами,
например, на основе их покупательского поведения, платежного поведения,
склонности к оттоку или вероятности дефолта. Каждому клиенту присваивается
итоговый балл.
Временные ряды тегов поведения
Один из популярных подходов к оценке и профилированию клиентов рассматривает недавность (R), частоту (F) и интенсивность (I) поведения клиента. Они
известны как показатели RFI; иногда интенсивность заменяется денежной (M),
поэтому она также известна как RFM. Недавность — это сколько дней прошло
с тех пор, как клиент в последний раз делал заказ или посещал ваш сайт. Частота — это количество раз, когда клиент делал заказ или посещал сайт, как правило, за последний год. А интенсивность — это то, сколько денег клиент потратил
за тот же период. При работе с большой клиентской базой поведение каждого клиента может быть смоделировано в виде точки в кубе RFI, как показано
на рис. 8-5. На этом рисунке шкалы вдоль каждой оси представляют собой квантили от 1 до 5, которые распределяют фактические значения по четным группам.
Если у вас есть миллионы точек в кубе, становится трудно увидеть значимые
скопления этих точек. Сейчас самое подходящее время спросить специалиста
по интеллектуальному анализу данных, где находятся значимые кластеры. Такой
специалист может вернуться со списком тегов поведения, подобным приведенному ниже, который составлен на основе несколько более сложного сценария,
включающего кредитное поведение и возвраты:
A: Постоянный клиент большого объема, хороший кредит, мало возвратов
товара.
B: Постоянный клиент большого объема, хороший кредит, много возвратов
товара.
C: Недавний новый клиент, нет установленной кредитной схемы.
D: Случайный клиент, хороший кредит.
Управление взаимоотношениями с клиентами
309
E: Случайный клиент, плохой кредит.
F: Бывший хороший клиент, которого в последнее время не видели.
G: Просто смотрит товар, не покупая, в основном непродуктивный.
H: Другое.
Высшая 5
4
Новизна
3
5 Высшая
4
2
Низшая 1
1
2
Низшая
3
4
5
Высшая
Интенсивность
3
2
1 Низшая
Частота
Рис. 8-5. Куб новизны, частоты, интенсивности (RFI)
Теперь вы можете просмотреть данные временных рядов клиентов и связать
каждого клиента в каждом отчетном периоде с ближайшим кластером. Майнер
данных может помочь в этом. Таким образом, последние 10 наблюдений клиента
по имени Джон Доу могут выглядеть так:
Джон Доу: C C C D D A A A B B
Такой временной ряд поведенческих тегов необычен, потому что, хотя он
получен в результате регулярного периодического процесса измерения, наблюдаемые «значения» текстовые. Теги поведения не числовые и не могут быть вычислены или усреднены, но их можно запросить. Например, вы можете захотеть
найти всех клиентов, которые были A когда-то в пятом, четвертом или третьем
предыдущем периоде и были B во втором или первом предыдущем периоде. Возможно, вы обеспокоены подобными изменениями и боитесь потерять ценного
клиента из-за растущего числа возвратов.
Теги поведения не должны храниться как обычные факты. Основное применение поведенческих тегов заключается в формулировании сложных шаблонов
запросов, подобных примеру в предыдущем абзаце. Если бы теги поведения хранились в отдельных строках фактов, такой запрос был бы чрезвычайно сложным,
требующим каскада взаимосвязанных подзапросов. Рекомендуемый способ обработки тегов поведения — построить явный временной ряд атрибутов в измерении «Клиент». Это еще один пример позиционного дизайна. Интерфейсы BI
310
Глава 8
просты, потому что столбцы находятся в одной таблице, а производительность
высока, потому что вы можете создавать на них битовые индексы. В дополнение
к отдельным столбцам для каждого периода времени тега поведения было бы
неплохо создать единый атрибут со всеми объединенными тегами поведения,
например CCCDDAAABB. Этот столбец будет поддерживать поиск по подстановочным знакам для экзотических шаблонов, таких как «D, за которым следует
буква B».
ПРИМЕЧАНИЕ В дополнение к временным рядам тегов поведения измере-
ния «Клиент» было бы разумно включить значение тега текущего поведения
в мини-измерение для анализа фактов по тегу поведения в момент, когда была
загружена строка фактов.
Взаимосвязь между интеллектуальным анализом данных
и системой DW/BI
Команда интеллектуального анализа данных может быть отличным клиентом
хранилища данных и особенно отличным пользователем данных о поведении
клиентов. Однако может возникнуть несоответствие между скоростью, с которой
хранилище данных может доставлять данные, и скоростью, с которой «добытчики» (miners) данных могут потреблять данные. Например, инструмент «дерево
решений» может обрабатывать сотни записей в секунду, но большой детализированный отчет, содержащий «наблюдения за клиентами», никогда не сможет
предоставлять данные с такой скоростью. Рассмотрим следующую семиступенчатую детализацию отчета, в котором могут быть представлены миллионы наблюдений за клиентами на основе данных переписи, демографических данных,
внешних кредитов, внутренних кредитов, покупок, возвратов и данных сайта:
SELECT Customer Identifier, Census Tract, City, County,
State, Postal Code, Demographic Cluster, Age, Sex, Marital
Status, Years of Residency, Number of Dependents, Employment
Profile, Education Profile, Sports Magazine Reader Flag,
Personal Computer Owner Flag, Cellular Telephone Owner
Flag, Current Credit Rating, Worst Historical Credit
Rating, Best Historical Credit Rating, Date First Purchase,
Date Last Purchase, Number Purchases Last Year, Change in
Number Purchases vs. Previous Year, Total Number Purchases
Lifetime, Total Value Purchases Lifetime, Number Returned
Purchases Lifetime, Maximum Debt, Average Age Customer's
Debt Lifetime, Number Late Payments, Number Fully Paid,
Управление взаимоотношениями с клиентами
311
Times Visited Web Site, Change in Frequency of Web Site
Access, Number of Pages Visited Per Session, Average Dwell
Time Per Session, Number Web Product Orders, Value Web
Product Orders, Number Web Site Visits to Partner Web Sites,
Change in Partner Web Site Visits
FROM *** WHERE *** ORDER BY *** GROUP BY ***
Команды по интеллектуальному анализу данных были бы в восторге от этого!
Например, большой файл из миллионов этих наблюдений может быть проанализирован с помощью инструмента «дерево решений», где инструмент «нацелен» на столбец «Общая стоимость покупок за весь срок службы», который
выделен выше. В этом анализе инструмент «дерево решений» определит, какой
из других столбцов предсказывает отклонение целевого поля. Возможно, ответ
заключается в «Лучшем историческом кредитном рейтинге» и «Количестве
иждивенцев». Вооружившись этим ответом, у предприятия теперь есть простой
способ предсказать, кто будет хорошим пожизненным клиентом, без необходимости знать весь остальной контент данных.
Но команда интеллектуального анализа данных хочет использовать эти наблюдения снова и снова для различных видов анализа, возможно, с помощью
нейронных сетей или инструментов рассуждения на основе конкретных случаев. Вместо того чтобы создавать этот набор ответов по запросу в виде большого
дорогостоящего запроса, этот набор ответов следует записать в файл и передать
команде интеллектуального анализа данных для анализа на ее серверах.
Различные счетчики в измерениях типа 2
Компании часто хотят подсчитывать клиентов на основе их атрибутов, не присоединяясь к таблице фактов. Если вы использовали тип 2 для отслеживания
изменений в атрибутах клиента, вам необходимо соблюдать осторожность,
чтобы избежать чрезмерного подсчета, поскольку у вас может быть несколько
строк в измерении клиента для одного и того же человека. Выполнение COUNT
DISTINCT от уникального идентификатора клиента, возможно, при условии,
что атрибут действительно уникален и устойчив. Индикатор текущей строки
в измерении «Клиент» также полезен для подсчета на основе наиболее актуальных описательных значений для клиента.
Ситуация усложняется, если вам нужно подсчитать количество клиентов
в определенный момент, используя даты вступления в силу и истечения срока
действия в измерении «Клиент». Например, если вам нужно знать количество
клиентов, которые у вас были в начале 2013 года, вы можете ограничить дату
вступления в силу строки <= '1/1/2013' и дату истечения срока действия строки
312
Глава 8
>= '1/1/2013', чтобы ограничить набор результатов только теми строками, которые были действительны на 1/1/2013. Обратите внимание, что операторы сравнения зависят от бизнес-правил, используемых для установки дат вступления
в силу /истечения срока действия строк. В этом примере дата истечения срока
действия строки в строке «недействительный клиент» на 1 день меньше даты
вступления в силу в новой строке.
Выносное внешнее измерение для атрибутов
с низкой кардинальностью
В главе 3 мы рекомендовали разработчикам избегать создания детализирующих
измерений по типу «снежинка», когда столбцы с низкой кардинальностью в измерениях перемещаются в новые измерения, которые затем связываются в исходную таблицу измерения. Как правило, структура «снежинки» не рекомендуется к использованию в среде DW/BI, поскольку она почти всегда усложняет
представление пользователя в дополнение к негативному влиянию на производительность просмотра. Несмотря на этот запрет на «заснеживание», существуют некоторые особые ситуации, когда допустимо создавать подобное внешнее
выносное измерение. Оно начинает выглядеть как таблица «снежинок».
Внешнее измерение «Демография страны»
Измерение «Клиент»
Таблица фактов
Ключ демографической принадлежности
страны (PK)
Общее население
Население до 5 лет
% Населения до 5 лет
Население до 18 лет
% Население до 18 лет
Население 65 и старше
% Населения 65 и старше
Женское население
% женского населения
Мужское население
% мужского населения
Количество людей с высшим образованием
Количество выпускников колледжей
Количество домохозяйств
Доля домовладельцев
...
Ключ клиента (PK)
ID клиента (Естественный
ключ)
Обращение к клиенту
Первое имя клиента
Фамилия клиента
Город клиента
Страна клиента
Ключ демографической
принадлежности
страны (FK)
Штат клиента
...
Ключ клиента (FK)
Другие ключи…
Факты…
Рис. 8-6. Внешнее измерение для кластера атрибутов с низкой
кардинальностью
Управление взаимоотношениями с клиентами
313
На рис. 8-6 внешнее выносное измерение представляет собой набор данных
от внешнего поставщика данных, состоящий из 150 демографических и социально-экономических атрибутов, касающихся округа проживания клиентов. Данные
для всех клиентов, проживающих в данном округе, идентичны. Вместо того чтобы повторять этот большой блок данных для каждого клиента в округе, выберите
его в качестве внешнего измерения. Есть несколько причин для нарушения правила «без снежинок». Так, демографические данные доступны для зернистости,
существенно отличающейся от данных первичного измерения, и они не столь
ценны с аналитической точки зрения. Он загружается в разное время, в отличие
от остальных данных в измерении «Клиент». Кроме того, в этом случае вы значительно экономите место, если базовый размер клиента велик. Если у вас есть
инструмент запроса, который настаивает на классической схеме звезды без снежинок, внешнее измерение может быть скрыто за обычным представлением (view).
Громоздкие внешние измерения допустимы, но они
должны быть скорее исключением, чем правилом. Красный предупреждающий
знак должен появиться, если ваш дизайн изобилует внешними измерениями;
возможно, вы поддались искушению чрезмерно нормализовать разработку, что
снижает ее эффективность.
ПРЕДУПРЕЖДЕНИЕ
Соображения об иерархии клиентов
Один из наиболее сложных аспектов работы с коммерческими клиентами — моделирование их внутренней организационной иерархии. Коммерческие клиенты
часто имеют вложенную иерархию организаций начиная от отдельных местоположений или организаций и заканчивая региональными офисами, штаб-квартирами бизнес-подразделений и конечными материнскими компаниями. Эти
иерархические отношения могут часто меняться по мере того, как клиенты реорганизуются внутри компании или участвуют в покупках и распродажах.
ПРИМЕЧАНИЕ В главе 7 мы описали, как работать с фиксированными
иерархиями, слегка изменяющимися иерархиями и неравномерными иерархиями нефиксированной глубины. В главе 7 основное внимание уделяется сводным
статьям затрат, но эти методы в точности можно перенести на иерархию клиентов. Если вы пропустили главу 7, вам нужно вернуться к ее изучению, чтобы
понять смысл последующих рекомендаций.
Хотя это относительная редкость, счастливчики среди нас иногда сталкиваются с иерархией клиентов, которая имеет очень предсказуемое фиксированное количество уровней. Предположим, вы отслеживаете не более трех уровней
314
Глава 8
иерархии, таких как конечная материнская компания, штаб-квартира бизнесподразделения и региональная штаб-квартира. В этом случае у вас есть три различных атрибута в измерении «Клиент», соответствующих этим трем уровням.
Для коммерческих клиентов со сложной организационной иерархией необходимо заполнить все три уровня, чтобы соответствующим образом представить три
различные сущности, задействованные на каждом уровне свертки. Это подход
с фиксированной глубинной иерархией из главы 7.
Напротив, если бы у другого клиента была смесь организаций одного, двух
и трех уровней, вы бы продублировали значение более низкого уровня для заполнения атрибутов более высокого уровня. Таким образом, все региональные штаб-квартиры будут суммироваться с суммой всех штаб-квартир бизнес-подразделений, которая будет суммироваться с суммой всех конечных
корпоративных родителей. Вы можете создавать отчеты по любому уровню
иерархии и видеть полную представленную клиентскую базу. Это так называемый подход со «слегка изменчивыми иерархиями».
Но во многих случаях сложные иерархии коммерческих клиентов представляют собой неравномерные иерархии с неопределенной глубиной, поэтому необходимо использовать метод моделирования такой иерархии, представленный в главе 7. Например, если коммунальная компания разрабатывает индивидуальный
тарифный план для всех потребителей коммунальных услуг, которые являются
частью крупного заказчика со многими уровнями офисов, филиалов, производственных помещений и торговых точек, вы не можете использовать фиксированную иерархию. Как указывалось в главе 7, наихудший вариант для разработчика — это создание набора общих уровней, названных, например, Уровень-1,
Уровень-2 и так далее. Это делает характеристики клиента непригодными для
использования, потому что вы не знаете, как ограничить эти уровни, когда у вас
организована нефиксированная иерархия неопределенной глубины.
Соединительные таблицы
для многозначных измерений
Фундаментальный принцип размерного моделирования состоит в том, чтобы определить зернистость таблицы фактов, а затем тщательно добавить измерения и факты к дизайну, которые соответствуют сути. Например, если
вы регистрируете транзакции покупок клиентов, суть отдельной покупки
естественна и физически убедительна. Вы не захотите менять эту структуру.
Таким образом, обычно требуется, чтобы любое измерение, прикрепленное
к этой таблице фактов, принимало одно значение, потому что тогда в таблице
фактов есть чистый единый внешний ключ, который идентифицирует один
Управление взаимоотношениями с клиентами
315
элемент измерения. Такие измерения, как клиент, местоположение, продукт
или услуга и время всегда имеют однозначное значение. Но у вас могут быть
некоторые проблемные измерения, которые принимают несколько значений
в зернистости отдельной транзакции. Обычные примеры этих многозначных
измерений включают:
■ демографические дескрипторы, взятые из множества источников;
■ контактные адреса коммерческого клиента;
■ профессиональные навыки соискателя работы;
■ хобби отдельного человека;
■ диагнозы или симптомы пациента;
■ дополнительные функции для легкового или грузового автомобиля;
■ владельцы совместных счетов на банковском счете;
■ арендаторы в арендуемой недвижимости.
Когда вы сталкиваетесь с многозначным измерением, есть два основных варианта: позиционный дизайн или дизайн соединительной таблицы. Позиционные
конструкции очень привлекательны, потому что многозначное измерение разбито на именованные столбцы, которые легко запрашивать. Например, при моделировании хобби отдельного человека, как упоминалось ранее, у вас может быть
измерение хобби с именованными столбцами для всех увлечений, собранных
у ваших клиентов, включая коллекционирование марок или монет, астрономию,
фотографию и многие другие. Вы сразу же видите проблему. Позиционный подход к проектированию не очень масштабируем. У вас может легко закончиться
количество столбцов в базе данных, и добавлять новые столбцы будет неудобно.
Кроме того, если у вас есть столбец для каждого возможного хобби, то строка
измерения хобби любого отдельного человека будет содержать в основном отсутствующие значения. Подход соединительной таблицы к многозначным измерениям мощный, но сопряжен с большим компромиссом.
Соединительная таблица не имеет проблем масштабируемости и нулевого
значения, поскольку строки в соединительной таблице существуют только в том
случае, если они действительно необходимы и вы можете добавить сотни или
даже тысячи хобби в предыдущем примере. Но результирующий дизайн таблицы
требует сложного запроса, который должен быть скрыт от прямого просмотра
бизнес-пользователями.
Имейте в виду, что для сложных запросов с использованием соединительных таблиц может потребоваться SQL, недоступный обычным инструментам BI. В следующих двух разделах мы проиллюстрируем многозначные конструкции соединительных таблиц, которые соответствуют темам
ПРЕДУПРЕЖДЕНИЕ
316
Глава 8
этой главы, ориентированным на клиента. Мы вернемся к многозначным соединительным таблицам в главах 9, 10, 13, 14 и 16. Затем мы опишем, как построить
эти таблицы в главе 19.
Соединительные таблицы для разреженных атрибутов
Организации все чаще собирают демографическую информацию и информацию
о статусе своих клиентов, но традиционный подход к моделированию фиксированных столбцов для обработки этих атрибутов становится сложным для масштабирования с сотнями атрибутов.
Позиционные конструкции имеют именованный столбец для каждого атрибута. Интерфейсы инструментов BI легко создавать для позиционных атрибутов,
поскольку именованные столбцы легко представлены в инструменте. Поскольку
многие столбцы содержат содержимое с низким количеством элементов, производительность запроса с использованием этих атрибутов может быть очень
хорошей, если в каждом столбце размещены битовые индексы. Позиционные
конструкции можно масштабировать примерно до 100 столбцов, прежде чем
базы данных и пользовательские интерфейсы станут неудобными или сложными в обслуживании. Колоночные базы данных хорошо подходят для такого рода
конструкций, поскольку новые столбцы могут быть легко добавлены с минимальными нарушениями во внутреннем хранилище данных, а столбцы с низкой кардинальностью, содержащие всего несколько дискретных значений, значительно
сжимаются.
Когда количество различных атрибутов выходит за пределы вашей зоны комфорта и если новые атрибуты добавляются часто, рекомендуется соединительная
таблица. В конечном счете, когда у вас очень большой и расширяющийся набор
демографических показателей, использование выносных внешних измерений
или мини-измерений просто не позволяет корректно масштабироваться. Например, вы можете собирать информацию о заявке на получение кредита в виде
набора открытых пар «имя — значение», как показано на рис. 8-7. Эти пары
интересны тем, что значения могут быть числовыми, текстовыми, указателем
файла, URL-адресом или даже рекурсивной ссылкой на вложенные данные пары
«имя — значение».
За определенный период вы могли бы собрать сотни или даже тысячи различных переменных заявки на получение кредита. Для источника данных, хранящего оригинальные данные пары «имя — значение», само поле значения может
быть сохранено в виде текстовой строки для поддержания открытой модальности, которая интерпретируется приложением анализа. В этих ситуациях, когда
количество переменных не ограничено и непредсказуемо, подходит конструкция
соединительной таблицы, как показано на рис. 8-8.
Управление взаимоотношениями с клиентами
317
Данные на получение кредита, пары «ключ — значение»
Фотография: <изображение>
Первичный доход: $72345
Другой облагаемый налогом доход: $2345
Доход, не облагаемый налогами: $3456
Долгосрочные вклады: $2367
Заработная плата: $789
Ожидающие судебного решения выплаты: $555
Алименты: $666
Оценочная стоимость совместно нажитым имуществом: $123456
Фото совместно нажитого имущества: <изображение>
Ссылка в списке объектов недвижимости: <URL>
Процент владения: 50
Количество иждивенцев: 4
Существующие ранее медицинские факты: Травма спины
Количество дней нетрудоспособности: 6
Заявление работодателя о пособии по инвалидности: <архив документов>
Тип последней декларации о банкротстве: 11
Лет прошло с банкротства: 8
Раскрытие финансовой информации супруга/супруги: <пары «ключ — значение»>
… 100 и больше пар «ключ — значение»…
Рис. 8-7. Данные пары «имя — значение» сопряженных данных
Таблица фактов
заявлений на кредит
Дата подачи заявки (FK)
Ключ заявителя (FK)
Ключ типа заявки (FK)
ID заявки (DD)
Ключ офиса подачи
заявки (FK)
Ключ андеррайтера (FK)
Ключ ветви (FK)
Ключ статуса (FK)
Ключ раскрытия
информации о заявке (FK)
Измерение «Раскрытие
информации о заявке»
Ключ раскрытия информации
о заявке (PK)
Описания раскрытия
информации о заявке
Соединительная таблица
раскрытия информации
о заявке
Ключ раскрытия
информации о заявке (FK)
Ключ предмета раскрытия
информации (FK)
Измерение
«Раскрытие информации»
Ключ предмета
раскрытия
информации (PK)
Имя предмета
Тип значения предмета
Значение предмета —
текстовая строка
Рис. 8-8. Таблица мостов для широкого и разреженного набора данных пар
«имя — значение»
Соединительная таблица для нескольких контактов
с клиентами
У крупных коммерческих заказчиков есть множество контактных лиц, включая
лиц, принимающих решения, агентов по закупкам, руководителей отделов и специалистов по связям с пользователями; каждый контакт связан с определенной
ролью. Поскольку количество контактов непредсказуемо, но, возможно, велико,
создание соединительной таблицы — удобный способ решения этой ситуации,
318
Глава 8
как показано на рис. 8-9. Следует проявлять определенную осторожность, чтобы
не переусердствовать с измерением «Контакт» и не превратить его в свалку для
каждого сотрудника, гражданина, продавца или человека, с которым взаимодействует организация. Ограничьте измерение для этого варианта использования
контактов как части отношений с клиентами.
Измерение «Клиент»
Ключ клиента (PK)
Имя клиента
Тип клиента
Группа контакта клиента (FK)
Дата первого контакта
...
Измерение
«Контактная группа»
Ключ группы
контакта (PK)
Наименование группы
контакта
Связь группы контакта
Измерение «Контакт»
Ключ группы
контакта (FK)
Ключ контакта (FK)
Роль контакта
Ключ контакта (PK)
Имя контакта
Адрес улицы
контакта
...
Рис. 8-9. Пример соединительной таблицы для нескольких контактов
Сложное поведение клиента
Поведение клиентов может быть очень неоднозначным. В этом разделе мы обсудим обработку когортных групп клиентов и отслеживание их последовательного
поведения. Мы также рассмотрим таблицы фактов с точным временным интервалом и пометку фактических событий показателями удовлетворенности клиентов
или ненормальными сценариями.
Группы по изучению поведения для когорт
При анализе клиентов простые запросы, такие как «Сколько было продано клиентам в этой географической области в прошлом году», быстро превращаются
в гораздо более сложные, например «Сколько клиентов купили в прошлом месяце больше, чем их среднемесячная сумма покупок за прошлый год». Последний
вопрос слишком сложен для бизнес-пользователей, чтобы выразить его в одном
SQL-запросе. Некоторые производители инструментов BI допускают встроенные подзапросы, в то время как другие реализовали возможности детализации,
когда сложные запросы разбиваются на несколько операторов выбора, а затем
объединяются в последующем проходе.
В других ситуациях вы можете захотеть взять набор клиентов из отчета о запросе или исключении, например, 100 лучших клиентов за прошлый год, клиентов, которые потратили более 1000 долларов в прошлом месяце, или клиентов,
которые получили специальное предложение о тестировании, а затем использовать эту группу клиентов, называемую «группой изучения поведения», для
последующего анализа без повторной обработки для определения их начального
состояния. Для создания группы по изучению поведения выполните запрос (или
Управление взаимоотношениями с клиентами
319
серию запросов), чтобы определить набор клиентов, которых вы хотите дополнительно проанализировать, а затем зафиксируйте постоянные ключи клиентов
идентифицированного набора в виде реальной физической таблицы, состоящей
из одного столбца ключа клиента. Если использованы устойчивые ключи клиентов, измерение «Исследуемая группа» невосприимчиво к изменениям типа 2
в измерении «Клиент», которые могут произойти после идентификации членов
исследуемой группы.
ПРИМЕЧАНИЕ Секрет построения сложных запросов по изучению поведе-
ния группы заключается в том, чтобы получить ключи клиентов или продуктов,
поведение которых вы отслеживаете. Затем вы используете сохраненные ключи
для последующей фильтрации других таблиц фактов без необходимости повторно запускать исходный анализ поведения.
Теперь вы можете использовать измерение «Изучаемая группа», содержащее
устойчивые ключи клиентов, всякий раз, когда захотите ограничить любой анализ в любой таблице этим набором специально определенных клиентов. Единственное требование состоит в том, чтобы таблица фактов содержала ссылку
на ключ клиента. Использование измерения «Исследуемая группа» показано
на рис. 8-10.
Таблица фактов продаж на кассе
Измерение «Исследуемая
группа клиентов»
ID клиента (устойчивый
ключ)
Измерение «Клиент»
Ключ клиента (PK)
ID клиента (надежный
ключ)
...
Ключ даты (FK)
Ключ клиента (FK)
Другие ключи …
Продано количество товаров
Сумма продажи в долларах
Рис. 8-10. Измерение группы по изучению поведения, соединенное
с надежным ключом измерения клиента
Измерение «Исследуемая группа» присоединено с помощью равнозначного соединения к устойчивому ключу измерения «Клиент» (см. «Идентификатор клиента» на рис. 8-10). Это можно сделать в представлении (view), которое скрывает явное соединение с измерением «Исследуемая группа». Таким
образом, полученная размерная модель выглядит и ведет себя как несложная
«звезда». Если таблица специальных измерений скрыта под представлением,
ее следует пометить, чтобы однозначно идентифицировать, например как связанную со 100 лучшими клиентами. Практически любой инструмент BI теперь
может анализировать эту специально ограниченную схему, не жертвуя простотой
320
Глава 8
синтаксиса или пользовательского интерфейса в пользу сложной обработки, которая определяла исходное подмножество клиентов.
ПРИМЕЧАНИЕ Обратите внимание, что исключительная простота таблиц
исследуемых групп позволяет комбинировать их с операциями объединения,
пересечения и вычитания множеств. Например, набор проблемных клиентов
в этом месяце можно пересечь с набором проблемных клиентов за прошлый
месяц, чтобы определить клиентов, у которых были проблемы в течение двух
месяцев подряд.
Измерение «Шаг» для последовательного поведения
В большинстве систем DW/BI нет хороших примеров последовательных процессов. Обычно замеры проводятся в определенном месте в виде наблюдения за потоком проходящих мимо покупателей или товаров. Последовательные замеры,
напротив, должны сопровождать клиента или продукт через ряд шагов, часто измеряемых различными системами сбора данных. Возможно, наиболее знакомый
пример последовательного процесса — веб-события, когда сеанс создается путем сбора отдельных событий страницы на нескольких веб-серверах, связанных
вместе с помощью файлов cookie клиента. Понимание того, где отдельный шаг
вписывается в общую последовательность, — серьезная проблема при анализе
последовательных процессов.
Введя измерение «Шаг», вы можете поместить отдельный шаг в контекст общего сеанса, как показано на рис. 8-11.
Пример строк измерения шагов
Таблица фактов транзакции
Ключ даты транзакции (FK)
Ключ клиента (FK)
Ключ сессии (FK)
Номер транзакции (DD)
Ключ шага сессии (FK)
Ключ шага покупки (FK)
Ключ шага выхода (FK)
Другие ключи …
Факты…
Измерение «Шаг» (3 роли)
Ключ шага (PK)
Общее количество шагов
Количество шагов
проделанных
Осталось шагов
Общее
Количество Осталось
Ключ количество
шагов
шагов
шага
шагов
проделанных
1
1
0
1
2
2
1
1
2
2
0
3
4
3
1
2
3
2
1
5
6
3
3
0
7
4
1
3
8
4
2
2
4
3
1
9
10
4
4
0
Рис. 8-11. Измерение «Шаг» для записи последовательных действий
Измерение «Шаг» — это абстрактное измерение, определенное заранее.
Первая строка в измерении используется только для одноэтапных сеансов, где
Управление взаимоотношениями с клиентами
321
текущий шаг первый и больше шагов не осталось. Следующие две строки в измерении шага используются для двухэтапных сеансов. Первая строка (ключ
шага = 2) предназначена для шага № 1, где нужно сделать еще один шаг, а следующая (ключ шага = 3) — для шага № 2, где больше нет шагов. Измерение «Шаг»
может быть предварительно настроено для размещения сеансов, состоящих
не менее чем из 100 шагов. На рис. 8-11 вы видите, что измерение «Шаг» может
быть связано с таблицей фактов транзакции, и ее основа — событие отдельной
страницы. В этом примере измерение шага выполняет три роли. Первая роль —
это общая сессия. Вторая роль — это подсессия успешной покупки, где последовательность событий страницы приводит к подтвержденной покупке. Третья
роль — брошенная корзина покупок, где последовательность событий страницы
завершается без покупки.
Используя измерение «Шаг», конкретная страница может быть немедленно
помещена в один или несколько понятных контекстов (общий сеанс, успешная
покупка и оставленная корзина покупок). Но что еще более интересно, запрос
может ограничиваться исключительно первой страницей успешных покупок.
Это классический запрос веб-события, где идентифицируется страница аттрактанта успешных сеансов. И наоборот, запрос может ограничиваться исключительно последней страницей брошенных корзин с покупками, где клиент вот-вот
решит отправиться в другое место.
Другой подход к моделированию последовательного поведения использует
преимущества определенных фиксированных кодов для каждого возможного шага. Если вы отслеживаете покупки товаров клиентами в розничной среде
и если каждый товар может быть закодирован, например в виде 5-значного номера, то вы можете создать один столбец с широким текстом для каждого клиента
с последовательностью кодов товаров. Вы разделяете коды уникальным нечисловым символом. Такая последовательность может выглядеть следующим образом
11254-45882-53340-74934-21399-93636-36217-87952|… и т. д.
Теперь, используя подстановочные знаки, вы можете искать конкретные товары, купленные последовательно, или купленные с вмешательством других товаров, или ситуации, в которых один товар был куплен, а другой нет. Современные реляционные СУБД могут хранить и обрабатывать широкие текстовые поля
объемом 64 000 символов и более с помощью поиска по шаблону.
Таблицы фактов временного интервала
В более оперативных приложениях может потребоваться получить точный статус
клиента в какой-то произвольный момент в прошлом. Подозревался ли клиент
банка в мошенничестве, когда ему было отказано в предоставлении кредита?
Как долго он был на расследовании в связи с мошенничеством? Сколько раз
322
Глава 8
за последние два года он был заподозрен в мошенничестве? Сколько клиентов
были заподозрены в мошенничестве в какой-то момент за последние два года?
Все эти вопросы можно решить, если вы тщательно управляете таблицей фактов транзакций, содержащей все события клиента. Ключевой этап моделирования — включение пары меток даты/времени, как показано на рис. 8-12. Первая
отметка даты/времени — это точный момент транзакции, а вторая — точный
момент следующей транзакции. Если это сделано правильно, то в истории транзакций клиентов сохраняется непрерывная последовательность отметок даты/
времени без пробелов. Каждая фактическая транзакция позволяет вам связать
как демографические данные, так и статус с клиентом. Плотные таблицы фактов
транзакций интересны тем, что вы потенциально можете изменять демографию
и особенно статус каждый раз, когда происходит транзакция.
Таблица фактов
транзакций клиента
Измерение «Дата»
Измерение «Демография»
Ключ даты транзакции (FK)
Ключ клиента (FK)
Ключ демографической
принадлежности (FK)
Ключ статуса (FK)
Номер транзакции (DD)
Другие ключи …
Эффективная дата/время
начала
Эффективная дата/время
окончания
Количество
Измерение «Клиент»
Измерение «Статус»
Рис. 8-12. Двойные метки даты/времени в таблице фактов временного
интервала
Критический момент заключается в том, что пара меток даты /времени для
отдельной транзакции определяет промежуток времени, в течение которого демография и статус постоянны. Запросы могут воспользоваться этим «тихим»
промежутком времени. Таким образом, если вы хотите узнать, каков был статус
клиента «Джейн Смит» 18 июля 2013 года в 6:33 утра, вы можете задать следующий запрос:
Select Customer.Customer_Name, Status
From Transaction_Fact, Customer_dim, Status_dim
Where Transaction_Fact_Customer_Key = Customer_dim.Customer_key
And Transaction_Fact.Status_key = Status_dim.Status_key
Управление взаимоотношениями с клиентами
323
And Customer_dim.Customer_Name = 'Jane Smith'
And #July 18, 2013 6:33:00# >=
Transaction_Fact.Begin_Eff_DateTime
And #July 18, 2013 6:33:00# < Transaction_Fact.End_Eff_DateTime
Эти метки даты / времени можно использовать для выполнения сложных запросов в вашей клиентской базе. Если вы хотите найти всех клиентов, которые
были заподозрены в мошенничестве в 2013 году, отправьте следующий запрос:
Select Customer.Customer_Name
From Transaction_Fact, Customer_dim, Status_dim
Where <joins>
And Status_dim Status_Description = 'Fraud Alert'
And Transaction_Fact.Begin_Eff_DateTime <= 12/31/2013:23:59:59
And Transaction_Fact.End_Eff_DateTime >= 1/1/2013:0:0:0
Удивительно, но этот запрос обрабатывает все возможные случаи вступившей в силу даты/времени начала и окончания, относящиеся к началу или концу
2013 года, полностью содержащиеся в 2013 году или полностью охватывающие
2013 год.
Вы даже можете подсчитать, сколько дней каждый клиент был заподозрен
в мошенничестве в 2013 году:
Select Customer.Customer_Name,
sum(least(12/31/2013:23:59:59, Transaction_Fact.End_Eff_DateTime)
- greatest(1/1/2013:0:0:0, Transaction_Fact.Begin_Eff_DateTime))
From Transaction_Fact, Customer_dim, Status_dim
Where <joins>
And Status_dim Status_Description = 'Fraud Alert'
And Transaction_Fact.Begin_Eff_DateTime <= 12/31/2013:23:59:59
And Transaction_Fact.End_Eff_DateTime >= 1/1/2013:0:0:0
Group By Customer.Customer_Name
За кулисами с двойными отметками даты/времени
Для такого клиента отметки даты/времени в последовательности транзакций
должны образовывать идеальную непрерывную последовательность без пробелов. Заманчиво сделать конечную отметку даты /времени вступления строки
в силу на один «тик» меньше, чем начальная отметка даты /времени вступления
в силу следующей транзакции, чтобы SQL-запрос мог использовать синтаксис
324
Глава 8
«МЕЖДУ», а не более трудночитаемые ограничения, показанные выше. Однако
во многих ситуациях небольшой разрыв, определенный как «тик», может быть
значительным, если транзакция может попасть в этот разрыв. Делая конечную
дату/время вступления в силу точно равными дате/времени начала следующей
транзакции, вы устраняете этот риск.
Использование пары меток даты/времени требует двухэтапного процесса
всякий раз, когда вводится новая строка транзакции. На первом этапе отметка
даты/времени окончания самой текущей транзакции должна быть установлена
на фиктивную дату/время в далеком будущем. Хотя было бы семантически правильно вставить NULL для этой даты/времени, неопределенные значения (Null)
становятся головной болью, когда вы сталкиваетесь с ними в ограничениях: они
могут вызвать ошибку базы данных, когда вы спрашиваете, равно ли поле определенному значению. Используя фиктивную дату/время в далеком будущем, этой
проблемы можно избежать.
На втором этапе, после ввода новой транзакции в базу данных, процесс ETL
должен извлечь предыдущую транзакцию и установить ее отметку даты/времени окончания действия на дату/время вновь введенной транзакции. Хотя двухэтапный процесс является заметной издержкой этого двойного подхода к дате/
времени, это классический и желательный компромисс между дополнительными
накладными расходами ETL «за кулисами» и снижением сложности запросов
для пользователей системы.
Пометка таблиц фактов показателями
удовлетворенности
Хотя прибыльность может быть наиболее важным ключевым показателем эффективности во многих организациях, удовлетворенность клиентов занимает второе
место. А в организациях, не имеющих показателей прибыли, таких как государственные учреждения, удовлетворенность является (или должна быть) номером
один.
Удовлетворенность, как и прибыльность, требует интеграции многих источников. Практически каждый процесс, с которым сталкивается клиент, — это
потенциальный источник информации об удовлетворенности, будь то продажи,
возвраты, поддержка клиентов, выставление счетов, активность на сайте, социальные сети или даже данные о геопозиционировании.
Данные об удовлетворенности могут быть как числовыми, так и текстовыми.
В главе 6 вы видели, как классические показатели удовлетворенности клиентов
могут быть смоделированы обоими способами одновременно. Показатели времени выполнения могут быть как дополнительными числовыми фактами, так
и текстовыми атрибутами в измерении «Уровень обслуживания». Другие чисто
Управление взаимоотношениями с клиентами
325
числовые показатели удовлетворенности включают количество возвратов товаров, количество потерянных клиентов, количество звонков в службу поддержки
и показатели отношения к продукту из социальных сетей.
Рис. 8-13 иллюстрирует измерение «Удовлетворенность» часто летающих
пассажиров, которое может быть добавлено в таблицы фактов о полетной деятельности, описанные в главе 12. Текстовые данные об удовлетворенности, как
правило, моделируются двумя способами в зависимости от количества атрибутов удовлетворенности и разреженности поступающих данных. Когда список
атрибутов удовлетворенности ограничен и достаточно стабилен, позиционный
дизайн очень эффективен, как показано на рис. 8-13.
Измерение удовлетворенности
Ключ удовлетворенности (PK)
Индикатор задержки рейса
Индикатор перенаправления в другой аэропорт
Индикатор потери багажа
Индикатор апгрейда места в самолете
Индикатор сиденья в центре
Индикатор проблем с обслуживающим персоналом
Рис. 8-13. Измерение «Удовлетворенность»
для часто летающих пассажиров авиакомпаний
Пометка таблиц фактов индикаторами
ненормальных сценариев
Накопительные таблицы фактов моментальных снимков зависят от ряда дат, которые реализуют стандартный сценарий для конвейерного процесса. Для выполнения заказа у вас могут быть этапы создания, отправки, доставки, оплаты заказа
и его возврата в качестве стандартных шагов в сценарии. Такой дизайн успешен,
когда 90 или более процентов заказов проходят эти этапы (надеюсь, без возврата)
без каких-либо необычных исключений.
Но если случайная ситуация отклоняется от стандартного сценария, у вас нет
подходящего способа рассказать, что произошло. Например, возможно, когда заказ был отправлен, у грузовика доставки была неисправная шина. Было принято
решение разгрузить груз на другой грузовик, но, к сожалению, начался дождь,
и груз был поврежден водой. Затем заказчик отказался от него, и в итоге возник
судебный процесс. Ни один из этих необычных шагов не моделируется в стандартном сценарии в накопительном снимке. И не должен!
Способ описания необычных отклонений от стандартного сценария заключается в добавлении измерения «Статус доставки» в накопительную таблицу
326
Глава 8
фактов моментальных снимков. В случае странного сценария доставки вы помечаете эту строку выполнения заказа статусом «Странно». Затем, если аналитик
хочет просмотреть полную историю, он может присоединиться к сопутствующей
таблице фактов транзакции с помощью номера заказа и номера строки, в которой
указан каждый шаг истории. Таблица фактов транзакции присоединяется к измерению «Транзакция», в котором действительно есть «Проколотая шина»,
«Поврежденный груз» и «Судебный процесс» в качестве транзакций. Хотя измерение «Транзакция» со временем будет расти из-за необычных записей, оно
хорошо ограничено и стабильно.
Подходы к интеграции клиентских данных
В типичных средах со многими процессами, связанными с клиентами, вам необходимо выбрать один из двух подходов: одно измерение «Клиент», полученное
из всех версий записей исходной системы клиента, или несколько измерений
«Клиент», связанных вместе согласованными атрибутами.
Управление основными данными при создании единого
измерения «Клиент»
В некоторых случаях вы можете создать одно измерение «Клиент», который
станет лучшим в своем роде выбором среди множества доступных источников
данных о клиентах. Вполне вероятно, что такое согласованное измерение «Клиент» представляет собой перегонку данных из нескольких операционных систем
вашей организации. Но для уникального клиента было бы типично иметь несколько идентификаторов в различных системах, с которыми он работает. Что
еще хуже, системы ввода данных часто не содержат адекватных правил проверки.
Очевидно, что цель операционной CRM — создание уникального идентификатора клиента и ограничение создания ненужных идентификаторов. Тем временем команда DW/BI, скорее всего, будет отвечать за сортировку и интеграцию
разрозненных источников информации о клиентах.
Некоторым организациям посчастливилось иметь централизованную систему управления основными данными (MDM), которая берет на себя ответственность за создание и управление единой на уровне организации записью о клиенте. Но такая централизация редко встречается в реальном мире. Чаще всего
хранилище данных извлекает несколько несовместимых файлов данных о клиентах и создает «нижестоящую» систему MDM. Эти два стиля MDM проиллюстрированы на рис. 8-14.
К сожалению, секретного оружия для решения этой проблемы консолидации
данных не существует. Атрибуты в измерении «Клиент» должны представлять
Управление взаимоотношениями с клиентами
327
лучший источник, доступный на предприятии. Национальный процесс изменения адреса (NCOA) должен быть интегрирован для обеспечения учета изменений адреса. Большая часть тяжелой работы, связанной с консолидацией клиентских данных, требует логики сопоставления, или дедупликации клиентов.
Удаление дубликатов или недействительных адресов из больших списков клиентов имеет решающее значение для устранения затрат, связанных с избыточной,
неправильно направленной или недоставленной связью, для предотвращения
ложного подсчета клиентов и повышения удовлетворенности клиентов за счет
более качественной связи.
Корпоративная
MDM
Операционное
приложение #1
Операционное
приложение #1
Операционное
приложение #2
Операционное
приложение #3
Операционное
приложение #2
EDW
Операционное
приложение #3
«Нижестоящая»
MDM
EDW
Рис. 8-14. Два стиля управления основными данными
Наука подбора клиентов более сложна, чем может показаться на первый
взгляд. Она включает в себя нечеткую логику, алгоритмы анализа адресов
и огромные поисковые каталоги для проверки элементов адреса и почтовых индексов, которые значительно различаются в зависимости от страны. Существуют
специализированные, коммерчески доступные программные и сервисные предложения, которые выполняют сопоставление отдельных клиентов или коммерческих организаций с поразительной точностью. Часто эти продукты сопоставляют
компоненты адресов со стандартизированными кодами переписи, такими как
коды штатов, коды стран, участки переписи, группы блоков, столичные статистические районы (MSAS) и широта/долгота, что облегчает объединение внешних
328
Глава 8
данных. Как обсуждалось в главе 10, существуют также возможности ручного
управления для группировки или связи клиентов, имеющих сходную информацию об имени и/или адресе. Вместо того чтобы просто выполнять внутреннее
сопоставление файлов, некоторые службы поддерживают огромный внешний
справочный файл всех жителей Соединенных Штатов для сопоставления. Хотя
эти продукты и услуги дорогостоящие и/или сложные, в их разработку стоит
вкладываться, если подбор клиентов имеет стратегическое значение для организации. В конечном счете эффективная консолидация данных клиентов зависит
от баланса максимально точного сбора данных в исходных системах в сочетании
с мощными инструментами очистки/объединения данных в процессе ETL.
Частичная согласованность нескольких
измерений «Клиент»
Сегодня предприятия создают хранилища знаний о клиентах, которые собирают
все внутренние и внешние источники данных, касающиеся клиентов, которые
они могут найти. Крупная организация может иметь до 20 внутренних источников данных и 50 или более внешних источников данных, все из которых так или
иначе связаны с клиентом. Эти источники могут сильно различаться по степени
детализации и согласованности. Конечно, не существует гарантированного высококачественного ключа клиента, определенного во всех этих источниках данных,
и нет согласованных атрибутов. У вас нет никакого контроля над этими источниками. Это похоже на безнадежный беспорядок.
В главе 4 мы заложили основу для согласованных измерений — необходимого
связующего звена для достижения интеграции между отдельными источниками
данных. В идеальном случае вы изучаете все источники данных и определяете
одно всеобъемлющее измерение, которое вы прикрепляете ко всем источникам
данных либо одновременно в одном табличном пространстве, либо путем репликации в нескольких табличных пространствах. Такое единое всеобъемлющее
согласованное измерение становится прекрасным драйвером для создания интегрированных запросов, анализов и отчетов, предоставляя согласованные метки
строк, доступные для детализации запросов.
Но в мире экстремальной интеграции с десятками измерений, связанных
с клиентами, разной степени зернистости и разного качества, такое единое
комплексное измерение «Клиент» невозможно создать. К счастью, вы можете
реализовать более легковесную версию в соответствии с размерами заказчика.
Помните: основное требование для согласованности двух измерений — то, что
они совместно используют один или несколько специально управляемых атрибутов, которые имеют одинаковые имена столбцов и значения данных. Не нужно,
чтобы десятки измерений, связанных с клиентами, были идентичными, — вам
Управление взаимоотношениями с клиентами
329
требуется, чтобы они использовали только специально управляемые соответствующие атрибуты.
Вы не только сняли нагрузку с хранилища данных, ослабив требование, чтобы все измерения «Клиент» в вашей среде были одинаковыми сверху донизу,
но и можете постепенно и гибко внедрять специально управляемые соответствующие атрибуты в каждое из измерений, связанных с клиентами. Например,
предположим, что вы начинаете с определения довольно высокоуровневой классификации клиентов, называемой «Категория клиента». Вы можете методично
начать работу со всеми измерениями «Клиент», добавляя этот атрибут в каждое
измерение, не изменяя зернистость какого-либо целевого измерения и не делая
недействительными любые существующие приложения, зависящие от этих измерений. С течением времени вы постепенно расширяете область интеграции,
добавляя специальные атрибуты в отдельные измерения «Клиент», прикрепленные к различным источникам. В любой момент вы можете остановиться
и выполнить детализацию отчетов, используя измерения, в которые вы вставили
атрибут категории клиентов.
Когда атрибут «Категория клиента» будет интегрирован в как можно большее количество измерений, связанных с клиентами, вы сможете определить более согласованные атрибуты. Географические атрибуты, такие как город, округ,
штат и страна, должны быть еще проще, чем «Категория клиента». С течением
времени объем и мощь согласованного измерения «Клиент» позволяют проводить все более сложные анализы. Это постепенное развитие с его сразу же заметными результатами обеспечивает гибкий подход.
Избегание соединений таблицы фактов
с таблицами фактов
Системы DW/BI должны строиться от процесса к процессу, а не от отдела к отделу, на основе согласованных измерений для поддержки интеграции. Вы можете
представить себе запрос таблиц фактов продаж или поддержки, чтобы лучше понять историю покупок или услуг клиентов.
Поскольку таблицы продаж и поддержки содержат внешний ключ клиента, вы
можете дополнительно представить объединение обеих таблиц фактов в общее
измерение «Клиент», чтобы одновременно суммировать факты продаж вместе
с фактами поддержки для данного клиента. К сожалению, соединение «многие
к одному ко многим» вернет неправильный ответ в реляционной среде из-за различий в кардинальности таблицы фактов, даже если реляционная база данных
работает идеально. Не существует комбинации внутренних, внешних, левых или
правых соединений, которая давала бы желаемый ответ, когда две таблицы фактов имеют несовместимые кардинальности.
330
Глава 8
Рассмотрим случай, когда у вас есть таблица фактов с предложениями клиентов и другая таблица фактов с ответами клиентов на предложения, как показано
на рис. 8-15. Существует взаимосвязь «один ко многим» между клиентом и взятием его в работу, а также другая взаимосвязь «один ко многим» между клиентом
и ответом. Таблицы фактов взятия в работу и ответа имеют различную мощность;
другими словами, не каждое взятие в работу приводит к ответу (к сожалению для
отдела маркетинга), а также поступают ответы, на которые не было предложения.
Одновременное присоединение таблицы фактов взятия в работу к измерению
«Клиент», которое, в свою очередь, присоединено к таблице фактов ответов,
не возвращает правильный ответ в реляционной СУБД из-за различий в кардинальности. К счастью, этой проблемы легко избежать. Вы просто используете метод
детализации, описанный в главе 4, для запроса таблицы взятия в работу и таблицы
ответов в отдельных запросах, а затем объединяете два набора ответов. Такой «горизонтальный» подход имеет некоторые преимущества для контроля параметров
производительности в дополнение к поддержке запросов, которые объединяют
данные из таблиц фактов в разных физических местоположениях.
Таблица фактов
предложения клиента
Ключ даты предложения (FK)
Ключ клиента (FK)
Другие ключи …
Факты предложения …
Измерение «Клиент»
Ключ клиента (PK)
ID клиента (Естественный ключ)
...
Таблица фактов
ответов клиента
Ключ даты ответа (FK)
Ключ клиента (FK)
Другие ключи …
Факты ответа …
Рис. 8-15. Объединенные таблицы «Многие к одному ко многим» не следует
запрашивать с помощью одного оператора SELECT
Будьте очень осторожны при одновременном соединении одной таблицы измерений с двумя таблицами фактов разной кардинальности. Во многих случаях реляционные механизмы возвращают неверный ответ.
ПРЕДУПРЕЖДЕНИЕ
Если бизнес-пользователи часто объединяют данные из нескольких бизнеспроцессов, окончательный подход заключается в определении дополнительной
таблицы фактов, которая объединяет данные один раз в консолидированную
таблицу фактов, вместо того чтобы полагаться на пользователей, которые последовательно и точно объединяют данные самостоятельно, как описано в главе 7. Простое использование SQL для горизонтального прохода таблиц фактов
для объединения результатов имеет больше смысла, когда базовые процессы
менее тесно взаимосвязаны. Конечно, при построении сводной таблицы фактов вам все равно необходимо установить бизнес-правила для учета различий
Управление взаимоотношениями с клиентами
331
в кардинальности. Например, включает ли консолидированная таблица фактов
все взятия клиента в работу и ответы или только те, в которых имели место как
взятие в работу, так и ответ?
Проверка реальности с низкими задержками
Поведение клиента в последние несколько часов или минут может быть чрезвычайно интересным. Возможно, вы даже захотите принимать решения, общаясь
с клиентом в режиме реального времени. Но вам нужно быть внимательным,
осознавая затраты и ограничения, связанные с данными с низкой задержкой.
Как правило, качество данных ухудшается по мере того, как данные передаются
ближе к реальному времени.
Бизнес-пользователи могут автоматически подумать, что чем быстрее информация поступает в систему DW/BI, тем лучше. Но уменьшение задержки
увеличивает проблемы с качеством данных. На рис. 20-6 кратко представлены
проблемы, возникающие при более быстрой доставке данных. В обычном мире
пакетной загрузки данных, возможно, загружая пакетный файл раз в 24 часа, вы
обычно получаете полные наборы транзакций. Например, если коммерческий
клиент размещает заказ, ему, возможно, придется пройти проверку кредитоспособности и подтвердить окончательное обязательство. Пакетная загрузка включает заказы только в том случае, если все эти шаги были выполнены. Кроме того,
поскольку пакетная загрузка обрабатывается только один раз каждые 24 часа,
у команды ETL есть время для полного спектра проверок качества данных, как
мы опишем в главе 19.
Если данные извлекаются много раз в день, то, возможно, придется отказаться от гарантии полного набора транзакций. Возможно, клиент разместил заказ,
но не прошел проверку кредитоспособности. Таким образом, существует вероятность, что результаты, возможно, придется корректировать постфактум. Вы также можете не выполнять полный спектр проверок качества данных, поскольку
у вас нет времени для подробного поиска в нескольких таблицах.
Наконец, возможно, вам придется разместить данные в хранилище данных,
если не все ключи были найдены в соответствующих родительских таблицах.
В этом случае может потребоваться использовать временные записи об измерениях в ожидании дополнительных потоков данных. Наконец, если вы доставляете данные мгновенно, вы можете получать только фрагменты транзакций, и у вас
может не быть времени для выполнения каких-либо проверок качества данных
или другой обработки данных.
Доставка данных с низкой задержкой может быть очень ценной, но бизнес-пользователи должны быть проинформированы об этих компромиссах.
332
Глава 8
Интересный гибридный подход заключается в обеспечении доставки с низкой
задержкой в течение дня, но затем возвращается к пакетной перезагрузке ночью,
тем самым исправляя различные проблемы с данными, которые не могли быть
решены в течение дня. Мы обсудим влияние требований к низкой задержке
на систему ETL в главе 20.
Выводы
В этой главе мы сосредоточились исключительно на клиентах, начав с обзора основ управления взаимоотношениями с клиентами (CRM). Затем мы углубились
в вопросы проектирования, связанные с измерением «Клиент». Мы обсудили
синтаксический анализ имен и адресов, при котором операционные поля разбиваются на их основные элементы, чтобы их можно было стандартизировать
и проверить. Мы исследовали несколько других типов общих атрибутов измерения «Клиент», таких как даты, атрибуты сегментации и агрегированные факты.
Были описаны выносные внешние измерения, которые содержат большой блок
атрибутов относительно низкой кардинальности.
В этой главе рассказывалось об использовании соединительных таблиц для
обработки непредсказуемых, трудноопределимых атрибутов измерений, а также многозначных атрибутов конкретных измерений. Мы также исследовали
несколько сложных сценариев поведения клиентов, включая последовательные
действия, таблицы фактов с временным интервалом и пометку событий фактов
индикаторами для выявления ненормальных ситуаций.
Мы завершили главу обсуждением альтернативных подходов к последовательной идентификации клиентов и консолидации богатого набора характеристик из исходных данных либо с помощью оперативного управления основными
данными, либо последующей обработки в закулисье ETL с потенциально частичным согласованием. Наконец, мы коснулись проблем, связанных с требованиями
к данным с низкой задержкой.
9
Управление
персоналом
Э
та глава, посвященная данным о персонале (HR), — последняя в серии,
посвященной межотраслевым бизнес-приложениям. Подобно данным бухгалтерского учета и финансов, описанным в главе 7, информация о кадрах широко распространяется по всей организации. Организации хотят лучше понять
демографию, навыки, доходы и производительность своих сотрудников, чтобы
максимизировать их влияние. В этой главе мы рассмотрим несколько методов
размерного моделирования в контексте кадровых данных.
В главе 9 рассматриваются следующие концепции:
■ таблицы измерения для отслеживания изменений профиля сотрудника;
■ периодические снимки численности персонала;
■ матрица шин для фрагмента процессов, ориентированных на управление
персоналом;
■ плюсы и минусы комплексных решений DW/BI или моделей данных;
■ рекурсивные иерархии сотрудников;
■ многозначные атрибуты ключевых навыков, обрабатываемые с помощью
атрибутов измерений, внешних выносных измерений и соединительных
таблиц;
■ опросные данные;
■ текстовые комментарии.
Отслеживание профиля сотрудников
До сих пор разрабатываемые нами размерные модели были очень похожи друг на друга; таблицы фактов содержали ключевые показатели производительности, которые
обычно можно добавлять по всем измерениям. Разработчикам размерных моделей
легко погрузиться в своего рода аддитивное самодовольство. В большинстве случаев
именно так все и должно работать. Однако в случае с данными о сотрудниках, требуемыми отделом кадров, надежное измерение «Сотрудник» необходимо бизнесу.
334
Глава 9
Чтобы сформулировать проблему коротко, давайте предположим, что вы работаете в отделе кадров крупного предприятия. У каждого сотрудника есть подробный профиль персонала, содержащий не менее 100 атрибутов, включая дату
приема на работу, класс работы, зарплату, даты проверки, результаты проверки,
право на отпуск, организацию, образование, адрес, страховой план и многие другие. Сотрудники постоянно нанимаются, переводятся и продвигаются по службе, а также корректируют свои профили различными способами.
Приоритетное бизнес-требованием — точное отслеживание и анализ изменений профиля сотрудника. Вы можете сразу же визуализировать схему, в которой
каждое событие изменения профиля сотрудника фиксируется в таблице фактов
с детализацией транзакций, как показано на рис. 9-1. Детализация этой несколько обобщенной таблицы фактов будет составлять одну строку на транзакцию
профиля сотрудника. Поскольку никакие числовые показатели не связаны с изменениями, внесенными в профили сотрудников, такими как новый адрес или
повышение по службе, таблица фактов не содержит фактов.
Таблица фактов
транзакций сотрудников
Измерение «Сотрудник»
Ключ сотрудника (PK)
ID сотрудника (NK)
...
Ключ даты транзакции (FK)
Дата/Время транзакции
Ключ сотрудника (FK)
Ключ типа «Транзакции
сотрудника» (FK)
Измерение «Дата транзакции»
Измерение «Тип транзакции сотрудника»
Ключ типа «Транзакции сотрудника» (PK)
Описание типа транзакции сотрудника
1 строка на транзакцию
профиля сотрудника
Рис. 9-1. Первоначальный проект схемы для отслеживания изменений
в профиле сотрудников
В этом проекте схемы измерения включают дату транзакции, тип транзакции
и сотрудника. Измерение «Тип транзакции» относится к коду причины, вызвавшей создание этой конкретной строки, например повышение по службе или
изменение адреса. Измерение «Сотрудник» чрезвычайно обширно и содержит
множество столбцов атрибутов.
Мы предполагаем использовать метод медленно меняющихся параметров
типа 2 для отслеживания измененных атрибутов профиля в измерении «Сотрудник». Следовательно, с каждой транзакцией профиля сотрудника в таблице
фактов на рис. 9-1 вы также создадите новую строку типа 2 в измерении «Сотрудник», которая представляет профиль сотрудника в результате события изменения профиля. Эта новая строка продолжает точно описывать сотрудника
Управление персоналом
335
до тех пор, пока следующая транзакция с сотрудником не произойдет в неопределенное время в будущем. Внимательный читатель быстро заметит, что таблица
фактов транзакции профиля сотрудника и таблица измерения «Сотрудник»
типа 2 имеют одинаковое количество строк; плюс они почти всегда соединены
друг с другом. На этом этапе должны сработать сигналы тревоги при моделировании измерений. Вы, конечно, не хотите иметь столько строк в таблице фактов,
сколько в таблице связанных измерений.
Вместо использования исходной схемы вы можете упростить дизайн, украсив
таблицу измерения «Сотрудник», чтобы сделать ее более мощной и тем самым
отказаться от таблицы фактов для событий с транзакциями каждого профиля.
Как показано на рис. 9-2, измерение «Сотрудник» содержат снимок характеристик профиля сотрудника после изменения этого профиля. Описание типа транзакции становится атрибутом причины изменения в измерении «Сотрудник»
для отслеживания причины изменения профиля. В некоторых случаях соответствующие характеристики числовые. Если числовые атрибуты суммируются,
а не просто ограничиваются, вместо этого они относятся к таблице фактов.
Измерение «Сотрудник»
Ключ сотрудника (PK)
ID сотрудника (NK)
Имя сотрудника …
Адрес сотрудника …
Класс работы …
Зарплата …
Образование …
Дата приема на работу (FK)
Дата последнего пересмотра (FK)
Оценочный рейтинг …
План медицинского страхования …
План отпусков …
Код изменения причины
Описание причины изменения
Дата/время вступления строки в силу
Дата/время истечения действия строки
Индикатор текущей строки
Рис. 9-2. Измерение «Сотрудник» с профильными характеристиками
Как и следовало ожидать, суррогатный ключ сотрудника — это первичный
ключ таблицы измерений; устойчивый натуральный идентификатор сотрудника,
используемый в операционной системе HR для постоянной идентификации сотрудника, включен в качестве атрибута измерения.
336
Глава 9
Точное время вступления в силу и истечения
срока действия
Как обсуждалось в главе 5, с охватом методов медленно меняющихся измерений
вам следует включить два столбца в измерение «Сотрудник», чтобы определить,
когда конкретная строка актуальна, а когда нет. Эти столбцы определяют точный
промежуток времени, в течение которого профиль сотрудника достоверен. Исторически сложилось так, что, когда ежедневная задержка данных была нормой,
столбцы вступления в силу и истечения срока действия имели тип «Дата». Однако, если вы загружаете данные из какого-то бизнес-процесса чаще, в столбцах
должны быть отметки даты/времени, чтобы вы могли связать соответствующую
строку профиля сотрудника, которая может отличаться между 9 утра и 9 вечера
в тот же день, с операционными событиями.
Атрибут истечения срока действия для текущей строки устанавливается
на будущую дату. Когда срок действия строки истекает из-за того, что система
ETL обнаружила новый набор атрибутов, для атрибута истечения срока действия обычно устанавливается значение «Непосредственно перед» вступления
в силу новой строки, что означает предыдущий день, минуту, секунду.
Если профиль сотрудника был изменен в течение определенного периода, а затем сотрудник возвращается к более раннему набору характеристик, вставляется
новая строка в измерение «Сотрудник». Вы не должны поддаваться желанию
просто вернуться к предыдущей строке профиля и изменить дату истечения срока
действия, поскольку несколько строк измерений будут иметь силу одновременно.
Индикатор текущей строки позволяет быстро получить последний статус любого сотрудника. Если для этого сотрудника появляется новая строка профиля,
необходимо обновить индикатор в предыдущей строке профиля, чтобы указать,
что этот профиль больше не текущий.
Само по себе измерение «Сотрудник» типа 2 с отметкой даты/времени отвечает на ряд интересных запросов отдела кадров. Вы можете выбрать точный
исторический момент и спросить, сколько у вас сотрудников и каковы были их
подробные профили на тот конкретный момент, ограничив дату/время, чтобы
оно было равно или больше даты/времени вступления в силу и строго меньше
даты/времени истечения срока действия. Запрос может выполнять подсчеты
и ограничения для всех строк, возвращаемых из этих ограничений.
Отслеживание причин изменения параметров
Если строка измерения содержит атрибуты типа 2, вы можете добавить в нее
причину изменения. Таким образом, некоторые метаданные, ориентированные на ETL, встраиваются в фактические данные. Атрибут причины изменения
Управление персоналом
337
может содержать двухсимвольную аббревиатуру для каждого измененного атрибута в строке измерения. Например, значение атрибута причины изменения для
изменения фамилии может быть LN или более разборчивым значением, таким
как «Фамилия», в зависимости от предполагаемого использования и аудитории.
Если кто-то спросит, сколько людей изменили почтовые индексы в прошлом
году, оператор SELECT будет включать оператора LIKE и подстановочные знаки, такие как «WHERE ChangeReason LIKE ' %ZIP %'».
Поскольку несколько атрибутов измерения могут изменяться одновременно
и быть представлены одной новой строкой в измерении, причина изменения
будет многозначной. Как мы рассмотрим позже в этой главе при обсуждении
навыков сотрудников, коды нескольких причин могут обрабатываться как один
атрибут текстовой строки, такой как «|Фамилия|Почтовый индекс|» или с помощью многозначной соединительной таблицы.
ПРИМЕЧАНИЕ Метки даты/времени вступления в силу и истечения срока
действия, а также описание кода причины в каждой строке медленно изменяющегося параметра типа 2 позволяют очень точно делать срез по времени.
Наконец, изменения профиля сотрудника могут быть зафиксированы в базовой исходной системе с помощью набора микротранзакций, соответствующих
каждому отдельному изменению атрибута сотрудника. В системе DW/BI вы
можете захотеть инкапсулировать серию микротранзакций из исходной системы и рассматривать их как супертранзакцию, такую как повышение по службе
сотрудника, потому что было бы глупо рассматривать эти искусственные микротранзакции как отдельные изменения типа 2. Новая строка измерения «Сотрудник» типа 2 будет отражать все соответствующие измененные атрибуты за один
шаг. Идентификация этих супертранзакций может быть сложной задачей. Очевидно, что лучший способ определить их — убедиться, что оперативное приложение HR отражает действия более высокого уровня.
Изменения профиля как атрибуты типа 2
или события факта
Мы только что описали обработку изменений атрибутов сотрудника как медленно изменяющиеся атрибуты измерения типа 2 с датами вступления в силу и датами истечения срока действия в измерении «Сотрудник». Разработчики иногда
искренне принимают этот шаблон и пытаются использовать его, чтобы отразить
каждое изменение, ориентированное на сотрудников. В результате получается
таблица измерения с потенциально сотнями атрибутов и миллионами строк для
организации со 100 000 сотрудников, учитывая изменчивость атрибутов.
338
Глава 9
Отслеживание изменений в таблице измерения «Сотрудник» позволяет легко связать точный профиль сотрудника с несколькими бизнес-процессами. Вы
просто загружаете эти таблицы фактов с ключом сотрудника, который имеет силу
на момент, когда произошло событие факта, и фильтруете и группируете на основе полного спектра атрибутов сотрудника.
Но маятник может качнуться слишком далеко. Вероятно, вам не следует использовать измерение «Сотрудник» для отслеживания каждого мероприятия по оценке производительности сотрудников, каждого мероприятия по участию в льготных
программах или каждого мероприятия по профессиональному развитию. Как показано на рис. 9-4 в матрице шины в следующем разделе, многие из этих событий
включают другие измерения, такие как дата события, организация, описание пособия, рецензент, утверждающий, интервьюер при выходе, причины увольнения,
и список можно продолжить. Следовательно, большинство из них следует обрабатывать как отдельные таблицы фактов, ориентированные на процесс. Хотя многие
события в области персонала не имеют конкретных фактов, их отражение в таблице фактов позволяет бизнес-пользователям легко подсчитывать или отслеживать
по периодам времени и всем другим связанным измерениям.
Безусловно, принято включать результаты этих кадровых мероприятий, таких как оценка должности в результате продвижения по службе, в качестве атрибута в измерении сотрудника. Но разработчики иногда ошибаются, добавляя
множество внешних ключей к выносным внешним измерениям для рецензента,
пособия, причины увольнения и других измерений в измерении «Сотрудник»,
что приводит к перегруженному измерению, в котором трудно ориентироваться.
Периодический снимок
численности персонала
В дополнение к изучению профилей сотрудников в отделе кадров вы также хотите регулярно сообщать о статусе сотрудников. Бизнес-менеджеров интересуют подсчеты, статистика и итоговые данные, включая количество сотрудников,
выплаченную заработную плату, взятые дни отпуска, начисленные дни отпуска,
количество новых сотрудников и количество повышений по службе. Они хотят
проанализировать данные по всем возможным срезам, включая время и организацию, а также характеристики сотрудников. Как показано на рис. 9-3, периодический снимок численности персонала состоит из обычной таблицы фактов
с тремя измерениями: месяц, сотрудник и организация. Таблица измерения
«Месяц» содержит обычные дескрипторы для корпоративного календаря
на уровне месяца. Ключ сотрудника соответствует строке измерения «Сотрудник», который имел силу в конце последнего дня данного отчетного месяца,
Управление персоналом
339
чтобы гарантировать, что отчет на конец месяца правильно отражает профили
сотрудников. Измерение «Организация» содержит описание организации,
к которой принадлежит сотрудник на конец соответствующего месяца, для анализа данных по всем возможным срезам, включая время и организацию, а также
характеристики сотрудника.
Таблица фактов численности
персонала в момент времени
Измерение «Организация»
Ключ месяца (FK)
Ключ организации (FK)
Ключ сотрудника (FK)
Количество сотрудников
Количество новых сотрудников
Количество переводов
Количество повышений
Выплаты зарплаты
Выплаты за переработки
Выплаты при выходе на пенсию
Вклад в фонд выплат выхода на пенсию
Запланированные дни отпуска
Использованные дни отпуска
Баланс дней отпуска
Измерение «Месяц»
Измерение «Сотрудник»
1 строка на сотрудника в месяц
Рис. 9-3. Пример организации численности персонала
Факты в этом моментальном снимке численности персонала состоят из ежемесячных числовых показателей и подсчетов, которые может быть трудно рассчитать только из таблицы измерения «Сотрудник». Эти ежемесячные подсчеты и показатели аддитивные по всем измерениям или атрибутам измерений,
за исключением любых фактов, помеченных как балансы. Эти остатки, как и все
остатки, полуаддитивные и должны быть усреднены по измерению месяца после
добавления по другим измерениям.
Матрица шин для HR-процессов
Хотя измерение «Сотрудник» с точным отслеживанием медленно меняющихся
измерений типа 2 в сочетании с ежемесячным периодическим снимком основных показателей эффективности работы с персоналом — хорошее начало, это
лишь вершина айсберга, когда дело доходит до отслеживания данных о кадрах.
На рис. 9-4 показаны другие процессы, которые специалисты по персоналу
и функциональные менеджеры, скорее всего, захотят проанализировать. Мы
340
Глава 9
Накапливающийся
X
Сотр
Мндж
X
X
Сотр
Мндж
X
бие
низа
ци я
к
X
Посо
Моментальный снимок должности
сотрудника
Орга
Периодический
Сотр
удни
Моментальный снимок должности
сотрудника
Долж
Тип факта
Дата
ност
ь
дополнили эту предварительную матрицу шины типом таблицы фактов, которая
может использоваться для каждого процесса; однако реалии ваших исходных
данных и бизнес-требования могут потребовать иной или дополнительной обработки.
Процесс приема на работу
X
Сотр
Мндж
Сотр
Мндж
X
Наем сотрудников
Транзакционный
X
X
Уже работающие сотрудники
Накапливающийся
X
X
Право на получение пособий
работникам
Периодический
X
X
X
X
Заявки на получение пособий
работникам
Накапливающийся
X
X
X
X
Участие в выплатах работникам
Периодический
X
X
X
X
Снимок численности персонала
Периодический
X
X
X
X
Компенсация работникам
Транзакционный
X
X
X
X
Начисления пособий работникам
Транзакционный
X
X
X
X
Оценка эффективности работы
сотрудника
Накапливающийся
X
Сотр
Мндж
X
X
Обзор эффективности работы
сотрудников
Транзакционный
X
Сотр
Мндж
X
X
Курсы повышения квалификации
для сотрудников
Транзакционный
X
X
X
Система дисциплинарных
взысканий сотрудников
Накапливающийся
X
Сотр
Мндж
X
Увольнения сотрудников
Транзакционный
X
Сотр
Мндж
X
X
Процесс выплаты премий
Процесс управления персоналом
Рис. 9-4. Строки матрицы шины для HR-процессов
Управление персоналом
341
Некоторые из этих бизнес-процессов отражают показатели эффективности,
но многие приводят к таблицам фактов без самих фактов, например, как право
на получение пособий или участие в выплатах работникам.
Комплексные аналитические
решения и модели данных
Многие организации приобретают решения поставщиков для удовлетворения
своих оперативных потребностей в области управления персоналом. Большинство из этих продуктов предлагают дополнительное решение DW/BI. Кроме
того, другие поставщики продают стандартные модели данных, иногда со встроенными загрузчиками данных для популярных продуктов HR-приложений.
Поставщики и сторонние организации утверждают, что эти стандартные готовые решения и модели обеспечивают более быструю и менее рискованную реализацию за счет сокращения объема моделирования данных и эффективности
разработки ETL. В конце концов, каждый отдел кадров нанимает сотрудников,
подписывает их на получение пособий, выплачивает им компенсации, проверяет их и в итоге обрабатывает увольнения сотрудников. Зачем изобретать колесо,
разрабатывая пользовательские модели данных и решения для поддержки этих
общих бизнес-процессов, когда вместо этого вы можете купить стандартную модель данных или комплексное решение?
Хотя, несомненно, существуют общие функции, особенно в сфере управления персоналом, предприятия, как правило, имеют уникальные особенности.
Чтобы справиться с этими нюансами, большинство поставщиков прикладного
программного обеспечения внедряют абстракции в свои продукты, которые позволяют их легче настраивать.
Эти абстракции, такие как таблица «Участники» и связанный с ней аппарат
для описания каждой роли или общих имен столбцов атрибутов, а не более значимых меток, обеспечивают гибкость для адаптации к различным бизнес-ситуациям.
Хотя адаптивность внедрения — преимущество для поставщиков, которые хотят,
чтобы их продукты учитывали широкий спектр бизнес-сценариев потенциальных
клиентов, недостаток таких решений — связанная с этим сложность.
Специалисты по персоналу, которые работают с продуктом поставщика
24 часа 7 дней в неделю, часто готовы скорректировать словарный запас своей
системы, чтобы приспособиться к новым абстракциям. Но эти абстракции могут
быть трудны к пониманию для менее погруженных в работу функциональных менеджеров. Предоставление данных бизнесу с помощью комплексного решения
DW/BI или стандартной отраслевой модели данных может обойти необходимые
переводы на язык бизнеса.
342
Глава 9
Помимо использования терминологии поставщика вместо включения бизнессловаря в решение DW/BI, еще один потенциальный острый угол — интеграция
исходных данных из других областей. Можете ли вы легко согласовать измерения
в решении поставщика или отраслевой модели с другими внутренними основными данными? Если нет, то поставленной как часть комплексного решения модели
суждено стать еще одним изолированным набором данных для узкоспециализированного использования. Очевидно, что такой результат непривлекателен; хотя
это может быть меньшим препятствием, если все ваши операционные системы
поддерживаются одним и тем же поставщиком ERP или вы небольшая организация без ИТ-отдела, занимающегося независимой разработкой.
Что вы можете реально ожидать получить от модели «из коробки»? Готовые универсальные модели могут помочь определить основные бизнес-процессы
и связать общие измерения. Это обеспечивает некоторый комфорт для команд
DW/BI, которые изначально чувствуют себя перегруженными задачей проектирования. После нескольких дней или недель изучения стандартной модели большинство команд приобретают достаточную уверенность, чтобы захотеть настроить схему для своих данных.
Однако стоят ли эти знания цены, связанной с коробочным решением или моделью данных? Скорее всего, вы могли бы получить такое же представление, проведя несколько недель с бизнес-пользователями. Вы не только улучшите свое понимание потребностей бизнеса, но и начнете подключать бизнес-пользователей
к инициативе DW/BI.
Также стоит отметить: тот факт, что модель «из коробки» или решение стоят тысячи долларов, не означает, что они демонстрируют общепринятые лучшие
практики размерного моделирования. К сожалению, некоторые стандартные
модели содержат в себе типичные ошибки моделирования; это неудивительно,
если разработчики модели больше сосредоточились на лучших практиках сбора
данных исходной системы, а не на тех, которые требуются для отчетности и аналитики BI. Сложно разработать заранее определенную универсальную модель,
даже если поставщик владеет исходным кодом сбора данных.
Рекурсивные иерархии сотрудников
Распространенная характеристика сотрудника — имя его руководителя. Вы можете просто встроить этот атрибут вместе с другими атрибутами в измерение
«Сотрудник». Но если бизнес-пользователи хотят большего, чем имя менеджера, необходимы более сложные структуры.
Один из подходов состоит в том, чтобы включить ключ сотрудника менеджера в качестве другого внешнего ключа в таблицу фактов, как показано на рис. 9-5.
Управление персоналом
343
Этот ключ сотрудника менеджера присоединяется к ролевому измерению «Сотрудник», где каждое имя атрибута ссылается на слово «Менеджер», чтобы отличать профиль менеджера от профиля сотрудника. Этот подход связывает сотрудника и его руководителя всякий раз, когда строка вставляется в таблицу фактов.
Анализ BI может легко фильтроваться и группироваться по атрибутам сотрудника
или менеджера с практически идентичной производительностью запроса, поскольку оба измерения обеспечивают симметричный доступ к таблице фактов. Недостаток этого подхода в том, что эти двойные внешние ключи должны быть встроены
в каждую таблицу фактов для поддержки управленческой отчетности.
Таблица фактов
увольнения сотрудников
Измерение «Сотрудник»
Ключ сотрудника (PK)
ID сотрудника (NK)
...
Измерение «Менеджер»
Ключ даты увольнения (FK)
Ключ организации (FK)
Ключ сотрудника (FK)
Ключ менеджера (FK)
Ключ профиля увольнения (FK)
Количество увольнений
Измерение «Дата»
Измерение «Организация»
Измерение
«Увольнение сотрудника»
Ключ профиля увольнения (PK)
Описание типа увольнения
Описание причины увольнения
Ключ менеджера (PK)
ID сотрудника менеджера (NK)
...
Рис. 9-5. Двойные ролевые взаимодействия сотрудника и менеджера
Другой вариант — включить ключ сотрудника менеджера в качестве атрибута
в строку измерения «Сотрудник». Ключ менеджера присоединится к выносному
внешнему ролевому измерению «Сотрудник», где все атрибуты ссылаются на «Менеджера», чтобы отличать их от характеристик сотрудника, как показано на рис. 9-6.
Измерение «Сотрудник»
Измерение «Менеджер»
Ключ менеджера (PK)
ID сотрудника менеджера (NK)
Атрибуты менеджера
сотрудника …
Дата вступления строки в силу
Дата истечения действия
строки
Индикатор текущей строки
Ключ сотрудника (PK)
ID сотрудника (NK)
Атрибуты сотрудника …
Ключ менеджера (FK)
Дата вступления строки
в силу
Дата истечения действия
строки
Индикатор текущей строки
Таблица фактов
увольнения сотрудников
Ключ даты увольнения (FK)
Ключ организации (FK)
Ключ сотрудника (FK)
Ключ профиля увольнения (FK)
Количество увольнений
Рис. 9-6. Выносное внешнее ролевое измерение «Менеджер»
344
Глава 9
Если внешний ключ менеджера в измерении «Сотрудник» обозначен как
атрибут типа 2, то при каждой смене менеджера будут создаваться новые строки
«Сотрудник». Тем не менее мы рекомендуем вам тщательно продумать основные бизнес-правила ETL.
Отслеживание изменений на встроенном ключе
менеджера
Давайте рассмотрим пример. Эбби — менеджер Хейдена. При только что описанном подходе внешнего измерения строка измерения «Сотрудник» для Хейдена будет включать атрибут, связывающий строку Эбби в ролевом измерении
«Менеджер». Если менеджер Хейдена изменится и если предположить, что бизнес хочет отслеживать эти исторические изменения, то будет уместно рассматривать внешний ключ менеджера как тип 2 и создавать новую строку для Хейдена,
чтобы зафиксировать его новый профиль с новым менеджером.
Однако подумайте о желаемом результате, если бы Эбби все еще была менеджером Хейдена, но профиль ее сотрудника изменился, возможно, вызванный
чем-то столь же безобидным, как смена домашнего адреса. Если домашний адрес указан как атрибут типа 2, это перемещение приведет к появлению новой
строки измерения сотрудника для Эбби. Если ключ менеджера также обозначен
как атрибут типа 2, то новый ключ сотрудника Эбби также создаст новую строку
измерения для Хейдена. А теперь представьте, что Эбби — генеральный директор крупной организации. Изменение типа 2 в ее профиле отразилось бы на всей
таблице; в итоге вы повторили бы новую строку профиля для каждого сотрудника из-за единственного изменения атрибута типа 2 в профиле генерального
директора.
Хочет ли бизнес зафиксировать эти изменения в профиле менеджера? Если
нет, возможно, ключом менеджера в строке сотрудника должен быть устойчивый
натуральный ключ менеджера, связанный с ролевым измерением, ограниченным
только текущей строкой для устойчивого натурального ключа каждого менеджера в измерении.
Если вы назначите ключ менеджера в измерении «Сотрудник» атрибутом
типа 1, он всегда будет связывать сотрудника с ее текущим менеджером. Хотя
этот упрощенный подход стирает историю, возможно, этого достаточно, чтобы
удовлетворить потребности бизнес-пользователей.
Детализация иерархий управления: вверх и вниз
Добавление атрибута, текстовой метки либо внешнего ключа к ролевому измерению в строку измерения «Сотрудник» подходит для обработки отношения
«многие к одному» фиксированной глубины между сотрудником и менеджером.
Управление персоналом
345
Однако могут потребоваться более сложные подходы, если бизнес хочет ориентироваться в более глубокой рекурсивной иерархии, например идентифицировать всю цепочку управления сотрудника или детализировать ее, чтобы определить деятельность для всех сотрудников, которые прямо или косвенно работают
на данного менеджера.
Если вы используете инструмент OLAP для запроса данных о сотрудниках,
может быть достаточно встроенного ключа менеджера в каждой строке измерения сотрудника. Популярные продукты OLAP содержат иерархическую структуру
«родитель — потомок», которая плавно работает с рекурсивными иерархиями
переменной глубины. На самом деле это одна из сильных сторон продуктов OLAP.
Однако, если вы хотите запросить рекурсивные отношения «сотрудник — менеджер» в реляционной среде, вы должны использовать нестандартный синтаксис Oracle CONNECT BY или синтаксис SQL Recursive common table extension
(CTE). Оба подхода практически неосуществимы для бизнес-пользователей, вооруженных инструментом отчетности BI.
Таким образом, у вас остаются варианты, описанные в главе 7 для работы
с иерархиями клиентов переменной глубины. На рис. 9-7 измерение «Сотрудник» с рис. 9-6 связано с таблицей фактов через промежуточную таблицу. В соединительной таблице есть одна строка для каждого менеджера и каждого сотрудника, который прямо или косвенно участвует в их цепочке управления, плюс
дополнительная строка для самого менеджера. Соединительные таблицы, показанные на рис. 9-7, позволяют детализировать цепочку командования менеджера.
Таблица фактов
увольнения сотрудников
Измерение «Менеджер»
Ключ менеджера (PK)
ID сотрудника менеджера (NK)
Атрибуты менеджера
сотрудника …
Дата вступления строки в силу
Дата истечения действия строки
Индикатор текущей строки
Связь иерархии управления
Ключ менеджера (FK)
Ключ сотрудника (FK)
# Уровней
от TOP-менеджмента
Флаг дна
Флаг вершины
Ключ даты увольнения (FK)
Ключ организации (FK)
Ключ сотрудника (FK)
Ключ профиля увольнения (FK)
Количество увольнений
Рис. 9-7. Сводная таблица для детализации структуры отчетности менеджера
Как было описано ранее, у этого подхода есть несколько недостатков. Соединительная таблица несколько сложна в построении, плюс она содержит много
строк, поэтому производительность запросов может быть недостаточной. Пользовательский интерфейс BI сложен для специальных запросов, хотя мы видели,
как аналитики эффективно его используют. Наконец, если пользователи хотят
346
Глава 9
агрегировать информацию вверх, а не вниз по цепочке управления, пути соединения должны быть обратными.
И снова ситуация усложняется, если вы хотите отслеживать изменения профиля сотрудника в сочетании с соединительной таблицей. Если менеджер и сотрудник отражают профили сотрудников с изменениями типа 2, соединительная
таблица будет быстро расти, особенно когда изменения в профилях высшего руководства приводят к появлению новых ключей по всей организации.
Вы можете использовать устойчивые натуральные ключи в соединительной
таблице вместо ключей сотрудников, которые фиксируют изменения профиля
типа 2. Ограничение отношений текущими профилями менеджеров — это одно.
Однако, если бизнес хочет сохранить историю сводных данных «сотрудников —
менеджеров», вам необходимо добавить в сводную таблицу даты вступления
в силу и истечения срока действия, которые отражают имевший силу промежуток времени для каждого отношения «сотрудника — менеджера».
Создание новых строк в этой соединительной таблице с использованием устойчивых ключей существенно сокращено по сравнению с соединительной таблицей
на рис. 9-7, поскольку новые строки добавляются при изменении отношений отчетности, а не при изменении любого атрибута сотрудника типа 2. Соединительной
таблицей, построенной на устойчивых ключах, проще управлять, но в ней довольно
сложно ориентироваться, особенно учитывая необходимость связать соответствующие организационные структуры с датами событий в таблице фактов. Учитывая эти
сложности, соединительная таблица должна быть скрыта в готовом приложении BI
для всех, кроме небольшого подмножества пользователей power BI.
Альтернативные подходы, обсуждаемые в главе 7 для обработки рекурсивных
иерархий, такие как атрибут Pathstring, также имеют отношение к головоломке
иерархии управления. К сожалению, не существует универсального решения для
простого и быстрого управления этими сложными структурами.
Многозначные атрибуты
ключевых навыков сотрудников
Давайте предположим, что ИТ-отдел хочет дополнить измерение «Сотрудник»
информацией о технических навыках. Вы могли бы рассматривать технические
навыки, такие как языки программирования, операционные системы или платформы баз данных, как ключевые слова, описывающие сотрудников. Каждый сотрудник помечен рядом ключевых слов для навыков. Вы хотите выполнить поиск
среди ИТ-сотрудников по их описательным навыкам.
Если бы интересующие технические навыки были конечным числом, вы могли бы включить их в качестве отдельных атрибутов в измерение «Сотрудник».
Управление персоналом
347
Преимущество использования позиционных атрибутов, таких как атрибут Linux
со значениями домена, такими как «Навыки Linux» и «Отсутствие навыков
Linux», заключается в том, что их легко запрашивать и они обеспечивают быструю производительность запросов. Этот подход хорошо работает до определенного момента, но разваливается, когда число потенциальных навыков увеличивается.
Ключевые слова для навыков сотрудников
Более реалистично, что каждый сотрудник будет обладать переменным, непредсказуемым количеством навыков. В этом случае атрибут ключевого слова навыка — основной кандидат на роль многозначного измерения. Ключевые слова
навыков по своей природе открытые; новые навыки регулярно добавляются
в качестве значений домена. Мы покажем две логически эквивалентные схемы
моделирования для обработки открытых наборов навыков.
На рис. 9-8 показана схема для многозначных измерений для обработки навыков в качестве внешней соединительной таблицы для таблицы измерения «Сотрудник». Как вы увидите в главе 14 «Здравоохранение», иногда многозначная
соединительная таблица соединяется непосредственно с таблицей фактов.
Таблица фактов
численности персонала
в момент времени
Ключ сотрудника (FK)
Другие ключи …
Факты численности…
Измерение
«Сотрудник»
Ключ сотрудника (PK)
…
Ключ группы навыков
сотрудника (FK)
Соединительная таблица
«Группы навыков
сотрудников»
Измерение «Навык»
Ключ группы навыков
сотрудника (FK)
Ключ навыка сотрудника (FK)
Ключ навыка сотрудника (PK)
Описание навыка сотрудника
Категория навыка сотрудника
Рис. 9-8. Таблица ключевых слов для группы навыков
Соединительная таблица «Группы навыков сотрудников» идентифицирует
заданный набор ключевых слов навыков. ИТ-сотрудникам, которые хорошо разбираются в Oracle, Unix и SQL, будет присвоен один и тот же ключ группы навыков. В соединительной таблице группы навыков для этой конкретной группы
будет три строки, по одной для каждого из связанных ключевых слов навыков
(Oracle, Unix и SQL).
Дилемма запроса И/ИЛИ
Даже если вы создали схему, показанную на рис. 9-8, у вас все еще остается серьезная проблема с запросами. Запросы по ключевым словам навыков делятся
на две категории. Запросы ИЛИ (например, опыт работы в Unix или Linux) могут быть удовлетворены простым ограничением ИЛИ для атрибута описания
348
Глава 9
навыков в таблице измерения «Навыки». Однако запросы И (например, опыт
работы в Unix и Linux) сложны, поскольку ограничение И — это ограничение
для двух строк в измерении «Навыки». SQL, как известно, плохо справляется
с ограничениями между строками. Решение заключается в создании кода SQL
с использованием объединений и пересечений, возможно, в пользовательском
интерфейсе, который скрывает сложную логику от бизнес-пользователя. Код
SQL будет выглядеть следующим образом:
(SELECT employee_ID, employee_name
FROM Employee, SkillBridge, Skills
WHERE Employee.SkillGroupKey = SkillBridge.SkillGroupKey AND
SkillGroup.SkillKey = Skill.SkillKey AND Skill.Skill = "UNIX")
UNION / INTERSECTION
(SELECT employee_ID, employee_name
FROM Employee, SkillBridge, Skills
WHERE Employee.SkillGroupKey = SkillBridge.SkillGroupKey AND
SkillGroup.SkillKey = Skill.SkillKey AND
Skill.Skill = "LINUX")
При использовании _UNION перечислены сотрудники с опытом работы
в Unix или Linux, в то время как при использовании _INTERSECTION идентифицируются сотрудники с опытом работы в Unix и Linux.
Текстовая строка для ключевого слова навыка
Вы можете устранить соединительную таблицу «многие ко многим» и необходимость в SQL объединения/пересечения, упростив дизайн. Одним из подходов было бы добавление внешнего измерения «Список навыков» в измерение
«Сотрудник», содержащего одну длинную текстовую строку, объединяющую
все ключевые слова навыков для этого ключа списка. Вам понадобится специальный разделитель, такой как обратная косая черта или вертикальная черта, в начале текстовой строки навыков и после каждого навыка в списке. Таким образом,
строка навыков, содержащая Unix и C++, будет выглядеть как |Unix|C++|. Этот
подход с внешним измерением предполагает, что ряд сотрудников имеют общий
список навыков. Если списки не используются повторно часто, вы можете свернуть внешнее измерение «Список навыков», просто включив текстовую строку списка навыков в качестве атрибута измерения «Сотрудник», как показано
на рис. 9-9.
Поиск текстовых строк может быть сложным из-за неоднозначности, вызванной поиском в верхнем или нижнем регистре. Это UNIX, Unix или unix? Вы
Управление персоналом
349
можете решить эту проблему, приведя список навыков в верхний регистр с помощью функции UCase в большинстве сред SQL.
Таблица фактов численности персонала в момент времени
Ключ сотрудника (FK)
Другие ключи …
Факты численности …
Измерение «Сотрудник»
Ключ сотрудника (PK)
…
Список групп навыков сотрудника
Рис. 9-9. Строка списка навыков с разделителями
С помощью конструкции, показанной на рис. 9-9, дилемма И/ИЛИ может
быть решена с помощью одного оператора SELECT. Ограничение ИЛИ выглядит следующим образом:
UCase(skill_list) like ' %|UNIX| % OR UCase(skill_list) like
' %|LINUX| %'
Между тем ограничение И имеет точно такую же структуру:
UCase(skill_list) like ' %|UNIX|' AND UCase(skill_list) like
' %|LINUX| %'
Символ % — это символ подстановки, соответствующий шаблону, определенный в SQL, который соответствует нулю или более символов. Разделитель вертикальной полосы явно используется в ограничениях, чтобы точно соответствовать
нужным ключевым словам и не получать ошибочных совпадений.
Подход со списком ключевых слов, показанный на рис. 9-9, может работать
в любой реляционной базе данных, поскольку он основан на стандартном SQL.
Хотя подход с использованием текстовых строк облегчает И /ИЛИ поиск, он
не поддерживает запросы, считающие по ключевым словам.
Данные анкеты-опросника
Отделы кадров часто собирают данные опросов сотрудников, особенно при сборе данных коллегиального и/или управленческого анализа эффективности работы сотрудника. Отдел анализирует ответы на анкеты, чтобы определить среднюю
оценку для проверяемого сотрудника и внутри отдела.
Для обработки данных анкеты в размерной модели обычно создается таблица
фактов с одной строкой для каждого вопроса опроса респондента, как показано на рис. 9-10. Два ролевых измерения «Сотрудник» в схеме соответствуют
350
Глава 9
отвечающему сотруднику и проверяемому сотруднику. Измерение «Анкетаопросник» содержит описание инструмента, с помощью которого проводится
опрос. Измерение «Вопрос» содержит вопрос и его категоризацию; предположительно, один и тот же вопрос задается в нескольких опросах. Измерения
«Анкета-опросник» и «Вопрос» могут быть полезны при поиске конкретных
тем в широкой базе данных анкет. Измерение «Ответ» содержит ответы и, возможно, категории ответов, такие как благоприятные или враждебные.
Таблица фактов
по опросам сотрудников
Измерение «Дата» (2 роли)
Измерение «Сотрудник» (2 роли)
Измерение «Вопрос»
Ключ вопроса (PK)
Метка вопроса
Категория вопроса
Цель вопроса
Ключ даты проведения
опроса (FK)
Ключ даты получения
результатов (FK)
Ключ опроса (FK)
Responding Ключ сотрудника (FK)
Ключ опрошенного
сотрудника (FK)
Ключ вопроса (FK)
Ключ категории ответа (FK)
Номер опроса (DD)
Ответ
Измерение
«Анкета-опросник»
Ключ опроса (PK)
Название опроса
Тип опроса
Цель опроса
Год проведения
Измерение
«Категория ответов»
Ключ категории ответов (PK)
Описание категории ответа
Рис. 9-10. Схема опросника
Создание простой схемы на рис. 9-10 надежно поддерживает срезы и выборки по анкетам-опросникам. Варианты этой схемы были бы полезны для анализа всех типов данных опросов, включая удовлетворенность клиентов и отзывы
об использовании продукта.
Текстовые комментарии
Факты обычно рассматриваются как числовые показатели с непрерывным значением; атрибуты измерения, с другой стороны, берутся из дискретного списка
значений предметной области. Итак, как вы обрабатываете текстовые комментарии, такие как замечания менеджера по обзору эффективности или отзывы
в свободной форме по вопросу опроса, которые, похоже, не поддаются четкой
классификации в категорию фактов или измерений? Хотя ИТ-специалисты могут инстинктивно захотеть просто исключить их из размерного дизайна, бизнеспользователи могут потребовать, чтобы они были сохранены для дальнейшего
описания показателей производительности.
После подтверждения того, что бизнес не желает отказываться от текстовых
комментариев, вам следует определить, можно ли преобразовать комментарии
Управление персоналом
351
в соответствующие атрибуты измерения. Хотя иногда есть возможность классифицировать текст, например комплимент по сравнению с жалобой, обычно также
требуется полнотекстовое изложение.
Поскольку текст произвольной формы имеет так много потенциальных значений, у дизайнеров иногда возникает соблазн сохранить текстовый комментарий в таблице фактов. Хотя они знают, что таблицы фактов обычно ограничены
внешними ключами, вырожденными измерениями и числовыми фактами, они
утверждают, что текстовый комментарий — это просто еще одно вырожденное
измерение. К сожалению, текстовые комментарии не относятся к вырожденным
измерениям.
Текстовые поля произвольной формы не следует хранить в таблице фактов,
потому что они просто добавляют большой беспорядок в таблицу. В зависимости
от платформы базы данных эти относительно малоценные данные послужат балластом при каждой операции, связанной с гораздо более ценными показателями
производительности таблицы фактов.
Вместо того чтобы рассматривать комментарии как текстовые показатели, мы
рекомендуем сохранять их за пределами таблицы фактов. Комментарии должны
быть либо записаны в отдельные измерения «Комментарии» (с соответствующим внешним ключом в таблице фактов), либо в качестве атрибута в таблице
измерений с детализацией транзакций. В некоторых ситуациях одинаковые
комментарии наблюдаются несколько раз. Как минимум, это обычно происходит с комментарием «Без комментариев». Если количество комментариев
меньше количества транзакций, текст должен быть записан в измерении «Комментарий». В противном случае, если для каждого события есть уникальный
комментарий, он рассматривается как атрибут измерения «Транзакция». В любом случае независимо от того, обрабатываются ли комментарии в измерении
«Комментарий» или «Транзакция», производительность запроса при подключении этого значительного измерения к таблице фактов будет низкой. Однако
к тому времени, когда пользователи просматривают комментарии, они, скорее
всего, значительно отфильтровали свой запрос, поскольку они могут реально
прочитать только ограниченное количество комментариев. Между тем более распространенные анализы, ориентированные на показатели производительности
таблицы фактов, не будут обременены дополнительным весом текстовых комментариев к каждому запросу таблицы фактов.
Выводы
В этой главе мы обсудили несколько концепций в контексте кадровых данных и подробнее остановились на преимуществах красивого дизайна таблицы
352
Глава 9
измерения «Сотрудник». В мире HR эта единая таблица используется для решения ряда вопросов, касающихся статуса и профиля базы сотрудников в любой
момент. Мы разработали матрицу шин, представляющую множество процессов
в сфере управления персоналом, и выделили таблицу фактов моментального
снимка общей численности персонала, а также потенциальные преимущества
и недостатки решений и моделей данных, разработанных поставщиками. Обсуждалась обработка управленческих сводок и многозначных атрибутов измерений. Наконец, мы предоставили краткий обзор обработки данных опроса или
анкеты, а также текстовые комментарии.
10
И
Финансовые
услуги
ндустрия финансовых услуг охватывает широкий спектр предприятий,
включая компании, выпускающие кредитные карты, брокерские фирмы и ипотечные компании. В этой главе мы в первую очередь сосредоточимся
на розничном банке, поскольку большинство читателей в той или иной степени
лично знакомы с этим типом финансовых учреждений. Банк с полным спектром
услуг предлагает текущие счета, сберегательные счета, ипотечные кредиты, личные ссуды, кредитные карты и сейфы. Эта глава начинается с очень упрощенной
схемы. Затем мы исследуем несколько расширений схемы, включая обработку
широкого спектра разнородных продуктов банка, которые значительно различаются в зависимости от сферы деятельности.
Мы хотим напомнить вам, что главы, посвященные отрасли, подобные этой,
не предназначены для предоставления полномасштабных отраслевых решений.
Хотя различные методы размерного моделирования обсуждаются в контексте
данной отрасли, эти методы, безусловно, применимы и к другим предприятиям.
Если вы не работаете в сфере финансовых услуг, вам все равно нужно прочитать
эту главу. Если вы работаете в сфере финансовых услуг, помните, что схемы в этой
главе не следует рассматривать как полные.
В главе 10 рассматриваются следующие концепции:
■ фрагмент матрицы данных для банков;
■ рассмотрение измерений для исключения ловушки «недостаточного количества измерений»;
■ служебные измерения;
■ соединительные таблицы для связи нескольких клиентов со счетом, а также
весовые коэффициенты;
■ несколько небольших атрибутов в одной таблице фактов;
■ динамическое распределение фактов по группам для отчетности;
354
Глава 10
■ обработка разнородных продуктов по направлениям бизнеса, каждая
из которых имеет уникальные показатели и/или атрибуты измерений,
в виде схем супертипов и подтипов;
■ измерения с возможностью быстрой замены.
Тематическое исследование
банковского дела и матрица шин
нка
ал ба
Домо
хозяй
ство
Прод
укт
X
X
Отслеживание привлечений
X
X
Процесс подачи заявки на счет
X
X
X
X
X
Открытие счета
X
X
X
X
X
X
X
Транзакции по счету
X
X
X
X
X
X
Ежемесячный снимок счета
X
X
X
X
X
X
Обслуживание счета
X
X
X
X
X
X
Счет
Клие
Фили
Перс
пе
Взятие в работу нового бизнеса
нт
Дата
ктива
Первоначальная цель для банка состоит в том, чтобы лучше анализировать банковские счета. Бизнес-пользователи хотят иметь возможность делать срезы и выборки
по отдельным счетам, а также по домохозяйствам, которым эти счета принадлежат.
Одна из основных целей банка — повышение эффективности продаж путем предложения дополнительных продуктов домохозяйствам, у которых уже есть один или
несколько счетов в банке. Рис. 10-1 иллюстрирует часть матрицы шины банка.
X
X
X
X
Рис. 10-1. Подмножество строк матрицы шины для банка
После проведения собеседований с менеджерами и аналитиками по всему
банку был разработан следующий набор требований:
1. Бизнес-пользователи хотят видеть исторические данные за пять лет в виде
моментальных снимков на конец месяца для каждого счета.
2. Каждый счет имеет основной баланс. Бизнес хочет группировать различные типы счетов в одном и том же анализе и сравнить основные балансы.
3. Каждый тип счета (известный в банке как «продукт») имеет набор пользовательских атрибутов измерения и числовых фактов, которые, как правило,
сильно отличаются от продукта к продукту.
Финансовые услуги
355
4. Считается, что каждый счет принадлежит одному домохозяйству (семье).
Существует удивительная степень нестабильности в отношениях между
счетом и домохозяйством из-за изменений в семейном положении и других факторов жизненного этапа.
5. В дополнение к идентификации домохозяйств пользователей интересует
демографическая информация как в отношении отдельных потребителей,
так и в отношении домашних хозяйств. Кроме того, банк фиксирует и сохраняет показатели поведения, относящиеся к деятельности или характеристикам каждого счета и домохозяйства.
Рассмотрение измерений для исключения
«недостаточного количества измерений»
Когда вы основываетесь на предыдущих бизнес-требованиях, начинают проявляться зернистость и размерность исходной модели. Вы можете начать с таблицы фактов, в которой записываются остатки основных средств на каждом счете
в конце каждого месяца. Очевидно, что суть таблицы фактов — это одна строка
для каждого счета каждый месяц. Основываясь на этой декларации о зернистости, вы можете изначально представить себе дизайн только с двумя измерениями:
месяц и счет. Это два внешних ключа из первичного ключа таблицы фактов, как
показано на рис. 10-2. Разработчик, ориентированный на данные, может утверждать, что вся остальная описательная информация, такая как характеристики
домохозяйства, филиала и продукта, должна быть встроена в качестве описательных атрибутов измерения «Счет», поскольку с каждым счетом связано только
одно домохозяйство, филиал банка и продукт.
Измерение «Месяц»
Ключ даты конца
месяца (PK)
Атрибуты месяца …
Таблица фактов
моментальных
снимков конца месяца
Ключ даты конца
месяца (FK)
Ключ счета (FK)
Основной остаток
на конец месяца
Измерение «Счет»
Ключ счета (PK)
Атрибуты счета …
Основные атрибуты клиента…
Атрибуты продукта …
Атрибуты домохозяйства …
Атрибуты статуса …
Атрибуты отрасли …
Рис. 10-2. Таблица фактов моментального снимка счетов на конец месяц
с недостаточным количеством измерений
Хотя эта схема точно отражает отношения «многие к одному» и «многие
ко многим» в данных моментального снимка, она неадекватно отражает естественные бизнес-аспекты. Вместо того чтобы сводить все в огромную таблицу
356
Глава 10
измерения «Счет», дополнительные аналитические измерения, такие как «Продукт» и «Филиал», отражают инстинктивное представление пользователей
о своем бизнесе. Эти дополнительные измерения обеспечивают гораздо меньшие
по размерам точки входа в таблицу фактов. Таким образом, они решают задачи как
производительности, так и удобства использования размерной модели. Наконец,
учитывая, что у крупного банка могут быть миллионы счетов, вам следует беспокоиться об эффектах медленно меняющихся измерений типа 2, которые могут привести к тому, что это огромное измерение превратится во что-то неуправляемое.
Атрибуты «Продукт» и «Филиал» — это удобные группы атрибутов, которые можно удалить из измерения «Счет», чтобы сократить рост строк, вызванный отслеживанием изменений типа 2. В разделе «Пересмотр мини-измерений» изменяющиеся демографические и поведенческие характеристики будут
удалены из измерения «Счет» по тем же причинам. Измерения «Продукт»
и «Филиал» — два отдельных измерения, поскольку между продуктами и филиалами существует взаимосвязь «многие ко многим». Они оба меняются медленно, но в разных ритмах, а главное, что бизнес-пользователи воспринимают их
как отдельные аспекты банковского бизнеса.
В целом большинство размерных моделей в итоге имеют от пяти до 20 измерений. Если вы находитесь на нижней границе этого диапазона или ниже нее,
у вас должны быть подозрения, что какие-то измерения могли быть непреднамеренно исключены из проекта. В этом случае тщательно продумайте, являются ли
какие-либо из следующих типов измерений подходящими дополнениями к вашей исходной размерной модели:
1. Причинно-следственные связи, такие как продвижение по службе, контракт,
сделка, состояние магазина или даже погода. Эти измерения, как обсуждалось в главе 3, дают дополнительное представление о причине события.
2. Множественные изменения дат, особенно когда таблица фактов представляет собой накопительный снимок. Примеры таблиц фактов с несколькими отметками дат см. в главе 4.
3. Вырожденные идентификаторы, которые идентифицируют контрольные
номера операционных транзакций, такие как заказ, счет-фактура, коносамент или билет, как первоначально показано в главе 3.
4. Ролевые измерения, например, когда с одной транзакцией связано несколько бизнес-объектов, каждый из которых представлен отдельным измерением. В главе 6 мы описали ролевые измерения для обработки нескольких дат.
5. Измерения типа «Статус», которые определяют текущий статус транзакции или ежемесячный снимок в более широком контексте, например статус счета.
Финансовые услуги
357
6. Измерения типа «Аудит», как обсуждалось в главе 6, для отслеживания
происхождения и качества данных.
7. Дополнительные измерения коррелированных показателей и показателей
эффективности, как описано в главе 6.
Эти измерения, как правило, могут быть корректно добавлены в дизайн
даже после запуска системы DW/BI в производство, поскольку они не изменяют структуру таблицы фактов. Добавление этих измерений обычно не изменяет
существующие ключи измерений или измеренные факты в таблице фактов. Все
существующие приложения должны продолжать работать без изменений.
ПРИМЕЧАНИЕ Обратите внимание, что любой описательный атрибут, кото-
рый является однозначным и находится в таблице фактов, — хороший кандидат
для добавления в существующее измерение или в качестве собственного измерения.
Измерение «Месяц»
Ключ даты конца
месяца (PK)
Атрибуты месяца …
Измерение «Филиал»
Ключ филиала (PK)
Номер филиала (NK)
Атрибуты адреса филиала…
Атрибуты сворачивания
филиала…
Измерение «Продукт»
Ключ продукта (PK)
Код продукта (NK)
Описание продукта
…
Измерение «Статус счета»
Ключ статуса счета (PK)
Описание статуса счета
Группа статуса счета
Таблица фактов
ежемесячных моментальных
снимков счета
Ключ даты конца месяца (FK)
Ключ филиала (FK)
Ключ счета (FK)
Первичный ключ
клиента (FK)
Ключ продукта (FK)
Ключ статуса счета (FK)
Ключ домохозяйства (FK)
Основной баланс на конец
месяца
Средний ежедневный баланс
Количество транзакций
Выплаченные проценты
Взимаемые сборы
Измерение «Счет»
Ключ счета (PK)
Номер счета (NK)
Атрибуты адреса счета …
Дата открытия счета
…
Измерение «Основной клиент»
Первичный ключ клиента (PK)
Имя основного клиента
Дата рождения основного
клиента
…
Измерение «Домохозяйство»
Ключ домохозяйства (PK)
ID Домохозяйства (NK)
Атрибуты адреса
домохозяйства…
Доход домохозяйства
Показатель домовладения
домохозяйства
Наличие детей в домохозяйстве
…
Рис. 10-3. Таблица фактов супертипа для всех учетных записей
358
Глава 10
На основе дальнейшего изучения требований банка вы можете в итоге выбрать следующие измерения для начальной схемы: дата окончания месяца, филиал, счет, основной клиент, продукт, статус учетной записи и домохозяйство. Как
показано на рис. 10-3, на пересечении этих семи измерений вы делаете ежемесячный снимок и записываете основной баланс и любые другие показатели, которые
имеют смысл для всех продуктов, такие как количество транзакций, выплаченные проценты и взимаемые сборы. Помните, что остатки на счетах аналогичны
остаткам на складах в том смысле, что они неаддитивные в течение какого-либо
периода времени. Вместо этого вы должны усреднить остатки на счетах, разделив
сумму баланса на количество периодов времени.
ПРИМЕЧАНИЕ В этой главе мы используем базовые объектно-ориентиро-
ванные термины супертип и подтип для обозначения единой таблицы фактов, охватывающей все возможные типы счетов, а также нескольких таблиц
фактов, содержащих конкретные сведения о каждом отдельном типе счета.
В прошлых работах они назывались основными и пользовательскими таблицами фактов, но пришло время перейти к более знакомой и общепринятой
терминологии.
Измерение «Продукт» состоит из простой иерархии, которая описывает все
продукты банка, включая название продукта, тип и категорию. Необходимость
создания общей классификации продуктов банка — это та же самая потребность,
которая заставляет продуктовые магазины создавать иерархию общих товаров.
Основное различие между примерами банка и продуктового магазина заключается в том, что банк также разрабатывает большое количество подтипов атрибутов
продукта для каждого типа продукта. Мы отложим обсуждение обработки этих
атрибутов подтипа до раздела «Схемы супертипов и подтипов для разнородных
продуктов» в конце главы.
Измерение «Филиал» аналогично измерениям объекта, которые мы обсуждали ранее в этой книге, таким как розничный магазин или склад распределительного центра.
Измерение «Состояние счета» — полезное измерение для записи состояния
счета в конце каждого месяца. В статусе записывается, активен или неактивен
счет, или произошло ли изменение статуса в течение месяца, например открытие или закрытие счета. Вместо того чтобы сокращать масштабное измерение
«Счет» или просто встраивать зашифрованный код статуса или аббревиатуру
непосредственно в таблицу фактов, мы рассматриваем статус как полномасштабное измерение с описательными расшифровками статуса, группировками и описаниями причин статуса в зависимости от обстоятельств. Во многих отношениях
Финансовые услуги
359
измерение «Статус счета» можно рассматривать как еще один пример мини-измерения, как мы представили в главе 5.
Измерение «Домохозяйство»
Вместо того чтобы сосредотачиваться исключительно на счетах банка, бизнеспользователи также хотят иметь возможность анализировать отношения банка
со всей экономической единицей, называемой домашним хозяйством. Они заинтересованы в понимании общей прибыли домохозяйства, масштабов существующих отношений с домохозяйством и того, какие дополнительные продукты
следует продавать домохозяйству. Они также хотят охватить ключевые демографические данные, касающиеся домохозяйства, такие как его доход, владеют ли
они своим домом или арендуют его, пенсионеры ли они и есть ли у них дети.
Эти демографические атрибуты меняются с течением времени; как вы можете
подозревать, пользователи хотят отслеживать изменения. Если банк фокусируется на счетах для коммерческих организаций, а не для потребителей, аналогичные
требования к идентификации и увязке корпоративных «домашних хозяйств»
можно назвать общими.
С точки зрения банка домашнее хозяйство может состоять из нескольких счетов и индивидуальных владельцев счетов. Например, рассмотрим Джона и Мэри
Смит как одно домашнее хозяйство. У Джона есть текущий счет, в то время как
у Мэри открыт сберегательный. Кроме того, у них есть совместный текущий счет,
кредитная карта и ипотека в банке. Все эти пять счетов считаются частью одного
и того же домохозяйства Смита, хотя в информации об оперативном названии
и адресе могут существовать незначительные несоответствия.
Привязку индивидуальных счетов к домашним хозяйствам (или эквиваленту коммерческого бизнеса) не следует воспринимать легкомысленно. Ведение
домашнего хозяйства требует разработки бизнес-правил и алгоритмов для назначения счетов домохозяйствам. Существуют специализированные продукты
и услуги для подбора, необходимые для этих назначений. Для крупной организации, предоставляющей финансовые услуги, очень характерно вкладывать значительные ресурсы в специализированные возможности, чтобы удовлетворить
свои потребности в обслуживании домохозяйств.
Решение рассматривать счет и домашнее хозяйство как отдельные измерения — в некоторой степени прерогатива дизайнера модели данных. Хотя они
интуитивно взаимосвязаны, вы решаете рассматривать их отдельно из-за размера
измерения «Счет» и изменчивости, составляющих счета в измерении «Домохозяйство», как упоминалось ранее. В крупном банке размер таблицы «Счет»
огромен, с более чем 10 миллионами строк, которые группируются в несколько миллионов домохозяйств. Измерение «Домохозяйство» обеспечивает
360
Глава 10
несколько меньшую точку входа в таблицу фактов без обхода таблицы измерения
«Счет» с 10 миллионами строк. Кроме того, учитывая меняющийся характер
взаимосвязи между счетами и домохозяйствами, вы решаете использовать таблицу фактов для отражения взаимосвязи, а не просто включать атрибуты домохозяйства в каждую строку измерения «Счет». Таким образом, вы избегаете
использования метода медленно меняющегося измерения типа 2 с измерением
счета в 10 миллионов строк.
Многозначные измерения и весовые коэффициенты
Как вы только что видели в примере с Джоном и Мэри Смит, со счетом может
быть связан один, два или более индивидуальных владельца счета или клиентов.
Очевидно, что клиент не может быть включен в качестве атрибута счета (помимо
указания основного клиента/владельца счета); это нарушает зернистость таблицы измерений, поскольку со счетом может быть связано более одного человека.
Аналогичным образом вы не можете включить клиента в качестве дополнительного измерения в таблицу фактов; это нарушает зернистость таблицы фактов
(по одной строке на счет в месяц), опять же потому, что с любым данным счетом
может быть связано более одного человека. Это еще один классический пример
многозначного измерения. Для связи отдельного измерения «Клиент» с детализированной таблицей фактов счета требуется использовать связующую таблицу
между счетом и клиентом, как показано на рис. 10-4. Как минимум первичный
ключ соединительной таблицы состоит из суррогатных ключей счета и клиента.
В этом сценарии также применима отметка времени для строк соединительной
таблицы, как обсуждалось в главе 7, для взаимосвязей между временными вариантами.
Таблица фактов ежемесячных
моментальных снимков счета
Ключ даты конца месяца (FK)
Ключ счета (FK)
Другие ключи …
Основной баланс на конец
месяца
Средний ежедневный баланс
Количество транзакций
Выплаченные проценты
Взимаемые сборы
Измерение «Счет»
Ключ счета (PK)
Номер счета (NK)
Атрибуты адреса счета …
Дата открытия счета
…
Соедиинтельная таблица
Ключ счета (FK)
Ключ клиента (FK)
Коэффициент
Измерение «Клиент»
Ключ клиента (FK)
Имя клиента
Дата рождения
клиента
…
Рис. 10-4. Таблица перехода от счета к клиенту с весовым коэффициентом
Если у счета два владельца, то соответствующая соединительная таблица
содержит две строки. Вы назначаете числовой весовой коэффициент каждому
Финансовые услуги
361
владельцу счета таким образом, чтобы сумма всех весовых коэффициентов составляла ровно 1,00.
Весовые коэффициенты используются для распределения любых числовых
аддитивных фактов между отдельными владельцами счетов. Таким образом, вы
можете сложить все числовые факты по отдельным держателям, и общая сумма
будет верной. Этот вид отчета — правильно взвешенный отчет. Весовые коэффициенты — это просто способ распределения числовых аддитивных фактов между
владельцами счетов. Некоторые предложили бы изменить зернистость таблицы
фактов на снимок счета и владельца счета. В этом случае вы бы взяли весовые коэффициенты и физически умножили их на исходные числовые факты. Это редко
делается по трем причинам. Во-первых, размер таблицы фактов будет умножен
на среднее число владельцев счетов. Во-вторых, некоторые таблицы фактов имеют более одного многозначного измерения. В этой ситуации количество строк
выйдет из-под контроля, и вы начнете сомневаться в физическом значении отдельной строки. Наконец, вы можете захотеть увидеть нераспределенные числа, и их трудно восстановить, если распределения были объединены физически
с числовыми фактами.
Если вы решите не применять весовые коэффициенты в данном запросе, вы
все равно можете суммировать снимки счетов по отдельным владельцам счетов,
но в этом случае вы получите так называемый отчет о влиянии. Примером отчета о воздействии может служить такой вопрос: «Каков общий баланс всех лиц
с определенным демографическим профилем?» Бизнес-пользователи понимают,
что анализ влияния может привести к завышению счета, поскольку факты связаны с обоими владельцами счетов.
На рис. 10-4 можно определить представление SQL, объединяющее таблицу
фактов и таблицу связей между учетными записями и клиентами, чтобы эти две
таблицы в сочетании отображались в инструментах BI как стандартная таблица
фактов с обычным внешним ключом клиента. Можно было бы определить два
представления: одно с использованием весовых коэффициентов, а другое без использования весовых коэффициентов.
ПРИМЕЧАНИЕ Открытый многозначный атрибут может быть связан
со строкой измерения с помощью соединительной таблицы для связи многозначных атрибутов с конкретными измерениями.
В некоторых компаниях, оказывающих финансовые услуги, индивидуальный
клиент идентифицируется и ассоциируется с каждой транзакцией. Например,
компании, выпускающие кредитные карты, часто выдают уникальные номера
карт каждому держателю карты. У Джона и Мэри Смит может быть совместный
362
Глава 10
счет кредитной карты, но номера на их соответствующих пластиковых карточках
разные. В этом случае нет необходимости в связующей таблице между счетом
и клиентом, поскольку факты атомарной транзакции находятся на уровне отдельного клиента; счет и клиент будут внешними ключами в этой таблице фактов.
Однако соединительная таблица потребуется для анализа показателей, которые
естественным образом фиксируются на уровне счета, таких как данные о выставлении счетов по кредитной карте.
Пересмотр мини-измерений
Аналогично обсуждению измерения «Клиент» в главе 8, существует широкий
спектр атрибутов, описывающих банковские счета, клиентов и домохозяйства,
включая ежемесячные атрибуты кредитного бюро, внешние демографические
данные и рассчитанные баллы для определения их поведения, удержания, прибыльности и характеристик просрочки. Организации, предоставляющие финансовые услуги, как правило, заинтересованы в понимании изменений этих атрибутов с течением времени и реагировании на них.
Измерение «Клиент»
Ключ клиента (PK)
Относительно постоянные атрибуты…
Демографические данные клиента
Ключ демографической
принадлежности клиента (PK)
Возрастная группа клиента
Группа доходов клиента
Материальный статус клиента
Таблица фактов
Ключ клиента (FK)
Ключ демографической
принадлежности клиента (FK)
Ключ профиля риска клиента (FK)
Другие ключи …
Факты …
Измерение «Профиль риска клиента»
Ключ профиля риска клиента (PK)
Кластер риска клиента
Кластер просрочек клиента
Рис. 10-5. Несколько мини-измерений, связанных с таблицей фактов
Как обсуждалось ранее, неразумно полагаться на метод медленного изменения измерения типа 2 для отслеживания изменений в измерении «Счет»,
учитывая количество строк измерения и изменчивость атрибутов, таких как
ежемесячное обновление атрибутов кредитного бюро. Вместо этого вы можете
разделить доступные для просмотра и изменяемые атрибуты на несколько миниизмерений, таких как мини-измерения кредитного бюро и демографии, ключи
Финансовые услуги
363
которых включены в таблицу фактов, как показано на рис. 10-5. Мини-измерения типа 4 позволяют вам нарезать таблицу фактов на кусочки, легко отслеживая изменения атрибутов с течением времени, даже если они могут обновляться с разной частотой. Хотя мини-измерения чрезвычайно эффективны, будьте
осторожны, чтобы не злоупотреблять этой техникой. Финансовые сервисы, ориентированные на счета, — хорошая среда для использования мини-измерений,
поскольку основная таблица фактов представляет собой очень длительный периодический снимок. Таким образом, каждый месяц для каждого счета гарантированно существует строка таблицы фактов, которая служит домом для всех
связанных внешних ключей. Вы всегда можете просмотреть счет вместе со всеми
мини-измерениями за любой месяц.
ПРИМЕЧАНИЕ Мини-измерения должны состоять из взаимосвязанных
групп атрибутов; каждый атрибут не должен быть отдельным мини-измерением,
иначе в таблице фактов этих измерений будет слишком много.
Как описано в главе 4, один из компромиссов, связанных с мини-измерениями, — необходимость группировать значения атрибутов для поддержания
разумного количества строк мини-измерений. Вместо того чтобы хранить чрезвычайно дискретные суммы дохода, такие как 31 257,98 доллара США, вы сохраняете диапазоны доходов, например «От 30 000 до 34 999 долларов США»,
в мини-измерении. Аналогично показатели прибыльности могут варьироваться
от 1 до 1200, которые вы разбиваете на фиксированные диапазоны, такие как
меньше или равно 100, от 101 до 150 и от 151 до 200 в мини-измерении.
Большинство организаций считают, что значения атрибутов, разбитые на такие группы, соответствуют их обычным аналитическим требованиям, однако существуют две ситуации, в которых разбивки по группам могут быть неадекватными. Во-первых, для эффективности анализа данных часто требуются дискретные
значения, а не фиксированные диапазоны. Во-вторых, ограниченное число мощных аналитиков может захотеть проанализировать дискретные значения, чтобы
определить, подходят ли диапазоны. В этом случае вы по-прежнему сохраняете
атрибуты мини-измерения с ограниченным значением для поддержки последовательной ежедневной аналитической отчетности, но также сохраняете ключевые дискретные числовые значения в виде фактов в таблице фактов. Например,
если бы показатель прибыльности каждого счета пересчитывался каждый месяц,
вы бы назначали соответствующее мини-измерение диапазона прибыльности для
этого показателя каждый месяц. Кроме того, вы бы зафиксировали показатель
дискретной прибыльности как факт в таблице фактов ежемесячного снимка счета. Наконец, при необходимости текущий диапазон или оценка прибыльности
364
Глава 10
могут быть включены в измерение «Счет», где любые изменения обрабатываются путем преднамеренной перезаписи атрибута типа 1. Каждый из этих элементов данных должен быть уникально помечен, чтобы их можно было различить.
Разработчики всегда должны тщательно сбалансировать добавочную стоимость
включения избыточных фактов и атрибутов по сравнению с затратами с точки
зрения дополнительной сложности как для обработки ETL, так и для представления BI.
Добавление мини-измерений к соединительным
таблицам
В примере с банковским счетом таблица связей между счетами и клиентами может быть очень большой. Если у вас 20 миллионов счетов и 25 миллионов клиентов, таблица связи может вырасти до сотен миллионов строк через несколько
лет, если как измерения «Счет» и «Клиент» — измерения типа 2 (где вы отслеживаете историю, создавая новые строки с новыми ключами).
Теперь опытный специалист по моделированию измерений спрашивает: «Что
произойдет, когда мое измерение «Клиент» окажется быстро меняющимся измерением-монстром?» Это может произойти, когда в измерение «Клиент» добавляются быстро меняющиеся демографические данные и атрибуты статуса, что
приводит к многочисленным добавлениям типа 2. Теперь измерение «Клиент»
с 25 миллионами строк грозит разрастись до нескольких сотен миллионов строк.
Таблица фактов
Ключ месяца (FK)
Ключ счета (FK)
Другие ключи …
Факты …
Измерение «Счет»
Связь счета и клиента
Ключ счета (PK)
Номер счета (NK)
…
Ключ счета (FK)
Ключ клиента (FK)
Ключ демографической
принадлежности (FK)
Измерение «Клиент»
Ключ клиента (PK)
Имя клиента
...
Измерение
«Демография клиента»
Ключ демографической
принадлежности (PK)
Возрастная категория
Категория доходности
Материальный статус
Рис. 10-6. Таблица перехода от счета к клиенту с добавленным
мини-измерением
Стандартный ответ на быстро меняющиеся измерения состоит в том, чтобы
разделить быстро меняющуюся демографию и атрибуты статуса на мини-измерение типа 4, часто называемое демографическим измерением. Это отлично
работает, когда это измерение подключается непосредственно к таблице фактов
Финансовые услуги
365
вместе с измерением «Клиент», поскольку оно стабилизирует многочисленные
атрибуты клиента и предотвращает их увеличение при каждом изменении демографических данных или атрибута статуса. Но можете ли вы получить такое же
преимущество, если измерение «Клиент» привязано к соединительной таблице,
как в примере с банковским счетом?
Решение состоит в том, чтобы добавить ссылку на внешний ключ в соединительной таблице в измерение демография, как показано на рис. 10-6.
Способ визуализации соединительной таблицы заключается в том, что она
связывает каждый счет с соответствующими клиентами и их демографическими данными. Ключ для соединительной таблицы теперь состоит из ключа счета,
ключа клиента и демографического ключа.
В зависимости от того, как часто новые демографические данные назначаются каждому клиенту, соединительная таблица, возможно, значительно вырастет.
В приведенной выше схеме, поскольку структура таблицы фактов корневого банковского счета зависит от месяца по счету, сводная таблица должна быть ограничена изменениями, зарегистрированными только в конце месяца. Это снимает
часть нагрузки на отслеживание изменений с соединительной таблицы.
Динамическая группировка значений в таблицах фактов
Предположим, бизнес-пользователи хотят иметь возможность создавать отчеты
по диапазонам значений для стандартного числового факта, такого как баланс
счета, но не желают жить с заранее определенными диапазонами в таблице измерений. Они могут захотеть создать отчет на основе моментального снимка баланса счета, как показано на рис. 10-7.
Диапазон баланса
0–1000
1001–2000
2001–5000
5001–10000
10001 и выше
Сумма на счете Сумма по всем счетам
456 783
$229 305 066
367 881
$552 189 381
117 754
$333 479 328
52 662
$397 229 466
8437
$104 888 784
Рис. 10-7. Строки отчета с динамическими группами диапазонов значений
Используя схему на рис. 10-3, трудно создать этот отчет непосредственно
из таблицы фактов. В SQL нет обобщения предложения GROUP BY, которое
объединяет аддитивные значения в диапазоны. Чтобы еще больше усложнить
ситуацию, диапазоны имеют неодинаковый размер и имеют текстовые названия,
такие как «10 001 и выше». Кроме того, пользователям обычно требуется гибкость для переопределения диапазонов во время запроса с различными границами или уровнями точности.
366
Глава 10
Схема, показанная на рис. 10-8, позволяет создавать отчеты о диапазонах
значений «на лету». Таблица определения диапазона может содержать столько
наборов различных диапазонов отчетности, сколько требуется. Название определенной группы диапазонов хранится в столбце группа диапазонов. Таблица
определения диапазона соединяется с фактом баланса с помощью пары соединений «меньше» и «больше». Отчет использует имя диапазона в качестве заголовка строки и сортирует отчет по атрибуту порядка сортировки.
Таблица фактов ежемесячных
моментальных снимков счета
Ключ даты конца месяца (FK)
Ключ счета (FK)
Ключ продукта (FK)
Другие ключи …
Первичный баланс на конец месяца
Таблица определения диапазона
Ключ группы диапазона (PK)
Порядок сортировки диапазона (PK)
Название группы диапазона
Band Range Name
Нижнее значение диапазона
Верхнее значение диапазона
Рис. 10-8. Отчетность по динамическому диапазону значений
Контроль производительности этого запроса может оказаться непростой
задачей. Запрос диапазона значений по определению очень слабо ограничен.
Пример отчета требовал сканирования остатков более чем на 1 миллионе счетов. Возможно, только измерение «Месяц» было ограничено текущим месяцем.
Кроме того, соединения с таблицей группирования значений не являются основой хорошего ограничивающего ограничения, поскольку они группируют 1 миллион балансов. В этой ситуации вам может потребоваться разместить индекс
непосредственно на факте баланса. Производительность запроса, который ограничивает или группирует значение баланса, подобного факту, будет значительно улучшена, если СУБД сможет эффективно сортировать и сжимать отдельные
факты. Этот подход был впервые предложен продуктом колоночной базы данных
Sybase IQ в начале 1990-х годов и в настоящее время становится стандартным
вариантом индексирования в нескольких конкурирующих колоночных СУБД.
Схемы супертипов и подтипов
для разнородных продуктов
Во многих компаниях, оказывающих финансовые услуги, возникает дилемма
из-за неоднородного характера продуктов или услуг, предлагаемых учреждением.
Как упоминалось во введении, типичный розничный банк предлагает множество
продуктов от текущих счетов до кредитных карт одним и тем же клиентам. Хотя
каждый счет в банке имеет основной баланс и связанную с ним сумму процентов,
Финансовые услуги
367
каждый тип продукта имеет множество особых атрибутов и измеряемых фактов,
которые не являются общими для других продуктов. Например, текущие счета
имеют минимальные остатки, лимиты овердрафта, плату за обслуживание и другие меры, связанные с онлайн-банкингом; срочные депозиты, такие как депозитные сертификаты, имеют несколько атрибутов, совпадающих с текущим счетом,
но имеют сроки погашения, частоту начисления и текущую процентную ставку.
Бизнес-пользователям обычно требуются две разные точки зрения, которые
трудно представить в одной таблице фактов. Первая перспектива — это глобальный взгляд, включающий возможность одновременного анализа всех счетов независимо от типа их продукта. Этот глобальный взгляд необходим для планирования
соответствующих стратегий управления взаимоотношениями с клиентами, перекрестных продаж и повышения продаж в отношении совокупной базы клиентов
/ домашних хозяйств, охватывающей все возможные продукты. В этой ситуации
вам нужна единая таблица фактов супертипа (см. рис. 10-3), которая охватывает все
направления бизнеса, чтобы получить представление о полном портфеле счетов.
Обратите внимание, однако, что таблица фактов супертипа может содержать лишь
ограниченное количество фактов, которые имеют смысл практически для каждого
направления бизнеса. Вы не можете разместить несовместимые факты в таблице
фактов супертипа, потому что их может быть несколько сотен, когда рассматриваются все возможные типы счетов. Аналогичным образом измерение супертипа
«Продукт» должно быть ограничено подмножеством общих атрибутов продукта.
Таблица фактов текущего счета
Ключ месяца (FK)
Ключ счета (FK)
Ключ основного клиента (FK)
Ключ отрасли (FK)
Ключ домохозяйства (FK)
Ключ продукта (FK)
Баланс
Изменение в балансе
Всего депозит
Всего снято
Количество транзакций
Максимальная сумма на счету
Количество перерасходов
Всего пени за перерасход
Количество транзакций в местных банкоматах
Количество транзакций в иностранных банкоматах
Количество транзакций онлайн
Дней ниже минимума
+ 10 других фактов
Измерение «Текущий счет»
Ключ счета (PK)
Номер счета (NK)
Атрибуты адреса счета
Дата открытия счета
…
Измерение
«Продукты текущего счета»
Ключ продукта (PK)
Код товара (NK)
Описание товара
Флаг премиум
Тип проверки
Тип внесенного платежа
Политика перерасхода
+ 12 других атрибутов
Рис. 10-9. Схема подтипа направления деятельности для продуктов текущего
счета
368
Глава 10
Вторая перспектива — это взгляд на направление бизнеса, который фокусируется на подробных деталях одного бизнеса, таких как «Текущий счет». Существует длинный список особых фактов и атрибутов, которые имеют смысл только
для обслуживания текущего счета. Эти особые факты не могут быть включены
в таблицу фактов супертипа; если бы вы сделали это для каждого направления
бизнеса в розничном банке, вы бы получили сотни особых фактов, большинство
из которых имели бы пустые значения в любой конкретной строке. Аналогично
этому, если вы попытаетесь включить атрибуты направления деятельности в таблицы измерений счета или продукта, в этих таблицах будут сотни специальных
атрибутов, почти все из которых будут пустыми для любой заданной строки. Результирующие таблицы будут напоминать швейцарский сыр, усеянный дырами
в данных. Решение этой дилеммы для текущего счета в этом примере — создание
схемы подтипа для направления «Текущий счет», которая ограничена только
текущими счетами, как показано на рис. 10-9.
Теперь таблица фактов текущего счета и соответствующее измерение «Текущий
счет» расширены для описания всех конкретных фактов и атрибутов, которые имеют смысл только для продуктов текущего счета. Эти схемы подтипов также должны
содержать факты и атрибуты супертипа, чтобы избежать объединения таблиц из схем
супертипов и подтипов для полного набора фактов и атрибутов. Вы также можете
создавать отдельные таблицы фактов и счетов подтипов для других направлений
бизнеса, чтобы соответствовать их требованиям к углубленному анализу. Хотя создание схем для конкретного типа счета звучит сложно, только администратор базы
данных видит все таблицы одновременно. С точки зрения бизнес-пользователей это
либо анализ кросс-продукта, который опирается на единую таблицу фактов супертипа и сопутствующую таблицу счетов супертипа, либо анализ конкретного типа
счета, когда используется только одна из бизнес-схем подтипа. В общем, мало смысла объединять данные из более чем одной схемы подтипов, поскольку по определению факты и атрибуты счетов не связаны (или почти не связаны).
Ключи измерений счета подтипа — это те же ключи, которые используются в измерении счета супертипа, которое содержит все возможные ключи счета.
Например, если банк предлагает «минимальный баланс в размере 500 долларов
США без взимания платы за каждый чек», этот счет будет идентифицирован
одним и тем же суррогатным ключом в измерениях «Текущий счет» как супертипа, так и подтипа. Каждое измерение счета подтипа представляет собой уменьшенное согласованное измерение с подмножеством строк из таблицы измерений
счета супертипа; каждое измерение счета подтипа содержит атрибуты, относящиеся к определенному типу счета.
Этот метод проектирования супертипов/подтипов применим к любому бизнесу, предлагающему самые разнообразные продукты по нескольким
Финансовые услуги
369
направлениям. Если вы работаете в технологической компании, которая продает
оборудование, программное обеспечение и услуги, вы можете представить себе
создание таблиц фактов продаж супертипа и измерения «Продукт», чтобы обеспечить глобальную перспективу клиентов. Таблицы супертипов будут включать
все факты и атрибуты измерений, общих для всех направлений бизнеса. Затем
таблицы супертипов будут дополнены схемами — они позволяют глубоко изучить факты и атрибуты подтипов, которые варьируются в зависимости от бизнеса. Опять же, определенному продукту будет присвоен один и тот же суррогатный ключ продукта в измерениях как супертипа, так и подтипа продукта.
ПРИМЕЧАНИЕ Семейство таблиц фактов супертипов и подтипов необхо-
димо, когда бизнес имеет разнородные продукты, которые, естественно, имеют
разные факты и дескрипторы, но единую клиентскую базу, которая требует интегрированного представления.
Если направления деятельности в вашем розничном банке физически разделены таким образом, что каждое из них имеет собственное местоположение,
таблицы фактов и измерений подтипа, скорее всего, не будут располагаться
в том же пространстве, что и таблицы фактов и измерений супертипа. В этом
случае данные в таблице фактов супертипа будут продублированы ровно один
раз для реализации всех таблиц подтипов. Помните, что таблицы подтипов
обеспечивают разрозненное разделение счетов, поэтому схемы подтипов не пересекаются.
Супертипы и подтипы банковских продуктов с общими
фактами
Только что рассмотренный метод супертипа и подтипа продукта подходит для
таблиц фактов, где одна логическая строка содержит множество фактов, относящихся к конкретному продукту. С другой стороны, показатели, учитываемые
некоторыми бизнес-процессами, такими как запросы банка на открытие новых
счетов, могут не различаться в зависимости от сферы деятельности. В этом случае
вам не нужны таблицы фактов по каждой линии бизнеса; достаточно одной таблицы фактов супертипа. Тем не менее вы все равно можете иметь богатый набор
разнородных продуктов с различными атрибутами. В этом случае вы создадите
полный портфель таблиц измерений счетов подтипов и будете использовать их
по мере необходимости в зависимости от характера приложения. При анализе
кросс-продуктов будет использоваться таблица измерений счетов супертипа, поскольку она может охватывать любую группу счетов. При анализе одного типа
счета вы можете дополнительно использовать таблицу измерений счета подтипа
370
Глава 10
вместо измерения супертипа, если хотите воспользоваться преимуществами атрибутов подтипа, специфичных для этого типа счета.
Измерения с возможностью быстрой замены
У брокерской конторы может быть много клиентов, которые следят за фондовым
рынком. Все они получают доступ к одной и той же таблице фактов ежедневных
цен акций с максимумом и минимумом цены на момент закрытия. Но у каждого клиента есть определенный набор атрибутов, описывающих каждую акцию.
Брокерская контора может поддерживать эту ситуацию с несколькими клиентами, имея отдельную копию измерения «Акция» для каждого клиента, которая соединяется с единой таблицей фактов во время запроса. Мы называем эти
измерения «измерениями с возможностью быстрой замены». Для реализации
измерений с возможностью быстрой замены в реляционной среде ограничения
ссылочной целостности между таблицей фактов и различными таблицами измерений «Акция», вероятно, должны быть отключены, чтобы переключатели выполнялись на основе отдельного запроса.
Выводы
Мы начали эту главу с обсуждения ситуации, когда в таблице фактов слишком мало
измерений, и представили предложения по выявлению дополнительных измерений с использованием процесса рассмотрения. Были описаны подходы к решению
часто сложных взаимоотношений между счетами, клиентами и домохозяйствами.
Мы также обсудили использование нескольких мини-измерений в одной таблице
фактов, что довольно часто встречается в схемах финансовых услуг.
Мы проиллюстрировали метод кластеризации числовых фактов в произвольные диапазоны значений для целей отчетности с помощью отдельной таблицы
диапазонов. Наконец, мы предоставили рекомендации для любой организации,
которая предлагает разнородные продукты одному и тому же кругу клиентов.
В этом случае мы создаем таблицу фактов супертипа, содержащую показатели
производительности, общие для всех направлений бизнеса. Таблица сопутствующих параметров содержит строки для всего портфеля учетных записей, но атрибуты ограничены теми, что применяются ко всем учетным записям. Схемы
нескольких подтипов, по одной для каждой отрасли бизнеса, дополняют схему
супертипа действиями и атрибутами, специфичными для учетной записи.
11
Телекоммуникации
Э
та глава будет несколько отличаться от предыдущих. Мы начнем с обзора
тематического исследования, но на этот раз мы не будем разрабатывать
размерную модель с нуля. Вместо этого мы перейдем к середине проекта, чтобы
провести анализ и найти возможности для улучшения первоначальной схемы.
Основная часть этой главы посвящена выявлению конструктивных недостатков
в размерных моделях.
В качестве основы для тематического исследования мы будем использовать
сценарий выставления счетов, взятый из телекоммуникационной отрасли; ее характеристики сходны с данными выставления счетов, сгенерированными коммунальной компанией. В конце этой главы мы опишем обработку информации
о географическом местоположении в хранилище данных.
В главе 11 рассматриваются следующие концепции:
■ фрагмент матрицы шины для телекоммуникационной компании;
■ упражнение по обзору проекта;
■ контрольный список распространенных ошибок при проектировании;
■ рекомендуемая тактика при проведении обзоров дизайна;
■ модернизация существующих структур данных;
■ абстрактные измерения географического положения.
Тематическое исследование
телекоммуникаций и матрица шин
Учитывая ваш обширный опыт в области размерного моделирования (на данный момент 10 глав), вы недавно были приняты на новую должность в качестве разработчика размерного моделирования в команде DW/BI для крупной
компании беспроводной связи. В свой первый рабочий день, после нескольких
часов бумажной работы с персоналом и ознакомления, вы готовы приступить
к работе.
372
Глава 11
Работ
ник
Проф
ил
сл ь вызо
поддужбы ва
ержк
и
лан
Орган
и
прод зация
аж
Номе
обслу р линии
жива
ния
Комм
утато
р
ный п
Тариф
Товар
Покупка
X
X
Внутренняя инвентаризация
X
X
Инвентаризация каналов
X
X
Активация услуги
X
X
X
X
X
X
Продажи продукции
X
X
X
X
X
X
Участие в продвижении
X
X
X
X
X
X
Детализация звонков
X
X
X
X
X
X
Выставление счетов клиентам
X
X
X
X
X
X
Звонки в службу поддержки
клиентов
X
X
X
X
X
X
X
X
Заказ на ремонтные работы
X
X
X
X
X
X
Клие
Дата
нт
Команда DW/BI очень хочет, чтобы вы ознакомились с ее первоначальным
дизайном измерений. Пока кажется, что проект находится на хорошем старте.
Комитет по спонсорству со стороны бизнеса и ИТ высоко оценивает тот факт,
что программа DW/BI ориентирована на бизнес; таким образом, комитет полностью поддержал процесс сбора бизнес-требований. Завершив сбор требований,
команда разработала исходную матрицу шины хранилища данных, проиллюстрированную на рис. 11-1. Команда определила несколько основных бизнеспроцессов и ряд общих измерений. Конечно, полная матрица предприятия будет содержать гораздо больше строк и столбцов, но вы уверены, что основные
требования к данным ключевых участников были учтены.
X
X
X
X
Рис. 11-1. Пример строк матрицы шин для телекоммуникационной компании
Спонсорский комитет решил сосредоточиться на процессе выставления счетов клиентам для первоначального проекта DW/BI. Руководство бизнеса решило, что улучшение доступа к показателям, полученным в результате процесса
выставления счетов, окажет существенное влияние на бизнес. Руководству нужна
возможность просматривать ежемесячные показатели использования и выставления счетов (иначе известные как выручка) по клиентам, торговой организации
и тарифному плану для выполнения анализа каналов продаж и тарифного плана. К счастью, ИТ-команда сочла возможным заняться этим бизнес-процессом
во время первой итерации хранилища данных.
Некоторые сотрудники ИТ-организации сочли, что было бы предпочтительнее обрабатывать информацию об отдельных звонках и сообщениях, например
Телекоммуникации
373
о каждом вызове, инициированном или полученном с каждого телефона. Хотя
этот уровень детализированных данных позволил бы получить интересную информацию, объединенный комитет по спонсорству определил, что связанные
с ними данные создают больше проблем с точки зрения практической осуществимости, но не обеспечивают такой же краткосрочной ценности для бизнеса.
Измерение «Клиент»
Таблица фактов счетов
Измерение «Счет»
ID клиента (PK and NK)
Имя клиента
Адрес клиента
Город клиента
Штат клиента
Индекс клиента
Первоначальный кредитный
рейтинг
Номер счета (FK)
ID клиента (FK)
Номер организации
продаж (FK)
ID канала продаж (FK)
Код тарифного плана (FK)
Код типа тарифного плана
Количество звонков
Количество потраченных
минут
Количество минут,
потраченных ночью
и в выходные
Количество минут ожидания
Количество сообщений
Мегабайт данных
использовано
Плата за обслуживание
в этом месяце
Плата за обслуживание
в предыдущем месяце
Ежемесячная плата
за обслуживание
Сервисное обслуживание
за год на текущую дату
Плата за сообщение
Дата списания
Плата за ожидание
Налоги
Нормативные сборы
Номер счета
Номер сервисной линии
Дата выставления счета
Измерение
«Организация продаж»
Номер организации продаж
(PK and NK)
ID канала продаж
Измерение «Канал продаж»
ID канала продаж (PK and NK)
Название канала продаж
Измерение «Сервисная линия»
Номер сервисной линии (PK)
Код города сервисной линии
Дата открытия сервисной
линии
Измерение
«Тарифный план»
Код тарифного плана
(PK and NK)
Аббревиатура тарифного
плана
Минут в тарифном плане
Сообщений в тарифном
плане
Мегабайт интернета
в тарифном плане
Индикатор звонков
в выходные и ночью
Рис. 11-2. Проект схемы до рассмотрения проекта
Основываясь на указаниях спонсоров, команда более внимательно изучила
платежные данные клиентов. Каждый месяц операционная биллинговая система
генерирует счет для каждого телефонного номера, также известного как линия
обслуживания. Поскольку компания беспроводной связи располагает миллионами линий связи, это значительный объем данных. Каждая линия обслуживания
связана с одним клиентом. Однако у клиента может быть несколько линий беспроводной связи, которые отображаются как отдельные позиции в одном счете;
каждая линия обслуживания имеет собственный набор показателей выставления
счетов, таких как количество минут, количество текстовых сообщений, объем
данных и ежемесячная плата за обслуживание. Существует единый тарифный
план, связанный с каждой строкой услуг в счете, но этот план может меняться
374
Глава 11
по мере развития привычек клиентов. Наконец, организация продаж и канал
связаны с каждой линией обслуживания для оценки текущего потока доходов
от выставления счетов, генерируемого каждым партнером по каналу.
Работая в тесном сотрудничестве с представителями бизнеса и другими членами команды DW/BI, разработчик моделей данных разработал таблицу фактов,
в которой зернистость составляет одну строку на счет каждый месяц. Команда
с гордостью разворачивает свой шедевр размерного моделирования, как показано на рис. 11-2, и выжидающе смотрит на вас.
Что вы можете сказать о нем? Прежде чем двигаться дальше, пожалуйста, потратьте несколько минут на изучение разработки, представленной на рис. 11-2.
Попробуйте определить недостатки дизайна и предложить улучшения, прежде
чем читать дальше.
Общие соображения
по рассмотрению и оценке проекта
Прежде чем мы обсудим конкретные проблемы и потенциальные рекомендации для схемы на рис. 11-2, мы опишем проблемы проектирования, с которыми обычно сталкиваются при проведении обзоров проектирования. Не хочу
намекать на то, что команда DW/BI в этом тематическом исследовании попала
во все эти ловушки, но она собрала несколько из них. Упражнение по обзору
дизайна станет более эффективным инструментом обучения, если вы уделите
время тому, чтобы записать свои идеи относительно рис. 11-2, прежде чем продолжить.
Сбалансируйте бизнес-требования и исходные реалии
Размерные модели должны разрабатываться на основе комплексного понимания
потребностей бизнеса, а также реалий данных операционной системы. В то время как требования собираются от бизнес-пользователей, базовые исходные данные должны быть изучены. Модели, основанные исключительно на требованиях,
неизбежно включают элементы данных, которые невозможно получить. Между
тем модели, основанные исключительно на анализе данных исходной системы,
неизбежно пропускают элементы данных, которые имеют решающее значение
для бизнес-аналитики.
Сосредоточьтесь на бизнес-процессах
Как указано в главе 10, размерные модели должны быть разработаны таким образом, чтобы отражать основные события бизнес-процесса организации. Размерные модели не должны разрабатываться исключительно для предоставления
Телекоммуникации
375
конкретных отчетов или ответов на конкретные вопросы. Конечно, аналитические вопросы бизнес-пользователей имеют решающее значение, поскольку они
помогают определить, какие процессы приоритетны для бизнеса. Но размерные
модели, разработанные для составления конкретного отчета или ответа на конкретный вопрос, вряд ли выдержат испытание временем, особенно когда вопросы и форматы отчетов слегка изменены. Разработка размерных моделей, которые
более полно описывают лежащий в основе бизнес-процесс, более устойчива к изменениям. Размерные модели, ориентированные на процессы, также удовлетворяют аналитические потребности нескольких бизнес-подразделений; то же самое
определенно неверно, когда модели разработаны для удовлетворения конкретных потребностей одного отдела.
После построения базовых процессов может быть полезно разработать дополнительные схемы, такие как сводные агрегации, накопительные моментальные снимки (они просматривают рабочий поток процессов), сводные таблицы
фактов (объединяют факты из нескольких процессов с общей степенью детализации) или таблицы фактов подмножества, которые предоставляют доступ
к ограниченному подмножеству фактических данных для целей безопасности
или распространения данных. Но все это вторичные дополнения к основным
размерным моделям, ориентированным на процессы.
Зернистость
Первый вопрос, который всегда следует задавать во время анализа дизайна: «Какова зернистость таблицы фактов?» Удивительно, но вы часто получаете противоречивые ответы на этот запрос от команды дизайнеров. Объявление четкого
и краткого определения сути таблицы фактов имеет решающее значение для продуктивного моделирования. Проектная группа и деловые партнеры должны разделять общее понимание декларации о зернистости; без этого соглашения работа
по проектированию пойдет по кругу.
Конечно, если вы дочитали до этого места, вы знаете о нашем твердом убеждении в том, что таблицы фактов должны создаваться на минимально возможном уровне зернистости для максимальной гибкости и расширяемости,
особенно с учетом непредсказуемой фильтрации и группировок, требуемых
запросами бизнес-пользователей. Пользователям обычно не нужно просматривать одну строку за раз, но вы не можете предсказать все способы, которыми
они захотят просмотреть данные и построить агрегации. Определение минимально возможного уровня зернистости зависит от моделируемого бизнеспроцесса. В этом случае вы хотите реализовать наиболее подробные данные,
доступные для выбранного процесса выставления счетов, а не только те, что
доступны на предприятии.
376
Глава 11
Единая зернистость фактов
После того как зернистость таблицы фактов будет установлена, следует определить факты, соответствующие декларации о зернистости. Чтобы повысить производительность или снизить сложность запроса, агрегированные факты, такие
как итоговые данные за год, иногда попадают в строку фактов. Эти итоговые
значения опасны, потому что они не идеально аддитивные. Хотя итоговый показатель с начала года снижает сложность и время выполнения нескольких конкретных запросов, его наличие в таблице фактов требует двойного подсчета столбца
с начала года (или хуже), когда в результаты запроса включено более одной даты.
Важно, чтобы после выбора структуры таблицы фактов все дополнительные факты были представлены в едином виде.
Вам следует запретить использование текстовых полей, включая загадочные
индикаторы и флажки, в таблице фактов. Они почти всегда занимают больше
места в таблице фактов, чем суррогатный ключ. Что еще более важно, бизнеспользователям обычно требуется выполнять запросы, создавать ограничения
и формировать отчеты по этим текстовым полям. Вы можете обеспечить более
быстрые ответы и более гибкий доступ, обрабатывая эти текстовые значения
в таблице измерений вместе с описательными атрибутами свертки, связанными
с флагами и индикаторами.
Зернистость измерений и иерархии
Каждое из измерений, связанных с таблицей фактов, должно принимать одно
значение в каждой строке измерений таблицы фактов. Аналогично этому каждый из атрибутов измерения должен принимать одно значение для данной строки измерения. Если атрибуты имеют отношение «многие к одному», это иерархическое отношение может быть представлено в одном измерении. Как правило,
вам следует искать возможности свернуть или денормализовать иерархии измерений, когда это возможно.
Опытные разработчики моделей данных часто возвращаются к методам нормализации, которые они бесчисленное количество раз применяли в операционных моделях отношений между сущностями. Этим разработчикам часто необходимо напоминать, что нормализация абсолютно необходима для поддержки
обработки транзакций и обеспечения ссылочной целостности. Но размерные
модели поддерживают аналитическую обработку. Нормализация в размерной
модели отрицательно влияет на две цели модели — понятность и производительность. Хотя нормализация не запрещена в системе извлечения, преобразования и загрузки (ETL), где должна быть обеспечена целостность данных, она
создает дополнительную нагрузку на подсистемы обработки изменений.
Телекоммуникации
377
Иногда дизайнеры пытаются разобраться с иерархиями измерений в таблице
фактов. Например, вместо того чтобы иметь один внешний ключ для измерения
«Продукт», они включают отдельные внешние ключи для ключевых элементов
в иерархии продуктов, таких как «Бренд» и «Категория». Не успеете вы оглянуться, как компактная таблица фактов превратится в непослушную таблицу«сороконожку», соединяющуюся с десятками таблиц измерений. Если таблица
фактов содержит более 20 или около того внешних ключей, вам следует поискать
возможности для объединения или свертывания измерений.
В других местах нормализация проявляется в виде «снежинки» иерархических связей в отдельных таблицах измерений, связанных друг с другом. Мы,
как правило, также не одобряем эту практику. Хотя использование схемы типа
«снежинка» может уменьшить дисковое пространство, потребляемое таблицами измерений, экономия обычно незначительна по сравнению со всей средой
хранилища данных и редко компенсирует недостатки в простоте использования
или производительности запросов.
На протяжении всей этой книги мы время от времени обсуждали внешние
измерения как допустимые схемы типа «снежинка». Внешние измерения могут
быть полезными в габаритных конструкциях, но имейте в виду, что использование
внешних измерений для кластера с относительно низкой мощностью должно быть
скорее исключением, чем правилом. Будьте осторожны, чтобы не злоупотреблять
техникой внешних измерений и не использовать их часто в ваших схемах.
Наконец, иногда мы просматриваем таблицы измерений, содержащие строки
как для атомарных, так и для иерархических сводных данных, например строки
для продуктов и брендов в одной и той же таблице измерений. Эти измерения
обычно имеют контрольный атрибут «Уровень», позволяющий различать их
базовые и сводные строки. Эта модель была распространена и общепринята десятилетия назад, до появления навигационных возможностей и возможностей
агрегации. Однако мы не рекомендуем его дальнейшее использование, учитывая
высокую вероятность путаницы пользователей и риск перерасчета, если показатель уровня в каждом измерении не ограничен в каждом запросе.
Измерение «Дата»
Каждая таблица фактов должна содержать по крайней мере один внешний ключ
для явного измерения «Дата». Проектные группы иногда присоединяют общее
измерение «Дата» к таблице фактов, потому что они знают, что это наиболее
распространенное измерение, но затем не могут четко сформулировать, к чему
относится дата, что создает проблемы как для команды ETL, так и для бизнеспользователей.
378
Глава 11
Применение сегментов временных рядов вместо
атрибутов даты
Разработчики иногда вообще избегают таблицы измерения «Дата», представляя
временные ряды ежемесячных наборов фактов в одной строке таблицы фактов.
Устаревшие операционные системы могут содержать наборы показателей, которые
повторяются 12 раз в одной записи для представления месяца 1, месяца 2 и так
далее. С таким подходом связано несколько проблем. Во-первых, жестко заданная
идентичность временных интервалов негибкая. Когда вы заполняете все отрезки,
у вас остается неприятный выбор. Вы можете изменить таблицу, чтобы расширить
строку. В противном случае вы могли бы сдвинуть все на один столбец, отбросив
самые старые данные, но это наносит ущерб существующим приложениям запросов. Вторая проблема такого подхода заключается в том, что за все атрибуты даты
теперь отвечает приложение, а не база данных. Нет измерения «Дата», в котором
можно было бы разместить описания событий календаря для будущих ограничений. Наконец, подход с фиксированным интервалом неэффективен, если измерения проводятся только в определенный период, что приводит к появлению пустых
столбцов во многих строках. Вместо этого эти повторяющиеся временные интервалы должны быть представлены в виде отдельных строк в таблице фактов.
Вырожденные измерения
Вместо того чтобы рассматривать номера операционных транзакций, такие как
номер счета-фактуры или заказа, в качестве вырожденных измерений, команды иногда хотят создать отдельную таблицу-измерение для номера транзакции.
В этом случае атрибуты измерения «Номер транзакции» включают элементы
из записи заголовка транзакции, такие как «Дата транзакции» и «Клиент».
Помните, что номера транзакций лучше всего рассматривать как вырожденные измерения. Дата транзакции и клиент должны быть записаны как внешние
ключи в таблице фактов, а не как атрибуты в измерении «Транзакция». Следите за таблицей измерений, в которой столько же (или почти столько же) строк,
сколько в таблице фактов; это предупреждающий сигнал, что в таблице измерений может скрываться вырожденное измерение.
Суррогатные ключи
Вместо того чтобы полагаться на операционные ключи или идентификаторы, мы
рекомендуем использовать суррогатные ключи в качестве первичных ключей таблиц измерений. Единственное допустимое отклонение от этого руководства относится к высокопрогнозируемому и стабильному измерению «Дата». Если вам
неясны причины применения этой стратегии, мы предлагаем вернуться к главе 3,
чтобы освежить вашу память.
Телекоммуникации
379
Расшифровки и описания в измерениях
Все идентификаторы и коды в таблицах измерений должны сопровождаться описательными расшифровками. Эта практика часто кажется нелогичной опытным
разработчикам моделей данных, которые исторически пытались уменьшить избыточность данных, полагаясь на поисковые коды. В размерной модели атрибуты
измерений должны быть заполнены значениями, которые бизнес-пользователи
хотят видеть в отчетах BI и раскрывающихся меню приложений. Вам нужно избавиться от ошибочного представления о том, что бизнес-пользователи предпочитают работать с кодами. Чтобы убедить себя, прогуляйтесь до их офисов, чтобы
увидеть шпаргалки о декодировании, заполняющие их рабочие столы или расположенные на мониторах их компьютеров. Большинство пользователей не запоминают коды, кроме нескольких избранных. Новые же сотрудники совершенно
беспомощны, когда их атакуют длинным списком бессмысленных кодов.
Хорошая новость: расшифровки обычно могут быть получены из операционных систем с относительно минимальными дополнительными затратами или
накладными расходами. Иногда описания недоступны в операционной системе,
но должны быть предоставлены деловыми партнерами. В этих случаях важно определить стратегию постоянного обслуживания для поддержания качества данных.
Наконец, проектные группы иногда предпочитают встраивать логику маркировки в семантический слой инструмента BI, а не поддерживать ее с помощью
атрибутов таблицы измерений. Хотя некоторые инструменты BI предоставляют
возможность декодирования в приложении запросов или отчетов, мы рекомендуем вместо этого сохранять декодированные данные в виде элементов данных.
Приложения должны основываться на данных, чтобы свести к минимуму влияние
дополнений и изменений в декодировании. Конечно, декодирования, хранящиеся
в базе данных, также обеспечивают большую согласованность маркировки отчетов,
поскольку большинство организаций в итоге используют несколько продуктов BI.
Приверженность согласованности
И последнее, но, безусловно, не менее важное: проектные группы должны стремиться использовать общие согласованные измерения в моделях, ориентированных на процессы. Каждый должен серьезно отнестись к этому. Согласованные
измерения абсолютно необходимы для надежной архитектуры данных, которая
обеспечивает согласованность и интеграцию. Без согласованных измерений вы
неизбежно увековечите несовместимые представления о производительности
узкоспециализированных решений во всей организации. Кстати, таблицы измерений должны быть согласованы друг с другом и использоваться повторно независимо от того, используете ли вы слепо архитектуру Кимбалла с верой в чудо
или же вы приверженец веерной архитектуры. К счастью, операционные системы
380
Глава 11
управления основными данными облегчают разработку и внедрение согласованных измерений.
Рекомендации по рассмотрению проекта
Прежде чем перейти к обзору проекта модели на рис. 11-2, давайте рассмотрим некоторые практические рекомендации по проведению обзоров дизайна размерной
модели. Надлежащая предварительная подготовка повышает вероятность успешного рассмотрения. Вот несколько советов по подготовке к проверке дизайна:
■ Приглашайте нужных игроков.
Очевидно, что команда моделирования нуждается в участии, но вы также
хотите, чтобы представители команды разработчиков BI гарантировали,
что предлагаемые изменения улучшат удобство использования. Очень важно, чтобы за столом сидели люди, которые хорошо осведомлены о бизнесе
и его потребностях. Хотя в обзоре должны участвовать различные точки
зрения, не приглашайте на вечеринку 25 человек.
■ Назначьте кого-нибудь для фасилитации проведения рассмотрения.
Групповая динамика, политика и проблемы проектирования будут определять, должен ли фасилитатор быть нейтральным ресурсом или вовлеченной
стороной. Как бы то ни было, их роль состоит в том, чтобы поддерживать
команду на пути к общей цели. Эффективные фасилитаторы нуждаются
в правильном сочетании интеллекта, энтузиазма, уверенности, сочувствия,
гибкости, уверенности в себе (и чувства юмора).
■ Согласовывайте объем рассмотрения.
Во время рассмотрения неизбежно возникнут дополнительные темы,
но предварительное согласование сферы охвата облегчает сосредоточение
внимания на поставленной задаче.
■ Блокируйте время в календаре каждого пользователя.
Обычно мы проводим обзоры размерных моделей в качестве целенаправленной двухдневной работы. Вся группа по проверке должна присутствовать в течение полных двух дней. Не позволяйте игрокам входить и выходить, чтобы выполнить другие дела. Обзоры дизайна требуют пристального
внимания; это очень отвлекает, когда участники периодически уходят.
■ Зарезервируйте нужное место.
Один и тот же конференц-зал должен быть заблокирован на целых два дня.
Оптимально, чтобы в комнате была большая белая доска; это особенно
полезно, если рисунки на белой доске можно сохранить или распечатать.
Если белая доска недоступна, имейте под рукой ватман или даже несколько. Не забудьте маркеры и скотч; напитки и еда также помогают.
Телекоммуникации
381
■ Назначьте домашнее задание.
Например, попросите всех участников составить список из пяти главных
проблем, проблемных областей или возможностей для улучшения существующего дизайна. Поощряйте участников использовать полные предложения при составлении своего списка, чтобы он был значим для других.
Эти списки должны быть отправлены фасилитатору до рассмотрения
проекта для консолидации. Запрашивание предварительной информации
вовлекает людей и помогает избежать группового мышления во время проверки.
После того как команда соберется, чтобы сосредоточиться на обзоре, мы рекомендуем следующую тактику:
1. Проверьте настроенность команды. Хотя это легче сказать, чем сделать,
не защищайте решение разработчиков. Приступайте к обзору, думая, что
перемены возможны; не смиряйтесь с мыслью, что ничего нельзя сделать
для улучшения ситуации.
2. Запретите использование гаджетов, если это не необходимо для процесса проверки. Ноутбуки и смартфоны также следует отнимать у двери
(по крайней мере, фигурально). Разрешение участникам проверять электронную почту во время сессий ничем не отличается от их ухода для участия в альтернативном собрании.
3. Продемонстрируйте сильные навыки фасилитации. Огласите основные
правила и убедитесь, что все открыто участвуют и общаются. Фасилитатор
должен направлять группу в правильное русло и запрещать сторонние разговоры и дискуссии, которые выходят за рамки или уводят в сторону.
4. Обеспечьте общее понимание текущей модели. Не думайте, что у всех
за столом уже есть хорошее понимание предоставленного дизайна. Возможно, имеет смысл посвятить первый час ознакомлению с текущим проектом и обзору целей, прежде чем углубляться в потенциальные улучшения.
5. Назначьте кого-нибудь в качестве стенографиста. Он должен делать подробные заметки как об обсуждениях, так и о принимаемых решениях.
6. Начните с общей картины. Точно так же, как при проектировании с чистого листа, начните с матрицы шин. Сосредоточьтесь на одном высокоприоритетном бизнес-процессе, определите его зернистость, а затем переходите к соответствующим измерениям. Следуйте тому же методу «снятия
шелухи с лука» с обзором дизайна; начните с таблицы фактов, а затем решайте проблемы, связанные с измерениями. Но не откладывайте трудные
дела на вторую половину второго дня.
382
Глава 11
7. Напомните всем, что принятие бизнесом имеет решающее значение.
Признание бизнесом — конечная мера успеха DW/BI. Обзор должен быть
направлен на улучшение работы бизнес-пользователей.
8. Набросайте примерные строки со значениями данных. Просмотр примеров данных во время сеансов обзора помогает убедиться, что у всех есть
общее понимание рекомендуемых улучшений.
9. Завершите собрание кратким изложением. Не позволяйте участникам
покидать комнату без четких ожиданий относительно их заданий и сроков
выполнения, а также установленного времени для следующего собрания.
После того как команда завершит совещание по рассмотрению проекта, вот
несколько рекомендаций по завершении процесса:
1. Назначьте ответственность за любые оставшиеся нерешенными вопросы. Обязуйтесь решать эти проблемы на местах после обзора, даже если это
может быть непросто без участия авторитетной стороны.
2. Не позволяйте тяжелой работе команды пылиться на полке. Оцените
затраты и выгоду для потенциальных улучшений; некоторые изменения
будут более безболезненными (или болезненными), чем другие. Затем необходимо разработать планы действий по внедрению улучшений.
3. Будьте готовы к будущим обзорам. Планируйте пересматривать модели
каждые 12–24 месяца. Старайтесь рассматривать неизбежные изменения
в дизайне как признаки успеха, а не неудачи.
Обсуждение эскизного проекта
Теперь, когда вы рассмотрели распространенные ошибки размерного моделирования, часто встречающиеся при рассмотрении проекта, обратитесь к эскизному
проекту на рис. 11-2. У вас сразу должно появиться несколько возможностей для
улучшения.
Первое, на чем следует сосредоточиться, — это содержание таблицы фактов.
Команда заявила, что зернистость составляет одну строку для каждого счета
каждый месяц. Однако, исходя из вашего понимания исходной системной документации и анализа данных, самый низкий уровень данных для выставления счетов будет составлять одну строку на услугу в счете. Когда вы указываете
на это, команда сначала направляет вас к измерению «Счет», которое включает услугу. Однако, если им напомнить, что каждая услуга имеет собственный
набор показателей выставления счетов, команда соглашается с тем, что более
подходящей декларацией зернистости будет одна строка на услугу на счет.
Телекоммуникации
383
Ключ услуги перемещается в таблицу фактов в качестве внешнего ключа для
измерения «Услуга».
При обсуждении зернистости тщательно изучается измерение «Счет»,
особенно потому, что ключ услуги был только что перенесен в таблицу фактов.
Поскольку проект модели был первоначально нарисован на рис. 11-2, каждый
раз, когда строка счета загружается в таблицу фактов, строка также загружается
в таблицу измерения «Счет». Не нужно много усилий, чтобы убедить команду:
с этой картиной что-то не так. Даже с измененной детализацией для включения услуги у вас все равно будет почти столько же строк как в таблицах фактов,
так и в таблице измерения «Счет», потому что многим клиентам выставляются
счета за одну услугу. Вместо этого номер счета следует рассматривать как вырожденное измерение. В то же время вы перемещаете дату счета в таблицу фактов
и объединяете ее с надежным измерением «Дата», играющим роль «Даты биллинга» в этой схеме.
Вероятно, вас беспокоили двойные соединения в таблице измерения «Канал
продаж» с тех пор, как вы впервые посмотрели на дизайн. Иерархия каналов
продаж была излишне нормализована. Вы решаете свернуть иерархию, включив
идентификаторы каналов продаж (надеюсь, вместе с более значимыми дескрипторами) в качестве дополнительных атрибутов в таблицу измерения «Организация продаж». Кроме того, вы можете удалить ненужный внешний ключ канала
продаж в таблице фактов.
В представленном дизайне неправильно создан код типа тарифного плана
как текстовый факт. Текстовые факты — редкий признак правильного дизайна.
В этом примере код типа тарифного плана и его декодирование можно рассматривать как атрибуты таблицы измерения «Тарифный план».
Команда потратила некоторое время на обсуждение взаимосвязи между услугой и клиентом, организацией продаж и измерением «Тарифный план». Поскольку с услугой связан один клиент, организация продаж и тарифный план,
теоретически измерения можно свернуть и смоделировать как атрибуты услуги.
Однако сворачивание измерений приведет к созданию схемы только с двумя измерениями: датой счета и услугой. Измерение «Услуга» уже содержит миллионы
строк и быстро растет. В конце концов вы решаете рассматривать клиента, торговую организацию и тарифный план как отдельные объекты (или мини-измерения) услуги.
Суррогатные ключи используются непоследовательно во всем дизайне.
Во многих таблицах черновиков измерений в качестве первичных ключей используются операционные идентификаторы. Вы поощряете команду внедрять
суррогатные ключи для всех первичных ключей измерений, а затем ссылаться
на них как на внешние ключи таблицы фактов.
384
Глава 11
Оригинальный дизайн был пронизан операционными кодами и идентификаторами. Добавление описательных имен делает данные более удобочитаемыми
для бизнес-пользователей. Если того требует бизнес, операционные коды могут
продолжать сопровождать дескрипторы в качестве атрибутов измерения.
Наконец, вы замечаете, что в таблице фактов хранится показатель с начала года
и до сегодняшнего дня. Хотя команда посчитала, что это позволит пользователям легче вычислять данные с начала года и до сегодняшнего дня, на самом деле такие факты
могут сбивать с толку и приводить к ошибкам. Вы решаете удалить этот факт. Вместо
этого пользователи могут рассчитать суммы с начала года на лету, используя ограничение на год в измерении «Дата» или используя возможности инструмента BI.
После двух изнурительных дней первоначальный обзор дизайна завершен.
Конечно, здесь еще многое предстоит обсудить, включая обработку изменений
атрибутов измерений. В то же время все члены команды согласны с тем, что обновленный дизайн, проиллюстрированный на рис. 11-3, значительно улучшился.
Вы отработали свою зарплату за первую неделю.
Таблица фактов счетов
Измерение «Клиент»
Ключ клиента (PK)
ID клиента (NK)
Имя клиента
Адрес клиента
Город клиента
Штат клиента
Почтовый индекс клиента
Первоначальный кредитный
рейтинг
Измерение
«Организация продаж»
Ключ организации
продаж (PK)
Номер организации продаж
Наименование организации
продаж
ID канала продаж
Название канала продаж
Ключ даты выставления
счета (FK)
Ключ клиента (FK)
Ключ сервисной линии (FK)
Ключ организации продаж (FK)
Ключ тарифного плана (FK)
Номер счета (DD)
Количество звонков
Количество потраченных минут
Количество минут,
потраченных ночью
и в выходные
Количество минут ожидания
Количество сообщений
Мегабайтов данных
использовано
Ежемесячная плата
за обслуживание
Плата за сообщение
Дата списания
Плата за ожидание
Налоги
Нормативные сборы
Рис. 11-3. Проект схемы после рассмотрения проекта
Измерение
«Дата выставления счета»
Измерение «Услуга»
Ключ услуги (PK)
Номер услуги (NK)
Код области услуги
Дата активации услуги
Измерение
«Тарифный план»
Ключ тарифного плана (PK)
Код тарифного плана
Название тарифного
плана
Аббревиатура тарифного
плана
Код типа тарифного плана
Описание типа тарифного
плана
Минут в тарифном плане
Сообщений в тарифном
плане
Мегабайт интернета
в тарифном плане
Индикатор звонков
в выходные и ночью
Телекоммуникации
385
Изменение существующих структур данных
Одно дело провести обзор и определить возможности для улучшения. Однако
о внедрении изменений проще сказать, чем сделать, если проект уже реализован
физически.
Например, добавление нового атрибута в существующую таблицу измерений
выглядит как незначительное улучшение. Это почти безболезненно, если бизнес-управляющий данными заметит, что это медленно изменяющийся атрибут
измерения типа 1. Также не много хлопот доставит ситуация, когда атрибут необходимо заполнять, начиная с текущего момента, но в уже имеющихся записях его можно заполнить как «Значение недоступно»; обратите внимание, что,
хотя эта тактика относительно проста в реализации, она создает аналитические
проблемы и может быть сочтена неприемлемой. Но если новый атрибут относится к атрибуту типа 2 с требованием фиксировать исторические изменения,
это, казалось бы, простое улучшение стало намного сложнее. В этом сценарии необходимо добавить строки в таблицу измерений, чтобы отразить исторические
изменения атрибута, а также изменения других атрибутов измерения. Затем необходимо изменить некоторые строки таблицы фактов, чтобы соответствующая
строка таблицы измерений была связана с событием таблицы фактов. Этот наиболее надежный подход потребляет на удивление больше энергии, чем вы могли
себе представить поначалу.
Гораздо менее удивительны трудозатраты, необходимые, чтобы взять существующую размерную модель и преобразовать ее в структуру, которая использует вновь созданные согласованные размеры. Как обсуждалось в главе 4, как
минимум строки таблицы фактов должны быть полностью переработаны, чтобы
ссылаться на соответствующие ключи измерений. Очевидно, что задача усложняется, если возникают проблемы с зернистостью или иные серьезные проблемы.
В дополнение к размышлениям о проблемах, связанных с модернизацией
существующих структур данных, в приложениях для отчетности и анализа BI,
построенных на существующей базе данных, также возникают нежелательные казусы. Использование представлений как буферов между приложениями BI и физическими структурами данных обеспечивает некоторое облегчение, но обычно
этого недостаточно, чтобы избежать неприятных сбоев в среде BI.
Рассматривая возможность улучшить существующие структуры данных, вы
должны оценить затраты на внесение изменений наряду с предполагаемыми
выгодами. Во многих случаях вы решите, что улучшения необходимо внести несмотря на затраты и неудобства. Аналогичным образом вы можете определить,
что наилучший подход — вывод из эксплуатации существующих структур, чтобы избавить их от страданий и заняться предметной областью с чистого листа.
386
Глава 11
Наконец, в некоторых ситуациях лучший подход состоит в том, чтобы просто игнорировать неоптимальные структуры данных, поскольку затраты по сравнению
с потенциальными выгодами не оправдывают усилий по реконструкции и улучшению схемы. Иногда наилучшим моментом для изменения структуры данных
становится внесение в рабочий процесс других изменений, таких как переход
на новую систему или на новый стандарт BI-инструментов.
Измерение «Географическое положение»
Давайте для разнообразия предположим, что вы работаете в телефонной компании с наземными линиями, привязанными к определенному физическому местоположению. Отрасли телекоммуникаций и коммунальных услуг имеют очень
хорошо развитое представление о местоположении. Многие из их измерений
содержат точное географическое местоположение как часть набора атрибутов.
Местоположение может быть определено как физическая улица, город, штат,
почтовый индекс, широта и долгота. Геокодирование широты и долготы может
быть использовано для геопространственного анализа и визуализации, использующей карты.
Некоторые разработчики представляют себе единую таблицу основных местоположений, в которой данные об адресах стандартизированы, а затем измерение «Местоположение» привязывается в качестве внешнего выносного
измерения к номеру телефона линии обслуживания, инвентарю оборудования,
инвентарю сети (включая столбы и распределительные коробки), инвентарю недвижимости, местоположению службы, местоположению отправки, праву проезда и объектам клиентов. В этом сценарии каждая строка в основной таблице
местоположений представляет собой определенную точку в пространстве, которая сводится ко всем мыслимым географическим группам.
Стандартизация атрибутов, связанных с точками в пространстве, имеет большое значение. Однако это скрытая задача ETL; вам не нужно раскрывать бизнеспользователям единую результирующую таблицу, содержащую все адреса, с которыми взаимодействует организация. Географическая информация естественным
образом обрабатывается как атрибуты в различных измерениях, а не как отдельное измерение местоположения или внешнее измерение. Как правило, географические местоположения, включенные в различные измерения, практически
не пересекаются. Вы заплатили бы высокую цену за объединение всех разрозненных адресов в одно измерение.
Операционные системы часто используют абстракцию данных, но обычно следует избегать общих абстрактных измерений, таких как обобщенное измерение «местоположение» в области представления DW/BI, поскольку они
Телекоммуникации
387
негативно влияют на простоту использования и производительность запросов.
Эти структуры более приемлемы за кулисами ETL.
Выводы
В этой главе была представлена возможность проанализировать проект с использованием примера тематического исследования. В нем содержались рекомендации по проведению эффективных обзоров имеющихся разработок, а также краткий список распространенных недостатков дизайна, которые следует учитывать
при проведении обзора. Мы рекомендуем вам использовать этот список задач
для просмотра ваших собственных проектов при поиске возможностей для потенциальных улучшений.
12
Т
Транспортировка
ранспортировка происходит всякий раз, когда человек или вещь путешествуют из одной точки в другую, возможно, с остановками. Очевидно,
что путешествия — фундаментальная концепция для организаций туристической индустрии. К обсуждению также относятся грузоотправители и внутренние логистические функции, а также службы доставки посылок и компании по прокату автомобилей. Несколько неожиданно то, что многие схемы
этой главы применимы также к анализу маршрутов телекоммуникационных
сетей; телефонную сеть можно рассматривать как карту возможных маршрутов, которые совершает звонок между исходными и конечными телефонными
номерами.
В этой главе мы будем использовать тематическое исследование авиакомпаний для изучения рейсов и маршрутов, потому что многие читатели знакомы
(возможно, слишком хорошо знакомы) с этой темой. Тематическое исследование
позволяет обсудить несколько таблиц фактов с разной зернистостью. Мы также
подробно остановимся на ролевых измерениях и дополнительных соображениях, касающихся измерения даты и времени. Как обычно, целевая аудитория этой
главы не должна ограничиваться ранее перечисленными отраслями промышленности.
В главе 12 рассматриваются следующие концепции:
■ фрагмент матрицы шин для авиакомпании;
■ таблицы фактов на разных уровнях зернистости;
■ объединение взаимосвязанных ролевых измерений;
■ измерение «Дата» для конкретной страны;
■ Даты и время в нескольких часовых поясах;
■ краткое описание проблем локализации.
390
Глава 12
Тематическое исследование
авиакомпаний и матрица шин для них
Пасса
К
брон анал
иров
ания
Класc
бслуж
ивани
я
Осно
вной
тариф
Возду
ш
судноное
X
X
X
X
X
X
X
X
Conf #
Выданные билеты
X
X
X
X
X
X
X
X
Conf #
Ticket #
Неполученный доход
и доступность
X
X
X
Активность полетов
X
X
X
X
X
X
X
Баллы на счете часто
летающих пассажиров
X
X
X
X
X
X
Взаимодействие с клиентами
X
X
X
X
X
Взаимодействие с часто
летающими клиентами
X
X
X
X
X
Подряды
на поддерживающие работы
X
X
X
Расписание работы экипажа
X
X
X
X
анзак
ID тр
иль с
Проф
X
Conf #
Ticket #
X
Conf #
Ticket #
X
X
ции
Аэро
порт
жир
Врем
Бронь
вязи
я
Дата
Мы начнем с изучения упрощенной матрицы шин, а затем углубимся в таблицы
фактов, связанные с полетной активностью.
На рис. 12-1 показан фрагмент матрицы шины авиакомпании. Этот пример
включает дополнительный столбец для отображения вырожденного измерения,
связанного с большинством событий процесса шины. Как и большинство организаций, авиакомпании остро заинтересованы в доходах. В этой отрасли продажа билета представляет собой незаработанный доход; доход получается, когда
пассажир совершает рейс между аэропортами отправления и назначения.
Case #
Ticket #
Work
Order #
X
Рис. 12-1. Подмножество строк матрицы шин для авиакомпании
Представители бизнеса и команды DW/BI решают, что первый результат должен быть сосредоточен на полетной деятельности. Отдел маркетинга хочет проанализировать, какие рейсы совершают часто летающие пассажиры компании,
Транспортировка
391
какой тариф они оплачивают, как часто они повышают класс, как они зарабатывают и используют свои мили для часто летающих пассажиров, участвуют ли
они в специальных акциях по тарифам, как долго они остаются на ночь и какая
доля этих часто летающих пассажиров имеет статус золотых, платиновых, алюминиевых и титановых клиентов. Первый проект не фокусируется на данных
о бронировании или продаже билетов, которые не привели к посадке пассажира
в самолет. Команда DW/BI будет работать с этими другими источниками данных
на последующих этапах.
Зернистость нескольких таблиц фактов
Когда дело доходит до зернистости, когда вы работаете над четырехэтапным процессом проектирования, то в этом случае представлено несколько потенциальных уровней зернистости таблицы фактов, каждый из которых имеет различные
связанные показатели.
На самом гранулярном уровне авиакомпания собирает данные на уровне
рейса. Рейс представляет собой самолет, взлетающий в одном аэропорту и приземляющийся в другом без каких-либо промежуточных остановок. Аналитики
по планированию вместимости и планированию полетов заинтересованы в этом
дискретном уровне информации, поскольку они могут посмотреть на количество
мест для расчета коэффициентов загрузки рейса. Эксплуатационные показатели
полета воздушных судов, такие как продолжительность полета и количество минут опоздания на вылет и прибытие, фиксируются на уровне рейса. Возможно,
есть даже измерение, позволяющее легко идентифицировать прибытие вовремя.
Следующий уровень детализации соответствует сегменту. Сегменты относятся к одному номеру рейса (например, номер рейса Delta 40 или DL0040), выполняемому одним самолетом. Сегменты могут иметь одну или несколько связанных
с ними рейсов; в большинстве случаев сегменты состоят только из одного рейса
с одним взлетом и посадкой. Если вы летите рейсом из Сан-Франциско в Миннеаполис с остановкой в Денвере, но не меняете номер самолета или рейса, у вас
есть один сегмент (SFO — MSP), но два рейса (SFO — DEN и DEN — MSP).
И наоборот, если бы полет проходил без остановок из Сан-Франциско в Миннеаполис, у вас был бы один сегмент и один рейс. Сегмент представляет собой
позицию в купоне на авиабилет; доходы от пассажиров и мили определяются
на уровне сегмента. Таким образом, хотя некоторые отделы авиакомпаний сосредоточены на операциях на уровне рейса, группы маркетинга и доходов сосредоточены на показателях на уровне сегмента.
Затем вы можете проанализировать полетную активность по поездкам. Поездка дает точную картину потребительского спроса. В предыдущем примере
предположим, что рейсы из Сан-Франциско в Миннеаполис требовали, чтобы
392
Глава 12
путешественник пересел на другой самолет в Денвере. В этом случае поездка
из Сан-Франциско в Миннеаполис повлечет за собой два сегмента, соответствующих двум задействованным воздушным судам. На самом деле пассажир просто
добирался из Сан-Франциско в Миннеаполис; тот факт, что ему пришлось
остановиться в Денвере, просто неизбежное зло. По этой причине аналитики
по продажам и маркетингу также интересуются данными на уровне поездок.
Наконец, авиакомпания собирает данные для маршрута, которые эквивалентны полному номеру подтверждения авиабилета или бронирования.
Таблица фактов полетной
активности на уровне сегментов
Измерение «Дата» (2 роли)
Измерение «Пассажир»
Измерение «Профиль пассажира»
Измерение «Класс обслуживания»
Измерение «Канал бронирования»
Ключ даты вылета
по расписанию (FK)
Ключ времени вылета
по расписанию (FK)
Ключ действительной даты
вылета (FK)
Ключ действительного времени
вылета (FK)
Ключ пассажира (FK)
Ключ профиля пассажира (FK)
Ключ аэропорта отправления
сегмента (FK)
Ключ аэропорта назначения
сегмента (FK)
Ключ воздушного судна (FK)
Ключ класса обслуживания (FK)
Ключ тарифа (FK)
Ключ канала бронирования (FK)
Номер подтверждения (DD)
Номер билета (DD)
Порядковый номер сегмента (DD)
Номер рейса (DD)
Плата по тарифу
Сервисный сбор с пассажиров
Сбор аэропорта
Правительственный сбор
Плата за багаж
Плата за апгрейд билета
Комиссия за транзакцию
Мили потраченные
Мили заработанные
Измерение «Время дня» (2 роли)
Измерение «Аэропорт» (2 роли)
Измерение «Воздушное судно»
Измерения «Тариф»
Рис. 12-2. Начальный сегмент схемы полетов
Команда DW/BI и представители бизнеса решают начать с зернистости
на уровне сегмента. Это представляет собой самый низкий уровень данных
со значимыми показателями дохода. В качестве альтернативы вы можете использовать бизнес-правила для распределения показателей на уровне сегмента
Транспортировка
393
по рейсам, возможно, на основе миль для каждого рейса в сегменте. Хранилище
данных неизбежно будет обрабатывать более детализированные данные на уровне рейсов для планировщиков пропускной способности и на уровне расписания рейсов в какой-то момент в будущем. Согласованные измерения, созданные
во время этой первой итерации, будут использованы в это время.
В таблице фактов будет одна строка для каждого посадочного талона, полученного от пассажиров. Размерность, связанная с этими данными, довольно обширна, как показано на рис. 12-2. Схема широко использует технику ролевых
измерений. Множественные измерения даты, времени и аэропорта связаны
с представлениями одной базовой таблицы физических измерений даты, времени и аэропорта соответственно, как мы первоначально обсуждали в главе 6.
Измерение «Пассажир» — это измерение с богатыми характеристиками,
отражающими наиболее ценных, часто летающих пассажиров. Интересно, что
часто летающие пассажиры мотивированы помогать точно поддерживать это измерение, потому что они хотят убедиться, что получают соответствующие мили
за полеты. Для крупной авиакомпании это измерение насчитывает от десятков
до сотен миллионов строк.
Ключ профиля
пассажира
Уровень часто
летающих
пассажиров
Аэропорт
отправления
Статус членства
в клубе
1
2
3
Базовый
Базовый
Базовый
ATL
ATL
BOS
Не член
Член клуба
Не член
...
789
...
Средний
...
ATL
...
Не член
790
Средний
ATL
Член клуба
791
...
2468
2469
2470
...
Средний
...
Высокий
Высокий
Высокий
BOS
...
ATL
ATL
BOS
...
Не член
...
Член клуба
Член клуба
Член клуба
...
...
Заработанные мили
за все время
Менее 100 000 миль
Менее 100 000 миль
Менее 100 000 миль
…
100 000–499 999 миль
100 000–499 999 миль
100 000–499 999 миль
…
1 000 000–1 999 999 миль
2 000 000–2 999 999 миль
1 000 000–1 999 999 миль
...
Рис. 12-3. Образцы рядов для подмножества пассажиров
Цель маркетологов — проанализировать активность на уровне часто летающих пассажиров, которые могут меняться в течение года. Кроме того, в процессе
определения требований вы узнали, что пользователи заинтересованы в выборках и срезах в зависимости от аэропортов, вылетов, принадлежат ли они к клубу
аэропортов авиакомпании во время каждого рейса, и количество накопленных
394
Глава 12
ими миль. Учитывая требования к отслеживанию изменений в сочетании с размером измерения «Пассажир», мы решили создать отдельное мини-измерение
«Профиль пассажира», как мы обсуждали в главе 5, с одной строкой для каждой
уникальной комбинации уровня элитности часто летающих пассажиров, аэропорта отправления, статуса членства в клубе и количества накопленных миль.
Примеры строк для этого мини-измерения показаны на рис. 12-3. Вы рассматривали эти атрибуты как медленно изменяющиеся атрибуты типа 2, особенно
потому, что атрибуты быстро не меняются. Но, учитывая количество пассажиров, вместо этого вы выбираете мини-измерение 4-го типа. Как выясняется, маркетинговые аналитики часто используют это мини-измерение для своего анализа
и отчетности, не затрагивая миллионы строк измерения «Пассажир».
Измерение «Самолет» содержит информацию о каждом самолете, который
у вас есть. Аэропорты отправления и назначения, связанные с каждым рейсом,
указываются отдельно, чтобы упростить просмотр данных пользователем и повысить эффективность доступа.
Класс обслуживания, которым летел пассажир, определяет, сел ли он в эконом-,
премиум-эконом, бизнес-класс или первый класс. Измерение «Базовый тариф»
описывает условия, связанные с тарифом. В нем будет указано, неограниченный ли
это тариф, тариф предварительной покупки за 21 день со штрафами за изменение
и отмену или 10-процентной скидкой в связи со специальной акцией.
Измерение «Канал продаж» определяет, как был приобретен билет, будь
то туристическое агентство, непосредственно по номеру телефона авиакомпании,
городской билетный офис или веб-сайт или другой поставщик туристических
услуг онлайн. Хотя канал продаж относится ко всему билету, каждый сегмент
должен наследовать размерность от уровня билета. Кроме того, с данными о полетной деятельности связано несколько оперативных номеров, включая номер
маршрута, номер билета, номер рейса и порядковый номер сегмента.
Факты, отраженные на уровне зернистости сегмента, включают доходы
от базового тарифа, сборы за обслуживание пассажиров, аэропортовые и государственные налоги, другие дополнительные сборы и сборы, собственные мили
сегмента и начисленные мили сегмента (в тех случаях, когда начисляется минимальное количество миль независимо от расстояния полета).
Объединение сегментов в поездки
Несмотря на мощную размерную структуру, которую вы только что разработали,
вы не можете легко ответить на один из самых важных вопросов о ваших часто
летающих пассажирах: «Куда они направляются?» Зернистость на уровне сегмента скрывает истинную природу поездки. Если вы выберете все сегменты поездки и упорядочите их по номеру сегмента, все равно практически невозможно
Транспортировка
395
различить начальную и конечную точки поездки. Большинство полных маршрутов начинаются и заканчиваются в одном и том же аэропорту. Если бы длительная остановка использовалась в качестве критерия для значимого пункта назначения поездки, это потребовало бы обширной и сложной обработки на уровне
отчетов BI всякий раз, когда вы пытаетесь суммировать поездки.
Ответ заключается в том, чтобы ввести еще два ролевых измерения «Аэропорт»: пункт отправления и пункт назначения, сохраняя при этом зернистость
на уровне сегмента полета. Они определяются во время извлечения данных путем просмотра билета на любую остановку продолжительностью более четырех
часов (официальное определение «остановки» у авиакомпаний). Вам необходимо проявлять некоторую осторожность при обобщении данных по поездкам в этой схеме. Некоторые измерения, такие как «Базовый тариф» и «Класс
обслуживания», не применяются на уровне поездки. С другой стороны, может
быть полезно посмотреть, сколько поездок из Сан-Франциско в Миннеаполис
включали неограниченный тариф на сегмент.
В дополнение к привязке сегментов к поездкам в схеме полетной активности сегмента, если бизнес-пользователи постоянно просматривают информацию
на уровне поездки, а не по сегментам, вы можете создать сводную таблицу фактов на уровне поездки. Некоторые из ранее обсуждавшихся измерений, таких
как «Базовый тариф» и «Класс обслуживания», очевидно, будут неприменимы.
Факты будут включать агрегированные показатели, такие как общий базовый тариф за поездку или общие налоги за поездку, плюс дополнительные факты, которые будут отображаться только в этой дополнительной сводной таблице поездок,
например количество сегментов в поездке. Однако вам придется создавать эту
сводную таблицу только в том случае, если при использовании таблицы уровня
сегмента в качестве основы для свертки одних и тех же отчетов возникнут очевидные проблемы с производительностью или удобством использования. Если
типичная поездка состоит из трех сегментов, вы едва ли увидите трехкратное повышение производительности с помощью такой сводной таблицы, а это означает,
что, возможно, не стоит беспокоиться.
Таблицы связанных фактов
Как обсуждалось ранее, вы, скорее всего, создадите детальную таблицу фактов
о рейсах, чтобы удовлетворить более оперативные потребности, связанные с вылетом и прибытием каждого рейса. Показатели на уровне рейса могут включать
фактическую и заблокированную продолжительность полета, задержки вылета
и прибытия, а также объем топлива при отправлении и прибытии.
В дополнение к полетной активности будут представлены таблицы фактов для учета бронирований и выданных билетов. Учитывая нацеленность
396
Глава 12
на максимизацию доходов, для каждого рейса может быть создан снимок доходов
и доступности; он может предоставлять снимки за последние 90 дней, предшествующих вылету рейса, с совокупным незаработанным доходом и оставшейся
доступностью по классу обслуживания для каждого запланированного рейса.
Снимок может включать измерение, поддерживающее концепцию «N дней
до вылета», чтобы облегчить сравнение аналогичных рейсов на стандартных
этапах, таких как 60 дней до запланированного вылета.
Расширения для других
отраслей промышленности
Использование тематического исследования авиакомпании для иллюстрации
схемы «Путешествия» имеет интуитивный смысл, потому что большинство
людей в то или иное время садились в самолет. Мы кратко коснемся нескольких
других вариаций на эту тему.
Грузоотправитель
Таблица фактов перевозки на судне
Измерение «Дата» (2 роли)
Измерение «Режим судна»
Измерение «Контейнер»
Измерение «Товар»
Ключ даты путешествия (FK)
Ключ даты рейса (FK)
Ключ порта начала путешествия (FK)
Ключ порта окончания
путешествия (FK)
Ключ порта начала рейса (FK)
Ключ порта окончания рейса (FK)
Ключ режима судна (FK)
Ключ контейнера (FK)
Ключ товара (FK)
Ключ грузоотправителя (FK)
Ключ иностранного перевозчика (FK)
Ключ иностранного
консолидатора (FK)
Ключ морского перевозчика (FK)
Ключ своего консолидатора (FK)
Ключ своего перевозчика (FK)
Ключ грузополучателя (FK)
Номер накладной (DD)
Пошлины за рейс
Тарифы за рейс
Длина рейса
Измерение «Порт» (4 роли)
Измерение «Бизнес-объект» (7 ролей)
Рис. 12-4. Схема грузоперевозки
Схема для грузоотправителя выглядит очень похоже на только что разработанные схемы авиакомпаний. Предположим, что трансокеанская судоходная компания перевозит сыпучие грузы в контейнерах из зарубежных портов
Транспортировка
397
во внутренние. Товары в контейнерах отправляются от первоначального отправителя к получателю. Поездка может состоять из нескольких остановок в промежуточных портах. Возможно, контейнеры могут быть перегружены с одного
судна на другое в порту, также возможно, что один или несколько рейсов могут
быть доставлены грузовиком, а не кораблем.
Как показано на рис. 12-4, основа таблицы фактов — контейнер с определенным номером коносамента на определенном этапе его перевозки. Измерение «Режим судна» определяет тип судоходной компании и конкретное судно.
Измерение «Контейнер» описывает размер контейнера и то, требуется ли ему
электроэнергия или охлаждение. Измерение «Товар» описывает товар в контейнере. Почти все, что может быть отправлено, может быть описано гармонизированными товарными кодами. Это своего рода согласованное измерение, используемое агентствами, включая таможню США. Отправитель, иностранный
перевозчик, иностранный консолидатор, грузоотправитель, внутренний консолидатор, внутренний перевозчик и грузополучатель — все это роли, которые
выполняет основное измерение «Бизнес-объект». Это измерение содержит все
возможные деловые стороны, связанные с путешествием. Номер коносамента —
вырожденное измерение. Мы предполагаем, что сборы и тарифы применимы
к отдельным рейсам в путешествии.
Туристические услуги
Измерение «Дата» (3 роли)
Измерение «Отель»
Таблица фактов остановки
в отеле по работе
Ключ даты бронирования (FK)
Ключ даты прибытия (FK)
Ключ даты отправления (FK)
Ключ клиента (FK)
Ключ отеля (FK)
Ключ канала продаж (FK)
Номер подтверждения брони (DD)
Номер билета (DD)
Количество ночей
Дополнительная плата за номер
Дополнительные сборы
Измерение «Клиент»
Измерение «Канал продаж»
Рис. 12-5. Схема пребывания в отеле
Если вы работаете в компании, предоставляющей туристические услуги, вы
можете дополнить схему деятельности по полетам таблицами фактов для отслеживания соответствующего проживания в отелях и использования арендованного автомобиля. Эти схемы будут иметь несколько общих измерений, таких как
«Дата» и «Клиент». Для проживания в отеле зернистостью таблицы фактов
398
Глава 12
является весь эпизод проживания, как показано на рис. 12-5. Зернистостью аналогичной таблицы фактов аренды автомобилей был бы весь эпизод аренды. Конечно, если бы вы строили таблицу фактов для сети отелей, а не для компании,
предоставляющей туристические услуги, схема была бы намного более надежной,
потому что вы знали бы гораздо больше о характеристиках отеля, использовании
услуг гостем и связанных с ними подробных сборах.
Объединение коррелированных измерений
Ранее мы указывали, что, если между двумя группами атрибутов измерений существует связь «многие ко многим», их следует моделировать как отдельные
измерения с отдельными внешними ключами в таблице фактов. Однако иногда
возникают ситуации, когда эти измерения можно объединить в одно измерение,
а не рассматривать их как два отдельных измерения с двумя отдельными внешними ключами в таблице фактов.
Класс обслуживания
Чертеж схемы на рис. 12-2 включает измерение «Класс обслуживания», выполняемое на самолете. После рабочей встречи с бизнес-сообществом вы узнаете,
что пользователи также хотят проанализировать приобретенный класс бронирования. Кроме того, бизнес-пользователи хотят легко фильтровать и сообщать
об активности в зависимости от того, произошло ли обновление или понижение
класса обслуживания. Вашей первоначальной реакцией может быть включение
второго ролевого измерения и внешнего ключа в таблицу фактов для поддержки
как приобретенного, так и фактического класса услуг. Кроме того, вам понадобится третий внешний ключ для индикатора обновления; в противном случае приложение BI должно было бы включать логику для определения многочисленных
сценариев обновлений, включая варианты с эконом-класса до премиум-эконом,
с эконом-класса до бизнес-класса, с эконом-класса до первого класса, с премиумэконом-класса до бизнес-класса и так далее. В этой ситуации, однако, в таблице
измерений «Класс» есть только четыре строки для обозначения первого, бизнес-, премиум-эконом и эконом-классов. Измерение «Индикатор обновления»
также будет содержать всего три строки, соответствующие повышению, понижению или отсутствию изменения класса. Поскольку количество строк очень мало,
вы можете вместо этого объединить измерения в одно измерение «Класс обслуживания», как показано на рис. 12-6.
Декартово произведение измерений отдельных классов приводит к таблице измерений из 16 строк (4 строки для класса, указанного в билете при
Транспортировка
399
приобретении, умножаются на 4 строки, уточняющие фактический класс при
полете). У вас также есть возможность в этом объединенном измерении описать
взаимосвязь между приобретенными и фактическими классами, например индикатор изменения класса. Думайте об этом объединенном измерении «Класс
обслуживания» как о мусорном измерении, представленном в главе 6. В этом тематическом исследовании атрибуты тесно взаимосвязаны. Другие таблицы фактов авиакомпаний, такие как наличие билетов или покупки билетов, неизменно
ссылаются на соответствующую таблицу измерений «Класс», содержащую всего
четыре строки.
Ключ класса
обслуживания
Оплаченный
класс
Каким классом Группа купленная
летел
и полетная
Индикатор
изменения класса
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Эконом
Эконом
Эконом
Эконом
Прем. эконом
Прем. эконом
Прем. эконом
Прем. эконом
Бизнес
Бизнес
Бизнес
Бизнес
Первый
Первый
Первый
Первый
Эконом
Прем. эконом
Бизнес
Первый
Эконом
Прем. эконом
Бизнес
Первый
Эконом
Прем. эконом
Бизнес
Первый
Эконом
Прем. эконом
Бизнес
Первый
Нет изменения класса
Повышение
Повышение
Повышение
Понижение
Нет изменения класса
Повышение
Повышение
Понижение
Понижение
Нет изменения класса
Повышение
Понижение
Понижение
Понижение
Нет изменения класса
Эконом-Эконом
Эконом-Прем. эконом
Эконом-Бизнес
Эконом-Первый
Прем. эконом-Эконом
Прем. эконом-Прем. эконом
Прем. эконом-Бизнес
Прем. эконом-Первый
Business-Эконом
Business-Прем. эконом
Бизнес-Бизнес
Бизнес-Первый
Первый-Эконом
Первый-Прем. эконом
Первый-Бизнес
Первый-Первый
Рис. 12-6. Строки выборки измерения комбинированного подмножества
ПРИМЕЧАНИЕ В большинстве случаев ролевые измерения следует рассма-
тривать как отдельные логические измерения, созданные с помощью представлений в одной физической таблице. В отдельных ситуациях может иметь смысл
объединить отдельные измерения в одно, особенно когда объемы данных чрезвычайно малы или существует необходимость в дополнительных атрибутах, которые зависят от объединенных базовых ролей для контекста и значения.
Пункты отправки и назначения
Аналогичным образом рассмотрите плюсы и минусы объединения измерений «Аэропорт» для аэропорта отправления и аэропорта назначения. В этой
ситуации объемы данных более значительны, поэтому более практичными
400
Глава 12
кажутся отдельные ролевые измерения для каждого аэропорта. Однако бизнеспользователям могут потребоваться дополнительные атрибуты, которые зависят
от сочетания начального пункта и пункта назначения. В дополнение к доступу
к характеристикам каждого аэропорта бизнес-пользователи также хотят анализировать данные о полетной активности по расстоянию между аэропортами, а также по типу рейса, который зависит от города отправления и города назначения,
например внутренние или трансатлантические.
Даже кажущийся простым вопрос, касающийся общей активности между
Сан-Франциско (SFO) и Денвером (DEN) независимо от того, были ли рейсы
совершены в SFO или DEN, представляет некоторые проблемы с отдельными
измерениями происхождения и назначения. Эксперты по SQL, несомненно, могли бы ответить на этот вопрос программно с помощью отдельных измерений
аэропорта, но как насчет менее уполномоченных лиц? Даже если эксперты смогут дать правильный ответ, стандартной метки для ненаправленного маршрута
между городами не существует. Некоторые приложения для отчетности могут
обозначать его SFO — DEN, в то время как другие могут выбрать DEN — SFO,
Сан-Франциско — Денвер, Den — SF и так далее. Вместо встраивания несовместимых меток в код приложения для создания отчетов BI значения атрибутов
следует хранить в таблице измерений, чтобы можно было использовать общие
стандартизированные метки во всей организации. Было бы стыдно утруждать
себя созданием хранилища данных, а затем позволять прикладному коду реализовывать несогласованные метки отчетов. Бизнес-спонсоры системы DW/BI
не будут долго терпеть это.
Чтобы удовлетворить потребность в доступе к дополнительным атрибутам
маршрута пары городов (город отправления и город прибытия), у вас есть два
варианта. Один из них состоит в том, чтобы просто добавить еще одно измерение в таблицу фактов для описания маршрутов, включая название маршрута
по направлению, название ненаправленного маршрута, тип и расстояние, как показано на рис. 12-7. Альтернатива — объединение атрибутов аэропорта отправления и назначения, а также дополнительных атрибутов маршрута, связанных
с городом, в одно измерение. Теоретически в объединенном измерении будет
количество строк, равное декартову произведению всех аэропортов отправления
и назначения. К счастью, в реальной жизни количество строк намного меньше
этого теоретического предела, потому что авиакомпании не выполняют рейсы
между всеми аэропортами, где они присутствуют. Однако если у вас есть пара дюжин атрибутов, относящихся к аэропорту отправления, плюс пара дюжин идентичных атрибутов, относящихся к аэропорту назначения, наряду с атрибутами,
относящимися к маршруту, то у вас, вероятно, возникнет соблазн рассматривать
их как отдельные измерения.
Транспортировка
Название
Ключ
Название
маршрута маршрута
маршрута
Расстояние
с учетом
«Пара
без учета
городов» направления направления в милях
1
191
BOS-JFK
BOS-JFK
Группа маршрута
по расстоянию
Менее 200 миль
2
JFK-BOS
BOS-JFK
191
Менее 200 миль
3
4
5
6
BOS-LGW
LGW-BOS
BOS-NRT
NRT-BOS
BOS-LGW
BOS-LGW
BOS-NRT
BOS-NRT
3267
3267
6737
6737
Индикатор
внутренний
или
междунар.
401
Индикатор
перелета океана
Внутренний Нет перелета
над океаном
Внутренний Нет перелета
над океаном
От 3000 до 3500 миль Междунар. Трансатлантический
От 3000 до 3500 миль Междунар. Трансатлантический
Более 6000 миль
Междунар. Через Тихий океан
Более 6000 миль
Междунар. Через Тихий океан
Рис. 12-7. Примерные строки измерения маршрута для пар городов
Иногда разработчики предлагают использовать соединительную таблицу, содержащую ключи аэропорта отправления и назначения, для сбора информации
о маршруте. Хотя источник и пункт назначения представляют собой связь «многие ко многим», в этом случае вы можете четко представить связь в существующей таблице фактов, а не использовать соединительную таблицу.
Дополнительные соображения
о дате и времени
С самых первых глав этой книги мы обсуждали важность наличия подробного измерения «Дата», будь то с детализацией по отдельным дням, неделям или
месяцам, которое содержит описательные атрибуты даты и частные метки для
финансовых периодов и рабочих праздников. В этом заключительном разделе мы
представим несколько дополнительных соображений для работы с измерениями
«Дата» и «Время».
Календари для конкретных стран в качестве внешних
выносных измерений
Если система DW/BI обслуживает многонациональные потребности, необходимо обобщить стандартное измерение «Дата» для обработки многонациональных календарей в неограниченном количестве стран. Основное измерение
«Дата» содержит общие атрибуты календаря, относящиеся к дате независимо
от страны. Если ваш многонациональный бизнес охватывает григорианский, еврейский, исламский и китайский календари, вы должны включить четыре набора
дней, месяцев и лет в это основное измерение.
Измерение «Дата» для конкретной страны дополняют основную таблицу
дат. Ключ к дополнительному измерению — основной ключ даты вместе с кодом
страны. Таблица будет включать атрибуты даты для конкретной страны, такие
402
Глава 12
как названия праздников или сезонов, как показано на рис. 12-8. Этот подход
аналогичен работе с несколькими календарями финансовой отчетности, как описано в главе 7.
Таблица фактов
Ключ даты (FK)
Другие ключи …
Факты …
Измерение «Дата»
Ключ даты (PK)
Дата
День недели
Номер дня в формате Epoch
Номер недели в формате Epoch
Номер месяца в формате Epoch
Номер дня в календарном месяце
Номер дня в календарном году
Номер дня в финансовом месяце
Индикатор последнего дня
финансового месяца
Календарный месяц
Номер календарного месяца в году
Календарный год — месяц
(YYYY-MM)
Календарный квартал
Календарный год — квартал
Календарный год
Финансовый месяц
Номер финансового месяца в году
Финансовый год — месяц
Финансовый квартал
Финансовый год — квартал
Финансовый год
...
Внешнее измерение даты,
специфичной для страны
Ключ даты (FK)
Ключ страны (FK)
Название страны
Гражданское название
Индикатор гражданского
праздника
Название гражданского
праздника
Индикатор религиозного
праздника
Название религиозного
праздника
Индикатор дня недели
Время года
Рис. 12-8. Выборка календаря для конкретной страны
Вы можете присоединить эту таблицу к основному измерению «Календарь»
в качестве вспомогательного элемента или непосредственно к таблице фактов.
Если вы предоставляете интерфейс, требующий от пользователя указания названия страны, то атрибуты приложения для конкретной страны можно рассматривать как логически добавленные к основной таблице дат, позволяя им просматривать календарь глазами одной страны за раз. Календари для конкретной страны
могут быть сложны в создании сами по себе; все становится еще сложнее, если
вам нужно иметь дело с местными праздниками, которые происходят в разные
дни в разных частях страны.
Транспортировка
403
Дата и время в нескольких часовых поясах
При работе в нескольких странах или даже просто в нескольких часовых поясах
вы сталкиваетесь с трудностями, связанными с датами и временем транзакций.
Фиксируете ли вы дату и время относительно местной полуночи в каждом часовом поясе или выражаете период времени относительно стандарта, такого как
дата/время штаб-квартиры корпорации, среднее время по Гринвичу (GMT) или
Всемирное координированное время (UTC), также известное как время Зулу
в мире авиации? Чтобы полностью удовлетворить требования пользователей,
правильным ответом, вероятно, будет и то и другое. Стандартное время позволяет вам видеть одновременный характер транзакций по всему бизнесу, в то время как местное время позволяет вам понимать время транзакций относительно
времени суток.
Вопреки распространенному мнению, в мире существует более 24 часовых
поясов (соответствующих 24 часам суток). Например, в Китае установлен единый часовой пояс, несмотря на его широтный охват. В Индии также существует
единый часовой пояс, отличающийся от UTC на 5,5 часа. В Австралии три часовых пояса, центральный из которых смещен на полчаса. Между тем Непал и некоторые другие страны используют сдвиг в четверть часа. Ситуация становится
еще более неприятной, когда вы учитываете переход на летнее время и обратно.
Учитывая сложности, неразумно думать, что простое указание значения UTC
в таблице фактов может поддерживать равные даты и время. Также смещение
не может находиться в таблице измерений времени или аэропорта, поскольку
смещение зависит как от местоположения, так и от даты. Рекомендуемый подход для выражения дат и времени в нескольких часовых поясах состоит в том,
чтобы включать отдельные измерения даты и времени суток, соответствующие
местным и равным датам, как показано на рис. 12-9. Измерения «Время суток»,
как обсуждалось в главе 3 («Розничные продажи»), поддерживают группировки
периодов времени, такие как номера смен или обозначения временных блоков
в период пиковой нагрузки.
Таблица фактов перелетов
Измерение «Дата»
(2 роли)
Ключ даты отправления (FK)
Ключ времени отправления в GMT (FK)
Ключ времени дня отправления (FK)
Ключ времени дня отправления в GMT (FK)
Другие ключи …
Вырожденное измерение …
Факты …
Измерение «Время
суток» (2 роли)
Рис. 12-9. Местная и усредненная дата/время в разных часовых поясах
404
Глава 12
Краткое описание локализации
Мы обсудили проблемы международной системы DW/BI в нескольких главах
книги. В дополнение к международным часовым поясам и календарям, рассмотренным в предыдущих двух разделах, мы также говорили о мультивалютной отчетности в главе 6 и многоязычной поддержке в главе 8.
Все эти методы, ориентированные на базы данных, подпадают под общую тему
локализации. Локализация в более широком смысле также включает перевод текста пользовательского интерфейса, встроенного в инструменты BI. Поставщики
инструментов BI реализуют эту форму локализации с помощью текстовых баз
данных, содержащих все текстовые подсказки и метки, необходимые инструменту, которые затем могут быть настроены для каждой локальной среды. Конечно,
это может стать довольно сложным, поскольку текст, переведенный с английского на большинство европейских языков, приводит к текстовым строкам, которые
длиннее их английских эквивалентов, что может привести к изменению дизайна
приложения BI. Кроме того, арабский текст читается справа налево, а многие
азиатские языки совершенно разные.
Серьезная международная система DW/BI, созданная для обслуживания
бизнес-пользователей во многих странах, должна быть тщательно разработана
с учетом определенного набора этих проблем локализации. Но, возможно, стоит подумать о том, как диспетчерские вышки аэропортов и пилоты самолетов
по всему миру справляются с языковой несовместимостью при передаче важных
сообщений о направлениях и высотах полета. Все они используют один язык (английский) и единицу измерения (футы).
Выводы
В этой главе мы обратили наше внимание на авиаперелеты или маршруты; мы
кратко коснулись аналогичных сценариев, взятых из отраслей судоходства и туристических услуг. Мы рассмотрели ситуацию, в которой у нас есть несколько
таблиц фактов с различной степенью зернистости и множеством фактов, специфичных для конкретных задач. Мы также обсудили возможность объединения
измерений в единую таблицу измерений для случаев, когда число строк чрезвычайно мало или когда имеются дополнительные атрибуты, зависящие от объединенных измерений. Опять же, объединение коррелированных измерений следует
рассматривать скорее как исключение, чем как правило.
Мы завершили эту главу обсуждением нескольких методов создания измерений «Дата» и «Время», включая привязку календаря к конкретной стране
и обработку абсолютных и относительных дат и времени.
13
Образование
В
этой главе мы вступаем в мир образовательного учреждения. Рассмотрим
для начала список абитуриентов как накопительный моментальный снимок. Когда в главе 4 были представлены таблицы фактов с накопительными
моментальными снимками, концепция была проиллюстрирована конвейером
движения товаров; рабочие процессы выполнения заказов были отражены в накопительном моментальном снимке в главе 6. В этой главе вместо наблюдения
за перемещением товаров или заказов по различным штатам используется накопительный снимок для отслеживания потенциальных абитуриентов по мере
прохождения ими этапов приема.
Другая основная концепция, обсуждаемая в этой главе, — таблица фактов без
фактов. Мы рассмотрим несколько примеров из практики, взятых из высшего
образования, чтобы подробнее изучить эти специальные таблицы фактов и обсудить анализ событий, которые не произошли.
В главе 13 рассматриваются следующие концепции:
■ пример фрагмента матрицы шины для университета или колледжа;
■ отслеживание заявок на получение грантов и предложений по исследовательским грантам в виде таблиц моментальных снимков;
■ таблица фактов без фактов для вступительных мероприятий, управления
средствами регистрации на курсы и посещаемости студентов;
■ обработка несуществующих событий.
Тематическое исследование
университета и матрица шин
В этой главе вы работаете в университете, колледже или другом учебном заведении. Кто-то из работников высшего образования однажды заметил, что управление университетом сродни управлению всеми предприятиями, необходимыми для поддержки небольшой деревни. Университеты — это одновременно
406
Глава 13
компания по управлению недвижимостью (студенческое жилье), рестораном
с несколькими торговыми точками (столовые), розничной торговлей (книжный
магазин), агентством по организации мероприятий и продаже билетов (мероприятия по легкой атлетике и выступлениям), департаментом полиции (безопасность кампуса), профессиональный сборщик средств (развитие выпускников),
компания по оказанию финансовых услуг потребителям (финансовая помощь),
инвестиционная фирма (управление пожертвованиями), венчурный капитал (исследования и разработки), фирма по трудоустройству (планирование карьеры),
строительная компания (обслуживание зданий и сооружений), поставщик медицинских услуг (медицинская клиника). В дополнение к этим разнообразным
функциям высшие учебные заведения, очевидно, также сосредоточены на привлечении высококвалифицированных студентов и талантливых преподавателей
для создания надежной образовательной среды.
Фрагмент матрицы шины на рис. 13-1 охватывает несколько основных процессов в образовательном учреждении. Традиционно в сфере высшего образования меньше внимания уделялось доходам и прибыли, но в условиях постоянно
растущих затрат и конкуренции университеты и колледжи не могут игнорировать эти финансовые показатели. Они хотят привлекать и удерживать студентов,
которые соответствуют их академическим и другим институциональным целям.
Существует большой интерес к анализу того, что студенты «покупают», с точки
зрения курсов в каждом семестре и связанных с ними академических результатов.
Колледжи и университеты хотят понять многие аспекты опыта студента, а также
поддерживать постоянные отношения после окончания учебы.
Таблицы фактов накопительных
моментальных снимков
В главе 4 использовалась накопительная таблица фактов моментальных снимков
для отслеживания продуктов, идентифицированных по серийным номерам или
номерам партий, по мере их прохождения через различные этапы инвентаризации на складе. Найдите минутку, чтобы вспомнить отличительные характеристики накопительной таблицы фактов моментальных снимков:
1. Одна строка представляет полную историю рабочего процесса или экземпляра конвейера.
2. Несколько дат представляют стандартные контрольные события конвейера.
3. Накопительные факты моментального снимка часто включали показатели,
соответствующие каждой вехе, плюс количество статусов и прошедших периодов.
Счет
Обор
удова
ние
Подр
аздел
ение
Заяви
тель
— Ст
уден
т—
Выпу
скни
к
Работ
ник (п
репо
кафе
дават
дры,
ель
обслу
жива
ние)
Курс
Дата/
Семе
стр
Образование
Процесс жизненного цикла студентов
Вступительные мероприятия
X
X
X
Процесс подачи заявления
X
X
X
X
Финансовая помощь на обучение
X
X
X
X
Регистрация студента / Снимок профиля
X
X
X
X
X
Студенческое жилье
X
X
X
X
Регистрация студента на курсы и итоги
X
X
X
X
X
X
Оценка преподавателем студента на курсе
X
X
X
X
X
X
Студенческие активности
X
X
Поиск работы
X
X
Контакты для продвижения по службе
X
X
X
Обещания и подарки для продвижения
по службе
X
X
X
X
X
X
Финансовые процессы
Бюджет
X
X
X
Отслеживание пожертвований
X
X
X
Бухгалтерские транзакции
X
X
X
Платежная ведомость
X
X
X
X
Закупки
X
X
X
X
Моментальный снимок численности
работников
X
X
X
Наем и увольнение сотрудников
X
X
X
Выплаты сотрудникам
X
X
X
Управление эффективностью персонала
X
X
X
Управление назначением преподавателей
X
X
X
Исследования
X
X
X
Расходы на исследования
X
X
X
Публикации преподавателей
X
X
X
Использование оборудования
X
X
X
X
Потребление энергии и утилизация
отходов
X
X
X
Заказы на выполнение работ
X
X
X
X
Процесс управления персоналом
X
X
Административные процессы
X
X
Рис. 13-1. Подмножество строк матрицы шины для образовательного
учреждения
X
407
408
Глава 13
4. Каждая строка пересматривается и обновляется всякий раз, когда изменяется экземпляр конвейера; как внешние ключи, так и измеренные факты
могут быть изменены во время обновления строк фактов.
Конвейер кандидатов
Теперь представьте себе те же самые характеристики моментального снимка, которые накапливаются применительно к системе приема будущих студентов. Для
тех, кто работает в других отраслях, существует очевидное сходство с отслеживанием кандидатов на работу в процессе найма или перспектив продаж по мере
того, как они проходят квалификацию и становятся клиентами.
В случае отслеживания абитуриентов будущие студенты проходят стандартный набор вступительных испытаний или этапов. Возможно, вас заинтересует
отслеживание действий по ключевым датам, таким как первоначальный запрос,
посещение кампуса, подача заявления, заполнение заявления, уведомление о решении о приеме, зачисление или отзыв. В любой момент аналитики по управлению приемом и зачислением интересуются тем, сколько абитуриентов находится на каждом этапе подготовки. Этот процесс во многом похож на воронку,
где многие запросы поступают в конвейер, но гораздо меньше продвигаются
к финальной стадии. Приемный персонал также хотел бы проанализировать пул
кандидатов по целому ряду характеристик.
Информация о выборке кандидатов на этом снимке вмещается в одну строку
на каждого потенциального студента; такая детализация представляет собой самый низкий уровень детализации, зафиксированный, когда потенциальный кандидат входит в конвейер. По мере сбора дополнительной информации, по мере
того, как будущий студент продвигается к подаче заявления, принятию и зачислению, вы продолжаете просматривать и обновлять строку таблицы фактов, как
показано на рис. 13-2.
Как и в предыдущих примерах, в таблице фактов есть несколько дат, соответствующих стандартным событиям вехи. Вы хотите проанализировать прогресс
потенциального клиента к этим датам, чтобы определить темпы продвижения
по конвейеру и выявить узкие места. Это особенно важно, если вы видите значительное отставание в отношении кандидата, в котором вы заинтересованы для
рекрутинга. Каждая из этих дат рассматривается как ролевое измерение с суррогатным ключом по умолчанию для обработки неизвестных дат для новых строк
и строк в процессе.
Атрибуты абитуриента содержат много интересных характеристик будущих
студентов. Аналитики заинтересованы в выборках и срезах по характеристикам
кандидатов, таким как география, входящие учетные данные (средний балл, результаты вступительных испытаний в колледж, дополнительные баллы и средняя
Образование
409
школа), пол, дата рождения, этническая принадлежность, предварительная специальность, источник заявки и множество других. Анализ этих характеристик
на различных этапах процесса может помочь персоналу приемной комиссии
скорректировать свои стратегии, чтобы побудить больше (или меньше) студентов перейти к следующей вехе. Факты в таблице фактов о кандидатах включают
множество показателей, которые тщательно отслеживаются персоналом приемной комиссии. Если таковая имеется, эта таблица может включать оценочные вероятности того, что потенциальный кандидат подаст заявление и впоследствии
поступит, если его примут, для прогнозирования результатов приема.
Измерение «Дата» (6 ролей)
Ключ даты (PK)
…
Семестр
Академический год/семестр
Академический год
Измерение «Статус
заявления на прием»
Ключ статуса заявления
Код статуса заявления
Описание статуса заявления
Категория статуса заявления
Таблица фактов подачи заявления
Ключ даты первоначального обращения (FK)
Ключ даты посещения кампуса (FK)
Ключ даты подачи заявления (FK)
Ключ даты полного заполнения заявления (FK)
Ключ даты уведомления о решении
по заявлению (FK)
Ключ даты регистрации отзыва заявления (FK)
Ключ заявителя (FK)
Ключ статуса заявления (FK)
ID заявления (DD)
Количество запросов
Количество визитов в кампус
Количество поданных заявлений
Количество завершенных заявлений
Количество досрочно принятых решений
Количество обычным образом принятых
решений
Количество ожидающих
Количество отложенных рассмотрений
до стандартного периода
Количество отказов
Количество зачислений досрочно
Обычное количество досрочных зачислений
Количество отклоненных заявлений
Измерение «Заявитель»
Ключ заявителя (PK)
Имя заявителя
Атрибуты адреса заявителя …
Старшая школа
Оценка GPA старшей школы
Тип старшей школы
Оценка SAT по математике
Оценка SAT по устным
экзаменам
Оценка SAT по сочинению
Сводная оценка ACT
Количество баллов AP
Пол
Дата рождения
Национальность
Индикатор полной/
неполной занятости
Источник заявления
Предполагаемое
направление
...
Рис. 13-2. Выборка кандидатов-студентов
Альтернативные схемы конвейера кандидатов
Накопительные моментальные снимки подходят для недолговечных процессов,
которые имеют определенное начало и конец со стандартными промежуточными этапами. Этот тип таблицы фактов позволяет вам видеть обновленный статус
и в итоге окончательное расположение каждого кандидата. Однако, поскольку
строки накопительных моментальных снимков обновляются, они не сохраняют
количество и статусы кандидатов в критические моменты в календаре приема, такие как дата раннего уведомления о принятии решения. Учитывая тщательное изучение этих цифр, аналитики, возможно, также захотят сохранить моментальные
410
Глава 13
снимки на несколько важных контрольных дат. В качестве альтернативы вы можете создать таблицу фактов транзакции приема с одной строкой на транзакцию
для каждого кандидата для подсчета и сравнения между периодами.
Конвейер предложений по исследовательским грантам
Конвейер исследовательских предложений — еще один пример накопительного
моментального снимка, основанный на образовании. Преподаватели и администрация заинтересованы в просмотре жизненного цикла предложения о предоставлении гранта по мере его продвижения по конвейеру от предварительного
предложения до утверждения гранта и получения награды. Это будет способствовать анализу количества невыполненных предложений на каждом этапе разработки по факультетам, кафедрам, тематическим областям исследований или
источникам финансирования исследований. Точно так же вы могли видеть показатели успеха по различным атрибутам. Наличие этой информации в общем
хранилище позволило бы использовать ее более широкому кругу населения университетского кампуса.
Таблицы фактов без фактов
До сих пор мы в основном разрабатывали таблицы фактов с очень похожими
структурами. Каждая таблица фактов обычно содержит от 5 до 20 столбцов внешнего ключа, за которыми следуют от одного до потенциально нескольких десятков числовых, непрерывно оцениваемых, предпочтительно аддитивных фактов.
Факты можно рассматривать как измерения, сделанные на пересечении значений
ключей измерений. С этой точки зрения факты — это обоснование для таблицы
фактов, а значения ключей — просто административная структура для идентификации фактов.
Однако существует ряд бизнес-процессов, таблицы фактов которых аналогичны тем, которые мы разрабатывали, с одним существенным отличием — нет
никаких атрибутов этих фактов! Мы представили таблицы фактов без фактов при
обсуждении рекламных мероприятий в главе 3, а также в главе 6 для описания назначений торговых представителей либо клиентов. В сфере высшего образования
существует множество примеров «безрезультатных» событий.
События приема
Вы можете представить себе таблицу фактов без фактов для отслеживания посещаемости каждого потенциального студента на мероприятиях по приему, например посещение средней школы, ярмарка колледжей, собеседование с выпускниками или ночевка в кампусе, как показано на рис. 13-3.
Образование
411
Таблица фактов посещения
события для подачи заявления
Измерение «Дата приема»
Измерение «Заявитель»
Измерение «Сотрудник,
принявший заявление»
Ключ даты события приема (FK)
Ключ плана приема на семестр (FK)
Ключ заявителя (FK)
Ключ статуса заявителя (FK)
Ключ сотрудника, осуществившего (FK)
Ключ события приема (FK)
Счетчик событий приема (=1)
Измерение
«План приема на семестр»
Измерение
«Статуса заявления на прием»
Измерение «Событие приема»
Рис. 13-3. Посещение вступительного мероприятия в виде таблицы фактов
без фактов
Регистрация на курсы
Аналогичным образом вы можете отслеживать регистрацию студентов на курсы
по семестрам, используя таблицу фактов без фактов. Основа ее будет состоять
из одной строки для каждого зарегистрированного курса по студенту и по семестру, как показано на рис. 13-4.
Характеристика семестра
В этой таблице фактов данные представлены на уровне семестров, а не на уровне
более типичной детализации календарного дня, недели или месяца. Измерение
«Семестр» по-прежнему должно соответствовать измерению «Календарная
дата». Другими словами, каждая дата в измерении «Календарная дата» должна
указывать семестр, например осенний, семестр и учебный год, например осень
2013 года, и учебный год, например 2013–2014. Метки и значения столбцов должны быть идентичными для атрибутов, общих как для измерений «Календарная
дата», так и для измерений «Семестр».
Измерение «Студент» и отслеживание изменений
Измерение «Студент» — это расширенная версия измерения «Кандидат»,
рассмотренного в первом сценарии. Вы все еще сохраняете некоторую информацию, полученную в процессе подачи заявки (например, географию, учетные
данные и предполагаемую специальность), но дополняете ее информацией
о жизни в кампусе, такой как статус неполного или полного рабочего дня, место
жительства, показатель участия в спортивных соревнованиях, заявленная специальность и статус (например, второкурсник).
Как обсуждалось в главе 5, вы могли бы представить себе размещение некоторых из этих атрибутов в мини-измерении типа 4, потому что аналитики по всему университету заинтересованы в отслеживании изменений в них, особенно
в отношении заявленной специальности, уровня класса и результатов обучения.
412
Глава 13
Люди в администрации и академических кругах остро заинтересованы в академической успеваемости и показателях удержания в разбивке по классам, школам, факультетам и специальностям. В качестве альтернативы, если существует
настоятельная необходимость сохранить профили учащихся во время регистрации на курс, а также фильтрацию и группировки по текущим характеристикам
учащихся, вам следует рассмотреть возможность обработки информации об учащемся в виде медленно меняющегося измерения типа 7 с двумя ключами измерения учащихся в таблице фактов, как также описано в главе 5. Суррогатный ключ
учащегося будет связан с таблицей измерений с атрибутами типа 2; устойчивый
идентификатор учащегося будет связан с представлением измерения «Студент»,
содержащего только текущую строку для каждого учащегося.
Измерение «Семестр»
Ключ семестра (PK)
Семестр
Академический год — семестр
Академический год
Измерение «Семестр»
Ключ курса (PK)
Название курса
Кафедра курса
Формат курса
Часы, отведенные на курс
Таблица фактов
регистрации на курс
Ключ семестра (FK)
Ключ студента (FK)
Ключ курса (FK)
Ключ преподавателя (FK)
Количество
зарегистрировавшихся
на курс (=1)
Измерение «Студент»
Ключ студента (PK)
ID Студента (NK)
...
Измерение «Преподаватель»
Ключ преподавателя (PK)
ID преподавателя как
сотрудника (NK)
Имя преподавателя
Атрибут адреса
преподавателя…
Тип преподавателя
Показатель срока пребывания
преподавателя в должности
Дата принятия преподавателя
на работу
Время работы преподавателя
Рис. 13-4. События регистрации курса в виде таблицы фактов без фактов
Метрика искусственного подсчета
Таблица фактов представляет собой надежный набор взаимосвязей «многие
ко многим» между измерениями; в ней записывается столкновение измерений
в определенный момент времени и пространства. Эта таблица фактов регистрации курса может быть запрошена, чтобы ответить на ряд интересных вопросов,
касающихся регистрации на академические мероприятия колледжа, например
«Какие студенты записались на какие курсы? Сколько студентов инженерных
специальностей проходят внеклассные финансовые курсы? Сколько студентов
записалось на курсы данного преподавателя за последние три года? Сколько
Образование
413
студентов записалось более чем на один курс от данного преподавателя?» Единственная особенность в этих примерах заключается в том, что у вас нет числового
факта, привязанного к этим регистрационным данным. Таким образом, анализ
этих данных будет основываться в основном на подсчетах.
ПРИМЕЧАНИЕ События моделируются в виде таблиц фактов, содержащих
ряд ключей, каждый из которых представляет участвующее в событии измерение. Таблицы событий иногда не имеют связанных с ними показателей и, следовательно, называются таблицами фактов без фактов.
SQL для выполнения подсчетов в этом факте асимметричен из-за отсутствия каких-либо фактов. При подсчете количества регистраций для преподавателя любой
ключ может быть использован в качестве аргумента функции COUNT. Например:
select faculty, count(term_key)… group by faculty
Это дает простой подсчет количества регистраций студентов по факультетам с учетом любых ограничений, которые могут существовать в предложении
WHERE. Странность SQL заключается в том, что вы можете посчитать любой
ключ и все равно получить один и тот же ответ, потому что вы подсчитываете
количество ключей, которые передаются запросом, а не их отдельные значения.
Вам нужно будет использовать COUNT DISTINCT, если вы хотите подсчитать
уникальные экземпляры ключа, а не количество встреченных ключей.
Неизбежная путаница, связанная с оператором SQL, хотя и не является серьезной семантической проблемой, заставляет некоторых разработчиков создавать
искусственный подразумеваемый факт, возможно, называемый подсчетом регистрации курса (в отличие от «фиктивного»), который всегда заполняется значением 1. Хотя этот факт не добавляет никакой информации в таблицу фактов, он
делает SQL более читабельным, например:
select faculty, sum(registration_count)… group by faculty
На этом этапе таблица больше не является строго «без фактов», но «1» —
не более чем артефакт. SQL будет немного чище и выразительнее с количеством
регистраций. Некоторым инструментам BI-запросов проще создать этот запрос
с помощью нескольких простых пользовательских жестов. Что еще более важно,
если вы создадите сводную таблицу над этой таблицей фактов, вам понадобится реальный столбец, чтобы получить значимые сводные показатели регистрации. И наконец, при развертывании в кубе OLAP вы обычно включаете явный
414
Глава 13
столбец подсчета (всегда равный 1) для сложных подсчетов, поскольку ключи
соединения измерений явно не отображаются в кубе.
Если измеримый факт действительно всплывает во время проектирования,
его можно добавить в схему, предполагая, что он соответствует зернистости регистрации студентов на курсы по семестрам. Например, вы можете добавить доход от обучения, заработанные зачетные часы и оценки в эту таблицу, но тогда
это больше не таблица фактов без фактов.
Несколько преподавателей курса
Если курсы преподает один преподаватель, вы можете связать его ключ с событиями
регистрации курса, как показано на рис. 13-4. Однако если некоторые курсы преподаются совместно, то это атрибут измерения, который принимает несколько значений для объявленной зернистости таблицы фактов. У вас есть несколько вариантов:
1. Измените структуру таблицы фактов так, чтобы она составляла одну строку для каждого преподавателя за регистрацию на курс для каждого студента за семестр. Хотя такой подход решает проблему нескольких преподавателей, связанных с курсом, эта неестественная зернистость может быть
подвержена ошибкам с завышенным количеством регистраций.
2. Добавьте соединительную таблицу с ключом группы преподавателей либо
в таблицу фактов, либо в качестве вспомогательного измерения в измерении
курса, как описано в главе 8. В этой таблице будет одна строка для каждого
преподавателя, который преподает курсы самостоятельно. Кроме того, для
каждой группы преподавателей будет две строки; эти строки будут связывать
один и тот же групповой ключ с отдельными ключами инструктора. Объединение ключа группы и ключа преподавателя будет однозначно идентифицировать каждую строку соединительной таблицы. Как описано в главе 10,
вы можете назначить весовой коэффициент каждой строке в соединительной
таблице, если распределение учебной нагрузки четко определено. Этот подход был бы подвержен потенциальным проблемам с завышением, связанным
с использованием соединительной таблицы, описанным в главе 10.
3. Объедините имена преподавателей в единый атрибут с разделителями в измерении «Курс», как описано в главе 9. Этот вариант позволяет пользователям легко помечать отчеты одним атрибутом измерения, но он не поддерживает анализ событий регистрации по характеристикам преподавателя.
4. Если один из преподавателей идентифицирован как основной, то его ключ
может обрабатываться как единственный внешний ключ в таблице фактов,
присоединенный к измерению, где атрибуты были названы соответственно, прибавляя «..основной..» к именам столбцов для дифференциации.
Образование
415
Регистрация на курс: примеры
Структура таблицы фактов, показанной на рис. 13-4, представляет собой одну
строку для каждого зарегистрированного студента по курсу и семестру. Некоторых пользователей в колледже или университете могут заинтересовать периодические снимки событий регистрации на курс в ключевые даты академического
календаря, такие как предварительная регистрация, начало семестра, крайний
срок отмены либо добавления курса и конец семестра. В этом случае зернистость
таблицы фактов будет составлять одну строку для зарегистрированных курсов
каждого студента за семестр на дату моментального снимка.
Использование объекта
Второй тип таблицы фактов без фактов касается охвата, который можно проиллюстрировать сценарием управления объектами. Университеты вкладывают
огромные средства в свои физические установки и оборудование. Было бы полезно понять, какие помещения для каких целей использовались в течение каждого
часа дня в течение каждого семестра. Например, какие объекты заняты наиболее интенсивно? Какова была средняя заполняемость помещений в зависимости
от времени суток? Значительно ли снижается загрузка по пятницам, когда никто
не хочет посещать занятия или преподавать?
Измерение «Семестр»
Измерение «День недели»
Измерение «Помещение»
Ключ помещения (PK)
Здание, где находится
помещение — Комната
Здание, где находится
помещение
Атрибут адреса здания…
Тип помещения
Этаж помещения
Площадь объекта
Вместимость аудитории
Индикатор наличия проектора
Индикатор наличия вентиляции
…
Таблица фактов
использования помещений
Ключ семестра (FK)
Ключ дня недели (FK)
Ключ времени дня — час (FK)
Ключ оборудования (FK)
Ключ подразделениявладельца (FK)
Ключ подразделения,
которому выдано (FK)
Ключ статуса
использования (FK)
Количество помещений (=1)
Измерение «Время суток — час»
Ключ времени дня — час (PK)
Время дня — час
Индикатор части дня
Измерение «Подразделение» (2 роли)
Измерение
«Статус использования помещения»
Рис. 13-5. Использование объектов в качестве таблицы фактов без учета самих
фактов
416
Глава 13
И снова на помощь приходит таблица фактов без фактов. В этом случае вы
должны вставить одну строку в таблицу фактов для каждого объекта для стандартных часовых временных блоков в течение каждого дня недели в течение
семестра независимо от того, используется ли объект. Рис. 13-5 иллюстрирует
схему.
Измерение «Помещение» будет включать все типы описательных атрибутов
объекта, таких как здание, тип объекта (например, класс, лаборатория или офис),
площадь, вместимость и удобства (например, доска или встроенный проектор).
Измерение «Статус использования» будет включать текстовый дескриптор
со значениями «Доступно» или «Использовано». Между тем в использовании
объектов может быть задействовано несколько организаций. Например, одна
организация может быть собственником объекта в течение временного блока,
но эта же или другая организация может быть назначена пользователем объекта.
Посещаемость студентов
Вы можете визуализировать аналогичную схему для отслеживания посещаемости студентами курса. В этом случае зернистость — это одна строка для каждого
студента, который каждый день проходит через дверь класса. Эта таблица фактов
без фактов будет содержать ряд тех же измерений, которые обсуждались при регистрации событий. Основное различие будет заключаться в детализации по календарной дате в этой схеме, а не просто по сроку. Эта размерная модель, проиллюстрированная на рис. 13-6, позволяет бизнес-пользователям отвечать на вопросы,
касающиеся того, какие курсы посещались чаще всего. На каких курсах в течение
семестра наблюдалось наименьшее сокращение посещаемости? Какие студенты посещали какие курсы? Какой преподаватель обучал больше всего студентов?
Таблица фактов
посещения студента
Измерение «Дата»
Измерение «Курс»
Измерение «Помещение»
Ключ даты (FK)
Ключ студента (FK)
Ключ курса (FK)
Ключ преподавателя (FK)
Ключ помещения (FK)
Счетчик посещения занятий
Измерение «Студент»
Измерение «Преподаватель»
Рис. 13-6. Таблица фактов посещаемости учащихся
Явные строки для того, что не произошло
Возможно, людям интересно следить за студентами, которые записались на курс,
но не пришли. В этом примере вы можете представить добавление явных строк
в таблицу фактов для событий посещаемости, которые не произошли. Таблица
Образование
417
фактов больше не будет лишена фактов, поскольку показатель посещаемости равен либо 1, либо 0.
Добавление строк в этом сценарии целесообразно, поскольку события, не связанные с посещением, имеют ту же размерность, что и события посещаемости.
Аналогичным образом таблица фактов не будет расти с угрожающей скоростью,
поскольку предполагается, что неявки составляют небольшой процент от общего
числа студентов, записавшихся на курс. Хотя этот подход разумен в данном сценарии, создание строк для событий, которые не произошли, нелепо во многих
других ситуациях, таких как добавление строк в транзакцию продажи клиента
для продвигаемых продуктов, которые не были приобретены клиентом.
«Не произошедшие события» в размерных OLAP
Размерные базы данных OLAP отлично справляются с задачей помочь пользователям понять, что у них не произошло. При построении куба размерные базы
данных обрабатывают разреженность данных транзакций, сводя к минимуму
накладные расходы, связанные с хранением явных пустых значений. Таким образом, по крайней мере в случае кубов фактов, которые не слишком разрежены,
данные о событиях доступны для анализа пользователями. При этом влияние
определенных сложностей, которые только что обсуждались в мире реляционных схем типа «звезда», будет снижено.
Увеличение образовательных
аналитических возможностей
Многие бизнес-процессы, описанные в предыдущих главах, такие как закупки
и управление персоналом, очевидно, применимы к университетской среде, учитывая желание лучше контролировать расходы и управлять ими.
Исследовательские гранты и взносы выпускников — ключевые источники дохода в дополнение к доходу от обучения. Анализ грантов на исследования — это
часто разновидность финансового анализа, как обсуждалось в главе 7, но на более низком уровне детализации. Зернистость будет включать дополнительные
измерения для дальнейшего описания исследовательского гранта, такие как
корпоративный или государственный источник финансирования, тема исследования, продолжительность гранта и исследователь факультета. Существует настоятельная необходимость лучше понимать бюджетные и фактические расходы,
связанные с каждым исследовательским проектом, и управлять ими. Цель: оптимизировать расходы таким образом, чтобы избежать ситуации профицита или
дефицита, а средства направлять туда, где они будут наиболее продуктивными.
Аналогичным образом понимание расходов на исследования, распределенных
418
Глава 13
по различным направлениям, необходимо для обеспечения надлежащего институционального контроля за такими денежными средствами.
Лучшее понимание выпускников университета во многом похоже на лучшее
понимание клиентской базы, как описано в главе 8. Очевидно, что существует
множество интересных характеристик, которые могли бы помочь в поддержании отношений с вашими выпускниками, таких как географические, демографические данные, информация о занятости, интересах и поведении, в дополнение
к данным, которые вы собрали о них как о студентах (например, документы, жилье, школа, специальность, продолжительность обучения и награды). Улучшенный доступ к широкому спектру сведений о контингенте выпускников позволит
учебному заведению лучше ориентироваться в сообщениях и распределять ресурсы. В дополнение к научному вкладу выпускников, отношения с ними могут
быть использованы для потенциального найма, трудоустройства и возможностей
для исследований. С этой целью надежная операционная система CRM должна
отслеживать все точки соприкосновения с выпускниками, чтобы собирать значимые данные для аналитической платформы DW/BI.
Выводы
В этой главе мы сосредоточились на двух основных концепциях. Во-первых, мы
рассмотрели таблицу фактов накопительных моментальных снимков, чтобы отслеживать конвейеры заявок или исследовательских грантов. Хотя накопительный снимок используется гораздо реже, чем более распространенные таблицы
фактов транзакций и периодических снимков, он очень полезен для отслеживания текущего состояния кратковременного процесса со стандартными контрольными точками. Как мы описали, накопительные моментальные снимки часто дополняются таблицами транзакций или периодическими моментальными
снимками.
Во-вторых, мы рассмотрели несколько примеров таблиц фактов без фактов.
Эти таблицы фактов отражают взаимосвязь между измерениями в случае события или охвата, но уникальны тем, что никакие показатели не собираются в качестве реальных фактов. Мы также обсудили обработку ситуаций, когда вы хотите
отслеживать события, которые не произошли.
14
Здравоохранение
И
ндустрия здравоохранения претерпевает огромные изменения, поскольку
она стремится улучшить результаты лечения пациентов и одновременно
с этим повысить эффективность работы. По мере того как организации пытаются интегрировать свою клиническую и административную информацию, возникает множество проблем. Данные о здравоохранении представляют несколько интересных моделей размерного проектирования, которые мы рассмотрим
в этой главе.
В главе 14 рассматриваются следующие концепции:
■ пример фрагмента матрицы шины для организации здравоохранения;
■ таблицы фактов накопительных моментальных снимков для обработки
требований выставления счетов и конвейера платежей;
■ ролевые измерения для нескольких записей и врачей;
■ многозначные измерения, такие как диагнозы пациентов;
■ обработка супертипов и подтипов медицинских сборов;
■ обработка текстовых комментариев;
■ показатели в измерениях для разреженных, разнородных измерений;
■ обработка изображений с размерными схемами;
■ транзакции и периодические снимки использования оборудования.
Тематическое исследование
здравоохранения и матрица шин
В условиях беспрецедентной ориентации на потребителя и государственной политики регулирования в сочетании с внутренним давлением организациям здравоохранения необходимо более эффективно использовать информацию, чтобы
повлиять как на результаты лечения пациентов, так и на эффективность работы.
Организации здравоохранения обычно борются со многими разрозненными системами для сбора своих клинических, финансовых и операционных показателей
420
Глава 14
Сотру
дник
Поме
щени
е
Диагн
оз
X
X
X
X
X
X
X
X
X
X
X
Назначения врача
X
X
X
X
X
Препараты
X
X
X
Результаты анализов
X
X
X
X
X
X
Участие в лечении заболевания
X
X
X
X
X
X
Сообщения пациента о результатах
X
X
X
X
X
X
Опрос удовлетворенности пациентов
X
X
X
X
X
X
Плате
льщи
к
Врач
X
Процедуры
Проц
едура
Паци
е
Процесс поступления пациента
нт
Дата
эффективности. Эта информация должна быть лучше интегрирована для обеспечения более эффективного ухода за пациентами при одновременном управлении
затратами и рисками.
Клинические события
X
X
X
События выставления счетов/получения доходов
Плата за нахождение в стационаре
X
X
X
X
X
X
Амбулаторные сборы
X
X
X
X
X
X
Выставление счетов по претензиям
X
X
X
X
X
X
X
Платы по счетам по претензиям
X
X
X
X
X
X
X
Поступления и списания
X
X
X
X
X
X
X
X
Утилизация использованных коек
X
X
X
X
X
Утилизация вышедшего из строя
оборудования
X
X
X
X
X
Закупка расходников
X
X
X
Утилизация расходников
X
X
X
X
X
X
X
Составление расписания работы
персонала
X
X
X
Операционные события
Рис. 14-1. Подмножество строки матрицы шины для консорциума
здравоохранения
Аналитики здравоохранения хотят лучше понять, какие процедуры обеспечивают наилучшие результаты, одновременно определяя возможности для влияния
на использование ресурсов, включая рабочую силу, помещения и сопутствующее оборудование и расходные материалы. Крупные медицинские консорциумы с сетями врачей, клиник, больниц, аптек и лабораторий ориентированы
на эти требования, тем более что как федеральное правительство, так и частные
Здравоохранение
421
плательщики поощряют поставщиков брать на себя большую ответственность
за качество и стоимость своих медицинских услуг. Рис. 14-1 иллюстрирует примерный фрагмент матрицы шины организации здравоохранения.
Традиционно участники медицинского страхования использовали информацию о претензиях, чтобы лучше понять свои риски, улучшить политику выдачи
полисов и выявить потенциальную мошенническую деятельность. Плательщики
страховых взносов исторически были более опытными, чем организации, предоставляющие медицинские услуги, в аналитическом использовании данных,
возможно, отчасти потому, что их основной источник данных (претензии) был
более надежно собран и структурирован, чем данные поставщиков медицинских
услуг. Однако данные о претензиях — как преимущество, так и проклятие для
аналитических результатов, поскольку исторически они не давали четкой и детализированной клинической картины. Все чаще получатели медицинских услуг
сотрудничают с поставщиками таких услуг, чтобы использовать подробную информацию о пациентах для поддержки более прогностического анализа. Во многих отношениях потребности и цели поставщиков и плательщиков совпадают,
особенно в связи с продвижением моделей предоставления услуг с разделением
рисков.
Каждый эпизод оказания медицинской помощи пациенту в организации
здравоохранения генерирует огромное количество информации. Транзакционные данные, ориентированные на пациента, делятся на две основные категории:
административные и клинические. Данные о выставлении счетов по претензиям
содержат подробную информацию о счете пациента из кабинета врача, клиники,
больницы или лаборатории. Клиническая медицинская карта более всеобъемлюща, она включает в себя не только услуги, за которые взимается плата, но также
результаты лабораторных анализов, рецепты, заметки врача или распоряжения,
а иногда и результаты. Проблемы согласованных общих измерений в здравоохранении остаются точно такими же, как и в других отраслях промышленности. Очевидно, что наиболее важным согласованным измерением является сам
пациент. В главе 8 мы описали необходимость 360-градусного обзора клиентов.
Легко утверждать, что 360-градусный обзор пациентов еще более важен, учитывая ставки; внедрение систем электронной медицинской карты пациента (EMR)
и электронной медицинской карты (EHR) явно направлено на достижение этой
цели.
Другие измерения, которые должны быть согласованы, включают следующее:
■ дата;
■ ответственная сторона;
■ работодатель;
■ план медицинского обслуживания;
422
Глава 14
■ плательщик (первичный и вторичный);
■ врач;
■ процедура;
■ оборудование;
■ лабораторный тест;
■ медикаментозное лечение;
■ диагностика;
■ учреждение (офис, клиника, амбулаторное учреждение и больница).
В сфере здравоохранения некоторые из этих измерений трудно согласовать,
в то время как другие проще, чем кажется на первый взгляд. Измерение «Пациент» исторически было сложным, по крайней мере в Соединенных Штатах,
из-за отсутствия надежного национального идентификационного номера и/или
последовательной идентификации пациента в разных учреждениях и врачах.
Чтобы еще больше усложнить ситуацию, «Закон о переносимости и подотчетности медицинского страхования» (HIPAA) включает строгие требования к конфиденциальности и безопасности для защиты конфиденциального характера
информации о пациентах. Усовершенствования операционных процессов, такие
как электронные медицинские записи, обеспечивают более последовательную
идентификацию основного пациента.
Измерения «Диагноз» и «Лечение» значительно более структурированы
и предсказуемы, чем вы могли бы ожидать, поскольку страховая отрасль и правительство утвердили их содержание. Например, диагностика и классификация
заболеваний соответствуют стандарту «Международной классификации болезней» (МКБ) для последовательной отчетности. Аналогичным образом «Система кодирования общих процедур здравоохранения» (HCPCS) основана
на текущей процедурной терминологии Американской медицинской ассоциации (CPT) для описания медицинских, хирургических и диагностических услуг,
а также расходных материалов и устройств. Стоматологи используют «Текущий
набор кодов стоматологической терминологии» (CDT), который обновляется
и распространяется Американской ассоциацией стоматологов.
Наконец, помимо интегрированной клинической и финансовой информации, ориентированной на пациента, организации здравоохранения также хотят
анализировать оперативную информацию, касающуюся использования их рабочей силы, помещений и расходных материалов. Многое из того, что обсуждалось
в предыдущих главах о персонале, управлении запасами и процессах закупок,
также применимо к организациям здравоохранения.
Здравоохранение
423
Выставление счетов
и платежей по претензиям
Представьте, что вы работаете в биллинговой организации консорциума здравоохранения. Вы получаете первичные счета от врачей и учреждений, готовите
счета для ответственных плательщиков и отслеживаете ход полученных платежей
по претензиям.
Размерная модель процесса выставления счетов по претензиям должна учитывать ряд бизнес-целей. Вы хотите проанализировать выставленные суммы
в долларах по всем доступным измерениям, включая пациента, врача, учреждение, диагноз, процедуру и дату. Вы хотите посмотреть, как были оплачены эти
претензии и какой процент претензий не был собран. Вы хотите узнать, сколько
времени требуется для получения оплаты, и текущий статус всех неоплаченных
претензий.
Как мы обсуждали в главе 4, всякий раз, когда исходный бизнес-процесс рассматривается для включения в систему DW/BI, существуют три основных варианта выбора зернистости. Помните: зернистость таблицы фактов определяет, что
представляет собой строку таблицы фактов. Другими словами, что представляет
собой регистрируемое событие измерения?
Транзакционная зернистость наиболее фундаментальна. В примере выставления счетов за здравоохранение зернистость транзакций будет включать каждую
платежную транзакцию от врачей и учреждений, а также каждую полученную
транзакцию по оплате претензий. Сейчас мы подробнее поговорим об этих таблицах фактов.
Периодический снимок — это обычный выбор зернистости для долгосрочных временных рядов, таких как банковские счета и страховые полисы. Однако
периодический снимок не очень хорошо отражает поведение относительно недолговечных процессов, таких как заказы или выставление счетов по медицинским претензиям.
Зернистость накопительного моментального снимка выбрана для анализа
рабочего потока выставления счетов и платежей по претензиям. Одна строка
таблицы фактов представляет собой одну строку в медицинской претензии.
Кроме того, строка представляет накопленную историю позиции с момента
создания до текущего состояния. Когда что-либо в строке меняется, строка
пересматривается и соответствующим образом изменяется. С точки зрения
биллинговой организации давайте предположим, что стандартный сценарий
претензии включает:
■ дату лечения;
■ дату выставления счета за первичной страховой компании;
424
Глава 14
■ дату выставления счета вторичной страховой компании;
■ дату выставления счета ответственной стороной;
■ дату последней страховой выплаты первичной страховой компании;
■ дату последней страховой выплаты вторичной страховой компании;
■ дату последнего платежа ответственной стороны;
■ дату нулевого баланса.
Эти даты описывают обычную обработку медицинских страховых претензий. Накопительный снимок не пытается полностью описать необычные
ситуации. Бизнес- пользователям, несомненно, необходимо ознакомиться
со всеми подробностями сценариев оплаты претензий, поскольку иногда для
одной строки принимается несколько платежей или, наоборот, один платеж
иногда применяется к нескольким претензиям. Неизбежно потребуются сопутствующие схемы транзакций. В то же время цель накопления моментального снимка состоит в том, чтобы поместить каждую претензию в стандартную структуру, чтобы можно было легко выполнить аналитические задачи,
описанные ранее.
Имея четкое представление о том, что отдельная строка таблицы фактов
представляет накопленную историю позиции в счете-претензии, вы можете определить измерения, тщательно перечислив все, что соответствует действительности в контексте этой строки. В этом гипотетическом сценарии вам
известны пациент, ответственная сторона, врач, врачебная организация, процедура, учреждение, диагноз, первичная страховая организация, вторичная
страховая организация и основной идентификационный номер счета пациента, как показано на рис. 14-2.
Интересные факты, накопленные за историю строки претензий, включают:
■ сумму выставленного счета;
■ выплаченную сумму первичной страховки;
■ выплаченную сумму вторичной страховки;
■ выплаченную ответственной стороной сумму;
■ общую выплаченную сумму (рассчитанную);
■ сумму, отправленную на сбор;
■ списанную сумму;
■ сумму, оставшуюся к оплате (рассчитанную);
■ продолжительность пребывания;
■ количество дней от выставления счета до первоначального платежа первичного страхования, до вторичного страхования и платежей ответственной
стороны;
■ количество дней до нулевого баланса.
Здравоохранение
425
Таблица фактов выставления
счетов и процесса оплаты
Измерение «Дата» (8 ролей)
Измерение «Пациент»
Измерение «Процедура»
Измерение
«Первичный диагноз»
Измерение
«Ответственная сторона»
Ключ даты оказания помощи (FK)
Ключ даты платежа основной страховой
компании (FK)
Ключ даты платежа второй страховой
компании (FK)
Ключ даты оплаты ответственной стороны (FK)
Ключ даты последнего платежа основной
страховой компании (FK)
Ключ даты последнего платежа второй
страховой компании (FK)
Ключ последней ответственной стороны
за оплату (FK)
Ключ даты нулевого баланса (FK)
Ключ пациента (FK)
Ключ врача (FK)
Ключ медицинской организации (FK)
Ключ процедуры (FK)
Ключ оборудования (FK)
Первичный ключ диагноза (FK)
Ключ основной страховой организации (FK)
Ключ второй страховой организации (FK)
Ключ ответственной стороны (FK)
Ключ работодателя (FK)
ID основного счета (DD)
Сумма, выставленная в счете
Оплачено основной страховой организацией
Оплачено второй страховой организацией
Оплачено ответственной стороной
Всего оплачено
Отправленная на сбор сумма
Выписанные счета
Не оплачено (баланс)
Продолжительность пребывания
Время от выставления счета до оплаты
основной страховой организацией
Время от выставления счета до оплаты второй
страховой организацией
Время от выставления счета до его оплаты
ответственной стороной
Время от выставления счета до его закрытия
Измерение «Врач»
Измерение «Медицинская организация»
Измерение «Помещение»
Измерение «Страховая организация» (2 роли)
Измерение «Работодатель»
Рис. 14-2. Накопительная таблица фактов для выставления счетов
по медицинским чекам и потоковых оплат
Строка изначально создается в этой таблице фактов, когда запрос оплаты
принимается от врачей или учреждений и генерируются первоначальные счета.
По данному счету, возможно, выставляется счет первичной страховой компании,
но счет вторичной страховой компании и ответственной стороне не выставляется в ожидании ответа от первичной страховой компании. После первого
ввода строки в таблицу фактов последние семь дат не применяются. Поскольку ключи суррогатной даты в таблице фактов не должны быть Null, они будут
указывать на строку измерения «Дата», зарезервированную для даты, которую
необходимо определить. В течение нескольких недель после создания строки
426
Глава 14
поступают некоторые платежи. Затем счета отправляются вторичной страховой
компании и ответственной стороне. Каждый раз, когда происходят эти события, одна и та же строка таблицы фактов пересматривается и соответствующие
ключи и факты разрушительно обновляются. Это разрушительное обновление
создает некоторые проблемы для администратора базы данных. Если большая
часть накапливающихся строк стабилизируется и перестанет изменяться в течение определенного периода, физическая реорганизация базы данных в это время
может восстановить дисковое хранилище и повысить производительность. Если
таблица фактов разделена по ключу даты лечения, физическая кластеризация или
партиционирование, вероятно, будут хорошо сохранены во время этих изменений, поскольку дата лечения не пересматривается и не изменяется.
Ролевое измерение «Дата»
В таблицах фактов моментальных снимков всегда включено несколько меток
даты, например, восемь внешних ключей, указывающих на измерение «Дата»
на рис. 14-2. Восемь внешних ключей даты не должны присоединяться к одному
экземпляру таблицы измерений «Дата». Вместо этого создайте восемь представлений в одной базовой таблице измерений «Дата» и присоедините таблицу
фактов отдельно к этим восьми представлениям, как если бы они были восемью
независимыми таблицами измерений дат. Восемь определений представлений
должны косметически изменить названия столбцов, чтобы их можно было
различить, поэтому инструменты BI, получающие доступ к представлениям,
предоставляют бизнес-пользователям понятные имена столбцов. Хотя ролевое
измерение «Дата» — основная характеристика таблиц фактов накопительных
моментальных снимков, другие измерения на рис. 14-2 играют аналогичные
роли, например измерение «Плательщик». В разделе «Супертипы и подтипы
для запросов оплаты» измерение «Врач» будет играть несколько ролей в зависимости от того, является ли врач направляющим врачом, лечащим врачом или
работает в качестве консультанта или ассистента.
Многозначные диагнозы
Обычно измерения, окружающие таблицу фактов, принимают одно значение
в контексте события факта. Однако бывают ситуации, когда многозначность
естественна и неизбежна. Хороший пример — измерение «Диагноз» в таблицах
фактов здравоохранения. На момент процедуры или лабораторного исследования у пациента есть один или несколько диагнозов. Приложения для электронных медицинских записей облегчают для врача выбор нескольких диагнозов,
выходящих далеко за рамки исторической практики предоставления минимального кодирования, необходимого для возмещения расходов; результат — более
Здравоохранение
427
богатая и полная картина тяжести состояния пациента. Существует сильный аналитический стимул для сохранения многозначных диагнозов наряду с другими
данными о финансовых показателях, особенно по мере того, как организации
проводят более сравнительный анализ использования и затрат.
Например, если бы всегда было не более трех диагнозов, у вас мог бы возникнуть соблазн создать три внешних ключа диагноза в таблице фактов с соответствующими измерениями, почти как если бы они были ролевыми. Однако
диагнозы не ведут себя как независимые роли. И, к сожалению, часто бывает
более трех диагнозов, особенно у госпитализированных пожилых пациентов,
у которых может быть 20 одновременных диагнозов! Диагнозы не вписываются
в четко определенные роли, кроме потенциально первичных диагнозов приема
и выписки. Наконец, дизайн с несколькими внешними ключами диагнозов сделал бы приложения BI очень неэффективными, поскольку запрос не знает, какое
измерение использовать для конкретного диагноза. Конструкция, показанная
на рис. 14-3, учитывает открытый характер множественных диагнозов. Внешний
ключ диагноза в таблице фактов заменяется ключом группы диагнозов. Этот
ключ группы диагнозов соединен соединением «многие ко многим» с соединительной таблицей группы диагнозов, которая содержит отдельную строку для
каждого отдельного диагноза в определенной группе.
Таблица фактов выставления
счета по претензии
Другие ключи …
Ключ группы диагноза (FK)
ID основного счета (DD)
Факты …
Соединительная таблица
«Группа диагнозов»
Ключ группы диагноза (FK)
Ключ диагноза (FK)
Измерение «Диагноз»
Ключ диагноза (PK)
Код диагноза (NK)
Описание диагноза
Код секции диагноза
Описание секции диагноза
Код категории диагноза
Описание категории диагноза
Рис. 14-3. Соединительная таблица для обработки многозначных диагнозов
Если у пациента три диагноза, ему присваивается группа диагнозов с тремя
соответствующими строками в соединительной таблице. В главе 10 мы описали
использование весового коэффициента в каждой строке соединительной таблицы для соответствующего распределения показателей таблицы фактов. Однако
в случае множественных диагнозов практически невозможно оценить их влияние
на лечение или счет пациента, помимо потенциального определения первичного
диагноза. Без реалистичного способа назначения весовых коэффициентов анализ
428
Глава 14
диагностических кодов должен быть в основном сосредоточен на вопросах воздействия, таких как «Какова общая сумма выставленного счета за процедуры,
связанные с диагностикой застойной сердечной недостаточности?» Большинство медицинских аналитиков понимают, что анализ воздействия может привести к чрезмерному подсчету, поскольку одни и те же показатели связаны с несколькими диагнозами.
ПРИМЕЧАНИЕ Весовые коэффициенты в многозначных соединительных
таблицах обеспечивают элегантный способ распределения числовых фактов для
создания правильно взвешенных отчетов. Однако эти весовые коэффициенты
ни в коем случае не требуются при проектировании измерений. Если в деловом
сообществе нет согласия или энтузиазма в отношении весовых коэффициентов,
их не следует учитывать. Кроме того, в схеме с более чем одним многозначным
измерением не стоит пытаться решить, как будут взаимодействовать несколько
весовых коэффициентов.
Если соединение «многие ко многим» на рис. 14-3 вызывает проблемы для
инструмента моделирования, который настаивает на правильных отношениях внешнего ключа к первичному ключу, можно использовать эквивалентный
дизайн на рис. 14-4. В этом случае дополнительная таблица, первичный ключ
в которой — группа диагнозов, вставляется между таблицами фактов и соединительной таблицей. Скорее всего, в этой дополнительной таблице нет новой
информации, если только не было меток для группы диагнозов, таких как синдром Кимбалла, но теперь и таблица фактов, и соединительная таблица имеют
обычные соединения «многие к одному» во всех направлениях.
Таблица фактов
выставления
счета по претензии
Внешние ключи …
Ключ группы диагноза (FK)
ID основного счета (DD)
Факты …
Измерение
«Группа диагнозов»
Ключ группы диагноза (PK)
Соединительная таблица
«Группа диагнозов»
Ключ группы диагноза (FK)
Ключ диагноза (FK)
Рис. 14-4. Измерение «Группа диагнозов» для создания связи
по первичному ключу
Измерение «Диагноз»
Ключ диагноза (PK)
Код диагноза (NK)
Описание диагноза
Код секции диагноза
Описание секции диагноза
Код категории диагноза
Описание категории диагноза
Здравоохранение
429
Если для каждого приема пациента будет создана уникальная группа диагнозов, количество строк может стать астрономическим, и многие группы будут
идентичными. Вероятно, лучший подход состоит в том, чтобы иметь набор групп
диагнозов, которые используются неоднократно. Каждый набор диагнозов будет
просматриваться в основной таблице групп диагнозов во время ETL. Если существующая группа найдена, она используется; если не найдена, создается новая.
Глава 19 содержит рекомендации по созданию и администрированию соединительных таблиц.
В сценарии пребывания в стационаре группа диагнозов может быть уникальной для каждого пациента, если она меняется с течением времени во время
пребывания пациента. В этом случае вы бы дополнили соединительную таблицу двумя отметками даты, чтобы зафиксировать даты начала и окончания. Хотя
двойные метки даты усложняют обновление сводной таблицы группы диагнозов,
они полезны для отслеживания изменений, как более подробно описано в главе 7.
Супертипы и подтипы для запросов оплаты
Мы описали схему оплачиваемого медицинского лечения, которая охватывает как стационарные, так и амбулаторные заявки. В действительности расходы
на здравоохранение напоминают схему супертипов и подтипов, описанную в главе 10. Плата за пребывание в стационаре отличается от профессиональных сборов за амбулаторное лечение в клиниках и кабинетах врачей.
Если бы вы были сосредоточены исключительно на пребывании в больнице,
было бы разумно изменить размерную структуру рис. 14-2, чтобы включить больше информации о конкретной больнице. На рис. 14-5 показан пересмотренный
набор измерений, предназначенных для пребывания в больнице, с новыми измерениями, выделенными жирным шрифтом.
Обратившись к рис. 14-5, вы можете увидеть две роли врача: принимающий
и лечащий. На рисунке показаны организации врачей для обеих ролей, поскольку врачи могут представлять разные организации в условиях больницы. При
более сложных хирургических вмешательствах, таких как операция по пересадке
сердца, собираются целые команды специалистов и ассистентов. В этом случае
вы можете добавить ключ в таблицу фактов для основного ответственного врача;
другие врачи и медицинский персонал будут связаны со строкой фактов с помощью группового ключа к многозначной соединительной таблице.
У вас также есть два многозначных измерения «Диагноз» в каждой строке
таблицы фактов. Группа диагнозов при поступлении определяется в начале пребывания в больнице и должна быть одинаковой для каждой записи в таблице
«Лечение» — это часть одного и того же пребывания в больнице. Группа диагнозов выписки неизвестна до тех пор, пока пациент не будет выписан.
430
Глава 14
Таблица фактов выставления счетов и процесса оплаты счетов стационарной больницы
Ключ даты оказания помощи (FK)
Ключ даты платежа основной страховой компании (FK)
Ключ даты платежа второй страховой компании (FK)
Ключ даты оплаты ответственной стороны (FK)
Ключ даты последнего платежа основной страховой компании (FK)
Ключ даты последнего платежа второй страховой компании (FK)
Ключ последней ответственной стороны за оплату (FK)
Ключ даты нулевого баланса (FK)
Ключ пациента (FK)
Ключ лечащего врача при поступлении (FK)
Ключ медицинской организации при поступлении (FK)
Ключ выписавшего врача (FK)
Ключ медицинской организации при выписке (FK)
Ключ процедуры (FK)
Ключ оборудования (FK)
Ключ группы диагноза при поступлении (FK)
Ключ группы диагноза при выписке (FK)
Ключ основной страховой организации (FK)
Ключ второй страховой организации (FK)
Ключ ответственной стороны (FK)
Ключ работодателя (FK)
ID основного счета (DD)
Факты …
Рис. 14-5. Варианты оплат пребывания в больнице
Электронные медицинские записи
Многие организации здравоохранения переходят от бумажных процессов к электронным медицинским записям. В Соединенных Штатах федерально установленные цели в области качества для поддержки улучшения управления здравоохранением населения могут быть достигнуты только при их принятии. Поставщики
медицинских услуг активно внедряют электронные системы медицинской документации; это движение оказывает существенное влияние на инициативы DW/
BI в области здравоохранения.
Электронные медицинские записи могут создавать проблемы для сред хранения данных из-за их чрезвычайной изменчивости и потенциально экстремальных
объемов. Данные медицинской карты пациентов представлены в самых разных
видах начиная от числовых данных и заканчивая текстовыми комментариями
произвольной формы, введенными медицинским работником, и заканчивая
изображениями и фотографиями. Мы подробнее обсудим неструктурированные данные в главе 21; электронные медицинские и/или санитарные карты могут стать классическим примером использования Big data. Одно можно сказать
Здравоохранение
431
наверняка: объем и изменчивость электронных данных в отрасли здравоохранения будут продолжать расти.
Измерение «Тип измерения» для разреженных фактов
Проектировщики стремятся к более стандартизированной структуре, которую
можно было бы расширить для обработки изменчивых данных. Например, вы
потенциально можете обрабатывать изменчивость результатов лабораторных
тестов с помощью измерения «Тип измерения», описывающего, что означает
строка фактов, или, другими словами, что представляет собой общий факт. Единица измерения для такой числовой записи находится в соответствующей строке
измерения «Тип измерения» вместе с любыми ограничениями на аддитивность,
как показано на рис. 14-6.
Таблица фактов результатов
лабораторных исследований
Ключ даты заказа (FK)
Ключ даты тестов (FK)
Ключ пациента (FK)
Ключ врача (FK)
Ключ лабораторного теста (FK)
Ключ типа метрик лабораторного теста (FK)
Наблюдаемые результаты теста
Таблица фактов результатов
лабораторных исследований
Ключ типа метрик лабораторного теста (PK)
Описание типа метрики лабораторного теста
Единица измерения результатов лабораторного теста
Рис. 14-6. Лабораторные тестовые наблюдения с характеристикой типа
«Измерение»
Этот подход удивительно гибкий; вы можете добавлять новые типы измерений, просто добавляя новые строки в измерение «Тип измерения», а не изменяя
структуру таблицы фактов. Этот подход также устраняет пустые значения (Null)
в классическом дизайне позиционной таблицы фактов, поскольку строка существует только в том случае, если существует измерение. Однако есть и компромиссы. Использование измерения «Тип» может привести к появлению большого
количества новых строк таблицы фактов, поскольку зернистость — «одна строка на измерение на событие», а не более типичное «одна строка на событие».
Если лабораторный исследование приводит к 10 числовым измерениям, то теперь
в таблице фактов 10 строк, а не одна строка в классическом дизайне. Для ситуаций, приводящих к разреженным данным, таких как клинические лабораторные
или производственные испытательные среды, это разумный компромисс. Однако
по мере роста плотности фактов вы в итоге будете создавать слишком много строк
фактов. На этом этапе у вас больше нет разреженных фактов, и вам следует вернуться к классическому дизайну таблицы фактов с фиксированными столбцами.
432
Глава 14
Более того, такой подход с типом измерений может усложнить приложения
для доступа к данным BI. В реляционной схеме типа «звезда» объединение
двух чисел, которые были записаны как часть одного события, при таком подходе сложнее, потому что теперь вы должны извлечь две строки из таблицы фактов. SQL любит выполнять арифметические функции внутри строки, а не между
строками. Кроме того, вы должны быть осторожны, чтобы не смешивать несовместимые суммы в расчете, поскольку все числовые показатели находятся в одном столбце суммы. Стоит отметить, что размерные кубы OLAP более устойчивы к выполнению вычислений между типами измерений.
Текстовые комментарии произвольной формы
Текстовые комментарии произвольной формы, такие как клинические заметки,
иногда ассоциируются с событиями таблицы фактов. Хотя текстовые комментарии не очень эффективны с аналитической точки зрения, если они не разбиты
на атрибуты измерения с правильным поведением, бизнес-пользователи часто
не желают расставаться с ними, учитывая, что в них можно найти хоть какие-то
крохи информации.
Текстовые комментарии не следует хранить непосредственно в таблице фактов, поскольку они занимают много места и редко участвуют в запросах. Некоторые дизайнеры считают допустимым хранить текстовые поля в таблице
фактов, если они называются вырожденными измерениями. Вырожденные измерения чаще всего используются для контрольных номеров и идентификаторов
операционных транзакций; это неприемлемый подход или шаблон для работы
с объемными текстовыми полями. Хранение комментариев произвольной формы в таблице фактов создает беспорядок, который может негативно повлиять
на производительность более типичных количественных запросов аналитиков.
Неограниченные текстовые комментарии следует либо хранить в отдельном
измерении комментариев, либо рассматривать как атрибуты в измерении «Событие транзакции». Ключевой фактор при оценке этих двух подходов — кардинальность текстового поля. Если для каждого события таблицы фактов имеется
почти уникальный комментарий, наиболее целесообразно хранить текстовое
поле в измерении «Транзакция». Однако во многих случаях «Комментарии»
не связаны с многочисленными строками фактов. Поскольку количество уникальных текстовых комментариев в этом сценарии намного меньше, чем количество уникальных транзакций, было бы разумнее хранить текстовые данные
в измерении «Комментарий» с соответствующим внешним ключом в таблице
фактов. В любом случае запросы, включающие как текстовые комментарии, так
и показатели фактов, будут выполняться относительно плохо, учитывая необходимость соединять две объемные таблицы. Часто бизнес-пользователи хотят
Здравоохранение
433
углубиться в текстовые комментарии для дальнейшего изучения после применения высокоселективных фильтров запросов таблицы фактов.
Изображения
Иногда данные, записанные в электронной медицинской карте пациента, представляют собой изображение в дополнение к количественным цифрам или качественным примечаниям. Существуют компромиссы между хранением имени
файла JPEG в таблице фактов для ссылки на связанное изображение и внедрением изображения в виде большого двоичного объекта (BLOB) непосредственно
в базу данных. Преимущество использования имени файла JPEG заключается
в том, что другие программы создания, просмотра и редактирования изображений могут свободно обращаться к изображению. Недостаток в том, что отдельная база данных графических файлов должна поддерживаться синхронно с таблицей фактов.
Использование инвентаря
помещений, оборудования
В дополнение к финансовым и клиническим данным организации здравоохранения также остро заинтересованы в более оперативных показателях, таких как
использование и доступность их активов, будь то койки для пациентов или хирургические операционные. В главе 4 мы обсуждали данные инвентаризации
продуктов как события транзакций, а также периодические моментальные снимки. Инвентаризация помещений или оборудования в организации здравоохранения может обрабатываться аналогичным образом.
Например, вы можете представить периодический снимок использования
кроватей со статусом каждой кровати в регулярно повторяющиеся моменты,
возможно, в полночь, в начале каждой смены или даже чаще в течение дня. В дополнение к дате моментального снимка и, возможно, времени суток эта таблица
фактов без фактов будет включать внешние ключи для идентификации пациента,
лечащего врача и, возможно, назначенной дежурной медсестры.
И наоборот, вы можете представить себе обработку данных инвентаризации
кроватей в виде таблицы фактов транзакций с одной строкой для каждого перемещения на больничную койку и обратно. Это может быть упрощенная таблица
фактов транзакции с внешними ключами измерения даты и времени транзакции,
а также измерениями для описания типа перемещения, например заполненного
или освобожденного. В случае использования и доступности операционной вы
можете представить более длинный список статусов, таких как дооперационный,
послеоперационный или простой, а также продолжительность времени.
434
Глава 14
Если изменения в инвентаре не дифференцированы, например койки в условиях реабилитации или ухода за пожилыми людьми, вам следует рассмотреть
таблицу фактов за определенный промежуток времени, как обсуждалось в главе
8, с датами и временем действия строк и датами истечения срока действия для
представления различных состояний кровати за определенный период.
Работа с ретроактивными изменениями
Как специалисты в области DW/BI мы обладаем хорошо разработанными методами точного сбора исторического потока данных из исходных приложений
нашего предприятия. Числовые измерения входят в таблицы фактов, которые
окружены современными описаниями того, что, как вы знаете, верно во время
измерений, упакованными в виде таблиц измерений. Описания пациента, врача,
учреждения и плательщика развиваются как медленно меняющиеся измерения
всякий раз, когда эти сущности меняют свои описания.
Однако в отрасли здравоохранения, особенно с устаревшими операционными системами, часто приходится иметь дело с запоздалыми поступающими данными, которые должны были быть загружены в хранилище данных несколько
недель или месяцев назад. Например, вы можете получать данные о процедурах,
проведенных пациентами несколько недель назад, или обновления профилей пациентов, которые были обновлены несколько месяцев назад. Чем больше задержек с поступающими записями, тем сложнее становится обработка ETL в системе DW/BI. Мы обсудим эти сценарии запоздалых фактов и измерений в главе 19.
К сожалению, эти шаблоны распространены в средах DW/BI здравоохранения;
на самом деле, они могут быть доминирующими способами обработки, а не специализированными методами для исключительных случаев. В итоге более эффективные системы сбора исходных данных должны снизить частоту этих аномалий
в данных, поступающих с опозданием.
Выводы
Здравоохранение предоставляет множество примеров размерного проектирования. В этой главе матрица шины корпоративного хранилища данных проиллюстрировала важнейшие связи между административными и клиническими
данными организации здравоохранения. Мы использовали таблицу фактов накопительных моментальных снимков с ролевыми измерениями «Дата» для выставления счетов и оплаты медицинских требований. Мы также видели ролевые
измерения, используемые для измерений «Врач» и «Плательщик», в других
таблицах фактов этой главы.
Здравоохранение
435
Схемы здравоохранения изобилуют многозначными измерениями, особенно
измерением «Диагноз». В сложных хирургических мероприятиях также могут
использоваться многозначные соединительные таблицы для представления команд задействованных врачей и других сотрудников. Соединительные таблицы,
используемые с данными о здравоохранении, редко содержат весовые коэффициенты, как обсуждалось в предыдущих главах, поскольку чрезвычайно сложно
установить бизнес-правила взвешивания, помимо обозначения первичных отношений.
Мы обсудили медицинские записи и результаты анализов, предложив измерение «Тип измерения» для организации разреженных и разнообразных измерений в единообразную структуру. Мы также обсудили обработку текстовых
комментариев и связанных изображений. Таблицы фактов транзакций и периодических моментальных снимков использовались для представления использования и доступности помещений или оборудования. В заключение мы коснулись
ретроактивных изменений фактов и измерений, которые достаточно часто встречаются с данными о деятельности здравоохранения.
15
Электронная
коммерция
Д
анные о потоке кликов в веб-бизнесе фиксируют поведение каждого посетителя сайта. В своей наиболее элементарной форме поток кликов — это событие
каждой страницы, записываемое каждым из веб-серверов компании. Поток кликов
содержит ряд новых измерений, таких как «Страница», «Сеанс» и «Ссылка»,
которых нет в других источниках данных. Поток кликов — это поток данных; это
может быть сложно и раздражающе для профессионалов DW/BI. Подключается ли
он к остальной части системы DW/BI? Могут ли его измерения и факты быть согласованными в архитектуре шины корпоративного хранилища данных?
Мы начнем эту главу с описания исходного источника clickstream-данных
и разработки соответствующих размерных моделей. Мы обсудим влияние Google
Analytics — сервис можно рассматривать как внешнее хранилище данных, предоставляющее информацию о вашем сайте. Затем мы интегрируем данные о потоке
кликов в более широкую матрицу более традиционных процессов для интернетмагазина и сообщим, что прибыльность канала интернет-продаж может быть измерена, если вы правильно распределите затраты на отдельные продажи.
В главе 15 рассматриваются следующие концепции:
■ поток кликов и его уникальная размерность;
■ роль внешних сервисов, таких как Google Analytics;
■ интеграция потока кликов с другими бизнес-процессами в матрице шины;
■ создание полного представления о прибыльности для веб-предприятия.
Источники данных для потока кликов
Поток кликов — это не просто еще один источник данных, который извлекается, очищается и сбрасывается в среду DW/BI. Поток кликов — это развивающийся набор источников данных. Существует несколько форматов файлов журналов сервера для сбора данных о потоке кликов. Эти форматы файлов журналов
содержат дополнительные компоненты данных, которые, если их использовать,
438
Глава 15
могут быть очень полезны для идентификации посетителей, сеансов и истинного
значения поведения.
Из-за распределенного характера интернета данные о потоке кликов часто собираются одновременно разными физическими серверами, даже если посетитель
думает, что он взаимодействует с одним сайтом. Даже если файлы журналов, собранные этими отдельными серверами, совместимы, возникает очень интересная
проблема при синхронизации файлов журналов постфактум. Помните, что загруженный веб-сервер может обрабатывать сотни событий страницы в секунду?
Маловероятно, что часы на отдельных серверах будут синхронизированы с точностью до одной сотой секунды.
Вы также получаете данные о потоке кликов от разных сторон. Помимо ваших собственных файлов журнала, вы можете получать данные о потоке кликов
от ссылающихся партнеров или от интернет-провайдеров. Другая важная форма
данных о потоке кликов — поисковый запрос, предоставляемый поисковой системе, которая затем направляет посетителя на сайт.
Наконец, если вы интернет-провайдер, предоставляющий веб-доступ напрямую подключенным клиентам, у вас есть уникальная перспектива, потому что
вы видите каждый клик ваших постоянных клиентов, что позволяет проводить
более мощный и инвазивный анализ сеансов клиента.
Основная форма данных о потоке кликов с обычного веб-сайта не имеет состояния, то есть в журнале отображается изолированное событие извлечения
страницы, но не обеспечивается четкая связь с другими событиями страницы
в других местах журнала. Без какой-либо контекстной помощи трудно или невозможно надежно идентифицировать полный сеанс посетителя.
Еще одно большое разочарование, связанное с базовыми данными о потоке
кликов, — это анонимность сеанса. Если посетители не согласятся каким-либо
образом раскрыть свою личность, вы часто не можете быть уверены, кто они и видели ли вы их когда-либо раньше. В определенных ситуациях вы можете не различать клики двух посетителей, которые одновременно просматривают сайт.
Проблемы с данными из потоков кликов
Данные потока кликов содержат много двусмысленностей. Идентификация происхождения посетителей, сеансов посетителей и идентификационных данных
посетителей — это своего рода искусство интерпретации. Кеш браузера и прокси-серверы усложняют эту идентификацию.
Идентификация происхождения посетителя
Если вам очень повезет, ваш сайт будет домашней страницей по умолчанию
для браузера посетителя. Каждый раз, когда он открывает свой браузер, ваша
Электронная коммерция
439
домашняя страница — это первое, что он видит. Это довольно маловероятно,
если вы не веб-мастер сайта или домашней страницы интрасети, но на многих
сайтах есть кнопки, при нажатии на которые посетителям предлагается указать
свой URL-адрес в качестве домашней страницы браузера. К сожалению, нет простого способа определить из журнала, установлен ли ваш сайт в качестве такой
страницы.
Посетитель может быть перенаправлен на ваш сайт из поиска в Yahoo! или
Google. Такие ссылки могут поступать либо из индекса портала, за который вы,
возможно, заплатили плату за размещение, либо из поиска по словам или контенту.
Для некоторых сайтов наиболее распространенный источник посетителей —
закладка браузера. Для этого посетитель должен предварительно сделать закладку на вашем сайте, и это может произойти только после того, как уровень интереса и доверия к сайту превысит порог закладок посетителя.
Наконец, на ваш сайт можно попасть в результате перехода по ссылке — преднамеренного нажатия на текстовую или графическую ссылку с другого сайта. Это
может быть платный реферал через рекламный баннер или бесплатный реферал
от частного лица или сотрудничающего сайта. В случае переходов по ссылкам
ссылающийся сайт почти всегда будет идентифицирован как поле в записи вебсобытия. Сбор этих значимых данных о потоке кликов важен для проверки эффективности маркетинговых программ. Он также предоставляет важные данные
для аудита счетов-фактур, которые вы можете получить в результате оплаты рекламы по кликам.
Идентификация сеанса
Большинство веб-ориентированных анализов требуют, чтобы каждый сеанс посетителя (посещение) имел собственную уникальную идентификационную метку, аналогичную номеру чека супермаркета. Это идентификатор сеанса. Записи
для каждого отдельного действия посетителя в сеансе независимо от того, результат ли это потока кликов или взаимодействия с приложением, должны содержать
этот тег. Но имейте в виду, что генерирует этот идентификатор сеанса операционное приложение, такое как система ввода заказов, а не веб-сервер.
Базовый протокол для интернета, протокол передачи гипертекста (HTTP),
не имеет состояния; то есть в нем отсутствует концепция сеанса. У HTTP нет
встроенных действий входа или выхода, поэтому идентификация сеанса должна
быть установлена каким-либо другим способом.
Во многих случаях отдельные обращения, составляющие сеанс, могут быть
объединены путем сопоставления непрерывных по времени записей журнала
с одного и того же хоста (IP-адреса). Если журнал содержит несколько записей
440
Глава 15
с одним и тем же идентификатором хоста за короткий промежуток времени
(например, один час), вы можете разумно предположить, что записи относятся
к одному и тому же сеансу. Этот метод не подходит для сайтов с большим количеством посетителей, поскольку динамически назначаемые IP-адреса могут быть
немедленно повторно использованы разными посетителями в течение короткого периода времени. Кроме того, в рамках одного и того же сеанса для одного
и того же посетителя могут использоваться разные IP-адреса. Этот подход также
создает проблемы при работе с браузерами, которые находятся за некоторыми
брандмауэрами. Несмотря на эти проблемы, многие коммерческие продукты
для анализа журналов используют этот метод отслеживания сеансов, и для этого
не требуются файлы cookie или специальные функции веб-сервера.
Другой, гораздо более удовлетворительный метод заключается в том, чтобы
позволить браузеру размещать файл cookie сеансового уровня в браузере посетителя. Этот файл cookie будет храниться до тех пор, пока браузер открыт,
и, как правило, не будет доступен в последующих сеансах браузера. Значение
файла cookie может служить временным идентификатором сеанса не только
для браузера, но и для любого приложения, которое запрашивает файл cookie
сеанса у браузера. Но использование временных файлов cookie имеет тот недостаток, что вы не можете определить, когда посетитель вернется на сайт позже
в новом сеансе.
Уровень защищенных сокетов HTTP (SSL) предоставляет возможность отслеживать сеанс посетителя, поскольку он может включать действие входа посетителя в систему и обмен ключами шифрования. Недостаток использования этого метода в том, что для отслеживания сеанса весь обмен информацией должен
осуществляться с использованием протокола SSL с высокими накладными расходами, и посетителя способны отпугнуть рекомендации по безопасности, которые могут появляться при использовании определенных браузеров. Кроме того,
каждый хост должен иметь собственный уникальный сертификат безопасности.
Если генерация страниц динамическая, вы можете попытаться сохранить
состояние посетителя, поместив идентификатор сеанса в скрытое поле каждой
страницы, возвращаемой посетителю. Этот идентификатор сеанса может быть
возвращен серверу в виде строки запроса, добавленной к последующему URLадресу. Этот метод отслеживания сеансов требует большого контроля над методами генерации страниц сайта, чтобы гарантировать, что поток идентификатора
сеанса не нарушен. Если посетитель нажимает на ссылки, которые не поддерживают механизм ping-pong для идентификатора сеанса, один сеанс может выглядеть как несколько сеансов. Этот подход также не работает, если несколько поставщиков предоставляют контент в одном сеансе, если только эти поставщики
не тесно сотрудничают.
Электронная коммерция
441
Наконец, сайт может установить постоянный файл cookie на компьютере посетителя, который не удаляется браузером по окончании сеанса. Конечно, возможно, что посетитель настроит свой браузер на отказ от файлов cookie или может вручную очистить свои файлы cookie, поэтому нет абсолютной гарантии, что
даже постоянный файл cookie сохранится. Хотя любой подобный файл cookie
может быть прочитан только сайтом, который вызвал его создание, определенные группы сайтов могут согласиться хранить общий идентификационный тег,
который позволил бы этим сайтам объединить свои отдельные представления
о сеансе посетителя в «суперсессию».
Таким образом, наиболее надежный метод отслеживания сеансов по записям
журнала веб-сервера достигается установкой постоянного файла cookie в браузере посетителя. Менее надежные, но хорошие результаты можно получить, установив уровень сеанса и непостоянный файл cookie, а также связав непрерывные
по времени записи журнала с одного и того же хоста. Последний метод требует
надежного алгоритма в постпроцессоре журнала, чтобы обеспечить удовлетворительные результаты и решить, когда не следует воспринимать результаты всерьез.
Идентификация посетителя
Идентификация конкретного посетителя, который входит на ваш сайт, представляет собой одну из наиболее сложных проблем, с которыми сталкиваются дизайнер сайта, веб-мастер или менеджер группы веб-аналитики.
1. Веб-посетители хотят быть анонимными. У них может не быть причин доверять вам, интернету или своему компьютеру личную идентификационную информацию или информацию о кредитной карте.
2. Если вы запрашиваете личность посетителей, они могут не предоставить
точную информацию.
3. Вы не можете быть уверены, какой член семьи посещает ваш сайт. Если вы
получаете идентификацию по ассоциации, например, с помощью постоянного файла cookie, оставленного во время предыдущего посещения, идентификация предназначена только для компьютера, а не для конкретного
посетителя. Любой член семьи или сотрудник компании, возможно, пользовался этим конкретным компьютером в тот момент времени.
4. Вы не можете предполагать, что человек всегда находится за одним и тем же
компьютером. Файлы cookie, предоставляемые сервером, идентифицируют
компьютер, а не физическое лицо. Если кто-то заходит на один и тот же
сайт с рабочего компьютера, домашнего компьютера и мобильного устройства, на каждом компьютере, вероятно, устанавливается другой файл cookie
сайта.
442
Глава 15
Размерные модели потока кликов
Прежде чем разрабатывать размерные модели потока кликов, давайте рассмотрим все измерения, которые могут иметь значение в среде потока кликов. Никакая размерная модель не будет использовать все измерения сразу, но приятно
иметь портфель измерений, ожидающих использования. Список измерений для
интернет-магазина может включать такие:
■ дата;
■ время суток;
■ деталь;
■ поставщик;
■ статус;
■ перевозчик;
■ расположение объектов;
■ продукт;
■ клиент;
■ средства массовой информации;
■ продвижение по службе;
■ внутренняя организация;
■ сотрудник;
■ страница;
■ событие;
■ сессия;
■ направление.
Все измерения в списке, за исключением последних четырех, выделенных
жирным шрифтом, — это уже знакомые вам измерения, большинство из которых мы использовали в предыдущих главах этой книги. Но последние четыре —
уникальные измерения потока кликов, они требуют некоторого пристального
внимания.
Измерение «Страница»
Измерение «Страница» описывает контекст для любого события веб-страницы,
как показано на рис. 15-1. Зернистость этого измерения — отдельная страница. Определение страницы должно быть достаточно гибким, чтобы обеспечить
эволюцию веб-страниц от статической до высокодинамичной доставки страниц,
при которой конкретная страница, которую видит клиент, уникальна в данный
момент. Мы предполагаем, что даже в случае динамической страницы существует четко определенная функция, которая характеризует страницу, и мы будем
Электронная коммерция
443
использовать ее для описания страницы. Мы не будем создавать строку в таблице
«Страница» для каждого экземпляра динамической страницы, потому что это
приведет к измерению с астрономическим количеством строк. Эти строки также
не будут особо отличаться друг от друга. Вам нужна строка в этом измерении
для каждого интересного различимого типа страницы. Статические страницы,
вероятно, получат собственную строку, но динамические страницы будут сгруппированы по аналогичной функции и типу.
Атрибуты измерения «Страница» Пример данных/определение
Ключ страницы
Суррогатные значения (1..N)
Исходный код страницы
Статичная, Динамическая, Неизвестно, Данные повреждены,
Неприменимо, …
Функции страницы
Портал, Поиск, Описание товара, Информация о компании, …
Шаблон страницы
Пустая, Много информации, …
Тип товара
Артикул товара, Номер ISBN книги, Тип телефонной сети, …
Тип изображений
GIF, JPG, Постепенная подгрузка, Размер предопределен, …
Тип анимации
Аналогично типу изображений
Тип звуков
Аналогично типу изображений
Название файла страницы
Необязательное имя, зависящее от приложения
Рис. 15-1. Атрибуты измерения «Страница» и значения выборочных данных
Когда определение статической страницы изменяется из-за того, что оно
изменено веб-мастером, строка измерения страницы может быть либо перезаписана типом 1, либо обработана альтернативным методом медленного изменения. Это решение относится к вопросам политики хранилища данных
и зависит от того, отличаются ли старые и новые описания страницы существенно и следует ли сохранять старое определение для целей исторического
анализа.
Дизайнерам сайтов, представителям бизнеса по управлению данными и архитекторам DW/BI необходимо сотрудничать, чтобы назначить описательные
коды и атрибуты каждой странице, обслуживаемой веб-сервером, независимо
от того, динамическая она или статическая. В идеале разработчики веб-страниц предоставляют описательные коды и атрибуты с каждой создаваемой
страницей и встраивают эти коды и атрибуты в дополнительные поля файлов
веб-журналов. Этот решающий шаг лежит в основе реализации измерения
«Страница».
Прежде чем покинуть измерение «Страница», мы хотим отметить, что некоторые интернет-компании отслеживают более детализированные отдельные элементы на каждой странице своих сайтов, включая графические элементы и ссылки. Каждый элемент генерирует собственную строку для каждого посетителя
444
Глава 15
и каждого запроса страницы. Одна сложная страница может генерировать сотни
строк каждый раз, когда она демонстрируется посетителю. Очевидно, что эта
крайняя степень детализации генерирует астрономические объемы данных, часто превышающие 10 терабайт в день!
Аналогичным образом игровые компании могут генерировать строку для
каждого движения каждого игрока онлайн-игры, что опять же может привести
к сотням миллионов строк в день. В обоих случаях наиболее атомарная таблица
фактов будет иметь дополнительные измерения, описывающие графический элемент, ссылку или игровую ситуацию.
Измерение «Событие»
Измерение «Событие» описывает, что произошло на определенной странице
в определенный момент. Основные интересные события: «Открытие страницы», «Обновление страницы», «Переход по ссылке» и «Ввод данных». Вы
захотите зафиксировать эту информацию в этом небольшом измерении события,
как показано на рис. 15-2.
Атрибуты измерения «Событие»
Ключ события
Тип события
Содержание события
Пример данных/определение
Суррогатные значения (1..N)
Открыть страницу, Обновить страницу, Перейти по ссылке,
Неизвестно, Неприменимо
Поля, зависящие от приложения, обычно управляются
XML-тегами
Рис. 15-2. Параметры события и значения выбранных данных
Измерение «Сеанс»
Измерение «Сеанс» обеспечивает один или несколько уровней диагностики
для сеанса посетителя в целом, как показано на рис. 15-3. Например, локальный
контекст сеанса может запрашивать информацию о продукте, но общий контекст
сеанса может заключаться в заказе этого продукта. Атрибут «Статус успеха»
позволит определить, была ли миссия завершена. Локальный контекст может
быть определен только на основе идентификатора текущей страницы, но общий
контекст сеанса, вероятно, можно оценить только путем обработки полного
сеанса посетителя во время извлечения данных. Атрибут «Статус клиента» —
это удобное место для обозначения клиента в течение определенного периода
с помощью меток, которые не видны ни на странице, ни в непосредственном
сеансе. Эти статусы могут быть получены из вспомогательных бизнес-процессов
в системе DW/BI, но, разместив эти метки глубоко в потоке кликов, вы можете
Электронная коммерция
445
напрямую изучать поведение определенных типов клиентов. Не помещайте эти
метки в измерение «Клиент», так как они могут измениться за очень короткие
промежутки. Если таких статусов много, рассмотрите возможность создать отдельное мини-измерение «Статус клиента», вместо встраивания этой информации в измерение «Сеанс».
Атрибут измерения «Сеанс»
Ключ сеанса
Тип сеанса
Локальный контекст
Контекст сеанса
Последовательность действий
Статус успеха
Статус клиента
Пример данных/определение
Суррогатные значения (1..N)
Классифицируется, Не классифицируется, Данные повреждены,
Неприменимо
Контекст, вытекающий из страницы, например «Запрос
информации о продукте»
Контекст, основанный на траектории, такой как заказ продукта
Общая метка для общей последовательности действий,
выполненных во время сеанса
Определяет, была ли выполнена общая цель сеанса
Новый клиент, Ценный клиент, Собирается уйти, В категории
«по умолчанию»
Рис. 15-3. Параметры сеанса и значения выборочных данных
Это измерение группирует сеансы для анализа, например:
■ Сколько клиентов ознакомились с информацией о вашем продукте перед
заказом?
■ Сколько клиентов просмотрели информацию о вашем продукте и так
и не сделали заказ?
■ Сколько клиентов не завершили заказ? Где они остановились?
Измерение «Направление»
Измерение «Направление», показанное на рис. 15-4, описывает, как клиент
попал на текущую страницу. Журналы веб-сервера обычно содержат эту информацию. Идентифицируется URL-адрес предыдущей страницы, а в некоторых
случаях присутствует дополнительная информация. Если реферером была поисковая система, обычно указывается строка поиска. Возможно, не стоит помещать необработанную спецификацию поиска в вашу базу данных, поскольку
спецификации поиска настолько сложны и специфичны, что аналитик может
оказаться не в состоянии с пользой запросить их. Вы можете предположить,
что в атрибуте спецификации помещена какая-то упрощенная и очищенная
спецификация.
446
Глава 15
Атрибут измерения «Направление» Пример данных/определение
Реферальный ключ
Суррогатные значения (1..N)
Тип реферальной ссылки
Внутренний сайт, Внешний сайт, Поисковик, Данные
повреждены, Неприменимо
URL реферальной ссылки
www.organization-site.com/linkspage
Сайт, с которого был переход
www.organization-site.com
Домен, с которого был переход
Тип поиска
Спецификация
Цель
www.organization-site.com
Простое соответствие текста, Сложная логическая математика
Реально использованная спецификация (полезно, если текст,
иначе использование спорно)
Метатеги, текст тела страницы, заголовок (где поисковик
нашел совпадение)
Рис. 15-4. Атрибуты измерения «Направление» и значения выбранных данных
Таблица фактов сеанса потока кликов
Теперь, когда у вас есть набор полезных измерений потока кликов, вы можете
создавать основные модели измерений потока кликов на основе данных журнала
веб-сервера. Затем этот бизнес-процесс может быть интегрирован в семейство
других предметных областей интернет-торговли.
Стремясь не допустить астрономического роста первой таблицы фактов,
вам следует выбрать размер зернистости в одну строку для каждого завершенного сеанса работы с клиентами. Эта зернистость значительно выше, чем
в журналах базового веб-сервера, которые регистрируют каждое событие отдельной страницы, включая как сами страницы, так и каждый графический
элемент на каждой странице, а также каждый графический элемент на каждой
странице. Хотя мы обычно рекомендуем разработчикам начинать с наиболее
детализированных данных, доступных в исходной системе, это целенаправленное отклонение от наших стандартных практик. Возможно, у вас большой сайт,
регистрирующий более 100 миллионов выборок страниц в день и 1 миллиард
событий микространицы (графических элементов), но вы хотите начать с более
управляемого количества строк, загружаемых каждый день. Ради аргумента мы
предполагаем, что 100 миллионов просмотров страниц сводятся к 20 миллионам полных сеансов посетителей. Это может возникнуть, если средний сеанс
посетителя коснется 5 страниц.
Измерения, подходящие для этой первой таблицы фактов, включают календарную дату, время суток, клиента, страницу, сеанс и направление. Наконец, вы
можете добавить набор измеренных фактов для этого сеанса, включая секунды
сеанса, посещенные страницы, размещенные заказы, заказанные единицы и доллары заказа. Завершенный проект показан на рис. 15-5.
Электронная коммерция
447
Таблица фактов потока
кликов в сессии
Измерение «Дата» (2 роли)
Измерение «Страница входа»
Измерение «Направление»
Универсальный ключ даты (FK)
Универсальные дата/время
Локальный ключ даты (FK)
Локальные дата/время
Ключ клиента (FK)
Ключ страницы входа (FK)
Ключ сеанса (FK)
Ключ ссылки (FK)
ID сессии (DD)
Длина сессии в секундах
Посещенные страницы
Размещенные заказы
Количество товара в заказе
Сумма заказа в долларах
Измерение «Клиент»
Измерение «Сеанс»
Рис. 15-5. Дизайн таблицы фактов потока кликов для полных сеансов
В этом дизайне есть ряд интересных аспектов. Вы можете задаться вопросом, почему существуют два соединения измерения календарной даты с таблицей фактов и две метки даты/времени. Это тот случай, когда и календарная дата,
и время суток должны играть две разные роли. Поскольку вы заинтересованы
в точном измерении времени сеансов, вы должны соответствовать двум противоречивым требованиям. Во-первых, вы хотите убедиться, что можете синхронизировать все даты и время сеансов на международном уровне в нескольких часовых
поясах. Возможно, у вас есть другие метки даты и времени с других веб-серверов
или не веб-систем в других местах среды DW/BI. Для достижения точной синхронизации событий между несколькими серверами и процессами необходимо
единообразно записывать все даты и время сеансов в одном часовом поясе, таком
как среднее время по Гринвичу (GMT) или всемирное координированное время
(UTC). Вы должны интерпретировать комбинации даты и времени сеанса как
начало сеанса. Поскольку у вас есть время ожидания сеанса в виде числового факта, вы можете определить, когда сеанс закончился, если это представляет интерес.
Другое требование, которому вы соответствуете при использовании этого
дизайна, — это запись даты и времени сеанса относительно настенных часов
посетителя. Лучший способ представить эту информацию — использовать второй внешний ключ календарной даты и отметку даты/времени. Теоретически
вы могли бы представить часовой пояс клиента в таблице измерения «Клиент», но ограничения для определения правильного времени настенных часов
были бы ужасно сложными. Разница во времени между двумя городами, такими
как Лондон и Сидней, может изменяться на целых два часа в разное время года
448
Глава 15
в зависимости от того, когда эти города переходят на летнее и зимнее время. Это
не входит в обязанности приложения BI для составления отчетов. Хранение этой
информации — обязанность базы данных, поэтому ее можно ограничить простым и прямым способом.
Две таблицы ролевого измерения «Календарная дата» представления в одной базовой таблице. Имена столбцов преобразуются в определении представления, поэтому они немного отличаются, когда отображаются в списках выбора
пользовательского интерфейса инструментов BI. Обратите внимание, что использование представлений делает два экземпляра каждой таблицы семантически независимыми.
Мы смоделировали точный момент времени с полной отметкой даты/времени, а не с измерением времени суток. В отличие от измерения «Календарная
дата», измерение «Время суток» будет содержать мало значимых атрибутов,
если вообще будет содержать их. У вас нет ярлыков для каждого часа, минуты или
секунды. Такое измерение «Время суток» могло бы быть смехотворно большим,
если бы его размер составлял отдельную секунду или миллисекунду. Кроме того,
использование явной отметки даты/времени позволяет проводить прямую арифметику между различными отметками даты/времени для расчета точных временных промежутков между сеансами даже в тех ситуациях, когда сеанс пересекает
границу суток. Вычислять временные промежутки с использованием измерения
«Время суток» было бы неудобно.
Включение измерения «Страница» на рис. 15-5 может показаться удивительным, учитывая, что зернистость дизайна заключается в сеансе клиента. Однако
в данной сессии очень интересна страница входа. Измерение «Страница» в этом
дизайне — это страница, с которой начался сеанс. Другими словами, где клиент
только что сел в ваш автобус? В сочетании с измерением «Направление» у вас
теперь есть интересная возможность анализировать, как и почему клиент зашел
на ваш сайт. Более продуманный дизайн также добавит размер страницы выхода.
У вас может возникнуть соблазн добавить измерение «Причина — следствие» в этот дизайн, но если такое измерение фокусируется на отдельных продуктах, было бы нецелесообразно добавлять его в этот дизайн. Признак того, что
измерение «Причина — следствие» не соответствует этому дизайну, — многозначный характер причинных факторов для полного сеанса. Если вы проводите рекламные кампании или специальные предложения для нескольких продуктов, как вы представляете эту многозначную ситуацию, если сеанс клиента
включает несколько продуктов? Правильное место для измерения «Причина —
следствие», ориентированного на продукт, будет в более детальной таблице,
описанной в следующем примере таблицы фактов. И наоборот, более широкое
Электронная коммерция
449
измерение «Рыночные условия», описывающее условия, влияющие на все продукты, был бы подходящим для детализированной таблицы фактов.
Факт секунд сеанса — это общее количество секунд, которые клиент провел на сайте во время этого сеанса. Будет много случаев, когда вы не сможете сказать, когда клиент ушел. Возможно, клиент ввел новый URL-адрес. Это
не будет обнаружено обычными журналами веб-сервера, но если данные собираются интернет-провайдером, который может видеть каждый клик в разных сеансах, эта конкретная проблема исчезнет. Или, возможно, клиент встал
со стула и не возвращался в течение часа. Или, возможно, клиент просто закрыл браузер, не сделав больше никаких кликов. Во всех этих случаях вашему
программному обеспечению для извлечения необходимо назначить небольшое
и номинальное количество секунд для этого последнего шага сеанса, чтобы анализ не был нереально искажен.
Мы специально разработали эту первую таблицу фактов потока кликов, чтобы сосредоточиться на полных сеансах посетителей, сохраняя при этом размер
под контролем. Следующая схема опускается до минимальной практической
зернистости, которую вы можете поддерживать в хранилище данных: событие
отдельной страницы.
Таблица фактов события страницы потока кликов
Детализация второй таблицы фактов потока кликов — это событие отдельной
страницы в каждом сеансе клиента; основные микрособытия, записывающие
графические элементы, такие как JPG и GIF, отбрасываются, если вы не являетесь
Yahoo! или eBay, как описано ранее. С помощью простых статических HTMLстраниц вы можете записывать только одно интересное событие на просмотр
страницы — собственно просмотр. Поскольку сайты используют динамически
создаваемые страницы на основе XML с возможностью установления постоянного диалога через страницу, количество и тип событий будут расти.
Эта таблица фактов может достичь астрономических величин. Вы должны
сопротивляться желанию агрегировать таблицу до более грубой детализации,
потому что это неизбежно влечет за собой уменьшение размерности. На самом
деле первая таблица фактов потока кликов представляет собой именно такую
совокупность; хотя это полезная таблица фактов, аналитики не могут задавать
вопросы о поведении посетителей или отдельных страницах.
Выбрав зернистость, вы можете выбрать соответствующие измерения. Список измерений включает календарную дату, время суток, клиента, страницу, событие, сеанс, идентификатор сеанса, шаг (три роли), продукт, направление и продвижение. Завершенный проект показан на рис. 15-6.
450
Глава 15
Таблица фактов события
поток кликов на странице
Измерение «Дата» (2 роли)
Измерение «Страница»
Измерение «Сеанс»
Измерение «Продукт»
Ключ продукта (PK)
Атрибуты продукта …
Измерение «Промоакция»
Универсальный ключ даты (FK)
Универсальные дата/время
Локальный ключ даты (FK)
Локальные дата/время
Ключ клиента (FK)
Ключ страницы (FK)
Ключ события (FK)
Ключ сеанса (FK)
ID сеанса (DD)
Ключ шага сеанса (FK)
Ключ шага покупки (FK)
Ключ шага, на котором работа
завершена (FK)
Ключ продукта (FK)
Ключ направления (FK)
Ключ промоакции (FK)
Секунд проведено на странице
Количество товара в заказе
Сумма заказа в долларах
Измерение «Клиент»
Измерение «Событие»
Измерение «Направление»
Ключ шага (PK)
Количество шагов
Шагов до конца
Измерение «Шаг» (3 роли)
Рис. 15-6. Дизайн таблицы фактов потока кликов для использования
на отдельных страницах
Рис. 15-6 выглядит аналогично первому дизайну, за исключением добавленных измерений «Страница», «Событие», «Промоакция» и «Шаг». Это
сходство между таблицами фактов типично для размерных моделей. Одной
из прелестей размерного моделирования — «скучное» сходство конструкций.
Но именно там они черпают свою силу. Когда у проектов предсказуемая структура, все программное обеспечение вверх и вниз по цепочке DW/BI от извлечения
до запроса к базе данных и инструментов BI может использовать это сходство
с большой пользой.
Две роли, которые играют календарная дата и метки даты/времени, имеют
ту же интерпретацию, что и в первом дизайне. Одна роль — универсальное синхронизированное время, а другая роль — местное время настенных часов, измеренное заказчиком. В этой таблице фактов эти даты и время относятся к отдельному событию страницы.
Измерение «Страница» относится к отдельной странице. Это основное различие в зернистости между двумя таблицами фактов потока кликов. В этой таблице фактов вы можете увидеть все страницы, к которым обращались клиенты.
Как описано ранее, измерение «Сеанс» описывает результат сеанса. Сопутствующий столбец «Идентификатор сеанса» — вырожденное измерение, у которого нет соединения с таблицей измерений. Это вырожденное
Электронная коммерция
451
измерение — типичная конструкция размерного моделирования. Идентификатор
сеанса — это просто уникальный идентификатор без семантического содержимого,
который служит для однозначной группировки событий страницы каждого сеанса
клиента. Вам не нужно было вырожденное такое измерение в первой таблице фактов, но его лучше включить в качестве родительского ключа, если вы хотите легко
связать таблицу фактов событий отдельной страницы. Наша рекомендация — более высокий уровень детализации для измерения «Сеанс», чем для измерения
«Идентификатор сеанса»; измерение «Сеанс» предназначено для описания
классов и категорий сеансов, а не характеристик каждого отдельного сеанса.
Измерение «Продукт» показано в этом дизайне в предположении, что сайт
принадлежит интернет-магазину. Сайт финансовых услуг, вероятно, имел бы аналогичное измерение. Сайт консультационных услуг будет иметь измерение «Услуга».
Сайт аукциона будет иметь измерение «Тематика» и «Категория», описывающее
характер выставляемых на аукцион предметов. Новостной сайт будет иметь измерение «Тематика», хотя и с другим содержанием, чем сайт аукциона.
Вы должны сопровождать измерение «Продукт» измерением «Промоакция», чтобы можно было применить полезные причинно-следственные интерпретации к изменениям спроса, наблюдаемым на определенные продукты.
Для каждого события страницы вы должны записать количество секунд,
прошедших до следующего события страницы. Назовите это «Секундами страницы», чтобы отличать от «Секунда сеанса» в первой таблице фактов. Это
простой пример, где надо обращать внимание на согласованные факты. Если вы
назовете обе эти меры просто «секундами», вы рискуете, что эти секунды будут
неправильно сложены или объединены. Поскольку эти секунды не совсем эквивалентны, вы должны назвать их по-другому в качестве предупреждения ошибки.
В этом конкретном случае вы ожидаете, что «Секунды страницы» для сеанса
в этой второй таблице фактов в сумме будут равны «Секундам сеанса» в первой
таблице фактов.
Остальные факты — это количество товара в заказе и сумма заказа в долларах.
Эти столбцы будут равны нулю или null для многих строк в этой таблице фактов,
если конкретное событие страницы не является событием, в котором размещается заказ. Тем не менее предоставление этих столбцов очень привлекательно,
поскольку они напрямую связывают доход от сайтов с поведением посетителей
сайта. Если бы заказанные единицы и сумма заказа в долларах были доступны
только через систему ввода производственных заказов в другом месте в среде
DW/BI, было бы неэффективно анализировать зависимость выручки от поведения в нескольких больших таблицах. Во многих системах управления базами
данных эти null факты обрабатываются эффективно и могут занимать буквально
нулевое место в таблице фактов.
452
Глава 15
Измерение «Шаг»
Поскольку зернистость таблицы фактов — событие отдельной страницы, вы
можете добавить измерение «Шаг», описанное в главе 8. Измерение «Шаг»,
первоначально показанное на рис. 8-11, ответственно за определение порядка
следования события конкретной страницы в общем сеансе.
Измерение «Шаг» становится особенно полезным, когда оно присоединено
к таблице фактов в различных ролях. На рис. 15-6 показаны три роли: общая
сессия, подсессия покупки и подсессия отказа. Подсессия покупки по определению заканчивается успешной покупкой. Подсессия отказа — это та, в которой
по какой-либо причине не удается завершить транзакцию покупки. Использование этих ролей измерения «Шаг» позволяет выполнять некоторые очень интересные запросы. Например, если измерение «Шаг» покупки ограничено шагом
номер 1, запрос не возвращает ничего, кроме начальной страницы для успешных
покупок. И наоборот, если измерение «Шаг» отказа ограничено оставшимися
нулевыми шагами, запрос не возвращает ничего, кроме последних и, предположительно, наиболее неудовлетворительных страниц, посещенных в сеансах неудачной покупки. Хотя вся конструкция, показанная на рис. 15-6, предназначена
для закупок продуктов, метод использования измерения «Шаг» может быть использован при анализе любого последовательного процесса.
Агрегированные таблицы фактов потока кликов
Обе таблицы фактов потока кликов, разработанные до сих пор, довольно велики.
Существует множество бизнес-вопросов, которые были бы вынуждены суммировать миллионы строк из этих таблиц. Например, если вы хотите отслеживать
общее количество посещений и доходы от основных демографических групп
клиентов, посещающих ваш сайт ежемесячно, вы, безусловно, можете сделать
это с помощью любой таблицы фактов. В таблице фактов с разбивкой по сеансам
вы бы ограничили измерение «Календарная дата» соответствующим промежутком времени (скажем, январь, февраль и март текущего года). Затем вы создадите
заголовки строк из атрибута «Тип демографии» в измерении «Клиент» и атрибута «Месяц» в измерении «Календарь» (чтобы отдельно пометить три месяца
в выходных данных). Наконец, вы бы суммировали суммы за заказ в долларах
и подсчитали количество сеансов. Все это прекрасно работает. Но это, скорее
всего, будет медленно без помощи агрегированной таблицы. Если такого рода
запросы частые, администратору базы данных будет предложено создать агрегированную таблицу, как показано на рис. 15-7.
Вы можете создать эту таблицу непосредственно из вашей первой таблицы фактов, ее зернистость — индивидуальный сеанс. Чтобы создать эту агрегированную
Электронная коммерция
453
таблицу, вы группируете по месяцам, демографическому типу, странице входа
и результатам сеанса. Вы подсчитываете количество сеансов и суммируете все
остальные дополнительные факты. Это приводит к значительно меньшей таблице фактов, почти наверняка менее 1% от исходной таблицы фактов с зернистостью сеанса. Это уменьшение размера напрямую приводит к соответствующему
увеличению производительности для большинства запросов. Другими словами,
вы можете ожидать, что запросы, направленные в эту агрегированную таблицу,
будут выполняться как минимум в 100 раз быстрее.
Агрегированная таблица
фактов сеанса
Измерение «Месяц»
Измерение «Страница входа»
Универсальный ключ месяца (FK)
Демографический ключ (FK)
Ключ страницы входа (FK)
Ключ исхода сеанса (FK)
Количество сеансов
Длина сеанса в секундах
Посещенные страницы
Размещенные заказы
Количество товара в заказе
Сумма заказа в долларах
Измерение «Демография»
Измерение «Исход сеанса»
Рис. 15-7. Агрегированная таблица фактов для потока кликов
Хотя это, возможно, и не было очевидно, мы тщательно следовали дисциплине
при составлении агрегированной таблицы. Она связана с набором сокращенных
сводных измерений, непосредственно относящихся к исходным измерениям в более подробных таблицах фактов. Измерение месяца — это соответствующее подмножество атрибутов измерения календарного дня. Демографический аспект — это
согласованное подмножество атрибутов измерения клиента. Вы должны предположить, что таблицы страниц и сеансов не изменились; тщательная разработка логики
агрегирования также может привести к соответствующему сокращению этих таблиц.
Google Analytics
Google Analytics (GA) — это сервис, предоставляемый Google. Лучше всего описать его как внешнее хранилище данных, предоставляющее множество сведений
о том, как используется ваш сайт. Чтобы использовать GA, вы изменяете каждую
страницу своего сайта, чтобы включить код отслеживания GA (GATC), встроенный во фрагмент кода Java, — он расположен в HTML-разделе <head> каждой
отслеживаемой страницы. Когда посетитель заходит на страницу, информация
отправляется в службу аналитики Google, если у посетителя включен JavaScript.
Практически вся информация, описанная в этой главе, может быть собрана через
454
Глава 15
GA, за исключением информации, позволяющей идентифицировать личность
(PII), которая запрещена условиями предоставления услуг GA. GA можно комбинировать с сервисом Google AdWords для отслеживания рекламных кампаний
и конверсий (продаж). Как сообщается, GA используется более чем 50% самых
популярных сайтов в интернете.
Данные из GA можно просматривать на панели инструментов BI в режиме
онлайн непосредственно из баз данных GA, или данные могут быть предоставлены вам в виде широкого спектра стандартных и пользовательских отчетов, что
позволяет создать собственную локальную схему бизнес-процессов, связанную
с этими данными.
Интересно, что подробное техническое объяснение элементов данных GA,
которые могут быть собраны с помощью сервиса, правильно описано либо как
измерения, либо как факты. Кто-то в Google читал наши книги…
Интеграция потока кликов
в матрицу шин интернет-магазина
В этом разделе рассматриваются бизнес-процессы, необходимые интернетмагазину компьютерной техники. Матрица шины корпоративного хранилища
данных розничной торговли показана на рис. 15-8. Обратите внимание, что
в матрице перечислены предметные области бизнес-процессов, а не отдельные
таблицы фактов. Как правило, каждая строка матрицы приводит к набору тесно
связанных таблиц фактов и/или кубов OLAP, которые представляют определенный бизнес-процесс.
Матрица на рис. 15-8 обладает рядом поразительных характеристик. Там много
галочек. Некоторые измерения, такие как дата/время, организация и сотрудник,
присутствуют почти в каждом бизнес-процессе. Измерения «Продукт» и «Клиент» доминируют в средней части матрицы, где они связаны с бизнес-процессами,
описывающими деятельность, ориентированную на клиента. В верхней части матрицы поставщики и комплектующие доминируют в процессах приобретения деталей, составляющих продукцию, и изготовления их на заказ для заказчика. В нижней части матрицы у вас есть классическая инфраструктура и бизнес-процессы,
определяющие затраты, которые напрямую не связаны с поведением клиентов.
Предметная область потока кликов веб-посетителя находится прямо среди
процессов, ориентированных на клиента. Она совместно с несколькими другими
бизнес-процессами поблизости использует такие общие измерения, как «Дата/
время», «Продукт», «Клиент», «Медиа», «Причина — следствие» и «Правила обслуживания». В этом смысле должно быть очевидно, что данные о потоке кликов веб-посетителей хорошо интегрированы в структуру общей системы
Электронная коммерция
455
X
X
Запасы деталей
X
X
X
X
Спецификация материалов
для сборки изделия
X
X
X
X
X
Спецификация материалов
для заказа
X
X
X
X
X
X
X
и вре
Дата
оакц
ии
Поли
т
и
обслу
к
жива а
ния
Внутр
е
орган нняя
изаци
я
Сотру
дник
Отсле
ж
по са ивание д
йту (4
в
измерижения
ения)
X
X
Пром
X
Доставки от поставщика
Поку
пател
ь
Меди
а
Прои
зводи
тель
Поста
вщик
Обор
удова
ние
Товар
Заказы на закупку и поставщика X
мя
Детал
ь
DW/BI для этого ретейлера. Приложения, привязывающие поток кликов вебпосетителя, будет легко интегрировать во все процессы, совместно использующие эти согласованные измерения, поскольку отдельные запросы к каждой таблице фактов могут быть объединены в отдельных строках отчета.
Управление цепочкой поставки
X
X
X
X
X
X
X
X
X
X
X
Управление клиентскими отношениями
Продвижение товаров
X
X
Реклама
X
X
Коммуникация с клиентами
X
X
X
Запросы клиентов
X
X
X
Посещение веб-сайта
X
X
X
Заказы товаров
X
X
X
X
Политика обслуживания
X
X
X
X
X
X
X
Доставка товаров
X
X
X
X
X
X
Выставление счетов клиентам
X
X
X
X
X
Оплата
X
X
X
Возврат товара
X
X
X
X
X
X
X
Поддержка клиентов
X
X
X
X
X
X
X
Ответы по политике
обслуживания
X
X
X
X
X
X
X
Обязанности сотрудников
X
X
X
X
Подбор персонала
X
X
X
X
Эксплуатация оборудования
X
X
X
X
Операции на веб-сайте
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Операции
Рис. 15-8. Матрица шины для интернет-магазина
456
Глава 15
Бизнес-процесс потока кликов веб-посетителя содержит четыре специальных
измерения потока кликов, которых нет в других. Эти измерения не представляют проблемы для приложений. Вместо этого способность соединять данные
и поток кликов веб-посетителей с обычным миром — это именно то преимущество, которого вы добиваетесь. Вы можете ограничить и сгруппировать атрибуты из четырех веб-измерений и изучить влияние на другие бизнес-процессы.
Например, вы можете увидеть, какие веб-сервисы предоставляют клиентов, которые приобретают определенные виды уровней обслуживания, а затем предъявляют определенные требования к услугам.
Наконец, следует отметить, что матрица служит своего рода средством коммуникации для всех бизнес-команд и высшего руководства, чтобы оценить необходимость согласованных измерениий и фактов. Этот столбец в матрице — фактически список приглашений на собрание для соответствия измерению!
Прибыльность по всем каналам, включая веб
После того как команда DW/BI успешно внедрит начальные таблицы фактов
потока кликов и свяжет их с бизнес-процессами транзакций продаж и общения
с клиентами, команда может быть готова заняться самой сложной предметной
областью из всех: прибыльностью в интернете.
Вы можете представить это как расширение сделок купли-продажи. По сути,
вы распределяете все расходы на деятельность и инфраструктуру по каждой
сделке продажи. В качестве альтернативы вы могли бы попытаться вычислять
веб-доходность на основе потока кликов, но это повлекло бы за собой еще более
спорный процесс распределения, при котором вы распределяете затраты на каждую сессию. Было бы трудно отнести затраты на деятельность и инфраструктуру
к сеансу, который не имеет очевидного участия в продукте и не приводит к немедленной продаже.
Большое преимущество расширения таблицы фактов транзакций по продажам заключается в том, что вы получаете представление о прибыльности по всем
вашим каналам продаж, а не только в интернете. В некотором смысле это должно
быть очевидно, потому что вы знаете, что должны рассортировать затраты и распределить их по различным каналам.
Зернистость таблицы фактов прибыли и убытков — каждая отдельная позиция, проданная клиенту в ходе продажи в определенный момент времени,
будь то одна продажа или один сеанс покупки онлайн. Это то же самое, что
и зернистость бизнес-процесса сделок купли-продажи, и включает в себя все
каналы, а именно продажи в магазинах, продажи по телефону и продажи через
интернет.
Электронная коммерция
457
Измерения фактов о прибылях и убытках также совпадают с таблицей фактов
транзакции продажи: дата, время, клиент, канал, продукт, акция и номер продажи (вырожденное измерение). Большая разница между таблицами прибыльности и таблицами фактов сделок купли-продажи заключается в разбивке затрат,
как показано на рис. 15-9.
Таблица фактов прибыльности
Измерение «Дата» (2 роли)
Измерение «Клиент»
Измерение «Товар»
Универсальный ключ даты (FK)
Универсальный ключ времени дня (FK)
Локальный ключ даты (FK)
Локальный ключ времени дня (FK)
Ключ клиента (FK)
Ключ канала (FK)
Ключ продукта (FK)
Ключ промоакции (FK)
Номер продажи (DD)
Количество проданного товара
Валовая выручка
Отклонение цены при производстве
Маркетинговое продвижение
Уценка при продаже
Чистая выручка
Стоимость производства
Стоимость хранения
Валовая прибыль
Транспортные расходы
Специальная цена сделки
Другие расходы
Чистая прибыль
Измерение времени дня (2 роли)
Измерение «Канал продаж»
Измерение «Промоакция»
Рис. 15-9. Факты о прибылях и убытках по всем каналам продаж, включая
продажи через интернет
Прежде чем обсуждать распределение затрат, давайте рассмотрим формат
данных о прибылях и убытках. Он организован в виде простого отчета о прибылях и убытках (P&L) (см. рис. 6-14). Первый факт — это уже знакомые нам
«проданные единицы товара». Все остальные факты — это значения в долларах,
начиная со стоимости продажи, как если бы она была продана по цене из каталога, называемой валовой выручкой. Предполагая, что продажи часто осуществляются по более низким ценам, вы должны учитывать любую разницу с учетом
надбавки производителя, маркетинговой акции (снижения цены) или уценки,
сделанной для перемещения запасов. Когда эти эффекты принимаются во внимание, вы можете рассчитать чистую прибыль, которая представляет собой действительную чистую цену, которую платит клиент, умноженную на количество
приобретенных единиц.
458
Глава 15
Остальная часть P&L состоит из серии вычитаний, в ходе которых вы рассчитываете все более отдаленные варианты прибыли. Вы можете начать с вычитания
стоимости изготовления продукта, если вы его производите, или, что эквивалентно, стоимости приобретения продукта, если он приобретен у поставщика.
Затем вычтите стоимость хранения продукта. На данный момент многие предприятия называют этот частичный результат «валовой прибылью». Вы можете
разделить эту валовую прибыль на валовой доход, чтобы получить коэффициент
валовой прибыли.
Очевидно, что столбцы, называемые чистой выручкой и валовой прибылью,
рассчитываются непосредственно из столбцов, предшествующих им в таблице фактов. Но следует ли вам явно хранить эти столбцы в базе данных? Ответ зависит от того, предоставляете ли вы доступ к этой таблице фактов через
представление или пользователи (либо приложения BI) напрямую обращаются к физической таблице фактов. Структура P&L достаточно сложна, поэтому, как поставщик хранилища данных, вы не хотите рисковать тем, что такие
важные показатели, как чистая выручка и валовая прибыль, будут рассчитаны
неправильно. Если вы предоставляете весь доступ через представления, вы можете легко предоставить вычисленные столбцы без их физического хранения.
Но если вашим пользователям разрешен доступ к базовой физической таблице,
вы должны включить чистый доход, валовую прибыль и чистую прибыль в качестве физических столбцов.
Ниже валовой прибыли вы можете продолжить вычитание различных затрат.
Как правило, команда DW/BI должна отдельно определить источник или оценить каждую из этих затрат. Помните, что фактические записи в любой заданной
строке таблицы фактов представляют собой доли этих общих затрат, распределенных вплоть до отдельных строк фактов. Часто на команду DW/BI оказывается
значительное давление по реализации компонентов хранилища данных, предоставляющих данные по бизнес-процессу «Прибыльность». Или, другими словами, существует огромная необходимость определить источники всех этих затрат.
Но насколько хороши и полезны данные о затратах в различных базовых наборах
данных? Иногда затраты доступны только в виде среднего показателя по стране, рассчитанного за целый год. Любая схема распределения будет присваивать
своего рода формальное значение, которое не имеет реальной структуры. Другие расходы будут разбиты немного более детально, возможно, по календарному
кварталу и географическому региону (если это уместно). Наконец, некоторые затраты могут быть действительно основаны на деятельности и изменяться очень
динамично, быстро и реалистично с течением времени.
Затраты на разработку веб-сайта — важный фактор затрат в бизнесе электронной коммерции. Хотя затраты на сайт — это классические затраты
Электронная коммерция
459
на инфраструктуру, и поэтому их трудно распределить непосредственно на продукт и деятельность клиентов, это ключевой шаг в разработке веб-ориентированного отчета о прибылях и убытках. Возможны различные схемы распределения,
в том числе распределение затрат на веб-сайт по различным линейкам продуктов
по количеству страниц, посвященных каждому продукту, распределение затрат
по посещенным страницам или распределение затрат по фактическим покупкам
онлайн.
Команда DW/BI не может отвечать за внедрение калькуляции затрат на основе деятельности (ABC) в крупной организации. Когда команда строит размерную модель прибыльности, то получает наилучшие данные о затратах, доступные на данный момент, и публикует P&L. Возможно, некоторые из этих чисел
являются простыми эмпирическими соотношениями. Другие могут быть очень
подробными затратами, основанными на деятельности. Со временем, по мере
увеличения источников затрат, команда DW/BI включает эти новые источники
и уведомляет пользователей об улучшении бизнес-правил.
Прежде чем оставить этот дизайн, стоит рассмотреть его в перспективе. Когда
P&L встроена в богатую размерную структуру, вы обладаете огромной властью.
Вы можете разбить все компоненты выручки, затрат и прибыли на все мыслимые
выборки и срезы, предоставляемые измерениями. Вы можете не только сказать,
что прибыльно, но также ответить «почему», так как вы можете видеть все компоненты P&L, в том числе:
■ Насколько прибылен каждый канал (продажи через интернет, продажи
по телефону и продажи в магазинах)? Почему?
■ Насколько прибыльны ваши клиентские сегменты? Почему?
■ Насколько прибыльна каждая линейка ваших продуктов? Почему?
■ Насколько прибыльны ваши промоакции? Почему?
■ Когда ваш бизнес наиболее прибылен? Почему?
Симметричный размерный подход позволяет комбинировать ограничения
из многих измерений, позволяя выполнять сложные версии анализа прибыльности:
■ Кто получает прибыль в каждом канале? Почему?
■ Какие промоакции хорошо работают в интернете, но плохо работают
в других каналах? Почему?
460
Глава 15
Выводы
Тематическое исследование интернет-магазина, используемое в этой главе, иллюстрирует любой бизнес со значительным присутствием в интернете. Помимо
описания предметной области потока кликов на нескольких уровнях зернистости, главная задача — эффективная интеграция данных потока кликов в остальную часть бизнеса. Мы обсудили способы решения проблем идентификации, связанных с посетителями сайта, их происхождением и границами сеанса, а также
специальными измерениями, уникальными для данных потока кликов, включая
измерения «Сеанс», «Страница», «Шаг».
В следующей главе мы обратим наше внимание на основные бизнес-процессы
в страховой компании, подытоживая различные паттерны измерений, представленные в этой книге.
16
В
Страхование
этом заключительном тематическом исследовании мы объединили концепции почти всех предыдущих глав, применяемые при создании системы
DW/BI для компании по страхованию имущества и несчастных случаев. Если
вы из страховой отрасли и сразу перешли к этой главе, чтобы быстро исправить
ситуацию, пожалуйста, примите наши извинения, но этот материал в значительной степени зависит от идей из предыдущих глав. Вам нужно будет вернуться
к началу книги, чтобы эта глава имела хоть какой-то смысл.
В соответствии с нашей стандартной процедурой эта глава начинается со справочной информации об этой предметной области. В процессе выявления новых
требований мы разработаем матрицу шины корпоративного хранилища данных,
как это было бы в реальной жизни. Затем мы разработаем серию размерных моделей, применяя основные методы, изученные до сих пор.
В главе 16 рассматриваются следующие концепции:
■ основанный на требованиях подход к размерному проектированию;
■ последствия для цепочки создания стоимости, а также пример фрагмента
матрицы шины для страховой компании;
■ дополнительные схемы транзакций, периодических моментальных снимков и накопительных моментальных снимков;
■ ролевые измерения;
■ обработка медленно изменяющихся атрибутов измерений;
■ мини-измерения для работы с большими, быстро меняющимися атрибутами измерений;
■ многозначные атрибуты измерений;
■ вырожденные измерения для операционных контрольных чисел;
■ измерение «Аудит» для отслеживания происхождения данных;
■ разнородные супертипы и подтипы для обработки продуктов с различными атрибутами и фактами;
■ мусорные измерения для хранения разнообразных индикаторов;
462
Глава 16
■ согласованные измерения и факты;
■ консолидированные таблицы фактов, объединяющие показатели из от-
дельных бизнес-процессов;
■ таблицы фактов без фактов;
■ типичные ошибки, которых следует избегать при проектировании размерных моделей.
Изучение предметной области «Страхование»
Представьте, что вы работаете на крупного страховщика имущества и несчастных
случаев, который предлагает страхование автомобилей, домовладельцев и личного имущества. Вы проводите обширные собеседования с представителями бизнеса и высшим руководством из отделов претензий, полевых операций, составления страховых полисов, финансов и маркетинга. Основываясь на этих интервью,
вы узнаете, что отрасль находится в состоянии постоянного изменения. Нетрадиционные игроки используют альтернативные каналы. Тем временем отрасль
консолидируется из-за проблем глобализации, дерегулирования и разъединения.
Рынки меняются вместе с потребностями клиентов. Многочисленные опрошенные говорят нам, что информация становится еще более важным стратегическим
активом. Независимо от функциональной области существует сильное желание
более эффективно использовать информацию для более быстрого выявления возможностей и наиболее адекватного реагирования.
Хорошая новость: внутренние системы и процессы уже собирают основную
часть требуемых данных. Большинство страховых компаний генерируют тонны
подробных оперативных данных. Плохая новость заключается в том, что данные
не интегрированы. На протяжении многих лет политические и информационные
границы способствовали возведению высоких барьеров вокруг изолированных
островков данных. Существует множество разрозненных источников информации о продуктах компании, клиентах и каналах распространения. В устаревших
операционных системах один и тот же страхователь может быть идентифицирован несколько раз в отдельных приложениях для автомобилей, домов и личного
имущества. Традиционно такой сегментированный подход к данным был приемлемым, поскольку различные направления бизнеса функционировали в основном автономно; в прошлом не было особого интереса к обмену данными для
перекрестных продаж и сотрудничества. Теперь в рамках нашего тематического
исследования руководство бизнеса пытается лучше использовать этот огромный
объем противоречивых и несколько избыточных данных.
Помимо неотъемлемых проблем, связанных с интеграцией данных, бизнес-пользователи не имеют возможности легко получать доступ к данным при
Страхование
463
необходимости. В попытке устранить этот недостаток несколько групп в компании, занимающейся тематическим исследованием, объединили свои ресурсы
и наняли консультантов для решения индивидуальных краткосрочных потребностей в данных. Во многих случаях одни и те же данные были извлечены из одних
и тех же исходных систем для доступа к ним отдельных организаций без какойлибо стратегической общей стратегии предоставления информации.
Не потребовалось много времени, чтобы осознать негативные последствия,
связанные с отдельными хранилищами аналитических данных, поскольку результаты работы, представленные на совещаниях руководителей, различались в зависимости от источника данных. Руководство понимало, что этот путь независимости нежизнеспособен в качестве долгосрочного решения из-за отсутствия
интеграции, больших объемов избыточных данных и трудностей в интерпретации и согласовании результатов. Учитывая важность информации в этом смелом
новом мире страхования, руководство было заинтересовано в том, чтобы разобраться с финансовыми последствиями, связанными с разработкой, поддержкой
и аналитической неэффективностью этих предполагаемых хранилищ данных,
которые просто увеличивали острова оперативных данных.
Высшее руководство назначило главного информационного директора (ИТдиректора) ответственным и уполномоченным по борьбе с хаосом хранения исторических данных для «достижения информационной нирваны». Они возложили
на ИТ-директора административную ответственность за более эффективное управление информационными активами организации и их использование. ИТ-директор разработал общее видение, которое сочетало корпоративную стратегию работы с огромными объемами данных с ответом на насущную необходимость стать
организацией, богатой информацией. Тем временем была создана корпоративная
команда DW/BI, которая приступила к разработке и реализации концепции.
Высшее руководство призывает к переходу на более ориентированный на клиента подход вместо традиционного подхода, ориентированного на продукт, в попытке получить конкурентное преимущество. ИТ-директор вскочил на эту последнюю ступенькую вагона уходящего поезда в качестве катализатора перемен.
Люди в окопах заявили о намерении делиться данными, а не собирать их для
одной цели. Существует сильное желание, чтобы у всех было общее понимание
состояния бизнеса. Они требуют избавиться от изолированных хранилищ данных, обеспечивая при этом доступ к подробным и сводным данным как на уровне предприятия, так и на уровнях конкретных бизнес-направлений.
Цепочка создания стоимости страхования
Основная цепочка создания стоимости страховой компании, на первый взгляд,
коротка и проста. Основной процесс — выдача полисов, сбор страховых взносов
464
Глава 16
и обработка претензий. Организация заинтересована в лучшем понимании показателей, порожденных каждым из этих событий. Пользователи хотят анализировать подробные транзакции, связанные с формулированием страховых полисов, а также транзакции, созданные в результате обработки претензий. Они
хотят измерять производительность с течением времени по охвату, охватываемому товару, страхователю и характеристикам каналов сбыта. Хотя некоторых
пользователей интересует корпоративная перспектива, другие хотят проанализировать неоднородный характер отдельных направлений деятельности страховой компании.
Очевидно, что страховая компания участвует во многих других внешних процессах, таких как инвестирование страховых взносов или комиссии страховых
агентов, а также во множестве внутренних мероприятий, таких как управление
персоналом, финансы и закупки. На данный момент мы сосредоточимся на основном бизнесе, связанном со страховыми полисами и претензиями.
Цепочка создания стоимости страхования начинается с различных операций
по страхованию. Основываясь на вашем текущем понимании требований и базовых данных, вы решаете обрабатывать все транзакции, влияющие на полис,
как единый бизнес-процесс (и таблицу фактов). Если эта перспектива слишком
упрощена для учета требуемых показателей, измерений или аналитики, вам следует обрабатывать операции с транзакциями в виде отдельных таблиц фактов,
таких как квоты, рейтинг и составление полисов. Как обсуждалось в главе 5, существуют компромиссы между созданием отдельных таблиц фактов для каждого
естественного кластера типов транзакций и объединением транзакций в единую
таблицу фактов. Также необходимо более четко представлять себе ежемесячный
доход от премий по каждому полису. Это будет ключевым вкладом в общую картину прибыли.
Страховой бизнес очень интенсивен в транзакциях, но транзакции (сделки)
не являются небольшими составляющими дохода, как при розничных продажах.
Вы не можете просто суммировать транзакции по полису, чтобы определить сумму дохода. В страховании картина еще более усложняется, поскольку клиенты
заранее платят за услуги. Эта же модель авансовых платежей применяется к организациям, предлагающим подписку на журналы или контракты с расширенной
гарантией. Страховые взносы должны быть распределены на несколько периодов: компания получает доход с течением времени, поскольку предоставляет
страховое покрытие.
Сложная взаимосвязь между транзакциями по полису и измерениями доходов часто делает невозможным ответить на вопросы о доходах, просматривая
отдельные транзакции. Такое сканирование не только отнимает много времени:
логика, необходимая для интерпретации влияния различных типов транзакций
Страхование
465
на доход, может быть ужасно сложной. Естественное противоречие между подробным представлением транзакции и перспективой моментального снимка
почти всегда требует создания таблиц фактов обоих типов в хранилище данных.
В этом случае снимок страховых взносов — это не просто краткое изложение
транзакций по полису; это совершенно отдельная вещь, полученная из отдельного источника.
Проект матрицы шины
Сотру
дн
Поли
с
X
X
X
X
X
X
Месяц
X
X
X
X
Агент
X
ик
Покр
ы
X
тие
Объ
покр ект
ытия
Снимок страховых
взносов
Страх
овате
ль
Транзакции по полису
Дата
На основе результатов опроса наряду с пониманием ключевых исходных систем
команда приступает к разработке матрицы шины корпоративного хранилища
данных с основными бизнес-процессами, ориентированными на полис, в виде
строк и основных измерений в виде столбцов. В матрице определены две строки,
одна из которых соответствует транзакциям по полису, а другая — моментальному снимку ежемесячных страховых взносов. Как показано на рис. 16-1, основные
измерения включают дату, страхователя, сотрудника, покрытие, покрываемый
объект и полис. При составлении матрицы не пытайтесь включить все измерения. Вместо этого попробуйте сосредоточиться на основных общих измерениях,
которые повторно используются в нескольких схемах.
Рис. 16-1. Первоначальный проект матрицы шины
Транзакции по страховому полису
Давайте обратим наше внимание на первую строку матрицы, сосредоточившись
на транзакциях для создания и изменения полисов. Предположим, что полис
представляет собой набор страховых покрытий, проданных страхователю. Страховые покрытия можно считать продуктами страховой компании. Страховые
покрытия домовладельцев включают пожар, наводнение, кражу и личную ответственность; автомобильные страховые покрытия включают всесторонний ущерб
от столкновения, незастрахованного автомобилиста и личную ответственность.
466
Глава 16
В компании по страхованию имущества и несчастных случаев страховые покрытия распространяются на конкретный объект страхования, такой как конкретный дом или автомобиль. Как страховое покрытие, так и покрываемый объект
тщательно указаны в политике. Конкретный охватываемый объект обычно имеет
несколько видов покрытия, перечисленных в полисе.
Агенты продают полисы держателям полисов. Прежде чем полис может быть
создан, актуарий по ценообразованию определяет страховой взнос, который
будет взиматься с учетом конкретных видов покрытия, охватываемых объектов
и характеристик страхователя. Страховая компания, которая берет на себя окончательную ответственность за ведение бизнеса со страхователем, дает окончательное одобрение.
Система операционных транзакций по полисам фиксирует следующие типы
транзакций:
■ создать полис, изменить полис или отменить полис (с указанием причины);
■ создать покрытие для охватываемого объекта, изменить покрытие или отменить покрытие (с указанием причины);
■ оценить покрытие или отказаться от оценки покрытия (с указанием причины);
■ выдать полис или отказаться от выдачи полиса (с указанием причины).
Зернистость таблицы фактов транзакции по полису должна состоять из одной строки для каждой отдельной транзакции. Каждая атомарная транзакция
должна быть снабжена как можно большим контекстом, чтобы создать полное
описание транзакции. Измерения, связанные с бизнес-процессом транзакции
по полису, включают дату транзакции, дату вступления в силу, владельца полиса, сотрудника, покрытие, охватываемый объект, номер полиса и тип транзакции
по полису. Теперь давайте подробнее обсудим измерения в этой схеме, пользуясь
возможностью, чтобы подкрепить концепции из предыдущих глав.
Ролевые измерения
С каждой транзакцией по полису связаны две даты. «Дата транзакции полиса» — это момент, когда транзакция была введена в операционную систему, тогда как «Дата вступления в силу» транзакции по полису — это момент, когда
транзакция вступает в силу на законных основаниях. Эти два внешних ключа
в таблице фактов должны иметь уникальные имена. Два независимых измерения,
связанных с этими ключами, реализованы с использованием единой физической
таблицы дат. Затем несколько логически различных таблиц представляются пользователю в виде представлений с уникальными именами столбцов, как первоначально описано в главе 6.
Страхование
467
Медленно меняющиеся измерения
Страховые компании, как правило, очень заинтересованы в отслеживании изменений измерений с течением времени. Вы можете применить три основных
метода для обработки атрибутов медленно изменяющегося измерения (SCD)
к измерению «Страхователь», как описано в главе 5.
С помощью метода типа 1 вы просто перезаписываете предыдущее значение
атрибута измерения. Это самый простой подход к работе с изменениями атрибутов, поскольку атрибуты всегда представляют самые последние дескрипторы.
Например, бизнес соглашается обрабатывать изменения даты рождения страхователя как изменение типа 1 исходя из предположения, что любые изменения
этого атрибута предназначены для исправления. Таким образом, вся история таблицы фактов для этого страхователя оказывается всегда свяанной с обновленной
датой рождения.
Поскольку почтовый индекс страхователя — ключевой элемент для алгоритмов ценообразования и оценки рисков страховщика, пользователи очень заинтересованы в отслеживании изменений почтового индекса, поэтому для этого
атрибута используется метод типа 2. Тип 2 — наиболее распространенный метод SCD, когда требуется точное отслеживание изменений с течением времени. В этом случае при изменении почтового индекса вы создаете новую строку измерения «Страхователь» с новым суррогатным ключом и обновленными
географическими атрибутами. Не возвращайтесь и не просматривайте таблицу
фактов. Строки таблицы исторических фактов, предшествовавшие изменению
почтового индекса, все еще отражают старый суррогатный ключ. В дальнейшем
вы используете новый суррогатный ключ страхователя, поэтому новые строки
таблицы фактов присоединяются к профилю измерения после изменения. Хотя
этот метод чрезвычайно изящен и эффективен, он накладывает большую нагрузку на процессы ETL. Кроме того, количество строк в таблице измерений увеличивается с каждым изменением SCD типа 2. Учитывая, что в вашей таблице
измерения «Страхователь» уже может быть более 1 миллиона строк, вы можете
использовать мини-измерение для отслеживания изменений почтового индекса,
которое мы рассмотрим в ближайшее время.
Наконец, давайте предположим, что каждый страхователь классифицируется
как принадлежащий к определенному сегменту. Возможно, держатели полисов,
не являющиеся резидентами, исторически относились либо к коммерческим,
либо к государственным организациям. В будущем бизнес-пользователи захотят
получить более подробную классификацию, позволяющую проводить различия
между крупными многонациональными компаниями, коммерческими клиентами среднего рынка и малого бизнеса, а также некоммерческими организациями и правительственными учреждениями. В течение определенного периода
468
Глава 16
времени пользователи хотят иметь возможность анализировать результаты либо
по историческим, либо по новым классификациям сегментов. В этом случае вы
могли бы использовать подход типа 3 для отслеживания изменений за определенный период, добавив столбец с пометкой «Исторический» для дифференциации, чтобы сохранить старые классификации. Новые значения классификации будут заполнять атрибут сегмента, который был постоянной структурой
в измерении «Страхователь». Этот подход, хотя и не очень распространенный,
позволяет вам видеть производительность либо по текущим, либо по историческим значениям сегментов. Это полезно, когда произошли массовые изменения,
такие как изменение классификации клиентов. Очевидно, что метод типа 3 становится чрезмерно сложным, если вам нужно отслеживать более одной версии
исторических изменений или изменения до и после для атрибутов нескольких
измерений.
Мини-измерения для больших или быстро меняющихся
атрибутов
Как упоминалось ранее, измерение «Страхователь» квалифицируется как большое измерение с более чем миллионом строк. Часто важно точно отслеживать
значения содержимого для подмножества атрибутов. Например, вам необходимо точное описание некоторых атрибутов страхователя и покрываемых объектов на момент создания полиса, а также на момент любой корректировки или
претензии. Как обсуждалось в главе 5, практический способ отслеживания изменяющихся атрибутов в больших измерениях состоит в том, чтобы разделить
тщательно отслеживаемые, более быстро изменяющиеся атрибуты на одно или
несколько мини-измерений типа 4, напрямую связанных с таблицей фактов с помощью отдельного суррогатного ключа. Использование мини-измерений влияет
на эффективность просмотра атрибутов, поскольку пользователи обычно хотят
просматривать и ограничивать эти изменяемые атрибуты. Если созданы все возможные комбинации значений атрибутов для мини-измерений, обработка изменений мини-измерения просто означает размещение другого ключа в строке
таблицы фактов с определенного момента времени. Больше ничего не нужно
изменять или добавлять в базу данных. Застрахованный предмет — это дом, автомобиль или другой конкретный застрахованный предмет.
Характеристики охватываемого объекта содержит одну строку для каждого
фактического покрываемого объекта. Измерение «Объект покрытия» обычно
несколько больше, чем измерение «Страхователь», поэтому это еще одно хорошее место для рассмотрения вопроса о развертывании мини-измерений. Вы
не хотите записывать переменчивые описания физических объектов в таблицы
фактов, потому что большинство из них текстовые, не являются числовыми или
Страхование
469
непрерывно оцениваемыми. Вы должны приложить все усилия для размещения
текстовых атрибутов в таблицах измерений, поскольку это объект текстовых
ограничений и источник меток отчетов.
Многозначные атрибуты измерений
Мы обсуждали многозначные атрибуты измерения, когда связывали несколько
навыков с сотрудником в главе 9. В главе 10 мы связали нескольких клиентов
с банковским счетом, а затем в главе 14 смоделировали множественные диагнозы
пациента. В этом тематическом исследовании вы рассмотрите другую многозначную ситуацию моделирования: взаимосвязь между коммерческими клиентами
и их отраслевыми классификациями.
Каждый коммерческий клиент может быть связан с одним или несколькими
кодами «Стандартной отраслевой классификации» (SIC) или «Североамериканской системы отраслевой классификации» (NAICS). Крупный диверсифицированный коммерческий клиент может быть представлен дюжиной или более
классификационных кодов. Подобно тому, как это было сделано в главе 14, соединительная таблица объединяет все коды отраслевой классификации внутри
группы. Эта таблица отраслевой классификации соединяется непосредственно
либо с таблицей фактов, либо с измерением «Клиент» в качестве внешнего измерения. Это позволяет вам сообщать о показателях таблицы фактов по любой
отраслевой классификации. Если отраслевая разбивка коммерческого клиента
определена пропорционально, например 50% сельскохозяйственных услуг, 30%
молочных продуктов и 20% бурения нефтяных и газовых скважин, то в каждую
строку соединительной таблицы следует включить весовой коэффициент. Чтобы
обработать случай, когда с данным клиентом не связан допустимый отраслевой
код, вы просто создаете специальную строку соединительной таблицы, которая
содержит «Неизвестное».
Числовые атрибуты как факты или измерения
Давайте перейдем к измерению «Покрытие». Крупные страховые компании
располагают десятками или даже сотнями отдельных продуктов страхового
покрытия, доступных для продажи определенному типу страхуемого объекта.
Фактическая оценочная стоимость конкретного объекта, на который распространяется действие, например, чьего-либо дома, представляет собой постоянно
оцениваемую числовую величину, которая может изменяться для этого предмета с течением времени, поэтому относитесь к ней как к законному факту. В таблице измерений вы можете сохранить более описательный диапазон значений,
например оценочную стоимость от 250 000 до 299 999 долларов США, для
группировки и фильтрации. Базовый лимит покрытия, скорее всего, будет более
470
Глава 16
стандартизированным и не будет постоянно переоцениваться, например «Восстановительная стоимость» или «до 250 000 долларов США». В этом случае он
также будет рассматриваться как атрибут измерения.
Вырожденные измерения
Номер полиса будет обрабатываться как вырожденное измерение, если вы извлекли всю информацию заголовка в другие измерения. Очевидно, что вы хотите избежать создания таблицы фактов транзакций по полису с небольшим
количеством ключей при встраивании всех описательных сведений (включая
владельца полиса, даты и покрытия) в перегруженное измерение «Полис».
В некоторых случаях может быть один или два атрибута, которые все еще принадлежат «Полису», а не другому измерению. Например, если страховщик
устанавливает общую оценку риска для полиса на основе общего покрытия
и пообъектного покрытия, то эта оценка риска, вероятно, относится к измерению «Полис». Конечно, тогда номер полиса больше не вырожденное измерение.
Таблицы измерений с низкой кардинальностью
Измерение «Тип транзакции» представляет собой небольшое измерение для
типов транзакций, перечисленных ранее, с описанием причин. Измерение «Тип
транзакции» может содержать менее 50 строк. Хотя эта таблица узкая с точки
зрения количества столбцов и неглубокая с точки зрения количества строк, атрибуты все равно должны обрабатываться в таблице измерений; если текстовые
характеристики используются для фильтрации запросов или маркировки отчетов, то они принадлежат измерению.
Измерение «Аудит»
У вас есть возможность связать метаданные процесса ETL со строками фактов
транзакции, включив ключ, который ссылается на строку измерения «Аудит»,
созданную процессом извлечения данных. Как обсуждалось в главе 6, каждая
строка измерения аудита описывает происхождение данных строки фактов,
включая время извлечения, исходную таблицу и версию программного обеспечения для извлечения.
Таблица фактов транзакций по полису
Таблица фактов транзакций по полису на рис. 16-2 иллюстрирует несколько характеристик классической таблицы фактов с зернистостью на уровне транзакций. Во-первых, таблица фактов почти полностью состоит из ключей. Схемы
транзакций позволяют анализировать поведение в мельчайших деталях. По мере
Страхование
471
того как вы переходите к более низкой детализации атомарных данных, таблица
фактов естественным образом приобретает большую размерность. В этом случае таблица фактов содержит один числовой факт; интерпретация факта зависит
от соответствующего измерения типа транзакции. Поскольку в одной и той же
таблице фактов существуют разные типы транзакций, в этом сценарии вы не можете обозначить факт более конкретно.
Гетерогенные продукты: супертипы и подтипы
Хотя в нашей страховой компании активно поддерживается корпоративная перспектива, бизнес-пользователи не хотят упускать из виду специфику своего бизнеса. Страховые компании, как правило, занимаются несколькими, очень разными
направлениями бизнеса. Например, подробные параметры покрытий для домовладельцев значительно отличаются от автомобильных покрытий. И то и другое
существенно отличается от страхования личного имущества, страхования общей
ответственности и других видов страхования. Хотя все страховые покрытия могут быть закодированы в общие структуры, используемые до сих пор в этой главе, страховые компании хотят отслеживать множество специфических атрибутов,
которые имеют смысл только для конкретного покрытия и покрываемого объекта. Вы можете обобщить начальную схему, разработанную на рис. 16-2, используя
технику супертипа и подтипа, описанную в главе 10.
Таблица фактов транзакций по политике
Измерение «Дата» (2 роли)
Измерение «Страхователь»
Измерение «Покрытие»
Измерение
«Тип транзакции по полису»
Ключ даты транзакции по полису (FK)
Ключ даты вступления полиса в силу (FK)
Ключ страхователя (FK)
Ключ сотрудника (FK)
Ключ покрытия (FK)
Ключ вступления полиса в силу (FK)
Ключ типа транзакции по полису (FK)
Ключ аудита транзакции по полису (FK)
Номер полиса (DD)
Номер транзакции по полису (DD)
Сумма транзакции по полису в долларах
Измерение «Сотрудник»
Измерение
«Объект покрытия»
Измерение
«Аудит транзакций по полису»
Рис. 16-2. Схема транзакций по полисам
На рис. 16-3 показана схема для обработки конкретных атрибутов, описывающих автомобили и их покрытия. Для каждого направления деятельности (или
типа покрытия) создаются таблицы измерений подтипов как для покрываемого
объекта, так и для связанного покрытия. Когда приложению BI требуются определенные атрибуты одного типа покрытия, оно использует соответствующие таблицы измерений подтипов.
472
Глава 16
Таблица фактов транзакций по полису
Измерение
«Покрытие автомобиля»
Ключ покрытия (PK)
Описания покрытия
Описание направления
бизнеса
Лимит
Франшиза
Покрытие арендованных
автомобилей
Покрытие лобового стекла
Ключ даты транзакции по полису (FK)
Ключ даты вступления полиса в силу (FK)
Ключ страхователя (FK)
Ключ сотрудника (FK)
Ключ покрытия (FK)
Ключ предмета иска (FK)
Ключ типа транзакции по полису (FK)
Ключ аудита транзакции по полису (FK)
Номер полиса (DD)
Сумма транзакции по политике в долларах
Измерение «Автомобиль
как объект покрытия»
Ключ объекта покрытия (PK)
Описание объекта покрытия
Производитель ТС
Марка ТС
Год выпуска ТС
Класс ТС
Объем двигателя
Оценочная стоимость ТС
Рис. 16-3. Схема транзакций по полису с таблицами измерения для подтипа
«Автомобильное страхование»
Обратите внимание на эту схему: вам не нужны отдельные таблицы фактов
для каждого направления бизнеса, поскольку показатели не зависят от направления бизнеса, но вы, скорее всего, создадите представление на базе таблицы фактов супертипа, чтобы представить только строки для данного подтипа. Таблицы
измерений подтипов вводятся для обработки специальных бизнес-атрибутов.
Никаких новых ключей генерировать не нужно; логически все, что мы делаем, —
это расширяем существующие строки измерений.
Дополнительная стратегия, накапливающая
моментальный снимок
Наконец, прежде чем покинуть транзакции по полисам, вам следует рассмотреть
возможность использовать накопительный моментальный снимок для учета совокупного эффекта транзакций. В этом сценарии зернистостью таблицы фактов,
скорее всего, будет одна строка для каждого покрытия и покрываемого полисом
объекта. Вы можете предусмотреть включение дат, ориентированных на полис,
таких как «Квотированные», «Оцененные», «Подписанные», «Вступившие
в силу», «Обновленные» и «Истекшие». Аналогичным образом в таблицу
фактов для агента и страховщика можно включить несколько ролей сотрудников. Многие из других обсуждаемых измерений будут применимы к этой схеме,
за исключением измерения «Тип транзакции». Накопительный снимок, скорее
всего, будет содержать расширенный набор фактов.
Как обсуждалось в главе 4, накопительный моментальный снимок эффективен для представления информации о ключевых этапах конвейерного процесса.
Он фиксирует совокупный срок действия полиса, общее покрытие и покрываемые объекты; однако он не хранит информацию о каждой произошедшей
Страхование
473
транзакции. Необычные транзакционные события или неожиданные отклонения от стандартного конвейера, скорее всего, будут замаскированы с точки зрения накопления. С другой стороны, накопительный моментальный снимок, полученный из транзакций, дает четкое представление о продолжительности или
времени задержки между ключевыми событиями процесса.
Премиальный периодический
снимок страховых взносов
Схема транзакций по полису полезна для ответов на широкий круг вопросов. Однако поток транзакций затрудняет быстрое определение статуса или финансовой
ценности действующего полиса в данный момент. Даже если все необходимые
детали содержатся в данных транзакции, для моментального снимка потребуется
взять в расчет транзакции с начала истории с учетом сложных бизнес-правил,
определяющих момент признания полученного дохода. Это не только непрактично в рамках одного полиса, но и нелепо — думать о создании сводных представлений ключевых показателей эффективности таким образом.
Решение этой дилеммы — создание отдельной таблицы фактов, которая
работает как дополнение к таблице транзакций по полисам. В этом случае бизнес-процесс представляет собой снимок ежемесячных страховых взносов. Зернистость таблицы фактов составляет одну строку для каждого покрытия и покрываемого полисом объекта каждый месяц.
Согласованные измерения
Конечно, при разработке таблицы периодических моментальных снимков страховых выплат вы должны стремиться повторно использовать как можно больше
измерений из таблицы транзакций по полису. Надеюсь, к настоящему времени
вы уже стали энтузиастом согласованных измерений. Как описано в главе 4, согласованные измерения, используемые в отдельных таблицах фактов, либо должны быть идентичными, либо представлять сокращенное подмножество атрибутов из детализированного измерения.
Такие измерения, как «Страхователь», «Объект покрытия» и «Покрытие»
будут идентичны. Измерение «Ежедневная дата» будет заменено соответствующей таблицей измерений «Месяц». Вам не нужно ежемесячно отслеживать
всех сотрудников, участвовавших в операциях с полисом; может быть полезно
сохранить задействованного агента, особенно потому, что операции на местах
сосредоточены на постоянном анализе показателей выручки. Измерение «Тип
транзакции» не будет использоваться, поскольку оно не применяется при детализации периодического моментального снимка. Вместо этого вы вводите
474
Глава 16
измерение «Статус», чтобы пользователи могли быстро определить текущее
состояние покрытия или полиса, например новые полисы или отмены в этом
месяце и с течением времени.
Согласованные факты
Пока мы обсуждаем тему согласованности, вам также необходимо использовать
согласованные факты. Если одни и те же факты отображаются в нескольких таблицах фактов, таких как факты, общие для этой таблицы фактов моментального снимка, а также сводной таблицы фактов, которую мы обсудим позже в этой
главе, то они должны иметь согласованные определения и метки. Если факты
не идентичны, то им нужно дать разные названия.
Факты о предоплате
Руководство бизнеса хочет знать, сколько доходов от страховых взносов было
записано (или продано) каждый месяц, а также сколько доходов было получено.
Хотя страхователь может заключить контракт и оплатить покрытие по застрахованным товарам в течение определенного периода времени, доход не будет
получен до тех пор, пока услуга не будет предоставлена. В случае страховой компании доход от полиса начисляется ежемесячно до тех пор, пока страхователь
не отменит его. Правильный расчет такого показателя, как «заработанные страховые взносы», будет означать полное воспроизведение всех бизнес-правил операционной системы признания доходов в приложении BI. Как правило, правила
преобразования суммы транзакции в ее влияние на ежемесячный доход сложны,
особенно при повышении и понижении уровня покрытия в середине месяца.
К счастью, эти показатели могут быть получены из отдельной операционной системы.
Как показано на рис. 16-4, мы включаем два показателя дохода от страховых
взносов в таблицу фактов периодического моментального снимка, чтобы учесть
различия в определении написанной и заработанной суммы от страховых взносов. Упрощенно говоря, если годовой полис для данного страхового покрытия
и покрываемого товара был выписан 1 января по цене 600 долларов США,
то «Записанная сумма страховых взносов» за январь составит 600 долларов
США, но «Заработанная сумма по страховым взносам» составляет 50 долларов
США (600 долларов США, разделенные на 12 месяцев). В феврале «Записанная
сумма» равна нулю, а «Заработанная сумма» по-прежнему составляет 50 долларов. Если полис будет отменен 31 марта, «Заработанная сумма» за март составит 50 долларов, в то время как «Записанная сумма» составит отрицательные
450 долларов. Очевидно, что на этом этапе поток заработанных доходов резко
останавливается.
Страхование
475
Таблица фактов страховых
взносов по полису
Измерение «Страхователь»
Измерение «Покрытие»
Измерение «Статус полиса»
Ключ даты состояния на конец
месяца (FK)
Ключ страхователя (FK)
Ключ агента (FK)
Ключ покрытия (FK)
Ключ предмета иска (FK)
Ключ статуса полиса (FK)
Номер полиса (DD)
Записанная сумма страховых взносов
Заработанная сумма страховых взносов
Измерение
«Конец месяца»
Измерение «Агент»
Измерение
«Объект покрытия»
Рис. 16-4. Периодическая схема страховых взносов
Бизнес-сценарии с оплатой авансом обычно требуют сочетания таблиц
фактов транзакций и ежемесячных моментальных снимков для ответа на вопросы о частоте и сроках транзакций, а также на вопросы о заработанном доходе за конкретный месяц. Вы почти никогда не сможете добавить достаточно
фактов в схему моментального снимка, чтобы избавиться от необходимости
в схеме транзакций. Или наоборот — не сможете добавить достаточно фактов в схему транзакций, чтобы отпала необходимость в схеме моментального
снимка.
Пересмотр гетерогенных супертипов и подтипов
Мы снова сталкиваемся с необходимостью взглянуть на данные моментальных
снимков с более конкретными атрибутами направления бизнеса и разобраться
с теми фактами моментальных снимков, которые варьируются в зависимости
от направления бизнеса. Поскольку пользовательские факты для каждой строки
несовместимы друг с другом, большая часть строки фактов будет заполнена null,
если вы включите все факты о бизнесе в каждую строку. В этом сценарии ответ
заключается в физическом разделении таблицы фактов ежемесячного моментального снимка по направлениям деятельности. В итоге вы получаете единую схему
ежемесячных снимков супертипа и серию снимков подтипа, по одному для каждой отрасли бизнеса или типа покрытия. Каждая из таблиц фактов моментального снимка подтипа — копия сегмента таблицы фактов супертипа только для
тех ключей покрытия и ключей охватываемых товаров, принадлежащих определенному направлению деятельности. Мы включаем факты супертипа для удобства, чтобы анализы в пределах типа покрытия могли использовать как факты
супертипа, так и пользовательские факты подтипа без доступа к двум большим
таблицам фактов.
476
Глава 16
Пересмотр многозначных измерений
Страхование автомобилей предоставляет еще одну возможность обсудить многозначные измерения. Часто несколько застрахованных водителей связаны с одним
полисом. Вы можете создать соединительную таблицу, как показано на рис. 16-5,
чтобы отразить взаимосвязь между застрахованными водителями и полисом.
В этом случае страховая компания может назначить реалистичные весовые коэффициенты, основанные на доле каждого водителя в общей стоимости премии.
Таблица фактов
страховых взносов
Ключ даты состояния на конец
месяца (FK)
Ключ страхователя (FK)
Другие ключи…
Ключ полиса (FK)
Записанная сумма страховых
взносов
Заработанная сумма страховых
взносов
Соединительная таблица
застрахованных водителей
Ключ политики (FK)
Ключ застрахованного
водителя (FK)
Коэффициент
Измерение
«Застрахованный водитель»
Ключ застрахованного
водителя (PK)
Имя застрахованного водителя
Атрибуты адреса
застрахованного водителя…
Дата рождения застрахованного
водителя
Категория риска застрахованного
водителя
Рис. 16-5. Соединительная таблица для нескольких застрахованных водителей
Поскольку эти взаимосвязи могут меняться с течением времени, вы можете
добавить даты вступления в силу и истечения срока действия в соединительную
таблицу. Не успеете вы оглянуться, как получите таблицу фактов без фактов, отражающую эволюцию отношений между полисом, держателем полиса, застрахованным товаром и застрахованным водителем с течением времени.
Более подробная информация
об изучении страховых случаев
К сожалению, у страхового бизнеса есть и обратная сторона. От опрошенных
мы узнаем, что в жизни есть нечто большее, чем сбор страховых взносов. Основные издержки в этой отрасли связаны с потерями по претензиям. После
того как полис вступит в силу, можно будет предъявить претензию в отношении конкретного страхового покрытия и покрываемого объекта. Заявитель —
им может быть страхователь или новая сторона, ранее не известная страховой
компании — предъявляет претензию. Когда страховая компания открывает
Страхование
477
новую претензию, обычно создается резерв. Резерв представляет собой предварительную оценку возможной ответственности страховой компании по данному иску. По мере поступления дополнительной информации этот резерв может
быть скорректирован.
Прежде чем страховая компания выплатит какую-либо претензию, обычно
проводится этап расследования, на котором страховая компания отправляет
специалиста по страхованию для изучения объекта страхования и опроса заявителя, страхователя или других вовлеченных лиц. На этапе расследования
создается поток транзакций задач. В сложных претензиях могут потребоваться
различные сторонние эксперты для вынесения суждения по претензии и размеру ущерба.
В большинстве случаев после этапа расследования страховая компания производит ряд выплат. Многие из этих платежей идут третьим лицам, таким как врачи, юристы или операторы автомастерских. Некоторые платежи могут поступать
непосредственно заявителю. Важно четко определить сотрудника, ответственного за каждый платеж, произведенный по открытой претензии.
Страховая компания может вступить во владение застрахованным предметом
после его замены для страхователя или заявителя. Если у товара есть какая-либо
остаточная стоимость, выплаты за спасение, полученные страховой компанией,
становятся кредитом в учете претензий.
В конце концов платежи завершаются и претензия закрывается. Если ничего необычного не происходит, это конец потока транзакций, сгенерированного
претензией. Однако в некоторых случаях дальнейшие выплаты по претензиям
или судебные иски истцов могут привести к повторному рассмотрению претензии. Важный показатель для страховой компании — то, как часто и при каких
обстоятельствах возобновляются претензии.
В дополнение к анализу подробных транзакций по обработке претензий страховая компания также хочет понять, что происходит в течение срока действия
претензии. Например, задержка во времени между датой открытия претензии
и датой первого платежа — важный показатель эффективности обработки претензий.
Обновленная матрица страховой шины
Для лучшего понимания бизнес-аспектов, связанных с претензиями, необходимо
пересмотреть проект матрицы на рис. 16-1. В соответствии с новыми требованиями вы добавляете в матрицу еще одну строку для размещения транзакций
претензий, как показано на рис. 16-6. Многие измерения, определенные ранее
в проекте, будут использоваться повторно; вы добавляете новые столбцы в матрицу для претензии, заявителя и получателя платежа третьей стороны.
Поли
с
X
X
X
X
X
Месяц
X
X
X
X
Агент
X
X
X
X
X
X
X
Заяви
Транзакции претензий
Прет
ен
Снимок страховых
взносов
тель
Треть
я
полу сторона,
ча ю
плате щая
ж
Сотру
дник
X
овате
Транзакции по полису
зия
Застр
ахов
объе анный
кт
Покр
ытие
X
ль
Страх
Глава 16
Дата
478
X
X
X
Рис. 16-6. Обновленная матрица страховой шины
Подробная матрица шины реализации
Команды DW/BI иногда испытывают трудности с уровнем детализации, отображаемым в матрице шины корпоративного хранилища данных. На этапе планирования проекта DW/BI с архитектурой имеет смысл придерживаться бизнес-процессов (или источников) довольно высокого уровня. Каждая из этих
строк бизнес-процесса может содержать несколько таблиц фактов с различными
уровнями детализации. На последующем этапе реализации вы можете вывести
подмножество матрицы на более низкий уровень детализации, отразив все таблицы фактов или кубы OLAP, полученные в результате процесса, в виде отдельных строк матрицы. На этом этапе матрицу можно расширить, добавив столбцы
для отражения детализации и показателей, связанных с каждой таблицей фактов
или кубом. Рис. 16-7 иллюстрирует более подробную матрицу шины реализации.
Операции с претензиями
Операционная система обработки претензий генерирует множество транзакций,
включая следующие типы задач транзакций:
■ Открыть претензию, Повторно открыть претензию, Закрыть претензию;
■ Установить резерв, Сбросить резерв, Закрыть резерв;
■ Установить оценку утилизации, Получить оплату за утилизацию;
■ Проверка наладчика, Собеседование с наладчиком;
■ Открыть судебный процесс, Закрыть судебный процесс;
■ Произвести платеж, Получить платеж;
■ Заменить претензию.
Рис. 16-7. Подробная матрица шины реализации
1 строка ан претензию
1 строка на сторону,
потерпевшую убытки
или вовлеченную
в претензию по авто
Работа по претензиям
Вовлеченность в инцидент
Количество вовлеченных
в происшествие
X
X
X
X
X
Авто
X
X
Агент
X
X
Авто
X
X
Дом
Агент
X
Агент
Авто Агент
X
Дом
Авто
X
X
X
X
X
X
X
X
X
Авто
X
X
Прет
ензия
Первоначальный резерв,
Оценка, Текущий резерв,
Оплаченная часть, Собранный
суммы; Убыток при открытии,
От открытия до оценки,
От открытия до 1-го платежа,
От открытия до суброгации
и От открытия до закрытия;
Номер транзакции
Trxn
Eff
Дом
Авто
X
Дом
Авто
X
X
X
X
Заяви
тель
1 строка на каждую
транзакцию претензий
X
X
X
X
X
X
X
Тр
полу етья сторо
чающ
н
ая пл а,
атеж
Транзакции претензий
События претензий
Количество транзакций
претензий
X
Суммы списанных выплат
и гонораров в страховых
взносам по полису
1 строка на каждую политику,
объект и выплаты в месяц
X
Суммы списанных выплат
и гонораров в страховых
взносам по полису
Страховые взносы
1 строка на каждую политику,
по автомобильному полису
объект и выплаты в месяц
Страховые взносы
по полису для домов
X
Суммы списанных выплат
и гонораров в страховых
взносам по полису
Количество транзакций
по полису
Страховые взносы
1 строка на каждую политику,
по корпоративному полису
объект и выплаты в месяц
Страховые взносы по полису
1 строка на каждую
транзакцию по полису
Транзакции
по полису домов
Количество транзакций
по полису
тие
X
Покр
ы
1 строка на каждую
транзакцию по полису
Страх
овате
ль
X
крыт
ия
Транзакции по полису
автомобилей
Дата
Trxn
Eff
Trxn
Eff
Trxn
Eff
кт по
Количество транзакций
по полису
Сотру
дник
1 строка на каждую
транзакцию по полису
Факты
Поли
с
Корпоративные транзакции
по полису
Гранулярность
Объе
Транзакции по полису
Таблица фактов / куб OLAP
Страхование
479
480
Глава 16
При обновлении матрицы шин на рис. 16-6 вы определяете, что в этой схеме используется ряд измерений, разработанных для мира полисов. У вас снова
есть два ролевых измерения «Дата», связанные с транзакциями претензий. Уникальные метки столбцов должны отличать транзакцию претензии и даты вступления в силу от тех, которые связаны с транзакциями полисов. Сотрудник — это
сотрудник, участвующий в транзакционной задаче. Как упоминалось в бизнеспримере, это особенно интересно для транзакций авторизации платежей. Измерение «Тип транзакции претензии» будет включать только что перечисленные
типы транзакций и группировки.
Как показано на рис. 16-8, в таблице фактов транзакции претензии появилось
несколько новых измерений. Истец — это сторона, предъявляющая претензию,
как правило, физическое лицо. Получателем платежа третьей стороны может
быть как физическое, так и юридическое лицо. Измерения «Заявитель» и «Получатель платежа» обычно являются «мусорными» измерениями из-за сложности их надежной идентификации в претензиях. Недобросовестные потенциальные получатели платежей могут изо всех сил стараться не идентифицировать себя
таким образом, чтобы снизить возможность связать их с другими претензиями
в системе страховой компании.
Таблица фактов
транзакций по претензии
Измерение «Дата» (2 роли)
Измерение «Страхователь»
Измерение «Покрытие»
Измерение «Заявитель»
Измерение
«Тип транзакции претензии»
Измерение «Претензия»
Ключ даты транзакции по иску (FK)
Ключ даты вступления в силу
транзакции по претензии (FK)
Ключ страхователя (FK)
Ключ сотрудника, проводящего
транзакцию по претензии (FK)
Ключ агента (FK)
Ключ покрытия (FK)
Ключ объекта покрытия (FK)
Ключ заявителя (FK)
Ключ получателя платежа третьей
стороны (FK)
Тип ключа транзакции претензии (FK)
Ключ профиля иска (FK)
Ключ иска (FK)
Номер полиса (DD)
Количество транзакций
по претензии (DD)
Сумма в долларах на транзакции
по претензии
Рис. 16-8. Схема транзакции обработки претензий
Измерение «Сотрудник» (2 роли)
Измерение «Объект покрытия»
Измерение «Третья сторона —
получатель платежа»
Измерение «Профиль претензии»
Страхование
481
Транзакция в сравнении с мусорным измерением
«Профиль претензии»
Помимо повторно используемых измерений из схем, ориентированных на полисы, и только что перечисленных новых измерений, ориентированных на претензии, существует большое количество показателей и описаний, связанных с претензией. У дизайнеров иногда возникает соблазн поместить все эти описательные
атрибуты в измерение «Претензия». Этот подход имеет смысл для дескрипторов высокой кардинальности, таких как конкретный адрес, где произошла потеря, или описание события. Однако, как правило, вам следует избегать создания
измерений с тем же количеством строк, что и в таблице фактов.
Как мы описали в главе 6, кодифицированные данные с низкой кардинальностью, такие как метод, используемый для сообщения о потере, или индикатор,
указывающий, является ли претензия результатом катастрофического события,
лучше обрабатываются в мусорном измерении. В этом случае мусорное измерение
было бы более уместно называть измерением «Профиль претензии» с одной строкой на уникальную комбинацию атрибутов профиля. Группировка или фильтрация по атрибутам профиля даст более быстрые ответы на запросы, чем если бы они
альтернативно обрабатывались как атрибуты измерения «Претензия».
Накопительный моментальный
снимок для претензий
Даже при наличии надежной схемы транзакций существует целый класс неотложных бизнес-вопросов, на которые невозможно ответить, используя только детали транзакции. Трудно получить показатели эффективности претензии на сегодняшний день путем детального анализа всех операций по претензиям с начала
истории претензии и соответствующим образом применяя транзакции.
На периодической основе, возможно, в конце каждого дня, вы можете переносить все транзакции вперед, чтобы постепенно обновлять накопительный
моментальный снимок заявки. Зернистость составляет одну строку для каждой
претензии; строка создается один раз при открытии претензии, а затем обновляется в течение всего срока действия претензии, пока она не будет окончательно
закрыта.
Многие измерения — это переиспользуемые согласованные измерения, как
показано на рис. 16-9. Вам следует включить больше дат в эту таблицу фактов,
чтобы отслеживать ключевые этапы подачи претензий и задержки во времени.
Эти задержки могут быть реальной разницей между двумя датами либо они
могут быть рассчитаны более сложным способом путем учета только рабочих
дней в расчетах. Например, добавляется измерение «Статус» для быстрого
482
Глава 16
определения всех открытых, закрытых или вновь открытых претензий. Измерения, относящиеся к конкретной транзакции, такие как «Сотрудник», «Получатель платежа» и «Тип транзакции» претензии, убраны, в то время как список
дополнительных числовых показателей был расширен.
Таблица фактов работы по претензии
Измерение «Дата»
(7 разных ролей)
Измерение «Страхователь»
Измерение «Покрытие»
Измерение «Заявитель»
Измерение
«Статус претензии»
Ключ даты подачи претензии (FK)
Ключ даты претензии (FK)
Ключ даты оценки претензии (FK)
Ключ даты первого платежа по претензии (FK)
Ключ даты последнего платежа по претензии (FK)
Ключ даты замены претензии (FK)
Ключ даты закрытия претензии (FK)
Ключ страхователя (FK)
Ключ ответственного за претензию (FK)
Ключ агента (FK)
Ключ покрытия (FK)
Ключ предмета претензии (FK)
Ключ заявителя (FK)
Ключ статуса претензии (FK)
Ключ профиля претензии (FK)
Ключ претензии (FK)
Номер полиса (DD)
Первоначальная резервная сумма в долларах
Ориентировочная сумма в долларах
Текущий резерв, сумма в долларах
Выплачено по иску на сегодняшний день сумма
в долларах
Утилизация, собранная на сегодняшний день,
сумма в долларах
Субподрядный платеж, собранный
на сегодняшний день, сумма в долларах
Время от несчастного случая до претензии
Время от открытия иска до его оценки
Время от открытия иска до первого платежа
по нему
Время от открытия иска до его суброгации
Время от открытия иска до его закрытия
Количество транзакций по претензии
Измерение «Сотрудник»
(2 взгляда на роли)
Измерение «Объект страхования»
Измерение «Профиль претензии»
Измерение «Претензия»
Рис. 16-9. Схема накопительного моментального снимка претензий
Накопление моментальных снимков для сложных
рабочих процессов
Таблицы фактов накопительных моментальных снимков обычно подходят для
предсказуемых рабочих потоков с четко установленными этапами. Обычно они
имеют от 5 до 10 ключевых дат, представляющих начало, завершение и ключевые события между ними. Однако иногда рабочие процессы менее предсказуемы.
У них все еще есть определенная дата начала и окончания, но промежуточные
Страхование
483
этапы многочисленны и менее стабильны. Некоторые события могут пропустить
некоторые промежуточные этапы, но надежной