資料庫系統中水平、垂直與混合式綱要之效能評估

中 華 大 學 碩 士 論 文

資料庫系統中水平、垂直與混合式綱要之 效能評估－以無線寬頻網路通訊產業為例

系 所 別：資訊管理學系碩士班 學號姓名：E09410009 吳鼎元 指導教授：李之中 博士

中華民國 九十八 年 七 月

資料庫系統中水平、垂直與混合式綱要之效能評估

－以無線寬頻網路通訊產業為例

The Performance Evaluation for Horizontal, Vertical and Hybrid Schema in Database Systems

－A Case Study of Wireless Broadband Networking Industry

研 究 生：吳鼎元 Student：Ting-Yuan Wu 指導教授：李之中 Advisor：Chi-Chung Lee

中華大學 資訊管理學系

碩士論文

A Thesis

Submitted to Department Information Management, Chung-Hua University

in partial Fulfillment of the Requirements for the Degree of

Master of Science

July 2009

TAIWAN

中華民國九十八年七月

摘 要

傳統在資料庫綱要(schema)的設計上以橫式即水平(horizontal)設計為主，意 即欄位即為實體屬性(entity attributes)。實體可視為真實世界可能發生的事件或者 是行為抽象化的結果。隨著產業的變化，企業的多元化經營讓越來越多的工廠生 產模式從早期的單純少樣的產品逐漸轉變為多樣化模式。從資料庫的角度來看，

產品多樣化勢必有許多實體，而在水平式的資料表(horizontal table)設計上就需要 有許多的屬性才能描述真實世界所發生的事件，完整儲存實體資料。

但是，隨著市場的需求越來越複雜而多元，要能滿足客戶與市場需求，生產 除了趨向多樣化，製程也必須要能夠彈性靈活(flexible)以及滿足未來的擴充性 (extensibility)。就水平式資料表綱要而言，要能滿足這樣的製程就必須不斷增加 屬性並且保留欄位以應付未來的擴充。可是這樣的綱要設計在長期運作之下就會 產生寬(wide)的資料表與稀疏資料集合(sparse data sets)。要解決這個問題可以不 斷的增加資料表並正規化(normalization)，但是這樣會造成資料庫綱要不斷改 變，就效能的影響是個變數且也造成 DBA(database administrator)在維護上的負擔 (loading)，故就有學者提出垂直式綱要(Vertical Schema)的設計方式，此種方式的 確可以達到彈性以及擴充性的需求。

不過，對於垂直式綱要的設計卻很少有研究探討它的效能問題。盡我們所 能，本論文是第一篇使用企業提供的實際運作資料庫綱要與數據資料之研究，並 依照專家之建議分別設計水平式、垂直式與水平垂直混合式(Hybrid)的資料庫綱 要並訪談該企業最關心的資訊設計 26 道查詢命令(queries)，以 Microsoft SQL Server 2005 為實驗平台，對未建立索引與建立索引之後分別比較三種不同綱要的 效能(performance)。我們可以得到結論，無論是有無建立索引，水平式綱要是效 能最佳的。更進一步的，混合式綱要雖不是最佳卻擁有媲美水平式綱要的效能，

且彈性與擴充性的能力如同垂直式綱要。

關鍵字：水平式綱要、垂直式綱要、水平垂直混合式綱要、資料庫設計、效能

ABSTRACT

In tradition, database schema design mainly utilize horizontal schema, in which each column is an entity attribute. Each entity is regarded as a single event which occurs either in the real world or from an abstracted result. With the constant changes of current industries, enterprises diversifications make each factory’s manufacturing mode switching from simple model of products gradually to a more complex one. As viewed from database design, products diversification results in a lot of entities, and the design of horizontal table needs many attributes to describe all events of the real world and to store data of entities completely.

However due to the complexity and diversity of market needs, production procedures must be flexible and extensible enough to satisfy customer’s requests and market demand. In terms of horizontal table schema, it is necessary to add attributes and reserve fields continually for future extension. But the schema in the long run generates wide tables and sparse data sets. If we want to resolve this issue, we can add tables continually and do normalization, but this approach would change database schema continually and efficiency would be uncertain. Moreover, database administrator’s maintenance work will be increased. Therefore vertical schema design is proposed and this methodology is proved to be flexible and extensible.

However, there are only a few papers to discuss the performance issue for the vertical schema. To do our best efforts, this thesis is the first one use the practical data of the enterprise to discuss this issue. In the performance evaluation, we designed three schemas - horizontal, vertical, and hybrid and found 26 queries from the daily operations and the most concerned for the enterprise to proceed the performance evaluation. From the results in the thesis, we can conclude horizontal schema is the best performance in term of the elapsed time and the numbers of disk I/O. Further, the results also show that the number of disk I/O of the hybrid schema is close to that of the horizontal schema, and the flexibility and extensibility of hybrid schema is the same as that of the vertical schema.

Key Words: horizontal schema, vertical schema, hybrid schema, database design, performance

誌 謝

時間過得真快，在研究所這段修業期間，我學到了很多知識與學問。除了感 謝系上老師的教導之外，要特別感謝指導教授 李之中老師的悉心指導。在研究 的過程當中，教授不厭其煩的叮嚀研究重點，並且傾囊相授所有相關知識，就深 怕漏了什麼沒教。教授在作研究上認真與細膩的態度並對論文研究的品質堅持最 令我深感敬佩。同時也感謝口試教授龍華科技大學 黃志宏老師與馬芳資老師給 予許多寶貴的建議使論文可以更善美。

感謝系主任 邱登裕教授、王文良教授、士林電機廠長 郭約瑟先生、中磊電 子副總 李瑞貴先生、訊舟科技品保暨工程處長 游長曄先生的推薦，讓我可以一 圓進修的夢想。

由衷感謝中磊電子企業品保處總監 陳榮坤先生、副理 劉龍翔先生、蘇州廠 廠長 陳志汶先生、品質管理部經理 盧廷熙先生的支持，縱使在職進修也讓我可 以沒有後顧之憂。再者要特別感謝資訊管理處 楊懿森先生在研究資源與技術上 的全力支援，讓我可以完成研究的實驗。另外要感謝京元電子資訊技術處副理 孫 榕芝小姐在本研究進行中給予的專業建議與經驗的分享以及啟碁科技產品經理 彭城先生在論文上的協助。能結合研究與工作並將所學回饋企業是難能可貴的，

謝謝你們。

由衷感謝支持我完成學業的親友們，特別感謝父母親默默為我禱告與噓寒問 暖，感謝教會所有弟兄姊妹給我的關心與代禱。

最後，謹以此論文予我的家人、上司與所有支持我的親友們共享。

吳鼎元 謹誌於 中華大學資管所商業智慧實驗室 中華民國 九十八 年 七 月

目 錄

摘 要...i

ABSTRACT...ii

誌 謝...iii

目 錄...iv

表目錄...vi

圖目錄...vii

第一章 緒 論...1

第一節 簡介 ...1

第二節 研究背景與動機 ...1

第三節 研究目的 ...5

第四節 研究範圍 ...6

第五節 論文架構 ...6

第二章 文獻探討...8

第一節 水平式綱要...8

1. 引言 ...8

2. 水平式綱要的問題 ...9

(1) 寬的綱要(Wide Schema) ...9

(2) 稀疏資料集 ...10

第二節 垂直式綱要 ... 11

1. 引言 ... 11

2. 優點 ...12

3. 缺點 ...13

第三節 水平式 vs.垂直式...14

1. 資料表示方式 ...15

2. 資料表示方式對查詢的影響 ...15

3. 正規化影響查詢複雜度與績效 ...17

第四節 彈性(Flexible)綱要設計...17

第五節 業界的彈性綱要設計方式 ...19

第六節 效能評估的方法 ...21

第三章 無線網路產品生產製程...25

第一節 無線網路概念 ...25

第二節 無線網路產品之分類與用途介紹 ...26

第三節 無線網路產品製程介紹 ...31

1. 產品製程簡介 ...31

2. 成品組裝生產流程說明 ...33

(1) 進料流程...34

(2) 工單審查...34

(3) 成品組裝(Product Assembly)製程 ...34

(4) 校準(Calibration)製程 ...35

(5) 指派(Assign)製程 ...35

(6) 下載(Download)製程...36

(7) 功能測試(Functional Test)製程...36

(8) 有線速率(Throughput)製程 ...37

(9) 無線速率(Throughput)製程 ...37

(10)成品包裝(Packing)流程 ...37

