맛있는 데이터베이스를 위한 재료 준비, 데이터 모델링과 분석 설계
데이터 모델링은 더 이상 특정 분야에 국한된 전문가들만의 영역이 아니다. 데이터베이스와 연관이 있는 모든 관련자들이 관심을 두어야 하는 영역이 되었다. 데이터 모델링은 정보 시스템의 관련 데이터베이스가 좋은 성능을 발휘하고, 사용자들의 다양한 요구 사항을 정확하고, 완전하게 구축하기 위해서 관련자들이 반드시 숙지해야 하는 데이터베이스 설계 기법이다.
데이터 모델링은 데이터베이스 모델링 이라고도 하며, 다른 말로는 개체-관계(Entity-Relationship) 모델링이라고도 한다.
데이터 모델링은 기업의 정보 구조를 중요한 3 대 요소인 개체(Entity), 관계(Relationship), 속성(Attribute)을 중심으로 명확하게 체계적으로 표현하고 문서화하는 기법이다. 정보 시스템 구축 중심을 데이터 관점에서 접근하는 분석/설계 방법으로 정보 시스템 내의 모든 데이터 구조를 연계하여 최적의 데이터베이스 구조를 도출해 낸다.
개체, 관계, 속성에 대한 정의는 여러 가지 있을 수 있으나, 간략히 정리해 보면 다음과 같다.
● 개체: 데이터베이스 내에 표현하고자 하는 정보를 포함하는 유형/무형의 파일 시스템의 레코드(Record)에 해당되며 정보를 표현하는 논리적인 단위
● 관계: 두 개 이상의 개체들 간에 연관성을 결정짓는 의미 있는 연결
● 속성: 개체의 성질, 분류, 식별, 수량, 상태 등을 나타내는 세부 정보의 관리 요소로써 관계형 데이터베이스에서 사용되는 데이터의 최소 단위
이와 함께 중요하게 다루어지는 또 하나의 요소는 식별자(Identifier) 이다.
● 식별자(Identifier) : 데이터베이스 시스템에서 로우 또는 오브젝트를 구분하기 위하여 부여된 자신만을 식별할 수 있게 하는 고유한 숫자 또는 문자이다. 개체에 존재하는 속성들 중에서 데이터 관리를 위하여 특별한 의미를 갖는 속성 또는 속성의 집합으로 구성
데이터 모델링 단계
데이터 모델링은 논리 데이터 모델링과 물리 데이터 모델링으로 구분되며, 이는 데이터베이스 설계의 단계에 따라 구분하는 방법이다. 먼저 논리 데이터 모델링은 외부 스키마 즉, 사용자들의 요구 정보를 데이터베이스에 저장하기 위한 구조로 변환하는 작업으로써 개념 스키마(논리 스키마)를 설계하는 행위를 말한다. 물리 데이터 모델링은 논리 데이터 모델링의 결과인 개념 스키마를 대상으로 구축하고자 하는 데이터베이스 특성을 고려하여 내부 스키마(물리 스키마)로 변환하는 작업을 수행하는 행위이다.
<그림 1>은 데이터 모델링 단계를 데이터베이스 스키마 구조와 연관 지어 표현한 것이다.
본 특집은 데이터 모델링을 소개하는 것이 아니라, 데이터 모델링을 수행하는 과정 즉, 데이터 모델 설계에 대한 내용이다. 보다 상세한 데이터 모델링 관련 내용이 필요한 독자들은 데이터 모델링 관련 서적을 참조하기 바란다. 데이터 모델링을 수행하기 위한 분석/설계 방법에는 데이터 모델링이 소개되던 초기에 데이터 모델러들이 활용하던 구조적 분석/설계 방법론에서 정보 공학 방법론, 그리고 최근의 객체-지향 분석/설계 방법에 이르기까지 매우 다양한 방법이 있다. 하지만 데이터 모델링은 어떤 분석/방법론을 이용하는가 보다는 사용자들이 요구하는 모든 정보를 얼마나 잘 도출해 낼 수 있느냐가 더욱 중요하다.
또한 단순히 데이터 흐름을 파악하여 데이터 구조만을 설계하는 단순한 데이터 모델보다는, 수행하는 업무를 정확히 분석하고 각 업무들에서 필요로 하는 정보가 무엇인가를 파악하여 데이터 모델에 반영시키는 것이 중요하다. 이제 좋은 데이터 모델을 설계하기 위해 꼭 알아두어야 하는 방법들에 대해 알아보자.
<그림1> 데이터베이스 스키마와 데이터 모델링 단계
논리 데이터 모델링
논리 데이터 모델링은 앞에서도 언급한 바와 같이 정보 시스템의 데이터베이스에 저장되어야 하는 데이터를 도출하여 최적의 저장 구조로 저장될 수 있는 데이터베이스 구조를 도출하는 것이다. 논리 데이터 모델링을 수행하는 방법은 하향식(Top-Down) 방법과 상향식(Bottom-Up) 방법으로 구분된다. 하향식 방법은 데이터베이스에 저장되어야 하는 개체를 먼저 도출하고, 속성을 도출 및 관계를 설정하는 방법으로 논리 개체-관계도를 작성한다. 따라서 이는 해당 업무(사업)에 대하여 잘 알고 있는 관련자들과 업무 협의를 거쳐 협의 결과로 도출된 내용을 기준으로 개체를 도출하고, 도출된 개체들의 관계를 설정하며, 도출된 개체에 적절한 속성을 추가한다. 상향식 방법은 현재 사용자들이 사용하고 있는 업무와 관련된 장표/양식/관리대장/관련문서 등을 분석하여 논리 개체-관계도를 작성하는 방법이다.
하향식 방법
하향식 방법은 주로 업무 분석한 내용을 간단한 형식의 단 문장으로 정리한 시나리오를 사용한다. 예를 들면, 구매발주 부서에서 업무 협의한 내용을 <리스트 1>과 같이 정리해 볼 수 있다.
<리스트 1> 구매 발주 업무 시나리오
1) 각 부서에서 구매의뢰를 한다.
2) 구매의뢰에 따라 구매발주가 이루어진다.
3) 구매의뢰는 구매의뢰번호를 주 식별자로 관리하며 구매의뢰일자 및 구매품목과 관련된 내용들을 관리한다.
4) 구매발주는 구매발주번호로 관리되며, 구매발주일자 등의 내용을 관리한다.
5) 한건의 구매의뢰는 여러 번 발주될 수 있다.
6) 여러 건의 구매의뢰를 한꺼번에 발주할 수는 없다.
7) 발주되는 품목인 발주자재는 자재-Master에 주 식별자 자재코드로 관리된다.
8) 자재-Master에는 자재명, 규격, 측정단위 등의 정보가 관리되어야 한다.
9) 한건의 발주는 한 거래처에 한 장의 구매발주서로 발행된다.
10) 거래처에는 거래처코드, 거래처명, 사업자등록번호 등의 정보가 관리된다.
11) 한 장의 구매발주서에는 여러 품목을 발주할 수 있다.
12) 단일 의뢰 및 발주에는 같은 품목을 여러 번 의뢰, 발주할 수 없다.
시나리오를 이용한 하향식 데이터 모델링 방법은 먼저 구축하고자 하는 정보 시스템과 관련이 있는 관련자들로부터 업무 설명 및 업무 협의를 수행하여 도출된 내용을 간단한 문장으로 정리하는 것으로부터 시작한다. 물론 여기에 제시한 예제는 특정 업무 전체를 정리한 것은 아니지만, 독자 여러분들에게 하향식 데이터 모델링 방법을 설명하기에는 충분하다고 생각된다.
다음으로는 정리된 시나리오에 나타나는 모든 명사들 중에서 데이터베이스에 저장되어 정보로 관리되어야 하는 명사들을 도출한다. 도출되는 명사들을 정리해보면 <리스트 2>와 같이 된다.
<리스트 2> 구매 발주 업무 명사 도출
1) 부서, 구매의뢰
2) 구매의뢰, 구매발주
3) 구매의뢰, 구매의뢰번호, 구매의뢰일자, 구매품목
4) 구매발주, 구매발주번호, 구매발주일자,
5) 구매의뢰, 발주
6) 구매의뢰, 발주
7) 발주, 품목, 발주자재, 자재-Master, 자재코드
8) 자재-Master, 자재명, 규격, 측정단위
9) 발주, 거래처, 구매발주서
10) 거래처, 거래처코드, 거래처명, 사업자등록번호
11) 구매발주서, 품목, 발주
12) 의뢰, 발주, 품목, 의뢰, 발주
다음은 도출된 명사들을 정리하는 단계이다. 이 단계는 도출된 명사들이 같은 의미를 갖는 여러 가지 명사로 표현할 수 있으므로 이러한 명사들은 한 개만 남기고 모두 제거하거나, 대체하는 과정이다.
먼저, ‘의뢰’와 ‘발주’는 각각 ‘구매의뢰’와 ‘구매발주’를 의미하므로 이를 ‘구매의뢰’와 ‘구매발주’로 대체하고, ‘구매발주서’는 ‘구매발주’의 결과 산출물이므로 ‘구매발주’로 대체한다. 그리고 ‘품목’, ‘구매품목’, ‘발주자재’, ‘자재-Master’는 같은 내용을 서로 다른 명칭으로 설명한 것이므로 이들을 모두 ‘자재-Master’로 대체한다. 이를 정리하면 <리스트 2> “구매 발주 업무 명사 도출”에 나타난 내용을 기준으로 <리스트 3>과 같이 정리할 수 있다.
<리스트 3> 구매 발주 업무 명사 대체
1) 부서, 구매의뢰
2) 구매의뢰, 구매발주
3) 구매의뢰, 구매의뢰번호, 구매의뢰일자, 자재-Master
4) 구매발주, 구매발주번호, 구매발주일자,
5) 구매의뢰, 구매발주
6) 구매의뢰, 구매발주
7) 구매발주, 자재-Master, 자재-Master, 자재-Master, 자재코드
8) 자재-Master, 자재명, 규격, 측정단위
9) 구매발주, 거래처, 구매발주
10) 거래처, 거래처코드, 거래처명, 사업자등록번호
11) 구매발주, 자재-Master, 구매발주
12) 구매의뢰, 구매발주, 자재-Master, 구매의뢰, 구매발주
이를 다시 간략히 정리하면 <리스트 4>와 같이 정리할 수 있다.
<리스트 4> 구매 발주 업무 명사 정리
1) 부서, 구매의뢰
2) 구매의뢰, 구매발주
3) 구매의뢰, 구매의뢰번호, 구매의뢰일자, 자재-Master
4) 구매발주, 구매발주번호, 구매발주일자,
5)
6)
7) 구매발주, 자재-Master, 자재코드
8) 자재-Master, 자재명, 규격, 측정단위
9) 구매발주, 거래처
10) 거래처, 거래처코드, 거래처명, 사업자등록번호
11)
12) 구매의뢰, 구매발주, 자재-Master
다음 단계는 속성화 대상 명사의 정리이다. 이 단계는 남아있는 명사들 중에서 속성, 즉 해당 개체의 데이터 항목으로 존재해야 할 명사들을 파악하여 정리하는 단계이다. 속성화 대상 명사들을 정리해보면 <리스트 5>와 같이 표현된다.
<리스트 5> 구매 발주 업무 속성화 대상 명사 정리
1) 부서, 구매의뢰
2) 구매의뢰, 구매발주
3) 구매의뢰(구매의뢰번호, 구매의뢰일자), 자재-Master
4) 구매발주(구매발주번호, 구매발주일자)
5)
6)
7) 구매발주, 자재-Master(자재코드, 자재명, 규격, 측정단위)
8) 자재-Master,
9) 구매발주, 거래처(거래처코드, 거래처명, 사업자등록번호)
10) 거래처,
11)
12) 구매의뢰, 구매발주, 자재-Master
‘구매의뢰번호’와 ‘구매의뢰일자’는 ‘구매의뢰’의 속성이 되고, ‘구매발주번호’와 ‘구매발주일자’는 ‘구매발주’의 속성이 된다. 또, ‘자재코드’, ‘자재명’, ‘규격’과 ‘측정단위’는 ‘자재-Master’의 속성이 되고, ‘거래처코드’, ‘거래처명’과 ‘사업자등록번호’는 ‘거래처’의 속성이 된다.
이제 ‘4) 구매발주’, ‘8) 자재-Master’ 그리고 ‘10) 거래처’는 개체-관계도를 작성하기에는 의미 없는 명사이므로 제거해도 된다. 현재 도출된 명사 중에서 개체로 도출되는 명사는 ‘부서’와 ‘구매의뢰’, ‘구매발주’, ‘자재-Master’, ‘거래처’라는 것을 알 수 있기 때문이다. 독자적으로 존재하는 개체는 다른 부분에 이미 포함되어 개체화 할 필요가 없는 명사이기 때문에 제거의 대상이다. <그림 2>는 이러한 근거로 개체를 도출하여 도표로 만든 것이다.
<그림2> 구매 발주 업무 개체 도출
<그림 2>를 보면 시나리오에는 없는 ‘부서코드’와 ‘부서명’ 속성을 ‘부서’ 개체의 속성으로 설정한 것을 확인할 수 있다. 그 이유는 개체들은 개체에 존재하는 모든 인스턴스들을 유일하게 식별할 수 있어야 한다는 개체 무결성 제약조건이 존재하기 때문이다. 또, 개체들 간의 관계를 설정하기 위해서는 모든 개체에 주 식별자가 존재해야 하기 때문이기도 하다.
이제 도출된 개체들의 관계를 설정할 차례이다. 데이터 모델링이 익숙하지 않거나, 업무를 잘 모르는 사람들에게는 관계를 설정하는 것이 너무 막연한 일이다. 그러나 주어진 시나리오에 존재하는 동사들이 데이터베이스에 존재하는 개체들 간의 관계를 결정한다는 사실만 기억한다면, 개체들 간의 관계 설정이 어렵지 않은 일이라는 것을 파악할 수 있을 것이다.
<리스트 6>은 주어진 시나리오를 분석하여 동사를 도출하고 관련 개체를 정리한 예제이다. 동사를 정리할 때에는 <리스트 6>과 같이 개체를 도출하기 바로 전 상태의 정리된 시나리오를 활용하는 것이 좋다. <리스트 6>은 구매 발주 업무 시나리오의 동사를 정의한 것이다.
<리스트 6> 구매 발주 업무 시나리오의 동사 정리
1) 한다. (부서, 구매의뢰)
2) 이루어진다. (구매의뢰, 구매발주)
3) 관리한다. (구매의뢰, 자재-Master)
4)
5)
6)
7) 관리된다. (구매발주, 자재-Master)
8)
9) 발행된다. (구매발주, 거래처)
10)
11)
12) 없다. (구매의뢰, 구매발주, 자재-Master)
이제 동사 뒤에 위치시킨 개체들 간의 관계를 설정할 차례이다. 예를 들어 ‘1) 한다. (부서, 구매의뢰)’를 살펴보면 ‘부서’ 개체와 ‘구매의뢰’ 개체가 관계를 맺어야 한다는 것을 알 수 있다. 또 다른 예제로 ‘3) 관리한다. (구매의뢰, 자재-Master)’를 살펴보면 ‘구매의뢰’ 개체와 ‘자재-Master’ 개체가 관계를 갖는다는 것을 알 수 있다. 이때 관계 설정의 차수를 정확하게 표현할 수 있도록 해야 한다. 차수의 종류 및 자세한 설명은 많은 관련 서적들에 정리되어 있으므로 여기에서는 생략한다.
일반적인 구매 발주 업무의 경우를 예제로 관계를 설정하면 <그림 3>과 같이 표현될 수 있다.
<그림3> 구매 발주 업무 관계 도출
관계를 설정할 때에는 특정 개체를 대상으로 발생하는 상대 개체의 데이터 발생 비율을 파악한 뒤에 차수를 결정해야 한다. 예를 들어 하나의 부서에서 구매의뢰를 하지 않을 수도 있고, 한번만 할 수도 있고, 여러 번 할 수도 있기 때문에 1:0, 1:1, 1: n을 모두 표현했다. 그리고 다른 예로 시나리오에 나타나있는 내용을 근거로 관계를 설정한 ‘구매의뢰’와 ‘구매발주’ 개체의 관계를 들 수 있다. 이는 ‘5) 한건의 구매의뢰는 여러 번 발주될 수 있다.’와 ‘6) 여러 건의 구매의뢰를 한꺼번에 발주할 수는 없다.’라는 내용에서 ‘구매의뢰’와 ‘구매발주’ 개체의 관계는 1:0, 1:1, 1:n으로 결정되는 것이다. 특히 ‘구매의뢰’와 ‘자재-Master’ 개체, 그리고 ‘구매발주’와 ‘자재-Master’ 개체의 관계가 n:n 관계로 설정되는 것에 주의를 기울여야 한다. 이러한 관계를 다:다(Many-to-Many) 관계라고 하며, 이런 관계는 교차 개체(Intersection Entity)를 삽입하여 제거해야 한다. 교차 개체는 다:다 관계를 발생 시킨 개체들 사이에 위치시키며, 다:다 관계를 발생시킨 개체들의 주 식별자를 새로 생성되는 개체의 주 식별자로 설정한다(특별한 업무의 경우에는 예외적으로 만들 수 있음). 이를 반영하여 <그림 3>을 변경해 보면 <그림 4>와 같은 구매 발주 업무 개체-관계도를 작성할 수 있다.
<그림4> 구매 발주 업무 개체-관계도
데이터 모델링 초보자들은 이 교차 개체를 도출하는 방법과 관계를 설정하는 방법에 특히 주의를 기울여야 한다. 따라서 독자들도 자신이 구축해야 하는 데이터베이스와 관련된 업무를 수행하는 관련자와 업무 협의를 수행한 뒤에 <리스트 2>와 같은 시나리오만 잘 작성할 수 있다면 논리 개체-관계도를 만들 수 있는 것이다. 이러한 방법이 하향식 데이터 모델 설계 방법이다.
●상향식 방법
상향식 방법은 수집된 장표/양식/관리대장/관련문서 등에서 속성을 도출하여 정규화 과정을 수행함으로서 논리 개체-관계도를 도식해 가는 방법이다. 정규화 방법을 이용하여 논리 개체-관계도를 도식할 때에는 함수적 종속 관계를 정확하게 이해해야 하므로 데이터베이스 관련 서적에서 함수적 종속에 대한 내용을 찾아 숙지하면 많은 도움이 될 것이다.
먼저, <그림 5>와 같은 ‘판매 전표’를 대상으로 상향식 데이터 모델링 방법에 대해 알아보자.
<그림5> 판매전표
<그림 6>은 판매 전표에 나타나는 속성들을 정리한 것이다. 이 전표에서 ‘판매일자’, ‘부서코드’, ‘판매순번’은 중복을 피하기 위한 주 식별자로 선정되었고 나머지 속성들은 모두 일반 속성으로 정리했다. 물론 ‘판매일자’와 ‘판매순번’ 속성만으로도 주 식별자가 가능하지만, 함수적 종속을 상세하게 설명하기 위하여 내용과 같이 정리했다. 특히 ‘제품번호’, 제품명’, ‘단가’, ‘수량’, ‘금액’과 같이 여러 번 반복되는 속성들은 반드시 반복적으로 표현해야 한다.
<그림6> 판매 전표 기본 자료
1차 정규화는 반복 그룹(Repeat Group) 속성들을 제거하는 것이므로 <그림 6>에서 3회 반복되는 속성들을 하위 개체로 분리하면 된다. 하위 개체로 분리할 때 주의해야 하는 점은 하위 개체에 상위 개체인 ‘판매전표’의 주 식별자가 외래 식별자(Foreign Identifier)로 존재해야 한다는 점이다. <그림 7>은 이러한 내용을 반영하여 정리한 것이다.
<그림7> 판매 전표 1차 정규화 예제
2차 정규화는 1차 정규화의 결과를 대상으로 주 식별자 전체에 완전 기능 종속(Non Fully Dependency)되지 않는 속성을 제거(주 식별자 속성 일부분에 함수적 종속되는 속성 제거)하는 것이다. 개체에 존재하는 속성들 중에서 주 식별자의 일부에만 함수적으로 종속되는 속성들을 종속을 유발하는 속성들과 함께 상위 개체로 분리하면 된다. 이 예제에서는 ‘판매전표’ 개체의 주 식별자 속성 중에 하나인 ‘부서코드’에 종속되는 ‘부서명’, ‘부서실적’과 ‘제품’ 개체의 주 식별자 속성 중에 하나인 ‘제품번호’에 종속되는 ‘제품명’, ‘단가’ 속성들을 새로운 상위 개체로 도출하면 된다. <그림 8>은 판매 전표 2차 정규화의 예제이다.
<그림8> 판매 전표 2차 정규화 예제
3차 정규화는 주 식별자에 이행 종속(Transitive De pendenc
y) 되는 속성들을 제거하는 것이다. 여기에서 이행 종속을 이해해야 하는데, 수학적으로 이행 종속을 이해해서 정규화를 이해하려 하지 말고, 개체에 존재하는 일반 속성들의 함수적 종속 관계를 파악하면 3차 정규화는 쉽게 할 수 있다는 것을 알 수 있다. 이 예제에서는 ‘판매전표’ 개체의 일반 속성인 ‘판매사원번호’ 속성에 ‘사원명’이 함수적 종속이고, ‘고객번호’ 속성에 ‘고객명’, ‘고객주소’, ‘누적판매량’, ‘채권액’ 속성이 함수적 종속 관계라는 것을 알 수 있다. 따라서 이 속성들을 함수적 종속을 유발하는 속성을 주 식별자로 하여 새로운 상위 개체로 도출하면 된다. 이 내용을 다시 정리하면 <그림 9>와 같이 표현된다.
<그림9> 판매 전표 3차 정규화 예제
물론 정규화는 1~3차 정규화 뿐 아니라, 4차, 5차, 그리고 그 외에도 많은 정규화 과정이 있지만 여기에서는 3차 정규화까지만 설명한다. 이러한 방법으로 개체-관계도를 도출해 가는 방법을 상향식 데이터 모델링 방법이라 한다.
데이터 모델링과 관련하여 보다 상세한 사항에 관심이 있는 독자들은 필자가 운영하는 데이터베이스 관련 카페( http://cafe .daum.net/DBDB)에서 보다 많은 자료를 얻을 수 있다.