分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

        在前面的兩篇部落格中，小編分別對軟考下午試題中的資料流圖設計和uml圖的相關知識點進行了詳細的闡述，今天我們繼續來看軟考下午題中的大題部分---資料庫設計，資料庫的設計我們也已經早早的接觸過，在第一次機房收費系統的時候我們直接用的是別人的指令碼，也沒有想過當時的資料庫存在什麼樣的問題，等到個人重構機房的時候，我們需要重新設計資料庫，這個時候，就不再是傻傻的匯入資料庫指令碼檔案這麼簡單了，我們需要從需求分析開始，自己設計資料庫，什麼三正規化，主外來鍵關聯這都是我們需要注意的地方，可以這麼說資料庫設計貫穿我們學習的始終，那麼今天，資料庫出現在我們的軟考當中，她又會以一種什麼樣的方式出現nie，是白裙搖曳，還是一席落地長裙，小編今天就簡單介紹一下資料庫設計的相關知識點，首先我們來看下面的一張圖：

        接下來，小編就隨著上面思維導圖的脈絡，一一講解資料庫設計中的相關知識點，首先我們來看第一個知識點：

        資料庫設計階段

        資料庫設計階段分為四個階段，我們來看下面的一張圖片：

         接下來，小編對四個階段到底是什麼，幹什麼的等進行一一的介紹。首先我們來看第一個階段，需求分析。所謂的需求分析就是

        我們再來看概念結構設計：概念結構設計是對需求說明書所提供的所有資料和處理要求進行抽象和綜合處理，

        接著是我們的邏輯結構設計：根據有關的規則 ，把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語句。同時在確定主外來鍵的時候，我們可以根據常識來得出結論，和試題描述，解答此類問題需要認真讀題。

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow