DB ERD 다이어그램

🟨 목 차 🟨

1. 데이터 모델링

      1-1. 데이터 모델링 순서

             1-1-1. 요구사항 분석

             1-1-2. 개념적 데이터 모델링

             1-1-3. 논리적 데이터 모델링

             1-1-4. 물리적 데이터 모델링

             1-1-5. 데이터 모델링 순서 간단 요약

 

2. ER 다이어그램

      2-1. ERD구성 요소 표기법[Entity]

             2-1-1. Entity Attribute

             2-1-2. Entity 분류

      2-2. ERD 구성 요소 표기법 - 키(Key)와 제약조건

             2-2-1. ERD 구성 요소 표기법 - Primary Key(기본키)

             2-2-2. ERD 구성 요소 표기법 - NOT NULL

             2-2-3. ERD 구성 요소 표기법 - Foregin Key(외래키)

      2-3. ERD 구성 요소 표기법 - 선 긋기[두 개체의 관계 -점선 / 실선]

      2-4. ERD 구성 요소 표기법 - 선 모양[두 개체의 관계 - 선의 끝 모양]

             2-4-1. ERD 구성 요소 표기법 - One-to-one Cardinality(1:1관계)

             2-4-2. ERD 구성 요소 표기법 - One-to-Many Cardinality(1:N관계)

             2-4-3. ERD 구성 요소 표기법 - Many-to-Many Cardinality(M:N관계)

      2-5. ERD 구성 요소 표기법 - 선택 기호

      2-6. ERD 구성 요소 표기법 - 두 개체의 관계 총정리

 

3. ERD 예제 - 도서 관리 시스템 

 

4. 효율적인 모델링 작업하기

 

 

 

 

 

저번 시간에는 데이터베이스에 저장되어 있는 레코드를 유일하게 구별할 수 있는 식별자인 KEY 에 대해서 알아보았습니다.

이번 시간에는 ER 다이어그램을 알기 위한 사전지식(데이터 모델링), ER 다이어그램 에 대해 알아보도록 하겠습니다. :)

---

 

◼️ 1. 데이터 모델링 ◼️

데이터 모델링이란 정보시스템 구축의 대상이 되는 업무 내용을 데이터 흐름을 도식화 하는 과정이다.

분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터 관리에 사용되는, 데이터베이스 설계의 핵심 과정이다.

[ 데이터를 추상화한 데이터 모델은 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL 문장을 기능과 성능적인 측면에서 효율적으로 작성하기 위해 꼭 알아야 한다. ]

---

 

◼️ 1-1. 데이터 모델링 순서

---

◼️ 1-1-1. 요구사항 분석

요구사항 분석을 제대로 하지 못했는데, 정확한 모델링을 할 수 없을 것이다.

요구사항 분석은 어떠한 업무를 시작하기 전에, 해당하는 업무에 대해서 요구사항을 파악하는 단계이다.

요구사항을 파악하기 좋은 방법으로 궁극적으로 만들어야 하는 것이 무엇인지 심도있게 알아봐야 한다.

 

[간단 정리]

• 하려고 하는 일을 의뢰인과 개발자가 잘 협력해서 알아내는 과정.
• 원하는 기능이 무엇인가?
• 산출물 : 요구사항 분석서

내 글에서 내가 참고한 블로그님의 예시 게시판을 예를 들며 설명을 하겠다.(감사합니다 블로그님...)

 

---

◼️ 1-1-2. 개념적 데이터 모델링

개념적 데이터 모델링은 내가 하고자 하는 일의 데이터 간의 관계를 구상하는 단계이다.

개념적 데이터 모델은 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델일을 수행한다.

주요 하는 것들을 말하자면 핵심 엔터티와 그들간의 관계를 발견하고, 그것을 표현하기 위해 엔터티-관계다이어그램(ER 다이어그램)을 생성하는 것이다.

즉, 간단하게 말해서 데이터베이스 ERD 다이어그램 테이블 표를 그리기전에 간단하게 도형으로 만들어보는 개념적 데이터 모델링 이라고 이해하면 쉽다.

그리는 방법으로는 도형이 의미하는 바를 알고 화살표를 통해 관계를 표현하면 된다.

