개발일지 29(수정필요) - 작품 타입 다대다 관계 구현

tk7580·2025년 6월 25일

개발일지 27: 작품 타입 다대다(N:M) 관계 구현

날짜

2025년 6월 26일

작업자

(사용자 닉네임)

목표

  • 기존의 단일 type 컬럼 구조가 가진 한계('영화'이면서 '애니메이션'인 작품을 표현할 수 없음)를 근본적으로 해결한다.
  • 작품이 여러 개의 타입(예: Movie, Animation, Drama)을 동시에 가질 수 있도록 데이터베이스 스키마 및 관련 애플리케이션 코드를 전면 수정하여, 향후 확장성을 확보하고 데이터의 표현력을 극대화한다.

변경 내용

1. 데이터베이스 스키마 변경 (구조 확정)

  • work 테이블:
    • 기존의 type (VARCHAR) 컬럼을 완전히 삭제함.
  • work_type 테이블 신규 생성:
    • id, name 등의 컬럼을 가진 타입 마스터 테이블을 신설함.
    • Movie, Drama, Animation, Live-Action 등 서비스의 핵심이 되는 타입을 마스터 데이터로 INSERT하여, 타입 정보를 중앙에서 관리하도록 함.
  • work_type_mapping 테이블 신규 생성:
    • workIdtypeId를 외래 키로 가지는 중간 테이블을 신설함.
    • 이를 통해 workwork_type 간의 다대다(N:M) 관계를 구축함.
  • 관리자 계정 추가:
    • authLevel이 7인 관리자 계정('admin')을 DB 생성 시 함께 추가하는 DDL을 최종 확정함.

2. 백엔드 (JPA) 수정

  • 신규 엔티티 생성:
    • WorkType.java, WorkTypeMapping.java 엔티티를 새로 생성하여 신규 테이블과 매핑함.
  • 기존 엔티티 수정 (Work.java):
    • String type 필드를 삭제함.
    • @OneToMany 어노테이션을 사용하여 Set<WorkTypeMapping> workTypeMappings 필드를 추가함으로써, 새로운 다대다 관계를 코드에 반영함.

3. 백엔드 (데이터 파이프라인 - Python) 수정

  • tmdb_collector.py:
    • TMDB API에서 가져온 작품의 media_typegenres 정보를 분석하여, ['Movie', 'Animation'] 과 같은 타입 목록(List)을 결정하는 로직으로 수정함.
    • work 테이블의 type 컬럼을 직접 수정하는 대신, get_type_ids_from_nameslink_types_to_work 헬퍼 함수를 통해 work_type_mapping 테이블에 타입 정보를 저장하도록 변경함.
  • data_reconciler.py:
    • AniList API의 format, genres 정보를 바탕으로 작품의 타입 목록을 결정하는 determine_types_from_anilist 함수를 구현함.
    • UPDATE 또는 INSERT 시, work_type_mapping 테이블에 타입 정보를 기록하도록 로직을 최종 수정함.

4. 백엔드 (Service, Repository) 수정

  • WorkRepository.java:
    • work.type을 직접 참조하던 모든 JPQL 쿼리를, work_type_mapping 테이블을 JOIN하여 work_type.name을 조건으로 조회하도록 전면 수정함.
    • findDistinctTypes 메소드가 work_type 마스터 테이블을 직접 조회하도록 변경하여 정확성과 효율성을 높임.
  • WorkService.java:
    • 변경된 WorkRepository의 메소드(findByTypeName...)를 호출하도록 내부 로직을 수정함.

5. 프론트엔드 (Thymeleaf) 수정

  • 목록 페이지 (list.html, home.html 등):
    • 작품 카드에 단일 타입을 표시하던 로직을, th:each를 사용하여 work.workTypeMappings 컬렉션을 순회하며 여러 타입을 쉼표로 구분하여 모두 표시하도록 수정함.
  • 상세 페이지 (detail.html):
    • 요청사항에 따라, 단일 타입을 표시하던 정보 라인을 제거하고, 향후 개봉일, 제작사 등 다른 정보를 표시할 수 있도록 공간을 확보함.

결론 및 성과

  • 작품의 속성을 단일 값이 아닌 여러 개의 특성 집합으로 표현할 수 있는 유연하고 확장성 높은 데이터 구조를 최종적으로 확립했다.
  • 데이터베이스부터 파이썬 수집기, 자바 백엔드, 프론트엔드 화면까지 모든 계층에 걸쳐 변경된 스키마를 성공적으로 적용하여, 애플리케이션이 정상적으로 작동함을 확인했다.
  • 이로써 향후 DB 스키마 변경 없이, 코드 레벨에서 새로운 타입과 장르에 유연하게 대응할 수 있는 견고한 토대를 마련했다.

0개의 댓글