數據庫設計三年夜范式簡析。本站提示廣大學習愛好者：（數據庫設計三年夜范式簡析）文章只能為提供參考，不一定能成為您想要的結果。以下是數據庫設計三年夜范式簡析正文
為了樹立冗余較小、構造公道的數據庫，設計數據庫時必需遵守必定的規矩。在關系型數據庫中這類規矩就稱為范式。范式是相符某一種設計請求的總結。要想設計一個構造公道的關系型數據庫，必需知足必定的范式。
在現實開辟中最為罕見的設計范式有三個：
1．第一范式(確保每列堅持原子性)
第一范式是最根本的范式。假如數據庫表中的一切字段值都是弗成分化的原子值，就解釋該數據庫表知足了第一范式。
第一范式的公道遵守須要依據體系的現實需求來定。好比某些數據庫體系中須要用到“地址”這個屬性，原來直接將“地址”屬性設計成一個數據庫表的字段就行。然則假如體系常常會拜訪“地址”屬性中的“城市”部門，那末就非要將“地址”這個屬性從新拆分為省分、城市、具體地址等多個部門停止存儲，如許在對地址中某一部門操作的時刻將異常便利。如許設計才算知足了數據庫的第一范式，以下表所示。
上表所示的用戶信息遵守了第一范式的請求，如許在對用戶應用城市停止分類的時刻就異常便利，也進步了數據庫的機能。
2．第二范式(確保表中的每列都和主鍵相干)
第二范式在第一范式的基本之上更進一層。第二范式須要確保數據庫表中的每列都和主鍵相干，而不克不及只與主鍵的某一部門相干（重要針春聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能保留一種數據，弗成以把多種數據保留在統一張數據庫表中。
好比要設計一個定單信息表，由於定單中能夠會有多種商品，所以要將定單編號和商品編號作為數據庫表的結合主鍵，以下表所示。
定單信息表
如許就發生一個成績：這個表中是以定單編號和商品編號作為結合主鍵。如許在該表中商品稱號、單元、商品價錢等信息不與該表的主鍵相干，而僅僅是與商品編號相干。所以在這裡違背了第二范式的設計准繩。
而假如把這個定單信息表停止拆分，把商品信息分別到另外一個表中，把定單項目表也分別到另外一個表中，就異常完善了。以下所示。
如許設計，在很年夜水平上減小了數據庫的冗余。假如要獲得定單的商品信息，應用商品編號到商品信息表中查詢便可。
3．第三范式(確保每列都和主鍵列直接相干,而不是直接相干)
第三范式須要確保數據表中的每列數據都和主鍵直接相干，而不克不及直接相干。
好比在設計一個定單數據表的時刻，可以將客戶編號作為一個外鍵和定單表樹立響應的關系。而弗成以在定單表中添加關於客戶其它信息（好比姓名、所屬公司等）的字段。以下面這兩個表所示的設計就是一個知足第三范式的數據庫表。
如許在查詢定單信息的時刻，便可以應用客戶編號來援用客戶信息表中的記載，也不用在定單信息表中屢次輸出客戶信息的內容，減小了數據冗余。
以上就是數據庫三年夜范式的引見，願望對年夜家設計冗余較小、構造公道的數據庫有所贊助。
