E-R図

E-R図はE(Entity)とR(relationship)で表記する方法です。
概念データモデルで前述したデータの集まりでるエンティティ(実態)同士をリレーションシップ(関連)します。
「データ定義」→「データ標準化」→「正規化」してからE-R図で表記していきます。
E-R図を作成する流れは以下です。

  1. (1) エンティティ抽出
  2. (2) エンティティ定義
  3. (3) E-R図作成

以下にエンティティの定義を記載します。

ユーザ 問題データ 問題回答ログ
ユーザID 実施年度 実施年度
パスワード 問題番号 問題番号
ニックネーム 分類 分類
最終ログイン日 問題内容 問題番号
図 ユーザID
回答アの内容 回答内容
回答イの内容 閲覧ブラウザ
回答ウの内容 実施日
回答エの内容
回答
分類
区分
問題の解説
作成日
更新日

「ユーザ」「問題データ」「問題回答ログ」に当たるのがエンティティタイプ名といい、その下の項目(ユーザID/実施年度など)を属性名といいます。
エンティティ間の結びつきをリレーションシップといいます。
概念データモデルでは、エンティティタイプ名だけを記載してリレーションし、論理データモデルでは属性も含めてリレーションします。
属性に実際の値を持ったもの(ユーザID：12345678901/実施年度：2018など)をインスタンス(実態)といいます。
論理データモデルのリレーションは、以下のようなイメージです。

エンティティ間の結びつき 実線の下線は主キー(レコードを特定するキー)を表します。
破線の下線は外部キー(別のエンティティを特定するキー)を表します。
主キーを構成する属性の組の一部が外部キーを構成する場合は、破線の下線は付けません。

結びつきの記載として「1対1」「1対多」「多対多」があり、以下のようなイメージです。 ※通常、主キーは1の値になり、外部キーは多の値になります。

様々なエンティティ

「〇」と「●」で、存在するしないを表記します。
「〇」の場合は存在しない(0になることがある)が含まれます。
「●」の場合は必ず存在(必須)します。

例としてエンティティ名の「ユーザ」は存在しないとそのログ保存されませんので、ユーザは「●」になりますが、ログは使用しなくてもいいですので「〇」で記載します。
また、問題データが存在しなければ問題を解き回答するとういログは発生しませんので、問題回答ログは同じく、「〇」になり問題は「●」で記載します。
記載方法としては、以下のようなイメージです。

リレーションの記載方法

エンティティには、強エンティティ(強実体)、弱エンティティ(弱実体)があり、強エンティティは他のエンティティが存在しなくても存在できるエンティティで弱エンティティは他のエンティティのインスタンスが存在するときだけ存在できるエンティティです。

次にスーパータイプとサブタイプについて記載します。
例として問題のエンティティには、IPAとLPIの問題があり、IPAには年度がありLPIにはレベルがあったとします。
その場合に問題の中にIPAとLPIが存在するため、スーパータイプを問題としてサブタイプをIPAとLPIとすることができます。
この関係を「is-a」の関係といい、「IPAは問題です。」となります。
スーパータイプとサブタイプは以下のようなイメージです。

スーパータイプとサブタイプ

問題のエンティティをサンプルとし、問題データをスーパータイプとしてデータベーススペシャリストやネットワークスペシャリストをサブタイプとしています。
サブタイプの切り口の単位に△を記載してスーパータイプと線をつなげます。

問題からIPAやLPIのように分類させることを特化といい、逆にIPAやLPIを一般問題化すること汎化と言います。
特化するには、主キーを同じにして、区分（今回では問題区分）を利用してIPAかLPIに振り分けます。
スーパータイプとサブタイプになるケースですが、IPAやLPIの属性のほとんどが同じで一部が異なるケースで使われます。
IPAやLPIで異なる部分(年度やレベル)をサブタイプに記述していくのを特化といいます。
エンティティや属性の記載は以下のようになります。

この記述方法は関係スキーマといい、次で説明いたします。
また、問題の区分を2つ（IPA区分とLPI区分）の切り口にすると次のようになります。

スーパータイプとサブタイプ

こちらでは取り扱いませんが、「part-of」の関係やは「has-a」の関係があります。
「part-of」では、厚生関係を表現します。
デスクトップPCを例として、一般的にデスクトップPCにはPCとモニタとキーボードとマウスの構成が考えられ、デスクトップPCからこのような構成に分解することを分解といいます。
また、分解している構成からデスクトップPCに集約することを集約化といいます。

「has-a」では、強い所有関係を表現します。
例として、ある会社の社員が存在した場合、その社員に扶養家族が存在すると社員と扶養家族に所有関係がありますので、そのような場合で利用したりします。

関係スキーマ

関係スキーマとは、関係名と属性を以下のように表記することです。
関係スキーマ 実線の下線は主キー(レコードを特定するキー)を表します。
破線の下線は外部キー(別のエンティティを特定するキー)を表します。
主キーを構成する属性の組の一部が外部キーを構成する場合は、破線の下線は付けません。
属性名1から属性名4に関数従属している場合は、「属性名1 → 属性名4」と記載します。
属性名1と属性名2から属性名4に関数従属している場合は、「{属性名1,属性名2} → 属性名4」と記載します。
属性名4から属性名1と属性名2が関数従属する場合は、「属性名4 → {属性名1,属性名2}、属性名4 → 属性名1、属性名4 → 属性名2」と記載します。
表で記載しますと以下のようになり、データベーススペシャリストの試験でも使用されています。
関係スキーマ例 実施年度と問題番号から問題内容が関数従属している場合は、「{実施年度,問題番号} → 問題内容」となります。

UML

E-R図の表記方法以外にも表記方法はあり、その1つのUMLについて記載します。 UMLはUnified(統一)・Modeling(モデリング)・Language(言語)で表記する方法です。
UMLには、ユースケース図 ·アクティビティ図などいろいろありますが、今回はデータベース試験で使用される内容について学習していきます。
データベースで使用されるUMLは以下です。

UML

□ですが、上がクラス名(部・課)で下が属性(部コード・課コード)です。
その下に要素がある場合は、それは操作になります。
図と図を線でつなげているのはその図同士に関連がある場合に線をつなげます。
破線は依存で、他の図に影響します。
破線の途中に◇がある場合、集約(全体と部分を表す)を表します。
記号の意味は以下です。
1：一つ
*：0以上
0..*：0以上
1..*：一つ以上
5..10：5つから10まで

ビジネスモデル

E/R図などデータベース設計をする上で、ビジネスモデルの考慮も必要です。
ビジネスモデルとは実世界で利益を生み出すための体系です。
例えば、ポイントカードを利用したお買い物もビジネスモデルになり、ポイントを貯めて割引や商品交換などでお得になるためお店がユーザをポイント目的で囲い込み利益を生み出すビジネスモデルです。
ビジネスモデルを理解する前に一般的なデータにはマスターデータとトランザクションデータとで分かれます。
マスター系は、社員・商品など基礎となる情報で、一度登録すると(新商品や入社などの例外を除き)特に増加することがないものです。
トランザクションデータは出社・商品購入・ログなど定期的にレコードが増加するものです。
トランザクションデータはファクトデータともいいます。
データベースを会社などの業務で進める場合は、ビジネスモデルの理解と設計が必要になっていきます。

← 関係モデル
正規化 →