[자격증]/SQLD

[1과목] 데이터 모델과 SQL

에디터 윤슬 2025. 2. 26. 21:42

제1절 정규화

1. 속성 a, b, c, d, e로 구성된 릴레이션에서 아래와 같은 함수 종속성(Functional Dependency)이 존재할 때, 이 릴레이션의 후보 키로 가장 적절하지 않은 것은?

보기: ab -> cde, e -> b, d -> ab

  • d
  • ab
  • ac
  • ae
함수 종속성

1. 함수 종속성(Functional Dependency)
• 함수 종속성은 데이터베이스에서 한 속성이 다른 속성을 고유하게 결정하는 관계를 나타냅니다.
• 표기법: 
• : 결정자(Determinant), : 종속자(Dependent).
• 예: “학번 → 이름, 학과”는 학번이 이름과 학과를 고유하게 결정함을 의미합니다.

2. 후보 키(Candidate Key)
• 후보 키는 릴레이션(테이블) 내의 모든 튜플(행)을 고유하게 식별할 수 있는 속성 또는 속성들의 최소 집합입니다.
• 후보 키는 두 가지 조건을 만족해야 합니다:
1. 유일성: 후보 키는 모든 튜플을 고유하게 식별할 수 있어야 함.
2. 최소성: 후보 키는 중복된 속성을 포함하지 않아야 함.

 

2. 정규화와 성능에 대한 설명으로 가장 적절하지 않은 것은?

  • 정규화를 수행하면 중복 속성을 제거하여 용량을 최소화시킬 수 있다.
  • 일반적으로 정규화 수행 시 데이터 처리 성능이 향상된다.
  • 반정규화가 조회 성능을 항상 향상시키는 것은 아니며, 때로는 정규화에 의해 성능이 향상될 수도 있다.
  • 정규화를 수행하면 조회 성능을 보장받을 수 있다.
개념

1. 정규화의 정의
• 정규화는 데이터베이스 설계 과정에서 데이터 중복을 제거하고 데이터 무결성을 유지하기 위해 데이터를 체계적으로 구조화하는 과정입니다.
- 주요 목표:
• 데이터 중복 최소화.
• 데이터 무결성 보장.
• 데이터 이상(Anomaly) 방지.

2. 정규화의 장점
• 저장 공간 절약: 중복 데이터를 제거하여 데이터베이스 크기를 줄임.
• 데이터 무결성 강화: 데이터를 일관되게 유지하며, 삽입/삭제/갱신 이상을 방지.
• 유지보수 용이성: 데이터 구조가 체계적이므로 수정 및 관리가 쉬움.

3. 정규화와 성능
- 장점:
• 데이터 중복이 줄어들어 저장 공간이 절약되고, 데이터 이상이 방지됨.
• OLTP(온라인 트랜잭션 처리) 시스템에서 적합하며, 데이터 무결성이 중요한 경우 유리.
- 단점:
• 데이터를 여러 테이블로 분리하기 때문에, 조회 시 여러 테이블 간의 조인(Join) 연산이 필요함.
• 조인 연산이 많아질수록 쿼리 성능이 저하될 수 있음.
• 따라서 정규화가 항상 조회 성능을 보장하지는 않음.

각 문항에 대한 분석
1. “정규화를 수행하면 중복 속성을 제거하여 용량을 최소화시킬 수 있다.”
• 정규화는 데이터를 분리하여 중복을 제거하므로 저장 공간을 절약할 수 있습니다.

2. “일반적으로 정규화 수행 시 데이터 처리 성능이 향상된다.”
• 정규화를 통해 데이터가 체계적으로 구조화되면 삽입, 삭제, 갱신 작업에서 이상 현상이 줄어들고, 데이터 무결성이 강화됩니다.
• 하지만 이는 주로 OLTP 시스템에서 유효하며, 조회 성능 향상은 보장되지 않습니다.

3. “반정규화가 조회 성능을 항상 향상시키는 것은 아니며, 때로는 정규화에 의해 성능이 향상될 수도 있다.”
• 반정규화는 조회 성능을 높이는 데 효과적일 수 있지만, 항상 그렇지는 않습니다. 반대로 정규화를 통해 데이터 크기가 줄어들고 효율적인 인덱스를 사용할 경우 조회 성능이 향상될 수도 있습니다.

