第一章 資料庫概論
一、檔案系統
[檔案處理系統] 1 | 92
92地三
(一)檔案系統的優點
是一種儲存和組織電腦檔案和資料的方法,它使得對其存取和尋找變得容易。檔案系統通常使用硬碟和光碟這樣的儲存裝置,並維護檔案在裝置中的實體位置。
(二)檔案系統的缺點
1.資料重複存放(Data Redundancy):
不同程式或部門皆擁有及維護自己的資料。
2.資料不一致(inconsistency):資料內容無同步更新,欄位或名稱的不一致等。
3.資料間無法分享共用:只有此檔案相對的應用程式可以使用。
4.不易建立資料標準:各部門、各應用程式可能自行建立自己的檔案標準。
5.資料與程式間高度相依:應用程式是針對特定檔案組成而撰寫的。
6.系統維護成本高:檔案結構改變,應用程式必須重寫。
7.程式撰寫無效率:針對不同的檔案結構,撰寫不同的應用程式。
89年關務人員特考資料處理
傳統檔案處理方法與資料庫管理檔案方法各有哪些優點及缺點?(20分) |
答:
1.需要大量分散各地單位的遠端資料分享共用。
2.屬於高度機密性資料、個人隱私範圍需要安全控管。
3.需要建立資料存放的共同標準,因為存取使用者多,重視資料品質。
4.資料重要性高需要規劃備份回復機制。
套用(二)資料庫的優點來寫。
二、資料庫系統
[資料庫系統] 12 | 87,89,90,93,94,96,97,101(3),102,105
87高三、89地三、90地三、93電員晉高、94-2地三、96技高、97高三、101關三、101國三(2)、102調四、105警三
(一)資料庫(Database)
1.定義:
資料庫是資料表 (table) 的集合體,一個資料庫可能有一個或多個資料表;資料表是由許多相同格式的資料記錄 (record) 所組成;在資料記錄中的每一個屬性稱為欄位 (field)。換言之,橫向的資料記錄和縱向的屬性欄位組織成一個資料表,儲存到電腦儲存設備後,就成了資料庫檔案。將相關資料以系統化且有效率地儲存在一起,減少資料的重複性;可以被特定組織的應用程式系統所使用,透過資料庫管理系統來管理。常見的資料庫有通訊資料庫、學籍資料庫、成績資料庫等,在資料庫中可以只有一個資料表,也可以把數十甚至數百個資料表集合起來。用來建立資料庫系統的軟體種類很多,例如 Access、FoxPro、Informix、Oracle、Sybase、DB2 等。
※參考資料:http://epaper.gotop.com.tw/pdf/ACI009700.pdf
2.資料庫技術主要特性:
(1)資料庫系統具有自我描述 (self-describing) 的本質。
(2)隔離程式與資料與資料抽象化 (data abstraction)。
(3)支援資料的多重景觀 (multiple views)。
(4)資料共享 (sharing) 與多使用者的異動處理 (transaction procesing)。
※參考資料:陳玄玲-資料庫系統原理第六版 1-8
(二)資料庫管理系統(DataBase Management System, DBMS)
1.定義:
是一種操縱和管理資料庫的大型軟體,用於建立、使用和維護資料庫。對資料庫進行統一的管理和控制,以保證資料庫的安全性和完整性。使用者通過 DBMS 訪問資料庫中的資料,資料庫管理員也通過 DBMS 進行資料庫的維護工作。提供多種功能,可使多個應用程式和用戶用不同的方法在同時或不同時間去建立、修改和查詢資料庫。
2.主要組成:資料 (data)、硬體、軟體、使用者。
3.基本功能:資料庫的定義、建構、處理。
※參考資料:
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所應具備的功能
1.重複性(redundancy)的控制:
達成「資料的一致性」及「節省儲存空間」。例如設定「主鍵」來控制 (資料表的主鍵不可重複)。
2.實施完整性限制(integrity constraints):
讓關聯表中的資料在經過新增、修改及刪除之後,不會將錯誤或不合法的資料值存入「資料庫」中。完整性限制有個體整合性限制、參考整合性限制、特定資料整合性限制。例如身份證字號及員工代號不可為空、不可重複。
3.提供備份(backup)與回復(recovery):
提供硬體或軟體故障中回復的功能,回復子系統要確保資料庫回復到程式開始執行前的狀態,或確保程式能從之前中斷處繼續執行。備份策略如每天只備份差異 (有異動) 部份、每週週末執行一次完整備份。
4.限制未授權的存取:提供安全性與認證機制。
5.表示資料間的複雜關係:利用資料庫關聯的外鍵 (foreign key)。
6.提供多重使用者介面:針對不同程度的使用者,提供不同的使用者介面。
7.使用演繹規則的資料庫推論:
從已儲存的資料庫中推論出新的資訊。例如從 Birthday 推算出 Age、資料庫行銷 (Database Marketing) 常透過統計及資料挖掘 (Data Mining) 技術。
8.程式物件與資料結構的永久儲存:複雜的程式物件或資料結構永久儲存。
(四)資料庫系統的自我描述性
不僅僅包含資料庫本身,同時包含了對於資料庫的定義及描述,這些非資料內容本身的資訊儲存於系統目錄 (system catalog) 中,稱為中繼資料 (meta-data)。例如資料庫儲存結構、資料項的儲存格式、資料間的關係及限制。
(五)資料庫的優點
1.避免資料重複存放(Data Redundancy):
整合重複的資料增加效率。資料重複原因是備份。
2.實施完整性限制(integrity constraints):
讓關聯表中的資料在經過新增、修改及刪除之後,不會將錯誤或不合法的資料值存入「資料庫」中。完整性限制有個體整合性限制、參考整合性限制、特定資料整合性限制。例如身份證字號及員工代號不可為空、不可重複。
3.提供備份與回復功能:必須提供從硬體或軟體故障中回復 (recover) 的能力。
4.限制未授權的存取:
大多數使用者不會被授權可存取資料庫中的全部資訊,例如財務方面的資料通常只有經過授權的人員方可存取。
5.表示資料之間的複雜關係:
一個資料庫可能包含許多種類的資料,彼此間以很多的方式相互關聯。
6.提供多種使用者介面:
因為有很多類型的使用者使用資料庫,他們的技術知識水準不一,所以應該提供多樣化的使用者介面,包括給偶爾使用的使用者所用的查詢語言、應用程式設計人員所用的程式語言介面、固定模式的使用者所用的表單和指令代碼,以及單機使用者所用的功能表介面和自然語言介面等。
7.使用演繹規則的資料庫推論:
從已儲存的資料庫中推論出新的資訊。例如從 Birthday 推算出 Age、資料庫行銷 (Database Marketing) 常透過統計及資料挖掘 (Data Mining) 技術。
8.程式物件與資料結構的永久儲存:
提供複雜的程式物件或資料結構永久儲存。這是物件導向資料庫系統(object-oriented database system) 的主要優點之一。
9.避免資料不一致(inconsistency):
任何更新的動作會自動地更新。
10.資料間的分享共用:不同應用程式共享資料庫的同一份資料。
11.提供有效處理查詢的儲存結構和搜尋技術:
資料庫通常是儲存在磁碟中,為了能找到想要的記錄,DBMS 必須提供特定的資料結構以加速磁碟搜尋,而索引 (index) 的使用就是為了這個目的。
12.資料獨立性(Data Independence):
邏輯資料獨立 (Logical Data Independence) 與實體資料獨立 (Physical Data Independence)。實體儲存方式改變或資料庫結構改變不需改變上層應用。
※參考資料:陳玄玲-資料庫系統原理第六版 1-15~1-20
※使用資料庫技術所帶來的間接好處:
1.容易建立資料標準:集中控制。
2.減少應用程式開發時間:資料庫的資料集中化及存取介面標準化。
3.彈性:資料的新增、刪除、修改、擴充皆十分容易。
4.可提供最新資訊給使用者:資料庫可即時反應最新狀況。
5.經濟效益:讓資料與應用程式統一,減少不必要的開銷與時間。
※參考資料:陳玄玲-資料庫系統原理第六版 1-20~1-21
(六)資料庫的缺點:成複限速集儲 / 成父限速後急儲蓄
1.初期成本高 (如軟體、硬體、教育訓練費用)。
2.設計較複雜,資料需要正規化。
3.過多的限制:
整合性限制 (Integrity)、安全性控制 (Security)、並行控制 (Concurrency)、回復 (Recovery) 等,必須多耗費許多資源來以確保這些限制。
4.資料存取的速度較慢。
5.資料集中,容易一起被破壞或盜取。
6.佔用較大的儲存空間。
(七)何時不必採用資料庫
1.資料與應用程式皆很簡單,不常變化。
2.未來擴充可能性非常小。
3.不需多使用者同時存取。
4.某些應用程式有非常嚴格的即時需求。
※資料庫的生命週期:
被稱為微觀生命週期(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 Design Methodology):
[資料庫設計] 9 | 91(2),94(2),96(2),97,101,104(2)
91地三(2)、94高二、94-1地三、96公關薦(2)、97調三、101專三、104關三、104鐵高
是使用特定程序、技術和工具的結構化設計方法,一種結構化的資料庫設計方法。簡單的說,這是一種計劃性、按部就班來進行資料庫設計。對於小型資料庫系統來說,就算沒有使用任何資料庫設計方法論,資料庫設計者一樣可以依據經驗來建立所需的資料庫。但是,對於大型資料庫設計的專案計劃來說,資料庫設計方法論就十分重要。完整資料庫設計共分成概念、邏輯和實體資料庫設計三個階段,如下圖所示:
上述圖例顯示當從真實世界進行需求收集和分析後,就可以撰寫資料庫需求書,通常是使用文字來描述系統需求。接著進行三個階段的資料庫設計來建立所需的資料模型。在這三個階段主要是建立概念、邏輯和實體資料模型。三個階段的資料庫設計如下所示:
1.概念資料庫設計(Conceptual Database Design):
將資料庫需求轉換成概念資料模型的過程,並沒有針對特定資料庫管理系統或資料庫模型。簡單的說,概念資料模型是一種使用者了解的模型,用來描述真實世界的資料如何在資料庫中呈現。實體關聯圖是目前最廣泛使用的概念資料模型。
2.邏輯資料庫設計(Logical Database Design):
將概念資料模型轉換成邏輯資料模型的過程,邏輯資料庫設計是針對特定的資料庫模型來建立邏輯資料模型,例如關聯式資料庫模型。簡單的說,邏輯資料模型是一種資料庫管理系統了解的資料模型,擁有完整資料庫綱要,可以使用外來鍵參考圖建立邏輯資料模型。事實上,實體關聯圖不只可以建立概念資料模型,也可以用來建立邏輯資料模型,其最大差異在於邏輯資料模型是一個已經正規化的實體關聯圖。邏輯資料庫設計的主要工作有兩項,第一是將實體關聯圖轉換成關聯表綱要、第二是關聯表的正規化。
3.實體資料庫設計(Physical Database Design):
將邏輯資料模型轉換成實體資料模型的過程,例如將邏輯資料模型轉換成關聯式資料庫管理系統的 SQL 指令敘述,以便建立資料庫。實體資料模型可以描述資料庫的關聯表、檔案組織、索引設計和額外的完整性限制條件。
※參考資料:chapter5 資料庫設計工具的使用.pdf
※概念設計(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
※資料庫應用程式發展生命週期各階段的說明:
階段 |
工作 |
輸出 |
資料庫規劃 (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) |
監控和維護,機動更新以符合新的規則和需求 |
操作說明 維護紀錄 |
※參考資料:許薰任-醫療管理系統實作.pdf p.32
※資料庫管理系統的演進趨勢:
|
1960年-1970年中 |
1960年-1980年中 |
1980年後 |
未來趨勢 |
資料模型 |
網路式/階層式 |
關聯式 |
物件導向式 |
合併資料模型-物件關聯式 |
資料庫硬體 |
大型主機 |
大型主機/迷你主機/個人電腦 |
工作站/快速個人電腦 |
平行處理/光學儲存媒體 |
系統架構 |
集中式 |
集中式 |
主從架構/分散式 |
異質分散/行動運算 |
使用介面 |
沒有/表單 |
查詢語言 |
圖形使用界面 |
自然語言/語音輸入 |
程式介面 |
程序式 |
內嵌查詢語言 |
第四代程式語言 |
整合資料庫和程式語言 |
※參考資料:陳玄玲-資料庫系統原理第六版 1-21~1-23
104年鐵路特考高員三級資料庫應用
四、為保護個人隱私,一些有機密考量的資料庫系統只允許彙總性資料的查詢,且每一筆彙總資料是由至少5筆原始資料所產生。 (一)請說明為何要這樣設計。(5分) (二)這樣的方式是否還是有可能洩密?請舉例說明。(10分) |
答:
(一)
彙總資料是很有用的方法,可將不同來源的資料彙總結合成一份樞紐分析表報表。如果每個地區辦公室都有一份費用統計的報表,可以使用資料彙總將這些費用統計整合成一份公司費用的樞紐分析表報表,這份報表可以包含銷售合計及平均、目前的庫存量,以及整個企業中銷售量最高的產品。只允許使用COUNT、SUM、MAX、MIN、AVG、標準差等聚合函數的統計資料查詢 (Statistical Query),並且以設定門檻值方式 (如值組個數過低,則拒絕執行 [資料少容易推論]) 來降低從統計摘要 (執行結果) 推論出個人資料的可能性。
※參考資料:樞紐分析表的應用.pdf
(二)
設定門檻值方式,只能降低洩密機率,無法完全避免洩密,舉例如下:
1.已知:
Employee(eNo, Name, Sex, Bdate, Address, Salary),其中有一員工名為小莉,Sex=‘女’、Bdate=‘1988-8-8’。
2.使用下列查詢,結果為3,表示有3個員工 (包括小莉) Sex=‘女’、Bdate=‘1988-8-8’。
SELECT COUNT(*)
FROM Employee
WHERE Sex=‘女’ AND Bdate=‘1988-8-8’;
3.再使用相同條件來查詢 Salary 的 MIN 及 MAX 值,結果皆為24000,則表示3個員工 (包括小莉) 有相同的 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
三、資料庫系統架構
(一)資料庫三層架構(ANSI/SPARC)
[ANSI/SPARC] 10 | 88,90,93,95,96,97,98,99,103,105
88高三、90地三、93關三、95地三、96專三、97高三、98關三、99關三、103高三、105鐵高
1.外部層次(External Level):外部綱目(External Schema)或使用者邏輯層次 (User Logical Level)
(1)包括了許多外部綱要 (external schema) 或使用者視界 (user view)。每個外部綱要負責描述某個使用者群組所需要的部分資料庫,而將資料庫的其他部份隱藏起來。可以使用 SQL 語法設計視界。
(2)個別使用者的觀點,資料於不同使用者有不同的呈現,即使用者的景觀(View),為最接近使用者的層次。
(3)隱藏不需要的欄位,對個別使用者只顯示其感興趣、或有權限讀取的部分。
(4)使用者可為應用程式或終端使用者 (如程式設計師)。
(5)使用外部性資料定義語言 (External DDL)。
(6)舉例:(C++)
struct emp {
char Eno[6];
int sal:
}
2.概念層次(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)
3.內部層次(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
(二)資料獨立性(Data Independence)
[資料獨立(Data Independent)] 8 | 89,93(2),96,97,98,103,104
89高三、93地三、93關三、97鐵三、98關薦、96警監二、103高三、104地三
1.定義:
當下一層的綱目被修改時,不會影響到上一層的綱目。例如當 DBA 修改內部綱目,新建另一個索引來提高效率時,並不會影響到概念綱目。同樣的,在概念綱目裡新增一個屬性 (如加上商品種類),也不會影響到現有的外部綱目。
2.種類:
(1)邏輯資料獨立(Logical Data Independence):
97鐵三
改變概念層次時,不必改變外部層次或應用程式。例如在資料庫中新增或移除一個表格、欄位或資料項目,外部層次 (如參考外部綱要結構的應用程式) 不需作任何更動。
(2)實體資料獨立(Physical Data Independence):
89高三、98關薦
改變內部層次,不必改變概念層次或外部層次。內部綱要的修改有時是資料庫系統原理必要的,因為要重組某些實體檔案 (如建立額外的存取結構來改善擷取或更新的效能)。假如之前的資料還留在資料庫,就不需要去更改概念綱要。例如因應資料量的增加,將循序檔更改為索引檔時,概念層次與外部層次不必變動。
※參考資料:陳玄玲-資料庫系統原理第六版 2-7~2-8
3.資料獨立的優點:
不管是那一種層次的定義,假如沒有資料獨立,則任一層次的定義改變會引起其他層次定義的改變,會造成資料庫系統維護上的困難。實際上各層之間的定義是有關聯的,資料獨立要把要把這些關聯對於各層定義之間的更動影響層面降低。
※參考資料:正修科技大學-Database自我評量與參考解答.doc
※資料庫綱要(Database schema)與案例(instances):
[Metadata] 2 | 85,101
85地三、101高三
[綱要(Schema)] 3 | 90,96,97
90高三、96公關薦、97警鑑二
1.資料庫綱要(Database schema):中繼資料(meta data)
描述資料庫架構 (外部綱要、概念綱要、內部綱要)、資料關聯性 (主鍵、外鍵、一對一、一對多、多對多)、資料的定義 (資料型態) 等。資料大部分不常變動。
2.案例(instances):資料庫在某時刻,所真正儲存的資料。資料較常變動。
※參考資料:陳會安、陳祥輝-資料庫系統理論與設計實務 2-14
※三層資料庫綱要:
1.外部綱要(External Schema):
描述使用的資料。源於概念綱要,主要是描述外部層顯示的資料,每一個外部層綱要只描述資料庫的部分資料,隱藏其他部分的資料。每一個外部層使用者觀點的資料都需要一個外部綱要,在一個資料庫可能擁有多個外部綱要,如下圖所示:
Student_Age_View:
S_No |
Name |
Age |
Student_Address_View:
No |
Name |
Address |
2.概念綱要(Conceptual Schema):
描述資料本身的意義。描述概念層的完整資料庫,這是「概念資料庫設計」的結果,其主要是分析使用者資訊,以便定義所需的資料項目,並不涉及到底是使用那一套資料庫管理系統。概念綱要描述完整資料庫的資料和其關聯,所以資料庫只能擁有一個概念綱要,如下圖所示:
Students:
No |
Name |
Address |
Telphone |
Birthday |
3.內部綱要(Internal Schema):
描述儲存的資料。描述內部層實際觀點的資料,定義資料的儲存結構和那些資料需要建立索引,資料庫只擁有一個內部綱要。例如 C 語言宣告學生 Students 的結構,如下:
struct Students {
char no[5];
char name[15];
char address[40];
int telephone;
struct Date birthday;
struct Student *next;
};
※參考資料:陳會安、陳祥輝-資料庫系統理論與設計實務 2-15~2-18
※儲存定義語言(Storage Definition Language, SDL):
定義內部綱要。在內部綱要主要考量:
1.配置資料和索引資料的儲存空間。
2.選擇 B 樹或雜湊函數建立索引資料。
3.描述資料階層中的記錄格式,以及如何組合記錄儲存成檔案。
4.資料壓縮 (Data Compression) 和資料加密 (Data Encryption) 技術,以減少佔用的磁碟空間和保護儲存的資料。
※參考資料:陳會安、陳祥輝-資料庫系統理論與設計實務 2-18
※資料庫綱要間的對映:
1.說明:
三層資料庫綱要只是描述資料,真正的資料是儲存在外部儲存裝置的資料庫。當以外部層使用者觀點顯示資料時,也就是參考外部綱要向概念綱要請求資料,然後概念綱要請求內部綱要從資料庫取得資料,在取得真正的資料後,資料需要進行轉換來符合概念綱要的定義,然後再轉換成符合外部綱要的定義,最後才是外部層使用者觀點看到的資料,在各層間進行的資料轉換過程,稱為對映 (Mapping)。
2.各層綱要間的對映:
(1)外部與概念對映(External/Conceptual Mapping):
所有外部綱要都是對映到概念綱要,以便資料庫管理系統知道如何將外部層的資料連結到那一部分的概念綱要。
(2)概念與內部對映(Conceptual/Internal Mapping):
概念綱要對映到內部綱要的關聯,以便資料庫管理系統可以找到實際儲存裝置的記錄資料後,建立概念綱要的邏輯結構。
※參考資料:陳會安、陳祥輝-資料庫系統理論與設計實務 2-18~2-19
93年交通事業電信人員升資考資料庫管理系統概要
三、開發資料庫時,常須作概念性綱要 (conceptual schema)、外部綱要及實體綱要,試說明以此綱要架構開發資料庫的詳細流程。(10分) |
答:
略
※資料庫管理師(DataBase Administrator, DBA)
[資料庫管理員(DBA)] 5 | 88,89,93,97,101
88高三、89高三、93地三、97鐵高、101關三
[DBMS user] 1 | 102
102高三
1.資料管理師(Data Administrator, DA):
主要工作乃為公司的資料作出策略與政策性的決策,例如公司需要哪些資料,有哪些儲存與維護的政策等。
2.資料庫管理師(Database Administrator, DBA):
經由 DA 制定的策略或政策,交由 DBA 處理。負責在系統上運行資料庫,執行備份,執行安全策略和保持資料庫的完整性。因為管理資料庫是個很龐大的職務,每個公司或組織的資料庫管理員的需要也是很不同。一個大公司可能有很多資料庫管理員,但是一個小公司可能也沒有資料庫管理員,而讓系統管理員管理資料庫。
3.資料庫管理師負責的工作:
(1)與使用者聯繫:定義外部層次,以及概念層與外部層的對應。
(2)定義資料庫概念層次:資料庫設計。
(3)定義內部層次:實體資料庫設計。
(4)定義安全性與整合性限制:透過概念層定義語言。
(5)錯誤管理:資料庫的備份 (backup)、復原 (recovery)。
(6)效能監測以及需求變更。
※參考資料:
http://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%AE%A1%E7%90%86%E5%91%98
※工具程式開發人員(Tool developer):
102高三
負責建構資料塑模工具、資料庫績效監控工具、測試案例產生工具。
※固定模式的終端使用者(Parametric end user):
102高三
主要工作為查詢更新資料庫、或存取資料庫以產生所需報表。通常透過應用程式達到此目的,這些標準動作稱為固定交易。
※應用程式的開發人員(Application programmer):
102高三
通常在系統分析師撰寫出需求規格後,進行應用程式開發。例如負責將需求規格撰寫為程式,並且測試、除錯、製作文件,以及維護。
※稽核追蹤:
記錄與追蹤所有與資訊安全相關的事件,並且保護這些追蹤的紀錄不會有未授權的竄改行為,方便事後查核,或是及時的提供不尋常的訊息。
四、主從式架構(Client/Server)與三層式架構(3-tier)
[資料庫架構] 7 | 84,90,91,92,93,101,105
84地三、90調三、91高三、92國三、93電員晉高、101高三、105關三
(一)主從式架構(Client/Server architecture)
1.定義:
一個主從式架構主要由客戶端 (Client)、伺服器端 (Server) 與網路 (Network) 三個部分組成。應用程式可分為展現 (Presentation)、處理 (Processing)、與資料管理 (Data Management) 等部份,再分別由客戶端或伺服器端來完成。客戶端透過網路提出要求,而伺服器端則透過網路回應此要求。使用者介面程式和應用程式可以在用戶端執行。等到需要存取 DBMS 時,程式會建立一個到伺服端 DBMS 的連結,建立好之後,用戶端程式便可以和 DBMS 溝通。例如 ODBC 提供一種能讓用戶端程式呼叫 DBMS 的應用程式介面 (API),條件是用戶端和伺服端都要同時安裝需要的軟體。
2.主從式架構(Client/Server architecture):
(1)用戶端(Client):前端(front-end)
DBMS 上所執行的應用程式,需透過一特定介面與 Server 溝通,以向 Server 端提出請求,並以適當的方式呈現出來。
(2)伺服器端(Server):亦稱為後端(back-end)
DBMS 本身。依 Client 端需求提供服務給使用者的應用程式。
3.主從式運算(Client/Server Computing)與主機式運算(Host-based Computing):
|
Client/Server |
Host-based |
特性 |
1.分散控制 2.多主機 3.鼓勵開放標準 4.多樣系統操作 5.軟體導向架構 6.混合式供應商 7.可攜性高 8.易於擴充 9.運算功能分散在 Client 及 Server 端 10.資訊中心組織 |
1.集中控制 2.單一主機 3.專屬標準 4.單一系統操作 5.硬體導向架構 6.單一供應商 7.可攜性低 8.不易擴充 9.運算功能集中在中大型主機上 10.集中型電腦中心 |
4.優點:簡單且與現有的系統相容性高。
※Client Side和 Server Side如何劃分資料庫系統相關軟體?
105關三
用戶端 (Client) 通常是個提供使用者介面和本機處理能力的使用者機器。當用戶端需要使用不在此機器裡的額外功能時 (如資料庫存取),它便連上能提供所需功能的伺服器。而伺服器 (Server) 則是能對用戶端提供服務的機器,像檔案存取、列印、封存 (archive) 或資料庫存取。一般來說,有些機器只安裝用戶端軟體,有些機器只安裝伺服端軟體,還有一些機器會同時安裝用戶端與伺服端軟體,通常是個提供使用者介面和本機處理能力的使用者機器。當用戶端需要使用不在此機器裡的額外功能時,如資料庫存取,它便連上能提供所需功能的伺服器。
※參考資料:陳玄玲-資料庫系統原理第六版 2-17
※開放資料庫互連(Open Database Connectivity, ODBC):
105關三
它是一個工業界的標準,可以看成是各家資料庫廠商所提供的一個應用程式介面 (Application Program Interface, API),可讓其他軟體或程式根據這個標準一致的程式介面,來對資料庫進行新增、讀取、修改、刪除等動作。
※參考資料:
http://mirlab.org/jang/books/asp/odbc&dsn.asp?title=18-1%20ODBC%20%BBP%20DSN%20%C2%B2%A4%B6
※ODBC如何在Client Side和Server Side之間運作?
105關三
使用者介面程式和應用程式可以在用戶端執行。等到需要存取 DBMS 時,程式會建立一個到伺服端DBMS 的連結,建立好之後用戶端程式便可以和 DBMS 溝通。例如有個名稱為 ODBC (Open Database Connectivity) 的標準,它提供一種能讓用戶端程式呼叫 DBMS 的應用程式介面 (Application Programming Interface, API),條件是用戶端和伺服端都要同時安裝需要的軟體。大多數 DBMS 廠商在系統內有提供 ODBC 驅動程式。因此,用戶端程式可以直接連接到數個伺服端的 RDBMS,並且使用 ODBC API 傳送查詢和異動請求,然後在伺服端進行處理。任何查詢結果將會傳送回用戶端程式,可以視需要處理及顯示此結果。而 Java 程式設計語言也已經定義出另一個相關標準,稱為 JDBC,此標準允許 Java 用戶端程式透過標準介面存取一或多個 DBMS。
※參考資料:陳玄玲-資料庫系統原理第六版 2-18~2-19
(二)三層式架構(3-tier architecture)
1.定義:
將應用程式代理者 (Application agent) 置於 Client 與 Server 中間,存放商業邏輯 (Business logic),以處理 Client 與 Server 間往來的業務。可整合後端不同的 Server,以統一的方式呈現內部的資料。
2.架構:
(1)展示層:用戶端(Client)
負責使用者介面的呈現。
(2)商業邏輯層:應用程式伺服器(Application Server)
負責企業邏輯的規劃及 Client-Server 間的溝通。
(3)資料庫服務層:伺服器端(Database Server)
負責資料庫資料的存取。
※參考資料:陳玄玲-資料庫系統原理第六版 2-6
(三)多層式架構(N-Tier architecture, Multi-Tier architecture)
1.定義:
在使用者與儲存資料間可以進一步分割成幾個更細的元件,其中的 n 可能是4或5。一般而言,商業邏輯層還會分割成好幾層。
2.優點:
(1)可將程式設計與資料分散在整個網路上。
(2)每一層可以分別在合適的作業系統平台上執行,而且可以被獨立處理。
※主從式架構(Client/Server architecture)與三層式架構(3-tier architecture)的比較:
|
優點 |
缺點 |
Client/Server |
可藉由client 本身的運算能力分擔server 處理資料的負荷(較terminal 佳) |
1.針對不同的 server 系統,需設計不同的 client 端介面 2.client 越多,connection 越多,server 的負擔也越重 |
3–tier architecture |
可用中間的應用程式伺服器整合後端不同server,client 只需面對單一的 agent 介面 |
規模不斷擴大後,中間端將成為此架構的瓶頸 |
※集中式架構(Centralized Architecture):
92高二
1.定義:
以集中式的大型主機 (mainframe) 來儲存一個資訊系統所有的資料、程式和介面元件供多人使用。使用者透過終端機 (或以 PC 來模擬終端機) 與系統互動。所有真正的處理和工作都在主機上完成。
2.優點:
(1)系統管理單純,因為所有的資源均由主機作業系統分配與管理。
(2)屬於封閉式作業系統,這種作業系統再與其他系統的連接上雖然有極大的問題,但是在資料安全上卻比較容易控制。
3.缺點:
(1)主機工作負擔較重。
(2)主機更替成本高。
(3)維護成本重。
(4)只能處理文字模式的介面,無法支援圖形使用者介面 (GUI)。
(5)缺乏彈性的環境。
※Intranet架構:
92高二
1.定義:將網際網路的技術應用在企業內部網路。
2.優點:
(1)整合異質性資料庫:
Intranet 系統大都採用開放性架構故較容易整合新舊系統資源,提供更有彈性的資訊基礎架構。
(2)可結合企業內部與外部的資訊溝通:
Intranet 是採用 Web 方式,除內部訊息公告外,尚可與網際網路資源進行溝通。
(3)提供多媒體應用系統:
Intranet 因採用 HTML,故可採用多媒體方式,有聲、光、影像的溝通。
(4)技術自主性高,系統開發及維護較為容易。
(5)資訊即時性加強服務績效,提昇整體形象。
(6)節省文字印刷需求,達到無紙化的境界。
※參考資料:http://www.lib.ntnu.edu.tw/jory/j35/j1/j102.htm
3.缺點:
由於使用者透過網路來與 Web 網站連絡,衍生出一些其他的問題,像網路的資料速率、成本與效能等,在開發工具方面,目前雖然進展得很快,但是還是需要一段時間才會比較成熟而穩定。缺點如下:
(1)專業技術的學習曲線過長。
(2)網路的品質影響系統穩定性。
(3)如何確保系統隨時正常運作?
(4)在有限的頻寬如何達到最佳的系統執行效率?
※參考資料:
1.http://epaper.gotop.com.tw/pdf/AED002100.pdf
2.http://nccur.lib.nccu.edu.tw/bitstream/140.119/35192/5/35603805.pdf
90年中央資管所計算機概論
為何 Web site 所用的後端 SQL server 的 license 人數不需要買很多?(2分) |
答:
Microsoft SQL Server授權方式有3種:
1.按照 CPU 數量。
2.按照裝置數量。
3.按照使用者人數。
※參考資料:http://blog.tenyi.com/2006/11/sql-server.html
92年高考二級資料庫設計
四、假設你現在是行政院某部會的管理資訊部門主管,想開發一套管理資訊系統將行政業務全面電腦化,現在有以下三種方案讓你評估: (一)採用主從式架構 (Client-Server Architecture),圖形介面, (二)採用集中式架構 (Centralized Architecture),圖形介面, (三)採用 Intranet 架構,可以與 Internet 結合。 依成本、效益與使用者的觀點,以及其他相關因素來評估其中的優、缺點。(30分) |
答:
無
五、分散式資料庫(Distributed Database)
[分散式資料庫管理系統] 9 | 87,90,93,100(2),101(2),102,103
87高三、90調三、93關三、100關三、100地三、101專三、101地三、102調三(國三)、103關三
(一)定義
在邏輯上是一個系統,但實體上資料卻分散在網路的多個地方,透過分散式資料庫管理系統 (Distributed DataBase Management System, DDBMS) 來從事資料的管理與控制。而集中式資料庫 (Centralized database) 將所有系統組件存在單一電腦或網站中。
(二)分散式資料庫的幾種透通性
1.存取透通性(Access transparency):可使用不同操作方法操作 DB。
2.位置透通性(Location transparency):不需知道物件實體位置。
3.網路透通性(Network transparency):不需知道分散各點使用的不同網路協定。
4.同步透通性(Concurrency transparency):
多個程序 (process) 並行,不會互相干擾。
5.重複透通性(Replication transparency):
使用備份,但使用者不需知道備份的存在。
6.錯誤透通性(Failure transparency):
隔離系統錯誤,其他各點可在不知道錯誤的情況下繼續運作。
7.移動透通性(Mobility transparency):物件系統中移動,使用者不需任何調整。
8.分割透通性(Fragmentation transparency):
不需要知道物件如何分割,可容易存取完整資料。
註:透通性 = 不知道
(三)資料分割(Data fragmentation)
1.水平分割(Horizontal fragmentation):
100地三
將一個資料表分割成多個資料表。每個資料表都包含相同數目的資料行。例如某個公司銷售記錄數據量太大了,可以按月進行水平分割,每個月的銷售記錄單獨成一張表。分割後可以降低在查詢時需要讀的資料和索引的頁數,同時也降低了索引的層數,提高查詢速度。
2.垂直分割(Vertical fragmentation):
將資料表分割成包含較少資料行的多個資料表。有正規化與資料列分割兩種。例如內含七個資料行的資料表中,只保留前四個資料行。查詢時必須聯結資料表,如果資料分割非常大,將會影響效能。
3.混合式分割(Mixed fragmentation):結合水平分割及垂直分割。
留言列表