SQLD 자격증 공부하면서 정리한 내용들을 작성한 글입니다.
5. 데이터베이스 구조와 성능
(1) 슈퍼/서브타입 데이터 모델(Extended ER모델)
- 논리적 데이터 모델에서 주로 이용되고 분석 단계에서 많이 쓰이는 모델
- 물리적 데이터 모델을 설계하는 단계에서는 슈퍼/서브타입 데이터 모델을 일정한 기준에 의해 변환을 해야 함
- 공통의 부분을 슈퍼타입으로 모델링 / 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의 서브엔터티**로 구분
→ 업무의 모습을 정확하게 표현
→ 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있음
(2) 데이터베이스 성능 저하 원인 3가지
-
트랜잭션 : 전체를 일괄처리 / 테이블 : 개별로 유지
→ Union 연산에 의해 성능 저하 -
트랜잭션 : 슈퍼+서브타입 공통 처리 / 테이블은 개별로 유지
→ 조인에 의해 성능 저하
- 트랜잭션 : 서브타입만 개별로 처리 / 테이블은 하나로 통합
→ 불필요하게 많은 데이터 집적
(3) 슈퍼/서브 타입의 변환 기준
-
데이터가 소량일 경우
- 데이터 처리 유연성 고려해 1:1 관계를 유지
-
데이터가 대량일 경우
- 전부 개별 테이블로 구성
- 슈퍼+서브타입 테이블로 구성
- 하나의 테이블로 구성
(4) 슈퍼/서브 타입의 데이터 모델 변환 기술
-
개별로 발생되는 트랜잭션
→ 개별 테이블로 구성(One to One type)- 업무적으로 변화 가능성이 높아 유연성을 확보할 필요가 있는 경우
- 수행 속도가 빠르다.
- 슈퍼 타입에 속한 정보만 조회하는 경우, 문장 작성이 용이하다.
- 칼럼의 중복이 적으므로, 상대적으로 작은 공간을 차지한다.
- 관계에 의해 발생하는 복잡한 참조 무결성 규칙을 적용할 수 있다.
-
슈퍼+서브타입으로 발생되는 트랜잭션
→ 슈퍼+서브타입 테이블로 구성(Plus type)- 정보를 각 서브타입 별로 조작할 경우, 조인하지 않아도 됨
- 관계에 의해 발생하는 복잡한 참조 무결성 규칙을 적용할 수 있다.
- 처리 속도가 감소할 수 있다.(단점)
-
전체를 하나로 묶어 발생하는 트랜잭션
→ 하나의 테이블로 구성(Single type)- 조인할 일이 없으므로 SQL 문장이 단순하고, 수행 속도가 빨라지는 경우가 많다.
- 서브타입을 구분하지 않고 데이터를 조회할 경우 처리가 용이하다.
- 특정 서브타입의 NOT NULL 제한 불가 → NULL 값이 많아질 수 있다.(단점)
쪼갤수록 확장성↑, Disk I/O 성능↑, 조인 성능↓, 관리 용이성↓
(5) PK / FK 컬럼 순서 및 성능
- 인덱스 중요성 : 데이터 조작 시 가장 효과적으로 처리될 수 있는 접근 경로 제공
오브젝트 앞쪽에 위치한 속성값(컬럼)이 비교자로 있어야 인덱스가 좋은 효율을 냄 - PK / FK 설계 중요성 : 데이터 접근 시 접근경로 제공, 설계단계 마지막에 컬럼 순서를 조정
- PK 순서 중요성 : 물리적 모델링 단계에서 스스로 생성된 PK 외에 상속되는 PK 순서도 중요
- FK 순서 중요성 : 조인을 할 수 있는 수단이 됨(=경로) , 조회 조건 고려해서 반드시 인덱스 생성
인덱스 액세스 범위 좁히는 가장 좋은 방법
- PK가 여러 개일 때, Where절에서 사용하는 조건용 컬럼들이 우선순위가 되어야 함
① ‘=’ EQUAL조건 (동등조건)에 있는 컬럼이 제일 앞으로
② BETWEEN, IN (범위조건)에 있는 컬럼이 그 다음순위
③ 나머지 PK는 그 뒤에 아무렇게나. (id값 이런거 상관없음)
- PK 순서를 조정하지 않으면 성능 저하되는 이유
- 조회 조건(WHERE)에 따라 인덱스를 처리하는 범위가 달라짐
- PK의 순서를 인덱스 특징에 맞게 생성하지 않고 자동으로 생성하면, 테이블에 접근하는 트랜잭션이 인덱스 범위를 넓게 하거나 Full Scan을 유발
- 물리적 테이블에 FK 제약이 걸려있지 않은 경우, 인덱스 미생성으로 생긴 성능 저하
- 물리적으로 두 테이블 사이 FK 참조 무결성 관계를 걸어 상속받은 FK에 인덱스 생성
안녕하세요, 웹 개발자 이하영입니다!