數據庫系統設計數據完整性第1頁，課件共26頁，創作于2023年2月

本講參考書目：

1[美]

Rob,P.Coonel,C.

數據庫系統設計、實現與管理（第5版）.陳立軍等譯.電子工業出版社，2004.32[美]

Ramakrishnan,R.Gehrke,J.

數據庫管理系統原理與設計（第3版）.周立柱等譯.北京：清華大學出版社，2004.3第2頁，課件共26頁，創作于2023年2月

1關系數據庫設計概述

DBMS

從產生直至發展到現在,出現了多種類型.按其數據模型來分，主要有層次數據庫、網狀數據庫和關系數據庫.前兩者在六七十年代較為流行，然而他們表示數據之間的聯系太過于復雜，現在已經很少使用，只是在講解數據庫的時候才有所提及.

關系數據庫以關系的數學理論為基礎，是數據庫技術的一項重大突破.

一、

關系數據庫設計要點

第3頁，課件共26頁，創作于2023年2月關系數據庫簡單嚴謹，二十多年來有了長足發展，現在已經成為事實上的標準，當今幾乎所有的數據庫產品都是基于關系數據庫的.

數據庫設計是數據庫應用的一個關鍵因素,設計結構合理、功能齊全的數據庫對于提高數據庫應用程序的開發效率和程序的性能都是非常重要的.

數據庫設計是指對于一個給定的應用環境,構造最優的數據模式，建立數據庫，使其能夠有效地存儲數據記錄，并能滿足各種應用需求.第4頁，課件共26頁，創作于2023年2月對于一個數據密集型應用來說，數據庫設計是它的一個核心部分，但對于大型的軟件系統設計來說,它只是其中一個部分.

數據庫設計的過程可以分為6

步.(1)需求分析

(2)概念數據庫設計

(3)邏輯數據庫設計

(4)模式的細化

(5)物理數據庫設計

(6)應用與安全設計第5頁，課件共26頁，創作于2023年2月

2規劃關系數據庫

進行數據庫規劃是所有數據庫編程的第一步,也是最重要的一步.

首先，列出客戶所關心的所有數據和建立這個數據庫的主要目的.這可以通過收集各種相關的數據報表和表格來完成.需求分析是數據庫設計的第一階段，不斷的調查與研究，了解組織機構的情況，了解部門的業務流程等系統需求，對于設計好數據庫是非常重要的.

然后，數據表規劃是整個數據庫設計中技巧性最強的一個步驟.數據表要滿足第三范式.第6頁，課件共26頁，創作于2023年2月

規劃數據庫有以下三條基本原則：

●數據庫中的記錄個數應該反映現實世界對象的個數.如果一個對象的實例在現實世界中存在，則在數據庫中有且只有一條記錄存在.

●每行記錄的字段應該表達現實世界對象的屬性.

●現實世界對象之間的關系應該反映在數據庫記錄之間的關系上.第7頁，課件共26頁，創作于2023年2月

3設計數據完整性概述

關系數據庫的目的是建立現實世界的模型.基于這一點,用來實施數據完整性的規則和方法無論對于理論和數據庫開發的實踐都很重要.

數據完整性是指存儲在數據庫中的數據的正確性和相容性.

設計數據完整性的目的是為了防止數據庫中存在不符合語義的數據,防止錯誤信息的輸入和輸出.第8頁，課件共26頁，創作于2023年2月數據完整性可以分為四類：●實體完整性每個實體都保持惟一性.

●值域完整性如何限制向表中輸入值的范圍.●引用完整性(參照完整性)

處理數據時維護表之間數據的一致性.●用戶定義的完整性

體現實際運用的業務規則.第9頁，課件共26頁，創作于2023年2月●實體完整性

每一個實體都必須擁有一個主鍵或者其他的惟一標識列.

要求：所有的主鍵項都是唯一的，并且主鍵的任何部分都不能為空.

目的：保證每個實體有惟一的標識，確保外鍵值可以正確地引用主鍵值.

例子：發貨單沒有重復的號碼，號碼也不能為空.●參照完整性

要求：外鍵可能是空---只要它不是它自己所在的表的主鍵的一部分---每個非null外鍵值必須參照已經存在的主鍵值.

目的：不能有無效的項.

例子：客戶可以沒有給定的代理商號碼，但是不能有無效的代理商號碼.第10頁，課件共26頁，創作于2023年2月

SQLServer提供的用來實施數據完整性的途徑主要是:

約束(

constraint)

標識列(identitycolumn)

默認值(default)

規則(rule)

觸發器(trigger)

數據類型(datatype)

索引(index)

存儲過程(storedprocedure)第11頁，課件共26頁，創作于2023年2月

●約束完整性約束完整性是指數據的正確性和完備性.在用INSERT、DELETE、UPDATE

語句修改數據庫內容時，數據的完整性可能會遭到破壞，有如下幾種情況：

