資料庫設計流程總結
一、專案中資料庫建庫套路
1、概念模型:就是從現實世界到資訊世界的第一層抽象,確定領域實體屬性關係等,使用E-R圖表示,E-R圖主要是由實體、屬性和聯絡三個要素構成的。
2、邏輯模型:是將概念模型轉化為具體的資料模型的過程,即按照概念結構設計階段建立的基本E-R圖,按選定的管理系統軟體支援的資料模型(層次、網狀、關係、面向物件),轉換成相應的邏輯模型。這種轉換要符合關係資料模型的原則。目前最流行就是關係模型(也就是對應的關係資料庫)
E-R圖向關係模型的轉換是要解決如何將實體和實體間的聯絡轉換為關係,並確定這些關係的屬性和碼。這種轉換一般按下面的原則進行:
(2)一個聯絡也轉換為一個關係,聯絡的屬性及聯絡所連線的實體的碼都轉換為關係的屬性,但是關係的碼會根據聯絡的型別變化,如果是:
1:1聯絡,兩端實體的碼都成為關係的候選碼。
1:n聯絡,n端實體的碼成為關係的碼。
m:n聯絡,兩端實體碼的組合成為關係的碼。
3、物理模型就是根據邏輯模型對應到具體的資料模型的機器實現。物理模型是對真實資料庫的描述。如關係資料庫中的一些物件為表、檢視、欄位、資料型別、長度、主鍵、外來鍵、索引、約束、是否可為空、預設值。
二、E-R圖跟UML類圖區別
一般概念設計都是使用E-R圖,這裡我為什麼把UML類圖也放進去了呢?
因為UML是面向物件的,有時候能夠表達E-R圖不能表達的內容,比如generalization,realization,aggregation,composition,association,dependency等關係,並且在powerdesigner中也能直接生成資料庫,比較方便。
當資料關係比較簡單的時候使用E-R圖與UML類圖都可以,基本沒什麼區別,但是一旦資料關係比較複雜的時候最好使用UML類圖設計,因為從資料庫到程式裡的資料模型畢竟還是有區別的(現實資料——資料庫中儲存(E-R圖)——程式中儲存(UML類圖)),直接通過UML類圖設計比較能夠清晰的掌握資料之間的關係,更好的將資料與功能聯絡起來,從而減少錯誤設計==
三、一對多關係總結
一對一關係和多對多關係大家都比較熟悉了,直接在一個表新增外來鍵或者多建一個表就行了,這裡詳細說一下一對多的關係,這種也比較常見。
舉例如下:
方案一(常規法):在學生表新增欄位——班級id,常規設計;
方案二(編號法):在學生表記錄id的時候在id前面新增教室id,如教室id有class001、class002,學生表中id寫為class001—001,class002—001……類似這樣,然年就不用在學生表中新增班級id了,發現很多單位外業習慣這樣記錄,然後設計資料庫的時候就直接使用了。
優缺點:方案一無法直接使用外業資料,必須經過整理新增教室id,但是新增資料的時候比較簡單規範;
方案二可以直接使用外業資料,但是新增資料的時候比較麻煩,新增實體資料主鍵要有規範要求;
四、總結
- 資料庫建庫
- E-R圖與UML類區別
- 一對多關係的建庫與優缺點