數據庫筆記資料

1、（第一課）數據庫的存放格式是堆文件從層次型數據庫轉變?yōu)殛P系型數據庫，基于資源管理器的樹狀結構的組織沒辦法科學化。基于層次結構的組織方式不能抽象成科學化的方法，而關系型可以使得數據庫的組織簡明而合理。將樹狀結構放入關系型數據庫中在大數據量的情況下如何提高性能：表設計、模式設計，SQL優(yōu)化等方法。環(huán)境為基于硬盤上的關系數據庫（SIP是將數據庫放入內存中，提高數據庫數據分析的效率。在之后十年中，大數據量的分析都會放入memory中進行）數據庫之間的比較，比如Oracle/MySQL/SQL Server/DB2，數據庫的連接、組織形式是完全不同的。要提高數據庫的性能最本質的是在某一個數據庫上提高性能

2、在基于web的應用中大量地使用非關系型數據庫，放寬對一致性的要求而提高吞吐量。因為系統(tǒng)有并發(fā)的限制，所以單一請求的性能作為系統(tǒng)的性能指標是不可行的，因此引入吞吐量的概念。計算機系統(tǒng)中，最大的瓶頸是總線級的傳輸效率，但是在軟件中瓶頸可能會在任何位置。一致性的要求會產生大量的回滾操作，從而降低吞吐量。NoSQL認為臟寫、不一致性都是可以接受的，只要在一段時間內保證數據庫的一致性即可（關系型數據庫要求實時保證數據庫的一致性）。Google、新浪微博等都是使用NoSQL實現(xiàn)的推薦教材見PDF關系代數：同樣的代數表達式，所有的操作都是關系和操作符之間的操作，改變代數的形式而不改變最終的結果。每一個表達式

3、都是一個SQL想要得到的結果集的表達式，where是選擇操作，select是投影操作。表達式可以轉換成多種具有相同結果的不同表達式，每一個表達式都被稱為完成某一個結果的某一條路徑，從中選出一條最省的路徑（運算的時間、中間結果的存儲空間），由查詢優(yōu)化器根據關系代數來尋找最快路徑計算機對于表達式的變換是有約束的，所以可以找到一個有限的變換集，尋找一個性能最好的表達式從而形成一個查詢。但是計算查詢優(yōu)化的耗時不能過長完整性約束：組件約束，引用約束視圖：是一個SQL語句，當使用到SQL語句進行查詢的時候才生成這個視圖，在用的時候才會被執(zhí)行。視圖用在：權限：當希望基本表不暴露給別人，所以使用視圖來暴露給別

4、人，此時視圖可能引用到多張表而形成一個可以被其他應用所看到和使用的視圖，從而保護基本表不被別人看到。與接口類似重構：用在數據庫重構中。完成了數據庫重構中，而將原來的表做成完全一樣的視圖，此時內部的所有重構都不會影響到外部的使用（外部應用使用視圖）。如果視圖引用到大于4張表，此時應當考慮到性能的問題，但是應用不會看到視圖的引用情況，所以使用視圖可能會掩蓋一些現(xiàn)象事務處理：需要有時間戳的概念（為了避免臟讀），出現(xiàn)臟讀需要回滾，但是Oracle不回滾而DB2和SQL Server都會回滾。Oracle稱其為一致性讀。NULL值就是不知道它是什么值的一個值，但是SQL Server認為空值是一個值。這

5、些問題會導致數據庫移植變得十分困難復雜事情：數據庫遷移；數據庫重構SQL：SQL的復雜度取決于from后面包含的表數量（笛卡爾積的基數）。沒有任何廠商支持完整的SQL99標準，而是只支持最基本的部分（query table/ query view/ select/ insert/ update/ delete）。每一個數據庫的存儲過程和觸發(fā)器都不一樣范式（使用范式來降低數據庫設計產生的冗余，有冗余則導致維護數據庫會帶來更多的操作。有時可能會打破范式形成一定的冗余，為了提高數據庫的性能，逆范式和反范式只有幾種方式）1范式（字段都是原子型單值，只被當成一個值來使用，這個值不做拆分進行驗證）3范式（

6、沒有函數依賴，身份證、性別、生日三個字段都存在的話，則不滿足第三范式，因為這些字段之間有函數依賴）（第二課）任何DBMS都可以支持三千個并發(fā)連接，超過三千個連接則需要使用其他方式來改善并發(fā)的性能。而理論上應用的并發(fā)數量無窮大并發(fā)修改針對的是數據庫上的某一個獨立資源。三千個并發(fā)連接可以并行使用同一個數據庫，但是不能同時修改其中的一個資源，即對資源的修改是串行的（為了保證數據庫的一致性）。這個資源稱為原子資源，page/block是數據讀取的最小單位。DBMS從硬盤中讀取數據不是按記錄讀取的，而是按塊（讀取完整的、固定大小的數據塊，當中包含多條記錄）讀取，而后修改其中一條記錄Oracle允許臟讀，

