스터디를 한지 시간이 오래 지나긴 했지만, 기록이 진짜 중요하고, 이런 기록 하나하나가 나에게 도움 된다고 생각해서 나를 위해 쓴다고 생각하여 늦게라도 쓴다.

지금은 멋쟁이사자처럼 대학 12th HACKATHON을 경험하고 온 후여서 그때 스터디할때는 이게 어떻게 쓰이지? 뭐지? 라는 생각이 해커톤을 경험한 후, 아 이렇게 쓰이는구나 이런식이구나 라는걸 많이 깨달았다.
역시 나는 몸으로 직접 부딪치면서 깨달아야한다는것을 알았다. 참 많은 도움이 된 해커톤이여서 빠른 시일 내에 회고를 해야겠다는 생각이 들었다.

백엔드 스터디 (2)

---

용어

연관관계 (Association)

엔티티 간의 관계를 의미하며, 데이터베이스의 테이블 간 외래 키 관계에 해당한다.

매핑 (Mapping)

객체 모델과 데이터베이스 모델 간의 관계를 정의하는 작업. JPA에서는 엔티티와 테이블을 매핑하고, 연관관계 매핑에서는 엔티티 간의 관계를 정의한다.

단방향 연관관계 (Unidirectional Association)

한 쪽 엔티티만 다른 엔티티를 참조하는 관계

양방향 연관관계 (Bidirectional Association)

두 엔티티가 서로를 참조하는 관계

일대일 (One-to-One)

한 엔티티가 하나의 다른 엔티티와 연관된 관계

일대다 (One-to-Many)

한 엔티티가 여러 엔티티와 연관된 관계

다대일 (Many-to-One)

여러 엔티티가 한 엔티티와 연관된 관계

다대다 (Many-to-Many)

여러 엔티티가 여러 엔티티와 연관된 관계

주인 엔티티 (Owner Entity)

연관관계에서 외래키를 소유하고 있는 엔티티

주인 아닌 엔티티 (Non-Owner Entity)

외래키를 소유하고 있지 않은 엔티티

---

연관관계의 필요성

객체 모델에서는 실제 비즈니스 로직을 구현하기 위해 엔티티간의 관계를 명확히 정의해야 한다. 데이터베이스의 테이블 간 외래키와 같은 관계를 객체 지향적으로 다루기 위해 연관관계가 필요하다.

매핑의 목적

객체 지향 코드와 관계형 데이터베이스의 구조를 일치시켜 데이터의 일관성을 유지하기 위함이다.
이를 통해 객체 모델을 통해 자연스럽게 데이터베이스 상호작용을 구현할 수 있다.

---

객체 연관관계는 간접적이고, 테이블 연관관계는 외래 키로 명확히 표현되며, JPA 매핑을 통해 이를 일관되게 연결할 수 있다.

---

연관관계 매핑의 종류

일대일(One-to-One) 관계

객체 연관관계

Member 객체와 Locker 객체가 1:1로 매핑되어 있다.
즉, Member는 하나의 Locker를 가질 수 있고, Locker도 하나의 Member에만 연결된다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 LOCKER_ID를 외래 키로 가지며, 이 키를 통해 LOCKER 테이블과 1:1 관계를 맺는다.
LOCKER_ID 필드는 외래 키(FK)이면서 유니크(UNIQUE) 제약조건이 설정되어 있어, 각 Locker는 하나의 Member와만 연관될 수 있다.

일대일 관계는 두 엔티티가 서로 1:1로 매핑되는 관계로, 하나의 객체가 다른 하나의 객체에만 연관되는 구조이다.
데이터베이스에서는 외래 키와 유니크 제약조건을 사용해 이를 구현하며, 객체 모델에서는 필드 참조를 통해 연관관계를 표현한다.

다대일(Many-to-One) 관계

<단방향>

객체 연관관계

Member 객체와 Team 객체가 다대일 관계를 가진다.
즉, 여러 Member 객체가 하나의 Team 객체와 연관될 수 있다.
Member 클래스는 Team team 필드를 통해 Team 객체를 참조한다.
이는 여러 Member가 동일한 Team 객체에 속할 수 있음을 나타낸다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID를 외래 키(FK)로 가지며, 이를 통해 TEAM 테이블과의 관계를 정의한다.
TEAM_ID 필드는 MEMBER 테이블에 속하며, 이는 여러 MEMBER가 동일한 TEAM에 연결될 수 있도록 한다.

