[UMC] Server 3주차 워크북 (데이터베이스)

UMC Server 3주차 워크북 기록입니다. 

---

📌 실습 및 미션

• AWS RDS 구축
• AWS RDS 인코딩 및 타임존 구축
• 당근마켓 분석해서 DB 설계하기

 

1. AWS RDS 구축

https://scshim.tistory.com/218

[AWS] Amazon RDS 시작하기 및 MySQL 워크벤치 연결하기

MySQL 버전 맞게 설정

DB 생성

인바운드 규칙 MYSQL 추가

AWS RDS DB 연결 성공

 

2. AWS RDS 인코딩 및 타임존 구축

https://velog.io/@lsysysy/AWS-RDS-%EA%B5%AC%EC%B6%95feat.-%ED%83%80%EC%9E%84%EC%A1%B4-%EC%9D%B8%EC%BD%94%EB%94%A9-UTF-8-%EC%84%A4%EC%A0%95

AWS RDS 구축(feat. 타임존, 인코딩 UTF-8 설정)

https://smarttechways.com/2022/07/16/error-saving-cannot-modify-a-default-parameter-group-service-amazonrds-status-code-400-error-code-invalidparametervalue-request-id-52f52887-7247-457a-97c3-abc76946cbd2-proxy-null/

Error saving: Cannot modify a default parameter group. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue;

 

parameter group에서 레퍼런스대로 검색해서 수정 후 저장 버튼 눌렀더니 다음과 같은 오류 메시지가 떴다.

Cannot modify a default parameter group. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: a4e9cb3e-4c28-4bb9-b005-7aa3b3a83a1d; Proxy: null)

구글링 해보니 RDS 인스턴스의 default parameter group은 수정할 수가 없기 때문이라고 한다. 추가로 parameter group을 생성해서 RDS 인스턴스의 기본 DB paremeter group을 새로 생성한 것으로 바꿔준다. 그리고 새로 생성한 parameter group에서 인코딩, 타임존 구축을 하니 변경이 잘 된다.

 

parameter group 생성

DB 설정 수정

DB default parameter group 수정 확인

RDS 인코딩 구축

RDS 타임존 구축

MySQL Workbench에서 DB 연결 및 설정 확인

 

3. 당근마켓 분석해서 ERD 설계하기

https://www.erdcloud.com/

ERDCloud

erd 설계 도구는 ERDCloud를 사용했고, 당근마켓 전체 erd를 설계하기엔 무리라고 판단되어 핵심 기능인 '거래(사고 팔기)' 행위를 할 수 있는 erd를 설계했다. 

먼저 다음과 같이 엔티티 추출 후 DB 설계를 해봤다. 간단하게 나만 알아보는 용도로 썼다.

1. 유저: PK, 이름, 전화번호, 비밀번호, 프로필, 닉네임
2. 유저 동네: PK, FK(유저PK), 주소, 활성화여부(active, inactive)
3. 판매글: PK, FK(유저PK), 제목, 카테고리, 생성 시간, 내용, 관심 수, 조회수, 가격, 가격 제안 가능 여부
4. 관심 목록: PK, FK(유저PK), FK(판매글PK)
5. 구매 내역: PK, FK(판매자PK), FK(판매글PK), 약속 시간, 약속 전 알림, 거래완료 여부(상태 - 예약중, 거래완료)
6. review 매너 평가: PK, 칭찬 항목, 칭찬 점수, FK(review PK)
7. review: PK, FK(작성자 유저PK), FK(구매 내역), 거래 후기 내용, 생성 날짜
   • 구매 내역에서 작성자 PK랑 동일한 컬럼이 판매자 PK이면, 판매자가 쓴 리뷰. 구매자가 받은 리뷰 + 1. 받은 거래 후기, 평가 개수 COUNT 가능.
8. 채팅방: PK, FK(articlePK), 생성 시간
9. 채팅 메세지: PK, FK(채팅방PK), FK(유저PK), 생성 시간

하다 보니 수정하는 부분도 생겼다.처음에 판매글과 유저동네와 식별관계를 맺으려 했는데 그 이유는 판매글에 유저 동네 정보를 넣으려 한 거였지만 그럴 필요가 없다. 판매글아이디로 유저 동네 테이블에서 찾으면 된다. 이렇게 쿼리로 찾을 수 있고, 기존 컬럼으로 계산 가능한 컬럼은 중복해서 추가할 필요 없다.

그리고 어느정도 설계 후에 보니 모두 식별 관계로 생각되어 식별 관계로 연결하고 보니 종속 관계가 많이 생겼다. a의 pk를 b가 참조하고, b의 pk이를 c가 참조하면 c에는 a,b가 다 연결 되어 들어 왔다. 식별, 비식별 관계가 헷갈려서 전체적으로 관계 설정이 어려웠다. 그래서 스스로 공부를 더 해보았는데, 그 결과 너무 어렵게 생각하고 있었다.

 

4. ERD 결과

주 식별자 선정으로 너무 많은 속성들을 조합하는 것은 바람직하지 않다. 복잡한 부모 개체 타입의 주 식별자가 자식 개체 타입의 주 식별자로 전이되면, 자식 개체 타입의 주 식별자는 매우 복잡해진다. 이 자식 개체가 또 부모-자식 관계를 맺어 자식 개체 타입에 주 식별자 속성들을 전부 전이한다면? 아주 복잡해진다. (실제 내 경험)

그럼 어떻게 해?

자식 개체 타입에 전이된 속성들을 외래키이자 일반 속성으로 설정하고, 새로운 주 식별자를 도입한다 !

외래 식별자란?

두 개체 타입 사이에 부모-자식 관계가 있을 때, 자식 개체 타입 쪽에 생성되는 속성이다. 자식 개체 타입 쪽에 생성되는 속성이 주 식별자 -> 식별 관계, 일반 속성 -> 비식별 관계이다.🔅 

당근마켓 ERD

erd, DB 설계에 많은 경험이 없는 터라 언제든지 피드백 대환영입니다 :)