에어비앤비 클론 코딩을 위해 ERD 설계를 해보았다.
ERD CLOUD
이번에 erd 설계를 해본 것이 처음이기도 하고 모르는 개념들도 많아서 블로그에 정리하면서 알아보도록 하자.
참고 블로그
- ERD: 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법 (개체-관계 다이어그램)
-
Tuple, Record : row, 가로로 묶은 데이터셋이며 한 객체에 대한 정보 가지고 있음
-
Column, Attribute : 세로로 묶인 데이터셋이며 속성이다
-
Table : 행과 열로 구성된 데이터 모음
-
PK : 기본키, 고유한 값, 중복/공백 불가
-
FK : 외래키, 다른 테이블의 Primary Key를 참조하는 속성(들)
->특징들:
릴레이션 간의 관계를 표현함
다른 릴레이션의 기본키를 참조하는 속성임
참조하고(외래키) 참조되는(기본키) 양쪽 릴레이션의 도메인은 서로 같아야 함
참조되는(기본키) 값이 변경되면 참조하는(외래키) 값도 변경됨
NULL값과 중복 값 등이 허용됨
자기 자신의 기본키를 참조하는 외래키도 가능함
외래키가 기본키의 일부가 될 수 있음 -
관계
-> 1:1관계:
-> 1:N관계:
-> N:M관계:
개념
위에 걸어둔 링크로 들어가면 ERD CLOUD로 접속 할 수 있다. ERD CLOUD는 웹 사이트 내에서 좀 더 간편하게 erd 설계를 할 수 있도록 만들어둔 사이트이다. 회원가입을 한 뒤 create ERD를 누르면 다음과 같은 창이 나오면서 erd 설계를 할 수 있게 된다.
사용자가 필요한 테이블을 만들고 column들을 추가해 가면서 설계 하면 된다.
ERD 설계
제목에서 볼 수 있듯이 필자는 에어비앤비에 대한 ERD 설계를 진행했다.
위 사진들은 설계한 에어비앤비 ERD의 전체적인 모습과 entity 리스트들이다.
유저
먼저 유저정보 쪽 엔티티들을 살펴보자. 
- 유저 정보 테이블 기본키: 유저의 프로필로 접속하면 /users/show/유저번호 로 접속이 된다. 즉, 유저테이블의 기본키는 유저 번호가 된다. 필자는 편의상 user_id로 PK를 정했다.
또, 유저 페이지를 보면 유저 프로필 사진을 등록 할 수 있다. 실제 에어비앤비 홈페이지 개인정보 페이지에 들어가면 위의 사진과 같이 개인정보들이 나열된다. 따라서, 유저정보 테이블에 개인정보에 관한 속성들을 추가해주었다. 굳이 제공하지 않아도 되는 정보들이 있기때문에 NULL값 허용을 해준 값들도 존재한다. 에어비앤비는 유저의 종류가 숙소를 제공할 수 있는 호스트와 게스트로 나뉜다. 따라서 호스트인지 게스트인지 구분하는 속성을 테이블에 넣어 주었다. created_at, updated_at, status 속성들은 각각 유저정보가 생성된 시간, 수정된 시간, 마지막으로 휴면, 비활성화 등의 상태를 보여주는 속성이다.
유저의 프로필 이미지도 따로 테이블로 생성했다. 프로필 이미지는 유저 정보를 참조하므로 유저 아이디번호를 외래키로 가지는 식별 관계로 연결했다.
- 예약 정보 테이블 기본키: 에어비앤비에서 게스트들이 숙소를 예약하면 위 사진과 같이 예약정보에 대한 페이지가 나오는데 도메인을 보면 예약 식별번호를 통해 접속하는 것을 볼 수 있다. 따라서, 예약 식별 번호가 기본키가 된다.
예약 정보에는 게스트 유저 정보와 예약한 방에 대한 정보가 필요하므로 유저 테이블과 방 테이블을 비식별 관계로 연결한다.
즉, 유저 아이디번호와 방 식별 번호를 외래키로 갖는다.
또 게스트가 체크인 할 날짜, 체크아웃 할 날짜, 예약한 인원에 대한 정보들을 속성으로 넣어줬다. 그리고 마찬가지로 예약정보가 생성된 시간, 수정된 시간, 상태에 대한 속성들도 만들었다.
숙소
이번엔 숙소(방)에 대한 엔티티들을 살펴보자.
위 사진은 한 숙소 페이지의 도메인이다.
- 기본키: 도메인을 보면, 유저 프로필때와 마찬가지로 식별 번호가 있는 것을 볼 수 있다. 따라서, 식별 번호를 기본키로 설정했다.
방을 제공하는 호스트의 아이디, 숙소의 특성, 카테고리 그리고 숙소의 종류같은 정보들을 외래키로 연결했다.
위 사진과 같이 숙소를 검색 할 때 필터를 통해 사용자가 필요로 하는 숙소들만 골라서 볼 수 있다. 그래서 필터들을 따로 엔티티로 만들어서 숙소 테이블과 연결 해 줄 것이다.
위 사진에서 보면 편의시설, 방 종류, 카테고리, 방의 옵션, 특성들과 같은 테이블들을 생성한 것을 볼 수 있다. 편의시설, 옵션 테이블은 N:M 관계이기 때문에 중간테이블을 만들고 연결해 주었다. 모든 필터 테이블들은 각각의 필터 식별번호를 두고 외래키들로 연결해 주었기 때문에 비식별 관계이다.
숙소 페이지를 들어가면 리뷰와 별점이 있는 것을 볼 수 있다. 리뷰를 쓸 때 별점을 추가하는 방식이다. 리뷰 테이블은 리뷰에 따른 식별번호를 기본키로 갖고, 별점은 리뷰에 종속되기때문에 리뷰 식별번호를 외래키이자 기본키로 갖는다. 별점 평가는 청결도, 정확성, 의사소통, 위치, 체크인, 가격 대비 만족도 같은 항목들을 평가하는데 각각의 속성으로 만들고 float 형태로 소수점으로 값을 받는다. 리뷰 테이블은 리뷰를 작성하는 유저의 아이디와 숙소 아이디를 외래키로 받는다.
마지막으로 위시리스트이다.
위시리스트 페이지도 도메인을 보면 식별번호가 있는 것을 볼 수 있다. 따라서 위시리스트 테이블은 식별번호를 기본키로 갖는다. 또, 개인 유저가 만드는 위시리스트이기 때문에 유저 정보 아이디를 외래키로 갖는다.
하지만, 위시리스트와 숙소 정보는 N:M 관계이기 때문에 중간 테이블을 만들어줬다. 방정보의 아이디를 외래키로 갖는다.
후기
처음 해보는 ERD 설계라서 생각보다 쉽지 않고 새로 공부해야 할 것도 많았다. 처음에 간단히 생각하고 접근해서 테이블끼리의 관계를 생각하지 못했고 외래키의 개념도 제대로 공부를 안해서 리셋하고 다시 공부하면서 만들었다. 앞으로 쿼리문도 짜고 결과물도 도출해야하는데, DB에 대한 공부가 많이 필요한 것 같다.
