릴레이션이라는 이름의 정체

왜 필요한가

05편에서 집합론을 다시 짚은 이유가 여기서 바로 쓰인다. SQL을 다루다 보면 “테이블(table)“이라는 말에 너무 익숙해져서, 그 뒤에 있는 수학적 정의를 건너뛰기 쉽다. 그런데 독학사 4단계는 “테이블을 다룰 줄 아는가”가 아니라 “관계 데이터 모델(relational data model)의 이론적 정의를 정확히 아는가”를 묻는다. 예를 들어 “릴레이션의 튜플 사이에는 순서가 있다”거나 “하나의 속성에 여러 값이 들어갈 수 있다”처럼 틀린 진술을 정답처럼 위장한 보기가 자주 나오는데, 정의를 정확히 알지 못하면 이런 함정을 골라내지 못한다.

쉽게 말하면: 릴레이션은 “정해진 열(속성)을 가진, 순서 없고 중복 없는 행(튜플)들의 집합”이다.

정의

릴레이션(relation)은 관계 데이터 모델에서 데이터를 저장하는 기본 구조로, SQL의 테이블(table)에 대응한다. 릴레이션을 정의하려면 먼저 아래 다섯 가지 용어를 순서대로 알아야 한다.

1. 도메인(domain): 어떤 속성이 가질 수 있는 값들의 집합이다. 예를 들어 “학년” 속성의 도메인은 {1, 2, 3, 4}라는 정수 집합이고, “이름” 속성의 도메인은 한글 20자 이내의 문자열 집합이다. 도메인은 그 값이 “어떤 종류의 데이터인지”를 규정하는 틀이다.
2. 속성(attribute): 릴레이션을 구성하는 열(column) 하나를 가리키는 이름이다. 각 속성은 반드시 하나의 도메인에 대응한다. 예를 들어 STUDENT 릴레이션의 “학번”, “이름”, “학년”이 각각 속성이다.
3. 튜플(tuple): 각 속성에 실제 값이 채워진 하나의 행(row)이다. 예를 들어 (20240001, '김민준', 2)처럼 속성 값들의 순서 있는 나열이 튜플 하나다.
4. 릴레이션 스키마(relation schema): 릴레이션의 이름과 그 릴레이션을 구성하는 속성들의 집합을 정의한 틀이다. STUDENT(학번, 이름, 학년)처럼 표기하며, 실제 데이터가 채워지기 전의 “설계도”에 해당한다.
5. 릴레이션 인스턴스(relation instance): 어떤 시점에 릴레이션 스키마에 실제로 채워져 있는 튜플들의 집합이다. 흔히 “릴레이션”이라고 하면 이 인스턴스를 가리킨다.

이제 릴레이션을 정식으로 정의할 수 있다. 릴레이션은 릴레이션 스키마 $R(A_1, A_2, \ldots, A_n)$에 대해, 각 속성 $A_i$의 도메인을 $D_i$라 할 때 $D_1 \times D_2 \times \cdots \times D_n$(05편의 카티전 곱)의 부분집합이다. 즉 릴레이션은 “가능한 모든 속성값 조합” 중에서 실제로 존재하는 튜플들만 모아 놓은 튜플의 집합이다.

이 정의에서 두 가지 중요한 성질이 바로 따라 나온다. 05편에서 다룬 “집합에는 중복과 순서가 없다”는 성질이 릴레이션에도 그대로 적용되기 때문이다.

• 튜플의 중복이 없다. 릴레이션은 집합이므로, 완전히 같은 값을 가진 튜플이 두 번 이상 존재할 수 없다. 이 성질이 뒤에서 다룰 기본키(primary key)가 반드시 필요한 이유의 근거가 된다.
• 튜플 사이에 순서가 없다. 어떤 튜플이 몇 번째 행에 있는지는 릴레이션의 정의에 포함되지 않는다. SQL에서 ORDER BY 없이 조회한 결과의 행 순서를 보장할 수 없는 이유가 여기에 있다.

여기에 한 가지 성질이 더해진다.

• 속성 값은 원자값(atomic value)이어야 한다. 하나의 속성 칸에는 더는 쪼갤 수 없는 단일 값만 들어가야 하며, 목록이나 여러 값을 한 칸에 넣을 수 없다. 이 조건을 만족하지 못하는 릴레이션을 비정규 릴레이션(unnormalized relation)이라 하며, 16편에서 다룰 제1정규형(1NF)의 출발점이 된다.

작은 예시

아래는 대학교의 학생 정보를 담은 STUDENT 릴레이션의 예다.

이 표에서 “학번, 이름, 학년, 학과”는 속성이고, 각 행(예: (20240001, '김민준', 2, '컴퓨터공학'))은 튜플이며, STUDENT(학번, 이름, 학년, 학과)는 릴레이션 스키마다.

차수와 기수

