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 Devel 133 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 133
비트 파워프로젝트/자동차보험사의 데이터 마이닝 시스템 구축
작성자
정재익(advance)
작성일
2001-12-06 20:48
조회수
19,570

90년대가 DBMS와 데이터 웨어하우스의 시대였다면, 다가올 21세기는 데이터 마이닝의 시대가 될 것이다. 방대한 데이터를 모아주고 질서를 부여하는 것만으로는 한계가 있기 때문이다. 넘쳐흐르는 데이터 가운데서 IT는 가치있는 정보를 제시하는 툴의 역할을 해야 하는데, 이런 목적에 가장 가까이 접근한 것이 바로 데이터 마이닝이라 할 수 있다.

 

IT 분야 관계자에게 있어 정확한 정보(Infomation) 처리는 항상 고민해야하는 숙제라 할 수 있다. 하지만 필자는 새로운 밀레니엄 시대가 IT 분야에 요구하는 것은 좀더 다른 것이라고 생각한다. 과거의 정보처리가 그 정보의 질적 문제에 대해 책임이 적었던 반면, 앞으로 다가올 새시대는 단순히 정보처리 결과의 정확도뿐만 아니라 그 결과의 질적 측면에 대해서도 많은 것을 요구할 수밖에 없기 때문이다. 단순한 데이터가 아니라 진정한 가치를 갖는 정보(Intelligen ce)여야 한다는 것이다.

 

이런 점에서 90년대가 DBMS와 데이터 웨어하우스(Data warehouse)의 시대였다면, 다가올 21세기는 데이터 마이닝(Mining)의 시대가 될 것으로 확신한다. 방대한 데이터를 모아주고 질서를 부여하는 것만으로는 한계가 있다. 넘쳐 흐르는 데이터 가운데서 IT는 올바른 판단을 내릴 수 있는, 가치있는 정보를 제시하는 툴의 역할을 하지 않으면 안된다. 그리고 현재까지 이런 목적에 가장 가까이 접근한 IT 툴이 바로 데이터 마이닝인 것이다.

이번 프로젝트는 자동차 손해보험회사의 운영계 데이터베이스를 기반으로 사고와 계약에 관련된 데이터 웨어하우스를 구축하고, 유용한 지식 추출을 위한 요약과 클러스터링, 예측을 통해 고객의 유형과 사고 패턴을 조사했다. 그리고 이러한 결과를 바탕으로 보험사가 고객과 계약할 때 그 구체적인 계약 조건을 효과적으로 판단해주는 OLAP(On-Line Analyti cal Processing)과 데이터 마이닝 시스템을 구축했다.

 

복잡한 패턴의 발견과 예측에 유용한 신경망(Neural Network) 기법 가운데 다층 퍼셉트론을 백프로퍼게이션(BackPropagation) 알고리즘으로 구현했으며, 또한 연관규칙 탐사를 위해 Apriori 알고리즘을 이용했고 데이터 클러스터링에는 의사결정 트리 가운데 하나인 ID3 알고리즘을 구현했다.

최근 데이터 마이닝에 대해 관심을 갖는 사람이 많아졌지만 아직까지 국내에는 자료를 체계적으로 정리한 출판물도 없는데다 우리 현실에 적합한 사례도 불충분해서 관련 자료를 찾고 해당 업무에 적용시켜 구현하기까지 3개월이란 프로젝트 기간이 짧기만 했다. 이번 데이터 마이닝 시스템 구축기를 연재하는 것을 계기로 미숙한 부분에 대한 발전적인 평가가 이뤄지길 기대한다. 그리고 데이터 마이닝은 데이터베이스, 인공지능, 통계, 경영 등 관련 분야에서 연구가 계속 이뤄지고 있는 상황이라 공식 용어에 대한 정의가 확립되지 않아 기술하는데 다소 어려움이 있었다. 이 점은 현명한 독자들이 이해해주기 바란다.

 

21세기는 왜 데이터 마이닝을 요구하는가

기업의 경영환경 변화(시장의 변화, IMF 이후 산업 구조조정, 다양한 고객 요구 등)로 기업 경영에 있어 데이터베이스 마케팅(Database Marketing), 고객관계관리(CRM : Customer Relationship Management), 위험관리(Risk Management) 등이 부각되기 시작했다. 보다 신속하고 정확한 의사결정과 마케팅 전략수립은 이제 기업의 사활이 걸린 문제가 됐다. 이러한 변화는 많은 기업들이 현재 데이터베이스 시스템의 한계를 극복하고 데이터의 주제별 통합과 축적을 통한 다각적인 분석이 가능한 데이터 웨어하우스를 구축하거나 특정 단위의 업무에 대한 신속한 분석 작업을 위한 데이터 마트(Data Mart)를 구축하게 했으며, 이로 인해 향후 기업의 의사결정 지원을 위한 OLAP과 데이터 마이닝 시스템을 갖추는 작업이 활발해질 전망이다.

 

지난 80년대에 모든 주요 조직들은 하부구조로서 자신의 고객, 경쟁업체 및 생산제품 등에 대한 데이터를 가지는 데이터베이스를 구축했다. 이 데이터베이스는 잠재적으로 금광의 역할을 할 수 있게 됐고 데이터베이스에는 SQL이나 다른 질의 도구를 사용해서는 추적할 수 없는 많은 숨겨진 정보들이 있다. SQL은 단지 질의어의 역할만 하며, 이것은 우리가 이미 알고 있는 데이터를 특정한 조건을 사용해 찾도록 도와줄 뿐이다. 하지만 데이터 마이닝 시스템은 데이터베이스 내의 데이터를 최적으로 분류하거나 의미있는 관련성을 찾아내 예상하지 못했던, 숨겨져 있는 정보와 지식, 패턴 등을 발견한다.

 

현재 데이터베이스에서의 지식 탐사(KDD, Knowledge Discov ery in Database)라고 부르는 복잡한 과정은 매우 중요하게 간주되고 있으며, 데이터 웨어하우징이라는 또다른 중요한 개발과 밀접하게 연관돼 있다. 경영전략 수립 및 의사결정을 위한 데이터 마이닝 시스템은 운영계 데이터베이스(RDB)로부터 구축한 전사적 데이터 웨어하우스를 기반으로 하는 것이 효과적이다. 데이터 웨어하우스는 운영 데이터로부터 추출된 데이터를 중앙으로 집중해 저장한 것이다.

 

데이터 웨어하우스에 저장된 정보는 주제 중심적이고 비휘발성이며, 이력 정보를 보유하므로 데이터 웨어하우스는 매우 커다란 데이터 집합을 보유하게 된다. 최근에는 데이터 웨어하우징과 의사결정 지원 및 데이터 마이닝이 결합돼 정보관리에 대해 혁신적이고 완전히 새로운 접근방식이 제시되고 있다. 지금까지 정보 시스템은 기업체의 운영절차를 주로 지원하기 위해 구축, 운영돼 왔지만 KDD와 데이터 웨어하우징은 기업의 정보를 완전히 새로운 방식, 즉 많은 기회를 제공하는 전략의 원천으로 바라보게 하고 있다.

 

현재 많은 국내 기업들이 데이터 웨어하우스를 속속 구축하고 있음에도 불구하고 해외 선진국에 비해 국내의 데이터 마이닝 구축 실적은 매우 미미하다. 데이터 웨어하우스 활용의 적극적인 방법인 데이터 마이닝은 기업의 잘못된 경영전략으로 인한 시행착오를 사전에 방지하고, 경험에 의존한 의사결정의 한계를 넘어 보다 강력한 경영혁신 도구가 될 수 있으며, 이는 기업이 추구하는 이윤창출을 배가시키는 결정적 요인으로 작용할 것이다. 하지만 국내 기업들도 점차 데이터 마이닝에 대한 관심이 고조되고 있는 상황이라 본 프로젝트가 향후 국내 데이터 마이닝 활성화에 일조를 할 수 있을 것으로 기대해 본다.

 

데이터 마이닝의 정의

데이터 마이닝이란 ‘대량의 데이터로부터 새롭고 의미있는 정보를 추출해 의사결정에 활용하는 작업’이다. 이런 면에서 볼 때 ‘채굴하다’라는 의미의 마이닝은 매우 적절한 용어이다. 다이아몬드를 만들기 위해서는 흙과 잡석을 파헤치고 제거하듯이 데이터베이스에서도 숨겨져 있는 정보를 찾기 위해 많 은 양의 데이터 부스러기를 제거하는 작업을 해야 하기 때문이다.

 

OLAP과 같은 다차원분석(Multi-Dimensional Analysis) 도구나 질의(Query)와 이를 기반으로 하는 의사결정지원시스템(DSS ; Decision Support Systems)이나 중역정보시스템(EIS ; Executive Information Systems) 등은 미리 가설을 세우고 이를 확인하는 방식이었다. 이 방식은 가설을 세울 수 없는 상황에서는 적용할 수 없으며, 따라서 예상할 수 없는 새로운 정보가 생성되지 않는다.

 

참고로 미국의 편의점 체인에서 아기 기저귀와 맥주 판매량간의 관련성을 찾아내어 화제가 된 적이 있었다. 아기 기저귀를 사러 온 아빠들은 맥주팩 6개를 함께 사는 경향이 있다는 것이 데이터 마이닝을 통해 분석됐다. 이처럼 데이터 마이닝은 전혀 예상하지 못해 가설조차 세우기 힘든 상황에서 유용하다. 그렇다고 해서 기존 조회방식을 버리고 데이터 마이닝으로 대체할 수 있다는 말은 아니다. 데이터 마이닝은 기존의 조회 방식과 상호 보완적이어야 한다. 대부분의 기본 정보는 기존 방식을 통해서, 예전에 알지 못했던 숨겨진 정보는 데이터 마이닝을 통해 얻어내 최종적으로 의사결정을 위한 고급 정보를 얻을 수 있어야 한다.

 

