잘못 설계한 사례 모델을 간혹 올릴 생각입니다.
궁금하신 점이나 다른 아이디어 있으면 댓글로 남겨주세요.
--
요건은 아래와 같습니다.
-회원은 주민등록번호 별로 한 번만 가입이 가능하다.
-회원은 고유한 회원아이디가 있으며, 한 회원이 여러 개의 회원아이디를 가질 수 있다.
[그림 1]은 위의 요건을 설계한 모델입니다.
[그림 1]
어디가 잘못 설계됐는지 잠깐 생각해 보세요.
그런데 모델이 너무 간단해서 잘못될 부분이 한 군데 밖에는 없네요. ㅎ
잘못된 부분은 답글에 올렸습니다.
답글 보시기 전에 많이 생각해 보세요.
--
회원아이디 엔터티의 주 식별자가 잘못 설계됐습니다.
회원아이디 속성 값이 고유하기 때문에 회원아이디 엔터티의 주 식별자는 [그림 2]와 같이 회원아이디 단독 속성이어야 합니다.
[그림 2]
회원이 아이디를 여러 개 가질 수 있어서 [그림 1]처럼 설계됐고요.
인덱스를 생각하다 설계하면 [그림 1]과 같이 될 거 같습니다.
이미 식별자 역할을 하는 주 식별자에 다른 속성을 추가해서 만든 것을 슈퍼 식별자라고 합니다.
실무에서 슈퍼 식별자는 광범위하게 사용되는데 찾기가 쉽지 않다는 게 또 다른 문제입니다.
업무 식별자를 충실하게 분석하는 방법 밖에 없습니다.
슈퍼 식별자가 사용되면 엔터티 본질이 흐려지고요.
실제 업무 식별자가 중복 발생될 수 있습니다.
슈퍼 식별자가 하위 엔터티로 상속되면 위의 문제가 배가 되고요.
계속 상속될수록 모델은 난해해집니다.
모델을 이해할 수 없게 만드는 주범 중의 하나가 슈퍼 식별자로 절대로 사용하지 않아야 합니다.
'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글
[worst practice 2] (3) | 2017.09.30 |
---|---|
모델러의 상처 (0) | 2017.09.25 |
DA 전망 (0) | 2017.09.23 |
모델링을 수행하는 주체는? (0) | 2017.09.17 |
업무를 모르면 모델링을 할 수 있을까요? (0) | 2017.09.02 |