database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Columns 568 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 568
정보처리기술의 페러다임 - Data WareHousing 과 OLAP (3)
작성자
정재익(advance)
작성일
2002-09-22 12:19
조회수
5,995
첨부파일: pictures2.zip (82,610bytes)

■ OLAP : On Line Analytical Processing

 

OLAP(온라인 분석 프로세싱)은 OLTP에 상대되는 개념으로 코드(1993)주)는 기업의 데이터 모델을 정적모델과 동 적모델로 구분한다음, OLAP을 "동적 모델로부터 정보를 생성, 조작, 활성화(animation), 종합하는 데 필요한 역동적 기업분 석"으로 정의하고 있다, 여기서 정적 모델이란 사용자의 대화식 참여가 거의 없고 정형화된 양식의 보고서생성작업이나 간 단한 질의가 수행되는 모델을 말한다. 여러자지 OLAP에대한 정의를 정의하면

『최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정』으로 정의하면 적절하겠다. 좀더 그특징을 살펴보면

 

첫째, 분석을 위해 활용되는 정보의 형태는 다차원적주)이라는 사실이다.

다차원정보는 사용자들에 의해 이해되는 기업의 실제 차원(기간, 제품, 부서, 지역등)을 반영한다. 정보의 다차원성은 OLAP시스 템을 다른 시스템과 구분하는 가장중요한 개념으로,OLAP를 다른 말로 표현한다면 바로 "다차원 분석"일 것이다.

 

둘째, 최종사용자는 중간 매개자(전산부서)나 매개체(리포트)없이 온라인 상에서 직접 데이터에 접근한다는 것이다. 가트너 그룹은 정보기술에 의한 정보매개자의 제거는 앞으로의 핵심적인 비지니스 이슈중의 하나라고 말한다. 이러한 의도의 방향은 OLA P의 지향점이라고 정의할수 있다.

 

셋째, 최종사용자는 대화식(interactive)으로 정보를 분석한다는 것이다.

시스템은 사용자의 사고 흐름이 중간에 끊이지 않도록 신속하게 질의 결과를 제시할수 있어야 한다는 의미이다.

 

넷째, OLAP의 목적은 최종사용자가 기업의 전반적인 상황을 이해할수 있게하고 의사결정을 지원하는데 있다. OLTP는 매일 매 일의 기업운영을 가능하게 하는반면, OLAP는 기업이 나가야할 방향을 설정할수 있는것이다.

 

주) 코드는 관계형 모델의 창시자이며 동적모델을 Exegetical Model, Contemplative Model, Formula ic Model로 구분했다.

 

주) 다차원정보는 사용자들에 의해 이해되는 기업의 실제차원을 반영하는 정보이다. 기본적으 로 기업의 업무구조는 다차원적이며, 비지느스 사용자가 필요로하고 활용하는 대부분의 정보는 다차원정보이다. 즉 사용자는 단 순히 '매출액이 얼마인가'라고 묻지 않는다. '이번달 매출액이 지난달에 비해서 얼마나 상승했는가 혹은 하락했는가', '지난 해 같은 달에 비해서 어떠한가', '목표치를 달성했는가', '경쟁사의 매출액과 비교해서는 어떠한가', 등과 같은 정보를 알고 싶어한다. 데이터는 이와같은 배경(Context)을 가질 때 비로소 정보로서 가치가 있다. 정보란 본질적으로 비교를 나타내며, 다차 원 정보는 다양한 각도(차원)에서 이러한 비교를 가능하게한다. 데이터 항목들 사이에 내재된 상호관련성이 높을수록 이러한 상 호관계에 대한 분석은 가치있는 정보가 될것이며, 다차원 모델의 대상이 될것이다.

 

 

▶ OLAP 시스템 분석 - OLAP Server와 웨어하우스

OLAP서버는 데이터 웨어하우스환경에서 사용자에게 다차원 정보를 제공하는 분석용 데이터 마트로 정의할 수 있다. OLAP서버 는 비지니스 룰에 의해 기존의 데이터로 부터 새로운 정보를 만들어 내는 연산엔진이라 할수 있을 것이다.

 

