blog de bonarbo

[작성일 : 2011-12-26]

1. 서론

미들웨어는 양 쪽을 연결하여 데이터를 주고 받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어를 말한다. 즉, 서로 다른 소프트웨어, 서비스 사이에 존재하여 표준적인 방법으로 연결할 수 있는 인터페이스를 제공하고, 또 안정적으로 데이터, 정보를 전달하는 소프트웨어 라고 할 수 있다. 예를 들어서, 데이터베이스로 부터 데이터를 저장하거나 읽어올 수 있게 하는 웹브라우져가 있다면, 이 때  데이터베이스와 웹서버를 연결시키는 미들웨어가 존재할 수 있다. 대표적인 미들웨어 분야로는 ODBC와 같은 DB 미들웨어, 코바ORB와 같은 객체 미들웨어, 트랜잭션을 위한 턱시도·티맥스 등의 TP모니터, 비동기 방식을 지원하는 메시징 미들웨어, 웹 애플리케이션 서버 등의 웹 미들웨어가 있다.

미들웨어가 갖는 공통적인 특징, 또는 미들웨어의 기준은 다음과 같다.

2. 미들웨어의 기준 : 배관 설비와의 비교

1) 대부분 눈에 보이지 않음

부엌과 욕실 등에서 사용하는 물은 집안의 배관을 통해서 전달되지만, 정작 배관은 눈에 보이지 않는 곳에 있다. 이와 마찬가지로 미들웨어를 통해 전달되는 정보는 웹사이트를 통해 눈으로 되지만, 미들웨어의 존재는 사용자가 눈으로 확인할 수 없다. 소프트웨어를 사용하는 경우, 논리적 뷰의 상단에 전자 상거래 웹 에플리케이션과 같은 소프트웨어 패키지가 있고, 하단에는 데이터베이스 및 운영체제와 같은 소프트웨어 패키지가 있다는 것은 분명하게 인식할 수 있다. 하지만 그 중간 부분, 즉 모든 것을 함께 연결하는 배관에 해당하는 미들웨어의 존재는 구체적으로 식별하기 어려울 수 있다. 

2) 표준 업무 방식 제공

집을 지을 때, 배관 설비를 처음부터 만들기 원한다면 물론 가능하다. 하지만 배관 설비를 구입하는 것이 훨씬 간편하다. 소프트웨어 개발자도 에플리케이션 서버, 데이터베이스 연결 드라이버, 인증 처리기, 메시징 서비스 등을 모두 처음부터, 자체적으로 개발할 수 있다. 하지만 이미 확립된 표준에 따라 개발된 "미들웨어 구성 요소"를 사용하는 것이 휠씬 간편하다. 미들웨어에서 이러한 표준은 잘 정의된 API ( Application Programming Interface ) 라는 형식으로 표현된다.

3) 복잡한 시스템의 구성 요소를 연결 해 줌

집안에는 주방, 난방 시스템, 욕실, 세탁기, 정원 등 여러 수도 시설이 있는데, 안정적인 배관 설비 덕분에 우리는 수도 공급에 차질이 생기지 않을까 걱정할 필요가 거의 없다. 미들웨어 역시 복잡한 시스템, 애플리케이션 및 데이터베이스를 안정적으로 연결하여, 정보를 계속 이동 시킨다. 배관과 미들웨어의 또 다른 유사점은 처음부터 모든 것을 재구성할 필요 없이, 다른 사람이 다른 시점에 구축한 시스템들을 연결할 수 있다는 것이다. 예를 들어, 구형 세탁기를 20년 만에 스팀 드럼 세탁기로 교체했다고 해서, 부엌와 욕실의 배관을 다시 교체 해야 할 필요는 없다. 미들웨어의 가장 강력한 접근법 중의 하나인 ESB(Enterprise System Bus)에 기반한 SOA(Service-Oriented Architecture)는 하드웨어 버스와 같은 기능을 하는 서버, 메시징 및 API 를 제공한다. 각기 다른 시점에, 다른 조직에 의해 개발되고, 다른 프로토콜을 통해 통신하는 엔터프라이즈 소프트웨어 애플리케이션을 통합 할 때, ESB는 프로토콜 간에 메시지를 전환하고, 해당 메시지를 올바른 서비스에 전달하는 역할을 하기 때문에, 통합을 위해서 하나의 일관된 언어를 사용하도록 애플리케이션을 재 작성 할 필요가 없다.

