01_ 관계형 테이블로 전환
  & 논리적 데이터 모델링을 통해 산출한 ERD를 테이블 관계도로 전환
  & 케이스툴(논리 모델 => 물리 모델)
  & 변환 항목
    ◎ 엔티티타입은 테이블로 전환한다. (엔티티타입:테이블 => 1:1, N:1, 1:N)
    ◎ 주식별자는 PK로 변환하다.
    ◎ 속성은 컬럼으로 변환한다.
    ◎ 관계에 의한 외부 식별자는 FK로 변환한다.

#엔티티타입을 테이블로 전환한다

(1) 독립 엔티티타입은 독립 테이블로 전환된다

[그림 7-2] 독립 엔티티타입은 독립 테이블로

독립 엔티티타입의 주식별자는 스스로 발생되었으며, 다른 엔티티타입 때문에 발생되지 않음, 따라서 위의 예에서 사원 엔티티타입의 주식별자인 사원번호는 테이블에서 PK가 된다.

(2) 완전 종속 엔티티타입은 완전 종속 테이블로 전환된다

[그림 7-3] 완전 종속 엔티티타입은 완전 종속 테이블로

완전 종속 엔티티타입의 주식별자는 자신의 부모 엔티티타입으로부터 상속받은 주식별자가 반드시 존재해야 한다, 위의 예에서 발령 엔티티타입의 주식별자는 사원번호+발령시작일자가 되며, 이와 같은 PK를 복합키(Composit Key)라고 한다.

(3) 부분 종속 엔티티타입은 부분 종속 테이블로 전환된다

[그림 7-4] 부분 종속 엔티티타입은 부분 종속 테이블로

부분 종속 엔티티타입의 주식별자는 스스로 생성되지만, 자신의 일반 속성은 부모 엔티티타입에서 상속받아 발생된다, 위의 예에서 부서 엔티티타입의 주식별자는 부서번호이며, 사원 엔티티타입의 주식별자는 사원번호이며 상속받은 부서번호는 주식별자를 구성하지 않는다.

#주식별자를 PK로 전환한다

& 엔티티타입의 주식별자는 테이블의 PK로 전환된다.
& PK는 각 로우(Row)를 유일하게(Unique) 할 뿐 아니라, 다른 테이블과의 관계에 의해 무결성 제약을 유지시키는 역할을 수행

(1) 데이터 모델의 주식별자는 PK로 전환된다

주식별자는 업무적으로 의미있는 속성이거나, 인공적으로 생성한 속성이거나와 관계 없이 PK가 된다

(2) 무결성 제약(Referential Integrity)을 유지하는 역할을 한다

[그림 7-5] PK는 무결성 제약을 유지시킨다

테이블의 PK는 다른 테이블과의 관게에서 무결성 제약 조건에 참여하는 역할을 수행한다, 위의 예에서 자신의(사원) 테이블에게 영향을 주는 상대(부서) 테이블의 PK(부서번호)가 포함 된다.

(3) PK는 테이블에 있는 각각의 로우(Row)를 유일하게 식별한다

일반적으로 PK를 지정하여 각각의 로우(Row)를 유일하게 식별할 수 있도록 하지만, 테이블간 참조가 없다면 Unique Index만 지정 할 수 있다. PK 이외에도 대체키(Alternate Key)가 있을 수도 있으며, 이는 테이블에서 Unique Index 대상이 된다.

(4) PK는 Null 값을 갖지 않는다

[그림 7-6] PK의 Null 처리

PK는 해당 테이블에 있는 각각의 로우를 대표하므로 Null 값을 갖지 않는다, 엔티티 통합한 경우 Null 대신 기본값을 지정 해서 사용한다, 오라클 에서는 Nullable 컬럼도 PK 를 생성하면 자동으로 Not Null 로 바뀐다, 위의 예에서 하나로 통합된 배송요청 엔티티타입의 경우 부서에서 배송 요청을 할경우 사원번호 컬럼에 Null 값이 발생하지 않도록 기본값을 지정해야 한다.

(5) PK는 변경되지 않는다

설사 PK 수정 업무가 있더라도, 실제로는 PK 삭제→생성 이다.

(6) 가능하면 모든 테이블에서 PK를 정의한다

