데이터 모델링의 이해

데이터모델링

설계과정에서 시스템의 중요한 개념을 논리적인 데이터 모델로 구성하는 작업을 의미

일반적으로 물리적인 데이터베이스 모델 구현, 시스템 데이터베이스 반영 과정을 포함

데이터 모델링은 단순 데이터를 다루는 것 뿐 아니라 시스템의 구체적인 Flow를 정의

 

데이터모델링이란

• 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
• 현실세계의 데이터(what)에 대해 약속된 표기법으로 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정

데이터모델링의 3요소

Thing, Attributes, Relationship

 

데이터모델링 특징

• 추상화(모형화) : 현실세계를 일정한 형식에 맞추어 표현한다.
• 단순화 : 복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 한다.
• 명확화(정확화) : 애매모호함을 제거하고 누구나 이해가 가능하도록 정확하게 현상을 기술한다.

데이터모델링 유의사항

• 중복(Duplication) : 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.
• 비유연성(Inflexibility) : 데이터 모델을 어떻게 설계했느냐 에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
• 비일관성(Inconsistency) 데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링을 할 때 데이터와 데이터 간 상호 연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다. 사용자가 처리하는 프로세스 혹은 이와 관련된 프로그램과 테이블의 연계성을 높이는 것은 데이터 모델이 업무 변경에 대해 취약하게 만드는 단점에 해당한다.

데이터모델링 과정

1. 개념적 데이터 모델링 : 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA수립시 많이 이용
2. 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
3. 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계

---

스키마(Schema)

데이터베이스에 어떤 테이블과 컬럼이 있고, 서로 어떻게 연결되는지에 대한 설계도

데이터 베이스 구조에 대한 설명서 또는 데이터의 설계도

데이터베이스 스키마 구조 3단계

항목	내용	비고
외부스키마 (External Schema)	View 단계 여러 개의 사용자 관점으로 구성, 즉 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB 스키마 DB의 개개 사용자나 응용프로그래머가 접근하는 DB 정의	사용자 관점접근하는 특성에 따른 스키마 구성
개념스키마(Conceptual Schema)	모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마	통합관점
내부스키마 (Internal Schema)	DB가 물리적으로 저장된 형식 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마	물리적 저장구조

---

ERD

데이터 모델에 대한 표기법으로 1976년 피터첸(Peter Chen)이 Entity-Relationship Model(E-R Model)이라는 표기법을 만들었다.

ERD 작성순서

① 엔터티를 그린다. ② 엔터티를 적절하게 배치한다. ③ 엔터티간 관계를 설정한다. ④ 관계명을 기술한다. ⑤ 관계의 참여도를 기술한다. ⑥ 관계의 필수여부를 기술한다.

ER 다이어그램 / ERD 기호 및 표기법 참고

**https://mjn5027.tistory.com/43**

엔터티, 인스턴스, 속성, 속성값의 관계

• 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
• 한 개의 엔터티는 두 개 이상의 속성을 갖는다.
• 하나의 인스턴스에서 각각의 속성은 한 개의 속성값을 갖는다.

---

엔터티(Entity)

필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)

 

엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
• 유일한 식별자에 의해 식별할 수 있어야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다. ('한 개'가 아니라 '두 개 이상')
• 엔터티는 업무 프로세서에 의해 이용되어야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
• 엔터티는 다른 엔터티와 최소한 한 개 이상의 관계가 있어야 한다.

 

발생시점에 따른 엔터티 분류

• 기본엔터티(Fundamental Entity)/키엔터티(Key Entity) : 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 하게 된다. 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다. 예를 들어 사원, 부서, 고객, 상품, 자재 등이 기본엔터티가 될 수 있다.
• 중심엔터티(Main Entity) : 기본엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다. 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성한다. 예를 들어 계약, 사고, 예금원장, 청구, 주문, 매출 등이 될 수 있다.
• 행위엔터티(Active Entity) : 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다. 분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다. 예를 들어 주문목록, 사원변경이력 등이 포함된다.

---

속성

업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

속성의 명칭 부여

