企业官网建设流程全解析

简介：这是北京邮电大学《数据库》课程实验四“数据库模式的设计”配套实验报告，面向高校数据库课程学生与需要完成模式设计实践的开发者。实验以在线考试系统为背景，针对用户管理、试题管理、试卷管理、考试管理等需求，定义了用户、试题库、知识点、试卷、考试管理五个实体及其属性，并通过E-R图、概念模型、物理模型和SQL脚本层层转换，最终在IBM DB2 v8.1中创建出对应表及考试信息、在线试卷两个视图。资源为1个docx文档，大小1.56MB，内含实验目的、需求说明、实体属性定义、完整SQL导出语句与建表建视图结果的查看方法，可帮助读者对照书中步骤检查自己的实验过程，理解数据库模式设计的完整链路。已有145人学习下载，适合用于实验报告参考、复习备考或自学数据库概念模型到物理模型的转换方法。

1. 数据库模式的设计：从E-R图到DB2五表两视图的完整链路

做数据库课程设计的人，最容易被卡住的往往不是需求分析，而是模式设计这一步：业务看懂了，却不知道实体该拆几个、外键放哪边、哪些字段要可空。这份实验文档来自北邮数据库实验四“数据库模式的设计”，以在线考试系统为背景，把用户管理、试题管理、试卷管理、考试管理四条线收拢成五个实体、两个视图，并用Power Designer从E-R图一路推到IBM DB2 v8.1的可执行SQL。适合两类人：一类是正在赶数据库实验但E-R图转物理模型总翻车的在校生，另一类是刚接触数据建模、想完整走一遍概念模型到物理模型链路的从业者。打开这份资源，你能得到一张可以直接对着抄的表结构、视图定义和排错清单。

2. 把需求翻译成五个实体：主键、外键与可空字段的取舍

2.1 为什么收拢成五个实体而不是七个

在线考试系统的需求文本里出现了不少名词：教师、学生、用户、试题、知识点、试卷、考试。新手第一眼会觉得每个名词都要建一张表，照这个思路数下去，会同时出现用户表、教师表、学生表，然后为“教师和学生都属于用户”重复维护一堆字段。实验文档在这里做了一个关键的收拢：教师和学生折叠进用户表，用Role字段区分，并明确“一个用户有且只有一种角色”。

这样收的好处不只是省一张表。考试管理表里只有UserID一个外键，查询时既可以通过Role='Teacher'反查出任教老师，也可以通过Role='Student'筛出学生成绩，不需要为每种角色各存一份外键。需求文本里提到的考试信息“考试标题、任教老师、考试时间”，最终落成的考试管理表只有考试名称、考试代码、考试时间、学生成绩、用户ID五列，任教老师没有冗余成字段，而是靠UserID关联用户表拿到。这个“关联得来就不重复存”的思路，正是模式设计里最基础的规范化意识。

真正决定实体数量的不是名词数量，而是关系。逐个看：用户和考试管理是一对多，一个学生能参加多场考试；知识点和试题库是一对多，一道题只考察一个知识点；试卷和试题库从需求描述“试卷由一定数量（即知识点的数量）的试题组成”来看，应该是一对多，一张卷子包含多道题。但实验把Paper表简化成PaperID、PaperName、ItemID外键三个字段，相当于用单列外键表达“一张试卷引用了一道题”，这在作业层面能交差，落到真实系统就会暴露问题——同一知识点的试题只能出现一次的约束，单靠这个结构根本控制不住。我一般在作业里先按原文建表，同时在文档里补一句“实际部署时应增加Paper_Item中间表”，既交出符合实验要求的结构，也让老师知道你看到了多对多的存在。

2.2 五张表的字段清单与外键方向

把五个实体列成一张对应表，建表时心里就踏实了。下面是从实验报告里整理出的最小字段集，主键、外键、可空状态都标了出来：

几个字段值得单独说明。Egrade在实验报告里明确写了“可空”，因为一场考试从安排到出成绩有时间差，考试记录先插入时成绩还没有，考完阅卷才回填；用可空字段表达“状态未知”，比用0或负数占位干净。Ioption在试题库里是单个字段而不是四个字段，说明备选答案是以文本块形式整体存放的，程序在展示时自己按分隔符拆开，这也是单选题系统里很常见的存法；拆成OptionA、OptionB、OptionC、OptionD四个字段也行，但选项数量一旦不固定，四列的方案就会浪费空间。

