建立客戶資料庫有哪些原則

Ⅰ 大型資料庫的設計原則與開發技巧

隨著計算機技術越來越廣泛地應用於國民經濟的各個領域 在計算機硬體不斷微型化的同時 應用系統向著復雜化 大型化的方向發展 資料庫是整個系統的核心 它的設計直接關系系統執行的效率和系統的穩定性 因此在軟體系統開發中 資料庫設計應遵循必要的資料庫範式理論 以減少冗餘 保證數據的完整性與正確性 只有在合適的資料庫產品上設計出合理的資料庫模型 才能降低整個系統的編程和維護難度 提高系統的實際運行效率 雖然對於小項目或中等規模的項目開發人員可以很容易地利用範式理論設計出一套符合要求的資料庫 但對於一個包含大型資料庫的軟體項目 就必須有一套完整的設計原則與技巧

一 成立數據小組

大型資料庫數據元素多 在設計上有必要成立專門的數據小組 由於資料庫設計者不一定是使用者 對系統設計中的數據元素不可能考慮周全 資料庫設計出來後 往往難以找到所需的庫表 因此數據小組最好由熟悉業務的項目骨幹組成

數據小組的職能並非是設計資料庫 而是通過需求分析 在參考其他相似系顫腔統的基礎上 提取系統的基本數據元素 擔負對資料庫的審核 審核內容包括審核新的資料庫元素是否完全 能否實現全部業務需求 對舊資料庫（如果存在舊系統）的分析及數據轉換 資料庫設計的審核 控制及必要調整

二 設計原沖遲則

規范命名 所有的庫名 表名 域名必須遵循統一的命名規則 並進行必要說明 以方便設計 維護 查詢

控制欄位的引用 在設計時 可以選擇適當的資料庫設計管理工具 以方便開發人員的分布式設計和數據小組的集中審核管理 採用統一的命名規則 如果設計的欄位已經存在 可直接引用 否則 應重新設計

庫表重復控制 在設計過程中 如果發現大部分欄位都已存在 開發人員應懷疑所設計的庫表是否已存在 通過對欄位所在庫表及相應設計人員的查詢 可以確認庫表是否確實重復

並發控制 設計中應進行並發控制 即對於同一個庫表 在茄判衫同一時間只有一個人有控制權 其他人只能進行查詢

必要的討論 資料庫設計完成後 數據小組應與相關人員進行討論 通過討論來熟悉資料庫 從而對設計中存在的問題進行控制或從中獲取資料庫設計的必要信息

數據小組的審核 庫表的定版 修改最終都要通過數據小組的審核 以保證符合必要的要求

頭文件處理 每次數據修改後 數據小組要對相應的頭文件進行修改（可由管理軟體自動完成） 並通知相關的開發人員 以便進行相應的程序修改

三 設計技巧

分類拆分數據量大的表 對於經常使用的表（如某些參數表或代碼對照表） 由於其使用頻率很高 要盡量減少表中的記錄數量 例如 銀行的戶主賬表原來設計成一張表 雖然可以方便程序的設計與維護 但經過分析發現 由於數據量太大 會影響數據的迅速定位 如果將戶主賬表分別設計為活期戶主賬 定期戶主賬及對公戶主賬等 則可以大大提高查詢效率

索引設計 對於大的資料庫表 合理的索引能夠提高整個資料庫的操作效率 在索引設計中 索引欄位應挑選重復值較少的欄位 在對建有復合索引的欄位進行檢索時 應注意按照復合索引欄位建立的順序進行 例如 如果對一個 萬多條記錄的流水表以日期和流水號為序建立復合索引 由於在該表中日期的重復值接近整個表的記錄數 用流水號進行查詢所用的時間接近 秒 而如果以流水號為索引欄位建立索引進行相同的查詢 所用時間不到 秒 因此在大型資料庫設計中 只有進行合理的索引欄位選擇 才能有效提高整個資料庫的操作效率

