데이터베이스 개념 정리

실제 서비스에서는 데이터를 단순히 파일에 저장하는 수준을 넘어, 다수의 사용자가 동시에 접근하더라도 데이터의 일관성과 무결성을 유지해야 한다. 이를 가능하게 하는 데이터베이스 시스템의 핵심 용어들과, 데이터를 구조화하는 정규화 과정에 대해 정리해 본다.

---

1. 데이터베이스 (Database)

1) 정의 데이터베이스는 특정 조직의 여러 사용자가 공유하여 사용할 수 있도록 통합해서 저장한 운영 데이터의 집합이다.

2) 파일 시스템과의 비교 및 필요성 과거에는 애플리케이션마다 종속된 데이터 파일(ex. 엑셀, txt)을 사용하는 파일 시스템을 이용했다. 하지만 이는 동일한 데이터가 여러 파일에 중복 저장되는 '데이터 중복성(Redundancy)' 과, 한 곳의 데이터만 수정되어 데이터 간 내용이 달라지는 '데이터 불일치(Inconsistency)' 문제를 야기했다. 데이터베이스는 이러한 중복을 최소화하고, 무결성(데이터의 정확성)과 보안을 중앙에서 제어하기 위해 필수적으로 도입된다.

2. DBMS (Database Management System)

1) 정의 DBMS는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 데이터를 처리해주고 데이터베이스를 관리해주는 소프트웨어 시스템이다.

2) 역할 데이터베이스 자체는 하드디스크에 저장된 데이터의 모음일 뿐이다. DBMS는 이 데이터에 대한 동시성 제어, 백업 및 복구, 권한 관리를 담당한다. 우리가 흔히 사용하는 MySQL, Oracle, PostgreSQL, MariaDB 등이 모두 관계형 데이터베이스 관리 시스템(RDBMS)에 해당한다.

3. 스키마 (Schema)

1) 정의 데이터베이스의 구조와 제약 조건에 관해 전반적인 명세(Specification)를 기술한 것이다. 즉, 데이터베이스의 '설계도' 역할을 한다.

2) 3단계 스키마 구조 데이터의 독립성을 보장하기 위해 스키마는 관점에 따라 3단계로 나뉜다.

• 외부 스키마 (External Schema): 개별 사용자나 응용 프로그램 입장에서 바라본 데이터베이스의 논리적 구조 (뷰).
• 개념 스키마 (Conceptual Schema): 조직 전체 입장에서 바라본 통합된 데이터베이스의 논리적 구조. (일반적으로 DB 설계 시 말하는 스키마)
• 내부 스키마 (Internal Schema): 물리적인 저장 장치 입장에서 데이터가 실제로 어떻게 저장되는지를 정의한 구조.

4. ER 다이어그램 (Entity-Relationship Diagram)

데이터베이스를 구축하기 전, 요구사항을 분석하여 시각적인 모델로 그려내는 방법이다. 개체(Entity)와 그들 간의 관계(Relationship)를 도식화한다.

• 개체 (Entity): 현실 세계에서 독립적으로 존재하는 대상 (예: 학생, 과목). ERD에서는 보통 직사각형으로 표현한다.
• 속성 (Attribute): 개체가 가지는 특성 (예: 학번, 이름). ERD에서는 타원으로 표현한다.
• 관계 (Relationship): 개체 간의 연관성 (예: 수강한다). ERD에서는 마름모로 표현한다.
• 카디널리티 (Cardinality): 두 개체 간의 수량적 대응 관계를 1:1, 1:N, M:N 등으로 표현한다. (예: 한 명의 학생은 여러 과목을 들을 수 있고, 한 과목도 여러 학생이 들을 수 있으므로 '학생'과 '과목'은 M:N 관계다.)

5. 릴레이션, 튜플, 애트리뷰트

관계형 데이터베이스(RDBMS)에서는 데이터를 2차원 표(Table) 형태로 관리하며, 이를 설명하기 위해 다음과 같은 용어를 사용한다.

• 릴레이션 (Relation): 데이터가 저장된 2차원 형태의 표 전체를 의미한다. (위 표 전체)
• 애트리뷰트 (Attribute): 릴레이션의 열(Column)을 의미한다. (학번, 이름, 전공). 애트리뷰트의 총개수를 '차수(Degree)' 라고 한다.
• 튜플 (Tuple): 릴레이션의 행(Row)을 의미한다. 실제 데이터 한 건(Record)이다. 튜플의 총개수를 '카디널리티(Cardinality)' 라고 한다.
• 도메인 (Domain): 하나의 애트리뷰트가 가질 수 있는 원자 값들의 집합이다. (예: 전공의 도메인은 '컴퓨터공학', '경영학' 등 존재하는 학과명 집합이다.)

6. Primary Key (기본키)와 Foreign Key (외래키)

1) Primary Key (기본키, PK) 릴레이션 내에서 각 튜플을 고유하게 식별할 수 있는 핵심 속성이다.

• 조건: '유일성(중복되는 값이 없음)'과 '최소성(식별하는 데 꼭 필요한 속성으로만 구성됨)'을 모두 만족해야 한다.
• 제약조건: 기본키는 절대 NULL(빈 값)을 가질 수 없으며, 이를 '개체 무결성' 이라고 한다.

