什麼是數據存儲設計
① 什麼是資料庫的概念設計、邏輯設計、物理設計，以及三者的關系
1、概念設計：
對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。
所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。
2、邏輯設計：
主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。
3、物理設計：
根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。這一步設計的結果就是所謂「物理資料庫」。
4、三者關系：
由上到下，先要概念設計，接著邏輯設計，再是物理設計，一級一級設計。三者一環扣住一環，缺一不可，概念設計是前提，邏輯設計是紐扣，將概念設計和物理設計緊密聯系起來，物理設計的結果就是傳說中的「物理資料庫」也就是最後的結果。三者密不可分，缺一不可。
(1)什麼是數據存儲設計擴展閱讀
資料庫設計的基本步驟：
1、需求分析階段：准確了解與分析用戶需求（包括數據與處理），是整個設計過程的基礎，是最困難、最耗費時間的一步。
2、概念結構設計階段：是整個資料庫設計的關鍵,通過對用戶的需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型。從實際到理論。
3、邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型,對其進行優化。優化理論。
4、資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。選擇理論落腳點。
5、資料庫實施階段：運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果,建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。理論應用於實踐。
6、資料庫運行和維護階段：資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。理論指導實踐，反過來實踐修正理論。
主要特點：
1、 實現數據共享：資料庫伺服器數據共享包含所有用戶可同時存取資料庫中的數據，也包括用戶可以用各種方式通過介面使用資料庫，並提供數據共享。
2、 減少數據的冗餘度：同文件系統相比，由於資料庫實現了數據共享，從而避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據冗餘，維護了數據的一致性。
3、數據的獨立性：數據的獨立性包括邏輯獨立性（資料庫中資料庫的 邏輯結構和 應用程序相互獨立）和物理獨立性（數據物理結構的變化不影響數據的邏輯結構）。
4、數據實現集中控制：文件管理方式中，數據處於一種分散的狀態，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用資料庫可對數據進行集中控制和管理，並通過 數據模型表示各種數據的組織以及數據間的聯系。
5、數據一致性和可維護性，以確保數據的安全性和可靠性主要包括：安全性控制：以防止數據丟失、錯誤更新和越權使用；完整性控制：保證數據的正確性、有效性和相容性；並發控制：使在同一時間 周期內，允許對數據實現多路存取，又能防止用戶之間的不正常交互作用。
6、故障恢復：由資料庫管理系統提供一套方法，可及時發現故障和修復故障，從而防止數據被破壞。資料庫系統能盡快恢復資料庫系統運行時出現的故障，可能是物理上或是邏輯上的錯誤。比如對系統的誤操作造成的數據錯誤等。
② 資料庫設計
說起資料庫設計，相信大家都明白怎麼回事，但說起資料庫設計的重要性，我想大家也只是停留在概念上而已，到底如何重要？怎麼重要呢？今天就將我至今為止的理解向大家闡述下。
一個不良的資料庫設計，必然會造成很多問題，輕則增減欄位，重則系統無法運行。我先來說說資料庫設計不合理的表現吧：
1. 與需求不符
因為這個原因造成的改動量往往是最大。如果進入編碼階段的話，很可能會直接讓你崩潰掉。
2. 性能低下
含有大數據量的表之間的關聯過多；沒有合理的欄位設計來用於查詢而造成的SQL查詢語句很復雜；對於大數據量的表沒有採用有效的手段去處理；濫用視圖等。
3. 數據完整性喪失
含有主外鍵關系的表之間關聯欄位的設計方式不合理，造成更新與刪除操作後程序容易出錯或不完善；使用了已經刪除或丟失掉的數據。
4. 可擴展性性太差
表設計的與業務綁定的太緊密、單一，造成表的可拓展性、可修改性太差，無法新需求的要求。
5. 非必要數據冗餘量太大
沒用的垃圾數據存儲過多，不僅佔用資源，還影響查詢效率。
6. 不利於計算或統計
缺少必要的聯系性或統計性欄位或用於計算統計的欄位分散於多個表中，造成計算統計的步驟繁瑣，甚至無法計算統計。
7. 沒有詳盡的數據記錄信息
缺少必要的欄位，造成無法跟蹤數據變化、用戶操作，也無法進行數據分析。
8. 表之間的耦合性太大
多張表之間關聯的過於緊密，造成一張表發生變化而影響到其他表。
9. 欄位設計考慮不周
欄位長度過短或欄位類型過於明確，造成可發揮、可拓展的空間太小。
大多數的程序員對於軟體開發的出發點認識不是很明確，總是認為實現功能才是重要的，在簡單了解完基本需求後就急忙進入編碼階段，對於資料庫設計思考的比較少、比較簡單，大多設計都只停留在表面上，這往往是要命的，會為系統留下很多隱患。要麼是寫代碼開發過程中才發現問題，要麼就是系統上線運轉後沒多久就出現問題，還有可能給後期維護增加了很多工作量。如果到了那個時候再想修改資料庫設計或進行優化等同於推翻重來。
資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！
那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則
1. 資料庫設計最起碼要佔用整個項目開發的40%以上的時間
資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。
2. 資料庫設計不僅僅停留於頁面demo的表面
頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。
3. 資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了
每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。
4. 資料庫設計時就要考慮到效率和優化問題
一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。
5. 添加必要的（冗餘）欄位
像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。
6. 設計合理的表關聯
若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。
7. 設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯
這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。
8. 選擇合適的主鍵生成策略
主鍵生成策略大致可分：int自增長類型（identity、sequence）、手動增長類型（建立單獨一張表來維護）、手動維護類型（如userId）、字元串類型（uuid、guid）。int型的優點是使用簡單、效率高，但多表之間數據合並時就很容易出現問題，手動增長類型和字元串類型能很好解決多表數據合並的問題，但同樣也都有缺點：前者的缺點是增加了一次資料庫訪問來獲取主鍵，並且又多維護一張主鍵表，增加了復雜度；而後者是非常佔用存儲空間，且表關聯查詢的效率低下，索引的效率也不高，跟int類型正好相反。
終上所述，我們可見資料庫設計在整個軟體開發的起到的舉足輕重的作用，尤其是我說的設計原則的第一點，資料庫與需求是相輔相成的，我經常把軟體開發比作汽車製造。汽車製造會經過圖紙設計，模型製作，樣車製造，小批量試生產，最後是批量生產等步驟。整個過程環環相扣，後一過程是建立在前一過程正確的前提基礎之上的。如果在圖紙設計階段發現了一個紕漏，我們可以重新進行圖紙設計，如果到了樣車製造階段發現這個錯誤，那麼我們就要把從圖紙設計到樣車製造的階段重來，越到後面發現設計上的問題，所付出的代價越大，修改的難度也越大。
資料庫設計難度其實要比單純的技術實現的難很多，他充分體現了一個人的全局設計能力和掌控能力，所以在今後的項目中大家一定要著重培養這方面的能力，這里我將我的經驗分享給了大家，希望能對大家有所幫助。
③ 數據存儲的三類簡介
一、DAS(Direct Attached Storage)直接附加存儲，DAS這種存儲方式與我們普通的PC存儲架構一樣，外部存儲設備都是直接掛接在伺服器內部匯流排上，數據存儲設備是整個伺服器結構的一部分。
DAS存儲方式主要適用以下環境：
(1)小型網路
因為網路規模較小，數據存儲量小，且也不是很復雜，採用這種存儲方式對伺服器的影響不會很大。並且這種存儲方式也十分經濟，適合擁有小型網路的企業用戶。
(2)地理位置分散的網路
雖然企業總體網路規模較大，但在地理分布上很分散，通過SAN或NAS在它們之間進行互聯非常困難，此時各分支機構的伺服器也可採用DAS存儲方式，這樣可以降低成本。
(3)特殊應用伺服器
在一些特殊應用伺服器上，如微軟的集群伺服器或某些資料庫使用的原始分區，均要求存儲設備直接連接到應用伺服器。
(4)提高DAS存儲性能
在伺服器與存儲的各種連接方式中，DAS曾被認為是一種低效率的結構，而且也不方便進行數據保護。直連存儲無法共享，因此經常出現的情況是某台伺服器的存儲空間不足，而其他一些伺服器卻有大量的存儲空間處於閑置狀態卻無法利用。如果存儲不能共享，也就談不上容量分配與使用需求之間的平衡。
DAS結構下的數據保護流程相對復雜，如果做網路備份，那麼每台伺服器都必須單獨進行備份，而且所有的數據流都要通過網路傳輸。如果不做網路備份，那麼就要為每台伺服器都配一套備份軟體和磁帶設備，所以說備份流程的復雜度會大大增加。
想要擁有高可用性的DAS存儲，就要首先能夠降低解決方案的成本，例如：LSI的12Gb/s SAS，在它有DAS直聯存儲，通過DAS能夠很好的為大型數據中心提供支持。對於大型的數據中心、雲計算、存儲和大數據，所有這一切都對DAS存儲性能提出了更高的要求，雲和企業數據中心數據的爆炸性增長也推動了市場對於可支持更高速數據訪問的高性能存儲介面的需求，因而LSI 12Gb/s SAS正好是能夠滿足這種性能增長的要求，它可以提供更高的IOPS和更高的吞吐能力，12Gb/s SAS提高了更高的寫入的性能，並且提高了RAID的整個綜合性能。
與直連存儲架構相比，共享式的存儲架構，比如SAN（storage-area network）或者NAS（network-attached storage）都可以較好的解決以上問題。於是乎我們看到DAS被淘汰的進程越來越快了。可是到2012年為止，DAS仍然是伺服器與存儲連接的一種常用的模式。事實上，DAS不但沒有被淘汰，近幾年似乎還有回潮的趨勢。 二、NAS(Network Attached Storage)數據存儲方式
NAS(網路附加存儲)方式則全面改進了以前低效的DAS存儲方式。它採用獨立於伺服器，單獨為網路數據存儲而開發的一種文件伺服器來連接所存儲設備，自形成一個網路。這樣數據存儲就不再是伺服器的附屬，而是作為獨立網路節點而存在於網路之中，可由所有的網路用戶共享。
NAS的優點：
(1)真正的即插即用
NAS是獨立的存儲節點存在於網路之中，與用戶的操作系統平台無關，真正的即插即用。
(2)存儲部署簡單
NAS不依賴通用的操作系統，而是採用一個面向用戶設計的，專門用於數據存儲的簡化操作系統，內置了與網路連接所需要的協議，因此使整個系統的管理和設置較為簡單。
(3)存儲設備位置非常靈活
(4)管理容易且成本低
NAS數據存儲方式是基於現有的企業Ethernet而設計的，按照TCP/IP協議進行通信，以文件的I/O方式進行數據傳輸。
NAS的缺點：
(1)存儲性能較低(2)可靠度不高 三、SAN(Storage Area Network)存儲方式
1991年，IBM公司在S/390伺服器中推出了ESCON(Enterprise System Connection)技術。它是基於光纖介質，最大傳輸速率達17MB/s的伺服器訪問存儲器的一種連接方式。在此基礎上，進一步推出了功能更強的ESCON Director(FC SWitch)，構建了一套最原始的SAN系統。
SAN存儲方式創造了存儲的網路化。存儲網路化順應了計算機伺服器體系結構網路化的趨勢。SAN的支撐技術是光纖通道(FC Fiber Channel)技術。它是ANSI為網路和通道I/O介面建立的一個標准集成。FC技術支持HIPPI、IPI、SCSI、IP、ATM等多種高級協議，其最大特性是將網路和設備的通信協議與傳輸物理介質隔離開，這樣多種協議可在同一個物理連接上同時傳送。
SAN的硬體基礎設施是光纖通道，用光纖通道構建的SAN由以下三個部分組成：
(1)存儲和備份設備：包括磁帶、磁碟和光碟庫等。
(2)光纖通道網路連接部件：包括主機匯流排適配卡、驅動程序、光纜、集線器、交換機、光纖通道和SCSI間的橋接器
(3)應用和管理軟體：包括備份軟體、存儲資源管理軟體和存儲設備管理軟體。
SAN的優勢：
(1)網路部署容易；
(2)高速存儲性能。因為SAN採用了光纖通道技術，所以它具有更高的存儲帶寬，存儲性能明顯提高。SAn的光纖通道使用全雙工串列通信原理傳輸數據，傳輸速率高達1062.5Mb/s。
(3)良好的擴展能力。由於SAN採用了網路結構，擴展能力更強。光纖介面提供了10公里的連接距離，這使得實現物理上分離，不在本地機房的存儲變得非常容易。 DAS、NAS和SAN三種存儲方式比較
存儲應用最大的特點是沒有標準的體系結構，這三種存儲方式共存，互相補充，已經很好滿足企業信息化應用。
從連接方式上對比，DAS採用了存儲設備直接連接應用伺服器，具有一定的靈活性和限制性；NAS通過網路（TCP/IP,ATM,FDDI）技術連接存儲設備和應用伺服器，存儲設備位置靈活，隨著萬兆網的出現，傳輸速率有了很大的提高；SAN則是通過光纖通道（Fibre Channel）技術連接存儲設備和應用伺服器，具有很好的傳輸速率和擴展性能。三種存儲方式各有優勢，相互共存，佔到了磁碟存儲市場的70%以上。SAN和NAS產品的價格仍然遠遠高於DAS.許多用戶出於價格因素考慮選擇了低效率的直連存儲而不是高效率的共享存儲。
客觀的說，SAN和NAS系統已經可以利用類似自動精簡配置（thin provisioning）這樣的技術來彌補早期存儲分配不靈活的短板。然而，之前它們消耗了太多的時間來解決存儲分配的問題，以至於給DAS留有足夠的時間在數據中心領域站穩腳跟。此外，SAN和NAS依然問題多多，至今無法解決。
④ 雲計算環境中的數據挖掘存儲管理設計
雲計算環境中的數據挖掘存儲管理設計
1.引言
Hadoop提供了一個基於HDFs的簡單資料庫HBase，它的設計思想和數據模型都與Google開發的模型簡化的大規模分布式資料庫BigTabIe極為相似。HBase不支持完全的關系數據模型，只為用戶提供了簡單的數據模型，讓客戶來動態控制數據的分布和格式。從數據模型角度看，HBase是一個稀疏的、長期存儲的（存在硬碟上）、多維度的、排序的映射表。這張表的索引是行關鍵字、列關鍵字和時間戳。每個值是一個不解釋的字元數組，用戶需要自己解釋存儲的字串的類型和含義。這種模型具有很大的靈活性，通過仔細選擇數據表示，用戶可以控制數據的局部化。但是這種靈活性的代價就是不支持完全的關系數據模型，這導致傳統的數據存儲格式無法應用於HBase。Google自身的GFS是為網頁搜索功能量身定做的，採用BigTable的簡單數據模型可以以字元串形式靈活存儲網頁的URL、時間戳等信息。HDFS的設計完全借鑒了GFS的思想，因此從目前的版本來看，HDFS對網頁搜索具有較好的支持，但是對於使用傳統的關系數據模型的產品來說，HDFS並不是一個很好的選擇，因為它不能提供傳統的關系資料庫的相關功能。如上所述，以Hadoop為例，目前的開源解決方案並不完全適用於某公司的新產品需求，因此我們需要參照現有解決方案，設計符合自身需要的新方案。
2.DDF的數據劃分策略
面對大量的異構的用戶數據，我們有必要對數據進行劃分，以期得到更好的查詢性能。
數據劃分策略可分為垂直數據劃分（Horizontal panition）和水平數據劃分（VerticaI partition），在DDF中同時採用了這兩種劃分策略。垂直數據劃分是按照功能劃分：
（1）首先把對象數據、查詢數據和其他數據劃分到不同的數據表中（資料庫的表）。
（2）對於對象數據，由於是按對象類型（Object type）訪問的，那麼我們可以進一步按照對象類型進行垂直劃分，把不同類型的對象數據劃分到相應的數據表中。
（3）對於查詢數據，在目前的研究階段，也將其按照對象類型進行垂直劃分，存儲到相應的數據表中。
另外，採用對象的全局標識（UID）的哈希值（Hash）進行水平劃分，從而將對象數據劃分到不同的數據節點（Datanode）的策略，需要面對數據遷移的問題，即當增加新的數據節點時，如何確保原有數據節點上的數據不進行或者盡量少進行遷移。
3.DDF的數據存儲策略
DDF借鑒了HDFS的設計思想，在架構中引入了數據節點的概念，整個數據存儲策略的設計理念如下。
（1）每個數據劃分只可能存放在同一個資料庫中，不允許一個數據劃分分裂存放在多個資料庫的情況出現。但是，具有相同數據對象類型的不同劃分可以存放在不同的資料庫中。
（2）允許不同類型的數據（如對象數據和查詢數據）採用不同的劃分策略。
（3）概念層次上的劃分和存儲層次上的資料庫是一個多對多的關系，也就是說，我們甚至可以將所有的劃分存放在同一個資料庫內。這種極端情況同樣是被允許的。
（4）當我們將一個劃分指定給一個資料庫時，它們的對應關系應被記錄，這樣在查詢數據時可以定位到正確的資料庫。
4.DDF的節點劃分策略
DDF的節點劃分策略是建立在數據劃分和數據存儲策略的基礎之上的，節點劃分策略從應用層面上描述了DDF各節點的功能。
對於收到的遠程更新和查詢操作的請求，調度節點必須進行分析，以判斷這些操作的作用域。如果操作與當前位置的數據無關，那麼這些更新和查詢操作會被拒絕。數據節點則應具有以下功能：
（1）存儲數據。
（2）處理索引相關的請求。
（3）處理查詢請求。
（4）負責部分對查詢結果進行分頁的功能。
（5）創建並管理集合對象（對緩存的查詢）。
（6）負責對過期數據進行處理，這包括刪除與過期數據相關的對象和索引。
數據節點本身並不關心數據的位置問題，調度節點應該關心數據所處的位置。數據對象的全局標識符決定了它應該位於哪個位置。
⑤ 如何進行資料庫的設計
資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。
在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。
一、資料庫和信息系統
(1)資料庫是信息系統的核心和基礎，把信息系統中大量的數據按一定的模型組織起來，提供存儲、維護、檢索數據的
功能，使信息系統可以方便、及時、准確地從資料庫中獲得所需的信息。
(2)資料庫是信息系統的各個部分能否緊密地結合在一起以及如何結合的關鍵所在。
(3)資料庫設計是信息系統開發和建設的重要組成部分。
(4)資料庫設計人員應該具備的技術和知識：
資料庫的基本知識和資料庫設計技術
計算機科學的基礎知識和程序設計的方法和技巧
軟體工程的原理和方法
應用領域的知識
二、資料庫設計的特點
資料庫建設是硬體、軟體和干件的結合
三分技術，七分管理，十二分基礎數據
技術與管理的界面稱之為「干件」
資料庫設計應該與應用系統設計相結合
結構（數據）設計：設計資料庫框架或資料庫結構
行為（處理）設計：設計應用程序、事務處理等
結構和行為分離的設計
傳統的軟體工程忽視對應用中數據語義的分析和抽象，只要有可能就盡量推遲數據結構設計的決策早期的資料庫設計致力於數據模型和建模方法研究，忽視了對行為的設計
如圖：
三、資料庫設計方法簡述
手工試湊法
設計質量與設計人員的經驗和水平有直接關系
缺乏科學理論和工程方法的支持，工程的質量難以保證
資料庫運行一段時間後常常又不同程度地發現各種問題，增加了維護代價
規范設計法
手工設計方
基本思想
過程迭代和逐步求精
規范設計法(續)
典型方法：
(1)新奧爾良（New Orleans）方法：將資料庫設計分為四個階段
S.B.Yao方法：將資料庫設計分為五個步驟
I.R.Palmer方法：把資料庫設計當成一步接一步的過程
(2)計算機輔助設計
ORACLE Designer 2000
SYBASE PowerDesigner
四、資料庫設計的基本步驟
資料庫設計的過程(六個階段)
1.需求分析階段
准確了解與分析用戶需求（包括數據與處理）
是整個設計過程的基礎，是最困難、最耗費時間的一步
2.概念結構設計階段
是整個資料庫設計的關鍵
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型
3.邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型
對其進行優化
4.資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）
5.資料庫實施階段
運用DBMS提供的數據語言、工具及宿主語言，根據邏輯設計和物理設計的結果
建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行
6.資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改
設計特點:
在設計過程中把資料庫的設計和對資料庫中數據處理的設計緊密結合起來將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計
設計過程各個階段的設計描述：
如圖：
五、資料庫各級模式的形成過程
1.需求分析階段：綜合各個用戶的應用需求
2.概念設計階段：形成獨立於機器特點，獨立於各個DBMS產品的概念模式(E-R圖)
3.邏輯設計階段：首先將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式；然後根據用戶處理的要求、安全性的考慮，在基本表的基礎上再建立必要的視圖(View)，形成數據的外模式
4.物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，建立索引，形成資料庫內模式
六、資料庫設計技巧
1. 設計資料庫之前（需求分析階段）
1) 理解客戶需求，詢問用戶如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。
舉例：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
2. 表和欄位的設計（資料庫邏輯設計）
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form（3NF）通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
舉例：某個存放客戶及其有關定單的3NF 資料庫就可能有兩個表：Customer 和Order。Order 表不包含定單關聯客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上，為了效率的緣故，對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源（文件、XML 文檔、其他資料庫等），不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有，如果用戶界面執行工作流之類的任務（發送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統存儲客戶信息時，在單獨的一個數據表裡存儲姓氏欄位，而且還附加起始日和終止日等欄位，這樣就可以跟蹤這一數據條目的變化。
欄位設計原則
4) 每個表中都應該添加的3 個有用的欄位
dRecordCreationDate，在VB 下默認是Now()，而在SQL Server • 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT • USER
nRecordVersion，記錄的版本標記；有助於准確說明記錄中出現null 數據或者丟失數據的原因 •
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來創建特定的時間關聯關系，從而可以實現自我文檔化。
舉例：用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說，當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值，同時增加一個日期/時間欄位來知道變化是何時發生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如，假如想看看月銷售總額，總額欄位類型是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位，比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行；最好採用清除數據程序而且要仔細維護索引整體性。
3. 選擇鍵和索引（資料庫邏輯設計）
鍵選擇原則：
1) 鍵設計4 原則
為關聯欄位創建外鍵。 •
所有的鍵都必須唯一。 •
避免使用復合鍵。 •
外鍵總是關聯唯一的鍵欄位。 •
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
3) 不要用用戶的鍵(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候，可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則：
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位，不要索引大型欄位（有很多字元），這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。
4. 數據完整性設計（資料庫邏輯設計）
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除；受限刪除；置空值
父表中插入數據：受限插入；遞歸插入
父表中更新數據：級聯更新；受限更新；置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制
用戶定義完整性：
NOT NULL；CHECK；觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語（或者其他任何語言）而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對Access）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
⑥ (32) 數據的存儲結構是指______。
指數據的邏輯結構在計算機中的表示。
數據有兩種不同的存儲結構：順序存儲結構和鏈式存儲結構。
1、順序存儲方法它是把邏輯上相鄰的節點存儲在物理位置相鄰的存儲單元里，結點間的邏輯關系由存儲單元的鄰接關系來體現，由此得到的存儲表示稱為順序存儲結構。順序存儲結構是一種最基本的存儲表示方法，通常藉助於程序設計語言中的數組來實現。
2、鏈接存儲方法它不要求邏輯上相鄰的節點在物理位置上亦相鄰，結點間的邏輯關系是由附加的指針欄位表示的。由此得到的存儲表示稱為鏈式存儲結構，鏈式存儲結構通常藉助於程序設計語言中的指針類型來實現。
(6)什麼是數據存儲設計擴展閱讀
數據的存儲對象
數據存儲對象包括數據流在加工過程中產生的臨時文件或加工過程中需要查找的信息。數據以某種格式記錄在計算機內部或外部存儲介質上。數據存儲要命名，這種命名要反映信息特徵的組成含義。數據流反映了系統中流動的數據，表現出動態數據的特徵；數據存儲反映系統中靜止的數據，表現出靜態數據的特徵。
在計算機科學中，數據存儲表示法一般是指數據的存儲結構表示方法，來表示數據之間的聯系。例如稀疏矩陣，有鄰接矩陣與鄰接表兩種存儲表示法來表示數據之間的關系。
⑦ 什麼是資料庫的概念設計，邏輯設計，物理設計，以及
資料庫設計過程包括：
現實世界→需求分析→概念設計→邏輯設計→物理設計
概念設計——利用數據模型進行概念資料庫的模式設計。它不依賴任何DBMS（資料庫管理系統）常用的數據模型為ERM（實體聯系模型），用到的術語有：實體、屬性、聯系、鍵。
邏輯設計——把概念設計得到的概念資料庫模式變為邏輯數據模式，它依賴於DBMS。用到的術語有：函數依賴、範式、關系分解。
物理結構設計——指的是根據資料庫的邏輯結構來選定RDBMS（如Oracle、Sybase等），並設計和實施資料庫的存儲結構、存取方式等。
確定資料庫的物理結構包含下面四方面的內容：
1、確定數據的存儲結構；
2、設計數據的存取路徑；
3、確定數據的存放位置；
4、確定系統配置。
資料庫物理設計過程中需要對時間效率、空間效率、維護代價和各種用戶要求進行權衡，選擇一個優化方案作為資料庫物理結構。在資料庫物理設計中，最有效的方式是集中地存儲和檢索對象。
⑧ 什麼是資料庫列存儲，原理是怎樣的
資料庫列存儲不同於傳統的關系型資料庫，其數據在表中是按行存儲的，列方式所帶來的重要好處之一就是，由於查詢中的選擇規則是通過列來定義的，因 此整個資料庫是自動索引化的。
按列存儲每個欄位的數據聚集存儲，在查詢只需要少數幾個欄位的時候，能大大減少讀取的數據量，一個欄位的數據聚集存儲，那就 更容易為這種聚集存儲設計更好的壓縮/解壓演算法。這張圖講述了傳統的行存儲和列存儲的區別：
⑨ .資料庫設計分為幾個階段,各階段的任務是什麼
按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：
各階段的任務如下：
1、需求分析：分析用戶的需求，包括數據、功能和性能需求；
拓展資料：
資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。
資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。
⑩ 簡述資料庫系統構成的及資料庫的設計原則。
資料庫系統（database systems），是由資料庫及其管理軟體組成的系統。它是為適應數據處理的需要而發展起來的一種較為理想的數據處理的核心機構。它是一個實際可運行的存儲、維護和向應用系統提供數據的軟體系統，是存儲介質、處理對象和管理系統的集合體。 資料庫系統DBS（Data Base System，簡稱DBS）通常由軟體、資料庫和數據管理員組成。其軟體主要包括操作系統、各種宿主語言、實用程序以及資料庫管理系統。資料庫由資料庫管理系統統一管理，數據的插入、修改和檢索均要通過資料庫管理系統進行。數據管理員負責創建、監控和維護整個資料庫，使數據能被任何有權使用的人有效使用。資料庫管理員一般是由業務水平較高、資歷較深的人員擔任。 資料庫系統的個體含義是指一個具體的資料庫管理系統軟體和用它建立起來的資料庫；它的學科含義是指研究、開發、建立、維護和應用資料庫系統所涉及的理論、方法、技術所構成的學科。在這一含義下，資料庫系統是軟體研究領域的一個重要分支，常稱為資料庫領域。