雖然透過ER or EER 概念設計出資料庫架構(Schema)，再透過Logical Design方法將其轉換為關聯式資料庫架構，就可以實務上作出關聯式資料庫，但是若是設計不好，可能會有謬誤的發生。例如若是資料庫管理者(DBA)將同樣一筆資料存放在資料庫內的多個地方，則工程師在使用時只改動了其中一筆資料，就會產生謬誤的結果。
為了減低這樣的謬誤發生機會，除了在進行資料庫設計時可以根據關聯式資料庫設計的guide line:
一entity一表格
盡量避免發生Update Anomalies (減少發生謬誤，廢話)
避免null, 越少越好
為了避免Spurious Tuples, 應基於P key & F key之間的關係來joint表格作日常化使用，若是不使用這樣的關係來作joint 則會產生大量錯誤的Spurious Tuples(無效的表格)
之外，亦必須在關聯式架構完成後，利用關聯式資料庫正規化將其轉換為正規化後的資料表，一般實務建議做到第3正規化或者第3.5正規化(所謂的BOYCE-COOD NORMAL FORM)，若在繼續做下去可能會將資料表分割太細造成實務使用及管理困難，也會增加系統效能負擔影響速度，需作取捨。因此更高階的正規化數學及精神意義大於實質。
講正規化前須先了解函數相依性(Functional Dependency)，若一張資料表上的某一個屬性或者某幾個屬性的集合Y，可以透過另個或一些屬性的集合X而被決定，就稱作Y依賴X，也稱作X決定Y，記作:
$X → Y$
而很多實務當中會產生的謬誤 Anomalies ，正是由於這些Dependency的存在而產生。故關聯式資料庫設計完成後仍需經過正規化的步驟來減少這些潛在風險。
<aside> 💡 在作正規化之前，須記得相依性的判斷可以是從屬性就可邏輯進行判斷，而非從資料值判斷；例如知道"學號"就一定能決定"名字"，也就是 "學號" → "名字" 從這樣的關係邏輯進行判斷，而非從資料值: "B9801005" → "王小明" 來進行判斷。 也就是說，在關聯式資料庫結構(schema)設計期，不用有資料值就可以透過屬性的關聯來進行判斷相依性了。
</aside>