(11)維修(Repair)流程...37

第四章 效能評估設計...38

第一節 實驗之資料庫綱要說明 ...38

1. 水平式綱要...41

2. 垂直式綱要...42

3. 水平垂直混合式綱要 (Hybrid H&V Schema) ...44

第二節 實驗查詢題目設計 ...46

第三節 實驗環境與樣本說明 ...50

第五章 效能評估結果與分析...53

第一節 實驗方法與進行 ...53

第二節 未建立索引的實驗結果 ...54

第三節 建立索引之後的實驗結果 ...58

第四節 實驗數據分析 ...62

第五節 實驗總結 ...68

第六章 結論與建議...69

第一節 研究結論 ...69

第二節 未來研究建議 ...70

參考文獻...71

英文部分 ...71

中文部分 ...75

網路部分 ...76

附錄...77

A 查詢命令...77

B 水平式與垂直式資料筆數分析...92

1. 水平資料表的稀疏度計算方式...92

2. 垂直資料表筆數的合理性...95

表目錄

表 1- 1 水平式綱要查詢結果 ...3

表 1- 2 垂直式綱要查詢結果 ...4

表 2- 1 水平式綱要 ...9

表 2- 2 稀疏資料集 ...10

表 2- 3 垂直式綱要 ...12

表 2- 4 水平式儲存 ...15

表 2- 5 垂直式儲存 ...15

表 2- 6 與系統應用程式協同合作的彈性綱要範本 ...18

表 2- 7 I/O 輸出項目摘要...24

表 3- 1 Domain 開放頻道對照 ...36

表 4- 1 查詢型態分佈表 ...49

表 4- 2 查詢題目分類彙總表 ...50

表 4- 3 三種綱要的資料筆數與佔用空間比較表 ...52

表 5- 1 未建立索引的實驗數據 ...55

表 5- 2 建立索引後的實驗數據 ...58

表 5- 3 未建立索引之查詢績效比較表 ...62

表 5- 4 建立索引後之查詢績效比較表 ...65

表 A- 1 三種綱要的 26 道查詢命令 ...77

表 B- 1 水平式綱要資料表稀疏度分析表...93

圖目錄

圖 1- 1 水平式綱要示意圖 ...3

圖 1- 2 垂直式綱要示意圖 ...4

圖 2- 1 內容屬性層級片段 ...18

圖 2- 2 垂直式綱要設計片段 ...20

圖 2- 3 水平垂直混合式綱要設計片段 ...21

圖 3- 1 無線產品製程流程圖 ...32

圖 3- 2 成品組裝生產流程圖 ...33

圖 4- 1 水平式綱要設計的 ER-Model ...41

圖 4- 2 水平式資料庫綱要 ...42

圖 4- 3 垂直式綱要設計的 ER-Model ...43

圖 4- 4 垂直式資料庫綱要 ...44

圖 4- 5 水平垂直混合式綱要設計的 ER-Model ...45

圖 4- 6 水平垂直混合式資料庫綱要 ...46

圖 4- 7 查詢型態分佈圖 ...49

圖 5- 1 Server 2005 Management Studio 查詢執行畫面 ...54

圖 5- 2 未建立索引之經過時間查詢績效比較圖 ...63

圖 5- 3 未建立索引之邏輯讀取查詢績效比較圖 ...63

圖 5- 4 未建立索引之實體讀取查詢績效比較圖 ...63

圖 5- 5 未建立索引之讀取前讀取查詢績效比較圖 ...63

圖 5- 6 建立索引後之經過時間查詢績效比較圖 ...66

圖 5- 7 建立索引後之邏輯讀取查詢績效比較圖 ...66

圖 5- 8 建立索引後之實體讀取查詢績效比較圖 ...66

圖 5- 9 建立索引後之讀取前讀取查詢績效比較圖 ...66

圖 5- 10 建立索引後之經過時間查詢績效差異影響比較圖 ...67

圖 5- 11 建立索引後之邏輯讀取查詢績效差異影響比較圖 ...67

圖 5- 12 建立索引後之實體讀取查詢績效差異影響比較圖 ...67

圖 5- 13 建立索引後之讀取前讀取查詢績效差異影響比較圖 ...67

第一章 緒 論

第一節 簡介

真實世界中所產生的資料(data)是非常龐大且複雜的，資料庫可以儲存龐大 的資料，資料庫技術的發展確實幫人類解決了儲存(store)與管理(management)的 問題。不過隨著文明不斷進步，真實世界中的需求越來越複雜，所以新的研究或 者是技術不斷產生。以本論文的研究而言，產業競爭企業多元化經營，如何將有 限資源效用最大化是企業所重視的課題，這關係著成本(cost)。就資料庫的角度 來看，除了要能夠滿足完整儲存真實世界所產生資料的條件之外，一個好的綱要 設計能使系統效能佳、彈性(以滿足多元化)、可擴充性且容易維護。

傳統的資料表綱要(Schema)設計方式是為水平式設計，但由於此種設計方式 若要滿足彈性與可擴充性的條件是有困難的，因此新的設計概念－垂直式設計被 發表出來。無論是水平或者是垂直式設計，它們都是為了滿足真實世界的需求而 抽象化的概念，都有其優劣，但符合企業的需求才是最重要的。

第二節 研究背景與動機

中磊電子股份有限公司創立於西元 1992 年，自成立之初即定位為專業網通 代工廠，秉持創新、服務以及確實的執行力之精神，致力於網通軟、硬體產品整 合服務與網路通訊協定(IP Protocol) 等核心技術之研發。中磊營運總部設立於台 灣台北，全球營運據點包括北美、歐洲以及亞太地區，2008 年合併營業額總計 為新台幣 85.35 億元 (約美金二億五千九百萬元) ，現已成為世界級無線寬頻設 備領導廠商。

中磊憑藉多年來累積之網通產品整合實力，掌握網路通訊產業的關鍵技術與 市場脈動，主要產品與服務包括：無線寬頻閘道器、無線寬頻路由器、網通整合 型 IAD 產品(Integrated Access Devices)、Cable 寬頻相關產品、網路安全監控設備

(IP Camera)、印表機列印伺服器(Print Server)以及網路語音產品(VoIP Phone)等，

目前皆居市場領導地位，客戶遍佈國際一線網通大廠。(Sercomm, 2009)

在傳統上，資料庫綱要大都是採用水平式設計。水平式綱要的主要特點就是 一個實體屬性就需要對應一個資料表欄位。換言之，當屬性需要變動的時候(例 如增加或減少屬性)，資料表綱要也需要隨之變動，故不適宜多變的屬性。另外 在水平式設計中會視需要增加資料表，否則若所有的屬性都存在同一資料表的時 候，就會形成寬資料表。

例如，生產線接獲一批無線寬頻路由器生產工單，透過工單號碼可以得知產 品的料號，再透過產品料號可以得知產品的產測路徑(rouing)，其中包含生產所 需要的產測程式資訊。每一支產測程式有不同的測試項目，依照水平式設計，每 一個測試項目都需要一個欄位。接著開始測試該產品是否為良品，PcbaNo 為產 品的製造序號，Domain 為產品的出貨國別，FwVer 為產品的韌體版本(firmware version)，Result 為產品的測試結果(Pass / Fail)，路由器產品測試資料，記錄在資 料庫水平式綱要的橫式表示架構。如圖 1-1 所示，一支產測程式對應一個資料表，

圖中 TestRecord、MAC_Assign 與 Download 為儲存生產過程所產生的產測紀錄，

而 MAC_Assign 與 Download 亦為產測程式名稱，資料表中的欄位都是為了滿足 實體屬性而設計。(為便於舉例，僅列出 Mac_Assign 與 Download 產測程式，實 際在生產時所用的程式不只這兩支。)

圖 1- 1 水平式綱要示意圖

表 1- 1 水平式綱要查詢結果

PcbaNo Domain FwVER Result S1.123 USA a.bin Pass S1.123 US b.bin Pass S1.123 Japan c.bin Fail S1.123 TW d.bin Pass S1.123 TW d.bin Pass

變更資料庫綱要設計將水平式綱要改為富有彈性的垂直式綱要。不同於水平 式綱要，垂直式綱要是以 data 的型式存放 metadata(意即 metadata 即為 tuple)，故 不需要像水平式綱要一個屬性就需要對應一個欄位，綱要的彈性自然就高了。所 以假使實體屬性有變動，資料表綱要並不需要隨之變動。圖 1-2 為路由器產品產 測紀錄儲存在資料庫的垂直式綱要表示方式，圖中的製程結果為垂直式設計，

TestPrgID 記錄程式編號；TestItemID 記錄測試項目編號；Value 則記錄測試值，

無論產測程式為何、測試項目的數量有多少，一個資料表就足以滿足實體儲存的 需要。

圖 1- 2 垂直式綱要示意圖

表 1- 2 垂直式綱要查詢結果

PcbaNo PrgID ItemID Value S1.123 MAS Domain USA S1.123 MAS FwVer a.bin S1.123 MAS Result Pass S1.123 DL Domain US S1.123 DL FwVer b.bin S1.123 DL Result Pass

本論文以中磊電子為研究的對象企業，隨著企業產品的多樣化、功能強大以 及功能複雜，在生產製程的設計上也隨著多變而彈性。依照原本企業(如圖 1-1 所示)的綱要設計已經不敷使用，(原因是新的產測程式不斷開發都需要資料表去 對應；產測程式的進版測試項目增多則資料表也需要增加屬性)，因此企業引進 一套資料庫綱要。不過，該綱要只有儲存測試的結果，卻沒有設計產測紀錄的儲 存。企業為了將產測紀錄保存下來，採用一筆產測紀錄即一個檔案的型式。新的

綱要導入之後，隨著產測紀錄逐漸增多，資料佔用龐大的磁碟空間，資料的保存 與管理也變得相當棘手，且當使用者需要測試資料的時候，電腦需要耗費大量運 算與時間。而從資料庫的角度來看，如何儲存如此彈性的製程生產紀錄(record) 而且又要擁有令人滿意的效能，即是本論文研究探討的議題。

第三節 研究目的

網路寬頻通訊的技術發展已久，在應用上也相當廣泛，舉凡無線寬頻閘道 器、無線寬頻路由器、網通整合型 IAD 產品(Integrated Access Devices)、Cable 寬頻相關產品、網路安全監控設備(IP Camera)、印表機列印伺服器(Print Server) 以及網路語音產品(VoIP Phone)等。由於本研究對象企業逐漸達到一線廠規模，

礙於產品多樣化(實體更多)、功能更強大(屬性更多)、製程更趨於彈性(屬性變動 大)等因素，採用一個程式對應一個資料表的水平式資料庫綱要設計已漸漸無法 滿足這樣的資料儲存需求；以一筆產測紀錄即一個檔案的型式儲存資料造成日後 保存與管理不易、查詢困難、大量佔用磁碟空間以及運算效能不佳等問題。而垂 直式綱要的設計已有許多學者探討並且有研究發表，證明垂直式設計確實符合彈 性可以滿足多變屬性下的資料儲存需求，但是對於資料庫效能的影響只有少數的 研究，且研究是自行建立少量的資料筆數去做效能評估，而缺乏已經有在企業實 際運作的數據來證明。

在本論文的研究中，是以中磊電子的真實案例，將企業原本的資料庫綱要 設計經過一再的討論與參考專家的意見，分別設計水平式、垂直式與水平垂直混 合式綱要儲存產測紀錄的資料庫設計，並訪談企業最關心的資訊結合日常的查詢 作業，設計 26 道 SQL 查詢命令在這三種綱要中運行，觀察耗費之系統成本作效 能評估，以經過時間(Elapsed Time)與磁碟 I/O 成本(Disk I/O Cost)為評估指標。

第四節 研究範圍

本研究是以網路寬頻通訊業為例，依照研究對象企業之資料庫綱要以及生 產模式與生產製程，設計水平式、垂直式與水平垂直混合式資料庫綱要。研究的 範圍為經由設計的 26 道查詢命令在這三種不同的資料庫綱要運行中，觀察費耗 系統成本的變化作效能評估。本研究有下列幾項限制條件：

1. 不考慮 INSERT、DELETE、UPDATE 等指令對效能的變化。

2. 假設實際工單的生產測試路徑(Routing)與資料庫定義的產品測試路徑 是相同的。

3. 為使資料單純化不將維修與重工程序(Repair and Rework Procedures)。

納入研究範圍。

4. 假設每一道查詢命令的權重都是相等的。

第五節 論文架構

本論文的架構介紹如下：

第二章『文獻探討』

本章從學界的研究作探討，分為六節：在第一節中介紹水平式綱要以及說明 其問題；第二節將介紹垂直式綱要與優缺點；在第三節中比較水平與垂直式綱 要；第四節介紹關於此議題的相關研究；第五節介紹業界彈性綱要在資料庫是如 何設計；第六節說明本研究效能評估的方法。

第三章『無線網路產品生產製程』

本章介紹無線網路的相關資訊，分為四節：在第一節中說明無線網路概念；

第二節說明產品分類與用途介紹；第三節介紹無線網路產品製程；第四節則承前 一節更詳盡的介紹產品的生產流程(著重在成品組裝段)。

第四章『效能評估設計』

效能評估的設計，分為三節：在第一節中說明實驗的三種資料庫綱要的設計 概念；第二節說明實驗查詢題目的設計；第三節說明實驗環境與樣本。

第五章『效能評估結果與分析』

未建索引與建立索引之後的效能評估，分為五節：在第一節中說明實驗的方 法與如何進行；第二節說明未建索引的實驗結果；第三節說明建立索引之後的實 驗結果；第四節分析實驗數據；第五節作實驗總結。

第六章『結論與建議』

本章將對研究作結論並給予未來延續本研究者之建議。

第二章 文獻探討

對 使 用 者 而 言 ， 資 料 庫 系 統 提 供 了 一 個 抽 象 化 的 資 料 表 示 方 式 (Representation Realism)，因此透過此一資料表示方式使用者在擷取或維護資料 庫中的資料時，無需處理實體(Physical)上的細節。因此，資料庫中的綱要設計方 式，對於所耗費的系統成本(執行效能)就有直接的影響。在資料庫學界的研究議 題中，學者 Agrawal 等人(2001)為了處理將近 5000 個屬性的稀疏資料(Sparse Data)，提出將關聯式資料庫系統中的資料表綱要(Schema)，從傳統的水平式 (Horizontal) 關聯資料表綱要調整成垂直式(Vertical) 關聯資料表綱要。為了便於 文章的敘述，我們簡稱水平式關聯資料表綱要為水平式綱要，垂直式關聯資料表 綱要為垂直式綱要。而此一議題在近三年持續受到資料庫學界的討論(Acharya et al., 2008a; 2008b; Chu et al., 2007b; Beckmann et al., 2006 )。然而，這些討論多集 中在查詢敘述撰寫 (Beckmann et al., 2006)、資料儲存結構與與索引設計等 (Acharya et al., 2008a; 2008b; Chu et al., 2007b)系統面上的議題。就我們能力範圍 所及，未曾見過有研究去探討資料表從水平式綱要調整成垂直式綱要之後，對於 實際在應用層面上造成執行效能的影響進行討論。本研究的議題主要就是在探討 不同綱要設計在實際應用層面上對執行效能(Execution Performance)的影響。

第一節 水平式綱要

1. 引言

水平式綱要是在資料庫中一種非常常見的設計方式，此種設計方式直覺而且 容易設計。它的特性是所有可能用來描述實體屬性都包含在該資料表的欄位 (columns)中如表 2-1 所示。然而這樣的設計可能會有下列問題存在：

表 2- 1 水平式綱要

UID PCBASN WoNo PartNo PdtName MAC PdtSn FwVer FwName Domain Throu ghput … 1 1.3T00001 A0001 0AA Router 00A00B SN0001 1F00 Value USA NULL Value 2 1.4T00110 A0002 0AB ADSL 00A002 SN0002 1A01 Value Europe 22.555 NULL 3 1.2T01789 E0005 0AC Cable 00B003 SN0900 1A03 Value Japan NULL Value 4 1.1T04388 B0003 0BB WNIC 00C004 SN0768 1B03 Value Taiwan NULL NULL 5 1.5T02345 F0007 0CC NAS 00D005 SN0366 1B04 Value USA 21.888 NULL

(1) 當屬性過多時會形成一個寬(Wide)資料表

就在業界的實際運作經驗，資料庫綱要不可能是不會變動的，乃是會隨著實 體屬性的改變(例如新產品開發、產品進版、功能改良等、生產製程)而改變。當 實體屬性改變就必須更改資料表綱要，若原資料表的屬性無法描述實體的變動 時，即須新增欄位以滿足完整描述實體屬性改變的事件。當屬性增多欄位也就越 多，即形成一個寬的資料表。在後面的章節中將說明寬資料表所造成的問題。

