5.1. 관계에 대한 서설

관계

• 참조 무결성은 관계(Relationship)의 다른 표현이며 RDB의 핵심이며 조인(Join)과 연관 됨

엔터티 연관성

• 논리적인 연관성(참조 무결성) 과 바로 상위 관계(1촌 관계) 필요
  • 하위에 존재하는 데이터는 상위에 존재해야 한다.
• 가상의 단순한 연관성이 아님 (한국 홍길동 - 미국 다니엘, 월드컵, 몇십단계...)

업무 흐름(Work Flow)

• 업무 흐름과 관계는 다름(관계로 표현되는 업무 흐름이 일부 있음)
• 업무 활동이 엔터티로 설계되면, 업무 흐름은 관계로 설계될 가능성이 높음
  • 업무 활동에 의해서 데이터(엔터티)가 생길 뿐, 대개 서로 별개임

정리

• 관계 / 속성 / 참조 무결성 / 조인
• 관계는 실존, 관계선의 실상 = 속성, 관계선의 실체화 = 참조 무결성 제약

5.2. 관계선(Relationship Line)이 의미하는 것

업무 규칙

• 관계선을 보고 업무 규칙(Business Rule)을 알 수 있다.
• 두 엔터티의 밀접도를 보여 준다.
  • 종속 관계 (한몸)
  • 참조 관계 (허전)

업무 프로세스

• 업무 프로세스에 의해 발생하는 데이터면 관계선이 업무의 흐름을 의미하기도 한다.

조인(Join)

• 관계선은 조인(Join)하는 경로를 의미한다.
  • 상위(부모) 엔터티의 주 식별자와 하위(자식) 엔터티의 관계 속성을 연결

입력 순서

• 관계선은 데이터를 입력할 때 입력 순서를 의미하기도 한다.
  • 보통 상위(부모) → 하위(자식) 엔터티 순서로 생성

표현

• 시스템 속성, 코드 속성을 제외하고 모든 관계는 모델에 표현한다.
  • 업무 규칙 의미 표시

5.3. 관계를 설계할 때 고려할 사항

속성으로 관리하려는 관계

• 관계 관리 필요 확인
  • 업무 담당자 판단
  • 모델러 분석 판단 (업무 효율을 위한 제안 & 검증)

• 추출(중복) 관계는 관리 필요 확인 제외
  • 성능 문제시 선택적 사용

• 관계선에 의한 속성 필요 확인
  • 속성 불필요 → 관계선 & 관계 속성 삭제

참조 무결성 관계(Referential Integrity Relationship)

• 외래 식별자(Foreign Key) 속성의 값은 상위(부모) 엔터티의 주 식별자 값과 일치하거나 널(Null) 값이어야 한다.
  • 참조 무결성 제약 (Referential Integrity Constraint)
  • 5.4 장 참조

바로 상위의 1촌 관계

• 바로 상위(부모) 엔터티 하나와의 관계만을 관계선으로 표현

• 바로 위의 부모 엔터티 찾기 #1

• • 'ad관계', 'bd관계' 는 성능 문제를 해결하기 위한 추출(중복) 관계
    • D 엔터티의 a, b, 속성은 추출(중복) 속성
  • 1촌 관계인 'cd관계'만 알면 문제 없음

• 바로 위의 부모 엔터티 찾기 #2
  • 통합종목 : 모든 종목 통합 관리
  • ETF종목 ⊂ 통합종목 & ETF종목 ⊂ 주식종목

1촌 관계 위반	1촌 관계 설계

• ETF종목 엔터티는 통합종목 엔터티와 간접 관계, 주식종목 엔터티와 직접 관계 (생략→표현)

• 1촌 관계는 참조 무결성 관계 보다 찾기 어려움

5.4. 참조 무결성(Referential Integrity)

• 참조 무결성은 참조하는 데이터 간에 결점이 없는 것을 의미
• 참조 무결성 상태
  • 하위(자식) 엔터티의 외래 식별자 속성(관계 속성)에 존재하는 값이 상위(부모) 엔터티의 주 식별자 값과 일치하거나 널(Null)인 상태
• 참조 무결성 제약
  • 하위(자식) 엔터티는 상위(부모) 엔터티에 있는 값만 입력 가능
  • 상위(부모) 엔터티는 하위(자식) 엔터티에 없는 값만 삭제 가능

