[Database] 데이터베이스 기본적인 개념 정리 (1)

sunbun·2023년 8월 21일

Database

목록 보기

1/2

SQLD 시험을 앞두고, 문제를 풀면서 이전에 학교 강의 시간에 배웠던 데이터베이스의 기본적인 개념이 헷갈려서 다시 정리를 진행해봤다.

그 때 배웠던 개념과 실제 SQLD 시험 문제는 굉장히 갭이 있어서 SQLD가 조금 어렵게 느껴지지만... 일단 그 때 배운 개념이 머릿속에서 잘 정리가 돼있어야 문제를 풀기 수월하다는 점을 느껴서 다시 한 번 정리해보고자 한다.

1. 데이터베이스와 정보 시스템

1.1 정보시스템의 발전

정보시스템(information system)
- 한 조직의 활동과 운영에 필요한 데이터를 수집, 저장해두었다가 다양한 방식으로 처리 및 가공함
- 의사결정에 필요한 정보를 생성하는 소프트웨어 체계

정보 시스템의 구조

→ input으로 data, output으로 information

정보 시스템의 발전 과정
- 광의(넓은 의미)
  - 데이터를 체계적으로 정리 및 관리 ⇒ 형식, 구성 상관 x, 모두 데이터베이스!
  - 관련된 콘텐츠와 데이터 모아놓은 저장소
- 협의(좁은 의미)
  - DBMS를 통해 관리하는 것을 데이터 베이스로 설명 (일반적 정의)
  - 데이터베이스를 보다 효율적이고 체계적으로 활용하기 위해 구성한 데이터 형식
  - 데이터의 형식과 구성에 엄격한 제약을 갖는 시스템 관점
- 기술적으로는 데이터 저장 방식의 구현과 활용 방식에 따라 두 가지로 구분됨
  - 파일 정보 시스템(File Information System)
  - 데이터베이스 시스템(Database System)
전통적 파일 정보시스템의 문제점

데이터 종속성(data dependency)의 증가
- 파일 안의 저장 방식이나 접근 방법을 변경할 경우, 연관된 모든 응용 프로그램도 함께 수정되어야 함. ⇒ RDBMS가 나온 이유!
  - related to 데이터 종속성(data dependency)
- 동일한 때에 동일하게 수정되지 않으면 Isolation 문제로 확대됨
  - 데이터 종속성의 증가, 데이터 중복성의 증가
    - 제어가 잘 안 될 경우,
      중복 데이터 간에 불일치가 생기고, 데이터 의미가 모순될 수 있음!
      ⇒ 데이터 일관성(Cosistency), 데이터 무결성(Integrity)도 손상
    - 보안 유지(Security)도 어렵
데이터 중복성(data redundancy)의 증가
- 같은 데이터가 여러 파일 안에 중복 저장되면 관리가 어렵고 메모리 낭비도 발생
- 제어가 잘 안될 경우:
  - 중복 데이터 간에 불일치가 생기고 데이터 의미가 모순됨으로써 데이터 일관성, 데이터 무결성이 손상됨
  - 보안 유지도 어려워짐
- 해결책으로 모든 데이터 파일의 통합을 고려
  - 데이터 중복성 문제는 줄어들 수 있음
  - 파일 단위의 동시 공유나 보안만 가능해 다수의 사용자 지원 제한
  - 대용량 데이터에 대한 공유나 보안, 장애 발생 시 회복 등의 처리가 어려움

데이터베이스 시스템
- 공통의 데이터 모델과 표준 데이터 언어를 이용하여 데이터 종속적 문제를 해결/최소화
- 통합 저장소를 이용하여 데이터 중복성 문제 해결/최소화
- 데이터베이스 접근성을 DBMS를 통해 개선
  - 응용 프로그램이나 사용자는 DBMS를 통해서만 데이터 처리 가능
  - 데이터 처리에 관한 복잡하고 힘든 과정을 DBMS가 모두 떠맡아 처리

DBMS의 궁극적인 목적
- 데이터 독립성
- 논리적 데이터 독립성(logical data independency)
  - 응용 프로그램에 영향을 주지 않고, 논리적 데이터 구조의 변경이 가능
  - 응용 프로그램의 효율적 개발
