【问题标题】:Does the Class Diagram present the Database structure?类图是否呈现数据库结构?
【发布时间】:2020-02-25 13:38:37
【问题描述】:

我第一次自己开始一个完整的项目,我被困在 UML 模型化(类图)和数据库结构之间。

我应该使用我在数据库的类图中建模的完全相同的类吗?

例如,我有两个UserService_providerClient。在类图中,我将它们中的每一个都视为一个独特的类。但是我选择在数据库中使用单表继承,所以我将两个用户存储在同一个表中,并在其中添加角色属性。

我的模型在这种情况下是否仍然有效?或者我只需要User 的一堂课? (但在这种情况下,我无法显示Service_providerClient 之间的关系,因为Service_provider 可能有很多Clients

谁能给我解释一下,好吗?

【问题讨论】:

  • 嗨@Ellin,您的单表方法也称为Table-Per-Hierarchy (TPH),但您也可以对多个表使用方法。 This post 对此进行了很好的讨论,我相信它会回答您的问题。我个人的建议是创建多个表,因为我很难想象像 Client 这样的类不会以 User 中不存在的唯一成员结尾,这种情况会导致数据库中的可空列很少。 (如果使用单个表)。
  • 您好,@diogoslima,实际上我选择使用单表方法是因为我只有一个字段存在于 service_provider 而不是 client 表中,并且所有其他字段都相同,所以我不想重复两个具有几乎完全相同字段的表。
  • 伟大的@Elin,所以如果你做出这个决定,我相信你的问题的简短回答是你的模型是有效的并且很好。通常,最佳实践指导我们,关系数据库和应用程序具有独立的设计,因为它们建立在不同的需求之上。如果您知道您的选择(正如我在之前的评论中分享的那样)并做出了决定,那看起来不错????如果您希望我将此作为您问题的答案,请告诉我。
  • 谢谢@diogoslima,是的!你实际上帮助我澄清了事情
  • 我很高兴能够提供帮助!我只是在下面的答案中总结了我们的聊天。祝您编码愉快,祝您项目顺利。

标签: database uml class-diagram single-table-inheritance


【解决方案1】:

UML 模型可以共存以用于不同的目的。例如,您可以使用分析图来理解领域,使用设计图来显示概念解决方案,并使用实现图来了解实际解决方案的细节。

您还可以保留一个不断发展的模型。但在这种情况下,您会放弃最初的设计,只保留实现模型。不幸的是,这个模型最没用,因为它与代码中的信息有些冗余,很快就过时了。

因此,我强烈建议保留两者:

  1. 真正的设计模型,显示您所看到的类;
  2. 带有表格的数据库模型来记录ORM mapping。为此,您可以使用 database profile 为 UML 添加 «table» 构造型

在纯数据库建模中,出于类似原因,区分逻辑模型(实体、关系)和物理模型(实现逻辑模型的表)也很常见。

例子:

【讨论】:

    【解决方案2】:

    一整套(不断发展的)模型支持应用的开发,如下图所示。

    在开发应用程序时制作 UML 类模型的三个主要目的是:

    1. 描述应用问题域的实体类型,以便在概念(域)模型中分析和更好地理解应用的需求。
    2. 设计应用底层数据库的架构(这通常是使用一组 CREATE TABLE 语句定义的 RDB 架构)。
    3. 设计您应用的数据模型模型类,将被编码为Java实体类或C#类带有 EF 注释。

    对于 1 和 2,您可以看看我的书 An introduction to information modeling and databases,而对于 3,您可以查看有关基于模型的开发的书,例如对于Java Backend AppsJavaScript Frontend Apps

    【讨论】:

    • 请说明这只是您的意见,并非基于任何国际公认的标准。 Rational Unified Process(不再流行)定义了其他模型,参见admiraalit.nl/admiraal/WhichUMLmodels.pdf
    • @www.admiralalit.nl:我的解释基于 OMG 的 MDA 标准。 RUP 不是一个开放标准,而是由一家公司提出的。
    【解决方案3】:

    虽然现有答案已经描述了问题域,但我想补充的是,独立的类设计和数据库模型(均源自抽象分析模型)将随着时间的推移而发展。一些工具支持模型转换和可追溯性,但我不会太相信这些。最好设置您的个人可追溯性和良好的机制以保持模型同步。随着时间的推移,这可能会变得很棘手,需要在任何建模之上进行全面分析。

    【讨论】:

      【解决方案4】:

      简而言之(正如我们在 cmets 中所讨论的),您的模型是有效且良好的 :)

      当然,我的回答是考虑到决定是在了解应用程序和数据库要求的情况下做出的。并且了解您对可用选项有很好的掌握(例如this other post 中列举的选项)。

      通常,最佳实践指导我们,关系数据库和应用程序具有独立的设计,因为它们建立在不同的需求之上。因此,没有必要尝试完美匹配它们的组件,但要确保数据架构和关系定义良好。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2015-06-29
        • 2011-11-23
        • 2013-12-19
        • 2020-03-11
        • 1970-01-01
        • 2021-11-30
        • 1970-01-01
        相关资源
        最近更新 更多