10.5 관계 종류
1:1 관계
- 성능적 : IO
- 관리적
- 업무적 : 그림 10.79 일대일 관계
그림 10.79 일대일 관계
| 그림 10.79 |
 |
그림 10.80 일대다 관계
| 그림 10.80 |
 |
그림 10.81 바람직하지 않은 실체 엔터티의 주 식별자
- 주 식별자 : 해당 엔터티의 인스턴스를 유일하게 식별할 수 있는 최소한의 구성
| 그림 10.81 |
 |
그림 10.82 일대일 관계를 합체한 엔터티
- 업무적으로 도출된 엔터티 간의 일대일 관계는 최종 단계까지 통합하지 않고 그대로 표현하는 것이 바람직하다.
| 그림 10.82 |
 |
그림 10.83 속성 하나가 엔터티로 도출된 모델
- 여권번호만 엔터티로 관리가 불필요. 하나로 통합
| 그림 10.83 |
 |
그림 10.84 일대일 관계가 발생하는 서브타입 모델
| 그림 10.84 |
 |
그림 10.85 널 속성을 별도의 엔터티로 분리한 모델
- 자주 조회 되지않은 속성이 핵심적인 엔터티에 포함되면 버퍼에 자주 쓰이게 되므로 성능을 저하시키는 요인이된다.
| 그림 10.85 |
 |
그림 10.86 자주 사용되지 않는 속성을 별도의 엔터티로 분리한 모델
- 배치( 월배치, 년배치 )
- 특정 계좌의 대량 기간
| 그림 10.86 |
 |
그림 10.87 엔터티를 분리해 락(lock)을 분산시킨 모델
- 엔터티를 분리해 트랜잭션이 상호 영향이 없도록 할 수 있다.
| 그림 10.87 |
 |
그림 10.88 배타 관계 엔터티
- 구분자 속성으로 관리
- 장점 : 새로운 베타관계가 추가 되더라도 거래내역 엔터티 구조 변경 없음
- 단점 : 배타관계 추가시 엔터티 발생, 참조 무결성 제약 조건 설정 못함
| 그림 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.89 |
 |
그림 10.90 배타 관계 속성을 개별적으로 관리하는 모델
- 단점 : 배타관계 추가시 컬럼 추가, 많은 널값 발생, 인덱스 늘어남
| 그림 10.90 |
 |
그림 10.92 고객과 계좌별로 관리되는 알림 서비스
| 그림 10.92 |
 |
그림 10.94 배타 관계를 개별 속성으로 관리하는 모델
- 고객과 계좌는 성격이 전혀 다르므로 통합 대상 아님
- 고객번호 : 10자리, 계좌번호 12자리
- 널값을 사용 할 수 없으므로 셋팅된 값을 설정
| 그림 10.94 |
 |
그림 10.95 배타 관계를 하나의 속성으로 관리 하는 모델
- 단점 : 고개번호 10, 계좌번호 12, 주 식별자의 값이 가변의 의미를 지니고 있는 것이 단점
| 그림 10.95 |
 |
그림 10.96 필수 속성을 주 식별자로 베타 관계를 관리하는 모텔
- 계좌번호 속성이 null 이면 고개별 알림 서비스를 의미하고, 계좌번호에 값이 존재하면 계좌별 알림 서비스를 의미한다.
| 그림 10.96 |
 |
그림 10.97 배타 속성을 일반 속성으로 사용해서 배타 관계를 관리하는 모델
- 인조식별자로 관리
- 단점 : 인조식별자가 업무적으로 사용되지 않을 수 있다
| 그림 10.97 |
 |
그림 10.98 배타 속성이 복잡한 엔터티
- 고객번호, 종합계좌번호, 지점코드의 데이터 성격과 길이가 유사하다면 그림 10.97의 고객계좌번호 속성과 같이 배타 속성으로 관리할 수 도 있다.
| 그림 10.98 |
 |
그림 10.99 필수 속성을 기준으로 배타 관계를 관리하는 모델
- 변경일시( 또는 변경순번)를 사용해서 데이터를 생성하는 것도 또 다른 방법이다.
| 그림 10.99 |
 |
순환 관계 그림 10.103
- 본사는 상위 부서가 존재하지 않으므로 업무적으로 상위부서코드 속성은 널값이 돼야 한다.
| 그림 10.103 |
 |
그림 10.104 계층 구조를 통합해 관계가 단순해진 모델
| 그림 10.104 |
 |
그림 10.107 순환 구조의 모델과 릴레이션
- 인덱스를 사용할수 없어 성능에 문제가 되며 '00'등의 무의미한 값을 사용할 수도 있다.
| 그림 10.107 |
 |
그림 10.108 코드 체계를 계층 구조로 관리하는 모델과 릴레이션
| 그림 10.108 |
 |
그림 10.109 다른 인스턴스를 지정해 관리하는 순환 관계
| 그림 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
- 관계선의 옵셔널러티가 정확히 표현되었는가? 선택 , 필수
- 생략된 관계선은 없는가?
- 배타 관계가 반복적으로 발생하는가?
- 엔터티 간에 관게가 다수 발생할 때 룰 이름을 적절하게 사용했는가?
- 양 방향 관계나 원한 관계가 제대로 표현되었는가?