데이터베이스 기본키 외래키 차이와 DB 문제 핵심 개념

관계형 데이터베이스의 표를 먼저 이해하기

테이블과 레코드와 필드의 역할을 구분하는 기본 원리

기본키와 외래키를 이해하려면 관계형 데이터베이스가 데이터를 어떤 단위로 저장하는지부터 정리해야 한다. 테이블은 하나의 주제에 관한 데이터를 모아 둔 구조이고, 행은 개별 대상을 나타내는 레코드이며, 열은 대상의 속성을 나타내는 필드다. 고객 테이블이라면 한 행은 한 명의 고객을 뜻하고 고객번호, 이름, 연락처 같은 열이 속성이 된다. 주문 테이블에서는 한 행이 한 건의 주문이고 주문번호, 고객번호, 주문일 같은 필드를 가질 수 있다. 고객과 주문을 한 테이블에 모두 반복해서 저장하지 않고 주제별로 나누는 이유는 중복을 줄이고 수정 과정의 불일치를 예방하기 위해서다.

테이블을 나누기만 하면 서로 관련된 정보를 함께 조회하기 어렵다. 그래서 두 테이블에 공통된 의미의 필드를 두고 관계를 설정한다. 고객 테이블의 고객번호와 주문 테이블의 고객번호를 연결하면 특정 고객이 어떤 주문을 했는지 찾을 수 있다. 이때 두 필드의 이름은 반드시 같아야 하는 것은 아니지만 서로 비교할 수 있는 데이터 형식과 같은 의미를 가져야 한다. 관계는 단순히 화면에 선을 그리는 작업이 아니라 어느 테이블의 레코드가 다른 테이블의 어떤 레코드와 연결되는지를 정의하는 규칙이다.

문제를 풀 때에는 먼저 각 테이블의 주제를 한 문장으로 정리한다. 다음으로 한 행을 유일하게 구별할 수 있는 필드를 찾고, 다른 테이블에서 그 값을 사용해 연결하는 필드를 찾는다. 고객번호처럼 이름에 ‘번호’가 붙었다고 항상 기본키가 되는 것은 아니다. 주문 테이블의 고객번호는 여러 주문에서 반복될 수 있으므로 외래키가 될 수 있다. 반대로 주문번호는 주문 한 건을 유일하게 구별한다면 주문 테이블의 기본키가 된다. 필드명보다 값의 유일성, 반복 가능성, 테이블 사이의 연결 방향을 살피는 것이 핵심이다.

기본키는 한 레코드를 유일하게 식별한다

중복과 빈 값을 허용하지 않는 이유와 복합키의 의미

기본키는 테이블 안의 각 레코드를 다른 레코드와 구별하는 기준이다. 고객 테이블에서 고객번호가 기본키라면 서로 다른 두 고객이 같은 고객번호를 가질 수 없고, 고객번호가 비어 있는 레코드도 허용할 수 없다. 값이 중복되거나 비어 있으면 특정 고객을 수정하거나 삭제하려 할 때 어느 행을 대상으로 해야 하는지 결정할 수 없기 때문이다. 이름, 주소, 전화번호처럼 현실에서 바뀌거나 중복될 가능성이 있는 값보다 변경 가능성이 낮고 유일성이 보장되는 식별자를 기본키로 선택하는 편이 안정적이다.

하나의 필드만으로 레코드를 구별하기 어려우면 둘 이상의 필드를 결합한 복합 기본키를 사용할 수 있다. 수강 테이블에서 학생번호만으로는 한 학생의 여러 과목 수강을 구별할 수 없고, 과목번호만으로도 여러 학생을 구별할 수 없다. 학생번호와 과목번호를 함께 묶으면 ‘어떤 학생이 어떤 과목을 수강한다’는 한 행을 유일하게 식별할 수 있다. 복합키를 구성하는 개별 필드에는 값이 반복될 수 있지만 두 값의 조합은 중복되어서는 안 된다. ‘기본키는 반드시 하나의 필드로만 구성된다’는 설명은 틀린 선지가 된다.

