10. 엔터티 분류법

엔터티 분류법

• 실체 엔터티 : 실체 물체(보이는 실상)에 대한 본질적인 데이터를 관리
• 행위 엔터티 : 행위나 행동으로 발생한 원천 데이터를 관리
• 가공 엔터티 : 원천 데이터를 추출, 집계한 데이터를 관리
• 기준 엔터티 : 실체나 행위 데이터의 기준(업무 기준)이 되는 데이터를 관리

엔터티를 분류하는 것은 부가적일 뿐 본질적인 것은 아니다.
그렇기에 업무에서 핵심적으로 사용하는 소수의 실체와 행위 엔터티 선정만 하는 경우도 있다.

엔터티 분류 기준

• 데이터의 성격 (용도, 중요도, 생성 순서 등)

설계 순서

• 기준 엔터티
• 실체 엔터티
• 가공 엔터티

11. 실체 엔터티

📕 실체 : 실제의 물체 또는 외형에 대한 실상

구분

• 실체적인 데이터 : 이름, 주민등록번호, 나이
• 실체적이지 않은 데이터 : 실체가 한 행동을 관리하지 않는다.

영향

• 실체 엔터티를 통해 행위 엔터티(실체가 발생시킴)가 생성된다.
• 실체 엔터티와 행위 엔터티를 통해 가공 엔터티가 발생한다.
• 기준 엔터티도 실체와 연관된 기준일 때가 많다.

특징

• 행위 엔터티의 주체가 되며, 부모 엔터티가 존재하지 않는다.
• 주식별자가 단순해야 좋다. (고객번호)
• 과감한 통합이 필요하다. (전체 모델 구조가 단순해지며 단순한 모델이 좋은 모델이 될 가능성이 높다)
• 이력 데이터 설계의 주의가 필요하며, 이력 데이터를 실체 데이터에 포함시키지 않아야 한다.
• 주로 행위에 의해서 생긴다.
  예시) 펀드 계약(원인) 엔터티는 존재하지만 펀드 계좌(결과) 엔터티가 없는 경우
  -> 하나만 관리해야 한다면 결과를 관리하는게 좋다.

12. 행위 엔터티

📕 행위 : 어떤 실체의 업무 행위나 활동에 의해 생긴 원천 데이터를 관리하는 엔터티

• 엔터티 중 가장 많다.
• 발생순서가 존재한다.
• 주식별자가 복잡하다.
  -> 업무 식별자를 사용하기 때문에
• 관계의 복잡성
  -> 일반적으로는 가공 엔터티와 관계가 발생하면 잘못된 모델이다.
• 중복속성이 많다.
• 행위 엔터티는 최대한 통합하는 것이 좋다.

업무 식별자를 도출 하는 방법

• 누가, 무엇을, 언제, 어떻게, 어디에서

13. 가공 엔터티

📕 가공 : 원천 데이터가 아닌 데이터를 관리한다.

• 주로 집계/요약/임시 데이터를 관리한다.

• 기초 속성은 일반 속성이며 일부 속성만 집계성격이 있다고해서 집계 엔터티가 되는 것이 아니다
  -> 예시) 고객 엔터티의 고객명,주민등록번호, 포인트총합이 있을 때 포인트총합이 있다고해서 집계 엔터티가 되는 것이 아니다.
  기초 속성이 무엇이냐에 따라 엔터티의 성격이 정해진다.

• DW에서 많은 부분을 차지하는 집계 엔터티가 업무에서 가장 사용이 많다.
  -> 해당 엔터티의 존재 여부를 고려해야한다.

집계엔터티의 통합

• 데이터가 중복됨으로 말미암아 데이터 정합성의 문제가 생긴다.

14. 기준 엔터티

📕 기준 :
1. 코드 데이터처럼 기준 정보 성격의 데이터 관리
2. 과목 데이터처럼 기본 정보 성격의 데이터를 관리
둘다 업무를 수행 할 때 참조되기 때문에 참조(Reference) 엔터티 라고도 불린다.

🤔Q. 기준과 기본 데이터의 예시는 어떠한 것이 있을까? (쉽게 와닿지 않음)

기준 엔터티

• 실체 엔터티와 여러면에서 유사하다. 단지 개념적인 것을 관리한다.
  예시) 환율

• 기준 엔터티를 사용하면 데이터 품질이 좋아진다.

• 통합적인 부분에서 관심을 두어야 한다.

  • 1. 기준에 의미 = 원천적으로 하나만 존재 = 중복으로 존재해선 안된다.
  • 2. 구조적인 통합 = 업무의 기준이 되는 금액이나 날짜는 하나의 엔터티에서 통합 관리

15. 데이터 생성에 따른 분류

📕 데이터가 어디서 생성되었는가? / 데이터가 어떻게 생성되었는가?

어디서 생성되었는가?

• 구분 하는 기준 자체가 중요한 것이 아니라, 기준을 정한 후 일관되게 생각하는 것이 중요하다.

