私は現在、ユーザーレコードの削除に対処するために、DPAとEU GDPR Right Forgottenなどの要件に対処するために、ユーザーレコード間の参照整合性を強制しないことを提案しているデータベース設計を検討していますトランザクション、通信イベントなどの「関連」テーブルが含まれているため、要求されたときにユーザーレコードを削除できますが、（非識別キー/シーケンス番号を使用する）関連テーブルのレコードはそのまま残ります。これまでユーザーレコードの削除を忘れてしまったというデータベースデザインの参照整合性を削除しても問題ありませんか？
私はこれを後にして「議論」を開く前に、誰かがこのような場合に参照整合性を削除することが可能であると考えていたかどうか、ユーザーの詳細をマスキングするか、ユーザーレコードをプレースホルダレコードに変更して、トランザクションが編集されたユーザーに関連していることを示すなどの方法を使用できます。
すべてのご意見をお待ちしております。
これは、参照整合性の制約を超える複雑なトピックです。
EUのプライバシーの制限（私は弁護士ではないことを強調します）は、個人的に識別可能な情報に関連するものであり、ビジネスに関連する「匿名」関係には関係しません。たとえば、削除されたユーザーは、アクティブな期間の「アクティブ」として数えることができます。彼らは誰なのか分かりません。
私のアプローチは、すべてのPIIデータを単一のテーブル/データベースに入れることです。ユーザーが忘れてしまった場合は、PIIを削除するためにレコードを更新します。したがって、すべての外部キーの関係は問題ありません。名前、住所、電子メールアドレス、およびPIIとみなされているものがすべて不足しています。
メールアドレスとユーザー名などが最も一般的でない場所に埋め込むことができるため、PIIを識別することは非常に難しいです（URLは見た目の明白な場所ですが、他にもある可能性があります）。
実際には、すべてのデータベースから人の痕跡をすべて削除することはお勧めしません。レポートがもはや均衡しなくなる状況になります。 。 。ああ、私たちの報告によれば、1,000,000人の顧客がいると言われましたが、999,900人しか見つけることができませんでした。何が起こったのかを把握するための人々の努力を無駄にしましょう。
私の提案：注意してください。これは長いプロセスであり、それに応じて組織の期待を設定します。
業界の保存法をご覧ください。人々は忘れられる権利を持っていますが、ある期間レコードを保持する法的義務もあります。
この時点でどの規則が別の規則を破棄しているかわかりませんので、私のアドバイスはこの問題を解決できる法律専門家を連れてくることです。
技術的な観点から、アプリケーションではプライベートデータに関連するビジネスデータが必要な場合があります。そのため、レコードを忘れているとフラグを立てて、プライベートデータを生成データに置き換えてください。このように、アプリケーションは同じように動作しますが、個人情報はなくなります。
これは、プロセスとして自動化された多くのレガシーアプリケーションに適用できる単純なアプローチです。
注意しなければならないのは、バックアップからデータを復元する必要がある場合、変更が元に戻される可能性があるためです。レコードを指し示すキーを持つ別のテーブルを忘れたままにする必要があります。バックアップが最新の変更を上書きする場合は、オートメーションスクリプトを再度使用して、忘れてしまったものを取り除くことができます。
私はその法律に精通していませんが、可能であれば、「このユーザーを忘れてください」という意味の「ユーザー」テーブルのフラグを使用したいと考えています。このようにして、ユーザーは通常の処理では表示されませんが、召喚状などを遵守するなどの社内処理では利用できるようになります。 – TommCatt
@TommCatt。 。 。残念ながら、それは間違いなくEUの法律では十分ではありません。 –