- 물리적 데이터 독립성(physical data independency)
  - 응용 프로그램과 논리적 데이터 구조에 영향을 주지 않고, 물리적 데이터 구조의 변경 가능해야 함
  - 저장 장치의 효율적 개발이 가능
- 데이터 독립성 구현 기법 - 사상(mapping)

2. 데이터베이스의 기본 개념

2.1 데이터베이스의 등장

데이터베이스(database)
- 광의
  - 관련된 콘텐츠와 데이터를 모아놓은 저장소
- 협의
  - 데이터베이스를 보다 효율적이고 체계적으로 활용하기 위해 구성한 데이터 형식
  - 데이터의 형식과 구성에 엄격한 제약을 갖는 시스템 관점

2.2 데이터베이스의 정의

공용 데이터의 저장소
- 다수의 사용자와 응용 프로그램이 다양한 목적을 위해 공동으로 소유하고 유지하는 공용 데이터 저장소
- 혼자 사용할 목적으로 자기 혼자만 소유한 데이터 저장소는 엄밀하게 데이터베이스로 분류하지 않음
통합 데이터의 저장소
- 여러 곳에서 필요한 데이터를 하나로 통합한 통합 데이터(integrated data) 저장소
- 물리적으로 여러 장소/장비에 나누어져 있더라도 상호 연결되어 접근할 수 있는 논리적 통합이 가능

→ 이를 위하여 데이터/정보의 무결성(형식/내용), 적시성, 신뢰성, 안정성, 사용성이 보장되어야 함

운영 데이터의 저장소
- 특정 조직의 운영 목적을 위해 사용되는 운영 데이터(operated data)들의 저장소
- 조직 운영을 위해 필수적 데이터
저장 데이터의 저장소
- 컴퓨터/시스템에서 직접 접근이 가능한 ‘0’과 ‘1’의 이진 문자열로 디지털화된 저장 데이터(stored data)
- USB메모리, 하드디스크, DVD 등 컴퓨터가 직접 접근하고 제어할 수 있는 저장 매체에 기록되어야 함

→ 여러 사용자나 응용 프로그램들이 함께 사용할 목적으로 체계적으로 통합하여 저장한 운영에 꼭 필요한 필수 데이터들의 저장소

2.3 데이터베이스의 특성

실시간 접근(realtime accessibility)
- 데이터베이스 (동시) 접근 사용자 수가 많아도 사용자의 데이터 요구에 실시간 수준으로 응답해야 함
끊임없는 변화(continuous evolution)
- 현실의 변화에 따라 데이터베이스도 변화하여 현실 세계를 정확히 반영해야 함
동시 공용(concurrent sharing)
- 여러 사용자가 동시에 공동으로 사용할 수 있고, 필요한 시기에 원하는 데이터를 활용할 수 있어야 함
내용 기반 참조(content based referencing)
- 데이터 참조를 위해 데이터의 (물리적) 저장 위치는 사용자에게 의미 없음
- 요구하는 데이터의 내용을 기준으로 데이터 접근이 가능해야 함

3. 데이터베이스 시스템의 구성 요소

3.1 데이터 언어

데이터베이스 사용자와 응용 프로그램은 모두 DBMS를 통해서만 데이터베이스 접근 가능
데이터 언어: DBMS에 요청 내용을 전달하기 위한 의사전달 수단/도구
- 요청해서 변수에 데이터 저장해주는 역할!
일반적으로는 RDBMS의 표준 데이터베이스 언어인 SQL(Structured Query Language)을 의미함
DB만을 위한 특수한 언어
Non-Procedural 순서대로 이행하지 X 한 특성 때문에 4세대 언어 객체지향언어 로 분류되기도!
데이터 언어는 사용 목적에 따라 3가지 명령어 그룹으로 분류
- 데이터 정의 언어 DDL(Data Definition Language)
  - 데이터베이스 구조를 새로 정의하거나 기존 데이터베이스 구조를 변경하는 명령어 집합
  - 데이터베이스 구조를 표현하는 데이터베이스 스키마를 명세(Define)하기 위해 사용
    - Create - 데이터베이스 생성
    - Alter - 데이터베이스 변경
    - Drop - 데이터베이스 제거
    - Show - 데이터베이스의 구조, 생성문, 권한 etc 보여줌
    - Use - 데이터베이스 사용
      → 사용자 생성, 삭제 등은 Create, Drop 등을 사용할 수 있으나,
      DML 사용할 수도 있음 (권한 있는 유저 한하여)
  - DBA나 응용 프로그래머가 주로 사용
  - 메타데이터
    - 일반적으로 데이터에 관한 구조화된 데이터, 다른 데이터를 설명해 주는 데이터
    - DDL로 정의된 내용은 메타데이터가 된다
