關系數(shù)據(jù)庫設計_第1頁
關系數(shù)據(jù)庫設計_第2頁
關系數(shù)據(jù)庫設計_第3頁
關系數(shù)據(jù)庫設計_第4頁
關系數(shù)據(jù)庫設計_第5頁
已閱讀5頁,還剩52頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

關系數(shù)據(jù)庫設計第一頁,共五十七頁,2022年,8月28日人們在總結信息資源開發(fā)、管理和服務的各種手段時,認為最有效的是數(shù)據(jù)庫技術(DBT)。DBT的應用已越來越廣泛,從小型的單項事務處理系統(tǒng)到大型的IS大都采用先進的DBT來保持系統(tǒng)數(shù)據(jù)的整體性、完整性和共享性。目前,一個國家的DB建設規(guī)模(指DB的個數(shù)、種類)、DB信息量的大小和使用頻度已成為衡量這個國家信息化程度的重要標志之一。第二頁,共五十七頁,2022年,8月28日

DB設計是研制DB及其應用系統(tǒng)的技術,是DB在應用領域中主要的研究課題。

DB設計是指:對于一個給定的應用環(huán)境,構造最優(yōu)的DB模式,建立DB及其應用系統(tǒng),使之能有效地存儲數(shù)據(jù),滿足各種用戶的應用需求(信息和處理要求)。

DB設計通常是在一個通用的DBMS支持下進行的,即利用現(xiàn)成的DBMS為基礎構建。在DB領域內,常把使用DB的各類系統(tǒng)統(tǒng)稱為“數(shù)據(jù)庫應用系統(tǒng)(DBAS)”。第三頁,共五十七頁,2022年,8月28日按規(guī)范設計的方法,可將DB設計分為六個階段:5.1.1需求分析階段5.1.2概念模型設計階段5.1.3邏輯模型設計階段5.1.4數(shù)據(jù)庫物理設計階段5.1.5數(shù)據(jù)庫實施階段5.1.6數(shù)據(jù)庫運行和維護階段5.1數(shù)據(jù)庫設計的基本步驟第四頁,共五十七頁,2022年,8月28日不滿意不滿意概念設計階段邏輯設計階段物理設計階段數(shù)據(jù)庫實施階段數(shù)據(jù)庫運行、維護階段應用要求、DBMS詳細特征應用需求(數(shù)據(jù)、處理)轉換規(guī)則、DBMS功能、優(yōu)化方法需求收集和分析設計概念結構設計邏輯結構數(shù)據(jù)模型優(yōu)化設計物理結構評價設計,性能預測物理實現(xiàn)試驗性運行使用、維護數(shù)據(jù)庫需求分析階段圖5.1數(shù)據(jù)庫設計步驟第五頁,共五十七頁,2022年,8月28日說明:(1)這個設計步驟是從DBAS設計和開發(fā)的全過程來考察DB設計的問題,因此,它既是DB也是DBAS的設計過程。(2)在設計過程中努力將DB設計和IS其它成分(模塊結構設計、代碼設計、處理流程設計等)的設計緊密結合,把數(shù)據(jù)和業(yè)務處理的需求收集、分析、抽象、設計、實現(xiàn)在各個階段同時進行、相互參照、相互補充,以完善兩方面的設計。第六頁,共五十七頁,2022年,8月28日

進行數(shù)據(jù)庫設計首先必須準確了解與分析用戶需求,包括數(shù)據(jù)與處理需求。需求分析是整個設計過程的基礎,是最困難、最耗時的一步。作為“地基”的需求分析是否做得充分與準確,決定了在其上構建“數(shù)據(jù)庫大廈”的速度與質量。需求分析做得不好,可能會導致整個數(shù)據(jù)庫重新設計。5.1.1需求分析階段第七頁,共五十七頁,2022年,8月28日該階段收集到的基礎數(shù)據(jù)和一組數(shù)據(jù)流圖(DataFlowDiagram,簡寫為DFD),是下一步設計概念結構的基礎。從DB設計的角度考慮,需求分析的目標是:對現(xiàn)實世界要處理的對象(組織、部門、企業(yè)等)進行詳細調查,在了解原系統(tǒng)的概況、確定新系統(tǒng)功能的過程中,收集支持系統(tǒng)目標的基礎數(shù)據(jù)及其處理。調查的重點是“數(shù)據(jù)”和“處理”,具體做法:1.了解組織結構情況。調查該組織由哪些部門組成,各部門的職責是什么,為分析信息流程作準備。第八頁,共五十七頁,2022年,8月28日2.了解各部門的業(yè)務活動情況。調查各部門輸入和使用什么數(shù)據(jù)、如何加工處理這些數(shù)據(jù)、輸出什么信息、輸出到什么部門、輸出結果的格式是什么等。3.確定新系統(tǒng)的邊界。確定哪些功能由計算機完成或將來準備讓計算機完成,哪些活動由人工完成。由計算機完成的功能就是新系統(tǒng)應該實現(xiàn)的功能。第九頁,共五十七頁,2022年,8月28日

