[굿모닝팝스] 2014년 2월 26일 GMP

[굿모닝팝스]  2014년 2월 26일 GMP

① Screen English

I was for worthy cause.
= There was good reason for it.
= It was all for the better.

=가치 있는 일을 위해 그런거야.

② Pops English

I'll meet you up there.

=거기서 당신을 만날께요.

③ KISS English

Don't for get attend orientation.

=오리엔테이션에 참석하는거 잊지 말고.

[DAP, DAsP] 물리 데이터 모델링 - 논리 물리 모델 변환

[DAP, DAsP] 물리 데이터 모델링 - 논리 물리 모델 변환
논리 데이터 모델-물리 데이터 모델 변환(Transformation) 용어



엔터티-테이블 변환

테이블 설명

테이블은 데이터를 저장하기 위해서 생성된 데이터베이스에서의 가장 기본적인 오브젝트

1)테이블(Table)

테이블은 기본적으로 칼럼(Column)과 로우(Row)를 가진다. 각각의 칼럼은 지정된 유형의 데이터 값을 저장

2)로우(Rows)

테이블의 한 로우에 대응. 튜플 , 인스턴스, 어커런스라고도 한다.

3)칼럼(Columns)

각 사원 개개인의 관리 항목에 대한 Value를 저장

4)기본키(Primary keys)

하나의 칼럼 혹은 몇 개의 칼럼 조합으로 어떤 경우라도 테이블 내에 동일한 값을 갖는 튜플이 존재하지 않도록 한다.

5)외래키(Foreign keys)

외부 데이터 집합과의 관계를 구현한 구조이다.

서브타입 변환(Transformation)

논리 데이터 모델에서는 비즈니스 또는 업무를 데이터 모델로 표현하기 위해서는 최대한 상세한 표현이 필수적
목적을 달성하기 위해서 가능하면 집합(엔터티)의 구성을 서브타입을 사용하여 구체적으로 표현하는 것이 통상적
각각의 서브타입들이 독립적인 속성(Attribute), 관계(Relationship)를 가지고 있는 경우에는 이러한 서브타입(Sub Type)을 사용한 집합의 표현은 필수적
논리 모델링에서 표현된 서브타입은 물리 데이터 모델에서는 테이블의 형태로 설계
서브타입 모델은 단순 엔터티-테이블 변환과는 다른 몇 가지 방법을 통해서 테이블로 변환

- 슈퍼타입 기준 테이블 변환
- 서브타입 기준 테이블 변환
- 개별타입 기준 테이블 변환

①슈퍼타입 기준 테이블 변환

서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만든다
이 통합된 테이블에는 모든 서브타입의 데이터를 포함해야 한다
주로 서브타입에 적은 양의 속성이나 관계를 가진 경우에 적용된다
    
    가) 절차

- 슈퍼타입으로 테이블 명칭 부여
- 서브타입을 구분할 수 있도록 칼럼 추가
- 슈퍼타입의 속성을 칼럼명으로
- 서브타입의 속성을 칼럼명으로
- 슈퍼타입의 관계를 FK로
- 서브타입의 관계를 FK로

    나) 테이블 사례

[그림 4-4-3]의 논리 모델에서의 서브타입을 하나의 테이블로 통합하는 경우 테이블의 모습은 [그림 4-4-5]의 사례 데이터 표와 같다.


- TYPE : 서브타입을 구분할 수 있는 칼럼이다. 즉 사원 구분에 해당하는 칼럼이다.
- DEPT : 구분이 정규직일 경우에 부서로부터의 관계로 인해서 생성된 칼럼이다.
- UNION : 구분이 임시직일 경우에 협력 업체로부터의 관계로 인해서 생성된 칼럼이다.

    다) 하나의 테이블로의 통합이 유리한 경우

- 데이터 액세스가 좀더 간편
- 뷰를 활용하여 각 서브타입만을 액세스하거나 수정 가능
- 수행 속도가 좋아지는 경우가 많다
- 서브타입 구분없는 임의 집합의 가공 용이
- 다수의 서브타입을 통합한 경우 조인(JOIN) 감소 효과가 크다
- 복잡한 처리를 하나의 SQL로 통합하기가 용이

    라) 하나의 테이블로의 통합이 불리한 경우

-특정 서브타입의 NOT NULL 제한 불가
-테이블의 칼럼 수가 증가
-테이블의 블럭 수가 증가
-처리시마다 서브타입의 구분(TYPE)이 필요해지는 경우가 많다
-인덱스(INDEX) 크기가 증가

②서브타입 기준 테이블 변환

- 슈퍼 타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로 만든다
- 분할된 테이블에는 해당 서브타입의 데이터만 포함돼야 한다
- 주로 서브타입에 많은 양의 속성이나 관계를 가진 경우에 적용된다


    가) 절차

- 서브타입마다 테이블 명칭 부여
- 서브타입의 속성을 칼럼명으로
- 테이블마다 슈퍼타입의 속성을 칼럼으로
- 서브타입마다 해당되는 관계들을 FK로
- 테이블마다 슈퍼타입의 관계를 FK로

    나) 테이블 사례

위의 [그림 4-4-3] 논리 모델에서의 서브타입을 여러 개의 테이블로 분할하는 경우 테이블의 모습은 [그림 4-4-7]과 [그림 4-4-8]의 데이터 사례 표와 같다. [그림 4-4-7]은 정규직 사원에 대한 표본 테이블의 모습과 인스턴스를 나타낸다. [그림 4-4-8]은 임시직 사원에 대한 표본 테이블의 모습과 인스턴스를 나타낸다.

    다) 여러 개의 테이블로 분할한 경우가 유리한 경우

- 각 서브타입 속성들의 선택 사양 명확한 경우에 유리
- 처리시마다 서브타입 유형 구분이 불필요
- 전체 테이블 스캔시 유리
- 단위 테이블의 크기가 감소

    라) 여러 개의 테이블로 분할한 경우가 불리한 경우

- 서브타입 구분 없이 데이터 처리하는 경우 UNION이 발생
- 처리 속도가 감소하는 경우가 많다
- 트랜젝션 처리시 여러 테이블을 처리하는 경우가 증가한다.
- 복잡한 처리의 SQL 통합이 어려워진다.
- 부분 범위 처리가 불가능해 질 수 있다.
- 여러 테이블을 합친 뷰는 조회만 가능
- UID 유지관리가 어렵다.

③개별타입 기준 테이블 변환

- 슈퍼타입과 서브타입을 각각 테이블로 변환한 경우이다.
- 슈퍼타입과 서브타입 테이블 간에는 1:1 관계가 생성된다.
  (한 쪽을 모두 합치면 전체와 같게 된다는 면에서 개념적으로 아크 관계와 유사)
    
    다음의 여러 가지 경우를 만족할 때 사용

- 전체 데이터 처리가 빈번하게 발생할 경우에 적용
- 서브타입의 처리는 주로 독립적으로 발생할 경우에 적용
- 테이블을 통합했을 때 칼럼의 수가 너무 많아지는 경우에 적용
- 서브타입의 칼럼 수가 많은 경우에 적용
- 트랜잭션이 주로 공통 부분(슈퍼타입)에서 발생
- 슈퍼타입의 처리 범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때 적용



서브타입 변환 예



[그림 4-4-10]의 데이터 모델을 물리적 모델로 전환하는 방법은 다양하다. 하나의 데이터 모델을 이용하여 하나 이상의 노드(분산 데이터베이스를 구현하였을 때의 각각의 단위 데이터베이스)에 자 신만의 데이터베이스를 설계할 수 있을 것이다. 데이터 모델의 전부를 물리적 모델로 전환할 수도 있 지만 필요에 따라 원하는 것만 전환하고자 할 수도 있을 것이다.

뿐만 아니라 엔터티를 하나의 테이블로 할 수도 있겠지만 각각의 서브타입 혹은 몇 개를 묶어서 하 나의 테이블로 결정하는 경우도 있을 수 있다. 만약 [그림 4-4-10]의‘엔터티3’처럼 서브타입 세트 를 이용하여 여러 차원에서 분류한 서브타입을 가지고 있다면 자신이 원하는 서브타입 세트의 일부서브타입만 테이블로 전환하는 것도 가능하다. 하나의 엔터티를 여러 개의 테이블로 설계하고 싶다 면 최소한 논리적 데이터 모델에는 서브타입으로 반드시 정의되어 있어야 가능하다. 즉, 물리적 모델 을 결정하는 단계에서 기존에 정의해 둔 서브타입이 아닌 다른 방법으로 테이블을 분할하고 싶다면 논리적 데이터 모델에 새로운 서브타입 세트를 추가로 정의해야 한다는 것을 의미한다.

속성을 물리적 모델로 전환하는 경우에도 전부나 일부만 선택하는 것은 얼마든지 가능하다. 이러 한 개념을 활용하면 하나의 논리적 데이터 모델을 이용하여 여러 개로 수직 분할된 물리 모델을 생성 할 수 있다.

    1) Case 1 : 서브타입을 테이블로 분리

속성에 붙어 있는 숫자가 같은 칼럼이 서로 변환된 것으로 간주한다.(예: 속성31 --> COL31)



엔터티1은 그대로 TABLE10으로 전환
서브타입 세트란 일종의 구분코드라는 속성
서브타입세트1은 칼럼(SUBTYSET1)으로 전환
엔터티1에 있던 서브타입1,2는 서브타입세트1의 속성에 들어가는 값의 내용이므로 칼럼으로 전환할 필요가 없다.

엔터티2는 서브타입별로 테이블을 분리한 모습
서브타입21은 TABLE21
서브타입22는 TABLE22로 
공통 속성인 키2, 속성21은 양쪽 모두에 전환

엔터티3은 두 종류의 서브타입 세트를 가지고 있다. 
물리 모델은 이 중에서 서브타입세트32에 있는 서브타입별로 분리
자세히 살펴보면 슈퍼타입에 있던 공통 속성 중에서 자신이 필요로 하는 일부분만 전환되었음을 발견
바커표기법으로 표현할 모델에서 관계선에 세로선
(UID BAR)이 붙어 있다면 식별자의 일부가 되겠다는 뜻이므로 물리적 모델이 될 때는 당연히 기본키(PK, Primary Key)이면서 외래키(FK, Foreign Key)가 되어야 한다.
    
    2) Case 2 : 서브타입을 통합 테이블로 생성

물리적 모델에서는 [그림 4-4-12] 같이 동일한 논리적 모델을 기반으로 했지만 앞서 예제와는 다른 모습의 모델을 만들 수도 있다.

