7.1 관계형 테이블로 전환

1) 논리ERD와 테이블관계도는 1:1이 아니다.

• 하나의 엔티티타입이 두개 이상의 테이블로 전환(세분화)되기도 하고 두개 이상의 엔티티가 하나의 테이블로 전환(통합화)되기도 한다. 또한 반정규화를 통해 엔티티타입에는 없던 속성이 테이블에서 칼럼으로 추가되기도 한다.

2) 테이블관계도 변환항목

• 엔티티타입은 테이블로 전환한다.
• 주식별자는 PK로 변환한다.
• 속성은 칼럼으로 변환한다.
• 관계에 의한 외부식별자는 FK로 변환한다.

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

독립 엔티티타입은 독립 테이블로 전환된다.

• 1)독립 엔티티타입이란 다른 엔티티타입과의 관계에 의해 생성되지 않고 독립적으로 생성되며 주로 업무에 원래부터 존재하는 정보이다
• EX)부서,사원,고객
• 2)엔티티타입 분류에 따르면 기본 엔티티타입이 이에 속한다.
• 3)엔티티타입의 주식별자가 PK가 되며 속성은 칼럼이 된다. PK와 칼럼은 다른 테이블과의 관계에 의해 생성된 것이 아니라 스스로 가지고 있는 정보이다
• 4)252페이지 <그림7-2> 참조

완전 종속 엔티티타입은 완전 종속 테이블로 전환한다.

• 1)완전종속 엔티티타입의 주식별자는 부모 엔티티타입으로 부터 상속받아 발생한다.
• 2)<사원>과 <발령> 엔티티타입을 볼 때 <발령>은 어떤 사원이 발령을 받을 때마다 어커런스가 생성되므로 결국 사원번호+발령일자를 식별자로 가지며 여기서 사원번호는 부모인 <사원>으로 부터 상속받은 것이다.
• 3)부모의 식별자가 자식의 식별자의 일부가 되므로 식별자관계가 된다.
• 4)253페이지 <그림7-3> 참조

부분 종속 엔티티타입은 부분 종속 테이블로 전환한다.

• 1)부분 종속 엔티티타입의 주식별자는 스스로 생성되지만 자신의 일반 속성중 일부는 부모엔티티타입에서 상속받아 발생된다.
• 2)<부서>와 <사원> 엔티티타입을 볼 때 <사원>에 소속부서라는 속성이 있을 경우 이 소속부서는 <부서>엔티티타입에서 상속받은 것이다.
• 3)부모의 식별자가 자식의 일반속성이 되므로 비식별자관계가 된다.
• 4)254페이지 <그림7-4> 참조

7.1.2 주식별자를 PK로 전환한다.

주식별자가 전환된 PK의 역할은 다음과 같다.

• 1) 무결성 제약유지:<사원>테이블에 <부서>테이블의 PK인 부서코드가 칼럼으로 있다면 <부서>테이블에 없는 부서코드를 가진 사원의 존재할 수 없게된다
• 2) PK는 테이블에 있는 각 로우를 유일하게 식별한다.
• 3) PK는 NULL값을 가질 수 없다.(PK가 NULL일 경우 2번의 역할을 하지 못하게 될 것이다)
• 4) PK는 기본적으로 UPDATE를 허용하지 않는다. UPDATE보다는 DELETE/INSERT 과정을 거치는 것이 좋다.
• 5) 가능하면 모든 테이블에는 PK를 정의하는 것이 좋다.

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

1:1 주식별자 관계변환

• 1)주는 쪽의 PK가 받는 쪽의 FK가 되면서 또한 PK가 되는 경우이다
• 2)하나의 청구에 대해 하나의 출금이 발생한다면 청구의 PK인 청구번호가 출금의 PK인 출금번호와 동일하게 된다
• 3)출금을 하기 위해서는 반드시 청구쪽에 해당 데이타가 있어야 하며 청구쪽 데이타를 삭제하려는 경우 출금에 데이타가 있는지 확인하여 있다면 출금 데이타를 삭제하고 난 후에야 청구데이타를 삭제할 수 있다.
• 4)257페이지 그림7-7 참조

1:1 비식별자 관계변환

• 1)주는 쪽의 PK가 받는 쪽의 FK지만 PK는 되지 못하고 일반칼럼이 되는 경우이다.
• 2)위에서 든 예에서 만일 출금이 청구요청이 없어도 이루어지는 경우라면 <청구>,<출금> 양쪽 모두가 선택관계가 되어 비식별자관계가 된다.
• 3)그러나 삭제시
  • 청구데이타를 삭제시 출금에 데이타가 있다면 출금쪽도 지워야 한다.
  • 출금데이타 삭제시 청구에 데이타가 있다면 청구쪽도 지워야 한다.
• 4)258페이지 그림7-8참조

1:M 관계변환

• 1)1:M의 경우도 주식별자,비식별자 관계가 존재한다.
• 2)주식별자관계일 경우 주는 쪽의 PK가 받는 쪽의 PK의 일부를 구성하게 된다. 즉 받는 쪽에선 받은 칼럼외에 또 다른 칼럼이 있어야 PK를 구성할 수 있게 된다.
• 3)258페이지 그림7-9참조

자기참조 관계변환