다대일 관계는 여러 엔티티가 하나의 엔티티와 연관되는 관계로, 객체 모델에서는 Member가 Team을 참조하는 방식으로 표현된다.
데이터베이스에서는 외래 키를 통해 이 관계를 구현하며, 여러 Member가 같은 Team에 속할 수 있다. 이 구조는 팀과 소속된 멤버들 간의 관계를 효율적으로 관리할 수 있게 해준다.

<양방향>

객체 연관관계

Member와 Team 객체가 서로 양방향으로 참조하고 있다. Member 객체는 Team team 필드를 통해 Team 객체를 참조하며, Team 객체는 List< Member > members 필드를 통해 여러 Member 객체들을 참조한다.
즉, 여러 Member가 하나의 Team에 속하고, Team은 자신에게 속한 모든 Member들을 참조할 수 있다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID 외래 키(FK)를 통해 TEAM 테이블과 연관되어 있다.
사진에서 표시된 것처럼, Team 객체에 추가된 members 필드는 테이블 구조에는 영향을 주지 않으며, 이는 객체 모델 상에서만 관리된다.

이 관계에서 Member 엔티티가 연관관계의 주인이다. 왜냐하면, 외래 키(TEAM_ID)가 MEMBER 테이블에 존재하기 때문이다. 연관관계 주인은 데이터베이스에서 실제로 외래 키를 관리하고, 해당 키를 업데이트하는 역할을 한다.

이 구조는 Member와 Team 간의 관계를 양방향으로 설정하여, Member가 Team을 참조할 뿐만 아니라 Team도 자신에게 속한 Member들을 참조할 수 있도록 한다.
이러한 양방향 관계는 데이터베이스 상에서 외래 키를 관리하는 주인 엔티티(Member)와 비주인 엔티티(Team)로 구분되어 구현된다.

일대다(One-to-Many) 관계

<단방향>

코드 구성을 보면 Team 클래스가 @OneToMany 어노테이션을 사용하여 Member들과 일대다 관계를 형성하고 있다.
@JoinColumn(name = "TEAM_ID") 어노테이션은 members 리스트가 TEAM_ID 외래 키를 통해 Member들과 연관된다는 것을 나타낸다.
List< Member > members 필드를 통해 Team 객체는 여러 Member 객체를 관리할 수 있다.

객체 연관관계

Team 객체는 여러 Member 객체와 연결되며, 이 관계는 단방향이다. 즉, Team은 Member들을 참조하지만, Member는 Team을 참조하지 않는다.
관계가 단방향이기 때문에 Member 객체에서는 Team에 대한 정보가 없다.

테이블 연관관계

데이터베이스에서 TEAM_ID는 MEMBER 테이블에 외래 키로 존재한다. 따라서 Member가 어떤 Team에 속해 있는지는 MEMBER 테이블의 TEAM_ID 컬럼을 통해 관리된다.

• 주의사항
  <외래 키 관리>
  @JoinColumn을 통해 지정된 외래 키는 반드시 MEMBER 테이블에 존재해야 하며, 이를 통해 Team과 Member 간의 연관관계가 설정된다.
  team.getMembers().add(member) 메서드를 호출하지 않으면, Member의 TEAM_ID 필드가 null로 저장되어 관계가 설정되지 않는다.

  <Update 쿼리 발생>
  Team 객체에 Member 객체를 추가할 때마다 외래 키(TEAM_ID)를 업데이트하기 위한 쿼리가 발생합니다. 이로 인해 성능에 영향을 줄 수 있으므로, 이를 주의하여 관리해야 한다.

  <실수로 양방향 연관관계로 변환될 가능성>
  만약 Member 객체가 Team 객체를 참조해야 하는 상황이 발생한다면, 단방향에서 양방향 연관관계로 변경해야 할 수 있다. 하지만 이 경우 Member 클래스에 Team 필드를 추가하고 @ManyToOne 어노테이션을 붙여야 한다.

  이 구조는 Team 객체가 여러 Member 객체와 일대다 단방향 관계를 가지도록 설정한다. 데이터베이스 상에서 외래 키는 MEMBER 테이블에 존재하며, 이 관계는 객체 모델에서 단방향으로 관리된다. 이 방식은 단순하지만, 외래 키 관리 및 업데이트 쿼리에 주의해야 하며, 필요에 따라 양방향 관계로 확장할 수 있다.

<양방향>

