본 게시글은 'SQL 전문가 가이드'의 내용을 정리한 것입니다.
https://dataonair.or.kr/db-tech-reference/d-guide/sql/
1. 데이터 모델링의 이해
2. 엔티티
(1) 엔티티의 개념
- 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)
- 업무 활동 상 지속적인 관심을 가지고 있어야 하는 대상
- 인스턴스의 집합이라고도 할 수 있음
- 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)를 가짐
- 주요 특징
- 사람, 장소, 물건, 사건, 개념 등의 명사에 해당
- 업무 상 관리가 필요한 관심사에 해당
- 저장이 되기 위한 어떤 것(Thing)
(2) 엔티티와 인스턴스에 대한 내용과 표기법
- 엔티티-인스턴스 ERD와 엔티티-인스턴스의 예

(3) 엔티티의 특징
- 엔티티의 주요 특징은 다음과 같으며 도출된 엔티티가 다음의 성질을 만족하지 못할 시 적절하지 않은 엔티티일 가능성이 있음
- 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 함
- 유일한 식별자에 의해 식별이 가능해야 함
- 영속적으로 존재하는 인스턴스의 집합이어야 함 (두 개 이상)
- 업무 프로세스에 의해 이용되어야 함
- 반드시 속성이 있어야 함
- 다른 엔티티와 최소 한 개 이상의 관계가 있어야 함
- 업무에서 필요로 하는 정보
- 반드시 시스템을 구축하고자 하는 업무에서 필요로 하고 관리하고자 하는 정보여야 함

- 식별이 가능해야 함
- 식별자(Unique Identifier)에 의해 식별이 가능해야 함. 유일한 식별자는 그 엔티티의 인스턴스만의 고유한 이름

- 인스턴스의 집합
- 영속적으로 존재하는 인스턴스의 <집합>이 되어야 함.

- 업무 프로세스에 의해 이용
- 업무 프로세스가 엔티티를 반드시 이용해야 함

- 속성을 포함
- 속성을 포함하지 않거나 주식별자만 존재하고 일반 속성은 전혀 없는 경우 적절한 엔티티가 아님. 단, 관계 엔티티의 경우 주식별자 속성만 가지고 있어도 엔티티로 인정

- 관계의 존재
- 다른 엔티티와의 관계가 최소 한 개 이상으로 존재해야 함.
단, 관계를 생략하여 표현해야 하는 경우가 존재하며 다음과 같음
- 통계를 위한 엔티티
- 코드를 위한 엔티티
- 시스템 처리 시 내부 필요에 의한 엔티티 (트랜잭션 로그 테이블 등)
(4) 엔티티의 분류
- 유무형에 따른 분류
- 유형 엔티티 (Tangible Entity) : 물리적인 형태가 있고 안정적이며 지속적으로 활용. 업무로부터 엔티티를 구분하기가 용이 (사원, 물품, 강사 등)
- 개념 엔티티 (Conceptual Entity) : 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 것. (조직, 보험상품 등)
- 사건 엔티티 (Event Entity) : 업무를 수행함에 따라 발생되는 것. 비교적 발생량이 많으며 각종 통계 자료에 이용될 수 있음 (주문, 청구, 미납 등)
- 발생 시점에 따른 분류
- 기본(키) 엔티티 (Fundamental Entity, Key Entity) : 그 업무에 원래 존재하는 정보, 다른 엔티티와의 관계에 의해 생성되지 않고 독립적으로 생성, 자신은 타 엔티티의 부모의 역할을 하게 됨. 자신만의 고유 주식별자를 가짐. (사원, 고객, 상품 등)
- 중심 엔티티 (Main Entity) : 기본 엔티티로부터 발생되고 그 업무에 있어서 중심적인 역할을 수행. 데이터의 양이 많이 발생되고 다른 엔티티와의 관계를 통해 많은 행위 엔티티를 생성 (계약, 사고, 청구, 주문 등)
- 행위 엔티티 (Active Entity) : 두 개 이상의 부모 엔티티로부터 발생, 자주 내용이 바뀌거나 데이터량이 증가 (주문 목록, 사원 변경 이력 등)
- 엔티티 분류 방법의 예
(5) 엔티티의 명명
- 가능하면 현업 업무에서 사용하는 용어를 사용
- 가능하면 약어를 사용하지 않음
- 단수명사를 사용
- 엔티티 생성의미대로 이름을 부여