05. 관계 이야기 (2)

관계 구성 요소

• 관계비
• 관계 존재성
• 관계 타입
• 관계 참여수
• 관계 명

 

관계 구성 요소 - 관계 참여수

관계 참여수는 관계와 연관된 엔터티의 개수를 의미한다. 하나의 관계에 포함된 엔터티의 개수를 관계 참여수라고 한다.

 

관계 참여수의 3가지 구분

1. 2개체 관계: 가장 흔한 참여수(2). 두 개의 엔터티 간의 관계
2. 재귀 관계/1개체 관계: 하나의 엔터티에서 발생하는 관계
3. 3개체 관계: 세 개의 엔터티에서 발생하는 관계
   • 3개체 관계는 복잡한 관계이다. 그렇지만 이를 편의성을 위해 2개체 관계로 관리하는 것은 함수 종속에 따라 데이터를 정확히 관리하는 것이 아니므로 바람직하지 않다. 요건만 제대로 반영했다면 3개체 관계가 특별히 부작용이 있는 것이 아니며, 오히려 효율적이므로 3개체 관계를 사용하는 것이 바람직하다.

 

관계 참여수와 주 식별자

• 대부분의 관계인 2개체 관계와 재귀 관계인 1개체 관계는 주 식별자와 직접적인 관계가 없다. 즉 엔터티 자체 성격에 의해 주 식별자가 결정된다. 하지만 3개체 관계는 일종의 교차 엔터티이기 때문에 관계가 주 식별자와 직접 연관된다. 3개체 이상이 관여한 관계는 주 식별자를 도출하기가 쉽지 않다.
• 3개체 관계 엔터티의 주 식별자가 반드시 세 개의 속성으로 구성되는 것은 아니다. 이는 교차 엔터티도 마찬가지다. 인스턴스를 유일하게 식별할 수 있도록 주 식별자를 도출해야 한다. 이를 알기 위한 방법은 함수 종속을 찾는 것이다. 함수 종속은 관계비와 연관 있다.
• N개체 관계를 관리하는 엔터티는 교차 엔터티이기 때문에 주 식별자를 도출할 때 주의해야 한다. 교차 엔터티의 인스턴스를 늘리는 데 영향을 끼친 엔터티, 즉 관계비가 'M'인 엔터티만이 주 식별자에 포함된다.

 

관계명

관계 명은 관계선 위에 표시하는 관계의 이름이다.

• 관계 명이 물리적으로 사용되지 않기 떄문에 아예 필요 없다는 주장도 있지만, 관계 명은 규칙에 맞도록 모델링 했을 때 모델의 가독성을 높일 수 있다.
• 관계선과 양쪽 엔터티명을 보고도 관계를 바로 알 수 없다면 관계 명이 필요하다.
• 관계 명을 붙이는 원칙: 필요할 떄 명사형으로 관계선의 중앙에 붙이는 것
• 다대다(M:M) 관계의 관계 명은 엔터티로 나타나며, 일대다(1:M) 관계의 관계 명은 속성으로 나타난다.

 

관계 명 붙이는 방법

관계 명 붙이는 방법: 하위(자식) 엔터티 + 수식어 + 상위(부모) 엔터티

 

1. 계좌사고(하위 엔터티) + 접수(수식어) + 부서(상위 엔터티)

2. 관계 명과 관계 속성 명을 거의 유사하게 표현한다.

3. 계좌사고를 접수한 부서와 계좌사고를 처리한 부서 모두 표현해야 한다면 아래와 같이 표기한다.

 

관계 명이 필요할 때와 필요 없을 때

관계 명이 필요할 때

• 수식어가 필요할 때
• 재귀 관계일 때
• 추출 관계일 때
• 양방향 관계일 때
• 다대다 관계일 때

관계 명이 필요 없을 때

• 상위(부모) 엔터티에 일대다(1:M)로 종속되는 관계일 때
• 성능이나 관리 차원에서 엔터티를 분해해서 관리하는 일대일(1:1) 관계일 때

 

일대일 관계

일대일 관계가 발생하는 이유

1. 업무 규칙에 의해서 발생하는 자연스러운 일대일 관계
2. 성능이나 관리 측면에서 발생하는 인위적인 일대일 관계

일대일 관계에서 주의할 점

