엔티티 복합속성 다가속성

 

 

복합속성 다가속성

복합 속성은 전화번호 속성과 같이 두 개 이상의 세부 속성으로 구성된 속성입니다.

다가 속성은 유사한 성격의 값을 복수로 갖는 성격의 속성입니다.

 

전화번호라는 속성은 국번화 번호 등으로 나누어질 수 있으며 고객주소는 시, 구, 동 등으로 상세히 분해해서 관리가 가능합니다. 이렇게 하나의 속성이 여러 의미를 가지며 독립적으로 존재할 수 있는 두 개 이상의 속성으로 나누어 질 수 있는 속성을 복합 속성이라 합니다.

 

복합 속성은 여러 개 개별 속성으로 나눠 별도 관리하는 것이 원칙이지만 필요에 따라 분해하지 않고 하나의 속성으로 관리하는 것이 효율적이기도 합니다.

 

업무에 따라 판단이 달라질 수 있습니다. 만약 통신 업체라면 휴대전화번호를 상세하게 세 개로 분해해서 관리할 수 있습니다. 하지만 대부분 업무에서는 휴대전화번호를 하나의 속성으로 관리하는 것이 효율적입니다.

 

분해해서 개별로 관리하면 오히려 휴대번호 조회 시 붙여서 조회하는 불편함이나 인덱스 문제 등이 발생할 수 있습니다. 

 

복합 속성은 분해하는 것이 원칙인데 복합 속성으로 관리할지 개별 속성으로 관리할지에 대한 판단 기준 중의 하나는 개별적인 의미로 조화가 이루어지는가 입니다. 만약 국번이나 지역번호로 조회되지 않으면 전화번호는 하나로 관리하는 것이 효율적입니다. 개별적인 의미로 조회된다는 것은 개별적인 속성으로 업데이트 될 수 있고 정렬이나 그룹화될 수 있다는 것을 의미합니다.

 

간혹 속성 값을 비트로 관리할 때가 있습니다. 각 비트가 의미하는 것이 하나의 의미를 뜻하는 값이라면 다가 속성이 되면 전혀 다른 의미를 관리하는 것이라면 복합 속성이 됩니다. 비트 형식의 속성은 사용하지 않아야 합니다. 여러 개의 여부 속성을 추가해 관리하거나 일대다 엔티티를 추가해 정규형을 사용해야 합니다.

 

복합 속성과 유사한 속성이 인조 식별자 성격의 속성입니다. 계좌번호나 계약번호 속성 값에 지점코드가 포함돼 있다면 복합 속성과 유사합니다. 인조 식별자를 체계화해 의미를 부여해 관리할 이유가 없다면 중복 방지를 위해서라도 인조 식별자에 여러 의미를 포함해 사용하지 않는 것이 좋습니다.

 

또한 코드 속성에 여러 의미가 있는 코드값을 사용하는 것도 복합 속성의 일종입니다. 코드값, 코드명이 한 종류를 의미하는 것이 아니기 때문에 여러 의미가 혼합돼 있을 때는 두 개의 코드 속성으로 분해해야 합니다.

 

다가 속성은 한 속성에 유사한 종류의 여러 값이 존재하는 속성입니다. 단일 값 속성은 하나의 값만 존재하는 속성입니다. 고객 엔티티의 주민등록번호 속성은 하나의 값만 갖습니다. 이력 데이터를 제외하고 주민번호가 두 개 이상인 사람은 없습니다. 

 

개념 모델링이나 초기 논리 모델링 단계에서 많은 속성으로 모델이 복잡하게 보이는 것을 피하기 위해 다가 속성을 사용하기도 합니다. 모델은 고객 데이터를 관리하는 엔티티로 아직 속성이 구체화 되기 전 모델링 과정이며 전화번호, 우편번호, 취미, 가족 속성이 다가 속성입니다.

 

다가 복합 속성이 사용된 엔티티

고객 테이블 - 고객번호 (PK) / 주민번호 / 고객성명 / 전화번호 / 우편주소 / 취미 / 가족

 

고객 엔티티는 모델링이 진행되면 아래와 같은 모델이 됩니다.

고객 테이블 - 고객번호 (PK) / 주민번호 / 고객성명 / 자택 전화번호 / 직장 전화번호 / 휴대전화번호 / 팩스번호 / 자택 우편주소 / 직장 우편주소

고객취미 테이블 - 고객번호 (FK) / 취미 코드

고객가족 테이블 - 고객번호 (FK) / 주민번호 / 가족성명

 

고객의 전화번호는 여러개 존재할 수 있고 집, 직장, 휴대폰, 팩스 등과 같이 여러 종류의 전화번호 관리가 필요할 수 있습니다. 우편주소도 집, 직장 주소를 관리할 수 있습니다. 전화번호와 우편주소는 고정돼 있어 관리 대상이 더 늘지 않는다고 가정하고 속성으로 추가한 반면 취미와 가족은 몇 가지 종류가 있을 수 있어, 속성의 개수가 고정돼 있지 않아 1 정규화를 수행한 모델입니다.

 

다가 속성은 1정규형과 관계가 밀접합니다. 모델링 과정에서 다가 속성이 발생하면 속성을 추가할지 1정규화를 할 지 결정해야 합니다.

속성이 고정된 종류의 값을 가지고 있어 분리해야 할 속성의 개수가 한정됐는지가 1정규화 선택 기본 기준이 됩니다. 분리해야할 속성 개수가 유동적이라면 고객취미, 고객가족 엔티티 처럼 1 정규화를 진행해야 합니다.

물리적으로 하나의 값을 갖는데 의미상 여러 종류 값을 의미하는 경우도 있습니다. 고객전화번호라는 속성을 사용하고 값은 집 전화번호나 사무실 전화번호 등을 같이 관리하는 것으로 하나의 값을 사용하지만 다가 속성과 유사해 바람직하지 않습니다.

이런 종류의 속성은 상세하게 정의되면 발생하지 않을 것입니다. 데이터를 관리하는 상세 수준에 따라 달라질 수는 있지만 하나의 속성에 여러 의미가 존재할 수 있도록 속성을 정의하면 좋지 않습니다. 

금액도 유사합니다. 한 엔티티에 속해 있는 속성이 금액, 금액2, 금액3 으로 사용될 때도 있습니다. 최초에 의미를 명확하게 부여했다면 이후 추가되는 유사 속성들도 의미가 명확해질 것입니다,