관계 구성 요소 (카디널리티, 옵셔널리티, 관계 디그리)

 

엔티티 사이 연관성은 관계선으로 표현합니다. 관계선은 크게 세 가지 요소로 구성됩니다.

카디널리티, 옵셔널리티, 관계 디그리 입니다.

 

카디널리티

엔티티 연관성을 파악하고 관계를 도출해서 관계선을 표현할 때 가장 기본적인 요소가 카디널리티 입니다.

카디널리티는 상위 엔티티의 인스턴스 하나가 하위 엔티티의 인스턴스 몇 개와 관련 있는지 나타내는 제약과 같습니다.

 

관계되는 인스턴스 개수를 엄격히 파악해 표현하는 것이 원칙이지만 대부분 관계는 고정되지 않는 카디널리티를 갖습니다.

카디널리티를 데이터베이스에서 구현하기 쉽지 않아 1:1, 1:M, M:N 과 같은 개념적으로 표현합니다. 

 

간혹 카디널리티 최대 수가 정해지는 관계도 존재합니다.

예를 들어 한 학생이 5과목 이상 수강할 수 없는 요건이 있는 경우입니다. 이때 관계선에 최대 숫자를 표시할 수 있습니다.

 

상위 엔티티의 인스턴스에 해당하는 하위 엔티티 인스턴스의 정확한 숫자를 파악하기 이전에 최대한 하나인지 최소한 하나 이상인지 파악해 관계선을 표현하는데 이것이 엔티티 간 연관성을 분석하는 첫 단계입니다.

 

데이터 성격에 따라 생성된 엔티티 사이에 관계선을 업무 규칙으로 반영합니다. 상대 엔티티 인스턴스 몇 개와 연관되는지 파악하는 것은 중요한 업무 규칙입니다. 이런 규칙을 파악하면 엔티티 정의도 명확해 집니다.

 

일대일 (1:1)

일대일 관계는 상위 부모 엔티티 하나의 인스턴스에 하위 엔티티의 인스턴스가 최대 하나만 연결됩니다.

부서와 부서장의 일대일 관계를 나타내는 예입니다.

 

부서에는 부서장 한명이며 한 사람이 여러 부서의 부서장을 할 수 없다는 요건이 존재한다고 가정합니다. 물론 한 사람이 여러 부서의 부서장이 될 수 있고 한 부서에 여러 명이 공동으로 부서장이 될 수 있다는 요건이 있다면 일대일 관계는 성립하지 않을 것입니다.

 

만약 과거의 부서장을 관리해야 한다는 요건이 있다면 일대일 관계는 깨지게 됩니다. 이력 데이터는 항상 카디널리티 제약에 영향을 미친다는 사실을 염두해야 합니다. 이력 데이터를 관리하면 카디널리티는 상향 조정됩니다.

원천 데이터 간 관계가 일대일이라면 이력 관계는 일대다 관계가 되고 원천 관계가 일대다 이면 이력 관계는 M:M 됩니다. 

원천 관계가 다대다 이면 이력 관계는 교차 엔티티에 주 식별자가 추가됩니다.

 

실전에서 업무 규칙에 따라 일대일 관계가 도출되는 경우는 적습니다. 이는 데이터를 얼마나 상세하게 관리하냐와 연관됩니다.

일반적으로 자세하게 관리하므로 대부분 일대다 관계가 발생합니다. 업무 규칙에 의한 일대일 관계가 드물지만 실무에서는 수많은 일대일 관계를 볼 수 있습니다.

 

주로 데이터 성능을 고려해 엔티티를 분해한 것입니다. 필요에 따라 하나의 엔티티를 분해하는 것이 효율적일 수 있습니다.

 

일대다 (1:M)

일대다 관계는 대부분 관계에서 발생합니다. 상위 엔티티 하나의 릴레이션에 하위 엔티티 릴레이션이 최소 하나가 연관되어 있습니다.

한 부서에 여러 사원이 존재하고 한 사원은 하나의 부서에만 속한다는 업무 규칙이 존재합니다. 만약 한 사원이 여러 부서에 속할 수 있다는 업무 규칙이 존재하면 일대다 관계는 성립하지 않고 다대다(M:N) 관계가 성립하게 됩니다.

 

다대다 (M:N)

다대다 관계는 최종 물리 모델에서는 구현될 수 없습니다. 그래서 두 개의 일대다 관계로 풀어야 하며 이 과정에서 새로운 엔티티인 교차 엔티티가 생성됩니다. 다대다 관계를 해소하면 두개의 1:M 관계가 발생하는 것이 일반적이지만 다시 다대다 관계가 발생할 수 있습니다.

 