• 해당업무에서 사용하는 이름을 부여 한다.
• 서술식 속성명은 사용하지 않는다.
• 약어사용은 가급적 제한한다.
• 전체 데이터모델에서 유일성 확보하는 것이 좋다. (반정규화, 통합 등의 작업에서 혼란을 방지할 수 있음)

속성의 특성에 따른 분류

• 기본속성 : 업무분석을 통해 바로 정의한 속성을 기본속성 (예: 원금, 예치기간, 이자율)
• 설계속성 : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성 (예: 예금분류)
• 파생속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성 (예: 이자)

도메인

각 속성은 가질 수 있는 값의 범위가 있는데 이를 그 속성의 도메인(Domain)이라하며, 엔터티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것이다.

---

데이터 독립성

데이터베이스 내부 구조가 바뀌더라도, 그 위에서 동작하는 프로그램이나 사용자 뷰에 영향을 주지 않는 성질

데이터 독립성이 중요한 이유

만약 데이터 독립성이 없다면:

• 테이블에 컬럼 하나만 추가해도 앱 코드 싹 다 수정해야 함.
• 파일 저장 방식을 바꾸면 모든 프로그램이 에러 날 수도 있음.

각 데이터 독립성 설명

독립성 설명 예시

물리적 독립성	물리적 저장 구조(파일, 색인 등)의 변화가 논리적 스키마(테이블 구조)에 영향을 주지 않음	데이터 파일을 SSD에서 HDD로 옮겨도 테이블 설계는 그대로
논리적 독립성	논리적 스키마(테이블 구조)의 변화가 응용 프로그램(애플리케이션)에 영향을 주지 않음	테이블에 새로운 컬럼 추가해도 프로그램 코드 수정 안 해도 됨
개념적 독립성	사용자 뷰(External Schema)의 변경이 논리적 스키마에 영향을 주지 않음	사용자가 보는 보고서에서 특정 컬럼을 빼도 DB 구조는 그대로
내부적 독립성	→ 사실상 물리적 독립성과 같은 의미로 간주됨 (현대 DBMS에서는 따로 구분 안 하는 경우가 많음)	파일 포맷이 바뀌어도 논리 설계 영향 없음

 

 

뜻 설명

 

External Schema	외부 스키마	사용자가 보는 데이터 구조 (뷰, 애플리케이션에 보여지는 데이터 형태)
Conceptual Schema	개념 스키마	논리적 데이터 구조 (테이블, 속성, 관계 등)
Internal Schema	내부 스키마	실제 데이터가 물리적으로 저장되는 구조 (파일, 색인 등)
view independence	개념적 독립성	사용자 뷰가 변경되어도 논리적 스키마에 영향 없음
Logical Independence	논리적 독립성	개념 스키마가 바뀌어도 외부 스키마(사용자 뷰)에 영향 없음
Physical Independence	물리적 독립성	내부 스키마(물리적 저장 방식)가 바뀌어도 개념 스키마에 영향 없음
User views / Applications	사용자 뷰 / 애플리케이션	최종 사용자가 보는 화면 또는 앱
Logical structure (Tables, Relationships)	논리적 구조 (테이블, 관계)	데이터의 논리적 설계 형태
Physical storage (Files, Indexes)	물리적 저장 (파일, 색인)	실제 데이터가 저장되는 방식

내부 스키마에 있는 데이터들은 물리적 독립성을 가져야 한다?

내부 스키마(데이터 파일 구조나 색인 같은 물리적 구조)가 바뀌더라도 논리적 구조(테이블 구조, 속성 등)에 영향이 없도록 물리적 독립성을 보장해야 한다 는 뜻

 

예시

변화	영향	독립성
데이터 파일 형식 바꿈 (예: CSV → SSD 블록 스토리지)	테이블 구조 안 바뀜	물리적 독립성
테이블에 컬럼 추가	사용자 뷰(앱 화면) 안 바뀜	논리적 독립성

---

관계

관계의 분류

• 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있다.
• UML(Unified Modeling Language)에는 클래스다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있고 이것을 구분하여 연관관계는 실선으로 표현하고, 의존관계는 점선으로 표현한다.
• ERD 에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 단일화된 표기법을 사용한다.

관계의 표기법

• 관계명(Membership) : 관계의 이름
• 관계차수(Cardinality) : 1:1, 1:M, M:N
• 선택사양(Optionality) : 필수관계, 선택관계

