논리적 모델링

 

 

거의 1년이 다 되어가는 포스트이지만.. 이전 포스트에서 데이터 모델링 개념에 대해 살펴보았다.

이번 포스트에서는 데이터 모델링 중 "논리적 모델링"을 중점적으로 알아보겠다.

[ SQL 스터디 - 1주차 ] 데이터 모델링의 이해

* 개념적 모델링 

- Entity와 간단한 Relationship만 표현

- Attribute에 대한 내용은 구체화하지 않음 

 

* 논리적 모델링 

- Entity, Relationship 뿐만 하니라 Attribute까지 표현

- PK, FK를 표시함

 

* 물리적 모델링 

- 실제로 데이터베이스를 구축할 수 있을 정도로 자세한 모델

- 각 Attribute에서 사용하는 Data Type, 실제로 저장되는 변수 이름 등의 정보 

 

 

 

 

01 ) 비즈니스 룰

---

데이터 모델링은 Entity, Attribute, Relationship 파악으로부터 시작한다.

이를 위해서는 각 기업(프로젝트)의 비즈니스 룰을 먼저 이해해야 한다.

* 비즈니스 룰
: 특정 조직이 운영되기 위해 따라야 하는 정책, 절차, 원칙들에 대한 간단명료한 설명  
: 개발자가 직접 정의하기 보다는 서비스를 제공하는 회사나 조직의 구성원들이 결정하는 경우가 다수 
: 기획자는 최대한 비즈니스 룰을 간단명료하게 만드는 것이 중요
: 개발자는 이 비즈니스 룰을 정확히 이해하는 것이 중요

 

 

• 유저는 상품을 주문할 수 있다
• 동일한 주문 내역은 한 번의 배달로, 3일 안에 유저가 지정한 배송지에 전달돼야 한다.
  만일 그렇지 못할 시, 유저에게 최대한 빨리 알려줘야 한다.
• 유저는 상품에 대한 평가를 줄 수 있다.
  평가는 두 종류의 데이터 : 1~5 사이 자연수의 별점, 200자 이내 줄 글

 

 

02 ) Entity, Attribute, Relationship 후보 찾기

---

앞서 우리는 비즈니스 룰이란 무엇인지 알아보았다.

비즈니스 룰 예시로부터 Entity, Attribute, Relationship를 찾고, 이를 바탕으로 ERD의 초안을 만들어보자.

아래 3가지는 Entity, Attribute, Relationship 후보를 찾는 규칙이다.

 

• 모든 명사는 Entity 후보이다
• 모든 동사는 Relationship 후보이다
• 하나의 값으로 표현할 수 있는 명사는 Attribute 후보이다

 

 

---

• 유저는 상품을 주문할 수 있다

첫 번째 비즈니스 룰에서는 유저, 상품, 주문 이라는 키워드로부터 ERD를 그릴 수 있다.

 

 

---

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

주문 내역 Entity를 order라고 표현하였음

 

배송지는 명사의 형태일 뿐만 아니라 특정 주문에 대한 내용이기에, 주문 내역 Entity의 Attribute에 해당한다.

그리고 맨 처음에는 order를 Relationship이라고 표시하였지만, 새로운 Entity 후보가 생겼기에 이를 수정한다.

 

 

---

• 유저는 상품에 대한 평가를 줄 수 있다.
  평가는 두 종류의 데이터 : 1~5 사이 자연수의 별점, 200자 이내 줄 글

 

별점, 줄 글은 평가에 관한 내용이기에 이를 평가 Entity의 Atrribute로 만들어준다.

유저는 상품에 대한 평가를 주고, 상품은 유저로부터 평가를 받는 관계이므로, 평가인 review Entity는 user, product Entity와 Relationship이 있다고 표시하면 된다.

 

 

 

 

 

비즈니스 룰에 없더라도 개발자가 알아서 추가해 주어야 하는 부분도 있다.

특정 Entity를 식별하게 하는 id와 같은 Attribute, 연결 관계를 나타내는 Foreign Key와 같은 내용이다.

 

 

 

이렇게 나타낸 ERD는 초안일 뿐 확정적인 모델은 아니다.

Attribute와 Relationship들의 특성에 따라서 모델링이 바뀔 수 있기에, 변경 시 이를 수정해 주어야 한다. 

 

 

 

 

03 ) 여러 값을 갖는 Attribute

---

 

ERD 초안을 만들기 위해 사용했던 규칙 중에서, 아래의 규칙에 대한 예외 경우에 대해 알아보겠다.

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

 

하나의 값으로 표현할 수 있는 명사는 Attribute로 표현한다고 하였지만,

여러 값으로 표현할 수 있는 명사가 존재할 경우에는 새로운 Entity를 만들어 사용해야 한다. 

 

 

user Entity

 

위 user Entity는 3가지의 Attribute를 가지고 있다.