在概念設計階段,設計人員僅從用戶角度看待數(shù)據(jù)及其處理要求和約束,產(chǎn)生一個反映用戶觀點的概念模型,也稱為“組織模式”。概念結構獨立于數(shù)據(jù)庫邏輯結構,獨立于支持DB的DBMS,其特點:(1)能充分反映現(xiàn)實世界,包括實體及實體間的聯(lián)系,能滿足用戶對數(shù)據(jù)處理的要求,是現(xiàn)實世界的一個真實模型;(2)易于理解,從而可以和不熟悉計算機技術的用戶交換意見;(3)易于更動,當現(xiàn)實世界改變時容易修改和擴充;(4)易于向關系模型轉換。描述概念模型的有力工具是E-R模型。5.1.2概念模型設計階段第十頁,共五十七頁,2022年,8月28日

邏輯模型設計階段的任務是將概念模型設計階段得到的基本E-R圖,轉換為與選用的DBMS產(chǎn)品所支持的數(shù)據(jù)模型相符合的邏輯結構。此設計過程分三步進行,如下圖所示:5.1.3邏輯模型設計階段概念結構(基本E-R圖)一般數(shù)據(jù)模型(關系模型)優(yōu)化的DM特定的DBMS支持下的數(shù)據(jù)模型轉換規(guī)則DBMS的特點和限制優(yōu)化方法第十一頁,共五十七頁,2022年,8月28日分析:(1)首先將概念結構向一般的關系模型轉換;(2)然后向特定的DBMS支持下的數(shù)據(jù)模型轉換;(3)最后進行模型的優(yōu)化。第十二頁,共五十七頁,2022年,8月28日對于一個給定的邏輯模型選取一個最適合應用環(huán)境的物理結構的過程,稱為DB物理設計。

DB的物理結構:主要指數(shù)據(jù)庫在物理設備上的存儲結構和存取方法,它完全依賴于給定的計算機系統(tǒng)。物理設計的內容包括:(1)確定數(shù)據(jù)的存儲結構。從DBMS所提供的存儲結構中選取合適的加以實現(xiàn)。目前使用的基本上均為關系型DBMS,所有數(shù)據(jù)均以“DBF”為存儲結構—即一個關系(若干記錄)存儲為一個文件。5.1.4數(shù)據(jù)庫物理設計階段第十三頁,共五十七頁,2022年,8月28日確定存儲結構應考慮三個因素:存取時間、存儲空間利用率、維護代價。有時幾個因素之間會產(chǎn)生矛盾,設計者應根據(jù)實際情況對這些因素進行權衡。(2)存取路徑的選擇和調整。DB必須支持多個用戶的多種應用,因而必須提供對DB的多個存取入口,即對同一數(shù)據(jù)存儲要提供多條存取路徑。(例,有時必須同時提供主存取路徑及輔存取路徑,前者用于主鍵檢索,后者用于輔助鍵-非主鍵檢索。)(3)確定數(shù)據(jù)存放位置。一般應將數(shù)據(jù)的易變部分和穩(wěn)定部分分開、經(jīng)常存取和不經(jīng)常存取部分分開存放。經(jīng)常存取或存取時間要求高的記錄應“聚簇(cluster)”在一起,存于高速存儲設備上(如硬盤),存取頻率小或存取時間要求低的存于低速存儲設備上(如軟盤、光盤等)。第十四頁,共五十七頁,2022年,8月28日

