본문 바로가기
배워야 산다

문항별 관련 주제_12~22

by 인라인타지마 2025. 8. 25.

문항12 (MSA 서비스 설계 방법) 관련 학습 내용, 예상 문제 및 해설

첨부된 PDF 파일 내 문항12는 특정 마이크로 서비스 설계 방법을 설명하고, 해당 방법을 보기에서 고르는 문제입니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용:
    • 서비스들이 메시지/이벤트를 주고받음
    • 별도의 조정자 없음 (⬅️ 핵심 특징)
    • Local Transaction 성공/실패 시 이벤트 발행 (실패 시 보상 트랜잭션 이벤트) (⬅️ 핵심 특징)
    • 서비스 간 결합도 낮음, 역할 집중 가능 (장점)
    • 서비스 간 순환 종속성, 프로세스 분산으로 이해 어려움 (단점) 위 특징들을 가진 마이크로 서비스 설계 방법을 보기에서 고르는 문제입니다.
  • 해설: SAGA 패턴의 Choreography 설계에 대한 설명이라고 명시합니다.
  • 출제 영역: 프로세스 모델링 – 설계 > MSA 서비스 설계 (⬅️ 문제와 직접 관련)
  • 출제 의도: SAGA 패턴의 이해와 하위단계의 이해 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 마이크로 서비스 아키텍처(MSA) 환경에서 분산 트랜잭션을 관리하는 SAGA 패턴의 두 가지 방식 중 하나인 Choreography 방식에 대한 이해를 평가하는 것에 초점을 맞추고 있습니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. MSA 서비스 설계 (⬅️ 문제와 직접 관련)

  • 개념: 단일 기능을 수행하는 작고 독립적인 서비스들로 시스템을 구축하는 아키텍처 스타일입니다.
  • 핵심 원칙: 서비스 분해, 서비스 데이터 소유권, 독립적인 배포, 느슨한 결합 등.
  • 주요 과제: 분산 시스템 복잡성, 서비스 간 통신, 분산 트랜잭션 관리, 데이터 일관성 유지 등.

3. 분산 트랜잭션 관리 (⬅️ 문제와 직접 관련)

  • 필요성: MSA에서는 각 서비스가 독립적인 데이터베이스를 가지므로 (서비스 데이터 소유권), 여러 서비스에 걸친 비즈니스 작업(예: 주문 -> 재고 감소 -> 결제)의 원자성(모두 성공 또는 모두 실패)을 보장하기 위한 메커니즘이 필요합니다.
  • SAGA 패턴: (⬅️ 문제의 핵심 주제) 분산 트랜잭션을 관리하는 패턴 중 하나입니다. 전체 비즈니스 트랜잭션을 여러 서비스의 로컬 트랜잭션 시퀀스로 구성하고, 실패 시 보상 트랜잭션을 통해 롤백합니다.
    • 보상 트랜잭션 (Compensating Transaction): SAGA 패턴의 핵심 메커니즘으로, 실패 발생 시 이미 완료된 이전 단계의 로컬 트랜잭션을 취소하기 위한 역작업을 수행합니다.

4. SAGA 패턴의 두 가지 방식 (⬅️ 문제의 핵심 출제 포인트)

SAGA 패턴은 전체 트랜잭션의 흐름을 어떻게 관리하는지에 따라 두 가지 방식으로 나뉩니다.

  • Orchestration 방식:
    • 개념: 중앙의 **SAGA 오케스트레이터(Orchestrator)**가 존재하여 SAGA의 모든 단계와 보상 로직을 직접 관리하고 지시합니다. 오케스트레이터가 각 서비스에게 특정 작업을 수행하도록 명령하고, 결과에 따라 다음 단계를 진행하거나 보상 트랜잭션을 지시합니다.
    • 특징: 전체 SAGA 흐름이 오케스트레이터에 중앙 집중화되어 있습니다.
    • 장점: 전체 흐름 파악 용이, 관리 용이성.
    • 단점: 오케스트레이터가 단일 실패 지점 가능성, 서비스의 오케스트레이터 의존성 증가.
  • Choreography 방식: (⬅️ 문제에서 설명하는 방식)
    • 개념: 중앙 조정자 없이 각 서비스가 **이벤트(Event)**를 발행하고, 해당 이벤트에 관심 있는 다른 서비스들이 이벤트를 **구독(Subscribe)**하여 다음 단계를 자율적으로 수행합니다. 트랜잭션 로직은 각 서비스에 분산됩니다.
    • 특징: "별도의 조정자 없음", "서비스들이 메시지/이벤트를 주고받는 방식" (⬅️ 문제 설명과 일치), "Local Transaction 성공/실패 시 이벤트를 발행" (⬅️ 문제 설명과 일치).
    • 장점: 서비스 간 결합도 낮음, 중앙 실패 지점 없음.
    • 단점: 전체 SAGA 흐름 파악 어려움, 관리 복잡성 증가, 서비스 간 순환 종속성 가능성. (⬅️ 문제 설명과 일치)

5. MSA 서비스 간 통신 (Choreography 관련)

  • 비동기 통신 (Asynchronous Communication): Choreography 방식은 서비스 간의 자율적인 이벤트 기반 통신을 사용하므로 주로 비동기 통신으로 구현됩니다. 메시지 큐나 이벤트 브로커를 통해 메시지/이벤트를 발행하고 구독하는 방식입니다.

6. 문제 해결 전략 (문항12)

문항12와 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 문제 설명의 핵심 특징 식별: 제시된 설명에서 가장 두드러지는 특징, 특히 "별도의 조정자 없음"과 "이벤트 발행"을 파악합니다.
  2. SAGA 패턴 방식과 특징 비교: 학습한 SAGA Orchestration 방식과 Choreography 방식의 특징과 장단점을 떠올립니다.
  3. 일치하는 방식 선택: 식별된 특징("별도의 조정자 없음", "이벤트 기반")과 가장 정확하게 일치하는 SAGA 패턴 방식을 보기에서 선택합니다.

7. 예상 문제 3개 (MSA 서비스 설계 - SAGA/CQRS)

문항12와 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 1) 마이크로 서비스 아키텍처(MSA) 환경에서 분산 트랜잭션을 관리하는 SAGA 패턴의 핵심 구성 요소 중 하나로, SAGA 시퀀스 중 어느 단계에서 로컬 트랜잭션이 실패할 경우, 이미 성공한 이전 단계의 로컬 트랜잭션에 의해 변경된 상태를 되돌리기 위해 실행되는 특별한 트랜잭션을 무엇이라고 합니까? [3점]

답: ____________________ 트랜잭션

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: SAGA 패턴 핵심 구성 요소 (롤백)
  • 출제 의도: SAGA 패턴의 보상 트랜잭션 개념 이해도 검증

해설: SAGA 패턴에서 실패 시 롤백을 위해 실행되는 역작업 트랜잭션을 보상 트랜잭션(Compensating Transaction)이라고 합니다.

예상 문제 2) SAGA 패턴의 두 가지 방식 중, 중앙의 SAGA 오케스트레이터(Orchestrator)가 전체 SAGA의 로직을 알고 각 서비스에게 수행할 작업을 명령하며 트랜잭션 흐름을 관리하는 방식을 무엇이라고 합니까? [3점]

답: ____________________ 방식

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: SAGA 패턴 방식 (중앙 조정 기반)
  • 출제 의도: SAGA 패턴의 Orchestration 방식 개념 이해도 검증

해설: SAGA 패턴에서 중앙의 Orchestrator가 전체 흐름을 관리하는 방식을 Orchestration 방식이라고 합니다.

예상 문제 3) CQRS(Command Query Responsibility Segregation) 패턴에 대한 설명으로 가장 적절한 것은? [4점] ① 여러 서비스에 걸친 분산 트랜잭션을 관리하기 위한 패턴이다. ② 시스템의 모든 기능을 단일 서비스로 통합하여 관리한다. ③ 데이터 변경(Command) 작업과 데이터 조회(Query) 작업을 분리하여 최적화한다. ④ 서비스 간 통신 시 항상 동기적인 요청/응답 방식을 사용하도록 강제한다. ⑤ 각 서비스가 데이터베이스를 공유하여 데이터 일관성을 쉽게 유지한다.

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: CQRS 패턴 개념 이해도 검증
  • 출제 의도: CQRS 패턴의 핵심 설계 원칙 및 목적 이해도 검증 (파일 문항13 관련)

해설: CQRS 패턴은 데이터 변경(Command)과 데이터 조회(Query)를 분리하여 각 작업의 요구사항에 맞춰 모델 및 저장소를 최적화하는 패턴입니다. ①은 SAGA 패턴, ②는 모놀리식 또는 통합 서비스, ④는 통신 방식 제약 없음, ⑤는 MSA의 서비스 데이터 소유권 원칙 위배입니다.

 

 

문항13 (수강신청 시스템 구성) 관련 학습 내용, 예상 문제 및 해설

첨부된 PDF 파일 내 문항13은 S 대학교 수강신청 시스템의 요구사항 및 설계 방안 시나리오를 제시하고, 빈칸 (가)에 들어갈 아키텍처 패턴의 명칭을 쓰는 문제입니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: S 대학교 수강신청 시스템의 효율성 및 부하 관리 개선을 위해 새로운 아키텍처 도입을 결정한 시나리오입니다.
    • 매 학기 수강 신청 기간에 수천 명 동시 접속, 과목 등록 -> 대량의 부하 발생
    • 데이터 처리와 조회의 분리를 통해 성능 최적화 -> 핵심 설계 방향
    • 대량 업데이트 발생 시에도 수강 신청 현황은 원활하게 조회되어야 함 -> 쓰기 부하에도 읽기 성능 유지 중요
    • (가) 패턴 적용 계획, (가) 패턴을 통해 '데이터 처리'와 '데이터 조회' 분리 -> (가) 패턴의 역할 명시
    • '데이터 처리' 모델: 입력, 수정, 삭제 트랜잭션 처리
    • '데이터 조회' 모델: 최신 상태 정보 제공 (이벤트 큐 동기화) 위 시나리오 및 설계 방안에 해당하는 패턴 명칭을 빈칸 (가)에 쓰는 문제입니다.
  • 해설: 빈칸 (가)에 CQRS 또는 Command and Query Responsibility Segregation가 들어간다고 명시합니다.
  • 출제 영역: 프로세스 모델링 – 설계 > MSA 서비스 설계 (⬅️ 문제와 직접 관련)
  • 출제 의도: CQRS 의 이해 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 시스템 아키텍처 패턴 중 하나인 CQRS(Command Query Responsibility Segregation) 패턴에 대한 이해를 평가하며, 특히 대규모 부하 상황에서 데이터 처리(쓰기)와 조회(읽기)를 분리하여 성능을 최적화하는 CQRS의 핵심 개념과 목적을 아는지를 묻고 있습니다. 출제 영역이 'MSA 서비스 설계'로 되어 있으나, CQRS 패턴은 MSA 환경에서 유용하게 사용될 수 있는 패턴이지 CQRS 자체가 MSA의 필수 구성 요소는 아닙니다. 다만, MSA 환경에서 서비스별 데이터 소유권으로 인해 데이터 분산 및 일관성 문제가 발생하므로, CQRS를 통해 읽기/쓰기를 분리하고 비동기 통신(이벤트 큐)으로 일관성을 맞추는 설계가 MSA와 잘 어울립니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 시스템 아키텍처 패턴 (⬅️ CQRS의 상위 개념)

  • 개념: 소프트웨어 시스템을 구조화하는 데 사용되는 일반적이고 재사용 가능한 해결책입니다. 시스템의 전체적인 구성 요소와 그 관계를 정의합니다.
  • 종류: 계층형 아키텍처, 클라이언트-서버 아키텍처, 모델-뷰-컨트롤러(MVC), 서비스 지향 아키텍처(SOA), 마이크로 서비스 아키텍처(MSA), 이벤트 기반 아키텍처(EDA) 등 다양한 패턴이 있습니다. CQRS는 이러한 아키텍처 패턴 중 하나 또는 다른 패턴(예: MSA, EDA) 내에서 사용될 수 있는 패턴입니다.

3. CQRS (Command Query Responsibility Segregation) 패턴 상세 학습 (⬅️ 문제의 핵심 주제)

  • 개념: 시스템의 기능을 데이터 변경(쓰기)을 수행하는 Command 작업과 데이터 조회(읽기)를 수행하는 Query 작업으로 분리하고, 각 작업에 대해 별도의 모델(객체 모델)과 데이터 저장소를 가질 수 있도록 설계하는 패턴입니다. CQRS = Command (쓰기) + Query (읽기) + Responsibility Segregation (책임 분리)
  • Command (쓰기): 데이터 변경(입력, 수정, 삭제)을 요청하는 작업입니다. Command 모델은 비즈니스 로직 적용, 유효성 검증, 트랜잭션 처리에 집중하며, 데이터 무결성을 보장하는 데 초점을 맞춥니다.
  • Query (읽기): 데이터를 조회하는 작업입니다. Query 모델은 데이터 조회에 최적화되어 있으며, 빠른 응답 속도와 다양한 형태의 조회 지원에 초점을 맞춥니다. 복잡한 조인이나 집계 없이 읽기 전용 데이터 구조를 사용하기도 합니다.
  • Responsibility Segregation (책임 분리): Command 작업과 Query 작업의 책임(모델, 저장소 등)을 분리한다는 의미입니다.
  • 목적 및 필요성:
    • 읽기/쓰기 부하 불균형 해소: 수강 신청 시스템처럼 쓰기 부하(등록, 변경, 삭제)와 읽기 부하(현황 조회)의 패턴이나 규모가 매우 다를 때 효과적입니다.
    • 성능 및 확장성 최적화: 쓰기 모델과 읽기 모델을 독립적으로 설계하고 확장할 수 있어 각 작업의 성능 요구사항에 맞춰 최적화가 용이합니다. 읽기 모델은 대규모 조회 트래픽 처리에, 쓰기 모델은 데이터 무결성 및 트랜잭션 처리에 특화시킬 수 있습니다. (⬅️ 수강신청 시나리오의 '효율성 및 부하 관리 개선', '성능 최적화', '원활하게 조회' 요구와 연결)
    • 유연한 조회 대응: 복잡하거나 다양한 형태의 조회 요구사항에 맞춰 읽기 모델 스키마를 자유롭게 변경할 수 있습니다.
    • 관심사 분리: 쓰기 로직과 읽기 로직이 분리되어 코드 및 모델의 복잡성을 관리하기 용이합니다.
  • 구현:
    • 모델 분리: Command 작업용 모델과 Query 작업용 모델을 별도로 설계합니다.
    • 저장소 분리: Command 모델 데이터 저장소와 Query 모델 데이터 저장소를 분리하여 사용할 수 있습니다. 다른 종류의 데이터베이스(RDBMS, NoSQL 등)를 사용할 수도 있습니다. (⬅️ 문제 설계 방안의 '데이터 처리 모델', '데이터 조회 모델' 및 '각 용도에 맞게 설정'과 연결)
    • 데이터 동기화: Command 모델에서 발생한 데이터 변경 사항을 Query 모델에 반영하여 데이터를 동기화해야 합니다. 보통 이벤트 기반의 비동기 방식을 사용합니다. (⬅️ 문제 설계 방안의 '이벤트 큐를 통해 동기화'와 연결) Command 모델이 데이터 변경 후 이벤트를 발행하고, 이벤트 핸들러가 이 이벤트를 받아 Query 모델의 데이터를 업데이트합니다.
    • 데이터 일관성: 비동기 동기화 방식 사용 시, 데이터 최종 일관성(Eventual Consistency)이 발생할 수 있습니다. 쓰기 완료 후 조회 시 최신 데이터가 아닐 수 있습니다.

