data warehousing, business intelligence, and dimensional modeling...

Data Warehousing, Business Intelligence, and Dimensional Modeling Primer

DMLAB 김지연

Content

비즈니스 중심의 DW/BI 목표

DW/BI system에 대한 출판업 비유

다차원 모델링 핵심 개념과 용어

Kimball의 DW/BI architecure의 구성요소와 사상

다른 DW/BI architecure와의 비교

다차원 모델링에 대한 오해

Different Worlds of Data Capture and Data Analysis

정보

• 의미 : 조직의 가장 중요한 자산 중 하나

• 목적 : 운영상 기록의 보관/의사결정을 위한 분석

운영시스템 vs DW/BI 시스템

운영시스템 DW/BI 시스템 데이터를 입력하는 곳 데이터를 꺼내 사용하는 곳 사용자 역할

조직의 수레바퀴 돌린다 (주문을 받고, 신규 고객을 모으고, 운영 업무의 상태 모니터링하며, 불만사항을 기록한다)

실적을 평가하기 위해 조직의 수레바퀴가 잘 돌아가는지 살펴본다 (신규 주문을 집계하고, 지난주 실적과 비교하고, 신규 고객의 가입 사유와 고객의 불만사항을 파악한다. 운영 업무 프로세스가 정확히 진행되고 있는지 살핀다)

최적화 트랜잭션의 신속 처리 고성능 쿼리 트랜잭션 처리

대부분 한 번에 한 건의 트랜잭션만 처리한다

한 번에 한 건의 트랜잭션만 처리하는 일은 거의 없다 (사용자의 질문은 종종 수십 또는 수백만 건의 트랜젝션을 검색해서 하나의 집합으로 합축된 결과를 요구)

이력 정보 관리

X 가장 최신의 상태를 반영하여 업데이트

O 시간 기준으로 조직의 성과를 정확히 평가하기 위해 필요

Goals of Data Warehousing and Business Intelligence

DW/BI 시스템의 요구 사항

• DW/BI 시스템은 정보에 쉽게 접근 가능하도록 만들어야 한다

이해하기 쉬운 content

개발자, 사용자 모두에게 직관적이고 분명한 data

사용자의 사고 절차와 언어에 근접한 data의 structure와 label

데이터에 접근이 간단하고 사용하기 쉬운 BI tool 또는 application

• DW/BI 시스템은 일관된 정보를 제공해야 한다

일관성 : 공통의 레이블과 정의 사용

두개의 실적 측정값 이름이 동일하다면 그것은 같은 것을 의미해야 한다. 반대로 두 개의 측정값이 같은 의미가 아니라면 그 두 개의 측정값은 서로 다르게 명명되어야 한다

• DW/BI 시스템은 변화에 유연해야 한다

사용자의 니즈, 사업환경, 데이터, 기술의 변화에 우연하게 대처할 수 있도록 설계해야 한다

DW/BI 시스템의 요구 사항 • DW/BI 시스템은 정보를 적시에 제공해야 한다

DW/BI 시스템이 점차 운영 업무 의사결정에도 사용되면서, 원시데이터가 몇 시간, 몇 분, 몇 초 안에 실행 가능한 정보로 변환될 수 있도록 해야 한다

• DW/BI 시스템은 정보자산을 보호하는 보안 요새가 되어야 한다 조직의 고급 정보가 저장되는 DW/BI 시스템은 기밀 정보에 대한 접근을 효

과적으로 통제해야 한다

• DW/BI 시스템은 향상된 의사결정을 위해 권위 있고 신뢰할 수 있는 토대가 되어야 한다 의사결정 지원을 위한 올바른 데이터를 가져야 한다

DW/BI 시스템의 중요 성과물 : 분석 결과로 제시된 증거에 기반한 의사 결정

• DW/BI 시스템이 성공적이라고 생각하기 위해서는 현업이 DW/BI 시스템을 받아 들여야 한다 아무리 좋은 시스템이라도 현업이 적극적으로 사용하지 않는다면 실패한 것

이기에, DW/BI 시스템이 실행 가능한 정보 획득을 위한 ‘쉽고 빠른’ 원천이 된다면, 현업 사용자는 DW/BI 시스템을 수용할 것이다

Goals of Data Warehousing and Business Intelligence