다음은 게시판에 필요한 정보에 대한 것을 데이터베이스 구상을 개념적 데이터 모델링으로 구현해본 것이다.

위의 사진을 보게 되면 간단한 게시판을 만들려고 해도 크게 테이블 기준으로 나눈다면 회원 정보, 로그인 정보, 게시글, 댓글 정도가 있고 이들과 서로 데이터를 물려받는 경우도 생긴다. 즉, 서로들 간의 관계가 생긴다. 이런것들을 대략적으로 간략히 알아볼 수 있는 단계라고 생각하면 된다.

 

[간단 정리]

• 하고자 하는 일의 개념들과 그 개념들 사이의 관계를 밝힌다.
• 서로들 간의 관계를 대략적으로 간략히 알아 볼 수 있는 단계
• 산출물 : ER 다이어그램(ERD)

---

◼️ 1-1-3. 논리적 데이터 모델링

엔터티 중심의 상위 수준의 엔터티 중심의 모델이 완성되면, 구체화된 업무중심의 데이터 모델을 만들어 내는데 이것을 논리적인 데이터 모델링 이라고 한다.

논리적 데이터 모델링 단계에서 업무에 대한 Key, 속성, 테이블과의 관계 등 을 표시하며, 정규화 활동을 수행한다.

[ 정규화란 데이터 모델의 일관성을 확보하고 중복을 제거하여 신뢰성 있는 데이터 구조를 얻는데 목적 ]

 

위에서 구현한 개념적 E-R 다이어그램을 테이블 형태로 재구성한다.

[ 추상적인 데이터에서 보다 구체적인 데이터로 작성한다.]

