1.1. 집합(Set)과 엔터티(Entity)

• 집합과 엔터티는 닮았다, 엔터티도 집합처럼 기준이 명확해야 함

• '우승해본 팀의 집합' 을 자세히 표현한 릴레이션

• • 집합의 원소(예:삼성)는 릴레이션의 인스턴스를 상징함
  • 원소가 서로 명확히 구별돼야 집합이 됨 → 엔터티에서 인스턴스는 유일하게 구별돼야 함
  • 식별자(Identifier)로 인스턴스를 유일하게 구별할 수 있음

1.2. 엔터티에 대한 서설(序說)

• 업무에서 관리하고자 하는 데이터(속성)를 함수 종속으로 도출한 결과 집합이 엔터티
• 엔터티 설계 시 판단 기준
  • '관리하고자 하는 데이터 인가?' : 현업의 판단 + 모델러의 판단
  • 엔터티와 주 식별자는 한 몸
  • 엔터티를 속성/관계와 혼동 금지
  • 엔터티는 모델링의 시발점 (중요)
  • 함수종속 개념 이해 필요 (통찰력)

1.3. 엔터티 정의(Definition)가 왜 중요한가?

• 식별자가 무엇이고 서브타입이 무엇인지를 밝히는 것
• 엔터티 정의가 명확해야 엔터티 설명이 정확해짐
• 엔터티 설명(Explanation)은 엔터티 정의(Definition)에 종속됨

• 잘못된 엔터티 정의(Definition)
  • 엔터티 정의 자체가 틀림 ('가' 를 'A' 로 정의)
  • 한 엔터티에 여러 집합이 존재하도록 정의 ('가' 엔터티에 'A' 도 함께 존재)

• 엔터티 정의의 중요성
  • 엔터티는 모델링의 시발점
  • 잘못된 엔터티 정의 이후 모델링 단계는 의미가 없음
    • 명확하지 않은 모델은 힘들게 오래 일하게 되는 원인임
    • 잘 설계된 데이터 모델 → 경영 혁신의 한 부분

1.4. 엔터티 분류법

• 다양한 엔터티 분류법 (분류가 목적이 아니며, 다양하게 분류 할 수록 엔터티 성격이 명확해 짐)
  • 만질 수 있는 것 & 만질 수 없는 것
  • 자립 엔터티 & 종속 엔터티
  • 원천 데이터 & 가공 데이터
  • 실체 엔터티 & 행위 엔터티 & 가공 엔터티 & 기준 엔터티
  • 내부 생성 엔터티 & 외부 생성 엔터티
  • 엔터티 유형에 의한 기본 / 내역 / 상세 등의 엔터티

1.5. 엔터티 정의 방법. 보이는 것인가?

• 필자는 엔터티 분석 설계 시 가장 먼저 엔터티의 관리 대상이 보이는지 판단
  • 보이면 실체 엔터티 (고객, 노트북, 상품, 자동차...)
  • 대상의 개수 = 엔터티의 인스턴스 개수
  • 많지 않으나 핵심 데이터일 가능성이 큼

• 보이지 않는 추상적인 것의 집합(개념적, 많다, 어렵다)
  • 연상이 되는것 : 주문과 같은 행위(行爲)
  • 연상이 안 되는것 : 환율과 같은 개념(槪念)

• 엔터티 분석/설계 시 실제로 보이는 데이터와 개념으로 존재하는 데이터를 명확히 구분하는 게 시발점이 될 수 있음

1.6. 엔터티 정의 방법. 스스로 존재하는가? 자립 엔터티와 종속 엔터티

• 필자는 엔터티 분석 설계 시 다음으로 스스로 존재할 수 있는지 판단

• 예) 엔터티 B가 존재하기 위해 엔터티 A가 반드시 존재해야 함
  • B는 A에 존재 종속(Existence Dependency)됨
  • 엔터티 B는 종속 엔터티
  • 엔터티 A는 자립 OR 종속 엔터티

• 다른 엔터티에 존재 종속된 종속 엔터티는 종속 관계와 같은 개념으로 많지 않음 (대부분 참조 관계만 존재)

• 업무에 따라 자립/종속 엔터티가 결정됨
  • 예) 교수 엔터티
    • 대학의 교수만 관리하는 경우 → 자립 엔터티
    • 전국 대학의 교수를 관리하는 경우 → 종속 엔터티

• 고객 엔터티는 자립 엔터티

그림 1.2 자립 엔터티인 고객 엔터티

• • 직업 엔터티가 없어도 존재 가능, 참조 관계(Referential Relationships)
  • 상위 엔터티인 직업 엔터티의 직업번호 가 일반 속성으로 상속됨

• 종속 엔터티는 부모 엔터티와 종속 관계가 있는 엔터티임
  • 부모 엔터티의 인스턴스가 삭제되면 종속 엔터티의 인스턴스도 삭제됨 : 존재 종속(Existence Dependency)

• 자립/종속 엔터티 분석은 관계를 고려한 분석이므로 엔터티 성격 파악에 도움이 됨
  • 엔터티 정의, 주 식별자, 관계 정의, 식별자 상속 등과 같은 복잡한 문제가 풀리기도 함

1.7. 종속 엔터티의 종류

• 부모 엔터티의 부가 데이터를 관리하는 엔터티

그림 1.3 부가 데이터를 관리하는 종속 엔터티

• • 상품 가격은 상품 없이 존재 불가, 부모 엔터티의 일부 성격

• 1정규화에 의해서 발생한 엔터티

그림 1.4 1정규화에 의한 종속 엔터티

• • 주문상품 엔터티는 주문 엔터티 없이는 존재 불가

• 이력 데이터를 관리하는 엔터티

그림 1.5 이력 엔터티인 종속 엔터티

• • 상품가격이력 엔터티는 원천 엔터티인 상품 엔터티 없이 존재 불가
  • 부모 엔터티와 종속 엔터티의 관계가 일대다(1:M)일 때는 보통 부모 엔터티의 주 식별자를 종속 엔터티의 식별자로서 상속 하고 자식 엔터티의 부분 주 식별자(Partial Primary Identifier)와 결합하여 주 식별자가 됨

• 다대다(M:N) 관계에서 발생한 교차 엔터티

그림 1.6 교차 엔터티인 종속 엔터티

• • 다대다(M:N) 관계는 보통 두 개의 일대다(1:M) 관계로 표현되면서 종속 엔터티가 생김
  • 교차 엔터티(Association Entity, Relationship Entity, Intersection Entity)

• 슈퍼타입에 대한 서브타입 엔터티

그림 1.7 서브타입인 종속 엔터티

• • 서브타입인 개인고객/법인고객 엔터티는 슈퍼타입 고객 엔터티의 종속 엔터티임

• 엔터티 분해에 의한 일대일(1:1) 관계의 엔터티

그림 1.8 일대일 관계의 종속 엔터티

• • 다시 합쳐도 문제 없음
  • 고객상세 엔터티는 고객 엔터티 없이 존재 불가

