假设我有一个“交易”表，其中有一列“客户 ID”（外键）和一个带有“ID”（主键）的客户表。如何显示两个表之间的关系并显示“客户 ID”是“交易”表的外键，而“交易”表是“客户”表中的主键？
我在 google 上搜索了这个问题，并在这个论坛上搜索了我的查询，但找不到一个带有解决我问题的图表的确切示例。
如果可能，请用图表向我解释。
我正在处理的应用程序的核心功能似乎只是关联实体。因此，一对多关系会产生“元数据”，这些“元数据”只会为我们的应用程序功能提供（以一种或另一种方式）关联实体。
现在我们有一个实体关系图 (ERD)，它有很多一对多（超过 10 个表）和只有一个关联实体。它对该模型或应用程序有何看法？
是否可以改进，即，如果改进 ERD 以添加更多关联实体，应用程序是否可以绕过更多功能？
关联实体很少是否意味着应用程序的功能不会很丰富？
其他注意事项
我想知道的是：如果项目范围说明书导致 ERD 只有一个多对多关系和十几个一对多关系，那么这是否意味着该项目没有解决很多问题（功能）除了只数字化大量数据？
我认为，如果多对多较少，它们一开始只会镜像（除非我们为其他目的创建连接查询......）。
或者简单地说：大量的多对多关联是否意味着软件的功能将比少对多的软件更丰富（不要在这个想法中包括连接查询）？
三级 ANSI SPARC 数据库架构建议了三个数据抽象级别，即外部、概念和内部级别。
如果我理解正确的话，外部层代表用户的视图，概念层是概念图（ER模型），内部层是关系模型。
我的问题是，我在文献中发现，除了这些之外，还有第四个层次（最低的一个），就是物理层次。
我想了解具体是什么？是不是在这一点上我们定义了索引的类型、访问路径以及与数据物理访问相关的事情？