論理削除か物理削除か

久しぶりにITの話をしたいと思います。情報システムには多くの場合リレーショナルデータベース(RDB)を利用しています。たとえスマートフォンのアプリであっても内部で組込み用のRDBを使っていることがあります。

RDBではテーブルという単位でデータの鋳型を定義して、その鋳型で出来る実際のデータはレコードと呼んでいます。レコードが不要になった時、レコードを削除するとその情報は消えてしまいます。一方で「削除したよ」という情報を付与するだけでレコード自体を残すことがあります。この場合、俗に前者を物理削除、後者を論理削除と呼んでいます。実はこの両者が、DB設計において一つのテーマであります。

それぞれのメリットとデメリット

というのも、物理削除の場合、一旦消してしまうとバックアップデータから復元するしかありません。もしバックアップデータが無ければ復元する方法はなく、必要ならもう一度登録し直さなければなりません。

また、論理削除の場合、うっかり削除してしまっても簡単に復元することができますが、本当に不要になっても完全に削除することが出来ず、ゴミ(不要なデータのことを俗にこう呼びます)が残ります。その場合、別に物理削除を行う手段を設ける必要があります。

操作画面上で「削除」というボタンが有った場合に、物理削除の場合は確認ダイアログを表示して本当に削除して良いかしつこいくらいに尋ねる必要があります。しかし論理削除の場合は確認なしに削除してしまっても簡単に復元できるので、結果として操作画面の利便性は向上することになります。

つまり、たかがDB設計なのですが、論理削除か物理削除かというのは運用設計や画面設計とも密接に絡んでくる複雑な話なのです。

私はRDBを学び始めて間もない頃、あるいくつかの現場では全てのテーブルに削除フラグを設けているRDBを見たことがあります。その影響もあって私は全てのテーブルに削除フラグを設ける方針で他の現場でもDBを設計していました。事実、内部統制が緩い現場においてうっかりの操作ミスが多く、論理削除を採用していたことによって何度も助けられたことがあります。しかし一方で次のような課題もお客様から突き付けられました。

  • 間違えて登録したデータを完全に削除できないのは困る。
  • あるデータに関しては通常の運用で完全に削除したい。

論理削除か物理削除かを決めるもう一つの観点は、取り扱うデータが情報資産であるかどうかです。情報資産というのはデータの所有者が、それを保有することに価値を見出している情報という意味です。一定の役目を終えたからと言って完全に削除してしまうと、新たなデータの参考にすることすらできなくなります。その場合は論理削除が良いのではないかと思っています。

削除フラグと設計方針

そもそも「論理削除」の業務的(仕様的)な意味は何でしょうか。もし本当に論理的に削除したということ以上の意味が無ければそれでも良いかもしれませんが、本当にそうでしょうか。良く考えてみると実際には「一時的に非表示にした」「公開を終了した」「有効期限を過ぎた」「処理が終了した」「退会した」といった意味があるのではないでしょうか。そうすると、論理削除を表すには「削除フラグ」よりも「公開フラグ」や「表示フラグ」「処理済みフラグ」という呼称の項目を設けた方が良さそうですね。あるいはそれらを複合的に取り扱う「ステータス」という項目を設けてもいいかもしれません。

また別のアプローチとして有効期間の開始日時と終了日時、公開期間の開始日時と終了日時を管理するという方法もあります。この場合、クエリー(問合せ)は多少煩雑にはなりますが、緻密な管理が実現できます。

ステータス管理が必要なデータは適切な管理項目を設けてステータスを変更し、単純な間違いなどのゴミデータは物理削除できるようにする。そして、ステータス管理の必要のないデータはそのまま物理削除するというのが現実的な方針かなと思っています。いずれにせよ、条件反射のようになんでもかんでも削除フラグというのではなく、きちんとデータの特性を考えて設計する必要がありますね。

「人気店はバーゲンセールに頼らない」齊藤孝浩 著

本書はインディペンデント・コントラクター協会の理事のお一人である齊藤孝浩さんの著作です。齊藤さんはいわゆるアパレル業界のコンサルタントで、商品陳列や適正在庫といったカテゴリでご活躍をされている方です。個人的にはいつもIC協会のイベント等でお世話になっております。