• 1)하나의 (상위)메뉴에는 하위메뉴가 없을 수도,1개일 수도,여러개일 수도 있다(해당 메뉴가 최하위메뉴라면 하위메뉴가 없을 것이다)
• 2)하나의 (하위)메뉴에는 상위메뉴가 없을 수도 있고 만일 있다면 반드시 1개가 있다(해당 메뉴가 최상위메뉴라면 상위메뉴가 없을 것이다)
• (?) 잠깐질문-만일 FK로 상위메뉴 대신 하위메뉴가 칼럼으로 있다면 어떻게 될까?
• 하위메뉴가 FK로 잡혀 있다면 PK인 메뉴ID는 상위메뉴라는 의미다. 하나의 상위메뉴에는 복수개의 하위메뉴가 존재할 수 있으므로 결국 같은 PK가 여러개 존재하는 상황이 발생하게 된다. 이것은 1:다의 관계에 있는 별개의 엔티티타입을 하나의 엔티티타입으로 묶어서 발생한 문제로 제 1 정규화의 대상이 된다

수퍼타입-서브타입 관계변환

1)각각의 테이블로 변환

• 수퍼타입과 서브타입간에는 1:1 주식별자관계로 정립된다
• 수퍼타입의 접수종류코드에 의해 수퍼타입의 로우가 어느 서브타입과 연결되는지가 결정된다
• 수퍼타입에 있는 하나의 로우의 상대 어커런스는 <인터넷접수>,<방문접수>,<전화접수> 셋중에 하나의 테이블에만 존재하게 되므로 서브타입쪽에 O가 나타난다

장점

• 칼럼의 중복이 없으므로 저장공간이 절약된다
• 관계에 의해 발생하는 복잡한 참조무결성 규칙을 적용할 수 있다
• 각각의 테이블로 처리할 경우 수행속도가 좋으며 수퍼타입에 속한 정보만 조회하는 경우 문장작성이 용이하다

단점

• 수퍼타입과 서브타입의 정보를 같이 처리할 경우 항상 조인이 발생하여 성능이 저하될 수 있다
• 전체 테이블에 대한 통합조회가 많이 필요한 경우 과다한 조인으로 쿼리문이 복잡해진다
• EX)특정 접수일자에 발생한 접수를 찾는 경우 접수종류가 어느 타입에 속할지 알 수 없으므로 세개의 서브타입을 뷰로 만들어 수퍼타입과 조인해야한다

2)서브타입 테이블로 변환

• 서브타입 칼럼에 수퍼타입에 있는 모든 속성을 포함하도록 구성한 경우이다
• 각각의 서브타입간에는 관계가 존재하지 않으며 로우가 서브타입별로 존재하므로 구분칼럼이 필요없다

장점

• 수퍼타입의 칼럼을 상속한 서브타입을 각각의 테이블로 변환시킨다. 따라서 구분자 칼럼이 필요없게 된다
• 정보를 서브타입별로 조회하는 경우 칼럼을 명확하게 구분하여 가져올 수 있다
• 테이블 풀스캔의 경우 유리하다(?)
• 다른 테이블과 관계에 대해 복잡한 참조 무결성 관계를 유지할 수 있다(?)
• 칼럼에 대한 NOT NULL,기본값 지정이 가능하다(?)

단점

• 서브타입을 동시에 이용하는 경우 쿼리문 작성이 어렵고 조인발생으로 인해 성능이 저하될 수 있다
• 서브타입을 묶어서 하나의 데이터 범위에서 부분처리를 해야 하는 경우에는 처리가 복잡하거나 불가능할 수 있다
• 즉, 업무처리시 서브타입별로 구분하여 처리하는 경우는 편리하나 통합하여 처리하는 경우는 권장되지 않는다

3)통합 테이블로 변환

• 서브타입에 있는 모든 칼럼을 수퍼타입에 하나로 통합하여 테이블로 만든다.
• 수퍼타입에 모든 서브타입의 정보가 있으므로 서브타입을 구분하기 위한 칼럼이 필요하다(접수구분종류)

장점

• 데이타조회가 간편하며 쿼리문이 단순해진다
• 여러 테이블을 조인하지 않아도 되므로 수행속도가 좋아진다
• 서브타입을 구분하지 않고 데이타를 조회할 경우 처리가 용이한다

단점

• 칼럼수가 증가하여 디스크 저장공간이 증가될 수 있다(해당 서브타입에 없는 칼럼은 NULL이 되므로 VARCHAR 타입 사용시 예외)
• 항상 구분자에 의해 로우를 구분하는 작업이 필요하다
• 테이블 인덱스를 사용할 경우 서브타입별 로우의 수보다 많은 인덱스 로우가 존재하여 인덱스가 커지고 효율이 떨어질 수 있다
• 풀스캔시 많은 로우수때문에 성능이 떨어진다
• 다른 테이블과 서브타입별로 참조 무결성 조약이 복잡한 경우 데이타를 처리하기가 복잡하다

4) 결론

• 위에서 제시한 3가지 방법중 어느 것을 사용할 것인가는 업무에서 요구하는 데이타의 특징,즉 트랜잭션의 성격과 양에 따라 결정해야 한다
• 데이타 처리시 수퍼타입과 서브타입 전체에 대해 처리하는 경우가 많은지(3번), 개별로 처리하는 경우가 많은지(1,2번)에 따라 적절한 방식을 선택하도록 한다