2023. 8. 4. 22:12ㆍ프로젝트/[Dotoring] 멘토링 어플리케이션
도토링 프로젝트를 진행하며 여러 아쉬웠던 점이 있었지만, 그 중 순위권 안에 드는 것은 단연코 설계할 시간이 너무나도 부족했던 것이다. 카카오 테크 캠퍼스와 동아리 프로젝트를 같이 병행하다 보니.. ++ 캡스톤까지
다 변명이야
8월 초에는 도토링의 DB 설계부터 단단히 다져볼 생각이다.
두번째 포스팅할 주제는 식별자와 비식별자 관계이다.
식별자 관계와 비식별자 관계가 무엇인 지 알아보기 이전에 이를 모르고 설계를 진행할 경우 아래와 같은 어려움을 맞이할 수 있다.
- 식별자 관계만을 이용하여 데이터 모델링을 전개할 경우, PK 속성의 숫자가 증가할 수록 관련된 SQL 구문이 복잡해져 개발 오류가 많아지게 된다.
- 비식별자 관계만을 이용하면 테이블간의 과다한 조인이 유발되 성능 저하가 올 수있다.
성능 저하 절대 안되지!
따라서, 식별자 관계와 비식별자 관계에대한 개념을 알고 설계를 진행해야한다.
지금부터 알아보도록 하자!
식별자 관계와 비식별자 관계
식별자 관계
식별자 관계란 부모 자식 관계에서 자식이 부모의 주 식별자를 외래 식별자로 참조해서 자신의 주 식별자로 설정하는 것입니다.
식별자 관계의 특징은 아래와 같습니다.
- 부모 엔티티가 생성된 이후 자식 엔티티가 생성될 수 있습니다
- 자식 엔티티가 부모로부터 받은 식별자만 사용하면 1:1관계
- 자식 엔티티가 부모로부터 받은 식별자와 자기 자신이 가지고있는 속성을 함께 사용하면 1:N 관계
여기서 생각해볼만한 점은 식별자 관계에서 복합키 즉 1:N 관계를 만들경우가 언제인가??이다!
필자의 생각
- 기록성 데이터에 위와 같은 방식이 적합한 것 같고 일반적인 테이블 같은 경우에는 복합키를 사용하지 않을 것 같습니다.
- 복합키를 사용할 경우에는 조인 조건의 개수가 많아져 개발자가 실수할 가능성이 높아질 것 같습니다.
비식별자 관계
비식별자 관계란 부모 엔티티로부터 속성을 받았지만 자식 엔티티의 주식별자로 사용하지 않고, 일반적인 속성(즉, 일반 속성 외부 식별자)로 사용하는 것입니다.
비식별자 관계의 특징은 아래와 같습니다.
- 부모 엔티티와 자식 엔티티간의 관계가 종속적이기때문에, 주식별자 구성을 독립적으로 할 수 있습니다.
- 즉, 부모쪽으로의 관계 참여가 선택적입니다.
현재 진행하고 있는 도토링 프로젝트를 예시로 사용해 언제, 왜 식별자 관계와 비식별자 관계를 사용하는 지 알아보겠습니다.
비식별자관계를 선정 하는 기준
1. 관계 분석
2. 관계의 강/약 분석 -> 약한 관계일 경우 비식별자 관계 설정 고려!
3. 자식테이블 독립 PK 필요 -> 비식별자 관계 설정 고려!
4. SQL 복잡도 증가, 개발 생산성 저하 -> PK 속성을 단순화 해야할 경우 비식별자 관계 설정 고려!
식별자 관계
아래는 식별관계의 예시 입니다.
회원 계정 엔티티와 멘토 엔티티
상황 : 회원가입
엔티티 : 회원 계정, 멘토
회원 계정
- 회원 번호, 아이디, 비밀번호, 이메일
멘토
- 닉네임, 소개, 소속, 연차, 멘토링 방식
엔티티들간의 관계 - 회원 계정 : 멘토 = 1 : 1
엔티티 생성 시기 - 회원계정과 멘토가 동시에 생성
데이터 생명 주기
회원가입시
회원계정의 경우 회원 번호, 아이디, 비밀번호, 이메일가 생성되고 멘토 엔티티는 닉네임, 소개, 연차는 생성되고
멘토링 방식은 null로 채워지게된다.
멘토가 탈퇴할 경우에 해당 회원 계정과 멘토는 삭제된다.
판단 기준
- 부모(회원 계정) 없는 자식(멘토)이 생성될 수 있는 여부를 확인해봅니다. → 생성될 수 없습니다!
- 데이터의 생명주기를 확인합니다.
- 멘토가 삭제될 경우 회원계정이 삭제되어야하고, 회원계정이 남아있는 데 멘토가 삭제되는 경우는 없습니다.
- SQL 성능 고려 - 조회 성능, 삽입/수정/삭제 성능
부모와 자식은 약한 관계이며자식이 독립 PK를 가질 필요도 없다고 판단됩니다.
최종 결론 : 멘토와 회원계정은 식별관계로 나타내어야합니다.
회원 계정- 회원 번호, 아이디, 비밀번호, 이메일
멘토 - 회원 번호, 닉네임, 소개, 소속, 연차, 멘토링 방식
비 식별자 관계
아래는 비 식별자 관계의 예시입니다.
상황 : 멘토, 멘티가 생성될 때
엔티티 : 멘토, 멘티, 프로필 이미지
멘토
- 회원 번호, 닉네임, 소개, 소속, 연차, 멘토링 방식
멘티
- 회원 번호, 닉네임, 소개, 학교, 학년, 선호 멘토링
프로필 이미지
- 원본 이미지 명, 저장시 사용할 이미지 명
엔티티들간의 관계 - (멘토 : 프로필 이미지 = 1 : 1), (멘티 : 프로필 이미지 = 1 : 1)
엔티티 생성 시기 - 기본 프로필 이미지 생성 이후 멘토 멘티 생성
데이터 생명 주기
멘토, 멘티가 생성될 때 기존에 가지고 있던 기본 프로필 이미지를 각 멘토,멘티의 프로필 이미지로 사용하고
이는 후에 마이페이지에서 변경할 수 있다.
만약, 기본 프로필 이미지가 아니라면 부모(멘토,멘티)가 삭제되면 자식(프로필 이미지)또한 삭제되어야한다.
판단 기준
- 부모(멘토,멘티)없는 자식(기본 프로필 이미지)가 생성될 수 있다.
- 부모(멘토,멘티)가 소멸되더라도 자식(기본 프로필 이미지)는 존재한다.
- SQL 성능 고려 - 여기서는 특히 조회 성능!
중간 결론은 멘토,멘티와 프로필 이미지 관계는 비 식별자 관계로 한다.
멘토와 멘티의 조회 즉, 닉네임, 소개, 소속, 연차, 멘토링 방식 + 프로필 이미지 조회가 빈번하므로 멘토와 멘티가 프로필 이미지에 대한 참조를 가지고 있게끔 만든다.
최종 결론
프로필 이미지의 식별자는 프로필 이미지 번호이고, 멘토와 멘티는 프로필 이미지 번호를 외래키로 가지고 있다.
참조 레퍼런스
https://snnchallenge.tistory.com/190
아는 만큼 보이는 데이터베이스 설계와 구축 - 이춘식님
이상입니다!!
'프로젝트 > [Dotoring] 멘토링 어플리케이션' 카테고리의 다른 글
QueryDSL을 사용해 통계(Count)쿼리의 결과를 사용해서 정렬하기 (0) | 2023.08.15 |
---|---|
데이터 무결성 지켜야지, 안 지킬거야?? (0) | 2023.08.07 |
엔티티의 통합과 분리의 기준이 뭐야?? (0) | 2023.08.04 |
읽기 전용 쿼리의 성능 최적화에 대한 고민 (0) | 2023.07.31 |
메서드가 연속으로 실행된다면, 트랜잭션이 중첩되어 데이터가 저장되지 않고 계속 수정되는 거 아냐?? (0) | 2023.07.26 |