Я отредактировал, чтобы перефразировать этот вопрос:
Мы хотим хранить торговые и субторговые данные. Итак, чтобы дать представление о данных, у нас есть такие входные данные:
Торговые данные (реляционное хранилище)
| TradeKey1 | TradeLevelMeasure1 |
| TradeKey2 | TradeLevelMeasure2 |
Субторговые данные
| TradeKey1 | SubTradeId1 | Measure2 | Measure3 |
| TradeKey1 | SubTradeId2 | Measure2 | Measure3 |
| TradeKey2 | SubTradeId1 | Measure2 | Measure3 |
Мы ищем лучшее решение для моделирования этого в AP.
Если мы используем реляционные хранилища для создания 2 хранилищ с таким же макетом, как указано выше (с хранилищем Sub-Trade, являющимся основным хранилищем ACTIVE_PIVOT) и присоединяем их на основе TradeKey, то мы в конечном итоге неправильно агрегируем показатели уровня торговли, поскольку сделка копируется в куб для каждой записи Sub-Trade. (Например, TradeLevelMeasure1 имеет двойное правильное значение, поскольку оно существует в кубе для обеих записей дополнительных сделок)
Решение, которое мы придумали, состоит в том, чтобы использовать один магазин и добавить новое измерение для указания уровня торговли (Trade или SubTrade). Итак, мы получаем что-то вроде этого:
| Trade | TradeKey1 | TradeLevelMeasure1 | | | |
| SubTrade | TradeKey1 | | SubTradeId1 | Measure2 | Measure3 |
| SubTrade | TradeKey1 | | SubTradeId2 | Measure2 | Measure3 |
| Trade | TradeKey2 | TradeLevelMeasure2 | | | |
| SubTrade | TradeKey2 | | SubTradeId1 | Measure2 | Measure3 |
Таким образом, мы должны иметь возможность правильно агрегировать, а затем при необходимости расширять дополнительные торговые меры.
Кажется ли это жизнеспособным решением, или есть лучший способ добиться этого?
