勘定科目の組み合せ

概要

Microsoft Dynamics 365 の財務および運用では、テーブル内の合計列数に対する SQL データベースの制限により、ディメンション フレームワークが拡張され、最大で約 50 個のディメンションが許可されます。 ディメンションを動的に作成し、任意の順序で入力できます。 モデルの無制限の性質、リレーショナル データベースの設計による利点、パフォーマンス要件の最適化により、以前のデータ モデルよりも複雑なデータ モデルが得られます。

パート 1: 台帳アカウントの組み合わせを作成するとどうなりますか?

この記事では、分析コード フレームワークを構成するさまざまな領域と、それらがどのように連携するかについて説明します。 この情報は、台帳アカウントの組み合わせを作成するときに何が起こるかを理解するのに役立ちます。

以下の図は、分析コードフレームワークを構成するさまざまな領域を示しています。

この記事では、上記の図で黄色で強調表示されている箇所「分析コード」、「分析コード値」、「分類」、「バッキング エンティティ」について説明します。

分析コードの属性

分析コード属性は、単に分析コードとも称され、勘定科目の組み合わせと関連付ける情報を分類する追加要素を意味します。 これは具体的なインスタンスではなく、要素の種類を意味します。 分析コードの作成に使用できる要素は、システム上に存在するエンティティクラス (部門、原価部門、経費の目的、顧客、仕入先、品目など)、または、特定のインストールに特化したカスタムエンティティ (ライセンスプレート番号、イベント名、およびチケット番号など) のいずれかです。

ディメンションを作成するときは、その値の取得場所を選択します。 ディメンションの値は、Customer エンティティや Department エンティティなど、システム内の既存のエンティティから取得することも、作成したカスタム リストから取得することもできます。 定義するディメンションごとに、ディメンション フレームワークはシステム内のテーブルへの参照を追跡します。 たとえば、既存の顧客エンティティについては、CustTable テーブルへの参照が使用されます。 定義したカスタム エンティティの場合、DimensionFinancialTag テーブルへの参照が使用されます。 DimensionAttributeテーブルには、各分析コードを表すメタデータが格納されています。

以下の図では、 財務分析コード ページに2つの分析コードが表示されています。 顧客分析コードには、アプリケーションに既に存在する顧客が表示され、LicensePlate分析コードは新しいカスタムリストが表示されます。

それぞれの分析コードは、DimensionAttributeテーブルに格納されています。 下図のSQLクエリは、各分析コードに関連付けられている基本情報の一部を表示しています。

Type の値は、分析コードがシステム上に存在しているエンティティと結びついているのか、もしくはカスタムリストと結びついているのかを表しています。 ただし、分析コード フレームワークは、CustTable のような既存エンティティのバッキング テーブルに対する直接参照は行いません。 代わりに、ディメンション フレームワークで使用できるように、システムでエンティティを使用できるようにするカスタム ビューが作成されます。 既定では、ディメンションとして 36 個の既存のエンティティを使用できます。

同じエンティティに基づいて複数のディメンションを作成できます。 場合によっては、トランザクション アクティビティを分類するときに、システム内のエンティティが複数の目的を果たします。 この場合、エンティティに対して複数のディメンションを定義し、目的ごとに 1 つずつ定義できます。 一般的な例として、プライマリ コスト センター (販売など) とトランザクションの取引対象のコスト センター (購入など) の両方を表すコスト センターバッキング エンティティがあります。

内部的には、ディメンション フレームワークの主要な機能をサポートするためにシステムによって自動的に作成される特別なディメンションが存在します。 MainAccount 分析コードが主要な例です。 この機能により、分析コードフレームワークが主勘定を分析コードとして扱うことができます。 ただし、ユーザーが主勘定を使用して分析コードを作成することはできません。 その他のタイプの特殊分析コードは、システムによって生成される分析コードです。これは分析コードフレームワークが内部使用する目的で生成されます。

分析コードの属性値

ディメンション属性値は、ディメンション フレームワークで使用するディメンションの特定のインスタンスです。 DimensionAttribute レコードの ViewName プロパティは、ディメンションの値を決定します。 CustTable などの既存エンティティの場合、値はそのテーブル内のレコードで構成されます。 カスタム リストの場合、値は DimensionFinancialTag テーブルの特定のレコード セットで構成されます。 特定の分析コードに使用可能となる値を参照するには、 財務分析コード ページ内の 財務分析コード値 ボタンを選択します。

CustTable などの既存のエンティティが値の一覧を提供する場合、[ 財務分析コード ] ページから編集することはできません。 顧客の新しいディメンション値を作成するには、[ 顧客 ] ページに直接移動し、新しい顧客を作成する必要があります。 新しい顧客を作成したら、ディメンション フレームワークで使用できます。 値のリストをカスタム リストとして指定した場合は、[ 財務分析コード ] ページで直接リストを編集できます。

次の図は、CustTable が提供する値の一覧の例を示しています。 以下例では、分析コードフレームワークには値が格納されていません。

