檢視與索引

在某些情況下，讓所有使用者看到整個邏輯模型是不合適的
考慮一個職員需要知道教師的標識、姓名和所在系名，但是沒有許可權看到教師的工資值，此人應該看到的關係由如下SQL語句所描述：
select ID,name,dept_name
from instructor
檢視就提供了這種機制：向使用者隱藏特定的資料，和一些許可權管理相關內容相結合可以進行安全方面的處理
SQL允許通過查詢來定義“虛關係“，它在概念上包含查詢的結果，但並不預先計算並儲存。像這種所謂虛關係對使用者可見的關係稱為檢視（對view的訪問都要轉換成對物理表的訪問）

1. 檢視定義

create 和之前的with as有什麼區別？create view是logical 、virtual的，但with佔空間

在instructor中對老師按照院系分類，然後將院系的名字和工資總和select出來，然後用來建立departments_total_salary檢視，還可以在檢視中對相關屬性進行命名

2. 檢視更新

插入的時候針對物理表進行插入，也就是values中應該包含實際上的instructor中的所有屬性，但是上面那個並沒有全部插入，所以沒有寫進的屬性都被賦值成null

在實際構建這個檢視的時候使用了兩張table——instructor和department，那麼對這樣一張view進行一條資訊的插入的話實際上是對兩個table進行插入，同樣也是沒有value寫出的地方用null代替。
但實際上會出現問題——插入的department的資訊是已經有的了，重複；還有如果插入的department資訊沒有，但是Taylor並不是主鍵，而正常的主鍵的位置卻是null，這樣其實也不允許的。
因此定義一個檢視之後是否是update是有條件的：

1. 解釋如上
2. 表示式和聚集的話，沒有辦法把這個表示式或者聚集的關係反推，聚集之後插入的時候的值沒有辦法對應到具體關係的元組上去了
3. 沒有出現的屬性必須插入空值，但是如果在這個table定義的時候設定成非空，在使用這個table的view進行插入的時候如果values列表裡沒有這個值，則會出錯
4. 和2類似

但是即使滿足上述條件也會出現一些問題：

實際上在預設情況下是允許更新的但是使用者沒有辦法看到插入的記錄因為不滿足構成檢視的條件。如果在語句的末尾加入with check option則不允許加入。

SQL-99對於何時可以在檢視上執行插入、更新和刪除有更復雜的規則集，這裡不予討論。

3. 物化檢視

檢視實際上是不存在的，任何對檢視的操作都會轉換為對錶的操作，這個時候可以建立物化檢視，顧名思義，物化檢視有自己對應的物理儲存，不用去底層訪問對應的table
維護的三種方式的解釋：
一旦關係被更新就更新檢視；在關係被更新的時候先不更新檢視，而是等到檢視被使用的時候才去更新檢視；週期性定時更新檢視（維護的工作量不大，但是資料可能是過時的，但是對於一些對時效性要求不高的應用可以使用這種方法。

【類似Cache處理的直寫法和寫回法】

4. 索引

索引在資料庫中查詢速度蠻快的，但是前提是在資料庫的table中只有幾千條或者幾萬條資料的時候，但是當表中的資料不斷增加如果不建立索引而去直接查詢的話，會發現等待的時候非常長

實際上是建立了一個資料結構，只把和查詢有關的儲存下來；
在資料庫中用空間換取時間的一種機制