예를 들어 회원정보의 필드인 아이디, 비밀번호에 각 데이터 타입을 명시해주고 각 데이터간의 관계를 정밀하게 맺어주며 테이블의 키(Key)를 지정해준다. [ 테이블 키에 대한 설명 참고 : https://bj-turtle.tistory.com/43 ]

[간단 정리]

• 관계형 데이터 베이스에 맞는 표로 개념들을 전환한다.
• 산출물 : ER다이어그램을 바탕으로 한 관계형 데이터 모델(개념적 데이터 모델링에서 만든 ER다이어그램을 통해 구체적 관계 설정을 한 ER다이어그램이라고 생각하면 편하다.)

---

◼️ 1-1-4. 물리적 데이터 모델링

물리적 데이터 모델링은 최종적으로 데이터를 관리할 데이터 베이스를 선택하고, 선택한 데이터 베이스에 실제 테이블을 만드는 작업이다.

시각적인 구조를 만들었으면 그것을 실제로 SQL 코딩을 통해 완성하는 단계라고 보면 된다.

애플리케이션의 설계나 업무 요건이 명확해지는 단계

무엇보다 도메인의 선언이 중요하며 도메인 규칙에 대한 충실한 준수는 물리 데이터 모델 내에서 유지하는 데이터를 고품질로 유지할 수 있는 필수 조건이 될 것이다.

[간단정리]

• 어떤 데이터베이스 제품을 사용할지 선택
• 데이터베이스 제품에 최적화된 코드를 작성, 실제 표를 만든다
• 산출물 : 표를 생성할 수 있는 SQL 코드(구체적인 데이터, 즉 논리적 데이터 모델링에서 만든 ER다이어그램을 통해 구체적인 데이터 타입, 도메인 규칙 등등을 설정하여 만드는 과정이라 생각하면 편하다.)

---

◼️ 1-1-5. 데이터 모델링 순서 간단하게 요약

1. 네이버 게시판의 화면에 어떠한 것들이 필요한지에 대한 개념을 잡는게 요구사항 분석 단계
2. 네이버 게시판의 화면에 표현되는 데이터들을 파악해서 관계를 설정하는게 개념적 데이터 모델링(ER다이어그램)
3. 개념적 데이터 모델링 한 것을 표로 만드는 게 논리적 데이터 모델링(개념적 데이터 모델링에서 만든 ER다이어그램을 통해 관계 설정을 한 ER다이어그램)
4. 이 일련의 과정을 수행한 것을, 실제 데이터베이스에 만드는 게 물리적 데이터 모델링(구체적인 데이터, 즉 논리적 데이터 모델링에서 만든 ER다이어그램을 통해 구체적인 데이터 타입, 도메인 규칙 등등을 설정하여 만드는 과정)

---

◼️ 2. ER 다이어그램 ◼️

◼️ 2-1. ERD구성 요소 표기법[Entity]

Entity는 정의 가능한 사물 또는 개념을 의미한다.

사람이나, 객체 혹은 개념이나 이벤트 등을 Entity로 둘 수 있다.

데이터베이스를 설계할 때, '테이블'이 Entity로 정의 될 수 있다.

---

◼️ 2-1-1. Entity Attribute

각각의 Entity에는 속성(Attribute)을 포함하고 있다. 필드(컬럼)명을 쓰면 된다.

예를 들어 Entity가 사람이라면 나이, 이름, 생년월일 등 속성들을 포함 할 수 있다.

RDBMS가 지원하는 데이터 타입에 맞게 해야한다.

 

*용어

• 엔터티(Entity) : 업무에 필요, 데이터를 저장 및 관리하는 테이블을 의미
• 속성(Attribute) : 엔터티의 한 부분으로서 업무에 필요하고 최소값의 단위를 의미. 필드(컬럼)명이라고 이해하면 된다.
• 도메인(Domain) : 속성의 값, 타입, 제약사항 등에 대한 갑의 범위를 표현.

---

◼️ 2-1-2. Entity 분류

Entity도 저장하는 데이터 정보 주제에 따라 종류가 구분된다.

이러한 Entity 분류 구분을 잘 해줘야 정규화 및 데이터베이스 설계에 있어 굉장히 도움이 된다.

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

---

◼️ 2-2. ERD 구성 요소 표기법 - 키(Key)와 제약조건

제약조건은 데이터베이스 데이터의 정확성을 유지하기 위한 목적으로 사용되며 테이블에 저장할 데이터를 제약하는 특수한 규칙을 의미한다.

[ 일단 ERD에 키와 제약조건을 표시하기 전에 테이블 제약 조건과 데이터베이스 키(Key)에 대해 공부하고 오자.]

==> 테이블 제약조건 : https://bj-turtle.tistory.com/42    데이터베이스 키(Key) : https://bj-turtle.tistory.com/43

My SQL 테이블 제약 조건 feat.Workbench

DB Key의 종류

---

◼️ 2-2-1. ERD 구성 요소 표기법 - Primary Key(기본키)

• 중복이 없고 NULL 값이 없는 유일한 값에 지정하는 키
• 보통 대부분의 ERD 다이어그램 툴에서 열쇠 표시로 나타낸다.

◼️ 2-2-2. ERD 구성 요소 표기법 - NOT NULL

• MySQL Workbench 기준 Null을 허용하면 흰색 마름모, Null을 허용하지 않으면 파란색 마름모로 표기한다.

◼️ 2-2-3. ERD 구성 요소 표기법 - Foregin Key(외래키)

• Foreign key를 표시할 때에는 선을 사용하는데, 개체와 관계를 따져 표시한다.
• 외래키 역시 key의 일종이라 ERD 엔티티에도 열쇠 아이콘으로 표시한다. 다만 PK와 구분하기 위해서 색깔을 다르게 하는 편이다.
  [ MySQL Workbench 기준 부모 테이블은 노란색 열쇠, 자식 테이블은 빨간색 열쇠로 표시 된다. ]
• 다만 ERD만 보고 어떤 FK가 어떤 테이블을 참조하는지 보기 어렵기 때문에 보통 외래키 이름을 테이블명_필드명 이린식으로 지어서 구성하는 편이다. (아래 사진에는 information 테이블과 관계를 맺었으니까 information_phone로 외래키명을 명명)

---

◼️ 2-3. ERD 구성 요소 표기법 - 선 긋기[두 개체의 관계 -점선 / 실선]

두 관계중 부모의 키를 PK(기본키)로 받는지 안받는지에 따라서 점선 실선 표기가 다르게 된다.

• 실선 : 식별 관계
  [ 부모 테이블의 기본키나 유니크 키를 자식 테이블이 자신의 기본키로 이용 ]
  장점 : 데이터의 정합성 유지를 DB에서 검증
  단점 : 구조 변경이 어렵다.
  
  
• 점선 : 비식별 관계
  [ 부모 테이블의 기본 키나 유니크 키를 자식 테이블이 자신의 기본키,유니크키를 제외한 다른 키(외래키)로 이용 ]
  장점 : 구조 변경이 자유롭다, 부모 데이터로부터 독립
  단점 : 데이터 정합성을 위한 로직 필요, 데이터 무결성 보장 하지 않는다.

자식 : store / 부모 : address

---

◼️ 2-4. ERD 구성 요소 표기법 - 선 모양[두 개체의 관계 - 선의 끝 모양]

관계가 존재하는 두 entity사이에 한 entity에서 다른 entity 몇 개의 개체와 대응되는지 제약조건을 표기하기 위해 선을 그어 표현한다.

ERD 에서는 선의 끝 모양을 보고 entity 간 몇 개체와 대응되는지 확인 가능하다.

 

Mapping Cardinality[대응] 의 종류

• One to one : 1 대 1 대응
• One to many : 1 대 다 대응
• Many to one : 다 대 1 대응
• Many to many : 다 대 다 대응

[ *Cardinality란 한 개체에서 발생할 수 있는 발생 횟수를 정의하며, 다른 개체에서 발생할 수 있는 발생 횟수와 연관됨 ]

 

위에서 보이는 사진을 설명을 하면 ER 다이어그램에 관계를 나타낸 것인데, 여기서 관계를 위해 선들을 막 그었다.

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

---

◼️ 2-4-1. ERD 구성 요소 표기법 - One-to-one Cardinality(1:1관계)

ex) 학생과 신체정보는 1:1 관계로 매칭된다. 왜냐하면 학생 한명이 하나의 신체정보를 갖기 때문이다.

