제 6장 데이터모델링

본 장의 목적은 데이터 모델링을 다루고자 함이 아니라, 대부분의 사용자들이 정확한 모델링을 실시하지 않은 채 시스템을 구축하고 있어 필연적으로 많은 문제점들을 양산하므로 간단하게나마 모델링에 대해 언급하는 것이다.

1 기본 개념 데이터모델링

데이터 모델링 이란..."정보화 시스템을 구축하기 위해 어떤 데이터가 존재하는지 또는 업무에 필요한 정보는 무엇인지 분석하는 방법"

모델링은 시스템의 대상이 되는 업무를 분석하여 정보와 시스템으로 구성하는 과정(분석/설계)에서 업무의 내용과 정보 시스템의 모습을 적절한 표기법(Notation)으로 표현하는 것을 모델링 이라고 한다.

1.1 엔터티(Entity)

엔티티란 "업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것으로 영속적으로 존재하는 단위"

정보가 저장될 수 있는 사람, 장소, 물건, 사전 그리고 개념을 정의할 수 있는 것으로 정보 시스템을 구현할때 데이터베이스 테이블에 해당되는 데이터 모델링에서 가장 중요한 표기법이다.

1.2 관계(Relationship)

관계란 "엔터티간의 상관관계를 양방향으로 표현하며, 현재의 관계나 장래 유용한 관계만 한정적으로 표시"

가. M:1 (Many to One) 관계

가장 일반적인 형태로,

• 관계형태는
  • 한쪽 방향은 하나이상(one or more),
  • 다른 방향은 단하나씩(one and only one) 이며,
• 선택사양은
  • 보통 Must be 와 May be 로 지정되나
  • 드물게는 양방향 Must be 로도 지정된다.

나. M:N (Many to maNy) 관계

자주 발생되는 형태로서, 양쪽 방향 모두 하나이상(one or more)이며, 상세개념모델(Advanced Conceptual Data Modeling) 단계에서 분할된다

다. 1:1 (One to One) 관계

양쪽 방향 모두 단 하나씩(one and only one)이며, 양방향 모두 반드시(must be)가 되는 경우는 아주 드물다
1:1 관계는 실제로는 동일한 ENTITY 일 경우가 많고, 1:1 관계가 많이 나타난다면 Entity 가 명확하게 정의되지 않았음을 의미한다.

라. 관계형 메트릭스

각 ENTITY 간의 초기 단계의 관계를 정의하기 위한 보조자료로 활용되고 있으며,

• Key Entity와 Main Entity를 가로, 세로로 배열하고,
• 일단 제3자 입장에서 관계 유무만 판단하여 표시한다.
• 또한 1차 표시된 것들에 대해 구체적인 관계명칭을 찾으면서 관계 유무를 최종 판단하고,
• 상관관계가 없으면 DASH를 표시한다.
• 세로에 있는 ENTITY가 주어가 된다
• 순환(recursive) 관계는 대각선 BOX 에 기술되고,
• RELATIONSHIP MATRIX의 내용을 이용해 E-R을 그린다

1.3 속성(Atrribute)

엔터티 내에서 관리해야 할 정보들의 항목을 속성이라 한다.
속성의 명칭은 의미가 명확하고, 내용을 함축성있게 부여하여야 하며, 집합개념(분자단위)의 속성은 단순개념(원자단위)으로 분할하여 가능한한 최소 단위까지 분할한 후, 괸리 필요에 따라 통합한다.또한 관계형 데이터베이스에서는 이러한 속성의 통합 및 분할이 수행속도에 미치는 영향이 크므로, 기존 현상조사에 국한하지 않고 적극적이고 개선적인 사고를 가지고 사용자에게 많은 질문을 하고 확인하여 속성을 결정한다.

각 속성들은

• 과연 언제 사용되는가?
• 어떻게 사용되는가?
• 정말 필요한가?
• 추출항목이 아닌가? 등을 고려하여 결정되어야 할 것이다.

