4.26 단순(Simple)속성 & 복합(Composite)속성

• 단순속성 : 논리적으로 의미가 있는 원자값으로 이루어진 속성
• 복합속성 : 두개 이상의 의미있는 단순속성으로 분해할 수 있는 속성
• 복합속성의 판단은 나누어서 의미가 있느냐가 기본적인 기준이며, 업무에서 사용여부가 기준이 되기도 한다.
• 다가속성? 복합속성?
  • 다가속성 : 각 자리가 의미하는 바가 동일 예)'수영,골프,테니스'
  • 복합속성 : 각 자리가 의미하는 바가 다름 예) '02-123-4567'
• 텍스트 속성도 넓은 의미의 복합속성임. 주제를 나눌 수 있는 내용이라면 개별속성으로 분해하는 것이 좋음
• 복합속성을 개별속성으로 분해할지 판단기준은 개별적인 의미로 조회되는지의 여부다.
• 개념모델에서는 모델의 복잡성이 줄고 가독성이 좋아서, 다가속성, 복합속성도 자주사용

4.27 필수(Required)속성 & 선택(Optional)속성

• 모델링의 품질을 높이기 위해 필수속성과 선택속성을 구분하는 것이 바람직
• 필수속성에는 Not Null 제약을 생성해야 하며, 필요시 Default제약을 생성해야 함
• 논리적, 물리적인 필수,선택속성은 의미가 다름
  • 논리적인 필수속성은 일반적인 알고 있는 필수속성의 의미
  • 물리적인 필수속성은 Default값을 지정한 속성

4.28 배타(Exclusive)속성

• 하나의 인스턴스에 대해 배타속성에 값이 모두 존재하면 데이터 무결성이 깨진 상태가 되기 때문에 주의

고객유형코드에 따라 주민등록번호 또는 법인등록번호에 저장됨	고객유형코드에 따라 고객식별번호가 의미하는 바가 다름
입출구분코드 속성값에 따라 발생일자,수량, 입출지점번호가 의미하는 바가 다름	종목구분코드에 따라 종목번호가 의미하는 바가 다름

• 배타속성은 구분자 역할을 하는 속성과 같이 위치해야 가독성이 좋아짐.

4.29 코드(Code)속성과 비코드(Non-Code)속성

• 코드속성은 코드엔터티를 봐야 물리적 값이 의미하는 바가 무엇인지 알수 있다.
• 비코드속성은 실제값이 저장되므로, 의미파악이 안되는 값이라면 데이터 자체가 잘못되었거나 관계속성일 경우임
• 식별자코드와 구별해야 함

4.30 일반코드와 식별자코드

• 식별자코드는 엔터티의 주식별자면서 속성이름이 '~코드'로 끝난 속성
• 특징
  • 식별자코드를 주식별자로 하는 독립된 엔터티가 존재
  • '_{코드'대신 '}번호'로 사용가능
  • 식별자코드 자체가 하나의 인스턴스이며 하나의 실체를 의미(일반코드는 독립적인 실체에 대한 '묶음'이나 '집합'을 의미)
• 식별자코드로 사용된 인조식별자에 체계가 존재하는 것은 좋지 않음
• 식별자코드와 연관된 엔터티가 실체엔터티

4.31 식별자코드와 일반코드의 관리

{+}일반코드&내부데이터{+}

• 코드엔터티에서 통합관리

{+}일반코드&외부데이터{+}

• 전문정의서나 인터페이스정의서 등에서 정한 코드인스턴스를 공통코드엔터티에서 통합관리

• 별도 엔티티에서 해당 코드를 관리

{+}식별자코드&내부데이터{+}

• 일반엔티티에서 관리하므로 특별한 문제 없음

{+}식별자코드&외부데이터{+}

• 식별자 코드와 함께 명(설명)을 사용한다면, 별도의 엔터티에서 관리
• 외부기관에서 보내줄 수 있는 속성 그대로 설계

4.32 식별자코드와 일반코드의 상호변환

• 일반코드가 식별자코드가 되는 경우(즉, 공통 엔티티에서 코드값, 코드명을 관리하다가, 별도 관리 속성이 늘어나 엔티티를 생성하는 경우)
  • 엔티티명을 '~코드'로 정하는 것은 적절치 않음
  • 공통코드 엔터티에서 관리하던 관련 인스턴스는 삭제해야 함.

