master table 이 없군요..  교수님이 저 많은 X 를 하신것은 기초 마스타테이블을 만들어서 해결할 수 있는 부분들이기 때문인것 같은데요..

주소나 학과의 경우 마스타 테이블을 두어 foreign key 로 연결하는것이 주소나 학과명등이 변경될때 훨씬 처리하기 쉬우니까요..

마스타테이블이 뭐죠?
논리모델링 단계에서는 적절치 않은 용어 인듯 싶습니다.

모델링 단계는 다음과 같습니다.

1.엔터티 수집 및 분류
2.엔터티 검증 및 확정
3.릴레이션 조사
4.릴레이션 정의
5.개념적 모델완성
6.속성 수집 및 확정
7.기본 논리적 모델
8.데이터 모델의 상세화
9.계층구조의 통합
10.엔터티 통합
11.관계의 통합
12.이력관리 확정

교수님이 X표를 해두신 내용을 보면...
관계가 엔터티로 표현되어 있거나, 관계가 속성으로 표현되어 있거나...
엔터티 인지 릴레이션인지 속성인지를 정확하게 판단해내지 못해서 X표를 한거 같습니다.
예를 들어
교수엔터티의 속성중에 소속학과라는 놈을 보면...
소속학과는 교수엔터티의 고유속성이 아닙니다.
님께서 엔터티로 만드신 학과 엔터티와의 관계입니다.
교수와 학과와의 "소속된다" 혹은 "구성된다" 라는 릴레이션이죠.
"소속학과"속성을 제거하시고 학과와의 관계를 맺어 주시면 됩니다.
속성 수집및 확정 단계에서 가장 실수를 범하는 부분이 릴레이션과 그 엔터티의 고유속성이 쉽게 구분이 가지 않는다는 점입니다.
마찬가지로 학생엔터티의 지도교수라는 속성또한 학생과 교수의 "지도한다"등의 관계이지 학생의 고유한 성질을 나타내는 속성은 아닙니다.
학과속성또한 마찬가지고요.
고로 이것 또한 제거 대상입니다.

또, 학과와 직원 엔터티의 교차엔터티로 만드신 "부속 및 부설기관"엔터티도 좀 문제가 있습니다만,
일단 그 속성들을 보면, 학생복지과, 산학협력과, 사무처 등등이 있습니다.
이렇게 속성으로 잡아 놓으신 것들은 "부설기관"이라는 집합을 구성하는 각각의 인스턴스(테이블로 맵핑시켰을경우 한건의 데이터, Row)이지, "부설기관"이라는 엔터티의 고유한 성질을 지닌 속성은 아닙니다.
부설기관이 계속 생기거나 개편되어 없어진다고 해서 계속 고유한 속성이 수시 때때로 변하는게 아니니까요.
물리적 단계에서 이렇게 테이블을 만드시면 부설기관이 늘어나거나 폐지되면 계속 칼럼을 생성하거나 Drop시켜야하는 말도 안되는 일이 벌어집니다. 더구나, 그 테이블을 엑세스 하는 모든 SQL 및 프로그램들을 다 수정해야 합니다.
따라서 부설기관코드 + 부설기관명칭 같이 보다 일반화, 추상화 시켜 그 엔터티의 고유한 성질을 대표할수 있는 속성을 잘 선정하셔야 합니다.

마지막으로 "부설기관"이라는, 직원과 학과 사이에 생성된 교차엔터티를 살펴보면...
교차엔터티가 생성되는 시점은 보통 키 혹은 메인 엔터티들간에 M:M릴레이션이 발견될때 입니다.
직원과 학과의 관계가 뭐가 있을까요?
"부설기관으로써"과 관계가 있긴 하겠지만 필연적인, 직접적인 관계라기 보다, 길가다 만난 사람과 나와 억지로 관계를 맺어 주는 그런 형태로 보입니다.
우리나라 사람 치고 관계가 없는 사람은 없습니다. 다 단군의 자손이니까요.
보통 릴레이션을 정의 할때는 1촌관계 즉, 직접적인 관계만 정의를 해줍니다.
부모와 자식의 관계만 정의할 뿐이지, 삼촌, 할아버지, 사촌관계는 정의해 주지 않습니다.
모든 혈연관계에서 "나"는 우리 부모님과의 필연적인 관계에서 태어날 뿐이지, 할아버지의 손자라서, 삼촌의 조카라서 태어나는건 아닌것과 같은 이치입니다.
부모/자식관계의 직접적 1촌관계가 모여서 2촌, 3촌관계가 형성되는 것입니다.

제 소견은 부설기관은 차라리 키엔터티에 가깝고, 나중에 해야할 단계의 일이지만,  학과, 부설기관은 학교를 구성하는 조직으로써 통합하는 것을 고려해볼수도 있을 것입니다. 엔터티통합을 하면서 자연스레 관계도 통합될것이니 간단명료하면서도 입체적이고 구체적인 데이터 모델을 완성하는 것입니다.
물론 무작정 무턱대고 이리저리 합치는건 절대 안됩니다. 이는 우리는 단군의 자손이니 다 부모자식으로 하자는 논리와 같습니다.

정리하자면 직원과 학과와의 관계는 "소속된다" 혹은 "관리한다"등의 관계로써 정의해주시고 이 관계가 M:M관계이거나,
이 관계가 중요한 업무상중요한 행위에 해당하는 행위엔터티라면 교차엔터티 생성도 고려하심이 맞다고 생각됩니다.

어렵지만 데이터 모델링은 철저하게 원리원칙에 근거해서 깊은 사고를 동반하지 않으면 안되는 작업입니다.
다 안다고 생각하지만 막상 실전에서 적용하면 엔터티 인지 속성인지 관계인지 정확하게 구분해 내기가 상당히 어렵습니다.
먼저 기본에 충실해야 하고 그에 맞게 다양한 실전경험을 쌓는것이 중요합니다.
모델러의 잠깐 실수에 그 프로젝트의 성패가 달려있을수도 있습니다.
그럼...

X 표시한 부분을 다 삭제하시고 그냥 줄로 이으세요.

잘 작성하였는데(다대다 관계를 해소하는 등)

학과는 부서로 바꾸시고 학과코드를 부서코드로 바꾸세요.

직원테이블의 소속코드는 부서코드로 수정,

그럼 부서와 직원이 연결됨.

교수테이블의 PK는 직원번호로 하시고,

직원과 교수를 1:1(Optional)로 하세요.

그리고 교수테이블에 별도 교수ID를 만드시고.

그럼 X를 다 삭제하고 그냥 줄로 이으시면 다대다도 해결되면서

ERD(CRD가 맞겠네요. Conceptual ...)

열심히하세요.