[맛침반] 일대일 연관관계에서의 주종관계

6720·2024년 2월 16일

프로젝트 맛침반

목록 보기

8/12

주종관계에 대해 많이 헷갈리는 상태로 엔티티를 작성하다보니 비효율적인 엔티티 설계가 이루어졌다. 그 과정에서 팀원분께서는 다음과 같은 피드백을 남겨주셨다.

상황 파악

현재 메뉴와 메뉴 이미지의 관계는 일대일이며, 설계는 메뉴 이미지가 주인이 되도록 설계를 해둔 상태이다.
왜 그랬냐고 자문해보자면 다음과 같은 이유 때문이었다.

한 사람당 하나의 포트폴리오를 가질 수 있다고 가정하자. 그렇다면 현재 사람과 포트폴리오의 관계는 일대일이다.
주종관계에서의 핵심은 fk라고 생각한다. 그리고 보통 상대의 pk를 fk로 가지는 자가 주인이 된다. 그렇기 때문에 포트폴리오가 주인이 된다고 생각했다.

이 가정을 그대로 프로젝트로 가지고 온다면 메뉴 이미지가 주인이 될 것이다.
메뉴 이미지 테이블에는 메뉴id를 fk로 가지는 데이터가 차곡차곡 쌓일 것이다.
이렇게 설계하는 것이 데이터를 관리하는 데 있어 편리할 것이라고 생각했다.

하지만 팀원분께서는 관계의 주도권을 메뉴가 가지는 게 좋을 것 같다는 피드백을 해주셨다.
대화를 더 짚어보겠다.

일대일 관계에서의 주도권

팀원분께서 담당하신 기능에는 메뉴를 호출하는 로직이 들어가는 기능이 있다.
그렇다면 메뉴를 호출하게 되는데, 메뉴가 양방향 일대일에서 주도권을 가지고 있지 않으므로 호출할 때 (필요 없는) 메뉴 이미지를 같이 호출하게 된다.
만약 메뉴가 주도권을 가진다면 지연 로딩을 사용하여 불필요한 메뉴 이미지를 쿼리 실행 시 같이 가져오지 않을 수 있다.

내가 잘못 생각한 게 무엇일까?

일대다의 연관관계

일대일 관계에서의 주종 관계가 어렵다면 잠시 일대다로 넘어가보자.
이때 다시 사람과 포트폴리오가 등장한다.

사람은 여러 장의 포트폴리오를 가질 수 있다고 해보자. 그렇다면 여기서의 주인은 누구인가?
주인은 "소유"한다. 그러므로 당연하게 사람이 주인이다.

엔티티 이름만 변경해서 사람과 동아리라고 다시 예시를 들어보자. 그렇다면 여기서의 주인은 동아리가 될 것이다.

public class 포트폴리오 {
	...
	
	private 사람 작성자;
}

public class 사람 {
	...
	
	private List<포트폴리오> 포트폴리오들;
}

public class 사람 {
	...
	
	private 동아리 소속동아리;
}

public class 동아리 {
	...
	
	private List<사람> 사람들;
}

아까 설명한 주종관계를 코드로 작성했다.
그렇다면 여기서 fk를 소유하게 되는 것은 누구일까? 소유되는 쪽이 연관관계의 주인이 된다.
즉, 일대다 중 다가 주인이 된다.
그렇다면 다시 일대일로 돌아가보자.

일대일의 연관관계

한 사람당 하나의 포트폴리오를 가질 수 있다고 가정하자. 그렇다면 현재 사람과 포트폴리오의 관계는 일대일이다.
주종관계에서의 핵심은 fk라고 생각한다. 그리고 보통 상대의 pk를 fk로 가지는 자가 주인이 된다. 그렇기 때문에 포트폴리오가 주인이 된다고 생각했다.

상황 파악에서 일대일 관계를 설명할 때 내가 했던 말이다.
사람과 동아리의 관계에서는 사람이 주인이었고, 사람과 포트폴리오의 관계에서는 포트폴리오가 주인이었다. 그렇다면 일대일 관계에서도 포트폴리오가 주인이 아닌가?

팀원분께서는 다음처럼 설명해주셨다.
사람이 주인이 될 수 있고, 포트폴리오가 주인이 될 수 있다.
핵심은 누가 더 자주 기준이 되는지다. 만약 포트폴리오가 더 기준이라면 포트폴리오를 그대로 주인으로 만들어도 될 것이며, 사람이 더 기준이라면 사람을 주인으로 변경해도 될 것이다.
그렇기 때문에 일대일 관계에서는 더 자주 기준이 되는 엔티티를 주인으로 설정하는 것이 유리하다.

다른 포스팅을 찾다가 일대일 관계에 대한 설명을 보게 됐는데(포스팅 링크는 참고 자료에 추가해 둠), 일대일 관계에서는 주 테이블에 fk를 둔다고 한다. 즉, 주 테이블이 주인이 되는 것이다. 그러므로 주 테이블만 확인해도 어떤 테이블과 연관이 됐는지를 확인할 수 있다.