# 数据库基础

# 关系数据库语言

关系语言定义了允许对数据进行的操作,包括从数据库中更新或检索数据所用的操作以及改变数据库对象结构的操作。关系数据库的主要语言是SQL语言。

SQLStructured Query Language的缩写,意为结构化查询语言。SQL已经被国际标准化组织(ISO)进行了标准化,使它成为正式的和事实上的定义和操纵关系数据库的标准语言。SQL语言又可分为DDLDMLDCLTCL四类。

DDLData Definition Language的缩写,意为数据定义语言,用于定义数据库结构和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。

DMLData Manipulation Language的缩写,意为数据操纵语言,用于检索、管理和维护数据库对象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。

DCLData Control Language的缩写,意为数据控制语言,用于授予和回收数据库对象上的权限。典型的DCL有grant和revoke。

TCLTransaction Control Language的缩写,意为事务控制语言,用于管理DML对数据的改变。它允许一组DML语句联合成一个逻辑事务。典型的TCL有commit、rollback、savepoint、set transaction等。

# 范式

员工表

id name mobile zip province city district deptNo deptName
101 张三 13910000001 13910000002 100001 北京 北京 海定区 D1 部门1
101 张三 13910000001 13910000002 100001 北京 北京 海定区 D2 部门2
102 李四 13910000003 200001 上海 上海 静安区 D3 部门3
103 王五 13910000004 510001 广东省 广州 白云区 D4 部门4
103 王五 13910000004 510001 广东省 广州 白云区 D5 部门5

# 第一范式(1NF)

表中的列只能含有原子性(不可再分)的值。 例如张三有两个手机号存储在mobile列中,违反了1NF规则。为了使表满足1NF,我们需要进行调整。

1NF

id name mobile ...
101 张三 139100001 ...
101 张三 139100002 ...

# 第二范式(2NF)

第二范式要同时满足下面两个条件:

  • 满足第一范式
  • 没有部分依赖

员工表的一个候选键是{id,mobile,deptNo},而deptName起来于deptNo,同样name依赖于id。因此不是2NF的。为了满足第二范式的条件,需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表:

2NF员工表

id name zip province city district
101 张三 100001 北京 北京 海定区
102 李四 200001 上海 上海 静安区
103 王五 510001 广东省 广州 白云区

2NF部门表

deptNo deptName
D1 部门1
D2 部门2
D3 部门3
D4 部门4
D5 部门5

2NF员工-部门表

id deptNo
101 D1
101 D2
102 D3
103 D4
103 D5

2NF员工-电话表

id mobile
101 1391000001
101 1391000002
102 1391000003
103 1391000003

# 第三范式(3NF)

第三范式要同时满足下面两个条件:

  • 满足第二范式。
  • 没有传递依赖。

例如,员工表的province、city、district依赖于zip,而zip依赖于{id},换句话说,province、city、district传递依赖于{id},违反了3NF规则。为了满足第三范式的条件,可以将这个表拆分成employee和zip两个表:

3NF员工表

id name zip
101 张三 100001
102 李四 200001
103 王五 510001

3NF 地区表

zip province city district
100001 北京 北京 海定区
200001 上海 上海 静安区
510001 广东省 广州 白云区

在关系数据模型设计中,一般需要满足第三范式的要求。如果一个表有良好的主外键设计,就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率,同时保证数据完整性。

然而,我们在实际应用中也要防止过度规范化的问题。规范化程度越高,划分的表就越多,在查询数据时越有可能使用表连接操作。而如果连接的表过多,会影响查询的性能。关键的问题是要依据业务需求,仔细权衡数据查询和数据更新的关系,制定最适合的规范化程度。还有一点需要注意的是,不要为了遵循严格的规范化规则而修改业务需求。

更新时间: 3/21/2020, 3:57:55 PM