OLAP서버는 많은 측면에서 데이터웨어하우스와는 다른 특성을 갖는다. OLAP은 복잡한 연산과 모델링을 포함하여 기업데이터 의 다차원 분석을 수행한다. OLAP는 이처럼 특화된 분석을 수행하는데 비해, 데이터웨어하우스는 기업의 모든 사용자를 대상으로 이들이 수행할 잠재적인 모든 유형의 질의에 대처하기 위한 정보저장고로서의 역할을 한다. 데이터웨어하우스는 사용자들이 자 신의 업무를 보다 효과적으로 수행할수 있도록, 그리고 좀더 정보에 근거한 의사결정을 할수있도록, 가능한 모든 정보의 저장소( Vertual repository)를 만드는데 있다(Crandall, 1995). 따라서 데이터웨어하우스는 좀더 상세한 혹은 트랜잭션 수준의 데이터까 지 보유할수 있다.

 

데이터웨어하우스는 일반적으로 OLAP시스템이 사용하는 것처럼 복잡한 다차원 분석을 지원하지 못하며, 읽기전용(Read only) 이다. 반면 OLAP시스템은 다음그림처럼 사용자들이 직접 데이터를 갱신하고 분석할수 있도록 허용한다. 예를들어 사용자들은 계 획 데이터, 예산 데이터를 갱신할 수 있다. 많은 OLAP시스템이 미래지향적(future oriented)인 반면, 데이터웨어 하우스는 과거 지향적이며, 추측과 관련된 자료를 포함하지 않는다. 즉 사용자는 OLAP을 통해 기업의 미래에 관한 질문을 수행한다.

 

그림 : 데이터웨어 하우스와 OLAP서버

Eg) '원료가격이 5%인상되고 운송비가 10% 하락한다면, 제품원가에 어떠한 영향을 미치는가"와 같은 질문을 수행하게된다.OLAP에서 사용자는 대화식질의를 수행하며, 질의 결과를 신속하고 일관성 있게 얻기를 기대한다. 반면 데이 터 웨어하우스에서 수행되는 질의는 매우 간단한 질의에서 매우 복잡한 프로세싱을 요구하는 질의에 이르기까지 다양하며, 질의 속도도 질의 유형에 따라 많은 차이가 있다.

 

7

 

OLAP서버는 데이터웨어하우스를 대체하는 개념이 아니며, 보완하는 개념이다. OLAP 시스템은 사용자에게 일관되고 신속한 응답 속도를 제공하기 위해 다차원정보를 물리적인 공간에 잠시 저장할수 있으며(다차원 데이터베이스 접근법 ), 데이터웨어하우스(혹은 데이터마트)로부터 실시간적으로 다차원 데이터 구조를 생성할수 있고, 두가지 기법을 병행살수도 있다.

 

■ 관계형 데이터베이스에 관한

 

데이터 웨어하우스(Data WareHose)디자인과 다차원데이터베이스

 

▶ 고전적 Entity-Relationship 모델링과 의사결정 지원

 

의사결정 지원 소프트웨어(Decision Support Software; DSS)는 복잡한 데이터 분석을 할 수 있다. 데이터 웨어하우스를 지원하 도록 고안된 데이터 모델들은 DDS의 문제를 처리할 수 있는 완벽한 전략을 요구한다. 고전적 Entity-Relationship 모델들이 의사 결정 지원과 관련해서 실패하는 많은 이유 중의 하나는 성능이 나쁘기 때문이다. 표준의 고도로 규정화 된 데이터 모델들은 레코 드를 거의 포함하지 않는 많은 양의 트랜잭션에 가장 효율적인 데이터 액세스를 제공하도록 고안되어 있다. 의사결정 지원 시스 템에서는, 많은 레코드들을 액세스하면서, 상대적으로는 트랜잭션을 거의 수행하지 않는 경향이 있습니다. 이것이 OLAP(OnLine A nalytical Processing, or Decision Support) 시스템과 OLTP(OnLine Transaction Processing)의 차이입니다. 이 차이는 정보 웨 어하우스 디자이너에게 중대한 암시를 주게된다.

 

