用 Clipper 多年, 近來重新出發, 努力用 Delphi 寫一些小系統, Q1. 我常聽說要資料庫正規化, 卻不知是啥 ! 可否指引解惑 ! Q2. 資料庫正規化 與 主流的SQL資料庫, 有直接關係嗎 ? Q3. 是依照SQL語法特性去規劃資料庫的方法, 叫作 [正規化] 嗎 ? 感恩

請參考： http://ccis.nou.edu.tw/access/item02-3-10.htm Kadee_BigRed

------
Kadee/BigRed Ent.
www.tw165.com

引言: 用 Clipper 多年, 近來重新出發, 努力用 Delphi 寫一些小系統, Q1. 我常聽說要資料庫正規化, 卻不知是啥 ! 可否指引解惑 ! Q2. 資料庫正規化 與 主流的SQL資料庫, 有直接關係嗎 ? Q3. 是依照SQL語法特性去規劃資料庫的方法, 叫作 [正規化] 嗎 ? 感恩

又看到一位Clipper的同好進來了, 如果是現在才轉入Delphi是稍嫌晚了點(我四年前即轉投了, 當時也是掙扎好久, 畢竟用了近10年的Clipper有深厚感情), 岔題了, "正規"要仔細講來可以出一本書, 但精神上我覺得kadee提供的內容很容易懂, 我想加強的是正規與非正規的差異 正規:不會造成資料表中的欄位有太多重覆及相近的欄位, 可降低資料的維護性及風險性, 也可使資料庫不至形成龐然大物, 可提昇效能(在一定量之後) 非正規:傳統式的結構考量, 把所有相關的資料全部集中於一個資料庫, 要拿什麼值就可以立刻取得, 很方便, 不用來回關聯的考慮, 但多個資料表中如果有一非主key值相同的欄位(例如客戶名稱)有異動, 那可就是大工程, 因為你必須全部都得改到, 否則就會發生不對稱結構了 再來談到正規的使用時機點, 如果你看一些sql的書籍, 大多會提到正規結構, 而且還分有第一正規, 第2,3,4,5..正規, 那簡直把資料庫給全拆散了, 就理想分析是很不錯的, 但就現實, 很可能會造成關聯上的遞迴現象, 一個處理不小心就會遺漏或重覆關聯, 所以我個人的經驗正規最好不要超過3階(就一般的商業設計來說) 另外在非正規用法上, 並非一無是處, 像我最近在寫一個案子, 一份報表必須使用到四組select , 如 select * from table1 where partno=(select * from table2 ....where .select * from table 3..... where select ....) 這是非正規的資料庫, 我可以在一整句sql語法上解決同一個資料表(table)需要判斷的條件, 如果是分成4個資料表那可就更複雜了, 可能還寫不出來, 這也就說正規化的資料庫比較不利於太複雜的查詢(如果你希望記錄一次就到位的話) 因此正規與非正規並不是對立的, 你必須憑自己的經驗決定那些資料庫要正規, 那些要非正規, 互相支援, 畢竟我還沒見到一個功力可以強到用一個資料庫就寫出一套完整系統的設計人 以上純屬個人意見~~~~~~~~~~

引言: 用 Clipper 多年, 近來重新出發, 努力用 Delphi 寫一些小系統, Q1. 我常聽說要資料庫正規化, 卻不知是啥 ! 可否指引解惑 ! Q2. 資料庫正規化 與 主流的SQL資料庫, 有直接關係嗎 ? Q3. 是依照SQL語法特性去規劃資料庫的方法, 叫作 [正規化] 嗎 ? 感恩

