有時，理論與實踐有一些差距，在做乙個具體的事情時，我們應該以實際為核心，而不是把理論死搬上來，要「從實際出發」，呵呵。
在資料庫的世界裡存在著三大正規化，也就是規範，真正的關係型資料庫應該盡可能的滿足這些規範，但有時，我們卻根據實際問題，需要違背這些規範，這個系列我將從實際專案**發來與大家一起說說「反正規化」的設計。
設計資料庫時，首先要根據業務，找出實體，確定實體間的關係。乙個結構良好的資料庫，讓專案在開發的過程中可以順暢，而乙個結構不穩定的資料庫則會導致專案在開發的過程中大量的修改**。不能滿物件導向的開閉原則（ocp）。有時，我們可能會經常為一些業務去新增表字段，而這並不是我提供的，建義大家，將新增的業務直接抽象成表物件，這樣可能避免原表物件的修改，而只是對原表在結構上進行了擴充套件，這是符合ocp的。
1.第一正規化（1nf）
在任何乙個關聯式資料庫中，第一正規化（1nf）是對關係模式的基本要求，不滿足第一正規化（1nf）的資料庫就不是關聯式資料庫。
所謂第一正規化（1nf）是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。 如果出現重複的屬性，就可能需要定義乙個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關係。在第一正規化（1nf）中表的每一行只包含 乙個例項的資訊。例如，對於員工資訊表，不能將員工資訊都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工資訊表的每一行只表示乙個員工的信 息，乙個員工的資訊在表中只出現一次。簡而言之，第一正規化就是無重複的列。
2.第二正規化（2nf）
第二正規化（2nf）是在第一正規化（1nf）的基礎上建立起來的，即滿足第二正規化（2nf）必須先滿足第一正規化 （1nf）。第二正規化（2nf）要求資料庫表中的每個例項或行必須可以被惟一地區分。為實現區分通常需要為表加上乙個列，以儲存各個例項的惟一標識。如 員工資訊表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主 碼。
第二正規化（2nf）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和 主關鍵字的這一部分應該分離出來形成乙個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上乙個列，以儲存各個例項的惟一標識。簡 而言之，第二正規化就是非主屬性非部分依賴於主關鍵字。
3.第三正規化（3nf）
滿足第三正規化（3nf）必須先滿足第二正規化（2nf）。簡而言之，第三正規化（3nf）要求乙個資料庫表中不包含 已在其它表中已包含的非主關鍵字資訊。例如，存在乙個部門資訊表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等資訊。那麼在員工資訊 表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表，則根據第三正規化（3nf）也應該構建它， 否則就會有大量的資料冗餘。簡而言之，第三正規化就是屬性不依賴於其它非主屬性。
資料庫設計 三大正規化和反正規化
總共有六大正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 巴斯 科德正規化 bcnf 第四正規化 4nf 和第五正規化 5nf，又稱完美正規化 只記前三正規化 三大正規化 第一正規化 資料表中欄位滿足原子性，字段不可再分 如學生資訊字段 儲存 張三,手機號 這個可以再分姓名，手機...
資料庫三正規化和反三正規化
要說資料庫什麼最抽象，我覺得就是這個三正規化，不是很好理解，但是表在設計的時候又必須要知道這麼乙個規則。首先使用最簡潔的話說說這三正規化 第一正規化 1nf the first normal form 每一列不能再分割。第二正規化 2nf the second normal form 滿足1nf條件...
資料庫正規化與反正規化
最近涉及到設計和建立數倉表，資料總體劃分為ods fact aggr dws rpt dim層，具體結構如下圖所示 遵從設計規則 以星型模型為設計模式,維度採用反正規化化,且維度資料要整個倉庫可共用,資料準確性要保證,事實表允許冗餘部分維度資料。針對其中幾個地方，解釋並mark一下。多維資料模型是最...