t_wの輪郭

「システム開発って何やったらいいですか？」って聞かれたので、当時よくわかってなかったなりに「ER図書きましょう」と答えたのだけれど、間違いではなかったっぽい。

概念データモデル

詳細さという面では最も大まかだが、モデルセットに含めるべき全体像を明らかにするという役割を担う最も上位のERモデル。概念ERモデルは通常、組織が使用するマスタ参照データ実体を定義する。組織全体の概念ERモデルを開発することで、組織のデータアーキテクチャ（英語版）の文書化に役立つ。概念ERモデルは1つ以上の論理データモデルの基盤として使うことができる。概念ERモデルのその際の目的は、論理ERモデル間でマスタデータ実体の構造的メタデータの共通性を確立することにある。概念データモデルは、データモデル統合の基盤としてERモデル間の共通性確立に使われることもある。

論理データモデル

異機種混合の単一のシステムを対象として論理ERモデルを構築するなら、概念ERモデルは特に必要とされない。論理ERモデルは概念ERモデルよりも詳細である。マスタデータ実体に加え、運用上および業務上のデータ実体も定義する。各データ実体を詳細化し、それらデータ実体間の実体関連を確立する。ただし、論理ERモデルの実装にはそれぞれ独立の技術が使用される。

物理データモデル

1つの論理ERモデルに対応して1つ以上の物理ERモデルが作られる。物理ERモデルは通常、そのままデータベースとして実体化される。したがって物理ERモデルにはデータベースを作るのに十分な詳細さが必須であり、個々の物理ERモデルは対応するデータベース管理システムの仕様に影響される。物理モデルは通常、構造化メタデータをデータベース管理システム上の関係データベースオブジェクト（表、主キーなどの索引、外部キー制約などのデータベースの制約）として実装できるよう設計が進められる。物理ERモデルは関係データベースの改造の際にもよく使われる。

引用元：https://ja.wikipedia.org/wiki/実体関連モデル#概要 2022年3月26日

https://products.sint.co.jp/ober/blog/create-er-diagram

https://plantuml.com/ja/ie-diagram

　PlantUMLでER図を書いていて気づいたのだけれど、輪郭のデータ構造ってどれだけ親ノードをたどっていっても根ノードにたどり着けないな。なんてデータ構造だ。
　なので、読み込みをした直後に表示するノードは、特別に記録しておかないといけない。

　テーブル設計がつらすぎる。DBの経験が薄い＆DBから長らく離れていた せいだろう。プログラムだったら感覚でなんとなくなんかいい感じにできてしまうが、経験のないやつはどうしようもない。
　PlantUMLでER図を書いて、壁打ちしたほうがよさそうだ。設計資料も残るのでその意味でも利点がある。

https://www.wakuwakubank.com/posts/805-design-uml-er/