又看到一位Clipper的同好進來了, 如果是現在才轉入Delphi是稍嫌晚了點(我四年前即轉投了, 當時也是掙扎好久, 畢竟用了近10年的Clipper有深厚感情), 岔題了, "正規"要仔細講來可以出一本書, 但精神上我覺得kadee提供的內容很容易懂, 我想加強的是正規與非正規的差異 正規:不會造成資料表中的欄位有太多重覆及相近的欄位, 可降低資料的維護性及風險性, 也可使資料庫不至形成龐然大物, 可提昇效能(在一定量之後) 非正規:傳統式的結構考量, 把所有相關的資料全部集中於一個資料庫, 要拿什麼值就可以立刻取得, 很方便, 不用來回關聯的考慮, 但多個資料表中如果有一非主key值相同的欄位(例如客戶名稱)有異動, 那可就是大工程, 因為你必須全部都得改到, 否則就會發生不對稱結構了 再來談到正規的使用時機點, 如果你看一些sql的書籍, 大多會提到正規結構, 而且還分有第一正規, 第2,3,4,5..正規, 那簡直把資料庫給全拆散了, 就理想分析是很不錯的, 但就現實, 很可能會造成關聯上的遞迴現象, 一個處理不小心就會遺漏或重覆關聯, 所以我個人的經驗正規最好不要超過3階(就一般的商業設計來說) 另外在非正規用法上, 並非一無是處, 像我最近在寫一個案子, 一份報表必須使用到四組select , 如 select * from table1 where partno=(select * from table2 ....where .select * from table 3..... where select ....) 這是非正規的資料庫, 我可以在一整句sql語法上解決同一個資料表(table)需要判斷的條件, 如果是分成4個資料表那可就更複雜了, 可能還寫不出來, 這也就說正規化的資料庫比較不利於太複雜的查詢(如果你希望記錄一次就到位的話) 因此正規與非正規並不是對立的, 你必須憑自己的經驗決定那些資料庫要正規, 那些要非正規, 互相支援, 畢竟我還沒見到一個功力可以強到用一個資料庫就寫出一套完整系統的設計人 以上純屬個人意見~~~~~~~~~~

P.D. 大大精湛的想法令人引起共鳴 ! 正規化有助於資料庫的精簡及效率，但是太著重於正規化反而會自我設限。通常作到第三正規化已經足夠了，因為在實務上必須保持彈性，隨時有修改的可能。 Clipper , Clipper 好久沒聽到的詞了 ，令人懷念 ! 從 Clipper 到 SQL 最重要的應該是 Primary Key 的觀念，在 xBase 中可允許重覆的資料列，可是在 SQL 中絕對不行，重覆的資料列會破壞 SQL 的 table。參考參考 。 發表人 - scotthsiao 於 2005/10/04 09:24:56

感謝 kadee 指導,還不難懂,這四點原則,在DOS時代都吃過苦頭,也知道要避免. P.D. 及 scotthsiao所講的不要太極端執著,我可以體會 還請教 : [我個人的經驗正規最好不要超過3階] ? 難道 , 正規化還有層次問題, 這下我就不解了!? 還是scotthsiao 所言 , [通常作到第三正規化已經足夠了] 應該不是叫我, 不要管第四原則 : [欄位獨立性] 吧 !? P.D. 舉例 select 四組, 不就是因為正規化才能辦到的嗎? 怎麼說這是非正規化的應用. 我有點轉不過來, 可以幫我舉個實例嗎 ?

如果cwc65536 大大可以設計完全符合正規化的資料結構，又符合使用者的需求，那非常的恭喜。 只是在我的經驗中，很少有那麼好康的事。使用者出怪招或來個政策大轉彎，都會破壞"正規化"。為了保住以前的程式還能作用，也得出怪招應付，大改表格和使用者比賽，看誰改得快! 完全正規化的資料庫，在查詢時必須參照所有相關的表格才能得到答案。有時想偷懶一下都不行，不能直接用 SELECT * FROM ... 。得用很多的 JOIN 又LEFT又RIGHT才能取得。還真的很麻煩 !

剛剛GOOGLE一下 http://www.bamboo.hc.edu.tw/research_publish/textbook/cis01/part2/info-ch07.html 參考看看。 原則上在SQL的資料庫的正規化越高，資料重複性就越低，但在找相關資料時需join 的table就會越多。 資料庫正規化規則，在我看來有些部分是為節省儲存空間而產生的（因應以前儲存媒體成本相當高），現在的硬碟動不動就80G，所以正規化的規則其實我個人覺得有些值得商榷。 Kadee_BigRed

------
Kadee/BigRed Ent.
www.tw165.com

