資料庫系統設計實現與管理

A. 簡述資料庫設計過程

資料庫設計過程分為以下六個階段：

1、需求分析階段

准確理解和分析用戶需求（包括數據和處理），它是整個設計過程的基礎，也是最困難、最耗時的一步。

2、概念結構設計階段

是整個資料庫設計的關鍵，通過對用戶需求的集成、歸納和抽象，形成了一個獨立於特定資料庫管理系統的概念模型。

3、邏輯結構設計階段

將概念結構轉換為DBMS支持的數據模型，對其進行優化。

4、資料庫物理設計階段

為邏輯數據模型選擇最適合應用程序環境的物理結構（包括存儲結構和存取方法）。

5、資料庫實現階段

根據邏輯設計和物理設計的結果，使用資料庫管理系統提供的數據語言、工具和主機語言，建立資料庫，編寫調試應用程序，組織數據倉庫，並進行試運行。

6、資料庫運行維護階段

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

註：在設計過程中，將資料庫的設計與資料庫中數據處理的設計緊密結合起來，在每個階段同時對這兩個方面的要求進行分析、抽象、設計和實現，相互借鑒和補充，從而完善這兩個方面的設計。

(1)資料庫系統設計實現與管理擴展閱讀：

資料庫設計技術

1、清晰的用戶需求：作為計算機軟體開發的重要基礎，資料庫設計直接反映了用戶的需求。資料庫必須與用戶緊密溝通，緊密結合用戶需求。在定義了用戶開發需求之後，設計人員還需要反映具體的業務關系和流程。

2、注意數據維護：設計面積過大、數據過於復雜是資料庫設計中常見的問題，設計人員應注意數據維護。

3、增加命名規范化：命名資料庫程序和文件非常重要，不僅要避免重復的名稱，還要確保數據處於平衡狀態。為了降低檢索信息和資源的復雜度和難度，設計人員應了解資料庫程序與文件之間的關系，並靈活使用大小寫字母命名。

4、充分考慮資料庫的優化和效率：考慮到資料庫的優化和效率，設計人員需要對不同表的存儲數據採用不同的設計方法。在設計中，還應該使用最少的表和最弱的關系來實現海量數據的存儲。

5、不斷調整數據之間的關系：不斷調整和簡化數據之間的關系，可以有效減少設計與數據之間的聯系，進而為維護數據之間的平衡和提高數據讀取效率提供保障。

6、合理使用索引：資料庫索引通常分為聚集索引和非聚集索引，這樣可以提高數據搜索的效率。

參考資料來源：網路-資料庫設計

B. 管理信息系統的資料庫設計包括哪些步驟

按照規范的設計方法，一個完整的資料庫設計一般分為以下六個階段：
⑴需求分析：分析用戶的需求，包括數據、功能和性能需求；
⑵概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；
⑶邏輯結構設計：通過將E-R圖轉換成表，實現從E-R模型到關系模型的轉換；
⑷資料庫物理設計：主要是為所設計的資料庫選擇合適的存儲結構和存取路徑；
⑸資料庫的實施：包括編程、測試和試運行；
⑹資料庫運行與維護：系統的運行與資料庫的日常維護。

C. 資料庫管理系統的實現

這么單純用語言給你解釋不明白，我用實例給你講一下吧

比如做個進銷存系統，java做前台，sqlserver做資料庫，用java連接sqlserver這個就不用說了，實現增刪改查這個你在頁面都能做到

假如6-8個實體
商品表，里邊包含商品id，商品名等等
供貨商表，里邊包含供貨商id，供貨商姓名及其他信息等
進貨表，商品id，供貨商id，供應數量，價錢，日期等等
出貨也類似
庫存就是進貨-出貨

這里庫存表的話就需要觸發器，你想，進來一批貨，這個就應該加到庫存里是吧，如果出貨了，庫存就應該相應的減少，存儲過程的話，比如你在頁面做個輸入參數的地方，比如輸入某供貨商名字，查他某幾個月之間的供貨數量，這個可能就需要用到存儲過程

至於報表，無非就是看統計一些什麼東西，象上邊說的，查詢所有供貨商2013年供貨的數量，然後做個餅圖，看一下每個供貨商占所有供貨商供貨的比例等等，或者某個供貨商，2013年每個月供貨的柱狀圖，這些都屬於圖形，不知道這么說你能簡單明白點不？

D. 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下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的概念模型。

設計概念結構通常有四類方法：

• 自頂向下。即首先定義全局概念結構的框架，再逐步細化。

• 自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。

• 逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。

• 混合策略。即自頂向下和自底向上相結合。

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


如果將這些數據畫成圖表，就像：



• 需要注意：


• ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。


• ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。


• ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。


• ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。


• ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。

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數據類型」。

E. .資料庫設計分為幾個階段,各階段的任務是什麼

