들어가며

웹 서비스를 만들 때 사용자는 회원가입을 하고, 상품을 장바구니에 담고, 게시글을 작성하고, 댓글을 남긴다.
이때 발생하는 수많은 데이터는 어딘가에 안전하게 저장되어야 한다.

예를 들어 쇼핑몰 서비스를 만든다고 생각해보자.

사용자 정보, 상품 정보, 장바구니 정보, 주문 정보, 결제 정보, 배송 정보 등이 모두 필요하다.
이런 데이터를 단순히 메모장이나 엑셀 파일에 저장한다면, 데이터가 많아질수록 관리하기 어렵고 오류도 쉽게 발생할 것이다.

그래서 실제 서비스에서는 데이터를 체계적으로 저장하고 관리하기 위해 데이터베이스(Database) 를 사용한다.

이번 글에서는 데이터베이스를 처음 배우는 사람도 이해할 수 있도록 DB 관련 핵심 용어들을 정리해보려고 한다.

1. 데이터베이스(Database)

1) 데이터베이스의 정의

데이터베이스(Database) 는 여러 사람이 함께 사용할 수 있도록 데이터를 체계적으로 모아 저장한 공간이다.

쉽게 말해, 데이터베이스는 서비스에 필요한 정보를 저장하는 데이터 창고라고 할 수 있다.

예를 들어 온라인 쇼핑몰에는 다음과 같은 데이터가 필요하다.

회원 정보
상품 정보
장바구니 정보
주문 정보
결제 정보
배송 정보
리뷰 정보

이러한 데이터를 아무렇게나 저장하면 원하는 정보를 찾기 어렵다.
따라서 데이터베이스는 데이터를 일정한 구조에 맞게 저장하고, 필요할 때 빠르게 조회하거나 수정할 수 있도록 도와준다.

2) 데이터베이스가 필요한 이유

데이터베이스가 필요한 이유는 다음과 같다.

첫째, 데이터를 체계적으로 저장할 수 있다.

예를 들어 회원 정보를 저장할 때 이름, 이메일, 비밀번호, 전화번호 등을 정해진 형식에 맞게 저장할 수 있다.

둘째, 필요한 데이터를 빠르게 찾을 수 있다.

쇼핑몰에서 특정 회원의 주문 내역을 찾거나, 특정 상품의 재고를 확인할 때 데이터베이스를 사용하면 효율적으로 조회할 수 있다.

셋째, 데이터의 중복과 오류를 줄일 수 있다.

같은 회원 정보가 여러 곳에 중복 저장되면 수정할 때 문제가 생길 수 있다. 데이터베이스를 잘 설계하면 이러한 중복을 줄일 수 있다.

넷째, 여러 사용자가 동시에 데이터를 사용할 수 있다.

여러 명의 사용자가 동시에 상품을 주문하거나 게시글을 작성해도 데이터베이스는 이를 관리할 수 있다.

3) 데이터베이스 예시

쇼핑몰의 회원 정보를 데이터베이스에 저장한다면 다음과 같은 형태가 될 수 있다.

user_id	name	email	phone
1	김민지	minji@example.com	010-1111-2222
2	이준호	junho@example.com	010-3333-4444

이 표는 회원 데이터를 저장하는 하나의 구조라고 볼 수 있다.

2. DBMS(Database Management System)

1) DBMS의 정의

DBMS(Database Management System) 는 데이터베이스를 관리해주는 소프트웨어이다.

데이터베이스가 데이터를 저장하는 공간이라면, DBMS는 그 데이터를 저장, 조회, 수정, 삭제할 수 있도록 도와주는 관리 프로그램이다.

대표적인 DBMS에는 다음과 같은 것들이 있다.

MySQL
PostgreSQL
Oracle Database
Microsoft SQL Server
SQLite
MariaDB

2) DB와 DBMS의 차이

데이터베이스와 DBMS는 비슷해 보이지만 정확히는 다르다.

