Освоение многомерного моделирования для успешного хранения данных

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

В начале 1990-х годов Ральф Кимбалл, видный деятель, когда дело дошло до подходы к хранилищу данных, разработал принципы размерного моделирования. Его книга «Инструментарий для хранилищ данных», впервые опубликованная в 1996 году, изложила концепции и лучшие практики многомерного моделирования. Подход Кимбалла был сосредоточен на моделировании данных таким образом, чтобы они соответствовали бизнес-процессам и требованиям пользователей, уделяя особое внимание простоте и удобству использования.

В этой статье мы углубимся в концепции размерных моделирование данных и понять его процессы, преимущества и ограничения.

Что такое многомерная модель данных?

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

Различные приложения требуют разных методов многомерного моделирования. В основном существует два метода моделирования: нормализованные модели «сущность-связь» (модели ER) и размерное моделирование.

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

Напротив, многомерные модели или модели многомерных данных Кимбалла представляют собой денормализованные структуры, предназначенные для извлечения данных из информационное хранилище. Они используют таблицы фактов и измерений для хранения исторических данных в хранилищах данных. Более того, они оптимизированы для выполнения Выберите и используются в базовой среде проектирования для создания высокооптимизированных и функциональных хранилищ данных.

Автоматизируйте задачи ручного проектирования и сократите время проектирования размерных моделей на 80 %.

Бесплатная пробная версия 14-Day

Элементы, участвующие в размерном моделировании

Таблицы фактов или бизнес-показатели

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

Таблица 1. Типы фактов в таблице фактов

Типы фактов, объясненные с помощью многомерной модели данных

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

Таблица 2. Таблица транзакций, поддерживаемая магазином одежды

Столбцы, содержащие числовую информацию о бизнес-процессе, являются нашими бизнес-фактами. В этом примере Количество, Цена за ед, Объем продаж, Каталогкачества Налог с продаж являются фактами. А остальные сущности(Время, Магазинкачества Категория) — размеры.

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

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

Пошаговое руководство

Таблицы размеров

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

Рисунок 1. Схема «звезда» с таблицами фактов и измерений.

Основной ключ

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

Внешний ключ

Внешние ключи соединяют две таблицы (обычно таблицы фактов и измерений). Первичный ключ в таблице измерений является внешним ключом в связанной таблице фактов и используется для ссылки на это конкретное измерение.

Пример моделирования размерных данных

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

1. Факты: Основными фактами в этом сценарии будут операции купли-продажи. Эти факты будут включать в себя такие данные, как:

• Доход от продаж
• Количество проданной продукции
• Скидки применяются
• Прибыли

2. Габаритные размеры:: Различные измерения будут обеспечивать контекст данных о продажах:

• Измерение времени: это измерение может включать такие атрибуты, как год, квартал, месяц, день и даже время суток. Например, это могло бы помочь ответить на такие вопросы, как: «Каковы были наши продажи в каждом квартале прошлого года?»
• Размер продукта: Оно могло бы описывать товары, продаваемые в магазинах. Он может включать такие атрибуты, как категория продукта, бренд и название продукта. Например, это может помочь ответить на такие вопросы, как «Какая категория продуктов принесла наибольший доход?»
• Размер магазина: может содержать информацию об отдельных местоположениях магазинов, например название магазина, город, штат и менеджера магазина. Он мог бы отвечать на такие вопросы, как: «В каком магазине в прошлом месяце были самые высокие продажи?»
• Измерение клиента: Это может дать представление о демографических характеристиках клиентов, таких как возраст, пол и местоположение. Это может помочь ответить на такие вопросы, как: «Какова средняя сумма покупки на сегмент клиентов?»

3. Отношения фактов и измерений: таблица фактов, содержащая транзакции продаж, будет иметь внешние ключи, связывающие ее с таблицами измерений. Например, каждая запись транзакции продажи может иметь внешние ключи, указывающие на соответствующее время, продукт, магазин и клиента в соответствующих таблицах измерений.
4. Иерархии: Иерархии внутри измерений помогут пользователям перемещаться и анализировать данные на разных уровнях детализации. Например, измерение времени может иметь иерархию, которая идет от года к кварталу, от месяца к дню.
5. меры: Показатели будут рассчитываться на основе фактов продаж, чтобы обеспечить ценную информацию. Например:

• Общая сумма продаж
• Средний процент скидки
• Процент маржи прибыли

Имея эту многомерную модель данных, розничный бизнес может использовать ее для ответа на широкий спектр вопросов, таких как:

• «Каков был наш общий объем продаж по каждой категории продуктов в последнем квартале?»
• «В каком магазине был самый высокий рост продаж по сравнению с аналогичным периодом прошлого года?»
• «Какова средняя норма прибыли для продуктов в каждой товарной категории?»

Проектирование многомерной модели данных

