イミュータブルなテーブル設計を目指して
本タイトル通り、不変的なテーブル設計目指すため、学習したことを書いておこうと思います。 今までテーブル設計に関して、正規化を守っていれば万事OKみたいな考えのもと、前職でテーブル設計などを行なっていました。 ことの発端はtwadaさんがインタビューを受けているweb音声メディアでテーブル設計の話しを聞いたことがきっかけで、設計に対する根本的な考えを変えないといけないと思いました。
データと情報
データとは
- いつ、誰が、どの店で、何を、いくら、購入したという『事実』を表す
データとは事実なのです。DBの本質は適切に事実を保存しておくこと。 〇〇したという事実は一過性で２度の再現性はないのです。
この観点から、事実を改竄(update), 損失(delete)するということは、基本的に一般の世の中では不正的な側面もあり行わないと思います。 なので適切にこれらの事実を保存しておくことが第一歩だと考えました。
また、１つのエンティティに複数の意味を持たせないことも重要です。userが部署コード、〜IDをたくさん持っているとか。あくまでuserを形成している要素だけを持たせておくことが大事。
情報とは
- 「データ」を選択、加工して当事者が必要とする知識（新たな価値）を取り出したもの
- 情報の必要性と価値は、当事者によって、時期によって、様々に変化する
常に求められているのは「情報」、そのために「データ」が必要！
「データ」は情報を生み出す宝の山！！
そんなデータを簡単にupdate「改ざん」delete「紛失」をアプリケーションで行っている。。
そして、updateは処理を複雑にする原因でもある。
以上から根本的な設計に関しての考えかたを変えないといけないと思いました。
物(resource)とコト(event)という考えかた
現実世界には「ある消費者(user)がスーパーで豆腐を買う」というactionがあると思います。ここでactionを物とコトで分けて考えると
- ある消費者(物): who
- スーパーで(物): where
- 豆腐(物): which
- 買う(コト): how
という風に分けることができます。
以上を踏まえ、論理モデリングリングする際に実世界の物事をモノ（resource）とコト（event）に分けてEntityとして抽出する作業を行います`。 この時点ではリレーションシップのことは一旦忘れる様にする。そうすることでデータのあるべき姿をEntityに表現しやすくなると考えてます。
モデリングする際は 5w1hを用いる
5W1Hがエンティティの候補
- Who 従業員,患者,プレイヤー,顧客,生徒,...
- What 製品,サービス,コース,曲,
- When 時間,日付,月,年,年度,...
- Where 送付先,URL,IPアドレス,...
- Why 注文,返品,入金,出金,取引,…
- How 請求書,契約書,注文書,…
また、5W1Hの分類において
- Who, What, When, Where → リソース
- Why, How → イベント
なんでもかんでも登録日、更新日をつけない
resourceエンティティに登録日は必要だろうか？？自然の流れだと、「userがサービスに登録する」が自然の流れで、 ということはuserというresourceがあり、入会と退会に相当するevent エンティティに該当するテーブルを設けることが自然な流れに感じる。
ここで、イベントはそのアクションが行なった日時時刻をもつ性質があるので、カラムとして持たせるが、必ずしもuserといったresorceエンティティは 日付時刻は必要ないと考える。
終わりに
こんな感じで自分の中のテーブル設計の考え方にインパクトを与えられました。 まだまだ、書き足りないですが参考になったリンクを貼っておきます。
