본문 바로가기
- 배움이 있는 삶/- 데이타베이스

2024년 기출문제 - 데이타베이스

by story of interesting 2025. 4. 9.
반응형

 

1. 관계 대수 (52번 문제)
2. 성능조인 기법(53번 문제)
3. 낙관적 locking / 비관적 locking (54번 문제)
4. 함수적종속관계 - 정규화 (57번 문제)
5. SQL VIEW 질의 변경( 63번 문제)
6. EER 모델링 개념(64번 문제)
7. 트리거와 프리시저 정의 및 특징 (65번 문제)
8. SQL  - Not In 연산과 Null 사용(70번 문제)
9. 확장성 해싱 - 전역변수, 지역변수(71번 문제)
10. B tree (73번 문제)
11.59번문제-인덱스저장:ROWID


- 25년 4월5일 국가직 9급 데이타베이스 총평 (여러번 듣기- 최신 기출)

https://www.youtube.com/watch?v=3FrXEfaI4NU

- 카디션 프로덕트 차수/ 카디널리티 계산 방법

1) 차수 : A+B (Attribute 를 더한다) 2+2 = 4
2) 카디널리티 : a 튜플 * b 튜플 ( 3*3=9)

 

좋은 질문이에요! 두 다이어그램 모두 1:N 관계를 나타내지만, 스키마 수가 반드시 같을 필요는 없습니다.
왜냐하면 스키마 수는 관계의 속성 유무관계 표현 방식에 따라 달라지기 때문이에요.


1. 첫 번째 다이어그램 (교수-지도-학생)

  • 관계(지도) 자체에 **속성(내용)**이 존재하기 때문에,
    관계 타입도 별도의 스키마로 생성되어야 해요.
  • 그래서 총 3개의 스키마가 필요:
    • 교수(교번, 이름)
    • 학생(학번, 이름)
    • 지도(교번, 학번, 내용)

2. 두 번째 다이어그램 (직원-부양가족)

  • 관계(Policy)에 **속성(cost)**이 있지만,
    → 이걸 따로 분리하지 않고 부양가족 테이블에 포함시킴으로써
    → 별도 관계 테이블 없이 2개의 스키마만으로 표현 가능:
    • Employees(ssn, name, lot)
    • Dependents(pname, age, cost, ssn)

이건 부양가족이 ssn(직원)과 pname(이름)으로 유일하다는 가정이 있어 가능한 방식이에요.


요약

  • 1:N 관계라고 해도, 관계에 속성이 있으면 보통 별도 스키마로 분리
  • 하지만 그 속성을 종속 엔터티 쪽에 포함시킬 수 있다면 스키마 수를 줄일 수 있음
  • 따라서 관계 속성의 존재 여부와 표현 방식에 따라 스키마 수는 달라져요

필요하면 ER → 릴레이션 변환 기준도 정리해드릴게요!

 


1. 52번 관계대수. Division. 확실히 공부 - 정답 : 2, (7임)

풀이) 1+ 6 = 7

1) R+ (파이 B(S)) = 1 임, R에 A는 2 만 남음

2) 자연조인으로 R의 카니널리티를 모두 가져옴 - 6

3) 세타조인으로 카디널리티는 5임

4) B=10 인 세타조인으로 카디널리티는 2임


2. 53번. 성능 조인기법

정렬합병. 각항목 스터티.

Nested join. Sort merge join. Hash join. 이걸 왜 설명했을까?

풀이)  내용 좀더 스터디 필요

문제내 오름차순 정렬되어 있는 경우 적용하는 방법 => 정렬 합병

https://www.youtube.com/watch?v=OiwjvEmiI4s

 


3. 54. 낙관적 락킹 / 비관적 락킹 locking - 병렬제어 locking 문제

- 낙관적 라킹 : 좀더 Free 하게 locking 하는 것. 마지막에 통으로 locking을 거는 것 으로 생각

- 비관적 라킹 : 엄격하게 locking을 거는 것, 암호화에는 유리하나, 성능에는 다소 떨어짐

- 낙관적 라킹 : 인터넷 등 비정형 상황에서 낙관적 라킹은 더 효율적임 (지문에서는 비관적 라킹이 효율적이라고 함)
: 그 이유는 

 

- 비관적 locking : undo / redo 불필요  / but commit 후 장애복구시 redo 필요할 수 있음