카디널리티 정의할 때 최대 수와 최소 수를 분석하는 것이 중요합니다. 하나의 인스턴스와 관계될 수 있는 상대 인스턴스 최대 개수는 하나 아니면 그 이상(1 or M)이 됩니다. 반면 하나의 인스턴스와 관계돼야 하는 인스턴스의 최소 개수는 없거나 단 하나(0 or 1)입니다.

 

이것이 옵셔널리티입니다. 최소 개수가 0이면 선택 관계이고 1이면 필수 관계입니다.

 

 

옵셔널리티 

상관되는 관계 값의 존재 여부를 의미합니다. 하위 엔티티 값과 연관되는 상위 엔티티 값이 반드시 존재해야 하는지 존재하지 않아도 되는지를 의미합니다. 그 반대도 마찬가지입니다.

 

옵셔널리티는 카디널리티 일부로 볼 수 있습니다. 인스턴스 개수를 의미하는카디널리티의 최소 개수가 0이라면 관계 인스턴스가 존재하지 않아도 되는 선택(Optional) 관계이며 최소 개수가 1이라면 관계 인스턴스가 반드시 존재해야하는 필수(Mandatory) 관계입니다. 

 

최소 카디널리티 개수를 확인하면 옵셔널리티를 정의할 수 있다. 옵셔널리티는 카디널리티 일부로 볼 수 있지만 옵셔널리티를 굳이 구분하는 이유는 관계가 존재하는 엔티티의 인스턴스 간 상호 존재 여부를 파악하는 것이 관계를 정의하는데 중요하기 때문입니다.

두 엔티티 사이 관계가 존재하는지 판단할 수 있는 요소입니다.

 

상관되는 인스턴스 존재 여부를 판단하는 기준은 상위 엔티티의 인스턴스에 데이터가 생성되는 시점 등 특정 시점을 기준으로 판단하는 것은 아닙니다. 언젠가 발생하게 되는 미래 시점을 기준으로 판단해야 합니다.

 

만약 상위 엔티티 인스턴스에 대한 하위 엔티티 인스턴스 존재 여부가 필수 관계이면 대부분 상위 엔티티 인스턴스가 생성되고 곧바로 하위 엔티티 인스턴스가 생성됩니다.

 

하위 엔티티 입장에서는 하위 엔티티의 인스턴스가 존재하기 위해서 상위 엔티티에 값이 반드시 존재해야 하면 관계선이 필수가 됩니다.

 

고객 테이블 - 고객번호 (PK)

주문 테이블 - 주문번호 (PK) / 고객번호 (FK) / 배송주소

 

하지만 간혹 하위 엔티티 인스턴스에 해당하는 값이 상위 엔티티에 존재하지 않아도 되는 경우가 있습니다.

이 경우 상위 엔티티쪽 옵셔널리티가 선택이 됩니다.

 

 

양쪽 필수인 일대다(1:M) 관계

주문 - 주문번호(PK) / 고객번호 / 배송주소

주문상품 - 주문번호 (FK) / 상품코드 / 주문수량 / 주문단가

 

보통 고객은 여러 개의 상품을 한꺼번에 주문할 수 있으며 한개만 주문할 수도 있다.

하지만 한개의 상품도 주문하지 않는 예는 없습니다. 최소 한 개 상품이 주문 포함돼야 한다면 그리고 누가 주문했고, 배송할 주소가 어딘지  등 주문 데이터가 존재하지 않을 수 없어 상위 엔티티 쪽도 필수이고 하위 엔티티 쪽도 필수(Mandatory)입니다.

 

하위 엔티티가 선택(Optional)인 일대일(1:1) 관계

보드 - 보드번호 (PK) / 보드명

컴퓨터 - 컴퓨터 번호 (PK) / 컴퓨터명 / 보드번호(FK)

 

컴퓨터에 사용되는 부품인 보드를 개별 관리하는 업무가 있을때 해당 보드가 어떤 컴퓨터에 조립됐는지 관리하는 모델

한 개의 보드는 한 개의 컴퓨터에 쓰일 수 있습니다. 또한 조립 안된 보드는 해당 컴퓨터가 존재하지 않을 수 있습니다.

 

업무적으로 선택(Optional) 제약이 맞더라도 가능하면 관계선에서 상위 엔티티 옵셔널리티가 선택(Optional)되지 않도록 하는 것이 좋습니다.

RDB 장점을 활용하기 위해 서도 업무 규칙을 물리적인 차원에서 무결성 규칙으로 반영하는 것이 좋습니다.

 