角色字段要避免一个常见误用：别用数字0、1去存角色，然后在查询时翻译成“教师/学生”。DB2 v8.1的CHECK约束很好用，直接把候选值写死在表里。用户表的建表语句我一般写成这样：

CREATE TABLE UserInfo ( UserID INTEGER NOT NULL, UserName VARCHAR(30) NOT NULL, Role VARCHAR(10) NOT NULL, Password VARCHAR(64) NOT NULL, PRIMARY KEY (UserID), CONSTRAINT CK_UserInfo_Role CHECK (Role IN ('Teacher', 'Student')) );

逻辑说明：Role字段上加了CHECK约束，写入Teacher、Student以外的值时数据库直接拒绝，这比应用层判断更早形成防线；UserName和Password的长度按实际场景留，密码字段给VARCHAR(64)，是为了兼容常见散列函数输出的定长字符串。

参数说明：VARCHAR(30)适合中文姓名和英文名混用的场景，如果用户名可能包含邮箱或手机号，改成VARCHAR(50)更稳；Password如果实验里只存明文，VARCHAR(20)就能跑，但真项目不建议这么干。

知识点表和试题库表的建表脚本可以直接抄，外键方向和字段类型都按DB2 v8.1的语法写：

CREATE TABLE KnowledgePoint ( PointID INTEGER NOT NULL, Pcontent VARCHAR(200) NOT NULL, Psubject VARCHAR(50), PRIMARY KEY (PointID) ); CREATE TABLE ItemBank ( ItemID INTEGER NOT NULL, Icontent VARCHAR(500) NOT NULL, Iscore DECIMAL(5, 2) NOT NULL, Ioption VARCHAR(200) NOT NULL, Ianswer VARCHAR(10) NOT NULL, PointID INTEGER NOT NULL, PRIMARY KEY (ItemID), FOREIGN KEY (PointID) REFERENCES KnowledgePoint (PointID) );

逻辑说明：试题库的外键指向知识点表，实现“一道试题只能考察一个知识点”。删父表时必须先处理子表数据，否则DB2会报外键约束错误。Iscore用DECIMAL(5,2)而不是直接用数字，是为了允许0.5分这种半题分值，且计算总分时不会出现浮点误差。

参数说明：Ioption若四个选项合计超过200字符，可以放宽到VARCHAR(400)；Ianswer存的是唯一正确答案的标识，建议存“A”“B”这种字母而不是整句原文，判卷时直接等值匹配，处理更省事。

试卷和考试管理两张表继续按同样风格建：

CREATE TABLE Paper ( PaperID INTEGER NOT NULL, PaperName VARCHAR(100) NOT NULL, ItemID INTEGER NOT NULL, PRIMARY KEY (PaperID), FOREIGN KEY (ItemID) REFERENCES ItemBank (ItemID) ); CREATE TABLE ExamManagement ( EID INTEGER NOT NULL, Ename VARCHAR(100) NOT NULL, Etime TIMESTAMP NOT NULL, Egrade DECIMAL(5, 2), UserID INTEGER NOT NULL, PRIMARY KEY (EID), FOREIGN KEY (UserID) REFERENCES UserInfo (UserID) );

逻辑说明：ExamManagement的Egrade定义为可空，学生没交卷前记录可以存在但没有成绩；UserID关联用户表，通过角色字段判断这一行是哪个学生的考试记录，而不是为教师、学生各建一张考试表。

参数说明：Etime用TIMESTAMP而不是DATE，考试要精确到几点几分，DB2 v8.1的TIMESTAMP默认精度能到秒；Ename给100字符对考试标题足够，即使带“2024秋季学期期中”这类长前缀也撑得住。

另外提醒一句：实验报告里的实体英文名有几处拼写错误，比如ExamMangement少了一个a，KonwledgePoint少了e。进Power Designer时，Code字段建议直接改成ExamManagement和KnowledgePoint，不要让错误拼写跟着进数据库，否则后面写视图和查系统目录都要反复校对。

3. Power Designer建模三步走：CDM、PDM与DB2方言生成

3.1 概念模型（CDM）：画实体时把Name和Code分开填

