第四章 效能評估設計
第一節 實驗之資料庫綱要說明
. 生產測試紀錄(Production and Test Record)
此資料表真實記錄產品產測過程的所有資料，包含 PCBA 序號、工單號碼、
產測程式 ID、測試項目、測試值、測試站 ID、測試人員、測試工時與產測 日期等項目。
為滿足符合本研究的探討重點以及避免涉及到該企業商業機密，已將企業原 來的資料庫綱要與資料作修改，在綱要中只保留研究所需的必要屬性，其餘與在 研究中用不到的屬性一律移除。
該企業所引進的新資料庫綱要中沒有儲存產測紀錄的設計，乃是以檔案型式 存在。因此，將產測紀錄檔案儲存到資料庫是本研究的重點項目之一。產測紀錄 檔案格式內容說明如下，括弧內代表屬性名稱：
檔案名稱格式：
WCNO_ISNO_TEST DATETIME.SFC+RESULT
底線為副檔 名，RESULT 為 0 或 1，0 代表 FAIL；1 代表 PASS。本範例檔案名稱：
AT_2.0S72618252_070721100612.SFC1
解釋為 PCBA 序號 2.0S72618252 在產測程式代碼為 AT 的測試時間為 2007/07/21 10:06:12 的測試結 果為 PASS。檔案格式內容：
ISNO:2.0S72618252;(PCBA 序號) WONO:A0523900101;(工單號碼)
MACHINE:A04000D88F705B6;(測試站電腦生產線別+網卡 MAC) WCNO:AT;(產測程式代碼)
OP:21019;(作業人員編號) RESULT:PASS;(測試結果)
DURATION:66.6;(作業耗費工時,單位 秒) TEST_ITEM:(測試項目)
TADSL,168,PASS,ET000;(格式為測試項目代號,測試值,測試結果,錯誤代碼) 21F3(檢查碼 CHECKSUM)
檔案內容中，除了
TEST_ITEM
會隨著產測程式的變動而變動之外，其它皆 為固定屬性。在資料庫綱要設計中，不同的綱要設計決定了產測紀錄的儲存方式。綱要一採用水平式的設計，截自該企業 2008 年 2 月至 8 月的產測紀錄經過 統計之後得知測試項目有 76 項，故在水平式資料表就需要有 76 個欄位對應這 76 項的屬性；綱要二是以學界提出的垂直式綱要概念設計，依照企業的生產模 式，經過正/反規化之後產生的資料庫綱要；綱要三是以水平垂直混合式綱要的 概念並參考某半導體封測公司專業人士的建議所產生的資料庫綱要。
一般在學界的研究資料庫綱要是以理論式的設計，且資料筆數不大，在沒有 實際運作的情況之下，相對顯得抽象而不具體。在本研究中，我們實際取得企業 提供的資料庫綱要設計以及 Shop Floor 系統運作的資料，這也是一般在研究中資 料來源最難取得的部份，因涉及商業機密企業通常不願意提供。在本研究中設計 了三種資料庫綱要，故將取得的來源資料分別以三種綱要的型式存在也是本研究 的工作重點項目之一。
本研究中的三種綱要，主要的差異在於產測紀錄(test record)的儲存方式不 同，儲存產測紀錄的資料表我們稱之為生產測試紀錄資料表。在水平式綱要設計 中是在水平式資料表內建立所有測試項目的欄位，以整合所有產測紀錄所有的屬 性；在垂直式綱要設計中是將所有產測紀錄屬性以資料的型態存在；而水平垂直 混合式綱要的設計是結合水平式與垂直式綱要的概念，除了有垂直式資料表之外 並設計一個水平式資料表儲存垂直式資料表中固定不變的屬性並附加彙總欄位 (原因請參閱第二章第五節的說明)。資料庫綱要分別詳述如下：
1. 水平式綱要
如前面所述，我們統計了產測紀錄中的測試項目總共有 76 項加上 2 個固定 屬性(PcbaNo 以及 TestPrgID)，設計了含有 78 個屬性的水平式資料表，換句話說，
這個資料表整合了所有產測程式的屬性。由於此資料表含有所有的測試項目，而 每一道產測程式有所屬的測試項目，所以可想而知每一筆產測紀錄並非所有的欄 位都是非 Null 值。因此，我們計算了此生產測試紀錄資料表的稀疏度，得到總 稀疏度為 97.71%(計算的方式請參閱附錄 B)，符合稀疏資料集的條件，為本研究 的效能評估創造有利的實驗環境。
ER-Model 如圖 4-1 所示。其中經正規化的程序將 Testing Record 資料表重複 的屬性抽離出來成為 Testing Result 資料表，之間以 Uid 作為參考外來鍵，資料 庫綱要如圖 4-2 所示。
圖 4- 1 水平式綱要設計的 ER-Model
圖 4- 2 水平式資料庫綱要
2. 垂直式綱要
此綱要的設計主要是將 Testing Record 的儲存方式從水平式轉換為垂直式。
另外，考量垂直式效能可能不佳的問題，在綱要中設計了一個 WorkingIP 的資料 表，主要目的是記錄 PCBA 在製的狀況，在某些查詢的條件下可以參考此資料表 以增進效能。再來要說明的是，在第一種綱要設計中，一個產品是需要一個測試 路徑(routing)，但有些產品是相同的路徑，在實際運用上每種產品都需要設定測 試路徑就生產管理的觀念而言就會增加工時而沒有效率。故在此綱要中更改為以 TestRouingID 為主鍵(primary key)，從 TestRoutingID 對應到產品料號，那麼在實 際運用上每種產品只需要以 TestRoutingID 設定即可，而不需要重新設定測試路 徑，就可以增加工時效率。ER-Model 的表示如圖 4-3。
在第二章第五節已提到過，在真實世界中由於有眾多屬性，故在垂直式綱要 的設計上不可能如學者所提出的垂直式綱要理論，以三個屬性欄位就可以完整描
述真實世界所發生的事件，故必須再添加屬性才能完整表達。依照本研究的對象 企業的彈性生產型態，產測程式(TestPrgID)、測試項目(TestItemID)與測試值(Value) 一定是彈性變動的，故將這三個屬性轉換以垂直式方式記錄，但是若資料表只有 這 三 個 屬 性 是 不 足 以 完 整 表 達 企 業 生 產 時 所 發 生 的 事 件 ， 故 需 再 加 上 PcbaNo(PCBA 序號)、WoNo(工單號碼)、TestStationID(測試站 ID)、Tester(測試 人員)、Result(測試結果)、ErrorCode(錯誤代碼)、Duration(測試耗費工時)以及 CDT(紀錄建立日期時間)等屬性。資料庫綱要如圖 4-4。
圖 4- 3 垂直式綱要設計的 ER-Model
圖 4- 4 垂直式資料庫綱要
3. 水平垂直混合式綱要 (Hybrid H&V Schema)
此綱要結合了水平式與垂直式綱要的設計。前面的章節已經提過，水平式綱 要適合變動不大的屬性，垂直式綱要適合多變彈性的屬性，故我們歸納了企業提 供的產測紀錄檔案裡的內容項目，將不變動者(PcbaNo, TestPrgID, TestStationID, WoNo, Result, ProductName)以水平式資料表(Testing Result)的型態存在，並在該 資料表中附加一個測試次數(ReTest)的屬性記錄 PcbaNo 出現的次數。由於產測程 式、測試項目與測試值會隨著產品的製程而有所不同，是擁有多變的特性，故將 之規劃採用垂直式設計的產測紀錄資料表(Testing Record)，它們之間以 PcbaNo 作為參考外來鍵。
承前面垂直式綱要設計的說明，混合式綱要的垂直式資料表如同前面垂直式 綱要的設計，除需要 TestPrgID、TestItemID、Value 等屬性外，還要將 WoNo、
TestStationID、Tester、Result、PcbaNo、ErrorCode、Duration、CDT 等屬性規劃 進來。
經此設計之後我們可以發現在 Testing Result 與 Testing Record 資料表中會有 一些相同的屬性(PcbaNo、TestPrgID、TestStationID、WoNo、Result)。這樣的設 計好處就是可以減少如 COUNT 等 SQL 函數的運算，直接以 Select [欄位名稱]
from [Testing Result]就可以取得，可以增加查詢效能。
另外，此綱要中的測試路徑乃是延用第一種綱要的設計方式。ER-Model 如 圖 4-5 所示，資料庫綱要如圖 4-6 所示。
圖 4- 5 水平垂直混合式綱要設計的 ER-Model
圖 4- 6 水平垂直混合式資料庫綱要