第八周翻譯
數據庫設計三級階梯:構建表
通過喬Celko,2013/09/18(第一次出版:2010/05/25)
該系列
本文是樓梯系列的一部分:數據庫設計的階梯
新設計和創建一個數據庫的任務嗎? 喬Celko,誰是最被廣泛閱讀的作家之一對SQL,解釋了基礎知識。 像往常一樣,他想到偶爾的驚喜,即使最老練的專業數據庫。 喬是DBMS的贏家連續四年雜誌讀者選擇獎。 他教會了SQL在美國、英國、北歐國家,南美和非洲。 他10年ANSI / ISO SQL標準委員會和導致SQL - 89和SQL - 92標準。
有幾種類型的表,各有其特殊的要求和完整性約束規則。 無論要求,表級約束將確保規則執行和數據完整性得到維護。
在一級,我們命名數據元素是什麽和分類。 在兩個水平,我們建模的數據元素的數據類型和約束在SQL給我們行。 在三個水平,我們要把這些行成表。 表不僅僅是一群行收集在一起下一個名字。
一列在一個表中只能出現一次。 只有有意義; 如果你兩次記錄別人的鞋碼,最好將冗余和模棱兩可的列不同意。 現在我們可以表檢查約束水平在每一行的列。 他們並不是真的那麽多不同的比列我們之前檢查約束。 他們可以命名,並將出現在列表中列在CREATE TABLE語句中聲明,不附加到任何行。。 例如:
約束Valid_Employee_Age——不要雇人在他們出生之前
檢查(emp_birth_date < emp_hire_date)
通常是一個好主意不是將約束結合到一個巨大的檢查()條款。 錯誤消息將包括約束的名稱,所以單獨的約束將會給你一個更好的主意出現了什麽問題比一個怪物叫“Bad_Things_Happened”約束。
繼續我們仇恨的冗余,在表級別我們希望每一行是獨特的因為同樣的原因。 這個可以用表約束。 這兩個表級約束是唯一的主鍵,這在一個或多個列的版本。
獨特的約束表示表中的列或列的組合是獨一無二的。 但是如果有一個空的一個或多個列,我們將允許它,就好像它是一個獨特的價值。 主鍵宣言有同樣的效果為NOT NULL和獨特的所有列。 但由於歷史原因,聲明一個表只能有一個主鍵。 這些列作為默認值對於其他表之間的約束,但是不要擔心。
如何使用唯一性約束取決於類型的表。 一般來說,我們可以將一個表的三種類型:
- 實體
- 的關系
- 輔助
一個實體表是一組同樣的事情列定義的屬性建模。 每一行是一個實例的那種東西。 每一行有相同的列。 如果你能看到它的感覺,看到或觸摸它,那麽它是一個實體。 實體表的名字不應該是單數(除非真的有一只這組的成員),因為它一組模型。需要復數或名稱,如果可能的話,集體。 例如,“員工”不好,“員工”是更好,“人員”是最好的。 “樹”不好,“樹”是更好,“森林”是最好的。 您可以添加您自己的例子。
實體也被歸類為弱或強。 一個強大的實體存在於自己的優點,而弱實體存在,因為一個或多個強大的實體。 你需要購買之前,你可以有一個折扣。
一個關系表引用一個或多個實體和它們之間建立一個關系。 一個關系可以有自己的屬性除了對實體的引用。 婚姻登記號碼屬於婚姻,而不是丈夫,妻子或部長。
的程度的關系是實體的數量關系。 二元關系有兩個實體,我們喜歡他們在現實世界中,因為它們很簡單。 一個遞歸二元關系與一個實體本身。 一般包括n n元關系實體,如住房抵押貸款與買方,賣方和銀行。 不可能總是n元關系分解為二元關系。 成員的關系可以是可選的或強制性的。 可選的會員意味著我們可以有零個實體的一種——購買並不總是得到一個折扣。
關系的實際數量的基數相關事件的兩個實體。 連接關系的基本類型有:一對一、一對多、多對多。 這些術語通常是合格的可選(0或多個)或強制(1或更多)會員資格。
一對一的最多(1:1)的關系是當一個實例的實體與一個實例相關聯的實體b .例如,采取傳統的丈夫和妻子之間的關系。 每個丈夫都有且只有一個妻子; 每個妻子都有且只有一個丈夫。 在這個例子中都是強制性的。
一對多(1:n)的關系是當一個實例的實體,零,一個或多個實例的實體B B,但對一個實例的實體只有一個實例的實體A一個例子可能是一個部門有許多雇員; 每個員工被分配給一個部門。 根據您的業務規則,你可能會允許一個未派職務的員工或一個空的部門。
多對多關系(m:n),有時被稱為非特異性,是當一個實體的實例,有0,1,或許多實例的實體B和實體B有0的一個實例,一個或多個實體的實例A一個例子可能是披薩和客戶。
一個輔助表既不是一個實體,也不是一個關系; 它提供信息。 他們像日歷或其他替代計算在SQL的查找表。 他們常常被誤解,當作實體或關系表。
讓我們使這個更具體。 銷售訂單是客戶(實體)之間的關系和我們的庫存(實體)。 訂單細節是弱實體存在,因為我們有一個訂單。 的關系有一個訂單號,不是庫存或客戶的一部分。 運輸成本從一個輔助表。 這裏有一些骨架表對於這個示例。 我使用GTIN(全球貿易項目編號)訂單項和兔褐(數據統一編號系統)的客戶。 總是尋找行業標準,當你設計一個數據庫。
創建表Sales_Orders
(order_nbr整數非空主鍵
檢查(order_nbr > 0),
customer_duns CHAR(9)不是零,
order_shipping_amt十進制(5,2)NOT NULL
檢查(shipping_amt > = 0.00),
等);
創建表Sales_Order_Details
(order_nbr整數非空,
gtin CHAR(15)不是零,
主鍵(order_nbr gtin),
item_qty整數非空
檢查(item_qty > 0),
item_unit_price十進制(8,2)NOT NULL
檢查(item_unit_price > = 0.00));
創建表的客戶
(customer_duns CHAR(9)NOT NULL主鍵
檢查(customer_duns像“[0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9]”),
等);
創建表的庫存
(gtin CHAR(15)NOT NULL主鍵
檢查(gtin像“[0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9]”),
onhand_qty整數非空
檢查(onhand_qty > = 0),
我們可以看到,銷售訂單是客戶和庫存之間的關系。 訂單有自己的關鍵(order_nbr)但是沒有強迫我們只使用有效客戶兔褐數字或產品GTIN編碼的事情我們有庫存。 事實上,我可以將明顯無效的兔褐和GTIN代碼插入Orders表這樣的聲明。
這是引用條款的由來。 這就是讓我們執行所有的基數和學位從數據模型。 不是一個鏈接或一個指針的引用。 這是物理概念和參考是一個邏輯概念,我們不知道它是如何實現的。 它執行的是一條規則,引用表列匹配引用表中的一行。 這意味著引用表中的行必須是獨特的; 默認情況下,引用表的主鍵是目標,但它dos不是必須的。 引用表中的值被稱為外鍵表——他們不是鑰匙,但其他地方的模式。
這是與更多的肉骨架模式:
創建表Sales_Orders
(order_nbr整數非空主鍵
檢查(order_nbr > 0),
customer_duns CHAR(9)不是零
引用客戶(customer_duns),
order_shipping_amt小數(5,2)默認0.00 NOT NULL
檢查(shipping_amt > = 0.00),
等);
創建表Sales_Order_Details
(order_nbr整數不是零
引用訂單(order_nbr),
gtin CHAR(15)不是零
引用庫存(gtin),
主鍵(order_nbr gtin)——兩個列的關鍵
item_qty整數非空
檢查(item_qty > 0),
item_unit_price十進制(8,2)NOT NULL
檢查(item_unit_price > = 0.00));
創建表的客戶
(customer_duns CHAR(9)NOT NULL主鍵
檢查(customer_duns像“[0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9]”),
等);
創建表的庫存
(gtin CHAR(15)NOT NULL主鍵
檢查(gtin像“[0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9][0 - 9]”),
onhand_qty整數非空
檢查(onhand_qty > = 0),
等);
註意,我們只有檢查()約束的地方兔褐和GTIN鑰匙,不出現在引用表。 引用的實體表、客戶和庫存; 關系表、訂單、引用其他表。 這是一個通用的模式,但它不是設置在混凝土。
這個條款的多個列的形式是這樣的:
外鍵(order_nbr gtin)
引用Sales_Order_Details(gtin order_nbr)
列引用表中的外鍵副條款中引用鍵必須匹配,列的列,但可能有不同的名稱。 我可以得到1:1,1:n和n:m關系通過唯一性約束在正確的地方。 腋表的一個例子,我們可以計算出運輸成本基於訂單的總價值。 表可能看起來像這樣:
創建表Shipping_Costs
(start_order_amt_tot小數(10、2)非空,
end_order_amt_tot小數(10、2)非空,
約束Valid_Shipping_Range
檢查(start_order_amt_tot < end_order_amt_tot),
主鍵(start_order_amt_tot end_order_amt_tot),
shipping_amt十進制(5,2)NOT NULL
檢查(shipping_amt > 0.00));
雖然我們已經宣布在輔助運輸成本表主鍵,它不像實體的鍵——沒有確認或驗證,它不是一個標識符。 使用此表,我們將查詢的時候可以這樣說:
選擇shipping_amt
從Shipping_Costs
其中<訂單總金額> start_order_amt_tot和end_order_amt_tot之間;
作為練習,試著寫一個約束,防止開始和結束範圍重疊和空白。 如果你需要可以重新設計表。
在修改後的骨架模式中,當你試圖把訂單沒有庫存的產品,你會得到一個錯誤,說,實際上,“這是脫銷! “你可以嘗試別的東西。 但如果你嘗試刪除一個產品庫存,您還將得到一個錯誤實際上說,“嘿,有人命令這個垃圾”,所以你必須去每個訂單和用別的東西代替的項目或NULL(如果允許)之前您可以刪除它從庫存。
這就是聲明引用完整性(DRI)操作。 的語法是:
在刪除任何行動|設置默認零| |設置級聯)
在更新任何行動|設置默認零| |設置級聯)
刪除和更新被稱為“數據基礎事件”; 當他們發生在桌上,然後DRI行動發生。
- 沒有ACTION =事務回滾,你會得到一個消息。 這是默認條款當你只是有一個簡單的引用。
- 設置默認=引用的列(s)都隨著時間的改變而改變,但引用列更改為默認值。 顯然,引用列需要違約聲明。 這些默認值必須在引用表中。
- 設置空=引用的列(s)都隨著時間的改變而改變,但引用列更改為NULL。 顯然,需要NULL-able引用列。 這就是“無罪推定”為null。
- 級聯=引用的列(s)改變的事件,和級聯到相同的值引用列。 在實踐中這是最重要的選擇。 例如,如果我們想要停止一個產品,我們可以刪除它從庫存和級聯刪除將SQL引擎Sales_Order_Details自動刪除匹配的行。 同樣地,如果你更新一個項目在庫存,在級聯更新將專制地將舊值替換為新的地方引用它。
在執行這些動作之後,引用完整性約束仍然有效。 這是最後一個框架:
創建表Sales_Orders
(order_nbr整數非空主鍵
檢查(order_nbr > 0),
customer_duns CHAR(9)不是零
引用客戶(customer_duns)
在級聯更新
在級聯刪除,
order_shipping_amt小數(5,2)默認0.00 NOT NULL
檢查(shipping_amt > = 0.00),
等);
創建表Sales_Order_Details
(order_nbr整數不是零
引用訂單(order_nbr)
在級聯更新
在級聯刪除,
gtin CHAR(15)不是零
引用庫存(gtin)
在級聯更新
在級聯刪除,
主鍵(order_nbr gtin)——兩個列的關鍵
item_qty整數非空
檢查(item_qty > 0),
item_unit_price十進制(8,2)NOT NULL
檢查(item_unit_price > = 0.00));
看你能不能找出當:
- 客戶死了,我們刪除了他。
- 我們改變草坪Gnome雕像更雅致的粉紅色的火烈鳥。
- 我們停止了粉紅色的火烈鳥。
- 有人試圖順序步驟1到3後草坪Gnome
顯然,我離開補充問題,其他的事情,但我們會得到的。
該系列
讀到的其余部分數據庫設計系列的樓梯並查看其他文章。
第八周翻譯