'2016/11'에 해당되는 글 3건

  1. 2016.11.05 OLTP / OLAP 1
  2. 2016.11.05 다차원 모델링(1/2)
  3. 2016.11.05 DW, DM, OLAP의 이해 2

OLTP / OLAP

DB 2016. 11. 5. 17:10

OLTP (Online Transaction Processing) - 온라인 트랜잭션 처리

네트워크상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위 작업을 처리하는 방식을 말한다. 주로 신용카드 조회 업무나 자동 현금 지급 등 금융 전산 관련 부문에서 많이 발생하기 때문에 ‘온라인 거래처리’라고도 한다. 이 방식의 특징은 기존 컴퓨터 통신에서 이용해 온 온라인 방식과 달리 다수의 이용자가 거의 동시에 이용할 수 있도록 송수신 자료를 트랜잭션(데이터 파일의 내용에 영향을 미치는 거래 ·입출고 ·저장 등의 단위 행위) 단위로 압축, 비어 있는 공간을 다른 사용자들이 함께 쓸 수 있도록 한 점이다.



OLAP (OnLine Analytical Processing) - 온라인 분석 처리

OLAP는 사용자가 다양한 각도에서 직접 대화식으로 정보를 분석하는 과정을 말한다.OLAP 시스템은 단독으로 존재하는 정보 시스템이 아니며, 데이터 웨어하우스나 데이터 마트와 같은 시스템과 상호 연관된다. 데이터 웨어하우스가 데이터를 저장하고 관리한다면, OLAP은 데이터 웨어하우스의 데이터를 전략적인 정보로 변환시키는 역할을 한다. OLAP은 기본적인 접근과 조회·계산·시계열·복잡한 모델링까지도 가능하다. OLAP은 최근의 정보 시스템과 같이 중간매개체 없이 이용자들이 직접 컴퓨터를 이용하여 데이터에 접근하는 데 있어 필수적인 시스템이라 할 수 있다. 



OLAP 와 OLTP 의 차이점 

OLTP :  현재 업무의 효율적인 처리에만 관심이 있음

OLAP : 의사결정에 도움되는 데이터 분석에 관심이 있음

'DB' 카테고리의 다른 글

트랜잭션 서비스 사용  (0) 2016.12.20
트랜잭션(Transaction)과 2PC(two-phase commit)  (0) 2016.12.20
다차원 모델링(1/2)  (0) 2016.11.05
DW, DM, OLAP의 이해  (2) 2016.11.05
mssql 천단위 콤마 처리  (0) 2013.01.08
:

다차원 모델링(1/2)

DB 2016. 11. 5. 17:06

OLTP에서 가장 성능 좋은 DB를 만드는 방법에는 무엇일까요하드웨어의 성능을 올리거나확장하는 방법 또는 인덱스 생성 등 여러 가지 방법이 있겠지만가장 좋은 건 적합하고 합리적인 설계에 따른 DB모델링이 가장 중요하다고 생각 됩니다. OLAP도 마찬가지 입니다.

이번 시간에는 다차원모델에 대해서 알아볼 시간인데요처음부터 말씀 드리자면, OLTP와는 너무나 다른 설계 방법입니다또는 완전히 반대입니다. OLTP에서는 왼쪽으로 가야 한다면 OLAP에서는 오른쪽으로 가면 되겠네요~, 이러한 이유는 목적이 서로 틀리기 때문입니다. OLTP에서는 트랜잭션 단위로 처리하는 것에 중점이 있다면, OLAP은 최적화된 조회에 목적이 있기 때문입니다.

OLTP에는 관계형 데이터베이스(RDB)가 있다면, OLAP에서는 다차원DB(MDB or MDDB)가 있습니다비즈니스 영역또는 주제별 관점으로 구축되는 다차원DB를 설계하기 위해서는 다음의 구성요소가 필요 합니다.

01.png


 

가장 가운데 있는 다차원 모델은 별(Star), 눈꽃송이(Snowflake), 복합(Composite) 스키마로 구성됩니다별은 Star스키마눈꽃송이는 Snowflake스키마 라고 하겠습니다분석관점과 데이터 양에 따라서 모델을 선택하게 되는데대용량에서 가장 많이 사용되는 Star스키마부터 알아 보겠습니다.

 02.png


 

