worst practice

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

 

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

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

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

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

 

위 요건을 설계한 모델이 [그림 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]처럼 일반 속성이 식별자에 포함된 것을 슈퍼 식별자라고 합니다.

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

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

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