처음으로 간단한 DB를 설계하며 한 고민 [정규화]

이번에는 fast api와 react를 활용해서, 풀스택으로 개발해야 했다.

DB를 설계하면서 고민한 것을 정리해보겠다!

 

정규화에 관해서

회원가입, 로그인 페이지 디자인에서 받아들이는 값은 [전화번호, 차량번호, 비밀번호] 였다.

또한 사용자와 관련해서, [전화번호, 차량번호, 프로필 이미지] 정보가 필요했다.

그래서 User Table을 정말 단순히 짜보면

• id
• phone
• car_number
• password
• profile_image
• join_date [ 가입 날짜 ]
• memo [ 서비스 운영 중, 해당 row의 설명이 필요할 때, 메모용 ]

이러한 칼럼이 필요하다.

하지만, 실제 서비스를 운영하면서 DB를 수정하기 힘든 상황이 발생할 수 있으니, 정말 한 테이블로 끝낼지 면접 준비를 하며 외웠던 정규화를 적용해보기로 했다.

 

- URL 구조는 https://../{id} 형태

- id는 내부 row 식별자이면서 동시에 **외부 식별자(공개 QR 경로)**로 사용

- 로그인은 phone + car_number + password 조합

종속성

어떤 속성[칼럼] 값을 알면 다른 속성 값이 유일하게 정해지는 의존 관계

A → B [ A를 알면 B의 값은 정해진다 = B는 A에 종속한다 ]

ex) id → 전화번호, 차량 번호, ...

 

함수 종속성

y = x + 1 [ x의 값이 정해지면 y의 값이 정해지는 관계 = y는 x의 함수 ]

=> 특정 속성에 다른 특성이 유일하게 결정될 때 '함수적으로 종속한다고 함

 

현재 User Table의 종속성을 살펴보면

• id → 모든 칼럼 정보

 

정규화

테이블을 분해하여 잘못된 종속성으로 발생한 이상현상을 없애는 과정

제 1 정규화

모든 값이 원자 값이어야 한다.

이름	익힌 언어
고감귤	Swift, Python, JS, ...

→

이름	익힌 언어
고감귤	Swift
고감귤	Python

여러가지 값이 하나에 저장되어있다면, 특정 열(row)을 지웠을 때 의도치 않게 지워지는 데이터가 존재할 수 있음.

 

제 2 정규화 [ 기본 키가 복합키가 아니라면 pass ]

기본 키가 복합 키이지만, 다른 속성이 복합 키의 일부에 또 종속되는 경우 이를 분리.

현재 테이블은 id 단독 키이니 넘어가자.

 

제 3 정규화

이행적 함수 종속성이 있는지 확인

ex) A → B → C

현재 테이블은 종속성이 id → 타 속성 값만 존재하기에 이행적 함수 종속성도 존재하지 않다.

id	phone	car_number	password	...	...
1	A	ㄱ	1111	...	...
2	B	ㄱ	2222	...	...
3	C	ㄱ	3333	...	...
.	.	.	.	.	.
5	D	ㄷ	1111	...	...
6	D	ㄹ	1111	...	...

 

오해 할 수 있는 종속성

phone → car_number ?

한 사람이 여러 차량을 보유할 수 있다. 또는 여러 사람이 한 차량을 공유하여 사용할 수 있다. → 1 대 1 대응이 되지 않기 때문에 X

 

이렇게 우리의 테이블은 이미 제3정규화까지 만족하고 있으므로, 현재 설계대로 진행해도 큰 문제는 없을 것 같다.