2.3 概念設計の手順（3/3）｜エディラボ

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

誰がいつデータを更新したか、どうやって管理しますか？

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

以下、解答を示します。

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

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

会計に関係するデータを削除する場合は、削除の履歴が後から確認できるよう、赤黒処理と呼ばれる方法をとり、物理的に削除することはほとんどありません。
会計以外のアプリケーションでも、単純な削除を避ける場合は、論理削除という方法をとります。
表に削除フラグを設け、削除対象の行は削除フラグをONにします。
更新の場合も同様で、単純に更新するのではなく、更新の履歴を残すようにします。

ただし、これらの操作をした場合、検索の際、現在有効な行を検索するためには、必ず「削除フラグ＝0」という条件式をつけることが必要になってしまいます。
また、削除データは物理的に削除されないため、放っておくとデータ量は増加する一方なので、削除のための作業を検討する必要があります。

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

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

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

一意識別子の候補となる属性または属性の組み合わせを候補キーと呼びます。

エンティティオカレンスを一意に特定できる属性であれば、識別子になり得るので、候補キーは複数存在することもあります。
概念設計では、一意識別子になり得る属性を、候補キーという形で洗い出しておき、最終的には論理設計で一意識別子を決めます。

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

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

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

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

現在の業務で使用されているコード体系を見直してみました。
新しいシステムではコードに意味をもたせず、必要に応じてエンティティという形で管理しようと考えています。
考えられるエンティティ、リレーションシップ、一意識別子を表しなさい。

表2-6 コード体系

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

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