モジュール | Anaplan Support

日本語

モジュールに関連する Planual のルール

モジュール名はできるだけ短くしてください。長い名前の代わりに、英数字のプレフィックスを使用してモジュールの整理や区別を行ってください。DISCO に倣ってモジュールにプレフィックスを付ける必要はありません。機能領域に合わせる方が適切です。
^{対象となるエンジン: Classic Hyperblock と Polaris}

2.01-01a ユーザーに表示されるモジュールのスペースの節約

ダッシュボードのスペースを節約するために、必要に応じてユーザーに表示されるモジュールの名前をよりわかりやすい名前に変更できます。ただし、一般的なデザイン原則に従って、ダッシュボードにあまりにも多くの要素を詰め込まないよう注意してください。

適切な命名規則

モジュールをカテゴリー分けする際には機能領域を使用してください。モジュールを論理的なビジネス機能にグループ化することで、モデルを整理し、すべてのモデルビルダーにとってナビゲーションが直感的になるようにしてください。
^{対象となるエンジン: Classic Hyperblock と Polaris}

空のモジュール (ラインアイテムを含まないモジュール) を使用して、モジュールリストにセクションを設けたり、順序を明確にしたりしてください。モデルの健全性を保つためにデフォルトの時間ディメンションを削除し、絵文字は使用せず、すべての区切りモジュールにおいて一貫した命名規則と書式設定を適用してください。
_{対象となるエンジン: Classic Hyperblock と Polaris}

機能領域内では「類似」モジュールを一つのグループにまとめてください。モジュールのタイプに合わせてデザインし、適切な構造を使用してください。

モデルデザインに関するベストプラクティス
 計算を少なくしてパフォーマンスを向上
 パフォーマンスが上がる式の構造

DISCO 規則はあくまでモジュールのタイプを分類するためのものであり、モデル全体のナビゲーションを整理するためのものではありません。通常、一つのビジネスプロセスや機能領域には複数のタイプのモジュール (データ、入力、システム、計算、出力) が必要となるため、機能領域を DISCO に基づいて整理すると論理的な流れが制限されてしまいます。機能領域はモジュールタイプではなく、常に具体的なビジネス上の目的 (例: 収益、ヘッドカウント、経費) に基づいて定義してください。
_{対象となるエンジン: Classic Hyperblock と Polaris}

全般的なガイダンス:補助ビューのラインアイテムは操作や監査が困難です。特に計算モジュールでは補助ビューの使用を最小限に抑えるようにしてください。代わりに、類似ディメンションを持つ計算モジュールのグループを作成してください。表示目的のインターフェースを設計する際、UX ページで結合グリッドを使用することで、より効率的な選択肢を利用できるようになります。

Polaris 固有のガイダンス: Polaris 計算エンジンでは、モデル間インポートやエクスポートアクションで補助ビューを使用すると、パフォーマンスが低下する可能性があります。補助ビューの代わりに、完全なディメンション性とガードを使用することで、最良のパフォーマンスが得られます。
_{対象となるエンジン: Classic Hyperblock と Polaris}

2.01-06a 分析またはフィルタリングのためにダッシュボードに表示	場合によっては、エンドユーザーエクスペリエンスを向上させるために、ページに属性を表示する必要があります。
2.01-06b 比率式	比率の数値は同じモジュール内にある必要があり、完全なディメンションを必要とする可能性は高くありません。
2.01-06c ページの同期	モジュールから同期する必要があるページがある場合には、特定のラインアイテムが必要になることがあります。
2.01-06d 並べ替えに必要なラインアイテム	場合によっては、並べ替えを容易にするために、ラインアイテムに完全なモジュールディメンションが必要ないことがあります。
2.01-06e レポート又はモジュールのエクスポート	レポートでフィルタリングを使用するか、エクスポート (モデル間) の属性を指定するには、非ディメンション属性のラインアイテムが必要になる場合があります。計算を最小限に抑えるために、これらが補助ビューとして設定されていることを確認してください。

時間のみに関連するすべての関数とフィルターを別々のモジュールに作成してください。再計算は、モデルを開いたときと時間設定が変更されたときにのみ行われるようになります。

時間の粒度 (週、月、四半期、年など) ごとに別のモジュールを使用することをおすすめします。

キーリストのプロパティと属性のためのシステムモジュールを作成します。キーリストには、大規模なリスト、複数のモジュールで使用されているリスト、主要な階層、あるいは頻繁に参照されるリストが含まれます。階層のすべてのレベルには独自のシステムモジュールが必要です。少なくとも、コードと親をラインアイテムとして含めてください。これにより、ITEM()、CODE()、NAME() といった関数を各メンバーに対して一度だけ計算し、マルチディメンションのラインアイテム内で参照できるようになります。
_{対象となるエンジン: Classic Hyperblock と Polaris}

