Проектирование аналитического хранилища данных

Аналитические хранилища данных (АХД)

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

Проектирование АХД – классификация первичных данных с последующим определением списка кубов, общих размерностей, мер, локальных размерностей, иерархий, уровней и атрибутов.
На начальном этапе проектирования настоятельно рекомендуется создать ER-модель. Это модель данных, позволяющая описывать концептуальные схемы предметной области. В ней моделирование структуры данных предметной области базируется на использовании графических средств - ER-диаграмм (диаграмм сущность-связь). Это позволяет выделить ключевые сущности и их связи.

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

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

Без заголовка

                         Пример ER-диаграммы

Пример разработки простой ER-модели

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

Основные действия системы включают:

  • Хранение информации о покупателях.
  • Печать накладных на товары.
  • Мониторинг наличия товаров на складе.

Выделим потенциальные сущности и атрибуты:

  • Сущности: Покупатель, Накладная, Товар, Склад (возможно, новая сущность, если складов несколько).
  • Атрибуты: Наличие товара (атрибут, но какой сущности?).

Существует связь: покупатели могут приобретать множество товаров, а товары могут продаваться многим покупателям. Первый вариант диаграммы выглядит так:

2

Уточнив информацию, выяснили, что фирма имеет несколько складов, и каждый товар может храниться на нескольких из них.

Куда поместить сущности “Накладная” и “Склад” и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями “Покупатель” и “Товар”? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:

3

Пора подумать об атрибутах сущностей:

  • Покупатель: наименование, адрес, банковские реквизиты.
  • Товар: наименование, цена, единица измерения.
  • Накладная: уникальный номер, дата, список товаров с количествами и ценами, общая сумма.
  • Склад: наименование.

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

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

Понятие “Список товаров в накладной” связано с сущностями “Накладная” и “Товар”, которые имеют отношение много-ко-многим. Для упрощения этой связи вводится дополнительная сущность “Список товаров в накладной”. Она характеризуется следующими связями: каждая накладная содержит несколько записей, каждая запись относится к одной накладной, каждый товар может быть в нескольких записях, и каждая запись связана с одним товаром. Атрибуты этой сущности включают “Количество товара в накладной” и “Цена товара в накладной”.

Аналогично, для связи между сущностями “Склад” и “Товар” вводится сущность “Товар на складе” с атрибутом “Количество товара на складе”, что позволяет учитывать количество каждого товара на разных складах.

Теперь можно внести все это в диаграмму:

4

Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы

Пример проектирования куба

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

В другой таблице хранится информация о товаре.
Таблица 2 – Товары
6

Внутреннюю структуру хранения данных можно представить в следующем виде:
Снимок экрана 2024-12-04 в 17.11.15

Рассмотрим схему на примере куба Отгрузка.

В АХД может одновременно храниться множество кубов с общими измерениями, например, в нашем случае размерности Товар и Период, что упрощает создание кубов и ускоряет обработку запросов.

Размерности могут быть простыми или содержать дополнительные столбцы, называемые атрибутами. Например, размерность Клиент включает поля Наименование клиента и Номер счета как атрибут. В размерности Товар атрибутами могут быть Вес, Ширина и другие.
Размерности Товар и Клиент являются иерархическими.

Иерархии в свою очередь могут быть сбалансированными и несбалансированными.
Сбалансированной называется иерархия, где все ветви иерархии опускаются до одного уровня, и логическим «родителем» каждого элемента является уровень непосредственно над элементом. Например, последним уровнем иерархии Контрагенты может быть только клиент, и каждый клиент обязательно относится к одной из категорий клиентов.

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

Мерами данного куба будут числовые показатели - Количество, Сумма к оплате и Наценка.
Графически эти данные можно представить в многомерном пространстве следующим образом:

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

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

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

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