정보처리기사/데이터베이스 구축

물리 데이터베이스 설계 1

RangA 2023. 5. 28. 18:10

01. 물리 데이터 모델 설계

01. 물리 데이터 모델 변환

1) 개체를 테이블로 변환

  논리적 설계(데이터 모델링)     물리적 설계  
  개체(Entity)     테이블(Table)  
  속성(Attribute)     컬럼(Column)  
  주 식별자(Primary Identifier)     기본키(Primary Key)  
  외래 식별자(Foreign Identifier)     외래키(Foreign Key)  
  1. 논리 모델에서 정의된 개체는 물리 모델에서 테이블로 변환
    • 테이블과 개체명을 동일하게 하는 것을 권장함
    • 개체명은 한글명을 사용하고, 테이블은 소스 코드의 가독성을 위해 영문명을 사용함
    • 사전에 표준화된 용어가 있을 경우 메타에 등록되어 있는 단어를 사용하여 명명함
  2. 서브 타입 변환
    • 논리 데이터 모델에서는 비즈니스나 업무를 데이터 모델로 표현하므로 최대한 상세하게 표현함
    • 일반적으로 가능한 개체 구성을 서브 타입으로 상세하게 표현함
    • 각각의 서브 타입이 독립적인 속성, 관계를 포함하는 경우 반드시 서브 타입을 사용하여 집합을 표현해야 함
    • 논리 모델링의 서브 타입은 물리 모델링에서 테이블의 형태로 설계됨
  3. 슈퍼 타입 변환
    • 서브 타입을 슈퍼 타입에 통합하여 하나의 테이블로 만드는 것을 의미
    • 서브 타입에 적은 양의 속성이나 관계를 가진 경우에 적용됨
  4. 서브 타입 기준 변환
    • 슈퍼 타입 속성들을 각각의 서브 타입에 추가하여 서브 타입마다 하나의 테이블로 만듦
    • 분할된 테이블은 해당되는 서브 타입 데이터만을 포함해야 함
    • 주로 서브 타입에 다량의 속성 및 관계가 포함된 경우 적용됨
  5. 개별 타입 기준 변환
    • 슈퍼 타입과 서브 타입 같은 관계가 아닐 때 개별 타입이라고 함
    • 슈퍼 타입과 서브 타입을 각각 테이블로 변환하는 것
    • 슈퍼 타입과 서브 타입 각각의 테이블 사이에는 1:1 관계가 형성됨
    • 전체 데이터에 대한 처리가 자주 발생하는 경우 사용함
    • 서브 타입 처리가 대부분 독립적으로 발생하는 경우 사용함
    • 통합하는 테이블의 컬럼 수가 지나치게 많은 경우 사용함
    • 서브 타입 컬럼 수가 다수인 경우 사용함
    • 트랜잭션이 주로 슈퍼 타입에서 발생하는 경우 사용함
    • 슈퍼 타입에서 범위가 넓은 처리가 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우 사용함

2) 속성을 컬럼으로 변환

  • 컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요가 없음
  • 명칭은 개발자와 사용자의 의사소통이 가능한 표준화된 약어를 사용함
  • SQL 예약어 사용을 피해야 함
  • SQL 문자의 가독성을 높이기 위해 열의 명칭은 가능한 짧게 함
  • 테이블에 컬럼을 정의한 후, 하나의 컬럼에 해당하는 샘플 데이터를 작성하여 컬럼의 정합성을 검증함
  • 컬럼의 명칭으로 복합 단어를 사용할 경우에는 미리 정의된 표준의 의해 명명함
  • 자기 참조 컬럼의 최상위는 NULL로 지정하지 않고 '*'로 지정함(인덱스 사용을 위해 지정함)
  • Default의 지정으로 코딩의 단순화와 데이터 무결성을 보장함

3) UID(Unique Identifier)를 키본키로 변환

  • UID에 해당하는 모든 속성에 대해 기본키로 선언하고, NOT NULL, UNIQUE 등의 제약조건을 추가적으로 정의함
  • 논리 모델링에서의 Primary UID는 물리 모델링의 기본키로 생성됨
  • 논리 모델링에서 정의된 Secondary UID 및 Alternate Key들은 해당 엔티티와 상대 엔티티의 선택적 관계를 갖는 데 중요한 역할을 하기 때문에 물리 모델링에서는 UNIQUE 키로 생성됨
  • DDL에서는 오브젝트가 생성되어 기본키 제약조건의 속성은 가짐
  • 외래키가 기본키에 포함될 수 있음

