MySQL數(shù)據(jù)庫應用與管理項目化教程課件:數(shù)據(jù)模型_第1頁
MySQL數(shù)據(jù)庫應用與管理項目化教程課件:數(shù)據(jù)模型_第2頁
MySQL數(shù)據(jù)庫應用與管理項目化教程課件:數(shù)據(jù)模型_第3頁
MySQL數(shù)據(jù)庫應用與管理項目化教程課件:數(shù)據(jù)模型_第4頁
MySQL數(shù)據(jù)庫應用與管理項目化教程課件:數(shù)據(jù)模型_第5頁
已閱讀5頁,還剩20頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

應用數(shù)據(jù)庫設計教學目標能力目標◎能針對數(shù)據(jù)庫設計項目,做好調(diào)研準備和有效采集調(diào)研數(shù)據(jù);◎能繪制業(yè)務流圖、數(shù)據(jù)流圖,分析數(shù)據(jù)并繪制簡單局部ER圖。知識目標◎熟悉需求分析的步驟和方法;◎掌握規(guī)范業(yè)務流圖、數(shù)據(jù)流圖、ER圖的繪制。學習重點◎熟悉需求分析方法步驟、調(diào)研準備和采集調(diào)研數(shù)據(jù)方法;◎掌握規(guī)范業(yè)務流圖、數(shù)據(jù)流圖、ER圖的繪制方法。學習難點◎需求分析和全局ER圖的繪制。任務任務1需求調(diào)研任務2需求分析任務3概念模型設計任務4邏輯結構設計數(shù)據(jù)庫設計流程圖?

數(shù)據(jù)庫設計流程任務四

數(shù)據(jù)模型設計任務說明概念模型是獨立于任何一種DBMS設計的,不能被任何一個具體的DBMS所支持。為適應具體的DBMS,需將概念模型轉化為某個具體的數(shù)據(jù)庫管理系統(tǒng)所支持的數(shù)據(jù)模型,即進行邏輯結構設計。本節(jié)將超市銷售管理系統(tǒng)的E-R模型轉換為當前流行的關系數(shù)據(jù)模型。教學目標掌握E-R圖到關系模式的轉換規(guī)則掌握關系數(shù)據(jù)庫規(guī)范化設計關系模式的轉換規(guī)則

(1)一個實體型轉換為一個關系模式,實體的屬性就是關系的屬性,實體的碼就是關系的關鍵字。(2)若實體間的聯(lián)系是1:1聯(lián)系,可在其中任一個實體的關系模式中加入另一個實體碼和聯(lián)系屬性。(3)若實體間的聯(lián)系是1:n聯(lián)系,則在n端實體類型轉換成的關系模式中,加入1端實體的主碼和聯(lián)系的屬性。(3)若實體間的聯(lián)系是m:n聯(lián)系,則將聯(lián)系也轉換成關系模式,其屬性為兩端實體類型的主碼加上聯(lián)系的屬性,該關系的主碼則為兩端實體主碼的組合。(4)3個以上實體的m:n聯(lián)系:則將聯(lián)系也轉換成關系模式,主碼為各實體的碼組成。(5)具有相同關鍵字的關系模式可以合并。例:關系模式的轉換舉例關系模式的轉換舉例(1)部門關系屬性為其自身的所有屬性:部門(部門編號,部門名稱、業(yè)務職責、電話)(2)員工關系除了其自身屬性外,根據(jù)1:n轉換規(guī)則,還應加入1端聯(lián)系的實本主碼:部門編號。員工(員工號,部門號,姓名,性別,身份證號,出生日期,入店日期,職業(yè),聯(lián)系電話,電子郵箱,住址,郵編)(3)銷售聯(lián)系與會員、員工、上架商品三個實體有關系,根據(jù)轉換規(guī)則,銷售除自身屬性外還應加入3個實體的主碼。銷售(銷售單號,商品號,件數(shù),時間,會員號,是否批發(fā),銷售時間,銷售員號)其他實體或聯(lián)系按轉換規(guī)則,用同樣方法轉換。關系數(shù)據(jù)庫規(guī)范化設計關系優(yōu)化檢查為了提高數(shù)據(jù)的存取效率,對設計出來的關系數(shù)據(jù)模式需要進一步進行優(yōu)化調(diào)整,通??梢圆捎藐P系規(guī)范化理論對數(shù)據(jù)關系進行檢查優(yōu)化。關系規(guī)范化的目的避免數(shù)據(jù)冗余。避免數(shù)據(jù)的不一致性避免刪除、插入的不規(guī)則。關系數(shù)據(jù)庫規(guī)范化設計例:在超市銷售管理中存在一個銷售關系它包含的屬性有銷售單號、銷售商品名、廠商、數(shù)量、售價、銷售日期、銷售員等,在這個關系中商品基本信息已經(jīng)包在里面,所以不再單獨設商品表,以銷售單號與為主碼。銷售單號商品編號商品名稱廠商售價數(shù)量銷售日期銷售員S0000102G0011快食面康師傅552009-08-12李映S0000103G0002礦泉水怡寶3.532009-08-12周強S0000108G0003礦泉水農(nóng)夫山泉452009-08-16張小軍S0000109G0011快食面康師傅3.5152009-09-12周強3.4關系數(shù)據(jù)庫的規(guī)范化問題1:哪些內(nèi)容是重復存儲了?(存在數(shù)據(jù)冗余)問題2:商品編號為G0002誤錄為G0003,在數(shù)據(jù)表中出現(xiàn)什么問題?(不小心輸入造成數(shù)據(jù)的不一致性)問題3:更新數(shù)據(jù)時,若將第4條記錄商品名修改了,將會怎樣?(造成G0011商品有多個名稱,造成數(shù)據(jù)不一致、更新異常)關系數(shù)據(jù)庫的規(guī)范化問題4:若插入一個商品信息,而該商品未銷售,按該關系能插入該商品信息嗎?(學生未選課就不能錄入學生信息,這是插入異常)問題5:若刪除所有商品銷售記錄,將會出現(xiàn)什么情況?(會把所有商品信息和銷售信息也都刪除了,這是刪除異常)。出現(xiàn)這些現(xiàn)象的原因是什么?關系的屬性間存在數(shù)據(jù)依賴,其中最重要的是函數(shù)依賴。函數(shù)依賴定義1:設R(U)是屬性集U上的關系模式,X,Y是U的子集。若對于R(U)的任意一個可能的關系r,r中不可能存在兩個元組在X上的屬性值相等,而在Y上的屬性值不等,則稱X函數(shù)確定Y或Y函數(shù)依賴于X,記作X->Y。例:在商品信息中,商品號唯一,則:不存在商品號相同,而商品名稱不同的商品元組(即在此關系中,不會出現(xiàn)商品號:商品名為1:n),我們說:商品號->商品名稱。函數(shù)依賴完全函數(shù)依賴設X->Y是一個函數(shù)依賴,并且對于任何X中的元素X’,X’->Y都不成立,則稱X->Y是一個完全函數(shù)依賴,即Y函數(shù)依賴于整個X。例:若銷售單為(銷售單號,商品編號,售價,數(shù)量,銷售日期,銷售員)關系中,(銷售單號,商品編號)為主碼,因銷售價因進貨價的不同、促銷的時間不同而有所不同,所以(銷售單號,商品編號)->售價是一個完全函數(shù)依賴。函數(shù)依賴部分函數(shù)依賴設X->Y是一個函數(shù)依賴,但不是完全函數(shù)依賴,則稱X->Y是一個部分函數(shù)依賴,即Y函數(shù)依賴于X的某個真子集。例:在銷售單(銷售單號,商品編號,商品名稱,廠商,售價,數(shù)量,銷售日期,銷售員)中,主碼為(銷售單號,商品編號),因有商品編號->商品名稱,所以(銷售單號,商品編號)->商品名稱是一個部分函數(shù)依賴。函數(shù)依賴4)傳遞函數(shù)依賴:設R(U)是一個關系模式,X,Y,Z是了集,如果X->Y,Y->Z成立,則稱Z傳遞函數(shù)依賴于X。例:銷售部編號->銷售部名稱銷售部名稱->銷售部經(jīng)理銷售部編號->銷售部經(jīng)理關系數(shù)據(jù)庫的規(guī)范化2、關系數(shù)據(jù)庫的規(guī)范化規(guī)則第1范式(1NF):關系每一個屬性的值域只包含原子項,即不可分割的數(shù)據(jù)項,無重復的屬性.第2范式(2NF):符合1NF,且非主屬性不部分依賴于主碼(即非主屬性完全依賴于主碼)即:每個非主屬性是由整個主鍵函數(shù)決定的,而不能由主鍵的部分碼來決定。

