Board logo

主題: [DB] [轉貼] 資料庫的正規化 (言情小說版) [打印本頁]
發表人: jocosn    時間: 2006-7-8 03:29 PM     主題: [轉貼] 資料庫的正規化 (言情小說版)

第一節、為甚麼要正規化
一進小博家的大門，小君就馬上從背包裡拿出上次整理的那本筆記本，迅速地翻到其中一頁，稍微看了一下內容後，抬頭好奇地問：「師父哥哥，我有個疑惑耶，為甚麼有時候可以看到一個資料庫裡面，只有一個資料表格，卻包含有很多個欄位；有時候卻又看到同一個功能的資料庫裡，有許多的資料表，每個資料表的欄位卻不多，但是這兩個資料庫所呈現的的用途卻一模一樣。到底這二者是差在哪裡啊？又到底怎樣才算是好的資料庫設計呢？

聽完小君的問題，小博將筆記本借過去翻閱一下，詳細閱讀倒數幾頁之後，滿心歡喜地說：「喔，妳問的問題越來越有深度了，想必這幾天不見，妳一定偷偷跑去外面練個幾招了。」

被小博一眼就看穿這幾天的行蹤，小君頓時之間覺得有點不好意思，只好顧左右而言它：「沒有，沒有，我只是跑到重慶南路上的電腦書籍專賣書店去翻一翻幾本介紹資料庫系統的書，講老實話，那些書真的要在短時間內看得懂還真是不容易呢。」

小博其實不是要虧小君，他真正的用意是想誇讚小君在學習資料庫系統這件事情上面表現得很不錯，藉此激發小君的學習欲望與潛力：「不錯不錯，妳很有上進心，我相信再努力下去，妳一定也可以成為資料庫系統領域裡的專家。」

聽到小博這麼誇讚自己，小君的內心可是「爽」的很，只見她用一雙手遮住眼睛臉紅紅地說：「這還要靠師父哥哥您的大力指導呢。」

小博看到小君已樂得快要飛上天了，心想目的既然已經達到，該是降溫冷卻的時候，於是語氣一轉，突然間正經八百地說：「好說好說，言歸正傳，妳的問題其實就在於資料表格是否有執行『正規化』動作。」

學習一個新的領域的知識就是如此，會一而再，再而三地接連地碰到許多新的名詞或牽扯其它領域的觀念，這時候能夠做的就是—「小心學習，虛心請教」才是學習者的最上策。小君提高音調地問：「蝦米？正規化？又來了一個新名詞，我該把我的筆記本準備好才對。」

小博等小君準備好速記時的各種前置動作，才慢慢地開始說：「我們先假設現在有一個資料表格，叫做學生選課資料表，裡面包含學生學號、課程編號、學分數、以及成績等值組，如果這個時候有一門新課程要開了，妳想會發生甚麼問題呢？」

小君搔一搔頭髮，並反握鉛筆輕敲自己的頭額，再用一種不太確定的語器說：「會有甚麼問題呢？讓我想想看，首先，在這個叫做學生選課的資料表格中，主鍵值應該是學生學號加上課程編號吧。」

小博不想說太多，他想讓小君用「自己的話」說出問題的癥結所在，這樣才會將學到的觀念融會貫通：「是這樣子沒錯，然後呢？」

小君將舌頭伸入牙齒的上顎，裝成一隻母猩猩的樣子，一邊比動作一邊繼續思考小博的問題，過了幾分鐘後才恢復正常並興奮地回答：「既然是新課程的話，一開始一定沒有開始收學生嘛。如果只把課號與學分數加入表格內，等一下，那不是讓主鍵值的其中一個學生學號欄位變成虛值了嗎？這就違反了個體整合限制條件了嘛。」

小博一邊鼓掌一邊模仿香港電影中周星馳的誇張語氣說：「厲害，厲害，高招，高招，沒想到妳看的出來。」

小君嘴巴笑得好開，幾乎可以吞下一個傳統鹹肉粽（嗯，有點想吃呢，怎麼辦呀？）了，只見她心花怒放地笑著說：「這是當然的囉，所謂名師出高徒就是這麼一回事嘛。」

小博瞭解小君為什麼會這麼高興，他自顧自地繼續說：「這就是所謂的新增異常，也就是說這樣的新增是不被資料庫系統允許的。」

小君雖然靠自己的力量推導出這個問題的答案，但還是非常地不解，她滿臉狐疑地問：「那不是變成任何老師開新課程的資料都無法輸入到表格中嗎？這種情況不是很不合理嗎？」