OLTP 시스템에서는 데이터 처리가 고도로 구조화되어 있기 때문에, 복잡한 데이터 모델들이 잘 작동될 수 있다. 일반적으로 트 랜잭션은 한 시점에 하나 또는 두 개의 테이블을 포함하고, 종종 하나의 레코드만을 처리하기도한다. 이것은 복잡한 테이블 관계 가 높은 성능을 발휘하는 데 크게 영향을 주지 않음을 의미한다. 반대로, DSS 처리는 한 번에 수십만의 열을 액세스하는 것을 수 반할 수 있다. 이와 같은 경우, 복잡한 결합은 성능에 중대한 영향을 미칠 수 있게되는 것이다.

 

 

그림: 샘플 ER 도표. 트랜잭션 세일즈 데이타 를 저장하기 위한 부분 스키마를 나 타내고 있다.

 

[img8]

 

실제 ER 모델들은 더 복잡하며, 전형적 Entity-Relationship 모델들이 의사결정 지원과 관련해서 실패하는 두 번째 이유는, 그 것들이 매우 복잡하고 조정하기 어려운 경향이 있기 때문이다. 위그림의 OLTP 시스템에서는 결코 문제가 되지 않았다. OLTP 환경 의 사용/액세스 방향은 잘 알려져 있으므로, 애플리케이션은 항상 특별한 데이터 구조를 사용하도록 하드코드화 될 수 있다. DDS 의 경우, 사용은 비구조화되어 있으며. 사용자들이 자료를 요구하기 전에, 사용자들이 종종 어떤 데이터가 분석되는지를 결정하 게된다. 사용자들이 원하는 데이터를 주기보다는, 데이터를 어떻게 얻을 수 있는지를 더 생각한다면, 그들의 의사결정 지원 환경 은 불충분하다.

 

▶ 독점적 다차원 데이터베이스

고전적 ER 모델링과 DDS의 문제에 대한 해결책으로, 독점적 "다차원" 데이터베이스를 제시하는 업자들의 분석을 살 펴볼 필요가 있다. "차원"은 정보를 보는 방법을 나타낸다. 다차원 데이터베이스는 이들 차원에 따라 구조화된다. 예 를 들면, 분석가는 세일즈 데이터를 구조화하기 위한 세 개의 전형적 차원인 지리적, 시간적, 제품에 의해 보기를 원할 것이다. 다차원 데이터베이스 업자들은 그들의 소프트웨어가 사용자들의 사업을 직관적으로 생각하는 방법에 꼭 맞는 공동 데이터의 뷰(V iew)를 나타낸다고 주장하는 경향이 있다. 그것들은 전통적인 RDBMS의 "열과 컬럼" 뷰와는 뚜렷한 차이를 보인다. 바 로 이것이 이해하기에는 결정적으로 어려운 부분이된다. 또한 다차원 업자들은 그들의 중간 사이즈의 독점적 데이터베이스가 전 통적 RDBMS 소프트웨어보다 더 좋은 성능을 수행한다고 주장하게된다.

그러나, 관계형 데이터베이스 디자인은 복잡함을 필요로 하지 않는다. 개방형 기술에 대한 투자를 계속하는 동안, 현업 사용자 에게 데이터의 직관적 표현을 제공하면서 RDBMS에서 다차원적으로 데이터를 모델화하는 것이 가능하다. 또한, 이 데이터 모델을 근거로 한 전략들은 관계형 데이터베이스가 매우 큰 데이터 웨어하우스에서 다차원 데이터베이스보다 성능이 우수하다. 이 데이 터베이스 디자인 활용례가 "차원적 모델링"으로 알려져 있다. 차원적 모델링 배후에 있는 기술적 개념을, 가장 큰 데이터 웨어하우스에서 고도의 성능을 수행하기 위해 투자 전략으로 세부사항을 살펴본다.

 