(2) 寬資料表可能形成稀疏資料集(Sparse Data Sets)

由於每種實體(例如產品)包含的屬性會因實體特性(property)而有所不同，而 每種實體並不需要用到寬資料表中的所有欄位來描述實體屬性，因此這會造成資 料表的儲存格(cell)存有 Null 值的情況發生，而當資料表的 Null 值存在過多時就 形成了稀疏資料集。在後面的章節中將說明稀疏資料集所造成的問題。

(3) 增加維護成本

隨著實體特性的改變(例如產品不斷推陳出新)，資料表綱要就必需不斷的更 新與維護(例如新增資料表欄位、更改欄位屬性等)，資料表綱要一旦改變，在大 部分的情況下需要修改應用程式(applications)，這樣的大工程都將付出大量的工 時、效率的浪費以及昂貴的人工成本。

2. 水平式綱要的問題

(1) 寬的綱要(Wide Schema)

學者 Abadi(2007)指出，水平式綱要當屬性非常多的時候，可能會造成效能 上的問題。例如，有一個電子商務市集含有 1000 家製造廠商，每一家廠商至少 有 500 項產品分類，每一項分類有 4000 種產品，故總共有 2,000,000,000 種可能 (parts)，那麼不難想像排序一個具有 4000 個屬性的寬資料表是一件多麼恐怖的事

情。而當使用者查詢(query)這個寬資料表時，業界經驗告訴我們使用者所利用到 的屬性常常僅佔有所有屬性中少少的百分比。另外，從磁碟讀取一筆資料時，其 所佔的 block 數遠大於一個屬性所佔的 block。再者如果只是需要從中讀取一個 屬性在水平式綱要的設計之下勢必連同旁邊周圍的卻用不到的屬性要一併讀進 來，便造成磁碟頻寬(disk bandwidth)的浪費。

(2) 稀疏資料集

學者 Chu 等人(2007a)指出，典型的稀疏資料集有多到甚至上千個屬性，但 大部分為非 Null 值在所有屬性中僅佔很少的百分比。要從某資料表的資料集(data sets)中判別是否為稀疏資料集可從兩個特徵(如表 2-2)：

1)稀疏資料集有大量的屬性

2)在所有屬性中大多數的值是屬於 Null

表 2- 2 稀疏資料集

稀疏資料集會造成索引(Index)的建立以及整個資料表佔用很大的儲存空 間，並且 Null 值會造成空間上的浪費。儘管業界有一些方法途徑可廣泛的應用 在稀疏資料的處理與管控(handle)，但卻沒有令人滿意的完美技術。由於水平式 綱要直覺而且容易設計，在一般正常(normal)的情況下如果實體屬性變動不大還 是最佳的選擇。缺點是一旦實體特性改變就必需更改資料表綱要且甚至極有可能 要修改程式，若要在最短時間內完成修改並上線，那麼擴充資料表的欄位是在最 快的方式了。但是若產品屬性變動頻繁(例如多樣化的產品)，在水平式綱要設計 的方式之下，只能一味的增加屬性欄位，這樣的方式結果就如前面所述會造成浪

費磁碟空間以及高度不佳的效能。要解決這樣的問題有一個折衷的方式那就是採 用垂直式綱要設計的資料表，它排除了 Null 值的問題且資料表屬性不多故不會 形成稀疏資料集以及寬資料表。因此，垂直式綱要對於上述的問題開啟更廣泛應 用的可能性，因為它突破了在寬資料表的限制，改變資料表綱要對垂直式綱要而 言反而是多餘的工程(task)。在第二節中將說明垂直式綱要。

第二節 垂直式綱要

1. 引言

除了 Agrawal 等(2001)的論文外，垂直式綱要的議題在近三年持續受到學界 (Chu et al., 2007b; Beckmann et al., 2006)與業界(Acharya et al., 2008a; 2008b)的討 論。學者 Agrawal 等人(2001)提出可將資料自垂直式資料表中取出然後以水平式 資料表展現的關聯式代數，Agrawal 等人同時也對這些代數式相對應 SQL 敘述的 語法提出建議。學者 Beckmann 等人(2006)則整理出在垂直式資料表擷取資料 SQL 敘述的一般式，同時也提出使用解釋格式(Interpreted format) 的來儲存垂直 式資料表的觀點。學者 Chu 等(2007a)則提出將稀疏資料儲存至多個資料表的限 制，並提出如何使用一個垂直式資料表儲存稀疏資料的建議。學者 Acharya 等 (2008b)則對儲存垂直式資料表的檔案結構與索引設計進行討論。

學者 Abadi(2007)提到垂直式導向設計(vertical-oriented)資料庫不同於水平式 綱要，垂直式綱要雖然也是將所有實體屬性描述全部儲存在一個資料表中且每個 實體屬性是分開的，卻又是以像連續的資料一樣儲存在資料表中(如表 2-3)，一 個實體有多少屬性就會在這個資料表存在有多少筆的資料。(水平式綱要乃是各 個屬性值儲存在同一列紀錄(tuple)。)

表 2- 3 垂直式綱要 UID Attr Name Value

1 PcbaSn 1.3T00001

1 WoNo A0001

1 PartNo 0AA

1 PdtName Router

1 MAC 00A00B

1 PdtSn SN001

1 FwVer 1F00

1 FwName Value

1 Doamin USA

1 … Value

2 PcbaSn 1.4T00110

2 WoNo A0002

2 PartNo 0AB

2 PdtName ADSL

2 MAC 00A002

2 PdtSn SN0002

2 FwVer 1A01

2 FwName Value 2 Domain Europe 2 Throughput 22.555

2 … Value

…

5 PcbaSn 1.5T02345

5 WoNo F0007

5 PartNo 0CC

5 … Value

對於垂直式綱要的設計有以下的優點分述如下：

2. 優點

(1)增進磁碟頻寬的利用率

在垂直式綱要設計中，只需從磁碟(或記憶體)讀取查詢所需要的屬性；而在 水平式綱要設計中，縱使只需要一個屬性，周圍的屬性也需自該屬性一併讀取，

資料才可以被存取。

(2)增進資料密度(compression)

資料是一起存放在相同的屬性領域(domain)以增加局部性(locality)與壓縮率 (compress ratio 尤其若該屬性有經過排序的時候)，也可以進一步降低資料傳送時 的頻寬。

(3)降低資料表綱要維護成本

在水平式綱要設計中，當實體特性改變時若資料表屬性無法完整描述實體屬

性，則必須修改資料表綱要，然而在垂直式綱要設計則無此問題。

(4)降低應用端程式維護成本

承(3)在水平式綱要設計中，資料表綱要一旦改變，在大部分的情況下應用 端的程式也必須修改(包括新增、修改、刪除、查詢與維護模組)，造成昂貴的人 工成本，而在垂直式綱要設計則無此問題。

(5)滿足實體特性多變的彈性

實體(例如產品)多樣化或者生產製程彈性等多變的特性在水平式綱要設計 中需不斷的維護資料表綱要，然而在垂直式綱要設計中可以滿足多變的彈性。

(6)增進快取的局部性(cache locality)

快取記憶體的空間需大於一筆紀錄所有屬性(tuple attributes)的總和，在水平 式綱要設計中快取記憶體需包含所有的屬性但不見得所有屬性都是用得到的，這 樣會造成空間浪費以及降低快取的擊中率(hit rates)，而在垂直式綱要設計則無此 問題。

雖然垂直式綱要有上述的優點，但卻非完美的設計，茲將缺點分述如下：

3. 缺點

(1)增加磁碟搜尋時間(disk seek time)

垂直式綱要的設計是將屬性當成資料存放，故磁碟在搜尋讀取 block 時，就 如同並行讀取複合欄位(multiple columns)一樣，才能將一筆紀錄讀完。然而如果 磁碟已經預先讀取(pre-fetches)以預備使用，那麼就可以維持較低的 I/O 成本。

(2)增加插入(inserts)的成本

承(1)垂直式綱要的設計是將屬性當成資料(data)存放，故若有 100 個屬性就 會至少有 100 筆資料。在執行插入命令(insert queries)時需要將每個屬性存放在獨 自的 tuple 位置為每個屬性 insert tuple，所以當屬性的數量多時，就會造成 insert 的執行效能不佳。

(3)增加查詢績效(query performance)的成本

