[SQLD] 엔티티와 속성 (Entity / Attribute)

●  스키마
- 3층 스키마

외부 Schema
개념 Schema
내부 Schema

- 3층 스키마 구조

● 엔티티 (Entity)
- 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 (Thing)
- 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서
   그 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합

 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당
 엔터티는 업무상 관리가 필요한 관심사에 해당
 엔터티는 저장이 되기 위한 어떤 것(Thing)이다.

→ 눈에 보이지 않는 개념들도 엔터티이다.

(엔터티-인스턴스 예)
과목-수학
과목-영어
강사-최민
강사-이민호
=> 엔터티는 인스턴스의 집합이다

- IE 표기법
-Barker 표기법

- 특징
1. 반드시 해당 업무에 필요하고 관리하고자 하는 정보이어야 한다. (ex. 환자, 토익 응시 횟수 등)
 * 업무에서 관리하조가 하는 영역(Business Boundary)에 대한 인식이 매우 중요함 
  (환자라는 엔터티는 병원시스템에 필요하지 인사시스템에 필요하진 않음)
2. 유일한 식별자에 의해 식별 가능해야 한다.
 * 식별자(Unique Identifier)에 의해 식별 가능해야 함
 * 유일 식별자: 해당 엔터티 인스턴스만의 고유한 이름
 * 두 개 이상의 엔터티를 대변하면 잘못된 설계이다.
  ( 환자라는 엔터티에서 식별자로 이름은 동명이인이 발생할 수 있으므로 유일 식별자가 아님,
    하지만 고유 환자번호는 올바른 식별자임)
3. 영속적으로 존재하는 인스턴스의 집합이어야 한다. 
 * '한 개'가 아니라 '두 개' 이상의 집합
 * 하나의 엔티티는 여러 개의 인스턴스를 포함 한다.
4. 업무 프로세스에 의해 이용되어야 한다.
 * 반드시 필요한 엔터티로 선정 하였는데 업무 프로세스에 의해 이용되지 않는다면 잘못 선정된 케이스임
