文章

目前顯示的是 四月, 2015的文章

關聯模式的五大鍵 Super key、Candidate Key、Primary Key、Alternate Key、Foreign Key

關聯模式的五大鍵,各是Super key、Candidate Key、Primary Key、Alternate Key、Foreign Key。靠著這些鍵的特性,讓關聯模式可以用來描述實體世界的資料。 關聯模式 可以比實體關係模式(ERM)更精準的描述資料,他有幾個條件必須滿足: (1)定義域限制: 指資料庫的關聯中的每個屬性質,必須符合該屬性的定義,例如產品名稱必須是字串,薪水必須是整數數字等。 (2)關聯鍵限制: 指資料庫的關聯中必須有關聯鍵的定義,也就是Super key、Candidate Key、Primary Key、Alternate Key、Foreign Key。這些定義我們稍後再來解釋。 (3)實體完整限制: 如果關聯存在主鍵(Primary Key),則不能為空。因為如果為空值,無法得知其相關的屬性值到底是描述哪一個實體。 (4)參考完整限制: 如果關聯存在外鍵(Foreign Key)為非空值,必須有可以參考的主鍵(Primary Key)。因為如果外鍵存在,而無法關連到其他表格的主鍵,這個關聯存在就沒有意義。 (5)語意完整限制: 這個限制不是必須的,但是可以更完備的描述實體世界的資料。例如交易金額高於100元才可以使用信用卡付款等。 例如,我們原本沒有限制 orderitem中的amount數字,但是如果我們為了~語意完整限制 訂購項目的數量當然不能小於1,所以寫了以下的語法,amount=0就無法插入。 delimiter $$ create trigger test_insert_orderitem before insert on orderitem for each row begin    if amount<1 then       signal sqlstate '2A000';    end if; end$$ delimiter ; 當我們 drop trigger test_insert_orderitem; 之後,amount=0就又可以插入了。 現在,我們再來解釋關聯模式五個關聯鍵定義。 Super key 超鍵 : 符合唯一性的關聯鍵。 Candidate Key 候選鍵 : 符合唯一性以及最小性的關聯鍵。 Primary Key 主鍵

Data Modeling (資料塑模) : 概念塑模、邏輯塑模、實體塑模

圖片
Data Modeling (資料塑模) 就是一種程序,用來定義跟分析資料需求,來支援某個商業程序。 下面就是維基百科所描述的資料塑模方法: 但是以上的方法,先經過邏輯塑模(Logical Data Model),再經過概念塑模(Conceptual Data Model),最後進行實體塑模(Physical Data Model)。 我們建議資料塑模,使用下圖的方式: 也就是先經過概念塑模(Conceptual Data Model),然後進行邏輯塑模(Logical Data Model),最後進行實體塑模(Physical Data Model)。 概念塑模(Conceptual Data Model)使用的工具,就是實體關係模型(Entity Relationship Model),最後會產生實體關係圖(Entity Relationship Diagram)。 邏輯塑模(Logical Data Model)使用的工具,就是關聯模型(Relational Model),最後會產生資料表的定義關聯綱目(schema)。 實體塑模(Physical Data Model)使用的工具,就是資料庫管理系統,或是 SQL語法,最後會產生真正的實體資料表。 為什麼要先進行概念塑模(Conceptual Data Model)呢? 因為實體關係模型比較適合從無到有去產生資料模型,而實體關係模型比較不精準的特性,再由邏輯塑模來修正。

實作練習~公司員工訂餐系統

圖片
某公司希望設計一個提供員工中午訂餐的服務,該系統需求如下: (1)該系統有數個餐廳的餐點提供員工點餐。 (2)該系統在每天早上讓員工線上點餐。 (3)為方便結帳,該系統採用預付制,也就是先存錢給秘書,然後依照訂餐扣款。 (4)希望每個訂餐依照所訂購的每位同事帳戶下扣款。 (5)每個每個人可以訂購多項餐點,也可以跨不同餐廳訂購。 (6)員工帳戶資料要能夠記載預付時間、金額,以及扣款時間、金額及對應的餐點。 (7)該系統必須能夠提供每位員工統計報告,記載每月的餐費。 (8)該系統必須能夠統計各餐廳/餐點的消費紀錄,以便知道員工對於餐廳/餐點的喜好。 該系統的 ERD應該如何設計呢? 該系統的實際資料庫應該如何設計呢? 步驟一: 先找出物件 (Entity) 員工(Employee)、餐廳(Restaurant)、餐點(Item)、帳戶(Account)、帳戶紀錄(Account Log)、訂單(Order)、訂單紀錄(Order Item),我們也可以再多出一個部門物件,以紀錄員工的部門。 所以總共八個物件。 步驟二: 再找出物件間的關係 (Relationship) 餐廳(Restaurant) --> 餐點(Item) 員工(Employee) --> 訂單(Order) 訂單(Order) --> 訂單紀錄(Order Item) 訂單(Order) --> 帳戶紀錄(Account Log) 員工(Employee) --> 帳戶(Account) 帳戶(Account) --> 帳戶紀錄(Account Log) 訂單紀錄(Order Item) --> 餐點(Item) 員工(Employee) --> 部門(Department) 步驟三: 檢視ERD的可能錯誤,及補上應該補上的屬性 (Attribute) 員工(Employee) : 員工編號(eid) 、部門編號(did)、姓名(ename) 部門(Department) : 部門編號(did) 、部門名稱(dname) 餐廳(Restaurant) : 餐廳編號(rid) 、餐廳名稱(rname) 餐點(Item) : 餐廳編號(rid)、餐點流水號(serial) 、