7、而NoSQL則不考慮數據的一致性性能在數據庫中非常重要。性能可度量，它的可度量的性能指標是吞吐量。性能在設計之前需要被測試（SQL的寫法、索引、文件存儲方式、表結構的設計都可以影響數據庫的性能，其中表結構的設計涉及到范式、反范式、逆范式）。數據庫的設計結果中，邏輯設計是表結構，物理設計是索引和物理組織形式缺省的索引結構為B樹索引，而oracle中的索引結構為位圖索引。位圖索引對于低頻字段（可取值的范圍小）可以大幅提高存取效率，當位圖索引的索引鍵進行切換修改的時候（N-Y），切換過程中與N相關的字段都會被鎖住每一個SQL的查詢都有很多查詢路徑，但是不能遍歷所有的路徑，所以必須要設置一個timeo

8、ut時間段DBA的職責：系統(tǒng)數據備份，系統(tǒng)數據恢復（恢復備份的數據）。開發(fā)人員則需要做配置工作，比如表設計、觸發(fā)器、視圖、索引設計、緩沖區(qū)大小設計等。普遍認為，索引以下的更底層的任務由DBA完成對于樹結構，oracle中使用with關鍵字實現(xiàn)遞歸，或者使用connect by start with來實現(xiàn)自頂向下或者自底向上的查詢二維表就是關系，關系操作是表和表之間的操作。關系不包含重復的數據，但是DBMS中并未這樣實現(xiàn)；關系的記錄之間沒有順序，如果數據之間有次序要求，則不能被稱為一張關系表，而記錄的順序往往會影響查詢的效率數據庫中不存在Yes/No或者True/False這樣的字段業(yè)務的約束可

9、以放在程序中檢查，也可以放在數據庫中比如：使用check關鍵字定義數據的取值范圍，對字段的有效性進行檢查；而購買操作可能包含多條數據庫操作，比如庫存減一、配送單加一，可以把它們作為一個業(yè)務邏輯“購買”，也可以放在程序中操作。如果數據庫是一個中心級數據庫，有多個應用對數據庫訪問，將業(yè)務邏輯放在數據庫中可以使得該業(yè)務邏輯被多個應用共享，業(yè)務邏輯發(fā)生變化時只需要修改一個業(yè)務邏輯；而某一個字段的取值范圍也應當放入數據庫中限制當有多值字段時（比如一個產品有多個歷史價格），則滿足范式的做法是再使用一個新的數據表，當中存儲產品ID和產品價格。這樣做的話會導致需要查詢多個數據表在架構層面上解決數據庫性能問題：

10、將耗時間的數據庫操作放在不密集的環(huán)境當中。比如所有的銀行跨行清算都是批處理模式，而這種清算都是在深夜進行同步操作：存取金額都是同步操作，必須要實時處理的業(yè)務異步操作：銀行清算屬于異步操作。異步處理方式處理很多不必要實時處理的業(yè)務，從而提高數據庫性能處理數據庫的方式同步和異步集中和分布式（第四課）避免在select后使用*和distinct，因為即使有重復行，也可以在程序中進行處理，但是如果直接用distinct處理可能會導致產生錯誤的結果普通查詢的過程：先做from，再做select，再做wheredistinct - exists如果通過不同的SQL寫法來完成必須去掉重復行這一約束？使用ex

11、ists關鍵字解決distinct的問題，需要用到嵌套查詢。exists嵌套被稱為關聯(lián)嵌套，在子查詢中需要用到外層插敘的表，所以子查詢不能單獨運行。一般而言是檢查外部查詢的每一行數據（針對外層查詢的每一個記錄），代入到子查詢中作為子查詢的條件。exists后的查詢只要不為空，則條件值為true。exists查詢應用于某一條件在結果集中所占比例較小的情況，在這種情況下使用exists查詢能大幅度提高查詢效率，因為執(zhí)行次數少（子查詢找到第一個結果就可以返回）。如果某一條件所占比重較大，則可以使用關鍵字in的嵌套查詢外層查詢所用到的字段的條件所對應的內層查詢的字段一定要在表中加上索引，這樣才能提高內

