[SQLD] SQL 개발자 기출유형 모의고사 10회 해설 페이지

데이터 모델은 많은 프로그램이 공통으로 기대는 기반이라 설계 후반이나 운영 중에 바꾸면 영향이 넓게 퍼지는데, 이를 파급효과(Leverage)라 한다.
그래서 모델은 개발 초기에 충분히 검토해 확정해야 하며, 늦게 바꿀수록 수정 비용이 커진다.
간결한 표현은 모델이 업무 요구를 정확하고 간결하게 전달하는 역할을 말한다.
데이터 품질은 중복·비일관 데이터로 생기는 정확성 문제를 가리킨다.
데이터 독립성은 3단계 스키마 구조의 성질로, 모델링이 중요한 이유(파급효과·간결한 표현·데이터 품질)에 들지 않는다.

유무형에 따른 분류에서 형태는 없지만 관리해야 할 개념적 정보는 개념 엔터티로, 보험상품·조직 등이 해당한다.
같은 기준의 다른 분류로 물리적 형태가 있는 유형 엔터티와 업무 수행 중 발생하는 사건 엔터티가 있다.
유형 엔터티는 고객·설계사처럼 물리적 형태가 있는 대상이다.
사건 엔터티는 청구 접수·납입처럼 업무 중 발생하는 대상이다.
행위 엔터티는 발생 시점에 따른 분류라 기준이 다르다.

다른 속성 값을 계산·집계해서 얻는 속성이 파생 속성이며, 납입 내역을 합한 누적납입액이 이에 해당한다.
파생 속성은 원천 값이 바뀔 때마다 함께 갱신해야 하므로 데이터 정합성 관리를 위해 꼭 필요한 경우에만 둔다.
청약서에 적힌 계약 시작일은 업무에서 나온 기본 속성이다.
업무 편의로 부여한 상태코드는 설계 속성이다.
가입 시 정한 월 보험료는 업무에서 나온 기본 속성이다.

계약 하나에 여러 특약이, 특약 하나가 여러 계약에 붙는 M:N 관계를 계약특약이라는 교차 엔터티로 1:N 두 개로 풀어낸 모델이다.
두 관계가 모두 식별 관계라 계약번호와 특약코드를 함께 상속받아 복합 주식별자를 이룬다.
상위 유형(슈퍼타입)이 아니라 두 엔터티 사이의 교차 엔터티다.
식별 관계로 계약번호를 상속하므로 계약 없이 생성될 수 없다.
주식별자는 계약번호와 특약코드의 조합이다.

주식별자는 모든 인스턴스에 반드시 값이 있어야 하는 존재성을 갖춰야 하는데, 질병 청구는 사고접수번호가 비어 있으므로 이를 어긴다.
이런 경우 모든 청구에 값이 생기는 청구번호 같은 속성을 주식별자로 두고 사고접수번호는 일반 속성으로 내린다.
발급된 사고접수번호끼리는 겹치지 않아 유일성 문제는 아니다.
속성 하나로 이루어져 최소성은 충족한다.
한 번 발급된 번호가 바뀌는 상황은 제시되지 않았다.

결정자 상담사가 후보키가 아니므로 BCNF 위반이지만, 종속되는 상담분야가 후보키의 일부(주요 속성)라 3NF는 만족한다.
모든 속성이 어느 후보키에 속해 있어 키가 아닌 속성의 부분·이행 종속이 생기지 않는다.
부분 종속은 키가 아닌 속성에 대한 것이라 2NF 위반이 아니다.
상담분야는 주요 속성이라 이행 종속에 의한 3NF 위반이 아니다.
(상담사, 상담분야)로 분해하면 (고객번호, 상담분야) → 상담사 종속이 보존되지 않는다.

모델의 관계는 자식 테이블의 외래키(FK) 값과 부모 테이블의 기본키(PK) 값이 같은 행을 잇는 조인으로 구현된다.
고객-계약이라면 계약.고객번호 = 고객.고객번호 조건으로 각 계약에 그 계약자 정보를 붙인다.
열 이름이 달라도 값의 의미가 같으면 조인할 수 있다.
1:N 관계의 외래키는 N 쪽(자식) 테이블에 둔다.
조인 조건은 PK 가 아닌 일반 열끼리도 쓸 수 있다.

