数据库——关系模型设计

本文详细介绍了数据库关系模型设计的重要性,特别是在大型项目中,规范化的表结构能提高存储效率和数据完整性。通过实例解释了第一范式、第二范式和第三范式,以及它们在消除数据冗余和确保数据一致性上的作用。最后,讨论了在实际工作中的范式选择,强调了理解规范化过程对开发人员的重要性。
摘要由CSDN通过智能技术生成

数据库关系模型设计

背景

目前公司内部主流数据库是关系型数据库MySQL,数据库设计是对数据进行组织化和结构化的过程,即关系模型的设计。
对于项目规模小、用户数量少的情况,处理数据库中的表结构相对轻松;目前公司的发展速度快、用户数量多、项目规模大、业务逻辑极其复杂;
相应的数据库架构、关系模型表结构越来越复杂,这时我们往往会发现我们写出来的SQL语句是很笨拙并且效率低下的。更可怕的是,由于表结构定义不合理,会导致对数据的增删改查不方便不高效;最致命的是,扩展性极差,不能应对业务的变化。

此时对我们开发人员关系模式设计能力要求提高了,我们要学习和掌握数据库的规范化流程,以指导我们更好的设计数据库的表结构,减少冗余的数据,借此可以提高数据库的存储效率,数据完整性和可扩展性。

简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计,在以后的数据维护中,不会发生插入(insert)、删除(delete)和更新(update)时的异常。反之,数据库表结构设计不合理,不仅会给数据库的使用和维护带来各种各样的问题,而且可能存储了大量不需要的冗余信息,浪费系统资源。

关于数据库关系模型设计的问题,就是在实际项目中,我们应该构造几个关系模型,每个关系(表)由哪些属性(列)组成,不同关系之间有什么关联。

规范化

一个低级范式的关系模型通过模式分解可以转为若干个高一级别范式的关系模型的集合,这个过程就叫规范化。

为了说明方便,我们用一个订单场景,来一步一步分析规范化的过程

如下只是为了演示,关系模型规范化的过程,存在不规范的地方

create table order_info (
    order_no varchar(10) not null comment '订单编号',
    account_name varchar(10) not null comment '会员姓名',
    account_address varchar(10) not null comment '会员地址',
    product_name varchar(10) not null comment '商品',
    product_address varchar(10) not null comment '产地',
    product_num int unsigned not null default 0 comment '数量',
    product_price double not null comment '单价',
    sum_price double not null comment '总价',
    primary key(order_no,account_name,product_name)
) engine=innodb default character set=utf8;
order_no account_name account_address product_name product_address product_num product_price sum_price
2019070800
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值