솔류선에서 제공한 ERD를 보면서 심히 느끼는 바가 많다. ERD관계선을 새로 그리고 있다.
이에 대해서 언급하기시작하면 白書를 써라고 해도 가능할 것 같다.

그냥 짧게 교차엔터티에 대해서 말하면...

Modeling 관점에서 교차엔터티는 null 허용 foreign key가 걸릴 이유가 없다. 일반적으로 교차엔터티의 식별자는 양쪽 엔터티간의 관계가 식별관계일 뿐만아니라, 인조식별자로 본질(업무)식별자를 대신하고 본질식별자를 비식별관계로 연결하여 일반속성으로 Foreign key를 건다하더라도(이렇게 인조식별자를 사용할때는 본질식별자에 unique 제약을 걸어 instance 생성 rule을 반드시 표현해야 한다. 이 경우는 양쪽 엔터티에서 상속받은 식별자가 본질식별자이고, 필요하다면 교차엔터티의 고유식별자와 함께 묶여 본질식별자로써 unique 제약이 걸려야한다), 교차엔터티의 Role이 양쪽 엔터티의 Mapping인데 한쪽값만 있고 반대편값이 없는 instance는 의미없기때문이다. 이렇게 관리하는게 더 복잡하다.

그런데 실제 AS-IS시스템을 분석하거나, 필드 PL들이 설계하는걸 보면 교차엔터티에 양쪽 엔터티에서 상속받은 식별자가 null 허용 foreign key로 비식별관계로 표현해 놓은 경우가 많고, 실제 테이블도 null허용으로 관계속성을 만들어 놨다. 그래서 실제 누적된 데이터를 조회해보면 한쪽이 없거나 심지어 양쪽 모두 값이 없는 garbage row가 있다. 사실 솔직히 말하자면 식별자를 제외하고 null허용여부 속성을 not null로 표현해 놓은 ERD나 테이블, 자체를 보기 힘들다.

ERD는 Table을 만드는 script를 뽑는 도구이거나, 프로젝트 막바지에 DB에서 reverse해서 제출하는 산출물이 아니다. 설계자와 개발자, 과거의 설계자 본인이 현재의 설계자 본인에게 또 나중에 다시 보게 될 본인에게 Business rule을 전달하는 communication 매개물이다. 이점을 잊지말고 Business rule이 왜곡되어 표현되지 않도록 엔터티의 성격을 알고 정확히 설계하여야 한다.

誤記는 誤解를 부르고 誤解는 誤用을 낳는다.

설계에서 誤記란 잘못된 기록뿐만아니라 반드시 해야 할 기록을 누락한것도 誤記이다.