179.關係數據庫設計技術(需求分析、設計、實施、運行、維護)

 

1.概述

數據庫設計是指在現有的應用環境下，從創建問題的概念模型開始，逐步創建和優化問題的邏輯模型，最後創建其高效的物理模型，並據此創建數據庫及其應用系統，使之可以有效地收集、存儲和管理數據，知足用戶的各類應用需求。

數據庫設計最終目的：（1）知足用戶的需求；（2）簡化應用程序的編程設計，實現系統協同、高效的開發，減小開發成本。

數據庫設計步驟：系統需求分析、概念結構設計、邏輯結構設計、物理結構設計、數據庫實施、數據庫系統運行和維護。

各步驟的前後關係如圖3.1所示。其中，對每個步驟，若是設計結果不知足要求，都有能夠返回前面的任一步驟，直到知足要求爲止。

 

 

 

2. 需求分析

需求分析是瞭解用戶需求、而後明確用戶需求、最後造成需求文字表達（需求分析說明書）的一個過程。需求分析的最終結果就是造成一份有效的需求分析說明書。

2.1 系統調研過程

系統調研也稱項目調研，即把系統開發看成項目來運做，其主要目的是經過接觸用戶以瞭解並最終明確用戶的實際需求。這個過程是一個系統分析人員理解和掌握用戶業務流程的過程，是一個須要不斷與用戶進行溝通和磋商的過程。系統調研方法比較靈活，因人、因系統而異。大體過程能夠分爲如下幾個步驟來完成：

 

　　充分了解項目背景以及開發的目的。

　　深刻用戶單位（指使用該系統的機構和組織）進行調查。包括瞭解單位的組織結構、運做方式，瞭解各部門的職責和功能。而後從數據流的角度分析各個部分的特性以及它與其餘部門之間的關係，如各部門的輸入（輸出）數據及其格式是什麼，這些數據來自哪裏、去向何方等，並做相應的記錄。

這個步驟是調查的重點，並且難度比較大，難點在於如何創建與用戶理性的溝通渠道。用戶與系統分析人員通常都具備不一樣的技術背景，因此常常致使這種狀況的出現：用戶認爲已經說清楚了的東西而分析人員也許對之還不能理解，或者用戶提出的要求太高，超出了計算機可以處理的範圍等。當出現這種狀況時，須要分析人員不斷的詢問或說明，久了就會致使用戶的厭倦。在進行這項調查前分析人員應該作好充分的準備，例如擬好調查方案、設計合理而簡潔的調查表等。

 

給出了一種調查方法，可供讀者參考和選用：

單位狀況及其運做方式的介紹。

對部門工做職能的深刻了解。

召開調查會。

若是與用戶尚未就需求達成共識，相關分析人員可有選擇地重複②和③步。

 

　　肯定用戶需求、明確系統功能和邊界。綜合各個分析人員的調查結果，造成系統的功能說明，肯定哪些功能是系統要實現的，哪些是不該該實現的，或者是不能實現的。全部這些結果都應該跟用戶確認後予以書面形式肯定下來。

 

 

2.2 需求分析的方法

2.2.1 SA方法

針對數據庫設計，造成用戶需求的有效表達，這種表達在說明書中多以數據流圖、數據字典等形式來描述。

爲創建用戶需求的表達，能夠採用多種分析方法來完成。這些方法主要包括自頂向下和自底向上兩種方法，其中常採用的方法是自頂向下的結構化分析方法（SA, structured analysis）。

SA方法的分析過程符合人類對問題的認識並最終解決的通常過程，其分析過程簡單、實用，現已在衆多領域中獲得應用。

SA特色能夠歸結爲一棵樹的產生過程：先建立樹根，而後建立樹根節點的子節點，接着建立各子結點的子節點，直到建立全部的樹葉節點爲止。在這棵樹中，樹根節點至關於整個系統（第一層次上的系統），其子節點至關於第二層次上的系統，…，最後層次上的系統由葉子節點表示，它對系統分析人員是可認知的（認爲已經清楚而沒必要再分解了）。自頂向下的SA方法是從整個系統開始，採用逐層分解的方式對系統進行分析的方法。

 

 

2.2.2 數據流圖（data flow diagram）

SA方法只是對問題分析的一種思想，在具體的分析過程當中還須要藉助其餘的分析工具，這樣才能完成對分析過程和結果的記錄、對用戶需求的表達等，數據流圖就是最爲經常使用的輔助分析工具和描述手段。

數據流圖是以圖形的方式來刻畫數據處理系統中信息的轉變和傳遞過程，是對現實世界中實際系統的一種邏輯抽象表示，但又獨立於具體的計算機系統。

 

數據流圖常採用的符號：

數據流

數據流是流動中的數據。因此數據流圖是用有方向的曲線或直線來表示，用前頭表示數據流的方向，其旁邊標以數據流的名稱，其格式以下：

 

 

 

數據流名不是隨意取的，它可以簡要地歸納數據流的含義，且易於理解。下文提到的數據名、加工名、文件名等都有一樣的要求。