次の図は、カスタム リストが提供する値の一覧の例を示しています。 以下例では、分析コードフレームワークには値が格納されています。

次の図は、上記図の分析コード設定テーブルから取得されたクエリの結果を示しています。

どちらの例でも、[ 財務分析コード値 ] ページには、ディメンション フレームワークが使用する値ではなく、エンティティに存在する値が表示されます。 ディメンション フレームワーク内のこれらの値の表現は、フレームワークがこれらの値を使用するまで作成されないため、バッキング値への参照を保持する必要があります。 そのため、フレームワークでまだ使用されていない値を削除できます。 この動作により、ストレージのサイズとパフォーマンスが最適化されます。

ディメンション フレームワークは、ディメンション値を参照した後、DimensionAttributeValue テーブルに値を格納します。 このテーブルは、DimensionAttribute レコードを、DimensionAttribute レコードが参照する ViewName ビューまたはテーブル内のレコードの特定の RecId 値にリンクします。 DimensionAttribute レコードと DimensionAttributeValue レコードの両方が、ユーザーが入力した元の値に戻る必要があります。

ディメンション フレームワークが値を参照しないシステムでは、DimensionAttributeValue テーブルにレコードがありません。

第2部: 分析コードの一覧とデフォルトの分析コード

この記事では、下記の図で黄色で強調表示されている箇所「分析コード一覧」、「既定分析コード」について説明します。

分析コード一覧とデフォルト分析コードは、分析コードまたは分析コード値のいずれかへの参照のセットを格納するために使用されます。 一般的には、両方とも顧客 (CustTable) や仕入先 (VendTable) のようなプライマリ データ ページにある財務分析コード タブに表示されます。

分析コードの一覧

分析コード一覧は、既存の分析コードに対する参照のセットであり、後に使用されることに備えて保存されます。 これらの分析コードには特に順序の制約がありません。また、分析コードフレームワークは、セット上に表示される分析コードに対する制約を課しません。 ただし、多くの場合、消費コードは使用中の元帳コードで使用できる分析コードの組み合わせに制約を加えます。 分析コードの一覧は、DimensionAttributeSetおよびDimensionAttributeSetItemテーブルに格納されます。

各組み合わせには列挙型を指定します。 この列挙型は、それぞれの分析コードに関連付けられている列挙値の元を表す、BaseEnum の列挙 ID を指します。 列挙番号を確認するには、 enumnum () メソッドを使用します。 これはバッキング エンティティを元とするユーザーが入力した値のリストではなく、開発者によって定義された列挙値の一覧です。 例としては、それぞれの主勘定に関連付けられ、固定 (固定値 とラベル)、または固定されていない (非固定 とラベル) 分析コードリストの格納です。

以下の図は、ページ内における分析コード一覧の表示例を示しています。

上記例では、 dimensionfixed 一覧を使用して、ドロップダウンリストの値のリストを制約しています。

選択した値はEnumerationValueが1（=DimensionFixed::Fixed）である項目を表し、他の項目はEnumerationValueの既定値である0（=DimensionFixed::NotFixed）を使用します。 以下の図は、DimensionAttributeSetレコードがどのように格納されているかを示しています。

MainAccountLegalEntity のレコードは、 FixedDimensions 列を使用して fielddimensionattributeset のレコードを参照しています。 DimensionAttributeSet に格納されているレコードは、列挙型の分析コードの組み合わせを表しています。 DimensionAttributeSetItem のレコードは、分析コードに結びつくデータの組み合わせと、関連する列挙値を表します。 列挙値は、整数値で表示されます。

既定の分析コード

ディメンション列挙は、関連付けられた列挙値を持つ一連のディメンションを保持します。 既定のディメンションは、特定のディメンション値を持つ一連のディメンションを保持します。 デフォルトディメンションという用語は、通常、トランザクションに直接ではなく、マスタデータレコードにこれらのセットを入力するという事実に由来します。 これらを使用して、勘定科目の組み合わせに既定値を入力します。 ディメンション列挙と同様に、特定の構造は既定のディメンションに関連付けされません。 ほとんどの場合、利用するコードは、現在の台帳で利用可能なディメンションにセットを制限します。 DimensionAttributeValueSet テーブルと DimensionAttributeValueSetItem テーブルには、既定のディメンションが格納されます。

以下の図は、ページ内における既定の分析コード例を表示しています。

前の例では、ユーザーは各ディメンションに関連付けるディメンション値を選択します。 以下の図は、これらの値がDimensionAttributeValueSetとDimensionAttributeValueSetItem テーブルにどのように格納されているかを示しています。

MainAccountLegalEntity のレコードは、入力された値の組み合わせを表す DimensionAttributeValueSet テーブルへの外部キー参照を保持します。 具体的には、このテーブルは、DimensionAttributeValueSetItem テーブルに格納されているディメンション値のペアのセットを表します。

