5.21 관계 디그리와 주 식별자

관계

• 2개체 관계와 1개체( 순환 ) 관계는 주 식별자와 직접적인 관계가 없다
• 3개체 관계( 일종의 교차 엔터티 )는 죽 식별자와 직접 연관 된다.

그림 5.73 3개체 관계의 릴레이션

• 릴레이션으로 함수적 종석성을 구하고 주 식별자을 도출
• 두 개의 상대 엔터티의 인스턴스값이 같을 때, 자신의 인스턴스는 몇 개의 값이 존재하는냐로 판단 하여 분석

• FD: ( 학생, 교수, 과목 ) -> 신청일자
• 주 식별자 : 학생 교수 과목 ( 복합 식별자 )

그림 5.74 카디널러티가 다른 3개체 관계의 릴레이션

• 현실 고려 : 과목은 1나만 설정 가능하다.

그림 5.75 그림 5.74 릴레이션에 대한 카디널러티

• FD: ( 학생, 과목 ) -> 교수, 신청일자

그림 5.76 그림 5.74 릴레이션에 대한 모델

• 교차 엔터티 주 식별자 : 카디널리티가 'M'인 엔터티만이 주 식별자에 포함 된다.

5.22 관계 디그리의 다양한 설계 방법

• 요건1 : 사원이 담당하고 있는 고객의 계좌를 관리하기 위해, 그룹번호를 만드는 요건
• 요건2 : 고객 스스로 그룹번호에 계좌를 묶어서 관리한다.

그림 5.77 계좌그룹을 관리하는 일반적인 모델

그림 5.78 2개체 관계( 교차 엔터티 )로 설계된 모델

• 요건 변경 : 계좌그룹을 여러 사원이 관리

그림 5.79 3개체 관계로 설계된 모델

• 요건 변경 : 계좌그룹비밀번호와 조회순서을 관리하지 않아도 된다면
• 속성 관리 + 관리할 고객 계좌를 하위 엔터티로 관리하는지, 관계 엔터티로 관리하는지가 다른 점이다

관계명 ( 명사 )

• 관계선 위에 표시하는 관계의 이름
• 관계을 바로 알 수 없다면 표기 ( 관계의 가독성을 높이기 위해 )
• 관계선 양쪽에 관계 동사로서 표현해야 한다는 원칙은 바람직 하지 않다 ( 필자님 고견 )

그림 5.80 다대다 관계의 관계명

그림 5.81 그림 5.80 다대다 관계를 해소한 모델

• 다대다 관계는 관계명은 엔터티로 나타난다.
• 일대다 관계의 관게명은 속성으로 나타난다

그림 5.82 명사형의 관계명을 사용한 엔터티

• 필요 할때만 명사형으로 표현 ( 역관계을 표현 할 경우 )

5.24. 관계명 붙이는 방법

관계명을 붙이는 방법을 체게화한 이유.?

• 많은 시간을 소비하는 경우
• 관계도 속성이기 때문에 관계명이 속성명과 연관된다고 생각

그림 5.83 관계명이 필요한 엔터티

그림 5.84 관계명이 사용한 모델

• 하위(자식) 엔터티 + 상위(부모) 엔터티 ( 방법1 )
• 하위(자식) 엔터티 + 롤( ROLE )+상위(부모) 엔터티 ( 방법2 )

그림 5.85 관계명과 유사한 관계 속성

그림 5.86 관게가 두 개인 모델의 관계명

• 관계가 여러 개 존재하는 모델은 관계명이 반드시 필요한 경우다

그림 5.87 관계를 설명한 관계명

그림 5.88 설명 형식의 관계명

• 관계에 대한 확실한 이해를 바탕으로 하고, 가독성에 도움을 준다면 상위 수준의 개념모델에서는 간략한 문구을 사용가능
• 모델이 상세화 되면 삭제해야 한다.

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

• 관계명이 필요한 일반적인 기준

롤(Role) 이름이 필요할 때

• 1. 관계가 여러 개일 때 사용함
• 2. 관계를 구체적으로 정의할 때 사용함

그림 5.89 다수 관계로 인해 관계명이 필요한 모델

