資料庫難懂

㈠ 大家為什麼都說說OceanBase4.0開啟了國產資料庫新的里程碑

OceanBase 4.0重新審視資料庫與分布式系統兩個領域最基礎的設計，全新推出業內首個單機分布式一體化架構。在單機部署時，自適應日誌流技術將只觸發一個日誌流，用戶操作不需要分布式事務，不損失性能。需要分布式部署時，自適應日誌流技術將會為每台機器觸發專屬的日誌流。實現多機性能自動擴展。可以說OceanBase 4.0打破了分布式技術的不可能，實現了首個單機分布式體化架構，真正做到可以像單機資料庫一樣使用。

針對這一現狀，有這么一群人從開始放棄了在互聯網大廠的高薪工作，歷經十餘年在分布式資料庫的深耕取得了一個又一個突破。從0到1開創原生分布式資料庫，堅持自主研發，堅持長期主義，堅持開放，從根本上去解決海量數據管理的問題。歷經12年時間，OceanBase4.0通過海量的業務場景打磨，產品不斷選代，使用成本得到極大降低，部署更加便捷。OceanBase4.0開啟了國產資料庫新的里程碑。可單機可分布，可大可小，跟火影忍者一樣，可合體可分散。

在成本上比傳統資料庫低50-70%大大降低中小企業的替換成本近年來數字經濟迅猛發展，中小企業更加迫切的需要進行數字化轉型。如何降低數字化進程中的成本，不僅是中小企業考慮的重要問題，也是OceanBase力求達到的目的。基於LSM-Tree的高壓縮引擎，OceanBase 4.0實現存儲成本降低70%-90%；以支付寶為例，用OceanBase原生分布式資料庫替代Oracle資料庫之後，單副本數據可以做到Oracle的1/7，其計算資源投入也降低為原來的1/12，相比Oracle，僅存儲一項，相比Oracle節省存儲成本約20億元，相當於每賬戶成本節省了90%。

首次將故障恢復時間從30秒降低到8秒現在的數據中心對業務的連續性有苛刻要求，但是故障往往是不可避免的。一旦發生了故障就需要啟動備份機制，確保業務的連續性。OceanBase4.0首次實現了RTO<8s，真正將故障恢復時間從分鍾級（30s）降低到秒級（8s），幫助業務系統更快恢復，最大程度減少業務影響，給業務帶來持續可用的能力。

㈡ 求資料庫應用題

資料庫語言的目標

要說清這個目標，先要理解資料庫是做什麼的。

資料庫這個軟體，名字中有個「庫」字，會讓人覺得它主要是為了存儲的。其實不然，資料庫實現的重要功能有兩條：計算、事務！也就是我們常說的 OLAP 和 OLTP，資料庫的存儲都是為這兩件事服務的，單純的存儲並不是資料庫的目標。

我們知道，SQL 是目前資料庫的主流語言。那麼，用 SQL 做這兩件事是不是很方便呢？

事務類功能主要解決數據在寫入和讀出時要保持的一致性，實現這件事的難度並不小，但對於應用程序的介面卻非常簡單，用於操縱資料庫讀寫的代碼也很簡單。如果假定目前關系資料庫的邏輯存儲模式是合理的（也就是用數據表和記錄來存儲數據，其合理性與否是另一個復雜問題，不在這里展開了），那麼 SQL 在描述事務類功能時沒什麼大問題，因為並不需要描述多復雜的動作，復雜性都在資料庫內部解決了。

但計算類功能卻不一樣了。

這里說的計算是個更廣泛的概念，並不只是簡單的加加減減，查找、關聯都可以看成是某種計算。

什麼樣的計算體系才算好呢？

還是兩條：寫著簡單、跑得快。

寫著簡單，很好理解，就是讓程序員很快能寫出來代碼來，這樣單位時間內可以完成更多的工作；跑得快就更容易理解，我們當然希望更短時間內獲得計算結果。

其實 SQL 中的 Q 就是查詢的意思，發明它的初衷主要是為了做查詢（也就是計算），這才是 SQL 的主要目標。然而，SQL 在描述計算任務時，卻很難說是很勝任的。

