4과목 ③ — 물리 데이터 모델링

공식 출제 범위의 세부 항목은 넷이다.

물리요소 조사 및 분석  ·  논리-물리 모델 변환  ·  반정규화  ·  품질검토

논리 모델이 "업무를 어떤 구조로 담을 것인가" 였다면, 물리 모델은 "그 구조를 실제 DBMS 위에 어떻게 앉힐 것인가" 다. 각 결정이 무엇을 얻고 무엇을 내주는지를 아는 것이 이 단계의 요구 수준이다.

---

1부 · 물리요소 조사 및 분석

변환을 시작하기 전에 판단의 근거가 될 정보를 모은다. 근거 없이 변환하면 성능 문제를 나중에 발견하게 된다.

1. 조사 항목

1.1 데이터 관련

1.2 트랜잭션 관련

조회 패턴이 가장 중요하다. 무엇을 자주 어떤 조건으로 찾는지 모르면 어느 것도 결정할 수 없다.

1.3 시스템 관련

· 사용할 DBMS 의 특성과 제약
· 가용한 저장 공간과 메모리
· 백업·복구 요건
· 연계 대상 시스템

2. 조사 항목이 아닌 것

✗  현업 부서의 조직 개편 계획
✗  수집된 업무 요구사항의 우선순위
✗  프로젝트 예산과 일정

요구사항 우선순위는 요건 분석 단계에서 이미 확정된다. 물리요소 조사는 확정된 논리 모델을 어떻게 저장할지 판단할 근거만 모은다.

---

2부 · 논리-물리 모델 변환

3. 대응 관계

함정 — "관계 → 인덱스". 관계의 대응물은 외래키다. 인덱스는 성능을 위해 덧붙이는 별개 객체이며, 관계가 없는 컬럼에도 만들 수 있다.

4. 변환 시 수행하는 것

✓  엔터티 → 테이블, 속성 → 컬럼
✓  식별자 → 기본키, 관계 → 외래키
✓  논리명 → 물리명 (명명 규칙 적용)
✓  자료형과 길이 확정 (표준 도메인 적용)
✓  슈퍼타입·서브타입 구현 방식 선택
✓  필요한 구간에 반정규화
✓  저장 구조 결정 (분할 등)

5. 변환 시 하지 않는 것

✗  업무 요건을 새로 수집
✗  정규화를 처음부터 다시 수행
✗  논리 모델을 건너뛰고 물리에서만 보완

물리 변환은 확정된 논리 모델을 옮기는 단계다. 여기서 새 요건이 발견되면 논리 모델로 돌아가 반영한 뒤 다시 변환해야 두 모델의 정합성이 유지된다.

6. 자료형과 길이

표준 도메인이 정한 형식을 그대로 적용한다. 같은 성격의 속성이 같은 자료형을 갖게 되는 것이 도메인을 두는 이유다.

주문일자 · 배송일자 · 취소일자   →  '일자' 도메인
주문금액 · 결제금액 · 환불금액   →  '금액' 도메인

6.1 문자형 통일의 함정

모든 속성을 문자형으로 두는 것이 흔한 실수다.

수량을 문자형으로 두면    '9' > '10' 이 참이 된다
날짜를 문자형으로 두면    '2025-02-31' 같은 값이 그대로 저장된다

자료형은 값의 조건을 강제하는 첫 번째 장치다. 통일하면 편해 보이지만 타입이 제공하는 검증과 연산을 모두 포기하게 된다.

6.2 길이 산정

· 값의 범위를 모두 수용할 수 있어야 한다
· 불필요하게 크게 잡지 않는다 (저장 공간과 인덱스 크기에 영향)
· 향후 확장을 고려하되 근거 없이 늘리지 않는다

7. 슈퍼타입·서브타입 구현

세 방식은 조인과 NULL 중 무엇을 감수할지의 선택이다.

7.1 선택 예시

개인 고객 95만 건 · 법인 고객 3천 건
개인 고유 속성 3개 · 법인 고유 속성 8개
조회의 90%가 '고객번호로 한 건' 이며 타입을 가리지 않음

통합 조회가 압도적이므로 조인이 없는 Single이 맞다. 법인 고유 속성 8개가 95만 건에서 비게 되지만, 법인이 3천 건뿐이라 그 손해는 작다.