小博就是在等待這一刻來到，當小君推導出來的答案和現實狀況產生某種衝突時，他再針對這些衝突或矛盾進行解釋，會比在一開始就把重點直接說出來要好得太多，至少對小君而言，她將會對這個觀念有非常深入的印象，不會一下子就忘記。小博一開始先從附和小君的話說起：「沒錯，這的確是非常的不合理，但這是因為資料表格設計不良而導致的。我們必須要做的動作，就是將表格中造成異常的部分屬性從表格中分離出來，產生另外一個新的表格，而這樣的過程就稱為『正規化』動作。」

小君在心裡重複一遍又一遍唸著小博說的話，每暗誦一遍，再思考一下，就覺得更能掌握「正規化」的整個概念，唸到第六遍時，她已經能夠完全明白小博想要表達的意思了。她恍然大悟地叫著：「原來這就叫做正規化啊，哈哈哈，看起來蠻有用的。」

小君剛剛的所有動作與結果，小博均看在眼裡。這些情況讓他回憶起自己過去學習電腦的經驗也是同樣的過程，他很高興能夠將所學習到的知識再傳授給其他人，並再次和小君沉浸在這種學習過程所產生的快樂中。他對小君的話做了一個總結性的歸納：「當然啦，妳再想想看，如果現在將學生選課資料表格縮減成三個欄位，分別為學生學號、課程編號、成績，而再另外產生一個資料表格，叫做課程資料表格，其中只有兩個欄位，就是課程編號以及學分數，妳再看看會不會發生剛剛的問題呢？」

果然這種學習過程所產生的大量喜悅是一種學習時的「腎上腺素」，不僅可以強化學習者的信心，更間接地促成一種學習過程的良性循環。小君思考小博繼續提出的問題，過了一會兒後，小君很有自信地說：「果然不會了耶，當我們要開新課程的時候，只要將新的課程資訊加到課程資料表格中，如此就動不到學生選課資料表格了，也就不會發生『新增異常』的問題了。」

小博補足小君沒有注意到的地方，讓小君更明瞭正規化的好處：「其實這樣子的修正，除了在新增資料的時候能解決異常的問題，刪除資料或更新資料時，也同樣解決了其它的異常問題。」

聽完小博的補充，小君若以所思地回答：「是不是說假如使用原本的表格，當只有一個人修某門課程，而後這個人又退選掉時，這個課程的資訊也一併從表格中被永久刪除了。」

為了讓「正規化」的觀念有個圓滿的結局，小博問小君最後一個問題：「完全正確，那妳要不要也順便說說為甚麼更新資料的時候也會產生異常問題。」

小君興在頭上，聽完小博的問題後就開始認真地想答案，過了好一會兒才胸有成竹地說：「我試著說看看，當某門課程想要從三學分的課變成四學分的課時，原來的表格修改起來就很吃力不討好了，萬一有某一些資料沒有被改到，不就造成了資料彼此間的不一致了嗎？」

小博很滿意小君的表現與這次教學過程中的互動模式，他舉起大姆指，對小君比出一個「棒」的手勢，並面帶微笑地說：「不錯不錯，我看妳是學通了。」

小君也非常謙虛地回應小博的誇獎：「師父哥哥，過獎過獎。」

第二節、第一、第二、第三正規化、BCNF
學習新領域的知識有時候是需要「乘勝追擊」的，就拿目前這種情況來說明，小君由於事先已經有稍做準備，所以學習的過程中就特別順暢容易，如果這個時候小博見好就收，下回再擱來的話，未免太可惜了，正確的做法應該趁小君樂在學習時，繼續進行下一階段的課題，雖然對小君而言困難了點，但學習過程的障礙會比較容易去克服。小博想通了以後，決定再接再厲，幫助小君挑戰正規化的進階課題，只見他不慌不忙地說：「其實正式來說，資料庫系統的正規化共可分為第一正規化、第二正規化、第三正規化、BCNF、第四正規化、第五正規化、第六正規化、第七正規化等等，不過對於一般的資料庫系統來說，只做第一階到第三階正規化就可以了，其他更高階的通常只會在很特殊的情況下才會出現，因此沒有必要耗費資源去考慮不太會發生的情形。而且前三階正規化就可應付絕大多數的資料庫系統所需要了。」

雖然「犛哩扣摳（國語發音，台語意義）」地聽了小博說了一大堆關於正規化的類別，但小君此時的興趣正高昂，絲毫不覺得半點疲倦，不僅如此，她還表達想繼續聽的意願：「原來正規化有這麼多種啊，我倒想聽聽這些正規化的分別在哪裡。」

小博也同樣很亢奮，誰叫小君的表現太優異了，他用一種急促地聲音回答：「沒問題，馬上就告訴妳。第一正規化的定義就是：關聯表的每一個屬性皆為單值。」

