DAY 76. DB - 물리적 모델링

 

물리적 모델링

논리적 설계 단계에서 표현된 데이터(ERD)를 실제 컴퓨터의 저장장치에 어떻게 표현할 것인가

( 관계형 데이터 베이스로 전환 )

어떤 DBMS를 사용할 것인지를 고려한다.

최종적인 ERD가 그려졌다면 실제 DB를 구축하기 전에 하는 모델링이다.

 

논리적 DB 설계 (데이터 모델링) —> DBMS의 종류나 제품에 상관없이 진행한다. (why? ERD는 어떤 데이터베이스를 사용해도 적용 가능) 물리적 DB 설계 —> 특정 DBMS를 전제로 진행한다. (적용할 DBMS의 특성을 고려한다.)

 

< 물리 모델링 과정 >

1.  사용자 DBMS 결정 (ex. 오라클, Mysql ...)
2.  데이터 타입 크기 결정 및 업무 분석
3.  반정규화
4.  무결정 제약조건 정의
5.  뷰, 인덱스 정의
6.  데이터 베이스 생성

 

논리적모델링과 물리적모델링

 

 

---

 

반정규화(De-Nomalization)

• 정규화 작업(삽입, 삭제, 갱신 이상을 방지)이 완료된 후 데이터 물리 모델링 과정 중 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화 추구를 위해 진행하는 작업이다.
• 중복은 감수하고 데이터베이스의 성능을 향상시키는 것 (특히, 검색 속도를 향상 시킨다.)
• 정규화를 통한 데이터의 무결성 유지도 중요하지만, 다수의 사용자가 동시에 이용하는 환경에서는 일정 성능을 유지하는 것도 매우 중요하기 때문이다.
• 이전 과정에서 정교하게 쪼개놓은 테이블들을 중복을 감수하고도 데이터베이스의 조회 경우가 많다면, 그것에 초점을 맞춘 작업(테이블 join 등)

CASE 1 - 엔티티 통합

항상 혹은 대부분 조인에 의한 검색을 하고, 검색이 빈번히 이루어지는 두 개의 엔티티를 대상으로 통합한다.

중복이 발생할 수 있지만 애플리케이션으로 해결이 가능하게 하는 대안이 필요하다.

CASE 2 - 수직분할에 의한 반정규화

엔티티의 튜플 수 및 속성의 수가 매우 많고, 엔티티의 속성들이 그룹화되어 각 그룹이 특정 부서 혹은 응용 프로그램에 의해서만 사용될 때 한다.

1:1 관계로 만들어야 한다.

CASE 3- 수평 분할에 의한 반정규화

한 테이블 내에서 튜플의 조회 빈도에 따라 엔티티를 분할한다.

 

---

 

아크관계(Arc relationship)

어떤 엔티티가 두 개 이상의 다른 엔티티의 합집합과 관계를 가지는 것 (a.k.a 배타적(Exclusive) 관계)

동일한 관계가 서로 다른 하나 이상의 엔티티와 배타적으로 관계를 갖고 있을 때 이를 하나로 통합함으로써 발생하게 된다.

공통적인 것을 모아 <슈퍼타입> 즉, 부모 엔티티로 놓고 이와 연결된 <서브타입> 엔티티들이 있다.

 

◾ 슈퍼타입 통합 테이블로 통합

서브타입에 있는 모든 컬럼을 슈퍼타입에 하나로 통합하고 각각의 서브타입 정보를 구분하기 위한 구분 컬럼이 필요하다.

 

• [ 장점 ]

1. SELECT 할 때 JOIN이 필요없다.
2. VIEW를 활용해 각 서브타입 조회 및 수정이 가능하다.
3. 서브타입 구분없는 데이터 접근이 간편하다.

• [ 단점 ]

1. 테이블의 컬럼 수가 증가된다.
2. 처리할 때마다 서브타입의 구분이 필요해진다.
3. 특정한 서브타입을 NOT NULL 제한할 수 없다.

 

◾ 각 서브타입 테이블로 변환

각 서브타입 컬럼에 슈퍼타입에 있는 모든 속성을 포함하도록 구성한다.

 

• [ 장점 ]

1. 처리시마다 서브타입의 유형 구분할 필요가 없다.
2. 단위 테이블의 크기 감소
3. 불필요한 컬럼 줄어든다.

• [ 단점 ]

1. 전체적인 데이터를 처리하는 경우 JOIN 불가, UNION만 가능하다.
2. 여러 테이블을 합친 VIEW 조회만 가능하다. 유지관리가 어렵다.
3. 복잡한 SQL 통합이 어렵다.

 

◾ 슈퍼타입, 서브타입을 각 테이블을 변환하고 관계를 설정

슈퍼타입 테이블과 서브타입 테이블 간에 필수 혹은 선택의 관계로 구성한다.

 

• [ 장점 ]

1. 저장 공간이 상대적으로 적다.
2. 서브타입에 해당하는 속성 정보만 조회하는 경우 SQL 작성이 용이하다. ⇒ 공통 속성인 슈퍼타입과 각 서브타입의 속성을 구분하기 용이하다.
3. 서브 타입의 컬럼 수가 많은 경우 유리하다. ⇒ 통합할 필요가 없어지기 때문에

• [ 단점 ]

1. 슈퍼타입의 속성과 서브타입의 정보를 같이 처리하려면 항상 JOIN 작업이 발생하여 성능이 저하된다.
2. 관리해야 할 테이블의 객체가 많아지기 때문에 테이블 구조 변경이 어렵다. ⇒ Merge, Migration 등의 개선 작업이 어렵다.