Publishing Metaphor for DW/BI Managers

편집자 DW/BI 관리자

독자 이해하기 • 독자의 인구통계학적 특성 식별하기 • 잡지에서 독자가 원하는 것 찾아내기 • 구독을 갱신하고 잡지 광고를 보고 제품

을 구매하는 ‘최우수’ 독자 식별하기 • 잠재적인 신규 독자를 찾아 그들에게 잡

지 알리기

비즈니스 사용자 이해하기 • 그들의 직무, 목표 및 목적을 이해하기 • 현업 사용자가 DW/BI 시스템의 도움을

받아 의사결정 하고자 하는 내용 파악하기

• 효과적으로 영향력 있는 의사결정을 하는 ‘최우수’ 사용자 식별하기

• 잠재적인 신규 고객을 찾아내고, 그들에게 DW/BI 시스템의 효용성 알리기

지속적으로 출판하기 • 광고주를 끌어들여 잡지의 수익을 창출

하기 • 정기적으로 잡지를 출판하기 • 독자의 신뢰를 구축하기 • 잡지사 오너를 계속 행복하게 만들기

DW/BI 환경 지속시키기 • DW/BI 시스템을 활용한 비즈니스 의사

결정에 대해 일정 부분 인정을 받고, 그 성공을 통해 지속적으로 투자와 직원 채용을 정당화하기

• 주기적으로 DW/BI 시스템 갱신하기 • 현업 사용자의 신뢰를 유지하기 • 현업 사용자, 스폰서 임원 및 IT 관리자

를 행복하게 만들기

Publishing Metaphor for DW/BI Managers

편집자 DW/BI 관리자

독자들에게 잡지 어필하기 • 흥미롭고 주목할만한 잡지 내용 선택하

기 • 독자의 즐거움을 극대화 할 수 있는 레

이아웃과 렌더링 결정하기 • 일관된 프레젠테이션 스타일 채택과 고

품격 집필 및 편집 표준 수립하기 • 기사의 정확성과 광고주의 요구를 지속

적으로 모니터링 하기 • 독자 프로파일 변화에 작가 및 기고가의

새로운 기사로 대응하기

접근하기 쉬운 고품질의 유관 정보와 분석 툴을 현업 사용자에게 전달하기 • 조직에서 가용한 광범위한 data source

로부터 주의 깊게 골라, 가장 양호하고 실행 가능한 데이터를 선택하여 DW/BI 시스템에서 보여지도록 하기

• 사용자 인터페이스와 애플리케이션을 단순하게 만들고 템플릿화해서, 사용자의 인지적인 처리와 일치하게 만들기

• 데이터를 정확하고 신뢰할 수 있게 만들고, 전사적으로 일관성 있게 이름 붙이기

• 데이터와 분석의 정확성을 지속적으로 모니터링하기

• 신규 data source의 추가와 더불어 사용자 프로파일, 요구 사항 및 비즈니스 우선순위 변화에 적응하기

Dimensional Modeling Introduction

다차원 모델링은 DB를 단순하게 만드는 오래된 기법이다

• 사용자들이 쉽게 데이터를 이해

• 소프트웨어가 빠르고 효율적으로 결과를 찾아 제공할 수 있도록

다차원 모델링이 분석 데이터 제공 시 선호하는 기법으로 널리 받아들여진 이유

• 비즈니스 사용자에게 이해하기 쉬운 데이터를 제공

• 빠른 쿼리 성능을 제공

다차원 모델은 정규화 모델과 동일한 정보를 담지만 사용자가 이해하기 쉽고, 쿼리 성능 및 변화에 대한 탄력성을 제공하는 형태로 데이터를 구성한다


3차 정규화 구조

• 데이터를 다수의 개별 entity로 분리하고, 각각은 관계형 테이블이 된다

주문 판매 DB는 각 주문 라인별 하나의 레코드로 시작하겠지만, 3차 정규화 모델로 인해 아마도 수백 개의 정규화된 테이블로 구성된 복잡한 거미줄 모양의 다이어그램으로 변화 할 것

• 갱신 또는 삽입 트랜잭션이 DB의 한 부분만 건드리면 되기 때문에 운영 업무 처리에 매우 유용하다


Star Schema vs OLAP Cube

• Star schema : RDBMS에서 구현되는 다차원 모델

