属性について、もう少し実務に即して考慮してみましょう。
次のクイズに答えてください。

データを削除するとき、論理削除を実装しますか？
また、物理削除を実行しますか？

以下、解答を示します。

マスタ表など、勝手に変更されては困るような表には、次のような列を定義しておき、アプリケーションで最終更新者の情報を表中に記述できるようにします。

• 作成日
• 更新日時
• 更新者列

特に決まりはありませんが、一般的なER表記方法に従うと、以下の表記方法が使われています。

• 属性に識別子であることを明確にするための印「★」をつける
• エンティティの外側に識別子のみを記述する
• エンティティの四角の内側に横線を引き、その上部に位置するのが一意識別子または一意識別子の組み合わせとする

表記例を図2-24に示します。

概念設計では、「現在の業務の中で使用されている」そして「候補になり得る」属性を一意識別子とします。
人工的にキーを作成するのは論理設計の段階で行います。
なぜかというと、この段階で人工キーを作成してしまうと、何をもってオカレンスを一意に特定するのかの定義があいまいになってしまうからです。
厳密に属性の組み合わせで一意識別子を定義することによって、エンティティオカレンスの意味が明確になります。
また、属性の組み合わせで一意にすることによって、オカレンスの一意性を確実にするという意味もあります。
人工的なキーを作成してしまうと、人工キーの値が一意でさえあれば、属性の値の組み合わせが同じであってもオカレンスを作成することができてしまいます。

概念設計では、このよう人工キーは作成せず、パフォーマンスの観点などから必要であれば、論理設計で人工キーを検討し、その際には先に一意識別子であった属性の組み合わせは一意キーとして制約を追加するなどして対応すべきと考えられます。

一意識別子は、汎用機の時代には「コード」として、値そのものに意味をもたせるのが一般的でした。 その場合、アプリケーション側でコードを分解してその意味を照合するなどの必要がありました。

次のクイズは、そのような汎用機の時代に使われていたコードに関する質問です。

表2-6 コード体系

クイズ5の解答例

エンティティおよび一意識別子作成時の方針を説明します。

• 商品エンティティの一意識別子「商品コード」は、そのコード自体に意味をもたせない
• どのような商品分野や対象者層が売れ筋かといった分析を行うためには、
  分析の軸となるエンティティをそれぞれ作成し、管理するこれによって、
  商品力タロクコードというコードで管理する必要はなくなる
• 分析の軸となるエンティティを作成することによって、
  エンティティオカレンスが増加しても（たとえば、扱う商品分野が増加するなど）モデルを変更する必要はない
  この形の場合、できれば、分析軸となるエンティティは最初に抽出しておくことが望ましい

< 前へ　｜　2.3 概念設計の手順（3/3）　｜ 次へ >