4. “정규화를 수행하면 조회 성능을 보장받을 수 있다.”
• 정규화를 수행하면 데이터 구조가 체계적이지만, 조회 시 조인 연산이 많아질 수 있어 성능 저하가 발생할 가능성이 있습니다.
• 따라서 정규화가 조회 성능을 보장한다고 단언할 수 없습니다.

  • 1. 제1정규형 (1NF: First Normal Form)
    • 조건: 모든 속성은 반드시 원자값(Atomic Value)을 가져야 함.
      • 각 셀에는 하나의 값만 포함되어야 하며, 배열이나 중첩된 데이터가 없어야 함.
      • 중복 그룹이 없어야 함.
      • 목적: 데이터를 단순화하여 중복된 열을 제거하고, 각 열이 고유한 값을 가지도록 함.
  • 2. 제2정규형 (2NF: Second Normal Form)
    • 조건:
      • 1NF를 만족해야 함.
      • 모든 비프라이머리 속성이 기본 키 전체에 완전 종속해야 함.
      • 부분 종속성(Partial Dependency)이 제거되어야 함.
      • 목적: 기본 키의 일부에만 종속된 속성을 제거하여 데이터 중복을 줄임.
  • 3. 제3정규형 (3NF: Third Normal Form)
    • 조건:
      • 2NF를 만족해야 함.
      • 비프라이머리 속성이 기본 키에만 직접 종속해야 함.
      • 이행적 종속(Transitive Dependency)이 제거되어야 함.
      • 목적: 비프라이머리 속성 간의 종속성을 제거하여 데이터 무결성을 강화함.
  • 4. 제4정규형 (4NF: Fourth Normal Form)
    • 조건:
      • 보이스-코드 정규형(BCNF)을 만족해야 함.
      • 다치 종속(Multi-Valued Dependency)이 제거되어야 함.
      • 목적: 다치 종속으로 인해 발생하는 중복 데이터를 제거함.
  • 5. 제5정규형 (5NF: Fifth Normal Form)
    • 조건:
      • 모든 조인 종속성(Join Dependency)이 후보 키에 의해 암묵적으로 유지되어야 함.
      • 목적: 조인으로 인해 발생할 수 있는 데이터 중복이나 불일치를 방지함.
  • BCNF의 정의
    • 릴레이션이 BCNF를 만족하려면, 모든 함수 종속성(Functional Dependency)에서 결정자(Determinant)가 반드시 후보 키(Candidate Key)여야 합니다.
    • 결정자(Determinant): 함수 종속성 에서 를 결정자라고 함.
    • 후보 키(Candidate Key): 릴레이션의 모든 속성을 유일하게 식별할 수 있는 속성 또는 속성들의 최소 집합.
      • BCNF와 제3정규형(3NF)의 차이
        • 제3정규형(3NF)은 비프라이머리 속성이 기본 키에만 직접 종속되도록 요구합니다.
        • 하지만, 제3정규형에서는 기본 키가 아닌 속성 간의 함수 종속성이 있을 경우에도 이상이 발생할 수 있습니다. BCNF는 이를 해결하기 위해 모든 결정자가 후보 키여야 한다는 조건을 추가합니다.

3. 아래와 같이 전제조건이 있을 때 테이블에서 나타날 수 있는 현상으로 가장 적절한 것은?

전제조건: 유형기능분류코드에 해당하는 속성들은 분포도가 양호하며, SQL WHERE절에서 각각의 값이 상수 값으로 조건 입력될 수 있는 특징을 가진다.

  • 조회 조건이 유형 기능 분류코드에 따라 반복되는 그룹이 칼럼단위로 되어 있으므로 제1정규형이라고 할 수 있다.
  • 유형기능분류코드에 대해 where절에 조건으로 들어오는 값이 있으므로 PK와 이에 대한 인덱스만 있으면 SQL 문장은 빠르게 수행될 수 있다고 할 수 있다.
  • 유형기능분류코드가 일반속성 안에서 반복적으로 속성이 구분되어 있기 때문에 이전종속을 수행해야 하는 제2정규형이라 할 수 있다.
  • 조회 성능을 위해 유형기능분류코드 각각에 대하여 개별로 인덱스를 모두 생성할 경우 입력, 수정, 삭제 때 성능이 저하되므로 제1차 정규화를 수행한 후 인덱스를 적용하는 것이 좋다.
