DataBase Key

DataBase에서 Key는 Data를 구분,관리하는 데 매우 중요한 역할을 한다.

주로 기본키(PK),외래 키(FK),고유 키(UK),체크 키(CK),후보키 등의 종류가 있다.

< 기본 키(Primary Key, PK) >

기본 키는 Table에서 각 행을 고유하게 식별하는 열이다. 기본 키의 특징은 다음과 같다.

• 고유성 : 각 행에 대해 유일한 값을 가져야 한다.
• 무결성 : NULL값을 허용하지 않는다.
• 테이블당 하나의 PK만 설정 가능하다.

Employees Table에서 PK를 사용했다고 가정하면 다음과 같다.

CREATE TABLE Employees (
ID INT PRIMARY KEY,
LastName VARCHAR(255) NOT NULL,
FirstName VARCHAR(255),
Address VARCHAR(255),
City VARCHAR(255)
);

 

<외래 키(Foreign Key, FK) >

외래 키는 다른 테이블의 기본 키나 고유 키를 참조할 수 있다.

고유 키는 각 행이 고유한 값을 가져야 하지만 NULL 값을 허용할 수 있다. 이는 고유 키가 기본 키와 다른 주요한 특징 중 하나이다.
따라서 외래 키가 참조하는 고유 키의 값이 NULL인 경우도 있을 수 있다. 하지만 이는 일반적으로 권장되지 않습니다. 외래 키는 데이터 무결성을 보장하는 데 중요한 역할을 하는데, 참조하는 키의 값이 NULL인 경우 데이터 무결성을 유지하는 데 문제가 발생할 수 있기 때문이다.

따라서 가능한 한 외래 키는 NULL이 아닌 고유한 값을 가진 기본 키나 고유 키를 참조하도록 설계하는 것이 좋다.

 

외래키의 특징은 아래와 같다.

• 참조 무결성: 외래 키의 값은 참조되는 기본 키의 값 중 하나이거나 NULL이어야 한다.
• RDBMS에서 Table 간의 관계를 나타낸다.
• 하나의 테이블에 여러 외래 키를 설정할 수 있다.

외래 키 예시를 들면, Orders 테이블에서 Employees 테이블을 참조할 수 있다.

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    OrderNumber INT NOT NULL,
    EmployeeID INT,
    FOREIGN KEY (EmployeeID) REFERENCES Employees(ID)
);

 

< 고유 키(Unique Key, UK) >

고유 키는 테이블의 각 행을 고유하게 식별할 수 있는 열이다. 기본 키와 비슷하지만, NULL 값을 허용한다는 점이 다르다.

 

고유 키의 특징은 아래와 같다.

• 각 행에 대해 유일한 값을 가져야 한다.
• NULL값을 허용할 수 있다.
• 하나의 테이블에 여러 고유 키를 설정할 수 있다.

고유 키는 다음과 같이 설정할 수 있다. 

CREATE TABLE Employees (
    ID INT PRIMARY KEY,
    LastName VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255),
    Email VARCHAR(255) UNIQUE
);

Email 열은 고유 키로 설정되어 각 행의 Email 값은 고유해야 한다.

 

< 체크 키(Check Key, CK) >

체크 키는 특정 열의 값이 지정된 조건을 만족해야 함을 보장하는 제약 조건이다.

체크 키의 특징은 아래와 같다.

• 데이터의 유효성 보장 한다.
• 열에 대해 지정된 조건을 만족해야 한다.
• 하나의 테이블에 여러 체크 키를 설정할 수 있다.

체크 키는 다음과 같이 설정할 수 있다.

CREATE TABLE Employees (
    ID INT PRIMARY KEY,
    LastName VARCHAR(255) NOT NULL,
    FirstName VARCHAR(255),
    Age INT CHECK (Age >= 18)
);

 

Age 열은 체크 키로 설정되어 Age 값이 18 이상이어야 한다.

< 캔디데이트 키(Candidate Key) >

캔디데이트 키는 기본 키로 선택될 수 있는 키다.

캔디데이트 키는 고유성(uniqueness)과 최소성(minimality)을 만족해야 한다.

 

고유성: 캔디데이트 키가 테이블의 각 행을 고유하게 식별할 수 있어야 한다는 것. 이것은 테이블에 동일한 값의 캔디데이트 키를 가진 두 개 이상의 행이 있으면 안된다는 의미다. 예를 들어, 학생 테이블에서 학생 ID는 고유성을 가지는 키일 수 있다. 왜냐하면 각 학생은 고유한 ID를 가지므로, 이 ID를 통해 각 학생을 "정확하게 식별"할 수 있기 때문이다.
최소성: 캔디데이트 키는 가능한 작은 수의 열로 구성되어야 한다는 것이다. 이것은 캔디데이트 키의 모든 부분이 행을 식별하는 데 필요하다는 의미이다. 예를 들어, 만약 학생 테이블에서 학생 ID와 성별을 결합하여 캔디데이트 키를 만들었다면, 이 키는 최소성을 만족시키지 못한다. 왜냐하면 학생 ID만으로도 각 학생을 고유하게 식별할 수 있기 때문이다. 따라서, 성별 열은 캔디데이트 키에서 불필요하게 된다.

 

예를 들어, 학생들에 대한 정보를 저장하는 'Students' 테이블이 있다고 가정해 보자.

CREATE TABLE Students (
StudentID INT,
Email VARCHAR(255),
FirstName VARCHAR(255),
LastName VARCHAR(255)
);

여기서 'StudentID'와 'Email' 열은 각각 Candidate Key가 될 수 있다. 왜냐하면 이들은 각각 학생들을 고유하게 "식별"할 수 있기 때문이다. 따라서 이들 중 하나를 기본 키로 선택할 수 있다.

CREATE TABLE Students (
StudentID INT PRIMARY KEY,
Email VARCHAR(255) UNIQUE,
FirstName VARCHAR(255),
LastName VARCHAR(255)
);

이 예제에서 'StudentID'는 기본 키로 선택되었고, 'Email'은 고유 키로 설정되었다.

이 두 키 모두 Candidate Key이다.

 

PK로 선택되지 않은 Candidate Key("Email")은 대체 키(alternate key)라고도 부른다.

이는 기본 키로 선택될 수 있는 대체 선택지라는 의미다.

 

그럼 어떤 상황에서 alternate key가 pk로 대체 될까?

1) 비즈니스 요구사항 변경 : 비즈니스 요구사항이 변경되어 기존 PK가 더이상 각 행을 유일하게 식별하지 못하거나,

새로운 요구사항을 충족시키지 못하는 경우 대체 키를 기본 키로 변경할 수 있다.

2. 데이터 구조 변경: 테이블의 데이터 구조가 변경되어 기존 PK가 더 이상 적절하지 않은 경우 대체 키를 기본 키로 변경할 수 있다. 예를 들어, 테이블을 분할하거나 병합하는 경우 기존의 기본 키가 더이상 유용하지 않을 수 있다. 

 

이러한 상황 외에 테이터베이스의 설계방식에 따라 다양한 방식에서 대체 키가 기본 키로 사용될 수 있다.