私はまだ OO 設計のすべての力を学んでおり、データベース (特に ER) 設計の経験が豊富です。問題に取り組み、OO 戦略に従って設計を考え出そうとするたびに、図 (UML クラスなど) が ERD のように見えます。クラスを各テーブルにマップしてそこから作業するのが賢明だと読んだり聞いたりしました...オブジェクト指向の大きな「いいえ」。
いくつかの Google 検索では、ER から OO への移行に関するいくつかのヒットが返されましたが、実際に掘り下げたものは何もありませんでした。誰かがこのトピックに関する資料を持っていますか、またはおそらくこの同様の問題に苦労していますか?
少し拡張するために、私が試みた OO 設計は、必ずしも OO 設計に存在しない暗黙の永続データ ストレージ要素に移行する傾向があります。
ご指導ありがとうございます。
オブジェクト指向ソフトウェアの設計を学ぶ方法は、実際には1つしかありません。それは、最初から学ぶことです。別のソフトウェア設計方法の知識をオブジェクト指向設計の理解に変換するための近道はありません。他の人と同じように、基本から始める必要があります。カプセル化、抽象化、is-aおよびhas-a関係などです。
あなたが書いたものから、いくつかのコアOO設計原則、特に継承とポリモーフィズムについてのより多くの経験/知識が必要であると思います。これらの概念をよく理解すると、オブジェクト間の関係、およびオブジェクトを結合する方法をよりよく理解するのに役立ちます。
暗黙の永続データストレージ要素に移行するオブジェクト指向設計についてのコメントを考えると、アスペクト指向プログラミングなどの概念も検討することをお勧めします（Springはこのための優れたツールです）。また、HibernateなどのORMで何ができるのか、どのように実行されるのかを調べてください（ただし、これは少し進んでいる可能性があります）。
E / Rコンセプトモデルは、エンティティ間の関係を設計する必要がある場合に役立ちます。設計時にどのように実装されるかは気にしないでください。Class、DataTable、XMLなどに変換できます。
あなたが求めていることは少し異なります。小規模なシステムの場合、またはビジネスロジックがそれほど複雑でない場合は、データテーブルのようなドメインモデルオブジェクトを作成できます。この場合、テーブルごとにオブジェクトを作成できます。このパターンは「テーブルモジュールパターン」と呼ばれます
http://martinfowler.com/eaaCatalog/tableModule.html
前述のようなシステムでNhibernate、EF、またはその他のORMを使用すると、実際には必要のないレイヤーを追加するため、リソースと時間の無駄になります。
Database Systems: A Practical Approach to...は、私が推奨する教科書 (第 3 章から第 4 章) です。
データ (リレーショナル データ モデル) とプログラムの根本的な違いが、ER と OO 設計の間の主なギャップだと思います。データベース スキーマの設計を UML で描くことはできますが、それは、現実のデータ モデルが OO パラダイムの意味のあるものになるという意味ではありません。
プログラムは、別の側面から見ると、再利用性の規律に従って正しく処理することに重点を置いています。ただし、データは、パフォーマンスの規律に従って正しく持続することに重点を置いています。
ギャップを緩和するいくつかのテクニックがありますが (OR マッピングなど)、データ/プログラムの基本的な目的は完全に同じではありません。
ですので、オブジェクト指向はあくまでデザインを抽象化するためのテクニックであり、デザインのゴールではないと思います。