RDBにおけるデータベース設計手法の分類 - 思想の違いで争わないために
公開日時:
どうもこんにちは。一般通過型システムエンジニア（役職）のニシキです。
今回は、RDBにおけるデータベース設計手法の分類をしてみたいと思います。
というのも、RDBにおけるデータベース設計手法について人と共有する機会があったのですが、 人によってやり方全然違うな、でも納得はできるな、ということがありました。 きちんと名前を付けて扱ってあげることによって、思想の違いで争うことなく、 「そういう考え方もあるんだな」とスルーできるようになるのではないかと思い、 この文章をまとめようと思いました。
はじめに
今回の内容はあくまで主観的なものです。学術的なものではありません。 また、0か1かではなく、グラデーションがあることを理解いただけると幸いです。
データベース設計手法の分類
データベース設計手法の派閥を、個人的には以下のように分類することにしました。
- 画面に基づいた設計
- 機能に基づいた設計
- データモデリングに基づいた設計
画面に基づいた設計
画面に基づいた設計は、画面を作ることが最優先となる設計手法です。
画面の構成要素に近い形のテーブルを作ります。 SQLが簡単になるため、開発が早く進むことが特徴です。
小規模アプリの場合は大体これで事足ります。(なんならRDBを使わなくてもいいかもしれません)
ただ、正直この方法は拡張性が低いので、機能追加が前提のアプリケーションにはおそらく向いていません。
港でアンチパターンと呼ばれたりするステータスカラムが発生しやすいのもこの設計手法の特徴です。
機能に基づいた設計
機能に基づいた設計は、機能の実現性を重視した設計手法です。
正直これをうまく説明する方法が思いつきませんでした。 つまるところは、世の中の設計本などに記載されている一般的なデータベース設計です。
また、SaaSなどの抽象度の高いアプリケーションはこういう設計が多いかもしれません。
データモデリングに基づいた設計
データモデリングに基づいた設計は、データモデリングを重視した設計手法です。
データモデリングにもいろいろな種類がありますが、私などはよくTM法にお世話になります。 現実をデータモデルに落とし込むため、実質的に業務設計図に近くなったりします。
ただこの方法、「テーブル数が多い」みたいなよくわかんねぇ理由で否定されることがあります。 悲しい。
個人的な感想
私はデータモデリングに基づいた設計を好んで使いますが、その理由は基本的には「業務設計図に近いから」です。 さらに深堀をするならば、データベースを基準にしたアプリケーション開発は、 現在のデータベースからER図を生成しやすい(設計書を作りやすい)というのも理由の一つです。
プログラムでももちろんやろうと思えばできますが、 どうしてもプログラムは「機能を作ること」が優先されがちで、そのあとのコードの整理などが後回しになってしまいます。 私にはその力学をどうにかする方法を今のところ持ち合わせていないので、この方法に流れ着きました。
本当は、データベースとプログラム双方で適切なモデリング及び設計を行いたいです。
まとめ
そんなこんなで、RDBにおけるデータベース設計手法の分類をしてみました。 再三言いますが、これはあくまで私の主観です。
こういう風に言語化しておけば、とりあえずこれらに当てはめて私の感情の収集をつけることができるので、 今後もこのような分類をしていくかもしれません。