數據操作的優化 在大型資料庫中 如何提高數據操作效率值得關注 例如 每在資料庫流水表中增加一筆業務 就必須從流水控製表中取出流水號 並將其流水號的數值加一 正常情況下 單筆操作的反應速度尚屬正常 但當用它進行批量業務處理時 速度會明顯減慢 經過分析發現 每次對流水控製表中的流水號數值加一時都要鎖定該表 而該表卻是整個系統操作的核心 有可能在操作時被其他進程鎖定 因而使整個事務操作速度變慢 對這一問題的解決的辦法是 根據批量業務的總筆數批量申請流水號 並對流水控製表進行一次更新 即可提高批量業務處理的速度 另一個例子是對插表的優化 對於大批量的業務處理 如果在插入資料庫表時用普通的Insert語句 速度會很慢 其原因在於 每次插表都要進行一次I/O操作 花費較長的時間 改進後 可以用Put語句等緩沖區形式等滿頁後再進行I/O操作 從而提高效率 對大的資料庫表進行刪除時 一般會直接用Delete語句 這個語句雖然可以進行小表操作 但對大表卻會因帶來大事務而導致刪除速度很慢甚至失敗 解決的方法是去掉事務 但更有效的辦法是先進行Drop操作再進行重建

資料庫參數的調整 資料庫參數的調整是一個經驗不斷積累的過程 應由有經驗的系統管理員完成 以Informix資料庫為例 記錄鎖的數目太少會造成鎖表的失敗 邏輯日誌的文件數目太少會造成插入大表失敗等 這些問題都應根據實際情況進行必要的調整

必要的工具 在整個資料庫的開發與設計過程中 可以先開發一些小的應用工具 如自動生成庫表的頭文件 插入數據的初始化 數據插入的函數封裝 錯誤跟蹤或自動顯示等 以此提高資料庫的設計與開發效率

避免長事務 對單個大表的刪除或插入操作會帶來大事務 解決的辦法是對參數進行調整 也可以在插入時對文件進行分割 對於一個由一系列小事務順序操作共同構成的長事務（如銀行交易系統的日終交易） 可以由一系列操作完成整個事務 但其缺點是有可能因整個事務太大而使不能完成 或者 由於偶然的意外而使事務重做所需的時間太長 較好的解決方法是 把整個事務分解成幾個較小的事務 再由應用程序控制整個系統的流程 這樣 如果其中某個事務不成功 則只需重做該事務 因而既可節約時間 又可避免長事務

適當超前 計算機技術發展日新月異 資料庫的設計必須具有一定前瞻性 不但要滿足當前的應用要求 還要考慮未來的業務發展 同時必須有利於擴展或增加應用系統的處理功能

Ⅱ 資料庫設計的基本步驟

資料庫設計的基本步驟

1、需求分析階段

進行資料庫設計首先必須准確了解與分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，是最困難和最耗費時間的一步。作為「地基」的需求分析是否做得充分與准確，決定了在其上構建資料庫「碼嘩大廈」的速度與質量。需求分析做的不好，可能會導致整個資料庫設計返工重做。

2、概念結構設計階段

概念結構設計階段是整個資料庫設計的關鍵，它通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體資料庫管理系統升賀的概念模型。

3、邏輯結構設計階段

邏輯結構設計是將概念結構轉換為某個資料庫管理系統所支持的數據模型，並對其進行優化。

4、物理設計階段

物理結構設計師為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方式）。

5、資料庫實施階段

在資料庫實施階段，設計人員運用資料庫管理系統提供資料庫語言及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編寫與調試應用程序，組織數據入庫，並進行測試運行。

6、資料庫運行和維護階段

資料庫應用系統經過試運行後即可投入正式運行，在資料庫系統運行過程中必須不斷對其進行評估、調整與修改。

資料庫設計的基本原則

1、一致性原則：對數據來源進行統一、系統的分析與設計，協調好各種數據源，保證數據的一致性和有效性。

2、完整性原則：資料庫的完整性是指數據的正確性和相容性。要防止合遲笑行法用戶使用資料庫時向資料庫加入不合語義的數據。對輸入到資料庫中的數據要有審核和約束機制。

3、安全性原則：資料庫的安全性是指保護數據，防止非法用戶使用資料庫或合法用戶非法使用資料庫造成數據泄露、更改或破壞。要有認證和授權機制。

4、可伸縮性與可擴展性原則：資料庫結構的設計應充分考慮發展的需要、移植的需要，具有良好的擴展性、伸縮性和適度冗餘。

5、規范化原則：資料庫的設計應遵循規范化理論。規范化的資料庫設計，可以減少資料庫插入、刪除、修改等操作時的異常和錯誤，降低數據冗餘度等。

