資料來源和系結 （SSAS 多維度）

立方體、維度和其他 Analysis Services 物件可以繫結至數據源。 資料來源可以是下列其中一個物件：

• 關係型數據源。

• Analysis Services 管線，輸出資料列集（或分組資料列集）。

表示數據源的方法會因數據源的類型而有所不同。 例如，關係型數據源會以連接字串來區分。 如需數據源的詳細資訊，請參閱 多維度模型中的數據源。

不論使用的數據源為何，數據源檢視 （DSV） 都會包含數據源的元數據。 因此，立方體或其他 Analysis Services 物件的系結顯示為對 DSV 的系結。 這些繫結可以包含邏輯物件的繫結，例如檢視、計算欄位，以及在數據來源中實際不存在的關聯性。 Analysis Services 會在 DSV 中新增一個計算欄以封裝該表示式，然後將對應的 OLAP 度量值綁定至 DSV 中的該欄位。 如需 DSV 的詳細資訊，請參閱 多維度模型中的數據源檢視。

每個 Analysis Services 對象都會以自己的方式系結至數據源。 此外，這些對象的數據系結和數據源的定義可以與數據系結對象的定義內嵌提供（例如維度），或以個別的定義集來換行。

Analysis Services 數據類型

系結中使用的數據類型必須符合 Analysis Services 所支援的數據類型。 Analysis Services 中定義了下列數據類型：

從數據源接收的所有數據都會轉換成系結中指定的 SSAS 類型（通常是在處理期間）。 如果無法執行轉換，就會引發錯誤（例如 String 到 Int）。 SQL Server Data Tools （SSDT） 通常會將系結中的數據類型設定為最符合數據源中來源類型的數據類型。 例如，SQL 類型 Date、DateTime、SmallDateTime、DateTime2、DateTimeOffset 會對應至 SSAS Date，而 SQL 類型 Time 會對應至 String。

維度的系結

維度的每個屬性都會系結至DSV中的數據行。 維度的所有屬性都必須來自單一數據源。 不過，屬性可以系結至不同數據表中的數據行。 數據表之間的關聯性定義於 DSV 中。 如果有多個關聯性集合存在同一個數據表，可能需要在 DSV 中引進具名查詢，才能做為「別名」數據表。 表達式和篩選條件是使用具名計算和具名查詢在 DSV 中定義。

綁定量度組、量度和分割區段

每個量值群組都有下列預設系結：

• 量值群組系結至 DSV 中的數據表（例如 ， MeasureGroup.Source。

• 每個量值都會繫結至該資料表中的數據列（例如 ， Measure.ValueColumn.Source。

• 每個量值群組維度都有一組 數據粒度屬性 ，可定義量值群組的數據粒度。 每個屬性都必須系結至事實數據表中包含屬性索引鍵的數據行或數據行。 （如需數據粒度屬性的詳細資訊，請參閱本主題稍後的 MeasureGroup 數據粒度屬性。

每個分割區可以具選擇性地覆蓋這些預設系結。 每個分割區都可以指定不同的數據源、數據表或查詢名稱，或篩選表達式。 最常見的數據分割策略是使用相同的數據源來覆寫每個分割區的數據表。 替代專案包括為每個分割區套用不同的篩選，或變更數據源。

默認數據源必須在 DSV 中定義，藉此提供架構資訊，包括關聯性的詳細數據。 在數據分割層級指定的任何其他數據表或查詢不需要列在 DSV 中，但是它們必須具有與針對量值群組定義之預設數據表相同的架構，或者至少必須包含量值或數據粒度屬性所使用的所有數據行。 每個量值和數據粒度屬性的詳細系結無法在數據分割層級覆寫，而且它們會假設為與針對量值群組定義的相同數據行。 因此，如果分割區使用實際上具有不同架構的數據源， TableDefinition 則針對數據分割定義的查詢必須產生與量值群組所使用的架構相同的架構。

MeasureGroup 數據粒度屬性

當量值群組的數據粒度符合資料庫中已知的數據粒度，而且事實數據表與維度數據表有直接關聯性時，數據粒度屬性只需要系結至事實數據表上適當的外鍵數據行或數據行。 例如，請考慮下列事實和維度數據表：

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

如果您依已排序的產品進行分析，針對 Sales 維度角色的已排序產品，Product 數據粒度屬性將會繫結至 Sales.OrderedProductID。

不過，有時 GranularityAttributes 可能不存在為資料表上的欄。 例如，在下列情況下，GranularityAttributes 可能不存在作為欄或列。

• OLAP 的粒度比來源中的粒度粗。

• 事實表與維度表之間有一個中間表作為中介。

• 維度索引鍵與維度數據表中的主鍵不同。

在所有這類情況下，都必須定義 DSV，讓粒度屬性存在於事實數據表上。 例如，可以引進具名查詢或計算欄位。

例如，在與上述相同的範例數據表中，如果數據粒度是依類別，便可以對銷售額進行檢視。

SalesWithCategory(RequestedDate, OrderedProductID, ReplacementProductID, Qty, OrderedProductCategory)

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

在此情況下，GranularityAttribute Category 會系結至 SalesWithCategory.OrderedProductCategory。

從決策支援物件移轉

決策支援物件 （DSO） 8.0 允許 PartitionMeasures 反彈。 因此，在這些情況下，移轉策略是建構適當的查詢。

