04. 속성 이야기 (2)

속성 종류

• 기초 속성
• 관계 속성
• 추출 속성
• 시스템 속성

 

기초 속성

엔터티의 본질을 설명하는 속성

• 엔터티에 반드시 존재해야 하는 업무 식별자와 후보 식별자, 엔터티의 특성을 설명하는 속성 등이 이에 해당한다.
• 오너십 중에 엔터티가 어느 주제 영역(ERD)에 속해야 하는지에 대한 오너십이 모델 오너십이며, 모델 오너십을 정하는 기준이 기초 속성이다.
• 기초 속성은 주로 논리 모델링 초반에 도출된다.

 

관계 속성

관계 속성은 타 엔터티와의 관계를 알기 위해 사용하는 외래 식별자 속성이다.

• 관계 속성은 두 가지로 나눌 수 있다.
  • 참조되는 엔터티와 존재 종속 관계면 관계 속성은 엔터티의 본질을 의미하므로 기초 속성이기도 하다.
  • 엔터티 간 관계가 존재 종속 관계가 아니로 단지 참조만 하는 관계라면 관계 속성은 기초 속성이 아니다.
• 관계 속성은 참조되는 엔터티의 주 식별자 속성이다. 따라서 관계 속성은 대부분 핵심 속성이다.

 

추출 속성

추출 속성은 이미 존재하는 속성으로 재생할 수 있는 속성이다. 이미 존재하는 속성이 원본 속성이다.

• 추출 속성은 기존에 존재하는 원본 속성의 값을 연산해서 생성(재현)할 수 있는 속성이다.
• 반드시 원본 속성이 존재해야 추출 속성도 존재하므로 추출 속성은 원본 속성에 종속돼 있다.
• 모든 속성은 원본 속성 아니면 추출 속성으로 나눌 수 있다.
• 추출 속성을 사용하는 가장 큰 목적은 데이터 조회 시간을 단축하기 위함이다.
• 추출 속성의 문제점은 정합성이 저하될 수 있다는 것이다. 추출 속성은 데이터 정합성을 실시간으로 맞춰야 한다.
• 추출 속성을 주 식별자로 사용하면 안 된다.
• 추출 속성은 다른 속성 값에서 재현할 수 있는 속성인데, 만약 재현할 수 없다면 추출 속성이 아니다.
• 추출 속성은 데이터 정합성 문제 때문에 사용하지 않는 것이 원칙이다. 추출 속성을 사용했다면 원본 속성의 관리가 더욱 중요하다.

 

시스템 속성

시스템 속성은 데이터(인스턴스)에 대한 추적, 감시를 위해 사용하는 속성이다. 해당 인스턴스를 누가 생성하고 언제 생성했는지, 누가 언제 수정했는지를 관리하는 속성이다.

• 시스템 속성은 일반적으로 전체 엔터티에 존재하며, 엔터티마다 다른 의미로 사용하는 것이 아니고 같은 목적으로 사용한다.
• 시스템 속서으이 개수는 가능한 적어야 좋다. 데이터 추적을 정밀하게 하려고 많은 속성을 사용하면 모델 관리가 불편해지며, 성능에도 악영향을 끼친다.
• 시스템 속성은 데이터를 추적할 수 있는 용도로만 사용하는 것이 바람직하다. 시스템 속성에 업무적인 의미를 부여해 업무적으로 사용하지 안흔ㄴ 것이 좋다.
• 시스템 속성은 모든 엔터티에 추가하는 것이 원칙이지만, 성능을 최적화해야 하는 엔터티에서는 삭제할 수도 있다.
• 시스템 속성은 엔터티의 제일 하단에 위치하는데, 시스템 속성을 추가한 상태에서 다른 속성이 추가될 수 있다. 이때 만약 데이터베이스에 테이블로 생성되기 전이라면 추가되는 속성을 시스템 속성 위로 위치시켜야 한다.
• 시스템 속성은 데이터베이스에 생성하기 바로 직전에 ERD에 추가하는 것이 바람직한 반면, 시스템 속성 선정은 가능한 빨리 하는 것이 좋다.

 

중복 속성

중복 속성은 추출 속성과 함께 주의해야 할 속성이다. 넓은 의미에서 중복 속성도 추출 속성에 속한다.

• 중복 속성을 제거하는 것이 관계형 데이터 모델링의 중요한 목적 중 하나다.
• 추출 속성은 때에 따라 효과적이어서 사용할 여지가 있는 반면, 중복 속성을 사용하면 얻는 것에 비해 잃는 것이 크다. 

 

시점 데이터가 중복 속성이다?

모델링할 때 중복 속성처럼 보이지만 주의해야 할 속성이 있다. 데이터가 발생항 시점의 값을 관리하는 속성은 주의해야 한다.

데이터가 발생한 시점의 값을 보관하고자 하는 속성은 중복 속성이라고 볼 수 없다.

 

 

중복 속성을 사용할 수 있는 경우

• 데이터 정합성 문제가 최소화되면 중복 속성을 사용할 수 있다. 즉 값이 변하지 않는 속성은 중복 속성으로 사용할 수 있다.
• 만약 값이 변경될 가능성이 아주 낮은 속성이 있다면, 하위(자식) 엔터티에 중복 속성으로 사용해도 부작용이 줄어든다.
• 데이터 정합성을 맞춰야 하는 대상이 적은 경우도 중복 속성을 사용할 때의 부작용을 최소화할 수 있다.
• 엔터티 간의 관계가 참조 관계일 때보다는 종속 관계일 때가 비교적 중복 속성을 채택하기 적당하다.

 

단일 값 속성과 다가 속성

단일값 속성: 한 시점에 하나의 값만을 가지는 속성

다가 속성: 유사한 성격의 값을 복수로 가지고 있는 속성

• 한 속성에 여러 개의 취미를 '100,101,102'와 같은 형태로 관리하는 것
• 비트값을 사용해 값의 자릿수에 미리 의미를 부여해서 한 바이트가 하나의 값을 의미하도록 하는 것(ex. 110 → 첫 번째 값은 true, 두 번째 값은 true, 세 번째 값은 false)
• 코드 속성에 여러 개의 코드 값을 저장해 사용하기도 한다.(ex. '1352' 자릿수마다 하나의 의미를 부여해 사용)

다가 속성은 모델링하는 과정에서는 발생할 수 있다. 하지만 최종 물리 모델에서 다가 속성이 존재하면 일반적으로 잘못된 모델이다. 최종 물리 모델에서는 여러 개의 속성으로 분해하든지, 별도의 1정규형 엔터티로 분리해야 한다.

 

 

단순 속성과 복합 속성

단순 속성: 일반적인 정상 속성(aka 원자 속성)

복합 속성: 여러 의미를 가지는 속성 → 두 개 이상의 의미 있는 단순 속성으로 분해할 수 있는 속성

• 다가 속성과 유사하지만, 다가 속성은 각 자리가 의미하는 바가 동일하고, 복합 속성은 각 자리가 의미하는 바가 다르다.
• 복합 속성은 이론적으로 잘못 설계된 속성이어서 여러 개의 개별 속성으로 나누는 것이 원칙이다. 하지만 업무에 따라서 복합 속성이 더욱 효율적일 때가 있다.
• 복합 속성을 그대로 사용할지, 여러 개의 개별 속성으로 분해할지에 대한 판단 기준은 개별적인 의미로 조회되는지다. 개별적인 의미로 조회된다는 것은 개별적인 속성으로 업데이트될 수 있고, 정렬이나 그룹화될 수도 있다는 것을 의미한다. 이를 복합 속성으로 관리하면 매우 불편하고 비효율이 발생할 것이다.
• 다가 속성과 마찬가지로 복합 속성도 1정규화의 대상이다.

 

필수 속성과 선택 속성

필수 속성: 값이 반드시 필요한 속성

선택 속성: 값이 없을 수 있는 속성

• 필수 속성에는 NOT NULL 제약을 생성해야 하며, 필요 시 Default 제약을 생성해야 한다.
• 필수 속성은 NULL 값을 허용하지 않는 속성이다. 이를 두 가지로 나눌 수 있다.
  • NULL을 논리적으로 허용하지 않는 것: 일반적인 필수 속성
  • NULL을 물리적으로 허용하지 않는 것: 기본값(Default)이 지정된 속성을 의미. 논리적으로는 널을 허용하지만, 여러 이유 때문에 NOT NULL로 설정한 후 기본값을 지정한 속성.(사실상 필수 속성은 아님)

 

배타 속성

배타 속성: 여러 속성에 저장된 값들이 상호 배타적일 때, 또는 한 속성에 저장된 값이 어떤 기준에 대하여 서로 배타적일 때 이 속성을 배타 속성이라 한다.

• 만약 하나의 인스턴스에 대해서 배타 속성에 값이 모두 존재하면 데이터 무결성이 깨진 상태가 되기 때문에 주의해야 한다.
• 하나의 속성이 배타 속성이라면, 배타 속성 명은 일반화시켜야 한다. (ex. 입고와 출고 일자 → 입출일자)

 

코드 속성과 비코드 속성