[그림 4-4-12]의 물리 모델은 앞서 소개한 물리적 모델과는 테이블의 개수도 다르며, 경우에 따라 테이블 명칭은 동일하지만 내용은 다르게 정의할 수도 있다.

테이블 목록 정의서



엔터티를 테이블로 변환하는 과정이 완료되면 [그림 4-4-13]과 같은 테이블 목록 정의서를 작성한다. 테이블 목록 정의서는 줄여서 테이블 목록이라 부르기도 하며, 전체 테이블이 목록으로 요약 관리되어야 한다.

속성-칼럼 변환

속성이나 관계를 물리 데이터 모델 객체로 변환하는데 있어서 사례 데이터 표를 작성해 보는 것은 실제 데이터가 어떤 형태로 저장되는지, 어떠한 예외사항이 존재할 수 있는지 등을 용이하게 파악할 수 있도록 도움을 주기 때문에 여기서는 사례 데이터 표를 활용하여 변환 과정을 설명한다.

일반 속성 변환

-엔터티에 있는 각 속성들에 대한 칼럼명을 사례 데이터 표의 칼럼명 란에 기록
-칼럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼동을 피하기위해 가능한 표준화된 약어를 사용
-표준화된 약어의 사용은 SQL 해독 시간을 감소
-SQL의 예약어(reserved word)의 사용을 피한다.
-가급적 칼럼 명칭은 짧은 것이 좋으며, 짧은 명칭은 개발자의 생산성에 긍정적인 영향을 준다.
-필수 입력 속성은 Nulls/Unique 란에 NN을 표시한다.
-실제 테이블에 대한 설계를 검증하기 위한 목적으로 가능하다면 표본 데이터를 입력시킨다.

Primary UID 기본키(Primary Key) 변환

논리 데이터 모델에서의 Primary UID는 물리 데이터 모델에서는 기본키로 생성된다. 실제 DDL 에서는 기본키 제약 조건의 형태로 오브젝트가 생성된다.

1) 변환 절차

- 사례 데이터 표의 키 형태 란에 엔터티의 Primary UID에 속하는 모든 속성에 PK를 표시
- PK로 표시된 모든 칼럼은 Nulls/Unique 란에 반드시 NN,U로 표시되어야 함
- 여러 개의 칼럼으로 UID가 구성되어 있는 경우는 각각의 칼럼에 NN,U1을 표시
- 또 다른 Unique Key(Secondary UID)가 있다면 U2로 표시

2) 변환 예



Primary UID(관계의 UID Bar) 기본키(Primary Key) 변환

논리 데이터 모델에서 Primary UID에 속하는 속성 중에는 해당 엔터티 자체에서 생성된 것도 존 재하지만 다른 집합(엔터티)으로부터의 관계에 의해서 생성되는 UID 속성(관계 속성)도 존재 한다. 이러한 관계 속성 UID의 변환은 기본적인 속성 UID 변환과는 약간 다르다.

1) 변환 절차

○ 테이블에 외래키 칼럼을 포함시킨다
○ PK의 일부분으로 표시

-Nulls/Unique 란에 각각 NN,U1을 표시

-키 형태란에 PK, FK를 표시

-여러 UID BAR가 있는 경우는 (PK, FK1), (PK, FK2), …

-여러 칼럼으로 구성된 경우 PK,FK1을 각각 표시

추가된 FK 칼럼에 표본 데이터를 추가

2) 변환 예



Secondary (Alternate) UID Unique Key 변환

논리 데이터 모델에서 정의한 Secondary UID 또는 Alternate Key 들은 해당 집합과 상태 집합과의 선택적인 관계를 가질 수 있도록 하는 데 중요한 역할을 수행한다. 이러한 Secondary UID들은 물리 데이터 모델에서는 Unique Key로 생성된다. 변환 절차는 기본적으로 Primary UID 변환 절차와 동일하다.

테이블 정의서



기본적인 테이블 변환, 칼럼 변환 작업이 완성되면 [그림 4-4-16]과 같은 테이블 정의서를 생성할 수 있다. 대부분의 시스템 구축 프로세스상에서 개발자들이 프로그램 개발을 수행하는 단계에서 가장 많이 참조하는 산출물 중 하나이다 .

관계 변환

1:M 관계 변환

논리 데이터 모델에서 존재하는 관계 중에?? 따라 서 관계 칼럼의 선택사양이 결정되게 된다.

1) 변환 절차
○ 1(One) 에 있는 PK를 M(Many)의 FK로 변환
 - FK의 명칭 결정
 - 키 형태 란에 FK 표시
 - Nulls/Unique 란에 NN 표시(Must Be 관계시)
 - 필수 관계가 아닌 경우에는 NN를 체크하지 않는다.
○ 표본 데이터 추가
○ UID BAR 가 있는 경우는 전단계에서 실시

2) 변환 예


3) 1:M 관계에서 1 쪽이 Mandatory 관계일 때의 변환시 주의사항
자식 쪽의 레코드(Row)가 반드시 하나 이상은 되어야만 부모 쪽의 레코드(Row)를 생성할 수 있다.
자식 쪽의 레코드(Row)를 삭제할 경우에는 전체를 다 삭제할 수는 없고 반드시 하나 이상의 자식 레코드(Row)를 남겨두어야 한다. 또는 자식, 부모 레코드(Row)를 동시에 삭제해야 한다.


1:1 관계 변환

1:1 관계는 논리 모델에서는 자주 발생하지는 않는 관계이다. 이러한 1:1 관계를 물리 모델로 변환하는 과정은 관계의 Optionality(기수성)에 따라서 다른 방법으로 적용된다. 양쪽 다 Optional인 경우에는 보다 빈번하게 사용되는 테이블이 외래키를 가지는 것이 유리하다.

1) 변환절차

- Mandatory 반대쪽에 있는 테이블의 기본키를 Mandatory 쪽 테이블의 외래키로 변환한다.
- NN 표시를 한다..

2) 변환 예


3) 변환시 주의사항
1:1 관계에 의해서 생긴 모든 외래키 부분은 Unique Key가 필수적이다.
한쪽이 Optional이고 다른 한쪽이 Mandatory라면 Mandatory쪽의 테이블에 외래키가 생성 된다.
양쪽다 Mandatory라면 변환시에 어떤 테이블에 외래키를 생성할 것인지를 선택해야 한다.


1:M 순환 관계 변환

대부분의 경우는 데이터의 계층 구조를 표현하기 위해서 이러한 관계를 사용한다. 특성상 최상위 관계 속성은 항상 Optional인 형태의 관계이어야 한다. 하지만 경우에 따라서는 최상위의 관계 속성에 특정 값을 지정하는 경우도 존재한다.

1) 변환 절차

해당 테이블 내에 외래키 칼럼을 추가한다. 외래키는 같은 테이블 내의 다른 로우의 기본키 칼럼을 참조하게 된다.
외래키 칼럼 명칭은 가능한 한 관계 명칭을 반영한다. 외래키는 결코 NN(Not Null) 이 될 수 없다.

2) 변환 예


배타적 관계 변환

[그림 4-4-22]와 같은 논리 모델에서의 배타적 관계의 모델은 실제 데이터 환경에서는 자주 등장하게 된다. 하지만 이러한 관계를 물리 데이터 모델로 생성하는 방법은 일반적인 관계를 물리 데이터 모델로 변환하는 것과는 다르다. 여기에는 두 가지 정도의 대표적인 방법을 가지고 설명한다.

1) 외래키 (Foreign Key) 분리 방법
각각의 관계를 관계 칼럼으로 생성하는 방법이다. 
실제 외래키 제약조건 (Foreign Key Constraints)을 생성할 수 있다는 장점
하지만 각각의 키 칼럼들이 Optional이어야 한다. 
또한 다음과 같은 체크 제약조건(Check Constraints)을 추가적으로 생성하 여야 한다.

- 추가적인 체크 제약조건
CHECK ( JUMIN_NO IS NOT NULL AND PART_NO IS NULL AND BUSINESS_ID IS NULL )
      OR ( JUMIN_NO IS NULL AND PART_NO IS NOT NULL AND BUSINESS_ID IS NULL )
      OR ( JUMIN_NO IS NULL AND PART_NO IS NULL AND BUSINESS_ID IS NOT NULL )

2) 외래키 결합 방법
각각의 관계를 하나의 관계 칼럼으로 생성하는 방법이다. 
실제 외래키 제약조 건을 생성할 수 없다는 단점
또한 각각의 관계를 선택적으로 구분할 수 있는 추가적인 칼럼이 필요



구분 칼럼 추가
[그림 4-4-24]에서와 같이 구분 칼럼 TYPE이 추가되어 배타적 관계의 각 테이블들이 구분된다.

-J : 개인
-P : 단체
-B : 법인

관리상 필요한 칼럼 추가

개념

논리 데이터 모델에는 존재하지 않지만 관리상의 이유로 혹은 데이터베이스를 이용하는 프로그래 밍이 좀더 빠르게 수행되도록 하기 위해서 테이블이나 칼럼을 추가할 수 있다. 예를 들면 해당 데이터를 등록한 일자나 시스템 번호 등과 같은 관리상의 이유로 필요한 것

시스템 칼럼 추가 예

[그림 4-4-25]는 생성일시, 생성 프로세스 ID라는 논리 데이터 모델에서는 존재하지 않는 속성인 데도 불구하고 물리 데이터 모델에서 추가하여 생성하고 있는 예를 보여주고 있다.

데이터 타입 선택

개념

물리 데이터 모델링 단계에서 일어나는 많은 문제 중의 하나
: 칼럼의 데이터 형식을 잘못 설정하 는 데에서 발생
특정 칼럼의 데이터 형식을 선택하는 것은 논리 데이터 모델에서 정의된 논리적인 데이터 타입(정보 타입 : Information Type)을 물리적인 DBMS의 특성과 성능 등을 고려하여 최적의 데이터 타입을 선택하는 작업
여기에서의 DBMS별 특성은 이 책을 통해 설명하는 것은 불가능하다. 따라서 여기에서는 대표적인 데이터 타입의 선택 기준에 대해서만 언급한다. 여기에서 는 데이터 타입의 선택에 대한 예제를 들어 설명한다. 단, 모든 DBMS를 예로 들 수는 없기 때문에 MS SQL Server를 예를 들어 설명한다.



문자 타입 (Character Data Types)

