[worst practice 2]

요건이 아래와 같습니다.

 

-고객이 발급 받아서 사용하는 보안카드를 관리한다.

-폐기한 보안카드 데이터를 관리하는데, 일자별로 폐기된 보안카드를 조회할 수 있도록 관리한다.

 

이 요건을 아래와 같이 설계했습니다.

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

 

[그림 1]

 

--

 

고객보안카드페기 엔터티의 주 식별자가 잘못됐습니다.

쉽게 찾으셨을 거 같아요.

 

하나의 보안카드가 여러 번 폐기될 때 [그림 1] 고객보안카드페기 엔터티와 같이 설계할 수 있습니다.

발급된 보안카드는 한 번 폐기되면 끝이기 때문에 [그림 2]와 같이 설계해야 적절합니다.

 

[그림 2]

 

일자별로 폐기된 보안카드를 조회한다는 이유 때문에 폐기일자 속성이 주 식별자에 포함된 사례로, 역시 슈퍼 식별자입니다.

폐기일자+보안카드번호는 인덱스를 나타내죠.

 

[그림 2] 정도도 좋지만, 고객보안카드폐기 엔터티 명은 행위를 나타내는 반면에, 데이터 성격은 보안카드라는 실체를 나타내기 때문에 [그림 3]이 더 명확할 거 같습니다.

 

[그림 3]

 

덧붙이면, 고객보안카드 엔터티에 보안카드상태구분코드 속성이 필요해 보이고, 폐기사유구분코드 속성 명은 일반적이라서 보안카드페기사유구분코드 정도가 명확합니다. 이 부분을 지적하셨다면 매우 치밀하신 것입니다.

 

코드 속성 명은 매우 신경써야 합니다.

코드 인스턴스가 있기 때문에 구체적이어야 오너십도 분명해지고 제대로 사용할 수 있습니다.

 

폐기일자 속성은, 그 정도로 충분하다고 생각합니다.

구체적으로 정해도 좋고요.

 

정제된 모델은 [그림 4]와 같습니다.

 

[그림 4]

 

마지막으로, 폐기에 대한 요건이 많지 않거나 폐기에 대한 속성이 별로 없다면, [그림 5]와 같이 설계해도 됩니다.

 

[그림 5]

 

요건이 자세하진 않지만, [그림 5]처럼 설계하셨다면 데이터 성격을 명확히 파악하신 것입니다.

원래는 하나의 데이터인데, 필요에 의해 일대일(1:1)로 분리해서 [그림 4]와 같이 되는 것이니까요.