第四章 系統實作方法
4.1 資料庫設計
國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第四章 系統實作方法
此章節主要在描述本論文系統架構時做的細節，重點會從資料庫設計出發，藉由 Data Modeling 的方式，解釋如何從和使用者討論的抽象概念一步一步轉化成本 論文的程式系統，負責前後端溝通的 REST API 的設計方式，再帶入實作 MVC 架 構的程式的實作細節。
4.1 資料庫設計
從 USER STORY 討論開始，將預計 APP 的使用情境按照流程繪製出來，以確認想 法，然後按照 Data Modeling 的流程先從 USER STORY 中去提取實體，繪製 conceptual data model，如圖 4.1~4.3 所示，這個 APP 運作的主要流程有三項，
第一項是 USER 根據地點打卡，並且將打卡紀錄存入資料庫中，第二項是根據第 一項產生的打卡紀錄去計算出這個時間下的 KEEPER，並將每一期的 KEEPER 存入 資料庫中以供查詢使用，第三項是根據上述兩項 USER 產生的打卡紀錄、KEEPER 紀錄，根據設定好的徽章條件，去計算 USER 是否取得這些徽章。
藉由上述三項流程，可以歸納成三類，如圖 4.4，最基本的實體資料 USER、
PLACE、BADGE，屬於程式邏輯的動作狀態打卡、計算 KEEPER、計算徽章，以及根 據動作衍生出來的資料打卡紀錄、獲得徽章、KEEPER 紀錄，再來將上述實體結合 USER STORY 中的程式流程繪製 logical data model，將資料的細節表達出來，
包括所有實體的關係跟程式邏輯。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.1:APP 流程圖(打卡)。
Figure 4.2:APP 流程圖(獲得徽章)。
Figure 4.3:APP 流程圖(計算 Keeper)。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.4:流程分類。
Figure 4.5:Logical data model。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.5，是本論文系統程式的 logical data model，這個 Pervasive game APP 的主要核心是 USER 的打卡紀錄，像是 KEEPER 以及 USER 獲得的徽章都是經 由打卡紀錄所產生出來的，而為了提高程式效能在設計上，會把原本動態產生的 資料，實體化成資料庫中的 TABLE，像是 KEEPER 是由特定期間內的打卡紀錄產 生，產生這一期的 KEEPER 後，就存入另一個 TABLE，這樣要查詢過去歷史的 KEEPER 時就不需要再從打卡紀錄中提取出來，而另一個提升效能的例子是 USER 的徽章 紀錄，從流程上出發，徽章是由 USER 的打卡紀錄中去尋找是否符合獲得徽章的 條件，符合才授予 USER 徽章，這其中需要跨越多個 TABLE，像是打卡、USER、
PLACE、KEEPER、BADGE…等，由此可知計算 USER 是否取的該徽章是件需要大量 效能以及對資料庫存取的工作，因此將 USER 已經獲得的徽章額外建立 TABLE 做 存取，不做重複的計算工作已減輕後端 Server 的負擔。
而在 physical data model 的部分，由於採用了 Object Relational Mapping 的架構，TABLE 的建立是在透過程式中 MODEL 的部分去操作，且為了增加彈性以 及維護性不實際賦予 Table 與 Table 間的主從鍵值關係，即每張 Table 在資料庫 的層級都是各自獨立的，而圖 15 中的關係，則是藉由程式邏輯層再賦予 Table 間的關係，以 USER、PLACE、CHECKIN 這三張 TABLE 為例，在資料庫的層級，都 是互相獨立的，刪除任一筆資料皆不會對另外三張表有所影響，而要在 CHECKIN 建立打卡紀錄資料，是從 USER 以及 PLACE 取得相關欄位值，結合時間資訊存入 CHECKIN，如圖 4.6，也由於這個設計方式，在程式邏輯上要考量到表之間不會有 相依的關係，表與表的關係僅是查詢作用，即刪除一筆 USER 資料，必須不會對 程式造成錯誤。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
，
Figure 4.6:Check in 流程圖。
而在設計上第一層的實體，USER、PLACE、BADGE 是不被刪除的，而是採用狀 態管理的方式決定是否停用，並不實際刪除該筆資料，其他的動態資料以及歷史 紀錄，都是向第一層的實體進行查詢。