프로그래머스 데브코스, 국비지원교육, 코딩부트캠프
🚩 프로그래머스 데브코스 웹 풀사이클 과정 3주차 DAY 1
오늘은 개인 프로젝트로 진행을 했다. 총 두 가지의 과제가 있었는데, 하나는 간단하게 포트폴리오 페이지를 HTML/CSS로 만들어보는 프로젝트가 있었고, 하나는 주어진 정보로 ERD를 그려보는 것이었다. 포트폴리오 페이지는 이전에 진행했던 실습에서 조금씩만 변경했다.
내가 집중한 부분은 바로 ERD였다. 크게 어렵거나 하지는 않았지만 어떤 테이블을 필요로 하고 각 테이블마다 어떤 연관성이 있는지 고민하며 ERD를 그려보았다.
✨ ERD를 그려보자
공연 예매 사이트
1. 회원가입을 할 때 입력 받아야 하는 정보는 회원의 이메일, 이름, 비밀번호다. 로그인을 할 때는 이메일을 필요로 한다.
2. 공연의 정보는 공연의 이름, 날짜, 가격, 공연에 대한 설명과 공연의 사진이 있다.
3. 예약을 할 때 예약자의 이름과 휴대폰 번호, 수량과 총 가격, 예약한 시간이 필요하다.
위와 같이 ERD를 그려보았는데, Velog를 작성하며 다시 찾아보니 수정해야할 부분이 있는 것 같아 해당 부분은 추가로 설명을 하고자 한다.
1. user table
| Attribute | Type | Constraint | Description |
|---|---|---|---|
| id | int | NN, PK | 사용자의 고유 아이디를 저장한다. |
| user_email | varchar | NN, Unique | 사용자의 이메일을 저장한다. |
| user_name | varchar | NN | 사용자의 이름을 저장한다. |
| password | varchar | NN | 사용자의 패스워드를 저장한다. |
먼저 유저의 정보를 저장해두는 테이블이다. 처음에는 user_email을 PK로 지정하려고 했지만 이메일은 차후 수정될 수 있기 때문에 각 유저마다 고유 ID를 부여하고 해당 ID를 PK로 설정하였다. 중복 가입을 막기 위하여 회원가입에 사용되는 user_email은 Unique 값을 부여하였다. 이 외에도 사용자의 이름을 저장하는 user_name 칼럼, 사용자의 패스워드를 저장하는 password 칼럼을 추가하였다.
근데 작성 후 강의를 듣다 보니 보통 칼럼명에는 테이블명을 함께 적지 않는다고 하셔서 칼럼명은 차후 수정이 필요할 것 같다.
2. booking table
| Attribute | Type | Constraint | Description |
|---|---|---|---|
| id | varchar | NN, PK | 고유 예매 번호를 저장한다. |
| concert_id | int | NN, FK | 공연의 고유 아이디를 저장한다. |
| user_id | varchar | NN, FK | 사용자의 고유 아이디를 저장한다. |
| phone_number | varchar | 예매자의 휴대폰 번호를 저장한다. | |
| quantity | int | NN | 예매 수량을 저장한다. |
| total_price | int | NN | 총 예매 가격을 저장한다. |
| booking_time | timestamp | NN | 예매 일자를 저장한다. |
각 예매 공연마다 고유한 예매 번호를 부여하고 해당 칼럼을 PK로 설정하였다.
라고 설정하였지만... 사실 처음 생각한 건 'K12341234' 느낌의 예매 번호를 생각했는데, 여기저기 찾아보니 PK는 외부에 나타나면 안 된다고 하더라. (데이터베이스 수강한 거 맞냐)
그래서 고유 예매 번호를 PK로 하는 게 아니라 다른 테이블의 PK처럼 int 형식으로 auto increment(자동 증가)를 사용하는 게 맞을 것 같다...
예약 시스템에서 어떤 공연을 예약했는지, 또 그 공연을 예약한 사람이 누구인지에 대한 정보가 필요하기 때문에 concert 테이블과 user 테이블에서 각각 PK인 concert_id, user_id를 참조하여 FK로 지정했다. 따라서 booking 테이블은 concert 테이블과 user 테이블과 관계를 맺은 상태다.
회원가입 시 휴대폰 번호 정보를 입력하지 않았고, 혹여 회원가입 시 휴대폰 번호 정보를 입력 받았다고 할지라도 예매자의 휴대폰 번호는 다를 수 있기 때문에 booking 테이블 내에 예매자의 휴대폰 번호를 입력하는 phone_number 칼럼을 추가하였다.
실제로 타 예매 사이트를 확인하면 위 사진과 같이 예매자 이름은 변경할 수 없지만 연락처는 변경할 수 있다. 혹시 휴대폰을 소지하지 않은 사람이 있을 수도 있기 때문에 Not Null 속성을 부여하지 않았다.
그리고 이 외에도 예매 수량을 저장하는 quantity, 총 예매 가격을 저장하는 total_price, 예매 일자를 확인하기 위한 booking_time 칼럼까지 생성하였다. booking_time은 시, 분, 초까지 저장되게 하기 위해 timestamp 타입을 사용하였다. 보통 공연 예매 같은 경우는 티켓팅을 해서 초단위(거의 밀리초)로 끊기는 경우가 많아서 상세하게 나타나는 timestamp 타입이 맞다고 생각했다.
3. concert table
| Attribute | Type | Constraint | Description |
|---|---|---|---|
| id | int | NN, PK | 공연의 고유 아이디를 저장한다. |
| concert_name | varchar | NN | 공연명을 저장한다. |
| date | date | NN | 공연 날짜를 저장한다. |
| price | int | NN | 공연 가격을 저장한다. |
| photo_url | text | NN | 공연의 이미지 URL을 저장한다. |
| description | text | NN | 공연의 소개 문구를 저장한다. |
공연의 정보를 저장해두는 테이블이다. 공연명이 중복되는 경우가 있을 수 있기 때문에 공연의 고유 아이디를 부여하고 해당 칼럼을 PK로 지정하였다. 공연 날짜를 저장하는 date 칼럼은 xxxx-xx-xx 형태로 저장하기 위해 date 타입을 사용하였다. 공연 가격을 저장하는 price 칼럼, 그리고 공연의 이미지 URL을 저장하는 photo_url 칼럼, 공연의 소개 문구를 저장해두는 description 칼럼을 생성했다.
다만 여기서 사진은 각 공연 당 공연을 소개하는 하나의 사진만 첨부한다고 가정해서 해당 테이블에 칼럼을 만들었지만, 만약 여러 개의 사진을 첨부한다면 새로운 테이블을 생성하고 해당 테이블의 PK, 즉 photo_id를 이 테이블에서 FK로 참조해야한다.
이것도 나는 단순히 포스터 한 장만 생각했는데, 생각해보니 프린트를 해서 오프라인에 붙이는 게 아니라 온라인에 올리는 거니... 사진이 여러 장이 필요하지 않을까 싶다. 따로 테이블을 생성해서 거기에 photo_url을 저장하는 게 맞을 것 같다. 아마 테이블을 작성하면
4. photo table
| Attribute | Type | Constraint | Description |
|---|---|---|---|
| id | int | NN, PK | 사진의 고유 아이디를 저장한다. |
| url | text | NN | 사진의 URL을 저장한다. |
이런 식으로 만들어두고 concert table에는 photo_id를 FK 로 참조하면 될 것이다.
🍀마치며
사실 이렇게 ERD를 짠 건 데이터베이스 수업을 들은 이후로 처음인 것 같다. 프로젝트를 할 때는 프론트엔드를 맡았어서 데이터베이스를 직접 짜지는 않았다. 짜면서 느낀 건데 역시나 난 데이터베이스에 대한 이해가 아직 많이 부족하다는 거다...
나름대로 보고서를 작성할 때는 많은 걸 생각하고 작성했다고 생각했는데 시간이 조금 지나고 다시 보니 구멍이 숭숭 뚫린 게 보여서 아주 많이 민망하다. 보고서에서 완전히 반대로 쓴 부분도 있어서 내 눈을 의심하기도 했다.
백엔드를 공부할 때 데이터베이스에 대한 이해는 사실상 필수다보니... 조금 더 열심히 공부해야겠다는 생각이 든다.
