数据库设计包含需求设计、逻辑设计、物理设计和维护优化。
为了设计出没有数据冗余和数据维护异常的数据结构,我们需要遵循以下规范:
针对这个问题,我们怎么破呢?我们对上面这个表拆分为3个表:学生表、课程表、学生课程关系表。其中,学生表和课程表只有一个主键,而学生课程关系表有一个复合主键(学生编号,课程),分数完全依赖于这个复合主键,因此符合第二范式。
每一个非主属性既不部分依赖于也不传递依赖于业务主键,也就是在第二范式的基础上消除了非主属性对主键的传递依赖。 对于学生表,学院依赖于学生编号,而学院地址却依赖于学院,这就是传递依赖,此时,这张表不满足第三范式。如果想让这张表满足第三范式就需要继续对这张表进行拆分。
遵循范式化的数据库设计,实现了消除数据冗余的目的,但是此时数据库的性能和读取效率并不是最优的。为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违反,而允许存在少量的数据冗余,换句话来说反范式化就是使用空间来换取时间。 举个栗子,以我们经常进行下单为例。根据范式准则,定单表和订单商品关联表如下:
订单表:{订单编号,下单用户名,下单日期,支付金额,物流单号}
订单商品关联表:{订单编号,订单商品分类,订单商品名,商品数量}
我们知道查询订单时,往往需要知道用户名称和用户手机号,那么,此时我们就需要将订单表和用户表进行关联查询。这种设计存在一个问题,当用户修改手机号,那么用旧手机号买的订单号的手机信息是新的手机号,而不是旧手机号,这是不符合业务需求的。解决这个问题的办法就是将用户名和用户手机号加入到订单表中。同样情况,商品的价格也存在修改的情况,因此,也需要将支付金额加入到订单表中,此时,订单表和订单商品关联表如下:
订单表:{订单编号,下单用户名,下单日期,支付金额,物流单号,订单金额}
订单商品关联表:{订单编号,订单商品分类,订单商品名,商品数量,商品单价}
欢迎关注微信公众号:木可大大,所有文章都将同步在公众号上。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。