- 낙관적 locking : undo/ redo 필요 ( 충돌시 롤백시 undo / 커밋 복구시 redo)


57. 함수적 종속관계 - 정규화

- 여러번 풀었으나, 제대로 이해를 못하고 있음 - 반드시 이해해야 함

나의 문제풀이)

1) (A,B) -> D 이고 B->C 이면 => 이는 부분함수 종속관계 임 -> 이를 위해 (A,B,D) (C, D)로 구분해야 함

2) A->B->C->D 는 이행함수 종속 문제가 있음 => 이를 위해 2NF 문제임 , 이를 분해한것이 A->B->C 도 이행함수 종속관계임 이를 다수 분해해야 함 

3) A->C->D 도 이행함수 종속관계, 이를 구분해야 함.  A,B,C로 구분하는 것은 A->C 가 부분함수 종속관계 임으로 별도 구분해야 함, 따라서 (A,C) (B,C,D) 로 분할

4) 3번과 유사하게 C->A가 다시 부분함수 종속관계, 따라서 (A,C)는 별도로 구분 필요함, 이행함수종속관계도 없음 -> 따라서 BCNF 정규화 임 = 정답은 4번

 

- 2020년 기출정리 자료 다시 가져옴 (여러번 수강하여 완전히 이해해야 함)

: https://www.youtube.com/watch?v=-bLCtP2HNHo

- 함수적 종속관계

1) 완전 함수 종속
2) 부분 함수 종속 : PK가 2개 일때 발생함

- 결정자 (PK)가 2개인데, 2개로 성적이 결정되는 것은 => 완전함수적 종속 관계

- 결정자 중 1개인 학번으로만으로도 -> 학과가 결정됨 => 부분함수적 종속 관계라고 함

3) 이행적 함수 종속관계

A->B -> C 관계가 형성될때 이행적 함수종속 관계라고 함

이를 2개의 테이블로 구분해야 함 ;

1번) - A->B, B->C 로 구분 => 3 정규화 로 구분

2번) 아래 그림과 같은 경우 : (주문번호, 회원ID), (회원ID, 회원명, 회원등급) 으로 테이블을 쪼갠다. 

정규화 과정 => 테이블을 쪼개는 과정이다

- 왼쪽은 부분함수종속 / 오른쪽은 이행함수종속 관계로 테이블을 쪼개는 원칙임

 

- BCNF 정규형

아래와 같은 경우 BCNF 위배 - C는 결정자가 아닌데, B를 결정하는 결정자 역활을 하는 것은 잘 못된 설계임


- 다치 종속 : A-> B 에서 B 값이 여러개 나타날때, 아래 테이블은 다치종속이 발생한 테이블 

 

위 영상에 50분 시간대에 " 다치종속 " "조인종속"에 대한 설명이 잘되어 있음

- 조인종속 시 -> 위조튜플이 발생할 수 있음


5. SQL VIEW 질의 변경( 63번 문제)

정답) SELECT S.name
          FROM Students S, Enrolled E
          WHERE S.sid=E.sid AND E.grade=‘B’
                         AND E.cid=‘101’

풀이) 위의 "나"는 잘못된 sql 문임, 이를 해결한 것이 무엇인지에 대한 질문임

즉, student의 cid=101인 이름을 찾는 view 이기 때문에, select 문에서 S.name을 가져와야 하고, and 조건을 "E.cid = 101 인 사람을 찾는 것이 정답임.

https://www.youtube.com/watch?v=MxwGWiuN3H8



6. EER 모델링 개념(64번 문제)

 


7. 트리거와 프리시저 정의 및 특징 (65번 문제)

https://www.youtube.com/watch?v=Yeh_efIv1W8

https://www.youtube.com/watch?v=wVNX_BUbNp0

 

트리거(Trigger)

1) 트리거(Trigger) 의 정의

- 어떤 트랜잭션이 일어날때 자동으로 반응하여 다른 명령을 실행하는 기능임

2) 트리거의 장점/ 단점

-장점 : 데이타 무결성강화, 검사기능 확장, 사용자 편의성 제공, 효과적인 데이타 보관
-단점 : 유지보수가 어려움, 과도한 사용시 복잡성 증가, 대규모 DB관리가 어려움

구성

CREATE TRIGGER <트리거명>
    [BEFORE | AFTER] <이벤트>
    ON <테이블명>
    [FOR EACH ROW]