- 데이터 조작 언어 DML(Data Manipulation Language)
  - 데이터베이스 안의 데이터를 실제 조작하는 명령어 집합
  - 가장 많이 사용되는 인터페이스 도구
  - DBMS에게 데이터의 입력, 수정, 삭제 및 검색을 요청하기 위해 사용
    - Select A from B where C
    - Insert A into B
    - Delete from B where C
    - Update B Set A where C
  - 응용 프로그래머, DBA, 일반 사용자 등이 모두 사용함
- 데이터 제어 언어 DCL(Data Control Language)
  - 데이터베이스를 제어하고 통제하기 위해 사용하는 명령어 집합
  - 데이터베이스가 안전하게 오류 없이 동작하고 성능을 유지하도록 관리하는 명령어
  - 각종 허가, 제약, 옵션을 설정함으로써 DBMS가 데이터베이스를 올바르게 관리하도록 함
    - 동시성 제어(Concurrency Control)
      - 동시 접근 가능하도록
    - 장애 회복(Recovery)
    - 데이터의 무결성(Integrity)
      - especially, 속성의 무결성
      - 데이터의 정확성 유지를 위한 무결성
    - 보안(Security)

3.2 데이터베이스 관리 시스템(DBMS)

데이터베이스를 효율적으로 관리하고 데이터베이스에 대한 데이터 요청을 처리하는 소프트웨어 시스템, 일종의 Middle Wear

사용자와 데이터베이스 사이의 중재자 역할 수행
- 다양한 사용자 or 응용 프로그램이 데이터베이스와 함께 사용하도록 지원
- 사용자에게 복잡한 내부 처리 과정, 물리적 구조 숨기고 데이터 언어 통해 DB 접근 및 제어
  - 일종의 black box

DBMS의 필수 기능
- 정의 기능 DDL
  - 데이터를 저장하는 통합 데이터베이스 구조를 생성하거나 이미 생성된 구조를 삭제 또는 변경
- 조작 기능 DML
  - 데이터베이스 안에 저장된 데이터에 접근하여 원하는 데이터 조작을 할 수 있도록 함
  - 사용자의 다양한 입력, 수정, 삭제 및 검색 요청을 효율적으로 처리
- 제어 기능 DCL
  - 여러 사용자가 동시에 다양한 목적으로 접근하더라도 항상 데이터를 정확하고 안전하게 유지하도록 통제함
  - 사용자별 보안과 권한 설정, 데이터 조작 과정 중에 동시성과 무결성 유지, 백업 및 장애 시 회복 조치 제어
  -> DBA 역할

3.3 데이터베이스 서버

데이터베이스가 구동되는 서버의 역할을 하는 컴퓨터

클라이언트/서버 컴퓨팅 환경
- 시스템 부하가 매우 크므로 보통 데이터베이스 시스템을 독립 서버로 운영하고 사용자나 응용 프로그래머는 클라이언트 컴퓨터를 통해 접근
- 최근에는 직접 구현하기보다는 클라우드나 호스팅 서버로 제공하는 경우가 많아졌음
- 데이터베이스 서버 안에는 데이터베이스가 물리적으로 저장되며 DBMS가 설치되어 다양한 요청이 처리됨
전통적으로 데이터베이스 서버는 고성능 사양을 요구하지만, 최근에는 성능 개선과 가격 하락으로 상대적으로 저렴한 일반 컴퓨터를 데이터베이스 서버로 활용하는 것도 가능(한계는 존재)

4. 3단계 데이터베이스

4.1 스키마(Schema)

데이터베이스 안에 저장되는 데이터 구조와 제약 조건(형식, 속성) 등을 정의한 것

