Вычисляемая мера агрегируется только по определенным ячейкам

Я пытаюсь понять, как я могу создать вычисляемую меру, которая производит подсчет только уникальных фактов в моей таблице фактов. Моя таблица фактов в основном хранит события с исторической точки зрения. Но мне нужна мера для фильтрации избыточных событий.
Использование продаж в качестве примера (Поскольку все материалы по OLAP всегда используют продажи в примерах):

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

Если я создаю меру количества с помощью SSAS, я получаю количество всех событий продаж, что означает, что уникальная продажа будет учитываться несколько раз для каждого изменения. сделал для него (что в некоторых отчетах желательно). Однако мне также нужна мера, которая производит подсчет уникальных продаж, а не событий, но не только на основе подсчета уникальных ссылок на продажи. Если пользователь фильтрует по дате, он должен увидеть уникальные продажи, которые все еще существуют на эту дату (если продажа была отменена к этой дате, она вообще не должна быть представлена ​​в подсчете).

Как мне сделать это в MDX/SSAS? Похоже, мне нужно, чтобы запрос на подсчет работал из подмножества запроса, который находит последние изменения в продаже на основе измерения времени. В SQL это будет что-то вроде:

SELECT COUNT(*) FROM SalesFacts FACT1 WHERE Event <> 'Cancelled' AND
Timestamp = (SELECT MAX(Timestamp) FROM SalesFact FACT2 WHERE FACT1.SalesRef=FACT2.SalesRef)

Возможно ли или эффективно ли иметь подзапросы в MDX?


database sql-server olap ssas cube
person nuit9    schedule 13.03.2011    source источник
comment
Кстати, это неэффективный способ подсчета в SQL. Отдельный подсчет идентификатора события (особенно, если он проиндексирован) был бы намного лучше. Или подход типа "Row_number over...". Вышеописанное умрет при значительных объемах данных.   -  person piers7    schedule 24.03.2011

Ответы (3)


arrow_upward
0
arrow_downward

В службах SSAS создайте меру, основанную на уникальном идентификаторе транзакции (номер продажи или номер заказа), а затем сделайте эту меру агрегатной функцией DistinctCount в окне свойств.

Теперь он должен подсчитывать различные порядковые номера в зависимости от того, в каком срезе измерения он находится.

person Meff    schedule 17.03.2011

arrow_upward
0
arrow_downward

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

SELECT COUNT(DISTINCT SalesRef)
FROM SalesFacts
WHERE Event <> 'Cancelled'
person Andriy M    schedule 17.03.2011

arrow_upward
0
arrow_downward

Простым ответом было бы просто иметь столбец «счетчик продаж» в вашем представлении фактов / запросе dsv, который предоставляет 1 для «начального» события, ноль для всех последующих изменений события и -1, если событие отменено. . Этот «журнальный» подход хорошо сочетается с инкрементной загрузкой таблицы фактов.

Другим подходом, возможно, более полезным в долгосрочной перспективе, было бы наличие измерения «События»: тогда вы могли бы предоставить вычисляемую меру, представляющую собой количество непустых элементов в этом измерении по заданной мере в таблице фактов. Однако для продаж это, по сути, вырожденное измерение (измерение, основанное на таблице фактов) и может стать очень большим. Это может быть неуместно.

Иногда требования могут быть более сложными. Если вы рассчитаете по времени, нужно ли вам знать все отдельные события, которые существовали тогда, даже если они были позже отменены? Это начинает становиться сложным: в блоге Криса Уэбба есть недавняя запись, в которой он рассказывает об одном (слегка волосатом) решении:

http://cwebbbi.wordpress.com/2011/01/22/solving-the-events-in-progress-progress-problem-in-mdx-part-2role-playing-measure-groups/

person piers7    schedule 24.03.2011