하나의 Fact(사실)테이블과 다수의 Dimension(차원)테이블로 구성되어 실제 사용자가 쉽게 이해할 수 있도록 단순하게 모델링 되며,원하는 보고서를 만들기 위해 필요한 조인의 횟수를 줄임으로써 사용자 질의에 빠른 속도로 응답할 수 있다는 장점을 가졌습니다각 차원은 기본 키 - 외래 키 관계에 따라 Fact테이블에 직접 연결되어 있는 단일 Dimension테이블을 기반으로 합니다

예를 들어 위에 그림처럼 Dimension테이블을 성별과 연령으로 각각 만들어서 Fact테이블에 외래키로 연결하는 것입니다. OLTP에서는 회원에 대한 Dimension테이블을 하나만 만들어서 성별과 연령을 속성으로 가져가겠지만 Star스키마에서는 이렇게 역정규화를 하게 됩니다.

Star스키마는 대용량에서 많이 사용됩니다분석관점이 명확하고 데이터 건수가 많은 경우에 유리하지만다른 관점으로 분석 요구 시 Dimension테이블이 추가 되고 Fact테이블에 대해서 변경이 일어 날 경우 처음부터 다시 쌓거나 다른 사실테이블을 만들어야 하는 불편함이 있습니다그러다 보니비슷한 테이블들이 여러 존재하고 너무 많아 지면 ETL에서 시간이 늘어나는 점이 있으니 유의 해야 합니다경험상으로는 분석관점이 명확할 때 사용해야 하는데 그렇지 않을 경우에는 Snowflake스키마가 더 적합할 때가 있습니다.

Snowflake스키마는 다음과 같은 구조를 가집니다.

 03.png


 

Star스키마의 Fact테이블 구조와 동일하게 유지하면서 Dimension테이블이 정규화된 구조를 말합니다

위에 Star스키마와 예와 비교한다면 회원에 대한 Dimension테이블을 하나를 만들어서 다시 여기서 성별 Dimension,연령Dimension을 생성한 후 회원Dimension과 연결하는 구조 입니다매출 Fact테이블에는 회원번호와 같이 식별할 수 있는 속성을 가지게 됩니다.

Snowflake스키마는 그래서 확장에 용이 합니다회원에 대한 속성에서 직업이 추가 된다고 해도 매출 Fact에는 변화가 없고 회원Dimension에 직업속성과 직업이라는 Dimension이 추가만 되면 됩니다하지만 Star스키마에 비해 많은 데이터를 보유 할 수 있으므로성능과 집계에 영향을 미칠 수 있습니다그리고 데이터 중복을 피할 수 있으나이해하기 어려운 단점이 있을 수 있습니다.이렇게 중간에 회원 Dimension과 같이 참조되는 테이블을 Outboard 또는 Outrigger 라고도 합니다.

Star스키마와 Snowflake는 각각 장단점을 가지고 있으므로실제 프로젝트에서는 획일적으로 설계하지 않고 복합적으로 설계합니다이러한 스키마 구조를 복합스키마 라고 합니다.

 04.png


 

데이터의 무결성(Integrity)을 유지하고 데이터의 중복 성을 줄이기 위한 정규화와 성능향상을 위한 비정규화가 일정한 수준에서 조합된 형태를 취하게 됩니다여기서 두 가지를 항상 염두 해야 합니다첫 번째는 집계 상세수준을 고려해서 정의하는 것과 두 번째는 사용자 질의 유형과 질의 응답성능을 고려하여 적절한 수준에서 테이블을 비정규화 필요성 여부를 고려하는 것입니다.

알맞은 설계 방법을 선택하기 위하여 Fact테이블을 설계하기 전에 데이터의 차원 별 분포도를 먼저 파악하기도 합니다

그 외에 여러 개의 Star스키마의 집합관계를 가지고 있는 Constellation(별자리)스키마도 있습니다각기 다른 Fact테이블들이 동일한 Dimension테이블과 조인되는 구조입니다대게 Star스키마로만 이루어진 DM에서 나타납니다.

