我仍在学习 OO 设计的所有功能，并且在数据库（特别是 ER）设计方面拥有更多经验。每次我处理一个问题并尝试按照 OO 策略提出设计时，我的图表（例如 UML 类）看起来就像一个 ERD。我已经阅读/听说将一个类映射到每个表并从那里工作是很聪明的......但这似乎从来没有真正让我到任何地方，而且我的设计有非常高（坏）的耦合，据我所知，这是一个OO 中的大“禁忌”。
一些谷歌搜索返回了从 ER 到 OO 的一些点击，但没有什么能真正让我明白。有没有人有关于这个主题的任何材料，或者可能已经为这个类似的问题而苦苦挣扎？
稍微扩展一下，我尝试的 OO 设计倾向于转向隐含的持久数据存储元素，这在 OO 设计中不一定存在。
感谢您的任何指导！
我怀疑从你写的内容中你需要更多关于一些核心 OO 设计原则的经验/知识，特别是继承和多态性。对这些概念的良好理解可以帮助您更好地理解对象之间的关系以及它们应该耦合的方式。
鉴于您对 OO 设计向隐含的持久数据存储元素发展的评论，您可能还想研究诸如面向方面编程之类的概念（Spring 是一个很好的工具）。另外，看看像 Hibernate 这样的 ORM 可以做什么，以及它是如何做到的（虽然这可能有点高级）。
实际上只有一种方法可以学习面向对象的软件设计：从头开始学习。您找不到任何捷径可以将您对另一种软件设计方法的知识转化为对面向对象设计的理解。你需要从基础开始，就像其他人一样：封装、抽象、is-a 和 has-a 关系等。
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 Mapping），但数据/程序的基本目的并不完全相同。
所以我认为OO只是一种抽象设计的技术，而不是设计的目标。