최종 정리(2)

게시 2024/05/15

By tonyleekorea 36 분읽는 시간

윈도우 함수 - 기출, 실전 자격검증 문제풀기

ROWS BETWEEN과 RANGE BETWEEN
- RANGE BETWEEN - 범위로 판단, 같은 값 존재 확률
- 결과값에 대한 차이점
RANK, DENSE RANK
- RANK: 중복 건너뛴다. (Ex, 1, 1, 3, 4)
- DENSE RANK: 건너뛰지 않는다. (Ex, 1, 1, 2, 3)
OVER(PARTITION BY, ORDER BY) 두 가지 파라미터가 올 수 있다.
윈도 함수의 기본 문법은 다음과 같다.
1 2 3 SELECT 함수명(파라미터) OVER ([PARTITION BY 컬럼1, ...] [ORDER BY 컬럼 A, ...]) FROM 테이블명
- PARTITION BY는 선택 항목이며, 순위를 정할 대상 범위의 컬럼을 설정
- PARTITION BY 구에는 GROUP BY절이 가진 집약 기능이 없으며, 이로 인해 레코드가 줄어들지 않음
- PARTITION BY를 통해 구분된 레코드 집합을 윈도라고 함
- 윈도 함수에는 OVER 문구가 필수적으로 포함
- ORDER BY 뒤에는 SORT 컬럼을 입력(어떤 열을 어떤 순서로 순위를 정할지를 지정)
1 2 3 SELECT 이름, 수학, DENSE_RANK() OVER (ORDER BY 수학 DESC) AS 등수 FROM 점수 ORDER BY 수학 DESC;

계층형 질의 - 34회 기출

PRIOR 자식데이터 = 부모데이터
부모에서 자식으로 가면 순방향(프 자 부 부 자 순)
= 부모데이터 = PRIOR 자식 데이터

LEVEL1	KING	EMPNO
LEVEL2	JAMES	MGR
LEVEL3	SCOTT

현재 JAMES의 MGR이 이전 KING의 EMPNO이다.
LEVEL2의 입장에서 PRIOR 값은 LEVEL1
PRIOR EMPNO = MGR(현재 값/LEVEL2의 MGR)

절차형 PL/SQL - 프로시저, 트리거 차이점

EXCEPTION: 생략 가능
PROCEDURE: 반드시 값이 안 나옴
TRIGGER: 커밋, 롤백 불가, 보통 DML에서 많이 사용
USER DEFINED FUNCTION: 반드시 값이 나옴

데이터모델링

업무 → 데이터 모델화
소프트웨어 개발방법론
- 데이터 구조화
  - 전통적, 업무프로세스에 집중, 절차도에 따른 프로그래밍
  - 정보의 중복, 데이터 퀄리티 떨어짐
- 관계형 데이터베이스
  - 데이터 자체와 관계에 집중, 유기체적
- 객체지향 데이터베이스
  - SQL 적용불가, 복잡

개체(Entity) - 지도 그리는 방법

개체는 데이터베이스에 표현하려는 사물 또는 사건이다.
피터 챈 모델(Peter Chen Model)에서는 개체를 사각형(□)으로 표시한다.
까마귀발 모델(Crow’s Foot Model)에서는 개체를 표 형식으로 표시한다.
업무상 관리하고자 하는 대상

① 도출 - 37회

병원에서 환자를 관리하고자 할 때 엔터티는 관리하고자 하는 대상인 환자이다.

② 특징

속성은 두 개 이상
인스턴스 두 개 이상
하나 이상의 관계
업무 프로세스에 이용

③ 분류

유형에 따른 분류 [유개사 기중행]
- 유형 엔터티
- 개념 엔터티
- 사건 엔터티
- 기본 엔터티
- 중심 엔터티
- 행위 엔터티

속성

① 정의

개체가 가지고 있는 요소 또는 성질이다.
피터 챈 모델(Peter Chen Model)에서는 속성을 타원(⬭)으로 표시한다.
까마귀발 모델(Crow’s Foot Model)에서는 속성을 표 내부에 표시한다.
관리하고 하는 대상(인스턴스)의 특징 및 특성들
- 속성은 열, 인스턴스는 행
- 속성은 인스턴스들의 집합