概念模型阶段的核心任务是把第2章的字段清单画成E-R图，Power Designer里这一层叫Conceptual Data Model。新建模型时选择Conceptual Data Model类型，工具栏上有Entity、Relationship、Association等图标。画实体的操作是：先点Entity图标，在画布上拖出一个方块，双击方块进入属性窗口，在Name里写中文名“用户”，在Code里写英文名UserInfo，然后打开Attributes页签逐行录入字段。

这里有一个特别容易被忽略的设计：Power Designer的Name和Code是两套标识。Name是给人看的中文描述，Code是最终生成SQL时落进数据库的表名和列名。如果只填了Name不填Code，生成脚本时会把中文直接写成列名，DB2 v8.1对中文标识符的兼容性非常差，要么报语法错误，要么建出一个完全没法写查询的表结构。我在这步的习惯是：Name写需求原词，Code写英文缩写，录入完字段后用Tools → Check Model做一次一致性检查，把所有Code缺失或重名的问题在转物理模型之前先清掉。

五个实体在CDM里连线时，关系方向直接决定PDM里的外键方向。用户到考试管理是一对多，一个用户多场考试，外键落在多端的ExamManagement上；知识点到试题库是一对多，一个知识点多道题，外键落在多端的ItemBank上；试题库到试卷在实验模型里也是一对多，Paper引用ItemBank的题目代码。双击Relationship连线可以设置强制性(Mandatory)和基数(Cardinality)，Paper的ItemID按实验文档默认NOT NULL就可以。

3.2 物理模型（PDM）转换：DBMS类型映射的边界

CDM画完，下一步是Tools → Generate Physical Data Model，这是整个实验里最有技术含量的一步。弹窗出现后，首先在DBMS下拉框里选数据库类型，实验环境是IBM DB2 v8.1，Power Designer的DBMS列表里对应项一般显示为IBM DB2 UDB 8.x；如果你的Power Designer版本较新，列表里没有8.x，就选最接近的IBM DB2 UDB版本，字段类型和约束关键字的差异在DB2家族里不大。

选定DBMS后，Power Designer会做一次类型映射，把概念模型里的数据类型映射成DB2 v8.1的具体类型。默认映射关系大致如下：

逻辑说明：分数落到DECIMAL(5,2)而不是FLOAT，是因为考试成绩要精确展示，浮点类型在求和、平均时会出0.30000000000000004这类观感很差的结果；DECIMAL是定点十进制，DB2在存储和运算上都按十进制处理，展示、统计都干净。

参数说明：DECIMAL(5,2)最大能表示999.99，对单题分值和考试成绩都足够；如果将来要把满分做成150或300分，记得把精度上限放大，只用DECIMAL(5,2)会直接超出表示范围。

PDM生成后，Power Designer会自动为每个一对多关系在“多”端补一个外键列。此时要特别检查Paper表：如果CDM里试题到试卷的关系方向画反，PDM里生成的就不是Paper.ItemID引用ItemBank.ItemID，而是ItemBank多出一个PaperID字段，后面的建表脚本全乱。我一般在转完PDM后先不看SQL，而是逐张表检查外键列出现的位置，确认外键都落在多端，再进生成脚本环节。

3.3 视图建模：在Power Designer里把两个视图画出来

实验第4步要求创建两个视图：考试信息视图Examinformation和在线试卷视图Realpaper。Power Designer里视图不是凭空写SQL，而是在PDM中新建View对象，定义查询来源，再由生成器把它转成CREATE VIEW语句。

考试信息视图在PDM里的做法是：点击工具栏View图标拖出视图框，双击进入属性窗口，在SQL Query页签里写查询语句，或用图形化的Columns页签勾选来源表字段。这个视图的目标是“向学生提供自己历年的考试时间、科目、成绩”，所以定义里要关联UserInfo和ExamManagement两张表，并用Role='Student'过滤。

在线试卷视图负责“提供在线考试试卷”，数据来源是Paper和ItemBank，让学生看到试卷名称、题目内容、选项和分值。这里有一个建模上的取舍：视图里是否包含正确答案Ianswer字段。从业务视角看，学生端显示的试卷不应该暴露答案；从实验报告给出的实体看，Ianswer属于试题库，视图如果不做列级过滤就会把答案带出去。我一般的做法是视图里只选PaperName、Icontent、Ioption、Iscore，不选Ianswer，并在视图说明里写明“答案仅供教师端查询”，这样既满足需求，也避开把答案暴露给学生的硬伤。

