페이지를 매긴 보고서의 데이터 검색 지침Data retrieval guidance for paginated reports

이 문서에서는 독자가 Power BI 페이지를 매긴 보고서를 디자인하는 보고서 작성자라고 가정하고,This article targets you as a report author designing Power BI paginated reports. 효과적이고 효율적인 데이터 검색을 디자인하는 데 도움이 되는 권장 사항을 제공합니다.It provides recommendations to help you design effective and efficient data retrieval.

데이터 원본 유형Data source types

페이지를 매긴 보고서는 기본적으로 관계형 및 분석 데이터 원본을 둘 다 지원합니다.Paginated reports natively support both relational and analytic data sources. 해당 원본은 클라우드 기반 또는 온-프레미스 중 하나로 추가로 분류됩니다.These sources are further categorized, as either cloud-based or on-premises. 온-프레미스 또는 가상 머신에서 호스트되는지 여부와 관계없이 온-프레미스 데이터 원본에는 Power BI가 연결할 수 있도록 데이터 게이트웨이가 필요합니다.On-premises data sources—whether hosted on-premises, or in a virtual machine—require a data gateway so Power BI can connect. 클라우드 기반은 Power BI가 인터넷 연결을 사용하여 직접 연결할 수 있음을 의미합니다.Cloud-based means that Power BI can connect directly using an Internet connection.

데이터 원본 형식(새 프로젝트의 경우)을 선택할 수 있는 경우 클라우드 기반 데이터 원본을 사용하는 것이 좋습니다.If you can choose the data source type (possibly the case in a new project), we recommend that you use cloud-based data sources. 페이지를 매긴 보고서는 특히 데이터 원본이 Power BI 테넌트와 동일한 지역에 있는 경우 더 짧은 네트워크 대기 시간으로 연결할 수 있습니다.Paginated reports can connect with lower network latency, especially when the data sources reside in the same region as your Power BI tenant. 또한 SSO(Single Sign-On)를 사용하여 해당 원본에 연결할 수 있습니다.Also, it's possible to connect to these sources by using Single Sign-On (SSO). 즉, 보고서 사용자의 ID가 데이터 원본으로 흐를 수 있으므로 사용자별 행 수준 권한이 적용될 수 있습니다.It means the report user's identity can flow to the data source, allowing per-user row-level permissions to be enforced. 현재는 온-프레미스 데이터 원본에 대해 SSO가 지원되지 않습니다. 즉, SQL Server Analysis Services가 사용자별 행 수준 권한을 적용할 수 없습니다.Currently, SSO isn't supported for on-premises data sources (meaning SQL Server Analysis Services cannot enforce per-user row-level permissions).

참고

현재 SSO를 사용하여 온-프레미스 데이터베이스에 연결할 수는 없지만 행 수준 권한을 계속 적용할 수 있습니다.While it's currently not possible to connect to on-premises databases using SSO, you can still enforce row-level permissions. 이 작업을 수행하려면 UserID 기본 제공 필드를 데이터 세트 쿼리 매개 변수에 전달합니다.It's done by passing the UserID built-in field to a dataset query parameter. 데이터 원본은 쿼리 결과를 올바르게 필터링할 수 있는 방식으로 UPN(사용자 계정 이름) 값을 저장해야 합니다.The data source will need to store User Principal Name (UPN) values in a way that it can correctly filter query results.

예를 들어 각 영업 사원은 Salesperson 테이블의 행으로 저장됩니다.For example, consider that each salesperson is stored as a row in the Salesperson a table. 이 테이블에는 UPN 및 영업 사원의 판매 지역에 해당하는 열이 있습니다.The table has columns for UPN, and also the salesperson's sales region. 쿼리 시 테이블은 보고서 사용자의 UPN을 기준으로 필터링되며 내부 조인을 사용하여 판매 팩트에도 관련됩니다.At query time, the table is filtered by the UPN of the report user, and it's also related to sales facts using an inner join. 이 방식으로 쿼리는 보고서 사용자 판매 지역의 판매로 판매 팩트 행을 효과적으로 필터링합니다.This way, the query effectively filters sales fact rows to those of the report user's sales region.

