속성 개념

속성 정의

속성은 엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 예를 들어, 엔터티 사원에 속하는 모든 엔터티는 이름을 갖고 있다. 또한 모든 사원에는 입사일자, 사원번호, 생년월일 등의 특성을 가지고 있다. 엔터티 사원에 속하는 모든 인스턴스들이 공통으로 가지는 이러한 특성을 속성(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 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의해 두는 경우를 말한다.