3-5 연습 문제 — 값을 따라가
연결된 행을 찾습니다

①·②·④는 자식에서 부모로 가는 방향입니다. 자식 행의 외래키 값을 들고 부모 테이블의 기본키를 찾아가면 됩니다 — 답은 언제나 한 행이에요. 부모의 기본키는 중복이 없으니까요.

③은 방향이 반대라서 조금 다릅니다. 부모(이영희)에서 출발해 그 번호를 가리키고 있는 자식 행들을 모으는 겁니다. 이쪽은 답이 여러 행일 수 있어요 — 한 부모를 여러 자식이 가리킬 수 있으니까요.

여기서 얻어갈 게 두 가지 있습니다.

첫째, order_items 는 자식 역할을 두 번 합니다. 부모가 orders 와 products 둘이에요. 한 테이블이 외래키를 여러 개 가질 수 있습니다.

둘째, orders 는 members 의 자식이면서 동시에 order_items 의 부모입니다. 부모·자식은 테이블에 영구히 붙은 신분이 아니라 — 관계 하나하나마다 정해지는 역할이에요.

①과 ④는 같은 규칙입니다. 테이블만 다를 뿐, 둘 다 존재하지 않는 부모를 가리키려 한 시도예요. 여기서 꼭 짚을 것 — 잘못된 값이 저장된 뒤에 문제가 되는 게 아니라, 저장 자체가 거부됩니다. 참조 무결성은 사후 점검이 아니라 사전 차단이에요.

②와 ③의 차이가 삭제 규칙의 전부입니다. 가리키는 자식이 있으면 부모를 지울 수 없고, 없으면 지울 수 있습니다. 백서윤이 삭제 가능한 이유는 특별해서가 아니라 그저 자식이 없어서예요.

⑤가 오늘의 함정입니다. 차단되는 건 맞지만 이유가 다릅니다. 외래키가 NULL 을 금지하는 게 아니라, 우리가 이 컬럼을 NOT NULL 로 정했기 때문이에요. 만약 NULL 을 허용하도록 설계된 외래키 컬럼이라면 “아직 연결된 부모가 없다” 는 뜻으로 비워둘 수 있습니다.

① — 연결을 만드는 건 이름이 아니라 규칙입니다.

설계도에 이 한 줄이 실제로 있어야 합니다.

CONSTRAINT fk_orders_member
  FOREIGN KEY (member_id) REFERENCES members(member_id)

이 규칙이 없으면 데이터베이스가 아는 건 “두 컬럼의 이름이 같다” 는 사실뿐이라, 999를 넣어도 막아주지 않습니다. 그리고 반대도 성립해요 — 컬럼 이름이 서로 달라도 FOREIGN KEY 규칙으로 연결할 수 있습니다.

② — 외래키와 NOT NULL 은 별개의 약속입니다.

외래키가 NULL 을 허용하도록 설계됐다면 “아직 연결된 부모가 없다” 는 뜻으로 비워둘 수 있습니다. 우리 orders.member_id 를 비울 수 없는 건 그 컬럼에 NOT NULL 을 따로 걸어두었기 때문이에요.

③ — 순서를 정확히 기억하세요.

데이터베이스는 저장하기 전에 부모 테이블을 확인합니다. 999번 회원이 없으면 그 자리에서 오류를 내고 거부해요. “잘못된 데이터가 들어간 뒤 나중에 깨진다” 가 아니라 “애초에 들어가지 못한다” 입니다.

④ — 가입만 하고 주문하지 않은 회원은 정상입니다.

20번 백서윤 회원은 members 에는 있지만 주문이 없습니다. 오류도, 누락도 아니에요. 자식이 부모 없이 존재할 수 없을 뿐, 부모는 자식 없이 얼마든지 존재할 수 있습니다.

⑤ — 한 테이블이 두 역할을 겸합니다.

orders.member_id 로 보면 orders 는 자식이고, order_items.order_id 로 보면 orders 는 부모입니다. 그래서 주문 1번을 지우려 하면 order_items 때문에 차단돼요.

⑥ — 다만 문법적으로는 다른 선택지도 있습니다.

외래키가 UNIQUE 처럼 중복을 허용하지 않는 다른 키를 참조할 수도 있습니다. 우리 샘플 DB 가 전부 기본키를 가리키고 있을 뿐이에요. 입문 단계에서는 이 구조부터 확실히 익히면 충분합니다.