ㄴ. 응용프로그램이나 데이터베이스의 논리적 구조에 독립적으로 데이터의 물리적 구조를 변경할 수 있다.
ㄷ. 논리적 데이터 독립성은 개념 스키마가 변경되어도 외부 스키마나 응용프로그램에 영향을 끼치지 않는 것을 의미한다.
ㄹ. 3단계 데이터베이스 구조의 내부 단계에서는 파일에 데이터를 효율적으로 저장하고 관리하기 위하여 여러 개의 내부 스키마를 가지고 있다.
옳은 설명은 ㄴ, ㄷ이다.
물리적 데이터 독립성은 내부 스키마(물리적 구조)를 바꿔도 개념 스키마·응용프로그램이 영향을 받지 않는 성질이고, 논리적 데이터 독립성은 개념 스키마가 바뀌어도 외부 스키마·응용프로그램이 영향을 받지 않는 성질이다.
- ㄱ: 물리적 구조가 바뀔 때 논리적 구조가 자동으로 함께 바뀐다는 설명은 틀렸다 — 독립성은 논리적 구조를 바꾸지 않아도 되게 하는 것이다.
- ㄴ: 논리적 구조와 무관하게 물리적 구조를 바꿀 수 있다는 설명은 물리적 데이터 독립성의 정의로 옳다.
- ㄷ: 개념 스키마 변경이 외부 스키마·응용프로그램에 영향을 주지 않는다는 설명은 논리적 데이터 독립성으로 옳다.
- ㄹ: 내부 스키마는 데이터베이스당 하나이므로 여러 개를 가진다는 설명은 틀렸다(여러 개일 수 있는 것은 외부 스키마이다).
○ 무한 호출에 따라 실행의 종료를 보장할 수 없는 문제가 있다.
○ 무결성 제약조건을 유지하기 위하여 데이터베이스 갱신을 모니터링하고, 데이터베이스 갱신을 전파한다.
설명하는 용어는 트리거(trigger)이다.
트리거는 삽입·삭제·갱신 같은 이벤트가 발생하면 DBMS가 자동으로 실행하는 사용자 정의 프로시저로, 무결성 유지와 갱신 전파에 쓰이며 트리거가 다른 트리거를 연쇄 호출하면 종료가 보장되지 않을 수 있다.
- assertion은 데이터베이스 전체에 걸친 조건을 선언하는 제약으로, 갱신을 전파하는 프로시저가 아니다.
- catalog는 스키마·제약조건 등 메타데이터를 저장하는 시스템 테이블이다.
- check는 속성·튜플 값이 만족해야 할 조건을 선언하는 제약조건으로, 자동 실행 프로시저가 아니다.
기본 키는 AD이다.
어떤 함수 종속의 오른쪽에도 나오지 않는 A와 D는 반드시 키에 포함되어야 한다. AD의 폐포를 구하면 A → B, C, B → E, E → F, D → E 로 모든 속성이 결정된다.
이고, A나 D 하나만으로는 전체를 결정하지 못하므로 AD는 최소성도 만족한다.
- A 단독의 폐포는 {A, B, C, E, F}로 D가 빠져 키가 될 수 없다.
- AB는 D를 결정하지 못하므로 키가 아니다.
- AE도 D를 결정하지 못하므로 키가 아니다.
고객
| 고객ID | 고객이름 | 주민등록번호 | 등급 | 적립금 | 추천고객 |
|---|---|---|---|---|---|
| K123 | 김탁구 | 96××××-××××××× | Gold | 2000 | P492 |
| L243 | 이승룡 | 97××××-××××××× | Vip | 3000 | K123 |
| C524 | 최무선 | 93××××-××××××× | Gold | 2000 | K123 |
| P492 | 박하얀 | 95××××-××××××× | Silver | 1000 | L243 |
| 주문번호 | 주문고객 | 주문제품 | 수량 | 단가 | 주문일자 |
|---|---|---|---|---|---|
| 1 | K123 | 우동 | 10 | 2000 | 2023 - 01 - 01 |
| 2 | C524 | 라면 | 5 | 1000 | 2023 - 01 - 02 |
| 3 | P492 | 만두 | 7 | 3000 | 2023 - 01 - 03 |
옳지 않은 것은 주문고객 값으로 'S254'를 가질 수 있다는 설명이다.
외래 키 값은 참조하는 릴레이션의 기본 키 값 중 하나이거나 NULL이어야 하는데(참조 무결성), 고객 릴레이션에는 고객ID가 S254인 튜플이 없다.
- 고객ID, 주민등록번호는 각각 유일하므로 이를 포함한 (고객ID, 고객이름), (고객이름, 주민등록번호)도 모두 슈퍼 키가 된다.
- 추천고객은 같은 릴레이션의 고객ID를 참조하는 자기 참조 외래 키로 정의할 수 있고, 추천인이 없으면 NULL을 가질 수 있다.
- 고객ID와 주민등록번호는 최소성을 만족하는 후보 키이지만, (고객ID, 고객이름)은 고객ID만으로도 유일하므로 최소성을 만족하지 못해 후보 키가 아니다.
R
| A | B | C |
|---|---|---|
| a1 | b1 | c1 |
| a2 | b2 | c2 |
| a3 | b3 | c3 |
| a4 | b4 | c5 |
| B | C | D |
|---|---|---|
| b1 | c1 | d1 |
| b3 | c2 | d2 |
| b3 | c3 | d3 |
| b5 | c5 | d5 |
| B | C | D |
|---|---|---|
| b3 | c2 | d2 |
| b3 | c3 | d3 |
| B | C |
|---|---|
| b1 | c1 |
| b3 | c3 |
| A | B |
|---|---|
| a3 | b3 |
| A | C |
|---|---|
| a2 | c2 |
옳지 않은 것은 의 결과를 (a2, c2)로 제시한 것이다.
자연조인은 공통 속성 B, C가 모두 같은 튜플끼리 결합하므로 조인 결과는 (a1, b1, c1, d1), (a3, b3, c3, d3) 두 튜플이다. 여기서 B='b3'을 선택하고 A, C를 추출하면 결과는 (a3, c3)이다.
- S에서 B='b3'인 튜플은 (b3, c2, d2), (b3, c3, d3)로 제시된 결과가 맞다.
- 조인 결과의 B, C를 추출하면 (b1, c1), (b3, c3)로 제시된 결과가 맞다.
- R에서 C='c3'인 튜플은 (a3, b3, c3)뿐이므로 A, B 추출 결과 (a3, b3)가 맞다.
최대로 접근하는 블록 수는 6개이다.
블로킹 인수(블록당 레코드 수):
필요한 블록 수:
정렬된 63개 블록을 블록 단위로 이진검색하면 최대 접근 횟수는 이다.
레코드가 블록 경계를 넘지 않으므로 블록당 남는 24바이트는 쓰지 않는다. 블록이 아닌 레코드 단위로 계산하거나 순차 탐색으로 계산하면 더 큰 값이 나온다.
○ 내부노드의 구조는 이며, 는 번째 키, 는 번째 서브트리를 가리키는 포인터이다.
○ 이면 이고, 이면 를 만족한다.
○ 이면 를 만족한다.
○ 노드 분할 시 상위 노드로 올리는 값은 분할대상 키 값들 중 중간 값을 올리는 것으로 가정한다.
루트에 있는 키 값은 F, M이다.
노드당 최대 4개 키이므로 다섯 번째 키가 들어오면 분할하고, 리프 분할 시 중간 값을 상위 노드로 복사해 올리며 중간 값은 오른쪽 리프에 남는다. T, W, M, E 삽입 → [E, M, T, W]. F 삽입 시 [E, F, M, T, W]가 넘쳐 중간 값 M을 올린다: [E, F] | [M, T, W], 루트 [M].
G, K 삽입 → 왼쪽 리프 [E, F, G, K]. C 삽입 시 [C, E, F, G, K]가 넘쳐 중간 값 F를 올린다: [C, E] | [F, G, K] | [M, T, W], 루트 [F, M].
이후 S → [M, S, T, W], D와 B → [B, C, D, E], L → [F, G, K, L]로 어느 리프도 넘치지 않아 루트는 [F, M]으로 유지된다.
ㄴ. DBMS의 필수 기능으로 정의 기능, 조작 기능, 제어 기능, 처리 기능이 있다.
ㄷ. DBMS의 정의 기능은 데이터를 정확하고 안전하게 유지하기 위한 데이터 무결성 유지, 보안 유지, 병행 제어 기능을 포함한다.
ㄹ. DBMS는 데이터의 중복성과 응용프로그램에 대한 종속성 문제 해결에서 파일 시스템 대비 우수한 장점을 가지고 있다.
옳은 설명은 ㄱ, ㄹ이다.
DBMS의 필수 기능은 정의·조작·제어 세 가지이며, 무결성·보안·병행 제어는 제어 기능에 속한다.
- ㄱ: 데이터 규모가 크고 동시 공유를 지원하므로 장애 시 일관된 상태로 회복하는 과정이 복잡하다는 설명은 옳다.
- ㄴ: 필수 기능에 '처리 기능'을 포함한 설명은 틀렸다.
- ㄷ: 무결성·보안·병행 제어를 정의 기능에 넣은 설명은 틀렸다 — 이는 제어 기능이다.
- ㄹ: 파일 시스템의 데이터 중복과 응용프로그램 종속 문제를 해결한다는 설명은 옳다.
order(cname, fname, price, date)
food(name, price, stock)
SELECT name
FROM food AS f
WHERE f.stock < 10 OR f.price > 20000;
관계대수:
SELECT c.name, c.phone
FROM customer AS c, order AS o, food AS f
WHERE o.fname = f.name AND c.name = o.cname
AND f.price > 10000;
관계대수:
SELECT name, SUM(price) AS orderPrice
FROM customer, order
WHERE name = cname
GROUP BY name;
관계대수:
SELECT name, AVG(food.price) AS avgPrice
FROM food, order
GROUP BY name;
관계대수:
옳지 않은 것은 가격이 10000을 넘는 음식을 주문한 고객의 이름·전화번호를 구하는 SQL에 대응시킨 관계대수식이다.
SQL의 WHERE 절에는 조인 조건 외에 f.price > 10000이 있는데, 관계대수식의 선택 조건에는 o.fname = f.name AND c.name = o.cname만 있어 가격 조건이 빠져 있다.
- 재고 10 미만 또는 가격 20000 초과인 음식 이름 질의는 재명명 후 OR 조건 선택과 name 추출로 정확히 대응한다.
- 고객별 주문 금액 합계 질의는 name = cname 조인 후 name으로 그룹화해 SUM(price)를 구하고 재명명하므로 대응한다.
- 조인 조건이 없는 FROM food, order는 카티션 곱이므로, 곱 결과를 name으로 그룹화해 AVG(food.price)를 구하는 식과 대응한다.
CREATE TABLE 보고(
상급자_사번 CHAR(10),
하급자_사번 CHAR(10),
(가)
);