여기서 address Attribute가 하나의 값이 아닌 여러 값으로 표현되어 있다고 가정해보자.

 

사용자가 이사를 갈 때마다 새롭게 address를 추가해야 하는 상황이 생긴다면,

address Attribute는 하나의 값이 아닌 여러 값을 표현하는 명사가 된다.

 

 

만약 여러 값이 존재하는 명사를 새로운 Entity로 분리하지 않고, 하나의 Entity로 표현한다면 3가지 문제가 발생한다. 

1. NULL이 많이 생김
2. 컬럼을 몇 개를 만들어야 하는지가 애매해짐 
3. 조회가 복잡함 

 

따라서 우리는 합쳐져 있던 Entity를 2개의 Entity로 나누고 새로운 관계로 표시해 ERD를 나타낸다. 

즉 address를 Attribute로 사용하지 않고, 새로운 Entity로 만들어 user Entity와 분리하면 된다.

 

 

 

04 ) 카디널리티

---

 

카디널리티란

Entity type A와 B 사이에서 A Entity 한 개가 B Entity 몇 개와 연결 될 수 있고,

B Entity 한 개가 A Entity 몇 개와 연결될 수 있는지를 말한다.

"관계차수" 라는 단어가 카디널리티와 같은 표현이다.

 

Entity 간의 관계는 일대일, 일대다, 다대다로 표현할 수 있으며, 어떤 관계가 있는지에 따라 ERD 모형이 바뀐다.

 

1:1(일대일)관계

 

법적 부부 관계처럼 한 명의 남편이 한 명의 부인만을 가질 수 있고, 한 명의 부인이 한 명의 남편만을 가질 수 있는 관계를 말한다.

 

이를 ERD에서 표현하면 아래와 같다.

이 포스트의 모든 ERD 표기법은 Crow's Foot 표기법으로 나타냅니다.

 

• 관계에서 일(1)에 해당하는 Entity일 때 

 

 

 

1:N(일대다)관계

 

한 명의 유저는 여러 개의 평가를 남길 수 있지만, 하나의 평가는 한 명의 유저에만 속하는 관계를 말한다.

또한 한 명의 교수는 여러 수업을 담당할 수 있지만, 하나의 수업은 한 명의 교수에만 속하는 관계 역시 이에 해당한다.

 

1:N(일대다)관계를 ERD에서 표현하면 아래와 같다.

 

• 관계에서 다수에 해당하는 Entity일 때 

 

 

 

M:N(다대다)관계

 

한 명의 유저가 여러 개의 상품을 찜하기 할 수 있고, 하나의 상품도 여러 명의 유저 사이에서 찜을 당할 수 있는 관계를 말한다.

또한 한 명의 학생은 여러 개의 수업을 수강할 수 있으며, 하나의 수업은 여러 명의 학생들이 수강할 수 있는 관계 역시 이에 해당한다.

 

M:N(다대다)관계를 ERD에서 표현하면 아래와 같다.

 

 

 

 

 cf ) 최소 카디널리티

 

어떠한 관계에서는 하나의 Entity가 존재하지 않더라도 표현이 되는 것이 존재할 수 있다.

 

앞서 1:N관계는 한 명의 유저는 여러 개의 평가를 남길 수 있지만, 하나의 평가는 한 명의 유저에만 속하는 관계라고 하였다.

만일 유저가 아무런 평가를 남기지 않았다면, 한 유저에 대해서 하나의 평가가 없어도 된다.

반면 평가는 꼭 하나의 유저가 존재해야 하는데, 이를 최소 카디널리티 라고 말한다.

 

최소 카디널리티는 최대 카디널리티보다 선 안쪽에 표시한다.

한 관계에서 한 개도 없어도 되는 Entity면, 0을 의미하는 동그라미를 표시하고

적어도 한 개가 꼭 있어야만 하는 Entity면, 1을 의미하는 수직선을 사용한다. 

 

• 관계에서 하나도 없어도 되는 Entity일 때 

• 관계에서 적어도 하나는 있어야 하는 Entity일 때 

 

 

 

 

 

 

 

 

---

카디널리티는 어떠한 Entity를 사용하는지 보다는 Entity를 어떻게 사용하는지에 포인트를 두고있다.

두 Entity 간에 나올 수 있는 16가지 경우에 대한 내용을 아래 링크에 첨부해 두었다. 궁금하다면 참고하길 바란다.

관계에 대한 카디널리티(Cardinality)가 총 16가지라고 하셨는데요?

 

또한 비즈니스 룰에 따라서 카디널리티가 달라지기에, 카디널리티에서도 비즈니스 룰 파악은 매우 중요하다.

 

 

 

 

---

이 포스트는 코드잇 "데이터베이스 모델링"의 논리적 모델링 강의를 바탕으로 작성한 글입니다.

https://www.codeit.kr/topics/database-modeling-and-normalization?version=1

데이터베이스 모델링 - SQL 강의 | 코드잇