第二篇 數據庫基礎篇

第3章 熟悉數據庫

數據庫從字面的意思上理解它就是一個存儲數據庫的倉庫，就像用來存儲藥品的藥庫或用來存放糧食的糧庫一樣。要使用數據庫就要先對數據庫有一個了解。本章主要學習以下知識點：

? 數據庫的歷史和模型

? 數據庫的三級模式和二級映像

? 關系型數據庫的設計

? 實體-聯系圖的繪制

本章內容基本涵蓋了關系型數據庫的設計和實體-聯系圖的繪制以及數據庫的基本知識。通過本章的學習，讀者可以了解數據庫的歷史，掌握關系型數據庫的設計方法以及實體-聯系圖的繪制。

3.1 什么是數據庫

隨著計算機和網絡的普及，我們日常的工作和學習都離不開數據庫了，如果沒有數據庫，我們就不能在網上訂書，網上也就沒有我們瀏覽的網站了。那么什么是數據庫呢？本節就將講解數據庫的歷史、數據庫的模型、數據庫的三級模式和二級映像、數據庫相關的術語以及數據庫設計的完整性。

3.1.1 了解數據管理的歷史

任何事物的發展都有一段歷史，數據管理的發展也不例外。在數據管理的發展過程中，主要經歷了3個階段，即人工管理階段、文件系統階段、數據庫系統階段。

1. 人工管理階段

20世紀50年代中期以前是人工管理階段，世界上第一臺計算機（ENIAC）是1946年2月14日在美國誕生的。那時計算機還是一個陌生的詞匯，對于計算機來說，存儲信息的設備沒有磁盤，只有磁帶、卡片等存儲設備；計算機中也沒有操作系統更沒有管理軟件；處理數據的方式只有批處理方式。在人工管理階段，主要負責數據管理的是人。人工管理數據具有以下4個特點：

1）不能長期保存數據。在20世紀50年代中期之前，計算機一般在信息中心這樣的研究機構里才能擁有，當時由于存儲的設備有限，都是在做實驗的時候暫存實驗數據，做完實驗就把結果打在紙帶或者磁帶上帶走，所以數據一般不需要長期保存。

2）數據并不是由應用軟件管理的而是由應用程序自己管理的。作為程序員在編寫程序時既要設計程序邏輯結構又要設計物理結構以及數據的存取方式等，因此，對程序員編寫代碼的工作量和質量要求都很高。

3）數據不能共享。在人工管理階段，可以說數據是面向程序的，由于每一個應用程序都是獨立的，即使要使用的相同數據已經在其他應用程序中存在，在應用程序之間也是不能共享的，這樣也造成了大量的數據冗余。

4）數據不具有獨立性。應用程序中只要發生改變，數據的邏輯結構和物理結構就相應地發生變化。因而程序員都要做出相應的修改，給程序員的工作帶來很多的負擔。

根據人工管理階段管理數據的特點，如果計算機中有3個應用程序，那么它們和各自數據集之間的對應關系就如圖3.1所示。

2. 文件系統階段

20世紀50年代后期到60年代中期，計算機開始應用于數據管理方面。此時，計算機的存儲設備也不再是磁帶和卡片了，已經可以用磁盤直接存儲了。此時，存儲數據使用的是文件系統也稱為管理軟件，文件系統是操作系統中負責管理和存儲文件信息的軟件機構。文件系統由三部分組成：與文件管理有關的軟件、被管理的文件以及實施文件管理所需的數據結構。文件系統階段存儲數據就是以文件的形式來存儲，由操作系統統一處理。文件系統階段也是數據庫發展的初級階段，使用文件系統存儲數據具有以下四個特點：

1）可以長期保存數據。有了大容量的磁盤作為存儲設備，計算機開始被用來處理大量的數據并可以存儲數據。

2）有簡單的數據管理功能。文件的邏輯結構與物理結構脫鉤，程序和數據分離，使數據與程序有了一定的獨立性，減少了程序員的工作量。

