01. 엔터티 이야기 (2)

1.18 엔터티 설계 원칙

엔터티를 설계할 때는 성격, 본질, 주제에 따른 정체성이 분명한 엔터티로 설계해야 한다.

 

▶ 엔터티를 설계하는 원칙

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

 

데이터 정체성

엔터티를 명확하게 정의하는 것은 데이터 모델링을 수행할 떄 가장 중요한 부분이면서, 동시에 가장 간과하는 부분이기도 하다. 엔터티만 명확하게 정의하면 모델링의 많은 문제는 해결된다.

엔터티 정의가 불분명할 때 발생할 수 있는 가장 커다란 부작용은 엔터티를 임의로 사용하는 것이다. 여러 데이터가 혼합된 형태의 엔터티는 엔터티가 아니라 뷰로 사용돼야 한다.

 

엔터티 무결성

엔터티 무결성(Entity Integrity)이라는 것은 주 식별자가 존재하도록 엔터티를 설계해야 한다는 것을 의미한다. 이는 물리적인 주 키(Primary key)가 존재해야 하는 것은 물론이고, 엔터티의 인스턴스를 식별할 수 있는 식별자가 존재해야 한다는 것을 의미한다.

 

엔터티 유일성

같은 성격의 데이터는 전사적으로 유일해야 한다. → 유사한 엔터티는 통합되어야 함을 의미한다.

 

데이터 혼용 배제

하나의 엔터티에 서로 다른 성격의 데이터를 혼용해서는 안 되는 것도 엔터티 설계의 중요한 원칙이다. 한 엔터티에 여러 종류의 데이터를 혼용해서 사용하는 것은 지양해야 한다.

 

타 엔터티와 관계 존재

엔터티는 보통 다른 엔터티와 관계가 존재하는 것이 일반적이다. 그렇지만 가공/기준 엔터티 등은 관계가 존재하지 않은 채 고립될 수 있다.

 

프로세스 도출 지양

실무에서 프로세스에 따라 엔터티를 설계하는 경향이 있으나, 일반적으로 프로세스와 엔터티는 별개다.

같은 성격의 데이터임에도 프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 설계하면 안 된다. 프로세스에 따라 엔터티가 별도로 도출되면 프로세스의 변화에 따라 엔터티나 관계가 바뀔 수밖에 없어 유연하지 않은 모델이 된다.

프로세스가 아닌 데이터 성격을 기준으로 엔터티를 생성하는 것이 원칙이다. 프로세스는 속성으로 표현될 수 있다.

 

화면 도출 지양

하나의 화면에 하나의 엔터티를 매핑해서 설계하는 것은 지양해야 한다.

 

데이터 관리 요건

가장 근본적인 원칙: 데이터베이스에서 관리하려는 데이터를 엔터티로 설계해야 한다는 것

관리할 필요가 없는 데이터는 엔터티로 만들 필요가 없다.

 

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

엔터티 명은 자신의 데이터 집합에 대한 이름이기도 하지만, 또한 다른 엔터티가 바라보는 이름이기도 하므로 타 엔터티와 연관 관계에서 중요한 역할을 한다. 

 

데이터 성격을 파악하기 쉽게 명명

엔터티 명을 정하는 가장 중요한 원칙: 데이터 성격을 가장 적절하게 표현하는 것

엔터티 명을 보고 어떤 데이터를 관리하는지 알 수 있도록 적절하고 구체적으로 표현하는 것이 중요하다.

 

일관성 있게 명명

엔터티 명을 정할 때는 일정한 약속을 정해 준수해야 한다.

 

구체적으로 명명

엔터티명을 정할 때의 두 가지 방법

• 구체적(Specific)으로 정할지
• 일반적(General)으로 정할지

구체적으로 정해야 한다는 의미는 데이터 성격을 파악하기 쉽게 정한다는 의미와 유사하다. 또한 모호하게 정하지 말아야 한다.

    ex. 주 식별자가 '고객번호 + 매체종류코드'인 수수료를 관리하는 엔터티 → '매체별수수료' 보다는 '매체별고객수수료'가 적절

    ex. '진행이력' 보다는 '계약진행이력'이 더 구체적이고 명확함

엔터티 명이 구체적이어야 한다는 의미는 엔터티의 성격을 표현해야 한다는 의미다. 엔터티 유형이 실체를 관리하면 실체를 연상할 수 있도록 엔터티 명을 정해야 한다.

    ex. 탈퇴한 고객을 관리하는 엔터티 → '고객탈퇴' 보다는 '탈퇴고객'이 적절

 

확장성을 고려하여 명명

엔터티명을 일반적(General)으로 정한다는 것 → 넓은 개념을 포함할 수 있도록 유연하게 정한다는 의미