해설

전제조건 분석
• 유형기능분류코드는 속성 값의 분포도가 양호하며, SQL `WHERE` 절에서 조건으로 자주 사용됨.
• 이는 유형기능분류코드가 데이터 조회 시 중요한 조건으로 사용된다는 것을 의미합니다.
• 하지만, 유형기능분류코드가 반복적인 그룹 형태로 칼럼 단위로 존재한다면 이는 제1정규형(1NF)을 만족하지 않는 상태입니다.

각 문항 분석
1. “조회 조건이 유형 기능 분류코드에 따라 반복되는 그룹이 칼럼단위로 되어 있으므로 제1정규형이라고 할 수 있다.”
• 잘못된 설명입니다.
• 제1정규형(1NF)의 조건은 모든 속성이 원자값(Atomic Value)을 가져야 한다는 것입니다.
• 유형기능분류코드가 반복되는 그룹 형태로 존재한다면 이는 제1정규형을 만족하지 않는 상태입니다.

2. “유형기능분류코드에 대해 where절에 조건으로 들어오는 값이 있으므로 PK와 이에 대한 인덱스만 있으면 SQL 문장은 빠르게 수행될 수 있다고 할 수 있다.”
• 부분적으로 맞는 설명이지만, 부적절합니다.
• PK와 인덱스만으로 성능이 항상 보장되는 것은 아닙니다. 특히, 유형기능분류코드가 반복적으로 존재하는 구조에서는 데이터 중복과 비효율적인 쿼리 처리가 발생할 수 있습니다.

3. “유형기능분류코드가 일반속성 안에서 반복적으로 속성이 구분되어 있기 때문에 이전종속을 수행해야 하는 제2정규형이라 할 수 있다.”
• 제2정규형(2NF)은 기본 키의 일부에만 종속된 부분 종속성을 제거하는 단계입니다.
• 하지만 문제에서 언급된 유형기능분류코드는 속성이 반복되고 있으며, 이는 제1정규형(1NF)을 만족하지 않는 상태입니다.

4. “조회 성능을 위해 유형기능분류코드 각각에 대하여 개별로 인덱스를 모두 생성할 경우 입력, 수정, 삭제 때 성능이 저하되므로 제1차 정규화를 수행한 후 인덱스를 적용하는 것이 좋다.”
• 유형기능분류코드가 반복되는 그룹 형태로 존재한다면 이는 제1정규형(1NF)을 만족하지 않는 상태입니다.
• 이를 해결하기 위해 제1정규화를 수행하여 데이터를 원자값으로 분리해야 합니다. 이후 적절한 인덱스를 생성하면 조회 성능을 개선할 수 있습니다.
• 또한, 과도한 인덱스 생성은 데이터 입력, 수정, 삭제 시 성능 저하를 초래할 수 있으므로 신중하게 적용해야 합니다.

정리
1. 유형기능분류코드는 반복되는 그룹 형태로 존재하므로 제1정규형(1NF)을 만족하지 않는 상태입니다.
2. 제1정규화를 통해 데이터를 원자값으로 분리한 후 적절히 인덱스를 생성해야 조회 성능과 데이터 무결성을 유지할 수 있습니다.

 

4. 아래에서 빈칸 ㄱ, ㄴ에 들어갈 용어로 가장 적절한 것은?

어떤 릴레이션 R이 ㄱ이고, 기본키에 속하지 않은 속성 모두가 기본키네 이행적 함수종속이 아닐 때 ㄴ에 속한다.

해설

1. “어떤 릴레이션 R이 ㄱ이고”
→ 이 부분은 릴레이션이 제2정규형 상태임을 의미합니다. 즉, 제1정규형을 만족하며, 기본 키의 부분 종속성(Partial Dependency)이 제거된 상태입니다.

2. “기본키에 속하지 않은 속성 모두가 기본키에 이행적 함수 종속이 아닐 때 ㄴ에 속한다.”
→ 이는 제3정규형의 정의를 설명하는 조건입니다. 즉, 기본 키 외의 속성들이 기본 키에만 직접적으로 종속되고, 다른 비프라이머리 속성에 종속되지 않을 때 제3정규형을 만족합니다.

 

