오늘은 팀 프로젝트에 대한 ERD (연관관계) 작성과 API 명세서, 요구사항 분석서를 작성하였다. 진행하면서 배운점을 정리하고자 합니다.

식별 ? 비식별 ?

먼저 ERD를 작성하면서 테이블간의 연관관계를 설정할때 두 테이블의 관계가 식별 혹은 비식별 인지 정의가 필요했다.

나는 식별, 비식별이란 키워드를 처음 들어봐서 정리를 하며 리마인드 하려고 한다.
그래서 식별 비식별이 뭘까 ?

---

유저 테이블과 게시판 테이블의 관계가 1 : N (일 대 다) 라고 생각해보자, 이유는 한명의 유저가 여러번 게시판에 글을 작성할수 있다고 가정하겠습니다.

이때 두 테이블의 관계를 식별 관계 혹은 비식별 관계로 정의 할수 있습니다.

식별

• 식별 관계란 부모의 테이블의 기본키 (PK)를 자식 테이블의 기본키 (PK)로 이용하는 방법입니다.
• 아래의 사진에서 유저 테이블이 부모 테이블이되고, 게시판 테이블이 자식 테이블이 됩니다.
• 실선으로 관계를 표현 하게 됩니다.

비식별

• 비식별 관계란 부모의 테이블의 기본키 (PK)를 자식 테이블의 외래키 (FK)로 이용하는 방법입니다.
• 점선으로 관계를 표현 하게 됩니다.

식별, 비식별 정리

• 식별 관계에서는 반드시 부모테이블의 참조 데이터가 존재 해야만 자식 테이블에 데이터를 추가 할수 있습니다.

➡ 예를 들면 유저가 없으면 게시글이 존재 할수 없다.

• 비식별 관계에서는 부모테이블의 참조 데이터가 존재하지 않아도 자식 테이블에 데이터를 추가 할수 있습니다.

➡ 예를 들면 축구선수와 축구화 일 것 같습니다.
(꼭 축구화를 신지 않아도 되는 느낌 인것 같다.)

식별관계는 구조변경의 어려움이 있지만, 데이터의 정합성을 유지할수 있습니다, 비식별 관계는 구조변경이 용이하지만, 데이터 무결성을 보장하지 않습니다. 이러한 장단점을 통해 필요에 따라 관계를 설정해야 될 것 같습니다.

프로젝트 진행중

@SuperBuilder

• 기존의 @Builder 어노테이션의 문제점인 상속받은 필드를 빌더를 사용하지 못한 제안 사항을 보안하기 위해 나온 개념 이라고 합니다.
• @SuperBuilder 를 사용하게 되면 상속받은 필더도 빌더를 사용할수 있습니다.

• 아래의 사진과 같이 자식 Entity (Product) 와 부모 Entity (BaseEntity) 양쪽에 @SuperBuilder 어노테이션을 각각 추가해줘야 합니다.
• 그 후 평소에 사용하던 @Builder 어노테이션과 동일하게 사용하면 됩니다.
  

Git 체리픽

• 처음 들어보는 Git 의 기능 이였다.

사진과 같이 다른 브랜치에 있는 커밋을 선택하여 나의 브랜치에 적용시킬때 사용하는 명령어 (기능) 입니다.

• 다른 브랜치의 커밋 내역이 나의 브랜치로 온전히 넘어오게 됩니다.
• 1 : 브랜치를 선택합니다.
  2: 체리픽 할 커밋을 기준으로 체리픽을 진행합니다.
  

마무리

• 추가로 아키텍처 구조, 패키지 구조 등을 정리할 예정이다.
• EndPoint (엔드포인트)도 정리할 예정이다.

REFERENCE

• https://brownbears.tistory.com/606 (체리픽)