希望的田野資源信息系統(tǒng)數(shù)據(jù)庫原理及設計同學們好！第二講：數(shù)據(jù)庫結(jié)構(gòu)設計第1頁，共86頁。數(shù)據(jù)庫設計的規(guī)范化理論數(shù)據(jù)庫設計一般方法資源數(shù)據(jù)庫結(jié)構(gòu)設計第二節(jié)資源數(shù)據(jù)庫結(jié)構(gòu)設計本節(jié)提要第2頁，共86頁。一、數(shù)據(jù)庫設計的規(guī)范化理論數(shù)據(jù)庫設計是建立數(shù)據(jù)庫應用系統(tǒng)的核心問題。設計的關鍵是如何使設計的數(shù)據(jù)庫能合理地存儲用戶的數(shù)據(jù)，方便用戶進行數(shù)據(jù)處理。本章將對數(shù)據(jù)庫設計進行討論，并給出關于如何進行設計的一些基本理論和原則。關系數(shù)據(jù)庫：自從提出了關系數(shù)據(jù)庫理論后，許多專家學者對關系數(shù)據(jù)庫理論進行了深入的研究和發(fā)展，借助于數(shù)學工具規(guī)定了一整套的關系數(shù)據(jù)庫設計的理論和方法——函數(shù)依賴理論和關系規(guī)范化理論。該理論使關系數(shù)據(jù)庫設計方法走向完備。第3頁，共86頁。數(shù)據(jù)庫設計完全是人的問題，而不是數(shù)據(jù)庫管理系統(tǒng)的問題。系統(tǒng)不管一個設計是好是壞，照樣運行。誰設計：在大型多用戶共享數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)庫設計應當由數(shù)據(jù)庫管理員和系統(tǒng)分析員一起負責，和用戶一道工作，了解各個用戶的要求，把所有要求合并起來，共同為整個數(shù)據(jù)庫做出恰當?shù)?、完整的設計。（一）數(shù)據(jù)庫設計概述第4頁，共86頁。（二）問題的提出開發(fā)一個具體的數(shù)據(jù)庫應用系統(tǒng)時，核心問題是設計數(shù)據(jù)庫結(jié)構(gòu)，數(shù)據(jù)庫結(jié)構(gòu)的設計好壞是成敗的關鍵所在。當一個應用系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)設計完成之后，就可利用我們選定的關系數(shù)據(jù)庫管理系統(tǒng)提供的數(shù)據(jù)定義語言去描述庫結(jié)構(gòu)，即定義關系數(shù)據(jù)庫模式及關系模式。但是，由于設計者對現(xiàn)實世界的認識或看問題的方法不同，同一個系統(tǒng)可以設計出不同的關系數(shù)據(jù)庫結(jié)構(gòu)。那么，我們?nèi)绾胃鶕?jù)設計的對象去構(gòu)造一個好的關系數(shù)據(jù)庫結(jié)構(gòu)，即構(gòu)造幾個關系（表）呢？每個關系由哪些屬性組成，好壞如何評價呢？為了說明關系模式設計的性能好壞，讓我們先看一個例子。例如，某學校要建立一個學生管理數(shù)據(jù)庫，有如下屬性：學號、系名、系主任、成績、課程。第5頁，共86頁。我們可以組成一個關系名為UN的關系模式：UN（學號，課程，成績，系名，系主任）現(xiàn)實世界的事實告訴我們：①一個系有若干學生，但一個學生只屬于一個系。②一個系只有一名系主任。③一個學生可以選修多門功課，每門課程可有若干學生選修。④每個學生學習每門課程有一個成績。當（學號，課程）組合屬性值一定時，也就確定了該學號和課程對應的成績、系名、系主任的屬性值，并且有唯一性，所以（學號，課程）具有記錄（元組）標識作用，是該關系的主鍵（關鍵字）。這個關系模式在使用中會出現(xiàn)什么問題呢？第6頁，共86頁。（1）數(shù)據(jù)冗余每個系主任的姓名和系名與該系的每個學生所選修的每一門功課的成績出現(xiàn)的次數(shù)一樣多，這將造成存儲空間的浪費和維護代價太高。例如，該系有100名學生，每個學生平均選30門課，則該系名和系主任名要重復100x30＝3000次。這種數(shù)據(jù)重復存放造成空間浪費稱為“數(shù)據(jù)冗余”。第7頁，共86頁。2.修改異常例中，如果要更換系主任，就必須逐一修改每條記錄。若有疏忽，則會造成數(shù)據(jù)的不一致性（同一系的學生有不同的系主任），當然也就破壞了數(shù)據(jù)的完整性（由于修改失誤，造成數(shù)據(jù)的不正確），這稱為“修改異?！被蚍Q為“潛在的不相容性”。第8頁，共86頁。3.插入異常在關系模式UN中，主鍵是（學號，課程）。主鍵的特性不能為空或部分為空，主鍵為空或部分為空的記錄（元組）不能存入數(shù)據(jù)庫中，否則，就會因為失去標識而使關系中存在相同元組，這是關系性質(zhì)的完整性約束所不允許的。例中，如果一個系剛成立，尚無學生，或者有了學生但還沒有選課，我們就無法將該系的系名和系主任插入到數(shù)據(jù)庫中，這稱為“插入異常”。第9頁，共86頁。4.刪除異常