지급 내역 입력과 청구 상태 변경은 한쪽만 반영되면 데이터가 어긋나므로 하나의 트랜잭션으로 묶어 원자성을 보장해야 한다.
모델에서는 이처럼 함께 생겨야 하는 엔터티·속성 변경을 필수 관계로 표현해 같은 작업 단위임을 드러낸다.
고객은 계약 없이 등록되는 선택 관계라 따로 처리해도 된다.
특약 등록과 설계사 수정은 서로 관련 없는 별개 작업이다.
조회와 출력 기록은 함께 확정해야 할 데이터 변경이 아니다.

NULL 은 알 수 없는 값이라 NULL 끼리 = 로 비교해도 TRUE 가 아니라 UNKNOWN이 되며, 그래서 IS NULL 로 검사해야 한다.
그룹 함수는 NULL 을 제외하고 계산하고, 산술 연산에 NULL 이 섞이면 결과도 NULL 이다.
COUNT(열)은 NULL 을 세지 않고 COUNT(*)만 모든 행을 센다.
NULL 에 어떤 수를 더해도 결과는 NULL 이다.
MAX 는 NULL 을 무시하고 나머지 값 중 최댓값을 구한다.

청구ID 4와 6은 계약 K03·사고일자 03-10·차수 1이 같은 업무상 중복인데, 인조식별자인 청구ID 값만 달라 기본키로는 걸러지지 않았다.
막으려면 (계약번호, 사고일자, 청구차수) 세 속성 조합 전체에 UNIQUE 제약을 걸어야 한다.
인조식별자 PK 는 값만 다르면 같은 업무 데이터도 받아들인다.
계약번호만 UNIQUE면 K01 의 정상적인 여러 청구까지 막힌다.
사고일자·차수만 UNIQUE면 K01 과 K02 의 정상 청구가 충돌한다.

관계형 모델에서 한 속성이 취할 수 있는 원자값들의 집합을 도메인(Domain)이라 하므로 납입주기의 허용값 집합은 도메인이다.
실제 테이블에서는 데이터 타입과 CHECK 제약 등으로 도메인을 구현해 범위 밖 값이 들어오지 못하게 한다.
튜플은 테이블의 한 행, 즉 계약 한 건의 값 묶음이다.
스키마는 테이블 이름과 속성 구성 같은 구조 정의이다.
인스턴스는 어느 시점에 테이블에 실제로 들어 있는 행들의 집합이다.

별칭에 공백·특수문자가 있거나 대소문자를 그대로 두려면 큰따옴표로 감싸야 한다. 예: 월보험료 * 12 AS "연간 보험료"
별칭 앞의 AS 는 생략할 수 있고, 별칭은 SELECT 이후에 처리되는 ORDER BY 에서 쓸 수 있다.
AS 는 선택 사항이라 생략해도 된다.
WHERE 는 SELECT 보다 먼저 처리되어 별칭을 쓸 수 없다.
작은따옴표는 문자열 상수를 나타낼 때 쓴다.

WHERE 가 그룹화보다 먼저 실행되어 50 미만인 계약 2·6·10번이 빠진 뒤 집계되므로 태오 170·한결 160·서윤 150(각 2건)이 남는다.
지호는 남은 행이 1건이라 HAVING 에서 제외되고, ORDER BY 는 SELECT 다음에 처리되어 별칭 합계로 내림차순 정렬된다.
지호 행이 남은 표는 HAVING 조건을 적용하지 않은 결과다.
건수가 3인 표는 WHERE 이전 행으로 COUNT 를 센 결과다.
서윤부터 나온 표는 정렬 방향이 오름차순으로 뒤집혔다.

NULLIF(지급액, 0)은 0을 NULL 로 바꾸므로 102·104는 청구액으로 넘어가 102는 300, 청구액도 NULL 인 104는 COALESCE 결과가 NULL 이다.
103의 지급액 NULL 은 두 WHEN 비교가 모두 UNKNOWN 이라 ELSE 의 심사중이 되고, 104는 지급액이 0이라 부지급이다.
102 기준액이 0인 표는 NULLIF 변환을 빠뜨렸다.
103이 부지급인 표는 NULL 을 0처럼 비교했다.
104 기준액이 0인 표는 모든 인수가 NULL 인 COALESCE 를 0으로 보았다.