논리 데이터 모델에서의 형식이 문자였다면 세부적으로 많은 문자 형식들 중에서 칼럼의 값이 어 떤 범주를 만족하는지를 판단해야 한다. 여기에는 현재 칼럼이 가지는 값의 특성도 고려되어야 하고, 미래에 가질 값의 특성들도 고려되어야만 한다.

1) 세부 문자 타입 선택을 위한 기준

    가) 영문만 사용되는가?

유니코드 형식은 모든 문자를 2바이트(Byte) 체계로 설계한 국제 표준 문자 형식이다. 한글을 저장하기 위해서 반드시 유니코드 형식을 사용해야 하는 것은 아니다. 하지만 일반 문자 형식들에 값을 지정한다면 영문은 1바이트, 한글은 2바이트라는 부조화를 일으키게 된다. 이러한 이유로 유니코드를 저장하는 데이터 타입에는 일반적으로 NCHAR, NVARCHAR등과 같이 앞에 N이 들어 가는 데이터 타입을 사용한다.

    나) 4000자 혹은 8000자 이상의 문자열이 포함되는가?

일반적인 문자들을 저장하는 데이터 타입은 4K 혹은 8K를 상한선으로 하고 있다. 물론 이 기준은 DBMS마다 조금씩 다르다. 이렇게 큰 데이터를 저장하기 위해서는 일반적인 문자열을 저장하 는 데이터 타입이 아닌 다른 데이터 타입을 사용해야 한다. 예를 들면 , LONG, TEXT 등과 같은 데이터 타입을 사용할 수 있다.

    다) 입력되는 값의 길이가 일정한가?

값의 길이가 일정하다는 것은 입력되는 칼럼 값의 길이가 일정하다는 것을 의미한다. 반대로 가 변적이라는 것은 입력되는 값의 길이가 일정하지 않다는 것을 의미한다.

2) 문자 형식 데이터 타입 설정 예

[[그림 4-4-26]은 MS SQL Server에서의 데이터 타입을 기준으로 예를 든 것이다.



숫자 타입 (Numeric Types)

숫자 타입의 데이터 타입도 DBMS마다 많은 형식이 존재한다. 많은 숫자 타입들 중에서 주어진 상황에 맞는 가장 적절한 데이터 타입을 설정해야 한다.

1) 세부 숫자 타입 선택을 위한 기준

    가) 정말 숫자 데이터인지 판단한다.

많은 경우 숫자처럼 보이는 숫자가 아닌 값들을 관리하는 경우가 존재한다. 예를 들면 6810301633318 과 같은 주민등록번호는 숫자처럼 보이지만 숫자가 아니다. 즉, 우리가 이 주민 번호를 가지고 연산을 하거나 할 가능성이 있는지를 보면 이것은 숫자 타입이 아닌 문자 타입의 데 이터라는 것을 알 수 있다.

    나) 세부 숫자 타입 결정

■ 불린(Boolean)
참(TRUE) 혹은 거짓(False)을 저장하는 경우에 선택한다.

■ 정수(Integer)
소수점 이하를 처리하지 않는 경우에 선택한다.

■ 소수(Decimal)
소수점 이하를 처리하는 경우에 선택한다.

■ 화폐(Money)
금액을 저장하기 위한 경우에 선택한다.

2) 숫자 형식 데이터 타입 지정 예



날짜 타입 (Datetime Types)

특정 데이터 항목에 대해서 날짜 타입으로 할 것인지 아니면 문자 타입으로 할 것인지는 이미 논리 데이터 모델에서 결정된다. 그렇기 때문에 물리 데이터 모델링에서는 논리 데이터 모델링에서 날짜 타입으로 결정된 부분을 DBMS 특성에 맞게 여러 개의 날짜 타입들 중에서 어떤 날짜 타입을 선택 할 것인지를 결정하는 것이다.

1) 세부 날짜 타입 선택을 위한 기준

대부분의 DBMS에서는 날짜 타입에 일자뿐만 아니라 시분초의 정보도 같이 저장한다. 심지어는 0.001초 차이까지도 저장하기도 한다. 그래서 그냥 일반적인 시간까지를 저장할 것이냐 아니면 이러 한 정밀한 시간을 저장할 것이냐에 따라 날짜 타입을 결정한다.

2) 세부 날짜 타입 지정 예



데이터 표준 적용

개념

논리 데이터 모델링 과정에서 정의된 엔터티, 속성, 관계들을 여러가지 기준으로 물리 데이터 모델 로 변환한다. 이 과정에서 필수적으로 엔터티명에 해당하는 테이블명을 생성하고, 속성 또는 관계에 해당하는 칼럼명을 생성하게 된다. 이러한 이름을 변환하는 과정에서 전사적으로 미리 생성된 데이 터 표준을 따르게 된다. 이러한 데이터 표준에는 대표적으로 표준 용어, 표준 도메인, 표준 명명 규 칙 등이 존재한다.

데이터 표준 적용 대상

물리 데이터 모델에서의 데이터 표준화는 다음과 같은 객체를 대상으로 수행하게 된다.

1) 데이터베이스(Database)

테이블의 집합으로 통합 모델링 단계의 주제 영역이나 애플리케이션 모델링 단계의 업무 영역에 대응되는 오브젝트이다.

2) 스토리지 그룹(Storage Group)

DASD(Direct Access Storage Device) 즉, 물리적인 디스크(Disk)를 묶어서 하나의 그룹으로 정의해 놓은 것이며 테이블스페이스, 인덱스 스페이스 생성시 스토리지 그룹명을 지정하여 물리적인 영역을 할당하도록 한다.

3) 테이블스페이스(Tablespace)

테이블이 생성되는 물리적인 영역이며, 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블을 저장할 수 있다.

4) 테이블(Table)

논리 설계 단계의 엔터티에 대응하는 객체이다.

5)칼럼(Column)

논리 설계 단계의 속성에 대응하는 객체이다.

6) 인덱스(Index)

테이블에서 특정 조건의 데이터를 효율적으로 검색하기 위한 색인 데이터로 대표적인 인덱스 대상 으로는 기본키(Primary Key), 외래키(Foreign Key)등이 있다.

7) 뷰(View )

테이블에 대한 재정의로서 물리적으로 테이블의 특정 칼럼, 특정 로우를 뷰로 정의하여 특정 사용 자만 접근이 가능하도록 할 수 있다.

데이터 표준 적용 방법

1) 명명 규칙에 의한 표준화 적용
테이블에 대한 명명 규칙과 적용 기준들의 예를 들면 다음과 같다.

논리 데이터 모델을 물리 데이터 모델로 전환시 테이블명은 엔터티 한글명과 동일하게 용어를 사 용하면서 해당 용어를 영문명으로 전환한다.
영문명은 영문 약어를 사용하며, 표준 용어 사전에 등록된 표준 영문 약어를 참조한다.
테이블의 명명 순서는 업무 영역 + 주제어 수식어 + 주제어 + 분류어 수식어 + 분류어 + 접미사 순



테이블 영문명에서는 각 어소별 구분자로 Under Bar(_)를 사용한다.
 예) 업무관계자_사원_정보 IVPT_EMP_INFO

2) 표준 용어집에 의한 표준화 적용
사전에 사용될 모든 객체명과 해당 객체에 대한 데이터 타입, 길이 등의 표준을 정의해 놓고 이 표준 들을 적용하는 방식이다. 현재 대부분의 회사들은 위 두 가지의 방법을 병행하여 사용하고 있다고 볼 수 있다.

발췌 - DBGUIDE.NET

[DAP, DAsP] 물리 데이터 모델링 - 반정규화

[DAP, DAsP] 물리 데이터 모델링 - 반정규화

논리 데이터 모델링의 마지막에 진행되었던 정규화 작업이 완료
데이터 모델은 데이터의 중복 을 최소화
데이터의 일관성 & 정확성 & 안정성을 보장

반정규화 과정 :
정규화된 데이터 모델은 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화
정규화의 원칙 들에 위배되는 행위를 의도적으로 수행
이러한 과정에는 크게 테이블 관점, 칼럼 관점에서의 반정규화 과정이 존재

장점 : 반정규화된 데이터 구조는 성능과 관리효율을 증대

단점 :
- 데이터의 일관성 및 정합성을 해칠 위험을 내포
- 유지하는데도 그만큼 비용이 발생
- 지나치면 오히려 성능에도 악영향

선택(경험에 의한 모델러의 선택)
-데이터 모델의 각 구성 요소인 엔터티, 속성, 관계에 대해 데이터의 일관성과 무결성을 우선으로 할지 ?
-데이터베이스의 성능과 단순화에 우선순위를 둘 것인지 ?
---------------------------------------------------------------------------------
테이블 분할

개념

하나의 테이블을 수직 혹은 수평 분할하는 것을 테이블 분할 또는 파티셔닝이라고 한다. 여기에서의 파티셔닝이라는 용어는 데이터베이스 디자인 단계에서의 데이터를 저장하는 방식의 파티셔닝과 는 구분되는 개념이다.

수평 분할(Horizontal Partitioning)

1) 개념

레코드(Record)를 기준으로 테이블을 분할하는 것을 말한다. [그림 4-4-30]의 사례는 EMP 테이 블에 대해 기본키인 ID 칼럼의 값이 10에서 30까지를 EMP 10-30이라는 테이블로 분할하고, 나머 지 40에서 60까지를 EMP 40-60이라는 테이블로 분리했다.



2) 사용 의의

하나의 테이블에 데이터가 너무 많이 있고, 레코드 중에서 특정한 덩어리의 범위만을 주로 액세스 하는 경우
분할된 각 테이블은 서로 다른 디스크에 위치시켜 물리적인 디스크의 효용성을 극대화할 수 있다.
현재는 이러한 수평 테이블의 분할은 DBMS 차원에서 제공하고 있다. 특히 분할의 방법 다양하게 제공하고 있는 추세이다. 분할의 대표적인 방법으로는 범위 분할, 해쉬 분할, 복합 분할 등의 기법이 사용된다. 이러한 DBMS 차원의 분할은 데이터베이스 디자인에서 자세하게 다루어질 것이다.

수직 분할 (Vertical Partitioning)

1) 개념

하나의 테이블이 가지는 레코드의 개수가 많아서 수평 분할을 한다면 수직 분할은 하나의 테이블이 가지는 칼럼의 개수가 많아지기 때문에 일어난다. 이러한 수직 분할이 일어나는 이유는 다양하다.