同前面所述，當屬性是以資料型態存放時，從關聯式資料庫的特性資料表沒 有欄位可以 join，所以在查詢命令中就需要以較多的 and、or 等邏輯運算元來完 成查詢的任務，難度較高容易寫錯且會形成複雜的查詢命令，那麼在執行複雜的 查詢時往往要忍受不佳的查詢效能(poor query performance)。

(4)漏失屬性型態

在垂直式綱要設計中所有的值需以 VARCHARS 型態填入欄位才能支援所 有需求的資料屬性，儘管它具有容易擴充延展的特性設計，但卻付上漏失資料屬 性的代價。(Agrawal et al., 2001)

第三節 水平式 vs.垂直式

綜合前面所述，不同特質的實體可以儲存在相同的水平式寬資料表(即一個 屬性對應一個欄位)。業界一般情況會選擇使用水平式資料表是因為

. 查詢時只要參考一個資料表(擁有較垂直式資料表好的效能)。

. 增加一個屬性(property)需要一個欄位(直覺且容易設計)。

. 更新資料時只要在一個資料表即可完成。

但這樣的設計卻可能帶來很多欄位的值是稀疏的且查詢的結果集也是稀疏 的。不過就一般而言，若實體屬性變動不大以及考慮到未來的擴充性(例如保留 欄位)，這樣的設計方式也未嘗不可。若因 Null 值造成小部分的稀疏資料集，就 總體而言是可以被接受的。

不過，若變動太大，為了要符合運作的環境，那麼就必需用垂直式綱要的解 決方法(solutions)來管控 Null 值以避免稀疏資料集所造成的空間浪費並且也可以 免於維護資料表綱要所造成的人工成本，尤其是在 OLTP 的環境。最後且最重要 的就是垂直式綱要只需一個屬性群(property bag)以及一個資料表就可以真實的 描述實體特性，並且支援(support)擴充性與彈性。(Acharya et al., 2008a)

資料模式一般可分成概念資料模式與邏輯資料模式，因此有關資料模式對使

用者查詢績效的影響的研究，可分為概念性資料模式彼此之間的比較研究(Chan and Teo, 2005; Debreceny and Bowen; 2005)、邏輯性資料模型彼此之間的比較研 究(Borthick et al., 2001)，以及概念性資料模式與邏輯性資料模型之間的比較研究 (Allen and March, 2006; Chan et al., 1993; Siau et al., 2004; Jih et al., 1989)。

1. 資料表示方式

表 2- 4 水平式儲存

(資料來源 Agrawal et al., 2001)

ID 為辨識子，ATTR 為屬性名稱，VAL 為屬性值。我們將表 2-4 中的水平式

表 2- 5 垂直式儲存

(資料來源 Agrawal et al., 2001)

2. 資料表示方式對查詢的影響

根據學者 Ogden(1986)提出認知模式(Cognitive Model)，要完成一個查詢敘述 的撰寫，需要經過查詢形塑(Formulation)、查詢轉換(Translation)與查詢撰寫 (Writing)三個階段。在查詢形塑階段中使用者將決定他需要哪些資料。在查詢轉 換階段中，使用者根據查詢形塑的結果，決定如何利用當前的資料表示方式(資 料模型、資料結構)搭配合適的資料庫操作(Operation)以滿足查詢形塑的需求。查 詢撰寫則是使用資料庫所提供的查詢語言(SQL)將查詢轉換階段的想法實作出 來。根據學者 Odgen(1986)的結果，完成一個查詢敘述時，在查詢轉換階段，資

料表示方式對使用者需要使用哪些操作將有重要的影響，而使用者所使用的操作 對其查詢績效亦有一定的影響。例如，學者 Borthick 等人(2001)的研究顯示使用 者根據 1NF 綱要撰寫的查詢敘述其正確性比根據 3NF 綱要撰寫的查詢敘述為 高。其原因為在 3NF 綱要的表格上撰寫的查詢相對於 1NF 綱要可能需要較多的 合併運算，而較多的合併運算可能導致較差的查詢績效(Topi et al., 2005)。

在本研究中，使用者根據垂直式綱要所寫的查詢敘述相較於根據水平式綱要 所寫的查詢敘述，可能使用較多的合併運算。例如，我們想要在表 2-4 中的資料 表 H 中找出屬性 A3 等於 b 的 A4 屬性值。其 SQL 敘述為

SELECT A4 FROM H

WHERE A3='b';

同樣的查詢若在表 2-5 中的資料表 V 上查詢，其 SQL 敘述為 SELECT V1.ATTR, V1.VALUE

FROM V V1, V V2 WHERE V1.ID = V2.ID AND V1.ATTR='A4' AND V2.ATTR = 'A3' AND V2.VALUE = 'b';

根據資料表 V 所寫的查詢需要使用合併運算，而根據資料表 H 所寫的查詢 則沒有使用合併運算的必要。

學者 Chan 等人(1997)與學者 Topi 等人(2005)提出在查詢敘述中如果使用愈 多的合併運算，則查詢績效可能愈差。在本研究中希望透過三種不同綱要的設計 驗證可能需要使用較多合併運算才能完成查詢敘述的垂直式綱要，在經過改良 (improve)之後可以有媲美可能使用較少合併運算的水平式綱要的查詢績效。

3. 正規化影響查詢複雜度與績效

在 A.F. Borthick et al. (2001)指出，資料庫依規則轉換正規化時，第一正規 化語義的錯誤會少於未正規化或第三正規化，而第三正規化語義的錯誤會少於未 正規化。

設計出新的資料庫綱要時，我們首先要將資料庫綱要正規化，一般來說，資 料分別存放在多個關聯表時，執行效率會比放在少數幾個關聯表來得差。

越高的正規化會分割成更多小型的表格和屬性，資料庫綱要會隨著結構的特性而 細微改變，此時關聯表會分割表格的數量，同時關聯表格也會增加重覆的資料和 屬性，造成資料的重覆性，所以，我們利用功能相依性避免發生資料庫產生重覆 的現象。

使用者在查詢時，因為系統所使用的合併運算越多，而合併運算是一個很花 時間的運算動作，所以也會增加查詢複雜，越高的正規化會產生越複雜的查詢。

除了做正規化之外，我們還要考慮到資料的更新異常現象以及查詢效率，我們稱 為反正規化。在本研究中不同的綱要設計也經過正規化與反正規化的過程，期望 能達到較理想的效能。至於在水平式綱要與垂直式綱要之間怎麼權衡至今仍在學 界與業界探討研究(explore)中。

第四節 彈性(Flexible)綱要設計

學者 Acharya 等人(2008a)在研究中以內容管理系統(content management system)為例指出它是由不同異質型態實體的集合。像這樣的應用兼具擴充性與高 效率而且可以將不同異質型態的實體實現存放在單一寬資料表的目的。此外有一 種邏輯的子資料表(subtable)概念建構在整體資料表裡面，項目列表請參考表 2-6 的範本資料表，內容包含了系統使用者的項目清單。

表 2- 6 與系統應用程式協同合作的彈性綱要範本

Root Offer

Owner ListID CollID Ordinol Content

Type Created Author File

Size Price Tax Rate

Date

Sent Name Phone Type

Phone

Number Desc Size Katie 1 1 1 Document 2007/10/2 Rick 30k

Bob 2 2 1 Invoice 2006/1/12 Bob 10k 100 9%

Rob 3 3 1 Offer 2003/5/2 Paul 110k 2004/1/12

Rob 3 4 1 Offer 2002/1/5 98k 2003/10/4

Rick 4 5 1 Picture 2007/11/3 ML

Rick 5 6 1 Contact 2006/7/4 Tom Home 206

Rick 5 6 2 Contact Work 425

Rick 5 6 3 Contact Cell 333

Rick 6 7 1 Picture 2004/11/2 Pans L

Document Invoice Contact Picture

(資料來源 Acharya et al., 2008a)

表中的內容為系統資料表內容雛型，上方的大括弧是表示每一種內容型態的 屬性(property)，粗線框的部分是為識別多值屬性。內容屬性的關係層級如圖2-1。

圖 2- 1 內容屬性層級片段

(資料來源 Acharya et al., 2008a)

如表 2-6 欄位可以允許 Null 值，在某些情況下內容型態可能是多值屬性，例 如電話的類型與電話號碼。在寬資料表中提供一個便利的方式去管控每個屬性無 論是否有經過排序，那就是每個實體以複合列(multiple rows)與相同的 CollID 綁 在一起明確指定。如果屬性排序是有意義的，那麼可以附加一個欄位序列。例如 表 2-6 中的 CollID 即為附加的欄位序列。在這個範例中，聯絡人種類裡有兩種多 值屬性—電話類型與電話號碼，它們是有次序的集合，這兩個屬性是必須雙雙緊 密結合在一起的複合屬性型態。例如一個有三個不同電話的範本實體編號 CollID=6 的集合屬於 ListID=5 的成員。

