できるエンジニアになるためのちょい上DB術/第2章 概念設計
3.3 論理設計の手順（1/4）
論理設計で行う作業を以下に示します。
- 処理機能と要件から性能を出すための最適化を行う。
- 論理ER図をRDBにマッピングできるようにする。
- 可能な限り正規化は崩さず、処理性能を高くする。
ブレークダウンし、手順を示します。
【STEP1】
業務に対するユーザ要件を検討する
【STEP2】
データ量を見積もる
【STEP3】
処理性能を出すための最適化の検討を行う
- インデックスを設計する
- 非正規化を検討する
【STEP4】
バッチ処理などアプリケーションを考慮し、必要な属性を再検討する（状態の遷移を表すフラグなど）
【STEP5】
一意識別子の検討を行う
【STEP6】
一貫性制約を見直す
【STEP7】
ビューとアクセス権限の設計を行う
【STEP8】
論理ER図からRDBへ変換するための準備をする
これらの処理を実行する前に、次のことを明らかにする必要があります。
- ユーザの処理要件（業務）
- ユーザが求める性能要件
- 予想される（または現状の）ピーク時のトランザクション数などのシステム環境
- データベースに対して発行されるSQL
3.3.1 ユーザ要件の確認（業務プロセスの確認）
業務（プロセス）に対するユーザ要件を収集し、論理設計で必要な処理を整理します。
まず、プロセス設計でどのように処理の単位を分割しているかを調べます。
表3-1は、販売管理サブシステムで定義されている各業務の説明と利用部門、処理形態をマトリクスにしたものです。
| 業務 | 機能 | 内容 | 備考 | 利用部門 | 処理形態 |
|---|---|---|---|---|---|
| 受注管理 | 受注の記録 | 顧客からの入力することによって受注を登録する | 営業所 | Online | |
| 商品引当管理 | 商品の引当が可能かどうかを検索し、可能であれば引当処理を行う | 仮引当 | 営業所 | Online | |
| 発注の登録 | 受注数に対して引当数が不足した商品について、発注の登録を行い、注文書を作成する | 発注業務への橋渡し | 営業所 | Online | |
| 受注の変更/ 確定 |
すべての受注明細を確定し、仮引当状態だった商品を引当する | 受注確定 | 営業所 | Online | |
| 受注の取消し | 出荷済みでなければ、注文キャンセル処理を行う | 注文取消し | 営業所 | Online |
表3-1 販売管理サブシステムの機能分割表
次に、表3-1の中の機能単位にブレークダウンし、どのようなエンティティにどのようなアクセス（SQLによるデータベースアクセス）をしているかを分析します。
表3-2は、機能ごとに対象となるエンティティに対して具体的にどのようなSQLが実行されるかを分析するために必要な情報の定義と具体例です。
表3-2は、機能ごとに対象となるエンティティに対して具体的にどのようなSQLが実行されるかを分析するために必要な情報の定義と具体例です。
| 要件 | 説明 |
|---|---|
| 機能処理内容 | 処理で使用されるエンティティと処理内容 |
| 操作パターン | Insert/Retrieve/Update/Deleteのいずれか |
| 条件指定の有無 | WHERE条件式の内容 |
| 要求性能 | 処理に要求される応答時間 |
| 処理形態 | オンライン/バッチ |
| 処理実行のタイミング | 処理が行われる時期、時間帯 |
| 実行頻度 | 単位時間内に実行される処理の数 |
| 処理データ量 | 1操作当りに処理されるデータ量/レコード件数 |
| 実行ユーザ | 業務を実行するユーザ |
表3-2 機能処理要件定義
表3-3は、表3-2の定義に基づいた具体例です。
| 要件 | 具体例 |
|---|---|
| 機能処理内容 | 商品引当管理：各倉庫の商品在庫を確認し、受注数量と比較し、十分あれば引き当てる |
| 操作パターン | 検索、更新 |
| 条件指定の有無 条件式＝「エンティティ名．属性名条件式値」 |
在庫．商品コード＝値 在庫．倉庫コード＝値 在庫．有効在庫数量＞値 |
| 使用されるエンティティ | 在庫、商品マスタ、倉庫マスタ、受注、受注明細 |
| 要求性能 | 3秒以内のレスポンス |
| 処理形態 | オンライン |
| 処理実行のタイミングと実行頻度 | 受注あり次第、随時。ピーク時は営業が帰社した後の20:00-22:00 |
| ピーク時トランザクション量 | ピーク時、5,000件/時 |
| 処理データ量 | 平均5レコード/処理 100バイト/レコード |
| 実行ユーザ | 営業部門、調達部門 |
表3-3 機能別処理要件表
このような機能処理ごとの情報を収集し、概念設計時に作成したCRUDマトリクスに「機能別処理要件」を追記して表3-4のようにまとめることができます。
表3-4「機能別処理要件付きCRUD」はエンティティ単位の処理要件しか分析していませんが、CRUDの基になっている表3-3「機能別処理要件表」では、エンティティの属性で設定する条件式まで分析しています。
処理要件から性能要件を満たすための方法を考察するには、属性のレベルで条件式まで分析されていないと十分な施策を打つことはできません。
表3-4「機能別処理要件付きCRUD」はエンティティ単位の処理要件しか分析していませんが、CRUDの基になっている表3-3「機能別処理要件表」では、エンティティの属性で設定する条件式まで分析しています。
処理要件から性能要件を満たすための方法を考察するには、属性のレベルで条件式まで分析されていないと十分な施策を打つことはできません。
解説トレーナー
Oracle / 上流工程 担当 中村 才千代
データベース設計、システム構築の上流～下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。
■認定・受賞
2000年 Oracle University「Best Instructor of the Year」受賞
2002年 Oracle University「Best Instructor of the Year」受賞
