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 429 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 429
데이터 모델링 강좌(3)
작성자
정재익(advance)
작성일
2002-07-12 22:18
조회수
5,919
첨부파일: DM2.jpg (34,466bytes)

원본출처 : http://korea.internet.com/channel/content.asp?nid=18891&kid=3

 

우리가 지금까지 행해 왔던 데이터 모델링의 잘못을 바로잡기 위해서 우리가 지켜야 할 주요 원칙과 그 실행 전략을 살펴보기로 한다. 가장 먼저 우리가 타파해야 할 잘못은 데이터 모델링의 작성 수준에 관한 부분이다. 데이터 모델링을 단지 테이블(table)과 컬럼(column)의 모습을 결정하는 과정 정도로 생각해서는 안된다.

 

데이터 모델링은 아무 정보도 가지고 있지 않은 빈 백지 상태에서 시작해서 현재(as-is)업무를 파악하고 문제점을 도출하여, 미래(to-be)의 최적의 설계를 이끌어 내기 위해 인간이 해야 할 대부분의 결정을 내리는 단계까지를 모두 포함하는 과정을 말한다.

 

또한 데이터 모델링은 매우 구체적이고 상세한 수준으로 실시되어야 하며, 누구나 인정할 수 있는 객관적인 근거를 토대로 결정되고, 그 결과가 입체적으로 표현되어야 한다. 상세한 수준으로 실시되지 않은 데이터 모델은 개발 단계에서 프로그래머의 작위적인 판단에 의해 변질되거나 훼손이 발생하여, 규칙은 깨어지고 복잡성은 갈수록 심해지며, 시스템은 점차 자꾸만 썩어 들어 가게 된다.

 

우리가 비록 다양한 토론과 많은 고민을 통해 결정한 사항들도 미래라는 이름의 변화의 괴물은 계속해서 우리를 괴롭히게 된다. 언제나 머지않아 미래는 곧 현실이 되는 것이며, 미래를 미리 대비하지 않은 대가는 항상 우리의 발목을 잡게 된다. 더구나 데이터 모델링은 건물의 골조와 같은 것이기 때문에 상황에 따라서 쉽게 변경시키기가 매우 어렵다.

 

이를 대비하기 위하여 우리가 해야 할 일은 데이터 모델에 융통성을 부여하는 것이다. 유연한 갈대가 강풍에도 잘 무러지지 않는 것처럼 변화의 강풍에 유연하게 대처할 수 있는 데이터 모델을 설계하는 것은 매우 중요하다. 그러나 융통성은 곧 비용(cost)로 나타나며, 비용을 무시한 현실은 또 다른 문제를 낳게 될 것이므로 여러가지 요소들을 두루 감안한 전략적인 결정은 유일하게 인간만이 할 수 있는 것이며 참으로 쉽지 않은 일일 것이다.

 

이러한 종합적인 판단을 하기 위해서 우리에게 가장 필요한 것은 확실하고 객관적인 결정을 할 수 있는 근거를 마련해 주는 ‘판단의 근거’와 이를 현실에 적용하기 위해 현실을 정확히 분석할 수 있는 수사력, 그리고 이것을 종합하여 최적의 결론을 도출할 수 있는 사고력일 것이다.

 

모델링은 방법을 알고 있다고 해서 쉽게 할 수 있는 것이 아니다. 어쩌면 방법 이전에 지금까지 자신이 인생을 살면서 직,간접적으로 취득해 왔던 많은 경험과 사고능력, 판단력, 적극성 등이 더 필요한 지도 모른다. 이런 의미에서 필자는 모델링을 단순한 ‘방법의 습득 차원’이 아닌 ‘사고능력의 개발 차원’에서 접근해야 한다고 믿는 사람이다.

 

* 데이터 모델링의 작성수준

 

