테이블·행·열·키·관계

데이터는 칸보다 의미와 연결이 먼저다

주문표에 고객 이름만 저장하면 이름이 같은 사람을 구분하기 어렵고, 고객 주소를 주문마다 반복하면 한 곳만 수정되어 값이 어긋날 수 있다. 관계형 데이터는 사실의 종류를 표로 나누고, 각 사실을 식별하는 키로 연결해 이런 혼란을 줄인다.

먼저 되짚기: 데이터 모델

데이터 모델은 현실의 대상·속성·관계·제약을 구조로 표현한다. 관계형 구조에서는 이 모델의 대상과 관계를 테이블·키·참조로 구체화한다.

테이블·행·열·키·관계

테이블은 같은 종류의 사실을 정해진 열로 표현한 집합이고, 행은 한 대상이나 사건의 기록, 열은 그 기록이 갖는 속성이다. 식별자(identifier, ID)는 여러 대상 중 하나를 다른 대상과 구별해 가리키는 값이다. 키는 하나 이상의 열을 사용해 행을 유일하게 식별하거나 다른 테이블의 행을 가리키는 제약과 역할을 맡는다. 따라서 모든 키는 식별에 쓰이지만, 화면의 임시 항목번호처럼 단지 구별에 쓰는 모든 ID가 곧 데이터베이스 키인 것은 아니다. 관계는 키를 통해 고객–주문처럼 서로 다른 사실이 어떤 의미로 연결되는지를 나타낸다.

주문과 고객을 연결해 보기

고객 테이블은 고객번호를 키로 이름과 연락처를 저장하고, 주문 테이블은 주문번호를 키로 주문시각과 금액을 저장한다. 주문 행의 고객번호가 고객 행을 가리키면 고객 정보를 매번 복사하지 않고도 주문 주체를 찾을 수 있다. 키 규칙은 중복을 막고, 존재하지 않는 고객을 주문이 가리키지 못하게 하는 검사 기준도 된다.

좋은 키와 관계를 판단하는 법

변하기 쉬운 이름이나 전화번호를 키로 쓰면 변경이 모든 연결에 번진다. 한 칸에 여러 값을 넣거나 서로 다른 사실을 한 표에 섞으면 검색과 갱신 규칙이 모호해진다. 키는 안정적이고 유일해야 하며, 관계의 방향·개수와 삭제할 때 남길 기록을 업무규칙으로 정해야 한다.

키는 행을 구별하고 관계의 양 끝을 잇는다

기본키는 각 행을 유일하게 가리키고 외래키는 같거나 다른 테이블의 참조 가능한 후보키나 유일키를 참조한다. 도식의 1과 N은 한 대상과 여러 대상이라는 최대 연결수를 나타낸다. 이 예에서는 주문의 고객번호를 필수로 정해 한 주문이 정확히 한 고객을 가리키지만, 고객은 주문이 전혀 없거나 여러 건 있을 수 있다. 따라서 고객 한 명의 주문 수는 0..N이며, 외래키만 선언했다고 모든 고객에게 주문이 적어도 한 건 생기는 것은 아니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

고객 C17(민수)을 주문 O901의 필수 고객번호 C17이 참조한다. 한 고객의 주문은 0..N건, 주문 1건의 고객은 정확히 1명이다. 화살표는 자식 외래키에서 부모 키로 향하는 참조이며 삭제·변경 정책은 별도 규칙이다.

고객 1명은 주문 여러 건을 만들 수 있고 주문 1건은 고객 1명에 속한다는 개수와 필수 여부가 관계의 업무 의미다. 외래키 값만 있다고 관계가 완성되는 것이 아니라 삭제·변경 시 허용 동작도 정해야 한다.

키의 역할과 값의 출처를 섞지 않는다

자연키는 이메일처럼 업무에서 이미 의미 있는 값이고, 대리키는 시스템이 별도로 생성한 번호처럼 식별을 위해 도입한 값이다. 자연/대리는 값의 출처에 관한 분류이고 기본/외래는 관계에서 맡는 역할이므로 같은 축이 아니다.

{고객번호, 이름}에서 이름을 빼도 고객번호만으로 유일하므로 슈퍼키이지만 최소가 아니어서 후보키가 아니다. 반대로 주문항목에서 {주문번호, 줄번호}가 키라면 둘 중 하나를 빼서 중복이 생기는지 각각 확인한다. 표본에서 우연히 유일한 것과 모든 허용 데이터의 업무 규칙은 구분한다.