그림 5.90 구체적인 관계명을 사용한 모델

• 확장성을 고려한 모델

그림 5.91 관계명이 없는 다수 관계 모델

그림 5.92 관계 속성이 없는 다수 관계 모델

• 모델의 복잡성을 피하고자 개념모델에서 사용되기도 하지만, 결국 존재해야 하는 속성이 누락 우려

그림 5.93 관계명과 관계 속성이 없는 다수 관계 모델

순호나 관계일 때

• 순환관계 또한 관계명이 반드시 필요하다

그림 5.94 관계명이 필요한 순환 관계 모델

추출 관계일 때

그림 5.95 관계명이 필요한 추출 관계 모델

양방향 관계일 때

그림 5.96 관계명이 필요한 양방향 관계 모델

그림 5.97 관계명이 없는 양방향 관계 모델

다대다 관계일 때

그림 5.98 관계 엔터리로 변환되는 다대다(M:M) 관계의 관계명

관계명이 필요 없을 때

그림 5.98 관계명이 필요 없는 종속 관계

그림 5.100 관계명이 필요 없는 일대일 관계

그림 5.101 관계명이 필요 없는 상세(내역) 관계

그림 5.102 여러 관계로 인해 관계명이 필요한 모델

일대일(1:1) 관계

• 비교적 자주 발생하는 관계, 설계할 때 혼란스러울 수 있는 관계다
  • 1. 업무 규칙에 의해서 발생
  • 2. 성능이나 관리 측면에서 발생

그림 5.103 업무에 의한 일대일 관계 모델

그림 5.104 프로세스 흐름에 의한 일대일 관계 모델

• 모델은 각 프로세스에서 관리하는 속성이 다르기 때문에 일대일 관계로 설계하는데 무리가 없다.
  • 간혹 프로세스대로 엔터티을 분리하는 게 명확할 때도 있지만, 프로세스에 따라 엔터티를 분리하는 것은 바람직하지 않다.
• 일대다 관계에 될 수 있는지 주의가 필요

관리 차원에서 일대일 관계

• 슈퍼타입과 서브타입의 관계 ( 사실상 하나의 엔터티임 )

그림 5.105 자주 사용되지 않는 속성을 분리한 일대일 관계 모델

• 성능이나 관리 효율성을 판단해서 분해했지만, 비정규화했을 뿐 사실은 데이터 본질이 같으므로 하나의 엔터티다.

그림 5.106 널이 자주 발생하는 속성을 분리한 일대일 관계 모델

• 고객 엔터티의 데이터 중에서 일부 인스턴스에만 배우자 데이터가 존재하고 대부분 인스턴스는 null이라면 분리
  • 저장 공간을 효율적으로 사용하는 것이다.(?)
  • 대부분의 인스턴스가 널값인 속은은 업무에서 중요하게 사용되지 않을 가능이 높다
    • 자주 조회되지 않는 속성이 핵심 엔터티에 포함되면 버퍼에 자주 쓰이게 되므로 성능을 저하시는 요인이 된다. (?)
• 엔터티에 속한 속성 중에서 유사한 2~3개의 속성을 묶어서 별도의 엔터로 불해하는 것은 지양
• 고유 데이터로 처리할만한 요건이 있다면, 일대일 관계의 별도 엔터티로 설계할 수도 있다.

5.27 일대일 관계와 이력 데이터

그림 5.107 원천 데이터만으로 설계한 일대일 관계 모델

• 변경 데이터을 제외하고, 원천 데이터만을 고려할 때 고객의 유효한 여권은 한개 뿐이다.( 업데이트 )

그림 5.108 이력 데이터를 포함한 일대다 관계 모델

• 일대다 관계지만, 특정 시점을 기준으로 고객에게 유효한 여권은 하나이므로 일대일 관계라는 것을 염두에 둬야한다.
  • 데이터 측면에서는 일대다
  • 업무 규칙 측면에서는 일대일

그림 5.109 일대일 관계 모델을 합친 엔터티