-조회 위주의 칼럼과 갱신 위주의 칼럼으로 나뉘는 경우
-특별히 자주 조회되는 칼럼이 있는 경우
-특정 칼럼 크기가 아주 큰 경우
-특정 칼럼에 보안을 적용해야 하는 경우




2) 갱신 위주의 칼럼 수직 분할

    가) 개념

갱신 위주의 칼럼들을 분할하는 이유는 데이터를 갱신하는 작업이 일어날 때 업데이트하려는 레코드(Record), 즉 레코드에 잠금(Locking)을 수행하기 때문이다. 잠금은 데이터의 무결성을 지키기 위한 수단으로 하나의 프로세스가 특정 데이터 값을 변경하려고 할 때 변경 작업이 끝날 때까지 다른 프로세스가 이 데이터의 값을 변경하지 못하도록 금지하는 것이다.

    나) DBMS 버전별 적용 검토

특정 DBMS의 경우에는 이러한 잠금이 레코드 전체에 걸리기 때문에 업데이트가 완료될 때까지 해당 레코드를 사용할 수 없게 하는 요인이 된다. 즉, 몇 개의 갱신 위주의 칼럼에 대한 작업이 나 머지 조회 위주의 칼럼 이용을 방해한다. 이러한 DBMS의 경우에는 이러한 갱신 위주의 칼럼들을 수직 분할하여 사용하는 것이 데이터 사용의 효율성을 증가시킨다.



3) 자주 조회되는 칼럼 분할

    가) 개념

테이블의 특정한 칼럼들이 자주 조회된다면 이러한 칼럼들을 분리해서 별도의 테이블로 관리하면 조회되는 쿼리의 작업 성능을 향상시킬 수 있다. 즉 칼럼 수가 아주 많은 테이블에서 주로 사용 되어지는 칼럼들이 극히 일부라고 가정한다면 이러한 일부 칼럼들로 이루어진 테이블을 생성하여 실제 물리적인 I/O의 양을 줄여서 데이터 액세스 성능을 향상시킬 수 있다.

    나) 물리적인 DBMS 메커니즘 고려

DBMS는 액세스하고자 하는 모든 데이터를 초기에 물리적인 데이터 파일에서 메모리로 읽어들이게 된다. 또한 한번 읽어들인 데이터는 읽고 나서 바로 지워지는 것이 아니라 일정기간 메모리에 저장되게 된다. 이러한 DBMS의 메커니즘상에서도 보듯이 읽어들이는 데이터의 양이 적다면 즉, 칼럼 수가 적은 테이블을 자주 읽는 작업을 많이 한다면 초기 데이터를 메모리로 적재하는 비용이 절약되고 또한 메모리상에 상대적으로 오래 머무를수 있기 때문에 데이터의 재사용성을 높여주는 효과를 가져올 수 있다.

    다) 회원 인증 테이블 사례



[그림 4-4-33]에서와 같이 회원 테이블에서 성명, 암호 칼럼을 분할하여 회원인증이라는 테이 블로 만들었다. 애플리케이션마다 다르기는 하지만 이러한 두 가지 정보들은 회원 인증을 위해서 사이트에 접속할 때마다 반복해서 액세스되는 데이터이다.

4) 특정 칼럼의 크기가 아주 큰 경우 분할

    가) 개념

특정 칼럼의 크기가 아주 큰 경우 분할이 일어나는 대개의 경우는 특정 칼럼의 크기가 크다는 것 보다는 특정한 데이터 형식에 기인하는 문형 문자열을 저장하기 위해 지원하는 데이터 타입은 크게는 2GB까지 저장할 수도 있다. 또는 이미지 데이터를 저장할 수도 있다. 이러한 텍스트 및 이미지와 같은 LOB(Large Objects) 데이터 형식을 지원하는 방법은 데이터베이스 시스템마다 약간의 차이는 있다. 하지만, 테이블의 칼럼에 이러한 텍스트 및 이미지 데이터가 포함될 때 성능이 저하될 가능성이 있다. 이것은 백업, 복원과 같은 관리나 프로그래밍과 같은 개발 부분에서 여러 가지 성능 저하 요인으로 작용할 수 있다는 것이다. 그래서 이러한 데이터 형식들을 분리할 수 있다.

    나) 회원 사진 테이블 사례



[그림 4-4-34]는 회원의 이미지 데이터를 저장하는 사진 이미지 칼럼을 수직 분할하여 별도의 회원사진 테이블을 생성한 사례이다.

5) 특정 칼럼에 보안을 적용해야 하는 경우의 분할

    가) 개념

많은 데이터베이스 시스템이 테이블이나 뷰와 같은 객체들에 대해서는 SELECT, UPDATE, DELETE 등과 같은 권한을 제어할 수 있는 기능을 제공하고 있다. 하지만 테이블 내의 칼럼에 대 해서는 이러한 권한(Permission) 제어 기능을 제공하지 않는다. 이러한 경우 해당 칼럼에 대해 권 한을 제어하기 위해서는 보안을 적용하고자 하는 칼럼을 분리해 이를 별도의 테이블로 만들어 그 테이블에 대한 권한을 제어하기 위한 목적으로 수직 분할을 할 수 있다.

    나) 회원 등급 테이블 사례



[그림 4-4-35]에서 회원 등급 칼럼은 서비스 기업의 특정한 사용자들에게만 부여하는 권한이다. 이 권한은 기업이 제공하는 서비스를 제어하고 설정할 수 있도록 하기 때문에 상당히 주의해서 관리되어야만 한다. 그래서 특정 칼럼에 보안을 적용하기 위해서 이를 회원 등급이라는 테이블로 분리하고 이테이블에 대해서 데이터베이스가 제공하는 객체 권한(Object Priviledge)을 조정해서 특정 사용자에게만 권한을 부여할 수 있도록 한다.

중복 테이블 생성

개념

많은 양의 정보들을 자주 Group By, Sum 등과 같은 집계 함수를 이용해서 실시간으로 통계 정보들을 계산해 낼 수 있다. 하지만 대부분 이러한 계산의 유형은 매우 많은 양의 데이터가 대상이 되고, 하나의 테이블이 아닌 여러 개의 테이블에서 필요한 데이터를 추출하는 경우가 대부분이다. 이를 위해서 특정 통계 테이블을 두거나 중복 테이블을 추가할 수 있다.

중복 테이블 생성 판단 근거

- 정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도 증가가 발생하는 경우 고려
- 많은 범위를 자주 처리해야 하는 경우에 고려
- 특정 범위의 데이터만 자주 처리되는 경우에 고려
- 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우에 고려
- 요약 자료만 주로 요구되는 경우에 고려
- 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정
- 인덱스의 조정이나 부분 범위 처리로 유도, 클러스터링을 이용하여 해결할 수 있는지를 철저히 검 토한 후 결정

이와 같은 상황이 존재한다고 판단된다면 논리 데이터 모델에는 존재하지 않지만 물리 데이터 모델에서 중복 테이블을 추가하여 생성할 수 있다.

중복 테이블 유형

중복 테이블에는 다양한 유형이 존재한다. 집계, 진행 테이블 추가를 검토할 수 있는 상황에 대한 예를 들면 다음과 같다.

1) 집계(통계) 테이블 추가

    가) 집계 테이블 유형

- 단일 테이블의 GROUP BY
- 여러 테이블의 조인 GROUP BY

    나) 집계 테이블 생성시 유의사항

- 로우 수와 활용도를 분석하고 시뮬레이션을 통해서 그 효용성에 대한 면밀한 검토가 선행
- 집계 테이블에 단일 테이블 클러스터링을 한다면 집계 레벨을 좀더 낮춰 활용도를 높일 수 있는지를 검토
- 클러스터링, 결합 인덱스, 고단위 SQL 을 활용하면 굳이 집계 테이블 없이도 양호한 수행 속도를 낼 수 있다. 이러한 부분도 사전 검토되어야 한다.
- 집계 테이블을 다시 집계, 조인하면 추출할 수 있는지를 검토하여 지나친 집계 테이블
- 추가된 집계 테이블을 기존 응용 프로그램이 이용할 수 있는지를 찾아 보정시키는 노력
- 데이터베이스 트리거의 오버헤드에 주의하고 데이터의 일관성 보장에 유의

2) 진행 테이블 추가

    가) 진행 테이블 추가 상황

- 여러 테이블의 조인이 빈번히 발생하며 처리 범위도 넓은 경우
- M:M 관계가 포함된 처리의 과정을 추적, 관리하는 경우
- 검색 조건이 여러 테이블에 걸쳐 다양하게 사용되며 복잡하고 처리량이 많은 경우

    나) 진행 테이블 생성시 유의 사항

- 데이터량이 적절하고 활용도가 좋아지도록 기본키를 선정
- 필요에 따라 적절한 추출(Derived) 칼럼을 추가하여 집계 테이블의 역할도 하는 다목적 테이블을 구상
- 다중 테이블 클러스터링이나 조인 SQL을 적절히 이용하면 굳이 진행 테이블을 만들지 않아도 양호한 수행 속도를 낼 수 있는 경우가 많다.

중복 칼럼 생성

개념

논리 데이터 모델링 과정에서 정규화를 통하여 중복 칼럼을 최대한 제거하는 작업
중복 데이터를 제거하는 이유는 여러 가지가 존재하지만 가장 중요한 이유 중에 하나는 데이터 의 정합성을 유지하기 위함
물리 데이터 모델링 과정에서 이러한 정규화를 어기면서 다시 데이터의 중복(중복 칼럼 생성)을 수행

중복 칼럼 생성 상황

- 빈번하게 조인을 일으키는 칼럼에 대해서 고려
- 조인의 범위가 다량인 경우를 온라인화해야 하는 경우처럼 속도가 중요한 칼럼
- 액세스의 조건으로 자주 사용되는 칼럼에 대해서 고려
- 자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 액세스 범위를 줄이지 못하는 경우에 자주 사용되는 조건들을 하나의 테이블로 모아서 조건의 변별성 을 극대화
- 복사된 칼럼의 도메인은 원본 칼럼과 동일하게 해야 한다. 이것은 데이터의 일관성을 위해서 필수 적인 사항
- 접근 경로의 단축을 위해서 부모 테이블의 칼럼을 자식 테이블에 중복
- 상위 레벨의 테이블에 집계된 칼럼을 추가(M:1 관계)할 수 있다. 즉, 집계 칼럼을 추가
- 하위 레벨의 테이블로 중복 칼럼을 복사(M:1 관계)할 수 있다.
- 연산된 결과를 주로 사용하는 경우에도 미리 연산을 하여 중복 칼럼을 생성
- 여러 칼럼들의 수 밖에 없는 값이 검색의 조건으로 사용되는 경우에는 연산의 결과를 중복 칼럼으로 생성
- 여러 개의 로우로 구성되는 값을 하나의 로우에 나열하는 경우이다. 즉 로우로 관리하던 데이터를 칼럼으로 관리하는 경우
- 기본키의 칼럼이 길거나 여러 개의 칼럼으로 구성되어 있는 경우 인위적인 기본키를 추가