데이터 무결성을 반영한 모델과 릴레이션

부서 - 부서코드 (PK) / 부서명

사원 - 사원번호 (PK) / 사원명 / 부서코드 (FK)

 

사원 - 123 / 홍길동 / 100

사원 - 124 / 김길동 / null

 

선택(Optionl) 관계를 의미하는 관계선의 양 방향 옵셔널리티와 널(Null) 값의 허용을 의미하는 사원 엔티티의 부서코드 속성입니다. 

사원 엔티티의 부서 코드 속성 값에 존재하는 Null은 부서가 정해지지 않았거나 모른다는 것을 의미할 뿐 부서 엔티티에 존재하지 않는 다른 부서코드 값이 존재해도 된다는 것을 의미하지 않습니다.

 

양쪽 옵셔널리티가 선택(Optional)인 관계선은 관계가 없는 거나 마찬가지지만 그렇다고 해도 관계선을 삭제하는 것은 옳지 않습니다.

관계선을 필수로 만들지는 못하지만 양쪽 엔티티의 연관관계가 존재하므로 관계선을 삭제하는 것이 좋습니다. 

 

 

관게 디그리

관계 디그리는 관계와 연관된 엔티티 개수를 의미합니다. 하나의 관계에 포함된 엔티티 개수를 관계 디그리라고 합니다.

많은 사람이 관계는 하나 또는 두 개의 엔티티 사이에서 발생한다고 알고 있지만 관계는 세개 이상의 엔티티 사이에서도 발생할 수 있습니다.

하나의 엔티티에서 발생하는 관계를 순환 관계 또는 1개체 관계라고 합니다.

순환 관계는 엔티티의 한 인스턴스가 동일한 엔티티의 다른 인스턴스와 관계를 갖습니다. 실제 비즈니스에서 발생하는 대부분의 업무 규칙이며 순환관계와 이 관계만을 지원합니다.

 

세 개의 엔티티가 연관된 관계를 3개체 관계라고 합니다. 일반적인 2개체 관례로는 엔티티들의 연관 관계를 충분히 설명하지 못할 때 필요합니다. 3개체 관계는 세 개의 2개체 관계와 같지 않습니다.

 

3개체 관계는 교수 인스턴스에 여러 개체가 포함 가능한 학생, 과목 엔티티와의 관계와 같습니다. 

 

3개체 관계 카디널리티 

교수 - 학생 (1:N)

교수 - 과목 (1:N)

학생 - 과목 (N:N)

 

일반적으로 N개체 관계에서 카디널리티가 1인 엔티티 숫자만큼 함수 종속이 발생하며 그 엔티티의 주식별자가 함수 종속에서 종속자가 됩니다. 또한 카디널리티가 1인 엔티티의 주 식별자는 N개체 관계에서 주 식별자에 포함되지 않습니다.

 

만약 3개체 관계를 관리하는 엔티티의 주식별자는 학생, 과목 엔티티의 주 식별자로 구성됩니다.

 

수강신청 - 학생번호 (FK) / 과목코드 (FK) / 교수 ID (FK) / 신청일자

과목 - 과목코드 (PK)

학생 - 학생번호 (PK)

교수 - 교수 ID (PK)

 

이렇게 3개체 관계와 같은 N개체 관계가 발생하면 수강신청 엔티티와 같은 별도 엔티티를 생성하고 관계를 관리해야 합니다.

3개체 관계 엔티티의 . 주식별자는 반드시 세 개의 식별자로 구성되는 것은 아니며 인스턴스를 유일하게 식별할 수 있게 도출해야 합니다. 함수 종속을 찾으면 주 식별자를 알 수 있습니다.

 

간혹 한 개의 3개체 관계로 표현해야 하는데 두 개의 2개체 관계로 잘못 도출할 수 있습니다.

 

3개체 관계

사원 - 기술

기술 - 언어

사원 - 언어

 

2개체 관계

사원 - 기술

사원 - 과목

 

관계에 참여하는 엔티티 개수는 대부분 한 개 또는 두 개지만 세 개 이상의 엔티티가 관계에 참여할 때도 빈번하게 발생합니다.

3개체 관계가 발생하면 그 관계를 관리하기 위한 엔티티가 필요하고 그에 해당하는 속성도 필요할 수 있습니다.

엔티티를 잘못 파악해 두 개의 일반적인 관계로 관리하게 되면 업무적으로 관리돼야 하는 요구 사항이 반영 안된 것이기 때문에 검토가 필요합니다.