4. MSA 서비스 설계 (CQRS 패턴의 활용)

  • CQRS 패턴은 MSA 환경에서 서비스별 데이터 소유권 원칙을 따르면서도 복잡한 읽기/쓰기 요구사항을 효과적으로 처리하기 위한 패턴으로 유용하게 사용될 수 있습니다. 각 마이크로 서비스 내부에 CQRS 패턴을 적용하거나, 여러 서비스에 걸쳐 CQRS 패턴을 확장하여 적용할 수 있습니다.

5. 문제 해결 전략 (문항13)

문항13과 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 시나리오의 핵심 문제점 파악: 수강 신청 시스템의 '대규모 동시 접속', '대량 업데이트 중 원활한 조회 필요'와 같은 문제 상황을 파악합니다. 이는 쓰기 부하가 심할 때 읽기 성능 유지가 어렵다는 문제임을 인지합니다.
  2. 제시된 설계 방안의 핵심 내용 파악: 문제 해결을 위해 제시된 설계 방안 중 "데이터 처리'와 '데이터 조회'를 분리"하고, "각 모델을 각 용도에 맞게 설정"하며, "이벤트 큐를 통해 동기화"한다는 내용을 파악합니다.
  3. 핵심 개념과 아키텍처 패턴 연결: 데이터 처리(쓰기)와 데이터 조회(읽기)를 분리하여 성능을 최적화하는 아키텍처 패턴이 무엇인지 학습 내용을 떠올립니다. 이는 CQRS 패턴의 정의와 정확히 일치합니다.
  4. 빈칸에 들어갈 용어 작성: 파악된 패턴 명칭인 CQRS를 빈칸 (가)에 작성합니다.

6. 예상 문제 3개 (MSA 서비스 설계 - CQRS)

문항13과 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 1) CQRS(Command Query Responsibility Segregation) 패턴에서 데이터 쓰기(Command) 모델과 데이터 읽기(Query) 모델을 분리하는 주된 목적 두 가지를 서술하시오. [4점]

답: 목적 1: ____________________, 목적 2: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: CQRS 패턴 분리 목적 서술
  • 출제 의도: CQRS 패턴의 핵심 목적 이해도 검증

해설: CQRS 패턴은 쓰기와 읽기의 요구사항(부하, 복잡성 등)이 다를 때, 각 작업의 특성에 맞춰 모델 및 데이터 저장소를 독립적으로 설계하고 최적화하여 성능을 향상시키고 확장성을 확보하기 위해 사용됩니다.

  • 목적 1: 데이터 쓰기(Command)와 읽기(Query) 작업의 요구사항에 맞춰 모델 및 데이터 저장소를 독립적으로 최적화하고 확장하기 위해
  • 목적 2: 읽기 성능 향상 및 다양한 조회 요구사항에 유연하게 대응하기 위해

예상 문제 2) CQRS 패턴에서 데이터 쓰기(Command) 모델의 변경 사항을 데이터 읽기(Query) 모델에 반영하여 데이터를 동기화할 때, 가장 일반적으로 사용되는 방식은 무엇입니까? [3점] ① 실시간 동기 통신 ② 배치 처리를 통한 주기적 동기화 ③ 이벤트 기반의 비동기 동기화 ④ 2PC (Two-Phase Commit)를 통한 동기화

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: CQRS 데이터 동기화 방식
  • 출제 의도: CQRS 패턴에서 사용되는 데이터 동기화 메커니즘 이해도 검증

해설: CQRS 패턴에서는 쓰기 모델의 변경 사항이 이벤트로 발행되고, 이벤트 핸들러가 이 이벤트를 받아 읽기 모델을 업데이트하는 이벤트 기반의 비동기 동기화 방식이 가장 일반적으로 사용됩니다. 이는 시스템의 유연성과 확장성을 높이지만 최종 일관성을 고려해야 합니다.

예상 문제 3) CQRS 패턴에서 데이터 쓰기(Command) 모델과 데이터 읽기(Query) 모델을 분리하여 얻는 주요 이점 중, 특히 대규모 조회 트래픽 발생 시 효과적인 이점 한 가지를 서술하시오. [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 프로세스 모델링 - 설계 > MSA 서비스 설계
  • 문제 제목: CQRS 패턴 장점 (대규모 조회) 서술
  • 출제 의도: CQRS 패턴의 주요 이점 중 읽기 성능 및 확장성 관련 내용 이해도 검증

해설: CQRS 패턴은 읽기 모델을 읽기 작업에 최적화하고 독립적으로 확장할 수 있게 함으로써, 대규모 조회 트래픽 발생 시에도 빠른 응답 속도를 유지하고 부하를 효율적으로 분산하는 데 매우 효과적입니다.

  • 정답: 읽기 모델을 독립적으로 확장하고 읽기 작업에 최적화하여 대규모 조회 트래픽 발생 시에도 빠른 응답 속도를 유지할 수 있다. (또는 유사 내용 서술)

 

 

 

문항14 (회원 테이블 수직 분할) 관련 학습 내용, 예상 문제 및 해설

본 문서는 첨부된 PDF 파일 내 문항14("A기관 포털의 회원 테이블 수직 분할")와 관련하여 학습하여야 할 주제 및 내용을 상세히 정리하고, 해당 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: A기관의 대용량 회원 테이블을 시스템 성능 문제를 고려하여 물리 데이터 모델 설계 단계에서 여러 테이블로 수직 분할하여 분리했습니다. **[데이터 모델]**에 제시된 수직 분할 결과(원본 파일에 포함된 분할된 테이블 스키마)를 보고, 수직 분할에 대한 설명 중 적절하지 않은 것을 고르는 문제입니다.
  • 해설: 원본 파일에서 문항14의 해설은 "회원과 회원등급의 분리는 1차 정규화가 아닌 업무적 성능을 고려한 수직분할임."이라고 명시합니다. 이를 통해 보기 중 하나가 수직 분할을 1차 정규화와 혼동했거나, 수직 분할의 목적(성능 고려)과 다른 설명을 하고 있음을 알 수 있습니다.
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 물리데이터 모델링 (⬅️ 문제와 직접 관련)
  • 출제 의도: 수직분할에 대한 전반적인 사유를 이해하는지 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 데이터 모델링 분야 중 물리 데이터 모델링 단계에서 대용량 데이터의 성능 향상을 위해 적용하는 데이터 분할 기법, 특히 **수직 분할(Vertical Partitioning)**에 대한 이해를 평가하며, 수직 분할을 수행하는 **주된 사유(목적)**와 그 특징을 정확히 아는지를 묻고 있습니다. 또한, 제시된 데이터 모델(수직 분할 결과)을 보고 설명의 적절성을 판단하는 능력도 요구됩니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 데이터 모델링 단계

  • 개념: 현실 세계의 업무를 데이터 관점에서 추상화하여 데이터 구조를 설계하는 과정입니다.
  • 주요 단계: 개념 모델링, 논리 모델링, 물리 데이터 모델링 (⬅️ 문항14의 대상 단계)
    • 물리 데이터 모델링: (⬅️ 문항14 출제 영역) 논리 모델을 특정 데이터베이스 관리 시스템(DBMS)의 특성, 성능, 저장 공간 등을 고려하여 실제 데이터베이스에 구축 가능한 테이블, 컬럼, 인덱스, 제약 조건 등으로 변환하는 단계입니다. 성능 고려가 이 단계에서 매우 중요하게 다루어집니다. (⬅️ 문제 언급 내용)

3. 데이터베이스 성능 관리 및 튜닝

  • 개념: 데이터베이스 시스템이 요구되는 응답 시간과 처리량을 만족하도록 관리하고 개선하는 활동입니다.
  • 성능 저하 원인: 대용량 데이터, 비효율적인 쿼리, 부적절한 스키마 설계, 하드웨어 제약 등.
  • 성능 향상 기법: 쿼리 튜닝, 인덱스 활용, 데이터 분할(Partitioning), 캐싱 적용 등. 데이터 분할은 대용량 테이블의 성능 문제를 해결하는 중요한 기법 중 하나입니다. (⬅️ 문제 언급 내용)

4. 데이터 분할 (Partitioning) (⬅️ 문항14의 핵심 주제)

  • 개념: 대용량의 테이블이나 인덱스를 더 작고 관리하기 쉬운 여러 개의 물리적인 단위(파티션)로 분할하는 기법입니다.
  • 주요 목적:
    • 성능 향상: 특정 데이터 접근 시 전체 테이블이 아닌 필요한 파티션만 스캔하여 I/O 및 검색 범위를 줄입니다.
    • 관리 용이성: 대규모 데이터 관리 작업(백업, 복원, 아카이빙, 삭제)을 파티션 단위로 수행하여 효율성을 높입니다.
    • 가용성 증대: 특정 파티션에 문제가 발생해도 다른 파티션은 사용 가능할 수 있습니다.
  • 종류:
    • 수평 분할 (Horizontal Partitioning): (⬅️ 수직 분할과 비교하며 이해) 테이블의 **행(Row)**을 특정 기준(예: 날짜, 지역, 범위)에 따라 여러 파티션으로 나눕니다. 각 파티션은 원래 테이블과 동일한 스키마를 가집니다. 특정 기준에 대한 범위 검색이나 삭제에 유리합니다.
    • 수직 분할 (Vertical Partitioning): (⬅️ 문항14의 핵심 기법) 테이블의 **컬럼(Column)**을 두 개 이상의 그룹으로 나누어 별도의 테이블로 저장합니다. 분할된 각 테이블은 원래 테이블의 기본 키(Primary Key)를 포함하여 서로 연결됩니다. 주로 자주 접근되는 컬럼 그룹과 드물게 접근되는 컬럼 그룹으로 분리합니다.
      • 주된 사유 (목적): 조회 성능 향상 (⬅️ 문항14 출제 의도 및 문제 언급). 자주 접근되는 컬럼들만 읽어서 디스크 I/O 양을 줄이고, 메모리 캐싱 효율을 높입니다.
      • 예시: 문항14의 회원 테이블 분할처럼, 회원 정보 중 자주 조회되는 기본 정보(이름, ID 등)와 가끔 조회되는 상세 정보(주소, 연락처 등), 또는 대용량 바이너리 데이터(사진 이미지) 등을 분리하는 것입니다.
      • 장점:
        • I/O 감소: 자주 사용하는 컬럼만 읽으므로 디스크 I/O가 줄어듭니다.
        • 캐싱 효율 증가: 작은 크기의 테이블이 메모리 캐시에 더 많이 적재될 수 있습니다.
        • 넓은 테이블의 단점 완화: 컬럼이 많은 테이블의 단점(많은 스캔 범위)을 개선합니다.
      • 단점:
        • 조인(JOIN) 필요: 원래 하나의 테이블이었던 데이터를 함께 조회하려면 분할된 테이블 간의 조인이 필요하여 추가적인 비용이 발생할 수 있습니다. (⬅️ 주의해야 할 단점)
        • 입력/수정 복잡성: 한 행의 데이터가 여러 테이블에 분산되므로 데이터 입력 또는 수정 시 여러 테이블을 조작해야 할 수 있습니다.

5. 정규화 (Normalization) 및 반정규화 (Denormalization)와의 관계

  • 정규화: 데이터 중복 제거, 무결성 강화, 이상 현상 방지를 위한 논리 모델링 과정입니다. 수직 분할은 정규화 과정(특히 제2, 3정규화)에서 발생하는 테이블 분리와 유사한 형태를 가질 수 있으나, 수직 분할은 성능을 주된 목적으로 하는 물리 모델링 기법이라는 점에서 차이가 있습니다. 문항14 해설이 "회원과 회원등급의 분리는 1차 정규화가 아닌 업무적 성능을 고려한 수직분할임"이라고 명시한 것은 이 둘을 혼동하지 말라는 중요한 지침입니다. (⬅️ 문제 해설에 명시)
  • 반정규화: 정규화된 모델에서 성능 향상을 위해 의도적으로 중복을 허용하거나 테이블을 통합하는 기법입니다. 수직 분할은 때때로 반정규화 기법의 일종으로 간주되기도 하지만, 엄밀히 말해 정규화로 분리되지 않은 컬럼들을 성능 목적으로 나누는 것이 수직 분할의 핵심입니다.

6. 문제 해결 전략 (문항14)

문항14와 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 문제 상황 이해: 대용량 회원 테이블을 성능 문제로 수직 분할했다는 핵심 내용을 파악합니다.
  2. [데이터 모델] 분석: (원본 파일의 이미지 참조 필요) 분할 전 원본 테이블의 컬럼 구성과 분할 후 여러 테이블로 나뉜 결과를 확인합니다. 어떤 컬럼들이 함께 묶여 분할되었는지 파악합니다.
  3. 수직 분할의 목적 및 특징 떠올리기: 학습한 수직 분할의 주된 사유(성능 향상), 방법(컬럼 그룹 분리), 장점, 단점(조인 필요성 등)을 떠올립니다. 정규화와의 차이점도 함께 고려합니다.
  4. 보기의 설명 분석: 각 보기가 수직 분할에 대해 설명하는 내용을 하나씩 읽습니다.
  5. 설명의 적절성 판단: 각 보기가 수직 분할의 목적, 방법, 장단점에 대해 올바르게 설명하고 있는지 판단합니다. 특히 수직 분할의 주된 목적인 '조회 성능 향상'과 이로 인해 발생할 수 있는 '조인 비용 증가' 등의 단점, 그리고 정규화와의 차이점을 중심으로 판단합니다. (⬅️ 해설과 출제 의도에 명시된 판단 기준)
  6. 적절하지 않은 설명 선택: 판단 결과, 수직 분할에 대해 잘못 설명하고 있거나 수직 분할의 사유/특징과 관련 없는 설명을 하고 있는 보기를 선택합니다.

7. 예상 문제 3개 (데이터 모델링 - 분할)

문항14와 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 14-1) 대용량 테이블의 데이터를 관리하고 조회하는 성능을 향상시키기 위해, 테이블의 **컬럼(Column)**을 두 개 이상의 그룹으로 나누어 별도의 테이블로 저장하는 기법을 무엇이라고 합니까? [3점]