當一個採用子資料表的概念應用在上述方法中，是可以將原本表達 metadata 的內容移位到 data。子資料表是一種特殊的設計方式，它是一種隱藏式的資料表 包在一個公開的資料表中，故沒有名稱指明(意即沒有資料表名稱)且不被欄位名

稱所斷定它就是子資料表。例如表 2-6 中，大括弧中的 contact 就是一個子資料 表 ， 它 包 在一 個 大資料 表 中 ， 以三 個 欄位存 在 (Name、Phone Type、Phone Number)，而且特別的它是以垂直式綱要設計存在，因為 Phone Type 可以視為屬 性；Phone Number 可以視為值。

子資料表的設計方式跳脫關聯式 metadata 的宣告(亦即一個屬性必須要建立 一個欄位)，利於簡單的開發應用以及管理，尤其預期一些資料表需動態產生或 者它們有層級關係。例如在不同層級可以直接用很直覺的方法去下查詢命令，且 只需在單一資料表就可以完成而可免於 union 以及 join。從 metadata 移位到 data 提供彈性且帶來高效益，且 metadata 可以被相關的查詢執行利用。

第五節 業界的彈性綱要設計方式

前面的章節中已經說明到彈性綱要可以採用垂直式綱要以及子資料表的概 念去設計，而實際在業界又是怎麼實現彈性的目的？本研究實際訪問了某半導體 公司，該公司是以 IC 封測為主，客戶不乏知名大廠，每一家客戶的規範(規格、

製程、產測程式甚至所用的生產設備)都不盡相同，且公司早期也是採用水平式 綱要，企業規模發展到最後無法滿足彈性且多樣化的生產製程所以改採用工研院 的設計(即垂直式綱要)。

在前面的章節已經說明到垂直式綱要可能會帶來效能上的問題。另外，在真 實世界中有眾多的實體，在第二節中所述的垂直式資料表以三個欄位的設計不太 可能完整描述真實世界裡發生的所有實體，必須再增加資料表欄位才可以完整呈 現。如圖 2-2，在本研究中的對象企業是屬於多樣化產品與彈性生產製程的生態，

故產測程式、測試項目與測試值是多變且彈性的。TestPrgID(產測程式 ID)、

TestItemID(測試項目 ID)以及 Value(測試值)會因產品與製程的不同而變化，故採 以垂直式綱要的設計，但是只有此三個屬性並無法完整描述企業行為的所有實 體，故需要再加入其它屬性才能完整表達真實世界所發生的事件。

圖 2- 2 垂直式綱要設計片段

由於垂直式綱要可能帶來效能上的問題，以半導體封測廠快速與龐大的資料 成長而言，只採垂直式綱要的設計將帶來效能災難，故該公司混合了水平式綱要 的設計，新增一個水平式資料表儲存垂直式資料表中固定不變的屬性，並附加幾 項彙總欄位，藉由這些彙總欄位，當使用者因為某些目的而需要統計時，可以直 接以 SQL 命令

Select [彙總欄位] from [資料表名稱]取得統計值，而不需要以 COUNT 等函數計算，如此可以增加資料庫的效能。

另外，因水平式資料表是儲存垂直式資料表中固定不變的屬性，再加上垂直 式資料表的欄位數並不多，故不會存在寬資料表以及稀疏資料集的特性。依照本 研究的對象企業，我們修改了資料庫綱要設計，混合水平式與垂直式綱要資料 表，我們稱水平式資料表為彙總資料表(Summary Table)，如圖 2-3 中所示 Test Result 即為彙總資料表。

Test Result(測試結果)

PcbaNo {FK}

ReTest

TestPrgID {FK}

TestStationID {FK}

WoNo {FK}

Result ProductName

Uid {PK}

TestRecord(測試記錄) Vertical Design

Uid {PK}

WoNo TestStationID Tester Result Value

TestPrgID {FK}

TestItemID {FK}

PcbaNo {FK}

ErrorCode Duration CDT

圖 2- 3 水平垂直混合式綱要設計片段

綱要的內容在第四章將有完整的說明。

第六節 效能評估的方法

在本節中並不說明如何效能調教，而是介紹效能評估的方法。一個查詢需要 的 CPU、IO 資源越多，查詢執行的速度就越慢。因此，調教效能的方式除了以 一種使用更少的 CPU、IO 資源的方式重寫查詢命令，另一種方式就是調教資料 庫綱要。調教效能的目的是盡可能的耗費更少的伺服器資源，而不單單只是查詢 耗費時間最短，尚需考慮磁碟 I/O 成本，尤其是在資源利用不斷變化的伺服器上 更是如此。

一 般 而 言 評 估 資 料 庫 效 能 有 兩 大 指 標 ， 一 為 查 詢 耗 費 的 時 間 (Elapsed Time)；另一為磁碟 I/O 成本(Disk I/O Cost)。本研究是採用 Microsoft SQL Server 2005 做 為 不 同 綱 要 設 計 的 實 驗 測 試 平 台 ， 在 此 資 料 庫 管 理 系 統 (Database Management System 縮寫為 DBMS)中提供兩個指令可以觀察上述兩大指標以用 於效能評估，這兩個指令分別為 SET STATISTICS IO ON 以及 SET STATISTICS TIME ON。

通常在 DBMS 中有 buffer(或稱 cache)的設計，目的是儲存先前的已經執行

過的查詢計畫，若下一次又再執行相同的查詢時可以不需要再從磁碟拿取，故可 以提昇整體效能。但本研究的評估基準是必須在 buffer 沒有預先儲存查詢計畫的 條 件 下 才 能 成 立 ， 故 在 執 行 上 述 兩 個 指 令 之 前 必 須 先 執 行 DBCC DROPCLEANBUFFERS 以及 DBCC FREEPROCCACHE，這二條指令將清空 SQL Server 的 buffer，這樣才能夠使每次執行查詢時能在同一個基準點上，否則每次 執行查詢得到的結果就不具有可比較性了(Chen S., 2004)。

Transact-SQL 命令範例如下：

DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS SET STATISTICS IO ON SET STATISTICS TIME ON

{ … … }

{ Query Commands }

{ … … }

SET STATISTICS TIME OFF SET STATISTICS IO OFF 執行結果：

DBCC 的執行已經完成。如果 DBCC 印出錯誤訊息，請連絡您的系統管理員。

DBCC 的執行已經完成。如果 DBCC 印出錯誤訊息，請連絡您的系統管理員。

---

0.11811023622047244 (query result sets) (1 個資料列受到影響)

資料表 'TestResult'。掃描計數 4，邏輯讀取 3462，實體讀取 57，讀取前讀取 37。…○² (Table 'TestResult'. Scan count 4, logical reads 3462, physical reads 57, read-ahead reads 37) SQL Server 執行次數(SQL Server Execution Times):

CPU 時間 = 0 ms，經過時間 = 250 ms。(CPU time = 0 ms, elapsed time = 250 ms. ) …○¹

○¹ 為 SET STATISTICS TIME ON 的效果。

表示執行此次查詢耗費多少 CPU 執行時間和執行查詢時使用多少時間 (elapsed time)。CPU 執行時間是對執行查詢所需要 CPU 資源的一種相對穩定的 測量方法，與 CPU 的忙閒程度沒有關係。但是，每次執行查詢時這個數字也會 有所不同，只是變化的範圍沒有總時間變化大。經過時間是執行查詢所需要的時 間(不計算阻塞或讀數據的時間)，由於伺服器上的負載(loading)是不斷在變化 的，因此這一數據的變化範圍有時會相當地大。

○² 是 SET STATISTICS IO ON 的效果 1. Scan Count

在查詢中涉及到的資料表被查訪的次數。在本範例中，其中 TestResult 資料 表被查訪了 4 次，本查詢命令的範例包括 join，故此一資訊是十分有用的，值越 小代表效能越好。

2. Logical Reads

