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 Tutorials 432 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 432
데이터 모델링 강좌(6)
작성자
정재익(advance)
작성일
2002-07-12 22:22
조회수
5,841

앞에서 데이터 모델링의 실태를 언급하면서 우리가 앞으로 해야 할 제대로 된 모델링이란 어떻게 실시되어야 하는 가에 대해서 설명하였다. 필자는 기존에 서점에 출판되어 있는 모델링 관련 서적들을 매도할 뜻은 없다.

 

다만 거기에는 모델링의 개념과 데이터 모델을 작성하는 방법에 대해서는 자세히 설명하고 있을 지는 몰라도 적어도 여기서 주창하는 확신을 가지고 모든 결정을 검출해내는 '객관적인 판단의 근거'와 업무에 무지한 상태에서 체계적인 결론을 도출해 가는 '고도의 수사 및 사고 능력'과 방법의 이해만으로는 도저히 해결할 수 없는 실전에 바탕을 둔 '다양한 실전 연구'는 없을 것이라 확언한다.

 

필자는 20년간 실전의 선봉에서 한번도 그 칼자루를 놓아 본 적이 없다. 그동안 단순한 경험론적인 주장이 아니라 체계적이고 합리적이면서 실전적인 방안을 여러분에게 구체적으로 제시해 왔음을 자타가 공인한다고 믿고 있다.

 

앞으로 필자가 제시하는 데이터 모델링은 매우 상세화된 단계에서 그 단계마다 구체적이고 객관적인 판단의 기준을 제시할 것이며, 좀더 깊은 심층연구를 통해 실전적인 모델링을 할 수 있도록 모든 경험과 지식을 쏟아 부을 것이다.

 

본격적인 데이터 모델링에 앞서 실전 데이터 모델링의 전체적인 형태와 그 핵심적인 특징들을 먼저 소개하기로 하겠다.

 

실전 데이터 모델링

 

실전 데이터 모델링은 별도로 업무를 분석한 후 그 결과를 정보시스템에 맞도록 전환시키는 것이 아니라 업무를 전혀 모르는 무지의 상태에서 출발하여 인간이 결정해야 할 대부분을 확정해 내는 작업을 구체적, 객관적, 실전적으로 풀어 나가는 과정을 의미하는 말이다.

 

이것은 말처럼 그리 쉽지 않다. 고도의 분석능력과 구체적인 접근 수순, 객관적인 판단 기준이 필요한 작업이며, 인간의 사고 능력에 크게 영향을 받는 오직 인간만이 할 수 있는 어려운 작업이다.

 

세상에는 방법을 알면 충분히 할 수 있는 것이 있고, 방법을 알더라도 흉내조차 낼 수 없는 것이 있다고 했다. 실전 데이터 모델링은 방법의 설명에 그치지 않고 구체적이고 객관적인 사고를, 판단을 할 수 있는 능력을 키우는 비법을 제시한다. 그렇지만 어느 한가지도 상식을 벋어나지 않는 매우 보편적이고 일반적인 내용이므로 여러분이 자신의 것으로 소화하는데 큰 어려움은 없을 것으로 확신한다.

 

실전 데이터 모델링의 개념

 

실전 데이터 모델링이 추구하고자 하는 핵심적인 주장은 데이터 모델링이 설계 과정 전체를 이끌어 나가는 '과정의 툴'이 되어야 한다는 것이다.

 

이 말은 업무에 무지한 상태에서 출발하여 모든 결정들을 완벽하게 확정해 가는 과정을 지원함으로써, 기존(as-is) 업무의 체계적인 분석을 유도하여 가장 효율적인 향후(to-be)의 업무 체계를 수립해 가는 구체적인 과정과 객관적인 판단을 할 수 있는 모든 실전적 요소들을 제시하겠다는 것을 의미한다.

 

우리가 업무에 무지한 상태에서 구체적인 객관화를 하는 것은 말처럼 쉬운 일이 아니다. 예들 들어, 여러분들이 아주 큰 빌딩을 짓는다고 생각해 보자. 이 빌딩을 하나 짓는데 들어 가는 전체 자재가 몇 가지가 되겠는가? 상상하기 어려울 만큼 상당히 많을 것이다.

 

지금 건물이 이렇게 세워져 우리 눈에 보이고 있으니까 당연히 모두가 제 자리에 붙어 있는 것처럼 보인다. 그렇지만 이 수 많은 자재가 건물을 세우기 전에 있었던 상태로 거슬러 올라가서 생각을 해 보자.

 

