데이터베이스 구축 · 오답노트

보기별 해설

1. 데이터 보안은 DCL의 대표 기능이다. GRANT로 사용자에게 검색·삽입·갱신 등의 권한을 부여하고 REVOKE로 회수해, 인가되지 않은 사용자의 접근을 막는다.

2. 논리적물리적 데이터 구조 정의(추출 과정에서 쉼표가 밀린 '논리적·물리적'을 뜻한다)는 DCL이 아니라 데이터 정의 언어(DDL)의 기능이다. CREATE로 스키마·테이블·인덱스를 생성하고 ALTER로 구조를 변경하며 DROP으로 삭제하는 것이 여기에 해당한다.

3. 무결성 유지는 DCL의 기능에 포함된다. 데이터베이스에 저장된 데이터가 정확성과 일관성을 유지하도록 제약 조건과 규정을 관리하는 역할이다.

4. 병행수행 제어도 DCL의 기능이다. 여러 사용자가 동시에 데이터베이스에 접근할 때 로킹 등을 통해 상호 간섭 없이 정확하게 처리되도록 통제한다.

정리

SQL 3분류 — DDL(CREATE/ALTER/DROP: 구조 정의), DML(SELECT/INSERT/UPDATE/DELETE: 데이터 조작), DCL(GRANT/REVOKE/COMMIT/ROLLBACK: 보안·무결성·회복·병행제어).

#데이터베이스#보안

병행제어의 로킹(Locking) 단위에 대한 설명으로 옳지 않은 것은?

1데이터베이스파일레코드, , 등은 로킹 단위가 될 수 있다.

2로킹 단위가 작아지면 로킹 오버헤드가 감소한다.

3로킹 단위가 작아지면 데이터베이스 공유도가 증가한다.

4한꺼번에 로킹할 수 있는 객체의 크기를 로킹 단위라고 한다.

정답 2번 · 로킹 단위가 작아지면 로킹 오버헤드가 감소한다.

핵심 해설

로킹 단위(Locking Granularity)란 병행제어에서 한꺼번에 잠글 수 있는 데이터 객체의 크기를 말하며, 데이터베이스 전체·파일·릴레이션·튜플·필드 등이 그 대상이 될 수 있다. 로킹 단위가 크면 잠금의 개수가 적어져 관리할 락 정보가 줄고 로킹 오버헤드는 감소하지만, 한 트랜잭션이 넓은 범위를 독점하므로 병행성(공유도)은 떨어진다. 반대로 로킹 단위가 작아지면 여러 트랜잭션이 서로 다른 부분을 동시에 다룰 수 있어 공유도는 증가하지만, 설정·해제해야 할 락이 많아져 로킹 오버헤드는 오히려 증가한다. 따라서 '단위가 작아지면 오버헤드가 감소한다'는 서술이 사실과 반대이다.

보기별 해설

1. 데이터베이스파일레코드 항목은 PDF 추출로 쉼표 위치가 깨진 것으로, 데이터베이스·파일·레코드 등이 모두 로킹 단위가 될 수 있다는 옳은 설명이다. 로킹 단위는 데이터베이스 전체부터 파일, 릴레이션, 튜플, 필드까지 계층적으로 선택할 수 있다.

2. 로킹 단위가 작아지면 로킹 오버헤드는 감소하는 것이 아니라 증가한다. 잠글 객체가 잘게 나뉘는 만큼 락의 개수와 락 관리를 위한 제어 정보가 많아져 시스템 부담이 커지기 때문이다.

3. 로킹 단위가 작아지면 데이터베이스 공유도가 증가한다는 설명은 옳다. 잠기는 범위가 좁아 다른 트랜잭션이 같은 릴레이션의 다른 튜플에 동시에 접근할 수 있어 병행성이 높아진다.

4. 한꺼번에 로킹할 수 있는 객체의 크기를 로킹 단위라 한다는 것은 로킹 단위의 정의 그대로이다. 어느 수준의 객체를 잠글지 정하는 기준을 가리킨다.

정리

로킹 단위 — 크면: 락 수 감소 → 오버헤드 감소, 공유도(병행성) 감소 / 작으면: 락 수 증가 → 오버헤드 증가, 공유도 증가. 오버헤드와 공유도는 항상 반대 방향으로 움직인다.

#데이터베이스

이행적 함수 종속 관계를 의미하는 것은?

1A → B이고 B → C일 때, A → C를 만족하는 관계

2A → B이고 B → C일 때, C → A를 만족하는 관계

3A → B이고 B → C일 때, B → A를 만족하는 관계

4A → B이고 B → C일 때, C → B를 만족하는 관계

정답 1번 · A → B이고 B → C일 때, A → C를 만족하는 관계

핵심 해설

이행적 함수 종속(Transitive Functional Dependency)은 속성 A가 B를 결정하고(A → B), B가 다시 C를 결정할 때(B → C), 그 결과로 A가 C를 결정하게 되는(A → C) 종속 관계를 말한다. 중간 매개 속성 B를 거쳐 종속이 '전이(transitive)'된다는 점이 핵심이며, 화살표의 방향이 A → B → C로 한쪽으로 이어져야 한다. 이런 종속이 남아 있으면 갱신 이상이 생기므로 제3정규형(3NF)에서 이를 제거한다. 따라서 A → B, B → C일 때 A → C가 성립하는 관계가 이행적 함수 종속이다.

보기별 해설

1. A → B이고 B → C일 때 A → C를 만족하는 관계가 이행적 함수 종속의 정의이다. 중간 속성 B를 매개로 종속이 전이되어 A가 C를 간접 결정하며, 3NF는 이 A → C를 분해해 제거한다.

2. A → B이고 B → C일 때 C → A는 종속의 방향을 거꾸로 되돌리는 역방향 관계이다. 함수 종속은 방향성을 가지므로 A → C가 성립한다고 해서 C → A가 성립하지는 않으며, 이행적 종속과 무관하다.