관계형 데이터 원본Relational data sources

일반적으로 관계형 데이터 원본은 판매 송장 같은 운영 스타일 보고서에 적합합니다.Generally, relational data sources are well suited to operational style reports, like sales invoices. 행 수가 1만 개를 초과하는 매우 큰 데이터 세트를 검색해야 하는 보고서에도 적합합니다.They're also suited for reports that need to retrieve very large datasets (in excess of 10,000 rows). 관계형 데이터 원본은 보고서 데이터 세트에 의해 실행될 수 있는 저장 프로시저를 정의할 수도 있습니다.Relational data sources can also define stored procedures, which can be executed by report datasets. 저장 프로시저는 다음과 같은 여러 이점을 제공합니다.Stored procedures deliver several benefits:

  • 매개 변수화Parameterization
  • 더 복잡한 데이터 준비를 허용하는 프로그래밍 논리 캡슐화(예: 임시 테이블, 커서 또는 스칼라 사용자 정의 함수)Encapsulation of programming logic, allowing for more complex data preparation (for example, temporary tables, cursors, or scalar user-defined functions)
  • 저장 프로시저 논리를 쉽게 업데이트할 수 있는 향상된 유지 관리 기능.Improved maintainability, allowing stored procedure logic to be easily updated. 일부 경우에는 페이지를 매긴 보고서를 수정하고 다시 게시하지 않고도 이 작업을 수행할 수 있습니다(열 이름과 데이터 형식이 변경되지 않는 경우).In some cases, it can be done without the need to modify and republish paginated reports (providing column names and data types remain unchanged).
  • 실행 계획이 다시 사용하기 위해 캐시되도록 향상된 성능Better performance, as their execution plans are cached for reuse
  • 여러 보고서에서 저장 프로시저 다시 사용Reuse of stored procedures across multiple reports

Power BI Report Builder에서는 관계형 쿼리 디자이너를 사용하여 쿼리 문을 그래픽으로 생성할 수 있습니다(Microsoft 데이터 원본에만 해당).In Power BI Report Builder, you can use the relational query designer to graphically construct a query statement—but only for Microsoft data sources.

분석 데이터 원본Analytic data sources

분석 데이터 원본은 운영 및 분석 보고서에 둘 다 적합하며 매우 큰 데이터 볼륨에서도 요약된 쿼리 결과를 제공할 수 있습니다.Analytic data sources are well suited to both operational and analytic reports, and can deliver fast summarized query results even over very large data volumes. 모델 측정값 및 KPI는 복잡한 비즈니스 규칙을 캡슐화하여 데이터를 요약할 수 있습니다.Model measures and KPIs can encapsulate complex business rules to achieve summarization of data. 그러나 해당 데이터 원본은 행 수가 1만 개를 초과하는 매우 큰 데이터 세트를 검색해야 하는 보고서에 적합하지 않습니다.These data sources, however, are not suited to reports that need to retrieve very large datasets (in excess of 10,000 rows).

Power BI Report Builder에서 두 가지 쿼리 디자이너인 Analysis Services DAX 쿼리 디자이너 및 Analysis Services MDX 쿼리 디자이너 중 하나를 선택할 수 있습니다.In Power BI Report Builder, you have a choice of two query designers: The Analysis Services DAX query designer, and the Analysis Services MDX query designer. 해당 디자이너는 Power BI 데이터 세트 데이터 원본이나 SQL Server Analysis Services 또는 Azure Analysis Services 모델(테이블 형식 또는 다차원)에 사용할 수 있습니다.These designers can be used for Power BI dataset data sources, or any SQL Server Analysis Services or Azure Analysis Services model—tabular or multidimensional.