3）共享數據能力差。由于每一個文件都是獨立的，當需要用到相同的數據時，必須建立各自的文件，數據還是無法共享，也會造成大量的數據冗余。

4）數據不具有獨立性。在此階段數據仍然不具有獨立性，當數據的結構發生改變時，也必須修改應用程序，修改文件的結構定義；而應用程序的改變也將改變數據的結構。

根據文件系統階段管理數據的特點，如果計算機中有3個應用程序，那么它們和各自文件之間的對應關系就如圖3.2所示。

3. 數據庫系統階段

從20世紀60年代后期開始就進入了數據庫系統階段。隨著計算機的普及，同時計算機的外存設備磁盤的容量也得到了擴充，需要管理的數據也與日俱增，此時，在文件系統的基礎上就開始有了數據庫技術。最早的數據庫管理系統是在1961年由通用電氣公司開發的，此后，數據庫的技術得到了飛速的發展。數據庫存儲數據不僅存儲數據的本身同時也存儲數據之間的聯系。在數據庫系統階段管理數據具有以下4個特點：

1）實現數據的共享。進入數據庫系統階段之后，數據終于可以得到共享。也就是說，數據在存入數據庫后，想使用數據的用戶可以同時來訪問數據庫使用數據，這樣就減少了數據的冗余。

2）數據具有了獨立性。在數據庫中數據庫的邏輯結構和應用程序之間是相互獨立的，同時數據庫的物理結構變化也不會影響數據庫的邏輯結構，這就給程序員減少了很多的工作量。

3）數據實現集中控制。此時，數據不再由各自的應用程序管理，而是由數據庫管理系統統一管理，這樣可以保證數據的安全性和可維護性。

4）故障恢復。在沒有數據庫管理系統之前，如果數據出現丟失或損壞的情況，那么數據是無法恢復的；但是有了數據庫之后，數據庫管理系統的備份恢復機制就可以幫助用戶找回丟失和損壞的數據，可以最大限度地減少損失。

根據數據庫系統階段管理數據的特點，如果計算機中有3個應用程序，那么它們與數據庫之間的對應關系就如圖3.3所示。

從文件系統發展到數據庫系統，這在信息領域中具有里程碑的意義。在文件系統階段，人們在信息處理中關注的中心問題是系統功能的設計，因此程序設計占主導地位；而在數據庫方式下，數據開始占據了中心位置，數據的結構設計成為信息系統首要關心的問題，而應用程序則以既定的結構為基礎進行設計。

3.1.2 數據庫的模型

數據庫的模型從數據庫技術出現至今一共有3種比較通用的模型，目前使用最多的是關系型數據模型。下面就分別介紹這3種模型。

1. 層次結構模型

最早使用層次結構模型的是IBM公司的IMS（Information Management System），即數據庫管理信息系統，這個系統也是被廣泛應用的。層次結構模型類似于倒置的樹型，一個父表可以有多個子表，但是每一個子表都對應著一個父表。圖3.4所示就是一個學校人員的層次結構模型。

在圖3.4中學校可以看做是父表，在學校下面有教職員工和學生兩個子表，教職員工下面又有兩個子表，學生下面也有兩個子表，但是每一個子表都只有一個父表與之對應。

由于層次結構模型的結構很難改變，而且在表示表之間的關系時也有一些局限性，所以目前使用層次結構模型設計數據庫是比較少的。

2. 網狀結構模型

網狀結構模型是對層次結構模型的改進，使用網狀結構模型的代表是DBTG（Data Base Task Group），它是20世紀70年代數據系統語言研究會下屬的數據庫任務組提出的一個系統方案。網狀結構模型打破了層次結構模型使用的限制，可以更全面地描述數據庫中表之間的關系，可以一個父表沒有子表，也可以一個子表有多個父表，還可以設置兩個表之間的多種關系。圖3.5所示是一個網狀結構模型的例子。