중복 칼럼 생성시 유의사항

- 다중 테이블 클러스터링으로 해결할 수 있는지 검토
- SQL GROUP 함수 이용하여 처리할 수 있는지 검토
- 저장 공간의 지나친 낭비를 고려하여 적절한 대비책을 마련
- 반복 칼럼은 특별한 경우를 제외하고는 절대 사용할 필요가 없고, 있다면 sum(decode.. ) 용법과 같은 SQL 
   기법 등을 활용하여 이러한 부분을 피할 수 있도록 한다.
- 경우에 따라 상대 테이블의 ROWID를 복사하는 경우가 효과적일 때도 있다.
- 데이터의 일관성 보장에 유의
- 칼럼의 중복이 지나치게 심하면 데이터 처리의 오버헤드가 발생
- 사용자나 프로그램은 반드시 원본 칼럼만 수정하는 것이 바람직
- 가능하 면 중복 칼럼을 적게 가져가는 것이 바람직하다.
- 클러스터링, 결합 인덱스, 적절한 SQL을 이용하면 특별한 경우를 제외하고는 거의 해결 가능하기 때문에 이 
   부분을 먼저 적극적으로 고려
- 중복 칼럼을 이용하면 손쉽게 액세스 효율을 개선할 수 있으나 지나친 중복화는 반드시 데이터 일관성 오류 
   발생의 개연성 증가 및 데이터 처리 오버헤드 증가라는 반대급부가 있다는 것을 염두 에 두고 수행
- JOIN, SUB-QUERY 액세스 경로의 최적화 방안을 보다 철저히 강구

발췌 - DB GUIDE. NET

[DAP, DAsP] 물리 데이터 모델링 - 물리 요소 조사 및 분석

[DAP, DAsP] 물리 데이터모델링-물리 요소 조사 및 분석

시스템 구축 관련 명명 규칙

사내의 시스템 구축과 관련된 명명 규칙을 파악하여 물리 데이터 모델의 각 요소의 내용에 이를 적용해야 한다.

하드웨어 자원 파악

☞CPU

중앙처리 장치의 성능과 집중적인 부하가 발생하는 시간 등을 파악

☞MEMORY

전체 메모리의 규모 및 시스템이 사용하는 메모리 영역을 포함하여 사용 가능한 메모리 영역을 파악

☞DISK

전체 디스크의 크기, 분할된 형태, 현재 디스크 활용률 등을 파악하고 사용 가능한 공간을 확인

☞I/O Controller

현재 입/출력 컨트롤러의 성능 및 적절하게 운용되고 있는가를 파악

☞Network

네트워크와 관련된 모든 내용을 파악한다. 여기에 관련된 내용으로는 다음과 같은 것들이 존재

- 현재 처리 가능한 속도
- 집중적인 부하가 발생하는 시간대
- 동시 접속 최대 가용 사이트 수

운영체제 및 DBMS 버전 파악

데이터베이스 운영 환경과 관련된 운영체제의 관련 요소를 파악하고 적절하게 관리되고 있는가를 파악한다. 특히 인스턴스 관리 기법 등에 대해서 파악하고 분석한다.

DBMS 파라미터 정보 파악

DBMS 환경 적용 단계에서 가장 중요하게 고려해야 하는 단계
물론 DBMS 파라미터는 데이터베이스 관리 시스템별로 많은 차이가 있으며 관리하는 방법도 서로 다르다.
자신들의 DBMS가 관리하는 파라미터의 종류와 관리 대상들을 정확하게 파악하고 정의
데이터 저장 공간 관리 기법과 메모리 관리 기법 등과 관련된 파라미터들에 대 해서는 세심한 주의
데이터 쿼리에서 활용하는 옵티마이져(Optimizer)의 운영 방법 등도 중요한 고려사항

데이터베이스 운영과 관련된 관리 요소 파악

- 사용자 관리 기법 및 정책
- 백업/복구 기법 및 정책
- 보안 관리 정책


발췌 - DBGUIDE.NET

물리 데이터 모델링 - 물리 데이터 모델링 이해

물리 데이터 모델 정의

물리 데이터 모델이란 논리적 모델을 특정 데이터베이스로 설계함으로써 생성된, 데이터를 저장할 수 있는 물리적인 스키마를 말한다. 데이터 모델의 엔터티와 서브타입은 논리적인 집합이며, 만약 관계형 데이터베이스로 설계한다면 이 단계에 와서 물리적인 테이블(Table)로 확정된다. 하나의 논리적 집합(엔터티 혹은 서브타입)은 하나 이상의 테이블이 될 수 있으며, 경우에 따라서는 속성의 일부만으로 생성될 수 있다.

물리 데이터 모델링은 논리 데이터 모델을 사용하고자 하는 각 DBMS의 특성을 고려하여 데이터 베이스 저장 구조(물리 데이터 모델)로 변환하는 것이다. 여기에서 물리 데이터 모델링과 데이터베이스 디자인과의 개념을 정리하자면 물리 데이터 모델링은 데이터의 구조에 관련된 것들을 물리적인 모습까지 설계하는 것이고, 반면에 데이터베이스 디자인은 이러한 물리적인 모델(설계도면)을 DBMS 관점의 오브젝트로 생성하는 최적의 설계(디자인)를 하는 것이다.

데이터베이스 디자인의 예
- 오브젝트별 저장공간의 효율적 사용 계획
- 오브젝트 파티셔닝 설계
- 최적의 인덱스 설계 등

물리 데이터 모델 의의

물리적 데이터 모델링은 관계 데이터 모델링(RDM, Relation Data Modeling)

사전적으로 작성된 논리적 데이터 모델을 각각의 관계형 데이터베이스 관리 시스템의 특성, 기능, 성능 등을 고려하여 데이터베이스의 물리적인 구조(Schema)를 작성해가는 과정

물리적 데이터 모델링 단계는 논리 데이터 모델에서 도출된 내용 변환을 포함하여
- 데이터의 저장공간
- 데이터의 분산
- 데이터 저장 방법 등
을 함께 고려하는 단계

결정되는 많은 부분이 데이터베이스 운용 성능(Performance)으로 나타나 소홀히 다루면 안된다.

논리 데이터 모델-물리 데이터 모델

☞분산 데이터베이스 구축 시

분산 데이터베이스를 구축하고자 할 때 노드별로 자신이 원하는 형태의 물리적 모델을 생성하고자 할 때 적용

☞물리 데이터 모델 비교

각자 나름대로의 특징을 가지고 있는 여러 개의 물리적 모델을 생성하여 종합적인 비교 검토를 하기 위하여 적용

☞물리적 환경의 변화

논리적인 모델에는 변화가 발생하지 않지만 물리적인 환경에는 변경이 발생했을 때 기존의 물리적 모델을 새로운 목표 물리적 모델로 개선하고자 할 때 적용

☞물리적 모델의 형상관리

물리적 모델이 세월의 흐름에 따라 조금씩 변해갈 때 그 이력을 관리할 목적으로 여러 개의 버전을 보유하고자 할 때 사용하는 경우



발췌 - DBGUIDE.NET

[블로그] 다음 검색등록 성공!

블로그를 시작한지 얼마 되지 않았다.
하루 하루 블로그의 매력에 느끼며 어떤식으로 어떻게 꾸밀까에 대한 고민을 많이 하게 된다. 현재는 창조적인 글은 못 쓰고 이곳 저곳에서 Copy & Paste 를 하고 있지만 조만간 창조적인 글을 작성해 봐야겠다.

다음에 검색 등록을 하니 ...............................................................................................................
훈's IDEABANK 라고 내 블로그가 검색이 된다 ...... 대박 ! ....... 하루 하루 신기함을 느끼며 살아가고 있다 ....... 화이팅 !
...마지막으로 네이버는 좀 느리네 ? 그냥 그렇다고 .

[DAP, DAsP] 논리 데이터 모델링 - 속성 정의

[DAP, DAsP] 논리 데이터 모델링 - 속성 정의

속성 개념

속성 정의

속성은 엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 예를 들어, 엔터티 사원에 속하는 모든 엔터티는 이름을 갖고 있다. 또한 모든 사원에는 입사일자, 사원번호, 생년월일 등의 특성을 가지고 있다. 엔터티 사원에 속하는 모든 인스턴스들이 공통으로 가지는 이러한 특성을 속성(Attribute)이라고 한다. 각 엔터티들은 일련의 속성들에 의해 상세화될 수 있다.

속성 특징

1) 속성의 어원적 의미

속성이라는 의미에는 가공되지 않은 것이라는 의미도 포함되어 있다. 이 말은 곧 원천적인 것을 의미한다. 또한 고유한 성질이란 의미도 가지고 있는데 이 말은 남의 도움을 받지 않더라도 자기만이 가지고 있는 독자적인 성질이 반드시 있어야 함을 뜻한다. 혼자서도 독자적인 성질을 가지고 있느냐에 대한 문제는 절대적이 아니라 상대적이라는 것 때문에 판단이 쉽지 않다. 즉 어떤 시스템의, 어떤 엔터티에서, 어떤 목적으로 사용하려고 하느냐에 따라서 달라지기 때문에 사람의 종합적인 판단이 필요하다는 것이다. 이러한 속성의 어원적인 특징들은 속성 검증의 원칙으로도 사용된다.

2) 속성도 일종의 집합이다.

물리 데이터 모델링 단계에서 엔터티는 테이블이 되고, 속성은 칼럼이 된다. 결국 속성에는 데이터 값이 들어가게 되며, 그 값들은 여러 종류를 가지게 된다. 가령, 사원 정보 엔터티의 직책 속성에는 사원, 대리, 과장, 부장 … 등 여러 종류의 값들이 존재한다. 만약 이 값들의 종류 하나 하나를 개체 라고 한다면, 직책이란 속성은 결국 이들을 구성요소로 하는 집합이란 뜻이 된다.

3) 릴레이션십도 속성이다.