앞서 데이터 모델은 건물의 골조와 같은 것이라고 했다. 이 말은 곧 ERD는 바로 설계도인 것이며 건물의 설계도처럼 상세하고 구체적으로 작성되어야 한다는 것을 의미한다. 우리가 알고 있는 도면에는 두가지가 있다. 하나는 복덕방에 가면 볼 수 있는 ‘평면도’이며, 다른 한가지는 건축현장에서 사용하는 ‘청사진’이다.

 

물론 평면도를 보아도 건축물이 어떻게 구성되었는 지를 대략은 알 수가 있다. 안방, 건너방, 마루, 식당 등이 모두 표시되어 있다. 그러나 이 도면은 건물을 짓는 사람들을 위한 도면이 아니라 그 건물을 사용할 사람을 위한 도면일 뿐이다. 만약 이 도면을 주고 아파트를 건축해 달라고 한다면 그는 정신병자 취급을 받지 않을 수 없을 것이다. 그러나 이런 상식을 초월한 일이 일반인들이 가장 우러러 보는 전문 직종의 하나인 정보시스템 개발에서 자행되고 있다는 것은 참으로 아이러니 하다.

 

커다란 엔터티 박스에 그저 깨알같이 박혀 있는 속성뿐인 ERD나 복덕방의 평면도나 다를 것이 무엇인가! 거기 어디에 길이와 높이가 있고 재질이 나타나 있는가? 여기에 문이 있다는 표시만 있지 어떤 종류의, 어떤 높이의 문이 정확히 어디에 달려 있어야 하는 지는 전혀 나타나 있지 않다.

 

우리가 작성한 ERD는 어떠한가? 가령, ‘사원’ 엔터티가 있다고 가정했을 때 속성이 ‘사번, 성명, 주민번호,…’로 구성되어 있다는 것만 나타나 있지 구체적으로 정의되어 있는 것이 어디 한 가지라도 제대로 있는가?

 

아래의 그림을 통해 우리는 데이터 모델이 최소한 어느 수준까지는 작성되어져야 할 것인지 서로 비교해 보기로 하자.

 

 

[그림1]

 

위의 두 그림을 비교해 보자. 좌측의 [그림1]은 엔터티가 사원을 관리한다는 것만 나타나 있을 뿐이지만 우측 그림은 우리가 관리하는 사원 엔터티가 ‘내근사원’,’설계사’,’대리점’으로 구성되어 있으며, 좌측 그림처럼 단순히 관리할 속성들이 나열만 되어 있는 것이 아니라 공통 속성들과 부분집합별 독립 속성이 구체적으로 나타나 있을 뿐만 아니라 다른 엔터티와 맺고 있는 관계 또한 공통 관계인지, 특정 부분집합만이 갖는 개별 관계인지를 구체적으로 나타내고 있다.

 

또한 관계의 내용도 단지 선분만 그어져 있는 좌측과는 달리 우측 그림은 관계의 구체적인 내용과 특기사항까지도 상세히 표현되어 있다. 이상에서 볼 수 있듯이 지금까지 우리가 작성한 데이터 모델은 평면도 수준을 넘지 못한다. 더구나 뒤에서 소개할 엔터티의 보조자료로 정의될 ‘엔터티 정의서’, ‘속성 정의서’에 담겨질 매우 상세한 정의는 애초부터 작성할 생각조차 없었으며, 단지 컬럼명과 데이터 타입(data type), 길이(length), 비고 등이 나타나 있는 ‘데이블 정의서’ 정도가 설계의 결과로 나타난 최종 산출물이다.

 

오직 구체적인 내용이 정의되어 있는 곳은 해당 업무를 담당하는 정보시스템 담당자의 머리 속일 뿐이다. 그러나 사실은 그 머리 속에도 정확한 정보는 저장되어 있지 않다. 이것은 필자가 컨설팅을 위해 관련된 현황을 파악하고자 할 때 항상 겪는 일이다. 담당자는 프로그램 유지.보수에 필요한 수준 이상을 알지 못하고 있다. 조금만 깊이 질문해 들어 가면 금방 자신이 없어진다. 이것이 우리의 현 주소이며, 어느 곳에서나 자주 나타나는 아주 심각한 증상이다.

 

