數據庫設計中ER模型設計問題范文

本站小編為你精心準備了數據庫設計中ER模型設計問題參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

摘要：數據庫設計中的概念結構設計階段是一個復雜過程，學生在設計時往往不能很快的上手，或者設計出來的er圖不合理或錯誤。本文針對學生在設計時易出現的問題和難點進行分析，通過一個設計好的ER圖剖析其中存在的問題和錯誤。進而進一步論述了屬性和實體的判斷方法，屬性間聯系的判斷和元數的確定方法，以及聚集的使用。通過論述為學生在數據庫概念結構設計時提供可操作性強的方法和指導。

關鍵詞：概念結構設計；ER模型；聚集

引言

在數據庫原理課程教學中，長期以來存在一個難點，即數據庫設計。數據庫設計是指對于一個給定的應用環境，構造設計優化的數據庫邏輯模型和物理結構，并據此建立數據及其應用系統，使之能夠有效的存儲和管理數據，滿足各種用戶的應用需求，包括信息管理要求和數據操作要求。在學完數據庫設計理論和數據操作后，學生對怎樣根據一個具體的應用需求去設計一個優化的數據庫仍然比較模糊。糾其原因主要有兩個方面：一、在數據庫的概念設計過程中，將需求轉化為數據庫的概念模式是一個復雜困難的過程。概念模式提供了一個應用環境中數據庫用戶的數據需求，設計者需反復檢查以確保所有數據需求在此模式中都被滿足，并且不相互沖突、沒有冗余。這個過程是比較困難，它需要通過對需求進行綜合、歸納和抽象。學生的這種綜合、歸納和抽象能力較弱，不能很好的完成。二、概念模式定義了數據庫中的實體、實體的屬性、實體之間的聯系以及實體上的限制。通常通過實體—聯系圖（ER圖）來描述概念模式?，F有很多相關教材說法不一、編寫內容過于簡陋，甚至錯誤，沒有實操性，給學生在學習和思考上帶來一定的誤導。本文就概念模式設計時遇到的一些基本問題和解決方法進行探討。

1從一個錯誤的ER圖說起

ER圖是描述概念模式的有力工具，它采用三個基本概念：實體集、聯系集和屬性。這里給出某一本科學生針對某企業考勤管理設計的ER圖，如圖1。該ER圖中存在的問題在很多同學的設計中都存在。

1.1數據需求和行為需求分不清

數據庫設計分為數據設計和行為設計兩個部分，在圖1中，設計者沒有分清楚數據設計和行為設計中各自的活動內容。ER圖表達的是應用環境中的數據需求，而不用于行為需求的表達。數據庫概念模式的設計主要關注的是如何描述數據及其相互關系。在圖1中“更新”，“查詢”這些動詞表達的是數據庫用戶的行為，而非實體集之間的相互關系，用戶行為是在編寫應用程序時考慮的內容。員工和考勤這兩個實體集之間的關系應該是員工擁有考勤記錄，“擁有”是員工實體集和考勤實體集之間的關系。

1.2實體確定有誤

數據庫概念模式設計的目標是產生反映應用環境信息需求的ER圖，在圖1中出現了“管理員”實體集，如果設計者是從系統安全的角度考慮的話，管理員屬于數據庫的用戶，不是應用環境的信息，不應該出現在ER圖中；如果設計者是為了實現管理者實體集和考勤實體集之間的關系，因為管理者實體集是員工實體集中的部分實體，那么這時可以將管理者實體集和員工實體集合并，而不用單獨的把管理員實體集單獨的拿出來，這樣可以避免數據冗余。

1.3映射基數沒有標注

映射基數是指明一個實體通過一個聯系集能同時與多少個實體相關聯。它依賴于該聯系集所建模的對象在現實世界中的實際情況。如果聯系集上的映射基數沒有標注，那么概念模式在語義表達上信息不完整，對后續邏輯模型的設計將產生致命的影響。

1.4屬性歸屬的判斷

