有關資料庫概念設計幾點見解經驗談(轉)

有關資料庫概念設計幾點見解經驗談(轉)[@more@]如果將資料庫設計比作是福爾摩斯破案，根據各種條件，限制，規則，抽絲撥繭，尋找其中的相互聯絡，一步一步深入案件的中間，最終解決案件。但破案首先需要有方法，那麼對於資料庫設計目前以使用已久的一系列設計資料庫結構的成熟方法（比如：規範化）都可以作為破案所需方法的良好的根基。實際上，這些方法幾乎都是經典的設計方法，因此，在進行資料庫設計的時候，遵循這些方法並不會感覺到太困難。正如同我們所知，我們可以直接將你按方法的設計可以直接轉變成SQL SERVER表。

但是，除非你只是為了抓一個現顯的小偷，否則需要各種條件，規則，限制，聯絡都必須考慮到。如同我們在需要統一的考慮資料庫解決方案中的分佈、冗餘、叢集、24/7支援、存取過程、觸發器、約束和完整性等問題的時候，就需要引入資料庫結構的技術。這種技術沒有提供物理地實現資料庫的方法，但可以透過它來選擇一種最佳的方法。

在現代按照不同的設計可以將整個資料庫系統按不同服務需求分解成不同的組成部分，而不是使用一種技術完成整個的任務。它們可以分為：

● OLTP（聯機事務處理）－－OLTP資料庫儲存當前業務運作所需要得資料，它的主要目的是使當前的公共資料完整合理，要達到這個目的需要遵循兩條原則：1、每一個當前資料塊只能儲存在一個可供編輯的位置，此處的如何改動都會反映倒所有使用這一資料的地方。2、提供事務支援，以便對資料庫進行多項更改一起生效。如果事務中的一個更改失敗了，其他的所有更改也都不允許生效，事務中止，所有操作回滾。

● 業務資料儲存（Operational Data Store，ODS）――用於日報表的彙總資料。這些資料經常取之幾個完全不同的地方，並進行了一定程度的預彙總，以便節省查詢的時間。它的目的是向使用者提供運算元據並跟蹤近期的趨勢，以便做出決策。

● 資料倉儲（Data Warehouse）――儲存整個公司的重要資料和歷史資料，它的目的一是利用公司現存歷史資訊做出決策；二是從資料庫系統的角度將活動的事務處理從報告中分力出來，以便更加細緻地進行查詢，而不會影響使用者在OLTP系統中建立和儲存的資料的能力。

● 資料集市（Data Mart）――為彙總而優先的專用資料儲存，用於特定的場合，其儲存的內容作為資料倉儲的子集。資料集市通常使用被成為OLAP的技術進行處理。它通常為一個公司的特定需求，或一個機構的特定業務而建立的，一般有兩種特殊的資料庫結構：星型模式和雪花模式。

對於以上四種型別，最終採用的資料庫總體結構完全取決於該資料庫將要解決的問題規模。

現在的大部分計算機系統中，資料庫是核心。即使不是一個以資料庫為核心的系統，也擁有一個資料儲存的需要。軟體歸根結底，也是對資料的處理。

在Internet中，在銀行、政府機關、公司、學校、超市、藥店等地方，都有許多資料庫例項。這類資料庫設計的過程一般可以分解成下面幾個步驟：

● 定義目標――不要由於覺得顯而易見而一笑置之,這個很重要，因為很多專案都是由於開發者不清楚使用者實際上要做什麼或需要什麼，而冒然斷定或沒有能夠很好地聽取使用者的正確意見或全部意見而帶來的麻煩。在這個階段，我們要為最終建立的系統定義功能、效能、面向客戶群，並寫需求報告。

● 邏輯設計――為了達到最終的目標而，透過對使用者業務的分析，實施的邏輯設計

● 物理設計――利用邏輯設計的成果，並將其轉換成一個真正的實現。這個階段涉及到資料庫系統如何物理地實現以及我們需要使用那些硬體和軟體。

● 物理實現――專案的實現階段涉及實際的物理資料、資料庫伺服器的制定以及編寫存取資料的程式碼。

● 複查――評定是否達到最終目標的過程。大多數的專案都忽視了這個階段，原因是耗時太長，並且引發不起人們的一點興趣：測試、編寫文件以及完成一些不願意做，但又必須做的事情。這個階段，應該有一個利用使用者反饋資訊的方法和維護更改所有問題的計劃。

在使用者使用過程中，使用者實際只要能夠瀏覽和處理他們所需的資料，就很少對原始資料或者用來存取資料的實際介面感興趣。專案設計分析人員，可能因為這樣那樣原因，往往使一些系統使用起來非常笨拙，考慮欠佳的原因。

下面幾點是我從學校、從同事、從書籍，從實際設計中得到的一些概念設計經驗之談：

1、定義目標階段：資訊採集，收集資料庫專案中的資訊。