• 물리적인 FK 제약 미생성 != 참조 무결성, 관계가 없음
  • 데이터 관점에서 참조 무결성이 존재하면, FK 제약이 없더라도 참조 무결성 관계임
  • 추후에 FK 제약을 생성했을 때 이상이 없도록 관계 도출 필요

• 참조 무결성 (논리 개념) = 참조 무결성 제약 (물리 개념)
• 참조 무결성 관계를 기준으로 관계선을 표현
  • 두 엔터티의 공통 속성인 식별자(주 식별자, 외래 식별자)로 조인할 수 있는 경우

• 참조 무결성이 존재하지 않는 릴레이션
  • 부서(상위)

• • 사원(하위)

• • '127' 이길동 사원의 현재근무부서번호 '600' : 참조 무결성 위반
  • 참조 무결성 제약 없음

• 성능 문제로 실무에서 참조 무결성 제약을 생성하는 경우는 드물다.
  • 입력/수정/삭제 시 무결성 유지를 위한 처리가 추가 됨 (10~15% 성능 저하)

• 참조 무결성 제약 생성 여부 선택
  • [V] 15% 정도의 성능 저하
  • 데이터 무결성 훼손

• 선택을 위한 정보
  • 데이터 무결성 훼손에 의한 비용 발생
  • 어플리케이션 로직으로 무결성 구현 역시 성능 저하 와 추가 개발 발생
  • 데이터 무결성보다 성능을 우선시 해야 하는 엔터티는 1% 이내 (저자 경험)
  • 참조 무결성 제약에 의한 개발 과 관리(DBA)의 불편함 (본질적 > 부가적)

• 참조 무결성 제약 사용의 현실적인 어려움
  • 이미 깨진 데이터 무결성 : 쉽지 않은 정제(Cleansing) 필요 (Data Quality 분야)
  • 분석의 어려움 : 참조 무결성은 데이터 값 분석을 통해 제대로 파악 가능 (예외 상황 고려 등)
    • 파악된 참조 무결성 관계를 기반으로 주요 데이터를 분석하면서 관계 확인

5.5. 기준 엔터티의 참조 무결성

• 기준 엔터티의 데이터가 바뀌면, 참조해 사용했던 다른 엔터티의 데이터를 어떻게 처리 할것인가?
  • 업무 요건에 따라서 엔터티간 관계를 심도 있게 분석 결정

케이스1) 참조 무결성 없음

• 우편주소(기준) 엔터티

• 고객 엔터티

• • 고객 엔터티에 우편주소 엔터티의 주 식별자가 없음 (관계X, 참조O)
  • 고객 엔터티의 데이터는 기준 데이터를 보고 선택한 시점의 데이터 (상위 엔터티 값이 바뀌어도 하위 엔터티에 영향 없음)

케이스2) 참조 무결성 있음

• • 기준 엔터티의 주 식별자 값이 고객 엔터티에 입력 됨
  • 고객 엔터티에 우편주소 속성 없음, 기준 엔터티 값이 바뀌면 하위 엔터티에 영향 있음 (이력 데이터, 업무 정의 검토)

케이스3) 참조 무결성 없음

• 보통 기준 엔터티와는 참조 무결성 관계가 없음

• • 데이터 입력시 기준 엔터티 값 참조 후 별도 키인 등 (계좌.수수료율 의 값은 수수료율.수수료율에 없을 수 있다)
  • 적용한 수수료율을 참조 무결성 관계로 관리하면 복잡해질 뿐 이득이 없음 (관계, 실익에 대한 고민 필요)

결론

• 기준 엔터티와의 관계 설계시 기준 엔터티의 값이 참조 엔터티에 값으로 존재 해야 하는지, 관계로 존재 해야 하는지 분석 필요
  • 값 : 참조 무결성 관계 없음 (일반적)
  • 관계 : 기준 엔터티 값 변경시 참조 엔터티 값도 변경됨 (시점 값 유지 필요시 이력 데이터 관리, 실익 없음)

5.6. 종속(Dependent) 관계와 참조(Referential) 관계

케이스1) 본질적 완전 종속 관계 (소수, 20% 이내)

• 상품가격 엔터티는 상품 엔터티가 없으면 존재 불가능 (예외 없음)
  • 종속 관계면 엔터티명도 유사 하고, 부모 엔터티의 주 식별자가 상속 된다.

케이스2) 업무적 종속 관계 (다수)

