[24] ERD(Entity Relationship Diagram)

프로젝트를 구현하기 전 미리 설계해야 할 부분이 두 가지 있다면, 

1. ERD 설계

2. API 설계 

일 것이다. 지난 번에 Restful한 API 에 대한 글을 정리했으므로 오늘은 ERD를 정리해 보려 한다.

RESTful API 설계 가이드 (참고 자료)

 

---

1. ERD

① ERD (Entity Relationship Diagram)

• 개체-관계 모델. 테이블간의 관계를 설명해주는 다이어그램이다.
• 프로젝트에서 사용되는 DB의 구조를 한눈에 파악할 수 있다. 즉, API를 효율적으로 뽑아내기 위한 모델 구조도라고 생각하면 된다.
• DB를 개발하기 전에 보다 많은 아이디어를 도출하고, 데이터베이스 설계의 이해를 높이기 위해 데이터 모델링을 실시한다.
• 쿼리문을 작성할 때 테이블들이 구조화된 다이어그램을 보면서 도움을 받을 수 있다.
• 데이터의 다양한 특징을 확인할 수 있어 요구사항을 그에 맞게 개발할 수 있다.

 

② ERD의 Notation

 

 

• 기본 요소는 Entity, Attribute, Relationship 
• 확장하여 Weak Entity, Multivalued Attribute, Weak Relationship 이 있다.

     

Entity

• Entity는 관리하고자 하는 정보의 실체이며, 사람, 객체 혹은 개념이라고 이해하면 된다.
• 데이터베이스를 설계할때, 쉽게는 테이블이 Entity로 정의될 수 있다.
• 모든 Entity는 하나 이상의 식별자 (UID)를 지녀야 하며, UID가 없다면 Entity라고 할 수 없다.
• 존재하는 다른 Entity에 의존적인 Entity를 Weak Entity라고 한다.

 

 

Attribute

• Attribute는 Entity를 구성하고 있는 구성 요소이다.
• 데이터 타입을 반드시 같이 명시해줘야 한다.

• Key Attribute : 다른 객체들과 중복되지 않는 고유한 값을 가진 Attribute로, 객체를 식별하는 데 사용된다.
• Composite Attribute : 독립적인 Attribute들이 모여서 생성된 Attribute를 의미한다.
• Multi-Valued Attribute : 하나의 Attribute가 여러개의 값을 가지는 Attribute를 의미한다.
• Derived Attribute : 이는 다른 Attribute가 갖고 있는 값으로부터 유도된 속성을 의미한다.

 

Relationship

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

 

Cadinality and Ordinality

• Entity들 간의 관계에 대한 추가 정보
• One to many, many to many 관계를 나타낼 수 있음
  

  

여러 기호들로 관계를 표현할 수 있으나, 기호들만 숙지하여도 충분히 표현이 가능하다.

 

 

 

2. ERD 설계 사이트

https://www.erdcloud.com/

ERDCloud

 

위의 링크에서 구현할 코드의 ERD를 만들 수 있다.

아래 다이아그램은 이번 주특기 심화주차 레벨2 ERD를 설계한 모델인데, 확실히 ERD를 통해 직관적으로 테이블의 연관관계를 파악할 수 있다.

 

 

 

 

3. IntelliJ 에서 작성한 ERD 확인 하는법

 

 

• 위와 같이 Show Entity Relationship Diagram 을 클릭하면 아래와 같이 작성한 코드의 테이블 관계를 확인 할 수 있다.

 

 

4. [DATABASE] 식별과 비식별 관계

• 기본키(PK) :  테이블의 하나의 행의 여러 정보들 중 이를 식별해 낼 수 있는 정보
• 외래키(FK) : 테이블간의 관계(참조하는 테이블과 참조되는 테이블 간의 관계)를 나타내는 정보
• 외래키를 사용하여 참조하고 참조되는 두 테이블간의 관계에 따라 식별관계와 비식별관계로 나눌 수 있다.

 

