データを削除/削除する前に考慮すべきこと Issue この記事で提供される情報では、ユーザー/アドミンがインスタンスからデータを削除する前の考慮事項について詳しく説明します。対象となる 2 つの領域は 参照データ損失 と カスケード削除です。 参照データの損失 Now Platform の参照フィールドは、sys_idに基づいてレコードの表示値を返すディクショナリタイプのフィールドであり、テーブルを参照する参照フィールドがあるテーブルからレコードが削除されるときに発生します。 たとえば、あるユーザーが会社レコードをクリーンアップした後、誤って Company ABC という会社レコードを削除してしまったとします。 結果:このレコードが削除されると、この会社レコードのデータを持つインスタンス内のすべての参照フィールドが NULL に設定され、sys_id値が 会社 ABC に割り当てられていたすべてのフィールドのインスタンス全体のすべての参照データが削除されます。 null にする参照フィールドを決定する方法 次の手順を実行して、core_company テーブルの 会社 ABC レコードが削除された例に基づいて、影響を受ける参照フィールドを特定できます。 sys_dictionary.list に移動次のフィルターを作成します。 [タイプ] [次の値に等しい (is)] [参照 (Reference)]AND [参照] [次の値に等しい] [会社]AND [参照カスケードルール] [次の値に等しい] [--なし--]OR [参照カスケードルール] [次の値に等しい] [クリア]このフィルターは、レコードの削除が発生したテーブルを参照し、フィールドの値が null になることを識別する、インスタンス内のすべての参照フィールドを返します。 提供された結果セットは、値 会社 ABC がフィールドに保存されている場合に、これらの各フィールドが null に設定されることを示しています。クエリの OOB の例を次に示します。 結果セットに基づいて、値「会社 ABC」がリストされた参照フィールドに格納されている場合に null に設定される可能性のあるフィールドが 211 sys_dictionary 9 個あることがわかります。 カスケード削除 参照データの損失に加えて、バックグラウンドでのカスケード削除の可能性があり、その結果、ユーザー/アドミンが認識していない可能性のある追加のレコードが削除されます (カスケード削除の詳細については、製品ドキュメントページ カスケードルール) の次のドキュメントを参照してください)。カスケード削除は、「参照カスケードルール」と呼ばれるsys_dictionaryの特定のフィールドにカスケードルールが定義されている場合に発生します。上記の例では、追加のクエリを実行して、core_companyテーブルからレコードを削除するときに予想されるカスケード削除があるかどうかを特定できます。 予想されるカスケード削除を決定する方法 sys_dictionary.list に移動のフィルターの作成 [タイプ] [次の値に等しい (is)] [参照 (Reference)]AND [参照] [次の値に等しい] [会社]AND [参照カスケードルール] [次の値に等しい] [削除]このフィルターは、会社レコードが削除されたときに発生する可能性のあるすべてのカスケード削除を返します。 結果セットは、会社レコードを削除するときに実際にはカスケード削除がないことを示しています。参照カスケードルールの null 値と「Clear」の値は、基本的に、これらのフィールドの値が単に null になることを示します。この場合、参照データの損失のみが発生します。 カスケード削除が予想される例を次に示します。 このフィルターは、構成アイテム (cmdb_ci) レコードが削除された場合に発生する可能性があるカスケード削除が 86 件あることを示しています。ユーザー/管理者が注意すべきことは、カスケード削除は本質的にスパイダーウェブ効果であり、カスケード削除が発生したすべてのテーブルにカスケードルールが定義されている可能性があるため、削除が増える可能性があるということです。 ユーザー/管理者は、インスタンスからデータを削除するときは十分に注意する必要があります。データの削除が必要な場合は、本番インスタンスで削除を行う前に、必ず準本番環境でテストする必要があります。ユーザー/アドミニストレーターは、このようなアクションを実行する前に、考えられる削除の影響を確認することが重要です。