4) 사소한 고민 거리를 피할 수 있음

미들웨어가 이처럼 눈에 보이지 않는 모든 기능을 관리해 주기 때문에, 소프트웨어 개발자는 소프트웨어 개발에 집중하여 비지니스 문제점을 해결하고, 고객의 요구를 충족 시킬 수 있다.

3. 미들웨어의 종류

미들웨어는 이 기종 소프트웨어 또는 서비스 사이에 존재하는 소프트웨어를 가리키는 범용적인 정의 이다. 그래서 미들웨어는 웹서버와 데이터베이스 사이에 존재하는 시스템일 수도 있고, 핸드폰 이나, RFID 단말기 에 존재하는 모듈일 수도 있다. 미들웨어를 범주로 나누어 살펴보면 다음과 같다.

1) 데이터베이스 기반 미들웨어

데이터베이스 벤더에서 제공하는 소프트웨어로서 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어이다. 이 소프트웨어을 사용하여 시스템을 구축하는 경우에 보통 2-티어 아키텍쳐라고 한다. (예, 오라클의 Sql*Net, IBM 인포믹스의 I*Net, ODBC 드라이버 등)

2) RPC(Remote Procedure Call) 기반 미들웨어

한 응용 프로그램의 프로시저를 사용하여 원격 응용 프로그램의 프로시저를 로컬 호출처럼 호출할 수 있게 해 주는 소프트웨어이다. 일반적으로 이 유형의 미들웨어는 프로시저 기반 프로그램을 처리했지만, 지금은 객체 기반 구성 요소도 포함한다. (예, DCE RPC, 엔테라 등)

3) MOM(Message Oriented Middleware) 기반 미들웨어

주로 비동기형 메시지 처리를 전달하는 방식의 미들웨어이다. 온라인 업무에 사용되기 보다는 이 기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용되고 있다. (예, IBM MQ시리즈, BEA Message Q, J2EE의 JMS 기반 제품 등)

4) TP-모니터 기반 미들웨어

온-라인 트랜잭션 업무(은행 계정, 항공기/버스 예약 업무 등)에서 트랜잭션을 처리, 감시하는 미들웨어이다. 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 OLTP 성의 업무에 적합하다. (예, BEA TUXEDO, BEA TOPEND, IBM TxSeries, 티맥스소프트 Tmax, 대만 CS Talk 등)

5) ORB(Object Request Broker) 기반 미들웨어

객체 지향 미들웨어로서, 특히 코바(CORBA) 표준 스펙을 구현한 미들웨어를 말한다. (예, IONA Orbix, Borland VisiBroker, BEA TUXEDO 8.0 이상 CORBA 엔진 등)

6) WAS(Web Application Server) 기반 미들웨어

클라이언트/서버 환경 보다는 웹 환경을 구현하기 위한 미들웨어이다. Web Application Server는 HTTP 세션 처리를 위한 웹서버 기능 뿐만 아니라, TP 기능을 보강하여, 미션-크리티컬한 기업 업무까지 자바, EJB 컴포넌트 기반으로 구현 가능하게 해주는 미들웨어이다. (예, BEA WebLogic, IBM WebSphere, Oracle 9iAS, SUN iPlanet 등)

4. 결론

미들웨어는 “이 기종 소프트웨어 또는 서비스 사이에 존재하면서 표준적인 방법으로 연결할 수 있는 인터페이스를 제공하여 안정적으로 데이터, 정보를 전달하는 소프트웨어” 라고 정의 할 수 있다. 데이터베이스 종류에 관계없이 표준적인 DB 접근 방법은 제공하는 ODBC 도 이 정의를 만족하기 때문에 미들웨어라고 할 수 있다. 일반적으로 기업에 있어서 상용 미들웨어 제품을 말할 때는 “독립적으로 개발되어 서로 다른 네트워크 플랫폼에서 실행되는 소프트웨어 구성 요소 간의 상호 작용을 가능하게 해 주는 소프트웨어" 라고 정의 하기도 한다. 상용 미들웨어는 일반적으로 RPC(Remote Procedure Call) 기반, MOM(Message Oriented Middleware) 기반, TP-모니터 기반, ORB(Object Request Broker) 기반, WAS(Web Application Server) 기반 으로 분류 한다.

