要說數據庫什麼最抽象，我覺得就是這個三範式，不是很好理解，但是表在設計的時候又必須要知道這麼一個規則。
首先使用最簡潔的話說說這三範式：
第一範式（1NF:The First Normal Form）：每一列不能再分割。
第二範式（2NF:The Second Normal Form）：滿足1NF條件下，每一列非主鍵列要完全依賴主鍵，不能只依賴聯合主鍵中的一部分（因爲主鍵可能是聯合主鍵，有多列的，必須所有字段都用上 ）
第三範式（3NF:The Third Normal Form）：滿足2NF條件下，非主鍵的列不能依賴於非主鍵的列；
看到這三句話肯定不理解，於是，我們用圖來理解一下
1.第一範式
簡單的來說就是不能建立下面這樣的表，可以看到地址這一列是可以分割的；
一般只要是關係型數據庫建立的表都會滿足第一範式的。
2.第二範式
看下面這個表，這裏聯合主鍵是（學號，科目），只有確定了這兩個值，才能確定其他的列；比如分數，如果只依賴學號，那麼當學號爲1的時候，分數有兩個，不能唯一確定；如果只依賴科目，當科目爲語文的時候，分數也對應有兩個；
注意上面這個表中的姓名，它只是依賴學號的，根據學號就可以找對唯一對應的姓名，所以這時非主鍵列 “姓名” 部分依賴於聯合主鍵“學號，科目”，不是完全依賴，所以不滿足第二範式；
我們需要將姓名這一列給提取出來，下表所示，對於完全依賴主鍵的放在一張表中，展示依賴一部分主鍵的放在另外一張表中；
3.第三範式
什麼叫做非主鍵列不能依賴非主鍵列呢？看着就看不懂...
不要急，我們再看一張表：
我們可以知道系名可以依賴學號，畢竟一個學生肯定對應着唯一的系，但是系主任呢？系主任肯定是依賴於系名的，不可能依賴某個學生吧，所以有這樣的一個依賴關係：學號->系名->系主任，系主任間接依賴於主鍵，這是不滿足第三範式的；
所以我們需要將系主任給拿出來，單獨弄一張表：
以上就是我對三範式的理解，看了一些視頻和找了一些博客總結一下的吧，其實可以使用更加專業的話來說三範式的，有興趣的可以看看這個老哥的博客，傳送門╮(╯_╰)╭ ，這個就比較專業了，哈哈
4.反三範式
按理來說按照三範式設計數據庫之後，可以避免冗餘數據，使得數據庫結構很精簡；但是有時這樣的設計會使得查詢表的時候需要進行關聯查詢，比如上面說第二範式的時候，姓名那裏就不需要單獨弄張表出來；
單獨弄張表出來，如果有個需求要查詢一個學生的名字，科目和分數，你就需要關聯查詢一下；但是不單獨弄張表出來，你只需要查詢一次就夠了；
所以適當的冗餘數據是可以接受的，而且可以提高查詢效率，不應該爲了遵守三範式而創建設計表，應該衡量自己項目的實際需要，在三範式和反三範式之間做權衡。
我這裏也就是大概講了一下我的理解，肯定有的地方不是很正確，哈哈哈，實際的項目中表肯定是非常複雜的，那就要多分析了╮(╯_╰)╭