Размерное моделирование

Многомерное моделирование ( DM ) является частью методологии Business Dimensional Lifecycle, разработанной Ральфом Кимбаллом , которая включает в себя набор методов, приемов и концепций для использования при проектировании хранилищ данных . Этот подход фокусируется на выявлении ключевых бизнес-процессов внутри бизнеса, их моделировании и реализации в первую очередь, прежде чем добавлять дополнительные бизнес-процессы, как подход «снизу вверх» . Альтернативный подход от Inmon предполагает разработку модели всех корпоративных данных сверху вниз с использованием таких инструментов, как моделирование сущностей и связей (ER).

Описание

Многомерное моделирование всегда использует концепции фактов (мер) и измерений (контекста). Факты обычно (но не всегда) представляют собой числовые значения, которые можно агрегировать, а измерения — это группы иерархий и дескрипторов, которые определяют факты. Например, объем продаж является фактом; отметка времени, продукт, номер регистра, номер магазина и т. д. являются элементами измерений. Многомерные модели строятся по областям бизнес-процессов, например, продажи в магазинах, запасы, претензии и т. д. Поскольку разные области бизнес-процессов имеют общие некоторые, но не все измерения, эффективность проектирования, эксплуатации и согласованность достигаются с использованием согласованных измерений , т. е. с использованием одного копия общего измерения по предметным областям.

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

Метод проектирования

Проектирование модели

Многомерная модель построена на основе звездообразной схемы или схемы снежинки с измерениями, окружающими таблицу фактов. Для построения схемы используется следующая модель проектирования:

1. Выберите бизнес-процесс
2. Объявить зерно
3. Определите размеры
4. Определите факт

Выберите бизнес-процесс

Процесс многомерного моделирования основан на четырехэтапном методе проектирования, который помогает обеспечить удобство использования многомерной модели и использования хранилища данных . Основы проектирования основаны на реальных бизнес-процессах, которые должно охватывать хранилище данных . Поэтому первым шагом в модели является описание бизнес-процесса, на котором строится модель. Например, это может быть ситуация с продажами в розничном магазине. Чтобы описать бизнес-процесс, можно сделать это в виде обычного текста или использовать базовую модель и нотацию бизнес-процессов (BPMN) или другие руководства по проектированию, такие как унифицированный язык моделирования |UML).

Объявить зерно

После описания бизнес-процесса следующим шагом в проектировании является объявление структуры модели. Зерно модели — это точное описание того, на чем должна быть сосредоточена многомерная модель. Например, это может быть «Отдельная позиция в чеке покупателя из розничного магазина». Чтобы прояснить, что означает зерно, следует выбрать центральный процесс и описать его одним предложением. Более того, зерно (предложение) — это то, на основе чего вы собираетесь построить свои измерения и таблицу фактов. Возможно, вам придется вернуться к этому шагу, чтобы изменить зернистость, поскольку получена новая информация о том, что ваша модель должна обеспечить.

Определите размеры

Третий шаг в процессе проектирования — определение размеров модели. Размеры должны быть определены внутри зерна на втором этапе 4-этапного процесса. Измерения являются основой таблицы фактов и местом сбора данных для таблицы фактов. Обычно измерениями являются существительные, такие как дата, магазин, инвентарь и т. д. В этих измерениях хранятся все данные. Например, измерение даты может содержать такие данные, как год, месяц и день недели.

Определите факты

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

Нормализация размеров

Нормализация размеров или «снежинка» удаляет избыточные атрибуты, которые известны в обычном сглаживании денормализованных измерений. Размеры строго соединены между собой в подразмерах.

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

Разработчики часто не нормализуют размеры по нескольким причинам:

1. Нормализация делает структуру данных более сложной.
2. Производительность может снизиться из-за большого количества соединений между таблицами.
3. Экономия места минимальна
4. Растровые индексы использовать нельзя.
5. Производительность запроса. Базы данных 3NF страдают от проблем с производительностью при агрегировании или извлечении множества размерных значений, которые могут потребовать анализа. Если вы собираетесь составлять только оперативные отчеты, возможно, вам удастся обойтись 3NF, поскольку ваш оперативный пользователь будет искать очень мелкие данные.