Oracle 은 문자와 숫자를 비교하면 문자 쪽을 숫자로 바꾸는 암시적 형변환을 하므로 조건은 TO_NUMBER(상품코드) = 10 으로 처리된다.
그래서 앞자리 0이 사라진 '10'·'010'·'0010' 세 행이 모두 10과 같아 건수는 3이다.
1건은 문자열 '10' 과 정확히 같은 값만 센 결과다.
2건은 '0010' 을 빠뜨린 결과다.
4건은 '100' 이나 '1' 까지 같다고 본 결과다.

검색 CASE 는 위에서부터 처음 참이 되는 WHEN 하나만 적용하므로 큰 기준(1000)을 먼저 두고, 나머지는 ELSE 로 L 을 주어야 한다.
금액이 NULL 인 고객 3은 모든 비교가 UNKNOWN 이라 ELSE 의 L 이 되고, 299인 고객 6은 300 미만이라 L 이다.
㉠은 1500도 첫 조건 300 이상에 걸려 H 가 나오지 않는다.
㉡은 ELSE 가 없어 고객 3·4·6의 등급이 NULL 이 된다.
㉣은 NULL 인 고객 3이 ELSE 로 가서 H 가 된다.

논리 연산자는 NOT → AND → OR 순으로 처리되므로 괄호가 없으면 AND 로 이어진 두 조건이 먼저 묶인다.
따라서 유지 상태 계약은 보험료와 관계없이 모두, 휴면 계약은 보험료 10 이상만 남는 A OR (B AND C) 형태가 된다.
OR 를 먼저 묶으면 유지 계약에도 보험료 조건이 붙는다.
보험료 조건을 유지 쪽에 붙이면 AND 의 결합 대상을 잘못 본 것이다.
휴면을 바깥으로 빼면 유지 계약이 전부 빠진다.

ESCAPE '#' 로 #_ 는 밑줄 문자 그 자체가 되어 패턴은 'CI_' 로 시작하는 값이고, 뒤의 % 는 0글자 이상과 일치하므로 상품번호 1·3·6이 남는다.
CI02·CIX01은 세 번째 글자가 밑줄이 아니라 빠지고, XCI_1은 앞부분이 CI 가 아니라 빠진다.
CI02·CIX01이 포함된 표는 #_ 를 한 글자 와일드카드로 본 결과다.
CI_ 가 빠진 표는 % 가 한 글자 이상을 요구한다고 본 결과다.
XCI_1이 포함된 표는 패턴이 중간에서도 맞는다고 본 결과다.

GROUP BY 가 없으므로 WHERE 로 남은 청구 2·3·4·5·7·8번 6행 전체가 한 그룹이 되어 결과는 1행이다.
지급액 NULL 2건을 뺀 지급건 4, NULL 고객번호를 뺀 고객 11·12·13의 3명, 합계 200+150+50+70=470으로 NULL 은 제외된다.
지급건 6인 표는 COUNT(열)이 NULL 도 센다고 보았다.
고객수 4인 표는 DISTINCT 집계에 NULL 을 포함했다.
합계가 NULL 인 표는 SUM 에 NULL 이 섞이면 NULL 이 된다고 보았다.

㉠은 WHERE 가 그룹화 전에 행 단위로 걸러 청구액 100 이상인 행이 있는 C1·C4만 남아 2행이다.
㉡은 모든 행을 묶은 뒤 HAVING 이 합계를 걸러 C1(150)·C2(110)·C4(200)의 3행이고, C3·C5는 합계 90이라 빠진다.
3, 2는 WHERE 와 HAVING 의 결과를 서로 바꾼 것이다.
2, 2는 C2 처럼 작은 청구를 합쳐 100 이상이 되는 그룹을 놓쳤다.
5, 3은 WHERE 로 행이 모두 빠진 그룹도 남는다고 보았다.