답: ____________________ 분할

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 데이터 모델링 - 물리 데이터 모델링
  • 문제 제목: 테이블 컬럼 분할 명칭
  • 출제 의도: 데이터 분할 기법 중 수직 분할 개념 이해도 검증

해설: 테이블의 컬럼을 그룹으로 나누어 별도의 테이블로 저장하는 기법은 수직 분할(Vertical Partitioning)입니다.

예상 문제 14-2) 아래는 대용량 테이블에 데이터 분할 기법을 적용할 때 발생하는 장점 또는 단점에 대한 설명입니다. 수평 분할(Horizontal Partitioning)을 적용할 때 발생할 수 있는 주된 장점으로 가장 적절한 것은? [4점] ① 자주 사용되는 컬럼만 읽어서 I/O 효율성을 높일 수 있다. ② 원래 하나의 테이블이었던 데이터 조회 시 조인 비용이 감소한다. ③ 특정 범위 또는 기준에 해당하는 데이터 검색 및 관리가 용이해진다. ④ 데이터 중복이 완벽하게 제거되어 저장 공간을 절약할 수 있다.

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 물리 데이터 모델링
  • 문제 제목: 테이블 수평 분할 장점
  • 출제 의도: 수평 분할의 주된 목적 및 장점 이해도 검증 (수직 분할과 비교하며)

해설: 수평 분할은 테이블의 행을 나누므로, 특정 범위(예: 특정 기간의 데이터)에 대한 검색이나 삭제와 같은 관리가 해당 파티션에서만 이루어져 효율적입니다. ①은 수직 분할의 장점, ②는 수직 분할의 단점(조인 필요)과 반대되는 설명이며, ③ 특정 범위/기준 데이터 관리가 용이해지는 것이 수평 분할의 주된 장점입니다. ④ 데이터 중복 제거는 정규화의 목적입니다.

예상 문제 14-3) 어떤 테이블을 수직 분할(Vertical Partitioning)하기로 결정했습니다. 분할 전에는 한 번의 테이블 스캔으로 필요한 모든 컬럼을 읽을 수 있었지만, 분할 후에는 데이터를 함께 조회하기 위해 조인이 필요하게 되었습니다. 이로 인해 성능 관점에서 발생할 수 있는 문제점 한 가지를 서술하시오. [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 물리 데이터 모델링
  • 문제 제목: 테이블 수직 분할 단점 (조인 비용)
  • 출제 의도: 수직 분할로 인한 조인 필요성 및 그 성능 영향 이해도 검증

해설: 수직 분할 후 데이터를 함께 조회하려면 조인 연산이 필수적입니다. 이 조인 연산은 추가적인 CPU 사용량, 메모리 사용량, I/O 발생 등 비용을 발생시켜, 특정 조회 작업의 성능을 오히려 저하시킬 수도 있습니다.

  • 정답: 분할된 테이블을 함께 조회하기 위해 조인 연산이 필요하며, 이로 인해 추가적인 처리 비용이 발생하여 성능 저하를 유발할 수 있다. (또는 유사 내용 서술)

 

문항15, 16 (커뮤니티회원 데이터 모델) 관련 학습 내용 상세 정리

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용 (공통 지문): B사 커뮤니티 서비스의 [커뮤니티회원 데이터] 샘플을 제시하고, 이 데이터 모델이 관리상 문제점과 효율적인 데이터 처리 어려움을 겪고 있다고 설명합니다. 주어진 데이터와 문제점 설명을 바탕으로, 데이터 모델 설계 설명의 빈칸 가) (문항15)와 나) (문항16)에 들어갈 내용을 작성합니다. 문제점 설명은 데이터 중복, 그로 인한 갱신/삭제 이상 현상 발생 가능성을 언급하고, 특정 속성이 '주식별자 중 하나'에만 종속되는 **Partial Dependency(부분 종속성)**가 문제의 원인임을 명시하며, 이를 제거하기 위해 '나)차 정규화'를 수행했다고 기술합니다.
  • 해설 (문항15 - 가)): '회원ID'가 들어간다고 명시합니다. '회원명'과 '회원전화번호'가 '회원ID'와 '회원명, 회원전화번호' 간에 존재하는 부분 종속성을 제거하여 2차 정규화를 수행했음을 설명합니다.
  • 해설 (문항16 - 나)): '2'가 들어간다고 명시합니다. '회원명'과 '회원전화번호'가 '회원ID'와 '회원명, 회원전화번호' 간에 존재하는 부분 종속성을 제거하여 2차 정규화를 수행했음을 설명합니다.
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링 (⬅️ 문제와 직접 관련)
  • 출제 의도: 2 차 정규화의 개념을 이해하는지 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 두 문제는 데이터 모델링 분야 중 논리 데이터 모델링 단계의 핵심 과정인 **정규화(Normalization)**에 대한 이해를 평가하며, 특히 정규화의 필요성 (데이터 중복 및 이상 현상), 함수 종속성 (부분 함수 종속), 그리고 **제2 정규형(2NF)**의 개념을 정확히 아는지에 초점을 맞추고 있습니다. 주어진 데이터 샘플과 문제점 설명을 통해 이상 현상 발생 원인(부분 종속성)을 파악하고, 이를 해결하기 위한 정규화 단계(제2 정규형)와 관련 용어(부분 종속성을 유발하는 속성)를 정확히 매핑하는 능력을 요구합니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 데이터 모델링

  • 개념: 현실 세계의 데이터를 추상화하여 데이터 구조를 설계하는 과정입니다. 개념 모델링, 논리 데이터 모델링, 물리 데이터 모델링 단계를 거칩니다.
  • 논리 데이터 모델링: (⬅️ 문항15, 16 출제 영역) 특정 데이터베이스 시스템에 독립적으로 데이터 구조를 모델링하는 단계입니다. 데이터 중복 제거, 데이터 구조 논리적 조직화, 데이터 무결성 확보를 위한 정규화 과정이 이 단계에서 수행됩니다.

3. 정규화 (Normalization) (⬅️ 문항15, 16의 핵심 주제)

  • 개념: 관계형 데이터베이스 설계에서 데이터 중복을 제거하고 데이터의 일관성 및 무결성을 강화하며, **이상 현상(Anomaly)**을 방지하기 위해 릴레이션(테이블)을 분해하는 체계적인 과정입니다. (⬅️ 문제점 설명과 연결)
  • 이상 현상 (Anomaly): 정규화되지 않거나 불완전하게 정규화된 테이블에서 데이터 삽입, 삭제, 갱신 시 발생하는 원치 않는 부작용입니다.
    • 삽입 이상: 특정 데이터를 삽입하기 위해 불필요한 다른 데이터를 함께 삽입해야 하는 문제.
    • 삭제 이상: 특정 데이터를 삭제할 때 보존해야 할 다른 데이터까지 함께 삭제되는 문제. (⬅️ 문제점 1과 연결)
    • 갱신 이상: 중복된 데이터 중 일부만 갱신하여 데이터 불일치가 발생하는 문제. (⬅️ 문제점 1과 연결)
  • 함수 종속성 (Functional Dependency): (⬅️ 정규화의 기반 개념) 릴레이션에서 특정 속성(들)의 값(X)이 다른 속성(들)의 값(Y)을 유일하게 결정하는 관계입니다. X -> Y (X는 Y를 함수적으로 결정한다)는 X 값에 따라 Y 값이 유일하게 결정된다는 의미입니다.
    • 부분 함수 종속 (Partial Functional Dependency): (⬅️ 문제점 2, 가) 해설 언급) 기본 키(Primary Key)가 복합 키(Composite Key, 즉 여러 속성으로 구성)일 때, 기본 키의 일부 속성이 기본 키가 아닌 다른 속성을 결정하는 경우입니다. (예: (A, B)가 기본키이고, A -> C 관계가 성립할 때 C는 기본키의 일부인 A에만 종속되는 부분 종속성 관계) 문제점 2 설명에 명확히 언급되었습니다.
    • 이행 함수 종속 (Transitive Functional Dependency): A -> B 이고 B -> C 이며 A -> C 일 때 (단, B가 기본 키의 일부가 아닌 경우), 기본 키(A)가 아닌 속성(B)을 통해 비기본 키 속성(C)이 결정되는 경우입니다.
  • 정규형 (Normal Forms): 정규화의 각 단계를 나타내는 기준입니다. 높은 정규형일수록 데이터 중복이 줄어들고 무결성이 강화됩니다.
    • 제1 정규형 (First Normal Form - 1NF): 모든 속성 값이 원자값(Atomic Value)이어야 하며, 반복 그룹이 없어야 합니다. (일반적으로 정규화의 시작점)
    • 제2 정규형 (Second Normal Form - 2NF): (⬅️ 문제의 핵심 출제 포인트) 제1 정규형을 만족하고, 기본 키가 복합 키일 때 부분 함수 종속을 모두 제거한 형태입니다. 부분 함수 종속 관계를 가지는 속성들을 원래 테이블에서 분리하여 별도의 테이블로 생성하는 방식으로 수행합니다. 문제점 2 설명과 해설에 명확히 언급되었습니다.
    • 제3 정규형 (Third Normal Form - 3NF): 제2 정규형을 만족하고 이행 함수 종속을 제거한 형태입니다.

4. 문제 해결 전략 (문항15, 16)

문항15, 16과 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. [커뮤니티회원 데이터] 분석: 데이터 샘플을 보고 어떤 속성들이 함께 나타나고 어떤 데이터가 중복되고 있는지 파악합니다. 커뮤니티ID와 회원ID의 조합으로 각 행이 유일하게 식별되는지, 아니면 다른 속성(예: 가입일자)까지 포함해야 하는지 등을 고려하여 기본키 후보를 유추합니다. (데이터 샘플을 보면 (커뮤니티ID, 회원ID) 조합이 기본키 후보임을 알 수 있습니다.)
  2. '데이터 모델 설계' 문제점 분석: 제시된 문제점(갱신 이상, 삭제 이상)이 정규화되지 않았을 때 발생하는 이상 현상임을 인지합니다.
  3. 문제점 2 (Partial Dependency) 상세 분석:
    • "일반 속성인 ‘회원명’, ‘회원전화번호’가 주식별자 중 하나인 ‘가)’에만 종속되는 Partial Dependency가 존재하기 때문이다."
    • 이 설명은 부분 함수 종속이 존재하며, 그 결정자가 '주식별자 중 하나'임을 명시합니다.
    • 데이터 샘플에서 '회원명'과 '회원전화번호'는 회원ID에 따라 결정되는 값임을 알 수 있습니다. (동일 회원ID는 동일 회원명/전화번호를 가짐). 기본키가 (커뮤니티ID, 회원ID)라면, '회원명', '회원전화번호'는 전체 기본키가 아닌 일부인 '회원ID'에만 종속됩니다. 따라서 부분 종속성을 유발하는 '주식별자 중 하나'는 회원ID입니다. (⬅️ 가)에 들어갈 내용)
  4. <TO-BE> 모델 설명 분석:
    • "일부 키에만 종속되는 속성들을 별도의 엔터티로 분리하는 ____나)____차 정규화를 진행했다."
    • '일부 키에만 종속되는 속성'은 부분 함수 종속 관계를 가지는 속성들을 의미합니다.
    • 부분 함수 종속을 제거하여 수행하는 정규화 단계가 **제2 정규형(2NF)**임을 학습 내용을 통해 알고 있습니다. (⬅️ 나)에 들어갈 내용)
  5. 빈칸 완성 및 정답 확인: 추론된 내용을 바탕으로 빈칸 가)에는 '회원ID', 빈칸 나)에는 '2'가 들어간다고 판단합니다. 파일 해설에서 이를 확인합니다.

5. 예상 문제 (문항15 관련) 3개

문항15(가)와 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 15-1) 아래 [수강 신청 테이블]은 제1 정규형은 만족하지만, 특정 정규형 규칙을 위반하고 있습니다.

[수강 신청 테이블]

학번 (PK)과목코드 (PK)학생명학과과목명교수명

1001 CS101 김철수 컴퓨터공학 자료구조 박교수
1001 MA202 김철수 컴퓨터공학 선형대수 최교수
1002 CS101 이영희 소프트웨어 자료구조 박교수

이 테이블에서 제2 정규형(2NF) 위반의 원인이 되는 부분 함수 종속 관계에서 결정자(Determinant) 역할을 하는 속성들을 모두 작성하시오. [4점]

답: ____________________, ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (복수 정답)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 수강 신청 테이블 부분 함수 종속 결정자 식별
  • 출제 의도: 주어진 테이블에서 제2 정규형 위반 원인인 부분 함수 종속의 결정자 식별 능력 검증

해설: [수강 신청 테이블]의 기본키는 (학번, 과목코드) 복합키입니다.

  • '학생명'과 '학과'는 '학번'에만 종속됩니다 (학번만 알면 학생명과 학과를 알 수 있음). 즉, 학번 -> 학생명, 학과 입니다.
  • '과목명'과 '교수명'은 '과목코드'에만 종속됩니다 (과목코드만 알면 과목명과 교수명을 알 수 있음). 즉, 과목코드 -> 과목명, 교수명 입니다. 부분 함수 종속이란 기본키의 일부가 비기본 키 속성을 결정하는 관계입니다. 여기서 '학번'과 '과목코드'는 기본키의 일부이며, 각각 비기본 키 속성(학생명, 학과 / 과목명, 교수명)을 결정합니다. 따라서 부분 함수 종속의 결정자는 '학번'과 '과목코드'입니다.

예상 문제 15-2) 제1 정규형(1NF)은 만족하지만 제2 정규형(2NF)을 위반하는 테이블의 특징을 설명하시오. [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 제2 정규형 위반 테이블 특징 서술
  • 출제 의도: 제2 정규형 위반 상태의 특징 이해도 검증

해설: 제1 정규형은 만족하지만 제2 정규형을 위반하는 테이블은 기본 키가 복합 키이며, 기본 키를 구성하는 속성들 중 일부 속성이 기본 키가 아닌 다른 속성을 함수적으로 결정하는 부분 함수 종속이 존재합니다.

예상 문제 15-3) 제2 정규형을 달성하기 위해 제1 정규형 테이블에서 수행해야 하는 작업은 무엇입니까? [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 제2 정규형 달성 방법 서술
  • 출제 의도: 제2 정규화 수행 방법 이해도 검증

해설: 제2 정규형을 달성하기 위해서는 기본 키가 복합 키인 테이블에서, 기본 키의 일부 속성에만 종속되는 속성들을 식별하여 원래 테이블에서 분리하고, 분리된 속성들을 기본 키의 일부 속성과 함께 새로운 테이블로 만들어야 합니다. 즉, 부분 함수 종속을 제거해야 합니다.

6. 예상 문제 (문항16 관련) 3개

문항16(나)와 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 16-1) 데이터베이스 정규화 과정에서, 제1 정규형을 만족하는 테이블에서 부분 함수 종속을 제거하여 도달하는 정규형 단계는 무엇입니까? [3점]

