[SQLD] 엔티티, 속성, 관계

Entity(개체)

정의

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

• Entity는 그 집합에 속하는 개체들의 특징을 설명하는 속성을 갖는다.
  • 이러한 속성은 전체가 공유하는 공통 속성일 수도, 일부에만 해당하는 개별 속성 일 수도 있다.
• 집합의 특성을 가지며 순수 개체 이거나 행위 집합 이다.

특징

1. Entity는 반드시 해당 업무에서 필요하고 관리하고자 하는 업무이다. 업무에서 관리되어야 하는 집합이다.
2. 유일한 식별자에 의해 식별 가능하다.
3. 2개 이상의 인스턴스의 집합이다.
4. Entity는 업무 프로세스에 의해 이용된다.
5. Entity는 반드시 속성을 가진다.
6. Entity는 다른 Entity와 반드시 관계를 가진다.
   • 관계를 생략하는 경우도 존재한다.
     1. 통계성 Entity 도출
     2. 코드성 Entity 도출
        • 너무 많은 엔티티와 그 관계 설정으로 인해 읽기 효율성이 저하되어 모델링 작업이 어려울 때, 또는 물리적 테이블과 프로그램 구현 이후에도 외부 키에 의해 참조 무결성을 체크하기 위한 규칙을 DB기능에 맡기지 않는 경우가 많아 관계를 설정할 이유가 없을 수 있음
     3. 시스템 처리시 내부 필요에 의한 Entity 도출
        • 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하지만 업무 상 필요가 아닌 시스템 내부적 필요에 의해 생성된 Entity이므로 관계를 생략한다.

분류

1. 유무형에 따른 분류

   • 유형 엔티티 (Tangible Entity)
     • 업무에서 도출되며 지속적으로 사용되는 엔티티
     • 물품, 사원 등
     • 물리적 형태, 지속적 안정적, 업무 도출
   • 개념 엔티티 (Conceptual Entity)
     • 물리적 형태는 없고 관리해야 할 개념적으로 사용되는 엔티티
     • 조직, 보험상품 등
     • 개념적
   • 사건 엔티티 (Event Entity)
     • 업무를 수행할 때, 비즈니스 프로세스를 실행할 때 발생되는 엔티티
     • 비교적 발생량이 많고 각종 통계 자료에 이용됨
     • 주문, 청구, 미납 등

2. 발생시점에 따른 분류

   • 기본 엔티티 (Base Entity) = 키 엔티티 (Key Entity)
     • 다른 엔티티의 영향을 받지 않고 독립적으로 생성되는 데이터
     • 타 엔티티의 부모 역할을 하며, 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가진다.
     • 사원, 부서, 고객, 상품, 자재 등
     • 독립 생성, 고유 주식별자
   • 중심 엔티티 (Main Entity)
     • 기본 엔티티와 행위 중간에 있는 엔티티
     • 기본 엔티티로부터 발생되고 행위 엔티티를 생성함
     • 업무처리에 중심이 된다.
     • 계약, 사고, 청구, 주문, 매출 등
   • 행위 엔티티 (Active Entity)
     • 2개 이상의 부모 엔티티로부터 발생되는 엔티티
     • 업무 처리를 하는 동안 발생되는 엔티티로 자주 변경되고 지속적으로 정보가 추가된다.
       • 보통 행위 엔티티의 데이터 양이 가장 많다.
     • 주문 목록, 사원변경 이력 등

Attribute(속성)

정의

‘업무에서 필요로 하는 인스턴스’, 의미 상 더 이상 분리되지 않는 최소의 데이터 단위

특징

1. 속성은 해당 업무에서 필요하고 관리하고자 하는 정보이다.
2. 정규화 이론을 근거로 주식별자에 함수적으로 종속된다. 즉, 기본키가 변경되면 속성 값도 변경 된다.
3. 한 속성은 하나의 값만 가진다. 한 속성에 다중값이 있을 경우 별도의 엔티티를 이용하여 분리한다.
4. 속성명은 데이터 모델에서 유일하게 사용하되, 속성값은 중복될 수 있다.

분류

1. 특성에 따른 분류
   • 기본 속성
     • 비즈니스 프로세스에서 도출되는 본래의 속성
     • 코드성 데이터, 엔티티 식별을 위한 일련 번호, 다른 속성을 계산하거나 다른 속성의 영향을 받아 생성된 속성을 제외한 모든 속성은 기본 속성이다.
     • 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성은 기본 속성이 아니다.
     • 회원ID, 이름, 계좌번호, 주문 일자, 이자율, 원금, 예치 기간 등
   • 설계 속성
     • 데이터 모델링 과정에서 속성을 새로 만들거나 변형하여 도출된 속성
     • 유일한 값을 부여한다.
     • 상품코드, 지점 코드, 예금분류 등
   • 파생 속성
     • 다른 속성에 의해 만들어지는 속성이다.
     • 합계, 평균, 이자 등
2. 엔티티 구성방식 (분해 여부)에 따른 분류
   • Entity를 식별할 수 있는 속성 \(\rightarrow\) PK 속성
   • 다른 Entity와의 관계에서 포함된 속성 \(\rightarrow\) FK 속성
   • Entity에 포함되고 PK/FK에 포함되지 않은 속성 \(\rightarrow\) 일반 속성