• 속성을 일반화시켜 하나의 엔터티에서 관리할 때는 뒤에 발생하는 프로세스가 여러 번에 걸쳐 입력될 수 있는지를 주의해야 한다. 즉 일대다(1:M) 관계가 될 수 있는지 주의해야 한다. 현재는 아니더라도 언젠가는 그렇게 될 가능성이 있다면 확장성을 위해 일대일 관계인 두 개의 엔터티로 설계해야 한다.
• 일대일 관계에서 외래 식별자는 발생이 늦은 엔터티 쪽에 생성되는 것이 일반적이다. 하지만 데이터 생성 순서는 때에 따라 뒤틀려지기도 하므로 데이터의 성격을 파악해 어떤 데이터가 의미상으로 상위(부모) 데이터인지를 파악해서 하위(자식) 엔터티에 외래 식별자를 생성한다.
• 대부분의 인스턴스가 널 값인 속성은 업무에서 중요하게 사용되지 않을 가능성이 높다. 따라서 핵심적인 엔터티에서 분리하는 것은 좋은 전략이다.
• 일대일 관계를 도출할 때, 엔터티에 속한 속성 중에서 유사한 2~3개의 속성을 묶어서 별도의 엔터티로 분해하는 것은 지양해야 한다.

 

일대일 관계와 이력 데이터

일대일 관계에는 이력 데이터가 포함되지 않는다. 이력 데이터까지 고려하면 일대일 관계는 있을 수 없으므로, 이력 데이터를 고려하기 전에 기본적으로 원천 데이터만으로 파악해야 한다.

 

배타 관계

배타 관계는 두 개 이상의 상위(부모) 엔터티와 관계를 가지며, 그 관계가 상호 배타적일 때의 관계를 말한다. 하위(자식) 엔터티의 하나의 인스턴스는 관계를 가지는 두 개 이상의 상위(부모) 엔터티 중에서 하나의 엔터티와만 관계를 가진다.

 

• 거래 내역은 주식이나 채권 종목과 관계가 있으며, 거래내역 엔터티의 각 인스턴스는 상위(부모) 엔터티인 주식종목이나 채권종목 둘 중 하나의 엔터티와만 관계가 있다.
• 배타 관계가 발생한 엔터티(거래내역)에는 보통 해당 인스턴스가 어떤 상위(부모) 엔터티와 관계를 가지는지를 나타내는 구분자 속성이 존재한다. 위 모델에서는 종목구분코드 속성이 이에 해당한다. 구분자 속성도 널이면 안 된다.

배타 관계를 속성으로 구현하는 두 가지 방법

1. 배타 관계를 하나의 속성으로 통합해 관리하는 방법 (위 모델)

• 새로운 배타 관계가 추가되더라도 엔터티 구조는 변경 없이 코드 인스턴스의 추가만으로 적용할 수 있기 때문에 확장성이 좋다.
• 해당 속성에 인덱스가 필요할 때 인덱스를 추가로 생성하지 않아도 돼 인덱스 관리 차원에서도 효율적이다.
• 쿼리도 효율적이어서 많은 장점이 있다.
• 참조 무결성을 사용할 수 없다는 단점이 있다.

2. 배타 관계를 개별적인 속성으로 관리하는 방법

• 유연하지 않은 모델이다.
• 많은 널 데이터가 발생한다.
• 인덱스가 늘어나며 쿼리 측면에서 비효율적이다.
• 참조 무결성 제약을 정확히 생성할 수 있어 데이터 무결성이 높아진다.

배타 관계와 서브타입은 관계가 있으며, 서브타입은 데이터 통합과 밀접한 관계가 있다. 엔터티를 통합하는 기준 중의 하나가 배타 관계가 발생할 때다. 배타 관계를 발생시킨 엔터티의 데이터 성격이 같다면 통합을 고려해야 한다.

 

주 식별자가 다른 엔터티의 배타 관계

고객번호와 계좌번호는 다른 성격의 번호며 고객번호는 10자리, 계좌번호는 12자리라고 가정한다.

 

 

위 모델과 같은 배타 관계가 있을 때 배타 속성을 관리하는 네 가지 방법

 

1. 고객번호 속성과 계좌번호 속성을 주 식별자에 개별적으로 관리하는 모델

