ISBN978-7-111-50122-0第3章

數據庫設計數據庫是數據庫系統中最基本、最重要的部分。數據庫性能的高低，決定了整個數據庫應用系統的性能。設計一個性能優(yōu)良的數據庫，是滿足各方面對數據需要的必須。本章主要介紹規(guī)范化概念，數據庫設計的概念以及方法。3.1規(guī)范化1．范式的種類為了使關系模式設計的方法趨于完備，數據庫專家研究了關系規(guī)范化理論。從1971年起，E.F.Codd相繼提出了第一范式（1NF）、第二范式（2NF）、第三范式（3NF），Codd與Boyce合作提出了Boyce-Codd范式（BCNF）。在1976年～1978年間，Fagin、Delobe，以及Zaniolo又定義了第四范式（4NF）。到目前為止，已經提出了第五范式（5NF）。2．范式之間的關系及規(guī)范化各范式之間的關系及規(guī)范化過程如下：1）取原始的1NF關系模式，消去任何非主屬性對關鍵字的部分函數依賴，從而產生一組2NF的關系模式。2）取2NF關系模式，消去任何非主屬性對關鍵字的傳遞函數依賴，產生一組3NF的關系模式。3）取3NF的關系模式的投影，消去決定因素不是候選關鍵字的函數依賴，產生一組BCNF的關系模式。4）取BCNF關系模式的投影，消去其中不是函數依賴的非平凡的多值依賴，產生一組4NF關系模式。所以有，1NF

2NF

3NF

BCNF

4NF

5NF。3.1.1函數依賴函數依賴（FunctionalDependency）是關系模式中各個屬性之間的一種依賴關系。是規(guī)范化理論中一個最重要、最基本的概念。定義1設R（U）是屬性集U上的關系模式，X和Y均為U的子集。如果R（U）的任意一個可能的關系r都存在著對于X的每一個具體值，Y都有惟一的具體值與之對應，則稱X函數決定Y，或Y函數依賴于X，記為：X→Y。稱X為決定因素，Y是依賴因素。下面介紹一些術語和記號：1）X→Y，但Y

Y，則稱X→Y是非平凡的函數依賴。若不特別聲明，總是討論非平凡的函數依賴。2）X→Y，但Y

X，則稱X→Y是平凡的函數依賴。3）若X→Y，則X叫做決定因素。4）若X→Y，Y→X，則記作X←→Y。5）若Y不函數依賴于X，則記作XY。定義2在R（U）中，如果X→Y，并且對于X的任何一個真子集X'，都有X'Y，則稱Y對X完全函數依賴，記作：XY。若X

Y，但Y不完全函數依賴于X，則稱Y對X部分函數依賴，記作：XY。定義3在R（U）中，如果X→Y，（Y不屬于X），YX，Y→Z，則稱Z對X傳遞函致依賴。3.1.2范式關系數據庫中的關系是滿足一定要求的，滿足不同程度要求的為不同的范式。滿足最低要求的叫第一范式。在第一范式中滿足進一步要求的為第二范式，其余以此類推。1．第一范式（1NF）第一范式是關系模式滿足所要遵循的最基本的條件，是所有范式的基礎，即關系中的每個屬性必須是不可再分的簡單項，不能是屬性組合。定義4如果關系模式R，其所有的屬性均為簡單屬性，即每個屬性都是不可再分的，則稱R屬于1NF。不滿足1NF條件的關系模式稱之為非規(guī)范化關系。在關系數據庫系統中只討論規(guī)范化的關系，凡非規(guī)范化關系模式必須化成規(guī)范化的關系。在非規(guī)范化的關系中去掉組金屬性和重復數據項，即讓所有的屬性均為原子項，就滿足1NF的條件，變?yōu)橐?guī)范化的關系。3.1.2范式【例3-1】

