09. 논리 모델링

이 글은 김영한님의 인프런 강의 실전 데이터베이스 설계 1편을 참고하여 정리한 글입니다.

1. 논리 모델링

• 데이터 구조 전체의 청사진을 그리는 단계다.
• 특정 DBMS 제품에 의존하지 않고, 데이터의 구조와 관계를 명확히 정의한다.
• 관계형 이론(정규화 등)에 맞추어 데이터의 논리적 구조를 설계한다.

2. 개념 모델 → 논리 모델 변환

• 엔티티는 테이블로, 속성은 컬럼으로 변환한다.
• 기본키는 비즈니스와 무관한 대리키로 둔다. 엔티티의 원래 식별자는 자연키로 남기고, 유니크 제약조건으로 유일성을 보장한다.
• 관계는 외래키 또는 연결 테이블로 변환하며, 비식별 관계로 맺는다.
  • 일대다: 다(N)쪽 테이블이 일(1)쪽 테이블의 기본키를 외래키로 갖는다.
  • 일대일: 종속되는(자식) 테이블이 외래키를 갖고, 해당 컬럼에 유니크 제약조건을 걸어 일대일 관계를 보장한다. 필수 관계라면 NOT NULL도 함께 건다.
  • 다대다: 두 테이블의 기본키를 외래키로 갖는 별도의 연결 테이블로 풀어낸다. 이때도 기본키는 대리키로 두고, 외래키 조합에 유니크 제약조건을 건다.

기본키는 대리키, 자연키는 유니크 제약조건, 관계는 비식별 관계.

3. 물리 모델링

• 논리 모델을 바탕으로 실제 데이터베이스에 어떻게 저장할지 구체화하는 단계다.
• 특정 DBMS에 최적화된 형태로 설계한다.
• 컬럼의 데이터 타입과 길이를 정하고, 인덱스·제약조건·파티셔닝 등을 설계한다.

4. 실무에서의 모델링

• 실무에서는 논리와 물리 단계를 엄격히 분리하지 않는다. 개발 속도를 높이고 재작업을 줄이기 위해 사용할 DBMS를 먼저 확정하고, 해당 DBMS의 특성과 성능 이슈를 논리 설계 단계에서부터 함께 반영한다.
• 구조 역시 이론대로만 가지 않는다. 개념 모델에서는 역할별로 엔티티를 분리하지만, 실무에서는 개발 속도와 단순성을 위해 일부 테이블을 합치기도 한다.
• 정규화 수준과 구조의 단순성은 트레이드오프 관계다.
• 서비스가 복잡해지면 합쳤던 테이블을 다시 분리할 수 있다. 다만 이미 쌓인 데이터를 옮겨야 하므로, 나중의 분리에는 적지 않은 비용이 따른다.