579. 참조 무결성 제약 조건 (CASCADE, RESTRICT, SET NULL)

⚠️ 이 문서는 관계형 데이터베이스(RDBMS)에서 부모 테이블(예: 부서)과 자식 테이블(예: 사원)이 외래 키(Foreign Key)로 끈끈하게 연결되어 있을 때, **부모 테이블의 데이터가 갑자기 삭제되거나 변경될 경우, 허공에 붕 떠버려 고아가 될 위기에 처한 자식 데이터를 어떻게 처리할 것인지 컴퓨터에게 미리 명령해 두는 '연쇄 반응 규칙(참조 무결성 제약 조건)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "부모(부서)가 죽으면 자식(사원)은 어떻게 할래?"라는 질문에 대한 DBA(데이터베이스 관리자)의 결단이다. 이 규칙이 없으면 RDBMS의 핵심인 테이블 간의 데이터 정합성(참조 무결성)이 붕괴하여 쓰레기 고아 데이터가 양산된다.
  2. 가치: 앱 개발자가 자바(Java) 코드로 일일이 사원 테이블을 검색해 지우는 수고를 덜어준다. 데이터베이스 엔진 자체가 트리거(Trigger)처럼 자동으로 연쇄 작업을 수행하므로, 실수가 발생할 확률을 0%로 만들어 준다.
  3. 기술 체계: 부모가 지워지면 자식도 쿨하게 다 죽여버리는 CASCADE(연쇄 삭제), 자식이 한 명이라도 살아있으면 부모의 자살(삭제) 자체를 막아버리는 RESTRICT(삭제 금지), 부모가 죽으면 자식들의 부모 이름표만 떼서 백지(Null)로 만들어 고아원에 버리는 SET NULL이 대표적이다.

Ⅰ. 참조 무결성 (Referential Integrity)의 붕괴 위협

부모 없는 자식이 생겨나는 순간, 데이터베이스는 쓰레기장이 된다.

  1. 외래 키(Foreign Key)의 속박:
    • 부서(부모) 테이블에 [부서번호: 10, 부서명: 기획팀]이 있다.
    • 사원(자식) 테이블에 [사원명: 홍길동, 소속_부서번호: 10]이 있다. 여기서 10은 부모를 가리키는 외래 키다.
  2. 고아(Orphan) 데이터의 탄생:
    • 만약 회사가 '기획팀'을 통째로 날려버리기로 하고, 부서 테이블에서 10번 데이터를 과감하게 DELETE 해버렸다고 치자.
    • 이제 홍길동의 소속 부서번호 10은 세상에 존재하지 않는 유령 번호가 되었다.
    • 누군가 "홍길동의 부서 이름을 가져와라!"라고 조인(JOIN) 쿼리를 치면, 부모가 없으므로 검색이 실패하고 에러를 뿜는다. 이것이 **참조 무결성이 깨진 최악의 상태(고아 데이터 발생)**다.

📢 섹션 요약 비유: 도서관 대출 장부(자식 테이블)에 "홍길동이 해리포터를 빌려 감"이라고 적혀있습니다. 그런데 사서가 도서관 회원 명부(부모 테이블)에서 홍길동의 이름을 냅다 지워버렸습니다(DELETE). 이제 대출 장부에는 실존하지 않는 유령이 해리포터를 훔쳐 간 것으로 기록되어, 영원히 책을 돌려받을 수 없는 데이터 붕괴 사태가 벌어집니다.

Ⅱ. 3가지 심판의 규칙: 부모가 죽었을 때 자식의 운명