按照規范的設計方法，一個完整的資料庫設計一般分為需求分析、概念結構設計、邏輯結構設計、資料庫物理設計、資料庫的實施、資料庫運行與維護六個階段：

各階段的任務如下：

1、需求分析：分析用戶的需求，包括數據、功能和性能需求；

拓展資料：

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求(信息要求和處理要求)。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就，而只能是一種"反復探尋，逐步求精"的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

F. 資料庫設計是指設計資料庫管理系統嗎

不是；前者是設計應用，後者是設計軟體怎麼開發。

資料庫設計(Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統。

使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。在資料庫領域內，常常把使用資料庫的各類系統統稱為資料庫應用系統。

資料庫管理系統(Database Management System)是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱DBMS。

它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。用戶通過DBMS訪問資料庫中的數據，資料庫管理員也通過dbms進行資料庫的維護工作。

它可使多個應用程序和用戶用不同的方法在同時或不同時刻去建立，修改和詢問資料庫。

大部分DBMS提供數據定義語言DDL（Data Definition Language）和數據操作語言DML（Data Manipulation Language）。

供用戶定義資料庫的模式結構與許可權約束，實現對數據的追加、刪除等操作。

(6)資料庫系統設計實現與管理擴展閱讀：

資料庫設計是建立資料庫及其應用系統的技術，是信息系統開發和建設中的核心技術。

由於資料庫應用系統的復雜性，為了支持相關程序運行，資料庫設計就變得異常復雜，因此最佳設計不可能一蹴而就。

而只能是一種「反復探尋，逐步求精」的過程，也就是規劃和結構化資料庫中的數據對象以及這些數據對象之間關系的過程。

需求分析：

調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。

需求分析是在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。

在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用數據流程圖(DFD)進行圖形化的描述。

概念設計：

對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中諸處的分類、聚集和概括，建立抽象的概念數據模型。

這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。

所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。

以擴充的實體—（E-R模型）聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等。

從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。

資料庫管理系統是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫，簡稱 DBMS。它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。

資料庫管理系統是一個能夠提供數據錄入、修改、查詢的數據操作軟體，具有數據定義、數據操作、數據存儲與管理、數據維護、通信等功能，且能夠允許多用戶使用。

另外，資料庫管理系統的發展與計算機技術發展密切相關。而且近年來，計算機網路逐漸成為人們生活的重要組成部分。

為此，若要進一步完善計算機資料庫管理系統，技術人員就應當不斷創新、改革計算機技術，並不斷拓寬計算機資料庫管理系統的應用范圍，從而真正促進計算機資料庫管理系統技術的革新。

技術特點：

（1）採用復雜的數據模型表示數據結構，數據冗餘小，易擴充，實現螞禪了數據共享。

（2）具有較高的數據和程序獨立性，資料庫的獨立性有物理獨立唯磨性和邏輯獨立性。

（3）資料庫系統為用戶提供了方便的用戶介面。

（4）資料庫系統提供4個方面的數指物斗據控制功能，分別是並發控制、恢復、完整性和安全性。

資料庫中各個應用程序所使用的數據由資料庫系統統一規定，按照一定的數據模型組織和建立，由系統統一管理和集中控制。

（5）增加了系統的靈活性。

參考資料來源：網路-資料庫設計

網路-資料庫管理系統

G. 具體的資料庫設計與實現過程

大致的講主要是根據用戶的需求，然後設計資料庫的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）及時改正運行中發現的系統錯誤。

H. 簡述資料庫應用系統的設計步驟

資料庫設計的基本步驟：

1、系統需求分析與設計。

2、概念結構分析與設計。

3、邏輯結構分析與設計。

4、物理結構分析與設計。

5、系統實施。

6、系統維護。

(8)資料庫系統設計實現與管理擴展閱讀：

資料庫設計技巧：

1、原始文件與實體的關系

它可以是一對一，一對多，多對多的關系。一般來說，它們是一對一的關系：一個原始文檔只對應於一個實體。在特殊情況下，它們可以是一對多或多對一關系，即一個原始文檔對應於多個實體，或者多個原始文檔對應於一個實體。

這里的實體可以理解為基本表。在對應關系明確後，對輸入介面的設計非常有利。

2、主鍵和外鍵

一般來說，實體不能既沒有主鍵也沒有外鍵。在E－R圖中，葉中的實體可以定義主鍵或不定義主鍵（因為它沒有子代），但它必須有外鍵（因為它有父項）。

主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國資料庫設計專家說：「鑰匙無處不在，只有鑰匙。」。這是他資料庫設計的經驗，也體現了他對信息系統核心（數據模型）高度抽象的理念。

因為：主鍵是一個高度抽象的實體。主鍵和外鍵的配對表示實體之間的連接。

3、基本表的屬性

基本表不同於中間表和臨時表，因為它具有以下四個特點：

原子性。基本表中的欄位不可分解。

原始主義。基本表中的記錄是原始數據（基本數據）的記錄。

演繹的。所有輸出數據都可以從基本表和代碼表中的數據導出。

穩定。基本表的結構比較穩定，表中的記錄要長期保存。

在了解基本表的性質之後，在設計資料庫時，可以將基本表與中間表和臨時表區分開來。

I. Oracle11g資料庫系統設計、開發、管理與應用的前 言

本書主要內容
本書共有19章，分4個部分，其中第1、2章屬於基礎篇，主要介紹資料庫設計方面的內容；第3～11章屬於開發篇，主要介紹Oracle資料庫的開發；第12～15章屬於管理篇，主要介紹Oracle 11g資料庫的管理；第16～19章屬於應用篇，主要介紹Oracle 11g資料庫應用系統的開發知識。各個章節的具體內容安排如下：
篇名 章 名 主 要 內 容
基礎篇 第1章 資料庫技術基礎 介紹了資料庫技術的基本概念、數據模型、E-R模型、資料庫的規范化和高級資料庫技術
第2章 進入Oracle世界 介紹了Oracle產品的發展變遷、Oracle 11g的新特性、體系結構、安裝過程、基本組件和Oracle服務的啟動、關閉
開發篇 第3章 SQL語言與PL/SQL 介紹了SQL和PL/SQL的基本知識，以及PL/SQL運算符、控制結構和常用函數
第4章 資料庫 介紹了資料庫和資料庫實例的基本知識、創建資料庫、修改資料庫、刪除資料庫和管理表空間的操作
第5章 數據表、約束和數據記錄 介紹了管理數據表、資料庫完整性的約束實現、數據記錄操作、管理序列、管理同義詞和管理評注等操作
第6章 數據查詢 介紹了查詢的基本語法、簡單查詢、連接查詢、子查詢和聯合查詢等操作
第7章 索引 介紹了索引的基本知識、管理索引和管理聚集等操作
第8章 視圖 介紹了視圖的基本知識、管理視圖和使用視圖等操作
第9章 存儲過程、函數和包 介紹了存儲過程的基本知識、管理存儲過程、嵌套存儲過程、管理函數和管理包等操作
第10章 觸發器 介紹了觸發器的基本知識、管理觸發器和使用觸發器的操作
第11章 游標、事務和鎖 介紹了游標的基礎知識和基本操作、事務和鎖的基本知識
續表
篇名 章 名 主 要 內 容
管理篇 第12章 Oracle 11g企業管理器 介紹了OEM的基本環境和使用OEM監視Oracle 11g環境、管理資料庫、管理部署和管理作業系統等操作
第13章 資料庫安全性 介紹了資料庫安全性基本知識、管理用戶、管理角色、授權和資料庫審計等操作
第14章 備份與恢復 介紹了資料庫備份、恢復、數據導入、導出等操作
第15章 Oracle配置和管理工具 介紹了Oracle 11g配置和管理工具概況、配置和管理網路服務、配置本地規則和安裝、配置客戶端等操作
應用篇 第16章 Java訪問Oracle資料庫 介紹了JDBC的基本結構、ODBC連接資料庫、JDBC連接資料庫和訪問資料庫等操作
第17章 .NET訪問Oracle資料庫 介紹了ADO.NET模型、綁定連接資料庫、ODBC連接資料庫、手動連接資料庫和調用存儲過程等操作
第18章 開發J2EE應用 介紹了J2EE開發和部署環境、開發JSP程序、開發Servlet和開發EJB等內容
第19章 Oracle XML DB 介紹了Oracle XML DB的基本體系結構、XML模式、二進制XML表和XQuery查詢等內容
本書特點
（1）本書內容根據資料庫開發的一般特點進行講解，內容通俗易懂。
（2）結合實際開發案例的大量例題，使讀者可以直觀感受Oracle 11g的內容。
（3）對每種Oracle技術均通過GUI方式和命令方式進行講解，既方便初學者快速入門，也方便對Oracle有一定了解的讀者更上一層樓。
本書既適合高職高專、本科院校或計算機培訓機構作為Oracle資料庫課程的教材或參考用書，也可以作為計算機愛好者和資料庫管理員的參考用書。
本書由來自湖南鐵道職業技術學院的希賽顧問團顧問馮向科（國家認證軟體設計師、系統分析師）和鄧瑩擔任主編。
由於作者水平有限，書中的錯誤和不妥之處在所難免，敬請讀者批評指正。有關本書的反饋和咨詢，讀者可以發送郵件至（請見擴展閱讀），也可以從（請見擴展閱讀）免費下載書中所用到的軟體、工具和源代碼。
編 者
2009年3月