Размерное моделирование (DM) является частью методологии Business Dimensional Lifecycle, разработанной Ральфом Кимбаллом, которая включает в себя набор методов, техник и концепций для использования при проектировании хранилищ данных . [1] : 1258–1260 [2] Подход направлен на определение ключевых бизнес-процессов в рамках бизнеса, моделирование и их внедрение, прежде чем добавлять дополнительные бизнес-процессы, восходящий подход. [1] : 1258–1260 Альтернативный подход от Inmon поддерживает проектирование модели всех корпоративных данных сверху вниз с использованием таких инструментов, как моделирование сущности-отношения.(ER). [1] : 1258–1260
Описание
В размерном моделировании всегда используются понятия фактов (мер) и измерений (контекста). Факты обычно (но не всегда) представляют собой числовые значения, которые можно агрегировать, а измерения - это группы иерархий и дескрипторов, которые определяют факты. Например, сумма продаж - это факт; timestamp, product, register #, store # и т. д. являются элементами измерений. Размерные модели строятся по областям бизнес-процессов, например, продажам в магазинах, запасам, заявкам и т. Д. Поскольку разные области бизнес-процессов имеют общие измерения, но не все, эффективность проектирования, работы и согласованности достигается с помощью согласованных измерений , т. Е. Использования одного. копия общего измерения по предметным областям. [ необходима цитата ]
Размерное моделирование не обязательно требует реляционной базы данных. Тот же подход к моделированию на логическом уровне может использоваться для любой физической формы, такой как многомерная база данных или даже плоские файлы. Он ориентирован на понятность и производительность. [ необходима цитата ]
Метод проектирования
Проектирование модели
Размерная модель построена на звездообразной схеме или схеме снежинки с измерениями, окружающими таблицу фактов. [3] [4] Для построения схемы используется следующая модель проекта:
- Выберите бизнес-процесс
- Объявите зерно
- Определите размеры
- Определите факт
- Выберите бизнес-процесс
Процесс размерного моделирования основан на четырехэтапном методе проектирования, который помогает обеспечить удобство использования размерной модели и использование хранилища данных . Основы проектирования основаны на реальном бизнес-процессе, который должно охватывать хранилище данных . Следовательно, первым шагом в модели является описание бизнес-процесса, на котором она построена. Это может быть, например, ситуация с продажами в розничном магазине. Чтобы описать бизнес-процесс, можно сделать это в виде обычного текста или использовать базовую нотацию моделирования бизнес-процессов ( BPMN ) или другие руководства по проектированию, такие как унифицированный язык моделирования ( UML ).
- Объявите зерно
Следующим шагом после описания бизнес-процесса является объявление структуры модели. Структура модели - это точное описание того, на чем должна фокусироваться размерная модель. Это может быть, например, «Отдельная позиция в квитанции покупателя из розничного магазина». Чтобы прояснить, что означает зерно, вы должны выбрать центральный процесс и описать его одним предложением. Кроме того, зерно (предложение) - это то, из чего вы собираетесь построить свои измерения и таблицу фактов. Возможно, вы сочтете необходимым вернуться к этому шагу, чтобы изменить зернистость из-за полученной новой информации о том, что ваша модель должна обеспечивать.
- Определите размеры
Третий шаг в процессе проектирования - определение размеров модели. Размеры должны быть определены в пределах зерна на втором этапе 4-этапного процесса. Измерения являются основой таблицы фактов и местом сбора данных для таблицы фактов. Обычно измерения - это такие существительные, как дата, магазин, инвентарь и т. Д. В этих измерениях хранятся все данные. Например, измерение даты может содержать такие данные, как год, месяц и день недели.
- Определите факты
Следующим шагом после определения измерений является создание ключей для таблицы фактов. Этот шаг предназначен для определения числовых фактов, которые будут заполнять каждую строку таблицы фактов. Этот шаг тесно связан с бизнес-пользователями системы, поскольку именно здесь они получают доступ к данным, хранящимся в хранилище данных . Поэтому большинство строк таблицы фактов представляют собой числовые, аддитивные цифры, такие как количество или стоимость за единицу и т. Д.
Нормализация размеров
Нормализация размеров или "снежинка" удаляет избыточные атрибуты, которые известны в обычных плоских ненормализованных измерениях. Размеры строго объединены во вспомогательные размеры.
Снежинка влияет на структуру данных, что отличается от многих концепций хранилищ данных. [4] Единая таблица данных (фактов), окруженная множеством описательных таблиц (измерений).
Разработчики часто не нормализуют размеры по нескольким причинам: [5]
- Нормализация усложняет структуру данных
- Производительность может быть ниже из-за большого количества объединений между таблицами.
- Экономия места минимальна
- Индексы Bitmap использовать нельзя
- Производительность запроса. Базы данных 3NF страдают от проблем с производительностью при агрегировании или извлечении множества размерных значений, которые могут потребовать анализа. Если вы собираетесь составлять только операционные отчеты, вы можете обойтись с 3NF, потому что ваш оперативный пользователь будет искать очень точные данные.
Есть несколько аргументов в пользу того, почему нормализация может быть полезной. [4] Это может быть преимуществом, когда часть иерархии является общей для более чем одного измерения. Например, географическое измерение может быть повторно использовано, потому что его используют и измерения клиента, и поставщика.
Преимущества размерного моделирования
Преимущества размерной модели следующие: [6]
- Понятность. По сравнению с нормализованной моделью, размерная модель проще для понимания и более интуитивно понятна. В размерных моделях информация сгруппирована в связанные бизнес-категории или измерения, что упрощает чтение и интерпретацию. Простота также позволяет программному обеспечению эффективно перемещаться по базам данных. В нормализованных моделях данные делятся на множество дискретных сущностей, и даже простой бизнес-процесс может привести к сложному объединению десятков таблиц.
- Производительность запроса. Размерные модели более денормализованы и оптимизированы для запросов данных, в то время как нормализованные модели стремятся устранить избыточность данных и оптимизированы для загрузки и обновления транзакций. Предсказуемая структура размерной модели позволяет базе данных делать строгие предположения о данных, которые могут положительно повлиять на производительность. Каждое измерение является эквивалентной точкой входа в таблицу фактов, и эта симметричная структура позволяет эффективно обрабатывать сложные запросы. Оптимизация запросов для баз данных, соединенных звездой, проста, предсказуема и управляема.
- Расширяемость. Размерные модели масштабируемы и легко учитывают неожиданные новые данные. Существующие таблицы можно изменить на месте, просто добавив в таблицу новые строки данных или выполнив команды изменения таблицы SQL. Никакие запросы или приложения, которые находятся в верхней части хранилища данных, не нуждаются в перепрограммировании с учетом изменений. Старые запросы и приложения продолжают выполняться, не давая других результатов. Но в нормализованных моделях следует тщательно продумывать каждую модификацию из-за сложных зависимостей между таблицами базы данных.
Размерные модели, Hadoop и большие данные
Мы по-прежнему пользуемся преимуществами многомерных моделей в Hadoop и аналогичных платформах больших данных . Однако некоторые функции Hadoop требуют от нас некоторой адаптации стандартного подхода к размерному моделированию. [ необходима цитата ]
- Система Hadoop Файл является непреложным . Мы можем только добавлять, но не обновлять данные. В результате мы можем только добавлять записи в таблицы измерений. Медленное изменение размеров в Hadoop становится поведением по умолчанию. Чтобы получить самую свежую и актуальную запись в таблице измерений, у нас есть три варианта. Во- первых, мы можем создать View , который извлекает последний запись , используя Windowing функции . Во-вторых, у нас может быть служба уплотнения, работающая в фоновом режиме, которая воссоздает последнее состояние. В-третьих, мы можем хранить наши таблицы измерений в изменяемом хранилище, например 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 года .
Рекомендации
- ^ а б в Коннолли, Томас; Бегг, Кэролайн (26 сентября 2014 г.). Системы баз данных - Практический подход к проектированию, внедрению и управлению (6-е изд.). Пирсон. Часть 9 Бизнес-аналитика. ISBN 978-1-292-06118-4.
- ^ Муди, Дэниел Л .; Кортинк, Марк А.Р. «От моделей предприятия к многомерным моделям: методология построения хранилищ данных и витрин данных» (PDF) . Размерное моделирование. Архивировано 17 мая 2017 года (PDF) из оригинала . Проверено 3 июля 2018 .
- ^ Ральф Кимбалл; Марджи Росс; Уоррен Торнтуэйт; Джой Манди (10 января 2008 г.). Набор средств жизненного цикла хранилища данных: экспертные методы проектирования, разработки и развертывания хранилищ данных (второе изд.). Вайли. ISBN 978-0-470-14977-5.
- ^ а б в Маттео Гольфарелли; Стефано Рицци (26 мая 2009 г.). Дизайн хранилища данных: современные принципы и методологии . McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1.
- ^ Ральф Кимбалл; Марджи Росс (26 апреля 2002 г.). Набор инструментов хранилища данных: полное руководство по размерному моделированию (второе изд.). Вайли. ISBN 0-471-20024-7.
- ^ Ральф Кимбалл; Марджи Росс; Уоррен Торнтуэйт; Джой Манди; Боб Беккер (январь 2008 г.). Инструментарий жизненного цикла хранилища данных (второе изд.). Вайли. ISBN 978-0-470-14977-5.