식별관계 : 식별관계는 실선으로 나타내 준다.

• 상품과 주문의 다대다 관계의 두 테이블이 있다. 상품 테이블에서는 상품번호가 기본키이고 주문테이블은 주문번호가 기본키이다.
• 상품과 주문테이블 사이에 주문_상품 테이블을 만들어 일대다 관계로 연결하면 아래와 같다.
• 상품테이블과 주문테이블의 기본키인 상품번호와 주문번호가 주문상품 테이블의 외래키가 되었다.
• 그리고 이 두 외래키는 주문상품테이블의 정보를 식별할 수 있는 기본키(2개이상의 컬럼도 기본키로 구성될 수 있다.)의 역할도 하게된다. 이러한 관계를 식별관계라고한다.

 

식별관계에 대해 정리를 해보자면

• 부모테이블(상품, 주문테이블) 기본키(PK)가 자식 테이블(주문_상품)의 외래키이자 기본키로 사용되는 관계이다.
• 자식 테이블의 행(정보)를 추가할 때 부모테이블의 참조 행(상품번호 또는 주문번호)이 없다면 자식테이블의 행을 추가 할 수 없다.
  : 주문_상품테이블은 상품번호와 주문번호 중 하나라도 없다면 기본키를 만들 수 없게 되고(두개의 외래키가 합쳐 기본키가 되므로) 기본키가 없어 정보를 식별할 수 없으므로 데이터를 넣을 수 없다.
  : 예를 들면 게시판의 작성글과 댓글의 관계를 식별관계라고 할 수 있다.(작성글이 없다면 댓글도 없다)

 

비식별관계 : 비식별관계는 점선으로 표시한다.

 

• 부모 테이블을 참조한 테이블에서 참조된 외래키가 기본키가 아닌 일반속성(컬럼)으로 참조되었을 때를 말한다.
• 위의 그림의 주문_상품테이블에 정보를 식별할 수 있는 기본키를 추가하면 다음과 같다.
• 주문상품번호라는 기본키를 추가하였다. 주문상품번호로 주문_상품테이블의 정보들을 식별할 수 있게 되고 외래키(상품번호와 주문번호)는 테이블의 일반속성이 되었다.

 

 

비식별관계에 대해 정리하면

• 부모 테이블(상품, 주문테이블) 기본키가 자식 테이블(주문_상품테이블)의 일반컬럼이나 외래키(Foreign Key) 컬럼에 저장되는 관계이다.
• 자식 테이블의 행(정보)를 추가할 때 부모테이블의 참조 행(상품번호 또는 주문번호)이 없어도 자식테이블의 행을 추가 할 수가 있다.
  : 예를 들면 회사의 부서와 사원의 관계를 비식별관계라고 할 수 있다. (사원이 부서가 배정되지 않을 수도 있으므로)

여기서 하나 참고할 부분에 대해 말하자면 위의 그림에서 비식별관계는 주문상품번호라는 기본키를 임의로 추가하여 만들었다. 이렇게 추가한 키를 인조키라고 하는데 기본키를 인조키로 설정하는 것이 권장된다.
이유는 식별관계를 나타내는 그림에서 보면 상품번호와 주문번호 두개의 키가 주문상품테이블의 기본키로 되어있다. 기본키는 최대한 변하지 않는 값이어야하는데 어떤이유에서 상품번호 또는 주문번호가 변경이 된다던지 사용을 할 수 없게 된다면 데이터 구조를 다시 만들어야하는 경우가 발생하기 때문이다.

 

---

[참고 자료]

• https://mslilsunshine.tistory.com/164
• https://velog.io/@kjhxxxx/DataBase-ERD%EB%9E%80
• https://velog.io/@jch9537/DATABASE-%EC%8B%9D%EB%B3%84%EA%B3%BC-%EB%B9%84%EC%8B%9D%EB%B3%84-%EA%B4%80%EA%B3%84