Class 图是否显示了数据库结构？
Does the Class Diagram present the Database structure?
我是第一次自己开始一个完整的项目，我被困在UML模型化（Class图）和数据库结构之间。
我是否应该使用与我在数据库的 class 图中建模的完全相同的 classes？
比如我有两个User，Service_provider和Client。在 class 图表中，我将它们中的每一个都视为唯一的 class。但是我选择在数据库中使用单table继承，所以我将两个用户存储在同一个table中，并为其添加角色属性。
我的模型化在这种情况下是否仍然有效？或者我只需要一个 class 用于 User？ （但在这种情况下，我无法显示 Service_provider 和 Client 之间的关系，因为 Service_provider 可能有很多 Clients）
有人可以给我解释一下吗？
简而言之（正如我们在评论中讨论的那样），您的模型是有效且良好的:)
当然，我的回答是考虑到在了解应用程序和数据库要求的情况下做出的决定。并且了解您对可用选项（例如 this other post 中列举的选项）有很好的掌握。
通常，最佳实践指导我们关系数据库和应用程序具有独立的设计，因为它们建立在不同的需求之上。因此，没有必要尝试完美匹配它们的组件，但要确保数据模式和关系定义明确。
UML 模型可以为不同的目的共存。例如，您可以使用分析图来了解领域，使用设计图来展示概念性解决方案，并使用实现图来了解实际解决方案的细节。
您也可以保留一个进化的模型。但在这种情况下，您将放弃初始设计，只保留实现模型。不幸的是，这个模型是最没有用的，因为它与代码中的信息有些冗余并且很快就会过时。
因此我强烈建议同时保留两者：
- 真实的设计模型，如您所见 类；
- 一个带有表的数据库模型来记录 ORM mapping. For this you coud use a database profile 为 UML 添加
«table» 构造型
在纯数据库建模中，出于类似原因，区分逻辑模型（实体、关系）和物理模型（实现逻辑模型的表）也很常见。
示例：
- Martin Fowler 解释的single table inheritance
- 一个answer to another question about database modeling with UML
虽然现有的答案已经描述了我想补充的问题领域，但独立的 class 设计和数据库模型（均源自抽象分析模型）将随着时间的推移而发展。一些工具支持模型转换和可追溯性，但我不会太相信这些。最好设置个人可追溯性和良好机制以保持模型同步。随着时间的推移，这可能会变得棘手，需要在任何建模之上进行彻底的分析。
应用程序的开发由一整套（不断发展的）模型支持，如下图所示。
在开发应用程序时制作 UML class 模型的三个主要目的是：
- 描述应用程序问题域的实体类型，以便在概念（域）模型.
中分析和更好地理解应用程序的需求
- 设计应用程序底层数据库的模式（这通常是用一堆 CREATE TABLE 语句定义的 RDB 模式）。
- 设计 模型 classes 数据模型应用程序，它将被编码，例如，作为 Java 实体 classes 或带有 EF 注释的 C# classes。
1和2可以看看我的书An introduction to information modeling and databases, while for 3 you may check out a book on model-based development, e.g. for Java Backend Apps or JavaScript Frontend Apps。
我是第一次自己开始一个完整的项目，我被困在UML模型化（Class图）和数据库结构之间。
我是否应该使用与我在数据库的 class 图中建模的完全相同的 classes？
比如我有两个User，Service_provider和Client。在 class 图表中，我将它们中的每一个都视为唯一的 class。但是我选择在数据库中使用单table继承，所以我将两个用户存储在同一个table中，并为其添加角色属性。
我的模型化在这种情况下是否仍然有效？或者我只需要一个 class 用于 User？ （但在这种情况下，我无法显示 Service_provider 和 Client 之间的关系，因为 Service_provider 可能有很多 Clients）
有人可以给我解释一下吗？
简而言之（正如我们在评论中讨论的那样），您的模型是有效且良好的:)
当然，我的回答是考虑到在了解应用程序和数据库要求的情况下做出的决定。并且了解您对可用选项（例如 this other post 中列举的选项）有很好的掌握。
通常，最佳实践指导我们关系数据库和应用程序具有独立的设计，因为它们建立在不同的需求之上。因此，没有必要尝试完美匹配它们的组件，但要确保数据模式和关系定义明确。
UML 模型可以为不同的目的共存。例如，您可以使用分析图来了解领域，使用设计图来展示概念性解决方案，并使用实现图来了解实际解决方案的细节。
您也可以保留一个进化的模型。但在这种情况下，您将放弃初始设计，只保留实现模型。不幸的是，这个模型是最没有用的，因为它与代码中的信息有些冗余并且很快就会过时。
因此我强烈建议同时保留两者：
- 真实的设计模型，如您所见 类；
- 一个带有表的数据库模型来记录 ORM mapping. For this you coud use a database profile 为 UML 添加
«table»构造型
在纯数据库建模中，出于类似原因，区分逻辑模型（实体、关系）和物理模型（实现逻辑模型的表）也很常见。
示例：
- Martin Fowler 解释的single table inheritance
- 一个answer to another question about database modeling with UML
虽然现有的答案已经描述了我想补充的问题领域，但独立的 class 设计和数据库模型（均源自抽象分析模型）将随着时间的推移而发展。一些工具支持模型转换和可追溯性，但我不会太相信这些。最好设置个人可追溯性和良好机制以保持模型同步。随着时间的推移，这可能会变得棘手，需要在任何建模之上进行彻底的分析。
应用程序的开发由一整套（不断发展的）模型支持，如下图所示。
在开发应用程序时制作 UML class 模型的三个主要目的是：
- 描述应用程序问题域的实体类型，以便在概念（域）模型. 中分析和更好地理解应用程序的需求
- 设计应用程序底层数据库的模式（这通常是用一堆 CREATE TABLE 语句定义的 RDB 模式）。
- 设计 模型 classes 数据模型应用程序，它将被编码，例如，作为 Java 实体 classes 或带有 EF 注释的 C# classes。
1和2可以看看我的书An introduction to information modeling and databases, while for 3 you may check out a book on model-based development, e.g. for Java Backend Apps or JavaScript Frontend Apps。