SQLD 1장 데이터 모델링의 이해
1장. 데이터 모델의 이해
1절. 데이터 모델의 이해
1. 모델링
- 다양한 현상을 추상화, 단순화하여 일정한 표기법에 의해 표현하는 것
- 모델이란 현실 세계의 추상화된 반영
2. 모델링의 특징
- 추상화 : 일정한 형식에 맞춰서 표현
- 단순화 : 제한된 표기법이나 언어로 표현
- 명확화(=정확화) : 애매모호함을 제거하여 이해가 쉽게 표현
3. 모델링의 관점
- 데이터 관점 (what) : 업무와 데이터 및 데이터 사이의 관계를 모델링
- 프로세스 관점 (how) : 업무가 실제로 하고 있는 일, 해야 하는 일 모델링
- 데이터와 프로세스의 상관 관점 (interaction) : 데이터에 대한 업무 처리 방식의 영향을 모델링
* 데이터 모델링의 중요성과 유의점
(1) 중요성 : 파급효과, 간결한 표현, 데이터 품질 유지
(2) 유의점
① 중복 : 여러 장소에 같은 정보 저장 X
② 비유연성 : 데이터의 정의를 데이터 사용 프로세스와 분리
③ 비일관성 : 모델링할 때 데이터 간 상호 연관 관계를 명확히 정의
4. 데이터 모델링의 3단계
- 개념적 모델링 (계획/분석) : ERD 도출, 업무중심, 포괄적인 수준의 모델링
- 논리적 모델링 (분석) : 테이블 도출 (key, 속성, 관계)를 표현, 재사용성, 정규화 수행
- 물리적 모델링 (설계) : DB구축, 물리적 성격, 개념적보다 구체적
5. 데이터 독립성
- 데이터의 구조가 변경되어도 응용 프로그램이 변경할 필요가 없음
- 논리적 독립성 + 물리적 독립성으로 실현됨
- 필요성 : 데이터의 중복성과 복잡도가 증가 -> 요구사항 대응 저하, 유지보수 비용 증가
* 데이터베이스 스키마 (Schema)
- 데이터 모델링 대상 (틀)
- 데이터베이스 구조, 데이터 타입, 제약조건에 대한 명세
- 데이터베이스 설계 단계에서 명시되어 자주 변경되지 않음
* 데이터베이스의 3단계 구조
- 외부 스키마 : 응용프로그램 관점에서의 요구사항, 사용자 관점, DB 정의
- 개념 스키마 : 외부 스키마가 필요로 하는 데이터 모두 모아놓은 것, 설계자 관점
(=DB에 저장되는 데이터의 사용자 관계 표현 -> 모든 사용자 관점 통합, 조직 전체 통합)
- 내부 스키마 : 데이터베이스가 물리적으로 저장된 형식, 개발자 관점
-> 데이터 모델링은 통합 관점의 개념 스키마를 만들어 가는 과정
* 사상 (Mapping)
- 상호 독립적인 개념을 연결시켜 주는 다리
- 논리적 사상 : 외부화면 및 사용자 인터페이스 스키마 구조는 개념스키마와 연결
- 물리적 사상 : 개념스키마 구조와 물리적 저장된 구조(테이블 스페이스)와 연결
* 논리적 독립성
- 논리적 사상 (외부적-개념적)을 통해 논리적 독립성 보장
- 개념 스키마가 변경되어도 외부 스키마에는 영향이 없음
- 논리적 구조가 변경되어도 응용 프로그램에는 영향이 없음, 통합구조 변경 가능
* 물리적 독립성
- 물리적 사상 (개념적-내부적)을 통해 물리적 독립성 보장
- 내부스키마가 변경되어도 외부/개념 스키마는 영향이 없음
- 응용프로그램과 개념스키마에 영향 없이 저장장치 구조변경 가능, 물리적 구조
6. 데이터 모델링 3요소 (개체, 속성, 관계)
- 업무가 관계하는 어떤 것(Thing) : 엔티티타입, 엔터티 / 엔터티, 인스턴스, 어커런스
- 어떤 것이 가지는 성격(Attributes) : 속성 / 속성값
- 어떤 것들 간의 관계(Relationships) : 관계 / 페어링
* 데이터베이스 인스턴스 (Instance)
- 특정 시점에 데이터베이스에 실제로 저장되어 있는 데이터의 값
| 개념 | 복수/집합개념 타입/클래스 |
개별/단수개념 어커런스/인스턴스 |
| 어떤 것 | 엔터티 타입 | 엔터티 |
| 엔터티 | 인스턴스/어커런스 | |
| 연관 | 관계 | 페어링 |
| 성격 | 속성 | 속성값 |
7. ERD (Entity, Relationship Diagram)
- 데이터 모델 표기법 : 엔터티를 사각형, 관계를 마름모, 속성을 타원형으로 표현
8. ERD 표기법을 이용하여 모델링하는 방법
① 엔터티를 그린 후 적절하게 배치
② 엔터티 간 관계 설정
- 식별자 관계를 우선 설정함
(식별자 관계 : 부모로부터 상속받은 FK(외래키)가 자식의 PK(기본키)의 일부가 되는 관계)
- 가급적 Cycle 관계도 발생하지 않아야 한다.
③ 관계명 기술 (양방향)
- 현재형 사용, 지나치게 포괄적인 단어는 지양
- 실제 프로젝트에서는 크게 고려 x
④ 관계차수, 관계의 참여도, 선택성 표시
9. 좋은 모델링의 요건
- 완전성 : 업무에서 필요로 하는 모든 데이터가 데이터 모데에 정의되어야 한다
- 중복배제 : 동일한 사실은 반드시 한 번만 기록
- 업무규칙 : 업무규칙이 데이터 모델에 표현되어야 한다.
- 데이터 재사용 : 회사 전체 관점에서 공통 데이터 도출, 전 영역 사용할 수 있도록 설계
- 통합성 : 동일한 데이터는 조직의 전체에서 한 번만 정의되고 이를 참조, 활용
2절. 엔터티
1. 엔터티
- 업무에 팔요한 정보를 저장하고 관리하기 위한 집합적인 것 (실제, 객체)
- 엔터티는 인스턴스의 집합 (인스턴스는 엔티티 안의 데이터)
2. 엔터티의 분류
* 유무형에 따른 분류
① 유형 (Tangible) 엔터티 : 물리적인 형태가 있고, 안정적이며 지속적 활동 ex) 사원, 물품
② 사건 (Event) 엔터티 : 업무 수행 과정에서 발생, 비교적 발생량 많음 (통계자료에 이용) ex) 주문, 창구
③ 개념 (Conceptual) 엔터티 : 물리적인 형태는 존재하지 않으나 관리해야 할 개념적 정보 ex) 조직, 장소
* 발생시점에 따른 엔터티 (기본 / 중심 / 행위)
① 기본(Key) 엔터티 : 독립적으로 생성되는 엔터티
② 중심(Main) 엔터티 : 기본 엔터티와 행위 엔터티 중간에 존재하는 엔터티
③ 행위(Active) 엔터티 : 2개 이상의 부모 엔터티로부터 발생, 비즈니스 프로세스를 실행하면서 생성되는 엔터티, 지속적으로 정보가 추가되고 변경되어 데이터양이 가장 많음
3. 엔터티의 특징
- 업무에서 필요로 하는 정보 포함
- 유일한 식별자를 가짐 ( 식별자에 의해 식별이 가능하도록, 관계엔터티 예외)
- 2개 이상의 인스턴스를 포함 (인스턴스의 집합)
- 업무 프로세스에 이용됨
- 속성 없이 엔터티의 이름만 존재할 수 없음 (속성이 포함)
- 다른 엔터티와 최소 1개 이상의 관계가 존재 (통계성, 코드성, 내부필요 엔터티 예외)
4. 엔터티의 명명
- 엔터티 생성 의미대로, 실제 업무에서 사용하는 용어를 사용
- 약어를 사용하지 않고, 단수명사 사용
- 이름이 동일한 엔터티가 중복으로 존재하지 않음
3절 속성
1. 속성의 정의
- 사물의 특징 또는 본질적인 성질 (속성이 없다면 실제를 생각할 수 없다)
- 인스턴스에 대해 의미상 더 분리되지 않은 최소의 데이터 단위
- 엔터티에 속한 인스턴스들의 성격을 구체적으로 나타냄
- 엔터티, 인스턴스, 속성, 속성값의 대응
* 엔터티, 인스턴스 속성의 관계
- 1개의 엔터티 : 2개 이상의 인스턴스 집합 가짐
- 1개의 인스턴스 : 2개 이상의 속성을 가짐
- 1개의 속성 : 1개의 속성값을 가짐
2. 속성의 특징
- 해당 업무에서 필요하고 관리해야 하는 정보
- 해당 속성은 정해진 주식별자에 함수적으로 종속되어야 함
- 하나의 속성은 한 개의 값만을 가짐 (다중값인 경우 해당 속성을 별도의 엔터티로 분리)
3. 속성의 명명
- 현업에서 사용하는 이름을 부여
- 약어 사용은 가급적 사용하지 않도록 함
- 수식어/소유격, 서술식 속성명은 사용하지 않아야 하고, 명시적 속성명을 사용
- 전체 데이터 모델에서 유일성 확보
4. 도메인
- 각 속성이 가질 수 있는 값의 범위
ex) 학점 : 0.0 ~ 4.5 사이의 실수
- 엔터티 내에서 속성에 대한 데이터타입과 크기, 제약사항을 지정
5. 속성의 분류
1) 특성에 따른 분류
- 기본 속성 : 가장 일반적인 속성으로, 원래의 업무로부터 유래된 속성
- 설계 속성 : 테이터 모델링을 위해 새로 만든 속성 (코드, 일련번호)
- 파생 속성 : 다른 속성으로부터 유도된 속성 (통계, 계산된 값)
2) 분해 가능 여부에 따른 분류
- 단일 속성 : 하나의 의미
- 복합 속성 : 여러 의미, 단일 속성으로 분해 가능
- 단일값 속성 : 속성 1개에 여러 값, 엔티티로 분해 가능
3) 엔터티의 구성방식에 따른 분류
- 기본키 속성 (Primary Key) : 엔터티의 인스턴스를 구별할 수 있는 속성
- 외래키 속성 (Foreign Key) : 타 엔터티의 PK를 참조하는 속성
- 일반 속성 : 엔터티에 포함되고 PK나 FK속성이 아닌 속성
4절. 관계
1. 관계와 페어링(Pairing)
- 관계 : 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로써 서로에게 연관성이 부여된 상태
- 페어링 : 엔터티 내 인스턴스 간 개별적 관계 -> 이것의 집합을 관계로 표현
- 인스턴스의 집합 -> 엔터티 페어링의 집합 -> 관계
2. 관계의 분류
1) ERD : 존재에 의한 관계 / 행위에 의한 관계 (구분 없이 단일화된 표기법 사용)
2) UML : 연관 관계 / 의존 관계 (실선과 점선 표기법으로 구분)
3. 관계의 표기법
① 관계명 : 엔터티가 관계에 참여하는 형태, 각 관계는 2개의 관계명 및 관점을 가짐
② 관계차수 : 1:1, 1:N, N:M (관계 엔터티 이용)
③ 관계선택사항 : 필수참여, 선택참여 (필수는 | 선택은 O로 표시)
5절. 식별자
1. 식별자의 개념
- 하나의 엔터티에 구성되어 있는 여러 개 속성 중 엔터티를 대표할 수 있는 속성을 의미
- 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재
2. 식별자의 분류
| 분류 | 식별자 | 설명 |
| 대표성 | 주식별자 | - 엔터티 내에서 각 인스턴스를 구분가능 - 타 엔터티와 참조관계를 연결가능 |
| 보조식별자 | - 엔터티 내에서 각 인스턴스를 구분가능 - 대표성을 갖지 못해 참조관계 연결에 사용되지 않음 |
|
| 목적 | 내부식별자 | - 자연스럽게 존재하는 식별자 (본질 식별자) |
| 외부식별자 | - 관계를 통해 유입되는 타 엔터티의 삭별자에 해당 - 주식별자 속성 또는 일반 속성으로 포함될 수 있음 |
|
| 속성 수 | 단일식별자 | - 허나의 속성으로 구성된 식별자 |
| 복합식별자 | - 둘 이상의 속성으로 구성된 식별자 | |
| 본질 | 본질식별자 | - 업무에 의해 만들어지는 식별자 |
| 인조식별자 | - 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자 |
3. 식별자의 특징
- 유일성 : 주식별자에 의해 엔터티 내의 모든 인스턴스들을 유일하게 구분함
- 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 돼야 함
- 불변성 : 주식별자가 지정되면 그 식별자의 값은 변하지 않아야 함
- 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재해야 함 (NULL X)
4. 주식별자 도출 기준
- 유일성을 갖는 속성 중 해당 업무에서 자주 이용되는 속성을 지정
- 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않음
-> 구분자가 존재하지 않을 경우 새로운 식별자 생성 (일련번호, 코드 등)
- 복합식별자를 구성할 경우 너무 많은 속성이 포함되지 않아야 함
-> 주식별자 개수가 많을 경우 새로운 인조식별자를 생성
5. 식별자 관계와 비식별자 관계
① 식별자 관계 (실선)
- 자식이 부모의 기본키를 상속받아 기본키로 사용하는 경우
- 강한 연결관계 부모에 종속, NULL은 없고, 1:1 or 1:N 관계
- 문제점 : 자식의 주식별자 속성이 지속적으로 증가할 수 있음 -> 복잡, 오류가능성
② 비식별자 관계 (점선)
- 부모로부터 속성을 받아 일반 속성으로 사용하는 경우 (약한 종속)
- 문제점 : 부모까지 조인, 불필요 현상 발생 -> SQL 구분 길어져 성능 저하
2장. 성능 데이터 모델링의 개요
1절. 성능 데이터 모델링의 개요
1. 성능 데이터 모델링 정의
- 데이터베이스 성능을 고려하여 데이터 모델링을 수행하는 것
- 정규화, 반정규화, 테이블 통합 및 분할, 조인 구조, PK / FK 설정 등
2. 수행 시점
- 빠를수록 좋음
- 분석/설계 단계에서 성능 모델링 수행 -> 재업무 비용 최소화
3. 성능 데이터 모델링 고려사항
- 정규화를 정확하게 수행 : 주요 관심사별로 테이블을 분산시킴
- 데이터베이스 용량산정 수행 : 각 엔터티에 어느 정도의 트렌젝션이 들어오는지 파악
- 데이터베이스에 발생되는 트렌잭션의 유형 파악 : CRUD 메트릭스 활용
- 용량과 트렌젝션의 유형에 따라 반정규화 수행 : 테이블, 속성, 관계 변경
- 이력모델의 조정, 인덱스를 고려한 PK/FK의 순서 조정, 슈퍼/서브타입 조정 등 수행
- 성능관점에서 데이터 모델 검증
2절. 정규화의 성능
1. 정규화 (Normalization)
- 정의 : 데이터 분해 과정, 이상현상 제거
- 목적 : 삽입/삭제/갱신 이상현상 방지
- 함수적 종속성에 기반한 정규화 수행 필요
2. 함수적 종속성 (Fuctional Dependency)
- 데이터들이 어떤 기준값에 의해 종속되는 현상을 지칭, 결정자와 종속자의 관계, 결정자의 값으로 종속자의 값을 알 수 있음
- 결정자 : 학번, 주민등록번호
- 종속자 : 이름, 혈액형, 출생지, 주소
3. 종류
- 정규형 (Normal Form) : 정규화로 도출된 데이터 모델이 갖춰야 할 특성
① 1NF : 모든 값이 원자값을 가짐
② 2NF : 부분함수종속 제거
③ 3NF : 이행함수종속 제거 (식별자가 아닌 속성이 결정자 역할 하는 함수 종속 제거)
4. 정규화의 효과
- 성능 : 조회, 입력/수정/삭제 2가지로 분류
- 데이터 중복 감소 -> 성능 향상
- 데이터가 관심사별로 묶임 -> 성능 향상
- 조회 질의에서 조인이 많이 발생 -> 성능 저하
-> 입력/수정/삭제의 경우 성능 향상, 그러나 조회의 경우 처리조건에 따라 향상 or 저하
3절 반정규화와 성능
1. 반정규화 (Denormalization)
- 정의 : 정규화된 엔터티, 속성, 관계에 대해 성능 향상을 목적으로 중복, 통합, 분리를 수행하는 데이터 모델링 기범
2. 특징
- 테이블, 칼럼, 관계의 반정규화를 종합적으로 고려 (일반적으로 속성(칼럼)의 중복 시도)
- 과도한 반정규화는 데이터 무결성을 침해
3. 반정규화 시전절차
1) 반정규화 대상 조사 : 데이터 처리 범위 및 통계성 등 조사
2) 다른 방법 검토 : 뷰, 클러스터링, 인덱스, 애플리케이션
3) 반정규화 적용 : 정규화 수행 후 반정규화 수행
4. 반정규화 기법
1) 테이블 반정규화
- 테이블 병합 : 관계 병합, 슈퍼/서브타입 병합
- 테이블 분할 : 수직, 수평 분할
- 테이블 추가 : 중복 테이블 / 통계 테이블 / 이력 테이블 / 부분 테이블 추가
2) 칼럼 반정규화
- 중복칼럼 추가 : 조인 횟수를 감소시키기 위해 다른 테이블의 칼럼 중복 칼럼 저장
- 파생칼럼 추가 : 값의 계산으로 인한 성능 저하 예방, 예상값을 미리 계산해서 중복 칼럼 저장
- 이력테이블 칼럼 추가 : 기능성 칼럼, 대량 이력 데이터 처리의 성능 향악을 위해 종료 여부, 최근값 여부 등의 칼럼 추가로 저장
- PK의 의미적 분리를 위한 칼럼 추가 : PK가 복합 의미를 갖는 경우 단일 속성을 구성시 발생, 구성 요소 값의 조회 성능 향상을 위해 일반 속성을 추가
- 데이터 복구를 위한 칼럼 추가 : 사용자의 실수 또는 응용프로그램 오류로 인해 데이터가 잘못 처리된 경우 원래 값으로 복구 위해 이전 데이터를 임시로 중복 저장
3) 관계 반정규화
- 중복관계 추가 : 조인으로 정보 조회가 가능하지만 조인 경로 단축을 위해 중복관계 추가
* 테이블과 칼럼의 반정규화는 데이터 무결성에 영향을 미침
* 관계의 반정규화는 데이터 무결성 보장 가능, 데이터처리 성능 향상
4절. 대량 데이터에 따른 성능
1. 성능 저하 원인
- 하나의 테이블에 데이터 대량 집중 : 테이블 구조 너무 커서 효율성이 떨어짐 디스크 I/O 증가
- 하나의 테이블에 여러 개의 칼럼 존재 : 디스크 함유량 증가, 데이터 읽는 I/O 증가
- 대량의 데이터가 처리되는 테이블 : SQL 문장에서 데이터 처리를 위한 I/O량 증가, 인덱스 구성
- 다량의 데이터가 하나의 테이블에 존재 : 인덱스의 크기가 증가하면 성능 저하
- 칼럼이 많아지는 경우 : 로우 체이닝, 로우 마이그레이션 발생
2. 해결 방안
- 한 테이블에 많은 칼럼 -> 수직 분할
- 대량 데이터 저장 문제 -> 파티셔닝 PK에 의한 테이블을 분할
* 대량의 데이터 발생에 따른 테이블 분할
- 수직분할 : 칼럼 단위로 분할하여 I/O 경감
- 수평분할 : 로우 단위로 분할하여 I/O 경감
3. 대향 데이터 발생으로 인한 현상
- 로우 체이닝 : 행 길이가 길어 데이터 블록 하나에 데이터를 모두 저장하지 않고 두 개 이상의 블록에 걸쳐 하나의 로우를 저장하는 형태
- 로우 마이그레이션 : 수정된 데이터가 해당 블록에 저장하지 못하고 다른 블록의 빈 공간에 저장되는 현상
4. 파티셔닝
- 테이블 수평 분할 기법, 논리적으로는 하나의 테이블이지만, 물리적으로 여러 데이터 파일에 분산 저장, 데이터 조회 범위를 줄여 성능 향상
Range Patition : 범위로 분할 ( 고객번호 1 ~ 1000, 1001 ~ 2000 등)
List Partition : 특정한 값을 가준으로 분할 ( 지역 : 서울, 부산 등)
Hash Partition : 해시 함수를 적용하여 분할, 데이터 위치는 알 수 없음
* 해시 함수 : 임의 길이의 데이터를 짧은 길이의 데이터로 매핑하는 함수
- Composite Partition : 여러 파티션 기법을 복합적으로 사용하여 분할
5절. 데이터베이스 구조와 성능
1. 슈퍼/서브타입 데이터 모델
- 논리적 데이터 모델에서 주로 이용 (분석단계에서 많이 쓰임)
- 물리적 데이터 모델로 설계 시 문제 발생
- 슈퍼타입 : 공통부분을 슈퍼타입으로 모델링
- 서브타입 : 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성만 모델링
2. 데이터베이스 성능 저하 원인 3가지
① 유니온(Union) 연산에 의해 성능 저하
- 트랜잭션 : 전체를 일괄처리, 테이블 개별로 유지
② 조인에 의해 성능 저하
- 트랜잭션 : 슈퍼 + 서브타입 공통 처리, 테이블 : 개별로 유지
③ 불필요하게 많은 데이터 집적
- 트랜잭션 : 서브타입만 개별로 처리, 테이블 : 하나로 통합
3. 슈퍼/서브타입 데이터 모델 변환을 통한 성능 향상
- 변환기준 : 데이터 양, 트랜잭션 유형
- 데이터 소량 : 데이터 처리 유연성 고려하여 가급적 1:1 관계 유지
- 데이터 대량 : 3가지 변환 방법 (개별 테이블, 슈퍼 + 서브타입 테이블, 하나의 테이블)
① 1:1 타입 (One to one type)
: 개별로 처리하는 트랜잭션에 대해 개별 테이블 구성하여 1:1 관계 유지
② 슈퍼/서브 타입 (Plus type)
: 슈퍼 + 서브 공통으로 처리하는 트랜잭션에 대해 슈퍼/서브 각각 테이블 구성
③ All in One 타입 (Single type)
: 전체를 하나로 묶어 트랜잭션이 발생, 단일 테이블 구성
| 구분 | One to one type | Plus type | Single type |
| 특징 | 개별 테이블 유지 | 슈퍼+서브타입 테이블 | 하나의 통합 테이블 |
| 확장성 | 우수함 | 보통 | 나쁨 |
| 조인 필요 수 | 많음 | 보통 | 적음 |
| I/O 성능저하 | 양호 | 양호 | 나쁨 |
| 관리 용이성 | 나쁨 | 나쁨 | 좋음 |
| 적합 트랜잭션 유형 | 개별 테이블로 접근이 많은 경우 | 슈퍼+서브 형식 데이터 처리가 많은 경우 | 전체에 대한 일괄 처리가 많은 경우 |
4. PK/FK 칼럼 순서 및 성능
- 일반적인 프로젝트에선 PK/FK 칼럼 순서의 중요성을 인지하지 못해 데이터 모델링 되어있는 상태로 DDL을 생성하여 성능이 저하되는 경우가 빈번
① 인덱스의 중요성 : 데이터 조작 시 가장 효과적으로 처리될 수 있는 접근 경로 제공
* 인덱스의 특징 : 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때, 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낼 수 있다. 앞쪽에 위치한 속성값이 가급적 '=' 아니면 최소한의 범위인 'BETWEEN'이 들어와야 됨
② PK/FK 설계 중요성 : 데이터 접근 시 접근경로 제공, 설계단계 마지막에 칼럼 순서 조정
③ PK 순서의 중요성 : 조인을 할 수 있는 수단이 됨, 조회 조건 고려해서 반드시 인덱스 생성
5, PK 순서를 조정하지 않으면 성능 저하 되는 이유
- 조회 조건(WHERE)에 따라 인덱스를 처리하는 범위가 달라짐
- PK의 순서를 인덱스 특징에 맞게 생성하지 않고 자동으로 생성하면, 테이블에 접근하는 트랜잭션이 인덱스 범위를 넓게 하거나 풀 스캔을 유발
6. 물리적 테이블에 FK 제약이 걸려있지 않은 경우 인덱스 미생성으로 생긴 성능 저하
- 물리적으로 두 테이블 사이 FK 참조 무결성 관계를 걸어 상속받은 FK에 인덱스 생성
7. 인덱스 액세스 범위 좁히는 가장 좋은 방법
- PK가 여러 개일 때, where절에 사용하는 조건용 칼럼들이 우선순위가 되어야 함
- 'ㄹ', EQUAL 조건, 등등 조건에 있는 칼럼이 제일 앞으로
- BETWEEN, IN 범위 조건에 있는 칼럼이 그다음 순위
- 나머지 PK는 그 뒤에 아무렇게나
6절. 분산 데이터베이스와 성능
1. 분산 데이터베이스 개념
- 물리적으로 분산된 데이터베이스를 하나의 논리적 시스템으로 사용
- 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역에서 노드로 위치시켜 사용성과 성능을 극대화하는 데이터베이스
2. 분산 데이터베이스 설계 방식
- 상향식 : 지역 스미카 작성 후 전역 스키마 작성
- 하향식 : 전역 스키마 작성 후 지역사상 스키마 작성
3. 분산 데이터베이스의 장/단점
| 장점 | 단점 |
| - 지역 자치성 증가 - 점증적 시스템 용량 확장 가능 - 신뢰성 / 가용성 / 효용성 / 융통성 - 빠른 응답 속도, 통신비율 절감 - 데이터의 가용성과 신뢰성 증가 - 시스템 규모의 적절한 조절 가능 - 각 지역 사용자의 요구 수용 기능 |
- 소프트웨어 개발 비용 증가 - 오류의 잠재성 증대 - 처리 비용 증대 - 설계, 관리의 복잡성 및 비용증가 - 불규칙한 응답 속도 - 통제의 어려움 - 데이터 무결성 유지의 어려움 |
4. 분산 DB의 투명성
- 분할 투명성 : 하나의 논리적 관계가 분할되어 각 단편의 사본이 어려 사이트에 저장
- 위치 투명성 : 사용하려는 데이터 저장 장소가 명시되지 않아도 됨
- 지역사상 투명성 : 지역 DBMS와 물리적 DB 사이의 사상이 보장됨
- 중복 투명성 : DB 객체 중복 여부를 몰라도 됨
- 장애 투명성 : 구성 요소(DBMS, 컴퓨터)의 장애에 무관하게 트랜잭션의 원자성이 유지됨
- 병행 투명성 : 다수의 트랜잭션을 동시 수행했을 때 결과의 일관성이 유지됨
5. 분산 데이터베이스의 적용 기법
① 테이블 위치 분산 : 설계된 테이블의 위치를 분산
- 테이블 구조 변경 X
- 테이블이 다른 데이터베이스에 중복으로 생성 X
- 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우 사용
- 테이블 위치를 파악할 수 있는 도식화된 위치별 데이터베이스 문서 필요
② 테이블 분할 분산 (수평, 수직분할) : 테이블을 수평이나 수직으로 분할하여 분산
- 수평 분할 : 특정 칼럼의 값 기준으로 로우 단위 분리, 칼럼 분리 X
- 수직 분할 : 칼럼을 기준으로 칼럼 단위로 분리, 로우 분리 X
③ 테이블 복제 분산 (부분, 광역복제)
- 동일한 테이블을 다른 지역이나 서버에서 동시 생성, 원격지 조인을 내부조인으로 변경하여 성능 향상. 프로젝트에서 많이 사용되는 데이터베이스 분산 기법
* 부분복제
- 마스터 데이터베이스에서 테이블의 일부 내용만 다른 지역이나 서버에 위치
- 본사는 통합 테이블 관리, 각 지사에서는 지사에 해당하는 로우만 관리
- 실제로는 지사에서 먼저 데이터 발생 -> 본사에서 전체 통합
* 광역복제
- 통합된 테이블을 본사에 가지고 있으며 각 지사에 본사와 동일한 데이터 분배
- 동일한 테이블을 여러 곳에 복제하여 관리
- 본사에서 데이터의 입력, 수정, 삭제 발생 -> 지사에서 이를 반영
④ 테이블 요약 분산 (분석, 통합요약)
- 유사한 내용의 데이터를 서로 다른 관점/수준에서 요약하여 분산 관리
* 분석요약
- 각 지사별 동일한 주제의 정보를 본사에서 통합하여 전체 요약 정보 산출
* 통합요약
- 각 지사별로 존재하는 다른 내용 정보를 본사에 통합, 다시 전체의 요약 산출