数据模型实现与PowerDesigner 16授权到期PDM打不开排查指南

打开项目资料看到这个编号“03.02.01.02”的时候，我大概就猜到提问的人正在学一门结构化的数据课程，而且多半卡在了同一个问题上：理论都听了，PowerDesigner也装了，可一旦要动手实现一个Data Model，就不知道怎么把业务需求变成一张张表。更麻烦的是，很多人用的PowerDesigner 16是评估版或工作电脑上的授权快到期了，关键时候双击一个PDM物理数据模型文件，软件直接不给用。这个场景我见过太多次，今天干脆把数据模型基础实现的完整思路写出来——从一个课程报名需求开始，讲清楚概念模型怎么翻译成物理模型、主外键和约束怎么落地、DDL怎么写，再专门讲PowerDesigner 16授权到期导致PDM打不开时应该怎么排查和自救。内容适合正在学习数据建模的同学，也适合被建模工具卡住、急需把模型抢救出来的在职开发。

1. 先搞清楚你在实现哪一层模型：概念、逻辑还是物理

很多初学者拿到建模题就急着开PowerDesigner画表，这是一个很自然的冲动，但也是后面返工率最高的原因。你还没想清楚要实现的到底是哪一层数据模型，就跳到了最终的物理实现，中间少了一步最重要的翻译过程。

1.1 数据模型不是一种，而是三层

稍微正规一点的数据建模训练都会提到三层模型，但实际项目里真正把它们分清楚的人不多。我用一句话概括：

• 概念数据模型（CDM）描述“业务世界里有哪些东西”，不关心技术；
• 逻辑数据模型（LDM）描述“这些东西之间的关系和数据规则”，但还不指定具体数据库；
• 物理数据模型（PDM）回答“在某个数据库里到底怎么存”，表名、列名、类型、索引都在这一层定下来。

大多数人说的“建个数据库表结构”，其实只对应第三层。PowerDesigner里的PDM，全称就是Physical Data Model，也就是物理数据模型文件。所以当你连PDM文件都打不开的时候，真正受影响的是最接近开发交付的那一层产物。

1.2 用一门课程报名需求举例：三层分别长什么样

为了不空谈理论，后面整个文章都用同一个例子：一个简单的课程报名管理需求，学生可以选课，一门课可以被多个学生选，选课后记录报名日期和最终成绩。

概念层我们只需要一句话：学生和课程之间存在多对多选修关系。这里不出现表名，不讨论字段长度，更不讨论MySQL还是SQL Server。

逻辑层要开始把实体提炼出来，并给出属性和关系了：

• 学生：学号、姓名、邮箱
• 课程：课程编码、课程名称、学分
• 选课关系：学生选某门课、报名时间、成绩

注意“选课”本身是一个关系，但在逻辑模型里它已经可以看成一个关联实体。一个学生会选多门课，一门课会被多个学生选，学生和课程之间是多对多。关系型数据库不能直接表达多对多，所以后面必须拆成中间表，这是逻辑模型阶段最重要的决策之一。

物理层要做的事就具体了：学生变成student表，学号设计成什么类型，姓名最长多少个字符，邮箱是否允许为空；选课关系变成enrollment表，用什么做主键，学生和课程的外键指向谁，成绩用什么类型保存才不会出现精度问题。这一层不再有模糊地带，每个决策都直接影响后续代码和数据库性能。

1.3 物理模型这一步到底比逻辑模型多了什么

有人觉得逻辑模型已经画出了属性和关系，物理模型不过是换了个工具的重复劳动。我不同意这个观点。从逻辑到物理不是机械翻译，而是一系列取舍：

第一，逻辑模型里的“学生ID”在物理层要决定用自增整数还是业务编号。学号看起来像自然键，但学生转学、学号重新分配的时候，它会成为灾难，所以物理层往往会额外生成一个代理主键。

第二，逻辑模型不管大小写、不管Unicode，物理层必须管。例如MySQL里，VARCHAR(50)的50指的是字符数而不是字节数，utf8mb4下中文姓名可以放心存，但如果用错了排序规则，唯一索引就会和你以为的大小写行为不一致。

第三，逻辑模型只说明“学生可以有多门课”，物理层必须通过外键约束把这条规则真正写进数据库，否则应用层漏判一次，脏数据就进去了。

在PowerDesigner操作时，你会看到每个列有Name和Code两个属性，Name可以写成“学生姓名”给业务看，Code写成student_name给数据库用。这是物理模型工具最常见的用法，也说明物理模型本身就是面向工程交付的。

想清楚自己在做哪一层之后，再往下看键、关系和约束，才有判断依据。

2. 把业务关系翻译成表结构：键与约束才是模型的地基

逻辑模型里画几条线很容易，可只要落到物理表，“关系是用什么字段维护的”“空值允不允许”“重复数据谁来拦”这些问题