不等小博說完，小君就插嘴道：「也就是說如果有些屬性如果有多個值，像住址欄，有人可能有多間房子，那麼它的住址欄可能不只填一個住址，那麼是不是要做點修正，才能符合第一正規化的要求。」

小博停頓了一下，想一想是否正確，過了一會兒後才明確地回答：「妳說的完全正確，然而在接著說第二正規化之前，首先我要先告訴妳甚麼叫做功能相依。」

從字面上完全推導不出這個專有名詞的真正涵意，小君只好棄械投降，搔一搔頭髮後百般不情願地道：「嗯，這的確是有點抽象哎。」

小博提醒小君待會的解釋可是要寫在筆記本中，否則再過不久後，一定會忘得一乾二淨。等小君準備好後，小博才開始解釋：「一般能當主鍵值的屬性，它應該要有一個特色，那就是它可以唯一決定所有其他的屬性，換句話說，所有其他的屬性就會功能相依於主鍵了。」

小君點點頭，這還不難瞭解，但她相信這幾句話絕對不是重點，他可等不及要聽完全部的解釋了。只見小君迅速地抄寫完畢，抬頭問小博：「這還算容易理解，嗯，再來呢？」

小博眼看小君已經將他剛剛說的話全部記錄在筆記本上，他接著說：「但有的時候有些屬性，並不是功能相依於主鍵值，而是功能相依於主鍵中的部分屬性時，那麼就稱為部分功能相依於主鍵了。如果只功能相依於主鍵的所有屬性的話，就稱為完全功能相依於主鍵了。」

小君不僅聽得懂，還準備舉一反三，來個「徒兒大進擊」呢，只見她興沖沖地回應小博的話：「那我懂了，之前那個學生選課資料表，學分數就是功能相依於課程編號，而課程編號只是主鍵的部分屬性，使得學分數部分功能相依於主鍵學生學號加上課程編號了。」

小博滿心希望小君在資料庫系統上能夠「青出於藍，而勝於藍」，因此他絲毫不吝嗇誇讚小君：「妳的觀察力很強的嘛。」

小君像個小孩子似的手舞足蹈地說：「這是一定要的啦，這是一定要的啦！」

小博被小君逗得好不開心，他一邊模仿小君的動作一邊說：「知道了部分功能相依以後呢，我就開始來定義甚麼是第二正規化了。」

小君體力充沛，比了許久都不覺得累，她一邊比一邊插斷小博的話，搶著說：「我猜之前那個還沒拆開的學生選課資料表，一定是沒有符合第二正規化才出問題的是吧。」

小博覺得這個動作做久好酸痛呀，於是他停止這個手勢，也示意小君停下來專心聽他講：「妳猜的很準，我現在開始定義囉。第二正規化的定義就是：所有非鍵值屬性完全功能相依於主鍵或候選鍵。」

就算這次小君很認真聽，仍然有聽沒有懂，她捏著鼻子，用怪怪的假鼻音問到：「師父哥哥，有點不懂耶，為甚麼功能相依於候選鍵也算？」

小博鼓勵小君多動動頭腦想一想這個問題：「妳想想看喔，如果今天除了學生學號外，又有學生姓名的欄位，而且學生姓名也都不同，其他的欄位當然也功能相依於學生姓名了啊？這樣子不符合第二正規化有點太嚴苛了。」

小君反覆思考小博的話，發現確實如他所說的一樣，會產生過於嚴苛的問題。她吐了一下舌頭，並俏皮地說：「我懂了，因為課程編號在學生選課資料表中，並非候選鍵，而學分數卻功能相依於它，而造成了學分數部分功能相依於主鍵學生學號加課程編號了，因此違反了第二正規化的要求，我說的對不對啊？小博哥哥。」

小博露出一嘴潔白的牙齒，微笑著說：「對極了。」

好還要再更好，這是人之常情，小君當然也不例外，在聽完第二正規化是蝦米碗糕之後，小君當下決定再接再厲，繼續挑戰第三正規化。小君採用試探性的語氣問小博：「那第三正規化呢？是不是限制會更多啊？會不會很難啊？」

小博早就猜到小君會提出這個問題，他好整以暇地清一清喉嚨後，才慢吞吞地說：「那是當然的囉，第三正規化一開始的定義就是一定要滿足第二正規化，然後再滿足我接下來要講的性質，不過在我要說下去之前呢，我先講個例子，讓妳知道即使滿足了第二正規化的表格，仍然可能發生新增，刪除，更新的異常問題的。」