• 관계가 없는 인스턴스에서는 주 식별자에 기본 값을 사용해야 한다.(ex. 0000000000)
• 가독성이 좋다는 장점이 있다.
• 주 식별자 속성 값에 약속된 기본 값(논리적으로는 널 값)을 사용해야 한다는 단점이 있다.

 

2. 주 식별자에 기본 값을 사용하지 않기 위해 고객번호와 계좌번호 속성을 통합한 모델

 

• 고객번호가 10자리고 계좌번호가 12자리이므로 고객계좌번호 속성은 고객번호와 계좌번호를 다 수용할 수 있는 12자리가 되어야 한다.
• 1번 모델보다는 장점이 많다고 생각되지만, 주 식별자의 값이 가변의 의미를 지니고 있는 것이 단점이다.

 

3. 고객번호 속성만 주 식별자로 사용한 모델

• 고객별 알림 서비스든, 계좌별 알림 서비스든 고객번호는 존재하기 때문에(계좌번호를 알면 고객번호도 알 수 있어) 고객번호를 주 식별자로 사용한다.
• 계좌번호 속성에 값이 존재하지 않으면, 즉 계좌번호 속성이 널이면 고객별 알림 서비스를 의미하고, 계좌번호에 값이 존재하면 계좌별 알림 서비스를 의미한다.
• 이 모델은 업무적으로는 배타 관계인데 모델은 배타 관계가 아니다. 
• 배타 관계라는 업무 규칙도 표현이 안 되며, 주 식별자 본연의 기능에 다른 기능이 혼합돼 혼란스러울 수 있는 모델이다.

 

4. 인조 식별자를 사용한 모델

• 배타 관계를 관리하는 알림서비스약정 엔터티에 인조 식별자를 채택하고, 배타 관계 속성은 고객계좌 번호 속성으로 통합한 모델이다.
• 알림서비스약정 엔터티에 하위(자식) 엔터티가 존재하면 모델을 단순하게 만들어 주는 장점까지 있는 모델이다.
• 배타 관계 속성이 일반 속성으로 사용돼 1번 모델이나 2번 모델보다 확장성이 좋다.
• 인조 식별자가 업무적으로 사용되지 않을 수 있다는 단점이 있다.

 

재귀 관계

엔터티의 특정 인스턴스가 같은 엔터티의 다른 인스턴스와 관계를 가지는 관계를 재귀 관계라고 한다.

 

재귀 관계가 발생하는 경우

1. 계층 데이터를 관리할 때(종속 관계)
2. 자기 참조 데이터를 관리할 때(참조 관계)

 

재귀 관계의 관계비

1. 일대일 재귀 관계
   • 실무에서 자주 발생하지 않는다.
   • 일대일 재귀 관계일 때는 관계 속성에 유니크 인덱스를 생성해야 한다. 그렇지 않으면 관계선은 일대일이지만 같은 값이 입력될 수 있어 일대다  재귀 관계가 될 수 있다.
2. 일대다 재귀 관계
   • 가장 일반적인 관계이다.
3. 다대다 재귀 관계
   • 재귀 관계 중에서 다대다 관계가 발생하는 모델을 BOM 모델이라고 한다.
   • 실무에서 BOM 관계는 그다지 많이 발생하지 않는다.

 

재귀 관계에서의 데이터 발생 규칙

계층 데이터를 관리하는 재귀 관계에서 최상위 데이터는 업무적으로 널이어야 하지만 최적의 조회 성능을 위해 임의의 값을 등록해서 사용한다.

최상위 부서에 대한 상위 부서는 없기 때문에 부서 엔터티에서 재귀 관계를 관리하는 상위부서번호 속성은 널이 허용돼야 한다.

하지만 인덱스에는 널 값이 존재하지 않기 때문에 성능 측면에서 비효율이 발생할 수 있다.

위와 같이 가상의 인스턴스(부서번호 000)를 채택해 쿼리 비효율을 방지해야 한다.

이렇게 가상의 인스턴스를 추가하면 인덱스를 효율적으로 사용할 수 있게 되고 무엇보다 재귀 관계를 참조 무결성 제약으로 구현할 수 있으므로 데이터 무결성도 높일 수 있다.

