问是否有充分的理由使用ER图而不是UML类图来进行数据建模？ERD是数据建模的COBOL吗？

EN

当我开发一个新功能时，我总是使用ERD。对我来说，数据结构比用来与它们交互的类更重要，而且重要的是要记住这两者并不一定是相同的。在将来的某个时候，我可能需要将一个类分割成多个类，或者将多个表的对象表示形式组合成一个类。我还可以使用不同的语言编写依赖于同一数据库的程序，比如Clojure或Haskell，其中将查询结果表示为对象是不自然的。

在我看来，UML是“数据建模的COBOL”，因为它代表了一个面向对象的必胜时期，假设一个单一的对象模型与数据库处于同一层。不是-也不应该是。在我的经验中，随着Rails所影响的对软件级数据完整性约束的使用，导致了很多痛苦。

一些相关的引文：

“把你的流程图给我看，把你的桌子藏起来，我就会继续迷惑不解。给我看看你的表格，我通常不需要你的流程图；它们会很明显。“-弗雷德·布鲁克斯( Fred Brooks )”事实上，我会声称，一个糟糕的程序员和一个优秀程序员之间的区别在于，他是否认为自己的代码或数据结构更重要。“-莱纳斯·托瓦尔兹( Linus Torvalds )”规则5。数据占主导地位。如果您选择了正确的数据结构，并且组织得很好，算法几乎总是不言自明的。数据结构，而不是算法，是编程的核心。“-罗伯派克”将知识纳入数据，这样程序逻辑才会愚蠢和健壮。

到目前为止，似乎没有一个答案能够理解概念数据建模和物理数据建模之间的区别。

UML概念模型将显示继承关系、基数和所有这些好东西，并提供最小的实现细节。

物理模型(ER图)将有所不同：

1. 继承已不再明显。有三种将继承映射到关系数据库的经典方法--每个具体类的表、每个类的层次结构表和每个基类的表+每个具体类的表(仅保留额外的字段)。许多数据库混合了这三种方法，因此ER图清楚地显示了物理映射。
2. 概念模型中的多到多映射转换为ER图中的联接表。在概念模型中，这只是一对乌鸦脚的符号，在关系链接的末尾。在数据库中，它是一个真正的表。
3. 命名约定通常是不同的。例如，我的组织将Java字段映射到Oracle列CREATION_TS时间戳。

但如果有选择的话，我总是选择ER图。考虑到概念模型，您无法轻松地编写SQL。考虑到一个不熟悉且没有文档的数据库，我通常使用反向工程工具来创建一个ER图。有了一个很好的工具和一个定义了引用完整性约束的数据库，您就会得到很好的结果。

概念模型的目标受众可能是企业架构师和更具技术性的业务分析师。

因此，在我看来，UML和ER图具有相似但完全不同的用途。