關聯式資料庫設計
設K為關係模式R中的屬性或屬性組合,若 ,則K為R的候選碼。若候選碼多於一個,則選定其中一個為主碼。
包含在任何一個候選碼中的屬性,叫做主屬性。不包含在任何碼中的屬性稱為非主屬性或非碼屬性。最簡單的情況,單個屬性是碼。最極端的情況,整個屬性組是碼,稱為全碼。
[@more@]設K為關係模式R中的屬性或屬性組合,若 ,則K為R的候選碼。若候選碼多於一個,則選定其中一個為主碼。
包含在任何一個候選碼中的屬性,叫做主屬性。不包含在任何碼中的屬性稱為非主屬性或非碼屬性。最簡單的情況,單個屬性是碼。最極端的情況,整個屬性組是碼,稱為全碼。
關聯式資料庫設計之時是要遵守一定的規則的。尤其是資料庫設計正規化現簡單介紹1NF(第一正規化),2NF(第二正規化),3NF(第三正規化)和BCNF,另有第四正規化和第五正規化留到以後再介紹。 在你設計資料庫之時,若能符合這幾個正規化,你就是資料庫設計的高手
第一正規化(1NF):在關係模式R中的每一個具體關係r中,如果每個屬性值都是不可再分的最小資料單位,則稱R是第一正規化的關係。例:如職工號,姓名,電話號碼組成一個表(一個人可能有一個辦公室電話和一個家裡電話號碼) 規範成為1NF有三種方法:
一是重複儲存職工號和姓名。這樣,關鍵字只能是電話號碼。
二是職工號為關鍵字,電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字,但強制每條記錄只能有一個電話號碼。
以上三個方法,第一種方法最不可取,按實際情況選取後兩種情況。
第二正規化(2NF):如果關係模式R(U,F)中的所有非主屬性都完全依賴於任意一個候選關鍵字,則稱關係R 是屬於第二正規化的。
例:選課關係 SCI(SNO,CNO,GRADE,CREDIT)其中SNO為學號, CNO為課程號,GRADEGE 為成績,CREDIT 為學分。 由以上條件,關鍵字為組合關鍵字(SNO,CNO)
在應用中使用以上關係模式有以下問題:
a.資料冗餘,假設同一門課由40個學生選修,學分就重複40次。
b.更新異常,若調整了某課程的學分,相應的元組CREDIT值都要更新,有可能會出現同一門課學分不同。
c.插入異常,如計劃開新課,由於沒人選修,沒有學號關鍵字,只能等有人選修才能把課程和學分存入。
d.刪除異常,若學生已經結業,從當前資料庫刪除選修記錄。某些門課程新生尚未選修,則此門課程及學分記錄無法儲存。
原因:非關鍵字屬性CREDIT僅函式依賴於CNO,也就是CREDIT部分依賴組合關鍵字(SNO,CNO)而不是完全依賴。
解決方法:分成兩個關係模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新關係包括兩個關係模式,它們之間透過SC1中的外關鍵字CNO相聯絡,需要時再進行自然聯接,恢復了原來的關係
第三正規化(3NF):如果關係模式R(U,F)中的所有非主屬性對任何候選關鍵字都不存在傳遞信賴,則稱關係R是屬於第三正規化的。
例:如S1(SNO,SNAME,DNO,DNAME,LOCATION)各屬性分別代表學號,
姓名,所在系,系名稱,系地址。
關鍵字SNO決定各個屬性。由於是單個關鍵字,沒有部分依賴的問題,肯定是2NF。但這關係肯定有大量的冗餘,有關學生所在的幾個屬性DNO,DNAME,LOCATION將重複儲存,插入,刪除和修改時也將產生類似以上例的情況。
原因:關係中存在傳遞依賴造成的。即SNO -> DNO。 而DNO -> SNO卻不存在,DNO -> LOCATION, 因此關鍵遼 SNO 對 LOCATION 函式決定是透過傳遞依賴 SNO -> LOCATION 實現的。也就是說,SNO不直接決定非主屬性LOCATION。
解決目地:每個關係模式中不能留有傳遞依賴。
解決方法:分為兩個關係 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)
注意:關係S中不能沒有外關鍵字DNO。否則兩個關係之間失去聯絡。
BCNF:如果關係模式R(U,F)的所有屬性(包括主屬性和非主屬性)都不傳遞依賴於R的任何候選關鍵字,那麼稱關係R是屬於BCNF的。或是關係模式R,如果每個決定因素都包含關鍵字(而不是被關鍵字所包含),則RCNF的關係模式。
例:配件管理關係模式 WPE(WNO,PNO,ENO,QNT)分別表倉庫號,配件號,職工號,數量。有以下條件
a.一個倉庫有多個職工。
b.一個職工僅在一個倉庫工作。
c.每個倉庫裡一種型號的配件由專人負責,但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析:由以上得 PNO 不能確定QNT,由組合屬性(WNO,PNO)來決定,存在函式依賴(WNO,PNO) -> ENO。由於每個倉庫裡的一種配件由專人負責,而一個人可以管理幾種配件,所以有組合屬性(WNO,PNO)才能確定負責人,有(WNO,PNO)-> ENO。因為 一個職工僅在一個倉庫工作,有ENO -> WNO。由於每個倉庫裡的一種配件由專人負責,而一個職工僅在一個倉庫工作,有 (ENO,PNO)-> QNT。
找一下候選關鍵字,因為(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此(WNO,PNO)可以決定整個元組,是一個候選關鍵字。根據ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能決定整個元組,為另一個候選關鍵字。屬性ENO,WNO,PNO 均為主屬性,只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函式依賴的,並且是直接依賴,所以該關係模式是3NF。
分析一下主屬性。因為ENO->WNO,主屬性ENO是WNO的決定因素,但是它本身不是關鍵字,只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字(ENO,PNO)的部分依賴,因為(ENO,PNO)-> WNO但反過來不成立,而ENO->WNO,故(ENO,PNO)-> WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴,但存在主屬性對候選關鍵字的傳遞依賴,同樣也會帶來麻煩。如一個新職工分配到倉庫工作,但暫時處於實習階段,沒有獨立負責對某些配件的管理任務。由於缺少關鍵字的一部分PNO而無法插入到該關係中去。又如某個人改成不管配件了去負責安全,則在刪除配件的同時該職工也會被刪除。
解決辦法:分成管理EP(ENO,PNO,QNT),關鍵字是(ENO,PNO)工作EW(ENO,WNO)其關鍵字是ENO
缺點:分解後函式依賴的保持性較差。如此例中,由於分解,函式依賴(WNO,PNO)-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫裡一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此,分解之後的關係模式降低了部分完整性約束。
一個關係分解成多個關係,要使得分解有意義,起碼的要求是分解後不丟失原來的資訊。這些資訊不僅包括資料本身,而且包括由函式依賴所表示的資料之間的相互制約。進行分解的目標是達到更高一級的規範化程度,但是分解的同時必須考慮兩個問題:無損聯接性和保持函式依賴。有時往往不可能做到既有無損聯接性,又完全保持函式依賴。需要根據需要進行權衡。
1NF直到BCNF的四種正規化之間有如下關係:
BCNF包含了3NF包含2NF包含1NF
小結:
目地:規範化目的是使結構更合理,消除儲存異常,使資料冗餘儘量小,便於插入、刪除和更新
原則:遵從概念單一化 "一事一地"原則,即一個關係模式描述一個實體或實體間的一種聯絡。規範的實質就是概念的單一化。
方法:將關係模式投影分解成兩個或兩個以上的關係模式。
要求:分解後的關係模式集合應當與原關係模式"等價",即經過自然聯接可以恢復原關係而不丟失資訊,並保持屬性間合理的聯絡。
注意:一個關係模式結這分解可以得到不同關係模式集合,也就是說分解方法不是唯一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有資訊為前提來實現。其根本目標是節省儲存空間,避免資料不一致性,提高對關係的操作效率,同時滿足應用需求。實際上,並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便資料查詢。尤其對於那些更新頻度不高,查詢頻度極高的資料庫系統更是如此。
在關聯式資料庫中,除了函式依賴之外還有多值依賴,聯接依賴的問題,從而提出了第四正規化,第五正規化等更高一級的規範化要求。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7718881/viewspace-1001379/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 物件導向的關聯式資料庫設計(轉)物件資料庫
- 關聯式資料庫索引設計和優化器前言資料庫索引優化
- 關聯式資料庫的幾種設計正規化資料庫
- 銀聯分散式資料庫安全設計分散式資料庫
- Web Sql 關聯式資料庫WebSQL資料庫
- 關聯式資料庫之父 (轉)資料庫
- 關聯式資料庫與文件資料庫對比資料庫
- 關聯式資料庫很快會替代向量資料庫資料庫
- 關聯式資料庫分片原則資料庫
- 關聯式資料庫 Query_Execution資料庫
- 資料庫 - 關聯式資料庫標準語言SQL資料庫SQL
- 從關聯式資料庫遷移到NoSQL雲資料庫資料庫SQL
- 【轉載】關聯式資料庫還是NoSQL資料庫資料庫SQL
- 關聯式資料庫的封建迷信資料庫
- 從關聯式資料庫遷移到CouchDB資料庫
- 從關聯式資料庫向NoSQL遷移資料庫SQL
- 關聯式資料庫SQL語言略解資料庫SQL
- 事件溯源將顛覆關聯式資料庫! - Remy事件資料庫REM
- 事件溯源超越關聯式資料庫 - confluent事件資料庫
- 規劃關聯式資料庫學習筆記資料庫筆記
- 在關聯式資料庫中儲存RDF (轉)資料庫
- 關聯式資料庫SQL語言詳解(轉)資料庫SQL
- 設計資料庫關係模型資料庫模型
- 鍵值資料庫與關聯式資料庫有沒有融合的可能?資料庫
- 資料庫關聯問題資料庫
- 響應式關聯式資料庫處理R2DBC資料庫
- 主流關聯式資料庫鎖實現的區別資料庫
- 關聯式資料庫比較:SQLite vs MySQL vs PostgreSQL資料庫SQLiteMySql
- 關聯式資料庫和NoSQL結合使用:MySQL + MongoDB資料庫MySqlMongoDB
- NoSQL資料庫探討之一 - 為什麼要用非關聯式資料庫?SQL資料庫
- 【資料庫設計】資料庫的設計資料庫
- 如何將傳統關聯式資料庫的資料匯入Hadoop?資料庫Hadoop
- 使用反應式關聯式資料庫連線規範R2DBC操作MySQL資料庫資料庫MySql
- 資料庫系統原理-關聯式資料庫的規範化理論總結資料庫
- 基於記憶體的關聯式資料庫memsql初探記憶體資料庫SQL
- 寫給關聯式資料庫開發者的 TDengine 入門指南資料庫
- 分散式資料庫設計10-14分散式資料庫
- 金融級分散式關聯式資料庫OceanBase 2.2版正式釋出分散式資料庫