4.1 4.2 数据抽象和建模方法

以某大学图书馆管理为背景，设计相关模型。分别表述它的概念模型、逻辑模型和物理模型。

• 概念模型：定义实体（图书、读者、借阅记录等）及其关系（借阅），明确业务规则（如一位读者可以借阅多本图书，一本图书可以被多人、多次借阅）。
• 逻辑模型：将实体映射为表（图书表、读者表、借阅记录表），定义字段（ISBN、借书证号、借阅记录编号等）和约束（主键、外键、唯一性约束）。
• 物理模型：确定存储细节（如使用InnoDB存储引擎、ISBN和借书证号学段确定数据类型等）。

4.3 4.4实体联系建模

实体与实例：实例是实体的具体表现，代表实体的一个特定对象.

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

File – new model – 可视化界面

DataBase – forward Engineer – 继续会将表转化为SQL代码，粘贴到我们的库中即可实现同样的效果

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

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

一范式 (1NF)

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

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

二范式 (2NF)

• 在满足第一范式的基础上消除部分依赖。第二范式要求实体设置复合主键并且其他非主属性完全依赖于主键，不能仅依赖主键的一部分
• 只要不是复合主键就一定满足二范式

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

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

三范式 (3NF)

在第二范式的基础上要求非主键字段之间不能相互依赖，第三范式要求一个数据表中每一列数据都和主键直接相关，而不能间接相关

如何判断是否遵循第三范式，副键A和B单独与主键都有关，但A和B之间不能有关
比如平时成绩和期末成绩和总评成绩单独都和主键学号有关，但是期末成绩和总评成绩也有关，这就不满足第三范式

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

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

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

总结

终点是业务：范式是手段，平衡查询效率与数据一致性是目标

拆到原子字段(1NF)-去多值→
拆表到完全依赖(2NF)-去部分依赖→
拆实体到直接依赖(3NF)-去传递依赖，外键连一切