反過來，如果某個系的學生全部畢業(yè)了，我們刪除該系學生及其選課信息的同時，會把系名和系主任的信息同時刪掉。上述這些問題的出現(xiàn)顯然是我們不希望的，因此我們說，上述關系模式是一個“不好”的關系數(shù)據(jù)庫模式。“不好”的數(shù)據(jù)庫設計在設計中應該避免。可見，關系數(shù)據(jù)庫中的各關系不能任意設計，關系要按一定的要求去設計，如果設計不好，將大量的字段（屬性）放于一個關系模式中，這就使用戶的數(shù)據(jù)庫要忍受著上述幾個問題的干擾，運行效率低，編程和維護工作量大。因此，用戶必須對數(shù)據(jù)庫設計給予高度重視。第10頁，共86頁。（三）解決辦法上述模式為什么會發(fā)生問題呢？這是因為關系中屬性之間存在不好的聯(lián)系。假如我們把上述模式改造分解為SD，DM和SG三個關系模式，就會消除上述問題，從而得到一個好的關系模式。三個關系模式如圖所示，下圖是三個關系模式填入數(shù)據(jù)的實例。第11頁，共86頁。 所以，當我們企圖把太多的信息存放在一個關系時，就會出現(xiàn)數(shù)據(jù)冗余和更新異常等問題。主要表現(xiàn)如下： 1．

數(shù)據(jù)冗余。 2．

修改異常。 3．

刪除異常。 4．插入異常。

第12頁，共86頁。（1）問題的根源關系的鍵碼函數(shù)決定該關系的所有其它屬性。由于鍵碼能唯一確定一個元組，所以，也可以說關系的鍵碼函數(shù)決定該關系的所有屬性。一個關系中的所有屬性都函數(shù)依賴于該關系的鍵碼。不同的屬性在關系模式中所處的地位和扮演的角色是不同的。把鍵碼所在的屬性稱為主屬性，而把鍵碼屬性以外的屬性稱為非主屬性。第13頁，共86頁。問題的根源（2）不同的屬性對鍵碼函數(shù)依賴的性質(zhì)和程度是有差別的。有的屬于直接依賴，有的屬于間接依賴（通常稱為傳遞依賴）。當鍵碼由多個屬性組成時，有的屬性函數(shù)依賴于整個鍵碼屬性集，而有的屬性只函數(shù)依賴于鍵碼屬性集中的一部分屬性。第14頁，共86頁。從上述例子中，我們可以看到，用幾個結(jié)構(gòu)簡單的關系去取代原來結(jié)構(gòu)復雜的關系，可有效地消除“異?！保@種分解過程叫做關系的規(guī)范化。分解時采用了關系規(guī)范化理論作指導。一般來說，通過規(guī)范化理論可以把不好的關系數(shù)據(jù)庫模式逐步轉(zhuǎn)變?yōu)橐粋€好的關系數(shù)據(jù)庫模式。所以，任何一個設計關系數(shù)據(jù)庫的人，都要熟悉規(guī)范化技術與理論，了解規(guī)范化理論必須先了解關系模式中各屬性之間的相互函數(shù)依賴，因此，下面將先討論屬性間（字段）的函數(shù)依賴關系，然后討論關系規(guī)范化理論，從而使大家掌握關系數(shù)據(jù)庫的設計理論，并將其用到具體的關系數(shù)據(jù)庫設計工作中去。第15頁，共86頁。函數(shù)依賴如果關系R的兩個元組在屬性A1，A2，…An上一致（也就是，兩個元組在這些屬性所對應的各個分量具有相同的值），則它們在另一個屬性B上也一致。那么，我們就說在關系R中屬性B函數(shù)依賴于屬性A1A2…An。 A1A2…AnB，