--------------------

참고 자료: 

www.kr.redhat.com/pdf/articles/what-is-middleware.pdf

http://ko.wikipedia.org/wiki/미들웨어

http://legendfinger.com/64

http://oneshot-textcube.blogspot.com/2010/01/tuxedo-미들웨어-개념-및-종류.html

http://docs.oracle.com/cd/E19148-01/820-0532/aeraq/index.html

http://technet.tmax.co.kr/kr/edocs/tmax/50/getting-started/index.html

<끝>

[작성일 : 2011-12-17] 

1. DW/OLAP 의 정의

DW (데이터 웨어하우스, Data Warehouse) 는 사용자의 의사 결정에 도움을 주기 위하여, 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다. 웨어하우스(warehouse)는 창고라는 의미인데 데이터의 수용이나 분석 방법까지 포함하여 조직 내 의사 결정을 지원하는 정보 관리 시스템으로 이용된다. DW는 원시 데이터 계층, 데이터 웨어하우스 계층, 클라이언트 계층으로 구성되며, 고객의 구매 동향, 신제품에 대한 반응도, 제품별 수익률 등 세밀한 마케팅 정보를 얻는 것을 목표로 한다.

OLAP (온라인 분석 처리, Online Analytical Processing) 은 의사결정 지원 시스템 가운데 대표적인 예로, 사용자가 동일한 데이터를 여러 기준을 이용하는 다양한 방식으로 바라보면서 다차원 데이터 분석을 할 수 있도록 도와준다. OLAP 기술의 발전을 계기로 적극적인 데이터의 활용을 통한 의사결정의 중요성이 더욱 강조되었다. OLAP 의 특징은 "다차원 정보 제공", "중간 매개자 없이 사용자가 직접 데이터 접근, 대화형태 정보 분석", "의사 결정지원" 으로 정리할 수 있다. OLAP 은 DW에 체계적으로 쌓여 있는 데이터 속에 담겨 있는 정보를 효율적으로 끌어내어 분석할 때 효율적이지만, 반드시 DW 가 구축되어 있어야 OLAP 시스템을 구출할 수 있는 것은 아니다.

참고로, OLTP (온라인 거래처리, OnLine Transaction Processing)는 여러 과정이 하나의 단위 프로세스로 실행되도록 하는 프로세스를 만한다. OLTP 시스템은 원시 데이터가 실제로 무엇이 발생하고, 기록되는지에 초점이 맞추어져 있다, 예를 들어 현재의 거래 상태를 정확하게 기록하여 갱신할 수 있는 은행의 창구업무, 항공사의 예약업무 시스템이 여기에 해당된다. 이에 비해서 OLAP 시스템은 데이터를 의사 결정에 활용할 수 있도록 하는 방법에 초점이 맞추어져 있다.

2. DW/OLAP 의 필요성

데이터의 생산과 소비라는 측면에서 보았을 때, 생산의 입장에서는 빠른 트랜잭션 처리 (추가, 수정, 삭제, 조회) 가 요구된다. 따라서, 최초로 생산된 데이터를 "원시 데이터" 라고 한다면, 원시 데이터는 데이터 내용이 상세하고, 최대한 중복 되지 않는 것이 중요하다. 그리고 단위 데이터가 소량이다. 이에 비해서, 소비의 입장에서는 다양한 관점에서의 분석, 통계, 요약정보, 보고서의 빠른 처리가 요구된다. 그래서 원시 데이터보다 분석된 정보가 중요하고, 데이터의 중복이 허용 되기도 한다. 이 처럼, 소비의 입장에서는 단위 데이터가 대량이고, 데이터를 바라보는 관점이 다양하기 때문에, 원시 데이터에서 직접 이러한 처리를 빠르게 처리하기에도 어렵고, 운영 데이터베이스에 과도한 부하를 발생시킬 수도 이는 문제가 발생한다. 이러한 문제점을 해결하기 위해서, 이루어진 많은 연구중에서 1993년 E.F.Codd 에 의해서 처음 사용된 개념이  바로 OLAP 이다.