05.png


 

이렇게 다양한 스키마 구조들에 대해서 알아 보았습니다다시 한번 말씀 드리면한 스키마 구조에만 얽매이지 않고 데이터 양과 활용되는 관점에서 다양하고 자유로운 설계가 전체적인 BI프로젝트를 건강하게 합니다.

위에서 자주 언급된 Fact테이블에 대해서 구체적으로 함 알아 볼까요? Fact테이블은 정규화된 테이블로써 스키마에 중심에 위치하며 설계 시 가장 큰 테이블입니다수억 개의 행을 가질 수도 있을 정도로 엄청 큰 Big 테이블 입니다.

 06.png


 

생성시 유의해야 할 점은 중복되는 데이터가 없어야 하며너무 큰 테이블의 경우에는 수직수평분할 고려해야 합니다또한 SQL 2005부터 지원하는 데이터 압축파티션 등을 적용하여 구성해야 합니다그리고 Fact테이블은 아래와 같은 특징을 가지고 있습니다.

l Dimension테이블과 연관된 키 구조를 가짐

l Dimension테이블과의 연관된 키 구조를 제외하고 숫자 형태의 포맷으로 주로 구성 (측정값)

l 측정값이 없는 Fact테이블은 Fact less Fact Tale(사실 없는 사실테이블)이라 하며카운트가능

 07.png


 

그러면 측정값 집계 시 유형에는 3가지가 있다고 했습니다가산비가산반가산입니다각 집계유형에 따른 타입은 해당표를 참고 하시면 됩니다.

Aggregation

Type

Sum

Additive

Count, Min, Max

Semiadditive

FirstChild, LastChild

Semiadditive

AverageOfChildren

Semiadditive

FirstNonEmpty, LastNonEmpty

Semiadditive

ByAccount

Semiadditive

DistinctCount, None

Nonadditive

Fact테이블을 구성하면서 가장 많이 고민하는 문제는 Dimension테이블과 조인되기 때문에 인덱스 설계와참조 무결 성을 유지하기 위해서 ETL시 유의해야 하는 점입니다그리고 일반적으로 SUM할 수 있는 숫자 포멧의 값을 측정값이라고 합니다이러한 측정값은 가급적 가산형태로만 하는 것이 좋습니다반가산비가산 등의 측정값은 사용자에게 혼란 등을 야기할 수 있으며 데이터의 왜곡을 초래할 수도 있습니다또한 가급적 산신을 넣지 않습니다산식이 변경될 경우 재계산해서 UPDATE가 발생할 수 있는데이때UPDATE는 대용량에서는 바람직하지 않습니다그러면 UPDATE가 필요한 경우에는 병렬로 처리하는 CTAS가 오히려 유리할 수 있습니다

Fact테이블의 왜곡되는 현상을 아래 그림으로 살펴보면

 08.png


 

인당 매출액을 평균값으로 Fact테이블에 적재할 경우, Type A: Sum(매출액)/Sum(고객수) = 인당평균매출액으로 구할 수 있지만, Type B: Sum(Avg(매출액)) / Count 로는 왜곡된 데이터가 나올 수 있으므로 유의해야 합니다.

많은 분들이 Fact테이블 구성 시 의문을 가지고 계시는 것이 바로 Dimension테이블과 FK를 만들어야 하는 가입니다. FK는 데이터의 정합성을 유지하는 Constraint로서 중요 합니다하지만 Fact테이블 적재하는 경우에 FK로 인하여 적재시간이 지연될 수 있는데, FK를 생략해서 나중에 테이블간의 정합성 체크를 하는 비용을 생각한다면 사전에 하는 것이 더 바람직해 보입니다.

일반적인 OLTP 모델링에서도 논리 명을 설계할 때 마찬가지 이겠지만, BI에서는 의사소통을 위해 더욱 강조 되는 부분이 명확한 명명 법 입니다예를 들면 ’, ‘금액’ 등의 명명보다는 가급적 ‘매출액’, ‘판매액’ 등의 자세한 명명을 사용하여전사적으로 이해하는 용어를 사용하여 혼란을 야기 하지 않도록 합니다예를 들어 매출액 = 판매액 – 반품액매출액 = 판매액 등 ‘매출액에 대한 이해가 부서마다 용어에 대한 이해가 다르다면 전사적으로 용어를 통일 시켜야 합니다

