안녕하세요 보라입니다!💜 벌써 4주차라니! 시간이 참 빠르네요~!
이번 주차 학습 내용은 서버를 다루기 위해서라면 필수인 DB!
저도 지금 학교에서 DB 강의를 수강 중이라서, 어떤식으로 나올 지 흥미가 느껴집니다!
그럼 포스팅 시작하겠습니다😁
- 실습
- 트러블 슈팅
1. 실습
STEP 1. 시스템 분석하기
아래 사진들을 보고 먼저 어떤 정보들이 필요한지 찾아보자!
<프로필>
이름, 닉네임, 프로필 사진, 한줄소개, (안읽은)스토리 유무, 게시물 수, 팔로워, 팔로잉
<피드 게시글>
올린 유저의 닉네임, 프로필 사진, 좋아요 수, 첨부 사진, 글 내용, 댓글 수
<댓글 창>
올린 유저의 닉네임, 프로필 사진, 좋아요 수, 글 내용, 좋아요 수, 리 댓글
↑ 나는 이렇게 생각했음! ↑ ↓ 이제 강의를 들으며 다시 정리해볼까 ↓
<프로필>
유저 닉네임, 유저 이름, 유저 프로필 사진, 유저 소개글, 유저 웹사이트 링크, 게시물 개수, 게시물 사진, 팔로워 수, 팔로잉 수
→ 게시물 사진을 놓침!
<피드 게시글>
(앞에서 중복 제외하고) 게시물 내용, 게시물 좋아요 수, 게시물 댓글 수, 게시물 올린 시간
→ 게시물 올린 시간을 놓침!
<댓글 창>
(앞에서 중복 제외하고) 댓글 내용, 댓글 올린 시간, 태그된 유저, 댓글 좋아요 수, 대댓글 여부
→ 댓글 올린 시간, 태그 유저를 놓침!
STEP 2. 논리에 따라 분류하기
위에서 얻은 정보들은 아래와 같은 논리에 따라 분류할 수 있다.
Entity : 객체
Attribute : 속성
Relation : 관계
강의를 잠시 멈춰 놓고, 내가 임의로 분류해보았다.
Entity : 유저
Attribute :
닉네임
이름
프로필 사진
소개글
웹사이트 링크
팔로워 수
팔로잉 수
Entity : 게시물
Attribute :
개수
사진
내용
좋아요 수
댓글 수
올린 시간
Entity : 댓글
Attribute :
내용
올린 시간
태그 된 유저
좋아요 수
대댓글 여부
→ 이번에는 거의 비슷했지만, 강의에서는 '팔로워 수'와 '팔로잉 수'를 '팔로우'라는 객체로 묶어주었다.
이제 Entity를 Table로, Attribute를 column으로 바꿔줄 것이다!
STEP 3. 물리-관계
데이터 베이스를 모델링할 때 가장 중요한 것은 '정규화'!
중복된 데이터를 최대한 줄이는 것을 뜻한다.
관계?
1명의 유저는 여러 개의 게시물을 쓸 수 있지만, 1개의 게시물을 여러 명의 유저가 나누어 쓰는 것은 어렵다! 게시글-댓글, 유저-댓글도 마찬가지이므로,
유저 : 게시물 = 1 : N
게시글 : 댓글 = 1 : N
유저 : 댓글 = 1 : N
와 같은 관계를 가지는 것을 알 수 있다.
1 : 1 관계는 한 쪽을 다른 한 쪽의 column으로 표현하거나, 두 개의 테이블로 나누어서 관리할 수 있다.
RDS
서버 별로 DB를 1개씩 가지고 있을 때, 서버가 터진다면 DB도 같이 터질 확률이 높다.
따라서, 하나의 데이터 베이스를 공유하는 방식을 생각하게 된다.
구글 아이디로 유튜브도 볼 수 있는 것처럼, 여러 서버가 공유하고 있는 데이터 베이스를 만들 수가 있다.
이것을 RDS라고 하고, 우리는 로컬 DB 대신에 RDS를 구축하여 사용할 것이다!
STEP 4. 테이블 시각화 하기!
나는 UMC에서 할인을 제공해주어서, AQuery Tool이라는 사이트를 두 달에 6000원으로 이용할 수 있게 되었다.
이제 이 AQuery Tool을 이용하여 위에서 내용한 내용들을 시각화해 볼 것이다.
자 먼저, 아래와 같이 ERD - 새로운 ERD 를 눌러준다.
그럼 새로운 ERD를 설정하는 창이 뜨는데, 나는 Mysql을 사용할 예정이기 때문에 다음과 같이 설정해주었다.
설정 후에, 톱니 바퀴 모양을 눌러주면 옵션을 설정할 수 있다.
여기에서 '논리'가 들어가는 속성들은 다 체크 해제 해준다! 나머지는 다 체크!!
살짝 내려서 'SQL 생성 시 FK 무시'까지 체크 해주면 옵션 설정은 완료!
이제 User 테이블 먼저 만들어주겠다.
이때, 테이블 명은 파스칼 방식으로 작성해주어야함! 대문자로 시작하면 된다.
그리고 PK, AI, FK, NULL 을 살펴보자.
PK(Primary key) 주로 int 형을 사용하며 겹치면 안된다. 따라서, AI(Auto Increment) 설정을 체크해준다. AI 설정을 해놓으면 새로운 데이터가 들어올 때마다 1씩 늘어나서 자동으로 설정이 된다!
나는 useridx를 다음과 같이 설정해주었다.
useridx를 시작으로, 아까 정리한 자료들을 다 자료형에 알맞게 설정해주었다!
비어있어도 상관없는 website와 introduce만 NULL을 체크해주었다.
반대로 NULL이 체크 되어있지 않다는 것은, 비어 있으면 안 된다는 것을 의미한다!
이때, 의문이 들 수 있다.
'게시글 사진이 빠졌는데?!' 라고 생각이 든다면, 당신은 정말 꼼꼼한 사람...
게시글 사진은 또 다른 테이블로 관리해야한다.
왜냐하면, 한 게시글에 여러개의 사진을 올렸을 때 중복이 발생할 수 있기 때문이다.
즉, 우리는 정규화를 위해 테이블을 하나 더 만들어줄 것이다!
여기까지 실습을 진행했을 때, 알 수 있는 것은?!
① Url은 길기 때문에 TEXT 타입으로 만든다.
② status, createdAt, updatedAt은 관리, 수정, 삭제를 위해 공통적으로 필요한 컬럼이다.
③ FK 키를 사용하고 싶다면?!
-> 예를 들어 PsotingUrl 테이블에서 Post 테이블의 postidx를 참조하고 싶을 때, PostingUrl의 postidx를 끌어서 Post 테이블의 postidx로 가져가면 된다! 그러면 참조한다는 뜻의 화살표가 생긴다.
Challenge 과제
다음 글로 업로드 하겠습니다😆
2. 트러블 슈팅
딱히 어려운 것이 없었지만, 놓치는 부분이 있었기 때문에 더 꼼꼼히 생각해야될 것 같다!