관계 체크사항

• 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

관계 읽기

• 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
• 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
• 관계선택사양과 관계명을 읽는다.

---

식별자

식별자의 종류

• 주식별자(Primary Identifier)/보조식별자(Alternate Identifier) : 자신의 엔터티 내에서 대표성을 가지는가에 따라 구분
• 내부식별자/외부식별자(Foreign Identifier) : 엔터티 내에서 스스로 생성되었는지 여부에 따라 구분
• 단일식별자(Single Identifier)/복합식별자(Composit Identifier) : 단일 속성으로 식별이 되는가에 따라 구분
• 본질식별자/인조식별자 : 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분

식별자 종류 특징 예시

주식별자 (Primary Identifier)	엔터티 내에서 인스턴스를 대표하는 유일한 식별자.	주민등록번호, 학번, 사번
보조식별자 (Alternate Identifier)	주식별자는 아니지만 유일성을 보장할 수 있는 다른 후보 식별자.	이메일, 휴대폰번호 (회원 식별)
내부식별자	엔터티 내 자체적으로 생성되는 식별자.	상품번호, 회원번호 (엔터티 내부에서 자동 생성)
외부식별자 (Foreign Identifier)	다른 엔터티(부모 엔터티)로부터 전달받는 식별자.	주문 → 고객ID (고객 테이블에서 가져옴)
단일식별자 (Single Identifier)	하나의 속성만으로 유일하게 인스턴스를 식별할 수 있는 경우.	주민등록번호, 학번
복합식별자 (Composite Identifier)	두 개 이상의 속성을 조합해야 유일하게 식별할 수 있는 경우.	(학생ID + 과목ID) → 수강신청ID
본질식별자	원래 업무적으로 의미를 가진 자연 속성이 식별자가 된 경우.	주민등록번호, 이메일주소 (이미 업무에서 고유하게 존재)
인조식별자	업무적으로 의미는 없지만 시스템 편의를 위해 새로 만든 일련번호형 식별자.	사용자ID(auto increment), 주문번호(UUID)

 

주식별자의 특징

• 유일성 : 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 한다.
• 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
• 불변성 : 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
• 존재성 : 주식별자가 지정이 되면 반드시 값이 들어와야 한다. (Null 안 됨)

 

주식별자 도출기준

• 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
• 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.

 

식별자와 비식별자관계 비교

항목	식별자관계	비식별자관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자 영향	자식 주식별자의 구성에 포함	자식 일반 속성에 포함
표기법	실선 표현	점선 표현
연결 고려사항	반드시 부모엔터티 종속 자식 주식별자 구성에 부모 주식별자포함 필요- 상속받은 주식별자속성을 타 엔터티에 이전 필요	약한 종속관계 자식 주식별자구성을 독립적으로 구성- 자식 주식별자구성에 부모 주식별자 부분 필요- 상속받은 주식별자속성을 타 엔터티에 차단 필요- 부모쪽의 관계참여가 선택관계

---

성능 데이터모델링

데이터베이스 성능 향상을 목적으로 설계단계의 데이터모델링 때부터 성능과 관련된 사항이 데이터모델링에 반영될 수 있도록 하는 것

 

성능 데이터모델링 특징

• 데이터의 증가가 빠를수록 성능저하에 따른 성능개선비용이 증가한다.
• 데이터모델은 성능을 튜닝하면서 변경이 될 수 있는 특징이 있다.
• 분석/설계 단계에서 성능을 고려한 데이터모델링을 수행할 경우 성능저하에 따른 Rework비용을 최소화 할 수 있는 기회를 가지게 된다.

 

성능 데이터모델링 수행절차

1. 데이터 모델링을 할 때 정규화를 정확하게 수행한다.
2. 데이터베이스 용량산정을 수행한다.
3. 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
4. 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
5. 이력모델의 조정, PK/FK 조정, 슈퍼타입/서브타입 조정 등을 수행한다.
6. 성능관점에서 데이터 모델을 검증한다.

---

정규화

데이터를 중복 없이 효율적으로 관리하기 위해 테이블을 쪼개는 과정

 

