ERD, 어떻게 설계하는 걸까?

🧐 What is ERD?

우선, ERD가 무엇인지 부터 짚고 넘어가자.

• ERD란 Entity Relationship Diagram의 약어로, 데이터베이스 구조를 한눈에 알아보기 위해서 쓰인다.
• DB를 개발하기 전에 보다 많은 아이디어를 도출하고, 데이터베이스 설계의 이해를 높이기 위해 데이터 모델링을 실시한다.
• 쿼리문을 작성할 때 테이블들이 구조화된 다이어그램을 보면서 도움을 받을 수 있다.
• 데이터의 다양한 특징을 확인할 수 있어 요구사항을 그에 맞게 개발할 수 있다.

 

 

ERD의 핵심은 세 가지 이다. "Entity" 와 "Relationship", 그리고 "Attribute"이다. 각 용어가 무엇을 의미하는지 살펴보자.

 

#Entity(개체)

• Entity는 관리하고자 하는 정보의 실체이며, 사람, 객체 혹은 개념이라고 이해하면 된다.
• 데이터베이스를 설계할때, 쉽게는 테이블이 Entity로 정의될 수 있다.
• 모든 Entity는 하나 이상의 식별자 (UID)를 지녀야 하며, UID가 없다면 Entity라고 할 수 없다.
• Weak Entity
  • 개체가 가진 속성들로는 개체를 고유하게 정의할 수 없는 개체를 의미한다. 예를 들어, 각 교육과정에 분반이 있다고 했을때, 분반이라는 개체는 자신을 정의하는 key가 없고, 각 교육과정에 의존하게 된다. 
  • 1203 이라는 강의가 존재하고, 001, 002, 003..분반이 있다고 했을때, 이 분반 이름은 따로 특징이 없고 다른 강의와도 겹칠 수 있다. 이를 단독으로 존재할 수 없고, 다른 개체에 의존해야 하는 Weak Entity라고 한다.

#Attribute (속성)

• Attribute는 Entity를 구성하고 있는 구성 요소이다.
• 데이터 타입을 반드시 같이 명시해줘야 한다.
• Key Attribute
  • 다른 객체들과 중복되지 않는 고유한 값을 가진 Attribute로, 객체를 식별하는 데 사용된다.
• Composite Attribute
  • 독립적인 Attribute들이 모여서 생성된 Attribute를 의미한다.
  • 예를 들어 OO시,OO동,OO아파트 등의 독립적인 Attribute 네개가 모여서 생성된 주소 Attribute는 복합 attribute라고 할 수 있다.
• Multi-Valued Attribute
  
  • 하나의 Attribute가 여러개의 값을 가지는 Attribute를 의미한다.
  • 예를 들어 하나의 영상물에 로맨스, SF, 호러 등의 여러가지 장르가 공통적으로 존재할 수 있다.
• Derived Attribute
  • 이는 다른 Attribute가 갖고 있는 값으로부터 유도된 속성을 의미한다.
  • 예를 들어 모든 상품의 총 가격을 나타내는 total이라는 속성은 상품의 가격 attribute, 상품의 개수 attribute를 곱해서 계산된 값이다. 이는 Derived Attribute이 된다.

 

#Relationship

• Entity간의 관계를 의미한다.
• 두 Entity간에 선을 긋고, 관계 명칭을 기록하게 된다.
• 선택 사항을 표시한다.
  • 점선은 선택적인 사항을 의미한다.
    • 예를 들어, 사원과 부서 Entity가 있을때 부서 입장에서는 사원을 배치 받을수도, 받지 않을 수도 있다.
  • 실선은 필수적인 사항을 의미한다.
    • 사원 입장에서는 부서가 필수적으로 배정받아야 한다.
• 관계 형태를 표시한다.
  • 삼지창 모양은 하나 이상을 의미한다.
  • 단선은 하나를 의미한다.
    • 부서는 여러명의 사원을 가질 수 있으나, 사원은 하나의 부서에만 배치된다.

 