BEGIN
   <트리거 실행 코드> -- SQL 문
   [EXCEPTION]
      <예외 처리 코드> -- 예외 처리 (선택적)
END;

프로시저 (Stored Procedure)

1) 프로시저 정의

- 일련의 SQL 명령을 미리 저장해 놓고, 필요할때 한번의 호출로 실행 할 수 있는 SQL 명령 집합, 즉 일종의 프로그램 동작처럼 작동하며, 특정 작업을 반복 실행 할 수 있도록 함

구성

CREATE PROCEDURE <프로시저명> (
   [입력 파라미터]
)
IS
BEGIN
   -- 프로시저 내 SQL 문
   <SQL 문들>
   [EXCEPTION]
   <예외 처리 코드> -- 예외 처리 (선택적)
END <프로시저명>;

 

* 트리거는 자동으로 실행, 프로시저는 사용자 호출에 의해 수동으로 실행되는 차이점이 있다



8. SQL  - Not In (70번 문제)

(copilot 답변)

 

https://rkwhr0010.tistory.com/109

 

NOT IN 에서 NULL 사용 시 주의사항

SELECT * FROM DEPT WHERE DEPTNO IN (10,20,NULL) SELECT * FROM DEPT WHERE DEPTNO NOT IN (10,20,NULL); 결과가 하나도 안나왔다. 아마도 대부분의 사람들은 다음과 같은 기대값을 생각했을 것이다. IN은 근본적으로 OR연산

rkwhr0010.tistory.com

DEPTNO = 40 

NOT IN 테이블

(DEPTNO = 10 , DEPTNO = 20 , DETPNO = NULL) 

(FALSE, FALSE, NULL)

(FALSE, NULL)  

(NULL)   OR 연산 시 FALSE는 NULL과 연산 결과로 NULL을 반환한다. 

 

따라서 하나라도 TRUE가 있는 경우 NOT 결과로 FALSE를 반환한다.

전부 FALSE일 때는 NULL이 있어 NULL을 반환하기 때문에 아무 결과도 나오지 않게 된다.

IN 연산자 안에 NULL값이 들어가게 되면 TRUE를 리턴한 때는 정상동작하지만

FALSE의 경우 항상 NULL과의 연산에서 NULL을 리턴하게 되므로 

NOT IN 은 NULL이 하나라도 들어가면 모든 결과가 부정된다.



9. 확장성 해싱 - 전역변수, 지역변수(71번 문제) - 정답: 4

https://www.youtube.com/watch?v=NBRiGD0w-_E

 

- 전역깊이-

교재 설명에서는 key값이 7개 임으로, 전역깊이 2^2 으로 전역깊이를 계산한다고 설명되어 있음. 이렇게 계산할 수 있으나, 오류가 발생할 수 있음, 만약에 key 값이 버킷의 overflow 시키는 경우만 발생할 경우는 전역변수의 값이 바뀌게 된다. (그러나 그런 경우는 기출문제에서 못 봄)

- 여기서도 2^2 (7개인데, 2^3인 8 값을 필요로 하지 않기때문에, 전역깊이 = 2

-지역깊이-

위의 설명에 따라, 문제의 지역깊이를 구하면 

- 나 첫번째 의 경우 : 000이 공동으로 사용 - 지역깊이= 3이다

-나 두번째의 경우 - 001 한개가 할당됬으므로- 지역깊이 = 3이다

- 나 세번째의 경우 - "01"이 공동으로 사용됬음으로 - 지역깊이 = 2이다

- 나 네번째의 경우 - "1" 하나만 공동으로사용됬으므로 - 지역깊디 = 1 이다 

위의 개념인데, 문제에서는 모조키가 000010인 레코드를 삽입하는 경우

- 2^3 = 8인데 1개의 레코드가 추가 됨으로 -> 2^4가 되어야 한다 => 전역변수 ; 4

- 지역변수는 첫번째에서 overflow가 되기 때문에, 분할해야 한다. "000010" 이 추가되면, 

1번지역변수 : 0000 | 0000 분할 -> 2번 지역변수 : 0001|0001|0001  분할 => 헤더값이 각각 4가 된다

나머지 지역변수의 header값은 그대로 있는다

( 4+4+3+2+1 = 14가 지역변수이다)


10. B tree

풀이) 차수 3 으로 - 자식 노드는 최대 2개 key 소유, 중간값을 부모노드로 올린다, 부모노드는 자식노드의 가장 큰 값이며, 그렇기 때문에 중간값을 올릴때 분할이 일어남, 부모노드 보다 작은 값이 오른쪽으로 갈 수 없다