다음에서 소개하는 것은 데이터 마이닝의 기법이지만 실제로 많은 양의 데이터로부터 새로운 정보를 뽑아낼 수 있는 기술이면 모두 데이터 마이닝 기법이 될 수 있다(이런 의미에서 질의 도구, 가시화 기법이나 OLAP 도구도 포함시켜야 한다는 의견도 있다). 다음은 광의로 본 데이터 마이닝 기법이다.

 

질의 도구(Query Tools)

통계적 기법(Statistical Technique)

가시화 기법(Visualization)

온라인 분석 처리(OLAP)

연관 규칙(Association Rule)

의사결정트리(Decision Tree)

신경망(Neural Networks)

유전자 알고리즘(Genetic Algorithm)

사례-기반 학습(Case-based Learning, 최단 인접 이웃(k-nearest neighbor))

 

위의 데이터 마이닝 기법 중에서 본 프로젝트에서는 연관 규칙 알고리즘, 의사결정 알고리즘, 신경망 알고리즘을 사용했다. 이번 시간에서는 세 가지의 알고리즘에 대해 간략하게 소개하고 연재를 통해 구체적인 구현 내용에 대해서 알아보겠다.

 

연관 규칙 알고리즘

먼저 알아볼 것은 연관 규칙(Association Rule) 알고리즘이다. 데이터베이스에서 알려져 있지 않는 숨겨진 패턴을 탐사하는 연구 중에서 연관 규칙에 대해 가장 많은 연구가 이뤄졌고, 이런 연관 규칙 알고리즘에 의해 새로운 패턴을 찾아내고 있다. 연관 규칙이란 말그대로 한 항목 그룹과 다른 항목 그룹 사이에 존재하는 강한 연관성을 찾아내는 마이닝 기법을 말한다. 예를 들면 앞서 잠시 언급한 미국의 편의점 체인에서 아기 기저귀를 사러 온 아빠들은 맥주팩 6개를 함께 사는 경향이 있다는 것과 같은 패턴을 찾아내는 것을 말한다.

 

이러한 연관 규칙 탐사는 발견된 연관성이 전체의 트랜잭션에서 얼마나 자주 일어나는가의 척도인 지지도(Support)와, 얼마나 그 연관성이 믿을만한가의 척도인 신뢰도(Confidence)를 지정하므로써 지식 탐사자가 명세한 정도의 항목들간의 상호 연관 규칙을 발견해 낼 수가 있다. 예를 들었던 기저귀와 맥주의 관계에서 10%의 지지도와 80%의 신뢰도를 갖는다면, 10%의 지지도는 주어진 데이터베이스의 트랜잭션들 중에서 10%가 기저귀와 맥주를 동시에 산다는 것을 의미하며, 기저귀를 사는 고객 중에서 80%는 맥주를 산다는 것을 의미하는 것으로 볼 수 있다.

 

이 지지도와 신뢰도의 개념은 연관 규칙 탐사에서 아주 중요한 개념으로 지식 탐사자가 원하는 정도의 빈발 항목 집합을 찾아내는데 있어 큰 역할을 한다. 물품구매의 한 건수를 트랜잭션으로 볼 수 있는 편의점에 대해 생각해보자. 편의점에서는 물품 구매의 트랜잭션이 매우 빈번하게 발생한다. 손님 한 명이 한 번에 구매하는 행위는 한 트랜잭션으로 볼 수 있고, 물품 내역은 한 트랜잭션 각각의 항목이 될 수 있다. 집합에서와 같이 한 트랜잭션에서 중복된 항목이 존재하지 않는다고 가정하고 그 항목들은 일정한 순서로 정렬됐다고 가정할 경우 사용자가 명시한 최소 지지도 이상을 갖는 트랜잭션들의 집합을 빈발 항목 집합이라고 한다.

 

이 빈발 항목 집합을 찾아내는 단계는 연관 규칙 탐사의 성능을 결정하는 아주 중요한 부분이 된다. 지금까지의 설명이 잘 이해되지 않더라도 걱정하지 말기 바란다. 필자도 처음엔 생소한 이론에 당혹감을 감추지 못했지만 다음 시간에 소개할 예정인 자동차 보험회사 관련 데이터를 바탕으로 한 프로젝트에서 구현한 연관 규칙을 살펴 나가면 연관 규칙이 데이터 마이닝 알고리즘 중에서 가장 평이하다는 것을 알게될 것이기 때문이다.

아무튼 이렇게 대용량 데이터베이스에서 잘 알려져 있지 않고 기존 데이터베이스 질의어로는 찾아내기 어려운 패턴은 연관 규칙에 의해 쉽게 발견될 수 있고, 이렇게 발견된 규칙을 바탕으로 편의점에서의 고객 구매 패턴을 알아 낼 수 있을 뿐 아니라 유용한 시장성 예측 등에 적용함으로써 의사결정 지원 시스템으로 아주 큰 역할을 할 수 있다.

 

그러면 연관 규칙의 응용에 대해 살펴보겠다. 응용된 연관 규칙에는 순차패턴탐사와 순회패턴탐사 등을 들 수 있는데, 순차패턴이란 한 트랜잭션 안에서 발생하는 항목들 간의 연관 규칙에 시의 변이를 추가하는 것이다. 예를 들어 비디오 대여점에서 고객들의 비디오 대여 패턴을 찾는 것을 생각해 볼 수 있다. ‘에일리언’을 대여한 고객은 ‘터미네이터 2’를 대여하고 ‘스타워즈 3’의 순서로 비디오를 대여하는 것과 같은 패턴을 찾는 것이다. 주의할 점은 ‘에일리언→터미네이터 2→스타워즈 3’ 사이에 다른 비디오가 대여돼도 그 패턴은 지지가 된다는 것이다. 이러한 순차 패턴은 의료 분야에서도 응용될 수 있는데, 환자에 대해 질병과 투약에 관한 데이터를 분석해 일정한 지지도 이상의 특정 질병에 대해 투약 과정을 순차 패턴으로 정리해 특정 질병을 치료하는데 많은 도움이 될 것이다.

순회패턴은 웹(WWW)이나 온라인 서비스, 천리안, 하이텔 등과 같이 분산돼 있고 상호접근이 가능한 정보들을 접근하는 패턴을 탐사하는 기법이라고 생각하면 된다. 웹에서 정보를 찾을 때 하이퍼링크를 통해 한 사이트에서 또다른 사이트로 이동하게 되는데, 이러한 접근 패턴을 분석하면 시스템 설계와 마케팅 전략 수립에 유용한 정보를 얻을 수 있다.

 

(그림 2)와 같은 접근 패턴을 생각해 보자. 순회 노드는 {A, B, C, D, C, B, E, F, G, F, H, A, W, X, W, Y}로 이뤄진다. 이 접근 패턴에서 순방향 참조 집합은 {ABCD, ABEFG, ABEFH, AWX, AWY}로 구성된다. 각각의 트랜잭션에 대한 순 방향 참조 집합을 구하고, 모든 트랜잭션에 대한 순 방향 참조 집합에서 최소 지지도를 만족하는 빈발 참조 순서를 발견하고 이들에 대해 최대 참조 순서를 찾아내는 방식으로 순회 패턴을 탐사하게 된다.

 

의사결정트리

이번에 알아볼 것은 의사결정트리(Decision Tree) 알고리즘이다. 다소 따분한 내용이 될 수도 있겠으나 예를 들어가며 설명했으니 그리 어렵지 않을 것이다. 의사결정트리는 데이터의 클러스터링(Cluste ring)이나 분류(Classification), 결과 예측을 위해 자주 사용되는 알고리즘이다. 이 알고리즘은 머리 아프게 굳이 통계학적으로 설명하지 않더라도 어떤 현상에 대해 영향을 미치는 변수와 변수들 사이의 상호작용에 대해 누구나 쉽게 이해할 수 있기 때문에 데이터 마이닝을 하고자 할 때 자주 사용되는 기법이며, DM(direct mail)의 응답 여부 등 알아보고자 할 경우나 그외 여러 부분에서 많이 사용되고 있다.

 

의사결정트리를 사용하는 경우는 크게 두 종류로 나눠 볼 수 있다. 우선 결과 예측에 좀더 큰 비중을 두었을 경우이고, 또 하나는 결과 예측보다는 그 결과가 일어나는데 있어 왜 그런 현상이 일어났는지를 설명하는 경우이다. 가령 백화점 등에서 여러 상품에 대한 정보를 팜플렛으로 만들었을 때 모든 고객에게 다 보내는 것은 여러 가지 면에서 낭비를 초래할 수 있다. 이런 경우 어떤 상품에 대해 구매할 가능성이 높은 사람을 우선적으로 예측해 선택적으로 각 고객에게 정말 필요하고 구미가 당길만한 상품 정보를 보내는 것이 훨씬 효과적일 것이다.

 

이러한 경우(DM 발송) 그 과정을 설명하기보다는 결과 예측이 우선이 될 것이다. 반면 결과보다는 그 과정을 설명해야 하는 경우도 있다. 대출을 거절할 만한 근거를 찾는다든가, 아니면 카드 사용승인에 있어 고객에게 그 이유를 반드시 설명해줘야 하는 경우가 있다. 이런 경우 의사결정트리를 사용하면 그 고객에 대한 기존 정보 - 가령 기존 대출액이나 부채, 담보가치 또는 고정 수입 등 - 를 가지고 ‘당신에게 대출을 거절하는 이유는 수입이 얼마 이하이며 담보가치가 얼마이하이기 때문입니다’라는 식의 근거이유를 제시할 수 있다. 예측의 경우 의사결정트리도 가능할 수 있으나 이보다는 주로 신경망 모형 알고리즘을 사용하며 그것이 훨씬 더 정확한 답을 예측할 수 있다.

 