데이터 분석 시간을 단축시키기 위해서 많은 기술들이 개발되었지만, 아직 완벽한 해결책을 내놓은 곳은 없다. 사용자들이 요구한 모든 데이터를 미리 구해 놓으면 반응 속도는 빠르지만, 데이터베이스가 폭발적으로 커졌고, 이를 피하기 위해서 실시간으로 계산하여 결과를 보여주면 응답 속도가 너무 느렸다. 그래서 많은 경우 이 두 가지를 적절하게 조화 시키는 방법을 추구하고 있다.

3. FASMI

보통 OLAP 이라는 개념의 기준을 FASMI 로 삼아서, 설명하고, 테스트 한다. FASMI (Fast Analysis of Shared Multidimensional Information)는 다음과 같다.

1) FAST

일반적으로 사용자의 쿼리에 대한 반응 속도가 5초 이내인 것을 의미한다. 간단한 분석의 경우 1초 이내이고, 아주 드물게 20초 이상 걸릴 수도 있다. 실제로 분석가들은 30초 이상 반응이 없으면 대개 강제로 종료시킨다고 한다.

2) ANALYSIS

시스템이 사용자에게 임의의 비지니스 로직과 통계적 분석 기능을 쉽게 제공해야 함을 의미한다. 즉, 별도의 프로그래밍이 없이도 원하는 형태로 보고서를 만들어 낼 수 있어야 한다.

3) SHARED

동일한 데이터를 다중의 사용자가 동시에 공유하며 분석할 수 있어야 한다. 이때 읽기 및 쓰기 작업이 적시에 안전하게 이루어 질 수 있도록, 데이터에 대한 적절한 레벨에서의 잠금기능를 지원해야 하는데, 이 부분은 많은 OLAP 제품들이 갖는 취약한 부분으로서, 실제로 읽기 전용만 지원하는 제품들이 많다.

4) MULTIDIMENSIONAL

OLAP 의 가장 중요한 개념으로써, 다양한 관점에서 데이터를 분석할 수 있는 다차원 뷰를 제공해야 한다는 것이다. 다차원 뷰는 구체적으로는 계층 구조와 다중 계층 구조를 표현해야 한다.

5) INFORMATION

원시 데이터와 필요에 의해 파생된 모든 정보를 말한다. 제품의 용량을 평가할 때, 얼마나 많은 입력 데이터를 처리할 수 있는지, 얼마나 많은 바이트의 데이터를 저장할 수 있는 지 등을 고려한다. 이외에도 데이터 중복, 필요한 RAM, 디스크 저장 공간, 성능, DW와의 통합성 등도 이 항목의 고려 대상이다.

4. OLAP 모델

1) MOLAP (Multidimensional OLAP)

MOLAP 은 OLAP 의 전통적인 모델로서, 다차원 데이터의 저장과 처리에 MDBMS (다차원 데이터 베이스) 가 사용된다. MDBMS 는 다차원 배열 형태의 데이터 구조를 사용하기 때문에 사용자 질의에 대해 빠른 응답 성능을 제공하는 장점이 있지만, 반면에, RDBMS (관계형 데이터 베이스) 에 비해 데이터 용량이나 에러 회복 능력, 하드웨어 활용등의 측면에서 상대적으로 다소 떨어진다.

대표적인 제품으로는 에이베이스 (하이페리언 솔루션 사), 익스프레스 (오라클 사), 디시전 서포트 (파일롯 소프트웨어) 등이 있다.

2) ROLAP (Relational OLAP)

ROLAP 은 다차원 데이터를 RDBMS 에 저장하며, 이때 "스타 스키마"가 많이 사용된다. 질의 응답 성능을 향상 시키기 위해서 상세 데이터를 가진 테이블과 함께 집계 테이블로 구성하기도 한다. ROLAP는 방대한 데이터를 대상으로 다차원 분석을 할 수 있지만 대부분의 RDBMS와 SQL 언어가 아직 OLAP 에 최적화 되지 않았기 때문에, 그 응답성능이 제한적이다. ROLAP 제품들은 사용자와 RDBMS 사이에 위치하여, 사용자를 대신해서 복잡한 SQL 을 생성하고, 다차원 연산을 수행한다. 따라서 ROLAP 제품들은 RDBMS 와 ROLAP 엔진과 ROLAP 클라이언트로 구성된다.

