我正在做关于数据库的工作，现在我需要展示三个不同的图像，一个带有概念模型的图像，另一个带有逻辑模型的图像，另一个带有数据库的物理模型的图像。
但是我在这里很难理解哪个图像代表每个模型。
我正在寻找有关此的可靠信息，但我找到了不同的答案，我有点困惑。
所以我来这里看看你能不能帮助我。
我的三张图片下面有，你认为我对每张图片都有正确的标题吗？
概念模型：
在概念模型中，我认为我需要将我的表格与属性但没有关系。
逻辑模型：
在逻辑模型中，我认为我需要将我的表格与属性放在一起，但现在与我的关系一起。
物理模型：
在物理模型中，我认为我需要将表与属性一起放置，但现在与我的关系以及外键一起放置
概念模型 (CM) 是以用户理解的方式表示的业务的非正式表示。它将由具有属性的实体类和有关这些的业务规则组成。它通常以实体关系图的形式呈现。
逻辑模型 (LM) 将 CM 形式化为数据结构和完整性约束。它应该包括数据的所有数据结构和完整性约束（这是所有约束，而不仅仅是在大多数可用数据库管理系统中容易定义的约束子集）。它与数据库管理系统无关。
LM 可以表示为关系数据模型 (RDM)。在这种情况下，所有数据结构和完整性约束将仅使用数学关系正式表示。
物理模型 (PM) 是 LM 在特定硬件和数据库管理系统上的表示。它可能包含存储大小和位置等信息；索引等访问方法；和分布，例如聚类或分区。
使用这些定义，我会说所有图表都是概念模型的版本；因为它们不包括所管理数据的所有完整性约束，也不包括有关特定硬件或数据库管理系统上的实施的任何信息。
多年来，概念/逻辑/物理层发生了一些变化，并且根据不同的思想流派而有所不同。我在 1980 年代的学习方式是这样的：
概念模型参考主题总结了数据的语义。它不受关系实现的约束。实现可以在某种预关系数据库中，甚至可以在经典的记录文件中。您有实体、关系、属性和域。你也有业务规则。就是这样。与您的摘要一样，它主要用于与用户和其他利益相关者进行交流。这个想法是在分析阶段确定需求。
逻辑模型是初步设计。它绑定到关系模型，但不绑定到特定的 DBMS。你有关系、元组、属性和约束。关系被实现为外键，有时需要连接关系。我倾向于使用表、行和列的术语，而不是关系、元组和属性，但这主要是命名法。规范化在这里是相关的。
物理模型是一个详细的设计。它是特定于 DBMS 的，并考虑了数据量、预期流量和性能。非规范化在这里是相关的。这直接导致创建脚本。
这绝不是多数人的观点，更不是普遍的共识。你需要了解你的听众，看看这个框架是否有效。
是作业还是什么？这个问题似乎太人为了……
第三个是物理的，因为数据类型更接近于实际的 DBMS 数据类型。
在第一个和第二个之间......我被卡住了。唯一的区别是鱼尾纹关系。如果三张图片之间有进展，我猜这会使第二张成为概念图。
但这很困难，因为使用 PowerDesigner，您仍然可以在逻辑模型中表示与乌鸦脚的关系。但不管怎样，应该有实体中“外键”属性迁移的证据，这里就没有了
没有。我阅读示例图的速度太快了，逻辑模型中没有迁移。id_cat。News
所以，只是通过消除，我会让第一个逻辑。