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

Размерное моделирование (DM) является частью Жизненный цикл бизнес-измерений методология разработана Ральф Кимбалл который включает в себя набор методов, техник и концепций для использования в хранилище данных дизайн.[1]:1258–1260[2] Подход направлен на определение ключевых бизнес-процессов в рамках бизнеса, моделирование и их реализацию, прежде чем добавлять дополнительные бизнес-процессы, восходящий подход.[1]:1258–1260 Альтернативный подход от Инмон выступает за построение модели всех корпоративных данных сверху вниз с использованием таких инструментов, как моделирование сущности-отношения (ER).[1]:1258–1260

Описание

В размерном моделировании всегда используются понятия фактов (мер) и измерений (контекста). Факты обычно (но не всегда) представляют собой числовые значения, которые можно агрегировать, а измерения - это группы иерархий и дескрипторов, которые определяют факты. Например, сумма продаж - это факт; timestamp, product, register #, store # и т. д. являются элементами измерений. Размерные модели строятся по областям бизнес-процессов, например продажи магазина, товарно-материальные запасы, претензии и т. д. Поскольку различные области бизнес-процессов имеют некоторые, но не все измерения, эффективность проектирования, работы и согласованности достигается с помощью соответствующие размеры, т. е. использование одной копии общего измерения в предметных областях.[нужна цитата ]

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

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

Разработка модели

Размерная модель построена на звездообразная схема или же схема снежинки, с измерениями, окружающими таблицу фактов.[3][4] Для построения схемы используется следующая модель проекта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества размерной модели следующие:[6]

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

Рекомендации

  1. ^ а б c Коннолли, Томас; Бегг, Кэролайн (26 сентября 2014 г.). Системы баз данных - практический подход к проектированию, внедрению и управлению (6-е изд.). Пирсон. Часть 9 Бизнес-аналитика. ISBN  978-1-292-06118-4.
  2. ^ Муди, Дэниел Л .; Кортинк, Марк А. «От моделей предприятия к многомерным моделям: методология построения хранилищ данных и витрин данных» (PDF). Размерное моделирование. В архиве (PDF) из оригинала 17 мая 2017 г.. Получено 3 июля 2018.
  3. ^ Ральф Кимбалл; Марджи Росс; Уоррен Торнтвейт; Джой Манди (10 января 2008 г.). Набор инструментов для жизненного цикла хранилища данных: экспертные методы проектирования, разработки и развертывания хранилищ данных (Второе изд.). Вайли. ISBN  978-0-470-14977-5.
  4. ^ а б c Маттео Гольфарелли; Стефано Рицци (26 мая 2009 г.). Дизайн хранилища данных: современные принципы и методологии. McGraw-Hill Osborne Media. ISBN  978-0-07-161039-1.
  5. ^ Ральф Кимбалл; Марджи Росс (26 апреля 2002 г.). Набор инструментов хранилища данных: полное руководство по размерному моделированию (Второе изд.). Вайли. ISBN  0-471-20024-7.
  6. ^ Ральф Кимбалл; Марджи Росс; Уоррен Торнтвейт; Джой Манди; Боб Беккер (январь 2008 г.). Набор инструментов для жизненного цикла хранилища данных (Второе изд.). Вайли. ISBN  978-0-470-14977-5.