基於可延伸性表格的多租戶應用程式資料綱要轉換工具 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 政治大. 基於可延伸性表格的立. ‧ 國. 學. 多租戶應用程式資料綱要轉換工具. ‧. Implementing Customizable Data Schemas sit. y. Nat. for Multi-tenant Applications n. er. io. Using Extension Table Layout al iv n Ch engchi U. 研究生：李明憲指導教授：陳. 恭. 中華民國一百一年十一月.

(2) 致謝辭今天能夠順利完成學業，首要感謝的是陳恭老師，謝謝他這兩年多來願意給我許多機會嘗試不同面向的發展，並且給我許多專業上的建議；除此之外，在平日的指導過程中，他也以嚴謹中帶點幽默的態度和我互動，讓我們之間的相處沒有任何壓力。另外，也要感謝口試委員王有禮老師以及廖峻鋒老師在口試當天的提點與指教，讓我最後能夠順利完成論文。此外，要感謝從小一路培養我到大的父母，在他們無私的關照下，我才能擁有一個好的學習環境，無顧慮地專心在我的研究上面，每個周末的晚餐時刻. 政治大再來，感謝實驗室的夥伴一路以來的協助、包容以及鼓勵。首先要感謝于立. 和父母的閒聊、關心也成了我研究生活中最好的調劑。. ‧ 國. 學. 育、文楷學長在我有技術上面的問題時，給我提點以及建議。感謝昱霖在我修課期間一起努力完成多項課程上的專題。感謝子文在我心情煩躁的時候願意陪. ‧. 我聊天解悶；感謝宸暉跟昱宇協助我完成實驗室的大小事情，減輕我許多負擔，. sit. y. Nat. 感謝佐玄擔任實驗室開心果的角色，讓實驗室充滿歡笑，紓解我的壓力。感謝. n. al. er. io. 家宇跟榆澤願意傾聽我任何大小瑣事，讓我在最後的衝刺階段能擁有一個好的. i Un. v. 傾吐空間。感謝致緯跟苑霖給了我很多協助以及建議，雖然你們不常出現，但. Ch. engchi. 總是能夠適時地幫助我解決許多問題。. 接下來，感謝我的兩位好室友：柏堯以及建成，謝謝他們在我生活上的照顧，忍耐了我很多不好的生活習慣。然後，感謝我的大學同窗好友：季儒、翌涵、辰鍵以及耀瑋，大家偶爾的聚會讓我在辛苦的研究生活中，能夠有稍微喘息的機會。最後，要感謝政大資科所的所有老師、助教以及同學們，在大家的指教以及協助之下，我才能順利地完成學業。. 2012 11 27 明憲 i.

(3) 基於可延伸性表格的多租戶應用程式資料綱要轉換工具. 摘要. 雲端運算環境的興起，軟體即服務(Software as a Service, SaaS)的營運. 政治大. 模式也開始受到軟體開發商的注意，其中一項關鍵技術是支援多租戶. 立. 的軟體開發。在設計多租戶應用程式時有許多需要考量的因素，包含. ‧ 國. 學. 每個租戶各自的客製化設定、資料安全性等等。本論文著重於資料層. ‧. 級的客製化部份，如何讓各個租戶之間可以共用資料庫，但又能提供. Nat. io. sit. y. 租戶適度地更改其資料表綱要(schema)以達到客製化的需求。. er. 為了解決資料層級客製化所面臨的問題，一種常見的作法是可延. al. n. iv n C hengchi U 伸性表格(Extension Table Layout)。但是，在關聯式資料庫中實作可. 延伸性表格，軟體開發人員為了配合可延伸性表格的資料存放方式，所使用的 SQL 語句會變得相當複雜且易錯。因此，本研究實作一個系統工具協助軟體開發人員將 SQL 語句，從一租戶一資料表寫法自動轉換成以可延伸性表格邏輯表達的 SQL 語句，透過執行轉換後的語句來對儲存在可延伸性表格的資料進行增刪修改。軟體開發人員在本系統工具的協助下，加入租戶識別碼(TenanId) ii.

(4) 的開發概念後，即可實際建立一個多租戶應用程式。為了評估本系統工具的效用，我們以其建置了一個多校(租戶)選課系統，並進行多項效能實驗以探討影響本系統工具效能的因素。初步的結果顯示，本系統工具可以協助軟體開發人員，以較低的代價滿足資料層級客製化應用的需求。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. iii. i Un. v.

(5) Implementing Customizable Data Schemas for Multi-tenant Applications Using Extension Table Layout. Abstract. Software as a service (SaaS) is an emerging service model of cloud. 治政 computing. One of the key technology in SaaS大 is supporting multi-tenant 立 applications. There are many considerations in the design of multi-tenant. ‧ 國. 學. applications, including customized configuration of tenants and data. ‧. security. In this thesis, we focus on data-level customized configuration,. sit. y. Nat. and propose an approach for not only sharing database between tenants but also supporting tenants to modify their table schemas within limits.. er. io. Extension Table Layout a is one solution for solving the problems in. n. iv l C n data-level customized configuration applications. h e n gforcmulti-tenant hi U. However, SQL statemenst based on the Extension Table Layout are rather complicated and error-prone. Thus, we develop a tool to help software developers that will automatically rewrite the SQL statements from the common Private Table Layout into those from the Extension Table Layout at runtime. In other words, our tool enable software developers to write SQL statements in a multi-tenant application like in a single tenant application. Indeed, software developers could develop a multi-tenant iv.

(6) application easily by using our tool and the multi-tenant enabler TenantId. In order to assess the feasibility of our tool, we develop an online multi-tenant course election application. Besides, we disscus the effectiveness of the factors that affecting our tool and work on a number of experiments and performance tests. The preliminary results show that our SQL rewriting tool can help software developers at a lower cost to meet the needs of data-level customized applications to a degree.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. v. i Un. v.

(7) 目錄第一章緒論 ........................................................ 1 1.1 前言 ......................................................... 1 1.2 研究動機 ..................................................... 2 1.3 研究目的 ..................................................... 5 1.4 研究成果 ...................................................... 6 1.5 論文大綱 ..................................................... 7 第二章技術背景與相關研究 .......................................... 8 2.1 多租戶應用程式之資料層級設計 ................................. 9 2.1.1 多租戶應用程式之資料層級設計分類 ......................... 9 2.1.2 Separate Databases ...................................... 10 2.1.3 Separate Schemas ........................................ 11. 政治大 2.1.4 Shared Schema 立........................................... 12 ‧. ‧ 國. 學. 2.1.5 多租戶應用程式之資料層級設計考量 ........................ 14 2.2 多租戶應用程式之資料表綱要類型 ............................... 15 2.2.1 Private Table Layout .................................... 15 2.2.2 Universal Table Layout .................................. 16 2.2.3 Extension Table Layout .................................. 17. er. io. sit. y. Nat. 2.2.4 Pivot Table Layout ...................................... 18 2.3 語句結構剖析工具 ............................................. 19 第三章系統設計 ................................................... 21. n. al. Ch. i Un. v. 3.1 系統設計理念 ................................................ 21 3.2 系統設計考量 ................................................ 23 3.3 系統流程 .................................................... 24 3.4 系統實作方法 ................................................ 26 3.4.1 Extension Table Layout 概念實作 .......................... 27 3.4.2 CREATE 語句的轉換、CREATE EXTENSION TABLE 的設計與實作 ... 28. engchi. 3.4.3 ALTER 語句的轉換 ......................................... 34 3.4.4 INSERT、UPDATE、DELETE 語句的轉換 ........................ 37 3.4.5 SELECT 語句的轉換 ........................................ 46 第四章系統實作與評估 ............................................. 49 4.1 系統實作展示 ................................................ 49 4.1.1 多租戶應用程式範例情境描述 .............................. 49 4.1.2 多租戶應用程式範例系統設計與實作 ........................ 50 4.2 系統效能之影響因素 .......................................... 59 vi.

(8) 4.3 系統效能測試 ................................................ 62 4.3.1 效能測試環境、測試項目、測試對象 ......................... 62 4.3.2 Extension Table Layout 效能測試 .......................... 63 4.3.3 Extension Table Layout 詮釋欄位建立 Index 之效能測試 ...... 64 第五章結論與未來研究方向 ......................................... 67 5.1 結論 ........................................................ 67 5.2 未來研究方向 ................................................ 68 參考文獻 .......................................................... 70. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. vii. i Un. v.