數據流能夠來自數據的源點、加工和數據文件，能夠流向數據的終點、加工和數據文件。當數據取自文件或者流向文件時，相應的有向直線或曲線能夠不命名，由於從相應的文件中便可知道流動的是什麼數據。

 

數據的源點和終點

系統中的數據是來自系統之外的其餘數據對象，其最終的流向也是系統之外的有關數據對象。

這種向系統提供數據的數據對象統稱爲系統的數據源點，而系統數據所流向的數據對象則統稱爲數據終點。這兩個概念的引入是爲了幫助用戶對系統接口界面的理解。

在數據流圖中，數據源點和數據終點都是用方框來表示，方框中標以數據的名稱。其格式以下：

 

 

加工

加工是對數據處理的一個抽象表示。若是這種「加工」還不爲系統分析員所理解，則須要SA方法對其進行分解，直到所獲得的加工已經足夠簡單、沒必要再分時爲止。這時的加工也稱爲基本加工。在數據流圖中，加工是用圓圈（或橢圓）表示，圓圈標以加工的名稱。其格式以下：

 

數據文件

數據文件是表示數據臨時存放的地方，「加工」可以對其進行數據讀取或存入。在數據流圖中，數據文件一般用平行的雙節線表示，旁邊標以數據文件名。其格式以下：

 

　　對於數據流圖中的一個節點，可能有幾條表示數據流的有向線出自或指向該節點。該節點對數據流的影響方式（流出狀況）或這幾股數據流對該節點的做用方式是有多種的。這種影響和做用方式說明如表3.1所示。

 

 

2.2.3基於數據流圖的SA方法

自頂向下的SA分析方法能夠與數據流圖有機地結合起來，將對系統的分析過程和結果形象地表示出來。

在數據流圖中，SA分析方法主要體如今對「加工」進行分解的過程。對數據流圖的繪製和分解過程就是用戶需求的分析及其表達的造成過程。

一個系統的數據流圖是由多個子圖構成，若是加上子圖之間的分解關係，就能夠造成一棵樹。但因爲全部的子圖經過表示分解關係的邊連在一塊兒而造成的樹將是很龐大的，沒法在同一平面中畫出，因此在繪製數據流圖時要分爲多個子圖來畫。

繪製的原則通常是，先繪製樹根節點對應的子圖，而後繪製根節點的子節點所對應的子圖，一直繪製到全部葉子節點對應的子圖爲止。

 

 

下面以某中石化集團的樣品分析管理系統（一個子系統）的開發爲例，介紹數據流圖的基本繪製方法。

1）繪製根節點圖。從加工粒度上看，根節點圖（即根節點對應的數據流圖）是最大的數據流圖，它是將整個應用系統看成一個加工。

【例子】 對於樣品分析管理系統（YPFXMS），其根節點子圖如圖3.2所示。

 

2）繪製子節點圖。數據流圖的根節點不提供任何有用的信息，須要對加工「樣品分析管理系統」做進一步的分解。在調研中發現，不是每一種樣品都須要分析的，可以分析的是那些已經有計算公式或分析方案的樣品，並且送樣（被送用於分析的樣品）要先存在樣品分析員那裏，樣品分析員則按照某一個原則一次對這些送樣進行分析。在送樣被分析，還須要對分析的結果進行檢查，若是發現分析結果不合格（是指分析手段和方法出錯）則返回給樣品分析員從新進行分析，分析合格則返回給送樣人員。因而，分解後獲得如圖3.3所示的數據流圖。

 

 

 

 

2.2.4 造成數據字典

數據流圖主要是表示數據和處理之間的關係，但缺少對數據流、數據文件、加工等圖中各個元素進行描述的能力。

數據流圖是將用戶頭腦中的須要轉化爲機器可以接受的表達的一箇中轉站，但數據流圖表示的信息離機器可以接受的信息還比較遠。若是把用戶需求和機器表示放在兩頭，數據流圖放在二者之間，那麼數據流圖更靠近用戶需求一些，而相對遠離機器表示。

須要引入數據字典的概念，經過數據字典能夠增強數據流圖的信息表達能力，同時這種表達拉近了與機器表示的距離，使得用戶需求從純粹的邏輯表達逐步轉向機器表示，爲數據庫的實施奠基基礎。

與數據流圖同樣，數據字典也是SA方法中一種有力的工具。數據字典與數據流圖結合使用，主要是用於對數據流圖中出現的各類元素進行描述，給出全部數據元素的邏輯定義。數據字典是數據流圖中數據元素的描述。這種描述是由一系列的條目組成，但不一樣的應用、不一樣的系統其組成的條目可能有所不一樣。至少應該包括數據流、數據文件、加工和數據項等四種條目。

 

數據項條目

     數據項是數據構成的最小組成單位，它不能再分割。數據項條目用於說明數據項的名稱、類型、長度、取值範圍等。

    例如，在課題管理系統中數據項「課題申請代碼」條目可描述以下：