看見小博已經啟程出發前進了，小君當然也不敢怠慢。她開始集中注意力，專注聽講：「是喔，那我可要仔細聽囉。」

為了容易理解，小博先舉一個例子，稍後在利用這個例子來解釋為什麼一個已經第二正規化的表格，仍舊會發生新增、刪除與更新的異常問題。他一邊在小君的筆記本上畫出這個表格的所有欄位，一邊說明：「假如說現在有一個表格叫做課程資料表格，它有課程編號、課程名稱、教師編號、教師姓名四個欄位。如果這時候學校新聘了一位老師，妳猜會發生甚麼事？」

小君看著小博畫在筆記本上的表格，沉思了一會兒後嘗試著提出自己的看法：「我先來觀察一下這個表格，主鍵值是課程編號，其他的屬性完全功能相依於主鍵值，可見這是第二正規化表格，如果這時候學校新聘了一位老師，那不是讓課程編號跟課程名稱都是虛值嗎，因為剛聘的老師應該是還沒開課的嘛，這就違反了主鍵不能是虛值的個體整合性限制條件了啊。」

小博拍拍手，誇了一下小君：「我可愛的小君，妳可是越來越聰慧了。」

小君笑呵呵地回答：「哈哈，看看是誰教的嘛。」

小博繼續引導小君回答問題：「嗯，那我再來驗收一下，妳認為刪除與更新，是不是也會有問題呢？」

小君又看了一下筆記本，嘴中唸唸有辭，好像在暗地推導規則似的，過了許久後，眼睛突然閃亮了起來，興奮地說：「耶，我想想看喔，如果某位老師只開了一門課，結果因為人數不足，開不成這門課，那麼原本開課的記錄會被刪除，這樣子的話，老師的資料也就被一起刪除掉啦。」

小博不想打斷小君的話，繼續讓她說：「不錯，再來呢？」

小君這會可不讓小博等待了，只見小博的話剛一說完，小君就接著說：「如果說老師人數增加，教師編號可能從兩碼變三碼，因此必須要重新編碼吧，那這樣如果漏了幾筆沒修改到，就會造成資料不一致的狀況了。我記得我們公司就遇過這種狀況。因為有一陣子老闆新請了一些員工，結果員工代碼不夠用了。」

小博希望小君把這個案例說得再清楚點，因為有助於瞭解第二正規化後的刪除異常問題。小博提示小君說下去：「最後是怎麼處理呢？」

這又是一個會勾起小君不好的回憶的案例，她用一種超級怨懟的語氣述說著：「還不是我們資訊部門的幾個人要開始加夜班，把公司裡的每一份表格都拿來修改，好怕改錯，或是漏改，事後被老闆罵喔。現在想起來這樣的工作真的好笨喔。不過現在有了電腦化，但資料更多了，改起來也是頗麻煩的。」

小博頗有同感地回應小君的話：「沒錯啊，雖然現在有了電腦，但資料沒有系統式的管理，一樣也是沒有效率。」

小君一副受難者見證的表情：「我實在是太感同身受了。」

有了這些悲慘的事例做為佐證，小博相信小君待會在學習「遞移相依性」時，一定會學習得更好。他開始說明：「會發生這樣的問題，主要是因為資料表中存在了遞移相依性的結果。」

小君「啊」的一聲，驚訝的語氣中帶點些許的無奈：「啊！遞移相依性？又是一個專有名詞，唉，術語真是越來越多囉。」

小博拍拍小君的肩膀，要她別擔心，有他在一切就輕鬆搞定了。他邊打氣邊說：「別怕，讓我告訴妳，妳馬上就會懂了。」

小君握住小博的手，擺出一切就交給你的臉孔，並且語重心長地說：「嗯，本姑娘洗耳恭聽。」

小博早已經準備好要怎麼說，一收到小君萬事具備的訊號後，他就開始「咕嚕咕嚕」地講了起來：「所謂的『遞移相依』，也就是說，表格中某個屬性除了功能相依於主鍵外，它還相依於某個不是候選鍵的屬性。這樣好了，我用符號來告訴妳，如果x是主鍵，y、z都是非候選鍵的屬性，當然y就功能相依於x，而z也功能相依於x，這時候，如果z功能相依於y，那麼z、y、x也就產生了遞移性的關係了。」

小君望著筆記本上小博剛剛畫的表格，想要驗證小博的話，可是看了老半天，就是不確定這個表格是否也有「遞移相依性」的問題，她抬頭求助小博：「就這個課程資料表格而言，也有遞移相依性嗎？」

小博也低頭看了一下這個表格，馬上回應小君的問題：「這個課程資料表格，的確有遞移相依性，妳注意看教師編號與教師姓名這兩個欄位。」