Ⅲ 創建資料庫有哪幾種方法

創建資料庫的方法有兩種，使用向導創建資料庫，使用菜單創建資料庫和創建空資料庫；使用向導創建資料庫是一種簡單便捷的方法。

在物理上，資料庫的建設要遵循實際情況。即在邏輯上建立一個整體的空間數據車、框架統一設計的同時，各級比例尺和不同數據源的數據分別建成子庫，由開發的平台管理軟體來統一協調與調度。

(3)建立客戶資料庫有哪些原則擴展閱讀：

在建庫時，要充分考慮數據有效共享的需求消伏，同時也要保證數據訪問的合法性螞橋爛和安全性。資料庫採用統一的坐標系統悶漏和高程基準，矢量數據採用大地坐標大地坐標的數據在數值上是連續的，避免高斯投影跨帶問題，從而保證資料庫地理對象的完整性，為資料庫的查詢檢索、分析應用提供方便。

在創建資料庫之時，要重點考慮獨立與完整性原則、面向對象的資料庫設計原則、建庫與更新有機結合的原則、分級共享原則、並發性原則、實用性原則。

Ⅳ 建立資料庫的原則（怎樣建立一個好的資料庫）

主目錄分類要清楚詳細（也就是要實現的功能）無論是自己,或別人看到你的資料庫名(或表名)都一鉛陪激目瞭然。
****每個表之間的關聯要明確，表之間的訪問，可讀寫（也就是安全，約束）要明確***這點最重要。
在表欄位追加方式和追加內容要明確（每個表欄位之間的關系一定要清楚，不然到時候會給你的表結構帶來許多不便）。
在這之前最好是寫出詳細的需求分析說明，用圖把層次結構畫出來，這要在建的時候才不會混亂。
還有就是當你在寫程序涉及到資料庫的時候，如果你的WEB（FORM）與最初設計的資料庫需求分析不同的話，最好是把需求分析也改為一致。這樣才能夠同步。盡量避免寫程序亂喚的時候再回頭設計資料庫。
以上是我自己的看法，可能同行內有更好的解決辦法，槐襪多多參考.多多總結..

Ⅳ 請問:資料庫建表時的原則是什麼

1. 原始單據與實體之間的關系
可以是滲雹和一對一、一對多、多對多的關系。在一般情況下，它們是一對一的關系：即一張原始單據對應且只對應一個實體。在特殊情況下，它們可能是一對多或多對一的關系，即一張原始單證對應多個實體，或多張原始單證對應一個實體。這里的實體可以理解為基本表。明確這種對應關系後，對我們設計錄入界面大有好處。

〖例1〗：一份員工履歷資料，在人力資源信息系統中，就對應三個基本表：員工基本情況表、社會關系表、工作簡歷表。這就是「一張原始單證對應多個實體」的典型例子。

2. 主鍵與外鍵
一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與外鍵的配對，表示實體之間的連接。