• 원칙적으로 성격이 다른 엔터티는 개별적으로 존재해야 함
  • 엔터티에 존재할 수 있는 속성이 한두 개가 전부고, 늘어날 가능성이 없다면 합체 고려
  • 위와 반대 경우는 엔터티로 도출
• 그림 5.108과 같이 이력 데이터를 관리하는 업무 요건의 변경 등으로 관게 카디널리티가 바뀔 가능성이 존재한다
  • 이력 데이터 관리 요건까지 검토가 마무리되고 나서 최종 단계, 가능하면 물리 모델링 단계에서 일대일 관계의 엔터티를 합체 고려
• 그림 5.109과 같이 사용하다 이력 데이터을 관리해야 할 때 그림 5.108모델과 같이 변경할 수 있지만,
  • 그림 5.109는 확장성이 떨어지는 모델이다
• 그림 5.108 과 같이 업무을 그대로 반영 모델이 이해하기 쉬우며, 업무 변경이나 이력관리 요건등을 유연하게 적용 할 수 있는 모델

5.28 배타적 관계( Exclusive Relationship )

• 두 개이상의 상위(부모) 엔터티와 관계를 가지며, 그 관계가 상호 배타적일 때의 관계

그림 5.110 배타 관계가 발생한 모델

• 장점 : 하나의 속성으로 통합 관리( 유연함 )
  • 새로운 배타 관계가 추가되어도( 펀드종목 ) 엔터티 구조 변경 없음
    • 인덱스 생성 불 필요 ( 존재시 )
  • SQL 효율적
• 단점 : 참조 무결성을 사용할 수 없다
  • 현실적으로 여러 가지 이유로 인해 참조 무결성 제약을 물리적으로 생성하지 않는다고 하더라도, 원천적으로 사용 할 수 없는 모델은 문제일 수 있다.

{code:SQL}

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

h5. [그림 5.111] 개별 속성으로 배타 관계를 관리하는 모델
* 단점 : 개별적인 속성으로 관리
** 개별적 인덱스 생성
** SQL 복잡
* 장점 : 무결성 ( FK )
|!5_111..PNG!| 
|{code:SQL}
 
 -- 상과 배타적 관계을 만족 및 인덱스 수도 최소로 관리 할 수 있다.
 CREEATE UNIQUE INDEX IX_RJFO ON 거래내역( CASE WHEN 종목구분코드 = '주식' THEN
 주식종목번호 WHEN 종목코드 = '채권' THEN 채권종목번호 END ) 

그림 5.112 배타 관계를 발생시킨 엔터티를 통합한 모델

• 그림 5.110 모델에서 베타 관계를 발생시킨 엔터티인 주식종목과 채권종목 엔터티는 서브타입 후보 엔터티다
• 그림 5.112 과 같이 두 엔터티가 통합 되면 배타 관계가 발생하지 않는다.
  • 종목구분코드 속성이 거래내역 엔터티에 필요 없다

그림 5.113 성격이 다른 엔터티에 의한 베타 관계

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

• 그림 5.114 모델과 같은 베타 관계가 있을 때, 배타 속성을 관리하는 방법은 크게 네 가지가 있다.
• 그림 5.114 배타 관계가 발생한 모델

그림 5.115 주 식별자에 개별 속성으로 배타 관계를 설계한 모델

• 장점
  • 가독성
• 단점
  • null 값 대신 디폴트 값 설정 ( ex : '999999999999' )

그림 5.116 주 식별자에 배타 속성으로 배타 관계를 설계한 모델

• 고객번호(10) 와 계좌번호(12)를 다 수용 할 수 있는 12자리가 돼야 함
• 단점 : 주 식별자의 값이 가변
• 그림 5.115나 그림 5.116 모델처럼 기본값, 가변적 바람직 하지 않음
  • EX : 계좌 엔터티의 주 식별자가 지점번호(4) + 계좌순번(8) 일 경우 그림 5.115나 그림 5.116 모델은 사용하기 어렵다.

그림 5.117 배타 관계 속성 중 하나만 주 식별자로 설계한 모델

