企业官网建设流程全解析

每次带学生做课程设计，只要是涉及管理系统的题目，十有八九都会遇到同一个画面：学生兴冲冲打开Navicat，噼里啪啦建了七八张表，填了一堆数据，然后开始写登录和CRUD。等到要查“某学生选了哪些课、成绩是多少”的时候，发现要么数据对不上，要么要写一个巨复杂的SQL硬凑，要么干脆在Service层用Java代码循环查库。问题出在哪？大概率是数据库设计这一步就没想清楚——它撑不起整个业务闭环。

所以这篇就专门聊一个很多人觉得“没什么好聊”的话题：学生信息管理系统的数据库设计。我会从最开始的业务梳理，到概念模型设计、逻辑结构设计，再到物理建表和后续与SSM框架的衔接，完整走一遍。文章的核心不是给你一套可以原样抄走的表结构，而是讲清楚每一步为什么这么做、有什么取舍、有哪些坑是你在设计阶段就该避开的。适合正在做课程设计或毕业设计的同学，也适合刚接触系统开发、想搞明白“表到底该怎么设计”的初级开发者。

1. 动手建表之前，先想清楚系统到底要管什么数据

很多人的第一个错误，是直接打开数据库工具开始建表。建表是物理设计阶段的事，在那之前还有需求分析、概念结构设计、逻辑结构设计三道工序。跳过这些直接建表，后面大概率要返工。

1.1 这个系统的核心业务范围

学生信息管理系统，光听名字会以为只需要管“学生信息”这一件事。但如果你去看课程设计任务书，或者稍微把使用场景往真实环境推一步，就会发现它至少要覆盖四块业务：

• 学生基本信息管理：学生的学号、姓名、性别、出生日期、民族、籍贯、政治面貌、入学年份、所属专业和班级等。这些信息解决的是“这个人是谁”的问题。
• 课程管理：课程编号、课程名称、学分、学时、授课教师、开课学期等。解决的是“学校开了哪些课”的问题。
• 成绩管理：哪个学生选了哪门课、考了多少分、是正常考试还是补考。这是整个系统里数据关系最复杂的一块，因为它把“学生”和“课程”两个原本独立的核心实体连接到一起。
• 用户账号与权限：谁可以登录系统、能干什么。学生只能看自己的成绩，教师能录入成绩，管理员能维护所有基础数据。

为什么要把这个边界划清楚？因为边界决定了表数量。最小可用的学生信息管理系统，至少需要5张表：学生表、课程表、成绩表、用户表，再加上承载“学生属于哪个班级、班级属于哪个专业”的班级表或专业表。如果把宿舍管理、缴费管理、图书借阅也塞进来，表数量会直接翻倍。

我的建议是：课程设计阶段，只做核心业务，扩展模块可以用“预留接口”的方式在文档里提，不要真把表建出来。数据库表一旦设计得过于庞大，关联查询的复杂度会指数级上升，最后占用大量时间在调试SQL上，反而挤占了写代码和写论文的时间。

1.2 从界面原型反推数据字段

需求分析阶段有一个很实用的技巧：先画出系统的页面原型，再反推每个页面上需要哪些字段。这个方法对新手特别友好，因为“页面需要展示什么”是具象的，而“表里需要什么字段”是抽象的。

举个例子，学生列表页面通常要展示学号、姓名、班级、性别、入学年份，那学生表里就要有这些字段。但是当你打开学生的详情页，发现要展示籍贯、民族、政治面貌、家庭住址，那这些字段也得在表里。如果你在需求阶段没想清楚，写代码写到一半发现页面缺字段，再回去改表，不仅麻烦，而且极容易引发数据一致性问题。

这里有一个反直觉的经验：页面上一时用不到的字段，如果从业务逻辑上判断未来大概率会出现，宁可设计阶段就加上，也不要等到后期再补。比如紧急联系人电话，课程设计里可能用不到，但这类字段属于学生管理的常规信息，加上也就多个字段的事，不用纠结。

