聊聊数据库范式
最近给新员工做了一次数据库基础的培训，其中涉及个主题，就是数据库范式，从理论层面讲，数据库会包含第一范式、第二范式、第三范式、BC范式、第四范式、第五范式等，但是一般情况下，满足第三范式就足够了。
什么是第三范式？我们要从第一范式开始看。
第一范式，理论概念是数据库表中的字段都是单一属性的，不可再分。举个例子，学生信息表，“地址”字段存储了学生的地址，可以看到，当前不是单一属性的，我们检索的时候，可能会根据“省”、“市”作为条件，该字段是可以继续进行分解的，
文章图片
将“地址”字段拆成“省份”、“城市”、“详址”三个字段，此时每个字段就是单一属性的了，当前的设计就是符合第一范式，
文章图片
第二范式，理论概念是数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖，不能部分依赖。听着抽象，翻译一下，应该包括了三层含义，
1. 首先就是符合第一范式。
【聊聊数据库范式】2. 表必须存在主键。
3. 非主键列不能只依赖于主键的一部分。
如下这张表，主键是“快递单号”和“商品编号”，但是像“价格”依赖于“商品编号”，“数量”依赖于“快递单号”，都是依赖于主键的一部分，这种情况，就是不符合第二范式的，
文章图片
因此，拆分为这三张表，快递信息表中都是和快递相关的字段，商品信息表中都是和商品相关的字段，快递项目表则是快递和商品的关联表，每张表中非主键列都依赖于主键的全部，此时，就是符合第三范式的，
文章图片
第三范式，理论概念是在第二范式的基础上，数据表中不存在非关键字段对任一候选关键字段的传递函数依赖，即除了主键外，其他字段必须依赖主键。如下例子，“爸爸”是主键，但是“儿子的玩具车”和“儿子的玩具枪”依赖的是“儿子”，并不依赖于主键，存在传递函数依赖的关系，因此不符合第三范式，
文章图片
可以拆成这两张，每张表中的非主键字段，都只依赖于主键，不存在传递函数依赖的关系，因此这是符合第三范式的，
文章图片
符合第三范式的表设计，可以说是从理论层面比较纯粹的设计了，但在实操层面，这种设计，未必一定可行。其实无论是数据库设计，还是系统架构的设计，都是为了业务需求服务的，都需要考虑实际的业务场景，仅从理论上考量，有时候未必能够满足业务的需求。
例如在第一范式中的例子，如果你的需求，会根据“区”、“路”进行检索，“详址”字段，当前的设计还可以继续拆，究竟什么是“单一属性”的粒度，还是取决于业务场景。例如在第二范式的例子，拆成了三张表，确实结构清晰，但是可能每次检索快递和商品信息的时候，都需要三表关联，如果数据量很大，表的字段属性再复杂些，对性能造成的影响就会更明显，此时，根据业务场景，向表中冗余一些字段，虽然违反了范式，但是能在满足业务需求和性能需求中得到平衡，可能就是一种更合适的方案。
因此，无论何种范式，都是理论基础，在实操过程中，还是要考虑实际业务场景的需求，有时候就需要“反范式”，套用一句广告词“没有最好的设计，只有最合适的设计”。
近期的热文：
《数据库到底能不能部署在docker容器中？》
《一道SQL问题，你来试试的？》
《如何捕获问题SQL解决过度CPU消耗的问题》
《了解一下ARM CPU架构》
《如何查看JVM运行的堆内存情况》
《Linux下如何快速删除大量碎小的文件？》
《打造国产技术产品的必要性》
《Oracle删除字段的方式和风险，你都了解么？》
《登录缓慢的诡异问题》
《Oracle相关提问的智慧技巧》
《PLSQL Developer几个可能的隐患》
《从70万字SRE神作提炼出的7千字精华文章》
《从数据误删到全量恢复的惊险记录》
《公众号600篇文章分类和索引》
推荐阅读
- Docker应用:容器间通信与Mariadb数据库主从复制
- 数据库设计与优化
- 数据库总结语句
- 想聊聊SA，聊聊手帐，也想和你们分享自己
- MySql数据库备份与恢复
- 数据库|SQL行转列方式优化查询性能实践
- MySQL数据库的基本操作
- springboot整合数据库连接池-->druid
- Android|Android sqlite3数据库入门系列
- Python3|Python3 MySQL 数据库连接