企业官网建设流程全解析

简介：面向高校数据库课程学习者与需要完成模式设计实验的学生，这份资源是北邮《数据库模式的设计》实验四的完整报告文档。内容围绕在线考试系统展开，从需求分析、实体属性确定到E-R图构建，再经Power Designer完成概念模型、逻辑模型与物理模型转换，最终生成并执行SQL脚本，在IBM DB2中创建表与视图。报告不仅梳理了用户、试题库、知识点、试卷、考试管理五个实体的字段设计及外键关系，还包含两个视图（考试信息、在线试卷）的建立思路与验证结果，可供参考E-R图绘制、Power Designer操作流程和DB2建表脚本写法。资源为单个doc文档，压缩包总大小约1.56MB，便于直接下载阅读。目前已有126人学习，适合正在做数据库设计实验、想对照完整实验报告梳理模式转换流程的读者。

1. 数据库模式设计实验：动手前先搞清楚它到底要你交什么

很多上过数据库课的人都有同感：前面的实验建库、写 SQL，跑得挺顺，一到“数据库模式设计”这种要交 Word 文档的实验就卡住了。前面实验是照着题目写代码，这道题是让你在没有现成表结构的情况下，把一段业务需求翻译成一组表设计。北邮这个实验四把重心放在模式设计上，最终交付物是一份 .doc 格式的设计文档——E-R 图、关系模式、函数依赖分析、范式说明，外加建表 SQL。它的核心训练不是“把表建出来”，而是让你用数据库设计的规范方法走完“需求分析 → E-R 建模 → 关系模式转换 → 规范化”这条完整路径。这篇笔记就是围绕这条路径写的：从怎么画 E-R 图、怎么转关系模式，到怎么用函数依赖判断范式，再到交付文档前怎么自检避坑。

2. 模式设计第一步：把需求拆成实体与联系，ER 图这么画不返工

2.1 实体识别的边界：从业务名词和动词入手

做模式设计，第一件事不是打开建表工具，而是读懂需求文本。这类实验题的需求通常几百字，比如“学生通过学号登录系统，查询课程信息、选课、退课；教师负责开设课程并录入成绩；教务管理员维护学生信息和课程信息”。你要做的第一步，是把这段文字里的“名词”和“动词”分别圈出来。

名词候选实体有：学生、课程、教师、教务管理员。动词候选联系有：选课、退课、开课、录入成绩、维护信息。但这里有一个容易翻车的点：不是所有名词都是实体。“教务管理员”在大多数选课系统实验里只是“学生”和“教师”之外的第三类账号，如果需求没有给管理员单独的属性（如工号、权限级别），它就不必单独建表，做成一个角色字段即可。判断标准其实就三条：

第一，这个名词有没有独立的主键。学生有学号，课程有课程号，教师有工号，这是实体；管理员的“角色”字段没有自己的唯一标识，它不是实体。第二，它是否携带一组独立属性。实体必须能被观察到多个描述属性，如果它只是另一个实体的附属信息，就是属性。第三，它是否在业务里被独立引用。比如“学院”这个名词，需求里如果只写“学生属于某学院”，那学院就是学生的一个属性；如果需求写了“学院下设多个专业，专业归学院管理”，那学院就变成实体了。

这里我一般会用一张草稿纸先列实体清单，每个实体后面写出候选属性，再反查需求原文确认每个属性是否在需求里有依据。这个过程看着繁琐，但能省掉后期返工。很多同学图快，直接打开 draw.io 画图，画到一半发现“班级”到底是个实体还是属性拿不准，整张图推倒重来。

关于实体粒度还有一个实用建议：属性字段能合并的不要轻易拆成实体，尤其是“联系方式”“地址详情”这类描述性信息。实验评分看的是你的设计是否满足需求覆盖度，不是看表数量。一个只有两三个字段的“实体”只会让关系模式变得碎片化，评审时还会被追问“为什么要单独建表”。

2.2 联系与基数比：1:1、1:N、M:N 决定外键放哪张表

实体确定之后，第二步是标实体之间的联系，并且给每个联系标基数比。基数比是模式设计里最影响后续建表的决策，它直接决定外键放在哪张表、需不需要建第三张中间表。