답: 제 ____________________ 정규형

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 부분 함수 종속 제거 관련 정규형 명칭
  • 출제 의도: 제2 정규형의 정의 이해도 검증

해설: 제1 정규형을 만족하고 부분 함수 종속을 제거한 형태는 제2 정규형입니다.

예상 문제 16-2) 다음 중 제2 정규형(2NF)을 위반하는 테이블에서 발생할 수 있는 이상 현상으로 가장 거리가 먼 것은? [3점] ① 삽입 이상 (Insertion Anomaly) ② 삭제 이상 (Deletion Anomaly) ③ 갱신 이상 (Update Anomaly) ④ 이행 이상 (Transitive Anomaly)

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 제2 정규형 위반 시 발생하는 이상 현상 식별
  • 출제 의도: 제2 정규형 위반으로 발생하는 이상 현상 이해도 검증

해설: 제2 정규형을 위반하는(부분 함수 종속이 존재하는) 테이블에서는 삽입, 삭제, 갱신 이상이 발생할 수 있습니다. 이행 이상은 이행 함수 종속으로 인해 발생하는 이상 현상으로, 제3 정규형 위반 시 발생합니다.

예상 문제 16-3) 제2 정규화 과정을 통해 얻을 수 있는 주요 효과는 무엇입니까? [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 제2 정규화의 효과 서술
  • 출제 의도: 제2 정규화 수행의 결과 및 효과 이해도 검증

해설: 제2 정규화는 부분 함수 종속을 제거함으로써 기본 키의 일부에만 종속되는 속성들의 데이터 중복을 감소시키고, 그로 인해 삽입, 삭제, 갱신 이상 현상을 완화 또는 방지하는 효과를 가져옵니다.

  • 정답: 기본 키의 일부에만 종속되는 속성들의 데이터 중복을 감소시키고 삽입/삭제/갱신 이상 현상을 완화 또는 방지한다. (또는 유사 내용 서술)

 

문항17 (조직 테이블 자기참조 모델) 관련 학습 내용, 예상 문제 및 해설

첨부된 PDF 파일 내 문항17은 A전자의 조직 테이블 데이터 목록 및 [예시] 설명을 제시하고, 자기참조(순환) 모델에 대한 설명 중 옳은 내용을 모두 고르는 문제입니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: 'A전자'의 조직 테이블 데이터([보기] - 조직코드, 조직명, 상위조직코드 컬럼)와 계층적 데이터 관리를 위한 자기참조(순환) 모델 사용을 언급합니다. 이 모델에 대한 설명 다섯 가지([예시] A-E) 중 옳은 것을 모두 포함하는 보기를 고릅니다.
  • 해설: 정답이 4번 보기(④)이며, [예시]의 A, B, C, E는 옳은 설명이고, D는 잘못된 설명이라고 명시합니다. D가 잘못된 이유는 속성 추가 등 구조를 변경해도 식별자는 변경되지 않으며 과거 데이터 변경 필요도 없기 때문이라고 설명합니다.
    • 옳은 설명 (A, B, C, E):
      • A. 자기참조 모델은 새로운 계층의 추가/수정에 대해 유연하게 대처할 수 있다. (구조 변경 없이 데이터만 추가) (⬅️ 자기참조 모델의 장점)
      • B. 최상위 계층의 '상위조직코드' 컬럼은 상위조직코드가 없으므로 NULL로 구성하였다. (⬅️ 최상위 계층 표현 방식)
      • C. 조직 테이블의 자기참조 모델은 1:M의 관계를 가진다. (⬅️ 모델 내 관계 유형)
      • E. 조직 엔터티를 물리 모델 변환 시, '상위조직코드'는 FK(Foreign Key) 컬럼이 되고, PK(Primary Key)인 '조직코드'를 참조하게 된다. (⬅️ 물리 모델 변환)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링 (⬅️ 주된 출제 영역)
  • 출제 의도: 자기참조 순환 모델의 특징을 이해하는지 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 데이터 모델링 분야 중 논리 데이터 모델링 단계에서 계층적 데이터를 표현하는 방법 중 하나인 자기참조(순환) 모델에 대한 이해를 평가하며, 이 모델의 개념, 구조, 장점, 최상위 표현 방식, 모델 내 관계 유형 등을 정확히 아는지에 초점을 맞추고 있습니다. 또한, 논리 모델이 물리 모델로 변환될 때의 관련 요소(FK)도 함께 묻고 있습니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 계층적 데이터 관리 (⬅️ 문제 언급)

  • 개념: 데이터 항목들이 부모-자식 관계를 가지며 나무(Tree) 구조 형태로 조직되는 데이터 구조입니다.
  • 예시: 조직도(회사/부서/팀), 파일 시스템(폴더/파일), 카테고리 분류(대분류/중분류/소분류), 댓글/답글 구조 등. 문항17은 조직도를 예시로 사용했습니다.
  • 데이터 모델링: 관계형 데이터베이스에서 계층 구조를 표현하기 위한 여러 모델링 방법이 존재합니다 (자기참조 모델, 인접 리스트 모델, 경로 열거 모델, 중첩 집합 모델 등). 문항17은 이 중 자기참조 모델에 집중합니다.

3. 자기참조 관계/순환 모델 (Self-Referencing / Recursive Model) (⬅️ 문제의 핵심 주제)

  • 개념: 데이터 모델링에서 하나의 엔터티가 자기 자신과 관계를 맺는 것입니다. 같은 엔터티의 인스턴스들 간에 부모-자식, 상위-하위 등의 관계를 표현할 때 사용됩니다.
  • 구현 방법 (관계형 DB):
    • 테이블 내에 외래 키(Foreign Key - FK) 컬럼을 추가합니다.
    • 이 외래 키 컬럼은 동일 테이블의 기본 키(Primary Key - PK) 컬럼을 참조(Reference)합니다.
    • 예시 (조직 테이블): 조직 테이블에 '조직코드' (PK)와 '상위조직코드' (FK) 컬럼이 있고, '상위조직코드'는 '조직코드'를 참조합니다. 특정 조직의 '상위조직코드' 값은 그 조직의 상위 조직의 '조직코드' 값이 됩니다. (⬅️ [보기] 및 [예시] E와 연결)
  • 최상위 계층 표현: 계층 구조의 뿌리(Root)에 해당하는 최상위 인스턴스(상위가 없는 인스턴스)의 외래 키 컬럼 값은 NULL로 설정합니다. (⬅️ [예시] B와 연결)
  • 모델 내 관계 유형: 하나의 부모 인스턴스가 여러 자식 인스턴스를 가질 수 있고, 하나의 자식 인스턴스는 하나의 부모 인스턴스에만 속하는 경우가 일반적입니다. 따라서 자기참조 모델은 일반적으로 1:M (일대다) 관계를 가집니다. (⬅️ [예시] C와 연결)
  • 장점:
    • 유연성: 계층 구조의 깊이에 제한 없이 표현할 수 있습니다.
    • 단순성: 새로운 하위 요소나 계층을 추가할 때 테이블 구조 변경 없이 데이터(레코드)만 추가하면 됩니다. (⬅️ [예시] A와 연결)
  • 단점:
    • 조회 복잡성: 특정 인스턴스의 모든 하위/상위 인스턴스를 조회하거나 전체 계층 구조를 탐색할 때, 일반적인 SQL 쿼리만으로는 복잡하며 재귀 쿼리(Recursive Query) 또는 계층형 쿼리(Hierarchical Query) 기능(예: CONNECT BY 또는 WITH RECURSIVE)이 필요할 수 있습니다.

4. 논리 데이터 모델링 및 물리 데이터 모델링 (⬅️ 문제 출제 영역 및 예시 E)

  • 논리 모델링: 현실 세계의 데이터를 특정 DBMS에 독립적으로 모델링합니다. 엔터티, 속성, 관계를 정의합니다. 자기참조 관계는 이 단계에서 논리적인 관계(예: '포함한다' 관계의 카디널리티/선택성 정의)로 표현됩니다.
  • 물리 모델링: 논리 모델을 실제 DBMS에 구축 가능하도록 변환합니다. 논리 모델의 엔터티는 테이블로, 속성은 컬럼으로, 관계는 외래 키(FK) 제약 조건 등으로 변환됩니다. 자기참조 관계는 물리 모델에서 테이블 내의 FK가 동일 테이블의 PK를 참조하는 형태로 구현됩니다. (⬅️ [예시] E와 연결)
  • [예시] D 분석: '자기참조 모델에서 속성 추가로 구조가 변경되면 식별자가 변해야 하므로, 과거 데이터에 대한 수정 작업을 수행해야 한다.' - 속성을 추가하는 것은 테이블 스키마 변경이며, 기존 데이터의 식별자(PK)를 변경하지 않습니다. 기존 데이터의 ID는 그대로 유지됩니다. 따라서 이 설명은 잘못되었습니다. (⬅️ 해설에서 틀린 이유 설명)

5. 문제 해결 전략 (문항17)

문항17과 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 문제 상황 이해: 조직 테이블, 계층 구조, 자기참조 모델이라는 핵심 개념을 파악합니다. [보기] 데이터를 통해 조직코드-상위조직코드 관계가 어떻게 표현되는지 확인합니다.
  2. 자기참조 모델의 특징 떠올리기: 학습한 자기참조 모델의 개념, 구조, 장점, 최상위 표현 방식, 모델 내 관계 유형 등을 떠올립니다.
  3. [예시] 설명 하나씩 분석: [예시] A, B, C, D, E 각 설명이 자기참조 모델의 특징에 대해 올바르게 기술하고 있는지 판단합니다.
    • A: 새로운 계층 추가 유연성 - 장점에 해당.
    • B: 최상위 '상위조직코드' NULL - 최상위 표현 방식에 해당.
    • C: 1:M 관계 - 모델 내 관계 유형에 해당.
    • D: 구조 변경 시 식별자 변경 및 과거 데이터 수정 - 단점/고려 사항과 비교하며 판단. (경험적 지식 또는 학습 내용을 통해 틀린 설명임을 알 수 있음)
    • E: 물리 변환 시 FK 참조 - 물리 모델 변환 방식에 해당.
  4. 옳은 설명 모두 포함한 보기 선택: 분석 결과 옳은 설명들(해설에 따르면 A, B, C, E)로만 구성된 보기를 선택합니다.

6. 예상 문제 3개 (데이터 모델링 - 자기참조 관계)

문항17과 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 17-1) 데이터 모델링에서 조직 구조, 파일 시스템 경로, 상품 카테고리 분류 등과 같이 계층적인 데이터 구조를 표현하는 데 적합한 데이터 모델링 기법 중 하나는 무엇입니까? [3점]

답: ____________________ 모델

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 계층적 데이터 모델링 기법 (자기참조) 명칭
  • 출제 의도: 계층 구조 표현을 위한 자기참조 모델의 용도 이해도 검증

해설: 조직 구조, 파일 시스템 등 계층적인 데이터를 표현하는 데 자기참조(순환) 모델이 사용됩니다.

예상 문제 17-2) 자기참조(순환) 모델을 사용하여 테이블 내에서 계층 구조를 표현할 때, 해당 테이블에 반드시 포함되어야 하는 두 가지 유형의 키(Key)는 무엇입니까? [4점] ① 기본 키 (Primary Key), 유일 키 (Unique Key) ② 기본 키 (Primary Key), 외래 키 (Foreign Key) ③ 외래 키 (Foreign Key), 후보 키 (Candidate Key) ④ 유일 키 (Unique Key), 후보 키 (Candidate Key)

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 자기참조 모델 필수 키 유형 식별
  • 출제 의도: 자기참조 모델 구현에 필요한 핵심 키 요소 이해도 검증

해설: 자기참조 모델은 테이블 내에 기본 키(PK)와, 동일 테이블의 기본 키를 참조하는 외래 키(FK)를 사용하여 구현됩니다. 따라서 기본 키와 외래 키가 반드시 포함되어야 합니다.

