관계형데이터모데링노트 요약

관계비

mitomi 2024. 1. 24. 18:11
반응형
SMALL

관계비 

상위엔터이의 한개의 인스턴스가 하위 엔터티의 몇개의 인스턴스와 연관이 있는지 의미하는 용어

관계선을 표현할 때 일대일(1:1), 일대다(1:N), 다대다(N:N) 

일대일 관계

상위 엔터티의 하나의 인스턴스와 하위 엔터티의 인스터스가 최대 하나만 연관

등본 -  세대주 (등본에 나타는 세대주는 한명) 업무규칙에 때른 순수한 일대일 관계이다.

일대다 관계

상위 엔터티의 인스턴스 하나와 연관된 하위 엔터티의 인스턴스가 최소한 하나

부서-사원(1:N) : 특정시점에 부서는 여러사원이 존재하고, 한 사원은 하나의 부서에만 속한다는 업무 요건

다대다 관계

다대다 관계를 해소하면 두개의 일대다 관계가 발생하는 것이 일반적이지만, 다시 다대다 관계가 발생할 수도 있다. 이때는 다대다 관계가 없어질 때까지 계속 교차 엔터티를 생성해야 한다.

 

실제 모델에서 일대일 관계모델이 생각보다 많은 이유는 성능이나 관리측면에서 하나의엔터티를 분리하는 경우가 많기때문에 생김

 

관계비 분석 할때는 업무적인 요건을만 판단해야 한다. 이력데이터는 제외하고 원천 데이터만 분석해야 한다.

 

관계비 분석 방법

관계비 분석은 상대 인스턴스 개수가 하나인지, 하나 이상인지를 파악하는 것이다. 상대 엔터티의 인스턴스 개수가 최대 하나라면 일대일 관계가 되고, 최소한 하나라면 일대다 관계가 된다.

 

관계비는 관계존재성을 포함하고 있다. 관계존재성은 '0'이 포함된 일대일관계와 '0'이 포함되지 않은 일대일 관계로 구분할 수 있다. 관계를 분석할 때는 관계비와 관계 존재성을 한번에 분석하게 된다.

최대한 하나라는 것은 없을 수도 있다는 것을 의미하며, 최소한 하나라는 것은 없을수는 없고 하나보다 많을 수도 있다는 것을 의미한다.

 

관계비 분석 할때 주의할 점

- 관계비는 특정시점을 기준으로 하지 않는다.(데이터가 입력되는 시점을 기준으로 관계비를 판단하지 않는다) 관계비는 발생 할 수 있는 가능성을 의미한다. 원천데이터만을 대상으로 언젠가 발생할 가능성이 있느냐로 판단한다.

언제가 발생한다는 것은 이력을 의미하는게 아니라 원천데이터를 기준으로 판단해야 한다.

부서의 관리사원이 현재는 한명이지만 나중에 한명이 추가될수 있다는 오견이 있음에도  입력되는 시점에 한명만 존재하기 때문에 일대일로 설계했다면 관계비를 잘 못 판단한 것이다.

입력되는 시점에는 한명일지라도 추후에 추가될 수 있다면 일대다 관계가 되어야 한다.

데이터는 계속 살아서 움직이는 유기체와 같기때문에 고정된 시점이 아닌 미래를 포함한 전체 시점으로 판단해야 한다.

 

-관계비 분석 시 주의점  이력데이터이다. 사원이 동시에 여러 부서의 관리사원이 될 수 없다는 요건때문에 관리사원 번호는 중복이 없다. 부서관리사원 관계의 관계비는 일대일이다. 요건에 따른 원천데이터만으로 판단해서 관계비를 설계해야 한다. 총무부에 관리사원이 바뀌는것과 두명이 되는것과는 다른 것이다.

원천 데이터만 포함된 업무규칙에 따른 관계비는 일대일이지만, 이력 데이터까지  포함하면 관계비가 일대다가 될 수 있다는점은 주의해야 한다. 업무가 그렇다는 것과 데이터가 그렇게 생성돼 있는것과는 다르다.

 