5. 반드시 속성이 있어야 한다.
 * 속성(Attribute) = 데이터베이스의 각 컬럼에 해당하는 값 (Class로 따지면 맴버변수
업무에 필요로하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
 * 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우
   관계가 생략되어 있거나 업무 분석이 미진하여 속성 정보가 누락된 경우
 * 주 식별자만 존재하고 일반 속성은 전혀 없는 경우도 올바르지 않은 케이스
 * (관계 엔터티;Associative Entity) 주 식별자 속성만 가지고 있어도 엔터티로 인정
6. 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.
 → 연결이 안된 독립적 엔티티는 존재하면 안된다.
 * 엔티티는 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다.
 * 엔터티가 도출되었다는 것은 해당업무 내 연광성을 갖고 다른 엔터티와 관계를 맺고 있음을 나타낸다.
 * 단 통계성 엔티티 도출, 코드성 엔티티 도출, 시스템 처리시 내부에 필요한 엔티티 도출과 같은 경우 관계 표현 생략 가능
    - 통계성 엔티티: 업무 진행 엔티티로부터 통계업무만(Read Only)을 위해 별도로 엔티티를 다시 정의
    - 코드성 엔티티: 너무 많은 엔티티와 엔티티간의 관계 설정으로 인해 데이터 모델의 읽기효율성(Readability)이 저하되어
모델링 작업 진행이 어려울 수 있게 됨
                 또한 물리적으로 테이블과 프로그램 구현 이후에도 외부키에 의한 참조무결성을 체크하기 위한 규칙을
데잍베이스 기능에 맡기지 않는 경우가 대부분임으로 논리적으로나 물리적으로 관계 설정할 필요가 없음
   - 시스템 처리시 내부 필요에 의한 엔터티: 시스템 내부적인 필요에 의해 생성된 엔티티이므로 관계 생략(트랜젝션 로그 테이블 등)


- 분류
@ 유무형에 따른 분류
→ 엔터티 자신의 성격에 의해 실제 유형에 따라 구분한다.
 1. 유형 엔터티(Tangible Entity)
  - 물리적인 형태가 있다.
  - 안정적이며 지속적으로 활용 된다.
  - 업무로부터 엔터티를 구분하기 가장 용이 (ex. 사원, 물품, 강사 등)
 2. 개념 엔터티(Conceptual Entity)
  - 물리적인 형태가 없다.
  - 관리해야 할 개념적 정보로 구분된다. (ex. 조직, 보험 상품 등)
 3. 사건 엔터티(Event Entity)
  - 업무 수행함에 따라 발생되는 엔터티
  - 발생량이 많아 각종 통계자료에 이용되기도 한다.(ex. 주문, 청구, 미납 등)

@ 발생 시점에 따른 분류
 1. 기본 / 키 엔터티(Fundamental Entity,  Key Entity)
  - 그 업무에 원래 존재하는 정보.
  - 다른 엔터티와의 관계로 생성되지 않고 독립적을 생성 가능하며 타 엔터티의 부모역할을 한다.
  - 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 갖게 된다. (ex. 사원, 부서, 고객, 상품, 자재 등)
 2. 중심 엔터티(Main Entity)
  - 기본 엔터티로부터 발생되고 업무에 있어 중심적인 역할을 한다.
  - 데이터의 양이 많이 발생되고, 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다. (ex. 제약, 사고, 예금원장, 청구, 주문, 매출 등)
 3. 행위 엔터티(Active Entity)
  - 두 개 이상의 부모엔터티로부터 발생되고, 자주 내용이 바뀌거나 데이터량이 증가된다.
  - 분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관 모델링을 진행하면서 도출 될 수 있다. (ex. 주문목록, 사원 변경이력 등)

@ 스스로 생성될 수 있는지에 따라 (독립 엔터티, 의존 엔터티)

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


● 데이터 모델의 표기법 ERD (Entity Relationship Diagram)
= 업무분석에서 도출된 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
= 식제 프로젝트에서는 도식화된 그림 정도로만 생각하지 않고 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기 하는데에 가장 중요한 표기법이자 산출물

- ERD 작업 순서
1. 엔터티를 그린다.
2. 엔터티를 적절하게 배치한다.
3. 엔터티간 관계를 설정한다.
 * 초기에 모두 Primary Key로 속성이 상속되는 식별자 관게를 설정
4. 관계명을 기술한다
5. 관계의 참여도를 기술한다.
 * 관계차수(Cardinality)를 표현 (=관계가 참여하는 성격 중 엔터티 내에 인스턴스들이 얼마나 관계에 참여하는지 나타냄)
6. 관계의 필수여부를 기술한다.


● 속성 (Attribute)
= 업무에서 필요로 한다
= 의미상 더 이상 분리되지 않는다.
= 엔티티를 설명하고 인스턴스의 구성요소가 된다.

- 엔티티, 인스턴스와 속성, 속성값에 대한 내용과 표기법
 1. 엔티티, 인스턴스, 속성, 속성 값의 관계
  * 한 개의 엔티티는 두 개 이상의 인스턴스의 집합이어야 한다.
  * 한 개의 엔티티는 두 개 이상의 속성을 갖는다.
  * 한 개의 속성은 한 개의 속성 값을 가진다.
2.  표기법
  * IE 표기법, Barker 표기법

- 특징
1. 엔티티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보다.
2. 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
3. 하나의 속성에는 한 개의 값만 가진다.
     하나의 속성에 여러 개의 값이 있는 다중 값일 경우 별도의 엔티티를 이용하여 분리한다.

- 분류
1. 속성의 특성에 따른 분류
  * 기본 속성: 업무로부터 추출한 모든 속성이 여기에 해당하며 엔티티에 가장 일반적이고 많은 속성을 차지한다.
  * 설계 속성: 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화 하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성
  * 파생 속성: 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다.
2. 엔티티 구성 방식에 따른 분류
  * 엔티티를 식별할 수 있는 속성: PK(Primary Key)속성
  * 다른 엔티티와의 관게에서 포함된 속성: FK(Foreign Key)속성
  * 엔티티에 포함되어 있고 PK,FK에 포함되지 않은 속성: 일반 속성

- 도메인 (Domain)
 = 속성이 가질 수 있는 값의 범위
 = 엔티티 내에서 속성에 대한 데이터타입과 크기, 그리고 제약사항을 지정한 것

-명명법
1. 해당 업무에서 사용하는 이름을 부여한다.
2. 서술식 속성명은 사용하지 않는다.
3. 약어 사용은 가급적 제한한다.
4. 전체 데이터 모델에서 유일성 확보하는 것이 좋다.