예상 문제 17-3) 자기참조 모델을 사용하여 계층 구조를 모델링할 때, 새로운 하위 항목(예: 기존 부서 아래 새로운 팀)을 추가하는 작업이 비교적 용이한 주된 이유는 무엇입니까? [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 논리데이터 모델링
  • 문제 제목: 자기참조 모델의 데이터 추가 용이성 이유
  • 출제 의도: 자기참조 모델의 특징 (구조 변경 불필요) 이해도 검증

해설: 자기참조 모델은 새로운 하위 항목을 추가할 때 테이블 구조(컬럼 등)를 변경할 필요 없이, 단순히 새로운 데이터(레코드/행)를 추가하고 해당 데이터의 외래 키(상위 항목 참조 컬럼)에 상위 항목의 기본 키 값을 넣어주기만 하면 되기 때문에 데이터 추가가 용이합니다.

  • 정답: 새로운 하위 항목 추가 시 테이블 구조 변경 없이 데이터(레코드)만 추가하면 되기 때문이다. (또는 유사 내용 서술)

 

 

 

문항18 (위험성 평가 지원 시스템) 관련 학습 내용, 예상 문제 및 해설

본 문서는 첨부된 PDF 파일 내 문항18("위험성 평가 지원 시스템 구축")와 관련하여 학습하여야 할 주제 및 내용을 상세히 정리하고, 해당 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다. 예상 문제는 문제와 해설을 이어서 제시합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: A제조사의 '위험성 평가 지원 시스템' 구축을 위해 **[화면 설계서]**를 분석하여 필요한 엔터티를 도출했으며, **[엔터티 정의서]**가 제시되었습니다. 이 두 문서를 참조하여 보기의 내용 중 **부적절한 항목 (2개)**을 고르는 문제입니다. (보기 전문은 파일에 제공되지 않았습니다.)
    • [화면 설계서] '위험성평가(상세)' 설명: 평가 항목 목록(가능성, 중대성, 위험성, 결정, 위험성 감소 대책, 개선 예정일, 담당자) 및 각 항목의 입력 방식, 값 범위, 활성화 조건('결정' 항목이 '보완'일 때 특정 항목 활성화), 첨부파일 필요성 등 명시.
    • [엔터티 정의서] 설명: '평가대상업종', '유해위험요인', '위험성평가', '위험성평가점검항목' 엔터티 명세 (초기건수, 비고 등).
  • 해설: "2 번 위험성평가점검항목 엔터티는 위험성평가 메인테이블과 1 차 정규화 관계이므로 ‘유해위험요인’ 엔터티의 초기건수와 같이 100 개의 속성이 되어서는 안됨. 3 번은 위험성평가와 위험성평가점검 엔터티의 Optionality 는 필수 대 필수의 관계임." (원본 파일 해설 전문)
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리 (⬅️ 문제와 직접 관련)
  • 출제 의도: 제시된 화면설계서와 엔터티 정의서를 참고하여 설계시 필요한 속성을 도출하고, 도메인 식별 및 표준용어를 작성할 수 있는지 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 요구사항 분석 결과물인 화면 설계서를 기준으로, 시스템에 필요한 **데이터 요소(엔터티, 속성)**를 식별하고, 데이터 모델링 결과물인 엔터티 정의서와 비교하여 데이터 정의의 적절성 및 일관성을 검토하는 능력을 평가합니다. 특히 데이터 표준화 관점에서 속성 도출, 도메인 식별, 표준 용어 적용 능력과, 데이터 모델의 구조적 적절성(정규화 관점) 및 **관계의 특성(Optionality)**에 대한 이해도를 함께 평가하는 복합적인 문제입니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 프로세스 모델링: 화면 정의서 분석 (⬅️ 문제에 제시된 정보 출처)

  • 개념: 사용자가 시스템과 상호작용하는 UI 화면의 구성, 요소, 동작 방식 등을 상세 기술한 문서입니다.
  • 데이터 요소 식별: 화면 설계서에 표시되거나 사용자가 입력/선택/첨부하는 모든 항목은 시스템이 관리해야 할 데이터 요소(속성 후보)입니다. 각 항목의 이름, 목적, 데이터 타입/형식/길이 제약, 필수 여부, 입력 가능한 값 범위/종류 등을 상세히 분석하여 데이터 모델링의 입력 정보로 활용합니다. 문항18에서는 '가능성', '중대성', '위험성', '결정', '위험성 감소 대책'(최대 4000자), '개선 예정일'(날짜 선택), '담당자'(사원 조회 선택) 등의 항목 분석이 중요합니다.

3. 데이터 모델링 (⬅️ 문제의 핵심 대상)

  • 개념: 현실 세계의 데이터를 추상화하여 데이터베이스 저장 구조를 설계하는 과정입니다. 논리 모델링 단계에서 엔터티, 속성, 관계를 정의하고 정규화를 수행하며, 물리 모델링 단계에서 DBMS에 맞게 변환합니다.
  • 엔터티 (Entity): 업무 상 관리하려는 대상 (예: 위험성평가, 유해위험요인).
  • 속성 (Attribute): 엔터티의 특징. 화면 항목은 속성에 매핑됩니다. (예: 위험성평가 엔터티의 '평가일자', '담당자ID', 위험성평가점검항목 엔터티의 '가능성', '중대성', '위험성', '결정', '위험성 감소 대책' 등)
  • 관계 (Relationship): 엔터티 간의 연관성. 화면 설계서에서 유추될 수 있는 엔터티 간 관계(예: '위험성평가'와 '유해위험요인', '위험성평가'와 '담당자(직원)')를 모델링합니다.
    • Optionality (선택성/참여도): 관계에 참여하는 엔터티 인스턴스가 필수적으로 연관되어야 하는지 선택적인지를 나타냅니다. 문항18 해설에서 '위험성평가'와 '위험성평가점검' 엔터티 간의 Optionality 검토를 언급합니다. (예: 모든 위험성 평가는 하나 이상의 점검 항목을 가져야 하는가?)

4. 데이터 표준화 (⬅️ 문항18 출제 영역 핵심)

  • 개념: 데이터 모델링 과정에서 데이터 요소(엔터티, 속성, 도메인 등)의 명칭, 정의, 형식 등에 대한 일관된 기준을 수립하고 적용하는 활동입니다.
  • 주요 요소:
    • 표준 용어: 데이터 요소에 대해 조직 내에서 통일하여 사용하는 공식 명칭 (예: 고객번호, 상품가격).
    • 표준 코드: 코드화된 데이터의 표준 체계 및 값 정의 (예: 성별 코드 'M'/'F').
    • 도메인 (Domain): (⬅️ 출제 의도 언급) 속성이 가질 수 있는 값의 유형, 형식, 길이, 허용 범위/목록 등을 정의한 논리적인 데이터 타입입니다. (예: '금액' 도메인: 숫자, 0 이상, 10자리; '이메일' 도메인: 문자열, @ 포함 형식). 화면 설계서에 명시된 항목의 데이터 제약 사항(최대 길이 4000자, 날짜 형식, 특정 값만 허용 등)은 해당 속성의 도메인을 식별하는 데 중요한 단서가 됩니다. (⬅️ 문제 해결에 필수적)
    • 표준 속성/엔터티: 표준 용어, 도메인 등을 적용하여 정의된 표준화된 속성 및 엔터티.

5. 화면 설계서와 데이터 모델 간의 일관성 및 적절성 검토 (⬅️ 문제의 핵심 평가 능력)

  • 핵심 활동: 화면 설계서의 요구사항(어떤 데이터가 필요하고 어떻게 사용되는가)이 데이터 모델(엔터티 정의서)에 올바르고 일관성 있게 반영되었는지 비교 분석하여 부적절한 부분을 찾아냅니다.
  • 검토 포인트:
    • 속성 누락/초과: 화면에 필요한 정보가 데이터 모델에 빠져 있거나, 화면에 불필요한 속성이 정의되어 있지 않은가?
    • 속성 정의 불일치: 화면 요구 사항(예: 최대 길이, 데이터 타입 제약, 필수 여부)과 엔터티 정의서의 해당 속성 정의(타입, 길이, 필수 여부)가 일치하는가? (⬅️ 도메인 식별 및 적용 오류)
    • 관계 부적절성: 화면 로직이나 업무 요구사항을 표현하기 위한 엔터티 간 관계가 올바르게 정의되었는가? 관계의 Optionality는 적절한가? (⬅️ 문항18 해설 언급)
    • 모델 구조 적절성: 화면 요구사항 대비 데이터 모델의 구조가 효율적인가? (예: 반복되는 그룹을 한 엔터티에 속성으로 나열한 경우 -> 1차 정규화 위반 가능성, 별도의 상세 엔터티로 분리 필요) (⬅️ 문항18 해설의 '1차 정규화 관계' 언급과 연결)
    • 표준 용어 적용: 속성 명칭 등이 데이터 표준(단어사전 등)에 따라 올바르게 사용되었는가? (⬅️ 출제 의도 언급)

6. 문제 해결 전략 (문항18)

문항18과 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다. (보기 전문이 없으므로 추정 기반 전략입니다.)

  1. [화면 설계서] 상세 분석: 화면에 표시되거나 입력/선택/첨부되는 모든 항목(데이터 요소)을 식별하고, 각 항목의 성격(이름, 목적, 데이터 타입/형식/길이 제약, 필수 여부, 입력 가능한 값 범위/종류, 다른 항목과의 연관성 등)을 꼼꼼히 파악합니다. '위험성 감소 대책'의 4000자 제약, '결정'에 따른 항목 활성화/비활성화 로직 등을 주의 깊게 봅니다.
  2. 필요한 데이터 모델 요소 및 특성 유추: 식별된 화면 항목들을 저장하거나 표현하기 위해 필요한 엔터티(예: 위험성평가, 유해위험요인, 위험성평가점검항목)와 속성들을 유추합니다. 각 속성의 예상되는 데이터 타입, 길이, 필수 여부, 도메인 제약 등을 화면 정의에 맞춰 예상합니다. 필요한 엔터티 간 관계도 유추합니다.
  3. [엔터티 정의서] 분석 (원 문제 필요): 제시된 엔터티 정의서의 내용을 분석하여, 실제로 어떤 엔터티가 정의되었고 각 엔터티가 어떤 속성을 어떤 정의(타입, 길이, 필수 등)로 가지고 있는지, 엔터티 간 관계는 어떻게 정의되었는지 파악합니다. (원본 파일에 엔터티 정의서 일부 텍스트가 있습니다.)
    • 엔터티: 평가대상업종, 유해위험요인, 위험성평가, 위험성평가점검항목.
    • 속성: 위험성평가점검항목 테이블에 필요한 최소 속성으로 {가능성, 중대성, 위험성, 결정, 위험성감소대책, 개선예정일, 담당자} 언급. '위험성감소대책' 속성은 '위험성감소대책내용' 용어로 등록하고 도메인 '내용_V4000'(VARCHAR, 4000자) 지정 언급.
  4. 화면 요구사항과 엔터티 정의 비교 및 부적절성 식별: 유추 및 분석한 화면 요구사항과 실제 엔터티 정의서의 내용을 비교하며 부적절하거나 일관성 없는 부분을 찾아냅니다. (⬅️ 문제의 핵심)
    • 속성 정의 불일치: 예: '위험성 감소 대책' 화면 요구(최대 4000자) vs 엔터티 정의('내용_V4000', VARCHAR 4000) -> 이 부분은 일치하는 것 같습니다. 하지만 다른 속성에서 불일치가 있을 수 있습니다.
    • 모델 구조 부적절성/불일치: '유해위험요인'별 평가 항목이 반복되는 구조인데, 엔터티 정의서에서 이를 어떻게 모델링했는지 (예: '위험성평가'와 '위험성평가점검항목' 엔터티로 분리). 만약 '위험성평가' 엔터티에 '가능성1, 중대성1, 가능성2, 중대성2...' 이런 식으로 반복 속성이 있다면 1차 정규화 위반으로 부적절합니다. (해설에서 '위험성평가점검항목 엔터티는 위험성평가 메인테이블과 1차 정규화 관계이므로 ... 속성이 되어서는 안됨' 언급 -> 아마 위험성평가점검항목 엔터티에 1차 정규화 위반 소지가 있거나, 다른 엔터티와의 관계를 잘못 설정하여 속성이 과도하게 많아진 경우를 지적하는 보기 내용이 있었을 수 있습니다.)
    • 관계 특성 불일치: '위험성평가'와 '위험성평가점검항목' 엔터티 간의 관계(1:M 또는 1:1?) 및 Optionality가 화면 요구 사항(예: 최소 1개 이상의 점검 항목 필수)이나 업무 규칙과 일치하는가? (해설에서 'Optionality는 필수 대 필수의 관계임' 언급 -> 아마 보기에서 이 관계의 Optionality를 다른 것으로 설명했거나, 실제는 필-필 관계인데 다른 관계 정의 오류를 지적했을 수 있습니다.)
    • 필수 여부 불일치: 화면에서 특정 조건(결정='보완') 만족 시 필수인 항목이 엔터티에서는 조건부 필수 정의가 어렵거나 (DB 제약상) 다른 방식으로 정의되어 불일치하는 경우.
    • 표준 용어/도메인 적용 오류: 속성 명칭이 표준에 어긋나거나, 도메인 정의가 부적절한 경우.
  5. 보기의 설명 검토 (원 문제 필요): 보기에 제시된 설명들이 화면 설계서 내용, 엔터티 정의서 내용, 데이터 모델링 원칙에 비추어 적절한지 판단합니다. 어떤 설명이 잘못되었는지를 찾아냅니다.
  6. 부적절한 항목 선택: 부적절하다고 판단된 설명 항목(보기)을 모두 고릅니다.

7. 예상 문제 3개 (화면 설계 -> 데이터 모델링)

문항18과 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 18-1) 아래 [사용자 프로필 편집 화면 설명]과 이 화면을 지원하기 위해 정의된 [사용자 엔터티 정의 일부]를 참조하여, [사용자 엔터티 정의 일부] 내용 중 화면 요구사항과 부적절한 항목을 모두 고르시오. (2개) [5점]

[사용자 프로필 편집 화면 설명] 사용자는 자신의 프로필 정보(이름, 이메일 주소, 전화번호)를 수정할 수 있습니다. 이름은 최대 50자까지 입력 가능하며 필수 항목입니다. 이메일 주소는 이메일 형식(@ 포함)이어야 하며, 필수 항목입니다. 전화번호는 선택 사항이며, 숫자와 하이픈(-)만 포함 가능합니다.

[사용자 엔터티 정의 일부]

속성명데이터 타입길이필수설명

user_id INT   Y 사용자 고유 ID
user_name VARCHAR 50 Y 사용자 이름
email VARCHAR 100 N 이메일 주소
phone VARCHAR 20 N 전화번호

① user_name 필수 여부 ② email 필수 여부 ③ email 유효성 검증 정의 누락 ④ phone 허용 문자열 제약 누락 ⑤ user_name 길이

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 사용자 프로필 화면 vs 엔터티 정의 불일치 식별
  • 출제 의도: 화면 요구사항과 엔터티 정의(필수 여부, 도메인 제약 등)를 비교하여 불일치 식별 능력 검증

해설: 화면 요구사항과 엔터티 정의를 비교합니다. ① user_name 필수 여부: 화면에서 필수. 엔터티에서 Y(필수). (일치) ② email 필수 여부: 화면에서 필수. 엔터티에서 N(선택). (불일치) ③ email 유효성 검증 정의 누락: 화면에서 이메일 형식(@ 포함). 엔터티 정의서에 Validation Rule 컬럼이 없지만, 해당 속성의 도메인 정의에 형식 제약이 명시되어야 합니다. 엔터티 정의서만 보고 누락 여부를 판단하기는 어려울 수 있으나, 표준적인 데이터 모델 정의서에는 도메인 또는 유효성 제약이 명시됩니다. 문제의 엔터티 정의서 일부에 해당 컬럼이 누락된 것이 부적절하다고 판단할 수 있습니다. (부적절) ④ phone 허용 문자열 제약 누락: 화면에서 숫자와 하이픈(-)만 포함 가능. 엔터티 정의서에 Validation Rule 컬럼이 없지만, 해당 속성의 도메인 정의에 형식 제약이 명시되어야 합니다. ③과 마찬가지로 누락된 것이 부적절하다고 판단할 수 있습니다. (부적절) ⑤ user_name 길이: 화면에서 최대 50자. 엔터티에서 50자. (일치)

부적절한 항목은 email 필수 여부(화면 필수 vs 엔터티 선택)와 email/phone의 유효성/형식 제약 정의 누락(화면 요구사항 있으나 엔터티 정의서에 반영 안됨)입니다. 보기 형태로 보아, ② email 필수 여부와 ③ 또는 ④ (둘 다 유효성/제약 정의 누락) 중 하나가 부적절한 항목에 해당할 가능성이 높습니다. 문제 원본 보기를 알 수 없으므로 정확한 조합은 판단 어렵지만, ②와 ③ 또는 ②와 ④의 조합이 정답일 수 있습니다.

예상 문제 18-2) 아래 [주문 상세 화면 설명]과 이를 지원하는 [주문 엔터티 정의 일부]를 참조하여, [주문 엔터티 정의 일부] 내용 중 화면 요구사항과 부적절한 항목을 모두 고르시오. (2개) [5점]

