第2章：数据库设计基础理论
好，咱们进入正题。这一章讲的是数据库设计的“内功心法”。你想想看，不懂这些基础理论，上来就建表，那跟盖楼不打地基有什么区别？我在项目里见过太多“跑得起来但改不动”的系统，说白了，就是基础没打牢。
2.1 关系型数据库核心概念
先聊聊最基础的东西。关系型数据库，你可以把它想象成一个Excel大合集。但比Excel严谨得多。
2.1.1 表（Table）与字段（Field）
表就是实体。比如“员工表”、“部门表”。字段就是属性。比如员工的姓名、工号、入职日期。
我个人习惯，在设计表时，字段名全小写，用下划线分隔。比如 user_name，而不是 UserName。为什么？因为大多数数据库对大小写敏感，全小写能避免很多莫名其妙的错误。嗯，这是踩坑换来的经验。
2.1.2 主键（Primary Key）
主键就是每行数据的“身份证号”。必须唯一，不能为空。我建议你用自增整数或者UUID。但要注意：
- 自增整数：性能好，但分布式场景下会冲突
- UUID：全局唯一，但占空间大，查询慢一点
2.1.3 外键（Foreign Key）
外键是用来建立表与表之间关系的。比如员工表里的 dept_id，指向部门表的主键。
但是！我在实际项目中，很少用数据库层面的外键约束。为什么？因为外键约束会影响写入性能，而且在分布式系统里根本没法用。我更倾向于在应用层（Java/Python代码里）维护这种关系。这叫“逻辑外键”。
2.1.4 索引（Index）
索引就是书的目录。没有索引，查数据就得全表扫描——数据量一上去，直接卡死。
我记得有一次，一个OA系统的审批流程页面打开要30秒。一查，核心表没加索引。加上之后，秒开。
索引类型主要有：
| 索引类型 | 说明 | 使用场景 |
|---|---|---|
| 普通索引 | 最基本的索引 | 经常查询的字段 |
| 唯一索引 | 值必须唯一 | 身份证号、工号 |
| 联合索引 | 多个字段组合 | 经常一起查询的字段 |
| 全文索引 | 用于文本搜索 | 文章内容、审批意见 |
2.2 三大范式详解
范式，说白了就是“表该怎么设计”的规范。一共6级，但实际工作中掌握前3级就够了。
2.2.1 第一范式（1NF）：字段不可再分
每个字段只能存一个值。比如“地址”字段不能写成“北京市海淀区中关村”，应该拆成“省、市、区、详细地址”。
我曾经接手过一个OA系统，里面有个“附件”字段，存的是“文件1.zip,文件2.pdf,文件3.docx”。查询时还得用代码拆分，麻烦得要死。这就是违反第一范式的典型。
2.2.2 第二范式（2NF）：非主键字段必须完全依赖主键
说白了，就是一张表只描述一件事。比如员工表里，员工信息依赖员工ID，部门信息依赖部门ID。如果把部门名称也放在员工表里，那部门改名时，就得更新所有员工记录——这就是部分依赖。
正确的做法：拆成员工表和部门表，用部门ID关联。
2.2.3 第三范式（3NF）：非主键字段不能传递依赖
这个有点绕。举个例子：员工表里有“部门ID”和“部门地址”。部门地址其实是通过部门ID推导出来的，这就是传递依赖。应该把部门地址放到部门表里。
2.3 ER图绘制规范
ER图（实体关系图）是数据库设计的“蓝图”。画好ER图，建表就成功了一半。
2.3.1 基本符号
- 矩形：实体（表）
- 椭圆：属性（字段）
- 菱形：关系（关联）
- 连线：1对1、1对多、多对多
2.3.2 我的绘图习惯
我一般先画核心实体，再画关联关系。比如OA系统：
- 先画出“用户”、“部门”、“角色”三个核心实体
- 再画“用户属于部门”（多对一）
- 再画“用户拥有角色”（多对多）
- 最后补充属性字段
2.4 PowerDesigner / PDMan 工具入门
工欲善其事，必先利其器。这两个工具我都用过，说说我的感受。
2.4.1 PowerDesigner
老牌工具，功能强大。支持逆向工程（从数据库生成模型）、正向工程（从模型生成SQL）。但缺点也很明显：
- 收费，而且不便宜
- 界面老旧，学习曲线陡
- 适合大型企业、传统项目
2.4.2 PDMan（国产之光）
我最近几年一直在用PDMan。免费、开源、界面清爽。支持MySQL、Oracle、PostgreSQL等主流数据库。
它的核心功能：
- 可视化建表：拖拽就能建字段
- 自动生成SQL：设计完直接导出建表语句
- 版本管理：可以对比两个版本的差异
- 文档导出：一键生成数据库设计文档（Word/PDF）
2.4.3 快速上手PDMan
安装后，跟着这几步走：
- 新建项目，选择数据库类型（比如MySQL 8.0）
- 创建表，添加字段（名称、类型、长度、是否为空）
- 设置主键（一般选自增ID）
- 建立外键关系（拖拽连线即可）
- 点击“生成SQL”，复制到数据库执行
嗯，就这么简单。你试试看，十分钟就能上手。
好了，这一章的内容就到这里。理论是枯燥的，但它是你未来少踩坑的保障。下一章我们开始实战——设计OA系统的用户模块表结构。