데이터베이스 중에서도 RDBMS 관점에서 강조되는 것
동일한 데이터베이스라도 접근 관점에 따라 스키마는 다를 수 있음
→ 어떻게 릴레이션을 잡냐에 따라
주로 데이터 구조 위주로 표현하며, 스키마의 세부 제약 조건보다는 릴레이션 구조만 간략히 표현

4.2 3단계 데이터베이스의 구조

3단계 데이터베이스의 구조
- 외부 단계(개별) > 개념 단계(통합) > 내부 단계(저장)
- 일반적으로 하나의 데이터베이스 안에는 여러 개의 테이블 존재
- 특정 테이블 구조를 명세한 것을 테이블 스키마라고 함
- 테이블 스키마를 모으면 데이터베이스 스키마가 됨
외부(External) 스키마
- 사용자가 외부에서 바라보는 관점에서의 개인적 데이터베이스 구조를 정의
- 일반 사용자나 응용 프로그래머 차원에서 접근하는 일부 논리적 부분을 표현
- 일부만을 대상으로 한정하여 명세한 구조 / 서브(하위) 스키마(sub schema)라고도 부름
- 각 사용자별 관점을 반영하기 때문에 여러 외부 스키마가 존재
개념(Conceptual) 스키마
- 모든 사용자들의 관점을 통합하여 전체 조직 관점에서 데이터베이스 구조를 정의
- 데이터베이스 관리 차원에서 접근되는 통합된 데이터베이스의 논리적 부분 표현
- 일반적으로 스키마라고 불림
- 조직이나 기관의 데이터베이스 전체를 명세한 구조로 하나의 데이터베이스에는 하나의 개념 스키마
내부(Internal) 스키마
- 저장 장치의 관점에서 전체 데이터베이스의 내부 구조 정의 = 개념 스키마의 시스템 내부 저장 방식
- 내부 레코드의 형식이나 배치 방법, 인덱스 등에 대한 명세를 포함
- 실제 장치의 물리적 저장 방식이나 구조를 명세한 것이 아님
  - 추상화된 상위표현
- 내부 스키마도 데이터베이스 당 하나만 존재
- but 전체 스키마 중 가장 상세!

4.3 데이터 사전

DBMS는 스키마와 스키마 매핑(Mapping) 정보를 데이터 사전이라는 별도의 저장소에 관리
데이터 사전 (data dictionary)
- 데이터베이스에 저장된 모든 부가 정보
- DBMS가 스스로 생성하고 유지
- 데이터베이스 정의나 명세 + 스키마와 이들 간의 사상 정보, 제약 조건 등을 저장하는 저장소
  - 다양한 데이터베이스 객체(테이블과 열, 뷰, 인덱스, 사용자 권한 등)에 관한 모든 데이터 포함
  - 시스템 데이터베이스 (시스템 카탈로그)
데이터 디렉토리 (data directory)
- 데이터 접근에 필요한 위치 정보를 저장하는 저장소
- 사용자가 접근할 수 없음

4.4 데이터 독립성

데이터 독립성

데이터의 논리적 구조나 물리적 구조가 변경되더라도 (스키마가 변경되더라도!) 응용 프로그램이 영향을 직접 받지 않는 특성
- 3단계 데이터베이스 구조를 통해 응용 프로그램과 데이터 사이의 독립성을 유지할 수 있음
- 반대로 데이터베이스에 영향을 미치지 않으면서 응용 프로그램을 수정할 수 있어야 함
- 각 단계의 스키마 사이에 적절한 내부 매핑을 하면 하위 스키마가 변경되더라도 상위 스키마에 영향을 주지 않도록 할 수 있음

외부/개념 사상 schema: 논리적 데이터 독립성 제공
- 외부 스키마를 변경하더라도 전체 개념적 스키마는 변경되지 않거나 변경 내용을 최소화함
- 다른 응용 프로그램에 주는 영향을 없애거나 최소화
- DBMS에 의해 수행되는 외부/개념 사상 즉, 하나의 개념 스키마를 여러 스키마 형태로 매핑하여 구현
  - 논리적 데이터 독립성
    
    응용 프로그램에 영향을 최소화하면서 데이터베이스의 논리적 구조를 변경할 수 있는 것
    - DBMS에 의해 수행되는 외부/개념 사상 즉, 하나의 개념 스키마를 여러 외부 스키마 형태로 사상시킴으로써 가능
    - 개념 스키마의 변경이 외부 스키마에 영향을 주지 않음