三种基数比的处理口诀大概是这样的：1:1 联系，外键放哪边都行，通常放在查询频率低的那一侧，或者任选一侧；1:N 联系，外键必须放在 N 侧（即“多”的那张表），比如“班级 1:N 学生”，学生表里放“班级编号”作为外键；M:N 联系，必须建中间表，比如“学生 M:N 课程”，中间表至少包含两个外键，形成复合主键。

实际做实验时，最容易混淆的是 1:N 和 M:N。我见过一个典型错误：需求写“一个教师可以教授多门课程，一门课程也可以由多个教师教授”，设计者却把“教师”直接做成“课程”表里的一个外键字段。这在语义上就漏掉了“多个教师教授同一门课”的约束，属于典型的基数比判断失误。

更隐蔽的情况是联系带属性的 M:N。比如选课这个联系，除了关联学生和课程之外，还带一个“成绩”属性。这个属性放哪儿？放学生表不对，一个学生有多门课；放课程表也不对，一门课有多个学生。它必须放在中间表（选课表）里，这是实验评分时经常被扣分的地方。

我在做这类设计时，会把每个联系单独写一行，格式是：“学生 —（选课，M:N，属性：成绩、学期）— 课程”。这样在画 E-R 图时就不用再去需求原文里翻，转关系模式的时候也能对着这个清单逐条转换。

2.3 画 E-R 图的工具选择：手绘、draw.io 还是 MySQL Workbench

实验交付的是 .doc 文档，E-R 图是其中的核心插图。选工具的标准不是“哪个功能强大”，而是“哪个能让你在截止时间前高效改图并导出高清图”。

手绘然后拍照或扫描是最不建议的，字迹一乱、线条一歪，评审体验很差。如果你有画图基础，draw.io（可导出矢量图）就够了：矩形表示实体，椭圆表示属性，菱形表示联系，连线两端标注基数。draw.io 是免费工具，网页版直接用，导出 PNG 到 Word 里清晰度足够。它的另一个好处是支持图层，你可以把“实体-属性”和“实体-联系”分成两层画，改起来不动整体布局。

如果你更倾向“画图顺便把建表脚本也生成了”，用 MySQL Workbench 的 EER 建模模块。它允许你在图形界面里拖拽表、定义字段、设置主外键，最后通过 Forward Engineer 直接生成创建表的 SQL 脚本。这个做法对新手比较友好，因为模式设计和建表脚本天然一致，不会再出现文档和 SQL 对不上的问题。

PowerDesigner 是教材里常提的工具，大学实验室也可能预装。但它的界面和授权对个人来说并不友好，我不太建议在课程实验阶段花时间折腾它。如果你的实验环境里只有 PowerDesigner 可用，那也没问题，它的 CDM（概念数据模型）转 PDM（物理数据模型）功能正好能对应“E-R 图转关系模式”这一步，能帮你省不少人工转换的时间。

3. 从 ER 图到关系模式：转换规则、复合主键与建表脚本落库

3.1 实体转表、属性转字段：主键与外键的映射关系

E-R 图画完，接下来的工作是把概念模型转成关系模式。这一步在实验文档里通常要求写成“关系模式列表”，格式类似：学生（学号，姓名，专业，入学年份）。转的时候有三条固定规则：实体变成表，实体的属性变成表的字段，实体的主键变成表的主键。

属性转字段时要注意几个细节。复合属性要拆成独立字段，比如“家庭住址”如果需求含有省份、城市、详细地址，就拆成三个字段，或者只保留一个“地址”字段，取决于需求里是否要按省份统计。多值属性不要试图塞进一个字段，比如“联系电话”如果一个人真有多个号码，正确做法是单独建一张联系表，而不是在一个字段里用逗号分隔——后者直接破坏 1NF。

联系的转换规则要单独说。1:1 联系，可以在任意一张表加外键指向另一张表的主键。1:N 联系，外键放在“多”的那一侧，也就是 N 侧。举一个具体例子：班级 1:N 学生，学生表里有“班级编号”字段；反过来，如果你在班级表里建一个“学号”字段去指学生，那这个设计基本就废了，因为一个班级能装下几百个学生，班级表里不可能放一排学号。

