[DB] 데이터 모델링 절차 & ERD 작성

 데이터 모델링

 

데이터 모델링이란?

 

데이터 모델링이란 정보시스템 구축의 대상이 되는 업무 내용을 분석하여 이해하고 약속된 표기법에 의해 표현하는걸 의미한다. 그리고 이렇게 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용된다.

특히 데이터를 추상화한 데이터 모델은 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성할 수 있기 때문에, 데이터 모델링은 데이터베이스 설계의 핵심 과정이기도 하다

 

 

데이터 모델링 절차

 

1. 네이버 게시판의 화면에 어떠한 것들이 필요한지에 대한 개념을 잡는게 업무파악 단계(요구사항 수집 및 분석)
2. 네이버 게시판의 화면에 표현되는 데이터들을 파악해서 관계를 설정하는게 개념적 데이터 모델링
3. 개념적 데이터 모델링을 한 것을 표롤 만드는 게 논리적 데이터 모델링
4. 위 과정을 수행한 것을, 실제 데이터베이스 테이블로 만드는 게 물리적 데이터 모델링

 

---

 

 ERD (Entity Relationship Diagram) 그리기

 

ERD (Entity Relationship Diagram)는 단어에서 의미하는 그대로 'Entity 개체'와 'Relationship 관계'를 중점적으로 표시하는 데이터베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램이다. 개체 관계도라고도 불리며 요구분석사항에서 얻은 엔티티와 속성들의 관계를 그림으로 표현한 것이다.

---

 

ERD 엔티티 표기법

 

 

 

 엔티티 (Entity)

 

• 엔티티는 정의 가능한 사물 또는 개념을 의미한다.
• 사람도 될수 있으며 프로필이나 도서정보와 같은 무형의 정보도 데이터화가 가능하다.
• 데이터베이스의 테이블이 엔티티로 표현된다고 보면 된다.
• 예를 들어 유저 Entity는 아래 그림과 같이 표현된다.

 

 

 엔티티 속성 (Attribute)

 

• 엔티티에는 개체가 갖고있는 속성(Attribute)을 포함한다.
• 예를들어 유저 엔티티라면 유저번호, 이름, 나이, 성별 ..등 속성들이 있다.
• 데이터베이스의 테이블의 각 필드(컬럼)들이 엔티티 속성이라고 보면된다.

 

 

 엔티티 도메인 (Domain)

 

• 도메인은 속성의 값, 타입, 제약사항 등에 대한 갑의 범위를 표현하는 것이다.
• 사용자 기호에 따라 속성 타입만 그릴수도 있고, 가독성을 위해서 생략할 수도 있다.
• 데이터 타입을 명시할때, 데이터베이스가 지원하는 타입에 맞게 해야한다.

 

 

 엔티티 분류

 

• 엔티티는 저장하는 데이터 정보 주제에 따라 종류가 다양하다.
• 고객 정보같은 실제로 물리적인 형태로 있는 정보와 구매 이력같은 무형적이고 개념적인 정보가 있다.
• 이 엔티티 분류 구분을 잘 해주어야 데이터베이스 설계에 있어 각 데이터 주제에 맞게 모델링을 구축할 수 있다.

구분	내용
유형 엔티티	물리적인 형태 (예 : 고객, 상품, 거래처, 학생, 교수 등)
무형 엔티티	물리적인 형태가 없고 개념적으로만 존재하는 엔티티 (예 : 인터넷 장바구니, 부서 조직 등)
문서 엔티티	업무 절차상에서 사용되는 문서나 장부, 전표에 대한 엔티티 (거래명세서, 주문서 등)
이력 엔티티	업무상 반복적으로 이루어지는 행위나 사건의 내용을 일자별, 시간별로 저장하기 위한 엔티티 ( 예 : 입고 이력, 출고 이력, 구매 이력 등)
코드 엔티티	무형 엔티티의 일종으로 각종 코드를 관리하기 위한 엔티티 (예 : 국가코드, 각종 분류 코드)

다음은 위에서 만든 유저 엔티티에 유저별 소속을 표현하는 엔티티를 추가했다. 유저 엔티티는 유형 엔티티에, 유저별 소속 엔티티는 무형 엔티티에 속하게 된다.

---

 

 ERD 키와 제약 조건 표기법

 

주 식별자 (PK)

 

• 데이터베이스 테이블의 Primary Key를 표현
• 중복이 없고 NULL 값이 없는 유일한 값에 지정하는 식별자
• 아래 그림과 같이 ◆ 다이아몬드로 표현하기도 하고 아니면 열쇠로도 표현하기도 한다.
• 주 식별자는 유일한 속성이므로 다른 속성과의 명확한 구분을 위해 구분선을 두기도 한다.

 

 

