SQLは画面や帳票のインターフェイス層に相当する
下記の記事で、データモデリングではSQLは画面や帳票のインターフェイス層に相当する、という点に気づいた。
ラフなメモ書き。
【参考】
顧客も技術者も不幸になる人海戦術に終止符を、実データで設計を吟味せよ | 日経クロステック(xTECH)
【1】僕はSQLは好きだ。
下手にExcelでデータをこねくり回すくらいなら、RDBに入れたデータをSQLで自由自在に抽出したり集計する方が楽だから。
一方、データモデラーではSQLは重視しない点にちょっと違和感があった。
しかし、上記の記事で、SQLは画面や帳票のユーザインタフェースに相当する事に気づいて納得した。
実際、正規化されたテーブルがあれば、欲しいデータはSQLで取ればいい。
その欲しいデータは、画面にあらわれているデータであり、帳票として印刷されるデータそのものだから。
よって、モデラーが業務の制約条件を上手くテーブル設計に反映しておけば、ユーザはSQLで好きなようにデータを抽出できるはず。
一方、訓練された設計者であれば、ER図を眺めれば、そこから業務フローや帳票、画面をイメージできるだろうが、外部設計フェーズで画面設計や帳票設計に注力してしまい、DB設計は単にデータベース定義書を作るだけ、という考えでいると、複雑なシステムになってしまい、失敗しやすいのだろう。
【2】サロゲートキーで統一されたテーブルでは、Webシステムは作りやすい。
Railsが典型的な例。
URLとメソッド、テーブルが1対1に関連付けられるので、URLベースで設計すれば、そのままプログラミングできる。
一方、DOAでモデル駆動開発を推進したい時、サロゲートキー中心のデータモデルでは、テーブル間の関係が判別しにくい。
テーブルを結合したり、入力データの制約がすぐに見えないからだ。
よって、業務を知るユーザがSQLを駆使して、テーブルを結合して、欲しい帳票を得る手法が取りづらくなる。
だから、データモデリング主導の開発では、サロゲートキーは廃止して、明示的にテーブル間の関数従属性を可視化できるようにしておきたい欲望がある。
【3】業務フローからテーブル設計するのはPOA。
本来のデータモデリングでは、AsIsの業務で手元にある帳票からER図を洗い出せる。
これは「楽々ERDレッスン」と同じ考え方。
やはり、既存の帳票はデータモデルの源泉になるから。
他方、あるべきデータモデルから、業務フローや画面構成を想像することはできるか?
これができれば、業務の要件定義がやりやすくなる。
これをやるには、個人的には、T字型ERの手法がやりやすいと思っている。
なぜなら、リソースやイベントのテーブル同士のリレーションシップは一定の法則で決定づけられる、という方針なので、初心者には使いやすいから。
「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索
業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索
| 固定リンク
« テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA | トップページ | Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine »
「モデリング」カテゴリの記事
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
「経済学・ERP・財務会計」カテゴリの記事
- 経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある(2022.06.04)
- Pythonで微分積分や統計の基礎を理解しよう(2022.05.15)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
コメント