코드로 설계 or 엔터티로 설계

엔터티의 인스턴스가 개별 개체를 의미하면 코드 속성으로 설계하지 않고 엔터티로 설계한다. 개별 개체를 의미한다는 것은 묶이기 전, 변형되기 전의 순수 데이터를 의미한다.

 

예를 들어 국가 집합에 속한 인스턴스가 대한민국, 호주, 일본 등이라면 각각은 개별 개체를 의미하기 때문에 엔터티로 설계한다.

 

만약 외국인 고객을 관리하는 엔터티에서 해당 고객의 국적을 관리한다면 [그림1] 모델처럼 국가 엔터티를 별도로 설계하여 외국인고객 엔터티와 관계선을 표현한다.

 

[그림1]

 

위와 같이 개별 개체를 의미하는 국가를 엔터티로 설계해서 관리하지 않고, [그림2] 모델과 유사하게 국가 엔터티 없이 통합 코드 엔터티나 별도의 시스템에서 관리하는 국가코드 속성으로 설계하는 것은 바람직하지 않다.

 

[그림2]

 

국가 데이터는 데이터 성격 상 코드 성격이 아니기 때문에 현재는 국가명 밖에 관리하지 않는다고 하더라도 나중에 관리해야 할 속성이 다양하게 존재할 수 있다.

 

반면에 엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념을 의미한다면 코드 속성으로 설계해야 한다. 예를 들어 어떤 집합이 아시아, 유럽, 오세아니아 등이라면 데이터 성격 상 개별 개체라고 볼 수 없으며, 이는 어떤 개체를 묶은 개념이므로 엔터티로 관리하는 게 아니라 코드 속성으로 관리하는 것이 원칙이다.

 

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

 

만약 인스턴스 성격이 개별 실체를 의미하지만 관리하고자 하는 특성이 명(名)뿐이어서 코드 속성으로 관리할 수 있다. 하지만 이 경우라도 추후에 부가 속성이 생길 가능성이 조금이라도 있기 때문에 실체를 의미하면 엔터티로 설계하는 것이 원칙이다.

 

간혹 어떤 집합은 실체를 의미하지만 개체 전체를 관리하지 않을 수 있다. 즉 집합 인스턴스가 대한민국/중국/일본 등으로 동북아시아 국가만 관리하면서 명(名)만 관리한다면, 인스턴스가 개체를 의하지만 동북아시아국가코드 등의 코드로 관리할 수 있다.