數據項名：課題申請代碼

類型：字符型

長度：12

取值範圍：000000000000～999999999999

取值說明：前4爲年號，第5到第6位、第7到第8位分別表示月份和日期，後4位表示     當天的課題序號

 

數據流條目

    數據流條目主要用於說明數據流的組成（由哪些數據項組成），數據流的來源和流向以及數據流量等信息。

    例如，數據流「樣品分析請求信息」條目描述以下：

數據流名稱：樣品分析請求信息

組成：申請表編號、申請表名稱、分析項目代碼、樣品編號、

            樣品名稱、送樣日期、送樣人員

來源：記錄送樣信息（加工）

去向：樣品分析請求信息（文件）

流量：10～20/天天

 

數據文件條目

    數據文件條目用於說明數據文件是由哪些數據項組成，組織方式、存儲頻率如何等信息。

例如，數據文件「一審合格實驗信息」條目以下：

文件名：一審合格實驗信息

數據組成：試驗記錄表編號、試驗記錄表名稱、試驗日期、試驗環境、試驗目的、     操做人員、原料規格、試驗配方與工藝、操做過程與現象、

                                  試驗結果與討論、記錄人員、試驗組長、課題代碼

組織方式：按試驗記錄表編號遞增排列

存儲頻率：1次/天

 

加工條目

    加工條目主要用於說明加工的邏輯功能、指明輸入數據和輸出數據等信息。其中邏輯功能項用於指出該加工用來作什麼、對加工處理的一些要求等。

       例如，

加工編號：1

加 工 名：記錄送樣信息

輸入數據：樣品數據

輸出數據：樣品分析請求信息

邏輯功能：對送檢的樣品數據進行登記，並由此轉化成樣品分析請求信息。

 

 

3. 數據庫結構設計

3.1 概念結構設計

3.1.1概念結構定義

　　需求分析的成果是數據流圖和數據字典，概念結構設計的目的就是將抽象轉化爲信息世界中基於信息結構表示的數據結構——概念結構，即概念結構是用戶需求在信息世界中的模型。

　　數據庫的概念結構獨立於它的邏輯結構，更與數據庫的物理結構無關。它是現實世界中用戶需求與機器世界中機器表示之間的中轉站。它既有易於用戶理解、實現分析員與用戶交流的優勢，也有易於轉化爲機器表示的特色。當用戶的需求發生改變時，概念結構很容易做出相應的調整。因此，概念結構設計是數據庫設計的一個重要步驟。

　　概念模式描述的經典工具是E-R圖，由E-R圖表示的概念模型就是所謂的E-R模型。E-R模型的建立和設計過程就是概念結構的建立和設計過程，概念結構的設計集中體現爲E-R模型的設計。

E-R模型的優勢：

　　它具備較強的表達能力，能夠充分表示各類類型數據及數據之間的聯繫；

　　數據表達形式簡單，沒有過多的概念，定義嚴格，無二義性等；

　　E-R模型是以圖形的形式出現，表示直觀。

 

 

3.1.2設計思想

　　四種概念結構的設計指導思想：

自頂向下：首先根據用戶需求定義全局概念結構的E-R模型，而後對其分解，逐步細化。

自底向上：首先根據各個部門的需求定義局部概念結構的E-R模型，而後將這些局部的E-R模型並接成爲全局的E-R模型，造成全局概念結構。

先主後次：分析各類子須要的「輕重」，首先設計最重要的概念結構，造成它的E-R模型，而後定義次要概念結構的E-R模型，接着按照相似的方法定義其餘全部概念結構的E-R模型，最後將這些模型繼承起來，造成全局概念結構。

上下混合：這是指將自頂向下和自底向上這兩種方法結合起來使用的一種設計方法。

 

　　概念結構設計一般採用的是自底向上的設計方法（而需求分析通常是採用自頂向下的方法），即這種方法分爲兩步：

• 　　先創建局部概念結構的E-R模型；
• 　　而後將全部的局部E-R模型集成起來造成全局概念結構。

 

如下主要介紹這種自底向上的概念結構設計方法：

步驟一： 局部E-R模型的設計

　　E-R模型的設計基於需求分析階段產生的數據流圖和數據字典來進行。一個系統的數據流圖是按分層來繪製，是由多張數據流圖構成。基於一張數據流圖及其對應的數據字典部分進行的E-R模型設計獲得的是一個局部概念。

實體和實體間聯繫的劃分並沒有統一的標準，通常採用的劃分原則是，先是憑經驗，後再做調整。

　　經驗是指在通常狀況下對於那些具備共同特徵和行爲的對象，能夠將之抽象爲實體；對象的共同特徵和行爲能夠抽象爲實體的屬性。

　　調整是指在憑經驗做出抽象後，根據具體的應用和建模環境對實體與其屬性之間的關係以及實體與實體之間的關係做出相應的更改，有可能使得原來的屬性變爲實體，原來是實體的變爲屬性等，從而也致使了實體間關係的改變。

 

