모델링 IE 표기법

IE 노테이션에서 관계(Relationship) 표기법은 항상 헷갈리는 경우가 많다.

ERWin에서 표준으로 사용하는 노테이션이 IE노테이션이고 이것을 잘 해석해야 설계를 잘 할 수 있고, 잘 이해할 수도 있기에 바쁜시간 쪼개서 포스팅을 해본다.

외발과 까치발의 관계 1:n

• 1:N : A에 대응하는 B가 여럿이다.
  1:1 : A에 대응하는 B가 하나다.
  
  

  

크게 어렵지 않고 뒤에 많이 나오므로 자세한 예는 생략한다.

실선과 점선의 관계 Identifying 과 non-Identifying 

• 실선 ( Idenfitying ) : A가 없으면 B가 존재 할 수 없는 관계이다.
• 점선 ( non-identifying ) : A가 없이도 B가 존재 할 수 있다.

헷갈리기 쉽다. 따라서 identifying과 non-identifying에 대한 예를 들어보자.

수강내역 입장에서 본다면 학생이 없다면 존재의 의미가 없다.
그러므로 실선인 identifying이 적절하다.

학생과 학과의 관계를 보자
학생은 학과가 없이도 생성 될 수 있는가?
그렇다. 학생은 학과가 없어도 존재 할 수 있다.
이렇듯 종속되지 않고 독립적으로 생성 될 수 있으면 non-identifying이다.

사실 이것이 물리 모델링에 가면 FK를 PK로 쓸것이냐 말것이냐를 결정짓는 요인이 된다.




필수와 선택 mandatory / optional

선택사양 중 필수 조건(Mandatory) 와 선택조건(Optional) 의 차이를 알아보자
Mandatory 는 아래 그림()처럼 원이 없는 직선으로 이루어져 있고
Optional 은 아래 그램()처럼 원이 포함되어 있다.

optional이 붙었다면 상대방입장에서 볼때, optional이 붙은 객체는 있어도, 없어도 되는 그런 존재가 된다.

물리 모델링에서는 optional 칼럼은 null이 가능, mandatory 칼럼은 not null이 가능 이정도로 구현이 된다.

이런건 백날 설명해도 헷갈리는 것이므로 가능한 뽑을 수 있는 모든 예를 뽑아 보겠다.

첫번째 예는 학생의 이동여부를 판단하는 학생 엔티티와 이동 엔티티에 대한 관계를 나타낸 것이다.

 

이동은 학생이 없이 존재 할 수 있을까? 

없다.

그러므로 identifying(실선)이 적합하다.(FK가 PK로 사용되어진다.)

이동을 한 학생도 있지만 이동하지 않은 학생도 있다고 생각이 드므로 이동족에 optional이 좋다.

이동은 항상 학생이 있어야 하기 대문에 mandatory가 어울린다.(학번이 not null) 

그렇다면 다음과 같은 표현은 과연 나올 수 있을까?

학생쪽에 optional이 붙었다는 것은 학생이 있어도 되고 없어도 되고 즉 null 가능이라는 뜻이다.

그렇지만 실선인 identifying이 붙었으므로 이동은 학생이 없이는 존재 할 수 없는 엔티티이다.

따라서 학생을 안가져도 된다는 의미를 담은 optional은 실선(identifying) 하에서는 1:n의 1쪽에 사용 될 수 없다.

이것이 이해가 잘 안된다면 물리적인 개념으로 이해를 해보자.

identifying으로 관계가 맺어 졌다면 FK가 PK로 들어와 있는 상태이다.

이 상태에서 학생쪽에 optional이 붙는다면 이동 테이블의 학번(FK) 속성이 null이 가능이 되어야 한다.

그렇지만 PK는 not null 제약을 포함한다.

따라서 위와 같은 표현은 나올 수 없는 표현이다.

또다른 예를 한번 들어보자.

당신은 쇼핑몰을 구현한다.

쇼핑몰을 주문을 받은 정보를 엔티티로 구현하려고 한다.

주문에는 담당 사원번호가 있다.

담당 사원은 기존의 사원 테이블과 연동하여 FK로 정의하고자 한다.

이 비지니스에 대한 IE 노테이션은 다음과 같을 것이다.

 

주문쪽에 있는 optional은 주문을 담당하지 않는 사원이 있을 수도 있기 때문이라고 해석이 된다.