圖3.5中描述的是某軟件公司技術部門的組成結構，這里程序員擁有員工宿舍和開發大廳兩個父節點，這是層次結構模型不能描述的。盡管網狀結構模型已經在層次結構模型的基礎上有了一定的改進，但是對數據庫的設計者要求很高，必須要非常熟悉數據庫才能使用這種網狀結構模型。

3. 關系結構模型

關系結構模型可以說是在層次結構模型和網狀結構模型的基礎上發展而來的，是目前使用最多的數據模型。最早給關系結構模型下定義的是E.F.Codd博士，他說：“關系數據結構保護數據，并且允許以一種可以預測并防止差錯的方法操作數據。”關系結構模型實際上就是一個二維表，是由行和列組成的。例如，一個員工信息登記表就是一個二維表即關系模型，如表3.1所示。

在表3.1中，把一行數據稱為一個元組，其中一共就有3個元組；把一列數據稱為一個字段或屬性，其中一共就有6個屬性，即員工編號、姓名、年齡、性別、所在部門、聯系方式。要想在設計數據庫時使用關系結構模型，必須要做到規范化。關于規范化的問題將在3.2節中詳細講述。

目前大多數的數據庫都是屬于關系型數據庫，這些數據庫主要有IBM DB2、Oracle、SQL Server、MySQL、SyBase、Informix、Access、FoxPro等。

3.1.3 學習數據庫的三級模式和二級映像

數據庫的模式（Schema）是對現實世界的抽象，是對數據庫中全體數據的邏輯結構和特征的描述。模式反映的是數據的結構及其聯系，數據庫系統在其內部具有三級模式和二級映像。三級模式分別為外模式、模式與內模式，二級映像則是外模式/模式映像和模式/內模式映像。

1. 三級模式

美國國家標準學會（American National Standard Institute，ANSI）的數據庫管理系統研究小組于1978年提出了標準化的建議，將數據庫結構分為3級：面向用戶或應用程序員的用戶級、面向建立和維護數據庫人員的概念級、面向系統程序員的物理級。用戶級對應外模式，概念級對應模式，物理級對應內模式。以下就分別講解這3種模式。

（1）模式

模式對應著概念級，它是由數據庫設計者綜合所有用戶的數據，按照統一的觀點構造的全局邏輯結構，是對數據庫中全部數據的邏輯結構和特征的總體描述，是所有用戶的公共數據視圖。它是由數據庫管理系統提供的數據模式描述語言（Data Description Language，DDL）來描述、定義的，體現并反映了數據庫系統的整體觀。

（2）外模式

外模式對應于用戶級，它是某個或某幾個用戶所看到的數據庫的數據視圖，是與某一應用有關的數據邏輯的表示。外模式是從模式導出的一個子集，包含模式中允許特定用戶使用的那部分數據。用戶可以通過外模式描述語言來描述、定義對應于用戶的數據記錄（外模式），也可以利用數據操縱語言（Data Manipulation Language，DML）對這些數據記錄進行操作。

（3）內模式

內模式對應于物理級，它是數據庫中全體數據的內部表示或底層描述，是數據庫最低一級的邏輯描述，它描述了數據在存儲介質上存儲方式的物理結構，對應著實際存儲在外存儲介質上的數據庫。

2. 二級映像

數據庫系統的三級模式是對數據的3個抽象級別，它把數據的具體組織留給DBMS管理，使用戶能邏輯地、抽象地處理數據，而不必關心數據在計算機中的具體表示與存儲。為了能夠在內部實現這3個抽象層次的聯系和轉換，DBMS在這3個級別之間提供了兩層映像：外模式／模式映像和模式／內模式映像。

外模式／模式映像使數據具有較高的邏輯獨立性。它定義了該外模式與模式之間的對應關系。這些映像定義通常包含在各自外模式的描述中。當模式改變時，DBA要對相關的外模式／模式映像做相應的改變，以使外模式保持不變。應用程序是依據數據的外模式編寫的，外模式不變應用程序就沒必要修改。所以，外模式／模式映像功能保證了數據與程序的邏輯獨立性。