(9) 表目錄表 3.1 共用資料表與私有資料表比較圖 ................................ 29 表 4.1 PRIVATE TABLE LAYOUT 和 EXTENSION TABLE LAYOUT 測試數據表 ............ 64 表 4.2 PRIVATE TABLE LAYOUT、EXTENSION TABLE LAYOUT 和 EXTENSION TABLE LAYOUT WITH INDEX OF METADATA 測試數據表 .................................... 65. 圖目錄圖 1.1 多租戶共享模式以及單一租戶開發模式隨時間變化之開發、維運成本比較圖 ......................................................... 2. 政治大圖 1.2 一租戶一資料庫 ............................................... 3 立圖 1.3 多租戶共享一資料庫 ........................................... 3 ‧. ‧ 國. 學. 多租戶技術的開發概念示意圖 ................................... 3 三種多租戶應用程式之資料層級技術 ............................. 9 SEPARATE DATABASES 示意圖 ....................................... 10 SEPARATE SCHEMAS 示意圖 ........................................ 12 SHARED SCHEMA 示意圖 ........................................... 13. y. Nat. 圖 1.4 圖 2.1 圖 2.2 圖 2.3 圖 2.4. sit. n. al. er. io. 圖 2.5 租戶的數量以及每個租戶的資料量大小影響圖 .................... 14 圖 2.6 基礎範例(PRIVATE TABLE LAYOUT 示意圖) ........................... 15 圖 2.7 基礎範例轉換成 UNIVERSAL TABLE LAYOUT 示意圖 ..................... 16 圖 2.8 基礎範例轉換成 EXTENSION TABLE LAYOUT 示意圖 ..................... 17 圖 2.9 基礎範例轉換成 PIVOT TABLE LAYOUT 示意圖 ........................ 18 圖 2.10 JSQLPARSER 對 SQL 語句進行剖析的程式碼範例 .................... 19 圖 3.1 採用本系統工具的運作模式 .................................... 22 圖 3.2 系統工具進行語句轉換流程圖 .................................. 24 圖 3.3 MULTITENANTSTATEMENT 類別繼承關係圖 ............................. 25 圖 3.4 圖 3.5 圖 3.6 圖 3.7 圖 3.8 圖 3.9. Ch. engchi. i Un. v. 系統工具攔截軟體開發人員所撰寫的 SQL 語句程式碼範例 .......... 25 EXECUTEUPDATE()的虛擬碼 ....................................... 26 COLUMNS_METADATA TABLE 的欄位資訊存放格式 ....................... 28 CREATE 語句範例 ............................................. 30 CREATE 語句轉換後的結果 ..................................... 30 執行 CREATE 語句後，COLUMNS_METADATA TABLE 的更新結果 ............ 30. viii.

(10) 圖 3.10 圖 3.11 圖 3.12 圖 3.13 圖 3.14. INTEGRITY CONSTRAINTS 的範例 ................................... 31 CREATE EXTENSION TABLE 語句範例 ............................. 32 產生私有資料表名稱的流程 ................................... 32 實作 CREATE EXTENSION TABLE 語句概念所產生的 CREATE 語句 ..... 33 執行 CREATE EXTENSION TABLE 語句後，COLUMNS_METADATA TABLE 的更新結果 ...................................................... 33 圖 3.15 多個共用資料表存在，實作 CREATE EXTENSION TABLE 語句所產生的 CREATE 語句 ................................................ 33 圖 3.16 多共用資料表存在時，執行 CREATE EXTENSION TABLE 語句 COLUMNS_ METADATA TABLE 的更新結果 .................................... 33 圖 3.17 ALTER 語句範例 ............................................. 36 圖 3.18 ALTER 語句轉換後的結果 ..................................... 36 執行 ALTER 語句後，COLUMNS ETADATA ABLE INSERT 語句範例 ............................................ 38 系統工具自動產生計算詮釋欄位 ROW 最大值的 SELECT 語句 ........ 39 INSERT 語句轉換後的結果 .................................... 39 INSERT 語句(僅新增共有欄位資料)範例 ........................ 40 INSERT 語句(僅新增共有欄位資料)轉換後的結果 ................ 40 UPDATE 語句範例 ............................................ 41. 立. ‧. ‧ 國. 學. y. Nat. 圖 3.19 圖 3.20 圖 3.21 圖 3.22 圖 3.23 圖 3.24 圖 3.25. 政治大 _M T 的更新結果 ............ 36. sit. n. al. er. io. 圖 3.26 UPDATE 語句轉換過程中，系統工具自動產生的 SELECT WITH JOIN 語句 .................................................................. 42 圖 3.27 UPDATE 語句轉換後的結果 .................................... 43 圖 3.28 UPDATE 語句(僅更新私有欄位資料)範例 ........................ 43 圖 3.29 UPDATE 語句(僅更新私有欄位資料)轉換後的結果 ................ 44 圖 3.30 DELETE 語句範例 ............................................ 44 圖 3.31 DELETE 語句轉換過程中，系統工具自動產生的 SELECT WITH JOIN 語句 .................................................................. 45 圖 3.32 DELETE 語句轉換後的結果 .................................... 46. Ch. engchi. i Un. v. 圖 3.33 SELECT 語句範例 ............................................ 47 圖 3.34 回傳資料欄位“*”關鍵字的轉換過程 .......................... 48 圖 3.35 建立實際查詢的資料表示意圖 ................................. 48 圖 3.36 取代”*”關鍵字示意圖 ...................................... 48 圖 4.1 多校(租戶)選課系統的範例之共用資料表的資料表綱要設計 ........ 50 圖 4.2 CREATE 語句範例展示－建立共用資料表 ......................... 51. ix.

(11) 圖 4.3 CREATE、CREATE EXTENSION TABLE 語句執行後，COLUMNS_METADATA TABLE 的更新結果 .................................................. 51 圖 4.4 學校新增課程資料的展示 ...................................... 52 圖 4.5 學校新增課程資料的結果展示 .................................. 53 圖 4.6 學校點選欲修改課程的展示 .................................... 53 圖 4.7 學校進行課程資料修改的展示 .................................. 54 圖 4.8 學校修改課程資料的結果展示 .................................. 54 圖 4.9 學校新增客製化欄位的展示 .................................... 55 圖 4.10 學校新增客製化欄位的結果展示 ............................... 55 圖 4.11 客製化欄位更名的展示 ....................................... 56 圖 4.12 刪除客製化欄位的展示 ....................................... 56 圖 4.13 客製化欄位更名以及刪除客製化欄位的 ALTER 語句展示 ........... 56. 政治大圖 4.14 客製化欄位更名的結果展示 ................................... 56 立圖 4.15 學生從選課清單刪除課程的展示 ............................... 57 ‧. ‧ 國. 學. 圖 4.16 學生從選課清單刪除課程的結果展示 ........................... 57 圖 4.17 學生查詢選課清單的 SELECT 語句與結果 ........................ 58 圖 4.18 依 PRIVATE TABLE LAYOUT 的概念設計其資料層級，進行新增共有欄位的 ALTER 語句範例 ............................................. 59 圖 4.19 依 EXTENSION TABLE LAYOUT 的概念設計其資料層級，進行新增共有欄位的. y. Nat. sit. n. al. er. io. ALTER 語句範例 ............................................. 59 圖 4.20 租戶的數量對 INSERT、DELETE 語句造成的影響 .................. 60 圖 4.21 租戶的數量對 UPDATE 語句造成的影響 .......................... 61 圖 4.22 租戶的數量對 SELECT 語句造成的影響 .......................... 61 圖 4.23 PRIVATE TABLE LAYOUT、EXTENSION TABLE LAYOUT 和 EXTENSION TABLE LAYOUT WITH INDEX OF METADATA 在測試項目一與測試項目二的比較圖 ............. 65 圖 4.24 PRIVATE TABLE LAYOUT、EXTENSION TABLE LAYOUT 和 EXTENSION TABLE LAYOUT WITH INDEX OF METADATA 在測試項目三、四以及測試項目五的比較圖 ....... 66 圖 4.25 PRIVATE TABLE LAYOUT、EXTENSION TABLE LAYOUT 和 EXTENSION TABLE LAYOUT WITH. Ch. engchi. i Un. v. INDEX OF METADATA 在測試項目六與測試項目七的比較圖. x. ............. 66.

(12) 第一章緒論 1.1 前言雲端運算的技術和架構是目前十分受到重視的研究議題，同時，也是各個軟體大廠競相努力發展的目標。根據 NIST 的定義[Mell et al.11]：雲端運算是一. 政治大. 種藉由網路存取所配置的共享資源(network、server、storage、application、. 立. and service)，以最小的成本做管理工作以及運算資源的配置。. ‧ 國. 學. 隨著雲端運算環境的興起，軟體即服務(Software as a Service, SaaS)的營運模式也開始受到軟體開發商注意。不同於以往到客戶端安裝(on-premises)，. ‧. 供單一用戶使用的模式，SaaS 的主要特色是在資料中心安裝，以多租戶(multi-. y. Nat. io. sit. tenants)方式營運：每個租戶的使用者透過網路使用該應用程式，其運作所需. n. al. er. 的軟硬體設施由資料中心與應用程式的軟體開發人員負責維運，租戶只需按使. Ch. i Un. v. 用量與服務品質等因素依合約付費。在設計多租戶應用程式架構時有許多需要. engchi. 考量的因素，包含租戶各自的客製化設定、資料安全性等等，要能達到獨立而不會受到其他租戶的影響，這些對 SaaS 服務而言都非常的重要，否則，一旦一個租戶在使用時發生狀況，其他租戶可能就會連帶的受到影響。由於此種開發模式在軟硬體資源的使用上相當可觀，軟體開發人員不可能為了每一個租戶都提供一台實體的機器，所以，提供具安全性的共用資料架構、客製化組態為多租戶技術所面臨到的問題。. 1.

