[
  {
    "courseSlug": "data-modeling",
    "question": "이 코스가 '미리 보는 핵심 문장'으로 제시한, 코스 전체를 한 줄로 줄인 문장은 무엇인가요?",
    "option1": "테이블은 무조건 잘게 쪼갤수록 좋은 설계다",
    "option2": "모든 데이터는 하나의 테이블에 모아서 관리한다",
    "option3": "같은 사실은 딱 한 곳에만 적고, 필요한 곳에서는 번호(FK)로 가리킨다",
    "option4": "관계는 종류와 상관없이 항상 중간 테이블로 표현한다",
    "answerIndex": 2,
    "explanation": "섹션 1의 팁에서 코스 전체를 한 줄로 줄인 문장으로 \"같은 사실은 딱 한 곳에만 적고, 필요한 곳에서는 번호(FK)로 가리킨다\"를 제시합니다. 무조건 쪼개는 것은 오히려 섹션 5에서 경계한 내용이에요."
  },
  {
    "courseSlug": "data-modeling",
    "question": "코스에서 기본키(PK)를 설명할 때 사용한 비유로 알맞은 것은 무엇인가요?",
    "option1": "이름 — 누구나 알아보기 쉬운 값",
    "option2": "학번 — 학교 안에서 절대 겹치지 않는 번호",
    "option3": "지도 — 테이블 전체의 구조를 보여 주는 것",
    "option4": "다리 — 두 테이블을 이어 주는 연결값",
    "answerIndex": 1,
    "explanation": "섹션 3에서 기본키는 '학번'에 비유됩니다. 이름은 동명이인이 있을 수 있지만 학번은 절대 겹치지 않아 모든 줄을 유일하게 찍어낼 수 있기 때문이에요. 지도는 ERD, 다리는 중간 테이블의 비유입니다."
  },
  {
    "courseSlug": "data-modeling",
    "question": "1:N 관계(예: 멘토 1명이 수습 여러 명을 담당)를 테이블로 표현할 때, 코스가 알려 준 규칙으로 옳은 것은 무엇인가요?",
    "option1": "항상 N쪽(여럿 쪽) 테이블에 FK 한 칸을 둔다",
    "option2": "항상 1쪽 테이블에 담당 대상 칸을 개수만큼 늘려 간다",
    "option3": "두 테이블 사이에 반드시 중간 테이블을 새로 만든다",
    "option4": "양쪽 테이블 모두에 서로를 가리키는 FK를 하나씩 둔다",
    "answerIndex": 0,
    "explanation": "섹션 4의 규칙은 \"1:N에서는 항상 N쪽(여럿 쪽)에 FK를 둔다\"입니다. 1쪽에 '담당수습1, 담당수습2...' 칸을 늘리는 것은 섹션 6의 나쁜 설계 냄새 2에 해당하고, 중간 테이블은 N:M 관계에서 필요해요."
  },
  {
    "courseSlug": "data-modeling",
    "question": "코스에서 이메일을 기본키(PK)로 쓰지 말라고 한 핵심 이유는 무엇인가요?",
    "option1": "이메일은 문자열이라 숫자보다 검색 속도가 크게 느리기 때문",
    "option2": "이메일은 동명이인처럼 여러 사람이 겹칠 수 있는 값이기 때문",
    "option3": "이메일은 민감한 개인정보라 테이블에 저장하면 안 되기 때문",
    "option4": "이메일은 바뀔 수 있는 값이라, 바뀌면 그걸 가리키던 FK가 모두 흔들리기 때문",
    "answerIndex": 3,
    "explanation": "섹션 3의 경고 박스에서 이메일은 유일하긴 하지만 '바뀔 수 있는 값'이라 PK가 바뀌면 그걸 가리키던 모든 FK가 함께 흔들린다고 설명합니다. 그래서 PK는 의미 없는 번호(id)로 두는 것이 정석이에요."
  },
  {
    "courseSlug": "data-modeling",
    "question": "실습에서 '쪽지 기능'을 설계하던 수습이 한 쪽지를 여러 명에게 보내는 단체 쪽지까지 지원하기로 했습니다. 코스에서 배운 대로라면 가장 알맞은 설계는 무엇인가요?",
    "option1": "쪽지 테이블에 받는사람1, 받는사람2, 받는사람3 칸을 추가한다",
    "option2": "받는 사람들의 이메일을 쉼표로 이어 붙여 한 칸에 저장한다",
    "option3": "쪽지와 users 사이에 수신자 중간 테이블을 만들어 N:M로 잇는다",
    "option4": "받는 사람 수만큼 쪽지 제목과 내용을 통째로 복사해 저장한다",
    "answerIndex": 2,
    "explanation": "섹션 7의 '흔한 함정 미리보기'에서 단체 쪽지(한 쪽지 → 여러 수신자)는 N:M 관계이므로 섹션 4의 중간 테이블이 답이라고 알려 줍니다. 번호 붙은 칸의 행진과 한 칸에 여러 값은 섹션 6의 나쁜 설계 냄새예요."
  }
]
