数据建模是探索面向数据的结构的行为。与其他建模工件一样，数据模型可用于各种目的，从高级概念模型到物理数据模型（PDM）。物理数据建模在概念上类似于设计类建模，目标是设计数据库的内部模式，描述数据表，这些表的数据列以及表之间的关系。

图1显示了该大学的部分PDM  - 您知道，由于Seminar表包含未显示的表的外键，并且坦率地说很多领域概念，例如课程和教授，这一事实并不完整。显然没有建模。除了其中一个框之外的所有框都代表表，一个例外是UniversityDB，它列出了在数据库中实现的存储过程。因为图中给出了构造型物理数据模型，所以您知道类框表示表，没有图构造型，我需要在每个表上使用构造型表。表之间的关系使用标准UML表示法建模，尽管在示例中未示出，但是对表之间的组合和继承关系进行建模是合理的。通过使用密钥实现关系（更多内容见下文）。

图1.大学的部分PDM。

在进行物理数据建模时，以迭代方式执行以下任务：

1. 识别表格。表是数据库的等价类;数据存储在物理表中。如图1所示，大学有一个学生表来存储学生数据，一个课程表来存储课程数据，等等。图1使用基于UML的表示法（这是一个公开定义的配置文件，任何人都可以提供输入）。如果你有一个类模型，一个好的开始就是将类与数据表进行一对一的映射，这种方法在“绿地”环境中运行良好，你可以从头开始设计数据库模式。 。因为这在实践中很少发生，所以您需要准备好受一个或多个遗留数据库模式的约束，然后您需要将类映射到。在这些情况下，您不太可能需要进行大量数据建模，您只需要学会使用现有数据源，但您需要能够阅读和理解现有模型。在某些情况下，您可能需要先执行旧数据分析并对现有模式进行建模，然后才能开始使用它。
2. 规范化表格。数据规范化是一个过程，在这个过程中，数据模型中的数据属性被组织起来，以增加表的内聚力并减少表之间的耦合。基本目标是确保数据存储在一个且只有一个地方。这是应用程序开发人员的一个重要考虑因素，因为如果数据属性存储在多个位置，将对象存储在关系数据库中是非常困难的。图1中的表格为第三范式（3NF）。
3. 识别列。列是数据库的等效属性，每个表都有一列或多列。例如，Student表具有FirstName和StudentNumber等属性。与类中的属性（可以是基本类型或其他对象）不同，列可以只是基本类型，例如char（字符串），int（整数）或float。
4. 识别存储过程。存储过程在概念上类似于由数据库实现的全局方法。在图1中，您可以看到，诸如averageMark（）和studentsEnrolled（）之类的存储过程被建模为UniversityDB类的操作。这些存储过程实现了与数据库中存储的数据一起使用的代码，在这种情况下，它们计算学生的平均分数并分别计算在给定研讨会中注册的学生数。虽然这些存储过程中的一些明确地对单个表中包含的数据起作用，但它们不是作为表的一部分建模的（沿着作为类的一部分的方法的行）。相反，因为存储过程是整个数据库的一部分而不是单个表，所以它们被建模为具有数据库名称的类的一部分。
5. 应用命名约定。您的组织应该有适用于数据建模的标准和指南，如果没有，您应该游说实施一些。与往常一样，您应该遵循AM的应用建模标准的做法。
6. 确定关系。表之间存在关系，就像类之间存在关系一样。 UML类图中的建议关系适用。
7. 应用数据模型模式。一些数据建模者将应用通用数据模型模式，David Hay（1996）的书“数据模型模式”是该主题的最佳参考。数据模型模式在概念上最接近分析模式，因为它们描述了常见域问题的解决方案。 Hay的书对于参与分析级建模的任何人来说都是一个非常好的参考，即使你采用对象方法而不是数据方法，因为他的模式模拟了来自各种业务领域的业务结构。
8. 分配键。键是一个或多个数据属性，用于唯一标识表中的行。两个或多个属性的键称为复合键。主键是实体类型的首选键，而备用键（也称为辅助键）是访问表中行的替代方法。在物理数据库中，密钥将由一个或多个表列组成，其值唯一地标识关系表中的行。主键使用<< PK >>构造型和外键通过<< FK >>表示。在此处阅读有关密钥的更多信息

尽管使用了类似的符号，但有趣的是注意到图21的PDM与基于ti的UML类图之间的差异：

1. 键。通常的做法是不在类模型上建模脚手架属性，通常建模键（脚手架的数据等价）。
2. 能见度。列的可见性未建模，因为它们都是公开的。但是，由于大多数数据库都支持访问控制权限，因此您可能希望使用UML约束，UML注释或业务规则对其进行建模。类似地，存储过程也是公共的，因此它们也不是建模的。
3. 没有多对多的联想。与对象不同，关系数据库本身不支持多对多关联，因此您需要通过添加关联表来解决它们。与关联表最接近的是WaitList，它是为了解决类图中描述的等待列表中的多对多关联而引入的。纯关联表由两个表的主键列组成，它维护两者之间的关系，在本例中是Student的StudentNumber和Seminar的SeminarOID。请注意，在WaitList中，这些列同时具有PK和FK构造型，因为它们构成WaitList的主键，同时是其他两个表的外键。 WaitList不是真正的关联表，因为它包含非键列，在这种情况下是添加列，用于确保等待列表中的第一个人是在座位可用时有机会注册的人。如果WaitList是一个纯关联表，我会将关联表构造型应用于它。

剩下的敏捷

我经常使用CASE工具来创建物理数据模型。我需要数据建模工具的两个特性是能够生成创建数据库模式所需的数据定义语言（DDL）代码，以及从现有数据库模式反向工程数据模型的能力。实际上，目前市场上的所有数据建模工具都支持这些功能。

资源

此工件描述摘自“对象入门第3版：使用UML 2的敏捷模型驱动开发”的第12章。

This artifact description is excerpted from Chapter 12 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

原文：http://www.agilemodeling.com/artifacts/physicalDataModel.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】