구분	의미
데이터베이스	데이터가 저장된 공간
DBMS	데이터베이스를 관리하는 소프트웨어

비유하자면, 데이터베이스는 책이 꽂혀 있는 도서관 서가이고, DBMS는 책을 정리하고 찾아주는 도서관 관리자라고 할 수 있다.

3) DBMS의 역할

DBMS는 다음과 같은 역할을 한다.

첫째, 데이터 저장

사용자 정보, 상품 정보, 주문 정보 등을 데이터베이스에 저장한다.

둘째, 데이터 조회

사용자가 로그인할 때 이메일과 비밀번호를 확인하거나, 상품 목록을 불러올 때 데이터를 조회한다.

셋째, 데이터 수정

회원이 전화번호를 변경하거나, 상품의 재고가 변경되었을 때 데이터를 수정한다.

넷째, 데이터 삭제

회원 탈퇴나 상품 삭제와 같이 더 이상 필요하지 않은 데이터를 삭제한다.

다섯째, 데이터 보안 관리

모든 사용자가 모든 데이터를 볼 수 없도록 권한을 관리한다.

여섯째, 동시 접근 제어

여러 사용자가 동시에 같은 데이터를 수정하려고 할 때 충돌이 발생하지 않도록 관리한다.

3. 스키마(Schema)

1) 스키마의 정의

스키마(Schema) 는 데이터베이스의 구조와 설계를 정의한 것이다.

즉, 데이터베이스 안에 어떤 테이블이 있고, 각 테이블에는 어떤 컬럼이 있으며, 데이터 타입은 무엇이고, 테이블끼리는 어떤 관계를 가지는지를 정리한 설계도이다.

쉽게 말하면 스키마는 데이터베이스의 설계도라고 할 수 있다.

2) 스키마 예시

쇼핑몰 서비스에서 회원 정보를 저장하는 users 테이블을 만든다고 해보자.

컬럼명	데이터 타입	설명
user_id	INT	회원 ID
name	VARCHAR	회원 이름
email	VARCHAR	이메일
password	VARCHAR	비밀번호
phone	VARCHAR	전화번호

이처럼 어떤 컬럼을 만들고, 각 컬럼에 어떤 종류의 데이터를 저장할지 정하는 것이 스키마 설계이다.

3) 스키마가 필요한 이유

스키마가 필요한 이유는 데이터의 구조를 명확하게 정하기 위해서이다.

예를 들어 email 컬럼에는 이메일 주소가 들어가야 하고, price 컬럼에는 숫자 형태의 가격이 들어가야 한다.
이런 규칙이 없다면 데이터가 뒤죽박죽 저장될 수 있다.

스키마를 잘 설계하면 다음과 같은 장점이 있다.

데이터 구조를 명확히 파악할 수 있다.
잘못된 데이터 입력을 줄일 수 있다.
테이블 간 관계를 체계적으로 관리할 수 있다.
서비스를 확장할 때 유지보수가 쉬워진다.

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

1) ER 다이어그램의 정의

ER 다이어그램(Entity–Relationship Diagram) 은 데이터베이스의 구조를 시각적으로 표현한 그림이다.

여기서 Entity는 개체, Relationship은 관계를 의미한다.

즉, ER 다이어그램은 서비스에 필요한 데이터의 개체와 그 개체들 사이의 관계를 그림으로 나타낸 것이다.

2) Entity란?

Entity 는 데이터로 관리해야 할 대상이다.

쇼핑몰 서비스를 예로 들면 다음과 같은 것들이 Entity가 될 수 있다.

회원
상품
장바구니
주문
결제
배송

각 Entity는 보통 데이터베이스에서 하나의 테이블로 만들어진다.

예를 들어 회원 Entity는 users 테이블이 되고, 상품 Entity는 products 테이블이 될 수 있다.

3) Relationship이란?

Relationship 은 Entity들 사이의 관계이다.