코드구성을 보면 Member 클래스는 Team 클래스와 다대일(Many-to-One)로 연결되어 있으며, @ManyToOne 어노테이션을 통해 이를 설정한다.
@JoinColumn(name = "TEAM_ID") 어노테이션은 Member 테이블에서 외래 키로 TEAM_ID를 사용함을 나타낸다.
insertable = false, updatable = false 설정은 이 필드를 읽기 전용으로 만들어, 데이터베이스에 값을 삽입하거나 수정할 수 없도록 제한한다. 이는 해당 관계가 양방향이지만, 데이터의 일관성을 유지하기 위해 한쪽에서만 외래 키를 관리하게 하려는 목적이다.

객체 연관관계

Team과 Member 간의 관계는 양방향이다. Team 클래스는 List< Member > 필드를 통해 여러 Member 객체들을 참조하고, Member 클래스는 Team 객체를 참조한다.
즉, Member가 어느 Team에 속하는지를 알 수 있으며, Team도 자신에게 속한 Member들을 알 수 있다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID 외래 키를 통해 TEAM 테이블과 연결되어 있다. 이 외래 키는 Member 엔티티에 의해 관리되지만, 해당 필드는 읽기 전용으로 설정되어있다.

일대다 양방향 연관관계는 Team이 여러 Member를 참조하고, Member도 Team을 참조하는 구조를 가진다. 이 관계에서 Member 쪽에서 외래 키를 관리하지만, 읽기 전용으로 설정하여 데이터의 일관성을 유지하고, 특정 상황에서 관계를 안전하게 처리할 수 있도록 한다. 이를 통해 양방향 관계를 구현하되, 외래 키 관리를 한쪽에서만 책임지는 방식으로 설정할 수 있다.

다대다(Many-to-Many) 관계

객체 연관관계

객체 모델에서는 Member와 Product 간의 다대다 관계를 List< Product >와 List< Member >를 사용하여 구현한다. 이를 통해 Member는 여러 Product를, Product는 여러 Member를 참조할 수 있다.
@ManyToMany 어노테이션을 사용하고, @JoinTable 어노테이션을 통해 중간 테이블(MEMBER_PRODUCT)을 설정하여 다대다 관계를 구현한다.

테이블 연관관계

데이터베이스에서는 다대다 관계를 직접적으로 표현할 수 없기 때문에, 중간 테이블(연결 테이블)을 사용한다. 이 중간 테이블은 두 엔티티의 외래 키로 구성되며, 각각의 외래 키는 양쪽 엔티티와 일대다[1:N]관계를 맺는다.
예시에서는 Member_Product라는 중간 테이블을 통해 MEMBER와 PRODUCT 간의 다대다 관계를 구현하고 있다.

• 주의사항
  <실무에서의 사용>
  실무에서는 다대다 관계를 직접 사용하는 것보다, 중간 테이블을 만들어 다대일 관계로 풀어내는 방식이 더 일반적이다. 이는 관리와 확장성을 높이고, 추가적인 컬럼을 필요로 할 때 유리하다.
  <성능 이슈>
  다대다 관계를 직접 사용할 경우, 조인 쿼리가 복잡해지거나 성능 이슈가 발생할 수 있으므로, 필요에 따라 중간 테이블을 명시적으로 관리하는 것이 좋다.

다대다 관계는 두 엔티티 간의 다대다 연결을 설정하는 구조로, 이를 위해 중간 테이블을 사용하여 관계를 관리한다. 객체 모델에서는 @ManyToMany 어노테이션을 사용하며, 실무에서는 이를 다대일 관계로 풀어내어 관리하는 것이 일반적이다.

---

요약

연관관계 매핑은 객체 지향 설계에서 엔티티 간의 관계를 명확하게 표현하고, 이를 데이터베이스의 관계형 모델과 일치시켜 데이터의 일관성과 무결성을 유지하는 데 필수적이다. 올바른 연관관계 매핑을 통해 코드의 가독성과 유지보수성을 높일 수 있으며, 복잡한 비즈니스 로직을 효율적으로 구현할 수 있다.

특히, 적절한 매핑 설계는 성능 최적화에 큰 영향을 미친다. 잘못된 매핑은 불필요한 쿼리 발생이나 N+1 문제를 초래할 수 있지만, 올바른 매핑은 쿼리의 효율성을 극대화하고 데이터베이스와의 상호작용을 최소화할 수 있다. 따라서 연관관계 매핑은 시스템의 성능과 유지보수성을 고려하여 신중하게 설계해야 한다. 이를 통해 안정적이고 확장 가능한 시스템을 구축할 수 있다.