第10章 ガイド付きデシジョンテーブルのリアルタイム検証および妥当性確認
Business Central は、ガイド付きデシジョンテーブルにリアルタイム検証および妥当性確認を提供し、テーブルのエラーがなくなったことを確認します。ガイド付きデシジョンテーブルは、各セルが変更するたびに妥当性が確認されます。ロジックに問題が検出されたら、エラー通知が表示され、問題を確認できます。
10.1. ガイド付きデシジョンテーブルの問題の種類
検証および妥当性確認の機能は、以下のタイプの問題を検出します。
- 冗長性 (Redundancy)
- 冗長性は、デシジョンテーブルの 2 つの行で、同じファクトセットの同じ結果を実行する際に生じます。たとえば、顧客の誕生日をチェックして誕生日割引を提供する行が 2 つあると、割引は 2 倍になる可能性があります。
- 包含 (Subsumption)
包含は冗長と似ていますが、2 つルールが同じ結果を実行し、1 つのルールがもう 1 つのルールのファクトのサブセットに対して実行する場合に生じます。たとえば、以下の 2 つのルールを見てみましょう。
- when Person age > 10 then Increase Counter
- when Person age > 20 then Increase Counter
この場合、対象者の年齢が 15 歳の場合はルールが 1 つだけ実行しますが、対象者の年齢が 20 歳を超えてる場合は 2 つのルールが実行します。これにより、実行時に冗長性の場合と同様の問題が生じます。
- 競合 (Conflict)
2 つの類似した条件が異なる結果をもたらす場合は、競合する状況が発生します。デシジョンテーブルの 2 つ行の (ルール) または 2 つのセルの間で競合が発生する場合があります。
以下の例は、デシジョンテーブルの 2 つの行で競合が発生しているのを示しています。
- when Deposit > 20000 then Approve Loan
- when Deposit > 20000 then Refuse Loan
この場合は、ローンが承認されるかどうかについて確認することができません。
以下の例は、デシジョンテーブルの 2 つのセル間の競合を示します。
- when Age > 25
- when Age < 25
競合セルを持つ行は実行しません。
- Unique Hit ポリシーの違反 (Broken Unique Hit Policy)
Unique Hit ポリシーをデシジョンテーブルに適用する際は、同時に 1 行しか実行できず、各列は一意であり、満たした条件が重複しないようにする必要があります。複数の行が実行した場合は、検証レポートが、違反したヒットポリシーを特定します。たとえば、価格の割引資格を決定するテーブルで、以下の条件を見てみましょう。
- when Is Student = true
- when Is Military = true
顧客が学生であり、軍隊に所属している場合は、両方の条件が適用され、Unique Hit ポリシーに違反します。したがって、この種のテーブルの行は、一度に複数のルールを実行できないように作成する必要があります。ヒットポリシーの詳細は、5章ガイド付きデシジョンテーブルのヒットポリシー を参照してください。
- 欠陥 (Deficiency)
欠陥は競合と似ていますが、デシジョンテーブルのルールのロジックが未完成の場合に生じます。たとえば、欠陥がある以下の 2 つのルールを見てみましょう。
- when Age > 20 then Approve Loan
- when Deposit < 20000 then Refuse Loan
この 2 つのルールは、20 歳を超え、預金が 20000 より少ない場合に混乱が発生する場合があります。さらに制約を追加すると、競合を避けることができます。
- 列の欠落 (Missing Column)
- 列を削除したため、不完全または不正確なロジックが発生した場合は、ルールが正しく発生しません。これを検出し、不足している列に対処したり、ロジックを調整して、意図的に削除した条件またはアクションに依存しないようにすることができます。
- 不完全な範囲 (Incomplete Ranges)
- 可能なフィールド値に対する制約がテーブルに追加されているにもかかわらず、可能な値がすべて定義されていない場合は、フィールド値の範囲が不完全です。検証レポートは、提供された不完全な範囲を特定します。たとえば、アプリケーションが承認されたかどうかをテーブルが確認した場合は、検証レポートにより、アプリケーションが承認されていない状況も処理できるようになります。