“A1，A2，…，An函數(shù)決定B”。A1A2…An稱為決定因素。學生（學號，姓名，院系，系主任，課程，成績）學號姓名第16頁，共86頁。對于函數(shù)依賴WA，如果存在VW（V是W的真子集）而函數(shù)依賴VA成立，則稱A部分依賴于W；若不存在這種V，則稱A完全依賴于W。學生（學號，姓名，院系，系主任，課程，成績）學號，課程姓名，院系，系主任 當存在非主屬性對鍵碼部分依賴時，就會產(chǎn)生數(shù)據(jù)冗余和更新異常。若非主屬性對鍵碼完全函數(shù)依賴，則不會出現(xiàn)類似問題。完全依賴與部分依賴P第17頁，共86頁。 ·對于函數(shù)依賴XY，如果YX（X不函數(shù)依賴于Y）而函數(shù)依賴YZ成立，則稱Z對X傳遞依賴。學生（學號，姓名，院系，系主任，課程，成績）學號院系，院系系主任 如果XY，且YX，則X，Y相互依賴，這時Z與X之間就不是傳遞依賴，而是直接依賴了。院系系主任系主任院系傳遞依賴第18頁，共86頁。解決的途徑部分依賴和傳遞依賴有一個共同之處，這就是，二者都不是基本的函數(shù)依賴，而都是導出的函數(shù)依賴：部分依賴是以對鍵碼的某個真子集的依賴為基礎傳遞依賴的基礎則是通過中間屬性聯(lián)系在一起的兩個函數(shù)依賴。第19頁，共86頁。導出的函數(shù)依賴在描述屬性之間的聯(lián)系方面并沒有比基本的函數(shù)依賴提供更多的信息。在一個函數(shù)依賴集中，導出的依賴相對于基本的依賴而言，雖然從形式上看多一種描述方式，但從本質(zhì)上看，則完全是冗余的。正是由于關系模式中存在對鍵碼的這種冗余的依賴導致數(shù)據(jù)庫中的數(shù)據(jù)冗余和更新異常。第20頁，共86頁。解決的途徑——消除關系模式中各屬性對鍵碼的冗余的依賴。由于冗余的依賴有部分依賴與傳遞依賴之分，而屬性又有主屬性與非主屬性之別，把解決的途徑分為幾個不同的級別，用范式來區(qū)別。第21頁，共86頁。范式就是符合某一種級別的關系模式的集合。目前主要有六種范式：第一范式第二范式第三范式BC范式第四范式第五范式第一范式需滿足的要求最低，在第一范式基礎上滿足進一步要求的為第二范式：1NF2NF3NFBCNF4NF5NF通過分解把屬于低級范式的關系模式轉(zhuǎn)換為幾個屬于高級范式的關系模式的集合，這一過程稱為規(guī)范化。第22頁，共86頁。第一范式（1NF）如果一個關系模式R的所有屬性都是不可分的基本數(shù)據(jù)項（原子項），則這個關系屬于第一范式。在任何一個關系數(shù)據(jù)庫系統(tǒng)中，第一范式是對關系模式的一個最起碼的要求。不滿足第一范式的數(shù)據(jù)庫模式不能稱為關系數(shù)據(jù)庫。第23頁，共86頁。第二范式（2NF）若關系模式R屬于第一范式，且每個非主屬性都完全函數(shù)依賴于鍵碼，則R屬于第二范式。當1NF的關系消除了非主屬性對關鍵字的部分函數(shù)依賴，即可成為滿足2NF的關系。如果關鍵字是單個屬性，該關系模式自然屬于2NF。當關系模式R屬于2NF，插入異常、刪除異常和修改復雜的問題會有所改善。第24頁，共86頁。第三范式（3NF）若關系模式R屬于第一范式，且每個非主屬性都不傳遞依賴于鍵碼，則R屬于第三范式。屬于3NF的關系中所有屬性不但要能夠唯一地被主關鍵字所標識，而且它們之間還必須相互獨立，不存在部分函數(shù)依賴和傳遞函數(shù)依賴關系。3NF關系可從2NF關系消除非主屬性對關鍵字的傳遞函數(shù)依賴后獲得。當R∈3NF時，通常出現(xiàn)的插入異常、刪除異常和修改復雜的問題可得到有效解決。第25頁，共86頁。規(guī)范化和模式分解1．規(guī)范化把一個低一級范式的關系模式轉(zhuǎn)換為若干個高一級范式的關系模式的過程叫作規(guī)范化。規(guī)范化的基本思想是逐步消除數(shù)據(jù)依賴中不合適的部分，使模式中的各關系模式達到某種程度的“分離”，即“一事一地”的模式設計原則，讓一個關系描述一個概念、一個實體或者實體間的一種聯(lián)系。多于一個概念，就把它“分離”出去。因此所謂規(guī)范化實質(zhì)上是概念的單一化。在設計數(shù)據(jù)庫應用系統(tǒng)中，關系的規(guī)范化是一個重要的、不可缺少的工作，用戶應給予充分的重視。第26頁，共86頁。2．模式分解在關系數(shù)據(jù)庫中，對關系模式的最基本要求是滿足第一范式，這樣的關系模式是合法的、允許的，但人們發(fā)現(xiàn)有些關系模式存在插入、刪除、修改異常和數(shù)據(jù)冗余等弊病，人們要尋求解決這些問題的方法，這就是規(guī)范化的目的。把一個關系模式分解為n個關系模式，稱為關系模式的分解。模式分解是提高關系模式范式等級的重要方法。第27頁，共86頁。下面我們舉例來說明關系模式的分解方法和遵守的準則。為便于表示函數(shù)依賴關系，可在主屬性下方劃一橫線，并用箭頭標出屬性之間的依賴關系。例1：求關系UN(學號，課程，成績，系名，系主任）的范式等級。同時，分解使之達到3NF。分析：①各屬性都是不可分的數(shù)據(jù)項； ②存在部分函數(shù)依賴，例如（學號，課程）系名。結(jié)論：UN∈1NF，不屬于2NF。第28頁，共86頁。我們采用投影運算使UN由1NF規(guī)范化為2NF。方法是將UN關系中屬性間的部分函數(shù)依賴分解為SG和SDM兩關系模式，模式如下：分析：SG不存在部分函數(shù)依賴和傳遞函數(shù)依賴。結(jié)論：SG∈3NF。分析：①SDM不存在部分函數(shù)依賴，因此，SDM∈2NF。②SDM存在傳遞函數(shù)依賴，例如：學號系名，系名學號，系名系主任。結(jié)論：SDM∈2NF，不屬于3NF。我們分析一下，如果關系SDM不屬于3NF會帶來什么問題。①系主任名仍要重復存儲（類似“更換系主任”的修改），仍需要修改較多的記錄。②當某一系沒有招生或?qū)W生全部畢業(yè)，系主任和系名信息將丟失，所以仍有插入、刪除、修改異常。第29頁，共86頁。為解決這些問題，可對SDM分解，使之成3NF，分解結(jié)果如下：很明顯，SD∈3NF，DM∈3NF。至此，我們用滿足3NF的三個關系模式SG，SD和DM取代原來的關系模式UN，所有的異?！氨撞　比肯Я恕Ｎ覀冞€可以看出，SG，SD和DM均用一個關系模式表示單個實體（學生實體、選課實體、系實體）。第30頁，共86頁。例2：假設某單位有訂貨合同一覽表，如圖4．4所示。該表中的零件單價在訂貨時根據(jù)雙方談判時決定。這種表規(guī)范程度低，其中包含有合同清單表。表的主關鍵字是“合同號十零件號”，存在部分函數(shù)依賴，例如，主關鍵字中的合同號訂貨日期等。規(guī)范化的方法是將表進行分解，使之成為一個獨立的、滿足3NF規(guī)范要求的表。這樣就得到訂貨合同和合同清單兩個規(guī)范的表，如圖4．5所示。第31頁，共86頁。一般說來，沒有異常弊病的數(shù)據(jù)庫設計是好的數(shù)據(jù)庫設計。但我們應從實際出發(fā)，對于那些只要求查詢而不要求插入、刪除等操作的系統(tǒng)，則不必擔心發(fā)生“異?！保膊槐匾筮^高的范式。如果過度分解，即使對消除異常有好處，但連接代價是很大的，這可能得不償失。因此，要綜合考慮，權(quán)衡得失。第32頁，共86頁。分解的原則主要涉及兩個原則： ·無損連接（LosslessJoin） 如果對新的關系進行自然連接得到的元組的集合與原關系完全一致，則稱為無損連接。 無損連接反映了模式分解的數(shù)據(jù)等價原則。第33頁，共86頁。 ·保持依賴（PreserveDependency） 如果分解后總的函數(shù)依賴集與原函數(shù)依賴集保持一致，則稱為保持依賴。 保持依賴反映了模式分解的依賴等價原則。依賴等價保證了分解后的模式與原有的模式在數(shù)據(jù)語義上的一致性。第34頁，共86頁。比如，我們對SDM的分解可以有如下三種結(jié)果，它們均屬于3NF，但分解質(zhì)量卻大不相同。①SD（學號，系名）DM（系名，系主任）；②SD（學號，系名）SM（學號，系主任）；③SM（學號，系主任）DM（系主任，系名）。第①種分解是無損的，因為同時保持了原來的學號系名和系名系主任（現(xiàn)實規(guī)律是先有系名后有系主任）的兩個完全函數(shù)依賴，這種分解是進行規(guī)范化要追求的目標。第②種雖然也是無損的，但是，這種分解只保持了學號系名，未保持系名系主任，卻用了原來的學號系主任，因此存在著“異?！薄＠?，學生轉(zhuǎn)系，要同時修改SD和SM兩個關系，顯然這種分解不符合要求。第③種分解使用了系名系主任，丟失了學號系名，這種分解是有損的，使分解后丟失了信息，不能從學生查詢到所在系名。丟失信息從根本上是不允許的。第35頁，共86頁。關系模式規(guī)范化流程圖：