12、部查詢的執(zhí)行效率內部查詢并不需要計算查詢結果集，只判斷是不是有滿足內部查詢的結果，換句話說，內部查詢并不一定將查詢執(zhí)行完畢，可能在找到第一條滿足條件的數據后就完成執(zhí)行。故而，子查詢的計算時間難以估算使用exists暗示查詢優(yōu)化器，這個查詢的查詢計劃是：內部查詢的查詢優(yōu)化，內部查詢的優(yōu)化是隨機方式，內部進行獨立的優(yōu)化；內部查詢是單表查詢，難以優(yōu)化exists查詢的好處內部查詢優(yōu)化完畢之后不會被完整執(zhí)行內部查詢中的join關系與外部查詢的表沒有直接的叉乘關系，而是代入外部查詢的結果值到內部查詢中。這樣做減少了一次叉乘的過程，但是導致內部查詢要被代入多次避免了distinct所帶來的結果集錯誤的問題

13、，因為它最主要的工作是對外部查詢中的表格做選擇，而不是對join后的表格做選擇exists和in的區(qū)別exists被優(yōu)化一次后執(zhí)行多次，但是每一次都不一定要執(zhí)行完。由于在查詢優(yōu)化器中，優(yōu)化的時間遠遠超過執(zhí)行的時間，所以exists雖然需要執(zhí)行多次，但是它的效率可能反而較高。執(zhí)行exists要求外部條件所占比重小，這樣能刪掉大部分的外部查詢結果，故而子查詢的執(zhí)行次數少in被優(yōu)化一次后只需要執(zhí)行一次，但是必須是完整的執(zhí)行，然后再與外部查詢的結果比較找到交集。如果外層查詢的條件所占比例較大的話，則in的查詢效率都會遠遠超過exists使用查詢計劃告訴DBMS的查詢工作一個訂單有多個狀態(tài)的話，根據三范

14、式的要求，必須將訂單狀態(tài)放在另一個表中，將訂單號作為該表的外鍵，與狀態(tài)一起作為該表的主鍵在訂單和客戶的例子中（PDF27頁），orderstatus被使用多次，通過查詢的寫法減少它的遍歷次數可以優(yōu)化查詢的過程?？梢詫蓚€子查詢結合在一起，找到最后的狀態(tài)并判斷它是不是完成狀態(tài)。解決的方法是，將查詢每一個訂單的最后結果的子查詢的結果關系表作為外部查詢的from中所要引用到的表，則這樣該查詢只需要執(zhí)行一次。這種優(yōu)化方法主要用于處理一張表被使用多次的情況（降低一張表的使用次數主要是在from后加入子查詢，該子查詢針對該使用多次的表，而且往往需要用到group by以及相應的aggregation操作）

15、查詢優(yōu)化的兩種方式當需要使用多次join的情況下，考慮使用exists和in來進行查詢優(yōu)化降低連接表的個數（降維），當有一張表被多次訪問時，要考慮合并其中的查詢（第六課）外鍵和索引如果沒有外鍵和引用的話，一次修改會導致多次修改大系統(tǒng)普遍取消外鍵的關聯(lián)，取消參照完整性（降低在更新主表時候的過多引用）是提高數據庫性能的一個措施。如果有大量的外鍵關聯(lián)，則做一次主表查詢可能會導致連接多個代碼表如果有外鍵的話，則需要對外鍵加上索引每個數據庫都會有一個自動生成（遞增）的序列號自己解決：在插入一行數據的時候，需要先找到當前的最大值，然后對當前值遞增作為新數據的值?？梢允褂靡粋€表，記錄其他表的當前序列號的最大

16、值，每次更新后修改最大值。它帶來的問題是串行化的插入，因為這個表需要被串行化的訪問，所以每一次對該數據庫的任意一張表插入新數據的動作都必須是串行的為了解決上述的串行化訪問的問題，必須采用系統(tǒng)所提供的自動遞增序列號的方式但是即便系統(tǒng)自動生成的序列號可以并發(fā)進行（導致插入數據可以并發(fā)進行），但是索引不能并發(fā)（如果索引是連續(xù)的，則一般會在一個塊中），即便插入數據表的操作可以并發(fā)，但是索引仍舊需要串行化操作解決上述問題的方式：反向鍵索引/逆向索引。當42、43、44三個記錄同時插入時，可以插入到不同塊中實現(xiàn)并發(fā)插入，但是插入索引還是串行化的（索引鍵連續(xù)，可能在同一塊中）?？梢詫㈡I逆向變成24、34、4