小君依照小博的指示依序檢查那二個欄位，發現確實有這種相依性存在其中，他高興地說：「沒錯耶，教師姓名的確是功能相依於教師編號的。這麼說來，課程編號、教師編號、以及教師姓名三個屬性間產生了遞移相依性了。」

在確定小君完全瞭解「遞移相依性」後，小博更進一步地提出解決的方案：「既然發現了遞移相依性，我們就要想辦法把它從表格裡移除，以消除前面所提到的新增、刪除、及更新的異常現象，進而符合資料庫系統的第三正規化。」

小君心中已經有了腹案，只是不太確定罷了，她決定還是請教小博，聽聽看正確的解決步驟到底是怎麼一回事：「要怎麼樣才能把遞移相依性給移除呢？」

小博不敢說得太簡略，怕小君有聽沒有懂，這才更遭呢！他慢條斯理地說：「將遞移相依性移除，我們還是利用分解表格的老方法，首先先把產生遞移相依的兩個屬性從表格中分離出來。以課程資料表為例，我們將教師標號與教師姓名獨立出來，產生新的教師資料表。而原本的課程資料表，則保留教師編號，而形成具有課程編號、課程名稱、教師編號三個欄位的表格。」

小君根據小博的指示，在筆記本上原本已經第二正規化的表格下方，再新增二個表格上去，各是課程資料表格與教師資料表格，並註明上下方三個表格彼此間的關係為何。畫好之後，小君還端詳了筆記本一會兒，思考小博剛剛說明的觀念，邊看邊說：「真的耶，這樣一來，我要新增教師姓名，只要在教師資料表新增即可，刪除課程的時候也不會影響到教師的資料，更新教師資料的時候，只要再教師資料表中改一次就好，再也不用擔心少改了一筆，這樣的第三正規化表格，實在是太方便了。」

小博附和小君的想法：「當然囉，優良的設計總是能帶給人們便利的。」

---------
陳尚寬
http://dns.bamboo.hc.edu.tw/rese ... art2/info-ch07.html
發表人: jocosn    時間: 2006-7-8 03:50 PM

關聯式資料模式

第一節、表格與鍵值
小君覺得意猶未竟，當下決定留下來不走，繼續糾纏著小博，看看能不能從他身上多挖出一些關於資料庫系統的寶藏：「對於關聯表格，你能不能再講解得深入一點啊？哥哥，我很有興趣呢。」

擁有真材實料的人，當然不怕別人硬磨，只見小博擺出一副無所謂的態度，雙手一攤，面帶微笑地說：「當然可以啊，只要學生想學，老師當然要認真教囉。」

小君伸出雙手緊抓著小博又粗又狀的雙臂膀，用力搖晃著說：「快點說嘛！快點說嘛！」

小博被小君前後搖得七葷八素，趕緊撥開小君的手並回答：「好，好，男女授授不親，首先我們先從表格的資料結構開始談起。每個表格都會有一個名稱，用來分辨每一個表格。而每個表格都會含有一個或一個以上的欄位，我們稱之為屬性。」

小君睜大了眼睛呆望著小博，一臉不解地問道：「蝦米是『屬性』碗糕啊？有點玄耶！」

小博也睜大了眼睛回望著小君，同時邊打哈欠邊說：「屬性嘛，就是一個主體所被賦予的性質囉。就像當我們在規劃所有部門的表格時，總是要知道所有部門的名稱、所有部門的編號、以及部門的主管是誰，這些不都是必要的欄位嗎？而這些欄位也就被稱為部門表格的屬性了。」

小君被看得有點不好意思，連忙露出一臉「知了」的模樣，俏皮地遮住眼睛說：「原來是這樣啊，那我知道了，還有嗎？」

小博也恢復正常，不再繼續瞪著小君，只見他的手伸向背部，一邊抓癢一邊說：「還有每個欄位的值都稱為屬性值，而屬性值的範圍就稱為值域，關聯表本身就是由一筆一筆的記錄所組成的，我們也稱一筆筆的記錄為值組囉。夠不夠清楚啊？我的大小姐。」

看著小博拙劣的抓癢姿勢，小君一邊偷笑一邊回答：「嗯，到目前為止都還聽的懂。」

從小君的偷笑中，小博知道自己抓癢的姿勢鐵定超級難看，於是又用力抓了最後幾下，就停止不再抓了，整理了一下衣服，清一清喉嚨後，才慢慢地說：「接下來要談論的觀念就比較複雜了，妳可要注意聽喔。」

小君學電視廣告舉起右手，一邊笑一邊唸：「這是一定要的啦！這是一定要的啦！不然你就不教我了」

