[정보처리기사 실기 이론] 논리 데이터 모델링 정규화 단계 뜯어보기

[자격증/정보처리기사] - [정보처리기사 실기 이론] 데이터 무결성 종류 - 개체/참조/속성/사용자정의/키 무결성

🧩 정규화란?

데이터베이스를 잘 설계하려면, 테이블을 어떻게 나눌지 잘 고민해야 한다.
정규화는 중복되는 데이터를 줄이고, 데이터의 일관성과 효율을 유지하기 위한 설계 방법이다.
이걸 하지 않으면 삽입 이상, 삭제 이상, 갱신 이상 같은 문제가 생길 수 있다.

---

✅ 예시로 시작

아래처럼 하나의 테이블이 있다고 가정한다.

학번	이름	전공	과목	교수명
101	철수	컴공	DB	김교수
101	철수	컴공	OS	박교수
102	영희	경영	마케팅	이교수

 

이 테이블은 겉보기에 괜찮아 보이지만, 이름이나 전공이 계속 반복되고 있다.
이런 식으로 반복되는 정보는 나중에 문제가 될 수 있다.
이걸 단계별로 정규화하면서 더 좋은 구조로 바꿔보자.

---

[원부이결다조]

✅ 제1정규형 (1NF) - 원자화

한 셀에 여러 값이 있으면 안 된다.

각 칸(속성)에는 하나의 값만 있어야 한다.
예를 들어 과목이 한 셀에 ‘DB, OS’ 이런 식으로 적혀 있으면 안 된다.
이럴 경우엔 행을 나눠서 따로 저장해야 한다.

🧾 예전 형태 (비정규형):

학번	이름	전공	과목명
101	철수	컴공	DB, OS

 

✅ 1NF로 바꾸면:

학번	이름	전공	과목명
101	철수	컴공	DB
101	철수	컴공	OS

 

이제 한 셀에 하나의 값만 있으니 1NF를 만족한다.

---

✅ 제2정규형 (2NF) - 부분함수 종속 제거

부분 종속 없애기 – 기본키의 일부에만 종속된 속성을 분리한다.

 

기본키가 복합키(예: 학번+과목명)일 때,
그 일부(학번이 기본키인 경우)에만 의존하는 속성이 있으면 안 된다.
이럴 땐 테이블을 나눠야 한다.

 

🔑 먼저 기본키 개념

기본키(Primary Key)는 테이블에서 각 행을 고유하게 구분할 수 있는 값이다.
예를 들어, "학생 테이블"에서 학번만으로 학생을 구분할 수 있으면, 학번이 기본키가 되는 거고,
"수강 테이블"처럼 한 명이 여러 과목을 들을 수 있는 경우에는 학번 + 과목명을 합쳐서 기본키로 쓸 수 있다.

---

📦 예시 테이블

아래는 학생이 어떤 과목을 수강하는지를 저장하는 테이블

학번	과목명	학생이름	전공
101	DB	철수	컴공
101	OS	철수	컴공

 

• 여기서 기본키는 (학번 + 과목명) -> 왜냐하면 학번만으로는 과목이 여러 개라서 안 되고,
  과목명만으로도 누가 듣는지 모르기 때문에 둘을 합쳐야 고유한 행이 된다.

---

📌 그런데 “부분적으로만 의존한다”는 건 뭘까?

• 이름과 전공은 과목명이랑은 아무 상관이 없다.
• 이 값들은 학번만 있으면 결정할 수 있다.

즉, 이름과 전공은 기본키 전체(학번+과목명)가 아니라,
기본키의 일부분(학번)에만 의존하고 있다.

=> 이게 바로 부분적 종속이다!!

• ‘부분 종속’이란 말 그대로 기본키 일부에만 의존하는 걸 뜻한다.
• 이게 있으면 제2정규형을 만족하지 못한 상태다.

---

🔧 해결 방법은? → 테이블을 나누면 된다

1. 학생 정보는 따로 빼기

