【DB設計】概念設計の進め方

前回は概念設計についての基本を見てきました。今回は概念設計の進め方を解説していきます。具体的な例を使いながら進めていきたいと思います。

エンティティ記載のルール

まずは、記載のルールを確認しておきます。エンティティ及び属性については以下のように記載していきます。

image1

属性切り出しの例

マスタとトランザクションで属性のとらえ方に特徴がありますので、それぞれに見ていきます。

マスタにおける属性についての設定

ユーザビューを確認して、インスタンスの保持している値に着目して属性を抽出します。

image2

顧客の場合は、お客様番号、お客様名、お客様住所がその属性になります。商品の場合は、商品番号、商品名、単価がその属性になります。

マスタについては、台帳や一覧表のようなもので管理されているのが一般的です。(顧客台帳や商品一覧表)分析対象がユーザビューである受注伝票のようなものであった場合、ここから顧客、商品などのキーワードをみつけ、それらの台帳や一覧表で管理しているもので属性を抽出することで、的確な属性の抽出ができることになります。

マスタにおけるキーの抽出

属性の抽出が終わったら、次にキーを決定します。属性の中から洗い出すわけですが、着目すべきはインスタンスを識別できるか否かです。上記例だと、

顧客インスタンスを識別する属性は顧客番号商品インスタンスを識別する属性は商品番号

と言えます。一般的にｘｘ番号やｘｘIDなどとなっている属性は識別するために設定されているケースがほとんどであるため、キーとしやすいです。

トランザクションにおける属性の設定

トランザクションの場合も利用するのはユーザービューですが、ヘッダー部分、ディテール（明細）部分から抽出していきます。

image3

伝票一枚につき、一つだけ記載されているものをヘッダーから抽出します。ヘッダーからは受注番号、受注日、お客様番号、お客様名、お客様住所、合計が該当します。次に伝票一枚につき複数記載されているものをディテールから抽出します。ディテールからは、明細番号、商品番号、商品名、個数、単価、小計が該当します。

抽出が完了したら、ここから２段階で属性を除外します。

一つ目が他のエンティティからキー決定できる属性の除外です。お客様名やお客様住所は顧客エンティティの顧客番号から決定できます。また、商品名や単価は商品エンティティの商品番号から決定できます。このためこの時点で残っている属性は以下のとおりになります。

受注番号、受注日、お客様番号、合計、明細番号、商品番号、個数、小計

二つ目が、導出項目の除外です。導出項目とは他の属性を利用することによって、導き出せる属性を指します。ここでいうと、小計と合計がこれにあたります。小計は、個数×単価にて導出が可能な属性です。合計は小計の合算にて導出できます。これらは概念設計には記載しないのが一般的です。この段階で残っている属性は以下のとおりとなり、これが受注エンティティになります。

受注番号、受注日、お客様番号、明細番号、商品番号、個数

しかし、実務では導出属性を意図的に残している場合があります。わかりやすい例だと、導出するための計算に負荷がかかることにより、インスタンスとしての抜き出しよりも、計算に時間がかかり、ユーザーの性能問題になってしまうときがあることです。こういうことを防ぐために、導出属性を残しているケースはありますが、設計書などにその理由を残しておいたほうが無難です。メンテナンスの際にその属性についての意図がわかりやすくなります。

トランザクションにおけるキーの抽出

次にトランザクションのキーの抽出です。受注インスタンスを識別する属性は、とある顧客からとある商品の受注を識別するとした場合、{受注番号、明細番号}がキーとなります。この例のように複数の属性でキーになることもあります。

リレーションシップ

これまで、エンティティタイプ及びその属性について抽出を行いました。ここからはエンティティタイプをつなぐ、リレーションについて確認していきます。

改めて解説になりますが、リレーションとは複数のインスタンスの結びつきを表すものです。それぞれのインスタンスが属するエンティティタイプ間のつながりを持っているものとしてモデリングすることができます。

リレーションシップの抽出

エンティティタイプの間を線でつなぎ、多重度を記載します。以下の例を記載します。

image5

ここで解説すると、顧客エンティティタイプと受注エンティティタイプには関係があります。受注エンティティタイプにはだれが注文したかという、顧客エンティティタイプを使って管理しているような場合です。この場合、多重度は顧客1に対して受注は複数ある可能性があるため、多の関係となります。一方、見込み顧客のような場合は受注はありません。このため、オプショナリティは顧客が●（1）、受注が○(0)となります。

また、商品エンティティタイプと受注エンティティタイプには関係があります。商品エンティティタイプの商品番号を使って受注エンティティタイプの対象商品を管理している場合です。

これで概念設計が完了しました。アウトプットとなるER図は以下のようなものになります。

image6