17、4，此時它們不再連續(xù)，就可能不在同一個塊中，可能可以實現(xiàn)并發(fā)插入使用上述方法，不僅在堆文件中可以實現(xiàn)并發(fā)插入（插入記錄），同時也可以在基本文件中實現(xiàn)并發(fā)插入（插入索引）質疑：毫無意義的系統(tǒng)自動生成鍵作為主鍵，是否有意義？（毫無意義的字段放到表中是否有意義？）如果不使用自動生成鍵，可能不能保證主鍵的取值一定是唯一的（比如身份證都可能會重復）不習慣使用非數值型的字段做表的主鍵從索引結構的角度來看和對數值型索引的處理方式來看，字符串索引的處理速度遠遠小于對數值索引的處理速度沒有使用索引的情況謂詞中沒有使用索引的最前列，所有的B+樹都是在索引的第一個鍵值上構建索引count(*)在全表中算行數，不使用

18、到索引。如果鍵有控制，count()操作仍舊算這些記錄，但是索引中不記錄空值（B樹索引不對空值構建索引，子節(jié)點中都有值）對于一個有索引的列做函數查詢或者隱形函數查詢（主要是時間和類型變化這兩種隱形函數查詢）使用索引是否會帶來效率的提高（查詢優(yōu)化器根據統(tǒng)計信息進行判斷）如果使用到索引反而會更慢。查詢優(yōu)化器未必會使用索引，使用前會先判斷使用索引有沒有價值，根據查詢的統(tǒng)計信息判斷是使用索引的評分高還是不使用索引的評分高如果查詢優(yōu)化器發(fā)現(xiàn)當前的查詢不該使用索引，所以它所制定的查詢計劃不包括所提供鍵的索引查詢。查詢優(yōu)化器根據統(tǒng)計信息進行判斷，如果統(tǒng)計信息是錯誤的，則查詢優(yōu)化器的判斷也是錯誤的使用索引的基

19、本要求是索引可用，且索引對查詢有幫助訪問索引的方式是點狀訪問，得出的結果是滿足條件的所以快的編號。索引所做的工作是：通過索引找到所需要的記錄；讀取這個記錄（通過堆文件來讀取記錄）數據庫的物理實現(xiàn)數據庫的數據存在數據庫所設計的文件中，數據文件在絕大多數情況下是堆文件。我們看到的是該文件的邏輯過程（二維表的讀取），而不能看到它的物理過程（記錄的存放、讀?。祿毂硎谴鎯Ψ绞降某橄筮^程，它屏蔽了所有的存儲過程的物理細節(jié)。比較關鍵的兩點是如何讀取數據以及數據的組織過程盡管物理結構與SQL沒有直接關系，但是使用SQL的好壞卻受物理結構的影響數據庫存在大量的沖突并發(fā)用戶數量大的系統(tǒng)緊湊：數據的緊湊程度和查

20、詢效率有正向相關關系。緊湊意味著一個塊中能夠存取更多的數據，如果有一定的順序的話，數據的緊湊度直接影響查詢效率。如果塊中能存更多的記錄，則一次查詢所需要讀取的塊的數量會降低（全表遍歷的效率會提高）分散：從并發(fā)的角度來看，數據越緊湊則并發(fā)數越低。數據緊湊則塊數少，則能夠支持的并發(fā)數量少。（3000個并發(fā)是一個很大的并發(fā)概念）。為了提高并發(fā)數量，需要將數據存儲的更加分散。所以需要在查詢效率和并發(fā)數量中間取一個平衡點任何提高查詢效率的手段，都會帶來某些性能的下降。整體提高數據庫應用效率的措施，應當是提高了大部分事務效率而降低了小部分事務的效率。頻繁事務效率提高的同時，非頻繁事務的效率會下降?？赡軙?/p>

21、用批處理的方式來處理頻繁事務，而使用實時處理的方式來處理非頻繁事務IOT索引組織表（根據索引結構存儲基本文件數據，只有Oracle提供這種存儲方式）數據的組織不再是隨機地向某一個塊中插入，而是使用一個B+樹索引結構，在主鍵索引中存儲表中的所有數據（按照主鍵的順序在索引中存儲所有的數據）優(yōu)點：它是一個有順序的存儲方式，而不是隨機的。針對一定范圍的（有層次的范圍）查詢是非常高效的缺點：更改文件的順序會造成極大的更新代價，這種代價在隨機文件中就不存在本質：把一個數據庫文件存成index的方式聚簇索引比如有兩個表staff和department，分別有10個塊和3個塊用于存儲數據記錄。clustere

