（二）資料庫設計

基本數據關係

實體就是我們存儲的數據，例如一個訂單或者醫生的預約。它是抽象的，就好比我說人。你應該想到的是一個鼻子兩隻眼的那種動物，而不是小姐姐這個具體的人（我想到的就是她）。

一旦你對資料庫中的基本實體有了想法，那麼你的下一個任務就是確定實體間的關係。目前有可能會遇到三種實體關係：

• 一對一(1:1)
• 一對多(1:n)
• 多對多(n:n)

心中謹記：提及的關係，是實例間的關係。客戶是一個實體，張三是客戶的一個實例；書是一個實體，《金瓶梅》是書的一個實例。只有張三可以和《金瓶梅》發生關係，而客戶和書都是實體，是抽象的（至少我不同意它們發生關係）。同時，關係也不是強制發生的。正如李四是一個客戶的實例，但是他完全可能不買任何書啊，而只買光碟啊。那麼李四和書的實例沒有關係。我的天啊，我都在說些什麼！這還是在說技術？

一對一關係

城市和機場都是實體，一個小城市 C 的機場 J 可以被描述為「這個機場坐落在一個並且是唯一的城市，和這個城市有且僅有一個機場。」這就是一個典型的一對一關係，因為無論是城市C不可能和其他機場發生關係，機場J亦如是。

噫吁戲，一對一在現實中並不多見。如果你發現自己正在處理一個一對一關係（比如妹子答應你去吃飯），記得多扇自己幾個大嘴巴子並告訴自己工頭一會就要過來派磚頭了。

一對多關係

這是最常見的關係（被你追的妹子是那個「一」。。。。）這種關係不強制建立的，交易自由，買賣不成仁義在！一台電腦可以有零個、一個、二個或以上數量的GPU。

多對多關係

這種關係也很常見。一個糙漢可以同時追很多妹子，一個妹子同時被巨多糙漢追。還是要記住，這種關係不是強制建立的，完全有可能出現糙漢不追妹子追漢子的情況。

資料庫設計中多對多關係有兩大問題在後邊有提到，先再心裡mark一下。

弱實體和強關係

此前多次提及，關係的非必要性，不能霸王硬上弓。一個實體完全可能沒有關係。但是在某些情況這種情況是不存在的，如張三的《金瓶梅》訂單JPM。張三沒有這個訂單可以存在，但是訂單JPM必須依賴張三存在。因而訂單這個實體就被叫做弱實體，它們之間的關係也被稱為強關係。確定資料庫中的弱關係和強聯繫對維護連續性和整體性至關重要。

同多對多關係打交道

資料庫設計中多對多關係有兩大問題：

• 關係數據模型無法直接處理多對多關係，囿於一對一和一對多關係。你可能需要將多對多關係分解為一群一對一和一對多關係，如果你使用關係型DBMS的話；
• 有點難，我舉一個??。一個訂單里可以有多種商品（每種商品的數量會變化），而一種商品（數量可變）又可以包含在多個訂單中，這是一個多對多關係。問題是：購買的商品的數量包含在哪裡？它不可以包含在訂單實體中，因為商品的數量還取決於某一中商品（如果一個訂單包含多個商品，那麼怎麼用一個數字去表示多個商品的數量？）；也不可以包含在商品實體中，因為沒有訂單哪來的商品和商品數量（那麼多訂單，你在商品實體中用一個數字怎麼表示那麼多訂單）？

這個尷尬被稱為關係數據，此數據作用於兩個實體之間的關係，而非實體們自己。然而，關係是不能有屬性啊。我們由此有必要定義一個實體來完成兩個實體關係的定義，從而讓該數據依附。

複合實體

複合實體的存在是為了表達兩個或以上實體間的關係。如上述的訂單-商品關係，我們需要的是一個實體告訴我們一個具體訂單的具體標題。三個訂單訂購了五種商品。中間一層包含了五種複合實體，稱之為單項產品(line item，類似流水單上的一項)。這一層的出現只是為了表示訂單和商品間的關係。

數據模型 VS 數據流

數據流在一個組織中被處理，包括了誰處理了數據、哪裡存儲數據以及數據做了哪些操作。相反，數據模型描述了數據的內部、邏輯關係，不關係誰動了數據或怎麼動了數據。

越看小姐姐越喜愛！