第36頁，共86頁。二、數(shù)據(jù)庫設計一般方法采用系統(tǒng)化、規(guī)范化設計方法。四個階段進行數(shù)據(jù)庫設計。理解需求分析。概念設計，我們將使用E-R模型作為概念設計的工具。邏輯設計，以關系模型和關系數(shù)據(jù)庫管理系統(tǒng)為基礎討論邏輯設計。物理設計。第37頁，共86頁。概述在給定的DBMS、操作系統(tǒng)和硬件環(huán)境下，如何表達用戶的需求，并將其轉(zhuǎn)換為有效的數(shù)據(jù)庫結(jié)構(gòu)，構(gòu)成較好的數(shù)據(jù)庫模式，這個過程稱為數(shù)據(jù)庫設計。數(shù)據(jù)庫及其應用系統(tǒng)開發(fā)的全過程可分為兩大階段：數(shù)據(jù)庫系統(tǒng)的分析與設計階段；數(shù)據(jù)庫系統(tǒng)的實施、運行與維護階段。

第38頁，共86頁。數(shù)據(jù)庫設計的任務根據(jù)一個單位的信息需求、處理需求和數(shù)據(jù)庫的支撐環(huán)境，設計出數(shù)據(jù)模式(包括外模式、邏輯（概念）模式和內(nèi)模式)以及典型的應用程序。其中信息需求表示一個單位所需要的數(shù)據(jù)及其結(jié)構(gòu)。處理需求表示一個單位需要經(jīng)常進行的數(shù)據(jù)處理。前者表達了對數(shù)據(jù)庫的內(nèi)容及結(jié)構(gòu)的要求，也就是靜態(tài)要求；后者表達了基于數(shù)據(jù)庫的數(shù)據(jù)處理要求，也就是動態(tài)要求。第39頁，共86頁。信息需求定義所設計的數(shù)據(jù)庫將要用到的所有信息，描述實體、屬性、聯(lián)系的性質(zhì),描述數(shù)據(jù)之間的聯(lián)系。處理需求定義所設計的數(shù)據(jù)庫將要進行的數(shù)據(jù)處理，描述操作的優(yōu)先次序、操作執(zhí)行的頻率和場合，描述操作與數(shù)據(jù)之間的聯(lián)系。第40頁，共86頁。數(shù)據(jù)庫設計有兩種不同的方法以信息需求為主，兼顧處理需求，這種方法稱為面向數(shù)據(jù)的設計方法以處理需求為主，兼顧信息需求，這種方法稱為面向過程的設計方法。第41頁，共86頁。數(shù)據(jù)庫設計的3個特點

