10.4 관계 표현

• 1. 관계명
• 2. 관계선

1. 관계명

• 모델의 가독성을 높이는게 목적
• 모든 관계선에 관계명을 붙이지 않는다.(모든 관계의 관계명을 표현하면 가독성이 훼손될 수도 있다.)
• 관계명을 관계선 양쪽에 관계 동사 형식으로 표현하는 것은 좋지 않다.
• 관계명을 명사형으로 하나만 표현하는 것이 모델을 이해하는 데 도움을 주므로 굳이 관계 동사로 표현할 이유가 없다.

• 양쪽관계에 동사로표현하는 경우 : 대부분 중복된 이중 표현으로 나타나고 관계명을 붙이는데 더욱많은 고민, 산재된 여러개의 텍스트로 가독성이 떨어지게 됨
• 관계명하나,동사나부사형으로 표현하는경우 : 의미가 명확히 전달되지 않고 모델만 복잡해진다.

그림 10.45

• 요건 : 계좌사고 엔터티에서 계좌의 사고를 접수한 부서를 관리한다.
• 관계명 : 하위엔터티 + 상위 엔터티 형식으로 생성(양쪽 엔터티명을 활용)
• Role 이름을 엔터티명 사이에 붙이는 때도 있다
• 관계속성의 Role 이름 : 상위엔터티의 주 식별자를 그대로 사용하지 않으려고 사용한 변형된 관계 속성명을 의미
• Role이름은 상위엔터티의 역할에 따라 달라지므로 상위엔터티 앞에 사용

그림 10.46

• 요건: 계좌 사고를 처리한 부서도 관리해야 할 경우(양쪽 엔터티명을 활용)
• 두 엔터티 사이에 관계가 여러 개 존재할 때는 관계명이 반드시 필요하다. 가독성 떨어지는걸 방지
• 관계속성명을 염두에두고 관계명을 정하므로 관계명과 속성명이 유사해짐

그림 10.47

• Role이름은 그림 10.49 주문 엔터티의 주문고객번호 속성과 같이 관계 속성명을 구체적으로 정의하려고도 사용한다.

그림 10.49

• 그림 10.50 의 주문자속성 은 관계속성만으로는 어떤 엔터티와 관계가 있는지를 명확하게 나타내지 못하므로 관계속성에 Role이름을 사용할 때는 상위엔터티의 주 식별자 속성명을 차용해서 사용하는 것이 좋다. 그림 10.49처럼 사용

그림 10.50

• 그림 10.51 주문과 주문상세 엔터티 같은 1:M 종속관계는 관계명이 필요 없다.
• 본질적으로 같은 성격의 데이터이므로 상세 관계에 대해 굳이 부가적인 설명이(Role 이름)이 필요하지 않다.

그림 10.51

• 그림 10.52 고객과 개인 고객상세 엔터티와 같이 1:1관계, 즉 성능이나 관리차원에서 엔터티를 분리해서 관리하는 1:1관계는 사실상 하나의 엔터티 이므로 관계명이 필요 없다.

그림 10.52

• 그림 10.53 계좌와 거래내역의 관계에서도 관계명을 필요 없다. 해당 계좌에 대한 거래내역을 관리하는 것이므로
• 억지로 관계명을 붙여야하면 해당거래계좌 등으로 관계명 붙이고 관계속성명은 해당거래계좌번호 등으로 정해야하는데 계좌번호로 정해도 의미가 충분히 통하고 간명하다.

그림 10.53

• 그림 10.55 최종거래와 같은 추출관계에 대해서도 관계명은 필요하다.
• 추출 관계명을 필자가 소개한 방법대로 붙이면 계좌최종거래 정도가 도겠지만 계좌는 일반적이라 생략.
• 거래내역 엔터티의 이름-> 필자는 엔터티 뒤에 내역과 같은 접미사를 붙이는 것을 꺼리지만 거래내역은 이미 너무 고착화된 엔터티명이라 계속사용한다.
• 대신 관계명은 계좌최종거래내역이라고 정하지 않고 내역이라는 단어를 생략

구람 10.55