이력데이터가 포함되면 관계비는 단계가 하나씩 올라간다. 원천데이터에 의한 관계비가 일대일이면 이력데이터는  일대다가 된다. 일대다일때는 다대다가 된다. 관계비를 설계할 때는 이력데이터가 관계비 제약에 영향을 미친다는 사실을 항상 염두해 두어야 한다. 전제조건은 원천데이터를 먼제 분석해서 관계비를 설계해야 한다는 것이다.

 

관계구성요소(관계존재성)

관계존재성은(Optionality)은 관계선에서의 양쪽 '0'표시에 해당되며, 관계비와 함께 사용돼 새발 표시로 표현되다.

관계존재성은 하나의 인스턴스와 관계가 있는 상대 인스턴스의 존재 여부를 의미한다.

하위 엔터티의 인스턴스와 연관되는 상위 엔터티의 인스턴스가 반드시 존재해야 하는지(Mandatory) 존재하지 않아도 되는지(Optional)을 의미한다. 하위엔터티의 관계속성에 사용된값이 상위 엔터티의 주 식별자 속성에는 반드시 존재하는지를 의미한다. 반대 입장에서는 주식별자 속성값이 하위엔터티의 관계속성에 반드시 존재하는지를 의미한다.

관계 존재성은 존재여부를 의미하는데, 상대 인스턴스개수를 의미하는 관계비에 포함한 개념이며, 최소개수가 '0'이면 선택관계이고,'1'이면 필수관계다. 관계비를 확인하기 전에 인스턴스 존재여부를 확인하는것이 우선이며, 특히 상위 엔터티의 관계존재성이 선택적이라면 업무 규칙이 없는 것이나 마찬가지여서 모델이 제대로 설계된 것인지 확인해봐야 한다.

 

고객 릴레이션의 입장에서  계약의 존재 여부는 계약엔터티 쪽에 있는 관계선의 동그라미로 나타낸다. 어떤 고객은 계약없음을 의미한다. 고객이 계약한 데이터가 존재하지 않는 것이므로 박길동이 계약한 인스턴스가 없다.

계약 입장에서 고객 존재여부는 고객 엔터티 쪽에 있는 관계선의 동그라미로 나타낸다. 즉 고객에 대한 계약 데이터가 존재하지 않는 다는 것을 의미한다.계약 릴레이션의 고객변호 속성에 해당하는 값중에 고객 릴레이션에 없는 값이 존재한다는 것이다. 90123456계약 인스턴스에 대한 고객번호 'A9876' 이 고객 릴레이션에 존재하지 않는다.

고객과 계약 두 릴레이션에 대해서 관계속성인 고객번호 속성을 비교해서 상대에서 존재하지 않는 값이 존재할 때는 관계존재성이 선택(동그라미)이 되는 것이다.

 

관계존재성은 존재성이 상대 인스턴스 존재여부를 의마하는데, 상위 엔터티의 관계 존재성이 선택일때 특히 주의해야 한다. 상위 엔터티쪽의 관계 존재성이 선택인 관계가 많을 수록 모델의 모호성도 증가한다. 가능하면 상위 엔터티 쪽 필수가 되도록 설계해야 한다.

 

상위 엔터티의 관계존재성

상위 엔터티의 관계 존재성이 선택일때는 업무 규칙이 관계선에 제대로 반영된 것인지 언터티가 제대로 도출된 것인지  확인해야 한다. 상위 엔터티의 관계존재성이 필수여야 두 엔터티 사이에 업무 규칙이 존재하는 것이다.

 

통장 엔터티는 고객에게 발급되기 전에 통장 실체를 의미한다. 통장번호만 생성한 후 고객이 개설하면 고객번호 통장비밀번호 통장개설일자 속성값을 업데이트하게된다.

