Database in Depth筆記-2(Predicate)

關係與關係變數

關係變數(用R表示)跟程式語言的變數一樣，是可以放置某種型別(這裡是關係)的容器。而關係(用r表示)，則是指在某個時點，實際存在的n個Tuples(n>=0)。以C.J. Date的觀點，所謂Relation Model的Insert、Delete、Update動作，都是透過關係變數R，取出所要的關係後，對其Tuple進行一些處理後，再重新指向回關係變數。

Predicate

Predicate的觀念是由集合論而來的。在指涉某個集合時，常常無法透過列出集合中包含的所有元素的方式，來表示該集合。因此改以使用用該集合中每個元素的共同因子作為參數來描述該集合。對應至Relational Model，組成關係變數Heading中的屬性集合，即可組成描述該關係變數的Predicate。例如某個關係變數 R的Heading為 {Customer_ID,Customer_Name,Customer_Address}，其意含可以解釋為這樣的Predicate:  編號為Customer_ID的客戶，其名稱為 Customer_Name，且其住址為Customer_Address。

將Assign到該關係變數的關係r中的每一Tuple的值，分別套上這個Predicate的結果後，就形成一個Proposition(命題)。此命題應該都為True，因為若結果為False，則此關係根本不存在，也就不會被Assign到關係變數中。所以C.J. Date提到一個重點：在EF Codd原始的Relational Model中，資料庫不是資料的集合，而是Proposition(命題)，則事實的集合。系統執行關聯式運算的過程，就是由既有事實推論出新的事實

Database in Depth筆記-1 (Relation及Tuple定義)

這本書買了好幾年了，因為讀起來有點艱澀，一直沒有把它翻完(作者太龜毛了，一直在辨證Relational Model不能有NULL、SQL不是Relational Model之類對我來說沒有意義的論點)，不過看在它是和EF Codd一起work on Relational Model的大師，還是應該把它翻過一遍，趁這次再翻它的機會，做一些筆記。

Tuple定義：

相對應於Table的Row。在原始的Relational Model中，是用Tuple這個概念來代表一組資料，而不是大家所熟知的Row。以下是它的定義：

假設T1,T2…,Tn(n>=0)是型別的名稱，而A1,A2…,An是代表n個不同的屬性名稱，若將每個屬性名稱Ai對應到相對的Ti型別，則如此組合成的每一個屬性名稱:型別 (Ai:Ti)就是一個屬性。若將每個屬性都賦予符合型別Ti的值Vi，則形成的屬性:值，就稱為一個Component。如此一來，n個屬性:值組成的n個Component的集合就稱為一個Tuple。而這n個Component中的屬性集合就形成讓Tuple的Heading，以集合{H}表示

Relation定義：

相當於RMDBS的Table。初學Relational Model的人可能會把關聯式資料庫的關聯想成是不同Table之間可以建立Join的關係。然而，在原始的Relational Model，Relation是較為抽象的定義。它是基於集合論而來的概念。假設Order Table有CustomerID及ProductID這兩個屬性，把CustomerID和ProductID這兩個屬性放到同一個實體來看，就是Relation的意義了。以下是CJ Date在此書中所下的定義

假設{H}是Tuple的Heading，而且t1,t2…,tm (m>=0)是帶Heading {H}的不同Tuple，則該Heading {H}與該不同Tuple的集合(t1,t2…,tm)的組合叫做Relation。此Relation就是帶有屬性A1,A2…An的關係，換句話說，該Relation的Body就是Tuple(t1,t2…,tm)的集合

1NF(一階正規化)

有了Relation及Tuple的觀念後，一階正規化就可以簡單用一句話來描述：每個Tuple的每一個屬性只能帶有單一值

資料庫的Isolation需求

資料來源

Isolation是資料庫系統的ACID其中的一個屬性。它是用來定義一個操作針對資料所做的修改 如何/何時 被另一個操作所看到。資料庫的Isolation層級從最高到最低排序如下。應用程式開發人員必需依照實際的需求，選用適當的Isolation層級。Isolation層級愈高，愈可能發生deadlock現象；相反地，層級愈低，資料愈可能出現不可預期的不一致現象

Serializable：

Serializable是最高的Isolation層級。在此層級之下，交易是依序執行的。也就是說，同一時間內，只能有一個交易針對同一組資料進行操作。雖然資料庫系統仍可允許多個交易同時進行，但是一定要維持交易是依序執行的一個假象。

若以Lock的方式來實作Serializable，當資料庫遇到查詢中有WHERE子句時，就會Acquire一個Range Lock來鎖住WHERE子句條件中，所有牽涉到的資料；另一種非Lock的實作機制，因其不Acquire Lock，所以必需偵測當前的交易是否違反了Serializable的假象，若有違反，必需Rollback交易。Optimistic lock即為一種非Lock的實作機制

Repeatable Read：

在此層級下，所有被SELECT語句碰觸到的資料都不能被其它交易所更動。也就是說，資料庫會保證在交易的範圍中，重覆讀取同一筆資料，得到的值都是一樣的。與Serializable的差別在於，Repeatable Read不會Acquire range lock，也就是說，它是讀到一筆資料後，才將該筆資料鎖住，而不會鎖住符合WHERE條件的所有資料。因為不Acquire rangle lock，可能會有phantom reads的情形發生。亦即，在同一個交易中，做兩次的SELECT，可能得到不同數目的Records。

Read Committed：

在此層級下，已被一個交易讀取的資料，可以被另一個交易修改，因此無法得到Repeated Read的結果。Read的Lock在資料讀到之後，就馬上放掉；而Write的Lock還是會持續到整個交易結束後才放掉

Read Uncommitted：

此層級是最鬆的層級，在此層級下，一個交易可以讀到被改動，而尚未Commit的資料。