이화식 대표이사 엔코아정보컨설팅
실전 데이터 모델링 개론
이화식 대표이사 엔코아정보컨설팅
제 1 장 데이터 모델링의 접근
데이터 모델이란 구현할 정보시스템의 골격을 정의한 설계도라고 할 수 있다. 정보시스템은 다량의 데이터와 수많은 업무규칙들이 매우 복합적이고 정밀하게 접목되어 탄생한다. 그 중에서 데이터 구조는 건물의 골격과 같은 것이기 때문에 사용자의 요구나 업무의 변화에 따라 쉽게 흔들린다면 위험성이 크게 증가함은 물론, 많은 유지·보수 비용을 필요로 하게 될 것이다.
데이터 모델은 정밀하게 작성되어야 한다. 시스템 설계 단계에서 인간이 조사하고, 판단하고, 결정해야 할 거의 모든 것들이 빠짐없이 구체적으로 명시되어 있어야 한다. 대부분의 시스템에서 나타나는 데이터 모델은 - 그것이 비록 유명 ERP 패키지라고 하더라도 - 개념적인 설계, 그 이상은 아니었다. 커다란 엔터티 박스에 다량의 속성들만 빼곡하게 나열되어 있을 뿐이다. 이러한 데이터 모델은 단지 엔터티 종류와 속성들을 수집해 두었다는 것, 그 자체에 지나지 않는다.
현실에 안주하는 사람에게 발전이란 없다. 우리가 지금까지 행한 데이터 모델이 턱없이 부족한 수준이었다는 것을 깊이 자각하지 않으면 어떻게 달라져야 할지 고민하지 않게 된다. 이런 의미에서 모델링의 상세한 접근방법으로 들어가지 전에 먼저 현재의 문제점들을 되새겨 보고, 올바른 모델링을 위해 깊이 유의해야 할 일들부터 살펴보는 것이 순서일 것이다.
1.1 데이터 모델링의 실태
실전에서 일어나는 데이터 모델링의 잘못된 유형과 잘못된 접근 행태를 먼저 살펴보기로 하자. 여러분들이 지금까지 실시해 온 데이터 모델링의 접근 방법들은 이러한 형태 중의 하나일 가능성이 매우 높다. 지금까지 수많은 데이터 모델들을 보아 왔지만 거의 대부분은 다음의 몇 가지 형태로 구분될 수 있었다.
1.1.1 데이터 모델링의 잘못된 유형(I)
대다수의 프로젝트에서 나타나는 데이터 모델들의 잘못된 형태를 크게 분류해 본다면 다음과 같이 세 가지의 유형으로 나눌 수 있겠다. 그 첫 번째 유형을 '형제형'이라 부르고, 두 번째 유형은 '족보형'이라고 부르기로 하며, 마지막 세 번째 유형은 '네트웍(network)형'이라고 이름을 붙이겠다.
'형제형'이란 말 그대로 엔터티 간에 실질적인 상하관계가 있음에도 불구하고 누구나 동격인 것처럼 표현되어, 마치 조상이 자신의 형제인 것처럼 나타나 있는 데이터 모델을 말한다. 이러한 일이 발생하는 이유는 데이터 모델링에서는 반드시 1촌 관계만을 표현하는 것을 원칙으로 한다는 점을 알지 못했기 때문이다. 물론 실용적 모델링 단계에 가서 다양한 현실적 요소들을 감안하여 접근경로를 단축하기 위해 1촌 이상의 관계들을 정의하는 경우도 있다. 그러나 이것은 어디까지나 나중에 생각해 볼 수 있는 일일 뿐이지 본질적 모델링에서는 그렇게 할 필요가 없다.
두 번째 유형을 '족보형'이라고 표현을 하였다. 이 유형은 마치 대대로 집안에 물려 오는 족보처럼 부계 중심으로 작성된 데이터 모델을 말한다.
세 번째 유형은 '네트웍형'이라고 표현할 수 있다. 이러한 유형은 마치 네트웍 도면에서 나타나는 것처럼 길게 선이 하나 늘어져 있고, 중간 중간에 하나씩 라인을 빼서 단말기가 붙어 있는 것과 유사한 형태를 말한다. 이처럼 잘못된 유형의 데이터 모델이 나타나는 원인은 데이터 모델링을 접근하는 방식의 근본적인 잘못에서 비롯되었다고 할 수 밖에 없다. 데이터 모델링은 현실에 흩어져 있는 수많은 요소들을 마치 복잡한 방정식을 풀어가듯이 하나하나 단계적으로 구체적이고 명확하게 정의를 해 가야 한다.
1.1.2 데이터 모델링의 잘못된 행태(II)
실무에서 진행되는 모델링을 살펴보면 필연적으로 이러한 딜레마에 빠지게 되어 있다. 다음에 소개하는 몇 가지 모델링 행태를 살펴본다면 금방 그 이유를 알아낼 수가 있다.
◆ 책상 앞에 앉아서 그리는 풍경화
데이터 모델링을 진행할 때 발생하는 가장 큰 문제행태는 참고인이며 최종 결정자라는 매우 중요한 역할을 담당해야 할 현업담당자와 함께 모델링을 진행해가지 않는다는 것이다. 여러분들이 노트를 들고 현업 실무자를 찾아가서 열심히 업무설명을 듣고 나름대로 최대한 이해를 한 후, 자기 책상에 돌아와서 ERD를 그린다고 가정해보자. 이것은 풍경을 눈에 익힌 후 자기 책상에 와서 풍경화를 그리는 것과 무엇이 다르겠으며, 과연 이 그림이 정확하게 그려졌다고 할 수 있을 것인가?
◆ 교육을 받는 수사관
설계자라는 사람이 현업 사람들을 앉혀 놓고 수사를 진행해 가는 것이 아니라 그들이 앞에 나가 열심히 업무를 설명하면 책상에 앉아 열심히 필기를 하는 풍경들이 펼쳐지고 있다. 업무는 원래 그 사람들 소관이고, 나보다는 그들이 훨씬 잘 알고 있을 것이므로 나는 그들의 말을 제대로 이해하여 정보시스템으로 적당히 전환시켜 주기만 하면 된다는 생각이 밑바닥에 깔려 있는 것이다.
이제 수동적인 자세로 필기나 하고 앉아 있는 수사관과 같은 한심한 작태를 당장 그만 두고, 셜록홈즈나 형사 콜롬보와 같은 유능한 수사관으로 환골탈태를 해야만 할 것이다.
◆ 사진관 아줌마
우리가 하고자 하는 데이터 모델링은 있는 그대로를 찾아서 그려 넣는 사진관 아줌마가 아니라 작품세계를 만들어야 하는 사진작가가 되어야 한다는 것이다.
진정한 사진작가라면 피사체의 질적인 문제보다도 작가의 전문성을 통해 이를 예술로 승화시킴으로써 아무나 창조할 수 없는 작품세계가 탄생될 수 있다. 이와 마찬가지로 구현할 대상 업무의 현재의 질적인 면과 상관없이 최상의 작품으로 개선, 승화시키는 역할을 해야 하는 것이 바로 우리에게 주어진 중요한 임무라고 하겠다.
1.2 데이터 모델링의 주요 원칙
우리가 지금까지 수행해 왔던 데이터 모델링의 잘못된 관행을 바로잡기 위해서 이제부터 우리가 지켜야 할 주요 원칙과 그 실행 전략을 살펴보기로 한다.
데이터 모델링은 아무 정보도 가지고 있지 않은 빈 백지 상태에서 시작해서 데이터적인 측면에서 현재(as-is)업무를 파악하고 문제점을 도출하여, 목표(to-be) 시스템에 대한 최적의 설계를 이끌어 내기 위해 인간이 해야 할 대부분의 결정을 내리는 단계를 모두 포함하는 과정을 말한다. 또한 데이터 모델링은 매우 구체적이고 상세한 수준으로 실시되어야 하며, 누구나 인정할 수 있는 객관적인 근거를 토대로 결정되고, 그 결과가 입체적으로 표현되어야 한다.
데이터 모델링은 방법을 알고 있다고 해서 쉽게 적용할 수 있는 것이 아니다. 어쩌면 방법 이전에 지금까지 자신이 인생을 살면서 직·간접적으로 터득해 왔던 많은 경험과 사고능력, 판단력, 적극성 등이 더 필요할 지도 모른다. 이런 의미에서 필자는 모델링을 단순한 '방법의 습득 차원'이 아닌 '사고능력의 개발 차원'에서 접근해야 한다고 믿는 사람이다.
1.2.1 데이터 모델링의 작성수준
앞서 데이터 모델은 건물의 골조와 같은 것이라 했다. 이 말은 건물의 청사진처럼 상세하고 구체적으로 작성되어야 한다는 것을 의미한다.
보통 건축물 청사진에는 상세한 자재 규격과 각종 기준들이 정의되어 있다. 마찬가지로 데이터 모델에서도 그림으로는 도저히 표현할 수 없는 상세 정의를 '엔터티 정의서'와 '속성 정의서'를 통해 보다 세밀한 것까지 정의하여야 한다.
<그림 2-1-1>의 좌측(①)은 지금까지 그래왔듯이 엔터티에 속성만 평면적으로 나열된 모습이고, 우측(②)은 이를 우리가 앞으로 적용하고자 하는 형태로 간략히 표현해 본 것이다.
거듭 말하지만 데이터 모델은 건축 공사 현장에서 사용되는 청사진 수준이 되어야 한다. 만약 이와 같이 프로젝트가 진행된다면, 전체를 내다보는 설계자의 통일된 컨셉도 없이 각각의 세부내용이 개별적인 소양에 따라 작위적으로 처리될 수 밖에 없어 필연적으로 다양한 문제점이 나타나게 될 것이다.
1.2.2 데이터 모델링의 객관화
데이터 모델링은 쉽게 자신의 실수를 인식할 수 없다. 온통 불확실한 것 투성이며, 무엇부터 결정해 가야 할지 막연하기 그지없다. 더구나 자신의 판단으로 결정한 것들이 얼마나 완벽한 것인지를 확인하기가 어렵다. 하지 만 데이터 모델링 또한 프로그래밍에 못지않게 객관화를 할 수 있다.
정확한 이유와 근거를 가지고 판단할 수 있는 힘이 있다면 자신이 판단한 결정이 한 점 부끄럼이 없도록 할 수 있을 것이다. 업무는 살아 있는 생명체와 같아서 수많은 변화를 필연적으로 수반한다. 앞으로 여러분에게는 수많은 객관화 방법이 구체적으로 소개될 것이다. 이러한 객관화 방법을 완벽히 이해하여 여러분의 귀중한 판단에 활용한다면, 이제 더 이상 자신의 결정에 불안해 하지 않게 될 것이며, 발생할 수많은 시행착오가 현격히 줄어들게 될 것이라 믿어 의심치 않는다.
1.2.3 단순하고 유연한 데이터 모델
정보시스템 분야에서 수행되는 거의 모든 문제의 핵심이 주로 응용 프로그램의 문제에서 발생된 것처럼 보이지만 좀더 깊이 있게 원인을 분석해 보면 그 근본적인 원인은 실상은 설계 상의 문제에서 비롯되었다는 것이다. 만약 건물은 이미 거의 다 세워졌는데 이제 와서 설계의 골격에 근본적인 변경이 발생되었다고 한다면, 건물의 상당 부분을 무너뜨리고 새로 엄청난 보수공사를 해야 할 것이다.
눈에 잘 보이지 않는 데이터의 문제는 원인을 알지 못해 그대로 둔 채, 눈에 보이는 애플리케이션만 고치는 일을 반복하는 것은 마치 눈에 잘 보이지 않는 간이 나빠져서 발생한 병을 겉으로 보이는 합병증만 치료하려는 것과 다르지 않다. 병의 근본적인 원인을 치료하지 못하고서는 결코 완치시킬 수 없다는 것을 반드시 명심해야 할 것이다.
데이터 모델은 곧 애플리케이션이라는 시각에서 데이터를 투명하게 해야 한다. 또한 단순·명료해야 한다. 내용은 훨씬 복잡하더라도 외형은 오히려 단순하게 만들 수 있는 것이 바로 진정한 기술이다. 어쩌면 설계를 단순화 시키라는 말은 참으로 포괄적이고 추상적인 말이라고 할 수도 있다.
1.2.4 데이터 모델링은 사고력과 수사력
정확한 데이터 모델링을 하기 위해서는 본질과 핵심을 정확히 끄집어 낼 수 있는 탁월한 분석력이 있어야 하고, 도출된 여러 정보와 감안해야 할 요소들을 종합적이고 전략적으로 판단할 수 있는 깊은 사고력을 가져야 한다.
미지의 세계에 묻혀 있는 수많은 불확실한 사실들을 종합적으로 분석하여 확실한 결론으로 도출하는 힘은 단지 책을 열심히 읽는다고 해서 습득할 수 있는 것이 아니며, 유사한 사례를 많이 경험하고, 그것을 열심히 암기해둔다고 얻을 수 있는 것도 아니다. 어쩌면 그것은 우리가 지금까지 지내온 수많은 순간들을 어떻게 살아 왔느냐에 대한 문제일지도 모른다.
만약 여러분들이 진정한 전문가가 되어 앞으로 오랫동안 엔지니어로 살아가기를 진심으로 원한다면, 더 이상 방법적인 것(how-to)만을 해서는 안 된다. 남이 방법을 알더라도 쉽게 흉내를 낼 수 없는 사고적인 것(what-to)을 할 수 있어야 한다. 앞서 강조했듯이 모델링이야 말로 정보시스템 분야에서 가장 거기에 걸맞은 분야일 것이며, 정말 남다른 능력을 키워왔다면 당신은 그 누구보다 나은 대접을 받게 될 것이 틀림없다는 것을 조금도 의심할 필요가 없다. 인간만이 할 수 있는 모델링은 아무리 좋은 툴, 개발언어, DBMS가 나타나더라도 이것은 절대적으로 인간만의 몫이다.
나 자신이 하고 있는 일이 과연 인간만이 할 수 있는 영역이고 세상이 보다 발전되면 할 일이 많아지는 일인지, 그렇지 않으면 오히려 줄어드는 일인지를 곰곰이 한번 따져 볼 일이다.
제 2 장 실전 데이터 모델링의 개요
앞 장에서 데이터 모델링의 실태를 언급하면서 우리가 앞으로 올바른 데이터 모델링을 수행하기 위해 훨씬 더 객관적이고 구체적으로 접근하여야 하며, 분명한 절차와 판단의 잣대를 가져야만 가능한 일이라고 하였다.
바둑을 단지 이론만 익히고 실전훈련을 병행하지 않았다면 결코 고수가 될 수 없다. 실전에서 발생하는 미묘하고 복잡한 문제를 확신 있게 풀어갈 수 있는 응용력과 적용능력이 없다면 데이터 모델링은 한낱 책상에서나 힘을 발휘하는 참고서에 불과할 것이다. 이처럼 실전과 이론적인 것에는 적지 않은 차이가 있기 때문에 실전적인 모델링을 할 수 있다는 것은 참으로 중요하다.
가령, 자신이 엔터티의 개념을 확실하게 이해했다고 하더라도 과연 단 한번도 보고 들은 적이 없는 어떤 업체에 가서 완벽하게 엔터티를 도출할 수 있겠는가? 수천 개의 엔터티 후보들 중에서 과연 무엇을 어떻게 통·폐합하여야 할지 쉽게 결정할 수 있겠는가? 이런 실제적인 문제에 명확한 답변을 줄 수 있는 것이 바로 '실전 데이터 모델링'이다.
이 장에서는 본격적인 데이터 모델링을 설명하기에 앞서 실전 데이터 모델링의 전체적인 형태와 그 핵심적인 특징들을 먼저 소개하기로 하겠다.
2.1 실전 데이터 모델링
실전 데이터 모델링이란 수행할 업무를 전혀 모르는 상태에서 출발하여 모든 현상과 요건들을 도출하여야 함은 물론, 최적의 목적 시스템을 위해 인간이 결정해야 할 대부분을 확정해 내는 작업을 구체적, 객관적, 실전적으로 풀어 나가는 과정의 도구를 말한다.
단지 방법을 익히고, 비슷하게 흉내를 내보는 것은 그리 어렵지 않겠지만 고도의 분석능력과 구체적인 접근 수순, 객관적인 판단 기준을 통해 온통 불확실한 것 투성이었던 상황을 명확한 모습으로 확정 지을 수 있다는 것은 매우 중요하고 어려운 일이다.
앞으로 제시하는 데이터 모델링 또한 매우 상세화된 단계와 그 단계마다 구체적이고 객관적인 판단의 기준을 제시할 것이며, 좀더 심층적인 실전 연구를 통해 실전적인 모델링을 할 수 있도록 모든 경험과 지식을 쏟아 넣을 것이다.
2.1.1 실전 데이터 모델링의 개념
실전 데이터 모델링이 추구하고자 하는 가장 핵심적인 주장은 데이터 모델링은 반드시 시스템 설계 과정 전체를 이끌어 나가는데 적용하는 '과정의 도구'가 되어야 한다는 것이다.
이 말은 곧 실전 데이터 모델링에서는 비록 업무에 무지한 상태에서 출발하였더라도 이를 통해 모든 결정들을 완벽하게 확정해 가는 전체 과정을 지원함으로써, 기존(as-is) 업무의 체계적인 분석을 유도하고, 이를 기반으로 가장 효율적인 향후(to-be)의 업무체계를 수립해 갈 수 있도록 구체적인 과정과 객관적인 판단을 할 수 있는 모든 실전적 요소들을 제시하겠다는 것을 의미하고 있다.
2.1.2 실전 데이터 모델링의 단계
* 엔터티 정의(엔터티 후보 선정)
엔터티는 하나씩 별도로 확정해 갈 수 있는 것이 아니다. 먼저 여러 엔터티 후보들을 다양한 경로를 통해 선정하여 최종 엔터티들을 결정해 가는 구체적인 절차를 거쳐 종합적이고 전략적인 방법으로 엔터티를 확정하게 된다.
* 엔터티 정의(엔터티 형태별 분류)
후보로 선정된 모든 엔터티들을 대상으로 모델링을 시작해 간다면 우리는 필연적으로 엄청난 복잡성에 빠지게 되며, 오류를 일으킬 확률도 그만큼 증가하게 된다. 이를 방지하기 위해 앞서 예를 들었던 골조 자재에 해당하는 핵심 엔터티들을 먼저 분류해 내고, 이들의 의미를 분명하게 정의하기 위하여 데이터 영역별로 엔터티들을 분류하는 과정이다.
* 엔터티 정의(엔터티 검증 및 확정)
이 과정부터는 핵심 엔터티에 대해서만 정의해 간다. 엔터티의 결정은 매우 중요하고 생각처럼 쉽지 않은 과정이다. 집합이란 정의하기에 따라 통합될 수도, 분리될 수도 있다. 우리가 분명하게 알고 있다고 생각하는 '사원' 엔터티 조차도 사실은 정확하게 정의되어 있지 못하고 있다. 가령, 내근사원만을 정의한 것인지, 협력회사, 관계사들도 여기에 포함되어 있는 집합인지, 만약 보험회사라면 설계사나 대리점도 사원에 포함되는지 등을 구체적으로 정의해야 한다.
* 릴레이션십 정의(릴레이션 존재파악)
엔터티와 엔터티 간에는 하나 이상의 관계가 존재할 수 있다. 엔터티가 단 100개만 되더라도 최소한 10,000 가지의 관계가 발생할 수 있다. 만약 엔터티 개수가 1,000개 라면 얼마가 되겠는가? 이것들을 우리가 오류 없이 정확하게 정의할 수 있겠는가? 생각처럼 쉽게 접근할 수 있는 것이 아니다. 이 단계의 보다 용이한 접근을 위하여 우리는 관계 상관도(relationship matrix)를 이용하여 제3자 입장에서 관계의 존재 유무만 파악한다.
* 릴레이션십 정의(관계명칭 확정)
관계가 존재한다는 용의점이 파악되면 이들을 대상으로 보다 구체적인 단계로 진행한다. 이 단계에서 그 용의점이 구체적으로 어떤 내용의 관계를 의미하는지를 결정한다. 다시말해서 이 단계에서는 릴레이션의 내용을 명확하게 정의하는 작업을 한다. 릴레이션십의 정의 또한 엔터티에서처럼 이들을 하나로 묶을 수도 있고, 구체적으로 각각을 세분화 시킬 수도 있다. 물론 어떤 결정을 하였느냐에 따라 나중에 미치는 영향은 실로 중차대하기 때문에 이 또한 쉽게 생각할 단계는 아니다. 이 단계의 결과는 관계 상관도의 최종 모습으로 나타난다.
* 개념 ERD 작성(핵심 엔터티 배치)
관계 상관도를 완성한 후 내용을 분석해서 가로, 세로의 빈 칸에 내용이 많이 채워진 것들을 골라낸다. 내용이 많이 채워졌다는 것은 그만큼 다른 엔터티와 많은 관계를 맺고 있는 주요 엔터티란 의미가 된다. 이러한 엔터티들을 선별해서 이제부터 ERD를 작성해 가야 하므로 적절한 위치에 구도를 잡아 배치한다.
* 개념 ERD 작성(키이 엔터티 연결)
앞 단계에서 선택된 엔터티는 대부분 뒤에서 설명할 메인(main) 엔터티들이며, 이들의 부모가 되는 키이(key) 엔터티들을 적당한 위치에 놓고 릴레이션쉽을 맺어나가면 마치 철제 빔을 조인트로 연결한 건물의 골조와 같은 모습이 된다.
* 개념 ERD 작성(릴레이션 확정)
이렇게 조인트로 연결한다는 작업의 의미는 릴레이션십을 그려 넣는 것을 말한다. 앞서 정의한 릴레이션십은 단지 관계명칭의 정의를 통한 관계의 내용만 정의한 것이지만 이 단계에서는 릴레이션의 구체적인 모습을 결정하게 된다. 관계의 확정은 반드시 물증 조사에 의한 구체적인 판단에 의해서 실시되어야 한다.
릴레이션이란 어느 한 쪽이 주어가 되어서 상대를 바라보는 관계와 그 반대 쪽이 주어가 되어서 다시 이쪽의 상대를 바라보는 두 가지 관계를 합성하여 생성한다.
이 과정에서는 많은 예외 사항이 검토되어야 하며, 정의를 구체화함에 따라 새로운 업무규칙(business rule)들이 정의되어 가고, 앞서 결정해 두었던 엔터티의 정의 또한 더욱 구체적으로 규정된다.
지금까지 작업한 결과로서 우리는 '개념적 데이터 모델(conceptual data model)'을 얻게 된다. 앞으로 이 데이터 모델에 최대한의 속성 후보들을 선정한 후 다음과 같은 4가지 단계를 통해 속성을 확정하거나 추가적인 엔터티를 도출하게 된다.
* 속성정의 1단계(원자 단위)
속성을 결정하는 첫 번째의 검증 내용은 "원자 단위냐?"라고 질문하는 것이다. 원자단위란 말 그대로 더 이상 분리될 수 없는 최소한의 단위를 말한다. 그러나 화학에서 말하는 원자는 누가 보아도 명확하지만 속성에서 말하는 원자란 소속된 엔터티와 그 속성의 구체적인 의미에 따라 얼마든지 달라질 수 있으므로 앞으로 설명할 명확한 판단의 기준을 가지고 결정해야 한다.
* 속성정의 2단계(single value)
이 단계에서는 그 속성이 반드시 단 하나의 값만 가지고 있는 지를 검증한다. 이것은 정규화 작업의 제1정규형(1st NF)과 동일한 것이다. 이 말은 곧 정상적으로 모델링을 수행하고 있다면 바로 이 단계에서 제1정규형이 이루어져야 함을 의미한다. 주의할 사항은 비록 현재는 하나의 값만 가지지만 앞으로는 보다 상세한 관리를 할 필요가 없는지를 다져 보는 것이다.
이와 같은 작업이 있음으로 해서 모델링은 단지 있는 그대로를 옮겨 그리는 것이 아니라 새로운 개선점을 찾아 개선해 가는 과정의 도구라고 할 수 있는 것이다. 이 단계에 저촉되면 하위에 새로운 엔터티를 추가해야 한다. 이처럼 속성 낱개에 대한 구체적인 검증 과정을 거치면서 지금까지 줄기와 큰 가지만 있던 앙상한 데이터 모델에 점차 곁가지들이 붙게 되어 모델링은 조금씩 더 상세화 되어져 간다.
* 속성정의 3단계(가공 값 제거)
만약, 어떤 속성 후보 중에 그 엔터티에 있는 다른 속성들로 재현할 수 있거나, 다른 엔터티의 정보를 이용하여 재현할 수 있다면, 그 속성은 이미 원본(source)이라고 할 수 없다.
논리적 데이터 모델링에서는 이러한 가공 값들을 제거해야만 한다. 데이터 모델링의 1차 목표는 자신의 본질을 정확히 정의하자는 데 있으므로 아직 본질이 분명해져 있지 않은 상태에서 본질이 아닌 것들이 포함되어 본질이 호도되도록 해서는 안 된다.
* 속성정의 4단계(상세화 관리 결정)
위의 3가지 판단이 완료되었더라도 우리는 보다 전향적인 자세를 가질 필요가 있다. 앞으로는 좀더 상세한 수준의 데이터를 관리해야 할 것인지를 심도있게 검토해 보아야 한다는 것이다. 이처럼 전산화 영역을 보다 심화 시키겠다는 결정을 하였다면 과거와는 다른 형태의 데이터 모델이 나타나게 될 것이다. 만약 여러분이 이 단계를 가볍게 여긴다면 개발을 진행하는 도중에 계속해서 설계를 보완하게 하는 주된 이유가 될 것이 틀림없다.
* 식별자 지정(의미상 주어 확정)
모델링을 수행해 나가는 과정에서는 식별자를 '의미상의 주어(본질 식별자)'로 표현해 둔다. 의미상의 주어는 인조(artificial) 식별자가 아닌 원래 보유하고 있던 속성이나, 부모 엔터티로부터 상속받은 릴레이션쉽으로 표현한 자신의 '출생의 비밀'이 되는 속성이나 관계를 말한다.
이 단계까지는 앞으로 불려질 최종적인 식별자보다 '자신이 누구였느냐?', 다시 말해서 '어떻게 해서 태어난 집합인가?'라는 것이 보다 중요하다. 그것은 논리적 모델링은 바로 '자신의 본질을 정확히 정의'하는 것이 가장 중요한 목적이 있기 때문이다.
* 식별자 지정(상속 및 단절 전략)
우리가 결정하는 식별자는 단지 '개체의 식별'만을 목적으로 하는 것은 아니다. 우리의 이름에 있는 성은 자기 이름의 한 부분이기도 하지만 자신의 가계를 나타내고 있는 정보이기도 하다. 이것은 부모로부터 물려받은 상속의 결과이다. 그렇다고 해서 항상 상속만 받는다면 단일민족인 우리는 모두 동일한 성씨를 가져야 할 것이다.
상속과 단절은 정보의 연속성과 단순성에 커다란 영향을 미친다. 이러한 특성을 이용하여 적절한 전략을 수립한다면 비록 모델상으로는 복잡하지만 실제 액세스를 하는 깊이(depth)는 단순하게 할 수 있는 매우 전략적인 단계이다.
* 식별자 지정(식별자 확정)
이와 같은 상속 및 단절 전략에 따라 우리는 상황에 따라 적절한 인조 식별자를 부여하게 된다. 자신의 이름은 '소유는 자신이지만 남이 주로 불러 준다'는 사실처럼 식별자의 소유는 자기 엔터티이지만 연결은 주로 다른 엔터티가 하게 되므로 자신을 참조하는 주변의 여러 엔터티와 종합적인 상황 판단을 하여 결정해야 한다.
* 데이터 모델 검증(사례 데이터 작성)
위의 모든 단계가 결정되었다면, 이제 우리는 기본 논리적 데이터 모델을 거의 완성했다고 할 수 있겠다. 그러나 아무리 전문 모델러와 업무에 정통한 현업 사용자들에 의해 모델링이 진행되었다 하더라도, 우리가 인간인 이상 허점이 존재할 가능성은 얼마든지 있다. 더구나 기본 논리적 데이터 모델은 건물의 골조와 같은 것이기 때문에 매우 견고하게 정의되어 있지 않으면 안 된다.
이러한 우려를 불식시키기 위해 우리가 해야 할 중요한 일들은 사례 데이터를 작성하는 것이다. 이 단계는 일견 불필요하게 보일 수도 있는 단계라고 생각할 수도 있겠지만 투자할 가치가 있는 작업이다.
* 데이터 모델 검증(데이터 모델 확정)
사례 데이터 작성을 통해 작성된 모델을 시뮬레이션 하면 데이터 모델의 보완 사항이 나타나게 된다. 모델러와 정보를 제공하는 현업 사용자 간에는 커뮤니케이션 에러가 있을 수 있으며, 이 단계를 통하여 전체적인 윤곽을 다시 바라봄으로써 새로운 요구사항이 추가로 나타날 수도 있기 때문이다.
특히 현업 사용자는 이러한 시뮬레이션을 통해 지금까지 진행한 데이터 모델에 대한 자신의 이해를 향상시킬 수가 있다. 그 결과, 모델링 과정의 잘못된 결정이나 새로운 요구사항이 더 늦지 않게 도출될 수 있다. 이러한 도출된 문제점을 최대한 보완하는 일은 매우 중 요한 작업이라 할 것이다.
* 데이터 모델 검증(주요 속성값 정의)
상기 모든 단계가 완료되면 매우 상세한 결과가 나타날 것처럼 보이지만 사실은 아직도 미흡한 부분이 많이 있다. 해당 속성에 정의할 값들의 형태를 결정하고, 그 값들이 데이터 생성 시에 반드시 입력(mandatory)되어야 하는 지에 대한 결정도 같이 정의하는 단계이다.
2.1.3 실전 데이터 모델링의 영역
데이터 모델링은 시스템을 개발하는 생명주기(lifecycle)의 어느 단계에서 어떤 목적으로 사용되는 방법론인가? 여기에 대해서는 방법론에 따라 많은 차이가 있고 사람마다 생각하는 영역이 다르다. 그러나 모든 방법론들은 나름대로 많은 특징이 있지만 대부분은 다음과 같은 단계를 거치게 된다.
사용자 요구사항에 대해서 전략을 수립하고, 업무를 파악하고 개선안을 찾아 새로운 목표(to-be) 시스템의 업무형태를 확정하는 분석 단계, 이것을 정보시스템 형태로 전환하는 설계 단계, 애플리케이션을 개발하는 단계, 문서화를 수행하는 단계, 개발 시스템을 종합적으로 테스트하는 단계를 거쳐 공급(가동 및 안정화 단계)을 한다.
결국 어떤 방법론도 이러한 과정을 거치지 않을 수는 없다. 이러한 공통적으로 존재하는 기본 과정에서 데이터 모델링은 어떤 영역에서 어떤 역할을 하게 되는 것인가? 여기서 말하는 데이터 모델링의 영역은 위의 단계 중에서 전략수립과 분석단계 전체를 가리킨다.
다시 말해서 개발 시스템의 업무를 전혀 모르는 상태에서 출발하여 업무에 대한 이해와 구체적인 조사 및 파악, 그리고 앞으로는 어떻게 할 것인가에 대한 확정작업을 모두 포함하는 - 다시 말해서 인간이 결정해야 할 대부분의 사항이 취급되고 확정되어 가는 모든 과정을 포함하는 - '과정의 툴'이라는 것이다.
2.1.4 실전 데이터 모델링의 필수 무공
데이터 모델링에서도 단지 방법론을 모두 이해했다고 해서 과연 업무를 전혀 모르는 어떤 시스템에 가서 업무를 즉시 구체적이고 객관적으로 체계화할 수 있는 능력이 금방 생겨나는 것이 아님은 물론이다. 방법의 저 편에는 보다 중요한 사고력, 분석력, 종합력, 논리력, 창의력, 설득력 등이 제대로 갖추어져 있어야 하기 때문이다.
이러한 무형적인 능력을 개발하기 위해서는 오랜 세월 동안 각고의 노력이 있어야 한다. 물론 여기서 이를 얻기 위해 세월을 뛰어 넘을 수 있는 왕도를 제시할 수는 없다. 그러나 특출한 능력을 지닌 슈퍼맨이 아닌 보통사람들이 이와 유사한 힘을 발휘할 수 있는 세 가지 무공(솔루션, 방법)들이 있다.
첫 번째 방법은 단계적으로 접근해 가는 방법이다. 20cm짜리 계단을 여러 개 놓고 하나씩 열심히 올라가는 방법이 있을 뿐이다. 다른 말로 한다면 바로 '수평적 사고'라고 할 수 있다.
두 번째 방법은 이름하여 무협지에 자주 등장하는 '흡입신공(吸入神功)'이라는 무공이다. 남(현업 사용자)의 힘을 끌어낼 수 있는 무공이 필요하다는 것을 의미한다.
세 번째 방법은 '견물생심(見物生心)'을 시키는 방법이다. 견물생심이란 말 그대로 '사물을 봄으로써 마음이 생겨난다'는 것이다. 우리가 원하는 정보를 쉽게 생각해 낼 수 있도록 무엇인가를 보여줌(견물)으로써 쉽게 생각이나 판단이 되도록 유도(생심)하는 것이다. 이처럼 보다 시의적절하고, 완전한 정보를 어떻게 획득하느냐에 대한 문제는 좋은 데이터 모델링을 할 수 있는 매우 중요한 요소 중의 한 가지임에 틀림이 없다.
여러분들이 아무리 우수한 분석력과 종합력, 판단력을 가지고 있다고 하더라도 현실의 요소들을 충분히 캐내지 못하면 결코 좋은 데이터 모델을 만들 수 없다는 것은 너무나 당연한 상식이다. 마치 아무리 우수한 의술을 가지고 있는 의사가 있다고 하더라도 환자의 상태를 제대로 파악할 수 없다면 결코 완벽한 처방을 내릴 수 없는 것과 동일하다고 하겠다.
2.1.5 데이터 모델링과 프로세스 모델링
정보시스템을 개발하는 그 과정에는 두 가지의 커다란 줄기가 있다. 한 가지는 정보의 요구사항을 설계하는 데이터 모델링 부문이고, 다른 하나는 사용자의 애플리케이션 요구사항을 수렴하기 위한 프로세스 모델링이 있다.
단계적으로 보면 전략수립 단계와 분석 단계에 데이터 모델링을 하여 ERD와 엔터티, 속성 정의서를 완성하고, 프로세스 모델링을 수행하면서 자료흐름도(DFD)나 기능계층도(FHD)를 완성한다. 설계 단계에서는 물리적인 데이터베이스를 설계하고, 또 애플리케이션을 설계를 하게 된다.
물론 이들은 상호검증을 통하여 보완되어야 하며, 이 과정을 거치면서 가동 가능한 데이터베이스와 프로그램 작성을 통한 가동 애플리케이션이 나온다. 정보시스템이란 결국 이 두 가지가 연결됨으로써 가동 가능한 시스템으로 태어난 것이다. 물론 이것은 당연한 것이기는 하지만 이 두 가지를 어떻게 잘 조화시켜 나갈 것인가 하는 것은 매우 중요하다.
2.1.5.1 접근 방법 I (先 프로세스 모델링)
이와 같이 프로세스 중심적으로 접근하는 이 방법은 접근성은 매우 우수하지만 미래의 변화에 대한 대응이 힘들고, 많은 추가 비용이 발생할 것이 분명하므로 결코 추천하고 싶은 접근방법이라고는 할 수 없겠다.
2.1.5.2 접근 방법 II (동시 진행)
전문가가 제대로 없는 상태에서 업무의 크기에 따라 여러 개발팀으로 분할해서 각 부문을 독자적으로 진행하는 방법이다.
2.1.5.3 접근 방법 III (先 데이터 모델링)
데이터 모델링을 먼저 한 다음 그 결과를 이용해 프로세스를 설계하는 방법이다. 필자는 가능하다면 반드시 이 방법을 적용해야 한다고 강력히 주장하는 사람이다. 그것은 이 방법이야 말로 가장 합리적으로 목적을 달성하는 지름길이라 믿기 때문이다.
2.1.5.4 객체지향 모델링에서 데이터 모델링 접근방법
객체지향 소프트웨어 개발 방법론에서 사용하는 클래스(class)는 지금까지 우리가 언급해 온 데이터 아키텍처의 데이터 영역이나 데이터 클래스, 엔터티, 서브타입과 매우 유사한 개념이다. 관계형 데이터베이스를 발전시켜 나감으로써 객체지향에 접근해 가는 방식은 몇 가지 이점을 지닌다.
첫째, 십 수 년간 입증된 또 확산된 - 그래서 어찌 보면 익숙한 - 관계형 데이터베이스 기술을 지렛대를 활용하듯이 이용할 수 있다는 것이다. 둘째, 현재 전 세계적으로 가장 많이 사용되는 관계형 데이터베이스 기반의 애플리케이션에 객체 기술로의 전이를 위한 '통로(Paths)'를 제공하게 된다는 것이다.
다시 말해 객체지향 애플리케이션과 기존에 사용해오던 애플리케이션이 공존할 수 있다는 것이다. 뿐만 아니라, 관계형 데이터베이스가 제공하는 신뢰성, 확장성, 보안, 질의 최적화 등이 객체 기술이 도입되더라도 그대로 보장될 가능성이 가장 크다.