oracle調優 淺析關聯設計

標籤：style   ar   使用   sp   資料   div   2014   on   art   

淺析關聯設計

 

【範式】

      比較理想的情況下，資料庫中的不論什麼一個表都會相應到現實生活中的一個對象，如球員是一個對象，球隊是一個對象，賽程是一個對象，比賽結果又是一個對象等等，則就是範式。

【關聯設計】

       對於關聯設計能夠理解成表和表之間要有關聯關係，在對錶查詢時常常使用關聯查詢。

       補充：關聯式資料庫的來源：對一個事務操作要從多個表中讀。

       如2014巴西世界盃這個資料表空間中要有球員表、賽程表、比賽結果表，比賽結果表要關聯比賽的隊伍名字、球員的名字最後關聯一個比賽的結果，這就是一個簡單的關聯關係。至於為何要設計成範式，也非常好理解，這是為了不冗餘儲存資料，同一場比賽的結果就不用反覆的儲存了，如巴西對德國0:0和德國隊巴西也為0:0（由於是相同的兩支隊伍，結果必定是一樣的），這樣就能夠僅僅存在一行資料了，結果也就是保持了資料的獨立性。

【不良好的範式、關聯設計舉例】

       假設不良好的範式、關聯設計會引發關聯的成本的問題，舉個範例，假設兩張表的成本都非常大，來做等值串連和不等值串連時將會有非常大的成本問題。如從世界盃的進球球員中去關聯到該名球員在俱樂部中一個賽季的表現情況時，如進球數、犯規數、搶斷數等等一些列資料時，而這個資料是存在於一個較大的表中的，對於這兩張表的關聯成本將會非常大。由於世界盃中進球球員的一行記錄有可能相應賽季表中的非常多行資料，而每個球員都是這樣，第一個表中的一行資料相應於第二個表中的非常多行資料，這樣的交叉的連結過程中，成本是相當高的。這也就引出了，目標比較流行的技術趨勢，反範式。

【反範式】

       反範式，打破舊有的良好設計，而有益使用存在冗餘的資料。

舉個範例，例如以

表1：

FIFA球員ID	球員名	國籍	2014世界盃進球	......
10982	小羅	葡萄牙	6	......
23781	比利亞	西班牙	5	......
12312	穆勒	德國	4	......
......萬條

表2

FIFA球員ID	10982	23781	12312	......
地區	歐洲	歐洲	歐洲	......
俱樂部	皇家馬德裡	馬德裡競技	拜仁慕尼黑	......
2014賽季進球	32	28	6	......
......萬條

            如上，表1是世界盃球員統計資料，表2為球員在俱樂部中的表現情況。為了避免球員重名情況，表2使用了ID號作為標識。如今想要查看世界盃表現優異有進球的小羅在俱樂部的表現情況，即要關聯世界盃有進球的球員在俱樂部中的表現情況時，要通過第一張表進行關聯，先要知道小羅的ID號，再查到相應的俱樂部表現情況。表1中的一行資料要相應到表2中的1列資料，表2中的1列資料也要相應表1中的1行資料，在以萬條計的兩張大表中，這個關聯成本是相當高的。儘管兩張表符合了良好的範式、關聯性，防止了冗餘、防止了衝突，但在效能上就很差了。相應的改善做法就是不寫ID號，而是直接填寫球員的名字，假設有重名在後台資料庫做一個標識。這樣想查詢某球員俱樂部表現情況時，就直接到表2中去查詢相應的資料資訊就可以。從設計上出發，沒有一個好的範式、沒有一個好的關聯設計。但從效能上分析，比一個良好的範式、關聯設計體現了更好的效能。

oracle調優 淺析關聯設計