14장. 데이터 모델링 - Real MySQL

공부하게 된 이유

데이터 모델링은 항상 개발 일정에 쫓겨 급하게 컬럼을 추가하거나 하나의 테이블에 모든 정보를 담아왔다. 하지만 DBMS 사용에 가장 중요한 부분이기 때문에 해당 챕터를 읽게 되었다.

 

들어가기 전에

서비스 개발 과정 중 데이터베이스 관련 부분을 단계별로 나누면 크게 2가지가 있다.

1. 논리 모델 : 서비스에 어떤 것들이 필요할지 분석하고 그의 집합 간의 관계에 대한 정의
2. 물리 모델 : 시스템으로 어떻게 표현할지 고려하는 것

논리 모델링

모델 정규화

정규화하면 항상 어렵게 생각했는데, 개념을 살펴보기 전에 해당 테이블을 살펴보자! 다음 모델을 보면 어떤 생각이 드는가?

• "우편번호와 주소" : 한 attribute에 2가지의 정보가 들어있다. attribute를 분리하자
• "친구회원들의 회원번호" : 한 attribute에 여러 개의 정보를 담고 있기 때문에 문제가 있다.
• "주문상품번호" : 회원 엔티티와 상관없는 정보이므로 제거해야 한다.

정규화를 그럼 왜 해야 될까?

• 정규화를 통해 데이터의 중복을 최소화함으로써 저장 비용 최소화
• 데이터를 효과적으로 읽어올 수 있게

제1정규화 ( No Repeating Group )

• "친구회원들의 회원번호"는 한명 이상의 친구들 정보를 갖게 되므로, 1정규화를 위반한 것이다. 

 

• "집주소"와 "회사주소" 같은 성격의 어트리뷰트가 반복되고 있다.

물론, 집주소와 회사주소 외 다른 주소가 더 생기지 않을 수도 있지만, 항상 유지 보수와 기능 추가에 대한 대비를 하여야 한다. 그리고 또 다른 이유도 있다! 일단 먼저 정규화를 진행해보자.

아래와 같이 자식 엔티티로 분리할 수 있다.

정규화하지 않은 테이블에서 주소를 검색해야 되는경우

SELECT * FROM 회원 WHERE 자택주소="..." OR 회사주소="..."

하지만 1정규화를 하면 OR 연결한 쿼리보다 훨씬 효율적이고 빠르게 처리가 된다.

SELECT * FROM 회원 WHERE 주소="..."

제 2정규화 ( Whole Key Dependent )

" 식별자 일부에 종속되는 어트리뷰트는 제거해야 한다" 라는 검증 규칙이다.

 

친구 엔티티에 친구회원명이라는 애트리뷰트가 있다면? 이는 친구회원번호에만 종속 관계를 가지고, 회원번호와는 종속관계를 가지지 않는다. 즉, 이 어트리뷰트를 제거해야 한다.

 

친구 회원명은 회원 엔티티로 이동해야 한다.

 

제 3 정규화 ( Non-Key Independent )

" 식별자 이외의 속성간에 종속 관계가 존재하면 안된다" 라는 검증 규칙이다.

 

아래 회원 엔티티를 보면 직업 코드가 직업명을 관리하고 있다. 직업명과 직업코드는 회원번호에 종속적이므로 제2정규화를 위반하고 있지는 않다. 다만, 직업명은 직업코드에 의존하고 있다. 즉, 별도의 직업이라는 엔티티도 분리를 해야 한다.

 

물리 모델링