[주문 상세 화면 설명] 화면은 특정 주문의 상세 정보(주문 번호, 주문 일자, 총 결제 금액)와 해당 주문에 포함된 여러 개의 주문 상품 목록(상품명, 수량, 가격)을 표시합니다. 주문 상품 목록은 최소 1개 이상 존재하며, 최대 20개까지 표시될 수 있습니다.

[주문 엔터티 정의 일부]

속성명데이터 타입길이필수설명

order_id INT   Y 주문 번호
order_date DATE   Y 주문 일자
total_amount DECIMAL 10,2 Y 총 결제 금액
item_name_1 VARCHAR 100 N 주문 상품명 1
item_qty_1 INT   N 주문 수량 1
... ... ... ... ...
item_name_20 VARCHAR 100 N 주문 상품명 20
item_qty_20 INT   N 주문 수량 20

① order_id 필수 여부 ② total_amount 데이터 타입 ③ 주문 상품 정보를 반복 속성으로 정의한 구조 ④ 주문 상품 목록의 최소 개수 제약 누락 ⑤ order_date 데이터 타입

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 주문 상세 화면 vs 엔터티 정의 불일치 식별 (구조 포함)
  • 출제 의도: 화면 요구사항과 엔터티 정의(속성 반복, 관계 부재 등)를 비교하여 부적절성 식별 능력 검증 (정규화 관점 포함)

해설: 화면 요구사항과 엔터티 정의를 비교합니다. ① order_id 필수 여부: 주문 번호는 주문의 식별자이므로 필수(Y)인 것이 적절합니다. (일치 가능) ② total_amount 데이터 타입: 총 결제 금액은 소수점을 가질 수 있는 숫자이므로 DECIMAL(10,2) 타입 적절합니다. (일치 가능) ③ 주문 상품 정보를 반복 속성으로 정의한 구조: 화면에서 여러 개의 주문 상품 목록이 표시된다고 했습니다. 엔터티 정의서에서는 이를 item_name_1~20, item_qty_1~20과 같이 반복 속성으로 정의했습니다. 이는 1차 정규형 위반이며, 데이터 중복 및 관리상 어려움을 유발하는 부적절한 구조입니다. 주문과 주문 상품은 별도의 엔터티(주문, 주문상품)로 분리하고 1:M 관계로 모델링해야 합니다. (부적절) ④ 주문 상품 목록의 최소 개수 제약 누락: 화면에서 최소 1개 이상 존재한다고 했습니다. 엔터티 정의서에는 이러한 최소 개수 제약이 명시되어 있지 않습니다. 데이터 모델 단계에서는 보통 관계의 Optionality로 표현하며, 엔터티 정의서에는 해당 제약에 대한 설명이나 DB 제약(CHECK, Trigger 등)이 명시될 수 있습니다. 엔터티 정의서만 보고 누락 여부 판단이 어려울 수 있으나, 요구사항이 있으므로 모델에 반영되어야 합니다. (부적절 가능) ⑤ order_date 데이터 타입: 주문 일자는 날짜이므로 DATE 타입 적절합니다. (일치 가능)

가장 명확하게 부적절한 항목은 ③ 주문 상품 정보를 반복 속성으로 정의한 구조입니다. 이는 데이터 모델링 기본 원칙(정규화)에 어긋나는 심각한 부적절성입니다. ④도 요구사항이 모델에 반영되지 않은 부적절성입니다. 따라서 ③과 ④의 조합이 정답일 가능성이 높습니다.

예상 문제 18-3) 화면 설계서에서 특정 항목(예: '담당자')이 다른 시스템(예: 사원 정보 시스템)의 조회 팝업을 통해 선택되는 방식으로 정의되어 있습니다. 이러한 화면 요구사항은 데이터 모델에서 어떤 점을 고려하여 설계해야 함을 시사합니까? [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 화면 UI 로직 기반 데이터 모델 관계/속성 추론
  • 출제 의도: 화면의 데이터 선택 로직을 보고 데이터 모델의 관계 및 속성 추론 능력 검증

해설: 화면에서 특정 항목이 다른 시스템(사원 정보 시스템)의 조회 팝업을 통해 선택된다는 것은, 해당 항목의 실제 값(예: 사원 번호)이 다른 엔터티(예: 직원 엔터티)에 이미 관리되고 있으며, 이 화면의 엔터티(예: 위험성평가)가 해당 다른 엔터티(직원)와 관계를 맺고 그 다른 엔터티의 식별자(예: 사원 번호)를 **외래 키(FK)**로 참조해야 함을 시사합니다. 화면에 표시되는 이름(사원명)은 외래 키를 통해 조인하여 가져오거나, 성능 고려 시 비정규화하여 함께 저장할 수 있습니다.

  • 정답: 해당 항목의 실제 값(식별자)은 다른 엔터티에 의해 관리되며, 이 화면의 엔터티와 그 다른 엔터티 간에 관계(Relationship)가 설정되고 외래 키(Foreign Key)를 통해 해당 식별자를 참조해야 함을 시사한다. (또는 유사 내용 서술)

 

 

문항19, 20 (입시마스터 테이블) 관련 학습 내용, 예상 문제 및 해설

본 문서는 첨부된 PDF 파일 내 문항19("입시마스터 테이블 인덱스 스캔") 및 문항20("입시마스터 테이블 도메인 정의")의 공통 지문 내용을 분석하고, 해당 문제들에 대해 공부해야 할 관련 주제 및 내용을 상세히 정리합니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다. 예상 문제는 각 문항별로 3개씩 도출하여 문제와 해설을 이어서 제시합니다.

1. 문제 분석 및 관련 학습 주제 파악 (문항19, 20 공통 지문)

  • 공통 지문 내용: 대학 학사관리시스템의 입시마스터 테이블에 대한 사례입니다.
    • 대용량 데이터: 총 100만 건, 도별 약 5만 건 (⬅️ 대용량 데이터 관리의 필요성 시사)
    • Primary Key: 수험번호, 도, 학기 순으로 구성된 복합 기본 키 (⬅️ 복합키 구조 제시)
    • 참고 자료: [보기]는 '데이터모델과 인덱스 구성' 및 'SQL과 실행계획' 정보를 포함 (⬅️ 인덱스, 쿼리 실행 계획 관련 문제 시사)

이 공통 지문은 대용량 데이터가 저장된 테이블, 복합 기본 키 구조, 그리고 인덱스 및 쿼리 실행 계획과 관련된 문제를 다룰 것임을 명확히 하고 있습니다. 이는 데이터 모델링 중 물리 데이터 모델링 단계에서의 성능 고려 사항 및 데이터베이스 튜닝 분야와 밀접하게 관련됩니다.

2. 문제 분석 및 관련 학습 주제 파악 (문항19)

  • 문제 내용: [보기]의 SQL 문(SELECT COUNT(수험번호) FROM 입시마스터 WHERE 년도 = '2024')이 현재 테이블 Full Scan으로 수행되고 있으며, PK Index 스캔을 수행하도록 가능한 테이블 구성 (보기에서 2개 선택)을 고르는 문제입니다.
  • 해설: 인덱스 스캔 수행을 위해서는 Index 구성 컬럼들이 WHERE 조건에 포함되어야 하며, 주식별자 순서대로 Index 구성 컬럼의 앞쪽에 위치해야 한다고 명시합니다. (⬅️ 인덱스 스캔 사용 조건 핵심 지침)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 물리데이터 모델링 (⬅️ 문제와 직접 관련)
  • 출제 의도: 인덱스 스캔 수행에 대한 이해 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 문항19는 물리 데이터 모델링 단계에서 대용량 테이블의 조회 성능을 향상시키기 위해 사용되는 데이터베이스 인덱스에 대한 이해를 평가합니다. 특히 **복합 기본 키(Composite Primary Key)**에 생성되는 PK 인덱스의 구조와, 특정 SQL 쿼리의 WHERE 절 조건이 해당 인덱스를 활용한 인덱스 스캔을 유도하기 위한 조건을 정확히 아는지를 묻고 있습니다. 문제의 해설은 인덱스 스캔이 사용되기 위한 핵심 조건(WHERE 절 컬럼 포함 및 복합 인덱스의 선행 컬럼 사용)을 명확히 제시하고 있습니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

문항19 관련 학습 주제 상세

  • 데이터 모델링 - 물리 데이터 모델링:
    • 개념: 논리 모델을 특정 DBMS 및 성능 고려하여 변환.
    • 성능 고려 사항: 대용량 데이터 처리 시 발생하는 성능 문제 이해.
  • **데이터베이스 **인덱스(Index)****: (⬅️ 문항19 핵심 주제)
    • 개념: 데이터 검색(조회) 속도를 높이기 위해 테이블의 특정 컬럼 값을 기준으로 데이터의 위치를 미리 저장해 둔 구조. (예: 책의 색인)
    • 필요성: 대용량 테이블에서 원하는 데이터를 빠르게 찾기 위해 Full Table Scan을 피하고 Index Scan을 사용.
    • 구조: 주로 B-Tree 구조 사용. 인덱스 키 컬럼들의 정렬된 형태로 구성.
    • 기본 키(PK) 인덱스: 대부분의 DBMS는 테이블 생성 시 정의된 기본 키에 대해 자동으로 인덱스를 생성합니다. 이 인덱스는 해당 테이블에 대한 빠른 접근 경로를 제공합니다.
    • 복합 인덱스 (Composite Index): 여러 컬럼을 조합하여 만든 인덱스입니다. PK가 복합 키일 경우 PK 인덱스도 복합 인덱스로 생성됩니다. (예: (컬럼1, 컬럼2, 컬럼3) 순서의 복합 인덱스)
    • 인덱스 스캔 (Index Scan) vs Full Table Scan:
      • Full Table Scan: 테이블의 모든 행을 처음부터 끝까지 읽어 필요한 데이터를 찾습니다. 대용량 테이블에서는 비효율적입니다. (⬅️ 문제의 현재 상태)
      • Index Scan: 인덱스를 먼저 검색하여 원하는 데이터가 저장된 테이블의 특정 행들만 선별적으로 읽습니다. (⬅️ 문제의 목표 상태)
  • SQL 쿼리 및 실행 계획:
    • SQL 기본: SELECT, FROM, WHERE 절의 역할 이해.
    • 쿼리 실행 계획 (Execution Plan): 특정 SQL 쿼리가 데이터베이스에 의해 어떤 방식으로(예: Full Scan, Index Scan) 실행될지 보여주는 계획. 옵티마이저(Optimizer)가 생성합니다. (⬅️ 문제 제시)
    • 옵티마이저: SQL 쿼리를 가장 효율적으로 실행하기 위한 방법을 결정하는 DBMS 내부 컴포넌트. WHERE 절 등을 분석하여 인덱스 사용 여부를 결정합니다.
  • 인덱스 사용 조건 (특히 복합 인덱스): (⬅️ 문항19 해설 핵심 지침 및 출제 의도)
    • WHERE 절에 인덱스 컬럼 포함: 인덱스가 생성된 컬럼 중 하나 이상이 쿼리의 WHERE 절에 사용되어야 옵티마이저가 해당 인덱스를 고려합니다.
    • 복합 인덱스의 선행 컬럼 사용: 복합 인덱스 (컬럼1, 컬럼2, 컬럼3)가 있을 때, WHERE 절에 컬럼1만 사용하거나 (컬럼1, 컬럼2)를 사용하거나 (컬럼1, 컬럼2, 컬럼3)를 사용하는 경우 해당 인덱스를 활용한 효율적인 인덱스 스캔이 가능합니다. 하지만 컬럼2만 사용하거나 (컬럼2, 컬럼3)를 사용하는 경우에는 일반적으로 해당 복합 인덱스를 효율적으로 활용한 스캔이 어렵거나 불가능합니다. PK Index 스캔을 유도하려면 PK 구성 컬럼 중 선행 컬럼(들)이 WHERE 절에 포함되어야 합니다. 문항19의 PK가 (수험번호, 도, 학기) 순서이므로, WHERE 절 조건이 이 순서를 고려하여 인덱스 스캔을 유도할 수 있는 형태를 갖춰야 합니다.

3. 문제 분석 및 관련 학습 주제 파악 (문항20)

  • 문제 내용: '등록금_N8’과 같이 특정 값 범위(0 ~ 99,999,999)를 가지는 숫자로 정의된 속성을 언급하며, 이처럼 유사 유형 데이터를 그룹화하여 해당 그룹의 유형과 길이를 정의하는 것을 무엇(가)이라고 하는지 묻는 문제입니다.
  • 해설: 가)에 '도메인' 또는 'Domain'이 들어간다고 명시하며, 등록금에 대한 데이터 타입 등의 표준화를 위해 도메인을 구성해야 한다고 설명합니다.
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준화 (⬅️ 문제와 직접 관련)
  • 출제 의도: 도메인의 개념을 이해하는지 검증 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 문항20은 데이터 모델링 분야 중 데이터 표준화의 핵심 요소인 **도메인(Domain)**에 대한 이해를 평가합니다. 특정 속성이 가질 수 있는 값의 유형(타입)과 길이/범위를 정의하고 이를 표준화하는 개념을 정확히 아는지를 묻고 있습니다.

문항20 관련 학습 주제 상세

  • 데이터 모델링 - 데이터 표준화: (⬅️ 문항20 출제 영역)
    • 개념: 데이터 모델링 과정에서 데이터 요소(엔터티, 속성, 도메인 등)의 명칭, 정의, 형식 등에 대해 조직 내에서 일관된 기준을 수립하고 적용하는 활동. 데이터 품질 향상, 시스템 간 연계 용이성 증대, 개발/유지보수 효율성 증대를 목적으로 합니다.
    • 주요 요소: 표준 용어, 표준 코드, 도메인, 표준 속성/엔터티.
  • 도메인 (Domain): (⬅️ 문항20 핵심 주제 및 출제 의도)
    • 개념: 데이터 모델링에서 속성(Attribute)이 가질 수 있는 값의 집합과 그 특성을 정의한 논리적인 데이터 타입입니다. 값의 유형(Type), 길이(Length), 정밀도(Precision), 허용 가능한 값 범위(Value Range), 허용 가능한 값 목록(Value List) 등을 정의합니다.
    • 목적: 데이터의 의미를 명확히 하고, 데이터 입력 시 유효성 검사를 통해 데이터 일관성 및 정확성을 확보합니다. 유사한 유형의 속성들에 동일한 도메인을 적용하여 표준화합니다. (⬅️ 문제 설명과 일치)
    • 예시: '금액' 도메인 (숫자, 0 이상, 10자리), '이메일' 도메인 (문자열, 이메일 형식), '성별' 도메인 (코드, 'M' 또는 'F' 값만 허용). 문항20은 '등록금'이라는 속성에 대해 '숫자' 유형과 '0 ~ 99,999,999' 범위라는 도메인이 정의된 예시를 제시하고 있습니다.

