라이징캠프 (3주차)-2

Do_Doolly·2022년 2월 26일

라이징캠프

목록 보기

8/14

부트캠프 상세내용은 아래 링크[1] 참고.

이번에는 실제 우리 생활에서 쓰이는 어플리케이션 중 하나를 선정해 데이터베이스를 만들어 보려고 한다. 개인적인 분석과 의견이 들어가있기 때문에 절대적으로 정확하지 않으며 내용도 많이 부실하겠지만, 이를 통해서 평소에 사용하는 어플에 어떤 데이터들이 필요하고, 사용되는지 알아본다.

📖 강의 주제

- DB & ERD

DB의 개념 및 구성 요소 파악, ERD 설계 방법론

📝 목표

- DB 서버 구축

AWS RDS 인스턴스 생성
RDS 파라미터 설정
DB 클라이언트 연결

- ERD 설계

상용 App 개념 데이터 모델링 분석
상용 App ERD 분석 및 설계
상용 App 화면 조회 쿼리

▶️ 개발 일지

5. ERD 설계

어떤 어플로 ERD 설계를 할까 고민하다가 평소에 관심이 많고, 요즘 ~~이라기엔 이미~~ 많이 뜨고있는 당근 마켓이 생각났다. 그래서 ERD 설계는 당근 마켓 어플로 진행했다 🥕🥕!!

1) 개념 데이터 모델링

개념 데이터 모델은 엔티티와 엔티티 사이의 관계 도출을 통해 데이터 모델의 골격을 정의한 것이다.
시스템에 대한 고객의 요구사항을 정형화한 모델로 표현함으로써 고객이 요구하는 데이터의 범위 및 구조를 용이하게 확인할 수 있다. (사이트 내용 참고[2])
바커 표기법이나 IE 표기법에 따라 작성해야 하지만 귀찮아서 생각나는대로 적어봤다. 물론 실제로는 이보다 훨씬 많을 거라고 생각한다.

2) 논리 데이터 모델링

논리 데이터 모델이란 물리적인 스키마를 설계하기 전 단계의 데이터 모델이다.
엔티티와 엔티티간 관계 분석 및 데이터의 흐름을 모두 정의한 상태로, 누가 데이터를 사용할 것이며 왜 그 데이터를 사용하는지 혹은 어떻게 데이터를 사용할 것인지를 정의한다. (사이트 내용 참고[3])
데이터베이스 모델링 중 가장 중요한 단계 라고 생각한다. 왜냐면 내 머릿속에 있는 데이터의 사용과 흐름을 실제적으로 구현하기 위한 바로 전 단계이기 때문이다. 여기에 사용되는 다양한 기법과 도구들이 있는데 그 중 ERD 설계로 모델링을 진행했다.
사용한 도구는 AqueryTool이다. OKKY 커뮤니티에 편의성 제공을 목적으로 프로그램을 배포한 처음 글[4]을 봤는데, 이런걸 보면 프로그래머란 정말 멋진 일인 것 같다... 어쨌든 하나씩 생각을 구체화해서 ERD를 만들어봤다!
프레임을 만들고 테이블을 추가하면 본격적으로 ERD 설계 시작이다. 참고로 무료 버전은 테이블을 5개밖에 만들 수 없다. 다른 도구들도 많지만 테이블을 5개 이상 쓰러면 유료 버전을 구입해야 한다.
내용이 너무 많아 일일히 적을 수가 없지만, 다 만들고 축소를 해보니 대략 24개 테이블이 나왔다.
개념 데이터 모델링 할 때 생각해둔 것을 모두 만들지 않았지만, 일단 진행을 위해 DB 클라이언트에서 테이블을 만들어보기로 했다. 왼쪽 상단 ERD 메뉴를 누르면 모든 테이블을 SQL로 생성하는 기능이 있다. 확인을 누르면 텍스트 파일로 DDL이 작성된다.
DB 클라이언트에서 쿼리 콘솔을 연 뒤, 텍스트 파일의 내용을 복사 및 붙여넣기하면 ERD 설계 때 만든 테이블이 모두 만들어지는 것을 볼 수 있다.
각 테이블에 맞는 데이터를 생성해보면서 잘 만들어지는지 확인한다.

3) 화면 조회 쿼리

물리 데이터 모델도 만들었으니 실제로 어플 화면과 비슷하게 나오는지 확인해보자. 일단 테스트 하기 충분한 만큼의 데이터를 테이블에 입력해둔다. FK를 고려하여 필요한 테이블에 적정한 값들을 입력하자.
데이터를 불러오고 싶은 화면을 정해야 한다. 무난한 개인 프로필 정보 화면을 선택했다.
어플 화면에서 보이듯이, 나는 사용자 사진 정보, 닉네임, 매너 온도, 재거래 희망률, 응답률, 사용자 위치, 위치 인증 횟수, 아이디 생성일자를 불러오려고 한다. 쿼리는 아래와 같이 작성했다.

# 검색할 사용자 ID 설정
SET @userID = 'carrot1';

# 프로필1 사용자 데이터 불러오기
SELECT PI.data AS profile_image, U.nickname, U.manner_temperature, U.retrade_rate, U.reply_rate,
       L1.name AS location1, UL1.auth AS location1_auth, UL1.auth_count AS auth_count1,
       L2.name AS location2, UL2.auth AS location2_auth, UL2.auth_count AS auth_count2,
       date_format(U.create_date, '%Y년 %c월 %e일') AS date
FROM Users AS U
         INNER JOIN UserLocations AS UL1
                    ON U.id=@userID COLLATE utf8mb4_unicode_ci AND U.location1=UL1.id
         INNER JOIN Locations AS L1
                    ON UL1.location=L1.id
         INNER JOIN UserLocations AS UL2
                    ON U.id=@userID COLLATE utf8mb4_unicode_ci AND U.location2=UL2.id
         INNER JOIN Locations AS L2
                    ON UL2.location=L2.id
         INNER JOIN ProfileImages AS PI
                    ON U.profile_img=PI.id;

나온 결과 테이블은 아래와 같은데, 각자 만든 테이블과 컬럼 내용에 따라 다르겠지만 나름 필요한 내용을 잘 뽑은 것 같다. 이제 내가 생각한 데이터베이스가 어느정도 당근 마켓의 기능을 구현하는데 일치한다는 것을 알 수 있다!

실제 당근 마켓에서 어떻게 데이터베이스를 만들어서 운영하는지는 모르지만, 일부 데이터를 쿼리로 뽑아보면 얼추 비슷하게 나오는 것을 확인했다. 그리고 하면서 느낀거지만 ERD 설계 때는 조회가 잘 된다고 생각한 것 들이 막상 쿼리로 작성하면 안 될 때가 있다.
데이터와의 관계들을 고려해서 일부 수정을 한 다음 API 설계도 진행할 예정이다.