CDM到PDM的链路到这里就走通了，剩下的只是把PDM导出成SQL文件再执行。

4. SQL脚本生成与DB2落地：导出、改编码、按顺序执行

4.1 生成脚本：Power Designer里最容易乱掉的两个选项

PDM画完，执行Database → Generate Database，弹窗里会看到多级复选框树，最常用的是Table和View两个节点。这里有两个选项直接影响脚本能不能一次跑通：一是Drop类语句，生成器默认会在每个CREATE TABLE之前生成一条DROP TABLE，数据库里还没有这些表时，DROP会报错但不影响后续，只是执行日志里会红字一片；二是生成目标，选择生成单个.sql文件再手动执行，不要选直接连接数据库生成，实验环境里Power Designer和DB2 v8.1的连接驱动不一定兼容，中断一次很难排查。

这一步还容易漏掉编码配置。数据库脚本如果手动保存，Power Designer默认按本机语言环境输出编码，Windows中文环境导出的.sql经常是GBK；而DB2 v8.1在服务器上如果数据库代码页是UTF-8，执行GBK文件里带中文注释的内容会直接报语法错。解决办法是在生成对话框的Options里找到Database Script → Format，把Encoding选成UTF-8；如果版本里没有这个选项，就生成后用编辑器把.sql转成UTF-8无BOM再执行。

生成的脚本还有一个值得看的细节：表顺序。Power Designer通常按依赖关系排序，先建KnowledgePoint、UserInfo这类无外键依赖的表，再建ItemBank、Paper、ExamManagement这些带外键的表。但这个自动顺序不总是可靠，模型里一旦有循环引用，脚本就会变得不可执行。我的习惯是生成后打开.sql文件，用查找功能确认CREATE TABLE的出现顺序：所有被外键引用的父表必须出现在子表之前。

提示：执行任何生成脚本前，先全局搜索“DROP”确认一遍，避免误删生产库里已有的同名对象。

4.2 在DB2 v8.1上执行：用db2命令行建库建表

假设数据库已经存在，直接进命令行操作。Windows环境下打开DB2 Command Window，或者先执行db2cmd进入DB2命令行环境，然后按下面的顺序跑：

db2 connect to examdb user db2admin using yourpassword db2 -tvf create_schema.sql

逻辑说明：第一条connect是建立到examdb数据库的连接，指定用户和密码；第二条-tvf是DB2命令行里最常用的脚本执行参数，-t表示按分号分隔语句，-v表示把正在执行的SQL回显出来，-f表示从文件读取。加-v的好处是执行完能清楚看到哪条语句、在哪个位置报错。

参数说明：examdb换成你的实际数据库名；db2admin如果是当前Windows登录用户且配了实例认证，密码参数可以省略，直接db2 connect to examdb也能连上；create_schema.sql换成你从Power Designer里导出的文件名。

执行完后，用下面的命令检查表是否都建成功：

db2 list tables for schema db2admin

逻辑说明：list tables for schema只显示指定schema下的表，实验环境里默认schema通常是建库时的用户名，比如db2admin。如果导入的是别人导出的脚本，schema前缀不一样，执行前先用db2 get current schema确认当前模式名。

参数说明：输出的Type列，T表示表，V表示视图。想看更细的结构定义，用db2 describe table ItemBank，它会按列列出字段名、类型、长度和是否可空。实验报告里查看建好的表时只列了四张表，少了用户表，实体定义是五个，检查时记得把UserInfo也查一遍，别因为报告没写就漏建。

4.3 两个视图的落地脚本与验证

视图脚本可以从Power Designer的View节点生成，也可以自己写。我个人建议实验里手动写视图SQL，Power Designer生成的视图语句常带内部对象ID注释，观感乱，手动写更干净。考试信息视图和在线试卷视图的定义如下：

CREATE VIEW Examinformation AS SELECT u.UserName, e.Ename, e.Etime, e.Egrade FROM UserInfo u JOIN ExamManagement e ON u.UserID = e.UserID WHERE u.Role = 'Student'; CREATE VIEW Realpaper AS SELECT p.PaperName, i.Icontent, i.Ioption, i.Iscore FROM Paper p JOIN ItemBank i ON p.ItemID = i.ItemID;

