[16일차] 50일 포트폴리오 챌린지

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://bit.ly/43z0P6S 

패스트캠퍼스 [직장인 실무교육]

---

---

ERD (ER 다이어그램)

ERD(Entity Relationship Diagram)

• 엔티티와 이들 간의 관계를 알기 쉽게 약속된 도형을 이용하여 일목요연하게 그림으로 표현한 것이다.
• ER모델의 구성요소는 엔티티(Entity), 관계(Relationship), 속성(Attribute) 을 기본으로 하여 관계 수, 식별자, 서브타입 등으로 세분화 할 수 있다.
• 문장 형식의 업무 처리 규정을 약속된 도형 형태로 나타내어 전체 업무 및 데이터의 구조를 쉽게 파악할 수 있다.
• 문장으로 기술하지 않고 공통적인 약속을 통해 표현함으로써 업무의 파악과 이해가 용이하다.
• 데이터베이스를 구현할 때 정규화(Normalization)된 테이블을 만들기 위한 근거 자료로 활용한다.

엔티티(Entity)

• 의미 있는 유용한 정보를 제공하기 위하여 기록‧관리하고자 하는 데이터의 유형으로 사람, 사물, 장소, 개념 또는 사건 등을 표현한다.
• 현업에서 관리하고자 하는 데이터를 엔티티라고 하며, 특징을 표현하기 위한 하나 이상의 속성이 있어야한다.

관계(Relationship)

• 엔티티 간 존재하는 업무의 상호연관성으로 해당 엔티티와 관련된 업무가 수행되는 규칙을 의미한다.
• 업무가 변경됨에 따라 관계는 변할 수 있다.
• 두 엔티티 사이의 관계에 따라 1:N, 1:1, M:M 관계 등으로 분류한다.

속성(Attribute)

• 엔티티와 관계의 성질을 나타내는 쪼갤 수 없는 정보의 단위이다.
• 엔티티에 저장되는 개체 집합의 특성을 설명하는 항목이다.
• 식별자와 설명자로 구분할 수 있다.

논리적(logical) ERD vs 물리적(physical) ERD

논리(logical) ERD

• 설계단계에서 엔티티와 엔티티타입, 관계를 정의한다.
• 어떠한 정보를 객체화할 것인가에 대한 규정이다. 한글이든 영문이든 중요하지 않다.

물리(physical) ERD

• 실제 DBMS에 생성될 테이블이 설계된다. (ex: many to many 관계에서 도출되는 table, super-sub 관계에서 도출되는 table)
• 이 외에도 관계에 대한 정의(캐스캐이드 등), 인덱스, 컬럼별 데이터타입 및 제약조건 등의 속성 정의하며 정규화를 실시한다.
• 결과적으로 모델링의 각종 이슈를 반영한 ERD를 기반으로 데이터베이스가 생성되면, 이를 보통 설계가 끝났다고 표현한다.

ERD 표기 방법

• ERD 관계 표현법

• 1 : 1 (식별 관계)
  • 주민(person)과 주소(detail_address)간 관계를 표현한 ERD이다.
  • 주소 테이블은 person_id를 기본키(primary key)로 설정하고, person_id를 통해 person 테이블을 참조한다.
  • 한 명의 주민은 한 개의 주소를 가진다.
  • 주소는 주민 id가 없다면 존재 할 수 없다. (식별 관계)
  • 주민 부모테이블이고, 주소는 자식테이블인 관계이다.
  • 부모테이블의 id를 저장하는 테이블은 자식이 되고, 데이터를 제공하는 테이블은 부모가 된다.

• 1 : N (참조 필수)
  • 부서(department)와 회사원(employee)간 관계를 표현한 ERD이다.
  • 회사원은 한 개의 부서에 반드시 소속되어야 한다.
  • 한 개의 부서에 여러 회사원이 소속 될 수 있다.

• 1 : N (참조 Null 허용)
  • 부서(department)와 회사원(employee)간 관계를 표현한 ERD이다.
  • 회사원이 꼭 부서에 소속될 필요는 없다.
  • 한 개의 부서에 여러 회사원이 소속 될 수 있다.
  • 한 개의 부서에 소속된 회사원이 한 명도 없을 수 있다.

• 비식별관계와 식별관계
  • 비식별 관계 : 기본키에 외래키가 포함되어 있지 않다
  • 식별 관계 : 기본키에 외래키가 포함되어 있다

비식별 관계

식별 관계