22、d index的存儲方式將這兩個表中融合在一起存儲，比如在一個塊中存儲department表中ID=1的記錄，以及staff表中外鍵=1的所有記錄。塊中的存儲沒有順序優(yōu)點：在查詢中需要join的情況（select name from staff where dID = ），這樣的存儲方式會提高查詢的效率數據庫分組原因：數據庫出錯需要備份，數據庫使用redu、undo日志來進行備份和回復（rollback），備份過程只能祈禱不要出錯，如果出錯，則整個備份活動失敗。為了防止備份出錯，則可以將記錄分組，存在不同的物理設備上，這樣即使出錯，也只是一個分組的備份出錯sybase最早提出partition

23、，希望能從管理數據庫的角度降低DBA的心理壓力。partition提供了一種數據管理的方法分組可以提高并發(fā)性舉例：當物理并發(fā)滿足并發(fā)性要求后，會考慮提高數據密集度來提高查詢效率，所采用的方式是滑動窗口如將存儲分成13個區(qū)，前12個區(qū)存當前12個月的數據，最后一個區(qū)存歷史數據；當時間進入到下一個月后，則為新的月新開一個區(qū)，而將倒數第二個區(qū)并入歷史數據中使用這種方式，當月的數據存入獨立的空間中，必定會提高查詢效率，但是降低了并發(fā)大小的可能性，所以可以將當月數據放入并發(fā)性較高的區(qū)，而將歷史數據方式并發(fā)性較低的區(qū)并發(fā)時，當前月所在的區(qū)的并發(fā)率最高，資源競爭最激烈。數據集中提高查詢效率，必然導致并發(fā)性下

24、降，所以應當從區(qū)的內部提高并發(fā)性（比如提供很多存儲塊）以上均為物理存儲，表面來講仍然是一個邏輯表分區(qū)方式根據記錄的值，將原來邏輯表中的數據按照行分到不同的分區(qū)中根據字段分區(qū)，將不同的列存入不同的分區(qū)中，重點照顧頻繁訪問到的列范圍分區(qū)、列表分區(qū)，希望在查詢過程中讓數據更加具體，而哈希分區(qū)希望在更大程度上提高并發(fā)性（第七課）分區(qū)范圍分區(qū)：根據字段的值把記錄分散在不同的物理存儲空間。分區(qū)最核心的目標是為了方便管理滑動窗口：按照時間分區(qū)可以使得最常使用到的數據被聚集在一起，這樣可以提高檢索效率。絕大部分銀行系統(tǒng)都是針對最近的數據加以訪問可以把最需要的數據（當月、當前的數據）放到最快的物理設備當中，通過

25、物理的部署狀況來提高查詢效率哈希分區(qū)：把數據按照某種不同的比例平均分在不同的物理區(qū)域，將數據分布的話出現(xiàn)錯誤后回滾的壓力較小分區(qū)缺點：從本質上來說降低了并發(fā)的個數，但是在數據量非常龐大的情況下，降低并發(fā)所帶來的缺陷遠遠小于分區(qū)所提高的性能并發(fā)和數據密集的沖突是一對不能被解決的矛盾，或者讀和寫是一對不能被解決的矛盾應當找到頻繁發(fā)生的事情，提高該事情的性能，并降低該事情所消耗的資源由于強制的數據聚合可能會導致其他數據的分散，所以不同的查詢請求也可能會形成性能上的矛盾分區(qū)注意：希望分區(qū)能夠平均分布，均衡；避免更新操作頻繁地移動分區(qū)，因為分區(qū)的移動會消耗大量的資源（以時間做partition key的

26、話，數據不會輕易移動）事務的三種狀態(tài)：等待W；正在被處理P；結束D如果某一個事務正在被處理，則它所涉及的數據表（分區(qū)）需要被鎖起來，如果大量的事務同時涉及同一個分區(qū)，則會導致并發(fā)數量的下降通過服務類型進行分區(qū)：應當把數據均衡地分布到不同的分區(qū)中，比如T1處理第一個分區(qū)，T2處理第二個分區(qū)，則這兩個事務可以完全地并發(fā)，不會導致并發(fā)數量下降通過狀態(tài)進行分區(qū)：分成三個區(qū)域，W區(qū)域存儲等待的數據，P區(qū)域存儲正在被處理的數據，D區(qū)域存儲已經結束的數據。將所有等待的數據放在同一個區(qū)域中，則減少了輪詢所消耗的時間（不這樣做的話，則需要輪詢尋找第一個需要被處理的數據）。每一個記錄在移動分區(qū)的時候（狀態(tài)變化），