SQL為什麼不行

先看寫著簡單的問題。

SQL 寫出來很象英語，有些查詢可以當英語來讀和寫（網上多得很，就不舉例了），這應當算是滿足寫著簡單這一條了吧。

且慢！我們在教科書上看到的 SQL 經常只有兩三行，這些 SQL 確實算是寫著簡單的，但如果我們嘗試一些稍復雜化的問題呢？

這是一個其實還不算很復雜的例子：計算一支股票最長連續上漲了多少天？用 SQL 寫出來是這樣的：

• selectmax(consecutive_day)from(selectcount(*) (consecutive_dayfrom(selectsum(rise_mark) over(orderbytrade_date) days_no_gainfrom(selecttrade_date,case when closing_price>lag(closing_price) over(order by trade_date)then 0 else 1 END rise_markfrom stock_price ) )group by days\_no\_gain)



這個語句的工作原理就不解釋了，反正有點繞，同學們可以自己嘗試一下。

這是潤乾公司的招聘考題，通過率不足 20%；因為太難，後來被改成另一種方式：把 SQL 語句寫出來讓應聘者解釋它在算什麼，通過率依然不高。

這說明什麼？說明情況稍有復雜，SQL 就變得即難懂又難寫！

再看跑得快的問題，還是一個經常拿出來的簡單例子：1 億條數據中取前 10 名。這個任務用 SQL 寫出來並不復雜：

• SELECTTOP 10x FROMT ORDERBYx DESC



但是，這個語句對應的執行邏輯是先對所有數據進行大排序，然後再取出前 10 個，後面的不要了。大家知道，排序是一個很慢的動作，會多次遍歷數據，如果數據量大到內存裝不下，那還需要外存做緩存，性能還會進一步急劇下降。如果嚴格按這句 SQL 體現的邏輯去執行，這個運算無論如何是跑不快的。然而，很多程序員都知道這個運算並不需要大排序，也用不著外存緩存，一次遍歷用一點點內存就可以完成，也就是存在更高性能的演算法。可惜的是，用 SQL 卻寫不出這樣的演算法，只能寄希望於資料庫的優化器足夠聰明，能把這句 SQL 轉換成高性能演算法執行，但情況復雜時資料庫的優化器也未必靠譜。

看樣子，SQL 在這兩方面做得都不夠好。這兩個並不復雜的問題都是這樣，現實中數千行的 SQL 代碼中，這種難寫且跑不快的情況比比皆是。

為什麼 SQL 不行呢？

要回答這個問題，我們要分析一下用程序代碼實現計算到底是在干什麼。

本質上講，編寫程序的過程，就是把解決問題的思路翻譯成計算機可執行的精確化形式語言的過程。舉例來說，就象小學生解應用題，分析問題想出解法之後，還要列出四則運算表達式。用程序計算也是一樣，不僅要想出解決問題的方法，還要把解法翻譯成計算機能理解執行的動作才算完成。

用於描述計算方法的形式語言，其核心在於所採用的代數體系。所謂代數體系，簡單說就是一些數據類型和其上的運算規則，比如小學學到的算術，就是整數和加減乘除運算。有了這套東西，我們就能把想做的運算用這個代數體系約定的符號寫出來，也就是代碼，然後計算機就可以執行了。

如果這個代數體系設計時考慮不周到，提供的數據類型和運算不方便，那就會導致描述演算法非常困難。這時候會發生一個怪現象：翻譯解法到代碼的難度遠遠超過解決問題本身。

舉個例子，我們從小學慣用阿拉伯數字做日常計算，做加減乘除都很方便，所有人都天經地義認為數值運算就該是這樣的。其實未必！估計很多人都知道還有一種叫做羅馬數字的東西，你知道用羅馬數字該怎麼做加減乘除嗎？古羅馬人又是如何上街買菜的？

代碼難寫很大程度是代數的問題。

再看跑不快的原因。

軟體沒辦法改變硬體的性能，CPU 和硬碟該多快就是多快。不過，我們可以設計出低復雜度的演算法，也就是計算量更小的演算法，這樣計算機執行的動作變少，自然也就會快了。但是，光想出演算法還不夠，還要把這個演算法用某種形式語言寫得出來才行，否則計算機不會執行。而且，寫起來還要比較簡單，都要寫很長很麻煩，也沒有人會去用。所以呢，對於程序來講，跑得快和寫著簡單其實是同一個問題，背後還是這個形式語言採用的代數的問題。如果這個代數不好，就會導致高性能演算法很難實現甚至實現不了，也就沒辦法跑得快了。就象上面說的，用 SQL 寫不出我們期望的小內存單次遍歷演算法，能不能跑得快就只能寄希望於優化器。

我們再做個類比：

上過小學的同學大概都知道高斯計算 1+2+3+…+100 的小故事。普通人就是一步步地硬加 100 次，高斯小朋友很聰明，發現 1+100=101、2+99=101、…、50+51=101，結果是 50 乘 101，很快算完回家午飯了。

聽過這個故事，我們都會感慨高斯很聰明，能想到這么巧妙的辦法，即簡單又迅速。這沒有錯，但是，大家容易忽略一點：在高斯的時代，人類的算術體系（也是一個代數）中已經有了乘法！象前面所說，我們從小學習四則運算，會覺得乘法是理所當然的，然而並不是！乘法是後於加法被發明出來的。如果高斯的年代還沒有乘法，即使有聰明的高斯，也沒辦法快速解決這個問題。

目前主流資料庫是關系資料庫，之所以這么叫，是因為它的數學基礎被稱為關系代數，SQL 也就是關系代數理論上發展出來的形式語言。

現在我們能回答，為什麼 SQL 在期望的兩個方面做得不夠好？問題出在關系代數上，關系代數就像一個只有加法還沒發明乘法的算術體系，很多事做不好是必然的。

關系代數已經發明五十年了，五十年前的應用需求以及硬體環境，和今天比的差異是很巨大了，繼續延用五十年前的理論來解決今天的問題，聽著就感覺太陳舊了？然而現實就是這樣，由於存量用戶太多，而且也還沒有成熟的新技術出現，基於關系代數的 SQL，今天仍然是最重要的資料庫語言。雖然這幾十年來也有一些改進完善，但根子並沒有變，面對當代的復雜需求和硬體環境，SQL 不勝任也是情理之中的事。

而且，不幸的是，這個問題是理論上的，在工程上無論如何優化也無濟於事，只能有限改善，不能根除。不過，絕大部分的資料庫開發者並不會想到這一層，或者說為了照顧存量用戶的兼容性，也沒打算想到這一層。於是，主流資料庫界一直在這個圈圈裡打轉轉。

SPL為什麼能行

那麼該怎樣讓計算寫著更簡單、跑得更快呢？

發明新的代數！有「乘法」的代數。在其基礎上再設計新的語言。

這就是 SPL 的由來。它的理論基礎不再是關系代數，稱為離散數據集。基於這個新代數設計的形式語言，起名為SPL（Structured Process Language)。

