데이터 원본 및 바인딩(SSAS 다차원)

큐브, 차원 및 기타 Analysis Services 개체는 데이터 원본에 바인딩할 수 있습니다. 데이터 원본은 다음 개체 중 하나일 수 있습니다.

• 관계형 데이터 원본입니다.

• 행 집합(또는 장 행 집합)을 출력하는 Analysis Services 파이프라인입니다.

데이터 원본을 표현하는 방법은 데이터 원본 유형에 따라 다릅니다. 예를 들어 관계형 데이터 원본은 연결 문자열로 구분됩니다. 데이터 원본에 대한 자세한 내용은 다차원 모델의 데이터 원본을 참조하세요.

사용된 데이터 원본에 관계없이 DSV(데이터 원본 뷰)에는 데이터 원본에 대한 메타데이터가 포함됩니다. 따라서 큐브 또는 다른 Analysis Services 개체에 대한 바인딩은 DSV에 대한 바인딩으로 표현됩니다. 이러한 바인딩에는 뷰, 계산 열 및 데이터 원본에 물리적으로 존재하지 않는 관계와 같은 논리 개체 개체에 대한 바인딩이 포함될 수 있습니다. Analysis Services는 DSV에 식을 캡슐화하는 계산 열을 추가한 다음 해당 OLAP 측정값을 DSV의 해당 열에 바인딩합니다. DSV에 대한 자세한 내용은 다차원 모델의 데이터 원본 뷰를 참조하세요.

각 Analysis Services 개체는 고유한 방식으로 데이터 원본에 바인딩됩니다. 또한 이러한 개체에 대한 데이터 바인딩 및 데이터 원본 정의는 데이터 바인딩 개체의 정의(예: 차원)와 함께 인라인으로 제공되거나 별도의 정의 집합으로 아웃 오브 라인으로 제공될 수 있습니다.

Analysis Services 데이터 형식

바인딩에 사용되는 데이터 형식은 Analysis Services에서 지원하는 데이터 형식과 일치해야 합니다. Analysis Services에서 정의되는 데이터 형식은 다음과 같습니다.

데이터 원본에서 받은 모든 데이터는 바인딩에 지정된 SSAS 형식(일반적으로 처리 중)으로 변환됩니다. 변환을 수행할 수 없는 경우(예: 문자열에서 Int로) 오류가 발생합니다. SSDT(SQL Server Data Tools)는 일반적으로 바인딩의 데이터 형식을 데이터 원본의 원본 형식과 가장 일치하는 데이터 형식으로 설정합니다. 예를 들어 SQL 형식 Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset은 SSAS 날짜에 매핑되고 SQL 형식 시간은 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

``

주문된 제품별로 분석하는 경우 Ordered Product on Sales 차원 역할에 대해 Product 세분성 특성은 Sales.OrderedProductID에 바인딩됩니다.

그러나 GranularityAttributes 이 팩트 테이블의 열로 존재하지 않는 경우가 있을 수 있습니다. 예를 들어 GranularityAttributes 다음과 같은 상황에서 열로 존재하지 않을 수 있습니다.

• OLAP 세분성은 원본의 세분성보다 거칠습니다.

• 중간 테이블은 팩트 테이블과 차원 테이블 사이에 끼어 있습니다.

• 차원 키가 차원 테이블의 기본 키와 동일하지 않습니다.

이러한 모든 경우, 팩트 테이블에 GranularityAttributes가 있도록 DSV를 정의해야 합니다. 예를 들어 명명된 쿼리 또는 계산 열을 도입할 수 있습니다.

예를 들어 위와 동일한 예제 테이블에서 세분성이 범주별인 경우 Sales 뷰를 도입할 수 있습니다.

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

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

이 경우 GranularityAttribute 범주는 SalesWithCategory.OrderedProductCategory에 바인딩됩니다.

의사 결정 지원 개체에서 마이그레이션

DSO(Decision Support Objects) 8.0을 사용하면 반등할 수 있습니다 PartitionMeasures . 따라서 이러한 경우 마이그레이션 전략은 적절한 쿼리를 생성하는 것입니다.

