共用方式為

編頁報表的資料擷取指導

  • 發行項

本文適用於設計 Power BI 分頁報表的報表作者。 本文提供建議，可協助您設計有效且有效率的資料擷取。

資料來源類型

編頁報表原生支援關聯式及分析資料來源。 這些來源會進一步地分類為雲端式或內部部署。 內部部署資料來源 (無論是裝載於內部部署，還是虛擬機器上) 需要資料閘道，以供 Power BI 連線。 雲端式表示 Power BI 可以直接使用網際網路連線進行連線。

若您可以選擇資料來源類型 (例如針對新專案的情況下)，則我們建議使用雲端式資料來源。 編頁報表可以在網路延遲較低的情況下進行連線，特別是在資料來源位於與您 Power BI 租用戶相同的區域時。 此外，也可以使用單一登入 (SSO) 來連線到這些來源。 這表示報表使用者的身分識別可以流向資料來源，其允許實行每位使用者的資料列層級權限。 目前，只有內部部署資料來源 SQL Server 和 Oracle 支援 SSO (請參閱 Power BI 編頁報表支援的資料來源)。

注意

雖然目前無法使用 SSO 連線到內部部署資料庫，但您還是可以實行資料列層級權限。 其執行方式是將 UserID 內建欄位傳遞至資料集的查詢參數。 資料來源將需要透過可以正確篩選查詢結果的方式來儲存使用者主體名稱 (UPN)。

例如，假設每一位銷售人員都是以一個資料列儲存在 Salesperson 資料表中。 資料表包含 UPN 的資料行，以及銷售人員的銷售區域。 在查詢時，會透過報表使用者的 UPN 篩選資料表，且會使用內部聯結來與銷售事實相關。 透過這種方式，查詢可以有效地將銷售事實資料列篩選到該位報表使用者的銷售區域。

關聯式資料來源

一般而言，關聯式資料來源相當適合操作樣式的報表，例如銷售發票。 這類資料來源也適合需要擷取非常龐大資料集的報表 (超過 10,000 個資料列)。 關聯式資料來源也可以定義預存程序，讓報表資料集執行。 預存程序可以傳遞數個優點：

  • 參數化
  • 封裝程式設計邏輯，允許進行更複雜的資料準備 (例如暫存資料表、資料指標，或是純量使用者定義函式)
  • 改善的可維護性，其允許輕鬆更新預存程序邏輯。 在某些案例中，可以在無須修改或重新發佈編頁報表的情況下執行 (只要資料行名稱和資料類型沒有變更即可)。
  • 改善的效能，因為會快取其執行計畫以重複使用
  • 跨多個報表重複使用預存程序

在 Power BI 報表產生器中，您可以使用關聯式查詢設計工具來以圖形方式建構查詢陳述式，但僅限 Microsoft 資料來源。

分析資料來源

分析資料來源 (也稱為資料模型或僅稱為模型) 非常適合操作報表和分析報表，即使在非常大的資料量上也可以提供快速彙總的查詢結果。 模型量值和 KPI 可以封裝複雜的商務規則以摘要資料。 不過，這些資料來源不適合需要擷取非常大量資料的報表 (超過 10,000 個資料列)。

在 Power BI Report Builder 中，有兩個查詢設計工具可供您選擇：Analysis Services DAX 查詢設計工具，以及 Analysis Services MDX 查詢設計工具。 這些設計工具可用於 Power BI 語意模型數據源，或任何 SQL Server Analysis Services 或 Azure Analysis Services 模型—表格式或多維度。

建議您使用 DAX 查詢設計工具 (只要該設計工具能夠完全符合您的查詢需求)。 若模型沒有定義所需的量值，則您將必須切換至查詢模式。 在此模式中，您可以透過新增運算式來自訂查詢陳述式 (以進行摘要)。

MDX 查詢設計工具會要求您的模型包含量值。 該設計工具具備兩種 DAX 查詢設計工具不支援的功能。 具體而言，該設計工具可允許：

  • 定義查詢層級導出成員 (於 MDX 中)。
  • 設定資料區域以在非詳細資料群組中要求伺服器彙總。 若您的報表需要呈現局部或非加總量值 (例如時間智慧計算或相異計數)，則使用伺服器彙總可能會比擷取低層級詳細資料列效率更高，並讓報表計算摘要。

查詢結果大小

一般而言，最佳做法是僅擷取報表所需的資料。 因此，請不要擷取報表不需要的資料行或資料列。

