軟考下午題詳解--數據庫設計

        在前面的兩篇博客中，小編分別對軟考下午試題中的數據流圖設計和uml圖的相干知識點進行了詳細的論述，今天我們繼續來看軟考下午題中的大題部份---數據庫設計，數據庫的設計我們也已早早的接觸過，在第1次機房收費系統的時候我們直接用的是他人的腳本，也沒有想過當時的數據庫存在甚么樣的問題，等到個人重構機房的時候，我們需要重新設計數據庫，這個時候，就不再是傻傻的導入數據庫腳本文件這么簡單了，我們需要從需求分析開始，自己設計數據庫，甚么3范式，主外鍵關聯這都是我們需要注意的地方，可以這么說數據庫設計貫穿我們學習的始終，那末今天，數據庫出現在我們的軟考當中，她又會以1種甚么樣的方式出現nie，是白裙搖擺，還是1席落地長裙，小編今天就簡單介紹1下數據庫設計的相干知識點，首先我們來看下面的1張圖：

        接下來，小編就隨著上面思惟導圖的脈絡，逐一講授數據庫設計中的相干知識點，首先我們來看第1個知識點：

        數據庫設計階段

        數據庫設計階段分為4個階段，我們來看下面的1張圖片：

         接下來，小編對4個階段究竟是甚么，干甚么的等進行逐一的介紹。首先我們來看第1個階段，需求分析。所謂的需求分析就是搜集和分析用戶對系統的信息需求和處理需求，得到設計系統所必須的需求分析，建立系統說明文檔，需求分析的目標是通過調查研究了解用戶的數據要求和處理要求，并且依照1定的格式整理構成需求說明書，也就是說，需求說明書是需求分析階段的成果，也是以后設計的1個基礎和根據，她包括數據庫所觸及的數據，數據的特點，使用頻率和數據量的估計，例如數據名。屬性。類型，還包括數據的保密要求， 數據庫的完全性束縛，使用的頻率，數據量的大小等1系列問題，設計大型數據庫的時候，這些數據信息通常是使用數字字典進行管理，這是需求分析的內容。

        我們再來看概念結構設計：概念結構設計是對需求說明書所提供的所有數據和處理要求進行抽象和綜合處理，依照1定的方法，構造反利用戶環境的數據和數據之間相互聯系的概念模型。也就是我們通常所講的ER模型，所以這類概念模型是與具體的DBMS是沒有關系的，她是面向現實世界的，用戶很容易理解的1種數據模型，為了保證所觸及的概念數據模型能夠正確的完全的反利用戶的數據和相互關系，便于進行所要求的各種處理，  在概念結構設計階段就能夠吸收用戶來參與，在進行概念結構設計的時候，可以先設計各個利用的視圖，也就是各個利用所看到的數據和他的結構，局部視圖，然后再把局部視圖進行集成，也就是后面所說的分ER圖到全部ER圖合并的進程，所以，終究結果，構成概念設計模型，構成了概念設計模型以后，就要開始邏輯結構設計。

        接著是我們的邏輯結構設計：根據相關的規則 ，把ER模型轉換為關系模式，再根據相關規范化的理論，肯定關系模式的主鍵、外鍵、束縛等這些特性，所以這類轉換就是要能為某個特定的DBMS所接受的邏輯模型所表示的1種情勢，邏輯結構設計階段的結果就是用DBMS所提供的數據定義語言所寫成的數據模式，邏輯設計的具體方法與dbms的邏輯數據模型是有關系的，所以另為1個輸入是DBMS的特性。邏輯模型應當要滿足數據庫的存儲，1致性，和運行各方面的用戶需求。

       最后是我們的的物理設計：把邏輯設計階段所得到的滿足用戶需求的已肯定的邏輯模型在物理上加以實現，他的主要內容是根據DBMS所提供的各種手段設計數據的存儲情勢和存儲路徑，包括文件結構，索引這樣1些設計進程，也就是說要設計數據庫的內模式或存儲模式，由于數據庫的內模式對數據庫的性能影響比較大，所以應當要根據處理的要求 和操作系統硬件的性能來進行設計，所以她的輸入是依照硬件和操作系統的特性。看完了數據庫的設計階段，我們再來看1下ER模型。

        ER模型

        ER模型，實體-聯系模型（簡稱E-R模型）它提供不受任何DBMS束縛的面向用戶的表達方法，在數據庫設計中被廣泛用作數據建模的工具。E-R數據模型問世后，經歷了許多修改和擴充。我們來看1張簡單的ER圖，以下所示：

        在我們的ER圖中，各個圖形表示的是甚么意思nie，小編來簡單的介紹1下， 橢圓表示屬性。長方形表示實體、菱形表示聯系，數字表示聯系的類型，比如倉庫和零件的關系是庫存，倉庫里面可以存多個零件，零件可以放在多個倉庫里面進行寄存，所以他們之間的關系是多對多的關系。總的來說，在數據庫的概念結構設計當中，先要設計各個 子系統的局部ER圖，左側是1個采購管理的ER圖，中間是庫存管理的ER圖，右側是人事管理的ER圖，先設計好局部的ER圖，然后再進行合并。
        那末要設計各個子系統的局部ER圖，可以分為以下步驟：
        首先，肯定局部視圖的范圍，然后再辨認該部份的每個實體，和實體之間的聯系，最后分配實體，和實體聯系之間的屬性。當各個子系統的局部ER圖設計好以后，我們需要做的就是合并子系統的ER圖使之成為1個總的ER圖，，稱為視圖的集成，這類集成有兩種方式，1種方式，多個局部ER圖1次集成，第1步逐漸集成，先集成前兩個，然后再集成。不管用那種方式，由于各個子系統在利用的時候面臨的問題不同，而且在1個大型的系統中，通常不只有1個設計人，所以不同的子系統由不同的設計人員設計，致使各個局部的ER圖之間一定會存在許多不1致的問題，我們把這類不1致的問題稱為沖突，因此合并分ER圖的時候，其實不能簡單的將各個局部的ER圖分到1起。而是必須消除各個子系統之間的不1致，這樣才能構成1個 能為全系統當中所有用戶都能理解和接受的統1的概念模型。關于數據庫設計的理論知識，小編就暫時介紹到這里，接下來，我們來看看歷年的軟考真題，看看我們如何利用理論知識在實際中應用的nie？

        典型例題分析

        首先，我們來看1道2004年11月份的1道真題，題目以下所示：

         ER圖以下所示：

         題目我們看完了，接著我們來看第1個小問，以下所示：

         據我們剛才介紹的把ER圖轉化為關系模式，在我們上面的圖中，1共有兩個聯系，3個實體，每一個實體都要轉換為關系模式，就有3個關系模式，兩個聯系轉換為1個關系模式，題目要求轉4個，把第1個進行合并。所以這個時候肯定這些實體之間的聯系，看她們之間的關系，我們看題目中是這樣來描寫的：“1個顧客可以在同1天填寫多張購書單，每張購書單上可填寫多種圖書，每種圖書可以訂購多本，bid相同的圖書在同1張足數單上不能出現屢次，注意，為了簡化起見，不斟酌信譽卡號碼泄漏所帶來的安全性等問題”通過試題中的描寫我，我們可以很容易的看出，顧客和購書單之間的聯系是1對多的聯系，我們再看圖書和定單，1個定單當中中含有多本圖書，根據嘗試，1本圖書可以出現在多個定單中，所以圖書和定單的聯系是多對多，前面我們提到過量對多的聯系應當要轉換成1個獨立的關系模式，所以PlaceOrder與Orders進行合并，所以4個關系模式是書籍Books（屬性6個，竹馬bid圖書編號），第2個顧客，屬性有4個，主鍵顧客編號cid，第3個是定單，所以她的屬性有定單的編號，顧客的編號，還有填寫的日期bRderDate,這是根據我們剛才所講的，1個n比n的關系與另外1段合并的時候，就應當包括1段的碼要加進來，所以這個定單的屬性有3個，定單編號，顧客編號，填寫日期，1個第4個OrderList，單獨組成1個關系模式，那末就要把與她相聯系的各個實體的碼都需要加進來，所以1共有4個屬性bid（圖書的編號），定單的編號，發貨的日期，數量，主鍵是圖書編號和定單編號的1個組合。
        外碼：對books來說，沒有外碼，由于這些屬性都是自己的，顧客也是的，定單有3個屬性，cid就是Orders的外碼，由于她是顧客的主鍵，不是定單的主鍵，所以她是1個外碼，在看OrderList，我們知道在OrderList當中他的主鍵是bid和ordernum的1個組合，但是其中的任何1個都不是她的主鍵，所以每個都是她的外鍵。接著我們來看第2個問題，以下所示：

        
        從題目的描寫我們知道顧客屬性有4個，所以這兩個空填寫的肯定不是屬性，那會是甚么nie，就是束縛，那末在這個題目當中有甚么束縛nie，看題目，首先要求cardnum這個值是唯1的，在這里沒有體現出，題中只是給出了不為空，我們采取束縛unique，所以第1個空填寫的是unique  cardnun，使cardnum的值是唯1的，還有1個束縛是甚么ne，我們知道在創建1個表的時候，我們需要指定這個表的主鍵，這里面沒有指出來，這個表的主鍵是cid，這里僅僅指出了非空，但是非空不是主鍵，所以第2個空填寫的是primary key（cid），所以有關填寫sql語句的題目的時候，建立表和視圖的情況，我們首先看他的屬性是不是完全，如果完全，剩下的就是束縛。接著我們來看第3題：

        
        我們首先不要急于看sql語句，這樣是看不出花樣來的，我們必須首先弄清楚，這個查詢怎樣去做，如題意，需要查詢的是所有訂購了bid為123 456圖書的用戶訂購其他圖書的情況，我們可以分為兩個步驟來進行，我們首先查出那些用戶訂購了bid為123 345的圖書，第2步再查這些用戶訂購了其他圖書的情況，所以這里面使用的就是查詢的嵌套，在嵌套里面現查第1個，然后查詢第2個，所以第4個空應當是c.bid，第5個空c.ordernum,在orderList這個關系模式當中，她是1個n比n的關系轉換過來的，所以她有圖書的編號和定單的編號，所以圖書的編號等于123-⑷56，定單的編號等于就等于定單這個關系模式的定單編號，所以4和5就填寫終了了，第4個空是c，第5個空是c.ordernum。所以3填寫的是not in。

         小編寄語：該博文，小編主要講授了軟考下午題目當中的數據設計的相干知識點，分別從數據庫設計的階段，ER模型已典型例題分析3個方面對數據庫設計進行了簡單的講授，在軟考當中，通常會考察我們，ER圖當中各個實體之間的聯系聯系，寫出關系模式，找出主外鍵；在軟考中考察的問題包括在給定的er圖當中，指出實體之間的聯系類型，在關系模式當中補充屬性，找出關系模式的主外鍵和sql語句。同時在肯定主外鍵的時候，我們可以根據常識來得出結論，和試題描寫，解答此類問題需要認真讀題。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