見表3-1，Employee表存儲了員工的基本信息。Employee表中的Salary（薪水）屬性列又細分為BasePay（基本工資）、Bonus（獎金）兩個列，所以不是1NF，更不是關系表。所有的關系表都必須符合1NF?？梢詫⒈?-1轉換為符合1NF的關系表，見表3-2。NameSexBirthdaySalaryBasePayBonus劉子峰男1975-12-1040001900趙凌莉女1980-06-1935001500NameSexBirthdayBasePayBonus劉子峰男1975-12-1040001900趙凌莉女1980-06-19350015003.1.2范式2．第二范式（2NF）定義5設有關系模式R是屬于1NF的關系模式，如果它的所有非主屬性都完全函數依賴于碼，則稱R是2NF的關系模式，記為R∈2NF?！纠?-2】

見表3-3，Student_Course表存儲了學生選修課程的信息。StudentIDNameCourseIDCourseName2014021224張?zhí)m婷202中國古代史2014002406劉雨航203世界史2014161336王峰宇102數據庫原理2014001203趙廣田101計算機網絡2014021268秦燕菲203世界史3.1.2范式Student_Course表的碼（即關鍵字）是StudentID和CourseID的屬性組合。對于非碼屬性Name來說，只函數依賴于StudentID，而不依賴于CourseID，所以不是2NF?？梢詫⒈?-3分解為兩個表，見表3-4和表3-5。經過分解后，這兩個關系的非主屬性都完全函數依賴于碼了，所以它們都是2NF。CourseIDCourseName101計算機網絡102數據庫原理202中國古代史203世界史StudentIDNameCourseID2014021224張?zhí)m婷2022014002406劉雨航2032014161336王峰宇1022014001203趙廣田1012014021268秦燕菲2033.1.2范式3．第三范式（3NF）定義6關系模式R<U，F>中若不存在這樣的碼X，屬性組Y及非主屬性Z（Z不是Y的子集），使得X→Y，(YX)Y→Z成立，則稱R<U，F>∈3NF。由定義可以證明，若R∈3NF，則每一個非主屬性既不部分依賴于碼，也不傳遞依賴于碼?！纠?-3】

見表3-6，Books表存儲了圖書的信息。BookIDTitleTypeIDTypeName201310225計算機網絡18計算機類201310079數據庫原理18計算機類201000205中國古代史06歷史類201300096世界史06歷史類201230328電磁學15物理類201450200藝術概論21藝術類201070201有機化學09化學類3.1.2范式Books表中的BookID為關鍵字，對于非碼屬性TypeID、TypeName來說，它們傳遞依賴于關鍵字，所以不是3NF?？梢詫⒈?-6分解為兩個表，見表3-7和表3-8。經過分解后，這兩個關系都不存在傳遞函數依賴關系，所以它們都是3NF。一個關系達到3NF后，基本解決了異常問題，但不能徹底解決數據冗余問題。BookIDTitleTypeID201310225計算機網據庫原國古代史06201300096世界史06201230328電磁術概論21201070201有機化學09TypeIDTypeName18計算機類06歷史類15物理類21藝術類09化學類3.1.2范式4．Boyce-Codd范式（BCNF）BCNF是由Boyce和Codd提出來的，通常認為BCNF是修正的3NF，有時也稱為擴充的3NF。定義7關系模式R<U，F>是1NF，若X→Y，且Y不是X的子集時，X必含有碼，那么稱R<U,F>是BCNF的模式?！纠?-4】

見表3-9，Student_Teacher_Course表存儲了學生選課的基本信息。StudentIDTeacherIDCourseID2014021224105061012201400240615252212320141613361362810533.1.2范式Student_Teacher_Course表中如果規(guī)定每位教師只教一門課，但一門課可以由多位教師講授。對于每門課，每位學生只由一位教師講授。即StudentID、CourseID函數依賴于TeacherID，TeacherID函數依賴于CourseID，StudentID、TeacherID函數依賴于CourseID，所以不是BCNF?？梢詫⒈?-9分解為兩個表，見表3-10和表3-11。經過分解后，這兩個關系都是BCNF。StudentIDTeacherID201402122410506201400240615252201416133613628StudentIDCourseID2014021224101220140024062123201416133610533.1.2范式5．第四范式（4NF）定義8關系模式R<U，F>∈1NF，如果對于R的每個非平凡多值依賴