当然，也不是字段越多越好。判断标准就一条：这个字段是否服务于明确的功能或业务规则？说不出用途的字段不要加，留着就是数据脏的根源。

2. 概念模型设计：实体识别与关系拆解

概念模型设计阶段不涉及具体的数据库产品，核心产出是ER图——找清楚有哪些实体、每个实体有哪些属性、实体之间是什么关系。很多教材把ER图讲得很抽象，我这里用一个具体例子把它说透。

2.1 核心实体与属性边界

学生信息管理系统里的核心实体，我按“主实体—辅助实体—关联实体”三个层次来梳理：

实体分类的意义在于明确主从关系。比如专业本身可以是一个独立实体，也可以只是学生表里的一个字段。什么时候需要独立建表？当专业有自己的属性（如专业代码、所属学院、培养方案）时，就应该独立建表。如果只是把一个名称塞给学生表，那确实不需要单独建表，但后续想扩展专业的描述信息就很被动了。

2.2 多对多关系的处理：学生-课程-成绩这个三角

学生和课程之间是典型的多对多关系：一个学生可以选多门课，一门课可以被多个学生选。在关系型数据库里，多对多不能直接用两个表的外键表达，必须引入第三张表——也就是关联表，把多对多拆成两个一对多。

成绩表就是这张关联表。它至少要包含三个核心字段：学生ID（或学号）、课程ID（或课程号）、成绩数值。这里要特别留意一个容易被忽视的问题：一张成绩表里，同一对“学生+课程”只能出现一次吗？正常考试如果不及格，后续还有补考。如果补考成绩也存同一张表，那同一对学生和课程就会有两行记录，这会让“查询最近一次成绩”变得很麻烦。

我见过两种主流处理方案：

• 方案一：成绩表里加一个“考试性质”字段（正常考试、补考、重修），查询时用“考试性质”筛选最近一次。
• 方案二：补考信息单独建一张补考表，和正式成绩分开管理。

课程设计阶段，我推荐方案一。虽然单独建补考表在语义上更清晰，但它会让查询逻辑复杂不少，而且大多数课程设计的打分标准不会要求到这种粒度。加一个exam_type字段，既保留了扩展空间，实现成本又极低。

2.3 ER图工具怎么用才有效率

PowerDesigner是传统教材里反复出现的设计工具，但其学习成本不低。以它的功能特性来说，绝大多数课程设计根本用不到那么完整的功能集，很多学生花了两三天把工具摸熟，结果画的图还不如手绘草图清晰。

如果你已经装了PowerDesigner，用它画ER图没问题。但我的建议是：概念模型阶段用纸笔或简单的绘图工具（draw.io、ProcessOn都可以），快速把实体和关系理清楚；进入逻辑设计和文档撰写阶段，再用PowerDesigner生成规范化的模型图。这样既避免工具学习成本占用太多时间，又能在论文里放一张规范的模型图。

另一个实用建议是：ER图画到“所有实体能一一对应将来的一张表”这个粒度就够了，不要再往下细化字段级设计。字段级设计属于逻辑结构设计的范畴，混在一起画只会让图变得难以阅读。

3. 逻辑结构设计：ER图转关系模式，字段定型的核心逻辑

概念模型设计完成后，下一步是把ER图转换成具体的表结构。这一阶段解决两个核心问题：关系模式怎么转换、字段的类型和约束怎么定。逻辑结构设计做得好不好，直接决定后面写SQL是顺畅还是痛苦。

3.1 关系模式转换的核心规则

ER图到关系模式的转换有标准规则，记住三条核心的就行：

• 每个实体转成一张表，实体的属性就是表的字段。
• 一对多关系，在“多”的一方加外键。比如一个班级有多个学生，就在学生表里加class_id外键字段。
• 多对多关系，额外建立一张关联表，关联表里放双方的主键，再加上关系本身的属性（比如成绩）。

按这三条规则，学生信息管理系统的核心表结构就基本成型了。表间的关联关系如下：

