Ch08. 논리적 모델링 - 실습 준비

쇼핑몰 MVP 개념적 모델

개념적 설계 모델

• 엔티티: 회원, 상품, 주문, 결제, 배송, 주문 항목
• 관계: 회원-주문(1:N), 주문-결제(1:1), 주문-배송(1:1), 주문-상품(M:N)은 주문 항목을 통해 1:N 관계로 해소

논리적 모델링은 이 개념적 모델을 관계형 데이터베이스의 언어(테이블, 컬럼, 키)로 번역하는 과정이다. 이 단계는 단순히 "1:1"로 번역하는 것에 그치지 않는다. 우리가 논리적 모델링 단계에서 학습한 수많은 트레이드오프들을 고민하면서 제품의 현실적인 제약과 개발 효율성, 성능까지 고려하여 모델을 다듬고 최적화하는 실용적인 판단이 필요하다.

 

개념에서 논리로(변환의 법칙)

1) 엔티티(Entity)는 테이블(Table)로 변환된다.

개념적 모델에서 정의한 데이터의 묶음, 즉 엔티티는 논리적 모델에서 데이터를 실제로 저장하는 구조인 테이블이 된다.

• 회원 엔티티 → 회원 테이블
• 상품 엔티티 → 상품 테이블
• 주문 엔티티 → 주문 테이블

2) 속성(Attribute)은 컬럼(Column)으로 변환된다.

각 엔티티가 가지고 있던 세부 정보, 즉 속성은 테이블의 각 컬럼으로 변환된다. 이 과정에서 우리는 각 컬럼에 저장될 데이터의 종류와 크기를 정의하는 데이터 타입(VARCHAR, BIGINT, DATETIME 등)을 결정하게 된다. 그리고 추가로 제약조건도 정한다.

• 회원 엔티티의 회원명 속성 → 회원 테이블의 회원명 VARCHAR(50) NOT NULL 컬럼
• 상품 엔티티의 가격 속성 → 상품 테이블의 가격 INT 컬럼

 

3) 식별자(Identifier)는 기본 키(Primary Key)로 변환된다.

각 엔티티를 유일하게 구분해주던 식별자는 테이블의 각 행(row)을 유일하게 보장하는 기본 키(Primary Key)가 된다. 여기서 우리는 앞서 배운 중요한 설계 원칙을 적용한다. 개념적 모델의 회원id와 같은 식별자는 비즈니스와 무관한 대리 키(Surrogate Key)를 사용하여 PK로 구현한다.

• 회원 엔티티의 식별자 "회원 id" → 회원 테이블의 "회원id" BIGINT NOT NULL AUTO_INCREMENT 기본 키

4) 관계(Relationship)는 외래 키(Foreign Key)와 제약조건으로 변환된다.

개념적 모델에서 엔티티 사이를 연결하던 선, 즉 관계는 논리적 모델에서 테이블들을 연결하는 외래 키(Foreign Key)를 통해 구체화된다.관계의 종류(카디널리티)에 따라 변환 방식이 달라진다.

• 일대다(1:N) 관계
  • "다(N)" 쪽 테이블이 "일(1)" 쪽 테이블의 기본 키를 외래 키로 가진다.
  • "회원(1)"과 "주문(N)"의 관계 → 주문 테이블에 "회원 id" 외래 키 컬럼이 추가되어 회원 테이블의 "회원 id"를 참조한다.
• 일대일(1:1) 관계
  • 두 테이블 중 하나가 상대방의 기본 키를 외래 키로 가지며, 해당 외래 키에는 UNIQUE 제약 조건이 추가되어야 한다.
  • 주로 더 부가적이거나, 나중에 생성되는 "자식" 역할의 테이블에 외래 키를 둔다.
  • "주문(1)"과 "배송(1)"의 관계 → 배송 테이블에 "주문 ID" 외래 키 컬럼을 추가하고, 여기에 UNIQUE 제약조건을 설정한다.
