실질식별자가 있는데도 불구하고 인조식별자를 사용하는 경우네요.
인조식별자는 식별자의 항목이 많을 때 상속이 어려워 사용하기도 하고
특별히 식별자로 잡을만한게 없어서 쓰기도 하는데요.
자료 조회시 불필요한 조인이 발생한다는 단점도 있겠구요.
장단점이 존재합니다. 장점과 단점 사이에서 줄다리기를 해야 하는데요.
위의 경우엔 인조식별자가 필요한 이유를 모르겠네요.
장점이 전혀 보이질 않네요.

사용자ID 나 부서코드가 변경되는 구조면 인조식별자가 필요하겠네요..

마농님 질문의 바꿔서 다시 문의 드리겠습니다.

위의 샘플에 부모키가 하나라서 UK대신 PK로 하라는 말씀 알겠습니다.

사실 위와 같이 한 이유는 사용자ID를 바꿔 달라고 하는경우 연결된 모든 테이블에 값을 바꾸거나 지워야 하는 문제 때문에 위와 같이 잡아 보려고 했습니다.

그리고 만약 부모테이블에 집합키가 여러개가 필요할 경우 때문에 인조식별자 잡고 집합키를 유니크로 잡으려고 했습니다. PK가 하나지만 가급적이면 동일한 구조로 가려고 했었거든요.

일단 내용을 바꿔서 테이블 모양을 잡자면 아래 처럼 될것 같은데... 부서테이블에 PK가 여러개 필요할 경우 인조키 만들고 유니크로 가야 되나요? 아님 그냥 PK를 아래 처럼 해도 될까요?

==  인조 식별자  ==
○ 사용 조건
 - 후보 식별자 중 주 식별자로 선정할 만 한 게 없을 때
 - 후보 식별자 속성 조합이 지나치게 복잡할 때
 - 실체/자립 엔티티에서 사용
○ 주로 "~코드" / "~번호" 등의 무의미한 번호가 사용됨
 - ~코드 라는 명은 공통코드 속성과 혼동되므로 권장하지 않음
○ 인조 식별자 고려 단계
 - 주요 엔티티는 개념모델 단계에서
 - 일반 엔티티는 논리모델 단계에서
○ 인조 식별자 사용 시 장점은
 - 모델이나 SQL 이 간단해 지는것
○ 인조 식별자 사용 시 단점은
 - 인스턴스 생성 기준을 인조(주) 식별자만으로 판단하기 어렵다
 - 실제 업무 식별자에 유니크 인덱스를 사용하여 추가 키 관리를 해야 한다
 - 모델만 보고 업무를 이해하기 어렵다
 - 특히 행위 엔티티에 인조 식별자 사용 시 가독성이 많이 저하된다
○ 참조 : http://wiki.gurubee.net/pages/viewpage.action?pageId=28115827

== 주 식별자로 인조 식별자 선택 시 특성 및 주의사항 ==
○ 데이터를 일반화 할 수록 인조 식별자를 사용하게 되는 경향이 있다
 - 인조 식별자는 확장성이 좋으므로 통합(일반화) 모델 엔티티에서 자주 사용된다
 - 실체/자립 엔티티에서도 인조 식별자가 주로 사용된다
○ 업무 식별자(후보 식별자)는 대체 식별자가 되므로 반드시 유니크 인덱스를 생성해야 한다
 - 인스턴스 중복을 방지 목적
 - 데이터 발생의 기준이 되는 업무 식별자는 특히 유니크 인덱스 설정이 필수적이다
○ 참조 : http://wiki.gurubee.net/pages/viewpage.action?pageId=28115841

기준은 업무식별자로 삼고 난 뒤에

인조식별자를 사용해도 되는지 검토해서 일부만 사용하는 것이 맞지 않나요?

기준을 인조로 잡고 일괄 적용하는 것은 아닌것 같습니다.

케바케(케이스 바이 케이스)죠.
이럴땐 이게 좋고 저럴땐 저게 좋고...
일반적인 장,단점은 위에 적은대로구요...
테이블간의 관계가 복잡해지면 그에 따른 조회 성능까지도 생각하셔야 하구요.
이게 좋다 저게 좋다 단정지을 수 있는게 아니죠.