實體及實體間關係的抽象注意如下三點：

   （1）在同一應用環境中，被抽象爲屬性的事物就不能再被抽象爲實體了，不然會致使「屬性又包含屬性」的錯誤，這違反第一範式；

   （2）屬性具備不可再分性，因此具備不可再分性的事物通常都應抽象爲屬性，而具備可再分性的事物通常不能抽象爲屬性；

   （3）一個事物不能同時被抽象爲兩個實體的屬性，即一個屬性只能隸屬於一個實體。

 

【例子】  對於一個企業信息管理系統來講，企業中的工做人員能夠抽象爲「職工」實體，而工做人員的姓名、性別、年齡、職稱、所在部門等能夠抽象爲「職工」實體的屬性，如圖3.4所示。

 

 

【例子】  若是在這個系統中除了「職工」信息之外還須要考慮部門的一些信息，如部門的名稱、人數、經理、位置等信息，那就應該對前面的抽象做調整：應該將「部門」由原來做爲「職工」的屬性改成一個新的實體——「部門」實體，同時原來做爲屬性的「部門」被刪除（這避免了一個事物既做爲屬性又做爲實體的狀況出現）。這兩個實體的關係是「部門」擁有「職工」（或者「職工」隸屬於「部門」），即「擁有」是這兩個實體之間的聯繫。這樣，原來的E-R圖進一步獲得調整和擴充，如圖3.5所示。

 

 

從需求分析中發現，部門中的職工所作的工做是開發項目，用於說明項目的信息包括項目名稱、項目性質、項目開發的起始時間、項目經費、項目經理等。將項目抽象爲實體，造成「項目」實體，其E-R圖如圖3.6所示。

 

 

步驟二：全局E-R模型的集成

相對於一個總體而言，以上是E-R局部圖，這些E-R圖應該可以合成一張總的E-R圖。對概念結構來講，就是將局部概念結構集成爲全局的概念結構。

【例子】 根據需求分析結果，在這個企業中每一個部門都有承接多個項目的可能，每一個職工只參加一個項目。將圖3.5和圖3.6所示的E-R圖並接起來，結果獲得了整個系統的E-R圖，如圖3.7所示。

 

 

　　局部E-R圖的並接過程當中產生許多問題，這些問題主要體現爲各個局部E-R圖之間的衝突，其中包括命名衝突、屬性衝突和結構衝突等。

• 命名衝突

命名衝突是指意義不一樣的元素在不一樣的局部E-R圖中有相同的名字，或者是有相贊成義的元素在不一樣的局部E-R圖中具備不相同的名字。

• 屬性衝突

 屬性衝突是指同義同名的屬性在不一樣的局部E-R圖中的取值類型、範圍、所使用的單位等卻徹底不同。

  【例子】 有的將職工編號定義爲長度爲12個字節的字符串類型，有的則定義爲8個字節的字符串類型，有的可能將職工編號定義爲整型。

在一個E-R圖中不該該存在屬性衝突。

• 結構衝突

結構衝突是指一個事物在一個局部E-R圖被抽象爲實體，而在另外一個局部E-R圖中又被抽象爲屬性。

　　這不能直接將這兩個局部E-R圖並接爲一個E-R圖，首先要解決結構衝突問題。解決的辦法是，視具體狀況將相應的屬性改成實體，或者將相應的實體改成屬性。

　　還有一種結構衝突是相同的實體在不一樣的局部E-R圖中有不一樣的屬性或不一樣的聯繫。對於前一種狀況，一種簡單的解決方法是：使該實體的屬性集爲它在各E-R圖中的屬性集的並；對於後一種狀況，解決方法相對複雜，要視具體狀況對聯繫進行分解，或者進行其餘的調整。

 

　　在構建的E-R圖中，最好不要包含環形結構，由於這容易出現「死循環」參照關係。

【例子】 假設實體X、Y和Z以及它們之間的聯繫a、b和c構成如圖3.8所示的E-R圖，則該E-R圖出現「死循環」問題，由於在據此圖創建數據表時，將出現X參照Y、Y參照Z、Z參照X的「死循環」參照關係，從而沒法建立數據表。所以，若是一個E-R圖包含環形結構，則須要進一步確認對概念結構的建模是否正確？從新修改E-R圖，或者直接將環中的一條邊（關聯）去掉，以破壞「死循環」結構。

 

 

 

3.1.3步驟 

　　概念結構設計中，實體集中的實體彼此是可區別的。若是實體集中的屬性或最小屬性組合的值能惟一標識其對應實體，則將該屬性或屬性組合稱爲碼。對於每個實體集，可指定一個碼爲主碼。

　　若是用矩形框表示實體集，用帶半圓的矩形框表示屬性，用線段鏈接實體集與屬性，當一個屬性或屬性組合指定爲主碼時，在實體集與屬性的鏈接線上標記一斜線，則能夠用圖1.4描述學生成績管理系統中的實體集及每一個實體集涉及的屬性。

 

 

