450 likes | 671 Views
關聯式模型簡介 Relational Model. 鄧姚文. The Relational Model. 出現: 1970 年代 創造者: E.F. Codd IBM 工程師 數學:關聯式代數( Relational Algebra ) Projection ( π) 投影, 從 R 中選出一組屬性,例如 Selection ( σ ) 選擇, 其中 是邏輯條件式,例如 Natural join (⋈ ) 合併, ,其中 是 笛卡兒積( Cartesian Product ). 關聯式模型重要名詞. Entity :個體 / 實體
E N D
The Relational Model • 出現:1970 年代 • 創造者:E.F. Codd • IBM 工程師 • 數學:關聯式代數(Relational Algebra) • Projection (π)投影,從 R 中選出一組屬性,例如 • Selection (σ)選擇,其中 是邏輯條件式,例如 • Natural join (⋈) 合併,,其中是笛卡兒積(Cartesian Product)
關聯式模型重要名詞 • Entity:個體/實體 • Relation:關聯 • Functional Dependency:功能相依性 • Determinant:決定因子 • Candidate Key:候選鍵 • Composite Key:組合鍵/複合鍵 • Primary Key:主鍵 • Surrogate Key:替代鍵 • Foreign Key:外來鍵/外部鍵 • Referential integrity constraint:參考的完整性限制 • Normal Form:正規化形式
個體Entity • 系統中可供識別(identifiable)的事物 • 我們想要追蹤與紀錄的對象 • 客戶 Customer • 員工 Employee • 訂單 Order • 產品 Product • 供應商 Supplier
關聯Relation • 資料庫中用於儲存資料的機制 • 一種特殊的資料表(Table)具備下列特性: • 一個資料列(Row)儲存一個個體(Entity)的資料 • 資料欄(Column)存放個體(Entity)的屬性(Attribute) • 同一資料欄內的資料項目,資料型態全部相同 • 資料欄的名稱不重複 • 一個儲存隔(Cell)只存放一筆資料 • 資料欄無先後順序(不可強調其順序) • 資料列無先後順序(不可強調其順序) • 每一個資料列都是獨一無二的,資料列的內容不重複
這個資料表不是關聯表! 一個儲存格存放多筆資料!
這個資料表不是關聯表! 資料列的順序必須固定!
功能相依性Functional Dependency • 若屬性A的值可以決定屬性B的值,則B功能相依於A • 學號 學生姓名 • 客戶編號 (客戶名稱, 送貨地址, 客戶電話) • 決定性因子 Determinant • 功能相依性裡,箭頭左邊的項目 • 複合決定因子 Composite Determinant (學號,課號) 成績 小計 = 單價 數量 (單價,數量) 小計 (課號,節次) 教室
功能相依性Functional Dependency • If A (B, C), then A B and A C • If (A,B) C, then neither A nor B determines C by itself • If A B and B C, then A C
關聯表 SKU_DATA 的功能相依性 品項編號 品項描述 買家 部門 Stock Keeping Unit SKU (SKU_Description, Department, Buyer) SKU_Description (SKU, Department, Buyer) Buyer Department
關聯表 ORDER_ITEM 的功能相依性 小計 單價 數量 品項 訂單編號 (OrderNumber, SKU) (Quantity, Price, ExtendedPrice) (Quantity, Price) (ExtendedPrice)
鍵 Keys • A key is a combination of one or more columns that is used to identify rows in a relation • 識別資料列的依據,可以由一個或多個資料欄組成 • A composite key is a key that consists of two or more columns • 組合鍵由多個資料欄組合而成
候選鍵和主鍵Candidate and Primary Keys • A candidate key is a key that determines all of the other columns in a relation • 任何足以作為資料列識別項者,皆為候選鍵 • A primary key is a candidate key selected as the primary means of identifying rows in a relation • 主鍵是從候選鍵之中選出來作為資料列主要識別依據者 • 一個關聯表只有一個主鍵 • 主鍵可以是組合鍵 • 畫底線標示 • 挑選主鍵的方針 • 資料型態越簡單越好 • 每一項個體都一定會有的屬性欄位(必填欄位) • 資料值一旦設定了,就不再變動
會員基本資料 那些是候選鍵? 主鍵是?
替代鍵/代理鍵Surrogate Keys • A surrogate key as an artificial column added to a relation to serve as a primary key • 在找不到適合的主鍵時,人造的欄位,作為主鍵使用 • 通常是一個流水號,也可以制定編碼規則 • MS SQL Server 以 identity 型別支援此功能 • 自動編號 • 對使用者而言,沒有意義 • 通常不顯示在使用者介面上
托售物件資料 Surrogate Key
外來鍵Foreign Keys • A foreign key is the primary key of one relation that is placed in another relation to form a link between the relations • 不是這個關聯表的主鍵,是另一個關聯表的主鍵 • 可以是組合鍵 • 以斜體字標示 • 作為『連結』,是查表的依據 • 參考完整性限制 Referential Integrity Constraint • 如果沒有值就罷了,如果有值就一定要查得到!
外來鍵Foreign Keys 訂單(訂單編號, 客戶編號, 訂單日期, 送貨地址, …) 客戶基本資料(客戶編號, 客戶名稱, 送貨地址, …)
Foreign Key with aReferential Integrity Constraint NOTE: The primary key of the relation is underlined and any foreign keys are in italics in the relations below: SKU_DATA (SKU, SKU_Description, Department, Buyer) ORDER_ITEM (OrderNumber, SKU, Quantity, Price,ExtendedPrice) Where ORDER_ITEM.SKU must exist in SKU_DATA.SKU
正規化形式Normal Forms • 緣由:修改的異常現象(Modification Anomalies) • 刪除資料時的異常現象 Deletion Anomaly • 插入資料時的異常現象 Insertion Anomaly • 更新資料時的異常現象 Update Anomaly
Modification Anomalies 維修金額 品項編號 維修日期 類型 購入金額 維修編號 車床 電鑽 磨 如何插入新品資料(未曾送修過)? 如何刪除『300, Mill 磨』? 如何刪除維修紀錄2300?
Modification Anomalies • The EQUIPMENT_REPAIR table before and after an incorrect update operation on AcquisitionCost for Type = Drill Press: 車床 電鑽 磨
正規化形式Normal Forms • Relations are categorized as a normal form based on which modification anomalies or other problems that they are subject to:
正規化形式Normal Forms • 1NF – A table that qualifies as a relation is in 1NF • 符合關聯表的規範(一個儲存格一筆資料) • 2NF – A relation is in 2NF if all of its non-key attributes are dependent on the whole key, not part of the key • 非鍵欄位和『整個主鍵』功能相依 • 3NF – A relation is in 3NF if it is in 2NF and every non-key attribute is dependent only on the key • 非鍵欄位之間不可以存在功能相依性 • Boyce-Codd Normal Form (BCNF) – A relation is in BCNF if every determinant is a candidate key • 所有的決定性因子都是候選鍵
一個不符合 2NF 的例子 • 客戶資料(分行代碼, 客戶身份證號, 客戶姓名, 貸款金額) • 分行代碼,客戶身份證號→貸款金額 • 客戶身份證號→客戶姓名 • 不符合 2NF,因為『客戶姓名』只和『客戶身份證號』功能相依,而不是和整個主鍵『分行代碼, 客戶身份證號』功能相依 • 改為 • 客戶資料(客戶身份證號, 客戶姓名) • 客戶貸款資料(分行代碼, 客戶身份證號, 貸款金額)
一個不符合 3NF 的例子 • 分店基本資料(分店編號,店長姓名,分店電話,店長電話) • 分店編號 →(店長姓名,分店電話,店長電話) • 店長姓名 → 店長電話 • 不符合 3NF,因為在『店長姓名 → 店長電話』之中,『店長姓名』不是主鍵 • 改為 • 分店資料(分店編號,店長姓名,分店電話) • 店長資料(店長姓名,店長電話)
一個符合 3NF 但是不符合 BCNF 的例子 • 修課資料(學生學號, 課程編號, 授課老師編號, 成績) • 學生學號, 課程編號→成績 • 授課老師編號→課程編號 • 課程編號→授課老師編號 • 學生學號, 授課老師編號→成績 • 符合 3NF,因為沒有非鍵屬性之間的功能相依性,也沒有發生和部分主鍵功能相依的情況 • 不符合BCNF 的原因:『課程編號→授課老師編號』裡『授課老師編號』與『課程編號』都是候選鍵的一部份,但不是完整的候選鍵
一個符合 3NF 但是不符合 BCNF 的例子 • 修改為 • 修課資料1(學生學號, 課程編號, 成績) • 授課資料(課程編號, 授課老師編號)
消除因為功能相依性造成的異常現象 • 所有的關聯表都正規化至 BCNF
將 EQUIPMENT_REPAIR 正規化為 BCNF EQUIPMENT_REPAIR (ItemNumber, Type, AcquisitionCost,RepairNumber, RepairDate, RepairAmount) ItemNumber (Type, AcquisitionCost) RepairNumber (ItemNumber, Type, AcquisitionCost,RepairDate, RepairAmount) ITEM (ItemNumber, Type, AcquisitionCost) REPAIR (ItemNumber, RepairNumber, RepairDate, RepairAmount) Where REPAIR.ItemNumber must exist inITEM.ItemNumber
將 SKU_DATA 正規化為 BCNF SKU_DATA (SKU, SKU_Description, Department, Buyer) SKU (SKU_Description, Department, Buyer) SKU_Description (SKU, Department, Buyer) Buyer Department SKU_DATA (SKU, SKU_Description, Buyer) BUYER (Buyer, Department) Where BUYER.Buyer must exist in SKU_DATA.Buyer
範例:學生社團 • 學生社團(學號, 姓名, 社團, 社費, 已收金額)
範例:學生社團 • 學生社團(學號, 姓名, 社團, 社費, 已收金額) • 學號→姓名 • 社團→社費 • (學號, 社團) →已收金額 • 分解為: • 學生(學號, 姓名) • 社團(社團, 社費) • 繳費狀況(學號, 社團, 已收金額)
範例:產品與部門 • SKU_DATA_3(SKU, SKU_Description, Department, Dept_BudgetCode, Buyer) 部門預算代碼
範例:產品與部門 • SKU→(SKU_Description, Department, Dept_BudgetCode, Buyer) • SKU_Description →(SKU, Department, Dept_BudgetCode, Buyer) • Buyer →(Department, Dept_BudgetCode) • Department →Dept_BudgetCode
範例:產品與部門 • 第一回合分解:依Buyer →(Department, Dept_BudgetCode) • BUYER(Buyer, Department, Dept_BudgetCode) • SKU_DATA_4(SKU, SKU_Description, Buyer) • 第二回合分解:依Department →Dept_BudgetCode • BUYER_2(Buyer, Department) • DEPARTMENT(Department, Dept_BudgetCode)