« 「危ないデータモデル」の定量的判定基準 | トップページ | 部門と従業員のデータモデリング »

2019.03.26

開発者が「コード体系」に関与する必要はない

 「コード体系」をどうすべきかについて相談されることがある。商品コード、品目コード、得意先コードといったマスター系テーブルの主キー項目の各桁にどんな意味合いを持たせたらいいのか、という問題だ。私はいつもこう答える。「コード体系についてはユーザサイドで勝手に決めてもらってけっこうです。ただし、コードのいずれかの桁を切り出すような操作を、システムに組み込むことはしません」

 かつてシステム開発者にとって、コード体系を定めることは重要な仕事だった。生産管理システムに関する古い本を開くと、コード体系について多くのページが割かれている。品目コードのあり方だけを扱う本さえあった。しかし時は流れ、コード体系は開発者が関わるべき問題ではなくなった。

 なぜか。順を追って説明しよう。ずいぶん昔の話だが、商品や製品は「少品種大量生産」を旨として企画されていた。ユーザがそれらのコードを入力することで、製造指示や出荷指示がなされていた。その際、処理対象を指し示すコードの体系をどうするかは重大な問題だった。たとえば「上3桁は商品分類、次の2桁は仕様区分、次の2桁は順序番号で最後の1桁が枝番」といった体系が与えられた。ユーザはその体系に従って発番されたコード値を、記憶したりコード表を印刷するなどして活用していた。

 時は移り、品目点数が増えてくると様子が変わった。ユーザはコード値を記憶しきれなくなったし、コード表から見つけ出すことも困難になった。膨大な対象の中から絞り込み条件を指定してオンラインで選びだすようなやり方でしか、対象を特定できなくなった。同時にコードの桁数が増えて体系が複雑化したため、発番管理も面倒になった。たとえば、7桁目が"1"の場合には8~9桁目は「容量」を表すが、7桁目が"2"の場合に4桁目が"A"であれば8~12桁目が「材質」を表し4桁目が"B"であれば8~11桁目が「内径」表す、といったハチャメチャなコード体系を維持する羽目になった。

 ではなぜ、それでも人々はコード体系にこだわったのか。理由はふたつある。まず、どんなに管理実体が増えても「常用品」は限られていたからだ。売上全体の80%を製品全体の20%が占める、といった「80:20の法則」はここでも適用できる。どんなに実体数が増えても、一部の常用品についてはコードを覚えてダイレクト指定できたほうが便利であることに変わりはなかったのである。ふたつ目の理由は、コード値から管理対象の仕様や特性を知りたかったからだ。コードを見るだけで対象のだいたいの様子がわかるのなら、それはそれで喜ばしいことだった。

 では、この要件に対するシステム仕様はどうあるべきか。品目コードを例として説明しよう。まず、「品目コード」ではなく「品目ID」を品目マスターの一次識別子(PK)とする。品目IDは発番順序だけを表すユニーク項目だ。そうしたうえで「品種区分」、「容量」、「材質」、「内径」といった品目の仕様情報を、属性項目としてコード体系から独立させる。品種区分によって属性の組み合わせが変わるようであれば、適宜「サブタイプ」を組み込めばよい(図1)。

▼図1.品目IDをPK、品目コードをSKとする
Zu1

 同時に、品目コードを二次識別子(SK)として組み込む。一部の常用品についてのみ、「源氏名(げんじな)」を与えてダイレクト指定できるようにするためだ。具体的には、品目IDと同値で品目コードを設定しておいて、必要に応じてユーザに変更してもらうようにすればよい。PKと違ってSKの値は後で変更可能だからだ。

 結果的にシステムは、品目コードの各桁を特別扱いするようなロジックを持たずに済むようになる。なにしろ品目の点数が膨大なうえに仕様次元も複雑なので、コード値から仕様を知るやり方を(ある程度は)あきらめる必要がある。基本的にはシステムに問い合わせることで正確な仕様がわかればよい、という管理方針を受け入れるということでもある。

 一意性が保証され、覚えやすく、かつ変更可能なコードを一部の実体だけに付与すればよい――ということであれば、複雑なコード体系にこだわる理由はない。せいぜい品種区分と略称と順序番号の組み合わせ程度でかまわない。極端に言えば、もっとも売れ筋の品目コードを"AKEMI(あけみ)"にしてもいい。いっぽう常用品以外については従来通り、膨大な一覧の中から属性値の組み合わせで絞り込んで選択してもらえばよい。どんな体系にしたところで、それらの品目コードなど誰も覚えていないのだから。

 ここで注意してほしいのは、常用品だろうがそうでなかろうが、DB内のテーブル関連(リレーションシップ)は、値が変化し得ないPK(ここでは品目ID)にもとづいて維持される点だ。ユーザが"AKEMI"の品目コード(SK)で品目を指定したとしても、アプリはその品目ID(PK)である"246417"の値を内部的に確保し、これにもとづいて結合等のDB操作を行う。つまり品目コード(SK)は対象データにアクセスするためのダシでしかない。その過程でユーザが品目ID(PK)の値を意識することもない。

 いったんこのような仕組みを用意してしまえば、コード体系は開発者が関わるべき問題ではなくなる。どんなに珍妙な体系でも、システム仕様には何の影響も与えないからだ。そういった体制を下支えするDB構造を創案することが、システム開発者の仕事である。あいかわらず複雑なコード体系の維持につきあっているとしたら、何かがおかしいと考えたほうがいい。

|

« 「危ないデータモデル」の定量的判定基準 | トップページ | 部門と従業員のデータモデリング »

コメント

コメントを書く



(ウェブ上には掲載しません)




« 「危ないデータモデル」の定量的判定基準 | トップページ | 部門と従業員のデータモデリング »