4.33 통합코드로 설계할지 개별엔터티로 설계할지?

• 데이터 집합의 인스턴스가 개별개체를 의미하는지 확인. 그 인스턴스가 명칭 외에 특성이 있는지 확인
• 데이터가 실제의 개체를 의미하는지, 개체의 묶음을 의미하는지에 따라 판단
  • 실제의 개체라면 개별엔티티로, 개체의 묶음이라면 통합코드로 관리

4.34 코드속성의 명명법

• 식별자코드와 일반코드는 성격이 다르므로 속성이름을 구분해서 정하는 것이 좋음
• 식별자코드는 '_{번호'로 사용(단, 식별자값이 문자,숫자가 혼합되고, 체계가 있어 범용적으로 코드값으로 인식해서 사용한다면 '}코드'로 사용가능)
  예)부서코드, 지점코드
• 일반코드는 구분, 유형, 종류등을 붙여서 사용가능
• 사용법
  • 구분코드 : 코드명이 더이상 늘어나지 않고 고정적일 때 사용. 예)남녀구분코드
  • 종류코드 : 고정적이지 않고 지속적으로 늘어날 수 있는 코드명을 나열할 때 사용. 예)서비스종류코드, 지불수단종류코드
  • 유형코드
    • 성질이나 특징이 유사한 것 끼리 묶을 때 사용. 예)지불수단유형코드, 거래유형코드
    • 유형코드는 종류코드의 여러 종류를 다시 한번 묶은 코드를 의미, 코드 인스턴스가 거의 늘어나지 않음

4.35 코드 인스턴스(집합) 설계원칙

• 코드값은 코드명에대한 사전에 정한 기호일 뿐, 코드명을 잘 설계하는 것이 중요
• 코드나 엔터티나 모두 집합개념을 기반으로 설계하므로, 설계기준이 동일
  

{+}코드인스턴스 설계원칙{+}

• 성격이 동일해야 함

S={동물,식물,양의정수,음의정수} (X)

• 상호배타적이어야 함

• 전체가 합집합이어야 함

• 상세화 수준이 유사해야 함

4.36 코드를 사용하는 용도

• 집계용도 : 나중에 집계의 필요성으로 사용하려고 할때
• 조회용도 : 업무에서 필요한 인스턴스만 조회할 경우
• 분기용도 : 프로그램에서 다른 로직을 적용해야 한다거나, 화면에 달리 보여줘야 할때
• 서브타입 구분용도 : 슈퍼타입의 특정 인스턴스가 어떤 서브타입과 연관되는지 알기위해 코드로 구분

4.37 코드 엔터티와 참조 무결성 관계

• 코드엔터티 관리방법
  • 개별코드 엔터티에서 관리하면서 직접관계존재 : 명 이외에 관리할 속성이 있거나, 인스턴스가 상당히 많다면 고려. 최근에는 거의 사용X
    
  • 통합코드 엔터티에서 관리하면서 직접관계존재 : 관계선 표현 생략가능. 가능한 표현해줄것
    
  • 통합코드 엔터티에서 관리하면서 간접관계존재 : 최근에 가장 많이 사용하는 모델. 논리적으로만 관계가 존재
    
  • 통합코드 엔터티에서 관리하면서 직접관계존재 : 그림 4.88을 보완한 모델, 주식별자를 단순화
    

4.38 통합 코드 엔터티 & 개별 코드 엔터티

• 한 종류의 코드를 개별 엔터티에서 관리하면 저장공간낭비가 심하고, 모델의 가독성이 나빠짐

{+}개별 엔터티에서 관리하는 것이 좋은 경우(예외)+

• 코드값, 코드명 이외에 관리할 속성이 있을 때
• 부분집합의 개념, 코드간의 관계등 코드관리에 부가적인 기능이 추가될 때
• 코드인스턴스가 상당히 많아 메모리 적중률을 저하시켜 다른 코드에 성능에 영향을 미칠 때
• 집중조회로 인한 경합현상 때문에 조회성능을 저하시킬 때
• 코드 인스턴스를 외부에서 받을 때
• 코드값이 자주 바뀔 때

4.39 일반적인 코드 모델

• 코드엔터티는 일반적인 엔터티와 성격이 다름
• 데이터 성격을 파악해 엔터티를 도출하기보다 관리가 용이하고, 어플리케이션에서 편리하게 사용가능한 방법으로 설계해야 함.

