國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Force.com Universal Table 資料架構做詳細的說明。
2.2 Force.com Universal Table 資料架構
Force.com 改良的 Universal Table 資料架構將資料表歸納成三種類型，分別為 Metadata Tables、Data Tables 以及 Specialized Pivot Tables，利用這三類型的資料 表建置一個虛擬資料庫[11]，以下為 Force.com 的 Universal Table 設計模型：
圖 2.2：Force.com Universal Table 資料架構，本圖取自[11]。
1. Metadata 類型的資料表示用來描述租戶資料的樣貌，這當中 Objects 資料 表讓租戶們可以建立自己的物件，如同一個虛擬資料表。Fields 資料表 則是讓租戶們建立客製物件中的客製欄位，並指定欄位的資料型別。
2. Data 類型的資料表中有 Data 資料表，當中保存了所有租戶的資料，此外 資料的保存統一使用字串資料型別，之後再利用 Fields 當中所記載的實 際型別進行對應。Clobs 資料表則保存了租戶非結構化文字資料。
3. Specialized Pivot 資料表主要在維護 Data 資料表中的非正規化資料，並 利用當中資料加速取得租戶在 Data 資料表中的資料。雖然 Force.com 並 未 把 全部 的 Pivot 資料 表 公布 ，但 主要有 Indexes 、 UniqueFields 、
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Relationships、NameDenorm 以及 FallBackIndex 資料表。由於 Data 資料 表中所保存的租戶資料都是字串，因此不可能使用關聯式資料庫的 Index 功能來建置索引加速查詢速度，所以把 Data 資料表中 Value 欄位的值複 製到 Indexes 後再建立關聯式資料庫的索引。UniqueFields 的功能如同 Indexes 資料表，但 Indexes 中的索引值是可以重複的，不過 UniqueFields 是不可重複。Relationships 則是記錄了 Objects 之間關聯的索引，當需要 使用到 join 進行查詢時，便會利用到此資料表。NameDenorm 則是提供 快速查詢 Object 名稱與 Id 的索引。此外當 Force.com 搜索引擎出問題或 是負載過高時，Force.com 的查詢機制便會使用 FallBackIndex 中資料來 完成查詢請求。
雖然 Force.com 並未公開其資料模型全部的細節，但根據文獻可以推論出其 資料模型的內部細節，以下將針對其內部細節說明。
2.2.1 Objects、Fields、Data 資料表
Data 資料表中保存了租戶的資料，Objects 與 Fields 則保存了資料的詮釋資料 (Metadata)，Objects 當中的每筆資料就如同關聯式資料庫的資料表(Table)，Fields 中的資料就如同資料表中的欄位(Column)。以下為這個三個資料表的內部的細節 欄位：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 2.3：Data、Objects、Fields 資料表關係。
Data 資料表的欄位中主要有 DataGuid 為主鍵(Primary key)，當中使用全域唯 一識別碼(Global Unique Identifier)產生器所產生的文字做為唯一值。TenantId 為 租戶 Id，ObjectId 則是此租戶所擁有的 Object 的 Id，ObjectName 則是該 Object 的名稱，因此使用 TenantId 與 ObjectId，我們便可知道某筆資料的租戶是誰，該 筆的資料所對應的 Object 為哪一個。實際的資料則是保存在 Data 資料表中以 Value 為開頭的欄位中，由 0 至 500，這些 Value 欄位便是未來提供給租戶擴充所 預留的。假設這筆資料有四個欄位的值要保存，便是存在 Value0、Value1、Value2、
Value3 這四個欄位中。假設我們要查詢 TenantId 為 1，ObjectId 為 1，Value0 欄 位值為 1 的資料，所需要執行的 SQL 指令如下：
Select Value0 , Value1 , Value2 , Value3 from Data where TenantId=1 and ObjectId=1 and Value0=1
圖 2.4：Universal Table 查詢 SQL 指令。
查詢出結果後，由於欄位的意義已被一般化成 Value 來表達，因此我們需要 透過 Objects 與 Fields 這兩個 Metadata 資料表來獲得資料實際所代表的意義。在
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Objects 資料表中有 ObjectId 與 ObjectName 欄位，分別代表 Object 的唯一 Id 與 名稱。一個 Object 所擁有的 Field 則是保存在 Fields Metadata 資料表中，Fields 資料表中有 FieldId、ObjectId、FieldName、FieldNum、FieldType 以及 IndexType。
FieldNum 是當中邏輯最為重要的欄位，因為透過 FieldNum 可以對應回 Data 資料表中 Value 的編號，假設 FieldNum 的值為 0 對應的 Value 欄位為 Value0，
如此我們才能真正了解 Data 資料表中 Value 欄位實際的意義。FieldId 是 Field 的 唯一 Id，FieldName 為其名稱，FieldType 是此 Field 實際的資料型別，IndexType 則為此 Field 是否被建立索引或者其索引類型為何。當然這兩個資料表都有 TenantId 的欄位，才能區別是和租戶所擁有的。
2.2.2 Indexes、UniqueFields 資料表
由於 Data 資料表中所保存的租戶資料的 Value 欄位中都是使用字串，不區分資 料實際型別的，因此無法使用關聯式資料庫索引的功能來加速查詢。Force.com 特別建立了 Indexes 與 UniqueFields 這兩個資料表來間接使用關聯式資料庫的索 引功能，Data、Indexes 與 UniqueFields 三者關係以及 Indexes 與 UniqueFields 資 料表欄位如下：
圖 2.5：Data、Indexes、UniqueFields 資料表關係。
‧
UniqueFields 資料表當中索引值是不可重複的。Indexes 與 UniqueFields 資料表使 用 TenantId、ObjectId、FieldNum 以及 DataGuid 這四個欄位做為複合主鍵來保持 唯一性。 TenantId 代表為哪個租戶，ObjectId 代表此租戶的哪個 Object，FieldNum 欄位則與 Fields 資料表中的 FieldNum 用意一樣，記錄這個 Field 是 Data 資料表 中哪個 Value 欄位。Force.在儲存資料時，會同步把需要建立關聯式資料庫索引的資料複製一份 到 Indexes 或 UniqueFields 中，此時需要建立索引的 Value 欄位值便會根據其實 際的資料型別來保 存 ，因此我們在可以看 到 Indexes 及 UniqueFields 中有 StringValue、NumValue、DateValue…等具有型別意義的欄位，屬於 String 的資料 便會儲存在 StringValue 中，屬於數字的資料便會儲存在 NumValue 中，依此類推。
藉由上述的設計方式，Force.com 的 Query Optimizer 在接受到查詢請求時，
會去判斷查詢條件中是否有建立索引的欄位，如果有的話便會先到 Indexes 或是 UniqueFields 中先查出 DataGuid；這時由於 Indexes 與 UniqueFields 儲存資料的 欄位都能依照其實際資料型別儲存，便可以利用關聯式資料庫的索引功能加速查 詢。取得 DataGuid 後再至 Data 資料表取得完整的資料，因為 DataGuid 為 Data 資料表的主鍵，所以使用此欄位進行查詢，在查詢上的速度同樣也會受惠於關聯 式資料庫索引功能。
2.2.3 Relationships 資料表
租戶們的資料統一儲存在 Data 資料表中，因此假如需要使用到 Join 查詢時，便 需要利子查詢(sub query)的 SQL 指令，以下將以訂購與訂購明細的 Join 查詢 SQL 指令做為例子：
Select * from (Select Value0 as OrderId , Value1 as OrderDate from Data where TenantId = 1 and ObjectId= 1 and Value0=1) o
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
inner join
(Select Value0 as OrderLineitemId , Value1 as OrderId , Value2 as ProductId , Value3 as Qty from Data where TenantId = 1 and ObjectId= 2
) oi
on oi.OrderId= o.OrderId
圖 2.6：Universal Table Join 查詢 SQL 指令。
我們分別利用兩個子查詢查出訂購與訂購明細的資料後再利用 OrderId 將這 兩個子查詢 Join 起來。但子查詢的方式在資料量大時，查詢效能並不如人意，
因此 Force.com 特別設計了一個 Relationships 資料表來改善 Join 查詢速度。但 Force.com 並未在其論文中公開 Relationships 資料表的欄位資訊，反而是在其開 發白皮書[14]中公開了 Relationships 資料表的欄位資訊，Data 與 Relationships 資 料表關係如下：
圖 2.7：Data、Relationships 資料表關係。
Force.com 針對某 Object 建立與其他 Object 的關聯性後，會在此 Object 的資 料中保存有關聯的 ObjectId 於 Data 資料表的 Value 欄位中，並且在儲存資料時，
會同步把需要具有關聯性的資料複製到一份到 Relationships 中。Relationships 資 料表中欄位設計使用了兩組複合索引鍵，分別為 TenantId 與 DataGuid 為一組，
‧
以及 TenantId、ObjectId、AssociationId、TargetObjectId 為一組。
TenantId 與 DataGuid 的複合索引鍵目的在於讓系統可透過租戶 Id 與 Data 資 料表中的 DataGuid 找出此筆資料的 Object 與其他 Object 的關聯性，因為可在查 詢結果可以找到有關聯的 ObjectId 與 TargetObjectId，如查詢結果為多筆資料的 話，則代表此 Object 與多個 Object 有關聯性。
使用 TenantId、ObjectId、AssociationId、TargetObjectId 複合索引鍵進行查 詢，代表系統已經知道 ObjectId 與 TargetObjectId，系統將使用 Object 的關聯性 查出資料 DataGuid，接著再利用此 Guid 結果再去查詢 Data 資料表，藉此達到 Join 的效果，反而不去使用子查詢。Force.com 對於 Relationships 資料表的應用 在論文與白皮書中都未有詳細說明，因此本研究在實作中介軟體框架的過程中，
發現其有所不足的地方並進行修改，請見 3.4.3 小節。