數(shù)據(jù)庫設(shè)計(jì)規(guī)范化的五個要求-預(yù)覽頁
【正文】 ，也會增加記錄的長度?！ ∮龅竭@種情況時，筆者建議可以把上面這張表分解成三種獨(dú)立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應(yīng)表等等。而且，數(shù)據(jù)庫規(guī)范往往沒有技術(shù)方面的嚴(yán)格限制，主要依靠數(shù)據(jù)庫管理員日常工作經(jīng)驗(yàn)的累積。對象要符合封裝的特性，確保與職責(zé)相關(guān)的數(shù)據(jù)項(xiàng)被定義在一個對象之內(nèi)，這些數(shù)據(jù)項(xiàng)能夠完整描述該職責(zé)，不會出現(xiàn)職責(zé)描述缺失。在確定關(guān)鍵字時，應(yīng)保證關(guān)鍵字不會參與業(yè)務(wù)且不會出現(xiàn)更新異常，這時，最優(yōu)解決方案為采用一個自增數(shù)值型屬性或一個隨機(jī)字符串作為表的關(guān)鍵字。這時，應(yīng)根據(jù)反向工程的思路反饋給領(lǐng)域模型。并且，我認(rèn)為數(shù)據(jù)庫中的表是用來持久化一個對象實(shí)例在特定時間及特定條件下的狀態(tài)的，只是一個存儲介質(zhì)，所以，表和表之間也不應(yīng)用強(qiáng)關(guān)聯(lián)來表述業(yè)務(wù)(數(shù)據(jù)間的一致性)，這一職責(zé)應(yīng)由系統(tǒng)的邏輯層來保證，這種方式也確保了系統(tǒng)對于不正確數(shù)據(jù)(臟數(shù)據(jù))的兼容性。雖然建立索引會消耗部分系統(tǒng)資源，但比較起在檢索時搜索整張表中的數(shù)據(jù)尤其時表中的數(shù)據(jù)量較大時所帶來的性能影響，以及無索引時的排序操作所帶來的性能影響，這種方式仍然是值得提倡的。四個范式確保了不會出現(xiàn)異常，但也可能由此導(dǎo)致過于純潔的設(shè)計(jì)，使得表結(jié)構(gòu)難于使用，所以在設(shè)計(jì)時需要進(jìn)行綜合判斷，但首先確保符合四個范式，然后再進(jìn)行精化修正是剛剛進(jìn)入數(shù)據(jù)庫設(shè)計(jì)領(lǐng)域時可以采用的最好辦法。在一般情況下，它們是一對一的關(guān)系：即一張?jiān)紗螕?jù)對應(yīng)且只對應(yīng)一個實(shí)體。 〖例1〗：一份員工履歷資料，在人力資源信息系統(tǒng)中，就對應(yīng)三個基本表：員工基本情況表、社會關(guān)系表、工作簡歷表。在E—R 圖中, 處于葉子部位的實(shí)體, 可以定義主鍵，也可以不定義主鍵 (因?yàn)樗鼰o子孫), 但必須要有外鍵(因?yàn)樗懈赣H)。 3. 基本表的性質(zhì) 基本表與中間表、臨時表不同，因?yàn)樗哂腥缦滤膫€特性： (1) 原子性。 (3) 演繹性。 理解基本表的性質(zhì)后，在設(shè)計(jì)數(shù)據(jù)庫時，就能將基本表與中間表、臨時表區(qū)分開來。 〖例2〗：有一張存放商品的基本表，如表1所示。“金額”這樣的列被稱為“計(jì)算列”，而“單價”和 “數(shù)量”這樣的列被稱為“數(shù)據(jù)列”。但是，沒有冗余的數(shù)據(jù)庫未必是最好的數(shù)據(jù)庫，有時為了提高運(yùn)行效率，就必須降 低范式標(biāo)準(zhǔn)，適當(dāng)保留冗余數(shù)據(jù)。消除的辦法是，在兩者之間增加第三個實(shí)體。一般來講，數(shù)據(jù)庫設(shè)計(jì)工具不能識別多對多的關(guān)系，但能處 理多對多的關(guān)系。 7. 主鍵PK的取值方法 PK是供程序員使用的表間連接工具，可以是一無物理意義的數(shù)字串, 由程序自動加1來實(shí)現(xiàn)。 8. 正確認(rèn)識數(shù)據(jù)冗余 主鍵與外鍵在多表中的重復(fù)出現(xiàn), 不屬于數(shù)據(jù)冗余，這個概念必須清楚，事實(shí)上有許多人還不清楚。冗余的目的是為了提高處理速度。反之要修改ER圖。視圖是供程序員使用數(shù)據(jù)庫的 一個窗口，是基表數(shù)據(jù)綜合的一種形式, 是數(shù)據(jù)處理的一種方法，是用戶數(shù)據(jù)保密的一種手段。 對于某些與國家政治、經(jīng)濟(jì)、技術(shù)、軍事和安全利益有關(guān)的信息系統(tǒng)，視圖的作用更加重要。請讀者想想：這是為什么？ 11. 中間表、報表和臨時表 中間表是存放統(tǒng)計(jì)數(shù)據(jù)的表，它是為數(shù)據(jù)倉庫、輸出報表或查詢結(jié)果而設(shè)計(jì)的，有時它沒有主鍵與外鍵(數(shù)據(jù)倉 庫除外)。 參照完整性：用PK、FK、表級觸發(fā)器來實(shí)現(xiàn)。因?yàn)橹麈I的作用，一是建主鍵索引，二是做為子表的外鍵，所以組 合主鍵的字段個數(shù)少了，不僅節(jié)省了運(yùn)行時間，而且節(jié)省了索引存儲空間； (3) 一個表中的字段個數(shù)越少越好。 數(shù)據(jù)庫設(shè)計(jì)的實(shí)用原則是：在數(shù)據(jù)冗余和處理速度之間找到合適的平衡點(diǎn)。試想：若覆蓋系統(tǒng)同樣的功 能，一百個實(shí)體(共一千個屬性) 的ER圖，肯定比二百個實(shí)體(共二千個屬性) 的ER圖，要好得多。 提倡“三少”原則的目的，是防止讀者利用打補(bǔ)丁技術(shù)，不斷地對數(shù)據(jù)庫進(jìn)行增刪改，使企業(yè)數(shù)據(jù)庫變成了隨意 設(shè)計(jì)數(shù)據(jù)庫表的“垃圾堆”，或數(shù)據(jù)庫表的“大雜院”，最后造成數(shù)據(jù)庫中的基本表、代碼表、中間表、臨時表 雜亂無章，不計(jì)其數(shù)，導(dǎo)致企事業(yè)單位的信息系統(tǒng)無法維護(hù)而癱瘓。 (2) 當(dāng)計(jì)算非常復(fù)雜、而且記錄條數(shù)非常巨大時(例如一千萬條)，復(fù)雜計(jì)算要先在數(shù)據(jù)庫外面，以文件系統(tǒng)方 式用C++語言計(jì)算處理完成之后，最后才入庫追加到表中去。若發(fā)現(xiàn)某個表的字段太多，例如超過八十個，則 垂直分割該表，將原來的一個表分解為兩個表。 上述十四個技巧，是許多人在大量的數(shù)據(jù)庫分析與設(shè)計(jì)實(shí)踐中，逐步總結(jié)出來的。 我前幾個月訂購了一本人郵圖靈出版的《MySQL 5 權(quán)威指南》第三版中文版，買這本書只是因?yàn)橛腥怂臀褻hinaPub的優(yōu)惠券，我就順手買本MySQL的書，用來管理JavaEye服務(wù)器的時候備查的。對于我這個不是計(jì)算機(jī)科班出身的人來說，到現(xiàn)在才知道什么是三大范式不算可恥。 所以結(jié)論就是這樣： 關(guān)系模型和對象模型存在概念上的阻抗不匹配，但是在關(guān)系數(shù)據(jù)庫的存儲模型上是一致的，無論你從關(guān)系模型的三大范式理論出發(fā)，還是從對象模型的ORM理論出發(fā)，最終一定會得到一致的數(shù)據(jù)庫表設(shè)計(jì)。 但是我們現(xiàn)在不一樣了，有了良好的ORM框架和應(yīng)用層的對象緩存機(jī)制，我們可以做到：讓比較簡單的查詢根本不打擾數(shù)據(jù)庫，讓比較復(fù)雜的查詢盡量少的掃描表記錄，其最終達(dá)到的效果在OLTP類型的應(yīng)用上面效果遠(yuǎn)遠(yuǎn)超過傳統(tǒng)的方式。所以良好的遵循三大范式，利用好ORM和對象緩存，可以取得非常棒的應(yīng)用性能，還可以讓你的數(shù)據(jù)庫更加輕松。 設(shè)計(jì)總是伴隨者“妥協(xié)”的。因?yàn)檫@樣會降低索引的效率，聯(lián)合主鍵一般都要用到至少一個業(yè)務(wù)字段，往往是字符串型的，而且理論上多字段的索引比單字段的索引要慢些。而且更容易避開“聯(lián)合主鍵”，而且可以使用索引效率高的字段類型，比如int、long、number。 個人使用實(shí)際狀況，總體來說“邏輯主鍵”比“業(yè)務(wù)主鍵”執(zhí)行效率低，但不會低到無法滿足需求。這個問題其實(shí)不是數(shù)據(jù)庫設(shè)計(jì)的問題了，在數(shù)據(jù)庫設(shè)計(jì)中，多對多關(guān)系也僅僅存在于邏輯模型（ER）階段，物理模型不在有多對多關(guān)系，實(shí)際數(shù)據(jù)庫中也不會有“多對多”關(guān)系。 ？我習(xí)慣在設(shè)計(jì)時給每個表設(shè)一個state字段，取值0或1，默認(rèn)值為1，具體業(yè)務(wù)意義或操作上的意義可以自定義。 ？建議不存！這樣做確實(shí)可以提高查詢效率，但在一個有很多表，并且關(guān)聯(lián)表多的情況下，很難保持?jǐn)?shù)據(jù)的一致性！數(shù)據(jù)庫結(jié)構(gòu)也
語文相關(guān)推薦
鄂ICP備17016276號-1