邏輯讀取，此項目是提供最有用的資訊。在 SQL Server 對任何資料進行運 作前，首先必須把資料讀取到 buffer 中。此外，SQL Server 會從 buffer 中讀取資 料，並把資料讀取到大小為 8K 位元組的頁(page)中。而邏輯讀取乃是指 SQL Server 為得到查詢中的結果而必須從 buffer 讀取的頁數。在執行查詢時，SQL Server 不會讀取比實際需求多或少的資料，因此，當在相同的資料集上執行同一 個查詢，得到的邏輯讀取的數字總是相同的(偶而會不同但差異很小)。所以如果 邏輯讀取值下降，那麼就表示查詢時所使用的伺服器資源減少，效能就有所提 高；反之則效能減低。故在其他條件不變的情況下，查詢所使用的邏輯讀取越少，

其效能就越好速度就越快。

3. Physical Reads

實體讀取。在 SQL Server 開始執行查詢前，首先它要作的就是檢查所需要

的資料是否存在 buffer 中，如果在就從中讀取，如果不在 SQL Server 就會先將 所需要的資料從磁碟讀到 buffer 中。不難想像 SQL Server 在執行實體讀取時比 執行邏輯讀取需要更多的伺服器資源。因此，在理想情況下應當儘量避免實體讀 取操作。值越小表示效能越好；反之則越差。

4. Read-Ahead Reads

讀取前讀取。表示 SQL Server 在執行預讀機制時讀取的實體頁。為了最佳 化性能，SQL Server 在認為它需要的資料之前預先讀取一部分資料，根據 SQL Server 對資料需求預測的準確程度，預讀的資料頁可能有用，也可能沒用。值越 小表示效能越好；反之則越差。

表 2- 7 I/O 輸出項目摘要

Output Item Meaning

Scan Count Number of index or table scans performed.

Logical Reads Number of pages read from the data cache.

Physical Reads Number of pages read from disk.

Read-Ahead Reads Number of pages placed into the cache for the query.

(資料來源 MSDN Library, 2009)

第三章 無線網路產品生產製程

第一節 無線網路概念

區域網路是把分佈在數公里範圍內的不同位置的電腦或網路設備連接在一 起，在網路作業系統的支持下可以相互通訊和資源共享的網路系統。通常網路的 傳輸媒介主要倚賴銅纜或光纖，構成有線區域網路。但有線網路在某些場合要受 到佈線的限制︰佈線、改線工程量大；線路容易損壞；網中的各節點不可移動。

特別是當要把相離較遠的節點連結起來時，鋪設專用通訊線路佈線施工難度之 大，費用、耗時之多，實在是令人生畏。這些問題都對正在迅速擴大的連網需求 形成了嚴重的瓶頸，限制了用戶連網。

無線網路(WLAN：Wireless Local Area Network)就是解決有線網路以上問題 而出現的。無線網路利用電磁波在空氣中發送和接受數據，而無需線纜介質。無 線網路的數據傳輸速率現下已經能夠達到 300Mbps(IEEE802.11n)，傳輸距離可遠 至 20Km 以上(但是要無障礙、無干擾才有可能)。無線連線模式是對有線連線模 式的一種補充和擴展，使網路上的電腦更具有機動性，能快速、方便的解決以有 線模式不易實現的網路連線問題。

與有線網路相比，無線網路具有以下優點︰

1. 安裝便捷

一般在網路建設當中，施工週期最長、對周邊環境影響最大的就是網路佈線 的施工了。在施工過程時，往往需要破牆掘地、穿線架管。而無線網路最大的優 勢就是免去或減少了這部分繁雜的網路佈線的工作，一般只要在安放一個或多個 無線存取橋接器(Access Point)設備就可建立覆蓋整個建築或地區的區域網路。

2. 使用靈活

在有線網路中，網路設備的安放位置受網路節點位置的限制。而一旦無線網 路建設完成後，在無線網路的信號覆蓋區域內任何一個位置都可以接入網路，進

行通訊。

3. 經濟節約

由於有線網路中缺少靈活性，這就要求網路的規劃者儘可能地考慮未來的發 展的需要，而往往導致需要預設大量利用率較低的節點。而一旦網路的發展超出 了設計規劃時的預期，又要花費較多費用進行網路改造。而無線網路可以避免或 減少以上情況的發生。

4. 易於擴充與擴展

無線網路具有多種配置模式，能夠根據實際需要靈活選擇。這樣，無線網路 能夠勝任只有幾個用戶的小型區域網路到上千用戶的大型網路，並且能夠提供像

“漫遊(roaming)”等有線網路無法提供的特性。

由於無線網路具有多方面的優點，其發展十分迅速。在最近幾年裡，無線網 路已經在醫院、商店、工廠和學校等不適合網路佈線的場合得到了廣泛的應用。

第二節 無線網路產品之分類與用途介紹

依照本研究對象企業的主要產品類別有無線寬頻閘道器、無線寬頻路由器、

網通整合型 IAD 產品(Integrated Access Devices)、Cable 寬頻相關產品、網路安全 監控設備(IP Camera)、印表機列印伺服器(Print Server)以及網路語音產品(VoIP Phone)與其它應用項目，其中寬頻路由器為市場上銷售量最大的種類。由於目前 很多家庭設有 ADSL 寬頻上網，申請 ADSL 時電信公司會附上 ADSL Modem，

因此只要加裝寬頻路由器即可達到多台電腦共享上網。由於無線技術的成熟，大 部份的路由產品都內建無線功能，使得使用者無須再忍受網路線的羈絆。列舉主 要的產品種類與用途介紹如下：

1) 無線寬頻閘道器(Access Point)

AP 是 Wireless Access Point 的縮寫，一般我們稱它為無線基地台。如果無線 網路可比作有線網路中的乙太網卡，那麼 AP 就是傳統有線網路中的集線器 (HUB)，也是目前組建小型無線區域網時最常用的設備。AP 相當於一個連接有 線網和無線網的橋樑，其主要作用是將各個無線網路用戶端連接到一起，然後將 無線網路接入乙太網路(這正是 Access Point 名稱的本義)。

目前大多數的無線 AP 都支援多用戶接入、資料加密、多速率發送等功能，

一些產品更提供了完善的無線網路管理功能。對於家庭、辦公室這樣的小範圍無 線區域網而言，一般只需一台無線 AP 即可實現所有電腦的無線連接。

AP 的室內覆蓋範圍一般是 30m～100m，目前不少廠商的 AP 產品可以互聯，

以增加無線區域網路覆蓋面積。也正因為每個 AP 的覆蓋範圍都有一定的限制，

正如手機可以在基地台之間漫遊一樣，無線區域網用戶端也可以在 AP 之間漫遊。

目前市場上的家用型 AP 基本上分為兩大類:單純型 AP 和複合型 AP。複合 型 AP 除了基本的 AP 功能之外，還可能帶有若干 Ethernet Switch、路由、

NAT(Network Address Translation)、DHCP、列印伺服器等功能。

2) 無線寬頻路由器(Broadband Router)

其概念是透過內建的 DHCP(Dynamic Host Configuration Protocol)機制、NAT 以及路由(Routing)功能，將一個 Public IP 轉化成多個 Private IP 分配給多台電腦，

即可達到多台電腦共享上網的目的。

由於無線網路技術成熟再加上無線晶片成本大大降低，故大多數的寬頻路由 器都有內建無線功能。

3) 無線寬頻路由器(ADSL Router)

ADSL，全名 Asymmetric Digital Subscriber Line，譯為非對稱數位式用戶線 路，ADSL 允許在一對雙絞銅線上，在不影響現有 POTS(Plain Old Telephone Service)電話業務的情況下，進行非對稱高速資料傳輸。ADSL 上行速率為 64kbps

～1Mbps，下行傳輸速率 0.25Mbps～12Mbps；傳輸距離在 2.7～5.5 公里。

ADSL 因為上行(從用戶端到電信服務公司方向，如上傳動作)和下行(從電信 服務公司到用戶的方向，如下載動作)頻寬不對稱(即上行和下行的速率不相同) 因此稱為非對稱數位式用戶線路。它採用頻分複用技術把普通的電話線分成了電 話、上行和下行三個相對獨立的通道，從而避免了相互之間的干擾。通常 ADSL 在不影響正常電話通信的情況下可以提供 64Kbps～1Mbps 的上行通道和 0.25～

12Mbps 的下行通道。

ADSL 是一種非同步傳輸模式(Asynchronous Transfer Mode)。