한 테이블에는 기본키 제약이 하나만 존재하지만 그 기본키가 여러 필드를 포함할 수 있다는 표현을 구별해야 한다. 또한 기본키를 설정하면 레코드의 식별과 관계 연결이 명확해지고 중복 입력을 방지하는 데 도움이 된다. Access에서는 일련번호 형식의 ID 필드를 기본키로 사용하는 경우가 많지만, 자동으로 증가하는 숫자만 기본키가 될 수 있는 것은 아니다. 업무 규칙상 고유성이 보장되는 코드나 여러 필드의 조합도 후보가 될 수 있다. 문제에서는 ‘유일하게 식별’, ‘중복 불가’, ‘Null 불가’, ‘둘 이상의 필드로 구성 가능’이라는 특징을 기본키와 연결해 판단한다.

외래키는 다른 테이블의 키를 참조한다

반복 가능한 연결값과 참조 대상의 관계를 이해하는 법

외래키는 한 테이블의 필드가 다른 테이블의 기본키나 고유한 키를 참조하도록 만든 연결 기준이다. 고객 테이블의 고객번호가 기본키이고 주문 테이블에도 고객번호가 있다면, 주문 테이블의 고객번호는 고객 테이블을 참조하는 외래키가 될 수 있다. 한 고객이 여러 주문을 할 수 있으므로 주문 테이블의 고객번호는 반복될 수 있다. 이 점이 값의 중복을 허용하지 않는 기본키와 가장 뚜렷한 차이다. 외래키의 역할은 주문 자체를 유일하게 구별하는 것이 아니라 각 주문이 어느 고객에게 속하는지 나타내는 것이다.

외래키 값이 비어 있을 수 있는지는 데이터베이스 설계와 필드의 필수 입력 조건에 따라 달라진다. 외래키라서 언제나 Null을 허용하거나 언제나 금지한다고 단정하면 안 된다. 주문에는 반드시 고객이 있어야 한다는 업무 규칙을 적용한다면 고객번호를 필수 값으로 만들 수 있다. 반대로 담당자가 아직 배정되지 않은 업무를 저장할 수 있도록 담당자번호를 비워 두는 설계도 가능하다. 다만 외래키에 실제 값이 들어 있다면 참조 무결성이 적용된 관계에서는 부모 테이블에 대응하는 값이 존재해야 한다. 존재하지 않는 고객번호로 주문을 등록하는 고아 레코드를 방지하는 것이 외래키 제약의 핵심이다.

하나의 필드는 상황에 따라 기본키이면서 외래키가 될 수도 있다. 예를 들어 회원 기본정보와 회원 상세정보를 일대일로 나눈 경우 상세 테이블의 회원번호가 상세 레코드를 유일하게 구별하면서 동시에 회원 테이블의 회원번호를 참조할 수 있다. 또한 한 테이블에 여러 외래키가 존재하는 것도 가능하다. 주문 테이블이 고객번호와 직원번호를 각각 고객 테이블과 직원 테이블에 연결할 수 있기 때문이다. 문제에서는 필드 이름만 보고 판단하지 말고 해당 테이블에서 값이 유일한지, 다른 테이블의 어떤 필드를 참조하는지, 값의 반복이 관계의 종류와 맞는지를 함께 살펴야 한다.

키를 연결하면 테이블 사이의 관계가 결정된다

일대일과 일대다 및 다대다 관계를 사례로 구별하기

일대다 관계는 한쪽 테이블의 레코드 하나가 다른 쪽의 여러 레코드와 연결되는 구조다. 고객 한 명이 여러 주문을 할 수 있다면 고객 테이블이 ‘일’ 쪽이고 주문 테이블이 ‘다’ 쪽이다. 일 쪽의 고객번호는 기본키로 유일하지만 다 쪽의 고객번호는 외래키로 반복될 수 있다. 시험 문제에서 기본키와 외래키가 연결된 그림이 나오면 연결 필드의 중복 가능성을 보고 어느 쪽이 일이고 어느 쪽이 다인지 판단할 수 있다. 주문마다 고객이 하나라는 조건과 고객 한 명이 주문을 여러 번 할 수 있다는 조건을 양쪽 방향으로 읽어 보는 것이 좋다.

일대일 관계는 한 테이블의 레코드 하나가 다른 테이블의 최대 한 레코드와 연결되는 구조다. 직원 기본정보와 직원 보안정보를 분리하되 각 직원에게 보안정보 행이 하나만 존재하도록 설계한 사례가 이에 해당할 수 있다. 양쪽 연결 필드에서 유일성이 유지되어야 하므로 외래키 쪽에도 중복을 막는 설정이 필요하다. 단순히 두 테이블이 한 필드로 연결되었다고 일대일이 되는 것이 아니다. 연결되는 값이 양쪽에서 얼마나 반복될 수 있는지를 확인해야 한다.

