简介：这份资源是北京邮电大学数据库课程实验四的完整实验报告文档，面向正在学习数据库设计的高校学生与自学者，聚焦数据库模式设计这一关键环节。内容围绕在线考试系统展开，涵盖用户、试题库、知识点、试卷与考试管理五个实体的属性定义，并完整呈现从E-R图抽象、Power Designer概念模型构建、物理模型转换到SQL脚本生成与执行的全流程，同时包含考试信息视图与在线试卷视图的创建与验证。资源包共1个docx文件，约1.56MB，以实验报告形式组织，结构清晰，便于对照学习。目前已有145人学习下载。读者可借此掌握E-R图到逻辑模式的转换方法、Power Designer建表与视图操作技巧，以及DB2环境下SQL脚本的导入与验证思路，适合作为数据库实验课参考或课程设计模板使用。
1. 北邮数据库实验四到底在练什么：从 E-R 图到可建库的物理模式
很多同学拿到“数据库模式的设计”这个题目，第一反应是打开 Word 写几段文字交差。但北邮数据库实验四真正想让你走通的，是一条从需求到可执行 SQL 的完整链路：先把业务语义抽象成 E-R 图，再把 E-R 图翻译成关系模式，接着用 Power Designer 这类建模工具把表、字段、主外键、约束画出来，最后导出能在 DB2 或 SQL Server 上直接跑的 DDL 脚本。它解决的不是“会不会写 CREATE TABLE”，而是“能不能在设计阶段就把冗余、异常和约束想清楚”。适合正在做实验四、准备数据库课设，或者第一次用 Power Designer 做物理模型的人。热搜里“数据库模式设计”“Power Designer”“E-R图”“SQL”“DB2”这几个词，恰好就是这条链路上的五个关键节点。
2. 先分清概念模型和物理模型：E-R 图不是画着好看
2.1 概念模型、逻辑模型、物理模型各自负责什么
数据库模式设计最容易翻车的地方，是把三个层次揉成一团。概念模型只关心业务世界里有哪些实体、实体之间是什么联系，典型产物就是 E-R 图；逻辑模型关心的是关系模式，也就是把实体和联系转成一张张二维表，并确定主键、外键；物理模型才关心具体 DBMS 的数据类型、索引、存储参数和约束语法。北邮实验四通常要求你从概念模型一路做到物理模型，所以每一步的产物都要能对得上。
我一般会这样区分：E-R 图里出现“学生”“课程”“选课”这些词，逻辑模型里出现“Student”“Course”“SC”这些表名，物理模型里出现VARCHAR(20)、PRIMARY KEY、FOREIGN KEY这些具体语法。如果你在 E-R 图阶段就开始纠结VARCHAR还是CHAR，说明层次混了；如果你在物理模型阶段还在画菱形表示联系，说明还没落地。
提示：实验报告里最好把三层模型分别截图或导出，老师一眼就能看出你不是直接拍脑袋建表。
2.2 用 Power Designer 建概念模型的实操步骤
Power Designer 的入口是 New Model → Conceptual Data Model。新建之后，先别急着拖实体，先把实体和联系的命名规范定下来。常见做法是实体用单数名词，联系用动词或动宾短语。下面是一个概念模型里实体和属性的描述方式，虽然 Power Designer 是图形化操作，但你可以用这段伪结构来检查自己的模型是否完整。
实体 Student: 属性 Sno（学号，标识符） 属性 Sname（姓名） 属性 Ssex（性别） 属性 Sage（年龄） 属性 Sdept（系别） 实体 Course: 属性 Cno（课程号，标识符） 属性 Cname（课程名） 属性 Ccredit（学分） 联系 SC（Student 与 Course 之间，多对多）: 属性 Grade（成绩）逻辑说明：概念模型里，多对多联系 SC 带一个属性 Grade，这是后面转成独立表的关键。参数说明：标识符就是候选主键，Power Designer 里用下划线或勾选 Primary Identifier 表示。很多同学在这里漏掉联系属性，导致后面 SC 表没有成绩字段，整个设计就断了。
2.3 从 E-R 图转关系模式的四条转换规则
转换规则不复杂，但每条都有边界。第一，每个实体转一张表，实体的标识符转主键。第二，一对多联系把“一”端的主键放到“多”端做外键。第三，多对多联系必须单独转一张表，主键是两个端实体主键的组合。第四，一对一联系可以把任一端主键放到另一端做外键，或者单独建表，看业务查询频率决定。
以学生选课为例，Student 和 Course 是多对多，所以 SC 表的结构应该是SC(Sno, Cno, Grade)，主键是(Sno, Cno)，Sno引用Student(Sno)，Cno引用Course(Cno)。如果你把 Grade 放到 Student 表里，一个学生选多门课就没法存多个成绩，这就是典型的范式错误。
CREATE TABLE SC ( Sno CHAR(9) NOT NULL, Cno CHAR(4) NOT NULL, Grade SMALLINT, PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Student(Sno), FOREIGN KEY (Cno) REFERENCES Course(Cno) );逻辑说明：这段 DDL 是逻辑模型落到物理模型后的产物，主键组合保证同一个学生同一门课只有一条记录。参数说明：CHAR(9)和CHAR(4)是定长字符串，如果学号或课程号长度不固定，可以换成VARCHAR；Grade允许为空，表示还没出成绩，如果业务要求必须录入，就加NOT NULL。
3. 在 Power Designer 里把逻辑模型做成能导出的物理模型
3.1 从 LDM 生成 PDM 的关键选项
Power Designer 里逻辑模型叫 LDM，物理模型叫 PDM。从 LDM 生成 PDM 的入口是 Tools → Generate Physical Data Model。这里有几个选项直接决定导出的 SQL 能不能用。第一，DBMS 要选对，实验要求 DB2 就选 DB2，要求 SQL Server 就选 SQL Server，因为不同 DBMS 的数据类型和约束语法不一样。第二，勾选“Generate primary key”和“Generate foreign key”，否则导出的脚本没有约束。第三，如果 LDM 里用了多对多联系，生成 PDM 时会自动转成中间表，但你要检查表名和字段名是否符合预期。
我见过最常见的翻车是：LDM 里实体名用了中文，生成 PDM 后表名也是中文，导出 SQL 在 DB2 命令行里执行报错。所以命名规范最好在 LDM 阶段就用英文，中文名放到 Comment 或 Name 里。
3.2 物理模型里必须检查的字段类型和约束
生成 PDM 之后，不要直接导出。先打开每张表，检查字段类型。DB2 和 SQL Server 的类型有差异，比如 DB2 里字符串常用VARCHAR，SQL Server 里NVARCHAR更常见；DB2 的IDENTITY和 SQL Server 的IDENTITY语法也不完全一样。下面这张表是我一般会对照检查的项。
| 检查项 | DB2 常见写法 | SQL Server 常见写法 | 注意点 |
|---|---|---|---|
| 自增列 | GENERATED ALWAYS AS IDENTITY | IDENTITY(1,1) | 导出后确认语法匹配 |
| 字符串 | VARCHAR(n) | NVARCHAR(n) | 中文多时优先 Unicode |
| 日期时间 | TIMESTAMP | DATETIME | 精度需求高用DATETIME2 |
| 主键约束 | PRIMARY KEY | PRIMARY KEY | 组合主键顺序要一致 |
| 外键约束 | FOREIGN KEY ... REFERENCES | 同左 | 被引用列必须有唯一约束 |
注意：Power Designer 里改字段类型后，要重新生成一次 DDL，不要手动改导出的 SQL 文件，否则下次生成会覆盖。
3.3 导出 DDL 并在 DB2 上跑通的最小命令
导出路径是 Database → Generate Database。选择目录和文件名，格式选.sql。导出后，在 DB2 命令行里执行。假设你已经建好数据库testdb，并且用db2 connect to testdb连上了，那么执行脚本的命令是：
db2 -tvf schema.sql逻辑说明：-t表示语句以分号结尾，-v表示回显每条语句，-f表示从文件读取。参数说明：如果脚本里有大量语句，建议加-z output.log把错误输出到日志，方便排查。执行完用db2 list tables确认表是否建成功。
如果报错“SQL0104N An unexpected token”，多半是语句分隔符或类型不匹配；如果报错“SQL0204N ... is an undefined name”，多半是外键引用的表还没建，调整脚本里 CREATE TABLE 的顺序即可。
4. 避坑与排查：实验四最容易翻车的五个地方
4.1 现象：Power Designer 里表名显示成中文，导出 SQL 报错
原因：LDM 阶段实体 Name 用了中文，PDM 生成时把 Name 当成了 Code。解决：在 LDM 里把 Name 写成中文，Code 写成英文；或者在 PDM 里用 Tools → Model Options 把 Name 和 Code 的映射关系改掉。更稳妥的做法是一开始就英文命名，中文放 Comment。
4.2 现象：导出的 SQL 在 DB2 里执行到外键就失败
原因：CREATE TABLE 的顺序不对，子表先于父表创建。解决：手动调整脚本顺序，先建被引用的表，再建引用表；或者在 Power Designer 生成时勾选“Generate foreign key after all tables”，让外键用 ALTER TABLE 单独加。
4.3 现象：多对多联系转成中间表后，主键丢了
原因：LDM 里多对多联系没有设置标识符，生成 PDM 时中间表没有主键。解决：回到 LDM，给联系加上标识符，或者手动在 PDM 里给中间表设置组合主键。
4.4 现象：SQL Server 上执行脚本提示“对象名无效”
原因：没有切换到正确的数据库，或者脚本里用了dbo.前缀但当前用户没有权限。解决：先执行USE 你的数据库名;，再执行建表脚本；如果用了 schema，确认 schema 已创建。
4.5 现象：字段允许空值导致后续查询出现 NULL 陷阱
原因：设计时没想清楚业务是否允许空值，默认全允许。解决：对业务上必须有的字段加NOT NULL，比如学号、课程号、姓名；对可能为空的字段，在查询时用IS NULL或COALESCE处理，避免= NULL这种无效条件。
5. 让模式设计经得起检查：反向验证与一个小技巧
模式设计做完，怎么证明它是对的？我一般会做两件事：反向生成 E-R 图和用测试数据跑一遍约束。Power Designer 支持从 PDM 反向生成 LDM 或概念模型，如果反向出来的图和最初画的差太多，说明中间转换有信息丢失。另一个办法是往每张表插几条测试数据，故意插违反主键、外键、非空约束的数据，看数据库是否按预期拒绝。
-- 测试主键冲突 INSERT INTO Student(Sno, Sname) VALUES ('202100001', '张三'); INSERT INTO Student(Sno, Sname) VALUES ('202100001', '李四'); -- 应报错 -- 测试外键约束 INSERT INTO SC(Sno, Cno, Grade) VALUES ('999999999', 'C001', 90); -- 应报错 -- 测试非空约束 INSERT INTO Course(Cno, Cname) VALUES ('C002', NULL); -- 应报错逻辑说明：这三条语句分别验证主键唯一性、外键引用完整性和非空约束。参数说明：如果你的数据库配置了级联删除或延迟约束，报错行为可能不同，以实验要求为准。跑完测试后记得回滚或删除测试数据，避免影响后续实验。
还有一个容易被忽略的技巧：在 Power Designer 的 PDM 里给每张表加 Comment，把业务含义写清楚。导出 SQL 时勾选“Generate comments”，这样 DB2 或 SQL Server 里表的注释就是完整的。以后别人接手你的库，不用翻实验报告也能看懂字段含义。我自己做课设时因为没写注释，过了一周再回头看SC表，愣了半天才想起Grade是成绩而不是等级。希望帮到你。
本文还有配套的精品资源，点击获取
