第一章 資料庫概論
1-1 檔案系統
[檔案處理系統] 2 | 92,106
92地三、106調三(國三)
一、檔案系統的定義
(一)由使用者定義與實作
1.是由使用者自己來定義與實作應用程式所需的檔案，這些檔案是屬於應用程式的程式設計工作的一部分。
2.通常使用硬碟和光碟這樣的儲存裝置，並維護檔案在裝置中的實體位置。
※參考資料：陳玄玲-資料庫系統原理第六版 1~18
(二)舉例
例如註冊組需要維護記錄學生成績的檔案，同時撰寫一些程式來列印學生成績單或是輸入成績到檔案中，這些檔案是應用程式的一部分。而出納組則需要記錄學生的學費與繳款資料。雖然這兩個使用者群組都會用到學生資料，但是卻各自維護不同的檔案與處理這些檔案的程式。像這樣重複定義與儲存資料的現象，不但導致儲存空間的浪費，而且要花雙倍的時間讓兩邊的資料都保持最新。
※參考資料：陳玄玲-資料庫系統原理第六版 1~18
二、檔案系統的優點
(一)資料容易存取
可以提供有效而且方便地存取磁碟方法，那就是允許資料能容易地儲存、找到，以及重新取出。
(二)程式的設計方式相當單純：不須要考慮各部門整合上的問題。
(三)較容易滿足各部門或應用系統的要求：只須要考慮單一部門需求。
※參考資料：李春雄-動畫圖解資料庫系統理論-第一章資料庫導論.ppt
三、檔案系統的缺點
(一)資料重複存放(Data Redundancy)：不同程式或部門皆擁有及維護自己的資料。
(二)資料不一致(inconsistency)
當某一位學生的姓名更改時，必須要同時到「教務處」與「學務處」更改資料。因此，資料內容無法同步更新、欄位或名稱的不一致等。
(三)資料間無法分享共用：只有此檔案相對的應用程式可以使用。
(四)資料保密性和安全性非常低
在檔案系統中沒有安全機制，而資料庫系統則有，因為可以設定資料庫的帳號與密碼。
(五)資料與程式間高度相依：應用程式是針對特定檔案組成而撰寫的。
(六)漫長的開發時間：程式設計師必須設計他們自己的檔案格式。
(七)系統維護成本高：檔案結構改變，應用程式必須重寫。
(八)不易建立資料標準：各部門、各應用程式可能自行建立自己的檔案標準。
(九)程式撰寫無效率：針對不同的檔案結構，撰寫不同的應用程式。
※參考資料：李春雄-動畫圖解資料庫系統理論-第一章資料庫導論.ppt
89年關務人員特考資料處理
|
傳統檔案處理方法與資料庫管理檔案方法各有哪些優點及缺點？（20分） |
答：
(一)資料庫管理檔案方法
1.需要大量分散各地單位的遠端資料分享共用。
2.屬於高度機密性資料、個人隱私範圍需要安全控管。
3.需要建立資料存放的共同標準，因為存取使用者多，重視資料品質。
4.資料重要性高，需要規劃備份回復機制。
註：可以套用「1-2 資料庫系統的五、資料庫的優點」來寫。
1-2 資料庫系統
[資料庫系統] 14 | 87,89,90,93,94,96,97,101(3),102,105,106(2)
87高三、89地三、90地三、93電員晉高、94-2地三、96技高、97高三、101關三、101國三(2)、102調四、105警三、106調三(國三)、106關薦
一、資料庫(Database)
(一)定義
1.資料庫是資料表 (table) 的集合體，一個資料庫可能有一個或多個資料表；資料表是由許多相同格式的資料記錄 (record) 所組成；在資料記錄中的每一個屬性稱為欄位 (field)。換言之，橫向的資料記錄和縱向的屬性欄位組織成一個資料表，儲存到電腦儲存設備後，就成了資料庫檔案。
2.將相關資料以系統化且有效率地儲存在一起，減少資料的重複性。
3.可以被特定組織的應用程式系統所使用，透過資料庫管理系統來管理。常見的資料庫有通訊資料庫、學籍資料庫、成績資料庫等，在資料庫中可以只有一個資料表，也可以把數十甚至數百個資料表集合起來。
4.用來建立資料庫系統的軟體種類很多，例如 Access、FoxPro、Informix、Oracle、Sybase、DB2 等。
※參考資料：http://epaper.gotop.com.tw/pdf/ACI009700.pdf
(二)資料庫技術主要特性
1.資料庫系統具有自我描述 (self-describing) 的本質。
2.隔離程式與資料與資料抽象化 (data abstraction)。
3.支援資料的多重景觀 (multiple views)。
4.資料共享 (sharing) 與多使用者的異動處理 (transaction procesing)。
※參考資料：陳玄玲-資料庫系統原理第六版 1-8
二、資料庫管理系統(DataBase Management System, DBMS)
(一)定義
1.是一種操縱和管理資料庫的大型軟體，用於建立、使用和維護資料庫。
2.對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。
3.使用者通過 DBMS 訪問資料庫中的資料，而資料庫管理員透過 DBMS 進行資料庫的維護工作。
4.提供多種功能，可以使多個應用程式和用戶用不同的方法在同時或不同時間去建立、修改和查詢資料庫。
(二)主要組成：資料 (data)、硬體、軟體、使用者。
(三)基本功能：資料庫的定義、建構、處理。
※參考資料：
http://wiki.mbalib.com/zh-tw/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%AE%A1%E7%90%86%E7%B3%BB%E7%BB%9F
三、一個良好的DBMS所應具備的功能
(一)重複性(redundancy)的控制
達成「資料的一致性」及「節省儲存空間」。例如設定「主鍵」來控制 (資料表的主鍵不可重複)。
(二)實施完整性限制(integrity constraints)
1.讓關聯表中的資料在經過新增、修改及刪除之後，不會將錯誤或不合法的資料值存入「資料庫」中。
2.完整性限制有個體整合性限制、參考整合性限制、特定資料整合性限制，例如身份證字號及員工代號不可為空、不可重複。
(三)提供備份(backup)與回復(recovery)
1.提供硬體或軟體故障中回復的功能，回復子系統要確保資料庫回復到程式開始執行前的狀態，或確保程式能從之前中斷處繼續執行。
2.備份策略如每天只備份差異 (有異動) 部份、每週週末執行一次完整備份。
(四)限制未授權的存取：提供安全性與認證機制。
(五)表示資料間的複雜關係：利用資料庫關聯的外鍵 (foreign key)。
(六)提供多重使用者介面：針對不同程度的使用者，提供不同的使用者介面。
(七)使用演繹規則的資料庫推論
從已儲存的資料庫中推論出新的資訊，例如從 Birthday 推算出 Age、資料庫行銷 (Database Marketing) 常透過統計及資料挖掘 (Data Mining) 技術。
(八)程式物件與資料結構的永久儲存：複雜的程式物件或資料結構永久儲存。
四、資料庫系統的自我描述性
不僅僅包含資料庫本身，同時包含了對於資料庫的定義及描述，這些非資料內容本身的資訊儲存於系統目錄 (system catalog) 中，稱為中繼資料 (meta-data)。例如資料庫的儲存結構、資料項的儲存格式、資料間的關係及限制。
五、資料庫的優點
(一)避免資料重複存放(Data Redundancy)
整合重複的資料增加效率。資料重複原因是備份。
(二)避免資料不一致(inconsistency)：任何更新的動作會自動地更新。
(三)資料間的分享共用：不同應用程式共享資料庫的同一份資料。
(四)實施完整性限制(integrity constraints)
1.讓關聯表中的資料在經過新增、修改及刪除之後，不會將錯誤或不合法的資料值存入「資料庫」中。
2.完整性限制有個體整合性限制、參考整合性限制、特定資料整合性限制。例如身份證字號及員工代號不可為空、不可重複。
(五)提供備份與回復功能：必須提供從硬體或軟體故障中回復 (recover) 的能力。
(六)限制未授權的存取
大多數使用者不會被授權可存取資料庫中的全部資訊，例如財務方面的資料通常只有經過授權的人員方可存取。
(七)表示資料之間的複雜關係
一個資料庫可能包含許多種類的資料，彼此間以很多的方式相互關聯。
(八)提供多種使用者介面
因為有很多類型的使用者使用資料庫，他們的技術知識水準不一，所以應該提供多樣化的使用者介面，包括給偶爾使用的使用者所用的查詢語言、應用程式設計人員所用的程式語言介面、固定模式的使用者所用的表單和指令代碼，以及單機使用者所用的功能表介面和自然語言介面等。
(九)使用演繹規則的資料庫推論
從已儲存的資料庫中推論出新的資訊。例如從 Birthday 推算出 Age、資料庫行銷 (Database Marketing) 常透過統計及資料挖掘 (Data Mining) 技術。
(十)程式物件與資料結構的永久儲存
提供複雜的程式物件或資料結構永久儲存。這是物件導向資料庫系統(object-oriented database system) 的主要優點之一。
(十一)提供有效處理查詢的儲存結構和搜尋技術：
資料庫通常是儲存在磁碟中，為了能找到想要的記錄，DBMS 必須提供特定的資料結構以加速磁碟搜尋，而索引 (index) 的使用就是為了這個目的。
(十二)資料獨立性(Data Independence)
邏輯資料獨立 (Logical Data Independence) 與實體資料獨立 (Physical Data Independence)。實體儲存方式改變或資料庫結構改變不需改變上層應用。
※參考資料：陳玄玲-資料庫系統原理第六版 1-15~1-20
※把相同資料儲存多次的重複性(redundancy)現象會導致以下幾個問題：資料重複(data redundancy)會帶來那些問題？
106調四
1.更新動作執行太多次：
同樣的更新動作需要執行很多次。例如假設要輸入一個新學生的資料，就必須修改每個記錄學生資料的檔案，導致事倍功半。
2.儲存空間浪費：
重複儲存相同的資料，對儲存空間而言是一種浪費。如果是大型資料庫，這種問題的後果可能會很嚴重。
3.資料不一致：
(1)不同檔案裡的相同資料，可能變得不一致 (inconsistent)，原因可能是因為修改動作執行的不完全，沒有同時修改所有的檔案，或是因為不同的使用者群組在修改檔案，而使得檔案的內容產生不一致。
(2)例如某個使用者輸入的學生生日資料「1-19-1988」是錯誤的，而另一個使用者輸入的資料「1-29-1988」是正確的，結果同一個學生有兩個生日資料。
※參考資料：陳玄玲-資料庫系統原理第六版 1~16
※控制冗餘(Controlled Redundancy)：有限度的重複性
106調四
1.資料庫技術會將不同使用者群組的視界在資料庫設計階段加以整合。
2.在理想情況下，在設計資料庫時，應該要將每個邏輯資料項目，例如學生的姓名或生日，都只儲存在一個地方。這就是所謂的資料正規化 (data normalization)，它可確保一致性並且可節省儲存空間。
3.不過在實務上，控制冗餘 (有限度的重複性) 可以提高查詢的效率。例如可以在成績報告檔案中重複儲存學生姓名、課程編號，因為只要一擷取成績報告記錄，就一定會擷取學號、學生姓名、選課識別碼、課程編號，以及成績。如果能將所有的資料放在一起，就不用找很多檔案來收集這些資料。這就是所謂的反正規化 (Denormalization)。資料表如下：
成績報告：
|
學號 |
學生姓名 |
選課識別碼 |
課程編號 |
成績 |
|
17 |
Smith |
112 |
MATH2410 |
B |
|
17 |
Smith |
119 |
CS1310 |
C |
|
8 |
Brown |
85 |
MATH2410 |
A |
|
8 |
Brown |
92 |
CS1310 |
A |
|
8 |
Brown |
102 |
CS3320 |
B |
|
8 |
Brown |
135 |
CS3380 |
A |
4.在上述這種情況下，DBMS 應該有能力控制這種重複性，防止檔案間的不一致。做法可能是自動檢查上述的成績報告記錄裡所有的學生姓名/學號值是否都與下列的學生記錄中相對應的學生姓名/學號值相同。同樣的，也可依據選課記錄來檢查成績報告的選課識別碼/課程編號值。像這樣的檢查動作可以在資料庫設計階段在DBMS 上指定，而且設定只要成績報告檔案一更新，DBMS 就會自動強制執行。假如重複性沒有善加控制，就有可能會因為錯誤的輸入。相關資料表如下：
學生：
|
學生姓名 |
學號 |
班級 |
主修 |
|
Smith |
17 |
1 |
CS |
|
Brown |
8 |
2 |
CS |
選課：
|
選課識別碼 |
課程編號 |
一學期 |
年度 |
教師 |
|
85 |
MATH2410 |
Fall |
07 |
King |
|
92 |
CS1310 |
Fall |
07 |
Anderson |
|
102 |
CS3320 |
Spring |
08 |
Knuth |
|
112 |
MATH2410 |
Fall |
08 |
Chang |
|
119 |
CS1310 |
Fall |
08 |
Anderson |
|
135 |
CS3380 |
Fall |
08 |
Stone |
※參考資料：
1.陳玄玲-資料庫系統原理第六版 1~16~1-17
2.https://read01.com/ANLnyo.html
※使用資料庫技術所帶來的間接好處：
1.容易建立資料標準：集中控制。
2.減少應用程式開發時間：資料庫的資料集中化及存取介面標準化。
3.彈性：資料的新增、刪除、修改、擴充皆十分容易。
4.可以提供最新資訊給使用者：資料庫可以即時反應最新狀況。
5.經濟效益：讓資料與應用程式統一，減少不必要的開銷與時間。
※參考資料：陳玄玲-資料庫系統原理第六版 1-20~1-21
六、資料庫的缺點
(一)初期成本高：例如軟體、硬體、教育訓練費用。
(二)設計較複雜：資料需要正規化。
(三)過多的限制
整合性限制 (Integrity)、安全性控制 (Security)、並行控制 (Concurrency)、回復 (Recovery) 等，必須多耗費許多資源來以確保這些限制。
(四)資料存取的速度較慢
(五)資料集中，容易一起被破壞或盜取
(六)佔用較大的儲存空間
(七)軟硬體的成本較高
發展資料庫系統必須另外購買 DBMS，這可能是一套昂貴的軟體 (如 MySQL 到Oracle，其價格可能從數千元到上千萬)，另外執行資料庫系統的硬體平台亦需要較好的配備。
(八)必須考慮備援作業
當資料處理完全使用資料庫系統時，備援作業的考量十分重要，從電源備援 (使用 UPS)、電腦系統備援 (使用兩套主機，其中一個為備援用) 以及人工備援 (電腦當機時) 均應有詳細的規劃。
七、何時不必採用資料庫？
(一)資料與應用程式皆很簡單，不常變化
(二)未來擴充可能性非常小
(三)不需多使用者同時存取
(四)某些應用程式有非常嚴格的即時需求
單純就檔案存取速度，文字檔比 DB 快。
※資料庫的生命週期：
被稱為微觀生命週期(micro life cycle)，包括下列各階段：
1.可行性分析(Feasibility analysis)：
分析可能的應用領域、確認資訊收集與散佈的經濟效益、執行初步的成本效益研究、決定資料與過程的複雜性及設定應用程式的優先順序。
2.需求收集與分析(Requirements collection and analysis)：
細部的需求可經由與預定的使用者或使用者群組溝通，找出他們的問題和需求。另外也要找出應用程式彼此間的相依性、通訊和回報程序。
3.設計(Design)：資料庫系統的設計、使用及處理資料庫的應用系統的設計。
4.實作(Implementation)：
實作資訊系統、載入資料庫，還有實作並測試資料庫異動。
5.驗證與接受度測試(Validation and acceptance testing)：
驗證系統是否符合使用者的需求和效能條件。系統會根據效能條件和行為規格來測試。
6.部署、運作和維護(Deployment, operation and maintenance)：
這可能會在轉換舊系統的使用者和使用者教育訓練之前進行。當所有的系統功能已經過驗證可以使用時，就可以開始運作階段。假如有出現新的需求，必須先經過上述所有的階段。
※參考資料：陳玄玲-資料庫系統原理第六版 9-23
※資料庫系統開發的生命周期：資料庫發展的生命週期
1.資料庫規劃(Preliminary planning)：
描述資料庫系統的目的、功能和預期目標等資訊。
2.需求收集和分析(Requirements collection and analysis)：
依照初步計劃進行資料收集、訪查來確定資料庫系統的需求，在此階段注重的是問題，而不是系統本身，在完成需求的收集後，就可以開始進行分析。
3.設計(Design)：
是資料庫設計與實作部分，當分析完資料庫的需求後，就可以進行資料庫設計。
4.實作(Implementation)：選擇的資料庫管理系統實作資料庫，例如 SQL Server。
5.維護(Maintenance)：
雖然資料庫系統已經設計完成，但是，還是需要定時維護資料庫系統，以維持資料庫系統的正常運作。
※資料庫應用程式發展生命週期各階段的說明：
|
階段 |
工作 |
輸出 |
|
資料庫規劃 (Database planning) |
組織人員，選擇開發工具，定義各階段相關工作，可行性評估 |
1.工作分配表 2.甘特圖 |
|
系統定義 (System definition) |
界定資料庫程式的應用範圍，使用者族群 |
1.組織圖 2.功能圖 |
|
需求收集和分析 (Requirements collection and analysis) |
詳述使用者需求，資料規則，處理方式，輸出輸入的要求 |
1.問題規格書 2.需求規格書 |
|
資料庫設計 (Database design) |
Logical desig、Physical design |
1.實體關係圖 2.資料庫欄位規格書 |
|
選擇資料庫管理系統 (DBMS selection) |
選擇適宜的DBMS，以符合設計需求和程式撰寫環境 |
1.DBMS的規格說明 2.選擇原因說明 |
|
應用程式設計 (Application design) |
建立使用者介面，以及使用和處理資料庫的應用程式 |
1.演算法虛擬碼 2.程式碼 |
|
建立雛型 (Prototyping) |
建立雛型供設計者及使用者測試和評估該系統將來的應有功能和操作介面 |
供評估的程式雛型 |
|
實作 (Implementation) |
建立資料庫表格、資料規則、SQL code、使用者介面和應用程式 |
1.可執行程式 2.建置完成的資料庫 |
|
資料轉換和載入 (Data conversion and loading) |
將舊系統的資料轉移載入到新系統，調整資料符合新系統的規則 |
|
|
測試 (Testing) |
資料處理正確性，效率和是否符合需求 |
測試紀錄 |
|
操作維護 (Operational maintenance) |
監控和維護，機動更新以符合新的規則和需求 |
1.操作說明 2.維護紀錄 |
※參考資料：許薰任-醫療管理系統實作.pdf p.32
※資料庫設計方法論(Database Design Methodology)：
[資料庫設計] 12 | 91(2),94(2),96(2),97,101,104(2),106(3)
91地三(2)、94高二、94-1地三、96公關薦(2)、97調三、101專三、104關三、104鐵高、106警鑑二、106調三(國三)、106調四
(一)定義
1.使用特定程序、技術和工具的結構化設計方法，一種結構化的資料庫設計方法。
2.是一種計劃性、按部就班來進行資料庫設計。
3.對於小型資料庫系統來說，就算沒有使用任何資料庫設計方法論，資料庫設計者一樣可以依據經驗來建立所需的資料庫。但是，對於大型資料庫設計的專案計劃來說，資料庫設計方法論就十分重要。
(二)三個階段
完整資料庫設計共分成概念、邏輯和實體資料庫設計三個階段，如下圖所示：
上述圖例顯示當從真實世界進行需求收集和分析後，就可以撰寫資料庫需求書，通常是使用文字來描述系統需求。接著進行三個階段的資料庫設計來建立所需的資料模型。在這三個階段主要是建立概念、邏輯和實體資料模型。三個階段的資料庫設計如下所示：
1.概念資料庫設計(Conceptual Database Design)：
(1)將資料庫需求轉換成概念資料模型的過程，並沒有針對特定資料庫管理系統或資料庫模型。
(2)概念資料模型是一種使用者了解的模型，用來描述真實世界的資料如何在資料庫中呈現。
(3)實體關聯圖是目前最廣泛使用的概念資料模型。
(4)輸入為資料庫需求；產出為實體關聯圖 (Entity Relationship Diagrams)。
2.邏輯資料庫設計(Logical Database Design)：
(1)將概念資料模型轉換成邏輯資料模型的過程，針對特定的資料庫模型來建立邏輯資料模型，例如關聯式資料庫模型。
(2)邏輯資料模型是一種資料庫管理系統了解的資料模型，擁有完整資料庫綱要，可以使用外來鍵參考圖建立邏輯資料模型。
(3)事實上，實體關聯圖不只可以建立概念資料模型，也可以用來建立邏輯資料模型，其最大差異在於邏輯資料模型是一個已經正規化的實體關聯圖。
(4)邏輯資料庫設計的主要工作有兩項：
a.將實體關聯圖轉換成關聯表綱要：
轉換「個體 (Entity)」、轉換「弱個體 (Weak Entity)」、轉換「二元1對1關係」、轉換「二元1對多關係」、轉換「二元多對多關聯」、轉換「多值屬性 (Multi-valued attribute)」、轉換「多元關係」。
b.關聯表的正規化：
第一正規化、第二正規化、第三正規化、Boyce-Codd正規化、第四正規化、第五正規化。
(5)輸入為實體關聯圖；產出為關聯式資料庫表格 (Relational Database Tables) 及概念綱要 (Conceptual Schema) [正規化的關聯表]。
3.實體資料庫設計(Physical Database Design)：
(1)將邏輯資料模型轉換成實體資料模型的過程，例如將邏輯資料模型轉換成關聯式資料庫管理系統的 SQL 指令敘述，以便建立資料庫。
(2)實體資料模型可以描述資料庫的關聯表、檔案組織、索引設計和額外的完整性限制條件。
(3)輸入為關聯表；產出為內部綱要 (Internal Schema)、資料庫。
※參考資料：
1.chapter5 資料庫設計工具的使用.pdf
2.chapter02eoc_sol.doc
※概念設計(Conceptual Design)：
目標是讓分析師以概念結構圖來表達訊息的流程，以便於讓不熟悉電腦的使用者交換意見。針對使用者的資料需求，使用概念資料模式來產生概念綱要(Conceptual Schema)。例如 ER 圖。
※參考資料：資料庫規劃與設計步驟.ppt
※邏輯設計(Logical Design)：
目的是將概念綱要轉換成真實資料庫管理系統 (DBMS) 的資料模式，例如關聯式、階層式與網路式模式。主要工作是將實體關聯圖轉成 DBMS 綱要 (如關聯式綱要)。關聯式綱要如下：
供應商 (供應商編號，供應商，地址，城市，傳真電話，首頁)
客戶 (客戶編號，公司名稱，地址，城市郵遞，電話，傳真電話)
※參考資料：資料庫規劃與設計步驟.ppt
※實體設計(Physical Design)：
對於設計好的邏輯資料模式 (如關聯式模式) 選取一個適合的程式語言 (如 SQL)。根據邏輯資料庫設計的 DBMS 綱要，使用 SQL 指令建立資料庫。範例如下：
|
描述 |
欄位名稱 |
欄位型態 |
鍵值屬性 |
其他屬性 |
|
客戶編號 |
C_ID |
VARCHAR(10) |
Primary Key |
NOT NULL |
|
客戶姓名 |
C_Name |
VARCHAR(30) |
|
NOT NULL |
|
性別 |
C_Sex |
VARCHAR(5) |
|
NULL |
|
出生年月日 |
C_Birth |
DATE |
|
NULL |
|
電話 |
C_Phone |
VARCHAR(20) |
|
NULL |
※參考資料：資料庫規劃與設計步驟.ppt
※資料庫管理系統的演進趨勢：
|
|
1960年-1970年中 |
1960年-1980年中 |
1980年後 |
未來趨勢 |
|
資料模型 |
網路式／階層式 |
關聯式 |
物件導向式 |
合併資料模型-物件關聯式 |
|
資料庫硬體 |
大型主機 |
大型主機／迷你主機／個人電腦 |
工作站／快速個人電腦 |
平行處理／光學儲存媒體 |
|
系統架構 |
集中式 |
集中式 |
主從架構／分散式 |
異質分散／行動運算 |
|
使用介面 |
沒有／表單 |
查詢語言 |
圖形使用界面 |
自然語言／語音輸入 |
|
程式介面 |
程序式 |
內嵌查詢語言 |
第四代程式語言 |
整合資料庫和程式語言 |
※參考資料：陳玄玲-資料庫系統原理第六版 1-21~1-23
104年鐵路特考高員三級資料庫應用
|
四、為保護個人隱私，一些有機密考量的資料庫系統只允許彙總性資料的查詢，且每一筆彙總資料是由至少5筆原始資料所產生。 (一)請說明為何要這樣設計。（5分） (二)這樣的方式是否還是有可能洩密？請舉例說明。（10分） |
答：
(一)
1.彙總資料是很有用的方法，可將不同來源的資料彙總結合成一份樞紐分析表報表。如果每個地區辦公室都有一份費用統計的報表，可以使用資料彙總將這些費用統計整合成一份公司費用的樞紐分析表報表，這份報表可以包含銷售合計及平均、目前的庫存量，以及整個企業中銷售量最高的產品。
2.只允許使用 COUNT、SUM、MAX、MIN、AVG、標準差等聚合函數的統計資料查詢 (Statistical Query)，並且以設定門檻值方式 (如值組個數過低，則拒絕執行 [資料少容易推論]) 來降低從統計摘要 (執行結果) 推論出個人資料的可能性。
※參考資料：樞紐分析表的應用.pdf
(二)
設定門檻值方式，只能降低洩密機率，無法完全避免洩密，舉例如下：
1.已知：
Employee(eNo, Name, Sex, Bdate, Address, Salary)，其中有一員工名為小莉，Sex=‘女’、Bdate=‘1988-8-8’。
2.假設使用下列查詢，結果為5，表示有5個員工 (包括小莉) 是 Sex=‘女’、Bdate=‘1988-8-8’。
SELECT COUNT(*)
FROM Employee
WHERE Sex=‘女’ AND Bdate=‘1988-8-8’;
3.再使用相同條件來查詢 Salary 的 MIN 及 MAX 值，結果皆為24,000，則表示5個員工 (包括小莉) 有相同的 Salary，亦可推論出包括小莉的 Salary 為24000。
SELECT MIN(Salary)
FROM Employee
WHERE Sex=‘女’ AND Bdate=‘1988-8-8’;
SELECT MAX(Salary)
FROM Employee
WHERE Sex=‘女’ AND Bdate=‘1988-8-8’;
※參考資料：
http://www.public.tw/prog/dannyer/exam_papers130130/Uploads/104%E9%90%B5%E8%B7%AF%E9%AB%98%E5%93%A1-%E8%B3%87%E6%96%99%E5%BA%AB%E6%87%89%E7%94%A8.pdf
1-3 資料庫系統架構
一、資料庫三層架構(ANSI/SPARC)
[ANSI/SPARC] 11 | 88,90,93,95,96,97,98,99,103,105,106
88高三、90地三、93關三、95地三、96專三、97高三、98關三、99關三、103高三、105鐵高、106警三
(一)外部層次(External Level)：外部綱要(External Schema)或使用者邏輯層次 (User Logical Level)
1.包括了許多外部綱要 (external schema) 或使用者視界 (user view)。每個外部綱要負責描述某個使用者群組所需要的部分資料庫，而將資料庫的其他部份隱藏起來。可以使用 SQL 語法設計視界。
2.個別使用者的觀點，資料於不同使用者有不同的呈現，即使用者的景觀(View)，為最接近使用者的層次。
4.使用者可為應用程式或終端使用者 (如程式設計師)。
5.使用外部性資料定義語言 (External DDL)。
6.舉例：(C++)
struct emp {
char Eno[6];
int sal:
}
(二)概念層次(Conceptual Level)、概念綱要(Conceptual Schema)、或邏輯層次(Logical Level)
1.整個資料庫的所有結構，介於外部層與內部層之間，有個概念綱要 (conceptual schema)，主要描述資料庫的實體、資料型態、關係、使用者操作限制，而隱藏實際儲存結構的細節。概念綱要最常使用個體關係模型 (ER Model)。
2.將所有資料以真實的面目呈現，例如表格或稱基礎表格 (Base Table)。
3.使用概念資料定義語言 (Conceptual DDL)。
4.舉例：
Employee
Enumber Char(6)
FirstName Char(8)
LastName Char(8)
Department Char(4)
Salary Numeric(5)
(三)內部層次(Internal Level)、內部綱要(Internal Schema)或實體層次(Physical Level)
1.有個內部綱要 (internal schema)，用來描述資料庫實際的儲存結構。內部綱要是使用實體資料模型，並且描述有關資料庫裡的資料儲存與存取路徑的完整資訊。實體資料模型可以使用 SQL 語法設計。
2.是真正的硬體結構，例如磁柱、磁區、磁柱。
3.有關資料實際儲存方法，為最接近實體儲存媒體的層次，描述有關資料庫的資料儲存與存取路徑的完整細節。
4.紀錄資料的儲存格式、存在哪些索引、儲存的欄位如何呈現、儲存紀錄的實體順序、檔案資料的存取方式 (如循序檔、雜湊檔、索引檔)。
5.使用內部資料定義語言 (Internal DDL)。
6.舉例：
Stored_Employee Length = 36
Prefix Type = byte(6), Offset = 0
Enumber Type = byte(6), Offset = 6, index = Empx
Fname Type = byte(8), Offset = 12
Lname Type = byte(8), Offset = 20
Department Type = byte(4), Offset = 28
Salary Type = fullword, Offset = 32
※參考資料：
1.陳玄玲-資料庫系統原理第六版 2-6
2.http://auneths.blogspot.tw/2013/08/three-schema-architecture.html
留言列表
國考資訊處理解答 (7)