M:N 联系的转换是这个实验的核心考点：必须新建一张中间表。中间表至少包含两个外键，分别指向两个实体的主键。要不要用两个外键作为复合主键？这是实验设计里的一个分岔路。我的建议是：如果联系本身没有除了外键之外的属性，用复合主键；如果联系带属性（比如选课带成绩、订单明细带数量），那主键的选择要结合业务约束。

这里还牵扯到一个实验交付的技巧：关系模式列表不要只写字段名，一定要把主键用下划线标出，外键用波浪线或括号注明，范式级别写在每张表后面。这个排版习惯看起来小，但评阅老师一眼就能看出你的设计思路是否清晰。

3.2 M:N 联系转中间表：选课表到底该建哪几个字段

拿“学生选课”这个最经典的场景展开。假设需求是：学生有学号、姓名、专业；课程有课程号、课程名、学分；学生选课后产生成绩；一个学生一个学期不能重复选同一门课。

这三句话对应的关系模式是：

学生（学号，姓名，专业） 课程（课程号，课程名，学分） 选课（学号，课程号，学期，成绩）

为什么选课表是四字段而不是两字段？因为“学期”和“成绩”是选课这个联系的属性，不是学生或课程的属性。选课表的主键选什么，直接取决于业务约束。题目里写了“一个学生一个学期不能重复选同一门课”，那意思是：同一个学号 + 同一课程号 + 同一学期只能出现一条记录。此时主键应该设成（学号，课程号，学期），而不是（学号，课程号）。

如果题目没有“学期”概念，只是说“一个学生不能重复选同一门课”，那主键用（学号，课程号）就够了。因此，你在实验文档里写关系模式时，必须明确写出你假设的业务规则。这不只是完成作业，更是数据库设计的底层思维：表结构设计是从业务约束反推出来的。

选课表的成绩字段用 DECIMAL(5,2) 还是 INT？如果成绩有 0.5 分制的课程，DECIMAL(5,2) 更稳；如果实验明确百分制整数，INT 也可以。我一般会用 DECIMAL(5,2)，因为它能兼容 0 到 999.99 的范围，不至于因为数据格式问题返工。

3.3 用 SQL DDL 落地：一份可复现的 MySQL 建库脚本

关系模式定稿之后，把它落成建表 SQL。下面是选课系统三张表的 MySQL 建表脚本：