Fact테이블의 Row수는 차원의 상세수준에 따라 결정되는데이에 대해서 알아보겠습니다예를 들어 매장차원(20개 매장)과 상품차원(10개 상품)만으로 구성이 되어 있을 때, Fact테이블의 Row수는 20 X 10 가지의 경우의 수를 쉽게 예상할 수 있습니다또한 Dimension테이블의 수는 동일하나 상세수준으로 조절이 가능한데그림으로 표현하면 다음과 같습니다.

 09.png


 

일반적으로 Dimension테이블의 수가 적을 수록 상세수준이 낮으며연관된 Dimension테이블들의 키(FK)의 경우의 수라고 보면 됩니다필요하다면 상세수준을 낮춰서 성능의 향상을 높일 수 있으며다양한 분석을 원한다면 높이는 것도 하나의 방법입니다이를 활용하여 실무자에게는 주문번호 별 매출 데이터를 보이고, CEO에게는 날짜 차원 별 데이터를 보여서 각각 리포트에서 성능을 조절하는 것입니다그러나 상세수준이 높은 Fact 테이블에서 상세수준이 낮은 Fact 테이블을 생성할 수 있으나반대로 상세수준이 낮은 Fact 테이블에서 상세수준이 높은 Fact테이블을 생성할 수 없으니 처음에 만들 테이블의 상세수준을 합리적으로 결정해야 합니다.

OLTP에서는 판매가 이루어질 때만 저장하므로, 10개의 매장에서 서로 다른 제품을 각각 1개씩팔았다면 10 Row가 되지만 다차원 모델에서는 10개 매장 * 10개 상품으로 Fact가 구성되므로 100 Row가 만들어 집니다이처럼 오히려 Fact테이블의Row수가 더 많게 되는데집계의 상세수준이 차원에 따라 달라진다는 점을 명심해서 집계의 효율성(성능)과 분석의 다양성 이라는 두 마리 토끼를 다 잡을 수 있게 고민의 고민을 거듭하게 됩니다

BI 프로젝트가 거의 마무리가 될 지점에서 테이블의 정보를 취합해 보면비슷한 Fact테이블들이 많이 존재하게 되는데이때 동일 상세수준과 동일Dimension테이블을 가진 Fact테이블간에 병합이 가능합니다이렇게 병합하게 되면 ETL 시간도 줄어 들고저장 공간도 절약되니 일석이조의 효과를 볼 수 있습니다단 업무적으로 상이한 Fact테이블 이라면분리되어 각각 존재하는 것이 향후 변경 Point가 적어 지므로 더 낳을 수 있습니다.


출처 - http://www.sqler.com/499404#0

'DB' 카테고리의 다른 글

트랜잭션(Transaction)과 2PC(two-phase commit)  (0) 2016.12.20
OLTP / OLAP  (1) 2016.11.05
DW, DM, OLAP의 이해  (2) 2016.11.05
mssql 천단위 콤마 처리  (0) 2013.01.08
MSSQL 날짜관련 함수  (0) 2012.12.11
:

DW, DM, OLAP의 이해

DB 2016. 11. 5. 17:04

이번 시간에서는 BI를 구축하기 위해서는 알아야 할 몇 가지 개념에 대해서 알아 보겠습니다.

아래 그림만 잘 이해할 수 있다면쉽게 이해가 되실 것 입니다.

01.png


 

공장에서 생산한 물건은 도매시장으로 넘어 오게 됩니다도매시장에서 다시 소매시장인 슈퍼마켓 등에서 물건을 구입하여 가정으로 오게 됩니다여러분들도 아시는 이러한 전통적인 프로세스는 물건이 공장에서 집으로까지 오는 일반적인 과정입니다.이러한 일련의 프로세스를 그대로 물건이 아니라 데이터에 비유하면 됩니다.

02.png

 


 