예를 들어 쇼핑몰에서는 다음과 같은 관계가 있다.

한 명의 회원은 여러 개의 주문을 할 수 있다.
하나의 주문에는 여러 개의 상품이 포함될 수 있다.
하나의 상품은 여러 주문에 포함될 수 있다.
한 명의 회원은 장바구니를 가질 수 있다.

이러한 관계를 ER 다이어그램으로 표현하면 데이터베이스 구조를 한눈에 이해하기 쉬워진다.

4) ER 다이어그램 예시

쇼핑몰의 간단한 ER 구조를 글로 표현하면 다음과 같다.

text

회원(User) 1 ─── N 주문(Order)
주문(Order) 1 ─── N 주문상품(OrderItem)
상품(Product) 1 ─── N 주문상품(OrderItem)
회원(User) 1 ─── 1 장바구니(Cart)
장바구니(Cart) 1 ─── N 장바구니상품(CartItem)
상품(Product) 1 ─── N 장바구니상품(CartItem)

여기서 1 : N은 일대다 관계를 의미한다.

예를 들어 회원 1 ─── N 주문은 한 명의 회원이 여러 개의 주문을 할 수 있다는 뜻이다.

5. 릴레이션(Relation), 튜플(Tuple), 애트리뷰트(Attribute)

관계형 데이터베이스를 이해하려면 릴레이션, 튜플, 애트리뷰트라는 용어를 알아야 한다.

1) 릴레이션(Relation)

릴레이션(Relation) 은 관계형 데이터베이스에서 데이터를 저장하는 표 형태의 구조이다.

쉽게 말하면 릴레이션은 테이블(Table) 이라고 이해하면 된다.

예를 들어 회원 정보를 저장하는 users 테이블이 하나의 릴레이션이다.

user_id	name	email
1	김민지	minji@example.com
2	이준호	junho@example.com

위 표 전체가 하나의 릴레이션이다.

2) 튜플(Tuple)

튜플(Tuple) 은 릴레이션에서 하나의 행을 의미한다.

일반적으로 테이블의 한 행은 하나의 데이터 기록을 나타낸다.

예를 들어 다음 한 줄이 하나의 튜플이다.

user_id	name	email
1	김민지	minji@example.com

이 튜플은 한 명의 회원 정보를 나타낸다.

쉽게 말하면 튜플은 데이터베이스 테이블의 row, 즉 행이다.

3) 애트리뷰트(Attribute)

애트리뷰트(Attribute) 는 릴레이션에서 하나의 열을 의미한다.

즉, 테이블의 컬럼이다.

예를 들어 users 테이블에서 다음 항목들이 애트리뷰트이다.

user_id
name
email
phone

쉽게 말하면 애트리뷰트는 테이블의 column, 즉 열이다.

4) 정리

용어	의미	쉽게 말하면
릴레이션 Relation	데이터를 저장하는 표	테이블
튜플 Tuple	테이블의 한 행	row, record
애트리뷰트 Attribute	테이블의 한 열	column, field

6. Primary Key, 기본키

1) Primary Key의 정의

Primary Key, 기본키는 테이블에서 각 데이터를 고유하게 식별하기 위한 값이다.

즉, 테이블 안에서 각각의 행을 구분할 수 있게 해주는 대표 식별자이다.

예를 들어 회원 테이블에서 user_id는 각 회원을 구분하는 기본키가 될 수 있다.

user_id	name	email
1	김민지	minji@example.com
2	이준호	junho@example.com

여기서 user_id 값은 회원마다 다르다.
따라서 user_id를 이용하면 특정 회원을 정확하게 찾을 수 있다.

2) 기본키의 특징

기본키는 다음과 같은 특징을 가진다.

첫째, 중복될 수 없다.

같은 user_id를 가진 회원이 두 명이면 안 된다.

둘째, 비어 있을 수 없다.

기본키는 각 데이터를 식별해야 하므로 NULL 값이 될 수 없다.