• 행위 엔터티간에는 일반적으로 관계명이 없어도 된다.
• 프로세스나 발생 규칙 등을 관계명에 적는것은 올바른 방법이 아니다.
• 이유 : 관계에 대한 왜곡된 이해가 생길 수 있다.(프로세스나 예외 상황,발생규칙 등을 표현하기 위해 관계선(속성)을 사용하지 않을까 우려)
• 하지만 관계에 대한 확실한 이해를 바탕으로 하고 모델의 가독성을 높이는데 도움을 준다면 상위 수준의 개념 모델에서는 간혹 간략한 문구를 사용하는 것도 좋다.
• 계좌 이력엔터티에서 관리할 이력데이터를 스냅샷 방식으로 생성한다는 고려사항이나 결정사항을 표현

그림 10.57

2. 관계선

• 관계선은 반드시 참조 무결성(RI)제약으로 구현돼야 한다.
• 하위엔터티의 속성값이 널이거나 상위 엔터티의 주식별자에 존재할 때만 관계선을 표현해야 한다.

• 주 식별자가 같고 엔터티까지 유사하면 무조건 관계가 존재하는 것으로 생각할 때가 많다.
• 그림10.60 모델에서 퇴직사원 데이터는 사원 엔터티에는 존재하지 않고 퇴직사원 엔터티에만 존재한다고 가정하면 서로 관계가 없으므로 관계선을 표현하면 안된다.

그림 10.60

• 프로세스를 관계로 표현하는 경우
• 프로세스가 관계로 표현되는 예도 존재하지만 그렇지 않은 예가많아서 주의해야한다.
• 하나의 주문이 여러 건으로 체결, 하지만 체결한 건에대해 여러건의 결제데이터를 관리하지는 않음

그림 10.62

• 그림 10.66 상속받은 관계속성이 상위엔터티의 주 식별자와 순서가 일치해야 한다.

그림 10.66

• 부모 엔터티의 주 식별자가 하위엔터티로 상속될 때는 전체가 실별자로 상속되든지 일반속성으로 상속되든지 해야 한다.
• 그림 10.63같이 상위엔터티의 주 식별자 중에서 계좌지점,계좌번호 속성은 하위엔터티에 주 식별자로 상속되고 계좌 상품 속성은 비식별자(일반속성)로 분리돼 상속되면 안된다.

그림 10.67

• 그림 10.68 같이 여러 속성을 하나의 속성으로 변환해서 상속하면 안된다.
• 계좌지점, 계좌상품,계좌순번 속성을 합친 번호가 계좌번호를 의미해서 하위엔터티에 계좌번호 속성으로 상속한 관계로, 이는 가독성에도 문제가 있지만 조인에도 문제가 있어 정당한 관계라고 볼 수 없다.

그림 10.68

• 상위 엔터티의 주 식별자가 상속될 때 Null/Not Null이 부분적으로 지정돼도 안된다.
• 그림 10.69같이 주문체결 엔터티에 일반속성으로 상속받은 주문일자,계좌지점,주문순번속성중에 일부만 널이 허용돼서는 안된다.

그림 10.69

• 그림10.70같이 하위 엔터티로 여러개의 관계가 상속될때, 주식별자 중 일부 속성이 같은 값을 사용한다는 이유로 상속을 생략할 경우가 있다.

그림 10.70

• 하위엔터티에 중복 성격의 관계속성이 생기더라도 그림10.71같이 관계선에 해당하는 속성을 모두표현
  그래야 참조무결성 제약도 생성하기 수월하고 가독성도 높아진다.

그림 10.71

• 원천엔터니와 백업엔터티와는 관계선을 표현하지 않는다.
• 채번 용도로 설계된 엔터티나 외부 기관과 주고 받는 전문을 관리하는 엔터티, 공통코드 엔터티 등과는 참조 무결성관계가 존재하지 않으므로 관계선을 표현하지 않는다.
• 엔터티간 관계가 존재하지만 입력사원번호 등과 같이 전체 엔터티에 공통으로 존재하는 시스템 속성과는 관계선을 생략|
• 그림 10.78 왼쪽은 거래주제영역을 기준으로 표현한 모델, 계좌 주제영역의 계좌엔터티와 관계가 존재해서 관계선을 표현했지만 주 식별자가 외부 엔터티로 상속되어 잘못된 표현, 오른쪽과같이 계좌 주제 영역에 표현해야 함

그림 10.78

핵심.

• 관계선을 표현하는 것은 업무 규칙이나 업무 요건을 반영하는 것이므로 추측해서 표현하지 않고 정확하게 표현해야한다.
• 항상 참조 무결성 제약을 염두에 두고 관계선을 표현해야 한다.