根據(jù)邏輯設計和物理設計的結果,在計算機系統(tǒng)上建立起實際數(shù)據(jù)庫結構、裝入數(shù)據(jù)、測試和試運行的過程稱為數(shù)據(jù)庫的實施階段。(相應與管理信息系統(tǒng)設計的編碼、調試階段。)實施階段主要有三項工作。(1)建立實際數(shù)據(jù)庫結構。對描述邏輯設計和物理設計結果的程序即“源模式”,經(jīng)DBMS編譯成目標模式并執(zhí)行后,便建立了實際的數(shù)據(jù)庫結構。(2)裝入試驗數(shù)據(jù)對應用程序進行調試。試驗數(shù)據(jù)可以是實際數(shù)據(jù),也可由手工生成或用隨機數(shù)發(fā)生器生成。應使測試數(shù)據(jù)盡可能覆蓋現(xiàn)實世界的各種情況。(3)裝入實際數(shù)據(jù),進入試運行狀態(tài)。測量系統(tǒng)的性能指標,是否符合設計目標。如果不符,則返回到前面,修改數(shù)據(jù)庫的物理模型設計甚至邏輯模型設計。5.1.5數(shù)據(jù)庫實施階段第十五頁,共五十七頁,2022年,8月28日

數(shù)據(jù)庫系統(tǒng)正式運行,標志著數(shù)據(jù)庫設計與應用開發(fā)工作的結束和維護階段的開始。運行維護階段的主要任務有三項:(1)維護數(shù)據(jù)庫的安全性與完整性:檢查系統(tǒng)安全性是否受到侵犯,及時調整授權和密碼,實施系統(tǒng)轉儲與備份,發(fā)生故障后及時恢復。(2)監(jiān)測并改善數(shù)據(jù)庫運行性能:對數(shù)據(jù)庫的存儲空間狀況及響應時間進行分析評價,結合用戶反應確定改進措施。(3)根據(jù)用戶要求對數(shù)據(jù)庫現(xiàn)有功能進行擴充。5.1.6數(shù)據(jù)庫運行和維護階段第十六頁,共五十七頁,2022年,8月28日

目前使用的RDB設計方法均稱為“規(guī)范設計法”,主要有:新奧爾良法、的五階段法、基于E-R模型的數(shù)據(jù)庫設計方法、基于3NF的設計方法、用戶視圖法等。本節(jié)主要介紹:5.2.1基于E-R模型的數(shù)據(jù)庫設計方法5.2.2用戶視圖法5.2關系數(shù)據(jù)庫設計方法第十七頁,共五十七頁,2022年,8月28日

E-R模型主要支持概念設計,是對現(xiàn)實世界的一種抽象。所謂抽象:是對實際的人、物、事和概念的人為處理;它抽取人們關心的共同特性,忽略非本質的細節(jié),并把這些特性用各種概念精確地加以描述。這些概念組成了某種模型。1.E-R模型的設計步驟

(1)設計局部E-R模式;(2)將各個局部E-R模式,綜合成全局E-R模式;(3)全局E-R模式的優(yōu)化。5.2.1基于E-R模型的數(shù)據(jù)庫設計方法第十八頁,共五十七頁,2022年,8月28日

設計局部E-R模式,其實質是將大系統(tǒng)進行分解,使其成為邏輯功能相對獨立的一些局部問題。先分別對每個局部模式進行設計,建立各局部的E-R模式,然后以各局部的E-R模式為基礎進行集成。設計E-R模式可以采用三種不同的次序進行設計:

①自頂向下:首先從抽象級別高、普遍性強的類開始,然后逐步細分。例如:物資管理中,物資是最高級別的抽象,它可分為五金類、燃料類、鋼材類、勞保類等。

