# 문제점
DB를 연동하기 위해 테이블 스키마를 구성하는 경우에도 변경을 최소화하고 확장이 가능한 스키마 구조로 구성하기 위해서, 그리고 스키마에 의존하지 않는 형태로 애플리케이션의 엔티티 객체를 구성하기 위한 고민을 필요로 했습니다.
# 해결방안
데이터 모델링
데이터를 모델링한다는 것은 데이터를 이해하고 유형화, 구조화하는 과정을 의미합니다. 하지만 복잡한 현실 업무의 속성과 규칙을 모델로 정형화하기 위해선 비즈니스 문제 영역의 데이터를 관찰해 그 안에 존재하는 유형과 관계를 찾아야 합니다. 즉, ERD와 같이 데이터를 형상화하기 위해선 문제 영역을 자연스럽게 일정한 크기의 덩어리로 나누게 되는데, 이 과정에서 범주화와 추상화라는 개념이 필요합니다.
- 범주화
- 유사한 것들을 일정하게 묶는 프로세스
- 업무에 필요한 데이터를 성격이 유사한 것끼리 모아놓는 과정
- 추상화
- 문제 영역에서 가장 핵심적인 특성만을 추리는 과정
- 어떤 관점을 기준으로 관심이 없고 복잡한 특성은 걷어내고, 핵심만을 간추리는 행위이며 그 과정에서 유사한 것들은 하나의 집합으로 파악하는 것을 의미
결국 데이터 모델링이라는 것은 어떤 개체가 속하는 범주를 규명하고 개체 집합을 분리해 묶는 수준을 고민하는 과정을 의미합니다.
엔티티는 업무의 기준이 되는 사뮬과 정보를 성격이 유사한 것끼리 모아놓은 집합으로 데이터 모델링을 통해 얻는 결정체라고 볼 수 있습니다.
제가 프로젝트에서 제품에 대해서 데이터 모델링을 통해 얻은 엔티티는 다음과 같습니다.
하지만 데이터 모델링을 통해 엔티티를 생성했다고 끝나는 것이 아닙니다. 데이터가 실제로 2차원 테이블 형태로 저장되기 위해서 어떻게 담아야 최적인지 고민하는 과정을 거쳐야 했습니다. 그 과정 속에선 정규화, 서브타입, 변경 가능성에 대해 고민해봤습니다.
1. 정규화
정규화란 속성들의 종속성을 분석해서 하나의 종속성이 하나의 표(릴레이션)로 관리되도록 분해해가는 과정을 의미합니다.
- 제 1 정규형
- 모든 속성이 값을 반드시 하나만 가져야 한다.
- 제 2 정규형
- 모든 속성이 반드시 주 식별자 전부에 종속되어야 한다.
- 제 3 정규형
- 주 식별자가 아닌 모든 속성이 상호 종속 관계여서는 안 된다.
그 외 정규형 종류
- BCNF : 결정자 중 후보키가 아닌 것들은 제거
- 제4 정규형 : 다치 종속 제거
- 제5 정규형 : 조인 종속성 제거
즉, 위와 같은 정규형을 고려해 하나 이상의 종속성을 가져 제대로 된 모델링이 안 되어있는 지점을 찾아 작은 엔티티로 구분해 결함도를 낮추는 작업을 정규화라고 합니다.
데이터 모델의 확장성과 유연성을 확보하기 위해선 제 1 정규형을 고려해 테이블을 구분해 줄 필요가 있습니다. 데이터 모델의 유연성은 변화를 최소화하면서 업무 요건이나 신규 업무를 빠르고 정확하게 반영할 수 있는 성질을 의미합니다.
데이터 모델 유연성의 핵심은 데이터를 속성 수준이 아닌 행 수준으로 저장해야 합니다. 즉 테이블에 컬럼을 추가하는 것이 아니라 새로은 인스턴스를 추가함으로써 업무 변경 사항을 적용하도록 해야 합니다.
그래서 제 1 정규화를 통해 두개 이상의 값을 가질 수 있는 컬럼을 다른 테이블로 구분해 저장하면서 새로운 값에 대한 저장 소요가 발생할 경우, 값만 추가되도록 구성해야 합니다.
제가 작성한 ERD에서 이와 같은 문제가 발생할 수 있는 부분은 Product에서 image 컬럼이였습니다. 하나의 Product에 대해서 이미지 링크는 하나 이상이 존재할 수 있고 이를 다른 테이블로 구분지으면서 이미지 사진 추가에 대한 변경 소요가 데이터 모델의 구조 변화없이 값만 추가하면서 대응이 가능하도록 변경했습니다.
2. 서브타입
서브타입은 데이터 모델링 과정에서 분류를 통해 결과로 얻는 유형을 의미합니다. 즉, 전체와 부분을 명시적으로 구분해 표현하는 방식입니다.
서브타입을 구분하는 이유는 대상의 본질을 분류하여 그 본질을 보다 쉽게 이해하기 윔입니다. 분명한 기준을 가지고 복잡한 대상을 분류함으로써 그 대상을 구성하는 요소들의 미묘한 동질성이나 차이점을 이해할 수 있게 됩니다.
서브타입을 나누는 여러 패턴 중 하나로는 계층이 존재하는 경우가 있습니다.
이러한 서브타입 개념을 Product 테이블에 적용시켜본다면 Category와 Brand에 대한 속성은 하나의 상품을 분류하기 위한 서브타입으로 구분해볼 수 있었습니다.
3. 변경 가능성
추가로 하나의 엔티티와 관련된 여러 속성을 하나의 테이블에서만 관리한다면 속성값에 대한 변경 소요가 발생했을 때 개체 전체가 새로 생성되게 됩니다. 이러한 현상을 방지하기 위해선 변경 소요 가능성이 높은 속성들에 대해선 분리를 시켜주는 것이 합리적이라는 판단을 했습니다.
그래서 Product 테이블에서 size에 대한 값을 담는 속성들은 size_info라는 테이블로 분리시켜 연관관계를 지정해 관리하도록 구성했습니다.
# 마치며
이처럼 데이터 모델링에 대한 깊을 고민을 통해 실제로 데이터가 저장되는 테이블 구조가 어떻게 설계되어야 하는지, 그리고 그러한 데이터 모델링은 어떠한 과정을 거쳐서 완성되는 지 경험할 수 있었습니다.
# 참고자료
- http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968482212
- https://nirsa.tistory.com/107