일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 환경변수
- 레포지토리
- 게시글 이미지 업로드
- .env
- N+1문제
- N+1
- 메뉴바
- JWT
- 네비게이션 한번에
- 이미지가 포함된 게시글
- 패스파라미터
- 포트번호
- secret코드
- Winston
- 알림생성
- 토큰
- 게시글 이미지
- 부트캠프
- 메뉴바 한번에
- route 53
- 스테이지어스
- 쿼리스트링
- getComputedStyle
- unnest
- JSON Web Token
- 3계층구조
- 알림생성모듈
- JWT 쓰는이유
- element.style
- JWT 쓰는 방법
- Today
- Total
기주
[DB] 식별관계와 비식별관계 본문
식별관계와 비식별관계
식별관계 : 부모테이블의 기본키나 유니크 키를 자식 테이블이 자신의 ( 기본키+외래키 )로 이용
ㄴ부모 데이터가 존재해야지만 자식 데이터를 추가할 수 있다
ㄴ부모 테이블의 키를 기본키로 가지고 있어서 부모 테이블의 데이터가 있어야지만 자식 테이블에 데이터를 추가할 수 있다
ㄴ 부모테이블의 키를 자식테이블에서 기본키로 삼으면 식별관계, 외래키로만 삼으면 비식별관계
ㄴ 식별관계에서는 부모테이블의 키를 기본키로 쓰기때문에, 자식테이블에서 부모테이블에 관한 정보가 1개씩만 들어갈 수 있다.
쓰는이유)
예시)
자동차(부모테이블)가 있어야지 자동차바퀴(자식테이블)이 존재할 수 있다
유저, 게시글, 추천 테이블이 있고, 한명의 유저는 하나의 게시글에 대해 "한번만" 좋아요 할 수 있다.
ㄴ 이때 추천테이블의 PK는 유저의 PK와 게시글의 PK를 조합해서 유일해야한다.
장점 : 데이터의 정합성 유지를 DB에서 검증
단점 : 구조 변경이 어려움
비식별관계 : 부모테이블의 기본키나 유니크 키를 자식 테이블이 외래키로만 이용
ㄴ 부모 데이터가 없어도 자식 테이블에서 데이터를 추가할 수 있다
ㄴㄴ자식데이터의 외래키 속성에 아무 값을 넣지않고도 데이터 추가 가능하다
ㄴ부모 테이블의 키를 외래키로 가지고 있어서 부모 테이블에 데이터가 없어도 자식테이블에 데이터를 생성할 수 있고 의존성을 낮출 수 있다
장점 : 구조변경이 자유로움, 부모 데이터로부터 독립
단점 : 데이터 정합성을 위한 로직 필요, 데이터 무결성 보장하지 않음
** 비식별 관계를 사용하는 이유)
데이터의 무결성을 위해서라면 식별관계가 좋겠지만, 개발 측면에서 다양한 요구 사항을 수용하기 위해서는 엔티티간의 관계를 약간 느슨하게 만드는 것이 좋다.
예를들어 식별관계에서 시험결과 테이블에 학생이 없다면 데이터를 추가할 수 없다.
하지만 "학생이 존재하지 않는 시험결과도 입력하게 해주세요",
"일단 시험결과를 먼저넣고 나중에 학생데이터를 넣고싶어요" 라는 요구사항이 있다면 비식별관계로 만드는 것이 더 좋은 선택이 될것이다.
'TIL' 카테고리의 다른 글
[DB] DB 모델링 - 소셜 로그인기능 (0) | 2024.02.25 |
---|---|
[postgresSQL] enum 타입 (0) | 2024.02.19 |
[DB] 트랜잭션 (Transaction) (0) | 2024.02.19 |
[AWS] aws 탄력적IP (0) | 2024.02.07 |
[AWS] aws 키페어 분실시 복구하는법 (0) | 2024.02.07 |