• OLAP cube : MDBMS에서 구현되는 다차원 모델

데이터는 다차원데이터를 위해 설계된 포맷과 기법을 통해 저장, 인덱싱 된다

성능을 위한 집계나 미리 계산된 요약 테이블이 OLAP cube 엔진에 의해 생성되고 관리된다

현업 사용자는 매번 새로 쿼리하지 않고도 뛰어난 성능으로 drill up, drill down 하거나 그들의 분석 결과에 속성을 추가 또는 삭제할 수 있다

대량 데이터의 경우, 상당한 로딩 시간이 필요하다


OLAP 도입 시 고려 사항

• RDBMS에 있는 star schema는 OLAP cube를 생성하기 위한 좋은 물리적 기반이고, 일반적으로 보다 안정적인 백업과 복원이 가능하다

• OLAP cube는 전통적으로 RDBMS를 능가하는 성능상의 뛰어난 이점이 있는 것으로 알려져 왔지만, RDBMS 소프트웨어의 발전으로 그 차별성은 점차 약화되고 있다

• OLAP cube 데이터 구조는 RDBMS보다 업체간의 차이가 다양하고, 최종 상세구현은 선택한 OLAP 업체에 의존하는 경우가 많다

• OLAP cube 상세 데이터 접근을 제한하고, 요약 데이터 접근은 허용하는 등 RDBMS보다 정교한 보안 옵션을 제공한다

• OLAP cube는 SQL의 제약 사항에 기반하는 RDBMS보다 뛰어난 분석 기능을 제공한다

• OLAP cube는 기존 데이터가 갱신 될 경우 cube가 부분적 또는 전체적으로 재처리 되어야 하는 경우가 많다


OLAP 도입 시 고려 사항

• OLAP cube는 트랜잭션 fact table과 주기적 snapshot fact table을 지원하지만 데이터 갱신에 대한 제약 때문에 점진적 snapshot fact table은 지원하지 않는다

• OLAP cube는 레벨이 일정하지 않는 복잡한 계층도 RDBMS에 비해 간단한 쿼리 구문을 지원한다

• OLAP cube는 dimension 계층에 대해 RDBMS보다 더 세밀한 제한을 줄 수 있다

• 몇몇의 OLAP은 dimension의 별칭을 지원하지 않아 물리적으로 별도의 dimension을 정의해야 한다


Fact Tables for Measurements

• 조직의 비즈니스 프로세스 이벤트에서 발생하는 성과 측정값을 저장하는 것

• Fact table은 dimension table의 기본키와 연결되는 외래키를 두 개 이상 갖는다

• 실제 발생한 하나의 측정 이벤트는 fact table 내 하나의 row와 1:1 관계이다

• 해당 제품이 판매되지 않으면 테이블에 아무 row도 넣지 않는다. 이때, 판매 없음을 ‘0’으로 표기하지 않는 것이 중요하다

why? ‘0’이 fact table에 꽉 채워질 것

fact table의 최소 사이즈 유지를 위해


Dimension Tables for Descriptive Context

• 비즈니스 프로세스 측정 이벤트와 관계된 배경설명을 담고 있는 것

• dimension table 속성은 DW/BI system의 필수적인

역할을 한다

• 실생활에서 활용되는 단어로 구성하여, 이해하기 쉬운 텍스트를 사용하여 dimension table에서의 code 사용을 최소화해야 한다

• 운영 시스템 code 안에 여러 정보를 내포하는 경우, 사용자가 쉽게 필터링, 그룹핑, 리포팅 할 수 있도록 미리 내포된 의미를 추출하여 각각 분리된 속성으로 만들어야 한다


어떻게 data 항목이 fact인지 dimension인지 결정하는가?

• 연속적인 숫자 값이라면?

거의 fact

• 비교적 작은 목록 범위 내에서 이산적인 숫자 값이라면?

대부분 dimension


스노우플레이킹(snowflaking)

• Dimension table을 정규화하는 방법

• 제품은 브랜드로, 브랜드는 카데고리로 roll up된다.

사용 용이성과 빠른 쿼리 성능을 제공하고자 제품 dimension의 각 row에 해당하는 브랜드명과 카테고리명도 함께 저장해야 한다