(13) 1.2 研究動機由於中小企業常常基於預算而無法獨立負擔一個私有應用程式開發以及維運，所以，軟體開發商採用多租戶共享資源的模式企圖減少開發以及維運成本，同時，這些減少的成本反應在對租戶的收費以符合中小企業的預算。藉此，軟體開發商渴望長尾效應[Chong et al.06]的發生，透過較低的租用價格去吸引中小企業，擴大消費市場並接觸到更多消費者。如圖 1.1 所示，採用多租戶共享資源的模式在開發初期由於技術層面大多尚未成熟，因此，可預期到相較於單一租戶的開發模式來說，需要花費較大的. 治政成本進行技術的探索以及設計；但相對地，軟體開發人員採用該模式可以在有大立限的軟硬體環境下，透過多租戶共享軟硬體資源，提供服務給較多數量的租戶； ‧ 國. 學. 另一方面，藉由多個租戶分攤軟硬體資源費用，例如：軟體授權費用、硬體設. ‧. 備成本等，亦可以減少每個租戶實際所需負擔的花費以解決中小企業基於預算. sit. y. Nat. 而無法獨立負擔一個私有應用程式開發以及維運的問題。長期看來，可以預期. io. al. n. 及維運來得低。. er. 每個租戶實際花費的所有租用成本會相對於獨立負擔一個私有應用程式開發以. Ch. engchi. i Un. v. 圖 1.1 多租戶共享模式以及單一租戶開發模式隨時間變化之開發、維運成本比較圖. 多租戶技術主要提出兩項目標，第一項是在軟硬體資源上達到租戶共享以減少開發成本；第二項是在共享資源的前提下亦可以提供每個租戶以自助的方式適度地客製化以達到擴充性。目前在實作多租戶應用程式之資料層級設計有兩種作法，第一種作法是一租戶一資料庫（如圖 1.2 所示），此種作法在成本上 2.

(14) 極為浪費，無法達到多租戶技術所提出的資源共享目標；第二種作法是多租戶共享一資料庫（如圖 1.3 所示），此種作法雖能達到多租戶資源共享，但缺乏擴充性，所有的租戶都必須使用同一種資料表綱要，無法滿足客製化的需求。本研究嘗試在上述第一種和第二種作法中找到一個平衡點，提供一種既可以讓多租戶共享資料庫又可以提供租戶適度地客製化其資料表綱要的作法。. 1.3 多租戶共享一資料庫政治圖大圖 1.4 為多租戶技術的開發概念示意圖，藉由一個應用程式搭配租戶共享立圖 1.2 一租戶一資料庫. ‧ 國. 學. 資料庫的模式可以提供服務給多個租戶使用。圖 1.4 中三個租戶透過網路介面設定或是撰寫設定檔的方式對租用的應用程式進行相關設定，例如：設定應用. ‧. 程式的使用介面、適度地客製化資料欄位等動作；軟體開發人員則從應用程式. sit. y. Nat. 加入每個租戶所獨有的租戶識別碼(TenantId)並迭代到資料層級，所以，不論. n. al. er. io. 是應用程式或是資料層級皆可以透過租戶識別碼(TenantId)去辨識租戶以完成該租戶及其使用者所交付的任務。. Ch. engchi. i Un. v. 透過網路介面設定或是撰寫設定檔的方式去對應用程式客製化. 圖 1.4 多租戶技術的開發概念示意圖. 3.

(15) 以開發一個多校(租戶)選課系統為例，軟體開發人員可能會提供一個課程資料表來存放課程資訊頁面所顯示的資料，其中包含了許多欄位，例如：課程名稱欄位、上課老師名稱欄位等，上述這些欄位都是每個租戶在課程資訊頁面共同需要的資料欄位，稱之為共有欄位；但由於每個租戶在課程資訊頁面的資料會有些不同，這裡，透過租戶建立其獨自擁有的私有欄位，讓每個租戶的課程資訊頁面上除了顯示共有欄位資料以外還有租戶自己獨有的私有欄位(客製化欄位)資料。但在開發過程中，由於軟體開發人員無法預先得知租戶會建立哪些私有欄位，所以，不會單獨針對私有欄位資料進行功能設計，私有欄位資料通常是扮演與共有欄位資料一起顯示在頁面上的角色，例如：當學生進到課程. 治政資訊的頁面時，應用程式可能會執行 SELECT 語句，將共有欄位資料以及私有欄大立位資料一起顯示在頁面，所以，不同租戶的課程資訊頁面，可能因為擁有不同 ‧ 國. 學. 的私有欄位而造成頁面顯示的內容有所不同。. ‧. 如同上一段所敘述的，站在軟體開發人員的角度，由於無法預測各個租戶. sit. y. Nat. 的私有欄位(即客製化欄位)，所以，軟體開發人員在開發、維運的階段只曉得. io. er. 共有欄位的存在，因此，只會針對共有欄位資料進行多租戶應用程式的功能設計。倘若能夠提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力，. n. al. ni Ch 則可以增加開發以及維運上的方便性。 U engchi. v. 在 2.2.1 小節所介紹的 Private Table Layout 雖符合在多租戶共享資料庫的情況下亦可以提供租戶適度地客製化其資料表綱要的能力(這裡所提到的” 租戶適度地客製化其資料表綱要的能力”是指租戶在不影響軟體開發人員所建立的共有欄位前提下，能夠以自助的方式透過設定來新增(建立)有別於其他租戶的私有欄位，亦即客製化欄位，此後，租戶也可以自行去更改這些私有欄位的資料型態或是欄位名稱，甚至在不需要這些私有欄位的時候進行刪除私有欄位的動作)；但是，在眾多考量因素下，相對於 Private Table Layout，2.2.3 小節所描述的 Extension Table Layout 更適合多租戶應用程式之資料層級設計，. 4.

(16) 其所提出共有欄位、私有欄位的觀念，除了可以滿足租戶適度地客製化其資料表綱要的需求外，亦可以提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力。簡單來說，採用 Extension Table Layout 的概念，租戶以自助的方式建立其私有欄位，滿足租戶客製化欄位的需求；軟體開發人員統一管理租戶的共有欄位以及其資料則可以減少在維運多租戶應用程式時修改既有資料表綱要以及資料所花費的時間成本，例如：軟體開發人員在開發新服務的過程中，倘若需要修改已存在的資料表綱要(schema)，則可以透過共有欄位的修改代替逐一對個別租戶資料表欄位修改的動作，節省其所花費的時間成本。. 1.3 研究目的. 政治大. 立. ‧ 國. 學. 採用 Extension Table Layout 的概念進行多租戶應用程式之資料層級設計，除了可以達到租戶客製化欄位的目標外，亦可以提供軟體開發人員對租戶的共. ‧. 有欄位以及其資料進行統一管理的能力。但是，軟體開發人員在撰寫 SQL 語句. sit. y. Nat. 時，為了配合 Extension Table Layout 的資料存放方式，所以，無法沿用一租. n. al. er. io. 戶一資料表的寫法來撰寫 SQL 語句。為了解決上述問題，本研究將實作一套系. i Un. v. 統工具協助軟體開發人員將 SQL 語句從一租戶一資料表寫法轉換成以 Extension. Ch. engchi. Table Layout 邏輯表達的 SQL 語句，透過執行轉換後的語句來對儲存在可延伸性表格的資料進行增刪修改。本研究的主要目標有： 1. 開發一套系統工具，協助軟體開發人員可以沿用一租戶一資料表的寫法開發應用程式，但透過 SQL 語句的改寫，資料層仍可以是以 Extension Table Layout 方式來儲存資料。 2. 評估以我們發展的工具來開發 Extension Table Layout 多租戶應用程式之資料層級設計的可行性。. 5.

(17) 在本系統工具的協助下，軟體開發人員以 Extension Table Layout 的概念進行多租戶應用程式之資料層級設計，使用 JDBC 介面進行資料庫的操作，沿用一租戶一資料表的 SQL 語句邏輯對資料進行增刪修改以及查詢等動作；系統工具則改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句，有系統地將 SQL 語句轉換成以 Extension Table Layout 邏輯表達的 SQL 語句並在資料庫上執行。. 1.4 研究成果. 政治大 Layout 的邏輯歸納出語句轉換步驟，同時，實作系統工具協助軟體開發人員立. 基於上述的研究動機以及目的，蒐集相關的技術資料，依據 Extension Table. ‧ 國. 學. 雖以 Extension Table Layout 的概念進行多租戶應用程式之資料層級設計，卻可以沿用一租戶一資料表的 SQL 語句邏輯撰寫 SQL 語句。另外，採用本系. ‧. 統工具協助開發多租戶應用程式展示使用本系統工具所帶來的優點。最後，. sit. y. Nat. 透過一連串的實驗推斷出影響此系統工具效能的因素並模擬多租戶共用資料. n. al. er. io. 庫的環境進行多項測試以評估此作法的可行性。本研究的主要成果有：. Ch. engchi. i Un. v. 1. 實作系統工具協助軟體開發人員將 SQL 語句從一租戶一資料表寫法轉換成以 Extension Table Layout 邏輯表達的 SQL 語句，透過執行轉換後的語句來完成軟體開發人員原先所預期達到的目的。 2. 採用本系統工具實際開發一個多校(租戶)選課系統並從開發過程中展示採用 Extension Table Layout 提出的共有欄位、私有欄位所帶來的優點 (提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力以降低維運所需花費的時間成本、滿足租戶適度地客製化其資料表綱要的需求)。. 6.

(18) 3. 探討影響本系統工具效能的因素，另外，實際測試本系統工具在效能上所造成的影響並根據其測試結果評估此作法的可行性。. 1.5 論文大綱本論文分成五個章節，第一章為緒論，主要對研究的動機、目的進行解說，同時，簡單地對系統工具的實作設計、研究結果作概略性說明。第二章主要介紹三種多租戶應用程式之資料層級設計，另外，介紹 SQL 語句結構剖析之工具－JSqlParser 的相關技術。第三章則完整地從設計層面到實作層面對本. 政治大租戶應用程式之資料層級設計以展示採用本系統工具的優點。另外，進行一立. 系統工具的核心架構進行詳細地解說。第四章將實際使用本系統工具協助多. ‧ 國. 學. 連串的實驗，藉著實驗結果推斷影響本系統工具執行時間的因素。最後，進行多項測試去更進一步地了解實際使用本系統工具在效能上會造成哪些影響. ‧. 並根據其結果進行可行性評估。在最後第五章的部分，提出結論並探討未來. n. al. er. io. sit. y. Nat. 值得深入研究的發展方向以及相關議題。. Ch. engchi. 7. i Un. v.