圖1.4 學生和課程實體集屬性的描述   其中 \主鍵

1．一對一的聯繫（1 : 1）
A中的一個實體至多與B中的一個實體相聯繫，B中的一個實體也至多與A中的一個實體相聯繫。例如，「班級」與「正班長」這兩個實體集之間的聯繫是一對一的聯繫，由於一個班級只有一個正班長，反過來，一個正班長只屬於一個班級。「班級」與「正班長」兩個實體集的E-R模型如圖1.5所示。

 

 

2．一對多的聯繫（1 : n）
A中的一個實體能夠與B中的多個實體相聯繫，而B中的一個實體至多與A中的一個實體相聯繫。例如，「班級」與「學生」這兩個實體集之間的聯繫是一對多的聯繫，由於，一個班級可有若干學生，反過來，一個學生只能屬於一個班級。「班級」與「學生」兩個實體集的E-R模型如圖1.6所示。

 

 

 

 

3．多對多的聯繫（m : n）
A中的一個實體能夠與B中的多個實體相聯繫，而B中的一個實體也可與A中的多個實體相聯繫。例如，「學生」與「課程」這兩個實體集之間的聯繫是多對多的聯繫，由於，一個學生可選多門課程，反過來，一門課程可被多個學生選修。「學生」與「課程」兩個實體集的E-R模型如圖1.7所示。

 

注意：實體圖ER圖能夠分開

 

 

 

 

 

3.2 邏輯結構設計

數據庫的邏輯結構設計就是將以E-R圖表示的概念結構轉換爲DBMS支持的數據模型並對其進行優化的過程。

概念結構是由E-R圖來描述的，概念結構到關係模型的轉換能夠歸結爲E-R圖到關係模型的轉換問題。E-R圖的基本元素是實體、屬性和聯繫等，因而E-R圖到關係模型的轉換就變成了實體、屬性和聯繫等基本元素到關係模式的轉化問題。

 

 

1. 實體和屬性的轉變

這種轉變比較簡單、直觀，即一個實體轉化爲一個關係模式，其中實體名變成了關係模式的名稱，實體屬性相應地變成了關係的屬性。

 【例子】 圖3.7中的三個實體分別轉化爲如下三個關係模式：

項目（編號，名稱，經理，性質，啓動時間，結題時間，經費）

部門（編號，名稱，經理，人數，地址）

職工（編號，姓名，性別，職稱，年齡）

 

 

2. （1:1）聯繫的轉變

一對一聯繫的轉變：建立一個獨立的關係模式，該關係模式的屬性是由該聯繫自己的屬性以及與之相連的實體的候選碼（每一個實體中取一個候選碼）組成。

 

1 : 1聯繫的E-R圖到關係模式的轉換

1∶1的聯繫既可單獨對應一個關係模式，也能夠不單獨對應一個關係模式。

能夠放在一個裏，不用單建表
（1）聯繫單獨對應一個關係模式，則由聯繫屬性、參與聯繫的各實體集的主碼屬性構成關係模式，其主碼可選參與聯繫的實體集的任一方的主碼。
例如，對於圖1.5描述的「班級（BJB）」與「正班長（BZB）」實體集經過屬於（SYB）聯繫E-R模型，可設計以下關係模式（下橫線表示該字段爲主碼）：
BJB（班級編號，院系，專業，人數 ）
BZB（學號，姓名）
SYB（學號，班級編號）

（2）聯繫不單獨對應一個關係模式，聯繫的屬性及一方的主碼加入另外一方實體集對應的關係模式中。
例如，對於圖1.5描述的「班級（BJB）」與「正班長（BZB）」實體集經過屬於（SYB）聯繫E-R模型，可設計以下關係模式：
BJB（班級編號，院系，專業，人數）
BZB（學號，姓名，班級編號）
或者
BJB（班級編號，院系，專業，人數，學號）
BZB（學號，姓名）

 

【例子】 一個倉庫僅由一個倉庫管理員管理，而一個倉庫管理員也只能管理一個倉庫，因此倉庫管理員和倉庫之間的聯繫是管理，管理時間爲8小時（一天），其E-R圖如圖3.9所示。

 

 

「倉庫管理員」和「倉庫」之間的聯繫是（1:1），該聯繫轉換後造成以下的關係模式：管理（管理員編號，倉庫編號，時間）

管理員編號和倉庫編號分別爲「倉庫管理員」實體和「倉庫」實體的候選碼，時間是「管理」聯繫的屬性。

 

 

有時候爲了減小數據冗餘，能夠將聯繫對應的關係合併到與之相連的某一個實體對應的關係中去。

方法：將一個實體的候選碼以及聯繫的屬性添加到另外一個實體對應的關係中。

 【例子】 對於以上例子，易知「倉庫管理員」實體對應的關係以下：

倉庫管理員（管理員編號，姓名）