제품 dimension에서 브랜드 코드만 저장하고 별도의 브랜드 lookup table에 설명을 저장해야한다는 데이터 정규화와 충돌

3차 정규화 하지 않고, 한 table 안에 1:n 관계를 납작하게 펼치는 반정규화가 일반적이다


Facts and Dimensions Joined in a Star Schema

• Fact table은 이벤트에 관한 숫자 측정값을 가지며, 이벤트 발생시점의 상황을 설명하는 dimension tables로 둘러 싸인다

• 다차원 스키마의 특징

단순성 : 데이터는 이해하기 쉽고 검색하기 쉬워야 한다

변경에 대한 대응 우수 : 사용자 분석 패턴에서의 예상하지 못한 변화에 강함


SELECT

store.district_name, product.brand, sum(sales_facts.sales_dollars)

AS "Sales Dollars"

FROM

store, product, date, sales_facts

WHERE

date.month_name="January" AND

date.year=2013 AND

store.store_key = sales_facts.store_key AND

product.product_key = sales_facts.product_key AND

date.date_key = sales_facts.date_key

GROUP BY

store.district_name, product.brand

dimension 속성 식별

fact table의 집계 값

table 식별

리포트 필터 정의

dimension과 fact table join

리포트 내 집계 기준 설정

Kimball’s DW/BI Architecure

DW/BI 환경의 고려 사항


Operational Source System

• 비즈니스 트랜젝션을 포착하여 기록하는 운영 시스템

• 다른 운영 시스템에 있는 제품, 고객, 지역, 기간 등 공통 데이터를 공유할 책임이 없는 특정 목적만을 위한 애플리케이션

애플리케이션간 넓게 적용될 수 있는 ERP system or operational master data management system이 단점 해결 도움

• DW의 외부영역으로 오해

Why? 운영 시스템의 데이터 내용과 형식을 제어할 수 없기 때문에

• 우선 순위 : 처리 성능과 가용성

• 운영 쿼리 : 1회 1레코드 쿼리

DW/BI 시스템처럼 광범위하고 예상치 못한 방법으로 쿼리하지는 않는다고 가정

• 과거 데이터 유지 하지 않음


Extract, Transformation, and Load System

• 작업영역, 데이터 구조, 프로세스 집합으로 구성

• Extract

DW 환경에서 데이터를 가져오는 과정

Source data를 읽고 이해하고, 추가적인 데이터 가공을 위해 ETL 시스템에 필요한 데이터를 복사하는 과정

이 때, data는 DW에 속하게 됨

• Transformation

추출된 데이터를 정제하고(오타 정정, 도메인 충돌 해결, 누락된 항목 처리, 표준 포맷에 맞추는 파싱), 합치고, 중복 제거 하는 과정

데이터 정제와 표준화 작업을 통해 데이터의 가치 증대

• Loading

최종목표인 프레젠테이션 영역의 다차원 모델에 데이터를 적재하고 물리적으로 구성하는 과정

Dimension과 fact table에 데이터를 담아 주는 적재 서브시스템이 중요


• Loading subsystem

Dimension Table

– 대체 키 할당

– 적절한 설명을 제공하기 위한 code lookup

– 적합한 데이터 값을 보여주는 column의 분리, 통합

– 제3정규화 테이블 구조를 평평한 반정규화 dimension으로 join

Fact Table

– 데이터 양이 많아 loading에 많은 시간 소요

• ETL 처리를 위해 정규화 DB를 만드는 것은 선택적이다

ETL 시스템 개발자는 정규화 구조를 이용한 정제와 변형 작업을 더 수월하게 수행 할 수도 있다


Presentation Area to Support Business Intelligence

• 데이터가 구성되고, 저장되며, 사용자 및 레포트 작성자와 BI 애플리케이션에 의해 직접적인 쿼리가 가능하도록 만들어지는 곳

• 데이터는 관계형 스타 스키마 또는 OLAP 큐브로 된 다차원 스키마로 표현되고, 저장되며, 접근되어야 한다

• 상세한 최소단위 데이터를 포함해야 한다

예측불가한 ad hoc 사용자 쿼리를 견디기 위해 최소단위 데이터가 필요

• 비즈니스 프로세스 중심적