(1)設計局部E-R模式第十九頁,共五十七頁,2022年,8月28日②由底向上:首先從具體對象開始,逐步抽象形成類。以物資為例,先查看倉庫有哪些物資,再分析每種具體的物資屬于哪個門類。③由內向外:首先從最中心的對象開始,逐步擴展到與它相關的其他對象。以物資管理為例,先從最中心的管理對象“物資”開始,逐步擴展到存放物資的倉庫,倉庫的管理者,物資的使用者,物資的采購入庫,庫存情況等。第二十頁,共五十七頁,2022年,8月28日應注意區(qū)分實體與屬性:在實體與屬性間并不存在形式上可以截然劃分的界限,而是根據(jù)需要選定并進行區(qū)分的,也即實體與屬性是相對的,常常是現(xiàn)實世界(人為主觀)對它們已有了大體的自然劃分:實體是E-R模式中的基本單位,是若干屬性有意義的聚合。例1,物資??稍O一個屬性為物資類別,則五金類、燃料類、鋼材類、勞保類均為屬性值,而不按實體設計;如果每種類別的物資需進行不同的描述,則應將其作為實體。例2,簡歷。在學生信息表中可設簡歷為一個屬性,而不按實體設計;如果每個學生的簡歷進行詳細的描述,則應將其作為實體。第二十一頁,共五十七頁,2022年,8月28日實體、屬性劃分準則:①作為“屬性”,不能再具有需要描述的性質(即屬性不可再細分);②“屬性”不能與其它實體具有聯(lián)系,即E-R圖中的聯(lián)系是實體之間的聯(lián)系而不是屬性之間的聯(lián)系??傇瓌t:能夠作為屬性的,盡量作為屬性對待,目的在于簡化E-R圖的處置。第二十二頁,共五十七頁,2022年,8月28日例,銷售管理子系統(tǒng)局部E-R圖設計。開發(fā)小組的成員經(jīng)過調查研究、信息流程分析和數(shù)據(jù)收集,明確該子系統(tǒng)主要功能:(1)接收定單:處理客戶和銷售員送來的定單;(2)處理定單:工廠根據(jù)定單安排生產(chǎn);(3)交貨同時開發(fā)票;(4)支付過帳:收到客戶付款后,根據(jù)發(fā)票存根和客戶信貸情況進行應收款處理。第二十三頁,共五十七頁,2022年,8月28日對應的局部E-R圖為:注:一個客戶對應每一份定單有一筆應收帳,所以,當一個客戶有多份定單就有多筆應收帳。客戶定單應收帳產(chǎn)品訂貨排產(chǎn)支付11NMNN第二十四頁,共五十七頁,2022年,8月28日實體及其屬性定義:(1)客戶(客戶號,客戶名,地址,電話,信譽狀況,帳號,帳戶余額,…)(2)應收帳款(客戶號,定單號,發(fā)票號,應收金額,支付日期,支付金額,…)(3)產(chǎn)品(產(chǎn)品號,產(chǎn)品名,規(guī)格,單價,…

)(4)定單(定單號,若干定單頭信息,定單細則,…

)。

第二十五頁,共五十七頁,2022年,8月28日按照“實體、屬性劃分原則”,“定單細則”不應該作為定單的屬性處理,而上升為實體。一張定單可以定購若干種產(chǎn)品,所以定單與定單細則兩個實體之間為1:N的聯(lián)系。定單可拆分為兩個實體來描述:①定單(定單號,客戶號,定貨項數(shù),定貨日期,交貨日期,…)②定單細則(定單號,細則號,產(chǎn)品號,定貨數(shù)量,單價,…

)第二十六頁,共五十七頁,2022年,8月28日則局部E-R圖應修改為:注:一份定單中可能定購了多種產(chǎn)品,但一個定單細則中只包含一種產(chǎn)品的信息。排產(chǎn)支付1N客戶定單應收帳產(chǎn)品訂貨1NN1定單細則組成1N第二十七頁,共五十七頁,2022年,8月28日

(2)將各個局部E-R模式,綜合成全局E-R模式①視圖集成方式有兩種:

·

多個局部E-R圖一次性集成;

·

逐步集成:用累加的方式一次集成兩個局部E-R圖。②每次集成的步驟:

·

合并,解決各局部E-R圖之間的沖突問題,生成初步E-R圖;

·

修改和重構,消除不必要的冗余,生成基本E-R圖。第二十八頁,共五十七頁,2022年,8月28日合并過程主要解決各E-R圖之間的沖突,其沖突主要有三類:屬性沖突、命名沖突和結構沖突。

①屬性沖突:即屬性值的類型、取值范圍或取值集合不同。例如:有的E-R圖中將日期作為日期型,有的定義為字符型。屬性沖突問題可通過統(tǒng)一規(guī)范的工程化管理來解決。②命名沖突:不同意義的對象在不同的局部應用中具有相同的名字(同名異義),或同一意義的對象在不同的局部應用中具有不同的名字(異名同義)。③結構沖突:同一對象在不同應用中具有不同的抽象。在某一局部應用中被當作實體,而在另一局部應用中則當作屬性;或同一實體在不同局部E-R圖中所包含的屬性個數(shù)不同。造成此問題的原因是各局部應用所關心的側重點不同,解決的辦法是取各分E-R圖中實體屬性的并集。第二十九頁,共五十七頁,2022年,8月28日(3)全局E-R模式的優(yōu)化