셋째, 변하지 않는 값이 적절하다.

이메일이나 전화번호는 변경될 수 있으므로 기본키로 사용하기에는 조심해야 한다.
그래서 보통 user_id, product_id, order_id처럼 별도의 ID 값을 기본키로 사용한다.

3) 기본키가 필요한 이유

기본키가 없으면 테이블 안에서 특정 데이터를 정확히 구분하기 어렵다.

예를 들어 이름이 같은 회원이 두 명 있을 수 있다.

name	email
김민지	minji1@example.com
김민지	minji2@example.com

이 경우 이름만으로는 어떤 회원을 의미하는지 알기 어렵다.
따라서 각 회원을 고유하게 구분할 수 있는 user_id 같은 기본키가 필요하다.

7. Foreign Key, 외래키

1) Foreign Key의 정의

Foreign Key, 외래키는 다른 테이블의 기본키를 참조하는 컬럼이다.

외래키는 테이블과 테이블 사이의 관계를 연결해주는 역할을 한다.

예를 들어 주문 테이블에는 어떤 회원이 주문했는지 저장해야 한다.
이때 주문 테이블에 user_id를 넣고, 이 user_id가 회원 테이블의 user_id를 참조하도록 만들 수 있다.

2) 외래키 예시

users 테이블

user_id	name
1	김민지
2	이준호

orders 테이블

order_id	user_id	total_price
1001	1	30000
1002	1	45000
1003	2	20000

여기서 orders 테이블의 user_id는 users 테이블의 user_id를 참조한다.

즉, 주문 1001번과 1002번은 김민지 회원의 주문이고, 주문 1003번은 이준호 회원의 주문이라는 것을 알 수 있다.

3) 외래키가 필요한 이유

외래키는 데이터 간 관계를 정확하게 유지하기 위해 필요하다.

예를 들어 존재하지 않는 회원의 주문이 저장되면 문제가 생긴다.

text

orders 테이블에 user_id = 999인 주문이 있음
그런데 users 테이블에는 user_id = 999인 회원이 없음

이런 데이터는 잘못된 데이터이다.
외래키 제약조건을 사용하면 존재하지 않는 회원의 주문이 저장되는 것을 막을 수 있다.

4) 기본키와 외래키 차이

구분	기본키 Primary Key	외래키 Foreign Key
역할	한 테이블의 행을 고유하게 식별	다른 테이블과의 관계를 연결
중복 가능 여부	중복 불가능	중복 가능
NULL 가능 여부	불가능	설정에 따라 가능
예시	users.user_id	orders.user_id

외래키는 중복될 수 있다.
예를 들어 한 명의 회원이 여러 번 주문할 수 있으므로 orders 테이블의 user_id에는 같은 값이 여러 번 들어갈 수 있다.

8. SQL Query

1) SQL의 정의

SQL(Structured Query Language) 은 관계형 데이터베이스와 소통하기 위한 언어이다.

데이터베이스에 데이터를 저장하거나, 조회하거나, 수정하거나, 삭제할 때 SQL을 사용한다.

쉽게 말해 SQL은 데이터베이스에게 명령을 내리는 언어이다.

2) Query의 의미

Query 는 데이터베이스에 요청하는 명령문이다.

예를 들어 “회원 목록을 보여줘”, “새로운 상품을 추가해줘”, “주문 상태를 배송 중으로 바꿔줘” 같은 요청을 SQL 문장으로 작성한 것이 SQL Query이다.

3) SQL의 주요 명령어

SQL에서 자주 사용하는 명령어는 다음과 같다.

명령어	의미
SELECT	데이터 조회
INSERT	데이터 추가
UPDATE	데이터 수정
DELETE	데이터 삭제
CREATE	테이블 또는 데이터베이스 생성
DROP	테이블 또는 데이터베이스 삭제
ALTER	테이블 구조 변경

4) SELECT: 데이터 조회