내부 데이터 : 내부에서 생성 할 수 있는 데이터

• 값에 대한 결정이 가능하다.
• 중복 데이터를 배제하고 완전 정규화된 관계형 데이터 모델에 저장한다.

외부 데이터 : 외부에서 받은 데이터

• 값에 대한 결정이 있지 않고 받은 그대로 관리한다.
• 받은 그대로 저장 할 수 있고, 재설계 할 수 있다.
  -> 대부분 전문(String) 형태로 받기 때문에 긴 문자열로도 저장한다.

🤔Q. 전문형식의 데이터는 관리의 차이에 따라 DBMS에 저장하기보다, 해당 위치를 보관하는 link만 저장하는 경우도 많은데, 이럴 때 이 데이터는 외부 데이터인가?

어떻게 생성되는가?

키 입력(key-in) : 화면 입력

배치(batch)

• 대부분 정규화 대상으로 생각하지 않는다.
• 데이터의 의미를 파악하기 어렵고 대량의 데이터이다.
• 외부의 요청에 따라 필요한 데이터를 뽑아야 하기 때문에 비정규형이 자주 사용된다.

배치의 구분

대량 배치 : 대부분의 사용

개별 배치 : 외부에서 받는 전문 형식을 데이터로 실시간 처리 경우, 트리거도 개별 배치

16. 엔터티 유형에 따른 분류

📕 기본 / 상세 / 내역 / 이력 / 코드 / 관계 / 집계 / 백업 / 임시

단점

• 기준이 명확하기 어렵다.
• 실무에서 접미어로 많이 사용한다
  ex) _L , _M , _H

기본 엔터티

• 기본적으로 실체 엔터티와 같다. 엔터티에 저장하는 데이터가 실체 물체라면 실체 엔터티며 기본 엔터티이다.
• 실무에서는 중요 엔터티를 기본 엔터티로 분류하기도 한다.
• ERD에서 가장 중심이 되는 한 개의 엔터티, 혹은 서너 개의 엔터티를 기본 엔터티로 선정한다.
  예시로 ~거래기본엔터티가 있는데 이 엔터티가 오히려 설명할 내역 엔터티(~거래내역)로 지정 하는 것이 더 적합한 경우도 있다.

내역 엔터티

• 기본적으로 행위 엔터티와 유사하다.
• 기본 엔터티와 구분이 모호 할 때가 있다.
  ex) 보험계약
  -> 계약 행위에 중심을 두면 '보험계약내역'
  -> 행위에 의한 결과를 중시하면 '보험계약기본'

상세 엔터티

• 기본 엔터티, 내역 엔터티와 혼동 되는 경우가 많다.
• 한 개의 엔터티를 1:1 관계의 두개의 엔터티로 분해 할 때 하위 엔터티를 의미한다.
  -> 주요 속성이 아닌 속성을 관리한다.
• 엔터티 명 또한 상세하게 정하는 것이 원칙이다.
  ex) '고객기본상세' 보다는 '고객연락처기본' / '거래내역상세' 보다는 '거래세금내역'

이력 엔터티

• 접미어의 의미가 포함된 엔터티

코드 엔터티

• 코드 명과 코드 값을 관리하는 엔터티
• 통합관리되어야 한다.

관계 엔터티

• 교차 엔터티의 일종이다.

집계 엔터티

• 어떤 값을 집계한 속성이 그 엔터티의 주요 속성이면 '~집계' 엔터티로 정한다.
  -> '~내역','~상세'로 정하지 않도록 한다.

백업 엔터티

• 중복 데이터를 관리하는 엔터티와 구분되어야 한다.

임시 엔터티

• 기준을 명확히 정해야 한다.

17. 교차 엔터티란?

📕 다대다(M:M) 관계에서 발생한 엔터티

• 다대다 관계는 물리 모델로 구현 될 수 없다. 그렇기에 교차 엔터티를 설계한다.
• 역할을 관리하는 모델에서도 많이 생긴다.
• 교차 엔터티의 명칭은 일반적으로 양쪽 부모 엔터티와의 연관성을 표현 할 수 있어야 한다.
  ex) 주문 -< 주문상품 >- 상품
• 다대다(M:M) 관계가 없어질 때 까지 교차 엔터티를 설계해야 한다.
• 작도 시 양쪽 엔터티 사이에 위치시키는 것이 좋다.
• 주식별자가 난해 할 수 있다.

18. 엔터티 설계 원칙

성격, 본질, 주제에 따른 정체성이 분명해야 한다.

• 데이터 정체성
• 엔터티 무결성
• 엔터티 유일성
• 데이터 혼용 배제
• 타 엔터티와 관계 존재
• 프로세스 도출 지양
• 화면 도출 지양
• 데이터 관리 요건

데이터 정체성

• 엔터티를 명확하게 정의해야 한다.
  -> 가장 큰 부작용은 엔터티를 임의로 사용하게 되어 여러 데이터가 혼합되는 경우이다.

엔터티 무결성

