이 글은 직접 학습하거나 구현하며 남긴 개인 기술 기록입니다. 참고 자료가 있는 경우 본문에 출처를 남기고, 틀린 부분을 발견하면 수정합니다.
데이터베이스 기본 개념 정리
출제빈도: 하
빈출 태그: DB 시스템, 스키마 RDBMS, 개체타입, 키
정보처리기사 시험에 나오는 DB 기본 용어들은 서로 분리된 암기 항목처럼 보이지만, 실제로는 “현실의 데이터를 어떻게 표(테이블)로 옮기는가”라는 하나의 문제를 여러 층위에서 설명하는 것이다. 이 글에서는 각 정의를 하나의 예시(학생 관리 시스템)에 계속 대입해가며 정리한다.
데이터베이스 시스템
데이터베이스 시스템은 데이터의 체계적인 집합으로, 데이터를 공유하고 통합하여 저장・운영하는 시스템입니다.
데이터베이스의 종류
- 공유 데이터: 여러 사용자가 공통으로 필요로 하는 데이터
- 통합 데이터: 불필요한 중복을 제거한 데이터
- 저장 데이터: 저장 매체에 저장된 데이터
- 운영 데이터: 조직의 업무를 수행하는데 필요한 데이터
DB 시스템의 특징
- 실시간 접근성
- 지속적인 변화
- 동시 공유
- 내용에 의한 참조 — 데이터의 위치가 아닌 내용에 따라 참조
- 데이터 논리적 독립성 — 논리 구조 변경시 응용프로그램 수정 불필요
데이터베이스의 장단점
장점: 데이터 중복 최소화, 무결성 보장, 보안성 확보, 안정성 향상, 효율적인 데이터 관리 단점: 복잡한 구조로 인한 비용 증가, 전문가 필요
스키마(Schema)
스키마는 데이터베이스의 구조와 제약조건을 정의한 것으로, 데이터 사전에 저장되며 관리 시스템과 구축 환경을 고려해 기술된다. 세 종류의 스키마는 “누구의 관점에서 보는가”로 구분하면 헷갈리지 않는다.
| 스키마 | 관점 | 정의 주체 | 개수 |
|---|---|---|---|
| 외부 스키마 | 사용자 개인 | 사용자 | 여러 개 가능 (사용자마다 다르게) |
| 개념 스키마 | 조직 전체 | DBA | 데이터베이스당 하나만 |
| 내부 스키마 | 물리적 저장장치 | DBA/시스템 | 하나 |
예를 들어 학생 관리 시스템에서, 교무처 직원이 보는 화면(외부 스키마)과 학생이 보는 성적 조회 화면(또 다른 외부 스키마)은 다르게 구성되지만, 그 아래에는 조직 전체가 공유하는 단 하나의 개념 스키마(전체 테이블 구조·무결성 규칙)가 있고, 그 데이터가 디스크에 실제로 어떻게 저장되는지를 정의하는 내부 스키마가 가장 아래에 있다.
데이터베이스 관리 시스템(DBMS)
DBMS는 정의(구조 정의) · 조작(처리/관리) · 제어(보안/권한) 세 기능을 제공하며, 내부적으로는 질의어 처리기, DB 처리기, DML/DDL 컴파일러, 저장 데이터 관리자로 구성된다.
DB 시스템 유형
| 유형 | 구조 | 장점 | 단점 |
|---|---|---|---|
| 파일 시스템 | 파일 단위 관리 | 단순함 | 중복·불일치 관리 어려움 |
| HDBMS (계층형) | 트리 구조 | 빠른 접근 속도 | 구조 변화에 취약, N:M 표현 어려움 |
| NDBMS (네트워크형) | 그래프 구조 | 상하종속관계 해결 가능 | 복잡한 구성 |
| RDBMS (관계형) | 테이블 구조 | 업무 변화 대응력 우수 | 시스템 부하 가능성 |
오늘날 대부분의 서비스가 RDBMS(또는 그 변형)를 쓰는 이유는 “테이블 + 키”라는 단순한 구조만으로 계층형·네트워크형이 각각 갖던 문제(구조 경직성, 복잡한 포인터 관리)를 동시에 완화할 수 있기 때문이다.
관계형 데이터베이스 용어 — 학생 테이블로 이해하기
다음과 같은 학생 테이블이 있다고 하자.
| 학번 | 이름 | 학과 |
|---|---|---|
| 20250001 | 김선영 | 컴퓨터공학과 |
| 20250002 | 이철수 | 전자공학과 |
- 개체 타입(Entity Type): “학생”이라는 개념 자체 → 테이블(릴레이션)에 해당
- 속성(Attribute): 학번, 이름, 학과 각각 → 하나의 열(Column)
- 도메인(Domain): “학과” 속성이 가질 수 있는 값의 집합(예: 컴퓨터공학과, 전자공학과…)
- 튜플(Tuple):
(20250001, 김선영, 컴퓨터공학과)한 줄 → 행(Row) - 릴레이션(Relation): 이 표 전체 — 차수(Degree)는 열의 개수(3), 기수(Cardinality)는 행의 개수(2)
키(Key) — 위 예시로 구분하기
| 키 종류 | 정의 | 예시(학생 테이블 기준) |
|---|---|---|
| 슈퍼키 | 유일성만 만족(최소성 불필요) | {학번, 이름} — 학번만으로도 유일하지만 이름을 더해도 여전히 유일 |
| 후보키 | 유일성 + 최소성 만족 | {학번} |
| 기본키(PK) | 후보키 중 실제로 선택된 것 | 학번 |
| 대체키 | 기본키로 선택되지 않은 후보키 | (만약 이메일도 유일하다면) 이메일 |
| 외래키(FK) | 다른 릴레이션의 기본키를 참조 | “수강신청” 테이블의 학번 컬럼이 “학생” 테이블의 학번을 참조 |
슈퍼키와 후보키를 헷갈리는 경우가 많은데, 기준은 “더 줄여도 유일성이 유지되는가”이다. {학번, 이름}은 학번 하나만 남겨도 유일하므로 최소성이 없어 슈퍼키에 그치고, {학번}은 더 이상 줄일 수 없으므로 후보키가 된다.
핵심 정리
- 스키마 3단계는 “누구 관점인가”(사용자/조직 전체/저장장치)로 구분한다.
- 릴레이션의 차수는 열 개수, 기수는 행 개수 — 헷갈리면 “차수는 세로(속성), 기수는 가로(행 수)”로 기억한다.
- 슈퍼키·후보키·기본키는 결국 “유일성을 만족하는 속성 집합” 안에서 범위가 좁아지는 관계다: 슈퍼키(유일성만) ⊇ 후보키(유일성+최소성) ⊇ 기본키(후보키 중 선택 1개).
댓글이 보이지 않으면 GitHub에 로그인한 뒤 새로고침해 주세요. 공개 댓글은 로그인 상태에서 더 안정적으로 표시됩니다.