2.3 概念設計の手順（1/3）

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

2.3 概念設計の手順（1/3）

エンティティとは、簡単にいうとデータの集合ですが、次のように定義することができます。

企業や業務で長期的に管理したい情報
その性質や意味を表すための複数のデータ項目（属性）をもち、特定のデータ項目により識別が可能なもの

エンティティは、システム化する対象となった業務説明の中で、名詞として管理されていることが多いものです。
これまで、すでに情報として管理されているものに関しては、管理するための何らかの識別子がついているはずなので、一意識別子も併せて定義することができます。
また、エンティティオカレンスという用語も設計時に使われることが多いので、用語の定義を解説しておきます。

エンティティの種類

マスタ系エンティティ
イベント系エンティティ
サマリ系エンティティ

エンティティオカレンス

エンティティは管理されるものを抽象化した概念です。
具体的な情報をグループ化した集合体と考えるとわかりやすいでしょう。
エンティティオカレンスとは、エンティティを構成する個別の実体のことです。
エンティティは、実装されるときにはデータベースの表となり、エンティティオカレンスは行（レコード）に相当します。
エンティティを抽出する際には、具体的なオカレンスを思い浮かべ、それをグループとしてまとめるものをエンティティとして考えるとわかりやすいでしょう。

マスタ系エンティティ

比較的安定した管理状態であり、実際に存在するモノを管理するエンティティということができます。
エンティティのオカレンス量や変更の頻度に関しては、時間の経過とともにおきる変化が少ないということができます。
リソース系エンティティとも呼ばれます。

（例）
社員、顧客、店舗、商品

イベント系エンティティ

時間の経過に伴い、企業活動の中で随時発生するオカレンスが、恒常的に増加するエンティティです。
履歴データエンティティとも呼ばれます。
マスタ系のエンティティに対して、エンティティ名は動詞の場合が多く、「動詞で表される処理を履歴として管理する」エンティティということもできます。

マスタ系エンティティとイベント系エンティティの関係を例として挙げます。
顧客が商品を注文する場合、「顧客」「商品」というマスタ系のエンティティどうしを結びつける「注文」がイベント系エンティティとなります。
トップダウンで分析する場合、全体で利用するリソース系のエンティティはわかりやすいため、まず最初に洗い出します。
次にリソース系エンティティを取り囲むようにイベント系エンティティを洗い出していくとわかりやすいでしょう。

（例）
受注、出荷、売上、請求、入金

サマリ系エンティティ

リソース系とイベント系のデータを、あるタイミングで集計した結果のサマリを格納するエンティティです。
定期的な処理（分析やレポート）のための情報を格納するのが一般的です。

サマリ系のエンティティは、バッチ処理で導出的に作成されることが多く、直接マスタ系のエンティティやイベント系のエンティティとはリレーションをもたない場合も多いのが一般的です。
管理している情報が導出の結果なので、本来の正規化の意味からすると存在しないはずのエンティティかもしれませんが、企業として管理する必要のあるデータという意味で抽出します。
どのような処理の結果、エンティティオカレンスが作成されるかという説明が必ず必要です。

（例）
商品別売上集計、部門別売上集計

エンティティの表記法

エンティティは長方形で表し、その中または左上にエンティティ名を記述します。