3. A → B이고 B → C일 때 B → A는 B와 A가 서로를 결정하는 상호 종속(1:1 대응)을 뜻할 뿐이다. 전이의 종착점인 C가 결론에 등장하지 않으므로 이행적 종속의 정의가 될 수 없다.

4. A → B이고 B → C일 때 C → B는 이미 전제로 주어진 B → C의 역방향에 지나지 않는다. 시작 속성 A가 결론에 없어 A에서 C로의 전이를 설명하지 못한다.

정리

이행적 함수 종속 = A → B, B → C ⇒ A → C. 정규화 제거 대상 — 2NF: 부분 함수 종속 / 3NF: 이행적 함수 종속 / BCNF: 후보키 아닌 결정자 / 4NF: 다치 종속.

#데이터베이스

SQL의 분류 중 DDL에 해당하지 않는 것은?

1UPDATE

2ALTER

3DROP

4CREATE

정답 1번 · UPDATE

핵심 해설

데이터 정의 언어(DDL)는 데이터베이스의 구조, 즉 스키마·테이블·뷰·인덱스 같은 객체를 정의하고 변경하고 삭제하는 명령어로 CREATE, ALTER, DROP 세 가지가 전부이다. 반면 이미 정의된 구조 안에 들어 있는 데이터 값을 검색·삽입·수정·삭제하는 명령어는 데이터 조작 언어(DML)로 SELECT, INSERT, UPDATE, DELETE가 여기에 속한다. UPDATE는 테이블의 행 값을 바꾸는 명령이므로 구조가 아니라 데이터를 다루는 DML이다. 따라서 DDL에 해당하지 않는 것은 UPDATE이다.

보기별 해설

1. UPDATE는 DDL이 아니라 데이터 조작 언어(DML)이다. UPDATE 테이블 SET 열 = 값 WHERE 조건 형태로 기존 튜플의 속성 값을 변경하며, 테이블 구조 자체는 건드리지 않는다.

2. ALTER는 DDL이다. 이미 만들어진 테이블에 열을 추가(ADD)하거나 자료형을 변경(MODIFY), 열을 삭제(DROP)하는 등 스키마 구조를 수정한다.

3. DROP은 DDL이다. 테이블·뷰·인덱스 같은 스키마 객체 자체를 삭제하며, CASCADE와 RESTRICT 옵션으로 참조 객체까지 함께 삭제할지 여부를 지정한다.

4. CREATE는 DDL이다. CREATE TABLE, CREATE VIEW, CREATE INDEX처럼 새로운 스키마 객체를 생성하고 속성과 제약 조건을 함께 정의한다.

정리

DDL = CREATE·ALTER·DROP(구조), DML = SELECT·INSERT·UPDATE·DELETE(데이터), DCL = GRANT·REVOKE·COMMIT·ROLLBACK(제어). UPDATE는 구조가 아니라 값을 바꾸므로 DML.

#데이터베이스#SQL

데이터베이스 로그(log)를 필요로 하는 회복 기법은?

1즉각 갱신 기법

2대수적 코딩 방법

3타임 스탬프 기법

4폴딩 기법

정답 1번 · 즉각 갱신 기법

핵심 해설

로그(Log)는 트랜잭션이 수행한 변경 내역을 발생 순서대로 기록해 둔 파일로, 장애 발생 시 REDO와 UNDO를 수행할 근거가 된다. 로그를 이용하는 대표적 회복 기법에는 즉각 갱신 기법(Immediate Update)과 지연 갱신 기법(Deferred Update)이 있으며, 이 밖에 검사점 기법과 그림자 페이징 기법이 있다. 즉각 갱신 기법은 트랜잭션이 완료되기 전이라도 변경 내용을 즉시 데이터베이스에 반영하되, 반영 전에 반드시 로그를 먼저 기록해 두어 장애 시 UNDO로 취소하고 완료된 트랜잭션은 REDO로 재수행한다. 따라서 로그를 필수적으로 요구하는 회복 기법은 즉각 갱신 기법이다.

보기별 해설

1. 즉각 갱신 기법은 트랜잭션 완료 전에도 변경을 데이터베이스에 즉시 반영하는 회복 기법이다. 반영에 앞서 로그를 먼저 남기므로(Write Ahead Log), 장애 시 미완료 트랜잭션은 UNDO, 완료 트랜잭션은 REDO로 회복하며 로그가 반드시 필요하다.

2. 대수적 코딩 방법은 데이터 전송 중 발생한 오류를 검출·정정하기 위한 부호화 기법으로 정보 이론 영역에 속한다. 데이터베이스 트랜잭션 회복과는 무관하다.

3. 타임 스탬프 기법은 회복 기법이 아니라 병행제어 기법이다. 트랜잭션마다 시간표(타임 스탬프)를 부여해 그 순서대로 직렬 가능하게 처리하며 로킹 없이 교착상태를 방지한다.

4. 폴딩 기법은 해싱에서 키 값을 여러 부분으로 나눈 뒤 더하거나 XOR하여 홈 주소를 구하는 해시 함수 방식이다. 파일 구조 영역의 개념으로 데이터베이스 회복과 관련이 없다.

정리

회복 기법 — 로그 기반: 즉각 갱신(수시 반영, UNDO+REDO), 지연 갱신(완료 후 반영, REDO만) / 로그 없이: 그림자 페이징. 타임 스탬프는 회복이 아니라 병행제어.

#데이터베이스

Commit과 Rollback 명령어에 의해 보장 받는 트랜잭션의 특성은?

1병행성

2보안성

3원자성

4로그 3

정답 3번 · 원자성

핵심 해설

