[7급 국가직 데이터베이스론] 21년 1회차 기출문제 정답·해설 페이지

SELECT는 데이터 조작어(DML)이지만 REVOKE는 권한을 회수하는 데이터 제어어(DCL)이므로, 둘을 함께 DML로 묶은 설명이 옳지 않다.
DML에는 SELECT·INSERT·UPDATE·DELETE가, DCL에는 GRANT·REVOKE가 속한다.
SQL은 관계 DBMS의 표준 언어라는 설명은 옳다.
데이터 정의·질의·갱신 문을 모두 갖춘 포괄적 언어라는 설명도 옳다.
트랜잭션의 완료·철회를 COMMIT·ROLLBACK으로 표현한다는 설명도 옳다.

회복 후 값은 A=20, B=12, C=30, D=15이다.
검사점 이전에 완료된 T1은 처리하지 않고, 검사점 이후 commit 기록이 있는 T4는 redo, commit 기록이 없는 T2·T3는 undo한다.
T4 redo: D를 15로, A를 20으로 다시 반영한다.
T2 undo(역순): 로그 13으로 D를 15로, 로그 6으로 B를 12로 되돌린다.
T3 undo: 로그 10으로 C를 30으로 되돌린다.
따라서 B·C는 변경 전 값으로 돌아가고, A·D는 T4가 기록한 값이 남는다.

뷰는 물리적으로 저장되지 않는 가상 테이블이므로, 독립 테이블로 물리 저장소에 저장된다는 설명이 옳지 않다.
뷰는 정의(질의문)만 시스템 카탈로그에 저장되고, 사용할 때 기본 테이블에서 데이터를 가져온다.
편의성·재사용성·보안성(필요한 열만 노출)을 높인다는 설명은 옳다.
조회는 자유롭지만 조인·집계 뷰 등은 갱신이 제한된다는 설명도 옳다.
하나의 테이블 위에 여러 뷰를 정의해 사용자별로 활용할 수 있다는 설명도 옳다.

릴레이션은 투플의 집합이므로 투플 사이에 순서가 없다. 순서대로만 나타나야 한다는 설명이 옳지 않다.
집합의 성질상 투플의 무순서성과 중복 투플 불허가 관계 모델의 기본 특성이다.
행을 투플, 열을 애트리뷰트라 부른다는 설명은 옳다.
각 값이 원자값이어야 한다는 설명(제1정규형 조건)도 옳다.
알 수 없거나 지정되지 않은 값에 NULL을 쓴다는 설명도 옳다.

㉠에는 AS, ㉡에는 부서=‘연구’가 들어간다.
뷰는 CREATE VIEW 뷰이름(열 목록) AS SELECT … 형식으로 정의하며, IN은 이 자리에 올 수 없다.
직급=‘대리’ 조건은 이수진과 함께 홍성대도 선택하므로 1행짜리 뷰_사원1과 다르다.
부서=‘연구’ 조건은 이수진 한 명만 선택해 뷰_사원1과 일치한다.

㉠은 450, ㉡은 550이다.
㉠ 시점에 T2의 삽입은 아직 commit되지 않았으므로 T1은 기존 세 행만 읽어 200+150+100=450을 얻는다.
T2가 commit한 뒤에도 팬텀을 허용하지 않으므로 T1에는 새 행(no=4)이 보이지 않는다. T1이 no=3의 price를 200으로 바꾸었으므로 ㉡은 200+150+200=550이다.
㉡이 600이 되려면 새 행의 50까지 합산되어야 하므로 팬텀 불허 조건에 어긋난다.
㉠이 500이 되려면 commit 전 삽입을 읽는 오손 읽기가 필요하므로 repeatable read에서 불가능하다.