DimensionAttributeValueSetItem テーブルには、入力したディメンション値ごとに 1 つのレコードが保持されます。 このレコードは、DimensionAttributeValue を参照しています。 入力しなかったディメンションのレコード (つまり、空白のレコード) は保存されません。 既定のディメンションを入力すると、ディメンションフレームワークでディメンション値が使用されるようになったため、DimensionAttributeValue テーブルに 2 つのレコードが作成されます。 この方法では、ディメンション フレームワークの値がバッキング エンティティとリンクされます。 パフォーマンス上の理由から、分析コード値のナチュラルキー (表示される値) は、DimensionAttributeValueSetItemテーブルに格納されています。

値のソースを取得するには、DimensionAttributeValue テーブルの EntityInstance フィールドに格納されているリンクと DimensionAttribute テーブルの関連する ViewName フィールドに従って、CustTable の元のテーブル (DimAttributeCustTable ビューを介して) および DimensionFinancialTag のレコードを検索します。

第3部: 構造と制約

この記事では、下記の図で黄色で強調表示されている箇所「構造」と「制約」について説明します。

前に説明したように、ディメンション フレームワークでは、次元の数に制限はありません。 さらに、ユーザーが勘定科目の組み合わせを入力する際に、組み込む分析コードとその順序を指定できます。 また、その勘定科目の組み合わせの各区分に対する入力値に制約を加えることも可能です。

勘定構造

以下の図は、勘定の構造例を示します。

以下の図が示すように、この勘定構造は、データベースの DimensionHierarchy テーブルに格納されています。 ここでは、勘定科目の組み合わせの最初の入力区分として主勘定を入力し、続いて顧客およびライセンスプレート番号を入力するように設定されています。 この設定では、階層の順位を定義します。 この設定はデータベースの DimensionHierarchyLevel テーブルに格納されています。

順序に加えて、制約を設定する必要があります。 制約とは、有効な値の組み合わせを定義する条件を意味します。 この例では、すべてのセグメントにて組み合わせの値を指定する必要があります。 それ以外の場合、有効とは見なされません。 既存の値 (つまり、バッキング エンティティに既に存在する任意の値) を入力でき、有効な値の組み合わせに関する特定の制限はありません。 DimensionConstraintTree、DimensionConstraintNode、DimensionConstraintNodeCriteria テーブルには、この条件が格納されます。

上記図の例では、必要最低限の制約ツリーが示されています。 アスタリスク (*) のついている制約条件は、3 つの制約ノードにそれぞれ関連付けられています。 この制約条件は、存在するすべての値を意味します。 データベース上はパーセント記号 (%) で保存されており、UI上では "<すべての値>" として表示されます。 これらの制約は、ルックアップを介して各セグメントに入力できる値を表示したり、セグメントに入力された値を検証するために使用されます。 最終的に、台帳アカウントの組み合わせに不適切な値が入力されると、これらの制約によって検証エラーが発生します。

Dimension frameworkでは、より複雑な制約ツリーを設定することが可能となり、最初のセグメントに入力された値によって次の区分に入力可能な値を判断することができます。 以下の図は、この多機能性の一例を表しています。

以下の図では、より複雑な制約ツリーを表しています。

以下の図は、制約定義のクエリ結果を示しています。

ユーザーが主勘定と顧客に 150-B と入力した場合は、特定のライセンス プレート番号を入力する必要があります。 一方で、 150-W と入力した場合は、ライセンスプレート番号は必要ありません。 どちらの場合も、ユーザーは常に、これらのセグメントの 1 つが空白のままであっても、勘定科目の組み合わせに 3 つのセグメントを表示します。 これらの構造、セグメント、制約が台帳ディメンション 勘定を入力したときの影響の例については、この記事の パート 5 のセクションを参照して、勘定科目の組み合わせの入力と保存について説明します。

入力必須となっている後続のセグメントのみを表示するには、詳細ルールと勘定構造の組み合わせることで、さらに柔軟な設定を実現することができます。

第4部: 高度なルール

この記事のこの部分では、次の図で黄色で強調表示されている 高度なルール 領域について説明します。

アカウント構造と制約を使用すると、有効な組み合わせの単純なツリーから複雑なツリーを構築できます。 ただし、許可されている有効な値を制約し、常にディメンションを表示するのではなく、特定の時刻にのみ、勘定科目の組み合わせでディメンションをセグメントとして表示するビジネス要件が存在する場合があります。 高度なルールを使えば、こうした要件にも対応可能です。

詳細ルール

アカウント構造とその制約に高度なルールを追加できます。 高度なルールは汎用性がありますが、次のガイドラインに従って、最適な使いやすさ、パフォーマンス、および理解を保証します。

• ルールによって勘定構造を置き換えることはできません。 構造は常に存在する必要があり、主勘定区分は必須項目です。
• 勘定構造に既に存在する他のセグメントの前に分析コードを追加することはできません。
• 主勘定に関係なく、常に必要とされる追加分析コードの勘定科目構造の制約をルールで置き換えることはできません
• アカウント構造に既に存在するセグメントをレプリケートしたり、他のルールをレプリケートしたりするには、ルールを使用しないでください。
• 重複のあるルールは自動的に結合され、最も制限の厳しい制約が使用されます。
• セグメント内に重複したルールがある場合については、同セグメント内の最初に記述された箇所のみに表示されます。

