データモデリング
- データと情報
- エンティティとリレーションシップ
- リソースエンティティとイベントエンティティ
- リレーションシップと多重度（カージナリティ）
- PK と AK と FK
- ドメインとデータ型
- 制約 (PK 制約、一意制約、NOT NULL 制約、参照制約、CHECK 制約)
- インデックス
- ドメインとデータ型までは概念設計
- 制約からが論理設計
データ：ある事実
情報 ：データを組み合わせて人間が必要となるものをつくる
データは記録・登録するもの。作り出せない。
情報はデータから作り出せる。
たとえば、
「未入荷」というのは情報。発注と入荷というデータ、事実の記録から作り出すもの。
発注したデータの集まりから入荷したデータの集まりの差をとれば、未入荷のものという情報が得られる。
データはテーブルとして設計される。
ER 図
エンティティとリレーションシップ。四角い枠をエンティティと呼ぶ。エンティティとエンティティの間の関係性（結ぶ線）をリレーションシップと呼ぶ。
テーブルを設計しようと考えるよりも、実世界（＝リアルワールド）をモデリングしようと考えるほうが良いことが多い。
図で表現することで
- 言葉で表現すると曖昧になってしまうようなこと
- 全体像を見ることができる
- 皆で考えを共有する
良いモデリングの例。地下鉄の路線図。必要な情報がすべて入っていて、かつ見やすい。重要なエッセンスを取り出して、不必要な情報は省略してわかりやすく簡素にする。
- リソース:
- あるモノがある時に存在した、存在する <登録>
- 名前を持つ。
- リソースの扱う「時」とイベントの扱う「時」の違いは、イベントは瞬間の刻印であり、リソースは有効に存在する期間を表現する。
- イベント:
- 繰り返し行われる行為。ある時起こった <記録>
- 例) 入荷、発注、etc
- 時刻 (タイムスタンプ) を持つ。
- 多くの場合、リソースを使って行われる
- 名前は (イベント自体がその行為の名前になってるので) 持たない
イベントはリソースとリソースを使って行われる行為。そのイベントとリソース間の関係を表現するのがリレーションシップ。
典型
+------------+ +------------+
| Event |●-----------------| Resource |
+------------+ +------------+
●
｜
｜
｜
+------------+
| Resource |
+------------+
時系列のイベント
+------------+ +------------+
| Event |-----------------●| Event |
+------------+ +------------+
前 後
まれ
+------------+ +------------+
| Resource |●-----------------| Event |
+------------+ +------------+
イベントがリソースを作り出す。非常にまれなので、こういうことがあったら間違っていないか確認したほうがいい
多重度: P (1 以上)
+------------+ +------------+
| Resource |-----------------●| Event |親
+------------+ +------------+
｜
｜
｜
●P (1 以上)
+------------+子 +------------+
| Resource |●-----------------| Event |
+------------+ n +------------+
多重度: Z (0 または 1)
+------------+ 1 +------------+
| |-----------------●| |
+------------+ Z +------------+
(0 または 1)
スーパー・サブ
+------------+ スーパー
----------------●| PK |----------------●
+------------+
｜
｜
○
==============
| |
+------+ +------+
| Z | Z
+------------+ +------------+ サブ
| PK | | PK |
+------------+ +------------+
スーパー・サブで一組でイベントかリソースを表す。スーパーが xx 区分を持って、サブのどちらかを表現する。
ER 図を作ったら、モデリングツールで入力し、そこから DDL (Data Definition Language) の自動生成へつなげる。
こうして蓄積したデータから必要になる情報を作り出すのが SQL (DML: Data Manipulation Language)
情報は SQL を書けば書くだけ後から作りだすことができる。モデリングとしては、システム化する対象をモデリングして、事実を記録 (データをつくる) することを重視する。事実はそのときに記録することを逃すとあとから作り出せない。
- 資材としてのリソース: コンサートの座席。売りものとして扱える。売ったらなくなる。そのときによって価格を変えたりとか。
- 資産としてのリソース: 座席。管理番号を持って、列などの座標を持ったり。
同じ座席だけど、こういうときは別モノとして管理する。
Q. テーブル設計の原則に従うと、One Fact in One Place で考えたい。でも、一方で名前を併存期間を持たせて扱いたいというようなバージョニングの問題がある。いつ洗い替えをするか、あるいはしないのか、この辺の課題はどのように扱いますか？
A. あるときリソースの名前が変わる、そのときは期間によってリソースのインスタンスは変えてやる。イベント発生のタイミングによって紐付くリソースのインスタンスが変わる。
R ●-----------------○
| ｜
| ●---------------->->
| |
| |
E ^ ^
Q. 期中に商品の名前が変わったが、あとから売上集計するときは同じ商品として計上したいようなときがある。このようなとき、リソースの期間でバージョンを扱うと、どのように対処する？
A. バージョニング後に名寄せしたいときは、「あれとあれはいっしょに集計したい」という意図に従って情報を得たいというケース。「いっしょに集計したいもの」の管理をするリソースとして扱ってやる。