▶ 차원(Dimensional) 모델링

차원 모델링은 Natural Business 개념에 대한 데이터를 구조화하고, 실행되는 세련된 데이터를 위한 기초를 제공하기 위해서 개 발된 기술이다.

전통적 ER 모델들은 "Entities"와 "Relationships"를 나타낸다. 이 전략은 정확한 한 개의 Entity를 나타 내는 많은 테이블로 정보를 분산하는 데 초점을 둔다. Entity는 실제 오브젝트(제품 또는 고객)이거나, 트랜잭션(세일즈 또는 주 문 라인 항목)이다. Entities는 결합의 복잡한 시리즈를 통해 밀접한 관계를 이룬다.

 

차원 모델링에서, 데이터 구조는 "측정(measures)"과 "차원(dimensions)"을 나타내기 위해서 구조화된다. 측정은 탐지되는 숫자 데이터이다. 그것은 중앙의 "실제(fact)" 테이블에 저장되며. 차원은 각 트랜잭션을 정의하는 N atural Business Parameter이다. 차원은 중앙의 실제(fact) 테이블에 연결된 위성 테이블에 저장된다. 실제(fact) 테이블에 저장 된 데이터의 고전적 예들은 세일즈, 재고, 잡지 구독예약, 지출과 총 판매수익 데이터를 포함하게된다. 고전적 차원 테이블은 시 간, 지리적, 거래와 제품 데이터를 포함한다. 차원 모델링의 초점은 분석가가 그들 사업에 대해 직관적으로 생각하는 방법에 따 라 정보를 구조화하고, 정보를 의미 있고 통합된 리포트로 검색하기 위해서 필요한 결합을 최소화하는 것이다.

 

예를 들어, 전형적으로 마케팅 분석가가 다음과 같은 질문처럼 세일즈 데이터를 조사한다고 가정하자. "지난 6개월 동안 제품 라인 매니저별 세일즈" 또는, "1994년 4월의 계좌별 세일즈". 이 시나리오에서, 데이터 모델은 세일즈 정보 를 추적하기 위한 하나의 fact table로 구성될 것이다. 각 세일즈의 경우, 다른 변수 중에서 주문된 양을 저장하는 레코드, 가격 및 증가한 가격이 있을 것이다. 위성 또는 차원 테이블은 거래 정보, 제품 정보와 시간 정보를 포함할 것이다(세일즈 정보의 내 추럴 차원).

이 시나리오에서, 모든 세일즈 레코드는 각각의 차원 테이블에 실제(fact) 테이블을 연결하는 키(key)를 소유하게 된다. 따라서 , 실제(fact) 테이블은 주문된 양, 세일즈, 거래 코드, 시간 코드 및 제품 코드를 저장할 것이다. 다음그림에서 실제(fact) 테이 블은 일반적으로 완전 정규화 되고 테이블 내에 어떠한 중복된 데이터를 허용하지 않음을 보여준다.

 

[img9]

 

그림 - 샘플 실제 테이블로부터의 데이타

 

차원 테이블 내의 정보는 Standard Query Constraints뿐 아니라, 리포트 내에 Sub-total Break Points를 정의하는 데 사용된다. 전형적 Query는 "서부 지역에 있는 모든 소매점을 위한 월별 브랜드별에 의한 세일즈"를 요청한다. 이 경우, 세일즈 는 실제(fact) 테이블에서 발견될 것이고, 이 테이블은 제품, 시간 그리고 지리적 차원 테이블에 연결되는 것이다. 지리(지역)가 Query Constraint로서 사용되는 동안, 제품(브랜드)과 시간(월)은 리포트의 Break Points로서 사용된다.

 

차원 테이블은 각각의 특별한 차원과 연관된 모든 정보를 저장하며 원래 이것은 다음을 포함합니다.

 