개념/내부 사상: 물리적 데이터 독립성 제공
- 물리적 구조의 변경으로 내부 스키마가 수정되더라도 연관된 개념-내부 사상 정보만 수정하고 상위 스키마에 대한 영향은 최소화할 수 있음
- 즉, 개념적 스키마에 영향을 최소화하면서 데이터베이스의 물리적 구조를 변경
- 물리적 데이터 독립성
  - DBMS에 의해 수행되는 개념/내부 사상 즉, 하나의 개념 스키마와 내부 스키마 사이의 사상을 통하여 가능
  - 개념 스키마의 데이터가 내부 스키마의 어느 물리적 위치에 어떤 방법으로 저장되는지 대응
    
    개념적 스키마에 영향을 최소화하면서 데이터베이스의 물리적 구조를 변경할 수 있는 것
```
	
```

5. 관계형 데이터 베이스

5.1 관계형 데이터베이스(relational database)의 개념

1970년 IBM 연구소의 코드(E. F. Codd)가 제안한 관계형 데이터 모델(lecture 02)에 기반
관계형 데이터 모델(Relational Data Model)
릴레이션(relation)
- 관계형 데이터 모델의 핵심 요소로 특별한 의미를 갖는 테이블
- 단순 테이블 형태로 구성, 테이블 이상의 많은 의미와 제약 사항 내포 관련된 여러 릴레이션들로 데이터베이스를 구성
- 릴레이션을 구조적으로 이해하고 커뮤니케이션 하기 위해 만든 것이 스키마다 ~

5.2 릴레이션 관련 용어

속성(attribute)
- 테이블의 열(column)
- 데이터를 표현하는 가장 작은 논리적 단위 → by normalization?
- 의미적으로 더 이상 분해할 수 없는 원자 값(atomic value)만 사용
- 릴레이션이 표현하는 대상의 주요 특성들을 서로 다른 이름으로 구별하여 표현
투플(tuple)
- 테이블의 각 행(row)
- row, instance, record, …
- 현실 세계의 개체(entity)를 표현 → 하나의 완성된 기록 record
- 각 속성 값(attribute value)들의 조합으로 구성
도메인 (domain)
- 각 속성이 취할 수 있는 모든 값들의 집합을 정의한 것
- 데이터 값들의 유형과 크기, 범위 정의
- 각 속성끼리 해당 도메인이 일치할 경우만 그 값을 서로 비교하는 것이 의미가 있음
```
$a = 11 ;
$b = '11';

>>> a == b
>>> False
```
  - 하나의 도메인이 둘 이상의 속성에서 사용될 수 있기 때문에 속성 이름이 다르더라도 도메인이 같다면 속성들의 값 비교가 가능!
- 관계형 데이터 모델은 속성 이름과는 별개로 각 도메인을 고유한 이름으로 정의
- 속성 이름 보통 각 도메인이 릴레이션에서 담당하는 역할(role)의 이름으로 지정
  - 속성 이름 보면 도메인 알 수 있게 만들어주기
카디널리티와 차수
- 각 릴레이션은 카디널리티와 차수를 통해 그 구성이 정의됨
- 카디널리티 (cardinality)
  - 릴레이션 안의 전체 투플의 개수
  - 입력, 수정, 삭제 등을 통해 계속 변화 (동적 특성)
- 차수 (degree)
  - 릴레이션을 구성하는 전체 속성의 개수
  - the number of attributes
  - 각 튜플이 가지는 속성 값의 개수 = 릴레이션의 차수 (정적 특성)
  - 차수를 늘리다가 system error 생길 수도, table 새로 생성 권장

5.3 릴레이션의 구성 요소

릴레이션 스키마(relation schema)
- 특정 릴레이션의 논리적 구조 뜻함
  - 릴레이션의 이름과 릴레이션 안에 포함된 모든 속성의 이름들로 정의
  - 테이블의 첫 번째 행인 헤더 부분에 표현
