初めてデータモデル

設計と

向き合ってみた

※スペースですすむ！バックスペースでもどる！

こんにちは！

# 突然ですが
# あなたのチームの # データモデル設計は # どうなってますか？
# チームの # 若手メンバーには # データモデル設計を # 任せられますか？
# これは # 某社にてあった # 事実を元にした # おはなし
## しょぼちむ初めての開発チーム
## チームリーダーからDBAを任される
## (DBAってなんだろう…？データベース…？)
## やっていた仕事 1. チームメンバー「このテーブルにこの項目を追加して」 2. しょぼちむ「おっけー」 3. サブリーダー「確認した。承認した。」 4. しょぼちむ：申請通りにER図をいじって設計書生成してコミット 5. チームメンバー「反映されてる。オッケー」
## (まためんどくさい雑用を押し付けられた！)Oo ## （´・ω・｀）
## はい
## データモデル設計の大切さ ## わかってなかった
## そしてすすんでいく外部設計工程
## そんなとき

てんてんさんがチームにアーキテクトして参入

･:*+.\\(( °ω° ))/.:+

　　　
## そしてX Dayを迎える
## そう、あれは、クリスマス、、、
## 明日で今年の仕事も終わる。そんな冬の日。

てんてんさんがパートナーさんから相談をうける

  • パートナーさん「データの検索条件が複雑になっちゃう」
  • てんてんさん「データモデル設計を見てみる」
  • しょぼちむ「|дﾟ)ﾁﾗｯ」
  • てんてんさん「これってFKとか設定してないの？」
  • しょぼちむ「( ﾟдﾟ)ﾊｯ!!」
  • てんてんさん「データの整合性チェックどうしてるの？」
  • しょぼちむ「( ﾟдﾟ)ﾊｯ!!」
# ( ﾟдﾟ)ﾊｯ !!
## FK、そういえばそんなのあったな。 #あかん
## ん？あれ？？あれ？？？
## サブリーダーが作ってくれて ## チームリーダーが業務的な観点でレビューして ## パートナーさんがアーキテクトとしてレビューした ## そんなER図

※業務で使用してるER図ではありません。
# ＿人人人人人人＿ # ＞　ただの線　＜ # ￣Y^Y^Y^Y^Y￣
![tweet](images/tweet2.png)
![tweet](images/tweet3.png)

![tweet](images/tweet4.png)
# ＼(^o^)／
![tweet](images/tweet5.png)
![tweet](images/tweet6.png)
![tweet](images/no.gif)
## データモデルの修正をはじめた
リレーションシップをペロっとはればいいんでしょ！！

余裕余裕！！

子テーブルのPKが増えた(・_・)
## そもそも親テーブルがもつ項目はこれでいいの？ ![oya](images/edm5.png)
## 親テーブルの項目の見直すことに ## (´・ω・｀)
そもそもなんでPKに変更適用日時なるものが
入っているかというと
  • ユーザ情報は画面から変更したい
  • 変更した設定をいつから適用するか決めたい
  • 過去にどんな設定だったのかを残したい
  • ※いくつかの項目は登録以降は変更しない
親にしようとしていたテーブルは
マスタで設定変更履歴で設定変更予約だった。

さらにテーブルの項目に見直しをかけていくと、
  • 外部システムから参照するだけの項目があった
  • ある特定の業務でしか参照＋更新しない項目があった
さらにテーブルの項目に見直しをかけていくと、
  • 外部システムから参照するだけの項目があった
  • ある特定の業務でしか参照＋更新しない項目があった
このままだと
  • 不変な項目をとる場合でもSQLに
    「1件を取得する」っていう条件を書かなきゃいけない
  • 不変な項目でも毎回INSERTするときにデータを入れないといけない
  • 外部システムがデータを参照する場合にも
    「1件を取得する」っていう条件を書かなきゃいけない
テーブルを役割ごと＋業務ごとにわけてみると、

　　

  • ひとつひとつのテーブルがシンプルになった！
  • 各業務で、余計な項目をとらなくてもよくなった！
  • 不変な項目と変更可能な項目がわかりやすくなった！
マスタテーブルからリレーションシップをつけてみる

つけられた



･:*+.\\(( °ω° ))/.:+
  • それぞれの関係が明確になった！
  • 関係性がないのに線が引いてあったのを検知した！

Before

After

## さらに良かったこと

それぞれのエンティティが

何対何の関係になっているのかを考えることで

不明確になっていた要件を

検知することができた！！

ユーザとユーザグループのカーディナリティは？
この２つのER図でシステムに差がでる

　　　

最終的に

  • ちゃんとデータの整合性を保つ仕組みがある(FK)
  • 各エンティティ同士の関係性もパッと確認することができる
  • それぞれの項目の役割ごとにテーブルがわかれている

くやしかったこと

  • 自分の知識がなくて、ただの線に違和感をもてなかった
  • 外部設計工程が終わってからの修正だったのでガッツリ修正はできなかった

よかったこと

  • データモデル設計の大切さを知ることができた
  • データモデル修正で色々相談していたときに「遅延評価」とか、いままで知らなかったことを知ることができた
  • この勉強会をひらけた！！

意識を改めなきゃいけないこと

  • DBAは雑用なんかじゃない。大切なお仕事だった。
  • (本当にごめんなさい)

たいせつなこと

リレーションシップ

ちゃんとつけよう。

## ありがとうございました ![bye](images/bye.gif)