나는 표준 OLTP 정규화 된 데이터베이스를 가지고 있으며 데이터의 다른 차원에서 몇 가지 복잡한 쿼리 (평균, 표준 편차)를 수행해야한다는 것을 알고 있습니다.관계형 OLTP 데이터베이스에서 OLAP 큐브로 전환하는 가장 좋은 방법은 무엇입니까?
그래서 SSAS와 OLAP 큐브를 만들었습니다.
그러나 큐브를 만들려면 데이터 원본 구조가 '별'또는 '눈송이'구성에 있어야한다고 생각합니다 (현재 생각하지 않습니다).
SSIS를 사용하여 기본 OLTP DB에서 일종의 ETL 프로세스를 수행하여 사실과 차원이 적절한 '별'구성에있는 다른 관계형 데이터베이스로 변환 한 다음이 데이터베이스를 다음과 같은 데이터 원본으로 사용합니다. OLAP 큐브?
감사합니다.
네, 그게 기본 아이디어입니다. 고도로 정규화 된 OLTP 데이터베이스를 가져 와서 데이터를 잘라내어 다이 싱 한 다음 보고서를 표시 할 목적으로 큐브로 비 정규화합니다. 논리적 설계 기법을 차원 모델링이라고합니다. 에 대한 많은 훌륭한 정보가 Kimball Group에 있습니다. Ralph Kimball의 books on the subject도 우수합니다. BI 도구에 대한 자세한 내용은 SSIS, 분석 서비스 등에 대한 virtual labs을 확인하십시오.
답변 : 예,하지만.
SSAS의 차원은 조각을 기준으로 필터링하기 위해 일련의 필드로 사용할 수있는 특성 간의 관계가 있습니다. 이러한 관계는 계층 구조가 될 수 있습니다 (한 수준 이상의 깊이 - 하나의 특성에 부모와 자식이있을 수 있습니다.) SSAS에서 계층 구조라고하는 드릴 다운 경로를 설정하여 특성처럼 작동하지만 가이드 드릴 다운을 수행 할 수도 있습니다.
순서대로 이 작업을 수행하려면 엄격하게 계층 적 관계에있는 데이터베이스에서 키를 사용할 수 있어야합니다. 즉, 키가 하나 이상의 부모를 가질 수있는 퍼지 관계를 가질 수 없습니다.
이러한 계층 구조는 시스템에서 플랫 데이터 구조로 만들거나 기본 데이터 소스 뷰에 마크 업된 관계로 눈송이를 통해 표시 할 수 있습니다 (DSV는 큐브 메타 데이터의 일부 임). 될 수있다. 데이터베이스보기와 유사한 방식으로 데이터를 마사지하는 데 사용됨).
눈송이는 1 : M 관계 만있는 3NF-ish 스키마입니다 (엄격히 3NF가 아니어야 실제로 실용적으로 전개 할 수 있습니다). SSAS는 부모 - 자식 (재귀 자체 조인을 가진 부모 - 자식 관계)과 M : M 차원 (M : M 관계 - 정확히 그들이 말하는 것처럼)과 같은 몇 가지 다른 차원 구조를 지원할 수 있습니다. 이 유형의 치수는 더 까다 롭지 만 유용 할 수 있습니다.
눈송이와 동일한 데이터 의미를 가질 수있는 소스 데이터에 키가있는 경우 소스 시스템에서 눈송이 모양의 기본 데이터를 표시하는 일련의 데이터베이스보기를 통해 큐브를 채울 수 있습니다. 큐브 차원에 사용할 형식을 사용합니다 (실제로이 작업을 두 번 수행했습니다). 합성 키를 많이 사용하는 스키마는이 작업에 적합합니다.
원본 데이터베이스에보기를 추가 할 수 없도록하는 경우 데이터 원본보기를 대신 사용할 수 있습니다. DSV는 데이터베이스 쿼리에서 채워지는 'named queries'라는 가상 테이블을 가질 수 있습니다.
팩트 테이블이 차원에 조인합니다. SSAS2005 +에서는 차원 내의 서로 다른 입자에서 서로 다른 팩트 테이블을 조인 할 수 있습니다. 데이터웨어 하우스에서 일반적으로 많이 사용하지는 않지만 원본 데이터를 너무 많이 마사지하지 않고도이 기능을 사용하면 유용 할 수 있습니다.
이것이 작동하지 않으면 별 또는 눈송이 스키마를 채우기 위해 ETL 프로세스를 작성해야 할 수 있습니다.
몇 가지 단서 조항 :
큐브 그들은 단지 기본 데이터에 대한 쿼리를 실행 실시간 모드에서 실행되도록 할 수
(i)의 Apropos를 사용하면 응용 프로그램의 화면에 대한 데이터 소스로 큐브를 사용할 수 없을 것입니다. 사용자가 화면에서보고 자하는 것에 대한 평균을 계산할 필요가 있다면 화면 뒤의 저장 프로 시저에서 계산해야 할 것입니다.
이렇게하면 복제 된 데이터베이스를 설정하고 큐브를 채 웁니다. 이 데이터베이스를 정기적으로 새로 고치십시오. 그러면 내부적으로 일관된 데이터 세트에서 ETL 프로세스를 실행할 수 있습니다. 실제 데이터베이스에서 실행하는 경우 해당 프로세스가 실행 된 후 작성된 레코드에 따라 나중에 채워지는 일부 항목의 위험에 노출됩니다.
차원로드를 실행 한 다음 시스템에 새 데이터가 입력되는 상황을 만들 수 있습니다. 팩트 테이블로드가 실행되면 이제로드되지 않은 디멘션 데이터에 종속 된 데이터가 포함됩니다. 그러면 큐브가 손상되고로드 프로세스가 실패하게됩니다. 복제 된 데이터베이스를 일괄 새로 고침하여 ETL 또는 큐브로드를 실행하면이 문제가 완화됩니다.
복제 된 데이터베이스 옵션이없는 경우 누락 된 데이터에 대해 더 많은 여유 시간 정책을 설정할 수 있습니다.
기본 생산 데이터에 중요한 데이터 품질 문제가있는 경우 큐브에 반영됩니다. GIGO.