확장성을 고려한다는 것은 데이터 통합을 고려한다는 의미와도 같다. 엔터티 명을 지나치게 구체적으로 정하면 엔터티가 유연해지지 않는다.

    ex. 해당 시스템에서 현재 개인 고객만을 관리하더라도 엔터티명을 '개인고객'으로 정하는 것보다는 '고객'으로 정해서 법인 고객

          이나 사업자 고객을 관리하게 될 때를 대비할 수 있음

 

필요한 단어로만 명명

엔터티 명에 필요한 단어만을 사용하는 것도 주요 원칙이다. 생략해도 의미가 통하는 단어는 생략해야 한다.

    ex. 등록/처리/정보/관리/리스트/테이블/시스템

    ex. ~마스터 (고객마스터 엔터티를 사용하면서 누군가 고객이라는 엔터티를 만들면 같은 의미의 엔터티가 존재하게 됨)

접미어를 삭제해도 엔터티를 이해하는 데 문제가 없다면, 그 접미어는 역할을 못 하는 사족과 같다.

중복 의미를 나타내는 단어가 사요되는 것도 바람직하지 않다.

    ex. 고객불만신고내역 → 고객불만내역

    ex. 서비스변경요청진행상태이력 → 서비스변경진행이력

 

프로세스를 표현하지 않도록 명명

'~등록', '~처리' 등은 군더더기 단어지만 프로세스를 표현한 단어이기도 하다. 엔터티 명에 프로세스(업무)를 표현하는 것은 바람직하지 않다.)

'JOB수행내역', '동기화요청내역' 엔터티도 단순히 업무를 설명한 엔터티 명이다. 해당 업무를 수행하는데 필요한 데이터가 무엇인지를 표현해야 한다.

 

명사형으로 명명

엔터티 명은 명사형으로 사용하는 것이 일반적이다. 형용사형을 사용한, 설명하는 식의 엔터티명은 함축적이지 않으며 직관적이지 않다. 그리고 띄어쓰기를 하지 않는 것이 또한 함축적이다. 띄어쓰기를 하지 않으므로 가독성에 문제가 될 정도로 길면 좋지 않다.

 

가능하면 짧게 명명

엔터티 명을 길게 정하더라도 엔터티 명을 보고 그 엔터티가 관리하는 데이터의 성격을 완전하게 알기는 어려우므로 지나치게 길지 않은 것이 바람직하다.

 

테이블 명이 엔터티 명에 종속되지 않도록 명명

엔터티 명은 업무에서 사용하는 표준 용어를 사용해야 하지만, 테이블 명(엔터티의 영문이름)이 엔터티 명에 종속되는 것은 바람직하지 않다. 속성 명을 컬럼 명으로 자동 전환하는 것과 달리 엔터티 명은 테이블 명으로 자동 전환하지 않아야 한다. 그래야 엔터티 명이 바뀌더라도 테이블을 재생성해야 하는 문제가 발생하지 않게 된다.

엔터티 정의가 바뀌는 것은 바람직하지 않지만, 엔터티 명은 생각보다 자주 바뀐다. 테이블 명이 엔터티 명에 종속돼 있다면 엔터티 명이 바뀔 때마다 테이블 명이 바뀌게 되고 애플리케이션도 수정해야 하므로 파장효과가 크다. 따라서 테이블 명에 단순 번호 등을 사용하는 것이 바람직하다. 

 

 

동일한 엔터티 명이 없도록 명명

테이블 명과 마찬가지로 엔터티 명은 전 영역에서 중복돼서는 안 된다. 하지만 관계선의 복잡성을 해결하기 위해 주로 사용하는 엔터티 복제는 모델읭 가독성을 위해 여러 번 사용하는 것이 가능하다.

외부 엔터티도 주제 영역 간에 여러 번 표현이 가능하다. 외부 엔터티를 사용할 때는 해당 주제 영역에서 엔터티 명을 반드시 확인해야 한다. 특히 모델링 중에는 엔터티 명이 수시로 변할 수 있으므로 확인을 게을리하면 안 된다.

    ex. '[외부 주제 영역]엔터티 명', '[복제]엔터티 명'

 

1.20 다양한 엔터티에 대한 명명법

실체 엔터티 명명법

실체 엔터티에 대한 명명법의 핵심은 엔터티 명이 명사로 끝나는 것이다. 

    ex. 회원 중에 탈퇴한 회원만 관리하며, 주 식별자가 회원번호 속성인 실체 엔터티의 이름 → '탈퇴회원'이 적절

          동사가 연상되는 명사(명사형)로 끝나는 '회원탈퇴'나 '회원탈퇴내역', '탈퇴회원내역' 등은 적절하지 않음

 

행위 엔터티 명명법