1)  17,20,5 로 중간값 17을 부모 노드로 올림 -> (17| ) -> (5 | 20)

2) 15 삽입시 -> 17 -> (5, 15), (20 | ) 노드 생성

3) 7 삽입시 -> 17->(5 | 7 | 15), (20 | ) 이는 분할이 일어남, 중간값인 7을 부모 노드로 올리고 분할 함,  7, 17 -> (5| ), (15| ), (20 | ) 로 구분됨

4) 18 삽입시 -> 7, 17 -> (5| ), (15| ), (20 | ) 에서 -> (7, 17)  -> (5| ), (15| ), (18| 20) 

5) 16 삽입시 -> (7 | 17)  -> (5 | ), (15 | 16 ), (18 | 20)

6) 19 삽입시 ->  (7 | 17)  -> (5 | ), (15 | 16 ), (18 | 20) -> (18 | 19 | 20) 의 중간값이 19가 부모노드로 -> (7 | 17 | 19) 로 중간값인 17이 부모 노드로 올라감

트리 레벨 1 : (17) -> 부모노드

트리레벨 2 : (7 | ), (19 | ) ->

트리레벨  3: (5 | ), (15 | 16 ), (18 | ), (20 | )   리프노드의 갯수는 4개가 된다 

 

(위 설명 영상이 존재함)

https://www.youtube.com/watch?v=3FJrVs3SM9Y

 

(B tree 기본 설명 영상)

https://www.youtube.com/watch?v=bqkcoSm_rCs

https://www.youtube.com/watch?v=Y11hGrKbilU


59번 문제 - 인덱스 저장 : ROWID : 정답 : 2번

관련 영상은 없음 - 아래는 GPT 답변임

 

  • SQL 실행 → 인덱스 검색 → ROWID 획득
  • ROWID 기반으로 데이터 블록 위치 파악
  • 버퍼 캐시에서 데이터 블록 확인 (없으면 디스크 I/O 수행)
  • 슬롯 번호를 이용해 테이블 블록에서 행 데이터 조회
  • 데이터 반환

- ROWID 란

ROWIDOracle과 같은 관계형 데이터베이스(RDBMS)에서 각 행(ROW)의 위치를 고유하게 식별하는 값이다.
즉, 특정 행이 저장된 물리적 위치(데이터 파일, 블록, 슬롯 번호)를 나타내는 주소라고 할 수 있다.

 

1. SQL 실행 및 인덱스 검색

  • 사용자가 특정 조건을 포함한 SQL 문을 실행하면 옵티마이저가 인덱스 스캔(Index Scan) 을 수행할지 결정한다.
  • 인덱스가 사용되면 검색 조건을 만족하는 ROWID를 가져온다.
  • ROWID는 데이터가 저장된 위치를 직접 가리키는 값으로, 다음과 같은 정보가 포함된다.
    • 데이터 파일 번호 (Datafile Number)
    • 블록 번호 (Block Number)
    • 슬롯 번호(ROW 번호) (Row Number)

2. 데이터 블록 접근

  • 인덱스에서 얻은 ROWID를 이용해 테이블의 데이터 블록을 읽기 위해 I/O 작업이 수행된다.
  • 데이터 파일 번호를 이용해 특정 데이터 파일을 찾는다.
  • 블록 번호를 이용해 해당 데이터 블록을 메모리(버퍼 캐시)로 가져온다.

3. 버퍼 캐시 확인

  • 데이터 블록이 이미 버퍼 캐시에 있는지 확인한다.
    • 있다면: 디스크 I/O 없이 바로 데이터를 가져옴 (빠름).
    • 없다면: 디스크에서 해당 블록을 읽어와 버퍼 캐시에 로드 (비교적 느림).

4. 테이블 블록 내의 행 검색

  • 데이터 블록이 메모리에 로드되면 **슬롯 번호(Row Number)**를 이용해 실제 데이터를 찾음.
  • 해당 행의 데이터를 읽어 결과를 반환.

5. 결과 반환

  • 찾은 데이터가 사용자에게 반환됨.
  • 다중 행 검색의 경우 위 과정이 반복되며, 필요한 경우 정렬(SORT), 조인(JOIN) 등의 추가 연산이 수행됨.

 

반응형