3. 속성은 그 세부 의미를 쪼갤 수 있는지에 따라 나뉜다.
   1. 단일 속성
      • 하나의 의미로 구성된 것
      • 회원ID, 이름, 나이, 성별 등

   2. 복합 속성

      • 여러 개의 의미가 있는 것

      • 주소 (시, 구, 동, 번지와 같은 세부 속성으로 구성) 등

   3. 다중값 속성
      • 속성에 여러 개의 값을 가질 수 있는 것
      • 다중값 속성은 entity로 분해되므로 1차 정규화를 하거나 별도의 entity를 만들어 관계로 연결해야한다.
      • 상품 리스트, 자동차의 색상(차 지붕, 차체, 외부의 색 별로 색이 다를 수 있음) 등

엔티티, 인스턴스, 속성, 속성값의 관계

1개의 엔티티는 2개 이상의 인스턴스가, 2개 이상의 속성을 갖는다.

• 예를 들면 사원은 이름, 주소, 전화번호, 직책 등을 가질 수 있다. 사원이라는 엔티티에 속한 인스턴스들의 성격을 구체적으로 나타내는 것이 속성이며 각각의 인스턴스는 속성의 집합이다. 한 속성은 하나의 인스턴스에만 존재할 수 있다. 속성은 관계로 기술될 수 없고 자신이 속성을 가질 수 도 없다.

엔티티 내 하나의 인스턴스 속 한 개의 속성은 한 속성값만 가질 수 있다.

• 사원의 이름은 홍길동, 주소는 서울시, 전화번호가 1234, 직책이 대리라고 할 때 이름, 주소, 전화번호, 직책은 속성이고 홍길동, 서울시, 1234, 대리는 속성값이다. 따라서 속성값 각각은 엔티티가 가지는 속성들의 구체적 내용이다.
• 속성명은 전체 데이터 모델에서 유일성을 확보하는 것이 좋다.

도메인이란?

도메인은 각 속성이 가질 수 있는 값의 범위이다.

Relation(관계)

정의

‘엔티티 간의 관련성을 의미’

• 이 관계에서 튜플의 전체 개수를 카디널리티(Cardinality)라고 한다.
• 관계에서 속성의 수는 차수(Degree)라고 한다.

분류

관계는 연결할 때 **어떤 목적으로 연결되었느냐에 따라 존재에 의한 관계 / 행위에 의한 관계로 구분된다.**

1. 존재 관계
   • 엔티티 간의 상태를 의미한다.
   • ‘소속된다’라는 의미는 행위에 의해 발생되는 의미가 아니라, 황경빈 사원이 DB 팀에 소속되어 있기 때문에 존재에 의해 형성된 의미이다.
   • UML 클래스 다이어그램의 관계 중 연관관계이며 실선으로 표현한다. (ERD에서는 표기 구분 X)
2. 행위 관계
   • 엔티티 간에 어떤 행위가 있는 것
   • 계좌를 개설하고 이를 통해 주문을 발주하는 것처럼 행위에 의해 관계가 형성된다. 위의 예를 보면 ‘주문하다’라는 행위를 통해 주문번호가 생성되었으므로 이는 행위에 의한 관계이다.
   • UML 클래스 다이어그램의 관계 중 의존관계이며 점선으로 표현한다. (ERD에서는 표기 구분 X)

관계의 표기법

• 관계명: 관계의 이름
• 관계 차수: 1:1, 1:N, M:N
• 관계 선택 사양: 필수관계, 선택관계

관계 차수

2개의 엔티티 관계에서의 참여자 수

1. 1:1 관계

관계에 참여하는 각각의 엔티티는 관계를 맺는 다른 엔티티에 대해 딱 하나의 관계만 가진다.

종류	설명
완전 1:1 관계	한 엔티티에 관계되는 엔티티가 하나만 있는 경우로, 반드시 존재한다.
선택적 1:1 관계	한 엔티티에 관계되는 엔티티가 0개 또는 1개이다.

1. 1:N 관계

   

   관계에 참여하는 각각의 엔티티가 관계를 맺는 다른 엔티티에 대해 1개 이상의 관계를 맺는 것이다. 하지만 반대 방향은 딱 하나의 관계만 가진다.

   예를 들어, 한 고객은 여러 개의 계좌를 가질 수 있지만 계좌주는 반드시 한 명이다.

2. M:N 관계

   

   두 개의 엔티티가 서로 여러 개의 관계를 가지는 것

   관계형 데이터베이스에서 M:N 관계의 조인은 카티샨 곱이 발생한다. 그래서 두 개의 주식별자를 상속받은 관계 엔티티를 이용하여 3개의 엔티티로 구분하여 표현한다. (M:N 관계를 1:N, N:1로 해소한다)

관계 선택 사양(필수 참여 관계와 선택 참여 관계)

구분	내용
필수참여관계 = 필수적관계	반드시 하나는 있어야 하는 관계이며 ‘|’로 표현된다.
선택참여관계 = 선택적관계	없을 수도 있는 관계며 ‘O’로 표현한다.

필수 참여관계는 모든 참여자가 타 엔티티의 참여자와 반드시 관계를 가진다. 예를 들어 주문서는 반드시 주문목록을 가지며 주문목록이 없는 주문서는 의미가 없으므로 주문서-주문목록은 필수참여관계이다.

데이터 모델에서 선택참여관계는 관련은 있지만 필수적이지 않은 관계를 의미한다. 목록은 주문이 될 수도 있고 주문이 되지 않는 목록이 있을 수도 있어서 목록-주문목록은 선택참여관계이다.