模式／內模式映像使數據具有較高的物理獨立性。它定義了數據庫全局邏輯結構與存儲結構之間的對應關系。該映像定義通常包含在模式描述中。當數據庫的存儲結束了，DBA要對模式／內模式映像做相應的改變，以使模式保持不變。模式不變，與模式沒有直接聯系的應用程序也不會改變。所以，模式／內模式映像功能保證了數據與程序的物理獨立性。

3.1.4 數據庫中的相關術語

在Oracle 11g數據庫中每個數據庫里面都包含很多對象，主要包括表、視圖、存儲過程、觸發器以及約束。在本小節里只簡單介紹一下每一個術語的含義，在后面的章節中會詳細地講解這些術語的使用。

1. 表

表，即在數據庫中存放數據用的數據表。每一個數據庫中都可以包含多張數據表，但是每一個數據表的名字都是不能重復的。表的一行代表一條記錄，每一列都有一個列名，列名是唯一的，行與列的交叉點稱為字段。例如，創建一個存放圖書信息的表，表中信息包括圖書編號、圖書名稱、圖書作者、圖書出版社、圖書價格、備注，如表3.2所示。

在表3.2中，第一行是表中每一列的列名，后兩行每一行都是表中的一條記錄。

2. 視圖

視圖是數據庫中的虛擬表。在視圖中存放的是從數據庫表中查詢出來的記錄，使用視圖主要是為了方便信息查詢，同時也能夠縮短查詢數據的時間。

3. 存儲過程

存儲過程是由SQL語句和控制流語句組成的語句塊。存儲過程存儲在數據庫內，可由應用程序通過存儲過程的名稱調用執行。

存儲過程在開發軟件時，可以把大量的數據操作放在服務器端的存儲過程中，而只返回需要的數據，這樣就減少了數據的傳輸量，速度也可以大大地提高。

4. 觸發器

觸發器是特殊的存儲過程，也是由SQL語句和程序控制語句組成的。但是，觸發器在數據庫中是不需調用而自動執行的。例如，在觸發器中可以定義在修改某張表記錄后執行觸發器中的內容。

5. 約束

約束是在數據庫中保證數據庫里表中數據完整性的手段。在Oracle 11g中使用的約束有主鍵約束、外鍵約束、唯一約束、檢查約束、非空約束5個，其中主鍵約束和唯一約束都被認為是唯一約束，而外鍵約束被認為是參照約束。

（1）主鍵（Primary Key）約束

主鍵約束在每個數據表中只能有一個，但是一個主鍵約束可以由多個列組成，通常把由多個列組成的主鍵又叫做復合主鍵或組合主鍵。主鍵約束可以保證主鍵列的數據沒有重復值且值不為空，也可以說是唯一地標識表中的一條記錄。

（2）外鍵（Foreign Key）約束

外鍵約束之所以被認為是參照約束，是因為它主要用作把一個表中的數據和另一個表中的數據進行關聯，表和表之間的關聯是為了保證數據庫中數據的完整性，使用外鍵保證數據的完整性，也叫參照完整性。在3.1.5小節還會詳細地說明數據的完整性。下面就創建商品信息表和商品類型信息表，并建立兩個表之間的外鍵約束，如表3.3所示。

在商品信息表中“商品編號”是主鍵，而在商品類型信息表中“類型編號”是主鍵，當把商品信息表中的“商品編號”與商品類型信息表中的“類型編號”設置為外鍵約束后，在商品信息表中的類型信息就可以用商品類型信息表中的類型編號代替。設置完外鍵約束后，商品信息表中類型字段值必須是在商品類型信息表中存在的，同時當在商品類型信息表中刪除一個類型時，如果商品信息表已經使用過該類型，那么商品類型信息表中的數據就無法被刪除。這樣就保證了數據庫中數據的完整性。

（3）唯一（unique）約束