HAVING 은 그룹마다 한 번 평가되므로 GROUP BY 열이나 집계 함수만 쓸 수 있는데, ㉢의 설계사는 그룹화되지 않은 열이라 오류가 난다.
설계사로 거르려면 그룹화 전에 처리되는 WHERE 절로 옮겨야 한다.
㉠은 그룹화 열인 상품코드를 HAVING 에 써서 정상 실행된다.
㉡은 GROUP BY 열을 SELECT 에 쓰지 않아도 되므로 4행이 나온다.
㉣은 그룹별로 서로 다른 설계사 수를 세는 정상 집계다.

Oracle 은 NULL 을 가장 큰 값으로 보아 DESC 에서 맨 앞에 두지만 NULLS LAST 를 지정했으므로 B→A→NULL 순이 된다.
같은 등급 안에서는 두 번째 키 보험료 DESC 로 B(70, 40)·A(90, 50)·NULL(60, 30) 순으로 정렬된다.
NULL 이 맨 앞인 표는 NULLS LAST 를 무시한 기본 DESC 정렬이다.
같은 등급 안에서 보험료가 오르는 표는 두 번째 키를 오름차순으로 보았다.
A 등급이 먼저인 표는 등급을 오름차순으로 정렬했다.

CROSS JOIN 은 조인 조건 없이 모든 행을 짝짓는 카티션 곱이고, WHERE 가 계약 쪽만 '유지' 4행으로 거르므로 4 × 3 = 12행이다.
특약명이 NULL 인 행도 곱하기에서 빠지지 않으며, 조건이 없는 한 NULL 여부는 행 수에 영향을 주지 않는다.
8행은 특약명이 NULL 인 행을 곱하기에서 뺀 결과다.
18행은 WHERE 필터 전 6 × 3 전체 곱이다.
6행은 계약 쪽 행 수만 남는다고 본 결과다.

세 테이블을 N-1 = 2개의 조인 조건으로 모두 이었고 INNER 조인이라 세 테이블 모두에 짝이 있는 청구 100·101·102 세 행만 남는다.
실손 계약에 청구가 둘이라 하늘·실손이 두 번 나오며, 고객번호가 NULL 인 단체상해와 청구 없는 운전자·치아는 빠진다.
2행 표는 한 계약에 청구가 여러 건이면 한 행만 남는다고 보았다.
단체상해 행이 있는 표는 NULL 고객번호도 조인된다고 보았다.
운전자 행이 있는 표는 OUTER 조인처럼 짝 없는 계약을 남겼다.

조인 뒤 WHERE 가 적용되므로 반려 청구 101·103 행이 빠지고, 청구가 없어 상태가 NULL 인 치아 행도 NULL <> '반려' 가 UNKNOWN 이라 제거되어 2행만 남는다.
결국 바깥 조인의 보존 효과가 사라져 INNER 조인과 같아지며, 기준 행을 살리려면 이 조건을 ON 절로 옮겨야 한다.
치아 행이 남은 표는 NULL 이 <> 조건을 통과한다고 보았다.
운전자·치아가 NULL 로 남은 표는 조건을 ON 절에 둔 결과다.
101 행이 남은 표는 WHERE 조건을 적용하지 않았다.

NATURAL JOIN 은 이름이 같은 상품코드·채널 두 열이 모두 같은 행만 결합하고, SELECT * 에서 공통 열을 맨 앞에 한 번만 표시한다.
계약 3은 채널이 NULL 이라 등치 비교가 UNKNOWN 이 되어 빠지고, 계약 5는 (P3, 온라인) 짝이 상품에 없어 빠지므로 계약 1·2·4 세 행이 남는다.
계약 3을 실손A 와 결합한 표는 NULL 인 공통 열을 비교에서 건너뛴다고 본 오해이다.
계약번호를 맨 앞에 둔 표는 공통 열이 앞으로 모인다는 규칙을 놓쳤다.
계약 5를 상품명 NULL 로 남긴 표는 외부 조인처럼 처리한 결과이다.

(+) 가 붙은 계약 쪽은 짝이 없을 때 NULL 로 채워지는 쪽이므로, 보존할 청구를 왼쪽에 둔 LEFT OUTER JOIN 이 같은 결과를 낸다.
C.상태(+) = '유지' 처럼 (+) 가 붙은 조건은 ON 절 조건이 되어, 해지 계약의 청구 2와 계약이 없는 청구 5도 고객명 NULL 로 남는다.
RIGHT OUTER JOIN 은 계약을 보존해 102·104가 청구 NULL 로 나오고 청구 2·5는 빠진다.
INNER JOIN 은 짝이 맞는 청구 세 건만 남겨 NULL 행이 사라진다.
CROSS JOIN 은 조건 없이 모든 행을 곱하는 구문이라 ON 절을 붙이면 오류가 난다.

