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

» 2006年06月08日 00時00分公開

[吉田知史，アクセンチュア・テクノロジー・ソリューションズ]

データベースをコードに依存しないように設計する

　さて、コードはできました。次はデータベースを設計します。コードがずっと同じ体系であれば何も考えずに設計できるのですが、残念ながらこの世は無常です。コードがパンクしなくても、業務・システム統合のためにコードを統一するという前向きな事情によりコード体系を変えることもあります。

　そこで本稿では、「データベースをコードに依存しないように設計するためにはどうすればよいか」に重点を置いて、注意すべきポイントを解説します。また、解説の際にケーススタディとして、図1のように書店の販売システムとクライアント企業の購買システムが連携する場面を利用します。

図1　販売システムと購買システムが連携するケース

（1）業務で利用するコードを主キーとして利用することは避ける

　業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。図1のケーススタディでは、書籍テーブルがありますが、これの主キーとしてISBNコードを利用すべきではないということになります。

書籍
書籍ID（PK）	⇒ISBNを主キーとして利用せず、書籍IDを別途用意する
ISBN
……
表1　書籍テーブルのスキーマ

　そもそも主キーとして求められる特性は以下に挙げるものです。

値の変わらないもの
できるだけけた数が短いもの
複合キーとなる場合、連結が多くならないもの
必ず存在するもの

　コード体系は変化し得るという前提に立つと、コードは「値の変わらないもの」という特性を損ないます。そして、有意コードであればけた数が長くなりがちなので、「できるだけけた数が短いもの」という特性も損ないます。従って業務で利用するコードはテーブルの主キーとしてはあまり適切ではありません。

　特に、顧客・受注といったエンティティはほかの多くのテーブルと結合されるため、顧客ID・受注伝票番号といった項目が業務上利用されている場合は、これを顧客・受注といったエンティティでは主キーとしては利用せず、主キーとなる項目をデータベース内に閉じたものとして別途用意すべきです。ただし、参照される機会が少ないような場合は、わざわざ主キー用の項目をシステム内で用意しないという判断も時に必要です（分類用のテーブルを切り出す場合など）。

（2）プログラムで条件判断や検索に利用し得る有意コードは分解する

　有意コードでは、複数の意味や何らかの分類をコード内に持ちます。一方、プログラム側では有意コードを条件分岐や検索に利用する場合、複数の意味が1つの項目にまとまっていると不便です。そのため、プログラムに利用される有意コードは意味ごとに分解すると処理が容易になります。

受注
受注ID（PK）
受注伝票番号	⇒B始まりの場合銀行は振込、C始まりがクレジットカード払いとする
支払い区分	⇒支払い方法を切り出す（01＝銀行振込、02＝クレジットカード払い）
……
表2　受注の支払い方法をプログラムで利用する場合

書籍
書籍ID（PK）	⇒ISBNを主キーには利用せず、書籍IDを別途用意する
ISBN	⇒日本図書コード管理センターが管理する書籍識別用のコード
分類コード	⇒日本図書コード管理センターが管理する書籍分類用のコード　販売対象コード・発行形態コード・内容コードからなる
販売対象コード
発行形態コード
内容コード
書名
……
表3　書籍の分類をプログラムで利用する場合

（3）システム連携で使用されるコードの取り扱いには注意する

　業界標準コードというものがあることからも想像できますが、業務で使用されるコードは企業間の業務・システム連携でも用いられることがあります。ケーススタディでは、クライアント企業側の発注データの中にある伝票番号を、納品書の印字や請求データに入れて、クライアント側の発注記録と突き合わせることに利用します（図2）。

図2　企業間の業務・システム連携で利用されるコード

　そのため、クライアント企業で採番された発注管理番号を書店の販売システムのデータベースに保持する必要があります。そして、クライアント側のコード体系がどのようなものでも対応できるよう、数十〜100程度のけた数を用意します。当初他社との連携がないシステムでも、将来その可能性がある場合はあらかじめ他社のコードを入れる項目を用意しておくべきです。

受注		請求
受注ID（PK）		請求ID（PK）
受注伝票番号		請求伝票番号
発注伝票番号		発注伝票番号
支払い区分		支払い区分
……		……
表4　企業間の業務・システム連携を想定したテーブル

Point　

データベース設計の際は、コードに依存しないよう以下の点に注意する。

業務で利用するコードを主キーとして利用することは避ける
プログラムで条件判断に利用し得る有意コードは分解する
システム連携がある場合、外部システムから受け取るコードの格納場所を確保する

まとめ

　以上、コード設計の手法を解説しましたが、私はコード設計という経験を通してデータベースエンジニアは2つの能力を高めることができると考えています。

　1つ目は「ビジネスを理解する力」です。コードはビジネスモデルを色濃く反映します。どんなコードが必要か、それぞれのコードにはどのような分類を埋め込むべきかを判断するためは、ビジネスを理解することが必要です。

　2つ目は「将来のビジネスを予測する力」です。コード設計というものは、現在必要なシステムを作るだけでよいのであれば、いいかげんにやってもさほど困ることはありません。しかし、多くの場合、将来のビジネスの拡大、変化の中でも使い続けられるシステム、つまり「寿命が長い」システムであることが求められます。そういったシステムを作るためには、コード設計を適切に行う必要があります。

　最後に、読者の皆さんが今後コード設計に取り組む際に、この記事が何らかの役に立ち、そして、その経験を通じてデータベースエンジニアとしてさらに成長していただければ幸いです。さて、次回は「データへの最短ルートを確保せよ！」というタイトルで、大量のデータの中から目的のデータを効率よく検索するためのテクニックを紹介します。お楽しみに。

筆者プロフィール

アクセンチュア・テクノロジー・ソリューションズ

アクセンチュアから生まれた、企業改革のためのシステム開発を手掛けるエンジニア集団。安間裕が代表取締役社長を務める。下平浩由はネットワーク、データベースなどのインフラ／ミドルウェアに精通したシニア・システム・アナリスト。ネットワークエンジニア、Javaシステム開発者を経て、現在はパッケージシステムの分野でSAPの導入に携わっている。

「次回」へ

「データベースエンジニアへの道」バックナンバー