MDX и DAX Measure создают несуществующее значение

Я изучаю табличную модель в службе анализа SQL Server 2012.

Я сделал такой куб. введите описание изображения здесь

Прежде всего, я проверил свои данные и результат следующим образом (извините, где утверждение не имеет смысла) введите описание изображения здесь

Персональные компьютеры по контракту определяются следующим образом => ПК по контракту: = СУММ ([Количество ПК])

Однако когда я построил диаграмму в точке производительности (Sharepoint), результат оказался ужасным. поэтому я проверил запрос многомерных выражений, используемый диаграммой.

Это запрос многомерных выражений и результат. введите описание изображения здесь

Фактически, все значения ServiceContractID являются существующими значениями ContractID в ServiceContract.

Мне действительно трудно понять, почему есть пустое значение. В чем причина этого неправильного расчета? (Когда я сделал это с помощью многомерного теста, я смог получить результат, которого ожидал.)


ssas dax mdx
person Stonpid    schedule 18.01.2013    source источник
comment
Вы пытались отфильтровать набор данных дальше, чтобы найти отдельные контракты с расхождениями, а затем искать их в своей базовой табличной модели? Возможно, проблема взаимосвязи или проблема усечения и загрузки данных, обработка, единственный способ определить это - это копаться в строке, а затем выяснять, что пошло не так.   -  person Kyle Hale    schedule 26.09.2015
comment
Также я бы рекомендовал упростить ваш запрос таблицы фактов до гораздо меньшего набора данных, скажем, 10 строк во время тестирования, чтобы вы могли быстро детализировать.   -  person Kyle Hale    schedule 26.09.2015

Ответы (1)


arrow_upward
0
arrow_downward

Когда вы проверяли свои данные с помощью запросов SQL, вы использовали WHERE DateKey = 20121231, но в вашем MDX нет такого ограничения по датам.

Либо вы снова запустите свой SQL без WHERE и посмотрите, не увидите ли вы лишние строки, либо вы добавите фильтр даты в многомерные выражения.

person Magnus Smith    schedule 21.01.2013
comment
Приятель, я написал это там, где утверждение бессмысленно, потому что есть только данные о том, что DataKey - 20121231. Без этого факта третий и четвертый запросы показывают, что все ServiceContractID в таблице фактов находятся в таблице измерений ServiceContract. Следовательно, при пустом уровне контракта результат будет совершенно неверным. - person Stonpid; 22.01.2013
comment
Хорошо, если вы уверены! Раньше я делал подобные предположения, а затем обнаружил, что вкрались несколько ложных строк данных, которых я не ожидал. - person Magnus Smith; 23.01.2013