21. 엔터티 설명은 어떻게 기술하는가?

📕 설명 : 엔터티에 관해서 기술

• 엔터티 설명은 생략하지 않고 반드시 기술해야한다.
  Why? : 해당 엔터티가 어떤 데이터를 관리하는지 알기 위해서이다.
  엔터티의 구별에서 설명보다 더 중요한 것은 엔터티 명과 업무 식별자이다.
  최종 엔터티 설명은 간결하고 명료하게 기술해야 한다.

기술

• 본질적인 설명 : 엔터티를 구성하는 데이터의 본질/성격/주제
• 부가 설명 : 업무에 대한 설명, 프로세스에 대한 설명

가공 데이터

• 원천 데이터가 어떤 엔터티인지 기술해야 한다. 외부에서 받았다면 어디에서 받았는지 기술이 필요하다.

22. 개념 모델에 포함하는 주요 엔터티란?

📕 개념 모델에 포함되는 엔터티가 핵심 엔터티이다.

• 핵심 엔터티 = 주요 엔터티
  -> 중요하고 주된 엔터티지만 기준이 모호하다.

주요 엔터티의 기준을 잡는 몇가지 방법

• 행위의 주체가 되는 엔터티 : 주문의 주체 : 고객
• 행위의 대상(목적)이 되는 엔터티 : 주문의 목적 : 상품
• 하위 엔터티가 많은 엔터티
• 핵심 업무를 파악 : Application 첫 화면에 나오는 업무가 핵심 업무
• 업무에서 자주 사용되는 엔터티 : 쿼리 분석으로도 찾을 수 있다.

주요 엔터티를 선정하는 이유

• 개념 모델링을 하기 위해서이다.
• 분석을 시작 할 엔터티인지의 대한 구분
• 프로젝트 초반에 선정해야 한다.

선정하는 과정

• 주로 현업 담당자들이 1차적으로 선정한다.
• 담당자들이 요청을 거절 할 때는 모델러가 실체,행위,가공 엔터티로 분류하면서 선정한다.

주요 엔터티의 영역

• 전체 엔터티 중 10~30%정도로 정한다.

🌟 주요 엔터티는 작업의 순서를 정하는 중요한 Task지만 본질적인 Task는 아니다. 여의치 않을 때 생략 할 수도 있고 모델링 중 재선정 할 수도 있다.

23. 업무 식별자

📕 업무적으로 인스턴스를 구분하게 하는 식별자

인조 식별자와 업무 식별자

• 인조 식별자는 인스턴스를 식별하는 역할을 하지만, 업무 식별자는 인스턴스의 발생 기준을 의미한다.
• 인조 식별자는 물리적으로 구분하는 역할을 하지만 업무 식별자는 업무적으로 구분하는 역할을 한다.
• 업무 식별자는 엔터티 정의와 직접 연결이 되기 때문에 엔터티를 정의하는 시점에서 도출해야 한다.

24. 업무 식별자 도출 방법

• 데이터 생성 기준을 찾아야 한다.
• 엔터티에서 인스턴스를 발생시키는 속성이다.
• 정규화를 수행하는 기준을 찾는다.

엔터티 종류에 따른 구분

• 실체 엔터티는 보통 식별 변호가 업무 식별자
  -> ex) 주민등록번호, 사업자등록번호
• 행위 엔터티는 육하원칙에 따른 결정 '누가', '무엇' , '언제', '어떻게' 으로 구분한다.
  -> 실체 엔터티에서는 '언제'에 해당되는 일자 속성은 업무 식별자가 아니다.
• 집계 엔터티는 집계 기준이 업무 식별자가 된다.

기본 원칙

• 최소한의 속성이 되어야 한다.
• 시간 속성과 순번 속성은 우선 제외하고 따져본다.

슈퍼 식별자

• 이미 인스턴스를 식별 할 수 있는 속성에 다른 속성을 추가하더라도 인스턴스는 식별해야 한다.
• 슈퍼 식별자는 지양해야 한다. 논리적인 업무 식별자를 분석 할 때 아무런 의미가 없다.

25. 업무 식별자 표현 방법

• 업무식별자에게 유니크 인덱스를 생성해야 한다.
  -> 물리적으로라도 업무 식별자의 역할을 부여한다.

• 일부 대리 식별자(AK), 후보 식별자(CK) 로 표시하기도 한다.

26. 데이터 모델을 검증 할 수 있는가?

• 단기간에 검증하는 노력이 덜 들어가는 빠른 방법은 없다.
• 모델 검증이 어려운 이유
  -> 인간의 종합적 판단으로 행해지기 때문이다.
  -> 모델러의 판단력과 통찰력에 의존해야하는 분야.