唯一約束和主鍵約束一樣都是設置表中的列不能重復的約束，區別就是一個表中只能有一個主鍵約束，而卻可以有多個唯一約束。通常情況下設置唯一約束的目的就是使非主鍵列沒有重復值。唯一約束與主鍵約束的另一個區別是如果數據表中的某一列中有空值，那么就不能把這個列設置為主鍵列，而可以設置成唯一約束。例如，在商品信息表中把商品編號設置成了主鍵，但是還要保證商品的名稱不重名時，就可以把商品名稱設置為唯一約束。

（4）檢查（check）約束

檢查約束是用來指定表中列的值的取值范圍的。例如，在員工信息表中員工年齡的列，如果要使員工年齡列的值為18～50，就可以使用檢查約束進行設置，當輸入的值不在有效范圍內時，就會出現錯誤。這樣就保證了數據庫中數據的有效性。

（5）非空（not null）約束

非空約束是用來約束表中的列不允許為空的。例如，在員工信息表中員工身份證號碼列，要求員工必須輸入時，可以使用非空約束來保證該列不能為空。

3.1.5 數據庫設計的完整性

使用數據庫約束就是保證數據庫完整性的方法。數據庫設計的完整性實際上就是為了保證數據的正確性。為了保證數據的正確性，在Oracle 11g中涉及的完整性主要有3個，即實體完整性、區域完整性、參照完整性。

1. 實體完整性

實體完整性要求表中的主鍵字段都不能為空或者重復的值。例如，在學校里每個學生的學號是唯一的，銀行卡的卡號也是唯一的，每個人的身份證號碼都是唯一的等。

2. 區域完整性

區域完整性是保證輸入到數據庫中的數據是在有效范圍內的，可以使用3.1.4小節中講的檢查約束來設置。例如，輸入郵箱的字段要求要有@，輸入身份證號碼要有15位或18位，輸入年齡只能是數字，輸入姓名不能有字母等。

3. 參照完整性

參照完整性可以保證數據庫中相關聯的表里面數據的正確性，使用用3.1.4小節講的外鍵約束就可以保證參照完整性。確保數據表的參照完整性，就可以避免誤刪和錯加數據。例如，學生選課，如果學生已經選修了某門課程，但是管理員錯誤地把學生選的課程刪除了，那么就會造成學生選修了課程但是無法上課，使用參照完整性設計數據表就會避免類似問題的發生。

3.2 范式—設計關系型數據庫的準則

關系型數據庫是目前流行和使用廣泛的數據庫，關系型數據庫的設計標準就是數據庫的范式，范式分別有第一范式、第二范式、第三范式。

3.2.1 第一范式—關系型數據庫設計的第一步

目前，只要是使用關系型數據庫來設計數據庫，都能夠滿足數據庫設計的第一范式。第一范式（1NF）就是數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性可以是數據庫中任何一種基本數據類型，如整型、字符型、日期型等。只要是關系型數據庫都會滿足第一范式。例如，一個產品信息表(product)，描述產品信息的字段有產品編號、產品名稱、產品數量、產品價格、產品描述，如表3.4所示，那么這個產品信息表就滿足第一范式的要求：每一個字段都是不可再分的單一屬性。

3.2.2 第二范式—關系型數據庫設計的第二步

第二范式是在第一范式的基礎上進一步對關系型數據庫進行規范，官方給出第二范式的定義是要求在數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴。意思就是說在第二范式中組合主鍵（AB）里面的A或者B與其他字段不能存在組合重復。為解決這個問題，通常的做法是不用組合主鍵，添加一個編號列，作為單一主鍵即可滿足第二范式。如果不想添加編號列，就滿足組合主鍵（AB）里面的A或者B與其他字段不能存在組合重復。例如，設計一個購物信息表，字段包括客戶編號、產品名稱、產品數量、產品類型、產品價格、客戶類型。如果用客戶編號和產品名稱作為組合主鍵，那么在組合主鍵中產品名稱和產品類型存在一定關系，是由產品名稱決定產品的類型，所以不符合第二范式的要求，如果不按照第二范式的要求設計表，就會出現以下4個問題：

