1 전산화란?

2 컴퓨터 세계는 단순하지만 현실은 복잡하다

3 데이터 모델링의 원칙: 추상화(Abstraction) 기법

4 데이터 모델링이란?

5 모델링을 통해 얻는 것

6 모델링의 고려사항

7 모델링과 성능과 무결성

8 모델링 권장 순서

다음의 두 이야기를 보자.

• 컴퓨터라는 것이 없는 시대의 편의점을 생각해보자. 편의점에서 쌀 1가마를 구입한다. 우리의 고객은 쌀 1가마에 해당되는 돈을 지불할 것이고, 거스름 돈을 고객에게 줄 것이며, 쌀 가게 주인은 장부에 기록을 할 것이다. 주인은 가게를 닫고 그 날의 쌀의 입고량과 출고량을 비교하여 재고[1]를 파악할 것이다. 또한 수입이 얼마인가 지출은 또 얼마인가 열심히 주판을 튕길 것이다. 재고량 계산과 수입과 같은 일은 매일 매일 반복되는 작업일 것이다.
  
  
• 그럼 컴퓨터가 있는 시대의 편의점을 생각해보자. 우리의 고객은 쌀 1가마를 구입한다. 주인은 바코드 인식기를 들고 찍을 것이다. 그럼 컴퓨터에 의해 지불된 돈과 쌀 1가마의 가격의 차이를 계산하여 거스름 돈이 얼마인가를 보여줄 것이다. 또한 그날의 재고량과 수입을 저절로 계산해 줄 것이다. 컴퓨터가 없던 시대에 매일 반복되는 작업이 없어지고 남는 시간을 통해 편의점 주인은 어린 아들과 좀 더 시간을 보낼 수도 있으며, 여가생활을 할 수 있거나, 조금 더 생산적인 지식 노동에 시간을 할애할 수 있을 것이다.
  
  

우리가 말하는 컴퓨터 즉, 전자계산기는 이런 생각에 기인하여 만들어졌다. 글을 보면 전산화란 현실세계의 어떤 일부를 컴퓨터 세계로 옮기는 작업일 뿐이라는 것을 알 수 있다. 그냥 옮기는게 아니라 아주 '잘' 옮겨야 한다.

마케팅 전문가인 쿠마르 교수의 '마케팅에 집중하라[2]'라는 책에서 '우리의 고객은 구멍을 뚫고 싶어하지 드릴을 사고 싶어하지 않는다'라는 말을 했다. 즉, 사용자는 단순 반복적인 일이나 어려운 계산을 빨리하고 싶어하지 UI가 화려하거나 복잡한 결과를 뿜어내어 보기조차 어려운 정보 시스템이 필요한 것이 아니다. 그러므로 사용자의 요구사항을 정확히 반영하는 일은 매우 중요하다.

어느 커뮤니티에 다음과 같은 질문이 올라왔다.

고객이 테이블이 있는데 사업자등록번호 고객번호가 바뀌어서 들어갔습니다. 손으로 일일이 고치기는 양이 너무 많습니다. SQL로 고칠 수 있을 것 같은데 저는 도저히 모르겠습니다. 도와주세요.

사업자등록번호와 고객번호가 뒤바뀌어 입력되었다는 것이다. 그것도 사람이 직접 고치기에는 그 양이 너무 많다는 만큼... 컴퓨터세계의 일이 아니라 현실세계에서 고객에게 보내는 문서에 사업자등록번호와 고객번호를 바꾸어서 공문을 보냈다면 어떻겠는가? 아마도 이런 실수로 몇 천, 몇 만 군데가 될 것이다. 한 두 군데라면 죄송하고 하고 다시 보내면 되겠지만, 이건 진짜 ‘아니올시다’ 이다.
위 문제는 쿼리로 해결한다고 해도 근본적인 문제는 개선되는 것이 아니다. 이것은 컴퓨터세계와 현실세계가 일치하지 않아서 생긴 문제다. 문제가 발생했을 당시의 현실은 불변이므로 컴퓨터 세계의 개혁이 필요한 것은 당연하다. (물론 현실이 변화하면 종속적인 컴퓨터 세계도 같이 변화해야 한다. 이것이 소프트웨어의 생명주기의 비용 60 ~ 70%를 차지하는 유지보수다.) 고객번호 자리에 사업자등록번호가 들어가지 못하게 하고, 그 반대의 경우도 마찬가지이다. 이것은 근본적인 설계의 문제라고 할 수 있다.

사원 테이블에 사원번호가 중복되게 들어가 있다. 중복된 로우가 없게 가져오고 싶다. 어떻게 해야 하는가?