高度なルールを設定するには、勘定科目の組み合わせにセグメントを追加するタイミングを制御するフィルターを定義します。 次に、追加する追加のセグメント、階層内での順序、およびそれらの間の制約を指定するルール構造をリンクします。 (ルールの構造は勘定構造と類似した特徴があります)。

たとえば、以下の勘定構造が設定されているとします。

以下の高度なルールでは、ユーザーが主勘定に 145 を入力し、かつ顧客に G ~ Qを 入力した場合にのみ、1つから2つ以上のセグメントを追加する設定です。

ルールを設定した後で、構造と制約定義を作成して、勘定科目の組み合わせにどのようなセグメントを追加するかの定義を加える必要があります。 この手順を完成させるには、以下のルール構造を作成します。 ルール構造を作成するプロセスは、勘定構造を作成するプロセスと共通しています。 これらの構造には、ただちにルールの適用がされません。 したがって、これらのルールを必要に応じて複数のルール間で共有することができます。

構造を作成したら、それをディメンション ルールに追加します。 次に、ルールと共にアカウント構造をアクティブにします。

このデータが保存される場所は、勘定構造の保存場所と共通のテーブルが使用されます ( 第3部を参照)。 DimensionRule、DimensionRuleAppliedHierarchy、およびDimensionRuleCriteriaテーブルは、ルールの定義に固有のデータを保持します。 ここにはルール構造の定義へのリンクも保持しています。 そのほか残りのテーブルは、勘定構造の定義と共有されています。

第5部: 勘定分析コード

この記事のこのセクションでは、次の図で黄色で強調表示されている 台帳ディメンション 領域について説明します。

すべての構成データを設定したら、台帳アカウントの組み合わせを入力、検証、永続化できます。 アプリケーションは、この領域をディメンション フレームワークの主な消費量として使用します。

ルールが適用されていない元帳分析コードストレージ

台帳ディメンションを理解するには、ユーザーが勘定科目の組み合わせを入力する方法を理解する必要があります。

このセクションでは、この記事の パート 4 のアカウント構造とルールの設定を使用します。 アカウントが入力されたときのアカウント入力コントロールに対するユーザー操作について説明します。 アラームとしてのアカウント構造を次に示します。

1つの勘定ルールが勘定構造に関連付けられています。

以下の図は、追加された構造を示しています。

以下の図は、ユーザーが最初にページで表示したときに、フォーカスを持たない勘定科目フィールドがどのように表示されるかを示しています。

このフィールドをクリックしても、何も変更されません。 ドロップダウンの矢印を選択すると、ルックアップが表示され、使用可能なセグメントが表示されます。 以下の図では、2つのセグメント候補が表示されています。

以下の例では、 150-Aの組み合わせが入力されています。

2番目のセグメントが入力し、 Tab を押下して入力欄を移動するとただちに、分析コードフレームワークが制約に基づいた検証を行い、その組み合わせが保存されます。 この例では、入力された組み合わせは有効とみなされています。 ユーザーは、文字を入力するか、あるいはルックアップを使用してセグメントに入力することができます。

この例では、組み合わせについて以下の情報がわかっています。

• 勘定構造は、 myaccountstructure という名称です。
• 最初のセグメントは、MainAccount分析コードです。 コード値は 150 です。
• 2番目のセグメントは、顧客分析コードです。 コード値は A です。
• 値がこの勘定構造に関連付けられている詳細ルールと一致しなかったため、区分が追加されませんでした。

結果として、以下の図に示すように、2つのセグメントの値が4つのテーブルにまたがって格納されます。

.

1番目のテーブルは DimensionAttributeValueCombination.です。 すべてのマルチセグメントアカウントの組み合わせと、その組み合わせに関する非正規化された情報が格納されます。 このテーブルに格納されている情報の例としては、連結されたセグメントをひとつの文字列として格納し、勘定構造への外部キー参照を格納し、使用された主勘定 (150) に対する外部キーが格納されています。

2 番目のテーブルは DimensionAttributeValueGroupCombination という名前で、後で説明します。

3番目のテーブルは、 DimensionAttributeValueGroup です。 組み合わせに含まれる各構造に関連付けられた、セグメントのグループが格納されています。 この場合、構造 (アカウント構造) は 1 つしかないため、レコードは 1 つだけです。

4番目のテーブルは、 DimensionAttributeLevelValue です。 関連するグループまたは構造に存在するセグメントの値がそれぞれ格納されています。 入力されたセグメントごとに1つのレコードが存在します。 セグメントが空の場合は、値が格納されません。 各レコードは対応する DimensionAttributeValue レコードを参照します。 値に対応するレコードが DimensionAttributeValue にて見つかった場合は、そのレコードが参照されます。 値に対して既存の DimensionAttributeValue レコードが見つからない場合は、作成されます。 このデータは、DimensionAttribute を実際のバッキング エンティティ レコードに連係します。 この例でDimensionAttributeLevelValue には２つのレコードが表示されており、ひとつは 150 というIDを持つ MainAccount レコードと、もう一方は A というIDを持つ CustTable レコードを表示しています。