(19) 第二章技術背景與相關研究多租戶(Multi-Tenancy)技術主要希望可以讓多個租戶(這裡的”租戶”泛指每個向軟體開發人員租用服務的客戶)共同使用一個運算環境或是應用程式，同時，提供完善的隔離技術以維護每個租戶的資料安全性。此外，亦要讓不同的租戶. 政治大採用多租戶技術可以創造許多實質上的效益。對軟體開發人員來說，可以立. 以自助的方式透過網路介面進行功能設定以達到客製化的效果。. ‧ 國. 學. 透過多租戶共享資源以達到在有限軟硬體設備下，提供服務給最多租戶數量的目的；此外，租戶們透過分攤軟體授權費用以及硬體設備成本的方式，降低其. ‧. 租用應用程式所需負擔的成本。另一方面，在這種共享的架構下，租戶亦可以. y. sit. Nat. 享受到每次應用程式所更新的服務，增加其使用功能。. n. al. er. io. 本研究著重於資料層級的客製化部份，如何讓各個租戶之間可以共用資料. i Un. v. 庫，但又能提供租戶適度地更改其資料表綱要(schema)以達到客製化的需求。. Ch. engchi. 首先，在 2.1 小節多租戶應用程式之資料層級設計中，依照租戶資料存放的共享程度分成三種類型的資料層級設計架構並逐一詳細探討，最後，歸納出實際在進行多租戶應用程式之資料層級設計時所需考量的因素。為了在多租戶共用資料庫的前提下，達到租戶適度地客製化其資料表綱要的需求，在 2.2 小節中將介紹四種符合上述需求的多租戶應用程式之資料表綱要類型，其中，2.2.3 小節的 Extension Table Layout 提出了共有欄位、私有欄位的觀念，除了滿足租戶客製化欄位的需求外，亦可以提升軟體開發人員對租戶共有欄位以及其資料進行統一管理的能力，藉此可以讓軟體開發人員更容易開發多租戶應用程式。 Extension Table Layout 的資料存放方式會讓軟體開發人員無法沿用一租 8.

(20) 戶一資料表的寫法撰寫 SQL 語句。為了讓軟體開發人員雖以 Extension Table Layout 的概念進行多租戶應用程式之資料層級設計，卻可以沿用一租戶一資料表的 SQL 語句邏輯對資料進行增刪修改，所以，本研究實作一套系統工具將 SQL 語句從一租戶一資料表寫法轉換成以 Extension Table Layout 邏輯表達的 SQL 語句。在進行實際的語句轉換之前，本系統工具必需對 SQL 語句進行結構剖析以獲得語句轉換過程中所需的語句元素，2.3 小節所介紹的 SQL 語句結構剖析工具-JSqlParser 則可以協助系統工具進行語句結構剖析並提供語句元素以利後續的語句轉換動作。. 政治大 2.1 多租戶應用程式之資料層級設計立. ‧ 國. 學. 進行多租戶應用程式之資料層級設計時，如何提高租戶間資料存放的共享程度是很重要的議題。下列各小節中，將探討三種不同共享程度的多租戶應用程. ‧. 式之資料層級設計(圖 2.1)，並在後續的各個小節中，針對每一種技術在開發上. sit. y. Nat. 所面臨的問題進行探討並作出經濟效益上的評估，最末節提出在多租戶應用程. n. al. er. io. 式之資料層級設計時所需要考量的因素。. i Un. Ch. v. engchi 2.1.1 多租戶應用程式之資料層級設計分類. 共享程度. 圖 2.1 三種多租戶應用程式之資料層級技術 (Separate Databases、Separate Schemas、 Shared Schema)共享程度示意圖. 9.

(21) 多租戶應用程式之資料層級設計依租戶資料存放的共享程度，如圖 2.1 所示，可以簡單地分成三類，從租戶資料存放的共享程度由低到高，分別是 : Separate Databases、Separate Schemas 以及 Shared Schema[Chong et al.06]。採用 Separate Databases 的開發過程較容易且租戶的資料安全性也較高，但是，由於每個租戶都要負擔費用去建置、維護硬體設備，所以，在經濟效益上相對於其它兩種技術來得低；採用 Separate Schemas 以及 Shared Schema 雖在初期的開發過程需要較長的時間且需提供額外的機制去加強租戶資料的隔離性，但是，由於租戶間資源共享程度較高，所以，可以降低每個租戶所需負擔的費用。. 政治大 2.1.2 Separate Databases 立. ‧ 國. 學. Separate Databases 主要是將每個租戶的資料存在放在各自的獨立資料庫中，以圖 2.2 為例，假定有三間學校(租戶)，分別為 Nccu、Fju 以及 Tku，每間學校. ‧. 皆有三個資料表，分別是 StudentInfo(儲存該校學生資料)、SelectCourse(儲. sit. y. Nat. 存該校學生選課記錄)以及 CourseInfo(儲存該校課程資料)，每間學校提供一個. n. al. er. io. 獨立的資料庫，讓每間學校可以各自將自己的資料存放在各自的獨立資料庫。. Ch. engchi. i Un. v. 圖 2.2 Separate Databases 示意圖:各個 Tenant 的資料存放在各自獨立的 Database. 10.

(22) 因為每個租戶各自擁有一個資料庫來存放自己的資料，所以，可以達到很高的資料安全性，資料表綱要(schema)也較容易依照各個租戶的需求來做異動，客製化的程度較高。除此之外，資料一旦損壞或遺失，單一租戶的還原資料 (restore data)的程序也比較容易，只需要獲得該租戶的備份資料(back-up data)來進行還原資料(restore data)的動作。但相對地，以經濟效益的層面看來，採用這種方法的租戶(例如:銀行、醫院)主要是為了達到高度的資料安全性 (銀行交易資料、醫院病歷資料)以及客製化，所以，需要負擔較高額的費用去提供硬體設備以及往後的設備維護[Chong et al.06]。由於採用這種方法必需為每個租戶提供一套硬體設備，因此，在有限的硬. 治政體設備下只能提供給有限數量的租戶，不符合經濟效益上的期望。在接下來的大立小節，將提出兩種方法(Separate Schemas、Shared Schema)可以透過技術來突 ‧ 國. 學. 破有限的硬體環境，實現多租戶的理想。. ‧. Nat. io. sit. y. 2.1.3 Separate Schemas. n. al. er. Separate Schemas 主要是將每個租戶的資料存放在同一個的資料庫中，同時，. Ch. i Un. v. 每個租戶又各自擁有各自的資料表集合，不同的租戶之間，資料表綱要(schema). engchi. 也不完全相同。以圖 2.3 為例，假定有三間學校(租戶)，分別為 Nccu、Fju 以及 Tku，每間學校可以根據自己的需求去制訂屬於自己的資料表綱要(schema) 以及資料表集合存放在同一個資料庫裡。從圖 2.3 的紅色方框部份可以發現 Nccu 的 CourseInfo 資料表綱要和另外兩間學校的 CourseInfo 資料表綱要有明顯的不同，這就是本研究一直提到的重點：租戶可以擁有客製化欄位的能力。由於各個租戶都擁有各自的資料表集合，所以，仍然可以根據自己的需求制定資料表綱要(schema)。但還是有一些缺點，一旦有一個租戶的資料表毀損或是資料遺失，還原資料(restore data)的程序就會比採用 Separate Databases. 11.

(23) 來得複雜，必須利用備份資料(back-up data)對整個資料庫進行還原資料 (restore data)的動作才能解決問題[Chong et al.06]。. Nccu. Nccu. Fju. Nccu. 立. Tku 政治大Nccu. ‧. ‧ 國. 學. 圖 2.3 Separate Schemas 示意圖:各個租戶將各自不同的資料表綱要. y. Nat. io. sit. 以及資料表集合存放在同一個資料庫. n. al. er. 此外，這種方法將所有租戶的資料都存放在同一個資料庫中，因此，不同. Ch. i Un. v. 租戶間的資料隔離程度降低，同時，資料的安全性也相對降低，所以，”如何. engchi. 設計好的隔離機制以防止租戶的資料遭到攻擊”變成了一個很重要的議題。在有限的硬體設備下，和採用 Separate Databases 方法相比，這種方法能夠提供服務給較多的租戶，相對地，每個租戶所需要負擔的費用也大幅降低，但有一個重要的前提是租戶要能夠了解並且同意它的資料和其它租戶的資料是放在同一個資料庫中；軟體開發人員也要事先將一些安全上的顧慮告知租戶並且提供相對應的隔離機制來有效地提升資料的安全性。. 2.1.4 Shared Schema 12.

