ObjectMapping 맛만 보자

윤주헌

Sep 02, 2024

Contents

중요함 정리 1대1 관계 1대 N관계 N대 M 관계

도메인은 범주를 말한다

1식 증가하는거를 프라이머리키로 언제부터 사용했냐? 예전에는 주민번호로 했는데 하지 말라 해서 다른걸로 찾음 법이 바뀔 때 마다 바뀐다.

비정형 데이터 → write없는 데이터 업데이트 없는 데이터( 엄청 많은 데이터 들어오면 gate way만들어서 분산해서 저장해 둔다 뺄 때 아무곳이나 가지고 가고 가운데에서??

그냥 못 찾아서 해쉬를 쓴다.

정형 데이터

💡

정형 데이터에는 보유하고 있는 정보에 대해 적절히 정의된 스키마가 있습니다. 매우 간단히 정의하면 구글 스프레드시트 또는 마이크로소프트 엑셀과 같은 스프레드시트 프로그램에 표시할 수 있는 모든 데이터는 정형 데이터입니다.

비정형 데이터

💡

미리 정의된 데이터 모델이 없거나 미리 정의된 방식으로 정리되지 않은 정보를 말한다. 비정형 정보는 일반적으로 텍스트 중심으로 되어 있으나 날짜, 숫자, 사실과 같은 데이터도 포함할 수 있다.

주의

클래스 위에도 @Builder 할 수 있는데 collection에 들어오면 터질 수 있음


package shop.mtcoding.blog.user;

import jakarta.persistence.*;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

import java.sql.Timestamp;

@Setter
@Getter
@Table(name = "user_tb")
@NoArgsConstructor
@Entity
public class User {

    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Id
    private Integer id;
    //유니크 해야함
    @Column(unique = true, nullable = false)
    private String username; //아이디
    @Column(nullable = false)
    private String password;
    @Column(nullable = false)
    private String email;
    private Timestamp createdAt;

    @Builder
    public User(Integer id, String username, String password, String email, Timestamp createdAt) {
        this.id = id;
        this.username = username;
        this.password = password;
        this.email = email;
        this.createdAt = createdAt;
    }
}

테이블을 만들 때 설계를 정규화로 만드는 시대는 지났다

만약 배달 프로그램 만들면

고객(명사)이 필요하다, 사장님(명사)도 필요하다 이게 핵심 테이블이다 사장님이 팔라면 상품(명사)이 필요하다

고객은 상품을 주문한다(명사끼리의 관계)(동사다)

프로토타입

핵심을 만드는 것이다

라이더 배달 없어도 프로그램은 돌아간다.

그래서 고객 상품 사장님 주문이 중요하다

관계를 만든다

1대 n관계

고객 한명은 상품 몇개를 주문할 수 있을까? 한명은 상품 여러개 주문할 수 있고 반대로 상품은 고객 한명한테 간다

게시글 한개에 댓글 여러개

1대1

댓글 하나는 게시글 하나에 포함된다 1대1 11 n1

n대 m

고객(1 ssar 2 cos)이 있고 영화(1 스파이더맨 100, 2 베트맨 100)가 있을 수 있다

스파이더맨 영화는 고객과 n대n 나올 때 중간 테이블이 만들어 진다 예매(동사)가 나온다

예매에는 고객의 pk, 영화의pk가 필요하다

이해 못한 예제

고객(1 ssar)이 있고 배(1 잠수함, 2 잠수함, 3 전투함, 4 전투함)

고객 한명은 잠수함 여래개 살 수 있다 1대n

잠수함은 1명의 고객 살 수 있다 1대1

관계는 1대n

다시 게시글로

1ssar이 있고 제목1이 있다면 포린키는 n쪽에 있어야 한다(UserId가 들어가야한다 )

외워라!!

일단 n쪽에 포린키가 들어가야 한다

테이블 만들 때는 동사가 아닌 명사만 생각해야 한다 이후에 둘의 관계를 보는데 1대1,n대1, 1대n인지

n대n은 동사 테이블이 만들어진다

join

join은 합치는것

board다 (id, title, content)

1 제목1 내용1

1 제목2 내용2

1 제목3 내용3

1 제목4 내용4

댓글(reply) (id, comment) (board_id)있어야 한다

1 댓글1 1

2 댓글2 2

3 댓글3 3

4 댓글4 1

테이블 나눈 이유 → reply가 board에 붙으면

1번 에 댓글 2개 들어가서 중복됨

그래서 쪼갬

포린키는 중복 가능해서 다 찾아야 한다

왼쪽 테이블 첫번째 행 잡고

1 제목1 내용1 1 댓글1 1 있는애 찾음

1 제목1 내용1 4 댓글4 1

join은 그냥 for문 돌리는 것

outerjoin null 왼쪽 테이블에는 있고 오른쪽 테이블에 있으면

중요함

찾는게 프라이머리키면 풀 스캔 하지 않고 다이랙트로 바로 찾는다 → 유일하기 때문 for문 안 돌림

여기서는 4번 만에 끝

만약 찾는게 프라이머리키가 아니라면 일일이 다 찾는다 16번이나 일한다

시간이 오래 걸린다!

드라이빙 테이블

💡

• JOIN시 먼저 액세스 돼서 ACCESS PATH(접근 경로)를 주도하는테이블

드리븐 테이블

💡

• 나중에 액세스 되는 테이블(DRIVEN TABLE, INNER TABLE)

중요!!

규칙 1대 n의 관계

n에 포린키가 있으면 n이 드라이빙 테이블이 되어야 pk를 한번에 찾는다

n포린키 드라이빙 테이블 → 엔포드로 외우자

💡

n포린키 드라이빙 테이블

왜 컬럼에 board_id가 아닌 board 테이블을 못 걸까?(통으로 넣기)

이렇게 넣으면 조인 안 해도 되지 않나? 왜 안 씀?

→ 1. 정규화를 해서 잘 만들어야 해서

→ 2. 보드의 제목 중 하나를 수정한다면 reply의 보드도 수정해줘야 해서 일관성이 깨질 수 있다.

Board 테이블은 값이 변했지만 합친 테이블의 title값은 그대로다 → 일관성이 깨진다

테이블을 넣는다면 수정이 없는 데이터는 합치는게 좋다

중복해서 하면 write에서 힘들고 Read하기에는 쉽다!

몽고DB 등 이런DB는 수정 안 하니까 테이블에 다른 테이블 자체를 가지고 있는다

일단 내일 하이버네이트 배울거임

DB의 타입과 Java 세상이 모순이 생기는데 이 모순을 해결해 주는게 하이버네이터다(ORM)

DB에서는 id가 int로 존재하고

java에서는 Object로 존재해서 서로 다르다

정리

1대1 관계

하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우

1대 N관계

하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우

N대 M 관계

동사 테이블이 만들어 진다

See more posts