勘定構造の値とセグメントの値のグループを DimensionAttributeValueCombination のメインレコードに連係するには、2番目のテーブルである Dimensionattributevaluegroup にレコードが挿入されます。

1 つのセグメントを新しい組み合わせで保存するには、これら 4 つの各テーブルに少なくとも 1 つのレコードを挿入します。 入力した追加のセグメントごとに、追加のレコードを DimensionAttributeLevelValue テーブルに挿入します。 これら4つのテーブルは、勘定分析コードと呼ばれます。 元帳分析コードは、DimensionAttributeValueCombination テーブルの RecId 値を参照する外部キーとして表されます。

ルールが適用された元帳分析コードストレージ

このセクションは、前のセクションで開始した台帳ディメンションストレージの例に基づいています。 ここでは、値を 150-A から 145-Q に変更します。 前に設定した高度なルールからわかるように、この変更により、アカウント構造に 3 番目のセグメントが追加されます。

2 番目のセグメントの後にハイフン (–) を入力すると、コントロールは 3 番目のセグメントを追加し、フォーカスを受け取ります。

第3セグメントにフォーカスがある状態でルックアップを開くと、考えられる有効な値が表示されます。

ライセンス番号を入力できるようになりました。

3 番目のフィールドに値を入力し、 Tab キーを押してコントロールの外に移動するとすぐに、組み合わせが検証されます。 入力された組み合わせが有効な場合は、勘定分析コードとして保存されます。

この例では、新規で入力された組み合わせについて以下の情報がわかっています。

• 勘定構造は、 myaccountstructure という名称です。
• 最初のセグメントは、MainAccount分析コードです。 コード値は 145 です。
• 2番目のセグメントは、顧客分析コードです。 コード値は Q です。
• この値は最初の2つのセグメントのルールと一致するため、 MyRuleStructure1 という名前の勘定科目のルール構造が追加されました。 この結果、1つのセグメントが追加されました。
• 3番目のセグメントは、LicensePlate 分析コードです。 コード値は AAA 111 です。

.

この組み合わせでは、勘定分析コードを格納する4つのテーブルに合計8個の行が挿入されました。 前段 (第4部) で述べた最初の勘定科目の組み合わせと、この勘定科目の組み合わせとの違いは、この勘定科目を構成する分析コードを活用するために複数の構造が使用される点です。 2つの分析コードは、DimensionAttributeValueGroupCombination および DimensionAttributeValueGroup テーブルに格納されます。 それぞれのレコードは、完全な組み合わせに使用、または結合される構造を表します。

各レコードに新しい RecId 値が割り当てられていることに注意してください。 古い値の組み合わせについては更新されません。 代わりに、新しい組み合わせが作成されます。 したがって、組み合わせを使用するために参照カウントが維持されないため、台帳ディメンションは不変です。 最初に入力したのと同じ 150-Q の組み合わせは、インスタンスを 145-Q-AAA 111 に変更する前に、アプリケーション内の複数のテーブルから参照されている可能性があります。 したがって、新しい組み合わせを作成し、台帳アカウントの組み合わせが変更されたテーブルからのみ参照を変更する必要があります。

セグメント値を追加または削除してレコードの組み合わせを変更すると、新しい台帳ディメンションを作成するため、未参照または孤立した台帳ディメンションになる可能性があります。 孤立した組み合わせを許可することで、組み合わせが変更されるたびに問題のテーブル全体のレコードを削除しないことで、ディメンション フレームワーク全体のパフォーマンスを向上させることができます。 一度使用された組み合わせは、再利用されることがあります。 したがって、最後に残っていた参照が削除された場合でも、再作成されることがあります。 元帳分析コードは孤立した状態であっても構造的には有効であり、構造とルールに関連した値の組み合わせが再度入力された場合は再利用することができます。 この組み合わせが別の時点で入力された場合、レコードは挿入されず、既存の参照が再利用されます。 結果として、パフォーマンスが向上します。

高度なルールを使用する場合は、記憶領域のサイズやデータ挿入のコストに対しても最適化処理が行われます。 たとえば、以下の図では、新しい勘定の組み合わせが入力されています。

この場合、新しい組み合わせと古い組み合わせとの違いは、高度なルール が指定する ライセンスプレート の番号が変更されたことです。 以下の図は、この組み合わせのデータがどのように格納されているかを示しています。 新しいレコードは白で強調表示されます。

新しい組み合わせが作成されると、以下5つのレコードが挿入されます。 (これらのレコードは、上記の図にて白で強調表示されています)。