▶각 차원의 계층적 관계를 추적

▶각 차원의 기술적 속성(descriptive attributes)을 추적

 

차원은 종종 계층 구조화될 수도 있다. 계층의 각 레벨은 다음 레벨로 다가가는 것이다(roll up). 예를 들면, 시간 차원에서 날 (days)들은 분기(quarters)로 가는 주(weeks)에 다가가는 것이다. 제품 차원의 경우, 제품(product)은 브랜드(Brand)로 가는 제 품 라인(product line)에 다가가는 것이다.

계층(Hierarchy)이 "drill-down"과 "drill-up" 기능을 위한 구조를 제공하는 것처럼, 계층은 차원 모델링 에서 매우 중요하다. Drilling down은 데이터 세트의 좀더 상세한 뷰를 요구하는 과정이다. 예를 들어, query가 지역별 세일즈를 나타낸다고 합자. 한 지역에서 볼 때, 사용자는 그 지역에서의 세일즈가 주(state)에 의해 어떻게 분류되는가를 보기 위해서 dr ill down하기를 원할 것이다. Drilling up은 데이터의 좀더 요약된 뷰를 요구하는 것처럼 drilling down과는 반대이다. 여기에 표시된 것처럼 모든 계층이 정확하게 다가가지(roll up) 않는다는 것을 주의해야 한다. 예를 들어, 날(days)들은 주(weeks)와 달 (months)로 다가갑니다. 달(months)이 주(weeks)로 공평하게 분할되지 않기 때문에, 주(weeks)는 달(months)로 갈 수 없다. 그러 나 주(weeks)와 달(months)은 분기(quarters)로 간다. 다음그림에서 많은 경우에 계층은 이것보다 매우 복잡하다. 계층 모델링의 문제 중 하나는 그와 같이 구조적으로 복잡하다는 것이다.

 

▶ 차원 요소

"차원 요소"는 차원 계층에서 특별한 레벨을 나타내는 데이터의 범주이다. 각 계층 레벨에는 한 개의 차원 요소가 있 다. 따라서, 제품 차원에는 3개의 차원 요소(제품, 제품 라인, 브랜드)가 있을 것이다. 이 모델에서, "브랜드"가 가장 상위의 레벨을 나타내는 반면, 차원 요소인 "제품"은 제품 차원에서 가장 낮은 계층 레벨을 나타낸다고 말할 것이다.

 

 

그림 : 복잡한 시간 계층. 차원 요소는 위의 피라미드 그림보다 실제로 더 복잡한 계층을 이루면서 몇몇 다른 조합으로 다가간다.

 

[img10]

 

▶ 차원 속성

"차원 속성"은 특별한 차원 요소를 나타냅니다. 예를 들어, "브랜드 매니저"는 차원 요소 "브랜드"를 나타내는 차원 속성일 것이다. "취향(flavor)"은 차원 요소인 "제품"을 나타내는 차원 속성일 것 이다. 차원 속성은 사용자가 비계층적 데이터를 분류할 수 있도록 한다.

 

▶ 스타 도해(Star Schema)

차원 모델의 실제 구조는 "스타" 도해로 나타낸다. 다음그림이 설명하는 것처럼 스타 도해는 차원 테이블로 둘러 쌓 여 있는 스타 중심에 있는 실제(fact) 테이블로 나타날 수 있다.이 schema는 테이블들이 여기에서 보 여준 컬럼보다 더 많은 컬럼을 가질 것임을 나타낸다. 테이블 의 실제 수(5)는 4차원 정보 웨어하우스에 있는 것과 같다.

 

▶ 차원 비정규화(Denormalization)

스타 도해의 특성을 정의하는 것은 차원 테이블을 비정규화하는 것이다. 비정규화는 데이터가 디자인의 단순함과 성능을 위해서 각각의 테이블에 반복적으로 저장되는 데이터베이스 디자인 접근 방법이다. 따라서, 차원 속성은 속성이 나타내는 차원 계층의 레벨에 따라 차원 테이블 속에 반복적으로 저장될 것이다.