本書は誰もが知っているような国内外のアパレルチェーンにおける成功事例を集めた本です。私はアパレル業界には疎いのですが、そんな人でも本書を読めばアパレル業界のトレンドに詳しくなり、明日からでもアパレルチェーンを展開できてしまうのではないかと錯覚してしまいそうになるほど具体的なノウハウが詰まっています。もしかしたら業界内では普通に知られていることばかりなのかもしれませんが、ブランド名を明示しているので外の人間からするとそんなことまでバラしちゃっていいの?と思ってしまいます。明日は用も無いのにZARAに行ってみたくなりました。(実はまだ行ったことありません。)

さて、私が本書を読んで感じたポイント。それは本文でも触れられていることなのですが、成功する秘訣は業務のサイクルの短さだということ。いわゆるPDCAを週単位で回せるというのは月単位、四半期単位、半期単位で回している企業にとっては脅威でしょう。また、本書では言及されていませんが、ここに挙げられた事例は制約理論(TOC)を実践した実例なのではないかと思われます。特に、エリヤフ・ゴールドラット博士晩年の著作である「ザ・クリスタルボール」。そのテーマはまさに小売業における適正在庫であって、そこに書かれていることを実践したとしか思えません。

本書は、今まさにアパレル業界で働いている人はもちろん、これからアパレル業界で働きたいと思っている人にとっては必読の書ですし、直接関係ないと思われる人でも本書にはビジネスにおけるヒントを多く得られると思います。また、特に女性の方に対しては、本書を読めばまた違ったショッピングの楽しみ方が出来るのではないかと思います。まずは是非手に取ってみてください。

あと、私の関心は本書の内容を逸脱して、成功した企業が行っているオペレーションが素晴らしいだけでなく、このようなオペレーションを可能にした組織がありますが、そのような組織を作り上げたその方法論を私は知りたいと思いました。また、成功に至る判断のためには迅速で的確なフィードバックが不可欠ですが、その背後にはそれを可能にした情報システムがあるはずです。それらがどのようなシステムなのか、どのような処理でどのようなアーキテクチャなのかということにも興味が及びました。そういったチームビルディング、システム設計といった側面を取り扱った姉妹編が出版されたら間違いなく買ってしまいますね。

――――
書名:人気店はバーゲンセールに頼らない
副題:勝ち組ファッション企業の新常識
著者:齊藤孝浩
発行:中央公論新社/2013年4月10日
ISBN:978-4-12-150451-7


ファッション流通ブログde業界関心事 (齊藤さんのブログ)


クラウド事例を発表させていただきました

4月8日(月)に西新宿でTOCfEの月例勉強会に参加いたしました。これは先月初めて参加させていただいた集いなのですが、その時はどんなことをやるのか知らないままに誘われ手ぶらで参加したところ、参加者の皆さんの事例発表があまりにも素晴らしく、私も自己完結した事例ではなく相手がいる状況で実践した事例を作りたいと思わされたのです。その日、家に帰って早速クラウドを試してみて、紆余曲折はあったものの丸く収まり、今回その成果を発表させていただきました。

私は基本的にグローバルオプティマム社の飛田さんに教わっただけですのでよく知らなかったのですが、クラウドにもいくつか流儀があるのだそうです。クラウドを描くときに「AであるためにはBである必要がある」と読み上げるのですが、それに加えて「なぜならば・・・」とその前提条件を続ける方法もあると。方法もあるというよりは、少なくとも意識はしていた方がうまく行きそうではありました。次はそのようにやってみたいと思います。

もう一つアドバイスを頂いたのはDとD’の書き方。今回私が試したのは最初は主語がはっきりしておらず、そのことに途中で気が付いて明記するようにしたというお話をさせていただきましたが、DとD’に限らずBとCも主語(誰の立場なのか)を明記した方が認識のずれが発生しないということでしたので、これも次回はそのようにやってみたいと思っています。

私以外に数人の方が発表されたのですが、TOCfEの全てのツール(クラウドとブランチとアンビシャス・ターゲット・ツリー)について万遍無く事例があり、私にとって大変濃度の高い勉強会となりました。特にブランチ。これは済んでしまったことですが、一度ブランチを描いて因果関係を分析したい題材があるので、時間を作ってチャレンジしたいと思います。