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

Question

Я пытаюсь выяснить, как я могу создать вычисляемую меру, которая производит подсчет только уникальных фактов в моей таблице фактов. Моя таблица фактов в основном хранит события с исторической точки зрения. Но мне нужна мера, чтобы отфильтровать избыточные события.
Используя продажи в качестве примера (так как весь материал вокруг 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?

Answer 1

Размещенный запрос может быть переписан так:

SELECT COUNT(DISTINCT SalesRef)
FROM SalesFacts
WHERE Event <> 'Cancelled'

Answer 2

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

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

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

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

Answer 3

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

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