前言

終于等到這一天，我要開始重新系統(tǒng)學(xué)習(xí)數(shù)據(jù)庫了，關(guān)于數(shù)據(jù)庫這塊，不出意外的話，每天會(huì)定時(shí)更新一篇且內(nèi)容不會(huì)包含太多，簡短的內(nèi)容，深入的理解。

SQL語句類別

SQL語句包括以下三個(gè)類別

（1）數(shù)據(jù)定義語言（Data Definnition Language）即DDL，我們數(shù)據(jù)最終從何而來，當(dāng)然首先必須得建立表，所以它包括CREATE、ALTER、DROP表。

（2）數(shù)據(jù)操作語言（Data Manipulation Language）即DML，我們對(duì)數(shù)據(jù)需要進(jìn)行什么操作，當(dāng)然無非就是增刪改查，所以它包括SELECT、INSERT、UPDATE、DELETE，其中還包括TRUNCATE、MERGE。

（3）數(shù)據(jù)控制語言（Data Control Language）即DCL，我們操作數(shù)據(jù)庫時(shí)針對(duì)不同的用戶會(huì)授予不同權(quán)限。

數(shù)據(jù)庫范式

范式是什么玩意，它意指規(guī)范化規(guī)則，通俗易懂一點(diǎn)講則是定義的規(guī)范、規(guī)則，需要我們?nèi)プ袷?，那么為何要定這一套規(guī)則呢？我們反過來想，肯定是前人遇到過，若不定義這一套規(guī)則，則出現(xiàn)這樣或那樣的問題，為了規(guī)避這樣問題的出現(xiàn)則出了這一套規(guī)則，主要是為了解決如下兩點(diǎn)問題。

（1）避免在數(shù)據(jù)修改過程中出現(xiàn)異常。

（2）保持?jǐn)?shù)據(jù)最低限度的冗余。

數(shù)據(jù)庫范式最基礎(chǔ)的范式為第一范式（1NF）、第二范式（2NF）、第三范式（3NF），還有更高層次的范式，但太過于復(fù)雜我們不做探討，大部分書籍都這樣說，我們就這樣去了解。

第一范式（1NF）

定義：關(guān)系表中行必須是唯一且屬性是原子性的。

太晦澀，太抽象，不太懂，我們一一來分析，我們看看上述定義中重點(diǎn)在于行【唯一】，屬性【原子性】。

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

第一：既然是唯一，那么行中某一標(biāo)識(shí)必須是已知而非未知即不能為空

第二：唯一也就是說不能重復(fù)諾

第三：怎么保證行唯一呢？通過定義一個(gè)唯一鍵來實(shí)現(xiàn)唯一行。

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

第一看到原子這個(gè)詞語是不是會(huì)立馬聯(lián)想到中國獨(dú)立研制的原子彈爆發(fā)，又或者是上化學(xué)課遇到的第一個(gè)化學(xué)式2H2+O2=2H2O，2個(gè)氫氣即4個(gè)氫原子與1個(gè)氧氣即2個(gè)氧原子集合生成1個(gè)水分子， 哦，回顧一下，分子是由原子組成，原子由原子核和核外電子組成，原子核又由質(zhì)子和中子組成，還有什么夸克之類的，無論是程序語言還是數(shù)據(jù)庫中都一直在講原子性，為什么沒有講質(zhì)子性和夸克性呢，因?yàn)樵右呀?jīng)算是比較小的，所以一直用原子性來強(qiáng)調(diào)并劃分，為了方便理解，可以這么思考，后面的就不用在敘述，到了這里還沒明白么，就相當(dāng)于原子組成分子，將原子作為最小的粒度即不能再分，那么我們反過來想屬性的原子性即屬性不可再劃分，這又是什么意思，比如在表中有一個(gè)地址屬性，如果我們存如（湖南省，岳陽市，華容縣）這樣就違背了第一范式，這個(gè)屬性還是可以再劃分為省、城市、縣。

到這里我們可以作出總結(jié)第一范式滿足的條件：

（1）唯一標(biāo)識(shí)的鍵

（2）鍵不能為空

（3）鍵不能重復(fù)

（4）屬性不可再劃分

第二范式（2NF）

定義：在滿足第一范式的前提下，每一個(gè)非鍵屬性必須滿足對(duì)整個(gè)候選鍵的完全函數(shù)依賴即非鍵屬性不能是對(duì)候選鍵某部分的完全函數(shù)依賴。