영업팀, 마케팅팀, 물류팀, 재무팀을 위한 유사하지만 약간씩 다른 매출 측정값들을 저장하는 DB를 구성하지 말고, 최소단위 매출 측정값을 갖는 하나의 팩트 테이블을 구성해야 한다

• 공통의 표준 dimension 사용

Enterprise DW Bus Architecture – ch4


Business Intelligence Application

• 비즈니스 사용자들이 분석적 의사결정을 위해 presentation Area을 활용하도록 기능을 제공해 주는 것

• Tool

Ad hoc query tool, 정교한 data mining이나 modeling application


Restaurant Metaphor for the Kimball Architecture

Restaurant DW/BI

Back room

장소 주방 ETL

설계시 고려사항

재료의 품질 정결함 동일한 맛

데이터 품질 무결성 일관성

접근 가능자 주방 직원 ETL 개발자

접근 제한자 손님 비즈니스 사용자 BI application 개발자

Front Room

장소 식당 Presentation area BI application

평가요소 음식 (품질, 맛, 미관) 인테리어 서비스 가격

Data (일관성 있는 높은 품질) BI 사용자의 선호로 구성 DW/BI 시스템 (데이터가 비즈니스 사용자와 BI application 개발자가 좋아하는 형태로 신속 전달) 비용

Alternative DW/BI Architecure

Independent Data Mart Architecture


Independent Data Mart Architecture

• 전사적으로 정보를 공유하고 통합하는 데는 관심이 없고 단지 부서 기준으로 만들어짐

• 하나의 부서가 operational source system으로부터의 데이터 요구사항을 정의한다

• 특정 부서는 그 부서의 니즈에 충족하는 비즈니스 규칙과 기본 레이블이


Hub-and-Spoke Corporate Information Factory Inmon Architecture


Hub-and-Spoke Corporate Information Factory Inmon Architecture

• CIF(Corporate Information Factory ) 방식은 Bill Inmon과 업계 사람들에 의해 주창됨

• data는 operational source system으로부터 추출되고 data 획득이라고 불리는 ETL system을 통해 처리 되고 이로 부터 나온 최소단위 데이터는 3차 정규화 DB에 적재된다

• 정규화된 최소단위 저장소 = EDW

• normalized EDW가 전사 차원의 데이터 중재와 통합하는 역할을 한다

• CIF는 비즈니스 프로세스 중심으로 구성되기 보다 부서중심적이고 최소 단위 데이터보다는 집계된 데이터를 제공한다


Hybrid Hub-and-Spoke and Kimball Architecture


Hybrid Hub-and-Spoke and Kimball Architecture

• Kimball + Inmon CIF

• CIF 중심의 EDW를 생성하는 곳으로 Kimball의 presentation area을 생성하는 원천이지만, 분석과 리포팅을 원하는 비즈니스 사용자의 접근은 금지한다

• presentation area의 data는 다차원적이고 최소단위이며, 프로세스 중심적으로 enterprise DW bus achitecture를 준수한다

• 사용자 쿼리는 전적으로 다차원의 presentation area에서 처리하도록 해 3차 정규화 EDW의 성능과 활용성 문제를 해결하면서 기존의 통합 저장소를 활용할 수 있다

Dimensional Modeling Myths

다차원 모델은 오직 요약데이터를 위한 것이다

• 잘못된 다차원 모델을 설계하는 근본 원인

• 비즈니스 사용자가 요청할 질문을 모두 예측할 수 없기 때문에 가장 상세한 데이터를 조회할 수 있도록 해야 한다

• 그래야 비즈니스 요청에 따라 데이터를 roll up 할 수 있다

다차원 모델은 전사가 아닌 부서단위 모델이다

• 조직의 부서가 아닌 비즈니스 프로세스 중심으로 구성되어야 한다

다차원 모델은 확장성이 없다

• Fact table은 수십억 건을 갖는 경우도 있고, 2조 건의 fact table이 보고된 사례도 있다

• DB 업체는 자신들의 제품이 다차원 모델의 확장성과 성능에 최적화되도록 기능을 지속적으로 추가 하고 있다

Dimensional Modeling Myths

다차원 모델은 예측 가능한 분석 패턴에만 유용하다

• 다차원 모델은 사전에 정의된 리포트나 분석에 맞춰서 설계하는 것이 아니라 측정 프로세스 중심으로 해야 한다

