⑴ 有關c/s架構的簡單問題 謝謝
C/S Client/Server
B/S Browser/Server
區別其實還是挺大的。
找篇文章給你看看，寫的不錯－－
當今世界科學技術飛速發展，尤其以通信、計算機、網路為代表的互聯網技術更是日新月異，令人眼花燎亂，目不睱接。 由於計算機互聯網在政治、經濟、生活等各個領域的發展、運用以及網路的迅速普及和全社會對網路的依賴程度，計算機網路已經成為國家的經濟基礎和命脈，成為社會和經濟發展強大動力，其地位越來越重要。但是，由於主流技術研發企業和用戶對「B/S」和「C/S」技術誰優誰劣、誰代表技術潮流發展等等問題的爭論不休，已經給檢察機關使用「OA（辦公）」和「案件管理」軟體工作開展帶來困惑，本文就此兩項技術發展變化和應用前景做些探討，供同行參考。
一、什麼是C/S和B/S
要想對「C/S」和「B/S」技術發展變化有所了解，首先必須搞清楚三個問題。
第一、什麼是C/S結構。
C/S （Client/Server）結構，即大家熟知的客戶機和伺服器結構。它是軟體系統體系結構，通過它可以充分利用兩端硬體環境的優勢，將任務合理分配到Client端和Server端來實現，降低了系統的通訊開銷。目前大多數應用軟體系統都是Client/Server形式的兩層結構，由於現在的軟體應用系統正在向分布式的Web應用發展，Web和Client/Server 應用都可以進行同樣的業務處理，應用不同的模塊共享邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現有的應用系統，通過現有應用系統中的邏輯可以擴展出新的應用系統。這也就是目前應用系統的發展方向。
傳統的C／S體系結構雖然採用的是開放模式，但這只是系統開發一級的開放性，在特定的應用中無論是Client端還是Server端都還需要特定的軟體支持。由於沒能提供用戶真正期望的開放環境，C/S結構的軟體需要針對不同的操作系統系統開發不同版本的軟體， 加之產品的更新換代十分快，已經很難適應百台電腦以上區域網用戶同時使用。而且代價高， 效率低。
第二、什麼是B/S結構。
B/S（Browser/Server）結構即瀏覽器和伺服器結構。它是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶工作界面是通過WWW瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，但是主要事務邏輯在伺服器端（Server）實現，形成所謂三層3-tier結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了用戶的總體成本（TCO）。
以目前的技術看，區域網建立B/S結構的網路應用，並通過Internet/Intranet模式下資料庫應用，相對易於把握、成本也是較低的。它是一次性到位的開發，能實現不同的人員，從不同的地點，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）訪問和操作共同的資料庫；它能有效地保護數據平台和管理訪問許可權，伺服器資料庫也很安全 。特別是在JAVA這樣的跨平台語言出現之後，B/S架構管理軟體更是方便、快捷、高效。
第三、管理軟體主流技術。
管理軟體技術的主流技術與管理思想一樣，也經歷了三個發展時期。首先，界面技術從上世紀DOS字元界面到Windows圖形界面（或圖形用戶界面GUI），直至Browser瀏覽器界面三個不同的發展時期。其次，今天所有電腦的瀏覽器界面，不僅直觀和易於使用，更主要的是基於瀏覽器平台的任何應用軟體其風格都是一樣的，使用人對操作培訓的要求不高，而且軟體可操作性強，易於識別；再者，平台體系結構也從過去單用戶發展到今天的文件/伺服器（F/S）體系、客戶機/伺服器（C/S）體系和瀏覽器/伺服器（B/S）體系。
二、C/S和B/S 之比較
C/S和B/S是當今世界開發模式技術架構的兩大主流技術。C/S是美國 Borland公司最早研發，B/S是美國微軟公司研發。目前，這兩項技術以被世界各國所掌握，國內公司以C/S和B/S技術開發出產品也很多。這兩種技術都有自己一定的市場份額和客戶群，各家企業都說自己的管理軟體架構技術功能強大、先進、方便，都能舉出各自的客戶群體，都有一大群文人墨客為自己搖旗吶喊，廣告滿天飛，可謂仁者見仁，智者見智。
1、C/S架構軟體的優勢與劣勢
（1）、應用伺服器運行數據負荷較輕。
最簡單的C/S體系結構的資料庫應用由兩部分組成，即客戶應用程序和資料庫伺服器程序。二者可分別稱為前台程序與後台程序。運行資料庫伺服器程序的機器，也稱為應用伺服器。一旦伺服器程序被啟動，就隨時等待響應客戶程序發來的請求；客戶應用程序運行在用戶自己的電腦上，對應於資料庫伺服器，可稱為客戶電腦，當需要對資料庫中的數據進行任何操作時，客戶程序就自動地尋找伺服器程序，並向其發出請求，伺服器程序根據預定的規則作出應答，送回結果，應用伺服器運行數據負荷較輕。
（2）、數據的儲存管理功能較為透明。
在資料庫應用中，數據的儲存管理功能，是由伺服器程序和客戶應用程序分別獨立進行的，前台應用可以違反的規則，並且通常把那些不同的（不管是已知還是未知的）運行數據，在伺服器程序中不集中實現，例如訪問者的許可權，編號可以重復、必須有客戶才能建立定單這樣的規則。所有這些，對於工作在前台程序上的最終用戶，是「透明」的，他們無須過問（通常也無法干涉）背後的過程，就可以完成自己的一切工作。在客戶伺服器架構的應用中，前台程序不是非常「瘦小」，麻煩的事情都交給了伺服器和網路。在C/S體系的下，資料庫不能真正成為公共、專業化的倉庫，它受到獨立的專門管理。
（3）、C/S架構的劣勢是高昂的維護成本且投資大。
首先，採用C/S架構，要選擇適當的資料庫平台來實現資料庫數據的真正「統一」，使分布於兩地的數據同步完全交由資料庫系統去管理，但邏輯上兩地的操作者要直接訪問同一個資料庫才能有效實現，有這樣一些問題，如果需要建立「實時」的數據同步，就必須在兩地間建立實時的通訊連接，保持兩地的資料庫伺服器在線運行，網路管理工作人員既要對伺服器維護管理，又要對客戶端維護和管理，這需要高昂的投資和復雜的技術支持，維護成本很高，維護任務量大。
其次，傳統的C/S結構的軟體需要針對不同的操作系統系統開發不同版本的軟體，由於產品的更新換代十分快，代價高和低效率已經不適應工作需要。在JAVA這樣的跨平台語言出現之後，B/S架構更是猛烈沖擊C/S，並對其形成威脅和挑戰。
2、B/S架構軟體的優勢與劣勢
（1）、維護和升級方式簡單。
目前，軟體系統的改進和升級越來越頻繁，B/S架構的產品明顯體現著更為方便的特性。對一個稍微大一點單位來說，系統管理人員如果需要在幾百甚至上千部電腦之間來回奔跑，效率和工作量是可想而知的，但B/S架構的軟體只需要管理伺服器就行了，所有的客戶端只是瀏覽器，根本不需要做任何的維護。無論用戶的規模有多大，有多少分支機構都不會增加任何維護升級的工作量，所有的操作只需要針對伺服器進行；如果是異地，只需要把伺服器連接專網即可，實現遠程維護、升級和共享。所以客戶機越來越「瘦」，而伺服器越來越「胖」是將來信息化發展的主流方向。今後，軟體升級和維護會越來越容易，而使用起來會越來越簡單，這對用戶人力、物力、時間、費用的節省是顯而易見的，驚人的。因此，維護和升級革命的方式是「瘦」客戶機，「胖」伺服器。
（2）、成本降低，選擇更多。
大家都知道windows在桌面電腦上幾乎一統天下，瀏覽器成為了標准配置，但在伺服器操作系統上windows並不是處於絕對的統治地位。現在的趨勢是凡使用B/S架構的應用管理軟體，只需安裝在Linux伺服器上即可，而且安全性高。所以伺服器操作系統的選擇是很多的，不管選用那種操作系統都可以讓大部分人使用windows作為桌面操作系統電腦不受影響，這就使的最流行免費的Linux操作系統快速發展起來，Linux除了操作系統是免費的以外，連資料庫也是免費的，這種選擇非常盛行。
比如說很多人每天上「網易」（原文為新浪）網，只要安裝了瀏覽器就可以了，並不需要了解「網易」的伺服器用的是什麼操作系統，而事實上大部分網站確實沒有使用windows操作系統，但用戶的電腦本身安裝的大部分是windows操作系統。
（3）、應用伺服器運行數據負荷較重。
由於B/S架構管理軟體只安裝在伺服器端（Server）上，網路管理人員只需要管理伺服器就行了，用戶界面主要事務邏輯在伺服器（Server）端完全通過WWW瀏覽器實現，極少部分事務邏輯在前端（Browser）實現，所有的客戶端只有瀏覽器，網路管理人員只需要做硬體維護。但是，應用伺服器運行數據負荷較重，一旦發生伺服器「崩潰」等問題，後果不堪設想。因此，許多單位都備有資料庫存儲伺服器，以防萬一。
3，C/S 與 B/S 區別
Client/Server是建立在區域網的基礎上的，Browser/Server是建立在廣域網的基礎上的。
（1）、硬體環境不同：
C/S 一般建立在專用的網路上， 小范圍里的網路環境， 區域網之間再通過專門伺服器提供連接和數據交換服務。
B/S 建立在廣域網之上的， 不必是專門的網路硬體環境，例如電話上網， 租用設備， 信息自己管理， 有比C/S更強的適應范圍， 一般只要有操作系統和瀏覽器就行。
（2）、對安全要求不同
C/S 一般面向相對固定的用戶群， 對信息安全的控制能力很強。 一般高度機密的信息系統採用C/S 結構適宜，可以通過B/S發布部分可公開信息。
B/S 建立在廣域網之上， 對安全的控制能力相對弱， 面向是不可知的用戶群。
（3）、對程序架構不同
C/S 程序可以更加註重流程，可以對許可權多層次校驗，對系統運行速度可以較少考慮。
B/S 對安全以及訪問速度的多重的考慮， 建立在需要更加優化的基礎之上。 比C/S有更高的要求，B/S結構的程序架構是發展的趨勢，從MS的.Net系列的BizTalk 2000 Exchange 2000等，全面支持網路的構件搭建的系統。SUN和IBM推的JavaBean構件技術等，使B/S更加成熟。
（4）、軟體重用不同
C/S 程序可以不可避免的整體性考慮， 構件的重用性不如在B/S要求下的構件的重用性好。
B/S 對的多重結構，要求構件相對獨立的功能。 能夠相對較好的重用。就如買來的餐桌可以再利用，而不是做在牆上的石頭桌子。
（5）、系統維護不同
系統維護是軟體生存周期中，開銷大，相當重要
C/S 程序由於整體性，必須整體考察，處理出現的問題以及系統升級難， 可能是再做一個全新的系統。
B/S 構件組成方面構件個別的更換，實現系統的無縫升級。 系統維護開銷減到最小，用戶從網上自己下載安裝就可以實現升級。
（6）、處理問題不同
C/S 程序可以處理用戶面固定，並且在相同區域， 安全要求高的需求，與操作系統相關， 應該都是相同的系統。
B/S 建立在廣域網上， 面向不同的用戶群，分散地域， 這是C/S無法作到的，與操作系統平台關系最小。
（7）、用戶介面不同
C/S 多是建立在Window平台上，表現方法有限，對程序員普遍要求較高。
B/S 建立在瀏覽器上， 有更加豐富和生動的表現方式與用戶交流， 並且大部分難度減低，降低開發成本。
（8）、信息流不同
C/S 程序一般是典型的中央集權的機械式處理，交互性相對低。
B/S 信息流向可變化， B－B、 B－C、 B－G等信息流向的變化， 更象交易中心
⑵ 資料庫設計的步驟有哪些
資料庫的設計過程大致可分為以下六個階段：
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
5. 資料庫實施階段
運用DBMS提供的數據語言（例如sql）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。
6. 資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。
⑶ 資料庫系統中的幾種架構及處理方式
主從式結構
是指一個主機帶多個終端的多用戶結構。在這種結構中，資料庫系統，包括:應用程序、DBMS、數據，都集中存放在主機上．所有處理任務都由主機來完成，各個用戶通過主機的終端並發地存取資料庫，共享數據資源.
主從式結構的優點是簡單，數據易於管理與維護。缺點是當終端用戶數目增加到一定程度後，主機的任務會過分繁重，形成瓶頸，從而使系統性能大幅度下降。另外當主機出現故障時，整個系統都不能使用，因此系統的可靠性不高。
集中式架構
是一種遠程桌面控制技術，使用此技術，遠程用戶能夠使用任何類型的終端系統，通過任何類型的網路連接，使用遠程伺服器上的應用程序。用戶甚至能夠使用同一個終端系統訪問甚至遠程多個不同平台、不同網路協議伺服器上的多個應用，這些應用被集成在一個訪問界面中，操作簡便。
C/S架構
（Client/Server或客戶/伺服器模式）：Client和Server常常分別處在相距很遠的兩台計算機上，Client程序的任務是將用戶的要求提交給Server程序，再將Server程序返回的結果以特定的形式顯示給用戶；Server程序的任務是接收客戶程序提出的服務請求，進行相應的處理，再將結果返回給客戶程序。
C/S （Client/Server）結構，即大家熟知的客戶機和伺服器結構。它是軟體系統體系結構，通過它可以充分利用兩端硬體環境的優勢，將任務合理分配到Client端和Server端來實現，降低了系統的通訊開銷。目前大多數應用軟體系統都是Client/Server形式的兩層結構，由於現在的軟體應用系統正在向分布式的Web應用發展，Web和Client/Server 應用都可以進行同樣的業務處理，應用不同的模塊共享邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現有的應用系統，通過現有應用系統中的邏輯可以擴展出新的應用系統。這也就是目前應用系統的發展方向。
傳統的C／S體系結構雖然採用的是開放模式，但這只是系統開發一級的開放性，在特定的應用中無論是Client端還是Server端都還需要特定的軟體支持。由於沒能提供用戶真正期望的開放環境，C/S結構的軟體需要針對不同的操作系統系統開發不同版本的軟體， 加之產品的更新換代十分快，已經很難適應百台電腦以上區域網用戶同時使用。而且代價高， 效率低。
C/S結構的優點
C/S結構的優點是能充分發揮客戶端ＰＣ的處理能力，很多工作可以在客戶端處理後再提交給伺服器。對應的優點就是客戶端響應速度快。缺點主要有以下幾個：
只適用於區域網。而隨著互聯網的飛速發展，移動辦公和分布式辦公越來越普及，這需要我們的系統具有擴展性。這種方式遠程訪問需要專門的技術，同時要對系統進行專門的設計來處理分布式的數據。
客戶端需要安裝專用的客戶端軟體。首先涉及到安裝的工作量，其次任何一台電腦出問題，如病毒、硬體損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。還有，系統軟體升級時，每一台客戶機需要重新安裝，其維護和升級成本非常高。
對客戶端的操作系統一般也會有限制。可能適應於Win98, 但不能用於win2000或Windows XP。或者不適用於微軟新的操作系統等等，更不用說Linux、Ｕnix等。
⑷ 如何設計資料庫樹狀數據結構
然後我覺得首先不要太關注裡面數據結構用c語言的實現方法。第一步，先把書看一遍，省略裡面C語言的具體描述，也就是先不看這些。也不要看那些計算公式，只需要弄清楚裡面的概念，比如說線性表，首先只需要弄清楚什麼是線性表，最好能給自己列個大綱，比如，線性結構-樹狀結構-圖狀結構，然後在細分，把所有的概念全部看懂。第二步，看第二遍書的時候，在去仔細看那些結構的定義語句，以及每種結構有哪些基本演算法，以及是怎樣用C語言來實現的。第三步，最後再去看一些公式，比如時間復雜度，等等。當然，這個是需要有高等數學的根基的。第四步，盡量用自己掌握的一些數據結構來用C語言描述，找些實例來做做，也就是實踐一下。最後如果還有興趣的話可以再深一層的去看看一些軟體工程里的一些基本演算法。相信你會學好數據結構的~
⑸ 為什麼採用C/S體系結構
[注1]：應當說明，對於其他的架構的資料庫體系，同樣可以實現分布式的數據存儲與管理，但從本例實現的角度看，比起基於C/S架構的體系，要復雜和昂貴。 3.2 潛在和不確定的需求 在電腦應用定製開發的領域，要想真正令客戶滿意，就必須真正理解用戶的需求，尤其是那些潛在的需求。比如，上述對數據同步更新頻率的需求，是基於現在的業務方式與節奏的，一旦電腦系統投入應用，改變了整個作業的節奏，就可能提出更高的要求。此外，公司的業務量的不斷發展，客戶對於公司作出反映的時間的提高，都會導致對電腦系統需求的提高。 在這個案例中，用戶的應用方式和規則具有不確定性和不斷改變發展的特徵，但資料庫描述的基本對象卻具有相對穩定、有序擴充的特點，因而資料庫的結構相對穩定，也就是說，基於對實體的深入分析和抽象作出的數據表是相對穩定的，隨著未來的發展，多數的變化將是新表的增加及數據項的增加，而較少更改。 針對這個特徵最直接有效的策略，就是將易變的部分（應用和應用規則）和相對穩定的部分（數據和基本屬性、結構）分離，這正是C/S結構資料庫應用的典型模式。 從原理和經驗上看，對本案例或類似的應用，C/S結構是目前技術條件下，能較好適應不確定和變化的需求環境的比較現實的方案。它可以令我們以較低的投入，實現將易變與穩定的要素分離，快速地增添和替換「瘦小」而互相獨立的前台應用，保持數據的連續性和繼承性。 3.3 未來的需求 在這個案例中，用戶確認了這樣的應用發展策略：由點到面，由簡到繁逐步引進電腦化作業方法，穩步改進日常的業務模式，並期望於時機成熟的時候開展基於信息技術的業務流程重規劃。 具體應用的規劃是：先建立簡單有效的資料庫應用，進一步開發更多的，更具專業性、更深入的應用項目，進而在更大的范圍上應用，最終期望將客戶也納入到電腦系統的用戶中來，實現客戶與銷售人員的遠程在線查詢、下單。在指導性的發展規劃中，具體提出了企業內部的互連網（Intranet）和面向國際互連網（Internet）的應用遠景。 在這樣的應用策略下，對電腦應用的開發，將是一個逐步完善的過程，對這樣的開發環境，上一節中已經做了分析。 以目前的技術看，先建立C/S結構的區域網絡應用，再向Internet/Intranet模式下資料庫應用過渡，是比較現實，相對易於把握、成本較低的。即使是一次到位的開發，對於類似的環境和小型的應用而言，要想實現不同的人員，從不同的地點，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）訪問和操作共同的資料庫，並有效地保證和管理數據的安全性、訪問許可權、完整性，採用C/S架構和支持C/S架構的數據平台，是必然選擇。 3.4 成本和資源的考慮 由於用戶已經建立並運行著LAN、文件伺服器，並運行著（並且以後也要繼續運行）一些基於PC或PC LAN的應用，現行的硬體設備基本上不用大的擴充，就可以運行基於文件伺服器的多用戶資料庫或基於應用伺服器的C/S應用。 採用C/S體系結構，客戶所支出的費用項目，將增加資料庫平台和對其維護的成本，和可能需要增加適合資料庫平台運行的應用伺服器操作系統。 這樣，從現有資源出發，不考慮開發的成本，最直接而經濟的實現方案，是建立基於文件伺服器的多用戶系統，其次才是C/S體系結構。相比之下，主機模式無論從軟硬體投資、開發成本上都是巨大的，沒有什麼理由替代前兩種模式。 3.5 發布、運行與維護的考慮 由於資料庫用戶的地理位置和數量增加的可能，需要考慮安裝上的因素。C/S結構的應用至少需要設置客戶和伺服器兩個項目，而基於文件伺服器的應用，通常只需要一次性的安裝和設置。現在的客戶伺服器開發技術，可以將客戶端作成簡單復制一個瘦小的執行文件就可以運行，客戶端通常沒有維護的要求，對伺服器的安裝設置則是一次性的。 對於非C/S架構的資料庫系統來說，維護方面的性能也是在應用程序的開發中決定的。這樣的系統，通常都需要原設計開發者才能比較好地維護。 C/S架構的資料庫系統，由於資料庫是建立在通用的平台之上，並且支持SQL這樣的通用技術，對資料庫的維護工作更加專業，但更為開放，這意味著維護和進一步開發對原設計開發者的依賴性可以降低。用戶可以更好地適應人員的流動或服務/供應商的變更。對體系規劃的合理性，和一些特殊技術的採用，例如後台伺服器上的存儲過程、觸發器等，會影響到這個特點。出於這個理由，在C/S應用設計時，應盡可能採用規范的模式，標准化的技術。同樣的努力，在其他架構中就相對難以實現或較少實際意義。 3.6 性能、開發與品質保證的考慮 非C/S結構應用的性能，更大程度取決於應用程序的設計與實現。基於文件伺服器運行的多用戶系統，當數據量、用戶數擴大時，性能就會嚴重下降，這包括巨大的網路傳輸量，以及難以有效地平衡工作站與伺服器的負荷。因此，大的數據容量和多用戶環境，通常是採納C/S結構的一個重要理由。主機-終端模式雖然可能更具能量，但高成本和封閉性，限制了它的應用領域。 從運行上來看，同樣設計良好的系統，C/S結構引入了更多的「銜接」環節，這意味著故障的機會和資源的耗費，然而，一旦系統處於開放的網路與應用環境中，這些開銷就變成是必須的。 對於具備良好的規劃能力的開發者而言，C/S結構給予規劃者更大的空間和更強的支持，易於實現不同應用間的合理分離，分別調試和投入應用。前台應用和後台資料庫的開發，被「強制」地分開；資料庫部分的邏輯與規則，一經調試完成，就可以在將來的應用中一直保證下去；在一個動態改進或逐步擴充的開發環境，或復雜的應用環境中，這些都是提高系統可靠性有利因素。對基於文件伺服器的系統而言，每次增加或修改功能，通常都意味著整個系統的升級，前後台的一體化，也就意味著每次變更都有更大的可能性造成對原有規則的破壞，並引起連鎖效應。 以目前的技術環境而言，在C/S結構下，有更多成熟的，適合不同規模應用的開發平台與資料庫平台可供選擇，並普遍遵循或採用SQL等標准或技術，相對較具開放性，有更多的技術支持、開發與維護人員的來源，並且——基於技術與行業發展的趨勢，將來也會有更多的發展和保障。 4 小結 總結以上的種種分析，可以發現，對於這個特定的案例，僅就當前已確定的和希望馬上實現的需求而言，可以用傳統的，基於LAN的文件伺服器的多用戶系統實現，但考慮到用戶真實需求的不確定性和不斷擴充的可能等等因素，有更多的理由支持採用C/S體系結構。作為一種權宜的方案，也可以考慮先採用基於文件伺服器的多用戶系統，在規劃和實現上，盡量為將適當時候來轉換成為C/S結構打下基礎。此外，如果採用C/S體系結構，還應當盡可能採用開放的，標準的技術。 在上面的分析中，支持採用C/S的理由主要有： 應用的不確定性，逐步開發和增加新應用的需要 適應將來開放的異種網路環境中應用的需要 用戶數、數據量增長的可能性 適應電腦開發、維護、供應商與相關技術人員變更的需要 有利於動態規劃與動態開發過程，對系統可靠性的保證 此外，從用戶的現有資源的延續利用與新增投入，及開發的成本和難度看，採用C/S結構，也是比較適中、現實的選擇。 讀者應當留意，這里僅僅是針對一個特定環境下小型應用案例開發策略的分析，而不是對資料庫體系結構的一個完整的分析比較，更不是對技術本身的評價。 發表日期：1999-03-05 更新日期：1999-03-14 對一些闡述不清楚或易於引起誤解的地方進行了修改，部分標明。作者：余彤鷹
⑹ 怎麼用C語言結合數據結構的知識來實現資料庫的功能，代碼怎麼設計和編寫
用數據結構組織起來就是簡單的資料庫了，無非就是插入刪除修改之類的功能
你說的那些資料庫語句，可以用簡單的字元串匹配來做
如： strcmp 匹配"Create table"這個字元串 對接下來字元進行提取，直到"(" 以後的關鍵字元也是用類似方法判斷","等實現
提取了需要的關鍵字元之後就可以進行對應的傳參，調用相應操作
⑺ c語言的數據結構和程序設計
數據結構
數據結構是計算機存儲、組織數據的方式。數據結構是指相互之間存在一種或多種特定關系的數據元素的集合。通常情況下，精心選擇的數據結構可以帶來更高的運行或者存儲效率。數據結構往往同高效的檢索演算法和索引技術有關。數據結構在計算機科學界至今沒有標準的定義。個人根據各自的理解的不同而有不同的表述方法： Sartaj Sahni 在他的《數據結構、演算法與應用》一書中稱：「數據結構是數據對象，以及存在於該對象的實例和組成實例的數據元素之間的各種聯系。這些聯系可以通過定義相關的函數來給出。」他將數據對象（data object）定義為「一個數據對象是實例或值的集合」。 Clifford A.Shaffer 在《數據結構與演算法分析》一書中的定義是：「數據結構是 ADT（抽象數據類型 Abstract Data Type） 的物理實現。」 Lobert L.Kruse 在《數據結構與程序設計》一書中，將一個數據結構的設計過程分成抽象層、數據結構層和實現層。其中，抽象層是指抽象數據類型層，它討論數據的邏輯結構及其運算，數據結構層和實現層討論一個數據結構的表示和在計算機內的存儲細節以及運算的實現。
重要意義
一般認為，一個數據結構是由數據元素依據某種邏輯聯系組織起來的。對數據元素間邏輯關系的描述稱為數據的邏輯結構；數據必須在計算機內存儲，數據的存儲結構是數據結構的實現形式，是其在計算機內的表示；此外討論一個數據結構必須同時討論在該類數據上執行的運算才有意義。 在許多類型的程序的設計中，數據結構的選擇是一個基本的設計考慮因素。許多大型系統的構造經驗表明，系統實現的困難程度和系統構造的質量都嚴重的依賴於是否選擇了最優的數據結構。許多時候，確定了數據結構後，演算法就容易得到了。有些時候事情也會反過來，我們根據特定演算法來選擇數據結構與之適應。不論哪種情況，選擇合適的數據結構都是非常重要的。 選擇了數據結構，演算法也隨之確定，是數據而不是演算法是系統構造的關鍵因素。這種洞見導致了許多種軟體設計方法和程序設計語言的出現，面向對象的程序設計語言就是其中之一。
研究內容 在計算機科學中，數據結構是一門研究非數值計算的程序設計問題中計算機的操作對象（數據元素）以及它們之間的關系和運算等的學科，而且確保經過這些運算後所得到的新結構仍然是原來的結構類型。
「數據結構」作為一門獨立的課程在國外是從1968年才開始設立的。 1968年美國唐•歐•克努特教授開創了數據結構的最初體系，他所著的《計算機程序設計技巧》第一卷《基本演算法》是第一本較系統地闡述數據的邏輯結構和存儲結構及其操作的著作。「數據結構」在計算機科學中是一門綜合性的專業基礎課。數據結構是介於數學、計算機硬體和計算機軟體三者之間的一門核心課程。數據結構這一門課的內容不僅是一般程序設計（特別是非數值性程序設計）的基礎，而且是設計和實現編譯程序、操作系統、資料庫系統及其他系統程序的重要基礎。
計算機是一門研究用計算機進行信息表示和處理的科學。這裡面涉及到兩個問題：信息的表示，信息的處理 。
而信息的表示和組織又直接關繫到處理信息的程序的效率。隨著計算機的普及，信息量的增加，信息范圍的拓寬，使許多系統程序和應用程序的規模很大，結構又相當復雜。因此，為了編寫出一個「好」的程序，必須分析待處理的對象的特徵及各對象之間存在的關系，這就是數據結構這門課所要研究的問題。眾所周知，計算機的程序是對信息進行加工處理。在大多數情況下，這些信息並不是沒有組織，信息（數據）之間往往具有重要的結構關系，這就是數據結構的內容。數據的結構，直接影響演算法的選擇和效率。 計算機解決一個具體問題時，大致需要經過下列幾個步驟：首先要從具體問題中抽象出一個適當的數學模型，然後設計一個解此數學模型的演算法（Algorithm），最後編出程序、進行測試、調整直至得到最終解答。尋求數學模型的實質是分析問題，從中提取操作的對象，並找出這些操作對象之間含有的關系，然後用數學的語言加以描述。計算機演算法與數據的結構密切相關，演算法無不依附於具體的數據結構，數據結構直接關繫到演算法的選擇和效率。運算是由計算機來完成，這就要設計相應的插入、刪除和修改的演算法 。也就是說，數據結構還需要給出每種結構類型所定義的各種運算的演算法。 數據是對客觀事物的符號表示，在計算機科學中是指所有能輸入到計算機中並由計算機程序處理的符號的總稱。
數據元素是數據的基本單位，在計算機程序中通常作為一個整體考慮。一個數據元素由若干個數據項組成。數據項是數據的不可分割的最小單位。有兩類數據元素：一類是不可分割的原子型數據元素，如：整數"5"，字元 "N" 等；另一類是由多個款項構成的數據元素，其中每個款項被稱為一個數據項。例如描述一個學生的信息的數據元素可由下列6個數據項組成。其中的出身日期又可以由三個數據項："年"、"月"和"日"組成，則稱"出身日期"為組合項，而其它不可分割的數據項為原子項。
關鍵字指的是能識別一個或多個數據元素的數據項。若能起唯一識別作用，則稱之為 "主" 關鍵字，否則稱之為 "次" 關鍵字。
數據對象是性質相同的數據元素的集合，是數據的一個子集。數據對象可以是有限的，也可以是無限的。
數據處理是指對數據進行查找、插入、刪除、合並、排序、統計以及簡單計算等的操作過程。在早期，計算機主要用於科學和工程計算，進入八十年代以後，計算機主要用於數據處理。據有關統計資料表明，現在計算機用於數據處理的時間比例達到80%以上，隨著時間的推移和計算機應用的進一步普及，計算機用於數據處理的時間比例必將進一步增大。
分類
數據結構是指同一數據元素類中各數據元素之間存在的關系。數據結構分別為邏輯結構、存儲結構（物理結構）和數據的運算。數據的邏輯結構是對數據之間關系的描述，有時就把邏輯結構簡稱為數據結構。邏輯結構形式地定義為（K，R）（或（D，S）），其中，K是數據元素的有限集，R是K上的關系的有限集。
數據元素相互之間的關系稱為結構。有四類基本結構：集合、線性結構、樹形結構、圖狀結構（網狀結構）。樹形結構和圖形結構全稱為非線性結構。集合結構中的數據元素除了同屬於一種類型外，別無其它關系。線性結構中元素之間存在一對一關系，樹形結構中元素之間存在一對多關系，圖形結構中元素之間存在多對多關系。在圖形結構中每個結點的前驅結點數和後續結點數可以任意多個。
數據結構在計算機中的表示（映像）稱為數據的物理（存儲）結構。它包括數據元素的表示和關系的表示。數據元素之間的關系有兩種不同的表示方法：順序映象和非順序映象，並由此得到兩種不同的存儲結構：順序存儲結構和鏈式存儲結構。順序存儲方法：它是把邏輯上相鄰的結點存儲在物理位置相鄰的存儲單元里，結點間的邏輯關系由存儲單元的鄰接關系來體現，由此得到的存儲表示稱為順序存儲結構。順序存儲結構是一種最基本的存儲表示方法，通常藉助於程序設計語言中的數組來實現。鏈接存儲方法：它不要求邏輯上相鄰的結點在物理位置上亦相鄰，結點間的邏輯關系是由附加的指針欄位表示的。由此得到的存儲表示稱為鏈式存儲結構，鏈式存儲結構通常藉助於程序設計語言中的指針類型來實現。索引存儲方法：除建立存儲結點信息外，還建立附加的索引表來標識結點的地址。散列存儲方法：就是根據結點的關鍵字直接計算出該結點的存儲地址。
數據結構中，邏輯上（邏輯結構：數據元素之間的邏輯關系）可以把數據結構分成線性結構和非線性結構。線性結構的順序存儲結構是一種隨機存取的存儲結構，線性表的鏈式存儲結構是一種順序存取的存儲結構。線性表若採用鏈式存儲表示時所有結點之間的存儲單元地址可連續可不連續。邏輯結構與數據元素本身的形式、內容、相對位置、所含結點個數都無關。
數據結構與演算法
演算法的設計取決於數據（邏輯）結構，而演算法的實現依賴於採用的存儲結構。數據的存儲結構實質上是它的邏輯結構在計算機存儲器中的實現為了全面的反映一個數據的邏輯結構，他在存儲器中的映象包括兩方面內容，及數據元素之間的信息和數據元素之間的關系。不同數據結構有其相應的若干運算。數據的運算是在數據的邏輯結構上定義的操作演算法，如檢索、插入、刪除、更新的排序等。
數據的運算是數據結構的一個重要方面，討論任一種數據結構時都離不開都離不開對該結構上的數據運算及其實現演算法的討論。
數據結構的形式定義為：數據結構是一個二元組：
Data-Structure=(D，S)
其中：D是數據元素的有限集，S是D上關系的有限集。
數據結構不同於數據類型，也不同於數據對象，它不僅要描述數據類型的數據對象，而且要描述數據對象各元素之間的相互關系。
數據類型是一個值的集合和定義在這個值集上的一組操作的總稱。數據類型可分為兩類：原子類型、結構類型。一方面，在程序設計語言中，每一個數據都屬於某種數據類型。類型明顯或隱含地規定了數據的取值范圍、存儲方式以及允許進行的運算。可以認為，數據類型是在程序設計中已經實現了的數據結構。另一方面，在程序設計過程中，當需要引入某種新的數據結構時，總是藉助編程語言所提供的數據類型來描述數據的存儲結構。
計算機中表示數據的最小單位是二進制數的一位，叫做位。我們用一個由若干位組合起來形成的一個位串表示一個數據元素，通常稱這個位串為元素或結點。當數據元素由若干數據項組成時，位串中對應於各個數據項的子位串稱為數據域。元素或結點可看成是數據元素在計算機中的映象。 一個軟體系統框架應建立在數據之上，而不是建立在操作之上。一個含抽象數據類型的軟體模塊應包含定義、表示、實現三個部分。 對每一個數據結構而言，必定存在與它密切相關的一組操作。若操作的種類和數目不同，即使邏輯結構相同，數據結構能起的作用也不同。
不同的數據結構其操作集不同，但下列操作必不可缺：1,結構的生成；2.結構的銷毀；3,在結構中查找滿足規定條件的數據元素；4,在結構中插入新的數據元素； 5,刪除結構中已經存在的數據元素； 6,遍歷。
抽象數據類型：一個數學模型以及定義在該模型上的一組操作。抽象數據類型實際上就是對該數據結構的定義。因為它定義了一個數據的邏輯結構以及在此結構上的一組演算法。抽象數據類型可用以下三元組表示：（D，S，P）。D是數據對象，S是D上的關系集，P是對D的基本操作集。ADT的定義為： ADT 抽象數據類型名{ 數據對象：（數據元素集合） 數據關系：（數據關系二元組結合） 基本操作：（操作函數的羅列） } ADT 抽象數據類型名;
抽象數據類型有兩個重要特性： 數據抽象
用ADT描述程序處理的實體時，強調的是其本質的特徵、其所能完成的功能以及它和外部用戶的介面（即外界使用它的方法）。 數據封裝 將實體的外部特性和其內部實現細節分離，並且對外部用戶隱藏其內部實現細節。
數據（Data）是信息的載體，它能夠被計算機識別、存儲和加工處理。它是計算機程序加工的原料，應用程序處理各種各樣的數據。計算機科學中，所謂數據就是計算機加工處理的對象，它可以是數值數據，也可以是非數值數據。數值數據是一些整數、實數或復數，主要用於工程計算、科學計算和商務處理等；非數值數據包括字元、文字、圖形、圖像、語音等。數據元素（Data Element）是數據的基本單位。在不同的條件下，數據元素又可稱為元素、結點、頂點、記錄等。例如，學生信息檢索系統中學生信息表中的一個記錄等，都被稱為一個數據元素。
有時，一個數據元素可由若干個數據項（Data Item）組成，例如，學籍管理系統中學生信息表的每一個數據元素就是一個學生記錄。它包括學生的學號、姓名、性別、籍貫、出生年月、成績等數據項。這些數據項可以分為兩種：一種叫做初等項，如學生的性別、籍貫等，這些數據項是在數據處理時不能再分割的最小單位；另一種叫做組合項，如學生的成績，它可以再劃分為數學、物理、化學等更小的項。通常，在解決實際應用問題時是把每個學生記錄當作一個基本單位進行訪問和處理的。
數據對象（Data Object）或數據元素類（Data Element Class）是具有相同性質的數據元素的集合。在某個具體問題中，數據元素都具有相同的性質（元素值不一定相等），屬於同一數據對象（數據元素類），數據元素是數據元素類的一個實例。例如，在交通咨詢系統的交通網中，所有的頂點是一個數據元素類，頂點A和頂點B各自代表一個城市，是該數據元素類中的兩個實例，其數據元素的值分別為A和B。 數據結構（Data Structure）是指互相之間存在著一種或多種關系的數據元素的集合。在任何問題中，數據元素之間都不會是孤立的，在它們之間都存在著這樣或那樣的關系，這種數據元素之間的關系稱為結構。根據數據元素間關系的不同特性，通常有下列四類基本的結構：
⑴集合結構。該結構的數據元素間的關系是「屬於同一個集合」。
⑵線性結構。該結構的數據元素之間存在著一對一的關系。
⑶樹型結構。該結構的數據元素之間存在著一對多的關系。
⑷圖形結構。該結構的數據元素之間存在著多對多的關系，也稱網狀結構。 從上面所介紹的數據結構的概念中可以知道，一個數據結構有兩個要素。一個是數據元素的集合，另一個是關系的集合。在形式上，數據結構通常可以採用一個二元組來表示。
數據結構的形式定義為：數據結構是一個二元組
Data_Structure ＝（D，R）
其中，D是數據元素的有限集，R是D上關系的有限集。 線性結構的特點是數據元素之間是一種線性關系，數據元素「一個接一個的排列」。在一個線性表中數據元素的類型是相同的，或者說線性表是由同一類型的數據元素構成的線性結構。在實際問題中線性表的例子是很多的，如學生情況信息表是一個線性表：表中數據元素的類型為學生類型; 一個字元串也是一個線性表：表中數據元素的類型為字元型，等等。
線性表是最簡單、最基本、也是最常用的一種線性結構。 線性表是具有相同數據類型的n(n>=0)個數據元素的有限序
列，通常記為：
(a1，a2，… ai-1，ai，ai+1，…an)
其中n為表長， n＝0 時稱為空表。 它有兩種存儲方法：順序存儲和鏈式存儲，它的主要基本操作是插入、刪除和檢索等。
常用數據結構數組 (Array) 在程序設計中，為了處理方便， 把具有相同類型的若干變數按有序的形式組織起來。這些按序排列的同類數據元素的集合稱為數組。在C語言中， 數組屬於構造數據類型。一個數組可以分解為多個數組元素，這些數組元素可以是基本數據類型或是構造類型。因此按數組元素的類型不同，數組又可分為數值數組、字元數組、指針數組、結構數組等各種類別。
棧 (Stack) 是只能在某一端插入和刪除的特殊線性表。它按照後進先出的原則存儲數據，先進入的數據被壓入棧底，最後的數據在棧頂，需要讀數據的時候從棧頂開始彈出數據（最後一個數據被第一個讀出來）。
隊列 (Queue) 一種特殊的線性表，它只允許在表的前端（front）進行刪除操作，而在表的後端（rear）進行插入操作。進行插入操作的端稱為隊尾，進行刪除操作的端稱為隊頭。隊列中沒有元素時，稱為空隊列。
鏈表 (Linked List) 是一種物理存儲單元上非連續、非順序的存儲結構，數據元素的邏輯順序是通過鏈表中的指針鏈接次序實現的。鏈表由一系列結點（鏈表中每一個元素稱為結點）組成，結點可以在運行時動態生成。每個結點包括兩個部分：一個是存儲數據元素的數據域，另一個是存儲下一個結點地址的指針域。
樹 (Tree) 是包含n（n>0）個結點的有窮集合K，且在K中定義了一個關系N，N滿足 以下條件： （1）有且僅有一個結點 k0，他對於關系N來說沒有前驅，稱K0為樹的根結點。簡稱為根（root）。 （2）除K0外，k中的每個結點，對於關系N來說有且僅有一個前驅。
（3）K中各結點，對關系N來說可以有m個後繼（m>=0）。
圖 (Graph) 圖是由結點的有窮集合V和邊的集合E組成。其中，為了與樹形結構加以區別，在圖結構中常常將結點稱為頂點，邊是頂點的有序偶對，若兩個頂點之間存在一條邊，就表示這兩個頂點具有相鄰關系。
堆 (Heap) 在計算機科學中，堆是一種特殊的樹形數據結構，每個結點都有一個值。通常我們所說的堆的數據結構，是指二叉堆。堆的特點是根結點的值最小（或最大），且根結點的兩個子樹也是一個堆。
散列表 (Hash) 若結構中存在關鍵字和K相等的記錄，則必定在f(K)的存儲位置上。由此，不需比較便可直接取得所查記錄。稱這個對應關系f為散列函數(Hash function)，按這個思想建立的表為散列表。
⑻ C語言資料庫是什麼
資料庫是用來存入數據的倉庫。用戶可以對文件中的數據進行新增、查詢、更新、刪除等操作。但是C語言和資料庫是兩個東西，他們之間的關系就是C語言可以用來開發資料庫管理軟體，也可以通過C語言藉助於SQL語句來操作資料庫。
C語言普適性最強的一種計算機程序編輯語言，它不僅可以發揮出高級編程語言的功用，還具有匯編語言的優點，因此相對於其它編程語言，它具有自己獨特的特點。具體體現在以下三個方面：
其一，廣泛性。C 語言的運算范圍的大小直接決定了其優劣性。C 語言中包含了34種運算符，因此運算范圍要超出許多其它語言，此外其運算結果的表達形式也十分豐富。此外，C 語言包含了字元型、指針型等多種數據結構形式，因此，更為龐大的數據結構運算它也可以應付。
其二，簡潔性。9 類控制語句和32個KEYWORDS是C語言所具有的基礎特性，使得其在計算機應用程序編寫中具有廣泛的適用性，不僅可以適用廣大編程人員的操作，提高其工作效率，同 時還能夠支持高級編程，避免了語言切換的繁瑣。
(8)c資料庫架構設計擴展閱讀
資料庫架構
1、內層：最接近實際存儲體，亦即有關數據的實際存儲方式。
2、外層：最接近用戶，即有關個別用戶觀看數據的方式。
3、概念層：介於兩者之間的間接層。
⑼ 請簡要的敘述一下資料庫的主要設計過程
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。
資料庫設計是指：對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計的各階段：
A、需求分析階段：綜合各個用戶的應用需求(現實世界的需求)。
B、在概念設計階段：形成獨立於機器和各DBMS產品的概念模式(信息世界模型)，用E-R圖來描述。
C、在邏輯設計階段：將E-R圖轉換成具體的資料庫產品支持的數據模型，如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖(VIEW)形成數據的外模式。
D、在物理設計階段：根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求(和數據流圖描述的處理需求)。
需求分析的重點：調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法(Structured Analysis，簡稱SA方法)從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典(Data Dictionary，簡稱DD)來描述。
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模隊伍，收集源材料，制定約束和規范。收集源材料是這階段的重點。通過調查和觀察結果，業務流程，原有系統的輸入輸出，各種報表，收集原始數據，形成了基本數據資料表。
2.2 第一步——定義實體
實體集成員都有一個共同的特徵和屬性集，可以從收集的源材料——基本數據資料表中直接或間接標識出大部分實體。根據源材料名字表中表示物的術語以及具有 「代碼」結尾的術語，如客戶代碼、代理商代碼、產品代碼等將其名詞部分代表的實體標識出來，從而初步找出潛在的實體，形成初步實體表。
2.3 第二步——定義聯系
IDEF1X模型中只允許二元聯系，n元聯系必須定義為n個二元聯系。根據實際的業務需求和規則，使用實體聯系矩陣來標識實體間的二元關系，然後根據實際情況確定出連接關系的勢、關系名和說明，確定關系類型，是標識關系、非標識關系(強制的或可選的)還是非確定關系、分類關系。如果子實體的每個實例都需要通過和父實體的關系來標識，則為標識關系，否則為非標識關系。非標識關系中，如果每個子實體的實例都與而且只與一個父實體關聯，則為強制的，否則為非強制的。如果父實體與子實體代表的是同一現實對象，那麼它們為分類關系。
2.4 第三步——定義碼
通過引入交叉實體除去上一階段產生的非確定關系，然後從非交叉實體和獨立實體開始標識侯選碼屬性，以便唯一識別每個實體的實例，再從侯選碼中確定主碼。為了確定主碼和關系的有效性，通過非空規則和非多值規則來保證，即一個實體實例的一個屬性不能是空值，也不能在同一個時刻有一個以上的值。找出誤認的確定關系，將實體進一步分解，最後構造出IDEF1X模型的鍵基視圖(KB圖)。
2.5 第四步——定義屬性
從源數據表中抽取說明性的名詞開發出屬性表，確定屬性的所有者。定義非主碼屬性，檢查屬性的非空及非多值規則。此外，還要檢查完全依賴函數規則和非傳遞依賴規則，保證一個非主碼屬性必須依賴於主碼、整個主碼、僅僅是主碼。以此得到了至少符合關系理論第三範式的改進的IDEF1X模型的全屬性視圖。
2.6 第五步——定義其他對象和規則
定義屬性的數據類型、長度、精度、非空、預設值、約束規則等。定義觸發器、存儲過程、視圖、角色、同義詞、序列等對象信息。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型(例如關系模型)，並對其進行優化。設計邏輯結構應該選擇最適於描述與表達相應概念結構的數據模型，然後選擇最合適的DBMS。
將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則：一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
數據模型的優化，確定數據依賴，消除冗餘的聯系，確定各關系模式分別屬於第幾範式。確定是否要對它們進行合並或分解。一般來說將關系分解為3NF的標准，即：
表內的每一個值都只能被表達一次。
表內的每一行都應該被唯一的標識(有唯一鍵)。
表內不應該存儲依賴於其他鍵的非鍵信息。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方法)。根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
5. 資料庫實施階段
運用DBMS提供的數據語言(例如SQL)及其宿主語言(例如C)，根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。 資料庫實施主要包括以下工作：用DDL定義資料庫結構、組織數據入庫 、編制與調試應用程序、資料庫試運行 ，(Data Definition Language(DDL數據定義語言)用作開新數據表、設定欄位、刪除數據表、刪除欄位，管理所有有關資料庫結構的東西)
●Create (新增有關資料庫結構的東西，屬DDL)
●Drop (刪除有關資料庫結構的東西，屬DDL)
●Alter (更改結構，屬DDL)
6. 資料庫運行和維護階段
在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。內容包括：資料庫的轉儲和恢復、資料庫的安全性、完整性控制、資料庫性能的監督、分析和改進、資料庫的重組織和重構造。
7. 建模工具的使用
為加快資料庫設計速度，目前有很多資料庫輔助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。
ERwin主要用來建立資料庫的概念模型和物理模型。它能用圖形化的方式，描述出實體、聯系及實體的屬性。ERwin支持IDEF1X方法。通過使用 ERwin建模工具自動生成、更改和分析IDEF1X模型，不僅能得到優秀的業務功能和數據需求模型，而且可以實現從IDEF1X模型到資料庫物理設計的轉變。ERwin工具繪制的模型對應於邏輯模型和物理模型兩種。在邏輯模型中，IDEF1X工具箱可以方便地用圖形化的方式構建和繪制實體聯系及實體的屬性。在物理模型中，ERwin可以定義對應的表、列，並可針對各種資料庫管理系統自動轉換為適當的類型。
設計人員可根據需要選用相應的資料庫設計建模工具。例如需求分析完成之後，設計人員可以使用Erwin畫ER圖，將ER圖轉換為關系數據模型，生成資料庫結構;畫數據流圖，生成應用程序。
二、資料庫設計技巧
1. 設計資料庫之前(需求分析階段)
1) 理解客戶需求，包括用戶未來需求變化。
2) 了解企業業務類型，可以在開發階段節約大量的時間。
3) 重視輸入(要記錄的數據)、輸出(報表、查詢、視圖)。
4) 創建數據字典和ER 圖表
數據字典(Data Dictionary，簡稱DD)是各類數據描述的集合，是關於資料庫中數據的描述，即元數據，不是數據本身。(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述: 數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系
數據結構描述: 數據結構名，含義說明，組成:[數據項或數據結構]
數據流描述: 數據流名，說明，數據流來源，數據流去向， 組成:[數據結構]，平均流量，高峰期流量
數據存儲描述: 數據存儲名，說明，編號，流入的數據流，流出的數據流，組成:[數據結構]，數據量，存取方式
處理過程描述: 處理過程名，說明，輸入:[數據流]，輸出:[數據流]，處理:[簡要說明]
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 表和欄位的設計(資料庫邏輯設計)
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式，但Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說，遵守3NF 標準的資料庫的表設計原則是：「One Fact in One Place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點：有一組表專門存放通過鍵連接起來的關聯數據。
2) 數據驅動
採用數據驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴展性。
舉例，假如用戶界面要訪問外部數據源(文件、XML 文檔、其他資料庫等)，不妨把相應的連接和路徑信息存儲在用戶界面支持的表裡。如果用戶界面執行工作流之類的任務(發送郵件、列印信箋、修改記錄狀態等)，那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上，如果過程是數據驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
4) 表名、報表名和查詢名的命名規范
(採用前綴命名)檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。你可以統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象(比如 tbl_Employees)。用 sp_company 標識存儲過程，用 udf_ (或者類似的標記)標識自定義編寫的函數。
欄位設計原則：
1) 每個表中都應該添加的3 個有用的欄位。
dRecordCreationDate，在SQL Server 下默認為GETDATE()
sRecordCreator，在SQL Server 下默認為NOT NULL DEFAULT USER
nRecordVersion，記錄的版本標記;有助於准確說明記錄中出現null 數據或者丟失數據的原因
時效性數據應包括「最近更新日期/時間」欄位。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。
2) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數據表，其間具有自身的類型和標記類別。
3) 表內的列[欄位]的命名規則(採用前綴/後綴命名)、採用有意義的欄位名
對列[欄位]名應該採用標準的前綴和後綴。如鍵是數字類型：用 _N 後綴;字元類型：_C 後綴;日期類型：_D 後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
假設有兩個表：
Customer 和 Order。Customer 表的前綴是 cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
這樣從資料庫中選出全部數據的 SQL 語句可以寫成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在沒有這些前綴的情況下則寫成這個樣子(用別名來區分)：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 個 SQL 語句沒少鍵入多少字元。但如果查詢涉及到 5 個表乃至更多的列[欄位]你就知道這個技巧多有用了。
5) 選擇數字類型和文本類型的長度應盡量充足
假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
6) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位，這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行;最好採用清除數據程序而且要仔細維護索引整體性。
7) 提防大小寫混用的對象名和特殊字元
採用全部大寫而且包含下劃符的名字具有更好的可讀性(CUSTOMER_DATA)，絕對不要在對象名的字元之間留空格。
8) 小心保留詞
要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突，比如，用 DESC 作為說明欄位名。後果可想而知!DESC 是 DESCENDING 縮寫後的保留詞。表裡的一個 SELECT * 語句倒是能用，但得到的卻是一大堆毫無用處的信息。
9) 保持欄位名和類型的一致性
在命名欄位並為其指定數據類型的時候一定要保證一致性。假如欄位在表1中叫做「agreement_number」，就別在表2里把名字改成 「ref1」。假如數據類型在表1里是整數，那在表2里可就別變成字元型了。當然在表1(ABC)有處鍵ID，則為了可讀性，在表2做關聯時可以命名為 ABC_ID。
10) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
3. 選擇鍵和索引(資料庫邏輯設計)
參考：《SQL優化-索引》一文
4. 數據完整性設計(資料庫邏輯設計)
1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除數據：級聯刪除;受限刪除;置空值
父表中插入數據：受限插入;遞歸插入
父表中更新數據：級聯更新;受限更新;置空值
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制(約束規則)和觸發器實現機制用戶定義完整性：
NOT NULL;CHECK;觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。不要依賴於商務層保證數據完整性;它不能保證表之間(外鍵) 的完整性所以不能強加於其他完整性規則之上。如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象，可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
6) 分布式數據系統
對分布式系統而言，在你決定是否在各個站點復制所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在資料庫欄位中設置一些標記，在目的站點收到你的數據之後更新你的標記。為了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。
7) 關系
如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那麼你最好一開始就設置成多對多關系。從現有的多對一關系轉變為多對多關系比一開始就是多對多關系要難得多。
8) 給數據保有和恢復制定計劃
考慮數據保存策略並包含在設計過程中，預先設計你的數據恢復過程。採用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來「更新查詢」供以後萬一數據丟失可以重新處理更新。
9) 用存儲過程讓系統做重活
提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。資料庫不只是一個存放數據的地方，它也是簡化編碼之地。
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
5. 其他設計技巧
1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文檔化。
2) 使用常用英語(或者其他任何語言)而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復(對Access)、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時，這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
對所有的快捷方式、命名規范、限制和函數都要編制文檔。
採用給表、列、觸發器等加註釋的 資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化，或者在資料庫自身的內部或者單獨建立文檔。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後，必須用用戶新輸入的數據測試數據欄位。最重要的是，讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。
三、資料庫命名規范
1. 實體(表)的命名
1) 表以名詞或名詞短語命名，確定表名是採用復數還是單數形式，此外給表的別名定義簡單規則(比方說，如果表名是一個單詞，別名就取單詞的前4 個字母;如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名;如果表的名字由3 個單片語成，從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成4 字母長的別名，其餘依次類推)
對工作用表來說，表名可以加上前綴WORK_ 後面附上採用該表的應用程序的名字。在命名過程當中，根據語義拼湊縮寫即可。注意：將欄位名稱會統一成大寫或者小寫中的一種，故中間加上下劃線。
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
舉例：
定義的縮寫 Sales: Sal 銷售;
Order: Ord 訂單;
Detail: Dtl 明細;
則銷售訂單明細表命名為：Sal_Ord_Dtl;
2) 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。
舉例：
定義的縮寫 Material Ma 物品;
物品表名為：Material, 而不是 Ma.
但是欄位物品編碼則是：Ma_ID;而不是Material_ID
3) 所有的存儲值列表的表前面加上前綴Z
目的是將這些值列表類排序在資料庫最後。
4) 所有的冗餘類的命名(主要是累計表)前面加上前綴X
冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位或者表
5) 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。
關聯表用於保存多對多關系。
如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。
舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object;
作者: 小靈, 出處:論壇, 責任編輯: 李書琴, 2007-09-27 15:17
本文詳細解析了資料庫設計過程、設計技巧以及總結了資料庫命名規范……
2. 屬性(列)的命名
1) 採用有意義的列名
表內的列要針對鍵採用一整套設計規則。每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義;
A、如果是資料庫自動生成的編碼，統一命名為：ID
B、如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名，即「XXXX_ID」
C、如果鍵是數字類型，你可以用_NO 作為後綴;
D、如果是字元類型則可以採用_CODE 後綴
E、對列名應該採用標準的前綴和後綴。
舉例：銷售訂單的編號欄位命名：Sal_Ord_ID;如果還存在一個資料庫生成的自動編號，則命名為：ID。
2) 所有的屬性加上有關類型的後綴
注意，如果還需要其它的後綴，都放在類型後綴之前。
注: 數據類型是文本的欄位，類型後綴TX可以不寫。有些類型比較明顯的欄位，可以不寫類型後綴。
3) 採用前綴命名
給每個表的列名都採用統一的前綴，那麼在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些資料庫聯系起來。
3. 視圖的命名
1) 視圖以V作為前綴，其他命名規則和表的命名類似;
2) 命名應盡量體現各視圖的功能。
4. 觸發器的命名(盡量不使用)
觸發器以TR作為前綴，觸發器名為相應的表名加上後綴，Insert觸發器加'_I'，Delete觸發器加'_D'，Update觸發器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存儲過程名
存儲過程應以'UP_'開頭，和系統的存儲過程區分，後續部分主要以動賓形式構成，並用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為'UP_Ins_Agent_Account'。
6. 變數名
變數名採用小寫，若屬於片語形式，用下劃線分隔每個單詞，如@my_err_no。
7. 命名中其他注意事項
1) 以上命名都不得超過30個字元的系統限制。變數名的長度限制為29(不包括標識字元@)。
2) 數據對象、變數的命名都採用英文字元，禁止使用中文命名。絕對不要在對象名的字元之間留空格。
3) 小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用訪問方法沖突
4) 保持欄位名和類型的一致性，在命名欄位並為其指定數據類型的時候一定要保證一致性。假如數據類型在一個表裡是整數，那在另一個表裡可就別變成字元型了。
⑽ 資料庫如何設計
資料庫設計的基本步驟
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段
1.需求分析
2.概念結構設計
3.邏輯結構設計
4.物理結構設計
5.資料庫實施
6.資料庫的運行和維護
資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。
在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。
1.需求分析階段（常用自頂向下）
進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。
需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。
調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。
分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。
數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。
2.概念結構設計階段（常用自底向上）
概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。
設計概念結構通常有四類方法：
自頂向下。即首先定義全局概念結構的框架，再逐步細化。
自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。
逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。
混合策略。即自頂向下和自底向上相結合。
- 需要注意：
- ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。
- ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。
- ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。
- ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。
- ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。
3.邏輯結構設計階段（E-R圖）
邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。
在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。
各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。
E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。
4.物理設計階段
物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。
常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。
5.資料庫實施階段
資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。
6.資料庫運行和維護階段
資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。
資料庫設計5步驟
Five Steps to design the Database
1.確定entities及relationships
a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。
b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。
c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。
d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：
· 增加新員工
· 修改存在員工信息
· 刪除調走的員工
e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。
====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。
定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。
細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級
這些微觀行為可用來確定需要哪些table或relationship。
確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。
2.確定所需數據
要確定所需數據：
a)確定支持數據
b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼
c)為每個table建立數據
d)列出每個table目前看起來合適的可用數據
e)為每個relationship設置數據
f)如果有，為每個relationship列出適用的數據
確定支持數據
你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。
Employee
Skill
Expert In
ID
ID
Level
Last Name
Name
Date acquired
First Name
Description
Department
Office
Address
如果將這些數據畫成圖表，就像：
3.標准化數據
標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。
標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。
如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。
數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。
主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。
RelationShip
Key
Office
*Office code
Office address
Phone number
Works in
*Office code
*Employee ID
Department
*Department ID
Department name
Heads
*Department ID
*Employee ID
Assoc with
*Department ID
*EmployeeID
Skill
*Skill ID
Skill name
Skill description
Expert In
*Skill ID
*Employee ID
Skill level
Date acquired
Employee
*Employee ID
Last Name
First Name
Social security number
Employee street
Employee city
Employee state
Employee phone
Date of birth
將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。
將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。
將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。
4.考量關系
當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。
考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。
遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。
考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。
有一些基本原則能幫助你決定將這些鍵放在哪裡：
一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。
一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。
多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。
5.檢驗設計
在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。
最終設計
最終設計看起來就像這樣：
設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。
對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。
選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。
為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型
關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。
長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。
關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。