---無效的數據被添加到數據庫中，如某訂單所指的產品不存在.---對數據庫的修改不一致，如為某產品增加了訂單，但卻沒有調整產品的庫存信息.---將存在的數據修改為無效的數據.第12頁，課件共26頁，創作于2023年2月在SQLServer

中實現數據完整性的方法之一就是約束.使用這種方法簡單且不容易出錯，它把完整性的要求定義在表和列上.

所謂約束，是SQLServer

強制實行的應用規則，它能夠限制用戶存放到表中的數據的格式和范圍.

約束是在CREATETABLE、ALTERTABLE語句中，通過CONSTRAINT

和DEFAULT實現.第13頁，課件共26頁，創作于2023年2月

1概論好的數據庫設計需要好的表結構.本節我們將學習如何評價和設計好的數據庫表，控制數據冗余，從而避免數據異常，這就是規范化.

為了識別和鑒賞好的表結構的特性，考察一個不好的表結構是很有用的.利用這種方法，我們將學會如何設計好的表結構，如何修改已有的不好的表結構.二、數據庫表的規范化第14頁，課件共26頁，創作于2023年2月通過規范化不僅可以消除數據異常，而且適當規范化的表結構實際上要比沒有規范化的來得簡單，它還能反映出一個組織的實際運行情況.

擁有好的關系數據庫軟件，并不足以避免數據冗余.即使在一個好的數據庫設計中,也有可能生成不好的表結構.

第15頁，課件共26頁，創作于2023年2月那么，如何識別不好的表結構，如何創建好的表結構呢？兩個問題的答案都是基于規范化的.規范化是給實體分配屬性的過程.它能夠減少但不能夠消除數據冗余；相反，它通過生成有控制的冗余來連接數據庫表.第16頁，課件共26頁，創作于2023年2月規范化通過一系列稱為范式的階段來完成.最前面的三個階段分別叫做第一范式(1NF)、第二范式(2NF)和第三范式(3NF).

從結構化的觀點來看，2NF比1NF好，3NF比2NF好.對于大多數的事物數據庫設計，我們只要能規范到3NF就已經足夠了.

雖然規范化是數據庫設計的一個重要組成部分，但是并不是規范化級別越高越好.通常,范式級別越高，產生制定輸出所要求的連接就越多，系統對終端用戶請求的響應就越慢.第17頁，課件共26頁，創作于2023年2月我們考察某建筑公司的一個簡單數據庫行為.該公司管理幾個建筑項目，每個項目都有它自己的項目號、項目名、員工等屬性，每個員工有員工號、姓名和職位級別等屬性.

公司根據每個合同需要花費的小時數來向客戶收費.每小時的報酬由員工的職位決定.

該應用周期性地生成信息報表.由這個報表對應地生成一個表.2

規范化的必要性第18頁，課件共26頁，創作于2023年2月這個表的結構不符合完整性的要求，它也沒有很好的處理數據.①項目號（PROJ_NUM）很明顯是希望作為一個主碼，或者至少是主碼的一部分，但是它包含空值.②表的數據輸入引起數據的不一致.如，Elect.Engineer可能寫成Elect.Eng,El.Eng,EE.

③該表中有數據冗余，會產生異常：更新異常:如修改105號的JOB_CLASS.

插入異常，刪除異常.

當把某員工分配到某項目時,重復輸入數據.第19頁，課件共26頁，創作于2023年2月

●

消除組重復在作為主碼的列中加入合適的項即可.●

主碼應能恰當地、惟一地確定任何屬性值取主碼為PROJ_NUM

和EMP_NUM

的組合.

這樣得到了符合第一范式的表.

3到第一范式的轉換第20頁，課件共26頁，創作于2023年2月PROJ_NUM

PROJ_NAME

EMP_NUMEMP_NAMEJOB_CLASSCHG_HOUR

HOUR部分依賴部分依賴傳遞依賴第21頁，課件共26頁，創作于2023年2月術語1NF描述了如下的表格式：

●

定義了所有的碼屬性.●

表中沒有重復組.●

所有的屬性都依賴于主碼.

所有的關系表都屬于1NF.上圖所示的第一范式的表結構的問題是它包含部分依賴,

也就是說，基于部分主碼的依賴.

雖然有時為了提高性能需要使用部分依賴,但要謹慎使用.因為這樣的表仍有數據冗余(由每行記錄都要求有數據副本而產生),重復輸入使效率很低，也會助長數據異常的產生.

第22頁，課件共26頁，創作于2023年2月一個表屬于第二范式是指：●

它屬于1NF.●

它不包含部分依賴，即，沒有屬性只依賴于主碼的一部分.

到第二范式的轉換是，將原表分為三個表:

PROJCT(PROJ_NUM,PROJ_NAME)EMPLOYEE(EMP_NUM,EMP_NAME,JOB_CLASS,CHG_HOUR)

ASSIGN(PROJ_NUM,EMP_NUM,ASSIGN_HOUR)4到第二范式的轉換