SPL 針對 SQL 的不足（更確切地說法是，離散數據集針對關系代數的各種缺陷）進行了革新。SPL 重新定義了並擴展許多結構化數據中的運算，增加了離散性、強化了有序計算、實現了徹底的集合化、支持對象引用、提倡分步運算。

限於篇幅，這里不能介紹 SPL（離散數據集）的全貌。我們在這里列舉 SPL（離散數據集）針對 SQL（關系代數）的部分差異化改進：

游離記錄

離散數據集中的記錄是一種基本數據類型，它可以不依賴於數據表而獨立存在。數據表是記錄構成的集合，而構成某個數據表的記錄還可以用於構成其它數據表。比如過濾運算就是用原數據表中滿足條件的記錄構成新數據表，這樣，無論空間佔用還是運算性能都更有優勢。

關系代數沒有可運算的數據類型來表示記錄，單記錄實際上是只有一行的數據表，不同數據表中的記錄也不能共享。比如，過濾運算時會復制出新記錄來構成新數據表，空間和時間成本都變大。

特別地，因為有游離記錄，離散數據集允許記錄的欄位取值是某個記錄，這樣可以更方便地實現外鍵連接。

有序性

關系代數是基於無序集合設計的，集合成員沒有序號的概念，也沒有提供定位計算以及相鄰引用的機制。SQL 實踐時在工程上做了一些局部完善，使得現代 SQL 能方便地進行一部分有序運算。