關系數(shù)據(jù)庫的規(guī)范化在銷售單(銷售單號,商品編號,商品名稱,廠商,售價,數(shù)量,銷售日期,銷售員)關系中,主碼為(銷售單號,商品編號),因有商品編號->商品名稱,所以(銷售單號,商品編號)->商品名稱是一個部分函數(shù)依賴。所以該關系不符合2NF.關系數(shù)據(jù)庫的規(guī)范化第3范式(3NF):符合2NF,且每個非主屬性都不傳遞函數(shù)依賴于主碼(即:屬性不依賴于非主屬性)。BC范式(BCNF):R中所有非主屬性對每一個碼都是完全函數(shù)依賴.R中所有主屬性性每一個不包含它的碼也是完全函數(shù)依賴R中沒有任何屬性完全函數(shù)依賴于非碼的任何一組屬性.關系數(shù)據(jù)庫的規(guī)范化3、關系模式的分解:無損分解:是對關系模式分解時,原關系模式下任一合法的關系值在分解之后應能通過自然連接運算恢復起來。定義:設p={R1,R2,…,Rk}是關系模式R<U,F>的一個分解,如果對于R的任一滿足F的關系r都有:

r=∏R1(r)∏R2(r)….∏Rk(r)則這個分解P是函數(shù)依賴集F的無損分解。

關系數(shù)據(jù)庫的規(guī)范化例如:將銷售單(銷售單號,商品編號,商品名稱,廠商,售價,數(shù)量,銷售日期,銷售員)可無損分解以下兩個關系,這兩個關系通過商品編號自然連接就可恢復原來關系。商品信息(商品編號,商品名稱,廠商),銷售單(銷售單號,商品編號,售價,數(shù)量,銷售日期,銷售員)關系數(shù)據(jù)庫的規(guī)范化4、關系數(shù)據(jù)庫的反規(guī)范化我們盡量要求規(guī)范化設計,但也不是一味追求高規(guī)范化,因為符合的范式越高,分出來的表就越細,可能會引起資源的浪費和造成多表聯(lián)系的復雜度越高.若關系表數(shù)據(jù)更新頻繁的,盡量要求規(guī)范化設計。關系表主要用來檢索查詢用,規(guī)范化要求可降低。關系數(shù)據(jù)庫的規(guī)范化例:在關系銷售(銷售單號,商品號,件數(shù),時間,會員號,是否批發(fā),銷售時間,銷售員號)中。根據(jù)銷售記錄主要用來查詢分析,很少有再修改,在設計時降低規(guī)范化,加入了下面

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論