Чтобы понять процесс проектирование объемных моделейДавайте рассмотрим пример линии одежды, которая продает в двух своих магазинах в Калифорнии и Пенсильвании ветровки двух видов — нейлоновые и полиэстеровые. Примерные данные для примера показаны в таблице 2.

Шаг 1. Определите бизнес-процессы

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

Шаг 2. Определите факты и измерения в многомерной модели данных.

Информация в многомерной модели разделена на два типа таблиц: Факты и Габаритные размеры:. Следующим шагом является определение бизнес-фактов, которые вы хотите измерить, и связанных с ними измерений. В нашем примере продажа ветровки — это тот факт, который мы хотим измерить. Дата, местонахождение магазина (Калифорния и Пенсильвания) и тип продукта (нейлоновые ветровки и ветровки из полиэстера) — это параметры, которые дают нам дополнительную информацию о процессе продаж.

Шаг 3. Определите атрибуты измерений

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

Таблица 3: Таблица размеров для даты

Таблица 4: Таблица размеров магазина

Таблица 5: Таблица размеров продукта

Шаг 4. Определите степень детализации бизнес-фактов

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

Шаг 5. Хранение исторической информации (медленно меняющиеся измерения)

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

Узнайте больше о разработке автоматизированного размерного моделирования с помощью нашего пошагового руководства

Что такое многомерная модель данных в хранилище данных?

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

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

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

Размерное моделирование по-прежнему остается наиболее часто используемым методом моделирования данных при проектировании корпоративных хранилищ данных из-за преимуществ, которые оно дает. К ним относятся:

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

Более быстрый поиск данных: Моделирование многомерных данных объединяет таблицы в самой модели, что позволяет пользователям быстрее извлекать данные из разных источников данных путем выполнения запросов на соединение. Денормализованная схема хранилища данных многомерной модели вместо нормализованной схемы «снежинка» оптимизирована для выполнения специальных запросов. В результате это значительно дополняет цели бизнес-аналитики (BI) организации.

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

Многомерный анализ: Многомерные модели поддерживают многомерный анализ, поэтому пользователи могут одновременно изучать данные из различных измерений и иерархий.

Уменьшенная избыточность данных: Размерные модели часто включают денормализацию, которая уменьшает избыточность данных и, следовательно, повышает производительность запросов по сравнению с моделями с высокой нормализацией.

Ограничения моделирования измерений

Хотя размерное моделирование является мощным методом для анализа и составления отчетов, оно также имеет некоторые ограничения, и существуют сценарии, в которых он может оказаться не самым подходящим подходом. Поэтому важно оценить, соответствует ли он характеристикам и требованиям ваших данных и вариантам использования. Вот некоторые ограничения размерного моделирования и ситуации, в которых можно рассмотреть альтернативные методы моделирования:

1. Сложные отношения: Многомерное моделирование предполагает, что отношения между измерениями и фактами относительно просты. Если ваши данные содержат очень сложные взаимосвязи, которые невозможно легко представить в виде схемы «звезда» или «снежинка», многомерное моделирование может оказаться не лучшим выбором.
2. Частые изменения данных: многомерные модели предназначены для исторического анализа и могут плохо обрабатывать данные, которые часто меняются или требуют обновления в реальном времени. В таких случаях более подходящей может оказаться транзакционная или нормализованная модель.
3. Разреженные данные: Когда вы имеете дело с данными, в которых многие комбинации измерений не имеют связанных фактов (разреженные данные), многомерные модели могут привести к неэффективному хранению и производительности запросов.
4. Большие и неструктурированные данные: Если ваши данные включают большие объемы неструктурированных или полуструктурированных данных (например, текстовые документы, каналы социальных сетей), одного многомерного моделирования может быть недостаточно. Возможно, вам придется использовать такие методы, как базы данных NoSQL или документо-ориентированные базы данных.

Автоматизация: меняет правила игры в размерном моделировании

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

Создайте свое комплексное хранилище данных без необходимости программирования

Посмотреть демо

Доступно Astera Построитель хранилища данных, вы можете быстро создавать многомерные модели в интегрированной среде разработки без визуального кода. Сущности можно денормализовать простым перетаскиванием и слиянием. Роли сущностей (факты и измерения) можно назначать массово, что экономит ваше драгоценное время при работе с сотнями сущностей. Кроме того, продукт позволяет управлять медленно меняющимися размерами благодаря встроенной поддержке типов SCD 1, 2, 3 и 6.

Astera DW Builder — это комплексная платформа автоматизации хранилища данных со встроенными возможностями многомерного моделирования данных, поддержкой широкого спектра баз данных и приложений CRM, функциями автоматического сопоставления и загрузки данных, а также встроенной интеграцией с платформами бизнес-аналитики, такими как Табло и Power BI.

Читать Astera DW BuiBuilder'smo или подпишитесь на бесплатная пробная версия на собственном опыте ощутить возможности автоматизации хранилищ данных.

Сократите время разработки хранилища данных до 80 %