3-1 연습 문제 — 표를 읽는 눈,
한 행의 주인공부터 찾습니다
이번 강의에서 배운 것 — 테이블 · 행 · 열 · 값, 그리고 스키마와 데이터의 차이. 오늘은 SQL을 한 줄도 쓰지 않습니다. 대신 표 세 개를 눈으로 읽고 "이 한 줄이 무엇 하나를 나타내는가" 를 직접 판단해 보세요. 이 감각이 잡히면 앞으로 처음 보는 테이블도 훨씬 편해집니다.
섹션 3 에서의 위치
완료 ✓
강의 완료 ✓
지금 여기
컬럼 · 타입 · 키 · 테이블 만들기
2-4에서 만든 AI 과외 선생님 세션을 그대로 쓰세요. 이번엔 SQL이 아니라 본인의 판단을 검증받는 연습입니다. 문제를 먼저 스스로 풀고 — 그다음 “orders 테이블에서 한 행의 주인공은 주문 한 건이라고 생각했는데 맞아? 왜 그런지도 설명해줘” 처럼 이유까지 물어보세요.
문제 1. orders — 이 한 줄의 주인공은?
우리 실습 DB의 orders 테이블 일부입니다.
| order_id | member_id | ordered_at |
|---|---|---|
| 1 | 1 | 2025-02-01 |
| 2 | 2 | 2025-02-15 |
| 3 | 3 | 2025-03-01 |
세 가지에 답해보세요.
- 이 테이블에서 한 행의 주인공은 무엇인가요?
member_id는 행·열·값 중 무엇인가요? 그리고 첫 줄의member_id칸에 있는1은 무엇인가요?- 행 안에 회원 번호가 들어 있는데도, 주인공이 회원이 아닌 이유는 무엇인가요?
정답 보기
1. 한 행의 주인공 — 주문 한 건
orders 의 한 줄은 주문 한 건을 나타냅니다. 첫 줄은 “1번 주문은, 1번 회원이, 2025-02-01 에 했다”는 기록 한 세트예요.
2. member_id 는 열(column), 1 은 값(value)
member_id 는 모든 주문에게 던지는 같은 질문 — “이 주문은 누가 했나요?” — 이므로 열입니다. 그 질문에 대한 첫 번째 주문의 실제 답이 1 이므로, 이건 값이고요.
3. 행 안에 무엇이 들어 있느냐 ≠ 주인공
회원 번호는 그 주문에 대해 기록한 여러 정보 중 하나일 뿐입니다. 판단 기준은 이 한 줄이 무엇 하나를 나타내는가 예요. 이 줄이 없어지면 사라지는 건 회원이 아니라 주문 한 건이죠 — 그래서 주인공은 주문입니다.
문제 2. order_items — 같은 주문 번호가 두 번 나옵니다
이번엔 조금 더 까다로운 표입니다. order_items (주문상세) 의 앞부분이에요.
| order_id | product_id | quantity |
|---|---|---|
| 1 | 1 | 1 |
| 1 | 16 | 2 |
| 2 | 22 | 1 |
- 이 테이블에서 한 행의 주인공은 무엇인가요? (주문 한 건도, 상품 한 개도 아닙니다)
order_id가1인 줄이 두 개인 이유는 무엇인가요?
1번 주문의 두 줄을 소리 내어 읽어보세요. “1번 주문에 1번 상품이 1개”, “1번 주문에 16번 상품이 2개”. 두 줄이 각각 무엇 하나씩을 말하고 있나요?
정답 보기
1. 한 행의 주인공 — “어떤 주문에 담긴 상품 한 종류”
한 줄이 주문 한 건이라면 1번 주문이 두 줄일 리 없고, 상품 한 개라면 수량이 따로 있을 이유가 없죠. 이 테이블의 한 줄은 “어떤 주문에, 어떤 상품이, 몇 개 담겼는가” 라는 기록 한 세트입니다. 장바구니에 담긴 품목 한 줄을 떠올리면 딱 맞아요.
2. 1번 주문에 상품이 두 종류 담겼기 때문
김철수의 1번 주문에는 라운드 티셔츠 1개와 프리미엄 그래놀라 2개가 함께 담겼습니다. 주인공이 “담긴 상품 한 종류”이므로 — 상품이 두 종류면 줄도 두 개가 되는 게 자연스럽습니다.
주문 40건인데 주문상세는 64줄입니다. 두 표의 줄 수가 다른 건 오류가 아니라 — 주인공이 서로 다르기 때문이에요. 표마다 주인공을 먼저 확인해야 하는 이유가 바로 이겁니다.
문제 3 (도전). 스키마가 바뀐 걸까, 데이터가 바뀐 걸까
members 테이블에 아래 다섯 가지 일이 각각 따로 일어났다고 해봅시다. 하나씩 스키마 변경인지 데이터 변경인지 구분하세요.
| # | 일어난 일 |
|---|---|
| ① | 한지우 회원이 새로 가입해 가로 한 줄이 추가됐다 |
| ② | 회원마다 별명을 기록하려고 nickname 열을 새로 만들었다 |
| ③ | 김철수의 나이가 35에서 36으로 바뀌었다 |
| ④ | 가입일 칸은 반드시 채우도록 규칙을 정했다 |
| ⑤ | 회원 20명을 전부 삭제해 표가 텅 비었다 |
정답 보기
| # | 일어난 일 | 답 | 이유 |
|---|---|---|---|
| ① | 새 회원 한 줄 추가 | 데이터 | 설계도는 그대로, 채워진 내용만 늘었습니다 |
| ② | nickname 열 추가 | 스키마 | 기록할 항목 자체가 늘었습니다 — 설계도가 바뀐 것 |
| ③ | 나이 35 → 36 | 데이터 | 한 칸의 값만 달라졌습니다 |
| ④ | 가입일 필수 규칙 | 스키마 | 열 이름은 그대로지만 규칙이 추가됐습니다 |
| ⑤ | 회원 전부 삭제 | 데이터 | 값이 다 사라져도 항목과 규칙은 남습니다 — 빈 설계도인 상태 |
⑤ 가 가장 헷갈립니다. 표가 텅 비면 테이블이 없어진 것 아닌가 싶지만 — 강의에서 값을 전부 지웠을 때 헤더가 그대로 남았던 것과 똑같은 상태예요. 데이터는 0건, 스키마는 그대로.
④ 도 짚고 갈 만합니다. 스키마에는 열의 이름만 들어가는 게 아니라 “이 칸은 반드시 채워야 한다” 같은 규칙도 함께 들어갑니다. 그 규칙들이 바로 3-2부터 배울 내용이에요.
다 풀었다면
처음 보는 표를 만났을 때, 컬럼 이름을 읽기 전에 “한 행의 주인공은?”부터 묻게 됐다면 — 오늘 목표는 달성입니다. 이 질문 하나가 앞으로 모델링과 SQL 전체를 지탱합니다.
2-2에서 연결해둔 DBeaver 좌측 트리에서 shop → Tables 를 펼치고 테이블을
더블클릭한 뒤 Data 탭을 열어보세요. SQL을 한 줄도 쓰지 않고 실제 표를 볼
수 있습니다. products 와 categories 에도 오늘의 질문을 던져보세요 — 한
행의 주인공은 무엇인가?
열이 같은 질문이라면 아무 값이나 넣어도 되는 걸까요? 다음 강의에서는 컬럼마다 어떤 약속이 필요한지를 다룹니다.