引言: 感謝 kadee 指導,還不難懂,這四點原則,在DOS時代都吃過苦頭,也知道要避免. P.D. 及 scotthsiao所講的不要太極端執著,我可以體會 還請教 : [我個人的經驗正規最好不要超過3階] ? 難道 , 正規化還有層次問題, 這下我就不解了!? 還是scotthsiao 所言 , [通常作到第三正規化已經足夠了] 應該不是叫我, 不要管第四原則 : [欄位獨立性] 吧 !? P.D. 舉例 select 四組, 不就是因為正規化才能辦到的嗎? 怎麼說這是非正規化的應用. 我有點轉不過來, 可以幫我舉個實例嗎 ?

引言: 剛剛GOOGLE一下 http://www.bamboo.hc.edu.tw/research_publish/textbook/cis01/part2/info-ch07.html 參考看看。 原則上在SQL的資料庫的正規化越高，資料重複性就越低，但在找相關資料時需join 的table就會越多。 資料庫正規化規則，在我看來有些部分是為節省儲存空間而產生的（因應以前儲存媒體成本相當高），現在的硬碟動不動就80G，所以正規化的規則其實我個人覺得有些值得商榷。 Kadee_BigRed

我加強一點說明, 最早的正規化的衍生, 其真正的核心是降低資料的複雜度與減少容量, 的確早期的容量每一k數是以元在計算, 很貴的, 不知各位有遇過最早期180K的5.25"碟片, 當初我使用時一片是150元(那時的一碗陽春麵是10元), 不過發展到今天, 正規化的目的已不是節省容量為主要考量, 而是結構表越多越複雜, 在 sql的建構上是非常不利的行為, 例如, 一個table 含括100個欄位與4個table 總含括100個欄位, 在啟動sql, 開啟, 讀取, sql轉換, 交易機制是?對不一樣的, 相較下要讀到完整的資訊, 後者肯定比前者要有效率! 談到這邊, 順便解答 cwc65536提的幾個問題 正規化是否有階層之分, 其實這是一個名稱之爭罷了, 如果大家有看一些sql的書籍, 都會談到正規的層次之分, 我只是引用而已, 如果真要來說階層的話, 以一個例子來說明 學校的成績資料表(假設我要設計一個各學校可用的程式) 第一階正規化: 校名 第二階正規化: 校名 班級 第三階正規化: 班級 學生 第四階正規化: 學生 科別 第五階正規化: 學生 科別 評量次 最後階正規化: 學生 科別 評量次 成績 其實第5,6階不可以算是正規化了, 如何說呢? 因為5,6階已違背正規精神, 因為主key重覆值太多了, 那是否第5階可改為 科別 評量次 答案是不可行, 因為科別並非唯一性, 假設每一位學生都有6科科別, 如果拿科別為key值, 將造成無法得知該科是屬於那一個學生, 那如何求得學生的科別的評量次呢? 所以在任何的案件中, 其實分到第4階就已經很難再分的下去, 這也就說明一般的案子3階足以, 太多就像上述這樣了, 但這不代表任何規劃都只到三階, 在商用軟體上並不常見, 但在一些工控系統上就有可能會發生 第二個可能cwc65536誤解我的說法了, 我說 select 4組, 並不是有四個table 要select, 而是只有一個table, 但因為條件的關係, 我必須在一句sql上要一次到位(即一句話就可以選出我要的記錄), 所以我用了4次的select, 在sql的語法上稱為遞迴次索引查詢, 如果今天我使用了正規化結構, 基本上是很難一次就能做到, 一定要如下類似做法 select * from table1 ... while not table1.eof do begin ... select * from table2 where table2.field1=table1.field1 ... end 免不了利用迴圈來執行, 當然也可以如scotthsiao所說的利用join語法, 但join是一個很吃資源的設計, 我舉這個例子是說明正規化不是不好, 也不是好, 反正就是適當的結構用在適當的設計上 我出個題目, 你想想看如何做 我想找出 某些學校所有小4年級的所有"王"姓學生的第1次評量的所有數學的記錄, 使用正規化做出的資料庫與非正規化的資料庫, 那一個sql比較好寫 非正規化就是把上述的第1-6階全部合成一個table=校名 班級 學生 科別 評量 成績, 你做下去其實正規與非正規就應該掌握十之八九了!