1.8. 모델(erd)과 메타 시스템의 속성 설명

종속 엔터티

그림 1.9 종속 엔터티

• 엔터티와 속성 정보를 메타 시스템에서 관리할 때 사용되는 엔터티의 예제
• 엔터티번호 속성을 식별 관계로 상속 받음

관계 엔터티

그림 1.10 교체(관계) 엔터티

• 엔터티와 속성을 개별적인 독립 실체로 관리
• 교차(관계) 엔터티를 통해 엔터티에 속한 속성을 관리
  • 엔터티속성관계.속성순서 속성은 엔터티 내 순서를 의미
• 속성은 엔터티에 존재 종속(Existence Dependency)된 식별 관계가 아니고 단지 관계의 존재임
  • 물론 엔터티-엔터티속성관계, 속성-엔터티속성관계는 종속 관계임

1.9. 엔터티 정의 방법. 원천 데이터인가?

• 엔터티 분석/정의 시 엔터티에서 관리하려는 데이터가 원천 데이터인지 가공 데이터인지를 구분하는 것도 엔터티를 제대로 이해하는데 도움이 됨

• 중복 데이터도 가공 데이터에 포함됨
  • 집계, 요약, 임시, 작업용 데이터

• 가공 데이터는 주로 업데이트가 발생하지 않음 (원천이 바뀔 경우 업데이트 발생)
• 원천 데이터는 엔터티 간의 참조 무결성(Referential Integrity) 관계가 존재
  • 원천-가공, 가공-가공 엔터티 간은 그렇지 않음 (연관성 있으나 참조 무결성은 아님)
  • 가공 엔터티는 보통 디멘젼(Dimension) 역할을 하는 엔터티와만 관계 발생
  • 원천 엔터티중 기준 엔터티는 참조 무결성 관계가 없음
  • 원천 엔터티는 활발한 관계(참조 무결성) 과 가공 엔터티로 재사용 되는점을 고려해서 특별히 잘 설계 해야 함
    • 정규화를 철저히 수행해야 함 (데이터 본래의 성격을 정의 하고 이해하는 과정)
    • 주 식별자는 주로 업무 식별자(Business Identifier)가 됨

• 백업 데이터
  • 원천 데이터로 정의 : 원본 삭제시 (원천 엔터티 - 백업 엔터티 간 참조 무결성 없음)
  • 가공 데이터로 정의 : 원본 유지시

• 외부 데이터
  • 외부 데이터가 원천/가공 여부에 관계 없이 받은 시스템에서는 원천 데이터
  • 기업 내의 다른 시스템은 판단 기준 필요 (예: 데이터베이스)
  • 외부 데이터를 직접 입력(Key-In)한 경우 원천 데이터 (새롭게 생성한 데이터)

• 뷰(View)
  • 단순한 SQL 은 가공 데이터가 아님
  • 실체화된 뷰(Materialized View)는 가공 데이터로 봄

• 가공 엔터티에 사용된 값
  • 원천 엔터티의 값이 바뀌면 수정 필요 (정합성 유지)
  • 정합성 유지 방법
    • 원천 데이터 수정 시 실시간 동기화
    • 특정 시간에 배치로 동기화

• 가공 데이터(엔터티,속성)에 대한 설명(Explanation)
  • 원천 엔터티 기술 (대상, 생성 방법, 정합성 구현 방법)

1.10. 데이터 본질에 따른 엔터티 분류법(실체/행위/가공/기준)

• ASIS 엔터티를 분석하는 상향식(Bottom-Up) 방법으로 모델링 수행시 단계적 접근을 위해 기존 엔터티 분류가 의미 있음

• 필자는 업무에서 핵심적으로 사용하는 소수의 실체/행위 엔터티만 분류 함
  • 분류는 부가적인 것일 뿐이며 본질적인 것은 아님 (엔터티의 정의가 중요 함)

• 보통 기준/실체 엔터티를 먼저 설계 하고 가공 엔터티를 마지막에 설계 함
• 최소화 해야 하지만, 간혹 어디에도 들어가지 못하는 엔터티도 있음
• 분류는 데이터의 정체성을 생각하도록 하기 때문에 오랫동안 연습하면 엔터티 설계에 대한 자신감이 생긴다

1.11. 실체 엔터티란?

• 실체 엔터티는 본질적이며 만질 수 있는 것을 관리하는 엔터티
• 이름, SSN, 나이 등 실체의 존재(Existence)와 연관된 데이터를 관리
  • 실체가 발생시킨 데이터를 관리하는 엔터티는 아님 (실체의 계약, 불만, 출금 등)
  • 실체와 실체의 역할 혼동 하면 안됨 (사원 과 정규직,계약직)

• 대부분 가장 상단에 위치하며 업무적 영향도가 큼 (실체→행위→가공)
• 주 식별자는 단순해야 좋음 (고객번호와 같은 인조 식별자는 효과적)
• 본질을 관리 하므로 과감한 통합으로 전체 모델 구조를 단순하게 만들어야 함 (단순한 모델 → 좋은 모델)
• 물리적으로 존재하는 실체를 하나의 인스턴스로 관리 하므로, 이력 데이터를 실체 데이터에 포함하면 안됨

• SSN 변경시 아래와 같이 두 개의 인스턴스로 관리하는 것은 옳지 않음 (실제 고객 수 != 고객 엔터티의 인스턴스 수)

그림1.11 실체 엔터티

• 실체 엔터티를 내역 엔터티인 것처럼 잘못 설계한 릴레이션

• 아래와 같이 이력 엔터티를 별도 관리 하는 것이 옳음 (실제 고객 수 = 고객 엔터티의 인스턴스 수)

그림1.13 실체 엔터티와 이력 엔터티를 분리한 모델

• 실체 데이터는 주로 행위에 의해서 생긴다.
  • 펀드 계약 후에 펀드 계좌가 생김
  • 원인(계약)과 결과(계좌)를 별도로 관리하지 않고 하나의 데이터로 본다면 결과(계좌)를 관리하는 것이 바람직

1.12. 행위 엔터티란?

• 모델링 시 가장 많은 시간이 소요된다.
  • 많은 엔터티가 행위 엔터티다.
  • 관리하는 속성도 대부분 많다.

• 대부분 업무 식별자를 사용하기 때문에 주 식별자가 복잡하다
  • 업무 식별자 도출 : 누가/무엇을/언제/어떻게/어디에서 했는지 분석
  • 하위 엔터티가 적음 → 인조식별자 안씀

• 관계도 복잡하다
  • 고객/계좌/부서/사원/상품 등과 같은 다양한 실체 엔터티와 관계가 발생
  • 생성 순서에 의해 행위 엔터티와의 관계도 발생, 기준 엔터티와도 관계 발생
  • 일반적으로 가공 엔터티와 관계는 없어야 함