• DimensionAttributeValueCombination テーブルに格納されている1つのレコード
• DimensionAttributeValueGroupCombination テーブルに格納されている2つのレコード
• DimensionAttributeValueGroup テーブルに格納されている 1つのレコード
• DimensionAttributeLevelValue テーブルに格納されている 1つのレコード

この挙動は勘定構造 グループ の一部として保管されている値が、以前の組み合わせ (DAVC2) と今回の組み合わせ (DAVC3) で同じであるために発生します。 DimensionAttributeValueGroup テーブルと DimensionAttributeLevelValue テーブルのレコードは再作成の必要がありませんでした。 代わりに3つのレコードを再利用し、挿入処理のコストを節約することができます。

勘定科目のルールに関連付けられている構造で、ライセンスプレート番号に空白の値を許可されており、 145-Q の組み合わせだけが作成された場合は、2つの新規レコードのみが挿入されます。

• DimensionAttributeValueCombination テーブルに格納されている1つのレコード
• DimensionAttributeValueGroupCombination テーブルに格納されている1つのレコード
• DimensionAttributeValueGroup テーブルには該当するレコードがありません。
• DimensionAttributeLevelValue テーブルには該当するレコードがありません。

この動作は、すべての DimensionAttributeValueGroup レコードと DimensionAttributeLevelValue レコードが既に存在し、新しい組み合わせで完全に再利用できるために発生します。 主にこの理由から、台帳ディメンションのストレージ テーブルのデータを直接変更しないでください。 1つのレコードに対する変更は、元帳分析コードに対するすべての参照に影響するだけでなく、その他の複数の勘定分析コードと参照に影響する可能性があります。

この記事のこの部分で示されている例では部分的に折りたたまれていますが、システムは DimensionAttributeValueCombination テーブルと DimensionAttributeValueGroup テーブルにハッシュ コードを割り当てます。

パート6: 高度なトピック

この記事を終了するために、このパートでは、ディメンション フレームワークの動作を促進する、より詳細な設計と実装の決定について説明するいくつかの高度なトピックについて説明します。

以下の図では、分析コードフレームワークを構成するさまざまな領域を示しています。

ハッシュ

ディメンション フレームワークのデータベース ストレージの設計では、次の機能がサポートされています。

• データが挿入されるだけで、更新も削除もしない不変データに対応しています。
• 作成済みの組み合わせを再利用して、挿入処理のコストを削減します。
• 参照カウントの実行と管理の必要性をなくします。
• 再利用可能な既存の組み合わせを検索するにあたって、パフォーマンスの向上が図れます。

勘定科目の組み合わせでは、分析コードの数は無制限で、構造体の数に制限はありません。そのため、1つの大きなクエリまたは複数の小さなクエリを作成して、既存のセットまたは組み合わせを検索することは現実的ではありません。 レコードの数と順序は、組み合わせごとに異なる可能性があるため、ハッシュ ベースのソリューションが実装されています。

ハッシュとは、関連付けられているテーブルのレコードに含まれる固有の情報を意味し、問い合わせ処理の高速化を可能にします。 フレームワークは、1 つのバイナリ コンテナー フィールド (160 ビット、20 バイト ハッシュ列) を格納して、セットまたは組み合わせに含まれるデータを一意に識別します。

分析コードフレームワークはハッシュを使用して、以下テーブルのデータを一意に識別します。

• Dimensionattributevaluecom このテーブルは、DimensionAttributeValueGroup テーブルと DimensionAttributeLevelValue テーブルから連係されたすべてのデータで構成されています。
• DimensionAttributeValueGroup このテーブルは、DimensionAttributeLevelValue テーブルから連係されたすべてのデータで構成されています。
• DimensionAttributeSet –このテーブルは、DimensionAttributeSetItem テーブルのレコードと関連付けられているデータで構成されています。
• DimensionAttributeSet –このテーブルは、DimensionAttributeSetItem テーブルのレコードと関連付けられているデータで構成されています。

ハッシュ メッセージ

ハッシュを生成するにあたって、セットまたは組み合わせの内容に関する個々の順序付けられた情報を持つメッセージが作成されます。 生成されたハッシュによってメッセージは異なりますが、ハッシュメッセージに基本的に含まれているのは、分析コード、値、構造に関する情報と、組み合わせ内における順序が含まれています。 この情報は、所定の方法で内部的に計算され、ハッシュルーチンに渡されます。 ハッシュ ルーティンは、バイナリ コンテナーを使用してハッシュ キー生成するハッシュを生成します。 これらのメッセージの正確な順序と内容は、分析コード フレームワークのストレージサポートクラスのメソッドによって提供されます。 これらのクラスには、 DimensionAttributeSetStorage、 DimensionAttributeValueSetStorage、 DimensionStorageが含まれます。

ハッシュ キー