물리 데이터 모델링 단계에 가서 보면 릴레이션십 또한 결국은 일종의 속성이 될 수 밖에 없다.



    가) 매출 부서

[그림 4-3-1]에서 매출 부서는 엄격히 말해서 매출 엔터티의 속성이 아니라 부서 엔터티와의 릴레이션십이라고 하는 것이 정확한 표현이다. 사실 이론적으로 따진다면 속성은 전체 엔터티를 통틀어 반드시 유일하게 존재해야만 한다. 나 자신(속성)은 우리집(엔터티)에 속하고, 거기서 유일하지만 다른 모든 것(엔터티)들에 대해서도 반드시 유일한 존재이다.
매출 엔터티에 있는 매출 부서 속성에는 나중에 분명히 부서 코드가 들어온다. 부서 코드 속성이 오직 한 곳에만 위치해야 한다면 반드시 부서 엔터티에 있어야만 한다. 이 말은 다른 엔터티에 있는 모든 부서 코드는 사실 모두가 릴레이션십이라는 것을 의미한다. 이 릴레이션십은 나중에 데이터베이스 설계 단계에서 관계형 데이터베이스로 설계하고자 한다면 매출 테이블에 매출 부서라는 외래키 칼럼으로 존재하게 된다.

    나) 매출 상품 릴레이션십

[그림 4-3-1]의 좌측에 있는 매출 상품 릴레이션십은 속성이 아닌 릴레이션십으로 제대로 표현 되어 있다. 설계 단계에서 결과적으로 동일해지는데 굳이 이것을 릴레이션십으로 표현하여 그림을 복잡하게 할 필요가 있겠는가?
물론, 원론적으로 본다면 이를 무조건 릴레이션십으로 표현하는 것이 옳다는 것에는 이견이 있을 수 없다. 왜냐하면 우리가 작성하는 논리적 데이터 모델이란 업무를 체계적으로 형상화하는 것이지 데이터베이스의 구조를 정의하는 것이 아니기 때문이다. 엄격히 말한다면 논리적 데이터 모델에는 데이터베이스나 컴퓨터와 같은 물리적 요소들은 전혀 감안하지 않은 상태에서 정의되어야 한다.

4) 속성들 간은 서로 독립적이다

속성들은 반드시 식별자에 직접 종속되어야 한다. 이 말은 정규화의 제2정규형에 해당하는 말이 다. 만약 속성들 간에 종속성이 존재한다면 이들은 별도의 엔터티로 분리되어야 한다. 이것이 바로 제3정규형이다.

속성 후보 도출

속성을 결정할 때에도 다양한 후보를 준비하고 이들 중에서 속성의 검증 규칙에 부합하는 것을 속성으로 최종 결정하게 된다. 특히 이러한 후보 도출 작업은 기존의 현장조사에 국한하지 않고 좀더 적극적이고 개선적인 사고를 가지고 사용자에게 많은 질문을 하고 확인해 속성 후보를 도출한다.

속성 후보 수집처

속성은 결국 속성 후보 중에서 선택되기 때문에 우리는 일단 다양한 경로를 통해서 좋은 후보를 가능하다면 최대한 많이 확보해야 한다.

1) 구 시스템의 문서자료

가동 중인 기존 시스템의 데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용자를 위한 지침서에 이르기까지 다양한 도큐먼트가 있을 것이다. 이 자료는 엔터티 후보 및 속성 후 보를 도출하는데 가장 유용하게 사용할 수 있다.

2) 현업 장표/보고서

현업에서 사용하고 있는 각종 장표나 보고 자료들을 수집해서 조사해 보는 것이다. 현업 업무 중에는 업무를 효과적으로 처리하기 위하여 많은 장표와 각종 보고 자료를 만들고 있다. 물론 이들을 그대로 속성 후보로 선정할 수 있는 것은 결코 아니다. 그 중의 상당 부분은 다른 속성에 의해 만들어질 수 있는 가공된 결과(추출 속성, Derived Value)인 경우가 많기 때문이다. 더구나 이것들은 대부분 정규화가 되어 있지 않기 때문에 정확히 파악해야만 진정한 의미의 속성 후보를 찾아낼 수 있다.

3) 사용자와 협의

데이터 모델링 과정에서부터 시종일관 현업 담당자들과 같이 진행하는 것이 데이터를 모델링하는 최상의 방법이다.

4) DFD의 DD(Data Dictionary)

업무 파악 및 시스템 분석을 위한 기능 설계로 자료 흐름도가 존재한다면 여기에 있는 데이터 저장소(Data Store)와 데이터 사전(Data Dictionary)에 있는 정보를 이용하여 속성의 후보를 도출할 수 있다. 자료 흐름도를 작성할 때 생성되는 자료 저장소는 비록 테이블처럼 표현되지만 사실은 이러한 내용의 데이터가 저장되어야 한다는 데이터의 추상화된 집합이라 할 수 있으며, 그 속에 들어가야할 구체적인 속성이 데이터 사전에 기술된다.

5) 전문 서적 및 자료

동일한 업무에 대한 전문 서적 또는 자료를 통해서도 속성의 후보를 도출할 수 있다.

6) 다른 시스템 자료

우리가 개발할 시스템의 주변을 살펴보면 사내외에 이와 관련된 시스템이나 유사한 시스템을 찾을 수 있을 것이다. 만약 여러분이 그들이 가지고 있던 속성 또한 후보로서 참조하는 것도 속성 후보를 찾는데 좋은 방법이다.

속성 후보 선정 원칙

속성의 후보를 선택할 때는 최대한 충분히 수집해야 한다. 그것은 검토한 결과 자신의 속성이 아닌것으로 판명될지라도 검토할 기회를 제공해 주는 단서라는 중요한 역할을 하기 때문이다.

1) 원시(Source) 속성으로 보이는 후보는 버리지 않는다

다른 속성에 의해 다시 재현할 수 있는 가공(추출, Derived) 속성이 아닌, 다시 말해서 만약 이 속성이 없다면 다시는 재현할 수가 없을 때 이 속성을 원시 속성이라고 부른다. 재현이 불가능하다면 이것을 버리는 순간, 이미 정보는 소실되어 버리므로 절대 버려서는 안된다.

2) 소그룹별로 후보군(Pool)을 만들고 가장 근접한 엔터티에 할당한다

모든 엔터티가 정의되어 있는 상태가 아니라 단지 핵심 엔터티들을 대상으로 모델링을 실시해왔을 뿐이므로 아직은 모든 엔터티가 드러나 있지는 않다. 그렇기 때문에 각 속성 후보들을 적절한 데이터 그룹으로 생성하여 두는 것이 필요하다.

속성의 기본 구성요소

1) 속성명

속성의 내용이나 목적이 무엇인지 알려주는 명사 또는 명사구이다. 기업에서 널리 사용하는 용어 를 쓴다.

속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용한다.
해당 업무에서 일반적으로 사용하는 용어를 사용한다.
실체명은 속성명으로 사용하지 말아야 한다.
필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 하는 것이 바람직하다.

2) 도메인

속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성이다. 모든 영역에서 같은 도메인을 사용하는 것이 좋다. 속성이 기존 도메인 집합에 속해 있지 않는 경우에는 새로운 도메인을 추가한다. 도메인은 다음과 같은 속성들을 가진다.

- 데이터 타입
- 길이
- 허용 값(Permitted Value): 속성에 지정할 수 있는 모든 값들의 집합
- 디폴트 값 및 디폴트 알고리즘

3) 선택성

모든 건의 해당 속성이 반드시 값을 가져야 하는지 여부를 나타낸다.

- 선택성 조건 => 선택성이 다른 속성 값에 의해 영향을 받는 경우
- 필요조건 / 금지조건 / 무관계조건

속성 검증 및 확정

다양한 경로를 통해 수집된 속성 후보를 엔터티에 배정시킨 후 이제 우리가 해야 할 일은 이들을 검증하여 제자리를 찾게 해 주는 일이다. 속성을 검증하는 작업은 총 4단계로 나누어 실시한다.

최소 단위(Atomic Value)까지 분할하라

1) 검증 방법

집합 개념의 속성은 단순 개념으로 분할한다.
가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합한다.
일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋다.
분할 및 통합의 기준은 업무의 요구 사항에 따른다.

2) 분할 속성의 대표적 유형

    가) 일자(日字) 형태의 속성 : 매출일자

분리된 것들이 속성의 자격을 가지고 있는지를 검토하기 위해서는 이들이 자기 혼자서도 독립적 인 의미를 가지고 있는지 확인해 보아야 한다. 매출월(mm)이 매출년도(yyyy)나 매출일(dd)을 무 시하고 혼자서도 어떠한 의미를 가지고 있겠는가? 아마 대부분의 경우는 이들을 하나로 결합했을 때만 매출이 발생한 일자라는 의미를 가질 수 있을 것이므로 이런 경우라면 통합된 것이 속성이라고 보아야 한다.


    나) 외부에서 공인된 속성 : 우편번호 유형

국가나 공공기관에 의해서 이미 공인되어 있는 각종 번호들(예; 우편번호, 주민등록번호, 사업자 등록번호, 법인번호, 여권번호 등)에 대한 속성 관리 형태는 매우 유사하다. 이들은 단지 길이에서 차이가 있지만 대부분 OOO-OOO 형식으로 나타난다. 우편번호의 앞의 세 자리는 마치 성명의 성과같이 나름대로 확실한 의미가 있다. 이 세자리 숫자는 반드시 단 하나의 시군구만 지칭하므로 분명한 의미가 있다는 것이다. 그러나 뒤의 세 자리는 앞의 시군구가 없으면 독자적으로 의미를 갖지는 못한다.

    다) 전화번호 유형 : 전화, 팩스번호

전화번호는 지역번호(DDD)+국번+개별번호로 나누어진다. 일반적인 의미로 본다면 이들 각각 에는 분명히 독립적인 의미가 있다. 그러나 지금 우리가 검토하고자 하는 엔터티 내에서 과연 독립 적인 의미를 가지느냐는 또 다른 문제일 수 있다. 예를 들어, 고객 엔터티에 있는 고객의 연락전화 번호를 검토한다고 가정해보자. 국번만 독립적인 의미로 부여할 경우가 있는가? 뒷자리 4자리의 개별번호만 액세스하여 어떤 처리나 참조를 할 가치가 있는가? 지역번호만 독립적인 의미로 인정 하여 처리할 경우가 있겠는가? 물론 이러한 질문에 대한 대답은 그 엔터티의 내용이나 앞으로의 관리 수준에 많은 영향을 받는다.

    라) 주소 유형 : 고객 주소

