관계형 데이터 모델링으로 설계하는 데이터베이스 구조

테이블보다 먼저 정해야 할 것

관계형 데이터 모델링은 실세계의 정보를 관계형 데이터베이스에 저장할 수 있는 구조로 바꾸는 설계 방법론이다. 1970년 E.F. Codd가 제안한 관계형 모델을 토대로 발전했으며, 데이터 사이의 연관성을 테이블과 관계로 표현한다.

좋은 모델은 데이터의 무결성과 일관성을 지키면서도 업무 변화에 대응할 수 있어야 한다. 이를 위해서는 관리 대상, 그 대상의 특성, 대상 간 연결 방식을 분리해 검토해야 한다.

관리 대상과 데이터 사이의 연결

엔티티는 업무에서 관리해야 하는 실체나 정보 객체다. 고객, 상품, 주문, 직원처럼 독립적으로 존재하고 식별할 수 있는 대상을 엔티티로 잡으며, 관계형 데이터베이스에서는 테이블로 구현한다.

속성은 엔티티가 지닌 특성이다. 고객 엔티티라면 고객ID, 이름, 주소, 전화번호 등이 속성이며 테이블의 컬럼이 된다.

관계는 엔티티 사이의 업무적 연관성과 데이터 참조 방식을 뜻한다. 관계는 1:1, 1:N, N:M으로 구분하며, 데이터베이스에서는 외래 키(Foreign Key)를 통해 연결을 구현한다.

개념 모델에서 물리 스키마까지

데이터 모델은 보통 개념적, 논리적, 물리적 설계로 구분해 발전시킨다. 앞 단계에서 업무의 구조를 확인하고, 뒤 단계로 갈수록 DBMS와 저장 구조에 가까운 결정을 내린다.

업무의 핵심을 드러내는 개념 모델

개념 모델에서는 업무 영역의 핵심 엔티티와 관계를 식별한다. 엔티티-관계 다이어그램(ERD)은 비즈니스 요구사항을 사용자와 개발자가 함께 확인하는 도구로 활용할 수 있다.

⤢✕

DBMS와 분리해 다루는 논리 모델

논리 모델은 개념 모델을 특정 DBMS에 종속되지 않는 형태로 구체화한다. 이 단계에서는 정규화를 통해 중복을 줄이고, 속성을 상세화하며, 식별자와 관계 표현 방식을 결정한다.

⤢✕

DBMS 특성을 반영하는 물리 모델

물리 모델에서는 특정 DBMS에 맞춰 스키마를 설계한다. 테이블, 컬럼, 제약조건의 상세 명세를 정하고, 인덱스와 파티션 같은 성능 요소도 함께 검토한다. 데이터 타입, 저장 공간처럼 물리적 특성도 이 단계의 대상이다.

정규화가 다루는 중복과 종속성

정규화는 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위한 방법이다. 정규형을 적용하면서 반복되는 값과 함수적 종속성을 분리한다.

원자값을 갖도록 분리하는 1정규형

1정규형(1NF)은 모든 속성이 원자값(Atomic Value)을 갖도록 한다. 반복 그룹을 제거하며, 여러 전화번호를 하나의 필드에 함께 저장하지 않고 나누는 방식이 예가 된다.

비정규화 상태:

고객(고객ID, 이름, 전화번호(집전화, 모바일))

1정규화 후:

고객(고객ID, 이름, 집전화, 모바일)

부분 함수적 종속성을 제거하는 2정규형

2정규형(2NF)은 1NF를 만족하면서 부분 함수적 종속성을 제거한다. 모든 비주요 속성이 주요 키에 완전 함수적 종속을 가져야 한다.

1NF 상태:

주문상품(주문번호, 상품번호, 상품명, 수량, 가격)

2정규화 후:

주문상품(주문번호, 상품번호, 수량)
상품(상품번호, 상품명, 가격)

이행적 함수 종속성을 없애는 3정규형

3정규형(3NF)은 2NF를 만족하고, 비주요 속성 사이의 이행적 함수 종속성을 제거한다.

2NF 상태:

고객주문(주문번호, 고객번호, 고객명, 배송주소)

3정규화 후:

고객주문(주문번호, 고객번호, 배송주소)
고객(고객번호, 고객명)

보이스-코드 정규형(BCNF)은 3NF를 만족하면서 모든 결정자가 후보키여야 한다. 제4정규형(4NF)은 다치 종속성을, 제5정규형(5NF)은 조인 종속성을 제거한다.

관계 차수가 바꾸는 테이블 구조