② 분류 [기설파] - 정의 확인

기본 속성
설계 속성
파생 속성

도메인 - 2문제

① 지정해줄 수 있는 것

데이터 유형, 크기, 제약 조건 - 어떤 값을 가져야 하는가
물리적 데이터 모델링의 경우 CHECK, PRIMARY KEY, …는 도메인(값의 범위)에 해당한다.

관계 - IE 표기법과 BARKER 표기법

엔터티가 가지는 최소 의미 단위, 인스턴스의 구성요소
엔터티와 인스턴스 및 속성과 속성값 간의 관계
존재에 의한 관계와 행위에 의한 관계가 있다.
두 개체(Entitiy) 간의 관계를 정의한다.
피터 챈 모델(Peter Chen Model)에서는 관계를 마름모(◇)로 표시한다.
까마귀발 모델(Crow’s Foot Model)에서는 관계를 다음 표와 같이 표시한다.
까마귀 발은 동일하게 표현 - 1:1 관계, 1:N 관계, N:M 관계
- IE
  - 식별자(PK)를 위에 올리고 나머지 일반 속성을 표 내부에 표시한다.
  - 필수/선택 관계 - 직선과 동그라미로 표현
- BARKER
  - SOFT CELL(둥근 박스), 식별자 표기는 #
  - 필수/선택 관계 - 실선과 점선

식별자

① ERD 표기시 식별자/비식별자 관계 표기법

IE/ Barker 둘다 존재, Barker 표기법은 UID(Unique Identifier) Bar를 사용해서 표기
점선: 비식별자
실선: 식별자

② 주식별자 특징 [유 최 불 존]

모두 만족 시 후보키 가능, 대표로 선정 시 기본키, 나머지는 대체키
- 유일성 - 인스턴스를 유일하게 구분할 수 있는 속성
- 최소성 - 여러 가지 속성을 묶어서도 식별자 가능, 그게 최소여야 한다.
- 불변성 - 한 번 만들면 바뀌지 않아야 한다.
- 존재성 - NOT NULL

③ 식별자 분류

대표성여부 - 주식별자, 보조식별자
- 주: 엔터티내에서 각 어커런스를 구분할 수 있는 구분자, 타 엔터티와 참조관계를 연결할 수 있음
- 보조: 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조관계 연결 불가
스스로 생성여부 - 내부식별자, 외부식별자
- 내부: 스스로 생성되는 식별자
- 외부: 타 엔터티로부터 받아오는 식별자
속성의 수 - 단일식별자, 복합식별자
- 단일: 하나의 속성으로 구성
- 복합: 2개이상의 속성으로 구성
대체 여부 - 본질식별자, 인조식별자
- 본질: 업무에 의해 만들어지는 식별자
- 인조: 인위적으로 만든 식별자

④ 주식별자 도출기준 - 업무에서 자주 이용되는 속성, 이름 명명 지양, 복합 식별자 지양

해당 업무에서 자주 이용되는 속성임
명칭, 내역 등과 같이 이름으로 기술되는 것들은x
복합으로 주식별자로 구성할 경우 너무 많은 속성x

식별자 관계, 비식별자 관계

주식별자
- 자식의 주식별자로 부모의 주식별자 상속
- 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우
- 강한 연결관계 표현, 실선 표기
- SQL 구문 복잡 - PK가 계속 상속되면서 내려가기에 PK 속성 수 증가
비식별자
- 부모 속성을 자식의 일반 속성으로 사용
- 부모 없는 자식이 생성될 수 있는 경우
- 부모와 자식의 생명주기가 다른 경우
- 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가진 경우
- 자식엔터티에 별도의 주식별자를 생성하는 것이 더 유리한 경우
- 약한 연결관계 표현, 점선 표기
- SQL 문장이 길어져 복잡성 증가되는 것 방지
- 불필요한 조인이 많아져서 느려짐

ERD 서술 규칙
- 시선, 좌상에서 우하로 움직여야 한다.
- 관계명 반드시 표기하지 않아도 된다.
- UML은 객체지향 모델링에서만 사용한다.

성능 데이터 모델링 [백종원]

