Uml 实体关系建模和面向对象设计-相关吗？

我不确定这是否是一个好问题，因为我不确定在这个问题上是否有任何一致意见。然而，由于互联网上缺乏信息，我不得不问

假设我正在制作一个主要是面向对象的系统，以及相应的UML图（用例、类、协作等）。然而，在处理数据库时，没有一个UML图是有用的，这应该与开发团队相关，这样他们就可以知道数据库中存在什么和不存在什么

有两种表示数据库的方法：实体关系和关系（我不知道是否有更多的方法，但这两种方法在关系数据库范例中是相关的）。ER根据业务规则处理BD的表示，关系处理实际的物理实现。但是没有一个是“UML标准”（除非我在这里遗漏了一些东西）

---

我应该使用哪种建模，为什么？ER是否与UML相关，还是应该坚持使用关系型？事先谢谢。

两者都是不同的ER图是实体的关系，UML图是项目的行为。根据我的观点，DFD（数据流图）是可选的。它有不同的级别，基于进程的数量，可以更好地解释数据实体。

如果只想使用UML，可以使用有限的类图，而不需要m-n关联和方法。但是，如果您使用的是一些类表映射工具，那么您可以使用除m-n关系之外的任何东西

从来没有人说过您只能对OOP类使用类图。如果复杂的CD元素可以满足它们的需求，您可以将它们用于任何或多或少的正式概念。我使用类图进行UI规划，甚至正式的文本规划。桌子离教室很近。所以，没问题

如果需要数据图，可以使用。但它们完全被类图所覆盖。这就是他们不再被支持的原因

---

你的任务是让每个人都能理解这个模型，谁都能掌握它。类图是最广为人知的UML图。一个好的标题和一对评论将解决所有可能的误解。

这是正确的，但两者都与应该传达给开发团队的内容相关。使用OO范式消除了ER建模的相关性，因为业务是通过UML图建模的。这就是为什么我要问ERM在OO系统中的相关性是什么，以及是否应该使用它。我个人认为，当你采用OO范式时，DFD不再是一个选项，因为UML中的大多数（如果不是所有的话）图都取代了DFD的功能。UML没有也不能取代的是数据库的组成方式。所以，如果我理解正确的话。。。我可以用类图代替ER或关系图来解决我所有的问题，对吗？例如，如果我想做一个ER图，我使用UML中相同的基数，就是这样，如果我想做一个关系图，我将它们转换成一个有向关联来表示FKs？是的，你可以使用类来表示它。这是一个标准的学校现在需要通过课堂诊断来描述DB。我上次回答了一些关于它的问题（）对不起，我不知道什么是FK。但您可以使用可导航关联来显示一个表具有另一个表的id。FK=外键，正如您所描述的（一个表具有另一个表的id）。谢谢，这是我的答案。对不起，我不知道你知道什么是外键。我自己也不认识这个缩写。我想：如果美国人为了纪念（约翰·菲茨杰拉德·肯尼迪）而在信中提到了什么名字？