データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか
関西IT勉強会で、データモデリングについて聞いてきた。
関西IT勉強会の議論について、@kitaohxさんと議論しながら、「データモデリングでは、システムが宿命的に負う複雑性をどのように解決しようとしているのか?」について気付きがあった。
ラフなメモ書き。
【参考】
販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon
システム開発・刷新のための データモデル大全 | 渡辺 幸三 |本 | 通販 | Amazon
業務別データベース設計のためのデータモデリング入門 | 渡辺 幸三 |本 | 通販 | Amazon
生産管理・原価管理システムのためのデータモデリング | 渡辺 幸三 |本 | 通販 | Amazon
業務システムのための上流工程入門 | 渡辺幸三 |本 | 通販 | Amazon
人月の神話 | フレデリック・P・ブルックス,Jr., 滝沢徹, 牧野祐子, 富澤昇 | 工学 | Kindleストア | Amazon
データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会: プログラマの思索
「やさしいデータベース設計」出版記念講演 in 新大阪 - connpass
「やさしいデータベース設計」出版記念講演 in 新大阪 (第105回IT勉強宴会) | IT勉強宴会blog
【0】システムが持つ本質的な複雑性を、データモデリング屋はどのように解決しようとしているのか?
「人月の神話」には「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という一節がある。
この言葉は、システムが本質的な複雑性を持っている、という論点だし、SEもアーキテクトも皆、この論点をいつも考えていると思っている。
この内容について以下考える。
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索
【1】お題は、大学生に対するストレスチェックみたいなアンケートシステムに対し、データモデルを書く。
渡辺さんは、ホワイトボードを前に、ライブ・コンサートみたいに、スラスラとデータモデルを書いていく。
データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会: プログラマの思索
書いたデータモデルについて、参加者と議論があった。
外部キー制約の実装箇所はDB層なのか、アプリ層なのか、あなたがモデラーならどうする?
外部キー制約をRDDBMSに貼れば、ER図をそのまま実現できる形になる。
一方、大量データをデータ移行する時、外部キー制約があると、外部キーとして存在しないキーを登録するとエラーになる。
つまり、データをインポートする順番を事前検討する手間がかかる。
Railsや他のフレームワークでもそうだが、たぶん、RDBのテーブルは主キーぐらいの制約だけで、アプリ層で外部キー制約を実装する場合が多いだろう。
渡辺さんもえとうさんも、話を聞くと同じで、フレームワーク層に配置する、と。
つまり、DBMSに制約も張らず、アプリ層でもなく、その間のフレームワーク層に配置する意見で一致していた。
渡辺さんは自作のローコード開発基盤を持っているので、その基盤上で制約を実装する。
えとうさんはTM手法手法の人だが、Seasarを使っていると言っていたので、フレームワーク層で実装するのだろう。
僕の理解と合ってたので特に違和感なかった。
【2】この論点の問題をさらに発展させると、外部キー制約だけでなく、動的参照関係、ユニーク制約などのDBMSの制約ロジックはDB層なのか、アプリ層なのか、どこに実装すべきなのか?
渡辺さんは、外部キー制約、動的参照関係、ユニーク制約など、DBMSの関数従属性にプラスアルファされる制約条件は、ローコード開発基盤に実装すべきであり、アプリ層に配置すべきではない立場だ。
なぜならば、DBMSの制約条件とビジネスロジックは関心事が異なるから、という論点と理解している。
えとうさんはTM手法ですが、実装レベルでは、Seasarで実装していると言っていたので、フレームワーク層で実現する点は同じと理解している。
つまり、DB層とアプリ層の中間レイヤである純粋仮想化物の層であるフレームワーク層に、制約を配置すべきだ。
【3】アンケートシステムのデータモデルでは、渡辺さんがデータモデルに、「支援制約」「回答値制約」というカラムを書いていた。
ストレスチェックのアンケートシステムの目的は、学生の心身状態をアンケートで回答してもらい、心が病んでいる学生にはカウンセリングや薬物処方などの手当や支援が必要だ、という考え。
だから、アンケートの質問に応じて回答内容は何でも良いわけではなく、何らかの制約がある。
「支援区分」には学生、家族のようなカテゴリがあり、学生への支援内容、家族向けの支援内容ではそれぞれ対策が異なるので、何らかの制約がある。
そのような内容があるので、「支援制約」「回答値制約」と書いていた。
【4】では、「支援制約」「回答値制約」のような制約ロジックの内容をテーブルのカラムに埋め込むのか、フレームワーク層やアプリ層にロジックを実装するのか?
確か楽々フレームワークの人はフレームワークに実装する意見だった。
渡辺さんは、テーブルのカラムに制約ロジックまで入れてしまえばいい意見だった。
例えば、何らかの制約ロジックはJavaScript プログラムのテキストでカラムに放り込み、フレームワーク層でJSプログラムを評価して実行すれば良い。
そうすれば、プログラム実装やビルド、デプロイも不要で、データをアップデートすれば簡単と言う理由と思う。
【5】僕の意見では、単に制約ロジックと言う業務ロジックをDB層に配置するか、フレームワーク層やアプリ層のプログラミングする層に配置するのか、と言う単純な論点ではないと考える。
つまり、論点は、アーキテクトとして、システムが持つ本質的な複雑性をどのように解決しようとするか、だ。
システムが宿命的に負うべき複雑性をいかに分散して全体のコストを最小化すべきか?
一般に、普通のアーキテクトであれば、N層レイヤーの発想を元に、MVCモデルのように、ビジネスロジックを層別に分割し配置して、複雑性を人間の手で扱えるレベルまでバラす。
一方、データモデリング屋は、業務ロジックをできるだけDB層に全て表現したい欲求がある。
この利点は、本質的な複雑性をDB層に押し込むことで、機能を実装するアプリ層の複雑性を狭めて、アプリ開発のコストを減らしたい意図があると考える。
渡辺さんが提唱する三要素分析法は、システムが持つ本質的な複雑性をDB層に落とし込むために、データモデリングでもっと頭を使い、プログラミングするアプリ層は簡単にしたい発想と思う。
「販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon」では、「データモデルと業務モデルを複雑にして機能モデルを簡単にする」という言葉で表現されている。
この意味は、システムが持つ本質的な複雑性をDB層のデータモデルと、例外業務を含む業務手順に集約し、プログラミングで実装する機能モデル、つまり、アプリ層は複雑にすべきではない、という考え方だ。
実際、例外業務はいくらでもあるので、それを全てシステムで実装すべきではないだろう。
年1回しかやらない例外業務で手間が駆らないなら、業務マニュアルで解決すればいい。
例外業務をプログラミングしてしまうと、例外業務のロジックがあれば修正コストが発生し、トレードオフを考慮すると無駄になるかもしれない。
また、業務ロジックから発生する関数従属性の制約条件は、アプリ層で逐一実装するのではなく、DB層あるいはDB層を薄く包むようなフレームワーク層に配置すればいい。
プログラマは、関数従属性の制約ロジックを逐一実装しなくてもいい。
もっと本質的な業務ロジックを実装すべきだから。
【6】この発想を推し進めると、ローコード開発基盤は、データモデルやモデル駆動開発と相性がいいと思う。
ローコード基盤はDB層をラッパーしているから、プログラマはRDBMSのテーブルを直接触ることもないし、アプリ層で必要なオブジェクトだけ触れば、自然に制約条件が満たされる、という形になるはずだ。
つまり、DB層をラッパーしたフレームワーク層はローコード開発基盤というわけだ。
今後はAIがプログラミングしてくれるので、モデリングや要件定義の重要性が高まるから、ますますローコード開発基盤の重要性は高まるだろう。
我々は本来、事業に役立つ業務を実行したいのであって、無駄なプログラムを大量に作りたいわけではない。
ローコード開発基盤を使って、直接の利用ユーザが使いたいシステムを素早く品質よく作りたいのだ。
特にローコード開発基盤は、製造業の基幹系システム、生産管理システムでニーズが多いと思う。
データモデリングを極めていくと、ローコード開発基盤に落ち着き、さらにはAIエージェント駆動によるプログラミング自動生成までつながるのが面白い。
【補足】
データモデリングでドメインを駆動する──分散/疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon
実践的デ-タモデリング入門 (DB Magazine SELECTION) | 真野 正 |本 | 通販 | Amazon
| 固定リンク
« データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会 | トップページ | 自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か? »
「IT本」カテゴリの記事
- 自動車の組込ソフトウェア開発が難しい理由は3つある(2026.02.23)
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
「モデリング」カテゴリの記事
- 自動車の組込ソフトウェア開発が難しい理由は3つある(2026.02.23)
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- 製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか(2026.02.04)
- プ譜でプロジェクトの目的を管理する(2026.01.31)
「経済学・ERP・財務会計」カテゴリの記事
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- E-BOMとM-BOMの違いは何か?(2026.02.08)
- 製造業におけるPLM製品とMES製品の違いは何か?(2026.02.08)
- 日本の半導体産業はなぜ凋落したのか(2026.02.07)
「astahによるUMLモデリング」カテゴリの記事
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)


コメント