행위 엔터티 명에는 '~신청', '~거래', '~지급' 등의 행위를 의미하는 단어가 포함된다. 

    ex. 행위 엔터티를 명명법을 고민할 때 사용하는 방법 → 엔터티 명에 '했음'이나 '~한 데이터'를 붙여 보는 것(이렇게 해서 자연스

          러운 문장이 되면 행위 엔터티에 대한 명명으로 적합함)

 

교차 엔터티 명명법

교차 엔터티의 명명법은 관계의 명명법과 연관된다. 즉 다대다(M:M) 관계의 관계 명은 교차 엔터티 명과 유사하다.

 

집계 엔터티 명명법

집계 엔터티는 집계 기준(Dimension)이 중요하다. 이 집계 기준은 집계를 하려는 기준이 되기 때문에 주 식별자와도 연관된다.

집계 엔터티 명을 정할 때 집계 기준은 앞쪽에, 대상(무엇을 집계했는지)은 뒤쪽에 위치하는 것이 좋다.

    ex. 일별고객별매출집계

 

외부 엔터티 명명법

특정 기관에서 받은 데이터만을 관리한다면 해당 기관명을 엔터티 명에 붙이는 것이 좋다. 만약 유사한 데이터를 다른 기관에서도 받을 수 있다거나, 유사한 데이터를 내부에서도 관래한다면 통합을 대비해 기과나명을 생략하는 것이 좋다. 

    ex. 한국거래소에서만 받는 채권 데이터를 관리하는 엔터티명 → 한국거래소채권

          만약 한국예탁결제원에서 받은 채권까지 두 기관의 채권 데이터를 관리한다면 '채권'이 적절함

 

서브타입 엔터티 명명법

서브타입의 명명법은 당연히 슈퍼타입과 연관된다. 서브타입 엔터티 명은 주로 슈퍼타입 엔터티에 수식어를 붙이는 형식으로 사용한다.

    ex. 슈퍼타입 '고객', 서브타입 '법인고객'/'개인고객'

 

일대일 관계 엔터티 명명법

원래 하나의 엔터티에서 관리하는 속성 일부를 분리할 때의 예시

• 유사한 속성을 분리했을 때 → '고객신용엔터티'와 같이 데이터의 성격에 맞게 붙이는 것이 적절함
• 사용 빈도에 따라 속성을 나눈 경우 → '~상세'로 붙이는 것이 적절
• 프로세스를 표현한 결과 일대일 관계가 나타나는 경우 → '~요청', '~승인'과 같이 데이터 성격에 맞는 엔터티 명을 붙이면 됨

 

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

엔터티 설명은 엔터티를 정의하는 것과 다르다. 설명은 단지 엔터티에 관해서 기술하는 것이다. 엔터티 정의는 추상적이고 측량할 수 없어 제대로 한 것인지 알 수 없지만, 엔터티 설명은 생략하면 바로 알 수 있다. 엔터티 설명은 생략하지 않고 반드시 기술해야 한다.

엔터티 설명을 기술하는 이유 → 그 엔터티가 어떤 데이터를 관리하는지 알게 하기 위함

엔터티 설명은 일반적으로 모델러가 다른 사람을 위해 기술하지만, 모델링하는 중에는 모델러 자신에게 도움이 된다. 모델링 도중에 엔터티 설명이 없으면 엔터티 정의가 모호해지는 때가 많다. 엔터티 설명은 타인을 위함이지만 모델러 본인을 위해서도 반드시 쓸 것을 권한다.

 

엔터티 설명에 기술하는 내용

1. 본질적인 설명
   • 엔터티를 구성하는 데이터의 본질/성격/주제 등에 대해서 설명
   • 엔터티에서 관래하는 데이터 자체에 대한 설명으로 필수 내용
2. 부가 설명
   • 데이터 본질에 대한 설명 이외의 업무에 대한 설명, 프로세스에 대한 설명
   • 참고로 기술하면 좋은 설명이기 때문에 이것이 주가 되는 것은 좋지 않다.
   • 해당 엔터티가 원천 엔터티가 아닌 가공 엔터티일 때는, 원천 엔터티가 어떤 엔터티인지를 기술해야 한다. → 중요한 부가 정보
   • 외부에서 받은 데이터라면 어디에서 받았는지를 기술해야 한다.

현행 엔터티

• '엔터티명[테이블명]' 형식의 현행 엔터티 정보를 기술하는 것이 좋다.

서브타입 엔터티

• 서브타입의 데이터 성격이 슈퍼타입과 같으므로 슈퍼타입에 준하는 설명을 기술하면 된다.
• 서브타입 집합에 대한 설명과 고유 속성에 대한 설명을 기술하는 것이 좋다.

그 외

