正規化與否,與domain 的東西有很大的關聯,
這不是資料庫軟體做得到的事(也不是他們的責任).
要證明表格有作過正規化
ER model和正規化後的資料表 應該是唯一的路徑.
不過,這應該是個非常辛苦的工作,需要對domain相當理解才行.

只是為何要求一定要正規化到BCNF 呢??
很多系統為了查詢上的方便與效能,
都會小小的偷吃步一下,在很多地方放了從重複的資料項.
也沒啥不好阿
有時正規化的太細,反而綁手綁腳.
查詢一個小東西,要join 一堆table 也不是好事呀...

通常到第三層的正規劃已經是大多數設計時的考慮，因為設計的時候也要兼顧到回應時間的需求，而且很多資料庫也會讓其他的軟體製作報告輸出之用，這些報表的射記者對於資料庫的認識不會有原始設計者深入，過量正規劃還可能導致報告設計上的困難與除錯的問題。

BCNF只是資料庫正規化的一個理想值....
可是有時候為了做到BCNF....
可能會犧牲到效能....
所以....一般廠商....
大概都會像樓上大大說的那樣....
有一些偷吃步的動作....
因為....現在硬碟空間根本不算什麼....
可是....查詢效能才是USER比較CARE的....

查詢時的需求才是重點~~BCNF為了是什麼,爽度嗎,省一個欄位,拖慢了效能,限制了以後的發展,何必呢~~
廠商在設計上,最重要的是達到客戶的需求,至於那些看不到的設計技巧,廠商實在沒有義務要告知~~
不是自認沒那個能力看出各欄位之間是否有相關聯,廠商有有什麼義務去證明是否做到BCNF
PS:自己寫資料庫時,BCNF真的只是為了爽度,實際的開發起來,還真的不會這樣來讓自己綁手綁腳的,搞到最後,自己都忘了關連到哪裡去了

個人不是高手,但還是說說自己的心得,個人認為正規化認定是看你的需求,簡單的說是將資料庫可輸入資料全輸入,過程中不會有重複要輸入,而如此後又能完全產生你所需求的表單,就算正規化了.

個人覺得正規化目的是考慮未來資料庫衍生壽命,但未來沒人知道會怎樣,能預估到什麼程度,真要照書上說的那套,那沒完沒了,寫的人是沒什麼,而負責輸入使用的人會很痛苦.

不知樓主要檢驗什麼?想太多了吧,資料庫資料能安全保存比較實際.