sql

SELECT *
FROM users;

위 쿼리는 users 테이블의 모든 데이터를 조회한다.

특정 컬럼만 조회하고 싶다면 다음과 같이 작성할 수 있다.

sql

SELECT name, email
FROM users;

5) INSERT: 데이터 추가

sql

INSERT INTO users (name, email, phone)
VALUES ('김민지', 'minji@example.com', '010-1111-2222');

위 쿼리는 users 테이블에 새로운 회원 정보를 추가한다.

6) UPDATE: 데이터 수정

sql

UPDATE users
SET phone = '010-9999-8888'
WHERE user_id = 1;

위 쿼리는 user_id가 1인 회원의 전화번호를 수정한다.

여기서 WHERE 조건을 작성하지 않으면 모든 회원의 전화번호가 변경될 수 있기 때문에 주의해야 한다.

7) DELETE: 데이터 삭제

sql

DELETE FROM users
WHERE user_id = 1;

위 쿼리는 user_id가 1인 회원 정보를 삭제한다.

DELETE 역시 WHERE 조건 없이 실행하면 테이블의 모든 데이터가 삭제될 수 있으므로 주의해야 한다.

8) JOIN: 테이블 연결 조회

실제 데이터베이스에서는 데이터가 여러 테이블에 나누어 저장된다.
이때 여러 테이블의 데이터를 연결해서 조회하려면 JOIN을 사용한다.

예를 들어 주문 목록을 조회하면서 회원 이름도 함께 보고 싶다면 다음과 같이 작성할 수 있다.

sql

SELECT orders.order_id, users.name, orders.total_price
FROM orders
JOIN users
ON orders.user_id = users.user_id;

이 쿼리는 orders 테이블과 users 테이블을 user_id 기준으로 연결해서 주문 ID, 회원 이름, 주문 금액을 조회한다.

9. 정규화(Normalization)

1) 정규화의 정의

정규화(Normalization) 는 데이터베이스에서 데이터 중복을 줄이고, 데이터의 일관성을 유지하기 위해 테이블을 적절하게 나누는 과정이다.

쉽게 말하면, 정규화는 데이터를 더 깔끔하고 효율적으로 저장하기 위한 데이터베이스 설계 방법이다.

2) 정규화가 필요한 이유

정규화가 필요한 이유는 데이터 중복으로 인해 여러 문제가 발생할 수 있기 때문이다.

예를 들어 주문 테이블에 회원 정보와 상품 정보를 모두 함께 저장한다고 해보자.

order_id	user_name	user_phone	product_name	product_price	quantity
1	김민지	010-1111-2222	티셔츠	15000	2
2	김민지	010-1111-2222	청바지	35000	1
3	김민지	010-1111-2222	운동화	50000	1

이 경우 김민지의 이름과 전화번호가 반복해서 저장된다.
만약 김민지의 전화번호가 바뀐다면 여러 행을 모두 수정해야 한다.

이런 구조에서는 다음과 같은 문제가 발생할 수 있다.

3) 이상 현상

정규화가 제대로 되지 않은 테이블에서는 이상 현상이 발생할 수 있다.

삽입 이상

필요한 데이터를 추가하려고 할 때 불필요한 데이터까지 함께 입력해야 하는 문제이다.

예를 들어 아직 주문하지 않은 회원 정보를 저장하고 싶은데, 주문 테이블에만 회원 정보를 저장하는 구조라면 주문 정보 없이는 회원을 추가하기 어렵다.

수정 이상

중복된 데이터 중 일부만 수정되어 데이터가 서로 달라지는 문제이다.

예를 들어 김민지의 전화번호가 여러 행에 저장되어 있는데, 한 행만 수정하면 같은 사람인데도 전화번호가 다르게 저장될 수 있다.

삭제 이상

특정 데이터를 삭제할 때 필요한 다른 데이터까지 함께 삭제되는 문제이다.

