Смоделируйте связь между двумя таблицами фактов
У меня есть таблица фактов продаж, таблица фактов заказов (обе детализации уровня строки) и два измерения ролевой игры даты (из измерения даты) для даты заказа и даты проводки.
Я пытаюсь добраться до точки, где вы можете просмотреть показатели продаж по дате заказа и показатели заказа по дате транзакции.
Таблица продаж содержит ключ для связанной строки заказа, если продажа была из заказа, и null, если это была неупорядоченная продажа. Таблица заказов не содержит ссылок на связанные торговая операция.
Я пытался понять, как смоделировать отношение, основанное на связи между двумя таблицами фактов, и единственный метод, который я могу использовать,-это создать измерение на основе таблицы Orders, которая содержит только ключ, а затем использовать отношения "многие ко многим"... что почему-то кажется совершенно неправильным, но я не уверен, каков будет "правильный" подход к этой ситуации.
Если это вообще возможно, я хотел бы, чтобы продажи без заказа отображались как" неизвестный " заказ даты при просмотре показателей продаж по дате заказа, так что вы можете видеть полную картину, а не только продажи из заказов. При использовании вышеприведенного подхода этого не происходит.
Какие-либо предложения о том, что нужно изменить, чтобы это сработало?
2 ответа:
Вы были на правильном пути. Я бы создал представление в реляционной базе данных или именованный запрос в DSV, содержащий в качестве одного столбца различные ненулевые идентификаторы порядка, возможно, назвал бы его "DimOrderId". Затем постройте измерение из него, установив свойство" обработка Null "(вы должны нажать " плюс "два раза для свойства" ключевые столбцы "атрибута в заявках, чтобы получить доступ к этому свойству) в"UnknownMember".
И затем используйте это измерение для отношения "многие ко многим".
Идентификатор заказа следует использовать для поиска даты заказа и размещения ключа измерения даты заказа в таблице фактов проводки по продажам. Поскольку на один ордер может приходиться несколько транзакций, другой путь, вероятно, просто не имеет смысла. Если это 1: 1, Вы можете сделать обратное, но это будет означать обновление фактов Заказа после того, как транзакция произойдет, что может быть связано со сложностью загрузки и снижением производительности. Убедитесь, что вам действительно нужен заказ по дате транзакции.