①反復性(Iterative) ②試探性(Tentative) ③分步進行(Multistage)第42頁，共86頁。數(shù)據(jù)庫設計的步驟數(shù)據(jù)庫的設計一般分為四步： 需求分析 概念設計 邏輯設計 物理設計

第43頁，共86頁。需求分析概念設計邏輯設計物理設計需求分析說明書概念模式邏輯模式物理模式信息需求硬件和操作系統(tǒng)處理需求DBMS特性獨立于DBMS相關于DBMS第44頁，共86頁。需求分析 首先必須確認數(shù)據(jù)庫的用戶和用途。由于數(shù)據(jù)庫是一個單位的模擬，數(shù)據(jù)庫設計者必須對一個單位的基本情況有所了解。收集和分析這些資料的過程稱為需求分析。第45頁，共86頁。概念設計 用概念數(shù)據(jù)模型，例如E-R模型，表示數(shù)據(jù)及其相互間的聯(lián)系，產(chǎn)生反映用戶信息需求和處理需求的數(shù)據(jù)庫概念模式。數(shù)據(jù)庫概念模式是獨立于任何數(shù)據(jù)庫管理系統(tǒng)、面向現(xiàn)實世界的數(shù)據(jù)模型。第46頁，共86頁。邏輯設計 在邏輯設計階段，將第二步所得到的數(shù)據(jù)庫概念模式，轉(zhuǎn)換成以DBMS的邏輯數(shù)據(jù)模型表示的邏輯模式。第47頁，共86頁。物理設計 根據(jù)數(shù)據(jù)庫的邏輯和概念模式、DBMS及計算機系統(tǒng)所提供的功能和施加的限制，設計數(shù)據(jù)庫文件的物理存儲結(jié)構(gòu)、各種存取路徑。第48頁，共86頁。