為了限制資料列，建議一律套用限制性最高的篩選條件，並定義彙總查詢。 彙總查詢會將來源資料分組及摘要，以擷取更細緻的結果。 例如，假設報表需要呈現銷售人員的銷售摘要。 相較於擷取所有銷售訂單資料列，您可以建立資料集查詢，將銷售人員分組，然後摘要每個群組的銷售。

以運算式為基礎的欄位

您可以透過以運算式為基礎的欄位來延伸報表資料集。 例如，如果資料集包含客戶的名字和姓氏，則您可能會希望有個欄位，其能夠串連兩個欄位來產生客戶的完整名稱。 若要進行這樣計算，您有兩個選項。 您可以：

  • 建立「導出欄位」，這種欄位是以運算式為基礎的資料集欄位。
  • 將運算式直接插入資料集查詢 (使用您資料來源的原生語言)，並形成一般的資料集欄位。

我們建議在可能的情況下使用第二個選項。 將運算式直接插入您資料集查詢的較佳原因有兩個：

  • 資料來源針對評估運算式最佳化的效率可能比 Power BI 更高 (特別是關聯式資料庫)。
  • 報表效能可以獲得改善，因為 Power BI 不需要在報表轉譯前具體化導出欄位。 當資料集擷取相當龐大數量的資料列時，導出欄位可能會明顯讓報表的轉譯時間變得更長。

欄位名稱

在您建立資料集時，其欄位會自動根據查詢資料行命名。 這些名稱可能並非易記或直覺式。 來源查詢資料行名稱可能也會包含報表定義語言 (RDL) 物件識別碼中禁止的字元 (例如空格或符號)。 在這種情況下，禁止的字元會以底線字元 (_) 取代。

我們建議您先驗證所有欄位名稱為易記、精簡，但仍然具有意義。 若不是的話，我們建議您「先」重新命名這些欄位，再開始進行報表配置。 因為重新命名後的欄位不會將變更擴散至您報表配置中所使用運算式。 如果您決定在完成報表配置後重新命名欄位，則將需要尋找和更新所有中斷的運算式。

篩選與參數

您的編頁報表設計將會具備報表參數。 報表參數通常會用於提示您的報表使用者篩選報表。 身為編頁報表的作者，您有兩種方式可以完成報表篩選。 您可以將報表參數對應到：

  • 資料集「篩選條件」，在這種情況下報表參數值會用來篩選已由資料集擷取的資料。
  • 資料集「參數」，在這種情況下報表參數值會插入傳送到資料來源的原生查詢中。

注意

所有報表資料集都會以「每個工作階段為基礎」進行快取，且不會超過「最後使用之後」的 10 分鐘。 資料集可以在提交新參數值 (篩選) 時、以不同格式轉譯報表時，或是透過某些方式與報表設計進行互動時 (例如切換可見度或排序) 重複使用。

假設有一個銷售報表範例，其中具備單一報表參數來篩選單一年度的報表。 資料集會擷取「所有年度」的銷售。 其這樣做的理由是報表參數會對應到資料集篩選條件。 報表會顯示所要求年度的資料，而該資料是資料集資料的一部分。 當報表使用者將報表參數變更為不同年度並檢視報表時，Power BI 便不需要擷取任何來源資料。 Power BI 會改為將不同篩選條件套用到已經進行快取的資料集。 在快取資料集後，篩選便會相當快速。

現在，假設有一個不同的報表設計。 這一次報表設計會將銷售年度報表參數對應到資料集參數。 透過這種方式，Power BI 會將年度的值插入原生查詢中，讓資料集僅擷取該年度的資料。 如此，每次報表使用者變更年度的報表參數值時並檢視報表時，資料集都會擷取該年度的新查詢結果。

這兩種設計方法都能夠篩選報表資料，且這兩種設計都適合您的報表設計。 但是經過最佳化的設計會倚賴預期資料量、資料波動性，以及您報表使用者的預期行為。

我們建議您在預期會多次重複使用不同資料集資料列子集時，使用「資料集篩選」(以節省轉譯時間，因為不需要擷取新的資料)。 在這種案例下，您可以辨識擷取較大資料集的成本能和其後重複使用次數取得平衡。 因此，這有助於產生相當耗費時間的查詢。 但請注意，以每一位使用者為基礎來快取大型資料集可能會對效能和容量輸送量產生負面影響。