27、不存在并發(fā)的沖突（不需要將分區(qū)鎖起來）。這種方案的最大特征：通過記錄在分區(qū)之間的不斷移動，可以降低某一個分區(qū)對同一個資源/記錄的競爭壓力除了堆文件，所有的物理環(huán)境都能帶來復雜性；存儲方式的變化會導致性能的下降。解決這些問題的方法只有測試層次機構關系型數據庫無法直觀地解決層次式問題，所以需要一種變換。關系型數據表中的字段之間是平級且等價的，沒有層次關系層次式結構（樹狀結構）不能直接放在關系型數據庫中，需要變換一種形式。樹狀結構中，節(jié)點之間有父子關系，存在兄弟節(jié)點，有根節(jié)點也有子節(jié)點簡單樹狀結構要求：一個節(jié)點只有一個父節(jié)點；所有的節(jié)點類型都是一樣的。如果存在多個父節(jié)點，則為物料單BOM簡單樹狀結構

28、的例子：檔案位置（樓-層-房間-櫥-柜），找到檔案是一個自頂向下的遍歷過程；風險分析（解決對沖基金的風險問題，一個基金可能包含多種基金、股票，甚至有可能包含平級的基金。計算一個基金的風險，要計算這個基金的組成部分的加權風險）將簡單樹狀結構存儲到數據庫中（建模）鄰接模型，使用ID來存儲每一個節(jié)點，使用PID（父節(jié)點ID）來存儲樹狀結構。這種方式假設兄弟節(jié)點無序。這種方式不支持多父節(jié)點，即物料單結構。在單父節(jié)點的情況下，鄰接模型是最重要的存儲方式物化路徑模型，PathID（1，1.1，1.2，1.1.1，1.2.1，），使用層次式的路徑明確地標識出來。它允許節(jié)點之間有順序（因為路徑的標識有順序），

29、比如家族族譜嵌套集合模型，每一個節(jié)點都有一個左編號和右編號某一節(jié)點（A節(jié)點）的所有節(jié)點，它的左右編號都在A節(jié)點的左右編號之間按照深度遍歷進行左編號，遍歷到葉節(jié)點后再原路返回進行右編號，而后再繼續(xù)深度遍歷進行左編號按照此遍歷方式，根節(jié)點的左編號是編號1，右編號是最后一個編號N，而它的第一個直接子節(jié)點的左編號是2，它的最后一個直接子節(jié)點的右編號是N-1當發(fā)生更新之后，整個結構的編號都要發(fā)生變化，所以增加節(jié)點和刪除節(jié)點會帶來很多開銷，所以較少使用使用這個方法，找到某一個節(jié)點的子節(jié)點很方便，所有左編號和右編號在這個節(jié)點的左右編號之間的節(jié)點，都是它的子節(jié)點（第八課）作業(yè)2A - B有一個班次G7001，

30、中間途徑C、D。現(xiàn)在可能購買A-C的車票，C-B的車票，這種情況下怎么在數據庫表結構中間解決這個問題。即實現(xiàn)區(qū)間購買票的記錄，以及對剩余票的檢索抽象和實際的問題。G7001是一個抽象的概念，真正跑的車次是今天早晨8：00出發(fā)的G7001。對于這樣的火車編號來說，它一天最多只開一班，但是有可能隔天發(fā)車，比如每周2、4、6、1發(fā)車（或者每隔1/2天發(fā)車；或者每隔兩天，同時逢10號開），需要判斷這班火車今天是否開車。探討如何將這個內容記錄在數據庫中（可以存儲規(guī)則，也可以存儲當前時刻表。不好使用存儲、比對字符串的方式）火車上有一組對應的班組人員（班組成員的數量會有規(guī)則，即為潛在的約束），包括一個司機、

31、一個列車長、若干列車員、一個車警。班組人員可能會變動，而且每天的G7001不可能都是同一個班組，所以需要一個排班表?？赡軙樵兡骋惶斓哪骋粋€班次的班組人員，也可能會統(tǒng)計某個車警一周工作的天數每一列真實運行的班次都有可能晚點，比如在C點晚點，如何計算實際到達B點的時間。有些情況下以上內容可以記錄在數據庫中，有些情況下可以即時計算A-B-C-D，要記錄在B-C之間有哪些具體的座位賣出去了，哪些具體的座位沒有賣出去作業(yè)要求（作業(yè)1和作業(yè)2都要如此）以文本提交作業(yè)結果提供一個數據庫模式（即數據庫表結構），最簡單的表結構T(column1, column2, column3, column4)提供一個滿