1.4 식별자(Unique Identifier)

식별자(UID:Unique IDentifier)는 하나, 혹은 하나이상의 ATTRIBUTE로 구성되며,모든 ENTITY는 반드시 UID를 가져야한다. 만약, UID를 가지지 못하면 ENTITY가 아니다.
UID를 구성하는 모든 ATTRIBUTE는 반드시 존재해야(mandatory) 하며, UID Attribute에는 #* 를 표시하고 대부분의 키 엔터티는 하나의 ATTRIBUTE로 구성된다.

상황에 따라서는 인위적으로 식별자를 생성해야 하는 경우도 발생을 하며, 인조키로 대체될 수 있다.

• 너무 긴 속성을 자주 사용하는 경우
• 사용자의 편의나 효율성을 위해 분류를 하고자 하는 경우
• 식별자 막애에 의해 너무 많은 속성으로 식별자가 구성되어 지는 경우
• 사용자의 데이터 처리에 관계없이 특정하게 부여된 식별자가 내부적으로만 많은 관계를 가지는 경우

식별자를 지정하는 절차

1. 엔터티를 식별할 필수 속성이 존재하는 가와 어떤 결합이 식별자가 될 수 있는가 확인
2. 만약 결합된 속성 중에도 식별자가 없다면 인공 속성을 검토
3. 누락된 관계가 있는지 확인
4. 엔터티를 식별할 관계가 있는지 고려
5. 사례표를 작성하여 혹시 잘못된 점이 없는지 검증하며, 식별자를 구성하는 속성과 관계가 필수인지 확인한다.

2. 상세 개념 데이터모델

기본 개념 데이터모델 단계에서는 현실상의 데이터를 옮겨오는 과정을 했다면, 상세 개념 데이터모델링에서는 정규화작업이나 M:N관계의 해소 등을 통해 더 세부적으로 분석하며, 엔터티의 재구성을 통해 구체화 한다.

2.1 정규화(Normalization) 작업

정규화란 다양한 유형의 검사를 통해 데이터 모델을 좀더 구조화 하고 개선시켜 나가는 절차에 관련된 이론이고, 정규화의 기본 원칙은 하나의 테이블에는 중복된 데이터가 없도록 하는 것이다.

가. 제 1 정규형

엔터티 내의 모든 ATTRIBUTE는 반드시 하나의 값을 가져야 한다
(반복형태가 있어서는 안됨)

나. 제 2 정규형

모든 ATTRIBUTE는 반드시 UID 전부에 종속되어야 한다 (UID 일부에만 종속되어서는 안됨)

다. 제 3 정규형

UID 가 아닌 모든 ATTRIBUTE 간에는 서로 종속될 수 없다 (ATTRIBUTE 간 종속성 배제)

2.2 M:N 관계의 해소

처리의 주체가 되는 엔터티간의 결합이 발생하여 업무가 복잡해지는 경우 엔터티 간에 M:N관계가 발생한다.
관계형 데이터베이스에서는 M:N의 관계를 지원하지 않으므로 M:N의 관계를 가지고 있는 두 엔터티 사이를 연결시켜 줄 수 있는 새로은 엔터티를 찾아 두개의 M:1관계로 바꾸어야 한다.
이렇게 생성된 엔터티를 교차(Intersection) 엔터티 라고 한다.

2.3 엔터티의 재구성

정규화 작업을 하고, M:N 관계를 해소 작업을 거치게 되면, 새로운 엔터티들이 추가된다. 이런 엔터티들은 사안에 따라 다양한 방법으로 재구성되어야 한다. 동일한 속성을 가진 엔터티들을 하나로 통합하거나, 계층형 관계를 가진 엔터티들은 순환관계 모델로 통합하거나, 얼마간의 공통 속성과 별도의 개별 속성을 가지고 있는 엔터티들은 서브타입(Sub-Type) 형태로 모으며, 전혀 통합할 수 없으나 그들의 합집합과 다른 엔터티가 관계를 가지는 경우를 위한 아크(Arc) 관계등을 검토하여 재구성 하야 한다.