예를 들어 어떤 회원의 마지막 주문을 삭제했더니 그 회원의 정보까지 사라지는 문제가 생길 수 있다.

4) 정규화의 목표

정규화의 목표는 다음과 같다.

데이터 중복 최소화
데이터 일관성 유지
삽입, 수정, 삭제 이상 방지
테이블 간 관계를 명확하게 설계
유지보수하기 쉬운 데이터베이스 구조 만들기

10. 제1정규형, 1NF

1) 제1정규형의 정의

제1정규형(First Normal Form, 1NF) 은 테이블의 각 컬럼이 하나의 값만 가지도록 만드는 것이다.

즉, 하나의 칸에 여러 개의 값이 들어가면 안 된다.

2) 제1정규형을 만족하지 않는 예시

user_id	name	phone_numbers
1	김민지	010-1111-2222, 010-3333-4444

위 테이블에서는 phone_numbers 컬럼에 전화번호가 여러 개 들어 있다.
이렇게 하나의 칸에 여러 값이 들어가면 제1정규형을 만족하지 않는다.

3) 제1정규형을 만족하도록 수정

user_id	name	phone_number
1	김민지	010-1111-2222
1	김민지	010-3333-4444

이렇게 하나의 칸에는 하나의 값만 들어가도록 분리하면 제1정규형을 만족한다.

하지만 이 구조도 완벽하지는 않다.
회원 이름이 반복되므로 더 나은 설계를 위해 별도의 전화번호 테이블로 나눌 수 있다.

users 테이블

user_id	name
1	김민지

user_phones 테이블

phone_id	user_id	phone_number
1	1	010-1111-2222
2	1	010-3333-4444

이렇게 나누면 전화번호가 여러 개인 회원도 더 깔끔하게 관리할 수 있다.

11. 제2정규형, 2NF

1) 제2정규형의 정의

제2정규형(Second Normal Form, 2NF) 은 제1정규형을 만족하면서, 기본키의 일부에만 의존하는 컬럼을 제거하는 것이다.

조금 어렵게 들릴 수 있지만, 핵심은 다음과 같다.

복합키를 사용하는 테이블에서 어떤 컬럼이 기본키 전체가 아니라 기본키의 일부에만 의존하면 테이블을 분리해야 한다.

2) 복합키란?

복합키는 두 개 이상의 컬럼을 합쳐서 기본키로 사용하는 것이다.

예를 들어 주문 상품 테이블에서 하나의 주문에는 여러 상품이 들어갈 수 있다.

order_id	product_id	product_name	quantity
1	101	티셔츠	2
1	102	청바지	1
2	101	티셔츠	1

여기서 하나의 행은 order_id와 product_id를 함께 사용해야 구분된다.
즉, (order_id, product_id)가 복합키가 될 수 있다.

3) 제2정규형을 만족하지 않는 이유

위 테이블에서 quantity는 주문 번호와 상품 번호가 모두 있어야 의미가 있다.

예를 들어 order_id = 1이고 product_id = 101인 상품의 수량이 2개라는 뜻이기 때문이다.

하지만 product_name은 product_id만 알면 결정된다.
즉, product_name은 복합키 전체가 아니라 product_id에만 의존한다.

이런 경우 제2정규형을 만족하지 않는다.

4) 제2정규형을 만족하도록 수정

테이블을 다음과 같이 나눌 수 있다.

order_items 테이블

order_id	product_id	quantity
1	101	2
1	102	1
2	101	1

products 테이블

product_id	product_name
101	티셔츠
102	청바지

이렇게 나누면 product_name은 상품 테이블에서 관리하고, 주문 상품 테이블에서는 주문과 상품의 관계 및 수량만 관리할 수 있다.

12. 제3정규형, 3NF

1) 제3정규형의 정의

제3정규형(Third Normal Form, 3NF) 은 제2정규형을 만족하면서, 기본키가 아닌 컬럼이 다른 일반 컬럼에 의존하지 않도록 만드는 것이다.

