財務次元データの変更

この記事では、財務ディメンション データが不変である理由、変更してはならないディメンション フレームワーク テーブル、および転記されたドキュメントでディメンション値が正しくない場合の処理について説明します。

財務ディメンション データの不変性

財務ディメンションデータは、最初の参照時に挿入専用です。 財務次元テーブルにレコードが挿入されると、レコードはそこに恒久的に存在します。 これまで許可されている変更は、名前の変更操作などの制限付きプロパティの調整のみです。 これらのテーブル内のレコードは、通常のアプリケーション操作によって更新または削除されることはありません。

ディメンション データが共有されるため、この設計が存在します。 複数のモジュールにまたがる複数のドキュメントで、同じディメンション レコードを参照できます。 ディメンション テーブルへの 1 つの外部キーは、さまざまなテーブル間でレコードが参照するデータを表すことができます。 その外部キーの下にある 1 行のデータを変更すると、修正する 1 つのドキュメントだけでなく、 その外部キーのすべての所有者のデータが変更されます。

ディメンション フレームワークでは、すべてのテーブルとすべての行をチェックすることなく、個々の値への参照を保持するテーブルとレコードの数を特定できません。これはマルチプロセスである可能性があります。

変更してはならないテーブル

SQL ステートメント (DELETE、UPDATE、または INSERT) を使用して、次のディメンション フレームワーク テーブルを直接変更しないでください。 名前が "Dimension" で始まり、"Status" という単語が含まれていないテーブルを不変として扱います。

• DimensionAttribute
• DimensionAttributeSet
• DimensionAttributeSetItem
• DimensionAttributeValue
• DimensionAttributeValueSet
• 次元属性値セットアイテム
• DimensionAttributeValueCombination
• DimensionAttributeValueGroup
• DimensionAttributeValueGroupCombination
• DimensionAttributeLevelValue

ディメンション フレームワークは挿入専用であり、レコードを削除しないため、財務分析コードを誤用してシリアル番号、日付、ドキュメント番号などの非常に可変のデータを追跡すると、これらのテーブルが非常に大きくなる可能性があります。 これらの値がトランザクション間で再利用されることはほとんどありません。これにより、フレームワークの重複除去が設計どおりに機能しなくなります。 このパターンの識別と対処に関するガイダンスについては、「 非常に可変のディメンション」を参照してください。

DimensionAttributeValueCombinationStatus テーブルと DimensionAttributeValueGroupStatus テーブルは例外です。 これらのテーブルは、パフォーマンス上の理由だけで存在する検証キャッシュ テーブルです。 データの破損を引き起こさずに切り捨てることができます。 これらを切り捨てると、キャッシュが再構築されるまでのアカウント構造に対する組み合わせの検証にかかる時間にのみ影響します。

DimensionValueDeleteAudit テーブルは、もう 1 つの特殊なケースです。 財務分析コード値のソースとして機能するレコードをバックアップ テーブルから削除するたびに、このテーブルに1行が書き込まれます。 各行は約 2,000 バイトの呼び出し履歴データをキャプチャするため、バッキング テーブルからレコードを一括削除すると、テーブルが急速に拡大する可能性があります。

残高とレポートへの影響

転記済ディメンション データを変更すると、現在のドキュメントだけでなく、それを参照するすべての転記済トランザクションのデータが変更されます。 この変更により、バランスの不一致や、事後の特定とクリーンアップが困難な問題が報告される可能性があります。 ディメンション フレームワークでは参照カウントが維持されないため、影響が発生する前に影響の全範囲を簡単に評価する方法はありません。

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

アプリケーション フレームワークの外部でデータを直接変更しないでください。 たとえば、Microsoft SQL Server Management Studio を使用したり、直接 SQL 書き込み操作を実行したりしないでください。 このガイドラインは、この記事で説明する列だけでなく、テーブルの 任意 の列のデータの変更にも適用されます。 これはさらに、1つの行から別の行へのデータのレプリケーションにも適用され、分析コードフレームワーク ストレージクラスの外部で "新しい" セットまたは組み合わせを作成する処理も対象となります。