• 주 식별자가 존재하도록 설계해야 한다.

엔터티 유일성

• 전사적으로 유일해야 한다. 유사 엔터티는 통합되어야 한다.

데이터 혼용 배제

• 유사한 데이터를 통합하는 것과 마찬가지로 서로 다른 성격의 데이터를 혼용해서도 안된다. (정체성 확보)

타 엔터티와 관계 존재

• 관계가 아예 없는 엔터티는 성격을 다시 한번 살펴봐야 한다.
• 가공/기준 엔터티 등은 관계가 존재하지 않는 경우도 있다.

프로세스 도출 지양

• 일반적으로 프로세스와 엔터티는 별개이다.
• 같은 성격이더라도 프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 위한 화면에 따른 엔터티를 설계하면 안된다.
  -> 프로세스의 변화에 따라 엔터티나 관계가 바뀔 수 밖에 없기 때문에 유연하지 않은 모델이 된다.

화면 도출 지양

• 프로세스와 동일하게 화면 별로 만드는 것도 지양해야 한다. 화면은 뷰와 유사하는 식이며 대부분 엔터티와 1:1 매칭하지 않는다.

데이터 관리 요건

• 데이터를 관리하기 위한 엔터티는 사용하지 않으면 삭제해야 한다.

19. 엔터티 명은 어떻게 정하는가?

📕 3가지 기준

• 어떤 집합으로 구성되었는가?
• 집합의 결정자는 무엇인가?
• 어떻게 엔터티명을 붙히는게 적절한가?

엔터티 명명

• 데이터 성격을 파악하기 쉽게 해야 한다.
• 일관성이 있어야 한다.
• 구체적이어야 한다.
  ex) 성격이 고정적이면 '서적'과 같이 구체적 정의 / 추 후 다른 상품이 들어오도록 가능성이 있으면 '상품'
• 확장성을 고려해야 한다.
  ex) 개인고객 -> 추후 법인고객과 사업자 고객 관리를 위한 '고객'
• 필요한 단어만 사용한다.
  -> 대부분 무의미한 단어 : 등록,처리,정보,관리,리스트,테이블,시스템
• 프로세스를 표현하지 않도록 한다.
  ex) '~등록','~처리'
• 명사형으로 명명을 노력한다.
• 가능하면 짧게 한다.
• 테이블 명이 엔터티 명에 종속되지 않도록 한다.
• 동일한 엔터티 명이 없도록 해야 한다.

🌟 엔터티 정의, 엔터티 명, 업무 식별자만 제대로 설계되면 엔터티는 온전해진다. 💯

🤔Q. 개발 도중 엔터티의 변경인 많이 있다. 이럴 때 모델링은 어느 시점에서 하는 것이 좋은가? 테스트가 끝날 때?

🤔Q. 테이블에 단순 번호를 사용하는 것의 장단점이나 실제로 사용 사례가 궁금하다.

20. 다양한 엔터티에 대한 명명법

• 실체 엔터티 명명법
• 행위 엔터티 명명법
• 교차 엔터티 명명법
• 집계 엔터티 명명법
• 외부 엔터티 명명법
• 서브타입 엔터티 명명법
• 일대일 관계 엔터티 명명법

실체 엔터티 명명법

• 핵심 : 명사로 끝나는 것 But 행위 엔터티는 명사로 끝나지 않는다.
  ex) 탈퇴한 회원만 관리 : 탈퇴회원 / 동사가 연상되는 회원탈퇴, 회원탈퇴내역, 탈퇴회원내역등은 적절하지 않다.

행위 엔터티 명명법

회원이 탈퇴한 행위를 관리 한다면 엔터티명은 '회원탈퇴','회원탈퇴내역'이 적절하다.

• 명명할 때 '했음'이나 '~한 데이터'를 붙혀보고 자연스러우면 행위 엔터티에 적합하다.
• 요청 엔터티는 대표적인 행위 엔터티이다.

교차 엔터티 명명법

집계 엔터티 명명법

• 기준이 중요하다. 주 식별자와도 연관성이 있다.
• 기준은 앞쪽에 대상은 뒤쪽에 위치하는 것이 좋다

외부 엔터티 명명법

• 상세화 : 특정 기관에서만 받은 데이터를 관리하면 해당 기관명을 붙이는 것이 좋다.
• 일반화 : 유사한 데이터를 다른 기관에서도 받는다면 기관명을 생략하는 것이 좋다.

서브타입 엔터티 명명법

• 주로 슈퍼타입 엔터티에 수식어를 붙힌다.
  ex) 주문 -> 국내주문, 국외주문

일대일 관계 엔터티 명명법

• 유사 속성을 분리 할 때는 데이터의 성격에 맞게 붙힌다.
• 사용 빈도에 따라 속성을 나누는 경우는 '~상세'가 적절하다.
• 프로세스를 표현한 결과일때는 '~요청','~승인'같이 데이터 성격에 맞는 엔터티를 붙힌다.