쿼리 요구 사항을 완전히 충족하는 경우 DAX 쿼리 디자이너를 사용하는 것이 좋습니다.We suggest you use the DAX query designer—providing it entirely meets your query needs. 모델이 필요한 측정값을 정의하지 않는 경우에는 쿼리 모드로 전환해야 합니다.If the model doesn't define the measures you need, you'll need to switch to query mode. 이 모드에서 요약을 위한 식을 추가하여 쿼리 문을 사용자 지정할 수 있습니다.In this mode, you can customize the query statement by adding expressions (to achieve summarization).

MDX 쿼리 디자이너를 사용하려면 모델에 측정값을 포함해야 합니다.The MDX query designer requires your model to include measures. 디자이너에는 DAX 쿼리 디자이너에서 지원되지 않는 두 가지 기능이 있습니다.The designer has two capabilities not supported by the DAX query designer. 특히 다음을 수행할 수 있습니다.Specifically, it allows you to:

  • 쿼리 수준 계산 멤버를 정의합니다(MDX에서).Define query-level calculated members (in MDX).
  • 세부 그룹이 아닌 그룹에서 서버 집계를 요청하도록 데이터 영역을 구성합니다.Configure data regions to request server aggregates in non-detail groups. 보고서가 반가산적 또는 비가산적 측정값(예: 시간 인텔리전스 계산 또는 고유 개수)의 요약을 제공해야 하는 경우 하위 수준 세부 정보 행을 검색하고 보고서가 요약을 계산하도록 하는 것보다 서버 집계를 사용하는 것이 더 효율적일 수 있습니다.If your report needs to present summaries of semi- or non-additive measures (like time intelligence calculations, or distinct counts), it will likely be more efficient to use server aggregates than to retrieve low-level detail rows and have the report compute summarizations.

쿼리 결과 크기Query result size

일반적으로 보고서에 필요한 데이터만 검색하는 것이 좋습니다.In general, it's best practice to retrieve only the data required by your report. 따라서 보고서에 필요하지 않은 열 또는 행은 검색하지 마세요.So, don't retrieve columns or rows that aren't required by the report.

행을 제한하려면 항상 가장 제한적인 필터를 적용하고 집계 쿼리를 정의해야 합니다.To limit rows, you should always apply the most restrictive filters, and define aggregate queries. 집계 쿼리는 원본 데이터를 그룹화하고 요약하여 더 개략적인 결과를 검색합니다.Aggregate queries group and summarize source data to retrieve higher-grain results. 예를 들어 보고서가 영업 사원 판매의 요약을 제공해야 한다고 가정해보겠습니다.For example, consider that your report needs to present a summary of salesperson sales. 모든 판매 주문 행을 검색하는 대신, 판매 사원별로 그룹화되고 각 그룹의 판매를 요약하는 데이터 세트 쿼리를 만듭니다.Instead of retrieving all sales order rows, create a dataset query that groups by salesperson, and summarizes sales for each group.

식 기반 필드Expression-based fields

식을 기반으로 하는 필드를 사용하여 보고서 데이터 세트를 확장할 수 있습니다.It's possible to extend a report dataset with fields based on expressions. 예를 들어 데이터 세트가 고객 이름 및 성을 가져오는 경우 두 필드를 연결하는 필드에서 고객 전체 이름을 생성하려고 할 수 있습니다.For example, if your dataset sources customer first name and last name, you might want a field that concatenates the two fields to produce the customer full name. 이 계산을 수행할 수 있는 두 가지 옵션이 있습니다.To achieve this calculation, you have two options. 다음을 할 수 있습니다.You can:

  • 식을 기반으로 하는 데이터 세트 필드인 _계산 필드_를 만듭니다.Create a calculated field, which is a dataset field based on an expression.
  • 데이터 원본의 기본 언어를 사용하여 데이터 세트 쿼리에 직접 식을 삽입합니다. 그러면 일반 데이터 세트 필드가 생성됩니다.Inject an expression directly into the dataset query (using the native language of your data source), which results in a regular dataset field.