屬性是實體集中每個成員所擁有的描述性性質。聯系也可以有描述性屬性。當一個屬性是由參與的實體集聯合確定而不是由單獨的某個實體集確定時，該屬性就必須放到聯系集中。日期屬性是用于記錄考勤中某一類型發生時的時間，它是管理聯系的描述性屬性，表示管理者管理考勤信息的日期，由管理者和考勤同時決定。

1.5實體屬性設計不合理

按照數據庫設計理論中的“一事一地”的原則，ER模型中，實體不應該包含其它實體的屬性，實體之間的關系通過“聯系”來表達?？记趯嶓w中包含了員工實體的主碼屬性，這是一個常見的錯誤，因為員工實體和考勤實體之間可以通過“擁有”聯系表示兩者之間的關系，而不是將這種關系隱含在屬性中。與此相關的另一個常見的錯誤是將相關實體集的主碼屬性作為聯系集的屬性，因為在聯系集的表示中已經隱含了這些主碼屬性。雖然在后續創建關系模式時這些屬性會出現在聯系集創建出的表中，但是，它們不應該出現在概念模式的聯系集中。加班、出差、請假、遲到、曠到是考勤記錄的幾種類型，其中每種類型可以有多值，并且多種類型不可能同時存在，這樣就會使數據庫產生大量的空值，所以將其作為考勤的屬性是不合理的。需要將其進行抽象，找出其共有的特征，因為加班、出差、請假、遲到、曠到這些屬于考勤的類型，所以將加班、出差、請假、遲到、曠到這些抽象為考勤的“類型”屬性，而加班、出差、請假、遲到、曠到這些作為“類型”屬性的屬性值。又因為加班、出差、請假、遲到、曠到等都涉及到時間段和具體的原因，所以在考勤實體上增加一個“內容”屬性。

1.6一個可能的正確ER圖

在概念模型設計時遵從“一事一地”的原則，即概念單一化。在ER圖中創建的實體應該清晰、純粹，盡可能與其他實體在意義上實現分離。完善的概念模式受到系統功能需求的影響，設計最終的概念模式應能滿足系統的功能需求。經綜合、歸納、抽象，按一定的功能需求將圖1的ER圖改為圖2的ER圖，這樣就清晰的表達了現實中員工實體集、考勤實體集和員工考勤的聯系集。

2ER圖設計需要考慮的幾個問題

ER圖是一種語義模型，力圖表達數據的意義。在設計時除了注意上述的知識點外，還需要注意以下幾個方面的內容。

2.1用實體集還是屬性

實體是現實世界中可以區別于其他對象的事物，實體通過一組屬性來表示，屬性是實體集中每個成員所擁有的描述性性質。實體和屬性都通過名詞來描述。什么作為屬性，什么作為實體集，對這兩個問題并不能簡單的回答。名詞到底是實體還是屬性可以通過名詞之間的限定來判斷。如“職工”和“族別”都是名詞，如果說成“職工的族別”在需求描述中是成立的，并且這時不存在有任何的名詞被“族別”限定，那么就把“職工”作為實體，把“族別”作為“職工”的屬性。又如“職工”和“考勤”都是名詞，說成員工的考勤在需求描述中是成立的，但考勤中的請假，出差等值還有對應的具體內容，如請假的具體時間段、請假的原因等。這時考勤屬性值不具有原子性，所以把考勤提升為實體對待。其中的請假、出差、加班等作為考勤的種類屬性值，具體的時間段、原因等作為考勤的內容屬性值。對上述員工考勤ER圖中，如果將考勤處理成員工實體的屬性，暗示對每個員工正好有一個考勤信息與之相關聯。而將考勤作為一個實體，就允許每個員工可以有幾個考勤信息與之相關聯。這兩者的主要差別是，將考勤作為一個實體來建?？梢员４骊P于考勤的額外信息，如考勤的類型（請假、出差、加班等），考勤的具體內容，因此把考勤視為一個實體比把它視為一個屬性的方式更具通用性；而且當這種通用性很重要的時候，這種定義方式就更為合適了。

2.2二元聯系集與N元聯系集