(24) 這種方法是利用資料庫裡面的單一資料表去存放所有租戶的資料，並將資料依序存放在共用表格欄位 (Col1、Col2、Col3、Col4…) 中，利用 TenantId 以及 Table 這兩個欄位作為依據去區分不同的租戶的資料(record)。以圖 2.4 為例，假定有三間學校(租戶)，分別為 Nccu、Fju 以及 Tku，其相對應的 TenantId 即以其學校英文代號表示(即 Nccu、Fju 以及 Tku)，利用 Table 欄位(1、2、3…) 去區分不同的資料表，例如：同樣 TenantId 為 Nccu，但 Table 欄位不同(1、2) 則代表兩個同租戶但存放不同資料的資料表(圖 2.4 中綠色及藍色方框)。共用欄位(Col1、Col2、Col3、Col4…)則依照每個租戶自訂的資料表綱要(schema) 去依序存放每一筆紀錄(record)。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. 圖 2.4 Shared Schema 示意圖:各個租戶將各自的資料表存放在同一個資料庫的單一資料表中. al. n. iv n C 由於所有的租戶資料都存放在同一個資料表中，所以，可支援的租戶數目 hengchi U. 增加了，因此，和上述兩種方法相比，租戶所需負擔的費用更低。但同時，資料的安全性就降低許多，如果沒有好的隔離機制去區分租戶，很容易會讓租戶的資料遭受攻擊。除此之外，還需要額外提供資料表去紀錄每個租戶所有資料表的詮釋欄位(meta-data)，以協助之後執行資料庫存取動作。另外，還原資料 (restore data)的部份，一旦有資料毀損或是遺失，則需要將整個資料庫進行還原資料(restore data)的動作才能解決問題[Chong et al.06]。相對於前兩種方法，採用 Shared Schema 方法更能充分地利用硬體設備，簡單來說，也就是在有限的硬體設備下，提供給相較於上述所有方法中最多的. 13.

(25) 租戶數量，但同樣地，前提是租戶必需要能夠同意它的資料和其它租戶的資料是放在同一個資料表中，此外，軟體開發人員也要事先將一些安全上的顧慮告知租戶並且提供相對應的隔離機制來有效地提升租戶間的資料安全性。. 2.1.5 多租戶應用程式之資料層級設計考量上述的三種多租戶應用程式之資料層級設計在經濟效益以及開發層面各有優缺點，所以，必需先了解租戶的需求並且在經濟效益上做適當的評估，在[Chong et al.06]也列出以下三項考量因素： 1. 經濟效益的考量：依據經濟效益的考量，在一定數量的硬體設備下，採用. 治政 Shared Schema 可以提供服務給最多數量的租戶，但是，軟體開發人員必需大立事先將一些安全上的顧慮告知租戶並且提供相對應的隔離機制來有效地提 ‧ 國. 學. 升資料的安全性。. ‧. 2. 資料的安全性：當租戶資料是屬於需要較高的安全性(例如:醫療紀錄、銀行. sit. y. Nat. 交易資料)的資料，則採用 Separate Databases 會較為適當。但事實上，如. io. 可以提供高度的資料安全性。. al. iv n C 租戶的數量以及需求：租戶的數量、每個租戶的資料量大小都會影響到多租 hengchi U n. 3.. er. 果採用 Shared Schema、Separate Schemas，額外搭配一些隔離機制，也是. 戶應用程式之資料層級設計。如圖 2.5 所示，若租戶的數量很多，則採用 Shared Schema 會比較節省成本；若每個租戶所存放的資料量很大，則採用 Separate Databases 的方式或許比較合適。 Separate Databases. Separate Schemas. Shared Schema. 租戶的數量每個租戶的資料量大小. 圖 2.5 租戶的數量以及每個租戶的資料量大小影響圖 14.

(26) 2.2 多租戶應用程式之資料表綱要類型目前實作多租戶應用程式之資料層級設計有兩種方式。一租戶一資料庫的方式在成本上極為浪費，無法達到資源共享的理念；多租戶共享一資料庫的方式雖然符合資源共享的理念，但缺乏擴充性，所有的租戶都必需使用同一種資料表綱要(Schema)，無法達到客製化的理想。所以，在接下來的各個小節中，將在上述二種方式中找到一個平衡點，從資料表綱要設計的面向，提供多種既可讓租戶共享資料庫又可滿足租戶適度地客製化欄位需求的資料表綱要類型。. 政治大 2.2.1 Private Table Layout 立. ‧ 國. 學. 假設目前有三間學校(租戶)： Nccu、Fju、Tku，圖 2.6 是每間學校都要使用的一個資料表：CourseInfo。所有學校的 CourseInfo 資料表都有 CourseId、. ‧. CourseName、Instructors、Credit、Days、Time 這六個共有欄位，但也有各間. n. al. er. io. sit. y. Nat. 學校各自擁有的私有欄位(即客製化欄位)以表達客製化欄位的需求。. Ch. engchi. i Un. v. 圖 2.6 基礎範例(Private Table Layout 示意圖)：三間學校(租戶)各別擁有不同的 CourseInfo 資料表，有共有欄位，同時，也有各別租戶所需要的私有欄位以表達客製化欄位需求 15.

(27) Private Table Layout [Aulbach et al.08]，此種方法是將不同租戶的資料放置在不同的資料表，這是最常見、最簡單的多租戶應用程式之資料表綱要設計。主要優點是租戶客製化資料表綱要的程度高，缺點是當租戶的數量一增加，其資料表的數量也隨之增加，且無法達到資源共享的理想。後面的章節將以此範例為基礎，介紹其他三種多租戶資料表綱要的設計技巧。. 2.2.2 Universal Table Layout Universal Table Layout [Aulbach et al.08]，此種方法是將所有租戶的資料. 治政放置於一個共用資料表中，同時，為了支援租戶間資料欄位的差異，它是採稀大立疏矩陣的方式來存放資料。具體而言，共用資料表的資料欄位是所有租戶的聯 ‧ 國. 學. 集，簡單以流水號命名(Col1、Clo2、…)，並以新增的 TenantId 欄位與 Table. n. al. er. io. sit. y. Nat. 展示這種作法。. ‧. 欄位(圖 2.2 中紅色方框)來區分不同租戶的資料。圖 2.7 以上述的基礎範例來. Ch. engchi. i Un. v. 圖 2.7 基礎範例轉換成 Universal Table Layout 示意圖. Universal Table Layout[Aulbach et al.08]的主要優點是無論多少個租戶都只需要一個資料表以滿足多租戶共用資料庫的基本需求。但因為不同租戶間的資料差異，所以，也造成一些缺點：(1)因為不同租戶間的資料差異，部份欄位會有浪費的情況發生，圖 2.7 中綠色方框即為此類欄位。(2)因為不同租戶間的資料差異，部份資料欄位的資料會有異質性型別的情況(例如，Col7 有字串 16.

(28) 也有數字)。(3)需要額外的 meta-data 去記錄欄位名稱。. 2.2.3 Extension Table Layout Extension Table Layout[Aulbach et al.08]，此種作法是將租戶共有的欄位提出放置於一個資料表，並以新增的 TenantId 欄位與 Row 欄位(圖 2.8 中紅色區塊)來區分不同租戶的資料。其它個別租戶私有的資料欄位(user column)則分別寫入不同的資料表中。圖 2.8 以上述的基礎範例來展示這種作法，其中欄位 Row 是用來標記表格內資料紀錄(record)的編號。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 2.8 基礎範例轉換成 Extension Table Layout 示意圖. Extension Table Layout[Aulbach et al.08]的主要優點是透過共有欄位的集中存放，可以統一管理共有欄位的部分。但也存在著一些缺點：(1)共用資料表中需額外增加一些詮釋欄位(meta-data)來區分不同的租戶，圖 2.8 中紅色方框即代表此資料表的詮釋欄位。(2)讀取資料的時候，需要執行較費時的 JOIN 指令。(3)跟 Private Table Layout 的作法一樣，仍然有資料表數量隨租戶數量增加而增加的問題。. 17.

(29) 2.2.4 Pivot Table Layout Pivot Table Layout[Aulbach et al.08]，此種作法是將所有租戶的資料依其資料型別來分別存放在不同的資料表，即同一型別的資料放置於同一個資料表，並以新增的 TenantId 欄位、Table 欄位、Col 欄位以及 Row 欄位來區分不同租戶的資料。其餘的欄位用來放置實際的租戶資料。圖 2.9 以上述的基礎範例來展示這種作法。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 2.9 基礎範例轉換成 Pivot Table Layout 示意圖. Pivot Table Layout[Aulbach et al.08]的主要優點是加入了資料型別的處理，同時，也不會有欄位浪費的情況發生。但共用資料表中需額外增加不少的詮釋欄位（meta-data）來區分不同的租戶，圖 2.9 中紅色方框即代表此資料 18.

(30) 表的詮釋欄位。. 2.3 語句結構剖析工具在 SQL 語句轉換成以 Extension Table Layout 邏輯表達的 SQL 語句過程中，必需先取得 SQL 語句中的語句元素，以圖 2.10 為例，其 UPDATE 語句是由資料表名稱(CourseInfo)、更新欄位以及其更新欄位數值(Days = ‘Tue’, Time = ‘D56’)、WHERE 條件式(CourseName = ‘軟體工程’)這三項語句元素所構成的。本研究將採用 JSqlParser 來協助系統工具進行語句結構剖析的動作。. 治政 JSqlParser 可以在 Java 程式中進行 SQL 語句的結構剖析並將其結構內容轉大立換成一種階層式的 Java 類別，並以 vistor pattern 的方式去操作這些 Java 類 ‧ 國. 學. 別。下圖 2.10 是一個 JSqlParser 對 SQL 語句進行剖析的程式碼範例。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 2.10 JSqlParser 對 SQL 語句進行剖析的程式碼範例. 以圖 2.10 程式碼為例，圖中名為 sql 的 String 物件是即將進行結構剖析的 SQL 語句(line 1)，首先，建立一個名為 pm 的 CCJSqlParserManager 物件(line 2)。接下來，藉由 parse()函式對名為 sql 的 String 物件進行語句 19.

