2.3 概念設計の手順(3/3)

できるエンジニアになるためのちょい上DB術/第2章 概念設計

2.3 概念設計の手順(3/3)

2.3.4 属性と一意識別子の洗い出し

属性とは

属性とは、エンティティがもつエンティティオカレンスに関する付加情報です。
エンティティオカレンスがもつ性質や特性を表現するもので、ユーザへのヒアリングや、現行業務で管理している帳票や画面から抽出します。
業務をよく知っているユーザに確認しながら、漏れなく抽出する必要があります。
管理すべき属性が漏れていると、実際の業務が遂行できなくなります。
また、属性の中には、業務の中だけでは類推できない、アプリケーションを実行するために追加で必要になるものもあります。
これについては、論理設計のフェーズでアプリケーションとつき合わせをする中で抽出します。

オプショナリティ

導出項目、重複項目を属性として定義するか

導出項目は元データがあって、そこから計算などによって導き出される項目のことです。
重複項目とは、他のデータからコピーして作られる項目であり、更新時の処理を考えると、1データ1箇所の原則からいって、両方とも存在していないほうが望ましいといえます。
原則的には、重複項目も導出項目も冗長なので、基本的には除きます。

DB設計の理論上は、正規化の観点から導出項目も重複項目も除くべきです。
しかし、分かりやすさと情報が欠落しない(導出項目だからという理由で削除してしまうと、本来管理されていたものが欠落してしまう)ことを重視するならば、業務で導出項目を使っている場合、ER図上に存在しても構わないと考えることができます。

たとえば、発注時の購入金額合計や買掛残高などは導出項目ですが、管理されるべき項目として挙げられます。
また、エンティティのライフサイクルの違いから作られる導出項目については、明示的に存在させるべきものもあります。

たとえば、商品販売単価などは、時の経過とともに変化する可能性があります。
しかし、受注エンティティで管理すべき商品販売単価は、受注したときに契約した商品販売単価です。
このような属性は、商品マスタを参照するのではなく、重複項目のように見えますが、受注明細エンティティでその時の商品販売単価として管理すべき属性です。

概念設計などの分析の初期段階では、業務上必要な情報は「漏れなく」洗い出すことが重要だといえます。
一度取り除いてしまうと、後から追加することは難しいため、導出項目や重複項目は、そうであることを明記して残しておくべきだということができるでしょう。

たとえば、以下のようなケースは、導出項目を残しておいたほうが良いと考えられます。

  • 画面、帳票上にでてくるデータ項目で、重要な意味をもつ
  • その値を出すための計算が複雑で(エンティティをまたがった集計処理など)、導出のためのCPU負荷が大きい

概念設計では、導出項目であることを明記しておいて、データベース上に残すかどうかは、性能などの観点を考慮して論理設計で決定するようにします。

属性情報として管理すべき項日

属性として管理すべき項目を決めたら、次のような情報を収集します。
説明 属性を説明
オプショナリティ 属性値を、オカレンス生成時から必ずもつ必要があるか
必須または任意
タイプ データ型(文字、数値、日付、時刻、ドメインなど)と桁数
許容値 値の範囲や具体的な値リスト
ドメイン ユーザが定義した、属性のとりうる値に関するルール

表2-3 収集する情報

表2-4に例を示します。
エンティティ 属性名 オプショナリティ タイプ 許容値 説明
顧客 顧客番号 必須 整数(5) 0001-99999 顧客を一意に特定するための番号
  顧客名 必須 氏名 0001-99999 顧客の姓名または法人名
  顧客名
フリガナ
必須 カナ 0001-99999 顧客名の読みガナ
  電話番号 必須 電話番号 0001-99999 顧客の自宅電話番号または法人の代表番号
  住所 任意 住所 0001-99999 顧客の自宅住所または会社住所

表2-4 管理すべき項目の例

属性のドメインを考える

ドメインは以下のように定義づけることができます。

属性を管理する際、データベースの中で整合性のとれた値を管理するために、ドメインをあらかじめ定義することができます。ドメインを定義することによって、属性に関しては、共通に管理できるデータ型、桁数などをそのつど定義する必要がなくなります。 また、ドメインを定義することによって、開発時の標準化を行うことになり、生産性が向上します。

また、データ型の定義などにおいて整合性がとれなくなることもなく、データの一貫性が保持できるというメリットがあげられます。

ドメインの例を表2-5に示します。

ドメイン 意味・形式 タイプ
年月日(和) 平成yymmdd 文字(10)
年月日(西) yymmdd 数値(8)
氏名 姓+空白+名 文字(30)
住所 都道府県名+市区町村名+番地 文字(30)
電話番号 xxxxx-xxxx-xxxx 文字(15)
金額 円単位の金額 zzz,zzz,zzz,zz9 数値(12)
重量 重さ 単位はkg 999999 数値(6)
識別番号 000001から999999まで 数値(6)

表2-5 ドメインの例

< 前へ | 2.3 概念設計の手順(3/3) | 次へ >

解説トレーナー

Oracle / 上流工程 担当 中村 才千代

データベース設計、システム構築の上流~下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。

■認定・受賞

2000年 Oracle University「Best Instructor of the Year」受賞
2002年 Oracle University「Best Instructor of the Year」受賞

Page Top