트랜잭션은 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 영속성(Durability)의 ACID 특성을 만족해야 한다. 이 중 원자성은 트랜잭션의 연산이 데이터베이스에 모두 반영되거나 전혀 반영되지 않아야 한다는 All or Nothing 원칙이다. COMMIT은 트랜잭션의 모든 연산을 성공적으로 끝내 그 결과를 영구 반영하는 명령이고, ROLLBACK은 오류 발생 시 지금까지의 변경을 모두 취소해 트랜잭션 시작 이전 상태로 되돌리는 명령이다. 두 명령 덕분에 '전부 반영' 또는 '전부 취소' 둘 중 하나만 남고 중간 상태가 남지 않으므로, 이들이 직접 보장하는 특성은 원자성이다.

보기별 해설

1. 병행성(Concurrency)은 여러 트랜잭션이 동시에 수행되는 성질로 로킹, 타임 스탬프, 다중 버전 기법 같은 병행제어가 관리한다. ACID 특성 이름이 아니며 COMMIT·ROLLBACK이 보장하는 대상도 아니다.

2. 보안성(Security)은 인가되지 않은 사용자로부터 데이터를 보호하는 성질로 GRANT와 REVOKE 같은 권한 제어 명령이 담당한다. 트랜잭션의 완료·취소 여부와는 별개의 영역이다.

3. 원자성(Atomicity)은 트랜잭션의 연산이 모두 반영되거나 하나도 반영되지 않아야 한다는 특성이다. COMMIT이 전부 반영을, ROLLBACK이 전부 취소를 수행해 부분 반영 상태를 남기지 않으므로 두 명령이 곧 원자성의 구현 수단이다.

4. 로그(Log)는 트랜잭션의 변경 내역을 기록한 파일로 회복을 위한 수단이지 트랜잭션의 특성이 아니다. ROLLBACK을 실제로 수행할 때 로그를 참조하지만, 문제가 묻는 '트랜잭션의 특성'에는 해당하지 않는다.

정리

트랜잭션 ACID — 원자성(All or Nothing, COMMIT/ROLLBACK), 일관성(수행 전후 일관 상태), 격리성(수행 중 간섭 차단), 영속성(완료 결과 영구 보존).

#데이터베이스#트랜잭션#보안

한 릴레이션 스키마가 4개 속성, 2개 후보키 그리고 그 스키마의 대응 릴레이션 인스턴스가 7개 튜플을 갖는다면 그 릴레이션의 차수(Degree)는?

정답 3번 · 4

핵심 해설

릴레이션에서 차수(Degree)는 속성(Attribute), 즉 열의 개수를 뜻하고, 카디널리티(Cardinality)는 튜플(Tuple), 즉 행의 개수를 뜻한다. 문제에서 릴레이션 스키마가 4개 속성을 가진다고 했으므로 차수는 4이다. 튜플이 7개라는 정보는 카디널리티가 7이라는 뜻이고, 후보키가 2개라는 정보는 유일성과 최소성을 만족하는 속성 집합이 두 벌 존재한다는 뜻일 뿐 차수와는 무관한 함정이다. 따라서 차수는 4이다.

보기별 해설

1. 1은 릴레이션의 개수나 기본키의 개수를 떠올렸을 때 나오는 값이다. 문제는 속성 수를 묻고 있으므로 해당하지 않는다.

2. 2는 후보키의 개수이다. 후보키 수는 유일 식별 가능한 속성 집합이 몇 벌 있는지를 나타낼 뿐 차수와는 관계가 없다.

3. 4는 속성의 개수이고 차수(Degree)는 속성 수로 정의되므로 이 값이 차수이다. 스키마가 4개 속성을 가진다고 명시했으므로 그대로 차수가 된다.

4. 7은 튜플의 개수, 즉 카디널리티(Cardinality)이다. 행의 수이므로 열의 수를 묻는 차수와 혼동해서는 안 된다.

정리

차수(Degree) = 속성(열)의 수, 카디널리티(Cardinality) = 튜플(행)의 수. 후보키 개수는 둘 중 어느 것도 아니다.

#데이터베이스

사용자 X1에게 department 테이블에 대한 검색 연산을 회수하는 명령은?

1delete select on department to X1;

2remove select on department from X1;

3revoke select on department from X1;

4grant select on department from X1;

정답 3번 · revoke select on department from X1;

핵심 해설

SQL에서 권한을 다루는 DCL 명령은 부여하는 GRANT와 회수하는 REVOKE 두 가지이다. GRANT는 'GRANT 권한 ON 테이블 TO 사용자' 형태로 쓰고, REVOKE는 'REVOKE 권한 ON 테이블 FROM 사용자' 형태로 쓴다. 즉 부여할 때는 대상 사용자에게 준다는 의미로 TO, 회수할 때는 대상 사용자로부터 뺏는다는 의미로 FROM을 쓴다는 점이 구분 기준이다. 사용자 X1에게서 department 테이블의 검색(SELECT) 권한을 회수하려면 REVOKE SELECT ON department FROM X1; 이 된다.

보기별 해설

1. delete select on department to X1;은 존재하지 않는 구문이다. DELETE는 테이블의 행을 지우는 DML 명령이지 권한 회수 명령이 아니며, 회수에는 TO도 쓰지 않는다.

2. remove select on department from X1;은 FROM 방향은 맞지만 REMOVE라는 권한 회수 명령어가 SQL에 없다. 권한 회수 키워드는 REVOKE 하나뿐이다.

3. revoke select on department from X1;은 REVOKE 권한 ON 테이블 FROM 사용자 형식을 정확히 따른다. X1이 가지고 있던 department에 대한 SELECT(검색) 권한을 회수한다.

4. grant select on department from X1;은 GRANT가 권한을 부여하는 명령이므로 회수라는 요구와 반대이고, 게다가 GRANT는 FROM이 아니라 TO를 써야 해 문법도 틀렸다.

정리

권한 제어 — GRANT 권한 ON 테이블 TO 사용자 [WITH GRANT OPTION] / REVOKE 권한 ON 테이블 FROM 사용자 [CASCADE]. 부여는 TO, 회수는 FROM.

#데이터베이스

개체관계- 모델의 E-R 다이어그램에서 사용되는 기호와 그 의미의 연결이 틀린 것은?