Group By, Distinct 를 쓰면 되기는 한다. 또한 중복된 것을 삭제하고자 하기도 한다. 중복된 로우를 없애는 방법은 여러 솔루션이 이미 만들어진 상태이다. 그러나 역시 이것은 바로 내 앞에 닥친 문제만을 해결할 뿐이다. 원천적인 문제는 모델링과 설계의 잘못이다.
그렇다면 사원번호가 중복되었다는 것은 무엇을 의하는 것일까? 그것은 그 조직에 나와 똑 같은 사원이 존재한다는 뜻이 된다. 요즘에 인간복제가 이슈가 되는 상황인데 인간복제라도 했단 말인가? 이것이 바로 우리가 데이터베이스론 책에서 보아왔던 ‘개체무결성’ 이 깨진 것이다. 이래도 이론이 필요 없는가? 이론이 바탕이 되지 못한 모델링과 설계로 사원이 복제된 꼴이란 참으로 우습다. 사원번호가 1111 이 중복되어 있다면 그 사원에게 주어진 직무를 50%로 나누어서 시킬 수도 있는 노릇이다. 월급은 어떻게 줄 것인가? 두 사람 모두에게 월급을 줄 것인가? 이런 단순한 잘못 하나로 기업은 엄청난 손해를 입을 수도 있다. 그러므로 Group By, Distinct의 사용으로 중복의 문제를 해결하는 것은 눈 가리기 식의 임시 방편일 뿐이다. 원천적인 잘못은 개체무결성을 생각하지 않은 설계의 문제이다. 그러므로 중복된 데이터를 삭제 후 물리적으로 Primary Key를 설정해주는 것이 당연한 방법이라 하겠다.

전산화는 현실세계를 적당히 추상화시켜 모델링하고, 설계하여 컴퓨터세계로 옮기는게 전산화다. 당장 '전산화'가 무엇인지 사수나 옆 사람에게 물어보라. 얼마 고개를 끄덕이게 설명할 수 있는지..

컴퓨터는 오로지 '1'과 '0'의 세계이다. 지금 모니터에 보여지는 것도 여러분이 보고 있는 동영상도 따지고 보면 '1'과 '0'의 조합이다. 그러나 현실은 어떠한가? 너무나도 복잡하다. 예를 들어 필자의 얼굴을 컴퓨터 세계에 표현한다고 해보자. 얼굴의 가로/세로 길이는 얼마이며, 코는 어디쯤 붙어있고, 땀 구멍의 개수는 몇 개이며, 팔의 길이는 얼마이며, 흉터는 어디쯤 있고, 뾰루지는 어디쯤에 나 있는지... 너무나도 복잡하고 표현하기가 어렵워 현실적으로 컴퓨터 세계로 완벽히 옮기려면[3] 어느 정도 타협을 해야 한다. 바로 이 타협을 '추상화'라고 한다. 필자를 추상화하면 다음쯤이 될 것이다.

그림 2-1

추상화의 개념은 아주 쉽다. 알아 볼 수 있을 만큼(식별 가능한)만 표현하면 된다. 이러한 식별 가능한 정도를 결정하는 것을 '추상화 레벨의 결정'이라고 한다. 위의 그림처럼 머리, 몸, 팔, 다리와 이름, 주민번호, 성별만 필요한지 아니면 눈, 코, 입도 필요한지 사용자의 요구사항을 수집/분석하여 추상화 레벨을 결정해야 한다. 적절한 추상화 레벨의 선택은 시스템의 복잡성을 줄이고, 필요 없는 낭비 요소를 제거할 것이다. 사실 개념은 간단하지만 실제로 정보시스템을 구축할 때 추상화 레벨을 결정하는 것을 매우 어려운 일이다.

추상화는 다음과 같이 정의 된다.

추상화의 기법도 분류화(Classification), 집단화(Aggregation), 일반화(Generalization) 이렇게 3가지가 있다.

분류화(Classification) - member-of
분류화는 공통의 성질에 의해서 특징지어진 집합을 의미한다. 이것은 나중에 배울 속성의 개념과 같을 수 있다. 즉, 정보통신공학과, 국어국문학과... 이러한 것들은 ‘학과명’이 될 수 있는 것이다. 그러나 이러한 학과명을 갖는 여러 개의 개체들이 모이면 그림에서와 같이 ‘학과’라는 하나의 엔티티 집합이 탄생하는 것이다.

• 학과
  
  • 정보통신공학과
    
  • 국어국문학과
    
  • 광고홍보학과
    
  • ...
    
    

집단화(Aggregation) - part-of
집단화는 부분집합이 모여서 하나의 개념의 집합이 되는 것을 말한다. 즉, 하나의 부분집합은 하나의 요소가 되는 것이다. 다음 그림에서와 같이 여러 개의 요소(자동차 부품들)가 모여서 하나의 자동차라는 개념이 탄생하는 것이다.

• 자동차
  
  • 타이어
    
  • 핸들
    
  • 실린더
    
  • 기타
    
    

일반화(Generalization) - is-a
앞에서 살펴본 그림의 “자동차” 와 “학과” 는 하나의 클래스로 볼 수 있다. 클래스란 객체들의 공통의 성질로 모여있는 것을 의미한다. 일반화는 두개 이상의 클래스들의 원소들의 사이의 부분 집합 관계를 정의하는 것이다.

• 사람
  
  • 남자
    
  • 여자
    
    
    
    

