はむはむエンジニアぶろぐ

このブログのコンセプトは"ハッキングの為なら愛する家族を傷つけることをいとわない" 自分にとってエンジニアリングは "手段ではなく生きる目的" である

【書評】T字型ERデータベース 設計技法

古き良きエンティティの抽出の極意という感じだった。
モデリングする上で知っておいた方がいいテクニックである。

第一部 基準編

T字型ER手法の体系

有意味なデータ構造を説明するために使った技法が、T字型ER手法。
T字型ER手法は、データ設計技法ではなく、ビジネス解析技法である。
現行のコード体系(受注番号など)を基にデータをグループ化してビジネスを逆解析する手法である。

DOA(データ中心アプローチ)は、POA(プロセス中心アプローチ)と違い、ビジネスで使われているデータ(帳票など)を基にデータ設計をする。
http://e-words.jp/w/DOA.html

identifierとentity

idは、データ集合であるentityを生成する判断基準である。
つまり、entityとはidが付与されているものである。

T字型ER図の表現形式

ER図は、T字型で書く。

f:id:secret_hamuhamu:20170325160542p:plain

ビジネス解析をしている段階で、データにアクセスするための一意性は考慮しなくてよい。
ナチュラルキーだけで、モデリングしてER図にする。
実際にcreate tableする際に、サロゲートキーであるidをつける。

<T字型ER図作成手順>

  1. idには、コード体系で補足されているXX番号やXXコードを使用する。
  2. entityに名称をつける
    従業員番号 -> 従業員
    部門コード -> 部門
    請求書番号 -> 請求

T字型は、コード体系に準拠しているので存在しないコード体系は使用しないこと。

entityは、以下の2つに分類される。

  • resource(事物)
  • event(事象)

<resourceとeventを区別する方法>

  • 数量や金額と言ったものが存在する
  • 〇〇(entity名)日という意味が通じるならevent
  • 〇〇(entity名)するという意味が通じるならevent

当てはまらないケースも有り(分類というresource)

Entityの配置

T字型のeventとresourceの配置

f:id:secret_hamuhamu:20170326133435p:plain

このように配置することで、見落としたeventが存在しないかチェックできる。
resourceが2つ以上あれば、eventを逆生成できる。
その為、resourceが特に大切である。
データ解析は、resourceの解析と言える。

resourceの数が多いなら、やれることが多いのでビジネスの可能性を増大できる。
しかし、eventの数が多いのであればビジネスがそれらのeventに制約されているということである。

勘違いされたER概念

ER手法は、思考手段(解析手段)である。
正規化してから、ER手法を使ってデータ構造を表現するものではない。

従業員ファイルに、部門コードが入ってしまうと、もはや従業員はresourceではなくなってしまう。
データ解析はresourceの解析のことを言う。

論理設計の目的は、minimal cover + stable である。
つまり、必要最小限のデータ量で、安定したデータ構造を提供する。

対照表

resourceとresourceを結んだ時に生成されるものを対照表という。
resourceとresourceの関係であれば、どちらかに他方のresourceのidを挿入することは無い。
外部キーを挿入されたresourceは、resourceではなくなってしまう。

そのため対照表を作る。
対照表は、resourceとresourceをつなげるのでeventとなる。

f:id:secret_hamuhamu:20170326141526p:plain

対応表

event:eventを結ぶものを対応表と呼ぶ。
対応表は時系列の遅い方に、外部キーを挿入する。

アトリビュートのnull

attributeは、entityが生成されたときには、すべての値がセットされているのを原則とする。
なので、nullが入るようなカラムは別のテーブルに切り出す。

例えば、ユーザにnullの退会日を設けるのではなくactive_userとwithdrawal_userに分ける。