다대다 관계는 학생 여러 명이 여러 과목을 수강하는 것처럼 양쪽 모두 여러 레코드와 연결될 수 있는 구조다. 관계형 데이터베이스에서는 보통 학생 테이블과 과목 테이블을 직접 다대다로 연결하지 않고 수강 테이블 같은 연결 테이블을 둔다. 연결 테이블에는 학생번호와 과목번호가 각각 외래키로 들어가며, 두 필드의 조합을 복합 기본키로 설정할 수 있다. 그러면 동일 학생이 동일 과목에 중복 등록되는 일을 막으면서 한 학생의 여러 과목과 한 과목의 여러 학생을 모두 표현할 수 있다. 관계 문제에서는 ‘다대다를 두 개의 일대다 관계로 해소한다’는 구조와 연결 테이블의 역할을 기억하면 표를 빠르게 해석할 수 있다.

참조 무결성은 연결된 데이터의 일관성을 지킨다

입력과 수정과 삭제에서 허용 여부를 판단하는 기준

참조 무결성은 관련된 두 테이블 사이에서 외래키 값이 유효한 참조를 유지하도록 하는 규칙이다. 고객 테이블에 고객번호 100이 없다면 주문 테이블에 고객번호 100을 가진 주문을 새로 입력하지 못하게 하는 방식이 대표적이다. 부모 레코드가 없는 자식 레코드가 생기면 주문이 누구의 것인지 알 수 없으므로 관계의 의미가 깨진다. 참조 무결성은 모든 데이터 오류를 자동으로 해결하는 기능이 아니라 키로 연결된 값의 일관성을 보호하는 제약이다. 이름의 오타나 금액의 잘못된 입력까지 검증해 주는 것은 아니다.

부모 테이블의 기본키 값을 변경하거나 삭제하려 할 때도 연결된 자식 레코드가 있으면 문제가 생긴다. 기본 설정에서는 관련 레코드가 남아 있는 동안 부모 키의 변경이나 삭제가 제한될 수 있다. 관계 옵션에서 관련 필드 모두 업데이트를 적용하면 부모의 키가 바뀔 때 자식 테이블의 외래키도 함께 변경될 수 있다. 관련 레코드 모두 삭제를 적용하면 부모 레코드를 삭제할 때 연결된 자식 레코드도 함께 삭제될 수 있다. 이러한 연쇄 동작은 편리하지만 많은 자료가 한꺼번에 변경되거나 삭제될 수 있으므로 관계의 의미를 이해하고 적용해야 한다.

문제에서 작업 허용 여부를 묻는다면 먼저 어느 테이블이 부모이고 어느 테이블이 자식인지 표시한다. 부모에 존재하는 키를 자식 외래키로 입력하는 것은 가능하지만 존재하지 않는 키를 입력하는 것은 제한된다. 연결된 자식이 있는 부모 레코드의 삭제는 연쇄 삭제 설정 여부에 따라 결과가 달라진다. 자식 레코드를 먼저 삭제하는 것은 다른 제약이 없다면 부모 레코드를 직접 손상시키지 않는다. Null 허용 여부와 연쇄 옵션은 별도의 설정이므로 참조 무결성이라는 말만 보고 임의로 결론을 내리지 않는다. 선지에 제시된 조건을 하나씩 적용해야 정확한 답을 고를 수 있다.

기본키와 인덱스와 고유 제약을 혼동하지 않기

비슷한 기능을 가진 데이터베이스 개념의 차이 정리

기본키와 인덱스는 연관되어 있지만 같은 개념은 아니다. 기본키는 레코드를 유일하게 식별하고 중복과 Null을 허용하지 않는 논리적 제약이다. 인덱스는 데이터를 빠르게 찾거나 정렬하는 데 도움을 주는 구조이며 고유하지 않은 값에도 만들 수 있다. 데이터베이스 제품은 기본키를 설정할 때 검색을 지원하는 인덱스를 함께 구성하는 경우가 많지만, 인덱스가 있다고 해서 그 필드가 자동으로 기본키가 되는 것은 아니다. 시험에서 ‘인덱스는 반드시 중복을 허용하지 않는다’거나 ‘한 테이블에는 인덱스가 하나만 존재한다’는 식의 설명은 일반적인 인덱스의 성격과 맞지 않는다.