외래키는 자기참조도 가능하다. 예를 들어 직원 표의 관리자번호가 같은 직원 표의 직원번호를 참조할 수 있다. 외래키만으로 관리자 순환이나 자기 자신을 관리자로 지정하는 모든 업무 오류까지 차단하는 것은 아니다. SQL의 NULL은 값이 알려지지 않음·없음을 표현하므로 필수 여부는 별도로 정한다. PostgreSQL 18의 기본 UNIQUE는 여러 NULL을 허용할 수 있어, 이메일을 후보키처럼 필수·유일하게 쓰려면 이 예에서는 UNIQUE와 NOT NULL을 함께 둔다. UNIQUE는 같은 값의 중복을 막는 유일 제약이고 NOT NULL은 NULL을 금지하는 필수값 제약이다. 따라서 이 사례의 이메일은 값이 반드시 있어야 하고 다른 고객의 이메일과 같아도 안 된다.

기본키는 유일성뿐 아니라 안정성과 단순성을 본다

후보키를 찾을 때 현실 업무에서 정말 중복이 금지되는지, 빈값이 가능한지, 시간이 지나도 바뀌지 않는지 확인한다. 자연키가 길거나 변경 가능하면 짧고 안정적인 대리키를 기본키로 두되 자연키의 유일 제약을 없애서는 안 된다. 관계는 한 고객–여러 주문 같은 개수, 필수/선택 여부, 대상 삭제 시 거절·함께 삭제·이력 보존 중 어떤 규칙을 쓸지 결정한다. 대리키가 있다고 중복 고객이라는 업무 오류가 자동으로 사라지는 것은 아니다.

사례: 동명이인 2명과 주문 3건

이름이 김민수인 고객이 2명이고 각각 주문이 2건, 1건 있다고 하자. 이름을 기본키로 쓰면 두 사람을 구별할 수 없다. 고객번호 C17, C52를 기본키로 두고 주문번호 O1~O3을 주문 기본키로 둔다. 주문의 고객번호는 고객 외래키가 되어 C17 두 건과 C52 한 건을 정확히 연결한다. 이메일이 업무상 유일하더라도 변경 가능하면 대체키 유일 제약으로 관리할 수 있다. 고객 삭제 시 주문 이력을 보존해야 한다면 참조가 남은 고객 삭제를 막거나 별도 익명화 정책을 적용한다.

이 사례에서는 고객번호는 필수 기본키, 이메일은 필수·유일 대체키, 주문의 고객번호는 필수 외래키로 선택한다. 주문이 남은 고객의 삭제는 거절한다.

삭제 거절과 익명화는 같은 동작이 아니다. 필요한 보존·개인정보 정책이 정해지기 전에 외래키 삭제 전파로 주문 이력을 지우지 않는다.

자체 10점 문제

관계형 데이터의 테이블·키·관계를 설명하고 키 선정 및 참조무결성 고려사항을 제시하시오.

요구어는 설명, 제시다. 슈퍼키–후보키–기본/대체키의 포함관계와 외래키 역할을 구분한다. 이어 자연키·대리키 선택축, 관계 개수·필수성·삭제 규칙을 동명이인 주문 사례에 대입한다.

10점 풀이 방향과 모범답안 보기

답안 목차: 구조–키–관계–제약

1. 테이블·행·열·식별자·관계 정의
2. 슈퍼키·후보키·기본키·대체키·외래키 비교
3. 자연키와 대리키의 안정성·의미·운영비용 판단
4. 관계의 개수·필수 여부와 외래키 연결 흐름
5. 중복·고아참조·변경·삭제 실패와 무결성 통제

답안 도식: 키의 포함관계와 참조

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

유일 식별 열 집합인 슈퍼키 중 불필요한 열이 없는 최소 집합이 후보키다. 후보키 중 대표로 선택한 것은 기본키, 선택하지 않은 나머지는 대체키이며 유일성은 계속 유지한다. 외래키의 부모 참조는 앞 고객–주문 그림의 별도 관계다.

자식 외래키는 부모의 참조 가능한 후보키·유일키를 가리킨다. 부모 키에는 유일성·필수성 규칙, 자식 참조에는 존재·삭제·변경 규칙을 함께 확인한다. 앞의 고객–주문 참조 그림과 연결해 두 관계를 구분한다.

모범답안 축약본

