Jas*_*Krs 6 erd database-design architecture application-design
我正在处理的应用程序的核心功能似乎只是关联实体。因此，一对多关系会产生“元数据”，这些“元数据”只会为我们的应用程序功能提供（以一种或另一种方式）关联实体。
现在我们有一个实体关系图 (ERD)，它有很多一对多（超过 10 个表）和只有一个关联实体。它对该模型或应用程序有何看法？
是否可以改进，即，如果改进 ERD 以添加更多关联实体，应用程序是否可以绕过更多功能？
关联实体很少是否意味着应用程序的功能不会很丰富？
其他注意事项
我想知道的是：如果项目范围说明书导致 ERD 只有一个多对多关系和十几个一对多关系，那么这是否意味着该项目没有解决很多问题（功能）除了只数字化大量数据？
我认为，如果多对多较少，它们一开始只会镜像（除非我们为其他目的创建连接查询......）。
或者简单地说：大量的多对多关联是否意味着软件的功能将比少对多的软件更丰富（不要在这个想法中包括连接查询）？
您涉及多个主题，因此确定它们的范围以及它们之间存在的联系很重要。
首先，如果您正在使用的特定业务领域意味着 (a) 多个一对多关联以及一个关联实体类型——或多对多 [M:N] 关联——，并且(b) 您是在感兴趣的数据库的概念和逻辑抽象级别以所需的精度表示所述特征然后(c) 这种情况没有什么特别的，你做得很好。
一个正确分隔的概念模式——我不确定，但似乎这就是你所说的“项目范围说明书”——意味着识别和定义描述实体类型之间互连 (1)的相关业务规则，( 2) 在实体类型和它们自己的属性之间以及 (3) 在属性本身之间，这可能以完全不同的基数比率出现——既不是只有一对多 [1:N]，也不是完全多对多 [M :N]- 并且可能会或可能不会在实体关系图中表示（为简洁起见，ERD）。
关于问题的初始标题，关联实体类型——它不同于实体，即实体类型的实例或出现——只有在数据库建模者未能（i）识别它并因此（ii） ) 没有在相关的概念模式中反映它，也许在 ERD 中。
描述某个场景的关联和相应基数比的 ERD 不应该解决“数字化批次数据的问题”，而是用于以图形方式捕获和公开相关业务的概念定义的目的。这种图表是一种交流工具，如果使用得当，它会非常强大。
如果您想查看具有非常不同的基数比（以及随后的逻辑级别表示）的关联的数据库概念模式的描述示例，请访问例如我对题为
既然你提到了“表”，我假设你有构建关系数据库的意图，并且所述类型的数据库必须独立于共享访问它的应用程序（应用程序，为简洁起见）。
自然，数据库的概念和逻辑元素的数量对应用程序必须（a）从最终用户终端或其他系统接收，（b）应用一些计算处理和（c ) 发送到数据库。但是应用程序组件（例如，面向对象的类）的量没有不一定必须镜（1）的概念层次的实体类型的数据库的数量也没有（2）对应的逻辑布局的基表的数量（例如，单个面向对象类的字段可能包含两个或多个基表或派生表的列）。
另一方面，ERD不是由表格组成，而是由描绘实体类型和关系的图形结构组成（我更喜欢词关联、连接或链接，原因我将在下面详述）。反过来，所述实体类型和关系通常由基表（即基关系）表示，并通过在具有相应数据类型或域（即关系属性）的列上声明的约束来强制执行，如果它们由凭借关系型上正在运行的数据库关系数据库管理系统——这是典型的情况，但概念级元素可以由例如过时的网络或分层数据库来处理。
以这种方式，区分 (i) 概念级关系和 (ii) 逻辑级关系非常重要，逻辑级关系是数学结构——由EF Codd 博士在他的关系模型中提出——用于管理数据一个关系数据库。在这方面，您可能会找到本系列帖子的帮助。
区分基本数据结构和可推导数据结构也是合适的；前者通常由基表表示（即，由 CREATE TABLE ... ( ... ); 语句的 dint 声明的表），后者由派生表（即，通过 SELECT 操作表示的表，例如“组合”列 FROM不同的基表或其他派生表通过 JOIN，有时固定为 VIEW），当在关系数据库上操作时。由于应用程序组件必须直接与将感兴趣的信息显示给最终用户的方式有关，因此当涉及到 ANSI/SPARC 架构时，它们属于外部抽象级别，因此它们应该与上述意见。
反过来，应用程序的功能涉及执行过程（使用面向对象的编程术语的“行为”），并且应该通过与创建数据库时使用的技术不同的技术（例如算法开发）进行分析和定义，因为数据库建模和应用程序设计是两个不同（虽然相关）的学科。
整个计算机化信息系统（即一个数据库和一个或多个共享它的应用程序）的结构和功能丰富性完全取决于设计者在成功（即准确）表示信息方面所拥有的技能。（关于数据库）和处理或计算（关于应用程序）要求。这与称为关注点分离的软件开发原则一致。