마찬가지로, DSO 8.0에서도 이 다시 바인딩을 허용하지만 파티션 내에서 차원 특성을 다시 바인딩할 수 없습니다. 이러한 경우 마이그레이션 전략은 차원에 사용되는 테이블 및 열과 동일한 테이블 및 열이 파티션의 DSV에 있도록 DSV에서 필요한 명명된 쿼리를 정의하는 것입니다. 이러한 경우 From/Join/Filter 절이 구조화된 관련 테이블 집합이 아닌 단일 명명된 쿼리에 매핑되는 간단한 마이그레이션을 채택해야 할 수 있습니다. DSO 8.0을 사용하면 파티션이 동일한 데이터 원본을 사용하는 경우에도 PartitionDimensions가 반등할 수 있으므로 마이그레이션 시 동일한 데이터 원본에 여러 DSV가 필요할 수도 있습니다.

DSO 8.0에서 해당 바인딩은 차원 테이블의 기본 키 또는 팩트 테이블의 외래 키에 바인딩하여 최적화된 스키마를 사용하는지 여부에 따라 두 가지 방법으로 표현할 수 있습니다. ASSL에서는 서로 다른 두 가지 형식이 구분되지 않습니다.

바인딩은 차원 테이블의 기본 키 열이 아니라 팩트 테이블의 외래 키 열에 바인딩이 수행되기 때문에 차원 테이블을 포함하지 않는 데이터 원본을 사용하는 파티션에도 적용됩니다.

마이닝 모델에 대한 바인딩

마이닝 모델은 관계형 또는 OLAP입니다. 관계형 마이닝 모델에 대한 데이터 바인딩은 OLAP 마이닝 모델의 바인딩과 상당히 다릅니다.

관계형 마이닝 모델에 대한 바인딩

관계형 마이닝 모델은 DSV에 정의된 관계를 사용하여 어떤 열이 어떤 데이터 원본에 바인딩되는지에 대한 모호성을 해결합니다. 관계형 마이닝 모델에서 데이터 바인딩은 다음 규칙을 따릅니다.

• 중첩되지 않은 각 테이블 열은 사례 테이블의 열 또는 사례 테이블과 관련된 테이블의 열과 연결됩니다(다대일 또는 일대일 관계를 따름). DSV는 테이블 간의 관계를 정의합니다.

• 각 중첩 테이블 열은 원본 테이블에 바인딩됩니다. 그런 다음 중첩 테이블 열이 소유한 열은 원본 테이블 또는 원본 테이블과 관련된 테이블의 열에 바인딩됩니다. (다시 말하지만, 바인딩은 다대일 또는 일대일 관계를 따릅니다.) 마이닝 모델 바인딩은 중첩 테이블에 대한 조인 경로를 제공하지 않습니다. 대신 DSV에 정의된 관계는 이 정보를 제공합니다.

OLAP 마이닝 모델에 대한 바인딩

OLAP 마이닝 모델에는 DSV와 동일한 모델이 없습니다. 따라서 데이터 바인딩은 열과 데이터 원본 간의 명확성을 제공해야 합니다. 예를 들어 마이닝 모델은 Sales 큐브를 기반으로 할 수 있으며 열은 Qty, Amount 및 Product Name을 기반으로 할 수 있습니다. 또는 마이닝 모델은 제품을 기반으로 할 수 있으며, 열은 제품 이름, 제품 색상 및 판매 수량과 함께 중첩된 테이블을 기반으로 할 수 있습니다.

OLAP 마이닝 모델에서 데이터 바인딩은 다음 규칙을 따릅니다.

• 중첩되지 않은 각 테이블 열은 큐브의 측정값이나 해당 큐브 차원의 속성(차원 역할의 경우 명확하게 구분하기 위해 CubeDimension 를 지정) 또는 차원의 속성에 연결됩니다.

• 중첩된 각 테이블 열은 .에 CubeDimension바인딩됩니다. 즉, 차원에서 관련 큐브로 이동하거나(중첩 테이블의 경우 덜 일반적인 경우) 큐브에서 해당 차원 중 하나로 이동하는 방법을 정의합니다.

오프라인 바인딩