(31) 結構剖析，同時，將剖析後獲得的語句元素存放在名為 updatestmt 的 Update 類別物件中(line 4)。最後，透過 getColumn()、getExpressions()、 getTable()以及 getWhere()這四個 getter 函式(line 7-13)來取得所需的語句元素，包含更改欄位(例如：[Days,Time])、更改欄位數值(例如：[‘Tue’, ’D56’])、資料表名稱(例如：CourseInfo)以及 Where 條件式的內容(例如： CourseName=‘軟體工程’)，並將取得的資訊儲存在 columns、expressions、 table 以及 where 這四個變數中以協助後續的語句轉換動作。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 20. i Un. v.

(32) 第三章系統設計基於多租戶技術的概念，在租戶資源共享的情況下，也要讓租戶以自助的方式去客製化其資源，所以，本研究在租戶共享資料庫的前提下，以提供租戶適度地客製化其資料表綱要的能力納入主要的設計考量，另外，由於採用 Extension. 政治大的共有欄位以及其資料的能力。本系統工具透過改寫 JDBC 的部分 API 去攔截軟立 Table Layout 的概念進行設計，因此，也可以提升軟體開發人員統一管理租戶. ‧ 國. 學. 體開發人員所撰寫的 SQL 語句；接下來，將攔截到的 SQL 語句交給 JSqlParser 進行結構剖析以獲得語句元素；再來，重組獲得的語句元素，將 SQL 語句從一. ‧. 租戶一資料表寫法轉換成以 Extension Table Layout 邏輯表達的 SQL 語句；最. sit. y. Nat. 後，將轉換後的 SQL 語句在資料庫中執行以進行資料表綱要的建立、更改或是. n. al. er. io. 資料的增刪修改以及查詢等動作。本章節將針對系統設計的部分進行詳細地解. i Un. v. 說，包含了系統設計理念、系統設計考量、系統流程以及系統實作方法。. Ch. engchi. 3.1 系統設計理念現今的多租戶應用程式之資料層級大部份是以 Private Table Layout 的概念去設計，雖然可以提供租戶客製化其資料表綱要的能力，但此種方式容易造成軟體開發人員在多租戶應用程式維運上的不便，倘若開發一個新服務的過程中，需要修改已存在的資料表綱要，則軟體開發人員要逐一針對每個租戶的資料表綱要(schema)進行修改，當租戶的數量或是受影響的資料表綱要(schema)逐漸增加，這無非是一個很費時的工程。相較之下，採用 2.2.3 小節 Extension Table 21.

(33) Layout 的概念更符合多租戶應用程式之資料層級的需求，其所提出的共有欄位、私有欄位概念可以提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力；除此之外，亦可以讓租戶建立私有欄位，也意味著滿足租戶適度地客製化欄位的需求。但是，當資料以 Extension Table Layout 的資料存放方式儲存，會讓軟體開發人員在撰寫 SQL 語句時，為了配合實際資料存放方式而無法採用一租戶一資料表寫法撰寫 SQL 語句，造成軟體開發人員在開發上的困難。為了解決上述採用 Extension Table Layout 的概念對軟體開發人員所造成的困難，本研究實作一套系統工具將 SQL 語句從一租戶一資料表寫法轉換成以. 治政 Extension Table Layout 邏輯表達的 SQL 語句，讓軟體開發人員可以沿用一租大立戶一資料表的 SQL 語句邏輯對以 Extension Table Layout 的資料存放方式儲存 ‧ 國. 學. 的資料進行增刪修改。. ‧. 因此，在應用程式的部分，軟體開發人員透過 JDBC 的 API 以標準的 SQL 語. sit. y. Nat. 句邏輯撰寫 SQL 語句來表達其所要對資料庫進行的動作，同時，設定 TenantId. io. er. 讓本系統工具知道其所要執行 SQL 語句的對象(租戶)。透過語句轉換機制的處理，產生以 Extension Table Layout 邏輯表達的 SQL 語句並在資料庫上執行，. n. al. ni Ch 完成軟體開發人員原先所要達到的目的。(圖 3.1) U engchi. 圖 3.1 採用本系統工具的運作模式. 22. v.

(34) 3.2 系統設計考量在進行多租戶應用程式之資料層級設計時需要經過多方面的考量，除了軟體開發人員利用共享資源的概念，在有限的資源設備下，提供服務給更多的租戶之外，站在租戶以及軟體開發人員的角度也有其他的考量要素，對租戶而言，應該要讓租戶能夠適度地客製化其資料表綱要；對軟體開發人員而言，應該要提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力。接下來，會針對這兩點進行細部的探討： 1. 提供租戶適度地客製化其資料表綱要的能力：. 治政實際開發一個多租戶應用程式，在資料表的部份，除了存在軟體開發人員大立所建立的共有欄位以外，提供租戶根據其需求在其資料表中新增、修改以及刪 ‧ 國. 學. 除私有欄位(客製化欄位)是一個很重要的需求，畢竟，每個租戶的資料表綱要. ‧. (schema)不盡相同。採用 Extension Table Layout 其所提出的私有欄位概念讓. io. er. 提供租戶適度地客製化其資料表綱要的能力”。. sit. y. Nat. 租戶針對各自的需求新增、修改以及刪除其獨有的私有欄位為本研究所強調的”. 2. 提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力：. al. n. iv n C 這裡，先定義甚麼是統一管理租戶的共有欄位以及其資料的能力，如同 1.2 hengchi U. 小節所提到的，站在軟體開發人員的角度，由於在開發階段無法預測租戶會建立哪些私有欄位(即客製化欄位)，只曉得共有欄位的存在，所以，只會針對共有欄位進行多租戶應用程式的系統功能設計，因此，如果能提升軟體開發人員統一管理租戶的共有欄位以及其資料的能力，則可以方便軟體開發人員進行開發以及維運。如同上一章節所敘述的，現今的多租戶應用程式之資料層級大部份是以 Private Table Layout 的概念去進行設計，此種開發方式雖然直覺、簡單，但當租戶的數量逐漸增加，資料表的數量也隨之增加，此時，軟體開發人員在多租戶應用程式的維運上需要花費更多的成本。雖然 Extension Table. 23.

(35) Layout 無法減少租戶數量增加，資料表數量增加的問題，但其所提出的共有欄位、私有欄位的概念，可以提供一套有效管理方式讓軟體開發人員能夠統一對所有租戶資料表中的共有欄位進行增刪修改，因此，降低軟體開發人員在多租戶應用程式開發以及維運上所需花費的時間成本。. 3.3 系統流程關於系統流程，主要可以分成三個階段(圖 3.2)，首先，透過改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句，接下來，將 SQL 語句經由 JSqlParser. 治政進行結構剖析，再來，從其剖析結果取得語句元素以協助系統工具以 Extension 大立 Table Layout 的邏輯進行語句轉換，最後，將轉換後的語句回傳至 JDBC 並在資 ‧ 國. 學. 料庫中執行，影響各別租戶的資料表綱要(schema)或是資料。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 3.2 系統工具進行語句轉換流程圖. 第一階段，如圖 3.3 所示，建立一個新類別－Multitenantstatement，此類別去繼承原先在 JDBC 中扮演實際執行 SQL 語句以及回傳查詢結果角色的 Statement 類別(此 Statement 類別已實作 JDBC 中的 Statement 介面)。在 Multitenantstatement 類別中，基於 1.2 小節所提到的多租戶技術的開發概念，. 24.

(36) 除了既有的類別成員之外，額外增加了一個類別成員－TenantId，透過此類別成員(TenantId)去辨識此 SQL 語句的執行對象(租戶)。. 學. ‧ 國. 立. 政治大. 圖 3.3 Multitenantstatement 類別繼承關係圖：. 藉由此類別協助系統工具取得租戶的識別碼－TenantId. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 3.4 系統工具攔截軟體開發人員所撰寫的 SQL 語句程式碼範例. 如何攔截到軟體開發人員所撰寫的 SQL 語句。站在軟體開發人員的角度，以圖 3.4 為例，首先，會先建立與資料庫的連線(line 1-3)，緊接著，建立一個新的 Multitenantstatement 物件取代原先 Statement 物件的位置，扮演實際 25.

(37) 執行 SQL 語句以及回傳查詢結果的角色(line 5)，接下來，撰寫其所要執行的 SQL 語句(line 6)，最後，利用 setTenantId()設定執行的對象(租戶)，透過 executeUpdate()去執行 SQL 語句。從圖 3.4 以及圖 3.5 清楚知道系統工具藉由 executeUpdate()攔截到軟體開發人員所撰寫的 SQL 語句(圖 3.4 的 line 8)，接下來，將 SQL 語句利用 If -Else 去判斷其語句型態(圖 3.5 的 line 6)，根據判斷結果將 SQL 語句進行不同型態的語句轉換。第二階段，將 SQL 語句轉換成以 Extension Table Layout 邏輯表達的 SQL 語句之前，必需先透過 JSqlParser 去進行語句結構剖析，從其剖析結果獲得進. 治政行語句轉換時所需的語句元素。最後，將取得的語句元素以 Extension Table 大立 Layout 邏輯進行重組。 ‧ 國. 學. 第三階段，將上一階段轉換後所產生的語句傳回 executeUpdate()並在. ‧. 資料庫中執行，影響個別租戶的資料表綱要(schema)或是資料。. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 3.5 executeUpdate()的虛擬碼. 3.4 系統實作方法在上一章節說明了系統工具如何利用改寫 JDBC 的部分 API 去攔截軟體開發人員 26.