咱們只需將「倉庫」實體的候選碼「倉庫編號」以及聯繫的屬性「時間」一塊兒添加到倉庫管理員關係中便可，從而實現對聯繫「管理」的轉換，結果獲得的關係模式以下：

             倉庫管理員（管理員編號，姓名，倉庫編號，時間）

也能夠將「倉庫管理員」的候選碼和聯繫的屬性「時間」一塊兒添加到倉庫關係中，結果獲得以下的關係模式：

            倉庫（倉庫編號，倉庫規模，管理員編號，時間）

聯繫能夠合併到任意與之相連的實體對應的關係中。但在實際應用，每每從效率的角度來考慮如何進行合併。

 

 

 

3.（1:n）聯繫的轉變

一對多聯繫能夠轉化爲一個獨立的關係模式，也能夠將聯繫合併到n端對應的關係模式中。

能夠放在一個裏，不用單建表

 【例子】 對於圖3.7所示的E-R圖，「擁有」聯繫是一對多聯繫，當把這個聯繫轉化爲獨立的關係模式時，則獲得以下的關係模式：

擁有（職工.編號，部門.編號）  

用合併的方法對該聯繫進行轉換，則獲得以下的關係模式：

職工（職工.編號，姓名，性別，年齡，職稱，部門.編號）

        其中，以上的「編號」屬性都是相應實體的主碼。

 

1 : n聯繫的E-R圖到關係模式的轉換
1∶n的聯繫既可單獨對應一個關係模式，也能夠不單獨對應一個關係模式。
（1）若聯繫單獨對應一個關係模式，則由聯繫的屬性、參與聯繫的各實體集的主碼屬性構成關係模式，n端的主碼做爲該關係模式的主碼。
例如，對於圖1.6描述的「班級（BJB）」與「學生（XSB）」實體集E-R模型，可設計以下關係模式：
BJB（班級編號，院系，專業，人數）
XSB （學號，姓名，性別，出生時間，專業，總學分，備註）
SYB （學號，班級編號）
（2）若聯繫不單獨對應一個關係模式，則將聯繫的屬性及1端的主碼加入n端實體集對應的關係模式中，主碼仍爲n端的主碼。
例如，對於圖1.6描述的「班級（BJB）」與「學生（XSB）」實體集E-R模型，可設計以下關係模式：
BJB（班級編號，院系，專業，人數）
XSB （學號，姓名，性別，出生時間，專業，總學分，備註，班級編號）

 

 

 

4.（m:n）聯繫的轉變

多對多必須創建一個表

多對多聯繫只能轉換爲一個獨立的關係模式，其屬性集是由與該聯繫相連的實體的屬性（碼）以及該聯繫自己的屬性轉換而獲得的。

【例子】 一個倉庫能夠存放多種零件，一種零件也能夠存放在多個倉庫中，可見倉庫和零件之間的聯繫——「存放」是（m:n）聯繫。假設其E-R圖如圖3.10所示。

 

 

「存放」聯繫轉換爲獨立的關係模式後，結果以下： 

存放（倉庫編號，零件編號，數量）

 

m : n聯繫的E-R圖到關係模式的轉換
m : n的聯繫單獨對應一個關係模式，該關係模式包括聯繫的屬性、參與聯繫的各實體集的主碼屬性，該關係模式的主碼由各實體集的主碼屬性共同組成。
例如，對於圖1.7描述的「學生（XSB）」與「課程（KCB）」實體集之間的聯繫可設計以下關係模式：
XSB（學號，姓名，性別，出生時間，專業，總學分，備註）
KCB（課程號，課程名稱，開課學期，學時，學分）
CJB（學號，課程號，成績）
關係模式CJB的主碼是由「學號」和「課程號」兩個屬性組合起來構成的一個主碼，一個關係模式只能有一個主碼。

 

 

5. 應用規範化理論實現邏輯結構的優化

邏輯結構設計的結果是數據模型。以上主要介紹瞭如何將以E-R圖表示的概念結構轉化爲以關係模型表示的邏輯結構。在造成關係模式後，還須要對其進行優化處理，以儘量地減小數據冗餘、刪除衝突和插入衝突等問題。

 

6. 用戶子模式的設計

用戶子模式也稱爲外模式，它是面向用戶的，是用戶可見的數據模型部分。它能夠屏蔽概念模式，有助於實現程序與數據的獨立，能夠知足不一樣用戶對數據的個性化需求，同時也有利於數據庫的管理。

用戶子模式的設計主要是利用局部E-R圖，由於每一張E-R圖通常都是表示局部概念結構。如今流行的DBMS通常都提供了視圖功能，支持用戶的虛擬視圖。咱們能夠利用這個功能設計符合不一樣局部應用須要的用戶子模式。

 

 

 

3.3 物理結構設計

物理結構設計就是爲既定的數據模型選取特定的、有效的存儲結構和存儲路徑的過程。

　　特定性是指跟具體的計算機系統有關，包括操做系統和DBMS等；

　　有效性是指以儘量少的系統資源獲取數據庫儘量高的運行效率。

物理結構設計的內容主要包括數據庫存儲結構的肯定和數據庫存取方法的肯定。

 

 