주소 형태로 관리되어야 하는 일단의 속성들은 어떤 시스템에서도 자주 등장하는 매우 중요한 속성의 한 유형이다. 주소를 세부적으로 나누는 방법은 여러 가지를 생각해 볼 수가 있다. 가령 도 (광역시) + 시군구 + 읍면동 + 단지(아파트,건물) + 동호수(번지)로 아주 세분화를 시킬 수도 있다. 크게 나누어 우편번호와 연결되어 사전에 이미 생성되어 있는 주소 부분(여기서는 지역주소라고 표현함)과 나머지 부분(상세주소로 표현)으로 분리하는 방법이다.

하나의 값(Single Value)만을 가지는지 검증한다

속성에서 관리되어야 할 값이 반드시 단 하나만 존재해야 한다는 것이다. 그러나 이 말의 진정한 의미는 그 속성에 들어올 수 있는 값의 종류가 반드시 하나만 존재하고 있다는 의미는 절대 아니다. 쉽게 설명한다면 그 엔터티에 들어가는 개체마다 반드시 하나의 값만 보유하고 있어야 한다는 것이다.

1) 검증 방법

여러 값을 가지거나 반복되는 속성은 잘못된 속성이다.
반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화의 대상이 된다.

2) 대표적 유형

    가) 계약일

계약일은 고객 엔터티의 속성이 아니라 가입계약의 속성이다. 즉, 고객은 여러 개의 계약일을 가질 수 있기 때문에 고객의 속성이 될 수 없다. 상황에 따라서 아직 가입계약 엔터티가 도출되지 않 았을 수도 있고, 이미 도출되어 있을 수도 있다. 만약 아직 도출이 되지 않은 상태라면 이 속성에 대한 유일 값 검증에 의해서 가입계약 엔터티는 자연스럽게 도출될 것이며, 이미 존재한다면 이 속 성을 거기에 적절히 반영하면 된다.

    나) 차량번호

어떤 고객은 하나 이상의 차량을 가질 수도 있다. 물론 지금까지 보유한 차량의 이력을 관리하고자 한다면 당연히 유일하지 않을 것이고, 현재 입장에서만 보더라도 하나 이상의 차량을 보유한 사 람들은 얼마든지 존재한다. 그러나 이처럼 실제로는 하나 이상이 존재하지만 업무적으로 판단했을 때 굳이 하나 이상의 차량을 관리할 필요성이 없다거나 과거의 이력을 관리할 의사가 없다면 모델 링 입장에서는 유일값이 되므로 이들은 이 엔터티의 속성이다.

    다) 취미

취미는 사람에 따라 당연히 여러 가지를 가질 수 있다. 취미와 같은 고객의 성향 정보는 마케팅의 중요한 자료가 된다. 엄청나게 많은 고객 모두를 대상으로 마케팅을 한다는 것은 너무 많은 비 용이 들어가기 때문에 가능성이 높은 고객들을 대상으로 표적 마케팅을 하지 않을 수 없다. 이때 고객의 각종 성향 정보는 매우 중요한 가치를 가진 정보이므로 이를 최대한 확보하려는 노력은 반드시 필요하다.

추출 속성(Derived Attribute)인지 검증한다

속성 검증의 제3단계는 그 속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인지를 검증하자는 것이다. 원천적인 값이란 말 그대로 다른 것에 의해 만들어진 것이 아닌 태초부터 창조된 것을 말하며, 추출 값이란 이들을 가지고 언제라도 쉽게 재현할 수 있는 속성을 말한다. 어 쩌면 이것은 매우 분명하고 단순한 개념이지만 실전적인 시각에서 바라보면 그리 간단하지만은 않다.

1) 대표적 유형



    가) 현재 정보만 관리하는 형태 : 현주소, 고객 등급 등

자식 엔터티에 있는 맨 마지막 정보를 현재의 정보라는 의미로 중복화하는 경우라고할 수 있다. 엄밀하게 말하면 이력(선분) 개념이 들어가 있는 자식 정보 중에서 현재 시점을 통과하고 있는 선 분에 해당하는 데이터를 미리 가져다 두는 형태이다.

    나) 최초 정보를 보관하는 형태 : 최초 가입일, 모집 사원 등

자식 엔터티의 여러 정보 중에서 하나만 선택하는 또 하나의 방법은 바로 최초로 발생한 정보만 가져다 두는 것이다. 실전에서 발생하는 대부분의 경우는 현재 정보나 집계 형태로 나타나지만, 가끔은 최초의 정보를 보관하고자 하는 경우도 나타난다.

    다) 집계 정보를 관리하는 형태 : 인원 수, 가족 수, 총직원 수 등

추출 값을 관리하는 속성 중에서 아마 가장 많이 나타나는 형태는 수행 속도를 위해 하위 엔터티의 정보를 집계해 가져다 둔 경우일 것이다. 물론 집계의 형태에는 금액 관련 속성들에서 많이 발 생하는 합계(sum)와 발생회수(count)를 관리하기 위해 사용하는 건수, 회수, 차수 등의 단어가 들 어가는 속성들이 대부분이다.

    라) 추출 릴레이션만 관리하는 형태 : 가입 계약번호, 관리 사원 등

추출 속성 중에는 자식 엔터티의 식별자를 전부 또는 일부만 옮겨둔 것을 자주 발견할 수 있다. 논리적으로는 M쪽의 식별자가 1쪽으로 올 수는 없지만 대부분의 경우 마지막 건의 식별자를 가져 다 두는 경우가 많다.

    마) 대표 정보만 관리하는 형태 : 대표 전자메일 ID, 취미, 법인의 대표자 정보

자식 엔터티에 있는 여러 개의 정보를 하나로 만들어 올리는 방법 중에는 가장 대표적인 것 하나 만을 선정하는 경우도 있다. 예를 들어, 한 사람이 여러 개의 전자메일 ID을 가질 수 있다. 심지어 사람에 따라서는 십여 개를 가지고 있기도 한다.

    바) 다른 속성의 일부 정보만 분리한 형태 : 성별, 결혼 여부 등

추출 속성 중에는 특별한 목적을 위해서 다른 속성의 일부를 떼어서 새로운 속성을 만드는 형태도 자주 등장하고 있다. 사실 우리가 확실한 속성이라고 할 수 있는 성별도 이러한 형태에 속한다. 만약 개인 서브타입에 속하는 모든 고객이 주민등록번호를 반드시 가져야 하고, 그 값이 확실하다고 가정한다면 일곱째 자리에 따라 남·여를 구별할 수 있다.

    사) 일부분만 추출 값인 형태 : 인원 수, 법인의 대표자 정보 등

일부분이란 이 속성에 값이 들어가는 수많은 개체들 중에서 일부는 다른 엔터티에서 가공하여 만들 수 있지만 다른 일부는 원시 값인 경우를 말하는 것이다.

보다 상세하게 관리할 것이냐?

‘보다 근원적인 정보를 관리해야 하지 않겠느냐?’고 질문하는 것이다. 다시 말해 현재까지는 이대로도 충분했지만 수 많은 변화가 예상되는 미래를 대비하기 위해 좀더 근원적인 정보를 관리할 필요 성에 대해 검토해 보자는 것이다. 이 단계가 바로 데이터 모델링이 현재뿐만 아니라 미래의 시스템 구조를 찾아 나가는 과정이라는 것을 의미한다

추출 속성 규칙

다른 엔터티나 속성으로부터 유도되거나 계산된 속성들은 유도 또는 계산에 사용된 기준 속성(Base Attribute)에 대한 종속성과 함께 그 방법이 데이터 모델에 표현되어야 데이터 가공에 따른연관관계를 명확하게 전달하고 기록으로서 의미를 가질 수 있다.

- 초기 데이터 모델링 이론을 보면 도출된 속성이나 가공된 속성은 중복으로 인식하고 이를 데이터 모델에 표현하지 말것을 권고했다. 그러나 현재는 이러한 속성들이야 말로 기업의 관리자들이 관 심을 가지고 보는 속성으로 데이터 모델 내 반드시 기술할 것을 권장하고 있다.
- 추출(Derived) 속성이란 하나 이상의 다른 데이터 속성에 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출하는 속성이다.
- 계산(Calculated) 속성은 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또다른 단일 사례로부터 계산된다.
- 추출 속성은 경영층이 진실로 원하고 필요로 하는 정보를 대표한다.
- 추출 속성은 사용자들의 데이터 요구 사항을 나타낸다.
- 데이터 모델에 추출 속성을 포함시키는 것은 그들의 물리적 구현에 대한 어떤 것도 내포하지 않는다.
- 추출 속성은 향후 과정에서 결코 기본키(Primary Key)로서의 역할을 맡지 않아야 한다.

속성 정의시 유의사항

데이터 모델링을 진행하는 과정에서 속성의 정의 시 흔히 범하는 오류는 필요할지도 모른다고 생각 되는 속성들을 필요할 때마다 이것저것 나열해 두는 방법으로 속성을 정의하는 것이다. 이런 방식의 속성 정의에는 진정한 엔터티 자신의 속성 이외의 다른 엔터티에서 빌려 온 것들이거나 여기저기에 있는 정보를 이용하여 가공을 해놓은 속성들이 많이 존재한다. 하지만 이러한 방법으로 정의된 속성들은 항상 데이터의 정합성을 해칠 수 있는 개연성을 가지고 있기 마련이다. 데이터 모델링에서 데이터가 들어가 살게 될 방이라 할 수 있는 속성을 명확하게 정의하는 일은 중요하다. 속성을 정의할 때에는 다음과 같은 유의 사항을 지켜야 한다.

의미가 명확한 속성 명칭을 부여한다.

속성의 명칭을 명확히 하는 것은 매우 중요하다. 이 말의 진정한 의미는 그 속성의 개념을 정확히 부여한다는 것을 뜻한다.

1) 직업이라는 속성 정의

직업의 사전적인 의미는 생계를 위하여 일상적으로 하는 일이라는 뜻이다. 하지만 이것이 ‘회사원, 전문직, 자영업, 공무원 …’처럼 수십 가지 정도로 분류한 것을 말하는 것인지, 아니면 이 보다 훨씬 상세하게 ‘전산설계, 프로그래머 …‘ 등과 같이 수백 가지로 분류한 것을 말하는지, 아니면 수 천 가지 이상으로 상세하게 분류한 것을 말하는지를 분명하게 정의해야 한다.