즉, 기본키가 아닌 컬럼들 사이의 종속 관계를 제거하는 것이다.

2) 제3정규형을 만족하지 않는 예시

회원 테이블이 다음과 같다고 해보자.

user_id	name	grade_id	grade_name	discount_rate
1	김민지	1	VIP	10
2	이준호	2	BASIC	0
3	박서연	1	VIP	10

여기서 기본키는 user_id이다.

name과 grade_id는 user_id에 따라 결정된다.
하지만 grade_name과 discount_rate는 user_id가 아니라 grade_id에 따라 결정된다.

즉, 다음과 같은 관계가 있다.

text

user_id → grade_id
grade_id → grade_name, discount_rate

이처럼 기본키가 아닌 컬럼인 grade_id가 또 다른 컬럼인 grade_name, discount_rate를 결정하는 구조는 제3정규형을 만족하지 않는다.

3) 제3정규형을 만족하도록 수정

테이블을 회원 테이블과 등급 테이블로 나눌 수 있다.

users 테이블

user_id	name	grade_id
1	김민지	1
2	이준호	2
3	박서연	1

grades 테이블

grade_id	grade_name	discount_rate
1	VIP	10
2	BASIC	0

이제 회원 테이블은 회원 정보만 관리하고, 등급 정보는 등급 테이블에서 관리한다.

이렇게 하면 VIP 등급의 할인율이 바뀌었을 때 grades 테이블의 한 행만 수정하면 된다.

13. BCNF

1) BCNF의 정의

BCNF(Boyce-Codd Normal Form) 는 제3정규형보다 더 엄격한 정규형이다.

BCNF는 모든 결정자가 후보키가 되도록 만드는 정규형이다.

여기서 결정자는 어떤 컬럼의 값을 결정하는 컬럼을 의미한다.
후보키는 테이블에서 각 행을 고유하게 식별할 수 있는 컬럼 또는 컬럼 조합을 의미한다.

조금 어렵게 느껴질 수 있지만 핵심은 다음과 같다.

어떤 컬럼이 다른 컬럼을 결정한다면, 그 컬럼은 반드시 후보키여야 한다.

2) BCNF가 필요한 이유

제3정규형을 만족하더라도 일부 특수한 경우에는 데이터 중복이나 이상 현상이 남아 있을 수 있다.
BCNF는 이러한 문제를 더 엄격하게 해결하기 위한 정규형이다.

3) BCNF를 만족하지 않는 예시

다음과 같은 수강 신청 테이블을 생각해보자.

student_id	course_name	professor
1	데이터베이스	김교수
2	데이터베이스	김교수
3	운영체제	이교수

이 테이블에서 한 과목은 한 명의 교수만 담당한다고 가정하자.

그러면 다음 관계가 성립한다.

text

course_name → professor

즉, 과목명이 정해지면 담당 교수가 정해진다.

하지만 course_name만으로는 테이블의 각 행을 고유하게 식별할 수 없다.
예를 들어 데이터베이스 과목을 듣는 학생이 여러 명일 수 있기 때문이다.

따라서 course_name은 결정자이지만 후보키는 아니다.
이 경우 BCNF를 만족하지 않는다.

4) BCNF를 만족하도록 수정

테이블을 다음과 같이 나눌 수 있다.

enrollments 테이블

student_id	course_name
1	데이터베이스
2	데이터베이스
3	운영체제

courses 테이블

course_name	professor
데이터베이스	김교수
운영체제	이교수

이렇게 나누면 과목과 교수의 관계는 courses 테이블에서 관리하고, 학생의 수강 신청 정보는 enrollments 테이블에서 관리할 수 있다.

14. 정규형 한눈에 정리