在不同的設計階段將形成數(shù)據(jù)庫的三層模式。 1）需求分析階段，綜合用戶應用需求； 2）概念設計階段，形成獨立于數(shù)據(jù)庫管理系統(tǒng)DBMS的概念模式；3）邏輯設計階段，將概念模式（可用E-R圖描述）轉(zhuǎn)換成DBMS支持的數(shù)據(jù)模型（如關系模型），形成數(shù)據(jù)庫的邏輯模式；第49頁，共86頁。4）據(jù)用戶處理的要求和安全性的考慮，在基本表的基礎上建立必要的視圖，形成數(shù)據(jù)庫的外模式； 5）物理設計階段，根據(jù)DBMS的特點和處理的需要，選擇存儲結(jié)構(gòu)，建立索引，形成數(shù)據(jù)庫的內(nèi)模式。第50頁，共86頁。數(shù)據(jù)庫的設計階段與數(shù)據(jù)庫的模式結(jié)構(gòu)之間的聯(lián)系如圖所示。第51頁，共86頁。應用1應用需求應用n應用需求概念模式邏輯模式內(nèi)模式應用1應用n外模式外模式綜合轉(zhuǎn)換映象映象設計使用第52頁，共86頁。需求分析分為應用領域的調(diào)查定義數(shù)據(jù)庫支持的信息與應用定義數(shù)據(jù)庫操作任務定義數(shù)據(jù)字典等幾步.第53頁，共86頁。應用領域的調(diào)查

應用領域的調(diào)查分為兩個階段。 第一階段對應用領域的組織結(jié)構(gòu)、業(yè)務流程和數(shù)據(jù)流程進行調(diào)查，對現(xiàn)行系統(tǒng)的功能和所需信息有一個明確的認識； 第二階段是在第一階段的基礎上進行應用領域的分析，抽象出應用領域的邏輯模型，把邏輯模型用數(shù)據(jù)流圖來表示。