코드 속성: 사전에 약속한 값인 코드 값이 사용된 속성

비코드 속성: 코드 속성이 아닌 일반 속성

• 예전에는 대부분 코드 값을 보고 의미를 짐작할 수 있도록 사용했지만(ex. KOR), 최근에는 굳이 코드 값을 보고 의미를 알 필요가 없기 때문에 '01' 등을 코드로 사용한다.
• 모드 속성에는 이미 정해 놓은 값이 사용된다. 따라서 그 값만 봐서는 의미를 알 수 없다. 물리적인 값으로서 논리적인 의미가 없는 값이다.
• 비코드 속성에는 실제 값이 저장된다. 그 값을 보고 의미를 파악해야 한다. 의미 파악이 안 되는 값이ㅏㄹ면 데이터 자체가 잘못됐거나 관계 속성일 때다.

 

일반 코드와 식별자 코드

코드 속성과 식별자 속성을 잘 구분해야 한다.

식별자 코드: 엔터티의 주 식별자이면서 속성 이름이 '~코드'로 끝나는 속성(ex. 부서코드, 지즘코드, 사원코드, 상품코드 등)

 

식별자 코드의 특징

• 식별자 코드를 주 식별자로 하는 독립된 엔터티가 존재한다.
• '-코드' 대신 '-번호'로 사용해도 된다.
• 식별자 코드 자체가 하나의 인스턴스를 의미하며, 하나의 실체를 의미한다.

 

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

일반 코드와 식별자 코드는 내부와 외부 데이터로 구분할 수 있다.

1. 일반 코드이면서 내부 데이터
   • 일반 코드이면서 내부 데이터는 코드 엔터티에서 통합 관리하는 것이 좋다. 이때 코드 값은 전사 표준에 의해서 정한다.
2. 일반 코드이면서 외부 데이터
   • 외부 기관과 데이터를 주고받을 때, 외부 기관에서 정한 코드 값이 데이터에 포함될 수 있다. 이 코드 값은 내부에서 정한 코드 값이 아니기 때문에 전사 표준을 따르지 않는 값이다.
3. 식별자 코드이면서 내부 데이터
   • 내부 식별자 코드는 일반 ㅇ네터티에서 관리하기 때문에 관리와 사용 측면에서 특별한 문제가 없다.
4. 식별자 코드이면서 외부 데이터
   • 만약 외부에서 받은 값만 보관한다면, 식별자 코드에 대한 명(설명)을 관리할 필요는 없다. 하지만 식별자 코드와 함께 명을 사용한다면 이를 별도의 엔터티에서 관리해야 하는데, 이 데이터 역시 외부에서 받아야 한다.

 

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

간혹 일반 코드가 식별자 코드가 될 떄가 있다. 공통 코드 엔터티에서 코드 값과 코드 명을 관리하다가 별도로 관리할 속성이 생겨서 새로운 엔터티로 생성해야 할 때가 있다. 반대의 경우, 즉 일반 엔터티에서 관리하던 값을 공통 코드 엔터티에서 관리하는 경우는 흔치 않다.

 

 

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

코드와 엔터티를 구분할 때 생각해야 할 것

1. 데이터 집합의 인스턴스가 개별 개체를 의미하는지
   • 하나의 인스턴스가 개별 개체를 의미하면 엔터티로 도출하는 것이 기본적인 원칙이다.
     • 예를 들어 국가 집합에 속한 인스턴스가 대한민국, 호주, 영국 등이라면 각각은 개별 개체를 의미하기 때문에 기본적으로 엔터티에서 관리해야 한다. 반면에 어떤 집합이 아시아, 유럽, 오세아니아 등이라면 개별 개체라고 볼 수 없다. 개별 개체를 묶은 개념이다. 이때는 엔터티로 관리하는 게 아니라 코드로 관리해야 한다.
2. 그 인스턴스가 이름 외의 특성(속성)이 있는지
   
   • 인스턴스 성격상 여러 고유 특성이 존재하거나, 현재는 관리하지 않더라도 향후에 관리될 속성이 생길 수 있다면 엔터티로 관리해야 한다.
   • 따라서 개별 개체를 묶은 개념이라도 고유 속성이 필요하다면 엔터티로 설계해야 한다.

엔터티로 관리해야 할 데이터를 코드로 관리하면 추후에 문제가 발생할 수 있다. 이런 문제를 사전에 방지할 수 있는 것은 애초에 데이터 성격에 맞게 엔터티를 도출하는 것이다. 데이터가 실제의 개체를 의미하는지, 개체의 묶음을 의미하는지에 따라 판단하면 무난하다.