TIL

데이터베이스 구축 - 2024 1회

ds3hfj 2025. 4. 30. 10:51

41. 참조 무결성을 유지하기 위하여 DROP문에서 부모 테이블의 항목 값을 삭제할 경우 자동적으로 자식 테이블의 해당 레코드를 삭제하기 위한 옵션은?

  1. CLUSTER
  2. CASCADE
  3. SET-NULL
  4. RESTRICTED

보기별 비교표

옵션설명삭제 시 행동비고
CASCADE 부모가 삭제되면 자식도 자동 삭제 자식 레코드도 함께 삭제됨 참조 무결성 보장
SET NULL 부모 삭제 시 자식의 FK 값을 NULL로 변경 자식은 남고, 참조 컬럼만 NULL 자식 테이블이 FK에 NULL 허용해야 함
RESTRICTED (RESTRICT) 부모가 참조 중이면 삭제 금지 자식이 존재하면 삭제 불가 기본값 (안전성 높음)
CLUSTER 여러 테이블을 물리적으로 한 묶음으로 저장 삭제와는 무관 데이터 저장 구조 개념 (Oracle 등에서 사용됨)

 

 

 

42. 뷰(View)에 대한 설명으로 옳지 않은 것은

  1. 뷰는 CREATE 문을 사용하여 정의한다
  2. 뷰는 데이터의 논리적 독립성을 제공한다
  3. 뷰를 제거할 때에는 DROP 문을 사용한다
  4. 뷰는 저장장치 내에 물리적으로 존재한다

🎯 해설

✔ 뷰(View)란?

하나 이상의 테이블로부터 파생된 가상의 테이블로,
물리적으로 데이터를 저장하지 않고, SELECT 문 결과를 마치 테이블처럼 보여주는 객체야.


❌ 보기 ④ 왜 틀렸는가?

  • 뷰는 물리적으로 데이터를 저장하지 않는다
  • 대신, 실제 테이블을 기반으로 하는 SQL 질의 결과를 보여주는 논리적 객체
  • 즉, 가상의 테이블이기 때문에 실제 저장 공간을 차지하지 않음

👉 일부 DBMS에서 Materialized View (물리 뷰) 라는 특별한 형태는 데이터를 저장하지만,
일반적인 View는 저장 X


✅ 나머지 보기 설명

보기설명옳고 그름
CREATE 문을 사용하여 정의한다 CREATE VIEW view_name AS SELECT ... 사용 ✔ 옳음
데이터의 논리적 독립성을 제공한다 뷰를 통해 실제 테이블 구조를 감추고, 사용자에게 필요한 정보만 보여줄 수 있음 ✔ 옳음
DROP 문으로 제거할 수 있다 DROP VIEW view_name; 사용 ✔ 옳음
저장장치에 물리적으로 존재한다 ❌ 뷰는 가상 테이블, 물리 저장 X 정답

📊 테이블 vs 뷰 비교표

항목테이블 (Table)뷰 (View)
저장 공간 ✅ 실제 데이터 저장 ❌ 데이터 저장 안 함
생성 방법 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 트랜잭션 처리

🎯 예시 보기에서 고르는 팁

보기포함 명령어DML 여부
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. 관계대수의 순수 관계 연산자가 아닌 것은?

  1. Select
  2. Cartesiam Product
  3. Division
  4. 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)값이 아닌 원자 값을 갖는 성질은

  1. 개체 무결성
  2. 참조 무결성
  3. 도메인 무결성
  4. 튜플의 유일성
보기 설명 맞는지 여부
개체 무결성(Entity Integrity) 기본키는 null이 될 수 없고, **하나의 고유한 값(원자값)**만 가져야 함 ✔️ 정답
참조 무결성(Referential Integrity) 외래키(FK)는 참조하는 기본키(PK)가 존재해야 함
도메인 무결성(Domain Integrity) 각 컬럼의 데이터 타입, 허용값(예: 날짜만, 1~100만 가능 등)을 지켜야 함
튜플의 유일성 각 행(레코드)은 중복되면 안 됨 → 기본키 역할과 관련 있음

 

 

46. 제 3정규형에서 보이스코드 정규형(BCNF)으로 정규화 하기 위한 작업은?

  1. 원자 값이 아닌 도메인을 분해
  2. 부분 함수 종속 제거
  3. 이행 함수 종속 제거
  4. 결정자가 후보키가 아닌 함수 종속 제거

✅ 정규화란?

데이터베이스에서 중복을 제거하고,
**데이터 이상(삽입/삭제/갱신 이상)**을 방지하기 위해
테이블을 논리적으로 쪼개는 과정


🎯 정규화 단계 요약표

