none
一個正規化的問題

    問題

  • 想請問一下,像底下這樣子的資料表,我應該如何去做正規化呢?
    我知道這是蠢問題啦~><

    *ReportSN Report_Date User Group Contact_Name Contact_Phone Contact_Ext Issue Action
    1 2006/11/11 Joy Engineer,MIS Emily 03-5637782 305 LCD Blank Replace LCD Module

    這是我做完的正規化~可是好像不太對

    *ReportSN Report_Date UserID ContactID Issue Action
    1 2006/11/11 1 1 LCD Blank Replace LCD Module

    *UserID *GroupID User GroupName
    1 1 Joy Engineer
    1 2 Joy Admin

    *ContactID Contact_Name Contact_Phone Contact_Ext
    1 Emily 1234 305
    2 Joyce 4567 107

    2006年11月17日 上午 02:05

解答

  • 不知道你要做到第幾正規化 .
    建議你看一本資料庫理論的書會比較好哦 .
    2006年11月20日 上午 04:21
    版主

所有回覆

  • User 的資料還是重覆了啊 ...

    建議你把資料表建在 SQL Server 上,然後用 SQL Server 的圖表來看會比較清楚 ...

    2006年11月17日 上午 11:06
    版主
  • 我現在將User的部分再拆開

    *PID USERID GroupID

    *USERID USERNAME

    *GroupID GROUPNAME

    不知這樣對不對

    2006年11月20日 上午 01:20
  • 不知道你要做到第幾正規化 .
    建議你看一本資料庫理論的書會比較好哦 .
    2006年11月20日 上午 04:21
    版主
  • 怎麼叫做第幾正規,我覺得你們都陷入一些理論的漩渦裡,我看到很多人按這些理論,該拆的不拆,不該拆的拆,沒錯書寫的都沒錯,但感覺覺得好像缺少些甚麼,難怪我每次國家考試分數都很低,在這裡我主張用oo方式去設計資料庫,看你資料庫要存那些企業資料,比如說很多人設計員工通訊錄都會設計成,員工姓名,通訊地址,戶籍地址,電話1,電話2.你說有錯嗎? 但我覺得是很差的設計,你應該將員工跟通訊方式拆開來,一個人會有0-無限的電話,0-無限的通訊地址,另外人與人關係,人與車..,你要清楚企業資料有那些,資料間的關係去切,而不是說放在同一個資料表會比較好查去合,為了不讓資料重覆而去切,當然小資料庫沒差,但上百千個資料庫就很難維護
    2006年11月23日 上午 12:57
  • 我曾經聽過一句話:沒有比理論更實務的了 .
    這句話有些地方也許是錯的,但用在資料表正規化可是正確的 .

    每種理論都會有適用它的地方,資料庫正規化已經行之有年了 .
    許多應用程式仍然會利用正規化的技巧來設計資料庫,並且開發應用程式 .

    物件導向並不是不好,它也有它的好處 .
    只是並不是什麼都適用 .
    它在程式設計和系統分析上確實有用,但到了資料庫就沒這麼好過了 .
    因為,DBMS 必須要支援 OODB 才可以 .
    在 OODB 普及之前,正規化仍然會是主流技巧 .

    能夠解決問題的方法或技術,才是最好的方法 .
    否則一切都只是空談而已 .

    2006年11月23日 上午 11:05
    版主
  • 人家請你看書,是因為覺得有些東西需要自己去學來的,別人的經驗不少也是自己買書回來K,今天這個問題沒有誰對誰錯的問題,若你覺得沒有讀書的必要,你可以想看看,別人的經驗值多少錢,一個資料庫的設計會影嚮到的層面有多廣,這就是他的價值,多少人是用錯誤的經驗換來的,您的認知若是有這麼大的落差,或許可以透過其他管道取得支援,但是別把人家讀過的知識當成一文不值,今天他可以講出來,就代表有他的價值,這沒有什麼好去說誰的一定好,因為跟工具也有很大的關係,每家的產品都有他一套的技術,有人認為微軟的資料庫不能用,但是又有多少人不是用微軟的資料庫,好與壞各有各的調,不要為了技術交流搞的不愉快,共勉之.
    2006年11月23日 下午 03:07
  • 資料庫正規化是適用在關聯式資料庫上。

    據我所知,是先有關聯式資料庫的架構,經過歷次的運用調整後,以經驗為基礎,才逐步發展出資料庫正規化的理論,並逐漸完善。

    因此正規化是類似歸納出來的結論,並非是絕對的準則,有部份情況會有例外,但是基本上這個準則是經過多個系統千錘百鍊出來的結果。

    你在另外一篇的經驗談

    http://forums.microsoft.com/MSDN-CHT/ShowPost.aspx?PostID=921452&SiteID=14

    提到:我建議資料庫端只做CRUD就好了,一個Table 只做一個新增,一個修改,一個刪除,帶數個不等查詢,其他的邏輯運算就抓到前端的程式去算就好了

    會不會就是你的資料庫規劃不良才會有這樣的結論?因為:

    1. 網路傳輸資料是重大瓶頸,本機傳輸亦將佔用系統大量資源
    2. 資料庫查詢引擎已針對查詢語法進行過最佳化

    先不管你是否有更好的演算法過濾你要的資料,網路傳輸、本機傳輸與演算法間的速度差,級距約在 10000:100:1 左右,亦即演算法的改善,可能只能節省 1 秒,但是資料減少,則能節省 10000 倍,因此一般仍然認為,能在資料庫端過濾掉只保留最小必要資料進行傳輸,才是資料庫處理比較理想的方法。

    我是偏向資料庫在架構時,以使用面為導向去設計,不單純以儲存面或正規化去限制他的架構,當然,這種狀況其實在正規化的過程中,就可以達到了,只是偶爾會有應用面與正規化發生衝突,這時候如何抉擇,就看架構者的想法了。

    2006年11月23日 下午 03:51
  • 真是對不起,大家有這麼大的回應,而就物件導向只說在資料庫規劃的方式,沒有說正規化有問題還是錯的,而在我目前的設計過程中,幾乎結果會是相同的,而在設計時可以跟oo一起設計,也跟工具無關.而就
    1. 網路傳輸資料是重大瓶頸,本機傳輸亦將佔用系統大量資源
    2. 資料庫查詢引擎已針對查詢語法進行過最佳化

    這兩項而言幾乎不會有問題,針對1第一是如果Table設計好的話每個Table 資料都是小小的不會很大,前後端傳輸次數也不會很多.

    針對2.資料庫查詢引擎進行過最佳化是沒錯,但它是關聯引擎,如果你做CRUD 以外的事如 IF  Else,Foreach, Switch ...很多邏輯       判斷效能上我就不評估了

     

    再來說明我寫程式的規範都依MS標準,MS很多範例程式,寫的都很漂亮,Table 都很小,做出來的功能卻很強,這是我一直努力的目標,但人家的Code 打開就很清楚,資料庫端的Script 一看就懂,當然每個人學經歷都一樣,你們可以找自己喜歡的範例來看,至於結果心得如何就由你們自己判斷.

     

     

    2006年11月24日 上午 12:37
  • 我的經驗是,先了解使用者的需要是什麼,再去架構資料庫 .
    因為連使用者要什麼都不知道,就貿然架構資料庫,那會死人的(設計資料庫的人)

    正規化是為了消除資料的重覆性,OO 不也是如此(藉由繼承來消除重覆的程式碼)嗎?
    但是,有時候設計資料庫,徹底的正規化並不是好事,所以通常會保留一點彈性 .

    微軟的範例都是用個案為基礎的,像是它的 IBuySpy Solution,資料庫設計就算漂亮 .
    但你深入進去看,是否只是都是純 schema? 不盡然 .
    有些可能用到很多的 stored procedure, view, trigger, rule, custom-data type 等等 .
    設計資料庫不是只看資料表而已,而要看的是整體的資料庫設計 .

    不必強迫別人接受自己的看法,但是如果討論的基礎是在一個已經被接受而且行之有年的方法論,這樣還有什麼好爭論的?
    只是每個人實作方法不同而已,就算是書上的討論,可能也只是作者認為可行的方法而已 .
    要多方涉獵與思考,才能夠架構出歸納各方優點的解決方案,但,不可能會有完美的解決方案 .

    還是那句話,能夠解決問題的技術,才是好技術 .
    否則一切都是空談而已 .

    2006年11月24日 上午 04:19
    版主
  • 感謝大家的回覆,看各位前輩的回覆獲益不少!^^

    非常感謝!^^

    2006年11月24日 上午 06:12