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

속성 정의

 

1.   속성 개념

가.  속성 정의

속성은 엔티티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다.

 

나.  속성 특징

1)     속성의 어원적 의미
속성이라는 의미에는 가공되지 않은 것이라는 의미도 포함되어 있다. 이 말은 곧 원천적인 것을 의미한다.

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

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

가)   매출 부서

매출 엔티티에 있는 매출 부서 속성에는 나주에 분명히 부서 코드가 들어온다. 부서 코드 속성이 오직 한곳에만 위치해야 한다면 반드시 부서 엔티티에 있어야만 한다. 이 말은 다른 엔티티에 있는 모든 부서 코드는 사실 모두가 릴레이션십이라는 것을 의미한다. 이 릴레이션십은 나중에 데이터베이스 설계 단계에서 관계형 데이터베이스로 설계하고자 한다면 매출 테이블에 매출 부서라는 외래키 칼럼으로 존재하게 된다.

나)   매출 상품 릴레이션십

원론적으로 본다면 이를 무조건 릴레이션십으로 표현하는 것이 옳다는 것에는 이견이 있을 수 없다. 왜냐하면 우리가 작성하는 논리적 데이터 모델이란 업무를 체계적으로 형상화하는 것이지 데이터베이스의 구조를 정의하는 것이 아니기 때문이다. 엄격히 말한다면 논리적 데이터 모델에는 데이터베이스나 컴퓨터와 같은 물리적 요소들은 전혀 감안하지 않은 상태에서 정의되어야 한다.

4)     속성들 간의 서로 독립적이다.
속성들은 반드시 식별자에 직접 종속되어야 한다.

 

2.   속성 후보 도출

가.  속성 후보 수집처

1)     구 시스템의 문서자료

2)     현업 장표/보고서

3)     사용자와 협의

4)     DFD의 DD(Data Dictionary)

 

나.  속성 후보 선정 원칙

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

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

 

다.  속성의 기본 구성요소

1)     속성명

n  속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용한다.

n  해당 업무에서 일반적으로 사용하는 용어를 사용한다.

n  실체명은 속성명으로 사용하지 말아야 한다.

n  필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 하는 것이 바람직하다.

2)     도메인

n  데이터 타입

n  길이

n  허용 값(Permitted Value): 속성에 지정할 수 있는 모든 값의 집합

n  디폴트 값 및 디폴트 알고리즘

3)     선택성

n  선택성 조건 => 선택성이 다른 속성 값에 의해 영향을 받는 경우

n  필요조건 / 금지조건 / 무관계조건

 

3.   속성 검증 및 확정

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

1)     검증방법

n  집합 개념의 속성은 단순 개념으로 분할한다.

n  가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합한다.

n  일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋다.

n  분할 및 통합의 기준은 업무의 요구사항에 따른다.

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

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

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

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

라)   주소 유형: 고객 주소

 

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

1)     검증방법

n  여러 값을 가지거나 반복되는 속성은 잘못된 속성이다.

n  반복되는 속성은 새로운 엔티티로 분할해야 할 1차 정규화의 대상이 된다.

2)     대표적 유형

가)   계약일

계약일은 고객 엔티티의 속성이 아니라 가입계약의 속성이다.

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

나)   차량번호

어떤 고객은 하나 이상의 차량을 가질 수도 있다.

다)   취미

취미는 사람에 따라 당연히 여러 가지를 가질 수 있다.

 

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

속성 검증의 제 3단계는 그 속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인지를 검증하자는 것이다. 원천적인 값이란 말 그대로 다른 것에 의해 만들어진 것이 아닌 태초부터 창조된 것을 말하며, 추출 값이란 이들을 가지고 언제라도 쉽게 재현할 수 있는 속성을 말한다.

1)     대표적 유형

가)   현재 정보만 관리하는 형태: 현주소, 고객 등급 등
이력(선분) 개념이 들어가 있는 자식 정보 중에서 현재 시점을 통과하고 있는 선분에 해당하는 데이터를 미리 가져다 두는 형태이다.

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

다)   집계 정보를 관리하는 형태: 인원 수, 가족 수, 총 직원 수 등
추출 값을 관리하는 속성 중에서 아마 가장 많이 나타나는 형태는 수행 속도를 위해 하위 엔티티의 정보를 집계해 가져다 둔 경우일 것이다.