NOT NULL

 

• 해당 속성에 들어갈 값에 Null 을 비허용한다면, N 혹은 NN을 적는다.
• 만일 Null 허용한다면 N을 적지 않는다.

 

 

외래 식별자 (FK)

 

• 데이터베이스 테이블의 Foreign Key를 표현
• 외래 식별자 역시 key의 일종이라 ERD 엔티티에도 열쇠 아이콘으로 표시한다. (프로그램에 따라 다를 수 있다)
• 외래 식별자를 표시할 때에는 선을 이어주는데 개체와 관계를 따져 표시한다.

 

---

 

 ERD 엔티티 관계 표기법

 

 

각 엔티티 유형들을 만들었으면, 엔티티 끼리 관계가 있는 경우 선을 이어 관계를 맺어야 한다. 엔티티 끼리 관계 선을 그을때 실선으로 그을지 점선으로 그을지 나뉘는데, 두 엔티티 관계에서 부모의 키를 자식에서 PK로 사용하는지 일반 속성으로 사용하지에 따라서 표기가 다르게 된다.

실선으로 그으면 강한 관계를 나타내는 것이며 '식별자 관계'라고 불리우며, 점선으로 그으면 약한 관계를 나타내는 것이며 '비식별자 관계'라고 불리우게 된다.

 

항목	식별자 관계	비식별자 관계
목적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자(PK) 영향	자식 PK의 구성에 포함	자식 일반 속성에 포함
표기법	실선	점선
연결 고려사항	- 반드시 부모엔티티 종속 - 자식 PK 구성에 부모 PK 포함 필요 - 상속 받은 PK 속성을 타 엔티티에 이전 필요	- 약한 종속 관계 - 자식 PK 구성을 독립적으로 구성 - 자식 PK 구성에 부모 PK 부분 필요 - 상속받은 PK 속성을 타 엔티티에 차단 필요 - 부모쪽의 관계참여가 선택관계

 

 

식별자 관계

 

• 실선으로 표현
• 부모 자식 관계에서 자식이 부모의 PK를 FK로 참조해서 자신의 PK로 설정
• 아래 그림에선 자식 엔티티(유저별 소속)가 부모 엔티티(유저)의 유저번호를 자신의 PK로 설정하였다.

 

 

비식별자 관계

 

• 점선으로 표현
• 부모 자식 관계에서 자식이 부모의 PK를 FK로 참조해서 일반 속성으로 사용.
• 아래 그림에선 자식 엔티티(사원정보)가 부모 엔티티(부서정보)의 부서코드를 일반 속성으로 두었다.

 

 

 ERD 관계의 카디널리티

 

관계가 존재하는 두 entity사이에 한 entity에서 다른 entity 몇개의 개체와 대응되는지 제약조건을 표기하기위해 선을 그어 표현한다. 대표적으로 Mapping Cardinality의 종류는 다음과 같다.

 

하지만 ERD 다이어그램에 위와같이 선 들을 막 긋는다면 가독성이 매우 안좋아지고 표가 더러워지기 때문에, 이러한 엔티티간의 1 대 다의 관계를 표기 하기 위해 ERD에서는 선의 끝 모양을 다르게 표시하는 방법을 사용한다.

 

 

One - to - One Cardinality ( 1 : 1 관계 )

• 유저와 신체정보는 1:1로 매칭된다.
• 한명의 유저는 하나의 신체정보를 갖기 때문이다.

 

 

 

One - to - Many ( 1 : N 관계 )

 

• 한명의 유저는 여러개의 취미를 가질 수도 있다.

 

 

 

 

Many - to - Many ( N : N 관계 )

 

• 제품 엔티티 입장에서, TV 제품은 대우 티비, 삼성 티비, 애플 티비 같은 여러 제조업체 제품이 있을 수 있다.
  이는 냉장고나 세탁기도 마찬가지이다. 여러 기업에서 자신 만의 상표를 생산한다.
• 제조업체 엔티티 입장에서, 삼성 제조업체는 세탁기만 생산하는게 아니라 MP3도 같이 생산한다.
  실제로 삼성이나 애플 회사는 가전제품, 스마트폰, 전자기기 등 여러 종류의 제품을 생산한다.
• 따라서 제품과 제조업체 관계는 N 대 N 관계 된다.

 

 

 

 

Many - to - Many 관계 해소

 

