一部の組み込み系システムを除けば，業務系システムはすべて何らかのデータベースを使っており，データベースを中核にしてシステムができあがっています。データベースを押さえることは，システムの中核を押さえることにほかなりません。したがって，データベースをどのような手順で，何に基づいて設計するのかを知っておくことは，システム構築に携わるすべての人にとって不可欠です。

　Part4は，データベース設計の上流工程である概念設計と論理設計にフォーカスして説明します。こうした作業はデータ・モデリングと呼ばれます。業務要件定義を解きほぐして，システムの中核となるデータベースの論理構造を決定することが目的です。

　データ・モデリングの重要性については，私たちが取り扱うビジネス・システム（業務システム）が，台帳中心のシステムであるということを考えれば明らかです。江戸時代などの時代劇を見ていると問屋の番頭が蔵の中で帳簿をつけている光景を目にすることがありますが，それは在庫台帳であったり，顧客台帳だったりします。現代になってこれらの作業の多くはコンピュータで機械化されました。しかし，台帳にデータを蓄積し，要求に応じてそこからデータを取り出し，加工し，必要とする人に配布するという本質のところは変わっていません。データ・モデリングはいわば，どのような台帳を作るのか，というのを決める作業なのです。

モデリングは3段階で行う

　Part4では，データ・モデリングは初めて，という方を対象に，簡単な事例に基づいてデータ・モデリングの手法について説明していきます。前提とするのは，テーブル，正規化といったリレーショナル・データベースの基礎知識だけです。

　ここではモデリングの記法としてER（エンティティ・リレーションシップ）図を使います。ここでちょっと注意していただきたいのは，ER図はテーブル間の関連を描くためだけのものではないということです。販売管理や物流といったターゲット業務の姿を，わかりやすく表したものであり，例えば，業務を改善するための分析などにも利用できます。とは言え，もちろん，データ・モデルですべてを表現できるわけではありません。

　最初に，モデリングの手順と，ER図における記法および用語について説明しておきましょう。一般にモデリングは，概念モデル作成（概念設計），論理モデル作成（論理設計），物理モデル作成（物理設計），の順に進めます。三つのモデルについて，ここでは次のように定義します。

　この記事では，冒頭で述べたように，概念モデル作成と論理モデル作成について取り上げます。物理モデル設計では，パフォーマンス上の問題などで論理モデルを変更する場合もありますが，ほとんどのケースで論理モデルをそのまま物理モデルとしても問題ないからです。

モデリング記法の基礎を押さえておこう

　ER図の基本的な考え方は，モデリングの対象を，エンティティ（Entity，実体）と，エンティティ間のリレーションシップ（Relationship，関連）で表すということです。

　まずエンティティについて説明しましょう。モデリングの記法には色々ありますが，今回は市販のモデリング・ツールなどに広く採用され，普及しているIDEF1X（アイデフワンエックス）を用います。

　図1上を見てください。「社員」というエンティティは，属性（attribute，性質）として，社員番号，社員名，入社年月日を持ちます。これらの属性のうち，社員を特定できる属性を主キー（あるいは識別子）と呼びます。普通の企業では，社員番号を指定すれば対応する社員がただ一人に決まりますね（社員名は同姓同名がいるかもしれません）。したがって，社員番号が主キーです。主キー以外の属性（ここでは社員名，入社年月日）を，非キー属性と呼びます。

図1●ER図における基本的な記法（IDEF1Xの場合）

　ER図では，エンティティを四角形で表します。四角形を二つに区切って，主キーを四角の上段に，非キー属性を下段に書きます。

　エンティティとしてもう一つ，ある社員の「家族」を取り上げてみましょう。家族の構成メンバーには，その社員の社員番号のほかに，家族内で番号をふった家族番号，家族氏名，性別，生年月日，などの属性を持たせます。これらのうち，社員番号と家族番号がペアで主キーになり，残りの属性が非キー属性になります（図1下）。

　あるエンティティの属性のうち，ほかのエンティティの主キーになっているものを，外部キー（Foreign Key）と呼び，属性の後ろに（FK）を付けて表します。この例では，家族エンティティにおける社員番号が外部キーです。

　次は，リレーションシップについて見ていきましょう。一般に社員には家族が複数います（1対nの関係）。 このことを，社員エンティティの四角形と，家族エンティティの四角形の間を線で結ぶことによって表します。このときn側にあたる家族エンティティ側には黒丸をつけます。社員エンティティの主キーである社員番号が，家族エンティティの外部キーになっていることから，社員エンティティを親エンティティ，家族エンティティを子エンティティと呼びます。

　リレーションシップの対応は1対nとは限りません。1対0，1対1などが考えられます。IDEF1Xのリレーションシップではこうした詳細な対応関係をカーディナリティによって規定します。

　図1において，黒丸の横に指定がない場合，1対「0以上」となります。これは，家族が一人もいない社員および複数人の家族を持つ社員が存在することを表します。

　1対「1以上」，すなわち社員には必ず家族が1人以上いることを表すには，黒丸の横に「P」を書きます。「Z」は，1対「0または1」の意味になり，社員は，家族がいないかまたは家族が1人であることを表します。1対ｎの「n」の値が決まっているときには，その数字を黒丸の横に記入します。すなわち家族は必ず3人と決まっていれば，黒丸の横に「3」を表記します。カーディナリティを最初から厳密に決めるのは難しいのですが，業務を正確に映し出すという点ではできるだけ，定義していくことが望ましいでしょう。

　最後に，リレーションシップとエンティティの種類について説明しておきます。家族エンティティの四角形の角が丸くなっていることにお気づきになったでしょうか。こう表記したエンティティは従属エンティティ（あるいは依存エンティティ）と呼ばれます。従属エンティティは，親エンティティ無しでは存在できないことを表しています。

　このER図で扱う家族には，必ず対応する社員がいます。すなわち，社員なしで家族が存在することはありません（このER図では社員の家族だけを表記していますから当然です）。したがって，家族エンティティは，従属エンティティになります。従属エンティティに対するリレーションシップは実線で表し，これを依存リレーションシップ（依存関係）と呼びます。

　これに対し，ほかのエンティティに依存しないエンティティを独立エンティティと呼びます。独立エンティティに対するリレーションシップは破線で表し，非依存リレーションシップ（非依存関係）と呼びます。依存関係と非依存関係を表現できるのは，IDEF1X記法の特徴の一つです。

図2●下の2通りのモデルの意味の違いを読み取れますか？

　図2の上は，会社と雇用関係を結んでいる“社員プログラマ”を表します。従属エンティティであるプログラマは，親のエンティティである会社無しでは存在できません。会社が倒産したら失業しちゃう，と考えていただければ良いでしょう。これに対して下のモデルでは，会社とプログラマが非依存関係で結ばれています。さらに，子エンティティも親エンティティと同様，独立エンティティとなっています。そうです，この場合は，会社と契約を結んで仕事をしている“フリー・プログラマ”を想定しています。ある契約先の会社が倒産してもほかの会社と契約していれば稼げるので，会社から独立しているというわけです。