(38) 所撰寫的 SQL 語句，進而將 SQL 語句交給 JSqlParser 進行結構剖析以取得語句轉換時所需的語句元素。緊接著，本章節將詳細地解釋如何依據 Extension Table Layout 邏輯進行各種型態的語句轉換。. 3.4.1 Extension Table Layout 概念實作在 2.2.3 小節中提到 Extension Table Layout 的概念是將所有租戶的共有欄位提出後放置在一個共用資料表中，同時，所有租戶屬於共有欄位的欄位資料也都存放在該共用資料表中。另外，為了滿足租戶客製化欄位的需求，替每個租. 治政戶建立其存放私有欄位(即客製化欄位)資料的私有資料表。接下來的部分，將大立了解如何實現 Extension Table Layout 所提出的共有欄位、私有欄位概念在多 ‧ 國. 學. 租戶應用程式之資料層級設計。. ‧. 在多租戶應用程式的開發過程中，資料層級的部分，軟體開發人員會依照. sit. y. Nat. 應用程式的需求設計一套資料表集合，以開發一個多租戶(此範例的租戶定義為. io. er. 學校)選課系統為例，假定目前有 Nccu、Fju 以及 Tku 三間學校(租戶)使用這個多租戶選課系統，根據 Extension Table Layout 所提出的概念，首先，軟體開. al. n. iv n C 發人員會透過 CREATE 語句去建立三個存放所有學校共有欄位資料的共用資料表， hengchi U 分別是用來存放所有學校學生共有欄位資料的 StudentInfoCommonFields、所有學校課程共有欄位資料的 CourseInfoCommonFields 以及記錄所有學校學生選課記錄共有欄位資料的 SelectCourseCommonFields。接下來，為了讓每個學校(租戶)可以依據各自需求適度地客製化其資料表綱要(schema)，本系統工具增加了一個名為 CREATE EXTENSION TABLE 的語句去協助軟體開發人員建立存放學校(租戶)其私有欄位(客製化欄位)資料的私有資料表集合，另外，藉由 ALTER 語句讓每個學校(租戶)對其所擁有的私有資料表綱要(schema)進行欄位的增刪修改，此一動作意味著私有欄位的增刪修改，同時，也代表著租戶擁有客製化欄位的. 27.

(39) 能力。除此之外，由於 Extension Table Layout 會將資料表欄位拆成共有欄位、私有欄位，共有欄位的資料存放在共用資料表中；私有欄位的資料則存放在各租戶各自擁有的私有資料表中。為了協助系統工具進行後續的語句轉換，所以，必須額外記錄各個共用資料表、私有資料表的欄位名稱資訊(不包含詮釋欄位名稱)在 Columns_Metadata Table 中。圖 3.6 是 Columns_Metadata Table 的欄位資訊存放格式。Columns_Metadata Table 主要記錄了實際在資料庫中，每個資料表所存在的欄位名稱，但不包含詮釋欄位名稱(TenantId、Row)。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. 圖 3.6 Columns_Metadata Table 的欄位資訊存放格式：每一列以實際資料表名稱開頭，. al. n. iv n C 以逗點分隔逐一記錄其所存在的欄位名稱(不包含詮釋欄位：TenantId、Row) hengchi U. 3.4.2 CREATE 語句的轉換、CREATE EXTENSION TABLE 的設計與實作為了實現共有欄位的概念，軟體開發人員可以撰寫 CREATE 語句建立存放所有租戶共有欄位資料的共用資料表；另外，CREATE EXTENSION TABLE 語句則是協助軟體開發人員建立每個租戶各自擁有的私有資料表集合。在進行共用資料表建立之前，必需先對共用資料表、私有資料表的命名方式作規定以方便系統工具能夠透過資料表名稱來分辨該資料表屬於共用資料表. 28.

(40) 或是私有資料表。本系統工具中統一共用資料表名稱必需以”CommonFields” 這個關鍵字作命名的結尾。假定建立一個存放學校課程資訊共有欄位資料的共用資料表，可以取課程資訊的英譯”CourseInfo”加上”CommonFields”關鍵字，將此共用資料表命名為”CourseInfoCommonFields”；相對地，私有資料表的命名方式則是加上 TenantId 以供系統工具識別。(表 3.1) 表 3.1 共用資料表與私有資料表比較圖. 資料表種類. 共用資料表. 私有資料表. 定義. 提供給每個租戶存放共有欄. 提供給每個租戶存放私有欄. 位的資料表. 位的資料表. 讓軟體開發人員可以透過共用資料表的修改來統一影響. 滿足租戶客製化資料表綱要的需求。透過私有資料表綱. 降低開發和維運上的時間成本。. 改客製化(私有)欄位名稱、資料型態等動作的需求。. 資料表命名方式. 資料表名稱以 CommonFields 結尾. 資料表名稱以 TenantId 開頭. 例子. StudentInfoCommonFields、 NccuStudentInfo、 SelectCourseCommonFields NccuSelectCourse、、CourseInfoCommonFields… NccuCourseInfo…. 特色. 學. ‧. ‧ 國. 政治大各租戶的共有欄位，減少逐一要的修改達到租戶新增、刪立修改各租戶資料表的機會以除客製化(私有)欄位或是更. n. er. io. sit. y. Nat. al. A. CREATE 語句的轉換. Ch. engchi. i Un. v. 這一小節，主要探討如何進行 CREATE 語句的轉換，共有三個步驟： 1. 透過改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句。 2. 接下來，將攔截到的 SQL 語句藉由 JSqlParser 進行語句結構剖析的動作，從其結果獲得轉換語句所需要的語句元素。 3. 以 Extension Table Layout 的邏輯進行語句轉換。以圖 3.7 為例，經由改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句後(line 7)，透過 JSqlPaeser 進行語句結構剖析以獲得語句元素，，例如：資料表名稱 ( 此為 CourseInfoCommonFields) 以及欄位宣告的部份 ( 此為 29.

(41) CourseId Char(50) ,CourseName Char(50)…)。最後，如圖 3.8 紅字部分，在原 SQL 語句中欄位宣告的部分加入了詮釋欄位(TenantId、Row)的宣告，同時，將詮釋欄位設置欄位限制為 Not Null；另外，增加一個 Composite Primary Keys 以確保(TenantId , Row)的組合會是唯一。. 立. 政治大. ‧. ‧ 國. 學. n. al. y er. io. sit. Nat. 圖 3.7 CREATE 語句範例. Ch. engchi. i Un. v. 圖 3.8 CREATE 語句轉換後的結果. 隨著共用資料表的建立，系統工具也會自動更新 Columns Meta data Table，新增一筆記錄共用資料表的欄位資訊在 Columns_Metadata Table(圖 3.9)。. 圖 3.9 執行 CREATE 語句後，Columns_Metadata Table 的更新結果 30.

(42) 一般來說，欄位宣告有四種類型的 Integrity Constraints[21]，除了最基本的 Domain Constraints 以外(亦即欄位資料型態限制)，有時也會結合其他三種條件限制：Entity Integrity、Referential Integrity 以及 User Defined Integrity。由於本系統工具在設計上部份採取共用資料表的架構，所以，在處理 Integrity Constraints 的時候會發生一些問題，必須將 TenantId 這個詮釋欄位納入考量。以圖 3.10 的 Uniqueness Check 處理為例，假定要將 CourseId 這個共有欄位設定為 Unique，則需要透過多欄位的唯一限制來協助處理(如圖 3.10 方框所示)。目前本系統工具尚未支援所有類型的 Integrity Constraints，其. 治政他有關於 Integrity Constraints 的討論會在第五章做出進一步地探討。大立 ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 3.10 處理 Integrity Constraints 的範例. B. CREATE EXTENSION TABLE 語句的設計概念及實作 CREATE EXTENSION TABLE 語句的設計概念主要是為了協助軟體開發人員在新增租戶的時候，可以撰寫該類型的語句建立新租戶所獨自擁有的私有資料表. 31.

(43) 集合。所以，CREATE EXTENSION TABLE 語句的實作主要有兩個步驟： 1. 查詢 Columns_Metadata Table 找出所有的共用資料表名稱並產生私有資料表名稱。 2. 為新加入的租戶建立其獨自擁有的私有資料表集合。. 政治大. 立. ‧ 國. 學. 圖 3.11 CREATE EXTENSION TABLE 語句範例 1. 取得共用資料表名稱. CourseInfoCommonFields. ‧ 2. 將”CommonFields”關鍵字刪除. n. al. sit. CourseInfo. Ch. er. io Nccu. y. Nat. CourseInfoCommonFieldss s. engchi. NccuCourseInfo. i Un. v. 3. 前面加上 TenantId. 4. 結果即為私有資料表名稱. 圖 3.12 產生私有資料表名稱的流程. 以圖 3.11 的 CREATE EXTENSION TABLE 語句為例(line 6)，先利用共用資料表名稱的關鍵字”CommonFields”在 Columns_Metadata Table 中搜尋出所有已存在的共用資料表名稱。接下來，為新加入的租戶建立其獨自擁有的私有資料表合(圖 3.12)，首先，將所搜尋到的共用資料表名稱中的關字”CommonFields” 刪除並在資料表名稱前面加上 TenantId(此為 Nccu)以作為識別，組合成私有資料表名稱；最後，產生 CREATE 語句(圖 3.13)，在欄位宣告的部分加入了詮釋欄 32.

