数据库的三大范式详解

数据库的三大范式

第一范式(1NF)

原子性:保证每一列不可再分

举例:
不满足第一范式
在上面的表中,family_inf列中不满足原子性的要求,故不满足第一范式。需调整如下:

满足第一范式

第二范式(2NF)

在第一范式的基础下,非主键属性必须完全依赖于主键(候选码)
举例:
不符合第二范式

在上面的表中,同一订单中可能包含不同的商品(如订单2、订单3),因此主键必须由“订单编号”和“商品号”联合组成。“商品名称”、“商品数量”、“商品折扣”和“价格”都是依赖于“订单编号”和“商品号”;“订单金额”只依赖于“订单编号”(没有完全依赖于主键)。

不满足第二范式,调整如下,需要分成两个表:

表一表二

第三范式(3NF)
在第一范式、第二范式的基础下,第三范式需要确保数据表中每一列数据都与主键直接相关,而不能间接相关(消除传递依赖)。
举例:
不符合第三范式在上面的表中,所有的属性都不可再分且都完全依赖于编号,所以符合第一、第二范式。但是,“老师性别”和“老师年龄”直接依赖的是“老师姓名”,而不是主键“编号”,所以需调整为以下两个表:

学生表表一老师表表二
这样就满足了第三范式的要求。

ps:上表中的老师姓名改成老师ID更确切,更符合我们实际开发的情况。

规范性和性能的问题

关联查询的表不得超过三张

  • 考虑商业化的需求和目标(成本、用户体验)数据库的性能更加重要
  • 在规范和性能的问题的时候,需要适当考虑规范性
  • 故意给一些表增加一些冗余的字段。(从多表查询变为单表查询)
  • 4
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库三大范式是指在设计关系型数据库时需要遵循的规范,以确保数据的完整性和一致性。具体而言,第一范式(1NF)要求每个字段只能包含原子性的值,第二范式(2NF)要求每个非主键字段都必须完全依赖于主键,第三范式(3NF)要求每个非主键字段之间不能相互依赖。下面是三大范式的详细介绍和示例: 1. 第一范式(1NF):要求关系中的每个属性都是不可再分的原子值,即每个属性都不可再分成更小的部分。例如,一个人的姓名和姓氏应该作为两个不同的属性存储,而不是将它们合并成一个属性。 2. 第二范式(2NF):在满足第一范式的基础上,要求关系中的非主键属性必须完全依赖于主键,而不能存在部分依赖关系。例如,如果一个订单号确定一个产品和数量,则产品和数量应该作为一个表的属性,而不是将它们作为订单表的属性。 3. 第三范式(3NF):在满足第二范式的基础上,要求关系中的非主键属性之间不能存在传递依赖关系。例如,如果一个订单号确定一个产品类型,则产品类型和产品描述应该作为不同的表的属性,而不是将它们作为订单表的属性。 下面是一些SQL语句的示例: 1. 创建表时指定主键: ``` CREATE TABLE orders ( order_id INT PRIMARY KEY, product_name VARCHAR(50), quantity INT, price DECIMAL(10,2), customer_id INT ); ``` 2. 添加外键: ``` ALTER TABLE orders ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id) REFERENCES customers(customer_id); ``` 3. 查询语句: ``` SELECT order_id, product_name, quantity, price FROM orders WHERE customer_id = 1; ```

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值