[SQLD 준비 #3] 데이터모델링의 이해_1장(2) 엔티티/속성/관계

ERD(Entity-Relationship Diagram)

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

• 데이터베이스 설계 단계 중 개념적 모델링 단계에서 ERD를 작성한다.
• ER Model을 도식화하여 표현하는 방법이 ERD이다.
• 현재 가장 인기가 많은 RDB 테이블 구조로 사상하기 쉬워 자주 사용된다.

ERD 표기법

: ERD 표기법에는 Peter-Chen 표기법(엔티티-직사각형, 속성-타원형, 릴레이션-마름모로 표현), 까마귀 발 표기법, IE 표기법과 Baker 표기법이 존재한다. (실무에서는 IE 표기법을 많이 사용한다.)

엔티티

• 위 그림과 같이 직사각형으로 엔티티를 표기한다.
• 약한 엔티티는 모서리가 둥근 직사각형으로 표기한다.

속성

• Entity 이름 하단 좌측에 PK, FK 등의 정보를 표기하고, 우측에는 속성 이름을 표기한다.

❉ 원으로 표현되기도 한다.

관계

1. 식별 관계
   : 부모 테이블의 기본키나 유니크키를 자식 테이블이 기본 키로 사용하는 경우 식별 관계라 한다.

• 부모 테이블에 무조건 데이터가 하나 이상 존재해야 자식 테이블 데이터가 생성될 수 있다.
• 즉 자식 데이터가 있으면 적어도 부모 데이터가 하나 이상 존재하며, 부모 테이블에 자식 테이블이 종속된다.
• ERD에서 실선으로 표기한다.
  ex. 학생 ⟷ 성적

2. 비식별 관계
   : 부모 테이블의 기본키나 유니크키를 자식 테이블이 외래 키로 사용하는 경우 비식별 관계라 한다.

• 자식 데이터는 부모 데이터가 없어도 독립적으로 생성될 수 있다.
• 부모와의 의존성이 상대적으로 적어 조금 더 자유롭게 데이터 생성과 수정이 가능하다.
• ERD에서 점선으로 표기한다.
  ex. 학생 ⟷ 과목

3. 전체 참여 관계

• 두 개의 실선으로 표현한다.

4. 부분 참여 관계

• 한 개의 실선으로 표현한다.

❉ 마름모로 표현되기도 한다.

Mapping Cardinality(사상 원소수)

: 특정 엔티티가 다른 엔티티와 관계를 맺을 때 해당 관계를 설명하기 위해 나오는 개념이다.

1. 1:1 관계
   : 대통령과 국가의 관계는 1:1이라 볼 수 있다.

2. 1:N, N:1 관계
   : 학생과 학급의 관계를 보자. 한 학생은 하나의 학급에만 속할 수 있고 하나의 학급은 여러 학생을 포함할 수 있다. 따라서 학생과 학급의 Mapping Cardinality는 N:1이라 할 수 있다.

3. N:M 관계
   : 드라마와 배우 사이의 관계를 떠올려보면 쉽다. 한 배우는 여러 드라마에 나올 수 있고, 한 드라마는 여러 배우를 포함할 수 있다. 따라서 1:1 관계로도 1:N 관계로도 나타낼 수 없는 이런 관계를 N:M 관계라 한다.

ERD 작성 순서

1. 엔티티 그리기
2. 엔티티를 적절하게 배치하기
3. 엔티티 간 관계 설정하기
4. 관계명 기술하기(❉ 관계 명칭은 관계 표현에 있어 매우 중요한 부분에 해당됨)
5. 관계의 참여도 기술하기
6. 관계의 필수여부 기술하기

엔티티

엔티티 분류

분류 기준1. 유무형에 따른 엔티티

1. 유형 엔티티
   : 물리적 형태가 있고 안정적이며 지속적으로 활용되는 엔티티이다.
   ex. 사원/강사/물품/···

2. 개념 엔티티
   : 물리적 형태가 있는 것이 아니라 관리해야 할 개념적 정보가 존재하는 엔티티이다.
   ex. 조직/보험 상품/···

3. 사건 엔티티
   : 업무를 수행함에 따라 발생하는 엔티티로, 발생량이 상대적으로 많으며 각종 통계자료에 이용될 수 있다.
   ex. 주문/청구/미납/···

분류 기준2. 발생 시점에 따른 엔티티

1. 기본 엔티티 = 키 엔티티
   : 업무에 원래 존재하는 정보로서 다른 엔티티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능하다. 기본 엔티티는 타 엔티티의 부모 역할을 한다. 또한, 다른 엔티티로부터 주식별자를 상속받지 않고 고유한 주식별자를 가진다.
   ex. 사원/부서/고객/상품/자재/···

2. 중심 엔티티 = 메인 엔티티
   : 기본 엔티티로부터 발생되고 업무에 있어서 중심적인 역할을 한다. 많은 데이터가 발생되고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다.
   ex. 계약/사고/주문/청구/매출/···

3. 행위 엔티티
   : 두 개 이상의 부모 엔티티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다. 분석 초기 단계보다는 상세 설계 단계나 프로세스와 상관 모델링을 진행하며 도출될 수 있다.
   ex. 사원 변경 이력/주문 목록/···

엔티티 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
  ex. 환자/토익 응시 횟수/···
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다.
• 2개 이상의 인스턴스와 2개 이상의 속성이 존재해야 한다. (소위, 면적으로 표현되어야 한다.)
• 엔티티는 업무 프로세스에 의해 이용되어야 한다.
• 엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다.
• 단, 공통코드/통계성 엔티티는 관계를 생략할 수 있다.
• 속성을 포함해야 한다.

엔티티 명명 규칙

1. 가능하면 현업 업무에서 사용하는 용어 사용하기
2. 가능하면 약어 사용하지 않기
3. 단수 명사 사용
4. 모든 엔티티에서 유일한 이름 부여하기
5. 엔티티가 생성되는 의미대로 이름을 자연스럽게 부여하기

속성

: 속성은 업무에서 필요로 하는 인스턴스에서 관리하고자 하는, 의미상 더 이상 분리되지 않는 최소의 데이터 단위를 부르는 말이다.

특징

• 한 개의 엔터티는 2개 이상의 인스턴스 집합이다.
• 한 개의 엔터티는 2개 이상의 속성을 가진다.
• 한 개의 속성은 1개의 속성값을 가진다. (여러 개의 속성값 X)
• 속성도 집합이다.
• 엔티티에 대한 자세하고 구체적인 정보를 나타낸다.

엔티티 구성 방식에 따른 분류

1. PK 속성
   : 엔티티를 식별할 수 있는 속성이다.
2. FK 속성
   : 다른 엔티티와의 관계에서 포함된 속성이다.
3. 일반 속성
   : 엔티티에 포함되어 있지만 PK, FK 속성이 아닌 속성이다.

속성의 특성에 따른 분류

속성은 업무분석을 통해 바로 정의한 기본 속성, 원래 업무상 존재하지 않았지만 설계하면서 도출해낸 설계 속성, 다른 속성으로부터 계산되거나 변형되어 생성되는 파생 속성 3가지로 분류할 수 있다.

1. 기본 속성
   : 업무로부터 추출한 모든 일반적인 속성
2. 설계 속성
   : 업무를 규칙화하기 위해 새로 만들거나 변형/정의하는 속성 (ex. 일련 번호/코드성 속성)
3. 파생 속성
   : 다른 속성에 영향을 받아 생성되는 속성으로 보통 다른 속성으로부터 계산된 값들이 이에 해당한다. 데이터 정합성 유지를 위해 유의할 점이 많으면 가급적 파생 속성은 적을수록 좋다. (ex. 합)

도메인

: 속성에 대한 데이터 타입, 크기, 제약사항 지정

속성 명명 규칙

• 해당 업무에서 사용하는 이름 부여하기
• 서술식 속성명은 금지
• 약어 사용 금지
• 구체적으로 명명해 데이터 모델에서 유일성 확보하기

관계

: 엔티티나 인스턴스 간 논리적인 연관성
ex. 선생님 - 가르친다(관계) - 학생

페어링

: 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것

UML(통합모델링언어)에서의 관계

1. 연관관계(실선)
   : 항상 이용하는 관계 (ex. 소속된다.)
2. 의존관계(점선)
   : 상대 행위에 의해 발생하는 관계 (ex. 주문한다.)

관계선택성(관계선택사양)

1. 필수 관계
   : 엔티티가 관계에 항상 참여하면 필수 관계이다.
2. 선택 관계
   : 엔티티가 관계에 선택적으로 참여하면(참여할 수도 있고 아닐 수도 있으면) 선택 관계이다.

관계 체크사항

: 2개의 엔티티 사이에서 관계를 정의할 때 다음 규칙을 체크해본다.

1. 2개의 엔터티 사이에 관심있는 연관 규칙이 존재하는가?
2. 2개의 엔터티 사이에 정보의 조합이 발생되는가?
3. 업무기술서, 장표에 관계연결에 대한 규칙 서술되어 있는가?
4. 업무기술서, 장표에 관계연결을 가능케 하는 동사가 있는가?

식별/비식별 관계 장단점

1. 식별 관계 장점

• 데이터 정합성 유지를 DB에서 한 번 더 할 수 있음
• 자식 테이블에 데이터가 존재하면 무조건 부모 테이블에 데이터가 존재함을 보장할 수 있음

2. 식별 관계 단점

• 요구사항이 변경되었을 때 구조 변경이 필요한 경우 이 과정이 어려움

3. 비식별 관계 장점

• 변경되는 요구사항들을 유동적으로 수용할 수 있음
• 부모 데이터와 독립적인 자식 데이터를 생성할 수 있음

4. 비식별 관계 단점

• 데이터 정합성을 지키기 위한 별도의 비즈니스 로직이 필요함
• 자식 데이터가 존재해도 부모 데이터가 존재하지 않을 수 있음
• 데이터 무결성을 보장하지 않음

참여 제약조건(Participant Constraint)

관계를 맺는 두 엔티티에 대해 한 엔티티가 다른 엔티티에 의존하는지 여부를 나타내는 제약 조건이다.

1. 전체 참여 관계
   : 전체 개체가 참여하는 관계이다.
   ex1. (교수 → 학과 : 전체 참여) 교수와 학과 엔티티는 '소속'이라는 관계가 있는데, 이 관계에 대해 모든 교수는 소속 학과가 있어야 한다는 전제 하에 교수는 학과에 전체 참여하는 관계를 가진다.
   ex2. (과목 → 학생 : 전체 참여) 과목은 무조건 학생을 가지고 있어야 한다.
2. 부분 참여 관계
   : 일부 개체만 참여하는 관계이다.
   ex1. (학생 → 과목 : 부분 참여) 휴학생은 아무런 과목을 수강하지 않는다.

존재 존속(existence dependence)

: A가 반드시 있어야만 B가 존재할때 B는 A의 존재 존속이라고 합니다.

• A를 주 개체, B를 종속 개체라 한다.