지금까지는 의사결정트리로 얻어낼 수 있는 것이 무엇인지 간략하게 설명했고 다음에는 의사결정트리의 결과가 어떤 형태로 출력되는지에 대해 알아보겠다. 또한 의사결정트리를 이해하는데 있어 필요한 용어에 대해서도 언급하겠다. (그림 3)은 의사결정트리의 기본적인 형태를 보여주고 있는데, 보다시피 기본적으로 그 모양이 나무 모양을 하고 있어 ‘의사결정을 하는데 도움을 줄 수 있는 나무’라는 의미의 의사결정트리라는 이름을 가지고 있다.

 

(그림 3)에 그려진 네모는 모두 마디(Node)로 불리워진다. 이 마디는 데이터베이스에서 사용하는 용어로 레코드의 개념, 혹은 레코드의 한 속성으로 이해하면 된다. 맨 위에 그려지는 마디를 뿌리 마디(Root Node)라 하며 모든 레코드를 말한다. 뿌리 마디를 어떤 특정한 법칙에 의해 나누게 되면 바로 밑에 생기는 마디는 자식 마디(Child Node)라 한다. 결국 자식 마디는 뿌리 마디의 한 부분이 되는 것이다. 이런 식으로 어떤 법칙을 가지고 위의 마디를 나누는 것을 가지치기라 하고, 더이상 가지쳐질 마디가 없으면 이 마디는 종단 마디(Leaf Node)가 된다. 다시 말하면 종단 마디는 의사결정수의 맨 하단에 생기는 마디가 된다. 이제는 실제적인 예로 의사결정수가 형성되는 과정을 설명해보도록 하겠다.

 

한 신용카드 회사에서 고객에 대한 대출여부를 가리는 경우가 있다고 가정하자. 이 회사는 고객에 대한 여러 가지 개인정보(고정수입, 담보가치, 부채 등)와 또한 다른 개인 신용정보를 가지고 있을 것이며, 그전에 이러한 개인 정보를 가지고 실제 대출하는데 있어 위험성이 있었는지에 관한 많은 데이터를 확보하고 있어야 한다. 여기서 최종적으로 얻어내고자 하는 것은 한 고객에 대해 신용에 대한 리스크(Risk)를 구해 고객의 리스크에 따라 대출을 허용함으로서 대출금 미상환으로 생길 수 있는 회사에 대한 손해를 최대한으로 줄이려는데 그 목적이 있다고 하자.

 

결론과 목적이 정해지면 다음으로 그 리스크에 가장 많은 영향을 끼치는 개인 정보를 찾아내 그 특성을 기준으로 뿌리 마디를 나눈다. 둘째로 리스크에 많은 영향을 끼치는 개인 정보를 찾아내 같은 방법으로 가지를 친다. 계속 수행하다가 더이상 리스크에 영향을 미치는 개인 정보가 발견되지 않으면 가지치기를 멈추고 이럴 경우 리스크로만 이뤄진 마지막 노드가 종단 노드가 된다.

 

위와 같은 방법으로 형성된 의사결정트리로 우리는 가령 ‘고정수입이 얼마 이상이고 부채가 어느 정도이면서 담보가치가 어느 정도 이상이면 배드 리스크(Bad Risk)가 예상되므로 대출을 해주면 위험할 수 있다’는 결론을 얻어낼 수 있다.

 

지금까지 정말로 간단하게 가장 굵은 라인만 설명했다. 다음에는 실제적인 예를 들어가면서 하나하나 설명할 것이기 때문에 이번 시간에서는 이 정도만 이해해도 좋을듯하다. 또한 설명하면서 ‘가장 영향을 끼치는’이라는 표현을 자주 사용했는데, 그 영향을 계산하는 원리, 영향의 정도를 나타내는 방법에 대해서도 다음 시간에 자세히 다룰 것이다.

마지막으로 의사결정트리에는 여러 가지 기법이 있다. CART, CHAID, C4.5, ID3 등이 대표적인 의사결정트리 기법들이다. 여기서 CART, CHAID, C4.5는 언급하지 않겠지만 그 레이아웃은 거의 비슷하다고 생각해도 된다. 이러한 분석기법에 대해 어떤 상황에, 어떤 알고리즘이 더 좋다고 단정지어 말하기는 어렵다. 여기서 단정지을 수 있는 것은 가지고 있는 데이터에 다양한 알고리즘을 적용해 보다 더 타당하게 해석이 가능해 의미있는 결론을 유출해주는 알고리즘을 선택해야 한다는 것이다. 참고로 본 프로젝트에서는 ID3 알고리즘을 사용했고 이 기법에 대한 자세한 내용은 다시 언급하겠다.

 

신경망에 대해

기능적인 면에서 우리의 뇌는 컴퓨터와 비교 가능하다. 하지만 <표 1>에서처럼 아직까지는 우리 인체, 특히 뇌에 대한 부분을 컴퓨터가 대신하기엔 아직까진 역부족인 것 같다. 뇌는 단순한 뉴런들의 구성임에도 불구하고 상당히 복잡한 작업을 처리하는 것을 보면 뇌에 대한 연구성과가 얻어질수록 컴퓨터의 발달은 더욱더 박차를 가하게 될 것이며 인간에게 편리를 제공할 것은 과거를 보듯 자명하다.

 

뉴로 컴퓨터는 1943년 McCulloch-Pitts 모델을 시작으로 1960년 B. Widrow와 M. Hoff에 의해 ADALINE이란 이름의 모델로 틀을 잡아가기 시작했으며 패턴분류, 음성인식, 문자인식, 영상인식, 로봇제어, 연상메모리, 신호처리 등 많은 분야에서 쓰여지고 있다. 우선 우리가 어떤 신경망 모델을 이용할 것이며, 구조는 어떻게 구성하고 신경망을 어떻게 효과적으로 학습시키는지 알아야 하고 학습패턴의 특징은 어떻게 추출하는지 또 실제 구현은 어떻게 할 것인가를 생각해 봐야 한다.

 

구체적인 내용은 다음 시간에 다루기로 하고 그러면 이번에는 간략하게 신경망 알고리즘에 대해 언급하겠다. (그림 4)의 일반적인 신경망 모델로 설명하면 다음과 같다.

 

X = [X1, X2 , ···, Xn] : 입력데이터,

W = [W1, W2, ···, Wn] : 연결강도,

NET = X1W1+ X2W2+ ··· Xn Wn,

OUT = f(NET) : 결과(출력)데이터

 

X는 입력 값 중 하나이고 W는 입력값에 대한 각 부분의 연결 강도이다. 하나의 입력값 X에 대한 W를 곱한 것이 NET이다. 이 NET을 활성화 함수를 사용해 원하는 결과로 분류 내지 예측할 수 있다. 활성화 함수는 단조증가 함수가 쓰이는데 단극성/양극성, 선형/비선형, 연속/이진 함수 등으로 쓸 수 있으며, 종류에는 항등 함수, 경사 함수, 계단 함수, 시그모이드 함수 등이 있다. 특히 시그모이드 함수를 활성화 함수로 사용하면 뉴런의 출력이 아날로그 형태로 나타내는 장점이 있다. 활성화 함수의 내용은 다음에 다루기로 하고 이 활성화 함수를 거쳐 나온 것이 최종 출력값이 되는 것이다.

 

여기까지의 단계를 방대한 데이터로 반복해 일련의 작업을 하는 것을 학습이라 한다. 그 결과로 전체 데이터에 대한 연결강도(w) 값이 고정이 되는 것이며, 또한 전체 데이터에 대한 분류 작업이 끝난 것이다. <그림 4>에서는 나와 있지 않은, 뒤에서 언급되는 부분이지만 우리는 역전파망(Back Propagation Network)을 사용했다. 이것은 입력, 출력 노드외에 은닉 계층을 가지고 있다. 학습을 시킨 결과와 실제의 값을 비교해 차이가 있다면 연결강도를 보정해 어느 정도 정확한 결과를 얻을 때까지 계속 반복 학습을 시키는 것이다. 그 결과로 신경망이 완성되는 것이며 우리가 알고자 하는 유형의 데이터를 완성된 신경망을 적용해 예측하는 것이 가능하다. 이해되지 않더라도 너무 걱정하지 않아도 된다. 다음 시간에 신경망에 대한 자세한 설명과 구체적인 구현 내용이 수록되니 참고하기 바란다.

 

데이터 마이닝 시스템의 실제 적용

이제까지 데이터 마이닝이란 무엇이며, 왜 필요하고 더불어 데이터 마이닝 알고리즘 중에서 연관 규칙, 의사결정트리, 신경망의 개략적인 지식에 대해 살펴봤다. 그러면 이제부터 실제로 본 프로젝트가 어떻게 이러한 데이터 마이닝 알고리즘을 사용해 데이터 마이닝 시스템을 구현했는지에 대해 살펴보겠다.

 

