junome

ERD 실습 2 - 물리적 모델

ERD 실습 2 - 물리적 모델(Physical Data Model)

0. 물리적 모델이란 무엇인가?

물리적 모델은 논리 모델에서 정의한 구조를
실제 데이터베이스에 구현 가능한 형태로 변환하는 단계다.

여기서는 비로소 다음을 결정한다.

  • 컬럼 타입
  • 길이
  • NULL 여부
  • 기본값
  • 인덱스
  • 제약조건
  • 파티션
  • 저장 전략

즉,

의미 중심 설계를
성능과 저장의 세계로 내리는 작업

이다.

1. 논리 모델과 물리 모델의 차이

논리 모델은
✔ 무엇이 존재하는가
✔ 어떻게 연결되는가

를 정의한다.

물리 모델은
✔ 얼마나 빠르게
✔ 얼마나 안전하게
✔ 얼마나 오래 버틸 수 있게

저장할지를 결정한다.


논리 모델이 맞아도
물리 설계를 잘못하면 느리고, 잠기고, 터진다.

2. 물리 모델링에서 가장 중요한 생각

이 테이블은 앞으로 얼마나 커질까?

이 질문을 안 하면 100% 문제 생긴다.


출하, 이력, 로그 같은 테이블은
시간이 지나면 폭발적으로 증가한다.

처음 설계가 미래 성능을 결정한다.

3. 데이터 타입 선택

타입은 저장 방식이자 성능 전략이다.

예:

  • 번호 → bigint / numeric?
  • 코드 → varchar / char?
  • 시간 → timestamp / date?

잘못 고르면

✔ 인덱스 비효율
✔ 저장 공간 낭비
✔ 비교 속도 저하

가 발생한다.


실무 노하우

"될 수 있으면 더 작은 타입"

이게 기본 원칙이다.

4. NULL 허용 여부

NULL은 편하지만
로직을 복잡하게 만든다.

가능하면

값이 없다면 왜 없는지
상태로 표현하는 방법은 없는지

먼저 고민해야 한다.

5. 기본값(Default)

데이터 누락을 막는 첫 번째 방어선.

예:

  • 상태 = 'READY'
  • 생성일 = now()

애플리케이션보다 DB가 먼저 책임지는 것이 안정적이다.

6. 인덱스 설계 (물리 모델의 꽃)

여기서 성능이 결정된다.


언제 필요한가?

  • 자주 조회
  • 조건 검색
  • 조인 키
  • 정렬 기준

실무에서 중요한 사실

인덱스는 많을수록 좋은 게 아니다.

INSERT / UPDATE / DELETE 비용 증가.


출하 예시

  • 출하번호 → PK
  • 수주번호 → FK index
  • 출하일 → 조회 많으면 index 고려

7. 제약조건 (Constraint)

프로그램이 아니라 DB가 지키게 하라.

예:

  • FK
  • UNIQUE
  • CHECK

이걸 안 하면
운영 중 반드시 사고 난다.

8. PK 전략

이건 설계자의 수준이 드러나는 영역이다.


자연키 vs 인공키

자연키: 업무 의미 있음
변경 위험 존재

인공키: 안정적
조인 단순

실무에서는 인공키 + 업무키 UNIQUE 조합을 많이 쓴다.

9. 대용량을 대비하는 설계

미래에:

  • 데이터가 수억 건 되면?
  • 백업 시간은?
  • 조회 속도는?

여기까지 생각해야 물리 모델이다.


그래서 등장하는 것:

  • 파티셔닝
  • 아카이빙
  • 인덱스 전략

10. 물리 모델을 잘하면 생기는 일

  • 성능 안정
  • 락 감소
  • 장애 예방
  • 확장 가능

11. 물리 모델에서 초보가 많이 하는 실수

  • varchar 길이 과하게 줌
  • 인덱스 남발
  • FK 안 걸음
  • 증가량 예측 안 함

12. 결국 물리 모델이란

시스템을 오래, 빠르게, 안전하게 운영하기 위한 준비

이다.

논리가 뼈대라면
물리는 체력이다.

요약

물리적 모델

  • 논리 설계를 실제 DB 구조로 구현하는 단계
  • 타입, 인덱스, 제약조건을 결정

중요한 이유

  • 미래 성능을 좌우
  • 운영 안정성을 결정

핵심 포인트

  • 데이터 증가량 예측
  • 작은 타입 사용
  • 필요한 인덱스만
  • 무결성은 DB가 보장

출하 예시

  • PK, FK 인덱스
  • 날짜 조건 조회 대비
  • 이력 데이터 증가 고려

정리

  • 논리가 맞아도 물리가 틀리면 시스템은 느려진다
  • 물리 설계는 운영을 위한 기술이다

학습 후기

물리적 모델을 배우면서 데이터베이스 설계가 단순히 테이블을 만드는 일이 아니라는 걸 느꼈다. 특히 타입과 인덱스 선택이 시간이 지날수록 시스템의 속도를 결정한다는 점이 인상 깊었다. 논리적으로 완벽해 보여도 실제 운영 환경에서는 저장 방식과 접근 패턴이 훨씬 큰 영향을 준다. 좋은 물리 설계는 당장의 편의가 아니라 수년 뒤에도 문제없이 동작하도록 만드는 준비라는 생각이 남았다.