[1과목] 11. 엔터티

yeomss·2022년 3월 4일
0

SQLD

목록 보기
11/14
post-thumbnail

엔터티의 개념 및 정의


데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티 이다.

  • 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상
  • 그 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합으로 정의할 수 있다.
  • 인스턴스의 집합 (집합적인 개념에 있어)
    • 인스턴스란? 엔터티의 하나의 값에 해당할 수 있다.
Entity: [학생]
Attribute: 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등
이러한 속성은 공통 속성도 있고, 엔터티 인스턴스 중 일부에만 해당하는 개별 속성도 존재한다.

엔터티 (Entity)

업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것

  • 실체, 객체
  • 데이터 베이스 내에서 변별할 수 있는 사물
  • 정보를 저장할 수 있는 어떤 것

엔터티에 포함되는 개념

  • 사람, 장소, 물건, 사건, 개념 (명사)
  • 업무상 관리가 필요한 관심사
  • 저장이 되기 위한 어떤 것(Things)

엔터티와 인스턴스에 대한 내용과 표기법


  • 대부분 엔터티는 사각형으로 ERD 에서 표기한다.
[과목] 이라는 엔터티가 존재하고
국어, 수학, 영어 라는 인스턴스가 존재한다.
  • 참고로, 오브젝트 모델링에는 Class와 Object라는 개념이 있다.

엔터티의 특징


  1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
  2. 유일한 식별자에 의해 식별이 가능해야 한다.
  3. 영속적으로 존재하는 인스턴스의 집합이어야 한다. (두 개 이상의 인스턴스)
  4. 엔터티는 업무 프로세스에 의해 이용되어야 한다.
  5. 엔터티는 반드시 속성이 있어야 한다. (두 개 이상의 속성)
  6. 하나 이상의 관계를 가지고 있어야 한다. (한 개 이상의 관계)

업무에서 필요로 하는 정보

  • 반드시 시스템을 구축하고자 하는 업무에서 필요로 하고 관리하고자 하는 정보여야 한다.

식별이 가능해야 함

  • Unique Identifier 에 의해 식별이 가능해야 한다.
  • 어떤 엔터티이건 임의의 식별자(일련 번호)를 부여하여 유일하게 만들 수 있지만, 도출 시 각각의 업무적으로 의미를 가지는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증해 보아야 한다.
  • 식별자는 고유한 것이어야 하며 중복이 발생해서는 안된다.

인스턴스의 집합

  • 영속적으로 존재하는 인스턴스의 집합이어야 한다.
  • 엔터티에서 한 개가 아니라 두개 이상의 집합 개념은 매우 중요한 개념이다.
  • 엔터티간의 관계, 프로세스와의 관계 등 업무를 분석하고 설계하는 동안 설계자가 모든 업무에 대입해보고 검증해 보아야 할 중요한 개념이다.

하나의 인스턴스는 여러 개의 인스턴스를 포함한다.

업무 프로세스에 의해 이용

  • 업무 프로세스가 반드시 해당 엔터티를 이용해야 한다.
  • 만약, 엔터티를 선정했는데 업무 프로세스에 의해 전혀 이용되지 않는다면 업무 분석이 정확하게 안되어 엔터티가 잘못 선정되거나 업무 프로세스 도출이 적절하게 이루어지지 않았음을 의미한다.
    • 데이터 모델과 검증을 하거나,
    • 상관 모델링을 할 때 엔터티와 단위 프로세스를 교차 점검하면서 문제점이 도출된다.

속성을 포함

  • 반드시 속성을 포함하고 있어야 한다.
  • 단, 예외적으로 관계 엔터티 (Associative Entity) 의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.

관계의 존재

  • 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다.
  • 엔터티가 도출되었다는 것은 해당 업무내에서 업무적인 연관성을 가지고 다른 엔터티와의 연관 의미를 가지고 있음을 나타낸다.
    • 존재적 연관성
    • 행위적 연관성
  • 단, 예외로 관계를 생략하여 표현해야 하는 경우
    • 통계성 엔터티 도출
      • 업무 진행 엔터티로부터 통계업무(read only)만을 위해 별도로 엔터티를 다시 정의하게 되므로 엔터티간의 관계가 생략되는 경우에 해당한다.
    • 코드성 엔터티 도출
      • 너무 많은 엔터티와 엔터티간의 관계 설정으로 인해 읽기 효율성(Readability)이 저하되어 모델링 작업을 할 수 없게 되기 때문에
      • 대부분의 코드성 엔터티는 외부키에 의한 참조무결성을 체크하기 위한 규칙을 db 기능에 맡기지 않은 경우가 많기 떄문에 논리적/물리적 관계를 설정할 필요가 없다.
    • 시스템 처리시 내부 필요에 의한 엔터티 도출
      • 예) 트랜잭션 로그 테이블
      • 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하지만, 시스템 내부적인 필요에 의해 생성된 엔터티 이므로 관계를 생략하게 된다.

엔터티의 분류


엔터티는 엔터티 자신의 성격에 의해 따라 구분하거나, 업무를 구성하는 모습에 따른 발생시점으로 구분할 수 있다.

유무형에 따른 분류

  1. 유형 엔터티
    1. Tangible Entity
    2. 물리적인 형태가 있으며, 안정적 및 지속적으로 활용되는 엔터티이다.
    3. 업무로부터 엔터티를 구분하기가 가장 용이한다.
    4. 예) 사원, 물품, 강사
  2. 개념 엔터티
    1. Conceptual Entity
    2. 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티
    3. 예) 조직, 보험상품
  3. 사건 엔터티
    1. 업무를 수행함에 따라 발생되는 엔터티
    2. 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다.
    3. 예) 주문, 청구, 미납

발생시점에 따른 분류

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

엔터티 분류 방법의 예

  • 이 밖에도 스스로 생성될 수 있는지 여부에 따라 독립/의존 엔터티를 분류할 수 있다.

엔터티의 명명


  1. 가능하면 현업 업무에서 사용하는 용어를 사용한다.
  2. 가능하면 약어를 사용하지 않는다.
  3. 단수 명사를 사용한다.
  4. 모든 엔터티에서 유일하게 부여되는 이름이어야 한다.
  5. 엔터티 생성 의미대로 이름을 부여한다.
    • 대체적으로 다섯번째는 제대로 잘 지켜지지 않는 경우가 있다.
    • 예) 고객 제품이라는 엔터티가 존재하면
      • 이는 고객의 제품인지, 고객이 주문한 제품인지
    • 이때 임의로 이름을 부여하게 된다면 의사소통에서 오류를 발생할 수 도 있다.

0개의 댓글