第1章 資料庫系統 1-1 資料庫系統的基礎 1-2 三層資料庫系統架構 1-3 資料庫綱要 1-4 資料庫管理系統 1-5 資料庫管理師 第1章 資料庫系統 1-1 資料庫系統的基礎 1-2 三層資料庫系統架構 1-3 資料庫綱要 1-4 資料庫管理系統 1-5 資料庫管理師 1-6 資料庫系統的處理架構
1-1 資料庫系統的基礎 1-1-1 資料庫的定義 1-1-2 資料塑模 1-1-3 資料庫環境的組成元件
1-1 資料庫系統的基礎 「資料庫系統」(Database System)是由「資料庫」(Database)和「資料庫管理系統」(Database Management System;DBMS)所組成,如下圖所示:
1-1-1 資料庫的定義-說明 資料庫(Database)是一個概念;一種資料儲存單位;一些經過組織的資料集合。事實上,有很多現成或一些常常使用的資料集合,都可稱為資料庫,如下所示: 在Word文件中編輯的通訊錄資料。 使用Excel管理的學生成績資料。 在應用程式提供相關功能來維護和分析儲存在大型檔案的資料。 銀行的帳戶資料和交易資料。 醫院的病人資料。 大學的學生、課程、選課和教授資料。 電信公司的帳單資料。
1-1-1 資料庫的定義-通用定義 資料庫正式的定義有很多種,比較通用的定義為:「資料庫(Database)是一個儲存資料的電子文件檔案櫃(An Electronic Filing Cabinet)。」 在資料庫的這個電子文件檔案櫃是一個儲存結構化(Structured)、整合的(Integrated)、相關聯(Interrelated)、共享(Shared)和可控制(Controlled)資料的檔案櫃。
1-1-1 資料庫的定義-長存資料的集合 以現代的企業或組織來說,資料庫是讓企業或組織能夠正常運作的重要元件,想想看!如果銀行沒有帳戶和交易記錄的資料庫,客戶存款和提款需要如何運作。航空公司需要依賴訂票系統的資料庫,才能讓各旅行社訂機票,旅客才知道班機是否已經客滿。 在這些企業或組織的資料庫,其儲存的大量資料並非是一種短暫儲存的暫時資料,而是一種長時間存在的資料,稱為「長存資料」(Persistent Data)。
1-1-2 資料塑模-圖例 資料庫儲存是結構化收集的「實體」(Entity)資料,實體是現實生活中存在的東西,我們可以將它塑模(Modeling)成資料庫儲存的結構化資料,如下圖所示:
1-1-2 資料塑模-基礎 「資料塑模」(Data Modeling)是將真實東西轉換成模型,這是一種分析客戶需求的技術。其目的是建立客戶所需資訊和商業處理的正確模型,將需求使用圖形方式來表示,其塑模過程如下圖所示:
1-1-2 資料塑模-邏輯關聯資料(說明) 資料庫是將真實東西轉換成模型定義的資料結構。 例如:塑模一間大學或技術學院,也就是從大學或技術學院儲存的資料中識別出: 實體。 屬性。 關聯性。
1-1-2 資料塑模-邏輯關聯資料(實體) 實體(Entities):在真實世界識別出的東西。例如:從大學和技術學院可以識別出學生、指導老師、課程和員工等實體,如下圖所示:
1-1-2 資料塑模-邏輯關聯資料(屬性) 屬性(Attributes):即每一個實體擁有的一些特性。例如:學生擁有學號、姓名、地址和電話等屬性,如下圖所示:
1-1-2 資料塑模-邏輯關聯資料(關聯性1) 關聯性(Relationships):二個或多個實體間所擁有的關係,以基數比限制條件(Cardinality Ratio Constraints)來說,主要分為三種,如下所示: 一對一(1:1):指一個實體只關聯到另一個實體。例如:指導老師是一位學校員工,反過來,此員工就是指這位指導老師。 一對多(1:N):指一個實體關聯到多個實體。例如:學生寫論文時可以找一位指導老師;但一位指導老師可以同時指導多位學生來撰寫論文。 多對多(M:N):指多個實體關聯到多個其他實體。例如:一位學生可以選修多門課程,反過來,同一門課程可以讓多位學生來選修。
1-1-2 資料塑模-邏輯關聯資料(關聯性2)
1-1-3 資料庫環境的組成元件-說明 資料庫是一個儲存資料的電子檔案櫃,資料庫管理系統(Database Management System;DBMS)是一套管理資料庫的應用程式。 「資料庫系統」(Database System)是指使用一般用途資料庫管理系統所開發,具有特定用途的資料庫系統。例如:使用Access、MySQL或SQL Server開發的學校註冊、選課系統和公司的進銷存系統等。 資料庫環境擁有四大元件:使用者、資料、軟體和硬體。
1-1-3 資料庫環境的組成元件-圖例
1-1-3 資料庫環境的組成元件-使用者1 初級使用者(Naive or Parametric Users):初級使用者是實際執行應用程式的使用者。 不常使用的使用者(Casual Users):通常是公司或組織的中高階主管,因為只有偶爾使用資料庫系統,而且每次查詢的資料都不相同。 熟練使用者(Sophisticated Users):熟練使用者是一些熟悉資料庫管理系統操作的使用者,通常是工程師或專家,他們不只了解資料庫結構,還精通資料庫查詢語言。 資料庫設計師(Database Designers):精通資料庫設計的使用者,其主要工作是建立資料庫結構,判斷哪些資料需要儲存在資料庫,和使用什麼樣的結構來儲存這些資料。
1-1-3 資料庫環境的組成元件-使用者2 資料庫管理師(Database Administrator;DBA):他是資料庫系統的總管,負責管理資料庫系統。 系統分析師(System Analyst;SA):他與應用程式設計師屬於「專業使用者」(Specialized Users),系統分析師依據終端使用者的需求;主要是指初級使用者(Naive or Parametric Users)的需求,來製定資料庫應用程式的規格與功能。 應用程式設計師(Application Programmer):依據系統分析師定義的規格,建立終端使用者使用的資料庫應用程式。
1-1-3 資料庫環境的組成元件-資料 長存資料(Persistent Data):資料庫儲存的是公司或組織的非暫時資料,這些資料是長時間存在的資料,使用者可以使用應用程式的介面來新增、刪除或更新資料。 系統目錄(System Catalog):由資料庫管理系統自動產生的資料,或稱為「資料字典」(Data Dictionary),其內容是從前述長存資料所衍生的一些資料。 索引資料(Indexes):索引的目的是為了在資料庫儲存的龐大資料中,能夠更快速的找到資料。 交易記錄(Transaction Log):交易記錄是資料庫管理系統自動產生的歷史資料,可以記錄使用者在什麼時間點下達哪些指令或執行什麼操作。當發生資料庫異常操作時,交易記錄可以提供追蹤異常情況的重要線索和依據。
1-1-3 資料庫環境的組成元件-軟體 資料庫管理系統(DBMS):資料庫管理系統提供一組程式模組定義、處理和管理資料庫的資料。 應用程式(Application Program):這是程式設計師以開發工具或程式語言自行建立的專屬軟體。 開發工具(Development Tools):用來建立資料庫和開發應用程式。例如:資料庫設計工具、資料庫開發工具或程式語言的整合開發環境,它可以幫助資料庫設計師建立資料庫結構和程式設計者快速建立應用程式。例如:PowerBuilder、Oracle Developer和Visual Studio等。
1-1-3 資料庫環境的組成元件-硬體 安裝資料庫相關軟體的硬體(Hardware)設備,包含:主機(CPU、記憶體和網路卡等)、磁碟機、磁碟陣列、光碟機、磁帶機和備份裝置。整個資料庫系統的硬體處理架構依照運算方式的不同,分為:集中式或分散式的主從架構。 一般來說,資料庫系統大多是公司或組織正常運作的命脈,它需要相當大量的硬體資源來提供服務,所以,我們都會選用功能最強大的電腦作為資料庫伺服器。
1-2 三層資料庫系統架構 1-2-1 概念層 1-2-2 外部層 1-2-3 內部層
1-2 三層資料庫系統架構-圖例 ANSI/SPARC三層資料庫系統架構是由「ANSI」(American National Standards Institute)和「SPARC」(Standards Planning And Requirements Committee)所制定的資料庫系統架構,如右圖所示:
1-2 三層資料庫系統架構-說明 ANSI/SPARC是以三個階層來說明資料庫管理系統的架構,即分別以使用者、資料庫管理師(也可能是資料庫設計師)和實際儲存的觀點來檢視資料庫儲存的資料,其簡單說明如下所示: 概念層(Conceptual Level):資料庫管理師觀點的資料,這是資料庫的完整資料,屬於在概念上看到的完整資料庫。 外部層(External Level):一般使用者觀點的資料,代表不同使用者在資料庫系統所看見的資料,通常都只有部分資料庫的資料。 內部層(Internal Level):實際儲存觀點所呈現的資料,它是實際資料庫儲存在電腦儲存裝置的資料。
1-2-1 概念層 在概念層(Conceptual Level)看到的是整個資料庫儲存的資料,它是資料庫管理師觀點所看到的完整資料庫。以關聯式資料庫模型的資料庫來說,在概念層(正確的說,應該是邏輯層)所看見的是使用二維表格顯示的資料,如下圖所示:
1-2-2 外部層 對於資料庫系統的使用者來說,其面對的是外部層(External Level)的使用者觀點(User Views)資料,這些資料包含多種不同觀點。例如:一所大學或技術學院,可提供多種不同使用者觀點,如下所示: 使用者觀點1:學生註冊資料 使用者觀點2:學生選課資料 使用者觀點3:學生成績單資料 每位使用者有不同的觀點,當然,一組使用者也可能看到相同觀點的資料。如同從窗戶看戶外世界,不同大小的窗戶和角度會看到不同的景觀。
1-2-3 內部層 在內部層(Internal Level)看到的是實際儲存觀點的資料庫,它就是實際電腦儲存在磁碟等儲存裝置的資料。換句話說,內部層在三層架構中,扮演資料庫管理系統與作業系統的介面。 內部層的資料是實際儲存在資料庫的資料結構或檔案組織所呈現的資料內容。例如:使用鏈結串列結構來儲存資料,如下圖所示:
1-3 資料庫綱要 1-3-1 三層資料庫綱要 1-3-2 資料庫綱要間的對映 1-3-3 實體與邏輯資料獨立
1-3 資料庫綱要-簡介 在資料庫管理系統看到的資料是儲存在資料庫的資料,除了資料本身外,還包含描述資料的定義,稱為「綱要」(Schema)。所謂「資料庫綱要」(Database Schema)是指整個資料庫的描述,即描述整個資料庫儲存資料的定義資料,如下圖所示:
1-3 資料庫綱要-說明 綱要(Schema):資料描述的定義資料,對比程式語言的變數就是資料型別(Data Type,或稱資料類型)。例如:C語言宣告成整數的age年齡變數,如下所示: int age; 資料(Data):資料本身,即程式語言的變數值。例如:年齡為22,如下所示: age = 22;
1-3-1 三層資料庫綱要-圖例 在ANSI/SPARC三層資料庫系統架構的每一層,都可以分割成資料和綱要,換句話說,完整資料庫綱要也分成三層,如下圖所示:
1-3-1 三層資料庫綱要-外部綱要 外部綱要(External Schema)源於概念綱要,主要是用來描述外部層顯示的資料,每一個外部層綱要只描述資料庫的部分資料,隱藏其他部分的資料。換句話說,每一個外部層使用者觀點的資料都需要一個外部綱要,一個資料庫可能擁有多個外部綱要,如下圖所示:
1-3-1 三層資料庫綱要-概念綱要 概念綱要(Conceptual Schema)是描述概念層的完整資料庫,即「概念資料庫設計」(Conceptual Database Design)的結果。概念資料庫設計主要是分析使用者資訊,以便定義所需的資料項目,它並不涉及到使用哪一套現有的資料庫管理系統。 概念綱要描述完整資料庫的資料和其關聯性,所以資料庫只能擁有一個概念綱要,如下圖所示:
1-3-1 三層資料庫綱要-內部綱要 內部綱要(Internal Schema)描述內部層實際儲存觀點的資料,定義資料的儲存結構和哪些資料需要建立索引。 資料庫只能擁有一個內部綱要。例如:使用C語言宣告學生Students結構,如下所示: struct Students { char no[5]; char name[15]; char address[40]; int telephone; struct Date birthday; struct Student *next; };
1-3-2 資料庫綱要間的對映-說明 ANSI/SPARC三層資料庫綱要只是描述資料,真正的資料是儲存在大量儲存裝置(Mass Storage)的資料庫。 當外部層以使用者觀點顯示資料時,也就是參考外部綱要向概念綱要請求資料,然後概念綱要請求內部綱要從資料庫取得資料,在取得真正資料後,資料需要進行轉換來符合概念綱要的定義,然後再轉換成符合外部綱要的定義,最後才是外部層使用者觀點所看到的資料。 在各層間進行的資料轉換過程,稱為「對映」(Mapping)。
1-3-2 資料庫綱要間的對映-圖例
1-3-2 資料庫綱要間的對映-種類 各層綱要間的對映主要分為兩種,如下所示: 外部與概念對映(External/Conceptual Mapping):所有外部綱要都要對映到概念綱要,以便資料庫管理系統知道如何將外部層的資料連接到哪一部分的概念綱要。例如:在外部綱要(學生編號, 姓名, 年齡),學生編號是對映到概念綱要的學號,年齡是從概念綱要的生日運算而得。 概念與內部對映(Conceptual/Internal Mapping):這是概念綱要對映到內部綱要,以便資料庫管理系統可以找到實際儲存裝置的記錄資料,然後建立概念綱要的邏輯結構。
1-3-3 實體與邏輯資料獨立-邏輯資料獨立 邏輯資料獨立(Logical Data Independence)是指當更改概念綱要時,並不會影響到外部綱要。其位置是在三層架構的外部綱要和概念綱要之間,如下圖所示:
1-3-3 實體與邏輯資料獨立-實體資料獨立 實體資料獨立(Physical Data Independence)是指當更改內部綱要時,並不會影響到概念綱要。其位置是在三層架構的概念綱要和內部綱要之間,如下圖所示:
1-4 資料庫管理系統-圖例 資料庫管理系統是由多種不同的程式模組所組成,基本資料庫管理系統的系統架構擁有四大模組,如右圖所示:
1-4 資料庫管理系統-儲存管理 儲存管理(Storage Manager) 儲存管理對於簡單的資料庫管理系統來說,就是作業系統的檔案管理,不過為了效率考量,資料庫管理系統通常會自行配置磁碟空間,將資料存入儲存裝置的資料庫。例如:硬式磁碟機,或是從資料庫讀取資料。 儲存管理可以再分為:檔案管理(File Manager)實際配置磁碟空間後將資料存入磁碟,和緩衝區管理(Buffer Manager)負責電腦記憶體的管理。
1-4 資料庫管理系統-查詢處理模組 查詢處理模組(Query Processor) 負責處理使用者下達的查詢語言指令敘述,可以再細分成多個模組負責檢查語法、最佳化查詢指令的處理程序。 查詢處理模組是參考系統目錄的中繼資料來進行「查詢轉換」(Query Transformation),將外部綱要查詢轉換成內部綱要的查詢,或是使用索引來加速資料查詢;如果是交易,就交給交易管理來處理。
1-4 資料庫管理系統-交易管理 交易管理(Transaction Manager) 交易管理主要分為:同名的交易管理子系統,負責處理資料庫的交易,保障資料庫商業交易的操作需要一併執行;「鎖定管理」(Lock Manager)也稱為「並行控制管理」(Concurrency-Control Manager)子系統來負責資源鎖定。
1-4 資料庫管理系統-回復管理 回復管理(Recovery Manager) 回復管理主要分為:「記錄管理」(Log Manager)子系統,負責記錄資料庫的所有操作,包含交易記錄,以便同名的回復管理子系統能夠執行回復處理,回復資料庫系統。
1-5 資料庫管理師-說明 「資料庫管理師」(Database Administrator;DBA)負責和執行一個成功資料庫環境的相關管理和維護工作。事實上,資料庫管理師負責很多工作,它可以是一個人,也可能是一個小組來擔任。 簡單的說,資料庫管理師的主要目的是維護資料庫系統的正常運作,並且讓使用者能夠存取所需的資料。
1-5 資料庫管理師-具備知識 通常資料庫管理師需要擁有公司管理和資料庫等電腦技術的專業知識,最好是主修資訊或資管科系的人員,其需要的相關電腦知識,如下所示: 熟悉作業系統操作。 熟悉一種或數種資料庫管理系統的使用。 精通資料庫系統提供的查詢語言,例如:SQL Server的Transact-SQL,Oracle的PL/SQL。 資料庫設計,至少需要清楚公司資料庫系統的資料庫綱要。 對電腦硬體與網路架構有一定的了解。例如:主從架構和Internet網際網路。
1-5 資料庫管理師-負責工作 資料庫管理師需要負責的工作相當多,一些主要負責的工作可以分成三大部分: 維護資料庫綱要 資料管理和維護 監控資料庫管理系統
1-6 資料庫系統的處理架構 1-6-1 集中式處理架構 1-6-2 分散式處理架構
1-6 資料庫系統的處理架構 「架構」(Architecture)這個名詞可以指單獨一台電腦的設計,不過,對於企業組織來說,通常是指整個公司組織電腦系統的配置,包含實際使用的電腦硬體種類、網路、配置位置和使用的電腦運算方式。 資料庫系統架構也可以分成這兩種處理架構,如下所示: 集中式處理架構(Centralized Processing Architectures)。 分散式處理架構(Distributed Processing Architectures)。
1-6-1 集中式處理架構 集中式處理架構擁有一台大型主機,使用多個終端機(Terminals)與主機進行溝通,如下圖所示:
1-6-2 分散式處理架構-說明 分散式處理架構(Distributed Processing Architectures)是隨著個人電腦和區域網路而興起,大型主機逐漸被功能強大的個人電腦或工作站(Workstation)所取代,個人電腦和工作站足以分擔原來大型主機負責的工作,使用多台個人電腦和工作站透過網路分開在各電腦執行所分擔的工作,稱為分散式處理架構。
1-6-2 分散式處理架構-主從架構 「主從架構」(Client/Server Architecture)的電腦本身並沒有分別,只是扮演不同角色,分為伺服端(Server)和用戶端(Client),如下圖所示:
1-6-2 分散式處理架構-二層式主從架構 標準主從架構就是一種二層式主從架構(Two-Tier Client/Server Architecture)。二層式主從架構是90年代廣泛使用的處理架構,如下圖所示:
1-6-2 分散式處理架構-三層式主從架構 三層式主從架構是擴充二層式主從架構,在之間新增一層「商業邏輯層」(Business Logic Tier)來建立「三層式主從架構」(Three-Tier Client/Server Architecture),如下圖所示:
End