연관 서브쿼리는 바깥 행 A 의 계약번호를 받아 같은 계약 안의 MAX(청구금액)을 매번 다시 구하므로, 계약마다 최대 금액과 같은 청구가 모두 남는다.
202는 60이 두 건이라 두 건 모두 남고, 204는 MAX 가 NULL 을 무시해 40이 최대가 되며 금액이 NULL 인 청구 6은 = 비교가 UNKNOWN 이라 빠진다.
202에서 한 건만 남긴 표는 동점을 하나로 줄인 것으로, = 비교는 같은 값을 모두 통과시킨다.
204가 빠진 표는 NULL 이 섞이면 MAX 가 NULL 이 된다고 본 오해이다.
청구 6을 넣은 표는 NULL 금액도 최댓값 비교를 통과한다고 본 것이다.

집계 함수만 있는 스칼라 서브쿼리는 대상 행이 없어도 한 행을 돌려주므로, 그 SUM 결과를 COALESCE(SUM(R.금액), 0) 으로 감싸야 청구가 없는 303도 0이 된다.
301은 NULL 을 뺀 100, 302는 70이고, 금액이 NULL 뿐인 304와 청구가 없는 303은 SUM 이 NULL 이어서 0으로 바뀐다.
SUM(R.금액) 만 쓰면 303·304가 NULL 로 나온다.
SUM(COALESCE(R.금액, 0)) 은 304는 0이지만 대상 행이 없는 303은 여전히 NULL 이다.
COUNT(R.금액) 는 금액이 아닌 건수를 세어 301·302가 1이 된다.

<> ALL 은 NOT IN 과 같은 뜻이라 서브쿼리 결과에 NULL 이 있으면 비교가 UNKNOWN 이 되어 여전히 0행이다.
NOT IN (a, NULL) 은 x <> a AND x <> NULL 로 풀리는데, 뒤쪽이 항상 UNKNOWN 이라 전체가 참이 될 수 없다.
서브쿼리에서 NULL 을 걸러 내면 비교 대상에 NULL 이 없어 정상 동작한다.
NOT EXISTS 는 행 존재 여부만 보므로 NULL 의 영향을 받지 않는다.
LEFT JOIN 후 청구 쪽 키가 NULL 인 행만 고르면 청구 없는 계약이 남는다.

UNION 은 합친 결과에서 중복 행을 제거하고 UNION ALL 은 그대로 두므로, 합친 결과에 중복 행이 없다면 두 연산의 행 수는 같다.
이 경우 중복 제거를 위한 정렬·비교 작업이 없는 UNION ALL 이 같은 결과를 더 적은 부하로 낸다.
UNION ALL 은 중복 제거도 정렬도 하지 않으며 순서는 ORDER BY 로만 정해진다.
UNION 은 중복을 판단할 때 NULL 끼리를 같은 값으로 본다.
집합 연산은 모든 SELECT 의 열 개수와 데이터 형이 맞아야 한다.

EXCEPT(MINUS) 는 위 결과에서 아래 결과에 있는 행을 빼고 중복을 제거하므로 (C1, P1) 과 (C4, P3) 두 행만 남는다.
(C1, P2)·(C2, P1)·(C3, NULL) 은 청구에도 있어 빠지는데, 집합 연산은 NULL 끼리를 같은 값으로 비교한다.
(C1, P1) 을 두 행 남긴 표는 EXCEPT ALL 처럼 중복을 유지한 결과이다.
(C3, NULL) 을 남긴 표는 NULL 끼리를 다른 값으로 본 오해이다.
(C5, P3) 만 있는 표는 두 SELECT 의 순서를 바꿔 청구에서 계약을 뺀 결과이다.

