📔 DB 테이블 설계, 어떻게 하는게 옳은 방법인가

#공부 #DB #DataBase #설계

어느? 데이터 테이블의 예시

Pasted image 20241220113308.png Pasted image 20241220113315.png

테이블의 효율성과 확장성

위 테이블의 비효율성은 무엇인가?

위 예시의 경우 데이터를 행(Row)이 아닌 열(Column)로 저장한 것으로 보인다.

1. 확장 시 문제점:

페이지가 10개를 초과하면 새로운 페이지에 대해 var11, var12 등의 컬럼을 추가로 만들어야한다. ( 실제로 일어날 뻔 했다. )
이는 테이블 스키마를 수정하는 작업이며, 다음과 같은 위험을 수반한다.
1. 서비스 중단: 테이블 스키마 변경 중 데이터베이스가 잠기거나 애플리케이션이 중단될 가능성이 있다.
2. 코드 변경 필요: 새로운 컬럼에 맞춰 애플리케이션 로직(예: 데이터 입력, 조회 쿼리)을 수정해야 한다.
3. 관리 복잡성 증가: 테이블 구조가 복잡해져 유지보수 비용이 증가한다.
데이터 활용도 제한

-현재 구조는 hit 수 외의 추가 정보를 기록하기 어렵다. ( 나중에 추가해달라고 할것같음. )
- 예: 페이지별 방문자의 디바이스 정보, 지역 정보 등.

2. 비효율적인 데이터 조회:

열로 데이터를 저장하면 특정 페이지의 hit 수를 조회할 때, 각 컬럼을 명시적으로 참조해야 합니다.
- 예: 특정 날짜에 대해 var1 ~ var10의 데이터를 모두 합산하려면 SELECT var1 + var2 + ... + var10 FROM table 같은 비효율적인 쿼리를 작성해야 합니다.
페이지별 hit 데이터를 통계적으로 분석하려는 경우(예: 총합, 평균 등) 쿼리가 복잡해지며, 컬럼이 늘어나면 쿼리 수정이 필요합니다.

- 위의 데이터 테이블의 설계자가, 데이터 테이블을 총 컬럼수를 줄이고

페이지당 hit수 만을 필요로 하기 때문에, 가볍게 작성했다면 어떻게 반박할 것인가?

적어도 이렇게는 만들었어야 하지 않았나?

idx (PK) | xdate (PK)  | page_id  | hit_count
---------------------------------------------
   1     | 20241208    | var1    | 21
   2     | 20241208    | var2    | 15
   3     | 20241209    | var1    | 13

새로운 페이지를 추가할 때 스키마 변경 불필요.
스토리지 효율성 향상 (0 또는 NULL 값 제거).
데이터 분석 및 통계 작업 간소화.
검색, 집계 성능 최적화 가능.

정규화 해보자!

제 1정규화 - 모든 도메인이 원자 값으로만 구성

변경 전 (비정규화된 테이블):

KEY `idx`	KEY `xdate`	`var1`	`var2`	`var3`
1	20241208	21	15	13

원자값을 갖는것 같은데??

맞다. var1, var2 .. 는 각기 다른 페이지의 hit를 저장한다.

하지만, "페이지의 hit 수"라는 속성에서 본다면, 동일한 의미를 여러 셀에 분산 저장한다고 볼 수 있다. 따라서 데이터의 동일 속성을 위반했다고 볼 수 있다.

KEY `idx`	KEY `xdate`	`page_id`	`hit_count`
1	20241208	var1	21
2	20241208	var2	15
3	20241208	var3	13

따라서 다음과 같이 각 컬럼이 진짜 원자값을 갖도록 수정할 수 있다.

제 2정규화 - 모든 비기본 속성이 기본키의 전체에 종속되어야 하며, 기본키의 일부에만 종속되는 부분 종속성이 없어야 함.

간접 종속 가능

예를 들어 누군가.. page_id에 대한 속성을 만들어달라고 하신다면..

다음과 같은 형태를 띄게 된다.

KEY `xdate`	KEY `page_id`	`hit_count`	`page_name`	`category`
20241208	var1	21	Kakao_main	main
20241208	var2	15	Kakao_case1	detail
20241208	var3	13	Kakao_case2	detail

여기서, category는 page_name에 종속되어있으며, page_name은 page_id에 종속되어있다.

페이지 속성(비기본 속성)들이 기본키의 부분적으로 종속되어있다.

결과

KEY `xdate`	KEY `page_id`	`hit_count`
20241208	var1	21
20241208	var2	15
20241208	var3	13

hit_count는 xdate, page_id를 기본키로 갖는다

KEY `page_id`	UNIQUE `page_name`	`category`
var1	Kakao_main	main
var2	Kakao_case1	detaile
var3	Kakao_case2	detaile

category는 page_name를 종속하며, page_name은 page_id -> page_id처럼 간접 종속을 하기 때문에 만족

제 3정규화 - 이행성 함수 종속관계 삭제 (모든 비기본 속성이 기본키에 직접 종속)

속성 A → 속성 B → 속성 C로 이루어진 종속 관계에서, A가 C를 직접 결정하지 않고, B를 통해 C를 결정하는 경우를 말한다.

KEY `page_id`	UNIQUE `page_name`	`category`
var1	Kakao_main	main
var2	Kakao_case1	detaile
var3	Kakao_case2	detaile

해당 테이블에서 간접 종속을 제외한다.

결과

KEY `page_id`	UNIQUE `page_name`
var1	Kakao_main
var2	Kakao_case1
var3	Kakao_case2

KEY `page_name`	`category`
Kakao_main	main
Kakao_case1	detaile
Kakao_case2	detaile