資料庫建構

本研究使用低壓AMI 用戶用電資料，牽涉到資訊安全、技術等因素，實務上無法 直接和台電現有資料庫進行連接，因此需取得資料來源檔案，先行建構中介資料庫後 再進行處理。

中介(Middleware)一詞最早出自 1968 年 NATO Software Engineering Conference，

學者Alexander D'Agapeyeff 提出倒金字塔架構，在此架構中，控制程式層、服務程序 層位於下方，而應用程式層位於上方，在中間進行承接的即為中介層。

應用程式層處理使用者的各種需求，並透過中介層讓控制程式層、服務程序層能 夠執行。然而，當底層程式有所更動時，上方層級皆會受到影響，在軟體開發上較為 敏感。

圖 4-1 D'Agapeyeff 倒金字塔架構

本研究為了解決資料來源與資料探勘問題，提出High-Performance Middleware Integrating Data Analysis Tools (簡稱 HIT)的資料處理架構。

doi:10.6342/NTU201702936

圖 4-2 HIT 資料處理架構 Microsoft® Access (以下簡稱 Access)進行資料聚合，最後以 Microsoft® SQL Server (以 下簡稱SQL Server) 建構資料庫。

初次輸出之資料，經過資料預處理、ETL 等步驟後，再由應用程式進行資料探 勘。以下將介紹資料庫建構過程。

Original

Database HIT

Matlab

35 又可分為叢集索引與非叢集索引。以下介紹兩種索引(Microsoft Developer Network, 2017)：

a. 叢集索引：將資料表或檢視中的資料列，依照其索引鍵值進行排序與儲

(Microsoft®

Access)

將聚合完畢之資 料匯出至ODBC

資料庫

建立SQL Server 資料表索引

doi:10.6342/NTU201702936

沒有任何叢集索引，資料列將儲存在未排序的結構中，這種資料結構又可 稱為堆積(Heap)。

b. 非叢集索引：非叢集索引含有一個與資料列分開的結構，此結構包含了非 叢集索引鍵值，而每個鍵值項目都有一個指標指向資料列。這些從非叢集 索引中的索引列指向資料列的指標，又被稱為資料列定位器。資料列定位 器的結構需視資料頁儲存在堆積或者是叢集資料表而定。若資料頁儲存於 堆積中，資料列定位器即為指向資料列的指標。若資料頁儲存於叢集資料 表中，資料列定位器即為叢集索引鍵。

以下比較建立索引的效能差異。在建立了日期時間索引的資料表中，其搜尋單日 用電資料的花費時間與運算子成本，皆比無建立日期時間索引的資料表較為節省。

圖 4-4 已建立日期時間索引之資料表查詢效能

37

圖 4-5 尚未建立日期時間索引之資料表查詢效能

doi:10.6342/NTU201702936

以搜尋全體用戶的單日資料為例，可以發現在未建立索引的資料表搜尋時，使用 了資料表掃描，而非透過索引進行搜尋，其估計運算子成本(單位:秒)約為建立索引後 的30 倍，總執行時間約為建立索引後的 5 倍(由 4 秒增加至 20 秒)。

雖然在單日搜尋資料的時間差異不大，但是以資料庫進行月資料﹑年資料查詢，

或是較複雜的複合查詢時，未建立索引而導致增加的處理時間，將隨著資料表掃描指 令的累積而巨幅增加，嚴重影響資料庫查詢執行效率。

而在輸出約8,000 名用戶的個別單日用電資料時，搜尋條件包含了表號與日期時 間，倘若只使用[日期時間]作為索引，仍將產生大量運算子成本。若搭配以[表號]建立 之非叢集索引進行查詢，能夠更大幅提昇查詢效率。

結合上述比較作為結論，針對用電資料建立適當的索引，在資料處理上是相當重 要的步驟。藉由本研究之HIT 架構所建立索引，除了可加速探勘資料輸出至應用程 式，在中介上所進行的操作也並不影響原始資料庫，因而能夠維持原資料庫的完整性 與穩定性。

39