2) Foreign Key (외래키, FK) 다른 릴레이션의 기본키를 참조하는 속성이다. 릴레이션 간의 관계를 맺어주는 연결고리 역할을 한다.

• 제약조건: 외래키 값은 반드시 참조하는 테이블의 기본키에 존재하는 값이거나 NULL이어야 한다. 존재하지 않는 데이터를 참조하는 것을 막는 이 규칙을 '참조 무결성' 이라고 한다.

7. SQL Query

SQL(Structured Query Language)은 관계형 데이터베이스에서 데이터를 조작하고 정의하기 위한 표준 언어다.

• DDL (Data Definition Language): 테이블 구조를 생성, 변경, 삭제한다. (CREATE, ALTER, DROP)
• DCL (Data Control Language): 데이터 접근 권한을 부여하거나 회수한다. (GRANT, REVOKE)
• DML (Data Manipulation Language): 실제 데이터를 조회하고 조작한다. 백엔드 개발에서 가장 많이 다루는 영역이다.
  • 조회: SELECT * FROM users WHERE age >= 20;
  • 삽입: INSERT INTO users (name, age) VALUES ('홍길동', 25);
  • 수정: UPDATE users SET age = 26 WHERE name = '홍길동';
  • 삭제: DELETE FROM users WHERE name = '홍길동';

---

8. 정규화 (Normalization)와 이상 현상 (Anomaly)

정규화는 데이터베이스 설계 시 데이터의 중복을 최소화하고, 구조를 논리적으로 분해하는 과정이다. 정규화를 하지 않으면 데이터를 조작할 때 다음과 같은 이상 현상(Anomaly) 이 발생할 수 있다.

• 삽입 이상: 특정 데이터를 추가하기 위해 불필요한 데이터까지 억지로 넣어야 하는 현상.
• 수정 이상: 중복 저장된 데이터 중 일부만 수정되어 데이터의 일관성이 깨지는 현상.
• 삭제 이상: 특정 정보를 삭제할 때 연관된 다른 유용한 정보까지 연쇄적으로 삭제되는 현상.

이러한 이상 현상을 막기 위해 단계별로 정규화를 수행한다.

1) 제1 정규형 (1NF)

규칙: 릴레이션의 모든 속성 값은 '원자값(Atomic Value)'만을 가져야 한다.

• 문제 상황: 한 컬럼에 여러 값이 들어가 있는 경우.

• 1NF 적용 후: 분리하여 단일 값을 가지게 한다.

2) 제2 정규형 (2NF)

규칙: 1NF를 만족하면서, 기본키의 일부에만 종속되는 '부분 함수 종속'을 제거해야 한다.

• 문제 상황: 기본키가 복합키(학번+과목코드)일 때, 일반 속성인 '과목명'이 '과목코드'에만 의존하는 경우.

• 2NF 적용 후: 종속성을 분리하여 테이블을 나눈다.
  • 수강 테이블: (학번, 과목코드, 성적)
  • 과목 테이블: (과목코드, 과목명)

3) 제3 정규형 (3NF)

규칙: 2NF를 만족하면서, 일반 속성들끼리의 종속 관계인 '이행적 함수 종속(A->B, B->C)'을 제거해야 한다.

• 문제 상황: 학생 테이블에서 [학번 -> 소속학과]를 알 수 있고, [소속학과 -> 학과 전화번호]를 알 수 있는 상태. 즉, 학번이 학과 전화번호를 간접적으로 결정한다.

• 3NF 적용 후: 학과에 대한 정보를 독립적인 테이블로 분리한다.
  • 학생 테이블: (학번, 이름, 학과명)
  • 학과 테이블: (학과명, 학과 전화번호)

4) BCNF (Boyce-Codd Normal Form)

규칙: 3NF를 만족하면서, 릴레이션의 모든 결정자가 '후보키'여야 한다.

• 문제 상황: 기본키가 (학번 + 과목명)인 수강 테이블이 있다. 교수는 한 과목만 가르친다고 가정할 때, '담당 교수'를 알면 '과목명'을 알 수 있다. 즉, 담당 교수가 결정자 역할을 한다. 하지만 담당 교수 속성만으로는 튜플을 식별할 수 없으므로 후보키가 아니다.

• BCNF 적용 후: 결정자 역할을 하지만 후보키가 아닌 속성을 분리한다.
  • 수강 신청 테이블: (학번, 담당 교수)
  • 강의 담당 테이블: (담당 교수, 과목명)

---

마무리

실무에서 데이터베이스 모델링을 할 때는 BCNF까지만 고려하는 경우가 많고, 복잡한 JOIN으로 인한 성능 저하를 우려해 오히려 테이블을 다시 합치는 '반정규화(De-normalization)'를 수행하기도 한다고 한다. 앞으로 진행될 프로젝트에서 이번에 정리한 스키마 설계와 정규화 개념을 바탕으로 이상 현상이 없는 효율적인 데이터베이스 구조를 직접 설계해 볼 계획이다.