가. 역활의 통합

처음에 엔터티를 분류할 때는 서로 다른 개념으로 간주하여 독립적으로 모델링을 하였으나, 관련된 모든 속성들을 서로 비교했을때, 동일한 속성을 가진다면, 하나의 엔터티로 통합할수 있다.

나. 계층형 데이터 모델

큰 단위 밑에 여러개의 작은 단위로 구성되는 계층형 구조를 가지게 된다.

다. 순환관계 데이터 모델

계층형 데이터 모델에서 엔터티의 속성들이 많은 부분 유사하다면, 각 엔터티의 모든 속성을 포함하는 하나의 엔터티로 통합할 수 있다. 즉, 연속적인 종속관계를 표현하는 방법이다.

라. BOM(Bill Of Material) 데이터 모델

BOM 데이터 모델링은 단계(Level)별로 어떤 제품 또는 어떤 부품이 얼마만큼 사용되었는가를 관리할수 있다.
실제적으로 제조업무에서는 이와같은 모델링 기법을 많이 필요로 하고 있다.
M:N 순환관계에 있는 데이터 모델을 해소할 수 있는 방법은 BOM 모델링 기법 뿐이다.

마. 서브타입 데이터 모델

모델링 작업을 진행하다 보면, 공통적으로 적용되는 속성들을 가지는 엔터티들이 있다.
이 속성들을 포함하는 상위개념의 엔터티를 생성하면 하나의 엔터티로 결합할 수 있다.
중복속성을 가진 여러개의 엔터티를 하나의 엔터티로 결합했을때, 그 구성 엔터티들을 서브타입(Sub-type)이라 한다.
수퍼타입(Super-type)이란 두개 이상의 서브타입을 가지는 엔터티를 말한다.

바. 아크관계 데이터 모델

업무 특성상 어떤 엔터티가 두개 이상의 다른 엔터티의 합집합 관계를 가지는 경우가 있는데, 이 관계를 맺는 순간에는 여러 엔터티들 중에서 하나를 반드시 선택해야 하는 관계(Exclusive OR관계)를 표현하고자 할때 아크(Arc)를 사용한다

사. 시계열 데이터 모델

데이터 이력을 관리하기 위해서 엔터티와 관계를 추가하는 경우가 있다. 이런 모델을 시계열 데이터 모델이라고 한다.

아. 복잡한 데이터 모델

3 데이터베이스 설계

3.1 엔터티를 테이블로

• 일반적으로 TABLE 명칭과 ENTITY 명칭은 같게 하는 것이 좋다
• 필요에 따라 ENTITY 명칭은 한글로하고 동의어를 영문으로 표시 (가능한 TABLE 명칭과 같게)
• SUPER-TYPE 이나 SUB-TYPE은 나중에 결정

3.2 속성을 컬럼으로

• 컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼동을 피하기 위해 가능한 표준화된 약어를 사용한다
• SQL의 예약어(reserved word)의 사용을 피한다
• 가능한 컬럼 명칭은 짧은 것이 좋으며 짧은 명칭은 SQL 해독시간을 감소시킨다
• 필수입력 속성은 Nulls/Unique 란에 NN을 표시한다
• 견본 데이터를 입력시킨다

3.3 식별자를 기본키로

• 1 단계
  • 키형태란에 ENTITY의 UID에 속하는 모든 속성들에 PK를 표시
  • PK로 표시된 모든 컬럼들은 Nulls/Unique 란에 반드시 NN,U 로 표시 되어야 함
  • 여러개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN,U1을 표시
  • 또 다른 Unique Key가 있다면 NN,U2로 표시

• 2 단계
  • 테이블에 외부키 컬럼을 포함시킨다
  • PK의 일부분으로 표시
  • Nulls/Unique 란에 각각 NN,U1을 표시
  • 키형태란에 PK,FK를 표시
  • 여러 컬럼으로 구성된 경우 PK,FK1을 각각에 표시
  • 추가된 FK 컬럼에 표본 데이터를 추가