數據庫存儲結構的設計

任務：肯定數據的存放位置和使用的存儲結構，肯定在磁盤空間中存儲關係、索引、日誌、備份等的數據庫文件，設置系統存儲參數，目的是使得以最小的系統資源獲取最高的系統性能。

存儲結構的設計是在已選定的DBMS和硬件條件下進行的，主要從如下兩個方面考慮:

（1）肯定數據的存放方式

在大多的關係DBMS中，數據的分類和指定存儲是經過數據文件的劃分和存儲來實現。

在DBMS中，不能直接指定數據的存放位置，而只能經過必定的機制實現數據文件的指定存放，從而實現將數據存放在指定的位置。肯定了數據文件的存放位置也就肯定了數據的存放位置。

數據文件的劃分和存儲主要是基於數據訪問的穩定性、安全性、效率等方面考慮的，相應的指導性規則包括：

　　數據庫文件和日誌文件應該分開存放在磁盤中。

　　若是計算機系統中有多個磁盤，能夠將數據庫文件分爲多個文件，並分佈在不一樣的磁盤中。

　　將數據表和索引等分開存放在不一樣的數據庫文件中。

　　大的數據對象要分散存儲在不一樣的數據庫文件中。

（2）肯定系統參數的配置

系統參數是指DBMS提供設置參數。這些參數主要包括數據庫的大小、同時鏈接的用戶數、緩衝區個數和大小、索引文件的大小、填充因子等。DBMS通常都對這些參數設置了初始值，但這些設置並不必定適應每一種應用環境，這須要設計人員從新設計。

這些參數的配置操做通常均可以在DBMS提供管理工具中完成。

【例子】 SQL Server 2008提供的管理工具是SQL Server Management Studio（SSMS），SSMS能夠管理SQL Server 2008的全部組件，包括訪問、配置、控制和開發這些組件。

 

 

2. 肯定存取方法

　　存取方法即關係模式的存取方法，目的是實現數據的快速存取。每一種DBMS都提供了多種不一樣的存取方法，索引法是最經常使用的一種，在實際開發當中用得最多。如下重點介紹索引法。

索引爲何能夠提升數據庫中數據的存取速度呢？

　　這道理與目錄能夠提升書的查閱速度的道理同樣，便可以將索引形象地比喻爲目錄。索引正是基於目錄的原理來設計，它是「數據標題」和數據內存地址的列表。經過索引能夠從部分數據檢索中實現數據的快速查找，從而提升數據的查詢效率。

索引的建立並非無代價的。

　　索引自己也是一種數據表，一樣佔用存儲資源，並且要保持與數據表的同步，這要求在進行數據更新操做（包括添加、刪除和修改操做）時也要對索引進行相應的更新操做。若是索引很大時，其佔用的空間資源以及對其更新維護所須要的代價一樣是很是可觀的。對索引的建立與否，應該慎重考慮。

 

 

　　在建立索引時，幾個經驗性的指導原則：

　　　　在常常用於檢索的列上建立索引，特別是要對主碼建立索引（通常是由DBMS自動完成）。

　　　　在外鍵上建立索引，由於它常常用於與其餘關係進行鏈接查詢。

　　　　多在以讀爲主或者常常須要排列的列上建立索引。由於索引已經排序，它能夠加快讀取速度和排序效率。

　　　　多在常常用於條件查詢的列上建立索引，特別是對那些經常出現少許元組知足條件的列。

　　　　而對具備如下性質的列，則不宜對其建立索引：

　　　　　　對於不常常用於檢索的列，則不宜在其上建立索引。

　　　　　　對於那些值域很小的列不該該建立索引。

　　　　　　對於值域嚴重分佈不均勻的列不宜在其上建立索引。

　　　　　　對於更新操做很是頻繁的列，不宜在其上建立索引。

　　　　　　對於長度超過30個字節的列，通常不要在其上建立索引。

 

 

4. 數據庫實施

數據庫實施包括如下幾方面的內容：

1. 創建數據庫結構

根據物理結構的設計結果，選定相應的DBMS。而後在該DBMS系統中利用其提供的DDL語言創建數據庫結構。

例如，在SQL Server中，可用下列的SQL語句來分別建立數據庫和數據表：    CREATE DATABASE database_name

             CREATE TABLE table_name

在數據庫結構定義之後，經過DBMS提供的編譯處理程序編譯後便可造成了實際可運行的數據庫。但這時的數據庫還僅僅一個框架，內容是空的。要真正發揮它的做用，還須要編寫相應的應用程序，將數據保存在其中，造成一個「有血有肉」的動態系統。

 

 

2. 裝載測試數據，編寫調試應用程序

應用程序設計與數據庫設計能夠同時進行，應用程序的代碼編寫和調試則在數據庫結構建立之後進行的。

應用程序的編寫和調試是一個反覆進行的過程，其中須要對數據庫進行測試性訪問。這時應該在數據庫中裝載一些測試數據。這些數據能夠隨機產生，也能夠用實際數據做爲測試數據（但這些實際數據要留有副本）。

 