• 그런데 두 엔티티가 다 대 다 관계에 있는 경우, 두개의 엔티티만으로는 서로를 표현하는데 부족하다.
• 데이터 모델링에서는 M:N 관계를 완성되지 않은 모델로 간주하여, 두 엔티티의 관계를 1:N, N:1 로 조정하는 작업이 필요하다.
• 따라서 두 엔티티의 관련성을 표현하기 위해서는 중간에 또 다른 엔티티를 필요로 한다. 이 중간 엔티티(업체별 제품)가 두 엔티티의 공유 속성 역할을 하게 된다.
• 이 부분은 데이터 모델링에서 공식 처럼 적용되는 규칙이며, ERD 프로그램에서 M:N을 잡게 된다면 자동으로 아래와 같이 조정 작업이 행해지게 된다.

 

 

 

 ERD 관계의 참여도

 

• 관계선 각 측의 끝자락에 기호를 표시
• '|' 표시가 있는 곳은 반드시 있어야 하는 개체. (필수)
• 'O' 표시가 있다면 없어도 되는 개체. (선택)

 

 

 

관계의 필수 기호

 

• 학번 21003 학생의 취미가 낚시 라는 정보가 있다면, 21003학번의 학생의 정보가 학생 엔티티에 반드시 존재해야 한다. (필수)
• 따라서 학생의 취미 테이블은 모두 학생 테이블에 대응된다.
• 어떤 학생이 어떤 취미를 갖는데 그 학생이 존재하지 않는다면 뭔가 잘못된 것이 된다.
• 이와 같이 어느 한 쪽이 존재하면 다른 쪽도 반드시 존재해야 하는 관계를 필수 관계 기호를 사용한다. 

 

 

 

관계의 선택 기호

 

• 취미를 가진 학생이 있을수도 있고, 취미가 없는 학생이 있을 수도 있다.
• 김철수 학생은 게임이 취미라서, 대응되는 학생의 취미 테이블에 없기 때문에 관계가 없다. (선택)
• 대응 되는 인스턴스가 있을 수도 있고 없을 수도 없을 때 선택 관계 기호를 사용한다.

 

 

 

 ERD 엔티티 관계 표현 총정리

 

 

 

1 : 1 관계 : 부모(SHOP)는 하나의 자식(FOOD)이 있다.

 

1 : N 관계 : 부모(SHOP)는 하나 이상의 자식(FOOD)이 있다.

 

M : N 관계 : 하나 이상의 부모와 하나 이상의 자식이 있다.

 

1 : 1(o) 관계 : 부모는 하나의 자식이 있을 수도 있다. (없을 수도 있다)

 

1 : N(o) 관계 : 부모는 여러개의 자식이 있을 수도 있다. (없을 수도 있다)

 

 

 ERD 연습 예제 - 도서 대여 관리

 

요구 사항

 

사용자 관련 요구 사항

1. 카카오 소셜 로그인을 구현 할 예정이다.
2. 회원 탈퇴 기능이 필요하다.
3. 이름, 닉네임, 전화번호, 성별이 필요하다.

책 관련 요구 사항

1. 사용자가 책 여러 권을 대여할 수 있다.
2. 책은 하나의 카테고리가 있다.
3. 책은 제목, 설명에 대한 정보가 필요하다.
4. 책 소개 페이지에 해시태그가 붙을 수 있고, 책 한 권에 해시태그 여러 개가, 해시태그 하나가 여러 책에 붙을 수 있다.
5. 사용자가 책 설명 페이지에서 책에 좋아요를 누를 수 있다.
6. 책 카테고리 별로 현재 몇 개의 책이 있는지 집계가 필요하다.

알림 관련 요구 사항

1. 알림은 공지 관련 알림, 책 반납 시간 임박 알림, 마케팅 알림이 있을 수 있다.
2. 공지 사항에 대한 알림은 알림 터치 시 해당 공지 사항으로 이동이 되고, 마케팅 알림의 경우 터치 시 해당 마케팅으로 이동이 된다.

 

설계 예시

 

 슈퍼 타입과 서브 타입

 

 

 

 하나의 테이블에 두고 dtype으로 구분

- 이 때 dtype을 테이블로 따로 관리를 하거나 enum으로 관리하는 것은 선택하면 된다.

 

 

 

 테이블 다 나누기

 

 

---

참조
https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8#erd_%EA%B4%80%EA%B3%84%EC%9D%98_%EC%B9%B4%EB%94%94%EB%84%90%EB%A6%AC%ED%8B%B0