아키텍처(데이터들의 구조) - 주방 개조
- 테이블, 파티션을 정규화 또는 반정규화
- 성능이 가장 좋다.
SQL 명령문 - 요리 빨리
- 조인 수행원리(4문제)
- OPTIMIZER
- 실행 계획(1문제)

성능 데이터 모델링의 개요
- 성능 데이터 모델링: DB 성능향상을 위한 사항이 데이터 모델링에 반영되도록 하는 것
- 수행 시점: 분석/설계 단계, 성능 데이터 모델링 시점이 늦어질수록 재업무 비용이 증가함
- 고려 사항: 정규화 수행, DB 용량 산정과 트랜잭션 유형 파악을 통한 반정규화 수행, 정규화는 무조건 해야 됨

정규화(Normalization) - 방법(정규화 처리 과정)

데이터 분해 과정, 이상현상(anomaly) 제거
반복적인 데이터를 분리하고 각 데이터가 종속된 테이블에 적절하게 배치되도록 하는 것
정규형(NF; Normal Form): 정규화로 도출된 데이터 모델이 갖춰야 할 특성
기본적으로 데이터는 속성간의 함수적 종속성에 근거하여 정규화되어야 한다. 정규화는 선택이 아니라 필수사항
함수적 종속성(FD; Functional Dependency): 결정자와 종속자의 관계, 결정자의 값으로 종속자의 값을 알 수 있음, 데이터들이 어떤 기준값에 의해 종속되는 현상
- 다치 종속(MVD; Multivalued Dependency): 여러 칼럼이 동일한 결정자의 종속자일 때
정규화와 성능: 정규화는 입출력 데이터의 양을 줄여 성능을 향상시킴
- 정규화로 인한 성능 향상: 입력/수정/삭제 시 성능은 항상 향상됨
  - 유연성 증가: High Cohesion & Loose Coupling 원칙에 충실해짐
  - 재활용 가능성 증가: 개념이 세분화됨
  - 데이터 중복 최소화
- 정규화로 인한 성능 저하: 조회 시 처리 조건에 따라 성능 저하가 발생할 수도 있음
  - 데이터 조회 시 조인을 유발하여 CPU와 메모리를 많이 사용하게 됨
    - 반정규화로 해결 가능
    - 조인이 발생하더라도 인덱스를 사용하여 조인 연산을 수행하면 성능 상 단점이 거의 없고, 정규화를 통해 필요한 인덱스의 수를 줄일 수 있음
    - 정규화를 통해 소량의 테이블이 생성된다면 성능 상 유리할 수 있음
정규화 이론
- 1차 2차 3차 보이스코드 정규화는 함수적 종속성에 근거
- 4차 정규화는 다치 종속을 제거
- 5차 정규화는 조인에 의한 이상현상을 제거하여 정규화를 수행함
  - 1차 정규화: 속성의 원자성 확보, 다중값 속성을 분리함, 기본키를 설정
  - 2차 정규화: 부분 함수 종속성 제거, 일부 기본키에만 종속된 속성을 분리함, 기본키가 하나의 칼럼일 때 생략 가능(기본키가 2개 이상의 속성으로 이루어진 경우 부분 함수 종속성을 제거)
    - 부분 함수 종속성
  - 3차 정규화: 이행 함수 종속성 제거, 서로 종속관계가 있는 일반속성을 분리함, 주식별자와 관련성이 가장 낮음(기본키를 제외한 컬럼 간 종속성을 제거)
    - 이행 함수 종속성
  - 보이스코드 정규화(BCNF; Boyce-Codd Normal Form): 후보키가 기본키 속성 중 일부에 함수적 종속일 때 다수의 주식별자를 분리함
    - 기본키를 제외하고 후보키가 있는 경우, 후보키가 기본키를 종속 시키면 분해
    - 결정자 함수 종속성을 제거하는 단계
  - 4차 정규화: 여러 컬럼들이 하나의 컬럼을 종속 시키는 경우 분해하여 다중값 종속성을 제거(다치 종속 분리)
  - 5차 정규화: 조인에 의한 종속성이 발생되는 경우 분해(결합 종속 분리)

① 데이터베이스 정규화 단계