逻辑说明：Examinformation关联用户表和考试管理表，只保留Student角色，学生登录后按这个视图查自己的历史记录，不会看到别的学生成绩；Realpaper关联试卷表和试题库表，把试卷名称、题目内容、选项、分数拼接成一份完整在线试卷。两处都没有列正确答案，视图层面的数据隔离就完成了。

参数说明：UserName、Ename这类字段名以你实际生成的PDM设置为准；如果Power Designer生成表时把列名统一成了大写，视图里的列名也要跟着大写，小写或驼峰拼写在DB2 v8.1里容易因为引号规则出现问题。

视图执行成功后，验证数据用下面两条查询：

db2 select * from Examinformation db2 select * from Realpaper

视图依赖的表还没有数据时，查询返回空集是正常的。可以先手工插入一条学生用户和一条考试记录，再重新查询视图，就能看到视图确实在工作。这些执行过程中的坑，集中放到下一章排掉。

5. 常见问题与排查：DB2 v8.1上五个高频翻车点

5.1 现象：执行Power Designer脚本报SQL0104N，语法错误定位在第一条CREATE TABLE附近

原因：多数是脚本编码不对，中文注释或中文列名在GBK和UTF-8之间互相污染，DB2把中文文本误读成非法字符；另一个常见原因是Power Designer生成时带了SET CURRENT SCHEMA语句，当前用户没有对应模式的建表权限，权限错误也常以语法错误的形式抛出来。

解决：先用编辑器把.sql统一转成UTF-8无BOM；打开文件开头，把Power Designer自动加的SET CURRENT SCHEMA和SET DROP相关语句直接删掉或注释掉，保留CREATE TABLE和CREATE VIEW即可。改完再执行前，可以在DB2命令行里用db2 ? sql0104n查看该错误码的官方说明。若仍然报错，执行db2 truncate db2diag.log清空诊断日志，再跑一次脚本，打开db2diag.log定位真正出错的语句，用文本编辑器批量修正后再执行。

5.2 现象：建表时提示外键引用的表不存在，或引用列不存在

原因：脚本里表的创建顺序和依赖顺序不一致。例如Paper排在ItemBank前面，DB2在建Paper时发现被引用的ItemBank还没建出来，就会返回SQL0530N；另一种情况是CDM里外键字段的Code写错，生成的PDM里外键列名和父表主键列名对不上。

解决：把.sql里所有CREATE TABLE按依赖顺序重新排：先UserInfo、KnowledgePoint，再ItemBank，再Paper、ExamManagement。同时逐行检查外键定义，确认REFERENCES后面的表名和字段名与父表完全一致，大小写也要一致。在DB2里可以用db2 describe table ItemBank确认主键列的真实名字，再去比对子表外键列。

5.3 现象：五张表都建成功了，创建视图却报“名称在系统目录中不存在”，指向视图里的某个列名

原因：PDM里外键列被Power Designer默认改名，例如Paper表的外键列不叫ItemID，而叫ItemBank_ItemID；视图定义还按手写的ItemID引用，两边对不上。这种情况常见于CDM里关系线连了两次、外键列被重复生成后自动加后缀。

解决：先执行db2 describe table Paper查看真实列名，再回头改视图SQL里的列名；或者回到PDM双击外键列重命名，重新生成脚本。关键是让视图引用的列名和PDM里Code列的最终值一致，而不是以实验文档里的字段名称为准。

5.4 现象：视图创建成功，但select出来是空，临时查两个原表都有数据

原因：视图里的过滤条件把数据全挡了。最常见的是Role列的实际值大小写不一致，建表时CHECK约束里写的是Student，导入数据时插了student或中文“学生”，视图用Role='Student'做严格等值匹配，自然查不出任何行。

解决：先执行SELECT DISTINCT Role FROM UserInfo看存量数据值；再用UPDATE把存量数据改成统一值，例如UPDATE UserInfo SET Role='Student' WHERE Role='student'，或者视图条件写成UPPER(u.Role)='STUDENT'并同步更新CHECK约束，从源头消除口径分歧。

5.5 现象：执行脚本时日志里红字一大片，定位发现全是DROP语句报错，CREATE其实都成功了

原因：Power Designer默认生成DROP TABLE与CREATE TABLE的配对结构，表还不存在时DROP必然失败；如果连接schema不对，DROP还可能误删其他模式里的同名表，属于双重隐患。