가능하면 두 번째 옵션을 사용하는 것이 좋습니다.We recommend the latter option, whenever possible. 데이터 세트 쿼리에 직접 식을 삽입하는 것이 좋은 두 가지 이유는 다음과 같습니다.There are two good reasons why injecting expressions directly into your dataset query is better:

  • 데이터 원본이 Power BI보다 더 효율적으로 식을 평가하도록 최적화되어 있을 수 있습니다(특히 관계형 데이터베이스의 경우).It's possible your data source is optimized to evaluate the expression more efficiently than Power BI (it's especially the case for relational databases).
  • Power BI가 보고서 렌더링 전에 계산 필드를 구체화할 필요가 없으므로 보고서 성능이 향상됩니다.Report performance is improved because there's no need for Power BI to materialize calculated fields prior to report rendering. 계산 필드는 데이터 세트가 많은 수의 행을 검색하는 경우 보고서 렌더링 시간이 눈에 띄게 길어질 수 있습니다.Calculated fields can noticeably extend report render time when datasets retrieve a large number of rows.

필드 이름Field names

데이터 세트를 만들면 해당 필드의 이름은 쿼리 열에 따라 자동으로 지정됩니다.When you create a dataset, its fields are automatically named after the query columns. 해당 이름은 친숙하거나 직관적이지 않을 수 있습니다.It's possible these names aren't friendly or intuitive. 원본 쿼리 열 이름에는 RDL(Report Definition Language) 개체 식별자(예: 공백 및 기호)에 금지된 문자가 포함될 수도 있습니다.It's also possible that source query column names contain characters prohibited in Report Definition Language (RDL) object identifiers (like spaces and symbols). 이 경우 금지된 문자는 밑줄 문자()로 바뀝니다.In this case, the prohibited characters are replaced with an underscore character ().

먼저 모든 필드 이름이 친숙하고 간결하지만 여전히 의미가 있는지 확인하는 것이 좋습니다.We recommend that you first verify that all field names are friendly, concise, yet still meaningful. 그렇지 않은 경우 보고서 레이아웃을 시작하기 전에 이름을 바꾸는 것이 좋습니다.If not, we suggest you rename them before you commence the report layout. 이름이 바뀐 필드는 보고서 레이아웃에 사용된 식에 변경 내용을 전파하지 않기 때문입니다.It's because renamed fields don't ripple changes through to the expressions used in your report layout. 보고서 레이아웃을 시작한 후 필드 이름을 바꾸려고 하면 손상된 모든 식을 찾고 업데이트해야 합니다.If you do decide to rename fields after you've commenced the report layout, you'll need to find and update all broken expressions.

필터 및 매개 변수Filter vs parameter

페이지를 매긴 보고서 디자인에는 보고서 매개 변수가 포함될 수 있습니다.It's likely that your paginated report designs will have report parameters. 보고서 매개 변수는 주로 보고서를 필터링하도록 보고서 사용자에게 메시지를 표시하는 데 사용됩니다.Report parameters are commonly used to prompt your report user to filter the report. 페이지를 매긴 보고서 작성자는 두 가지 방법으로 보고서를 필터링할 수 있습니다.As a paginated report author, you have two ways to achieve report filtering. 보고서 매개 변수를 다음에 매핑할 수 있습니다.You can map a report parameter to:

  • 데이터 세트 필터, 이 경우 보고서 매개 변수 값은 데이터 세트에서 이미 검색한 데이터를 필터링하는 데 사용됩니다.A dataset filter, in which case the report parameter value(s) are used to filter the data already retrieved by the dataset.
  • 데이터 세트 매개 변수, 이 경우 보고서 매개 변수 값은 데이터 원본으로 전송되는 기본 쿼리에 삽입됩니다.A dataset parameter, in which case the report parameter value(s) are injected into the native query sent to the data source.

참고

