[개미의 걸음 SQLD 1과목] 성능 데이터 모델링 ④ PK/FK 칼럼순서&슈퍼타입/서브타입 모델

PK[Primary Key]/FK[Foreign Key]

출처 : DBGUIDE.NET

• 기본키[Primary Key]는 하나의 테이블에서 유일성과 최소성, Not Null을 만족하면서 해당 테이블을 대표하는 것
• 외래키[Foreign Key]는 다른 테이블의 기본키를 참조(조인)하는 칼럼
       → 관계 연산 중에서 결합 연산을 하기 위해서 사용하는 것이 외래키

키의 종류	설    명
기본키 [Primary Key]	후보키 중에서 엔터티를 대표할 수 있는 주키[Primary Key] Null값을 가질 수 없음 한 릴레이션에서 특정 레코드를 유일하게 구별할 수 있는 속성 기본키로 정의된 필드(속성)에는 동일한 값이 중복되어 저장될 수 없음
외래키, 외부키 [Foreign Key]	관계를 맺고 있는 테이블 R1, R2에서 테이블 R1이 참조하고 있는 테이블 R2의 기본키와 같은 R1 테이블의 속성을 외래키라고 함 참조 무결성[Referential Integrity]을 확인하기 위해 사용되는 키 허용된 데이터 값만 데이터베이스에 저장하기 위해 사용 하나의 테이블에는 여러 개의 외래키가 존재할 수 있음 외래키로 지정된 필드에는 Null값이나 중복된 값을 입력할 수 있음

 

인덱스 특성을 고려한 PK/FK 칼럼 순서

출처 : DBGUIDE.NET

• PK/FK설계 시, 성능을 고려한 데이터베이스 설계가 될 수 있도록 설계단계 마지막에 칼럼의 순서를 조정
• 일반적으로 프로젝트에서는 PK/FK 칼럼 순서의 중요성을 잘 인지하지 못함
      → 데이터 모델링이 되어 있는 그대로 DDL을 생성할 경우, 데이터베이스 데이터처리 성능에 문제를 유발
• PK순서는 실전 프로젝트에서 매우 중요
      → 특히 물리적인 데이터 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지 항상 주의하여 표시해야 함.
      → 해당 해당테이블의 데이터를 접근할 가장 빈번하게 사용되는 유일한 인덱스(Unique Index)를 모두 자동 생성
      → 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를 지정
      → 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때, 앞쪽에 위치한 속성 값이 가급적 ‘=’ 아니면 최소한 범위 ‘BETWEEN’ ‘< >’가 들어와야 인덱스 이용 가능
  
• 데이터 모델링 때 결정한 PK순서와 다르게 DDL문장을 통해 PK순서를 다르게 생성가능
      → 대부분의 프로젝트에서는 데이터 모델의 PK 순서에 따라 그대로 PK를 생성
      → 만약 다르게 생성할 경우, 데이터 모델과 데이터베이스 테이블의 구조가 다른 것처럼 보여 유지보수가 어려움
• FK는 데이터 조회시 조인의 경로를 제공하는 역할 수행
      → FK는 반드시 인덱스 설정
      → FK는 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스를 생성

2020/12/01 - [자격증/SQLD] - [개미의 걸음 SQLD 1과목] 데이터베이스 구조① 스키마, 테이블, 뷰, 인덱스

 

 

 

슈퍼/서브타입 모델

논리적인 데이터 모델에서 이용되는 형태로 분석 단계에서 많이 쓰이는 모델

• 최근에 데이터 모델링할 때 자주 쓰이는 모델링 방법으로 Extended ER모델이라고도 함
• 업무를 구성하는 데이터를 공통점과 차이점의 특징을 고려해 효과적으로 표현 가능하여 자주 사용
      → 공통 부분을 슈퍼타입으로 모델링, 차이나는 부분을 서브타입으로 구분해 표현
• Super type와 Sub type 간의 관계는 베타적 관계와 포괄적 관계가 있음   
      ex> 고객 엔터티가 개인고객과 법인 고객으로 분류되는 경우
                Super type : 고객 엔터티
                Sub type : 개인고객, 법인고객
                베타적 관계 : 고객이 개인 고객이거나 법인고객인 경우
                포괄적 관계 : 고객이 개인 고객일 수도 있고 법인 고객일 수도 있는 경우

 

슈퍼/서브타임 데이터 모델의 변환

출처 : DBGUIDE.NET

OneToOne Type	Super Type과 Sub Type을 개별 테이블로 도출 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성 슈퍼타입이 각 서브탕비에 대해 기준역할을 하는 형식으로 사용할때 이러한 유형의 트랜잭션 발생 테이블 수가 많아서 조인이 많이 발생하고 관리가 어려움
Plus Type	Super Type과 Sub Type 테이블로 도출 슈터+서브 타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼+서브 타입 테이블로 구성 조인이 발생하고 관리가 어려움
Single Type	Super Type과 Sub Type을 하나의 테이블로 도출 테이블들을 하나로 묶었을 때 각각의 속성별로 제약사항(NULL/NOT NULL, 기본값, 체크값)을 정확하게 지정하지 못할지라도 대용량이고 성능향상이 필요하다면 하나의 테이블로 묶어서 만들어 줌. 조인 성능이 좋고 관리가 편리하지만 입출력 성능이 나쁨

• 슈퍼/서브타입에 대한 변환을 잘못하여 성능이 저하되는 경우[트랜잭션 특성을 고려하지 않고 테이블이 설계됨]
    1. 트랜잭션이 항상 전체를 일괄 처리할 때, 테이블은 서브타입렬로 개별 유지되어 변환하면 Union연산에 의해 성능이 저하될 수 있음
    2. 트랜잭션이 항상 서브타입 개별로 처리할 때, 테이블은 하나로 통합하여 변환하면 불필요하게 많은 양의 데이터가 집접되어 있어 성능이 저하될 수 있음
    3. 트랜잭션은 항상 Super type과 Sub type을 함께 처리하는데 개별로 유지하면 조인에 의해 성능이 저하됨
• 성능이 중요한 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 성능저하현상을 예방
• 데이터 양이 소량일 경우 성능에 영향을 미치지 않으므로 데이터 처리의 유연성을 고려해 가급적 1:1관계를 유지