4.1 4.2 数据库设计流程以及数据抽象和建模方法

实体联系建模（案例4.3及案例4.4）

元素类型	图形符号	核心含义	关键说明与示例
实体（Entity）	单矩形框（□）	独立存在的事物（人 / 物 / 概念）	框内写实体名，如 “学生”“课程”“订单”
普通属性	单椭圆形（○）	实体的描述特征（数据项）	用直线连对应实体，如 “姓名”“成绩”“价格”
主键属性	下划线单椭圆形（○）	唯一标识实体的属性	示例：“学号”（学生实体主键）、“课程号”（课程实体主键）
复合属性	含子椭圆形的单椭圆形	可拆分子属性的属性	如 “地址” 拆分为 “省”“市”“街道”，子椭圆形连父椭圆形
多值属性	双椭圆形（○○）	一个实体可对应多个值的属性	如学生的 “联系方式”（多个电话）、“兴趣爱好”
派生属性	虚线椭圆形（○）	由其他属性推导得出的属性	如 “年龄”（由 “出生日期” 计算）、“总成绩”（由多门课成绩求和）
关系（Relationship）	单菱形框（◇）	实体间的关联 / 相互作用	框内写关系名，如 “选课”“授课”“下单”，用直线连关联实体
标识关系（弱实体关联）	双菱形框（◇◇）	弱实体与主实体的依赖关联	如 “订单明细”（弱实体）与 “订单”（主实体）的 “包含” 关系
弱实体	双矩形框（□□）	依赖主实体存在的实体	如 “订单明细” 依赖 “订单”，需通过标识关系关联
关系基数标注	数字 / 符号（1、N、M 等）	实体间关联的数量限制	标注在关系与实体的连接线上，如 1:1（学生 – 身份证）、1:N（班级 – 学生）、M:N（学生 – 课程）

在关系数据库中不能直接实现多对多联系，那么就有了第四行内容读者和图书与借阅记录都是一对多的联系，借阅记录作为一个中间表呈现

案例4.5 为图书馆管理系统设计实现实体—联系模型

File – New model – Add Diagram

从WorkBench设计图表转换为代码：DataBases- Forward Engineer
因为有三个实体学生，借阅记录和书籍，所以导出有3张表

数据库范式设计（案例4.6至案例4.9）

可以帮我们设计出高效，一致且易于维护的数据库结构。3范式就可以解决大部分应用中的规范化问题

常用范式

一范式 (1NF)

• 第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值，或不能有重复的属性。简而言之，第一范式遵从原子性，属性不可再分

作者列包含多个值违反了字段原子性的原则，所以不符合第一范式
解决方法：将作者信息拆解为单独的关系表，转化后变成两张表，形成数目和作者一对多的关系，这样每条书目的作者都可以在作者表中体现同时不违反第一范式

二范式 (2NF)

• 满足第二范式必须先满足第一范式。第二范式要求实体设置主键并且其他非主属性完全依赖于主键，不能仅依赖主键的一部分（对于复合主键而言）。简而言之，第二范式要求非主键字段需完全依赖主键（在一范式的基础上消除部分依赖）

图书名称（非主键）仅仅依赖于条码号，而不是整个联合主键，而这个表的联合主键有多个列
解决方法：将图书信息拆分为单独的表，通过外键进行关联。

当然这会降低效率，实际应用中应权衡两者利弊

三范式 (3NF)

第三范式（3NF）是在第二范式的基础上建立起来的，即满足第三范式必须先满足第二范式。第三范式要求一个数据表中每一列数据都和主键直接相关，而不能间接相关。简而言之，第三范式要求非主键字段之间不能相互依赖

学院信息拆分为单独的表并通过外键进行关联

利用反范式设计兼顾效率与规范

订单需要快速查找，且信息一般都不变。可以改用反范式设计，牺牲一部分规范性约束换取效率的提升