테이블은 같은 종류의 사실을 열 구조로 표현한 행의 집합이고, 식별자는 대상을 구별해 가리키는 값이다. 슈퍼키는 행을 유일하게 구별하는 열 집합, 후보키는 그중 최소 집합, 기본키는 대표로 선택한 후보키, 대체키는 나머지 후보키다. 외래키는 같거나 다른 테이블의 참조 가능한 후보키나 유일키를 참조해 관계를 잇는다. 자연키와 대리키는 값의 출처, 기본키와 외래키는 역할의 분류이므로 구분한다. 키는 실제 유일성, 빈값, 변경 가능성, 길이와 업무 의미로 선택하고 대리키를 써도 자연 업무키의 유일 제약을 유지한다. 관계에는 개수·필수 여부와 삭제·변경 규칙을 명시해 중복 식별과 존재하지 않는 부모를 가리키는 고아참조를 막는다.

자체 25점 문제

고객·주문 데이터에서 안정적인 키와 참조 관계를 설계하고, 키 변경·삭제·중복 위험을 검증하는 절차를 제시하시오.

요구어는 설계, 검증, 제시다. 키 종류를 나열하는 데서 끝내지 않고 업무상 유일성·변경 가능성·관계 필수성·삭제 규칙을 실제 데이터 흐름에 연결한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 고객·주문 대상과 식별 요구
2. 후보키와 기본키 선정
3. 자연키·대리키 비교
4. 주문 외래키와 관계 개수·필수성
5. 대체키 유일 제약
6. 삭제·변경·이력 정책
7. 중복·고아참조 검증
8. 경계 사례와 운영 점검

25점 답안 도식

키 선택 그림과 고객–주문 참조 그림을 다음 검증표에 대입한다.

연결한 키	반드시 검증할 규칙
고객 후보키에서 선택한 기본키 C17	고객을 안정적·유일하게 식별
선택하지 않은 대체키	유일성 유지, 변경·중복 검사
고객 키를 참조하는 주문 외래키	부모 존재, 삭제·이력 보존 규칙

25점 모범답안

고객과 주문을 별도 대상으로 두고 각 행을 안정적으로 식별할 후보키를 먼저 찾는다. 이름은 동명이인이 있으므로 고객 기본키로 쓰지 않고 고객번호 같은 안정적 식별자를 둔다. 이메일이 업무상 유일하더라도 변경 가능하면 기본키와 별개인 대체키 유일 제약으로 보존한다.

주문은 주문번호를 기본키로 두고 고객번호를 외래키로 참조해 주문이 어느 고객에 속하는지 표현한다. 관계가 필수인지 선택인지, 한 고객이 여러 주문을 가질 수 있는지, 고객 삭제 시 주문 이력을 유지할지 명시한다. 이력을 보존해야 하면 참조가 남은 고객의 물리 삭제를 막거나 비식별화 정책을 둔다.

검증은 동명이인, 중복 이메일, 존재하지 않는 고객번호, 기본키·대체키 변경, 부모 삭제와 대량 이력 보존을 포함한다. 대리키를 쓴다는 이유로 업무상 유일성 검사를 없애지 않고, 키 변경이 참조와 외부 계약에 미치는 영향까지 확인한다. 테이블·키·관계 설계는 데이터베이스 설계의 선수 구조로 사용하되 물리 저장구조 선택과는 구분한다.

출처와 적용 경계

테이블·후보키·기본키·외래키·관계의 구분은 안정된 관계형 데이터 기초개념이다. C17·C52와 O1~O3은 식별·참조를 연습하기 위한 자체 사례이며 특정 DBMS의 물리 구현이나 삭제정책을 뜻하지 않는다.

PostgreSQL 18 제약조건 문서의 기본키·유일성·외래키·NULL 규칙을 구현 사례의 근거로 참고한다. 이 사례에서 필수 참조는 외래키와 NOT NULL을 함께 적용하는 선택이며, SQL 제품마다 NULL의 유일성 처리 등이 다를 수 있다.

자기교정과 조건 변경

이메일을 변경할 수 없도록 규칙이 바뀌면? 자연키 후보로 평가할 수 있지만 길이·외부 노출·업무 의미와 운영변경 가능성을 다시 본다.

한 주문을 여러 고객이 공동 소유할 수 있다면? 주문의 고객번호 한 칸으로 표현하지 말고 주문–고객 연결관계와 그 관계의 키를 별도로 모델링한다.

고객 삭제 뒤 주문은 5년 보존해야 한다면? 참조 이력을 깨지 않도록 삭제 제한·비식별화·별도 이력키 중 정책을 명시한다.

한 번에 되찾기

테이블은 같은 종류의 사실, 행은 한 기록, 열은 속성이다. 키는 행을 식별하고 테이블 사이 관계를 연결하며, 안정성·유일성·참조 규칙이 데이터 품질을 좌우한다.