차수(degree)는 릴레이션이 가진 속성의 개수다. STUDENT 릴레이션은 학번·이름·학년·학과 네 개의 속성을 가지므로 차수는 4다. 기수(cardinality)는 릴레이션에 실제로 들어 있는 튜플의 개수다. 위 예시는 튜플이 4개이므로 기수는 4다. 차수는 릴레이션 스키마가 정해지면 (열을 추가·삭제하기 전까지는) 고정되지만, 기수는 데이터가 삽입·삭제될 때마다 계속 바뀐다는 점에서 두 개념의 성격이 다르다.

자주 틀리는 점

키의 종류: 슈퍼키에서 외래키까지

왜 필요한가

릴레이션에 중복 튜플이 없다는 성질을 실제로 보장하려면, “이 릴레이션에서 튜플 하나를 유일하게 구별해 주는 속성(들의 조합)“이 무엇인지 정해야 한다. 이 역할을 하는 속성 조합을 통틀어 키(key)라 부르며, 독학사 시험에서는 슈퍼키·후보키·기본키·대체키·외래키 다섯 가지를 정의만이 아니라 실제 테이블에서 골라내는 문제로 자주 낸다.

쉽게 말하면: 키는 “이 값(들)을 알면 튜플을 한 개로 딱 찍어낼 수 있는 속성 조합”이다. 다섯 가지 키는 그 조합을 고르는 기준이 서로 다를 뿐이다.

정의

아래 STUDENT 릴레이션을 예로 각 키를 정의한다. 이 릴레이션에서는 “학번”이 유일하고, “주민등록번호”도 유일하며, “이름”은 겹칠 수 있다고 가정한다.

1. 슈퍼키(superkey): 릴레이션의 튜플을 유일하게 구별할 수 있는 속성(들의 조합)이면 전부 슈퍼키다. {학번}도 슈퍼키이고, {학번, 이름}처럼 필요 없는 속성을 더 붙여도 여전히 유일성이 유지되므로 슈퍼키다. 즉 슈퍼키는 “유일성만 만족하면” 되고, 최소성은 요구하지 않는다.
2. 후보키(candidate key): 슈퍼키 중에서 최소성(minimality)을 만족하는 것이다. 즉 그 조합에서 어떤 속성을 하나라도 빼면 더는 유일성이 보장되지 않는 슈퍼키만 후보키가 된다. 위 예에서는 {학번}과 {주민등록번호}가 각각 후보키다. {학번, 이름}은 슈퍼키이지만, “이름”을 빼도 “학번”만으로 이미 유일하므로 최소성을 만족하지 못해 후보키가 아니다.
3. 기본키(primary key): 여러 후보키 중에서 데이터베이스 설계자가 대표로 선정한 딱 하나의 키다. 위 예에서 {학번}과 {주민등록번호} 중 하나를 골라 기본키로 지정한다(개인정보 보호를 고려하면 보통 학번을 고른다).
4. 대체키(alternate key): 후보키였지만 기본키로 선정되지 않고 남은 나머지 후보키다. {학번}을 기본키로 골랐다면 {주민등록번호}가 대체키가 된다.
5. 외래키(foreign key): 어떤 릴레이션의 속성(들의 조합)이 다른 릴레이션(또는 같은 릴레이션)의 기본키를 참조하는 경우, 그 속성을 외래키라 한다. 외래키는 두 릴레이션 사이의 관계(참조 관계)를 표현하는 연결 고리 역할을 한다.

작은 예시: 외래키로 두 릴레이션 연결하기

DEPARTMENT(학과) 릴레이션과 STUDENT(학생) 릴레이션이 있고, 학생은 반드시 하나의 학과에 소속된다고 하자.

여기서 STUDENT 릴레이션의 “학과코드” 속성은 DEPARTMENT 릴레이션의 기본키인 “학과코드”를 그대로 값으로 가져와 참조하고 있으므로, STUDENT의 “학과코드”는 외래키다. 이 관계를 도식으로 표현하면 다음과 같다.

