모델링 기본 정리

이번 포스팅은 모델링 기본기를 정리하려고 합니다 :)

해당 글은 코드잇에서 실습한 내용을 토대로 정리한 글입니다.

 

모델링의 시작은 Entity, Attribute, Relationship을 파악하는 것입니다. 바로 비즈니스 룰(사업 규칙)을 이용하면 쉽게 알 수 있습니다. 다같이 더 자세하게 알아볼까요.

 

1. 비즈니스 룰

"특정 조직이 운영되기 위해 따라야 하는 정책, 절차, 원칙에 대한 간단명료한 설명" - Coronel

 

예를 들어 온라인 쇼핑몰, 고공 쇼핑몰's 의 비즈니스 룰을 살펴봅시다. 쇼핑몰 사이트를 운영할 때 아래와 같은 정책들을 살펴볼 수 있습니다.

 

고공의 쇼핑몰's 비즈니스 룰

- 고객은 상품을 주문할 수 있다. 하나의 주문에는 최대 10개의 상품까지만 가능하다.

- 동일한 주문 내역은 한 번의 배달로, 3일 안에 유저가 지정한 배송지에 전달되어야 한다. 만약 그렇지 못할 시, 고객에게 최대한 빨리 알려줘야 한다.

- 유저는 상품에 대한 평가를 줄 수 있다. 평가는 두 종류의 데이터: 1-5 사이 자연수의 별점, 그리고 고객에게 받은 200자 이내 줄 글을 통해 할 수 있다.

 

위의 세가지보다 더 많은 비즈니스룰을 설정할 수 있습니다. 이렇게 웹사이트면 페이지에서 제공하는 모든 기능에 관한 규칙을 말하는 것입니다. 비지니스를 룰은 데이터 모델링의 핵심 기반이 되기 때문에 이 룰을 만든 기획자는 최대한 간단명료하게, 개발자는 만들어진 비즈니스 룰을 정확하게 이해하는 게 중요합니다.

 

 

2. Entity, Relationship, Attribute 후보 찾기

비즈니스 룰이 있을 때, Entity, Relationship, Attribute를 찾는 가장 기본적인 원칙에 대해 알아봅시다.

 

1. 모든 명사는 Entity 후보이다.

2. 모든 동사는 Relationship 후보이다.

3. 하나의 '값'으로 표현할 수 있는 명사는 Attribute 후보이다.

 

이 세 가지 기본 원칙을 통해 비즈니스 룰에서 ERM 초안을 만들어냅니다. 고공 쇼핑몰의 비즈니스 룰이 있을때, 다음과 같은 ERM을 만들 수 있습니다.

ERM

만약 비즈니스 룰이 구체적이지 않거나 누락되어있으면 당연히 모델링을 할 때 문제가 생길 수밖에 없을 것입니다. 그렇기에 비즈니스 룰은 항상 간단명료하면서도 필요한 내용을 모두 담고 있어야합니다. 이렇게 만들어진 ERM은 초안이 될 수 있지만 확정적인 모델은 아닙니다. 왜냐하면 Attribute와 Relationship 특성에 따라 달라지기 때문이죠.

 

3. Attribute 후보 찾기 예외 경우

제가 위에서 Attribute와 Relationship 특성에 따라 달라진다는 말을 좀더 다뤄보겠습니다. 바로 세 번째 원칙인 "하나의 값으로 표현할 수 있는 명사는 Attribute 후보이다."의 예외 경우입니다. 하나의 값으로 표현할 수 있더라도 하나의 Entity가 여러 개의 값을 가져야하는 경우입니다. 테이블로 표현한 것을 보면서 조금 더 이해를 해보겠습니다.

 

user 테이블

 

한 고객이 여러 개의 주소를 가질 수 있기 때문에 주소에 해당하는 컬럼 또는 attribute가 여러 개로 나눠졌습니다.

 

이렇게 모델링을 하게 되면 3가지의 문제점을 찾아볼 수 있습니다.

 

1. NULL이 많이 생길 수 있게 된다.

2. 컬럼을 몇 개 만들어야 하는지 애매하다.

3. 조회가 비효율적이다.

 

그렇기 때문에 다음과 같이 주소를 컬럼이 아니라 새로운 테이블, Entity를 만들게 되는 것입니다. 

새로운 user 테이블과 address 테이블

이를 ERM으로 다시 나타내보면,

이렇게 기존의 ERM을 다음과 같이 두 개로 나누고 그 사이에 선을 추가해서 표현할 수 있습니다.

 

 

짧은 글 읽어주셔서 감사합니다 :)