{+}유형1{+}

• 가장 일반적인 모델
• 매수매도구분을 의미하는 코드유형번호가 001이라는 것을 알고 있어야 함

{+}유형2{+}

• 4.91과 모델은 동일하나, 코드유형 엔터티의 코드유형코드 속성값을 코드 속성의 물리명을 사용
• 일반적으로 주 식별자 값에 의미부여는 좋지 않으나, 코드모델은 어플리케이션에서 사용하기 편하도록 의미를 부여하는 것이 좋은 방법
• 4.94의 코드유형코드 속성값에 코드 속성명(한글)을 사용하는 것도 유용한 방법

{+}유형3{+}

• 하나의 엔터티에서 코드유형과 코드값을 통합관리
• 코드유형번호가 null인 것은 코드유형을 의미
• 코드속성값 앞 세자리와 코드유형번호 속성 값과 일치하게 관리해야 하며, 중복데이터이고 저장공간의 낭비가 있으나, 사용이 편리
• 관계선 표현도 수월하여 참조 무결성 제약을 생성할 수 있어, 데이터 무결성을 높일 수 있음

{+}유형4{+}

• 데이터를 구조적으로 관리
• 4.95와 같은 효과가 있으면서, 공간을 더 사용하고, 덜 유연

=> 데이터만 제대로 생성해 놓으면 사용이 편리해서 필자는 주로 그림 4.95 모델을 사용

4.40. 전체 코드의 부분집합을 관리하는 모델

• 전체코드값 집합중에 필요한 코드값만 부분집합으로서 별도 관리할 수 있는 모델
• 문제점
  • 관리문제
  • 오너십문제

4.41. 코드 간 관계를 관리하는 코드 모델

• 코드값(코드인스턴스)간에 존재하는 계층 체계를 관리하는 기능
• 코드를 전체집합과 부분집합으로 나눠 관리하는 방법과 유사
• 계층체계는 상위계층의 코드만 관리, 상하위계층 코드를 관리하는 것으로 나눌수 있음

{+}상위코드를 관리하기 위한 모델{+}

{+}다대다관계를 관리하기 위한 모델{+}

• 주문채널구분코드(103)은 '온라인'과 '오프라인'이 있음
• '온라인'에는 온라인채널종류코드 유형에 속하는 HTS, ARS, MTS가 있으며, '오프라인'에는 오프라인채널종류코드 유형에 속한 창구,지점단말이 있음
• 그림 4.104는 상위코드만 관리 가능, 상하구분없이 관리하는 요건에는 그림 4.107이 유연

{+}서브코드를 관리하는 모델과 코드계층을 관리하는 모델을 혼합한 모델{+}

• 서브코드를 관리하는 그림 4.100과 코드계층을 관리하는 그림 4.107을 혼합한 모델
• 매우 유연하나 복잡한 모델, 요건의 중요도가 미미할 때는 단순한 모델 사용

4.42. 출력 순서를 관리하는 코드 모델

4.43. 코드 모델의 이력관리

• 감시의 목적으로 이력관리가 필요

• 코드유형 엔터티에서는 '코드유형명'만 이력관리
• 코드 엔터티에서는 코드는 코드인스턴스 전체를 봐야 의미를 알 수 있으므로, 전체코드인스턴스를 스냅샷방식으로 이력관리

4.44. 속성명은 어떻게 정하는가?

• 도메인 성격의 속성명은 혼란을 초래하여 임의대로 해석해서 사용하게 됨
• 예) 전화번호(X), 자택전화번호(O), 고객자택전화번호(O)
• 영문명은 가능한 짧은 것이 좋기 때문에, 단어에 대응하는 영문단축명은 짧게 정하는 것이 좋음
• 속성명도 전체 모델에서 유일하게 존재해야 하는 것이 원칙이나, 이것은 너무나 이상적
• 관계속성은 참조하는 엔터티의 주식별자를 참조하여 속성명을 정해야 함

4.45. 속성 설명

• 속성 설명은 기술하는 것이 원칙
• 속성설명은 단순, 명료하게 기술(명사형으로 끝나는 간략한 형식)
• 해당 엔터티에서의 속성 쓰임새를 기술하는 것이 좋음
• 중복속성은 원본속성이 무엇인지 기술, 추출속성은 추출대상 데이터와 추출로직을 기술, 코드속성은 코드 인스턴스를 기술