• 상위 실체 엔터티와 조인을 피하고자 속성을 중복시켜 놓을때가 많다.
  • 반대로 실체 엔터티도 유사한 현상이 있음 (하위 행위 엔터티에서 여러 인스턴스를 추출해 가져다 놓음)
  • 추출/중복 속성은 가능한 사용하지 않아야 함

• 업무 식별자를 명확히 한 후 최대한 통합 하는 것이 좋다.

1.13. 가공 엔터티란?

• 조회 시간 단축 목적으로 DW 시스템의 집계 엔터티로 가장 많이 사용 됨
• 집계 속성 관련하여 기초 속성이 무엇이냐에 따라 그 엔터티의 성격이 정해진다.
  • 기초 속성이 일반 속성이며, 일부 속성이 집계 속성인 경우 (고객 엔터티에 포인트 총합 속성이 존재 → 가공(집계) 엔터티 아님)
  • 기초 속성이 집계 속성이며, 일부 속성이 일반 속성인 경우 (포인트 총합, 사용 포인트 총합등을 관리하는 엔터티에 고객명 속성 존재 → 실체 엔터티 아님)

• 작업용 엔터티
  • 처리 예정 내역등 업무 처리 대상 한정 목적
  • 어떤 데이터의 부분집합 별도 보관, 조회 성능 고려한 엔터티 복사
  • 없다고 가정하고 설계 하는등, 제거 고려 필요

• 디멘젼(Dimension) 역할 엔터티 와의 관계만 존재
• 주 식별자는 집계하려는 기준을 의미
• 늘어가는 집계 요건과 데이터 정합성을 위해 통합을 고려 해야 함

• 가공 엔터티는 원천 엔터티보다 숫자가 월등히 많다.
  • 원천 엔터티를 다양하게 가공, 같은 데이터를 화면에 따라 엔터티 분리, 사용자가 달라지거나, 작업의 편의성을 위해 중복

• 가공 엔터티 증가 원인
  • 원천 데이터를 중요시 하기 때문에 가공 엔터티는 신경을 덜 쓰게 됨
  • 프로젝트 후반에 일정/시기 등의 현실적인 이유로 충분한 분석이 부족

1.14. 기준 엔터티란?

• 개념적인 것을 관리 하나, 실체 엔터티와 여러 면에서 유사
• 통합 (기준 : 하나만 존재)
  • 데이터 통합 (A부서의 환율 엔터티, B부서의 환율 엔터티)
  • 구조 통합 (업무의 기준이 되는 금액/날짜 등을 하나의 엔터티에서 통합 관리)
• 기준 엔터티를 제대로 설계하면 실체/행위 엔터티의 데이터 품질이 좋아진다.

1.15. 엔터티 정의 방법. 데이터 생성에 따른 분류법

생성 위치

• 내부 데이터(Internal Data)
  • 값의 정합성 결정 가능
  • 중복 데이터 배제, 완전 정규화된 관계형 데이터 모델에 저장

• 외부 데이터(External Data)
  • 받은 값 그대로 관리
  • 받은 그대로 저장(전문) 혹은 관계형 데이터 모델에 저장
    • 데이터를 사용 하기 위해서는 정규화된 모델에 저장 하는 것이 바람직
    • 실무에서는 전문을 파싱하여 저장하고, 동일한 엔터티를 업무에서 사용하기 위해 생성
      • 데이터는 한 번만 존재해야 하므로 지양해야 한다.

• 내부/외부 기준 : 회사/시스템, 일관성이 중요

생성 방법

• 화면 입력(Key-In)
  • 외부 고객이나 내부 사용자가 주체, 정규화 대상

• 배치(Batch)
  • 하나의 엔터티로 해결하려 함(X) → 정규화 필요
  • 외부로 보내는 데이터는, 필요한 데이터만 뽑아서 보관하기 위해 비정규형과 데이터 중복이 자주 사용됨
  • 대량 배치 / 개별 배치 (전문 실시간 처리, 트리거)

1.16. 엔터티 정의 방법. 엔터티 유형에 따른 분류법

• 엔터티를 분석하고 정의하는 데 사용 : 기본/상세/내역/이력/코드/관계/집계/백업/임시
• 문제점
  • 기준을 명확하게 적용하기 어렵다
  • 유형을 엔터티명의 접미어로 사용한다

기본 엔터티

• 실체 엔터티와 같음
  • 엔터티에 저장하는 데이터가 실제 물체를 의미하는 데이터

• 실무에서 중요 엔터티를 기본 엔터티로 분류하기도 함
  • 중요 엔터티에 대한 기준이 불명확 하고, 성격을 나타내지 않음

• 기본 엔터티를 숫자로 제한 하기도 함
  • 역시 기준이 명확하지 않음
  • 균등 배분 하는 분류 기본 원칙에도 위반

내역 엔터티

• 행위 엔터티와 유사
  • 활동이나 행위에 의해 발생한 데이터를 관리하는 엔터티

• 기본/내역 엔터티 구분 (보험계약 엔터티)
  • 보험계약기본 : 행위의 결과 중점
  • 보험계약내역 : 계약 행위에 중점
  • 접미사를 뺀 "보험계약"이 오히려 의미 명확

• 한번만 신청할 수 있는 ~신청 엔터티
  • ~신청기본 : 행위의 결과 중점
  • ~신청내역 : 신청 행위에 중점

상세 엔터티

• 기본/내역 엔터티와 혼동되는 가장 혼란스러운 엔터티
• 일대일(1:1) 관계의 두 개의 엔터티로 분해할 때의 하위 엔터티 의미
• 중요 속성이 아닌 속성 관리 (기본 정보는 상위 엔터티, 상세 정보는 하위 엔터티) → (주식종목기본, 주식종목상세)
• 논리적인 기준을 정해도 들어 맞지 않는 엔터티 있으며 실무에서 상세 엔터티에 대한 논란이 빈번하다.

이력 엔터티

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

코드 엔터티

• 코드명과 코드값을 관리하는 엔터티
• 통합 코드 엔터티에서 통합 관리 함, 개별 코드 엔터티는 거의 없음

관계 엔터티

• 교차 엔터티의 일종, 소수
• 내역/기본 엔터티와 구분이 쉽지 않다

집계 엔터티

• 엔터티 성격 파악이 부족해 기본/내역 엔터티와 혼용 되기도 함
  • 집계한 속성이 주요 속성이면 ~집계 엔터티로 결정
  • 내역 엔터티를 집계 했기 때문에 상세 데이터로 판단해 _내역/상세로 정해지면 안됨
  • 실체를 기준으로 집계 했기 때문에 ~기본 으로 정해지면 안됨

백업 엔터티

• 원천 엔터티의 데이터를 백업한 엔터티 (중복 데이터 엔터티와 다름)
• 백업 엔터티와 원천 엔터티를 합치면 전체가 됨

임시 엔터티

• 사용한 후에 삭제하는 데이터
  • 트랜잭션 종료시 삭제
  • 매일 삭제

정리

