こんにちは、TeamSpirit EX バックエンドエンジニアの尾上です！
ここ最近、スキルの向上を目的に研修を受ける機会が多くなっていますが、
オンラインで受けられる研修も多くてインドアの自分は助かっています……！
今回は以前受講した「データモデリング基礎研修」で学んだ内容について自分が気になったことを復習がてらざっくり振り返りたいと思います！
データモデリングとは
以下のような要件を満たせるようにデータの形式（モデル）を設計すること
- データを一定のルールで定めた形式で保管し、情報をわかり易くかつ共有しやすくする
- データの追加・更新・削除を行った場合に関連データ間で不整合を発生させない
- データに効率よくアクセスできる
データモデリングの難しいところ
- ここが決まらないと機能の設計が進まないため、先行して設計作業を行う必要がある
- 一度決めると途中での変更が難しい
（データモデルを前提に設計された他機能に影響が出る）
つまり素早く正確に設計する必要がある（！！！）
データモデリング設計でやること
概念設計
データのエンティティ間の関係、エンティティの属性を決める論理設計
属性のデータ型やデータ長、制約を決める物理設計
"実装可能な状態"に必要なことを決める、DDL（Data Definition Language） を作成する
以降、それぞれのフェーズについてかいつまんでみます！
概念設計でやること
データのエンティティ間の関係や属性を決定するため、
トップダウンアプローチ、ボトムアップアプローチの 2 方向から設計を進めます。
成果物：「概念 ER 図」
- トップダウンアプローチ → どういうシステムを作りたいかの理想を考える
- ボトムアップアプローチ → 現在の旧システムがどうなっているか
ボトムアプローチの「旧システムが〜」はシステム刷新の場面を想定されていそうですが、
「現状どうなっていて何があるのか」から設計をすすめるようなので
普段開発しているプロダクトの新機能に置き換えると……
- 現在顧客はどんな運用をしている？
- プロダクトの他機能はどうなっている？
といったことを考慮して設計するのがよさそうですね！
また、概念設計ではネーミングルールも制定します。
お客さんを指す言葉は「顧客」？「取引先」？
"商品" とは具体的に何を指す？
コンテキストによって「名称」と「〜名」が混在していない？
など、様々な言葉の定義や、命名の規則などを決めていきます。
これによってコミュニーケーションロスの防止や
ドキュメントの可読性向上につながります！
論理設計でやること
エンティティ属性の詳細化と分類
インデックス設計、エンティティのライフサイクル分析
成果物：「論理 ER 図」、「テーブル定義書（論理設計分）」
- エンティティ属性の詳細化 → データの型や取り得る値を体系化、制約の決定
- エンティティのライフサイクル分析 → どの業務がどのエンティティにアクセスするか、アクセスのタイミング
業務要件に沿ってエンティティを詳細化していくフェーズですが
概念設計で業務要件の整理がしっかり出来ていれば、論理設計はひたすら情報を整理していく作業！
物理設計でやること
テーブル定義、インデックス設計、サイズ見積もり
ビュー設計、セキュリティ設計 など
成果物：「テーブル定義書」、「DDL」
- テーブル定義 → 物理名称の決定や管理用列の追加、DDL の作成
- サイズ見積もり → 初期データ件数、増加率増加件数を推定して検査する
- セキュリティ設計 → アクセス権限の設定や暗号化など
テーブルを実装可能な状態にするために必要な細かい情報を詰めていきます！
また、運用に耐えうる件数に収まるか、増加数からみて何年の寿命が見込めるかを試算しておく
アクセス権限の設定では DB ユーザーのアクセス範囲や権限を設定していく。
主に開発者や利用者などで分けたロールを設計し、ロールごとに権限を設定します。
暗号化については、どのデータを暗号化するのか？
暗号化した結果、データサイズへどれほど影響があるか？
暗号方式や、暗号化/復号はどこで行うか？（DB サーバー or AP サーバー）
を決定します。
まとめ
- 概念設計では業務要件を整理してエンティティの関係や属性を決める
- 論理設計では業務要件を元にエンティティのデータ型や制約を決める
- 物理設計では実装可能な状態になるために必要な細かい情報を決める
最後に
研修を受けた時のノートを見ると 2021/07/12 となっていました。
（記事公開：2021/09/01）
タイトルに「やっと書いた」と付けているのはこのためです
早めにブログを書こうと思ってはいたのですが、
なんだかんだずるずると引きずってしまい……。
（細かなタスクは後回しにしがちですが早めに終わらせましょう、、）
-
現在自分はとある新機能のため、Salesforce オブジェクト
（DB テーブルと同じようなもの）の設計を行っていて、 "データモデリングの難しいところ" である
- ここが決まらないと機能の設計が進まないため、先行して設計作業を行う必要がある
- 一度決めると途中での変更が難しい
のプレッシャーに苦しめられています！
- 何から考えればよいのか……？
- 他に考慮すべきことはないか……？
- 自分の判断は正しいか……？
- 他の実現方法はないか……？
新たな挑戦にワクワクする反面、不安になったりもしますが
研修で学んだことを活かしつつ、困ったら頼れるチームに相談して
よりよい機能が実現できるように頑張りたいと思います！
あ、XXXさん！この後ちょっと相談いいですか！！
