淺談數(shù)據(jù)庫設計技巧.docx

《淺談數(shù)據(jù)庫設計技巧.docx》由會員上傳分享，免費在線閱讀，更多相關內容在學術論文-天天文庫。

1、淺談數(shù)據(jù)庫設計技巧(上)時間:2004-09-1200:00來源:作者:點擊:1116次【字號：大中小】淺談數(shù)據(jù)庫設計技巧(上),閱讀淺談數(shù)據(jù)庫設計技巧(上),說到數(shù)據(jù)庫，我認為不能不先談數(shù)據(jù)結構。1996年，在我初入大學學習計算機編程時，當時的老師就告訴我們說：計算機程序＝數(shù)據(jù)結構＋算法。盡管現(xiàn)在的程序開發(fā)已由面向過程為主逐步過渡到面向對象為主，但我　　說到數(shù)據(jù)庫，我認為不能不先談數(shù)據(jù)結構。1996年，在我初入大學學習計算機編程時，當時的老師就告訴我們說：計算機程序＝數(shù)據(jù)結構＋算法。盡管現(xiàn)在的程序開發(fā)已由面向過程為主逐步過渡到面向對

2、象為主，但我還是深深贊同8年前老師的告訴我們的公式：計算機程序＝數(shù)據(jù)結構＋算法。面向對象的程序開發(fā)，要做的第一件事就是，先分析整個程序中需處理的數(shù)據(jù)，從中提取出抽象模板，以這個抽象模板設計類，再在其中逐步添加處理其數(shù)據(jù)的函數(shù)(即算法)，最后，再給類中的數(shù)據(jù)成員和函數(shù)劃分訪問權限，從而實現(xiàn)封裝?！　?shù)據(jù)庫的最初雛形據(jù)說源自美國一個奶牛場的記賬薄(紙質的，由此可見，數(shù)據(jù)庫并不一定是存儲在電腦里的數(shù)據(jù)^_^)，里面記錄的是該奶牛場的收支賬目，程序員在將其整理、錄入到電腦中時從中受到啟發(fā)。當按照規(guī)定好的數(shù)據(jù)結構所采集到的數(shù)據(jù)量大到一定程度后，

3、出于程序執(zhí)行效率的考慮，程序員將其中的檢索、更新維護等功能分離出來，做成單獨調用的模塊，這個模塊后來就慢慢發(fā)展、演變成現(xiàn)在我們所接觸到的數(shù)據(jù)庫管理系統(tǒng)(DBMS)——程序開發(fā)中的一個重要分支?！　∠旅孢M入正題，首先按我個人所接觸過的程序給數(shù)據(jù)庫設計人員的功底分一下類：　?。?、沒有系統(tǒng)學習過數(shù)據(jù)結構的程序員。這類程序員的作品往往只是他們的即興玩具，他們往往習慣只設計有限的幾個表，實現(xiàn)某類功能的數(shù)據(jù)全部塞在一個表中，各表之間幾乎毫無關聯(lián)。網上不少的免費管理軟件都是這樣的東西，當程序功能有限，數(shù)據(jù)量不多的時候，其程序運行起來沒有什么問題，但

4、是如果用其管理比較重要的數(shù)據(jù)，風險性非常大?！　。?、系統(tǒng)學習過數(shù)據(jù)結構，但是還沒有開發(fā)過對程序效率要求比較高的管理軟件的程序員。這類人多半剛從學校畢業(yè)不久，他們在設計數(shù)據(jù)庫表結構時，嚴格按照教科書上的規(guī)定，死扣E-R圖和3NF(別灰心，所有的數(shù)據(jù)庫設計高手都是從這一步開始的)。他們的作品，對于一般的access型輕量級的管理軟件，已經夠用。但是一旦該系統(tǒng)需要添加新功能，原有的數(shù)據(jù)庫表差不多得進行大換血?！　。?、第二類程序員，在經歷過數(shù)次程序效率的提升，以及功能升級的折騰后，終于升級成為數(shù)據(jù)庫設計的老鳥，第一類程序員眼中的高人。這類程序

5、員可以勝任二十個表以上的中型商業(yè)數(shù)據(jù)管理系統(tǒng)的開發(fā)工作。他們知道該在什么樣的情況下保留一定的冗余數(shù)據(jù)來提高程序效率，而且其設計的數(shù)據(jù)庫可拓展性較好，當用戶需要添加新功能時，原有數(shù)據(jù)庫表只需做少量修改即可?！　。?、在經歷過上十個類似數(shù)據(jù)庫管理軟件的重復設計后，第三類程序員中堅持下來沒有轉行，而是希望從中找出“偷懶”竅門的有心人會慢慢覺悟，從而完成量變到質變的轉換。他們所設計的數(shù)據(jù)庫表結構有一定的遠見，能夠預測到未來功能升級所需要的數(shù)據(jù)，從而預先留下伏筆。這類程序員目前大多晉級成數(shù)據(jù)挖掘方面的高級軟件開發(fā)人員。　?。怠⒌谌惓绦騿T或第四類

6、程序員，在對現(xiàn)有的各家數(shù)據(jù)庫管理系統(tǒng)的原理和開發(fā)都有一定的鉆研后，要么在其基礎上進行二次開發(fā)，要么自行開發(fā)一套有自主版權的通用數(shù)據(jù)庫管理系統(tǒng)?！　∥覀€人正處于第三類的末期，所以下面所列出的一些設計技巧只適合第二類和部分第三類數(shù)據(jù)庫設計人員。同時，由于我很少碰到有興趣在這方面深鉆下去的同行，所以文中難免出現(xiàn)錯誤和遺漏，在此先行聲明，歡迎大家指正，不要藏私哦8)　　一、樹型關系的數(shù)據(jù)表　　不少程序員在進行數(shù)據(jù)庫設計的時候都遇到過樹型關系的數(shù)據(jù)，例如常見的類別表，即一個大類，下面有若干個子類，某些子類又有子類這樣的情況。當類別不確定，用戶希

7、望可以在任意類別下添加新的子類，或者刪除某個類別和其下的所有子類，而且預計以后其數(shù)量會逐步增長，此時我們就會考慮用一個數(shù)據(jù)表來保存這些數(shù)據(jù)。按照教科書上的教導，第二類程序員大概會設計出類似這樣的數(shù)據(jù)表結構：類別表_1(Type_table_1)名稱　　　　　類型　　　　約束條件　　　說明type_id　int　無重復　　類別標識，主鍵type_name　　char(50)不允許為空類型名稱，不允許重復type_fatherint不允許為空該類別的父類別標識，如果是頂節(jié)點的話設定為某個唯一值　　這樣的設計短小精悍，完全滿足3NF，而且可

8、以滿足用戶的所有要求。是不是這樣就行呢？答案是NO！Why？　　我們來估計一下用戶希望如何羅列出這個表的數(shù)據(jù)的。對用戶而言，他當然期望按他所設定的層次關系一次羅列出所有的類別，例如這樣：總類別　　類別1　　　　類別1.1