• 간결한 설명이 좋은 설명이다. 단순 명료하게 설명해야 한다. 
• 엔터티 설명은 엔터티 명과 엔터티 속성에 종속적이다. 결국은 데이터베이스에 생성돼 운영되는 표면(스키마)을 보고 판단하는 것이지 글(설명)을 그대로 따라 판단할 수는 없다. 설명은 스키마를 이해하기 위한 보조 정보일 뿐이다.
• 속성 설명은 조사를 생략할 수도 있고 명사형으로 끝나도록 작성하는 것이 명료하지만, 엔터티 설명은 속성 설명과의 차별을 위해 완전한 문장으로 기술하는 것이 좋다.

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

개념 모델이란

• 일반적으로 핵심 에넡티와 핵심 엔터티 간의 관계를 표현한 모델을 말한다.

핵심 엔터티/주요 엔터티

• 중요하고 주된 엔터티 → 무엇이 중요하고 주된 것인가?
  • 행위의 주체가 되는 엔터티
  • 어떤 행위의 대상(목적)이 되는 엔터티
  • 하위 엔터티가 많은 엔터티
  • 핵심 업무에 사용되는 엔터티
  • 업무에서 자주 사용되는 엔터티(쿼리를 분석해서 주요 엔터티를 찾아야 하는데 모델링이 끝난 상태에서 할 수 있음므로 현실적이지 않음)

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

• 개념 모델링을 하기 위해서
• 분석을 시작할 엔터티를 찾기 위해서

주요 엔터티를 선정하는 가장 효과적인 방법

• 현업 IT 담당자에게 도움을 받는 것
  • 이 방법을 사용하면 주요 엔터티 선정이 빠르고 정확하다.
  • 자연히 선정된 주요 엔터티부터 본격적인 분석을 시작할 수 있으므로 장점이 많다.
  • 개념 모델링을 바로 시작할 수 있다
• 모델러의 개략 분석을 통하여 주요 엔터티 선정
  • 실체/행위/가공 엔터티로 분류하면서 주요 엔터티를 선정하면 효과적이다.
  • 다소간의 시간이 걸린다.
  • 현행 엔터티를 개략적으로 분석한 후에 개념 모델링을 시작할  수 있다

 

1.23 엔터티 정의의 또 다른 이름 - 업무 식별자

엔터티를 정의할 때 중요한 또 다른 요소는 업무 식별자다. 엔터티를 정의하는 것에는 업무 식별자를 도출하는 것이 포함된다. 업무 식별자를 모르고 엔터티를 설계(정의)할 수 없다. 집합을 식별할 수 있는 식별자(결정자)가 무엇인지는 엔터티를 정의하면서 자연스럽게 결정된다.

 

식별자

• 엔터티에서 데이터의 유일성을 보장해 주는, 결정자 역할을 하는 속성이나 속성 집합을 의미

업무 식별자

• 업무 식별자는 식별자의 종류 중 하나 → 업무적으로 인스턴스를 구분하게 하는 식별자를 의미
• 업무 식별자는 인스턴스의 개수를 늘리는 데 영향을 준다. 데이터를 업무적으로 구분해서 사용할 때 업무 식별자 값이 새롭게 생긴다. 데이터를 쌓는 기준이 되는 것이 업무 식별자이다.
• 업무 식별자는 엔터티를 정의하는 시점에 도출해야 한다. 주 식별자를 결정하는 것은 조금 늦춰질 수 있지만, 업무 식별자는 엔터티 정의와 직접 연결되기 때문에 엔터티를 정의하는 시점에서 도출해야 한다.

위 사원 릴레이션에서 사원주등록번호 속성이 업무 식별자(밑줄 표시)라면, 사원의 주민등록번호가 같으면 새로운 사원으로 인식하지 않겠다는 것을 의미한다. 즉, 새로운 인스턴스가 추가되는 기준은 사원주민등록번호 속성이다. 

