數據庫的設計我們也已經早早的接觸過，在第一次機房收費系統的時候我們直接用的是別人的腳本，也沒有想過當時的數據庫存在什麼樣的問題，等到個人重構機房的時候，我們需要重新設計數據庫，這個時候，就不再是傻傻的導入數據庫腳本文件這麼簡單了，我們需要從需求分析開始，自己設計數據庫，什麼三范式，主外鍵關聯這都是我們需要注意的地方，可以這麼說數據庫設計貫穿我們學習的始終，那麼今天，數據庫出現在我們的軟考當中，她又會以一種什麼樣的方式出現nie，是白裙搖曳，還是一席落地長裙，小編今天就簡單介紹一下數據庫設計的相關知識點，首先我們來看下面的一張圖：
接下來，小編就隨著上面思維導圖的脈絡，一一講解數據庫設計中的相關知識點，首先我們來看第一個知識點：
數據庫設計階段
數據庫設計階段分為四個階段，我們來看下面的一張圖片：
接下來，小編對四個階段到底是什麼，干什麼的等進行一一的介紹。首先我們來看第一個階段，需求分析。所謂的需求分析就是收集和分析用戶對系統的信息需求和處理需求，得到設計系統所必須的需求分析，建立系統說明文檔，需求分析的目標是通過調查研究了解用戶的數據要求和處理要求，並且按照一定的格式整理形成需求說明書，也就是說，需求說明書是需求分析階段的成果，也是以後設計的一個基礎和依據，她包括數據庫所涉及的數據，數據的特征，使用頻率和數據量的估計，例如數據名。屬性。類型，還包括數據的保密要求， 數據庫的完整性約束，使用的頻率，數據量的大小等一系列問題，設計大型數據庫的時候，這些數據信息通常是使用數字字典進行管理，這是需求分析的內容。
我們再來看概念結構設計：概念結構設計是對需求說明書所提供的所有數據和處理要求進行抽象和綜合處理，按照一定的方法，構造反應用戶環境的數據以及數據之間相互聯系的概念模型。也就是我們通常所講的ER模型，所以這種概念模型是與具體的DBMS是沒有關系的，她是面向現實世界的，用戶很容易理解的一種數據模型，為了保證所涉及的概念數據模型能夠正確的完全的反應用戶的數據以及相互關系，便於進行所要求的各種處理， 在概念結構設計階段就可以吸收用戶來參與，在進行概念結構設計的時候，可以先設計各個應用的視圖，也就是各個應用所看到的數據以及他的結構，局部視圖，然後再把局部視圖進行集成，也就是後面所說的分ER圖到整個ER圖合並的過程，所以，最終結果，形成概念設計模型，形成了概念設計模型以後，就要開始邏輯結構設計。
接著是我們的邏輯結構設計：根據有關的規則 ，把ER模型轉換為關系模式，再根據有關規范化的理論，確定關系模式的主鍵、外鍵、約束等這些特性，所以這種轉換就是要能為某個特定的DBMS所接受的邏輯模型所表示的一種形式，邏輯結構設計階段的結果就是用DBMS所提供的數據定義語言所寫成的數據模式，邏輯設計的具體方法與dbms的邏輯數據模型是有關系的，所以另為一個輸入是DBMS的特性。邏輯模型應該要滿足數據庫的存儲，一致性，以及運行各方面的用戶需求。
最後是我們的的物理設計：把邏輯設計階段所得到的滿足用戶需求的已經確定的邏輯模型在物理上加以實現，他的主要內容是根據DBMS所提供的各種手段設計數據的存儲形式和存儲路徑，包括文件結構，索引這樣一些設計過程，也就是說要設計數據庫的內模式或者存儲模式，由於數據庫的內模式對數據庫的性能影響比較大，所以應該要根據處理的要求 以及操作系統硬件的性能來進行設計，所以她的輸入是按照硬件以及操作系統的特性。看完了數據庫的設計階段，我們再來看一下ER模型。
ER模型
ER模型，實體-聯系模型（簡稱E-R模型）它提供不受任何DBMS約束的面向用戶的表達方法，在數據庫設計中被廣泛用作數據建模的工具。E-R數據模型問世後，經歷了許多修改和擴充。我們來看一張簡單的ER圖，如下所示：
在我們的ER圖中，各個圖形表示的是什麼意思nie，小編來簡單的介紹一下， 橢圓表示屬性。長方形表示實體、菱形表示聯系，數字表示聯系的類型，比如倉庫和零件的關系是庫存，倉庫裡面可以存多個零件，零件可以放在多個倉庫裡面進行存放，所以他們之間的關系是多對多的關系。總的來講，在數據庫的概念結構設計當中，先要設計各個 子系統的局部ER圖，左邊是一個采購管理的ER圖，中間是庫存管理的ER圖，右邊是人事管理的ER圖，先設計好局部的ER圖，然後再進行合並。
那麼要設計各個子系統的局部ER圖，可以分為以下步驟：
首先，確定局部視圖的范圍，然後再識別該部分的每一個實體，以及實體之間的聯系，最後分配實體，以及實體聯系之間的屬性。當各個子系統的局部ER圖設計好之後，我們需要做的就是合並子系統的ER圖使之成為一個總的ER圖，，稱為視圖的集成，這種集成有兩種方式，一種方式，多個局部ER圖一次集成，第一步逐步集成，先集成前兩個，然後再集成。不管用那種方式，由於各個子系統在應用的時候面臨的問題不同，而且在一個大型的系統中，通常不只有一個設計人，所以不同的子系統由不同的設計人員設計，導致各個局部的ER圖之間必定會存在許多不一致的問題，我們把這種不一致的問題稱為沖突，因此合並分ER圖的時候，並不能簡單的將各個局部的ER圖分到一起。而是必須消除各個子系統之間的不一致，這樣才能形成一個 能為全系統當中所有用戶都能理解和接受的統一的概念模型。關於數據庫設計的理論知識，小編就暫時介紹到這裡，接下來，我們來看看歷年的軟考真題，看看我們如何利用理論知識在實際中運用的nie？
典型例題分析
首先，我們來看一道2004年11月份的一道真題，題目如下所示：
ER圖如下所示：
題目我們看完了，接著我們來看第一個小問，如下所示：
據我們剛才介紹的把ER圖轉化為關系模式，在我們上面的圖中，一共有兩個聯系，三個實體，每個實體都要轉換為關系模式，就有三個關系模式，兩個聯系轉換為一個關系模式，題目要求轉四個，把第一個進行合並。所以這個時候確定這些實體之間的聯系，看她們之間的關系，我們看題目中是這樣來描述的：“一個顧客可以在同一天填寫多張購書單，每張購書單上可填寫多種圖書，每種圖書可以訂購多本，bid相同的圖書在同一張夠數單上不能出現多次，注意，為了簡化起見，不考慮信用卡號碼洩露所帶來的安全性等問題”通過試題中的描述我，我們可以很容易的看出，顧客和購書單之間的聯系是一對多的聯系，我們再看圖書和訂單，一個訂單當中中含有多本圖書，根據嘗試，一本圖書可以出現在多個訂單中，所以圖書和訂單的聯系是多對多，前面我們提到過多對多的聯系應該要轉換成一個獨立的關系模式，所以PlaceOrder與Orders進行合並，所以四個關系模式是書籍Books（屬性六個，竹馬bid圖書編號），第二個顧客，屬性有四個，主鍵顧客編號cid，第三個是訂單，所以她的屬性有訂單的編號，顧客的編號，還有填寫的日期bRderDate,這是根據我們剛才所講的，一個n比n的關系與另外一段合並的時候，就應該包括一段的碼要加進來，所以這個訂單的屬性有三個，訂單編號，顧客編號，填寫日期，一個第四個OrderList，單獨組成一個關系模式，那麼就要把與她相聯系的各個實體的碼都需要加進來，所以一共有四個屬性bid（圖書的編號），訂單的編號，發貨的日期，數量，主鍵是圖書編號和訂單編號的一個組合。
外碼：對於books來講，沒有外碼，因為這些屬性都是自己的，顧客也是的，訂單有三個屬性，cid就是Orders的外碼，因為她是顧客的主鍵，不是訂單的主鍵，所以她是一個外碼，在看OrderList，我們知道在OrderList當中他的主鍵是bid和ordernum的一個組合，但是其中的任何一個都不是她的主鍵，所以每一個都是她的外鍵。接著我們來看第二個問題，如下所示：
從題目的描述我們知道顧客屬性有四個，所以這兩個空填寫的肯定不是屬性，那會是什麼nie，就是約束，那麼在這個題目當中有什麼約束nie，看題目，首先要求cardnum這個值是唯一的，在這裡沒有體現出，題中只是給出了不為空，我們采用約束unique，所以第一個空填寫的是unique cardnun，使cardnum的值是唯一的，還有一個約束是什麼ne，我們知道在創建一個表的時候，我們需要指定這個表的主鍵，這裡面沒有指出來，這個表的主鍵是cid，這裡僅僅指出了非空，但是非空不是主鍵，所以第二個空填寫的是primary key（cid），所以有關填寫sql語句的題目的時候，建立表和視圖的情況，我們首先看他的屬性是否完整，如果完整，剩下的就是約束。接著我們來看第三題：
我們首先不要急於看sql語句，這樣是看不出名堂來的，我們必須首先弄清楚，這個查詢怎麼去做，如題意，需要查詢的是所有訂購了bid為123 456圖書的用戶訂購其他圖書的情況，我們可以分為兩個步驟來進行，我們首先查出那些用戶訂購了bid為123 345的圖書，第二步再查這些用戶訂購了其他圖書的情況，所以這裡面使用的就是查詢的嵌套，在嵌套裡面現查第一個，然後查詢第二個，所以第四個空應該是c.bid，第五個空c.ordernum,在orderList這個關系模式當中，她是一個n比n的關系轉換過來的，所以她有圖書的編號和訂單的編號，所以圖書的編號等於123--456，訂單的編號等於就等於訂單這個關系模式的訂單編號，所以4和5就填寫完畢了，第4個空是c，第5個空是c.ordernum。所以3填寫的是not in。
小編寄語：該博文，小編主要講解了軟考下午題目當中的數據設計的相關知識點，分別從數據庫設計的階段，ER模型已經典型例題分析三個方面對數據庫設計進行了簡單的講解，在軟考當中，通常會考察我們，ER圖當中各個實體之間的聯系聯系，寫出關系模式，找出主外鍵；在軟考中考察的問題包括在給定的er圖當中，指出實體之間的聯系類型，在關系模式當中補充屬性，找出關系模式的主外鍵以及sql語句。同時在確定主外鍵的時候，我們可以根據常識來得出結論，和試題描述，解答此類問題需要認真讀題。