三原則:(1)進行相關實體類型的合并,以減少實體類型的個數(shù);(2)盡可能消除實體中的冗余屬性;(3)盡可能消除冗余的聯(lián)系類型。

第三十頁,共五十七頁,2022年,8月28日

E-R圖向關系模型轉換,要解決的問題是如何將實體和實體間的聯(lián)系轉換為關系模式,以及如何確定這些關系模式的屬性和碼。關系模型的邏輯結構是一組關系模式的集合。E-R圖則由實體、實體的屬性和實體之間的聯(lián)系三個要素組成。所以將E-R圖轉換為關系模型實際上就是將實體、實體的屬性和實體之間的聯(lián)系轉換為關系模式,這種轉換一般遵循如下原則:

(1)一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性,實體的碼就是關系的碼。

2.E-R圖向關系模型的轉換第三十一頁,共五十七頁,2022年,8月28日

(2)一個1:1聯(lián)系可以轉換為一個獨立的關系模式,也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式,則與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性均轉換為關系的屬性,每個實體的碼均是該關系的候選碼。如果與某一端實體對應的關系模式合并,則需要在該關系模式的屬性中加入另一個關系模式的碼和聯(lián)系本身的屬性。

(3)一個1:N聯(lián)系可以轉換為一個獨立的關系模式,也可以與N端對應的關系模式合并。如果轉換為一個獨立的關系模式,則與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性均轉換為關系的屬性,而關系的碼為N端實體的碼。如果與N端實體對應的關系模式合并,則需要在該關系模式的屬性中加入1端關系模式的碼和聯(lián)系本身的屬性。第三十二頁,共五十七頁,2022年,8月28日(4)一個M:N聯(lián)系轉換為一個關系模式,與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性均轉換為關系的屬性,而關系的碼為各實體碼的組合。(5)具有相同碼的關系模式可合并。形成了一般的數(shù)據(jù)模型后,下一步就是向特定的RDBMS的模型轉換。設計人員必須熟悉所用RDBMS的功能與限制。這一步是依賴于機器的,不能給出一個普遍的規(guī)則,但對于關系模型來說,這種轉換通常都比較簡單,不會有太多的困難。第三十三頁,共五十七頁,2022年,8月28日例,根據(jù)調查、分析構建了如下E-R圖,要求將之轉換為一組對應的關系模式。其對應的一組關系為:(1)實體轉換結果:領導M供應商供應物資項目NP參加部門屬于職工MN1N11天數(shù)供應量第三十四頁,共五十七頁,2022年,8月28日①供應商(供應商編號,供應商名稱,電話,帳號…)②物資(物資編號,物資名稱,型號規(guī)格,計量單位,價格…)③項目(項目編號,預算,開工日期,預計完成時間…)④職工(職工編號,姓名,出生日期,職稱…)⑤部門(部門編號,部門名稱…)第三十五頁,共五十七頁,2022年,8月28日(2)聯(lián)系轉換結果:①供應(供應商編號,項目編號,物資編號,供應量)②參加(職工編號,項目編號,參加天數(shù))③領導,該聯(lián)系并入“部門”實體,則“部門”的關系模式修改為:部門(部門編號,部門名稱,領導者職工編號…)④屬于,該聯(lián)系并入“職工”實體,則“職工”的關系模式修改為:職工(職工編號,姓名,部門編號,出生日期,職稱…)第三十六頁,共五十七頁,2022年,8月28日

用戶視圖法就是將需要設計的數(shù)據(jù)庫應用系統(tǒng),從不同的用戶角度分析數(shù)據(jù)需求,這些單獨的需求稱為用戶視圖。然后再將所有的用戶視圖合成一個復雜的數(shù)據(jù)庫系統(tǒng),其目的是化繁為簡,分步設計。用戶視圖法需要經(jīng)過以下步驟:1.分析與該系統(tǒng)有關的用戶種類;

