好的關系設計的特點
1. 設計選擇：更大的模式
e.g.
instructor (ID, name, dept_name, salary)
department (dept_name, building, budget)
假設用更大的模式（instructor和department自然連接的結果）inst_dept (ID, name, salary, dept_name, building, budget)代替instructor和department，則：某些查詢可以用更少的連接來表達；
但相比原設計將會重復存儲building和budget，並且承擔產生不一致的風險；
無法直接表示關於一個department的信息，除非該department在學校中至少有一位instructor，或將不得不創建帶空值的元組。
2. 設計選擇：更小的模式
函數依賴（function dependency）：可提供信息以發現“模式可能存在信息重復的問題”的規則。設計者從而可以發現一個模式應該分解成兩個或多個模式。
e.g.
假設原有模式inst_dept；
通過對企業本身規則的了解，我們發現大學每個department（由dept_name唯一標識）必須只有一個building和一個budget，得到函數依賴dept_name→budget；
該規則定義：如果存在模式(dept_name, budget)，則dept_name可作為主碼（i.e. dept_name的每個特定值對應至多一個budget）；
因為dept_name不能是inst_dept的主碼，所以budget可能會重復；
設計者將模式inst_dept分解為模式instructor和模式department。
並非所有的模式分解都有益，應避免有損分解。
e.g.
employee (ID, name, street, city, salary)
假設分解為模式employee1 (ID, name)和employee2 (name, street, city, salary)。自然連接后雖然擁有較多元組，但實際上擁有較少信息（能夠指出某個steet, city和salary信息屬於一個name為Kim的人，但無法區分是拿一個Kim），造成有損分解。
原子域和第一范式
在關系模型中，如果一個域的元素被認為是不可分的單元，則該域是原子的（atomic）。
如果一個關系模式R的所有屬性的域都是原子的，則稱R屬於第一范式（First Normal Form, 1NF）。
使用函數依賴進行分解
1. 碼和函數依賴
合法實例（legal instance）：一個滿足所有現實世界約束的實例稱為關系的合法實例。在一個數據庫的合法實例中所有關系實例都是合法實例。
常用的現實世界約束可形式化地表示為碼或函數依賴。
超碼（superkey）：考慮關系模式r(R)，R為一個屬性集，K為R的子集。如果在關系r(R)的任意合法實例中，對於r的實例中的所有元組對t1和t2總滿足“若t1≠t2，則t1[K]≠t2[K]”（i.e. 在關系r(R)的任意合法實例中沒有兩條元組在R的子集K上可能具有相同的值），則屬性集K為r(R)的超碼。
函數依賴：考慮關系模式r(R)，屬性集α⊆R，屬性集β⊆R。
如果對於給定一個r(R)的實例中所有元組對t1和t2總滿足“若t1[α]=t2[α]，則t1[β]=t2[β]”，則這個實例滿足（satisfy）函數依賴α→β。
如果在r(R)的每個合法實例都滿足函數依賴α→β，則該函數依賴在模式r(R)上成立（hold）。
如果函數依賴K→R在r(R)上成立，則K是r(R)的一個超碼。
如果一個函數依賴在所有關系中都滿足，則稱為平凡的（trivial）。一般地，如果β⊆α，則形如α→β的函數依賴是平凡的。
給定關系r(R)上成立的函數依賴集F，有可能會推斷出某些其他的函數依賴也一定在該關系上成立。
e.g.
給定模式r(A, B, C)，如果函數依賴A→B和B→C在r上成立，可以退出函數依賴A→C也一定在r上成立。
閉包（closure）：使用符號F+表示集合F的閉包，表示能夠從給定集合F推導出的所有函數依賴的集合。F+包含F中所有的函數依賴。
2. Boyce-Codd范式
Boyce-Codd范式（Boyce-Codd Normal Form, BCNF）：可消除所有基於函數依賴能夠發現的冗余。
考慮具有函數依賴集F的關系模式R，對F+中所有形如α→β的函數依賴(α⊆R且β⊆R)，如果以下至少一項成立：
·α→β是平凡的函數依賴（i.e. β⊆α）；
·α是模式R的一個超碼。
則關系模式R屬於BCNF。
（判斷時，一般找出所有成立的非平凡的函數依賴，如果箭頭左側為模式的超碼，則屬於BCNF。）
另：可驗證，任何只包含兩個屬性的模式都屬於BCNF。
如果構成一個數據庫設計的關系模式集中的每個模式都屬於BCNF，則這個數據庫設計屬於BCNF。
判定和分解不屬於BCNF模式的一般規則
如果r(R)為不屬於BCNF的一個模式，則存在至少一個非平凡函數依賴α→β，其中α不是R的超碼。
在設計中用以下兩個模式取代R：
·( α ∪ β )
·( R - ( β – α ) )
e.g.
關系模式inst_dept(ID, name, salary, dept_name, building, budget)不屬於BCNF，因為函數依賴dept_name→building, budget在inst_dept上成立，但dept_name不是超碼；
( α ∪ β ) = (dept_name, building, budget);
( R - ( β – α ) ) = (ID, name, dept_name, salary);
inst_dept(ID, name, salary, dept_name, building, budget)分解為instructor(ID, name, dept_name, salary)和department(dept_name, building, budget)。
當分解不屬於BCNF的模式時，產生的模式中可能有一個或多個不屬於BCNF，需要進一步分解，最終結果為一個BCNF模式集合。
3. BCNF和保持依賴
如果函數依賴的檢驗僅需要考慮一個關系就可以完成，那么檢查通過該函數依賴表達的一致性約束的開銷就很低。所以有些情況下，到BCNF的分解會妨礙對某些函數依賴的高效檢查。
e.g.
設實體集instructor、student和depatment由三元聯系集dept_advisor關聯，從{instructor, student}對到department多對一。
約束“一個student可以對應多個instructor，但對應於一個給定的department最多只有一個instructor”。
即：a. 一個instructor只能對應一個department；b. 對於一個給定的department，一個student可以對應至多一個instructor。
聯系集dept_advisor的關系模式為dept_advisor (s_id, i_id, dept_name)。
則：
函數依賴i_ID→dept_name和s_ID, dept_name→i_ID在dept_advisor上成立；
可判斷出dept_advisor不屬於BCNF，根據BCNF分解規則得到(s_ID, i_ID)和(i_ID, dept_name)；
但在BCNF設計中沒有一個模式包含函數依賴s_ID, dept_name→i_ID中出現的所有屬性，使得該函數依賴的強制實施在計算上很困難，因此稱此BCNF設計不是保持依賴的（dependency preserving）。
當不存在保持依賴的BCNF設計時，必須在BCNF和3NF之間權衡。
4. 第三范式
第三范式（third normal form, 3NF）:如果經常需要保持依賴，可考慮比BCNF弱的第三范式。
考慮具有函數依賴集F的關系模式R，對於F+中所有形如α→β的函數依賴(α⊆R且β⊆R)，如果以下至少一項成立：
·α→β是平凡的函數依賴（i.e. β⊆α）；
·α是模式R的一個超碼。
·β - α中的每個屬性A都包含於R的一個候選碼中。(候選碼：最小的超碼)(並不要求單個候選碼必須包含β- α中的所有屬性，β- α中的每個屬性都可能包含於不同的候選碼中)
則關系模式R屬於3NF。
BCNF是比3NF更嚴格的范式，任何滿足BCNF的模式也滿足3NF。
e.g.
函數依賴i_ID→dept_name和s_ID, dept_name→i_ID在聯系集dept_advisor上成立；
判斷后可知函數依賴i_ID→dept_name導致dept_advisor模式不屬於BCNF；
β - α = dept_name – i_ID = dept_name；
因為函數依賴s_ID, dept_name→i_ID在dept_advisor上成立，所以dept_name包含於一個候選碼中；
dept_advisor屬於3NF。
屬於3NF的關系也許會含有冗余，但是總存在保持依賴的3NF分解。
5. 更高的范式
某些情況下，使用函數依賴分解模式可能不足以避免不必要的信息重復，因此定義了另外的依賴和范式。
函數依賴理論
1. 函數依賴集的閉包
邏輯蘊含（logically imply）：給定關系模式r(R)，F為r上的函數依賴集，f為R上的函數依賴。如果r(R)的每一個滿足F的實例也滿足f，則稱f被F邏輯蘊含。
可證明，一個關系只要滿足給定的函數依賴集F，這個關系也一定滿足被F邏輯蘊含的函數依賴f。
令F為一個函數依賴集，F的閉包是被F邏輯蘊含的所有函數依賴的集合，稱為F+。給定F，可油函數依賴的形式化定義直接計算出F+。（該運算需要論證，過程比較復雜。）
公理（axiom）：a.k.a. 推理規則，提供一種用於推理函數依賴的更為簡單的技術。
Armstrong公理（Armstrong’s axiom）：一組用於尋找邏輯蘊含的函數依賴的規則。通過反復應用這三條規則，可找出給定F的全部F+。
·自反律（reflexivity rule）：給定屬性集α和β，若β⊆α，則α→β成立；
·增補律（augmentation rule）：給定屬性集α、β和γ，若α→β成立，則γα→γβ成立。(γα表示γ∪α)
·傳遞律（transitivity rule）：給定屬性集α、β和γ，若α→β成立且β→γ成立，則α→γ成立。
Armstrong公理是正確有效的（sound）且完備的（complete）。
為進一步簡化計算，可應用另外一些（可用Armstrong公理證明為正確有效的）規則。
·合並律（union rule）：給定屬性集α、β和γ，若α→β成立且α→γ成立，則α→βγ成立。
·分解律（decomposition rule）：給定屬性集α、β和γ，若α→βγ成立，則α→β成立且α→γ成立。
·偽傳遞律（pseudotransitivity rule）：給定屬性集α、β、γ和δ，若α→β成立且γβ→δ成立，則αγ→δ成立。
使用Armstrong公理計算F+過程的形式化示范：（該過程可以保證終止）
2. 屬性集的閉包
給定屬性集α和屬性B，若α→B，則稱B被α函數確定（functionally determine）。
要判斷屬性集α是否為超碼，需要計算函數依賴集F下被α函數確定的所有屬性的集合（即α的閉包α+）。可采用兩種算法：
a. 計算F+，找出所有左半部為α的函數依賴，並合並這些函數依賴的右半部；（開銷很大）
b. 計算屬性閉包α+的高效算法，輸入F和α，輸出result。（該算法可找出a+的全部屬性）
屬性閉包算法的多種用途：
·判斷超碼：若檢查發現α+包含R中所有屬性，則α為超碼；
·判斷函數依賴成立：若β⊆α+，則函數依賴α→β成立；
·另一種計算F+的方法：對任意γ⊆R，計算出閉包γ+。對任意S⊆γ+，輸出函數依賴γ→S。
3. 正則覆蓋
數據庫系統必須保證更新操作不破壞關系模式上的任何函數依賴，否則必須回滾該更新操作。可通過測試與給定函數依賴集F具有相同閉包的簡化集來減小檢測沖突的開銷。
如果去除函數依賴中的一個屬性不改變該函數依賴集的閉包，則稱該屬性為無關的（extraneous）。
無關屬性（extraneous attribute）：
考慮函數依賴集F和F中的函數依賴α→β，
·如果A∈α且F邏輯蘊含(F – {α→β})∪{(α - A)→β}，則屬性A在α中是無關的；
·如果A∈β且函數依賴集(F – {α→β})∪{α→(β - A)}邏輯蘊含F，則屬性A在β中是無關的。
使用無關屬性定義時應注意蘊含的方向，因為(F – {α→β})∪{(α - A)→β}總是邏輯蘊含F，同時F也總是蘊含(F – {α→β})∪{α→(β - A)}。
如何有效檢驗一個屬性是否無關：
設在關系模式R上成立的給定函數依賴集F，考慮依賴α→β中的一個屬性A。
·如果A∈β：考慮集合F‘ = (F – {α→β})∪{α→(β - A)}，計算F’下的α+（α的閉包）。如果α+包含A（即α→A能由F‘推出），則A在β中是無關的；
·如果A∈α，令γ = α - {A}，計算F下的γ+（γ的閉包），如果γ+包含β中的所有屬性（即γ→β能由F推出），則A在α中是無關的。
正則覆蓋（canonical）：F的正則覆蓋Fc是一個依賴集，使F邏輯蘊含Fc中的所有依賴，並且Fc蘊含F中的所有依賴。Fc必須具有如下屬性：
·Fc中任何函數依賴都不含無關屬性；
·Fc中函數依賴的左半部都是唯一的。即：Fc中中不存在兩個依賴α1→β1和α2→β2滿足α1=α2。
可證明：F的正則覆蓋Fc是與F具有相同閉包的最小的簡化集，驗證是否滿足Fc等價於驗證是否滿足F。
正則覆蓋未必是唯一的。
4. 無損分解
無損分解（lossless decomposition）：設關系模式r(R)上的函數依賴集F，令R1和R2為R的分解。如果用兩個關系模式r1(R1)和r2(R2)替代r(R)時沒有信息損失（即：將r投影至R1和R2上，計算投影結果的自然連接仍得到一樣的r），則稱該分解為無損分解，a.k.a. 無損連接分解（lossless-join decomposition）。
所有的有效分解都必須是無損的。
有損分解（lossy decomposition）：不是無損分解的分解稱為有損分解，a.k.a. 有損連接分解（lossy-join decomposition）。
可用函數依賴來判斷分解是否無損。設關系模式r(R)上的函數依賴集F，令R1和R2為R的分解。如果以下函數依賴中至少有一個屬於F+（即：R1∩R2是R1或R2的超碼）：
·R1∩R2→R1
·R1∩R2→R2
則該分解為無損分解。
5. 保持依賴
限定（restriction）： 設F為關系模式R上的一個函數依賴集，R1, R2, …, Rn為R的一個分解，F在Ri上的限定Fi是F+中所有只包含Ri中屬性的函數依賴的集合。因為一個限定中的所有函數依賴只涉及一個關系模式的屬性，所以這種函數依賴的檢驗只需要檢查一個關系。
保持依賴的分解（dependency-preserving decomposition）：令F‘ = F1∪F2∪…∪Fn，F’為R上的一個函數依賴集，通常F‘≠F，但有可能F‘+=F+。
如果F’滿足F‘+=F+，則F中的所有依賴都被F’邏輯蘊含，證明F‘中的函數依賴滿足等價於證明F中的函數依賴滿足。
滿足F‘+=F+的分解稱為保持依賴的分解。
如果分解是保持依賴的，則給定一個數據庫更新，所有的函數依賴都可以由單獨的關系進行驗證，無須計算分解后的關系的連接。
判定保持依賴的算法（需計算F+，開銷很大）
輸入：分解的關系模式集D={R1, R2, …, Rn}，函數依賴集F。
替代方法1：簡單的驗證保持依賴的方法
如果F中的每個函數依賴都可以在分解得到的某一個關系上驗證，那么這個分解就是保持依賴的；
該方法只能用作一個易於檢查的充分條件，如果驗證失敗也不能判定該分解不是保持依賴的，需進而采用一般化的驗證方法。
替代方法2：避免計算F+的驗證保持依賴的方法
對F中的每一個α→β執行：
(這里的屬性閉包是函數依賴集F下的)如果result包含β中的所有屬性，則函數依賴α→β保持。當且僅當F中所有依賴都保持時這個分解是保持依賴的分解。
分解算法
1. BCNF分解
簡化的BCNF判定方法
對關系模式R的給定依賴集F中所有函數依賴進行以下檢驗（不用檢查F+中所有的函數依賴）：
·如果α→β是平凡的函數依賴（i.e. β⊆α），則該函數依賴不違反BCNF；
·對非平凡的函數依賴α→β，計算α+，如果α+包含R中所有屬性（i.e. α模式R的一個超碼），則該函數不違反BCNF。
如果F中沒有函數依賴違反BCNF，則關系模式R屬於BCNF。
可證明：如果F中沒有函數依賴違反BCNF，則F+中也不會函數依賴違反BCNF。
當一個關系分解后，則“僅需檢查F中函數依賴，不必檢查F+中所有函數依賴”不再適用。可能會有一個屬於F+但不屬於F的依賴證明分解后的關系不屬於BCNF。
對於關系模式R分解后的關系Ri是否屬於屬於BCNF，應用以下判定：
·對於Ri中屬性的每個子集α，確保α+要么不包含Ri - α的任何屬性，要么包含Ri的所有屬性。
如果Ri上有某個屬性集α違反該條件，可證明F+中有函數依賴α→(α+ - α)∩Ri 說明Ri違反BCNF。
BCNF分解算法
如果輸入關系模式R不屬於BCNF，該算法可將R保持依賴且無損分解成一組BCNF模式。
有些關系不存在保持依賴的BCNF分解。
2. 3NF分解
3NF分解算法
該算法可將輸入關系模式R保持依賴且無損分解為一組3NF模式。
生成的模式集可能會包含冗余的模式。如果一個模式Rk包含另一個模式Rj所有的屬性，算法會刪除Rj，分解仍然是無損的。
一種設計方法：
首先使用3NF算法，然后對3NF設計中任何一個不屬於BCNF的模式用BCNF算法分解。如果結果不是保持依賴的，則還原到3NF設計。
3. 3NF算法的正確性
上述3NF分解算法又稱3NF合成算法（3NF synthesis algorithm）。
該算法通過保證至少有一個模式包含被分解模式的候選碼，確保無損分解。
可證明：如果一個關系Ri在由該算法產生的分解中得到，Ri一定屬於3NF。
該算法結果不是唯一確定的，因為：
·一個函數依賴集可能有不止一個正則覆蓋，某些情況下該算法的結果依賴於Fc中依賴的順序；
·該算法有可能分解一個已經屬於3NF的關系，但仍然保證分解是屬於3NF的。
4. BCNF和3NF的比較
3NF的優點：總能在滿足無損並保持依賴的前提下得到3NF設計；
3NF的缺點：可能不得不用空值表示數據項間的某些（可能有意義的）聯系，並且存在信息重復問題。
SQL中指定函數依賴的途徑較少：
可用斷言保證函數依賴（但目前沒有數據庫系統支持強制實施函數依賴所需的復雜斷言，且檢查開銷大）；
一些特殊的函數依賴可用主碼或唯一約束聲明超碼指定（使用標准SQL只能高效檢查左半部是碼的函數依賴）。
如果分解不能保持依賴，對函數依賴的檢查可能會用到連接。可通過使用物化視圖的方法降低開銷（如果數據庫系統支持物化視圖上的主碼約束）：
給定一個非保持依賴的BCNF分解，對於正則覆蓋Fc中每一個在分解中未保持的依賴α→β，定義一個物化視圖對分解中所有關系計算連接，並將結果投影到αβ上。利用約束unique(α)或primary key(α)在物化視圖上檢查函數依賴。
優點：因為維護物化視圖是數據庫的工作，應用程序員不需要編碼保持冗余數據在更新上的一致性；
缺點：物化視圖會帶來額外開銷；目前絕大多數數據庫系統不支持物化視圖上的約束。
綜上，因為在SQL中檢查非主碼約束的函數依賴很困難，在不能得到保持依賴的BCNF分解的情況下，通常傾向於選擇BCNF。
對應用函數依賴進行數據庫設計的目標：1. BCNF 2. 無損 3. 保持依賴
使用多值依賴的分解
1. 多值依賴
函數依賴規定某些元組不能出現在關系中。如果A→B成立，則不能有兩個元組在A上值相同而在B上值不同。因此又稱相等產生依賴（equality-generating dependency）。
多值依賴並不排除某些元組的存在，而是要求某種形式的其他元組存在於關系中，因此又稱元組產生依賴（tuple-generating dependency）。
多值依賴有助於理解並消除某些形式（函數依賴無法理解的）的信息重復。
多值依賴（multivalued dependency）：給定關系模式r(R)，α⊆R且β⊆R，如果在關系r(R)的任意合法實例中，對於r中任意一對滿足t1[α]= t2[α]的元組對t1和t1，r中都存在元組t3和t4使得
則多值依賴α→→β在R上成立。
（多值依賴α→→β表明α和β之間的聯系獨立於α和R-β之間的聯系。）
如果模式R上的所有關系都滿足多值依賴α→→β，則α→→β是模式R上平凡的多值依賴。
如果β⊆α或β∪α=R，則多值依賴α→→β是平凡的。
多值依賴的兩種使用方式
1）檢驗關系以確定它們在給定的函數依賴集和多值依賴集下是否合法；
2）在合法關系及上指定約束。
如果關系r不滿足多值依賴，可通過向r中增加元組構造一個確實滿足多值依賴的關系r’。
e.g.
向r2中加入元組(Physics, 22222, Main, Manchester)和(Math, 22222, North, Rye)可使該關系合法化。
用D表示函數依賴和多值依賴的集合， D的閉包D+表示由D邏輯蘊含的所有函數依賴和多值依賴的集合。
可用函數依賴和多值依賴的規范定義根據D計算D+。（適用於處理非常簡單的多值依賴）；
可用推理規則系統推導依賴集（適用於復雜的依賴）。對於α、β⊆R，有以下規則：
·若α→β，則α→→β；（每個函數依賴也是一個多值依賴）
·若α→→β，則α→→R-α-β。
2. 第四范式
第四范式（Fourth Normal Form, 4NF）：比BCNF約束更嚴格，每個4NF模式一定也屬於BCNF，但有些BCNF模式不屬於4NF。
考慮函數依賴集和多值依賴集為D的關系模式r(R)，α⊆R且β⊆R，對D+中所有形如α→β的多值依賴，如果以下至少有一項成立：
·α→→β是一個平凡的多值依賴；
·α是R的一個超碼。
則r(R)屬於第四范式。
如果構成一個數據庫設計的關系模式集中的每個模式都屬於4NF，則該數據庫設計屬於4NF。
要檢驗分解中的每一個關系模式ri是否屬於4NF，需要找到每一個ri上成立的多值依賴。
限定（restriction）： 設D為關系模式R上的一個函數依賴和多值依賴的集合，R1, R2, …, Rn為R的一個分解，D在Ri上的限定Di包含：
·D+中所有只包含Ri中屬性的函數依賴；
·所有形如α→→β∩Ri的多值依賴，其中α⊆Ri且α→→β屬於D+。
3. 4NF分解
4NF分解算法（類似BCNF分解算法，但使用多值依賴以及D+在Ri上的限定）
該算法只產生無損分解。
更多的范式
連接依賴（join dependency）：概化了多值依賴的一類約束，並引出了投影-連接范式（Project-Join Normal Form, PJNF, a.k.a. 第五范式 fifth normal form）。
一類更一般化的約束可引出域-碼范式（Domain-key Normal Form, DKNF）。
PJNF和DKNF等其他范式消除了更多細微形式的冗余，但難以操作且很少使用。
第二范式（Second Normal Form, 2NF）只具有歷史意義。
數據庫的設計過程
1. E-R模型和規范化
如果小心定義E-R圖並正確識別所有實體，則由E-R圖生成的關系模式應該不需要太多進一步的規范化；
一個實體的屬性之間有可能存在函數依賴，大多數是由不好的E-R圖設計引起的；
包含兩個實體集以上的連計息有可能會使產生的模式不屬於所期望的范式；
函數依賴有助於檢測到不好的E-R設計，如果生成的關系模式不屬於想要的范式，可在E-R圖中解決（規范化可作為數據建模的一部分規范地進行）。
創建E-R設計的過程傾向於產生4NF設計。如果一個多值依賴成立且不是被相應的函數依賴所隱含的，則通常由a. 一個多對多的聯系集 或 b. 實體集的一個多值屬性 引起。
2. 屬性和聯系的命名
唯一角色假設（unique-role assumption）：數據庫設計的一個期望的特性，指每個屬性名在數據庫中只有唯一的含義。（因此不能使用同一個屬性在不同的模式中表示不同的東西）
如果不同關系中的屬性含義不兼容，適合采用不同的名字；（唯一角色假設）
如果不同關系中的屬性有相同的含義，適合采用相同的名字。
習慣上在模式的屬性名順序中將主碼屬性列在前面；
實體集命名習慣采用單數形式（單數復數形式皆可，所有實體集應保持一致）。
3. 為了性能去規范化
去規范化（denormalization）：把一個規范化的模式編程非規范化的過程，用於調整系統性能以支持響應時間苛刻的操作。
e.g.
可保存一個包含course和prereq所有屬性的關系以避免計算連接，提高性能。（代價是用於保持冗余數據一致性的額外工作）；
更好的方法：可使用規范化的模式將course和prereq的連接作為物化視圖額外存儲。
4. 其他設計問題
時態數據建模
時態數據（temporal data）：具有關聯的時間段的數據，在時間段之間數據有效（valid）。
快照（snapshot）：數據的快照表示一個特定事件點上該數據的值。
時態函數依賴（temporal functional dependency）：如果對於關系模式r(R)的所有合法實例，r的所有快照都滿足函數依賴X→Y，則時態函數依賴
在r(R)上成立。
也可退回到更簡單的方法來設計時態數據庫：
先設計整個數據庫，忽略時態改變（僅考慮一張快照）；
研究多個關系，決定哪些關系需要跟蹤時態變化；
將起始時間和終止時間作為屬性，為每隔這樣的關系添加有效時間；
e.g.
關系模式course(course_id, title, dept_name, start, end)
該關系的一個實例最初含有總共2條記錄：
(CS-101, “Introduction to Programming”, 1985-01-01, 2000-12-31)
(CS-101, “Introduction to C”, 2001-01-01, 9999-12-31) //用相當遠的終止日期表示當前仍然有效
插入一條新的”Introduction to Java”記錄的操作：
將第二條記錄的終止時間改為正確有效的終止時間，插入新元組。
如果另一個關系有一個參照時態關系的外碼，需決定參照是針對當前版本的數據還是一個特定時間點的數據。