ハッシュ メッセージを生成するには、組み合わせを構成する各ディメンション、値、および構造を一意に識別するものが必要です。 RecId 値は一意の識別子として機能できますが、不変ではなく、レコードがエクスポートされ、別のシステムまたはパーティションにインポートされた場合に変更できるため、サロゲートと見なされます。 RecId 値は、インポートプロセス中に再割り当てすることができます。 RecId 値を使用するハッシュ メッセージを含むハッシュを作成した場合、それを使用してその新しいシステムまたはパーティションのディメンション フレームワークの組み合わせを識別することはできません。 代わりに、GUID を使用します。 GUIDは、DimensionAttribute、DimensionAttributeValue、Dimensionattribute の各テーブルに存在し、 hashkey 列に格納されています。 新しいレコードを作成するたびに、そのレコードに残っている GUID を割り当てて一意に識別します。

データを直接変更するリスクについて

財務ディメンション データを直接変更しない理由、影響を受けるテーブル、およびディメンション値が正しくない場合の処理の詳細については、「 財務分析コード データの変更」を参照してください。

組み合わせの重複

分析コードフレームワークのテーブルを参照して、保存されているレコードの DisplayValue フィールドのみを表示すると、組み合わせが重複しているように見える場合があります。 しかし、 displayvalue の内容が同じで見かけ上は重複していても、ハッシュまたは結合テーブルのデータが異なることがわかります。 Displayvalue 文字列は、パフォーマンスの向上を目的として格納されているのであって、レコードを一意に識別するために使用されるわけではありません。

たとえば、ある会社の勘定構造に MainAccount-Department があり、別の会社の勘定構造に MainAccount-CostCenter があるとします。 このシナリオでは、勘定構造ごとに1つずつ、2つの組み合わせの DisplayValue 文字列が 145-A と表示されることがあります。 最初の勘定構造では、 A が最初の会社の部門を表します。 しかし、2番目の勘定構造では、2番目の会社の原価部門を表します。 DimensionAttributeValueCombination テーブルには、複数の種類の元帳分析コードが格納されています。 たとえば、 DisplayValue のフィールドを確認すると、予算に関する特別なタイプは他の組み合わせのタイプと同じに見えることがあります。 しかし、内部的には異なる情報を保持し、それぞれ異なる一意のハッシュ値を保持しているのです。

この同じ動作は、 DimensionCombinationEntity と DimensionSetEntity にも適用されます。 これらのエンティティのクエリを実行すると、 DisplayValue に基づいて一見重複する行が返されますが、基になるレコードは異なります。 よくあるのは次のような理由です。

• 会社別に分類されたデータ - ディメンションデータはグローバルに格納されますが、会社固有のバックレコードを参照できます。 既定のディメンション "Department 001 - Project P012" は、USMF、USSI、RUMF 用に個別に存在し、3 つの一意の行を生成できます。 エンティティはデータ領域を公開しません。これは、外部キー参照を持つ所有テーブルによって保持されます。
• 統合形式ではディメンションが除外 されます。統合形式が "Department - Project" のみをエクスポートし、システムが "Department - Customer - Project - Employee" を追跡している場合、顧客/従業員の値が異なる 2 つのレコードがエンティティ出力の同じ DisplayValue に折りたたまれます。
• さまざまな台帳ディメンションの種類 - 既定の勘定、勘定科目、予算勘定、予算管理勘定、フォーカス残高勘定はすべて DimensionAttributeValueCombination に格納されます。 異なる種類のレコードは、同じ DisplayValue を共有できます。
• ハッシュ アルゴリズムの移行 — HashV2 更新では、一部の組み合わせに対して新しいレコードを作成する必要があります。この組み合わせは、その場で再ハッシュできませんでした。 古いレコードと新しいレコードは、エンティティで公開されていない Hash 列と HashVersion 列でのみ異なります。

データ領域間でディメンション外部キー参照を共有することはできません

ディメンション外部キー列 (CustTable の DefaultDimension など) は、会社間のデータ共有 (SysDataSharing、DuplicateRecordSharing) または手動のレコード コピーを使用して、企業間でレプリケートすることはできません。

ディメンション テーブル (DimensionAttributeValueSet、 DimensionAttributeValueCombination) は会社固有ではありません (SaveDataPerCompany = No)、内部的に参照されるレコードは多くの場合です。 既定のディメンション セットには、 CustTable や ProjTable などの会社固有のテーブルの RecId 値を指すセグメント参照を含めることができます。 以下に例を示します。

CustTable (SaveDataPerCompany: はい)

DimensionAttributeValueSet (保存データを会社ごとに: いいえ)

次元属性値セット項目 (会社ごとのデータ保存：いいえ)

行をコピーして CustTable レコードを別の会社 (RUMF) にレプリケートした場合、新しいレコードは DefaultDim = 401 を継承します。 そのディメンション セットには、USMF の CustTable の RecId 201 と USMF の ProjTable の RecId 301 へのセグメント参照がまだ含まれています。 RUMF の顧客CUST001には、誤った企業のデータを参照する既定のディメンションが含まれるようになり、この破損は転記された組み合わせに広がり、同じビジュアルキーに対して試算表の行を分割する可能性があります。

