Многомерные и кубические модели данных разработки

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

В этой модели более тысячи столбцов, поэтому она хорошо подходит для добавления или удаления дополнительных столбцов. Вот действительно хороший блог об этом дизайне: http://garrettedmondson.wordpress.com/2011/10/26/diversity-modeling-financial-data-in-ssas/

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

Вопросы: Относится ли этот дизайн к категории Entity-Attribute-Value (EAV)?

Будет ли дизайн с использованием нескольких таблиц фактов лучше? Очень много широких таблиц фактов (до 10) до 200-300 столбцов в каждой, но меньше строк.

Должен ли я ожидать больше проблем с производительностью с гораздо более широкими таблицами?


person user2704501    schedule 28.08.2013    source источник


Ответы (1)


Вы правы, что конкретная конструкция считается моделью EAV.

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

Я бы не рекомендовал использовать один столбец для каждой меры. Большая часть учетной записи будет нулевой в большинстве строк. Кроме того, при таком дизайне вам необходимо прочитать все ваши меры, даже если вам нужно получить только одну из них.

Мы активно используем измерение счетов в наших кубах. К сожалению, такие вещи, как общие члены, не так просто обрабатывать в SSAS, как в Essbase.

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

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

Общие элементы и все наши формулы реализованы как настраиваемые элементы объединения.

person ebayindir    schedule 02.09.2013
comment
Спасибо. Цените время. - person user2704501; 09.09.2013