---

◼️ 2-4-2. ERD 구성 요소 표기법 - One-to-Many Cardinality(1:N관계)

ex) 한명의 학생은 여러개의 취미를 가질수도 있다.

---

◼️ 2-4-3. ERD 구성 요소 표기법 - Many-to-Many Cardinality(M:N관계)

ex) 예를 들어 TV라는 제품은 LG티비, 삼성티비, 애플티비 같은 여러 제조업체 제품이 있을 수 있다.

냉장고나 세탁기도 마찬가지이며, 여러 기업에서 자신만의 상표를 생산한다.

또한 삼성 제조업체는 세탁기만 생산하는게 아니라 MP3도 같이 생산한다.

실제로 삼성은 티비, 스마트폰, 전자기기 등 여러개를 생산한다.

==> 위의 사진을 보게되면 다대다 관계에 있는 경우 두 개의 테이블(엔티디)로만 두 테이블이 관련이 있다는 정보를 나타내기 어렵다. 

즉, 다대다 관계에 있는 경우 관련성을 표현하기 위해서 중간에 또 다른 엔티티를 필요로 한다.

그래서 데이터 모델링에서 M:N관계는 완성되지 않는 모델로 간주되어 M:N관계를 1:N 관계로 전환시켜주는 작업을 필요로 한다.

위의 사진은 M:N관계가 완성되지 않은 모델로서 1:N 관계로 전환시켜주는 작업이다.

---

◼️ 2-5. ERD 구성 요소 표기법 - 선택 기호

• 'I' 표시가 있는 곳은 반드시 있어야 하는 개체 [ 필수 ]
• 'O' 표시가 있다면 없어도 되는 개체 [ 선택 ]

[ex]

김철수 학생은 게임이 취미라서, 취미 테이블에 없기 때문에 관계가 없다. (선택)

 

어떤 학생이 어떤 취미를 갖는데, 그 학생이 존재하지 않는다며 뭔가  잘못된 것이다.

학번 21003 학생의 취미는 낚시라는 정보가 있다면 21003학번의 학생의 정보가 학생 엔티디에 반드시 존재해야 한다. 이와 같이 어느 한 쪽이 존재하면 다른 쪽도 반드시 존재해야 하는 관계를 필수 관계라고 한다. (필수)

취미를 선택적으로 갖는 학생 테이블

관련된 학생 정보를 필수적으로 갖는 학생의 취미 정보 테이블

---

