제1장. 데이터 모델링의 이해
제1절 데이터 모델의 이해
| 발생시점에 따른 엔터티 분류 | ||
| 종류 | 기본/키 엔터티 | ■그 업무에 원래 존재하는 정보. ■ 다른 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 하게 된다. ■ 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다. ex) 사원, 부서, 고객, 상품, 자재 등. |
| 중심 엔터티 | ||
| 행위 엔터티 | ||
데이터모델링이란
- 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실세계의 데이터에 대해 약속된 표기법에 의해 표현되는 과정
- 데이터 베이스를 구축하기 위한 분석/설계의 과정
데이터 모델링 유의점
- 중복
- 비유연성 : 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
- 비일관성
| 데이터 모델링 종류 | 설명 |
| 개념적 데이터 모델링 | 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA수립시 많이 이용. |
| 논리적 데이터 모델링 | 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음. |
| 물리적 데이터 모델링 | 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계 |
| 데이터베이스 스키마 구조 3단계 | 설명 |
| 외부스키마 | |
| 개념스키마 | 통합관점의 스키마구조를 표현한 것 |
| 내부스키마 |
ERD = E-R 다이어그램의 약자.(1976. 피터첸)
영어 약자 해서 : '존재하고 있는 것(Entity)들의 관계(Relationship)을 나타낸 도표(Diagram)' .
여기서 말하는 존재하고 있는 것 = 데이터 -> 데이터들의 관계를 나타낸 도표인 셈이다.
ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않지만 클래스다이어그램에서는 이것을 구분하여 연관관계와 의존관계로 표현한다.
ERD 규칙(출처: https://mjn5027.tistory.com/43)
A는 부모, B는 자식의 관계를 가진 ERD.
'~B로 구성되어 있다' = '~B를 포함하고 있다'
A 테이블의 기본키를 B 테이블이 가지고 있다 = A테이블이 부모 테이블, B테이블이 자식 테이블.
| ERD의 점선과 실선에 따른 관계 구분 | ||
| 구분 | 부모 테이블의 PK를 자식 테이블이 갖나? (부모테이블의 PK가 자식테이블의 FK인가) |
해당 키가 기본키로도 사용되나? (해당 키가 PK의 역할도 수행하나?) |
| 실선 (PK + FK) 1:1 관계 |
O (FK 역할 수행) |
O (부모 테이블의 PK=자식 테이블의 PK) |
| 점선( FK only ) 1:N 관계 |
O (FK 역할 수행) |
X (자식테이블의 PK는 따로 존재) |
엔터티가 성립하려면 다음 5가지 조건을 만족해야 함
1️⃣ 식별 가능 (고유한 PK가 있어야 함)
2️⃣ 속성을 가져야 함 (데이터를 설명하는 특징이 있어야 함)
3️⃣ 두 개 이상의 인스턴스를 가져야 함 (단 하나만 존재하면 엔터티가 아님)
4️⃣ 다른 엔터티와 관계를 가질 수 있어야 함 (고립된 데이터는 속성이 될 가능성이 높음)
5️⃣ 업무적으로 의미가 있어야 함 (단순 데이터가 아니라 관리할 필요가 있어야 함)
✅ 이 조건을 충족하지 않는다면 테이블이 아니라 속성(Attribute) 또는 값(Value)로 관리하는 것이 적절함
└ 위 엔터티의 특징 재정리
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.(예, 환자, 토익의 응시 횟수,..)
- 유일한 식별자에 의해 식별이 가능해야 한다.
- 영속적으로 존재하는 인스턴스의 집합이어야 한다('한 개'가 아니라 '두개 이상')
- 엔터티는 업무 프로세스에 의해 이용되어야 한다.
- 엔터티는 반드시 속성이 있어야 한다.
- 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.(but 공통코드, 통계엔터티의 경우는 관계 생략 가능.)
엔터티(Entity)는 논리 모델(Logical Model)의 개념이고, 테이블(Table)은 물리 모델(Physical Model)의 개념이다.
논리 모델은 비즈니스 개념을 다루고, 물리 모델은 실제 DBMS에 구현되는 형태라고 보면 됩니다.
💡 즉, 논리적 모델링과 물리적 모델링을 의미하는 것이 맞습니다!
ERD 작성 순서
①엔터티를 그린다 → ②엔터티를 적절하게 배치한다. →③엔터티간 관계를 설정한다(1:1, 1:M, N:M).
→④관계명을 기술한다.
→⑤관계의 참여도를 기술한다.(전체 참여, 부분 참여)
→⑥관계의 필수여부를 기술한다.
| 관계 표기법 | 설명 | |
| 관계명(Membership) | ■관계(Relationship)는 두 개 이상의 개체(Entity) 사이의 ■연관성을 의미, 관계의 이름을 관계명이라고 함. ■ 관계명은 보통 동사 형태로 표현. (업무기술서, 장표에 관계 연결을 가능하게 하는 동사(서술)가 있는가.) 요약 : 개체 간의 연관성을 나타내는 이름 ex) "수강한다(Enrolls in)", "구매한다(Buys)" |
|
| 관계차수(Cardinality) | ■ 관계차수(Degree of Relationship)는 관계에 참여하는 개체(Entity)의 개수를 의미. ■ 주로 1차수(단항), 2차수(이항), 3차수(삼항) 관계로 나뉨. 요약 : 관계에 참여하는 개체의 수 ex) 단항(1차수), 이항(2차수), 삼항(3차수) |
|
| 선택성(선택사양) | ■ 선택성(Selectivity) 은 관계에서 한 개체가 다른 개체와 얼마나 관계를 맺을 수 있는지를 나타냄. ■ 관계의 카디널리티(Cardinality) 와 밀접한 관련이 있음. 요약 : 한 개체가 다른 개체와 맺을 수 있는 관계의 수 ex) 1:1, 1:N, N:M / 필수관계 선택관계. |
관계 읽기(관계 도출 시 체크 사항)
■ 기준 엔터티를 한 개 또는 각으로 읽는다.
■대상 엔터티의 관계참여도 즉 개수(하나, 하나 이상)을 읽는다.
■관계선택사양과 관계명을 읽는다.
속성(ATTRIBUTE) : 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위. 업무상 관리가 가능한 최소한의 의미 단위.
속성의 특징
■반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
■정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가진다.
■하나의 속성에는 한 개의 값만을 가진다.
■하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.
엔터티, 인스턴스, 속성, 속성값의 관계
■한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
■한 개의 엔터티는 두 개 이상의 속성을 갖는다.
■한 개의 속성은 한 개의 속성값을 갖는다.
엔터티 명명 기준
| 기준 | 설명 |
| 업무적으로 의미 있는 이름 사용 | 비즈니스 용어 기반으로 작성 |
| 단수형 명사 사용 | 개별 엔터티를 나타내므로 단수형으로 작성 |
| 데이터 성격을 정확히 반영 | 모호한 단어 대신 구체적인 용어 사용 |
| 혼동할 수 있는 단어 피하기 | 유사하지만 다른 개념은 명확히 구분 |
| 업무 규칙 반영 | 도메인(업무)에서 사용하는 용어를 반영 |
| 약어 사용 시 일관성 유지 | 표준 약어를 정하고 일관되게 적용 |
| 기술적인 용어 배제 | "_테이블", "_데이터" 같은 기술 용어 제외 |
<속성의 분류>
| (1) 속성의 특성에 따른 분류 | 설명 | 예시 |
| 기본 속성 | 업무로부터 추출한 모든 속성, 가장 일반적이고 많은 속성을 차지한다. |
이자율, 원금, 예치기간 |
| 설계 속성 | 데이터 모델링을 위해, 업무를 규칙화하기 위해 새로 만들거나 변형하여 정의하는 속성이다.
|
예금 분류 |
| 파생 속성 | 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다. (데이터 조회 빠르게 하려고)
|
이자 |
| (2) 엔터티 구성 방식에 따른 분류 | 설명 |
| PK 속성 | 엔터티를 식별할 수 있는 속성 |
| FK 속성 | 다른 엔터티와의 관계에서 포함된 속성 |
| 일반 속성 | PK, FK에 포함되지 않은 속성
|
| (3) 단순형 vs 복합형 | 설명 |
| 단순 속성 |
|
| 복합 속성 |
|
| (4) 단일값 vs 다중값 | 설명 |
| 단일값 속성 | 속성 하나에 한 개의 값을 가지는 경우
|
| 다중값 속성 | 여러 개의 값을 가지는 경우
|
도메인
- 각 속성이 가질 수 있는 값의 범위이다.
- 엔터티 내에서 속성에 대한 데이터 타입과 크기, 제약사항을 지정하는 것이다.
- not null , check 조건 등
식별자와 비식별자관계 비교
| 항목 | 식별자관계 | 비식별자관계 |
| 목적 | 강한 연결관계 표현 | 약한 연결관계 표현 |
| 자식 주식별자 영향 | 자식 주식별자의 구성에 포함됨 | 자식 일반 속성에 포함됨 |
| 표기법 | 실선 표현 | 점선 표현 |
| 연결 고려사항 | -반드시 부모엔터티 종속 -자식주식별자구성에 부모 주식별자 포함 필요. -상속받은 주식별자속성을 타 엔터티에 이전 필요 |
-약한 종속관계 -자식 주식별자구성을 독립적으로 구성 -자식 주식별자구성에 부모 주식별자 부분 필요. -상속받은 주식별자속성을 타 엔터티에 차단 필요 -부모쪽의 관걔참여가 선택관계 |
식별자의 종류
■엔터티 내에서 대표성을 가지는가의 여부 → 주식별자 vs 보조식별자
■엔터티 내에서 스스로 생성되었는지 여부 → 내부식별자 vs 외부식별자
■단일 속성으로 식별이 되는가 여부 → 단일식별자 vs 복합식별자
■원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위함 → 본질식별자(ex.사번) vs 인조식별자()
식별자의 분류 체계
| 분류 | 식별자 | 설명 |
| 대표성 여부 | 주식별자 | 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자. 타 엔터티와 참조관계를 연결할 수 있는 식별자 |
| 보조식별자 | 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나, 대표성을 가지지 못해 참조관계 연결을 못함 | |
| 스스로 생성 여부 | 내부식별자 | 엔터티 내부에서 스스로 만들어지는 식별자 |
| 외부식별자 | 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자 | |
| 속성의 수 | 단일식별자 | 하나의 속성으로 구성된 식별자. |
| 복합식별자 | 둘 이상의 속성으로 구성된 식별자 | |
| 대체 여부 | 본질식별자 | 업무에 의해 만들어지는 식별자 |
| 인조식별자 | 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자 |
주식별자가 갖는 특징.
■ 유일성 : 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다.(사람 이름은 동명이인 가능성이 있어 적절치 x, 같은 맥락으로 명칭이나 내역과 같이 이름으로 기술되는 것도 부적절.)
■ 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
■불변성 : 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
■존재성: 주식별자가 지정이 되면 반드시 데이터 값이 들어와야 한다. (Null 안됨)
주식별자 도출 기준
■ 해당 업무에서 자주 이용되는 속성.
■ 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않음.
■ 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
자주 수정되는 속성이 주식별자가 되면 자식 엔터티에 대한 연쇄 수정이 필요하여 시스템 상에 부하 원인이 될 수 있기 때문에 부적절
제2절 엔터티
제3절 속성
제4절 관계
제5절 식별자
제2장. 데이터 모델과 성능
제1절 성능 데이터 모델링의 개요
성능데이터모델링이란?
데이터베이스 성능 향상을 목적으로 설계 단계의 데이터모델링 때부터 성능과 관련된 사항이 데이터모델링에 반영될 수 있도록 하는 것.
성능 데이터 모델링 수행 절차.
① 데이터모델링을 할 때 정규화를 정확하게 수행한다.
② 데이터베이스 용량산정을 수행한다.
③ 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
④ 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
⑤ 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행한다.
⑥ 성능관점에서 데이터모델을 검증한다.
제2절 정규화와 성능
https://belle-sooir.tistory.com/174
반정규화 vs 정규화 차이 방법 비교 예시
정규화가 항상 조회 성능을 저하시킨다는 것은 잘못된 생각. 기본적으로 중복된 데이터를 제거함으로써 조회성능을 향상시킬 수 있음. ✅ 1. 정규화(Normalization)정규화는 데이터 중복을 최소화
belle-sooir.tistory.com
[SQL] 1차 2차 3차 정규화 개념 및 사례 정리
현재 SQLD 자격증을 공부 중이다. 이론부터 시작해서 실습으로 넘어갈 생각!! 정규화 목적 1. 데이터 중복을 최소화한다. 같은 속성을 지닌 데이터가 테이블에 중복해서 나타나는 경우가 생깁니다
dewworld27.tistory.com
1차 정규화 대상 : 중복속성에 대한 분리= 모든 속성이 원자값(Atomic Value)이어야 함 (= 반복되는 그룹이 없어야 함)
○로우단위의 중복,
○ 칼럼 단위 중복.
eX)
칼럼에 의한 반복적인 속성값을 갖는 형태 (속성의 원자성을 위배했기 때문에.)
eX)
일재고
| 물류센터코드 재고일자 |
| 월초재고수량 장기재고1개월수량 장기재고2개월수량 장기재고3개월수량 장기재고1개월주문수량 장기재고2개월주문수량 장기재고3개월주문수량 장기재고1개월금액 장기재고2개월금액 장기재고3개월금액 장기재고1개월주문금액 장기재고2개월주문금액 장기재고3개월주문금액 |
컬럼 단위에서 중복된 경우도 1차 정규화의 대상이 된다.
이에 대한 분리는 1:M 관계로 두개의 엔터티로 분리된다.
🔹 반복 그룹 예시 (1NF를 만족하지 않는 테이블)
아래처럼 한 학생이 여러 개의 과목을 듣는 경우, 하나의 행(Row)에 여러 개의 과목이 들어가 있습니다.
학번학생명수강과목1수강과목2수강과목3
| S001 | 홍길동 | 수학 | 영어 | 과학 |
| S002 | 김철수 | 국어 | 수학 | NULL |
🔍 이 테이블이 1NF를 만족하지 않는 이유:
- 한 개의 컬럼(수강과목1, 수강과목2, 수강과목3)이 동일한 속성을 여러 개 나눠서 표현하고 있음
- 학생마다 수강하는 과목 수가 다를 경우 NULL이 발생 (컬럼 개수가 고정될 수 없음)
- 과목을 추가하려면 새로운 컬럼이 필요 (예: 수강과목4 추가 필요)
- 검색 및 수정이 어려움 (예: 수학을 듣는 모든 학생을 찾고 싶을 때, 수강과목1, 수강과목2, 수강과목3을 모두 검색해야 함)
🔹 1NF 적용 후 (정규화된 테이블)
반복 그룹을 제거하고 각 속성(컬럼)이 원자적 값을 가지도록 테이블을 변환합니다.
✅ 정규화된 테이블 (1NF 적용)
학번학생명수강과목
| S001 | 홍길동 | 수학 |
| S001 | 홍길동 | 영어 |
| S001 | 홍길동 | 과학 |
| S002 | 김철수 | 국어 |
| S002 | 김철수 | 수학 |
🔍 1NF 적용 후 개선된 점
✅ 각 속성이 원자적(Atomic) 값만 가짐
✅ 반복 그룹 제거 → 테이블 구조가 유연해짐
✅ 과목을 추가해도 새로운 컬럼을 만들 필요 없음
✅ 과목 검색이 쉬워짐 (예: 수학을 듣는 학생을 WHERE 수강과목 = '수학'으로 쉽게 조회 가능)
2차 정규화 대상 : 부분 함수 종속 제거 (= 기본키의 일부분에만 종속된 속성이 없어야 함)
매각기일은 일자별로 매각이 시행되는 장소와 시간을 의미하는 것으로, 일자별매각물건 엔터티의 매각시간, 매각장소 속성은 두 개의 주식별자 속성 중 매각일자에만 종속되기 때문에 2차 정규화 대상이 된다.
eX)
[수강지도]
| 학번 과목코드 |
| 성적 지도교수명 학과명 |
함수종속성
1. 학번 || 과목번호 → 성적
2. 학번 → 지도교수명
3. 학번 → 학과명
PK에 대해 반복이 되는 그룹이 존재하지 않으므로 1차 정규형이라고 할 수 있으며, 부분함수종속의 규칙을 가지고 있으므로 2차 정규형이라고 할 수 없음. 2차 정규화의 대상이 되는 엔터티.
🔥 부분 함수 종속이 존재하는가?
속성결정되는 값종속성 유형
| (학번, 과목번호) → 성적 | 성적은 학번과 과목번호가 함께 결정해야 하므로 부분 종속 아님 (✅ 정상) | |
| 학번 → 지도교수명 | 학번만으로 지도교수명이 결정됨 → 부분 함수 종속 발생! (❌ 2NF 위반) | |
| 학번 → 학과명 | 학번만으로 학과명이 결정됨 → 부분 함수 종속 발생! (❌ 2NF 위반) |
즉, "지도교수명"과 "학과명"이 기본키 전체(PK: 학번, 과목번호)에 종속되지 않고, "학번" 하나에만 종속되어 있기 때문에 2차 정규화를 위반한 상태!
2NF를 만족시키기 위해 "학생 정보(지도교수명, 학과명)"를 분리해야 함
제3절 반정규화와 성능
반정규화 : 데이터를 중복하여 성능을 향상시키기 위한 기법(좁은의미)
성능을 향상시키기 위해 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정(넓은 의미)
반정규화(Denormalization)**는 성능을 최적화하기 위해 정규화된 데이터 모델을 일부 해제하는 과정입니다.
다량 데이터 탐색 방법 : 인덱스, 파티션, 데이터 클러스터링 등의 다양한 물리 저장 기법 활용하여 성능 개선.
but 하나의 결과셋을 추출하기 위해 다량의 데이터를 탐색하는 처리가 반복적으로 빈번하게 발생할 경우 -> 반정규화 고려하는 것이 바람직.
테이블의 반정규화
| 기법분류 | 반정규화 기법 | 설명 |
| 테이블 병합 | 1:1관계 테이블 병합 | ● 1:1 관계를 가지는 두 테이블을 하나로 합치는 방법 ● 주로 자주 JOIN되거나, 하나의 엔터티로 관리하는 것이 더 적절한 경우 적용 |
| 1:M관계 테이블 병합 | ● 1:N 관계를 가지는 부모-자식 테이블을 하나로 합치는 방법 ● 보통 자주 조회하는 데이터를 함께 저장하여 JOIN을 최소화하는 목적 |
|
| 슈퍼/서브타입 테이블병합 | ● 슈퍼타입-서브타입 관계를 하나의 테이블로 합치는 방법 ● 보통 상속 개념이 적용된 데이터 모델에서 사용 |
|
| 테이블 분할 | 수직분할 | ● 컬럼이 너무 많아 조회 성능이 저하될 경우, 자주 사용하는 컬럼과 잘 사용되지 않는 컬럼을 분리하는 기법 ✅ 장점: 주요 컬럼만 조회할 때 성능이 향상됨 ❌ 단점: 고객의 전체 정보를 조회하려면 JOIN이 필요함 |
| 수평분할 | ● 데이터 양이 많아질 경우, 레코드를 기준으로 여러 개의 테이블로 분리하는 기법 ● 날짜별, 지역별, 상태별로 데이터를 나누어 성능을 최적화 ✅ 장점: 특정 연도의 주문 데이터만 조회하면 성능 향상 ❌ 단점: 연도별로 데이터를 합쳐서 조회할 경우 JOIN이 필요함 |
|
| 테이블 추가 | 중복테이블 추가 | ● 자주 조회되는 데이터를 미리 계산하여 별도의 테이블에 저장하는 기법 ● 집계 데이터를 빠르게 조회해야 할 때 유용 ✅ 장점: 고객별 총 구매금액을 빠르게 조회 가능 ❌ 단점: 주문이 추가될 때마다 총 구매금액을 업데이트해야 함(데이터 관리 부담 증가) |
| 통계테이블 추가 | ● 대량의 데이터를 실시간으로 연산하지 않고, 미리 집계하여 저장하는 테이블 ● 주로 리포트, 분석, 대시보드 등의 성능 최적화에 사용 |
|
| 이력테이블 추가 | ● 기존 테이블의 변경 이력을 추적하기 위해 과거 데이터를 저장하는 테이블을 추가하는 방법 ● 주로 로그 데이터, 주문 상태 변경 기록, 사용자 변경 내역 등을 관리할 때 사용 |
|
| 부분테이블 추가 | ● 원본 테이블의 일부 데이터를 별도로 저장하여 관리하는 방식입니다. ● 특정 기준(예: 날짜, 지역, 상태 등)으로 데이터를 나누어 별도 테이블로 관리하는 기법입니다. ● 주로 대용량 데이터의 성능 최적화를 위해 사용됩니다. |
칼럼의 반정규화
| 반정규화 기법 | 설명 |
| 중복칼럼 추가 | 조인 감소를 위해 여러 테이블에 동일한 칼럼을 갖도록 한다. |
| 파생칼럼 추가 | 조회 성능을 우수하게 하기 위해 미리 계산된 칼럼을 갖도록 한다. |
| 이력테이블 칼럼 추가 | 최신값을 처리하는 이력의 특성을 고려하여 기능성 칼럼을 추가한다. |
| PK에 의한 칼럼 추가 | |
| 응용시스템 오작동을 위한 칼럼 추가 |
✅ 주문 테이블, 주문목록 테이블, 제품 테이블에서 "단가 합산 컬럼"을 어디에 추가해야 할까?
📌 주어진 테이블 구조
- 주문 테이블 (Orders)
- 주문번호 (order_id)
- 주문목록 테이블 (Order_Items)
- 주문번호 (order_id)
- 제품번호 (product_id)
- 제품 테이블 (Products)
- 제품번호 (product_id)
- 단가 (unit_price)
🔹 "단가 합산 컬럼"을 어디에 추가하는 게 가장 적절할까?
단가 합산 컬럼은 **"주문에 포함된 모든 제품의 총 가격"**을 의미합니다.
즉, 하나의 주문(order_id) 기준으로 모든 제품(product_id)의 단가(unit_price) 합계를 저장하는 컬럼이 필요합니다.
📍 결론: "주문 테이블(Orders)"에 추가하는 것이 가장 적절함! ✅
- 주문별로 전체 금액을 미리 저장하면 조회 성능이 향상됨
- 주문 테이블에서 단가 합산을 저장하면 불필요한 연산을 줄이고, 빠르게 조회 가능
📌 주문 테이블(Orders) 컬럼 추가 예시
주문번호 (order_id)총 주문 금액 (total_price)
| 1001 | 120,000 |
| 1002 | 80,000 |
반정규화 대상에 대해 다른 방법으로 처리
●지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰(VIEW)를 사용하면 이를 해결할 수도 있다.( 데이터를 조회할 때 너무 많은 JOIN이 필요하면, 이를 단순화하기 위해 뷰(VIEW)를 사용할 수 있다. )
- 뷰는 가상 테이블이며 실제 데이터를 저장하지 않음.
뷰를 사용하여 조인 최적화 예제
📍 문제 상황:
- 주문(Orders), 주문목록(Order_Items), 제품(Products), 고객(Customers) 테이블이 있고, 고객별 주문 내역을 조회해야 함
- 매번 복잡한 조인 쿼리를 실행하면 성능 저하와 코드 관리 어려움 발생
📌 기존 복잡한 SQL (JOIN 여러 개 포함)
❌ 문제점:
- JOIN이 많아서 쿼리가 복잡하고, 여러 테이블을 매번 조인해야 하므로 성능 저하 가능
- 동일한 조회를 여러 번 수행해야 하면 매번 긴 SQL을 작성해야 하는 번거로움
✅ 3. 뷰를 사용하여 해결하기
📌 뷰 생성 (복잡한 조인 쿼리를 미리 저장)
📌 뷰를 사용한 간단한 조회
✅ 뷰를 사용하면:
- 매번 JOIN을 직접 작성할 필요 없이 간결한 SQL로 데이터 조회 가능
- 쿼리 실행 시간이 단축될 수 있으며, 코드 재사용성이 높아짐
- 데이터 모델이 변경되더라도 뷰만 수정하면 다른 쿼리는 그대로 유지 가능
● 대량의 데이터처리나 부분처리에 의해 성능이 저하되는 경우에 클러스터링을 적용하거나 인덱스를 조정함으로써 성능을 향상시킬 수 있다.
-비슷한 데이터를 물리적으로 가깝게 저장하여 검색 성능을 향상시키는 기법
-데이터를 자주 정렬된 상태로 조회해야 할 경우 유용
🔹 클러스터링(Clustering)이란?
- 비슷한 데이터를 물리적으로 가깝게 저장하여 검색 성능을 향상시키는 기법
- 데이터를 자주 정렬된 상태로 조회해야 할 경우 유용
📌 클러스터링 적용 전 문제점
- 데이터가 랜덤하게 저장되어 검색 시 많은 디스크 I/O가 발생
- 예를 들어, 날짜별로 데이터를 조회하는 경우 데이터가 섞여 있으면 검색 속도가 느려짐
📌 예제 (비효율적인 데이터 저장 방식)
주문번호고객ID주문날짜| 1021 | C001 | 2024-02-03 |
| 1022 | C002 | 2024-01-10 |
| 1023 | C003 | 2024-02-01 |
| 1024 | C004 | 2024-01-15 |
날짜별 정렬 없이 저장되면 "2024년 1월의 주문"을 찾을 때 전체 테이블을 스캔해야 함 → 비효율적
✅ 클러스터링 적용 후 (정렬된 상태로 저장)
- 데이터를 주문날짜 기준으로 **클러스터링 인덱스(Clustered Index)**를 적용
- 이제 "2024년 1월" 데이터를 빠르게 조회 가능
📌 클러스터링 인덱스 적용 SQL
✅ 결과:
- 데이터가 물리적으로 정렬되어 저장되므로 날짜별 검색 속도 향상
- 디스크 I/O 최소화
🔹 인덱스(Index)란?
- 데이터 검색 속도를 향상시키기 위해 별도로 생성하는 자료구조
- WHERE, JOIN, ORDER BY 절에서 자주 사용되는 컬럼에 적용
📌 인덱스 미적용 문제점
- 테이블이 커지면 검색 시 Full Table Scan(전체 검색)이 발생
- 특정 조건으로 데이터를 찾을 때 속도가 매우 느려짐
📌 예제 (인덱스 없는 검색)
❌ 문제점:
- customer_id에 인덱스가 없으면, 모든 레코드를 검사해야 하므로 속도 저하 발생
✅ 인덱스 조정으로 성능 향상
- 기본 인덱스 추가 (B-Tree Index)
- customer_id 기준으로 빠르게 검색 가능
- ✅ 효과: 특정 고객의 주문 내역을 빠르게 조회
-
sql복사편집CREATE INDEX idx_customer_id ON Orders(customer_id);
- 복합 인덱스(Multi-Column Index)
- 두 개 이상의 컬럼을 조합하여 검색 성능 최적화
- ✅ 효과: 특정 고객이 특정 날짜에 주문한 내역을 더 빠르게 조회
-
sql복사편집CREATE INDEX idx_order_search ON Orders(customer_id, order_date);
- 커버링 인덱스(Covering Index)
- 조회할 모든 컬럼을 포함하는 인덱스
- ✅ 효과: 테이블을 직접 조회하지 않고 인덱스만으로 데이터를 검색할 수 있음
-
sql복사편집CREATE INDEX idx_order_summary ON Orders(customer_id, order_date, order_amount);
● 대량의 데이터는 Primary Key의 성격에 따라 부분적인 테이블로 분리할 수 있다. 즉 파티셔닝 기법이 적용되어 성능저하를 방지할 수 있다.
● 응용 어플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬 수 있다.
파티셔닝이란? : 하나의 테이블에 많은 양의 데이터가 저장되면 인덱스를 추가하고 테이블을 몇 개로 쪼개도 성능이 저하되는 경우가 있다. 이때 논리적으로는 하나의 테이블이지만 물리적으로는 여러 개의 테이블로 분리하여 데이터 액세스 성능도 향상시키고, 데이터 관리방법도 개선할 수 있도록 테이블에 적용하는 기법.
PK순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를 지정해야 한다. 즉 인덱스의 특징은 여러갱의 속성이 하나의 인덱스로 구성되어 있을 때 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스라 좋은 효율을 나타낼 수 있다. 앞쪽에 위차한 속성 값이 가급적 '='아니면 최소한 범위 'Between' '<>'가 들어와야 인덱스를 이용할 수 있다.
sql문의 where 조건에서 '=' 로 들어온 조건에 해당하는 칼럼이 인덱스의 가장 앞쪽에 위치할 때 인덱스의 이용 효율성이 가장 높다.
엔터티 간에 논리적 관계가 있을 경우(= 엔터티 간에 관계를 정의하여 관련 엔터티 상호간에 업무적인 연관성이 있음을 표현한 경우)에는, 이 데이터들이 업무적으로 밀접하게 연결되어 상호간에 조인이 자주 발생한다는 것을 의미하는 것이기 때문에, 데이터베이스 상에서 DBMS가 제공하는 FK Constraints를 생성했는지 여부와 상관없이 조인 성능을 향상시키기 위한 인덱스를 생성해주는 것이 좋다. 그러므로 수강신청테이블의 학사기준번호에 인덱스가 필요하다.
제4절 대량 데이터에 따른 성능
제5절 데이터베이스 구조와 성능-
제6절 분산 데이터베이스와 성능
| 분산데이터베이스 장단점 | |
| 장접 | 단점 |
| -지역 자치성, 점증적 시스템 용량 확장 -신뢰성과 가용성 -효용성과 융통성 -빠른 응답 속도와 통신비용 절감 -데이터의 가용성과 신뢰성 증가 -시스템 규모의 적절한 조절 -각 지역 사용자의 요구 수용 증대 |
-소프트웨어 개발 비용 -오류의 잠재성 증대 -처리 비용의 증대 -설계, 관리의 복잡성과 비용 -불규칙한 응답 속도 -통제의 어려움 -데이터 무결성에 대한 위협 |
| 분산데이터베이스 적용 가능성 | |
| 가능 | 불가능 |
| 공통코드(마스터 데이터를 한 곳에 두고 운영하는 경우) 기준정보( 마스터 데이터를 한 곳에 두고 운영하는 경우) 백업 사이트 구성 |
GSI(global single instance) |
참고자료 : sql 자격검정 실전문제
'자격증 > sqld' 카테고리의 다른 글
| [sqld 2장]PL/SQL 구문에서의 DML, DCL, DDL 사용법 (0) | 2025.03.05 |
|---|---|
| maria db 테이블에 데이터 넣기 (0) | 2025.02.20 |
| maria db 테이블 생성하기 (0) | 2025.02.20 |
| 10061 Can't connect to server on 문제 해결 방법 (0) | 2025.02.20 |
| [sqld 과목2]SQL Server 과 Oracle 차이점 정리 & connect by prior (0) | 2025.02.13 |
