こんにちは。
最終的に、どのような結果を望んでいるか？つまり、どのようなクロス集計をイメージしているか？で変わってくると思いますが。
明細データ（数量、金額）がメジャーであるとすれば、
受注データ：合計金額 => メジャーを受注ＩＤで集計された値と捉えられるのではないでしょうか。
消費税は計算列として用意できると思います。
こうすると、値引値はどうするんだ？ということになりますが、値引き値に対する明細ＩＤデータがあれば問題ないように思えます。
（値引きを消費税計算前に適用するという前提ですが）
消費税を計算列で用意する場合、母集合(Dimension)によって消費税計算結果が変わってしまう可能性がありますから、計算列側でCASE文などで条件を判定するなど必要となるかもしれません。たとえば、受注ＩＤによる集合では消費税が正しく計算できるが、仕入先コードを母集合とした場合はうまく計算されないかもしれないなどです。
あらかじめ、明細データに日付を結び付けておくことが必要と思います。
また別のアプローチでは、明細の分析と、受注データの分析を別CUBEとして用意するという方法もありそうです。
別CUBE(分析)であれば、付帯的な情報は単にIDに対する属性として用意すれば良いだけですし。
このようなことから、何に対するどのような分析を行いたいか？を整理してみるとよいのではないでしょうか。
後あまりRDBの構造を考えすぎないように(囚われない)したほうがよいかもしれません。
って投稿してから、ふっっと思いましたが、もしかして、受注データの受注IDで受注明細に論理リレーションシップ張り(DSN)、両者合わせてメジャー系とすればよいだけかもって思いました。
もしくは、それぞれのメジャー系を用意して、受注IDで結びつくのだから、何も問題ないような・・・とか
結局目的次第ですね。