1마름모 - 관계 타입

2선 – 개체 타입과 속성을 연결

3사각형 - 개체 타입

4삼각형 - 속성

정답 4번 · 삼각형 - 속성

핵심 해설

개체-관계(E-R) 다이어그램은 현실 세계를 개체, 속성, 관계로 표현하는 개념적 설계 도구로 각 요소마다 정해진 기호가 있다. 사각형은 개체(Entity) 타입, 마름모는 관계(Relationship) 타입, 타원은 속성(Attribute), 이중 타원은 다중값 속성, 밑줄 친 타원은 기본키 속성을 나타내며, 선은 개체·속성·관계를 서로 연결하고 그 위에 1:1, 1:N 같은 대응수를 표기한다. 삼각형은 표준 E-R 표기법에서 사용하는 기호가 아니며, 속성을 나타내는 기호는 타원이다. 따라서 '삼각형 - 속성'이 잘못된 연결이다.

보기별 해설

1. 마름모 - 관계 타입은 옳은 연결이다. 개체와 개체 사이의 연관성을 나타내며 마름모 안에 '수강', '소속' 같은 관계 이름을 적는다.

2. 선 - 개체 타입과 속성을 연결은 옳은 연결이다. 선은 개체와 속성, 개체와 관계를 이어 주며 관계선 위에는 1:1, 1:N, N:M 같은 대응수를 표시한다.

3. 사각형 - 개체 타입은 옳은 연결이다. 학생, 과목처럼 독립적으로 존재하며 데이터로 관리할 대상을 사각형 안에 이름을 써서 표현한다.

4. 삼각형은 E-R 다이어그램의 표준 기호가 아니며, 속성을 나타내는 기호는 타원이다. 기본키 속성은 타원 안 이름에 밑줄을, 다중값 속성은 이중 타원을 사용한다.

정리

E-R 기호 — 사각형: 개체, 마름모: 관계, 타원: 속성, 이중 타원: 다중값 속성, 밑줄: 기본키, 선: 요소 연결 및 대응수 표기. 삼각형은 쓰지 않는다.

#데이터베이스

Q10

3NF에서 BCNF가 되기 위한 조건은?

1이행적 함수 종속 제거

2부분적 함수 종속 제거

3다치 종속 제거

4결정자이면서 후보키가 아닌 것 제거

정답 4번 · 결정자이면서 후보키가 아닌 것 제거

핵심 해설

보이스코드 정규형(BCNF)은 제3정규형을 만족하면서 릴레이션의 모든 결정자가 후보키인 상태로, 강한 제3정규형이라고도 부른다. 결정자(Determinant)는 함수 종속 X → Y에서 화살표 왼쪽의 속성 X를 말하는데, 3NF까지만 만족한 릴레이션에는 후보키가 아니면서도 다른 속성을 결정하는 결정자가 남아 있을 수 있고 이 때문에 삽입·삭제·갱신 이상이 계속 발생한다. BCNF는 바로 그런 '후보키가 아닌 결정자'를 분해해 제거하는 단계이다. 따라서 3NF에서 BCNF로 가기 위한 조건은 결정자이면서 후보키가 아닌 것의 제거이다.

보기별 해설

1. 이행적 함수 종속 제거는 제2정규형에서 제3정규형으로 갈 때의 조건이다. A → B, B → C로 인해 생긴 A → C 형태의 간접 종속을 분해하는 단계이므로 BCNF의 조건이 아니다.

2. 부분적 함수 종속 제거는 제1정규형에서 제2정규형으로 갈 때의 조건이다. 복합키의 일부 속성만으로 결정되는 비주요 속성을 분리해 모든 속성이 기본키에 완전 함수 종속이 되게 만든다.

3. 다치 종속 제거는 BCNF에서 제4정규형으로 갈 때의 조건이다. 하나의 속성이 다른 속성의 값 집합을 결정하는 A →→ B 형태의 종속을 분해하는 단계이다.

4. 결정자이면서 후보키가 아닌 것의 제거가 BCNF의 조건이다. 릴레이션의 모든 결정자가 후보키가 되도록 분해하면 3NF에서도 남아 있던 이상 현상이 사라진다.

정리

정규화 단계별 제거 대상 — 1NF: 원자값 아닌 속성 / 2NF: 부분 함수 종속 / 3NF: 이행적 함수 종속 / BCNF: 후보키 아닌 결정자 / 4NF: 다치 종속 / 5NF: 조인 종속.

#데이터베이스

Q11

뷰(VIEW)에 대한 설명으로 옳지 않은 것은?

1DBA는 보안 측면에서 뷰를 활용할 수 있다.

2뷰 위에 또 다른 뷰를 정의할 수 있다.

3뷰에 대한 삽입갱신삭제, , 연산 시 제약사항이 따르지 않는다.

4독립적인 인덱스를 가질 수 없다.

정답 3번 · 뷰에 대한 삽입갱신삭제, , 연산 시 제약사항이 따르지 않는다.

핵심 해설

뷰(View)는 하나 이상의 기본 테이블로부터 유도된 가상 테이블로, 실제 데이터를 저장하지 않고 정의만 데이터 사전에 보관한다. 필요한 열과 행만 보여 줄 수 있어 보안 수단으로 쓰이고, 이미 정의된 뷰를 기반으로 또 다른 뷰를 정의할 수도 있으며, 물리적 데이터가 없으므로 독립적인 인덱스를 가질 수 없다. 다만 뷰는 실체가 없는 가상 테이블이기 때문에 삽입·갱신·삭제 연산에 제약이 따르는데, 집계 함수·GROUP BY·DISTINCT가 포함되거나 여러 테이블을 조인한 뷰는 갱신할 수 없다. 따라서 '제약사항이 따르지 않는다'는 설명이 틀렸다.

보기별 해설

1. DBA가 보안 측면에서 뷰를 활용할 수 있다는 설명은 옳다. 기본 테이블 중 공개해도 되는 열과 행만 뷰로 정의해 권한을 주면, 사용자는 나머지 데이터에 접근할 수 없다.