1:1 관계는 양쪽 엔티티의 레코드가 각각 하나씩만 연결되는 형태다. 직원과 개인정보가 이에 해당한다.

⤢✕

1:N 관계에서는 한 엔티티의 레코드 하나가 다른 엔티티의 여러 레코드와 연결된다. 부서와 직원처럼 가장 일반적으로 사용하는 관계 유형이다.

⤢✕

N:M 관계는 양쪽 엔티티가 서로 여러 레코드와 연결되는 구조다. 관계형 모델에서는 중간 테이블로 이를 구현하며, 학생과 과목의 관계가 예가 된다.

⤢✕

식별자와 키로 무결성 유지하기

기본키(Primary Key)는 엔티티의 각 인스턴스를 고유하게 식별한다. 중복과 NULL을 허용하지 않으며 변경은 최소화해야 한다. 고객ID와 주문번호가 대표적인 예다.

외래키(Foreign Key)는 다른 엔티티의 기본키를 참조하는 값이다. 관계를 구현하는 핵심 메커니즘이며 참조 무결성 제약조건의 기반이 된다. 주문 테이블의 고객ID가 이에 해당한다.

후보키(Candidate Key)는 기본키가 될 수 있는 키의 집합으로, 유일성과 최소성을 만족해야 한다. 학생 테이블에서는 학번과 주민등록번호가 후보키가 될 수 있다. 후보키 가운데 기본키로 선택되지 않은 키는 대체키(Alternate Key)다.

복합키(Composite Key)는 두 개 이상의 속성으로 만든 키다. 수강신청의 학번과 과목코드 조합이 예다.

모델을 검토하고 표현하는 도구

ERD(Entity-Relationship Diagram)는 엔티티, 속성, 관계를 시각적으로 나타내는 대표적인 모델링 표기법이다. IE 표기법, Barker 표기법 등 여러 표현 방식이 있다.

UML(Unified Modeling Language)은 객체지향 분석과 설계를 위한 표준 언어다. 클래스 다이어그램으로 데이터 모델을 표현할 수 있다.

읽기 성능을 위한 비정규화의 대가

비정규화(Denormalization)는 성능 향상을 위해 정규화 원칙을 의도적으로 완화하는 기법이다. 읽기 작업이 많은 시스템에서는 데이터 중복을 허용해 조인 연산을 줄일 수 있다. 반면 데이터 무결성 위험은 커진다. 주문 테이블에 고객 이름을 중복 저장하는 경우가 예다.

요구사항을 스키마로 옮기는 과정

모델링은 사용자 인터뷰, 업무 프로세스 분석, 기존 문서와 시스템 분석을 통해 요구사항을 파악하는 데서 시작한다. 이후 업무에서 쓰이는 명사형 단어를 추출하고 중요성을 평가해 엔티티를 도출하며, 엔티티 정의서를 작성한다.

엔티티별 속성과 도메인을 정하고 기본키를 선정한 뒤, 엔티티 간 연관성 및 관계 차수(1:1, 1:N, N:M)를 결정한다. 식별 관계와 비식별 관계도 구분한다. 그 다음 단계별 정규화를 진행해 업무 요구사항에 맞는 수준을 정하고, 물리 설계에서 DBMS 특성, 성능 고려 요소, SQL DDL 생성을 반영한다.

운영 요구사항을 설계에 반영하는 기준

확장성을 위해 미래 요구사항 변화를 고려한 유연한 구조가 필요하다. 성능 검토에서는 쿼리 효율성, 적절한 인덱싱, 필요시 비정규화를 함께 다룬다.

데이터 품질은 무결성 제약조건과 유효성 검사 규칙으로 관리한다. 보안 측면에서는 접근 제어와 민감 데이터 처리를 모델링 단계부터 고려해야 한다.

관계형 모델은 데이터 중복을 줄이고 일관성을 유지하기 쉽고, 표준화된 쿼리 언어(SQL)를 사용할 수 있다. 관련 도구와 전문가 풀(pool)이 넓다는 점도 장점이다. 반대로 대용량 데이터 처리에서는 성능 이슈가 생길 수 있으며, 스키마 변경이 어렵고 복잡한 관계 표현에는 한계가 있다. 객체 지향 패러다임과의 불일치(임피던스 불일치)도 고려 대상이다.

온라인 쇼핑몰의 관계 구조

온라인 쇼핑몰에서는 고객, 주문, 주문 항목, 상품, 카테고리의 관계를 다음과 같이 모델링할 수 있다.

⤢✕