3. 基本表的性質
基本表與中間表、臨時表不同，因為它具有如下四個特性：
(1) 原叢盯子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始數據（基礎數據）的記錄。
(3) 演繹性。由基本表與代碼表中的數據，可以派生出所有的輸出數據。
(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。
理解基本表的性質後，在設計資料庫時，就能將基本表與中間表、臨時表區分開來。

4. 範式標准
基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。

〖例2〗：有一張存放商品的基本表，如表1所示。「金額」這個欄位的存在，表明該表的設計不滿足第三範式，因為「金額」可以由「單價」乘以「數量」得到，說明「金額」是冗餘欄位。但是，增加「金額」這個冗餘欄位，可以提高查詢統計的速度，這就是以空間換時間的作法。
在Rose 2002中，規定列有兩種類型：數據列和計算列。「金額」這樣的列被稱為「計算列」，而「單價」和「數量」這樣的列被稱為「數據列」。
表1 商品表的表結構
商品名稱 商品型號 單價 數量 金額
電視機 29吋 2,500 40 100,000

5. 通俗地理解三個範式
通俗地理解三個范肆納式，對於資料庫設計大有好處。在資料庫設計中，為了更好地應用三個範式，就必須通俗地理解三個範式(通俗地理解是夠用的理解，並不是最科學最准確的理解)：
第一範式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解；
第二範式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；
第三範式：3NF是對欄位冗餘性的約束，即任何欄位不能由其他欄位派生出來，它要求欄位沒有冗餘.
沒有冗餘的資料庫設計可以做到。但是，沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降低範式標准，適當保留冗餘數據。具體做法是：在概念數據模型設計時遵守第三範式，降低範式標準的工作放到物理數據模型設計時考慮。降低範式就是增加欄位，允許冗餘。

6. 要善於識別與正確處理多對多的關系
若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。

〖例3〗：在「圖書館信息系統」中，「圖書」是一個實體，「讀者」也是一個實體。這兩個實體之間的關系，是一個典型的多對多關系：一本圖書在不同時間可以被多個讀者借閱，一個讀者又可以借多本圖書。為此，要在二者之間增加第三個實體，該實體取名為「借還書」，它的屬性為：借還時間、借還標志(0表示借書，1表示還書)，另外，它還應該有兩個外鍵(「圖書」的主鍵，「讀者」的主鍵)，使它能與「圖書」和「讀者」連接。

7. 主鍵PK的取值方法
PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。

8. 正確認識數據冗餘
主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。

〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。

9. E--R圖沒有標准答案
信息系統的E--R圖沒有標准答案，因為它的設計與畫法不是惟一的，只要它覆蓋了系統需求的業務范圍和功能內容，就是可行的。反之要修改E--R圖。盡管它沒有惟一的標准答案，並不意味著可以隨意設計。好的E—R圖的標準是：結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。

10. 視圖技術在資料庫設計中很有用
與基本表、代碼表、中間表不同，視圖是一種虛表，它依賴數據源的實表而存在。視圖是供程序員使用資料庫的一個窗口，是基表數據綜合的一種形式, 是數據處理的一種方法，是用戶數據保密的一種手段。為了進行復雜處理、提高運算速度和節省存儲空間, 視圖的定義深度一般不得超過三層。 若三層視圖仍不夠用, 則應在視圖上定義臨時表, 在臨時表上再定義視圖。這樣反復交迭定義, 視圖的深度就不受限制了。

對於某些與國家政治、經濟、技術、軍事和安全利益有關的信息系統，視圖的作用更加重要。這些系統的基本表完成物理設計之後，立即在基本表上建立第一層視圖，這層視圖的個數和結構，與基本表的個數和結構是完全相同。並且規定，所有的程序員，一律只准在視圖上操作。只有資料庫管理員，帶著多個人員共同掌握的「安全鑰匙」，才能直接在基本表上操作。請讀者想想：這是為什麼？

11. 中間表、報表和臨時表
中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。

12. 完整性約束表現在三個方面
域的完整性：用Check來實現約束，在資料庫設計工具中，對欄位的取值范圍進行定義時，有一個Check按鈕，通過它定義欄位的值城。參照完整性：用PK、FK、表級觸發器來實現。用戶定義完整性：它是一些業務規則，用存儲過程和觸發器來實現。

13. 防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性) 的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。

14. 提高資料庫運行效率的辦法
在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用C++語言計算處理完成之後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。

上述十四個技巧，是許多人在大量的資料庫分析與設計實踐中，逐步總結出來的。對於這些經驗的運用，讀者不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。並逐步做到：在應用中發展，在發展中應用。

Ⅵ 企業如何建立客戶資料庫

客戶關系管理，是建立在以客戶為中心元素的信息協同管理。其目的是讓公司的管理層能夠很好跟蹤銷售的趨勢，並建立些策略來應對銷售中的問題。在客戶關系管理系統的設計上，國外的專家，力圖讓客戶關系管理系統具備營銷的功能，即所謂的營銷輔助支持（前面即所謂的銷售自動化）。那麼這個營銷的輔助支持是如何體現在營銷和市場中。它的關鍵就是全面的客戶資料庫，這個資料庫發展起來就將成企業核心競爭力。 1）客戶數據的收集平台 要想建立一個全面，立體客戶資料庫，必須依託一個平台的強大運作。不管是採用電子表格報告形式，還是利用一個分布式信息系統，都必須跨空間的，並且橫渡時間坐標的。我們知道一個信息系統在技術上都能具備分布和實時性，一個好的信息系統就可以做到。 2）客戶數據的收集過程 客戶數據的收集過程，是企業管理之功。漢江源於精楚大地的山川，而漢江將匯於長江，追溯長江，還有諸多支流，同樣源於中華的山川。長江黃河是中華的生命動脈，對於企業來說把握好自己的動脈，將來才可以形成企業的核心競爭力。 3）客戶數據的分級策略 管理者的運籌帷幄，必須把不可控的因素，都變成准可控因素，方能勝！治軍，日日不廢，治客戶數據，也需策之入日，同樣是日日不廢。 4）客戶數據的分析平台 有了以上的步驟和海量客戶數據，那麼你的營銷策略，市場策略就可以啟航，同時你的企業「核心競爭力」就形成拉。因此客戶關系管理是一個長期的效益的工程，並且一定是「人之為」，加上新技術的充分利用。