第54頁，共86頁。數(shù)據(jù)流圖（DataFlowDiagram）可以表示現(xiàn)行系統(tǒng)的信息流動和加工處理等詳細情況，是現(xiàn)行系統(tǒng)的一種邏輯抽象表示，它獨立于系統(tǒng)的實現(xiàn)。第55頁，共86頁。成績管理員統(tǒng)計處理成績統(tǒng)計產(chǎn)生報表獎學金評委會成績清單統(tǒng)計結(jié)果第56頁，共86頁。定義操作任務數(shù)據(jù)庫操作任務對應于最終數(shù)據(jù)庫系統(tǒng)的事務。一個應用包括一個或多個數(shù)據(jù)庫操作任務。每個數(shù)據(jù)庫操作任務可屬于多個應用。第57頁，共86頁。操作任務定義的內(nèi)容如下：1.操作任務名3.所屬應用名5.輸出數(shù)據(jù)項7.數(shù)據(jù)庫操作定義9.使用頻率2.操作任務編號4.輸入數(shù)據(jù)項6.功能定義8.操作信息量10.響應時間第58頁，共86頁。概念設計概念設計的任務包括兩個方面：數(shù)據(jù)庫概念模式設計:以需求分析階段所識別的數(shù)據(jù)項為基礎，使用高級數(shù)據(jù)模型建立數(shù)據(jù)庫概念模式事務設計:考察需求分析階段提出的數(shù)據(jù)庫操作任務，形成數(shù)據(jù)庫事務的高級說明第59頁，共86頁。應用得最廣泛的是實體聯(lián)系(E-R)模型。E-R模型除了具有上述的特點外，還可以用E-R圖表示數(shù)據(jù)模式，便于理解與交流。第60頁，共86頁。E-R模型實體—聯(lián)系數(shù)據(jù)模型基于對現(xiàn)實世界的這樣一種認識：現(xiàn)實世界由一組成為實體的基本對象以及這些對象間的聯(lián)系構(gòu)成。數(shù)據(jù)庫中實體通過屬性集合來描述，例如account-number與blance屬性描述了銀行某個特定的帳戶聯(lián)系是實體間的相互關系。例如depositor聯(lián)系將一個客戶和她的帳號聯(lián)系在一起。同一類型的所有實體的集合稱為實體集，同一類型的所有聯(lián)系的集合稱為聯(lián)系集第61頁，共86頁。概念模型--ER模型基本概念實體（Entity）：客觀存在并可以相互區(qū)分的事物叫實體。（例如：一個個學生、一輛輛轎車）屬性（Attribute）：實體一般具有若干特征，稱之為實體的屬性。例如：學生具有學號、姓名等屬性。域（Domain）：一個屬性可能取值的范圍稱為這個屬性的域。例如：性別的域值只能為“男”或“女”第62頁，共86頁。ER模型基本概念候選碼：能夠唯一標識實體的屬性或最小屬性組稱為候選碼，可能存在多個候選碼，設計者必須指明一個候選碼做主碼（關鍵字）。例如：見圖實體型（Entitytype）：具有相同屬性的實體具有共同的特征和性質(zhì)，用實體名及其屬性集合來抽象、刻畫同類實體，稱為實體型。學生學號姓名性別專業(yè)第63頁，共86頁。ER模型基本概念實體集（Entityset）：同型實體的集合聯(lián)系：現(xiàn)實世界的事物之間是有聯(lián)系的，這種聯(lián)系在信息世界中反映為：實體(型)內(nèi)部的聯(lián)系和實體(型)之間的聯(lián)系。兩個實體型之間的聯(lián)系一對一聯(lián)系（1：1）例如：部門、經(jīng)理一對多聯(lián)系（1：n）例如：部門、雇員多對多聯(lián)系（m：n）例如：學生、課程第64頁，共86頁。ER模型基本概念第65頁，共86頁。⑴實體例：客戶帳戶課程⑶屬性例：,客戶名學號⑵關系例：存款教課111NMNE-R圖（實體–聯(lián)系圖）第66頁，共86頁。例1：銀行存款的簡化模型客戶存款帳戶編號姓名性別電話帳戶號余額第67頁，共86頁。實例分析例子2：開發(fā)學校信息管理系統(tǒng)。學校中有若干系，每個系有若干班級和教研室，每個教研室有若干教師，其中有教授和副教授每人各帶若干名研究生，每個班有若干學生，每個學生選若干課程，每門可由若干學生選修。第68頁，共86頁。實例分析（E-R圖）系系名電話號班名地址學號人數(shù)班級學生課程教研室教師有設有屬于工作選修指導姓名住處課程號課程名學時教研室名地址電話號職工號姓名職稱研究方向1nn11n1nnm研究方向是否四級1n指導人數(shù)第69頁，共86頁。邏輯設計數(shù)據(jù)庫邏輯設計的任務是把數(shù)據(jù)庫概念設計階段產(chǎn)生的數(shù)據(jù)庫概念模式變換為數(shù)據(jù)庫邏輯模式。數(shù)據(jù)庫邏輯設計依賴于邏輯數(shù)據(jù)模型和數(shù)據(jù)庫管理系統(tǒng)。第70頁，共86頁。例：銀行存款的簡化模型客戶存款帳戶住址編號姓名電話帳戶號余額第71頁，共86頁。customerCusto_idCusto_nameCusto_addressCusto_tel001001黎鏵武漢278989001002黎鏵武漢108989Accoun_idbalanceAccoun_idCusto_idaccountdeopsitor第72頁，共86頁。邏輯模式的規(guī)范化和優(yōu)化 從E-R圖轉(zhuǎn)換而來的關系模式還只是邏輯模式的雛形，要成為邏輯模式，還需要進行下列幾步的處理： ·