5. 데이터 모델링의 정규화에 대한 설명으로 가장 적절하지 않은 것은?

  • 정규화는 개념 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 한다.
  • 제1정규형은 모든 인스턴스가 반드시 하나의 값을 가져야 함을 의미한다.
  • 제3정규형을 만족하는 엔터티의 일반속성은 주식별자 전체에 종속적이다.
  • 반정규화는 성능을 위해 데이터 중복을 허용하는 것이지만 성능의 향상을 항상 보장하는 것은 아니다.
해설

정규화와 데이터 모델링의 개념
정규화는 데이터베이스 설계에서 데이터 중복을 제거하고 무결성을 유지하기 위한 과정입니다. 이를 통해 데이터 이상(Anomaly)을 방지하고, 효율적인 데이터 처리가 가능하도록 구조를 개선합니다. 하지만 정규화는 개념 데이터 모델이 아니라 논리 데이터 모델 단계에서 수행됩니다.

각 문항 분석
1. “정규화는 개념 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 한다.”
• 정규화는 논리 데이터 모델 단계에서 수행되며, 개념 데이터 모델 단계에서는 엔터티와 속성 간의 관계를 정의하는 수준에 머뭅니다.
• 따라서 “개념 데이터 모델”이라는 표현은 부적절합니다.

2. “제1정규형은 모든 인스턴스가 반드시 하나의 값을 가져야 함을 의미한다.”
• 제1정규형(1NF)의 정의는 모든 속성이 원자값(Atomic Value)을 가져야 한다는 것입니다.
• 즉, 각 셀에는 하나의 값만 포함되어야 하며, 배열이나 중첩된 데이터가 없어야 합니다.

3. “제3정규형을 만족하는 엔터티의 일반속성은 주식별자 전체에 종속적이다.”
• 제3정규형(3NF)의 정의는 “모든 비프라이머리 속성이 기본 키에 직접적으로 종속되어야 한다”는 것입니다.
• 이는 이행적 종속(Transitive Dependency)을 제거하는 과정으로, 일반속성이 기본 키 전체에 종속된다는 설명은 제2정규형과 관련된 내용입니다.
• 하지만 이 문장은 제3정규형의 정의와도 일치하므로 적절합니다.

4. “반정규화는 성능을 위해 데이터 중복을 허용하는 것이지만 성능의 향상을 항상 보장하는 것은 아니다.”
• 반정규화는 조회 성능 향상을 위해 데이터를 중복 저장하거나 테이블을 병합하는 과정입니다.
• 하지만 반정규화가 항상 성능 향상을 보장하지 않으며, 삽입/갱신/삭제 시 성능 저하를 초래할 수 있습니다.

 

제2절 관계와 조인의 이해

6. 관계와 조인에 대한 설명으로 가장 적절하지 않은 것은?

  • 조인이란 식별자를 상속하고, 상속된 속성을 매핑키로 활용하여 데이터를 결합하는 것을 의미한다.
  • 부모의 식별자를 자식의 일반속성으로 상속하면 식별 관계, 부모의 식별자를 자식의 식별자에 포함하면 비식별 관계라고 할 수 있다.
  • 관계를 맺는다는 것은 식별자를 상속시키고 해당 식별자를 매핑키로 활용해 데이터를 결합해 보겠다는 것을 의미한다.
  • 'select b.고객명 from 주문 a, 고객 b where a.고객번호 = b.고객번호' 쿼리에서 조인키는 '고객번호'이다.
해설

1. 조인의 정의
• 조인(SQL JOIN)은 두 개 이상의 테이블을 공통된 열(주로 기본 키와 외래 키)을 기반으로 결합하여 데이터를 조회하는 작업입니다.
• 조인은 테이블 간의 관계를 활용하여 데이터를 결합하고, 결과적으로 여러 테이블에서 필요한 정보를 하나의 결과 집합으로 반환합니다.

2. 관계와 조인의 차이
• 관계는 데이터베이스 설계 시 테이블 간의 연결을 정의하는 개념입니다(예: 기본 키와 외래 키 관계).
• 조인은 이러한 관계를 활용하여 데이터를 실제로 결합하는 SQL 연산입니다.