同樣地，雖然 DSO 8.0 也允許此重新系結，但在數據分割中不可能重新系結維度屬性。 在這些情況下，移轉策略是在 DSV 中定義必要的具名查詢，讓分割區的 DSV 中存在與維度所使用的相同的數據表和欄。 這些案例可能需要採用簡單的移轉，其中 From/Join/Filter 子句會對應至單一具名查詢，而不是對應至結構化的一組相關數據表。 由於 DSO 8.0 可讓 PartitionDimension 重新系結，即使分割區使用相同的數據源，移轉可能也需要相同數據源的多個 DSV。

在 DSO 8.0 中，對應系結可以透過系結至維度數據表上的主鍵或事實數據表上的外鍵，以兩種不同的方式表示，視是否採用優化架構而定。 在 ASSL 中，不會區分這兩種不同的形式。

即使使用不包含維度表的資料來源，資料分割的系結也適用於事實表中的外鍵欄，而不是維度表中的主鍵欄。

採礦模型的系結

採礦模型是關係型或 OLAP。 關係型採礦模型的數據系結與 OLAP 採礦模型的系結大不相同。

關係型採礦模型的系結

關係型採礦模型依賴 DSV 中定義的關係，來解決哪些欄位與哪些資料來源系結的歧義。 在關係型採礦模型中，數據系結會遵循下列規則：

• 每個非巢狀表格的表欄會系結至案例表格中的一個欄位或與案例表格相關的表格中的欄位（遵循多對一或一對一的關係）。 DSV 會定義數據表之間的關聯性。

• 每個巢狀數據表數據行都會系結至源數據表。 巢狀數據表數據行所擁有的數據行接著會系結至該源數據表上的數據行或與源數據表相關的數據表。 （同樣地，系結遵循多對一或一對一關係。採礦模型系結不會提供巢狀數據表的聯結路徑。 相反地，DSV 中定義的關聯性會提供這項資訊。

OLAP 採礦模型的系結

OLAP 採礦模型沒有與 DSV 相似功能的結構。 因此，數據繫結必須在欄與數據源之間提供消除歧義的功能。 例如，採礦模型可以根據銷售立方體，而資料欄可以根據數量、金額和產品名稱。 或者，採礦模型可以以 Product 為基礎，而數據行可以根據產品名稱、產品色彩，以及具有 Sales Qty 的巢狀數據表。

在 OLAP 採礦模型中，數據系結會遵循下列規則：

• 每個非巢狀數據表的資料欄都會系結至 Cube 上的度量值、該 Cube 的維度上的屬性（在維度角色的情況下指定 CubeDimension 以消除歧義），或系結至維度上的屬性。

• 每個巢狀資料表資料列都會繫結至 CubeDimension。 也就是說，它定義了如何從一個維度導覽到相關立方體，或在較不常見的情況下，從立方體導覽到其維度之一的巢狀表格。

離線系結

離線系結可讓您在命令持續期間暫時變更現有的數據系結。 非嵌入式系結是指包含在命令中且不會持久化的系結。 只有在該特定命令執行時，才會套用離線系結。 相反地，內嵌系結會包含在 ASSL 物件定義中，並與伺服器元數據中的物件定義一起保存。

ASSL 允許在Process命令（若未在批次中）或Batch命令上指定行外系結。 如果在 Batch 命令上指定了分行系結，那麼在 Batch 命令中指定的所有系結將建立一個新的系結環境，批次中的所有 Process 命令都在此環境中執行。 這個新的系結內容包含因為 Process 命令而間接處理的物件。

當在命令中指定行外系結時，它們會替代指定物件所保存的 DDL 中的內嵌系結。 這些已處理的物件可能包含直接在命令中 Process 命名的物件，或可能包含其他物件，其處理是自動起始作為處理一部分的一部分。

使用處理命令來包含選擇性 Bindings 集合物件，以指定行外系結。 選擇性 Bindings 集合包含下列元素。

與離線系結相關的所有元素都是選擇性的。 對於未指定的任何專案，ASSL 會使用保存物件之 DDL 中包含的規格。 命令中的 DataSourceProcess 或 DataSourceView 規格是選擇性的。 如果有指定 DataSource 或 DataSourceView，它們不會被具現化，而且在 Process 指令完成後不會持續存在。

離線系結類型的定義

在外行 Bindings 集合內，ASSL 允許多個物件的系結集合，每個 物件各一個 Binding。 每個 Binding 都有一個延伸的對象參考，類似於對象參考，但它也可以參考次要物件（例如維度屬性和量值群組屬性）。 這個對象採用命令中Process元素的Object一般格式，不同之處在於<物件></物件>標籤不存在。

指定系結的每個物件都是由表單 <物件>識別碼的 XML 項目來識別（例如 ， DimensionID。 當您使用格式<物件>ID儘可能明確識別物件之後，即可識別需要指定系結的元素，通常是Source。 要注意的常見情況是當 Source 是 DataItem 上的一個屬性時，這就是屬性中欄位綁定的情形。 在此情況下，您不會指定 DataItem 標記，而是直接指定 Source 屬性，就好像它直接在要系結的數據行上一樣。

KeyColumns 會透過集合內的 KeyColumns 排序來識別。 例如，無法指定屬性的第一和第三鍵列，因為無法指出要略過第二鍵列。 所有關鍵欄位必須出現在維度屬性的外部綁定中。

Translations雖然它們沒有標識碼，但語意上是由其語言所識別。 因此，TranslationsBinding內部需要包含其語言標識碼。

在 Binding 中允許的一個額外元素，而該元素並不存在於直接的 DDL 中，是 ParentColumnID，用於資料挖掘中的巢狀資料表。 在此情況下，必須識別提供系結之巢狀數據表中的父數據行。