小博一面搖頭看著小君耍寶，一面對小君提出問題：「如果某一個屬性的屬性值保證獨一無二，就像學生的學號或身份證號，有一個這樣的屬性會有甚麼好處？」

被小博這麼一問，小君趕緊停止耍寶中的動作，認真地回答問題：「這個嘛，嗯…我想最重要的是應該不會混淆吧，如果有學號可以對到不同的學生姓名，那不就天下大亂了。」

小博覺得小君還不太能夠瞭解這個問題的重點，因此決定延伸小君的解釋：「沒錯，我們在建立一個表格的時候，的確會需要有這樣的一個屬性，這個屬性就相當於這個表格的鑰匙，所以這樣的屬性，我們就叫它做key，中文就翻譯為鍵值。」

聽完小博的解釋後，小君才明白剛剛的回答真是有點牛頭不對馬嘴，於是趕緊應答掩飾：「嗯，形容蠻貼切的嘛，如果一把鑰匙能夠開兩扇門，感覺起來的確是怪怪的。」

小博非常滿意小君的補充，他繼續說下去：「的確是這樣沒錯，當然囉，在一個表格裡面，可能會有不只一個屬性具有鍵值的條件，而這些屬性，我們都稱它為候選鍵。」

小君身體前傾，使用一種非常誇張的語調說：「甚麼『候選』啊，怎麼資料庫系統也可以跟政治選舉扯上關係啦？師父哥哥，你有沒有說錯啊？」

小博也將身體往前傾，並把雙手搭在小君的肩膀上，又好氣又好笑地說：「妳嘛給我幫幫忙，妳的想像力還真是很豐富勒，這不是跟政治選舉扯上關係，而是這些候選鍵都有資格被我們挑選出來成為這個表格的主鍵值。」

小君仍是丈二金剛摸不著頭緒，只好用一臉「莫宰羊」的一號表情面對小博：「那蝦米又是主鍵值呢？你給我說說看。」

小博看小君一臉茫茫然的模樣，就知道她又彈盡糧絕，陣亡在前線了。為了挽救這位多年同袍好友，他只好盡己所能地解釋給她聽：「主鍵值是一個值組中唯一的記錄識別值，它扮演著非常重要的地位，因為它負責與別的表格產生關聯。不過主鍵值亦可以由多個非鍵值的屬性所組合而成，只要它們的組合所產生的值是獨一無二的就行了。」

聽完小博的解釋，小君決定用「自己的話」再說一遍，證明她不僅聽懂，而且已經百分百地瞭解：「是不是像全國政府機關的表格，縣市名稱會有重複，單位名稱也會有重複，但是二者組合起來之後，就是獨一無二的名稱了。」

小博一邊鼓掌一邊微笑地說：「對，妳說得完全正確。不過接下來的『外來鍵』觀念，會更難喔。」

聽到小博的警告後，小君又瞪大了眼睛，擺出一副全神貫注，準備洗耳恭聽的模樣：「那我可要好好聽了，小博哥哥，出招吧！」

小博咳了幾下，清一清喉嚨後才說：「外來鍵是表格的某一個欄位，其屬性值與另一個表格的主鍵的屬性值有相同的值域，如此形成表格彼此間的關聯。」

小君有點懂，但又沒有把握完全懂的表情全然浮現在臉上：「有相同的值域？哦…哦…表格間的關聯？A，那A按奈，小博哥哥，舉個例子說明一下好不好？」

小博想了一下要怎麼講小君才會真的明瞭呢，想了許久，終於讓他想到一個好範例，他急忙回答：「那當然囉，如果我們今天有兩份表格，一個是部門表格，一個是員工表格。員工表格裡面查不到部門的所在地是很正常的一件事，是不是啊？」

小博每說一句話，小君就跟著點一次頭，終於點到小博說完話了，小君也不需要再點頭，他趕緊揉一揉脖子，神情愉快地說：「沒錯啊，如果一個表格要容納所有必要與不必要的資訊，那不是把表格撐得很大，就算是我這個外行人也不會贊成這麼做。」

小博開始準備將前面所談論的一些概念慢慢地串連起來，逐漸變成一個較完整的觀念，為了讓小君融會貫通，它決定採取循序引導的方式：「妳說的很對，但是如果今天有人想知道某某員工是在那一個地理位置工作的話，那要怎麼辦呢？」

小君左想想右思思，終於給她想到了一個方案，她嘗試著將這個方案清楚地說出來：「那可能要求助於部門表格囉，因為部門位置正常應該是部門表格中的一個屬性嘛。」