• 기본/상세/내역/이력/코드/집계/백업/임시 엔터티 구분은 기준이 명확해야 한다.
• 이 분류법은 내역vs이력 결정과 같은 소모적인 논란 발생 가능
• 데이터 자체가 모호한데 이를 하나로 구분해 마치 명확한 것처럼 하는것은 모호한 채로 있는 것보다 좋지 않다.
• 물리명이 영향 받을 수 있음 : '~기본' 엔터티의 테이블명에 '~BS' 사용, 엔터티명 변경 된다면 원칙 위배됨
• 명확하게 정하기 어려운 엔터티가 다수 존재 하며 이는 좋은 분류법이 아님

1.17. 교차 엔터티(Association Entity)란?

• 교차 엔터티(Association Entity, Relationship Entity, Intersection Entity)는 다대다(M:N) 관계에서 발생한 엔터티다.
• 관계 엔터티와 일부 내역 엔터티가 교차 엔터티에 해당 됨

그림 1.15 다대다(M:N) 관계
그림 1.14 교차 엔터티

• • 주문상품 엔터티는 주문 엔터티와 상품 엔터티의 다대다(M:N) 관계에서 발생한 교차 엔터티
  • 다대다(M:N) 관계는 물리 모델에서 구현 불가능 하므로 가능한 빠른 단계에서 두개의 일대다(1:M) 관계로 설계

• 교차 엔터티 종류
  • 행위 엔터티 : 다대다(M:N) 관계를 관리하는 전형적인 교차 엔터티 (그림 1.14)
  • 관계 엔터티 : 관계를 관리하는 엔터티 (그림 1.16, 1.17)
    • 보험계약관계인 엔터티는 관계 엔터티며 관리 속성이 많지 않은 특징이 있음

그림 1.16 관계를 관리하는 교차 엔터티

• • • 입고별출고 엔터티는 특정 상품의 입고별 출고 수량을 관리

그림 1.17 매핑 관계를 관리하는 교차 엔터티

• • • • 언제 입고된 것이 출고됐는지 알 필요 없다면 입고별출고 엔터티는 불필요
    • 릴레이션

[입고]

[출고]

[입고별출고]

• • BOM(Bill Of Materials) 엔터티

그림 1.19 다대다 순환 관계에 의한 교차 엔터티

• • • 사원 엔터티에서 발생한 다대다(M:N) 순환 관계를 교차 엔터티로 설계한 모델
    • 다대다(M:N) 순환 관계는 역할(Role)을 관리하는 모델에서 주로 발생
    • 릴레이션
      • 한 사원의 멘토 사원은 여러명 가능, 한 사원은 여러 사원의 멘토 사원 가능
      • 홍길동의 멘토는 김길동/박길동, 홍길동은 이길동/최길동의 멘토

[사원]

[관계사원]

• 3개체 관계(Ternary Relationship)

그림 1.21 3개체 관계에 의한 교차 엔터티

• • 수강신청 엔터티는 학생과 교수와 과목과의 관계를 관리하는 교차 엔터티

• 교차 엔터티의 명명법
  • 교차 엔터티의 엔터티명은 일반적으로 양쪽 부모 엔터티와의 연관성을 표현해야 함
  • 교차 엔터티 이름은 다대다 관계명으로 적합해야 함

그림 1.22 다대다 관계의 관계명
그림 1.23 다대다 관계명과 동일한 교차 엔터티명

• • 매핑 + 다른 요건 (사원메뉴, 사원메뉴권한)

그림 1.24 주 식별자를 매핑한 교차 엔터티명
그림 1.25 부가 데이터를 관리하는 교차 엔터티명

• • 관계를 관리하는 관계 엔터티명 (보험계약관계인)

그림 1.26 관계 엔터티명

• • 다대다(M:N) 관계명이 행위를 나타낼 때

그림 1.27 다대다 관계

• • • 다대다(M:N) 해소 필요 (주문)

그림 1.28 다대다 관계가 생긴 교차 엔터티

• • • 다대다(M:N) 또 해소 필요 (주문상품)

그림 1.29 다대다 관계가 없는 엔터티

• • • • 다대다(M:N) 관계가 존재하지 않는 최종 모델

1.18. 엔터티 설계 원칙

데이터 정체성

• 엔터티를 명확하게 정의(Definition)하는 것은 데이터 모델링에서 가장 중요함
• 여러 데이터가 혼합된 형태의 엔터티는 대신 뷰를 사용해야 함
• 불명확한 엔터티로 확장성과 업무 파악에 문제가 생기게 됨
  • 비슷한 엔터티 새로 만들기 → 시스템 누더기화 → 데이터 정합성 저하 → 유지보수 어려움 ...

엔터티 무결성

• 주 식별자가 존재하도록 엔터티 설계
• 물리적인 PRIMARY KEY 는 물론이고, 인스턴스를 식별할 수 있는 식별자(Identifier) 필요

엔터티 유일성

• 통합을 통해 같은 성격의 데이터는 전사적으로 유일 해야 함

데이터 혼용 배제

• 하나의 엔터티에서 서로 다른 성격의 데이터 혼용 금지 (정체성 확보)

타 엔터티와 관계 존재

• 표현상의 약속을 제외하고, 다른 엔터티와 관계가 있는것이 일반적
• 가공/기준 엔터티 예외

프로세스 도출 지양

• 데이터 성격을 기준으로 엔터티 도출하고 프로세스는 속성으로 표현
• 프로세스에 따라 엔터티를 도출하면 프로세스 변화에 유연하지 못하게 엔터티나 관계가 영향받게 됨
• ||그림 1.30 프로세스(상태)에 따라 엔터티를 설계한 모델||

• • 비품을 요청, 승인, 계약 하는 프로세스를 보여주는 모델
• ||그림 1.31 프로세스(상태)가 생길 경우의 모델||

• • 요청 후 프로세스가 추가 되거나, 계약승인 프로세스가 없어 진다면?
• 프로세스를 떠나 속성이 유사한 엔터티를 상태에 따라 일대일(1:1) 관계의 엔터티로 나누는 것은 유연하지 못하며 바람직하지 않음

화면 도출 지양

• 화면은 뷰(View)와 유사하며, 대부분 엔터티와 일대일(1:1)로 매핑되지 않는다.

데이터 관리 요건

• 관리하려는 데이터를 엔터티로 설계
• 예외도 있지만, 요건상 필요 없는 데이터를 관리할 필요 없음

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

• 엔터티명은 자신의 데이터 집합에 대한 이름이자 다른 엔터티가 바라보는 이름

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

• 엔터티명을 보고 어떤 데이터를 관리하는지 알 수 있도록 표현

일관성 있게 명명

• 일관된 약속인 명명법(命名法)

구체적으로 명명

• 구체적/일반적 엔터티명은 모델러가 상황에 맞게 판단

• 엔터티의 성격이 표현된 구체적이고 명확한 예제
  • 주 식별자가 '고객번호+매체종류코드' 인 엔터티 : 매체별수수료(X), 매체별고객수수료(O)
  • 진행이력(X), 계약진행이력(O)
  • 탈퇴한 고객을 관리하는 엔터티 : 고객탈퇴(X), 탈퇴고객(O)
  • 탈퇴 신청서를 관리하는 엔터티 : 탈퇴신청고객(X), 고객탈퇴신청(O)

