차원-소개Dimensions - Introduction

적용 대상: yesSQL Server Analysis Services 없음Azure Analysis ServicesAPPLIES TO: yesSQL Server Analysis Services noAzure Analysis Services

모든 Microsoft SQL ServerSQL Server Analysis ServicesAnalysis Services 차원은 테이블 또는 뷰에서 데이터 원본 뷰에서 열 기반으로 하는 특성 그룹입니다.All Microsoft SQL ServerSQL Server Analysis ServicesAnalysis Services dimensions are groups of attributes based on columns from tables or views in a data source view. 차원은 큐브와 독립적으로 존재하며 여러 큐브에서 사용되거나 단일 큐브에서 여러 번 사용되고 Analysis ServicesAnalysis Services 인스턴스 간에 연결될 수 있습니다.Dimensions exist independent of a cube, can be used in multiple cubes, can be used multiple times in a single cube, and can be linked between Analysis ServicesAnalysis Services.instances. 큐브와 독립적으로 존재하는 차원을 데이터베이스 차원이라고 하며 큐브 내의 데이터베이스 차원 인스턴스를 큐브 차원이라고 합니다.A dimension that exists independent of a cube is called a database dimension and an instance of a database dimension within a cube is called a cube dimension.

별모양 스키마 디자인을 기반으로 하는 차원Dimension based on a Star Schema Design

차원의 구조는 기본 차원 테이블의 구조에 의해 크게 좌우됩니다.The structure of a dimension is largely driven by the structure of the underlying dimension table or tables. 가장 간단한 구조를 별모양 스키마라고 하는데 이러한 구조에서 각 차원은 기본 키 - 외래 키 관계에 따라 팩트 테이블에 직접 연결되어 있는 단일 차원 테이블을 기반으로 합니다.The simplest structure is called a star schema, where each dimension is based on a single dimension table that is directly linked to the fact table by a primary key - foreign key relationship.

다음 다이어그램의 하위 섹션에서는 AdventureWorksDW2012AdventureWorksDW2012 있는 예제 데이터베이스는 FactResellerSales 팩트 테이블이 두 차원 테이블에 관련 되어 DimResellerDimPromotion합니다.The following diagram illustrates a subsection of the AdventureWorksDW2012AdventureWorksDW2012 sample database, in which the FactResellerSales fact table is related to two dimension tables, DimReseller and DimPromotion. ResellerKey 열에는 FactResellerSales 팩트 테이블에 외래 키 관계를 정의 고 ResellerKey 기본 키 열에는 DimReseller 차원 테이블입니다.The ResellerKey column in the FactResellerSales fact table defines a foreign key relationship to the ResellerKey primary key column in the DimReseller dimension table. 마찬가지로,는 PromotionKey 열에는 FactResellerSales 팩트 테이블에 외래 키 관계를 정의 고 PromotionKey 는 의기본키열 DimPromotion 차원 테이블입니다.Similarly, the PromotionKey column in the FactResellerSales fact table defines a foreign key relationship to the PromotionKey primary key column in the DimPromotion dimension table.

팩트 차원 관계에 대 한 논리 스키마Logical schema for fact dimension relationship

눈송이 스키마 디자인을 기반으로 하는 차원Dimension based on a Snowflake Schema Design

차원을 정의하는 데는 여러 테이블의 정보가 필요하기 때문에 좀 더 복잡한 구조가 요구되기도 합니다.Frequently, a more complex structure is required because information from multiple tables is required to define the dimension. 눈송이 스키마라고 하는 이 구조에서 각 차원은 기본 키 - 외래 키 관계로 서로 간에 및 팩트 테이블에 연결되어 있는 여러 테이블의 열 특성을 기반으로 합니다.In this structure, called a snowflake schema, each dimension is based on attributes from columns in multiple tables linked to each other and ultimately to the fact table by primary key - foreign key relationships. 예를 들어 다음 다이어그램에서는 Product 차원에 완벽 하 게 설명 하는 데 필요한 테이블은 AdventureWorksDW 샘플 프로젝트:For example, the following diagram illustrates the tables required to completely describe the Product dimension in the AdventureWorksDW sample project:

AdventureWorksAS Product 차원에 대 한 테이블Tables for AdventureWorksAS Product dimension

제품을 완벽하게 설명하려면 해당 제품의 범주와 하위 범주가 Product 차원에 포함되어야 합니다.To completely describe a product, the product's category and subcategory must be included in the Product dimension. 그러나 해당 정보에 대 한 주 테이블에 직접 존재 하지 않습니다는 DimProduct 차원입니다.However, that information does not reside directly in the main table for the DimProduct dimension. 외래 키 관계가 DimProductDimProductSubcategory, 외래 키 관계를 다시가 DimProductCategory 테이블로 Product 차원의 제품 범주 및 하위 범주에 대 한 정보를 포함 하도록 가능 합니다.A foreign key relationship from DimProduct to DimProductSubcategory, which in turn has a foreign key relationship to the DimProductCategory table, makes it possible to include the information for product categories and subcategories in the Product dimension.

