數據庫學習--關係模式

最近開始作數據庫的大實驗，其中有一條實驗要求以下：

經過網絡查找相關文獻並參考所給資料進行需求分析，畫出系統的 E-R 圖，給出實體或聯繫的屬性，標明聯繫的種類，並寫出 關係模式。

畫ER圖沒有什麼問題，可是關係模式是什麼就不知道了。因此，仍是有必要學習一下的。

關係模式的定義

經過google和課本上對關係模式的定義得出以下定義：

關係模式（Relation Schema）是對關係的描述,它能夠形式化地表示爲： R（U，D，dom，F）。

其中R爲關係名，U爲組成該關係的屬性名集合，D爲屬性組U中屬性所來自的域，dom爲屬性向域的映象集合，F爲屬性間數據的依賴關係集合。

一般簡記爲：R(U)或R(A1，A2，…,An)其中R爲關係名，U爲屬性名集合，A1，A2，…,An爲各屬性名。

有了定義，對關係模式有一個大概的認識（能夠說基本上仍是蒙的），那麼按照實驗的要求，咱們要如何從ER圖中的到一個關係模式呢？

ER圖轉關係模式

這裏我會以學生管理系統中常見的幾個實體關係爲例，設計簡單你的ER圖，並作轉換說明。

1對1轉換關係

首先咱們先從最簡單的作起。這裏咱們將教師和課程的關係看作是1:1的關係（班主任）,而後ER圖以下:

經過定義，咱們能夠初步的到一組關係模式：

教師（性別，職工號，手機號，年齡，姓名）
班級（班級名稱，班級號）
負責（職工號，班級號）

這就是一組關係模式，有人會說，負責這組關係模式好像多餘呀。是的，下面咱們就着手將其進行合併。

這裏能夠將教師和負責兩個關係合併到一塊兒，也能夠選擇將班級和負責合併到一塊兒。

1.合併教師和負責

教師（性別，職工號，手機號，年齡，姓名，班級號）
班級（班級名稱，班級號）

合併就是將關係負責的屬性添加到教師的屬性中去，而後合併重複的屬性。

2.合併班級和負責

教師（性別，職工號，手機號，年齡，姓名）
班級（班級名稱，班級號，職工號）

經過上面的合併，咱們發現，合併後的兩個關係才更像是咱們最終的數據表結構。

1對n轉換關係

班級和學生是1對n的關係，ER圖以下：

一樣的，咱們有能夠先獲得一組獨立地關係模式：

學生（學號，姓名，性別）
班級（班級名稱，班級號）
包含（學號，班級號，人數）

而後將聯繫的關係進行合併。在1對n的關係中，須要將聯繫的關係添加到n的一方的關係模式中。

學生（學號，姓名，性別，班級號）
班級（班級名稱，班級號）

m對n轉換關係

最後看一下多對多的關係是如何轉換的。首先仍是先給出ER圖：

學生和課程的關係是m:n的。而後獲得初步的關係模型：

學生（學號，姓名，性別）
課程（課程號，課程名）
選修（學號，課程號，成績）

按照上面的慣例，下面咱們應該合併關係模型了。可是在多對多的關係下，三種關係模式是不能進行合併的。而兩個實體聯繫的關係模式正式咱們常說的中間表的結構。

理解關係模式的做用

在上面經過ER圖獲得關係模式和合並關係模式的過程當中，咱們發現關係模式其實就是對應咱們的數據表結構。那麼關係模式有什麼用呢，以往咱們不經過關係模式同樣能夠獲得表結構。

實際上是沒錯的，可是經過範式的學習，發現咱們的關係模式更多的時候是獲得最終數據表的一個分析工具。就像咱們上面同樣，一開始會獲得一個初始的獨立的關係模式，而後對關係模式作合併，獲得一個更加合理的關係模式。

使用範式也是同樣的，咱們會從基本的關係模式出發，而後利用範式的規則，獲得最終更加合理的關係模式。這個過程若是隻是靠抽象的想象的話，若是實體數量少還好說的，可是隨着實體數愈來愈多，就會顯得不大現實，並且準確性也會降低。

總的來講，經過對關係模式的化簡合併，纔會獲得咱們最終的實際編程用的數據表結構，好比下面這樣：

總結

經過學習，本身理解了一下關係模式。發現本身原來建立數據表的方式有點隨意了。我只是作到了給出了一種數據表的解決辦法，可是還不能算是數據庫設計的範疇。看來本身仍是處在一個程序員的位置，想要成爲一個工程師，還有很長的路要走。

後面我還會繼續更新對範式的相關學習。

---

相關參考：https://blog.csdn.net/tang_hu...