각 문항 분석
1. “조인이란 식별자를 상속하고, 상속된 속성을 매핑키로 활용하여 데이터를 결합하는 것을 의미한다.”
• 조인은 테이블 간의 공통된 열(주로 외래 키와 기본 키)을 사용하여 데이터를 결합하는 작업입니다.
• “식별자를 상속하고, 상속된 속성을 매핑키로 활용”이라는 설명은 조인의 본질과 맞습니다.

2. “부모의 식별자를 자식의 일반속성으로 상속하면 식별 관계, 부모의 식별자를 자식의 식별자에 포함하면 비식별 관계라고 할 수 있다.”
• 식별 관계:
• 부모의 식별자가 자식의 식별자에 포함되는 경우를 의미합니다.
• 즉, 부모 테이블의 기본 키가 자식 테이블의 기본 키에 포함됩니다.
• 비식별 관계:
• 부모의 식별자가 자식의 일반 속성으로 상속되는 경우를 의미합니다.
• 즉, 부모 테이블의 기본 키가 자식 테이블에서 단순히 외래 키로 사용됩니다.

3. “관계를 맺는다는 것은 식별자를 상속시키고 해당 식별자를 매핑키로 활용해 데이터를 결합해 보겠다는 것을 의미한다.”
• 데이터베이스에서 관계를 맺는다는 것은 주로 기본 키와 외래 키를 통해 두 테이블 간 연결을 정의하는 것을 의미합니다.

4. ”‘select b.고객명 from 주문 a, 고객 b where a.고객번호 = b.고객번호’ 쿼리에서 조인키는 ‘고객번호’이다.”
• 이 쿼리는 “주문” 테이블과 “고객” 테이블을 `고객번호`라는 공통 열을 기준으로 조인하는 예제입니다.
• 여기서 `고객번호`는 두 테이블을 연결하는 조인키로 사용됩니다.

 

7. 아래에서 설명하는 정규형으로 가장 적절한 것은?

'엔터티의 일반속성은 주식별자 전체에 종속적이어야 한다.'

  • 제1정규형
  • 제2정규형
  • 제3정규형
  • 보이스-코드 정규형

 

제3절 모델이 표현하는 트랜잭션의 이해

8. 순차적으로 수행되는 작업 A와 B가 반드시 모두 수행되거나 모두 수행되지 않아야 한다고 할 때, 이에 대한 설명으로 사장 적절하지 않은 것은?

  • A와 B는 하나의 트랜잭션으로 묶여 처리되어야 한다.
  • A와 B를 수행한 후 각각 커밋(Commit)을 해주어야 한다.
  • A와 B에 주어진 조건은 트랜잭션의 원자성에 해당한다.
  • A까지만 수행되고 시스템 장애가 발생했다면 A를 undo해야 한다.
개념

트랜잭션(Transaction)
• 트랜잭션은 데이터베이스에서 하나의 논리적 작업 단위를 의미합니다.
• 여러 작업(A, B, C 등)이 하나의 트랜잭션으로 묶여 처리되면, 이 작업들은 모두 성공하거나 모두 실패해야 합니다.
• 트랜잭션은 데이터베이스의 일관성을 유지하기 위해 매우 중요한 개념입니다.

ACID 속성
트랜잭션이 안정적으로 수행되기 위해 만족해야 하는 4가지 속성:
1. 원자성 (Atomicity)
• 트랜잭션 내 모든 작업이 모두 성공하거나 모두 실패해야 함.
• 중간에 실패하면 이미 완료된 작업도 모두 취소(롤백)되어야 함.
• 예: 은행 계좌 이체에서 A 계좌에서 돈을 빼고(B 작업) B 계좌에 돈을 넣는 작업이 모두 수행되거나 모두 취소되어야 함.
2. 일관성 (Consistency)
• 트랜잭션이 실행되기 전과 후에 데이터베이스가 항상 일관된 상태를 유지해야 함.
• 예: 은행 계좌 이체 후에도 총 자산의 합계는 변하지 않아야 함.
3. 격리성 (Isolation)
• 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 독립적으로 실행되는 것처럼 보여야 함.
• 즉, 다른 트랜잭션의 중간 결과를 볼 수 없도록 해야 함.
• 예: 두 사용자가 동시에 같은 데이터를 수정하려고 할 때 충돌 방지.
4. 지속성 (Durability)
• 트랜잭션이 성공적으로 완료되면 그 결과는 시스템 장애가 발생하더라도 영구적으로 저장되어야 함.
• 예: 전원이 꺼져도 커밋된 데이터는 손실되지 않음.

