久しぶりにITの話をしたいと思います。情報システムには多くの場合リレーショナルデータベース（RDB）を利用しています。たとえスマートフォンのアプリであっても内部で組込み用のRDBを使っていることがあります。
RDBではテーブルという単位でデータの鋳型を定義して、その鋳型で出来る実際のデータはレコードと呼んでいます。レコードが不要になった時、レコードを削除するとその情報は消えてしまいます。一方で「削除したよ」という情報を付与するだけでレコード自体を残すことがあります。この場合、俗に前者を物理削除、後者を論理削除と呼んでいます。実はこの両者が、DB設計において一つのテーマであります。
それぞれのメリットとデメリット
というのも、物理削除の場合、一旦消してしまうとバックアップデータから復元するしかありません。もしバックアップデータが無ければ復元する方法はなく、必要ならもう一度登録し直さなければなりません。
また、論理削除の場合、うっかり削除してしまっても簡単に復元することができますが、本当に不要になっても完全に削除することが出来ず、ゴミ（不要なデータのことを俗にこう呼びます）が残ります。その場合、別に物理削除を行う手段を設ける必要があります。
操作画面上で「削除」というボタンが有った場合に、物理削除の場合は確認ダイアログを表示して本当に削除して良いかしつこいくらいに尋ねる必要があります。しかし論理削除の場合は確認なしに削除してしまっても簡単に復元できるので、結果として操作画面の利便性は向上することになります。
つまり、たかがDB設計なのですが、論理削除か物理削除かというのは運用設計や画面設計とも密接に絡んでくる複雑な話なのです。
私はRDBを学び始めて間もない頃、あるいくつかの現場では全てのテーブルに削除フラグを設けているRDBを見たことがあります。その影響もあって私は全てのテーブルに削除フラグを設ける方針で他の現場でもDBを設計していました。事実、内部統制が緩い現場においてうっかりの操作ミスが多く、論理削除を採用していたことによって何度も助けられたことがあります。しかし一方で次のような課題もお客様から突き付けられました。
- 間違えて登録したデータを完全に削除できないのは困る。
- あるデータに関しては通常の運用で完全に削除したい。
論理削除か物理削除かを決めるもう一つの観点は、取り扱うデータが情報資産であるかどうかです。情報資産というのはデータの所有者が、それを保有することに価値を見出している情報という意味です。一定の役目を終えたからと言って完全に削除してしまうと、新たなデータの参考にすることすらできなくなります。その場合は論理削除が良いのではないかと思っています。
削除フラグと設計方針
そもそも「論理削除」の業務的（仕様的）な意味は何でしょうか。もし本当に論理的に削除したということ以上の意味が無ければそれでも良いかもしれませんが、本当にそうでしょうか。良く考えてみると実際には「一時的に非表示にした」「公開を終了した」「有効期限を過ぎた」「処理が終了した」「退会した」といった意味があるのではないでしょうか。そうすると、論理削除を表すには「削除フラグ」よりも「公開フラグ」や「表示フラグ」「処理済みフラグ」という呼称の項目を設けた方が良さそうですね。あるいはそれらを複合的に取り扱う「ステータス」という項目を設けてもいいかもしれません。
また別のアプローチとして有効期間の開始日時と終了日時、公開期間の開始日時と終了日時を管理するという方法もあります。この場合、クエリー（問合せ）は多少煩雑にはなりますが、緻密な管理が実現できます。
ステータス管理が必要なデータは適切な管理項目を設けてステータスを変更し、単純な間違いなどのゴミデータは物理削除できるようにする。そして、ステータス管理の必要のないデータはそのまま物理削除するというのが現実的な方針かなと思っています。いずれにせよ、条件反射のようになんでもかんでも削除フラグというのではなく、きちんとデータの特性を考えて設計する必要がありますね。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。