ERPの落とし穴part5～コード設計の難しさ

業務システム開発で、マスタテーブルを新規に作る場合、コード設計を事前に深く考慮する必要がある。
考えたこと、経験したことをラフなメモ書き。

【元ネタ】
Hot Heart, Cool Mind.: コード設計の話

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (1/3) - ＠IT

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (2/3) - ＠IT

データベースエンジニアへの道（4）：システムの寿命はコードで決まる！ (3/3) - ＠IT

うぃっとWorks: 有意コードと無意コード

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (1/3) - ＠IT

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (2/3) - ＠IT

ゼロからのデータモデリング入門（10）：ビジネスの変化に強いデータモデルを作る (3/3) - ＠IT

【1】2013年の日本の政治でマイナンバー制度が決まった。
この法律は、日本人全てに固有の一意の番号を割り当てて、今後増大するであろう年金の管理や税金の徴収に使いたい目的があるのだろう。
その場合、マイナンバーというコード(主キー)はどのように作ればいいのか？
コード設計がまずいと、システムの運用が長引くにつれて、どんどん複雑化し、システムの運用の支障になる。

SEの観点によるマイナンバー制度の解説については、@hatsanhatさんの下記の記事がとても秀逸。

共通番号制度（旧：マイナンバー制）施行に合わせて、IT企業は何をすべきか｜HATのブログ

コード設計が重要な理由は、ERP導入時に、現状の業務システムにバラバラに散在しているマスタを一元化するために使われるからだ。
普通の大企業では、サイロのような業務システムが過去に作られていて運用が続いているために、コード体系がマチマチで業務に支障が出ている場合は少なくない。
例えば、小売業の商品マスタや顧客マスタや取引先マスタ、製造業における製品コードや製番管理などがあげられるだろう。
ビジネスの変化にコード設計がついていけない状況が多くなっているのだ。

だから、ERPを導入する時に、過去システムのデータを移行してコードを振り直したり、過去システムは捨て去って、新たにコードを振り直す。
会計、CRM、SCMなどのデータが業務の流れで一元化して管理しやすくするために、マスタのコードを一元化するのだ。

【2】コードの種類には、幾つかの概念がある。

有意コードは、特定のけたに意味を持つキー。
業務で使われるキーが相当する。
よくある例は、国民年金で有名な社会保障番号、日本人全てに振られるマイナンバーなどがあるだろう。
他にも、病院の診察券に振られた患者番号、スーパーのポイントカードにふられたカード番号、クレジットカード番号、銀行の口座番号も相当するだろう。
あるいは、製品コードを仕様コードと設計コードとプロダクトコードでハイフンでつなげた番号などがあるだろう。
これらはユーザキーであり、自然キーでもある。

無意コードは、特定の桁に意味を持たせないキー。
OracleなどのDBが振るシーケンスが相当する。
人工キーである。

標準コードは、業界標準のコード。
有意コードが多い。
商品のJANコード、書籍のISBN番号があるだろう。
これらの番号は、公的機関ないし公的と認められる団体が一意に番号を振る。

独自コードは、企業などで独自で振るコード。
例えば、会社の社員番号。
普通は業務システム内部で採番しているだろう。

【3】コード設計には、DOAで既によく知られた幾つかのノウハウがある。

【3－1】業務で利用するキー（有意コード）は主キーにしない

コード体系とデータベース設計を独立させるという観点で重要。
有意コードを主キーにすると、有意コードは変更される可能性があるため、主キーは値が変わらないキーという前提が崩れる。
主キーが変わるということは、その主キーを参照するテーブルにも影響があり、データの整合性やプログラムの複雑化を考えると、大変な作業になる。
普通は、主キーは無意コード化した方がDB設計上もプログラミングも都合が良い。

@sugimoto_keiさんの下記の記事がとても分かりやすい。

Hot Heart, Cool Mind.: コード設計の話

主キーはシーケンスのような無意コードとし、ISBN番号やJANコードのような有意コードは2次識別子(代替キー)として設計した方が良いと思う。