離散數據集中的集合是有序的，集合成員都有序號的概念，可以用序號訪問成員，並定義了定位運算以返回成員在集合中的序號。離散數據集提供了符號以在集合運算中實現相鄰引用，並支持針對集合中某個序號位置進行計算。

有序運算很常見，卻一直是 SQL 的困難問題，即使在有了窗口函數後仍然很繁瑣。SPL 則大大改善了這個局面，前面那個股票上漲的例子就能說明問題。

離散性與集合化

關系代數中定義了豐富的集合運算，即能將集合作為整體參加運算，比如聚合、分組等。這是 SQL 比 Java 等高級語言更為方便的地方。

但關系代數的離散性非常差，沒有游離記錄。而 Java 等高級語言在這方面則沒有問題。

離散數據集則相當於將離散性和集合化結合起來了，既有集合數據類型及相關的運算，也有集合成員游離在集合之外單獨運算或再組成其它集合。可以說 SPL 集中了 SQL 和 Java 兩者的優勢。

有序運算是典型的離散性與集合化的結合場景。次序的概念只有在集合中才有意義，單個成員無所謂次序，這里體現了集合化；而有序計算又需要針對某個成員及其相鄰成員進行計算，需要離散性。

在離散性的支持下才能獲得更徹底的集合化，才能解決諸如有序計算類型的問題。

離散數據集是即有離散性又有集合化的代數體系，關系代數只有集合化。

分組理解

分組運算的本意是將一個大集合按某種規則拆成若干個子集合，關系代數中沒有數據類型能夠表示集合的集合，於是強迫在分組後做聚合運算。

離散數據集中允許集合的集合，可以表示合理的分組運算結果，分組和分組後的聚合被拆分成相互獨立的兩步運算，這樣可以針對分組子集再進行更復雜的運算。

關系代數中只有一種等值分組，即按分組鍵值劃分集合，等值分組是個完全劃分。

離散數據集認為任何拆分大集合的方法都是分組運算，除了常規的等值分組外，還提供了與有序性結合的有序分組，以及可能得到不完全劃分結果的對位分組。

聚合理解

關系代數中沒有顯式的集合數據類型，聚合計算的結果都是單值，分組後的聚合運算也是這樣，只有 SUM、COUNT、MAX、MIN 等幾種。特別地，關系代數無法把 TOPN 運算看成是聚合，針對全集的 TOPN 只能在輸出結果集時排序後取前 N 條，而針對分組子集則很難做到 TOPN，需要轉變思路拼出序號才能完成。

離散數據集提倡普遍集合，聚合運算的結果不一定是單值，仍然可能是個集合。在離散數據集中，TOPN 運算和 SUM、COUNT 這些是地位等同的，即可以針對全集也可以針對分組子集。

SPL 把 TOPN 理解成聚合運算後，在工程實現時還可以避免全量數據的排序，從而獲得高性能。而 SQL 的 TOPN 總是伴隨 ORDER BY 動作，理論上需要大排序才能實現，需要寄希望於資料庫在工程實現時做優化。

有序支持的高性能

離散數據集特別強調有序集合，利用有序的特徵可以實施很多高性能演算法。這是基於無序集合的關系代數無能為力的，只能寄希望於工程上的優化。

下面是部分利用有序特徵後可以實施的低復雜度運算：

1) 數據表對主鍵有序，相當於天然有一個索引。對鍵欄位的過濾經常可以快速定位，以減少外存遍歷量。隨機按鍵值取數時也可以用二分法定位，在同時針對多個鍵值取數時還能重復利用索引信息。

2) 通常的分組運算是用 HASH 演算法實現的，如果我們確定地知道數據對分組鍵值有序，則可以只做相鄰對比，避免計算 HASH 值，也不會有 HASH 沖突的問題，而且非常容易並行。