• 다대다(M:N) 관계
  • 두 엔티티 사이의 관계 자체가 새로운 테이블로 변환된다.
    • 이 테이블을 연결 테이블(Junction Table)이라 부른다.
    • 참고로 개념적 모델에서 양쪽으로 뻗어 나가던 다대다 관계는 관계형 데이터베이스에서 직접 표현할 수 없다.
    • 그래서 중간에 연결 테이블이라는 새로운 테이블을 만들어 두 개의 "일대다(1:N)" 관계로 풀어낸다.
  • "주문(M)"과 "상품(N)"의 관계 → "주문 항목"이라는 새로운 연결 테이블이 생성된다.
    • 이 테이블은 주문 테이블을 참조하는 "주문 ID" 외래 키와 상품 테이블을 참조하는 "상품 ID" 외래 키를 모두 가진다.
  • 우리의 경우 이미 자신의 속성을 가지는 "주문 항목"이라는 연관 엔티티를 개념적 모델링 단계에서 찾았다. 이 경우 연관 엔티티를 연결 테이블로 만들면 된다.

요약: 개념적 모델 vs 논리적 모델

개념적 모델과 논리적 모델 요약

 

참고: 논리적 모델링과 물리적 모델링, 무엇이 다를까?

관계형 데이터베이스 설계는 개념적 설계 이후에 논리적 모델링과 물리적 모델링 두 단계로 나뉘지만, 실제로는 그 경계가 모호할 때가 많다.

 

관계형 데이터베이스별 물리적 타입 비교

논리적 타입	MySQL	Oracle	PostgreSQL
자동 증가하는 큰 숫자	BIGINT AUTO_INCREMENT	NUMBER (+ SEQUENCE)	BIGSERIAL
가변 길이 문자열	VARCHAR(n)	VARCHAR2(n)	VARCHAR(n)

 

 

논리적 모델링: 데이터의 청사진 그리기

논리적 모델링은 이미 관계형 데이터베이스를 사용하기로 결정한 단계이다. 그리고 어떤 관계형 데이터베이스를 사용할지 정하기 전에, 데이터의 구조와 관계를 정의하는 단계이다. 정리하면 관계형 데이터베이스 모델에 맞추어 일종의 데이터 청사진을 그리는 과정이다.

• 핵심
  • 관계형 데이터베이스 이론에 맞추어 데이터의 논리적 구조를 설계한다.
  • MySQL, Oracle 등 특정 기술과 무관
• 예시
  • "회원에게는 "회원명" 속성이 있고, 문자열(String) 형태다."라고 정의하는 것이다.
  • 이렇게 하면 특정 기술과 무관하게 정할 수 있다.

 

물리적 모델링: 실제 창고에 물건 쌓기

물리적 모델링은 논리적 모델을 바탕으로, 실제 데이터베이스에 어떻게 데이터를 저장할지 구체적으로 정하는 단계이다.

• 핵심
  • 특정 데이터베이스(예: MySQL)에 최적화된 형태로 구현한다.
• 예시 
  • 논리 모델의 "문자열"을 MySQL에서 "VARCHAR(50)"으로 할지, "TEXT"로 할지 성능과 효율을 따져 결정한다.
  • 인덱스를 설정하는 것 또한 이 단계에 해당한다.

 

이론과 실무의 차이: 왜 경계가 모호할까?

데이터베이스 설계에서 논리적 모델링(청사진)과 물리적 모델링(실제 구현)은 이론적으로 구분되지만, 실무에서는 개발 속도를 높이고 불필요한 수정을 줄이며, 처음부터 성능을 고려하기 위해 두 단계를 함께 진행하는 경우가 많다. 즉, 효율성을 위해 청사진을 그리는 동시에 실제 사용할 데이터베이스의 특성을 미리 반영한다. 여기서도 컬럼과 같은 일부 내용은 논리적 모델링 단계에 함께 적용하겠다