확장성을 고려하여 명명

• 넓은 개념을 포함할 수 있도록 유연하게 표현
• 의미가 충분히 전달되면 확장성을 고려해 다소 일반적인 엔터티명을 선택
  • 시스템에 현재 개인 고객만 있어도 법인/사업자 고객을 대비하여 : 개인고객(X), 고객(O)
  • 책 쇼핑몰 설계 시 향후에 다른 상품 판매를 고려하여 : 도서상품(X), 상품(O)
  • 현재는 금액만 관리하더라도 다른 데이터 관리를 고려하여 : 사원별거래총액(X), 사원별거래집계(O)
  • 고객별/계좌별 한도를 통합 관리시 다른 기준 추가를 고려하여 : 고객계좌한도(X), 통합한도(O)

• 확장성 고려는 데이터 통합을 고려 하는것, 좋은 모델러는 유연하게 설계 한다.
• 리버스 모델링 수행시에는 통합 대상 파악 과 혼란 방지를 위해 오히려 구체적으로 표현하는 것이 좋다.

필요한 단어로만 명명

• 생략해도 의미가 통하는 단어는 생략한다
  • 생략해도 되는 군더더기 표현 : 등록, 처리, 정보, 관리, 리스트, 테이블, 시스템
  • 삭제해도 엔터티를 이해하는데 문제가 없는 접미어는 사족 : 고객마스터(X), 고객(O)

• 접미어를 사용해 엔터티 종류를 표현
  • 엔터티 구분 접미어 : 기본/상세/내역/이력/코드/집계/백업/임시

• 접미어를 붙이는 표준은 시스템에 유용할 수도 있음
  • 지침(Guideline)이 있다는 것은 90점은 될수 없어도 70점은 될 수 있음
  • 몇 가지 결정적인 단점으로 필자는 사용하지 않음 (없어도 엔터티 이해에 문제가 없고, 일부 구분은 부정확 함 : 내역vs이력)

• 생략하면 간명해지는 단어 ('_{시', '}용', '~별')
  • 계약용파일(X), 계약파일(O) / 업체별연락처(X), 업체연락처(O)

• 중복 의미 단어
  • 고객불만신고내역(X), 고객불만내역(O) / 서비스변경요청진행상태이력(X), 서비스변경진행이력(O)

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

• 엔터티명에 프로세스(업무)를 표현하는 것은 바람직하지 않다.

명사형으로 명명

• 명사형으로 띄어쓰기 없이 표현

가능하면 짧게 명명

• 어차피 엔터티명으로 데이터 성격을 완전하게 알기는 어려움

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

• 엔터티명은 표준 용어 사용 하지만 테이블명은 엔터티명에 종속되면 안되며, 단순 번호 사용 권장
• 속성명은 컬럼명으로 자동 전환 해도 되나, 테이블명은 안됨 (어플리케이션 수정이 필요 하는 등 영향도가 큼)
• 분석 진행, 요건 변경, 통합/분리 등의 사유로 엔터티명은 생각보다 자주 바뀜

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

• 가독성을 위한 엔터티 복제를 예외로 하고, 전 영역에서 유일해야 함
• 외부 엔터티 사용시 해당 주제 영역에서 엔터티명 변경 여부 확인 필요
• 특수문자 : '_', '/', '()', '[]' 사용 가능 : 주문내역(2035)

1.20. 다양한 엔터티에 대한 명명법(命名法)

실체 엔터티 명명법

• 엔터티명이 명사로 끝남
• 주 식별자가 회원번호 인 탈퇴 회원 관리 엔터티 : 탈퇴회원(O), 회원탈퇴(X), 회원탈퇴내역(X), 탈퇴회원내역(X)

행위 엔터티 명명법

• 엔터티명에 '_{신청', '}거래', '~지급' 등 행위를 의미하는 단어가 포함
• 회원이 탈퇴한 행위 관리 엔터티 : 회원탈퇴(O), 회원탈퇴내역(O), 탈퇴회원(X), 탈퇴신청회원(X)

그림 1.32 행위 엔터티

• • 탈퇴 행위는 여러번 발생 가능
  • 엔터티명에 '했음' 을 붙여서 자연 스러우면 행위 엔터티명으로 적합
    • 시뮬레이션결과내역(X), 시뮬레이션내역(O) / 탈퇴회원(X) / 환율(X)

교차 엔터티 명명법

• 다대다(M:N)관계의 관게명은 교차 엔터티명과 유사

집계 엔터티 명명법

• 집계 기준(Dimension)은 앞쪽에, 대상(무엇을 집계했는지)은 뒤쪽에 위치
• '(사원/부서/월/매체)별(거래/매출/주문)집계'
• 디멘전이 여러개 존재하면, 기간(월/일/분기)을 맨 앞으로 하고, 가장 상세한 디멘전을 기준으로 명명 (인스턴스 건수가 적은것, 가장 구체적인 것)
• 고객별 주문을 집계해서 고나리하는 엔터티 : 고객집계(X), 고객별주문집계(O)

외부 엔터티 명명법

• 특정 기관에서 받은 데이터만을 관리 : 기관명을 엔터티명에 붙임
• 유사한 데이터를 다른 기관에서 받을 수 있는 경우 : 통합을 고려해 기관명 생략
• 한국거래소채권, 한국예탹결재원채권 → 채권 (통합)

서브타입 엔터티 명명법

• 슈퍼타입 엔터티에 롤이름(Role Name) 붙임
  • 고객 → 개인고객, 법인고객
  • 상품 → 주식상품, 채권상품
• 슈퍼타입 엔터티명 앞에 롤 이름을 사용하지 않은 서브타입은 명확하지 못함
  • 슈퍼타입(주문) → 서브타입(국내, 국외) : (X)
  • 슈퍼타입(주문) → 서브타입(국내주문, 국외주문) : (O)

일대일 관계 엔터티 명명법

• 하나의 엔터티에서 관리하는 속성 일부 분리

그림 1.35 유사한 속성으로 분리한 일대일 엔터티
그림 1.36 사용 빈도로 분리한 일대일 엔터티 : ~상세

• 프로세스를 표현한 결과 일대일 관계 발생 : 성격에 맞는 엔터티명 표현

그림 1.37 프로세스 분리한 일대일 엔터티

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

• 엔터티가 어떤 데이터를 관리하는지 알게 하기 위해서 설명(Explanation)은 반드시 기술해야 한다.
  • 설계(정의)한 사람조차 기억이 희미해지며, 모델링중 스스로 참조할 수 있다.
  • 설명이 부실하면 후일에 그 엔터티를 다른 사람이 관리할때 오용할 가능성이 있다.