◼️ 2-6. ERD 구성 요소 표기법 - 두 개체의 관계 총정리

 

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

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

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

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

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

---

◼️ 3. ERD 예제 - 도서 관리 시스템 ◼️

[회원 ↔ 대여]

• 회원번호PK가 대여 테이블에서 FK로 일반속성으로 쓰이고 있다. ( 점선 )
• 회원은 대여를 여러개 할 수 있다. ( 1:N )
• 아예 대여하지 않은 회원이 있을 수 있다. ( 1:N(선택) )
• 대여를 할땐 반드시 회원 정보가 필수로 존재해야한다. ( 1[필수]:N[선택] )

[도서 ↔ 대여]

• 도서번호PK가 대여 테이블에서 FK로 일반속성으로 쓰이고 있다. ( 점선 )
• 도서가 과거에 여러번 대여된 기록이 있을 수 있다. ( 1:N )
• 아예 대여하지 않은 도서가 있을 수 있다. ( 1:N[선택] )
• 대여를 할땐 반드시 도서 정보가 필수로 존재해야한다. ( 1[필수]:N[선택] )

[회원 ↔ 예약]

• 회원번호PK가 예약 테이블에서 FK이자 PK로 쓰이고 있다. ( 실선 )
• 회원은 예약을 여러개 할 수 있다. ( 1:N )
• 아예 예약하지 않은 회원이 있을 수 있다. ( 1:N[선택] )
• 예약을 할땐 반드시 회원 정보가 필수로 존재해야한다. ( 1[필수]:N[선택] )

[도서 정보 ↔ 도서]

• ISBN(국제표준도서번호)테이블의 PK가 도서 테이블에서 FK(외래키)로 일반속성으로 쓰이고 있다. ( 점선 )
• 같은 책이 여러개 있을 수 있다. 도서정보가 같은 도서가 여러개 있을 수 있다. ( 1:N )
• 유실된 책이 있을수 있다. 도서정보는 무형의 정보일 뿐이고, 도서 엔티티는 실제 물리적 엔티티이다. ( 1:N[선택] )
• 도서는 반드시 도서 정보가 필수로 존재해야한다. ( 1[필수]:N[선택] )

[도서 ↔ 예약]

• 도서번호 PK(기본키)가 예약 테이블에서 FK이자 PK(기본키가 외래키로)로 쓰이고 있다. ( 실선 )
• 하나의 도서에 여러개 예약이 걸려 있을수 있다. ( 1:N )
• 예약이 없는 도서가 있을 수 있다. ( 1:N[선택] )
• 예약 정보에는 반드시 도서 정보가 들어 있어야 한다. ( 1[필수]:N[선택] )

---

◼️ 4. 효율적인 모델링 작업하기 ◼️

위에서 예제로 든 도서 관리 시스템에서 도서 Entity에 관해서 말하자면, 도서관의 같은 책(책 이름이 같음)이 있다는 가정하에 모델링을 했음에도 불구하고, 이것은 효율적으로 하지 못한 모델링이였다.

 

왜냐하면 도서번호로 같은 책이 있더라도 번호를 달리해 구분은 가능할 지 몰라도, 똑같은 자료를 중복하게되는 구조여서 결과적으로 데이터공간을 낭비하는 결과를 초래하기 때문이다.

 

다시 말하면 도서관의 실제도서를 나타내는 Entity와 실제도서의 속성을 정의하는 Entity를 구분해야된다는 말이다.

왜냐하면, 도서번호만 다른 똑같은 책인 속성 정보가 완전히 같기 때문이다.

[ 이와 같은 형태들은 한 데이터들은 데이터 중복으로 저장됨을 아래 사진으로 알 수 있다. ]

 

즉, 따라서 속성정보를 중복해서 한 테이블에 저장하는 것보다, 테이블을 따로 분리해서 속성을 따로 저장하는것이 데이터공간을 절약 할 수 있는 방법이다.

==> 이러한 분담 행위를 정규화라고 한다.

[ 정규화에 대해 공부하고 싶다면 아래 링크를 클릭해주세요. ]

DB 정규화

 

---

 

 

 

참고 

---

[DB] 📚 데이터 모델링 개념 및 📈 ERD 다이어그램 그리는법 (1:N 관계)