[DB] Basics (1)

2024년 5월 7일에 마지막으로 수정되었습니다.
수정 내용: Nest.js 예제 코드 추가

개요

요즘 틈틈이 서버를 개발해보고 있다. '프로덕트' 라는 단위의 산출물을 낼 때 거치게 되는 설계 - 개발 - 배포 - 유지보수 등등... 의 과정에서, 프론트엔드 개발자로 내 역할과 지식을 한정지었다가는 너무나 많은 기회와 재미난(!) 일들을 놓치게 되겠다는 생각이 들었다.

문제는 단순히 백엔드 프레임워크만 아는 것으로는 부족하다는 것이다.ㅎㅎ 당연하게도 예전에 들었던 데이터베이스개론 개념들을 끌어와야 하는 경우들을 슬슬 마주치고 있다. 데베개 강의를 다시 처음부터 끝까지 들을 수 있다면 좋겠지만 시간을 아끼기 위해 문제를 마주칠 때 마다 필요한 부분만 찾아본 뒤 간단히 정리해두는 편을 택했다.

결국 하고 싶은 말은 깊이 있는 깨달음을 목적으로 이 글을 쓰는 것이 아니라는 점이다.
🧐 이 글의 목적은 단순히 개념들을 요악하여 나열하는 데 있다.

Entity

• 데이터의 의미 단위 (라고 이해함)
  • 실체, 객체
  • 데이터베이스 내에서 변별 가능한 객체 등
• ex. name, age, gender, height, ... 등의 속성들이 모여 User 라는 Entity 를 구성한다.

@Entity()
export class UserModel {
    @PrimaryGeneratedColumn()
  	id: number;
    
    @Column()
	name: string;
    
    @Column()
    age: number;
    
    @Column()
    height: number;
    
    @Column()
    gender: 'male' | 'female'
}

• name, age, gender, ... 라는 속성들이 개별적인 값으로 존재할 때에는 DB 상에서 명확한 의미를 갖지 않는다.
  • 예를 들어, name string 이 어떤 의미를 갖는 값인지 알 수 없다.
• name 이 User entity 를 이루는 속성일 때 비로소 DB 상에서 의미를 갖는다.
  • name string 은 'PK 로 구별되는 어떤 user 의 이름' 이라는 해석할 수 있게 된다.
• 엄밀히 말해 Entity === table 은 틀린 정의다.
  • 테이블이란 row 로 표현되는 인스턴스들의 집합이다. 이 때 각 row 들은 미리 정의된 속성들인 column 들에 해당하는 값만 가질 수 있다.
  • 따라서 정의 상 모든 테이블은 엔티티의 정의를 만족한다.
  • 하지만 모든 엔티티가 테이블인 것은 아니다.

DTO

• Data Transfer Object: 계층 간 데이터 교환을 위해 사용되는 객체 (인터페이스)
• 엔티티와 달리, DTO 는 수신 계층에서 '필요로 하는 데이터' 만 담아야 한다.
  • ex. '유저 이름 변경' 기능을 구현하기 위해 클라이언트 - 서버가 통신하는 경우: 해당 API의 DTO 는 유저 이름과 관련된 데이터 및 메서드만 담고 있어야 한다.
  • 위에 정의한 속성들 중 height, gender 등 이름을 변경하는 것과 무관한 데이터들이 포함될 필요는 없다.
  • 또한 불필요한 속성들까지 전부 포함될 경우 비즈니스 모델이 그대로 드러난다는 문제도 발생한다.

interface UserNameDto {
  id: number
  name: string
}
...
@Patch('user/:id')
async PatchUserName = (
	@Param('id') id: string
  	@Body('name') name: string,
): UserNameDto => {
	...
    return { id, name }
}

Primary Key

• PK: Not null, unique.
• 테이블 상의 각 레코드(Row) 를 식별하는 데 사용되는 값
• 각 레코드의 primary key value 는 테이블 전체에 걸쳐 고유한 값이어야 한다.
  • Null 값이 허용되지 않는다. (고유해야 하므로 당연하다)
• 테이블 당 오직 한 종류의 Primary Key 만 지정할 수 있다.
  • 단 반드시 한 개의 필드(column) 이어야 하는 것은 아니다.
  • 필드 또는 필드의 집합이 될 수 있다.

Foreign Key

• FK: 외부 PK를 참조.
• 다른 테이블의 primary key 를 참조하는 필드
• 서로 다른 두 테이블이 참조 관계를 맺을 때, 무결성과 일관성을 보장하는 방법이 된다.