小博繼續引導著小君：「對，我們是必須求助於部門表格，但是我們也必須知道這個員工的部門編號或是部門名稱囉。妳說呢？」

聽到自己的方案完全被小博肯定，小君心裡可樂得很。現在不管小博說什麼，她都一定點頭稱是：「那是當然的囉，不過員工表格也一定會有員工所屬的部門編號才對吧。」

小博覺得小君的學習能力很強，能夠一路追得那麼緊卻不會落後太多，也算是不簡單了。想到這裡，他露出一個燦爛的笑容，算是給小君打氣（這算是鼓勵嗎？）：「是的，員工表格的部門編號就是一個外來鍵，它必須與部門表格的部門編號的值域相同，妳說是吧。」

小君故意模仿電影中僵屍的模樣，一邊跳呀跳地撲向小博一邊輕飄飄地說：「這是一定要的嘛，不然某某員工不就變成公司的幽靈人物了。」

小博眼看小君就要撲跳過來，連忙使出段譽的絕門武學—「凌波微步」，迅速跳往一旁，並且還臉不紅氣不喘地接著說：「那這樣妳了解了嗎？表格間就是靠相同的屬性值做聯繫的，也就是產生關聯。」

小君停止模仿僵屍的動作，伸出右手比了個OK的手勢，並且笑笑地說：「這樣我完全了解了。謝謝師父哥哥的解說。」

小博也學小君的口氣回答：「徒兒免禮。」


第二節、整合性限制條件
小君翻閱剛剛記錄下來的筆記，心中突然昇起一個疑問，於是揮手請小博過來，並客氣地問：「小博哥哥，我有個疑問想請教你耶，究竟一般的資料表欄位可不可以不用填任何資料啊。」

小博想了一下，認為這個問題包含在另外一個觀念底下，如果要解釋得好，就要先說明整個觀念才行，他說：「妳這個問題倒是讓我想到整合性限制條件的觀念。」

又是天外飛來一塊莫名的隕石，小君閃避不及，當場被擊個正著。小君只好搔搔頭，滿臉委屈地說：「哇勒，『整合性限制條件』？那又是蝦米碗糕啊？」

看著小君誇張的表情與動作，小博再也忍不住地笑了出來，過了好一會兒，小博才恢復正常，似笑非笑地說：「整合性限制條件，簡單來說，就是用來規範關聯式的資料表格。它分為個體整合限制以及參考整合限制。」

小君雖然聽過「不入虎穴，焉得虎子」，但勇闖虎穴的代價還真是高呀，一路上艱辛萬苦，困難重重，各式各樣的難題都有。小君只好硬著頭皮繼續問：「甚麼是『個體整合限制』，甚麼又是『參考整合限制』，弄得我暈頭轉向的，這又跟我的問題有甚麼關係呢？」

對第一次聽到這些名詞的人，一定會被搞得昏頭昏腦的，小博當初也是如此，所以他非常明白小君第一次聽到這些名詞的感受。他試著用一些淺顯的例子解釋給她聽：「妳剛剛的問題，就是被個體整合限制所規範，其他如主鍵的值不可以是虛值，輸入值的檢查等等，都是規範資料表內部的整合條件。」

就像倒吃甘蔗愈吃愈甜一樣，小君目前的學習狀況亦是如此：「你剛剛說的輸入值的檢查，是不是電腦可以自動幫我進行檢查，看看我輸入的資料有沒有錯誤或違反規則啊？」

小博在說下去之前，先給小君一個愛的鼓勵：「妳說的一點也沒錯。」

有了小博的鼓勵與支持，小君開懷地笑著說：「有了這個限制，我將來輸入資料時，錯誤就會減少許多，就不會常常挨老闆的罵了，耶，真棒！」

小博借機好好督促一下小君，希望她能夠對資料庫系統持續保持高昂的興趣：「所以你是不是應該要好好地學習資料庫系統啊，我的大小姐。」

小君甩了一下頭法，使用一種「超優伶」的語氣回答：「那是當然的囉。」

小博恢復正經的模樣，很認真地說：「好吧，接下來我告訴你甚麼是參考整合限制，它基本上是規範關聯表格彼此間的一種整合限制條件。」

小君搔了一下頭髮，順帶仰頭瞧了一下天花板，邊瞧邊說：「表格與表格間，還是不懂勒，你就舉個例子來說說嘛。」

小博已經觀察許久，發現小君有一個習慣性的招牌動作，就是在遇到不容易瞭解的觀念時，就會抓抓頭皮或搔搔頭髮，這真是一個有趣的發現啊！為了讓小君明白他講的觀念，他得利用剛剛談論過的「外來鍵」，於是他一面比手勢一面說：「還記得剛剛我們談論過的『外來鍵』嗎？」