3.4 관계를 외부키로

가. M:1 관계

• 반드시 1(one) 에 있는 PK를 M(many) 의 FK로 지정해야 한다
  • FK 의 명칭을 결정하고
  • 키형태란에 FK 표시한다.
  • Nulls/Unique 란에 NN 표시(must be 관계시) 한다
• 추가한 컬럼의 견본 데이터 작성한다.

나. 1:1 관계

어느 한쪽이 필수, 또는 모두가 선택으로 지정된 경우에 따라 참조하는 방법이 달라진다.

• Mandatoy
  • Mandatory 반대쪽에 있는 테이블의 PK를 Mandatory 쪽 테이블의 FK로 하며, NN 표시한다

• Optional
  • 어느 한쪽의 PK를 다른 쪽의 FK로
  • 보다 빈번하게 사용되는 테이블이 FK를 가지는 것이 유리하며, FK에 U 표시한다.

다. 순환관계

• M:1 순환관계
  • 해당 테이블 내에 FK 컬럼 추가
  • 이 FK 는 같은 테이블 내의 다른 로우의 PK 컬럼을 참조하게 됨
  • FK 컬럼명칭은 가능한 관계명칭을 반영
  • 이FK는 결코 NN 이 될 수 없음

• 1:1 순환관계
  • 해당 테이블 내에 UNIQUE 한 FK 컬럼 추가
  • 이 FK 는 같은 테이블 내의 다른 로우의 PK 컬럼을 참조하게 됨
  • FK 컬럼명칭은 가능한 관계명칭을 반영
  • 이 FK는 결코 NN 이 될 수 없음

3.5 아크처리 관계

아크 관계로 지정된 관계를 외부키로 전환하는 방법은 크게 두가지가 있다.

위의 은행계좌 테이블이 개인, 단체, 법인 에서 참조하는 외부키를 지정하는 방법은

(1) 외부키 분리

• 각각의 컬럼을 별도로 분리하는 방법으로, 각각의 외부키는 별도의 컬럼으로 지정되며,어느 한 컬럼에 값이 입력될 때,
  다른 외부키는 항상 NULL값을 가진다.

(2) 외부키 통합

• 외부키를 하나로 통합하는 것
• 외부키를 하나로 통합했을 때, 각 외부키를 구분하기 위해 별도의 구분컬럼을 같이 지정하게 된다.

(3) 아크관계로 참조되는 엔터티의 식별자는

• 가능한 인조키를 사용하여 하나의 컬럼으로 지정되도록 조치할 필요가 있다.
• 그렇게 할 수 없다면, 최소한 식별자 속성의 수를 통일 시키도록 하는 것이 좋다.
• 한번 결정된 식별자의 속성은 참조하는 모든 테이블에 동일한 형식으로 외부키를 지정해야 하며,
• 그렇지 못하면 '연결고리 이상' 상태가 발생하여 조인에 심각한 영향을 미칠수 있다.

3.6 서브타입의 처리

서브타입 데이터 모델은 그야말로 관련된 엔터티를 논리적인 잡합관계로 묶어놓은 것이다.
이러한 논리적 집합은 상황에 따라 여러 형태의 테이블로 전환하게 된다. 사용의 용이성뿐만 아니라 수행속도에 미치는 영향은 엄청난 차이를 가져오므로 신중하게 판단한다.

서브타입을 적절한 형태의 테이블로 전환하기 위한 서브타입 모델은 다음과 같다.

서브타입으로 지정된 모델을 테이블로 전환하는 방법에는 세가지가 있다.

가. 하나의 테이블로 통합

• SUB-TYPE을 SUPER-TYPE 에 통합하여 하나의 테이블로 만든다
• 이 통합된 테이블에는 모든 SUB-TYPE의 데이터를 포함해야 한다
• 주로 SUB-TYPE에 적은 량의 속성이나 관계를 가진 경우에 적용된다