사실 대부분의 경우 1:n의 n쪽에는 optional이 붙게 된다.

이는 물리적 DB구현이 어려워서이기도 한다.

optional이 붙지 않게 되는 경우는 의미상으로 있을 수 있지만( 다음 예제에서 설명하겠다.) 

DB 로 구현하기가 힘들어진다.(TRIGGER 또는 어플리케이션 단계에서 손봐야 한다.)

이것을 감안하여 까치발(n)에는 동그라미(optional)가 달리도록 DB테이블을 설계하는 것이 좋다.

주문은 사원없이 존재할 수도 있지만(non-identifying), 꼭 하나의 담당 사원이 할당 되어야 한다.(mandatory)

따라서 점선인 non-identifying, 사원쪽에는 필수조건인 mandatory가 붙었다.

만약 위의 테이블을 아래와 같이 구현했다면 어떤 의미가 되는 것일까?

이것은 해당 주문에 담당사원이 배정 되지 않아도 된다는 의미를 가진다.

따라서 담당사원번호(FK) 컬럼이 null이 가능한 컬럼이 된다.

그렇다면 1:n관계지만 optional이 아닌 관계는 없을까?

의미적으론 가능하다.

다음 테이블을 보자

주문이란 일반적인 홈쇼핑몰에서 주문하는 정보를 의미하고, 한개의 주문 속에 있는 여러개의 상품은 주문상품이라는 테이블로 분리를 하였다.

생각을 해본다면, 주문과 주문상품은 1:n관계이다. 장바구니에 담아서 여러 상품을 한꺼번에 구입 할 수도 있기 때문이다. 

주문과 주문상품은 그리하여 1:n관계라는 것은 어렵지 않다.

그렇지만 여기서는 보통과 다른 관계가 나온다.

아무런 상품없이 주문하는 경우가 없기 때문에 주문은 주문상품이 적어도 하나 이상은 존재해야 가능하다.

따라서 1:n의 n쪽이 optional이 아닌 mandatory 가 되는 경우가 발생했다.

잘 발생하지 않는 경우긴 하지만, 의미가 너무 명확하다.

그렇지만 이런식의 구조는 물리적 DataBase로 구현하기 쉽지 않다.

따라서 optional로 바꾼 후 처리를 해주는 경우가 있고,(비지니스적인 룰을 수정할 수도 있다.)

굳이 구현을 하고자 한다면, 주문상품과 주문이 한꺼번에 등록이 되어야 하므로 트리거 혹은 어플리케이션 단계에서의 도움을 받아야 한다.

DB단계에서 무결성을 체크해주는 단계가 없으므로 사용에 주의 해야 한다.

정리

이제 정리를 해보자.

1:1 관계는 사실 많이 쓰이지 않는다.

자주 쓰이는 1:n 관계의 종류와 그것을 물리적으로 구현한 모양을 간단히 나타내 본다면 다음과 같다.

1번째 , identifying , mandatory, optional 이경우는 B는 A가 없다면 존재 할 수 없다. 반면 A는 B가 없어도 괜찮은 관계이다. 물리적 DB구성은 B테이블에 A의 PK를 FK로 하며, B테이블의 PK로 들어온다.

2번째 , identifying , mandatory, mandatory 이 경우는 B도 A없이 존재 할 수 없고, A또한 B가 없다면 존재하기 힘든 관계이다.물리적 DB구성은 B테이블 경우는 1번째 경우와 동일하다. A의 ID가 PK로 들어온다.
그렇지만 1:n의 1의 관계에서 B의 ID를 PK로 물고 있는 경우가 없기 때문에 무결성을 지키기 위해서는 별도의 처리 로직 (TRIGGER 혹은 어플리케이션단계에서의 처리) 이 필요하다.

3번째 , non-identifying , optional, optional 이 경우는 A가 없이도 B는 존재 할 수 있으며, B는 A의 ID를 PK가 아닌 일반 속성으로 가지게 된다. 그리고 B의 입장에서 A또한 있어도 그만 없어도 그만인 optional 속성이므로 A의 ID 컬럼이 null이 들어와도 무방하게 된다.

4번째 , non-identifying , mandatory, optional 이 경우는 3번째와 마찬가지로 A없이 B가 존재할 수 있다. 그렇지만, B의 입장에서 A는 필수 조건이다. 따라서 B의 주키는 일반속성으로 들어와 있긴 하지만 not null 속성을 가져야만 한다.