• 专业表（1）—（N）班级表：一个专业下有多个班级。
• 班级表（1）—（N）学生表：一个班级有多个学生。
• 学生表（1）—（N）成绩表：一个学生可以有多条成绩记录。
• 课程表（1）—（N）成绩表：一门课程可以对应多条成绩记录。
• 教师表（1）—（N）课程表：一个教师可以带多门课程（按实际情况也可改为多对多，课程设计阶段用一对多足够）。

3.2 核心表的字段选型与理由

先说一个很多初学者会犯的错误：学号和课程号一律用int，或者反过来一律用varchar，不加思考。这两种做法都有问题。

学号为什么不用int？原因有三点：

• 学号以0开头的情况很常见（比如某些学校学号是0开头的），int会丢失前导零。
• 学号是标识符，不是数字，不需要参与算术运算。
• 学号可能有字母（部分学校的学号含字母），varchar更通用。

课程号同理。课程号通常有固定编码规则（如“CS101”），用int无法表达这种结构。

但主键就不一样了。我建议每张表都用一个自增的id作为逻辑主键，同时在业务字段上建立唯一约束。这样做的理由很实际：成绩表里关联学生和课程时，用student_id和course_id两个整数做外键，比用一串字符型的学号效率更高，写SQL也更简洁。学号只是业务上的唯一标识，不代表它适合做物理主键。

下面是我建议的核心表字段方案，可以直接作为参考：

学生表（student）

这里简单解释几个选型细节：

• gender用TINYINT而不是CHAR(2)存“男/女”，是为了后续扩展（比如“未知”状态）和程序处理的便利。MySQL里TINYINT只占1字节，查询和对比都更高效。实际显示层的转换交给Java代码处理就行。
• enrollment_year用VARCHAR(4)而不是INT，原因是招生年份是编号性质的字符串，不需要参与加减。而且显示时不用再转换格式。
• 每个表加上created_at和updated_at，是老生常谈但真没几个人自觉加。一旦数据出现异常需要排查，这两个字段能帮你迅速定位问题。

课程表（course）

学分用DECIMAL(3,1)而不是FLOAT，是因为学分通常是0.5的整数倍，DECIMAL可以精确保存这种小数，而FLOAT存在二进制无法精确表示的问题，虽然这一点在分值上一般不会暴露，但养成精确保存的习惯对任何金额、分数类字段都有好处。

成绩表（score）

用户表（sys_user）

role和ref_id的组合是整个系统的权限模型基础。学生登录后，通过role=3和ref_id找到对应的学生记录，就能查询自己的成绩。这个设计比给每类用户单独建表要简单得多，而且足够应对课程设计的场景。

3.3 规范化程度怎么取舍

数据库设计理论要求范式，但实际工程里范式不是越高越好。学生信息管理系统里，绝大多数表满足第三范式（3NF）即可。

什么叫第三范式？简单说就是：非主键字段不传递依赖于主键。比如学生表里存了班级名称，而班级名称本来属于班级表，学生表里存它，就是传递依赖，不满足3NF。但当查询需要班级名称时，不存班级名称就得连表查询。这两种做法没有绝对的对错，而是取舍。

课程设计阶段，我的建议是严格遵守3NF。理由很直接：评分老师在查阅数据库设计部分时，看到明确的规范化分析会加分；而冗余字段带来的查询性能提升，在这个量级的数据下根本感知不到。等到以后做真实项目，数据量大了，再根据实际情况做适度的反规范化设计。

4. 物理设计与实施：建库建表SQL的完整落地

逻辑结构设计完成后，才轮到真正写SQL建库建表。这一阶段有几个细节特别容易被忽略：字符集选错导致中文乱码、外键策略不明确导致删除数据时报错、索引缺失导致查询慢。

4.1 字符集、排序规则与存储引擎

