データ検証ルールのシナリオ

これらのシナリオは、データ検証がビジネス・ポリシーの実装にどのように役立つかについての例となります。

シナリオ1

Johnは、Acme, Incという会社で働くコンサルタントで、フォームを設計したり、会社のポリシーを実施するデータ検証ルールを実装しています。彼は、実際のコスト合計が予算額を超えたときに実績額を赤色で示す検証ルールを実装するよう求められました。このテストは、アプリケーションで年度および期間ごとに繰り返す必要があります。Johnは、次の図のようにフォームを設計し、ディメンション間メンバーを使用してセル・レベルにデータ検証ルールを追加しました。

設計時のフォームのレイアウト:

設計時のデータ検証ルール:

データ検証が適用されたデータ入力時のフォーム:

ヒント:

Johnは、コスト合計を分割して独立したセグメントとし、このセグメントにデータ検証ルールを適用することにより、パフォーマンスをわずかに向上させることができます。ただし、これを行うと、新規のアカウントとシナリオがフォームに追加されるためにメンテナンス作業が増えます。
「実績」の年合計期間のみを赤色で示すというように要件が変更された場合、Johnには2つのオプションがあります。最善のオプションは、年合計が「期間」メンバーであるかどうかをチェックするIFエントリを追加する方法です。もう1つのオプションは、年合計メンバーを分割して独立した列とし、パフォーマンスを向上させる方法です。ただし、これを行うと、分散ロジックが破綻し、「年」の列ヘッダーが繰り返されるため、新規年度が追加されるにつれてフォームのメンテナンスがより困難になります。

シナリオ2

シナリオ1でJohnによって設計されたフォームをレビューした後、Acmeは、「予算」を行ではなく列として配置することにしました。この要件を実装するには、Johnは、軸内でメンバーを移動してフォームのレイアウトを変更できます。ただし、データ検証ルールを更新する必要はありません。Johnは、次の図のようにフォームを更新しました。

設計時のフォームのレイアウト:

データ検証が適用されたデータ入力時のフォーム:

シナリオ3

これらのフォームを正常にロール・アウトした後、Johnは、次のポリシーを実装するよう求められました。それは、今年度の予算金額が前年度の実績金額を大幅に超えないことを確認するためです。差が5%を超える場合、差が赤色で示されます。

Johnは、メンバー式を持つメンバーを使用して、今年度の予算金額と前年度の実績金額の差異を計算することにしました。次のメンバー式を追加しました:

@varper(@Prior("Actual", 1, @Relative("Year", 0)), budget)/100;

Johnは、次の図に示すようにフォームを設計し、セル・レベルでデータ検証ルールを追加しました。Johnは、「メンバー名」を使用して検証をコスト合計にのみ適用しました。

設計時のフォームのレイアウト:

設計時のデータ検証ルール:

データ検証が適用されたデータ入力時のフォーム:

ヒント:

Johnがアウトラインの変更を許可されていない場合、またはメンバー式のパフォーマンスに問題が発生した場合、式の列を使用できます。式の行と列を使用したフォームの設計を参照してください。
Johnは、次の理由により、このルールを「差異の割合(%)」列に定義します。
- パフォーマンスが向上します。ルールは、「差異の割合(%)」列のセルにおいてのみ評価されます。これに対し、ルールが年合計に割り当てられている場合は、今年度の予算についてすべての期間でルールを評価することが必要になってしまいます。
- ユーザーがデータ検証メッセージに対応しやすくなります。Johnは、差異が大きいという内容のメッセージを、年合計に追加するのではなく、「差異の割合(%)」列に追加できます。これにより、ユーザーは、差異を確認するために「差異の割合(%)」を探さなくてすみます。
年合計と「差異の割合(%)」の両方を赤色で示すことが要件の一部であった場合、Johnは両方を赤色で示すことができます。

シナリオ4

セルを赤色で示すのみでなく、今年度の「予算」が前年度の「実績」金額より大幅に多い(> 5%)場合に、承認ユニットを移動できないようにすることも必要です。この要件を実装するためにJohnに必要な作業は、次の図に示すように、データ検証ルールの処理命令を編集し、「移動しない」を選択することです。

設計時のデータ検証ルール:

シナリオ5

最後に、Johnは、特定部門の従業員の合計報酬が許容範囲内に収まっているかどうかを検証するデータ検証ルールを設計するよう求められました。このルールにより、「運用」部門の「既存の従業員」を評価します。このルールでは、「合計報酬」が許可された「最小」より大きく、従業員の等級に応じた報酬範囲の4分の3以下である場合、アクションは必要ないと認定します。

「合計報酬」が報酬範囲の4分の3を超える場合、検証メッセージが表示され、承認ユニットは人事部長の承認を受ける必要があります。この値が「最小」より小さい場合や、「最大」より大きい場合は、エラーが生成され、ユーザーはその承認ユニットを移動できません。

Johnは、「フォームの管理」ダイアログ・ボックスから従業員費用サマリーフォームを開きました。このフォームでは、ページに従業員と部門、行に勘定科目(「合計報酬」など)、および列として期間があります。検証を構築しやすくするために、Johnは、次の図に示すように、報酬範囲の4分の3を計算するための計算行を追加し、フォームに最小報酬および最大報酬メンバーを追加しました。従業員の等級に応じた最小報酬および最大報酬は、メンバー式を使用して計算されます。

設計時のフォームのレイアウト:

承認ユニットの移動を阻止するデータ検証ルール:

人事部長を確認者として追加するデータ検証ルール:

データ検証が適用され、検証メッセージが表示された、データ入力時のフォーム: