我們讀不同的描寫數據庫的文章，會看到不同的概念名稱，從某種意義上來講，是公說公有理，婆說婆有理的問題，只是個人理解不同而稱呼有異，這也給一些人，尤其是初學者帶來一定的困擾，鑒于此，特整理《數據庫常用專業術語的基本概念的定義與理解》這篇文章，行文參考了很多網上的資料(請原諒我不喜歡看書)，并加入了我自己的理解，如有謬誤，請指正。

實體

實體是指現實世界中客觀存在的并可以相互區分的對象或事物。至于如何定義一個實體，則會根據不同的需要，不同的視角有所不同，比如我們將生物作為實體，那么我們就考慮這個實體有哪些屬性，首先生物是生命體，其次可繁殖等等，也可以將某一種生物當作一個實體看待，比如人這種生物，按照人種這一屬性，可以分為黃色人種、亞美人種、蒙古人種、蒙古利亞人種等。就數據庫而言，實體往往指某類事物的集合。也就是數據庫表，可以是具體的人、事、物，也可以是抽象的概念、

實體屬性

屬性是實體之間相互區分的最基本特征，是對象或事物具象的描述。比如有兩個人，一個姓名叫張三、一個叫姓名李四，那么姓名就是張三、李四這兩個實體相互區分的屬性。值得注意的是，實體屬性依然會根據我們視角的不同而有不同的劃分。

數據庫

數據庫就是存儲數據的倉庫，其本質是一個文件系統，數據按照特定的格式將數據存儲起來，可視為電子化的文件倉庫。數據庫分為關系數據庫與非關系數據庫(NoSql數據庫)。數據庫實現了數據的新增、查詢、更新、刪除等操作，并提供了完善的數據管理相關的功能，如權限、事務等，并定義了表(實體)與表(實體)之間的關系。

數據庫中以表為組織單位存儲數據。表與實體之間應該是一一對應的關系，可以把表當作實體在數據庫中的描述。數據庫表描述的實體是具有一些列共同實體屬性的數據的集合，比如學生表，描述了學生這一實體，而學校表描述了學校這一實體，將學生與學校分別建表存儲。這里容易讓人迷糊的是在個別時候，數據表中的一行記錄也被叫做實體，這個確實也是對的，這是因為將學生看作實體與將某一個學生看作一個實體的時候我們的視角不一樣了。是不是感覺很隨意？是的就是這么隨意。

字段

字段是數據表中實體所具有的某一特性，在關系數據庫中，屬性可以看作是“表的一列”。如上面學生這一尸體可能具有姓名、性別、年齡、愛好等屬性，對應到學生表中則是姓名、性別、年齡、愛好等字段。

元組(記錄/行)

表中的一行記錄就是一個元組，元組也稱為行。

分量(字段/屬性)

元組的某個屬性值叫做分量，實際上就是數據庫中的字段，也即實體的屬性。在一個關系數據庫中，它是一個操作原子，即關系數據庫在做任何操作的時候，屬性是“不可分的”。否則就能滿足數據庫范式。

碼(主鍵、主關鍵字)

碼也就是我們常說的主鍵、主關鍵字，他們都是一個意思。

碼是能唯一標識實體的屬性，它是整個實體集的性質，而不是單個實體的性質。它包括外碼、候選碼和主碼。表中可以唯一確定一個元組的某個屬性(或者屬性組)，如果這樣的碼有不止一個，那么大家都叫 候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。

如果一個碼包含了所有的屬性，這個碼就是全碼。

一個屬性只要在任何一個候選碼中出現過，這個屬性就是主屬性

一個屬性(或屬性組)，它不是碼，但是它別的表的碼，它就是外碼。

若關系中的某一屬性或屬性組的值能唯一的標識一個元組，而其任何真子集都不能再標識，則稱該屬性組為(超級碼)候選碼。

數據完整性約束

數據完整性約束指的是為了防止不符合規范的數據進入數據庫，在用戶對數據進行插入、修改、刪除等操作時，DBMS自動按照一定的約束條件對數據進行監測，使不符合規范的數據不能進入數據庫，以確保數據庫中存儲的數據正確、有效、相容。

我們常見的有：

not null(非空)約束：定義字段不能為空值，如果新增數據非空約束的字段值為空，則不能寫入并報錯。

unique(惟一)約束：用于指明創建惟一約束的列上的取值必須惟一。

primary key(主鍵)約束：用于定義基本表的主鍵，起唯一標識作用，其值不能為null,也不能重復，以此來保證實體的完整性。

foreign key(外鍵)約束：定義了一個表中數據與另一個表中的數據的聯系。

check(校驗)約束：用來檢查字段值所允許的范圍。DBMS每當執行delete,insert或update語句時，都對這個約束過濾。如果為true，則執行。否則，取消執行并提示錯誤。

依賴關系

數據依賴是一個數學概念，是通過一個關系中屬性間值的相等與否體現出來的數據間的相互關系，數據依賴是現實世界屬性間相互聯系的抽象，屬于數據內在的性質。在計算機科學中，數據依賴是指一種狀態，當程序結構導致數據引用之前處理過的數據時的狀態。

復雜的數學公式推導有興趣的朋友可以自行查看。

簡單來說在數據庫中依賴關系就是描述數據庫不同字段(屬性)之間的關系。比如管理員id 依賴倉庫id， 物品id 依賴倉庫id。在這個以來關系中管理員id 到物品id是存在依賴關系的，依賴關系對于理解數據庫范式很重要。

部分依賴

部分函數依賴：設X,Y是關系R的兩個屬性集合，存在X→Y，若X’是X的真子集，存在X’→Y，則稱Y部分函數依賴于X。

舉個例子：學生基本信息表R中（學號，身份證號，姓名）當然學號屬性取值是唯一的，在R關系中，（學號，身份證號）->（姓名），（學號）->（姓名），（身份證號）->（姓名）；所以姓名部分函數依賴與（學號，身份證號）；

完全依賴

完全函數依賴：設X,Y是關系R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函數依賴于X。
例子：學生基本信息表R（學號，班級，姓名）假設不同的班級學號有相同的，班級內學號不能相同，在R關系中，（學號，班級）->（姓名），但是（學號）->(姓名)不成立，（班級）->(姓名)不成立，所以姓名完全函數依賴與（學號，班級）；

傳遞依賴

傳遞函數依賴：設X,Y,Z是關系R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函數依賴于X。
例子：在關系R(學號 ,宿舍, 費用)中，(學號)->(宿舍),宿舍！=學號，(宿舍)->(費用),費用!=宿舍，所以符合傳遞函數的要求；

范式

英文名稱是 Normal Form，它是英國人 E.F.Codd(關系數據庫的老祖宗)在上個世紀70年代提出關系數據庫模型后總結出來的，范式是關系數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。

在使用mysql中對表的設計，我們需要遵循三大范式。設計關系型數據庫時，遵從不同的規范和要求，設計出合理的關系型數據庫，這些不同的規范和要求稱為不同的范式。各種范式呈遞次規范，越高的范式數據庫冗余越小。但也意味著數據庫表關系越復雜。

若要遵循后面的范式必須遵循之前的范式。1NF<2NF<3NF<…>

目前關系數據庫有六種范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF，又稱完美范式)。

巴斯-科德范式因為并沒有定義新的規范，只是對第三范式(3NF)的補充與完善，所以并沒有命名為第四范式。

通常所用到的只是前三個范式，即：第一范式(1NF)，第二范式(2NF)，第三范式(3NF)。也即我們常說的設計數據庫的三大范式。
1NF 一言以蔽之：“第一范式的數據表必須是二維數據表”，第一范式是指數據庫的每一列都是不可分割的基本數據項，強調列的原子性，試題中某一屬性不能擁有幾個值。比如數據庫的電話號碼屬性里面不可以有固定電話和移動電話值，如下圖：

說明：在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。
再例如：

列1唯一確定列2, 列3, 列4, ...，即列2, 列3, 列4, ...不能再分裂出其它列。

假設有關系模式列1: 訂單名; 列2: 商品。一個訂單下可以有多個商品，即列2: 商品可以分裂成商品A, 商品B, 商品C, ...，所以列1: 訂單名; 列2: 商品這樣的關系模式不符合第一范式。

2NF

滿足2NF的前提是必須滿足1NF。此外，關系模式需要包含兩部分內容，一是必須有一個（及以上）主鍵；二是沒有包含在主鍵中的列必須全部依賴于全部主鍵，而不能只依賴于主鍵的一部分而不依賴全部主鍵。