사원주민등록번호 속성에 의해서 데이터가 발생되고 인스턴스가 구별된다. 업무 식별자인 사원주민등록번호 속성이 없다면 해당 데이터의 인스턴스를 늘리는 기준을 알 수 없게 된다. 반면에 주 식별자(# 표시)인 사원번호는 단지 인스턴스를 식별하는 역할만을 한다. 엔터티의 인스턴스를 늘리는 데는 영향력이 없다. 인스턴스가 늘어난 결과를 반영했을 뿐이다.

 

사원번호 속성은 주 식별자이면서 인조 식별자이다. 인조 식별자는 단지 인스턴스를 식별하는 역할을 하지만, 업무 식별자는 ㅇ니스턴스의 발생 기준을 의미한다. 인조 식별자는 인스턴스를 물리적으로 구분하는 역할을 하지만 업무 식별자는 인스턴스를 업무적으로 구분하는 역할을 한다. 

 

1.24 업무 식별자 도출 방법

업무 식별자를 찾는 방법

• 엔터티의 인스턴스가 어떤 기준(속성)에 의해서 생성되는지를 찾아야 한다. → 데이터가 생성되는 기준을 찾아야 한다.
• 정규화를 수행하는 기준(결정자, Determinant)을 찾아야 한다. → 결정자가 곧 업무 식별자.
• 최소한의 속성이 되도록 해야 한다.(슈퍼 식별자 사용은 지양할 것)

실체 엔터티의 업무 식별자

• 보통 식별 번호가 업무 식별자가 된다.(ex. 주민등록번호, 사업자등록번호)
• 실체를 지칭하는 식별 번호 자체가 실체 엔터티의 업무 식별자가 된다.
• 실체 엔터티의 업무 식별자에는 일자 속성이 포함되지 않는다.(이력 데이터는 예외)

행위 엔터티의 업무 식별자

• 육하원칙에 의해 정해진다.
• 행위 엔터티의 데이터를 생성시키는 기준
  • 누가(Who, 행위의 주체)
  • 무엇을(What, 행위의 대상)
  • 언제(When, 행위의 시간)
  • 어떻게(How, 행위의 방법)
• 행위 엔터티의 업무 식별자에는 일자가 포함되는 경우가 많다.(행위가 여러 번 발생할 수 있기 때문)

집계 엔터티의 업무 식별자

• 집계 기준이 업무 식별자가 되며, 이 경우 대부분 업무 식별자가 그대로 주 식별자가 된다.

시각 속성과 순번 속성

• 업무 식별자를 도출할 때는 시각 속성은 배제하고 생각하는 것이 좋다.
• 타임스탬프 타입 속성이 이미 물리적으로 인스턴스를 구분할 수 있기 때문에 업무 식별자와 혼동될 수 있다. 간혹 업무 식별자는 도출하지 않고 타임스탬프 속성을 주 식별자로 설계할 때가 있는데, 이렇게 접근하면 타임스탬프 속성은 모든 엔터티의 주 식별자가 될 수 있기 떄문에 의미가 없다.
• 시각 속성을 배제한 후에 정한 업무 식별자가 인스턴스를 구별할 수 없다면 그때 시각 속성을 추가하면 된다. 

• 순번 속성은 순수한 인조 식별자 → 시각 속성보다 더욱 업무 식별자로서의 의미가 없어서 순번 속성은 업무 식별자에 포함시키지 않아야 한다.
• 순번 속성을 주 식별자에서도 무분별하게 사용하지 않도록 주의해야 한다.
• 시각 속성과 순번 속성을 배제하고 업무 식별자를 고민해보면 엔터티의 성격을 파악하는 데도 많은 도움이 된다.

 

1.25 업무 식별자 표현 방법

업무 식별자에 유니크 인덱스를 생성한다. → 해당 속성에 중복 값이 생기지 않게돼 물리적으로 업무 식별자의 역할을 할 수 있음

 

 

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

모델링이 끝난 후 최종 모델을 단기간에 검증하는 방법은 없다.

모델을 검증하기 위해 엔터티 하나하나를 상세하게 들여다보는, 사실상 모델링과 마찬가지 수준의 검증을 할 수는 없다. 어느 정도까지 가능할지 모르겠지만, 객관화하기 위해서는 정량화해서 수치로 평가할 수 있어야 한다.

모델 검증은 모델의 품질을 높이는 행위이기 때문에 비록 부족하더라도 지속해서 수행해야 하고 좋은 방법을 연구해야 한다. 

 

▶ 모델링 검증 방법

• 엔터티 검증
• 관계 검증
• 속성 검증

 

1.27 엔터티 검증

데이터 모델 검증 시 근본적으로 검토해야 할 사항

• 모델에 표현되지 않은 업무가 있는가?
• 모델에 표현된 불필요한 업무가 있는가?

엔터티 존재 여부 검증 방법(기초적인 방법)

1. 화면과 비교하는 방법
   • 화면은 있는데 엔터티가 없는 경우
   • 엔터티만 존재하고 화면이 없는 경우
   • 엔터티에도 없고 화면에도 없는 경우
2. ASIS 엔터티와 비교하는 방법
   • ASIS 엔터티가 TOBE 모델에 없는 경우
   • TOBE 모델에 있는 엔터티가 ASIS 모델에 없는 경우

엔터티를 검증하는 여러 가지 방법

1. 속성으로 설계해야 하는 것은 아닌지?
   
   • 속성으로 설계해야 하는데 엔터티로 설계한 경우
   • 엔터티로 설계해야 하는데 속성으로 설계한 경우
2. 하나의 엔터티는 하나의 주제로 구성되었는가?
   • 한 엔터티에 여러 성격의 데이터가 혼재해서는 안 된다.
3. 유사한 성격의 데이터인데 개별적인 엔터티에서 관리하고 있지 않은지?
   • 유사한 데이터가 여러 엔터티에 존재하는 것은 특별한 이득이 없으므로 엔터티 통합을 기본 원칙으로 검증해야 한다.
   • 유사한 성격의 엔터티를 찾는 방법
     • 엔터티 명으로 정렬하기
     • 애플리케이션과 비교하기(애플리케이션 명으로 정렬)
     • 모델의 모양을 살펴보는 방법(유사한 구조가 반복되는지)
4. 필요한 단어만을 사용해서 엔터티 명을 구체적으로 붙였는지?
   • 엔터티 명을 보고 어떤 데이터를 관리하는 엔터티인지를 알 수 있도록 가능한 구체적이어야 한다.
   • 확장성을 고려해서 유연하게 엔터티 명을 정했는지 검토해야 한다.
   • 엔터티 명에 필요 없는 단어는 생략해야 한다.
   • 서브타입 엔터티 명은 슈퍼타입 엔터티 명을 차용해야 한다. 
5. 엔터티 명이 주 식별자와 한 쌍이 되도록 붙였는지?
   • 엔터티 명은 주 식별자와 한 쌍처럼 잘 어울려야 한다.
   • 엔터티 명과 주 식별자를 엑셀로 뽑아서 서로 어울리는지 검토해보는 것은 좋은 방법이다.
6. 엔터티 설명이 존재하며 간결하고 명확한가?
   • 엔터티 설명은 반드시 기술하는 것이 원칙이다.
   • 엑셀에 엔터티 명과 엔터티 설명만을 뽑아서 검토하는 것도 좋은 방법이다. 모델러는 엔터티 명과 설명만을 보고도 해당 엔터티를 충분히 설명할 수 있어야 한다.
7. 업무 식별자가 존재하는가?
   • 주 식별자가 존재하지 않는 엔터티는 있을 수 있지만 업무 식별자가 존재하지 않는 엔터티가 있어서는 안 된다.
8. 이력 데이터를 관리하는 엔터티가 맞는지?
   • 이력 엔터티는 우선 엔터티 명이 '~이력'으로 끝나야 한다.
   • 이력 데이터와 내역 엔터티를 구분해야 한다.(추후 6.2장에서 설명 예정)
   • 이력 엔터티가 맞는지를 검증하는 가장 간단한 방법 → 주 식별자에 변경일자나 종료일자 속성이 있는지를 확인할 것
   • 실체 엔터티라면 원천 엔터티와 이력 엔터티를 별도로 관리하는 것이 좋다.
   • 주 식별자에 '~순번' 속성을 사용한 이력 엔터티도 별도 검토가 필요하다.
9. 일대일 관계의 두 엔터티를 합체할 수는 없는가?
   • 이유 없이 엔터티가 늘어나는 것은 바람직하지 않기 때문에 성능/관리 문제가 없다면 합체할 것을 고려한다.
10. 종속 관계 엔터티의 주 식별자 상속이 적절한가?
    1. 종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속한다. 식별자로 상속한 관계만 뽑아서 종속 엔터티인지를 검토하는 것도 유용한 검증 방법이다.
11. 데이터 인스턴스가 하나뿐인 특수 엔터티가 있는가?
    • 인스턴스가 하나뿐인 엔터티는 흔치 않다. 이런 엔터티가 반드시 잘못된 것은 아니지만, 재차 확인해 볼 필요는 있다.
    • 업무 요건에 의해서 하나의 인스턴스만 발생하는 엔터티는 정상적인 엔터티이기 때문에 이를 금지하는 것은 바람직하지 않다.
12. 주 식별자가 존재하지 않는 엔터티가 있는가?
    • 주 식별자가 없다고 반드시 잘못된 엔터티는 아니지만, 주 식별자가 없는 엔터티를 뽑아서 다시 검토해야 한다.
13. 주 식별자가 동일한 엔터티가 있는가?
    • 성능이나 관리 측면에서 엔터티를 분해한 일대일(1:1) 관계나 슈퍼타입/서브타입 관계 등을 제외하고, 엔터티의 주 식별자가 같은 엔터티는 주 식별자를 검토해 볼 필요가 있다.
    • 업무 식별자를 근간으로 주 식별자를 설계했다면 주 식별자가 동일한 엔터티가 존재하면 안 된다.
14. 엔터티의 의미를 쉽게 설명할 수 있는가?
    • 모델러는 스스로 설계한 엔터티와 속성을 쉽게 설명할 수 있어야 한다.
15. 외부/복제 엔터티의 엔터티 명과 주 식별자가 원천 엔터티와 같은가?
    • 외부 엔터티나 복제 엔터티는 원천 엔터티와 엔터티 명과 주 식별자가 동일해야 한다.

 

1.28 데이터 모델 설계 원칙

모델링 수행 시 고려해야 할 우선순위

• 데이터 무결성
• 데이터 성능 - 데이터를 빨리 처리(입력/조회)하는 것을 의미
• 관리 효율성 - ERD나 DB 관리를 효율적으로 하는 것을 의미
• 사용 편의성 - 개발하기 편하도록 설계하는 것을 의미

데이터 모델 설계 시 고려해야 할 설계 원칙

1. 정체성
   • 데이터 성격에 맞는 정체성이 뚜렷한 엔터티를 설계하는 것은 데이터 모델 설계의 중요한 원칙이다.
   • 모델이 전반적으로 잘못 설계된 경우, 주요 엔터티의 정체성이 불분명할 때가 많다.
2. 통합성
   • 유사한 성격의 데이터는 통합하는 것이 데이터 모델링의 주요 원칙이다.
   • 데이터를 통합하여 서브타입으로 설계하면 데이터를 효율적으로 관리할 수 있고 가독성이 좋아진다.
3. 유연성
   • 유연한 모델 = 확장하기 수월한 모델
   • 데이터를 통합할수록 모델은 유연해진다.
   • 엔터티가 정규화될수록 모델은 유연해진다.
4. 무결성
   • 무결성은 데이터에 결점이 없는 상태를 의미한다.
   • 엔터티에 주 식별자가 없다면 무결성을 지키기 어렵다.
   • 참조 무결성이 없어도 무결성을 지키기 어렵다.
   • 무결성을 지키기 위해서는 중복 데이터를 배제하는 것이 좋다.
5. 가독성
   • 가독성은 데이터베이스와는 무관한 것이기 때문에 가볍게 여기는 경향이 있지만 바람직하지 않다.
   • 가독성을 높이는 방법으로는 관계선이 겹치지 않도록 하는 것, 서브타입을 표현하는 것, 재취 관계나 배타 관계를 표현하는 것 등이 있다.
6. 업무 연관성
   • 업무 요건에 맞는 모델을 설계하기 위해서는 업무 식별자를 제대로 도출하여 엔터티를 분명히 설계해야 한다.
7. 성능 효율성
   • 성능 문제는 요건별로 검토하는 것이 바람직하다.
   • 어떤 요건은 데이터를 통합하고 정규화를 해야 성능이 좋아질 수 있다. 대부분의 요건은 적절한 비정규화를 통해 성능을 극대화할 수 있다.
8. 관리 효율성
   • ERD가 제대로 관리될 수 있도록 설계하는 것도 원칙이다.
   • ERD 관리 측면에서 고려해야 할 것은 엔터티 개수다. 엔터티가 최대한 늘어나지 않는 방향으로 설계하는 것이 좋다.
9. 표준화
   • 표준 지침을 메타 시스템에 적용하여 속성 명을 일관되게 사용해야 한다.
   • 데이터 표준 지침이 있어야 하며, 표준 관리 체제를 따라서 표준 데이터를 관리해야 한다.
10. 데이터 보안 대비
    • 데이터 보안은 대부분 DBMS 차원의 이슈가 있으며 데이터 모델링 차원의 이슈는 드물다. 하지만 모델링할 때는 암호화 대상 속성을 주의해야 한다.(ex. 주민등록번호)
    • 암호화 대상 속성을 주 식별자로 사용하면 안 된다.

 

1.29 무결성에 대해서

무결성: 데이터 값이 완전하고 정확한 상태를 의미

정합성: 데이터들이 서로 일관되게 일치해야 한다는 의미

 

데이터베이스 차원에서 지켜야할 무결성의 종류

1. 엔터티 무결성
   • 엔터티에 존재하는 모든 인스턴스는 고유해야 하며, 널 값을 가지면 안 된다는 것 → 엔터티에는 동일한 주 식별자 값이 존재할 수 없으며, 주 식별자 속성은 널값을 허용할 수 없다.
   • 엔터티 무결성을 지키기 위한 핵심은 식별자이다.
     • 업무 식별자: 논리적으로 엔터티 무결성을 만족(유니크 인덱스 생성)
     • 주 식별자: 물리적으로 엔터티 무결성을 만족(PK 생성)
2. 참조 무결성
   • 엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 널 값이어야 한다는 것 → 외래 식별자 속성 값이 상위 엔터티의 인스턴스에 반드시 존재하거나 널이어야 한다.
   • 참조 무결성은 관계형 데이터베이스에서 절대적으로 필요한 중요한 요소이며, FK 제약으로 지켜진다.
3. 도메인 무결성
   • 엔터티 무결성이 식별자와 관련된 제약이고 참조 무결성이 관계와 관련된 제약이면, 도메인 무결성은 속성과 관련된 제약이다.
   • 엔터티의 특정 속성 값은 같은 데이터 타입과 길이, 같은 널 여부, 같은 기본 값, 같은 허용 값 등 동일한 범주의 값만이 존재해야 한다. (ex. 고객이름 속성에 123 이런 데이터 들어가면 안 됨)
4. 업무 무결성
   • 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미(ex. 주문 금액이 3만 원 이상이면 배송비가 무료이다.', '초회 보험료를 입금하지 않은 보험 계약은 효력이 없다')
   • 업무 무결성은 범위가 넓어 주로 프로그램에서 점검한다. (ex. 트리거)

 

1.30 성능에 대해서

성능의 두 가지 종류

• 조회 성능(Select)
• 쓰기 성능(Insert/Update/Delete)

소량의 데이터에 대한 조회 성능은 주로 인덱스로 해결하며, 대량의 데이터에 대한 조회 성능은 스캔 방법과 조인 방법을 사용해서 해결할 수 있다.

조회 성능은 데이터 블록과 밀접하게 연관돼 있다. 대부분의 DBMS는 데이터를 블록 단위로 메모리에 올려서 읽는다. 따라서 해당 데이터가 메모리에 이미 존재하면 빠르게 읽을 수 있다. 몇 블록을 읽느냐가 조회 성능에 가장 크게 영향을 미치는 요소다. 그런데 이는 조인과 무관하지 않다.

엔터티를 물리적으로 분리해서 만들면(엔터티를 정규화하면) 저장소인 블록도 물리적으로 서로 분리된다. 분리된 데이터를 한 번에 조회하는 요건(쿼리)이 있다면 여러 블록에서 데이터를 가져와야 하므로(여러 블록을 조인해야 하므로) 조회 성능이 떨어지게 된다.

중복 데이터를 사용하면 조회 성능이 향상되지만, 반대로 쓰기 성능은 저하된다.(ex. 고객명이 바뀌게 되었을 때 여러 엔터티에 업데이트를 해야하는 경우) 많은 업데이트는 데이터 정합성을 떨어뜨린다.

정규화를 할수록 엔터티가 분해되기 때문에 많은 조인이 생겨 조회 성능이 나빠지는 반면에, 중복 데이터를 사용하면 많은 인서트/업데이트가 생겨 쓰기 성능이 나빠진다. 물론 쓰기는 조회와 비교하면 빈도수가 적다는 점은 참고할 사항이다.

조회 성능 문제는 화면의 종류에 따라 달리 검토할 수 있따. 해당 엔터티의 조회 요건이 주로 목록(리스트)인지 명세(상세)인지를 확인한 후, 목록 위주라면 비교적 많은 건수가 조회될 수 있어 조회 성능 문제를 적극적으로 고려해야 한다. 만약 명세 위주라면 주로 한 건의 데이터만을 조회하는 것이므로 데이터 무결성만을 고려한다.

또한 고려해야 할 요소는 화면 구성이다. 데이터를 화면에 횡으로 이어서 보여주는지 종으로 떨어뜨려서 보여주는지에 따라 모델 설계가 달라질 수 있따. 화면이 횡으로 구성됐다면 비정규형을 고려하고, 종으로 구성됐다면 정규형으로 설계해야 한다. 최근에는 데이터양도 많아지고 집계에 대한 다양한 요구 사항이 존재해서 화면에 딸느 비정규형 채택을 심도 있게 고려하게 된다.

이렇게 화면을 고려할 때는, 화면의 중요도와 사용 빈도까지 고려해야 한다. 어떤 화면이 중요하게 사용되는지, 자주 사용되는지에 따라 전략이 달라질 수 있다. 동일한 데이터가 여러 화면에서 사용될 수 있기 때문에 특정 화면의 조회 성능을 위해 다른 화면의 조회 성능을 희생하는 것이 될 수도 있다. 만약 어떤 화면에서 사용하는 조회 성능을 획기적으로 개선했지만, 그 화면보다는 다른 화면이 더욱 중요하다면 전략을 잘못 세운 것이다. 화면의 중요도와 사용 빈도, 성능 이슈의 강도 등을 고려해서 전략을 세워야 한다.

성능 검토는 정규화를 한 상태에서 해야 한다는 점을 주의해야 한다. 성능 문제가 예상돼 먼저 비정규형으로 설계하고 추후 검토하는 방법은 잘못된 접근이다. 성능을 위해 정규화라는 관계형 모델링 원칙을 깨고 비정규형을 사용하는 것이 데이터 무결성을 지키는 것만큼의 가치가 있는지에 대한 검토 또한 필요하다. 부정확한 데이터를 빠른 성능으로 보여준다면 가장 치명적일 것이다.