Аналитические хранилища данных (АХД)
Аналитические хранилища данных (АХД) предназначены для предоставления пользователям информации, необходимой для статистического анализа и принятия управленческих решений.
Проектирование АХД – классификация первичных данных с последующим определением списка кубов, общих размерностей, мер, локальных размерностей, иерархий, уровней и атрибутов.
На начальном этапе проектирования настоятельно рекомендуется создать ER-модель. Это модель данных, позволяющая описывать концептуальные схемы предметной области. В ней моделирование структуры данных предметной области базируется на использовании графических средств - ER-диаграмм (диаграмм сущность-связь). Это позволяет выделить ключевые сущности и их связи.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность – объект предметной области, имеющий атрибуты. Класс однотипных объектов, информация о которых должна сохраняться и быть доступна.
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Процесс создания ER-диаграмм итеративен: после первоначального варианта диаграммы уточняются данные с помощью опросов экспертов предметной области. Это позволяет детализировать хранилище данных, определяя сущности, их свойства и отношения.
Пример ER-диаграммы
Пример разработки простой ER-модели
Предположим, что перед нами стоит задача разработать АХД по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней.
Основные действия системы включают:
- Хранение информации о покупателях.
- Печать накладных на товары.
- Мониторинг наличия товаров на складе.
Выделим потенциальные сущности и атрибуты:
- Сущности: Покупатель, Накладная, Товар, Склад (возможно, новая сущность, если складов несколько).
- Атрибуты: Наличие товара (атрибут, но какой сущности?).
Существует связь: покупатели могут приобретать множество товаров, а товары могут продаваться многим покупателям. Первый вариант диаграммы выглядит так:
Уточнив информацию, выяснили, что фирма имеет несколько складов, и каждый товар может храниться на нескольких из них.
Куда поместить сущности “Накладная” и “Склад” и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями “Покупатель” и “Товар”? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Пора подумать об атрибутах сущностей:
- Покупатель: наименование, адрес, банковские реквизиты.
- Товар: наименование, цена, единица измерения.
- Накладная: уникальный номер, дата, список товаров с количествами и ценами, общая сумма.
- Склад: наименование.
Некоторые атрибуты требуют уточнения, например, цена товара может отличаться от цены в накладной. Также необходимо выделить список товаров в накладной в отдельную сущность.
В итоге, каждый товар имеет текущую цену, которая может меняться со временем и различаться в разных накладных.
Понятие “Список товаров в накладной” связано с сущностями “Накладная” и “Товар”, которые имеют отношение много-ко-многим. Для упрощения этой связи вводится дополнительная сущность “Список товаров в накладной”. Она характеризуется следующими связями: каждая накладная содержит несколько записей, каждая запись относится к одной накладной, каждый товар может быть в нескольких записях, и каждая запись связана с одним товаром. Атрибуты этой сущности включают “Количество товара в накладной” и “Цена товара в накладной”.
Аналогично, для связи между сущностями “Склад” и “Товар” вводится сущность “Товар на складе” с атрибутом “Количество товара на складе”, что позволяет учитывать количество каждого товара на разных складах.
Теперь можно внести все это в диаграмму:
Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы
Пример проектирования куба
Пусть во внешнем источнике хранится информация об отгрузках, представленная следующей таблицей.
Таблица 1 – Отгрузка товаров
В другой таблице хранится информация о товаре.
Таблица 2 – Товары
Внутреннюю структуру хранения данных можно представить в следующем виде:
Рассмотрим схему на примере куба Отгрузка.
В АХД может одновременно храниться множество кубов с общими измерениями, например, в нашем случае размерности Товар и Период, что упрощает создание кубов и ускоряет обработку запросов.
Размерности могут быть простыми или содержать дополнительные столбцы, называемые атрибутами. Например, размерность Клиент включает поля Наименование клиента и Номер счета как атрибут. В размерности Товар атрибутами могут быть Вес, Ширина и другие.
Размерности Товар и Клиент являются иерархическими.
Иерархии в свою очередь могут быть сбалансированными и несбалансированными.
Сбалансированной называется иерархия, где все ветви иерархии опускаются до одного уровня, и логическим «родителем» каждого элемента является уровень непосредственно над элементом. Например, последним уровнем иерархии Контрагенты может быть только клиент, и каждый клиент обязательно относится к одной из категорий клиентов.
В несбалансированной иерархии количество уровней может быть разным, и конечный элемент иерархии может быть на любом из уровней.
Несбалансированной, в нашем случае, будет иерархия размерности Товар.
Мерами данного куба будут числовые показатели - Количество, Сумма к оплате и Наценка.
Графически эти данные можно представить в многомерном пространстве следующим образом:
Для работы с многомерными данными необходимы специальные знания, и здесь на помощь приходит язык многомерных выражений - MDX. Он позволяет формулировать сложные запросы, агрегировать данные и анализировать их по различным измерениям.
Если вы хотите узнать больше о языке MDX и его терминах, рекомендуем ознакомиться с материалами по ссылке для более глубокого понимания использования кубов данных.
OLAP кубы — удобный инструмент для анализа многомерных данных, позволяющий быстро извлекать полезную информацию оперируя различными срезами. Они организуют данные в многомерном пространстве, что упрощает выполнение сложных аналитических операций.
При проектировании АХД можно столкнуться с рядом неочевидных подходов, которые могут негативно сказаться на производительности и качестве анализа данных. Для более подробного изучения стандартных ошибок при проектировании кубов и методов их предотвращения, вы можете ознакомиться с дополнительными материалами по ссылке.
Проектирование АХД - фундаментальный процесс подготовки данных, от которого напрямую зависит скорость выполнения аналитических запросов, требуемые аппаратные мощности и разнообразие возможных ad-hoc операций.