#관계 형태(Cardinality)

당연하게도, 각 Entity들이 가지고 있는 관계에는 여러가지 형태가 존재한다.

 

1) 1:1 관계 

  : 양쪽 모두 단 하나씩 존재하는 경우이다. 예를 들면, 어떤 상점에는 하나의 주소만이 존재한다.

2) 1:N 관계

 : 일대다/다대일 관계는 하나의 원소가 두개 이상의 원소와 관계를 맺는 것을 의미한다. 한 부서에는 여러명의 사원이 소속되어 있다.

-> 이를 관계 모델로 바꿀 때 따로 relationship의 table을 만들지 않고, "Many"쪽에 있는 entity에 "one"쪽의 primary key를 Attribute로 추가하게 된다. 쉽게는 사원의 정보에 부서 번호를 추가한다고 생각하면 된다.

 

 

3) N:M 관계

: 다대다 관계라고 하며, 양쪽 모두 하나 이상과 연관될 수 있다. 예를 들어 하나의 수업에는 여러명의 학생이 있을 수 있고, 한 명의 학생이 여러 개의 수업을 들을 수 있다.

-> 이러한 경우에는, M:N 관계를 M:1 관계로 분할한다. 관계를 맺는 두 entity의 primary key를 가져와 하나의 relation을 생성한다. 즉, 수강신청이라는 테이블을 하나 더 만들어 학생은 자신이 수강신청하는 수업에만 관계를 맺고 있으면 된다.

 

 

#ERD 설계 과정

필자가 넷플릭스를 관찰하며 설계한 ERD 모델이다.

• Entity와  Attribute 추출
  • 넷플릭스를 예시로 들어보도록 하겠다.
  • Entity의 예시로는 영상물, 유저, 회차정보, 배우, 국가, 특징, 장르, 언어.. 이 있겠다.
  • 각 Entity를 추출한 다음에는 Entity에 맞는 Attribute를 추출했다. 필자같은 경우에는 엑셀 파일을 이용해 필요해보이는 데이터를 쭉 적어내려갔다.

Entity와 속성 추출의 예시

• 개체들간의 관계 추출
  • 1: N 관계를 갖고 있는 관계 (너무 많아서 예시만 간단하게 들겠다.)
    • video-epsiode, video-actor, video-genre, video-characteristic, video-ratinglist,video-wishlist, video-watchedlist, video-DownloadedList..
    • 이 경우에는 Many 쪽의 테이블에 one의 Primary key를 FK로 추가해주었다.
  • N: M 관계를 갖고 있는 관계 : 이 경우에는 relation을 따로 만들어 주었다. 이 관계는 추후 관계 모델링에서 따로 테이블이 된다.
    • 영상물-출연자 : 한 영상에 여러명의 출연자가 출연할 수 있고, 한 출연자가 여러가지 영상물에 출연 할 수 있다. → Casting 
    • 영상물- 장르 → Video_Genre 
    • 영상물 - 영상물의 특성 → Video_Characteristic 
    • 영상물 - 유저 : Watched , Wish, Downloaded (이미 시청한 영상, 찜한 영상, 다운로드받은 영상)

• 각 개체의 속성들의 데이터 타입(int, varchar...)이 어떻게 될지 판단하고, ERD를 작성한다.
• Key 제약 조건과, 무결성 제약 조건 등을 추가해준다.​

 

💡보통 개념적 모델링- 논리적 모델링은 다른 개념이다. 그렇지만 보통의 ERD를 설계할 때는 테이블을 세세하게 설계하면서 하기 때문에 ER 다이어그램부터 그려가면서 하기보다는 한꺼번에 테이블로 설계하고, 관계를 파악해가면서 테이블을 추가하거나 키/무결성 제약 조건을 추가하는 등 개념적 모델링과 논리적 모델링을 한번에 하는 것처럼 보인다.