고유 제약도 중복 값을 막는다는 점에서 기본키와 비슷하지만 테이블의 대표 식별자로 지정되는 기본키와 역할이 다르다. 한 테이블에는 기본키가 하나이지만 업무상 중복되면 안 되는 다른 필드에는 고유 제약을 추가할 수 있다. 예를 들어 회원번호를 기본키로 사용하면서 이메일 주소에도 중복 금지 규칙을 둘 수 있다. Null 처리 방식은 데이터베이스 제품과 설정에 따라 세부 차이가 있을 수 있으므로 시험의 대상 프로그램과 조건을 확인해야 한다. 공통적인 판단 기준은 기본키가 레코드 식별의 중심이고, 고유 제약은 다른 후보 값의 중복을 제한한다는 점이다.

후보키는 레코드를 유일하게 식별할 수 있는 최소한의 속성 집합이며, 그중 실제 대표로 선택한 것이 기본키다. 선택되지 않은 후보키는 대체키로 설명될 수 있다. 슈퍼키는 유일하게 식별할 수 있지만 불필요한 속성을 더 포함할 수 있어 최소성을 반드시 만족하지는 않는다. 외래키는 이러한 식별 후보를 고르는 개념이 아니라 다른 테이블의 키를 참조하는 관계 개념이다. 문제를 풀 때 ‘유일성’, ‘최소성’, ‘대표로 선택’, ‘다른 테이블 참조’라는 표현을 각각 후보키, 기본키, 외래키와 연결해 보면 용어가 섞인 선지를 구별하기 쉬워진다.

DB 문제는 테이블 그림을 직접 표시하며 푼다

Access 관계 설정과 선지 판단을 위한 단계별 점검법

데이터베이스 문제에서 두 개 이상의 테이블이 제시되면 각 테이블의 기본키 후보에 먼저 표시한다. 한 행을 유일하게 구별할 수 있는지, 중복될 가능성이 있는지를 데이터 사례로 확인한다. 다음으로 같은 의미를 가진 필드를 찾아 부모와 자식 방향을 정한다. 고객 테이블의 고객번호에서 주문 테이블의 고객번호로 연결된다면 고객은 일 쪽, 주문은 다 쪽이 된다. 연결 필드의 데이터 형식도 호환되어야 한다. Access에서 자동 증가 형식의 기본키를 숫자 형식 외래키와 연결하는 경우처럼 화면에 보이는 값뿐 아니라 필드 크기와 형식의 대응을 살펴야 한다.

관계 설정 화면에서는 기본키가 있는 테이블의 필드를 관련 테이블의 대응 필드와 연결하고, 참조 무결성 및 연쇄 옵션의 선택 여부를 확인한다. 관계선에 표시되는 1과 무한대 기호는 일대다 관계의 방향을 보여 준다. 원하는 관계가 만들어지지 않으면 기본키나 고유 인덱스가 설정되었는지, 연결 필드의 형식이 맞는지, 기존 데이터에 고아 레코드가 있는지 점검한다. 이미 자식 테이블에 존재하지 않는 부모 키가 입력되어 있다면 참조 무결성을 바로 적용하지 못할 수 있다. 이때 옵션을 무작정 해제하기보다 잘못된 기존 데이터를 먼저 찾아 수정해야 한다.

선지형 문제는 문장을 키의 속성과 작업 결과로 나누어 판단한다. 기본키의 중복과 Null 허용 여부, 외래키의 반복 가능성, 복합키 구성 가능성, 부모 삭제 시 연쇄 옵션의 효과를 각각 따로 검토한다. 실습형 문제에서는 작은 고객·주문 표를 만들고 정상 입력, 존재하지 않는 고객번호 입력, 연결된 고객 삭제를 차례로 시도해 본다. 설정에 따라 어떤 메시지와 결과가 나타나는지 직접 확인하면 문장 암기보다 오래 기억된다. 마지막으로 기본키는 ‘행의 신원’, 외래키는 ‘다른 행과의 연결’, 참조 무결성은 ‘연결의 유효성’으로 요약하면 낯선 사례에서도 핵심 개념을 적용할 수 있다.