4.1 擷取 Facebook 資料子系統
4.1.2 資料處理
國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
31
Access Token 有時效性的問題，為了避免在我們需要存取資料時，Access Token 失效，因此我們透過程式，每小時定期更新，並將 Log 狀況記錄在資 料庫中。
4.1.2 資料處理
本章節將會介紹本系統對從 Facebook 擷取回的資料做了哪些處理：(1) 轉換並儲 存擷取回的資料 (2) 過濾出我們需要的打卡資料 (3) 將同筆打卡的資料分為一 組 (4) 先行計算是否有手機 Log 的前景程式操作。資料處理的流程，參照章節 3.1 系統架構中的擷取 Facebook 資料子系統區塊。
使用 Facebook Graph API 擷取資料，所回傳的資料格式為 JSON(JavaScript Object Notation)的資料型態，儲存資料的方式為一組 key 與 value 的資料結構。
圖 15 為使用公用帳號進行打卡發文後，擷取回來的 JSON 資料結構(移除掉部份 重複的結構)，圖片中除發文者「Susan Su」，已將使用者以及對話內容隱藏。該 篇發文的內容包含橘色區塊的「使用者打卡」、咖啡色區塊的「按讚的使用者」、 藍色區塊的「使用者回覆」。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
32
圖 15. Facebook Graph API 傳回的 JSON 資料結構。
我們所使用的 SDK 為 Facebook 官方提供的 Facebook SDK for PHP[23]，因此 轉換 JSON 時處理資料內容所使用的程式語言為 PHP，轉換後的資料經過濾地點 後再存入 MySQL 資料庫中。
Facebook Graph API 回傳的 JSON 資料結構中所包含的 key 並不固定，key 會 依該篇發文中有的內容才會呈現，例如：若該篇發文中沒有使用者按讚，則「likes」
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
33
的 key 與 value 均不會出現。因此我們將 Facebook Graph API 傳回的 JSON 依據在 Facebook 上不同的操作內容(發文內容、按讚、回覆…等)，定義不同的 Class 來儲 存從 JSON 中取出的資料內容，並使用不同的資料表來儲存，表 6 為不同資料表 對應存入的內容。
表 6. 資料表所儲存的資料內容。
資料表
打卡資料類型 (純文字、附圖片)
儲存的內容
CheckinInfo 純文字 打卡的內容、時間、地點 CommentInfo 純文字 打卡的回覆
LikeInfo 純文字 按讚該篇打卡的使用者
ObjectInfo 附圖片 打卡的內容、時間、地點 ObjectCommentInfo 附圖片 打卡的回覆
ObjectLikeInfo 附圖片 按讚該篇打卡的使用者 PlaceInfo 純文字、附圖片 打卡的地點資訊
UserInfo 純文字、附圖片 打卡相關的使用者
使用 Facebook Graph API 擷取資料的方式沒辦法單純取回含有地點的發文，
因此我們需要再進行過濾地點的步驟。若是要取得使用者的打卡發文，我們需要 個別對純文字與圖片的類型分別進行擷取，而擷取回來的資料不一定每筆使用者 的發文都含有「place」的資訊，因此需要再透過程式過濾出含有地點資訊的發 文內容再存入資料庫中。
在先前段落有提到「key 會依該篇發文中有的內容才會呈現」，若是該筆發 文中沒有地點資訊，「place」的部份不會出現在回傳的內容中，因此我們透過判 斷 key 為「place」的內容是否存在，決定是否要將該筆發文內容存入資料庫中，
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
34
若 key 為「place」的內容不存在，即捨棄該筆發文資料。
在 Facebook 上的發文中，單筆發文附有多張圖片(如圖 16)，一張圖片會被 算為一筆資料，因此若是附有多張圖片，在擷取回的資料中會呈現為多筆圖片類 型的發文內容(如圖 17)，會造成在筆數計算與呈現上的問題。因此我們對在一定 時間內，同個打卡地點的發文，合併為同一筆打卡，並新增一個欄位(groupNum) 給予新的 id 值，屬於同筆打卡的資料會為相同的編號。
圖 16. Facebook 上同筆打卡，附有多張圖片。
圖 17. Facebook 上同筆打卡，附有多張圖片，擷取到的資料會分為多筆。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
35
在 Facebook 回傳的資料中，會有地點名稱相同，但地點 id 不同的狀況，因 此我們在判斷打卡地點是否相同的判斷方式，是以 Facebook 回傳的地點 id 來判 別，地點 id 相同，則為相同地點，若地點名稱相同但地點 id 不同則視為不同地 點。考量到使用者打卡時可能受限於網速等因素，造成同筆打卡中的多筆圖片資 料會有時間差，因此我們時間的判定方式為 2 筆資料間時間差為 5 分鐘內，則視 為是在同一時間打卡。
在我們的互動介面設計中，需要同時顯示 Facebook 打卡資料與其前後的手 機 Log 資料，為了讓之後查詢資料庫時的效能提高，我們會先行計算每筆打卡資 料是否有符合的手機 Log 資料，並將結果存回資料庫中，之後研究者透過介面篩 選時，系統的查詢方式便可以先行對這些欄位篩選是否有符合的資料，不用重新 比對每筆打卡與手機 Log 資料的對應結果。