제 1정규형(1NF): 도메인이 원자값으로 구성
- 속성 값 2개 자르기
제 2정규형(2NF): 부분 함수 종속 제거(완전 함수적 종속 관계)
- 부분 함수적 종속성: 기본키의 부분집합이 결정자가 되어버린 현상
제 3정규형(3NF): 이행 함수 종속 제거
보이스-코드 정규형(BCNF): 결정자이면서 후보키가 아닌 함수 종속 제거
제 4정규형(4NF): 다치(다중 값) 종속 제거
제 5정규형(5NF): 조인 종속 제거

② Anomaly(이상)

릴레이션 조작 시 데이터들이 불필요하게 중복되어 예기치 않게 발생하는 곤란한 현상
데이터베이스 이상현상은 다음과 같다.
- 삽입 이상
  - 정보 저장 시 해당 정보의 불필요한 세부정보를 입력해야 하는 경우
  - 삽입할 때 의도와 달리 원하지 않은 값들도 함께 삽입되는 현상
- 삭제 이상
  - 삭제할 때 의도와 달리 원하지 않은 값들도 함께 삭제되는 현상
- 갱신 이상
  - 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

③ 성능

SELECT에서는 JOIN으로 인해 느려질 수 있다.
INSERT, UPDATE에서는 성능 증가
정규화는 성능 모델링 전에 제일 먼저 실행

④ 정규화 주의사항

모든 정규화는 이전 정규화를 만족해야 한다.
정규화시 이상현상은 제거되지만 테이블의 분해로 테이블 조인의 발생이 많아지고, 이는 조회 성능 저하로 이어질 수 있다. (I/O 증가 및 조인 연산 증가)
단일 테이블 조회시엔 데이터 중복이 제거되어 조회 성능이 향상 될 여지가 있다.

반정규화 또는 역정규화(De-Normalization) - 2020 축소

정규화된 엔터티, 속성, 관계에 대해 시스템의 성능향상과 개발과 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법
데이터 중복을 허용하여 조인을 줄이는 DB 성능 향상 방법, 데이터의 무결성을 희생하고 조회 성능 향상
조회속도를 향상시킬 수 있지만 데이터 모델의 유연성은 낮아진다.
반정규화를 위해서는 데이터의 일관성과 무결성을 우선으로 할지 데이터베이스의 성능과 단순화에 우선순위를 둘 것인지를 비교하여 조정하는 과정이 중요하다.
- 테이블 통합, 테이블 분할, 중복 테이블 추가, 중복 속성 추가
반정규화: 데이터 무결성 해침

① 반정규화 대상분석 [대범한 통조림]

대량 범위, 범위 처리(빈도수), 통계 처리, 테이블 조인수

→ 디스크 I/O량이 많아 성능저하, 조인으로 성능저하(경로 멀어서), 컬럼 계산해 읽을 때 성능저하

② 다른방법 유도 [응클뷰](→ 무결성 해치니까!)

응용시스템 변경, 클러스터링/인덱스 조정, 뷰 처리

③ 반정규화 [테속관] - 정의, 의미, 몇 개?

테이블 반정규화
- 병합 : 1:1, 1:M, 슈퍼-서브타입
- 분할 : 수직분할(COL 단위), 수평분할(ROW 단위)로 분할하여 I/O 경감
- 추가 [이부분 통중]
  - 이력 테이블 : 마스터테이블 레코드를 이력테이블에 중복
  - 부분 테이블 : 전체 컬럼 중 자주 이용하는 컬럼들을 모아놓은 별도 테이블
  - 통계 테이블 : SUM, AVG 등 미리 계산, 조회시 성능 향상
  - 중복 테이블 : 서버 다르거나 다른 업무 → 동일한 테이블구조 중복 원격조인 제거
속성 반정규화 [파오이 P중]
- 파생칼럼 추가 : 계산에 의한 성능저하 예방 미리 계산하여 컬럼에 보관(Derived 컬럼)
- 응용시스템 오작동 위한 컬럼 추가 : 사용자 실수 대비 임시로 중복값 저장(이전 데이터 임시적 중복보관, 원래 값 복구 용도)
- 이력테이블 컬럼 추가: 대량처리 위해 기능성 컬럼 추가(최근값 여부, 시작 및 종료일자)
- PK에 의한 컬럼추가 : PK에 데이터 있지만 일반속성으로 PK데이터 포함(편입) - 복합의미 PK 단일속성 구성시 발생
- 중복컬럼 추가 : 조인을 감소시키기 위해 중복 컬럼 위치시킴(경로 단축)
관계 반정규화
- 중복 관계 추가 : 여러 경로를 거친 조인을 방지하기 위해 추가적인 관계를 맺음

