【機房收費系統】資料庫設計

標籤：

概述本文介紹基於機房收費系統  基本遵循三範式的資料庫設計。

僅滿足最準系統需求。不包括額外的資訊儲存。

 

回想

關係模式設計的好壞直接影響到資料冗餘度和資料一致性等問題。

由此我們有了一個評價指標。即範式。

第一範式：關係模式R的每一個關係r的屬性值都是不可分的原子值

第二範式：關係模式R是1NF且每一個非主屬性全然依賴於候選索引鍵

第三範式：關係模式R是1NF且每一個非主屬性都不傳遞依賴於R的候選索引鍵

 

ER圖

 

 

ER圖轉換成關係模式集的演算法

 

步驟一（實體類型的轉換）

將每一個實體類型轉換成一個關係模式。實體的屬性即為關聯式模式的屬性，實體標識符即為關係模式的鍵。

由此得到學生表卡表工作人員表基本資料表和機器表。因為機器僅僅有一個屬性，可與其它合并。

步驟二（聯絡類型的轉換）依據不同情況做不同的處理。

步驟2.1 二元聯絡類型的轉換

1）若實體間聯絡是1：1可在兩個實體類型轉換成一個關係模式，實體的屬性即為關係模式的屬性，實體標識符即為關係模式的鍵。

2）若實體聯絡是1：N則在N端實體類型轉換成關係模式中增加1端實體類型的鍵作為外鍵和聯絡類型的屬性。

3）若實體間聯絡是M:N，則將聯絡類型也轉換成關聯式模式。其屬性為兩端實體類型的鍵（作為外鍵）加上聯絡類型的屬性。而鍵為兩段實體間的組合。

即得

 

步驟2.2一元聯絡類型的轉換

和二元聯絡類型的轉換類似。

 步驟2.3（三元聯絡類型的轉換）

1）若實體間聯絡是1：1：1 能夠再三個實體類型轉換成三個關係模式中隨意一二關係模式的屬性中增加另兩個關係模式的鍵（作為外鍵）和聯絡類型的屬性。

2）若實體間聯絡是1:1：N 則在N端實體類型轉換成關係模式中增加兩個1端實體類型的鍵（作為外鍵）和聯絡類型的屬性。

3）若實體間聯絡是M:N:P，則將聯絡類型也轉換成關係模式，其屬性為是那段實體類型的鍵（作為外鍵）加上聯絡類型的屬性，二鍵為三端實體鍵的組合。

由此得到

 

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxMDE3NjAxNA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

 

以上為個人理解，在實際實現中還會有想的不到的地方稍有改動。有不妥之處歡迎指導。

【機房收費系統】資料庫設計