문제와 관련된 핵심 속성: 원자성(Atomicity)
원자성의 핵심
• “모두 수행되거나 모두 수행되지 않아야 한다”는 조건은 원자성을 설명하는 것입니다.
• 한 트랜잭션 내에서 일부 작업만 완료되고 나머지가 실패하면, 이미 완료된 작업도 취소(롤백)되어야 합니다.

예시로 이해하기
은행 계좌 이체
1. A 계좌에서 100만 원 출금 (작업 A).
2. B 계좌에 100만 원 입금 (작업 B).
정상 처리:
• A와 B가 하나의 트랜잭션으로 묶여 처리되므로, 두 작업이 모두 성공하면 커밋(Commit)됩니다.
장애 발생:
• A 계좌에서 출금은 성공했지만, 시스템 장애로 인해 B 계좌에 입금이 실패한 경우:
• 원자성을 보장하기 위해 A 계좌에서 출금한 금액을 롤백(Undo)하여 이전 상태로 복구합니다.

문제와 관련된 개념 요약
1. 트랜잭션: 논리적인 작업 단위로, 모든 작업이 성공하거나 실패해야 함.
2. 원자성: 트랜잭션 내 작업들이 모두 수행되거나, 실패 시 모든 작업이 취소되어야 함.
3. 커밋(Commit): 트랜잭션이 성공적으로 완료되어 변경 사항을 영구적으로 저장하는 명령.
4. 롤백(Rollback): 트랜잭션 중 오류가 발생했을 때, 이미 수행된 작업을 취소하여 이전 상태로 복구하는 명령.

각 문항 분석
1. “A와 B는 하나의 트랜잭션으로 묶여 처리되어야 한다.”
• 원자성을 보장하기 위해 A와 B는 하나의 트랜잭션으로 묶여야 합니다.

2. “A와 B를 수행한 후 각각 커밋(Commit)을 해주어야 한다.”
• 하나의 트랜잭션 내에서는 단일 커밋만 허용됩니다. 각각 커밋하면 원자성이 깨질 수 있습니다.

3. “A와 B에 주어진 조건은 트랜잭션의 원자성에 해당한다.”
• “모두 수행되거나 모두 수행되지 않아야 한다”는 조건은 원자성을 설명하는 내용입니다.

4. “A까지만 수행되고 시스템 장애가 발생했다면 A를 undo해야 한다.”
• 원자성을 보장하기 위해 일부만 완료된 상태에서는 롤백(Undo)하여 이전 상태로 복구해야 합니다.

제4절 Null 속성의 이해

9. Null 값에 대한 설명으로 가장 적절한 것은?

  • Null 값에 어떤 숫자를 더해도 결과는 항상 Null이다.
  • Null 값과 어떤 숫자의 크기를 비교해도 결과는 항상 Null이다.
  • 'Null = Null' 연산의 결과는 True이다.
  • 집계 함수를 계산할 때 Null 값은 0으로 처리된다.
해설

Null 값의 개념
• Null은 데이터베이스에서 “값이 존재하지 않음”을 나타냅니다.
• Null은 0이나 빈 문자열과는 다르며, “알 수 없는 값” 또는 “정의되지 않은 값”으로 간주됩니다.
• Null과 관련된 연산은 일반적인 값과 다르게 동작합니다.

각 문항 분석
1. “Null 값에 어떤 숫자를 더해도 결과는 항상 Null이다.”
• Null은 “알 수 없는 값”이므로, Null에 어떤 값을 더하거나 곱해도 결과는 여전히 알 수 없습니다.
• 예: `NULL + 5`의 결과는 `NULL`입니다.

2. “Null 값과 어떤 숫자의 크기를 비교해도 결과는 항상 Null이다.”
• Null은 “알 수 없는 값”이므로, Null과 숫자 간의 크기 비교(`>`, `<`, `=` 등)는 항상 `NULL`을 반환합니다.
• 예: `NULL > 5`, `NULL = 5` 등의 결과는 모두 `NULL`입니다.