参照とハッシュの整合性に影響する可能性があるデータのバックアップと部分的な復元を検討する場合は、このガイドラインを理解してください。 たとえば、台帳ディメンション関連のレコードのみをバックアップして別のパーティションにインポートすると、CustTable テーブルのレコードや組み合わせを作成するために使用された他のテーブルなどのすべてのバッキング エンティティ レコードに加えて、ディメンション フレームワーク内の他のすべてのレコードもインポートしない限り、問題が発生する可能性があります。 これらのテーブル内のデータを変更したり、GUID やハッシュを合成したりしようとすると、データが破損し、破損の原因を見つけて修正を試みるために、複雑で時間のかかる分析が必要になります。

データベース内のバッキング エンティティ値の直接の名前変更 (たとえば、SQL を使用した顧客アカウントまたは部門コードの名前変更) は、ディメンション フレームワークの同期コードを含むバッキング テーブルの .update() メソッドと .renamePrimaryKey() メソッドをバイパスします。 このアクションにより、バッキング エンティティには新しい名前が表示されますが、ディメンション レコードは古い名前を引き続き参照する、矛盾した名前が存在する可能性があります。

ディメンションの表示値がバッキング レコードと既に同期されていない場合は、2 つの方法のいずれかで再同期できます。

オプション 1: データ メンテナンス ポータル (バージョン 10.0.18 以降) を使用する

1. データ メンテナンス ポータルに移動します。
2. [ソース レコードからディメンション データを再構築する] を選択します。
3. 実行を選択します。
4. バッチ ジョブが完了するまで待ちます。 状態が [完了] と表示されると、ディメンションの表示値が基になるバッキング レコードと再同期されます。

オプション 2: アプリケーションを使用してバッキング レコードの名前を変更する

1 つのレコードの場合、アプリケーション UI を使用してバッキング エンティティ値の名前を変更することで、バッチ ジョブを実行せずに再同期をトリガーできます。

1. バッキング エンティティ レコード (顧客や部署など) を開きます。
2. 値の名前を一時的な名前に変更します（例：アンダースコアを先頭に追加して _DEPT001）。
3. レコードを保存します。 このアクションにより、ディメンションの表示値を一時名に同期する .renamePrimaryKey() メソッドがトリガーされます。
4. 値の名前を元の名前に戻し、もう一度保存します。 このアクションにより 2 つ目の同期がトリガーされ、ディメンションの表示値は正しい元の名前と一致します。

この方法は、アプリケーションを通じて保存するたびに、直接 SQL の名前変更によってバイパスされる同期フックが呼び出されるために機能します。

ディメンション フレームワークが内部的にハッシュを使用する方法と、変更によってデータ整合性が中断される理由の詳細については、「 台帳アカウントの組み合わせ」を参照してください。

代わりに実行する操作

転記されたドキュメントのディメンション値が正しくない場合は、ディメンション データではなくドキュメント参照を修正します。 この方法は、システム内の他の共有参照を処理する方法と同じではありません。

次の例を考えてみましょう。間違った仕入先 (ディメンション) にチェック (ドキュメント) を印刷する場合、その変更は、その仕入先に対して既に行われた他のすべてのチェックに影響するため、仕入先レコードを別の ID に変更しません。 代わりに、別の仕入先を指すようにチェック レコードを変更します。

財務ディメンション データにも同じ原則が適用されますが、多くのテーブルやモジュールのレコード間で 1 つのディメンション外部キーを共有できるため、影響が大きくなります。

セット内の 1 つ以上のディメンション値が何らかの理由で正しくない (値が入力されていない、必須ではない、入力時にクリアされる、または正しくない) 場合、適切な修正は次のようになります。

1. アプリケーションで新しい一時ドキュメントを介して、正しいディメンション値のセットを作成します。
2. そのドキュメントの外部キー参照を、問題のある元のドキュメントにコピーします。

この方法により、正しいハッシュと参照整合性を持つフレームワークのストレージ クラスを通じて新しいディメンション データが適切に作成されますが、正しくないドキュメントはシステム内の他のドキュメントに影響を与えずに正しいデータに再ポイントされます。