기존 데이터 바인딩을 명령의 지속 시간 동안 일시적으로 변경할 수 있도록 하는 "Out-of-Line" 바인딩을 사용하면 됩니다. 줄 바꿈 바인딩은 명령에 포함되어 있고 유지되지 않는 바인딩을 참조합니다. 특정 명령이 실행되는 동안에만 아웃 오브 라인 바인딩이 적용됩니다. 반면, 인라인 바인딩은 ASSL 개체 정의에 포함되며 서버 메타데이터 내에서 개체 정의와 함께 유지됩니다.

ASSL을 사용하면 일괄 처리에 포함되지 않은 경우 Process 명령과 Batch 명령에서 외부 바인딩을 지정할 수 있습니다. 명령어에 대해 줄 바깥의 바인딩이 Batch 명령어에 지정된 경우, Batch 명령어에 지정된 모든 바인딩은 일괄 처리의 모든 Process 명령어가 실행되는 새로운 바인딩 컨텍스트를 만듭니다. 이 새 바인딩 컨텍스트에는 명령으로 인해 간접적으로 처리되는 개체가 Process 포함됩니다.

명령에서 아웃 오브 라인 바인딩을 지정하면 지정된 개체에 대해 지속형 DDL에 포함된 인라인 바인딩을 재정의합니다. 이러한 처리된 개체는 명령에 직접 명명된 개체를 Process 포함하거나 처리의 일부로 처리가 자동으로 시작되는 다른 개체를 포함할 수 있습니다.

아웃 오브 라인 바인딩은 처리 명령에 선택적 Bindings 컬렉션 개체를 포함 하 여 지정 됩니다. 선택적 Bindings 컬렉션에는 다음 요소가 포함됩니다.

아웃 오브 라인 바인딩과 관련된 모든 요소는 선택 사항입니다. 지정되지 않은 요소의 경우 ASSL은 지속형 개체의 DDL에 포함된 사양을 사용합니다. Process 명령에서 DataSource 또는 DataSourceView의 사양은 선택 사항입니다. DataSource 또는 DataSourceView이 지정되면, 인스턴스화되지 않으며 Process 명령이 완료된 후에도 유지되지 않습니다.

비라인 바인딩 타입 정의

아웃 오브 라인 Bindings 컬렉션 내에서 ASSL은 여러 개체 Binding에 대한 바인딩 컬렉션을 허용합니다. 각각 Binding 에는 개체 참조와 유사한 확장 개체 참조가 있지만 보조 개체(예: 차원 특성 및 측정값 그룹 특성)도 참조할 수 있습니다. 이 개체는 Process 명령의 Object 요소에서 일반적인 평면 형식을 취하지만, <Object></Object> 태그가 없습니다.

바인딩이 지정된 각 개체는 양식 <개체>ID의 XML 요소(예: DimensionID)로 식별됩니다. 양식>< 개체 ID를 사용하여 개체를 가능한 한 구체적으로 식별한 후에는 바인딩이 지정되는 요소(일반적으로Source)를 식별합니다. 일반적으로 주의해야 할 사례는 DataItem 위에 속성으로 있는 Source의 경우로, 이는 속성에서 열 바인딩에 해당됩니다. 이 경우 태그를 DataItem 지정하지 않고 바인딩할 열에 직접 있는 것처럼 속성을 지정 Source 하기만 하면 됩니다.

KeyColumns 은 컬렉션 내의 순서로 식별됩니다 KeyColumns . 예를 들어 두 번째 키 열을 건너뛰어야 함을 나타낼 방법이 없으므로 특성의 첫 번째 및 세 번째 키 열만 지정할 수 없습니다. 모든 키 열은 차원 속성에 대한 비동시적 바인딩에 있어야 합니다.

TranslationsID는 없지만 해당 언어로 의미 체계로 식별됩니다. 따라서 Translations 내부에 Binding 해당 언어 식별자를 포함해야 합니다.

Binding 내에서 추가 가능한 요소 중 하나는 DDL에 직접 존재하지 않는 데이터 마이닝을 위한 중첩 테이블에 사용되는 ParentColumnID입니다. 이 경우 바인딩이 제공되는 중첩 테이블의 부모 열을 식별해야 합니다.