32、足查詢的SQL語句可以提供多種數據庫設計，并且運行在不同的平臺之上，并說明它們的不同以create table的方式構建表結構，使用關鍵字check來設置表結構的約束例子：普法戰(zhàn)爭自頂向下查詢，查詢Vandamme所管轄的所有部隊鄰接模型查找某一個節(jié)點的所有子節(jié)點，這是一個典型的遞歸過程。首先需要找到這個節(jié)點的所有直接子節(jié)點，查出來之后放在一個臨時表中；然后遍歷臨時表，找到表里每一個節(jié)點的直接子節(jié)點，繼續(xù)放入臨時表中。直到沒有新的節(jié)點放入臨時表中，則遞歸結束，臨時表存放了一開始的節(jié)點的所有子節(jié)點實現(xiàn)遞歸過程，Oracle提供的關鍵字connect by。而SQL標準實現(xiàn)遞歸的關鍵字是with，

33、DB2最早使用with。with是一個基于關系操作的遞歸過程，而connect by完全地去關系化，是一個基于過程的查詢方式，所以它的查詢效率非常高對于物化路徑的存儲方式，子節(jié)點的前綴就是父節(jié)點的路徑，找到某個節(jié)點的子節(jié)點，只需要匹配它們的前綴即可。但是物化路徑的效率不如鄰接模型的效率高，因為物化路徑最關鍵的部分是字符串比較，它最大的問題是拆分字符串可以使用01010102來代替路徑1.1.1.2，計算它的深度就是路徑字符串長度除以二，即strlen(“01010102”)/2使用一個系統(tǒng)自動生成的ID，而不是使用物化的路徑作為字段ID嵌套集合模型，子節(jié)點的left_num和right_num

34、都在根節(jié)點的left_num和right_num的范圍之內。它無法直接獲得節(jié)點的層次自底向上查詢，查詢某一個子節(jié)點的所有祖先節(jié)點關系操作可以合并相同的父節(jié)點，很容易地找到所有的祖先結果集，但是不能做到很好的層次排序MySQL有一個機制，可以解決字串索引的問題，substring index因為自底向上需要遍歷多個節(jié)點，而自頂向下只需要遍歷一個節(jié)點，所以物化路徑的方式，自底向上的查詢效率遠遠低于自頂向下的查詢效率對于嵌套集合模型，自頂向下和自底向上的查詢效率相同，它們的差異僅僅體現(xiàn)在自底向上查詢的排序過程，這個排序比較耗時間樹狀結構的聚合計算在部隊的樹狀結構中，葉節(jié)點往往存儲一個數值，說明了一個

35、團的士兵人數。可以將兄弟葉節(jié)點聚合，得到它們的父節(jié)點的數值，即一個旅的士兵人數使用oracle的connect by關鍵字進行遞歸。connect by .start with方式，只能獲取自頂向下和自底向上的最終結果，而不保存中間的遞歸過程，所以每一級別都需要做一次自底向上的操作，效率降低（第九課）要封裝數據庫，JDBC仍然不方便，因為存在關系和關系對象之間的mismatch一個對象不可能存在一張關系表中，如果這樣存儲，則應當為對象數據庫而不是關系數據庫。一個對象可能存在多張表中ORM，封裝數據訪問的過程。數據封裝層主要用來屏蔽業(yè)務邏輯，屏蔽OO與關系之間的差異性，設置關系表和對象之間的關系

36、數據庫封裝的優(yōu)點應用程序員能夠專注于（應用的）業(yè)務問題可以實現(xiàn)公共的面向的對象的業(yè)務規(guī)則仍舊能夠利用數據庫的特性提高應用程序的性能（第十課）數據庫方法學Database planning，數據庫設計的計劃System definition，最主要的是定義系統(tǒng)的邊界Requirements collection and analysis，需求分析和收集，收集表單和行為Database design，邏輯設計（與具體的數據庫無關）和物理設計（與具體的數據庫有關）比如在構建索引的時候，就從邏輯數據庫設計進入物理數據庫設計。數據庫系統(tǒng)與文件系統(tǒng)的差別，在于并發(fā)修改（而不是并發(fā)讀）。數據庫系統(tǒng)是處于并發(fā)

37、修改的最好載體；數據量大并不足以使文件系統(tǒng)轉變成數據庫，而如果數據關系復雜的話，則需要將信息存入數據庫中；必須要安全存儲的信息需要存到數據庫中。正常情況下，文件系統(tǒng)的效率遠遠高于數據庫的效率DBMS selection，選擇哪一個具體數據庫。如果有遺留數據庫，則選擇遺留的數據庫系統(tǒng)；或者某個數據庫系統(tǒng)有其他數據庫沒有的特性，比如OracleApplication designPrototypingImplementationData conversion and loading，數據轉換指的是數據庫的遷移，loading指的是對遺留數據庫的重構TestingOperational mainte