정규형제거 대상핵심 조건예시 개념목적
1NF
(제1정규형)
반복 속성, 원자값 아님 모든 속성은 **원자값(단일 값)**이어야 함 주소 = “서울, 부산” ❌ 테이블을 구조적으로 정리
2NF
(제2정규형)
부분 함수 종속 기본키가 복합키일 경우, 일부 키에만 종속된 속성 제거 (학번, 과목) → 교수명 ❌ 키 전체에만 의존해야 함
3NF
(제3정규형)
이행 함수 종속 A → B → C 같은 간접 종속 제거 학번 → 과, 과 → 과장 ❌ 중간 단계 제거
BCNF
(보이스-코드 정규형)
후보키가 아닌 결정자 모든 결정자후보키여야 함 과목 → 교수 (과목이 후보키 아님!) ❌ 3NF보다 더 엄격한 키 조건

🔧 주요 용어 간단 정의

용어뜻
부분 함수 종속 복합키의 일부 속성만으로 결정되는 종속
이행 함수 종속 A → B, B → C가 있을 때 A → C 간접 종속
결정자 값을 결정하는 속성 (A → B에서 A가 결정자)
후보키 기본키가 될 수 있는 후보들 중 하나

📘 예시 흐름 (학생 테이블 예)

초기 테이블:

scss
복사편집
학생(학번, 이름, 과목, 교수명)

1NF: 원자값으로 정리

 
❌ 과목 = "수학, 영어" → 나눔 ✅ (학번, 과목) 기준으로 각각 나눔

2NF: 부분 종속 제거

 
(학번, 과목) → 교수명 ❌ → 과목-교수 테이블로 분리

3NF: 이행 종속 제거

 
학번 → 학과, 학과 → 학장 ❌ → 학과-학장 테이블로 분리

BCNF: 후보키가 아닌 결정자 제거

 
과목 → 교수명 ❌ (과목은 후보키 아님) → 과목-교수 테이블로 분리

✅ 시각적 정리

 
초기 테이블
↓ (1NF) 원자값으로 정리
↓ (2NF) 부분 종속 제거
↓ (3NF) 이행 종속 제거
↓ (BCNF) 결정자가 후보키가 아닌 경우 분해

 


✅ 마무리 요약

정규형핵심 제거 대상결과
1NF 비원자값, 반복 속성 칼럼 정리
2NF 부분 함수 종속 속성 분리
3NF 이행 함수 종속 간접 종속 제거
BCNF 후보키가 아닌 결정자 강한 함수 종속 제거

47. 로킹(Locking)기법에 대한 설명으로 틀린 것은

  1. 로킹의 대상이 되는 객체의 크기를 로킹 단위라고 한다
  2. 로킹 단위가 작아지면 병행성 수준이 낮아진다
  3. 데이터베이스도 로킹 단위가 될 수 있다
  4. 로킹 단위가 커지면 로크 수가 작아 로킹 오버헤드가 감소한다