2.分析各類用戶分別用到的視圖(將用戶視圖表示為一些表的集合):(1)判斷用戶視圖所包含的實體,并為每個實體建立一個表。

5.2.2用戶視圖法第三十七頁,共五十七頁,2022年,8月28日

(2)判斷每個表的關鍵字,關鍵字可能是一個或多個屬性組合。(3)判斷每種實體的性質,根據(jù)用戶需求來尋找所需實體的其他屬性。(4)判斷實體之間的關系,即1:1、1:N、M:N。

3.表的規(guī)范化將第二步所列出的表規(guī)范化為三范式(3NF)。第三十八頁,共五十七頁,2022年,8月28日

4.數(shù)據(jù)庫圖示化表示方法,用數(shù)據(jù)結構圖表示表集合中的約束與聯(lián)系。5.匯總各用戶視圖的設計結果,將所有的用戶視圖綜合成一個復雜的數(shù)據(jù)庫系統(tǒng)(注意合并過程中的沖突解決)。第三十九頁,共五十七頁,2022年,8月28日5.3.1將用戶視圖表示為一些表的集合5.3.2判斷實體之間的關系5.3.3列出所有表的關鍵字5.3.4數(shù)據(jù)庫圖示化表示方法5.3.5匯總各用戶視圖的設計結果(選擇倉庫管理進行設計)5.3數(shù)據(jù)庫設計舉例第四十頁,共五十七頁,2022年,8月28日1.倉庫保管員用戶視圖倉庫保管員需要隨時掌握倉庫的入庫情況、出庫情況、庫存情況。倉庫保管員的需求就是物資基本情況表(wzbmb)、物資入庫表(wzrkb)、物資出庫表(wzlkb)、物資庫存表(wzkcb)、用料單位表(dwbmb)等的集合。(1)判斷用戶視圖所包含的實體,并為每個實體建立一個表。

5.3.1將用戶視圖表示為一些表的集合第四十一頁,共五十七頁,2022年,8月28日

(2)判斷每個表的關鍵字。其他屬性在后面的步驟中再填入。主關鍵字是一個唯一的標識符,通過它來區(qū)分不同的對象。物資基本情況表(wzbmb)的主關鍵字是物資編碼,物資入庫表(wzrkb)的主關鍵字是日期與入庫單編號,物資出庫表(wzlkb)的主關鍵字是日期與出庫單編號,物資庫存表(wzkcb)的主關鍵字是物資編碼和日期,單位編碼表(dwbmb)的主關鍵字是單位編碼,現(xiàn)將主關鍵字加入對應的表中。

