當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

【Normal Form】数据库表结构设计所遵从的范式

發(fā)布時間：2024/9/5 数据库 38 豆豆

生活随笔收集整理的這篇文章主要介紹了【Normal Form】数据库表结构设计所遵从的范式小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

數據庫設計是件嚴肅、關鍵的事兒，一畢業(yè)，加入一個大型的行業(yè)項目，那兒的前輩資深工程師，就給我灌輸數據庫如何關鍵、神圣、深不可測的觀念，所以，我一直懷著崇拜的眼神。

幾年前，項目經理把一個小項目的數據庫設計工作交給我，我除了花費晚上和周末去完成。后來，更由于第一次負責整個系統的數據庫設計，更請教了以前公司的架構師哥們，幫我把把關，看自己有哪些木有想到的。

后來，將設計方案通過了評審，甚是高興，畢竟自己第一次設計一個系統的表結構，盡管，是一個小系統。

那么，有了幾次數據庫表結構設計經驗，如何描述你設計表所遵循的原則呢？這時候，回歸到大學課本，就是范式（Normal Form）。

原子性，即，字段應該是不可再分的。

如，一個系統的地址用于郵寄商品，那么下表的ADDRESS是符合第一范式的。

ID	USER_NAME	AGE	PHONE	ADDRESS
1	Nick Huang	18	12345678	深圳市羅湖區(qū)地王大廈1003室

而如何判斷是否原子性，這需要根據實際的業(yè)務判斷。

比如一些系統僅根據地址作送貨服務的，則使用上述的結構即滿足第一范式；而某些系統，地址除了用于送貨，還需要對用戶所在地區(qū)分布做長期的統計，為了統計方便，上面的ADDRESS設計就不符合原子性了，也許應該為：

ID	USER_NAME	AGE	PHONE	PROVINCE	CITY	ADDRESS
1	Nick Huang	10	12345678	廣東省	深圳市	地王大廈1003室

還有其他一些典型的不符合原子性的，就是將多個數據放在一個字段中了。

如Phone字段：

ID	USER_NAME	AGE	PHONE
1	Nick Huang	10	23658745,25654150

還有這種情況，如EXT_FIELDS字段：

ID	USER_NAME	AGE	PHONE	ADDRESS	EXT_FIELDS
1	Nick Huang	10	12345678	深圳市XXX	<DATA><JOB>Programmer</JOB><PASSPORT>12345678</PASSPORT></DATA>

非主鍵必須完全依賴于主鍵，而不能只依賴于主鍵的一部分（聯合主鍵）

博文《權限管理系統概要設計》有一系列用戶權限的表，如果以此為例子，將其中的表結構設計為如下，則不符合第二范式：

USER_ID、ROLE_ID為主鍵，描述用戶和角色的關聯關系；STATUS描述這個關聯關系是生效還是失效。

可以看出，STATUS是描述這段關聯的，是依賴USER_ID、ROLE_ID的，即完全依賴于主鍵。

而USER_NAME是用戶名稱，它只依賴于USER_ID，即只依賴于主鍵的一部分。USER_NAME字段的設置不符合第二范式。

如果有一天，用戶的名稱需要修改，那么就要修改與此用戶相關的每一筆關聯的數據。

非主鍵必須直接依賴于主鍵，而不是傳遞依賴或間接依賴。

博文《權限管理系統概要設計》有一系列用戶權限的表，如果以此為例子，將其中的表結構設計為如下，則不符合第三范式：

此為角色表，ID為角色ID，NAME為角色名稱，STATUS為此角色是否生效，SYSTEM_ID為此角色所屬的系統ID，SYSTEM_NAME為此角色所屬的系統的名稱。

可以看出SYSTEM_NAME為傳遞依賴，在角色表中SYSTEM_ID依賴與ID，而SYSTEM_NAME有依賴與SYSTEM_ID。SYSTEM_NAME字段的設置不符合第三范式。

是不是數據庫設計一定得嚴格遵守3范式呢？

這不一定，要視具體情況，實際上，常見許多情況故意設置冗余字段使系統查詢更高效、更方便。

轉載于:https://www.cnblogs.com/CandiceW/p/10033424.html

以上是生活随笔為你收集整理的【Normal Form】数据库表结构设计所遵从的范式的全部內容，希望文章能夠幫你解決所遇到的問題。

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