[오픈소스 소프트웨어 프로젝트] 1. DB 엔티티 설계 및 테이블 설계

https://wonsjung.tistory.com/463

[2022년 2학기] 오픈소스 소프트웨어 프로젝트

해당 게시글에서 소개했듯이 지금까지 진행했던 프로젝트를 정리해보려고 한다. 우선, 프로젝트 목적에 맞게 어떻게 데이터베이스 엔티티를 설계했는지 정리해보고자 한다. 
 
아직 데이터베이스 설계에 대한 공부와 고민이 더 필요하기에 부족한 부분이 많이 존재할 것이다. 추가적인 공부를 진행하게 되면서 내가 설계했던 엔티티에 대한 문제점을 발견하게 된다면 그거에 대한 최적화와 수정 부분을 따로 정리하여 업로드 할 예정이다. 

---

1. 프로젝트 기능 소개

▶  먼저 진행했던 프로젝트는 인증 및 인가를 부여받은 회원이 URL정보를 입력창에 입력하면 해당 URL 본문 내용을 텍스트와 시각화 이미지 2개로 변환한 후 사용자에게 반환한다. 원래는 사용자가 입력했던 URL을 개인 페이지에서 조회할 수 있게 구현하려했으나 시간상 개인 페이지가 아닌 모든 사용자가 입력했던 URL 정보를 저장한 후 카테고리 별로 분류하도록 구현하였다. 그리고 채팅방이 구현되어 있기 때문에 채팅을 통해 다른 사용자와 채팅이 가능했다. 
 
 

2. 프로젝트 기능 목적에 맞는 엔티티 설계 과정

▶  위 1번 문단에서 강조한 단어들은 모두 엔티티가 될 수 있는, 엔티티가 되어야 하는 단어들이다. 이제 내가 각 기능을 어떻게 연관지어 데이터 베이스를 설계했는지 정리해보자.
 

• 우선, 회원이라는 하나의 객체는 여러 개의 URL 정보를 분석할 수 있다 → 회원(1) : URL(다) 관계가 성립한다고 생각하였다. URL을 이용하여 회원을 참조하는 경우는 없다고 판단하여 일대다 단방향 연관관계로 설정하였다.
• 이어서 URL 정보는 텍스트 요약 결과와 시각화 자료 2개를 반환해야한다. [텍스트 요약 결과]와 [시각화 자료 2개]는 하나의 URL에 대한 요약 결과물로 {텍스트 요약 결과, 시각화 자료 2개} 형태로 객체로 생성할 수 있다고 판단하였다. 이를 Analyze객체라고 칭하면 URL(일) : Anaylze(일) 관계가 성립한다고 생각하였다. 마찬가지로 Anaylze 객체로 URL 정보를 참조하는 경우는 없다고 판단하여 일대일 단방향 연관관계로 설정하였다.
• 다음은 채팅방 관련 설계이다. 회원은 여러 개의 채팅방에 참여할 수 있고, 하나에 채팅방에는 여러 명의 회원이 참여할 수 있다. 즉, 회원과 채팅방 엔티티는 서로 다대다 관계가 성립할 수 있다. 만약 다대다 관계를 그대로 코드로 옮긴다면 여러 가지 한계점이 존재한다.

다대다 매핑의 한계

• 개발하다 보면, 연결 테이블이 단순히 연결만 하고 끝나지 않는다. 조인 테이블 자체에 주문시간, 수량 같은 추가 데이터가 많이 들어갈 수 있다.
• 하지만, 매핑 정보만 넣는 것이 가능하고, 추가 정보를 넣는 것 자체가 불가능하다.
• 그리고 중간 테이블이 숨겨져 있기 때문에 예상하지 못하는 쿼리들이 나간다.
• 이런 문제점들 때문에 실무에서는 안쓰는게 맞다고 본다.

따라서, 이를 극복하기 위해 다대다가 아닌 중계 테이블을 이용하여 일대다 ↔ 다대일로 풀어 설계해주었고 회원이 채팅방을 조회 가능해야하고, 채팅방에서 회원 조회가 가능해야하기 때문에 양방향 연관관계로 설정하였다.

• 그리고 채팅방은 대표 사진을 가질 수 있도록 구현하였다. 그래서 채팅방(1) : 채팅방 이미지(1)로 설계해주었다.

 
연관관계가 존재하는 엔티티들은 위와 같이 설계 진행해주었고, 전체 채팅방 조회를 위한 테이블도 생성하여 조회 가능하도록 하였다. 또한, 카테고리 분류는 모든 회원이 진행했던 URL들을 분류해야하기 때문에 회원과 연관관계가 존재하는 URL 테이블이 아닌 카테고리 번호로 테이블 조회가 가능하도록 구현한 테이블을 하나 새로 생성해주었다.
 
 

3. 엔티티 설계 결과

엔티티 설계

프로젝트와 DBeaver를 연동하여 구현한 코드를 시각적으로 확인한 모습이다.