학번	학생이름	전공
101	철수	컴공

 

2. 수강 정보만 남기기

학번	과목명
101	DB
101	OS

 

---

🔁 다시 정리해보면

기본키	학번 + 과목명
부분 종속	이름과 전공은 과목과 관계 없이 학번만 알면 결정됨
문제점	기본키의 일부분(학번)에만 의존하므로 2NF 위반
해결법	학생 정보 따로, 수강 정보 따로 → 테이블 분리

 

---

✅ 제3정규형 (3NF) - 이행함수 종속 제거

이행적 종속 제거 – 기본키가 아닌 속성이 또 다른 속성을 결정하면 안 된다.
즉, 기본키 아닌 애들끼리 서로 의존하면 안 된다.

 

이번에는 기본키 말고 테이블에 있는 속성들끼리 서로 영향을 주는 경우를 정리해야 한다.
이걸 이행적 종속이라고 부른다.

 

📦 예시 테이블

학번	이름	전공코드	전공명	소속대학
101	철수	C01	컴공	공과대학
102	영희	B02	경영	사회대학

 

• 기본키는 학번이다. 학번만으로 학생 한 명을 정확히 알 수 있기 때문이다.
• 그런데 전공코드 → 전공명 → 소속대학이라는 또 다른 관계가 있다.

---

📌 무슨 문제가 있을까?

학번으로 전공코드를 찾고,
전공코드로 전공명을 찾고,
전공명으로 소속대학을 찾아야 한다.
이렇게 되면 속성 간에 2단계 이상 연결된 의존 관계가 생긴다.
이걸 이행적 종속이라고 부른다.

• 학번 → 전공코드
• 전공코드 → 전공명
• 전공명 → 소속대학
  ⇒ 즉, 학번으로 소속대학까지 찾아낼 수 있는 간접적 연결이 생긴다.

---

🔍 그래서 뭐가 문제일까?

만약 전공명을 잘못 수정하면, 그에 따라 소속대학도 꼬인다.
예를 들어 누가 ‘컴공’을 ‘컴퓨터과학’으로 바꾸다가
‘공과대학’도 실수로 ‘정보대학’으로 바꾸면 데이터에 일관성이 깨진다.
즉, 기본키 아닌 애들끼리 서로 영향을 주는 구조가 문제다.

---

🛠️ 해결 방법은? → 속성들끼리 따로 테이블로 분리하기

1. 학생 테이블: 학생에 대한 정보만 남긴다
   | 학번 | 이름 | 전공코드 |
   |------|------|-----------|
   | 101 | 철수 | C01 |
   | 102 | 영희 | B02 |
2. 전공 테이블: 전공코드로 전공명과 소속대학을 따로 관리한다
   | 전공코드 | 전공명 | 소속대학 |
   |-----------|--------|-----------|
   | C01 | 컴공 | 공과대학 |
   | B02 | 경영 | 사회대학 |

---

🧠 이게 바로 제3정규형이다

이제는 모든 속성이 기본키에만 직접적으로 의존하고,
다른 속성에 끌려 다니는 애들(이행 종속)이 없다.
그러니까 제3정규형이 된 거다.

비유로 이해해보기

“학생(학번)이 전공을 가지고 있고,
전공이 소속대학을 알려준다.
근데 학생이 소속대학을 직접 갖고 있으면
전공이 바뀔 때마다 대학 정보도 같이 바뀌어야 하니까 귀찮고 오류가 생긴다.

마치 이런 느낌이다:
🧍‍♂️ 철수는 ‘컴공’을 다니고,
‘컴공’은 ‘공과대학’ 소속이다.
그런데 철수한테 ‘공과대학’이라는 정보도 저장하면,
나중에 ‘컴공’이 다른 대학으로 옮겼을 때 철수 기록도 수정해야 한다.
귀찮고 위험하니까 '컴공'이라는 코드만 저장하고
‘컴공’에 대한 정보는 따로 관리하는 게 낫다.

 

