標准化是在數據庫中組織數據的進程。其中包括，根據設計規則創建表並在這些表間建立關系；通過取消冗余度與不一致相關性，該設計規則可以同時保護數據並增加數據的靈活性。
冗余數據會浪費磁盤空間並帶來維護問題。如果必須更改同時放在幾個位置的一個數據，則必須按同一種方式更改所有位置的數據。如果該數據只保存在 Customers 表中而非數據庫中的其它位置，更改客戶地址要容易得多。
什麼是“不一致相關性”？雖然在 Customers 表中查找部分客戶的地址對於用戶來說很直觀，但是對於在此查找訪問該客戶的雇員的薪水來說可能沒有意義。雇員的薪水與雇員本身有關或者說取決於雇員本身，因此應在“雇員”表中進行查看。由於查找數據的路徑有可能丟失或破壞掉，不一致相關性會使得數據難於訪問。
有一些規則用於數據庫標准化。每個規則稱為“常規表單(范式)”。如果遵循了第一條規則，則數據庫是“第一常規表單(范式)”。如果遵循了前三條規則，則數據庫是“第三常規表單(范式)”。雖然標准化可能有其它等級，但對於大多數應用程序而言，通常認為第三常規表單(范式)是必須的最高等級。
由於有許多常規規則與規范，實際情況並不總是要求完全符合。一般說來，標准化需要其它表，而且一些客戶覺得這比較麻煩。如果您決定不遵循標准化前三個規則之一，請確保應用程序會預見可能發生的任何問題，如冗余數據與不一致相關性問題。
下面的說明中包括一些示例。
第一常規表單(第一范式)
1.去掉各個表中的重復組。
2.為每組關聯數據創建獨立的數據。
3.使用主關鍵字確定每組關聯數據。
請勿在一個表中使用多個字段保存相似數據。例如，要跟蹤可能來自兩個可能資源的清單項，清單記錄可能包含 Vendor Code 1 和 Vendor Code 2 的字段。
添加第三方供應商時會出現什麼情況？添加字段並不能解決問題；添加字段需要修改程序和表，而且無法很好地適應供應商個數不斷變化的情況。反而，將所有供應商信息放在稱為 Vendors 的獨立表中，然後使用項目編號關鍵字將清單鏈接到供應商，或使用供應商代碼關鍵字將供應商鏈接到清單。
第二常規表單(第二范式)
1.為應用到多個記錄的多組數值創建獨立表。
2.使用外部關鍵字將這些表關聯起來。
記錄不應取決於表主關鍵字（如有必要，可以是組合關鍵字）之外的任何關鍵字。例如，在計帳系統中考慮使用客戶地址。除 Customers 表需要該地址外，Orders、Shipping、Invoices、Accounts Receivable 與 Collections 表也需要該地址。在上述每個表中並不是將客戶地址作為獨立條目進行保存的，而是將其保存在一個位置，即保存在 Customers 表或獨立的 Addresses 表中。
第三常規表單(第三范式)
去掉了不取決於關鍵字的字段。
在記錄中而不是記錄的關鍵字部分的數值並不包含在表中。一般來說，在任何時候，字段組的內容可能適用於表中的多個記錄，可以考慮在一個獨立表中存放這些字段。
例如，在 Employee Recruitment 表中，可能包括應聘者的大學名稱和地址。但是，您需要一個完整的大學列表以便於進行分組郵寄。如果大學信息保存在 Candidates 表中，沒有當前的應聘者無論如何無法列出這些大學。創建獨立的 UniversitIEs 表並使用大學代碼關鍵字將其鏈接至 Candidates 表。
例外情況：遵循第三常規表單（這在理論上是必要的）不一定總是實際有用的。如果您有一個 Customers 表且要去掉所有可能的字段內相關性，則必須對城市、郵政編碼、銷售代表、客戶類別以及任何其它可能在多個字段中重復的因素創建獨立的表。理論上講，標准化是值得投資的。但是，許多小的表可能會使性能降低或超出打開文件與內存的能力。
僅將第三常規表單應用於不斷變化的數據的方法可能更加靈活。如果還保留了一些相關的字段，則需要將應用程序設計為當對一個數據進行更改時，需要用戶確認所有的相關字段。