- 릴레이션 내포(relation intension) 또는 릴레이션 내연이라고도 부름
- 시간이 경화해도 좀처럼 변경되지 않는 정적인 특성 잘 안 바꾼다!
  - e.g.) ‘학생’ 릴레이션에 대한 릴레이션 스키마?
    - 릴레이션 이름 뒤의 괄호 안에 릴레이션이 포함되는 속성들의 이름을 열거
- 키 속성(primary key, pk)은 밑줄 표시
  - 릴레이션 이름(속성이름1, 속성이름2, …, 속성이름n)

릴레이션 인스턴스(relation instance)
- 어느 한 특정 시점에 릴레이션에 존재하는 투플들의 집합
  - 보통 테이블의 첫 번째 행인 헤더 부분을 제외한 나머지 모든 행들의 집합으로 표현
- 릴레이션 외연(relation extension)/릴레이션 확장이라고도 부름
  - 특정 시점에서의 전체 투플들의 내용 즉, 릴레이션의 상태를 의미
  - 시간에 따라 변하는 동적인 특성
  - e.g.) ‘학생’ 릴레이션에 대한 릴레이션 인스턴스
    - 예) { <’s001’, ‘김연아’, 4, ‘여’>, <’s002’, ‘홍길동’, 1, ‘남’>, <’s003’, ‘이승엽’, 3, ‘남’> }

투플의 유일성(uniqueness of tuple)
- system적으로는 가능하긴하지만, but 지켜라!
- 릴레이션 안에는 똑같은 투플이 존재할 수 없음 record 중복 X
  - 하나의 릴레이션은 투플들의 집합 → 모든 투플은 서로 달라야 함
- 중복된다면? → 데이터 중복성 발생! → 릴레이션이 아니게 됨
- 모든 투플은 다른 투플과 구별되는 유일한 속성 값이 있어야 함
  - 집합은 식별할 수 없는 똑같은 원소를 중복해서 포함할 수 없기 때문
투플의 무순서성(no ordering of tuple)
- 릴레이션의 투플 사이에 순서는 의미가 없음
  - 집합은 포함한 원소들 사이에 순서가 없음
  - 투플의 집합인 릴레이션 역시 투플 사이에 순서를 갖지 않음
속성의 무순서성(no ordering of attribute)
- 릴레이션의 속성 역시 순서는 의미 X
- 릴레이션이 속성의 집합, 같은 이유로 순서 갖지 X
- 속성 값은 속성의 순서가 아닌, 속성 이름에 의해 참조됨
속성의 원자성(atomicity of attribute)
- 릴레이션을 구성하는 모든 속성 값 = 의미적으로 더이상 분해할 수 없는 하나의 원자 값
- 각 속성 값으로 의미적으로 더 쪼개서 사용할 수 있는 값이나 여러 개의 값이 허용되지 않음
- 릴레이션은 다중 값 속성이나 복합 속성을 허용하지 않음

5.4 제약 조건

릴레이션의 키(key)
- 각 투플을 유일하게 식별할 수 있는 하나 이상의 속성 집합
- 릴레이션은 항상 투플의 유일성 규칙 충족 → 중복 투플 허용 X
- 결과적으로 모든 투플은 속성 값이 하나 이상이 서로 다름
- 모든 릴레이션은 키를 가짐
- 키에 속하는 속성 집합은 반드시 그 속성 값의 조합이 투플마다 달라야 함
- 릴레이션이 단순한 테이블이 아님을 보여주는 대표적 개념
- 여러 무결성 제약 조건과 관련하여 중요한 역할!
- 키 선정은 현재 릴레이션 데이터 값만으로 결정하지 않아야 함
- 릴레이션 인스턴스는 계속 변화하므로 미래 입력값까지 포함한 속성의 본질적 의미 고려하여 키 지정 여부 결정!
- 종류: 후보키, 슈퍼키, 기본키, 대체키, 외래키 등
후보키(CK: Candidate Key)
- 후보키 중 primary key 선정
- 투플을 유일하게 식별할 수 있는 꼭 필요한 속성들로 구성됨
- 유일성(Uniqueness)과 최소성(Minimality) 조건을 모두 만족해야 함
  - 유일성 조건: 릴레이션에서 키로 지정한 속성 값의 조합은 투플마다 모두 달라야 함
  - 최소성 조건: 릴레이션에서 키로 지정한 속성의 개수를 최소화해야 함