，X都含有碼，則稱R<U，F>∈4NF?！纠?-5】

見3-12，Hobby表存儲了學生的愛好信息。StudentIDSportsFruit2014021224乒乓球

2014002406排球蘋果2014161336

桔子3.1.2范式Hobby表中，學號列為主關鍵字。但是學號與運動列、水果列是一個一對多的關系，使得表數據冗余，有大量的空值存在，并且不對稱，不是4NF。可以將表3-19分解為兩個表，見表3-13和表3-14。StudentIDFruit2014002406蘋果2014161336桔子StudentIDSports2014021224乒乓球2014002406排球3.1.2范式經過分解后，這兩個關系都是4NF。有關第五范式的知識本節(jié)不予介紹。其實關系的規(guī)范化就是將一個不規(guī)范的關系表分解為多個規(guī)范化的關系表的過程。關系規(guī)范化理論為數據庫設計提供了理論指南和工具，但這些指南和工具在結合應用環(huán)境和現實世界具體實施數據庫設計時應靈活掌握，并不是規(guī)范化程度越高，模式就越好。因為當規(guī)范化程度越高時，做綜合查詢時付出的做連接運算的代價越大。在實際設計關系模式時，分解進行到3NF就可以了。至于一個具體的數據庫關系模式設計要分解到第幾范式，應綜合利弊，全面衡量，依實際情況而定。3.2數據庫設計概述數據庫中的數據不是相互孤立的，數據庫在系統中扮演著支持者的角色。而通常把使用數據庫的各類信息系統都稱為數據庫應用系統。數據庫設計廣義的講，是數據庫及其應用系統的設計，即設計整個數據庫應用系統。狹義的講，就是設計數據庫本身。本書主要介紹狹義的數據庫設計。數據庫設計是指對于一個給定的應用環(huán)境，構造最優(yōu)的數據庫模式，建立數據庫，使之能夠有效地存儲數據，滿足各種用戶的應用需求。3.2.1數據庫設計的特點大型的數據庫的特點是數據量龐大、數據保存時間長、數據關聯比較復雜、用戶要求多樣化。因此，數據庫設計既是一項涉及多學科的綜合性技術，又是一項龐大的工程項目。1．數據庫設計人員應該具備的技術和知識要設計一個性能優(yōu)良的數據庫，數據庫設計人員應該具備的技術和知識包括數據庫的基本知識和數據庫設計技術，計算機科學的基礎知識和程序設計的方法和技巧，軟件工程的原理和方法，還應有相關應用領域的知識。2．數據庫設計的方法數據庫設計應該和應用系統設計相結合，也就是說，整個設計過程要把結構（數據）設計和行為（處理）設計密切結合起來，這是數據庫設計的特點之一。結構（數據）設計用于設計數據庫框架或數據庫結構，行為（處理）設計用于設計應用程序、事務處理等。數據庫設計有兩種不同的方法：1）以信息需求為主，兼顧處理需求，這種方法稱為面向數據的設計方法。2）以處理需求為主，兼顧信息需求，這種方法稱為面向過程的設計方法。3.2.1數據庫設計的特點3．數據庫設計的評定對于什么樣的數據庫是一個好的數據庫，事實上并沒有一個嚴格的、規(guī)范的標準來判定。因為每個數據庫都有其自身的用途，用途不同，設計角度就不同，設計方法也不同，最后的數據庫也不同。（1）好的數據庫特征一般，一個好的數據庫應該滿足以下特征：1）便于檢索所需要的數據。2）具有較高的完整性、數據更新的一致性。3）使系統具有盡可能良好的性能。（2）不好的數據庫特征有一些具體的特征可以幫助用戶判斷什么是設計得不好的數據庫。1）需要多次輸入相同的數據，或需要輸入多余的數據。2）返回不正確的查詢結果。3）數據之間的關系難以確定。4）表或列的名稱不明確。在數據庫的設計中，應盡量保證設計的數據庫具有好的特征，同時應盡量避免具有上述一些不好的特征。3.2.1數據庫設計的特點4．數據庫設計的基本規(guī)律數據庫設計具有3個基本規(guī)律。（1）反復性（Iterative）一個性能優(yōu)良的數據庫不可能一次性地完成設計，需要經過多次的、反復的設計。（2）試探性（Tentative）一個數據庫設計完畢，并不意味著數據庫設計工作完成，還需要經過實際使用的檢測。通過試探性的使用，再進一步完善數據庫設計。（3）分步進行（Multistage）由于一個實際應用的數據庫往往都非常龐大，而且涉及到許多方面的知識，所以需要分步進行，最終達到用戶的需要。3.2.2數據庫設計的步驟數據庫設計其實就是軟件設計，軟件都有軟件生存期。軟件生存期是指從軟件的規(guī)劃、研制、實現、投入運行后的維護，直到它被新的軟件所取代而停止使用的整個期間。數據庫設計方法有多種按照規(guī)范化設置的方法，考慮數據庫及其應用系統開發(fā)的全過程，通常將數據庫設計分為6個階段：需求分析階段、概念設計階段、邏輯設計階段、物理設計階段、數據庫實施階段、運行和維護階段。一個完善的數據庫應用系統不可能一蹴而就，而是上述6個階段的不斷反復。在設計過程中把數據庫的設計和對數據庫中數據處理的設計緊密結合起來，將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計。3.3需求分析階段需求分析就是分析用戶對數據庫的具體要求，是整個數據庫設計的起點和基礎。需求分析的結果直接影響以后的設計，并影響到設計結果是否合理和實用。需求分析階段是數據庫設計的第一步，也是最困難、最耗時的一步。需求分析就是理解用戶需求，詢問用戶如何看待未來的需求變化。讓用戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經常詢問用戶保證其需求仍然在開發(fā)的目的之中。了解用戶業(yè)務需求有助于在以后的開發(fā)階段節(jié)約大量的時間。同時還應該重視輸入/輸出，增強應用程序的可讀性。需求分析主要考慮“做什么”，而不考慮“怎么做”。需求分析的結果是產生用戶和設計者都能接受的需求說明書，作為下一步數據庫概念結構設計階段的基礎。3.4概念結構設計階段需求分析階段描述的用戶需求是面向現實世界的具體要求。將需求分析得到的用戶需求抽象為信息結構即概念模型的過程就是概念結構設計，是整個數據庫設計的關鍵。3.4.1概念結構設計的任務概念結構設計就是將需求分析得到的信息抽象化為概念模型。概念結構設計應該能真實、充分地反映現實世界，包括事物和事物之間的聯系，能滿足用戶對數據的處理要求。同時還要易于理解、易于更改，并易于向各種數據模型轉換。概念結構具有豐富的語義表達能力，能表達用戶的各種需求。不但反應現實世界中各種數據及其復雜的聯系，還應該獨立于具體的DBMS，易于用戶和數據庫設計人員理解。概念結構設計的工具有多種，其中最常用、最有名的就是E-R圖。概念結構設計的任務其實就是繪制數據庫的E-R圖。3.4.2概念結構設計的步驟概念結構設計分為3步，即設計局部概念模式、綜合成全局概念、評審。1．設計局部概念模式局部設計概念模式，即設計局部E-R圖的任務是根據需求分析階段產生的各個部門的數據流圖和數據字典中的相關數據，設計出各項應用的局部E-R圖。具體步驟為：1）確定數據庫需要的實體。2）確定各個實體的屬性（包括每個實體的主屬性）以及與實體的聯系。3）畫出局部E-R圖。例如，一個數據庫需要2個實體，每個實體都有自己的屬性（包括主屬性），如圖所示。3.4.2概念結構設計的步驟2．綜合成全局概念全局設計概念模式，即將局部E-R圖根據聯系，綜合成一個完整的全局E-R圖。具體步驟為：1）確定各個實體之間的聯系。哪些實體之間有聯系，聯系類型是什么，需要根據用戶的整體需求來確定。2）畫出聯系，將局部E-R圖綜合。例如，將局部E-R圖聯系起來，綜合成一個完整的全局E-R圖。結果如圖所示。3.4.2概念結構設計的步驟3．評審將局部E-R圖根據聯系，綜合成一個完整的全局E-R圖，這并不是只是簡單的整合，還需要評審。評審哪些數據或聯系冗余，將冗余數據與冗余聯系加以消除。在整合時，哪些數據冗余，哪些聯系冗余，也需要根據用戶的整體需求來確定?？傊涍^評審，消除屬性沖突、命名沖突、結構沖突、數據冗余等，最終形成一個全局E-R圖。3.5邏輯結構設計階段概念結構設計是獨立于任何一種數據模型的信息結構。而邏輯結構設計的目的是把概念設計階段設計好的基本E-R圖轉換為與選用的具體機器上的DBMS所支持的數據模式相符合的邏輯結構（包括數據庫模式和外模式）。3.5.1邏輯結構設計的任務邏輯結構設計的任務就是把概念結構設計好的基本E-R圖轉換為與指定DBMS產品所支持的數據模型相符合的邏輯結構。從理論上講，設計邏輯結構應該選擇最適用于相應概念結構的數據模型，然后對支持這種數據模型的各種DBMS進行比較，從中選出最合適的DBMS。但實際情況往往是用戶已經指定好了DBMS，而且現在的DBMS一般都是RDBMS，所以數據庫設計人員沒有什么選擇余地。數據庫設計人員只有按照用戶指定的RDBMS，將概念結構設計的E-R圖轉換為符合RDBMS的關系模型。3.5.2邏輯結構設計的步驟邏輯結構設計一般分為以下兩個步驟。1．將E-R圖轉換為關系模型將E-R圖轉換為適當的模型。由于現在常用的DBMS都是基于關系模型的關系數據庫，所以，通常只需要將E-R圖轉換為關系模型即可。將E-R圖轉換為關系模型一般應遵循的原則是：一個實體轉換為一個關系模式，實體名轉換為關系名，實體屬性轉換為關系屬性。由于實體之間的聯系分為一對一、一對多和多對多3種，所以實體之間的聯系轉換時，則有不同的情況：1）一個一對一聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。如果與某一端實體對應的關系模式合并，則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。2）一個一對多聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。合并轉換規(guī)則與一對一聯系一樣。3）一個多對多聯系轉換為一個獨立的關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。3.5.2邏輯結構設計的步驟三個或三個以上實體間的一個多元聯系可以轉換為一個關系模式，但是較為復雜。原則上合并碼相同的關系模式。這一階段還需要設計外模式，即用戶子模式。根據局部應用需要，結合具體DBMS的特點，設計用戶子模式。利用關系數據庫提供的視圖機制、目標，方便用戶對系統的使用（例如命名習慣、常用查詢），滿足系統對安全性的要求（例如安全保密）。例如，將圖3-2的E-R圖轉換為關系模型：關系A（X，Y，Z）關系B（M，N）關系C（K，L）3.5.2邏輯結構設計的步驟2．數據模型優(yōu)化數據庫的邏輯設計的結果不是惟一的。為了進一步提高數據庫應用系統的性能，還應該根據應用需求適當地修改、調整數據模型的結構。這就是數據模型優(yōu)化。規(guī)范化理論為數據庫設計人員提供了判斷關系模式優(yōu)劣的理論標準。3．數據庫命名規(guī)則在概念結構設計階段，實體和屬性的命名，可以比較隨意。而在邏輯結構設計階段，關系和屬性要求盡量規(guī)范化命名。通常，盡量不用漢字，最好采用有意義的英文來命名。可以是全拼，也可以是縮寫，也可以是連寫，通常第一個單詞的字母都大寫。本書對數據庫以及數據庫對象等都使用有意義的英文全拼來命名。數據庫名全用大寫，表名、列名等對象名的第1個字母大寫。3.6物理結構設計階段物理結構設計階段用于為邏輯模型選取一個最適合應用環(huán)境的物理結構，包括數據庫在物理設備上的存儲結構和存取方法。3.6.1物理結構設計的任務物理結構設計根據具體DBMS的特點和處理的需要，將邏輯結構設計的關系模式進行物理存儲安排，建立索引，形成數據庫內模式。設計人員都希望自己設計的數據庫物理結構能滿足事務在數據庫上運行時響應時間少、存儲空間利用率高和事務吞吐率大的要求。為此，設計人員需要對要運行的事務進行詳細分析，獲得所需的參數，并全面了解給定的DBMS的功能、物理環(huán)境和工具。3.6.2物理結構設計的步驟物理結構設計通常分為兩步：1．確定數據庫的物理結構根據具體DBMS的特定要求，將邏輯結構設計的關系模式轉化為特定存儲單位，一般是表。一個關系模式轉換為一個表，關系名轉換為表名。關系模式中的一個屬性轉換為表中的一列，關系模式中的屬性名轉換為表中的列名。為了提高物理數據庫讀取數據的速度，還可以設置索引等。為了保證物理數據庫的數據完整性、一致性，還可以設置完整性約束等。2．對物理結構進行評價數據庫物理結構設計的過程中，需要確定數據存放位置、計算機系統的配置等，還需要對時間效率、空間效率、維護代價和各種用戶需求進行權衡，其結果也可以產生多種方案。數據庫設計人員必須從中選擇一個較優(yōu)的方案作為物理數據庫的物理結構。3.7數據庫實施階段1．定義數據庫結構確定了數據庫的邏輯結構與物理結構后，就可以用所選的DBMS提供的數據定義語言（DDL）來嚴格描述數據庫的結構。2．組織數據入庫數據庫結構建立好后，就可以向數據庫中裝載數據了。組織數據入庫是數據庫實施階段最主要的工作。數據入庫可以人工入庫，也可以計算機輔助入庫方式。3．編制與調試應用程序數據庫應用程序的設計應該與數據設計并行進行。當數據庫結構建立好后，就可以開始編制與調試數據庫的應用程序，也就是說，編制與調試應用程序是與組織數據入庫同步進行的。4．數據庫試運行應用程序調試完成，并且已有一小部分數據入庫后，就可以開始數據庫的試運行。試運行需要對數據庫進行功能測試和性能測試。如果功能或性能測試指標不能令用戶滿意，需要進行局部修改，有時甚至需要返回邏輯設計階段，重新調整或設計。3.8數據庫運行和維護數據庫試運行合格后，數據庫開發(fā)工作就基本完成，即可以投入正式運行了。數據庫投入運行標志著開發(fā)任務的基本完成和維護工作的開始。由于應用環(huán)境在不斷變化，數據庫運行過程中物理存儲會不斷變化，因此，對數據庫設計進行評價、調整、維修等維護工作時一個長期的任務，也是設計工作的繼續(xù)和提高。在數據庫運行階段，對數據庫還要進行經常性的維護，維護工作主要由DBA完成。這一階段的工作主要包括數據庫的轉儲和恢復，數據庫的安全性、完整性控制，數據庫性能的監(jiān)督、分析和改進，數據庫的重組織和重構造等。3.9數據庫設計實例本節(jié)以兩個簡單的數據庫學生成績管理和圖書出版管理數據庫為例，介紹數據庫設計的具體方法。3.9.1學生成績管理數據庫設計按照數據庫設計的6個階段，設計步驟如下：1．需求分析階段學生成績管理數據庫是一個用來管理學生成績的數據庫，必須滿足學校對學生成績管理工作的需求。既然是管理學生成績的數據庫，那么學生、學院、課程等信息是必不可少的。學生擁有學號、姓名、性別、出生日期、所屬學院編號等特征，學院擁有學院號、學院名稱等特征，課程也擁有課程號、課程名、學分等特征，以及每個學生每門課程的成績信息。3.9.1學生成績管理數據庫設計2．概念結構設計階段首先，根據需求分析得出，該系統應該包括學生、學院、課程、成績4個實體。學生實體有學號、姓名、性別、出生日期、學院號等屬性，學號為主屬性。學院實體有學院號、學院名等屬性，學院號為主屬性。課程實體有課程號、課程名、學分等屬性，課程號為主屬性。成績實體有學號、課程號、分數等屬性，學號、課程號為主屬性。然后畫出局部E-R圖，即每個實體的E-R圖。如圖所示。3.9.1學生成績管理數據庫設計再根據全局設計概念模式，將局部E-R圖綜合成一個完整的全局E-R圖。學生實體和成績實體之間有聯系，學生實體和學院實體之間有聯系，課程實體和成績實體之間有聯系。由于各個實體屬性比較多，所以全局E-R圖只聯系實體。如圖所示。3.9.1學生成績管理數據庫設計3．邏輯結構設計階段將圖3-4的E-R圖轉換為關系模型并規(guī)范命名如下：學生（學號，姓名，性別，出生日期，學院編號）學院（學院編號，學院名）課程（課程號，課程名，學分）成績（學號，課程號，分數）4．物理結構設計階段將邏輯結構設計的關系模型轉換為物理數據庫，即具體的數據庫管理系統中支持的關系數據模型——表。本書使用的是SQLServer2012數據庫管理系統，所以在SQLServer2012中創(chuàng)建“學?！睌祿?，在該數據庫中創(chuàng)建學生表、學院表課程表、成績表。同時還要對表設置完整性約束，創(chuàng)建索引等。3.9.1學生成績管理數據庫設計5．數據庫實施階段在SQLServer2012中創(chuàng)建表后，向表中添加數據。然后使用T-SQL語言對數據庫進行操作。再選擇其他數據庫開發(fā)工具或語言（例如VB、C#等）設計數據庫應用程序。數據庫應用程序的設計應該與數據設計并行進行。6．數據庫運行和維護階段最終完成數據庫的設計后，交付用戶，進行售后服務，并繼續(xù)對數據庫進行維護、調整。3.9.2圖書出版管理數據庫設計按照數據庫設計的6個階段，設計步驟如下：1．需求分析階段圖書出版管理數據庫是一個出版社用來管理出版的圖書的數據庫，必須滿足出版社對作者信息、圖書信息、圖書類型等管理。作者信息應該包括作者編號、姓名、性別、出生日期、所在省市等特征，圖書信息應該包括圖書編號、圖書名、該本書作者信息、單價、圖書類型等特征，圖書類型信息應該包括圖書類型編號、類型名等特征。3.9.2圖書出版管理數據庫設計2．概念結構設計階段首先，根據需求分析得出，該系統應該包括作者、圖書、圖書類型3個實體。作者實體有作者編號、姓名、性別、出生日期、所在省市等屬性，作者編號為主屬性。圖書實體有圖書編號、圖書名、該本書作者信息、單價、圖書類型等屬性，圖書編號為主屬性。圖書類型實體有圖書類型編號、類型名等屬性，圖書類型編號為主屬性。然后畫出局部E-R圖，即每個實體的E-R圖。如圖所示。3.9.2圖書出版管理數據庫設計再根據全局設計概念模式，將局部E-R圖綜合成一個完整的全局E-R圖。作者實體和圖書實體之間有聯系，圖書實體和圖書類型實體之間有聯系。如圖所示。3.9.2圖書出版管理數據庫設計3．邏輯結構設計階段將圖3-6的E-R圖轉換為關