はじめに
今回は、#テーブル設計 超入門 の勉強会に参加して、テーブル設計をする上で考えるべきことについて学んだので備忘録としてまとめておきます。 初学者なりの解釈であるため、解釈のズレ等あるかもしれません。（少しずつ更新予定）
下記twitterで勉強会の資料がアップされています。参考にしてみて下さい。
（勉強会の資料をアップしてくれるのはありがたい）
#テーブル設計 超入門
前半
1. アプリ開発におけるデータ設計の意義
2. データ分割、テーブル設計
3. RDRAでデータ設計を俯瞰
4. データモデルとドメインモデル
アプリ開発におけるデータ設計の意義
アプリ開発でしばしばデータから考えることが多いがそれはなぜなのか？
それは、他のview(画面)やservice(処理)といったものは状況によって変化しやすいがDBは変化しにくいものであるからである。つまり、変化しにくい＝中心になりやすいためにDBを考えるのはアプリ開発をする上では取っ掛かりやすい項目なのだ。
データ分割、テーブル設計
ただ、実際に必要なデータを考える上で、画面や帳票にはデータの拾いやすさがあり、画面等を作って具体的に当てはめてデータの項目を挙げていくことは多々ある。
つまり、テーブル設計の流れとして
○データで必要なものをピックアップ
(ピックアップの手段として画面モックや帳票も同時に考える作業は必要。)
○データの項目を具体的にピックアップした後は、データの塊を整理。
（マスターデータ/トランザクションデータ）
○正規化・NOTNULL制約などの制約の設定
これでテーブル設計は完成だろうか？
RDRAでデータ設計を俯瞰
本当にこれで十分かどうか？を精査する手段の1つとしてRDRAがある。
RDRAとは一言で言うと要件定義、要件手法のこと。4つのレイヤー(システム価値・システム外部環境・システム境界・システム)に分けてダイアグラムを書くことで要件の内容をモデリングする手法。
(RDRAを使わないにしても…)
○要件定義に戻って吟味し、実際に表計算などでデータを作ってみることでデータの過不足やおかしな機能をチェックする。
○データモデルを作る際に、概念モデル・論理モデル・物理モデルと段階を踏んで作成することでチーム内での認識の齟齬を減らす。
データモデルとドメインモデル
要件定義→設計→実装の順に作業が流れていくが、設計を担うのがドメインモデル・データモデルである。DDDで言うところのモデルの定義はここでは割愛するが、
ドメインモデルは、ビジネスルールやロジックをどうするか？状態の遷移ルールは？データ構造はどうあるべきか？ビジネスプロセスは？など考えることが多く、いきなり取り掛かるのは難しい。
ドメインモデル ： 動的（考えることが多い）
データモデル ： 静的 (変化しにくい) → 取っ掛かりやすい
アプリ開発ではデータモデルから考えるのが無難。
最後に
テーブル設計する際に気をつけるべきこととして、ある一断面しか見ずにテーブル設計をすると限られた状況でしか使えないテーブルになってしまうことが挙げられる。
そのため、『全体から詳細を俯瞰し、データを具体化し気づきを得る』。この一連の作業を繰り返すことでデータモデルが洗練されていくことに繋がる。