질의 결과로 남는 RSID는 1004뿐이다.
이 질의는 S의 과목에서 x가 수강한 과목을 뺀 차집합이 비어 있는지(NOT EXISTS)를 보아, S의 모든 과목(영어·국어)을 가진 RSID를 찾는 관계 나눗셈이다.
1001은 국어만 있어 영어가 남으므로 제외된다.
1002는 영어만 있어 국어가 남으므로 제외된다.
1003은 국어·수학이어서 영어가 남으므로 제외된다.
1004는 국어·영어·수학을 모두 가져 차집합이 공집합이 되므로 선택된다.

집계 함수는 WHERE 절에 쓸 수 없으므로, WHERE COUNT(*) >= 10을 쓴 학년별 질의가 옳지 않다.
그룹 단위 조건은 GROUP BY grade 뒤에 HAVING COUNT(*) >= 10으로 지정해야 한다.
학과별 평균·최고·최저 성적을 GROUP BY deptno로 구한 질의는 옳다.
학과·학년 두 열로 묶어 인원수와 평균을 구한 질의도 옳다.
행 조건 deptno >= 100을 WHERE로 거른 뒤 학과별 평균을 구한 질의도 옳다.

옳은 것은 ㄱ, ㄹ이다.
정규화는 함수 종속과 키를 바탕으로 이상을 줄이는 분석 과정이고(ㄱ), 3NF는 2NF에서 이행적 함수 종속을 제거한 형태다(ㄹ).
ㄴ: 1NF는 모든 도메인이 더 이상 나눌 수 없는 원자값일 때 성립한다.
ㄷ: 2NF는 기본키가 아닌 속성이 기본키에 완전 함수 종속이어야 하며, 부분 함수 종속은 제거 대상이다.
ㅁ: 모든 결정자가 후보키인 것은 BCNF 조건이고, 4NF는 다치 종속을 제거한 형태다.

NoSQL은 스키마가 없거나 유연한(schema-less) 구조이므로, RDBMS처럼 스키마를 필요로 한다는 설명이 옳지 않다.
고정 스키마 없이 키-값·문서·컬럼·그래프 형태로 저장해 구조 변경에 유연하다.
데이터를 여러 노드로 나누는 샤딩을 지원한다는 설명은 옳다.
BigTable·Cassandra를 대표 NoSQL로 든 설명도 옳다.
가용성과 수평 확장성을 중시한다는 설명도 옳다.

E의 폐포는 E 자신뿐이므로 E→D는 유도할 수 없다.
F에는 E만으로 결정되는 종속이 없고, BE→D는 B가 함께 있어야 적용된다.
E→E는 반사 규칙에 의한 자명한 종속이다.
AE→D: A→B로 AE의 폐포에 B가 들어오고, BE→D로 D가 유도된다.
AC→BC: A→B의 양변에 C를 첨가(증가 규칙)하면 얻어진다.

행 수준 트리거는 FOR EACH ROW 절로 표시하므로, FOR EACH STATEMENT를 쓴다는 설명이 옳지 않다.
FOR EACH STATEMENT는 문장 전체에 대해 한 번 실행되는 문장 수준 트리거에 쓴다.
이벤트 발생 시 자동으로 실행되는 작업이라는 설명은 옳다.
무결성 유지 도구라는 설명도 옳다.
이벤트 전후에 실행되는 BEFORE·AFTER 트리거가 있다는 설명도 옳다.

오류 발생 직전에 이미 완료(커밋)된 $T_{4}$는 실행취소 대상이 아니라 redo(재실행) 대상이므로, $T_{4}$가 undo된다는 설명이 옳지 않다.
즉시 갱신·체크포인트 회복에서는 체크포인트 이후 오류 전까지 커밋된 트랜잭션은 redo, 오류 시점에 미완료인 트랜잭션은 undo, 체크포인트 이전에 커밋된 트랜잭션은 무시한다. 그림에서 $T_{3}$와 $T_{5}$는 오류 시점까지 끝나지 않아 undo, $T_{2}$와 $T_{4}$는 오류 전에 끝나 redo된다.
$T_{2}$ redo — 체크포인트 전에 시작했지만 오류 전에 커밋되었으므로, 체크포인트 이후의 변경분을 재실행해야 한다는 설명은 옳다.
$T_{1}$ 무작업 — 체크포인트 이전에 커밋이 끝나 변경이 이미 디스크에 반영되었으므로 옳다.
체크포인트 로그 기록 — 체크포인트 시점에 활성 상태인 트랜잭션은 $T_{2}$와 $T_{5}$뿐이므로 이 둘을 담은 checkpoint 레코드를 기록한다는 설명은 옳다.