PK 가 없으면 FK 를 생성할 수 없다, 데이터의 참조 무결성을 보장하기 위해 가급적 모든 테이블에 PK를 생성한다.

#관계에 의한 외부 식별자는 FK로 변환된다

& 관계는 1:1, 1:M, M:N 로 구분되며, 주식별자에 영향을 주는가의 여부에 따라 주식별자 관계(Identifying Relationship)와 비식별자 관계(Non-Identifying Relationship)가 있을 수 있다.

(1) 1:1 주식별자 관계 변환

[그림 7-7] 1:1 주식별자 관계를 테이블로

위의 예는 청구가 존재해야 출급이 존재할 수 있다는 업무 규칙이 있는 경우이며 (관계도 실선), 청구.청구번호 가 출급 테이블의 PK (출급.출급번호)로 이용 되었다. FK 제약이 없을경우 데이터의 참조 무결성을 보장할 수 없다.

(2) 1:1 비식별자 관계 변환

[그림 7-8] 1:1 비식별자 관계를 테이블로

위의 예는 청구가 반드시 존재할 필요가 없는 업무 규칙이 있는 경우이며 (관계도 점선), 청구.청구번호 가 출급 테이블의 일반 컬럼 (출급.청구번호)로 이용 되었다, 출급.청구번호가 Null 이 아니라면 반드시 청구 테이블에 존재하는지 확인해야 한다.

(3) 1:M 관계 변환

[그림 7-9] 1:M 주식별자 관계를 테이블로

1:1 주식별자 관계 처럼 자식 PK가 영향을 받으나, 자식 테이블의 PK 컬럼 개수가 반드시 더 많아야 한다. (주문.주문번호, 주문목록.{주문번호(FK),제품번호})

(4) 자기 참조 관계 변환

[그림 7-10] 자기 참조 관계를 테이블로

자신의 테이블에 자신의 PK 영역이, 일반 컬럼의 FK 영역으로 포함하는 모습으로 나타난다.

(5) 슈퍼타입/서브타입 관계 변환

& 실전 프로젝트에서는 슈퍼타입 서브타입 모델링을 많이 활용함, 모델 결정은 슈퍼타입과 서브타입의 데이터 특징(트랜잭션의 성격과 양)에 따라 결정 해야 함.

[그림 7-11] 슈퍼타입/서브타입 관계를 테이블로

논리 모델링에서 자주 이용되는 모델링 방법
① 각각의 테이블로 변환

[그림 7-12] 슈퍼타입/서브타입 관계-개별 테이블로 변환

[그림 7-13] 슈퍼타입/서브타입 관계-개별 테이블로 변환

슈퍼타입 테이블과 서브타입 테이블간에 모두 1:1 주식별자 관계에 의해 접수번호가 생성 되었으며, 접수.접수종류코드 를 통해서 접수 테이블의 각각의 레코드가 어느 서브타입 테이블과 연관되는지 구분한다.
속도↑, 슈퍼타입정보조회SQL작성↑, 저장공간↓, 참조무결성규칙적용↑, 슈퍼타입+서브타입정보조회SQL작성/성능↓

② 서브타입 테이블로 변환

[그림 7-14] 슈퍼타입/서브타입 관계-각 서브타입 테이블로 변환

[그림 7-15] 슈퍼타입/서브타입 관계-각 서브타입 테이블로 변환(1:1 관계)

서브타입별 구분자불필요, 부모 테이블과 조인 불필요, 풀 스캔 유리, 참조무결성규칙적용 가능, 서브타입 동시 활용 SQL 작성 어려움/성능저하, 서브타입별로 구분하여 처리하는 업무가 많을 경우 권장

③ 통합 테이블로 변환

[그림 7-16] 슈퍼타입/서브타입 관계-통합 테이블로 변환

[그림 7-17] 슈퍼타입/서브타입 관계-통합 테이블로 변환

서브타입의 모든 컬럼을 슈퍼타입에 하나로 통합하여 테이블로 구성, 서브타입별 구분자필요, 데이터 조회/SQL 구성 편리, 조인 없음, 서브타입별로 구분하지 않고 처리하는 업무가 많을 경우 권장, 서브타입별 컬럼 형식이 상이함으로 인해 제약조건 설정 어려움(Not Null)