DMBS

• DB 내에 있는 data의 물리적, 논리적 변화가 응용시스템에 영향을 미치지 않도록 함으로써 data의 독립성을 보장한다

기본키와 외래키

• 데이터베이스의 key는 일반적인 의미와 조금 다르다.
  • 어떤 table에 새로운 튜플을 삽입하려고 하는 상황이라고 가정하고 삽입하려는 튜플이 기존에 존재하는 튜플과 완전히 일치하면 몇 가지 문제가 발생한다.
    • 1. 만약 전체 인원을 알아내기 위해 튜플 수를 카운트하는 연산을 수행시키면, 중복된 튜플도 카운트 되기 때문에 실제 인원보다 더 많은 수를 반환하게 된다.
    • 2. 이와 같은 문제를 방지하기 위해 DB에서는 중복된 튜블의 삽입을 막아야할 필요가 있다.
    • 3. 그런데 DBMS를 구현하는 입장에서는 중복된 튜플이 삽입되는지를 확인하는 것은 쉬운 일이 아니다. 일일이 모든 튜플을 검사해도 되긴하지만, 실제로 수십만개의 튜플을 모두 다 검사한다는 것은 불가능한 뿐더러 , 시간이 많이 소요되기 때문이다. 그리고 의미적 중복의 경우에는 데이터의 의미를 이해할 수 없는 DBMS로서는 알아낼 수 없다.

• 이에 대한 답이 바로 key 이다. 보다 정확히는 후보키이다.
  • 후보키란?
    • 테이블에서 각 튜플을 구별하는데 기준이 되는 하나 or 그 이상의 컬럼들의 집합이다. 후보키는 테이블에 존재하는 각 튜플을 고유하게 식별 할 수 있어야한다.
    • 실제로 개개인을 구분하기 위해 학번이라는 후보키를 사용할 수 있다.

• DBMS는 새로운 튜플이 릴레이션에 삽입 될 때 새로운 튜플의 후보값이 기존의 튜플들의 후보키 값과 동일한지 여부를 비교하여 중복여부를 판단하게 된다.
  • 후보키 값의 비교는 모든 컬럼을 비교하여 보지않아도 되기 때문에, 시간도 절약한다는 장점이 있다.
  • 그리고 인덱스 기법을 사용하면 빠른 시간에 중복 여부를 판단할 수 있다.
    • 만약 새로운 튜플을 삽입하려고 할 때 후보키 값이 중복된다면 DMBS는 삽입 연산을 거절한다.
• 키는 일반적으로 테이블이 생성될 때 지정한다.

• 후보키(candidate key)는 기본키(primary key)와 대체키(alternate key)로 구분된다.
  • 테이블은 한 개 이상의 후보키를 가질 수 있다.
    • 이 때 선택된 후보키를 기본키 , 선택되지 않은 키를 대체키라고 부른다.
    • 후보키 중 어느 것을 사용해야한다는 규칙은 없지만 현실에서 빈번히 사용하고 데이터의 길이가 짧을수록 좋다.

복합키

• 어떤 릴레이션에 후보키가 하나만 존재한다면 당연히 그 키가 기본키가 된다.
  • 기본키를 지정하는 문제는 DB를 설계하는 데 있어 매우 중요하다.

• 후보키, 대체키, 기본키에 추가하여 복합키(composite key)가 있다.
  • 하나의 컬럼이 후보키 역할을 하는 릴레이션이 있는 반면, 두 개이상의 컬럼이 합쳐져야만 후보키의 역할을 할 수 있는 릴레이션도 있다.
  • 이렇게 두 개 이상의 컬럼이 모여 키의 역할을 하는 경우를 복합키라고 한다.

• 예를 들어 학번(sid)이 후보키가 된다면, 각 튜플의 학번 컬럼은 중복된 값이 들어올 수 없으므로 유일해야한다. 그런데 이 테이블은 취미와 관련된 테이블이라서 한명이 여러개의 취미를 가질 수 있기 떄문에 유일하지 않기 때문에 후보키의 자격이 없다.
  • 동아리 이름 (club) 이나 club_president 또한 유일하지 않기 때문에 자격이 없다.
  • 그렇다면 sid와 club을 합친 경우는 어떨까
    • 이 테이블은 학생들이 가입한 동아리 정보를 관리하는 것이기 때문에, a라는 학생이 b라는 동아리에 가입했다는 정보는 한번만 기록된다. 만약 그렇지 않다면 중복이 되는 것이다.
    • 따라서 {sid, club}은 후보키가 될 수 있고, 두 개 이상의 컬럼이 더해져서 후보키의 역할을 하기 때문에 복합키이다.
    • 극단적으로 모든 컬럼을 합쳐야 후보키가 되는 경우도 존재한다.