정규화의 목표

• 중복 제거
• 변경이 일어날 때 오류 방지
• 저장 공간 절약 & 유지보수 편하게

---

1차 정규형

• 모든 속성은 반드시 하나의 값을 가져야 한다. 즉, 반복 형태가 있어서는 안된다.
• 각 속성의 모든 값은 동일한 형식이어야 한다.
• 각 속성들은 유일한 이름을 가져야 한다.
• 레코드들은 서로 간에 식별 가능해야 한다.

예시

비정규형

UserID 이름 구매아이템1

UserID	이름	구매아이템1
1	홍길동	검,방패,활

 

1차 정규형

UserID	이름	구매아이템
1	홍길동	검
1	홍길동	방패
1	홍길동	활

 

---

2차 정규형

• 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다.
• 이것을 물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 칼럼들이 기본키에 종속적이어야 2차 정규형을 만족할 수 있다는 것이다.

예시

구매 테이블

UserID (PK) ItemID (PK) UserName ItemName 구매수량

UserID (PK)	ItemID (PK)	UserName	ItemName	구매수량
1	A	홍길동	검	2
1	B	홍길동	방패	1

 

기본키(PK) → UserID + ItemID (복합키)

 

문제점:

• UserName → UserID에만 종속 (ItemID와는 무관)
• ItemName → ItemID에만 종속 (UserID와는 무관)
• 구매수량 → UserID + ItemID 조합에 종속 (OK)

→ UserName, ItemName은 부분 종속 → 2NF 위반

 

2차 정규화 후

UserID	UserName
1	홍길동

 

Items 테이블

ItemID	ItemName
A	검
B	방패

 

UserItems (구매내역) 테이블

UserID	ItemID	구매수량
1	A	2
1	B	1

---

3차 정규형

• 2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다.

이행적 종속이란?

기본키 → 속성1 → 속성2

즉, PK가 속성1을 결정하고, 속성1이 속성2를 결정하는 관계

 

문제가 되는 이유:

• PK가 아닌 속성이 다른 속성을 좌우하면
• 데이터가 바뀔 때 오류 생기기 쉬움
• 중복 발생 가능성 ↑

예시

UserID (PK)	UserName	직책ID	직책명
1	홍길동	2	팀장
2	김철수	1	사원

 

문제점:

• UserID → 직책ID → 직책명
• 직책명은 UserID로 직접 결정되는 게 아니라 직책ID로 결정됨 → 이행적 종속 발생!
• → 3NF 위반

 

3차 정규화 후

Users 테이블

UserID (PK)	UserName	직책ID
1	홍길동	2
2	김철수	1

 

직책 테이블

직책ID (PK)	직책명
2	팀장
1	사원

---

BCNF (보이스-코드 정규형)

3NF보다 더 엄격하게 키 종속성 검사

(복합키, 후보키가 여러 개일 때 발생하는 특수한 상황 처리)

일반적인 업무에서는 3NF까지만 하면 충분한 경우가 많아요.

---

4차 정규형 (4NF)

3차 정규형을 만족하고 다치 종속이 존재하면 안됨

 

다치 종속이란?

기본키가 아닌 속성들이 서로 독립적으로 여러 개의 값을 가질 때 발생하는 종속관계

 

다치 종속(Multi-valued dependency) 제거

(한 테이블에 두 개 이상의 독립적인 다대다 관계가 있을 때 발생)

 

예시

UserID	취미	보유아이템
1	낚시	검
1	낚시	방패
1	게임	검

 

문제점

• 취미 추가 → 아이템 데이터가 중복 생성됨
• 아이템 추가 → 취미 데이터가 중복 생성됨

→ 중복 데이터 증가 → 수정/삭제 어려움 → 오류 발생 가능성 높음

4차 정규화 후

UsersHobbies 테이블

UserID	취미
1	낚시
1	게임

 

UsersItems 테이블

UserID	보유아이템
1	검
1	방패

---

정규화 요약

단계	제거하는 문제
1NF	반복 속성
2NF	부분 종속
3NF	이행 종속
4NF	다치 종속 (독립적인 다대다 관계의 중복 문제)

---

반정규화