• 검증의 지표가 될 수 있는 세가지 요소 : 엔터티 / 관계 / 속성

🤔Q. 일반적으로 현업에서 모델의 검증은 어떠한 프로세스를 거치나요? 어느 시점에서 하게 되나요? 일정의 어느정도 부분을 (%) 가지고 검증 기간을 가지나요?

27. 엔터티 검증

관리하고자 하는 데이터

• 모델에 표현되지 않은 업무가 있는가? 모델에 표현된 불필요한 업무가 있는가?
• 현재 시점에 필요한 데이터인가? 미래 시점에 필요 할 수도 있는 데이터인가?

엔터티 존재 여부 검증 방법

• Application 화면과의 Metrix : UI와 비교

  • 엔터티만 존재하고 화면이 없는 경우
  • 엔터티에도 없고 화면에도 없는 경우
  • 화면은 있는데 엔터티가 없는 경우 : 누락 여부 판단이 어려움

• ASIS 엔터티와의 Metrix

  • ASIS 엔터티가 TOBE 모델에 없는 경우 : 확인 후 누락 여부 체크
  • TOBE 모델에 있는 엔터티가 ASIS 모델에 없는 경우

속성으로 설계해야하는 것은 아닌가?

• 속성으로 설계해야하는데 엔터티로 설계하는 경우
  -> 1:1 관계 엔터티 중에 상위 엔터티와 합치면 의미가 명확해지는 엔터티가 있는지 검토 필요
• 엔터티로 설계해야하는데 속성으로 설계하는 경우
  -> 정규화, 변경 이력 데이터 검토

하나의 엔터티는 하나의 주제로 구성되어 있는가?

• 엔터티를 분류하는 것도 도움이 된다.
• 실체 / 행위 / 가공 / 기준

유사한 성격의 데이터인데 개별적인 엔터티에서 관리되는지 확인

• 성격이 유사한 데이터 집합은 엔터티 통합을 기본 원칙으로 검증해야 한다.
• 유사 데이터 -> 통합하면 실익이 있는지 확인
  유사데이터인지 확인 할 때 엔터티 명을 정렬해서 유사성을 검토해본다.
  ASIS 데이터와 비교해서 정렬도 검토 가능
• 모델의 모양을 살펴본다. 유사한 구조가 반복되면 좀 더 일반화하여 통합이 가능하다.

필요한 단어만 사용해서 엔터티 명을 구체적으로 했는가?

• 엔터티명을 단어로 분할 시 2~3개의 단어로 이루어졌다면 충분히 데이터 성격을 반영하고있는지 고민해본다.
• '기타'같은 모호한 단어를 사용했는지 확인하고 모호한 단어는 제외한다.
• 확장성을 고려한 엔터티명인지 확인한다.
• 필요 없는 단어를 생략해야 한다.
  -> 대표적으로 처리/정보/테이블/마스터/관리/등록/리스트/시스템
  ex) '~접수신청내역'

엔터티 명이 주 식별자와 한쌍이 되도록 붙였는가?

• 예를 들어 엔터티 명이 '계약'인데 주 식별자는 '약정번호','계좌번호'는 어울리지 않는다.

엔터티 설명이 존재하며 간결하고 명확한가?

• 엔터티 설명은 반드시 기술하는 것이 원칙이다.

업무 식별자가 존재하는가?

이력 데이터를 관리하는 엔터티가 많는가?

• 내역과 이력의 구분이 명확해야 한다.
  이력 데이터는 변경된 데이터를 관리하는 엔터티이기에
  쌓이는 데이터는 발생 내역과 변경 이력이 존재한다.

• 실체 엔터티는 원천 엔터티와 이력 엔터티를 별도로 관리하는게 좋다.

• '~순번'이 들어가게되면 이력 성격인지 내역 성격인지 구분하기 어려워 진다.

일대일 관계의 두 엔터티를 합체 할 수 없는가?

• 이유가 없다면 합체 할 것을 고려한다.

종속 관계 엔터티의 주 식별자 상속이 적절한가?

• 종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속한다.

데이터 인스턴스가 하나뿐인 특수 엔터티가 있는가?

• 업무 요건이 하나의 인스턴스만 발생하는 엔터티도 존재하니 확인이 필요하다.

주 식별자가 존재하지 않는 엔터티가 있는가?

• 인스턴스가 하나뿐이라면 주 식별자가 필요하지 않지만 그럼에도 있는 것이 좋다.

주 식별자가 동일한 엔터티가 있는가?

• 성능이나 관리 측면에서 1:1 , Super/Sub로 나눈 것을 제외하고는 검토가 필요하다.

엔터티의 의미를 쉽게 설명 할 수 있는가?