• 엔터티를 파악하는데는 엔터티명과 업무 식별자(주 식별자)가 설명 보다 더 중요하다.
  • 설명은 스키마를 이해하기 위한 보조 정보 이며, 두가지가 충돌하면 설명이 무시됨

• 두가지 엔터티 설명

• 설명 기타
  • 가공 엔터티일 경우 원천 엔터티 기술, 외부 데이터라면 출처 기술
  • 현행 엔터티가 있다면 '엔터티명[테이블명]' 정보 기술 (가능 하면 설명과 구분)
  • 서브 타입은 슈퍼 타입 설명 + 고유 집합과 속성에 대한 설명 기술
  • 완전한 문장으로 기술

• 간결한 설명이 좋은 설명임 (단순 명료)
  • 엔터티의 성격이 바뀜에 따라 설명도 변경 필요
  • 계좌 엔터티 설명 '계좌의 정보를 관리하는 엔터티' : 간결 하지만 명료하지 못함 (삭제 해도 될 일반적인 단어 구성)

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

• 중요하고(Important) 주된(Main) 엔터티 (엔터티 분류 방법중 가장 모호함)
• 주요 엔터티 찾기
  • 행위의 주체와 대상이 되는 엔터티 : 고객(주체)이 상품(대상)을 주문(행위)한다.
  • 하위 엔터티가 많은 엔터티
  • 시발점이 되는 핵심 업무에서 사용하는 엔터티
  • 업무(SQL)에서 자주 사용되는 엔터티

• 개념 모델링과 분석을 시작할 엔터티를 찾기 위해 주요 엔터티가 필요
  • 현업 IT 담당자가 골라주는 엔터티 (리스트업 or 인터뷰, 빠르고 정확)
  • 모델러의 개락적인 분석 (실체/행위/가공 분류, 느림)

• 전체 엔터티중 10~30% 를 주요 엔터티로 적당함
• 주요 엔터티 선정은 본질적인 것은 아니며, 생략 하거나 모델링 중 재선정 가능

1.23. 엔터티 정의의 또 다른 이름. 업무 식별자(Business Identifier)

• 엔터티 정의시 한 몸인 업무 식별자(Business Identifier) 도출이 포함 됨
  • 엔터티 정의 : 집합의 본질, 집합의 결정자, 엔터티명 에 대한 고민

• 식별자(Unique Identifier)는 엔터티에서 데이터의 유일성을 보장해 주는 결정자(Determinant) 역할을 하는 속성(집합)
  • 업무 식별자 : 인스턴스의 개수를 늘리는 데 영향을 줌 (업무적 구분)
  • 주(인조) 식별자 : 인스턴스 식별 (물리적 구분)

• 그림 1.38 사원주민등록번호가 업무 식별자인 릴레이션

[사원]

• • 사원주민등록번호가 같으면 같은 사원으로 인식, 인스턴스 발생 기준
  • 사원번호는 인스턴스가 늘어난 결과를 반영하고 식별하는 역할임

• 그림 1.39 사원주민등록번호와 입사일자가 업무 식별자인 릴레이션

[사원]

• • '홍길동'이 퇴사하고 재 입사할 때 다른 사원번호를 부여하는 요건 반영

• 그림 1.40 사원주민등록번호가 업무 식별자인 릴레이션

[사원]

• • '홍길동'이 퇴사하고 재 입사할 때 같은 사원번호를 부여하는 요건 반영

• 그림 1.41 그림1.40 릴레이션의 이력 릴레이션

[사원이력]

• • 기존 데이터를 이력 관리하는 요건 반영

1.24. 업무 식별자 도출 방법

• 엔터티의 인스턴스가 어떤 기준(속성)에 의해서 생성되는지 찾는다
  • 고객 엔터티 : 인격체 기준 (주민등록번호), 인격체 역할 (주민등록번호 + 역할)
  • 주 식별자인 고객번호는 인조 식별자로서 인스턴스 식별 기능, 업무 식별자는 인스턴스 식별과 발생 기준

• 정규화를 수행하는 기준(결정자, Determinant)을 찾는다
  • 결정자 = 업무 식별자

• 엔터티의 종류별 인스턴스를 구분하는 속성
  • 실체 엔터티 : 보통 식별 번호 (주민등록번호, 사업자등록번호)
  • 행위 엔터티 : 육하원칙 - 누가(주체), 무엇을(대상), 언제(시점), 어떻게(방법) - 중 주로 '누가', '무엇' + '언제'
    • 업무 식별자 도출 시에는 '언제'(시각 속성)는 배제하고, 필요시 나중에 포함
  • 집계 엔터티 : 데이터 집계 기준인 디멘젼(Demension)
  • 이력 엔터티 : 실체, 행위 엔터티의 업무 식별자 + '언제' (일자)

• 타임스탬프는 물리적으로 인스턴스를 식별할 수 있지만, 인스턴스 발생 기준이 아니기 때문에 업무 식별자에 부적합
• 순번 속성은 타임스탬프 보다 업무 식별자로서 더 의미가 없으며, 주 식별자에도 무분별하게 적용 하면 안됨
  • 시각, 순번 속성을 배제하고 업무 식별자를 고민하면 엔터티 성격 파악에 도움됨

• 업무 식별자 도출 기본 원칙 : 최소한의 속성이 되도록 함 (슈퍼 식별자 지양)
  • 슈퍼 식별자 : 이미 인스턴스를 식별할 수 있는 속성에 다른 속성 추가

1.25. 업무 식별자 표현 방법

• 주 식별자(PK) 존재, 인스턴스 발생 기준 알 수 없음 (그림 1.39, 1.40 케이스)
  • 업무 식별자에 유니크 인덱스 생성 : 업무 식별자 역할 및 데이터 품질 향상

그림 1.42 릴레이션에 대한 모델

• 업무 식별자를 표현할 수 있는 CASE 툴은 없고 대리 식별자(Alternate Identifier)는 표현 가능
• ||그림 1.43 주 식별자만 존재하는 엔터티||

• • 객실예약번호 : 주 식별자, 인조 식별자
  • 객실번호 + 투숙일자 : 업무 식별자
• ||그림 1.44 대리 식별자(AK)가 표현된 엔터티||

• 업무 식별자를 대리(보조) 식별자로 표현

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

• 엔터티를 하나씩 상세하게 평가는 가능하나 많은 시간이 소요 되며 현실적으로 어려움
• 데이터 모델은 객관식 문제를 채점 하듯이 기계적으로 평가하는 방법은 없음
  • 기계적 점검 요소가 있지만 모델 평가로는 부족 함

• 모델링은 인간의 종합적인 판단과 통찰력에 의존적인 분야기 때문에 수치화 해서 평가하기 어려움.
  • 모델링은 업무에 종속적이다 (동일한 요건도 기업에 따라 다른 결과가 나타남)

• 검증하기 어렵지만 검증은 해야 하며, 객관하기 위해서 정량화해서 수치로 평가 필요

1.27. 엔터티 검증(Entity Reviedw)