이처럼 업무적으로는 존재할 필요가 없는 데이터이지만, 성능이나 참조 무결성 측면에서 유용하기 때문에 추가되는 인스턴스가 간혹 존재한다.

 

분류 계층 모델

어떤 분류를 대/중/소 계층으로 관리하는 모델은 자주 사용된다. 이런 모델은 재귀 관계를 기반으로 하거나, 주 식별자 값에 체계를 부여햐여 관리하면 효율적으로 관리할 수 있다.

 

위 모델은 단순해보이지만 사용하기에는 불편하다. 조인도 많이 발생하지만 여러 요건에 대한 조회 쿼리를 작성하기 쉽지 않다. 이와 같은 분류 계층 구조 모델은 재귀 관계를 사용하거나 코드 체계를 사용하면 효율적인 모델이 된다.

 

위 모델은 계층 구조가 가변적이라면 사용해야 하는 모델이다.

 

위 모델은 계층 구조가 고정적일 때 사용할 수 있는 모델이다.

 

위 모델은 재귀 관계 없이 코드 체계를 활용한 모델이다. 이 모델 또한 분류 계층이 고정적일 때 사용할 수 있다. 

데이터를 생성하기 어렵지만, 분류 계층이 고정적일 때 조회 요건ㅇ르 가장 쉽게 구할  수 있는, 생각보다 효율적인 모델이다.

 

추출 관계

속성에도 추출/중복 속성이 있듯이 관계에도 중복을 의미하는 추출 관계가 있다. 추출 관계는 중복 관계라고도 한다. 추출 속성이 관계 속성일 때는 추출 관계가 된다. 추출 관계는 이미 존재하는 관계로 구현이 가능한 관계다. 다시 생성할 수 있으므로 따로 관리하지 않아도 되는, 없어도 되는 관계다.

 

 

추출 관계를 사용하는 경우

1. 상속되는 관계의 깊이를 줄이려고 하는 경우
2. 추출 속성을 채택하기 위한 경우

추출 관계는 성능을 향상시키기 위해서만 사용해야 한다. 사용 편이성을 위해서 사용해선 안 된다.

추출 관계는 가능한 사용하지 않는 것이 바람직하며, 사용하더라도 데이터 정합성을 주의해야 한다.

 

양방향 관계

두 엔터티 간에 서로 존재하는 관계가 양방향 관계다. 상호 관계나 교차 관계라고도 한다. 양방향 관계는 잘 알려지지 않았지만, 실무에서 비교적 자주 발생한다.

 

 

실무에서 양방향 관계는 크게 두 가지 이유에서 나타난다.

1. 업무에서 필요한 요건을 반영해서 나타나는 경우
2. 추출 관계를 사용하는 경우

 

잘못 설계한 관계선

관계선을 잘못 표현하는 유형

1. 엔터티 간에 연관성이 존재하는데도 관계를 표현하지 않는 것
2. 연관성이 없는데도 관계를 표현하는 것

관계 도출 시 염두해 둘 것

• 속성으로 관리하려는 관계
• 참조 무결성 관계
• 바로 상위의 1차 관계

위의 세 가지 요소를 기준으로 해당 사항이 없으면 관계선으로 표현하면 안 된다.

 

잘못 설계한 관계선의 다양한 예제

1. 주 식별자가 같을 때

• 관계선을 무의식적으로 표현하는 대표적인 경우는 엔터티가 유사하며, 주 식별자 속성이 같을 때다.
• 단순히 데이터의 성격이 유사하고 주 식별자가 같다는 이유로 두 엔터티에 관계선을 표현한 잘못된 모델이다.

2. 프로세스를 표현할 때

• 관계선에 대해 주로 혼동하는 것 중의 하나가 프로세스를 관계로 표현하는 것이다.
• 물론 프로세스가 관계로 표현되는 예도 있지만, 그렇지 않은 예도 많기 때문에 프로세스를 무조건 관계로 표현하지 않아야 한다.

3. 주 식별자를 상속한 관계가 추출 관계일 때

• 주 식별자를 상속한 추출 관계선도 표현하지 않아야 한다.

4. 상위(부모) 엔터티가 복합 주 식별자일 때

