데이터베이스 레포트 - 2개 이상의 테이블에 외래키를 선언하여 관계를 만들었을 때 발생할 수 있는 문제와 해결 방법을

I. 서론

데이터베이스 실습에서 회원 테이블과 주문 테이블을 연결했을 때 처음에는 외래키가 매우 편한 기능처럼 느껴졌다. 주문 테이블의 회원번호가 회원 테이블에 실제로 존재하는 값만 가리키게 하면 잘못된 주문 데이터가 들어가는 일을 막을 수 있기 때문이다. 문제는 테이블이 2개를 지나 3개, 4개로 늘어날 때부터 생겼다. 회원을 삭제하려고 했더니 주문 때문에 거부되고, 주문을 지우려니 결제 기록이 걸리며, 연쇄 삭제를 켜자 생각보다 넓은 범위의 데이터가 함께 사라질 수 있었다. 외래키는 관계형 데이터베이스의 참조 무결성을 지켜 주는 강한 장치이지만 관계를 어떻게 설계하느냐에 따라 삭제 실패, 순환 참조, 연쇄 작업, 잠금과 성능 문제까지 만들 수 있다. 따라서 외래키를 많이 선언하는 것보다 각 관계가 실제 업무에서 어떤 생명주기를 가지는지 먼저 이해하는 편이 중요하다.

II. 본론

1) 부모와 자식 테이블 사이에서 생기는 참조 무결성 문제

외래키의 기본 목적은 자식 테이블의 값이 부모 테이블의 유효한 키를 가리키도록 보장하는 것이다. 예를 들어 회원 테이블에 회원번호 101이 있고 주문 테이블의 회원번호가 101을 참조하면 두 데이터는 관계를 가진다. 여기서 주문 테이블에 회원번호 999를 넣으려는데 회원 테이블에 999가 없다면 데이터베이스는 입력을 거부한다. 이런 제약이 없다면 주문은 존재하지만 누구의 주문인지 알 수 없는 고아 데이터가 생길 수 있다. Microsoft SQL Server 공식 문서도 외래키가 부모와 자식 데이터 사이의 참조 무결성을 유지하며, 부모 키 변경이 관계를 깨뜨릴 때 작업을 막는다고 설명한다.

문제는 개발자가 외래키 제약을 오류처럼 느끼기 시작할 때다. 회원 탈퇴 기능을 만들면서 회원 행을 바로 삭제했는데 주문 테이블이 회원을 참조하고 있으면 삭제가 실패한다. 초보 단계에서는 "외래키 때문에 삭제가 안 된다"고 생각하기 쉽지만 실제로는 데이터베이스가 설계상의 질문을 던지는 것이다. 주문 이력이 남아 있는데 회원이라는 원인이 사라져도 되는가, 주문 이력을 법적 또는 회계상 보관해야 하는가, 회원 개인정보만 지우고 식별용 키는 남겨야 하는가를 결정해야 한다. 외래키 오류를 없애기 전에 데이터의 생명주기를 정해야 한다.

전자상거래를 예로 들면 회원, 주문, 주문상세, 결제, 배송 테이블이 연속으로 연결될 수 있다. 주문은 회원을 참조하고, 주문상세는 주문을 참조하며, 결제와 배송도 주문을 참조한다. 회원이 탈퇴했다고 주문 기록까지 모두 없어져야 하는 구조라면 연쇄 삭제를 고려할 수 있다. 반대로 거래 기록을 보관해야 한다면 회원 행을 물리적으로 삭제하지 않고 탈퇴 상태로 바꾸거나 개인정보 컬럼을 별도 정책에 따라 비식별화하는 방식이 더 적절할 수 있다. 데이터베이스 제약은 업무 규칙을 대신 결정하지 않는다.