• 항상 변화하는 분석 패턴이 아닌 안정된 조직의 측정 이벤트에 초점을 맞추는 것이다

다차원 모델은 통합되지 않는다

• 다차원 모델은 enterprise DW bus architecture를 준수한다면 반드시 통합된다

• 표준 demension은 ETL system에서 중앙 집중적이고 지속적인 mater data로서 생성되고 유지되고, 데이터 통합과 의미론적 일관성을 위해 다차원 모델에서 재 사용하며, 데이터 통합은 표준화된 레이블, 값, 정의에 의존한다

More Reasons to Think Dimensionally

DW/BI 프로젝트의 중요 시점마다 다차원적으로 생각해야 한다

DW/BI 요구사항 수집 시, 비즈니스 프로세스 중심으로 생각해야 한다

DW/BI 시스템의 data architecure 설계 시, 관련된 master dimension data와 함께 조직의 프로세스 중심으로 정리해야 한다

데이터 관리체계나 거버넌스 프로그램은 먼저 주요 dimension에 집중해야 한다

• 비즈니스를 서술할 때 중심이 되는 명사들이 비즈니스 커뮤니티의 업무 전문가에 의해 주도되는 데이터 거버넌스의 대상이 된다

• 데이터 거버넌스 확립이 결과적으로 일관성을 보장하고, 분석 시 조건, 그룹핑, 레이블 등 업무 니즈를 해결하는 dimension을 구축하는 핵심이다

More Reasons to Think Dimensionally

다차원 개념은 스타스키마나 OLAP 큐브를 설계하기 훨씬 이전부터 전면에 중심에 있고, ETL system과 BI application을 설계하는 동안에도 최전방에 있다

Agile Considerations

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은 것을 빠르고 낭비 없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

- wiki -

agile 방법론은 오랜 기간이 걸리는 프로젝트 보다는 몇 주 만에 완료할 수 있는 관리가 쉬운 크기의 작업에 초점을 둔다

Kimball과 일치하는 agile 핵심 원칙

• 비즈니스 가치 전달에 초점을 두자

• 개발팀과 비즈니스 이해관계자 간의 협력을 중시하자

• 비즈니스 이해관계자와 지속적인 면대면 의사소통, 피드백, 우선순위 매기기를 실행하자

• 필연적으로 진화하는 요구 사항에 빠르게 대응하자

• 반복적이고, 점진적인 방법으로 개발하자


agile 방법론은 계획과 아키텍처의 부족, 지속적인 관리가 어려운 단점을 가지는데, enterprise DW bus architecture는 이러한 단점을 해결하는 강력한 도구이다

enterprise DW bus architecture

• Bus matrix

agile 개발을 위한 프레임워크와 마스터 플랜을 제공하고, 데이터의 일관성과 신속한 개발을 위한 재사용 가능한 공통 dimension을 식별해 준다

현업과 IT 간의 올바른 협력 관계를 통해 비교적 짧은 시간에 만들 수 있다

기능이 충분해져서 현업에 릴리스 될 때까지 점진적 개발을 통해 구성요소를 생산해 낼 수 있다


표준 dimension

• 다수는 표준 dimension을 만들고 싶지만 현실적으로 불가능하다

• Kimball은 agile DW/BI 개발과 agile 의사결정을 함께 가능하게 한다

• 구축된 표준 dimension이 늘어날수록 개발은 점점 빨라진다

• 새로운 비즈니스 프로세스에 대한 data source를 추가하는 시간이 단축된다

• 나중에는 신규 ETL 개발이 거의 fact table을 만드는 것에만 집중할 수 있다


대부분, enterprise DW bus matrix와 같은 프레임워크 없는 상태에서 분석 또는 리포팅 솔루션을 만들기 위해 agile 기법을 사용하는 덫에 빠진다

• 소수 사용자들과 작업하여 제한된 data source에서만 추출하고 그들의 특별한 문제만 해결해준다

• 결과는 고립된 data 저장소가 되어 다른 사용자들은 전혀 활용할 수 없거나 조직 내 다른 분석정보와 연관성을 맺을 수 없어 시너지를 낼 수 없다

agile을 권장하지만 고립된 data set을 구축하는 것은 피해야 한다

Thank you

data warehousing, business intelligence, and dimensional modeling...

Documents