在電信服務公司端，需要將每條開通 ADSL 業務的電話線路連接在數位用戶線路 訪問多工器(DSLAM)上。而在用戶端，用戶需要使用一個 ADSL 終端(因為和傳 統的數據機(Modem)類似，所以也被稱為“魔電”)來連接電話線路。由於 ADSL 使用高頻信號，所以在兩端還都要使用 ADSL 信號分離器將 ADSL 資料信號和 普通音頻電話信號分離出來，避免打電話的時候出現噪音干擾。

通常的 ADSL 終端(即為 ADSL Modem)有一個電話線路 Line-In、一個乙太 網路(RJ45)插孔以及一個連接的 Phone 介面。本研究的對象企業所生產的機種是 複合 ADSL Modem、路由器甚至含無線的功能。

4) 網通整合型 IAD 產品

隨著資訊在網際網路上的傳送量日趨龐大，用戶對於接取網路 (Access Network) 傳輸速度的需求也相對提高，電信業者更加速數位用戶迴路 (DSL) 網 路的建置，以提升資訊的載送頻寬。IAD (Integrated Access Device，整合接取設 備) 便是一項附加 VoDSL (Voice over DSL) 或 VoIP (Voice over Internet Protocol) 功能的整合型接取設備，可以說是一個多工處理器，目的在於將不同的信號，例 如數據、語音與影音等資訊匯集後於網際網路中傳送，置放在用戶端，具有 xDSL 數據機以連接數位用戶迴路 (DSL)，並提供使用者多種服務的裝置。使用者涵蓋 一般的家庭用戶、SOHO 工作者、中小企業、乃至於擁有個體區域網路的大型企

業。雖然使用者規模不一，但是從網路架構的觀點來看功能是大致相同的，均為 透過 IAD 將語音傳送至網際網路，或者再透過語音閘道器 (Voice Gateway) 連接 至傳統第五類 (Class 5) 語音電話交換機進入公眾電話交換網路 (PSTN，Public Switched Telephone Network)，進行電話語音的通訊。總體來說，使用 IAD 架構 網路有以下幾項優點：

1. 使用者不需要改變舊有的使用習慣即可進行網路電話的使用。

2. 簡化複雜的網路架設，如一般的家庭用戶僅需一項設備就可以同時具有網 路電話與連結網際網路的功能。

3. 減少網路電話網路建置的成本，企業用戶無需替換既有的傳統電信網路設 備，如傳統的類比/數位電話、PBX 等，便可將其與連網設備整合。

4. 採用整合式接取設備可以降低企業採購與技術支援的成本，利用業務單一 化來提昇管理效率。(工研院, 2004)

5) 印表機列印伺服器(Print Server)

它是網路上管理列印工作的電腦。列印伺服器接受來自多個不同用戶的列印 工作，並且按序或按預先定義好的優先順序對它們進行列印。列印佇列在記憶體 或磁片上保存列印工作，直到它們準備列印為止。列印佇列也可能管理和工作站 相連網路上的印表機，為滿足用戶的請求，將列印工作送到這些印表機。例如，

一個工作站可能有一台相連的彩色印表機。列印伺服器知道哪些印表機具有這些 特徵，並且將工作發送到合適的工作站和相連的印表機。

不過，就單純在網路上管理列印工作而買一台電腦對企業而言成本實在太 高。以成熟的技術，本研究企業開發出一種掌上型大小的裝置，將管理網路上列 印的工作置入在這種裝置。這種裝置提供一個 RJ45(Ethernet)介面、一個 USB、

一個 Parallel Port(並列埠)甚至包含無線功能。這樣企業或個人用戶只要買這種裝 置就可以達到印表機共享的目的，大大節省設備購置成本。目前該企業還有生產 複合式列印伺服器，比如將列印伺服器的功能與路由器結合。

6) Network Attached Storage

NAS，英文全名為 Network Attached Storage，可譯之為網路附加存取。它被 定義為一種特殊的專用資料儲存伺服器，內嵌系統軟體，可提供跨平臺檔共用功 能。NAS 設備完全以資料為中心，將儲存設備與伺服器徹底分離，集中管理資 料，從而有效釋放頻寬，大大提高了網路整體性能，也可有效降低總擁有成本，

保護用戶投資。

該企業所生產的 NAS 為小型機種，適用於個人、SOHO 或 10 人以下區域網 路模式。

7) 網路安全監控設備(Network Camera Server)

又稱 IP Camera，它是以 TCP/IP 的通訊協定，將影像轉換成網路封包傳送到 用戶端。故只要待 Camera 取得 IP 之後，即可以瀏覽器直接觀看其所傳送之影像 以達到監控的目的。

IP Camera 的應用，使得影像監控技術進入新的世代。首先，網路的數位佈 線代替了傳統的視訊類比佈線，實現了真正的三訊(視訊、音訊頻、資訊)合一，

網路攝影機隨插即用，施工簡便，系統擴充容易；其次，跨區域遠端監控成為可 能，特別是利用 Intranet，影像監控已經沒有距離限制，而且影像清晰，穩定可 靠；再者，影像的存儲、檢索十分安全、方便、可異地儲存，多機備份儲存以及 快速查詢等。

8) Wireless Network Client Card

又稱“Wireless Network Interface Card”，簡稱“WNIC”，是具有無線功能的網 卡。網卡是區域網路之中最基本的元件之一，它是連接電腦與網路的硬體設備。

無論是雙絞線連接、同軸電纜連接、光纖連接或者是無線連接，都必須借助於網 卡才能實現資料的通信。

網卡的主要工作是整理電腦發送網路上的資料，將資料分解為適當大小的封 包之後向網路上發送出去。對於網卡而言，每塊網卡都有一個唯一的網路節點位

址，它是網卡生產廠商在生產時即燒入 ROM (Read Only Memory)，我們把它叫 做 MAC Address，且是全世界獨一無二的。

9) HomePlug

它是採用電源線作為網路資料傳送的媒介(裝置)。HomePlug 電源網路的優 點，在於電源插口在任何地方都可以找得到，安裝的方便度別的無可比擬，它的 成本亦較其他的為低。

利用電源作傳輸亦有一定的障礙，由於電源線上會有不同的阻抗及損耗，令 傳送數據時增加困難，資料在不同的頻率上會有很極端的變化，因而影響傳送。

就算簡單的電源開關動作亦會影響數據傳輸，所以 HomePlug 的技術採用了 FEC (Forward Error Correction)、Interleaving、錯誤偵測及 ARQ (Automatic Repeat Request)來確保透過電源線作資料傳送可以達到一個可靠而穩健的系統。

HomePlug 一般的傳送速度較其他為低，2002 年底時的最高傳送速度只約有 12Mbps，比 802.11b 規格快少許。不過由於技術的突破，克服了瓶頸，現在的傳 送速度理論值可到 200Mbps。

第三節 無線網路產品製程介紹

1. 產品製程簡介

無線網路產品製程主要分為印刷電路板組裝(print circuit board assembly；

PCBA)及成品組裝(product assembly)兩大部分。印刷電路板組裝製程，在業界一 般稱之為 PCBA 製程。PCBA 製程係將電子元件(electrical component)依設計部門 所提出之印刷電路板設計圖(PCB layout)置放於印刷電路板上所指定位置，其製 程中主要包括表面黏著(Surface Mount Technology；SMT)製程、插件(Direct Insertion Process；DIP)製程、PCBA 功能測試(PCBA functional test)製程三大部 分。其中以 SMT 製程為 PCBA 之技術核心，其主要製程為錫膏印刷(solder printing)、元件置放(component placement)、迴焊(re-flow)、內部線路測試(in-circuit

test)及外觀檢驗等；插件製程主要是將 SMT 製程以外之零件，以波焊(wave soldering)方式予以固定於印刷電路板；功能測試則為依機種類型不同，定義各產 品之測試項目及標準，如燒機前測試、燒機測試以及燒機後測試，為 PCBA 之最 重要檢驗製程。成品組裝製程主要是包括成品元件組裝(product assembly)、成品 功能測試(product functional test)兩大部分。成品組裝係將產品所需元件、相關模 組與 PCBA 進行組立的工作，依不同的機種類型會有不同的模組化元件。例如無 線寬頻路由器有外殼(chassis)、無線模組(wireless module)；NAS 有外殼、無線模 組、硬碟(hard drive)、電源供應器(power supply)；網路安全監控攝影機則有外殼、

無線模組、鏡頭模組(lens module)、馬達動件組等等。而成品組裝完成後即進行 相關之成品測試如電氣測試、功能性測試、外觀檢查等，最後則進行成品包裝及 入庫。整個產品的製造流程概要如圖 3-1 所示。

圖 3- 1 無線產品製程流程圖