태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'워스트 프랙티스'에 해당되는 글 2건

이번 요건은 다소 까다롭습니다.

 

-한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.

-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.

-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.

-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다.

 

위 요건을 설계한 모델이 [그림 1]입니다.

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

 

[그림 1]

 

역할유형코드의 인스턴스는 관리사원, 실적사원입니다.

 

--

 

식별자밖에 없으니 식별자에 대한 문제죠.

 

우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다.

 

그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 역할유형코드 속성이 식별자에서 제외됩니다.

 

따라서 정제된 모델은 [그림 2]와 같습니다.

 

[그림 2]

 

릴레이션은 아래와 같습니다.

 

[계좌역할사원]

#계좌번호

#사원번호

역할유형코드

역할지정일자

10001

500(홍길동)

관리사원

2045-01-01

10001

100(강길동)

실적사원

2045-01-01

40001

100(강길동)

관리사원

2045-03-31

80001

500(홍길동)

관리사원

2045-05-01

80001

300(이길동)

실적사원

2045-05-01

50001

500(홍길동)

실적사원

2045-05-31

 [그림 3]

 

항상 사례 데이터를 만들어서 요건을 확인해 보시길 바랍니다.

설계할 때부터 그렇게 하는 게 좋습니다.

특히 기준 정보, 관계 정보, 기본 정보 등의 데이터는 필수라고 생각합니다.

 

코드 속성이 식별자에 포함될 때는 주의해야 합니다.

코드 속성이 식별자에 포함된다는 것은, 코드 별로 관리하려는 대상이 여러 개라는 것을 의미하죠.

 

[그림 3]을 예로 들면, ‘10001’번 계좌에 대해서 관리 사원이 홍길동강길동이 될 수 있거나, ‘홍길동이 관리 사원과 실적 사원이 동시에 될 수 있을 때 역할유형코드 속성이 식별자에 포함됩니다.

 

위의 요건 중 첫 번째, 두 번째 요건은 관계비(까마귀발)를 나타냅니다.

즉 첫 번째 요건은 해당 엔터티와 계좌 엔터티에 대한 관계비를 나타내고, 두 번째 요건은 해당 엔터티와 사원 엔터티의 관계비를 나타냅니다.

 

세 번째 요건은 관계가 없으니 관계비와는 무관하고, 해당 엔터티에서의 식별자와 연관됩니다.

네 번째도 마찬가지로 해당 엔터티에서의 식별자와 연관됩니다.

 

위와 같이 요건 중에는 관계비를 의미하는 게 있고요. 관계 속성이죠.

일반 속성을 의미하며 식별자와 연관되는 요건이 있습니다.

둘을 구분하면 주 식별자 설계에 도움이 됩니다.

관계비가 일대다라고 꼭 식별자에 포함되는 것은 아닙니다.

 

두 개념이 복잡하게 엮인 요건은 주 식별자 설계가 까다롭습니다.

인터뷰 시에도 담당자가 정확히 설명하지 못할 수 있습니다.

사례 데이터를 만들어 보면서 많이 연습하는 게 중요합니다.


참고로 [그림 1]처럼 일반 속성이 식별자에 포함된 것을 슈퍼 식별자라고 합니다.

이미 식별이 되는데 다른 속성을 추가했으니 식별자 역할은 합니다.

슈퍼 식별자면 요건 자체도 흔들릴 수 있고, 데이터가 잘못 쌓이면 요건이 망가집니다.

데이터 무결성을 저해하는 가장 심한 것 중의 하나가 슈퍼 식별자입니다.

 

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

데이터 아키텍트 프레임웍  (0) 2018.03.31
[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
블로그 이미지

블루퍼필

댓글을 달아 주세요

요건이 아래와 같습니다.

 

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

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

 

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

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

 

[그림 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  댓글주소  수정/삭제  댓글쓰기

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