라)   추출 릴레이션만 관리하는 형태: 가입 계약번호, 관리 사원 등
추출 속성 중에는 자식 엔티티의 식별자를 전부 또는 일부만 옮겨둔 것을 자주 발견할 수 있다. 논리적으로는 M쪽의 식별자가 1쪽으로 올 수는 없지만 대부분의 경우 마지막 건의 식별자를 가져다 두는 경우가 많다.

마)   대표 정보만 관리하는 형태: 대표 전자메일 ID, 취미, 법인의 대표자 정보
자식 엔티티에 있는 여러 개의 정보를 하나로 만들어 올리는 방법 중에는 가가 대표적인 것 하나만을 선정하는 경우도 있다.

바)   다른 속성의 일부 정보만 분리한 형태: 성별, 결혼 여부 등
추출 속성 중에는 특별한 목적을 위해서 다른 속성의 일부를 떼어서 새로운 속성을 만드는 형태도 자주 등장하고 있다.

사)   일부분만 추출 값인 형태: 인원 수, 법인의 대표자 정보 등
일부분이란 이 속성에 값이 들어가는 수 많은 개체 중에서 일부는 다른 엔티티에서 가공하여 만들 수 있지만 다른 일부는 원시 값인 경우를 말하는 것이다.

 

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

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

 

4.   추출 속성 규칙

n  초기 데이터 모델링 이론을 보면 추출된(Derived) 속성이나 가공된 속성은 중복으로 인식하고 이를 데이터 모델에 표현하지 말 것을 권고했다. 그러나 현재는 이러한 속성들이야 말로 기업의 관리자들이 관심을 가지고 보는 속성으로 데이터 모델

n  추출(Derived) 속성이란 하나 이상의 다른 데이터 속성에 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출하는 속성이다.

n  계산(Calculated) 속성은 엔티티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또 다른 단일 사례로부터 계산된다.

n  추출 속성은 경영층이 진실로 원하고 필요로 하는 정보를 대표한다.

n  추출 속성은 사용자들의 데이터 요구 사항을 나타낸다.

n  데이터 모델에 추출 속성을 포함시키는 것은 그들의 물리적 구현에 대한 어떤 것도 내포하지 않는다.

n  추출 속성은 향후 과정에서 결코 기본키(Primary Key)로서의 역할을 맡지 않아야 한다.

 

5.   속성 정의 시 유의 사항

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

1)     직업이라는 속성 정의

2)     학점이라는 속성

 

나.  유일한 복합명사 사용

속성의 개념을 구체적이고 명확하게 정의했다면 그 명칭을 제대로 부여하는 것도 매우 중요한 일이다.

결론적으로 말하면, 보편적인 용어를 적절히 결합한 복합명사를 만듦으로써 구체적인 표현을 할 수 있다는 것이다.

1)     순번
여기서 정확하게 표현하고자 한다면 보험계약순번 혹은 계약순번으로 지정하는 것이 옳다.

2)     상태
어떤 상태를 의미하는지 누가 보아도 알 수 있도록 명칭을 분명하게 지정해야 한다.

3)     보험기간
개월로 표기되는지, 년도로 표현되는 것인지를 알 수가 없다.

4)     최초납입영수일자
누가 보더라도 오해가 없을 만큼 상세하게 표현되어 있다.

5)     초회납방
최초납입회차 납입방법으로 표현하는 것이 바람직하다.

 

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

속성은 단일 값만을 저장하기 때문에 단수형으로 적는 것이 바람직하다.

 

라.  표준 단어 제정

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

 

마.  작의적인 전용 금지

전용이란 말을 사전에서 찾아보면 예정되어 있는 곳에 쓰지 않고, 다른 데로 돌려서 쓰는 것이라고 되어 있다

n  모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의했기 때문에 그것을 적용하는 개발자들이 각기 다르게 이해함으로써 나타나는 경우이다.

n  개발이 막바지에 도달했거나 이미 운용 중인 시스템에서 새로운 사용자 요구사항으로 인해 새로운 속성의 추가가 필요할 때 나타나는 경우이다.

n  ERP 패키지에서 자주 나타나는 형태로서, 미리 전용의 용도로 속성을 정의해 두는 경우를 말한다.