4. 예상 문제 (문항19 관련) 3개

문항19 및 데이터베이스 인덱스, 복합 PK 관련 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 19-1) 대용량 데이터베이스 테이블에서 특정 조건을 만족하는 데이터를 빠르게 조회하기 위해, 테이블의 특정 컬럼 값들을 기준으로 데이터 위치를 미리 저장해둔 데이터베이스 객체는 무엇입니까? [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형
  • 출제 영역: 데이터 모델링 - 물리데이터 모델링
  • 문제 제목: 데이터 검색 속도 향상 객체 명칭
  • 출제 의도: 데이터베이스 인덱스 개념 이해도 검증

해설: 데이터베이스 테이블의 검색 속도를 높이기 위해 사용하는 객체는 인덱스(Index)입니다.

예상 문제 19-2) [입시마스터 테이블]의 Primary Key는 (수험번호, 도, 학기) 순서로 구성되어 있습니다. 이 PK에 대해 자동으로 생성되는 복합 인덱스를 활용하여 효율적인 인덱스 스캔이 가능한 SQL 쿼리의 WHERE 절 조건을 모두 포함하는 보기를 고르시오. (단, 각 보기는 WHERE 절의 일부 조건만을 나타냅니다.) [4점] ① WHERE 도 = '서울' ② WHERE 학기 = '1학기' AND 도 = '서울' ③ WHERE 수험번호 = '20240001' ④ WHERE 학기 = '1학기' ⑤ WHERE 도 = '서울' AND 수험번호 = '20240001'

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 물리데이터 모델링
  • 문제 제목: 복합 PK 인덱스 스캔 사용 조건
  • 출제 의도: 복합 인덱스 사용 시 WHERE 절 조건과 인덱스 컬럼 순서 간의 관계 이해도 검증

해설: [입시마스터 테이블] PK 인덱스는 (수험번호, 도, 학기) 순서로 구성됩니다. 복합 인덱스를 효율적으로 활용한 인덱스 스캔은 WHERE 절에 인덱스의 선행 컬럼(들)이 포함될 때 가능합니다. ① '도'만 사용: 선행 컬럼이 아니므로 비효율적 스캔 또는 Full Scan. ② '학기', '도' 사용: 선행 컬럼이 아니므로 비효율적 스캔 또는 Full Scan. ③ '수험번호'만 사용: 인덱스의 가장 선행 컬럼이므로 효율적인 인덱스 스캔 가능. ④ '학기'만 사용: 선행 컬럼이 아니므로 비효율적 스캔 또는 Full Scan. ⑤ '도', '수험번호' 사용: '수험번호'는 선행 컬럼이나, 순서가 바뀌어 사용되면 효율성이 떨어질 수 있습니다. (옵티마이저에 따라 달라질 수 있으나 일반적으로 인덱스 정의 순서를 따르는 것이 효율적입니다.) 가장 효율적인 경우는 ③번처럼 선행 컬럼부터 순서대로 사용되는 경우입니다. 따라서 효율적인 인덱스 스캔이 가능한 WHERE 조건은 ③입니다.

예상 문제 19-3) 대용량 테이블에서 Full Table Scan 대신 Index Scan을 사용하는 주된 이유는 무엇입니까? [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 물리데이터 모델링
  • 문제 제목: Index Scan 사용 이유
  • 출제 의도: Index Scan의 장점 이해도 검증

해설: 대용량 테이블에서 Index Scan은 Full Table Scan보다 훨씬 적은 양의 데이터를 읽어 데이터 검색(조회) 속도를 크게 향상시키기 위해 사용됩니다.

  • 정답: 테이블의 전체 데이터를 읽는 대신 인덱스를 통해 필요한 데이터만 빠르게 찾아 읽어서 조회 성능을 향상시키기 위해 사용된다. (또는 유사 내용 서술)

5. 예상 문제 (문항20 관련) 3개

문항20 및 데이터 표준화, 도메인 관련 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 20-1) 데이터 모델링 시 속성(Attribute)이 가질 수 있는 값의 유형(Type), 길이(Length), 허용 범위(Value Range) 등을 정의하여 데이터의 의미를 명확히 하고 일관성을 확보하는 데이터 표준화 요소를 무엇이라고 합니까? [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형
  • 출제 영역: 데이터 모델링 - 데이터 표준화
  • 문제 제목: 데이터 표준화 요소 (값 특성) 명칭
  • 출제 의도: 도메인 개념 이해도 검증

해설: 속성 값이 가질 수 있는 유형, 길이, 범위 등을 정의하는 데이터 표준화 요소는 도메인(Domain)입니다.

예상 문제 20-2) 데이터 표준화 활동을 통해 얻을 수 있는 주요 기대 효과 두 가지를 서술하시오. [4점]

답: 기대 효과 1: ____________________, 기대 효과 2: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 표준화
  • 문제 제목: 데이터 표준화 기대 효과 서술
  • 출제 의도: 데이터 표준화의 목적 및 기대 효과 이해도 검증

해설: 데이터 표준화를 통해 얻을 수 있는 주요 효과는 다음과 같습니다.

  • 기대 효과 1: 데이터의 일관성 및 정확성이 향상되어 데이터 품질이 높아진다.
  • 기대 효과 2: 시스템 간 데이터 연계 및 통합이 용이해진다.
  • 기대 효과 3: 데이터 정의의 명확성으로 개발 및 유지보수 효율성이 증가하고 의사소통이 원활해진다. (위 세 가지 중 두 가지를 작성하면 됩니다.)

예상 문제 20-3) 아래 [속성 목록]과 [도메인 정의]를 참고하여, '상품 가격' 속성에 적용할 수 있는 가장 적절한 도메인은 무엇입니까? [3점]

[속성 목록]

  • 사용자 이름
  • 상품 가격
  • 주문 수량
  • 배송 예정일

[도메인 정의 일부]

도메인 명칭데이터 타입허용 범위

텍스트 문자열  
정수 숫자  
날짜 날짜  
금액 숫자 0 이상

① 텍스트 ② 정수 ③ 날짜 ④ 금액

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 표준화
  • 문제 제목: 속성에 적합한 도메인 선택
  • 출제 의도: 속성의 성격을 보고 적합한 도메인을 식별하는 능력 검증

해설: '상품 가격'은 금액을 나타내며, 금액 도메인이 숫자 타입이고 0 이상이라는 허용 범위를 가집니다. 이는 상품 가격의 성격과 가장 잘 맞습니다.

 

 

 

문항21 (계좌 엔터티 대체키 변경) 관련 학습 내용, 예상 문제 및 해설

본 문서는 첨부된 PDF 파일 내 문항21("L보험사 계좌 엔터티 대체키 변경")과 관련하여 학습하여야 할 주제 및 내용을 상세히 정리하고, 해당 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다. 예상 문제는 문제와 해설을 이어서 제시합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: L보험사가 '계좌' 엔터티의 주식별자를 여러 속성으로 이루어진 원래의 식별자에서 하나의 대체키로 변경했습니다. **[데이터 모델]**에 이러한 변경 결과가 제시되었으며, 대체키 사용에 관한 설명 중 **부적절한 내용 (2개)**을 고르는 문제입니다. (보기 전문은 파일에 제공되었습니다.)
    • 보기 (원본 파일): ① '계약해지신청’ 하위 엔터티 생성 시, ‘계좌ID’만 상속받기 때문에 엔터티 단순화 및 비즈니스키 변경 영향 감소. (⬅️ 대체키의 장점 설명) ② ‘계좌ID’는 Occurrence 발생하는 순서 기준으로 번호 부여받아 비즈니스적 의미 파악에 도움. (⬅️ 대체키의 특징 설명) ③ 물리 모델에서 ‘계좌ID’를 대체키로 사용하면 참조 테이블 조인 조건 줄어 쿼리 간결. (⬅️ 대체키의 장점 설명) ④ ‘계좌ID’ 같은 대체키는 순차적 번호 부여 가능, 개별 계좌 구체 정보 직접 노출 않아 보안상 유리. (⬅️ 대체키의 특징 및 장점 설명) ⑤ 대체키는 일반적으로 논리 모델링 단계부터 사용하는 것 바람직하며, 비즈니스키 대신하므로 별도 Unique 인덱스 생성 불필요. (⬅️ 대체키 사용 시점 및 인덱스 관련 설명)
  • 해설: "2 번: 업무를 파악하는데 도움이 되는 것은 Business Key 이다. 5 번: 일반적으로 논리 모델링시 Business Key /본질식별자 위주로 모델링하고, 효율성을 고려하여 물리 데이터모델링 시 대체키/인조식별자로 도입을 검토하며, 대체키를 적용하면 Unique 인덱스를 생성하여 유일성을 보장할 필요가 있음." (원본 파일 해설 전문)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 물리데이터 모델링 (⬅️ 문제와 직접 관련)
  • 출제 의도: 물리데이터 모델링전환 시 대체키/인조식별자에 대한 장단점 비교 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 데이터 모델링 분야 중 물리 데이터 모델링 단계에서 사용되는 식별자(Identifier), 특히 **대체 키(Surrogate Key) 또는 인조 식별자(Artificial Identifier)**에 대한 이해를 평가합니다. **비즈니스 키(Business Key) 또는 본질 식별자(Natural Identifier)**와 대비되는 대체 키의 개념, 특징, 장점, 단점, 그리고 물리 모델링에서의 역할을 정확히 아는지를 묻고 있습니다. 제시된 보기 설명의 적절성을 판단하기 위해 각 식별자의 속성을 명확히 구분할 수 있어야 합니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 데이터 모델링 단계 및 물리 데이터 모델링 (⬅️ 문항21 출제 영역)

  • 논리 데이터 모델링: 현실 세계 데이터를 특정 DBMS 독립적으로 모델링. 비즈니스 키(본질 식별자) 위주로 식별자를 정의하는 것이 일반적입니다. (⬅️ 문항21 해설 언급)
  • 물리 데이터 모델링: 논리 모델을 특정 DBMS 및 성능 고려하여 변환. 이 단계에서 성능이나 관리 효율성을 위해 대체 키(인조 식별자) 도입을 검토하기도 합니다. (⬅️ 문항21 해설 언급)

3. 식별자 (Identifier) / 키 (Key) 종류

  • 개념: 엔터티 내에서 개별 인스턴스를 유일하게 식별하는 속성 또는 속성 집합.
  • 비즈니스 키 (Business Key) / 본질 식별자 (Natural Identifier): (⬅️ 문항21 해설 언급)
    • 개념: 업무적으로 의미를 가지고 있으며, 실제 비즈니스에서 해당 인스턴스를 구분하는 데 사용하는 식별자입니다. (예: 주민등록번호, 학번, 계좌번호(원래 식별자) 등)
    • 특징: 사용자가 이해하기 쉽고 비즈니스 규칙과 연결됩니다. 업무를 파악하는 데 도움이 됩니다. (⬅️ 문항21 해설 및 보기 ② 관련) 비즈니스 요구사항 변경 시 함께 변경될 가능성이 있습니다.
  • 대체 키 (Surrogate Key) / 인조 식별자 (Artificial Identifier): (⬅️ 문항21 핵심 주제)
    • 개념: 시스템 내부적인 필요(성능, 관리 용이성 등)에 의해 인위적으로 생성되어 부여하는 식별자입니다. 비즈니스적인 의미는 없습니다. (예: DB의 Auto-Increment 값, GUID 등) 문항21의 '계좌ID'가 이에 해당합니다.
    • 특징:
      • 비즈니스 의미 없음: 업무를 파악하는 데 직접적인 도움을 주지 않습니다. (⬅️ 문항21 해설 및 보기 ② 관련)
      • 변경되지 않음: 비즈니스 요구사항 변경과 무관하게 안정적으로 유지됩니다.
      • 주로 단일 속성: 복합 비즈니스 키 대신 단일 속성으로 사용되는 경우가 많습니다.
      • 주로 물리 모델링 단계에서 도입: 논리 모델에서는 비즈니스 키로 모델링하고, 물리 모델 변환 시 효율성 등을 고려하여 대체 키를 추가 도입하는 방식이 일반적입니다. (⬅️ 문항21 해설 및 보기 ⑤ 관련)
  • 키의 역할:
    • 기본 키 (Primary Key): 엔터티 인스턴스를 유일하게 식별하는 논리적/물리적 식별자. Not Null과 Unique 제약을 가집니다.
    • 외래 키 (Foreign Key): 다른 테이블의 기본 키를 참조하여 테이블 간 관계 설정 및 참조 무결성 유지.
  • 대체 키의 활용 및 장단점:
    • 활용: 복합 비즈니스 키 대신 사용, 조인 컬럼 단순화, 데이터 변경으로부터 독립성 확보.
    • 장점:
      • 조인 성능 향상: 복합 비즈니스 키 대신 단일 속성 대체 키를 사용하면 조인 조건이 단순해져 물리 모델에서의 조인 성능이 향상될 수 있습니다. (⬅️ 보기 ③ 관련)
      • 관리 용이성: 키 값이 인위적이므로 관리 정책 수립 용이.
      • 변경 안정성: 비즈니스 규칙 변경 시에도 키 값 변경이 불필요.
      • 보안: 실제 비즈니스 정보를 노출하지 않아 보안에 유리할 수 있습니다. (⬅️ 보기 ④ 관련)
      • 하위 엔터티 단순화: 상속 관계의 슈퍼/서브타입 모델에서 슈퍼타입의 대체 키만 하위 서브타입이 상속받아 모델을 단순화할 수 있습니다. (⬅️ 보기 ① 관련)
    • 단점:
      • 비즈니스 의미 부족: 사용자나 개발자가 키 값만 보고 데이터 의미 파악 어려움.
      • Unique 제약/인덱스 필요: 대체 키는 인위적인 값이므로 유일성을 보장하기 위해 별도의 Unique 제약 조건을 설정하거나 Unique 인덱스를 생성해야 합니다. (⬅️ 문항21 해설 및 보기 ⑤ 관련)

4. 데이터베이스 제약 조건 (Constraint)

  • 개념: 데이터의 정확성, 완전성, 일관성을 보장하기 위해 데이터베이스에 정의하는 규칙.
  • Unique 제약: 특정 컬럼의 값이 테이블 내에서 유일해야 함을 보장합니다. 대체 키는 유일성을 보장하기 위해 Unique 제약 또는 Unique 인덱스를 필요로 합니다. (⬅️ 문항21 해설 및 보기 ⑤ 관련)

5. 문제 해결 전략 (문항21)