정규형	핵심 개념	쉽게 말하면
제1정규형, 1NF	하나의 컬럼에는 하나의 값만 저장	한 칸에 여러 값을 넣지 않기
제2정규형, 2NF	기본키 일부에만 의존하는 컬럼 제거	복합키 일부에만 관련된 정보는 분리하기
제3정규형, 3NF	기본키가 아닌 컬럼에 의존하는 컬럼 제거	일반 컬럼이 또 다른 일반 컬럼을 설명하지 않게 하기
BCNF	모든 결정자가 후보키가 되도록 설계	무언가를 결정하는 컬럼은 식별자 역할을 할 수 있어야 함

15. 전체 개념 연결해서 이해하기

지금까지 배운 개념들을 쇼핑몰 서비스에 연결하면 다음과 같다.

온라인 쇼핑몰은 회원, 상품, 주문, 장바구니 데이터를 저장해야 한다.
이 데이터를 체계적으로 저장하는 공간이 데이터베이스이다.

데이터베이스를 직접 관리하기 어렵기 때문에 DBMS를 사용한다.
DBMS는 데이터를 저장, 조회, 수정, 삭제할 수 있게 해준다.

데이터베이스를 만들기 전에는 어떤 테이블이 필요하고, 각 테이블에 어떤 컬럼이 들어갈지 정해야 한다.
이 구조를 스키마라고 한다.

스키마를 더 쉽게 이해하기 위해 회원, 상품, 주문 같은 Entity와 이들 사이의 관계를 그림으로 나타낸 것이 ER 다이어그램이다.

관계형 데이터베이스에서는 표 형태로 데이터를 저장한다.
이때 표를 릴레이션, 행을 튜플, 열을 애트리뷰트라고 한다.

각 행을 고유하게 식별하기 위해 기본키를 사용하고, 테이블 간 관계를 연결하기 위해 외래키를 사용한다.

데이터베이스에 명령을 내릴 때는 SQL Query를 사용한다.
SQL을 통해 데이터를 조회하고, 추가하고, 수정하고, 삭제할 수 있다.

마지막으로 데이터 중복과 이상 현상을 줄이기 위해 정규화를 수행한다.
정규화를 통해 데이터베이스를 더 안정적이고 유지보수하기 쉬운 구조로 만들 수 있다.

16. 마무리

데이터베이스는 웹 서비스 개발에서 매우 중요한 개념이다.
사용자가 입력한 정보, 서비스에서 발생하는 기록, 상품과 주문 데이터 등 대부분의 핵심 정보는 데이터베이스에 저장된다.

처음에는 DB, DBMS, 스키마, ERD, 정규화 같은 용어가 낯설게 느껴질 수 있다.
하지만 이 개념들은 서로 따로 떨어져 있는 것이 아니라 하나의 흐름으로 연결되어 있다.

정리하면 다음과 같다.

text

서비스에 필요한 데이터 파악
→ 데이터베이스 설계
→ 스키마 작성
→ ER 다이어그램으로 관계 표현
→ 테이블 생성
→ 기본키와 외래키 설정
→ SQL로 데이터 조작
→ 정규화로 데이터 구조 개선

이 흐름을 이해하면 데이터베이스를 단순히 데이터를 저장하는 공간이 아니라, 서비스를 안정적으로 운영하기 위한 핵심 구조로 바라볼 수 있다.

앞으로 실제 백엔드 개발을 할 때도 데이터베이스 설계는 매우 중요하다.
API를 아무리 잘 만들어도 데이터 구조가 좋지 않으면 서비스 유지보수가 어려워질 수 있기 때문이다.

따라서 데이터베이스의 기본 개념과 정규화 원리를 이해하는 것은 좋은 백엔드 개발자가 되기 위한 중요한 출발점이라고 할 수 있다.

참고하면 좋은 학습 자료

데이터베이스 개론 관련 도서
MySQL 공식 문서
PostgreSQL 공식 문서
생활코딩 SQL 강의
관계형 데이터베이스와 SQL 관련 블로그 글
ERD 설계 도구: ERDCloud, dbdiagram.io, draw.io