1. 資料庫和數據模型設計的關注點有哪些
設計的關鍵有以下4點：
業務需求：從了解業務需求著手分析，簡要分析業務特點和業務期望，協助清理理解後續的數據設計。
系統架構：從系統架構和數據分布、數據特性等角度，分析系統架構設計上是否有問題。
邏輯設計：從數據模型邏輯設計出發是否設計合理，是否符合資料庫開發和設計規范等。
物理設計：從庫表類型、庫表分區、索引、主鍵設計等維度，主要針對性能，可擴展性進行物理模型設計審查。
2. 資料庫設計的步驟有哪些
資料庫的設計過程大致可分為以下六個階段：
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
3. 邏輯結構設計階段
將概念結構轉換為某個DBMS所支持的數據模型（例如關系模型），並對其進行優化。
4. 資料庫物理設計階段
為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
5. 資料庫實施階段
運用DBMS提供的數據語言（例如sql）及其宿主語言（例如C），根據邏輯設計和物理設計的結果建立資料庫，編制與調試應用程序，組織數據入庫，並進行試運行。
6. 資料庫運行和維護階段
資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。
3. 如何設計資料庫 實現大數據分析
可以藉助大數據分析工具，未至科技魔方是一款大數據模型平台，是一款基於服務匯流排與分布式雲計算兩大技術架構的一款數據分析、挖掘的工具平台，其採用分布式文件系統對數據進行存儲，支持海量數據的處理。採用多種的數據採集技術，支持結構化數據及非結構化數據的採集。通過圖形化的模型搭建工具，支持流程化的模型配置。通過第三方插件技術，很容易將其他工具及服務集成到平台中去。數據分析研判平台就是海量信息的採集，數據模型的搭建，數據的挖掘、分析最後形成知識服務於實戰、服務於決策的過程，平台主要包括數據採集部分，模型配置部分，模型執行部分及成果展示部分等。
4. 資料庫設計實例
某種「資料庫技術」課程的作業吧
把表的結構提供給你，其它的最好看看書自己做吧
車主（車主ID，...）
汽車（汽車ID，...，所屬車主ID）
事故（事故ID，...，所屬汽車ID）
所有的主ID應該有索引，車主姓名和車牌號也可以有索引
視圖：車主與汽車的連立，車主、汽車與事故的連立
E-R圖就是三大區域，中間有兩個1:n連接
這是3NF範式（主外碼連接無冗餘）
5. 資料庫如何設計
資料庫設計的基本步驟
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下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數據類型」。
6. 資料庫優化(ER模型設計）
據訪問需要的完整解datamole4.adoquery2.sql.add('SELECT借書證號,密碼FROM[user]WHERE(借書證號=:tt)');
datamole4.adoquery2.parameters[0].value:=username;
datamole4.adoquery2.open;
在為TQuery或TADOquery部件設置SQL屬性時調用Close方法總是很安全的，如果TQuery或TADOquery部件已經被關閉了，調用Close方法時不會產生任何影響。在應用程序中為SQL屬性設置新的SQL命令語句時，必須要調用Clear方法以清除SQL屬性中現存的SQL命令語句，如果不調用Clear方法，便調用Add方法向SQL屬性中設置SQL命令語句，那麼新設置的SQL命令語句會追加在現存SQL命令語句後面，在程序運行時常常會出現出乎意料的查詢結果甚至程序無法運行下去。
在這里要特別注意的，一般情況下TQuery或TADOquery部件的SQL屬性只能包含一條完整的SQL語句，它不允許被設置成多條SQL語句。當然有些資料庫伺服器也支持在TQuery或TADOquery部件的SQL屬性中設置多條SQL語句，只要資料庫伺服器允許這樣，我們在編程時可以為SQL屬性設置多條SQL語句。
在為TQuery或TADOquery部件設置完SQL屬性的屬性值之後，也即編寫好適當的SQL程序之後，可以有多種方式來執行SQL程序。
在設計過程中，設置完TQuery或TADOquery部件的SQL屬性之後將其Active屬性的值置為True，這樣便可以執行SQL屬性中的SQL程序，如果應用中有與TQuery或TADOquery部件相連的數據瀏覽部件(如TDDGridTDBEdit等)那麼在這些數據瀏覽部件中會顯示SQL程序的執行結果。
在應用程序運行過程中，通過程序調用TQuery或TADOquery組件的Open方法或ExecSQL方法可以執行其SQL屬性中的SQL程序。Open方法和ExecSQL方法是不一樣的。Open方法只能用來執行SQL語言的查詢語句(Select命令)，並返回一個查詢結果集，而ExecSQL方法還可以用來執行其它常用的SQL語句(如INSERT,UPDATE,DELETE等命令)，例如：
Query1.Open(這樣會返回一個查詢結果集)
如果調用Open方法，而沒有查詢結果時，會出錯。此時應該調用ExecSQL方法來代替Open方法。如：
Query1.ExecSQL(沒有返回結果)
當然在設計應用程序時，程序設計人員是無法確定TQuery或TADOquery組件中的SQL語句是否會返回一個查詢結果的。對於這種情況應當用Try…Except模塊來設計程序。在Try部分調用Open方法，而在Except部分調用ExceSQL方法，這樣才能保證程序的正確運行。
例如：
Try
Query1.Open
Except
Query1.ExecSQL
End
通過Tquery或TADOquery組件可以獲得兩種類型的數據：
u「活動」的數據
這種數據就跟通過TTable部件獲得的數據一樣，用戶可以通過數據瀏覽部件來編輯修改這些數據，並且當調用Post方法或當焦點離開當前的數據瀏覽部件時，用戶對數據的修改自動地被寫回到資料庫中。
u非活動的數據(只讀數據)
用戶通過數據瀏覽部件是不能修改其中的數據。在預設情況下，通過TQuery部件獲得的查詢結果數據是只讀數據，要想獲得「活動」的數據，在應用程序中必須要設置Tquery或TADOquery組件的RequestLive屬性值為True，然而並不是在任何情況下(通過設置RequestLive的屬值True)都可以獲得「活動」的數據的，要想獲得「活動」的數據，除了將TQuery部件的RequestLive屬性設置為True外，相應的SQL命令還要滿足以下條件。
本地SQL語句查詢情況下，要得到可更新的數據集，SQL語句的限制為：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG
n在Select後的欄位列表中不能有計算欄位
n在Select語句WHERE部分只能包含欄位值與常量的比較運算，這些比較運算符是：Like,>,<,>=,<=。各比較運算之間可以有並和交運算：AND和OR
當通過SQL語句查詢資料庫伺服器中的資料庫表：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG運算
另外，如果是查詢Sybase資料庫中的表，那麼被查詢的表中只能有一個索引。
如果在應用程序中要求TQuery或TADOquery組件返回一個「活動」的查詢結果數據集，但是SQL命令語句不滿足上述約束條件時，對於本地資料庫的SQL查詢，BDE只能返回只讀的數據集。對於資料庫伺服器中的SQL查詢，只能返回錯誤的代碼。當Tquery或TADOquery組件返回一個「活動」的查詢結果數據集時，它的CanModIfy屬性的值會被設置成True。
§3.4MSSQLServer簡述
SQLServer是一個後台資料庫管理系統,它功能強大操作簡便,日益為廣大資料庫用戶所喜愛。越來越多的開發工具提供了與SQLServer的介面。SQLServer是一個關系資料庫管理系統，它最初是由Microsoft、Sybase和Ashton-Tate三家公司共同開發的。於1988年推出了第一個OS/2版本，在WindowsNT推出後，Microsoft與Sybase在SQLServer的開發上就分道揚鑣了，Microsoft將SQLServer移植到WindowsNT系統上，專注於開發推廣SQLServer的WindowsNT版本。
SQLServer2000是Microsoft公司推出的SQLServer資料庫管理系統的最新版本，該版本繼承了SQLServer7.0版本的優點，同時又比它增加了許多更先進的功能、具有使用方便、可伸縮性好與相關軟體集成程度高等優點。可跨越從運行MicrosoftWindows98的膝上型電腦到運行MicrosoftWindows2000的大型多處理器的伺服器等多種平台使用。MSSQLServer不但可以應用於大中型資料庫管理中，建立分布式關系資料庫，並且也可以開發桌面資料庫。事實上，SQLServer資料庫處理的基本結構，採取關系型資料庫模式，盡管如此，相信大家都可以輕易的發現，在SQLServer的資料庫處理方式，則是使用面向對象的操作方式與精神，也就是說，SQLServer的所有功能，都可以基於系統已經建立好的一些對象來達成，是相當OO（面向對象）的一個系統結構。
SQLServer企業管理器是SQLServer的主要管理工具，它提供了一個遵從MMC標準的用戶界面，使用戶得以：
·定義SQLServer實例組。
·將個別伺服器注冊到組中。
·為每個已注冊的伺服器配置所有SQLServer選項。
·在每個已注冊的伺服器中創建並管理所有SQLServer資料庫、對象、登錄、用戶和許可權。
·在每個已注冊的伺服器上定義並執行所有SQLServer管理任務。
·通過喚醒調用SQL查詢分析器，交互地設計並測試SQL語句、批處理和腳本。
·喚醒調用為SQLServer定義的各種向導。
·
第三章圖書管理系統設計分析
§4.1應用需求分析
圖書管理系統需要滿足來自三方面的需求，這三個方面分別是圖書借閱者、圖書館工作人員和圖書館管理人員。圖書借閱者的需求是查詢圖書館所存的圖書、個人借閱情況及個人信息的修改；圖書館工作人員對圖書借閱者的借閱及還書要求進行操作，同時形成借書或還書報表給借閱者查看確認；圖書館管理人員的功能最為復雜，包括對工作人員、圖書借閱者、圖書進行管理和維護，及系統狀態的查看、維護並生成催還圖書報表。
圖書借閱者可直接查看圖書館圖書情況，如果圖書借閱者根據本人借書證號和密碼登錄系統，還可以進行本人借書情況的查詢和維護部分個人信息。一般情況下，圖書借閱者只應該查詢和維護本人的借書情況和個人信息，若查詢和維護其他借閱者的借書情況和個人信息，就要知道其他圖書借閱者的借書證號和密碼。這些是很難得到的，特別是密碼，所以不但滿足了圖書借閱者的要求，還保護了圖書借閱者的個人隱私。
圖書館工作人員有修改圖書借閱者借書和還書記錄的許可權，所以需對工作人員登陸本模塊進行更多的考慮。在此模塊中，圖書館工作人員可以為圖書借閱者加入借書記錄或是還書記錄，並列印生成相應的報表給用戶查看和確認。
圖書館管理人員功能的信息量大，數據安全性和保密性要求最高。本功能實現對圖書信息、借閱者信息、總體借閱情況信息的管理和統計、工作人員和管理人員信息查看及維護。圖書館管理員可以瀏覽、查詢、添加、刪除、修改、統計圖書的基本信息；瀏覽、查詢、統計、添加、刪除和修改圖書借閱者的基本信息，瀏覽、查詢、統計圖書館的借閱信息，但不能添加、刪除和修改借閱信息，這部分功能應該由圖書館工作人員執行，但是，刪除某條圖書借閱者基本信息記錄時，應實現對該圖書借閱者借閱記錄的級聯刪除。並且還應具有生成催還圖書報表，並列印輸出的功能。
在本系統中由於沒有列印機設備供試驗，所以預先把報表列印改成報表預覽。
設計不同用戶的操作許可權和登陸方法
對所有用戶開放的圖書查詢
借閱者維護借閱者個人部分信息
借閱者查看個人借閱情況信息
維護借閱者個人密碼
根據借閱情況對資料庫進行操作並生成報表
根據還書情況對資料庫進行操作並生成報表
查詢及統計各種信息
維護圖書信息
維護工作人員和管理員信息
維護借閱者信息
處理信息的完整性
對借閱過期的圖書生成報表
圖4-2圖書管理系統資料庫應用需求的總結
根據以上所做的需求分析，並略掉一些細節（如不考慮用戶的登錄；對記錄的維護），得出以下的三層數據流圖。
§4.2系統功能模塊劃分
系統功能框圖如圖4-10所示。
§4.3系統資料庫設計
4.3.1概念設計
在概念設計階段中，設計人員從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然後再把概念模式轉換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。
利用ER方法進行資料庫的概念設計，可分成三步進行：首先設計局部ER模式，然後把各局部ER模式綜合成一個全局模式，最後對全局ER模式進行優化，得到最終的模式，即概念模式。
（1）設計局部ER模式
實體和屬性的定義：
圖書（圖書編號，圖書名稱，作者，出版社，出版日期，備注，價格，數量，）
借閱者（借書證號，姓名，性別，身份證，聯系電話，密碼）
身份（身份編號，身份描述，最大借閱數）
圖書類別（圖書類別編號，類別描述）
ER模型的「聯系」用於刻畫實體之間的關聯。一種完整的方式是對局部結構中任意兩個實體類型，依據需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯系。若有聯系，進一步確定是1:N，M:N，還是1:1等。還要考察一個實體類型內部是否存在聯系，兩個實體類型之間是否存在聯系，多個實體類型之間是否存在聯系，等等。聯系定義如圖4-5所示。解釋如下：
u一個借閱者（用戶）只能具有一種身份，而一種身份可被多個借閱者所具有；
u一本圖書只能屬於一種圖書類別（類別），而一種圖書類別可以包含多本圖書；
u一個用戶可以借閱多本不同的書，而一本書也可以被多個不同的用戶所借閱。
（2）設計全局ER模式
所有局部ER模式都設計好了後，接下來就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的資料庫概念結構。
1)確定公共實體類型
為了給多個局部ER模式的合並提供開始合並的基礎，首先要確定各局部結構中的公共實體類型。在這一步中我們僅根據實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候眩
2)局部ER模式的合並
合並的原則是：首先進行兩兩合並；先和合並那些現實世界中有聯系的局部結構；合並從公共實體類型開始，最後再加入獨立的局部結構。
3)消除沖突
沖突分為三類：屬性沖突、結構沖突、命名沖突。
設計全局ER模式的目的不在於把若干局部ER模式形式上合並為一個ER模式，而在於消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。
3)全局ER模式的優化
在得到全局ER模式後，為了提高資料庫系統的效率，還應進一步依據處理需求對ER模式進行優化。一個好的全局ER模式，除能准確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數要盡可能的少；實體類型所含屬性個數盡可能少；實體類型間聯系無冗餘。
綜上所述，「圖書管理系統」的全局ER模式如圖4-13所示。
4.3.2關系資料庫的邏輯設計
由於概念設計的結果是ER圖，DBMS一般採用關系型（本人所使用的MSSQLServer就是關系型的DBMS），因此資料庫的邏輯設計過程就是把ER圖轉化為關系模式的過程。由於關系模型所具有的優點，邏輯設計可以充分運用關系資料庫規范化理論，使設計過程形式化地進行。設計結果是一組關系模式的定義。
（1）導出初始關系模式
book（圖書編號＃，圖書名稱，圖書類別＃，作者，出版社，出版日期，備注，價格，數量）class（圖書類別#，類別名）user（借書證號＃，姓名，性別，身份編號＃，身份證，聯系電話，密碼）ID（身份編號#，身份描述，最大借閱數）Owner（借書證號#,圖書編號#，借書日期）
圖4-14關系模式集
（2）產生子模式
子模式是用戶所用到的那部分數據的描述。除了指出用戶用到的數據外，還應指出數據與概念模式中相應數據的聯系，即指出概念模式與子模式之間的對應性。
借書子模式（借書證號#，姓名，圖書編號＃，圖書名稱，借書日期）
圖4-15部分子模式
（3）根據設計中出現的問題本人在寫系統時還加入了兩個關系模式：
1、ownertemp：用於工作人員在處理借書、還書工作時臨時存儲借書、還書信息，以便列印報表時使用。
2、keyer：用於存儲工作人員和圖書館管理員的用戶名和密碼及許可權，以便工作人員或圖書館管理員進入相應的功能模塊時進行驗證用戶的身份。
4.3.3資料庫的實現
我選用MicrosoftSQLServer2000(企業版)資料庫來進行資料庫的邏輯設計。首先創建七個基本資料庫表如表4-1－4-7所示，然後根據全局ER圖，建立各個表之間的聯系，如圖4-8所示。
表4-1借閱者基本信息表的結構(User)
表4-2圖書信息表的結構（Book）
表4-3圖書類別信息表的結構（Class）
表4-4借閱者身份信息表的結構（ID）
表4-5借閱情況信息表的結構（Owner）
表4-6借閱情況臨時存儲信息表的結構（Ownertemp）
註：在owner表和ownertemp表中加入了索引欄位，用來唯一標識一條借書記錄，並且設置為標識，標識種子為1。
表4-7工作人員和管理員信息表的結構（Keyer）
圖4-8資料庫表間聯系圖
第五章圖書管理系統應用程序設計
§5.1系統窗體模塊組成
§5.2數據模塊窗體的設置
在編寫資料庫應用程序時，經常要遇到這樣的情況，即好多組件、窗體同時訪問相同的數據源，如果為每一個組件或者窗體都設置一個數據源將是十分耗時的工件，而且要保證這些數據源的確是相同的也需花一番功夫。那麼，能不能將這些數據源集中管理，最好是做成一個統一的模塊，需要時就將該模塊引入而不必直接操作數據源本身呢？數據模塊（DataMole）是解決這個問題最好的答案。簡單說來，數據模塊是用來集中管理數據源的一個窗體，該窗體可被需要的地方隨時引入。
但本人在開發這個系統時，開始使用了一下數據模塊，但在使用過程中卻碰到了一些問題。並且考慮這個系統使用到的TADOQuery控制項比較多，如果使用數據控制項可能會帶來管理上的麻煩，如弄混各個數據控制項的作用。還考慮到使用動態生成ADOQuery可能會更節省資源。所以在本人的系統中，開始做的第一個模塊「借閱者個人模塊」中還稍微使用了一下數據模塊。但在後面做的兩個模塊中大多都是用動態生成ADOQuery來實現的。並且由於SQL語句是動態加入的所以datamole中的控制項也不會多。
§5.3啟動畫面的實現
啟動畫面是為了給用戶一個良好的印像，加深軟體的親和力，沒有實際的功能，在Form1窗體中加入了Image和Time組件。啟動畫面的窗體略，主要的源代碼如下：
§5.4用戶登錄窗體的的實現
本窗體是為三種不同的用戶（一般用戶，工作人員，管理員）提供選擇以進入不同的模塊，滿足不同用戶的需求。源代碼比較簡單，略。
§5.5用戶密碼認證窗體的的實現
本窗體是為了讓工作人員或圖書館管理員按照用戶名和密碼進行登錄，並且跟據用戶名檢查Keyer表中的「許可權」欄位，以分辯進入圖書館管理人員模塊還是進入工作人員模塊。窗體界面、源代碼如下
§5.6借閱者服務模塊的實現
借閱者服務窗體的功能主要是圖書的查詢，個人借閱情況查看及個人部分信息的修改。界面圖如下：
5.6.1圖書查詢功能的實現
在本系統中，任何人都有許可權使用查詢功能，不做任何限制。界面如下，
由於實現的查詢功能有多種，如按圖書編號、圖書名稱等欄位進行完全體配查找和部分體配的模糊查找，還有按多個條件進行邏輯與或是邏輯或的多條件查找。其中實現的方法者差不多，所以只給出多條件查找的代碼，如下：
5.6.2借閱者登錄功能的實現
這個功能的實現與工作人員和管理人員登錄功能實現的方法大致一樣，並且還要簡單。是從User表中查到到借閱證號與密碼，看與用戶輸入的是否一致。如果一致，那麼用戶就可查看自已的借閱情況並維護自己的部分信息。源代碼與借閱者登錄界面都略。
5.6.3借閱者借閱情況功能的實現
當借閱者正確登錄到系統後，此功能將被激活，使用戶能查看到自身的借閱情況。在此系統中，信息的顯示一般用ListView來實現，只在較少的情況下用到了DBgrid，因為我覺得ListView更好實現，並能使信息數據對用戶的完全分離。
在這里跟據借閱者的不同要求實現借閱情況的查詢，有檢查所有的借閱情部、某本書的借閱情況、和根據已借閱天數的來查詢。其中根椐借閱天數來查詢更有代表性，有方式一和方式二。以下給出此功能的源代碼
按借閱天數查詢方式一
按借閱天數查詢方式二
5.6.4借閱者個人資料維護功能的實現
此功能實現當前借閱者部份資料的修改，但借書證號和身份類別這樣的信息不允許修改，這是圖書館管理員模塊的功能。在此界面中點擊修改按鈕將出現「修改」窗體（Form8），點擊修改密碼按鈕將出現groupbox8，在這里進行密碼修改。關鍵源代碼如下。
這里給出個人部分信息修改的源代碼：
這里給出密碼修改的源代碼：
5.7工作人員－圖書借閱/歸還模塊的實現
5.7.1工作人員進行圖書借閱功能實現
在這個功能中，工作人員輸入借閱者的借閱證號和所要借閱的圖書的圖書編號，然後點擊借閱按鈕就可進行圖書借閱。考慮到實際中可能會出現只知圖書名而不知圖書編號的情況，在此界面下方加入了一個轉換功能，可以把圖書名稱轉換成圖書編號，再進行圖書借閱。
在借閱完成後會生借閱報表以便借閱者檢查和確認，借閱報表的列印效果如下圖，實現比較簡單，略去實現過程。
5.7.2工作人員進行圖書歸還功能實現
在此功能中，工作人員根據借閱者的借書證號和歸還的圖書編號進行圖書的歸還工作。並且根據現實中可能會出現的只知圖書名不知圖書編號的歸還情況，所以加入了按書籍名稱進行歸還的功能。這個功能是圖書借閱功能中把圖書名稱轉換成圖書編號的一種改進方法，這樣就不用如借閱功能中一樣要先轉換再借閱了。歸還完成後，同樣會列印出歸還報表以便用戶檢查和確認。
5.8圖書館管理員模塊的實現
5.8.1圖書館管理員圖書管理功能的實現
在這個功能中可以在（＊圖書編號）中輸入圖書編號，點查找按鈕後就會在各個相應的組件中顯示出信息，或按圖書名稱模糊查找到所要的記錄，在各個相應的組件中顯示第一條記錄的信息，也可在下端的ListView組件中點擊某一條記錄，在各個相應的組件中也會顯示所選記錄的信息。在入庫功能中只要不是相同的圖書編號並且帶＊號提示的欄位不為空就可插入新的圖書記錄。刪除則刪除那些Book表中的圖書記錄，如果借出還可依用戶要求連帶刪除owner表中的記錄。因為圖書修改與圖書入庫的功能與工作人員記錄修改和工作人員記錄添加的實現過程一樣，所以下面僅給出刪除功能的源代碼，如下
5.8.2圖書館管理員工作人員和管理員管理功能的實現
在此功能中可以加入工作人員或是管理員，或是修改他們的密碼、許可權。
在此功能中如果選中ListView中的記錄，則在右邊相應的組件中顯示出信息，並且管理員還可對這些記錄進行修改或加入新的記錄。並且也可以點刪除按鈕刪除選中的一條或多條記錄。刪除功能與圖書記錄的刪除一般，所以下面只給出添加與修改的實現過程。
5.8.3圖書館管理員修改圖書類別及統記功能的實現
在此窗體中能對圖書的類別進行刪除，添加和修改，這模塊的功能的實現過程與圖書記錄的刪除，添加和修改一樣的，但是這個窗體還能跟據圖書類別進行統計，還可根據Book表和owner表統計出圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目。在這里給出統計圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目的實現過程中的幾個函數和過程
5.8.4圖書館管理員借閱者管理功能的實現
查詢借閱者可根據借閱者的借書證號或姓名或身份編號查找到借閱者的信息，也可以實行模糊查找，這個功能的實現與前面圖書查找的實現過程一般，就不再詳細說明。
5.8.5圖書館維護借閱者管理功能的實現
此功能能對借閱者信息進行查看添加、刪除、修改。在這里給出刷新按鈕的實現過程
5.8.6圖書館身份維護功能的實現
這一部分是對借閱者身份進行管理，能對身份進行添加、刪除、修改。並且同樣的在listview中選中某條或多條記錄時會在相應的右邊的組件中顯示出信息。此功能實現過程與前面所敘有雷同，略。
5.8.7圖書館借閱者統計功能的實現
此功能按借閱者身份進行統計，得出具有某種身份的借閱者總數，此種身份的並借閱圖書的借閱者數和所借閱的圖書數，在下面給出實現過程。
5.8.8圖書館統計借閱過期記錄功能的實現
列印出的借閱過期催還報表如下圖所示：
此報表能顯示按借書證號升序排列的借閱信息超過限定時限的信息，其中主要的SQL語句如下：
5.9系統信息顯示的實現
顯過本系統的信息，並且右邊的字向上滾動顯示，主要實現如下：
另外,虛機團上產品團購,超級便宜
7. 系統資料庫和模型庫設計
（一）系統資料庫類型
資料庫是整個農用地分等信息系統的基礎，是系統開發設計要考慮的重中之重。在數據形式上，系統資料庫包括兩大塊：一是空間資料庫，二是屬性資料庫。目前的空間數據技術已從以MapInfo為代表的混合型資料庫（空間資料庫＋關系型資料庫）發展到以ArcInfo的Coverage為代表的拓展型資料庫。鑒於農用地分等屬性數據量龐大，為減少數據冗餘，提高數據檢索的速度，本研究採用空間數據和屬性數據分開管理的模式，依據關鍵欄位進行綁定，進行科學索引，從而實現空間數據和屬性動態鏈接和高效整合。
1.空間資料庫
江蘇省農用地分等信息系統空間資料庫內容包括以下方面：
（1）土地利用現狀圖層：全省13個省轄市以1996年土地利用現狀圖為基礎，經變更調繪形成以2000年為基準年的土地利用現狀圖，以現行的土地分類標准按八大類分類進行信息提取並分層存儲，系統分別存儲為耕地、林地、水域、未利用地、建設用地等圖層。
（2）全省土壤類型圖層：以土屬為分類單位，比例尺為1:20萬。
（3)1996年和2000年全省行政區劃圖層：在行政區劃中精確到鄉鎮級別，分別提取存儲了市名圖層、縣（區）名圖層、鄉（鎮）名圖層、全省行政界線圖層、市級行政界線圖層、縣（區）級行政界線圖層、鄉（鎮）級行政界線圖層。
（4）評價單元圖層：通過GIS空間疊加功能，利用土地利用現狀圖、行政區劃圖和土壤類型圖疊加產生的評價單元圖層，建立分等評價單元資料庫。
2.屬性資料庫
江蘇省農用地分等信息系統屬性資料庫內容包括以下方面：
（1）土壤屬性數據：以全國第二次土壤普查為基礎，結合全省土壤監測樣點數據，建立土壤質量狀況資料庫，最小單位為土種，包括pH值、有機質含量、表層土壤質地、耕層厚度、障礙層深度、水土侵蝕程度、鹽漬化程度數據。
（2）農田水利環境數據：建立了1996～2000年間各鄉鎮農田水利環境基礎資料庫，包括灌溉保證率、排水條件數據。
（3）土地利用現狀數據：建立了全省13個省轄市的以1996年土地利用現狀圖為基礎，經變更調繪形成的以2000年為基準年的土地利用現狀資料庫，區分耕地中的詳細用地類型差異，標示水田、旱地、荒草地等納入本次評價范圍的用地內容。
（4）全省地形地貌資料庫。
（5）農業區劃數據：輸入了江蘇省農業區劃數據，把江蘇全省劃分為6大區劃，以鄉鎮為最小級別，建立全省鄉鎮的區劃歸屬資料庫。
（6）農業耕作制度數據：建立了全省各市、縣、鄉鎮的農業耕作制度資料庫，包括指定作物水稻和小麥的播種空間分布狀況資料庫。
（7）光溫生產潛力數據：建立了全省各市、縣指定作物水稻和小麥的光溫生產潛力和氣候生產潛力資料庫。
（8）農業投入－產出數據：全省13個省轄市以鄉鎮為單位，建立了1996～2000年農業生產投入－產出資料庫。
（9）作物產量數據：全省13個省轄市以鄉鎮為單位，建立了1996～2000年的指定作物水稻和小麥的產量資料庫。
（10）土地利用詳查分類面積數據：全省13個省轄市以鄉鎮為單位，建立了2000年土地利用詳查分類面積資料庫。
從數據格式上分，資料庫又可分為：①圖件資料庫：指空間數據以及綁定在空間數據上的相關屬性數據，本次江蘇省農用地分等建立了以分等單元為記錄的屬性資料庫，並通過關鍵欄位與空間數據關聯；②分類統計資料庫：包括全省13個省轄市以鄉鎮為單位的1996～2000年指定作物產量統計數據和全省13個省轄市以鄉鎮為單位的2000年土地利用詳查分類面積統計數據。
（二）系統資料庫管理模式
為減少數據存儲冗餘，同時提高索引速度，江蘇省農用地分等信息系統數據文件採用普遍的目錄樹形式進行管理，按省－市－縣行政體系分別存儲相關數據。全省建立13個省轄市分目錄，分目錄下按照各自所含的縣（區）建立子目錄。根據目前行政管理體系現狀，基礎資料大多來源於縣級行政單位，因此採用縣（區）為基本行政單位較為合理，在保證資料來源的同時，也利於資料的分類歸檔存儲。其相對應的空間圖件數據也按精度要求分割到縣級行政單位，既能減少系統調用數據的吞吐量，同時也滿足了系統的精度需求。空間數據、屬性數據、文本數據按照各自所屬的行政級別歸類存儲，同時設立數據文件管理器進行目錄文件的索引管理，見圖3-86。
圖3-86 江蘇省農用地分等信息系統數據文件管理模式圖
（三）系統資料庫結構
資料庫的結構設計決定了數據之間的調用及介面關系，清晰的邏輯調用關系和統一的數據介面格式有利於數據的組織、管理、調用。
1.空間資料庫
江蘇省農用地分等信息系統空間資料庫以矢量圖件的形式存在，以分圖層的方式管理，包括了全省行政界線、土壤類型、按八大類分別提取的土地利用現狀、分等單元等圖層。其中，分等單元圖層作為農用地分等的基礎，考慮到圖層本身信息量大，可能影響到系統運行效率，因此所在圖層的屬性表中只保留了ID欄位，通過ID欄位與外部屬性庫綁定，實現分等單元與外部屬性庫一一對應關系。ID欄位是本圖層的特徵代碼，表徵了單元的唯一性，能體現出單元的圖上位置和行政歸屬。《農用地分等定級規程》（國土資源大調查專用）和《中華人民共和國行政區劃代碼》（GB/T 2260-1999）為本研究分等單元代碼的編碼依據；本研究有1996年和2000年兩套行政區劃工作底圖，為此分等單元特徵代碼共設14位，依次為江蘇省代碼（2位）－市代碼（2位）－2000年縣或區代碼（2位）－2000年鄉鎮代碼（2位）－1996年縣或區代碼（2位）－1996年鄉鎮代碼（2位）－分等單元號（2位）。其中，省、市、縣（區）的行政代碼按國家統一代碼，鄉鎮級代碼在縣（區）范圍內根據劃分分等單元的需要依次編碼；分等單元編號的原則是不破鄉鎮界，即單元號是在同一鄉鎮內部自行編碼。示例：32011501210101，指1996年江蘇（32）南京（01）市江寧縣（21）由於2000年行政調整變更為南京（01）的江寧區（15）。按行政體系分級編碼的優點是有利於空間查詢和國土資源管理部門根據工作需求按行政級別分類匯總統計數據。
2.屬性資料庫
江蘇省農用地分等信息系統採用關系型資料庫來存儲數據，優點是結構清晰明了，數據的更新維護方便，通過索引能優化資料庫，建立快速的查詢瀏覽（表3-26～表3-30）。
表3-26 行政代碼數據結構表
表3-27 土壤屬性數據結構表
表3-28 農田水利設施數據結構表
表3.29 指定農作物投入－產出數據結構表
表3-30 農業耕作制度及農業區劃表
（四）系統模型庫
系統以《農用地分等定級規程》（國土資源大調查專用）中的相關技術方法和計算模型為基礎，在模型庫中預先內置了分等計算模型。模型庫是動態，它允許專家根據情況動態調整計算模型形式及其參數。系統主要模型的數學計算公式如下：
（1）農用地自然質量分值（Clij）計算公式見式（3-11）。
（2）樣點土地利用系數計算公式：
中國耕地質量等級調查與評定（江蘇卷）
式中：
Klj´——樣點的第j種指定作物土地利用系數；
Yj——樣點的第j種指定作物實際單產；
Yj,max——第j種指定作物最大標准糧單產。
（3）等值區土地利用系數計算公式：
中國耕地質量等級調查與評定（江蘇卷）
式中：
Klj——等值區內第j種指定作物土地利用系數；
Klj´——參與計算的同一等值區內合格樣點第j種指定作物土地利用系數；
n——排除異常數據後參與計算的樣點的個數。
（4）樣點土地經濟系數計算公式：
中國耕地質量等級調查與評定（江蘇卷）
式中：
Kcj′——樣點的第j種指定作物土地經濟系數；
Yj——樣點第j種指定作物實際單產；
Cj——樣點第j種指定作物實際成本；
Aj——第j種指定作物最高「產量－成本」指數。
（5）等值區土地經濟系數計算公式：
中國耕地質量等級調查與評定（江蘇卷）
式中：
Kcj——等值區內土地經濟系數；
Kcj´——參與計算的同一等值區內合格樣點第j種指定作物土地經濟系數；
n——排除異常數據後參與計算的樣點的個數。
（6）農用地自然質量等指數（Ri）計算公式見式（3-12）和式（3-13）。
（7）農用地利用等指數（Yi）計算公式見式（3-14）和式（3-15）。
（8）農用地經濟等指數（Gi）計算公式見式（3-16）和式（3-17）。
8. 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
1、項目計劃
1.1系統開發目的
（1）大大提高超市的運作效率；
（2）通過全面的信息採集和處理，輔助提高超市的決策水平；
（3）使用本系統，可以迅速提升超市的管理水平，為降低經營成本， 提高效益，增強超市擴張力， 提供有效的技術保障。
1.2背景說明
21世紀，超市的競爭也進入到了一個全新的領域，競爭已不再是規模的競爭，而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢，多種業態：超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模，成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點，為了幫助超市解決現在面臨的問題，提高小型超市的競爭力，我們將開發以下系統：前台POS銷售系統、後台管理系統，其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
（1）商品條形碼：每種商品具有唯一的條形碼，對於某些價格一樣的商品，可以使用自定義條形碼。
（2）交易清單：包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
（3）商品積壓：在一定時期內，遠無法完成銷售計劃的商品會造成積壓。
（4）促銷：在一定時期內，某些商品會按低於原價的促銷價格銷售。
庫存告警提示：當商品的庫存數量低於庫存報警數量時發出提示。
（5）盤點：計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編
2、邏輯分析與詳細分析
2.1系統功能
（1）、零售前台（POS）管理系統，本系統必須具有以下功能：
商品錄入：根據超巿業務特點制定相關功能，可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
收銀業務：通過掃描條形碼或者直接輸入商品名稱（對於同類多件商品採用一次錄入加數量的方式）自動計算本次交易的總金額。在顧客付款後，自動計算找零，同時列印交易清單（包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號）。如果顧客是本店會員並持有本人會員卡，則在交易前先掃描會員卡，並對所購物品全部實行95折優惠，並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年，滿一年未續卡者，該會員卡將被注銷。
安全性：OS登陸、退出、換班與操作鎖定等許可權驗證保護；斷電自動保護最大限度防止意外及惡意非法操作。
獨立作業：有的斷網收銀即在網路伺服器斷開或網路不通的情況下，收銀機仍能正常作業
(2)、後台管理系統，本系統必須具備以下功能
進貨管理： 根據銷售情況及庫存情況，自動制定進貨計劃（亦可手工制定修改），可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
銷售管理： 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜，靈活察看和列印商品銷售日、月、年報表。
庫存管理： 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警，避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
人員管理： 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。
（3）系統結構
系統總體結構
模塊子系統結構
功能描述：商品錄入子系統要求能快速錄入商品，因此必須支持條形碼掃描。
功能描述：收銀業務子系統能計算交易總額，列印交易清單，並根據會員卡打折。
功能描述：進貨管理子系統可以根據庫存自動指定進貨計劃，進貨時自動等級，以及提供查詢和列印計劃進貨與入庫記錄的功能。
功能描述：銷售管理子系統可以控制某商品是否允許銷售，查詢每種商品的銷售情況並產生年、月、日報表，同時可以生成銷售排行榜。
功能描述：庫存管理子系統提供查詢庫存明細記錄的基本功能，並根據庫存的狀態報警，以及自動盤點計算。
功能描述：人員管理子系統提供基本信息登記管理，員工操作許可權管理，客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統
頂層DFD圖
第0層DFD圖
第1層DFD圖
2.3、戶類型與職能
（1）、員工（營業員）：
通過商品條形碼掃描輸入商品到購買清單
操作軟體計算交易總金額
操作軟體輸出交易清單
對會員進行會員卡掃描以便打折
（2）、：超市經理
操作軟體錄入商品，供貨商，廠商
操作軟體制定進貨計劃
查詢列印計劃進貨與入庫記錄
操作軟體控制商品銷售與否
查詢列印銷售情況
操作軟體生成銷售排行榜
查詢庫存明細記錄
根據軟體發出的庫存告警進行入貨
操作軟體進行盤點計算
（3）、總經理：
基本信息登記管理
員工操作許可權管理
客戶銷售許可權管理
2.4、統開發步驟
確定參與者和相關的用況
為每個用況設計過程
建立順序圖，確定每個腳本中對象的協作
創建類，確定腳本中的對象
設計, 編碼, 測試, 集成類
為過程編寫系統測試案例
運行測試案例，檢驗系統
2.5、系統環境需求
系統模式
本系統採用C/S模式作為開發模式
硬體環境
伺服器端：
高性能的計算機一台，
普通的雙絞線作為連接。
客戶端： 普通的計算機或者工作站，
普通的雙絞線作為連接。
軟體環境
伺服器端：安裝SQL Server 2000的伺服器版本，
安裝windows 2000伺服器版本，
配置了諾頓等必須的防毒軟體。
客戶端： 安裝SQL Server2000的伺服器版本，
安裝了VB等可視化開發工具軟體，
安裝windows2000伺服器版本。
2.6、系統安全問題
信息系統盡管功能強大，技術先進，但由於受到自身體系結構，設計思路以及運行機制等限制，也隱含許多不安全因素。常見因素有：數據的輸入，輸出，存取與備份，源程序以及應用軟體，資料庫，操作系統等漏洞或缺陷，硬體，通信部分的漏洞，企業內部人員的因素，病毒，「黑客」等因素。因此，為使本系統能夠真正安全，可靠，穩定地工作，必須考慮如下問題：為保證安全，不致使系統遭到意外事故的損害，系統因該能防止火，盜或其他形式的人為破壞。
系統要能重建
系統應該是可審查的
系統應能進行有效控制，抗干擾能力強
系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型（use cases view）（用例視圖）的基本組成部件是用例（use case）、角色(actor)和系統(system)。用例用於描述系統的功能，也就是從外部用戶的角度觀察，系統應支持哪些功能，幫助分析人員理解系統的行為，它是對系統功能的宏觀描述，一個完整的系統中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統的所有基本功能（集）。角色是與系統進行交互的外部實體，它可以是系統用戶，也可以是其它系統或硬體設備，總之，凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域（即用例的活動區域）則抽象表示系統能夠實現的所有基本功能。在一個基本功能（集）已經實現的系統中，系統運轉的大致過程是：外部角色先初始化用例，然後用例執行其所代表的功能，執行完後用例便給角色返回一些值，這個值可以是角色需要的來自系統中的任何東西。
UML：是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標准表示；它不是一種可視化的程序設計語言而是一種可視化的建模語言；不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准；不是過程也不是方法但允許任何一種過程和方法使用它。
用例（use case）：
參與者（actor）：
3.2、UML模型
3.21、系統UML模型
3.22、子系統UML模型
（1）零售前台（POS）管理系統用例視圖
（2）後台管理系統用例視圖
3.3、系統實現圖
4、超市銷售系統概念設計文檔
（1）、系統ER圖
（2）、系統ER圖說明
1) 商店中的所有用戶（員工）可以銷售多種商品，每種商品可由不同用戶（員工）銷售；
2) 每個顧客可以購買多種商品，不同商品可由不同顧客購買；
3) 每個供貨商可以供應多種不同商品，每種商品可由多個供應商供應。
（3）、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖；
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖；
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖；
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
（1）、系統關系模型
a) 商品信息表（商品編號，商品名稱，價格，條形碼，促銷價格，促銷起日期，促銷止日期，允許打折，庫存數量，庫存報警數量，計劃進貨數，允許銷售，廠商編號，供貨商編號）
b) 用戶表（用戶編號，用戶名稱，用戶密碼，用戶類型）
c) 會員表（會員編號，會員卡號，累積消費金額，注冊日期）
d) 銷售表（銷售編號，商品編號，銷售數量，銷售金額，銷售日期）
e) 交易表（交易編號，用戶名稱，交易金額，會員卡號，交易日期）
f) 進貨入庫表（入庫編號，入庫商品編號，入庫數量，單額，總額，入庫日期，計劃進貨日期，入庫狀態）
g) 供貨商表（供貨商編號，供貨商名稱，供貨商地址，供貨商電話）
h) 廠商表（廠商編號，廠商名稱，廠商地址，廠商電話）
（2）、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表
商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號
用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型
會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期
銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額
交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱
入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態
供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話
廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go
/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO
/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO
/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO
7、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
9. 千表的資料庫模型怎麼設計模塊模型
設計千表的資料庫模型設計模塊模型的方法：
細化和確定模塊的功能(包括異常處理需求)、識別關鍵問題和實現策略與流程、以及主要靜態類和線程結構設計等。
詳細設計完成並通過評審之後，模塊負責人根據詳細設計指導，進行編碼並實現模塊。
模塊設計方法是從計算機的模塊程序設計法發展而來用於操作系統的方法，即對操作系統的各個模塊分別進行設計的方法。要使操作系統具有較高的可靠性、可維護性和高效率，關鍵是結構設計。早期的傳統模塊設計法出自於早期的管理程序。
總結如下：
一個龐大的操作系統劃分成許多模塊之後，各模塊之間必然產生聯系，組成復雜的網狀結構，其復雜程度將隨著模塊的增加而成倍增長。
主要問題是如何劃分模塊，如何處理模塊之間的介面關系。近來提出的類程和管理模塊是劃分模塊的好方法。它可使模塊之間的介面簡化，而且還保持了模塊具有的效率高、系統開銷小的特點。
10. 具體的資料庫設計與實現過程
大致的講主要是根據用戶的需求，然後設計資料庫的E-R模型，然後將E-R模型圖轉換為各種表，並對其進行資料庫設計範式（範式因不同書籍有不同）的審核，然後進行資料庫的實施，然後運行維護。
一句話來講就是將用戶的需求變成帶有各種關系的表，以及其它的資料庫結構，然後供編程使用
具體如下：
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下六個階段
（1）需求分析。
（2）概念設計。
（3）邏輯設計。
（4）物理設計。
（5）資料庫實施。
（6）資料庫運行和維護。
5．1．1 需求分析階段
進行資料庫設計首先必須准確了解與分析用戶需求，包括數據與處理需求。需求分析是整個設計過程的基礎，是最困難、最耗時的一步。作為「地基」的需求分析是否做得充分與准確，決定了在其上構建「資料庫大廈」的速度與質量。需求分析做得不好，可能會導致整個資料庫重新設計，因此，務必引起高度重視。
5．1．2 概念模型設計階段
在概念設計階段，設計人員僅從用戶角度看待數據及其處理要求和約束，產生一個反映用戶觀點的概念模式，也稱為「組織模式」。概念模式能充分反映現實世界中實體間的聯系，又是各種基本數據模型的共同基礎，易於向關系模型轉換。這樣做有以下好處：
（1）資料庫設計各階段的任務相對單一化，設計復雜程度得到降低，便於組織管理。
（2）概念模式不受特定DBMS的限制，也獨立於存儲安排，因而比邏輯設計得到的模式更為穩定。
（3）概念模式不含具體的DBMS所附加的技術細節，更容易為用戶所理解，因而能准確地反映用戶的信息需求。
概念模型設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型。如採用基於E-R模型的資料庫設計方法，該階段即將所設計的對象抽象出E-R模型；如採用用戶視圖法，則應設計出不同的用戶視圖。
5．1．3 邏輯模型設計階段
邏輯模型設計階段的任務是將概念模型設計階段得到的基本E-R圖，轉換為與選用的DBMS產品所支持的數據模型相符合的邏輯結構。如採用基於E-R模型的資料庫設計方法，該階段就是將所設計的E-R模型轉換為某個DBMS所支持的數據模型；如採用用戶視圖法，則應進行表的規范化，列出所有的關鍵字以及用數據結構圖描述表集合中的約束與聯系，匯總各用戶視圖的設計結果，將所有的用戶視圖合成一個復雜的資料庫系統。
5．1．4 資料庫物理設計階段
資料庫的物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存取方法。顯然，資料庫的物理設計完全依賴於給定的硬體環境和資料庫產品。在關系模型系統中，物理設計比較簡單一些，因為文件形式是單記錄類型文件，僅包含索引機制、空間大小、塊的大小等內容。
物理設計可分五步完成，前三步涉及到物理結構設計，後兩步涉及到約束和具體的程序設計：
（1）存儲記錄結構設計：包括記錄的組成、數據項的類型、長度，以及邏輯記錄到存儲記錄的映射。
（2） 確定數據存放位置：可以把經常同時被訪問的數據組合在一起，「記錄聚簇（cluster）」技術能滿足這個要求。
（3）存取方法的設計：存取路徑分為主存取路徑及輔存取路徑，前者用於主鍵檢索，後者用於輔助鍵檢索。
（4）完整性和安全性考慮：設計者應在完整性、安全性、有效性和效率方面進行分析，作出權衡。
（5）程序設計：在邏輯資料庫結構確定後，應用程序設計就應當隨之開始。物理數據獨立性的目的是消除由於物理結構的改變而引起對應用程序的修改。當物理獨立性未得到保證時，可能會引發對程序的修改。
資料庫物理設計是為邏輯數據模型選取一個最適合應用環境的物理結構，包括存儲結構和存取方法。
5．1．5 資料庫實施階段
根據邏輯設計和物理設計的結果，在計算機系統上建立起實際資料庫結構、裝入數據、測試和試運行的過程稱為資料庫的實施階段。實施階段主要有三項工作。
（1）建立實際資料庫結構。對描述邏輯設計和物理設計結果的程序即「源模式」，經DBMS編譯成目標模式並執行後，便建立了實際的資料庫結構。
（2）裝入試驗數據對應用程序進行調試。試驗數據可以是實際數據，也可由手工生成或用隨機數發生器生成。應使測試數據盡可能覆蓋現實世界的各種情況。
（3）裝入實際數據，進入試運行狀態。測量系統的性能指標，是否符合設計目標。如果不符，則返回到前面，修改資料庫的物理模型設計甚至邏輯模型設計。
5．1．6 資料庫運行和維護階段
資料庫系統正式運行，標志著資料庫設計與應用開發工作的結束和維護階段的開始。運行維護階段的主要任務有四項：
（1）維護資料庫的安全性與完整性：檢查系統安全性是否受到侵犯，及時調整授權和密碼，實施系統轉儲與備份，發生故障後及時恢復。
（2）監測並改善資料庫運行性能：對資料庫的存儲空間狀況及響應時間進行分析評價，結合用戶反應確定改進措施。
（3）根據用戶要求對資料庫現有功能進行擴充。
（4）及時改正運行中發現的系統錯誤。