- 도쿄
- 수요미식회
- Python
- 건담
- 650d
- 대만
- 사진
- 대만여행
- 시청
- ai_엔지니어링
- 전주
- 축복이
- 글로벌소프트웨어캠퍼스
- 맛집
- SQL
- 17-55
- 축복렌즈
- 우리fis아카데미
- 여행
- k-디지털트레이닝
- 전시
- 군산
- 해리포터
- 우리에프아이에스
- fdr-x3000
- 오사카
- 카페
- CS231n
- 제주도
- 우리fisa
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Today
- Total
브렌쏭의 Veritas_Garage
ERD : 관계형 DB 본문
데이터 정규화는 중복 데이터를 분리하는 것입니다
정규화는 이전에도 말했듯이, 데이터베이스의 작성 이전에 시행되어야 하는 작업이며, 최대한 중복되는 항목을 분리, 분해를 통해 추후 생길 수 있는 데이터 변경이나 추가, 삭제에 유연하게 대응할 수 있도록 한다.
정규형
Normal Form. 줄여서 NF.
- 1NF
- 2NF
- 3NF
- ...
- BCNF ...etc
왜 알아야 하는가?
백엔드 개발자란 자고로 이것저것 할 줄 알아야한다. 할일이 많으니 당연히 알아야 할 것도 많고.
- 프로그래밍 능력
- 네트워크에 대한 개념 이해
- 배포(Publish)에 대한 지식
- 데이터베이스, 종류에 따른 차이점과 장단점
정도는 기본으로 할 줄 알아야하기 때문이다. 인생이란 녹록치가 않다. 어차피 하다보면 하게 된다. 그냥 하면 된다. 걍 해 그냥. 다시 데이터베이스로 돌아가서,
1NF
보통 1~3NF 까지의 과정을 진행하게 되는데, 이 과정 자체가 순차적인 것이다. 먼저 최초로 한 칼럼에 여러 속성이 있는 다가속성을 분리한다. 이 과정에서 열은 일단 정리되지만, 반대로 행은 중복되게 된다.
최대한 칼럼을 세부적으로 나누는 것을 첫번째 목표로 한다.
그러면 이제 열의 내용물이 중복 데이터가 발생하게 된다. 그럼 이제 테이블을 2개로 나누는 것이다. 고유한 값( = Primary Column, Primary Key )을 기준으로 중복되는 행을 최소한도로 억제하면서 진행한다.
만약 2개의 행들이 중복된다면 두가지를 묶어서 한세트로 PK로 취급한다.
2NF
이제 중복되는 칼럼은 없어졌다. 그러나 뭔가 묘하게 속성이 겹치는 것이 보인다. 나뉘어진 테이블에서, 독립적으로 빼낼 수 있는 데이터는 따로 분리한다.
3NF
각 테이블들을 돌아보면서 잘 생각해보라, 과연 그 중 하나의 값이 변해버린다면 골치가 아파질 값이 보이는가? 혹은 연관없는 것이 같은 테이블에 있진 않은가? 를 고민하면서 다시 내용을 분리한다. 내용만으로 생각하면 2정규화와 딱히 다른 개념인지는 알수가 없다. 그러나 차이는 key에 있다. 분리하려는 값이 복합키를 가지고 있다면 2NF, 복합키를 가진 것이 아니라면 새로운 고유키를 주고 3NF로 분류된다.
3정규화까지 진행되면,
중복되는 데이터가 없는 상태로 하나였던 테이블이
각각의 속성으로 나뉘어져 있을 것이다
나누는 기준은 남아있는 테이블을 유심히 바라보면서 저 값이 과연 이 테이블에 있어도 되는 이유를 설명할 수 있는가? 이다. 납득할 수 있게 설명가능하다면 남기고, 설명 못하겠으면 그냥 전부 나눠라.
ERD
이 일련의 과정을 거치고, 그것을 시각적으로 명시하는 것이 ERD라고 할 수 있다.
이러한 수동식 작성법이 있긴한데, 보통 draw.io, ERDcloud 같은 툴을 쓴다. 일단 무료이기도 하거니와, 딱히 내 레벨에서는 크게 문제될 것이 없다.
ERD Cloud
데이터 내용은 없이, pk와 칼럼명만 이용해서 작성한다. 큰그림을 위한 것... 일단 형태를 보면 각 중심 테이블을 시작으로 나눈 테이블들이 보인다. 각 테이블들은 PK로 이어져있고, 아마 중간테이블도 있을 것이다. 그리고 당연히 중간테이블은 거쳐가는 곳이므로 복합키를 가지고 있게 된다.
FK는 Foreign Key로, 분홍색이고 참조키, 외래키라고 불린다. 한 테이블에서 다른 테이블이 어디있는지 알려주는 용도로, PK와는 다르다는 것을 잊지말자.
몇 대 몇
교통사고 과실 비율을 이야기하는 것이 아니다. 각 테이블의 값이 대응하는 값이 하나인지, 여러개인지 알려주는 개념이다. 일대일, 일대다, 다대일, 다대다 관계가 있을 수 있겠고, 일대다나 다대일이나 같은거니까 그건 퉁치고, 앞서가는 놈 제끼고 뭐하고 하면 3가지다.
1:1 1:N N:M
이 과정에서 저번 포스팅에서도 말했던 기괴한 다이어그램 표식들과 규칙이 등장한다. 엔티티와 카디널리티들이다.
N:M은 다대다 관계로, 서로가 서로에게 여러가지 값을 동시에 늘려줄 수 있는 관계가 된다. 위험위험.
따라서 그 사이에 중간 테이블이
필연적으로 생겨 중복으로 생성되는 것을 막는다
MySQL의 데이터타입
문자열
- CHAR(4) : 4글자 고정. 탐색 시 가볍고 빠름
- VARCHAR(100) : 100글자 내에서 지정
- TEXT : 제한없음
숫자
- INTEGER : 정수
- TINYINT : ( 0 or 1 )
- DECIMAL(4, 1) : 실수, 총 4개수, 한자리가 소수.
불린
- TINYINT ( 0 or 1 )
먼저 엑셀을 이용해 테이블을 정리해보자.
물론 나누기만 한다고 능사는 아니다. 오히려 성능을 하락시킬 수도 있다고 한다. 그리고 이 데이터를 기반으로 ERD를 제작한다.
이제 다시 이 다이어그램을 보고, 다시 엑셀을 고친다. 다이어그램으로 옮기고 나면, 이쪽이 레퍼런스다.
'[Project_하다] > [Project_공부]' 카테고리의 다른 글
Storage : 쿠키, 세션 & 로컬 (0) | 2022.04.07 |
---|---|
로그인, 그 참을 수 있는 무거움 (0) | 2022.04.05 |
중간자 공격으로 부터의 탈출 : JWT (0) | 2022.04.02 |
code first & schema first (0) | 2022.03.30 |
데이터베이스 스키마 (0) | 2022.03.30 |
OOP*( NestJS + TypeORM ) = [ DTO & Entity ] (0) | 2022.03.30 |
Nest.js 로 간다 #20220329 (0) | 2022.03.29 |