[worst practice 4]

요건은 아래와 같습니다.

 

-부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.

-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다.

 

위의 요건을 설계한 모델이 아래와 같습니다.

잘못된 부분을 생각해 보세요.

 

 

[그림 1]

 

 

--

 

이력 데이터를 어떻게 설계할지에 대한 문제입니다.

 

이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다.

 

[그림 2]

 

실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다.

 

실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고 새로운 인스턴스로 생성하면 데이터 성격을 반영하지 못 한 것이라 하나의 인스턴스로 존재해야 하고요. 기본 정보나 기준 정보 또한 실체 성격을 포함하고 있기도 하고, 참조하기 좋아야 하기 때문에 그렇습니다.

 

행위 엔터티가 아닌데 일자 속성이 주 식별자에 존재하면 한번 더 고민하셔야 됩니다. 대개 이력 데이터를 포함시켜서 그렇게 되는데 바람직하지 않습니다.

 

쉽게 생각해서 참조되는 엔터티는 관계선을 표현할 수 있도록 설계해야 합니다. 조인해서 사용한다는 의미니까요. [그림 1]이라면 다른 엔터티와 조인해서 사용하기 매우 어려운 상태입니다. 약간씩 다르지만 [그림 3]도 역시 마찬가지로 모두 바람직하지 않습니다.

 

   

  

[그림 3]

 

일부 기본 정보를 관리하는 엔터티는 [그림 1]처럼 원천 데이터와 이력 데이터를 같이 관리할 수 있습니다. 굳이 나눠서 관리하면 엔터티 개수만 늘어나서 같이 관리할 수 있는데, 조인해서 사용하지 않을 때만 가능합니다.

 

[그림 4] 모델도 간혹 보는데, 많이 참조되는 주요 엔터티가 이렇게 설계되면 매우 난감해집니다. 어떻하든 사용은 가능하지만요.

 

[그림 4]