by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

관계 종류




10.5 관계 종류

  • 1:1 관계
  • 배타적 관계
  • 순환적 관계

1:1 관계

  • 성능적 : IO
  • 관리적
  • 업무적 : [그림 10.79] 일대일 관계

[그림 10.79] 일대일 관계

  • 현재 상태의 여권 데이터을 관리함

[그림 10.80] 일대다 관계

  • 여권의 과거 데이터를 관리하면 1:M

[그림 10.81] 바람직하지 않은 실체 엔터티의 주 식별자

  • 주 식별자 : 해당 엔터티의 인스턴스를 유일하게 식별할 수 있는 최소한의 구성

[그림 10.82]일대일 관계를 합체한 엔터티

  • 업무적으로 도출된 엔터티 간의 일대일 관계는 최종 단계까지 통합하지 않고 그대로 표현하는 것이 바람직하다.

[그림 10.83]속성 하나가 엔터티로 도출된 모델

  • 여권번호만 엔터티로 관리가 불필요. 하나로 통합

[그림 10.84]일대일 관계가 발생하는 서브타입 모델

[그림 10.85]널 속성을 별도의 엔터티로 분리한 모델

  • 자주 조회 되지않은 속성이 핵심적인 엔터티에 포함되면 버퍼에 자주 쓰이게 되므로 성능을 저하시키는 요인이된다.

[그림 10.86]자주 사용되지 않는 속성을 별도의 엔터티로 분리한 모델

  • 배치( 월배치, 년배치 )
  • 특정 계좌의 대량 기간

[그림 10.87]엔터티를 분리해 락(lock)을 분산시킨 모델

  • 엔터티를 분리해 트랜잭션이 상호 영향이 없도록 할 수 있다.

배타 관계

[그림 10.88] 배타 관계 엔터티

  • 구분자 속성으로 관리
  • 장점 : 새로운 베타관계가 추가 되더라도 거래내역 엔터티 구조 변경 없음
  • 단점 : 배타관계 추가시 엔터티 발생, 참조 무결성 제약 조건 설정 못함

구분자 속성 필요 이유..

SELECT A.거래번호, A.종목구분코드
 FROM 거래내역 A, 주식종목 B, 채권종목 C
WHERE B.주식종목코드(+) = DECODE( A.종목구분코드,1, A.종목번호 )  -- 종목구분코드( 1:주식,2:채권 )
 AND  C.채권종목코드(+) = DECODE( A.종목구분코드,2, A.종목번호 )

[그림 10.89] 배타 관계 엔터티를 통합해 서브타입이 도출된 모텔

  • 바람직한 모델

[그림 10.90] 배타 관계 속성을 개별적으로 관리하는 모델

  • 단점 : 배타관계 추가시 컬럼 추가, 많은 널값 발생, 인덱스 늘어남

[그림 10.92] 고객과 계좌별로 관리되는 알림 서비스

[그림 10.94] 배타 관계를 개별 속성으로 관리하는 모델

  • 고객과 계좌는 성격이 전혀 다르므로 통합 대상 아님
  • 고객번호 : 10자리, 계좌번호 12자리
  • 널값을 사용 할 수 없으므로 셋팅된 값을 설정

[그림 10.95] 배타 관계를 하나의 속성으로 관리 하는 모델

  • 단점 : 고개번호 10, 계좌번호 12, 주 식별자의 값이 가변의 의미를 지니고 있는 것이 단점

[그림 10.96] 필수 속성을 주 식별자로 베타 관계를 관리하는 모텔

  • 계좌번호 속성이 null 이면 고개별 알림 서비스를 의미하고, 계좌번호에 값이 존재하면 계좌별 알림 서비스를 의미한다.

[그림 10.97] 배타 속성을 일반 속성으로 사용해서 배타 관계를 관리하는 모델

  • 인조식별자로 관리
  • 단점 : 인조식별자가 업무적으로 사용되지 않을 수 있다