STUDENT의 Dept_No 값 3·4가 DEPARTMENT의 Dept_Number에 없으므로 참조 무결성 제약조건을 만족하지 않는다.
외래키 값은 참조 릴레이션의 기본키 값이거나 NULL이어야 한다.
ID와 Dept_Number 값이 각각 중복되지 않으므로 유일성은 만족한다.
기본키에 NULL이 없으므로 엔티티 무결성도 만족한다.
주어진 인스턴스에서 함수 종속을 위반하는 투플 쌍도 없다.

응용 프로그램이나 논리 구조에 영향 없이 물리 구조를 바꿀 수 있는 것은 물리적 데이터 독립성이므로, 이를 논리적 독립성이라 한 설명이 옳지 않다.
논리적 데이터 독립성은 개념 스키마가 바뀌어도 외부 스키마·응용 프로그램이 영향을 받지 않는 성질이다.
내부 스키마가 물리적 저장 구조를 기술한다는 설명은 옳다.
외부 스키마가 사용자 그룹의 관심 부분만 보여 주고 나머지를 숨긴다는 설명도 옳다.
기본 테이블이 확장되어도 기존 뷰 사용자가 영향을 받지 않아 뷰가 논리적 독립성을 일부 제공한다는 설명도 옳다.

DDL로만 이루어진 조합은 DROP, TRUNCATE(ㄴ, ㄷ)이다.
ALTER·DROP·TRUNCATE는 객체 구조를 정의·변경·제거하는 DDL이고, GRANT는 DCL, COMMIT은 트랜잭션 제어어(TCL)다.
ALTER와 COMMIT 조합은 COMMIT이 DDL이 아니어서 제외된다.
TRUNCATE와 GRANT 조합은 GRANT가 권한 부여 명령이어서 제외된다.
GRANT와 COMMIT 조합은 둘 다 DDL이 아니다.

동등한 식은 사원에서 급여·취미 조건을 선택해 부서번호를 추출하고, 건물층=1인 부서의 부서번호·부서명과 조인한 뒤 재정의 예산·부서번호와 조인해 부서명·예산을 투영한 식이다.
선택·투영을 조인 앞으로 내려 보내도 결과가 같다는 관계대수 동치를 이용한 형태다.
최종 투영을 E.부서번호로 한 식은 결과 열이 부서명·예산이 아니며, 사원에 대해 부서명·예산을 투영해 성립하지 않는다.
재정에서 예산만 투영한 식은 조인 속성인 부서번호가 사라져 부서와 연결되지 않는다.
재정에 열 목록을 선택 조건처럼, 사원에 조건식을 투영 목록처럼 쓴 식은 선택과 투영이 뒤바뀌었다.

세미 조인 결과에 (a4, b3, c3)이 빠져 있으므로 이 결과가 옳지 않다.
세미 조인은 S와 B·C 값이 일치하는 R의 투플을 R의 속성만으로 돌려준다. (b3, c3)은 S에 있으므로 a1·a2·a3·a4의 네 투플이 나와야 한다.
자연 조인은 a2가 d2·d3와 두 번, a3·a4가 각각 d4와 결합해 총 5행이 되므로 맞다.
왼쪽 외부 조인은 자연 조인 5행에 짝이 없는 a5를 D=NULL로 더한 결과로 맞다.
오른쪽 외부 조인은 짝이 없는 S의 (b4, c4, d5)를 A=NULL로 더한 결과로 맞다.