거듭 말하지만 데이터 모델은 건축 공사 현장에서 사용되는 청사진 수준이 되어야 한다. 평면도 수준의 개략적인 설계도를 공사현장에 던져 주면 자세한 사항은 현장에서 그들의 경험에 의존하여 작위적으로 처리될 것임은 너무나 당연하다. 데이터 모델링도 이와 마찬가지로 [그림1]과 같은 ERD를 개발부문에 던져 주면 자세한 사항은 프로그래머가 작위적으로 판단하여 개발하게 되는 것은 너무나 당연한 일이다.

 

이러한 설계도가 나타난 실상을 파헤쳐 보면 어쩌면 설계자가 세부적인 내용을 현장에 있는 사람들 보다 잘 모를 수도 있기 때문에 이렇게 하는 것이 오히려 더 나았는 지도 모른다. 마찬가지로 시스템 개발에도 설계자의 능력이 그 정도 밖에 이르지 못했다고 보는 것이 맞을 지도 모른다. 참으로 걱정되고 슬픈 일이다.

 

전체를 내다보는 설계자의 통일된 컨셉이 없이 각각의 세부내용이 작위적으로 처리된다면 필연적으로 다양한 문제점이 나타날 것이며, 이를 해결하기 위해 대다수 프로젝트의 후반기는 끝없는 수정과 테스트로 점철되곤 한다.

 

 

 

[그림2]

 

위의 그림은 필자가 어떤 프로젝트에서 수행했던 데이터 모델의 일부분이다. 여러분들이 작성했던 것과 비교했을 때 무엇을 느꼈는가? 아마 복잡하다는 생각이 가장 먼저 들었을 것이다. 만약 정말로 이런 생각이 들었다면 문제는 심각하다.

 

왜냐 하면 이 그림이 복잡하다는 생각을 했다는 것은 자신이 설계 전문가가 아니라는 것을 웅변적으로 증명해 주고 있기 때문이다. 우리는 전자 제품이나 자동차에 문제가 생겼을 때 전문적으로 수리하는 사람이 보는 회로도를 보고 문제를 진단하고 해결해 가는 것을 볼 떄가 있다. 아니면 어떤 공장에 견학을 갔을 때 공정에서 작업 중인 사람들이 보고 있는 설계도면을 본 경우가 있을 것이다.

 

내용을 잘 모르는 우리가 보면 분명히 복잡하기 이를 데 없는 그림이다. 그러나 그들에게 물어 보라. 자신이 보는 그림이 복잡한 지를.

 

작업을 하기 위해 상세한 내용이 들어 있는 그림은 복잡하다는 생각을 하지 않지만 내용을 알 수 없는 개념도만 주고 문제를 해결하거나 공정 작업을 하라고 하면 그들은 크게 화를 낼 것이 분명하다. 이와 같이 전문적으로 그 일을 하는 사람에게는 상세한 내용은 절대 복잡하다고 생각하지 않는다. 복잡하다고 생각하는 사람은 이미 그 일에는 직접 관련이 없는 사람들이거나 아직 숙달되지 않은 초보자라고 보는 것이 옳을 것이다.

 

자! 여러분은 어디에 속한다고 생각하는가? 각자의 판단에 맡기기로 하겠다.

 

다음 시간엔 데이터 모델링의 객관화에 대해 살펴보기로 하자.

[Top]
No.
제목
작성자
작성일
조회
432데이터 모델링 강좌(6)
정재익
2002-07-12
5951
431데이터 모델링 강좌(5)
정재익
2002-07-12
5580
430데이터 모델링 강좌(4)
정재익
2002-07-12
5593
429데이터 모델링 강좌(3)
정재익
2002-07-12
5919
428데이터 모델링 강좌(2)
정재익
2002-07-12
6253
427데이터 모델링 강좌(1)
정재익
2002-07-12
8380
426Java Language 완전정복
정재익
2002-07-12
4943
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.016초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다