建库时，字符集一定要选utf8mb4，而不是utf8。很多人以为这两个没区别，实际上utf8在MySQL里最多只能存3字节的字符，像Emoji表情这类4字节字符会直接存不进去，报错或者变成乱码。虽然学生信息管理系统的数据一般不会有Emoji，但选型时养成用utf8mb4的习惯，以后做真实项目能少踩很多坑。

建库SQL：

CREATE DATABASE student_management DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;

排序规则选utf8mb4_general_ci就够了，它不区分大小写，适合姓名、课程名这类数据的比较和排序。utf8mb4_unicode_ci更精确但稍微慢一丁点，在这个场景下没有实际差别。

存储引擎选InnoDB，核心原因是它支持事务和外键约束。MyISAM在某些老项目里还有存量，但新项目应该一律InnoDB，这是标配。

4.2 完整建表SQL参考

下面是完整的建表SQL，我按业务依赖关系，从“被引用的基础表”开始建，避免外键引用到尚不存在的表。

-- 专业表 CREATE TABLE major ( id INT PRIMARY KEY AUTO_INCREMENT, major_no VARCHAR(20) NOT NULL UNIQUE COMMENT '专业编号', major_name VARCHAR(100) NOT NULL COMMENT '专业名称', college VARCHAR(100) DEFAULT NULL COMMENT '所属学院' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 班级表 CREATE TABLE class ( id INT PRIMARY KEY AUTO_INCREMENT, class_no VARCHAR(20) NOT NULL UNIQUE COMMENT '班级编号', class_name VARCHAR(100) NOT NULL COMMENT '班级名称', major_id INT NOT NULL, CONSTRAINT fk_class_major FOREIGN KEY (major_id) REFERENCES major(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 教师表 CREATE TABLE teacher ( id INT PRIMARY KEY AUTO_INCREMENT, teacher_no VARCHAR(20) NOT NULL UNIQUE COMMENT '工号', teacher_name VARCHAR(50) NOT NULL COMMENT '姓名', title VARCHAR(50) DEFAULT NULL COMMENT '职称' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 学生表 CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT DEFAULT 0 COMMENT '性别 0未知 1男 2女', birth_date DATE DEFAULT NULL COMMENT '出生日期', class_id INT NOT NULL, enrollment_year VARCHAR(4) NOT NULL COMMENT '入学年份', phone VARCHAR(20) DEFAULT NULL, address VARCHAR(255) DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_student_class FOREIGN KEY (class_id) REFERENCES class(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 课程表 CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE COMMENT '课程编号', course_name VARCHAR(100) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) NOT NULL COMMENT '学分', hours INT NOT NULL COMMENT '学时', teacher_id INT NOT NULL, semester VARCHAR(20) DEFAULT NULL COMMENT '开课学期', CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 成绩表 CREATE TABLE score ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, course_id INT NOT NULL, score DECIMAL(5,2) DEFAULT NULL COMMENT '成绩，NULL表示未录入', exam_type TINYINT DEFAULT 1 COMMENT '1正常考试 2补考 3重修', exam_time VARCHAR(20) DEFAULT NULL COMMENT '考试时间批次', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 用户表 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, role TINYINT NOT NULL COMMENT '1管理员 2教师 3学生', ref_id INT DEFAULT NULL COMMENT '关联student或teacher表的id' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.3 外键约束与级联策略

关于外键，业界有两种声音。一种认为外键应该在数据库层强制约束，保证数据一致性；另一种认为外键约束影响写入性能，应该在应用层控制。课程设计阶段，我强烈建议保留外键约束。

原因是：你在设计文档里写了“外键保证数据完整性”，然后数据库里却没有外键约束，评阅老师一查数据字典就会挑出问题。再者，课程设计的数据量根本谈不上性能瓶颈，外键带来的约束价值远大于其开销。等你以后做高并发的真实项目，再根据实际场景考虑是否去掉外键约束。

但外键的级联策略需要认真想，不能随手写ON DELETE CASCADE。以成绩表为例：

• 如果删除学生时级联删除成绩，逻辑上是通顺的——人都没了，成绩自然也没了。
• 但删除课程时级联删除成绩，就未必符合预期。课程可能只是暂时停开，历史成绩应该保留。

更稳妥的方案是：业务上需要保留历史数据的表，一律不用级联删除，改为限制删除或者在应用层做逻辑删除。具体到学生信息管理系统，删除学生这种操作，大概率应该只是把账号停用，而不是把历史和成绩一起删掉。

5. 数据准备与SSM框架衔接的实战细节

表建好只是第一步，后面还有两个环节经常卡住人：测试数据怎么造才合理、数据库设计和SSM框架怎么衔接才不踩坑。

5.1 测试数据怎么造才专业

很多学生随手插几条数据就开始测试，结果开发过程中经常触发一些没预料到的边界问题。测试数据的质量直接影响开发效率，造数据时有几个原则值得遵守：

第一，数据量要够。学生表至少插50~100条，成绩表至少几百条。数据量太少，分页查询、模糊搜索、索引是否生效这些问题根本测不出来。等交项目前才用真实数据测试，发现查询慢或者SQL写错了，彼时改动成本高得多。

第二，覆盖边界情况。比如成绩表里要有及格和不及格的记录；要有某个学生一门课都没选的记录，也要有某门课没有任何学生选的记录。这些边界数据能帮你尽早发现SQL里JOIN和LEFT JOIN的语义问题。

第三，成绩值的分布要接近真实。不要全是90多分，要有60分刚及格的、有59分不及格的、有缺考为NULL的。这样在测试统计功能时，结果才经得起推敲。

造大量测试数据时，手动一条条INSERT效率太低。可以用存储过程或写一段Java代码批量生成。下面是批量生成成绩数据的存储过程示例：

DELIMITER $$ CREATE PROCEDURE generate_score_data() BEGIN DECLARE i INT DEFAULT 1; DECLARE s_id INT DEFAULT 1; DECLARE c_id INT DEFAULT 1; DECLARE max_s INT DEFAULT 100; DECLARE max_c INT DEFAULT 10; WHILE i <= 300 DO SET s_id = FLOOR(RAND() * max_s) + 1; SET c_id = FLOOR(RAND() * max_c) + 1; INSERT INTO score (student_id, course_id, score, exam_type, exam_time) VALUES (s_id, c_id, ROUND(RAND() * 100, 2), 1, '2024-2025-1'); SET i = i + 1; END WHILE; END$$ DELIMITER ; CALL generate_score_data();

注意，这个存储过程没有处理“同一个学生同一门课重复生成”的情况，你需要在插入前补充判断。这正好引出一个重要观点：造数据的过程其实是检验表约束设计的好机会。如果你的成绩表没有对(student_id, course_id)做唯一性设计，重复数据插进去就只能靠应用层去规避。

5.2 数据库设计与SSM框架衔接的注意事项

SSM（Spring + Spring MVC + MyBatis）是目前课程设计里最常见的框架组合。数据库设计得再好，和框架衔接不顺畅，开发时一样会让人抓狂。以下几个点是最常出问题的：

字段命名风格。数据库字段名我建议统一用下划线风格，如student_no、birth_date。在MyBatis里配置mapUnderscoreToCamelCase=true，就能自动把student_no映射到Java实体类的studentNo属性。如果数据库字段和Java属性都混用不同风格，映射配置会写到你怀疑人生。

时间字段的类型匹配。MySQL的DATETIME字段，对应Java 8及以后推荐用LocalDateTime，而不是老旧的java.util.Date。MyBatis 3.4.4以上版本原生支持LocalDateTime，不需要额外处理。实体类里这么写即可：

private LocalDateTime createdAt;

外键字段和关联对象要分开。很多初学者会在实体类里把class_id字段写成一个Class对象，这本身没问题，但要注意区分“单纯存外键值”和“关联查询出对象”。比如学生实体类里，通常两个字段都保留：private Integer classId;和private ClassInfo classInfo;。前者用于插入和更新，后者用于列表展示时的连表查询。对应SQL里，查询语句需要LEFT JOIN class ON student.class_id = class.id。

5.3 唯一约束的应用场景

在逻辑设计阶段给student_no、course_no、username这些业务字段加上唯一约束，很多人不理解为什什么要加——明明应用层也可以通过查询判断重复。

数据库里的唯一约束是数据正确性的最后一道防线。应用层的判断有两个问题：一是并发场景下，两个请求同时判断“学号不存在”，然后同时插入，结果就出现了重复数据；二是应用层判断逻辑难免存在遗漏，而数据库的唯一约束是从物理层面杜绝重复。

课程设计阶段可能体会不到并发问题，但评分老师看设计文档时，看到“学号字段设置了唯一约束”，比看到“学号重复靠程序判断”要专业得多。这是极低成本的高价值设计。

6. 数据库设计阶段最容易踩的坑与个人经验

最后分享一些我在实际开发和指导学生过程中反复遇到的坑。这些坑有一个共同特点：都不是什么高深的技术问题，但它们确实会浪费大量时间。

6.1 常见错误复盘

第一个坑：把所有逻辑都写在应用层，数据库层形同虚设。比如成绩的录入、课程容量的限制、学生选课时间的校验，全部放在Java代码里，数据库只负责存数据。结果就是Java代码越来越庞大，SQL反而变成了简单的SELECT。正确的做法是：核心的业务约束数据能用数据库表达的就用数据库表达（主键、外键、唯一约束、非空约束），应用层只处理数据库表达不了的业务规则。

第二个坑：一味追求大而全，表设计超过实际需求。有个学生提交的课程设计，数据库里有20多张表，什么图书借阅、宿舍分配、社团活动全都有。这种设计乍一看很唬人，但实际上每张表的字段都空着大半，关联关系也理不清，代码写到最后自己都不知道某张表是干什么用的。数据库设计的第一准则永远是满足需求并适度超前，而不是越复杂越好。

第三个坑：不注意NULL值的使用。性别字段默认为NULL，出生日期也是NULL，成绩也是NULL。查询时忘了处理NULL，score < 60这种条件会把NULL的缺考记录一并排除。说实话，NULL的处理是SQL开发里最容易出错的地方之一。我的建议是：业务上必须有值的字段一定要NOT NULL加默认值；允许为空的字段，写SQL时养成用IS NULL显式判断的习惯，避免被隐含的类型转换和条件判断坑到。

第四个坑：表数据量大后忘了设计索引。学生信息管理系统数据量不大，但查询场景其实很明确：按学号查学生、按班级查学生、按学生查成绩、按课程查成绩。这些都是高频操作。除了主键索引，至少应该在这些外键字段上建索引。成绩表的student_id和course_id如果没索引，等成绩表数据量到几千条，关联查询的耗时就能明显感觉到差异。

CREATE INDEX idx_student_class ON student(class_id); CREATE INDEX idx_score_student ON score(student_id); CREATE INDEX idx_score_course ON score(course_id);

6.2 我一直推荐的工作习惯

在项目开发最初期就建好数据库设计文档，哪怕只是一份简单的Excel表格，把每张表的字段、类型、约束、用途记录清楚。我见过太多人把设计文档放在最后写，等于把“回忆当初为什么这么设计”的难度系数拉到最高。

还有一个非常实用的习惯：每次修改表结构，都顺手把修改时间和原因记在设计文档的备注里。等你写完代码回过来补文档时，这些备注就是你重构思路的还原线索。这个习惯对课程设计阶段的帮助不大，但对以后参与真实项目开发会产生深远影响。

学生信息管理系统虽然业务不算复杂，但它几乎涵盖了关系型数据库设计的全部核心知识点：实体关系建模、ER图设计、规范化与反规范化取舍、完整性约束、索引设计和框架衔接。把它吃透，很多管理类系统的设计思路你都能举一反三地套用。如果看完这篇文章正准备动手做类似项目，建议你先把业务边界和实体关系理清楚，再打开数据库工具——这一步想明白了，后面就顺了。