2. 뷰 위에 또 다른 뷰를 정의할 수 있다는 설명은 옳다. 뷰의 정의는 SELECT 문이므로 그 뷰를 FROM 절에 놓고 새로운 뷰를 만들 수 있다.

3. 뷰에 대한 삽입·갱신·삭제 연산에는 오히려 제약사항이 따른다. 집계 함수, GROUP BY, DISTINCT를 포함하거나 여러 테이블을 조인해 만든 뷰는 원본 행을 특정할 수 없어 변경 연산이 허용되지 않는다.

4. 독립적인 인덱스를 가질 수 없다는 설명은 옳다. 뷰는 물리적으로 저장된 데이터가 없는 가상 테이블이므로 인덱스는 기반이 되는 실제 테이블에만 만들 수 있다.

정리

뷰 — 기본 테이블에서 유도된 가상 테이블, 정의만 저장. 보안에 유리하고 뷰 위의 뷰 정의 가능, 독립 인덱스 불가, 삽입·갱신·삭제에 제약 있음. 변경은 ALTER 불가, DROP으로 삭제 후 재생성.

#데이터베이스#보안

Q12

다음 릴레이션의 카디널리티와 차수가 옳게 나타낸 것은? 아이디 성명 나이 등급 적립금 가입년도 yuyu01 원유철 36 3 2000 2008 sykim10 김성일 29 2 3300 2014 kshan4 한경선 45 3 2800 2009 namsu52 이남수 33 5 1000 2016

1카디널리티 : 4, 차수 : 4

2카디널리티 : 4, 차수 : 6

3카디널리티 : 6, 차수 : 4

4카디널리티 : 6, 차수 : 6

정답 2번 · 카디널리티 : 4, 차수 : 6

핵심 해설

카디널리티(Cardinality)는 릴레이션의 튜플, 즉 행의 개수이고 차수(Degree)는 속성, 즉 열의 개수이다. 제시된 표의 열은 아이디, 성명, 나이, 등급, 적립금, 가입년도로 6개이므로 차수는 6이다. 행은 yuyu01(원유철), sykim10(김성일), kshan4(한경선), namsu52(이남수)의 4개이므로 카디널리티는 4이다. 따라서 카디널리티 4, 차수 6이 옳다.

보기별 해설

1. 카디널리티 4, 차수 4는 행의 수만 맞다. 열이 아이디·성명·나이·등급·적립금·가입년도로 6개이므로 차수는 4가 아니라 6이다.

2. 카디널리티 4, 차수 6이 표를 그대로 센 값이다. 데이터 행이 4개이므로 카디널리티가 4, 속성 열이 6개이므로 차수가 6이다.

3. 카디널리티 6, 차수 4는 행 수와 열 수를 서로 뒤바꾼 값이다. 6은 열의 개수, 4는 행의 개수이므로 대응이 반대이다.

4. 카디널리티 6, 차수 6은 차수만 맞다. 열 개수 6을 행 개수에도 그대로 적용한 값으로, 실제 데이터 행은 4개이다.

정리

카디널리티 = 튜플(행) 수 = 기수, 차수 = 속성(열) 수 = Degree. 표를 볼 때 헤더 행은 세지 않는다.

#데이터베이스

Q13

다음 SQL 문에서 ( ) 안에 들어갈 내용으로 옳은 것은? UPDATE 인사급여 ( ) 호봉 = 15 WHERE 성명 = ‘홍길동’;

1SET

2FROM

3INTO

4IN

정답 1번 · SET

핵심 해설

UPDATE 문의 기본 형식은 UPDATE 테이블명 SET 속성명 = 값 WHERE 조건; 이다. 절 순서대로 보면 UPDATE 인사급여가 갱신 대상 테이블을 지정하고, WHERE 성명 = '홍길동'이 그 테이블에서 성명이 홍길동인 튜플만 골라내며, SET 호봉 = 15가 선택된 튜플의 호봉 속성 값을 15로 바꾼다. 따라서 변경할 속성과 값을 지정하는 자리에 들어갈 키워드는 SET이다.

보기별 해설

1. SET은 UPDATE 문에서 변경할 속성과 새 값을 지정하는 절이다. SET 호봉 = 15는 WHERE 조건으로 선택된 튜플의 호봉 값을 15로 갱신한다.

2. FROM은 SELECT 문에서 조회 대상 테이블을 지정하는 절이다. UPDATE 문은 명령어 뒤에 테이블명을 바로 쓰므로 FROM이 들어갈 자리가 없다.

3. INTO는 INSERT INTO 테이블명 VALUES(...) 형태로 삽입할 대상 테이블을 지정할 때 쓰는 키워드이다. 새 튜플을 넣는 명령의 일부이므로 기존 값을 바꾸는 UPDATE와는 맞지 않는다.

4. IN은 WHERE 절에서 값이 주어진 목록이나 부속 질의 결과에 포함되는지 검사하는 비교 연산자이다. 갱신할 속성과 값을 지정하는 역할은 하지 못한다.

정리

DML 기본 형식 — INSERT INTO 테이블(속성) VALUES(값) / UPDATE 테이블 SET 속성=값 WHERE 조건 / DELETE FROM 테이블 WHERE 조건. UPDATE만 SET을 쓴다.

#데이터베이스#SQL

Q14

병행제어 기법의 종류가 아닌 것은?

1로킹 기법

2시분할 기법

3타임 스탬프 기법

4다중 버전 기법

정답 2번 · 시분할 기법

핵심 해설