• 모델의 품질을 높이기 위해서 논리 모델이 완료된 시점에 데이터 모델 검증(Data Model Review) 하는 것이 좋다
• 엔터티가 잘못 설계됐을 경우 주 식별자나 관계, 속성, 변경 이력 데이터 설계가 무의미 하기 때문에 엔터티 검증은 가장 중요 하다.

엔터티 존재 여부 검증 방법

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

• 검증 방법
  • 어플리케이션 화면 과의 매트릭스(Matrix)
    • 엔터티 없음, 화면 존재
    • 엔터티 존재, 화면 없음 : 엔터티 제거 혹은 화면이 누락 되었을 수도
    • 엔터티 없음, 화면 없음 : 누락 여부 발견 불가
  • ASIS 엔터티와의 매트릭스
    • ASIS 존재, TOBE 없음 : 엔터티 추가 혹은 업무 삭제 검토
    • ASIS 없음, TOBE 있음 : 신규 업무 여부 검토

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

• 일대일(1:1) 관계의 엔터티에서 속성으로 설계해야 하는데 엔터티로 설계하는 경우가 있음
  • 성능/관리를 고려한 수직 분할이 아니라면 속성으로 설계
  • 상위 엔터티와 통합하면 의미가 명확해지는 엔터티는 속성으로 설계

• 엔터티로 설계 해야 하는데 속성으로 설계 하는 경우는 검토 필요
  • 반 정규화
  • 속성 값의 변경 이력 미고려

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

• 한 엔터티에 여러 성격의 데이터가 혼재되서는 안됨
• 실체/행위/가공/기준 으로 명확히 분류 되어야 함

유사한 성격의 데이터인데 개별적인 엔터티에서 관리하고 있지 않은지?

• 성격(정체성)이 유사한 데이터 집합은 통합을 기본 원칙으로 검증
• 엔터티 통합 검증 순서
  • 유사한 엔터티 식별
    • 엔터티명 정렬 후 유사성 검토 (필자)
    • ASIS 엔터티명/테이블명 정렬 후 유사성 검토
    • 어플리케이션명 정렬 후 유사성 검토
    • 모델의 구조(모양)가 반복되는 경우 검토
  • 통합시 실익 검토

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

• 엔터티명을 보고 어떤 데이터를 관리하는 엔터티인지를 알 수 있도록 가능한 구체적으로 명명
• 확장성을 고려해 유연한 엔터티명인지 검토
• 엔터티명에 필요 없는 단어는 생략 (처리, 정보, 테이블, 마스터, 관리, 등록, 리스트, 시스템...)
• 서브타입은 슈퍼타입의 엔터티명 차용 (고객→개인고객)

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

• 엔터티명은 주 식별자와 한 쌍처럼 잘 어울려야 한다.
• 엔터티 : 계약, 주 식별자 : 약정번호\(?), 계좌번호\(?)

엔터티 설명(Explanation)이 존재하며 간결하고 명확한지?

• 엔터티 설명은 반드시 기술 해야 하며, 하나씩 읽고 이해하는 방식으로 검토
• '계좌' 엔터티의 설명이 '계좌의 정보를 관리하는 엔터티' 라면 의미가 없다

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

• 주 식별자는 없을 수 있지만, 업무 식별자는 반드시 있어야 한다.
• 존재를 기계적으로 검증 하기 위해 AK(Alternate Key)표시 등으로 표준 형식을 정해서 관리
• 제대로 도출 되었는지에 대한 검증은 하나하나 검토 해야 한다

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

• 이력 엔터티는 엔터티명이 '~이력'으로 끝난다.
  • '계좌' 엔터티, '계좌이력' 엔터티 : '이력' 용어는 데이터의 성격을 나타내므로 접미어 사용 가능

• 해당 엔터티가 내역 엔터티가 아닌지 검토 필요
  • 이력 엔터티 : 변경된 데이터를 관리하는 엔터티
  • 내역 엔터티 : 발생된 데이터를 관리하는 엔터티

• 이력 엔터티 여부 검증 방법
  • 주 식별자에 변경/종료 일자 속성이 있는가? (혹은 일반 속성 + 주 식별자의 순번)
  • 원천 엔터티와 일대다(1:M) 관계

• 실체 엔터티, 하위 엔터티가 많은 엔터티는 이력 엔터티를 별도 관리
• 이력 엔터티에 시작/종료 일자 사용시 선분이력 사용 여부 검토, 성능 문제가 없다면 변경일자 사용
• 주 식별자에 '~순번' 속성 사용한 이력 엔터티는 검토 필요 : 이력/내역 구분이 어려워짐 (변경일자 혹은 시작/종료 일자 적용)

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

• 성능/관리 문제가 없다면 합체를 고려
• 일대일 관계 엔터티의 성격이 같을 때는 주 식별자가 같아야 함

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

• 종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속한다.
• 식별자로 상속한 관계만 뽑아서 종속 엔터티인지 검토 한다.

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

• 흔하지 않고, 재차 확인 필요
• 기준 데이터라면 다른 기준 데이터를 관리하는 엔터티에 통합 검토

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

• 주 식별자가 필수는 아니지만, 주 식별자가 없는 엔터티는 검토 필요

주 식별자(PK)가 동일한 엔터티가 있는지?

• 성능, 관리 측면에서 엔터티를 분히한 일대일(1:1) 관계, 슈퍼/서브 타입을 제외하고, 엔터티의 주 식별자가 같은 경우 주 식별자 검토 필요
  • '계좌번호+순번' 등의 인조 식별자 남발 케이스

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

• 모델러는 스스로 설계한 엔터티와 속성을 쉽게 설명할 수 있어야 함

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

• 외부/복제 엔터티는 원천 엔터티와 엔터티명과 주 식별자가 동일해야 함

1.28. 데이터 모델 설계 원칙

• 모델링시 고려 사항 (우선 순위 순)

정체성

• 데이터 성격에 맞는 정체성 뚜렷한 엔터티 설계는 중요한 원칙
  • 명확한 엔터티 정의(Definition) 과 주 식별자
• 엔터티 설계가 제대로 되지 않으면 이후 모델링은 의미 없음

통합성

• 유사한 성격의 데이터는 통합하는 것이 주요 원칙
• 통합 후 서브타입 설계 : 데이터 관리 효율 향상, 모델 가독성 향상

유연성(확장 용이성)

• 확장하기 수월한 모델 설계
• 데이터의 통합, 엔터티 정규화

무결성

• 엔터티의 주 식별자
• 엔터티간 참조 무결성(Referential Integrity)
• 도메인에 맞는 속성 데이터 타입 (숫자:NUMBER, 문자:VARCHAR, 날짜:DATE)
• 심각한 성능 문제를 제외하고 중복 데이터 배제

가독성

• 관계선이 겹치지 않도록 작성
  • 외부/복제 엔터티 사용, 서브타입 적용, 순환/배타 관계 표현

업무 연관성