문항21과 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 문제 상황 이해: 계좌 엔터티의 주식별자를 여러 속성에서 하나의 대체키로 변경했다는 핵심 내용을 파악합니다. [데이터 모델]을 통해 변경 결과를 시각적으로 확인합니다.
  2. 대체 키의 특징 및 장단점 떠올리기: 학습한 대체 키의 개념, 비즈니스 키와의 차이점, 장점, 단점, 물리 모델링에서의 역할, 그리고 Unique 제약/인덱스 필요성 등을 상세히 떠올립니다.
  3. 보기의 설명 하나씩 분석: 각 보기가 대체 키 사용에 대해 설명하는 내용을 하나씩 읽습니다.
  4. 설명의 적절성 판단: 각 보기가 대체 키의 특징, 장점, 단점, 사용 시점, 제약 조건 등에 대해 올바르게 설명하고 있는지 판단합니다. 특히 해설에서 언급된 보기 ②와 ⑤의 내용이 부적절한 설명임을 염두에 두고 분석합니다.
    • 보기 ①: 하위 엔터티 단순화 - 대체 키의 장점 중 하나.
    • 보기 ②: Occurrence 순서 기준 번호 부여 -> 비즈니스 의미 파악 도움 - 대체 키는 비즈니스 의미가 없고 업무 파악에 도움 안됨 (해설). 비즈니스 키에 대한 설명. (⬅️ 부적절)
    • 보기 ③: 물리 모델 조인 조건 줄어 쿼리 간결 - 대체 키의 장점 중 하나.
    • 보기 ④: 순차 번호 부여 가능, 정보 노출 않아 보안 유리 - 대체 키의 특징 및 장점 중 하나.
    • 보기 ⑤: 논리 모델링부터 사용 바람직, Unique 인덱스 불필요 - 주로 물리 모델링에서 도입 (해설). 유일성 보장 위해 Unique 인덱스 필요 (해설). (⬅️ 부적절)
  5. 부적절한 설명 모두 선택: 판단 결과, 부적절하다고 판단된 설명 항목(보기) ②와 ⑤를 선택합니다.

6. 예상 문제 3개 (데이터 모델링 - 식별자/키)

문항21 및 식별자/키 관련 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 21-1) 데이터 모델링에서 현실 세계의 업무적 의미를 가지며, 사용자가 데이터를 구분하는 데 사용하는 식별자를 무엇이라고 합니까? [3점]

답: ____________________ 식별자

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 데이터 모델링 - 데이터 구조 설계 > 식별자
  • 문제 제목: 비즈니스적 의미를 가진 식별자 명칭
  • 출제 의도: 비즈니스 키(본질 식별자) 개념 이해도 검증

해설: 업무적 의미를 가지고 사용자가 데이터를 구분하는 데 사용하는 식별자를 비즈니스 식별자 또는 본질 식별자라고 합니다.

예상 문제 21-2) 데이터 모델링 시 대체 키(Surrogate Key) 사용의 단점 중 하나를 서술하시오. [4점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (서술형)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 물리데이터 모델링
  • 문제 제목: 대체 키 단점 서술
  • 출제 의도: 대체 키 사용 시 발생 가능한 단점 이해도 검증

해설: 대체 키는 비즈니스 의미가 없으므로 사용자나 개발자가 키 값만 보고는 해당 데이터의 의미를 파악하기 어렵다는 단점이 있습니다. 또한, 유일성 보장을 위해 Unique 인덱스 등 추가적인 관리가 필요할 수 있습니다.

  • 정답: 키 값만 보고는 해당 데이터(행)가 무엇을 의미하는지 파악하기 어렵다. (또는 유일성 보장을 위해 별도의 Unique 제약/인덱스 설정이 필요하다 등)

예상 문제 21-3) 대체 키(Surrogate Key)는 일반적으로 논리 모델링 단계보다는 어느 데이터 모델링 단계에서 도입을 검토하는 것이 바람직합니까? [3점]

답: ____________________ 데이터 모델링 단계

/ 필수 문항 정보 /

  • 문제 유형: 단답형 (빈칸 채우기)
  • 출제 영역: 데이터 모델링 - 데이터 모델링 > 물리데이터 모델링
  • 문제 제목: 대체 키 도입 단계
  • 출제 의도: 대체 키 도입이 주로 고려되는 데이터 모델링 단계 이해도 검증

해설: 논리 모델링 단계에서는 비즈니스 키 위주로 모델링하고, 성능이나 물리적 구현 효율성을 위해 대체 키는 일반적으로 물리 데이터 모델링 단계에서 도입을 검토합니다.

 

 

문항22 (시립도서관 ERD 컬럼명) 관련 학습 내용, 예상 문제 및 해설

본 문서는 첨부된 PDF 파일 내 문항22("A시 시립도서관의 ERD 일부")와 관련하여 학습하여야 할 주제 및 내용을 상세히 정리하고, 해당 주제를 기반으로 한 예상 문제 3개를 제시합니다. 문제의 해설, 출제 영역, 출제 의도를 종합적으로 분석하여 관련 학습 주제, 예상 문제, 그리고 해설을 상세히 정리합니다. 문제와 직접적으로 관련되었다고 파악한 사항은 강조하여 기술합니다. 예상 문제는 문제와 해설을 이어서 제시합니다.

1. 문제 분석 및 관련 학습 주제 파악

  • 문제 내용: A시 시립도서관 시스템의 논리 ERD 일부, 물리 ERD 일부, 그리고 **[단어사전]**이 제시되었습니다. 업무 담당자는 [단어사전] 규칙을 사용하여 물리 ERD 컬럼명을 정의하고 있습니다. 물리 ERD 가)에 들어갈 컬럼명을 대문자로 작성하는 문제입니다.
    • [데이터 모델] 논리 ERD/물리 ERD 이미지 (원본 파일): 논리 ERD에 '도서' 엔터티의 속성으로 '도서명'이 있습니다. 물리 ERD에는 'BOOK' 테이블의 컬럼으로 빈칸 가)가 있습니다. (즉, 논리 '도서명'에 해당하는 물리 컬럼명을 찾는 문제입니다.)
    • [단어사전]: 단어명, 단어영문명, 단어 영문 정식명 컬럼. '대출'-BRRW, '명'-NM, '번호'-NO, '예약'-RSRV, '일자'-DT 등의 단어별 영문명 정의 포함. ('도서'에 대한 직접적인 단어사전 항목은 파일에 없습니다. 해설을 통해 '도서'가 'BOOK'으로 매핑됨을 유추해야 합니다.)
  • 해설: "논리 ERD의 '도서명'은 '도서'와 '명' 단어의 조합으로 볼 수 있다. 단어사전에서 '도서'는 BOOK, '명'은 NM으로 정의되어 있다. 물리 ERD 컬럼명은 단어영문명을 대문자로 조합하며, 보통 언더스코어(_)로 구분하거나 붙여쓴다. 여기서는 파일 스타일을 따라 BOOK_NM 또는 BOOKNM으로 작성 가능하다." (원본 파일 해설 요약)
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리 (⬅️ 문제와 직접 관련)
  • 출제 의도: 물리데이터 모델링시 단어사전을 사용한 컬럼명 정의 (⬅️ 문제와 직접 관련)

종합적으로 볼 때, 이 문제는 데이터 모델링 분야 중 데이터 표준화의 핵심 활동인 데이터 명명 표준 적용 능력을 평가합니다. 특히 단어사전에 정의된 규칙을 사용하여 논리 데이터 모델의 속성명을 물리 데이터 모델의 표준화된 컬럼명으로 변환하는 방법을 정확히 아는지를 묻고 있습니다.

따라서 이 문제를 해결하고 관련 주제에 대한 대비를 하기 위해서는 다음 내용들을 학습해야 합니다.

2. 데이터 모델링 단계 및 물리 데이터 모델링

  • 논리 데이터 모델링: 업무 요구사항을 기반으로 데이터 구조를 개념적으로 정의한 후, 특정 DBMS에 독립적인 엔터티, 속성, 관계 등으로 상세화하는 단계입니다. 이 단계에서 속성명은 업무적으로 의미 있는 용어(논리명)로 정의합니다. (예: 도서명, 회원명, 주문일자)
  • 물리 데이터 모델링: 논리 모델을 실제 사용할 DBMS에 맞게 테이블, 컬럼, 데이터 타입, 제약 조건, 인덱스 등으로 변환하는 단계입니다. 이 단계에서 논리 속성명은 물리적인 컬럼명으로 변환됩니다.

3. 데이터 표준화 (⬅️ 문항22 핵심 주제 및 출제 영역)

  • 개념: 데이터 모델링 및 데이터베이스 구축/운영 과정에서 데이터 요소의 명칭, 정의, 형식 등에 대한 일관된 기준을 수립하고 적용하는 활동입니다. 데이터 품질 향상, 시스템 간 연계 용이성 증대 등을 목적으로 합니다.
  • 주요 요소:
    • 표준 용어: 조직 내에서 데이터 요소에 대해 통일하여 사용하는 공식 명칭 및 정의.
    • 단어사전 (Word Dictionary): (⬅️ 문제에 제시된 정보 형태) 데이터 표준 용어를 구성하는 단어들의 표준 약어나 영문명, 정식명 등을 정의한 문서입니다. 논리명이나 표준 용어를 구성하는 단어들을 단어사전에서 찾아 영문명으로 변환한 후 조합하여 물리명을 만듭니다.
      • 예시 (문항22): '명' -> NM, '번호' -> NO, '일자' -> DT. (해설을 통해) '도서' -> BOOK.
    • 표준 명명 규칙: 엔터티명, 속성명(컬럼명), 관계명 등에 대해 표준 용어 및 단어사전을 활용하여 이름을 만드는 규칙입니다. (예: 물리 컬럼명은 단어 영문명을 조합하고 대문자로, 언더스코어(_)로 단어 구분). 문제는 이 표준 명명 규칙을 적용하여 논리 속성명을 물리 컬럼명으로 변환하는 것을 평가합니다. (⬅️ 출제 의도)
    • 도메인 (Domain): 속성 값이 가질 수 있는 유형, 길이, 허용 범위 등 정의.

4. 문제 해결 전략 (문항22)

문항22와 같은 유형의 문제를 해결하기 위해서는 다음 단계를 따릅니다.

  1. 논리 ERD 및 물리 ERD 분석: 논리 ERD에서 빈칸 가)에 해당하는 논리 속성명을 식별합니다. (원본 파일 이미지에서 '도서명'임을 확인) 물리 ERD에서 이 속성이 변환될 물리 테이블(BOOK) 및 컬럼 위치를 확인합니다.
  2. 논리 속성명을 단어 단위로 분해: 식별된 논리 속성명('도서명')을 구성하는 단어 단위로 분해합니다. ('도서', '명')
  3. [단어사전] 참조: 단어사전을 보고 분해된 각 단어에 해당하는 표준 영문명을 찾습니다. ('명' -> NM) ('도서'는 단어사전에 없지만, 해설에서 BOOK으로 매핑됨을 유추)
  4. 표준 명명 규칙 적용: 단어사전에서 찾은 영문명을 물리 명명 규칙에 따라 조합하여 물리 컬럼명을 완성합니다. 문제에서는 대문자로 작성하고, 해설은 언더스코어(_)로 구분하거나 붙여쓴다고 합니다. 파일 스타일(해설 언급)을 따릅니다. (BOOK + NM -> BOOK_NM 또는 BOOKNM)
  5. 빈칸 완성: 완성된 물리 컬럼명(BOOK_NM 또는 BOOKNM)을 빈칸 가)에 작성합니다. 문제 요구사항에 따라 대문자로 작성해야 합니다.

5. 예상 문제 3개 (데이터 모델링 - 데이터 표준화)

문항22와 유사한 유형 및 수준의 예상 문제 3개를 제시합니다. 문제 풀이 및 해설은 문제 아래에 바로 이어서 제공합니다.

예상 문제 22-1) 데이터 모델링에서 논리 데이터 모델의 속성명(예: 회원 이름)을 물리 데이터 모델의 표준화된 컬럼명(예: USER_NM)으로 변환할 때, 변환 규칙의 기반이 되는 단어별 표준 영문명을 정의한 문서는 무엇입니까? [3점]

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 데이터 표준 명명 규칙 기반 문서 명칭
  • 출제 의도: 단어사전의 역할 이해도 검증

해설: 단어사전(Word Dictionary)은 표준 명명 규칙에 따라 논리명을 물리명으로 변환할 때 사용하는 단어별 표준 영문명 등을 정의한 문서입니다.

예상 문제 22-2) 아래 [단어사전 일부]와 [논리 속성명]을 참고하여, 이 속성의 표준 물리 컬럼명을 작성하시오. (단, 단어 영문명 사용, 여러 단어 조합 시 언더스코어(_) 구분, 대문자 표기) [4점]

[단어사전 일부]

단어명단어 영문명

주문 ORDR
일자 DT
번호 NO

[논리 속성명] 주문 일자 번호

답: ____________________

/ 필수 문항 정보 /

  • 문제 유형: 단답형
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 논리 속성명 -> 표준 물리 컬럼명 변환 (복합)
  • 출제 의도: 단어사전 및 명명 규칙을 활용한 복합 논리명 변환 능력 검증

해설: [논리 속성명] '주문 일자 번호'는 '주문', '일자', '번호' 단어의 조합입니다. [단어사전]에 따르면 '주문'은 ORDR, '일자'는 DT, '번호'는 NO입니다. 언더스코어(_)로 구분하고 대문자로 표기하는 규칙에 따라 물리 컬럼명은 ORDR_DT_NO가 됩니다.

예상 문제 22-3) 데이터 표준화를 통해 얻을 수 있는 기대 효과로 가장 거리가 먼 것은? [3점] ① 데이터 품질 향상 및 오류 감소 ② 시스템 개발 및 유지보수 비용 절감 ③ 데이터 모델링 복잡성 증가 ④ 데이터 관련 의사소통 명확화

/ 필수 문항 정보 /

  • 문제 유형: 선다형
  • 출제 영역: 데이터 모델링 - 데이터 표준화 > 데이터 표준관리
  • 문제 제목: 데이터 표준화 기대 효과 식별
  • 출제 의도: 데이터 표준화의 목적 및 기대 효과 이해도 검증

해설: 데이터 표준화는 데이터의 일관성을 확보하고 정의를 명확히 하여 데이터 품질을 높이고(①), 개발 및 유지보수 효율성을 증진시키며(②), 관련자 간 의사소통을 원활하게 합니다(④). 데이터 모델링을 체계적으로 지원하여 복잡성을 '감소'시키거나 효율성을 높이는 것이므로, 복잡성이 '증가'한다는 설명(③)은 거리가 멉니다.

 

반응형
저작자표시 비영리 변경금지 (새창열림)

'배워야 산다' 카테고리의 다른 글

문항별 관련 주제_1~11  (3) 2025.08.25
[C] exit 함수 오류 warning: incompatible implicit declaration of built-in function 'exit'  (0) 2011.05.23

관련글

티스토리툴바