1. 數據冗余

同一個產品由n個顧客購買，“產品類型”就重復n-1次；同一個顧客購買了多件產品，那么就會多次記錄顧客的個人信息。

2. 更新異常

若調整了某個產品的類型，數據表中所有行的“產品類型”值都要更新，否則會出現同一個產品不同類型的情況。

3. 插入異常

假設新進了一個產品，暫時還沒有人購買。這樣，由于沒有人購買，產品的名稱和類型也無法記錄到數據庫中。

4. 刪除異常

假設一批顧客把已經購買完的商品退貨，這些產品信息就從數據表中刪除了。但是，與此同時，產品名稱和產品類型等信息也被刪除了。這樣就導致了刪除異常。

為了消除數據冗余、更新異常、插入異常和刪除異常，可以把現有的一個表拆分成3張表：

第1張表是產品類型表，表中有產品類型、產品名稱。

第2張表是客戶信息表，表中有客戶編號、客戶類型。

第3張表是產品信息表，表中有產品名稱、產品類型、產品價格、產品數量。

3.2.3 第三范式—關系型數據庫設計的第三步

第三范式是在第二范式的基礎上對數據庫設計進行規范，第三范式的要求是數據表中不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴。所謂傳遞函數依賴，指的是如果存在A決定B、B決定C的決定關系，則C傳遞函數依賴于A。因此，滿足第三范式的數據庫表應該不存在依賴關系，假定員工信息表為employee（員工編號，姓名，年齡，所在部門，部門電話），使用員工編號作為員工信息的主鍵，那么就存在決定關系：員工編號就決定了姓名、年齡、所在部門、部門電話這些字段。從上面的關系可以看出，在表中有一個主鍵，數據表的設計符合第二范式的要求。但是它不符合第三范式的要求，因為存在決定關系：員工編號就決定了所在部門，所在部門又決定了所在部門的電話，那么就存在了傳遞函數依賴關系，即員工編號決定部門電話，那么也會出現不滿足第二范式時的數據冗余和更新、插入、刪除異常的情況。為了滿足第三范式的要求，必須把員工信息表拆分成如下兩個數據表：

員工表：員工編號、姓名、年齡、所在部門；

部門表：部門名稱、部門電話。

3.3 繪制E-R圖設計數據庫

E-R（Entity-Relationship）圖又叫實體-聯系圖，是描述現實世界的概念模型。構成E-R圖的基本要素是實體、屬性和聯系。下面就來詳細地講解如何繪制E-R圖。

3.3.1 繪制E-R圖的基本要素

在E-R圖中涉及的基本要素有實體、聯系以及屬性，下面就對這3個要素進行詳細說明。

（1）實體（Entity）

實體是客觀存在并可以相互區別的事物。實體既可以是人、物，也可以是抽象的概念。例如，一個學生、一個老師、一個產品都可以認為是實體。相同類型的實體可以構成一個實體集。例如，全體學生就是一個實體集。在E-R圖中實體一般用矩形表示，矩形框內寫明實體的名稱。例如，寫一個老師的實體，如圖3.6所示。

（2）屬性（Attribute）

屬性是實體所具有的某一特性，一個實體可由若干個屬性來刻畫。在E-R圖中一般用橢圓形表示，并用無向邊將其與相應的實體連接起來。例如，產品的名稱、價格、類型等都是屬性。例如，給圖3.6的老師實體加上屬性：姓名、年齡、所教專業、所屬院系，如圖3.7所示。

（3）聯系（Relationship）

聯系，即在信息世界中反映實體內部或實體之間的聯系。實體內部的聯系通常是指組成實體的各屬性之間的聯系；實體之間的聯系通常是指不同實體集之間的聯系。在E-R圖中用菱形表示，菱形框內寫明聯系名，并用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型。實體之間存在著3種聯系類型，分別是一對一、一對多、多對多，它們反映到E-R圖中即為相應的聯系類型，即1∶1、1∶n和m∶n。

? 一對一關系（1∶1）

