정규화
정규화는 Redux를 배우며 알게된 상태 정규화를 통해 미약하게나마 알게되었다.
복잡한 상태(JSON)의 중첩을 풀고, 구조를 단순하게 만드는 행위였다.
이때 클라이언트측에서 상태라고 부르는 값은 사실 백엔드측에서 DB를 순회한 후, 데이터를 Http 프로토콜로 넘겨준 값이다. 결국 상태 정규화와 DB에서의 정규화는 비슷한 결 아닌가 싶은데.
아마도 불필요한 중첩 구조를 제거하고 쉽게 데이터를 서칭 할 수 있게 만드는 게 아닐까?
추측은 요쯤하고 한번 정규화가 무엇인지 알아보자.
정규화의 의미
이상현상을 제거하며 데이터베이스를 올바르게 설계해나가는 과정이다.
이상현상이 뭘까?
이상현상
이상현상이란, 불필요한 데이터 중복으로 인하여 릴레이션에 대한 삽입-수정-삭제연산을 수행할때 발생하는 부작용이다.
즉, 상태 정규화를 진행했던 이유와 비슷하다고 볼 수 있다.
데이터 베이스 구조의 문제일까? 예시로 한 번 알아보자
삽입 이상
수업신청을 아직 하지 못한 학생이 데이터베이스에 등록하게될 때, 과목명이 Null로 입력되며 문제가 발생한다.
| 학번 | 이름 | 학과 | 과목명 |
|---|---|---|---|
| 101 | 윈터 | 컴퓨터공학과 | 데이터베이스 |
| 102 | 지젤 | 정보보호학과 | 네트워크 |
| 103 | 카리나 | 컴퓨터공학과 | 객체지향의 이해 |
| 104 | 닝닝 | 컴퓨터공학과 | NULL |
갱신 이상
한 교수가 여러과목을 담당하고있다.
| 교수명 | 과목명 | 연락처 |
|---|---|---|
| 김교수 | 데이터베이스 | 010-1234-5678 |
| 이교수 | 운영체제 | 010-1234-5678 |
| 박교수 | 네트워크 | 010-5678-1234 |
| 김교수 | 객체지향의 이해 | 010-6767-6767 |
이때 김교수의 연락처를 수정했는데, 하나의 튜플만 수정한다면 데이터 불일치가 일어나게 된다.
삭제 이상
| 학번 | 이름 | 과목명 | 교수명 |
|---|---|---|---|
| 101 | 윈터 | 데이터베이스 | 김교수 |
| 102 | 지젤 | 네트워크 | 박교수 |
| 103 | 카리나 | 객체지향의 이해 | 김교수 |
만약 데이터베이스과목이 폐지된다면, 윈터학생의 정보(학번, 이름)도 잃게된다. 즉, 꼭 필요한 데이터도 같이 삭제된다.
위에 소개된 예시들을 어떻게 정규화 할까?
함수 종속
정규화는 이상현상을 방지하기위해 릴레이션을 분해하는 과정을 뜻한다.
=> 상태정규화에서 계층구조를 잘 쪼개는 행위와 비슷하다!
이때 함수적 종속성을 판단하여 정규화를 수행한다.
함수란 무엇일까?
존재하는 f(x)함수에 어떤 x값을 대입했을때 항상 y값 하나만 도출된다.
예를들어 f(12)라는 값을 구했을때 값이 단 하나 a여야한다. 만약 a,b가 된다면 함수가 아니다.
즉, X라는 변수에 따라 Y값이 결정된다. 이를 X가 Y를 함수적으로 결정한다, Y가 X에 함수적 종속되어있다라고 표현하며 기호로 X → Y라고 표현한다.
한 번 예를 들어보자.
함수적 종속 예시
| 학번 | 이름 | 학과 | 연락처 |
|---|---|---|---|
| 101 | 카리나 | 컴퓨터공학과 | 010-1234-5678 |
| 102 | 윈터 | 정보보호학과 | 010-5678-1234 |
| 103 | 지젤 | 컴퓨터공학과 | 010-8765-4321 |
| 104 | 닝닝 | 산업공학과 | 010-4321-8765 |
위 릴레이션에서 각 튜플을 유일하게 구분하는 방법은 쉽게 학번을 떠올릴 수 있다.
즉 학번을 알아내면 이름,학과,연락처를 알아낼 수 있다.
학번이 나머지 셋을 함수적으로 결정한다 학번 → (이름, 학과 연락처)
어디서 봤던 개념같은데, 기본키아닌가?
사실 기본키, 후보키는 각 튜플을 유일하게 구분할 수 있으므로 다른 모든속성들을 함수적으로 결정할 수 있다.
하지만 기본키나 후보키가 아니어도 다른 속성값을 유일하게 결정한다면 함수종속관계에서 X(결정자)가 될 수 있다.
| 직원 ID(기본키) | 이름 | 이메일 | 부서 |
|---|---|---|---|
| 101 | 카리나 | karina@example.com | 개발팀 |
| 102 | 윈터 | winter@example.com | 마케팅팀 |
| 103 | 지젤 | gisel@example.com | 개발팀 |
| 104 | 닝닝 | ningning@example.com | 인사팀 |
기본키인 직원ID가 나머지 셋을 함수적으로 결정할 수 있다. 그러나 이메일또한 중복될 수 없으므로 기본키가 아니지만 함수적으로 결정할 수 있다.
=> 결국 후보키는 가능하다는 말이다. 만약 기본키, 후보키가 둘 다 아니라면, 결정자가 될 수 없을 것이다. (추측임!)
함수종속 3가지
함수종속에는 3가지 종류의 종속이 존재한다.
한번 예시로 알아보자.
| 학생 ID | 학생 이름 | 과목 ID | 교수 | 성적 |
|---|---|---|---|---|
| 101 | 카리나 | CS101 | 김 교수 | A |
| 102 | 윈터 | CS101 | 김 교수 | B+ |
| 103 | 지젤 | CS102 | 이 교수 | A- |
| 101 | 카리나 | CS102 | 이 교수 | B+ |
| 104 | 닝닝 | CS101 | 김 교수 | C |
-
부분 함수 종속
여기서 기본키는
학생 ID + 과목ID가 된다.
이때 복합키인학생ID + 과목ID에서과목ID는 필요하지 않고,학생ID만 있어도교수의 이름을 알 수 있다.
즉, 복합키 일부에만 종속(학생 ID → 교수)되어있다. -
완전 함수 종속
특정 학생의 성적을 알고싶다면, 과목또한 알아야한다. 따라서
학생ID + 과목ID가 필요하다.
즉, 복합키의 모든 속성(학생 ID, 과목 ID → 성적)이 결합되어 성적을 결정한다. -
이행적 함수 종속
여긴 새로운 예시가 필요하다
직원 ID 직원 이름 부서 ID 부서 이름 101 카리나 D01 개발팀 102 윈터 D02 마케팅팀 103 지젤 D01 개발팀 104 닝닝 D03 인사팀 직원 ID → 직원 이름
직원 ID가 있으면 해당 직원의 직원 이름을 알 수 있다.부서 ID → 부서 이름
부서 ID가 있으면 해당 부서 이름을 알 수 있다.직원 ID → 부서 이름
직원 ID → 부서 ID가 있고,부서 ID → 부서 이름이므로,직원 ID → 부서 이름도 성립한다.아하 그러니까, 삼단 논법 이구만?
정규화 파트에서 계속!
