[데브코스][5-2] DBMS, RDBMS, PK, FK, 테이블 정규화

단·2024년 5월 13일

데브코스

목록 보기

15/20

1. 데이터베이스란?

데이터 베이스 정의

데이터를 통합으로 효율적으로 관리하기 위한 데이터 집합체

데이터 구조화, 관리함으로써 데이터 중복 막고, 효율적이고 빠른 데이터 연산 가능하게 함

데이터 베이스 장점?

인터뷰에 잘 나오기 생각해보기

1.1 DBMS란?

DBMS 정의

데이터베이스를 운영하고 관리하기 위한 DBMS를 통해서 사용하도록 함

DBMS의 종류

오라클, mysql, maraidb 등

부동의 1위는 오라클

SQL

DBMS 사용하기 위한 언어는 SQL,

CRUD 언어 익숙해지기

2. RDBMS 쓰는 이유?

우리가 검색하고 생각하는 방법은

생각을 꼬리를 물고 진행됨

만약 배우 공유의 이름을 까먹어서 찾으려고 한다면

우리는 공유가 나온 드라마 “도깨비”라고 검색하고 도깨비의 등장 인물을 확인해서 찾을 것

우리 인간 세계의 검색 방법을 데이터베이스에 적용한 게 RDBMS

관계형 데이터 베이스

3. PK, 데이터 중복, 정규화

3.1 PK(primary key)

해당 테이블의 각 행을 유일하게 구별할 수 있는 키 값

각 행을 구별하기 위해서 필요함

3.2 정규화

id (PK)	title	content	author_name	occupation	birthdate
1	"첫 번째 게시글"	"내용 내용 내용"	"홍길동"	"작가"	1980-01-01
2	"두 번째 게시글"	"내용 내용 내용"	"이몽룡"	"시인"	1990-05-15
3	"세 번째 게시글"	"내용 내용 내용"	"성춘향"	"소설가"	1985-09-30
4	"네 번째 게시글"	"내용 내용 내용"	"홍길동"	"작가"	1980-01-01
5	"다섯 번째 게시글"	"내용 내용 내용"	"이몽룡"	"시인"	1985-12-25

우리가 게시글 제작을 위한 테이블을 구성한다고 생각해보기

홍길동과 이몽룡의 경우 이름이 중복됨

이 사람들이 과연 동명이인인지 동일인물인지 알기 위해서 직업, 생년월일이 추가적으로 기입된 부분도 테이블에 추가한다면, 매번 직업, 생년월일 등이 게시글 테이블에 추가될 것

같은 인물이라면, 쓸데없이 데이터가 너무 많고 관리하기 어려움

따라서, 작성자와 작성자의 정보를 담은 테이블을 각기 만들기(정규화)

정규화

테이블을 쪼갠다는 뜻

데이터 중복을 없앤다

4. 테이블 분리, 장-단점

4.1 테이블 분리시키기

🗒️ 게시글 테이블

post_id (PK)	title	content	author_id (FK)
1	"첫 번째 게시글"	"내용 내용 내용"	1
2	"두 번째 게시글"	"내용 내용 내용"	2
3	"세 번째 게시글"	"내용 내용 내용"	4
4	"네 번째 게시글"	"내용 내용 내용"	1
5	"다섯 번째 게시글"	"내용 내용 내용"	3

🗒️ 사용자 테이블

author_id (PK)	name	occupation	birthdate
1	"홍길동"	"작가"	1980-01-01
2	"이몽룡"	"시인"	1990-05-15
3	"이몽룡"	"시인"	1985-12-25
4	"성춘향"	"소설가"	1985-09-30

4.2

장점: 분리해서 데이터 중복을 막는다

단점: 원하는 정보를 한 테이블에서 볼 수 없고 여러 테이블 이동해서 확인해야 한다 → 이건 이미 해결된 문제

4.3 PK

사용자 테이블의 사용자 번호는 PK

게시글 테이블의 사용자 번호는 다른 테이블(사용자 테이블)의 PK이고, 이걸 게시글 테이블에서는 FK(foreign key) 역할을 시킨 것

A 테이블에서 B테이블의 데이터를 찾아가고 싶을 때, 사용하는 key 값

최대한 B 테이블에서 PK 값을 A 테이블의 FK로 쓰는 것이 이상적임

5. 생년월일 바꿔보기, 1-N, 관계의 주인

데이터 베이스 테이블 간 어떤 관계를 가지고 있는지 연관관계는 3가지 종류 1:1, 1:N, N:N

게시글 vs 사용자의 경우 생각해보기

1) 사용자 1명 → 게시글 여러 개 1:N

2) 게시글 1개 당 : 사용자 1명 1:1

게시글 테이블을 보고 사용자 확인 가능 : 연관관계

→ 게시글 테이블을 보고 사용자랑 어떤 관계인지

사용자를 보고는 게시글 테이터 확인 불가능

테이블 간의 연관관계를 확인해야 하면, 양쪽의 관계 모두 생각해보고

테이블 그려보고, 확인

cf) 현업에 계신 분들? 설계 어떻게 잘하나?

DBA분들이 도와주시거나, 하나씩 설계 후, 이걸 기준으로 구현하면, SQL 꼬이거나 너무 길다면 → 설계 뜯어고치기

5. 유튜브 실습

🗒️ 채널

채널 번호(PK)	채널명	구독자 수	영상 수	영상 수	채널주인	회원 id	비밀번호	연락처
1	스탠리	1	5	5	가가가	GA	1111	010-1249-4999
2	스타벅스	20	50	2	나나나	NA	2222	010-9149-4999
3	다이소	50	200	8	다다다	DA	3333	010-6549-4999
4	애플	1000	600	10	나나나	NA	2222	010-4249-4999
5	아마존	10000	900	132	마마마	MA	5555	010-3449-4999

🗒️ 채널(분리)

채널 번호(PK)	채널명	구독자 수	영상 수	회원 id(FK)
1	스탠리	1	5	1
2	스타벅스	20	50	2
3	다이소	50	200	3
4	애플	1000	600	2
5	아마존	10000	900	4

🗒️ 사용자(분리)

회원 id(PK)	채널주인	비밀번호	연락처
GA	가가가	1111	010-1249-4999
NA	나나나	2222	010-9149-4999
DA	다다다	3333	010-6549-4999
MA	마마마	5555	010-3449-4999

채널 vs 사용자

1) 사용자 1명 → 채널 n명 = 1:n

2) 채널 1개 → 사용자 1명 = 1:1

채널 테이블을 보고 사용자 확인 가능 : 연관관계