관계형 데이터베이스와 키·무결성

1. 데이터베이스와 DBMS

데이터베이스는 조직의 업무에 필요한 데이터를 여러 사용자가 공유하도록 통합하여 저장한 데이터 집합이다. 핵심 특성은 다음과 같다.

• 통합 데이터: 불필요한 중복을 줄여 일관성을 유지한다.
• 저장 데이터: 컴퓨터가 접근할 수 있는 저장장치에 기록한다.
• 운영 데이터: 조직의 업무 수행에 지속적으로 사용한다.
• 공유 데이터: 여러 사용자와 응용 프로그램이 공동으로 이용한다.

DBMS는 데이터의 정의·저장·검색·변경·보안·동시성·회복을 담당하는 소프트웨어이다. 파일 시스템보다 데이터 독립성, 무결성, 공유, 보안, 복구를 체계적으로 제공하지만 비용과 관리 복잡성이 증가한다.

2. 3단계 스키마와 데이터 독립성

사용자·응용 프로그램
        │
   [외부 스키마]
   사용자별 View
        │  논리적 데이터 독립성
   [개념 스키마]
   조직 전체 논리 구조
        │  물리적 데이터 독립성
   [내부 스키마]
   파일·페이지·인덱스·저장 위치
        │
     저장장치

• 외부 스키마: 사용자나 응용 프로그램이 보는 데이터의 일부이다.
• 개념 스키마: 조직 전체 데이터의 논리적 구조와 제약조건이다.
• 내부 스키마: 데이터가 실제로 저장되는 파일·페이지·인덱스 구조이다.
• 논리적 데이터 독립성: 개념 스키마가 일부 변경되어도 외부 스키마와 응용 프로그램의 영향을 최소화한다.
• 물리적 데이터 독립성: 내부 저장방식이 변경되어도 개념 스키마의 영향을 최소화한다.

시스템 카탈로그 또는 데이터 사전은 테이블·열·제약조건·인덱스·권한과 같은 메타데이터를 저장한다.

3. 관계형 모델의 기본 용어

관계형 모델에서 튜플은 집합의 원소이므로 중복되지 않으며, 튜플의 순서는 논리적 의미가 없다. SQL 테이블은 중복 행을 허용할 수 있으므로 관계형 모델의 수학적 릴레이션과 SQL 구현을 구분해야 한다.

4. 키의 종류

예를 들어 다음 테이블을 생각해 보자.

[부서 DEPARTMENT]
PK dept_id
   dept_name
      ▲
      │ FK가 PK를 참조
      │
[사원 EMPLOYEE]
PK emp_id
   email UNIQUE
FK dept_id
   emp_name

EMPLOYEE에서 emp_id와 email이 모두 유일하고 최소라면 둘 다 후보키가 될 수 있다. emp_id를 기본키로 선택하면 email은 대체키가 된다. dept_id는 DEPARTMENT.dept_id를 참조하는 외래키이다.

5. 무결성 제약

• 개체 무결성: 기본키는 NULL이거나 중복될 수 없다.
• 참조 무결성: 외래키 값은 참조 대상 키에 존재하거나, 해당 열이 NULL을 허용한다면 NULL이어야 한다.
• 도메인 무결성: 속성 값은 자료형·길이·범위·형식 등 정의된 도메인을 만족해야 한다.
• 사용자 정의 무결성: 업무 규칙에 따라 추가한 조건이다. 예: 급여는 0보다 커야 한다.

CREATE TABLE department (
    dept_id   INTEGER PRIMARY KEY,
    dept_name VARCHAR(50) NOT NULL UNIQUE
);

CREATE TABLE employee (
    emp_id    INTEGER PRIMARY KEY,
    email     VARCHAR(100) NOT NULL UNIQUE,
    dept_id   INTEGER,
    emp_name  VARCHAR(50) NOT NULL,
    salary    DECIMAL(12, 2) CHECK (salary >= 0),
    FOREIGN KEY (dept_id) REFERENCES department(dept_id)
);

위 정의에서 dept_id 외래키는 열 자체에 NOT NULL이 없으므로 NULL을 가질 수 있다. 그러나 NULL이 아닌 값은 반드시 department.dept_id에 존재해야 한다.

6. SQL의 bag 의미와 키 판정 계산

수학적 릴레이션은 튜플의 집합이지만 일반 SELECT는 중복을 허용한다. 따라서 다음 두 결과는 다를 수 있다.

SELECT dept_id FROM employee;          -- 중복 유지 가능
SELECT DISTINCT dept_id FROM employee; -- 중복 제거

함수 종속이 주어지면 속성 폐쇄로 키를 판정한다.

R(A,B,C,D,E), F={A→BC, C→D, D→E}
A+={A} → {A,B,C} → {A,B,C,D} → {A,B,C,D,E}

A는 모든 속성을 결정하고 더 줄일 수 없으므로 후보키이다. AB도 유일하지만 B를 제거해도 A가 키이므로 슈퍼키일 뿐 후보키는 아니다.

7. 자연키·대리키와 복합 외래키

대리키를 기본키로 두어도 이메일·상품코드 같은 업무상 자연키의 중복을 막으려면 UNIQUE를 별도로 둔다.

CREATE TABLE enrollment (
  student_id INTEGER,
  course_id  INTEGER,
  semester   CHAR(6),
  PRIMARY KEY(student_id,course_id,semester)
);

CREATE TABLE attendance (
  student_id INTEGER,
  course_id  INTEGER,
  semester   CHAR(6),
  attended_on DATE,
  FOREIGN KEY(student_id,course_id,semester)
    REFERENCES enrollment(student_id,course_id,semester)
);

복합 외래키는 참조 키와 열 수·대응 순서·도메인이 맞아야 한다.

8. 참조 동작과 데이터 독립성

내부 파일·인덱스 변경 → 개념 스키마 유지 → 물리적 데이터 독립성
개념 열·관계 변경 → 기존 외부 View 유지 → 논리적 데이터 독립성

물리적 독립성이 일반적으로 달성하기 쉽고, 개념 스키마 변경은 응용이 보는 의미에 직접 영향을 주므로 논리적 독립성이 더 어렵다.

확인 문제

1. R(A,B,C,D), F={A→B,B→C,AC→D}에서 A가 후보키인가?
2. (사번,이메일)이 유일하지만 사번만으로도 유일하면 어떤 키인가?
3. 대리키 PK를 추가한 뒤 이메일 중복을 막는 제약은?
4. ON DELETE SET NULL의 핵심 전제는?
5. 인덱스·파일 배치 변경을 응용에 숨기는 성질은?