1. 식별자

테이블의 특정 레코드를 읽거나 변경하려면 레코드끼리 구분할 수 있는 고유의 키 (=식별자)가 필요.
키는 1) 값이 꼭 있어야 하며, 2) 구분을 위해 고유값을 가져야 함.

조건을 만족하는 필드를 후보키 Candidate Key라고 하며 한 테이블에 여러 개의 후보키가 있음. 이 중 '레코드를 가장 잘 대표하는 키 하나를 골라 기본키 Primary Key'로 선정. 짧게 줄여 PK라고 부름. 기본키는 물리적인 조건 외에도 다음 조건을 만족해야 함,
1) 대표성 : 레코드를 상징하는 값이어야 한다.
2) 자주 참조하는 속성 : 기본키에는 기본적으로 인덱스가 생성되어 검색 효율이 좋다.
3) 가급적 짧은 속성 : 테이블 간의 연결고리가 되므로 비교 속도가 빨라야 한다.
이메일의 경우 소유를 강제하면 기본키로 사용가능 하고, 회원 목록 테이블이라면 회원 ID가 가장 적합한 기본키. 회원은 반드시 ID가 있어야 하고 같은 ID를 가지는 회원은 둘 이상 존재하지 않음.
iCity는 도시명인 name이 기본 키이며 다음 쿼리문은 에러가 생김.

INSERT INTO tCity VALUES ('춘천',1116,27,'n','강원');

춘천이 테이블에 이미 있는데 또 삽입하면 어떤 레코드가 진짜 춘천에 대한 정보인지 구분할 수 없음, 모호함이 생기면 무결성이 깨지므로 기본키에 대해서는 중복을 허락하지 않음.
DBMS는 기본키를 특별하게 관리. NULL 금지와 중복 방지는 물론이고 인덱스를 생성하여 검색속도를 높임.
기본키는 검색시 조건문에 활용하며 테이블간의 관계를 구성하는 연결고리로 사용.

2. 기본키 설정

제약을 선언하는 위치에 따라 컬럼 제약과 테이블 제약이 있음. 컬럼 제약은 컬럼 선언 뒤에 위치하며 테이블 제약은 모든 컬럼 선언이 끝난 후 마지막 위치에 옴.

CREATE TABLE 테이블
(
필드 선언, <- 이 위치에 오면 컬럼 제약
필드 선언, 필드 선언,
<- 이 위치에 오면 테이블 제약
)

NULL 허용 여부나, 기본값 등 컬럼에 대한 속성은 컬럼 제약으로 지정. 기본키는 컬럼 제약으로 선언할 수 도 있고 테이블 제약으로 선언할 수도 있음. 각 제약의 형식은 다음과 같음

• 컬럼 기본키 제약 : [CONSTRAINT 이름] PRIMARY KEY
• 테이블 기본키 제약 : [CONSTRAINT 이름] PRIMARY KEY(대상 필드)

PRIMARY KEY 제약은 NOT NULL 속성을 겸함. 제약의 이름을 생략하면 서버가 자동으로 이름을 붙임.

CREATE TABLE tCity
(
name CHAR(10),
area INT NULL ,
popu INT NULL ,
metro CHAR(1) NOT NULL,
region CHAR(6) NOT NULL,
CONSTRAINT PK_tCity_name PRIMARY KEY(name)
);

필드 선언문에 PRIMARY KEY 속성을 지정하는 컬럼 제약이 간단하지만, 여러 필드를 묶어 복합키로 지정하거나 외래키를 지정할 때는 테이블 제약을 사용.

3. 복합키

기본키 필드가 꼭 하나여야 한다는 법은 없으며 하나의 필드만으로 레코드를 특정하기 어려운 경우가 있음.
iCity 테이블의 경우, 도시명이 중복되지 않는다는 가정을 하고 있지만 현실은 다름.
경기도 광주, 전라도 광주 처럼 도시 이름이 중복되는 경우가 있는데 iCity 테이블의 구조로는 두 도시 모두 입력할 수 없음.
이름만으로 도시를 특정할 수 없으니 지역과 함께 묶어서 기본키로 정의해야 함. 이처럼 두개 이상의 필드를 묶어 기본키로 지정하는 것을 복합키 Composite Key라고 함.
name, region 두 개의 필드에 PRIMARY KEY를 지정하면 에러가 남.

CREATE TABLE tCity
(
name CHAR(10) PRIMARY KEY,
region CHAR(6) PRIMARY KEY,
area INT NULL ,
popu INT NULL ,
metro CHAR(1) NOT NULL
);

복합키는 두 개의 필드를 묶어 기본키로 지정, 테이블당 기본키는 하나만 지정 가능.
두 개 이상의 필드를 복합키로 지정할 때는 테이블 제약으로 기본키를 지정하며 괄호 안에 필드 목록을 콤마로 구분하여 나열.

CREATE TABLE tCityCompoKey
(
name CHAR(10) NOT NULL,
region CHAR(6) NOT NULL,
area INT NULL ,
popu INT NULL ,
metro CHAR(1) NOT NULL,
CONSTRAINT PK_tCity_name_region PRIMARY KEY (name, region)
);

이렇게 하면 이제 이름이 같은 두 개의 도시를 저장할 수 있음.

INSERT INTO tCityCompoKey VALUES ('광주', '전라', 123, 456, 'y');
INSERT INTO tCityCompoKey VALUES ('광주', '경기', 123, 456, 'n');

복합키도 중복값을 허용하지 않지만 복합키를 구성하는 개별 키는 중복해도 무방. 두 필드가 동시에 같지만 않으면 됨.

4. 유니크

유니크 UNIQUE 제약은 필드의 중복값을 방지하여 모든 필드가 고유한 값을 가지도록 강제, 기본키 제약과 유사하지만 몇 가지 차이점이 있음.

1) 기본키는 NULL을 허용하지 않지만 '유니크는 NULL을 허용'. 단 NULL끼리도 중복 할 수 없어 딱 하나의 NULL만 존재할 수 있음.
2) UNIQUE와 NOT NULL을 동시에 지정하면 기본키와 유사해짐. 그러나 기본키는 테이블당 하나만 지정할 수 있지만 '유니크는 개수에 상관없이 얼마든지 지정 가능'.
3) 기본키는 자동으로 인덱스를 생성하여 레코드의 정렬 순서를 결정하지만 유니크는 그렇지않음, 인덱스를 생성하더라도 기본키의 인덱스와는 종류와 효율이 다름.

유니크는 기본키를 보조하는 중복 방지 제약. 만일 iCity 테이블이 도시끼리 인구수가 같아서는 안된다는 규칙이 있다면 popu필드에 대해 UNIQUE 제약을 설정.

CREATE TABLE tCityUnique
(
name CHAR(10) PRIMARY KEY,
area INT NULL ,
popu INT UNIQUE NULL,
metro CHAR(1) NOT NULL,
region CHAR(6) NOT NULL
);

이 테이블의 도시끼리는 인구가 같아서는 안됨. NULL은 가능하지만 하나만 가능.
NULL을 허가하지 않으려면 UNIQUE NOT NULL로 지정. 두 개 이상의 키를 묶어 복합 UNIQUE 제약을 걸 수도 있음.

CREATE TABLE tCityUnique
(
name CHAR(10) PRIMARY KEY,
area INT NULL ,
popu INT NULL,
metro CHAR(1) NOT NULL,
region CHAR(6) NOT NULL,
CONSTRAINT Unique_tCity_area_popu UNIQUE(area, popu)
);

이 테이블의 도시는 이름이 고유해야 하며 area와 popu가 모두 같아서는 안됨, 둘중 하나라도 달라야 함