ERD : Entity Relationship Diagram은 DB 구축에 있어서 가장 기초적인 뼈대 역할을 하며, 릴레이션 간 관계를 정의한 것이다.
서비스 구축시 가장 먼저 신경써야 하며, 나도 프로젝트를 시작할때 첫날은 ERD 작성에 골머리를 썩힌다.
ERD의 중요성
ERD는 시스템의 요구사항을 기반으로 작성되며, ERD를 기반으로 DB를 구축한다.
DB 구축 이후에도 디버깅, 비즈니스 프로세스 재설계시 설계도 역할을 한다.
근데 비정형 데이터는 충분히 표현하지 못하는 단점이 있다.
정규화 과정
릴레이션간 잘못된 종속 관계로 인해 DB에 이상 현상이 일어나서 이를 해결하거나, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정
예를 들면, 회원이 여러 등급을 갖고있거나, 삭제시 중요한 데이터가 같이 삭제되고, 데이터를 삽입해야 하는데, 하나의 필드 값이 NUll이 되면 안되서 삽입이 안되는 현상
정규화 과정은 정규형 원칙을 기반으로 정규형을 만들어 가는 과정이며, 정규화 레벨은 Normal Form인 NF로 표현한다.
제 1 정규형, 제 2 정규형, 제 3 정규형, 보이스/코드, 제 4 정규형, 제 5 정규형이 있고, 숫자가 커질수록 더 빢빡한 정규화다.
정규형 원칙
같은 의미를 표현하는 릴레이션이지만, 더 좋은 구조, 중복성 감소, 독립적 관계는 별개의 릴레이션으로 표현, 각 릴레이션은 독립적 표현이 가능해야 하는 원칙
제1정규형
모든 도메인이 더 이상 분해될 수 없는 원자 값으로 구성된 릴레이션
즉, 한 개의 기본키에 대해 두 개 이상의 값을 갖는 집합이 있어선 안된다. 한 row에 각 컬럼에 한 데이터만 들어있어야 한다는 것.
ID : 1, 수강과목 : CS, 알고리즘 이걸 ID : 1, 수강과목 : CS,ID : 1, 수강과목 : 알고리즘
이렇게 분리 하라는 것.
제2정규형
제 1정규형 + 부분 함수의 종속성 제거
기본키가 아닌 모든 속성이 기본키에 완전 함수 종속적이라는 것이다.
| 유저정보 | 유저 이름 | 수강명 | 성적 |
|---|---|---|---|
| 1 | 범석 | CS | A+ |
| 1 | 범석 | OS | B+ |
| 2 | 창민 | 자료구조 | B- |
| 2 | 창민 | CS | C+ |
이 사앹가 지금 1정규형인데,
| 유저정보 | 유저 이름 |
|---|---|
| 1 | 범석 |
| 2 | 창민 |
와
| 유저 이름 | 수강명 | 성적 |
|---|---|---|
| 범석 | CS | A+ |
| 범석 | OS | B+ |
| 창민 | 자료구조 | B- |
| 창민 | CS | C+ |
이렇게 나눈것이다.
제3정규형
제 2정규형 + 기본키가 아닌 모든 속성이 이행적 함수 종속을 만족하지 않는 상태
쉽게 말하면 이행적 함수 종속은 A -> B -> C 형태다.
| 유저 이름 | 수강명 | 성적 |
|---|---|---|
| 범석 | CS | A+ |
| 범석 | OS | B+ |
| 창민 | 자료구조 | B- |
| 창민 | CS | C+ |
이게 이행적 함수 종속인데, 이름 -> 수강명 -> 성적으로 이어져있다.
이걸 유저이름|수강명, 수강명|성적 으로 나누면 된다.
보이스/코드
제 3 정규형이면서, 결정자가 후보키가 아닌 함수 종속 관계를 제거해서 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태
결정자는 X->Y에서 X이다.
테이블에 학번, 수강명, 강사가 컬럼이면, [CS,창민]을 수강명, 강사에 넣고 싶어. 근데 이러면 학번이 없어서 학번이 null이 되는 문제가 발생한다. 또한, [학번,수강명]이 강사를 결정하고, 강사가 수강명을 결정하는 문제가 발생한다.
즉, 강사 속성이 결정자이지만 후보키가 아니라서 강사를 분리해야 한다.
[학번,강사],[수강명,강사]
근데, 정규형이 딥해진다고 성능이 좋아지는건 아니다. 오히려 조인같은거 때문에 성능이 안좋아질 수 있음