-- 学生表：主键学号，定长字符类型 CREATE TABLE student ( sid CHAR(10) NOT NULL COMMENT '学号', sname VARCHAR(30) NOT NULL COMMENT '姓名', major VARCHAR(50) DEFAULT NULL COMMENT '专业', enroll_year YEAR DEFAULT NULL COMMENT '入学年份', PRIMARY KEY (sid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 课程表：主键课程号 CREATE TABLE course ( cid CHAR(8) NOT NULL COMMENT '课程编号', cname VARCHAR(60) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) DEFAULT NULL COMMENT '学分，如 3.5', PRIMARY KEY (cid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 选课表：复合主键 + 外键约束 CREATE TABLE enroll ( sid CHAR(10) NOT NULL COMMENT '学号', cid CHAR(8) NOT NULL COMMENT '课程编号', semester VARCHAR(20) NOT NULL COMMENT '开课学期，如 2024-2025-1', grade DECIMAL(5,2) DEFAULT NULL COMMENT '成绩，百分制', PRIMARY KEY (sid, cid, semester), CONSTRAINT fk_enroll_student FOREIGN KEY (sid) REFERENCES student (sid), CONSTRAINT fk_enroll_course FOREIGN KEY (cid) REFERENCES course (cid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个关键参数说明：学号用 CHAR(10) 而不是 VARCHAR(10)，是因为学号是定长编码，定长字符类型在等值查询时效率更高，语义上也更严格。成绩用 DECIMAL(5,2) 是为了容纳“98.5”这类小数成绩，整数成绩存进去也不受影响。外键约束显式命名（fk_enroll_student），这样后期做删约束、查约束时能直接通过约束名操作，不用去翻系统表。

外键字段的类型和长度必须与引用主键完全一致，包括字符集。上面脚本里 enroll.sid 是 CHAR(10)，student.sid 也是 CHAR(10)，两表默认字符集都是 utf8mb4，这样才能确保外键约束能正常创建。实际中我看到太多建表失败是因为主表和从表的字段一个用 VARCHAR(20)、一个用 CHAR(10)，MySQL 报错都没提示，只会在建外键时静默失败。

这段脚本写进实验文档时，我建议在每张表的 COMMENT 里写清业务含义，在关键字段的 COMMENT 里写清取值约束（比如“百分制”）。评阅老师拿到文档不看正文，只看 SQL 也能还原你的设计意图，这就是一份好的 DDL 脚本该有的品质。

4. 规范化实战：函数依赖分析到 3NF 拆表，参数与取舍一次讲清

4.1 函数依赖分析：找出主键和候选键，把隐藏依赖列全

规范化的理论起点是函数依赖。在关系模式里，函数依赖描述的是“通过 X 能唯一确定 Y”的约束关系，记作 X → Y。比如“学号 → 姓名”成立，因为只要给出学号，姓名只有一个取值；反过来“姓名 → 学号”通常不成立，因为可能有重名。

做实验时，我会先用一张表把所有已知依赖写出来。拿选课系统举例，把所有属性列出来：学号、姓名、专业、课程号、课程名、学分、学期、成绩。然后逐一判断依赖关系：

学号 → 姓名，学号 → 专业 课程号 → 课程名，课程号 → 学分 （学号，课程号，学期）→ 成绩

最后一行依赖要重点说明：为什么成绩的单属性决定是复合属性？因为单看学号无法确定成绩——一个学生选多门课；单看课程号也无法确定成绩——一门课有多个学生；只有把学生、课程、学期三者绑在一起，才能唯一定位一条选课记录。

候选键的分析也在这个环节做。候选键是能唯一标识一条记录的最小属性集合。上面这个场景里，（学号，课程号，学期）是唯一的候选键，也就是主键。判断候选键的方法很朴素：从全属性集合开始，逐个尝试删掉属性，检查剩下的集合是否还能唯一确定其他所有属性；如果不能，就在主键里保留这个属性。

这个分析过程必须在实验文档里体现，不只是给结论。因为评阅老师要看的不是“我知道这表该这么建”，而是“我按什么依据判断出这么建”。函数依赖清单写全了，后面范式分析才有说服力。

4.2 从 1NF 到 3NF：一个选课信息表拆成三张的完整过程

理论上讲，规范化的目标是消除数据冗余和更新异常。实验里最常考的是判定一张表属于第几范式，以及把一张设计不合理的表逐步拆到 3NF。

我用一个“选课信息表”作为反例来演示完整拆表过程。假设原始表设计成一个宽表：

选课信息表（学号，姓名，专业，课程号，课程名，学分，学期，成绩）

先判断它是否满足 1NF。1NF 要求所有字段不可再分，即每个字段只存一个值。这张表的字段都是原子的，所以它满足 1NF。但它的主键是（学号，课程号，学期），存在两个明显的依赖问题。

第一是部分函数依赖：学号 → 姓名、学号 → 专业。学号只是主键的一部分，但姓名字段依赖学号，不依赖课程号和学期。这在 2NF 定义里属于“非主属性对候选键的部分函数依赖”，因此这张表不满足 2NF。第二是传递函数依赖：课程号 → 课程名、课程号 → 学分。课程名通过课程号传递依赖于主键，这会在 3NF 检查时被卡住。

现在开始拆表。第一步消除部分依赖：把依赖学号的字段（姓名、专业）拆到学生表，把依赖课程号的字段（课程名、学分）拆到课程表。第二步把中间关联部分（学号，课程号，学期，成绩）单独作为选课表。拆完得到三张表：

学生（学号，姓名，专业） 课程（课程号，课程名，学分） 选课（学号，课程号，学期，成绩）

拆完后检查这三张表的依赖：学生表里学号是主键，姓名、专业都完全依赖学号，满足 2NF 和 3NF；课程表同理；选课表里学号、课程号、学期构成复合主键，成绩依赖整个主键，不存在部分依赖，也不存在传递依赖，所以也满足 3NF。

这个拆表过程是实验文档必写的内容。写的时候我习惯用“拆分前后对比”的格式：一张表列出拆分前的字段和存在的问题，一张表列出拆分后的关系模式和各自的范式级别。这样评阅老师能直接看到你的分析链条。

4.3 范式与性能的权衡：什么时候停在 2NF 反而合理

需要特别提醒的是：范式不是越高越好，3NF 也不是所有表设计的终点。实验文档里花大篇幅写“我拆到了 3NF”是稳妥的做法，但更有区分度的做法是同时写出“哪些地方我故意保留冗余，为什么”。

举一个实际的例子。需求里有“查询学生及其专业名称”的高频场景。如果严格 3NF，专业应该单独建表，学生表里存专业编号，查询时要 JOIN 专业表。但如果专业名称极少变动，查询又极其频繁，把“专业名称”冗余到学生表里就是一种反规范化设计。此时学生表里同时存在“专业编号”和“专业名称”，字段之间形成“专业编号 → 专业名称”的传递依赖，表停在 2NF 而非 3NF——但这是有意识的选择。

在实验文档里写这类权衡要给出理由：什么查询场景驱动了这个设计、冗余带来的更新成本有多大（专业改名时需要 UPDATE 多少行）、是否可接受。这样写不仅不会被扣分，反而是加分项，因为它说明你理解规范化的本质是消除异常，不是机械套规则。

我的习惯是：先把所有表都设计到 3NF，然后在高频查询路径上分析是否要反向做冗余。如果决策是冗余，在文档里用一段“设计权衡说明”写明理由。这个习惯在一线项目里也完全适用——过度规范化的案例比比皆是，一张报表查询 JOIN 十张表的性能灾难，源头往往就是设计阶段不敢留冗余。

5. 数据库模式设计避坑指南：5 个高频翻车现场

5.1 现象：外键字段类型不一致，关联查询静默失败

做模式设计实验时，学生表和选课表都建好后，执行“SELECT * FROM enroll JOIN student ON enroll.sid = student.sid”，结果一条记录都没返回。两张表单独 SELECT 都有数据，JON 却查不到东西。

原因是创建表的时候没有保持外键字段类型的一致。比如学生表的 sid 用 CHAR(10)，选课表的 sid 却用 VARCHAR(12) 甚至 INT；两个字段在存储层面就不相等，MySQL 在做等值连接时虽然不会报错，但匹配结果可能因为字符集或隐式转换问题变成空集。

解决方法是建表前就把外键字段的设计规则定死：外键类型、长度、字符集必须与引用主键完全一致。建完表用“SHOW CREATE TABLE 表名”检查两边的字段定义是否逐字相同。我还会额外执行一条“SELECT COUNT(*) FROM enroll e LEFT JOIN student s ON e.sid = s.sid WHERE s.sid IS NULL”来验证，如果有未匹配行，说明数据本身就有问题。

5.2 现象：M:N 联系没建中间表，数据冗余直接爆炸

学生和课程之间是典型的 M:N 联系，但初版设计只给了两张表：学生表和课程表。学生在选课场景下有多条选课记录，设计者想“简单处理”，直接把学生选修的课程拼接成一个字段存进学生表，比如“课程1，课程2，课程3”。

结果是这张表连 1NF 都不满足，查询“选了课程2的所有学生”时只能靠 LIKE 匹配，又慢又容易错；更新时如果学生退选一门课，要整行 UPDATE 一个大字段；插入时还要先查询拼接字符串。这些反常现象的本质是：没有为 M:N 联系建立独立的中间表。

解决方法是把选课关系拆成第三张表（选课表），至少包含学号、课程号两个外键，再根据业务约束决定是否加入“学期”等字段。这个表中每条记录代表一个学生选一门课，主键用复合键或自增 ID 都可以，但业务唯一性约束必须落在数据上。实验里我一般用（学号，课程号，学期）复合主键，能顺便挡住重复选课。

5.3 现象：设计文档和建库脚本对不上，验收时当场翻车

这类实验的交付物是 Word 文档，很多同学的流程是先在文档里写好关系模式，再凭记忆去写 SQL 脚本，结果文档写“学号 CHAR(10)”，脚本里却写成“VARCHAR(20)”；文档里写了三张表，脚本里只建了两张。

原因是文档和脚本是两条生产路径，没有同步机制。解决方法是把“最终真源”定为 SQL 脚本。先用工具（比如 MySQL Workbench）把表建好并调试通过，再用“SHOW CREATE TABLE”导出标准 DDL，最后把这段 DDL 粘贴进 Word 文档的对应章节。如果设计修改了，先改表再重新导出脚本，文档始终以脚本为准。

还需要检查一个细节：Word 里画的 E-R 图和脚本里的表数量、字段名是否一致。我自检时会做一个清单，E-R 图实体数、关系模式表数、SQL 建表语句数三个数字必须完全相同，任何一个数字对不上就说明某一步漏了。

5.4 现象：字段命名无规则，一个月后自己都看不懂

学生表里有个字段叫“data”，评审时被问“这个字段存的是什么”，回答不出来。这类字段名包括：info、val、flag、temp、a、b1，单独看完全无法推断业务含义。

原因是命名时没有约定规范。解决方法是立一条命名规则并写进文档开头：全小写加下划线，字段名必须表达业务含义。例如：student_id 而不是 sid（除非全校统一用 sid），enroll_date 而不是 date，course_name 而不是 cname（如果需求里有全称和简称之分，用全称更稳妥）。

在建表 SQL 里给每个字段写 COMMENT 也属于这个习惯。COMMENT 不只是给人看的，后续做数据字典导出、给下游系统同步元数据时，COMMENT 就是字段语义的唯一来源。实验阶段养成这个习惯，比临时补注释效果好得多。

5.5 现象：为了 3NF 拆表上瘾，简单查询也要 JOIN 七张表

学生表拆成“基本信息表”“扩展信息表”“联系方式表”，课程表拆出“课程基本信息”“课程负责人”“开课学期表”，一张查询只要带学生姓名和课程名，就得 JOIN 五张以上表。如果实验数据和查询量都很小，性能问题不明显，但这种设计在评审时会显得缺乏控制力——拆表是为了消除异常，不是为了炫技。

原因是把规范化当成了目标而不是手段。解决方法是每拆一步都问一个问题：拆完后哪类查询变慢了？哪类更新变简单了？如果拆表只是让表数量变多，却没有解决任何更新异常，那这个拆分就是过度设计。

实验文档里最稳妥的写法是：默认所有表到 3NF，然后对一两个真正需要冗余的地方做有意识的反规范化，并写明理由。这比把每一张表拆成六亲不认的样子专业得多。团队里做评审时，资深工程师看设计的第一眼，往往就是看表数量和数据冗余是否是业务驱动的，而不是理论推导驱动的。

6. 交付前用三类数据路径自检模式设计，附文档骨架

6.1 插入、查询、更新三类自检用例怎么构造

模式设计完成后，不要急着写文档，先拿数据“走”一遍设计。我会构造三类自检用例：插入用例、查询用例、更新用例。插入用例的目标是验证完整性约束是否覆盖业务规则，比如尝试插入一条重复的选课记录，看看复合主键能不能挡住；插入一条成绩为空的数据，看看允许为空的设置是否符合需求。查询用例的目标是验证高频查询的路径长度，比如列出某个学生的所有选课及成绩，这个查询要 JOIN 几张表，能不能控制在两张以内。更新用例的目标是验证冗余是否可控，比如学生换了专业，需要 UPDATE 几张表；如果只要更新一张表，说明设计没有引入不可控的冗余。

三类用例各写一条 SQL 跑通，再把运行结果截图放进文档里，实验的完整度一下子就上来了。这比你空口说“设计合理”有说服力得多。

6.2 一份模式设计文档的最终骨架

文档骨架我建议分成五块：需求分析（简述业务场景和约束）、E-R 图（图 + 实体/联系说明）、关系模式列表（含主外键标记和范式级别）、规范化分析（函数依赖 + 拆表过程 + 权衡说明）、建表 SQL 脚本（可运行 + 有注释）。如果学校要求交 .doc 格式，所有内容在一个文档里就能交付。

我自己在带新人时经常说一句话：设计文档的价值不在于那张图，也不在于那段 SQL，而在于图、表、SQL 三者之间的推导链条是完整的。我把这个教训带到每一次实验里——先用 SQL 验证可行性，再回填文档；文档里的每一个数字都来自实际执行结果，而不是拍脑袋。希望这篇笔记能帮你在做数据库模式设计时少走一段弯路，把功夫花在设计和验证上，而不是花在返工和改错上。

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