業務モデルとシステムモデル

業務を表現したモデル（業務モデルと呼ぶ）とコンピュータシステムの構造あるいはソフトウェア構造を表現したモデル（システムモデルと呼ぶ）は、表現形式が似ていても内容は本質的に異なります。

たとえば、データの構造を表すデータモデルを取り上げてみます。

業務モデルとしてのデータモデルとシステムモデルとしてのデータモデルは、両方ともデータの塊を「箱」で表現し、それらの関係を「線」で表現します。一見同じように見えますが、表現する内容に違いが出ます。

1. 「箱」が表現するもの
   業務モデルでは、この「箱」をエンティティと言います。業務の世界で扱われる「物」「事」をデータ項目名の列挙で表現したものです。一方で、システムモデルではこの「箱」をテーブル（またはファイル）と言います。データベースマネジメントシステムが記憶する対象（データの塊）を表現したものです。
2. 「線」が表現するもの
   業務モデルでは、この「線」は業務の世界で扱われる物事の「関係」を表現したものです。もちろん人が頭の中で具体的な線をイメージしているわけではありません。人が具体的に認識し、他の人に伝えることができるのは、データ項目の値を使った関係づけです。
   たとえば、受注エンティティに顧客コード=1000（データ総研）が含まれることによって、「この受注はデータ総研からのものだな」と理解します。そして、この顧客コードの値=1000が、顧客エンティティの識別子である顧客コード=1000（データ総研）と同じことによって、顧客エンティティが持つデータ項目（住所、電話番号、担当者名など）を参照することができます。つまり、受注エンティティと顧客エンティティの間に関係があることを認識します。
   一方で、システムモデルはテーブルとテーブルの関係を表現します。業務モデルとシステムモデルの違いを端的に例示すれば、受注したときに在庫数を引き当てる場合、業務モデルでは受注エンティティと在庫エンティティの間に線を引きます。一方、実装された受注テーブルと在庫テーブルはアクセスパスのルートに乗っているわけでもなく、フォーリンキーを使った参照制約も必要ありませんから、線を引きません。

情報システムは一種の製造物ですが、自動車やビルのような形のある、さわって確認できる製造物ではありません。受注とは何か、受注金額とは何か、顧客とは何か、受注先と顧客は何が違うのか、といった言葉の定義を積み上げて造るものです。

最近、業務モデルを説明しているのか、システムモデルを説明しているのか言葉を使い分けない人が増えているように感じます。

• エンティティとテーブル
• アトリビュートとカラム（またはフィールド）
• 識別子とプライマリキー