資料庫設計與實現
『壹』 如何進行資料庫的設計
資料庫設計(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) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說,針對每一種最終表達數據的原型應用,保證你檢查了數據模型並且查看如何取出數據。
『貳』 資料庫設計代碼實現怎麼寫
用什麼語言?這個問抄的很奇怪襲
啊.。
你學的什麼語言嘛,自然就是那種語言了.!!!
一般的流程是這樣的;
我只說下大概的流程.。
首先,需求分析,分析一些業務.。
然後,根據一些業務,去設計資料庫.建資料庫表.。
,然後在根據資料庫中的欄位畫界面,。
寫代碼.。
最後測試階段。.
寫的不是很詳細。..。請見諒.
『叄』 資料庫酒店管理系統資料庫的設計與實現
我暈,這種東西你要是不花點錢是弄不到的,給你個地址,你自己去看,如果沒錢就照抄,有錢就下載下來自己改改用用,好像也不貴。http://www.docin.com/p-95667780.html http://www.docin.com/p-100672648.html
『肆』 建立與維護數據看系統的管理員和負責設計實現的系統分析員以及資料庫設計人員負責的內容有什麼差別
1、管理員不管資料庫的設計,他是通過一個已經設計好的界面進行數據維護。說難聽點,他可能連資料庫怎麼設計都不會,也不必會;
2、系統分析員就超厲害了,他是對大型、復雜的信息系統建設任務中,承擔分析、設計和領導實施的領軍人物。 要做好與客戶之間的關系,同時對客戶的需求要正確的理解,要選擇合適的開發技術,同時做好與客戶間溝通交流,學會說服對方。
3、你說的資料庫設計人員就是DBA,DBA的基本職責是:
安裝和升級資料庫伺服器(如Oracle、Microsoft SQL server),以及應用程序工具。
資料庫設計系統存儲方案,並制定未來的存儲需求計劃。
一旦開發人員設計了一個應用,就需要DBA來創建資料庫存儲結構(tablespaces)。
一旦開發人員設計了一個應用,就需要DBA來創建資料庫對象(tables,views,indexes)。
根據開發人員的反饋信息,必要的時候,修改資料庫的結構。
登記資料庫的用戶,維護資料庫的安全性。
保證資料庫的使用符合知識產權相關法規。
控制和監控用戶對資料庫的存取訪問。
監控和優化資料庫的性能。
制定資料庫備份計劃,災難出現時對資料庫信息進行恢復
維護適當介質上的存檔或者備份數據
備份和恢復資料庫
聯系資料庫系統的生產廠商,跟蹤技術信息 。
『伍』 求《資料庫系統設計,實現與管理》pdf
本書以豐富的示例,介紹了資料庫系統的基本原理、設計、實現以及管理,全書分為資料庫概念、資料庫設計概念、高級資料庫設計與實現、高級資料庫概念、資料庫與Internet等5部分共15章,是一本非常實用的資料庫系統教材。
『陸』 具體的資料庫設計與實現過程
大致的講主要是根據用戶的需求,然後設計資料庫的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)及時改正運行中發現的系統錯誤。
『柒』 資料庫設計與實現壓力圖怎麼設計
web應用和資料庫分開部署,WEB應用伺服器和資料庫伺服器各司其職,在系統訪問量增加的時候可以分別升級應用伺服器和資料庫伺服器,這種部署方式是一般小規模網站的典型部署方式。在將應用程序進行性能優化並且使用資料庫對象緩存策略的情況下,可以承載較大的訪問量,比如2000用戶,200個並發,百萬級別的數據量。
『捌』 關於《資料庫系統 設計、實現與管理(基礎篇)》的求助
第一頁看不清,但其實沒必要,資料庫單值屬性就是指基於某個業務場景時,一版個屬性只有一個值,比如一個學生的權年齡、性別,都是只有一個值的,多值就是一個屬性可以有多個值,比如學生的電話,可能有手機1 手機2 固話等,這類知識點理解下就行。
第二頁是候選關鍵字,上面是staffNo 員工編碼