41. 참조 무결성을 유지하기 위하여 DROP문에서 부모 테이블의 항목 값을 삭제할 경우 자동적으로 자식 테이블의 해당 레코드를 삭제하기 위한 옵션은?
- CLUSTER
- CASCADE
- SET-NULL
- RESTRICTED
보기별 비교표
| ✅ CASCADE | 부모가 삭제되면 자식도 자동 삭제 | 자식 레코드도 함께 삭제됨 | 참조 무결성 보장 |
| ❌ SET NULL | 부모 삭제 시 자식의 FK 값을 NULL로 변경 | 자식은 남고, 참조 컬럼만 NULL | 자식 테이블이 FK에 NULL 허용해야 함 |
| ❌ RESTRICTED (RESTRICT) | 부모가 참조 중이면 삭제 금지 | 자식이 존재하면 삭제 불가 | 기본값 (안전성 높음) |
| ❌ CLUSTER | 여러 테이블을 물리적으로 한 묶음으로 저장 | 삭제와는 무관 | 데이터 저장 구조 개념 (Oracle 등에서 사용됨) |
42. 뷰(View)에 대한 설명으로 옳지 않은 것은
- 뷰는 CREATE 문을 사용하여 정의한다
- 뷰는 데이터의 논리적 독립성을 제공한다
- 뷰를 제거할 때에는 DROP 문을 사용한다
- 뷰는 저장장치 내에 물리적으로 존재한다
🎯 해설
✔ 뷰(View)란?
하나 이상의 테이블로부터 파생된 가상의 테이블로,
물리적으로 데이터를 저장하지 않고, SELECT 문 결과를 마치 테이블처럼 보여주는 객체야.
❌ 보기 ④ 왜 틀렸는가?
- 뷰는 물리적으로 데이터를 저장하지 않는다
- 대신, 실제 테이블을 기반으로 하는 SQL 질의 결과를 보여주는 논리적 객체야
- 즉, 가상의 테이블이기 때문에 실제 저장 공간을 차지하지 않음
👉 일부 DBMS에서 Materialized View (물리 뷰) 라는 특별한 형태는 데이터를 저장하지만,
일반적인 View는 저장 X
✅ 나머지 보기 설명
| ✅ CREATE 문을 사용하여 정의한다 | CREATE VIEW view_name AS SELECT ... 사용 | ✔ 옳음 |
| ✅ 데이터의 논리적 독립성을 제공한다 | 뷰를 통해 실제 테이블 구조를 감추고, 사용자에게 필요한 정보만 보여줄 수 있음 | ✔ 옳음 |
| ✅ DROP 문으로 제거할 수 있다 | DROP VIEW view_name; 사용 | ✔ 옳음 |
| ❌ 저장장치에 물리적으로 존재한다 | ❌ 뷰는 가상 테이블, 물리 저장 X | ❌ 정답 |
📊 테이블 vs 뷰 비교표
| 저장 공간 | ✅ 실제 데이터 저장 | ❌ 데이터 저장 안 함 |
| 생성 방법 | CREATE TABLE | CREATE VIEW |
| 수정 가능성 | ✅ 직접 수정 가능 | 일부 제한 있음 (JOIN 뷰 등) |
| 성능 | 빠름 (직접 저장) | 느릴 수 있음 (기준 테이블에 의존) |
| 보안 | 직접 권한 설정 | 뷰를 통해 컬럼 제한 가능 (보안 필터링) |
✅ 보너스: 관련 객체
| 뷰 (View) | 가상의 테이블 (SELECT 결과를 저장 없이 보여줌) |
| 머티리얼라이즈드 뷰 (Materialized View) | 실제 데이터 저장하는 뷰 – 성능 향상용 |
| 인덱스 (Index) | 검색 성능 향상을 위한 별도 구조 |
| 시퀀스 (Sequence) | 자동 증가 값 생성기 (예: 자동 번호) |
| 동의어 (Synonym) | 다른 테이블/뷰/시퀀스 등을 별칭으로 부르는 객체 |
✅ 결론
- 뷰는 물리적으로 저장되지 않으며,
- 정답은 ❌ “저장장치에 물리적으로 존재한다”
43. DML에 해당하는 SQL명령으로만 나열된 것은?
✅ DML이란?
데이터 조작 언어
테이블에 저장된 데이터(레코드)를 조회, 삽입, 수정, 삭제하는 명령어 집합이야.
📘 DML에 해당하는 SQL 명령어
| SELECT | 데이터 조회 (읽기) |
| INSERT | 새로운 행(레코드) 삽입 |
| UPDATE | 기존 데이터 수정 |
| DELETE | 데이터 삭제 |
✅ 위 네 가지가 모두 DML 명령어야.
❌ DML이 아닌 것들은?
| DDL (정의어) | CREATE, ALTER, DROP, TRUNCATE 등 | 테이블 구조 정의/변경 |
| DCL (제어어) | GRANT, REVOKE | 권한 부여/회수 |
| TCL (트랜잭션 제어) | COMMIT, ROLLBACK | 트랜잭션 처리 |
🎯 예시 보기에서 고르는 팁
| SELECT, INSERT, UPDATE, DELETE | ✅ 전부 DML | ✅ 정답 |
| CREATE, INSERT, SELECT | ❌ CREATE는 DDL | ❌ |
| DELETE, DROP, UPDATE | ❌ DROP은 DDL | ❌ |
| SELECT, GRANT, INSERT | ❌ GRANT는 DCL | ❌ |
✅ 결론
DML에 해당하는 명령어만 포함된 보기는
SELECT, INSERT, UPDATE, DELETE로 구성된 경우야.
44. 관계대수의 순수 관계 연산자가 아닌 것은?
- Select
- Cartesiam Product
- Division
- Project
관계대수(Relational Algebra)란?
관계형 데이터베이스에서 데이터를 다루기 위한 이론적 연산 체계
주어진 테이블(관계)에서 원하는 데이터를 새로운 관계 형태로 추출하는 방법을 수학적으로 정의한 것
즉, SQL의 기반이 되는 이론적 데이터 처리 언어라고 보면 돼.
✅ 관계대수의 연산자 분류
관계대수는 크게 **순수 관계 연산자(기본 연산)**와 **일반 연산자(파생 연산)**로 나뉘어.
📊 순수 관계 연산자 vs 일반 관계 연산자
| ✅ SELECT (σ) | 순수 관계 연산자 | 행(튜플)을 조건에 따라 선택 | σ조건(관계) |
| ✅ PROJECT (π) | 순수 관계 연산자 | 열(속성)만 추출 | π속성명(관계) |
| ✅ DIVISION (÷) | 순수 관계 연산자 | 두 관계를 나누어 공통 데이터 추출 | R ÷ S |
| ❌ CARTESIAN PRODUCT (×) | ❌ 일반 관계 연산자 | 두 테이블의 모든 조합 생성 | R × S |
✅ 순수 관계 연산자(기본 5가지)
| SELECT | σ | 조건에 맞는 행(튜플) 선택 |
| PROJECT | π | 원하는 **열(속성)**만 추출 |
| RENAME | ρ | 테이블 이름이나 속성 이름 변경 |
| UNION | ∪ | 두 테이블의 합집합 |
| SET DIFFERENCE | − | 두 테이블의 차집합 |
| DIVISION | ÷ | 나누기 연산 (모든 조건 만족하는 값 찾기) |
❌ 일반 연산자 (순수 아님)
| CARTESIAN PRODUCT (×) | 모든 튜플 쌍을 조합해 새로운 관계 생성 |
| JOIN | 공통 속성 기반으로 두 테이블 결합 |
| INTERSECTION (∩) | 교집합 |
| NATURAL JOIN | 같은 속성을 기준으로 자동 결합 |
✅ 결론
순수 관계 연산자가 아닌 것은
❌ CARTESIAN PRODUCT (×)
(일반 연산자에 속하며, 순수 관계 대수 연산자는 아님)
45. 관계 데이터 모델의 무결성 제약 중 기본키 값의 속성 값이 널(Null)값이 아닌 원자 값을 갖는 성질은
- 개체 무결성
- 참조 무결성
- 도메인 무결성
- 튜플의 유일성
| 보기 | 설명 | 맞는지 여부 |
| ✅ 개체 무결성(Entity Integrity) | 기본키는 null이 될 수 없고, **하나의 고유한 값(원자값)**만 가져야 함 | ✔️ 정답 |
| 참조 무결성(Referential Integrity) | 외래키(FK)는 참조하는 기본키(PK)가 존재해야 함 | ❌ |
| 도메인 무결성(Domain Integrity) | 각 컬럼의 데이터 타입, 허용값(예: 날짜만, 1~100만 가능 등)을 지켜야 함 | ❌ |
| 튜플의 유일성 | 각 행(레코드)은 중복되면 안 됨 → 기본키 역할과 관련 있음 | ❌ |
46. 제 3정규형에서 보이스코드 정규형(BCNF)으로 정규화 하기 위한 작업은?
- 원자 값이 아닌 도메인을 분해
- 부분 함수 종속 제거
- 이행 함수 종속 제거
- 결정자가 후보키가 아닌 함수 종속 제거
✅ 정규화란?
데이터베이스에서 중복을 제거하고,
**데이터 이상(삽입/삭제/갱신 이상)**을 방지하기 위해
테이블을 논리적으로 쪼개는 과정
🎯 정규화 단계 요약표
| 1NF (제1정규형) |
반복 속성, 원자값 아님 | 모든 속성은 **원자값(단일 값)**이어야 함 | 주소 = “서울, 부산” ❌ | 테이블을 구조적으로 정리 |
| 2NF (제2정규형) |
부분 함수 종속 | 기본키가 복합키일 경우, 일부 키에만 종속된 속성 제거 | (학번, 과목) → 교수명 ❌ | 키 전체에만 의존해야 함 |
| 3NF (제3정규형) |
이행 함수 종속 | A → B → C 같은 간접 종속 제거 | 학번 → 과, 과 → 과장 ❌ | 중간 단계 제거 |
| BCNF (보이스-코드 정규형) |
후보키가 아닌 결정자 | 모든 결정자는 후보키여야 함 | 과목 → 교수 (과목이 후보키 아님!) ❌ | 3NF보다 더 엄격한 키 조건 |
🔧 주요 용어 간단 정의
| 부분 함수 종속 | 복합키의 일부 속성만으로 결정되는 종속 |
| 이행 함수 종속 | A → B, B → C가 있을 때 A → C 간접 종속 |
| 결정자 | 값을 결정하는 속성 (A → B에서 A가 결정자) |
| 후보키 | 기본키가 될 수 있는 후보들 중 하나 |
📘 예시 흐름 (학생 테이블 예)
초기 테이블:
1NF: 원자값으로 정리
2NF: 부분 종속 제거
3NF: 이행 종속 제거
BCNF: 후보키가 아닌 결정자 제거
✅ 시각적 정리
✅ 마무리 요약
| 1NF | 비원자값, 반복 속성 | 칼럼 정리 |
| 2NF | 부분 함수 종속 | 속성 분리 |
| 3NF | 이행 함수 종속 | 간접 종속 제거 |
| BCNF | 후보키가 아닌 결정자 | 강한 함수 종속 제거 |
47. 로킹(Locking)기법에 대한 설명으로 틀린 것은
- 로킹의 대상이 되는 객체의 크기를 로킹 단위라고 한다
- 로킹 단위가 작아지면 병행성 수준이 낮아진다
- 데이터베이스도 로킹 단위가 될 수 있다
- 로킹 단위가 커지면 로크 수가 작아 로킹 오버헤드가 감소한다
먼저, 로킹(Locking)이란?
데이터베이스에서 여러 사용자가 동시에 같은 데이터를 사용하려고 할 때, 충돌을 막기 위해 잠그는(LOCK) 기술
즉,
- 누군가 수정 중이면, 다른 사람은 읽거나 수정 못 하게 잠금
- 그래서 데이터가 엉키지 않고 일관성 있게 유지됨
철수: 은행 잔고 100만원 → 20만원 출금 중...
영희: 동시에 같은 잔고 100만원 보고 있음
→ 둘 다 20만원 출금하면? → 데이터 충돌 발생 ❌
➡ 그래서 철수가 출금 중일 땐 영희가 잠시 대기하도록 "잠금(Lock)"을 건다
➡ 이게 바로 로킹 기법이야!
🎯 문제 보기 다시 보기
틀린 설명은?
| ✅ ① 로킹의 대상이 되는 객체의 크기를 로킹 단위라고 한다 | 맞음! | ✔️ |
| ❌ ② 로킹 단위가 작아지면 병행성 수준이 낮아진다 | ❌ 틀림! → 작아지면 병행성은 높아짐 | ❌ 정답 |
| ✅ ③ 데이터베이스도 로킹 단위가 될 수 있다 | 맞음. (테이블, 페이지, 레코드, 전체 DB 등 모두 가능) | ✔️ |
| ✅ ④ 로킹 단위가 커지면 로크 수가 작아 로킹 오버헤드가 감소한다 | 맞음. (하지만 병행성은 낮아짐) | ✔️ |
🔧 핵심 개념: 로킹 단위(Granularity)
| 작음 | 예: 행(Row) 단위, 칼럼 단위 | 높음 (동시 처리 많음) | 높음 (잠금 관리 복잡) |
| 큼 | 예: 테이블 전체, DB 전체 | 낮음 (한 번에 잠금 큼) | 낮음 (간단함) |
✅ 정답 요약
"로킹 단위가 작아지면 병행성 수준이 낮아진다" → ❌
실제로는 작아질수록 병행성은 높아진다!
📌 추가로 알아두면 좋은 개념
| 공유 Lock (S-Lock) | 읽기는 가능, 수정은 금지 |
| 배타 Lock (X-Lock) | 수정하려면 걸어야 하는 Lock, 다른 트랜잭션은 읽기도 못 함 |
| 교착 상태(Deadlock) | 서로가 서로를 기다려서 끝나지 않는 상태 → 회피 필요 |
1. 로킹 오버헤드(Locking Overhead)란?
데이터를 잠글 때 발생하는 부가적인 비용을 말해.
즉, 잠금(lock)을 관리하는 데 들어가는 시스템 자원 소모야.
✅ 왜 오버헤드가 생길까?
- 잠금을 설정/해제하는 코드 처리
- 잠금 리스트 관리
- 충돌/대기 처리
- 교착 상태 감지 및 회피
📌 특징 요약
| 로킹 단위 작음 (행 단위) | 🔺 높음 (잠금 수가 많아짐) |
| 로킹 단위 큼 (테이블 단위) | 🔻 낮음 (잠금 수가 적음) |
✅ 예시
- 1만 명의 고객 정보 중 1명만 수정해야 함
- 테이블 전체를 잠그면 간단하지만, 9,999명은 대기해야 함
- 1명만 잠그면 병행성은 좋지만, 관리할 잠금도 많아짐
👉 그래서 성능과 동시성을 조율할 필요가 있어
🧠 2. 로킹 전략(Locking Strategy)
데이터 무결성과 성능을 지키기 위해 사용하는 잠금 정책
✅ 1) 비관적 로킹 (Pessimistic Locking)
"다른 놈이 건드릴까 무서우니, 먼저 잠가두고 시작"
| 동시성 낮음 | 항상 먼저 잠금 걸고 시작 |
| 안전함 | 충돌 거의 없음 |
| 속도 느림 | 불필요한 대기 가능성 |
| 예시 | 은행 계좌 처리, 재고 차감 등 |
✅ 2) 낙관적 로킹 (Optimistic Locking)
"다른 놈이 안 건들 거라고 믿고, 끝날 때 충돌 나면 다시 시도"
| 동시성 높음 | 잠금 없이 작업 진행 |
| 충돌 위험 | 마지막에 충돌하면 롤백 |
| 성능 빠름 | 충돌 적은 시스템에 적합 |
| 예시 | 게시글 읽기, 조회가 많은 시스템 |
✅ 3) 2단계 로킹(2PL, Two-Phase Locking)
트랜잭션이 진행되며 잠금을 걸고, 끝나기 전까지는 잠금 해제 금지
| 확장 단계 | 필요한 만큼 잠금을 계속 추가 |
| 축소 단계 | 한 번이라도 해제하면, 이후로는 새 잠금 불가 |
| 목적 | 직렬 가능성(Serializability) 보장 (안전한 동시성 제어) |
✅ 로킹 전략 요약표
| 비관적 | 먼저 잠금 후 작업 | 안정성 높음 | 동시성 낮음 | 계좌 이체 |
| 낙관적 | 충돌 나면 롤백 | 성능 우수 | 충돌 시 비용 큼 | 쇼핑몰 조회 |
| 2단계 | 확장 후 축소, 직렬성 보장 | 이론적 안전성 | 구현 복잡 | 트랜잭션 처리 시스템 |
✅ 마무리 요약
- 로킹 오버헤드: 잠금을 걸고 관리하는 데 드는 시스템 자원 비용
- 로킹 전략:
- 비관적: 미리 잠금 → 안정적, 느림
- 낙관적: 끝나고 확인 → 빠름, 위험
- 2단계 로킹: 직렬화 보장
48. 다음 SQL문에서 빈칸에 들어갈 내용으로 옳은 것은?
UPDATE 회원 ( ) 전화번호='010-14'
WHERE 회원번호='N4';
| SELECT | FROM | 데이터를 어디서 가져올지 지정 |
| WHERE | 조건 지정 (필터링) | |
| GROUP BY | 그룹화 (예: 부서별 평균) | |
| HAVING | 그룹 조건 지정 (GROUP BY 이후 필터) | |
| ORDER BY | 정렬 (ASC, DESC) | |
| INSERT | INTO | 테이블 지정 |
| VALUES | 삽입할 값 지정 | |
| UPDATE | SET | 수정할 컬럼과 값 지정 |
| WHERE | 수정할 행 조건 지정 | |
| DELETE | FROM | 삭제 대상 테이블 지정 |
| WHERE | 삭제할 행 조건 지정 | |
| CREATE | TABLE, INDEX, VIEW 등 | 새 객체 생성 |
| DROP | TABLE, VIEW, INDEX 등 | 객체 제거 |
49. 다음에서 설명하는 스키마는?
- 데이터베이스 전체를 정의한 것으로 데이터개체,관계,제약조건,접근권한, 무결성 규칙 등을 명세한것
- 개념 스키마
- 내부 스키마
- 외부 스키마
- 내용 스키마
🧠 스키마(Schema)란?
데이터베이스의 구조, 제약 조건, 구성요소들을 정의한 청사진(설계도)
쉽게 말해: 데이터를 어떤 방식으로 저장하고, 연결하고, 관리할지 정의한 것
✅ DB 3계층 스키마 구조 (ANSI-SPARC 모델)
| ✅ 외부 스키마 | External Schema | 사용자/응용프로그램 관점의 데이터 구조 → 개인화된 "뷰(View)" |
사용자 |
| ✅ 개념 스키마 | Conceptual Schema | 데이터베이스 전체를 논리적으로 정의 → 모든 테이블, 관계, 제약 조건 등 |
DB 관리자, 설계자 |
| ✅ 내부 스키마 | Internal Schema | 실제로 데이터가 저장되는 물리적 구조 정의 (저장 방법, 인덱스 등) |
DBMS, 시스템 |
📊 스키마 종류 요약표
| 외부 스키마 | 1층 | 사용자별로 보는 데이터 뷰 | 특정 사용자는 이름, 이메일만 조회 |
| ✅ 개념 스키마 | 2층 | DB 전체 구조/제약 정의 | 테이블 구조, FK, PK, 제약 조건 등 |
| 내부 스키마 | 3층 | 물리적 저장 방식 | 인덱스, 페이지 저장 방식, 파일 구조 |
🎯 보기 정리
| ✅ 개념 스키마 | 데이터베이스 전체 구조/관계/제약 등을 정의 | ✅ 정답 |
| ❌ 내부 스키마 | 물리적 저장 구조 | ❌ |
| ❌ 외부 스키마 | 사용자 맞춤 뷰 | ❌ |
| ❌ 내용 스키마 | ❌ 존재하지 않는 용어 (오답 유도용) | ❌ |
✅ 결론 요약
데이터베이스 전체 구조 및 제약을 논리적으로 정의한 스키마는?
➤ 정답: ✅ 개념 스키마
50. 시스템 카탈로그에 대한 설명으로 틀린 것은?
- 시스템 카탈로그의 갱신은 무결성 유지를 위하여 SQL을 이요하여 사용자가 직접 갱신하여야 한다
- 데이터베이스에 포함되는 데이터 객체에 대한 정의나 명세에 대한 정보를 유지관리한다
- DBMS가 스스로 생성하고 유지하는 데이터베이스 내의 특별한 테이블의 집합체이다
- 카탈로그에 저장된 정보를 메타 데이터라고 한다
🧠 시스템 카탈로그(System Catalog)란?
데이터베이스 안에 있는 **모든 객체(테이블, 뷰, 인덱스, 사용자 등)**의 정보를 자동으로 저장하고 관리하는 내부 테이블 집합이야.
쉽게 말하면:
DBMS(데이터베이스 시스템 스스로가 만들어서 관리하는 사전 같은 것)
🗂️ 시스템 카탈로그는 어떤 걸 저장할까?
- 테이블 이름, 컬럼 이름, 타입
- 제약조건 (PK, FK)
- 인덱스 정보
- 사용자 권한
- 뷰 정의
- 트리거 등
📘 예시:
| customers | name | TEXT | 50 |
| customers | age | INT | 4 |
➡ 이런 정보를 자동으로 저장해두는 게 시스템 카탈로그야.
❗ 왜 1번이 틀렸을까?
"사용자가 SQL로 직접 갱신해야 한다" → ❌
- 시스템 카탈로그는 사용자가 직접 수정하지 않는다!
- ✅ DBMS가 자동으로 갱신하고 유지한다
- 테이블 만들면 → 카탈로그에 자동 반영
- 컬럼 삭제하면 → 카탈로그도 자동 업데이트
➡ 사용자가 임의로 수정하면 무결성 깨짐 → 위험
✅ 보기별 설명
| ❌ ① 사용자가 SQL로 직접 갱신해야 한다 | ❌ DBMS가 자동 갱신 (사용자 직접 수정 안 함) | ❌ 정답 |
| ✅ ② 데이터 객체 정의 정보 유지 | 맞음. 테이블, 뷰 등 메타정보 관리 | ✔️ |
| ✅ ③ DBMS가 생성하고 유지하는 특별한 테이블 집합 | 정답. 사용자 눈에는 안 보일 수도 있음 | ✔️ |
| ✅ ④ 카탈로그에 저장된 정보를 메타데이터라고 한다 | 메타데이터 = "데이터에 대한 데이터" | ✔️ |
📊 용어 정리
| 시스템 카탈로그 | DBMS가 내부에서 관리하는 객체 정보 저장소 | 테이블 이름, 컬럼 타입 등 |
| 메타데이터 | 데이터를 설명하는 정보 | "name 컬럼은 TEXT 타입" |
| 사용자 데이터 | 우리가 넣는 실제 데이터 | "홍길동", "25살" 등 |
✅ 한 줄 요약
시스템 카탈로그는 DB 객체의 정보를 자동으로 저장/관리하는 DBMS 내부 테이블이며, 사용자가 직접 수정하지 않는다.
51. 다음 릴레이션의 카디널리티와 차수가 옳게 나타낸 것은
🧠 개념 정리
| ✅ 카디널리티 (Cardinality) | 행(row, 튜플)의 수 | 데이터 몇 줄 있어? | 4개 |
| ✅ 차수 (Degree) | 열(column, 속성)의 수 | 항목이 몇 개 있어? | 6개 |
🎯 이 문제에서
- 카디널리티: 행이 4개 → 4
- 차수: 열이 6개 (아이디, 성명, 나이, 등급, 적립금, 가입년도) → 6
✅ 정답: ③ 카디널리티 : 4, 차수 : 6
📌 보너스 요약
| 카디널리티 | 튜플 수 | 행(Row)의 개수 | 이 표엔 4명 → 4 |
| 차수 | 속성 수 | 열(Column)의 개수 | 항목이 6개 → 6 |
52. 병행제어 기법의 종류가 아닌 것은?
- 로킹 기법
- 시분할 기법
- 타임 스탬프 기법
- 다중 버전 기법
✅ 병행제어(Concurrency Control)란?
여러 사용자가 동시에 데이터베이스에 접근해도
데이터의 일관성과 무결성을 유지하도록 순서를 제어하는 기술
🧠 병행제어 기법의 대표적인 종류
| ✅ 로킹 기법 | 데이터를 잠가서 동시에 수정하지 못하게 함 | ✅ |
| ✅ 타임스탬프 기법 | 각 트랜잭션에 시간표시를 부여하여 순서 제어 | ✅ |
| ✅ 다중 버전 기법 (MVCC) | 데이터의 버전을 나누어 읽기/쓰기 충돌을 줄임 | ✅ |
| ❌ 시분할 기법 | 운영체제의 CPU 스케줄링 기법 (병행제어 X) | ❌ 정답 |
📘 보기 해설
| 로깅 기법 | ❌ 회복 기법(복구용 로그 기록) → 병행제어 X | ❌ |
| 시분할 기법 | ❌ 운영체제 용어 (시간을 나눠 CPU 공유) | ❌ 정답 |
| 타임스탬프 기법 | ✅ 병행제어용 시간 기반 순서 제어 | ✅ |
| 다중 버전 기법 | ✅ 읽기/쓰기 충돌 최소화 (MVCC) | ✅ |
📊 병행제어 vs 회복 기법 비교표
| ✅ 병행제어 | 로킹, 타임스탬프, 다중버전 | 동시에 접근하는 트랜잭션들 간 충돌 방지 | 은행 입출금 중복 방지 |
| ✅ 회복 기법 | 로깅, 체크포인트, 트랜잭션 롤백 | 장애 발생 시 DB 복구 | 시스템 다운 후 복원 |
✅ 한 줄 요약
병행제어 기법은 동시성 문제를 해결하기 위한 방법이고,
보기 중 시분할 기법은 운영체제 개념으로 병행제어와 무관하다.
53. 데이터 속성 간의 종속성에 대한 엄밀한 고려없이 잘못 설계된 데이터베이스에서는 데이터 처리 연산 수행 시 각종 이상현상이 발생할 수 있는데, 이러한 이상 현상이 아닌 것은?
- 검색 이상
- 삽입 이상
- 삭제 이상
- 갱신 이상
먼저, 이상현상(Anomaly)이란?
정규화가 제대로 안 된 테이블에서
데이터를 **삽입(insert), 삭제(delete), 수정(update)**할 때
**원하지 않는 부작용(데이터 손실, 중복 등)**이 발생하는 현상
📌 대표적인 이상현상 3가지
| ✅ 삽입 이상 (Insertion Anomaly) | 일부 데이터만 추가하고 싶어도 불필요한 다른 데이터도 강제로 입력해야 함 | 학생을 추가하려는데 아직 수강 과목이 없어서 못 넣음 |
| ✅ 삭제 이상 (Deletion Anomaly) | 한 정보만 삭제했는데 원하지 않는 다른 정보까지 같이 사라짐 | 어떤 과목 삭제했더니 학생 정보도 함께 삭제됨 |
| ✅ 갱신 이상 (Update Anomaly) | 동일한 정보가 여러 곳에 중복돼 있어, 일일이 다 수정 안 하면 불일치 발생 | 한 교수 이름을 바꿨는데 다른 테이블엔 그대로 남아있음 |
❌ 보기 중 틀린 것: 검색 이상
| 검색 이상 | ❌ 정규화 개념에서 사용되지 않는 용어 | ❌ 정답 |
| 삽입 이상 | ✅ 강제로 다른 열까지 넣어야 하는 문제 | ✔️ |
| 삭제 이상 | ✅ 일부 삭제가 전체 삭제로 이어지는 문제 | ✔️ |
| 갱신 이상 | ✅ 중복 데이터로 인해 수정 누락 발생 | ✔️ |
✅ 결론
정답: 검색 이상 ❌
→ 검색 이상은 정규화에서 말하는 공식적인 이상현상(Anomaly)이 아님!
54. 트랜잭션의 주요 특성 중 하나로, 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없음을 의미하는 것은?
- Log
- Consistency
- Isolation
- Durability
✅ 트랜잭션(Transaction)이란?
데이터베이스에서 하나의 작업 단위
즉, 논리적으로 반드시 함께 수행되어야 하는 작업의 묶음
📌 왜 트랜잭션이 필요할까?
예시: 은행 이체
👉 이 두 작업은 무조건 같이 성공하거나, 둘 다 안 돼야 해!
- A에서 돈 빠졌는데 B에 입금 안 되면? → ❌ 데이터 불일치 발생!
➡ 그래서 ①②를 하나의 트랜잭션으로 묶어서 처리함
✅ 트랜잭션의 대표적 특징: ACID
| A | Atomicity (원자성) | 모두 성공 or 모두 실패 (쪼갤 수 없음) |
| C | Consistency (일관성) | 트랜잭션 전후 데이터가 항상 정합성 유지 |
| I | Isolation (고립성) | 다른 트랜잭션과 간섭 없이 독립적으로 실행 |
| D | Durability (지속성) | 트랜잭션 완료 결과는 영구 저장됨 (전원 꺼져도 보존) |
🛠️ 트랜잭션이 실제로 사용되는 예
| 은행 이체 | 출금 + 입금 |
| 쇼핑몰 주문 | 재고 차감 + 주문 생성 + 포인트 차감 |
| 회원가입 | 계정 생성 + 기본 설정 + 인증 메일 발송 |
✅ 한 줄 요약
트랜잭션은 데이터베이스에서 "절대 함께 실행돼야 하는 작업 묶음"이야.
중간에 끊기면 안 되고, 모두 성공하거나 모두 실패해야 해.
55. 관계형 데이터베이스에서 다음 설명에 해당하는 키는?
한 릴레이션 내의 속성들의 집합으로 구성된 키로서, 릴레이션을 구성하는 모든 튜플에 대한 유일성은 만족시키지만 최소성은 만족시키지 못한다
- 후보키
- 대체키
- 슈퍼키
- 외래키
📊 키 종류별 비교표
| ✅ 슈퍼키(Super Key) | 튜플을 유일하게 식별할 수 있는 속성 집합 | (학번), (학번+이름), (주민번호+전화) 등 | ✔ 유일성 ❌ 최소성 |
| ✅ 후보키(Candidate Key) | 유일성 + 최소성 만족하는 최소 슈퍼키 | (학번), (주민번호) 등 | ✔ 유일성 ✔ 최소성 |
| ✅ 기본키(Primary Key) | 후보키 중 대표로 선택된 키 | (학번) | ✔ 유일성 ✔ 최소성 |
| ✅ 대체키(Alternate Key) | 후보키 중 기본키가 아닌 나머지 키 | 주민번호 (기본키가 학번일 경우) | ✔ 유일성 ✔ 최소성 |
| ✅ 외래키(Foreign Key) | 다른 테이블의 기본키를 참조하는 키 | 주문 테이블의 고객번호 (→ 고객 테이블 참조) | ❌ 유일성 ❌ 최소성 |
56. 물리적 데이터베이스 설계에 대한 설명으로 거리가 먼 것은?
- 물리적 설계의 목적은 효율적인 방법으로 데이터를 저장하는 것이다
- 트랜잭션 처리량과 응답시간,디스크용량 등을 고려해야 한다
- 저장 레코드의 형식,순서,접근 경로와 같은 정보를 사용하여 설계한다
- 트랜잭션의 인터페이스를 설계하며, 데이터 타입 및 데이터 타입들 간의 관계로 표현한다
🧠 물리적 설계(Physical Design)란?
논리적으로 정의된 테이블, 속성 등을 실제로 “하드디스크에 어떻게 저장할지” 정하는 단계야.
즉, DB 구조를 실제 파일과 인덱스, 저장 방식으로 성능을 고려해 설계하는 것!
✅ 물리적 설계에서 고려하는 것
| 저장 형식 | 데이터가 어떻게 저장될지, 레코드 구조 |
| 레코드 순서 | 데이터를 어떤 순서로 정렬할지 |
| 접근 경로 | 어떤 인덱스를 사용할지, 빠르게 찾는 법 |
| 성능 지표 | 응답시간, 트랜잭션 처리량, 디스크 사용량 등 |
❌ 왜 보기 ④가 틀렸을까?
"트랜잭션의 인터페이스를 설계하며, 데이터 타입 및 관계로 표현"
- 이건 논리적 설계(Logical Design) 단계에 가까운 설명이야
- 논리적 설계는 ER 다이어그램, 데이터 타입, 관계 등을 정의함
- 반면 물리적 설계는 저장, 인덱스, 구조 최적화를 다룸
📊 설계 단계별 비교표
| 개념 설계 | 사용자 요구 분석, 개체-관계 도식 (ERD) | 엔터티, 속성, 관계 |
| 논리 설계 | ER 모델을 관계형 모델로 변환 | 테이블, 데이터 타입, 제약조건 |
| ✅ 물리 설계 | 테이블을 실제 디스크에 저장할 구조로 최적화 | 레코드 구조, 인덱스, 저장 경로, 성능 |
✅ 정리
| ① 물리 설계는 데이터를 효율적으로 저장하는 것이 목적 | ✔ 맞음 | |
| ② 트랜잭션 처리량, 응답 시간, 디스크 용량 고려 | ✔ 맞음 | |
| ③ 저장 포맷, 순서, 접근 경로 등 설계 요소 포함 | ✔ 맞음 | |
| ④ 트랜잭션 인터페이스, 데이터 타입 관계 설계 | ❌ 논리 설계 내용 → 정답 |
✅ 결론
물리적 설계는 "저장 구조 최적화"가 핵심이며, 데이터 타입이나 트랜잭션 인터페이스는 논리 설계에 속한다.
57. 관계해석에서 모든것에대하여의 의미를 나타내는 논리기호는?
📊 논리 기호 정리표
| ∀ | 전칭 기호 (for all) | 모든 것에 대해 | "모든 학생은 20살 이상이다" | ∀x (학생(x) → 나이(x) ≥ 20) |
| ∃ | 존재 기호 (there exists) | 어떤 것이 존재한다 | "어떤 학생은 A학점을 받았다" | ∃x (학생(x) ∧ 학점(x) = 'A') |
| ¬ | 부정 기호 (not) | ~이 아니다 | "x는 학생이 아니다" | ¬학생(x) |
| ∧ | 논리곱 (and) | 그리고 | "학생이면서 성적이 A" | 학생(x) ∧ 성적(x) = 'A' |
| ∨ | 논리합 (or) | 또는 | "학생이거나 교수다" | 학생(x) ∨ 교수(x) |
| → | 조건 (if...then) | 이면 → 이다 | "학생이면 등록함" | 학생(x) → 등록(x) |
58. 다음 조건에 부합하는 SQL문을 작성하고자 할 때, SQL문의 빈칸에 들어갈 내용으로 옳은 것은?
조건 : 이름이 정도일인 팀원이 소속된 팀코드를 이용하여 해당 팀에 소속된 팀원들의 이름을 출력하는 SQL문 작성
SQL문 :
SELECT 이름
FROM 직원
WHERE 팀코드 = ( );
SELECT 팀코드 FROM 직원 WHERE 이름 = '정도일'
59. 데이터베이스에 영향을 주는 생성,읽기,갱신,삭제 연산으로 프로세스와 테이블 간에 매트릭스를 만들어서 트랜잭션을 분석하는 것은?
- CASE 분석
- 일치 분석
- CRUD 분석
- 연관성 분석
📊 보기별 비교표
| ✅ CRUD 분석 | 프로세스와 테이블 간의 생성, 읽기, 수정, 삭제 관계를 분석 | Create, Read, Update, Delete | 트랜잭션 흐름, DB 접근 분석 |
| ❌ CASE 분석 | Computer Aided Software Engineering의 약자로, 개발 자동화 도구 분석 | 설계 도구, 모델링 | 개발 도구 기능 분석 (X 분석기법 아님) |
| ❌ 일치 분석 | 특정 용어로 사용되지 않음, 보기용 오답 | - | ❌ |
| ❌ 연관성 분석 | 마케팅, 머신러닝 등에서 사용하는 기법 (A와 B가 함께 발생) | 장바구니 분석, 패턴 분석 | DB 트랜잭션 분석 아님 |
✅ CRUD 매트릭스란?
행(Row): 프로세스 (예: 화면, 기능, 트랜잭션)
열(Column): 데이터 테이블
값: C / R / U / D (생성/읽기/수정/삭제)
예:
| 회원가입 | C | ||
| 상품조회 | R | ||
| 주문수정 | U |
➡ 어떤 프로세스가 어떤 테이블에 어떤 영향을 주는지 한눈에 볼 수 있어.
✅ CRUD 분석이 왜 중요할까?
| ✅ 데이터 흐름 파악 | 어떤 기능이 어떤 테이블을 건드리는지 파악 가능 |
| ✅ 충돌 방지 | 동시에 수정되는 데이터 예측 가능 |
| ✅ 보안 설계 | 민감한 테이블은 어디서 접근되는지 확인 가능 |
| ✅ 유지보수 용이 | 특정 기능 수정 시 영향을 미칠 범위 분석 가능 |
✅ 정답 요약
| "생성/읽기/수정/삭제로 분석" | ✅ CRUD 분석 |
60. 데이터베이스에는 관계형,계층형,네트워크형 등 다양한 종류가 잇는데 이들을 구분하는 기준은?
- 개체(Object)
- 관계(Relationship)
- 속성(Attribute)
- 제약조건(Constraint)
🎯 문제 해설
데이터베이스를 관계형 / 계층형 / 네트워크형처럼 나누는 기준은 무엇일까?
이건 바로 데이터 간의 "관계를 어떻게 표현하느냐"에 따라 구분되기 때문에,
정답은 **관계(Relationship)**야.
🧠 왜 "관계"가 기준이 될까?
- 관계형 DB: 데이터를 **테이블(관계)**로 표현 (RDBMS, SQL 기반)
- 계층형 DB: 데이터를 **부모-자식 계층구조(Tree)**로 표현 (1:N 관계)
- 네트워크형 DB: 데이터를 그래프처럼 복잡하게(N:M 관계) 연결
➡ 따라서, **데이터 간 연결 방식(=관계)**이 핵심 기준이야!
📊 보기별 설명 비교표
| ✅ 관계(Relationship) | 데이터를 어떻게 연결하느냐(1:1, 1:N, N:M 등) | ✅ 정답 | 구조 구분 기준 |
| 개체(Object) | 데이터를 나타내는 단위 (ex. 고객, 주문) | ❌ | 모든 DB에 존재함 |
| 속성(Attribute) | 개체의 특성 (ex. 이름, 나이) | ❌ | 공통 요소 |
| 제약조건(Constraint) | 무결성 유지 위한 규칙 (ex. NOT NULL, FK) | ❌ | 설계 규칙일 뿐 구분 기준 아님 |
✅ 간단 구조 예시로 더 쉽게 이해하기
| 관계형 | 테이블 간 외래키 | 고객-주문 테이블 |
| 계층형 | 부모 → 자식 트리 구조 | 부서 → 직원 |
| 네트워크형 | 다중 부모-자식, 그래프형 | 부서 ↔ 직원 ↔ 프로젝트 (복잡 연결) |
✅ 결론
관계형 / 계층형 / 네트워크형 데이터베이스를 구분하는 기준은
➤ 데이터 간의 관계 표현 방식, 즉 **관계(Relationship)**이다.
'TIL' 카테고리의 다른 글
| 정보시스템 구축 관리 2024 1회 (0) | 2025.04.30 |
|---|---|
| 프로그래밍 언어 활용 - 2024 1회 (0) | 2025.04.30 |
| 소프트웨어 설계 2024 1회 (0) | 2025.04.30 |
| 소프트 웨어 개발 - 2024 1회 (0) | 2025.04.30 |
| 사전캠프 24일차 (1) | 2024.11.21 |