sql 范式

范式,英文 normal from ,直接翻译就是通用的形式。也就是在数据库设计中的通用设计标准。


在说明一个范式前先声明几个概念。表中的关键字。

一张表总会有好几个字段,其中有某些字段是有一定作用的,叫做关键字,关键字有几种:公共关键字,主关键字,外关键字,候选关键字。

公共关键字就是在表中能够共同表示同样的意思的几部分;

主关键字,也会简称主键,主键可以代表这张表的存在;

外关键字,也会简称外键,就是在这张表中可以通过这个外键找到对应的其他表,在语法中要加上一个映射;

候选关键字就是加入表中有几部分都可以作为关键字,选好其中一个作为主键,那么其他的几个就是候选关键字了。

create table test(

  a int primary key,

 b varchar(3)

);

其中表test就是主键

create table test1(

 a int primary key ,

 b varchar(3),

 test_id int,

 foreign key(test_a) test(a)

);

其中a 是主键,test_id 是外键,外键的映射在下一句中  foreign key(test_a) test(a) ,表明这个外键对应表test的主键。

对于这几个关键字就好比美国选总统一样,所有参加被选举的人一起就是公共关键字,最后当上总统那个就是代表美国的人,即主键,参选但是没被选上的就是候选关键字,如果总统刚选上就死掉了,这个候选人就有资格继续参选,如果有某些国家的外加大使在那里看着,这个人就可以当做外键了。


函数依赖:函数依赖是 一种依赖关系,这种关系没有绝对的存在,要看具体的环境,函数依赖就是一张表中,里面的某些字段是有关联的,其他的一个或几个的存在可以决定其他的字段的存在,这个比如表 test(name,address,identity,factory_address),对于这张表大部分的情景下都可以认为是一个人的name,可以决定他的  address, identity  的存在,所以存在依赖(name)->(address,identity),这就是函数依赖。


在sql中一般有  几种范式  第一范式(1NF),第二范式(2NF),第三范式(3NF),BC范式,(还有第四范式和第五范式,这两个不提)。

    第一范式:就是表的中字段的设计要符合原子性,原子性就是不可分开,比如一个字段  名字,名字有名和姓 的存在,所以这个字段就是不符合原子性的。

    第二范式:表中所有的字段都必须和主键有依赖关系,如果主键是组合主键(多个关键字组合形成主键),也必须是同时和组合主键中的所有字段有依赖关系,不能只和主键中部分字段有依赖关系。这样可以看到,如果主键只是一个字段的话,那表就符合第二范式。如果出现不符合第二范式的字段的情况,可将该字段分离出来。

    第三范式:在第二范式的基础上不存在传递依赖(X->Y,Y->Z),如果出现这种情况可以将原来的表(X,Y,Z),分离为两张表,表1(X,Y),表2(Y,Z)。

    BC范式:在第三方式的基础上,候选关键字不存在相互依赖的关系,比如在一种情景中有(X,Y)->(R,Z),(R,Y)->(X,Z),这样(X,Y)和(R,Y)就属于候选关键字,但注意到有这样的关系X->R  和R->X,这样就不符合第三范式了。


### SQL范式及其在数据库设计中的应用 #### 什么是SQL范式SQL范式是指通过一组规则和标准来优化数据库的设计,从而减少数据冗余并增强数据的一致性和完整性。这些范式由埃德加·科德首次提出,并逐步发展成为现代数据库设计的核心理论之一[^2]。 #### 常见的范式层次 以下是常见的几个主要范式: 1. **第一范式 (1NF)** 数据库表中的每一列都必须是不可分割的基本数据项,即不允许有嵌套集合或多值属性。这确保了每一条记录都是原子性的。 2. **第二范式 (2NF)** 在满足1NF的基础上,进一步要求非主键字段完全依赖于整个主键而非部分主键。这意味着如果某个表具有复合主键,则所有其他字段应只与完整的主键相关联[^4]。 3. **第三范式 (3NF)** 这是在2NF基础上的一个扩展,规定除了主键外没有任何其他字段之间存在传递函数依赖关系。换句话说,任何非主属性都不能间接地依赖另一个非主属性。 4. **巴斯-科德范式 (BCNF)** BCNF是对3NF的一种更严格的改进形式,在此级别上消除了任何形式的功能依赖冲突问题,即使当候选关键字多于一个时也能保持逻辑一致[^1]。 #### 如何利用范式进行数据库规范化? 要实现高效的数据库规范化过程,可以遵循以下几个原则: - 首先识别业务需求以及相应的实体间的关系; - 将原始未加工的数据拆分为多个符合最低限度的第一范式的表格; - 接着依据功能依赖分析调整到更高阶次如二三范式直至达到理想状态下的BCNF水平为止; 下面给出一段简单的Python代码用于演示如何创建基本的SQLite数据库并执行一些基础操作: ```python import sqlite3 conn = sqlite3.connect('example.db') c = conn.cursor() # 创建一张新表 c.execute('''CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY, name TEXT NOT NULL UNIQUE, age INT CHECK(age >= 0))''') # 插入几条测试数据 c.executemany("INSERT INTO users VALUES (?, ?, ?)", [(None,'Alice',30),(None,'Bob',25)]) # 查询全部用户信息 for row in c.execute("SELECT * FROM users ORDER BY age"): print(row) conn.commit() conn.close() ``` 上述脚本展示了怎样构建一个简单但已遵照一定范式约束条件的小型用户管理系统模型。 #### 实际应用场景举例说明 考虑这样一个场景——学校教务管理系统的课程注册情况跟踪。假设最初版本如下所示: | StudentID | CourseName | Grade | |-----------|------------------|-------| | S001 | Database Systems | A | | S002 | Calculus | B+ | 然而这样的布局违反了至少三个级别的规范要求因为重复出现了诸如学生姓名之类的额外细节并且难以维护更新同步等问题。因此重新规划后的架构可能看起来像这样分开存储学生的个人信息、所修读科目清单还有最终评分结果分别置于独立关联起来的不同子集当中去处理会更加合理有效率得多[^5]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值