CUBE (유형, 채널) 는 (유형, 채널)·(유형)·(채널)·() 네 가지 그룹을 모두 만들므로 상세 5 + 유형 소계 3 + 채널 소계 3 + 총계 1 = 12행이다.
채널이 NULL 인 통원 청구는 상세 그룹 (통원, NULL) 과 채널 NULL 소계를 따로 만들며, 이 소계는 총계와 합쳐지지 않는다.
9행은 ROLLUP 처럼 유형 소계와 총계만 센 값이다.
11행은 채널 NULL 소계를 총계와 같은 행으로 본 값이다.
10행은 채널이 NULL 인 데이터를 상세와 소계 모두에서 뺀 값이다.

GROUPING SETS ((유형, 채널), (유형)) 은 유형·채널 상세와 유형 소계만 만들고 총계는 만들지 않으며, 소계 행의 GROUPING(채널) 만 1이다.
입원의 NULL 채널 50은 원래 데이터의 NULL 이라 G=0 인 상세 행이고, 입원 소계 150은 NULL 채널 금액까지 더한 값이다.
원래 NULL 행에 1을 준 표는 GROUPING 이 집계로 생긴 NULL 에만 1을 준다는 점을 놓쳤다.
총계 행이 있는 표는 () 를 지정하지 않았는데도 전체 합계를 넣었다.
입원 소계를 100으로 쓴 표는 채널이 NULL 인 행을 소계에서 뺀 것이다.

[결과]에는 상품군별 소계(지점 NULL)와 총계만 있으므로, 상품군을 상위 계층으로 둔 ROLLUP (상품군, 지점) 이 맞다.
ROLLUP 은 인수 순서대로 (상품군, 지점), (상품군), () 단계로 집계하며 SELECT 절 열 순서와는 무관하다.
ROLLUP (지점, 상품군) 은 지점별 소계를 만들어 강남·분당 소계 행이 나온다.
CUBE 는 상품군 소계와 지점 소계를 모두 만들어 행이 더 많다.
지점, ROLLUP (상품군) 은 지점별 소계만 만들고 총계 행이 없다.

윈도우 함수는 GROUP BY 가 끝난 뒤 그룹 결과 3행 위에서 계산되므로, 행 수는 고객 수인 3행이고 COUNT(*) OVER () 도 3이다.
SUM(SUM(금액)) OVER () 는 고객별 합계 150·220·30을 모두 더한 400을 각 행에 붙이며, K3 합계는 NULL 을 뺀 30이다.
고객수를 6으로 쓴 표는 윈도우 함수가 원본 행에 적용된다고 본 오해이다.
K3 와 전체를 NULL 로 쓴 표는 집계 함수가 NULL 을 무시한다는 점을 놓쳤다.
전체를 누적 값으로 쓴 표는 ORDER BY 가 없는 OVER () 를 누적 프레임으로 본 것이다.

[결과]에서 강남은 9건 두 명 뒤의 8건까지, 판교는 6건과 동점인 5건 두 명이 모두 나오므로 동점 뒤 순위를 건너뛰지 않는 DENSE_RANK() 가 맞다.
강남 순위는 DENSE_RANK 로 1·1·2·3, RANK 로 1·1·3·4 가 되어 동점 뒤 순위 처리에서 결과가 갈린다.
RANK() 는 강남 8건이 3위가 되어 강남에서 9건 두 명만 남는다.
ROW_NUMBER() 는 동점에도 고유 번호를 주어 판교 5건 중 한 명이 빠진다.
NTILE(2) 는 행을 두 묶음으로 나눌 뿐이라 모든 행이 2 이하가 되어 하린까지 나온다.

OVER 안의 ORDER BY 회차 DESC 때문에 누적은 계약별 마지막 회차부터 거꾸로 쌓이고, 출력 순서는 바깥 ORDER BY 에 따라 회차 오름차순이 된다.
A01은 3회차 100, 2회차는 NULL 을 건너뛴 누적이라 100, 1회차 200이며 B02는 2회차 70, 1회차 120이다.
1회차부터 쌓은 표는 OVER 의 정렬 방향을 바깥 정렬과 같다고 본 것이다.
NULL 이후를 NULL 로 쓴 표는 SUM 이 NULL 을 건너뛴다는 점을 놓쳤다.
계약별 총합을 모든 행에 쓴 표는 OVER 안의 ORDER BY 를 무시한 결과이다.

ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING 은 앞·현재·뒤 한 행씩 세 행 중 최댓값을 구하므로 4월은 NULL·20·60 중 60이다.
LEAD(금액, 1, 0) 의 기본값 0은 다음 행이 없는 5월에만 쓰이고, 2월은 다음 행 금액이 실제 NULL 이라 NULL 이 나온다.
2월 다음을 0으로 쓴 표는 기본값이 NULL 값까지 대신한다고 본 오해이다.
이웃최대가 40·70·70·70·70 인 표는 처음부터 현재 행까지의 누적 프레임으로 계산했다.
5월 다음을 NULL 로 쓴 표는 세 번째 인수인 기본값을 무시했다.