외부*복제 엔터티의 엔터티 명과 주 식별자가 원천 엔터티가 같은가?

28. 데이터 모델 설계 원칙

모델 우선순위

📚

• 데이터 무결성
• 데이터 성능
• 관리 효율성
• 사용 편의성

설계 원칙

📚

• 정체성
• 통합성
• 유연성
• 무결성
• 가독성
• 업무 연관성
• 성능 효율성
• 관리 효율성
• 표준화
• 데이터 보안 대비

정체성

• 데이터 성격에 맞는 정체성이 뚜렷해야 한다.
• 정의가 명확해야 하고 그것에 맞게 주 식별자를 정해야 한다.

통합성

• 유사한 성격의 데이터는 통합하는 것이 주요 원칙이다.
• 서브타입을 설계하면 모델 가독성이 좋아진다.

유연성

• 유연한 모델이란? 확장하기 쉬운 모델이다.
• 데이터가 통합 될 수록 모델은 유연해진다.
• 엔터티가 정규화 될 수록 모델은 유연해진다.

무결성

• 데이터의 결점이 없는 상태를 의미한다.
• 엔터티의 주 식별자가 없으면 무결성을 지키기 어렵다.
• 속성은 도메인에 맞는 데이터 타입을 사용해야 한다.
• 중복데이터를 배제해야 한다. 예외가 있다면 심각한 성능 문제가 있을 때만 채택을 고려해본다.

가독성

• 관계선이 겹치지 않게 한다.
• 서브타입으로 표현한다.
• 재귀 관계나 배타 관계를 표현한다.

업무 연관성

• 업무 요건에 맞는 모델이어야 한다.
• 업무 식별자가 제대로 도출되어야 한다.

성능 효율성

• 요건 별로 검토하는 것이 바람직하다.
  어떤 요건은 데이터를 통합하고 정규화를 해야 성능이 좋아지고
  어떤 요건은 비정규화를 통해 성능을 극대화 시킬 수 있다.

관리 효율성

• ERD가 제대로 관리 할 수 있도록 설계해야 한다.
• 엔터티의 개수도 관리 측면에서 필요하다.
  의미없는 1:1을 통합하며, 백업 엔터티를 설계하기보다 파티션으로 설계한다.

표준화

• 동일한 용어를 사용하도록 설계해야 한다.
• 메타시스템을 사용하여 속성 명을 일관되게 사용한다.

데이터 보안 대비

• 데이터 모델링 시 암호화 대상 속성을 주의해야 한다.
• 암호화 대상 속성을 주 식별자로 사용하면 안된다.
  이렇게 되면 외래키도 암호화가 되기에 검색 구문에 사용하기 불편하며, 인덱스를 사용하지 못하는 이슈가 있을 수 있다.

29. 무결성에 대하여

📕 무결성 : 흠이 없이 온전한 상태.

데이터 무결성을 지킬 수 있는 방법

📚

• 엔터티 무결성
• 참조 무결성
• 도메인 무결성
• 업무 무결성

엔터티 무결성

• 엔터티에 존재하는 모든 인스턴스는 고유해야 하며, Null 값이 없어야 한다.
• 주 식별자에게는 PK (Unique + Not null) , 업무식별자에게는 (Unique)를 부여한다.

참조 무결성

• 외래 식별자 속성 값이 참조되는 엔터티의 주 식별자 값과 일치하거나 Null이어야 한다.
  -> 반드시 상위 엔터티에 인스턴스가 존재하거나 널이어야 한다.

도메인 무결성

• 속성과 관련된 제약이다.
  특정 속성 값은 같은 데이터 타입과 길이, 같은 널 여부, 같은 기본 값, 같은 허용 값등을 동일한 범주의 값만 존재해야한다.
  -> ex) 고객이름 속성에 '123' , 전화번호 속성에 '서울시'

업무 무결성

• 기업에서 업무를 수행하는 방식이나 데이터를 처리하는 규칙
• 강제적으로 지키게하는 방법으로 Trigger가 존재한다.

🤔Q. Application에서 무결성들을 구현하는 것의 장단점은 무엇인가?

30. 성능

성능의 종류

1. 조회 성능 (Select)
2. 쓰기 성능 (DML)

화면 구성에 따른 모델 설계 (?)

1. 화면이 횡으로 구성되었다면 비정규형도 고려한다.
2. 화면이 종으로 구성되었다면 정규형으로 고려한다.

• 화면의 중요도와 사용 빈도도 고려해야 한다.

🤔Q. 화면이 횡으로 이루어져서 비정규형을 고려한다는 것은 하나의 스키마에서 많은 컬럼을 출력한다는 의미로 보이는데, 이러한 경우가 많이 있나요?