3. 試運行

　　在應用程序調試之後，給數據庫加載一些實際數據並運行應用程序，但尚未正式投入使用，而只是想查看數據庫應用系統各方面的功能，那麼這種運行就稱爲試運行，試運行也稱聯合調試，

　　試運行與調試的區別：二者目的基本同樣，但側重點有所不一樣。調試主要是爲了發現系統中可能存在的錯誤，以便及時糾正；試運行雖然也須要發現錯誤，但它更注重於系統性能的檢測和評價。

　　試運行的主要工做包括：

　　　　系統性能檢測。包括測試系統的穩定性、安全性和效率等方面的指標，查看是否符合設計時設定的目標。

　　　　系統功能檢測。運行系統，按各個功能模塊逐項檢測，檢查系統的各個功能模塊是否可以完成既定的功能。

　　　　若是檢測結果不符合設計目標，則返回相應的設計階段，從新修改程序代碼或數據庫結構，直到知足要求爲止。

 

 

5. 數據庫系統的運行和維護

試運行結束並被證明符合設計要求後，數據庫就能夠正式投入使用。

數據庫的正式使用標誌着數據庫開發階段的基本結束，同時意味着數據庫運行和維護階段的開始。

數據庫的運行和維護並非數據庫設計的終點，而是數據庫設計的延續和提升。

數據庫的平常運行和維護也是一項專業性很強的工做，須要很強的專業技術。維護工做不是普通的用戶就可以勝任的，通常是由系統管理員（DBA）完成。這種工做就是軟件產生品的售後服務。

 

 

在數據庫的運行和維護階段，DBA的主要工做包括：

1.數據庫的轉儲和恢復

一旦數據庫正式投入使用，企業的相關數據將所有存入數據庫（通常不會另記在紙質材料中）。若是數據庫發生故障，可能會致使這些數據的丟失，從而形成企業的重大損失。爲了儘可能避免在數據庫發生故障時形成數據丟失，DBA應當根據應用的具體要求指定相應的備份和恢復方案，保證一旦發生故障，可以儘快將數據庫恢復到某一種一致性的最近狀態，儘可能減小損失。

數據庫轉儲：數據庫恢復技術，是指按期地把整個數據庫複製到磁盤或者其餘存儲設備上保護起來的過程。數據庫的轉儲和恢復是數據庫運行維護中最重要的工做之一。

2. 數據庫性能的檢測、分析和改善

隨着運行時間的增長，數據庫的物理存儲不斷髮生改變，加上數據量和用戶的不斷增長，這都使得數據庫的運行性能不斷降低。DBA必須利用DBMS提供的性能監控和分析工具按期地對數據庫的各類性能指標進行檢測，以便及早地發現問題並採起相應的優化和改善措施。

3. 數據庫的安全性和完整性維護

無論是從企業內部仍是從企業外部來說，數據庫的安全性和完整性都是相當重要的。做爲數據庫的管理者，DBA必須對數據庫的安全性和完整性負責。DBA應該認真審覈每個用戶的身份，並正確授予相應的權限；隨着時間的推移和應用環境的改變，對安全性的要求也隨之發生變化，這要求DBA對數據庫的安全性控制做出相應的調整，以適應新的狀況。相似地，數據庫的完整性約束條件也會發生變化，這一樣要求DBA做出相應的修正，以知足新的要求。

4. 數據庫的重組和重構

　　數據的插入、修改和刪除是數據庫的基本操做。這些操做的屢次使用會使得數據在磁盤上的存儲分佈愈來愈散，致使數據的存儲效率下降，整個系統性能降低。這時應該對數據庫進行從新組織（即重組），以提升系統的性能。如今流行的DBMS通常都提供重組功能。

　　數據庫的重構:對數據庫的模式和內模式進行調整，如增長或刪除某些列和表、增長或刪除某些索引、修改數據庫的完整性約束條件等，這種調整就是對數據庫進行從新構造的過程。

　　數據庫重組和數據庫重構有着本質的區別：

　　　　數據庫重組的目的：提升系統的性能，經過DBMS提供的功能對數據庫在磁盤上的存儲分佈進行調整來達到重組的目的，重組不會改變數據庫的模式和內模式；

　　　　數據庫重構的目的：實現新的用戶需求，須要修改數據庫結構，從而使得數據庫的概念模式和內模式也被修改。

　　不是在迫不得以的狀況下，不要使用數據庫重構。數據庫重構不但使數據庫結構發生了改變，並且在多數狀況下也要求應用程序做出相應的修改。這會致使「牽一髮而動全身」的後果，由數據庫重構而引發的修改工做量是很是大的。

　　數據庫重構並非「無所不能」，數據庫重構能夠實現新的用戶需求，但這種需求的變化幅度必須限制在必定的範圍內。超過這個範圍，數據庫重構可能沒法實現，也多是實現的代價過高而失去重構的意義。