a、在這裡應該儘量避免一開始就設計結構。即使你具有資料庫設計的經驗，也不要在這裡定義表和欄位等等，你應該對它們逐步地進行處理。在聽取使用者講解其想法和需求，並歸納出該專案應該應該完成的任務之前，不要深入到某一個具體的部分。我們常常在對所完成的任務沒有足夠了解之前，就對它實施一種結構和一種解決方案，這樣即不利於客戶也不利於我們。

b、在分析過程中，儘快地將所需的資料編寫成文件是一個很好的習慣。例如：在公司，因為一個員工生病或者另謀高就，為了不對開發速度造成很大的影響，接替人員需全力以赴地瞭解專案的全部內容，能夠為其提供幫助的唯一途徑就是全部的資訊文件。因此你瞭解編寫文件重要性，要求是不把任何專案內容留在你的腦袋中。在對使用者需求進行記錄時應注意：

△ 維護一套共享的系統設計和說明書文件。文件應該主要包含：設計會議記錄，記錄口頭更改需求的文件和最終的所有說明書，比如，功能、技術、測試等各方面的內容。

△ 除了規範的文件外，要為所有的資訊而開發和維護一個公共資料庫。

△ 花一些時間召開會議，在客戶講述時，儘量不要發表你個人的意見。讓客戶暢所欲言，注意傾聽客戶的每一個建議、請求或想法。

△ 注意那些你新增的而沒有得到使用者許可的資訊。

△ 應早確立專案使用的範圍，並始終牢記在心。這樣做可以避免日後開發的專案過大或遺漏了有用的東西。編寫專案操作範圍的說明書（任務說明或任務物件），用以來描述專案的引數。該說明書應該在專案的設計、實現過程中不斷地進行協商、對比、完善，直到最後完成為止。若專案的物件和最終目標在這個階段不予確認，或者沒有記載任何內容，當你和客戶的想法出現不一致時，就很可能與使用者發生衝突。因此，要確保客戶對你將要實現的系統十分清楚，並使用清晰易懂的語言進行描敘，儘可能詳細描述專案所有內容。

c、在整個資料庫設計期間，客戶通常會對欄位名、欄位定義、業務規則、使用者介面和顏色做一些修改，為此，你要做好思想準備。無論客戶有什麼要求，都應該給予支援，這個專案最終要由使用者控制使用，所以你必須要使系統能夠靈活地適用各種用途的變化，不管是次要的還是主要的，但對於這些客戶的想法都要在客戶在設計階段對你做出的決策確認簽字的基礎上。

因為在任何時候，客戶都有可能對你說，“怎麼這裡少了一項”、“我根本沒這樣說”等等。如果你在說話時，手中沒有文件為自己撐腰，就會帶來很多麻煩。因此，儲存文件，如果你做出的決策與客戶所說的不同，就應該利用文件來證明自己決策的正確性。

d、資料庫原型作為公司與客戶簽定合約時相互交流資訊所使用的畫面。每次協商都要藉助於開發的原型，它可以很好的反映開發商最終開發的產品。資料庫設計者可以利用其為工作模型，設計文件所使用，避免使用者所需資訊的缺失。

e、與客戶商談時應注意，不要搶先發言；威脅客戶；以及在他們向你講述他們想要做的事情之前大談你的看法，而不顧使用者的期望都有可能造成專案的失敗。與客戶進行友善地商談是我們獲得設計資訊得堅實基礎。如果基礎不牢靠，最終的產品也不會成功。在向客戶提出：

1、誰使用這些資料？

2、如何使用這些資料？

3、客戶需要那些報表？

4、以前資料處理辦法？

5、由那些規則控制資料的使用？

這幾個問題都很有必要了解清楚。

2、邏輯設計階段

a、我認為在邏輯設計階段，應禁止談論效能問題，應該瞄準概念模型。作為一般建議，設計者最好嘗試規範化儘量高的級別。如果在系統測試中，發現了效能問題，則可以反向規範化這個系統。但我們永遠不要為了調整應用程式的效能而放棄規範化的結構。所以，提倡等到物理模型化階段或至少迫不得已的理由再反向規範化。

b、在邏輯設計結束，下一步開始時，建議考慮一下以下問題：

1、資料的用法

報表的處理；資料的使用和所有權；與外部系統的介面；資料轉換計劃

2、容量的測定

表和資料庫的增長

3、專案計劃

4、最後的文件複審

通讀所有文件，並對其修改和校準。使客戶在合同上簽字。

c、作為設計者，你還應對客戶在未來可能產生的需求進行必要預測和文件編寫。這樣可以在客戶未來的業務到來時，可以獲得更多的操作時間。

結束語

當然，隨著資料庫技術的發展，各種技術，新方法都會不斷的出現。這都需要我們在紛繁錯雜中去探尋，去發掘。