3) 數據表對鍵有序，兩個大表之間對位連接可以執行更高性能的歸並演算法，只要對數據遍歷一次，不必緩存，對內存佔用很小；而傳統的 HASH 值分堆方法不僅比較復雜度高，需要較大內存並做外部緩存，還可能因 HASH 函數不當而造成二次 HASH 再緩存。

4) 大表作為外鍵表的連接。事實表小時，可以利用外鍵表有序，快速從中取出關聯鍵值對應的數據實現連接，不需要做 HASH 分堆動作。事實表也很大時，可以將外鍵表用分位點分成多個邏輯段，再將事實表按邏輯段進行分堆，這樣只需要對一個表做分堆，而且分堆過程中不會出現 HASH 分堆時的可能出現的二次分堆，計算復雜度能大幅下降。

其中 3 和 4 利用了離散數據集對連接運算的改造，如果仍然延用關系代數的定義（可能產生多對多），則很難實現這種低復雜的演算法。

除了理論上的差異， SPL 還有許多工程層面的優勢，比如更易於編寫並行代碼、大內存預關聯提高外鍵連接性能等、特有的列存機制以支持隨意分段並行等。

再把前面的問題用 SPL 重寫一遍有個直接感受。

一支股票最長連續上漲多少天：

• stock_price.sort(trade_date).group@o(closing_price



計算思路和前面的 SQL 相同，但因為引入了有序性後，表達起來容易多了，不再繞了。

1 億條數據中取前 10 名：

• T.groups(;top(-10,x))



SPL 有更豐富的集合數據類型，容易描述單次遍歷上實施簡單聚合的高效演算法，不涉及大排序動作。

這里還有更多 SPL 代碼以體現其思路及大數據演算法：

重磅！開源SPL交流群成立了

簡單好用的SPL開源啦！

為了給感興趣的小夥伴們提供一個相互交流的平台，

特地開通了交流群（群完全免費，不廣告不賣課）

需要進群的朋友，可長按掃描下方二維碼

㈢ 資料庫三大範式究竟是什麼

資料庫範式1NF 2NF 3NF BCNF(實例）
設計範式（範式,資料庫設計範式,資料庫的設計範式）是符合某一種級別的關系模式的集合。構造資料庫必須遵循一定的規則。在關系資料庫中，這種規則就是範式。關系資料庫中的關系必須滿足一定的要求，即滿足不同的範式。目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、第四範式（4NF）、第五範式（5NF）和第六範式（6NF）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。下面我們舉例介紹第一範式（1NF）、第二範式（2NF）和第三範式（3NF）。
在創建一個資料庫的過程中，范化是將其轉化為一些表的過程，這種方法可以使從資料庫得到的結果更加明確。這樣可能使資料庫產生重復數據，從而導致創建多餘的表。范化是在識別資料庫中的數據元素、關系，以及定義所需的表和各表中的項目這些初始工作之後的一個細化的過程。
下面是范化的一個例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面這個表用於保存物品的價格，而你想要刪除其中的一個顧客，這時你就必須同時刪除一個價格。范化就是要解決這個問題，你可以將這個表化為兩個表，一個用於存儲每個顧客和他所買物品的信息，另一個用於存儲每件產品和其價格的信息，這樣對其中一個表做添加或刪除操作就不會影響另一個表。
關系資料庫的幾種設計範式介紹

1 第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。

2 第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。

3 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
資料庫設計三大範式應用實例剖析
資料庫的設計範式是資料庫設計所需要滿足的規范，滿足這些規范的資料庫是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
設計範式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照範式來設計資料庫。
實質上，設計範式用很形象、很簡潔的話語就能說清楚，道明白。本文將對範式進行通俗地說明，並以筆者曾經設計的一個簡單論壇的資料庫為例來講解怎樣將這些範式應用於實際工程。
範式說明
第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。
例如，如下的資料庫表是符合第一範式的：
欄位1 欄位2 欄位3 欄位4
而這樣的資料庫表是不符合第一範式的：

欄位1 欄位2 欄位3 欄位4
欄位3.1 欄位3.2
很顯然，在當前的任何關系資料庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫，因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫都是不可能的。
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個資料庫表不滿足第二範式，因為存在如下決定關系：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的欄位決定非關鍵字的情況。
由於不符合2NF，這個選課關系表會存在如下問題：
(1) 數據冗餘：
同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
(2) 更新異常：
若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：
假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。
(4) 刪除異常：
假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關系表SelectCourse改為如下三個表：
學生：Student(學號, 姓名, 年齡)；
課程：Course(課程名稱, 學分)；
選課關系：SelectCourse(學號, 課程名稱, 成績)。
這樣的資料庫表是符合第二範式的， 消除了數據冗餘、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的資料庫表都符合第二範式，因為不可能存在組合關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：
關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)
這個資料庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：
(學號) → (所在學院) → (學院地點, 學院電話)
即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關系表分為如下兩個表：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 地點, 電話)。
這樣的資料庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。
假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫表中存在如下決定關系：
(倉庫ID, 存儲物品ID) →(管理員ID, 數量)
(管理員ID, 存儲物品ID) → (倉庫ID, 數量)
所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：
(1) 刪除異常：
當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常：
當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。
(3) 更新異常：
如果倉庫換了管理員，則表中所有行的管理員ID都要修改。
把倉庫管理關系表分解為二個關系表：
倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；
倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的資料庫表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。
範式應用
我們來逐步搞定一個論壇的資料庫，有如下信息：
（1） 用戶：用戶名，email，主頁，電話，聯系地址
（2） 帖子：發帖標題，發帖內容，回復標題，回復內容
第一次我們將資料庫設計為僅僅存在表：
用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容
這個資料庫表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：
用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容
這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：
(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)
但是，這樣的設計不符合第二範式，因為存在如下決定關系：
(用戶名) → (email,主頁,電話,聯系地址)
(發帖ID) → (發帖標題,發帖內容)
(回復ID) → (回復標題,回復內容)
即非關鍵欄位部分函數依賴於候選關鍵欄位，很明顯，這個設計會導致大量的數據冗餘和操作異常。
我們將資料庫表分解為（帶下劃線的為關鍵字）：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：發帖ID，標題，內容
（3） 回復信息：回復ID，標題，內容
（4） 發貼：用戶名，發帖ID
（5） 回復：發帖ID，回復ID
這樣的設計是滿足第1、2、3範式和BCNF範式要求的，但是這樣的設計是不是最好的呢？
不一定。
觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合並到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合並到第3項的"回復信息"中。這樣可以一定量地減少數據冗餘，新的設計為：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：用戶名，發帖ID，標題，內容
（3） 回復信息：發帖ID，回復ID，標題，內容
資料庫表1顯然滿足所有範式的要求；
資料庫表2中存在非關鍵欄位"標題"、"內容"對關鍵欄位"發帖ID"的部分函數依賴，即不滿足第二範式的要求，但是這一設計並不會導致數據冗餘和操作異常；
資料庫表3中也存在非關鍵欄位"標題"、"內容"對關鍵欄位"回復ID"的部分函數依賴，也不滿足第二範式的要求，但是與資料庫表2相似，這一設計也不會導致數據冗餘和操作異常。
由此可以看出，並不一定要強行滿足範式的要求，對於1：N關系，當1的一邊合並到N的那邊後，N的那邊就不再滿足第二範式了，但是這種設計反而比較好！
對於M：N的關系，不能將M一邊或N一邊合並到另一邊去，這樣會導致不符合範式要求，同時導致操作異常和數據冗餘。
對於1：1的關系，我們可以將左邊的1或者右邊的1合並到另一邊去，設計導致不符合範式要求，但是並不會導致操作異常和數據冗餘。
結論
滿足範式要求的資料庫設計是結構清晰的，同時可避免數據冗餘和操作異常。這並意味著不符合範式要求的設計一定是錯誤的，在資料庫表中存在1：1或1：N關系這種較特殊的情況下，合並導致的不符合範式要求反而是合理的。
在我們設計資料庫的時候，一定要時刻考慮範式的要求。
__________________________________________________________________
應該是第二種說法，只聽說過1NF,2NF,3NF這么分的，我大學教科書上也這么寫的