조장이다보니 DB를 혼자 설계하겠다고는 했으나.... oracle 며칠 책으로 배운 게 전부여서..... 😫 도대체 어떻게 설계를 해야하는가 정말 막막했지만 최대한 다른 프로젝트 참고하면서 만들어 본다.. !!!
<ver.1>
- reviews 테이블은 members, movie 의 자식
- rivews 테이블은 기본키로 reviewsID를 가지고 있고 복합키로는 reviewsID + MemberID를 가지고 있다.
외래키는 memberID와 moviedID를 가지고 있음. - movie 테이블에서 adminID는 영화를 등록할 때 관리자가 맞는 지를 확인하는 보안상의 이유로 참조한 것
- member가 리뷰를 작성할 수도 있고 안할 수도 있음. (one-to-many relationship)
- 선생님한테 물어보니 Admin을 굳이 따로 테이블로 만드는 것보다 member 테이블에 포함시키고 나중에 부트에서 권한? 레벨? 같은 걸 배우는데 그렇게 사용하는 게 더 좋다고 하셔서 admin은 없애기로 함.
<ver.2>
admin 테이블 없애면서 또 여러 프로젝트를 참고하는데 생각해보니 한 영화에는 여러 명의 감독, 여러 명의 출연진, 여러 개의 장르가 있을 수 있다.... 😱
한 감독이 여러개의 영화를 만들 수 있음(크리스토퍼 놀란만 해도 영화가 한 둘이 아니지..)
한 영화에 여러명의 감독이 있을 수 있음(연출 감독, 음향 감독 뭐..)
한 출연진이 여러개의 영화에 출연할 수 있음
한 영화에는 여러명의 출연진이 있음
한 영화는 여러개의 장르를 가질 수 있음
한 장르는 여러개의 영화를 가질 수 있음
한 명의 회원이 여러 개의 리뷰를 작성할 수 있음
한 명의 회원이 여러 영화의 리뷰를 작성할 수 있음
짜다보니 영화에 content도 없고 movie와 reviews에 중복되는 content 등이 구분이 잘 안된다는 의견이 있어서 이것도 필드명을 변경...
<ver.3>
PK로 들어가는 모든 ID를 number 타입으로 해서 시퀀스를 주려고 했는데 member id는 숫자보다는 스트링 타입 아이디로 주는 게 맞는 것 같아서... (memberID(고유번호)+ID 해도 되겠지만 너무 복잡해진다.... 4일짜리 프로젝트임을 기억하자....)
-> movie, reviews, actor, director, genre에 시퀀스 적용했음!
movie에 content없어서 추가하고 테이블마다 이름 구분할 수 있게... 등등 수정...
일단은 최종은 이렇게 ERD 설계를 마쳤다. 다시 말하지만 4일짜리 프로젝트라 데이터 전이가 잘 되는가? 를 중점에 두고 하라고 했던 건데 어쩌다보니 어쩌다보니 조금 더 자세하게 설계를 한 것 같다.... ERD를 처음에 잘못 설계하면 어지러워진다고 몇 번 들었던 적이 있어서.... 🤔
처음 만들어 보는 거라서 테이블명, 필드명, 다대다일 때 어떻게 처리를 해야하는 지 등 막막했는데 여러 프로젝트에서 보다보니 어느정도 패턴은 비슷한 것 같아 따라서 구현해봤다...
다대다 관계일 때 교차(연관)정보를 저장하는 테이블(=교차 엔티티)를 별도로 만든다는 것도 알게 됐다. 예를 들어 위의 설계에서 movie_genre 처럼 영화의 장르가
1. 한 영화에 여러 장르가 있을 수 있다. (로맨스+스릴러 등)
2. 한 장르에 여러 영화가 있을 수 있다. (로맨스 영화1, 로맨스 영화2 ...)와 같은 경우 genre_id는 genre 테이블에서 참조하고 movie_id는 movie 테이블에서 참조한다.
join을 이용해서 특정 영화의 장르와 타이틀을 가져올 수도 있다!
데이터 가져오는 걸 해보니 필드명은 movie_title 이런식으로 하는게 아니라 그냥 title로 해야겠다... 너무 쓰기가 불편하다 ㅠㅠ... 조원이 구별을 못하는 것 같아서 보기 편하라고 변경했는데 막상 사용을 하려니 너무너무 불편하다... 자동완성으로 불러와지는데 xml에서는 이 기능도 없을테니까