• 상속받은 관계 속성이 상위(부모) 엔터티의 주 식별자와 순서가 일치하지 않으면 안 된다.
• 부모 엔터티의 주 식별자가 하위 엔터티로 상속될 때는 전체가 식별자로 상속되든지 일반 속성으로 상속되든지 해야 한다.
• 복합 주 식별자를 하나의 속성으로 변환해서 상속하면 안 된다.
• 상위(부모) 엔터티의 주 식별자가 상속될 때 NULL/NOT NULL이 혼용돼도 안 된다.

5. 집계 엔터티와 관계선을 표현할 때

• 집계 엔터티의 주 식별자를 원천 엔터티에 식별 관계로 상속할 수 없으므로 위와 같은 관계는 주의해야 한다.
• 주 식별자가 같을 때 집계 엔터티 간에도 관계선을 표현할 때가 많다.
• 집계 엔터티의 집계 기준 역할을 하는 엔터티와는 관계선을 표현해야 한다.

6. 원천에 대한 백업 엔터티가 존재할 때

• 원천 엔터티와 백업 엔터티와는 관계선을 표현하지 않아야 한다. 특정 데이터에 대한 인스턴스는 백업 엔터티와 원천 엔터티 둘 중의 하나에만 존재하므로 참조 무결성 관계가 존재하지 않는다.

7. 주 식별자가 체계 값일 때

• 계좌 엔터티의 주 식별자인 계좌번호 속성 값에는 체계(지점번호+계좌순번)가 존재해, 지점번호별로 순번을 채번해서 계좌번호를 생성한다.
• 이때 계좌번호 체계 내에 있는 지점번호와 지점 엔터티의 지점번호는 관계가 존재하지 않는다. 체계 내에 속해있는 속성과는 관계를 표현하지 않아야 한다.
• 이밖에 채번 용도로 설계된 엔터티나 외부 기관과 주고받는 전문을 관리하는 엔터티, 공통 코드 엔터티 등과는 참조 무결성 관계가 존재하지 않으므로 관계선을 표현하지 않아야 한다.

 

관계 검증

1. 관계 검증의 어려움
   • 엔터티/속성과 달리 관계는 비교 기준이 부족해 검증이 어렵다.
   • 업무 규칙과 실제 데이터 분석이 필요하며, 기계적으로 자동 검토하기 힘들다.
   • 대부분 관계선을 눈으로 확인하며 검토해야 함.
2. 검증 방법
   • 관계 속성 기반 검토: 화면에 관계 속성 또는 관련 속성이 사용되었는지 확인.
   • 쿼리 분석: 개발 후 조인 구문이 관계선과 일치하는지 확인.
   • 고립된 엔터티: 다른 엔터티와 관계 없는 경우 검토 필요.
3. 잘못 설계된 관계 주의
   • 단순히 주 식별자가 같다고 관계를 만든 경우.
   • 프로세스를 관계로 표현한 경우.
   • 집계 엔터티의 관계가 집계 기준에 맞지 않는 경우.
4. 검토 대상 관계 유형
   • 배타 관계: 불필요한 복잡성을 만들므로 통합 여부 검토.
   • 양방향/순환 관계: 업무 규칙을 제대로 반영했는지 확인.
   • 다수 관계: 관계 엔터티로 통합 가능성 검토, 속성 수식어 사용 여부 확인.
   • 일대일(1:1) 관계: 드물게 발생 → 요건 오해나 불필요한 분리 여부 검토.
   • 선택적 상위 관계: 사실상 관계 없음과 유사 → 가능하면 필수 관계로 설계.
5. 추가 검토 포인트
   • 모든 관계는 가능하면 1차 관계여야 함. (성능 고려 추출 관계 제외)
   • 표현되지 않은 1차 관계가 없는지, 중복 관계가 없는지 확인.
   • 일부 시스템 속성/코드/이력 엔터티 관계선은 생략 가능하지만 무결성이 우선이면 생략하지 않음.
   • 복합 주 식별자 상속 관계: 속성 순서와 정의가 정확히 일치하는지 검토.

결론:

관계 검증은 자동화하기 어렵고 많은 경우 업무 규칙과 모델러의 판단에 의존해야 한다. 관계의 실효성과 무결성, 단순성(1차 관계 위주), 불필요한 관계(배타, 순환, 과도한 다중 관계) 여부를 중점적으로 점검하는 것이 중요하다.