規(guī)范化； ·適應ＤＢＭＳ限制條件的修改； ·對性能、存儲空間等的優(yōu)化； ·用ＤＢＭＳ提供的ＤＤＬ定義邏輯模式。第73頁，共86頁。物理設計數(shù)據(jù)庫物理設計的任務是，為每個關系模式選擇合適的存儲結(jié)構(gòu)和存取路徑。第74頁，共86頁。選擇索引的一般步驟

滿足下列條件之一，不宜建立索引： ①很少出現(xiàn)在查詢條件中的屬性； ②屬性值很少的屬性。 ③屬性值分布嚴重不均的屬性。 ④經(jīng)常更新的屬性或表，因為更新時有關的索引需要做相應的修改； 第75頁，共86頁。

凡符合下列條件之一，可以考慮在有關屬性上建立索引：①主鍵碼和外鍵碼上一般都建有索引，這有利于主鍵碼唯一性檢查和引用完整性約束檢查；主鍵碼和外鍵碼通常都是連接條件中的公共屬性，建立索引，可顯著提高連接查詢的效率。②對于以讀為主或只讀的表，只要需要，存儲空間又允許，可以多建索引；第76頁，共86頁。數(shù)據(jù)庫的實施

根據(jù)數(shù)據(jù)庫的邏輯設計和物理設計的結(jié)果，建立實際的數(shù)據(jù)庫結(jié)構(gòu)、裝入數(shù)據(jù)、進行測試和試運行的過程稱為數(shù)據(jù)庫的實施。

1．

建立實際數(shù)據(jù)庫結(jié)構(gòu) 2．

裝入試驗數(shù)據(jù)，調(diào)試應用程序 3．

裝入實際數(shù)據(jù) 4．進入試運行第77頁，共86頁。三、地礦資源屬性數(shù)據(jù)庫結(jié)構(gòu)設計數(shù)據(jù)庫結(jié)構(gòu)的設計是數(shù)據(jù)庫系統(tǒng)設計的核心。其主要任務是確定整個數(shù)據(jù)庫的數(shù)據(jù)邏輯結(jié)構(gòu)。地礦資源勘查信息系統(tǒng)子系統(tǒng)的設計過程，實質(zhì)上就是將反映勘查區(qū)的有關地礦資源屬性的數(shù)據(jù)，按照系統(tǒng)分析的結(jié)果組織成符合于某個特定的數(shù)據(jù)庫管理系統(tǒng)(例如，F(xiàn)oxBASE+、FoxPRO、Oracle或SyBASE等)的數(shù)據(jù)模式所要求的數(shù)據(jù)結(jié)構(gòu)。第78頁，共86頁。（一）地礦資源勘查區(qū)數(shù)據(jù)模式的建立先將地礦模型中各種實體集的全部屬性，按其來源和取值方式分成許多類別，再在各個類別中進行比較，合并其中同種或同名的屬性，然后再與有關的“標準”、“規(guī)范”及現(xiàn)行的生產(chǎn)記錄表格作比較，歸納為幾個大類，得到了一系列數(shù)據(jù)模式。每個數(shù)據(jù)模式便是一個新的實體集，而新實體集內(nèi)的每個數(shù)據(jù)項對應著一個屬性。第79頁，共86頁。煤資源勘查區(qū)地質(zhì)信息勘探開發(fā)史地理條件水文條件巖心編錄采樣化驗勘查區(qū)概況測井分析生產(chǎn)管理綜合數(shù)據(jù)其他數(shù)據(jù)煤炭資源勘查區(qū)全局數(shù)據(jù)模式第80頁，共86頁。（二）數(shù)據(jù)文件結(jié)構(gòu)的設計1.劃分實體集，給定初選文件名稱2.選擇描述實體集的全部屬性，確定索引關鍵字3.分析實體集內(nèi)各屬性的依賴關系，進行數(shù)據(jù)規(guī)范化處理4.定義數(shù)據(jù)完整性約束第81頁，共86頁。沉積巖巖心編錄煤心編錄巖心編錄巖漿巖巖心編錄構(gòu)造巖巖心編錄巖心編錄數(shù)據(jù)模式的實體集劃分第82頁，共86頁。勘查區(qū)巖心編錄表501鉆孔概況515火成巖綜合描述502巖層一般參數(shù)516火成巖礦物成分描述503礦芯與礦層(體)描述517火成巖包裹體描述