병행제어(Concurrency Control)는 여러 트랜잭션이 동시에 수행될 때 데이터베이스의 일관성이 깨지지 않도록 상호작용을 제어하는 기법이다. 대표적인 기법으로는 데이터에 잠금을 걸어 접근을 통제하는 로킹(Locking) 기법, 트랜잭션에 고유한 시각을 부여해 그 순서대로 직렬 가능하게 만드는 타임 스탬프(Time Stamp) 기법, 갱신 시마다 새 버전을 만들어 읽기와 쓰기의 충돌을 피하는 다중 버전 병행제어(MVCC), 그리고 일단 수행한 뒤 검증하는 낙관적 병행제어가 있다. 시분할(Time Sharing)은 운영체제가 CPU 시간을 잘게 나누어 여러 사용자에게 번갈아 할당하는 스케줄링 방식으로 병행제어 기법이 아니다.

보기별 해설

1. 로킹 기법은 대표적인 병행제어 기법이다. 트랜잭션이 데이터에 접근하기 전 lock을 걸고 사용 후 unlock 하여 다른 트랜잭션의 간섭을 막으며, 2단계 로킹 규약으로 직렬 가능성을 보장한다.

2. 시분할 기법은 병행제어 기법이 아니라 운영체제의 CPU 스케줄링 방식이다. 각 사용자에게 일정한 시간 할당량(time slice)을 돌아가며 배정해 동시에 쓰는 것처럼 보이게 하는 기술이다.

3. 타임 스탬프 기법은 병행제어 기법이다. 트랜잭션이 시스템에 들어온 시각을 고유 식별자로 부여하고 그 순서대로 처리해, 로킹 없이 직렬 가능성을 보장하며 교착상태가 발생하지 않는다.

4. 다중 버전 기법(MVCC)은 병행제어 기법이다. 데이터가 갱신될 때마다 새로운 버전을 만들어 두고 읽기 트랜잭션에는 알맞은 과거 버전을 제공해, 읽기와 쓰기가 서로를 기다리지 않게 한다.

정리

병행제어 기법 — 로킹, 타임 스탬프, 다중 버전(MVCC), 낙관적 병행제어. 시분할은 운영체제의 CPU 스케줄링 기법이다.

#데이터베이스

Q15

SQL의 논리 연산자가 아닌 것은?

1AND

2OTHER

3OR

4NOT - 4

정답 2번 · OTHER

핵심 해설

SQL의 연산자는 산술 연산자(+, -, *, /), 비교 연산자(=, <>, >, <, >=, <=), 논리 연산자로 나뉜다. 이 중 논리 연산자는 조건식을 결합하거나 부정하는 데 쓰이며 AND(그리고), OR(또는), NOT(부정) 세 가지뿐이다. OTHER는 SQL에 존재하지 않는 키워드이므로 논리 연산자가 아니다. 참고로 BETWEEN, IN, LIKE, IS NULL은 논리 연산자가 아니라 WHERE 절에서 쓰는 특수 비교(술어) 연산자로 분류한다.

보기별 해설

1. AND는 논리 연산자이다. 좌우 두 조건이 모두 참일 때만 참을 반환하며 WHERE 학년 = 3 AND 학과 = '전산'처럼 조건을 좁힐 때 쓴다.

2. OTHER는 SQL에 존재하지 않는 키워드로 논리 연산자가 아니다. 조건 분기를 다루는 SQL 구문으로는 CASE ~ WHEN ~ ELSE ~ END가 있으며, 이때도 OTHER가 아니라 ELSE를 사용한다.

3. OR는 논리 연산자이다. 좌우 조건 중 하나라도 참이면 참을 반환하며 조건의 범위를 넓힐 때 사용한다.

4. NOT은 논리 연산자이다. 뒤따르는 조건의 참·거짓을 뒤집으며 NOT IN, NOT BETWEEN, IS NOT NULL처럼 다른 술어와 결합해서도 쓰인다.

정리

SQL 논리 연산자는 AND, OR, NOT 세 가지. BETWEEN·IN·LIKE·IS NULL은 논리 연산자가 아니라 WHERE 절의 술어(비교) 연산자이다.

#데이터베이스#SQL

Q16

관계대수에 대한 설명으로 틀린 것은?

1원하는 릴레이션을 정의하는 방법을 제공하며 비절차적 언어 이다.

2릴레이션 조작을 위한 연산의 집합으로 피연산자와 결과가 모 두 릴레이션이다.

3일반 집합 연산과 순수 관계 연산으로 구분된다.

4질의에 대한 해를 구하기 위해 수행해야 할 연산의 순서를 명시 한다.

정답 1번 · 원하는 릴레이션을 정의하는 방법을 제공하며 비절차적 언어 이다.

핵심 해설

관계대수(Relational Algebra)는 원하는 결과를 얻기 위해 릴레이션에 어떤 연산을 어떤 순서로 적용할지 명시하는 절차적 언어이다. 피연산자도 릴레이션이고 결과도 릴레이션이며, 합집합(∪)·교집합(∩)·차집합(−)·카티션 프로덕트(×)의 일반 집합 연산과, 셀렉트(σ)·프로젝트(π)·조인(⋈)·디비전(÷)의 순수 관계 연산으로 구분된다. 반면 '무엇을 원하는지'만 기술하고 절차는 밝히지 않는 비절차적 언어는 관계해석(Relational Calculus)이다. 따라서 관계대수를 비절차적 언어라고 한 서술이 틀렸다.

보기별 해설

1. 원하는 릴레이션을 정의하는 방법을 제공하며 비절차적 언어라는 설명은 관계대수가 아니라 관계해석(Relational Calculus)에 대한 서술이다. 관계해석은 튜플 관계해석과 도메인 관계해석으로 나뉘며 술어 논리에 기반해 '무엇을' 원하는지만 기술한다.

2. 릴레이션 조작을 위한 연산의 집합으로 피연산자와 결과가 모두 릴레이션이라는 설명은 옳다. 이 폐쇄성 덕분에 한 연산의 결과를 다시 다음 연산의 입력으로 이어 붙일 수 있다.

3. 일반 집합 연산과 순수 관계 연산으로 구분된다는 설명은 옳다. 일반 집합 연산은 합집합(∪)·교집합(∩)·차집합(−)·카티션 프로덕트(×)이고, 순수 관계 연산은 셀렉트(σ)·프로젝트(π)·조인(⋈)·디비전(÷)이다.