ROWNUM 은 행을 꺼낼 때 1부터 차례로 붙으므로, 첫 행이 ROWNUM 4 이상 조건에서 탈락하면 다음 행도 다시 1을 받아 계속 탈락해 ROWNUM BETWEEN 4 AND 6 은 항상 0행이다.
4~6위를 얻으려면 ROWNUM 을 인라인 뷰 안에서 별칭(RN)으로 고정한 뒤 바깥에서 비교해야 한다.
정렬한 인라인 뷰에서 ROWNUM 을 RN 으로 고정한 뒤 RN >= 4 로 거르면 4~6위가 나온다.
OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY 는 앞 3행을 건너뛰고 다음 3행을 가져온다.
ROW_NUMBER 로 매긴 RN 을 바깥에서 비교하면 4~6위가 정확히 나온다.

7행의 30%는 2.1행인데 TOP n PERCENT 는 소수 행을 올림해 3행을 고르고, WITH TIES 가 세 번째 행과 보험료가 같은 행을 더해 4행이 된다.
보험료 내림차순으로 90·80·70 다음에 같은 70인 계약이 동점으로 함께 나온다.
2행은 2.1을 내림하고 동점도 무시한 값이다.
3행은 올림은 했지만 WITH TIES 를 무시한 값이다.
5행은 동점이 아닌 60까지 포함한 값이다.

SELECT 절의 PRIOR 코드 는 현재 행의 부모 행 값을 돌려주므로, D 행에서는 부모인 B 가 나오고 A 가 아니다.
D 는 A→B→D 경로의 세 번째 단계라 LEVEL 이 3이고, 자식이 없어 CONNECT_BY_ISLEAF 는 1이다.
LEVEL 은 루트를 1로 시작해 한 단계 내려갈 때마다 1씩 늘어난다.
D 아래에는 자식 행이 없으므로 말단 표시가 1이다.
CONNECT_BY_ROOT 는 그 행이 속한 계층의 루트인 A 를 돌려준다.

NOCYCLE 은 K3 의 자식으로 이미 조상인 K1 이 다시 나오는 순환을 만나도 오류 없이 그 행을 내지 않고, 순환을 일으킨 K3 에 CONNECT_BY_ISCYCLE 1을 표시한다.
K1→K2 다음 K2 의 자식 K3·K4 가 형제로 ORDER SIBLINGS BY 고객 순서에 따라 나오며, 자식이 없는 K4 는 순환이 아니므로 0이다.
K4 가 빠진 표는 순환을 만나면 전체 전개가 멈춘다고 본 오해이다.
K1 에 1을 준 표는 다시 방문될 행에 순환 표시가 붙는다고 본 것이다.
LEVEL 4의 K1 을 넣은 표는 NOCYCLE 이 순환 행을 한 번 더 보여 준다고 본 것이다.

PIVOT 은 집계 대상(금액)과 FOR 열(유형)을 뺀 나머지 모든 열로 암묵적 GROUP BY 하므로, 청구번호가 남아 있는 이 쿼리는 원본 4행이 그대로 4행이 된다.
각 행은 자기 유형 칸에만 금액이 들어가고 다른 칸은 NULL 이며, 고객별로 합치려면 인라인 뷰에서 청구번호를 빼고 PIVOT 해야 한다.
고객별 2행으로 합친 표는 청구번호가 그룹 기준이 된다는 점을 놓쳤다.
빈 칸을 0으로 쓴 표는 해당 값이 없을 때 SUM 이 NULL 을 돌려준다는 점을 놓쳤다.
유형 열이 남은 표는 FOR 절의 열이 결과 열로 바뀌며 사라진다는 점을 놓쳤다.