erDiagram의 ||--o{는 “DEPARTMENT 하나가 STUDENT 여러 개와 관계를 맺는다(1:N 관계)“는 뜻이며, 이 표기법 자체는 04편에서 이미 익힌 것을 그대로 재사용한 것이다. 자세한 표기법은 04편을 참고하고, 여기서는 “기본키를 그대로 가져와 참조하는 속성이 외래키”라는 정의에 집중한다.

결과 해석

다섯 가지 키의 관계를 한 문장으로 정리하면 다음과 같다. 슈퍼키는 후보키를 포함하는 더 넓은 개념이고, 후보키 중 하나가 기본키로 뽑히면 나머지 후보키는 대체키가 되며, 외래키는 이 모든 것과 별개로 “다른 릴레이션을 가리키는 역할”을 하는 속성이다. 즉 외래키는 자신이 속한 릴레이션에서는 기본키가 아니어도 되고(중복 값을 가질 수 있다), 심지어 널(NULL, 값이 없음)이 허용되는 경우도 있다(선택적 참여 관계일 때).

아래 표로 다섯 키의 관계를 한눈에 비교한다.

자주 틀리는 점

무결성 제약: 데이터가 지켜야 할 네 가지 규칙

왜 필요한가

키를 정의하는 것만으로는 데이터가 항상 올바르게 유지된다고 보장할 수 없다. 예를 들어 기본키에 중복된 값이나 빈 값이 들어가거나, 외래키가 존재하지 않는 부모 데이터를 가리키거나, 나이 속성에 “abc” 같은 값이 들어가는 등의 오류를 막으려면 별도의 규칙이 필요하다. 이 규칙들을 통틀어 무결성 제약(integrity constraint)이라 하며, 독학사 출제기준은 엔티티 무결성·참조 무결성·도메인 무결성·사용자 정의 무결성 네 가지를 다룬다.

쉽게 말하면: 무결성 제약은 “데이터베이스에 절대 들어와서는 안 되는 잘못된 데이터의 형태”를 미리 정해 놓은 규칙이다.

정의

1. 엔티티 무결성(entity integrity): 기본키를 구성하는 속성은 널 값을 가질 수 없다는 제약이다. 기본키가 널이면 그 튜플을 다른 튜플과 구별할 방법이 없어져, 릴레이션에 중복 튜플이 없다는 정의 자체가 무너지기 때문이다.
2. 참조 무결성(referential integrity): 외래키 값은 반드시 참조하는 릴레이션에 실제로 존재하는 기본키 값이거나 널이어야 한다는 제약이다. 예를 들어 STUDENT의 “학과코드”에 “MATH”라는 값이 들어 있는데 DEPARTMENT 릴레이션에 “MATH”라는 학과코드가 없다면, 이는 참조 무결성 위반이다.
3. 도메인 무결성(domain integrity): 각 속성의 값은 그 속성에 정의된 도메인(자료형·범위·형식)을 벗어날 수 없다는 제약이다. “학년” 속성에 정수 1~4만 허용하도록 정의했다면, “다섯”이나 5.5, “일학년” 같은 값은 도메인 무결성 위반이다.
4. 사용자 정의 무결성(user-defined integrity, 업무 규칙 무결성이라고도 한다): 앞의 세 가지로는 표현할 수 없는, 그 업무 도메인에서만 통용되는 규칙이다. 예를 들어 “재고 수량은 0 이상이어야 한다”, “종강일은 반드시 개강일보다 뒤여야 한다”처럼 업무 상식에서 나오는 제약이 여기에 속한다.

작은 예시

앞서 만든 DEPARTMENT와 STUDENT 릴레이션에 각 무결성 제약을 적용해 보면 다음과 같다.

결과 해석

이 네 가지 제약은 SQL로 구현될 때 서로 다른 문법으로 나타난다. 12편에서 배울 PRIMARY KEY 제약이 엔티티 무결성을, FOREIGN KEY ... REFERENCES 제약이 참조 무결성을, CHECK나 NOT NULL, 자료형 선언이 도메인 무결성을, 그리고 CHECK 제약이나 트리거(trigger)가 사용자 정의 무결성을 구현하는 도구가 된다. 즉 지금 배운 이론적 분류가 이후 SQL 실습에서 “이 제약을 어떤 문법으로 걸어야 하는가”를 판단하는 기준이 된다.

자주 틀리는 점

핵심 정리

• 릴레이션은 릴레이션 스키마 위에서 정의되는 튜플들의 집합으로, 중복 튜플이 없고 튜플 사이에 순서가 없으며 속성 값은 원자값이어야 한다. 차수는 속성(열) 개수, 기수는 튜플(행) 개수다.
• 슈퍼키는 유일성만 만족하는 속성 조합, 후보키는 유일성과 최소성을 모두 만족하는 슈퍼키, 기본키는 후보키 중 대표로 선정된 것, 대체키는 기본키로 뽑히지 못한 나머지 후보키, 외래키는 다른(또는 같은) 릴레이션의 기본키를 참조하는 속성이다.
• 엔티티 무결성은 기본키의 널 금지, 참조 무결성은 외래키가 존재하는 기본키 값이거나 널이어야 한다는 제약, 도메인 무결성은 속성 값이 정의된 도메인을 벗어나면 안 된다는 제약, 사용자 정의 무결성은 앞의 세 제약으로 표현할 수 없는 업무 규칙이다.
• 외래키는 자신이 속한 릴레이션의 기본키가 아니어도 되고, 관계가 선택적이면 널을 가질 수도 있다.

마무리 복습

참고 자료

• 국가평생교육진흥원 독학학위제 
• Oracle Database SQL Language Reference