定義聽起來有點繞，不慌，直接看上圖，只有全部的非主鍵列依賴于全部主鍵，才滿足第二范式。

3NF 若某一范式是第二范式，且每一個非主屬性都不傳遞依賴于該范式的候選鍵，則稱為第三范式，即不能存在：非主鍵列 A 依賴于非主鍵列 B，非主鍵列 B 依賴于主鍵的情況。

舉例來說：Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)，當員工表中emp_id能夠唯一確定員工員工信息，但是dept_name可由dept_id唯一確定，此時，該表不符合第三范式，此時可以刪除除了dept_id之外的其他部門信息，把所有部門信息單獨建立一張部門表。

再例如：
滿足3NF的前提是必須滿足2NF。另外關系模式的非主鍵列必須直接依賴于主鍵，不能存在傳遞依賴。即不能存在：非主鍵列m既依賴于全部主鍵，又依賴于非主鍵列n的情況。

定義聽起來還是有點繞，不慌，直接看上圖，只要非主鍵內部存在傳遞依賴，就不滿足第三范式。

假設存在關系模式主鍵1: 課程編號; 列1: 教師名; 列2: 教師家庭地址。顯然滿足第一范式和第二范式，但是教師家庭地址傳遞依賴于教師名，所以不滿足第三范式。

示例:

設有課程關系模式如下：R(C#, Cn, T, Ta)（其中C#為課程號，Cn為課程名，T為教師名，Ta為教師地址），并且假定不同的課程號可以有相同的課程名，每門課程只有一位任課教師，但每名教師可以有多門課程。關系R范式最高達到（）。

A）1NF
B）2NF
C）3NF
D）BCNF

【正確答案】B

【解析】

一個“課程號”確定一個“課程名”，確定一個“教師名”，確定一個“教師地址”，所以符合第一范式；

“課程號”是無重復的，所以“課程號”是主鍵，“課程名”、“教師名”、“教師地址”均是可重復的，所以它們都是非主鍵列并完全依賴于主鍵“課程號”，所以符合第二范式；

非主鍵列“教師地址”傳遞依賴于非主鍵列“教師名”，所以不符合第三范式，故選B。

BCNF 在第三范式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。

（1）所有非主屬性對每一個碼都是完全函數依賴；
（2）所有的主屬性對于每一個不包含它的碼，也是完全函數依賴；
（3）沒有任何屬性完全函數依賴于非碼的任意一個組合。

R屬于3NF，不一定屬于BCNF，如果R屬于BCNF，一定屬于3NF。

假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系：

(倉庫ID, 存儲物品ID) →(管理員ID, 數量)

(管理員ID, 存儲物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三范式的。但是，由于存在如下決定關系：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

即存在關鍵字段決定關鍵字段的情況，所以其不符合BCNF范式。

非關系數據庫

各個數據之間存在關聯是關系型數據庫得名的主要原因，為了進行join處理，關系型數據庫不得不把數據存儲在同一個服務器內，這不利于數據的分散，這也是關系型數據庫并不擅長大數據量的寫入處理的原因。相反NoSQL數據庫原本就不支持Join處理，各個數據都是獨立設計的，很容易把數據分散在多個服務器上，故減少了每個服務器上的數據量，即使要處理大量數據的寫入，也變得更加容易，數據的讀入操作當然也同樣容易。

關系型數據庫應用廣泛，能進行事務處理和表連接等復雜查詢。相對地，NoSQL數據庫只應用在特定領域，基本上不進行復雜的處理，但它恰恰彌補了之前所列舉的關系型數據庫的不足之處。

典型的NoSQL數據庫：臨時性鍵值存儲(memcached、Redis)、永久性鍵值存儲(ROMA、Redis)、面向文檔的數據庫(MongoDB、CouchDB)、面向列的數據庫(Cassandra、HBase)。

整篇參考自https://blog.csdn.net/weixin_39755003/article/details/110619027
https://blog.csdn.net/u014458048/article/details/56678698
https://blog.csdn.net/weixin_43971764/article/details/88677688
https://blog.csdn.net/weixin_28745975/article/details/113140462

總結

以上是生活随笔為你收集整理的数据库中的实体、元组、字段、属性、码、分量、依赖关系、完全部份传递依赖、范式等你了解吗？【笔记自用】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。