聯系是指多個實體間的相互關聯，一般通過動詞來描述。哪些實體之間有聯系，看作為實體的名詞之間是否有動詞存在，并且這個動詞要體現在數據需求中。數據庫中的聯系通常都是二元的。如“職工”實體和“考勤”實體之間能說成“職工擁有考勤記錄”在數據需求描述中是存在的，并且是為管理員工考勤信息功能提供數據支持的。那么認為“職工”和“考勤”之間的聯系是存在的。又如“管理員”實體和“職工”實體，可以說成“管理員管理職工”，如果在數據需求描述中不存在這樣的描述，那么“管理”這個動詞就不作為聯系，即不考慮管理員和職工之間管理的聯系。對于非二元的聯系可以用多個二元聯系來表示，但如果這樣做會額外的增加設計的復雜程度，以及對總得存儲空間的需求。其實n元聯系集可以更清晰地表達n個實體集之間的聯系。如三元聯系：“供應商給超市供應商品”，這個“供應”是三個實體集之間的聯系，如果將其設計為供應商和超市之間的聯系、超市和商品之間的聯系、供應商和商品之間的聯系這三個二元聯系。假設供應商S1、S2給超市C1、C2供應商品P1、P2，從三個二元聯中可以記錄S1給超市C1、C2供貨，S1供應P1、P2商品，但是無法記錄S1給C1超市只供應商品P1不供應商品P2，S1給C2超市只供應商品P2不供應商品P1。而三元聯系就表達的非常清晰。

2.3聚集

ER模型的一個局限性在于它不能表達聯系間的聯系。但有時這在應用設計時是必要的。這里用圖書借閱這個實例來做以說明。圖書和讀者之間有借閱的聯系，現在考慮讀者借閱圖書被罰款的請況，當圖書歸還時有超期、損壞、丟失等事情發生時對讀者進行罰款。一種方法是將罰款作為借閱聯系的一個多值屬性，因為一些借閱是沒有罰款的，這樣會使得數據庫中罰款項存在大量的空值，從邏輯結構和執行開銷上都是不合理的。比如要查詢某一罰款項是哪個讀者借閱圖書的罰款就比較困難。另一種方法將罰款作為一個實體，為了表示罰款聯系，一種選擇是創建讀者、圖書、罰款之間的一個三元聯系，得到了圖3的ER圖（為了簡單省略了實體集的屬性）。但是，按照這種方法產生的ER圖存在冗余信息，因為在罰款聯系集中的每個讀者信息和圖書信息在借閱聯系中也有。對上述情況建模的最好辦法就是使用聚集。聚集是一種抽象，通過這種抽象，聯系被當作高層實體來看待。這樣，在這個例子中，將借閱聯系看成一個高層實體集，并且可以像對待任何別的實體集那樣對待這個高層實體集。這樣，就可以在罰款和借閱之間創建一個二元聯系來表示罰款是那一次借閱產生的。圖4所示為用聚集的概念表示上述情況的ER圖。

3總結

概念模式和具體應用環境的需求分不開，相同的應用環境下不同的需求可能對應不同的概念模式，所以概念模式一定是依據需求得到的，不能脫離需求、更改需求。概念模式設計是數據庫設計過程中最易出錯的部分，它涉及到人腦的抽象思維過程，需要大量的理論知識和實踐經驗。在設計時考慮的內容繁多復雜。對于數據庫概念模型的設計，很多的教材和參考資料都有設計步驟，粗看之下簡約明了，但可操作性甚小。學生掌握了這些流程后仍不能正確快速的設計出概念模式。筆者結合多年的教學經驗，在前人設計理論的基礎上進行了總結分析，通過一個典型的錯誤實例，分析了學生在設計概念模型時容易出現錯誤的地方，通過分析使學生清楚的理解數據庫概念模式設計時應注意的知識點。為學生設計概念模式提供了有力的理論依據和設計方法。

參考文獻：

[2]王珊，薩師煊.數據庫系統概論（第5版）[M].北京:高等教育出版社，2014:15-16.

[3]趙良輝.數據庫課程中ER模型設計的反例教學[J].教育技術，2012,8:8-10.

[4]徐廣定，潘錦平.實體聯系模型-用作數據的統一的觀點[J]計算機工程與應用，1983,12:22-37.

作者：牛榮 陳紀龍 杜義君 單位：塔里木大學信息工程學院