대표적인 제품으로는 메타큐브 (인포믹스 사), 디시전 쉬이트 (인포메이션 어드벤티지 사), DDS 에이젼트 (마이크로스트래티지 사) 가 있다.

3) DOLAP (Desktop OLAP)

DOLAP 은 다차원 데이터의 저장 및 프로세싱이 모두 클라이언트에서 이루어 진다. 분석에 필요한 데이터는 데이터베이스에서 추출되어 클라이언트에 특수한 파일 형태로 저장되며, 제한된 기능의 다차원 분석을 수행한다. 비교적 설치와 관리가 용이하며, 유지보수의 부담이 적고, 또 적은 비용으로 OLAP 시스템을 구축할 수 있는 장점이 있다. 하지만 필요한 데이터가 모두 클라이언트로 이동될 필요가 있으며, 대용량의 데이터를 처리하는데 한계가 있다. 또 각각의 사용자 PC에 저장된 데이터의 일관성을 유지하는 것이 큰 문제가 되기도 한다.

대표적인 제품으로는 파워클레이 (코그노스 사), 브리오쿼리 (브리오 테트놀러지 사) 등이 있다.

4) HOLAP (Hybrid OLAP)

HOLAP 은 다차원 데이터의 저장 공간으로 MDBMS와 RDBMS 가 함께 사용될 수 있는 제품이다. 일반적으로 요약된 데이터나 관계식에 의해 새로 계산된 데이터는 MDBMS 에 저장되며, 상세 데이터는 RDBMS 에 저장된다. 빠른 응답성능을 제공하는 MOLAP의 장점과 확장성이 뛰어난 ROLAP의 장점을 결합하여 보다 나은 성능을 제공한다.

대표적인 제품으로는 익스프레스 (오라클 사), SQL 서버 OLAP (마이크로소프트 사) 등이 있다.

5. OLAP Cube

MDBMS 에서 다차원 데이터는 큐브(Cube)로 정의된다. 큐브의 구성 요소는 다음과 같다.

1) 모델

하나의 큐브 를  말한다.

2) 차원 (Dimension)

큐브를 구성하는 축(Axis) 이다.

3) 차원 항목 (Member 또는 Element)

각 축의 좌표에 해당한다.

4) 셀 (Cell)

각 차원을 구성하는 항목들의 조합에 의해 만들어 지는 공간을 말하며, 데이터가 제장되는 곳이다. 셀은 큐브를 구성하는 차원들이 가진 항목들의 조합수 만큼 존재한다.

5) 계층 구조 (Hierachy)

다차원 모델을 구성하는 대부분의 차원들은 일반적으로 계층구조를 갖는다. 계층 구조는 레벨들 간에 혹은, 항목들 간에 존재할 수 있다. 항목들 간의 가장 기본적인 관계는 Parent-Child 관계이다. Sibling 은 동일한 Parent를 가진 항목을 말한다. Parent 를 갖지 않는 항목을 Root 항목이고 한다. 반대로 Child 를 갖지 않는 항목을 Leaf 항목, 또는 Detail 항목 이라고 한다. 특히 계층 구조 상 루트 항목까지 연결되는 Branch 에서 그 항목의 상위에 나타나는 모든 항목을 Ancestor 라고하고, 반대로 계층 구조 상의 Leaf 항목 까지 연결되는 Branch 에서 그 항목의 하위에 나타나는 모든 항목을 Descendent 라고 한다.

6) 레벨 (Level)

Level 사이에 계층 구조가 존재할 수 있다. 일부 OLAP 제품들은 계층 구조 상의 거리를 나타내는 개념으로 Level을 사용한다. Level 은 Leaf 항목에서 시작하여 Root 항목 방향으로 항목이 속하는 계층의 위치를 계산한다. 이 때 두 항목이 임의의 Branch 에 대하여 Descendent의 최대치가 동일할 경우를 "동일한 Level 에 속한다" 라고 한다. Generation 은 Root 항목에서 시작하여 Leaf 항목 방향으로 항목이 속하는 계층의 위치를 계산한다. 계층 구조 상의 두 항목의 동일한 수의 Ancestor를 가질 경우 동일한 Generation 에 속한다고 말한다.

7) 애트리뷰트

