본문 바로가기

데이터 Story/데이터 상념(想念)

[worst practice 1] 잘못 설계된 모델

잘못 설계한 사례 모델을 간혹 올릴 생각입니다.

궁금하신 점이나 다른 아이디어 있으면 댓글로 남겨주세요.

 

--

 

요건은 아래와 같습니다.

 

-회원은 주민등록번호 별로 한 번만 가입이 가능하다.

-회원은 고유한 회원아이디가 있으며, 한 회원이 여러 개의 회원아이디를 가질 수 있다.

 

[그림 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