• 요건에 맞는 모델 설계를 위해 업무 식별자를 제대로 도출 해야 함 (명확한 엔터티 설계)
• 요건에 맞도록 엔터티간 관계선을 표현 하고 참조 무결성 적용
  • 업무요건(Business Requirements) → 관계선(Relationship Line) → RI 제약(Referencial Integrity Constraints)

성능 효율성

• 요건 별로 검토
  • 데이터를 통합하고 정규화를 통해 성능 개선 개선 케이스
  • 적절한 비정규화를 통해 성능 극대화 케이스

관리 효율성

• ERD가 제대로 관리될 수 있도록 설계
  • 엔터티가 늘어나지 않는 방향으로 설계
  • 별 의미 없는 일대일(1:1) 엔터티는 통합, 백업 엔터티 대신 파티션 설계

표준화

• 표준 지침이 적용된 메타 시스템 사용 : 속성명에 일관된 용어 적용
• 표준 관리 체제에 따라 표준 데이터 관리

데이터 보안 대비

• 암호화 대상 속성 주의
  • 주 식별자 적용 (외래 식별자 영향, 인덱스 검색 영향)
  • 중복 속성 : 암호화 대상 증가로 인한 관리 어려움
• 주민등록번호와 같이 향후에 사용되지 않을 수 있는 속성 고려

1.29. 무결성(Integrity)에 대해서

• 데이터 무결성 : 데이터 값이 완전하고 정확한 상태
• 정합성 : 데이터들의 값이 서로 일치
  • 중복 데이터, 비정규형 사용으로 결국 정합성이 깨지게 됨
  • 정합성에는 이상이 없으나 무결성은 훼손된 상태가 가능 (무결성의 정의가 더 광범위)

• 데이터 중복이 완전히 제거 되도 불완전한 데이터 존재 가능
  • 참조 무결성 생략
  • 필요한 초기 값의 생략
  • 업무적으로 논리/규칙에 맞지 않는 데이터

• 데이터베이스 차원에서 지켜야 할 무결성의 종류
  • 엔터티 무결성(Entity Integrity)
  • 참조 무결성(Referential Integrity)
  • 도메인 무결성(Domain Integrity)
  • 업무 무결성(Business Integrity)

엔터티 무결성(Entity Integrity)

• 모든 인스턴스는 고유하고, 주 식별자는 Null 값을 가지면 안됨
• 엔터티 무결성의 핵심은 식별자(Identifier)
  • 업무 식별자 : 논리적 엔터티 무결성 (Unique Index)
  • 주 식별자 : 물리적 엔터티 무결성 (Primary Key)
  • 그림 1.46 무결성이 깨진 릴레이션
    [고객]

참조 무결성(Referential Integrity)

• 엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 Null 이어야 함
• 두 엔터티의 연관된 인스턴스 간의 일관성을 유지하기 위한 제약
• 데이터 모델에 관계를 정의 할때 참조 무결성을 기준으로 정의 한다.
• 데이터베이스에서 절대적으로 필요한 중요한 요소며 제약(Constraints)임 : FK(Foreign Key)
• 그림 1.47 외래 식별자가 존재하는 주문 릴레이션

[고객]

[주문]

• • 주문 릴레이션의 고객번호 속성은 외래 식별자이며, 고객 릴레이션의 주 식별자인 고객번호 속성에 존재 해야 함

도메인 무결성(Domain Integrity)

• 속성(Attributes)과 관련된 제약
  • 특정 속성 값은 동일한 범주의 값만이 존재 해야 함 : 이름 속성에 '홍길동'(O), '123'\(?)
• 데이터 타입(Data Type)과 기본 값(Default) 제약, 널(Null) 제약, 체크(Check) 제약 등으로 지켜짐

업무 무결성(Business Integrity)

• 업무를 수행하는 방법이나 데이터를 처리하는 규칙
  • 예) 주문 금액 3만원 이상이면 배송비 무료
• 주로 프로그램에서 점검, 데이터베이스의 트리거(Trigger)로 강제 적용 가능
• 무결성 준수 방법
  • 논리적인 방법 : 지침(Guideline)을 제시 (약속)
  • 물리적인 방법 : 데이터베이스 제약 사용 (사용 정도에 비례해 데이터 무결성 향상, 적극 고려)

1.30. 성능에 대해서

• 성능

• 조회 성능

• • 공통 해결책 : 비정규형

• 조회 성능과 데이터 블록(Block)
  • 대부분의 DBMS는 데이터를 블록 단위로 메모리에 올려서 읽음
  • 해당 데이터가 메모리에 이미 존재하면 빠르게 읽을 수 있음

• ||그림 1.49 블록이 인스턴스 길이만큼 소비되는 일반 모델||

• • 고객명(20B) 하나만 조회해도 1블록(8KB)을 메모리에 올려서 읽어야 함
  • 고객의 데이터가 9KB 라면 2블록이, 2KB 라면 1블록이 있으면 됨

• ||그림 1.50 블록이 많이 소비되는 정규형||

• • '홍길동'이 주문한 상품을 조회(고객명/상품명 함께 조회)시 최소 3블록 필요

• ||그림 1.51 블록이 적게 소비되는 비정규형||

• • 같은 상황에서 1블록 필요, 하지만 정합성이 떨어지고 쓰기 성능은 저하됨

• 엔터티를 물리적으로 분리(정규화)해서 만들면 저장소인 블록(Block)도 분리 됨
• 정규화를 할수록 엔터티가 분해되어 조회 성능이 나빠지고, 중복 데이터를 사용하면 쓰기 성능이 나빠짐

• 모델링시 성능을 고려하는 것에 대한 어려움 : 시점과 자원(인력/시간)
  • 모델링 후 DB에 테이블을 생성하고 데이터 입력하고, 화면에서 사용한 SQL 까지 고려 해야 성능 최적화 가능 (시점)
  • 성능 문제가 도출 되는 단계
    • 모델링 ERD → DB 생성 → DATA 생성 → SQL 분석 → 성능문제
  • 모델러가 쿼리(SQL)까지 검토할 수 있을 정도의 시간과 인력이 주어지는 프로젝트는 없다.
• 대부분 모델링 단계에서는 이미 발생했거나 예상되는 성능 문제가 최소화 될 수 있도록 고려하는 수준임

• 조회 성능 문제
  • 명세 조회 요건 : 한건 조회 이므로 무결성만 고려
  • 목록 조회 요건 : 다수 조회 가능하므로 성능 문제 적극 고려

• 화면 구성 문제
  • 횡으로 표시 : 비정규형 고려
  • 종으로 표시 : 정규형 고려

• 화면의 중요도와 사용 빈도, 성능 이슈 까지 고려한 전략 수립
• 가능한 빠른 단계에서 성능 문제를 검토 해야 함
  • 검토는 해결을 의미하지 않음
  • 성능 문제로 비정규형 고려시 성능과 무결성에 대한 비교 검토 필요
  • 경험, 분석에 의해서 예상 되는 문제를 단계(물리모델링)가 올 때 까지 미룰 필요 없음