4. 질의에 대한 해를 구하기 위해 수행할 연산의 순서를 명시한다는 설명은 옳으며, 이것이 곧 관계대수가 절차적 언어로 분류되는 이유이다.

정리

관계대수 = 절차적 언어(어떻게), 관계해석 = 비절차적 언어(무엇을). 순수 관계 연산 — σ 셀렉트(행 선택), π 프로젝트(열 선택), ⋈ 조인, ÷ 디비전.

#데이터베이스

Q17

SQL문에서 HAVING을 사용할 수 있는 절은?

1LIKE 절

2WHERE 절

3GROUP BY 절

4ORDER BY 절

정답 3번 · GROUP BY 절

핵심 해설

SELECT 문의 절은 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY 순으로 처리된다. FROM에서 테이블을 읽고, WHERE에서 개별 행을 걸러 내며, GROUP BY에서 남은 행을 지정한 열 값이 같은 것끼리 묶어 그룹을 만든다. HAVING은 그 다음 단계에서 만들어진 그룹 자체에 조건을 걸어 COUNT(*) >= 3 같은 집계 결과로 그룹을 걸러 내는 절이므로, 그룹이 존재해야만 의미가 있어 반드시 GROUP BY 절과 함께 사용한다. 따라서 HAVING을 사용할 수 있는 절은 GROUP BY 절이다.

보기별 해설

1. LIKE 절은 사실 독립된 절이 아니라 WHERE 절 안에서 쓰는 문자열 패턴 비교 연산자이다. %와 _ 와일드카드로 부분 일치를 검사하며 그룹 조건과는 무관하다.

2. WHERE 절은 그룹이 만들어지기 전, 개별 튜플에 조건을 적용해 행을 걸러 내는 절이다. 처리 순서상 GROUP BY보다 앞서므로 집계 함수 결과를 조건으로 쓸 수 없고 HAVING이 붙지도 않는다.

3. GROUP BY 절은 지정한 속성 값이 같은 튜플끼리 그룹을 만드는 절이며, HAVING은 이렇게 만들어진 그룹에 조건을 거는 부속 절이다. 그래서 HAVING은 GROUP BY와 짝을 이루어 사용한다.

4. ORDER BY 절은 최종 결과 집합을 특정 속성 기준으로 오름차순(ASC)이나 내림차순(DESC) 정렬하는 절이다. 처리 순서상 가장 마지막이며 조건을 거는 기능이 없다.

정리

SELECT 처리 순서 — FROM → WHERE(행 조건) → GROUP BY(그룹 생성) → HAVING(그룹 조건) → SELECT → ORDER BY(정렬). HAVING은 GROUP BY와 짝, WHERE는 그룹화 이전.

#데이터베이스#SQL

Q18

데이터베이스의 무결성 규정(Integrity Rule)과 관련한 설명으로 틀린 것은?

1무결성 규정에는 데이터가 만족해야 될 제약 조건규정을, 참조 할 때 사용하는 식별자 등의 요소가 포함될 수 있다.

2무결성 규정의 대상으로는 도메인키종속성, , 등이 있다.

3정식으로 허가받은 사용자가 아닌 불법적인 사용자에 의한 갱 신으로부터 데이터베이스를 보호하기 위한 규정이다.

4릴레이션 무결성 규정(Relation Integrity Rules)은 릴레이션 을 조작하는 과정에서의 의미적 관계(Semantic Relationship) 를 명세한 것이다.

정답 3번 · 정식으로 허가받은 사용자가 아닌 불법적인 사용자에 의한 갱 신으로부터 데이터베이스를 보호하기 위한 규정이다.

핵심 해설

무결성(Integrity)은 데이터베이스에 저장된 데이터가 정확하고 일관된 상태를 유지하는 성질이며, 무결성 규정은 데이터가 만족해야 할 제약 조건을 명세한 것이다. 개체 무결성(기본키는 NULL이나 중복 불가), 참조 무결성(외래키는 참조 릴레이션의 기본키 값이거나 NULL), 도메인 무결성(속성 값은 정의된 도메인에 속함) 등이 이에 해당한다. 반면 불법적인 사용자로부터 데이터베이스를 보호하는 것은 무결성이 아니라 보안(Security)의 목적이며, GRANT·REVOKE 같은 권한 제어로 다룬다. 무결성은 '인가된 사용자가 실수로 부정확한 데이터를 넣는 것'을 막고, 보안은 '인가되지 않은 사용자의 접근 자체'를 막는다는 점이 결정적 차이이다.

보기별 해설

1. 무결성 규정에 제약 조건과 참조 시 사용하는 식별자 등이 포함될 수 있다는 설명은 옳다. 참조 무결성에서 외래키가 참조 릴레이션의 기본키를 가리키도록 명세하는 것이 그 예이다.

2. 무결성 규정의 대상으로 도메인, 키, 종속성 등이 있다는 설명은 옳다. 도메인 무결성은 속성 값의 범위와 자료형을, 키 무결성은 기본키의 유일성과 NULL 불가를, 종속성 무결성은 속성 간 함수 종속 관계를 규정한다.

3. 정식으로 허가받은 사용자가 아닌 불법적인 사용자의 갱신으로부터 데이터베이스를 보호한다는 것은 무결성이 아니라 보안(Security)의 정의이다. 보안은 GRANT·REVOKE 권한 제어와 암호화로 인가되지 않은 접근을 막고, 무결성은 인가된 사용자가 넣는 값이 규정에 맞는지를 검사한다.

4. 릴레이션 무결성 규정이 릴레이션을 조작하는 과정에서의 의미적 관계를 명세한 것이라는 설명은 옳다. 삽입·삭제·갱신 시 어떤 값이 허용되고 어떤 연쇄 동작이 일어나야 하는지를 규정한다.

정리