DB 생성 시 ON DELETE 또는 ON UPDATE 옵션에 적어주는 판결문이다.

  1. RESTRICT (제한/거부) - "자식이 살아있는 한 부모는 죽을 수 없다!" $\star$
    • 원리: 가장 깐깐하고 널리 쓰이는 국룰 방어막이다.
    • 부서 테이블에서 '10번 기획팀'을 지우려고 DELETE 버튼을 누른다.
    • DB 엔진이 즉시 자식(사원) 테이블을 뒤져본다. "어? 기획팀 소속인 홍길동이 아직 살아있네?"
    • DB는 그 즉시 부서 테이블의 DELETE 명령 자체를 빠꾸(에러) 쳐버린다. "참조 무결성 제약 조건 위반! 자식 데이터가 남아있어 부모를 지울 수 없습니다."
  2. CASCADE (연쇄 폭발) - "부모가 죽으면 자식도 다 같이 묻어라!"
    • 원리: 가장 무섭고 파괴적인 옵션이다. (ON DELETE CASCADE)
    • 부서 테이블에서 '10번 기획팀'을 DELETE 한다.
    • DB 엔진이 자식(사원) 테이블로 달려가서, 소속이 10번인 홍길동, 김철수, 이영희의 데이터 **줄(Row)을 모조리 몽땅 연쇄적으로 삭제(DELETE)**해 버린다. (개발자가 코드 한 줄 안 쳤는데도 알아서 삭제된다.)
    • 주의: '쇼핑몰 회원'을 탈퇴시켰다고 '결제 내역(자식)'까지 CASCADE로 다 날아가 버리면 회사가 망한다. 주로 '게시글'이 지워질 때 달린 '댓글'들을 한 방에 지우는 용도로만 쓴다.
  3. SET NULL (고아원 보내기) - "부모가 죽으면 호적만 백지로 파라!"
    • 원리: 부서를 지울 때, 사원의 데이터(줄) 자체는 삭제하지 않고 살려둔다. (ON DELETE SET NULL)
    • 대신 자식(홍길동)의 외래 키 컬럼인 소속_부서번호 칸의 숫자 10을 지우개로 지워버리고 **빈칸(NULL)**으로 덮어쓴다.
    • 홍길동은 사원 테이블에 살아남아 급여는 받을 수 있지만, 소속 부서가 없는 상태(부서 배정 대기 상태)가 된다.

📢 섹션 요약 비유: 쇼핑몰 사장님(부모)이 폐업 선언(DELETE)을 했습니다. RESTRICT는 "사장님, 당신 밑에 결제 안 끝난 직원(자식)이 한 명이라도 있으면 절대 폐업 신고를 받아줄 수 없습니다!"라고 멱살을 잡는 룰입니다. CASCADE는 사장님이 폐업하는 순간 건물 밑에 폭탄이 터져 직원들(자식)까지 전원 떼죽음을 당하는 잔인한 연쇄 폭발입니다. SET NULL은 사장님이 폐업하면, 직원들을 죽이진 않고 이마에 붙어있던 회사 배지만 뜯어낸 뒤(Null), 거리에 백수로 풀어주어 딴 회사로 갈 기회를 주는 자비로운 방식입니다.

Ⅲ. 업데이트(UPDATE) 상황에서의 무결성

부모가 지워지지 않고 이름표(PK)만 바꿀 때는 어떻게 할 것인가?

  1. ON UPDATE CASCADE의 마법:
    • 기획팀의 부서 번호(PK)가 10에서 99로 부득이하게 변경(UPDATE)되었다고 치자.
    • 이때 자식 테이블에 ON UPDATE CASCADE가 걸려있다면, 신기한 일이 벌어진다.
    • DB 엔진이 자식(사원) 테이블로 뛰어가서, 원래 10이라고 적혀있던 홍길동의 부서 번호를 자동으로 99로 싹 바꿔서 업데이트해 준다!
    • 고아 데이터가 생기지도 않고, 두 테이블의 연결(Link)이 0.1초 만에 최신 번호로 완벽히 갈아 끼워지는 기적의 자동화 연산이다.

📢 섹션 요약 비유: 부모님의 성씨(PK)가 '김'에서 '박'으로 강제 개명(UPDATE)되었습니다. 자식들의 주민등록등본에 적힌 아버지 성씨가 옛날 '김'씨로 남아있으면 호적(무결성)이 꼬입니다. ON UPDATE CASCADE 룰을 켜두면, 아버지가 동사무소에서 이름을 바꾸는 그 찰나의 순간, 전국에 흩어져 사는 자식들의 호적 등본에도 저절로 아버지 성씨가 '박'으로 싹 바뀌어 잉크가 마르는, 엄청난 행정력의 초자동화 시스템입니다.