먼저정보를 생성하는 공장의 역할은 OLTP(On-Line Transaction Processing) 입니다기업 운영에 필요한 비즈니스 프로세스를 자동화한 시스템으로 인사급여구매생산재고물류 등 기업 운영의 전반적인 측면을 포함하고 있습니다. OLTP 시스템은 정보를 트랜잭션단위로 수집하고 분류저장유지보수갱신검색하는 기능을 빈번히 일어나는 수행 하는 시스템들입니다.

생산한 물건을 도매시장으로 모두 옮겼듯이, OLTP에서 발생한 데이터들을 모두 DW(Data Warehouse)라는 곳에 저장 합니다.사용자의 의사결정을 지원하기 위해 기업이 축적한 많은 데이터를 사용자 관점에서 주제별로 통합하여 아래와 같이 별도의 장소에 저장해 놓은 데이터베이스 입니다.

 

 

DW는 데이터 창고와 같은 개념이므로 몇 가지 특성이 있습니다

· 정보데이터를 위한 중립적인 저장영역

· 의사결정을 지원하기 위한 정제된 데이터

· 데이터의 단일공급원

· 데이터에 기반한 의사결정의 효율성향상

03.png

 


 

 

DW는 과거에서는 구축실패가 많았다고 합니다. Enterprise Data Warehouse(EDW)라고 하여 전사적으로 빅뱅방식으로 한번에 모두 구축하려다 보니노하우부족과 성숙되지 않은 설계가 주된 이유였습니다현재는 모델링부터 데이터이관을 위한 시스템까지 체계적으로 되어 있어 과거와는 달리 많은 기업들이 DW를 구축하고 있으며 다음과 같은 장점을 얻게 됩니다.

 

 

· OLTP(운영시스템)을 보호하고 사용자 질의에 신속한 응답성능을 제공할 수 있다.

· 여러 시스템에 산재된 데이터들이 DW로 취합되고 통합되므로 사용자는 자신들이 필요로 하는 데이터를 쉽게 가져다 쓸 수 있다.

· 데이터는 DW로 옮겨오기 전에 정제 및 검증과정을 거치게 되며따라서 사용자는 양질의 데이터를 사용할 수 있다

 

 

소매업인 DM(Data Mart)는 이해관계가 동일한 사용자 집단의 특화된 사용자 중심의 데이터장고로서동질적인 사용자 집단에게 유사한 비즈니스 모델과 비즈니스 언어를 제공함으로써 데이터에 대한 가 독성을 높이는데 초점을 맞춰져 있습니다이러한DM에는 다음과 같은 특징을 가지고 있습니다.

l 부서나 사용자집단의 필요에 맞게 자유롭게 가공

l 각 부서는 다른 부서에 영향을 주지 않고 필요한 시점에서 원하는 어떠한 프로세스도 가능

l DM에 없는 데이터를 필요로 할 경우 DW에 드릴스루(Drill-Through)할 수 있는 환경도 고려

04.png

 

 


 

 

그러면 DW와는 무슨 차이가 있는 것일까요? DW는 최종사용자와의 인터페이스보다는 방대한 분량의 데이터를 효율적으로 통합하고 관리하는 측면에 보다 초점을 맞춘다따라서 사용자 측면에서 편리한 형태로 설계되지 않을 수 있습니다그리고 전사적인 용도로 구축되기 때문에 각 개별부서나 사용자 집단에 적합한 형태로 데이터가 저장되지 않는다따라서 사용자 질의에 최적의 성능을 제공하지 못할 수도 있습니다대부분의 사용자들은 DW의 전체 데이터 중 일부분만을 주로 사용할 것이며기업의 모든 사용자들이 DW에 대해 직접 질의를 수행하는 것은 많은 시스템 자원을 필요로 하며 시스템 성능에 심각한 부하를 줄 수 있기 때문에 분산된 DB영역에서 구축 하는 것이 바람직합니다.

 

 

OLAP에 대해서 한번 알아 볼까요?

