위 설계는 "쇼핑몰에서 제조사로 발주를 하게 되고 각 발주는 여러상품을 묶어 발주할 수 있다. 이렇게 발주된 상품은 여러번에 걸처서 운송업체로 부터 입고를 받는다"는 것으로 표현되어 있다. 

가) '발주'엔터티는 '발주상품'엔터티와 1 : one or more (IE에서 cardinality가 P로 표기)관계다. 즉 발주는 발주상품이 최소 한건이라도 있어야 성립될 수 있다는 것이다. 발주상품없이 발주데이터가 만들어 질 수 없기 때문이다. 실무에서 1 : zero, one or more로 잘 못 표기하기는 경우가 많다. 자식쪽에 zero가 허용되는 것처럼 표기하면 '발주상품없이 발주가 나갈수 있다'라고 해석 될 수 있으므로 잘 못 된것이다. 가끔 실무에서 업무진행상의 편의기능으로 필수 데이터를 입력하지 않은 상태에서도 임시저장가능하도록 요구하는 경우가 있는데 본인은 일반 속성인경우는 null허용을 고려해보기보다 기본값을 셋팅하는 것으로 유도하고,  엔터티간의 관계에서는 사용상의 편의성이 업무규칙이나 데이터 품질보다 우선할 수 없기 때문에 더더욱 잘 받아들이지 않는 편이다. 그냥 고객을 설득한다.

그와 달리
나) '발주상품'엔터티와 '발주상품입고'엔터티는 1 : zeor, one or more 관계다. 발주와 발주상품의 데이터가 만들어지는 시점에는 발주상품입고 데이터가 현실적으로 동시에 만들어 질수 없다. 즉 발주생성시점에는 '발주상품'과 '발주상품입고'관계가 1 : zero 상태로 만들어 지고, 시간이 지나 입고가 되면 1 : one, 1 : more 관계의 데이터가 누적되게 된다. 가장 일반적인 관계다.

'가'와 '나'의 관계선 차이를 살펴보면 
Barker표기법으로는 부모쪽 표기가 실선(mandatory) 혹은 점선(optional)으로 구별되고,
IE표기법에서는 자식쪽 표기에 '○'(zero) 표기존재여부로 구분된다. 

주목해야할 관계는 '대금지급'과 '발주상품입고'간의 관계이다.

먼저 대금지급은 입고가 모두 완료되면 한번에 한다는 조건으로서 결국 발주당 단 한번만 대금지급이 되므로 '발주'와 '대금지급'과의 관계는 1 : zero or one관계다.
1 : 1 혹은 1 : 0 or 1 관계의 엔터티는 사실 한 몸뚱이다. 즉 '발주'와 '대금지급'엔터티는 '발주'엔터티로 통합할 수 있다.
그러나 '발주'행위와 '대금지급'행위는 서로 다른시점의 업무이고, 업무의 R&R도 다를 수 있으므로 별개의 엔터티로 가져가서 업무규칙을 명확히 하는 것이 좋다.

보통은 부모자식엔터티간의 관계는 1쪽인 부모가 필수이고 n쪽인 자식은 선택이다.
그런데 '대금지급'과 '발주상품입고'간의 관계선을 유심히 보면 1쪽인 '대금지급'쪽이 선택(optional)이고 n쪽인 '발주상품입고'가 필수(mandatory)이다.
뭔가 이상해 보인다. 어떻게 n쪽인 자식이 필수이고 1쪽인 부모가 선택일까?

'대금지급'이 '발주상품입고'를 근거 진행되는 업무이기하나 본질적인 데이터는 서로간 부모자식관계 혹은 존재종속관계가 아니다. 그냥 참조관계이다.
※ 존재종속관계는 부모가 없다면 자식도 존재할 수 없는 관계를 말한다. 위에서는 '발주'와 '발주상품'간 '발주상품'과 '발주상품입고'간의 관계가 존재종속관계이다.
'발주상품입고'데이터가 쌓이고 이를 근거로 나중에 '대금지급'행위가 발생한다.
즉 '발주상품입고'엔터티에 데이터가 채워지는 시점에는 '대금지급'데이터는 없으므로 '대금지급번호'속성은 null허용이어야 하고, '대금지급'은 '발주상품입고'행위가 완료된 후에 이를 근거로 생성되는 데이터이므로 '발주상품입고'데이터는 필수여야 한다. 이 역시 실무에서 정확히 표현하지 못하는 경우가 많다. 유의해야할 관계이다.