[그림 10.98] 배타 속성이 복잡한 엔터티

  • 고객번호, 종합계좌번호, 지점코드의 데이터 성격과 길이가 유사하다면 [그림 10.97]의 고객계좌번호 속성과 같이 배타 속성으로 관리할 수 도 있다.

[그림 10.99] 필수 속성을 기준으로 배타 관계를 관리하는 모델

  • 변경일시( 또는 변경순번)를 사용해서 데이터를 생성하는 것도 또 다른 방법이다.

순환 관계 [ 그림 10.103 ]

  • 본사는 상위 부서가 존재하지 않으므로 업무적으로 상위부서코드 속성은 널값이 돼야 한다.

[그림 10.104] 계층 구조를 통합해 관계가 단순해진 모델

  • 바람직한 모델

[그림 10.107] 순환 구조의 모델과 릴레이션

  • 인덱스를 사용할수 없어 성능에 문제가 되며 '00'등의 무의미한 값을 사용할 수도 있다.

[그림 10.108] 코드 체계를 계층 구조로 관리하는 모델과 릴레이션

  • 분류계층이 고정적이라면 사용할 수 있는 모델

[그림 10.109] 다른 인스턴스를 지정해 관리하는 순환 관계

  • 원래 주문이 무엇인지를 순환 관계로 표현

[그림 10.110] 일대일 순환 관계

  • 1:1일때는 상위 관계 속성에 유니크 인덱스를 생성해야 한다. 1:1이지만 같은 값이 입력되어 1:M 관계가 될 수 있다.

[그림 10.111] 일대다 순환 관계

[그림 10.112] 다대다 순환 관계

  • 하나의 엔터티에서 실현될 수 없으므로 교차 엔터티을 사용해 관계를 해소해야한다.

[그림 10.113] 여러 역할을 관리하는 다대다 관계

추출 관계 == 중복 관계 ( 반정규화 ? )

  • 관계에도 중복을 의미하는 추출 관계가 있다.
  • 추출 속성은 기존에 존재하는 속성 값에서 생성시킬 수 있는 속성이다.
  • 저장해 관리하며 오히려 데이터 정합성이 훼손될 가능성이 존재해 성능 문제가 없는 한 채택하지 않는 것이 바람직

[그림 10.117] 상속 단계를 줄이기 위한 추출 관계

  • 왼쪽 모델처럼 대분류.중분류.소분류를 관리하는 엔터티가 있을때
    소분류 엔터티에서 특정 소분류코드의 대분류코드가 무엇인지를 알려면 중분류.대분류 엔터티를 조인 해야 한다.

양 방향 관계

[그림 10.121] 역할이 다른 양 방향 관계

  • 대표적 양반향 관계

[그림 10.122] 추출 관계로 인한 양 방향 관계

[그림 10.123] 일대일 관계가 포함된 양 방향 관계

[그림 10.124] 추출 관계로 인한 원환 관게

  • 계좌 엔터티의 고객번호 관계 속성과 계좌약정 엔터티의 계좌번호 관계 속성은 정상적인 일대다 관계이다.

10.6 참조 무결성( Referential Integrity )

관계 검증

  • 관계선으로 표현된 관계가 업무에서 관리하려고 하는 관계인가?
  • 1촌 관계만을 관계선으로 표현했는가?
  • 참조무결성제약으로 존재하는 관계선만을 표현했는가?
  • 관계선의 카디널리티가 정확하게 표현되었는가? 1:1, 1:M
  • 관계선의 옵셔널러티가 정확히 표현되었는가? 선택 , 필수
  • 생략된 관계선은 없는가?
  • 배타 관계가 반복적으로 발생하는가?
  • 엔터티 간에 관게가 다수 발생할 때 룰 이름을 적절하게 사용했는가?
  • 양 방향 관계나 원한 관계가 제대로 표현되었는가?

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.