第 二 章 文獻探討
2.1 企業資源規劃
現今的競爭市場變動太多，世界將變成小且變動不斷的競爭 市場，企業今天面對的是一個新的競爭環境、新的市場和顧客多 變 的 需 求 。 這 樣 的 環 境 帶 給 製 造 商 一 些 刺 激 競 爭 優 勢 的 改 變 例 如：1.整個供應鏈的總成本降低 2.生產的時間縮短 3.達到最少存 貨 4.改善產品的品質 5.擴大產品的種類 6.提供更準確的送達日跟 服務給顧客 7.有效地整合供應商、通路商跟製造商。 今天企業必 須 去 改 變 它 們 的 競 爭 策 略 跟 企 業 流 程 程 序 去 對 她 們 的 客 戶 負 責 並且使企業本身更具有競爭力。
經濟自由國際化後，因應市場的激烈競爭，企業的產銷策略 必須緊盯 市場脈動隨時調整，因此企業導入接單後生產(BTO)與 全球運籌模式(Global Logistic)，以迎接競爭時代的來臨，此時企 業的管理人必須了解海內外企業的所有資源狀況，並能將所有資 源全部整合，其中包括公司本身的人事、財務、物料、技術、資 訊 、 生 產 外 ， 並 結 合 上 下 游 成 為 一 個 完 整 的 供 應 鍊 模 式 (Supply Chain)，並能即時提供有用的資訊作為決策之用【10】。而企業資 源規劃系統應運而生，此系統結合軟體廠商、管理顧問公司與資 訊廠商，並結合公司各部門人員，在高層領導人與全體員工的全 力支持與配合下，依需求採用全面導入、逐漸導入與快速導入等 方式，並依照妥善事前的準備工作、企業的分析、系統的導入與
規劃、系統的測試到系統的上線、因應變革持續調整等步驟逐一 完成，藉以提昇本身的競爭力，開拓企業的新契機【10】。 整體 而言，企業資源規劃系統已成為經營管理系統的核心。
2.1.1 企業資源規劃系統的演進
1960 年代，製造系統的焦點注重在庫存盤點的管理控制上。
那時候很多的軟體通常都是依顧客需求訂做的，都是用來處理庫 存盤點利用傳統一般的盤點概念。
1970 年 代 ，焦點轉移到物料需求規劃(Material Requirement Planning，MRP)系統。MRP 系統可以將支配的排程表建立成時間 點上的出貨組合需求、原料計劃和採購行為，以期能夠達到供貨 的即時性跟採購物料的準確性。
1980 年 代，MRP-II (Manufacturing Resources Planning)則是由 原先的 MRP 系統從製造業移轉到商店購物場所層面和管理分類 物的活動。1990 年代早期，製造資源規劃(MRP-II)更進一步延伸 涵蓋工程、財務、人力資源、專案管理等方面。任何企業組織皆 都 包 含 這 所 有 活 動 的 應 用 。 因 此 ， ERP (Enterprise Resource Planning)系 統 便 從 這 時 期 有 了 基 本 功 能 的 雛 形 。 表 2.1 整 理 出 ERP 系統的演進。
年代
Item
60 年代 70 年代 80 年代- 90 年代
90 年代 -現在
市場需求 大多數企業 大多數企業 分眾 分眾、個人
需求方向 功能、成本 功能、品質 品質、彈性 彈性、時效
生產方式 少樣大量生產 少樣小量生產 多樣大量生產 大 量 客 制 生 產
系統名稱 尚無統一名稱 MRP MRP-II ERP、SCM
管理概念
以 處 理 存 貨 盤 點為主
強 調 物 料 規 劃、生產 及 現場 監控
強 調 成 本 、 品 質、效 率與工料 的即時性
強調研發、銷 售、生產、被 銷、服務與財 務 等 內 部 資 源 整 合 及 最 佳 化 的 應 用 並 結 合 外 部 客 戶 與 廠 商 整 合 成 全 球 運籌的模式
表2.1 企業資源規劃系統的演進【3】
除了系統的需求之外，ERP 系統將科技技術方面定位成客戶 端跟服務端的分散式系統架構，物件導向程式設計等方向。ERP 系統將廣義的 ERP 解決問題定位廣義的範圍包含製造系統、配 銷、財務、專案管理、售後服務等。 ERP 系統應該可以充分地應
用自如地去支援不同製造工業的環境，比如倉儲、配銷、訂單處 理應用。客戶訂單處理應該有彈性地且有足夠能力地整合這些相 同系統的製造環境。ERP 系統應用部分，要考慮理論與實務雙方 面，不能一謂地只是著重於系統本身的各個模組特性，缺乏理論 的基礎。其實 ERP 系統並不是一個全新的領域，他是沿習早期的 物料需求規劃（MRPI）和製造資源規劃（ MRPⅡ）之概念，再 加以整合除生產部門之外的各個部門營運資訊，使經營者可以得 到與決策者相關的適時決策資訊。
今日的 ERP 系統，不但可以使導入的企業擁有全球運籌的能 力，還能讓企業的「產業供應鏈」更形完整，與上下游廠商合作 更為緊密。最重要的是，導入 ERP 的流程更是企業檢視自我狀 況，進而企業再造的最好方式。由此看來，ERP 不僅只是一項 IT 的產品，更是結合了商業管理知識與眾多企業經營經驗的整合式 商業系統，充分展現了人類運用資訊科技產生的強大力量，更創 造了未來可能的商業發展與運作模式。
2.1.2 ERP 系統對企業的影響
ERP 系統是一種企業再造的解決方案，藉由資訊科技技術的 協助，將企業的營運策略與經營模式導入整個以資訊系統為主幹 的企業體之中。ERP 系統卻絕不僅僅只是科技上的改變，還牽涉 到組織內部所有關於人員、資金、物流、製造，乃至於整個運作 流程和組織機制相關的全方面變革管理。換句話說，ERP 系統能
夠有效掌握各式各類相關資源，協助決策 者即 時訂定完善的因應 策略。
從組織內部的構面來看，ERP 系統涵蓋了組織的運作、管理、
溝通、檔案處理，以及決策等企業數個相當關鍵的流程，同時它 也整合了以往的物料需求計畫、人力資源管理、財物管理、專案 管理等既有的架構，更納入全球運籌（ Global Logistic ）的觀念。
ERP 系統導入一方面提昇企業在競爭市場中的競爭實力，另 一 方 面 也 將 企 業 內 部 的 資 源 做 有 效 的 整 合 跟 利 用 而 使 得 企 業 本 身擁有即時有效的資訊。導入 ERP 系統對於企業有怎樣的效益，
總歸於以下幾點：提昇作業效率、減少組織層級、減少人工成本 及物料成本、改善產品品質提昇生產力、提昇資金週轉率、整合 客戶級協力廠商、管理分散組織、管理企業文件或資料。
2.1.3 企業導入 ERP 遇到的問題
但是 ERP 系統對於企業組織內部本身既有的應用程式系統的 溝通跟整合又會是一項極需要解決的問題。雖然 ERP 系統可以將 企業本身擁有的資源做妥善的規劃跟分析，但是針對的也只有特 定的系統跟功能。 在導入 ERP 之後，企業往往會發生 ERP 系統 的資料格式和企業本身既有的資料並無法整合應用於 ERP 系統 之中，且也無法和企業組織本身既有的應用程式做溝通交流。假 如，本身企業 自行發展的應用程式無法和導入的 ERP 系統作溝通 整合，勢必浪費了轉換資料介面開發所需要支出的成本跟人力，
假如可以保有企業自行開發的系統且該系統又可以和 ERP 系統 共同享用企業本身的資源，而達到資源共享且又適用於該企業本 身特有的營運流程，這就是現在各個企業所追求的方向。所以，
EAI(Enterprise Application Integration) 的 應 用 觀 念 就 這 樣 誕 生 了。
2.2 企業應用程式整合
EAI(Enterprise Application Integration)主 要 整 合 的 類 型 分 別 是資料、訊息和程序流程，能夠協助企業整合內部網路、ERP、
CRM、SCM 及電子交易市集等軟體系統。可以清楚的知道的是，
整 合 企 業 程 序 發 展 雖 然 做 起 來 複 雜 且 花 費 很 多 但 是 卻 能 給 企 業 提供一個很大的利益及回饋的報酬。 在這一節裡頭，我們將會將 EAI 做一個介紹並將三種類型的 EAI 做一個比較跟介紹。
2.2.1 EAI 的起源
近幾年來， EAI 的方向在於整合各種在異質環境下的硬體或 軟體去執行且發展一個適用於所有不同平台的應用程式、企業自 行 開 發 的 應 用 程 式 或 是 套 裝 商 用 軟 體 系 統 而 產 生 一 個 好 用 又 有 效率的應用系統整合。在企業的資訊技術應用中，多種樣式的應 用程式都擁有各自的資料庫，且形成資料的分隔，這樣會形成三 個方向的影響【11】：
1.每一個資料庫應用系統都有它自己本身擁有的企業營運目 標規則。
2.每一個資料庫都會有資料重複儲存的問題。
3.沒有一個資料庫擁有完整的企業營運目標規則，必然要去 整 合 多 個 應 用 程 式 的 資 料 而 得 到 總 觀 完 整 的 企 業 營 運 目 標。
這三方面的影響，造成資料的分隔，每個應用系統皆各自為 政而無法真正達到有效率地整合運用。造成每一個應用程式的產 生只為了特定的營運目標而設置。譬如，ERP 系統是為特定目的 和 特 定 的 一 群 人 所 設 計 建 構 的 ， 並 無 法 針 對 大 眾 化 的 目 的 而 設 置。特 定目的的應用程式系統大多有限地提供公司部分程式處理 的功能而無法提供過多的營運法則作業功能。
在 營 運 規 則 (Business Rule)中 也 會 因 為 應 用 程 式 的 部 分 應 用 功能而無法全盤地提供公司營運的規則功能，而造成三個主要方 向的影響【11】：
1.每一個部門區域只運用有限的活動
2.在不同的部門區域中，同時執行了企業營運規則，造成了 營運規則作業的重複使用。
3.沒有一個部門區域擁有整個公司完整的企業營運法則，而 變成要為多個部門建立共同的的營運流程。
一些企業目前已經利用手動的方式將廣泛使用的營運流程功 能重新分析再呈現出最佳的使用營運作業流程，但是這些營運功 能必須要能自動化運作且也要文件形式上的展現。以上企業在資
料 儲 存 重 複 和 營 運 作 業 流 程 重 複 且 不 統 一 的 這 兩 方 面 問 題 導 致 了以下的問題【11】：
1. 資 訊 真 實 性 (Information fidelity) ： 資 料 庫 之 間 多 餘 的 企 業資料會形成錯誤的狀態描述在多個資料庫之間。
2.企業程序方法(Business Processes)：每一個應用程式都有它 該負責的功能跟應用的方向 ， 且它們也不知道其他應用程 式的屬性和應用的方向。這樣就必須將不同類型的應用程 式整合連結起來，以提供充足的處理能力。
以上的兩個問題造成了企業對於整合應用系統的需求，解決 方 式 就 是 建 立 多 個 應 用 程 式 之 間 企 業 程 序 流 程 的 整 合 和 確 定 資 料庫裡資料一致性，以提供使用者一個有用的資訊訊息去做適當 合理的決策。
2.2.2 EAI 的定義
2001 年 的 2 月，Boris Lublinsky 對 EAI 下的定義是『 EAI 是 一種策略、技巧或是作用過程針對整合分隔的資訊和建立企業營 運流程』【11】。
根據 OVUM 的定義『 EAI 係指結合技術與流程的策略性整合 方案，能將客製化、套裝軟體與 Web 的功能作有效結合，以商業 間所熟悉的文件及檔案格式進行商業資訊的交換 』。其中 EAI 所 使 用 的 整 合 方 法 乃 以 標 準 化 的 中 介 軟 體 架 構 與 分 散 式 物 件 技 術 將不同應用程式作安全且有效率的整合【7】。
1999 年，David S. Linthicum 發表文章認為 EAI 的定義是『企 業 體 中 任 兩 個 以 上 的 連 接 應 用 程 式 和 資 料 庫 無 限 制 地 共 享 彼 此 的資料和營運流程。』。企業的基本需求是希望能夠共享資料而 不改變應用程式和資料儲存的結構【15】。
EAI 的趨勢在於兩個方向，一是 web 功能應用在企業的需求；
另一個則是企業對企業(B2B)的整合。 要達到這兩個方向就必須 整合企業組織內部之間的系統。這些系統必須提供的功能有網路 環境、EDI 介面溝通的管道、web 的傳輸功能等【11】。
2.2.3 Middleware 和 EAI 的差異
圖2.1 點對點的整合方法【23】
中介軟體介面(Middleware)主要是利用 message queuing 或是 remote procedure calls(RPCs) 這 兩 種 方 式 針 對 點 對 點 (point to point)提供解決方法 ，如圖 2.1【23】，Middleware 的方法則是透 過點對點的整合方法。傳統點對點的整合方法，會和每一個應用 程式溝通間產生一個新的 API 介面，當應用程式增多時，要建構
的 API 介面程式也增多，因此往往無法滿足企業的需求並導致整 合成本過高與整體效率過低的現象。
EAI 的整合方法，如圖 2.2【23】所示，以整體的觀點使用集 中式的整合平台，將過去不一致的應用程式間整合的方式汰換，
避 免 使 用 傳 統 整 合 方 法 所 導 致 之 基 礎 資 訊 軟 體 資 源 與 資 料 大 量 重複的情況，以提昇企業內、外部應用系統整合的整體效率。
圖2.2 Message Broker 整合的方法【23】
基本上 EAI 機制是中介軟體介面的一種，但是 EAI 和傳統的 Middleware 也有所區別，下列將提出 EAI 和 middleware 之間不 同的特色比較，如圖 2.3【25】：
1.EAI 著 重 在 企 業 營 運 流 程 和 資 料 兩 者 的 整 合 ， 反 之 傳 統 Middleware 的方法則是以資料為主要導向。
2.EAI 包含重新利用企業營運流程和資料的想法。
3.EAI 允許使用者只了解少部分詳細的應用程式系統而去整 合應用。
圖2.3 EAI 和傳統中介軟體的差別(Aberdeen Group) 【25】
以上就是 EAI 和傳統的 Middleware 不同的地方，EAI 的方法 則 是 要 做 到 應 用 程 式 自 動 化 且 以 企 業 營 運 流 程 的 概 念 為 導 向 而 發展出來的一個新的機制。Middleware 的整合方法是每個應用程 式之間各自獨立發展的 API 介面程式，而 EAI 的整合方法則是利 用 Message 倉儲的觀念，將流程和應用程式系統間的 API 介面加 以整合而發展的應用系統，更具訊息性、連結性和安全性。
2.2.4 EAI 的類型
Boris Lublinsky 在 文 章 中 提 到 ， EAI 有 三 種 類 型 ， 分 別 是 Data、Message 和 Process 這三方面，以下我們將針對這三個類型 做簡單的介紹。
2.2.4.1 Data-Level EAI
Data-Level EAI 處理在多個資料庫或資料儲存系統中移動的 資料。很多企業了解到資料階層整合是企業要進入 EAI 整合的一 個重點。當應用程式之間要分享資訊時，就要從異質的資料庫中 去 轉 換 需 要 的 資 料 。 有 很 多 工 具 和 技 術 支 援 這 一 階 段 類 型 的 EAI，實際上，執行這一階段的 EAI 整合，就像我們實際去進入 資料庫讀取資料而不用去改變應用程式的設計碼【12】。
在 一 般 的 EAI 導 入 的 企 業 裡 ， 資 料 可 能 是 透 過 數 以 百 計 的 Database 和 多 達 數 千 的 table 所 分 析 處 理 而 產 生 出 來 的 。 Data-Level EAI 的好處是花費成本低廉。因為，企業可以不用改 變應用程式的程式碼(code)，且也不需要去額外增加改變應用、
測試、延伸使用習慣的損失。
2.2.4.2 Message-Level EAI
Message Level EAI 處理的工作是在多個應用程式之間作訊息 的轉換。這個方法不同於 Data Level EAI 在應用程式間傳遞訊息 的功能。這個方法的功能主要在傳輸應用程式資料並使其能有效 地被運用。Message level EAI 是侵入很多 Data Level EAI 整理後 的資料，因為 EAI 需要很多修飾的應用程式而去產生傳遞跟接收 訊息的介面【13】。
2.2.4.3 Process-Level EAI
Process Level EAI 處理的是建立企業營運流程和整合多個企
業內部的應用系統而應用於企業的營運流程。Process-Level EAI 是 Message-Level EAI 的延伸。實際的資料轉換仍然存在於相對 的資訊傳輸訊息中，但是 EAI 中介軟體的動作和 Workflow engine 相似。Process Level EAI 是 EAI 執行的基本原理，因為它轉換異 質間的應用程式凝聚成企業程序系統，支援企業所有需求的功能
【11】。
圖2.4 Process-Level EAI【11】
企業選擇 EAI 方法時，需要考慮的是公司的需要跟能負擔得 起的成本等條件。 有限的預算跟資源的考慮條件下，就應該選擇 Data-Level EAI 的整合方法。將來在維護跟擴充上可能會有點花 費但是依目前的情況來說這將是最便宜的做法。這個方法通常是 利 用 在 網 際 網 路 上 的 整 合 。 Message Level EAI 可 以 認 定 為 Process Level EAI 的中間步驟，或是不是定義很好的企業營運流 程的運用，直線地移動資訊在 Process Level EAI 中。
Process Level EAI 提供高度整合的資訊，並且也可以提供方
法給 WEB 程式的應用及 B2B 的整合。Process Level EAI 將企業 內部營運法則看待成一組彼此有關係的企業營運程序。依圖 2.4 來 看 EAI 是一個焦點支援各個企業流程的運作，Process Level EAI 負責編譯 Message 傳遞流程的功能、營運執行法則(控制邏輯) 和程序執行的定義等。
本研究將採用圖 2.4 中 的 Process-Level 的模式架構去進行 EAI 模組機制架構的研究。此部份將會在第三章中詳細述說。
2.2.5 企業導入 EAI 的優點
EAI 的價值在於能夠有效地協助企業達到降低風險、軟體開 發 和 維 護 成 本 的 降 低 並 能 進 一 步 整 合 供 應 鏈 廠 商 之 間 的 合 作 關 係。以下簡單地敘述 EAI 對企業的效益【8】：
1.降低企業本身既有應有程式的維護成 本：企業採用 EAI 方 法期望能有效降低現有系統的維護成本，企業的系統維護 成本由原先維護個別系統應用程式到只針對整合的應用程 式系統，大大地降低了應用程式的維護成本。
2.降低應用程式整合成本：企業採用 EAI 的解決方法後，就 能將新的技術快速地且容易地整合在原先的應用系統架構 下 。在資料分析跟應用系統整合過程中所花費的時間跟整 合成本都有顯著的降低。EAI 的解決方案讓企業不同部門間 應用程式整合更容易且也具有成本效益。
3.增加整合的彈性：EAI 的解決方法提供彈性的整合方法以支
援分散時進行不同商業系統間的系統與資訊的整合交換。
4.提高跨組織溝通的效率：目前企業間的合作關係越來越緊 密，因此企業導入 EAI 將能有效地提昇企業間供應鏈系統 跟資訊傳遞的即時性與諧調性。
企業導入 EAI 概念後，對於開發應用程式的成本將會降低，
且對於新系統的開發應用將會更容易更快速，進而縮短開發的時 間。
2.3 統一化模式語言
物件導向技術是以物件為主要角色，所強調的是物件跟系統 可以再利用、有擴充性極易於維護設計等特性。物件導向技術是 由早期的物件導向程式語言(OOP)，漸漸發展成轉體工程分析和 設計工具。
UML 是 以 Grady Booch 的 Booch Method，Ivar Jacobson 的 Use Case，以及 Jim Rumbaugh 的 OMT 方法為基礎，再參考其他 的 方 法 論 設 計 者 、 軟 提 供 應 商 以 及 使 用 者 的 意 見 所 制 定 而 成 。 UML 已成為國際物件管理組織(OMG)接受為物件導向之標準模 式語言。因為不同的企業組織就有不同的流程，所以 UML 就是 希望能整合出一套標準流程模型語言。
UML 提供九個圖供各個發展階段使用，且將這九種圖分成結 構圖(Structural diagram)、行為圖(Behavioral diagrams)以及實行 圖 (Implementation Diagrams) 。 其 中 結 構 圖 包 含 類 別 圖 (Calss
diagram)和 物 件 圖 (Object Diagram)； 行 為 圖 則 包 含 使 用 案 例 圖 (Use Case Diagram) 、 循 序 圖 (Sequence Diagram) 、 合 作 圖 (Collaboration Diagram)、狀態圖(State transition Diagram)、活動 圖 (Activity Diagram) ； 而 實 行 圖 則 包 含 元 件 圖 (Component Diagram)和部署圖(Deployment Diagram)。
UML 可以從不同角度檢視一個系統，為不同的目的使用不同 的圖形。由 圖 2.5 中知道，UML 擁有不同的觀點來使用不同的圖 形規劃以下我們就針對 UML 的幾個觀點做介紹【24】：
圖2.5 模型觀點和圖形
1.使用者模型觀點：此觀點來自提出答案所解決問題的個人 見解。這個觀點展示了問題所有者的目標，以及他們對答 案的要求。這個觀點使用 Use Case 圖，敘述由一個系統提 供外部互相合作的功能，圖形包括行為者、 Use case 和兩者 之間的關係。
使用者觀點 Use Case 圖
結構觀點 實作觀點
行為觀點 環境觀點
元件圖 類別圖
物件圖
循序圖 部署圖 合作圖 狀態圖 活動圖
2.結 構 模 型 觀 點 ： 包 括 一 個 問 題 和 答 案 的 靜 態 或 結 構 性 觀 點。這個觀點也稱靜態或邏輯觀，由類別圖和物件圖組成。
3.行 為 模 式 觀 點 ： 包 含 一 個 問 題 和 答 案 的 動 態 或 行 為 化 觀 點，這一觀點也稱作動態、程序、同時發生的、或合作性 觀點。此觀點由循序圖、合作圖、狀態圖和活動圖。
4.實作模型觀點：包括解答實作的結構及行為觀點，此觀點 也稱為元件或發展觀點，是由元件圖組成。
5.環 境 模 型 觀 點 ： 包 括 解 答 必 須 實 作 的 領 域 結 構 及 行 為 觀 點，此觀點也稱為部署或實體觀點，它是由部署圖所組成。
2.4 可延伸標籤語言
本小節的重點在介紹 XML，並包含介紹 XML 與 HTML 跟 SGML 的關係，並簡單的敘述 XML 文件表示方法跟基本結構語 法，最後將探討 XML 在 web 尚如何傳遞資料的運用。
2.4.1 XML 與 SGML 和 HTML 之間的關係
XML 的 前 身 是 SGML(Standard Generalized Markup Language，標準一般化標記語言)，這是一種用來描述電子文件結 構與內容的標記語言。因 為 SGML 的複雜性使得它不易於使用在 網路文件的格式呈現表式。儘管 HTML 是 SGML 的一種應用以 及網路出版業的標準，但是 SGML 始終沒能運用在網路開發上。
SGML HTML XML
全名 Standard Generalized Markup Language
Hyper Text Markup Language
eXtensible Markup Language
Markup Language Language Language
中譯 標準通用標記語言 超文字標記語言 延伸標記語言
發展歷史
國 際 標 準 組 織 (ISO) 於 1986 年公告的電 子文件交換標準
源 自 SGML，1989 年 由 歐 洲 核 子 物 理 研 究 中 心 的 研 究 人 員所 創 ，為 SGML 的應用
源 自 SGML，1998 年 由 W3C 所發展
目的 規 範 文 件 製 作 及 交 換標準，與不同電腦 系統交換
針 對 網 頁 頁 面 呈 現
方式 針 對 網 頁 內 容 ， 撰 寫 結構化文件語言
內容
1.SGML 宣告 2.DTD(Document Type Definition ) 3.DI(Document Instance)
1.文字 2.圖形 3.超連結
1.XML
2.XML Schema 3.XSL
4.XLL 特色 DTD(Document Type
Definition )
網 際 網 路 上 使 用 的
超連結文件 內 容 和 格 式 是 分 離 的，不是綁死的
優點
1. 各 種 資 訊 自 行 定 義擴充標準
2. 維 持 資 料 格 式 一 致
3. 可 重 複 使 用 資 源 共享
1. 嚴 謹 正 確 的 結 構 化文件
2. 不 限 電 腦 週 邊 語 言的限制
3. 可 隨 所 需 格 式 輸 出
1.簡單易學
2. 支 援 各 種 方 法 製 作 HTML
3.HyperLink 4.表單建立容易 5.程式撰寫容易 6.提供開放平台
1.延伸 S G M L 的 優 點 2.改善 HTML 的 缺 點 3.開發應用程式容易 4.具 延 展 性 適 用 各 個 領域
5.異 質 資 料 庫 之 間 文 件處理
6.採用 unicode
缺點
1. 缺 乏 網 頁 瀏 覽 器 的支援
2. 缺 乏 標 準 樣 式 支 援
1. 結 構 限 制 造 成 瀏 覽障礙
2. 缺 法 表 達 內 容 的 支援
3. 格 式 固 定 限 制 資 料交換
4. 缺 乏 一 致 性 限 制 自動化
5.搜尋不夠精準 6.管理維護不易
1. 各 界 定 義 標 籤 不 一 致，難以統一執行 2. 各 領 域 使 用 自 行 定
義 的 標 籤 易 產 生 相 容性溝通的問題 3. 資料安全問題有議
表2.2 SGML、HTML 和 XML 之間的差異比較
1998 年 2 月，XML 建議標準提出，是目前通用的 XML1.0 版 本標準，XML 的規格便是由 W3C XML 工作群維護並負責增修 跟調整的工作。基本上 SGML、HTML 和 XML 不會因為誰的存 在而使其他的標記語言消失。XML，主要運用在長期使用且須結 構化的文件；HTML 仍運用於快速出版的網頁，SGML 仍無法被
Internet 接受，將繼續適用複雜結構的運用。
今天我們將 XML、SGML 及 HTML 三者做簡單的比較整理在 表 2.2 中【1】【9】。
2.4.2 HTML 在 WEB 上發展的缺點
透過 HTML 標準所定義的標籤，人們可以很快地的將所要公 佈的訊息，放在全球資訊網之上，企業間還可以透過網際網路來 完成部分的交易作業。 但是，因為網際網路的普遍應用，HTML 逐漸出現了一些無法適用的地方：
1.HTML 無結構化文件格式
沒 有 傳 輸 處 理 文 件 的 規 則 ， 只 傳 送 可 讀 取 的 資 料 。 HTML 只提供了一種標準的標籤用來表示資料，並且藉由瀏覽器 來觀看，以及文件中的結構都無法方便的使用 HTML 來表 示，HTML 缺乏表達文件結構的能力。
2.搜尋能力有限
HTML 的文件中並不含結構性的資訊 ，所以當我們要做檢 索或搜尋時， 在 HTML 中常會找到一大些不相關的資料，
而無法做到 context-sensitive 的搜尋方式。
3.交換互通性不夠
因為網際網路無遠弗屆的特性，人們喜歡透過它來交換訊 息，但是因為 HTML 無法傳輸文件格式等缺點而無法傳輸 資訊。
4.自動化流程不易
自動化的施行可以減低人力成本、加快傳遞速度與改善資 訊的品質，尤其是對於大部分表單作業，如訂單、線上銀 行交易等更是如此。然而自動化的施行，有賴於自動化流 程中的資料需具有高度的描述性與一致性，但 HTML 有限 的標籤，正是明確描述資料的一大限制。
為 了 要 讓 各 式 各 樣 的 資 料 能 在 WEB 上 使 用， W3C (World Wide web Consortium) 發展了一種 well- control 資料交換語言 XML (Extensible Makeup Language)。XML 本身不是一個單一的 標示語言 ，它是一種元語言(meta-language)， 可以被用來定義任 何一種新的標示語言【26】。像 HTML 之類的傳統標示語言，是 用來定義某一類文件的格式，以便於展示或列印；而 XML 則是 可以用來創造類別文件的格式定義，也就是在 XML 之中創造出 很多不同的標示語言，用來定義不同的文件類別。
2.4.3 XML 文件的結構
XML 是一個具有結構化且功能強大的標示語言。每一份 XML 文件都包含邏 輯結構和實體結構。邏輯的結構就跟範例一樣，告 訴你在此文件中應該以哪種順序包含一些元素。實體的結構則表 示為文件中的實際資料，這些資料可能是電腦記憶體中的文字也 可以是網路上的圖形【26】。
2.4.3.1 XML 的邏輯結構
l PROLOG
XML 文件中 ，第一個結構性元素是選擇性的 prolog，它本身 包含 XML 宣告和 document type 宣告二個基本選擇性的元件。
XML 宣告要同時包含 encording 宣告用來辨識編碼的字元組 和 stand -alonedocument 的宣告用來辨識 XML 文件中是否有外界 的標籤宣告。 Document Type 宣告中包含特別類別文件的文法規 則或 DTD 等，此文件型別宣告要出現在 XML 的宣告後面，但是 要在其他文件元素之前。 在 Prolog 之後就是 Document 元素，是 XML 文件核心及文件內容所在。
l Document 元素
一個 Document 文件包含整個 XML 文件中的所有資料，單一 元素可以包含任何數目的巢狀次階層元素和外部實體。
l 巢狀結構
巢狀結構就是將一個物件包含在另一物件之中，元素間巢狀 結構建立了元素之間的父子關係，每一個子元素是完全地包含在 它的父元素裡面。
2.4.3.2 XML 實體結構
XML 文件的實體結構便是由 文件中所有的內容組成。 每一個 實體都有一個獨特的名字和屬於他們的內容，這些內容可以是文 件中的一個字元，或是文件外的一個大型檔案。XML 文件可分
為下列幾種實體：
1.可拆解實體和不可拆解實體
可拆解實體也稱為文字實體(text entity)，這個實體的內容被 處理後就成為 XML 文件的一部份。不可拆解實體可以說是 一個容器，內容可為文字也可能不是。 如果是文字的話，
其內容仍舊是無法拆解的 XML。
2.預先定義實體
在 XML 文件中，某些字元是有著特殊的作用的，處理器會 將他們解譯成文件的標籤而不是真實的資料。
3.內部和外部實體
內 在實體並沒有另外的實際儲存體單位；實體的內容就在 Prolog 宣告的敘述中。外部實體在它的宣告中，藉由系統或 公有的辨識字串來參照實際內容的儲存體位置。
2.4.4 XML 語法
l tag(標籤)
XML 的 結 構 規 則 則 反 映 在 它 的 語 言 規 則 或 是 語 法 上 。 在 HTML 中，一個元素通常包含開始和結束標籤，同樣的在 XML 上也同樣擁有這樣的語法。雖然 XML 必須使用結束標籤，但是 它卻支援 Empty-Element，Empty-Element 標籤有效地將沒有內容 的 元 素 開 始 和 結 束 的 標 籤 結 合 起 來 ， 它 的 格 式 是 ：
<TAGNAME/>，在標籤名稱之後加上正斜線。
l 屬性
屬性是給元素指定的一個值，但卻不使屬性本身成為元素內 容的一部份。
2.4.5 有效的與合乎語法的 XML
XML 的最重要的兩個特徵：一為 Valid 一 為 Well-Formed。這 兩個特徵為文件提供良好的結構及使資料成為自我描述的資料。
l 有效的文件
一個有效的 XML 文件必須要很嚴謹地遵從所有在 DTD 文件 中規定的所有規則。有效的文件也必須遵守 XML 規格中所定義 的所有有效文件的限制。
l 合乎語法的文件
雖然合乎語法(Well-formed)文件也有一些規則必須遵從，但 這些規則並不如那些有效性限制一般的嚴格。 但是一份有效的文 件必須符合所有的語法規則和所有的有效性限制。
2.5 XML 文件概觀
一份 XML 文件可以包含三種檔案：XML、XSL 和 DTD。XML 文件主要是用來存放文件內容資料的格式，DTD 或 是 Schema 檔 案則是制定 XML 文件中資料的邏輯結構，另一個 XSL 檔案則是 提供 XML 文件不同的外觀顯示。
2.5.1 文件格式定義
建構 XML 文件資料結構之前，我們要先決定文件的格式。也 就是說，我們要先把文件的基本骨架建構出來後，我們才能依照 架構依圖行事，而有一定的標準。簡單的說，DTD 就是對 XML 文件在格式及架構上的定義。 以下簡單介紹 DTD 的宣告 內容要 如何撰寫【9】：
1.元素宣告
每個元素宣告都要包含元素的名字與資料型態，叫做 Content specification，由 content 模型、關鍵字 EMPTY、關鍵字 ANY 和混合的內容等其中依類型所組成。語法表示如下：
<!ELEMENT element-name element-definition>
<!ELEMENT 表示開始元素的設定且 ELEMENT 是保留字。
element-namem 元素名稱 ，element-definition 元素的定義 ，>
是結束的意思。元素的資料型別將顯示在表 2.3，表 2.4 表示 元素宣告符號。
2.屬性宣告
屬性宣告可出現在 DTD 的任何位置，也可以將單一元素中使 用多個屬性宣告，以下是屬性宣告的表示方法：
<!ATTLIST element-name AttributeName Type Default>
<!ATTLIST>是用來定義屬性宣告的標籤，element-name 是應
用屬性的元素名稱，AttributeName 是屬性的名稱，type 則是 屬性的類型，Default 是屬性的內建值。表 2.6 表示屬性類型，
表 2.5 則顯示屬性的內建值。
型別 宣告 說明
可剖析的文字 #PCDATA 可以被剖析的文字資料
純文字 CDATA 當作純文字不需經過剖析的 資料
沒有內容 EMPTY 不包含任何資料 任何內容 ANY 任意資料
混合型內容 #PCDATA|x|y|z 提供選擇性的資料 表2.3 元素資料型別【26】
符號 目的 例子
“{}” 將元素中內容及順序包容在一起 (A)
“,” 將上述項目分開並以之確定順序 (A,B)
“|” 將各種可替代的選項分開 (A|B|C)
“?” 規 定 某 一 項 目 需 出 現 一 次 或 完 全 不
出現 A?
“*” 規定某一項目可任意出現 A*
“+” 規 定 某 一 項 目 必 須 出 現 一 次 或 一 次
以上 A+
No 只有一個項目會出現 A
表2.4 元素宣告符號【26】
內建值 用法
#REQUIRED 每一個包含此屬性的元素都必須為此元素指 定一個值
#IMPLIED 這個屬性是選擇性的。如果處理器並未讀到 指定的值，便會忽略此屬性
#FIXED 此屬性之值必須為固定的值
Default 指定屬性的內建值，若此屬性為包含於元素 中，處理器會假設值為 default
表2.5 屬性內建值【26】
屬性型態 用法
CDATA 只有字元資料可以在屬性中被使用
ENTITY 屬性的值必須參照到在 DTD 中宣告的外部二 進位實體
ENTITIES 和 ENTITY 一樣但是可有多屬值由空白值分 隔
ID 屬性值應是唯一。 如果一個文件有相同的 ID 屬性值，處理器會產生錯誤
IDREF 其值應參照到文件中別地方的宣告，沒有相 符的 ID 值處理器會產生錯誤。
IDREFS 和 IDREF 一樣，但可以由空白鍵分隔多個數 值
NMTOKEN 屬性值是字元組合，這些字元應為字母、數 字、虛線、冒號或底線
NMTOKENS 和 NMTOKEN 一樣 ，但可以空白鍵分隔的多 個數值。
NOTATION 屬性值是參照 DTD 其他地方宣告的記號 Enumerated 屬性值必須符合列舉值之一
表2.6 屬性類型【26】