엄청난 양과 수의 자재가 땅위에 제 멋대로 흩어져 있으며, 어떤 것은 가공되어 있지 않은 상태로, 또 어떤 것은 땅 속에 묻혀 있는 채로, 어떤 것은 아직 준비도 되어 있지 않은 것들도 있을 것이다. 이것들을 제대로 깎아서, 모으거나 분류해서 제 위치에 제대로 찾아서 끼우는데 몇가지의 경우의 수가 나올 것인가를 생각해 보면 실로 엄청난 일이 아닐 수 없다.

 

다른 예를 들어 보자. 여러분들이 어린아이들 '그림 조각 맞추기' 놀이를 알고 있을 것이다. 조각들을 모두 땅바닥에 쏟아 놓고 제 위치의 맞추는 것도, 조각 수가 10여개 정도라면 어린아이들도 맞출 수 있겠지만, 이 조각이 몇 백개가 넘는다고 생각해 보면 제 위치에 찾아서 맞출 수 있는 경우의 수는 참으로 만만하지 않다.

 

이러한 문제는 '시행착오법'으로는 도저히 풀어 낼 수가 없다. 여러분들이 얼마나 모델링에 자질이 있는 지를 실험해 보는 방법이 있다. 내가 장차 훌륭한 모델러가 될 수 있는지 없는지를 실험해 보기 위해서 여러분들이 집에 가서 애들이 가지고 노는 그림조각 맞추기를 쏟아 놓고 한 번 맞추어 보시라.

 

만약 시간을 재어서 항상 시간이 일정하게 나오는 사람은 확실히 자격이 있는 사람이다. 반면에 소요된 시간이 들쭉날쭉 하는 사람은 빨리 포기를 하는 것이 좋다. 왜냐하면 시간의 차이가 크다는 것은 오로지 시행착오를 통해 해결 했다는 것을 의미하기 때문이다. 다시 말해서 만약, 운이 좋을 때는 시행착오를 적게 해서 빨리 맞추었을 것이고, 그렇지 않았다면 늦어졌을 것이기 때문이다.

 

우리가 땅바닥에 널려 있는 수 많은 자재의 제 위치를 찾기 위해서 엄청난 시행착오에 빠지지 않으려면 반드시 접근 방법을 다르게 하지 않으면 안된다. 아직 건물의 골조도 결정되지 않은 상태에서 도어록을 들고 어디다 붙일까 고민하는 사람은 정신이 없는 사람이다. 문짝부터 결정한 다음에 생각할 일을 먼저 고민해서는 안 된다.

 

이것을 가능하게 하는 것이 바로 실전 데이터 모델링의 특징이다. 개념의 이해를 위해서 건축물의 예를 통해 좀더 상세하게 접근해 보자.

 

길거리를 지나다 보면 높은 빌딩을 세우는 모습을 보았을 것이다. 먼저 붉은 골조를 모두 세운 다음, 거기에 바닥공사와 벽공사를 하면 외형적으로는 건물의 일차적인 모습을 갖출 수 있다.

 

그러나 이 상태로서는 아직 사람들이 들어가서 살 수 있는 상태는 아니다. 여기에 다시 전기공사, 배관공사 등의 내부 공사를 하여야 비로소 사람이 살 수 있는 건물이 완성된다.

 

여기서 중요한 것은 내부 공사를 하면서 건물의 외형, 즉 골조를 바꾸어서는 안된다는 것이다. 골조 자재는 크고 중요하지만 그 개수와 종류는 상대적으로 적다. 이처럼 건축 자재들도 골조 공사에 들어 가는 자재와 내장 공사에 들어 가는 자재가 있듯이 엔터티에서도 골조에 해당하는 엔터티가 있고, 그 하위 레벨의 엔터티가 있다.

 

골조 엔터티는 그 종류와 개수가 상대적으로 적다는 것도 유사하다. 특히 골조 공사는 단단하고 확실하게 세워져야 하듯이 골조 엔터티를 정의하고 명확화 하여, '관계(relationship)'이라 불리우는 나사로 단단히 연결하여 견고하게 세워서 모델링의 상세화 단계에서도 흔들리지 않도록 정의되어야 하는 것 또한 유사하다.

 

이처럼 중요하면서도 우선적으로 처리할 것들을 먼저 견고하게 확정하는 작업은 우리를 복잡성에 빠지게 하지 않으면서, 시행착오를 줄이도록 하는데 큰 도움을 줄 것이다. 다행스럽게도 이러한 골조에 해당하는 엔터티들은 상대적으로 개수가 많지 않기 때문에 업무 지식이 미흡한 모델링 초기 단계에서도 그리 어렵지 않게 추진할 수 있다.

 