본 프로젝트는 자동차 손해 보험사의 운영계 데이터베이스를 기반으로 사고와 계약에 관련된 데이터 웨어하우스를 구축하고 OLAP과 데이터 마이닝 시스템를 구축했다. 현재 자동차 보험은 보험개발원의 통제를 받는 11개사를 중심으로 시장이 형성돼 있는데, 최근 일고 있는 보험시장 개방화 및 보험상품 가격 자유화의 움직임은 2000∼2001년에 구체화될 전망이다. 또한 외국 보험사의 시장 유입으로 국내외 보험사간의 경쟁은 치열해질 것으로 보인다. 자동차 보험사들은 이러한 변화에 대응하는 정책 개발을 위해 기존에 확보하고 있는 데이터를 분석하고 그를 기반으로 새로운 의사결정을 할 수 있는 전산 시스템의 개발을 피할 수 없게 된 것이라 할 수 있다.

 

특히 자동차보험 가격 자유화라는 상황에 적응할 수 있는 새로운 전략은 자동차 보험회사에게 특히 자사의 이익과 관련해 중요한 문제가 됐다. 과거 구미 선진국이 가격 자유화 시행초기에 가격덤핑과 과다경쟁으로 수많은 보험사가 도산했는데, 보험사는 무차별적인 가격인하에 따른 손익 악화를 미연에 차단하고 경영에 건전성을 확보하기 위해 합리적이고 적절한 보험료를 제시해야만 한다.

 

많은 우량 고객을 지속적으로 확보하므로써 얻어지는 안정적인 이익율의 유지는 고객층을 세분화하고 보험료를 차별화함으로써 이룰 수 있다. 우량 고객을 집중적으로 확보하기 위해서는 개인 위험도(사고 액수에 따라 분석 가능하다)에 따라 위험도가 낮은 고객은 우량 고객으로 구분해 할인 혜택을 부여하고, 위험도가 높은 고객에게는 보험료를 할증하는 방안을 적극적으로 모색해야 한다. 과학적이고 세분화된 고객 구분과 보험료의 할인, 할증의 적용은 자동차 보험사의 손익차원에서 매우 중요하다(대한화재의 경우 성별, 연령, 차종 등 피보험자의 정보를 통해 위험도를 세분화한다든지, 동양화재와 국제화재는 개별 위험도에 따른 최적의 가격을 제공하고 우량 고객을 확보한다는 계획으로 정교한 요율 산출 시스템을 구축하고 있다).

 

현재는 보험료를 책정할 때 기본 보험료(차종, 용도 한정, 배기량, 나이에 따라 책정됨)에 보험 경력, 사고 경력 등 피보험자의 과거 이력을 중심으로 해 왔다. 이러한 보험료 계산은 자동차 보험사의 손익 형평성에 문제를 발생시킨다. 예를 들어 어떤 사람이 A자동차 보험사에 가입하고 일년간 커다란 교통사고를 여러 번 일으켜서 그 회사에 사고배상책임을 지게 했다. 그런데 다음해에 B자동차 보험사에 가입하면서 사고에 따른 할증을 붙인 보험료를 지불했다면 A자동차 보험사는 손해를 보게 되고 B자동차 보험사는 이익을 보게 된다. 보험료와 사고배상액수의 차이가 있기 때문이다. 비단 이런 문제외에도 현재의 보험료 계산이 과학적이지 못하고 허점이 있다는 것은 지역을 전혀 고려하지 않는다는 점에서도 나타난다.

본 프로젝트는 새로운 보험료 책정방법을 대안으로 제시하고자 한다. 즉 피보험자의 지역, 성별, 나이, 차종, 용도, 한정, 3년간 사고액수를 통해 일년간 사고액수를 예측하는 시스템을 개발해 1년간 사고예상액수를 추가적으로 적용해 보험사의 이익을 보장해 줄 수 있는 현실적인 보험료 책정에 기여하고자 한다.

 

시스템 구축은 보험 업무를 이해하고 요건을 정의하는 단계에서 시작해 실제 시스템을 구축하는 단계(데이터 준비, 모델 구축, 시스템 개발)를 거쳤다. 마이닝 시스템 구축에 필요한 데이터를 준비하는 단계에서 많은 노력이 필요했는데, 대개의 경우 운영 데이터는 기업의 보안상 공개하지 않고 해당 기업으로부터 수주를 받지 않는 한 실제 데이터를 얻는 것은 쉬운 일이 아니었다. 본 프로젝트는 소량이지만 실제 데이터를 가지고 작업했으며 부족한 부분은 적용하고자 하는 보험 업무에 관한 기초 통계자료를 이용해 통계치에 알맞은 데이터(약 1백만개 이상)를 시뮬레이션해 사용했다.

모델 구축은 샘플링(Sampling), 탐색(Exploration) 변환 및 조정(Modification), 모델링(Modeling), 그리고 평가(Assessment)의 단계로 이루어졌다. 트레이닝 셋으로는 1988∼1999년 사이에 자동차 보험에 가입한 차량과 피보험자에 관련된 교통사고 중에서 업무용과 영업용을 제외한 개인용 자동차 보험에 한정해 구성했다. 우선 피보험자를 기준으로 그와 관련된 계약 데이터를 선정하고 그 피보험자와 차량과 관련된 10년간 사고를 추출해 샘플 데이터를 구성했다.

 

본격적인 모델링 작업에 들어가기 전에 샘플 데이터를 중심으로 고객과 사고의 특징을 탐색하고 그 정보를 바탕으로 다양한 변수변환이 수행됐다. 주된 마이닝 기법으로는 복잡한 패턴의 발견과 예측에 유용한 신경망(Neural Network) 중 다층 퍼셉트론이고 백프로퍼게이션 알고리즘으로 구현했다. 또한 연관 규칙 탐사를 위해 Apriori 알고리즘, 데이터의 클러스터링에는 의사결정트리 중 하나인 ID3 알고리즘을 구현했다.

 

데이터 웨어하우스의 구축

 

-데이터 웨어하우스와 데이터 마이닝

 

데이터 마이닝을 위해 데이터 웨어하우스가 반드시 존재해야 하는 것은 아니다. 하지만 “Garbage In Garbage Out!!”이란 말처럼 오류가 있는 데이터에서 아무리 뛰어난 마이닝 알고리즘을 적용한다 해도 얻어진 결과에 대해서는 신뢰가 생길 수 없다. 따라서 마이닝을 통해 정확하고 올바른 결과를 얻기 위해서는 적용된 데이터가 정제되고 표준화돼 일관성 있는 체계적인 구조로 준비돼야 한다.

 

일반적으로 기업이 가지고 있는 데이터는 다양한 형태로 모아지므로 서로 일치하지 않거나 부정확한 값을 가지고 있는 경우가 많다. 그러므로 먼저 이러한 문제점이 해결된 후에야 비로소 효과적이고, 신뢰할 수 있는 데이터 마이닝을 수행할 수 있다. 이러한 부분은 데이터 웨어하우스가 구축돼 있다면 보다 쉽게 해결될 수가 있다. 데이터 웨어하우스는 데이터 마이닝 과정에서 많은 시간과 노력을 요구하는 학습자료의 수집, 데이터 정제 및 전처리 과정에 들어가는 부담을 경감시킴으로써 데이터 마이닝의 성공 가능성을 높여준다. 따라서 데이터 웨어하우스가 효율적인 데이터 마이닝을 위한 출발점이 된다고 볼 수 있다.

 

-데이터 웨어하우스 설계 및 구축

 

데이터 웨어하우징 프로세스의 개발 단계는 종종 사용자 요구사항을 기초로 한 선택된 주제 영역의 중요 매트릭스와 차원(Dimensio nal) 비즈니스 모델을 생성함으로써 시작된다. 고도의 정규화된 방법으로 데이터를 조작하는 OLTP 시스템과 달리 데이터 웨어하우스의 데이터는 관계형 데이터베이스 관리 시스템(RDBMS)에 대한 질의 성능을 향상하기 위해 아주 비정규화된 수단으로 조직화된다. 관계형 데이터베이스의 기본 설계도가 ER-다이어그램(Diagram)이라면 데이터 웨어하우스의 설계도는 스타 스키마(Star Schema)라는 별 모양의 설계를 바탕으로 보통 데이터 웨어하우스가 구축된다.

 

스타 스키마는 주제 분야를 위한 비정형화된 중앙(‘Fact’) 테이블과 주제들의 차원에 관한 서술적인 정보를 포함하는 복수의 Dimension 테이블을 포함한다. Fact 테이블과 직접적인 관련을 갖지는 않지만, Dimension 테이블과 직접적 참조로 관련성을 갖는 스노우플레이크(Snowflake)도 존재한다. 중앙 Fact 테이블은 수백만건의 행(row)을 포함할 수 있다. 스타형 스키마는 데이터 웨어하우스 설계를 단순화하고 성능을 향상시키기 위해 데이터베이스 관리자를 위해 기본적으로 고려된 도구인 동시에 또한, 비즈니스 사용자에게 보다 쉽게 이해되도록 데이터 웨어하우스 정보를 표현하기 위한 유용한 규약이다. 자동차보험 마이닝을 위한 데이터 웨어하우스를 구축하기 위해 웨어하우스 설계를 위한 스타 스키마를 이용했다.

<화면 1>에서 처럼 Accident_Fact와 Sales_Fact라는 Fact 테이블이 자동차 보험의 중심 주제가 되는 테이블이 된다. Accident_Fact는 자동차 사고내용 테이블로, 그리고 Sales_Fact는 자동차 보험 가입 내용으로 후에 데이터 마이닝의 의사결정(ID3 알고리즘 이용), 연관 규칙(Apriori 알고리즘 이용), 신경망(백프로퍼게이션 이용)에서 자동차 사고와 자동차 보험에 관련된 클러스터링 패턴 발견으로 예측 시스템을 구현하는데 적용될 주제중심의 효과적 수행을 이룰 중심 Fact 테이블이 된다.

 

이 Fact 테이블의 Foregin Key는 이 테이블과 연결된 즉, 관련성을 갖는 Dimension 테이블의 Primary Key로써 실제 Accident_Fact 테이블의 주제 중심 필드는 Unit_Accident (자동차 사고 회수)이고, Sales_Fact 테이블에서는 Unit_Sales(자동차 보험 계약 회수)가 주제 중심 필드가 된다. 데이터 웨어하우스를 가지고 후에 OLAP 서버 구축시 MS-SQL 서버 7.0의 OLAP 서비스 중 OLAP 매니저를 가지고 큐브(Cube)를 생성하게 되는데, 큐브 생성시 이 주제 중심 필드들이 큐브의 수치(Measure)로 되어, 이 OLAP을 가지고 경영자가 의사결정을 할 때 이 수치를 보고 상황을 쉽게 파악하게 해준다.

 

CREATE TABLE [dbo].[Accident_Fact] (

[TID] [int] NOT NULL ,

[AFact_Customer_ID] [int] NOT NULL ,

[AFact_Insure_ID] [int] NOT NULL ,

[AFact_Time_ID] [int] NOT NULL ,

[AFact_Accident_ID] [int] NOT NULL ,

[Unit_Accident] [int] NULL

) ON [PRIMARY]

 

CREATE TABLE [dbo].[Sales_Fact] (

[CFact_Contract_ID] [int] NOT NULL ,

[CFact_Customer_ID] [int] NOT NULL ,

[CFact_Insure_ID] [int] NOT NULL ,

[CFact_Time_ID] [int] NOT NULL ,

[Unit_Sales] [int] NULL

) ON [PRIMARY]

 

이렇게 중심이 되는 Fact 테이블을 만든 후 이와 연결 즉, 관계를 갖는 Dimension 테이블과 간접적 관계를 갖는 Snowflake 테이블을 생성한다.

 

Fact Tables :

Accident_Fact

Sales_Fact

 

Dimension Tables :

Time_Table

Accident_Kind

Customer

Insuranc_Com

Contract

 

Snowflake Tables :

Car_Name

Career

Pay_Method

Car_Kind

Age

Region

Gender

 

이론적으로 지식 탐사 절차는 다음과 같은 단계로 나누어진다.

 

◆ 데이터 선정(Selection)

◆ 정제 (Cleaning)

◆ 보강 (Enrichment)

◆ 코딩(Coding)

◆ 데이터 마이닝(Mining)

◆ 보고서 작성(Report)

 

하지만 이러한 절차가 일련의 연속과정은 아니고 단계에서는 오류를 발견하거나 새로운 데이터를 발견해 데이터 보강의 필요성이 있을 경우 언제든지 전 단계로 피드백 과정이 이뤄진다. 본 프로젝트는 앞서 밝힌 바와 같이 자동차 보험회사의 자동차 사고와 보험 계약에 관련된 데이터를 선정했다. 정제 과정은 데이터 마이닝 시스템을 구축하는 데 있어 가장 중요한 단계라고 볼 수 있으며, 정제 작업의 한 요소로 중복을 제거하는 것을 생각할 수 있다. 중복된 데이터는 고의적으로 또는 착오로 발생할 수 있는데 본 프로젝트에서는 이러한 중복 데이터는 없는 것으로 간주하고 데이터 마이닝 시스템을 구축했다.

 

정제 작업의 또 다른 요소로 일관성 유지를 들 수가 있다. 예를 들어 1901년 1월 1일에 보험회사에 가입한 사람이 데이터베이스에서 발견됐다고 하자. 또는 생일이 11월 11일인 사람의 기록이 예상 이상으로 많이 발견됐다고 하자. 이 두 가지 경우를 놓고 볼 때 전자의 경우 100살에 가까운 사람이 자동차 보험에 가입한 경우로 볼 수 있고, 후자의 경우 자신의 인적 사항 노출로 인한 피해를 방지할 생각으로 생일을 11-11-11로 기입한 경우가 될 수도 있다.

 

이런 두 가지 경우는 데이터 마이닝에서 심각한 오류 결과를 도출할 수 있기 때문에 불확실한 정보에 대해 일관성을 유지할 수 있도록 해야 한다. 그래서 본 프로젝트에서 이러한 데이터들은 NULL로 대치하도록 했다. 보강 작업은 운영계 데이터베이스가 존재해 도출하고자 하는 데이터 마이닝 결과에 영향을 줄 수 있는, 다시 말해 지속적으로 삽입, 삭제, 갱신이 되는 운영계 데이터베이스가 존재해야 하지만 일정 기간의 자동차 보험회사의 데이터를 대상으로 데이터 웨어하우스를 구축했고 운영계 데이터베이스는 더이상 삽입, 삭제, 갱신이 없는 것으로 했다.

 

따라서 보강 작업은 생략했다. 코딩 작업은 수집된 데이터에 대해 도출할 마이닝 결과나 OLAP에서 도출할 결과에 맞게 데이터를 변환하는 작업이다. 본 프로젝트에서는 이러한 코딩 작업을 수행해 데이터 웨어하우스의 Dimension 테이블과 Snowflake 테이블을 구축했다. 다음은 평평화(flattening) 작업이 수행된 자동차 사고와 관련된 Dimension 테이블과 Snowflake 테이블이다.

 

이상으로 OLAP 시스템과 데이터 마이닝 시스템 구축을 위한 선처리 단계로써 데이터 웨어하우스 구축에 대해 알아봤고 다음으로 본 프로젝트에서 구현한 OLAP 시스템에 대해 이해를 돕기 위해 간략하게 이론을 살펴보고 OLAP 시스템의 실제적인 구축에 대해 살펴보도록 하자

 

OLAP 시스템 구축

온라인 분석 프로세싱이라 불리는 OLAP은 기업의 데이터 모델을 정적 모델과 동적 모델로 구분하며, OLAP을 ‘동적 모델로부터 정보를 생성, 조작, 활성화(animation), 종합하는데 필요한 역동적 기업분석’으로 정의할 수 있다, 여기서 정적 모델이란 사용자의 대화식 참여가 거의 없고 정형화된 양식의 보고서 생성작업이나 간단한 질의가 수행되는 모델을 말한다. 여러 가지 OLAP에 대한 정의를 정의하면 ‘최종 사용자가 다차원 정보에 직접 접근해 대화식으로 정보를 분석하고 의사 결정에 활용하는 과정’으로 정의하면 적절하겠다.

 

특징을 살펴보면 우선 분석을 위해 활용되는 정보의 형태가 다차원적이라는 사실이다. 그리고 최종 사용자는 중간 매개자(전산부서)나 매개체(리포트) 없이 온라인 상에서 직접 데이터에 접근한다는 것이다. 또한 최종 사용자는 대화식(Interactive)으로 정보를 분석한다는 것이고, OLAP의 목적은 최종 사용자가 기업의 전반적인 상황을 이해할 수 있게 하고 의사결정을 지원하는데 있다.

 

다음은 OLAP 서버와 웨어하우스의 관계에 대하여 알아보자. OLAP 서버는 많은 측면에서 데이터 웨어하우스와는 다른 특성을 갖는다. OLAP은 복잡한 연산과 모델링을 포함해 기업데이터의 다차원 분석을 수행한다. OLAP은 이처럼 특화된 분석을 수행하는데 비해, 데이터 웨어하우스는 기업의 모든 사용자를 대상으로 이들이 수행할 잠재적인 모든 유형의 질의에 대처하기 위한 정보 저장고로서 역할을 한다.

 

데이터 웨어하우스는 사용자들이 자신의 업무를 보다 효과적으로 수행할 수 있도록, 그리고 좀더 정보에 근거한 의사결정을 할 수 있도록 가능한 모든 정보의 저장소(Virtual Repository)를 만드는데 있다. 따라서 데이터 웨어하우스는 좀더 상세한, 혹은 트랜잭션 수준의 데이터까지 보유할 수 있다. 데이터 웨어하우스는 일반적으로 OLAP 시스템이 사용하는 것처럼 복잡한 다차원 분석을 지원하지 못하며, 읽기 전용(Read only)이다. 반면 OLAP 시스템은 <그림 5>처럼 사용자들이 직접 데이터를 갱신하고 분석할 수 있도록 허용한다.

 

많은 OLAP 시스템이 미래지향적인 반면 데이터 웨어하우스는 과거 지향적이며, 추측과 관련된 자료를 포함하지 않는다. 즉 사용자는 OLAP을 통해 기업의 미래에 관한 질문을 수행한다. OLAP에서 사용자는 대화식 질의를 수행하며, 질의 결과를 신속하고 일관성 있게 얻기를 기대한다. 반면 데이터웨어 하우스에서 수행되는 질의는 매우 간단한 질의에서 매우 복잡한 프로세싱을 요구하는 질의에 이르기까지 다양하며, 질의 속도도 질의 유형에 따라 많은 차이가 있다.

 

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

 

OLE DB for OLAP은 OLE 데이터베이스의 여러 프로바이더 중 하나로 다차원적 데이터베이스(Multi Dimensional Database)에 접근해 데이터를 가져오는 MSOLAP이라는 프로바이더를 사용해 프로그래밍을 하도록 만들어진 서비스이다. OLE DB for OLAP은 DataSet이라는 자료 구조형을 지원하며, 이 자료 구조는 다차원 구조의 DBMS에서 원하는 자료를 가져오기 위해 정의돼 있고 다차원 스키마 정보에 의해 자료를 검색 및 추출한다. 기본적으로 OLE 데이터베이스의 사용법과 같은 방법으로 사용한다.

 

DataSet 데이터형으로 자료를 가져오기 위해서는 MDX(Multi Dimensional Expression, 이하 MDX)라는 쿼리문을 사용한다. MDX 문법은 기존의 SQL과는 다른 문법구조를 가지며 다차원 정보에 접근해 정보 추출을 하기 위해 컬럼(Cloumn)과 열(Row)로 슬라이서(Slicer)라는 기본 골격을 가진다. 데이터셋을 이용하기 위해 OLE DB for OLAP은 DataSet이라는 객체를 제공하며, Comm and 객체에서 MDX 쿼리를 이용해 DataSet 객체를 만들 수 있다.

OLE DB for OLAP 인터페이스들은 COM 기반하에 다차원적인 데이터의 표현, 이동 그리고 효과적인 검색 등을 가능하게 하며, 단일 프로세스에서 데이터 소비자 또는 제공자 그리고 다차원 데이터 제공자(Multidimensional Data Provider)들이 같은 프로세스에서 작동된다. 예를 들면 OLE DB for OLAP 제공자와 RDBMS의 쿼리 엔진이 같은 프로세스에서 작동하는 것이다. 서로 다른 기기 또는 서로 다른 프로세스에서 돌아가는 소비자와 MDP 등과 같은 구성 예는 피봇 테이블 컨트롤이 MDP와 함께 돌아간다.

 

또한 OLE DB for OLAP은 OLE 데이터베이스의 구성을 높여준다. 같은 인터페이스들이 데이터 제공자와 서비스 제공자의 다양한 레벨에서 동작할 수 있게 서로 연결되며, 가능한 많은 OLE 데이터베이스를 재사용한다. 그리고 명세 객체들과 인터페이스들의 개수는 최소화됐다. OLE DB for OLAP은 공동 이용이 가능한 액세스를 위해 디자인되어 있다. 이런 인터페이스는 공통적인 소비자의 다차원적 데이터 처리를 위해 요구하는 것들을 커버할 수 있지만 서버 레벨에서 변화를 구현하지 않고 현존하는 MDPs를 OLE DB for OLAP으로 표현할 수 있게 하는데 중요한 요소로 작용한다.

 

OLAP의 표준 부재로 인해 다차원 데이터를 조회하기 위한 표준 질의 언어 역시 존재하지 않는다. 현재 각 OLAP 제품들은 자신들의 고유한 스크립트 언어를 사용해 보고서 작성에 필요한 질의문을 구성하고 있다. 한편, OLE DB for OLAP API에 포함된 MDX라는 다차원 질의 언어는 풍부한 기능을 갖추고 많은 OLAP 벤더의 호응을 얻고 있는 다차원 질의 언어의 실질적인 표준으로 받아들여지고 있다. 다차원 질의 결과를 데이터셋(DataSet)으로 표현하며, 데이터셋의 열과 행을 구성하는 차원을 축(Axis) 차원, 페이지를 구성하는 차원을 슬라이서( 차원이라고 부른다. 일반적인 MDX 구문은 다음과 같은 형태를 취한다.

 

SELECT <축 차원>

FROM <큐브>

WHERE <슬라이서 차원>

예를 들어 다음과 같은 보고서를 만들어 보자.

 

위와 같은 보고서의 페이지는 ‘매출분석’ 큐브의 기간 차원으로, 열은 매장 차원으로 행은 제품 차원과 변수 차원으로 구성돼 있다. 이 보고서를 만들기 위한 MDX 구문은 다음과 같다.

 

SELECT ([반포], [잠실]) ON ROWS,

CROSSJOIN({[냉장고], [세탁기]}, {[매출액],[매출수량]}) ON COLUMNS

FROM [매출분석]

WHERE ([1월]

 

데이터를 가져올 큐브는 FROM절을 사용해 구성한다. 예를 들어 ‘매출분석’ 큐브로부터 데이터를 조회하기 위해서는 ‘FROM [매출분석]’ 절이 필요하다. 하나 이상의 큐브에서 데이터를 가져올 경우 From 다음에 큐브명을 나열한다. 보고서의 행과 열은 SELECT절에서 정의된다. 앞에서 보고서의 행은 제품과 변수 2개 차원이 중첩돼 있으며, 제품차원에서는 냉장고와 세탁기가, 변수차원에서 매출액과 매출 수량이 선택됐다.

 

2개의 항목들이 결합돼 4개의 좌표 - (냉장고, 매출액), (냉장고, 매출 수량), (세탁기, 매출액), (세탁기, 매출 수량)-가 만들어졌는데, 이를 튜플(Tuple)이라 한다. 즉 튜플은 다른 차원에 속하는 항목이 결합돼 만들어지는 항목들의 모임을 말한다. 튜플은 보고서의 행과 열을 구성하는 기본 단위로 생각할 수 있으며 튜플의 집합을 셋(Set)이라고 한다. 2개 이상의 차원이 중첩되는 경우 각 차원에서 선택된 항목을 하나씩 결합해 나열하는 작업은 매우 번거롭다. 따라서 다음과 같이 각 차원에서 선택된 항목들에 대해 CROSSJOIN 함수를 사용할 수 있다.

 

CROSSJOIN {([냉장고], [세탁기]), ([매출액], [매출수량])}

 

보고서의 행은 매장 차원으로 구성돼 있으며 반포와 잠실이 선택됐다. 이처럼 보고서의 행이나 열을 하나의 차원이 구성할 경우 각 튜플은 항목과 동일하다. 보고서의 열과 행을 구성하는 튜플이 만들어지면, 다음과 같이 SELECT절을 구성할 수 있다.

 

SELECT {([냉장고], [세탁기]), ([매출액], [매출수량])} ON COLUMNS,

CROSSJOIN ([강북권], [강남권]) ON ROWS

SELECT절에서 컬럼과 열은 데이터셋을 구성하는 축을 나타낸다. 실제 MDX에서 데이터셋은 컬럼(Column), 열(Rows), 페이지(Pages), 부분(Section), 장(Chapter) 등 다섯 개의 축으로 구성되는데, 각각은 AXIS(0), AXIS(1), AXIS(2), AXIS(3), AXIS(4)로 표현될 수도 있다. 모든 축은 순서대로 사용돼야 하며 중간에서 생략될 수 없다. MDX에서 페이지는 지금까지 설명한 페이지 차원과는 약간 다른 개념이다. 보고서의 페이지 차원은 WHERE절에서 정의된다. 앞의 예에서 데이터는 기간 차원의 ‘1월’ 항목에 대해 추출되며 다음과 같이 구성된다.

 

WHERE ([1월])

 

한편 SELECT절 없이 모든 차원이 WHERE절에 명시된 경우 하나의 데이터 값만을 조회하게 된다. 예를 들어 다음과 같은 MDX문은 매출분석 큐브로부터 반포매장의 1월, 세탁기, 매출액 값 하나를 가져온다.

 

FROM [매출분석]

WHERE ([1월], [매출액], [반포], [세탁기])

 

또한 MDX에서 항목 선택은 매우 다양한 방식으로 이루어 질 수 있는데, MDX는 셋을 구성하는 항목을 선택할 수 있도록 다양한 함수를 제공하고 사용자는 데이터 값과 함께 차원 항목의 애트리뷰트(또는 프로퍼티)를 조회할 수 있다. 그리고 MDX는 다차원 모델에서 존재하지 않는 항목을 관계식을 이용해 직접 생성할 수 있도록 한다. 이외에도 MDX는 다차원 질의에 필요한 매우 풍부한 기능을 제공하고 있다. 현재 대부분의 OLAP 제품은 MDX의 풍부한 기능을 완벽하게 사용할 수 있을 만큼 충분한 환경을 제공하지 못하고 있다. 따라서 OLAP 벤더들에 의해 MDX가 지원하더라도 당분간은 MDX의 일부만 지원되고, MDX가 완벽하게 구현되기까지는 어느 정도 시간이 걸릴 것이다. 이제부터는 본 프로젝트에서 구축한 OLAP 시스템에 대해 구체적으로 살펴보도록 하자.

<그림 6>은 본 프로젝트의 시스템 구성도이다. 데이터베이스는 자동차 보험회사의 실제 데이터를 바탕으로 데이터베이스를 관계형 데이터베이스로 구축하고 OLAP이나 데이터 마이닝을 위한 적정 수준의 데이터를 구축하기 위해 실제 데이터로부터 샘플링해 이를 바탕으로 최소 30만개에서 최대 60만개의 데이터를 구현했다. 운영 데이터베이스를 바탕으로 다차원 모델링을 통해 OLAP과 마이닝의 트랜잭션 데이터베이스를 위한 데이터웨어 하우스를 <그림 6>과 같이 구축한다. 데이터 웨어하우스는 사고와 계약에 관련된 두 개의 Fact 테이블로 구성되며 OLAP 툴에서 수치(Measure)가 된다. 각각의 Fact 테이블은 다차원으로 이뤄졌다.

데이터 웨어하우스는 윈도우 NT 4.0 상에서 MS-SQL 7.0을 사용해 원시 데이터베이스와 같은 시스템 상에서 구현했고 OLAP 서버는 윈도우 NT 상에서 구현하며, MS-SQL 7.0에서 지원하는 OLAP 엔진인 OLAP 매니저를 사용했다. OLAP 클라이언트는 OLE 데이터베이스를 이용해 데이터 웨어하우스에 접근하고 OLAP 매니저와 동일 시스템 상에서 구현했다.

본 프로젝트 OLAP의 실행 화면을 보면서 관련 소스를 살펴보자. <화면 2>는 OLAP 클라이언트에서 OLAP 서버에 접속한 후 알고자 하는 Dimension과 Measure를 왼쪽 트리에서 오른쪽의 FlexGrid로 드래그 앤 드롭해 보여진 결과이다.

화면의 하단에 MDX문이 생성된다. 반드시 하나의 축에 하나의 Dimension을 놓아야 하는 것은 아니다. 두 개 이상의 차원을 하나의 축에 놓으면 MDX는 Crossjoin로 문장이 생성된다. 다음과 같이 Grid의 실행 결과를 그래프로 볼 수 있는데, 실행 결과 전체를 그래프로 보기 원하면 그냥 GraphView 버튼을 누르면 되고, 특정 부분을 그래프로 보기 원하면 Grid 위에서 특정 부분을 마우스를 이용해 드래그한 후 GraphView 버튼을 누르거나 마우스의 오른쪽 버튼을 눌러 컨텍스트 메뉴(Context Menu)에 그래프보기 버튼을 누르면 된다.

 

void CExceView::OnMouseDownGrid(short Button, short Shift, long x, long y) 
{
// TODO: 컨트롤 통지 핸들러 코드를 첨가한다.
if( Button == 1)
{
CExceDoc* pDoc = GetDocument();
m_FlexGrid.SetMergeCells(0);
bGridDrag = TRUE;
int SC = m_FlexGrid.GetMouseCol();
int SR = m_FlexGrid.GetMouseRow();
int cRowHeader = m_FlexGrid.GetFixedCols();
int cColHeader = m_FlexGrid.GetFixedRows();

if ( SC < cRowHeader ) SC = cRowHeader;
if ( SR < cColHeader ) SR = cColHeader;
pDoc->SetDragStart(SC,SR);
}
}

void CExceView::OnMouseUpGrid(short Button, short Shift, long x, long y) 
{
// TODO: 컨트롤 통지 핸들러 코드를 첨가한다.
if ( GetApp()->m_bDragging )
{
GetApp()->m_bDragging = FALSE;
GetApp()->m_pDragImage->DragLeave(this);
GetApp()->m_pDragImage->EndDrag();
delete GetApp()->m_pDragImage;
CTreeCtrl *pTree = GetDocument()->m_pCTree->m_pTree;
int ColPosition = m_FlexGrid.GetMouseCol();
int RowPosition = m_FlexGrid.GetMouseRow();

if ( GetApp()->m_pDragWnd->IsKindOf(RUNTIME_CLASS(CTreeView)) )
{
if( ColPosition == 0 && RowPosition > 0) 
GetDocument()->m_pCQueryBuilder->SelectAxis_Mode = 2;
// on rows
if( ColPosition > 0 && RowPosition < 2) 
GetDocument()->m_pCQueryBuilder->SelectAxis_Mode = 1;
// on columns
if( ColPosition > 0 && RowPosition > 1) 
GetDocument()->m_pCQueryBuilder->SelectAxis_Mode = 3;
// where
HTREEITEM DropHitem = GetApp()->m_TreeItemDrag;
GetDocument()->m_pCQueryBuilder->SetAxis(DropHitem);
} 
}

if( bGridDrag ) 
{
CExceDoc* pDoc = GetDocument();

bGridDrag = FALSE;
int LC = m_FlexGrid.GetMouseCol();
int LR = m_FlexGrid.GetMouseRow();

if ( LC < m_FlexGrid.GetFixedCols() ) LC = m_FlexGrid.GetFixedCols();
if ( LR < m_FlexGrid.GetFixedRows() ) LR = m_FlexGrid.GetFixedRows();
if( (LC == pDoc->StartCol) && (LR == pDoc->StartRow) )
{
pDoc->SetDragEnd(0,0);
pDoc->SetDragStart(0,0);
m_FlexGrid.SetMergeCells(1);
}
else 
{
pDoc->SetDragEnd(LC,LR);
pDoc->SetDragSort();
}

}
}
void CExceView::OnContextMenu(CWnd* pWnd, CPoint point) 
{
// TODO: 메시지 핸들러 코드를 첨가한다.
CMenu muTemp, *pContextMenu;

muTemp.LoadMenu(IDR_MAINFRAME);
pContextMenu = muTemp.GetSubMenu(2);
pContextMenu->TrackPopupMenu(TPM_RIGHTBUTTON|TPM_LEFTALIGN, 
point.x, point.y, AfxGetMainWnd());
}

 

위의 소스에 관해 간단히 설명하면 OnMouseDownGrid()에서 FlexGrid의 시작 행과 열을 변수에 대입하고 OnMouseUpGrid()에서 끝나는 행과 열을 변수에 대입해서 그 범위 안에 있는 데이터를 그래프로 볼 수 있도록 한다. 그리고 OnContextMenu()는 <화면 3>에서 처럼 마우스의 오른쪽 버튼을 클릭했을 그래프를 볼 수 있도록 하는 메뉴가 나타나게 한다.

GraphView 버튼을 누르면 [Bar Graph]가 초기화면으로 나타난다. 그래프를 표현하기 위해서 ChartFX(www.softwareFX.com)라는 액티브X 컨트롤을 사용했다. 그래프의 종류 선택 라디오 버튼에서 바(Bar), 큐브(Cube), 선(Line), 파이(Pie), 버블(Bubble)을 선택해서 각각의 그래프를 볼 수 있다. 또한 그래프 회전 슬라이더(Slider)를 이용해 그래프의 X축, Y축을 회전시켜서 이동시킬 수 있고, 프린트 버튼을 눌러서 그래프, DataEditBox, 범례를 출력해 볼 수 있다

 

BOOL graphdlg::OnInitDialog() 
{
CDialog::OnInitDialog();
// TODO: 또다른 초기화 첨가
SetIcon(m_hIcon, TRUE); // 큰 아이콘 설정
SetIcon(m_hIcon, FALSE); // 작은 아이콘 설정
// 텍스트 범위에서의 버튼
HDC hDC = CreateCompatibleDC(GetDC() -> GetSafeHdc());
HRGN c;
HFONT hFont = CreateFontIndirect(&lf);
HFONT hOldFont = (HFONT) SelectObject(hDC, hFont);
c = CreateRectRgn(0, 0, 0, 0);

int mode = SetBkMode(hDC, TRANSPARENT);
BeginPath(hDC);
TextOut(hDC, 0, 0, “PRINT”,5);
EndPath(hDC);
c = PathToRegion(hDC);
SetBkMode(hDC, mode);

m_Btn5.Create(“”, WS_CHILD | WS_VISIBLE, CPoint(776,605), 
c, this, MY_BTN5, RGB(0,0,255)); 

SelectObject(hDC, hOldFont);
DeleteObject(hFont);
DeleteObject(c);

////////////////////////////////////////////////////////////////
CenterWindow(); 

// 그래프 회전 각도의 범위 설정 
m_X.SetRange(0,360);
m_X.SetPos(45);
m_X.SetTicFreq(10);
m_Y.SetRange(0,360);
m_Y.SetPos(40);
m_Y.SetTicFreq(10);

m_Chart.ClearData(268435455);
m_Chart.ClearLegend(0); // clear value legend 
m_Chart.ClearLegend(3); // clear series lengend
m_Chart.ClearLegend(1); // clear key series lengend
m_Chart.CloseData(1);
// m_Chart.OpenDataEx(1,1,1);
m_Chart.OpenDataEx(1,1,1);

m_pFlexGrid = ((CMainFrame*)AfxGetMainWnd())->
m_pDoc->m_pCPushDataTG->m_pFlexGrid;

int ECol,ERow,SCol,SRow;
int FixedCols,FixedRows;
long Chartlong;
CString ChStr;
CString Buffer;
CExceDoc* pDoc = ((CMainFrame*)AfxGetMainWnd())->m_pDoc;

// FlexGrid에서 선택된 행과 열을 변수에 대입.
FixedCols = m_pFlexGrid->GetFixedCols();
FixedRows = m_pFlexGrid->GetFixedRows();

if( pDoc->LastCol == pDoc->StartCol && pDoc->LastRow == 
pDoc->StartRow )
{
SCol = FixedCols;
SRow = FixedRows;
ERow = m_pFlexGrid->GetRows(); 
ECol = m_pFlexGrid->GetCols();

}
else
{
SCol = pDoc->StartCol;
SRow = pDoc->StartRow;
ERow = pDoc->LastRow+1; 
ECol = pDoc->LastCol+1;
}

// FlexGrid에서 선택된 데이터를 그래프로 표현
for( int i=SCol ; i < ECol ;i++ )
{
m_Chart.SetLegend(i-SCol, m_pFlexGrid->GetTextMatrix
(FixedRows-1,i));
}
for( i= SRow ; i < ERow ; i++)
{
m_Chart.SetSerLeg(i-SRow,m_pFlexGrid->
GetTextMatrix(i,FixedCols-1));
}

for( i=0;i< ERow-SRow;i++) 
{
m_Chart.SetThisSerie(i);
for( int j=0; j < ECol - SCol;j++)
{
ChStr = m_pFlexGrid->GetTextMatrix(i+SRow,j+SCol); 
if( ChStr == “” )
{
Chartlong = 0;
}else
{
for( int k=0;k < ChStr.GetLength();k++)
{
if((ChStr.GetAt(k) != ‘’) && (ChStr.GetAt(k) != ‘,’))
Buffer += ChStr[k];
}
Chartlong = atol(Buffer);
Buffer = “”;
}
m_Chart.SetValue(j,Chartlong);
}
}

m_Chart.SetDataEditor(TRUE); // DataEdition을 표현
m_Chart.SetLegendBox(TRUE); // LegendBox를 표현
m_Chart.SetPointLabels(TRUE); // PointLabels을 표현
m_bar.SetCheck(1); // 바 모양의 그래프를 디폴트로 선택
m_Chart.Refresh(); // 전체적으로 그래프를 리프레시

return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}

 

위 OnInitDialog()는 FlexGrid에서 선택되어진 범위의 데이터를 가지고 그래프를 나타내기 위한 것이다. ChaertFX 컨트롤의 주어진 함수를 이용해 그래프에서 볼 수 있듯이 그래프의 모양을 옵션으로 표현할 수 있으며, 그래프를 회전해 볼 수 있도록 할 수 있다. 그리고 그래프를 보고서로 제출할 수 있도록 하기 위해 프린트 기능도 만들 수 있다.

 

튼튼한 기초를 다지자

지금까지 데이터 마이닝에 대한 기본적인 지식과 데이터 마이닝, OLAP을 구축하기 위한 선처리 단계로써의 데이터 웨어하우스 구축, 그리고 OLAP 시스템의 실제적인 구축에 대해서 알아봤다. 읽는 독자에 따라서는 다소 지루함을 느꼈을 것이라고 생각되지만 튼튼한 기초 지식 아래서 제대로 된 시스템 구축이 이뤄질 수 있다는 것이 필자의 생각이다.

다음 호에서는 본격적인 마이닝 시스템의 구축 중에서도 연관 규칙과 의사결정트리에 대해 알아보고자 한다. 이번 시간에 배운 데이터 마이닝에 대한 지식을 충실하게 읽은 독자라면 우리가 구축한 연관 규칙 알고리즘과 의사결정트리에 대해 조금이나마 도움이 될 것이라 생각한다.

 

데이터 웨어하우스에 대해

데이터 웨어하우스는 전략적인 의사결정 지원용으로 설계됐으며 운영 데이터베이스를 구성하는 데이터베이스를 기반으로 구축됐다. 데이터 웨어하우스의 기본 특징은 매우 커다란 양의 데이터를 포함한다는 것으로 보통 수십 만∼수십 억 개의 레코드를 가진다. 규모가 작고 지역에 국한된 데이터 웨어하우스는 별도로 데이터 마트라고 한다. 데이터 웨어하우스는 기본 구조를 규정하는 특정한 규칙이 있는데 이것은 다음과 같다. 즉 데이터 웨어하우스는 다음의 성격을 지닌 데이터의 집합체를 의미한다.

 

-주제지향성(Subject Oriented)

 

데이터 웨어하우스 내의 데이터는 일상적인 트랜잭션을 처리하는 프로세스 중심 시스템의 데이터와 달리 일정한 주제별 구성을 필요로 한다. 예를 들어 보험회사의 경우 프로세스 중심의 시스템으로는 ‘자동차보험’, ‘생명보험’, ‘개인연금보험’ 등이 해당되지만 이들의 주제영역을 보면 ‘고객’, ‘약관’, ‘청구’ 등이 될 수 있다.

 

-통합성(Integrated)

 

데이터 웨어하우스 내의 데이터는 고도로 통합돼야만 한다. 예를 들어, 기존의 애플리케이션 중심의 환경에서는 남자와 여자를 남/여, Male/Female, 1/0 등으로 다양하게 적용할 수 있으나 데이터 웨어하우스에서는 이들을 통합할 필요가 있다(예, 남자와 여자는 ‘남’과 ‘여’로만 통합).

 

-비휘발성(Non-volatile)

 

데이터 웨어하우스는 오직 두 가지 오퍼레이션(Operation)을 갖게 되는데, 하나는 데이터를 로딩하는 것이고, 다른 하나는 데이터를 읽는 것, 즉 액세스하는 것이다. 이를 달리 표현하면 데이터 웨어하우스에 일단 데이터가 로딩되면 읽기 전용으로 존재한다는 것이다. 따라서 데이터 웨어하우스의 데이터는 오퍼레이셔널 시스템(Operational System)에서 수시 발생되는 갱신이나 삭제 등이 적용되지 않으므로 수시로 변한다는 의미의 ‘휘발성’을 갖지 않게 된다.

 

-시계열성(Time Variant)

 

오퍼레이셔널 시스템의 데이터는 액세스하는 순간에 정확해야만 의미가 있게 된다. 그러나 데이터 웨어하우스의 데이터는 일정한 시간 동안의 데이터를 대변하는 것으로 ‘스냅샷 (Snap Shot)’과 같다고 할 수 있다. 따라서 데이터 구조상에 ‘시간’이 아주 중요한 요소로 작용한다. 이와 같은 이유에서라도 데이터 웨어하우스의 데이터에는 수시적인 갱신이나 변경이 발생할 수 없다.

 

 

데이터 웨어하우스의 기법과 구조

‘하향식(Top Down)’과 ‘상향식(Bottom Up)’으로 알려진 두 가지 기본 기법이 데이터 웨어하우스를 구축하는데 사용될 수 있다. ‘하향식’ 기법에서는 전체 기업에 대한 데이터 웨어하우스를 먼저 구축해 모든 최종 사용자 정보가 저장되는 대규모의 데이터베이스를 만들고, 이것으로부터 특정 부서나 지역 최종 사용자에 필요한 정보가 선택된다.

 

이 데이터베이스에 대해 데이터 마이닝 도구를 사용해 작업을 수행한다. ‘상향식’ 기법에서는 데이터 마트라고 부르는 작은 규모의 지역 데이터 웨어하우스가 질의 목적이나 통계 분석과 같이 지역 요구사항에 적합하게 지역 최종 사용자에 의해 사용된다. 이러한 지역 최종 사용자는 기업 내에서 다른 데이터 웨어하우스에 대해 독립적이다. 지역 데이터 웨어하우스는 빠른 기간 내에 구축될 수 있으며 부서 레벨에서 관리되는데 각 데이터 마트는 데이터 마이닝과 같은 특정한 작업에 완전히 최적화된다. 전사적인 규모의 데이터 웨어하우스는 이것을 토대로 생성된다.

 

데이터 마이닝 기법을 사용하려고 데이터 마트를 구축했다면 사용자는 지역 데이터베이스를 최적화할 수 있다. 먼저 사용자는 하드웨어와 구축된 데이터베이스 요구조건이 이 목적에 적합하다는 것을 확실히 해야 한다. 때때로 많은 시일이 소요된 후에야 모든 정보를 적재하거나 비교하는 것이 가능하게 되며 이 단계에서 데이터베이스와 하드웨어 전문가의 컨설팅을 필요로하기도 한다.

 

-데이터 웨어하우스의 구조

데이터 웨어하우스는 데이터 소스 즉, 관계형 데이터베이스로부터 옆의 박스 기사에서 언급된 성격(주제지향, 통합, 비휘발성, 시계열성)을 가지며, 소스보다는 더욱 정제된 형태의 데이터 집합체로 다시 재구성된다. 이렇게 구성된 웨어하우스는 주제별, 지역별로 존재하는 데이터 마트로 분리된다. 그리고 최종적으로 이것이 데이터 마이닝과 연결된다. 하지만 우리의 자동차보험 프로젝트는 기업이 운영하는 웨어하우스에 비해 양이 적고 단지 자동차보험 대리점을 타겟으로 그 주제와 지역이 ‘자동차보험’이라는 것으로 뚜렷했기에 데이터 마트는 생략하게 되었다. 하지만 보통의 기업에서 마이닝을 시도한다면 다음과 같은 구조로 데이터 웨어하우스와 마이닝이 연결되어져야 할 것이다.

 

데이터 웨어하우스를 구축할 때 최종 사용자와 관리자는 테이블과 항목(또는 애트리뷰트)에 대한 다음과 같은 모든 정보를 접근해야만 한다.

 

◆ 데이터가 저장된 위치

◆ 데이터의 종류

◆ 데이터의 타입과 형식

◆ 다른 데이터베이스에 있는 데이터와의 관련성

◆ 데이터의 출처 및 데이터의 소유자

 

복잡한 데이터베이스 환경에서 적절한 메타데이터는 필수적인데 그 이유는 이것이 운영 데이터와 데이터 웨어하우스의 구조를 모두 결정하기 때문이다. 메타데이터는 질의 목적으로 최종 사용자에 의해 사용되며, 또한 데이터 관리자가 데이터베이스의 관리를 구조화하는 데에도 사용된다.

 

 

참고자료

● Visual C++ 6.0 Bible, 이이표 김병세 공저, 삼양출판사

● Visual C++ 완벽 가이드, 김용성저, 영진출판사

● OLAP 테크놀로지, 조재희 박성진, SIGMA CONSULTING GROUP

● 데이터 마이닝, Pieter Adriaans, Dolf Zantinge

● Fast Algorithms for Mining Association Rules, Rakech Agrawal, Ramakrishnan Srikant

● Mining Generalized Association Rules, Ramakrishnan Srikant, Rakesh Agrawal

● Mining Quantitative Association Rules in Large Relational Tables, Ramakrishnan Srikant, Rakesh Agrawal

● Mining Association Rules between Sets of Items in Large Database

● Neural Networks Theory and Applications, 김대수

● 정보과학회지 제 16권 제 9호(통권 제 112호)

 

필자 연락처 : clearday@hard.korea.ac.kr

정리 : 박준상(jspark@infoage.co.kr)

 

http://www.zdnet.co.kr/develop/backend/db/article.jsp?id=557&page=2&forum=0

[Top]
No.
제목
작성자
작성일
조회
1068SQLite 와 PHP의 연결 [1]
정재익
2005-01-03
17553
461리눅스 쓰레드 프로그래밍
정재익
2002-07-22
15581
177멀티미디어 데이터베이스 기술
정재익
2001-12-14
20446
133비트 파워프로젝트/자동차보험사의 데이터 마이닝 시스템 구축
정재익
2001-12-06
19570
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.049초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다