조건이 반대였다면 — 타입별 조회가 대부분이고 고유 속성이 많다면 — One To One이 낫다. 슈퍼타입 없이 각각 독립적으로만 쓰인다면 Plus다.

7.2 Plus 방식의 주의점

개인고객(고객번호, 고객명, 생년월일, 성별)
법인고객(고객번호, 고객명, 사업자번호, 대표자명)
              └──┬──┘
           공통 속성이 양쪽에 중복

전체 고객을 한 번에 조회할 방법이 없다. 두 테이블을 합쳐야 하며, 고객명이 양쪽에 중복된다.

7.3 자주 나오는 함정

✗  Single 은 고유 속성이 많을수록 NULL 이 줄어 유리하다     → 정반대
✗  슈퍼타입·서브타입은 항상 별도 테이블로 구현해야 한다      → 세 방식 중 선택
✗  논리에서 나눴으면 물리에서도 반드시 나눠야 한다           → 층위가 다르다

8. 참조 동작

관계를 외래키로 구현할 때, 부모가 삭제되거나 값이 바뀌면 자식을 어떻게 할지 함께 정한다.

연쇄와 제한을 반대로 이해하는 것이 가장 흔한 혼동이다. 연쇄는 막는 것이 아니라 같이 지우는 것이다.

선택 기준은 업무 규칙이다.

주문 ─ 주문상세    주문이 사라지면 상세도 의미 없음  → 연쇄
부서 ─ 사원        부서가 없어져도 사원은 남아야 함  → NULL 설정 또는 제한

9. 컬럼 순서

논리 모델의 속성 나열 순서는 읽기 좋게 정리한 것일 뿐이므로 물리에서 그대로 따를 이유가 없다.

· 기본키 컬럼을 앞쪽에 둔다
· 함께 조회되는 컬럼을 가까이 둔다
· 가변 길이 컬럼의 위치가 저장 효율에 영향을 줄 수 있다
· NOT NULL 컬럼을 앞쪽에 두는 편이 유리한 경우가 있다

이름순 정렬처럼 내용과 무관한 기준은 근거가 없다.

10. 접근 경로 확보

조회 조건과 정렬에 자주 쓰이는 속성은 접근 경로를 따로 두는 것을 검토한다.

값의 종류가 적은 속성(처리상태 세 가지)은 조건을 걸어도 걸러지는 양이 적어 효과가 작다. 회원번호처럼 값이 다양한 속성은 한 건으로 좁혀진다.

접근 경로를 늘리면 조회는 빨라지지만 입력·수정·삭제가 느려진다. 데이터를 바꿀 때마다 경로도 함께 갱신해야 하기 때문이다. 필요한 곳에만 두는 것이 원칙이다.

11. 대량 엔터티의 분할

인스턴스가 대량으로 쌓이는 엔터티는 일정 기준으로 나누어 저장하는 것을 검토한다.

얻는 것    조회 범위 축소 · 관리 단위 축소 (오래된 구간만 삭제·이관)
주의할 점  조회 조건이 분할 기준과 다르면 이득이 없다
           범위로 나누면 데이터 분포를 그대로 따라 한쪽에 몰릴 수 있다

분할은 물리 수준의 결정이다. 나누어 저장해도 논리 모델의 엔터티는 여전히 하나이며, 사용하는 쪽에서는 하나로 보인다.

---

3부 · 반정규화

12. 왜 하는가

정규화된 모델은 조인이 많아진다.

주문 목록 화면    주문과 회원을 조인해 회원명을 함께 표시
                  하루 200만 번 조회

회원명을 주문 엔터티에 복사해 두면 조인이 사라진다. 대신 회원명이 바뀔 때 두 곳을 맞춰야 한다.

반정규화는 성능을 얻고 정합성 관리 부담을 지는 거래다. 공짜가 아니며, 이득이 비용보다 크다는 판단이 있을 때만 정당화된다.

13. 대상 선정 기준

✓  응답 시간 요건을 반복적으로 만족하지 못하는 조회
✓  조인 단계가 깊고 그 조회가 전체 부하의 상당 부분을 차지
✓  같은 집계를 매번 대량 데이터에서 다시 계산
✓  대량 데이터를 범위로 처리하는 조회

✗  개발자가 쿼리 작성이 번거롭다고 느끼는 구간
✗  엔터티 수가 많아 모델 문서가 한 장에 안 들어감

기준은 측정된 성능이다. 작성 편의는 조회용 구조를 따로 두어 해결할 문제이지 데이터 구조를 바꿀 이유가 아니다.

14. 기법

14.1 테이블 차원

14.2 컬럼 차원

14.3 수직 분할의 함정

변경 전   회원(회원번호, 회원명, 등급, 자기소개글, 프로필이미지경로)

변경 후   회원기본(회원번호, 회원명, 등급)                -- 목록 화면 300만 회/일
          회원부가(회원번호, 자기소개글, 프로필이미지경로)  -- 상세 화면 5만 회/일

목록 조회는 가벼워지지만 상세 화면에서는 조인이 새로 생긴다. 300만 대 5만이므로 이 경우는 이득이지만, 비율이 반대였다면 손해다.

"분할하면 항상 조인이 줄어 성능이 좋아진다" 는 오답이다. 접근 패턴에 따라 이득과 손해가 갈린다.

15. 정규화와 혼동하지 않기

보기에 정규화 작업을 섞어 놓는 문제가 자주 나온다.

반정규화     중복 컬럼 추가 · 파생 컬럼 추가 · 테이블 병합 · 수직/수평 분할 · 요약 테이블
정규화       부분 함수 종속 제거 · 이행 종속 제거 · 다중값 속성 분리

✗  주문상세에서 상품번호에만 종속되는 상품명을 상품 테이블로 옮긴다
   → 제2정규형을 만족시키는 정규화다

16. 적용 원칙

1  논리 구조를 먼저 그대로 변환한다
2  접근 패턴을 분석해 병목이 예상되는 구간을 찾는다
3  그 구간에만 좁게 적용한다
4  적용 전후를 측정해 효과를 검증한다

미리 넓게 적용하면 중복 관리 부담만 전면적으로 늘어난다.

17. 정합성 유지 설계

반정규화를 적용했다면 반드시 함께 설계해야 한다.

① 갱신 기능에서 원본과 복사본을 함께 수정
② 데이터베이스 차원의 자동 동기화 장치를 둠
③ 주기적으로 두 값을 대조해 불일치를 점검

갱신 시점과 갱신 주체를 명시하는 것이 핵심이다.

"중복된 값은 조회 전용이므로 별도 관리가 필요 없다" 는 오답이다. 사용자가 보는 것은 복사본이므로, 방치하면 옛 이름이 계속 표시된다.

---

4부 · 물리 모델 품질검토

18. 검토 항목

19. 논리 모델과의 정합성

물리 모델은 반정규화 때문에 논리 모델과 일부러 달라진다. 그래서 검토가 필요하다.

확인    달라진 지점이 모두 의도된 것인가
        각 차이에 근거가 기록되어 있는가
        논리 모델에 반영되지 않은 변경이 물리에만 있지 않은가

마지막 항목이 중요하다. 물리에만 있는 변경은 추적할 수 없게 된다.

20. 세 모델을 모두 유지하는 이유

개념    전체 윤곽 · 범위 합의
논리    업무 의미의 기준 · 변경 영향 판단
물리    실제 구현

물리 모델만 남으면 반정규화된 테이블이 왜 그렇게 생겼는지 알 수 없다. 업무가 바뀔 때 어디를 고쳐야 하는지 판단할 근거가 사라진다.

21. 모델과 실제를 일치시키기

✓  DDL 을 모델에서 생성해 적용 (한 방향 흐름)
✓  주기적으로 실제 구조를 읽어 모델과 대조
✓  모델 변경과 데이터베이스 변경을 하나의 절차로 통제
✓  변경 이력과 사유를 형상 관리

✗  데이터베이스를 먼저 바꾸고 모델은 나중에 몰아서 맞춤
✗  모델은 초기 설계용으로만 쓰고 이후 관리하지 않음

몰아서 맞추면 그 사이 기간의 영향 분석이 모두 잘못된 전제 위에서 이루어진다.

---

22. 한 줄 정리