國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
45
肆、 系統建置與研究結果
一、 系統實作與建置
(一) 客戶端
在客戶端方面，採用了網頁設計基本的 HTML 與 CSS Style 做為使用者介 面的排版，功能方面加入了 jQuery 與 YUI3 兩種語言來撰寫。公司搜尋條件 使用了 jQuery 中的 autocomplete，最後資料呈現在畫面上則使用 YUI3 來當 作填寫工具。
(二) 伺服器端
在伺服器端採用了 Node.js 當作開發工具，使用的是純粹的 JavaScript 語言。在系統裡面會用到以下功能，index 為 Node.js 驅動的 js 檔案，server 主要功能是開啟伺服器端網頁，router 為接收 URL 所傳入之參數，另外還有 requestHandlers 是前端主要呈現的模組，使用者介面以及執行函數接在這個 模組裡面執行。
前面有介紹過，Node.js 是以模組為基底的，因此模組的建置與使用就變 得相當重要，這裡提出本系統的其中一個模組當範例來說明如何建立與運用 模組，首先建立一個 requestHandlers 的 js 檔，由下圖所示能看到此 js 檔 案中包含兩個函數，start 與 upload：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
46
圖 十八 模組中 start 函數
圖 十九 模組中 upload 函數
函數內容不是本研究重點，重點是在 requestHandlers 這個模組中建立 此二函數之後，要如何讓這個模組與其函數成為真正的模組讓其他 js 檔使用 呢？就是利用 export，利用 export 將函數匯出即可，要將 requestHandlers 的 start 與 upload 函數匯出即如下圖所示：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
47
圖 二十 利用 export 匯出模組函數範例圖
只需要短短一行：exports.函數名稱 = 函數名稱，即可將函數匯出，此 模組與其函數此時已經可以供其他 js 檔使用。接下來介紹如何使用模組，使 用 require 函數將模組路徑即名稱以參數方式丟入可以引用，如果是 Node.js 內建模組則只需要名稱不需路徑，以下圖為例子說明：
圖 二十一 模組引用說明範例圖
依上圖所示，上圖為 index 首頁的模組引用範例，從圖中可以看出 index 頁面裡用 require 函數引用五個模組，分別是 http、url、server、router 以及 requestHandlers，前兩個 http 以及 url 是 Node.js 內建模組，因此參 數不需要加上路徑即可成功引用，而後面三個 server、router 與
requestHandlers 是內建模組，在引用內建模組是必須要有路徑位置與模組名 稱，路徑位置可以是絕對位置也可以是相對位置。從上圖中成功引用五個模 組，在與前面範例介紹的 requestHandlers 結合說明，接下來只需要下指令 requestHandlers.start()就可以執行 requestHandlers 中剛剛建立的 start 函數。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
48
(三) 資料庫端
因為 CouchDB 的特色有內建備份機制，支援離線儲存與線上同步以及文 件為儲存基礎等特性，所以這個小節主要是針對 CouchDB 的這兩個特色做討 論。
1. CouchDB 同步機制
在講解同步機制前，先放上 CouchDB 簡易結構圖如下：
圖 二十二 CouchDB 簡易結構圖
簡易結構圖如上，我們可以看到 CouchDB 是可以存取許多個資料庫，
也就是 CouchDB 是多個資料庫所組成的。而一個資料庫 A 是由若干個文 件(Document)所組成，一個資料庫可以存放許多的文件，然一個文件 a 裡面組成元件有文件編號、文件版本號以及文件內容包含 key 以及 value 若干組。而了解 CouchDB 結構後，我們來看看許多客戶端主機與一台主 機想要將所有資料同步該如何處理。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
49
圖 二十三 多台客戶端主機與主機連接示意圖
客戶端 A、B、C 與 HOST 皆為雙向同步，因此可以想像成資料在彼此 之間會完全互相傳遞，接下來看這其中是如何運作。假設客戶端 A 更新 一筆資料，因為客戶端 A 有箭頭指向 HOST，也就是客戶端資料會與 HOST 同步，同步完成後，因為 HOST 資料發生改變，便會通知客戶端 B 與客戶 端 C，接著將資料同步於客戶端 B 與 C，經過這樣的同步程序後，客戶端 A、B、C 與 HOST 就會保持資料一致性，不論是哪個客戶端對資料庫更動 一筆資料，所有與其連線的主機將會與該資料庫進行同步。
而事實上同步指的是資料庫間的同步，而且不限定資料庫名稱、使 用者資料等條件，更詳盡的同步示意圖如下：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
50
圖 二十四 CouchDB 同步機制詳細示意圖
如上所述，同步不限定資料庫名稱與客戶端用戶，因此從圖二十四 中可以看出，其同步可以是客戶端 A 的資料庫 A 與 HOST 端的資料庫 D 以 及客戶端 B 的資料庫 C 和客戶端 C 的資料庫 B 互相同步，且不受到其他 相同命名資料庫之干擾，也就是只要設定好，任何名稱的資料庫不論幾 台都可以互相同步，這也是 CouchDB 同步機制中很強大的一部分。
從剛剛到現在，我們討論的都整個資料庫的同步，但是其實 CouchDB 的同步機制還有類似篩選器(Filter)的功能，資料庫與資料庫間可以只 保有一部分文件同步，以下圖說明之：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
51
圖 二十五 CouchDB 同步機制加上篩選器
上圖表示資料庫 A 的文件 a1 與 b1 與資料庫 HOST 的文件 a1、b1 進 行雙向同步；而資料庫 B 的文件 a1、b2 與資料庫 HOST 的 a1、b2 做雙向 同步；資料庫 C 的文件 a2、b2 以及 c1 與資料庫 HOST 的文件 a2、b2、c1 做雙向同步。雖然資料庫 A、B、C 總共有七個文件總數，但是由於資料 庫 A 與資料庫 B 中都存有文件 a1，所以扣除重複的部份總共有六種文件，
也就是資料庫 HOST 的文件總數。資料庫 C 的文件並未與其他資料庫相同，
因此可以看做是整個資料庫同步(即使資料庫 C 還有其他文件也可不進行 同步)，資料庫 A 與資料庫 B 有相同的文件 a1，可看做未加入篩選器時的 同步機制，不論誰更新都會同步至資料庫 HOST 接著再同步至另外一台資 料庫，此外，資料庫 A 與資料庫 B 都分別擁有自己才有的文件，分別是 b1 與 b2，此資料會與資料庫 HOST 進行同步更新但不受其他資料庫干擾。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
52
2. 傳統關聯式資料庫轉換文件導向資料庫之規則
由於 CouchDB 是 schema-less 的資料庫，但所謂 schema-less，其實 就是指沒有 schema，當然也沒有傳統的關聯式資料庫裡面合併(join)的 概念。然而，儘管 CouchDB 本身沒有提供這樣的支援，真的需要用到關 聯式表格的時候還是能使用一些小技巧，像是重新定義 schema，利用新 的文件加上 View 就可以做到合併(join)的用法。在本小節會舉簡單的例 子稍作說明。
表 三 學生資料表
表 四 公司資料表
上面兩張分別是學生資料表以及公司資料表，在關聯式資料庫中，
若要查詢該學生所在的公司其電話及地址變可使用 join 的觀念將兩張表 格合併，不過在 CouchDB 中並沒有這樣的概念，那麼要如何做這樣的功 能呢？先從下圖左邊看起：
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
53
圖 二十六 簡易轉換規則說明圖
上圖可以看到 Student 與 Company 資料表裡的資料格式，以 JSON 格 式展示，資料表內有各自的文件編號、文件版本號還有文件自己的屬性。
今天如果希望 Student 與 Company 有所連結，就可透過圖二六最下面所 示，在 Student 資料格式的 Company 改成儲存 Company 為 AAA 這間公司 的文件編號，如此一來只要從 Student 表格中取出 Company 的值(此時為 文件編號)，再利用文件編號去找到此間公司的詳細資訊，雖然此方式稍 較複雜，但是在沒有 schema 的 CouchDB 中，已經可以利用此方法解決資 料關連性的問題。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
54
二、 研究結果
(一) 系統介面呈現
進入系統之後輸入公司名稱或代號，而後經過計算則會輸出公司合理股 價。輸入與輸出畫面可在下兩張圖中看到：
圖 二十七 系統輸入
圖 二十八 系統輸出畫面
從圖中可以看到，輸入公司代號之後，系統會輸出根據 ROE、OPINC、
CASHFLOW、CVCS 以及多變數迴歸等五種模型之預測盈餘結果，根據五種不同 的預測方式產出不同的結果並分別列出。
因為本研究旨在建立 JavaScript Application Framework 與 CouchDB 的 連線機制，盈餘預測系統只是拿來實作的範例，因此系統介面並無美化，僅 是將連線機制確立並且印出結果。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
55
(二) 系統與研究困難點
本研究有幾個困難點，第一：儘管提供了傳統的關聯式資料庫轉換至文 件導向資料庫的規則，但是畢竟 CouchDB 原本就不是設計給複雜資料用的。
剛好本研究採用的範例需要的資料是公司的會計科目，並沒有太過複雜的結 構，否則複雜架構的資料用 CouchDB 處理會非常困難。第二：由於 CouchDB 特性的關係，資料量只會越來越大，而該如何在版本控制與 Compaction 之間 取得平衡，依舊是很困難的。第三：因為本研究採用 JavaScript 應用框架，
此為目前較新穎的技術，因此實作上面仍有許多資料搜尋是相對困難許多，
但是相信往後技術越來越成熟這方面問題也會逐漸改善。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
56
伍、 結論與未來展望
這份研究主要是利用 JavaScript Application Framework 來實作盈餘預測系 統，實作出符合前後端(客戶端、伺服器端)同一程式語言的架構，而底層資料庫 技術使用的是 CouchDB，CouchDB 特點有內建強大的備份機制，因而可以做到離線 儲存、自動同步等功能。此研究雖然不是建立協同合作的平台，但有特別針對 CouchDB 的同步機制加以說明，也點出 CouchDB 是很適合作為協同合作平台的底層 資料庫選擇，但也因為 CouchDB 版本控制機制的緣故，資料量變大會非常占空間 也是最大的問題。
本研究最終有實作出以 CouchDB 為資料庫的系統，並且探討 CouchDB 所提供的 同步機制與離線儲存技術，能利用這些技術運用到其他地方並且做出實作雲的概 念，較可惜的是此次系統並沒有提供完整的協作機制，只是針對這些協作機制做 詳細的討論。這次的研究只是一個實作研究，說明以 CouchDB 當做資料庫能符合 協作環境的需求，因此若要實作協作雲系統 CouchDB 將是底層資料庫的選擇之一，
而盈餘預測系統只是本研究的一個實作範例，並沒有提出更新的架構，往後的研
而盈餘預測系統只是本研究的一個實作範例，並沒有提出更新的架構，往後的研