여러 트랜잭션이 동시에 수행되어도 결과의 일관성을 유지하는 성질은 병행(concurrency) 투명성이므로, 이를 장애 투명성이라 한 설명이 옳지 않다.
장애 투명성은 사이트·통신 장애가 생겨도 트랜잭션의 원자성이 보장되어 사용자가 장애를 의식하지 않게 하는 성질이다.
릴레이션의 단편화 방식을 사용자가 알 필요가 없다는 설명은 옳다.
중복 데이터와 그 저장 위치를 인지할 필요가 없다는 설명도 옳다.
데이터의 물리적 위치를 알 필요가 없다는 위치 투명성 설명도 옳다.

사원 테이블의 차수는 4, 카디날리티는 3이다.
차수(degree)는 애트리뷰트(열)의 수로 사번·이름·직급·부서 4개이고, 카디날리티(cardinality)는 투플(행)의 수로 3개다.
차수를 3으로 본 조합은 열과 행의 개수를 혼동한 것이다.
카디날리티를 4로 본 조합은 열 개수를 행 개수로 센 것이다.

API 방식은 응용 프로그램이 암·복호화 API를 직접 호출하므로 응용 프로그램 수정이 필요하다. 수정이 필요 없어 편리하다는 설명이 옳지 않다.
응용 프로그램 수정이 거의 없는 쪽은 DB 서버에 모듈을 설치하는 플러그인 방식이다.
암·복호화 모듈을 애플리케이션 서버에 설치한다는 설명은 옳다.
암·복호화를 애플리케이션 서버에서 처리해 플러그인 방식보다 상대적으로 빠르다는 설명도 옳다.
DB 서버에 암·복호화 부하가 거의 걸리지 않는다는 설명도 옳다.

갱신분실은 한 트랜잭션의 변경 결과를 다른 트랜잭션이 덮어써서 앞선 갱신이 사라지는 문제다.
두 트랜잭션이 같은 값을 읽고 각자 갱신해 기록하면 나중에 쓴 값만 남는다.
서로 상대가 끝나기만 기다리며 영원히 완료되지 못하는 것은 교착상태다.
롤백 전에 변경 데이터를 가져간 트랜잭션이 이미 완료되어 롤백할 수 없는 것은 회복 불가능(연쇄 복귀) 문제다.
일관성이 깨진 상태의 데이터를 읽어 연산하는 것은 모순성(비일관성 분석) 문제다.

2단계에서 조정자는 모든 참여 사이트로부터 ready T를 받으면 T를 완료하고, 그렇지 않으면 취소한다.
1단계는 조정자가 prepare T를 보내고 각 사이트가 ready 또는 abort로 응답하는 과정이며, 응답을 모아 완료 여부를 결정하는 것은 2단계의 일이다.
1단계 수행 중 고장이 발생하면 트랜잭션은 완료되지 않고 취소된다.
지역 사이트에서 시작된 트랜잭션의 실행을 조정하는 것은 트랜잭션 관리자가 아니라 트랜잭션 조정자(TC)의 역할이다.
prepare T 응답을 모두 받아 완료 가능 여부를 판단하는 것은 1단계가 아닌 2단계에 해당한다.

은행·보험·주식처럼 중요한 응용에서는 데이터 전체를 주기적으로 백업해 안전한 장소에 보관한다는 설명이 옳다.
재해 시에는 백업본을 복원한 뒤 백업된 로그로 이후의 완료 트랜잭션을 redo해 최근 상태까지 되살린다.
재해 시 백업 사본은 백업 장치에서 디스크로 적재되므로 방향이 반대로 서술되었다.
시스템 로그를 백업해 두면 마지막 DB 백업 이후의 트랜잭션도 잃지 않고 복구할 수 있다.
완료된 트랜잭션의 실행 결과는 undo가 아니라 redo에 사용된다.