Создайте связь между двумя таблицами фактов

Question

У меня есть таблица фактов продаж, таблица фактов заказов (как подробно на уровне строки), так и два формата ролей в дате (из измерения даты) для даты заказа и даты транзакции.

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

В таблице «Продажи» есть ключ для соответствующей строки заказа, если продажа была заказана и была нулевой, если это была продажа не по заказу. В таблице заказов нет ссылок на связанную транзакцию.

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

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

Любые предложения о том, что необходимо изменить, чтобы заставить это работать?

Answer 1

Вы были на правильном пути. Я бы создал представление в реляционной базе данных или именованный запрос в DSV, содержащий в качестве единственного столбца разные ненулевые идентификаторы ордеров, может быть, назвать его «DimOrderId». Затем постройте измерение из него, установив свойство «Null processing» (вам нужно дважды щелкнуть «плюс» для свойства «Ключевые столбцы» атрибута в BIDS для доступа к этому свойству) на «UnknownMember».

И затем используйте это измерение для отношений «многие ко многим».

Answer 2

Вы должны использовать Идентификатор заказа для поиска даты заказа и поместить ключ измерения даты заказа в таблицу фактов транзакции продаж. Поскольку на заказ может быть несколько транзакций, другой способ, вероятно, просто не имеет смысла. Если это 1: 1, вы можете сделать обратное, но это будет означать обновление фактов порядка после того, как произойдет транзакция, которая может быть сложной по времени загрузки и производительности. Убедитесь, что вы действительно НЕОБХОДИМО заказывать по дате транзакции.