[4-3-2]: 속성 정의

01. 속성이란?

엔터티에서 관리하고자 하는, 

더 이상 분해될 수 없는 최소의 데이터 보관 단위.

속성의 특징

• 필요성 : 해당 엔터티에서 반드시 필요한 속성이어야 함.
• 명세성 : 해당 속성이 엔터티의 특성을 표현할 수 있어야 함.
• 원자성 : 더 이상 분해되지 않는 속성이어야 함.
• 종속성 : 주식별자에 대하여 함수적 종속성을 가져야 함.

속성의 구성

• 속성명 : 명확하고 의미있는 단수 명사(구)로 부여 
• 도메인 : 허용값, 기본값, 데이터타입을 지칭
• 선택성 : Not null 제약여부

속성과 관련된 내용

• 속성은 고유한 것, 가공되지 않은 것, 독립적인 것.
• 속성은 해당 속성의 도메인이 모여서 만들어진 집합.
• 관계도 속성으로 나타날 수 있다. → [4-2-5] 병렬 관계 형태 참조.
• 속성들 간은 서로 독립적이어야 한다. → 정규화와 관련.

02. 속성 도출 및 검증

다양한 후보를 도출한 뒤, 

기준에 맞는 속성만 골라낸다.

수집처

• 구 시스템의 문서 자료
• 타 시스템의 문서 자료
• 현업 장표/보고서
• 사용자와의 협의 → 이상적인 방법
• 자료 흐름도(DFD)의 데이터 사전(DD)
• 전문 서적 및 자료

선정 원칙

• 원시(기본, 고유) 속성으로 보이는 후보는 버리지 않는다.
• 소그룹별로 후보군(Pool)을 만들고 가장 근접한 엔터티에 할당한다.

검증 기준

• 원자성 : 일단 최대한 분해하자, 통합은 나중에. 
• 단일성 : 여러값을 가지거나, 비슷한 속성이 반복되면 안된다. (1차 정규화 대상)
• 유도속성 : 다른 속성의 가공으로 만들어진 속성이면 충분히 검토하고 결정한다. 
• 근원속성 : 미래의 업무변화를 대비하기 위해 근본적인 속성에 대해 검토한다.

유도속성 (추출속성ㅡDerived Attribute) 규칙

• 유도속성은 기본속성의 가공으로 얻을 수 있으므로 중복성을 띔.
• 하지만, 관리자/사용자가 진실로 원하는 정보라면 가급적 추가할 것.
• 물리적 구현에 대한 어떤 것도 언급되지 말아야 한다.
• 기본키(주키ㅡPK)의 역할을 맡지 않아야 한다.

03. 속성명에 관련된 이슈

속성명은 명확하게 정의되어야 한다.

속성명은 어떠한 중의성도 없어야 한다

• 잘못 이해할 수 있을 가능성을 가진 속성명은 배제. 
• 모호한 속성명은 배제 → 유일한 복합명사 이름으로 부여. 
• 매우 추상적인 속성명 베재 → 전용 발생 (의도하지 않은 다른 엔터티에도 사용할 수 있는 경우)

잘못 설계된 속성명의 예시

• 학점 → 성적으로서 학점? 이수시간단위의 학점?
• 상태 → 어떤 상태?

전용이 발생하는 경우

• 모델러가 매우 추상화된 속성명을 사용 → 개발자가 각기 다르게 이해함
• 개발 막바지에 새로운 요구사항이 들어왔을 때
• 인위적으로 전용의 속성을 정의해두는 경우.