두 번째 정규형(2NF) 원칙

테이블이 두 번째 정규형에 있다고 하려면 다음 조건을 만족해야 해:

1. 이미 첫 번째 정규형(1NF)에 있어야 해.
2. 모든 비키 컬럼이 전체 기본키에 의존해야 하고, 키의 일부에만 의존하면 안 돼.

기본키가 여러 필드로 구성된(복합키) 경우, 어떤 비키 속성(컬럼)도 그 키의 일부에만 의존하면 안 돼. 다시 말해, 2NF는 부분 종속성을 없애는 거야.

2NF 위반 예시

예를 들어, student_courses(학생과 강의) 테이블이 있다고 해. 이 테이블은 학생, 그들의 강의, 그리고 강사 정보를 저장해:

• student_id와 course_id가 합쳐져서 복합 기본키가 돼.
• 근데 course_name이랑 instructor_name 컬럼을 봐봐. 얘네는 course_id에만 의존하고, 전체 키(student_id, course_id)에는 의존하지 않아.

이게 바로 부분 종속성이야! course_name이랑 instructor_name은 복합키의 일부(course_id)에만 의존하지. 이건 2NF 원칙 위반이야.

테이블을 2NF로 바꾸기

우리의 목표는 부분 종속성을 없애는 거야. 테이블을 둘로 나누면 중복도 줄고 데이터 일관성도 좋아져.

강의 정보를 따로 courses 테이블로 분리해보자:

메인 테이블은 이렇게 간단해져:

이제 모든 컬럼이 전체 기본키에 의존하게 됐어. 데이터를 논리적으로 나눠서 2NF 위반을 해결한 거지.

중복 제거의 마법

정규화 전 테이블을 보면 instructor_name 컬럼에 "Lin"이 계속 반복돼. 실제로 수천 개의 데이터가 있다면 얼마나 많이 반복될까? 테이블을 분리하면 이런 중복이 사라지고, 오타("Lin" vs "Ling") 같은 실수도 줄어들어.

실생활 예시

상품 주문을 관리한다고 상상해봐. order_items(주문과 상품) 테이블이 있고, order_id와 item_id가 기본키야:

보다시피, 상품명과 가격이 반복돼. 이건 2NF 위반의 신호야. 왜냐면 item_name과 price는 item_id에만 의존하거든.

2NF로 바꾸려면 items 테이블을 만들어보자:

그리고 order_items 테이블에는 주문과 상품 id만 남겨:

이제 데이터가 코드 리뷰 후처럼 깔끔해 — 중복이 없어.

실습: 직접 해보기!

employee_projects 테이블이 있다고 해. 이 테이블은 직원, 프로젝트, 그리고 프로젝트 매니저 정보를 담고 있어:

한번 해봐:

1. 2NF를 위반하는 종속성을 찾아봐.
2. 테이블을 둘로 나눠서 위반을 해결해봐.

왜 2NF를 지켜야 할까?

도대체 왜 두 번째 정규형(2NF)을 지켜야 할까? 간단해: 데이터가 중복되지 않고 헷갈리지 않게 하려고. 부분 종속성을 없애면 테이블이 더 깔끔해져 — 같은 강사 이름이 줄마다 반복되는 일도 없어. 공간도 아끼고, 한 군데만 수정해도 전체가 최신이 돼.

게다가, 이런 구조면 쿼리 짜기도 쉬워져. 구조가 논리적이고 데이터가 여기저기 흩어져 있지 않으니까, 필터링이나 그룹핑도 더 빠르고 안정적으로 돼. 물론 테이블이 많아지니까 SQL에서 JOIN을 더 써야 하긴 해. 그래도 똑같은 이름이 백 번 반복되는 것보단 JOIN 한 번이 낫지. 대부분의 경우 정규화는 그만한 가치가 있어.

실제 프로젝트에서의 활용

2NF를 알면 이런 데서 써먹을 수 있어:

• 데이터베이스 설계할 때: 테이블이 엉망진창 되는 걸 막아줘.
• 면접 볼 때: 정규형 설명하거나 테이블 정규화 시키라는 질문 자주 나와.
• 실무에서: 기존 데이터베이스 최적화할 때, "모놀리식" 테이블을 정규화된 테이블로 쪼갤 때.

두 번째 정규형(2NF)은 복합 기본키가 있는 테이블에서 부분 종속성을 없애는 데 도움을 줘. 테이블을 논리적 블록으로 나눠서, 모든 컬럼이 전체 키에만 의존하게 만드는 거지. 이러면 데이터베이스 품질도 좋아지고, 중복도 사라지고, 유연성도 높아져. 이제 세 번째 정규형으로 넘어갈 준비됐지? 계속 가보자!