4.46. 속성 표준화

• 속성의 일관된 사용은 데이터 오류를 줄여 데이터 품질을 높임
• 사전전 의미에 얽매이기 보다는 일관된 사용이 더 중요

{+}단어{+}

• 속성 표준화의 출발은 단어를 정의하는 것
• 속성에 사용한다는 것을 전제로 단어를 정의해야 함(업무적 사용 또는 화면에서 활용용도로 적절치 않음)

{+}영문약어{+}

• 영문약어는 컬럼명에 사용하므로 단순하게 사용(길게 정의하지 않도록 주의)
• 단어의 영문약어는 2~3개의 알파벳으로 정하는 것이 복합어를 최소화하는 방법임

{+}이음동의어{+}

• 이음동의어 : 동일한 의미의 여러단어 예) 사원, 직원
• 이음동의어 중 대표적 하나의 단어만 사용하고, 이음동의어로 묶인 다른 단어들은 참조만 할 수 있도록 할 것

{+}동음이의어{+}

• 동음이의어 : 동일한 단어인데 의미가 다른 것 예) '이후'에 대한 상대적인 의미인 이전, '옮긴다'의 이전
• 사용하지 않는 것이 바람직하나 불가피하게 허용하기 위해서는 시스템에서 기능을 지원해야 함
  ==> 속성등록시 '이전'이라는 단어 사용하려 할 때, 두개의 영문을 보여줘 선택할 수 있도록 해야 함

{+}도메인{+}

• 속성을 표준화하기 위해서는 기본적인 표준화 원칙이 있어야 하며, 상세한 지침이 있어야 함
• 상세지침 사례
  • 특정한 날짜를 의미할 때는 '일자'를 사용한다. 예)입금일자
  • '시분초'까지 의미할 때는 '일시'를 사용한다. 예)방문일시
  • 년,월,일 중 일부만을 의미할 때는 '년', '년월', '월', '월일', '일'등으로 사용한다. 예)회계년, 기준년월, 적용월, 이체일
  • 가격,좌수,단가,잔액등의 관행적으로 사용하는 단어를 제외하고, 금전을 의미할 때는 '금액'을 사용한다. 예)계약금액
  • 비율을 의미할 때는 '율'을 사용한다. 예)이율
• 표준화는 모델링의 작은부분임. 데이터 정의를 명확히 하고, 정규화를 기반으로 데이터구조를 정확하게 구축하는 역할에 집중해야 함.

4.47. 도메인(Domain)

{+}물리 도메인{+}

• 물리도메인을 구성하는 주요 요소는 데이터 타입과 길이. (허용값의 범위와 기본값, 값의 포맷등을 포함하기도 함.)
• 도메인 개수를 한정하는 것은 바람직하지 않음
• 도메인이 많아지는 것에 대한 부담이 있다면, 도메인은 타입만 지정하고 자릿수는 별도로 지정하는 방법이 시스템을 유연하게 함.

{+}논리 도메인{+}

• 대표속성을 의미
• 예) '고객명'이라는 속성등록시 varchar(30)이라는 물리도메인을 지정. 의미가 유사한 'CRM고객명'이라는 속성등록시 varchar(30)대신, '고객명'이라는 속성을 지정 ==> '고객명'이 논리도메인 역할을 함
• 데이터 성격이 고정적인 속성에만 적용하는 것이 바람직
  • 주식별자(후보식별자, 업무식별자, 인조식별자 등)
  • 식별자번호(주민등록번호, 사업자등록번호, 법인등록번호, 전화번호 등)
  • 코드속성
  • 표준 데이터 성격의 기준 데이터(우편번호, 주소 등)
  • 외부시스템에서 받은 번호나 코드
• 논리도메인을 사용하면 동일한 것을 의미하므로 속성을 일관되게 사용하게 되어 무결성이 높아짐

4.48. 도메인과 메타 시스템

• 도메인과 속성명은 밀접한 관계가 있음. 속성표준화는 메타시스템을 사용해야 함.
• 결합도를 감안하여 논리 도메인으로 묶고, 물리 도메인을 자유롭게 지정할 수 있도록 사용하는 것이 유연.

4.49. 데이터 타입 선정 원칙과 절차