'기본 논리적 데이터 모델링'이라고 불리는 이 단계에서 우리는 엔터티 후보들을 선정하고, 핵심 엔터티들을 분류하며, 이들을 객관적인 검증 단계를 거쳐 명확화 시킨다. 이것은 마치 공사에 사용할 자재들의 후보를 선정하고 먼저 골조 자재(빔, 철근, 시멘트, 모래, 자갈 등)들을 선별하여 분류하고, 이를 적절하게 다듬어 준비 - 빔을 자르게나, 벽돌을 만들거나 철근을 자르고 묶는 등과 같은 준비 - 하는 명확화 단계를 거치는 것과 유사하다.

 

이렇게 준비된 골조 자재를 땅 위에 세우기 위해서는 어떤 것끼리 연결해야 할 것인 지를 찾는 것처럼 엔터티 간의 관계(relationship)을 찾는 작업이 있어야 하며, 이 관계로 연결하면 마치 철제빔이 땅 위에 세워진 것과 같은 모양이 된다.

 

그러나 아직 앙상한 골조만 있는 이 상태로는 함부로 걸어 다닐 수도 없고, 비바람을 막을 수도 없다. 여기에 바닥공사와 벽공사를 해 주어야 기본적인 건물의 모습이 되는 것처럼 모델링에서는 여기에 해당하는 '속성(attribute)' 공사를 하게 된다.

 

벽공사를 할 떄 창문을 달 수도 있고, 내벽을 쌓아 방들을 구분할 수도 있는 것처럼 속성을 정의할 때도 '속성 검증 4단계'를 거치면서 엔터티는 보다 세분화 되어진다. 이와 같은 공사가 완료되면 드디어 외형적으로는 건물의 모습이 갖추어 지는 것처럼 데이터 모델도 '기본 논리적 모델'이 완성된다.

 

그러나 이 상태는 아직 사람이 들어가서 살 수 있는 모습이 아니듯이 데이터 모델도 아직 완성된 상태는 아니다. 여기에 전기공사, 수도공사, 배관공사 등을 하는 과정이 반드시 필요하듯이 데이터 모델링에서는 '상세 논리적 데이터 모델링'이라고 부르는 상세화 과정이 필요하다.

 

지금까지 우리가 복잡성에 빠지지 않기 위해 핵심(골조) 엔터티 위주로 처리해 왔기 때문에 먼저 상세화 과정이 필요하다. 이 과정에는 '정규화(normalization)'라고 불리는 세분화 작업을 통해 모든 속성들이 정확한 제 위치를 찾도록 하며, 복잡성에 빠지지 않기 위해 기본 논리적 모델링 단계에서 덜 풀어 두었던 M:M 관계를 보다 세부적으로 풀어 가는 작업을 한다.

 

이 단계를 거치게 되면, 보다 세분화된 엔터티 - 나무로 말하면 많은 곁가지에 해당 - 가 나타나게 되는데 이것들을 그냥 두어서는 매우 복잡한 모양이 되므로 이들을 여러가지 방법으로 통합하는 작업을 거치게 된다.

 

통합작업에는 수직적관계의 엔터티를 통합하여 순환적(recursive) 구조로 만드는 '수직적 통합', 역할을 통합하거나 의미의 상향 조정을 통해 수평적 관계의 엔터티를 부분집합(subtype)으로 묶어내는 '수평적 통합', 엔터티는 통합하지 못하지만 관계들을 하나의 의미로 묶어 낼 수 있을 때 이를 '배타적(exclusive) 관계'로 통합하는 '관계의 통합', 2차원적 관계(당사자 간의 관계)를 통합하여 다차원적으로 묶어 내는 '차원적 통합'이 있다.

 

이와 같이 통합 작업까지 거치면 개념적으로는 완성된 데이터 모델이 만들어 지지만 아직 완전히 끝난 것은 아니다. 이 상태에 '이력(history)' 관리에 대한 종합적인 판단이 있어야 한다. 이력 관리에 대한 결정을 이처럼 나중에 결정하는 것은 이력을 감안하는 순간 모든 관리 형태는 변형이 발생한다.

 

지금까지 수행해 온 모델링 작업의 가장 큰 목적은 본질을 정확히 규명하고 최선의 형태를 결정하는 것이 없다. 만약 이러한 작업에서 이력으로 인해 본질에 변형이 발생한다면 우리는 그만큼 본질을 찾기가 어려워 질 것이며, 오류의 발생 확률도 크게 증가할 것이다.

 

이러한 문제를 예방하기 위해서 이력관리는 모든 본질적인 형태가 완성된 다음 이력 관리 입장에서만 다시 평가하고 결정하는 단계를 거치는 것이 바람직하다. 이력 관리는 뒤에서 상세하게 설명하겠지만 기존에 우리가 사용하던 개념과는 크게 다르다. 무한대의 '점'을 표현할 수 있는 '선분'의 개념을 도입하여 보다 낮은 비용으로 완벽한 과거를 재현할 수 있는 방법을 제시한다. 여러분들은 아마 상당히 충격적인 느낌을 받을 것이라 생각하게 될 것이다.

 