눈송이 스키마 및 참조 관계 비교Snowflake Schema versus Reference Relationship

일부 경우에 눈송이 스키마를 사용하여 여러 테이블을 통해 차원의 특성을 정의하는 방법이나 별도의 두 차원을 정의하고 이 두 차원 간에 참조 차원 관계를 정의하는 방법 중에서 한 가지를 선택할 수 있습니다.Sometimes, you may have a choice between using a snowflake schema to define attributes in a dimension from multiple tables, or defining two separate dimensions and defining a reference dimension relationship between them. 다음 다이어그램에서는 이러한 시나리오를 보여 줍니다.The following diagram illustrates such a scenario.

샘플 참조 된 차원에 대 한 논리 스키마Logical schema for sample referenced dimension

이전 다이어그램에는 FactResellerSales 팩트 테이블에 외래 키 관계에 없는 DimGeography 차원 테이블입니다.In the previous diagram, the FactResellerSales fact table does not have a foreign key relationship with the DimGeography dimension table. 그러나는 FactResellerSales 팩트 테이블에 외래 키 관계에는 DimReseller 는 차원 테이블에 외래 키 관계에는 DimGeography 차원 테이블입니다.However, the FactResellerSales fact table does have a foreign key relationship with the DimReseller dimension table, which in turn has a foreign key relationship with the DimGeography dimension table. 각 대리점에 대 한 지리 정보를 포함 하는 Reseller 차원을 정의 하려면에서 이러한 특성을 검색 해야는 DimGeographyDimReseller 차원 테이블입니다.To define a Reseller dimension that contains geography information about each reseller, you would have to retrieve these attributes from the DimGeography and the DimReseller dimension tables. 그러나 Analysis ServicesAnalysis Services에서는 별도의 두 차원을 만든 후 두 차원 간에 참조 차원 관계를 정의하여 측정값 그룹 내에서 두 차원을 연결하는 방식으로 동일한 결과를 얻을 수 있습니다.However, in Analysis ServicesAnalysis Services, you can achieve the same result by creating two separate dimensions and linking them in a measure group by defining a reference dimension relationship between the two dimensions. 참조 차원 관계에 대 한 자세한 내용은 참조 차원 관계합니다.For more information about reference dimension relationships, see Dimension Relationships.

이 시나리오에서 참조 차원 관계 사용의 이점은 추가 저장 공간 없이 단일 지리 차원을 만든 후 해당 지리 차원을 기반으로 여러 개의 큐브 차원을 만들 수 있다는 점입니다.One advantage of using reference dimension relationships in this scenario is that you could create a single geography dimension and then create multiple cube dimensions based on the geography dimension, without requiring any additional storage space. 예를 들어 지리 큐브 차원 중 하나를 대리점 차원에 연결하고 또 다른 지리 큐브 차원을 고객 차원에 연결할 수 있습니다.For example, you could link one of the geography cube dimensions to a reseller dimension and another of the geography cube dimensions to a customer dimension. 관련 항목:차원 관계, 참조 관계 및 참조 관계 속성 정의Related topics:Dimension Relationships, Define a Referenced Relationship and Referenced Relationship Properties

차원 처리Processing a Dimension

차원을 만든 후에는 차원을 처리해야만 해당 차원의 특성 멤버 및 계층을 볼 수 있습니다.After you create a dimension, you must process the dimension before you can view the members of the attributes and hierarchies in the dimension. 차원의 구조가 변경되거나 해당 기본 테이블의 정보가 업데이트되면 차원을 다시 처리해야만 변경 내용을 볼 수 있습니다.After the structure of a dimension is changed or the information in its underlying tables is updated, you have to process the dimension again before you can view the changes. 구조 변경 후에 차원을 처리할 때 차원을 포함하는 큐브도 처리해야 하며 그렇지 않으면 큐브를 볼 수 없습니다.When you process a dimension after structural changes, you must also process any cubes that include the dimension - or the cube will not be viewable.

보안Security

계층, 수준 및 멤버를 포함한 차원의 모든 하위 개체는 Analysis ServicesAnalysis Services의 역할을 통해 보안이 설정됩니다.All the subordinate objects of a dimension, including hierarchies, levels, and members, are secured using roles in Analysis ServicesAnalysis Services. 차원 보안은 해당 차원을 사용하는 데이터베이스의 모든 큐브에 적용될 수도 있고 특정 큐브에만 적용될 수도 있습니다.Dimension security can be applied for all the cubes in the database that use the dimension, or for only a specific cube. 차원 보안에 대 한 자세한 내용은 참조 차원에 대 한 사용 권한을 부여 (Analysis Services)합니다.For more information about dimension security, see Grant permissions on a dimension (Analysis Services).

관련 항목:See Also

차원 저장소 Dimension Storage
차원 번역 Dimension Translations
쓰기 가능 차원Write-Enabled Dimensions