小君嗯了老半天，終於迸出幾句話：「是不是表格中的一個欄位，其屬性值與另一個表格主鍵的屬性值域相同，你瞧，我背的不錯吧。」

小博搖搖頭，哭笑參半地回答：「是啊，是啊，但是會背也要會融會貫通才行。」

看到小博被自己逗得哭笑不得，小君心裡百味雜陳，只好豁出去繼續逗趣地回應：「遵命，師父又在教訓徒弟了，徒弟遵旨。」

小博伸手輕輕地打了一下小君，並擺出一副神聖不可侵犯的模樣，非常嚴肅地說：「只會耍嘴皮子，好了，我現在要開始舉例啦。就用剛剛的例子吧，妳想如果某個員工的部門編號，並不出現在部門表格中的部門編號裡面，這時候妳會希望電腦怎麼處理？」

小君瞪大眼睛直視前方，裝出一副真的很認真地在思考的表情，過了十幾秒後才學小博嚴肅的語氣回答：「電腦這時候應該通知使用者，讓使用者知道這個狀況，因為八成是輸入錯誤，或者部門資料表格太久沒有更新了。」

小博對這個同學真是沒有辦法，從高中時代開始就是班上的鬼靈精一個，不過從另一方面來看，只要她有興趣的東西，學起來比任何人都還要快精通：「妳說的一點也沒錯，設定這樣的整合性限制條件，就是要讓電腦知道，當使用者違反了一些關聯式資料表所預先設定的規則時，就應該通知使用者改變其輸入，來維護關聯式資料表間的完整性與一致性。」

小君趕緊在筆記本上速記小博說的每一句話，這些資料對她而言，都是很寶貴的資訊，她決定回家後，好好地瀏覽一遍，把今天學到的觀念再溫習一遍，期望能夠融會貫通：「耶！我又學到一課了，謝謝師父哥哥的教導。」

小博看著小君整理筆記，同時愉快地說：「快別這麼說。」
發表人: ROACH    時間: 2006-10-8 04:14 PM

此時小君站起來的時候忽然從筆記中掉出來一張圖片
小博馬上撿起來一看，這張穿著性感水手服的不是..
小君甩了一下頭髮，說道：「小博哥哥，我想....」
小博吞的一口口水，立即撲向小君


.......以下限制級.........




＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
言情小說本來還以為是那個東西
不過老實說，修過那麼多堂課的資料庫課程
還是很不了解，常會被一些複雜的需求稿混
還是學校教的比較簡單

不過還是要送花啦！！
發表人: soupjvc999    時間: 2006-10-16 04:31 AM

我的感想是:
1.別人用大量的經驗(let somebody's exp = 100),整理寫成經典的幾句濃縮文字
2.沒經驗的我反覆學著這些經典的句子(let my exp = 0)
3.下場是怎麼正規化我都體會不出其中的精華

還不如特意照自己的方式寫
寫完給個很有經驗的 DBA 測試,等到他給你建議與問題清單
再來想自己到底哪些地方要改進.....我想這樣操下去很快就進步了
發表人: topedia    時間: 2006-11-6 11:21 AM

先打包回家再看，
目前正在學PHP以後還會學到MYSQL，
先收下來當經驗。
發表人: agogoman    時間: 2008-8-21 02:14 PM

有關資料庫的正規化, 我是比較喜歡用獨孤木在Javaweek裡面發表的一系列文章, google一下應該就可以找到.
我都用那一份去教新進的小朋友, 畢竟很多時候正規化只是個工具(或說是手段), 但是很多時候 反正規化也是很合理的.

老實講, 我遇過為正規化而正規化的混蛋...完全捨本逐末, 搞得系統慢得像烏龜... 因為我是收攤的子....唉...
發表人: psycho    時間: 2008-9-9 02:54 AM


引用:
agogoman寫到:
有關資料庫的正規化, 我是比較喜歡用獨孤木在Javaweek裡面發表的一系列文章, google一下應該就可以找到.
我都用那一份去教新進的小朋友, 畢竟很多時候正規化只是個工具(或說是手段), 但是很多時候 反正規化也是很合理的.

老實講, 我遇過為正規化而正規化的混蛋...完全捨本逐末, 搞得系統慢得像烏龜... 因為我是收攤的子....唉...

正規化易學
反正規化難學
因為反正規化需要很多case study
像有些公司data base 就有N種版本
為了不同的部門需要這樣

這時候如何重新做db的design就是靠經驗啦
幸好我不是DBM



歡迎光臨 TWed2k (http://twed2k.org/) Powered by Discuz! 4.1.0