ERD 실습 1 - 논리적 모델(Logical Data Model)
0. 논리적 모델이란 무엇인가?
논리적 모델은 DB를 만들기 직전 단계의 설계다.
아직 DBMS(PostgreSQL, Oracle 등)나
데이터 타입, 인덱스 같은 물리적 요소는 고려하지 않는다.
대신,
✔ 어떤 정보가 필요하고
✔ 각각이 어떤 의미를 가지며
✔ 서로 어떻게 연결되는지
업무의 규칙을 데이터 구조로 표현한다.
즉,
프로그램이 아니라
업무를 데이터 언어로 번역하는 작업
이다.
1. 왜 논리적 모델이 중요한가?
여기서 잘못 설계되면
이후 단계는 전부 고통이 된다.
- 개발 복잡
- 수정 어려움
- 데이터 불일치
- 확장 불가능
반대로 논리 모델이 좋으면
구현은 따라온다.
2. 논리 모델 vs 물리 모델
논리 모델
무엇을 관리해야 하는가?
예:
- 수주가 존재한다
- 수주에는 여러 제품이 있다
- 출하는 수주에 의해 발생한다
물리 모델
DB에 어떻게 저장할 것인가?
예:
- varchar 길이
- index
- partition
- 테이블스페이스
개발자 대부분이
논리를 건너뛰고 물리로 바로 가서
시스템이 망가진다.
3. 논리적 모델링의 핵심 질문
좋은 설계자는 항상 묻는다.
- 이 데이터의 주인은 누구인가?
- 언제 생성되는가?
- 언제 변경되는가?
- 삭제 가능한가?
- 이 정보는 이력인가 현재 상태인가?
4. 출하 / 수주로 보는 논리 모델 사고법
수주(Order)
→ 고객의 요청
수주번호, 거래처, 요청일
출하(Shipment)
→ 요청의 실행 결과
출하번호, 수주번호, 출하일
출하상세
→ 무엇을 얼마나 보냈는가
제품, 수량
여기서 중요한 발견:
✔ 수주와 출하는 역할이 다르다
✔ 출하는 여러 번 나갈 수 있다
✔ 수량은 헤더가 아니라 상세에 있어야 한다
이게 논리 모델링이다.
5. 논리 모델에서 반드시 분리해야 하는 것
마스터 vs 트랜잭션
제품, 거래처 → 마스터
수주, 출하 → 트랜잭션
현재 상태 vs 이력
재고 수량 vs 이동 기록
요청 vs 결과
수주 vs 출하
이걸 섞으면
100% 나중에 터진다.
6. 논리 모델이 잘못되었을 때 생기는 현상
- 수정할 곳이 여러 군데
- 어디 값이 맞는지 모름
- 화면마다 결과 다름
- 통계 안 맞음
즉, 신뢰를 잃는다.
7. 고급 설계자가 보는 포인트 (진짜 중요)
ERD를 보면 확장이 보여야 한다.
부분 출하 가능?
취소 가능?
재출하 가능?
이게 안 보이면 구조 부족.
업무 규칙이 데이터 구조 안에 녹아 있어야 한다.
코드로 막지 말고
구조로 표현해야 한다.
8. 논리 모델을 잘하면 생기는 일
- 개발 빨라짐
- 유지보수 쉬움
- 데이터 설명이 쉬움
- 신규 인원 적응 빠름
9. 결국 논리 모델이란
시스템의 미래를 준비하는 설계 단계
이다.
여기서 대충 만들면
그 시스템은 계속 대충 고쳐가며 살아야 한다.
요약
논리적 모델
- 업무 규칙을 데이터 구조로 정의하는 단계
- DBMS나 성능보다 의미와 관계가 우선
논리 모델을 하는 이유
- 구현 전에 구조 문제를 발견하기 위해
- 수정과 확장이 가능한 형태로 만들기 위해
핵심 질문
- 누가 주인인가?
- 요청인가 결과인가?
- 현재인가 이력인가?
출하/수주 예시
- 수주 = 요청
- 출하 = 실행
- 수량 = 상세
중요 원칙
- 마스터와 트랜잭션 분리
- 상태와 이력 분리
- 의미가 다른 것은 다른 테이블
정리
- 논리 모델이 좋으면 구현은 자연스럽다
- 대부분의 시스템 문제는 이 단계에서 시작된다
학습 후기
논리적 모델을 배우면서 데이터베이스 설계의 중심이 기술이 아니라 업무 이해라는 사실을 깨닫게 되었다. 테이블을 어떻게 만들지가 아니라, 어떤 개념을 어디에 두어야 하는지가 더 중요했다. 특히 수주와 출하를 요청과 결과로 나누는 순간 구조가 선명해졌고, 왜 많은 시스템이 시간이 지나며 복잡해지는지도 이해할 수 있었다. 좋은 설계는 당장의 편의가 아니라 미래의 변경을 버틸 수 있는 준비라는 점이 인상 깊었다.