패턴은 LF 또는 NL 로 시작해 하이픈이 0~1개(-?) 온 뒤 숫자 정확히 4개로 끝나야 하므로 LF-2026, NL2027, NL-0007 세 행이 일치한다.
REGEXP_LIKE 는 기본으로 대소문자를 구분하고, ^ 와 $ 앵커가 앞뒤에 다른 문자가 붙는 것을 막는다.
lf-2026 은 소문자라 LF 와 일치하지 않는다.
LFNL-2026 은 선택 그룹이 한 번만 와야 하는데 LF 뒤에 NL 이 붙어 탈락한다.
NL-20261 과 LF-202 는 숫자가 4개가 아니어서 끝 조건을 만족하지 못한다.

INSERT … SELECT 는 조건에 맞는 해지 2행을 해지계약에 복사하고, 이어진 DELETE 가 계약에서 같은 2행을 지워 (4, 2) 가 된다.
상태가 NULL 인 계약은 = '해지' 비교가 UNKNOWN 이라 복사도 삭제도 되지 않고 계약에 남는다.
(3, 2) 는 상태가 NULL 인 행까지 삭제된다고 본 값이다.
(4, 0) 은 INSERT … SELECT 가 행을 넣지 못한다고 본 값이다.
(6, 2) 는 DELETE 의 결과를 반영하지 않은 값이다.

T1 이 이미 읽은 행을 T2 가 수정·커밋해 같은 조회의 값이 달라졌으므로 Non-Repeatable Read 이고, 이를 막는 가장 낮은 수준은 REPEATABLE READ 이다.
REPEATABLE READ 는 트랜잭션이 읽은 행이 끝날 때까지 바뀌지 않게 보장하며, 새 행이 나타나는 팬텀까지 막으려면 SERIALIZABLE 이 필요하다.
격리 수준을 REPEATABLE READ 이상으로 올리면 이 현상은 막을 수 있다.
READ COMMITTED 는 Dirty Read 만 막고 커밋된 수정은 다시 읽을 때 보인다.
SERIALIZABLE 로도 막히지만 가장 낮은 수준은 아니다.

값이 들어 있는 열은 데이터 형을 바꿀 수 없으므로, 숫자 열인 금액을 VARCHAR2 로 MODIFY 하면 열이 비어 있어야 한다는 오류가 난다.
형을 바꾸려면 열 값을 모두 NULL 로 비우거나, 새 열을 ADD 해 값을 옮긴 뒤 기존 열을 지워야 한다.
새 열 추가는 기존 행에 NULL 이 채워지므로 데이터가 있어도 된다.
RENAME TO 는 테이블 이름을 바꾸는 구문으로 정상 실행된다.
DROP COLUMN 은 데이터가 있어도 열과 값을 함께 지운다.

ON DELETE CASCADE 는 부모 행이 삭제될 때 그 행을 참조하는 자식 행도 함께 삭제하므로, 계약 501과 그 청구 2건이 지워져 (2, 3) 이 된다.
다른 계약을 참조하는 청구 3건은 영향을 받지 않고 그대로 남는다.
(2, 5) 는 자식 행을 남기고 FK 만 NULL 로 바꾸는 SET NULL 의 동작이다.
(3, 5) 는 자식이 있으면 부모 삭제를 막는 RESTRICT 의 동작이다.
(2, 4) 는 연쇄 삭제가 자식 한 건에만 적용된다고 본 값이다.

WITH GRANT OPTION 으로 객체 권한을 받은 KIM 은 청구의 SELECT 권한을 다른 사용자에게 다시 부여할 수 있다.
시스템 권한에는 WITH ADMIN OPTION 을 쓰며, 이를 받은 LEE 도 CREATE VIEW 를 다른 사용자에게 줄 수 있다.
LEE 는 ADMIN OPTION 을 받았으므로 CREATE VIEW 를 넘길 수 있다.
KIM 이 받은 권한은 SELECT 뿐이라 INSERT 는 할 수 없다.
ADMIN OPTION 은 시스템 권한용이고 객체 권한에는 GRANT OPTION 을 쓴다.