• 고객별 알림 서비스든, 계좌별 알림 서비스든 고객번호는 존재 하기 때문에 고객 번호를 주 식별자로 사용한다.
• 계좌번호 속성이 null : 고객별 알림 서비스
• 계좌번호 속성이 not null : 계좌별 알림 서비스
• 업무적 배타적 관계인데 모델은 배타 관계가 아니다.
• 고객번호 속성으로 조회하는 요건이 많을 때 사용( 예외적 사용 )

그림 5.118 인조 식별자를 사용한 모델

• 필자님 생각 : 개인적으로 인조 식별자를 사용한[그림 5.118]모델을 선호한다.
• 배타 관계 속성이 일반 속성으로 사용돼[그림 5.115]나 그림 5.116 모델보다 확장성이 좋다
• 계좌 엔터티의 주 식별자가 지점번호(4) + 계좌순번(8) 일 경우 유연하게 적용 가능
• 추후에 계약별 알림 서비스가 추가 되더라도 확장하기 수월한 모델이다.
• 단점 : 인조 식별자가 업무적으로 사용되지 않을 수 있다는 점 ( 실무에서 꺼림 : 주 식별자를 보고 업무를 파악할 수 없다. )

그림 5.119 상위 엔터티의 주 식별자를 복합한 베타 관계 모델

• 엔터티의 주 식별자가 복잡할 때는, 비 식별자 관게로 상속하고, 인조 식별자를 사용하는 방법이 무난하다.
• 고객번호 종합계좌번호 계약지점번호 속성의 데이터 성격과 길이가 유사하다면 그림 5.118 모델의 고객 계좌번호 속성같은 배타 속성으로 관리할 수도 있다 ( ? )

그림 5.120 복잡한 주 식별자와의 배타 관계를 관리하는 유연한 모델

• 엔터티를 통합하는 것이 실익이 없다면 배타 관계로 관리하지 않고, 개별적 엔터티에서 관리할 수도 있다.

5.30 순환 관계( Recursive Relationship )

• 엔터티의 특정 인스턴가 같은 엔터티의 다른 인스턴스와 관게를 가지는 관계를 순환 관계

계층

• 소속 개념이 존재

그림 5.121 계층 조직을 설계한 모델

• 계층 단계가 늘어나면 엔터티를 추가해야 하며, 조직이 개편돼 중간 계층이 없어지면 확장성이 떨어지는 모델

그림 5.122 계층 관계 엔터티와 베타 관계가 발생한 모델

그림 5.123 그림 5.121 모델을 통합한 모델

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

[그림 5.124} 그림 5.122 모델에 대한 순환 관계 설계 모델

[그림 5.125} 2개의 계층으로 고정된 모델

• 계층 관계가 두 개로 완전히 고정됐다면

자기 참조( Self Referencing ) == ( 순환 )

그림 5.126 자기 참조 관계

• 계층 구조의 엔터티를 하나의 엔터티로 통합해 순환 관계로 구현하는 것은 주로 실체 엔터티나 주요 엔터티와 같은 상위 엔터티
• 엔터티 내의 관계(연관) 된 인스턴스를 참조해 관리하는 순환 관계는 행위 엔터티까지 전반적으로 많이 발생한다.

순환 관계 카디널리티

• 1:1 관계, 1:M 관계, M:M 관계 ( 다대다 순환 관계를 해소하면 교차 엔터티( BOM ) )

일대일 순환 관계

• 배우자 변경을 이력으로 관리하면 1:M으로
• 1:1 순환 관계 : 관계 속성에 유니크 인덱스 생성

그림 5.127 일대일 순환 관계 모델

일대다 순환 관계

그림 5.128 일대다 순환 관계 모델

다대다 순환 관계

• 하나의 부품이 다른 여러 개의 부품으로 구성되며, 그렇게 구성된 하나의 부품이 다른 부품의 구성원이 될 수 있다.
• 다대다 순환 관계는 BOM 모델보다 역할( Role )을 관리하는 모델로 주로 발생한다.

그림 5.129 다대다 순환 관계를 해소한 BOM 모델

그림 5.130 역할을 관리하는 관계 사원이 다수인 모델

그림 5.131 다수의 역할을 관계 엔터티( BOM 엔터티 )로 설계한 모델