3. ”‘Null = Null’ 연산의 결과는 True이다.”
• SQL에서 `NULL = NULL`은 True가 아니라 NULL을 반환합니다.
• 두 Null 값은 서로 같다고 판단할 수 없기 때문입니다. 대신, Null 값을 비교하려면 `IS NULL` 또는 `IS NOT NULL`을 사용해야 합니다.

4. “집계 함수를 계산할 때 Null 값은 0으로 처리된다.”
• 집계 함수(예: `SUM`, `AVG`, `COUNT`)는 Null 값을 무시하지만, 이를 0으로 처리하지 않습니다.
• 예: 테이블에 값이 `{10, NULL, 20}`인 경우:
• `SUM`: 30 (Null 무시)
• `AVG`: 15 (Null 무시)
• `COUNT`: 2 (Null 무시)
• 따라서 Null 값을 0으로 처리한다는 설명은 부적절합니다.

제5절 본질식별자 vs 인조식별자

10. 본질식별자와 인조식별자에 대한 설명으로 가장 적절하지 않은 것은?

  • 인조식별자는 대체로 본질식별자가 복잡한 구성을 가질 때 만들어진다.
  • 인조식별자를 사용하면 중복 데이터를 막기 어려워진다.
  • 인조식별자를 사용하면 본질식별자를 사용할 때와 비교하여 추가적인 인덱스가 필요해진다.
  • 인조식별자는 개발 편의성을 높여주기 때문에 되도록 사용하는 것이 바람직하다.
해설

본질식별자(Natural Key)와 인조식별자(Surrogate Key)의 정의
1. 본질식별자 (Natural Key)
• 현실 세계에서 이미 존재하는 데이터 값으로 엔터티를 고유하게 식별하는 속성.
• 예: 주민등록번호, 이메일 주소, 차량 번호 등.
• 장점: 의미가 있는 데이터를 사용하므로 직관적이고 이해하기 쉬움.
• 단점: 값이 변경될 가능성이 있으며, 복잡한 구조일 경우 관리가 어려움.

2. 인조식별자 (Surrogate Key)
• 시스템에서 생성된 인공적인 키로, 데이터와 직접적인 의미가 없는 고유 식별자.
• 예: 자동 증가 ID, UUID 등.
• 장점: 단순하고 고정적이며, 데이터 변경 시에도 안정적으로 유지됨.
• 단점: 데이터 자체와 관련된 의미를 제공하지 않으며, 디버깅 시 어려움이 있을 수 있음.

각 문항 분석
1. “인조식별자는 대체로 본질식별자가 복잡한 구성을 가질 때 만들어진다.”
• 본질식별자가 여러 속성으로 이루어져 있거나, 값이 자주 변경되는 경우 인조식별자를 사용하는 것이 일반적입니다.
• 예: 복합 키(Composite Key)를 대체하기 위해 인조식별자를 생성하여 관리 용이성을 높임.

2. “인조식별자를 사용하면 중복 데이터를 막기 어려워진다.”
• 인조식별자는 고유한 값을 생성하므로 중복 데이터를 방지하는 데 유리합니다.
• 오히려 본질식별자는 값이 변경되거나 중복될 가능성이 있어 중복 방지에 취약할 수 있습니다.

3. “인조식별자를 사용하면 본질식별자를 사용할 때와 비교하여 추가적인 인덱스가 필요해진다.”
• 인조식별자를 사용하면 본질식별자와 별도로 고유 식별자를 생성해야 하므로 추가적인 인덱스가 필요할 수 있습니다.
• 이는 설계 및 성능 최적화를 위한 트레이드오프입니다.

4. “인조식별자는 개발 편의성을 높여주기 때문에 되도록 사용하는 것이 바람직하다.”
• 인조식별자는 특정 상황에서 유용하지만, 무조건 사용하는 것이 바람직하지는 않습니다.
• 예를 들어, 본질식별자가 간단하고 안정적인 경우 굳이 인조식별자를 사용할 필요가 없습니다.
• 또한, 인조식별자는 데이터의 의미를 제공하지 않으므로 디버깅 및 유지보수 시 불편함을 초래할 수 있습니다.