• 요건(팀이 특정 리그에 반드시 속해야 한다)에 의한 종속 관계
  • 요건에 따라 달라질 수 있음, 아래 처럼 팀 엔터티 주 식별자의 전략적 구성 가능 (참조 관계, 확장성을 고려한 느슨한(Loosely Coupled) 관리)

• • 아래 처럼 팀.리그번호 에 널(Null) 허용시 단순 참조 관계 (팀이 리그 없이 존재 가능)

케이스3) 참조 관계

• 관계 삭제 (사원.부서번호 속성 삭제) 시 사원 데이터 존재 가능 (업무 요건...)
  • 상위(부서) 엔터티의 주 식별자가 하위(사원) 엔터티의 주 식별자에 관여하지 못함
  • (저자는) 참조 관계에서는 부모/자식 엔터티 대신 상위(Referenced)/하위(Referencing) 엔터티로 표현

케이스4) 잘못 설계한 참조 관계

• 상품유형이 없어도 상품 데이터 생성 가능, 종속 관계 설계로 인한 경직성

• 위와 같이 참조 관계가 바람직, 유연하고 간명한 모델

결론

• 명확한 엔터티 정의 후, 종속/참조 관계를 도출 해보자.

5.7. 식별(Identifying) 관계와 비식별(Non-Identifying) 관계

• 종속- 참조 관계, 엔터티의 정의(자립- 종속)와 연관 되어 있음
  • 종속- 참조 관계는 식별- 비식별 관계를 선택하는 기준이 됨 (전략적 선택도 있음)

관계 타입(Relationship Type)	식별(Identifying) 관계	비식별(Non-Identifying) 관계
상위(부모) 엔터티의 주 식별자를 하위(자식) 엔터티의	주 식별자에 포함	일반 속성에 포함
예제

식별 관계

• 업무 요건을 명확하게 표현하고 관리 (종속 관계)
• 주 식별자를 인덱스로 사용 가능

결론

5.8. 종속- 참조 관계 그리고 식별- 비식별 관계

• 상위(부모) 엔터티의 주 식별자를 하위(자식) 엔터티에 어떻게 상속하지? (식별자/참조속성)
  • 일반적인 원칙은 5.7 의 결론과 같다

• 종속- 참조 관계 와 식별- 비식별 관계는 연관성은 있지만, 같은 개념은 아니다.

종속 관계면서 식별 관계

• 속성은 엔터티에 속해 있다. (엔터티 없이는 속성이 존재하지 않는다.)
• 부모 엔터티에 존재 종속(Existence Dependency)된 종속 엔터티는 대부분 식별 관계로 상속 받는다.
  • 단점 : 변화에 취약함, 하위(자식) 엔터티의 주 식별자가 복잡해짐

종속 관계면서 비식별 관계

