> 1장 데이터 모델링의 이해
1. 데이터 모델의 이해
1. 모델링
1) 모델링이 갖춰야 할 조건
- 현실세계를 반영해야 한다.
- 단순화하여 표현해야 한다.
- 관리하고자 하는 데이터를 모델로 설계한다.
2) 모델링의 특징
▷ 추단명
| 추상화 | 현실 세계를 일정한 형식으로 표현하는 것 |
|---|---|
| 단순화 | 복잡한 현실 세계를 정해진 표기법으로 단순하고 쉽게 표현한다. |
| 명확화 | 불분명함을 제거하고 명확하게 해석할 수 있도록 기술한다. |
3) 데이터 모델링 시 지양해야 할 점
| 중복 | 같은 데이터가 여러 엔터티에 중복으로 저장되는 현상 |
|---|---|
| 비유연성 | 사소한 업무변화에 데이터 모델이 수시로 변경되면 안 된다. |
| 비일관성 | 데이터 간 상호 연관 관계에 대해 명확히 정의해야 한다. |
2. 모델링의 세 가지 관점
| 데이터 관점 | 데이터 위주의 모델링 |
|---|---|
| '데이터 간의 관계' | |
| 프로세스 관점 | 프로세스 위주의 모델링 |
| '무엇을 해야 하는가' | |
| 데이터, 프로세스 상관 관점 | 데이터와 프로세스의 관계를 위주로 한 모델링 |
| '업무처리 방법에 따라 데이터에 어떤 영향을 주는가' |
3. 모델링의 세 가지 단계
▷ 개논물
| 개념적 데이터 모델링 | 전사적 데이터 모델링 수행 시 행해지며, 추상화 레벨이 가장 높은 모델링이다. |
|---|---|
| 논리적 데이터 모델링 | 재사용성이 가장 높은 모델링으로 데이터베이스 모델에 대한 Key, 속성, 관계 등을 모두 표현하는 단계이다. |
| 물리적 데이터 모델링 | 실제 데이터베이스로 구현할 수 있도록 성능이나 가용성 등의 물리적인 성격을 고려하여 모델을 표현하는 단계이다. |
4. 데이터의 독립성
▷ ANSI-SPARC 아키텍처 : 3단계 스키마 구조
▷ 외개내
| 외부 스키마 | View 단계 | 논리적 사상 |
|---|---|---|
| 여러 개의 사용자의 관점 | ||
| 각 사용자가 보는 데이터베이스의 스키마 | ||
| 개념 스키마 | 모든 사용자가 보는 데이터베이스의 스키마 | 논리적 사상, 물리적 사상 |
| 내부 스키마 | 물리적인 저장 구조 | 물리적 사상 |
▷ Mapping(사상) = 상호 독립적인 개념을 연결시켜주는 다리
1) 논리적 사상 : 외부 - 개념
2) 물리적 사상 : 개념 - 내부
▷ 3단계 스키마 구조가 보장하는 독립성 = 물리적 구조와 개념 구조의 독립
1) 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마는 영향받지 않는다.
2) 물리적 독립성 : 내부 스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다.
5. ERD(Entity Relationship Diagram)
1) ERD 표기 방식
| Peter Chen | 주로 대학교재에서 사용하는 표기법 |
|---|---|
| IDEF1X | ERWin에서 사용되는 모델 |
| IE/Crow's Foot | 까마귀발 표기법이라고도 부르고 가장 많이 사용하는 표기법 |
| Min-Max/ISO | 각 엔터티의 참여도를 좀 더 상세하게 나타내는 표기법 |
| UML | 소프트웨어 공학에서 주로 사용되는 모델 |
| Case*Method/Barker | Oracle에서 사용되는 모델로 Crow's Foot과 비슷하다. |
2) IE/Crow's Foot 표기법
3) ERD 작성 순서
ㄱ. 엔터티를 도출하고 그린다.
ㄴ. 엔터티를 배치한다.
ㄷ. 엔터티 간의 관계를 설정한다.
ㄹ. 관계명을 기입한다.
ㅁ. 관계의 참여도를 기입한다.
ㅂ. 관계의 필수/선택 여부를 기입한다.
4) 시스템 분석을 위한 모델링의 기능
- 시스템이 향후 변화하고자 하는 모습으로 가시화 해준다.
- 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
- 시스템의 구조와 행동을 명세화 해준다.
6. 좋은 데이터 모델의 요소
| 완전성 | 업무에 필요한 모든 데이터가 모델에 정의 |
|---|---|
| 중복배제 | 하나의 데이터베이스 내에 동일한 사실은 한번만 |
| 업무규칙 | 많은 규칙을 사용자가 공유하도록 제공 |
| 데이터 재사용 | 데이터가 독립적으로 설계돼야 한다. |
| 의사소통 | 업무규칙은 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세히 표현 |
| 통합성 | 동일한 데이터는 한번만 정의, 참조 활용 |
2. DBMS
Database Management System 데이터베이스 관리 시스템
3. DB
1. 관계형 데이터베이스, RDB
Key와 value를 테이블화시킨 DB
- SQL문에 의해 관리된다.
- 참조 구조가 없다. JOIN을 통해서만 연관관계가 정의된다.
2. 객체 지향형 데이터베이스
모든 것은 객체(object)다.
- 사용자가 정의한 데이터 유형을 지원한다.
- 비정형 복합정보 모델링이 가능하다.
- 객체들 사이 참조(ref) 구조를 생성가능하다.
3. 객체 관계형 데이터베이스
관계형 모델을 기반으로 객체 지향 정보를 지원한다.
- 사용자 정의 타입을 지원한다.
- 객체 사이 참조 타입도 지원한다.
- 객체 간 상속관계를 지원한다.
4. 엔터티
1. 정의
독립체. 식별이 가능한 객체
- 업무에서 쓰이는 데이터를 용도별로 분류한 그룹
- 속성 : 컬럼
- 인스턴스 : 로우
2. 특징
1) 업무에서 쓰이는 정보여야 한다.
- 실질적으로 업무에서 쓰이는 정보여야 엔터티로 도출하는 의미가 있다.
- 모호한 기준은 성립될 수 없다.
2) 유니크한 식별자가 있어야 한다.
- 엔터티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 이 엔터티는 설계가 잘못된 것이라고 볼 수 있다.
- 테이블에서는 PK
3) 2개 이상의 인스턴스를 가지고 있어야 한다.
- 엔터티는 인스턴스의 집합이다.
4) 반드시 속성을 가지고 있어야 한다.
- 하나의 인스턴스에는 한 개 이상의 속성이 있어야 한다.
5) 다른 엔터티와 1개 이상의 관계를 가지고 있어야 한다.
6) 부모-자식 이외에 다른 관계도 존재한다.
3. 엔터티 분류
1) 유형 or 무형
▷ 유개사
| 유형 엔터티 | 물리적인 형태가 존재한다. |
|---|---|
| - 안정적 & 지속적 | |
| 개념 엔터티 | 물리적인 형태가 없다. |
| - 개념적 | |
| 사건 엔터티 | 행위를 함으로써 발생한다. |
| - 빈번하다. | |
| - 통계 자료로 이용된다. |
2) 발생시점
▷ 기중행
| 기본 엔터티 | 독립적으로 생성된다. 자신만의 주식별자를 가지며 다른 엔터티의 부모 역할을 한다. |
|---|---|
| 중심 엔터티 | 기본 엔터티로부터 파생되고, 다른 엔터티와의 관계로 많은 행위 엔터티가 생성된다. |
| 행위 엔터티 | 2개 이상의 엔터티로부터 파생된다. 자주 바뀌거나 양이 증가한다. |
- 엔터티 이름을 정할 때 주의점
1) 업무에서 실제로 쓰이는 용어를 사용한다.
2) 한글은 약어를 사용하지 않고 영문은 대문자로 표기한다.
3) 단수 명사로 표현하고 띄어쓰기는 하지 않는다.
4) 다른 엔터티와 의미상으로 중복될 수 없다. 유일한 이름 부여가 원칙이다.
5) 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확(분명)하게 표현한다.
6) 엔터티가 생성되는 의미대로 자연스럽게 부여하도록 한다.
5. 엔터티 작성 순서
1) 엔터티 도출
2) 엔터티 배치
3) 엔터티 관계 설정
4) 관계명 기술
5) 관계 참여도 기술
6) 관계 필수 여부 기술
5. 속성
사물이나 개념의 특징을 설명해 줄 수 있는 항목
- 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 분리되지 않는 최소의 데이터 단위
- 의미상 더이상 쪼개지지 않는 레벨
- 하지만 속성도 집합이다. 하나의 속성값을 갖기 때문에
1. 속성값
각각의 속성은 속성값을 가지며 속성값은 엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터라고 볼 수 있다.
- 하나의 속성은 한 개의 속성값만 가질 수 있다. 하나의 속성이 여러 개의 속성값을 갖는 경우 별도의 엔터티로 분리하는 것이 바람직하다.
2. 엔터티, 인스턴스, 속성, 속성값의 관계
1) 1개의 엔터티는 2개 이상의 인스턴스를 갖는다.
2) 1개의 인스턴스는 2개 이상의 속성을 갖는다.
3) 1개의 속성은 하나의 속성값을 갖는다.
3. 분류
1) 특성에 따른 분류
| 기본속성 | 업무 프로세스 분석을 통해 바로 정의가 가능한 속성. |
|---|---|
| 설계속성 | 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 인위적으로 만들어 정의한 속성. |
| - 유니크한 식별자를 부여하기 위한 것이 목적. | |
| 파생속성 | 원래 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성 |
| - 적을 수록 좋다. | |
| - 조회할 때 빠른 성능을 낼 수 있도록 하기 위한 게 목적이다. |
2) 구성방식에 따른 분류
| PK(Primary Key) 속성 | 엔터티의 인스턴스들을 식별할 수 있는 속성 |
|---|---|
| FK(Foreign Key) 속성 | 다른 엔터티의 속성에서 가져온 속성 |
| 다른 엔터티와 관계를 맺게 해주는 매개체 역할을 하는 속성 | |
| 다른 PK값과 일치하거나 NULL값을 가질 수도 있는 속성 | |
| 일반속성 | PK, FK를 제외한 나머지 속성 |
4. 도메인
속성이 가질 수 있는 속성값의 범위
- 엔터티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.
5. 용어사전
엔터티의 속성명을 정의할 때 명확한 의미의 이름을 부여하고 다른 엔터티와의 혼란을 예방하기 위해 이용하는 것
- 하나의 데이터베이스에서 같은 의미를 가진 데이터가 엔터티마다 다른 명으로 정의된다면 자칫 혼란을 초래할 수 있다. 이런 현상을 방지하기 위해 설계 시 용어사전을 두고 각 엔터티에 공통된 룰로 적용하는 것이 바람직하다.
▷ 엔터티 ⊃ 인스턴스 ⊃ 속성 ⊃ 속성값
6. 속성명을 지을 때 주의점
1) 해당업무에서 사용하는 이름 부여
2) 서술식 속성명(복합 명사)은 사용 금지
3) 약어 사용 금지
4) 구체적으로 명명하여 데이터 모델에서 유일성 확보
6. 관계
엔터티와 엔터티의 관계
| 연관관계 | 항상 이용하는 관계 |
|---|---|
| ____실선 | |
| 의존관계 | 상대 행위에 의해 발생하는 관계 |
| - - - - 점선 |
1. 존재적 관계
존재 자체로 연관성이 있는 관계
2. 행위적 관계
특정한 행위를 함으로써 연관성이 생기는 관계
3. 표기법
1) 관계명
- 관계의 이름
- 모든 관계는 두 개의 관계명을 가지고 있다.
- 반드시 명확한 문장으로 표현해야 하며, 현재형이어야 한다.
2) 관계차수
- 관계에 참여하는 수
- 1:1, 1:M, M:N
3) 관계선택사양
- 필수인지 선택인지의 여부
- 이 관계가 필수요소인지 선택사항인지를 나타내는 말이다.
| 필수적 관계 | 참여자가 반드시 존재해야 하는 관계 |
|---|---|
| 선택적 관계 | 참여자가 없을 수도 있는 관계 |
4. 관계 체크
1) 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
2) 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
3) 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?
4) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
7. 식별자
속성 중에 각각의 인스턴스를 구분 가능하게 만들어주는 대표 속성
1. 주식별자
기본키, PK에 해당하는 속성 (주문 - 주문상품)
| 유일성 | 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다. |
|---|---|
| 최소성 | 유일성을 보장하는 최소 개수의 속성이어야 한다. |
| 불변성 | 속성값이 되도록 변하지 않아야 한다. |
| 존재성 | 속성값이 NULL일 수 없다. |
1) 키의 종류
| 기본키 | 후보키 중에서 엔터티를 대표할 수 있는 키 |
|---|---|
| 후보키 | 유일성과 최소성을 만족하는 키 |
| 슈퍼키 | 유일성은 만족하지만 최소성을 만족하지 않는 키 |
| 대체키 | 여러 개의 후보키 중에서 기본키를 선정하고 남은 키 |
| 외래키 | 타 테이블의 기본키를 가리키는 키 |
| (참조무결성을 확인하기 위해 사용) |
1) 대표성 여부
| 주식별자 | 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자 |
|---|---|
| - 다른 엔터티와 참조 관계로 연결 | |
| 보조식별자 | 인스턴스를 식별할 수는 있지만 대표 식별자가 아님. |
| - 다른 엔터티와 참조 관계로 연결되지 않음 |
2) 스스로 생성되었는지 여부
| 내부식별자 | 엔터티 내부에서 스스로 생성된 식별자 |
|---|---|
| 외부식별자 | 다른 엔터티에서 온 식별자. 다른 엔터티와의 연결고리 역할 |
3) 속성의 수
| 단일식별자 | 하나의 속성으로 구성된 식별자 |
|---|---|
| 복합식별자 | 두 개 이상의 속성으로 구성된 식별자 |
4) 대체 여부
| 원조식별자(본질식별자) | 업무에 의해 만들어지는 식별자 |
|---|---|
| - 가공되지 않은 원래의 식별자 | |
| 대리식별자(인조식별자) | 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 |
| - 새롭게 만든 식별자 | |
| - 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자 |
3. 식별자 관계
| 식별자 관계 | 비식별자 관계 |
|---|---|
| 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계 | 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계 |
| 부모 엔터티가 있어야 생성 가능하며 1:1이거나 1:M | 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능하고, 마찬가지의 이유로 자식 엔터티가 존재하는 상태에서 부모 엔터티가 삭제될 수도 있다. |
| 강한 관계 | 약한 관계 |
| 실선으로 표현 | 점선으로 표현 |
4. 비식별자 관계가 되는 경우
1) 부모 없는 자식이 생성될 수 있는 경우
2) 부모와 자식의 생명주기가 다른 경우
3) 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가진 경우
4) 자식 엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
5) SQL 문장이 길어져 복잡성이 증가되는 것을 방지하기 위한 경우
> 2장 데이터 모델과 성능
1. 성능 데이터 모델링
데이터베이스의 성능을 향상시키기 위해 설계 단계부터 성능과 관련된 사항들이 모델링에 반영될 수 있도록 하는 것
- 정규화, 반정규화, 테이블통합, 테이블분할, 조인구조, PK, FK 등
- 한 테이블에 많은 컬럼들이 존재할 경우 데이터가 물리적으로 저장되는 디스크 상에 넓게 분포할 가능성이 커지게 되어 디스크 I/O가 대량으로 발생할 수 있고, 이로 인해 성능이 저하될 수 있다. 따라서 트랜잭션이 접근하는 컬럼유형을 분석해서 자주 접근하는 컬럼들과 상대적으로 접근 빈도가 낮은 컬럼들을 구분하여 1:1로 테이블을 분리하면 디스크 I/O가 줄어들어 성능을 향상시킬 수 있다.
1. 순서
1) 데이터 모델링을 할 때 정규화를 정확하게 수행한다.
2) 데이터베이스 용량산정을 수행한다.
3) 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
4) 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
5) 성능 향상을 위한 이력모델의 조정, PK/FK 조정, 슈퍼/서브타입 조정 등을 수행한다.
6) 데이터 모델의 성능을 검증한다.
▷ 정용트반조검
2. 데이터 모델링에서 생길 수 있는 이상 현상
| 삽입이상 | 기본적으로 주문되지 않은 상품의 정보를 삽입할 수 없으며, 강제로 삽입하기 위해서는존재하지 않는 가짜 주문번호를 만들어 주어야 한다. |
|---|---|
| 갱신이상 | 중복된 데이터 중 일부만 업데이트되어 데이터의 불일치가 발생하게 되는 현상 |
| 삭제이상 | 데이터 삭제 시 삭제되면 안 되는 데이터까지 덩달아 삭제되는 현상 |
2. 정규화
데이터 정합성을 위해 엔터티를 작은 단위로 분리하는 과정
- 데이터에 대한 중복성을 제거한다.
- 정규화를 할 수록 엔터티는 증가한다.
- 데이터 입력, 수정, 삭제 성능이 향상된다. 반대로 조회 성능은 저하될 수 있다.
- 함수 종속성을 고려하여 이상 현상이 생기지 않도록 테이블을 분할한다.
- 함수 종속성 : 데이터들이 어떤 기준 값에 의해 종속되는 현상
1. 주의사항
1) 정규화를 통해 만든 회원(엔터티)의 배송상태(속성)를 조회하려면 여러 번의 JOIN을 해야 한다.
- 지나친 정규화는 성능 저하를 초래할 수 있다. (조회 성능은 항상 저하)
- 해결을 위해 회원 엔터티와 배송 엔터티 간의 관계를 생성하여 성능을 개선할 수 있다.
2) 모든 정규화는 이전의 정규화를 만족해야 한다.
- 제2정규화를 만족하기 위해서는 제1정규화가 이미 충족되있어야 한다.
3. 반정규화
데이터의 조회 성능을 향상시키기 위해 데이터의 중복을 허용하거나 데이터를 그룹핑하는 과정이다.
- 조회 성능은 향상될 수 있으나 입력, 수정, 삭제 성능은 저하될 수 있으며 데이터 정합성 이슈가 발생할 수 있다.
- 데이터 무결성이 저해된다.
- 정규화가 끝난 후 거치게 된다.
- 조회 성능은 재현의 적시성, 데이터 제공의 적시성과 같은 의미이다.
- 다량의 데이터를 탐색하는 처리가 반복적으로 빈번하게 발생한다면 반정규화를 하는 것이 좋다.
- 최근의 변경된 값만을 조회하는 경우 과도한 조인으로 인해 성능이 저하되어, 반정규화를 하는 게 좋다.
1. 반정규화 절차
1) 반정규화 대상조사(범위처리빈도수, 범위, 통계성)
- 자주 사용되는 테이블에 접근하는 프로세스의 수가 많고 항상 일정한 범위만을 조회하는 경우
- 테이블에 대량의 데이터가 있고, 대량의 데이터 범위를 자주 처리하는 경우에 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없는 경우
- 통계성 프로세스에 의해 통계 정보를 필요로 할 때 별도의 통계테이블을 생성한다.
- 테이블에 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우
2) 다른 방법유도 검토
| VIEW | 사용 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 VIEW를 사용한다. |
|---|---|
| 클러스터링 | 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나 인덱스를 조정한다. |
| 파티셔닝 | 대량의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리할 수 있다. |
| - 파티셔닝 키에 의해 물리적 저장공간 분리. | |
| - 데이터 액세스 성능을 향상시키기 위해 테이블에 적용하는 기법 | |
| 캐시 | 응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬 수 있다. |
3) 반정규화 적용
2. 테이블 반정규화
3. 테이블 병합
업무 프로세스상 JOIN이 필요한 경우가 많아 테이블을 통합하는 것이 성능 측면에서 유리할 경우 고려한다.
4. 테이블 분할
5. 테이블 추가
6. 컬럼 반정규화
7. 관계 반정규화 = 중복 관계 추가
- 업무 프로세스상 JOIN이 필요한 경우가 많아 중복 관계를 추가하는 것이 성능 측면에서 유리할 경우 고려한다.
- 데이터의 무결성을 깨뜨릴 위험성 없이 데이터 처리 성능을 향상시킬 수 있는 기법이다.
4. 트랜잭션(Transaction)
데이터를 조작하기 위한 하나의 논리적인 작업 단위.
1. 트랜잭션의 예시
▷ 이벤트 응모 이력을 저장한다.
▷ 쿠폰을 발행한다.
5. 슈퍼-서브 타입 모델
업무를 구성하는 데이터를 공통 부분과 차이점의 특징을 고려하여 효과적 표현. 논리적 모델.
| 슈퍼 타입 | 공통 부분 |
|---|---|
| 서브 타입 | 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성 |
1. 슈퍼 서브 / 타입 데이터 모델의 변환기술
1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
(OneToOne Type)
2) 슈퍼타입 + 서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼 + 서브타입 테이블로 구성
(Plus Type)
3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성 (Single Type, All in One Type)
6. 인덱스 특성을 고려한 PK/FK 데이터베이스 성능 향상
인덱스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때, 앞쪽에 위치한 속성의 값이 비교자로 있어야 좋은 효율을 낸다. 앞쪽에 위치한 속성의 값이 가급적 ‘=’ 아니면 최소한 범위 ‘BETWEEN’, ‘<>’ 가 들어와야 효율적이다.
1. 엔터티 간 논리적 관계가 있을 경우
업무적으로 밀접하게 연결되어 상호간에 조인이 자주 발생한다는 것을 의미하는 것이기 때문에, 데이터베이스 상에서 DBMS가 제공하는 FK Constraints 생성여부와 관계없이 조인 성능을 향상시키기 위해서
자식 테이블에서 FK 컬럼에 대한 인덱스를 생성해주는 것이 좋다.
7. NULL
NULL은 존재하지 않음, 값이 없음을 의미한다.
- 가로 연산에 포함되면(인스턴스 안에서 사칙연산) 결과로 NULL을 준다.
- 세로 연산에 포함되면(인스턴스들 끼리 집계) NULL 값이 제외된 결과값이 나온다.
- WHERE COL = NULL은 항상 False 반환
8. 분산 데이터베이스
여러 곳으로 분산되어있는 DB를 하나의 가상 시스템으로 사용할 수 있도록 한 DB. 논리적으로 동일한 시스템에 속하지만 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터집합.
1. 분산 데이터베이스를 만족하기 위한 6가지 투명성
| 분할 투명성(단편화) | 하나의 논리적 Relation이 여러 단편으로 분할되어 각 사본이 여러 site에 저장 |
|---|---|
| 위치 투명성 | 사용하려는 데이터의 저장 장소 명시 불필요, 위치정보가 시스템 카탈로그에 유지 |
| 지역사상 투명성 | 지역 DBMS와 물리적 데이터베이스 사이의 Mapping 보장 |
| 중복 투명성 | 데이터베이스 객체가 여러 site에 중복되어있는지 알 필요가 없는 성질 |
| 장애 투명성 | 구성요소의 장애에 무관한 트랜잭션의 원자성 유지 |
| 병행 투명성 | 다수 트랜잭션 동시 수행시 결과의 일관성 유지, Time Stamp, 분산 2단계 Locking 이용 |
2. 분산 데이터베이스 장단점
**3. 효율성 증대가 가능한 경우
1) 공통코드, 기준정보 등 마스터 데이터는 분산 데이터베이스에 복제분산을 적용한다.
2) 거의 실시간 업무적인 특성을 가지고 있을 때 분산 데이터베이스를 사용하여 구성할 수 있다.
3) 백업 사이트(site)를 구성할 때 간단하게 분산기능을 적용하여 구성할 수 있다.
(*GSI는 통합된 한 개의 인스턴스, 통합 데이터베이스 구조를 의미하므로 분산데이터베이스와는 대치되는 개념)