解决：在Database → Generate Database的Options里，把Table节点下的Drop Table选项取消勾选；对已经生成的文件，全局搜索“DROP”并删除对应行。这个选项在导出时顺手就能改，比事后在日志里挨个挑错误快得多。

6. 建完表之后：视图验证与测试数据填充的实用技巧

表结构和视图都落库后，不要急着写实验报告。先把数据填进去，让视图能查出东西，再截图，报告才完整。填充数据有固定顺序：先插无外键依赖的父表，再插子表。以这个实验为例，顺序是UserInfo、KnowledgePoint、ItemBank、Paper、ExamManagement。

INSERT INTO UserInfo (UserID, UserName, Role, Password) VALUES (1, 'zhangsan', 'Student', '123456'); INSERT INTO UserInfo (UserID, UserName, Role, Password) VALUES (2, 'lisi', 'Teacher', '123456'); INSERT INTO KnowledgePoint (PointID, Pcontent, Psubject) VALUES (1, 'SQL基础', '数据库'); INSERT INTO KnowledgePoint (PointID, Pcontent, Psubject) VALUES (2, 'E-R模型', '数据库'); INSERT INTO ItemBank (ItemID, Icontent, Iscore, Ioption, Ianswer, PointID) VALUES (1, 'E-R图的中文全称是？', 1, 'A.实体关系图 B.扩展关系图 C.外部关系图 D.实体属性图', 'A', 2); INSERT INTO Paper (PaperID, PaperName, ItemID) VALUES (1, '期中考试卷A', 1); INSERT INTO ExamManagement (EID, Ename, Etime, Egrade, UserID) VALUES (1, '2024期中', '2024-11-20 14:00:00', 87.5, 1);

逻辑说明：插入顺序严格按外键依赖来，UserInfo和KnowledgePoint不依赖别人，先插；ItemBank依赖知识点，Paper依赖ItemBank，ExamManagement依赖UserInfo，依次跟上。这样任何一步都不会触犯外键约束。

参数说明：最后一条考试记录里Egrade填87.5，对应学生用户ID=1的成绩；如果想模拟“考试还没出分”的状态，Egrade可以直接省略不写，让字段保持默认为空。

数据填完，再查两个视图：

SELECT * FROM Examinformation; SELECT * FROM Realpaper;

Examinformation应该返回一行zhangsan的历史考试记录，Realpaper返回期中考试卷A的题目明细。这一步同时验证了前面做的视图过滤是否生效：只看到Student自己的记录，正确答案列没有出现在视图里。

额外的进阶验证是查DB2系统目录，把表之间的关系数出来：

SELECT TABNAME, TYPE FROM SYSCAT.TABLES WHERE TABSCHEMA = CURRENT SCHEMA; SELECT TABNAME, CONSTNAME, REFTABNAME FROM SYSCAT.REFERENCES WHERE TABSCHEMA = CURRENT SCHEMA;

第一条列出当前schema下所有表和视图，确认五表两视图齐全；第二条列出所有外键约束及其引用的父表，一眼看出Paper和ExamManagement的外键有没有落对位置。DB2 v8.1的SYSCAT视图是排查建模问题的高效工具，比在Power Designer里反复看模型图更快。

如果想让报告多体现一步专业度，可以给关键字段补注释：

COMMENT ON TABLE UserInfo IS '系统用户，含教师和学生两种角色'; COMMENT ON COLUMN ExamManagement.Egrade IS '考试成绩，考试未结束时为空';

COMMENT ON在DB2 v8.1里直接支持，Power Designer生成的脚本不会带这些注释，手工补上后，表结构在图形化管理工具里的可读性会高很多。到这步，概念模型、物理模型、SQL脚本、表、视图、数据验证全链路都通了。真正决定报告质量的，是模型到物理层的转换细节，而不是最后粘贴的那几张截图。从那以后，我每次做数据库模式设计都强制走一遍同样流程：先在纸面定实体和外键方向，再进建模工具画CDM，转PDM时逐表确认外键落点，导出SQL后手工检查DROP和依赖顺序，最后才连库执行。这套清单帮我挡住了绝大多数可以在生成阶段就避免的错误，这份完整样例也值得存一份当建模模板，下次接到类似系统时照着走一遍，能少熬两个晚上。希望帮到你。

本文还有配套的精品资源，点击获取