SQL Server-语句类别、数据库范式、系统数据库组成(一)

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
简介: 前言 终于等到这一天,我要开始重新系统学习数据库了,关于数据库这块,不出意外的话,每天会定时更新一篇且内容不会包含太多,简短的内容,深入的理解,Always to review the basics。

前言

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

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是一种传递关系,而非相互之间独立。此时若需要满足第三范式则应该是如下表示:

我们可以看出第三范式着重强调的是非键属性与非键属性之间独立,而第二范式着重强调的是非键属性与候选主键的完全依赖。所以第二范式和第三范式我们统一概括为:非键属性必须是对键的依赖,而非相互之间依赖,并且是对整个键的依赖。 

系统数据库组成

当打开数据库中后在数据库下默认会有个系统数据库,里面的内容如下:

master 

master数据库存储实例范围的元数据信息、服务器配置、实例中的所有数据库信息和初始化信息。

Resource

Resource数据库是一个隐藏、只读数据库,存储所有系统对象的定义。

model

model数据库是创建新数据库的模板,创建的每个新数据库都是有model的副本初始化创建的。

tempdb

tempdb数据库是SQL Server存储临时数据的地方,如工作表、排序空间、行版本控制信息。同时SQL Server允许我们创建我们自己使用的临时表,并且这些临时表的位置是tempdb,但是我们需要注意的是每当重新启动SQL Server实例时,该数据库将会被破坏掉,并由model副本创建。

msdb

msdb数据库是SQL Server代理的服务存储数据的地方,SQL Server代理负责自动操作,包括作业、计划和警报,同时也负责复制服务等等。

总结

本节我们着重讲解了SQL语句的组成以及数据库的三个范式,对系统数据库的组成进行简短的介绍,属于了解的范畴吧,今天我们先到这里,我们下节再会。

目录
相关文章
|
10月前
|
人工智能 JavaScript IDE
好消息,在 Visual Studio 中可以免费使用 GitHub Copilot 了!
好消息,在 Visual Studio 中可以免费使用 GitHub Copilot 了!
745 11
|
SQL 数据管理 BI
SQL Server 有哪些版本?
SQL Server 有哪些版本?
895 3
|
负载均衡 应用服务中间件 nginx
nginx配置kibana访问用户名和密码认证、及无认证访问配置
nginx配置kibana访问用户名和密码认证、及无认证访问配置
666 0
|
存储 编解码 文件存储
Windows 中的硬链接、目录联接(软链接)、符号链接、快捷方式
【10月更文挑战第5天】本文介绍了四种链接类型的概念及用途:硬链接允许通过多个入口访问同一文件内容,适用于不复制文件的情况下提供多处访问;软链接(目录联接)用于创建目录间的虚拟映射,可跨越文件系统;符号链接则更为灵活,可链接文件或目录并指向任意路径;快捷方式则是Windows中常用的一种特殊文件类型,便于快速访问程序、文件或网络资源。分别描述了它们的定义、工作原理、特点以及创建方法。
3037 10
|
弹性计算 自然语言处理 Windows
通义灵码 Visual Studio 下载安装指南(附安装包)
本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。
2963 3
|
JavaScript
【vue】vue 在线编辑、实时预览的代码交互组件 vue-code-view
【vue】vue 在线编辑、实时预览的代码交互组件 vue-code-view
1777 0
|
自然语言处理 监控 网络协议
[基础服务-windows] [ELK] ElasticSearch + Kibana + Logstash 以及插件安装和配置
[基础服务-windows] [ELK] ElasticSearch + Kibana + Logstash 以及插件安装和配置
736 0
[基础服务-windows] [ELK] ElasticSearch + Kibana + Logstash 以及插件安装和配置
|
SQL 运维 监控
【走进RDS】之SQL Server性能诊断案例分析
数据库性能诊断不仅对其数据库技能要求较高,而且需要大量的前期准备工作,如收集各种性能基线、性能指标和慢SQL日志等,尤其是面对多数据库性能调优时,往往事倍功半。
29001 0
【走进RDS】之SQL Server性能诊断案例分析
|
SQL Go 索引
SQL Server-聚焦计算列或计算列持久化查询性能(二十二)
前言 上一节我们详细讲解了计算列以及计算列持久化的问题,本节我们依然如前面讲解来看看二者查询性能问题,简短的内容,深入的理解,Always to review the basics。 持久化计算列比非持久化计算列性能要好 我们开始创建两个一样的表并都插入100条数据来进行比较,对于计算列我们重新进行创建计算列和非计算列持久化。
1045 0
|
SQL 并行计算 Go
SQL Server-聚焦查询计划Stream Aggregate VS Hash Match Aggregate(二十)
前言 之前系列中在查询计划中一直出现Stream Aggregate,当时也只是做了基本了解,对于查询计划中出现的操作,我们都需要去详细研究下,只有这样才能对查询计划执行的每一步操作都了如指掌,所以才有了本文的出现,简短的内容,深入的理解,Always to review the basics。
1450 0