4) 관계를 외래키로 변환

  • "참조하는" 릴레이션에는 외래키, "참조되는" 릴레이션에는 기본키로 선언함
  • 외래키명은 기본키 이름을 그대로 사용하지만 다른 의미를 가질 경우 외래키명을 수정함
  • 순환 관계에 있는 테이블에서 자신의 기본키는 외래키로 정의됨

5) 일반 속성을 변환

  • 속성(열)의 타입(유형)이나 길이를 변환함
  • 정의된 각 열에 대해 적용 DBMS에서 제공하는 데이터 유형 중 적절한 유형을 정의하고, 해당 데이터의 최대 길이를 파악하여 길이를 설정함


02. 클러스터와 파티션 설계

1) 클러스터 설계 적용 기준

  • 분포도가 넓을수록 유리함
  • 접근 기법이 아니라 접근 효율을 향상시키기 위한 물리적인 저장 방법
  • 분포도가 넓은 테이블의 클러스터링은 저장 공간을 절약할 수 있음
  • 다중 블록 이상(일반적으로 6이상의 블록)의 테이블에 적용할 수 있음
  • 대량의 범위를 자주 접근하는 경우에 적용할 수 있음
  • 인덱스 사용 시 처리 부담이 되는 넓은 분포도에 활용할 수 있음
  • 여러 개의 테이블이 빈번하게 조인이 필요할 때 활용할 수 있음

2) 클러스터 설계

  • 지정된 컬럼 값의 순서대로 데이터 행을 저장하는 방법
  • 하나 혹은 그 이상의 테이블을 같은 클러스터 내에 저장이 가능함
  • 액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법
  • 검색 효율은 높여주나 입력, 수정, 삭제 시에 부하가 증가할 수 있음
  • 분포도가 넓을수록 오히려 유리함(인덱스의 단점을 해결)
  • 분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약이 가능함

3) 클러스터 설계 시 고려사항

  • UNION, DISTINCT, ORDER BY, GROUP BY가 빈번한 컬럼은 고려함
  • 수정이 자주 발생하지 않는 컬럼이 고려 대상
  • 처리 범위가 넓어 문제가 발생하는 경우는 단일 테이블 클러스터링을 고려함
  • 조인이 많아 문제가 발생하는 경우는 다중 테이블 클러스터링을 고려함

4) 파티션(Partition) 설계

  1. 파티션 종류
    • 범위(Range) 분할 : 지정한 컬럼 값을 기준으로 분할함
    • 해시(Hash) 분할 : 해시 함수에 따라 데이터를 분할함
    • 조합(Composite) 분할 : 범위 분할 후 해시 분할로 다시 분할함
  2. 파티션 장점
    • 데이터 접근 범위를 줄여 성능을 향상시킬 수 있음
    • 전체 데이터의 훼손 가능성이 감소되고 데이터의 가용성이 증가됨
    • 각 분할 영역을 독립적으로 백업하고 복구할 수 있음
    • 디스크 Striping으로 입출력 성능을 향상시킬 수 있음
      • 디스크 Striping : 연속된 데이터들이 여러 개의 디스크 드라이브에 물리적으로 나뉘어 기록할 수 있는 기술로, 디스크에 접근하는 디스크 컨트롤러에 대한 경쟁이 감소되므로 성능이 향상됨

5) 디스크 구성 설계

  • 정확한 용량을 산정하여 디스크 사용을 효율을 높임
  • 업무량이 집중되어 있다면 분리하여 집중되어 있는 디스크에 대한 입출력 부하를 분산함
  • 입출력 경쟁을 최소화하여 데이터의 접근 성능을 향상시킴
  • 테이블 객체를 위한 테이블 스페이스와 인덱스 객체를 위한 테이블 스페이스를 분리하여 구성함
  • 테이블 스페이스와 템포러리 스페이스를 분리하여 구성함
  • 테이블을 마스터 테이블과 트랜잭션 테이블로 분류함
  • 디스크의 구성에 따라 테이블 스페이스의 개수와 사이즈를 결정함
  • 파티션 할 테이블을 별도로 분리함
저작자표시 비영리 변경금지