2) 학점이라는 속성

학생이 수강한 강좌에서 취득한 ‘A학점, B학점 …’을 말하는 것인지, 그 강좌를 이수했을 때 받는 ‘2학점, 3학점 …’을 말하는지 분명히 해야 한다는 것이다. 이런 상황에서는 설사 최초 설계 단계에서는 매우 명확한 정의가 되었더라도 의미의 와전이나 단절은 필연적으로 발생한다.

유일한 복합명사 사용

속성의 개념을 구체적이고 명확하게 정의했다면 그 명칭을 제대로 부여하는 것도 매우 중요한 일이다. 남들에게 구구절절 보충설명을 하지 않더라도 거의 유사한 생각을 가질 수 있도록 보편적이고 함축성 있는 단어를 찾아내어야 한다. 속성이란 자신만이 가지는 분명한 독립적인 의미를 가지고 있 기 때문에 명칭 또한 단순히 일반 용어만으로 부여해서는 결코 구체적인 의미를 나타낼 수 없다. 결론적으로 말하면, 보편적인 용어를 적절히 결합한 복합명사를 만듦으로써 구체적인 표현을 할수 있다는 것이다.

[그림 5-3-5]와 같은 논리 데이터 모델을 예로 보면 모호하게 이름지어진 속성이 많이 존재한다.



1) 순번

많은 데이터 모델에서 순번 혹은 일련번호라는 명칭의 속성을 자주 접하고 있다. 이 속성은 인조식별자를 생성하기 위해서 사용한 것이 분명하며, 누구나 그렇게 받아들이고 있기도 하다. 그러나 분명히 이 속성의 명칭에는 문제가 있다. 여기서 만약 정확하게 표현하고자 한다면 보험계약순번 혹은 계약순번으로 지정하는 것이 옳다. 만약 순번이라고만 표현한다면 나중에 테이블로 설계가 되었을 때 이 테이블을 참조하는 하위 테이블에서 보면 어디서 온 칼럼인지 분명치 않게 된다. 만약 또 다른 엔터티에서도 순번이라는 속성을 가지고 있고 그것도 참조한다면 실제로는 서로 다른 속성이었지만 참조하는 쪽에서 보면 동일한 이름으로 나타난다는 문제가 있다.

2) 상태

이 명칭만으로는 속성의 의미가 참으로 애매모호하기 짝이 없다. 물론 심증적으로는 보험계약상태를 말하는 것으로 보이지만 확실하지 않다. 실전에서는 이처럼 오해의 여지가 남아있는 애매한 명칭들이 많이 나타난다. 이 상태가 자기 엔터티에서 지정되는 값을 관리하고자 하는 것인지, 하위 엔터 티의 최종 상태를 가져다 둔것인지, 그것도 아니면 하위 엔터티의 상태를 종합해서 새로 의미를 부여한 상태를 의미하는지 구분할 수 없다. 어떤 상태를 의미하는지 누가 보아도 알 수 있도록 명칭을 분명하게 지정해야 한다.

3) 보험기간

보험계약이 적용되는 기간일 것으로 예상되기는 하지만 가령 12개월, 20개월 …로 표현되는 것인지 1년, 2년, …으로 표현되는 것인지를 알 수가 없다.

4) 최초납입영수일자

간결한 명사를 최초 + 납입 + 영수 + 일자로 잘 결합하여 복합명사를 만듦으로서 누가 보더라도 오해가 없을 만큼 상세하게 표현되어 있다.

5) 초회납방

최초로 납입한 회차의 납입 방법을 말하는 것인데 설사 그 업무에 관련 있는 대부분의 사람들이 이해한다고 하더라도 최초납입회차 납입방법으로 표현하는 것이 바람직하다.

이렇듯 우리가 데이터 모델링에서 사용하는 속성명을 분명하게 표현하기 위해서 가능한 한 복합명사를 사용해야 한다.

단수형으로 속성명을 사용한다

속성은 단일 값만을 저장하기 때문에 단수형으로 적는 것이 바람직하다. 예를 들어 고객 엔터티의 전자메일 속성 이름을 [전자메일들]과 같이 지었다면, 이 속성은 여러개의 값들을 저장하는 것인가? 그렇다면 속성이 될 수 없으므로 여러 속성으로 분리하든지 아니면 별도의 고객 전자메일 엔터티로 분리해야 한다.

표준 단어 제정

표준 용어 사전을 데이터 모델링을 하기 이전에 생성하여 두면 데이터 모델의 각 객체들(엔터티, 속성, 테이블, 칼럼 등)이 최대한 그 기준을 준수하도록 유도하기가 용이하며 뚜렷한 일관성이 생길것이다. 또한 표준화 준수 여부를 관리하거나, 표준으로 변경할 대상을 선정하는 일, 어떤 속성의 파생 근원을 분석하는 데도 굉장한 힘을 발휘한다. 뿐만 아니라 속성을 구성하는 단어들을 관리하는 용어 사전에 데이터베이스 설계 단계에서 속성을 칼럼(Column)으로 전환시킬 때 사용할 영문 약어를 같이 제정해 두는 것도 바람직하다. 최근에는 모델링 도구뿐만 아니라 데이터 표준화를 전문적으로 수행하는 툴도 등장하고 있는 추세이다.

작의적인 전용 금지

전용(轉用)이란 말을 사전에서 찾아보면 예정되어 있는 곳에 쓰지 않고, 다른 데로 돌려서 쓰는것이라고 되어 있다. 이말과 통합이란 말에는 미묘한 관련이 있다. 가령 A를 위해 A와 B를 위해서 만들었다면 통합이다. 그러나 결과만 놓고 본다면 어쨌거나 A와 B를 위해 사용되었다는 것은 동일하다.

전용이 발생하는 경우는 크게 세 가지로 나눌 수 있다.

- 모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의했기 때문에 그것을 적용하는 개발자들이 각기 다르게 이해함으로써 나타나는 경우이다.
- 개발이 막바지에 도달했거나 이미 운용 중인 시스템에서 새로운 사용자 요구 사항으로 인해 새로운 속성의 추가가 필요할 때 나타나는 경우이다.
- ERP 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의해 두는 경우를 말한다.

[DAP, DAsP] 논리 데이터 모델링 - 논리 데이터 모델링 이해

[DAP, DAsP] 논리 데이터 모델링 
                  - 논리 데이터 모델링 이해
논리 데이터 모델링 정의

논리적 데이터 모델링이란 데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법이다. 논리적 모델은 데이터 모델링이 최종적으로 완료된 상태를 말한다. 즉, 물리적인 스키마 설계를 하기 전단계의 데이터 모델 상태를 일컫는 말이다.

논리적 데이터 모델링의 핵심은 어떻게 데이터에 액세스하며, 누가 데이터에 액세스하며, 그러한 액세스의 전산화와는 독립적으로 비즈니스 데이터에 존재하는 사실을 인식·기록하는 기법일 뿐만 아니라 철학이다.

특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정이 아닌 별도의 과정을 통해서 조사하고 결정한 사실을 단지 개체-관계 다이어그램(ERD, Entity Relationship Diagram)이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 과정의 도구라고 해야 할 것이다.

논리 데이터 모델링 목적 및 효과

■ 해당 비즈니스에 대한 데이터 관점에서의 명확한 이해

데이터 모델링을 한마디로 하면 업무의 데이터 관점에서의 표현 또는 설계라고 할 수 있다.

■ 전사적인 통합 데이터 체계 확립

논리 데이터 모델링을 통하여 전사의 데이터에 대한 구조를 체계화하고 이를 통한 통합 데이터 체계를 확립한다.

■ 데이터의 일관성 및 정확성 유지를 위한 규칙 도출

기업이 관리하는 데이터의 일관성, 정확성을 유지하기 위해서는 데이터에 대한 정확한 업무 규칙과 데이터 처리 규칙들을 생성 관리해야 한다. 이것을 표현하고 관리하는 것은 논리 데이터 모델을 통해서 하게 된다.

■ 안정적인 데이터베이스 설계의 토대 마련

논리 데이터 모델을 통하여 물리 데이터 모델이 생성된다. 특히 데이터 모델의 구체적인 실체(객체)인 데이터베이스를 안정적이고 체계적으로 생성하는 기초가 된다.

■ 사용자와의 명확한 의사소통을 위한 수단으로 활용

시스템 설계자와 업무 담당자 간의 의사소통의 수단으로 논리 데이터 모델이 사용된다. 반면 설계자와 개발자 간의 의사 소통의 수단은 물리 데이터 모델이라고 볼 수 있다. 하지만 이 과정에서 개발자라고 하더라도 논리 데이터 모델에 표현되어 있는 비즈니스 규칙에 대한 이해가 선행되어야 한다.

논리 데이터 모델링 필수 성공요소

■ 업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행하라

데이터 모델링 작업은 결국 업무를 데이터 관점에서 체계화하는 작업이다. 즉, 비즈니스에서 사용되는 데이터를 집합(엔터티)으로 생성하고 이들 간의 관계(Relationship)를 지정하는 작업이다. 이러한 작업을 하는 과정에서 업무를 알고 있는 현업 사용자의 참여는 필수적이다.

■ 절차(Procedure)보다는 데이터에 초점을 두고 모델링을 진행하라

데이터 모델에는 순서와 시간, 흐름의 개념이 들어가지 않는다. 이러한 개념을 넣어서 마치 데이터 흐름도(DFD, Data Flow Diagram)처럼 업무의 흐름에 따라 엔터티가 발생하는 경우를 실전에서는 많이 보게 된다. 이런 식의 데이터 모델에서는 많은 데이터의 중복과 데이터 정합성을 훼손할 개연성을 내포한 모델이 만들어지게 마련이다. 그렇기 때문에 가능한 절차를 배제한 채로 데이터 모델을 생성해야 한다.

■ 데이터의 구조(Structure)와 무결성(Integrity)을 함께 고려하라

■ 개념화(Conceptualization)와 정규화(Normalization) 기법을 적용하라

■ 가능하면 다이어그램(Diagram)을 이용하여 업무를 표현하라

■ 데이터 모델링을 지원하는 데이터 사전을 구축하라

발췌 - DB GUIDE.NET

[구글 블로그]구글 블로그 추가 및 검색 가능하게 변경

블로그 검색에 블로그 추가(클릭)

웹마스터 등록 - 검색 가능하게 변경(블로그 글)(클릭)