浅述SQL Server的语句类别数据库范式系统数据库组成

数据库发布日期：2024/12/29 浏览次数：1

正在浏览：浅述SQL Server的语句类别数据库范式系统数据库组成

前言

终于等到这一天，我要开始重新系统学习数据库了，关于数据库这块，不出意外的话，每天会定时更新一篇且内容不会包含太多，简短的内容，深入的理解。

SQL语句类别

SQL语句包括以下三个类别

（1）数据定义语言（Data Definnition Language）即DDL，我们数据最终从何而来，当然首先必须得建立表，所以它包括CREATE、ALTER、DROP表。

（2）数据操作语言（Data Manipulation Language）即DML，我们对数据需要进行什么操作，当然无非就是增删改查，所以它包括SELECT、INSERT、UPDATE、DELETE，其中还包括TRUNCATE、MERGE。

（3）数据控制语言（Data Control Language）即DCL，我们操作数据库时针对不同的用户会授予不同权限。

数据库范式

范式是什么玩意，它意指规范化规则，通俗易懂一点讲则是定义的规范、规则，需要我们去遵守，那么为何要定这一套规则呢？我们反过来想，肯定是前人遇到过，若不定义这一套规则，则出现这样或那样的问题，为了规避这样问题的出现则出了这一套规则，主要是为了解决如下两点问题。

（1）避免在数据修改过程中出现异常。

（2）保持数据最低限度的冗余。

数据库范式最基础的范式为第一范式（1NF）、第二范式（2NF）、第三范式（3NF），还有更高层次的范式，但太过于复杂我们不做探讨，大部分书籍都这样说，我们就这样去了解。

第一范式（1NF）

定义：关系表中行必须是唯一且属性是原子性的。

太晦涩，太抽象，不太懂，我们一一来分析，我们看看上述定义中重点在于行【唯一】，属性【原子性】。

那么到底什么情况下才算是行唯一呢？

第一：既然是唯一，那么行中某一标识必须是已知而非未知即不能为空

第二：唯一也就是说不能重复诺

第三：怎么保证行唯一呢？通过定义一个唯一键来实现唯一行。

那么到底什么是原子性呢？

第一看到原子这个词语是不是会立马联想到中国独立研制的原子弹爆发，又或者是上化学课遇到的第一个化学式2H2+O2=2H2O，2个氢气即4个氢原子与1个氧气即2个氧原子集合生成1个水分子，哦，回顾一下，分子是由原子组成，原子由原子核和核外电子组成，原子核又由质子和中子组成，还有什么夸克之类的，无论是程序语言还是数据库中都一直在讲原子性，为什么没有讲质子性和夸克性呢，因为原子已经算是比较小的，所以一直用原子性来强调并划分，为了方便理解，可以这么思考，后面的就不用在叙述，到了这里还没明白么，就相当于原子组成分子，将原子作为最小的粒度即不能再分，那么我们反过来想属性的原子性即属性不可再划分，这又是什么意思，比如在表中有一个地址属性，如果我们存如（湖南省，岳阳市，华容县）这样就违背了第一范式，这个属性还是可以再划分为省、城市、县。

到这里我们可以作出总结第一范式满足的条件：

（1）唯一标识的键

（2）键不能为空

（3）键不能重复

（4）属性不可再划分

第二范式（2NF）

定义：在满足第一范式的前提下，每一个非键属性必须满足对整个候选键的完全函数依赖即非键属性不能是对候选键某部分的完全函数依赖。

好了，我们继续入上述解释第一范式来解释第二范式晦涩难懂的定义。我们看下如下表

上述定义候选键都是指的主键。上述给出表中OrderId和ProductId都是作为候选键即主键，但是此时我们可以通过部分候选键（主键）比如OrderId得到OrderDate、CustomerId和CompanyName等列，此时是仅仅是OderId的部分依赖而非对OderId和ProductId二者的完全依赖。此时为了表现出对候选键的完全依赖应该划分成如下两个表。

所以将上述定义通俗讲则是：属性对主键应该属于完全依赖而非部分依赖，否则违反第二范式。

第三范式（3NF）

同样第三范式是在满足第一和第二范式的前提下来看第三范式。

定义：所有非键属性必须依赖于非传递的候选键，也就是非键属性相互之间必须相互独立，进一步讲非键属性之间不能形成依赖关系。

我们看看上述经过修改满足第二范式的两个表，此时订单表中OrderId为主键，客户Id即CustomerId和公司名称即CompanyName对OrderId是完全依赖，我们可以通过订单Id得到客户Id，也可以通过订单Id得到公司名称，同时我们也可以通过客户Id得到客户公司名称，也就是说此时CustomerId和CompanyName是一种传递关系，而非相互之间独立。此时若需要满足第三范式则应该是如下表示：