RDB OLAP의 창시자인 E.F CODD 박사가 10년전 돌아 가셨는데대용량에서 다양한 쿼리 후 결과를 얻는 것에 대해서 RDB의 한계를 느끼고 20여년전에 12개의 제언을 하였습니다이후 이러한 사상을 바탕으로 OLAP제품이 만들어지고 COGNOS, MSTR, BO, SQL SSAS등이 각축을 벌이고 있으며지금은 사상이나 처리방법에 대해서 OLAP에 대한 방향이 어느 정도 자리가 잡혀있는 상황입니다.

 

 

OLAP(On-Line Analytical Processing) OLTP에 상대되는 개념으로써최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정입니다.

05.png

 


 

 

오른쪽과 같은 내용의 질의를 OLTP에서 쿼리로 만든다면 시간도 오래 걸리고빠른 결과를 낼 수가 없으며결정적으로 2년치의 판매테이블을 모두 읽어서 결과를 보기 위해서는 OLTP시스템에 영향을 줄 수 밖에 없을 것입니다그렇다고 OLTP에서 모든 것을 예측해서 리포트를 만들거나 할 수 없으므로업무 담당자가 원하는 관점에 따라 자유자재로 만들기가 어렵습니다또한 별도의 집계테이블을 가지고 있지 않는 이상 10초 안에 답을 구하기란 어려운 일입니다. 10초의 기준은 아래 같습니다.

 

 

0.1

시스템이 즉시반응 한다고 느끼는 한계

1

사용자가 지연은 느끼나사고의 흐름이 중단되지 않는 단계,

2

응답속도 지연에 대한 불만을 느끼지 않는 한계

3

응답속도 기준의 품질 기준

10

사용자가 현재의 작업에 주의를 집중할 수 있는 한계

(지연이 10초이상 될 경우 사용자는 다른 일을 하고 싶어함)

 

 

사고의 흐름이 끊기지 않고 계속 분석하여 원하는 답을 얻어내는 것이 중요 합니다그리고 여기서 사용자는 매출액을 기간매장제품실적이라는 네 가지 각도에서 분석하였는데그림으로 표현하면 다음과 같습니다.

 06.png

 


 

이러한 다양한 차원으로분석 목적에 적합하게 사용자의 관점에서 설정하게 되는데 이를 다차원분석이라고 합니다.

OLAP의 목표는 다음과 같습니다.

 

l 직접접근

전산 부서와 같은 정보 매개자를 거치지 않고 원하는 정보에 직접 접근하는 것입니다.

 

 07.png


 

직접접근의 필요성은 전산부서에 요청 후 리포트를 얻기까지의 시간이 걸리며정형화된 양식이나 정보를 가공하려면 다시 의뢰해야 하는 번거로움이 발생할 수 있습니다의사결정에 활용하기 위해서는 사용자가 쉽게 이해할 수 있고조조작하기 쉬운 형태로 존재 사용자의 관점으로 보여줘야 학 때문입니다그러므로 사용자가 필요한 시점에 정보 매개자의 도움 없이 정보원에 직접 접근하여 다양한 각도에서 분석을 수행 할 수 있어야 합니다.

 

 

l 대화식 분석
하나의 질문에 대한 답은 또 다른 질문을 이끌어 냄으로써 사고의 흐름이 중간에 끊어지지 않도록 사용자 질의에 신속한 답을 제공해야 합니다

 08.png


 

 

 

l 의사결정에 활용
기존 OLTP는 실제로 발생하고 기록되는 시스템으로 무엇(What)초점이 맞춰져 있는 반면, OLAP은 다차원 정보분석을 하여 왜(Why)라는 의사결정 활용 과점으로 시스템이 구축되어야 합니다.

BI프로젝트를 진행하다 보면일단 데이터를 모두 수집해와야 하고 모든 OLTP비즈니스를 담으려고 하는 강박관념에 빠지게 되면 자칫 프로젝트를 실패하게 됩니다항상 의사결정에 활용할 수 있는 것에 초점을 맞춰야 합니다리포트가 아무리 많아도 소용없으며단 하나의 리포트가 회사의 중요한 의사결정에 활용된다면, 100개의 리포트보다도 더 중요 합니다.

 

 

