Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

削除規則

モジュールの複数エンティティ間の関係を作成する場合、レコードを削除する際にどのような参照整合性を使用するのかを定義する必要があります。参照整合性は、エンティティAのレコードが削除されたときそのエンティティAのレコードを参照しているエンティティBのレコードがどうなるかを指定するものです。

以下のエンティティ図は、Customer(主エンティティA)とOrder(関連エンティティB)の関係を定義しています。CustomerにはOrderが複数ある場合があり、Orderは1つのCustomerにのみ属します。参照アトリビュート(データベース用語の外部キーに相当)は、エンティティOrderのアトリビュートCustomerIdです。

この例の場合、参照整合性を指定することで、Customerが削除されたときにCustomerのOrderがどうなるかを定義することができます。

2つのエンティティ間の関係で参照整合性を指定するには、関連エンティティの参照アトリビュートを編集し、Delete Ruleプロパティの値をProtectDeleteIgnoreのいずれかの値に設定する必要があります。

Protect

Delete RuleProtectに設定した場合、関連エンティティ内に関連するレコードがある間、主エンティティのレコードは削除されません。

この動作は、参照アトリビュートに作成されたデータベース制約によって保証されます。関連エンティティに関連するレコードをまだ持っている主エンティティのレコードを削除しようとすると、Platform Serverがデータベース例外を返し、操作は実行されません。

Delete(削除)

Delete RuleDeleteに設定した場合、主エンティティのレコードを削除したとき、関連エンティティ内の関連するレコードもすべて削除されます。この仕組みは一般的に「カスケード削除」として知られています。

この動作は、参照アトリビュートに作成されたデータベース制約によって保証されます。

Ignore

Delete RuleIgnoreに設定した場合、主エンティティのレコードを削除したとき、関連エンティティ内の関連するレコードは保持されます。

Ignore値では参照整合性が保証されないため、データベース制約は作成されません。そのため、Delete Ruleプロパティを前の値からIgnoreに変更した場合、対応する自動インデックスは削除されます(いずれかのプロパティを手動で変更した場合を除きます)。

拡張機能によって公開されている外部エンティティを外部キーのアトリビュートが参照している場合、参照整合性を保証することができないため、使用可能なDelete Ruleプロパティの値はIgnoreのみです。

エンティティモデルを設計する際、複数の関係のDelete Ruleを適切に設定し、システムが各ユースケースで期待どおりに動作するようにする必要があります。ユースケースに応じた適切な選択を行うために役立つ、各オプションの例と考慮事項を以下に示します。

「Protect」の例

Protect値がよく使用されるのは、エンドユーザーがアプリケーションの画面から直接エンティティデータを削除できる場合です。

以下のビジネスシナリオについて考えてみます。

  • エンドユーザーがCustomerを削除できるアプリケーション画面があります。

  • CustomerにはOrderが複数ある場合があり、Orderは1つのCustomerにのみ属します。

  • 関連するOrderがある場合、Customerを削除することはできません。

参照アトリビュートCustomerIdDelete RuleプロパティをProtectに設定すると、エンドユーザーは関連するOrderが残っているCustomerを削除できません。

関連するOrderが残っているCustomerを削除しようとすると、データベース例外を返し、操作は実行されません。

この場合、Customerを削除するには、そのCustomerによって行われたOrderを先にすべて削除する必要があります。

この方法は、delete文を個別に制御および最適化することができ、データの整合性も確保されるため、パフォーマンスに優れています。より優れた制御とパフォーマンスを得ようとすると、実装コストが高くなるため、どちらかを優先する必要があります。

利点

  • 関連エンティティで参照されている主エンティティのレコードは削除できないため、常にデータモデルの整合性が確保されます。

制約

  • ロジック内で削除の順序が適切になるように調整する必要があります。関連エンティティのレコードを先に削除してから主エンティティのレコードを削除する必要があります。

  • モデルに新しい関連エンティティを追加するたびに、その関連エンティティを削除サイクルロジックに含める必要があります。

「Delete」の例

Delete値がよく使用されるのは、データパージメカニズムを実装するときに、モデル全体の間で自動カスケード削除を行う必要がある場合です。

通常、データパージメカニズムは非同期プロセス(タイマーまたはBPT)によって処理されるため、パフォーマンスには影響を及ぼしません。

以下のビジネスシナリオについて考えてみます。

  • 5年以上前の終了済みのOrderをすべて削除します。

  • OrderにはOrder_Itemが1つまたは複数あり、Order_Itemは1つのOrderにのみ属します。

  • Orderが削除されたときに、関連するOrder_Itemもすべて削除される必要があります。

参照アトリビュートOrderIdDelete RuleプロパティをDeleteに設定すると、Orderが削除されたときに関連するOrder_Itemもすべて自動的に削除されます。

利点

  • 常にデータモデルの整合性が確保されます。主エンティティのレコードを削除すると、関連エンティティの関連するレコードもすべて削除されるため、関連エンティティでレコードが参照されなくなります。

  • 主エンティティレベルでのみレコードを削除すればよいため、削除ロジックの開発と保守を簡単に行えます。

  • 参照アトリビュートのDelete RuleDeleteに設定するだけでよいため、新しい関連エンティティをモデルに追加するときの開発労力が少なくてすみます。

制約

  • 関連レコードの数によってパフォーマンスが低下する可能性があります。削除操作のたびに関連エンティティの関連レコードを確認するため、delete文の実行に時間がかかります。このため、エンティティモデルが複雑でパフォーマンスが重要である場合(エンドユーザーがアプリケーションの画面から直接エンティティデータを削除できる場合など)、この方法は推奨されません。

「Ignore」の例

Ignore値がよく使用されるのは、履歴データアーカイブメカニズムを実装するときに、主エンティティのレコードは削除するが、主レコードの詳細に関連性がないことを考慮して、関連エンティティのレコードをすべて保持する必要がある場合です。

以下のビジネスシナリオについて考えてみます。

  • Orderに対して実行されたすべての操作のログがOrder_Historyに記録されます。

  • 1つのOrder_Historyレコードは1つのOrderにのみ関連し、1つのOrderに関連するOrder_Historyレコードは1つまたは複数あります。

  • 5年以上前の終了済みのOrderをすべて削除します。ただし、コンプライアンス上の理由により、Order_Historyレコードを10年間保持する必要があります。

参照アトリビュートOrderIdDelete RuleプロパティをIgnoreに設定すると、Orderを削除しても、関連するOrder_Historyレコードを保持することができます。

利点

  • 関連エンティティに影響を及ぼすことなく、主エンティティのレコードを削除することができます。

制約

  • この方法では、データモデルが不整合になります。関連レコードは保持されますが、主レコードの詳細を取得することはできず、取得できるのは識別子のみになります。

  • 参照アトリビュートのDelete Ruleプロパティを前の値からIgnoreに変更した場合、対応する自動インデックスは削除されます。参照アトリビュートをクエリフィルタとして使用する場合、新しいインデックスを手動で追加する必要があります。

  • Was this article helpful?