예를 들어, 한 회사가 총 5개의 브랜드로 나타나는 100개의 개별 제품을 가지고 있다고 하자. 차원 테이블에 등록되어 있는 모 든 제품을 위해서, 브랜드에 모든 속성이 있는 것처럼, 그와 연관된 브랜드도 역시 등록되어 있다. 브랜드 매니저 정보는 제품 차원에 있는 모든 레코드에 실제로 저장될 것이다. 브랜드명과 다른 모든 브랜드 속성들은 같다. 규정화된 데이터 모델에서, 브 랜드 속성은 일단 브랜드 테이블에 통상적으로 저장될 것이고, 오직 그 테이블의 foreign key만 여러 번 참조될 것이다.

 

 

▶ 차원 모델링의 장점

차원 모델링에서 스타 도해의 단순함은 다음의 4가지 중요한 장점을 보여준다.

 

첫째,이것은 복잡한 다차원 데이터 구조를 매우 단순한 데이터 모델로 정의하도록 합니다. 각 차원 내에 계층적 관계를 정의하 기 쉽게 하고, 여러 테이블을 통해 연결하는 작업을 단순화한다.

둘째,Query가 수행해야 하는 실제 연결(join) 횟수를 감소시킵니다. 이것은 굉장한 성능 향상을 가져온다.

세째,데이터 모델의 뷰를 단순화함으로써, 중요한 자원을 소모하며 부정확한 정보를 보여주는, 사용자의 부주의함으로 발생되는 잘못되고 장시간 수행되는 Query를 감소시킨다.

넷째데이터 웨어하우스의 확장이 용이하고, 상대적으로는 관리가 쉽다. 스타 도해의 단순함과 강력한 차원 디자인은 데이터 웨 어하우스 성장에 융통성을 제공한다.

 

 

▶ 결 론

전통적 entity-relationship 데이터 모델은 오늘날 대부분 오퍼레이션인 RDBMS에 의거한 애플리케이션을 추구하는 OLTP에서 효 율적으로 기능을 수행한다. 이 데이터 모델의 성공으로, 그래픽 DDS와 EIS 시스템이 유사한 디자인을 이용해서 실행되었다. DDS 데이터베이스가 점점 커지고 복잡해짐에 따라, 성능은 나빠지고, 시스템은 사용하고 관리하기 어렵게 되었다.

여기에서 논의한 데이터베이스 디자인 접근 방식인 차원 모델링은 몇십배 까지 성능 향상을 가져온다. 다차원 사업 환경(multi- dimensional business environment)에 유사한 형식으로 정보를 나타냄으로써, 차원 모델링은 사용자에게 직관력을 주는 조정하기 쉬운 데이터 모델을 제공하는것이다. 더욱이, 차원 모델링의 구조적 단순함은 애플리케이션 관리를 손쉽게 하고, 데이터 웨어하 우스를 확장하는 데 융통성을 제공한다. 마지막으로, 데이터 웨어하우징에 대한 접근 방식은 개방적 기술에 대한 투자 수단인것 이다

[Top]
No.
제목
작성자
작성일
조회
576Datamodeling and Relational Database Design (1)
정재익
2002-09-29
5680
570정보처리기술의 페러다임 - Data WareHousing 과 OLAP (5)
정재익
2002-09-22
5717
569정보처리기술의 페러다임 - Data WareHousing 과 OLAP (4)
정재익
2002-09-22
5736
568정보처리기술의 페러다임 - Data WareHousing 과 OLAP (3)
정재익
2002-09-22
5995
567정보처리기술의 페러다임 - Data WareHousing 과 OLAP (2)
정재익
2002-09-22
5242
566정보처리기술의 페러다임 - Data WareHousing 과 OLAP (1)
정재익
2002-09-22
4922
559데이터베이스 모델링과 디자인의 기초
정재익
2002-09-17
6680
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.048초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다