무결성 vs 보안 — 무결성은 인가된 사용자의 잘못된 값 입력을 막아 데이터의 정확성·일관성을 지키고(개체·참조·도메인 무결성), 보안은 인가되지 않은 사용자의 접근 자체를 막는다(GRANT·REVOKE).

#데이터베이스

Q19

분산 데이터베이스 시스템(Distributed Database System)에 대한 설명으로 틀린 것은?

1분산 데이터베이스는 논리적으로는 하나의 시스템에 속하지만 물리적으로는 여러 개의 컴퓨터 사이트에 분산되어 있다.

2위치 투명성중복, 투명성병행, 투명성장애, 투명성을 목표로 한다.

3데이터베이스의 설계가 비교적 어렵고개발, 비용과 처리 비용 이 증가한다는 단점이 있다.

4분산 데이터베이스 시스템의 주요 구성 요소는 분산 처리기, P2P 시스템단일, 데이터베이스 등이 있다.

정답 4번 · 분산 데이터베이스 시스템의 주요 구성 요소는 분산 처리기, P2P 시스템단일, 데이터베이스 등이 있다.

핵심 해설

분산 데이터베이스 시스템은 물리적으로 여러 사이트에 흩어져 있는 데이터베이스를 논리적으로는 하나인 것처럼 사용하게 하는 시스템이다. 주요 구성 요소는 각 사이트에서 자체 처리 능력을 갖는 분산 처리기(Distributed Processor), 여러 사이트에 물리적으로 분산된 분산 데이터베이스(Distributed Database), 사이트들을 연결하는 통신 네트워크(Network), 그리고 이를 조정하는 분산 트랜잭션 관리자이다. 목표로는 위치 투명성, 중복(복제) 투명성, 병행 투명성, 장애 투명성의 네 가지 투명성을 든다. 따라서 구성 요소로 'P2P 시스템'과 '단일 데이터베이스'를 든 설명은 틀렸으며, 단일 데이터베이스는 분산이라는 전제 자체와 모순된다.

보기별 해설

1. 분산 데이터베이스가 논리적으로는 하나의 시스템에 속하지만 물리적으로는 여러 컴퓨터 사이트에 분산되어 있다는 설명은 분산 데이터베이스의 정의 그대로이다. 사용자는 데이터가 어디에 있는지 몰라도 하나의 데이터베이스처럼 사용할 수 있다.

2. 위치 투명성, 중복 투명성, 병행 투명성, 장애 투명성을 목표로 한다는 설명은 옳다. 각각 데이터의 물리적 위치·복제본 존재·동시 수행·사이트 장애를 사용자가 의식하지 않아도 되게 만드는 성질이다.

3. 데이터베이스의 설계가 비교적 어렵고 개발 비용과 처리 비용이 증가한다는 설명은 옳다. 분산 데이터베이스는 응답 속도와 가용성이라는 장점을 얻는 대신 설계 복잡도, 잠재적 오류 증가, 통신 오버헤드라는 단점을 감수한다.

4. 분산 데이터베이스 시스템의 주요 구성 요소를 분산 처리기, P2P 시스템, 단일 데이터베이스라고 한 설명은 틀렸다. 올바른 구성 요소는 분산 처리기, 분산 데이터베이스, 통신 네트워크, 분산 트랜잭션 관리자이며, '단일 데이터베이스'는 분산이라는 성격과 정면으로 어긋난다.

정리

분산 DB 구성 요소 — 분산 처리기, 분산 데이터베이스, 통신 네트워크, 분산 트랜잭션 관리자. 4대 투명성 — 위치, 중복(복제), 병행, 장애.

#데이터베이스

Q20

CREATE TABLE문에 포함되지 않는 기능은?

1속성 타입 변경

2속성의 NOT NULL 여부 지정

3기본키를 구성하는 속성 지정

4CHECK 제약조건의 정의

정답 1번 · 속성 타입 변경

핵심 해설

CREATE TABLE은 새 테이블을 만들면서 속성의 이름과 자료형, NOT NULL 여부, 기본키(PRIMARY KEY)와 외래키(FOREIGN KEY), UNIQUE, CHECK, DEFAULT 같은 제약 조건을 한꺼번에 정의하는 DDL 명령이다. 즉 처음 만들 때 구조를 '설정'하는 명령이지, 이미 만들어진 테이블의 구조를 '변경'하는 명령이 아니다. 이미 존재하는 속성의 자료형을 바꾸거나 열을 추가·삭제하려면 ALTER TABLE의 MODIFY, ADD, DROP COLUMN을 사용해야 한다. 따라서 속성 타입 변경은 CREATE TABLE에 포함되지 않는 기능이다.

보기별 해설

1. 속성 타입 변경은 CREATE TABLE이 아니라 ALTER TABLE의 기능이다. ALTER TABLE 테이블명 MODIFY 속성명 자료형 형태로 이미 정의된 열의 자료형을 바꾼다.

2. 속성의 NOT NULL 여부 지정은 CREATE TABLE에서 가능하다. 열 정의 뒤에 NOT NULL을 붙이면 해당 속성에 NULL 값이 들어가는 것을 막는다.

3. 기본키를 구성하는 속성 지정은 CREATE TABLE에서 가능하다. PRIMARY KEY(속성목록) 절로 지정하며, 여러 속성을 묶은 복합키도 함께 정의할 수 있다.

4. CHECK 제약조건의 정의도 CREATE TABLE에서 가능하다. CHECK(학년 BETWEEN 1 AND 4)처럼 속성이 가질 수 있는 값의 범위를 제한해 도메인 무결성을 강제한다.

정리

CREATE TABLE에서 지정 가능 — 속성명·자료형, NOT NULL, PRIMARY KEY, FOREIGN KEY, UNIQUE, DEFAULT, CHECK. 이미 만든 테이블의 속성 타입 변경·열 추가/삭제는 ALTER TABLE(MODIFY/ADD/DROP).

#데이터베이스