Ⅶ 建立資料庫的原則（怎樣建立一個好的資料庫）

資料庫設計原則2007-05-26 01:08一個好的資料庫產品不等於就有一個好的應用系統，如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。一般來講，在一個MIS系統分析、設計、測試和試運行階段，因為數據量較小，設計人員和測試人員往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低……

資料庫設計是建立資料庫及其應用系統的核心和基礎，它要求對於指定的應用環境，構造出較優的資料庫模式，建立起資料庫應用系統，並使系統能有效地存儲數據，滿足用戶的各種應用需求。一般按照規范化的設計方法，常將資料庫設計分為若干階段：

系統規劃階段
主要是確定系統的名稱、范圍；確定系統開發的目標功能和性能；確定系統所需的資源；估計系統開發的成本；確定系統實施計劃及進度；分析估算系統可能達到的效益；確定系統設計的原則和技術路線等。對分布式資料庫系統，還應分析用戶環境及網路條件，以選擇和建立系統的網路結構。

需求分析階段
要在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。通過對組織、部門、企業等進行詳細調查，在了解現行系統的概況、確定新系統功能的過程中，收集支持系統目標的基礎數據及其處理方法。

概念設計階段
要產生反映企業各組織信息需求的資料庫概念結構，即概念模型。概念模型必須具備豐富的語義表達能力、易於交流和理解、易於變動、易於向各種數據模型轉換、易於從概念模型導出與DBMS有關的邏輯模型等特點。

邏輯設計階段
除了要把E－R圖的實體和聯系類型，轉換成選定的DBMS支持的數據類型，還要設計子模式並對模式進行評價，最後為了使模式適應信息的不同表示，需要優化模式。

物理設計階段
主要任務是對資料庫中數據在物理設備上的存放結構和存取方法進行設計。資料庫物理結構依賴於給定的計算機系統，而且與具體選用的DBMS密切相關。物理設計常常包括某些操作約束，如響應時間與存儲要求等。

系統實施階段
主要分為建立實際的資料庫結構；裝入試驗數據對應用程序進行測試；裝入實際數據建立實際資料庫三個步驟。

另外，在資料庫的設計過程中還包括一些其他設計，如資料庫的安全性、完整性、一致性和可恢復性等方面的設計,不過，這些設計總是以犧牲效率為代價的,設計人員的任務就是要在效率和盡可能多的功能之間進行合理的權衡。
一個好的資料庫產品不等於就有一個好的應用系統，如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。一般來講，在一個MIS系統分析、設計、測試和試運行階段，因為數據量較小，設計人員和測試人員往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低……

資料庫設計是建立資料庫及其應用系統的核心和基礎，它要求對於指定的應用環境，構造出較優的資料庫模式，建立起資料庫應用系統，並使系統能有效地存儲數據，滿足用戶的各種應用需求。一般按照規范化的設計方法，常將資料庫設計分為若干階段：

系統規劃階段
主要是確定系統的名稱、范圍；確定系統開發的目標功能和性能；確定系統所需的資源；估計系統開發的成本；確定系統實施計劃及進度；分析估算系統可能達到的效益；確定系統設計的原則和技術路線等。對分布式資料庫系統，還應分析用戶環境及網路條件，以選擇和建立系統的網路結構。

需求分析階段
要在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。通過對組織、部門、企業等進行詳細調查，在了解現行系統的概況、確定新系統功能的過程中，收集支持系統目標的基礎數據及其處理方法。

概念設計階段
要產生反映企業各組織信息需求的資料庫概念結構，即概念模型。概念模型必須具備豐富的語義表達能力、易於交流和理解、易於變動、易於向各種數據模型轉換、易於從概念模型導出與DBMS有關的邏輯模型等特點。