모든 보고서 데이터 세트는 마지막 사용 이후 최대 10분 동안 _세션 단위 기준_으로 캐시됩니다.All report datasets are cached on a per-session basis for up to 10 minutes beyond their last use. 새 매개 변수 값을 제출하거나(필터링), 보고서를 다른 형식으로 렌더링하거나, 표시 여부 토글 또는 정렬 같은 특정 방법으로 보고서 디자인과 상호 작용하는 경우 데이터 세트를 다시 사용할 수 있습니다.A dataset can be re-used when submitting new parameter values (filtering), rendering the report in a different format, or interacting with the report design in some way, like toggling visibility, or sorting.

단일 연도를 기준으로 보고서를 필터링하는 단일 보고서 매개 변수가 있는 판매 보고서의 예제를 살펴보겠습니다.Consider, then, an example of a sales report that has a single report parameter to filter the report by a single year. 데이터 세트는 _모든 연도_의 판매를 검색합니다.The dataset retrieves sales for all years. 이 작업이 수행되는 이유는 보고서 매개 변수는 데이터 세트 필터에 매핑되기 때문입니다.It does so because the report parameter maps to the dataset filters. 보고서는 데이터 세트 데이터의 하위 집합인 요청 연도의 데이터를 표시합니다.The report displays data for the requested year, which is a subset of the dataset data. 보고서 사용자가 보고서 매개 변수를 다른 연도로 변경한 다음, 보고서를 보는 경우 Power BI는 원본 데이터를 검색할 필요가 없습니다.When the report user changes the report parameter to a different year—and then views the report—Power BI doesn't need to retrieve any source data. 대신, 이미 캐시된 데이터 세트에 다른 필터를 적용합니다.Instead, it applies a different filter to the already-cached dataset. 데이터 세트가 캐시된 후에는 필터링이 매우 빨라질 수 있습니다.Once the dataset is cached, filtering can be very fast.

이제 다른 보고서 디자인을 살펴봅니다.Now, consider a different report design. 이번에는 보고서 디자인이 판매 연도 보고서 매개 변수를 데이터 세트 매개 변수에 매핑합니다.This time the report design maps the sales year report parameter to a dataset parameter. 이 방법으로 Power BI는 연도 값을 기본 쿼리에 삽입하고 데이터 세트는 해당 연도의 데이터만 검색합니다.This way, Power BI injects the year value into the native query, and the dataset retrieves data only for that year. 보고서 사용자가 연도 보고서 매개 변수 값을 변경한 다음, 보고서를 볼 때마다 데이터 세트는 해당 연도의 새 쿼리 결과만 검색합니다.Each time the report user changes the year report parameter value—and then views the report—the dataset retrieves a new query result for just that year.

두 디자인 방법은 모두 보고서 데이터를 필터링할 수 있으며 보고서 디자인에 적합합니다.Both design approaches can filter report data, and both designs can work well for your report designs. 그러나 최적화된 디자인은 예상 데이터 볼륨, 데이터 변동성 및 보고서 사용자의 예상 동작에 따라 달라집니다.An optimized design, however, will depend on the anticipated volumes of data, data volatility, and the anticipated behaviors of your report users.