[절차]
① 반정규화 대상 조사: 데이터 처리 범위 및 통계성 등 조사
② 다른 방법 검토: 1) 뷰 2) 클러스터링 3) 인덱스 4) 애플리케이션
③ 반정규화 적용: 정규화 수행 후 반정규화 수행

대량 데이터에 따른 성능 - 특징, 언제 발생?

Row Migration : 수정 후 다른 블록 빈 공간에 저장
Row Chaining : row가 너무 길어서 여러 블록에 걸쳐서 저장

디스크 I/O 많이 발생 → 성능 저하 → 1:1 관계로 분리
해결책: 파티셔닝 - 각각의 특징(관리 용이성)
- 리스트 파티셔닝 : 기업 / 대량 데이터
- 레인지 파티셔닝 : 관리 쉽다 / 가장 많이 쓰임 / 숫자값으로 분리
- 해시 파티셔닝 : 관리 어렵 / 데이터 위치 모름

슈퍼타입/서브타입 데이터 모델 변환을 통한 성능 향상

용량 - 그림, 경우에 따른 타입?
- 작은 경우: OneToOne type - 트랜잭션이 개별로 들어간다.
- 큰 경우: 트랜잭션 유형으로 분류
  - Plus type: 공통점/차이점에 따라서 별개로 트랜잭션으로 들어간다.
  - Single type: 전체 통합 - 하나의 통합된 테이블

슈퍼타입/서브타입 데이터 모델: 속성을 할당하여 배치하는 수평 분할된 형태의 모델 (공통 속성은 슈퍼타입으로 모델링하고 차이가 있는 속성은 서브타입으로 구분됨), 변환을 통해 1) 정확하게 업무를 표현할 수 있고 2) 물리적 모델링 시 선택의 폭을 넓힐 수 있음
변환 기준: 데이터 양, 트랜잭션 유형
변환 기술
- 1:1 타입(OneToOne type): 개별로 처리하는 트랜잭션에 대해 개별 테이블 구성, 슈퍼타입과 서브타입 각각 필요한 속성과 유형에 적합한 데이터만 가지도록 분리하여 1:1 관계를 갖도록 함
- 슈퍼/서브 타입(Plus type): 슈퍼타입과 서브타입을 공통으로 처리하는 트랜잭션에 대해 슈퍼타입과 서브타입 각각의 테이블 구성
- All in One 타입(Single type): 일괄 처리하는 트랜잭션에 대해 단일 테이블 구성

분산데이터베이스 - 반정규화와 유사, 데이터 무결성 해침

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

분할 투명성: 하나의 논리적 릴레이션을 여러 단편으로 분할, 그 사본을 여러 Site에 저장
위치 투명성: 사용하려는 데이터 저장 장소가 명시되지 않아도 됨, 위치정보 시스템 카탈로그에 유지
지역사상 투명성: 지역 DBMS와 물리적 DB 사이의 Mapping 보장. 각 지역시스템 이름과 무관한 이름 사용 가능
중복 투명성: DB 객체가 여러 Site에 중복 되어 있는지 알 필요 x
장애 투명성: 구성요소(DBMS, 컴퓨터)의 장애에 무관하게 트랜잭션의 원자성이 유지
병행 투명성: 다수의 트랜잭션을 동시 수행했을 때 결과의 일관성이 유지됨(Time Stamp, 분산 2단계 Locking을 이용하여 구현) - 병렬x

조인 수행 원리(4문제)

① 조인 순서: 항상 두 테이블을 조인함

선행 테이블(First Table, Outer Table, Driving Table, Build Input)
후행 테이블(Second Table, Inner Table, Driven Table, Probe Input): 선행 테이블로부터 입력값을 받아 처리함, 후행 테이블에 걸리는 조인 조건이 성능에 큰 영향을 미침

② 조인 방식: NL 조인 > 소트 머지 조인 > 해시 조인 순서로 발전됨

