Основы создания витрин данных - создание схемы звезда и снежинка
•Download as PPTX, PDF•
1 like•1,506 views
Краткий курс посвященный основам моделирования хранилищ данных, построенных по классической схеме - звезда или снежинка (Dimensional Modeling). Дает представление в целом об архитектурах хранилищ данных и их компонентах.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Основы создания витрин данных - создание схемы звезда и снежинка
Similar to Основы создания витрин данных - создание схемы звезда и снежинка (20)
Основы создания витрин данных - создание схемы звезда и снежинка
- 1. Витрины данных Основы создания модели данных - схемы звезда и снежинка Сергей Сухарев Эксперт отдела BI-систем и интеграционных технологий ООО «Джи-Эм-Си-Эс Верэкс»
- 2. Сергей Сухарев • Эксперт отдела BI-систем и интеграционных технологий • > 20 лет в IT • > 18 лет в DWH • Экспертиза: • Архитектор информационных систем • Архитектор Хранилищ Данных и систем Business Intelligence • Знания методик построения Корпоративных Хранилищ Данных (ER, Dimensional Modeling, Data Vault) • Бизнес аналитик/Системный аналитик • Опыт оптимизации баз данных для целей построения Корпоративных Хранилищ Данных и отчетности (Oracle, MS SQL Server) • Опыт разработки Витрин Данных и отчетов в системах отчетности • Разработчик процессов загрузки данных в Корпоративные Хранилища Данных и Витрины Данных (ETL)
- 3. Хранилища / витрины данных • Предназначены для: • Хранить данные • Предоставлять данные в удобном для анализа виде
- 4. Последовательность разработки витрины данных Определение требований Разработка модели данных Разработка физической модели данных Разработка процессов загрузки данных
- 5. Модель данных – фундамент хранилищ данных и витрин
- 6. Модели данных • Сущность / связь модель данных (E/R modeling) • Многомерная модель данных (Dimensional modeling) • Иногда встречается альтернативное название - Kimball Modeling
- 7. Сущность / Связь E/R модель базируется на трех вещах – сущность, атрибуты сущностей, связи сущностей
- 8. Dimensional modeling Dimensional modeling содержит два основных вида таблиц: таблицы фактов и таблицы измерений
- 9. Таблицы фактов • Таблицы фактов содержат числовые значения, которые называются мерами • Каждая таблица фактов содержит ссылки (foreign keys) на таблицы измерений • Таблицы фактов часто имеют небольшое кол-во колонок • Таблицы фактов часто имеют миллионы строк • Характеристики информации в таблице фактов: • Это числа, которые могут использоваться для вычислений агрегатов и сумм • Значения могут быть аддитивными (одно правило расчета на всех узлах иерархий) или полуаддитивными (например сумма за месяц равны сумме на последний день месяца) • Делится на сегменты: сегмент [ключи измерений] и сегмент [данные] DATE_ID CUSTOMER_ID STORE_ID AMOUNT AMOUNT WITH VAT
- 10. Хорошие и плохие таблицы фактов dim_Time dim_Customer dim_Product dim_Promotion Salesperson Type Status Unit Price Gross Margin Dally Sales YearToDate Sales last Year YTD Sales Это плохая таблица фактов dim_Time dim_Customer dim_Product dim_Promotion dim_Salesperson dim_Status Это хорошая таблица фактов quantity sold extended list price total allowances total discounts extended net price Элементы данных в плохой таблице фактов содержат значения: • Не числовые. Поэтому данные нельзя суммировать. • Не аддитивный. Например, скидки и скидки скрыты в Цене за единицу. • Не имеют связей с измерениями, что означает, что они не могут быть аддитивным.
- 11. Таблицы измерений • Таблицы измерений содержат сведения о фактах. • Таблицы измерений содержат описательную информацию о числовых значения в таблице фактов. Т.е. они содержат атрибуты фактов например [Компания покупатель]-[Период]-[Продукт]-[Маркетинговая акция] • Поскольку данные в таблице измерений денормализуются, они часто имеют большое кол-во столбцов • Таблицы измерений чаще всего содержат значительно меньшее количество строк, чем таблицы фактов. • Атрибуты в таблице измерений обычно используются как строки и столбцы заголовков в отчетах или результатов запроса. Например, текстовые описания в отчете берутся из атрибутов измерения.
- 12. Типы многомерных моделей данных
- 13. «Снежинка»
- 15. Корпоративное хранилище данных (EDW)
- 18. Модели данных и архитектуры хранилищ данных
- 19. Модели данных в слоях корпоративного хранилища данных
- 20. Модели данных в архитектуре несогласованных и согласованных витрин Несогласованные витрины данных Согласованные витрины данных
- 21. Последовательность создания модели данных Определение бизнес требований Создание логической модели данных Создание физической модели данных Выполнение бизнес требований при хранении данных
- 23. Пирамида информации Оперативные системы, анализ данных за 60, 120, 180 … дней Промежуточная область денормализованных данных, анализ данных за 60, 120, 180 … дней Предрасчитанные, просуммированные данные, анализ данных за последний год Хранилище детальных данных чаще в 3NF, анализ данных за последний год Информационные панели, статичные отчеты Витрины данных, анализ данных за последний год Оперативный уровень Тактический уровень Стратегический уровень
- 24. Типы пользователей BI систем • Корпоративные пользователи, потребители и партнеры. • Случайные пользователи или пользователи повседневной отчетности. • Бизнес пользователи. • Продвинутые пользователи • IT специалисты
- 25. Технология многомерного анализа данных • Многомерный анализ позволяет взглянуть на бизнес-проблему с большим числом связанных факторов • Чаще всего при многомерном анализе данных применяют следующие шаги: • Slice и Dice • Разворот таблицы • Переходы по уровням сверху вниз и снизу вверх, переход на связанный отчет, детализация данных (Drill Down, Drill Up, Drill Through) • Свертывание и развертывание
- 26. Slice
- 27. Dice
- 28. Разворот таблицы по измерениям
- 29. Drill Down и Drill Up
- 30. Drill Through
- 33. Основные шаги • Определение бизнес-процессов и требований к ним • Определение ядра бизнес-процесса, поиск атомарного уровня • Идентификация измерений • Идентификация фактов • Верификация модели • Физический дизайн
- 34. Определение бизнес-процессов и требований к ним • Формирование списка бизнес-процессов всего предприятия • Идентификация бизнес-процесса (включая приоритеты) • Определение сущностей и показателей • Определение источников данных, связанных с бизнес-процессом • Определение подхода к сбору требований • Собор требований • Анализ требований
- 35. Список бизнес-процессов • Планирование продаж • Реклама и маркетинг • Закупка • Производство • Продажа
- 36. Идентификация бизнес-процесса • Определение приоритетов • Детализация бизнес-процесса • Разработка E/R модели бизнес-процесса • Разработка BI матрицы верхнего уровня • Определение источников данных • Сбор требований пользователей к анализу данных • Сбор требований к отчетам • Анализ требований
- 37. E/R модель бизнес-процесса Заказ на проивзводство PK ЗаказНаПроизводство Номер Заказа Дата производства FK2 Организация FK1 Склад FK3 SKU (продукт хранения) Бух.счет Рабочий центр Смена План, кг Статус Участок Конфигурация Подразделение склада Цех Плановое количество Описание Накладная расхода в производство PK НакладнаяРасхвПроизв Документ Дата накладной Дата проводки Тип журнала Заказ на производство Смена Рабочий центр FK2 Склад FK1 ЗаказНаПроизводство Подразделение склада Участок Накладная расхода в производство строки PK Накладная FK1 НакладнаяРасхвПроизв Документ – Накладная FK3 SKU (продукт хранения) Заказ на производство FK2 ЗаказНаПроизводство Операция Количество, базовая ЕИ Количество,кг Конфигурация Накладная приемки PK ОтгрузочнаяНакладная Документ Дата накладной Дата обработки Тип журнала Заказ на производство FK1 ЗаказНаПроизводство FK2 Склад Накладная приемки строки PK ОтборочнаяНакладная отгрузочная накладная FK1 ОтгрузочнаяНакладная FK3 SKU (продукт хранения) Заказ на производство FK2 ЗаказНаПроизводство Операция Единица измерения Количество в ед.изм. Вес, кг Организация PK Организация Склад PK Склад Продукт PK ПродуктХранения Упрощенное производство PK УпрощенноеПроизводство (PK) Номер документа Дата документа FK2 Организация FK1 Склад Имя Описание Упрощенное производство строки PK Накладная FK1 УпрощенноеПроизводство (PK) FK2 ПродуктХранения Номер документа Номер строки Конфигурация Спецификация Единица измерения Количество Вес, кг Заказ на закупку PK ЗаказНаЗакупку Номер заказа Дата заказа FK1 Организация FK2 Поставщик FK3 ПоставщикКЗ Договор Статус Валюта Цена с НДС Заказ на закупку строки FK1 ЗаказНаЗакупку Номер заказа FK3 SKU (продукт хранения) Номер строки FK2 Склад Единица измерения Количество Вес Цена Сумма с НДС Ставка НДС Сумма без НДС Сумма НДС Конфигурация Приходный ордер PK ПриходныйОрдер Номер документа Дата документа FK1 ЗаказНаЗакупку Номер заказа FK5 Склад FK3 Поставщик Операция FK4 Поставщик (кредитор) Валюта FK2 Организация Приходный ордер строки PK ОтборочнаяНакладная FK1 ПриходныйОрдер FK2 ЗаказНаЗакупку Номер заказа Номер документа FK4 SKU (продукт хранения) Номер строки FK3 Склад Единица измерения Количество Вес, кг Ставка НДС Сумма с НДС Сумма без НДС Сумма НДС Сумма валюта Конфигурация Накладная закупки PK НакладнаяНаЗакупку FK1 ЗаказНаЗакупку Номер документа Номер заказа Дата документа FK2 Организация Договор FK3 Поставщик FK4 ПоставщикКЗ Операция Цена включает налог Валюта Сумма в валюте Сумма с НДС Сумма без НДС Сумма НДС Бух.счет КЗ Накладная закупки строки PK Накладная FK1 НакладнаяНаЗакупку FK2 ЗаказНаЗакупку Номер документа Номер заказа FK3 Склад FK4 SKU (продукт хранения) Единица измерения Количество Вес, кг Цена единицы Скидка % Сумма скидки Сумма с НДС Сумма без НДС Сумма НДС Сумма в валюте Конфигурация Бух.счет Организация PK Организация Склад PK Склад Продукт PK ПродуктХранения Производство Закупка
- 38. Матрица верхнего уровня Дата Организация Контрагент Склад Продукт Продажа + + + + + Закупка + + + + + Производство + + + + Справочники (измерения) Факты (бизнес процессы, показатели или меры)
- 39. Определение ядра бизнес-процесса и поиск атомарного уровня • Гранулярность таблицы фактов • Определение таблиц фактов одного бизнес-процесса, один бизнес процесс может содержать несколько таблиц фактов • Определить тип каждой таблицы фактов (транзакции, периодические снимки, снимки с накоплением) • Определить возможность получения данных для таблицы фактов на самом детальном уровне • Определить перечень измерений для каждой таблицы фактов • Создание отчета по результатам работы для каждой таблицы фактов
- 40. Определение измерений 1 Определение измерений Определение измерений, которые соответствуют таблицам фактов 2 Определение вырожденных (degenerate) измерений Поиск в таблицах фактов колонок, которые на самом деле являются не мерами а измерениями 3 Определение согласованных (conformed) измерений Определение измерений, которые связывают разные таблицы фактов из разных источников. 4 Определение атрибутов и иерархий Определение атрибутов и иерархий измерений, сбалансированные и не сбалансированные иерархии, иерархии родитель-потомок. Определение правил обработки измерений и их атрибутов 5 Определение требований к измерению Время (календарь) Определяется вид календаря, наличие в модели нескольких альтернативных календарей н.р. + производственный календарь 6 Определение медленно меняющихся измерений Определение медленно меняющихся измерений 1-го, 2-го и 3-го типа. 7 Определение быстроменяющихся измерений Определение быстроменяющихся измерений, создание нескольких мини измерений, определение способов обработки данных таких измерений 8 Определение измерений, которые приводят модель данных к типу - снежинка Определение измерений, которые состоят из нескольких связанных между собой таблиц н.р. Продукт -> Группа продукта -> Тип продукта 9 Определение остальных измерений: Multi-valued измерение Измерение имеет множество значений и требует таблицы-мост Role-playing измерение Одна и та же таблица имеет несколько ролей в модели данных Heterogeneous измерение Гетерогенные измерения имеют разный набор атрибутов но являются одним и тем же измерением Garbage измерение Определение мусорных измерений (коды, индикаторы, флаги статусов, пол) Hot Swappable измерение Измерение имеет несколько альтернативных версий и меняется в зависимости от контекста запроса
- 41. Определение измерений Измерения в теле документа
- 47. Типы медленно меняющихся измерений Тип 1 Тип 2 Тип 3
- 48. Определение быстро меняющихся измерений Age и Weight быстро меняющиеся измерения
- 49. Трансформация модели с быстро меняющимся измерением Плохое решение – превращение справочника в снежинку Хорошее решение – добавление нового справочника
- 50. Определение измерения, которое должно быть трансформировано в снежинку
- 52. Multi-valued измерение Одна продажа – несколько торговых представителей Добавлена таблица – мост, для того что бы развязать справочник и факты (M:M)
- 53. Heterogeneous измерение Разделение таблицы фактов по измерениям Оставляем атрибуты, которые являются общими Страховой продукт имеет разный набор атрибутов для страхования ОСАГО и ДМС
- 55. Определение фактов 1 Определение фактов Определение фактов, которые соответствуют ядру бизнес-процесса 2 Определение согласованных фактов Согласованные факты соответствуют согласованным измерениям, если такие имеются то обработка фактов должна быть идентична 3 Определение типа факта Типы фактов: - Additive - Semi-additive - Non-additive - Derived - Textual - Pseudo - Factless 4 Year-to-date факты Факты с расчетом накопленным итогом за период, такие факты необходимо держать отдельно от транзакций или рассчитывать в BI приложении 5 Факты - события Определение фактов, которые являются событиями н.р. факт изменения статуса заказа клиента, конвейер данных 6 Определение ключей Определить составные ключи таблицы фактов, поиск первичного ключа таблицы фактов, обработка ситуации вырожденного измерения в таблице фактов 7 Прогнозирование роста таблицы фактов Определение необходимости сегментирования таблицы фактов и правила его определения
- 56. Определение факта на основе документа Факты в теле документа
- 57. Определение факта на основе E/R модели • Выделить в E/R модели сущности бизнес-процесса • Найти таблицы со стороной связи многие ко многим, это кандидаты в таблицы фактов • Провести денормализацию остальных таблиц, преобразовав их в таблицы измерений • Определить дату / время для создания измерения календарь
- 58. Типы фактов • Additive • Могут применяться функции SUM, MIN, MAX по любому измерению, которое ассоциируется с этим фактом • Semi-additive • Могут применяться функции SUM, MIN, MAX но не ко всем измерениям, которые ассоциируются с фактом (н.р. сумма за квартал равна сумме за последний месяц квартала, средний за квартал равен сумме за первый месяц квартала и за последний месяц квартала, деленное по полам) • Non-additive • К ним не могут примется функции агрегирования (н.р. проценты или отношения) • Derived • Факты, рассчитанные на основе других фактов. Рекомендация: не смешивать факты рассчитанных агрегатов и деталей в одной таблице фактов • Textual • Чаще всего коды или символы, которые помогают в расчетах производных фактов • Factless • Факты без числовых мер, такие таблицы содержат только ссылки на измерения, чаще всего это результаты каких то событий
- 59. Факты - события • Факты – события • Таблицы фактов в которых содержатся события • Примеры: • Переходы web-пользователя по страницам сайта • Посещение пациентом лечебного учреждения по страховке • Учет времени прихода / ухода сотрудника на работу • Сдача студентом зачета / экзамена
- 60. Определение первичного ключа таблицы фактов • Первичный ключ факта – набор ключей измерений • Не обязательно чтобы все ключи измерений входили в первичный ключ факта • Не всегда комбинация всех ключей измерений дает уникальность строки таблицы факта, для добавления уникальности иногда добавляют вырожденное измерение в ключ
- 61. Верификация модели данных • Проверка правильности определения ядра гранулярности модели бизнес-процесса • Неправильное определение ядра может повлечь за собой в дальнейшем полную переделку модели данных • Детализация данных – данные разной гранулярности должны находиться в разных таблицах фактов • Идеальная модель данных – таблицы фактов содержат данные на атомарном уровне • В модели должно присутствовать хотя бы одно измерение календарь • Измерение дата и измерения время должны быть разделены по разным таблицам измерений • Вырожденные измерения должны быть выделены из таблицы фактов в таблицы измерений • Измерения обязательно должны содержать суррогатные ключи, это обеспечивает стабильность модели данных • Денормализация схемы «снежинка» в схему «звезда» • Балансировка несбалансированных иерархий • Разная гранулярность данных факта для одного измерения • Таблица фактов содержит планы производства на уровне месяц и факты производства, собранные по дням, для связи с одним измерением календарь планы необходимо загружать на первый или последний день месяца
- 62. Разработка модели данных Практический пример
- 64. Описание бизнес-процесса • Представлена база данных компании, занимающейся прокатом DVD фильмов; • Две основных таблицы (бизнес-процесса) – аренда (rental), оплата (payment), аренда и оплата связаны между собой по полю RENTAL_ID (эта связь – кандидат на вырожденное измерение RENTAL); • Справочники системы – фильмы с описанием (film, category, film_category (категории фильма), actor, film_actor (актеры в фильме), language (язык оригинала, язык фильма)) ; сотрудник (staff); клиент (customer); магазин (store); адрес (address, city, country);
- 65. Матрица верхнего уровня фильм сотрудник клиент магазин календарь аренда* аренда + + + + + + оплата + + + +
- 66. Измерения • Фильм: фильм, категории фильма, актеры в фильме, язык DVD, язык оригинала • Магазин: магазин, адрес магазина, город, страна, директор магазина • Сотрудник магазина: адрес, город, страна, магазин • Клиент: адрес, город, страна • Дата аренды (календарь) • Дата возврата (календарь) • Дата оплаты (календарь) • Аренда*
- 67. Факты • Аренда: кол-во взятых в аренду, кол-во возвращенных клиентом, продолжительность аренды в днях • Оплата: кол-во платежей, сумма платежа
- 68. Результат
- 69. Литература • IBM Dimensional Modeling: In a Business Intelligence Environment ibm.com/redbooks • Ralph Kimball and Margy Ross: The Data Warehouse Toolkit
Editor's Notes
- E/R модель базируется на трех вещах – сущность, атрибуты сущностей, связи сущностей
- Dimensional modeling (многомерная модель) содержит два основных вида таблиц: таблицы фактов (F_) и таблицы измерений (D_)
- Элементы данных в плохой таблице фактов содержат значения: Не числовые. Поэтому данные нельзя суммировать. Не аддитивный. Например, скидки и скидки скрыты в Цене за единицу. Не имеют связей с измерениями, что означает, что они не могут быть аддитивным.
- Star Schema (звезда) – одна таблица фактов, каждый справочник (измерение) состоит только из одной таблицы Snowflake Schema (снежинка) – одна таблица фактов, справочник (измерение) может состоять из нескольких связанных таблиц Multi-Star Schema (связанная звезда) – несколько таблиц фактов, соединенных общими для них справочниками
- Market и Product – измерения, которые составляют лучи «снежинки», состоят из нескольких связанных таблиц Sales – таблица фактов
- Корпоративное хранилище данных – это многослойная система, каждый слой которой предназначен для определенной цели. Source Systems – источники данных, находятся вне корпоративного хранилища данных Stage Area – обязательная область данных, которая предназначена для временного хранения входных данных, в этой области производятся процессы очистки, преобразования и согласования данных, подготовки данных для загрузки в следующий слой EDW – область хранения данных, предназначена в соответствии со своим названием хранить данные, данные в этой области могут быть представлены как в 3-й нормальной форме, так и Anchor (6NF) или Data Vault Отчеты по этой области данных строятся только с технологической целью, а не с целью анализа данных. Data Mart (витрина данных) – область представления данных, данные в этой области лежат в удобном для анализа виде, что бы их было легче достать с наименьшими затратами по ресурсам системы.
- Несогласованные витрины данных чаще всего встречаются в виде функциональных систем бизнес-анализа. Системы разделены по функциям, департаментам или бизнес-задачам. Например одна система служит для анализа и планирования закупок, другая система служит для управления и анализа задолженностью по договорам поставки. Справочники несогласованных витрин никак не связаны между собой, каждая из независимых витрин может грузиться разными процессами, даже если в основе лежит один и тот же источник данных.
- Противоположность несогласованных витрин, справочники (измерения) и факты таких витрин данных согласованы между собой. Согласование справочника – загрузка одного справочника производится из разных источников, данные одного источника «обогащаются» атрибутами другого источника. Например справочник контрагентов может собирать информацию из ERP и CRM системы, при этом базой для справочника является таблица из ERP системы, а к ней добавляются колонки из таблицы CRM системы. Для двух разных департаментов справочник контрагентов будет иметь один и тот же набор данных.
- Staging Area – может быть построена или содержать в себе все типы моделей данных одновременно – нормализованные, денормализованные данные EDW – ядро хранилища данных чаще всего построено по нормализованной модели Data Mart – всегда строится на основе многомерной модели данных (Dimensional Model)
- Несогласованные витрины: Staging Area – нормализованная модель данных, Data Mart – многомерная модель данных, EDW – центральное хранилище данных отсутствует Согласованные витрины – присутствует EDW – центральное хранилище данных, которое является ядром системы и основой для согласованных витрин данных
- Оперативный уровень – ежедневная отчетность, с ней работают менеджеры среднего звена, для анализа текущей ситуации в оперативном режиме. Данные на этот уровень могут поступать в реальном режиме времени или могут быть получены непосредственно из учетных систем. Срок хранения данных не большой. Тактический уровень – уровень принятия тактических решений, отчетность от ежедневной до сравнения данных с предыдущим годом. Срок хранения данных не больше 2-х лет. Стратегический уровень – уровень принятия стратегических решений, руководство и акционеры компании, отчетность сгруппирована по показателям на верхних уровнях иерархий измерений, чаще всего используются анализ TOP лучших и TOP худших , сравнение данных за несколько лет.
- Корпоративные пользователи, потребители и партнеры: у этих пользователей самая низкая потребности в отчетности. Эти пользователи обычно получают доступ к данным в виде информационных панелей или через веб-сайт компании. Случайные пользователи. Повседневные пользователи в основном используют статические отчеты и портлеты. Oни требуют простоты использования и обычно предпочитают работать с автономными приложениями, например в excel. Бизнес-пользователи: обычно принадлежат к среднему уровню управления. Их больше интересуют панели мониторинга и другие статические типы отчетов. Бизнес-пользователи участвуют в принятии тактических и стратегических решений. Продвинутые пользователи: эти пользователи требуют более высокой функциональности по сравнению с другими типы пользователей. Они понимают окружающую среду, знакомы с данными инструменты анализа и удобны в сложных приложениях. ИТ-пользователи: ИТ-пользователи несут ответственность за создание отчетов для бизнеса. ЭТО пользователи работают с расширенными приложениями для отчетов, такими как программное обеспечение комплекты разработки (SDK) и программное обеспечение для интеллектуального анализа данных. Они понимают ИТ окружающей среды и удобно взаимодействовать с несколькими гетерогенных источников данных.
- Поиск и группировка продуктов с наибольшим и наименьшим количеством продаж.
- Сначала выбирается магазин, потом добавляется другое измерение – даты, анализ продаж по магазинам и датам Сначала выбирается магазин, потом добавляется продукт, анализ данных по магазинам и продуктам
- Переход по иерархии измерения
- Переход из одного отчета в другой с передачей параметров. Например во второй отчет передается код региона (CA), при этом во втором отчете необходимо иметь входной параметр по региону, который фильтрует данные.
- Переход по иерархии измерения с сохранением уровней.
- Плюс «+» стоит там, где мера может быть отображена в координатах этого измерения н.р. Прооизводство не содержит справочник Контрагента, следовательно «+» не ставится
- В таких таблицах существует колонка «ID родителя» которая содержит ссылку на поле ID той же таблицы
- Несбалансированная иерархия имеет разное кол-во уровней для разных ветвей дерева
- Тип 1 – данные в справочнике всегда соответствуют их значениям в учетной системе, т.е. обновляются полностью Тип 2 – данные в справочнике делятся на актуальные и не актуальные, актуальные данные соответствуют значениям учетной системы в текущий момент времени, неактуальные данные – это данные предыдущих значений. Тип 3 – текущее и предыдущее значение хранятся не в строках как у Тип-а 2, а в соответствующих колонках таблицы (актуальное значение, предыдущее значение)
- Быстро меняющиеся измерения – иногда среди атрибутов большого справочника есть несколько атрибутов, которые меняются достаточно часто н.р. возраст меняется раз в год, вес человека может меняться еще чаще. Если создавать такой справочник по типу 2 медленно меняющейся размерности, то придется хранить слишком много срок всей таблицы, отслеживая каждое изменение этих атрибутов. Если хранить по типу 1 или 3 медленно меняющейся размерности, то потеряем информацию для анализа данных.
- Правильным решением будет преобразовать такой справочник, разделив его на две части, выводя атрибуты, которые меняются чаще остальных в отдельную таблицу. При этом нужно не забыть создать в таблице фактов для этого измерения соответствующий суррогатный ключ.
- На схеме слева измерение Customer (покупатель) содержит географические данные – данные о стране. Если бизнес-пользователям необходимо проводить анализ данных отдельно по странам без связи с покупателями, то правильно – выносить эти данные из таблицы покупатель в отдельную таблицу – страны.
- Ролевое измерение – одна и та же таблица справочник, которая имеет несколько логических ролей для бизнес-анализа, например одна таблица календарь может отвечать за даты заказов, за даты отгрузки и за даты доставки заказа покупателю
- Измерение со множеством значений. Например заказ покупателя хранится в таблице заказов одной строчкой, но этой строчке соответствует некоторое ко-во торговых представителей (измерение торговый представитель), которые участвовали в формировании этого заказа. Для того, что бы данные в заказах не размножались по кол-ву торговых представителей необходимо в модель данных добавить таблицу-мост, которая развяжет список торговых представителей и строку заказа.
- Одно и тоже измерение для разных типов одного и того же бизнес-процесса имеет разный набор атрибутов, например страховой продукт КАСКО и ОСАГО.
- Измерение с горячей заменой. Справочник меняет набор данных в зависимости от контента запрашиваемых данных. Заказ-наряд автосервиса содержит данные о запчастях и работах.
- Неправильное определение ядра может повлечь за собой в дальнейшем полную переделку модели данных