• 요건이 변경될 가능성이 있거나, 복합 주 식별자가 바람직하지 않을 때 사용
• 속성 엔터티는 엔터티번호를 속성으로 내리고(Nullable?), 인조 식별자 (#속성번호) 사용
• 엔터티 관계를 전략적으로 약 결합(Loosely Coupled) 상태로 만든 모델 (유연함)

참조 관계면서 비식별 관계

• 부서가 없더라도 사원은 존재 가능
• 사원 엔터티의 주 식별자는 인조 식별자 혹은 자신의 업무 식별자로 구성

참조 관계면서 식별 관계

• 매우 드물고, 보통 잘못 설계한 모델
• 사원 엔터티의 주 식별자가 모호해짐, 소속부서 변경시 관리 어려움, 하위 엔터티 영향도

결론

• 위의 네가지 유형을 기준으로 결정
  • 기본 : 종속 관계는 식별 관계 사용, 참조 관계라면 비식별 관계를 사용
  • 주의 : 무의식적으로 상위(부모) 엔터티의 주 식별자를 하위(자식) 엔터티의 주 식별자로 상속 하는것

5.9. 식별 관계와 비식별 관계를 채택하는 예외 경우

• 예외를 모델링 전략으로 요긴하게 사용할 수 있다.
  • 주의 : 종속 관계 & 비식별 관계, 참조 관계 & 식별 관계 (특히 주의)

성능 고려

• 비식별자로 상속해서 단절된 연결을 식별자로 상속해서 연결 시키는 것

	복잡한 상속 관계	식별자로 상속	중복 관계
모델
D → A 참조 요건	C 엔터티를 거쳐야 함(쿼리 복잡함, 성능 부정적)	직접 조인(Join) 가능	직접 조인(Join) 가능

• 그림 5.22
  • B 엔터티 는 A 엔터티에 종속
  • D 엔터티 는 C 엔터티에 종속

• 그림 5.23
  • B 엔터티와 C 엔터티가 종속 관계는 아니지만 성능 요건을 위해 전략적으로 식별자로 상속
  • C, D 엔터티의 주 식별자는 혼란스러워짐, 심각한 성능 문제가 있을 때만 사용

• 그림 5.24
  • 중복(추출) 관계를 사용한 비 정규형
  • 데이터 정합성 유지 필요(C.A 값과 D.A 값의 일치)

모델 구조 고려

• 단순한 모델을 위해 종속 관계가 존재하더라도, 식별자 상속을 단절 시켜 속성으로 상속하는 전략 (그림 5.22)
  • 식별자 상속 단계가 깊어지면, 주 식별자가 복잡 해지고, 하위(자식) 엔터티가 많이 존재하는 엔터티에는 효율적이지 않다. (그림 5.23)

식별자로 상속(복잡)

비식별자로 상속(단순)

• 고객주소 엔터티의 주 식별자에 인조 식별자 적용

결론

• 성능 향상과 단순한 모델을 위해 식별자를 적절하게 상속하고 단절시키는 전략 필요 .

5.10. 참조 관계의 주 식별자를 식별 관계로 상속한 경우

• 종속 관계와 참조 관계를 분명하게 구분하지 못하면 모델이 흔들릴 수 있음

• 요건
  • 병원은 교회에서 건강 검진 수행
  • 이후 교회로 청구 하면서 검진 결과 보냄
  • 교회는 개인에게 검진 결과를 보내고, 비용을 병원에 납부

요건을 잘못 설계한 모델

• 청구와 검진결과 엔터티는 서로 다른 성격이며, 종속 관계일 수 없음

• 청구

• 검진결과

• 위는 A병원이 B교회로 출장 가서 검진한 세 명의 데이터를 청구한 케이스, 아래는 홍길동 검진 결과를 다음달 결과에 포함시킴

• 청구

• 검진결과

• 홍길동에 대한 청구 번호가 바뀜, 업무가 불편할 수 있음
  • 검진 결과를 먼저 통보하고, 청구를 나중에 한다면 청구 번호가 없어서 불가능 (청구번호 미리 채번 예외)
  • 홍길동이 몇 번 검진 받았는지 파악이 어려움

제대로 설계한 모델

• 청구와 검진결과 엔터티는 참조 관계, 데이터 성격이 반영 되었고, 유연한 모델

• 청구

• 검진결과

• 최종청구번호 속성이 업데이트 된다, 이력 데이터 관리가 필요할 수 있다

5.11. 관계 속성 & 관계 엔터티

• 데이터 생성 순서 개념
  • 하위 엔터티 속성(관계 속성)의 데이터는 상위 엔터티의 속성(주 식별자)에 존재해야 한다.

일반적인 모델

• 관계 속성이 엔터티 간에 두개 이상인 모델
• 각 관계명에 롤(Role) 이름을 사용해야 함
• 인덱스 개수가 증가 한다

관계 속성이 늘어난 일반적인 모델

• 관계 속성이 더이상 늘어나지 않는다면 사용 가능
• 더 늘어날 수 있다면 관계 엔터티(Relationship Entity)를 사용 - 연대보증인고객번호4 ... 연대보증인고객번호9 ?

관계 엔터티로 설계한 모델

• 연관 관계가 많아지거나, 그럴 가능성이 있다면 관계 엔터티로 관리 필요 - 보험계약당사자
• 관계 엔터티 사용은 가능한 정규화를 한다는 것을 의미
• 세 개 이상의 엔터티 사이의 관계 관리 : 3개체 관계(Ternary Relationship)
• 인덱스 개수가 줄어 든다, 인스턴스 개수가 증가 한다

5.12. 관계 엔터티의 특징

유연함

• 관계 엔터티의 최대 장점, 다수 관계 속성의 최대 단점
• 그림 5.23 모델에서 당사자 유형이 늘어날 때 변경 관리가 어려움, 관계 엔터티에서는 당사자구분코드에 값만 추가 하면 됨

부가 속성 관리

• 관계 엔터티도 고유의 속성을 가질 수 있다 - 신용정보활용동의여부

부가 속성이 존재하는 관계 엔터티

• 관계 속성 적용시

부가 속성이 존재하는 관계 속성

하위 엔터티 관리

• 드물지만 관계 엔터티가 하위 엔터티 가질 수 있다 - 법정대리인

관계 엔터티의 하위 엔터티가 존재하는 모델

• 관계 속성 적용시

관계 속성에 대한 하위 엔터티가 존재하는 모델

• 'a관계'는 보험계약 엔터티의 속성이 피보험자고객번호일 때만 성립한다는 업무 규칙 필요 (암호와 같은 모델)

중복 관계 관리

• 만약 성능 문제가 있다면 비정규형 고려 (단, 관계 속성 사용은 지양)

관계 엔터티 모델

• 보험계약 엔터티에 중복 관계(계약자고객)를 채택

중복 관계(계약자고객)를 사용한 모델

• • 계약자는 언제나 한명, 계약자 기준 조회가 빈번 할때 적합
  • 중복(추출) 관계를 피하기 위해 보험계약당사자 엔터티에서 계약자 제거 검토 (중복 속성 → 기초 속성)

중복 속성 관리

• 계약 당사자의 이름이 항상 같이 조회 되는 경우

중복 속성(고객명)을 사용한 모델

• 관계 속성 적용시

중복 속성(고객명)을 사용한 모델 (관계 속성)

자체 이력 관리

• 자체적으로 이력 관리 가능, 별도 이력 엔터티 관리 가능

이력 데이터를 관리하는 관계 엔터티

• 상대적으로 쿼리가 단순 해진다

-- 홍길동(고객번호='123')과 관련된 보험 계약 조회
SELECT *
  FROM 보험계약당사자
 WHERE 고객번호 = '123'
--   AND 당사자구분코드 = :V1

• 관계 속성 적용시

관계 속성을 관리하는 엔터티에 대한 이력 모델

• 조회시 많은 OR 조건으로 성능 비효율 발생 가능

-- 홍길동(고객번호='123')과 관련된 보험 계약 조회
SELECT *
  FROM 보험계약
 WHERE 계약자고객번호 = '123'
    OR 피보험자고객번호 = '123'
    OR 피보험자고객번호2 = '123'
    OR 연대보증인고객번호 = '123'
    OR 연대보증인고객번호2 = '123'
    OR 연대보증인고객번호3 = '123';

5.13. 관계 엔터티 선택 기준

• 관계 엔터티는 원칙과 기준을 바탕으로 신중하게 적용 필요

관계가 늘어날 가능성

• 관계 속성의 개수와 관계 속성이 늘어날 가능성 확인
  • 관계 속성도 적고, 변경 가능성이 없다면 관계 속성이 효율적일 수 있음
  • 보통은 성능 문제가 없는 한 관계 엔터티가 효율적

관계 속성을 사용한 모델

• 보험료 납부자, 공동 계약자와 같은 다른 관계 추가시 변경 관리 어려움

관계 엔터티를 사용한 모델

• 관계가 늘어날 가능성이 있다면 관계 엔터티 적용

조회 요건

• 중요한 화면의 구성(성능 고려)에 따라 고려
  • 성능에 문제가 없다면 어떤 경우에도 관계 엔터티 사용

• 복수의 보험계약 당사자를
  • 로우 형식으로 보여줌 : 관계 엔터티 적용
  • 컬럼 형식으로 보여줌 : 관계 속성 적용

결론

• 대부분의 온라인 처리(OLTP) 화면은 성능 이슈 보다 확장성에 초점을 맞춤 - 관계 엔터티 우선
• 이력 관리가 핵심 요건일 경우 - 관계 엔터티 우선
• 관계 엔터티에서 별도 속성을 관리 하거나 하위 엔터티가 존재할 때 - 관계 엔터티 우선

5.14. 관계선의 구성 요소

카디널러티(Cardinality)

• 하나의 인스턴스와 관계있는 상대 인스턴스의 개수를 의미
• 새 발(Crow's Foot)로 표시

옵셔널러티(Optionality)

• 하나의 인스턴스와 관계있는 상대 인스턴스의 존재(Existence) 여부를 의미
• 반드시 존재 하거나(Mandatory) 존재하지 않거나(Optional)를 의미

관계 타입(Relationship Type)

• 식별- 비식별 관계 상속 구분

관계 디그리(Relationship Degree)

• 관계선과 연관된 엔터티의 개수
  • 보통 두개, 간혹 세개도 있음

관계명(Relationship Name)

• 모델의 가독성을 높이기 위해서 사용
  • 직관적으로 알 수 있는 경우 생략

5.15. 관계 구성 요소 - 카디널러티(Cardinality)

• 상위(부모) 엔터티의 한 개의 인스턴스가 하위(자식) 엔터티의 몇 개의 인스턴스와 연관이 있는지를 의미
• 관계 분석시 '몇대몇' 이라고 하는, 관계선 표현의 가장 기본 요소
  • 종류 : 일대일(1:1), 일대다(1:M), 다대다(M:M)

일대일(1:1) 관계

• 상위(부모) - 하위(자식) 엔터티의 인스턴스가 최대 하나씩 연관 됨

• 업무 요건, 성능/모델 관리 측면에서 일대일 관계가 나타남

일대다(1:M) 관계

• 상위(부모) - 하위(자식) 엔터티의 인스턴스가 최소 하나씩 연관 됨
• 카디널러티 끝에 숫자(최대 개수, 고정 개수)를 표시 - CASE 툴 표현, 데이터베이스 구현 문제

• 부서에 여러 사원이 존재, 한 사원은 하나의 부서에 소속

다대다(M:M) 관계

• 학생은 여러 강좌를 수강, 한 강좌는 여러 학생이 수강

• 논리적으로(업무적으로) 많이 발생
• 개념(초기 논리)모델링 단계에서 많이 발생
  • 최종 물리 모델에서는 구현 불가 - 다대다(M:M) 관계는 두개의 일대다(1:M) 관계로 변경 (교차 엔터티)

결론

• 대부분(90% 이상) 카디널러티는 일대다(1:M) 관계임
• 실제 모델에서는 성능/관리 목적으로 엔터티 분리하는 경우로 일대일(1:1) 관계도 많음

5.16. 카디널러티 분석 방법

• 보통 카디널러티와 옵셔널러티를 한번에 분석

• 주의사항
  • 특정 시점을 기준으로 하지 않는다 (카디널러티는 발생할 수 있는 가능성을 의미),
  • 이력 데이터가 아닌 원천 데이터만을 대상으로 한다

일대일 카디널러티로 설계한 모델

• 부서의 관리 사원이 나중에 추가될 수 있는 요건 - 카디널러티 오판

일대다 카디널러티로 설계한 모델

• 부서관리사원 릴레이션

• 2035년 개발부 관리 사원 추가 - 설계시 업무 요건 고려 필요

부서관계사원 관계가 일대다인 모델

• 관리사원이 바뀔 수 있다는 이유로 일대다(1:M) 카디널러티로 설계 하면 안됨
• 일대일(1:1) 카디널러티에서 업데이트 처리 가능

• 부서관리사원 릴레이션

• 원천 데이터를 대상으로 카디널러티 분석 필요 - 일대일(1:1)
  • 한 사원은 하나의 부서에 대해 관리사원이 될 수 있다
• 이력 데이터까지 포함하면 카디널러티가 일대다(1:M)가 될 수도 있음
  • 업무는 일대일(1:1), 데이터는 일대다(1:M) 구성
  • 이력 데이터가 포함되면 카디널러티는 단계가 하나씩 올라간다 (일대일 → 일대다 → 다대다)

5.17. 관계 구성 요소 - 옵셔널러티(Optionality)

• 관계선에서 양쪽의 '○' 표시에 해당, 카디널러티와 함께 새발(Crow's Foot)로 표현 됨
• 하위(자식) 엔터티의 인스턴스와 연관되는 상위(부모) 엔터티의 인스턴스가 반드시 존재해야 하는지(Mandatory), 존재하지 않아도 되는지(Optional)를 의미
  • 상위(부모), 하위(자식 엔터티 각각 입장에서 판별

• 옵셔널러티는 존재(Existence) 여부를 의미 → 카디널러티(Cardinality)에 포함된 개념
  • 최소 개수가 0 이면 선택(Optional) 관계
  • 최소 개수가 1 이면 필수(Mandatory) 관계

옵셔널러티가 선택인 모형

• 사원 집합에 대한 부서 집합의 옵셔널러티는 선택(Optional) 임 - 강길동(임시부)
• 부서 집합에 대한 사원 집합의 옵셔널러티는 필수(Mandatory) 임

5.18. 상위 엔터티의 옵셔널러티

• 상위 엔터티의 옵셔널러티가 선택적(Optional)이라면 업무 규칙이 없는 것과 같음.
  • 엔터티가 제대로 도출된 것인지 검토
  • 업무 규칙이 관계선에 제대로 반영 되었는지 검토

관계선 양쪽의 옵셔널러티가 선택인 모형

• 고객에 통장이 발급되면 통장 엔터티의 고객번호 등의 속성이 업데이트
• 고객 엔터티와 관계 없는 외부고객에 발급된 통장을 포함 → 정확하지 못한 설계
  • 통장 엔터티 쪽의 옵셔널러티가 선택(Optional) : 기존 고객에 발급 되기 전, 외부 고객에 발급 된 후

• 고객

• 통장

• 통장 릴레이션의 '234' 고객이 고객 릴레이션에 없음 : 관계가 깨진 릴레이션 (?)
• 고객 릴레이션의 '126' 고객은 통장 릴레이션에 없음 : 옵셔널러티가 선택

• 양쪽 엔터티의 옵셔널러티가 선택(Optional)인 관계선은 관계가 없는 거와 같음
  • 관계선 삭제 보다는 상위(부모) 엔터티의 옵셔널러티를 필수(Mandatory)가 되도록 수정

상위 엔터티 쪽 선택 옵셔널러티 제거

• 고객- 외부고객 엔터티의 옵셔널러티가 선택(Optional)로 보임 - 배타 관계, 두 엔터티를 합치면 옵셔널러티가 필수(Mandatory)가 됨
• 고객- 외부고객 엔터티는 통합 대상 - 유사 성격, 배타 관계 해소

위의 모델을 정제

• 통장 쪽 옵셔널러티 명확화 - 발급 전 통장은 고객과 관계 없음
• 고객- 외부고객 엔터티 통합

• 프로세스에 따라 엔터티를 생성하지 않는 것이 원칙이나, 프로세스에 따라 관리하는 속성(데이터 성격)이 많이 달라지면 별도 엔터티(통장- 고객통장)로 관리

5.19. 카디널러티 & 옵셔널러티 표기법

• 다대다(M:M) 관계 제외
• 카디널러티
  • 상위 엔터티 : 0, 1
  • 하위 엔터티 : 0, 1, M
  • 최소 0 - 선택(Optional)
  • 최소 1 - 필수(Mandatory)

예제 모델

예제1

• 일대일 관계 : 조립이 안된 보드 포함

예제2

• 일대일 관계 : 조립된 보드만 관리
• 데이터 발생시 하나의 트랜잭션은 아님

예제3

• 가장 일반적인 관계선
  • 일대일 관계는 드물고 상위 엔터티 옵셔널러티는 필수, 하위 엔터티 옵셔널러티는 선택인 관계가 많다.

예제4

• 여러개 상품 혹은 한개 상품 주문 가능 (최소 한개 상품 필요)

예제7

• 하위(자식) 엔터티에 존재하는 데이터가 상위(부모) 엔터티에 존재하지 않을 수 있음

• 부서

• 사원

• '인사부' 에 소속된 사원이 없음, '강길동' 이 소속된 부서(999)는 없음
• 참조 무결성 제약 생성 불가, 의미 없는 관계

• 해결책1 - 부서 릴레이션에 부서(999) 등록 하고 옵셔널러티를 필수(Mandatory)로 변경
  • 한두 개의 예외 경우일 경우

• 부서

• 사원

• 해결책2 - 별도 엔터티 추가하고 배타 관계 적용
  • 예외를 집합으로 둘 정도로 많을 때

• 기타부서 엔터티에 부서(999) 등록
  • 부서- 기타부서 각각은 옵셔널러티가 선택(Optional) 이지만 합치면 필수(Mandatory)가 됨

• 그림 5.68 의 사원 릴레이션의 부서번호 속성에 Null 허용하지 않는 경우 모델

5.20. 관계 구성 요소 - 관계 디그리(Relationship Degree)

• 관계(Relationship)와 연관된 엔터티의 개수를 의미

• 한과목 - 여러 교수, 한학생 - 여러 과목, 한학생 - 여러 교수

• 3개체 관계도 다대다(M:M) 해소 처럼 관계 엔터티(수강신청)가 발생
• 관계 엔터티의 속성(신청일자)은 주 식별자 조합에 의해 유일하게 결정 됨

결론

• 요건에 의한 3개체 관계는 복잡하지만 정당하며 효율적이고 바람직 함