하나의 차원에 대해 차원을 구성하는 항목들의 특성을 나타내는 이러한 정보를 Arribute 또는 Property 라고 한다.

5. 스타 스키마 (별모양 스키마, Star Schema)

RDBMS 에서 다차원 모델 을 표현할 때 많이 사용되는 스키마가 스타 스키마 (Star Schema) 이다. 스타 스키마는 정보를 사실(Fact)과 차원(Dimension)으로 분류한다. "사실"은 실제 데이터요소로 분석을 요하는 변수차원의 항목들로 구성된 정규화된 테이블을 말한다. "차원"은 "사실"을 보는 관점을 나타내며, 각각의 차원은 별도의 차원테이블에 표되고, 비정규화된 테이블로 존재한다.

6. 스노우 플레이크 스키마 (눈송이 스키마, Snowflake Schema)

RDBMS 에서 다차원 모델 을 표현할 때 많이 사용되는 다른 스키마로 스노우 플레이크(Snowflake) 스키마가 있다. 이 스키마는 스타 스키마의 사실테이블 구조와 동일하게 유지하면서 차원테이블이 정규화(일반적으로 제3정규형)된 구조를 말한다. 사실테이블과 직접 조인되는 차원테이블이 있으며, 이 차원테이블은 또 다른 차원 테이블 상의 기본키를 참조하는 외래키를 가진다. 이렇게 참조되는 테이블을 아웃트리커(Outtrigger) 테이블 혹은 아웃보드(Outboard) 테이블이라한다. 하지만 실제 현업에서는 최상의 성능을 내기 위해서 데이터의 무결성(Integrity)을 유지하고 데이터의 중복성을 줄이기 위한 정규화와 성능향상을 위한 비정규화가 일정한 수준에서 조합된 형태를 취한다.

7. 결론

DW/OLAP 은 생산된 데이터를 빠른 시간 내에 다양한 관점에서 분석 하여, 의사 결정에 도움을 주기 위한 기술이다. 특히 DW 가 이러한 목적을 달성하기 위해서, 가공된 데이터를 별도로 관리하는 데이터 베이스를 말하는데 비해서, OLAP을 DW에 체계적으로 담겨있는 데이터를 효율적으로 분석하는 기술을 말한다. 보통 OLAP은 FASMI 라고 하는 기준을 만족해야 하는데, 그 중에서도 다차원 데이터 구조 지원(MULTIDIMENSIONAL)이 그 핵심이라고 할 수 있다. 다차원 구조의 데이터를 빠른 시간 내에 분석 하기 위한 방법으로 크게 4가지 OLAP 모델이 있다. 그 중에서 대표적인 모델로 MOLAP 과 ROLAP 을 들 수 있는데, MOLAP 모델은 다차원 데이터 베이스 (MDBMS)를 사용하고, 큐브 구조로 다차원 데이터 모델을 표현한다. 응답 속도가 빠른 반면 대용량 처리가 어렵고, 기능이 부족한 단점이 있다. 반면에 ROLAP 모델은 관계형 데이터 베이스 (RDBMS) 를 사용하고, 스타 스키마 (Star Schema) 또는 스노우플레이크 스키마 (Snowflake Schema)로 다차원 데이터 모델을 표현한다. 대용량 처리가 가능하고, 상대적으로 다양한 기능을 제공하지만, 응답 속도가 느린 단점이 있다. 이처럼 각각의 장단점이 명확하지만, 현재 대부분의 DW 에서는 RDBMS 를 사용하는 ROLAP, 또는 MOLAP 와 ROLAP 의 장점을 결합한 HOLAP 모델이 대부분을 차지하고 있다.

[참고 자료]

http://ko.wikipedia.org/wiki/데이터_웨어하우스

http://ko.wikipedia.org/wiki/OLAP

http://innobizard.com.ne.kr/main/it/olap/olap.html

http://www.bi-verdict.com/fileadmin/dl_temp/877f5adf65b03215fe4a6299dcc69cf0/fasmi.htm

http://www.exforsys.com/tutorials/msas/understanding-olap-models.html

http://tire.egloos.com/10616651

http://dbrang.tistory.com/416

첨부파일 : Kishore-jaladi-DW.ppt

첨부파일 : 데이터 웨어하우징.ppt

<끝>