Есть несколько аргументов в пользу того, почему нормализация может быть полезна. Это может быть преимуществом, если часть иерархии является общей для более чем одного измерения. Например, географическое измерение можно использовать повторно, поскольку оно используется как в измерениях «Клиент», так и в «Поставщик».

Преимущества размерного моделирования

Преимущества размерной модели заключаются в следующем:

• Понятность. По сравнению с нормализованной моделью размерная модель проще для понимания и более интуитивно понятна. В многомерных моделях информация группируется в последовательные бизнес-категории или измерения, что упрощает ее чтение и интерпретацию. Простота также позволяет программному обеспечению эффективно перемещаться по базам данных. В нормализованных моделях данные разделены на множество дискретных объектов, и даже простой бизнес-процесс может привести к тому, что десятки таблиц будут объединены сложным образом.
• Производительность запроса. Размерные модели более денормализованы и оптимизированы для запроса данных, тогда как нормализованные модели стремятся устранить избыточность данных и оптимизированы для загрузки и обновления транзакций. Предсказуемая структура многомерной модели позволяет базе данных делать серьезные предположения о данных, которые могут оказать положительное влияние на производительность. Каждое измерение является эквивалентной точкой входа в таблицу фактов, и эта симметричная структура позволяет эффективно обрабатывать сложные запросы. Оптимизация запросов для баз данных, объединенных звездой, проста, предсказуема и контролируема.
• Расширяемость. Размерные модели масштабируемы и легко вмещают неожиданные новые данные. Существующие таблицы можно изменить на месте, просто добавив в них новые строки данных или выполнив команды изменения таблицы SQL. Никакие запросы или приложения, расположенные поверх хранилища данных, не нужно перепрограммировать для внесения изменений. Старые запросы и приложения продолжают выполняться, не принося других результатов. Но в нормализованных моделях каждую модификацию следует рассматривать внимательно из-за сложных зависимостей между таблицами базы данных.

Многомерные модели, Hadoop и большие данные

Мы по-прежнему получаем преимущества многомерных моделей в Hadoop и аналогичных средах обработки больших данных . Однако некоторые особенности Hadoop требуют от нас немного адаптировать стандартный подход к многомерному моделированию.

• Файловая система Hadoop является неизменяемой . Мы можем только добавлять, но не обновлять данные. В результате мы можем только добавлять записи в таблицы измерений. Медленное изменение измерений в Hadoop становится поведением по умолчанию. Чтобы получить самую последнюю и актуальную запись в таблице измерений, у нас есть три варианта. Во-первых, мы можем создать представление , которое извлекает последнюю запись с помощью оконных функций . Во-вторых, мы можем запустить в фоновом режиме службу сжатия, которая воссоздает последнее состояние. В-третьих, мы можем хранить наши таблицы измерений в изменяемом хранилище, например HBase, и объединять запросы в двух типах хранилища.
• Способ распределения данных по HDFS делает объединение данных дорогостоящим. В распределенной реляционной базе данных ( MPP ) мы можем размещать записи с одинаковыми первичными и внешними ключами на одном узле кластера. Это делает объединение очень больших таблиц относительно дешевым. Для выполнения соединения данные не должны передаваться по сети. В Hadoop и HDFS это сильно отличается. Таблицы HDFS разбиваются на большие куски и распределяются по узлам нашего кластера. У нас нет никакого контроля над тем, как отдельные записи и их ключи распределяются по кластеру. В результате соединения в Hadoop двух очень больших таблиц обходятся довольно дорого, поскольку данные должны перемещаться по сети. Нам следует избегать соединений, где это возможно. Для большой таблицы фактов и измерений мы можем денормализовать таблицу измерений непосредственно в таблицу фактов. Для двух очень больших таблиц транзакций мы можем вложить записи дочерней таблицы в родительскую таблицу и выровнять данные во время выполнения.

Литература

• Кимбалл, Ральф ; Марджи Росс (2013). Инструментарий хранилища данных: полное руководство по размерному моделированию (3-е изд.). Уайли. ISBN  978-1-118-53080-1 .
• Ральф Кимбалл (1997). «Манифест пространственного моделирования» . СУБД и Интернет-системы . 10 (9).
• Марджи Росс (Kimball Group) (2005). «Идентификация бизнес-процессов» . Kimball Group, Советы по дизайну (69). Архивировано из оригинала 12 июня 2013 года.