먼저, 로킹(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. 다음에서 설명하는 스키마는?

  • 데이터베이스 전체를 정의한 것으로 데이터개체,관계,제약조건,접근권한, 무결성 규칙 등을 명세한것
  1. 개념 스키마
  2. 내부 스키마
  3. 외부 스키마
  4. 내용 스키마

🧠 스키마(Schema)란?

데이터베이스의 구조, 제약 조건, 구성요소들을 정의한 청사진(설계도)
쉽게 말해: 데이터를 어떤 방식으로 저장하고, 연결하고, 관리할지 정의한 것


✅ DB 3계층 스키마 구조 (ANSI-SPARC 모델)

구분이름설명누가 보는가
외부 스키마 External Schema 사용자/응용프로그램 관점의 데이터 구조
→ 개인화된 "뷰(View)"
사용자
개념 스키마 Conceptual Schema 데이터베이스 전체를 논리적으로 정의
모든 테이블, 관계, 제약 조건 등
DB 관리자, 설계자
내부 스키마 Internal Schema 실제로 데이터가 저장되는 물리적 구조 정의
(저장 방법, 인덱스 등)
DBMS, 시스템

📊 스키마 종류 요약표

스키마계층설명예시
외부 스키마 1층 사용자별로 보는 데이터 뷰 특정 사용자는 이름, 이메일만 조회
개념 스키마 2층 DB 전체 구조/제약 정의 테이블 구조, FK, PK, 제약 조건 등
내부 스키마 3층 물리적 저장 방식 인덱스, 페이지 저장 방식, 파일 구조

🎯 보기 정리

보기설명정답 여부
개념 스키마 데이터베이스 전체 구조/관계/제약 등을 정의 ✅ 정답
내부 스키마 물리적 저장 구조
외부 스키마 사용자 맞춤 뷰
내용 스키마 ❌ 존재하지 않는 용어 (오답 유도용)

✅ 결론 요약

데이터베이스 전체 구조 및 제약을 논리적으로 정의한 스키마는?
➤ 정답: ✅ 개념 스키마

 

 

50. 시스템 카탈로그에 대한 설명으로 틀린 것은?

  1. 시스템 카탈로그의 갱신은 무결성 유지를 위하여 SQL을 이요하여 사용자가 직접 갱신하여야 한다
  2. 데이터베이스에 포함되는 데이터 객체에 대한 정의나 명세에 대한 정보를 유지관리한다
  3. DBMS가 스스로 생성하고 유지하는 데이터베이스 내의 특별한 테이블의 집합체이다
  4. 카탈로그에 저장된 정보를 메타 데이터라고 한다

🧠 시스템 카탈로그(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. 병행제어 기법의 종류가 아닌 것은?

  1. 로킹 기법
  2. 시분할 기법
  3. 타임 스탬프 기법
  4. 다중 버전 기법

✅ 병행제어(Concurrency Control)란?

여러 사용자가 동시에 데이터베이스에 접근해도
데이터의 일관성과 무결성을 유지하도록 순서를 제어하는 기술


🧠 병행제어 기법의 대표적인 종류

기법 이름설명병행제어 여부
로킹 기법 데이터를 잠가서 동시에 수정하지 못하게 함
타임스탬프 기법 각 트랜잭션에 시간표시를 부여하여 순서 제어
다중 버전 기법 (MVCC) 데이터의 버전을 나누어 읽기/쓰기 충돌을 줄임
시분할 기법 운영체제의 CPU 스케줄링 기법 (병행제어 X) 정답

📘 보기 해설

보기설명병행제어 여부
로깅 기법 ❌ 회복 기법(복구용 로그 기록) → 병행제어 X
시분할 기법 ❌ 운영체제 용어 (시간을 나눠 CPU 공유) 정답
타임스탬프 기법 ✅ 병행제어용 시간 기반 순서 제어
다중 버전 기법 ✅ 읽기/쓰기 충돌 최소화 (MVCC)

📊 병행제어 vs 회복 기법 비교표

분류이름설명예시
병행제어 로킹, 타임스탬프, 다중버전 동시에 접근하는 트랜잭션들 간 충돌 방지 은행 입출금 중복 방지
회복 기법 로깅, 체크포인트, 트랜잭션 롤백 장애 발생 시 DB 복구 시스템 다운 후 복원

✅ 한 줄 요약

병행제어 기법은 동시성 문제를 해결하기 위한 방법이고,
보기 중 시분할 기법은 운영체제 개념으로 병행제어와 무관하다.

 

 

53. 데이터 속성 간의 종속성에 대한 엄밀한 고려없이 잘못 설계된 데이터베이스에서는 데이터 처리 연산 수행 시 각종 이상현상이 발생할 수 있는데, 이러한 이상 현상이 아닌 것은?

  1. 검색 이상
  2. 삽입 이상
  3. 삭제 이상
  4. 갱신 이상

먼저, 이상현상(Anomaly)이란?

정규화가 제대로 안 된 테이블에서
데이터를 **삽입(insert), 삭제(delete), 수정(update)**할 때
**원하지 않는 부작용(데이터 손실, 중복 등)**이 발생하는 현상


📌 대표적인 이상현상 3가지

이상 종류설명예시
삽입 이상 (Insertion Anomaly) 일부 데이터만 추가하고 싶어도 불필요한 다른 데이터도 강제로 입력해야 함 학생을 추가하려는데 아직 수강 과목이 없어서 못 넣음
삭제 이상 (Deletion Anomaly) 한 정보만 삭제했는데 원하지 않는 다른 정보까지 같이 사라짐 어떤 과목 삭제했더니 학생 정보도 함께 삭제됨
갱신 이상 (Update Anomaly) 동일한 정보가 여러 곳에 중복돼 있어, 일일이 다 수정 안 하면 불일치 발생 한 교수 이름을 바꿨는데 다른 테이블엔 그대로 남아있음

❌ 보기 중 틀린 것: 검색 이상

보기설명이상현상인가?
검색 이상 ❌ 정규화 개념에서 사용되지 않는 용어 정답
삽입 이상 ✅ 강제로 다른 열까지 넣어야 하는 문제 ✔️
삭제 이상 ✅ 일부 삭제가 전체 삭제로 이어지는 문제 ✔️
갱신 이상 ✅ 중복 데이터로 인해 수정 누락 발생 ✔️

✅ 결론

정답: 검색 이상
→ 검색 이상은 정규화에서 말하는 공식적인 이상현상(Anomaly)이 아님!

54. 트랜잭션의 주요 특성 중 하나로, 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없음을 의미하는 것은?

  1. Log
  2. Consistency
  3. Isolation
  4. Durability

✅ 트랜잭션(Transaction)이란?

데이터베이스에서 하나의 작업 단위
즉, 논리적으로 반드시 함께 수행되어야 하는 작업의 묶음


📌 왜 트랜잭션이 필요할까?

예시: 은행 이체

text
복사편집
A 계좌 → B 계좌로 10만원 이체하려면 ① A 계좌에서 10만원 출금 ② B 계좌에 10만원 입금

👉 이 두 작업은 무조건 같이 성공하거나, 둘 다 안 돼야 해!

  • A에서 돈 빠졌는데 B에 입금 안 되면? → ❌ 데이터 불일치 발생!

➡ 그래서 ①②를 하나의 트랜잭션으로 묶어서 처리


✅ 트랜잭션의 대표적 특징: ACID

약자이름의미
A Atomicity (원자성) 모두 성공 or 모두 실패 (쪼갤 수 없음)
C Consistency (일관성) 트랜잭션 전후 데이터가 항상 정합성 유지
I Isolation (고립성) 다른 트랜잭션과 간섭 없이 독립적으로 실행
D Durability (지속성) 트랜잭션 완료 결과는 영구 저장됨 (전원 꺼져도 보존)

🛠️ 트랜잭션이 실제로 사용되는 예

상황트랜잭션 예
은행 이체 출금 + 입금
쇼핑몰 주문 재고 차감 + 주문 생성 + 포인트 차감
회원가입 계정 생성 + 기본 설정 + 인증 메일 발송

✅ 한 줄 요약

트랜잭션은 데이터베이스에서 "절대 함께 실행돼야 하는 작업 묶음"이야.
중간에 끊기면 안 되고, 모두 성공하거나 모두 실패해야 해.

 

 

55. 관계형 데이터베이스에서 다음 설명에 해당하는 키는?

한 릴레이션 내의 속성들의 집합으로 구성된 키로서, 릴레이션을 구성하는 모든 튜플에 대한 유일성은 만족시키지만 최소성은 만족시키지 못한다

  1. 후보키
  2. 대체키
  3. 슈퍼키
  4. 외래키

📊 키 종류별 비교표

키 종류정의예시조건 만족
슈퍼키(Super Key) 튜플을 유일하게 식별할 수 있는 속성 집합 (학번), (학번+이름), (주민번호+전화) 등 ✔ 유일성
❌ 최소성
후보키(Candidate Key) 유일성 + 최소성 만족하는 최소 슈퍼키 (학번), (주민번호) 등 ✔ 유일성
✔ 최소성
기본키(Primary Key) 후보키 중 대표로 선택된 키 (학번) ✔ 유일성
✔ 최소성
대체키(Alternate Key) 후보키 중 기본키가 아닌 나머지 키 주민번호 (기본키가 학번일 경우) ✔ 유일성
✔ 최소성
외래키(Foreign Key) 다른 테이블의 기본키를 참조하는 키 주문 테이블의 고객번호 (→ 고객 테이블 참조) ❌ 유일성
❌ 최소성

 

 

56. 물리적 데이터베이스 설계에 대한 설명으로 거리가 먼 것은?

  1. 물리적 설계의 목적은 효율적인 방법으로 데이터를 저장하는 것이다
  2. 트랜잭션 처리량과 응답시간,디스크용량 등을 고려해야 한다
  3. 저장 레코드의 형식,순서,접근 경로와 같은 정보를 사용하여 설계한다
  4. 트랜잭션의 인터페이스를 설계하며, 데이터 타입 및 데이터 타입들 간의 관계로 표현한다

🧠 물리적 설계(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. 데이터베이스에 영향을 주는 생성,읽기,갱신,삭제 연산으로 프로세스와 테이블 간에 매트릭스를 만들어서 트랜잭션을 분석하는 것은?

  1. CASE 분석
  2. 일치 분석
  3. CRUD 분석
  4. 연관성 분석

📊 보기별 비교표

분석 기법설명키워드사용 목적
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. 데이터베이스에는 관계형,계층형,네트워크형 등 다양한 종류가 잇는데 이들을 구분하는 기준은?

  1. 개체(Object)
  2. 관계(Relationship)
  3. 속성(Attribute)
  4. 제약조건(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) 설계 규칙일 뿐 구분 기준 아님

✅ 간단 구조 예시로 더 쉽게 이해하기

DB 유형관계 표현 방식예시
관계형 테이블 간 외래키 고객-주문 테이블
계층형 부모 → 자식 트리 구조 부서 → 직원
네트워크형 다중 부모-자식, 그래프형 부서 ↔ 직원 ↔ 프로젝트 (복잡 연결)

✅ 결론

관계형 / 계층형 / 네트워크형 데이터베이스를 구분하는 기준은
데이터 간의 관계 표현 방식, 즉 **관계(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