태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'슈퍼 식별자'에 해당되는 글 1건

요건이 아래와 같습니다.

 

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

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

 

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

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

 

[그림 1]

 

--

 

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

쉽게 찾으셨을 거 같아요.

 

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

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

 

[그림 2]

 

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

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

 

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

 

[그림 3]

 

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

 

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

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

 

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

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

 

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

 

[그림 4]

 

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

 

[그림 5]

 

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

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



'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
DA 전망  (0) 2017.09.23
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • jack 2017.11.09 16:19  댓글주소  수정/삭제  댓글쓰기

    기창님 매번 좋은 글 올려 주셔서 감사합니다.
    모델링 노트, 일이 막힐 때마다 찾아서 읽고 있습니다.
    다름 아니라 게시글에 한 가지 궁금한 점이 있어서 그런데요..
    보안카드상태구분코드 속성은 없어도 되지 않을까요? 폐기일자 속성이 null이 아닐 경우 폐기됐다라고 간주함 충분할 거 같습니다.

    • 블루퍼필 2017.11.11 19:41 신고  댓글주소  수정/삭제

      예.. 맞습니다.
      폐기 여부는 말씀하신대로 하면 판단 가능해서 굳이 상태구분코드가 필요 없는데요.
      요건이 복잡해지면 정상, 정지, 폐지 등으로 늘어날 수 있고.. 집계에 사용될 수도 있고..
      아시다시피 요건에 따라 달라지겠네요.
      예제 모델에서는 굳이 필요 없습니다. ㅎ
      의견 감사합니다.

  • jack 2017.11.15 15:58  댓글주소  수정/삭제  댓글쓰기

    며칠 동안 고민했는데 말씀주신거처럼 요건이 복잡해지면 구분코드가 필요하겠네요^^