我們建議您在預期不會要求不同的資料集資料列子集時，或是當要篩選的資料集資料列數量可能會非常龐大 (因此無法有效率地快取) 時，使用「資料集參數化」。 這種設計方法也能在您的資料存放區為動態時運作良好。 在這種案例下，每個報表參數值變更都會導致擷取最新的資料。

非原生資料來源

如果您需要根據不被編頁報表原生支援的資料來源來開發編頁報表，您應該先在 Power BI Desktop 中開發資料模型。 這樣，您就可以連線到由 Power BI 所支援的數百個資料來源。 一旦發佈至 Power BI 服務，您接著便可以開發連線到 Power BI 語意模型的編頁報表。

資料整合

如果需要合併來自不同資料來源的資料，則您有兩個選項：

  • 合併報表資料集：如果編頁報表原生支援資料來源，您可以考慮建立使用 Lookup 或 LookupSet 報表產生器函式的計算欄位。
  • 開發 Power BI Desktop 模型：不過，在 Power BI Desktop 中開發資料模型可能會更有效。 您可以使用 Power Query 以根據任何支援的資料來源來合併查詢。 一旦發佈至 Power BI 服務，您接著便可以開發連線到 Power BI 語意模型的編頁報表。

網路延遲

網路延遲可能會因要求到達 Power BI 服務所需時間增加以及傳遞回應所需時間增加而影響報表效能。 Power BI 中的租用戶會指派給特定區域。

提示

若要判斷租用戶的所在位置，請參閱我的 Power BI 租用戶位於何處？

租用戶中的使用者存取 Power BI 服務時，他們的要求一律會路由至此區域。 例如，當要求到達 Power BI 服務之後，服務可能會將其他要求傳送至底層資料來源或資料閘道，而這些要求也受限於網路延遲。 一般而言，若要將網路延遲的影響降到最低，請盡量將資料來源、閘道和 Power BI 容量保留在最接近的位置。 要求最好位於相同區域內。 如果網路延遲是問題，則您可以透過將其放置在雲端裝載的虛擬機器中，嘗試將閘道與資料來源放置在更接近 Power BI 容量的位置。

SQL Server 複雜資料類型

因為 SQL Server 是一種內部部署的資料來源，Power BI 必須透過閘道與其連線。 但閘道不支援擷取複雜資料類型的資料。 複雜資料類型包括 GEOMETRY 和 GEOGRAPHY 空間資料類型，以及 hierarchyid 等內建類型。 其中也可能包含透過 Microsoft.NET Framework 通用語言執行平台 (CLR) 中組件類別實作的使用者定義類型。

在地圖視覺效果中繪製空間資料和分析需要 SQL Server 空間資料。 因此，若 SQL Server 是您的資料來源，即無法使用地圖視覺效果。 更清楚而言，若您的資料來源是 Azure SQL Database 則可以運作，因為 Power BI 不需要透過閘道進行連線。

影像可以用來將標誌或圖片新增至您的報表配置。 當報表資料集擷取與資料列相關的影像時，您有兩個選項：

  • 您可能也可從資料來源擷取該影像資料 (若已儲存在資料表中)。
  • 當影像是儲存在網頁伺服器上時，您可以使用動態運算式來建立影像 URL 路徑。

如需詳細資訊和建議，請參閱編頁報表的影像指導。

冗餘資料擷取

您的報表可能會擷取冗餘資料。 這在您刪除資料集查詢欄位，或報表具備未使用的資料集時便可能會發生。 請避免這些情況，因為這會對資料來源、網路和 Power BI 容量資源造成不必要的負擔。

已刪除的查詢欄位

在 [資料集屬性] 視窗的 [欄位] 頁面上，您可以刪除資料集的「查詢欄位」 (查詢欄位會對應到資料集查詢所擷取資料行)。 但是，報表產生器不會從資料集查詢中移除對應的資料行。

如果您需要從資料集刪除查詢欄位，我們建議從資料集查詢中移除對應的資料行。 報表產生器會自動移除任何冗餘的查詢欄位。 若您刪除了查詢欄位，請務必確認也修改資料集查詢陳述式，以移除那些資料行。

未使用的資料集

執行報表時，會評估所有的資料集，即使這些資料集並未與報表物件繫結也一樣。 基於這個理由，請在發佈報表前務必移除任何測試或開發資料集。

相關內容

如需本文的詳細資訊，請參閱下列資源：