「コード体系はユーザインターフェイスである」とはどういうことか

RDB モデリング

今、複合キー論・ID論・コード体系論が熱い！
トラックしてるけど流れが速くてついていけない。地道に整理する。
まずは羽生氏の言う「コード体系はユーザインターフェイスである」の意味がわかったと思うのでメモ。
多分こういうこと：

「コード体系はユーザインターフェイスである」とはどういうことか

  • コードは、ユーザが欲しいデータを一撃で取得するためのキーである。
  • コードは、ユーザが設定したいデータを一撃で入力するためのキーである。
  • 要するに、コードはユーザが業務を効率的に行うための道具である。システムが内部で使うためのものではない。
  • コードは一意性を必ずしも保障しない(例:「その他」を示すコード。あるいは支店間で伝票番号が重複している会社)。
  • コードは不変ではない。
  • よって、コードは外部キーにはなれない。

コードを捏造すると便利な状況

コードは単なるUIである（＝外部キーにはなれない！）という前提に立てば、SEが名前に対してコードを振るべき状況は限定される。

  • 名前が変わることがある
  • 名前が重複している
  • 名前がない
    • 例：伝票一枚にいちいち「伝票名」なんて付けるわけがない。伝票番号が必要
  • コードの方が名前より入力が速い
    • 例：伝票入力画面で、いちいちIMEを使って勘定科目名を入力したくない。テンキーだけで入力したい
  • コードの方が名前より分かりやすい
    • 例：類似の部品や製品がたくさんあるときに、名前で識別しようとするとかえってわかりにくい。違うものを発送してしまいそう

コードなんて要らない状況

以上の状況に当てはまらない場合は、ユーザに見せるコードを捏造する必要がない。resource なり event なりを、ユーザが今使っている名前で管理すればよい。
例えば倉庫が２つしかないときに、「倉庫コード」なるものを振ってみても、ユーザから見て入力や検索が便利になるわけではない。
ユーザには「札幌倉庫」「小樽倉庫」のような名前で倉庫の個体識別をしてもらえばよい。
システム内部で一意性の保障が必要なら、それぞれの倉庫にIDを振って、そのIDを外(画面や帳票)に漏らさなければよい。ユーザに見せなければよい。


ただしこれはGUI前提の考え方。
「札幌倉庫」「小樽倉庫」をコンボボックスで指定する世界の話。
COBOLだったら「1. 札幌倉庫」「2. 小樽倉庫」という選択肢を提示して、ユーザに1か2を入力させるのだろう。多分。
だから、COBOLならコードの捏造が必要。

SEが捏造したコードと、IDとの違い

SEが捏造したコードと、IDとの違いは、画面や帳票に漏れ出ているかどうかだけのこと。
GUI前提ならコードの捏造は必要ない。顧客の了承なしに、勝手にIDを振ればいい。