예) 학생 릴레이션
| 학 번 | 이 름 | 학 년 | 학 과 |
| 20200101 | 강아지 | 1 | 소프트웨어학과 |
| 20190202 | 고양이 | 2 | 컴퓨터공학과 |
| 20180303 | 호랑이 | 3 | 인공지능학과 |
| 20170404 | 독수리 | 4 | 기계공학과 |
릴레이션 특징
▶ 튜플의 유일성 : 하나의 릴레이션에는 동일한 튜플이 존재할 수 없다.
하나의 릴레이션에 똑같은 튜플이 있으면 안되며 모든 튜플에는 다른 튜플과 구별되는 유일한 특성이 있어야합니다.
조금 더 설명하자면 이 포스팅 본문 위에 학생 릴레이션에서 학번 속성의 값이 튜플마다 다르므로 각 튜플을 유일하게 구별할 수 있습니다. 이처럼 튜플을 유일하게 구별하기 위해 선정되는 속성(또는 속성들의 모임)을 key 키라고 부릅니다. 이 키를 이용해 튜플의 유일성이 만족되면 릴레이션에서 원하는 튜플에 쉽게 접근할 수 있습니다.
▶ 튜플의 무순서 : 튜플 사이의 순서는 무의미하다.
데이터베이스는 위치가 아닌 내용으로 검색되므로 튜플의 순서는 중요하지 않습니다. 이 포스팅 본문 위의 학생 릴레이션에서 강아지의 튜플과 코끼리의 튜플의 위치가 바뀌어도 상관없습니다.
▶ 속성의 무순서 : 속성 사이의 순서는 무의미하다.
이 포스팅 본문 위의 학생 릴레이션에서 '학생(학번,이름,학년,학과)'로 표현된 릴레이션 스키마와 '학생(이름,학과,학번,학년)'으로 표현된 릴레이션 스키마는 동일하므로 두 릴레이션은 같습니다. 속성 값은 릴레이션에서 위치가 아닌 속성의 이름으로 접근하므로 하나의 릴레이션에는 이름이 같은 속성이 존재할 수 없고, 이름도 속성의 의미가 명확히 드러나는 것으로 사용하는 것이 좋습니다.
▶ 속성의 원자성 : 속성 값으로 원자값만 사용할 수 있다.
모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있습니다. 다시 말해 하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없습니다. 이 포스팅 본문 위의 학생 릴레이션에서 학년의 속성 값으로 1,2,3,4 등은 더이상 분해 할 수 없는 하나의 값입니다.
키의 종류
▶ 슈퍼키 Super key
슈퍼키는 유일성을 만족하는 속성 또는 속성들의 집합입니다. 유일성(uniqueness)은 키가 갖추어야 하는 기본 특성입니다. 키로 지정된 속성 값은 튜플마다 달라야 한다는 의미입니다. 즉, 키 값이 같은 튜플은 존재할 수 없습니다.
이 포스팅 본문 위의 학생 릴레이션에서 학번의 속성은 모든 학생 튜플마다 값이 달라야 하고 이를 통해 다른 튜플과 유일하게 구별할 수 있으므로 슈퍼키가 될 수 있습니다. 그러나 이름 속성은 같은 이름을 가진 학생이 있을 수 있으므로 유일성을 만족시키지 못해 슈퍼키가 될 수 없습니다.
슈퍼키는 속성들의 집합으로 이루어 질 수도 있기 때문에 (학번과 이름)속성으로 구성된 속성 집합은 슈퍼키가 될 수 있습니다.
서로 다름을 판단하기 위해 불필요한 값까지 확인하는 비효율적인 작업이 될 수도 있기 때문에 꼭 필요한 속성의 집합만으로 튜플을 유일하게 구별할 수 있도록 하는 또 다른 키의 개념이 바로 후보키입니다.
▶ 후보키 candidate key
후보키는 유일성과 최소성을 만족하는 속성 또는 속성들의 집합입니다. 최소성(minimality)은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성입니다. 그러므로 하나의 속성으로 구성된 키는 당연히 최소성을 만족합니다.
슈퍼키중에서 튜플을 유일하게 구별하기 위해 꼭 필요한 최소한의 속성들로만 이루어진 키가 바로 후보키입니다.
학번 속성은 단독으로 학생 튜플을 유일하게 구별할 수 있으므로 후보키가 될 수 있습니다. 하지만 이름이나 학년은 후보키가 될 수 없습니다. 이름 속성이 없어도 학번 속성만으로 유일성을 만족할 수 있기 때문입니다.
새로운 튜플이 삽입되거나 기존 튜플의 속성 값이 바뀌어도 유일성과 최소성은 유지되어야 합니다. 이름 속성은 슈퍼키는 물론 후보키로도 선택되지 않아야 하는 것이 바람직합니다.
▶ 기본키 primary key
릴레이션에서 튜플을 구별하기 위해 여러 개의 후보키를 모두 사용할 필요는 없습니다. 데이터베이스 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 하는데 이것이 기본키입니다.
기본키를 선택하는 기준
→ 기본키는 NULL 값을 가질 수 없습니다.
→ 기본키로 선택된 속성에는 중복된 값이 저장될 수 없습니다.
→ 값이 자주 변경되지 않는 속성으로 구성된 후보키를 기본키로 선택하는 것이 좋습니다.
→ 데이터베이스를 이용하는 일반 사용자뿐만아니라 데이터베이스를 처리하는 컴퓨터 시스템도 단순 값 처리를 선호하므로 단순한 후보키를 기본키로 선택하는 것이 좋습니다.
→ 기본키 선정 과정은 대학에서 학생회장을 선발하는 과정과 유사하게 생각하면 쉽습니다. 대학에 다니는 학생들(슈퍼키) 중에서 학생회장이 될 만한 후보학생(후보키)를 추천한 다음, 지지를 많이 받은 한명의 학생(기본키)를 학생회장으로 임명하는 과정이라고 이해하면 쉽습니다.
만약 후보키가 1개만 존재한다면 당연히 해당 후보키를 기본키로 선택해야겠지만 여러개일 경우에는 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택해야 합니다.
이 포스팅 본문 위의 학생 릴레이션에서는 학번 속성만 후보키이기 때문에 자연스럽게 학번 속성이 기본키가 됩니다. 선택한 기본키는 속성 이름에 밑줄을 그어 표현합니다.
▶ 대체키 alternate key
대체키는 기본키로 선택되지 못한 후보키입니다. 이름에서 알 수 있듯이 대체키는 기본키를 대신할 수 있지만 기본키가 되지 못하고 탈락한 이유가 있을 수 있습니다.
▶ 외래키 foreign key
외래키는 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키입니다. 다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키입니다. 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요합니다.
3개의 릴레이션은 외래키를 이용해 서로의 관계를 표현하고 있습니다.
→ 상담 릴레이션의 학번 속성은 학생 릴레이션의 기본키인 학번 속성을 참조하는 외래키입니다.
→ 담당교사 속성은 교사 릴레이션의 기본키인 교사번호 속성을 참조하는 외래키입니다.
→ 상담 릴레이션의 기본키는 두 외래키의 속성 조합으로 구성됩니다.
이처럼 하나의 릴레이션에는 외래키가 여러 개 존재할 수도 있습니다. 그리고 외래키를 기본키로 사용할 수도 있고 외래키를 포함하여 기본키를 구성할 수도 있습니다.
만약 외래키가 참조되는 릴레이션의 기본키가 아닌 다른 속성을 참조한다면 어떻게 될까요? 기본키가 아니면 튜플을 유일하게 구별하기 어렵기 때문에 참조되는 릴레이션에서 관련 있는 튜플을 검색하지 못할 수 있습니다. 그래서 외래키는 반드시 다른 릴레이션의 기본키를 참조해야 하며 외래키의 도메인은 참조되는 기본키와 같게 정의되어야 합니다.
예) 가상 쇼핑몰의 고객 릴레이션
| 아이디 | 추천인 | 이 름 | 적립금 |
| abcd | efgh | 강아지 | 1,000 |
| ijkl | efgh | 고양이 | 1,000 |
| efgh | NULL | 호랑이 | 4,000 |
외래키가 다른 릴레이션의 기본키를 참조하는 키라고 정의했지만 반드시 다른 릴레이션을 참조할 필요는 없습니다. 참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있습니다.
바로 위의 가상 쇼핑몰의 고객 릴레이션에서 아이디 속성이 기본키입니다. 그리고 추천인 속성은 같은 릴레이션의 아이디, 즉 기본키를 참조하는 외래키 입니다. 이처럼 기본키와 외래키가 하나의 릴레이션에서 표현되며, 이것은 자신과 관계 맺고 있음을 의미합니다.
외래키가 기본키와 다른 특징
위의 고객 릴레이션에서 호랑이 고객은 다른 고객의 추천을 받지 않았기 때문에 다른 튜플과 달리 추천인 속성값이 NULL 입니다. 외래키는 기본키를 참조하지만 기본키가 아니기 때문에 NULL 값을 가질 수 있습니다. 그리고 강아지와 고양이 고객의 추천인 속성이 efgh로 같은데, 이 또한 외래키가 기본키가 아니기 때문에 서로 다른 튜플이 같은 값을 가질 수 있습니다.