昨今のWebシステムでは、Railsのように主キーは全てサロゲートキー(代理キー)にしてしまい、RESTfulにする設計が主流になっているように思う。

【3－2】プログラムで利用する有意コードは分解する

有意コードはプログラム内部で分割して、条件分岐や検索処理のために使われる時が多い。
例えば、最初の8桁のyyyyMMddは切り取って、その後の桁の値を元に検索したりする。

有意コードを分解して利用する共通ロジックが多いならば、有意コードを分解してテーブル内で保持する方がプログラムも書きやすいし、データの重複も減る場合がある。
検索で使うならば、有意コードを分解しておく方が、テーブルにインデックスを貼ることで性能を上げることもできる。

【3－3】外部システム連携で使うキーは保持する

例えば、EOS発注のように、仕入先に発注した商品の伝票データを、仕入先企業の外部システムから自社の業務システムへ取り込む場合、仕入伝票番号を受け取る時がある。
その場合、外部システムから連携される仕入伝票番号というコードは、自社システムで保持しておく。
その理由は、例えば、紙でもらった伝票番号と自社システムに取り込んだ伝票番号を照合するなどのマッチング処理で使いたいからだ。
つまり、外部システムから連携された伝票番号とそのデータ内容がそもそも正しいのか、自社システム内部で照合処理に使うわけだ。

その場合、伝票番号は、外部キーないし2次識別子としてテーブル内で保持する場合が多いだろう。
つまり、T字形ERで解説するならば、eventとeventを1対1ないし1対多でつなぐ場合、先行トランザクションの主キーを時系列の遅い後続トランザクションに外部キーとして保持するパターンになる。

候補キーと2次識別子に関する概念: プログラマの思索

【3－4】コード化する件数を把握する

コード設計するからには、コードの件数や桁数をあらかじめ事前に計画しておかないといけない。
何故なら、後から桁数を拡張したり、データ型を変更するのはかなり難しいからだ。

桁数が小さすぎると、コードを使い切ったら、過去のコードを使いまわす事になり、One Fact One Placeという原則が崩れてしまう。
コードの件数が多すぎる場合、桁数を増やしすぎると、無駄にディスクスペースを消費してしまう。
この辺りの物理設計はデータベースの知識がモノを言う。

【3－5】DA（データ管理者）を決める

コード体系を決める場合、業務をよく知っている人がDAの役割を担って、コード体系が破綻しないように見守る。
各部門で保持するコード体系はどのように振るか、業界標準の標準コードを採用スべきか、過去のコードを再利用すべきか、有意コードや無意コードをどの範囲まで適用するか、色々考えるべき点がある。

【3－6】ユーザの使い勝手を考慮する

例えば、JANコードにはチェックディジットのように、バイトの人が商品番号を入力する時に誤って入力したらエラーになるような仕組みがあったりする。
商品のバーコードやクレジットカード番号にもチェックディジットの仕様が組み込まれている。
あるいは、コードの意味がユーザに分かるように、シーケンスのような数字の羅列ではなく、英数字にしたり、日付や顧客番号を組み合わせた有意コードにしたりする。

【4】コード設計は正直アジャイルにはならない。
一度作ったテーブルの主キーの設計を修正するのは、あまりにもシステムの影響が大きく、業務の支障にもなる。
もちろん、ユーザの使い勝手も変わってしまう。
だから、どうしても事前の計画の準備が重要視されるために、DOAはウォーターフォール型開発とセットになって運用されやすい。

でも、DOAの重要性は業務システム開発では変わらない。
マイナンバー制度のように、コード設計が最初から間違っていると、データ構造の複雑さに耐え切れずにプログラムは複雑になるし、業務システムを長く運用してデータが増えていくにつれて、データの整合性を維持するだけでも大変になる。
一度作ったコード体系を破棄することは余程のことがない限りありえない。
だから、コード変換処理という無駄なプログラムが増えて、業務システムはどんどん複雑化していく。

アーキテクチャ設計の鍵は、アーキテクチャ設計の未熟さをプロセスでカバーするアジャイル開発か、正面から設計を考えるDOAの2つにあるような気がしている。