데이터 세트 행의 다른 하위 집합이 여러 번 다시 사용될 것으로 예상하는 경우 _데이터 세트 필터링_을 사용하는 것이 좋습니다(이로 인해 새 데이터를 검색할 필요가 없기 때문에 렌더링 시간이 절약됨).We recommend dataset filtering when you anticipate a different subset of the dataset rows will be reused many times (thereby saving rendering time because new data doesn't need to be retrieved). 이 시나리오에서는 더 큰 데이터 세트를 검색하는 비용이 다시 사용되는 횟수와 교환될 수 있음을 알게 됩니다.In this scenario, you recognize that the cost of retrieving a larger dataset can be traded off against the number of times it will be reused. 따라서 생성하는 데 시간이 오래 걸리는 쿼리에 유용합니다.So, it's helpful for queries that are time consuming to generate. 하지만 사용자 단위 기준으로 큰 데이터 세트를 캐시하면 성능 및 용량 처리량에 부정적인 영향을 줄 수 있습니다.But take care—caching large datasets on a per-user basis may negatively impact on performance, and capacity throughput.

데이터 세트 행의 다른 하위 집합이 요청될 가능성이 거의 없을 것으로 예상하는 경우 또는 필터링할 데이터 세트 행 수가 매우 커서 캐시하기에 비효율적일 수 있는 경우 _데이터 세트 매개 변수화_를 사용하는 것이 좋습니다.We recommend dataset parameterization when you anticipate it's unlikely that a different subset of dataset rows will be requested—or, when the number of the dataset rows to be filtered is likely to be very large (and inefficient to cache). 이 디자인 방법은 데이터 저장소가 일시적인 경우에도 적합합니다.This design approach work well, too, when your data store is volatile. 이 경우 각 보고서 매개 변수 값이 변경되면 최신 데이터가 검색됩니다.In this case, each report parameter value change will result in the retrieval of up-to-date data.

기본이 아닌 데이터 원본Non-native data sources

페이지를 매긴 보고서에서 기본적으로 지원되지 않는 데이터 원본을 기반으로 페이지를 매긴 보고서를 개발해야 하는 경우에는 먼저 Power BI Desktop 데이터 모델을 개발할 수 있습니다.If you need to develop paginated reports based on data sources that aren't natively supported by paginated reports, you can first develop a Power BI Desktop data model. 이렇게 하면 100개가 넘는 Power BI 데이터 원본에 연결할 수 있습니다.This way, you can connect to over 100 Power BI data sources. Power BI 서비스에 게시된 후 Power BI 데이터 세트에 연결하는 페이지를 매긴 보고서를 개발할 수 있습니다.Once published to the Power BI service, you can then develop a paginated report that connects to the Power BI dataset.

데이터 통합Data integration

여러 데이터 원본의 데이터를 결합해야 하는 경우 다음 두 가지 옵션을 사용할 수 있습니다.If you need to combine data from multiple data sources, you have two options:

  • 보고서 데이터 세트 결합: 데이터 원본이 페이지를 매긴 보고서에서 기본적으로 지원되는 경우 Lookup 또는 LookupSet 보고서 작성기 함수를 사용하는 계산 필드를 만드는 것이 좋을 수 있습니다.Combine report datasets: If the data sources are natively supported by paginated reports, you can consider creating calculated fields that use the Lookup or LookupSet Report Builder functions.
  • Power BI Desktop 모델 개발: 그러나 Power BI Desktop에서 데이터 모델을 개발하는 것이 더 효율적일 수 있습니다.Develop a Power BI Desktop model: It's likely more efficient, however, that you develop a data model in Power BI Desktop. 파워 쿼리를 사용하여 지원되는 데이터 원본을 기반으로 쿼리를 결합할 수 있습니다.You can use Power Query to combine queries based on any supported data source. Power BI 서비스에 게시된 후 Power BI 데이터 세트에 연결하는 페이지를 매긴 보고서를 개발할 수 있습니다.Once published to the Power BI service, you can then develop a paginated report that connects to the Power BI dataset.

SQL Server 복합 데이터 형식SQL Server complex data types

SQL Server가 온-프레미스 데이터 원본이므로 Power BI는 게이트웨이를 통해 연결해야 합니다.Because SQL Server is an on-premises data source, Power BI must connect via a gateway. 그러나 게이트웨이는 복잡한 데이터 형식의 데이터 검색을 지원하지 않습니다.The gateway, however, doesn't support retrieving data for complex data types. 복합 데이터 형식에는 GEOMETRY 및 GEOGRAPHY 공간 데이터 형식hierarchyid 같은 기본 제공 형식이 포함됩니다.Complex data types include built-in types like the GEOMETRY and GEOGRAPHY spatial data types, and hierarchyid. Microsoft.NET Framework CLR(공용 언어 런타임)에서 어셈블리의 클래스를 통해 구현되는 사용자 정의 형식이 포함될 수도 있습니다.They can also include user-defined types implemented through a class of an assembly in the Microsoft.NET Framework common language runtime (CLR).

지도 시각화에서 공간 데이터 및 분석을 그리려면 SQL Server 공간 데이터가 필요합니다.Plotting spatial data and analytics in the map visualization requires SQL Server spatial data. 따라서 SQL Server가 데이터 원본인 경우 지도 시각화를 사용할 수 없습니다.Therefore, it's not possible to work with the map visualization when SQL Server is your data source. 분명히 말하면, Power BI는 게이트웨이를 통해 연결되지 않으므로 데이터 원본이 Azure SQL Database인 경우에는 해당 기능이 작동합니다.To be clear, it will work if your data source is Azure SQL Database because Power BI doesn't connect via a gateway.

이미지를 사용하여 보고서 레이아웃에 로고 또는 그림을 추가할 수 있습니다.Images can be used to add logos or pictures to your report layout. 이미지가 보고서 데이터 세트에서 검색한 행에 관련된 경우 다음 두 가지 옵션을 사용할 수 있습니다.When images relate to the rows retrieved by a report dataset, you have two options:

  • 데이터 원본에서 이미지 데이터를 검색할 수도 있습니다(테이블에 이미 저장된 경우).It's possible that image data can also be retrieved from your data source (if already stored in a table).
  • 이미지가 웹 서버에 저장된 경우 동적 식을 사용하여 이미지 URL 경로를 만들 수 있습니다.When the images are stored on a web server, you can use a dynamic expression to create the image URL path.

자세한 내용 및 제안 사항은 페이지를 매긴 보고서의 이미지 지침을 참조하세요.For more information and suggestions, see Image guidance for paginated reports.

중복 데이터 검색Redundant data retrieval

보고서가 중복 데이터를 검색할 수 있습니다.It's possible your report retrieves redundant data. 데이터 세트 쿼리 필드를 삭제하거나 보고서에 사용되지 않는 데이터 세트가 경우 이 작업이 수행될 수 있습니다.This can happen when you delete dataset query fields, or the report has unused datasets. 데이터 원본, 네트워크 및 Power BI 용량 리소스에 불필요한 부담이 발생하므로 이 상황을 방지하세요.Avoid these situations, as they result in an unnecessary burden on your data sources, the network, and Power BI capacity resources.

삭제된 쿼리 필드Deleted query fields

데이터 세트 속성 창의 필드 페이지에서 데이터 세트 쿼리 필드(쿼리 필드는 데이터 세트 쿼리에서 검색한 열에 매핑됨)를 삭제할 수 있습니다.On the Fields page of the Dataset Properties window, it's possible to delete dataset query fields (query fields map to columns retrieved by the dataset query). 그러나 보고서 작성기는 데이터 세트 쿼리에서 해당 열을 제거하지 않습니다.However, Report Builder doesn't remove corresponding columns from the dataset query.

데이터 세트에서 쿼리 필드를 삭제해야 하는 경우 데이터 세트 쿼리에서 해당 열을 제거하는 것이 좋습니다.If you need to delete query fields from your dataset, we recommend you remove the corresponding columns from the dataset query. 보고서 작성기는 중복 쿼리 필드를 자동으로 제거합니다.Report Builder will automatically remove any redundant query fields. 쿼리 필드를 삭제하게 되는 경우에는 열을 제거하도록 데이터 세트 쿼리 문을 수정해야 합니다.If you do happen to delete query fields, be sure to also modify the dataset query statement to remove the columns.

사용되지 않는 데이터 세트Unused datasets

보고서가 실행되면 보고서 개체에 바인딩되지 않은 경우에도 모든 데이터 세트가 평가됩니다.When a report is run, all datasets are evaluated—even if they're not bound to report objects. 이런 이유로 보고서를 게시하기 전에 테스트 또는 개발 데이터 세트를 모두 제거해야 합니다.For this reason, be sure to remove any test or development datasets before you publish a report.

다음 단계Next steps

이 문서와 관련된 보다 자세한 내용을 알아보려면 다음 리소스를 참조하세요.For more information related to this article, check out the following resources: