EN-CORE, ACADEMY, SOLUTION, DATOR - 함께 만드는 데이터 세상!

천천히 가는것이 빠른 것이여~

핫신 — Fri, 10 May 2013 15:40:11 +0900

내가 내가 아니야.

내 목소리가 내 목소리가 아니야.

내 말이 내 말이 아니야.

내가 들어도 들은 것이 아니야.

내 생각이 내 생각이 아니야.

내 마음이 내 마음이 아니야.

내가 내가 아닐 수도 있겠군.

어느 봄날 점심시간. 순간 철학자가 되었다.

내가 말하는 목소리와 녹음한 목소리가 다르다는 것에 대하여 동료와 이야기를 나누다가 꼬리에 꼬리를 물고 생각의 파장이 확장되었다.

위 시를 한줄 한줄 음미해 보면 왠지 철학자? 도사?가 된것 같다. 내가 내가 아니다 ? 한번쯤 고민해 볼 화두 인것 같다.

우리말은 참으로 오묘하여 이치에 맞지 않는 말들이 많이 있다. 어찌 보면 선문답 같기도 하고 상상력이 풍만한 유머 같기도 하고 논리력이 모자란 바보스러운 말 같다.

골프에서 비거리를 늘이려면 힘을 빼고 강하게 쳐야 한다는 말이 있다. 힘빼고 강하게 ? ? ? 어떻게 힘을 빼고 치는데 멀리 보낼 수 있는 것일까? 마음을 비우라는 것인지, 몸의 긴장을 풀라는 것인지, 어깨와 팔 근육을 느슨하게 하라는 것인지 아리송하다. 힘을 주되 힘을 빼라니... 이것 참 난감하다.

천천히 가는 것이 빠른 것이여 ~

이 말도 앞뒤가 맞지 않는다.

"빨리 하는 것이 빠르다. 천천히 하는 것이 느리다." 가 맞는 것 같은데 말이다.

위 말은 프로젝트를 진행할때도 내가 가끔 사용하는 말이다.

천천히 가자.

우왕좌왕 서두르지 말고 천천히 생각을 다듬고, 어떻게 일처리를 진행할 것인지 스토리를 잡아보고, 메모장이나 ppt에 낙서 하듯이 그려본다.

sql을 작성 할때 타닥~ 타타닥~ 타다다다 닥 ! 엔터;

마치 워드 연습하듯이 엄청난 속도로 키보드를 내려친다.

컴퓨터로 글을 쓰다보면 머리가 생각하여 글을 쓰고 있는 것인지? 손가락이 생각하여 글을 쓰고 있는지 모를 때가 있다. 손가락이 생각을 하고 있다.

그런데 가만히 보면 그렇게 열심히 작성한 것은 나중에 변경, 수정, 보완이 계속 이루어지는 경향이 있다. 결국 완료까지 걸리는 시간은 매우 길어진다.

생각하고 고민하여 sql을 천천히 작성해 보자. 천천히 작성하였는데 빨리 마무리되는 신기한 경험을 할 수 있을 것이다.

데이터 모델링 프로젝트를 진행하다 보면 책에 나오지 않는 작업들을 매우 많이 하게 된다. 엔티티와 속성을 정의하고, 관계선을 연결하여 ERD를 작도하는 일만 하는 것이 아니다. 엄연히 프로젝트이기 때문에 작성해야할 PPT, word, xls문서들이 많다. 회의록과 주간보고 문서 만드는 것도 귀찮다. 손이 가야하는 것들이 즐비하다.

예전에 현행 데이터 모델에 대한 표준화 작업을 수행한 적이 있다.

영문으로 구성된 컬럼명을 한글명으로 표준화 적용할 때 엑셀 작업과 함께 관련 데이터를 작업테이블에 입력하고 데이터 조작을 통해 표준검검을 할 때 였다. asis 현행 모델의 컬럼들이 제대로 된 규칙으로 작성 되었을리가 없기 때문에 완료된 컬럼명=속성명이 올바른지 검증을 해 보아야 했다. 4000개 정도 되는 컬럼을 어떻게 검증 할까 ?

a아 b 두명은 서로 2000개씩 검증하기로 하였다. 물론 검증하면서 기존 표준명칭이 잘못 되었으면 수정하면서 진행하기로 하였다. a는 속성들의 패턴, 오류유형을 찾아서 검증 및 수정을 한다. b는 2000개를 엑셀로 옮겨 놓고 하나씩 컬럼명=속성명 파싱 결과를 눈으로 비교한다. 누가 더 빨리 작업을 완료 하였을까 ?

상황에 따라 다르겠으나 위 작업은 b가 더 빨리 더 정확히 끝냈다. a는 임시테이블과 sql을 사용하면서 프로그램 하듯이 잘못된 데이터를 보정처리 하였는데, 그만 중간에 로직들이 꼬여서 검증 완료된 데이터가 오류가 없다는 것을 확신 할 수가 없었다. 왜냐햐면 데이터를 하나하나 보면서 체크 한것이 아니락 이런저런 상황에 맞는 것들을 처리하다 보니까 스스로 품질의 완전성을 믿지 못하였다. 결국 완성된 2000개를 검증하기 위해서 엑셀로 다시 확인하는 작업을 거쳐야먄 했다.

똑똑하고 지혜롭다고 실행한 방식이 묵묵하게 하나씩 차근차근 엑셀을 검토한 방식보다 한참 늦게 마무리 되었다.

그때 a에게 한말히 바로 . . .

천천히 가는 것이 빠른 것이여 ~

가끔 우직하게 천천히 가는 것이 빠른 길이라는 것을 느낀다.

조급해 하지 말고 하나씩 차근차근 풀어 갈 수 있는 지혜의 내공을 계속 쌓아야 겠다.

. . .

2013년 5월 어느 봄날 이천에서 . . .

데이터 이행시 SYSTEM Partition 활용

한 걸음 더! — Thu, 09 May 2013 14:54:08 +0900

데이터 이행은 주어진 이행 시간내에 기존 운영 데이터(ASIS)를 목표 시스템(TOBE)으로 정확하고, 빠르게 적재하는 것이다.

물론, 기존 데이터에 대한 누락이 없어야 하며 잘못된 데이터에 대해서는 바르게 수정해야 함은 기본이다.

특히 대용량 데이터인 경우 전체 이행시간에서 차지하는 비중이 높은 편이다.

따라서 이를 얼마나 빠른 시간내에 완료할 수 있는지가 전체 이행시간을 좌지우지 할 수 있다.

우선 현재 사용하고 있는 이행 아키텍처는 별도의 전환 영역을 사용하고 있으며 자세한 내용은 아래의 URL을 참조하자.

- 참조 URL: http://www.dator.co.kr/hjkim/99700

-> 별도의 전환영역이라 함은 ASIS의 데이터를 바로 TOBE에 이행하지 않고 중간에 레이어를 가져가는 것을 의미한다.

-> 이 경우 데이터 이행은 ASIS의 데이터를 전환영역에 가져온 후, 이 데이터를 기반으로 이행을 수행하여 다시 전환영역에 TOBE 데이터를 생성한뒤 전환 영역에 생성된 TOBE 데이터를 최종 목표 시스템으로 저장하는 구조이다.

-> 불필요한 작업이라 생각할 수 있으나, 여러가지 장점이 있으므로 추천하는 이행 아키텍처이다.

ASIS에서 특정 테이블들은 대용량 데이터이며 다음과 같은 유형이 존재한다.

- 유형1) 대용량의 데이터

- 유형2) LOB 컬럼 포함

- 유형3) 유형1과 유형2가 같이 존재

그리고 위에서 정의한 ASIS의 테이블을 TOBE 테이블로 이행시 여러가지 이유로 파티션을 할 수 없는 상황이다.

- TOBE 테이블은 파티션할 수 있는 키가 없거나, TOBE 에서도 파티션 적용 대상 테이블이 아닐수 있다.

이런 상황에서 TOBE 테이블로 데이터 이행시 아래와 같은 유형으로 이행을 고려해볼 수 있다.

1. 다수의 ASIS 테이블이 하나의 TOBE 테이블로 통합되는 경우

1.1. 통합되는 테이블을 UNION ALL로 묶어서 하나의 SQL로 처리함

- 단점: 대용량 데이터인 경우 TEMP를 사용하는 경우 저장시 성능이 느릴 수 있음

- 장점: PARALLEL, APPEND를 사용할 수 있으므로 TEMP를 사용하지 않는다는 전제가 있다면 매우 빠를 것이다.

1.2. 통합되는 테이블을 테이블별로 각각 분리하여 처리

1.2.1. 순차적으로 처리하는 경우

- TOBE 테이블이 파티션되어 있지 않으므로 PARALLEL, APPEND를 사용하는 경우 순차적으로 수행해야 함

1.2.2. 동시에 실행하는 경우

- APPEND 힌트를 제거하고 동시에 수행해야 하므로 오히려 느릴 수 있음

2. LOB 컬럼을 포함하고 있는 경우

2.1. 전체를 하나의 SQL로 수행

- LOB 컬럼은 PARALLEL이 지원되지 않으므로 여러 SQL을 동시에 수행하는 경우 수행속도가 매우 느려지게 됨

2.2. 프로그램 병렬 수행의 개념으로 여러 개의 JOB으로 나누어 수행

2.2.1. 순차적으로 처리하는 경우

- TOBE 테이블이 파티션되어 있지 않으므로 PARALLEL, APPEND를 사용하는 경우 순차적으로 수행해야 함

2.2.2. 동시에 실행하는 경우

- APPEND 힌트를 제거하고 동시에 수행해야 하므로 오히려 느릴 수 있음

TOBE 테이블이 파티션 되어 있지 않은 상황에서 수행시간을 단축시키기란 쉽지 않다.

이런 경우에 시스템 파티션(http://www.dator.co.kr/data/textyle/97958)을 적용하면 다음과 같은 장점들을 가져갈 수 있다.

1. 예를 들어 ASIS의 테이블 5개가 TOBE에 하나의 테이블로 통합이 되는 경우라면 시스템 파티션을 5개 생성하고 각각 테이블별로 파티션을 지정하여 수행하면 수행속도가 향상된다. 이는 각각의 파티션별로 PARALLEL, APPEND를 사용할 수 있기 때문이다.

2. ASIS가 매우 큰 대용량인 경우 이를 특정 기준으로 분할(ex> 블럭단위)하여 수행하는 경우에도 프로그램 병렬 수행 개수만큼 시스템 파티션을 생성하여 각각 파티션에 저장하게 되면 역시, 수행속도가 향상된다.

3. 전환영역의 데이터를 TOBE에 이관할때도 해당 파티션단위로 PARALLEL을 지정하여 넘길 수 있기 때문에 수행속도를 향상 시킬수 있다. 단, TOBE는 파티션이 아니기 때문에 순차적으로 수행해야 하는 단점은 있다.

(참고) 시스템 파티션을 적용할 수 없다면 테이블을 여러 개로 분할하고 전환 영역에 VIEW를 하나 생성하여 전환영역으로부터 TOBE로 넘기는 것을 고려할수 있다.

세줄 요약.

1. 데이터 이행시 전환영역을 가져가는 이행 아키텍처를 사용한다.

2. 대용량 데이터이지만 TOBE 테이블을 파티션할 수 없는 상황이다.

3. 해당 TOBE 테이블은 시스템 파티션을 적용하고 파티션 단위로 JOB을 쪼개서 동시에 수행한다.

[데이토웹진 7호] 글로벌 기업들이 성공하는 이유, 데이터에 답이 있다

엔코아 — Wed, 08 May 2013 10:18:21 +0900

데이토웹진 7호 - 이메일

글로벌 기업들이 성공하는 이유, 데이터에 답이 있다. . . .(주)엔코아 오창세 이사

엔코아 — Mon, 06 May 2013 15:11:17 +0900

최근 들어 경험과 직관을 조합해 자신의 판단 기준으로 삼는 기업 임원들이 점점 줄어드는 추세다. 자신들의 본능적인 비즈니스 감각에 기댄 의사 결정이 아닌 객관적인 데이터를 활용해 주요 의사 결정을 내리고 있는 것이다.

타블로 소프트웨어(Tableau Software)가 후원한 EIU(Economist Intelligence Unit)의 조사 결과에 따르면, 업무를 처리하고 결정을 내리는 데 있어 데이터에 기반하는 기업들이 실적에서도 우수한 걸로 나타났다. 스스로를 데이터 사용에 있어서 앞서 있다고 평가한 데이터 주도적 문화의 기업들은 재정적 성과에 있어서 타사보다 앞서 있다고 응답한 비율이 3배나 높았다. 이때 높은 실적을 내는 기업 중역들의 76%는 데이터 수집이 아주 중요하거나 절대적이라고 말한 반면, 이들 경쟁사들보다 뒤쳐지는 기업의 중역들 중에서는 절반도 안 되는 42%만이 동일한 응답을 했다.

이처럼 데이터가 기업 성과에 미치는 영향이 결코 작다 할 수 없다. 실제로 유통업의 월마트와 타겟, 운송업의 페덱스와 유피에스, 이커머스 분야의 넷플릭스와 아마존을 비롯해 여행 유흥업의 씨저스 엔터테인먼트(구 하라스 엔터테인먼트), 금융업의 웰스 파고와 캐피털원 등에 이르기까지 전 산업 분야에 걸쳐 데이터 주도형 기업들의 성공적인 부상은 이 접근 방식이 얼마나 경쟁력을 발휘할 수 있는지를 반증해 준다.

그러나 국내 경영진들은 데이터에 입각한 분석적 의사 결정 성향이 강한 편이면서도 단편적으로만 활용하고 있는 모습이다. 해외 글로벌 기업들이 사전 검토 단계부터, 사후 평가에 이르기까지 지속적으로 데이터를 활용하여 점점 더 고도화된 역량을 쌓아 가고 있는 것과는 대조적이다.

어떠한 상황에서도 항상 합리적이고 최적화된 의사 결정을 내리는 사람은 존재하지 않는다는 점을 감안하면 이는 매우 위험한 경영 방식이라고 할 수 있다. 자신의 경험이나 직관에 의존해 의사 결정을 내릴 시에는 눈으로 보이는 것만을 현실이라고 믿는 오류를 범하기 쉽다. 이런 함정에 빠질 경우, 현재 자신이 생각하는 틀 내에서 기존에 보던 방식대로 사물을 바라보게 된다. 즉, 시장, 경쟁사 등 비즈니스 환경을 전체적으로 바라보지 못하고 좁은 시야에서 보게 되어, 의사 결정에 필요한 충분한 정보를 얻지 못하게 되는 것이다. 또한 과거의 패턴이나 추세에 입각하여 현실을 바라보며, 이미 자기에게 익숙한 과거의 대응 방식을 반복하기 쉽다.

막대한 자금이 투입되는 신사업이나 사회•경제적 외부 환경이 복잡한 해외 사업과 관련해 의사 결정을 내릴 경우 경영자가 자신의 직관에 의해 판단하는 것은 매우 위험하다. 정보와 데이터에 기반한 의사 결정만이 위험을 최소화 할 수 있다. 이에 조직 내•외부의 정보를 취합하는 경영 도구, 즉 시스템을 갖춰야 한다.

그러나 시스템의 도입이 ‘만병통치약’이 되어 줄 순 없다. 프로젝트를 수행하다 보면 클라이언트 중 대부분은 데이터의 중요성은 분명히 인지하고 있으나, 비즈니스 가치를 얻기 위해 어디부터 집중해야 하고, 시작해야 될지 감을 잡지 못하거나 어떻게 데이터를 행동 가능한 통찰로 해석해야 하는지 갈피를 잡지 못하는 경우가 허다했다. 현재도 기업에서는 시시각각으로 새로운 데이터를 생성하고, 기업의 정보 시스템은 다양한 종류의 데이터가 저장되어 있지만, 그들을 충분히 활용할 수 있는 기업은 소수에 불과하다.

이는 기업들이 조직 내•외부의 다양한 소스에서 발생하는 데이터를 분석하여 이를 의사 결정에 활용하고자 하는 바람은 갖고 있으나, 정작 데이터를 어떻게 수집하고 분석해서 가치 있는 정보를 추출할지, 생성된 지식을 어디에 활용할 지에 대한 고민이 선행되지 않은 채 무작정 컨설팅을 요청하거나 솔루션부터 도입했기 때문이다. 그리고 무엇보다 전사 차원에서 데이터를 시의 적절하게 활용하고자 하는 문화가 형성되어 있지 못한 탓도 있다. 즉, 조직 내에서 데이터를 공유하지 못하고 역량 축적으로 이어지지 않는 소모적인 데이터 활용에만 그친다는 얘기다.

데이터를 기반으로 기업 경쟁력을 제고하기 위해서는 데이터를 활용한 분석적 접근을 전략의 핵심이라 여기고, 부서 차원이 아닌 전사적 관점에서 내•외부의 데이터를 적절하게 활용하고자 하는 문화가 먼저 형성되어야 한다. 이때 경영자의 마인드 확립이 무엇보다 중요하다.

최고의 경영 전략 애널리스트인 데이븐포트가 경영자의 필수 덕목은 분석이라고 했듯, 경영자가 먼저 솔선수범하여 데이터를 경영 자산으로 생각하고, 전사 차원에서 다각적인 분석에 기초한 의사 결정을 통해 불확실한 시장 경쟁 하에서 위험 요소를 최소화하고 경쟁 우위를 선점해야 할 것이다.

Groovy를 이용해 멀티스레드로 SQL 실행시키기

야옹이다옹멍멍 — Mon, 29 Apr 2013 22:30:48 +0900

Groovy SQL을 둘러봤으니 이번엔 Groovy SQL을 이용해서 만든 스크립트 예제를 하나 보겠습니다.
아래 Groovy 스크립트는 많은 수의 BR검증SQL에 대해서 멀티스레드를 이용해서 동시에 여러개의 SQL을 실행시키게 만든 스크립트입니다. 데이터베이스의 성능이 받춰주는 만큼 스레드 갯수를 조절해서 실행시키면 SQL이 끝나기를 기다리는 시간을 많이 줄일 수 있습니다. 스레드 갯수를 잘못 조정하면 디비를 멈추게 할 수도 있으므로 적절히 조절할 필요가 있습니다. 짧은 코드지만 꽤 다양하게 활용이 가능한 스크립트입니다.

import java.sql.*
import groovy.sql.Sql
import java.util.concurrent.*

/**
* BR 검증SQL을 일괄 실행시켜서 결과값을 확인하기 위한 클래스이다.
*
* @author hkwee
* @since 2012-05-03
*/
class ExecBRSql{
def THREADS = 5

def url = "jdbc:oracle:thin:@127.0.0.1:1521:ora10g"
def userid = "scott"
def passwd = "tiger"
def driver = "oracle.jdbc.driver.OracleDriver"

static void main(String[] args) {
def execBrSql = new ExecBRSql()
execBrSql.execute()
}

private void execute() {
def sql = Sql.newInstance(url, userid, passwd, driver)

def queue = new ArrayBlockingQueue<String>(1000);
def pool = Executors.newFixedThreadPool(THREADS)

def nDq = """
select dq_no, dq_table, br_sql
from n_dq
order by dq_no
"""

sql.eachRow(nDq) { row ->
def sqlDto = new SqlDto()
sqlDto.no = row.dq_no
sqlDto.sql = row.br_sql

queue << sqlDto
}

def item = null

while (item = queue.take()) {
pool.execute(new ExecuteStatement(item))

if (queue.size() == 0)
break
}

pool.shutdown();
}
}

class ExecuteStatement implements Runnable {

def sqlDto = null
def ExecuteStatement(sqlDto) {
this.sqlDto = sqlDto
}

@Override
public void run() {
def url = "jdbc:oracle:thin:@127.0.0.1:1521:ora10g"
def userid = "scott"
def passwd = "tiger"
def driver = "oracle.jdbc.driver.OracleDriver"

def sql = Sql.newInstance(url, userid, passwd, driver)
def THREAD_NAME = Thread.currentThread().getName()
def insertQuery = """insert into temp_n_dq (dq_no, col1, col2, col3, col4, col5, col6, col7, col8, col9, col10)
values (?,?,?,?,?,?,?,?,?,?,?)"""
def vals = new Object[11]
try {
println "[${THREAD_NAME}], ${sqlDto.no} - " + this.sqlDto.sql.replaceAll("\n", "")

sql.query(sqlDto.sql) { rs ->
vals = new Object[11]
def meta = rs.metaData
def isClean = true;
vals[0] = sqlDto.no

while(rs.next()){
for (int i = 1; i <= (meta.columnCount > 10 ? 10 : meta.columnCount); i++) {
vals[i] = rs.getString(i)
}

sql.executeUpdate(insertQuery, vals)
isClean = false;
}

if (isClean) {
vals[1] = "no data"
sql.executeUpdate(insertQuery, vals)
}
}
} catch (Exception e) {
println "[${THREAD_NAME}], ${sqlDto.no} - error : ${e.message}"
sql.executeUpdate(insertQuery, [sqlDto.no, e.message])
} finally {
sql.close()
println "[${THREAD_NAME}], ${sqlDto.no} - finished .."
}
}
}

class SqlDto {
def no
def sql
}

[데이토 웹진6호] BIG DATA 결론은 품질이다

엔코아 — Mon, 29 Apr 2013 16:26:46 +0900

데이토 뉴스레터 6호(웹표준)

하단메뉴: DATOR; ACADEMY; SOLUTION; CONSULTING; EN-CORE; CHINA

본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률에 의거, 메일수신에 동의하신
분에게만 발송되는 메일입니다. 발신 전용이므로 회신하실 수 없습니다. 문의 사항이나
이용 안내는 webmaster@en-core.com으로 남겨주세요.

서울시 영등포구 여의도동 45-21 알리안츠타워 3층
Tel : 02-754-7301 | Fax : 02-754-7305 | e-mail : webmaster@en-core.com

Groovy SQL을 이용한 데이터 핸들링 #3

야옹이다옹멍멍 — Sun, 28 Apr 2013 07:44:54 +0900

이번에는 Groovy SQL의 DataSet에 대해서 알아보겠습니다.

DataSet은 단일 테이블 작업에 대한 작업을 간단히 처리할 수 있게 해주는 편리한 기능입니다.
GORM의 극히 일부 기능을 구현해 놓은 것 같은 느낌이 드는 기능이지만 간단히 사용하기에 편리합니다.
개인적으로는 Grails의 GORM을 그대로 Groovy에서 사용할 수 있었으면 하는 바램이 있지만
아직 공식적으로 GORM을 Groovy에서 그냥 사용할 수 있는 방법은 없습니다.
(약간의 꼼수로 GORM을 Groovy에서 사용할 수는 있습니다.)

앞 강좌에서 사용하던 sql 객체를 가져와서 진행합니다.

def sql = Sql.newInstance('oracle.jdbc.driver.OracleDrive', 'userid', 'passwd', 'jdbc:oracle:thin:@192.168.1.36:1521:ora11g')

다음은 DataSet을 생성합니다.

def emp = sql.dataSet('EMP')

여기서 생성한 emp 객체에 add를 하면 바로 레코드가 추가 됩니다.

emp.add( name: '유재석', job : 'Gagman', birth : '19700101' )

// 복수개의 레코드를 생성할 때
(0..100).each { i ->
emp.add( name: i, job : "job${i}")
}

이런 기능은 좋은데 아쉽게도 dataset에서 update / delete는 지원하지 않습니다.
조회할 때는 다음과 같습니다.

emp.each {
println it.name
}

간단히 emp 테이블에 있는 name 컬럼을 조회해서 출력했습니다.
조건을 줘야 할 필요가 있거나 할때는 findAll 이라는 메서드를 사용합니다.

def rows = emp.findAll {
it.name = '유재석'
}
rows.each {
println it.name
}

다양한 조건이 필요할때는

def rows = emp.findAll { it.name = '유재석' && birth >= '19700101' }
rows.each {
println it.name
}

Groovy SQL에 대해서 간단히 소개를 했습니다. 기본적인 CRUD에 대해 알아봤으니
다음엔 실제로 Groovy를 사용해서 데이터를 처리 하는 코드를 리뷰하도록 하겠습니다.

Groovy SQL을 이용한 데이터 핸들링 #2

야옹이다옹멍멍 — Tue, 23 Apr 2013 23:17:53 +0900

지난 강좌에 이어 이번엔 Groovy SQL의 유용한 기능들을 다음의 순서대로 알아보도록 하겠습니다.

1. 데이터베이스 접속
2. execute (Create / Insert / Update / Delete)
3. eachRow, rows (Select)
4. DataSet

1. 데이터베이스 접속
Groovy SQL에서 데이터베이스에 접속하는 방법은 아래와 같습니다.
def sql = Sql.newInstance([JDBC DRIVER], [ID], [PASSWORD], [JDBC URL])

def sql = Sql.newInstance('oracle.jdbc.driver.OracleDrive', 'userid', 'passwd', 'jdbc:oracle:thin:@192.168.1.36:1521:ora11g')

기존 어플리케이션에서 WAS를 사용하고 있고 사용하는 Data Source가 있다면

def sql = Sql.newInstance(dataSource)

기존에 사용하던 Connection 객체가 있다면

def sql = Sql.newInstance(connection)

이런식으로 넣어주면 됩니다.
#. execute (Create / Insert / Update / Delete)
  위에서 생성한 sql 객체를 이용해서 진행을 합니다.
  * create 구문의 사용

sql.execute('''
create table t1 (
col1 varchar2(100)
,col2 varchar2(100)
)
''')

간단하죠? 그런데 작은 따옴표를 3개 연달아 사용하고, 줄바꿈을 해주고 있습니다.

Groovy에서 지원하는 문자열 형식입니다. 덕분에 문자열 처리가 상당히 쉬워졌습니다.
* insert 구문의 사용

sql.execute('''
insert into t1 (col1, col2) values ('유재석', '유느님');
insert into t1 (col1, col2) values ('박명수', '2인자');
insert into t1 (col1, col2) values ('정준아', '식신');
''')

insert 구문도 마찬가지로 간단합니다. prepare 방식으로 넣고 싶을때는 아래와 같이 사용합니다.

def insertSql = '''
insert into t1 (col1, col2) values (?, ?);
'''
sql.execute(insertSql, ['유재석', '유느님'])
sql.execute(insertSql, ['박명수', '2인자'])
sql.execute(insertSql, ['정준아', '식신'])

update, delete도 동일한 방법을 사용합니다.

sql.execute("update t1 set col2 = '1인자' where col1 = '박명수'")

배치작업이 필요한 경우에는 anonymous pl/sql block으로 작성하는 것보다 코드량을 훨씬 줄일 수 있습니다.

* select
select에는 insert보다 좀 더 다양한 메서드가 지원되고 Closure를 최대한 활용합니다.
- eachRow

sql.eachRow('''
select * from t1
''') { row ->
println row.col1
// 여기서 필요한 처리를 하면 됩니다.
}

select한 결과를 출력하는 코드가 몇줄 안됩니다. 조건을 주고 싶을때는 아래와 같이 처리합니다.

sql.eachRow('''
select * from t1 where col1 = ?
''', ['유재석']) { row ->
println row.col1
}

또는

def name = '유재석'
sql.eachRow('''
select * from t1 where col1 = ${name}
''') { row ->
println row.col1
}

closure에 익숙하지 않다면 다음과 같이 rows를 이용해도 됩니다.

def list = sql.rows('select * from t1')

조건을 주고 싶을때는 이렇게 하면 됩니다.

def list = sql.rows("select * from t1 where col1 = ${col1}")
for (def row : list) {
println row.col1
}

뭔가 자동화된 작업을 하려고 할때는 DBMS의 메타데이터를 활용해야 할 경우가 자주 있습니다.
select 쿼리 결과의 메타데이터를 가지고 작업해야 할 경우에는 다음과 같습니다.

sql.query('select * from t1') { rs ->
def meta = rs.metaData
for (i in 0..<meta.columnCount) {
println "${meta.getColumnLabel(i + 1)} / ${rs.getObject(i)}"
}
}

"${}" 문자열은 GString에서 지원하는 특별한 기능입니다.

이번 강좌는 여기까지입니다. DataSet은 다음 강좌에서 알아보도록 하겠습니다.

테이블명 입력으로 컬럼 목록, 코멘트가 추가된 select 쿼리를 출력하는 스크립트

야옹이다옹멍멍 — Tue, 23 Apr 2013 22:38:55 +0900

인스턴스 차트를 만들때 유용하게 사용할 수 있는 스크립트입니다.
아래 코드는 코드 컬럼에 대해서 코드명을 찾는 스칼라 서브쿼리와 컬럼 코멘트가 추가된 select sql을 만들어 주는 코드입니다. 각자 환경에 맞게 조금만 수정하시면 유용하게 사용하실 수 있을 겁니다. 단 코드명을 찾는 스칼라 서브쿼리를 사용하기 위해서는 컬럼에 대한 표준화 작업이 되어있는 상태여야 합니다.

SET SERVEROUTPUT ON
spool select.sql
declare
   l_sql        varchar2 (30000);
   l_column     varchar2 (30000);
   l_where      varchar2 (1000);
   l_idx        number := 0;
   l_scheme     varchar2 (100) := 'SCOTT';
   l_tab_name   varchar2 (100) := '&tname';
   l_comma      varchar2(100);
l_cd_grp_id varchar2(10);
begin
dbms_output.put_line ('--------');
   dbms_output.put ('select ');

   l_sql := 'select ';
   for l_tab in (select a.table_name, a.column_name, b.comments
                   from all_tab_cols a, all_col_comments b
                  where 1 = 1
                    and a.table_name = b.table_name
                    and a.column_name = b.column_name
                    and a.owner = upper(l_scheme)
                    and b.owner = upper(l_scheme)
                    and a.table_name = upper(l_tab_name)
                  order by a.column_id)
   loop
      if l_idx = 0
      then
        l_comma := '';
      else
         l_comma := '      ,';
      end if;
   if l_tab.column_name like '%CD'
   then
     begin
     select cd_grp_id into l_cd_grp_id
        from cd_grp_info
      where cd_grp_nm = l_tab.comments
        and efct_end_dt = TO_DATE ('99991231', 'YYYYMMDD');
    exception
     when others then
      l_cd_grp_id := '0000';
    end;

       dbms_output.put_line (l_comma||'a.' || lower(l_tab.column_name)||'|| ');
    dbms_output.put_line ('''(''||'||'(select cd_nm from cd_info ');
    dbms_output.put_line ('where cd_id = a.'||lower(l_tab.column_name));
    dbms_output.put_line (' and efct_end_dt = TO_DATE(''99991231'', ''YYYYMMDD'') ');
    dbms_output.put_line (' and cd_grp_id = '''||nvl(l_cd_grp_id,'0000')||'''');
    dbms_output.put_line (')||'')'' '||lower(l_tab.column_name)||' -- '|| l_tab.comments);
   else
       dbms_output.put_line (l_comma||rpad('a.' || lower(l_tab.column_name), 40, ' ') ||' -- ' || l_tab.comments);
   end if;

      l_idx := l_idx + 1;
   end loop;
   dbms_output.put_line (' from ' || l_tab_name || ' a ');
   l_idx := 0;
   for l_cons in ( select b.table_name
                          ,b.constraint_name
                          ,a.column_name
                          ,a.position
                      from all_cons_columns a, all_constraints b
                     where 1 = 1
                       and a.constraint_name = b.constraint_name
            and a.owner = upper(l_scheme)
            and b.owner = upper(l_scheme)
                       and a.table_name = upper(l_tab_name)
                       and b.table_name = upper(l_tab_name)
                       and b.constraint_type = 'P'
                  order by 1, 2, 4)
   loop
      if l_idx = 0
      then
         dbms_output.put_line (' where 1 = 1');
      end if;
      dbms_output.put ('   and ');
      dbms_output.put_line (lower(l_cons.column_name) || ' = :' || lower(l_cons.column_name));
      l_idx := l_idx + 1;
   end loop;
   dbms_output.put_line (';');
end;
/
spool off
SET SERVEROUT OFF

Groovy SQL을 이용한 데이터 핸들링 #1

야옹이다옹멍멍 — Sat, 20 Apr 2013 23:27:35 +0900

Groovy SQL에 대해서 간단히 소개해 보겠습니다.

우선 Groovy 가 무엇인지 모르는 분들도 계실텐데.. Groovy는 자바 기반의 스크립트 언어입니다.

그리고 Groovy를 이용해서 작업을 하면 짧은 코드로 많은 일을 할 수 있어서 간단한 작업을 하기 위해 필요했던 많은 코드들로부터 벗어날 수 있어 작업이 즐거워집니다. 자바에서 사용되는 모든 클래스를 활용할 수 있고 컴파일된 Groovy 클래스는 자바에서도 호출해서 사용이 가능합니다. 제가 처음 Groovy를 접한 것은 3년전쯤 소수의 인원으로 짧은 기간에 많은 양을 구현해야하는 프로젝트에서 단순작업을 줄이고 개발기간을 단축할 목적으로 Grails를 도입하면서 Groovy를 사용하게 되었는데 기대이상의 효과를 봤었습니다. Closure, GORM의 Dynamic Finder, Criteria, 다양한 Builder들.. Grails에 대해서도 하고 싶은 얘기가 많지만 다음에 좀 더 시간이 있을때 소개를 해보겠습니다.
(Grails는 Spring Framework으로 유명한 SpringSource에서 인수해서 진행하고 있습니다.)

오늘 소개할 Groovy SQL은 소개할게 많지는 않지만 활용할 분야는 많은 기능입니다.
자바의 jdbc를 이용해서 데이터 조작을 해야하는 경우에 대부분은 귀찮은 코드들 속에서 실제로 작업할 코드는 얼마 되지 않습니다. 그래서 spring jdbc 라던지, 개별적으로 helper 클래스들을 만들어서 사용하게 되는데요. Groovy를 사용하면 그런 귀찮은 작업들에서 벗어나 필요한 부분에 더욱 집중할 수 있습니다.

아래 두 코드를 한번 비교해 보시죠.

java의 jdbc를 이용한 처리

Class.forName("oracle.jdbc.driver.OracleDrive");
PreparedStatement pstmt = null;
ResultSet rs = null;
try {
conn = DriverManager.getConnection("jdbc:oracle:thin:@192.168.1.36:1521:ora11g", "userid", "passwd");
StringBuffer sqlsb = new StringBuffer();
sqlsb.append("\n SELECT ROWNUM rnum, table_name                       ");
sqlsb.append("\n   FROM ( SELECT table_name                          ");
sqlsb.append("\n             FROM user_tables                         ");
sqlsb.append("\n            WHERE table_name LIKE '%'||UPPER(?)||'%' ");
sqlsb.append("\n         ORDER BY table_name)                         ");
sqlsb.append("\n WHERE ROWNUM <= ? ");
String tableName = "EMP";
int limit = 30;
int idx = 1;
pstmt = conn.prepareStatement(sqlsb.toString());
pstmt.clearParameters();
pstmt.setString(idx++, tableName);
pstmt.setInt(idx++, limit);
while (rs.next()) {
System.out.println(" Table Name : " + rs.getString("TABLE_NAME"));
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (SQLException e) {
e.printStackTrace();
} finally {
if (rs != null) {
try {
rs.close();
} catch (Exception e) {
} finally {
rs = null;
}
}
if (pstmt != null) {
try {
pstmt.close();
} catch (Exception e) {
} finally {
pstmt = null;
}
}
if (conn != null) {
try {
conn.close();
} catch (Exception e) {
} finally {
conn = null;
}
}
}
return list;
}

실제로 하는 일은 select 쿼리 결과를 단지 출력만 하는 것인데 코드량이 상당합니다.

Groovy SQL을 이용한 처리

def sql = Sql.newInstance('oracle.jdbc.driver.OracleDrive', 'userid', 'passwd', 'jdbc:oracle:thin:@192.168.1.36:1521:ora11g')
def tableName = 'EMP'
def limit = 30
sql.eachRow("""
SELECT ROWNUM rnum, table_name
FROM ( SELECT table_name
FROM user_tables
WHERE table_name LIKE '%'||UPPER(?)||'%'
ORDER BY table_name)
WHERE ROWNUM <= ? """, [tableName, limit]) { row ->
println "Table Name : ${row.table_name}"
}
}

음.. 그루비는 짜다 말은 것인가? 아닙니다. 코드양이 너무 적은데? 하지만 실행시키면 자바로 코딩했을때와 동일한 결과를 출력해 줍니다.
이런 코드가 가능한 것은 그루비가 지원하는 Closure와 GString이라는 기능 덕분입니다. Closure를 이용하면 리소스 관리를 별도로 하지 않아도 되고, 메서드로 분리해야할 작업들도 간단히 Closure로 구현할 수 있습니다. 그리고, 강력한 문자열 처리기능을 지원하는 GString은 귀찮은 문자열 작업을 상당히 많이 줄여줍니다.
프로젝트를 진행하다보면 여러가지 다양한 방법으로 데이터를 처리해야 할 경우가 많은데 늘 시간은 부족하고 때로는 SQL이나 PL/SQL만으로 처리하기에는 어려운 작업들이 있습니다. 그렇다고 일반적인 프로그래밍 언어로 작업하기엔 부담스럽고..

그럴때 그루비를 사용하면 상당한 효과를 볼수 있습니다. 잘 보셨나요? Groovy SQL을 간단히 보여드렸습니다.

다음 글에서 Groovy SQL을 본격적으로 사용해 보겠습니다.

입출고.In/Out.수량관리

핫신 — Wed, 17 Apr 2013 23:32:20 +0900

데이터의 입력, 출력을 살펴 본다.

데이터 모델링을 하면서 가장 난해한 부분은 이벤트, 트랜잭션과 같은 테이블을 설계하는 일인것 같다. 마스터 데이터들은 집합의 개체가 구체적으로 정의되어 있고 고유의 특성을 표현하는 속성들도 구체적으로 알 수 있다. 데이터가 많이 발생하고 빈번한 트랜잭션을 관리하는 테이블들은 구조만을 갖고서는 도대체 어떻게 데이터를 관리하고 있는지 그 속내을 알아 채기가 쉽지 않다.

대부분 시스템에서는 입력과 출력, Input과 Output에 대한 이벤트를 관리하는 테이블들이 하나씩은 있을 것이다.

대표적인 것들이 재고관리에서 사용하는 입출고관리, 영업시스템의 매입과 매출, 은행에서의 입금과 출금, 쇼핑몰에서의 마일리지 추가/사용 등등 많은 영역에서 IN / OUT에 대한 수량관리를 하고 있다. 그러나 수량 관리 방식은 참으로 다양하다. 사이트마다 관리 방식이 다름에도 불구하고 동일한 비즈니스를 처리하고 있는 것이 놀랍고 신비스럽다.

먼저 INPUT과 OUTPUT의 개념을 매우 단순화 시킨 시나리오를 바탕으로 데이터 흐름, 데이터 발생방법, 테이블설계를 하나씩 알아보도록 한다.

[ 그림1 : 입출고 Input Output 시나리오 ]

그림1에는 사과 BOX에 사과가 투입되었다가 판매되고 남은 사과를 다른 BOX에 이동하는 것이 표현되어 있다. [ 투입 >> 판매 >> 이동 ] BOX는 수량관리가 이루어지는 지점, 위치, 창고, 계좌 등으로 비유 될 수 있다. 사과는 수량관리가 이루어지는 대상물로서 재료, 자재, 부품, 돈, 쿠폰, 마일리지, 상품 등이 될 수 있다.

이벤트는 크게 6개가 발생된 시나리오를 만들어 보았다. 1) 처음 100개의 사과가 box 1에 투입되었다. 이 사과는 시간이 지남에 따라 box에서 판매되어 소비된다. 또한 남은 사과는 다른 box로 이동을 하게 된다. 이동은 위치 --> 위치로의 물류 이동과 흡사하다. box와 사과 사이에 엄청난 변화가 발생되고 있는데 우리는 다음과 같은 비즈니스 적인 질문을 던질 수 있다.

각 BOX에 남아 있는 재고 수량은 도대체 몇개 인가 ?

어느 BOX에서 판매가 가장 많이 이루어 졌는가 ?

BOX들간의 물물 교류가 가장 왕성하게 발생한 연관 box 들의 쌍으 어떤 것이지 ?

위 질문을 위해 간단하게 정리한 수량변화 이벤트 그림을 보자

[ 그림2 : 입출고 도식화 ]

먼저 위 6개의 시나리오를 1개의 그림으로 요약해 보았다. 각 box에서 발생한 수량의 변화와 재고, 판매 수량을 살펴 보길 바래요..

위 시나리오를 단순한 그림으로 도식화 해 보았다.

각각의 BOX에는 사과가 들어 왔다 나갔다를 반복하고 있다. 들어오는 부분은 INPUT, 입고, FROM에 해당하고 나가는 부분은 OUTPUT, 출고, TO에 해당한다. BOX는 내부적으로 사용,판매와 같은 이벤트가 발생한다. 이는 마치 수학에서의 함수 f(x)와 같다는 생각이 든다.

BOX에는 현재 몇개의 사과 재고가 남아 있냐는 것이 중요한 팩터이다. 또한 어느 BOX에서 판매가 가장 왕성하게 이루어졌나를 알아 볼 수도 있다.

100개 투입된 사과는 BOX3에 20개, BOX4에 20개 남아 있다. 판매된 사과는 총 60개 이다.

입고 + 이전재고 = 판매 + 출고 + 재고 : 공식을 눈 여겨 보자.

이 공식은 BOX 관점에서의 수량을 관리하는 공식이다. 제품의 수불관리에서 이와 유사한 공식이 사용된다.

입고 > BOX에 투입되는 수량이다.

이전재고 > 시점(이벤트) 별로 수량관리를 할때, 바로 직전의 재고수량이 다음 데이터의 이전재고수량이 된다. 무슨 의미인지 궁금하면 다음에 나오는 예시 데이터를 보면 알 수 있을 것이다.

판매 > BOX에 있을때 사용되거나, 소모되거나, 판매된 수량이다.

출고 > 다른 BOX로 이동 되었을때는 출고가 된다.

재고 > 총투입수량 - 총사용수량에서 남은 수량이 된다. 즉 "잔여수량"이다. 다른 의미로는 "판매가능수량"이라고도 불린다.

데이터 발생 ~~

이제 시나리오를 바탕으로 데이터를 발생시켜 보자. 1개의 시나리오에는 숨겨진 여러개의 이벤트들이 있으니 유의해야 한다. 6개의 시나리오니까 6건의 발생 데이터가 있을까요 ? 우선 데이터를 발생시키는 방법에는 몇가지가 있는지 살펴 보자.

데이터 1) 사과관점의 from ~ to 방식으로 데이터를 1건씩 발생 시킬 수 있다.

- 사과 100개가 box1에 투입되었다.

- 사과 50개가 box1에서 box2로 이동 하였다.

- 사과 30개가 box1에서 판매(소비) 되었다.

- 사과 20개가 box2에서 box3로 이동였다.

데이터가 발생한 그 시점의 이벤트를 그대로 기술한 듯이 데이터를 발생하면 된다. 아주 직관적이다. 특징은 사과 관점에서 이벤트를 정의하고 있다는 것이다.

[ 데이터 1 : 사과관점 from ~ to 입출고 1줄]

예시 데이터를 오른쪽의 도식이미지와 함께 대칭시켜 보면 쉽게 이해 할 수 있을 것이다. 사과 관점에서 이벤트를 정의하였기 때문에 box관점에서는 from box와 to box 필드를 모두 보아야만 box이벤트가 어디에 있는지 알수 있다. from --> f(x) --> to 라는 수식이 발생하는데, 여기서 f(x)는 시간이라고 볼수 있다. 함수처리를 위한 지연 시간이 없다고 간주한다. 마치 갑이 을에게 사과를 주는데 건네 주는 시간은 0.1초 정도 소요 될 것이다. 따라서 from일시 = to일시 = 이벤트일시 라고 보아도 무방할 것이다.

데이터 2) BOX관점의 from ~ to 방식으로 데이터를 2건씩 발생 시킬 수 있다.

- box1에 사과가 100개 투입되었다.

- box1에서 사과가 50개 출고되었다. 어디로? box2로

- box2로 사과가 50개 투입되었다. 어디에서? box1에서

- box2에서 사과가 30개가 판매(소비) 되었다.

- box2에서 사과가 20개 출고되었다. 어디로? box3로

- box3에서 사과가 20개 투입되었다. 어디에서? box2에서

첫번째 데이터 방법 보다는 조금 더 복잡해 보이는 이벤트 설명이다. 그러나 천천히 읽어 보면 아주 직관적이다. 특징은 box 관점에서 이벤트를 정의하고 있다는 것이다.

[ 데이터2 : box관점 이벤트 입출고 2줄]

여기에서도 from --> f(x) --> to 라는 수식이 발생하는데 f(x) 함수 처리시간이 약간 있다는 느낌이 든다. 왜냐하면 들어왔다, 나갔다를 box 단위에서 바라보기 때문에 사과가 전달되는 시간이 오래걸렸을 것이라고 상상된다. 마치 from box와 to box는 매무 먼 거리에 위치해 있어서 전달(운송)하기 위해서 별도의 기구를 사용하였을 것이다. 그러니 이동에 걸린 시간이 있었을 것이고 from일시 = 이벤트일시, to일시 = 이벤트일시 이지만 from일시 <> to일시 이다. 따라서 소요일시 = to일시 - from일시 라는 공식도 발생할 거라는 것을 알 수 있다.

보통 input --> output 의 데이터는 위 2가지 방식으로 구현 될 수 있다. 비즈니스에 따라 적절한 방식을 선택하는 것이지 어느 방식이 옳고 틀리다를 논할 수는 없다. 그럼 다른 방식의 데이터 처리방법은 없을까? 를 고민해 본다. 위에서 입고 + 이전재고 = 판매 + 출고 + 재고라는 공식을 소개한 것을 눈여겨 보자. 이벤트마다 수량의 변화가 발생하였으면 5개의 정보는 어딘가에는 있을 것인데 해당 공식을 뒷받침해주는 데이터가 직관적으로 나타나지 않는다. 이 데이터는 어디에 숨어 있는 것일까 ? 이벤트가 발생할때마다 위 공식의 수량을 알고 싶다면 어떻게 구현해야 할까? 뭐 데이터를 지지고 볶으면 어떻게 든지 만들어 낼 수는 있을 것이다.

이제 또 다른 3 방식의 데이터 발생 방법을 생각해 보자

데이터3) BOX관점의 from ~ to 방식으로 데이터를 2건씩 발생 시킬 수 있다. > 상세한 부가속성을 관리한다.

- box1에 사과가 100개 투입되었다. 재고는 10개이다

- box1에서 사과가 50개 출고되었다. 어디로? box2로 총 100개에서 50개 출고되고 재고는 50개이다

- box2로 사과가 50개 투입되었다. 어디에서? box1에서 50개가 투입되어서 재고는 50개이다

- box2에서 사과가 30개가 판매(소비) 되었다. 총 50개에서 30개가 판매되어서 재고는 20개이다.

- box2에서 사과가 20개 출고되었다. 어디로? box3로 총 20개에서 20개가 출고되어서 재고는 0개이다.

- box3에서 사과가 20개 투입되었다. 어디에서? box2에서 20개가 투입되어서 재고는 20개이다.

세번째 데이터 방법은 두번째 방식고 동일하다. 다만 수량의 종류를 좀 더 상세하게 관리하고 있다. 하나의 이벤트에는 input와 output이 함께 공존한다. 이벤트수량 1개의 속성이 입고수량, 이전재고수량, 사용수량, 출고수량, 재고수량 5개로 관리되고 있다. 데이터 관리는 좀 복잡해 보이지만 이벤트 시점의 수량 변화를 직관적으로 알 수 있다는 장점이 있다. 일종의 계산용 추출속성을 관리하는 방식이다.

[ 데이터3 : box관점 이벤트 입출고 2줄 부가속성]

세번재 방식을 응용하면 일별, 월별, 년별 재고수량을 쉽게 관리할 수도 있다. 물론 중간에 데이터가 뻑~이 나더라고 원인파악을 하거나 원상복귀 하는게 용이 하겠다.

그럼 마지막으로 위 세가지 방식을 데이터모델로 구성해 보자. 여기까지 개념과 데이터 발생규칙을 자세히 살펴 보았다면 아래 제시된 데이터 모델은 금방 이해 할 수 있을 것이다. 사과 개체집합은 생략되어 있다. box에서 관리하는 물품이 여러개 라면 "상품" 테이블을 만들고 box수량이력에 해당 상품번호를 연결(관계)시키면 될 것이다.

[ 데이터 모델 ]

다시 한번 말하지만 이벤트, 이력, 트랜잭션, 변화와 같은 데이터 모델링시에는 비즈니스 규칙에 따른 데이터 발생규칙을 이해해야만 완성도 놓은 데이터 모델이 된다. 이런 모델에는 반드시 시나리오별 예시 데이터를 만들어 주어야 개발시 혼선을 줄일 수 있을 것이다.

다만 모델링 프로젝트에서 1인당 감당해야 할 분량이 무지막지하게 많아서 개념을 구상하고 예시 데이터를 만들고 데이터 모델에 데이터를 흘려 보면서 테이블을 만들수 있는 시간이 절대 적으로 부족하다는 것이 안타깝도다. ! 그래도 포기하지 말고 순서대로 차근차근히 시도해 보는 것이 데이터를 사랑하는 사람의 본분일 것이라고 생각한다.

" 매일 매일 조금 씩 강해 지자 " 천 천 히 . . .

자판기 데이터모델 시나리오 #2

핫신 — Fri, 12 Apr 2013 00:14:49 +0900

자판기와 관련된 데이터 모델을 설계해 봅니다. ( 계속 )

두번째는 주어진 사물에 대한 추상화를 통해서 개념적으로 재 구성해 보는 방식을 택할 것이다. 단순하고 확장성이 보장된 형태이다. 이해를 돕기 위해서 재료를 투입하는 것을 좀 단순하게 표현해 보도록 한다.

< 두 번째 모델링 : 개념적 추상화 >

[그림 1]

첫번째 모델링에서와 동일한 자판기 실물과 개념도이다. 그러나 이제 데이터 모델이 좀 바뀌었다. 가장 큰 특징은 자판기슬롯 엔티티에 "슬롯번호"라는 속성일 것이다. 자판기의 콜라, 사이타, 커피를 꽂을 수 있는 투입구를 속성으로 형상화 하지 않고 슬롯이라는 개념으로 추상화 하였다.

자판기는 여러 개의 슬롯을 가질수 있다. 이 슬롯은 자판기에 따라 1개 혹은 수십개를 가질 수가 있을 것이다. 또한 슬롯마다 어떠한 재료를 투입하여도 된다. 1번 슬롯에서 콜라를 판매하다가 사이다로 상품을 교체 할 수도 있고, 심지어 커피로 교체할 수도 있는 구조이다. 매우 유연하고 확장성있는 모델임에는 틀림없다.

재료 > 첫번째 모델의 재료 테이블과 동일하다.

자판기 > 첫번째 모델의 자판기와 동일한 개체를 관리한다. 다만 콜라, 사이다, 커피, 율무, 껌, 초코릿 속성들이 사라졌다. 개체와 관련없는 속성들이 사라짐으로 인해 자판기 본연의 속성만을 지니게 되어 매우 단순해 졌다.

자판기 슬롯 > 자판기의 슬롯구성을 나타내고 있다. 재료ID는 현재 슬롯에 세팅되어 있는 재료이다. 콜라가 세팅되었다가 사이다 판매로 변경된다면 재료ID는 UPDATE 될 것이다.

자판기 이력 > 자판기에 재료가 투입될때와 재료가 판매되었을때의 이력이 보관된다. 즉 INPUT과 OUTPUT의 데이터가 누적된다. 슬롯이라는 것을 발견함으로 인해서 많았던 이력의 속성들도 매우 단순하게 변경되었다. 재료수량은 투입되거나 사용되어진 수량을 의미한다.

이 모델만 보고서 어떤 데이터가 어떻게 발생되겠구나를 짐작 할 수 있지 않은가 ?

이제 데이터를 발생시켜 보겠다.

[ 데이터 예시 1 ]

재료 > 첫번째 모델의 데이터와 같은 형태이다. 콜라의 총수량 50, 자판기에 30개가 투입되었고 현재 20개를 여유분으로 갖고 있다.

자판기 > 자판기는 JA-10, JA-20 2대가 있다. 매우 단순한 데이터 구조임을 알 수 있다.

자판기 슬롯 >

JA-10 자판기는 투입구가 2개 짜리이기 때문에 슬롯번호1, 2 가 있다. JA-10에서 현재 판매하는 재료는 콜라와 사이다이다.

JA-20 자판기는 투입구가 2개 짜리인데 1번은 콜라용 슬롯이고, 2번은 커피용 슬롯이다. 커피의 재료는 밀크커피, 블랙커피가 있는데 현재는 밀크 커피용으로 사용되고 있다. 이력 데이터를 보면 블랙에서 밀크로 용도 변경되었음을 알 수 있다. 만약 슬롯에서 어떤 재료가 판매 되었었나를 이력으로 관리할 필요성이 있다면 PK를 "자판기번호 + 슬롯번호 + 시작일시 + 종료일시"로 변경하면 될 것이다. 여기서는 이력까지는 관리 할 필요가 없다고 가정해 둔다.

[ 데이터 이력 1 ]

자판기는 JA-10에는 IN, OUT 구분자로서 투입, 출력을 알 수 있다. IN일 때는 콜라 10개, 사이다 10개가 동시에 투입되었다. 슬롯별로 판매 순번을 취하고 있다. 동시에 콜라 + 사이다가 판매된다면 2개의 데이터를 발생시키는 형태이다.

데이터를 ROW 형태로 발생시키고 있기 때문에 사용량, 재고량을 구하기가 더 간편해 진다.

> 이력 테이블의 SUM( IN ) = 콜라 10개, 사이다 10개

> 이력 테이블의 SUM( OUT ) = 콜라 5개, 사이다 3개

> 현재 JA-10 자판기의 재고 = 콜라 10개 투입 - 콜라5개 판매 = 5개 재고

첫번째 모델 처럼 "자판기" 테이블에 재고(잔고) 컬럼이 반정규화 되어 관리되고 있다.

데이터를 row 형태로 변환하여 관리함으로써 데이터 모델의 유연성과 확장성이 보장되었음을 알 수 있다.

[ 두 모델 정리 ]

첫번째 #1 모델은 컬럼형태의 모습이고, 두번째 #2 모델은 ROW형태의 모습이다.

첫번째 모델의 반복적인 컬럼들을 정규화하여 분리한 모습이 두번째 모델형태 이다.

첫번째 모델이 더 단순하고 편리해 보이고, 두번째 모델이 복잡하고 어려워 보이는가 ? 속성이 모델에 나열되어 있는 것이 단순한 형태는 아니다. 실제 현장에서 사용되고 있는 테이블에는 100여개의 컬럼들이 있는데 이 컬럼들의 용도와 목적을 모를 때가 종종 있다. 프로세스별로 발생하는 속성들을 나열하면 무슨 정보가 있는지는 알겠지만 데이터 발생규칙과 구조적인 모습을 파악하기는 매우 난해 하다. 보통 이런 경우에는 데이터가 존재해야할 구조적인 위치를 잡아 주어야 되는데 이것은 "정규화"를 통해서 이루어 질 수 있다.

첫번째 #1 모델의 데이터는 지정된 컬럼의 값 유무에 따라 in/out이 발생한 것을 알수 있고, 두번째 #2 모델은 재료ID 컬럼에 있는 값을 보고서 어떤 재료인지를 판단 할 수 있다. 데이터 모델링에 익숙하지 않거나, 엑셀형태를 그대로 테이블로 설계하는 사이트에서는 종종 첫번째 형태의 테이블들이 설계되곤 한다. 왜냐하면 데이터가 입력되어질 필드가 속성(컬럼)으로 이미 지정되었기 때문에 더 편함을 느끼는 것 같다.

첫번째 #1 데이터 모델을 보고서 두번째 #2 데이터 모델로 과감하게 개선해야 겠다는 것을 어떻게 알아 낼 수 있었을까 ? ? ?

실제로는 매우 어려운 일이다. 1안을 2안으로 변경해야 한다는 것은 알겠지만 처음부터 2안을 생각해 내지는 못 할 것이다. " 왜 그럴까? 이상한데 ? 무언가 꼬인것 같아 ?" 라는 질문과 의문을 계속 품고 있는 모델러만 알아챌 수 있다고 생각된다. 데이터 모델에서 관리하는 개체의 실제 모양새와 이 물체들의 개념적이고 추상적인 구조를 연구해 보아야만 2안 처럼 "슬롯" 이란 개념을 만들어 낼 수 있을 것이다. 또한 다양한 경험력도 필요하겠다.

상상력과 창의력을 키워야 겠다. ;;;;

자판기 데이터모델 시나리오 #1

핫신 — Thu, 11 Apr 2013 00:06:03 +0900

자판기와 관련된 데이터 모델을 설계해 봅니다.

< 목적>

우리 주변에서 있는 사물들에서 발생하는 이벤트를 데이터 모델로 어떻게 형상화 되는지 살펴 본다.
데이터의 입력/출력, 입고/출고, Input/Output이 어떻게 구현될 수 있는지 살펴 본다.
보이는 대로 모델링 방식과 추상화한 모델링의 방식을 살펴본다.

< 시나리오 >

우리가 관리하는 자판기는 여러 종류가 있다.
자판기에서 판매하는 재료는 음료수캔, 커피, 과자, 생활용품 등이다.
어떤 자판기는 음료수캔 재료만을 취급하지만 , 복합 자판기는 음료수 + 커피 + 생활용품을 모두 다룰 수 있다.
자판기에 재료을 투입할때는 상품 선택 위치에 따라 재료를 넣어 주어야 한다. 재료의 위치는 때때로 변경될 수 있다.
우리가 운영중인 재료가 몇개 있는지, 몇개가 자판기에 투입되어 있는지, 사용수량은 어떻게 되었는지 수량관리를 하고 싶다.

데이터 모델은 2가지 관점에서 진행 보도록 한다.

첫번째는 위 시나리오를 바탕으로 액면 그대로 설계를 하는 것이다. 모델링에 대한 깊은 이해 없이 겉으로만 드러난 현상만을 가지고 테이블을 설계할 때 나타날 수 있다.

< 첫 번째 모델링 : 보이는 대로 테이블 설계를 해 보자 ~ >

[개념도 1]

K모델러는 자판기에서 사용하는 재료를 조사하여 보니 "콜라, 사이다, 커피, 율무, 껌, 초코릿" 6가지 였다. 그리고 자판기에 세팅 할 수 있는 재료를 살펴 보니 콜라 1개, 사이다1개, 커피, 율무, 껌, 초코릿은 1개씩만 세팅 할 수 있었다. 즉 현재로서는 커피를 2개 세팅할 수 있는 자판기는 없다고 가정한다. 그래서 작성한 자판기 개념도는 [그림1]과 같았다.

개념도를 바탕으로 테이블이 다음과 같이 설계되었다. 2*3개의 재료를 관리, 판매 할 수 있는 모델이다.

[ 데이터 모델 1]

재료 > 재료는 자판기에서 판매 가능한 모든 재료들이 관리된다. 위 시나리오에서는 "콜라, 사이다, 커피, 율무, 껌, 초코릿" 6가지가 관리된다. 커피종류가 3개라면 커피1 = '모카', 커피2 ='아이스', 커피3 = '블랙' 3건이 등록되어 진다.

자판기 > 자판기 개체를 관리한다. 자판기에 투입될 수 있는 모든 재료들 만큼 재료ID + 재료수량 컬럼을 만들어 놓았다. 현재는 6개 재료만 관리하기 때문에 6개의 속성들이 있다. 자판기의 슬롯이 max 6개 이기 때문에 컬럼 종류가 6개 이다. 자판향후 다른 재료를 위한 예비컬럼으로서 재료1, 재료2 속성이 추가 되었다. 재료수량에는 현재 자판기에 설치된 재료들의 재고 수량을 관리된다. 자판기 재고수량이 기준 수량이하로 떨어지면 새로운 재료를 투입해야 한다.

현재 모델에는 자판기의 사이다 안전재고 수량을 어떻게 관리 해야 할지 막막하기만 하다. 새로운 요건이 추가되거나 변경되면 컬럼을 늘이거나 또 다른 테이블들이 주렁주렁 매달릴 것으로 예상된다. 실제로 개체성격의 데이터에 업무적인 컬럼들이 붙어버리면 개체만의 고유속성이 무엇인지? 업무속성은 무엇인지? 중복속성인지 아닌지를 판단하기는 쉽지 않다...

자판기 이력 > 자판기에 재료가 투입될때, 재료가 판매되었을때의 이력이 보관된다. 즉 INPUT과 OUTPUT의 데이터가 누적된다. 이력은 판매, 교체, 투입, 제거등의 모든 이벤트들을 관리 할 수 있다. 자판기 마스터 테이블의 재료ID + 재료수량 컬럼이 똑 같이 존재한다. 재료수량은 투입되거나 사용되어진 수량을 의미한다.

모델 설명에서 알수 있듯이 수량의 의미가 재료, 자판기, 이력에서 그 의미가 조금씩 달라진다. 재고수량, 사용수량, 누적수량이 속성명에 명시되어 있지 않고 테이블의 용도에 따라 달라진다. 당연히 모델만 보아서는 그 의미를 짐작 할수가 어려울 것이다.

이제 데이터를 발생시켜 보겠다.

[ 데이터 예시 > 재료, 자판기 ]

재료 > 재료 데이터는 재료의 총수량, 자판기 투입수량과 남아 있는 재고 수량이 관리되고 있다. 이런 데이터는 자판기 이력에서 IN, OUT 발생시 업데이트 되고 있을 것이다.

> 코카-1은 총 50개였는데 자판기에 30개 투입되었고 20개 남아있다.

자판기 > 자판기는 JA-10, JA-20 2대가 있다. JA-10 자판기는 콜라 + 사이다 판매용이고, JA-20 자판기는 콜라 + 밀크커피 판매용이다. 따라서 해당 재료의 컬럼에만 데이터가 입력되어 있다.

> JA-10 자판기에는 현재 콜라 5개, 사이다 7개가 남아 있음을 알 수 있다.

> JA-20 자판기에는 콜라 12개 밀크 70(g)이 남아 있다.

[ 데이터 예시 > 이력1 ]

자판기는 JA-10 이력 데이터를 살펴 보자. JA-10 자판기에는 IN, OUT 구분자로서 투입, 출력을 알 수 있다. IN일 때는 콜라 10개, 사이다 10개가 동시에 투입되었다. 동시에 투입되었기 때문에 이벤트는 01번에 기록되고 해당 컬럼에 데이터가 입력되었다. 02 순번에서는 콜라만 1개 판매되었고, 03일대는 콜라, 사이다가 동시에 판매 되었다는 것을 알 수 있다.

- 이력 테이블의 SUM( IN ) = 콜라 10개, 사이다 10개

- 이력 테이블의 SUM( OUT ) = 콜라 5개, 사이다 3개

JA-10 자판기에는 콜라는 5개 남아 있고 사이다는 7개 남아있음을 알 수 있다. 이 값은 "자판기" 테이블에 반정규화 되어 관리되고 있다. 왜냐하면 자판기에 얼마의 재고(잔고)가 남아 있는지를 파악해야 하기 때문이다.

[ 데이터 예시 > 이력2 ]

자판기 JA-20의 커피ID가 재미있다. 처음에는 블랙-1 제품을 판매하다가 밀크-1로 교체 되었음을 알 수 있다. 그리고 자판기테이블에는 현재 밀크-1 제품이 70(g) 재고가 남아 있음을 기록하고 있다.

위의 데이터 모델과 데이터 관리방법에는 어떤 에로 사항이 있을까? 얼핏보면 큰 문제는 없어 보인다. 관리하는 속성들이 컬럼들로 되어 있으니 혹자는 이해하기 더 편해 할 수도 있겠다.

재료, 자판기라는 개체가 관리되고 있고, 자판기 판매이력이 관리되고 있으니 비즈니스를 처리하는 데는 문제가 당장 발생하지 않을 수 있다.

만약 자판기의 슬롯에 다른 제품을 판매하고 싶다면? 여러 슬롯이 있는 복합적인 자판기가 발생한다면 컬럼을 계속 추가해야 할까? 입력, 출력과 관련된 데이터 발생로직은 적절한 것일까 ? 판매 이벤트가 발생하였을 때 콜라 + 사이다가 동시에 투입, 판매 되었다면 함께 이벤트 기록하는 것이 좋을까 ?

여러가지 걱정스러운 생각들이 든다. 무슨 문제가 있을지 생각해 보는 것은 각자의 몫에 맡긴다.

누군가 꼼꼼하게 읽어 보는 회원이 있을지 살짝 고민이 된다..ㅎㅎ. 말이 많아서리...

두번째 모델링에서는 동일한 환경과 업무요건을 가지고 다른 방식으로 구현해 보도록 하겠다.

CLOB 가공 속도 향상 사례2 (DBLINK를 통한 CLOB 컬럼 복제 시 속도 향상)

이정수 — Tue, 09 Apr 2013 21:09:26 +0900

본 글은 CLOB 컬럼의 가공 속도 향상에 대한 글 2탄으로 CLOB 컬럼이 존재하는 테이블을 DBLINK로 복사할 때의 성능 향상 방안이다.

해결 포인트는 먼저 쓴 글과 동일한데, DBLINK에도 적용할 수 있음을 강조하기 위해 별도의 글로 정리해 본다.

우선 문제가 되는 상황을 설명하기 위해 공유해야 하는 몇 가지 사실은 다음과 같다.

1. CLOB컬럼은 DBLINK를 통해서 SELECT할 수 없다.

2. 단, CTAS나 INSERT INTO ... SELECT 문을 통해서 TARGET 쪽 DB에 복제한 후 사용해야 한다.

3. DBLINK를 통해서 CLOB컬럼이 있는 테이블의 INSERT ALL은 불가능하다.

문제는 CLOB 컬럼이 있는 테이블을 복제하는 것은 생각보다 시간이 많이 걸린다는 사실이다. CLOB 컬럼이 존재하니 오래 걸리는 것이 당연한 결과라고 생각하기 쉬운데, 동일한 DB 내에서 복제 SQL을 수행해보면 DBLINK를 적용할 때 보다 훨신 빨리 수행됨을 알 수 있을 것이다. 환경에 따라 차이는 있겠지만, 다음과 같이 거의 20 ~ 40배 정도의 속도 차이를 경험하게 되며 네트워크의 속도에서 원인을 찾기에는 그 차이가 너무 크게 느껴진다.

CREATE TABLE T_TABLE NOLOGGING AS SELECT TITLE, CONT FROM S_TABLE; -- 3초 (동일 DB) , CONT가 CLOB 컬럼

CREATE TABLE T_TABLE NOLOGGING AS SELECT TITLE, CONT FROM S_TABLE@DBNAME; -- 110초 (DBLINK), CONT가 CLOB 컬럼

이렇게 차이가 나는 원인은 DBLINK를 통해 CLOB 컬럼을 가져올 때, CLOB 컬럼을 가공하는 것과 유사하게 오라클이 무엇인가 성능에 상당한 악영향을 미치는 작업을 하기 때문으로 예측할 수 있다. 따라서, 해결 방안은 먼저 글과 매우 유사한데, 차이점은 INSERT ALL문장을 사용할 수 없어 다음과 같이 2개의 문장을 사용해야 한다는 점이다.(그 결과 SOURCE 테이블을 2번 FULL SCAN해야만 하는 안타까움이 존재...)

CREATE TABLE T_TABLE NOLOGGING AS SELECT TITLE, CONT FROM S_TABLE@DBNAME WHERE LENGTHB(CONT) > 4000; -- 2초

INSERT /*+ APPEND */ INTO T_TABLE SELECT TITLE, TO_CHAR(CONT) FROM FROM S_TABLE@DBNAME WHERE NVL(LENGTHB(CONT),0) <= 4000; -- 16초

결과적으로 110초 걸리던 작업이 18초로 줄어들게 되었다.

* 위의 CREATE 문은 물론 다음과 같이 INSERT 문으로 대체할 수 있다.

INSERT /*+ APPEND */ INTO T_TABLE SELECT TITLE, CONT FROM FROM S_TABLE@DBNAME WHERE NVL(LENGTHB(CONT),0) > 4000;

BIG DATA, 결론은 품질이다 . . . (주)엔코아 문태식 이사

엔코아 — Tue, 09 Apr 2013 09:43:07 +0900

80년대에 기업의 문서를 관리하던 부분을 대체하는 수단으로 정보 시스템이 활용됐다면 90년대 들어서는 기업의 핵심 업무 프로세스를 관리하는 수단으로 발전을 하였고 2000년대 들어서는 인터넷의 발달로 인터넷 쇼핑몰, 인터넷 뱅킹 등을 활용한 고객과의 최접점에서 영업의 기능을 수행하였다. 현재는 차를 몰고 가다가 주유소에서 기름을 넣거나 식당에서 식사 후에 결재를 하고 나면 근처의 맛집이나 커피숍을 추천해 주는 등 고객의 위치나 상황에 따라서 적극적으로 마케팅 전략을 펼치는 역할로까지 발전하고 있다. 이러한 시대 흐름과 함께 데이터 분석의 요구는 항상 있어 왔다. 80년대에 집계 테이블을 생성하여 고객별 영업 사원별 지점별 매출 현황 등을 분석하였고, 90년대 들어서는 비즈니스의 다양성에 발맞춰 많은 단위 시스템들이 추가되었고, 또한 기간계 트랜잭션들이 늘어남으로써 정보계 시스템을 별도로 구축하는 DW 프로젝트를 통해서 다양한 데이터 분석을 하였다. 2000년대 들어서는 비즈니스 역동성이 더욱더 확장되면서 이를 분석하기 위한 BI 시스템을 도입하여 데이터를 분석하였다. 현재는 빅데이터에 대한 분석 열풍이 거세게 일고 있는 시점이다.

기업은 소셜 네트워크 시대에 대한 불안감이 있다. 고객 한 사람의 목소리가 퍼져 나가는 속도가 엄청나게 빠른 시대에 살게 됐기 때문이다. 과거에는 고객 불만에 대한 목소리가 다른 사람들에게 전달되기란 쉽지 않았다. 주로 입소문을 통해서 퍼져 나갈 수 밖에 없었으니까… 그러나 지금은 유나이티트 에어라인의 사례와 같이 고객 불만의 목소리가 유투브 동영상을 통해 4일만에 천만 조회 이상을 퍼져 나가서 기업의 주가가 10% 하락하게 만드는 영향력을 행사하는 세상이 되었고, 반대의 경우도 마찬가지다. 그래서 기업은 이에 적극적으로 대응을 하지 않으면 안 되는 상황이 된 것이다. 또한, 소셜 네트워크상에 나와 있는 정보들을 가지고 마케팅 전략에 적극적으로 활용하는 기업이 훨씬 더 경쟁 우위에 있음은 두말 할 나위도 없다.

그러나 좀더 엄밀하게 본다면 기업의 빅데이터 분석이라는 것이 기존의 것이 없어지고 빅데이터 분석만 있다는 것은 아니다. 집계 테이블을 만드는 것도 비즈니스에 따라서 필요하고 DW, BI 시스템도 그대로 존재하며, 여기에 BIG DATA 분석에 대한 부분이 더해지는 확장의 개념으로 봐야 한다. 소셜 네트워크상의 비정형 데이터에서 의미 있는 데이터를 뽑아 내는 것은 별도의 기술이 더 필요한 부분이지만 의미 있는 데이터가 되고 나서부터는 정형화된 데이터가 될 것이고 여기에 내부에서 그 동안 너무 큰 사이즈여서 관리를 못했던 것들도 우리가 원하는 형태의 정형화된 데이터로 관리를 할 것이다. 최종적으로 이렇게 모아진 모든 데이터들을 분석 대상에 올려 놓고 원하는 형태로 조회를 하거나 마이닝을 통하여 의미 있는 데이터를 찾아내서 마케팅에 활용 할 것이다.

소셜 네트워크상에서 데이터를 갖고 오거나 대용량의 데이터를 분석하는 부분을 제외한다면 BI 시스템의 기능과 유사한 부분들이 많은 데 지금도 성공적으로 BI 시스템을 활용하고 있느냐를 반문해 볼 필요가 있다. 결론적으로 말하면, 과거부터 항상 데이터 분석을 할 때 데이터 품질의 문제가 대두되어 왔고 지금도 마찬가지이며 그로 인해 외부적으로는 성공한 것 같이 보이지만 내부적으로는 실패한 프로젝트들이 다반사이다. 결과를 조회하는 화면별로 다른 수치들이 조회되는 경우가 허다하고 이를 보정하기 위해서 사용자가 별도의 수치를 입력하여 데이터를 맞추는 인터페이스를 제공하는 OLAP 툴들이 인기를 끄는 상황까지 온 것이다. 이러한 상황에서 실시간 데이터 분석을 한다는 것은 요원할 것이다.

데이터 품질을 저하시키는 원인들은 잘못 코딩된 프로그램의 문제도 많이 있겠으나 가장 큰 문제는 데이터 구조 설계의 미비 때문이다. 구체적으로는 첫 번째 전사적인 데이터 구조 설계의 개념 없이 업무별로 데이터 모델을 설계하거나 이 조차도 하지 않고 급하다고 먼저 테이블에 반영을 해놓고 데이터 모델에는 나중에 반영을 한다든지 설계 자체를 아예 하지 않는 기업들이 대부분이다. 두 번째로는 데이터 설계를 할 때 데이터 구조 구현, 데이터 품질 관리 체계와의 연계, 데이터 흐름과의 연계, 애플리케이션을 포함한 전사적인 변경 영향도에 대한 고려를 하지 않고 단순히 데이터 설계만을 범위라고 생각하는 것이 문제다. 세 번째로는 체계적인 통제 프로세스에 대한 고민이 부족하다는 것이다. 요즘 차세대 프로젝트를 수행할 때 많은 기업들이 메타 관리 체계를 도입하면서 거버넌스 체계를 구축했다고 말을 하지만 앞서 언급한 두 가지 부분을 포함한 거버넌스 체계를 구현한 사례는 찾아보기 힘들다.

그렇다면 데이터 품질을 최대화 시키는 방법은 무엇일까? 명확하게 세 가지로 말 할 수가 있다.

첫 번째는 전사적인 데이터 아키텍처 기반의 데이터 설계를 하자는 것이다. DW, BI를 구축할 때 가장 어려운 부분이 마스터 데이터의 불일치성이다. 전사적인 데이터 아키텍처 기반이라는 것은 마스터 주제 영역의 통합을 추구하고 핵심 계약 레벨 주제 영역의 업무별 통합 정도를 관리하며 거래 주제 영역의 업무별 주제 영역 분할 정도를 관리하는 것이다. 이러한 개념 없이는 일관된 데이터 구조 관리가 요원할 뿐 아니라 데이터 값의 품질도 보장을 할 수가 없을 것이다.

두 번째는 데이터 모델을 설계한 것으로 다른 부분들과 원활하게 연계하여 전체적인 데이터 품질 관리 체계를 만들자는 것이다. 애플리케이션에서 MDA(Model Driven Architecture)라는 개념이 있듯이 데이터 영역에서도 DDA(Design Driven Architecture)를 구현하자는 것이다. 데이터 모델 기반으로 DBMS에 테이블 구현을 자동화하고 데이터 품질 관리체계와 원활하게 연계를 하여 데이터 값 품질관리를 하고, 데이터 흐름관리와 연계를 하여 ETL의 품질을 높이며, 설계 시점에 전사적인 프로그램 영향도를 분석하여 전체 IT시스템의 품질을 높일 수 있도록 하자는 것이다.

세 번째는 이러한 모든 것들이 거버넌스 체계에 포함되어야 한다는 것이다. 연관되는 모든 요소들이 시스템화 되어야 하고 우리가 하는 모든 업무 절차가 프로세스를 통해서 통제가 되어야 한다는 것이다. 많은 프로젝트를 수행하면서 사람을 믿지 않는 버릇이 생겼다. 사람의 능력을 믿지 않는 것이 아니라 사람이기 때문에 많은 양의 데이터를 수작업으로 처리하다 실수가 필연적으로 발생할 수 밖에 없다는 것이다. 일정한 규칙을 가지고 수행하는 일은 시스템이 훨씬 잘 한다. 그렇기 때문에 시스템화하는 것이 필수적이고 이를 통제하는 프로세스가 내재화 되어 있어야 한다.

빅데이터 시대, 과거 정보계 시스템의 잘못된 전철을 밟지 않으려면 시스템을 구축할 때 데이터 품질 관리체계를 함께 구축하는 것이 중요하다. 그것이 단순히 메타관리시스템을 도입하는 것이 아닌 데이터 아키텍처 기반의 설계 사상과 전사적인 정보시스템과의 연계를 고려했을 때 훨씬 더 기업에서 필요한 가치 있는 데이터를 분석할 수 있는 근간이 될 것이고 정보 시스템이 기업의 핵심 경쟁력으로 자리 잡을 수 있으리라 생각한다.