データベースの設計をするタイミングは、基本設計書が出来上がってから、と信じ込んでいる若いSEは多いようです。
実際に、システムの全体スケジュールでは、納品は、基本設計書と同じタイミングですしね。
しかし、打ち合わせの途中でも、頭の中に「データモデリング」のイメージは出来上がっており、大体このような設計になるんだろうなぁ、とどのSEも思っているようです。
そして、驚くべきことに、SE同士で話してみれば、このデータベースの設計は、ほとんど一致します。
これには、システム設計の基本パターンというものが存在するからというのが一つの大きな理由でしょう。
詳細なER図を書くまでもなく、テーブル（エンティティ）の名前や、そのエンティティに、どんな項目が登録されるかは、80％以上決まっているのです。
ソフトウェア工学で言えば、エンティティには2つの種類があります。
「マスタ」と「ジャーナル」です。
マスタとは、Master（主人）からきています。
システムを支える情報であり、頻繁に値が変わらないものがマスタとなります。
「社員マスタ」、「得意先マスタ」、「商品マスタ」といったものです。
ジャーナルは、Journal（日記、日誌）の意味で、日々の情報を記録するものです。
「売上ファイル」、「仕入ファイル」、「出勤ファイル」といったものです。
ジャーナルは、昔はトランザクションとも呼ばれていました。
トランザクションは、Transaction（処理、取引)であり、ジャーナルと同じように、日々の取引ファイルを意味していました。（COBOLの索引ファイルでシステムを作っていた頃）
ところが、現在ではRDBを使ったシステムがほとんどで、RDBMSのトランザクション処理と混乱しないように、私はジャーナルと言っています。
実際には、さらに細かく分けて、マスタに3つ、ジャーナルに3つ、種類があると思っています。
一般的な「販売管理 売上・仕入から請求まで」を例に挙げてみます。
●マスタの分類
1)業務で使用するメインマスタ
・社員
・役職
・営業所
この考え方は、どのシステム開発会社でも同じだと思います。
2)常に、どんなシステムにも（システム的理由で）存在するマスタ
・管理
そのシステム全体で、使用する値が1つである場合に、このマスタにセットする。プログラムのConfigと違い、マスタの値を変更するだけで、プログラムに何の影響もなく、システム全体の振る舞いを変えることができる。
例：現在の期、期首、期末日、会社名、代表者名、住所……、消費税率とその期間
・名称
RDBといえども、コードと名前さえあればいい、といったものが多い場合に、1つのテーブル上で、共有して設定しておく。本来のRDB設計の観点からいえば邪道かもしれないが、便利なことが多く、弊害は、ほぼない。
・メニュー
・プログラム名
・メッセージ
3)業務独自でシステム的に必要なマスタ
・帳票定義
・権限
・運用管理
・カレンダー
●ジャーナルの分類
1)業務で使用する主ジャーナル
画面入力、外部連動で最初に作られるジャーナル
・売上
・売上明細
・仕入
・在庫移動
2)システムの難易度を下げるためのジャーナル
・帳票のための駆動表
・月次などの印刷のレスポンスを上げ、過去照会を容易にするための実績集計
3)システムのログを取るためのジャーナル（また、システム的なバグを見える化するために使用する）
・バッチの中間ワーク
・バッチログ
・操作ログ
マスタ、ジャーナル共に 1）は、どのシステム開発会社でも、どのSEでも、考える基本のものとなります。
つまりこれがデータべースの基本です。
しかし、優れたSEは、自分の設計に 2) や 3)も当たり前のように基本パターンを持っているものです。
内容や考え方は、システム会社によって、そしてSEによって、様々なものがあるはずです。
特にジャーナルの 2)システムの難易度を下げるためのジャーナルは、若いSEには思いつかないものが多いはずです。
他の会社でも、同じ会社内でも、他人が設計したシステムでこういうものを見つけたときに「なぜ、何のために、このようなジャーナルを設計しているのか」を考え、真似することをお勧めします。
優れたSEの作るシステムは、データベース設計にそのヒントが隠されているのです。
Vol.00139