데이터 모델링[4]이란, 현실에 존재하는 데이터[5]를 전산화[6]시키기 위해서 추상화 레벨을 결정하여 단순화, 가시화, 문서화시키는 작업이다. 말 그대로 데이터를 모델링하는 작업일 뿐이다. 흔히 데이터 모델링이라고 하면 흔히 ERD[7]를 떠올리는데, 이는 표기법의 한 종류일 뿐이다. UML의 Class Diagram으로도 표현할 수 있고, 의미-객체 모델의 표현방법도 있다. 하지만 보편적으로 ERD를 많이 사용하므로 ERD를 사용하는 것이 좋다. 왜냐하면 모델이라는 것 자체가 의사소통의 수단이기 때문이다. ERD가 가장 많이 쓰이는 이유는 표기법이 매우 간단하여 ERD를 모르는 사람도 간단한 설명만으로도 이해할 수 있으므로 다른 표기 방식에 비해 의사소통의 효과가 뛰어나기 때문일 것이다. ERD의 종류도 매우 많이 있다. 아직도 교과서에는 Chan방식[8]으로 많이 표현되고 있는데 현실에 맞지 않다. 옛날에는 정보시스스템의 규모가 크지 않아서 데이터의 표현에 무리가 없었겠지만 현재는 규모가 매우 커졌기 때문에 네모, 마름모, 타원현으로 데이터를 표현하기에는 단순성, 가시성이 떨어지고 문서(종이문서)로 프린트해서 보기에도 무리가 있다.

필자는 데이터 모델링이란 용어를 처음 접했을 때 그저 뜬 구름을 잡는 듯한 느낌을 받았다. 하지만 모델링이란 것 자체가 개뿔도 아니다. 여러분이 연습장에 끄적대는 것도 모델링이다. 순서도도 모델링이라고 볼 수 있고, 만화도 모델링이라고 할 수 있다. 필자는 이미 여러분이 알고 있는 것을 풀었을 뿐이다. 모델에 대한 이해는 다음의 문서를 참고하도록 하자.

왜_모델을_만드는가.zip

• 모델은 현실을 단순화 시키는 것 (추상화 레벨을 잘 결정해야 한다)
  
• 모델을 만들어 봄으로써 시스템의 이해를 돕는다.
  
• 현재 또는 원하는 모습으로 가시화.
  
• 업무에 대한 명세화.
  
• 시스템을 구축하는 틀 제공.
  
• 우리가 결정하는 것에 대한 문서화.
  
• 좋은 모델은 현실을 잘 반영한 모델이다.
  
  

• 최대한 객관화(모델링은 주관적인 것이 아니다.)
  
• 불확실한 업무를 확실하게 정의.
  
• 단순한 설계 (다중 사용자 환경, 사용자 및 개발자 등의 관계자와의 통신 프로토콜)
  
• 단순하면서도 성능을 최대한 이끌어 내야 한다.
  
• 현재뿐만 아니라 미래에 대한 고려까지 이루어져야 한다.
  
• 관계형 데이터베이스의 특성을 반영해야 한다.
  
• 모델링의 접근 전략과 사고의 객관화.
  
• 일의 순서를 정하는 것이 중요
  
  

모델링[9]을 하게 되면 정규화라는 강력한 도구를 이용하여 무결성과 성능을 동시에 보장하게 한다. 개체집합을 정의하고, 관계를 정의하고, 속성을 정의를 명확히 했다면 도메인과 무결성이 어느 정도 보장되었다는 의미이다. 물리적으로 구현되면 여러 가지 제약조건들이 개체, 관계, 속성들의 도메인이 무결성을 보장하고, 비즈니스 로직은 프로시저나 트리거로 구현이 된다. 이러한 것은 성능과 코딩의 양에 많은 영향을 준다. 무결성이 보장되지 못하면 자연히 어플리케이션 로직에서 무결성을 위한 코딩을 해야 한다. 그러므로 더 많은 개발시간과 더 많은 노력이 필요하다. 어플리케이션의 코딩량이 늘어난다는 것은 그만큼 어플리케이션에서 처리해야 할 것들이 많다는 것이 되므로 자연히 자원 사용량이 늘어난다. 여러분은 모델링과 설계가 코딩량을 줄여주고 모듈의 단순화에 매우 큰 영향을 준다는 것을 꼭 알아야만 한다.

1. 데이터 모델링을 위한 개념 정립
   
2. 도메인 레벨 정의
   
3. 개체집합의 후보 수집
   
4. 개체집합의 선정
   
5. 키 개체 집합의 단순화(통합)
   
6. 하위 개체집합에서 키 개체 집합 도출
   
7. 관계의 유무판단
   
8. 관계명 결정
   
9. 속성의 정의
   
10. 식별자 지정
    
11. 정규화
    
12. 다:다 관계의 해소
    
13. 순환관계 해소
    
14. 역할의 통합
    
15. 서브타입과 슈퍼타입으로 나눔
    
16. 관계의 통합
    
17. 이력관리