回避策はありません。 ディメンションの外部キー値をデータ領域間でレプリケートしないでください。

DimensionAttributeValueCombination の中の AccountStructure 列

DimensionAttributeValueCombination (DAVC) テーブルの多くの行には、空の AccountStructure 列があります。 これは仕様であり、データの破損を示すわけではありません。

フレームワークは、すべての次の条件が真である場合にのみDAVC.AccountStructureをポピュレートします。

• この組み合わせは、複数セグメント勘定タイプ台帳ディメンション (LedgerDimensionType::Account) です。
• 参照される DimensionHierarchy 型は Account Structure です。
• 階層はシステムによって生成されません (DimensionHierarchy.IsSystemGenerated = No)。

転記プロファイル (主勘定のみを含む)、予算の組み合わせ、単一セグメントの仕訳帳勘定、フォーカス残高の組み合わせ用の既定のアカウントはすべて、意図的にこのフィールドを空白にしています。

ピボット解除された列とインデックス

DimensionAttributeValueCombination テーブルと DimensionAttributeValueSet テーブルには、Dynamics 365 バージョン 7.0 で追加された "ピボット解除済み" 列と 50 ~ 100 以上のサポート インデックスが含まれています。 これらの列は非正規化されたディメンション値を組み合わせやセットのレコードに直接格納するため、ディメンション値でのクエリにおける複数のテーブルを結合する必要がなくなります。

これらの列のインデックスは必須です。 これを使用しないと、ピボットされていない列に対するクエリはテーブル スキャンにフォールバックします。これは、元の正規化されたアプローチよりも悪くなります。 これらのインデックスは削除しないでください。

一部の勘定タイプ (顧客、仕入先、銀行、プロジェクトなど) は、仕訳帳明細行の セグメント入力コントロール を通じて入力されますが、複数セグメントの元帳勘定ではなく単一値参照です。 これらは同じコントロールとデータ モデルを共有するため、システムはこれらを SystemGeneratedAttribute ディメンション型として自動生成します。これにより、ピボット解除された列とインデックスも生成されます。

パフォーマンスと非常に可変のディメンションを挿入する

ディメンション フレームワークは、各一意の値セットを最初に使用した場合にのみデータを挿入し、後続の要求ごとに参照を再利用するように設計されています。 時間が経つにつれて、組み合わせが再利用されるため、挿入の数は減る必要があります。

ディメンション テーブルに対する挿入のパフォーマンスが時間の経過と共に改善されない場合、最も一般的な原因は、 非常に変動の大きいディメンション (揮発性が高く、ほとんど再利用されないディメンション値) の使用です。 たとえば、日付、シリアル番号、ライセンス プレート、チケット番号、在庫ディメンション (サイズ、色、サイト/倉庫/場所) などがあります。 これらのディメンションは、財務ディメンションではなく、財務タグ またはカスタムフィールドとして実装します。 詳細については、変動幅の大きい分析コード を参照してください。

バージョン管理/有効日付データ

分析コードフレームワークでは、バージョン管理データまたは日付効率データに直接対応していません。 このプラットフォームでは、日付が有効なテーブルの最新バージョン行に新しい RecID が割り当てられます。 分析コードフレームワークは、元のエントリの時点で RecId によるバッキング値への参照を取得するため、新しいレコードが導入された場合、日付コンテキストが分析コード データに維持されないので、システムは古いバージョンを使用できなくなります。

同じバッキング エンティティ レコードが使用されている分析コード データを使用して、別の追加したテーブルが所有しているモジュール内の改訂履歴情報を追跡している場合は、分析コードフレームワークではこのバージョン間の差異を特定できません。これはバッキングエンティティに存在する RecId の値が異なるバージョン間であっても同一であるためです。 これにより、分析コード フレームワークは、バージョン管理されていないテーブルと同様に、現在のバージョンを常に効率よく確認できます。

ディメンション、構造、ルール、制約など、ディメンション フレームワーク テーブルのいずれも、内部的なバージョン管理をサポートしません。 システムは以前のバージョンを新しいバージョンに置き換え、履歴は保持しません。

構造またはルールが変更された場合、勘定科目の組み合わせが未転記トランザクションに対して保存されていると、分析コードフレームワークが新しい組み合わせが作成し、未転記のトランザクションテーブルの外部キー参照がすべて更新されます。 転記されたトランザクションから参照されている場合があるため、元の組み合わせは変更されません。 この2つの組み合わせは、連係されることがありません。 変更前の構造とルールがどのようなものであったかを判別する方法はありません。 一部の情報は、格納されている組み合わせによって判別できる場合もあります。 ただし、空白の値は保存されておらず、不完全なデータとみなされるため、古いバージョンの再構築に使用することはできません。

分析コードフレームワークでは、分析コード値レベルでの "有効な開始日付" と "有効な終了日付" の両方に対応しています。 これらの日付は、値が "有効" と見なされた時点を示しています。これらは有効日付データとは異なり、値の過去の状態を意味するものではありません。