지금까지 설명한 과정을 거쳐 '논리적 데이터 모델'은 완성된다. 여기서 가장 중요한 것은 기본 논리적 데이터 모델링이다. 골조란 한번 만들어서 세우면 다시 바꾸기가 굉장히 어렵기 때문에 잘못되지 않도록 매우 단단하게 만들어야 한다는 것을 다시 한번 강조하고자 한다.

 

여기까지 모델링이 끝나면 그 결과를 이용해서 우리가 원하는 데이터베이스 형태에 맞는 적절한 방법을 사용하여 전환시키면 데이터베이스가 만들어 진다. 이 과정은 이미 데이터 모델링에서 인간이 해야 할 거의 모든 결정이 완료된 상태이기 때문에 대부분의 경우 정해진 규칙대로 전환시키기만 하면 되는 단순한 작업이다.

 

모델링은 업무를 체계적으로 정의해 놓은 것이지 데이터베이스 구조를 정의해 놓은 것이 아니다. 그러므로 그 결과를 이용하여 관계형 데이터베이스에 맞도록 전환시키면 관계형 데이터베이스가 되는 것이고, HDB, NDB, ODB에 맞도록 전환시킬 수도 있는 것이다.

 

이와 같이 데이터 모델링의 결과를 이용하여 원하는 어떠한 종류의 데이터베이스로도 전환시킬 수가 있지만 현재 대부분의 시스템이 관계형 데이터베이스를 사용하고 있으므로 여기에서는 관계형 데이터베이스로 전환시키는 방법만 설명하기로 한다. 그러나 데이터 모델을 데이터베이스로 전환시키는 작업이 끝났다고 해서 데이터베이스 설계가 모두 완료된 것은 아니다.

 

관계형 데이터베이스는 살아서 움직이기 때문에 그 외적인 여러 가지 설계가 추가 되어야 하는데 이 과정은 많은 부분이 '대용량 데이터베이스 솔루션' 시리즈에서 취급되었던 부분이므로 여기서는 다루지 않기로 한다.

 

추가적인 데이터베이스 설계의 주요 내용으로서는, 가령 각종 참조무결성과 같은 제약조건(constraints)을 정의를 한다든지, 뷰(view), 인덱스(index) 전략 수립, 테이블 파티션(partition) 설계, 저장공간 사용계획 수립 등의 추가적인 설계가 필요하다. 앞서 말했듯이 이 부분은 새로운 내용에 대해서는 앞으로도 계속해서 '대용량 데이터베이스 솔루션' 시리즈를 통해 개정판으로나 시리즈의 다음 판을 지속적으로 출판할 것을 약속한다. 다만, 워낙 시간이 없이 생활하는 관계로 약속된 시간에 출판하지 못할 수도 있음을 넓은 마음으로 이해하기를 바라마지 않는다.

 

한 가지 설명을 하지 않은 부분이 있다. 사실은 논리적 데이터 모델링과 데이터베이스 설계 사이에는 물리적 데이터 모델링이 존재한다. 이 과정은 현실에서 발생하는 물리적 요소, 가령 H/W적인 요소, DBMS적인 요소, 네트워크 관련 요소, 업무의 중요성, 엔터티 간의 친밀도, 결합도, 처리의 분포도 등 수많은 물리적인 요소를 감안하여 엔터티를 추가하거나, 분할, 속성의 중복화, 반정규화(de-normalization)등을 실시하는 과정이다.

 

다양한 물리적인 요소를 감안하여 최적의 최소비용으로 수행속도나 사용 상의 편의를 위한 물리적 데이터 모델링은 매우 H/W, DBMS 등에 종속적이고 이를 감안할 기술적인 요소들이 워낙 광범위하므로 여기에서는 다루지 않겠다.

 

다음 시간엔 실전 데이터 모델링의 단계에 대해 살펴보도록 하겠다.

[Top]
No.
제목
작성자
작성일
조회
435데이터 모델링 강좌(9)
정재익
2002-07-12
5362
434데이터 모델링 강좌(8)
정재익
2002-07-12
5510
433데이터 모델링 강좌(7)
정재익
2002-07-12
7120
432데이터 모델링 강좌(6)
정재익
2002-07-12
5841
431데이터 모델링 강좌(5)
정재익
2002-07-12
5481
430데이터 모델링 강좌(4)
정재익
2002-07-12
5484
429데이터 모델링 강좌(3)
정재익
2002-07-12
5819
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.018초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다