语言 Chinese, Simplified

SEO Title

Physical Data Model (PDM)s: An Agile Introduction

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

图1.大学的部分PDM。

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

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

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

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