邏輯設計階段
除了要把E－R圖的實體和聯系類型，轉換成選定的DBMS支持的數據類型，還要設計子模式並對模式進行評價，最後為了使模式適應信息的不同表示，需要優化模式。

物理設計階段
主要任務是對資料庫中數據在物理設備上的存放結構和存取方法進行設計。資料庫物理結構依賴於給定的計算機系統，而且與具體選用的DBMS密切相關。物理設計常常包括某些操作約束，如響應時間與存儲要求等。

系統實施階段
主要分為建立實際的資料庫結構；裝入試驗數據對應用程序進行測試；裝入實際數據建立實際資料庫三個步驟。

另外，在資料庫的設計過程中還包括一些其他設計，如資料庫的安全性、完整性、一致性和可恢復性等方面的設計,不過，這些設計總是以犧牲效率為代價的,設計人員的任務就是要在效率和盡可能多的功能之間進行合理的權衡。

http://www.crazycoder.cn/Tag/29113/Index.html

例子
http://www.ibm.com/developerworks/cn/db2/library/techarticles/dm-0605jiangt/

Ⅷ 建立CRM資料庫的幾個原則

CRM（Customer Relationship Management）即客戶關系管理。是指企業用CRM技術來管理與客戶之間的關系。在不同場合下，CRM可能是一個管理學術語，可能是一個軟體系統，通常所指的CRM，指用計叢衫算機自動化分析銷售、市場營銷、客戶服務以及應用支持等流程的族爛軟體兆鄭漏系統。
它的目標是縮減銷售周期和銷售成本、增加收入、尋找擴展業務所需的新的市場和渠道以及提高客戶的價值、滿意度、贏利性和忠實度。CRM項目的實施可以分為3步，即應用業務集成，業務數據分析和決策執行。
CRM是選擇和管理有價值客戶及其關系的一種商業策略，CRM要求以客戶為中心的企業文化來支持有效的市場營銷、銷售與服務流程。

Ⅸ 在系統設計中，對資料庫的設計應考慮哪些設計原則

資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計禪仿巧師所必須具備的基本素質條件！
那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則：
1、資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。
2、資料庫設計不僅僅停留於頁面demo的表面
頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。
3、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了
每個欄位的設計都是大友有他必要賀鍵的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。
4、資料庫設計時就要考慮到效率和優化問題
一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。
5、添加必要的（冗餘）欄位
像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。
6、設計合理的表關聯
若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。
7、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯
這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。
8、選擇合適的主鍵生成策略

Ⅹ 企業如何建立客戶資料庫

1.盡可能完整地保存客戶資料
現在的資料庫具有非常強大的處理能力，但是無淪怎樣處理，原始數據總是最寶貴的。有了完整的原始數據，隨時都可以通過再次加工，獲得需要的結果。但如果原始數據缺失嚴重，數據處理後的結果也將失去准確性和指導意義。
2.區分經營過程中與通過其他渠道獲得的客戶資料
企業內部資料主要是一些銷售記錄、客戶購買活動的記錄以及促銷等市場活動中獲得的直接客戶資料。這些資料具有很高的價值，具體表現在：首先是這些資料具有極大的真實性，其次是這些資料是企業產品的直接消費者，對公司經營的產品已經產生了理性的認識。外部數據是指企業從數據調查公司、政府機構、行業協會、信息中心等機構獲得的數據，這些數據最重要的特徵是其中記載的客戶是企業的潛在消費者，所以是企業展開營銷活動的對象。但是，這些數據真實性較差、數據過時、不能回答企業要求的問題，需要在應用過程中不斷地修改和更正。
3.確保資料庫管理的安全性
企業應確保記錄在計算機系統中的資料庫安全地運行，如果這些數據意外損失或者外流，將給企業造成難以估量的損失。因此，需要加強安全管理，建立資料庫專人管理和維護的機制。
4.隨時更新與維護
資料庫中的數據是死的，而客戶是動態的，因此，客戶的資料也應該是活的。企業要想充分享受資料庫帶來的利益，千萬別怕浪費精力和金錢，一定要盡可能地完成客戶資料的隨時更新，將新鮮的數據錄入到資料庫中，這樣才有意義。