정규화 쉽게

---

https://youtu.be/Y1FbowQRcmI

 

---

체육센터 등록한 사람들 DB에 정리 해야해

그럼 어떡해?

 

---

이렇게?

이러면

골프 초급 수강신청한 사람 찾을 때 조건식 같은것 where문을 간단히 쓰는게 아니라

LIKE연산자를 쓴다든지 귀찮아진다

 

---

그래서

제1정규화 : 한 칸엔 하나의 데이터만, 이 작업이 완료된 테이블을 제1정규형 테이블이라고 한다

이렇게 하면 나중에 SELECT할 때 성능 문제도 없어질 것

데이터를 수정할 때도 편리

 

---

 

---

컬럼이 늘어났어. 이때?

6000원인걸 다 찾아서 7000원으로 수정해야

데이터가 엄청 많을 땐 가격 하나 수정하는데 몇만개 수정해야해

 

---

이때 제2정규화

현재 테이블은 누가 어떤 프로그램을 등록했는지 저장을 하기 위한 테이블, 가격소개하는 테이블이 아니다

가격컬럼은 현재 테이블 주제와 딱히 안맞아

 

---

이러면 헬스 가격을 수정할 때 한곳만 수정하면 된다

 

단점은 손흥민은 얼마 내야해?하고 싶으면 테이블 한개만 봐선 모른다

다른 테이블 것까지 갖고 와야해. 나중에 select조회할 때 귀찮아져

 

---

그래서 이런 애들이 있고

단점이 있겠지만 단점을 그냥 감수하고 쓴다

 

RDB들은 테이블을 정규화 해두는게 일반적

 

---

정확한 정의가 있어

저것때문에

일단 이것부터

---

대신 Composite primary key라는 게 있다

이거 두개를 연결하면 PK역할을 할 수 있지 않을까?

▽한 사람이 같은 프로그램 두개를 등록하진 않을테니까

 

---

꼭 두개가 아니어도 3개 4개 여도 상관없다

 

---

그럼 이제 다시 partial dependency로 돌아와서

Composite primary key에 종속된 컬럼이 있다.

가격은 프로그램에 따라서만 결정이 돼. 회원번호랑은 상관이 없어.

이 경우에 이 컬럼은 여기에 partial dependency가 있다고 표현

partial dependency가 있는 컬럼을 다른 테이블로 뺄거야! -> 제2정규화 완성

 

어쨌든 완성된 테이블은 제 2정규화 하고 나면

이렇게 되는 것

 

---

어려우면

 

---

제3정규형

 

프로그램마다 누가 가르치는지 해놓고 싶어서 강사 컬럼을 만들고 강사들이 어디 대학 출신인지

그리고 composite primary key가 없어서 partial dependency도 없다

 

프로그램이라는 PK역할을 하는 하나의 컬럼만 있다

 

근데 여기서 출신대학이라는 컬럼을 주목해보면

PK(프로그램)랑 전혀 상관이없다

강사라는 잔챙이 컬럼에만 종속이 돼 있어

 

---

저 작업이 완료된 테이블을 제 3정규형이라고 한다

 

---

장점 : 수정편리

 

---

제2정규형에선 두군데 수정

제3정규형에선 한곳만 수정

 

---

단점

저쪽 테이블에서 데이터를 꺼내와야한다

그래도 RDB들은 제3정규화까지는 해놓는 경우가 많다

 

이제 이 컬럼을 여기에 만들지 말지 알아서 판단할 수 있다!

정규화를 하는게 좋다고 했으니까!