• 속성데이터가 날짜면 Date, 숫자면 Number, 문자면 Varchar를 사용하는 것이 기본원칙
• 숫자이나 종류가 한정되어 있다면 문자타입으로 정하는 것이 좋음 예) 고객등급(1~5등급)
• 데이터 타입 선정 절차
  
• 속성의 데이터타입은 개념모델링 단계부터 고려하여 결정

4.50. 널(Null)에 대한 서설

• 속성을 정밀하게 모델링하기 위해서는 '모르는 것'과 '해당 사항이 없는 것'을 구분할 필요가 있음
• 주문상태코드가 '1'인 경우만 주문취소사유가 존재, '해당없음(0)'과 '모름(9)'를 분리해서 관리
• 널이 존재하는 속성이 많을 때는 원천 엔터티에서 분리해서 별도의 엔터티에서 관리하는 것도 고려

4.51. 널(Null)과 DBMS & 인덱스

• DBMS에서는 널(Null)값도 하나의 고유한 값이므로, 사용시 세심한 주의가 필요
• Null값의 활용
  • Null로 저장된 인스턴스가 적은 경우, 속성에 기본값(Default)값을 사용해 인덱스 사용을 유도
  • Null로 저장된 인스턴스가 많은 경우, 널(Null)값을 사용해 테이블 풀스캔을 유도
• 한 방향으로 널 허용여부를 결정하기 보다는 기본적으로 Null을 허용하여 본질적으로 접근하고, 물리적 특성을 고려할 때는 Null을 허용하지 않는 것이 바람직

4.52. 널(Null)사용법 & 특징

• 속성의 특성에 맞게 널 허용여부를 결정
• 대체로 널값을 허용하면 좋지않은 속성 : 코드속성, 여부, 유무 속성
• 외래식별자는 업무요건에 따라 결정(널 허용일 때는 기본값을 사용하지 말아야함)
• 금액속성인 경우도 주의 요함
• 널 허용과 Not Null 제약에 대한 특징
  

4.53. 속성 검증(Attribute Review)

• 속성은 개수가 많아 검증이 어려움. 메타시스템을 이용하여 기계적인 방법으로 검증가능

{+}속성 존재 여부 검증방법{+}

• 모델에 표현이 안된 속성이 있는지, 불필요한 속성이 있는지를 검증
• 어플리케이션 화면에서 사용한 항목과 모델 속성과의 매트릭스를 작성하여 비교
  • 화면에는 존재, 속성은 없음
  • 속성은 존재, 화면은 없음
  • 속성 없음, 화면에도 없음

• ASIS속성과 TOBE속성과의 매트릭스 작성 비교
  • ASIS존재, TOBE없음
  • ASIS없음, TOBE존재

{+}식별자 검증방법{+}

• 엔터티명과 엔터티 정의, 주식별자를 엑셀로 뽑아서 서로 어울리는지 검토
• 주식별자에 논리적인 널값(기본값) 사용은 바람직하지 않음
• 주식별자 속성은 값이 변경되지 않아야 하고, 추출속성이 사용되면 안됨
• 체계가 존재하는 식별자 지양, 단순해야 함
• 부분인조식별자가 사용된 엔티티는 재검토
• 슈퍼식별자 사용금지
• 복합 주 식별자 사용시 식별자의 순서의 효율성 겁토
• 주 식별자가 동일한 엔터티가 존재하지 않는지 검토

{+}일반속성 검증{+}

• 속성이 단어의 조합으로 구성되어 있는지 확인
• 속성명이 도메인과 일치해서는 안됨(사원번호와 같은 도메인 역할을 하는 속성은 제외)

{+}모델구조 검증{+}

• 속성명끝에 숫자가 포함된 속성지양(속성명을 구체적으로 정하던, 정규화를 통해 엔터티 분리 고려)
• 반복속성 검토(반복속성 불변일때는 비정규화 고려하나, 기본적으로 정규화 검토)
• 복합속성 다가속성
• 중복속성, 추출속성
  • 중복속성 최대한 사용배제
  • 추출속성은 추출로직 기술
• 코드속성은 코드 인스턴스확인
• 서브타입 모델은 슈퍼/서브타입의 속성이 제위치에 있는지 확인
• 주식별자에 변경일자, 종료일자 속성이 포함되어 있으면 이력엔티티인가 맞는지 확인
• 이음동의어, 동음이의어 검토