数据库设计三范式

            数据库表设计的时候有一定的科学规范,就是三范式

一、第一范式

          数据库表中不能出现重复记录,每个字段是原子性的不能再分

          理解:记录没有重复的,即使业务信息是重复的,主键不一样,也认为是不同记录;每个字段记录的信息是最小粒度

二、第二范式

          第二范式是建立在第一范式基础上的,另外要求所有非主键字段完全依赖主键,不能产生部分依赖

          理解:第二范式可以理解不能有联合主键,存在联合主键的时候必然是非主键字段依赖于联合主键中的一个

三、第三范式

          建立在第二范式基础上的,非主键字段不能传递依赖于主键字段。(不要产生传递依赖

          例:

学生编号(PK)

学生姓名

班级编号

班级名称

1001

张三

01

一年一班

1002

李四

02

一年二班

1003

王五

03

一年三班

1004

03

一年三班

      班级名称字段存在冗余,因为班级名称字段没有直接依赖于主键,班级名称字段依赖于班级编号,班级编号依赖于学生编            号,那么这就是传递依赖,解决的办法是将冗余字段单独拿出来建立表

四、几个经典的设计

         一对一:第一种方案:分两张表存储,共享主键

                       第二种方案:分两张表存储,外键唯一

         一对多:分2张表存储,在多的一方添加外键,这个外键字段引用一方中的主键字段

         多对多:分3张表存储,两张事实表加一个关系表

四、三范式总结

          第一范式:有主键,具有原子性,字段不可分割

          第二范式:完全依赖,没有部分依赖

          第三范式:没有传递依赖

          数据库设计尽量遵循三范式,但是还是根据实际情况进行取舍,有时可能会拿冗余换速度,最终用目的要满足业务需求。

五、个人思考

          看到数据库三范式就想到了数据仓库,两者的思路基本完全相反,数据仓库没有主键概念,且会刻意制造信息冗余,基本是完全违背了数据库的三范式,毕竟两者的实际应用场景不一样。不过知道了设计的三范式可以更科学的思考一些数据构建问题。

已标记关键词 清除标记
相关推荐
课程简介: 历经半个多月的时间,Debug亲自撸的 “企业员工角色权限管理平台” 终于完成了。正如字面意思,本课程讲解的是一个真正意义上的、企业级的项目实战,主要介绍了企业级应用系统中后端应用权限的管理,其中主要涵盖了六大核心业务模块、十几张数据库表。 其中的核心业务模块主要包括用户模块、部门模块、岗位模块、角色模块、菜单模块和系统日志模块;与此同时,Debug还亲自撸了额外的附属模块,包括字典管理模块、商品分类模块以及考勤管理模块等等,主要是为了更好地巩固相应的技术栈以及企业应用系统业务模块的开发流程! 核心技术栈列表: 值得介绍的是,本课程在技术栈层面涵盖了前端和后端的大部分常用技术,包括Spring Boot、Spring MVC、Mybatis、Mybatis-Plus、Shiro(身份认证与资源授权跟会话等等)、Spring AOP、防止XSS攻击、防止SQL注入攻击、过滤器Filter、验证码Kaptcha、热部署插件Devtools、POI、Vue、LayUI、ElementUI、JQuery、HTML、Bootstrap、Freemarker、一键打包部署运行工具Wagon等等,如下图所示: 课程内容与收益: 总的来说,本课程是一门具有很强实践性质的“项目实战”课程,即“企业应用员工角色权限管理平台”,主要介绍了当前企业级应用系统中员工、部门、岗位、角色、权限、菜单以及其他实体模块的管理;其中,还重点讲解了如何基于Shiro的资源授权实现员工-角色-操作权限、员工-角色-数据权限的管理;在课程的最后,还介绍了如何实现一键打包上传部署运行项目等等。如下图所示为本权限管理平台的数据库设计图: 以下为项目整体的运行效果截图: 值得一提的是,在本课程中,Debug也向各位小伙伴介绍了如何在企业级应用系统业务模块的开发中,前端到后端再到数据库,最后再到服务器的上线部署运行等流程,如下图所示:
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页