NL 조인(Nested Loop Join)
- 랜덤 액세스, 대용량 소트 작업시 유리
- 선행 테이블의 데이터 하나씩 순차적으로 조인 (중첩 반복문과 유사함), 선행 테이블 처리 범위가 성능을 결정함 (~ 해시 조인, ↔ 소트 머지 조인은 순서에 무관함), 랜덤 액세스 위주이므로 대용량 데이터 처리 시 불리(유니크 인덱스를 이용하여 소량 테이블 조인할 때 유리함)
- 절차
  - 선행 테이블에서 조건을 만족하는 행을 찾음
  - 후행 테이블에 선행 테이블의 조인키가 존재하는지 확인함
  - 후행 테이블 인덱스에 선행 테이블의 조인키가 존재하는지 확인함
  - 인덱스에서 추출한 ROWID로 후행 테이블을 액세스함
- 조인 결과를 하나씩 바로 출력하여 OLTP 환경에 적합함
소트 머지 조인(Sort Merge Join)
- 조인 칼럼을 기준으로 데이터를 정렬하여 조인한다. 비동등 조인에 대해서도 조인이 가능하다.
- 두 테이블을 개별적으로 스캔한 후 조인(↔ NL 조인은 선행 테이블을 랜덤 액세스 방식으로 조회하며 조인), 대용량 데이터 처리 시 디스크에서 정렬이 진행되므로 성능상 불리, 인덱스 유무가 성능에 큰 영향을 주지 않음 (↔ NL 조인은 인덱스 구성에 크게 영향을 받음)
해시 조인(Hash Join)
- =로 수행하는 동등 조인만 가능하다.(해쉬 함수를 이용하기 때문)
- 결과 행의 수가 적은 테이블을 선행 테이블로 사용
- 해싱 기법을 이용하여 조인을 수행한다. 별도의 저장공간 필요
- 조인 칼럼을 기준으로 동일한 해시 값을 갖는 데이터의 실제 값을 비교하며 조인, 두 테이블의 데이터 차이가 클 때 유리, 1) NL 조인의 랜덤 액세스와 2) 소트 머지 조인의 정렬 작업 부담 해결, 등가 조인에서만 사용할 수 있음, 해시 메모리에서 해시 테이블을 생성하므로 선행 테이블이 작을 때 유리 테이블이 커서 소트 부하가 심할 때 유리함
- OLAP 환경에 적합함

옵티마이저(Optimizer)

사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할 수행. 이러한 최적의 실행 방법을 실행계획(Execution Plan)이라 함
어떤 방법으로 처리하는 것이 동일한 일을 최소의 일량으로 처리할 수 있을지 결정
옵티마이저가 최적의 실행 방법을 결정하는 방식
- 규칙기반 옵티마이저 (RBO, Rule Based Optimizer)
  - 규칙(우선순위)를 가지고 실행계획을 생성 실행계획을 생성하는 규칙을 이해하면 누구나 실행계획을 비교적 쉽게 예측 가능
  - 인덱스를 이용한 엑세스 방식이 전체 테이블 액세스 방식보다 우선 순위가 높음, 이용 가능한 인덱스가 존재하면 전체 테이블 엑세스 방식보다 항상 인덱스를 사용하는 실행계획을 생성
  - 조인 순서를 결정 시 조인 칼럼 인덱스의 존재 유무가 중요한 판단의 기준
- 비용기반 옵티마이저 (CBO, Cost Based Optimizer
  - 비용(예상되는 소요시간, 자원 사용량)이 가장 적은 실행계획을 선택하는 방식
  - 규칙기반 옵티마이저의 단점을 극복하기 위해서 출현
  - 다양한 객체 통계정보와 시스템 통계정보 등 이용, 통계정보 없을 경우 정확한 비용 예측이 불가능해 비효율적 실행계획 생성

인덱스

인덱스는 부정형, LIKE 함수, 묵시적 형변환 사용 x
인덱스 사용시 성능이 저하
- DML - INSERT, UPDATE, DELETE

실행 계획 - 실행 순서(1문제)

들여쓰기 먼저 실행, 같은 레벨인 경우 위부터, 뭉텅이로 처리

정규화, PIVOT/ UN PIVOT, MERGE

참고 자료

Certificate, [SQLD] 개념 및 문제풀이

인기 태그