외부 고객한테 발급한 통장까지포함한다. 고객과 관계가 아예없는 통장과 외부 고객한테 발급한 통장을 정확히 설계하지 못한 모델이다. 통장이 기존고객에게 발급되기 전에는 통장 엔터티 쪽의 관계 존재성이 선택이며, 고객 엔터티에 존재하지 않는 외부 고객에게 통장이 발급되면 고객 엔터티 쪽의 관계존재성이 선택이 된다.

 

통장 릴레이션에 고개번호가 '234'인 고객은 고객 릴레이션에 없기 때문에 고객 릴레이션과의 관계가 깨진 릴레이션이다.

고객 릴레이션의 '126'고객은 통장 릴레이션에 없어 관계존재성이 선택이다.

 

양쪽 엔터티의 관계 존재성이 선택인 관계선은 관계가 없는거나 마찬가지지만, 그렇다고 관계선을 삭제하는 것은 바람직하지 않다. 이런 관계선은 상위 엔터티의 관계존재성을 필수가 되도록 만들어야 한다는 신호이다. 또는 관계가 아예없을 수도 있어 모델이 잘 못 설계됐을 수 있다는 신호이다.

상위 엔터티 쪽 선택인 관계성을 없앤모델

위 모델에서 고객·외부고객 엔터티의 관계존재성이 선택인 것처럼 보이지만, 통장 엔터티에 배타 관계가 생겼기 때문에 상위 엔터티인 고객·외부고객 엔터티를 합하면 관계존재성은 필수가 된다. 통장 릴레이션의 고객번호가 '234'인 외부 고객도 상위 엔터티에 존재하기 때문에 관계 존재성은 필수다.

 

모델의 고객엔터티와 외부고객엔터티는 통합대상 엔터티이다. 성격이 유사하며 복잡한 배타관계까지 없앨 수 있기 때문이다. 통장쪽 관계 존재성도 명확하지 않다. 통장자체는 고객과 관계가 없는데 관계선으로 연결돼 명확한 관계가 있는 것 처럼 보인다. 관계는 있지만 관계에 참여하지 않는 데이터와 관계가 아예없는 데이터는 다르기 떄문에 구분하는 것이 좋다.

발급되기 전에 통장 실체와 고객에게 발급된 통장을 구분해서 설계하면 더욱 명확한 모델이 된다. 

양쪽 관계 존재성을 명확하게 설계한 모델

외부와 내부 고객데이터를 고객데이터로 통합해서 고객쪽 관계 존재성이 필수가 되었으며, 통장 엔터티는 고객엔터티와 직접적인 관계가 없다. 고객통장 엔터티와는 관계가 있지만 관계에 참여하지 않은 고객이 있기 때문에 고객통장 엔터티 쪽 관계 존재성은 선택이다.

 

상위 엔터티의 관계 존재성이 선택일 때는 대부분 상위엔터티에 누락데이터를 포함시키거나, 누락데이터를 새로운엔터티로 설계해사 배타관계로 관리하면 상위 엔터티의 관계존재성은 필수가 된다.

 

통장엔터티는 고객엔터티와는 직접적인 관계가 없으며, 고객통장 엔터티와 관계가 존재한다. 고객통장 엔터티에는 고객번호 속성값이 존재하는 인스턴스만 관리할 수 있다.

 

통장 엔터티 처럼 프로세스가 진행되면서 상태가 바뀌는 데이터는 보통 프로세스에 따라 엔터티를 생성하지 않는 것이 원칙이다. 하지만 프로세스테 따라 관리하는 속성이 많이 달라지면 데이터 성격이 변하는 것일 수 있고, 관계가 다르다면 성격이 다른것일 수 있으므로 별도의 엔터티(통장, 고객통장)로 관리되는것이 효과적이다.

 

양쪽 엔터티의 관계존재성이 선택인 관계선은 관계가 없는 거나 마찬가지다. 모호한 모델을 사용할 수록 데이터 무결성을 훼손된다. 관계선의 양방향 관계 존재성이 선택인 모델은 다시 한번 검토해야 한다.

 

 

 