전환절차

1. SUPER-TYPE으로 테이블 명칭 부여
2. SUB-TYPE을 구분할 수 있도록 컬럼 추가
3. SUPER-TYPE의 속성을 컬럼명으로
4. SUB-TYPE의 속성을 컬럼명으로
5. SUPER-TYPE의 관계를 FK로
6. SUB-TYPE의 관계를 FK로

나. 서브타입 별로 분리

• 각각의 SUB-TYPE 마다 하나의 테이블로 만든다
• 분할된 테이블에는 해당 SUB-TYPE의 데이터만 포함해야 한다
• 주로 SUB-TYPE에 많은 량의 속성이나 관계를 가진 경우에 적용된다

전환절차

1. SUB-TYPE마다 테이블 명칭 부여
2. SUB-TYPE의 속성을 컬럼명으로
3. 테이블마다 SUPER-TYPE의 속성을 컬럼으로
4. SUB-TYPE마다 해당되는 관계들을 FK로
5. 테이블마다 SUPER-TYPE의 관계를 FK로

다. 아크 관계로 분리

• SUPER-TYPE 과 SUB-TYPE 을 각각 테이블로 전환시키는 방법
• SUPER-TYPE 과 SUB-TYPE 테이블간에는 아크(ARC) 관계를 가지며,

• 다음의 여러 가지 경우를 만족할 때 사용
  • 전체 테이터 처리가 빈번하거나
  • SUB-TYPE의 처리는 주로 독립적으로 발생하고
  • 테이블을 통합했을 때 컬럼의 수가 너무 많아지는 경우
  • SUB-TYPE의 컬럼 수가 많은 경우
  • 트랜잭션이 주로 공통부분(super-type)에서 발생하며
  • SUPER-TYPE 의 처리범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때

전환절차

1. 각각의 엔터티 명칭을 기준으로 테이블 명칭 부여
2. 기본키 지정 (이러한 사항은 항상 수퍼 타입에 존재하고 있으며, 모든 테이블의 기본키는 동일하다.)
3. 각각의 엔터티 내에 있는 속성을 컬럼으로 지정
4. 수퍼타입에 연결된 관계를 각 테이블에 동일하게 외부키로 지정
5. 해당 서브타입에만 연결된 관계들에서 추가적인 외부키를 지정
6. 사례표에 견본 데이터를 작성

3.7 테이블 정규화 작업

• 제 1 정규화
  • 테이블은 반드시 무순서
  • 2차원 형식의 집합
  • 반복되는 그룹을 가질 수 없다

• 제 2 정규화
  • 반드시 제1정규형을 만족할 것
  • 키가 아닌 모든 컬럼은 PK에 종속적이어야 한다

• 제 3 정규화
  • 반드시 제2정규형을 만족할 것
  • 키가아닌 모든 컬럼은 다른 키가아닌 컬럼에 독립적이어야 한다

• 정규화 이유?
  • 정규화는 데이터의 중복을 최소화
  • 데이터의 중복은 데이터의 일관성을 해친다
  • 트랜젝션이 여러 테이블을 불필요하게 처리한다
  • 정규화 작업은 ENTITY 나 RELATIONSHIP, 테이블의 누락을 방지하는데 도움을 준다

3.8 추가적인 작업

• 참조 무결성의 CONSTRAINT 정의
• 인덱스(INDEX) 설계
• 클러스터링(CLUSTERING) 설계
• 해쉬 클러스터(HASH CLUSTER) 설계
• 뷰(VIEW) 설계
• 데이터베이스 설계의 반 정규화(denormalize)
• 저장공간 사용량 계획

문서에 대하여

• 최초작성일 : 2007년 11월 2일
• 이 문서는 오라클클럽 대용량 데이터베이스 스터디 모임에서 작성하였습니다.
• 이 문서의 내용은 이화식님의 대용량 데이터베이스 솔루션1 을 참고했습니다.