關系型數據庫：使用范式創建數據庫
2024-07-21 02:36:58
供稿：網友
關系型數據庫理論可能是20世紀60年代和70年代存儲系統先鋒的救星，但是從那是開始它就成了許多數據開發人員的毒藥，就是因為現代數據庫系統發展得如此之好，以至于它將其關系型支柱對開發人員隱藏了。設計良好的關系型數據庫很輕易使用、很靈活，并且能夠保護數據的有效性。 而設計不良的數據相反仍然能夠發揮相當的作用，但是最終可能會導致數據的無效、錯誤或者丟失。
開發人員有一些專用的規則，叫做范式（normal forms），他們根據這些規則來創建設計良好的數據庫。在這里，我將通過創建一個用于保存書籍信息的簡單數據庫來探討一下范式。
本系列的第二部分
本文Builder.com是針對數據庫設計系列的第二部分。假如錯過了前一部分，你可以看看第一部分(關系型數據庫：理論背后的靈感) ，它揭示了關系型數據庫理論發展的內在動力。
確定實體和元素
設計數據庫的第一步是做你的家庭作業并確定你所需要的實體。實體是數據一種類型的概念集。通常只從一兩個實體開始，再隨著你數據的規范化而增加列表。對于我們的示例數據庫，它看上去就似乎我們只需要一個實體——書。
在確定了所需要實體的清單之后，你下一步就需要為每個實體創建數據元素（也就是說，你需要保存的信息）的清單。收集這樣的信息有多種途徑，但是最有效的可能就是依靠你的用戶了。向你的用戶詢問他們日常工作的情況，要求查看當前完成他們工作所需要的各種表格和報告。例如，訂單上可能會列出你創建銷售應用程序所需要的許多數據元素。
我們的書籍實體沒有書面表格和報告可用，但是下列元素清單將有助于我們開始設計這個數據庫：
{Title, Author, ISBN, PRice, Publisher, Category}
很重要的一點是，要注重，把我們這里要用的實體移動到元素的過程并不能適用于所有狀況。你所需要的實體不會總是像我們書籍示例那樣清楚，所以你可能要從數據元素的一長串清單開始，在后面你會根據實體來劃分元素。
正規化的頭幾步
一旦有了實體清單（表格）和數據元素（字段），你就預備好讓關系型數據庫理論運作了。這個理論的主要推動力是規范化——刪除任何重復的組和冗余的數據，并把它們放到兩個或者更多相關表里的過程。你并不是一定需要擁有一個以上的表格，但是你的數據簡單到只需要一個表格的機會并不多。
你應該小心地檢查數據（這些數據會出現在多條記錄里）和依靠性錯誤的實體和元素清單，并把已損壞的字段移動到不同的表格里。例如，你可能列出同一個作者的多本書，并在數據庫里重復了作者的名字。當你認為會一次又一次地看到相同的數據值時，你就應該考慮把這個字段移動到另一個表格里了。
要記住，在這一點上，你只是在操作潛在表格的列表，而不應該真正地創建這個表格：現在還是要用筆和紙來列表。
范式簡介
數據庫規范化的過程非常聞名，所以有正式的規則來保證規范化數據庫的建設。這些規則有七條，叫做范式，而在大多數情況下頭四條就夠用了：
第一范式（1NF）——這條規則有幾個要求，包括：無多值項目（multivalued item）和重復組（repeating group）；每個字段都是原子型的（atomic），也就是說每個字段必須包含可能的最小數據元素；以及表格含有要害字（key）。
第二范式（2NF）——表格必須按照1NF來規范化。所有的字段必須引用（或者描述）主鍵值。假如主鍵基于一個以上的字段，那么每個nonkey字段必須取決于復雜鍵（complex key），而不僅僅是一個沒有鍵的字段。不支持主鍵的nonkey字段應該被移動到另一個表格里去。
第三范式（3NF）——表格必須符合1NF和2NF的要求。所有的字段都必須相互獨立。任何描述nonkey字段的字段都必須被移動到另一個表格里。
Boyce-Codd范式（BCNF）——一定不能存在依靠于nonkey的字段。這條規則實際上是3NF的一個子規則，用于捕捉可能會通過進程的依靠性。這一點相當的抽象，一開始是很難應用的。
以上的規則很精確，但是技術定義以及規范化的規則能夠被簡化成下面幾點：
每個字段必須盡量小。
每個字段只能包含一個數據項目。
每條記錄都必須是唯一的。
注重重復的條目。
每個字段都必須完全支持主鍵，而且只支持主鍵。
下一步該做什么？
應用這些規范化規則，尤其是1NF的幾個要求，將會是個很需要技巧的過程。正如你會在下面內容里看到的，我會開始真正地把范式應用到實力數據庫上，在進行了其他規范化的步驟之后，你就會重新回到1NF。