wzbmb(wzbm,wzrkb(rq,rkh,

wzlkb(rq,lkh,dwbmb(dwbm,

wzkcb(wzbm,rq,

第四十二頁,共五十七頁,2022年,8月28日

(3)判斷每種實體的性質。根據(jù)用戶需求來確定所需實體的其他屬性。

wzbmb(wzbm,wzmc,xhgg,jldw,price)。

wzrkb(rkh,rq,wzbm,cgl,sssl,price,ysr)。

wzlkb(lkh,rq,dwbm,wzbm,qls,sfs,price)。

wzkcb(wzbm,rq,price,wzkcl)。

dwbmb(dwbm,dwmc)。第四十三頁,共五十七頁,2022年,8月28日

2.倉庫主管用戶視圖因為每個單位有多個倉庫,每個倉庫有多種物資,倉庫主管需要隨時了解每個倉庫的庫存量、資金總額,每個倉庫存放哪些物資。既要保證生產(chǎn),又不積壓物資,以保證流動資金的周轉。倉庫主管的需求包括:倉庫情況、庫存情況、各單位用料情況等。(1)判斷用戶視圖所包含的實體,并為每個實體建立一個表。有倉庫情況表(wzckbmb)、庫存情況表(wzkcb)、各單位用料情況表(wzhyb)。

第四十四頁,共五十七頁,2022年,8月28日

(2)判斷每個表的關鍵字,其他屬性在后面的步驟中再填入。倉庫情況表(wzckbmb)的主關鍵字是倉庫編碼(wzckbm),庫存情況表(wzkcb)的主關鍵字是物資編碼和日期,各單位用料情況表(wzhyb)的主關鍵字是單位編碼和物資編碼,現(xiàn)將主關鍵字加入對應的表中。

wzckbmb(wzckbm,

wzkcb(wzbm,rq,

wzhyb(dwbm,wzbm,第四十五頁,共五十七頁,2022年,8月28日

(3)判斷每種實體的性質。倉庫情況表(wzckbmb)除主關鍵字倉庫編碼(wzckbm)外,還包括倉庫名稱(wzckmc)。庫存情況表(wzkcb)除主關鍵字物資編碼與日期(wzbm,rq)外,還應包括價格(price),庫存量(wzkcl)。各單位用料情況表(wzhyb)除主關鍵字單位編碼(dwbm)和物資編碼(wzbm)外,還應包括匯總期(rq),總金額(zje)。

wzckbmb(wzckbm,wzckmc)wzkcb(wzbm,rq,price,wzkcl)wzhyb(dwbm,wzbm,rq,zje)第四十六頁,共五十七頁,2022年,8月28日

3.物資用戶的用戶視圖每個使用物資的用戶需要隨時了解哪個倉庫存放哪些物資,庫存量是多少,能否滿足生產(chǎn)需要,即需要掌握倉庫庫存情況、本單位用料情況等。(1)判斷用戶視圖所包含的實體,并為每個實體建立一個表。有庫存情況表(wzkcb)(該表在前面已設計)、本單位用料情況表(dwylhyb)。第四十七頁,共五十七頁,2022年,8月28日(2)判斷每個表的關鍵字,其他屬性在后面的步驟中再填入。本單位用料情況表(dwylhyb)的主關鍵字是單位編碼和物資編碼,現(xiàn)將主關鍵字加入對應的表中。

dwylhyb(dwbm,wzbm,

(3)判斷每種實體的性質。本單位用料情況表(dwylhyb)除主關鍵字單位編碼(dwbm)和物資編碼(wzbm)外,還應包括匯總期(rq),總金額(zje):dwylhyb(dwbm,wzbm,rq,zje)。第四十八頁,共五十七頁,2022年,8月28日

(1)1:N的聯(lián)系,應將“1”表的主關鍵字加入到“N”表中作為外部關鍵字。在上述用戶視圖中,倉庫情況表wzckbmb(wzckbm,wzckmc)與庫存情況表wzkcb(wzbm,rq,price,wzkcl)就是1:N的聯(lián)系。因為每個倉庫可以存放多種物資,所以應將倉庫情況表wzckbmb表中的wzckbm加入到庫存情況表wzkcb表中作外部關鍵字。

wzkcb(wzbm,rq,price,wzkcl,wzckbm)5.3.2判斷實體之間的關系第四十九頁,共五十七頁,2022年,8月28日

(2)M:N的聯(lián)系,應建立一個新表,新表的關鍵字是原始表中多個關鍵字的組合。在上述用戶視圖中,用料單位與物資是M:N的聯(lián)系,即每個用料單位可以領用倉庫中的任何一種物資,反之每一種物資可被任一單位領用。物資出庫表(wzlkb)就是用料單位與物資基本情況表(wzbmb)之間加入的表,如果出庫單是一單多料制即一張領料單填寫多種物資,物資出庫表(wzlkb)的關鍵字就必須包括出庫日期(領料日期)和物資編碼。第五十頁,共五十七頁,2022年,8月28日

(1)主關鍵字:所有表的關鍵字均在前面列出。但是要根據(jù)實際需求,進行調整,如果各個倉庫允許存放相同物資的話,那么庫存情況表wzkcb中的(wzckbm)也必須包含在主關鍵字組合中。同樣,wzckbm也應包含在物資入庫表wzrkb和物資出庫表wzlkb的主關鍵字組合中。(2)可選關鍵字:可選關鍵字可以作為主關鍵字的屬性或者屬性的組合,但它不是主關鍵字。可選關鍵字并不常見,在上述表中不存在。(3)第二關鍵字:第二關鍵字是指與檢索數(shù)據(jù)緊密相關的屬性。如果系統(tǒng)中有第二關鍵字則可在這一步明確。(4)外部關鍵字:第2章已指出,它是指一個表的屬性或屬性的集合,必須與另一個表某行的主關鍵字相匹配。5.3.3列出所有表的關鍵字第五十一頁,共五十七頁,2022年,8月28日5.3.4

溫馨提示

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

評論

0/150

提交評論