모델이 표현하는 트랜잭션: 업무 단위와 데이터 발생 구조

핵심 요약

데이터 모델에서 말하는 트랜잭션은 고객 주문, 계약 체결, 입금 처리처럼 업무에서 한 번에 발생하는 사건과 데이터 변화의 단위입니다. 데이터베이스의 COMMIT·ROLLBACK 단위와 관련은 있지만 같은 개념은 아닙니다. 업무 트랜잭션을 분석하면 어떤 엔터티가 동시에 생성·변경되는지, 관계의 필수성·카디널리티·이력 구조가 적절한지 판단할 수 있습니다.

업무 트랜잭션과 DB 트랜잭션

한 업무 트랜잭션이 구현상 여러 DB 트랜잭션으로 분리될 수도 있고, 여러 작은 업무 처리가 한 Batch DB 트랜잭션으로 묶일 수도 있습니다. 모델링에서는 먼저 업무 의미를 식별하고, 구현 단계에서 원자성·동시성·복구 요구에 맞는 DB 경계를 정합니다.

주문 업무 예

고객 1 ── N 주문 1 ── N 주문상품
                    1 ── N 결제시도
                    1 ── 0..N 배송

“주문 접수”라는 업무 사건을 분석하면 다음 데이터가 발생할 수 있습니다.

1. 주문 한 행 생성
2. 선택한 상품마다 주문상품 여러 행 생성
3. 결제를 시도하면 결제시도 행 생성
4. 재고 예약 또는 배송 요청 상태 변경
5. 상태 변경 이력 기록

이때 주문과 주문상품을 한 테이블에 반복 저장하면 주문일시·고객번호가 상품 수만큼 중복되고, 주문 Header 수정 시 갱신 이상이 발생할 수 있습니다. 반대로 주문상품을 분리하면 주문 한 건의 Grain과 상품 Line Grain을 명확히 표현할 수 있습니다.

트랜잭션 분석으로 확인하는 관계

필수성

주문 없이 주문상품이 존재할 수 없다면 주문상품에서 주문 관계는 필수입니다. 반면 배송은 주문 직후 아직 없을 수 있으므로 주문 기준 0..N일 수 있습니다.

카디널리티

한 주문에 상품이 하나 이상인지, 0개도 가능한지에 따라 관계 최소 카디널리티가 달라집니다. 단순히 “1:M”만 외우지 말고 업무 발생 시점을 확인합니다.

데이터 발생 순서

주문 생성 → 주문상품 생성 → 결제 승인 → 배송 준비

발생 순서는 FK, 상태값, 이력 엔터티와 트랜잭션 처리 순서를 설계하는 근거가 됩니다. 다만 논리 모델의 관계 방향과 프로그램 실행 순서를 같은 것으로 단정하지 않습니다.

반복 속성과 이력 분리

고객 테이블에 최근주문1, 최근주문2, 최근주문3 같은 반복 속성을 두면 주문 횟수 증가에 대응하기 어렵습니다. 주문은 독립 엔터티로 분리하고 관계로 표현합니다.

상태가 여러 번 변하면 현재 상태만 덮어쓸지, 상태 이력을 별도 엔터티에 남길지도 업무 요구로 판단합니다.

ORDER(order_id, current_status)
ORDER_STATUS_HIST(order_id, changed_at, status)

문제 적용 순서

1. 지문에서 한 번 발생하는 업무 사건을 찾습니다.
2. 사건 하나가 생성·변경하는 엔터티를 나열합니다.
3. 각 엔터티의 한 행이 무엇을 나타내는지 적습니다.
4. 필수·선택 관계와 1:1·1:M·M:N을 판단합니다.
5. 반복 속성, 중복 저장, 이력 누락이 없는지 확인합니다.
6. 업무 트랜잭션과 COMMIT 문법을 같은 개념으로 혼동하지 않습니다.

자주 틀리는 판단

• 업무 트랜잭션은 반드시 SQL 한 문장이다 → 틀림
• 한 업무 트랜잭션은 반드시 DB COMMIT 한 번과 1:1이다 → 구현과 요구에 따라 다름
• 데이터 발생 순서만으로 관계의 모든 카디널리티가 결정된다 → 업무 규칙 확인 필요
• 반복되는 업무 사실을 컬럼 번호로 늘리면 된다 → 확장성과 정규화 문제

복습 문제

1. 업무 트랜잭션과 데이터베이스 트랜잭션의 차이를 설명하라.
2. 주문 접수 업무를 분석할 때 주문과 주문상품을 분리하는 근거는 무엇인가?
3. 트랜잭션 분석으로 관계의 필수성과 카디널리티를 판단하는 순서를 설명하라.