2.01-08a SYS モジュールは不要

ダッシュボード上のフィルター又はセレクターモジュールとして式で参照されていない場合、階層は不要です。

モジュールデザインに関するベストプラクティス

時間とその他の「SELECT」値の仮定を保持する、ディメンションのないモジュールを作成してください。これらは、モデル全体で使用されるグローバルな仮定と一般的な設定に役立ちます。アプリケーションライフサイクル管理 (ALM) セットアップ内でも役立ちます。

すべてのモジュールタイプで、すべてのラインアイテムの [Summary Method] を [None] に設定してください。レポート作成や下流のロジックにおいて、階層のすべてのレベルが厳密に必要とされる場合にのみ、集計方法を有効にしてください。すべてのレベルが必要でない場合は、下流での集計に SUM 関数を使用する方が効率的です。この手法は、セル数が非常に多いラインアイテムにおいて、不要な計算負荷 (Classic Hyperblock と Polaris の双方) を回避し、データが入力されるセル数 (Polaris のみ) を削減するうえで極めて重要です。
^{対象となるエンジン: Classic Hyperblock と Polaris}

2.01-10a すべての集計レベルが必要

すべての集計レベルが必要な場合は、SUM 式を使用するよりもネイティブ集計を使用した方が高速になります。

計算を少なくしてパフォーマンスを向上
 パフォーマンスが上がる式の構造

Classic エンジンで構築する際は、モジュール間でディメンションの順序の一貫性を保つようにしてください。[Applies To] の構成で共通ディメンションがまったく同じ順序で並んでいる場合、計算処理がより高速になります。これは、リストのサイズよりもその順序の方がパフォーマンスに大きく影響するためです。
_{対象となるエンジン: Classic Hyperblock のみ}

ディメンションの順番

同じディメンションを使用してラインアイテムのセットを格納する計算モジュールを作成してください。補助ビューの使用は避けてください。

ラインアイテムサブセットの神秘を解き明かす
 式の長さを短くする

非時間ベースのデータは静的属性とは別のモジュールに保持してください。

データハブの目的とピーク時のパフォーマンス

UX ページ、保存済みビュー、又はエクスポートでフィルターと選択レベルを併用しないでください。「表示レベルの選択」は他のフィルターが適用される前にフィルターとして機能します。そのため、追加のオーバーヘッドが生じる可能性があります。効率的なフィルター評価を行うために、いずれか一方だけを使用してください。階層レベルでは、エクスポートレイアウトで [Omit summary items] を使用するか、システムモジュール内のブール値ラインアイテムの集計オプションを「なし」に設定する方が、はるかに効率的に同じ結果を得られることが多くなります。

_{対象となるエンジン: Classic Hyperblock と Polaris}

フィルターが複数ある場合には、それぞれを別のシステムモジュールに保持するようにしてください。その後、各フィルターはさまざまなモジュールで再利用できます。[Reference By] 列にはビューのフィルターが一覧表示されないため、このフィルターが誤って削除されないようにするために、どこでどのように使用されるかをメモ (Notes) で説明してくださ。

何か理由がある場合を除き、データタグを使用して DISCO カテゴリーを明示します。

関連する組み合わせを再利用するには、アクセスドライバーごとにモジュールを作成します。こうすることで、モデル全体のメンテナンスと有効化に役立つだけでなく、ロジックの繰り返しを削減できます。必要に応じて、設定ごとに異なるラインアイテムを使用してください。

大規模なモジュール、特にフィルターや多くのビューを含むモジュールのコピーには時間がかかり、コピー中にモデルを使用できなくなる可能性があります。モジュールが大きい場合は、モジュールを再作成した方が早い可能性があります。

ネイティブタイムスケールかネイティブバージョンの代わりにリストを使用している場合は、必ずリストをディメンションの順番の最初の二つのリストとして配置してください。これによってネイティブの時間とバージョンの設定が反映され、ネイティブの時間/バージョンとスタンダードリストの間でマッピングする際のパフォーマンスが向上します。

ディメンションの順番

モジュールを作成する際には、計算の範囲を考慮して必要なディメンションのみを含めてください。式で目的の値が返されない場合、またはエラーが発生した場合には、正しいデータが表示されるまでディメンションを追加し続けないでください。計算自体を見直すことをおすすめします。他のモジュールを確認してください。関連するディメンションがある計算モジュールがすでに存在する可能性があるため、既存のモジュールに計算を追加してください。

計算を少なくしてパフォーマンスを向上

title

caseportalLink.text

registrationLink.text

callLink.text

免責事項

常に最新の情報を提供するため、Support は定期的に更新されます。