• 그림 5.130 에서 순환 관계가 추가 된다면..

5.32. 순환 관계에서의 데이터 발생 규칙

그림 5.132 널 허용인 순환 관계

그림 5.133 널 값인 최상위 인스턴스

• 상위부서번호가 null 인 값의 조회가 자주 발생하면 성능 측면에서 비효율이 발생 할 수 있다.
  • 부서

SELECT 부서번호, 부서구분코드
FROM 부서
CONNECT BY 부서번호 = PRIOR 상위부서번호
START WITH 상위부서번호 IS NULL

{CODE}

그림 5.134 가상의 인스턴스를 추가한 릴레이션

• 위 그림 비효율 방지 START WITH 상위부서번호 = '000'
• 참조 무결성 제약으로 구현할 수 있으므로 데이터 무결성도 높일 수 있다.
  • 부서

5.33. 분류 계층 모델

• 원칙적으로 주 식별자 값에 체계가 존재하는 것은 바람직 하지 않다.
• 이번장에서는 예외적으로 사용하면 효율적인 체계에 대해 설명함.

그림 5.135 분류 계층 모델

그림 5.136 그림 5.135 모델에 대한 릴레이션

• 모델은 단순해 보이지만 사용하기에 불편하다
• 조인도 많이 발생하지만 여건에 대한 조회 SQL를 작성하기 쉽지 않다.
  • 상품대분류

• • 상품중분류

• • 상품소분류

5. 그림 5.137 분류 계층을 순환 관계로 설계한 모델

그림 5.138 그림 5.137 모델에 대한 릴레이션

• 상품분류번호 '06'의 상위상품분류번호는 '03'이며, '03'에 대한 상위상품분류번호는 '01'이다.
• '01'에 대한 상위상품분류번호는 널이다.
• 계층 구조가변적일때 사용
  • 상품분류

그림 5.139 계층 구조가 고정적 모델

그림 5.140 그림 5.139 모델에 대한 릴레이션

• 대분류상품분류번호 속성 값이 널이면 대분류
• 중분류상품분류번호 속성 값이 널이면 중분류
• 모델이 유연하지 않기 때문에 고정적일때 사용
  • 상품분류

그림 5.141 코드 체계로 설계한 모델

그림 5.142 그림 5.141 모델에 대한 릴레이션

• 상품대분류번호 상품중분류번호 상품소분류번호 속성 값이 '00'이면 해당 분류에 대한 체계가 없다는 것을 의미
• 분류가 고정적일때 효율적인 모델
  • 상품분류

5.34. 추출 관계

• 관계의 중복을 의미
  • 상속되는 관계의 깊이을 줄이려고 사용
  • 추출 속성을 채택하기 위해 사용
• 성능 향상을 위함 ( SQL 사용 편이성 X )
  • 비정규화 기법 중 하나다

그림 5.143 추출 관계가 사용된 모델

그림 5.144 관계 상속 단계가 깊은 모델

• 관계를 식별자로 상속 시킬지, 비식별자로 상속시킬지, 추출 관계를 사용할지 전략적으로 판단

그림 5.145 추출 속성으로 인한 추출 관계

• 데이터 정합성 염두

그림 5.146 그림 5.143 모델에 대한 릴레이션

• 추츨 관계로 인한 데이터 정합성 이슈
  • 대분류

• • 중분류

• • 소분류

그림 5.147 추출 관계를 설계한 모델

• 근무 도시 관계선이 없더라도 사원의 근무도시는 알 수 있으므로 삭제 바람직

그림 5.148 추출 관계를 설계한 모델

• 사원의 거주 도시는 알 수 없으므로 필요한 관계

5.35 양방향 관계

• 실무에서 양방향 관계는 크게 두가지
  • 업무에서 필요한 요건을 반영
  • 추출 관계를 사용해서 나타날 수 있다.

그림 5.149 업무 요건에 의한 양방향 관계

그림 5.150 추출 관계에 의한 양방향 관계

그림 5.151 변형된 추출 관계에 의한 양방향 관계

그림 5.152 순환 관계