반정규화는 정규화된 엔터티, 속성, 관계에 대해 시스템의 성능향상과 개발(Development)과 운영(Maintenance)의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법을 의미한다. 반정규화는 데이터를 중복하여 성능을 향상시키기 위한 기법이라고 정의할 수 있고 좀 더 넓은 의미의 반정규화는 성능을 향상시키기 위해 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정을 의미한다.

데이터 무결성이 깨질 수 있는 위험을 무릅쓰고 데이터를 중복하여 반정규화를 적용하는 이유는 데이터를 조회할 때 디스크 I/O 량이 많아서 성능이 저하되거나 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나 칼럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 된다.

 

반정규화 절차

반정규화의 대상에 대해 다른 방법으로 처리

• 지나치게 많은 조인(JOIN)이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰(VIEW)를 사용하면 이를 해결할 수도 있다.
• 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우에 클러스터링을 적용하거나 인덱스를 조정함으로써 성능을 향상시킬 수 있다.
• 대량의 데이터는 Primary Key 의 성격에 따라 부분적인 테이블로 분리할 수 있다. 즉 파티셔닝 기법(Partitioning)이 적용되어 성능저하를 방지할 수 있다.
• 응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬 수 있다.

 

핵심 키워드 정리

용어 뜻 비유

뷰(View)	자주 쓰는 쿼리를 미리 저장한 가상 테이블	필요한 페이지 북마크
클러스터링	특정 컬럼으로 데이터 저장 순서를 정렬	책 내용을 챕터별로 정리
인덱스	데이터 검색을 빠르게 하는 목차	책 목차
파티셔닝	테이블을 논리적/물리적으로 나누기	책을 권(Volume)으로 나누기
애플리케이션 로직 변경	프로그램 코드 최적화	검색창에 자동완성 추가하기

 

테이블의 반정규화

기법분류 기법 내용

테이블병합	1:1 관계 테이블병합	1:1 관계를 통합하여 성능향상
	1:M 관계 테이블병합	1:M 관계를 통합하여 성능향상
	슈퍼/서브타입 테이블병합	슈퍼/서브 관계를 통합하여 성능향상
테이블분할	수직분할	컬럼단위의 테이블을 디스크 I/O를 분산처리하기 위해 테이블을 1:1로 분리하여 성능향상(트랜잭션의 처리되는 유형파악이 선행되어야 함)
	수평분할	로우단위로 집중 발생되는 트랜잭션을 분석하여 디스크I/O 및 데이터 접근의 효율성을 높여 성능을 향상하기 위해 로우단위로 테이블을 쪼갬(관계가 없음)
테이블추가	중복테이블 추가	다른 업무이거나 서버가 다른 경우 동일한 테이블구조를 중복하여 원격조인을 제거하여 성능을 향상
	통계테이블 추가	SUM,AVG 등을 미리 수행하여 계산해 둠으로써 조회시 성능을 향상
	이력테이블 추가	이력테이블 중에서 마스터 테이블에 존재하는 레코드를 중복하여 이력테이블에 존재하는 방법
	부분테이블 추가	하나의 테이블을 전체 칼럼 중 자주 이용하는 집중화된 컬럼이 있을 경우, 디스크I/O를 줄이기 위해 해당 컬럼들을 모아놓은 별도의 반정규화된 테이블을 생성

 

컬럼 반정규화

반정규화 기법 내용 장점 단점

