お題: DB設計書の書き方

2023-12-20 4 min read

A：エンプラ向けのDB設計書の書き方って、何かいい参考書とかドキュメントあるかなあ。ChatGPTに聞いたりしてとりあえずこういう項目は書くことにしたんだけど。

RDBMS設計書の目次案
概要

- 物理設計
  - DBどこにおくのかみたいなやつ
- ミドルウェア設計
  - DB何使うのか（PostgreSQL使うのか、みたいな）みたいなやつ
- 論理設計
  - DB設計
    - 複数のデータベースある場合はそれらの説明
  - DBごとのテーブル設計
  - ER図的な何か
  - スキーマのバージョニングとマイグレーション
- セキュリティ
  - 認証
  - 認可
  - ロール定義
    - 一覧と説明
  - ユーザー定義
    - 管理者とか
- バックアップとリカバリ
- ロギング
- 監視
- 運用
  - 起動・停止
- 開発者向けドキュメント
- 接続方式
  - ちゃんとしたクライアント使えよ的なやつ

B：セキュリティ系とか、Audit系とかの考慮は必要かもしれないね。DDLでの変更をあとから追えるようにするやつ。要件によっては要らないかもしれないけど。

C：CRUD表はOLTPなら必ずかくよ。謎のままだとトラブルの元になる。よくERとかCRUDとかと設計は、コードが進むと実装と乖離するから要らないんじゃない？みたいな話も聞くけど、設計図を盲信せずとも議論のベースとして使うだけで、話を整理しやすい。既知と未知を分けられるだけでもマシだよ

B: CRUD表にならなくても、主要な更新系はなにがある？のリストだけでもいいよね

C：そうだよね。あと、テーブルの類型をまとめた資料も作ると便利だよ。

A：テーブルの類型って、履歴系とかマスタ系とかの分類？

C：そうだね。命名規則でも良いんだけど、「このテーブルは履歴系」「このテーブルはマスタ系」「このテーブルは外部連携系」「このテーブルはログ蓄積」みたいなのをある程度分類しておけるようにすると設計議論する際に、おかしなことに気づき易くなる。類型x業務で表を作ると抜け漏れを見つけやすくなる。

A : 業務というのはアプリケーション単位とかシステム単位みたいに、なんらかの業務処理を実行する存在みたいな感じですかね。「分析アプリである」とか、「作業者が手入力して更新していくアプリである」とか、「別の大きな業務を行うシステムと接続する部分である」とか

C : そうそう

A : なるほどね。そういえば、別の同僚がDBの移行を行う影響と複雑度をだすために、どのテーブルは段階移行できるのかできないのか、とかを調べてた。最初からそれがわかる設計資料あるとやりやすいのか

B：あとDFDはよく書くね。古のいわゆるDFDでなくて、単にデータの流れがわかる図。 どちらかというとETLパイプラインの図かな。ただしOLTP含む。流量とバッチ頻度とかを記入すると、真のデータ鮮度を洗い出せる。

C：データフローは論理と物理に分けるとわかりやすいよ。

A：おすすめの設計書って、

  • テーブルの類型
  • 論理テーブル一覧
  • 物理テーブル一覧
  • CRUD表

とかかな。

B：テーブルのフィールド単位まで細かく書き出す必要はないよね。

C: そうね。テーブルのフィールド単位まで細かく書きだすと、ドキュメントのメンテできなくなる。それらが一通り揃ったら、テーブルの類型と業務の直交表を作って、抜け漏れを確認する。

B：論理テーブルと物理テーブルって、どういう意味？

C：論理テーブルは、要件定義で出てくる用語を使って作る一覧。物理テーブルは、連関テーブルみたいなDB固有の仕組みを含めたテーブル一覧。物理テーブル一覧とDDLは対応関係があるけど、論理テーブル一覧とDDLに対応関係はない。一つの論理テーブルが一つの物理テーブルになるとは限らないんだよね。

A : なるほど。「売上伝票」「ユーザー」みたいなのが論理テーブルで出てくる用語で、「sales」とか「user」みたいに実際のDDLで定義されるテーブル名が含まれてるやつを物理テーブルって感じですね

C : そうそう

B：CRUD表は論理テーブルに対して書くよね。物理テーブルに書くと破滅する。

C：そうだね。論理テーブルへのCRUDはアプリケーション実装とは直接は関係ないから変更頻度が低いんだよね。そういう変わらない事、当たり前の事が明文化されてると物理設計がすごく捗るのよ

A：類型って、マスタテーブル、システムマスタテーブル、イベントテーブルとかそういう感じかな？

B：そうだね。その類型に概要説明、データの追加頻度、更新頻度、削除頻度、列数の想定、データのざっくりとした規模感みたいなのを雑にまとめておくと良いよ。

A：すごい。めちゃくちゃ参考になります。

B：よかった。

この記事は、pyspa内での会話をBardで蒸留してもらいました。

shirou

ロボットです