- 결과적으로, 모든 릴레이션은 최소 하나 이상의 후보키 가짐
- 둘 이상의 속성으로 이루어진 복합키(Composite key) 아니라면 최소성 조건 항상 충족
슈퍼키(SK: Super Key)
- 투플을 유일하게 식별할 수 있는 속성 집합
- 식별을 위해 꼭 필요한 속성 아니어도 포함 할 수 있음
- ~~최소성 충족여부~~, 후보키의 유일성 조건만 만족하면 됨
  - 후보키 ⊂ 슈퍼키
  - 모든 후보키는 슈퍼키임
- 후보키를 포함하는 속성 집합도 모두 슈퍼키가 됨
기본키(PK: Primary Key)
- 투플을 대표하도록 선정된 후보키로, 여러 후보키 중에서 하나를 선택하여 지정
- 하나의 조합!, real 하나만 X
- 의미적으로 투플을 가장 대표할 수 있고 또한 식별 수단으로도 적합한 후보키를 기본키로 선정
- 기준?
- 후보키가 하나일 경우
  - 후보키가 여러 개일 경우 추가 검토 조건!
    - 값이 자주 변경되지 않는 정적인 속성으로 구성된 후보키
    - null 값을 가질 수 없는 속성으로 구성된 후보키
    - 속성 개수가 작은 후보키
    - 속성 값의 물리적 크기가 작은(숫자 크기가 작거나 문자열 길이가 짧은) 후보키
대체키(AK: Alternate Key)
- 기본키로 선정되지 못한 후보키
- 둘 이상의 후보키 중 하나를 기본키 지정, 기본키 지정되지 않은 나머지는 대체키
- 대체키는 여러 개 존재 가능
외래키(FK: Foreign Key)
- 특정 릴레이션의 기본키를 참조하는 속성 집합
- 외래키의 값은 참조되는 기본키 값 중에서 값 하나를 참조하여 취함
- 외래키 값은 동일한 값을 기본키 값으로 갖는 투플과의 관계를 자연스럽게 표현
- 기본키와 외래키는 릴레이션 간의 연관성을 표현
- 의미적 연관성이 있음에도 다른 릴레이션으로 분리된 투플 사이의 연결 고리 역할
  - 재귀적 관계?
- 이론적으로 외래키는 다른 릴레이션을 연결할 수도 있고, 같은 릴레이션일 수도 있음
- 이론적으로는
  외래키를 포함하여 PK를 지정할 수도 있음 (식별관계)
  - 기존에 참조관계였다가 식별관계로 바뀌게 되는 것!
무결성 제약 조건(Integrity Constraint)
- 관계형 데이터 모델에서 릴레이션 안의 모든 데이터들을 의미적으로 흠없이 항상 정확하고 완전한 상태로 유지하기 위한 제약 사항
- 구현방식?
  - [방법 1] 개별 응용 프로그램 안에 코드 추가 구현
    → 각 프로그램마다 제약사항 점검 코드 추가
  - [방법 2] DBMS 안의 무결성 제약 조건 설정하여 구현
    → 준수할 공통 제약 사항을 무결성 제약조건으로 권장방법!
- DBMS는 이를 해석하여 데이터를 입력, 수정, 삭제할 때마다 제약조건을 자동적으로 검사
개체 무결성 제약조건(entity integrity constraint)
- 기본키로 지정한 모든 속성은 null 값을 가질 수 없고 릴레이션 안에서 중복되지 않는 유일한 값을 가져야 한다는 제약 사항
- 기본키 제약 조건(primary key constraint)
  - 개체의 유일성을 선언하는 제약조건
  - DBMS에게 기본키를 선언함으로서 즉시 적용됨
- 기본키는 객체 식별자
참조 무결성 제약 조건(referential integrity constraint)
- 외래키로 지정한 속성은 참조하는 릴레이션의 기본키 속성 값과 일치하는 값이나 null 값만 가짐
- 외래키 제약 조건(foreign key constraint)
  - 개체의 참조 관계 선언하는 제약 조건
  - DBMS에게 외래키를 선언함으로써 즉시 적용됨
  - 의미적으로 연관된 두 릴레이션 투플 사이의 일관성 유지 위해 사용
- 외래키는 개체 참조자