DeepSee で有効な階層を設計

DeepSee で階層を設計する場合、子メンバーに 1 つの親しか指定できません。 子が 2 つの親に対応する場合には、信頼性のない結果が得られることになります。 類似する 2 つのメンバーが存在する場合、そのキーがそれぞれ一意になるように変更する必要があります。 これが起きる場合とそれを回避する方法について、2 つの例を見ながら説明します。

例 1

（アメリカには）Boston と言う都市がある州がたくさんあります。 私のサンプルデータでは、Boston, MA（マサチューセッツ州ボストン）と Boston, NY（ニューヨーク州ボストン）のレコードがあります。 次元は次のように定義されています。

私の場合、City（都市）と State（州）は単純な文字列です。 キューブにビルドすると、"MA" と "NY" の2 つの州メンバー、"Boston" と "Boston" の 2 つの都市メンバーが得られます。 Boston が 1 つではなく 2 つあるのはなぜでしょうか。 メンバーには 2 つの親メンバーを指定できないため、親ごとに異なるメンバーを作成する必要があります。 残念ながら、1 つのキーが 2 つの異なるメンバーを持っているため、この時点で「不適切な階層」状態になっています。

これを修正するには、キーを一意にしなければなりません。 "City" プロパティをレベルのソースプロパティとして直接使用する代わりに、ソース式を使うとこのメンバーを一意にすることができます。

こうすることで問題は解決されますが、望ましくない副作用が発生する可能性があります。 この式では、ピボットテーブルで以下のような結果になります。

これは表示フォーマットとして適切な場合も、適切でない場合もあります。 この時点ではキーとメンバー名が同じであるため、もう少し手を加えれば "Boston" だけが表示されるようにできますが、その後ろに一意のキーがあります。 詳細は、ドキュメントをご覧ください。

まとめると、異なるメンバーには一意のキーが必要です。 特定のキーを持つ子メンバーに、同じキーを持つ既存の子メンバーとは異なる親メンバーがある場合、そのキーは再利用されますが、新しいメンバーが生成されます。 このため、階層が無効になります。

例 2

無効な階層は日付階層によく見られます。 自然と以下の階層を作成する傾向にあります:
Year
Month
Week
Day

*** ここでは、具体的に DeepSee における Year、MonthYear、WeekYear、および DayMonthYear 抽出関数について言及しています。

知っての通り、Week は 2 つの月、さらには 2 つの年に含まれる場合があります。 ここでの他のすべてのレベル（Year、Month、Day）はどれも親に適合し、2 つの親に含まれることはありません。 このように Week メンバーで定義された階層がある場合、DeepSee エンジンがツリーをトラバースする方法（Jan 3 2020 から December 2019 の Week 52 2019 まで。 ただし Jan 3 2020 は December 2019 の子ではないため、エンジンはこれらの結果を削除する可能性があります）が原因で予期しない結果となる可能性があります。

一般的な解決策は、Week メンバーのみの階層を新たに作成することです。 こうすることで、元の階層の整合性を保持しながら、クエリ内で Week を使用することができます。

DeepSeeButtons on Open Exchange には、生成レポート内にこれらの条件をチェックして、階層が無効であるかを通知するセクションがあります。

*** InterSystems IRIS 2020.3 以降では、DeepSeeButtons は製品に含まれています。 追加情報は、ドキュメント をご覧ください***