[Database] 데이터 모델링의 특징 및 유의사항

데이터 모델링이란?

비즈니스에서 사용하는 데이터(고객, 주문, 상품, 계약 등)를
현실 세계 → 시스템에서 다룰 수 있는 구조로 옮겨 담는 설계 작업

 

데이터 모델링의 3가지 특징

1. 추상화 (Abstraction)

복잡한 현실을 본질적인 것만 골라 표현하는 것

• 고객 = “이름/연락처/등급/가입일” 정도만 쓰고 혈액형, 좋아하는 색 같은 건 설계 대상에서 제외
• “배송 상태”를 상세 텍스트가 아닌 주문상태코드로 관리

2. 단순화 (Simplification)

이해하기 쉽고 관리하기 쉬운 구조로 정리해서 표현하는 것

• 같은 의미의 정보를 여기저기 나누지 말고 한 곳(한 엔터티)에 모으기
• 복잡한 규칙은 코드·도메인 테이블로 정리
• 엑셀처럼 “보이기용 컬럼”을 막 추가하는 게 아니라 정리된 구조 유지

3. 명확화 (Clarification)

누가 봐도 동일하게 이해할 수 있도록 규칙과 의미를 분명히 하는 것

• “고객” vs “사용자” vs “회원” 용어 구분
• “주문일자”가 주문 생성일인지, 결제 완료일인지 정의
• PK, FK, NOT NULL, UNIQUE, 도메인(코드 값 범위) 등 제약조건을 모델에 명시

 

데이터 모델링의 3단계

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

비즈니스 관점. “무엇을 관리할 것인가?”

• 주요 엔터티: 고객, 주문, 상품, 결제, 계약, 매장 …
• 엔터티 간 관계: 고객–주문(1:M), 주문–상품(M:N) 등
• 기술 요소(DBMS 종류, 인덱스)는 고려 X

Ex: 개념 ERD, 용어 정의서

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

시스템 관점. “어떻게 구조화할 것인가?”

• 엔터티 → 테이블 구조로 구체화
• 속성 정의: 데이터 타입(정수, 문자, 날짜), 길이, 필수 여부(NOT NULL)
• PK/FK 설정, 정규화 진행
• DBMS 종류에 의존하지 않는 수준의 모델

Ex 논리 ERD, 속성 정의서, 정규화된 테이블 목록

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

실제 DB 관점. “선택한 DBMS에 어떻게 구현할 것인가?”

• Oracle, MySQL, PostgreSQL 등 구체 DBMS 문법 적용
• 인덱스 설계, 파티셔닝, 클러스터링, 스토리지, 자료형 최종 결정
• 성능/보안/백업 전략 반영

Ex: 실제 CREATE TABLE 스크립트, 인덱스 설계서, 파티션 전략

 

ANSI-SPARC 3단계 스키마 구조

ANSI-SPARC는 “DB를 3개의 관점으로 나눠서 보자”는 구조를 제안.

1) 외부 스키마 (External Schema)

사용자/응용 프로그램 각각의 시야.

• 예: “영업팀이 보는 고객리스트 화면”, “정산팀이 보는 매출보고서”
• 전체 DB 중 필요한 일부만, 특정 형식으로 보여줌 (뷰 VIEW가 대표적)
• 목적: 사용자마다 다른 관점 제공 + 보안/편의성 확보

2) 개념 스키마 (Conceptual Schema)

조직 전체 관점에서의 통합 논리 모델.

• 모든 엔터티, 관계, 제약조건을 일관되게 정의한 “공식 설계도”
• 데이터 중복/모순을 최소화하고, 전체 구조를 하나로 통제하는 레벨

3) 내부 스키마 (Internal Schema)

실제 저장 구조 관점.

• 테이블이 디스크에 어떻게 저장되는지
• 인덱스 구조, 파티션, 파일 구조 등
• 성능·저장 효율을 위한 물리적 설계 요소 포함

 

데이터 모델링 시 유의사항

모델 그리기 전에/그리면서 꼭 잡아야 하는 체크포인트들

1. 업무 용어 정리
   • 같은 말을 다른 의미로 쓰지 않기
   • 용어 사전(데이터 사전, Data Dictionary)을 함께 관리
2. 업무 규칙과 제약조건을 모델에 반영
   • “한 주문은 한 고객에 속한다”
   • “회원 탈퇴 시 주문 기록은 유지”
   • 이런 규칙이 엔터티/관계/제약조건으로 드러나야 함
3. 중복·모순 최소화
   • 같은 정보가 여러 테이블에 흩어져 있으면 안됨.
   • 필요한 경우(성능 튜닝용 중복)는 “왜 중복했는지”를 명확히
4. 정규화 + 성능 균형
   • 기본은 정규화로 구조를 깨끗하게.
   • 조회 패턴, 트래픽, 성능 요구를 보고 필요한 부분에만 비정규화(캐시/집계 컬럼 등).
5. 변경 가능성 고려 (유연성)
   • 코드값 추가, 상품 종류 확대 등 “당연히 바뀔 것들”을 상수 박지 말고 테이블화.
   • M:M 관계는 중간 테이블로 풀어두어 확장 여지 확보.
6. 현업과의 커뮤니케이션
   • ERD는 개발자 전용 그림이 아니라,
     현업도 “아 이게 우리 데이터 구조구나” 이해할 수 있게 설명 가능한 수준으로.
7. 보안·권한·감사 로그 고려
   • 민감 정보(주민번호, 카드정보 등)는 별도 테이블/마스킹/암호화 전제.
   • 누가 뭘 바꾸는지 추적 가능한 설계.