매번 프로젝트 때마다 erd를 설계하기는 하지만 매번 헷갈리는게 바로 identifying & non-identifying relationship의 차이점이다.
이번 기회에 확실히 알고 가기 위해 이 글을 작성한다.
이 둘에 대해 알아보기 전에 RDBMS의 기본적인 용어들을 정리하고 가자.
(key들에 관해서는 정말이지 매번 헷갈린다.)
✏️ "Composite key(복합 키)"
- 두 개 이상의 column을 묶어서 하나의 기본키로 지정하는 것
- 기본 키는 하나의 테이블에 하나만 존재할 수 O -> 기본키가 복합키라면, 당연히 '유일성'과 '최소성'을 만족해야 한다.
✏️ "Alternative key(대체 키)"
- 기본 키를 제외한 나머지 후보키들을 의미
⭐ 식별관계(Identifying Realtionship)와 비식별관계(Non-Identifying Relationship) 은 RDBMS에서 나누는 관계가 아닌, ER Diagram 상에서 논리상 나누는 개념이다.
1. Identifying Relationship(식별 관계)
=부모 테이블의 기본키(PK) 또는 복합키가 자식 테이블의 기본키 또는 복합키의 구성원으로 전이되며, 관계는 서로 종속되게 된다.
- B라는 테이블의 FK가 child로 A 테이블의 PK를 참조하게 된다면, Identifying Relationship 에서 B테이블은 A테이블에 종속이 되어서, A값이 없으면 B값은 홀로 의미를 가지지 못하게 된다.
위와 같이, A와 B 모두 studentId를 PK로 가지고 있다. 이때, tableB는 studentId가 없다면 독립적으로 존재할 수 없는 정보가 된다.
즉, Identifying Relationship은 strong coupling이라고 할 수 있다. - 위 그림에서는 A=부모테이블, B=자식테이블이다.
2. Non-Identifying Relationship(비식별관계)
= 자식 테이블의 일반 속성(Attribute) 그룹의 구성원으로 전이되는 비식별관계로, 부모는 자식의 부분적인 정보만을 표현한다.
Non-Identifying Relationship의 경우 B테이블이 A와 FK의 관계를 맺고 있긴 하지만, 독립적으로 존재할 수 있어야 한다. 즉, FK가 B테이블의 PK가 되어서는 안된다.
- 이제 테이블 B는 studentId를 키로 가지지 않고, 독자적인 subjectId를 키로 가진다.그리고 학생정보를 기록하는 테이블 A가 이를 참조하는 방식으로 변경되었다.
- 특정 학생의 성적을 알고 싶을 때는, 테이블 A에서 subjectId를 찾으면 해당 학생의 성적 정보를 찾을 수 있다.
∴ 두 테이블은 서로가 없어도 유효한 정보를 나타낼 수 있다.
또 다른 예시로는, "책"과 "독자", 그리고 "저자"의 관계에 있다.
- 책-독자 : "Non-Identifying Relationship"
- 책이 없어도 독자는 존재할 수 있고, 독자가 없어도 책은 존재할 수 있기 때문.
- 책-작가 : "Identifying Relationship"
- 작가가 없으면 책이 존재할 수 없다.
🤔 내가 설계하려는 erd 에서는 어떨까?
나는 user가 자신만의 여러 개의 space(공간)을 생성할 수 있도록 해야 한다. user가 없으면 space는 존재할 수 없다.
∴ 고로, 이 둘은 Identifying Relationship(식별관계) 여야 한다.
그리고 이 공간(space)에 업로드할 콘텐츠(item)와의 관계도 설정해야 한다.
이때, item은 space가 없어도 존재할 수 있다. 따라서 비식별관계로 설정하였다. 그런데, 여기서 헷갈리는 지점이 생겼다. 공간(space)는 이미 space_id를 PK로, user_id를 FK로 설정하였다. 이렇게 되면 item에서 참조되는 id가 space_id, user_id가 된다. 이 두개를 무조건 모두 참조해야 하는지, 혹은 하나만 참조해도 되는지 헷갈리기 시작했다.
우선 필요한 기능상 item을 클릭하면 해당 user의 정보가 검색되는 기능이 필요했으므로, 두 개의 field를 모두 참조하기는 했지만, 원칙상 어떻게 해야하는지는 아직도 잘 모르겠다.
또한, item과 space의 관계에서 어떤게 자식이고, 부모인지 헷갈린다. 아무래도 자식 테이블과 부모 테이블에 대해 좀 더 자세히 공부해야 겠다.
space에 여러 개의 tag를 설정할 수 있는 기능도 존재하는데, tag는 space와 별도로 존재할 수 있으므로, 이 또한 Non-Identifying Relationship(비식별관계)로 설정하였다.
tag를 이용하는 기능에도 마찬가지로 user_id가 필요해서 space_id, user_id field 모두를 참조하였다.
또다른 궁금증이 생겼다. user_id가 필요한 경우,
space_id만 참조해서 해당 space_id를 이용해서 다시 user_id를 찾는 방식으로 api를 작성하는 방식이 나을까,
혹은 지금처럼 entity 자체에서 user_id, space_id 두개의 필드를 모두 참조하여 space_id를 통해 찾지 않아도 되는 방식이 더 효율적일까? 🤨
더 공부해보면서 해결 방법을 찾아야 할 것 같다.
우선 이게 현시점에서의 erd이다.
