엔티티 간 연관관계를 얘기할 때에는, "엔티티 간 식별 관계" 와 "엔티티 간 연결되는 개체 수", "선택/필수 관계"를 이용해서 관계를 정의할 수 있다.
1. 부모, 자식 관계가 있는 엔티티 간 식별 여부를 정의하는 "식별 관계"
2. 관계가 있는 엔티티 간 하나의 엔티티에서 다른 엔티티에 몇개의 개체와 대응되는 갯수를 의미하는 "Cardinality"
3. 대응되는 개체의 필수 여부를 정의하는 "선택/필수 관계"
식별 관계와 비식별 관계
먼저 엔티티 간 식별 관계이다.
식별/비식별 관계는, 자식 개체가 부모 객체 없이도 식별될 수 있는지, 부모 객체 없이는 식별될 수 없는지를 의미한다.
식별 관계
자식 엔티티가 부모 엔티티의 식별자 (PK)를 본인의 식별자 (PK)로 사용하거나
복합키일 경우, 자신의 식별자에 부모의 식별자를 포함시키는 경우 식별 관계로 본다.
자식 엔티티는 부모 엔티티 없이 식별될 수 없을 만큼, 개체 간 아주 강한 의존관계를 가진다.
<예시>
1:M 관계로, 주문과 주문 상세 엔티티 관계가 있다.
주문 상세 엔티티는 주문의 PK인 주문번호를 자신의 PK로 갖기 때문에, 주문 데이터의 식별자 없이 주문 상세 데이터를 식별할 수 없다.
1:1 관계로, 조인 전략을 맺는 엔티티 간 관계를 예시로 들 수 있다.
김영한 님의 JPA 강의에서 만난 예제인데, 판매 상품 정보들의 공통점 데이터가 하나의 상품 테이블에 존재하고
각 ALBUM, MOVIE, BOOK 은 해당 ITEM 테이블을 상속받으면서, 각자의 속성을 관리하는 테이블이 있다. (객체의 상속 관계를 나타내는 '조인 전략' 방법이다.)
이때 세 테이블은 ITEM 테이블의 PK 를 자신의 PK이자 FK로 참조하고 있다.
비식별 관계
자식 엔티티가 부모 엔티티와 독립적인 식별자 (PK)를 갖고 있어
자식 엔티티가 부모 엔티티와 독립적으로 존재할 수 있는, 엔티티 간 약한 의존 관계를 가진다.
<예시>
멤버 테이블과 팀 테이블이 있다. 멤버 테이블은 팀 테이블의 식별자를 PK에 포함하지는 않고, FK로 갖는다.
팀에 속해있지 않은(TEAM_SEQ를 FK로 갖지 않는) 멤버도 독립적으로 존재할 수 있다.
Cardinality
관계가 있는 엔티티 간 하나의 엔티티에서 다른 엔티티에 몇개의 개체와 대응되는 지에 따라 여러 종류가 존재한다.
1. 1:1 관계
2. 1:N 관계
3. M:N 관계
1:1 관계
하나의 엔티티에서 다른 엔티티에 대해 하나의 개체만 대응되는 관계이다.
<사례> 회원과 회원 정보 테이블. 회원 데이터 한개는 하나의 회원 정보 테이블 데이터와 매핑되기 때문에 1:1 관계이다.
1:N 관계
하나의 엔티티에서 다른 엔티티에 대해 2개 이상의 개체와 대응되지만, 반대 방향으로는 단일 개체만 매칭되는 관계이다.
<사례> 회원과 주문 테이블. 회원 데이터 한개는 2개 이상의 주문을 할 수 있지만, 주문 데이터 한개는 2개 이상의 회원과 연결될 수 없는, 1:N 관계이다.
M:N 관계
하나의 엔티티에서 다른 엔티티의 2개 이상의 개체와 대응되고, 반대 방향으로도 2개 이상의 개체와 대응되는 관계이다.
<사례>
주문과 상품 테이블. 주문 데이터 한개는 2개 이상의 상품 데이터를 갖을 수 있고, 상품 데이터 한개도 2개 이상의 주문 데이터와 대응될 수 있기 때문에 M:N 관계이다.
보통 M:N 관계는 1:M, N:1 관계로 풀어질 수 있도록 중간 테이블을 두는 것이 일반적이다. ex) 주문:상품 관계 (M:N)는 주문 : 주문_상품 = 1:M, 주문_상품 : 상품 = N:1 으로 구성.
필수/선택 관계
마지막으로 엔티티 간에는 필수 관계, 선택 관계가 있다.
필수 관계인 경우, 엔티티 내 개체가 생성될 때, 상대 엔티티에 대응되는 개체를 무조건 하나 가져야 한다. 그렇기 때문에 외래키(FK) 에는 Null을 허용하지 않는다.
선택 관계는 앤티티 내 개체가 상대 엔티티에 대응되는 개체 없이 독립적으로 존재할 수도 있다. (선택적인 관계) 이런 경우를 위해 외래키 (FK) 에 Null을 허용한다.
이러한 선택/필수 관계는 관계를 맺는 두 엔티티 입장에서 다를 수 있다.
<사례>
1) 고객 (부모) 과 주문 (자식) 관계
주문 데이터는 반드시 고객 데이터를 가져야 하지만 -> 자식 엔티티에게는 필수 관계
고객 데이터는 주문 데이터를 반드시 가질 필요는 없다. -> 부모 엔티티에게는 선택 관계
2) 할인 정책 (부모) 과 상품 (자식) 관계
상품은 할인 정책을 갖을 수 있지만, 필수는 아니다. -> 자식 엔티티에게는 선택 관계
할인 정책은 하나 이상의 상품에 적용될 수도 있고, 아닐 수도 있다. -> 부모 엔티티에게도 선택 관계
(할인 정책은 항상 적용될 상품이 있어야 한다는 개념을 적용한다면, 부모 엔티티에게는 필수 관계일 것이다.)
'백엔드 개발하며 작성한 > 데이터베이스' 카테고리의 다른 글
[ORM] 상속 관계 매핑 (0) | 2022.05.20 |
---|---|
[ORM] 연관관계의 주인을 정해야하는 이유 (0) | 2022.05.20 |
[ORM > JPA] 영속성 컨텍스트 (0) | 2022.04.14 |
[MySQL]날짜/시간 타입과 TIMESTAMP 칼럼 생성 (0) | 2021.10.08 |
[MySQL Workbench] ERD를 SQL 코드로 변환하기 (0) | 2021.09.02 |