FOREIGN KEY (상급자_사번) REFERENCES 직원(사번),
FOREIGN KEY (하급자_사번) REFERENCES 직원(사번)
FOREIGN KEY (상급자_사번) REFERENCES 직원(사번),
FOREIGN KEY (하급자_사번) REFERENCES 직원(사번)
FOREIGN KEY (상급자_사번, 하급자_사번)
REFERENCES 직원(사번)
FOREIGN KEY (하급자_사번) REFERENCES 직원(사번)
직원 개체의 M:N 순환 관계 보고는 두 사번을 묶은 복합 기본 키와 각 사번별로 따로 선언한 외래 키 2개로 테이블을 만든다.
M:N 관계는 한 상급자가 여러 하급자를, 한 하급자가 여러 상급자를 가질 수 있으므로 어느 한쪽 사번만으로는 행을 식별할 수 없다. 또 상급자_사번과 하급자_사번은 각각 직원(사번)이라는 단일 속성을 참조하므로 외래 키도 하나씩 따로 정의해야 한다.
- 기본 키를 상급자_사번 하나로 두면 한 상급자가 여러 하급자를 둘 때 키가 중복되어 M:N 관계를 표현할 수 없다.
- 두 속성을 묶어 직원(사번)을 참조하는 외래 키는 2개 열을 1개 열에 대응시키는 것이라 참조 대상의 키 구성과 맞지 않는다.
- 기본 키를 하급자_사번 하나로 두고 외래 키도 하급자만 두면 1:N 관계가 되고 상급자 쪽 참조 무결성도 빠진다.
| ID | NAME | SALARY | SUPERID |
|---|---|---|---|
| 1001 | Kim | 8000 | NULL |
| 1002 | Lee | 5000 | 1003 |
| 1003 | Park | 7000 | NULL |
| 1004 | Cho | 3000 | 1001 |
SELECT *
FROM EMP S RIGHT OUTER JOIN EMP E
ON S.ID = E.SUPERID;
결과의 차수는 8, 카디널리티는 4이다.
SELECT *로 S와 E의 속성 4개씩이 모두 나오므로 차수는 4 + 4 = 8이다. 오른쪽 외부 조인은 오른쪽 E의 모든 튜플을 보존한다.
ID가 기본 키라 E의 각 튜플과 일치하는 S 튜플은 최대 하나이다. Lee는 Park과, Cho는 Kim과 결합하고, SUPERID가 NULL인 Kim, Park은 S 쪽 속성을 NULL로 채워 남으므로 4행이다.
- 차수를 4로 본 것은 SELECT *가 양쪽 속성을 모두 출력함을 놓친 것이다.
- 카디널리티를 2로 본 것은 일치하는 행만 남기는 내부 조인 결과이다.
고객
| 고객ID | 고객이름 | 등급 | 적립금 |
|---|---|---|---|
| k123 | 김상중 | Gold | 3000 |
| l018 | 이영우 | Vip | 4000 |
| c389 | 최영 | Gold | 3000 |
| p273 | 박구연 | Silver | 2000 |
| h328 | 홍연수 | Vip | 5000 |
| j451 | 정영상 | Silver | 3000 |
| y524 | 윤성진 | Gold | 2000 |
FROM 고객
WHERE 적립금 = (SELECT MAX(적립금) FROM 고객);
FROM 고객
WHERE 적립금 >= ALL (SELECT 적립금 FROM 고객);
FROM 고객
WHERE 적립금 > ANY (SELECT 적립금 FROM 고객
WHERE 등급 = ‘Vip’);
FROM 고객
WHERE 적립금 IN (SELECT 적립금 FROM 고객
WHERE 등급 = ‘Vip’);
결과가 다른 것은 IN 부속질의를 쓴 구문이다.
Vip 등급의 적립금은 4000, 5000이므로 IN 조건은 적립금이 4000 또는 5000인 이영우, 홍연수를 반환한다.
- MAX(적립금)과 같은지 비교: 최댓값 5000인 홍연수만 반환한다.
- >= ALL: 모든 적립금 이상인 값은 5000뿐이므로 홍연수만 반환한다.
- Vip 적립금에 대한 > ANY: 4000, 5000 중 하나라도 초과하면 되므로 4000 초과인 홍연수만 반환한다.
옳지 않은 것은 비절차적 데이터 조작어가 처리 절차까지 명세한다는 설명이다.
비절차적 DML은 어떤(what) 데이터를 원하는지만 명세하고 처리 방법은 DBMS에 맡긴다. 원하는 데이터와 처리 방법(how)을 모두 명세하는 것은 절차적 DML이다.
- 데이터 언어가 사용자와 DBMS 간의 통신 수단이라는 설명은 옳다.
- 데이터 제어어가 무결성·일관성을 유지하며 공유하도록 규칙·기법을 정의한다는 설명은 옳다.
- 데이터 정의어가 스키마를 정의·삭제·수정한다는 설명은 옳다.
○ ( 나 )는 분산 데이터베이스에 저장할 모든 데이터 구조와 제약조건을 정의하는 것으로서, 관계 데이터 모델의 관점에서 보면 데이터베이스 안에 존재하는 모든 릴레이션 스키마의 집합이다.
(가)는 할당 스키마, (나)는 전역 개념 스키마이다.
분산 데이터베이스 스키마는 전역 개념 스키마 → 단편화 스키마 → 할당 스키마 → 지역 스키마로 구성되며, 조각을 어느 지역(사이트)에 저장할지 정하는 것이 할당 스키마이다.
- 단편화 스키마는 전역 릴레이션을 어떻게 조각(fragment)으로 나눌지를 정의하므로 (가)에 해당하지 않는다.
- 지역 스키마는 각 사이트의 지역 DBMS가 관리하는 스키마로, 모든 릴레이션 스키마의 집합인 (나)가 아니다.
옳지 않은 것은 Ingres를 NoSQL 시스템으로 든 설명이다.
Ingres는 SQL을 지원하는 대표적인 관계형 DBMS이며, NoSQL의 예로는 MongoDB, Cassandra, Redis, HBase 등이 있다.
- 가용성을 위해 궁극적 일치성을 제공하는 경우가 많다는 설명은 옳다.
- 미리 정의된 스키마 없이 데이터를 저장할 수 있다는 설명은 옳다.
- 여러 컴퓨터에 데이터를 분산 저장·처리한다는 설명은 옳다.
| 시간 | 로그 | 데이터베이스 |
|---|---|---|
| <T1, start> | ||
| <T1, A, 100, 90> | ||
| <T1, B, 50, 60> | A = 90 | |
| (가)→ | B = 60 | |
| <T1, commit> | ||
| <T2, start> | ||
| <T2, C, 100, 90> | ||
| <T2, D, 50, 60> | C = 90 | |
| (나)→ | D = 60 | |
| <T2, commit> |
| 시간 | 로그 | 데이터베이스 |
|---|---|---|
| <T3, start> | ||
| <T3, E, 90> | ||
| (다)→ | <T3, F, 60> | |
| <T3, commit> | ||
| E = 90, F = 60 | ||
| <T4, start> | ||
| <T4, G, 90> | ||
| (라)→ | <T4, H, 60> | |
| <T4, commit> | ||
| G = 90, H = 60 |
바른 연결은 (가) , (나) , (다) 회복작업 없음, (라) 이다.
첫 번째 로그는 이전 값과 새 값을 모두 기록하므로 즉시 갱신 기법이다. 커밋 전에도 DB에 반영되므로 커밋된 트랜잭션은 Redo, 커밋되지 않은 트랜잭션은 Undo한다.
- (가): 이 커밋 전이고 A = 90이 이미 기록되었으므로 Undo가 필요하다.
- (나): 은 커밋되었으므로 Redo, 는 커밋 전에 C가 기록되었으므로 Undo한다.
두 번째 로그는 새 값만 기록하므로 지연 갱신 기법이다. 커밋 후에야 DB에 반영되므로 Undo는 필요 없고 커밋된 트랜잭션만 Redo한다.
- (다): 은 커밋 전이라 DB에 반영된 것이 없으므로 회복작업이 없다.
- (라): 커밋된 은 Redo하고, 커밋 전인 는 DB에 반영된 것이 없으므로 로그만 무시한다.
옳지 않은 것은 참조되는 릴레이션에 튜플을 삽입할 때 참조무결성 위반이 발생한다고 본 설명이다.
피참조 릴레이션에 새 튜플을 삽입해도 기존 외래 키 값은 깨지지 않는다. 삽입 시 위반은 참조하는 릴레이션에 존재하지 않는 키 값을 외래 키로 넣을 때 발생한다.
- 임의의 두 튜플에서 SK 값이 서로 다르면 SK가 슈퍼 키라는 설명은 유일성 정의로 옳다.
- 외래 키는 참조되는 기본 키와 같은 도메인이고 그 값 중 하나이거나 NULL이어야 한다는 설명은 옳다.
- 데이터베이스가 개체무결성과 참조무결성을 만족해야 한다는 설명은 옳다.
옳지 않은 것은 ANY가 단일 행 부속질의에만 적용된다는 설명이다.
ANY·ALL·IN은 부속질의가 여러 행을 반환할 때 쓰는 다중 행 비교 연산자이다. 단일 행 반환에만 쓰는 것은 =, <, > 같은 단일 행 비교 연산자이다.
- 부속질의가 SQL문 안에 중첩된 질의라는 설명은 옳다.
- 스칼라 부속질의가 단일 값을 반환한다는 설명은 옳다.
- 인라인 뷰가 FROM 절의 부속질의라는 설명은 옳다.
의미가 다른 것은 을 곱하는 식이다.
이 식은 조인 전에 속성 C를 제거하므로 결과 릴레이션에 C가 없다. 나머지 식은 모두 의 전체 속성을 유지하는 동등 변환이다.
- 조인 결과에 B=5를 선택하는 식이 기준 질의이다.
- B=5 선택을 먼저 수행한 뒤 곱과 A=D 선택으로 조인하는 식은 선택 연산을 아래로 내린 동등 변환이다.
- 와 을 먼저 조인한 뒤 과 조인하고 B=5를 선택하는 식은 조인의 교환·결합 법칙에 의한 동등 변환이다.
○ T2에서 1번 상품의 가격을 10만 원에서 15만 원으로 변경하다가 커밋을 수행하지 않고 롤백(rollback)하는 과정에서 T1에서 1번 상품의 가격을 조회하였으나 허용되지 않았다.
○ T1에서 등록된 상품을 조회하였는데 0건이 조회되었고, T2에서 1번 상품을 등록하고 커밋을 수행하였다. T1에서 등록된 상품을 다시 조회하였더니 1개 상품이 나타났다.
이 현상이 나타나는 격리 수준은 Read Committed이다.
커밋된 변경 때문에 같은 데이터를 다시 읽을 때 값이 달라지는 반복 불가능 읽기와 새 튜플이 나타나는 팬텀 읽기는 발생하지만, 커밋되지 않은 값 읽기(dirty read)는 허용되지 않았다.
- Serializable은 반복 불가능 읽기와 팬텀 읽기를 모두 막는다.
- Repeatable Read는 같은 데이터를 다시 읽을 때 값이 바뀌는 현상을 막는다.
- Read Uncommitted는 롤백 중인 미커밋 값을 읽는 것도 허용한다.
옳지 않은 것은 단일 루프 조인에 물리적 정렬이 필요하다는 설명이다.
단일 루프 조인은 한 릴레이션의 조인 속성에 인덱스(또는 해시 키)가 있을 때, 다른 릴레이션의 각 레코드로 그 접근 구조를 탐색해 일치 레코드를 찾는 방법이다. 필요한 것은 정렬이 아니라 접근 구조이다.
- 중첩 루프 조인은 모든 레코드 쌍을 비교하므로 별도의 인덱스나 정렬이 필요 없다.
- 정렬-합병 조인은 두 릴레이션이 조인 속성으로 정렬되어 있을 때 한 번씩만 훑으면 되어 가장 효율적이다.
- 해시 조인은 두 릴레이션을 같은 해시 함수로 조인 속성에 따라 분할해 같은 버킷끼리 비교한다.
바르게 짝 지어진 것은 ARIES 기법의 분석 → REDO → UNDO 단계이다.
ARIES는 분석 단계에서 갱신된 페이지와 활성 트랜잭션을 파악하고, REDO로 장애 시점 상태를 재현한 뒤, UNDO로 미완료 트랜잭션을 취소한다.
- 지연 갱신은 커밋 전 DB에 반영하지 않으므로 NO-UNDO/REDO이다.
- 즉시 갱신은 커밋 전에도 반영하므로 UNDO/REDO(또는 UNDO/NO-REDO)이다.
- 그림자 페이지 기법은 그림자 페이지 테이블로 이전 상태를 보존하므로 NO-UNDO/NO-REDO이다.
옳지 않은 것은 소유 객체의 권한 부여를 반드시 데이터 관리자가 해야 한다는 설명이다.
객체를 생성한 소유자는 그 객체에 대한 모든 권한을 가지며 GRANT로 다른 사용자에게 직접 권한을 부여할 수 있다.
- 권한 관리로 권한 없는 사용자의 접근을 막는다는 설명은 옳다.
- 허가된 사용자의 실수에 의한 무결성 위반을 제약조건으로 통제한다는 설명은 옳다.
- 보안 단위를 데이터베이스 전체부터 특정 행·열까지 정할 수 있다는 설명은 옳다.
옳지 않은 것은 데이터 웨어하우스가 최신 값만 유지한다는 설명이다.
데이터 웨어하우스는 시간에 따른 변화를 이력으로 보관하는 시변성(time variant)을 가진다. 현재 시점의 최신 값만 유지하는 것은 운영 데이터베이스의 특성이다.
- 의사결정 주제별로 데이터를 관리하는 주제 지향성은 옳다.
- 여러 원천 데이터를 일관된 형식으로 정의하는 통합성은 옳다.
- 적재 후 갱신하지 않고 읽기 위주로 유지하는 비휘발성은 옳다.
ㄴ. 교착상태(deadlock) 방지
ㄷ. 복구가능한(recoverable) 스케줄 보장
바르게 짝 지어진 것은 엄격한(strict) 2PL과 ㄱ, ㄷ이다.
2PL 계열은 모두 직렬가능성을 보장하지만 교착상태는 막지 못한다. 엄격한 2PL은 배타 로크를 커밋·철회 시까지 유지해 미커밋 값을 읽지 못하게 하므로 복구가능 스케줄도 보장한다.
- 기본 2PL은 ㄱ은 보장하지만 커밋 전 로크 해제로 미커밋 값을 읽을 수 있어 ㄷ은 보장하지 못한다.
- 엄중한 2PL과 ㄱ, ㄴ의 짝은 틀렸다 — 로크 대기 순환이 생길 수 있어 교착상태 방지는 보장하지 않는다.
- 엄중한 2PL과 ㄱ, ㄴ, ㄷ의 짝도 ㄴ을 포함하므로 틀렸다(ㄱ, ㄷ만 보장).