2.2 資料庫之整合
2.2.2 欄位對照
在整合的第二步要解決的就是語言上的問題，因為台灣地區食品營養成份資料是 以中文名稱為欄位，因此首先必須建立一張對照表，用來對照台灣與美國食品營養成份 資料間的欄位。如圖 2-7 所示，第一欄為台灣地區食品營養成份資料之中文欄位的名 稱，第二欄為第一欄營養素名稱之英文，第三欄為各營養素之單位，第四欄為美國地區 營養素之欄位名稱。
未來若想新增一個食品營養成份資料的對照，則只要在這張對照表中加入對應的 欄位，如圖 2-12 所示加入 Canada 與 Japan 兩個食品營養成份資料，再到表中將對應到 中文欄位的營養素填入即可。如圖 2-13 所示，未來在程式設計時，只要適時的參照欄 位即可切換語系，也可以達到跨資料庫欄位參照的目的。
圖 2-12 整合資料庫之對照表
圖 2-13 新增外國語系、資料庫對照
整合資料庫之系統架構圖如圖 2-14 所示。美國地區食品營養成份資料以 MSSQL 之轉換程式便可順利轉入整合式資料庫中，台灣地區食品營養成份資料則先將資料以 Excel 檔收集並將其中特殊符號以替代值代換才能轉入整合式資料庫之中。此外，我們 亦開發線上登錄系統，開放廠商或研究人員可以線上即時登錄最新的食品資訊。
圖 2-14 整合資料庫系統架構圖
2.2.3 缺值處理
在食品的量測上，可能會發生因為數值太小儀器無法測出正確的數值。這時候可 能會有幾種處理方式，有可能以計算份量的方式推估營養素的量。在美國及加拿大地區 食品營養成份資料中是以一張表來記錄各種判斷的方式及其代碼，在營養素的資料表中 並沒有特別標示出未量測、推估為零或者直接分析間的差異。因此使用者若想知道某食 品之營養素之值是量測出、計算或推估得到，必須查詢其他關聯資料表才能得知。
台灣與日本地區營養資料庫則是直接將這幾種不同營養素的取得方法轉換成代號
因此，美國與加拿大地區食品營養成份資料的營養成分表中除了數值與空值外沒 有其他特殊符號，而台灣地區食品營養成份資料中則多了這些符號。因此在匯入整合 時，我們為降低將來在程式設計時比對符號的困難度，我們將「-」以數值的「-1」代 替，「Φ」以「-2 代替」，「Tr」以「-3」代替。
圖 2-16 為台灣地區食品營養成份資料之營養素分佈圖。橫軸為營養素數目，由 1 到 75。縱軸表示有幾個營養素值之資料筆數與整個資料庫筆數之比例。圖 2-17 為圖 2-16 之累積圖。我們從分佈圖可以看出擁有 22 個左右的營養素之資料筆數有將近 10%
的比例，其次為擁有58 個營養素之資料筆數將近 6%的比例。圖 2-18 則是以營養素為 觀點，我們首先對每一個營養素查詢資料庫中擁有之資料筆數，再以此筆數值除以全部 資料筆數可以得到每一個營養素擁有筆數百分比。將所有百分比由高至低排序後分成十 個區段計算每個區段中之營養素個數再將每個區段的個數除以全部的營養個數（75 個），就可以得到縱軸的數值。因此可以從圖中看出35%的營養素在資料庫中缺值的資 料筆數有40%。可以看出缺值情形相當嚴重。
圖 2-20 為美國地區食品營養成份資料的營養素分佈圖。美國的食品營養成份資料 的簡表中擁有43 個營養素。從分佈圖中可以看出擁有 30~32 個營養素的資料筆數都有 將近10%的比例，資料的完整性比較高。
圖 2-15 台灣地區食品營養成份資料-原始資料
0%
5%
10%
0 10 20 30 40 50 60 70 80
營養素個數
比例
圖 2-16 台灣地區食品營養成份資料營養素個數分佈圖
0%
20%
40%
60%
80%
100%
0 20 40 60 80
營養素個數
累積比例
圖 2-17 台灣地區食品營養成份資料營養素個數累積圖
0
0%
做關聯。reginfo 則是使用者註冊時之暫存表，若使用者通過審核就會將資料儲存至 manage 表中。而使用者權限則分為三級，一般使用者可新增食品但無權限刪除，若要 確認新增至實體資料庫及刪除資料需透過群組管理者或是網站管理者。
圖 2-22 營養資料庫之應用設計
圖 2-23 存取權限之分級
2.3 資料庫之管理
一般所提出之Food Database Management System (FDBMs)通常是撰寫一套單機軟 體來管理資料庫[25]。而我們則是讓系統管理者可以透過網站的後端程式，新增、修改 及刪除資料庫中的營養資訊。如圖 2-24 所示，使用者可用兩種方式搜尋欲修改或刪除 的資料。
圖 2-25 為使用者點選穀物類後列出資料庫中所有穀物類的食品資訊，圖 2-26 為 使用者輸入欲查詢之關鍵字後列出資料庫中不分種類的食品資訊。
圖 2-24 資料庫後端管理介面
圖 2-25 後端管理介面-依種類搜尋
圖 2-26 後端管理介面-依關鍵字搜尋
找到欲修改的食品後，可點選刪除選項刪除資料，或點選食品可進行食品資料的 修改，如圖 2-27 所示。此外，使用者也可以新增食品資料到營養資料庫之中，在圖 2-24 中，點選新增選項，則可以進行新增食品資料，如圖 2-28 所示。新增完成後，食品資 料會暫時存放在另一個營養成分表中，如圖 2-29 所示，等待系統管理員或是群組管理 員檢閱資料無誤後便可加入營養資料庫中。在等候審核期間，新增此筆資料的人員、群 組管理員以及系統管理員皆有權限修正資料。
圖 2-27 後端管理介面-食品資料修改
圖 2-28 後端管理介面-新增食品資料
圖 2-29 後端管理介面-新增食品資料等待審核
系統提供這些線上新增、修改及刪除的介面，可讓資料庫即時更新資訊。不僅能 即時修正資料，更能快速提供使用者更多、更正確的營養資訊。
2.4 Web Services
Web Services[7][17][22]是一種允許電腦間彼此以制定格式的訊息自動相互溝通，
由Worldwide Web Consortium（W3C）設計訂定，用來促進跨平台間程式對程式的通訊。
若我們將查詢功能建置成Web Services 形式，並將之推廣使得全世界的查詢食品營養素 之功能也都建置成Web Services 形式，如此一來程式與程式間便能彼此互相溝通。若我 在某個國家網站查詢某一個食品之營養素時，此查詢會自動與世界上其他查詢程式相互 溝通，並同時查詢其他資料庫中之相關資料，查詢資料因此可以變的廣泛多樣化不僅僅 侷限於某一個資料庫來源。
要運用Web Services 功能必須了解有三個元件是 Web Services 所必要的：
z UDDI（Universal Description Discovery and Integration）：提供註冊與搜尋 Web Service 資訊的一個標準。
z WSDL（Web Service Description Language）：以 XML 撰寫的文件，主要的 用途是「描述 Web Services」，也就是讓用戶端知道如何使用 Web Services，
包括提供服務的種類、呼叫方法、參數傳遞等。
z SOAP（Simple Object Access Protocol）[20]：架構在 HTTP 之上的物件存取 協定，用來在網路上交換結構化和型別資訊。當用戶端程式需要呼叫 Web Services 時，會把要求封裝成 SOAP 呼叫，傳遞給遠端，當遠端 Web Services 收到請求後，會執行指定的工作並利用SOAP 傳回結果。
可以從圖 2-30 看出，當一個用戶端想找尋一個 Web Services 來使用時，先於 UDDI 伺服器中尋找，當尋找到時便以UDDI 所提供的位址，到該 Web Services 所在的位址。
此時向該 Web Services 要求 WSDL 文件，此 WSDL 文件可以提供使用者在使用 Web Services 所需輸入的訊息格式。最後使用者便可依這些資訊向該 Web Services 發出請求 取得服務[3]。
圖 2-30 Web Services 的架構圖
傳統的旅遊訂票流程如圖 2-31 所示，使用者必須自行訂飯店、訂機票以及其他相 關服務，每個服務間無法彼此溝通。而透過Web Services 如圖 2-32 所示，每個服務間 以共通的訊息相互聯繫，如此一來使用者決定了目的地時，系統會自動連繫航空公司自 動找尋可訂購之航班，決定好時間地點後系統會自動聯繫當地飯店的服務系統，自動找 出抵達當日可提供住宿的飯店[12]。
圖 2-31 傳統的旅遊訂票流程
圖 2-32 透過 Web Services 的旅遊訂票流程
因此我們也希望能夠建置一個類似的服務，網路上其他程式或是使用者送出欲查 詢之關鍵字，我們所建置的Web Services 就會根據傳入的字串查詢後端資料庫，再將資 料回傳。如圖 2-33 所示，我們建置一個 QueryNutrient 的 Web Services，我們定義只要 輸入關鍵字便可以傳回所有食品名稱中擁有該關鍵字之食品。
只要世界上各國皆建立類似的Web Services 查詢功能，使用者不須分別到各國資 料庫中查詢食品營養素，只需到其中一個資訊網站輸入查詢關鍵字後，便可以利用Web Services 的便利查詢出與此資訊網站之 Web Services 能相互溝通之所有食品營養資訊，
對使用者來說是非常方便且實用的功能，也能達到查詢資料廣泛且多樣的特性。
圖 2-33 Query Nutrient Web Services
圖 2-34 QueryNutrient 本機測試畫面
2.5 小結
綜觀世界各國大多有開始建置國內之食品成份資料，但將國內與國外營養資訊整 合的很少。我們將不同營養資料整合後不僅僅是資料的增加，對於往後一些應用服務的 提供更有著廣泛的來源。我們提供的整合方式只要將欲新增的食品成份資料來源之營養 素名稱與國內的相對應即可，提供一個較為快速方便的整合方式，不須為了整合食品營 養成份資料而從頭變更整體的架構。
第3章 整合式營養資料庫之應用
選擇是以最常被食用的食品為主[6]。作者以 Linear Programming 的方式自動產生建議菜 單，過程中也會考慮各種營養素的攝取量之平衡。此論文將研究地區在食品的季節上分圖 3-1 USDA 提供的查詢介面
圖 3-2 USDA 的查詢結果
加拿大也是提供類似的查詢功能。使用者輸入關鍵字或是食品代碼，如所圖 3-3
圖 3-3 加拿大提供的查詢介面
圖 3-4 加拿大的查詢結果
3.2 查詢功能介紹
為提供多樣且便利的查詢介面，我們設計的資料庫應用，提供「依營養成份查詢」、
「依名稱查詢及「依種類查詢」等三種常用的查詢方法，茲分別詳述如下。
「依名稱查詢及「依種類查詢」等三種常用的查詢方法，茲分別詳述如下。