2.3 概念設計の手順(3/3)|エディラボ

お問い合わせ・お申し込みはお気軽に「0120-876-544」

  • 研修コースをさがす
  • サービスをさがす
  • 新着情報
  • キャンペーン

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

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

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

クイズ3

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

クイズ4

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

以下、解答を示します。

クイズ3の解答

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

  • ●作成日
  • ●更新日時
  • ●更新者列
クイズ4の解答

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

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

一意識別子

  • ●エンティティオカレンスを一意に識別するための属性
  • ●属性値は必須で、値は同じ属性の中で一意であること
  • ●複数の属性(または属性とリレーションシップ)の組み合わせで構成することもできる

一意識別子になる属性は必ずしも1つに決まるわけではありません。
いくつかの候補のうち、最も処理に適した候補を論理設計の最終フェーズで一意識別子と決めればよいでしょう。

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

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

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

一意識別子の表記例

図2-24 一意識別子の表記例

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

候補キー

エンティティのどの属性YもXに関数従属であり(一意性)、Xが極小(または非冗長)であるとき、Xを候補キーと呼びます。

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

連結キー

複数の属性でエンティティオカレンスを一意に識別できる場合、この複数属性のことを連結キーまたは複合キーといいます。
また、外部キーが連結キーの一部になる(リレーションシップが連結キーの一部になる)場合もあります。

一意識別子の抽出

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

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

一意識別子とコード体系

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

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

クイズ5

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

コードの種類 現行のコード 現行のコードがもつ意味
商品コード X01A 先頭1バイトが商品分野を示す
(カジュアル、フォーマル、アウトドア、スポーツなど)
次の2バイトが連番、最後の1バイトがバージョンを示す
商品カタログコード AA101 先頭2バイトが対象層を示す(メンズ、レディス、キッス、ベビーなど)
次の3バイトが連番を示す

表2-6 コード体系

クイズ5の解答例

エンティティ、リレーションシップ、一意識別子の表記例

図2-25 エンティティ、リレーションシップ、一意識別子の表記例

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

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

データベース設計についてもっと学びたいなら

> Oracle設計 研修コース一覧

具体的な作業イメージが掴みづらい概念設計を詳しく学べるコースです。
技術力に定評のあるトレーナー陣がデータベース設計作業をじっくり丁寧に解説し、スキルアップをサポートします。
また、ご要望に応じて一社向けに研修コースをカスタマイズすることも可能です。

スケジュールガイド

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

エディフィストラーニングHOME