(44) 位(TenantId、Row)的宣告，同時，將詮釋欄位設置欄位限制為 Not Null；另外，增加一個 Composite Primary Keys 以確保(TenantId , Row)的組合會是唯一。. 圖 3.13 實作 CREATE EXTENSION TABLE 語句概念所產生的 CREATE 語句. 同時，在 Columns_Metadata Table 進行更新的動作，新增一筆記錄(圖 3.14) 該私有資料表(此為 NccuCourseInfo)的欄位資訊在 Columns_Metadata Table。. 政治大圖 3.14 執行 CREATE EXTENSION TABLE 語句後，Columns_Metadata Table 的更新結果立 ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i Un. v. 圖 3.15 多個共用資料表存在，實作 CREATE EXTENSION TABLE 語句所產生的 CREATE 語句. 圖 3.16 多共用資料表存在時，執行 CREATE EXTENSION TABLE 語句後， Columns_Metadata Table 的更新結果. 事實上 CREATE EXTENSION TABLE 語句概念是由多個 CREATE 語句所實作而 33.

(45) 成。倘若資料庫中存在一個以上的共用資料表，則仿造上述的作法，逐一為新租戶建立每一個私有資料表。因此，實作 CREATE EXTENSION TABLE 語句所產生的 CREATE 語句數量會等同於共用資料表的數量。假定目前已存在三個共用資料表，分別是 CourseInfoCommonFileds、StudentInfoCommonFields 以及 SelectCourseCommonFields，則實作 CREATE EXTENSION TABLE 語句所產生的 CREATE 語句數量會是三句(圖 3.15)。另外，Columns_Metadata Table 也會隨之進行更新的動作，其所增加的欄位資訊部分如圖 3.16 的紅色方框部份。. 政治大. 3.4.3 ALTER 語句的轉換. 立. 上一小節藉著建立共用資料表去實現共有欄位的概念，接下來的小節將以建立. ‧ 國. 學. 好的私有資料表透過 ALTER 語句的撰寫來滿足租戶客製化欄位的需求。本系統. ‧. 工具中，主要支援了四種常見的 ALTER 語句類型，這些 ALTER 語句分別在執行. sit. y. Nat. 之後對資料表綱要產生不同影響，依照其影響結果可以分成四種類型：. n. al. er. io. 類型 1. 增加一個資料表欄位. i Un. v. 在”CourseInfo”資料表中增加一個資料表欄位 Location，其欄位型態為 char，長度為 10。. Ch. engchi. 類型 2. 改變資料表欄位的名稱在” CourseInfo”資料表中的資料表欄位 Location 的名稱變更成 Classroom。. 類型 3. 改變資料表欄位的資料型態 34.

(46) 在” CourseInfo”資料表中將資料表欄位 Location 的資料型態從 char(10) 變更成 char(30)。. 類型 4. 刪去一個資料表欄位刪除” CourseInfo”資料表中的資料表欄位 Location。. 介紹完四種 ALTER 語句的表達方式，可以知道執行 ALTER 語句對私有資料. 政治大作。假定租戶要建立客製化欄位可以利用上述介紹的類型 1.去完成；若要更改立表影響可以滿足租戶建立客製化欄位或是對其客製化欄位進行變更、刪除等動. ‧ 國. 學. 其客製化欄位名稱或是資料型態，則分別透過類型 2 以及類型 3 去完成；若執行類型 4.則可達到刪除客製化欄位的效果。接下來，探討本系統工具如何進行. ‧. ALTER 語句轉換，主要有三個步驟：. Nat. sit. y. 1. 透過改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句，此外，. n. al. er. io. 軟體開發人員在 setTenantId()設定其 TenantId 以協助系統進行語句轉. i Un. v. 換。在此，透過 TenantId 能夠清楚得知其 SQL 語句所要執行的對象(租戶)。. Ch. engchi. 2. 將攔截到的語句藉由 JSqlParser 進行語句結構剖析的動作，從其結果獲得轉換語句所需要的語句元素。 3. 以 Extension Table Layout 的邏輯進行語句轉換。這個部份將以圖 3.17 的 ALTER 語句(line 6)為範例來進行詳細的轉換過程說明。首先，透過改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句，利用 setTenantId()取得 TenantId(此為 Nccu)以協助系統進行語句轉換 (line 7)。接下來，JSqlPaeser 分析語句結構取得所需的語句元素，例如：資料表名稱(此為 CourseInfo)、新建立的欄位名稱(此為 Location)以及新建立的欄位型態(此為 Char(10))。 35.

(47) 最後，進入依據 Extension Table Layout 邏輯進行語句轉換的階段，先判斷資料表名稱來了解執行對象是共用資料表或是私有資料表，此例因為資料表名稱結尾沒有關鍵字”CommonFields”，所以，可以知道執行對象是屬於私有資料表，實際上，也就是租戶進行新增客製化欄位的動作(反之，若其執行對象為共有資料表，則代表軟體開發人員對共用資料表進行新增欄位的動作)，接下來，本系統工具把 TenantId(此為 Nccu)以及資料表名稱(CourseInfo)組合起來形成轉換所需的私有資料表名稱 (此為 NccuCourseInfo)，其餘的語句元素不需要做額外的改變。轉換後的結果如同 3.18 所示。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. ni Ch 圖 3.17 ALTER 語句範例 U engchi. v. 圖 3.18 ALTER 語句轉換後的結果. 最後，同樣在 Columns_Metadata Table 新增”Location”欄位名稱到原本記錄 NccuCourseInfo 資料表欄位資訊的該筆記錄(圖 3.18)。. 圖 3.19 執行 ALTER 語句後， Columns_Metadata Table 的更新結果. 總結 3.4.2 以及 3.4.3 兩小節，在其所提到的 CREATE、CREATE EXTENSION TABLE 以及 ALTER 語句相互配合之下，順利在多租戶應用程式之資料層級實現 36.

(48) Extension Table Layout 的共有欄位、私有欄位概念。. 3.4.4 INSERT、UPDATE、DELETE 語句的轉換 INSERT、UPDATE、DELETE 語句主要是協助軟體開發人員進行資料的新增、更改以及刪除等動作。由於 Extension Table Layout 的概念將欄位分成共有欄位、私有欄位並且分別存放在共用資料表、私有資料表，所以，在進行這三種類型語句的語句轉換過程中，必要時會同時新增、更改共用資料表以及私有資料表上的資料，亦或是同時刪除存在於共用資料表以及私有資料表中的資料。因此，. 治政轉換過程中系統工具會自動產生兩個語句分別對存在於共用資料表以及私有資大立料表的資料進行增刪修改的動作以達到原 SQL 語句的目的。 ‧ 國. 學 ‧. A. INSERT 語句的轉換. sit. y. Nat. 在轉換之前，先了解 INSERT 語句的語句結構，從圖 3.20(line 6)清楚得知 INSERT. io. 成。轉換 INSERT 語句有四個主要步驟，歸納如下：. al. iv n C 透過改寫 JDBC 的部分 API 去攔截軟體開發人員所撰寫的 SQL 語句，此外， hengchi U n. 1.. er. 語句是由資料表名稱、新增資料欄位名稱與新增資料數值這三項語句元素所組. 軟體開發人員在 setTenantId()設定其 TenantId 以協助系統進行語句轉. 換。在此，透過 TenantId 能夠清楚得知其 SQL 語句所要執行的對象(租戶)。 2. 將攔截到的語句藉由 JSqlParser 進行語句結構剖析的動作，從其結果獲得轉換語句所需要的語句元素。 3. 產生獨一無二的詮釋欄位組合以及查詢新增資料欄位、新增資料數值所在的資料表並依其查詢結果進行分派。 4. 以 Extension Table Layout 的邏輯去進行語句轉換。. 37.

(49) 立. 政治大圖 3.20 INSERT 語句範例. ‧ 國. 學. 這個部份將以圖 3.20 的 INSERT 語句為例說明如何進行 INSERT 語句轉換。首先，藉由改寫 JDBC 的部分 API 攔截去軟體開發人員所撰寫的 SQL 語句，另外，. ‧. 透過 setTenantId()取得 TenantId(此為 Nccu)以協助系統進行語句轉換. sit. y. Nat. (line 7)。再來，JSqlParser 取得其他語句元素，例如：資料表名稱(此為. n. al. er. io. CourseInfo)、新增資料欄位名稱(此為 CourseId,CourseName,Instrutors…). i Un. v. 以及新增資料數值(此為’Nccu3’,‘編譯器設計’,‘陳恭’…)。接下來，本. Ch. engchi. 系統工具會自動產生 SELECT 語句去計算詮釋欄位 Row 的最大值(圖 3.21)，將 Row 的最大值加一之後和 TenantId 組成一個獨一無二的詮釋欄位組合(TenantId、 Row)。緊接著，在 Columns_Metadata Table 中查詢新增資料欄位名稱所在的資料表並進行新增資料欄位名稱的分派，以 CourseId 欄位為例，由於其屬於共有欄位，存在於共用資料表的欄位資訊中，所以，分派在共用資料表 INSERT 語句；反之，Location 欄位存在於私有資料表的欄位資訊中，所以，分派在私有資料表 INSERT 語句，仿造上述的方式，新增資料數值也是進行相同的分派過程。最後，進入依據 Extension Table Layout 邏輯進行語句轉換的階段，本系 38.