OLTP에서DW, DM, OLAP에 이르기까지의 과정에서 중간 중간에서 데이터를 이관하는 과정을 ETL이라고 합니다. E(Extraction – 추출), T(Transformation – 변형), L(Load – 적재) 3가지 과정을 거치게 됩니다.ETL은 또는 ETT라고 합니다마지막에 T는 Transportation(수송) 입니다.

 09.png


 

다음 그림과 같이 도식화할 수 있습니다중간에 변형작업에서 주로 하는 일은 바로 정제 입니다. OLTP에서 발생한 데이터를 그대로 이관하여 DW, DM을 만들게 될 때 가장 먼저 부딪히는 벽이 바로 데이터의 정합성 문제 입니다이를 해결하기 위해서 DQ(Data Quality)를 하게 되는데 다음에 알아 보도록 하겠습니다.

 

OLTP에서 DW로 바로 데이터를 넣기 전에 임시 영역이 있습니다이를 영어로 Staging 영역이라고 하며데이터베이스나 파일 시스템 기반의 물리적 저장소로서 각 영역 간의 데이터 이전/통합/가공을 원활히 하고 안정적으로 수행하기 위해 임시적으로 사용하는 영역이라고 할 수 있습니다.

 

DW에서 ODS(Operational data store)라고 하는 운영 데이터 영역은 분리된 각각의 원천 시스템으로부터 운영 데이터를 통합한 저장소를 말합니다. ODS에는 트랜잭션 레벨의 상세한 데이터가 전사적인 데이터 수요를 만족하는 일반적이고 통합된 데이터를 저장하고 있어 전사적인 정보가 트랜잭션 레벨의 상세한 형태로 중복이 제거되어 통합 저장되기 때문에운영 리포트를 제공할 수 있는 소스가 될 뿐 아니라 하나의 업무가 아닌 여러 업무에 걸친 현재 시점의 데이터를 통한 리포트 제공에도 활용됩니다이 영역은 때로는 고객이나 상품과 같은 핵심 주제 영역의 데이터 추출 용도의 마스터 데이터 관리 허브로 사용되기도 합니다.

 

이렇게 용어에 대해서 알아보았습니다. OLTP에서ODS, DW, DM, OLAP까지 한번에 오류 없이 데이터를 전송하기란 쉬운 일은 아닙니다. OLTP를 위한 시스템의 개발과는 달리 BI의 구축은 특히Data 에 관한 구체적인 지식이 요구되므로 데이터를 찾고품질을 높이고 데이터를 정련하는데 많은 시간이 소요됩니다. OLTP운영에서는 이상이 없지만, BI구축의 데이터 정합성 문제는 가장 큰 이슈입니다또 BI 개발이 끝났다 하더라도 OLTP에서 DB정보를 변경하는 일(컬럼 추가/삭제테이블 추가/삭제)은 비일비재합니다가장 안 좋은 케이스는 OLTP에서 제대로 된 ER-Diagram조차 없었을 때 입니다시스템의 분석을 위해 필요한 산출물이 없는 경우Reverse Engineering을 하기도 합니다. OLAP구축 전 단계인 DM까지 데이터를 이관하고 정합성을 체크하는데전체 개발기간의60% 이상이 할애되기도 합니다.

 

이번 시간에서는DW, DM, OLAP등 BI를 구축하기 위해서 필요한 용어 대해서 알아 보았습니다. BI를 구축하기 위해서는 많은 부서와의 협력이 필요 합니다특히 초기 구축에서는 정보부서의 도움이 필요하기 때문에기본적인 의사소통을 위해서는 정보부서를 포함하여, BI 구축과 연관된 부서에 이러한 용어 또는 개념에 대한 정보를 전달하는 것이 좋습니다.

 

출처 - http://www.sqler.com/498994

'DB' 카테고리의 다른 글

OLTP / OLAP  (1) 2016.11.05
다차원 모델링(1/2)  (0) 2016.11.05
mssql 천단위 콤마 처리  (0) 2013.01.08
MSSQL 날짜관련 함수  (0) 2012.12.11
iBATIS 강좌 <1> Complex Type Property 사용하기  (0) 2012.11.13
: