데이터 모델링 관점(데이터·프로세스·상관)과 3단계(개념·논리·물리) 정리

martin blake 12월 31, 2025


데이터 모델링 관점(데이터·프로세스·상관)과 3단계(개념·논리·물리) 정리

데이터 모델링은 “DB 테이블을 그리는 작업”만을 의미하지 않습니다. 조직이 어떤 정보를 어떤 규칙으로 관리할지, 업무가 어떤 흐름으로 돌아가며 그 과정에서 데이터가 어떻게 생성·변경·조회·삭제되는지까지 구조화하는 활동입니다. 특히 실무에서는 요구사항이 바뀌거나(정책 변경), 시스템이 확장되거나(신규 채널/서비스), 성능과 규제가 강화될 때(개인정보/보안) 모델링 품질이 곧 운영 안정성으로 이어집니다.


요약

  • 데이터 모델링의 관점은 데이터 관점(무엇을 관리할 것인가), 프로세스 관점(어떻게 처리할 것인가), 데이터-프로세스 상관 관점(업무가 데이터를 어떻게 바꾸는가)로 나눌 수 있습니다.
  • 데이터 모델링 3단계는 개념적 → 논리적 → 물리적 순서로, 이해관계자 합의에서 구현 최적화까지 점진적으로 구체화합니다.
  • 실무 품질을 높이려면 “엔터티/관계(ERD)”만 보지 말고, CRUD 관점으로 프로세스와 데이터의 연결을 반드시 점검해야 합니다.


목차


핵심 포인트

  • 데이터 관점은 “데이터 자체의 구조와 규칙”을, 프로세스 관점은 “업무 처리 흐름과 기능 단위”를, 상관 관점은 “기능이 데이터를 어떻게 다루는지(CRUD)”를 중심으로 봅니다.
  • 개념/논리/물리 모델링은 산출물이 달라지고, 보는 사람(업무/기획/개발/DBA)과 질문이 달라집니다. 단계별 목적을 혼동하면 과도한 설계 또는 구현 누락이 발생합니다.
  • 모델링 품질은 ERD의 모양이 아니라, 업무 규칙이 데이터 제약조건으로 제대로 반영되는지, 프로세스가 데이터 생애주기와 정합적인지로 판단하는 편이 안전합니다.


1) 데이터 관점: 무엇을 저장하고 어떤 규칙으로 관리할까

데이터 관점은 “업무에서 관리해야 하는 대상(사람/상품/주문/계약 등)을 데이터로 정의하고, 그 데이터가 어떤 속성과 관계를 가지는지”에 초점을 둡니다. 핵심은 다음 질문에 답하는 것입니다.

  • 우리가 관리해야 하는 핵심 엔터티(개체)는 무엇인가?
  • 각 엔터티의 속성(항목)은 무엇이며, 필수/선택은 어떻게 구분하는가?
  • 엔터티 간 관계는 어떻게 연결되며(1:1, 1:N, N:M), 그 관계에 업무 규칙(제약)이 있는가?
  • 데이터의 유일성(식별자), 정합성(도메인/범위), 무결성(참조/업무 규칙)은 어떻게 보장하는가?

이 관점의 장점은 “데이터 표준화”에 강하다는 점입니다. 엔터티/속성/코드 체계를 명확히 하면 여러 시스템이 붙더라도 용어 혼선이 줄고, 분석·리포팅 기반이 안정됩니다. 반면 프로세스 변화(업무 흐름 변경)가 데이터 구조에 어떤 영향을 주는지까지는 별도 점검이 필요합니다.

엔터티(Entity)
저장/관리해야 하는 "대상"이며, 보통 테이블로 구성됩니다.
예) 고객(Customer), 주문(Order), 상품(Product)

속성(Attribute)
엔터티가 가지는 "항목(칼럼)"입니다.
예) 고객 : 고객ID, 이름, 연락처

관계(Relationship)
엔터티들 사이의 "연결 규칙"입니다. 보통 외래키(FK)로 구현됩니다.
예) 고객 1명이 여러 주문을 가질 수 있다. (1:N)

ERD(Entity-Relationship Diagram)
위의 엔터티(테이블), 속성(컬럼), 관계(연결/카디널리티)를 한 눈에 보이도록 나타낸 다이어그램입니다.


2) 프로세스 관점: 업무 흐름과 처리 단위를 어떻게 볼까

프로세스 관점은 “업무가 어떤 단계로 진행되고, 각 단계에서 어떤 입력이 들어오며 어떤 결과가 나오는지”에 초점을 둡니다. 일반적으로 프로세스 모델(예: 업무 흐름도, DFD, BPMN 등)로 표현하며 다음을 정리합니다.

  • 업무의 시작/종료 조건, 주요 단계(접수→검증→승인→정산 등)
  • 각 단계의 책임 주체(사용자/시스템/외부 기관)와 예외 흐름(반려/재처리)
  • 처리 규칙(승인 조건, 한도, 상태 전이)과 이벤트(알림, 배치, 마감)

프로세스 관점의 장점은 “요구사항 누락을 줄이고, 기능 단위를 설계하기 쉽다”는 점입니다. 다만 데이터 구조가 탄탄하지 않으면 같은 의미의 데이터가 여러 위치에서 중복 관리되거나, 상태가 분산되어 정합성 문제가 생길 수 있습니다.


3) 데이터-프로세스 상관 관점: 업무가 데이터를 어떻게 바꾸는가(CRUD)

상관 관점은 데이터 관점과 프로세스 관점을 연결합니다. 핵심은 “각 프로세스 단계가 어떤 데이터를 생성(Create), 조회(Read), 변경(Update), 삭제(Delete)하는지”를 명확히 하는 것입니다. 이 관점이 중요한 이유는 다음과 같습니다.

  • 업무는 돌아가는데 데이터가 누락되는 문제(예: 승인 단계에서 상태값 갱신 누락)를 초기에 발견할 수 있습니다.
  • 권한·감사(누가 무엇을 바꿨는가), 개인정보 접근 통제처럼 운영 요구사항을 CRUD 기반으로 설계하기 쉽습니다.
  • 성능 관점에서도 “조회가 많은 테이블/인덱스 후보”와 “갱신이 많은 구간(락/트랜잭션)”을 사전에 파악할 수 있습니다.

실무에서는 ERD와 프로세스 흐름도를 각각 만든 뒤, CRUD 매트릭스로 교차 점검하는 패턴이 많이 쓰입니다. 이때 “아무도 만들지 않는 데이터(고아 엔터티)”나 “누구도 쓰지 않는 컬럼(죽은 속성)”이 눈에 띄게 드러납니다.


4) 데이터 모델링 3단계: 개념적 → 논리적 → 물리적

개념적 데이터 모델링(Conceptual)

  • 목적: 업무 관계자와 “무엇을 관리할지”를 합의합니다.
  • 특징: 엔터티와 주요 관계 중심으로 단순화(핵심 개념만). 기술 요소(타입, 인덱스, 파티션)는 배제합니다.
  • 산출물: 핵심 엔터티 목록, 관계(대략), 용어 정의(업무 용어 사전 초안).

논리적 데이터 모델링(Logical)

  • 목적: 업무 규칙을 데이터 구조와 제약조건으로 구체화합니다.
  • 특징: 속성(컬럼) 정의, 식별자(PK)와 관계(FK) 설계, 정규화, 도메인/코드 체계, 필수/선택, 카디널리티 등을 명확히 합니다.
  • 산출물: 논리 ERD, 속성 정의서(데이터 사전), 업무 규칙 목록(제약조건으로 반영할 항목 포함).

물리적 데이터 모델링(Physical)

  • 목적: 특정 DBMS에 맞춰 실제 구현과 성능·운영을 최적화합니다.
  • 특징: 테이블/컬럼 타입, 인덱스, 파티션, 제약조건, 스토리지 옵션, 명명 규칙, 히스토리/로그 테이블, 배치 전략 등을 설계합니다.
  • 산출물: 물리 ERD, DDL, 인덱스/파티션 설계서, 운영 가이드(백업/아카이빙/모니터링).


관점/단계 비교 표

구분 초점 대표 질문 주요 산출물
데이터 관점 데이터 구조/규칙 무엇을 저장하고 어떤 관계인가? 엔터티/관계, 속성, 제약
프로세스 관점 업무 흐름/처리 단위 어떤 단계로 처리되고 예외는? 업무 흐름도/DFD/BPMN
상관 관점 CRUD 연결/정합성 이 단계가 어떤 데이터를 C/R/U/D 하는가? CRUD 매트릭스, 권한/감사 포인트
개념 모델 업무 합의 핵심 개념은 무엇인가? 핵심 엔터티/관계, 용어
논리 모델 규칙의 구조화 식별자/관계/도메인은 타당한가? 논리 ERD, 데이터 사전
물리 모델 구현/성능 어떤 타입/인덱스/파티션이 필요한가? DDL, 인덱스/파티션 설계


물리 모델링 예시: DDL로 연결해 보기

아래 예시는 “고객-주문” 관계를 물리 모델로 구현하는 간단한 DDL 예시입니다. 논리 모델에서 정한 식별자(PK), 참조 무결성(FK), 상태 관리(주문 상태), 성능 고려(조회 인덱스)를 최소 범위로 반영했습니다.

-- 고객
CREATE TABLE customer (
  customer_id      BIGINT PRIMARY KEY,
  customer_name    VARCHAR(100) NOT NULL,
  email            VARCHAR(200) UNIQUE,
  created_at       TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- 주문
CREATE TABLE orders (
  order_id         BIGINT PRIMARY KEY,
  customer_id      BIGINT NOT NULL,
  order_status     VARCHAR(20) NOT NULL, -- 예: CREATED, PAID, SHIPPED, CANCELED
  order_amount     DECIMAL(12,2) NOT NULL,
  ordered_at       TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT fk_orders_customer
    FOREIGN KEY (customer_id) REFERENCES customer(customer_id)
);

-- 조회 패턴(고객별 최신 주문) 고려 인덱스
CREATE INDEX idx_orders_customer_ordered_at
  ON orders (customer_id, ordered_at DESC);

이 예시를 상관 관점으로 연결하면, “주문 생성” 프로세스는 orders에 Create, “결제 완료 처리”는 Update(상태 변경), “고객 주문 조회”는 Read, “취소/삭제 정책”은 Update(상태 변경) 또는 Delete(정책상 물리 삭제 허용 시)로 매핑됩니다. 즉, 물리 모델은 프로세스와 분리된 결과물이 아니라, 프로세스의 데이터 영향이 안전하게 구현된 형태로 보는 편이 실무에서 일관성이 높습니다.


실무 실행 단계 체크리스트

  1. 업무 범위 확정: 도메인(예: 주문/정산/배송)과 용어를 먼저 합의하고, 핵심 엔터티 후보를 뽑습니다.
  2. 개념 모델 작성: “핵심 엔터티/관계”만으로 단순화해 이해관계자와 빠르게 정렬합니다.
  3. 프로세스 모델 작성: 주요 시나리오(정상/예외)를 흐름도로 정리하고 상태 전이를 명확히 합니다.
  4. 논리 모델 구체화: PK/FK, 필수값, 도메인/코드, 정규화, 업무 제약을 구조에 반영합니다.
  5. 상관 점검(CRUD): 기능 단위로 CRUD 매트릭스를 만들고 누락/중복/권한 이슈를 잡습니다.
  6. 물리 모델/성능 설계: DBMS별 타입·인덱스·파티션, 대량 처리(배치)와 트랜잭션 경계를 설계합니다.
  7. 운영 기준 반영: 감사 로그, 개인정보 마스킹/암호화, 보존/파기, 백업/아카이빙을 포함합니다.
  8. 변경 관리: 모델 버전 관리, 마이그레이션 전략, 배포 절차(롤백 포함)를 문서화합니다.


추가로 생각해볼 점

  • 정규화 vs 성능: 논리 모델은 정규화를 통해 의미를 명확히 하는 데 강점이 있지만, 물리 모델에서는 조회 패턴에 따라 일부 비정규화/요약 테이블이 필요할 수 있습니다.
  • 상태 모델링: 프로세스가 상태 전이로 표현되는 업무(주문/승인/정산)는 “상태값 정의와 전이 규칙”을 데이터 제약과 함께 관리해야 운영 혼선이 줄어듭니다.
  • 감사/이력: 누가 언제 어떤 값을 바꿨는지(감사)와 과거 시점 조회(이력)는 초기에 요구가 모호해도, 운영 단계에서 자주 필요해집니다.
  • 개인정보/보안: 상관 관점에서 CRUD를 기준으로 접근 권한을 설계하면, “누가 어떤 데이터에 접근 가능한지”가 명확해집니다.
  • 모델링 산출물의 수명: ERD는 한 번 그려서 끝이 아니라, 정책 변경과 기능 확장에 따라 지속적으로 갱신되는 운영 자산으로 관리하는 편이 좋습니다.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

Reactions
martin blake

작성자: martin blake

댓글 쓰기

0 댓글