중복컬럼 추가	조인시 성능저하를 예방하기 위해,중복된 컬럼을 위치시킴	조회 속도 향상 (조인 안 해도 됨)	여러 테이블에서 같이 수정해야 함 (데이터 중복의 대가)
파생컬럼 추가	트랜잭션이 처리되는 시점에 계산에 의해 발생되는 성능저하를 예방하기 위해, 미리 계산하여 컬럼에 보관	매번 계산 안 해도 돼서 조회 속도 빠름	원본 데이터가 바뀌면 파생 컬럼도 같이 수정해야 함
이력테이블 컬럼추가	대량의 이력데이터 처리시 불특정 일 조회나 최근 값을 조회할때 나타날 수 있는 성능저하를 예방하기 위해 기능성 컬럼(최근값여부, 시작일자,종료일자)을 추가함	"가장 최근 데이터" 같은 조회가 빨라짐	컬럼이 늘어나고 데이터 수정 시 추가 관리 필요
PK에 의한 컬럼추가	복합의미를 갖는 PK를 단일속성으로 구성했을 때 발생되며, PK안에 데이터가 존재하지만 성능향상을 위해 일반속성으로 포함하는 방법	복잡한 조인 안 해도 바로 조회 가능	일반 컬럼이 바뀌면 다 같이 수정해야 해서 유지보수 어려움
응용시스탬 오작동을 위한 컬럼 추가	업무적으로는 의미가 없으나, 데이터 처리시 오류로 인해 원래값으로 복구하길 원하는 경우 이전 데이터를 임시적으로 중복보관하는 방법	오류로 잘못 수정됐을 때 복구 가능	컬럼이 늘어나고, 스토리지(저장공간) 소모 증가

 

대량 데이터발생

로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태가 로우체이닝(Row Chaining) 현상이다. 또한 로우마이그레이션(Row Migration)은 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식이다. 로우체이닝과 로우마이그레이션이 발생하여 많은 블록에 데이터가 저장되면 데이터베이스 메모리에서 디스크와 I/O(입력/출력)가 발생할 때 불필요하게 I/O 가 많이 발생하여 성능이 저하된다.

 

대량 데이터 처리

• RANGE PARTITION : 가장 많이 사용하는 파티셔닝의 기준이다. 대상 테이블이 날자 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리된다면 RANGE PARTITION 을 적용한다. 또한 RANGE PARTITION 은 데이터보관주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하므로(파티션 테이블을 DROP 하면 되므로) 데이터보관주기에 다른 테이블관리가 용이하다.
• LIST PARTITION : PK 가 구성되어 있고 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티셔닝이 되는 LIST PARTITION을 적용할 수 있다. LIST PARTITION은 대용량 데이터를 특정값에 따라 분리 저장할 수는 있으나 RANGEPARTITION 과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.
• HASH PARTITION : HASH PARTITION 은 지정된 HASH 조건에 따라 해슁 알고리즘이 적용되어 테이블이 분리되며 설계자는 테이블에 데이터가 정확하게 어떻게 들어갔는지 알 수 없다. 역시 성능향상을 위해 사용하며 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.

 

데이터베이스 구조와 성능

슈퍼/서브 타입 데이터 모델의 변환기술

• 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
• 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
• 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

 

PK 순서를 결정하는 기준

PK 순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK 순서를 지정해야 한다. 즉 인덱스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낼 수 있다. 앞쪽에 위치한 속성 값이 가급적 ‘=’ 아니면 최소한 범위 ‘BETWEEN’ ‘<>’가 들어와야 인덱스를 이용할 수 있는 것이다.

 

분산 데이터베이스

분산 데이터베이스의 투명성

• 분할 투명성 (단편화) : 하나의 논리적 Relation 이 여러 단편으로 분할되어 각 단편의 사본이 여러 site 에 저장
• 위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요. 위치정보가 System Catalog 에 유지되어야 함
• 지역사상 투명성 : 지역 DBMS 와 물리적 DB 사이의 Mapping 보장. 각 지역시스템 이름과 무관한 이름 사용 가능
• 중복 투명성 : DB 객체가 여러 site 에 중복 되어 있는지 알 필요가 없는 성질
• 장애 투명성 : 구성요소(DBMS, Computer)의 장애에 무관한 Transaction 의 원자성 유지
• 병행 투명성 : 다수 Transaction 동시 수행시 결과의 일관성 유지, Time Stamp, 분산 2 단계 Locking 을 이용 구현

 

분산 데이터베이스 장단점

장점	단점
지역 자치성, 점증적 시스템 용량 확장	소프트웨어 개발 비용
신뢰성과 가용성	오류의 잠재성 증대
효용성과 융통성	처리 비용의 증대
빠른 응답 속도와 통신비용 절감	설계, 관리의 복잡성과 비용
데이터의 강요성과 신뢰성 증가	불규칙한 응답 속도
시스템 규모의 적절한 조절	통제의 어려움
각 지역 사용자의 요구 수용 증대	데이터 무결성에 대한 위협