software

Academic Suite 데이터베이스 설계

발행: (2025년 12월 29일 오후 12:06 GMT+9)
7 분 소요
원문: Dev.to

Source: Dev.to

데이터베이스는 Academic Suite의 기본 기반 역할을 합니다. 온라인 시험 시스템에서 부적절한 데이터베이스 스키마 설계는 특히 수백에서 수천 명의 학생이 거의 동시에 답안을 제출할 때 심각한 병목 현상을 초래할 수 있습니다.

이 장에서는 시스템 도메인 관점에서 데이터베이스 설계에 대해 논의하며, 데이터 스키마가 온라인 시험 시스템의 확장성, 일관성 및 가시성 요구를 어떻게 지원하는지에 초점을 맞춥니다.

2.1 데이터 모델 개요

Academic Suite는 PostgreSQL을 사용한 관계형 접근 방식으로 구축되었습니다. 이는 트랜잭션 처리, 복잡한 관계 관리 및 강력한 데이터 일관성을 제공하기 때문입니다.

데이터 모델은 네 가지 주요 그룹으로 나뉩니다:

  • 조직 모델 – 기관, 사용자 및 클래스
  • 학술 모델 – 과목, 퀴즈 및 문제 은행
  • 시험 모델 – 시험 실행 및 학생 시도
  • 감사 및 모니터링 모델 – 답변 및 부정 행위 방지 활동

이러한 구분은 책임을 분리하고 고급 기능 개발을 용이하게 합니다.

2.2 엔터티 관계 다이어그램 (ERD)

아래 다이어그램은 Academic Suite 시스템의 엔터티 간 주요 관계를 보여줍니다.

erDiagram
    INSTITUTION ||--|{ USER : has
    INSTITUTION ||--|{ SUBJECT : offers

    USER ||--|{ CLASS : "teaches/enrolled"
    USER ||--o{ ATTEMPT : takes

    SUBJECT ||--|{ CLASS : has
    SUBJECT ||--|{ QUIZ : contains

    QUIZ ||--|{ QUESTION : contains
    QUIZ ||--|{ EXAM_BATCH : scheduled_as

    QUESTION ||--|{ OPTION : has

    EXAM_BATCH ||--o{ ATTEMPT : records
    CLASS ||--|{ EXAM_BATCH : participates_in

    ATTEMPT ||--|{ ANSWER : contains
    ATTEMPT ||--|{ EVENT_LOG : generates

이 ERD는 이 장 및 이후 장들 전반에 걸쳐 주요 참고 자료로 사용됩니다.

2.3 조직 모델 (User, Institution, Class)

Institution & User

모든 사용자는 하나의 기관에 연결되어야 하며, 이는 향후 확장을 위한 멀티‑테넌시를 가능하게 합니다.

Table institutions

  • id (PK)
  • name
  • created_at

Table users

  • id (PK)
  • email (unique)
  • role (admin, teacher, student)
  • institution_id (FK)

이러한 관계는 초기 단계에서 과도한 복잡성을 추가하지 않으면서 기관 간 데이터 격리를 보장합니다.

Class

Class 엔터티는 학생들을 그룹화하고 시험 일정을 관리합니다.

  • student_ids는 학생 ID 배열을 포함하는 JSON Text 형태로 저장됩니다.

Design Decision
조인 테이블(class_students) 대신 JSON을 사용하는 이유는 시험 중 읽기 성능을 최적화하기 위함입니다. 높은 부하 상황에서 단일 행을 읽고 JSON을 파싱하는 것이 대규모 조인 테이블에 대해 JOIN을 수행하는 것보다 종종 더 빠릅니다. 이는 데이터베이스 수준에서 외래키 제약을 포기하는 것이며, 일관성 검증은 애플리케이션에서 수행합니다.

2.4 학술 모델 (Subject, Quiz, Question)

과목

기관에서 제공하는 과목을 나타냅니다.

퀴즈

Quiz는 시험 청사진 역할을 하며 전역 설정을 저장합니다:

  • time_limit
  • passing_score
  • exam_type

질문 및 옵션

각 Question은 내용과 유형(mcq, essay 등)을 저장합니다. 객관식 질문의 경우, 답변 옵션은 별도의 테이블(question_options)에 저장되어 옵션 수에 대한 유연성을 제공하고 향후 질문 유형을 지원합니다.

2.5 시험 모델 (ExamBatch & Attempt)

ExamBatch (시험 세션)

ExamBatch는 퀴즈의 구체적인 실행을 나타냅니다.

  • 하나의 퀴즈를 서로 다른 반에 대해 여러 번 일정에 잡을 수 있습니다.
  • 시험 입장 코드로 사용되는 token을 포함합니다.
  • 라이프사이클 상태: scheduled → active → finished.

Attempt (시험 시도)

학생이 시험을 시작할 때마다 Attempt 레코드가 생성됩니다.

주요 필드:

  • status: ACTIVE, SUBMITTED
  • remaining_time: 초 단위로 남은 시간의 스냅샷 (페이지 새로 고침이나 중단 후에도 일관성을 보장)
  • score: 최종 점수

2.6 Answer & EventLog (Critical Data & Anti‑Cheating)

Answer

answers 테이블은 각 질문에 대한 학생의 답안을 저장합니다.

  • 매우 큰 데이터 양
  • 시험 중 높은 쓰기 강도

최적화: (attempt_id, question_id) 복합 인덱스를 사용하여 시험 페이지를 다시 로드할 때 쿼리를 빠르게 유지합니다.

EventLog

의심스러운 활동은 event_logs 테이블에 기록되며, 포함 항목:

  • FOCUS_LOST
  • TAB_SWITCH
  • DEVICE_CHANGE

이 데이터는 이후 장에서 논의되는 실시간 모니터링 기능 및 시험 무결성 평가의 기반이 됩니다.

장 요약

우리는 조직 구조, 학술 모델, 시험 거래 모델 및 활동 로깅을 포괄하는 Academic Suite 데이터베이스 설계를 다루었습니다. 이 설계는 성능, 데이터 일관성 및 개발 유연성의 균형을 맞춥니다.

다음: Chapter 3 – 인증 및 인가 시스템 구축, 모든 Academic Suite 데이터와 기능에 대한 접근을 보호하는 주요 게이트웨이.

Back to Blog

관련 글

더 보기 »