好了，我們繼續(xù)入上述解釋第一范式來解釋第二范式晦澀難懂的定義。我們看下如下表

上述定義候選鍵都是指的主鍵。上述給出表中OrderId和ProductId都是作為候選鍵即主鍵，但是此時(shí)我們可以通過部分候選鍵（主鍵）比如OrderId得到OrderDate、CustomerId和CompanyName等列，此時(shí)是僅僅是OderId的部分依賴而非對(duì)OderId和ProductId二者的完全依賴。此時(shí)為了表現(xiàn)出對(duì)候選鍵的完全依賴應(yīng)該劃分成如下兩個(gè)表。

所以將上述定義通俗講則是：屬性對(duì)主鍵應(yīng)該屬于完全依賴而非部分依賴，否則違反第二范式。

第三范式（3NF）

同樣第三范式是在滿足第一和第二范式的前提下來看第三范式。

定義：所有非鍵屬性必須依賴于非傳遞的候選鍵，也就是非鍵屬性相互之間必須相互獨(dú)立，進(jìn)一步講非鍵屬性之間不能形成依賴關(guān)系。

我們看看上述經(jīng)過修改滿足第二范式的兩個(gè)表，此時(shí)訂單表中OrderId為主鍵，客戶Id即CustomerId和公司名稱即CompanyName對(duì)OrderId是完全依賴，我們可以通過訂單Id得到客戶Id，也可以通過訂單Id得到公司名稱，同時(shí)我們也可以通過客戶Id得到客戶公司名稱，也就是說此時(shí)CustomerId和CompanyName是一種傳遞關(guān)系，而非相互之間獨(dú)立。此時(shí)若需要滿足第三范式則應(yīng)該是如下表示：

我們可以看出第三范式著重強(qiáng)調(diào)的是非鍵屬性與非鍵屬性之間獨(dú)立，而第二范式著重強(qiáng)調(diào)的是非鍵屬性與候選主鍵的完全依賴。所以第二范式和第三范式我們統(tǒng)一概括為：非鍵屬性必須是對(duì)鍵的依賴，而非相互之間依賴，并且是對(duì)整個(gè)鍵的依賴。

系統(tǒng)數(shù)據(jù)庫組成

當(dāng)打開數(shù)據(jù)庫中后在數(shù)據(jù)庫下默認(rèn)會(huì)有個(gè)系統(tǒng)數(shù)據(jù)庫，里面的內(nèi)容如下：

master

master數(shù)據(jù)庫存儲(chǔ)實(shí)例范圍的元數(shù)據(jù)信息、服務(wù)器配置、實(shí)例中的所有數(shù)據(jù)庫信息和初始化信息。

Resource

Resource數(shù)據(jù)庫是一個(gè)隱藏、只讀數(shù)據(jù)庫，存儲(chǔ)所有系統(tǒng)對(duì)象的定義。

model

model數(shù)據(jù)庫是創(chuàng)建新數(shù)據(jù)庫的模板，創(chuàng)建的每個(gè)新數(shù)據(jù)庫都是有model的副本初始化創(chuàng)建的。

tempdb

tempdb數(shù)據(jù)庫是SQL Server存儲(chǔ)臨時(shí)數(shù)據(jù)的地方，如工作表、排序空間、行版本控制信息。同時(shí)SQL Server允許我們創(chuàng)建我們自己使用的臨時(shí)表，并且這些臨時(shí)表的位置是tempdb，但是我們需要注意的是每當(dāng)重新啟動(dòng)SQL Server實(shí)例時(shí)，該數(shù)據(jù)庫將會(huì)被破壞掉，并由model副本創(chuàng)建。

msdb

msdb數(shù)據(jù)庫是SQL Server代理的服務(wù)存儲(chǔ)數(shù)據(jù)的地方，SQL Server代理負(fù)責(zé)自動(dòng)操作，包括作業(yè)、計(jì)劃和警報(bào)，同時(shí)也負(fù)責(zé)復(fù)制服務(wù)等等。

總結(jié)

本節(jié)我們著重講解了SQL語句的組成以及數(shù)據(jù)庫的三個(gè)范式，對(duì)系統(tǒng)數(shù)據(jù)庫的組成進(jìn)行簡短的介紹，屬于了解的范疇吧，今天我們先到這里，我們下節(jié)再會(huì)。

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，同時(shí)也希望多多支持腳本之家！