38、nance邏輯設計（ER圖）。ER圖最大的問題是，其在UML中沒有標準MDA模型驅動架構。畫完UML圖后，程序結構和邏輯就可以生成強實體和弱實體。強實體是可以由自己的主鍵標識自己的實體，比如課程有課程號，學生有學號，都是強實體。如果選課是由課程號和學好來限制的話，則其沒有標識自己的主鍵，屬于弱實體；如果選課有一個選課流水號來標識自己的話，則它也算是強實體關于人與公司的雇傭關系，可以有兩種設計表達：（1）人與公司是多對多的關系，它們產生一個雇傭關系，雇傭關系中有雇傭的屬性；（2）人與公司沒有直接的關系，人可以有多份合同說明他所在的公司以及相關的雇傭屬性，公司也可以有多份合同說明它雇傭的員工。第一

39、種中，雇傭關系是弱實體，一個員工和一個公司只可能產生一個關聯(lián)實例；第二種中，合同是強實體，一個員工和一個公司可以產生多個關聯(lián)實例（因為合同由合同號來標識）注意ER模型中的一對一、一對多、多對一、多對多的關系，以及一個實體是否強制參與某個關系1:1，一對一全部參與可以放在一張表中，并且不會有空值一對一部分參與必須分在兩張表中，如果放在一張表中則會出現(xiàn)很多空值。如果是一個全部參與一個部分參與的話，則將全部參與的實體的主鍵放在部分參與的表中作為外鍵（以此來描述他們的對應關系）；如果兩個都是部分參與的話，則參與更多的一方的主鍵放入參與更少的一方的表中作為外鍵，這樣能產生較少的空值多對多會產生一個關系表

40、，將相關的兩個實體的主鍵作為復合外鍵，作為關系實體的主鍵。這樣關系產生的實體是一個弱實體強制性地表達表中的完整性約束，no action，cascade，set null，set default，no check。這些關鍵字說明了主鍵被刪除后，外鍵應該怎么辦數據庫泛化的問題。比如設置一個Staff實體為父實體，它有manager、salesPersonnel、secretary三個子實體，它們共享父實體中的屬性。這種結構會產生以下的約束參與約束，participation constraint，是不是所有的實例都存在于某一個子實體中，父實體只是一個抽象的概念。即是不是所有的員工都屬于某一個職位

41、，如果有一個員工不是子實體中的一員，則他為父實體的實例，這屬于部分參與disjoint constraint，互斥約束。一個實例是不是只屬于一個子實體。如果一個人，他既是manager又是sales，則manager和sales這兩個子實體是overlap的，不是disjoint的數據庫泛化的約束產生的結果mandatory + nondisjoint，完全參與且不互斥，則所有的父實體+子實體都使用一張表，雖然可能會因為某個實例不屬于某一個子實體而產生空值，但是產生的空值比較少，所以可以optional + nondisjoint，部分參與且不互斥，則將父實體做成單獨的一張表，所有的子實體做成

42、一張表mandatory + disjoint，完全參與，但是互斥，則父實體產生一個主表，子實體分別分成一個表optional + disjoint，部分參與，但是互斥，則父實體產生一個主表，子實體分別分成一個表。只要是disjoint的情況，都要將子實體拆分成獨立的子表逆范式/反范式（打破三范式的規(guī)則來生成冗余數據）合并1：1關系部分合并1：*關系，不復制外關鍵字而復制常用的字段比如staff和department之間有一對多的關系，將department中常被連接查詢的字段復制并遷移到staff表中（比如department的名字是一般需要查詢到的，則將名字放入staff表中，這樣查詢st

43、aff所屬部門的名字時就不需要連接兩個表了），降低連接查詢的數量使用“一致性控制”模式來保證兩個表中冗余字段的一致性，這種控制放在UI界面中進行，使用combo list或者check box進行選擇，而不是獲取用戶的輸入在1：*關系中復制外關鍵字在*：*關系中復制屬性比如多對多關系的orders、articles的關系，有一個關系表中保存了oid和aid。如果要知道某個訂單中某個產品的名字和價格的話，則需要三表連接在現(xiàn)今的電子商務系統(tǒng)中，article的某些屬性會直接復制到關系表中，即關系表中除了oid和aid之后，還包括price（price現(xiàn)在已經是缺省放入關系表的字段）、article name、數量為了避免查詢和更新這兩個不可調和的矛盾，可以將更新和查詢放在兩張表中，從工作表提取出查詢表，專門用于查詢。這個方法演化成了數據倉庫。這個方法只適用于查詢的實時性要求不高的情況物理設計（第十一課）SAP + HANA數據以列的形式存在數據庫中。當需要查詢某幾個列的數據時，只需要將這幾個列中的數據移入內存之中（第十二課）列數據庫column family: 任何的co