• 세 개의 엔터티 간의 관계가 순환하면 순환 관계, 두 엔터티 간의 관계가 순환하면 양방향
• 순환 관계 는 관계가 비식별 관계 일 때만 성립한다. 식별 관계일 때는 성립하지 않는다.
  • 식별자로 상속한 순환관계는 논리적으로도 틀린 모델이며, CASE 툴에서도 허용되지 않는다.

그림 5.153 잘못된 표기법으로 인해 알 수 없는 모델

• 양방향 관계를 구현한 관계 속성에는 롤 이름을 반드시 사용해야 한다.

5.36 잘못 설계한 관계선

• 관계선을 잘못 표현하는 유형
  • 엔터티 간에 연관성이 존재하는데도 관계를 표현하지 않는 것
  • 연관성이 없는데도 관계를 표현하는 것이다.
• 관계 도출 염두 사항
  • 속성으로 관리하는 관계
  • 참조 무결성 관계
  • 바로 상위의 1촌 관계
• 모델의 가독성을 위해 참고용 관계를 남발

그림 5.154 1촌 관계를 위반한 모델

• 주문전 반드시 예약주문을 해야 한다는 업무 규칙을 반영한 모델
• 'a관계' 와 'b관계'는 1촌 관계가 아니고 추출관계인데 정합성에 문제가 생길 수 있는 관계다.

그림 5.155 1촌 관계를 위반한 모델

• 반드시 선 예약주문
  • 정합성 이슈로 'a관계' 와 'b관계' 불필요 관계 발생
• 비 반드시 선 에약주문
  • 'a관계' 와 'b관계' 정상 관계
  • 예약주문과 주문 관계 삭제
• 예약주문

• 주문

그림 5.156 참조 무결성 관계를 위반한 모델

• b관계는 정상 관계
• a관계는 주 식별자가 같을 뿐 참조 무결성 관계가 아니기 때문에

h5.그림 5.157 그림 5.156 모델에 대한 올바른 릴레이션

• 고객

• 외국인고객

• 외국인거래

h5.그림 5.158 외국인고객이 고객에 통합된 모델

• 'b관계'는 1촌 관계며 참조 무결성 관계
• 'a관계'는 2촌 관계기 때문에 추출 관계다

h5.그림 5.159 그림 5.158 모델에 대한 릴레이션

• 'b관계'가 없고, 'a관계'만 있다면, 업무 규칙을 제대로 설게하지 못한 것이다.
  • 이때문에 그림 5.159와 릴레이션이 생길 수 있다.
• 성능상 불가피할 때만 'a관계'를 추출 관계로 채택해야 한다.
• 고객

• 외국인고객

• 외국인거래

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

• 참조 무결성과 1촌 관계를 고려하지 않아서 나타난다.

주 식별자가 같을 때

• 관계선을 무의식적으로 표현하는 대표적인 경우는 엔터티가 유사하며, 주 식별자 속성이 같을 때다.

h5.그림 5.160 주 식별자가 같아서 관계선을 표현한 모델

• 거래내역 엔터티 : 현금 거래만 관리
• 수표거래내역 엔터티 : 수표 거래만을 관리하는 엔터티
  • 거래번호 -> 수표거래번호

h5.그림 5.161 주 식별자가 같아서 관계선을 표현한 모델

• 요건 : 퇴직 사원 데이터는 사원 엔터티에는 존재하지 않고 퇴직 사원 엔터티에만 존재한다면,

h5.그림 5.162 관계가 없이 별개의 엔터티로 설계한 모델

• 관계가 없어 뭔가 허전한 것 같지만 맞는 모델
  • 물론 한 엔터티로 통합관리 하는 것이 효율적

프로세스를 표현할 때

• 프로세스를 무조건 관계로 표현하지 않아야 한다.

h5.그림 5.163 프로세스에 따라 관계선을 표현한 모델

• 하나의 주문이 여러 건으로 체결되므로 주문과 체결 사이의 관계는 정상
• 체결 한 건에 대해 여러 건의 결제 데이터가 생기지 않으므로 체결과 결재 사이의 관계는 정상이 아니다