✅ BCNF란? (Boyce-Codd Normal Form) - 결정자 후보키가 아닌 함수 종속 제거

BCNF는 제3정규형보다 조금 더 엄격한 버전이다.
제3정규형도 대부분의 상황에서 충분하지만,
특별한 경우에는 3NF를 만족해도 여전히 구조가 애매한 경우가 있다.
그럴 때 사용하는 게 바로 BCNF다.

 

👉 "모든 결정자(→의 왼쪽 값)는 반드시 후보키여야 한다."

결정자라는 건 '어떤 값을 기준으로 다른 값을 정할 수 있는 열(속성)'이다.

예를 들어 ‘학번 → 이름’이면, 학번이 결정자고, 이름이 종속자다.
이 결정자가 후보키가 아니면 BCNF는 위반된다.

---

📦 예시 테이블

과목명	강의실	교수명
DB	101호	김교수
OS	101호	김교수
통계학	202호	이교수

이 테이블을 보면 과목명은 고유한 수업이니까, 기본키(또는 후보키)는 과목명이다.
근데 보면 강의실 → 교수명이라는 관계도 있다.

---

🔍 문제 분석

• 과목명은 고유하니까 후보키다. → OK
• 근데 강의실이 교수명을 결정한다. (한 강의실에는 한 교수만 강의)
  → ‘강의실 → 교수명’이라는 결정 관계가 생긴다
• 문제는, 강의실은 후보키가 아니다.
  → 결정자(강의실)가 후보키가 아니므로 BCNF를 위반한다

즉, 후보키가 아닌 속성이 다른 걸 결정하고 있을 때 문제가 된다.

---

🛠️ 해결 방법 → 테이블을 다시 나눈다

1. 강의실-교수 테이블

강의실	교수명
101호	김교수
202호	이교수

 

2. 과목-강의실 테이블

과목명	강의실
DB	101호
OS	101호
통계학	202호

 

이렇게 나누면 모든 결정자(→ 왼쪽)가 후보키가 되니까 BCNF 조건을 만족한다.

---

🧠 비유로 쉽게 이해해보기

강의실은 교수를 결정하고, 과목은 강의실을 결정하는데
그 구조가 꼬여 있어서 나중에 교수나 강의실을 바꿔야 할 때 여러 군데를 수정해야 한다.
이럴 땐 테이블을 나눠서
‘강의실이 교수명을 결정한다’는 관계를 독립된 테이블로 분리해야
중복도 없고, 수정도 편하다.

 

✅ 제4정규형 (4NF): 다치 종속 제거

🔎 한 줄 요약

👉 한 기본키에 여러 개의 독립된 정보가 따로따로 붙어 있으면 테이블을 나눠야 한다.

서로 완전히 독립된 정보는 따로따로 관리해야 한다는 게 제4정규형의 핵심이다.

 

✅ 제5정규형 (5NF): 조인 종속 제거

🔎 한 줄 요약

👉 테이블을 여러 개로 나누면 다시 원래대로 합칠 수 있어야 한다.
그런데 합치다 보면 잘못된 조합이 생기면, 그건 5NF 위반이다.

 

불필요하게 쪼개서 잘못된 조합이 생기는 상황이라면
굳이 쪼개지 말고 합쳐서 유지하는 게 맞다.
이게 바로 제5정규형의 핵심이다.

 

---

🎓 정리

정규형	무엇을 없애나	핵심설명
1NF	셀 안의 여러 값	하나의 셀에 하나의 값만
2NF	부분 종속	기본키 일부에만 의존하는 속성 제거
3NF	이행 종속	기본키 아닌 속성끼리의 종속 제거
BCNF	후보키 아닌 결정자 제거	결정자는 반드시 후보키여야
4NF	다치 종속 제거	서로 관계없는 여러 값은 따로 나눈다
5NF	조인 종속 제거	나눈 테이블끼리 합쳤을 때 가짜 조합 생기면 안 된다