一對一關系是指實體集A與實體集B，A中的每一個實體至多與B實體集中一個實體有聯系；反之，在實體集B中的每個實體至多與實體集A中一個實體有聯系。例如，給學生排座，“學生”實體和“座位”實體之間的關系，每一個學生最多可以分得一個座位，同時每一個座位最多只能有一個學生來坐。用圖形表示如圖3.8所示。

? 一對多關系（1∶n）

一對多關系是指實體集A與實體集B中至少有n（n>0）個實體有聯系，并且實體集B中每一個實體至多與實體集A中一個實體有聯系。例如，“學生”實體和“班級”實體之間的關系，一個班級里面可以有若干個學生，而每一個學生都屬于這個班級。用圖形表示如圖3.9所示。

? 多對多關系（m∶n）

多對多關系是指實體集A中的每一個實體與實體集B中至少m（m>0）個實體有聯系，并且實體集B中的每一個實體與實體集A中的至少n（n>0）個實體有聯系。例如，顧客在商場購買商品，顧客與商品之間就是多對多的關系，每一個顧客都可以購買多種商品，而每一種商品又可以被多個顧客購買。用圖形表示如圖3.10所示。

其實，實體之間的這3種關系，不僅對兩個實體有效，也可以表示多個實體之間的關系。

3.3.2 E-R圖繪制實例

繪制一個網上購物系統的E-R圖，在網上購物系統中簡單分析出顧客、商品、商品類型、訂單4個實體。下面分別繪制每個實體屬性圖并在最后繪制一個整體的E-R圖。

1. 顧客實體屬性圖

顧客實體主要包括用戶編號、姓名、年齡、性別、身份證號、聯系方式、送貨地址、銀行卡卡號8個屬性，實體屬性圖如圖3.11所示。

2. 商品實體屬性圖

商品實體主要包括商品編號、商品名稱、商品價格、商品數量、商品描述5個屬性，實體屬性圖如圖3.12所示。

3. 商品類型實體屬性圖

商品類型實體主要包括商品類型編號和商品類型兩個屬性，實體屬性圖如圖3.13所示。

4. 訂單實體屬性圖

訂單實體主要包括訂單編號、送貨地址、顧客姓名、是否付款、聯系方式、所購商品6個屬性，實體屬性圖如圖3.14所示。

5. 網上購物系統E-R圖

在繪制整體的E-R圖之前，先要了解一下網上購物系統的購物流程。首先由顧客選擇要購買的商品，之后把購買商品的列表生成一個訂單，然后網站的售后人員會根據訂單的地址送貨，在這個網上購物系統里要求一個顧客每次只能生成一個訂單。那么，這4個實體之間是什么關系呢？首先商品和顧客之間的關系是多對多的關系，多個商品可以被一個顧客購買，同時多個顧客也可以購買相同的商品；訂單和商品之間的關系是一對多的關系，一個訂單是由多個商品組成的，多個商品組成一個訂單；顧客和訂單之間的關系是一對一的關系，一個顧客可以生成一個訂單，一個訂單只能屬于一個顧客；商品和商品類型之間的關系是一對一的關系，一個商品屬于一種商品類型。網上購物系統的E-R圖如圖3.15所示。

3.4 小結

通過本章的學習，用戶可以了解數據庫的歷史，掌握關系型數據庫設計的規則，即范式的使用，以及使用E-R圖繪制數據庫中表之間的聯系。這些知識也是數據庫的基礎。此外，本章在介紹數據庫歷史和設計數據庫的基礎上，還對數據庫中常用的術語，即表、視圖、存儲過程、觸發器以及約束做了簡單的介紹，方便讀者學習本書后面的章節。

3.5 習題

簡答題

1. 在數據管理的人工階段，數據的存放主要用什么？

2. 簡述數據庫的三級模式。

3. 什么是E-R圖？并繪制一個選課系統的E-R圖。

4. 設計一張符合第三范式的數據庫表。

5. Oracle 11g是什么類型的數據庫？