h5.그림 5.164 요건에 의해 프로세스와 다른 관계선을 표현한 모델

• 체결 후 추후 업데이트을 위해 널값 허용

그림 5.165 주 식별자로 상속된 추출 관계선을 표현한 모델

• 의미 없는 관계선 : 지점 -> 거래내역

그림 5.166 추출 관계선을 표현한 모델

• 추출 관계를 채택할 수도 있다 : 지점 -> 거래내역

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

그림 5.167 상속받은 주 식별자의 순서가 일치하지 않는 모델

그림 5.168 식별자와 일반 속성으로 분리해서 상속한 모델

• 계좌지점번호 계좌순번 속성은 하위 엔터티에 주 식별자로 상속되고, 계좌상품번호 속성은 비 식별자로 분리돼 상속하면 안 된다.

그림 5.169 상위 엔터이와 주 식별자를 한 속성으로 합쳐서 상속한 모델 ( Page. 594 )

• 가독성 문제
• 참조 무결성 생성 불가
• 조인에도 문제가 발생
• 부득이하게 이렇게 사용하려면 관계선은 생략, 조인은 사용하지 말아야 한다.

그림 5.170 상속받은 속성이 Null과 Not Null로 혼용된 모델

그림 5.171 관계 속성이 생략된 모델

그림 5.172 관계 속성이 표현된 모델

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

그림 5.173 원천 엔터티와 관계를 표현한 집계 데이터

• 일별계좌거래집계 데이터가 생성 되어야만, 계좌거래내역이 등록이 가능

그림 5.174 집계 엔터티 간에 관계가 존재하는 모델

그림 5.175 디멘젼 엔터티와 관계가 존재하는 집계 엔터티

• 참조 무결성 만족
• 가독성 우수

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

• 원천 데이터와 백업 데이터와는 관계선을 표현하지 않아야 한다.

그림 5.176 원천 엔터티와 관계가 존재하지 않는 백업 엔터티

주 식별자가 체계 값일 때

• 그림 5.177 계좌 엔터티와 주 식별자인 계좌번호 속성 값에는 체계( 지점번호 + 계좌번호 )일 때

그림 5.177 체계가 존재하는 주 식별자와 관계를 표현한 모델

• 참조 무결성 불가

그림 5.178 집계 엔터티와 관계가 존재하는 원천 데이티

• 어떤 원천 데이터를 집계한 것인지를 관리 할 수 있다.
• 참조 무결성 생성 가능
  • 일반적으로 집계 데이터와 원천데이는 참조무결성 조건이 존재 하지 않는다.
  • 관계가 적합한지 확인 두 엔터티를 조인하는 쿼리가 있는지를 살펴보는 것이다.

관계 검증

• 관계는 검증이 어려운 대상
  • 업무 규칙을 이해
  • 데이터 값을 분석해야 정확한 관계를 파악 할 수 잇기 때문이다.

대략적인 관계 검증 방법

• 관계선은 속성으로 구현되기 때문에 화며에 관계 속성이 화면에 사용돼는지는 검토
  • 화면에 관계 속성이 존재
  • 관계 속성과 연관된 속성이 존재 할 수도 있다.
• 개발이 진행된 후에 검토할 수 있는 방법
  • SQL의 조인 구문을 분석해서 관계선과 매핑
• 관계선이 표현된 엔터티에 대해서 데이터 사이에 참조 무결성 제약이 있는지 검토
• 베타 관계는 모델을 복잡하게 만들기 때문에 배타 관게를 발생시킨 엔터티를 통합 할 수있는지 검토
• 양방향 관계는 업무 규칙을 제대로 표현한 관계인지 검토
• 엔터티 간에 관계가 다수 발생한 경우도 검토
  • 통합하여 설계 고민
  • 적정 롤인지 검토
• 1:1 관계도 검토
  • 일반적을 많지 않음을 염두로
  • 분리하지 않아도 무관한 엔터티를 분리한 것인지
• 1촌 관계 검토
  • 성능을 고려한 추출 관계를 제외한 모든 관계는 1촌 관계인지
• 관계가 제대로 상속 되었는지 검토
  • 주 식별자 순서