부서에는 최대한 한명의 사원이 소속돼있다는 것을 의미한다. 업무요건으로는 자주 발생하지 않는 관계다. 일대일 관계의 모델이다.하위 엔터티에 데이터가 끝까지 생기지 않을 수 있다.

 

일대일 필수관계는 하나의 트랜잭션을 의미하지 않는다. 반드시 두 엔터티에 동시에 데이터가 생겨야 하는 것은 아니며, 언제가는 꼭 생겨야 하는 것을 의미한다. 

 

 

가장일반적인 관계선이다. 부서에 소속된 사원은 없거나 한명이거나 여러명일 수 있다. 사원은 반드시 하나의 부서에 소속돼야 한다. 소속된 부서가 없을 수는 있지만(Null) 부서에 존재하지 않은 임의의 부서에 속할 수는 없다.

 

부서에 최소한 한명의 사원이 있어야 한다는 업무 규칙이 있는 대표적인 모델이다.

 

 


고객은 여러개의 상품을 한꺼번에 주문할수 있으며, 한개만 주문할 수도 있다. 최소한 한개의 상품이 주문에 포함되어야 주문이라 할수 있는 것이다.

상위·하위 엔터티의 관계존재성 필수이다.

 

 

상위 엔터티의 관계존재성이 선택인 모델이다.  하위 엔터티에 존재하는 데이터가 상위 엔터티에 존재하지 않을 수도 있다는 업무 규칙을 표현한 관계선이다.

 

 

 

 

 

 

 

 

 

 

양쪽의 관계 존재성이 선택인 일대다 관계의 모델 및 릴레이션

사원 릴레이션은 부서번호 속성에 임의의 값을 사용할 수 있어 관계 무결성은 깨진 것이다. '9999'가 의미하는 것이 어떤 부서인지 관리하기도 쉽지 않고, 가능하면 관계선의 상위 엔터티 쪽 관계존재성이 선택이 되지 않도록 하는 것이 좋다.

RDB의 장점을 활용하기 위해서라도 물리적인 차원에서 참조 무결성 제약으로 반영하는 것이 바람직하다.

 

위문제를 해결하는 방법 2가지

1.임의 부서 '9999'를 등록하는 것. 그러면 상위 엔터티의 관계존재성도 필수가 되며 데이터 무결성도 보장된다.

참조 무결성 제약을 생성할 수 있고, 모델의 효율성이 좋아진다면 때에 따라 적극적으로 검토해야 한다. 한두개의 예외경우만을 추가하면 될 정도로 인스턴스개수가 적다면 사용하기 적합하다.

임의의 인스턴스 추가한 릴레이션

만약 추가되는 인스턴스 개수가 많다면  소수의 예외경우가 아니라 특정집합이 필요할 정도라면 별도의 엔터티를 추가하고 배타관계를 사용할 수 있다.

별도 엔터티를 추가해서 배타관계로 설계한 모델

부서엔터티와 기타부서 엔터티 개별로 보면 관계존재성이 선택이 되지만, 두 엔터티를 합친(배타관계) 관점에서 보면 필수 관계가 된다. 별도의 엔터티를 둔다는 것은 특정 집합이 될 정도의 인스턴스가 있다는 것을 의미한다. 집합으로 도출할 정도의 인스턴스가 있을때 배타관계로 관리할 수 있다.

 

상위 엔터티 쪽의 관계존재성이 선택인 관계는 참조 무결성 제약을 생성할 수 없는 의미가 없는 관계다. 물리적으로 없어도 되는 관계이기 때문에 관계 존재성이 필수가 되도록 방안을 마련해야 한다.

 

 

 

 

728x90

'관계형데이터모데링노트 요약' 카테고리의 다른 글

[이력데이터 설계 1]  (0) 2024.02.21
관계 명  (0) 2024.02.01
식별 관계와 비식별 관계  (0) 2023.12.30
참조 무결성  (0) 2023.12.15
관계 이야기  (0) 2023.12.09