세 번째로 속성에 대해 알아보자
속성의 개념
- 사전적 의미
: 사물의 성질, 특징 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것으로 정의할 수 있다.
- 데이터 모델링 관점에서의 의미
: 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
속성의 정의를 정리해 보면 다음과 같다.
- 업무에서 필요로 한다.
- 의미상 더 이상 분리되지 않는다.
- 엔터티를 설명하고 인스턴스의 구성요소가 된다.
엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법
1. 엔터티, 인스턴스, 속성, 속성값의 관계
- 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 한 개의 속성값을 갖는다.
2. 속성의 표기법
속성의 표기법은 엔터티 내에 이름을 포함하여 표현하면 된다.
속성의 특징
속성은 다음과 같은 특징을 가지고 있다. 만약 도출된 속성이 다음의 성질을 만족하지 못하면 적절하지 않을 확률이 높다.
- 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
- 정규화 이론에 근거하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
- 하나의 속성은 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.
속성의 분류
1. 속성의 특성에 따른 분류
- 기본 속성 (Basic Attribute)
: 업무로부터 추출한 모든 속성이 여기에 해당한다. 엔터티에 가장 일반적이고 많은 속성을 차지
주의해야 할 것은 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것이다. 이러한 경우도 속성의 값이 원래 속성을 나타내지 못하므로 기본속성이 되지 않는다.
- 설계 속성 (Designed Attribute)
: 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다.
일련변호와 같은 속성은 단일한 식별자를 부여하기 위해 모델에서 새로 정의하는 설계속성이다.
- 파생 속성 (Derived Attribute)
:다른 속성에 영향을 받아 발생하는 속성이다.
다른 속성에 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 할 점이 많으므로 가급적 파생속성을 적게 정의하는 것이 좋다.
2. 엔터티 구성방식에 따른 분류
- 엔터티를 식별할 수 있는 속성 => PK속성
- 다른 엔터티와의 관계에서 포함된 속성 => FK속성
- 엔터티에 포함되어있고 PK/FK에 포함되지 않은 속성 => 일반속성
또한 속성을 그 안에 세부 의미를 쪼갤수 있는지에 따라 단순형 혹은 복합형으로 분류가능할 수 있다.
- 복합속성
: 예를 들어 주소 속성은 시구동번지 같은 여러 세부 속성들로 구성 될수 있다.- 단순 속성
: 나이, 성별등의 속성은 더이상 다른 속성들로 구성될 수 없는 단순한 속성이다.
일반적으로 속성은 하나의 값을 가지고 있으나 그 안에 동일한 성질의 여러 개의 값이 나타나는 경우가 있는데 속성 하나에 한개의 값을 가지는 경우인 단일값속성과 여러개의 값을 가지는 경우인 다중값속성으로 나눌 수 있다.
- 단일값속성
:주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 단일값속성에 해당한다.- 다중값 속성
: 어떤 사람의 전화번호와 같은 속성은 집,휴대전화,회사 전화번호와 같이 여러개의 값을 가질수있으므로 다중값속성에 해당한다.
다중값속성의 경우 하나의 엔터티에 포함될수 없으므로 1차정규화를 하거나, 별도의 엔터티를 만들어 관계로 연결해야 한다.
도메인
- 각 속성은 가질 수 있는 값의 범위가 있는데 이를 그 속성의 도메인이라고 한다.
도메인을 좀 더 이해하기 쉽게 정리하면, 엔터티 내에서 속성에 대한 데이터타입과
크기•제약사항을 지정하는 것이다.
속성의 명명
-
속성 이름을 정확하게 부여하고 용어의 혼란을 없애기 위해 용어사전을 만들고 각 속성이 가지는 값의 종류와 범위를 명확하게 정리해놓은 도메인정의를 같이 사용하여 프로젝트를 진행할 경우 용어적 표준과 데이터타입의 일관성을 확보할 수 있게 된다.
-
속성명을 부여하는 원칙
- 해당 업무에서 사용하는 이름을 부여한다.
: 아무리 일반적인 용어라 할지라도 그 업무에서 사용되지 않으면 속성의 명칭으로 사용하지 않는 것이 좋다.
- 서술식 속성명은 사용하지 않는다.
: 수식어가 많으면 의미 파악이 힘들고, 상세 설계 단계에서 물리속성으로 전환하는 데 명확한 의미 파악이 어렵게 된다. 소유격도 사용하지 않도록 한다.
- 약어 사용은 가급적 제한한다.
: 지나치게 약어를 많이 사용하면 업무 분석자 내에서도 의사소통이 제약을 받으며, 시스템을 운영할 때도 많은 불편을 초래할 수 있다.
- 전체 데이터 모델에서 유일성을 확보하는 것이 좋다.
: 데이터에 대한 흐름을 파악하고 데이터의 정합성을 유지하는 데 큰 도움이 된다.
또한 반정규화를 적용할 때 속성명의 충돌을 해결하여 안정적으로 반정규화를 적용할 수 있게 된다.
참고자료: SQL전문가가이드, DATA-ON-AIR
