데이터 모델링의 이해 - 엔티티 / 속성

(1) 엔티티란?

-  엔티티의 사전적인 의미는 '독립체'이다 데이터베이스에서 엔티티는 식별이 가능한 객체라는 의미를 가지고 있다.

 - 식별할 수있는 사물

 - 데이버테이스 내에서 식별 가능한 객체

 - 정보를 저장할 수 있는 어떤 것 

 - 정보를 저장할 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 

 

* 엔티티는 업무에서 스이는 데이터를 용도별로 분류한 그룹이라고 할 수 있다.

 

Tip

엔티티 : Table

인스턴스 : Row

속성 :  Column

 

각각의 엔티티는 자신을 더 상세하게 나타내기 위해 속성을 갖게 되는데 속성의 개수는 엔티티마다 상이해서 용도에 따라 매우 많을 수도 있고 매우 적을 수도 있다. 

만약에 엔티티에 '새우깡'이라는 상품과 '자갈치'라는 상품이 있다고 가정한다면 각각은 상품 엔티티의 인스턴스가 된다.

 

 (2) 엔티티의 특징 

    1)  업무에서 쓰이는 정보여야 함

         - 너무 당연한 말이겠지만 실질적으로 업무에서 쓰이는 정보여야 엔티티로 도출하는 의미가 있다. 

         - 사용하지 않는 엔티티는 삭제하는 것이 바람직하다.

    

    2) 유니크함을 보장할 수 있는 식별자가 있어야 함 

         -  엔티티에 속한 각각의 인스턴스가 중복되거나 식별이 모호하면 이 엔티티는 설계가 잘못된 것이라고 볼 수 있다. 

            동일한 상품이 존재할 수 있으므로 별도의 상품 코드를 발번하여 인스턴스를 식별 가능하도록 설계하는 것이 바람

            직하다

 

    3) 2개 이상의 인스턴스를 가지고 있어야 함 

         - 현재 인스턴스가 1개만 존재하고 앞으로도 쭉 1개만 존재할 예정이라면 이것은 엔티티로 볼 수 없다. 

            앞으로도 쭉 1명일 예정이라면 이걸 굳이 엔티티로 만들 필요는 없을 것이다.

 

    4) 반드시 속성을 가지고 있어야 함

         - 속성이 없는 엔티티는 깡통 휴대폰과 같다. 엔티티는 반드시 자신을 상세하게 나타낼 수 있는 속성을 가지고 있어야

           한다. 

 

    5) 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함

         -  각각의 엔티티는 다른 엔티티와의 연관성을 가지고 있어야 한다. 

 

(3) 엔티티의 분류 

   1) 유형 vs 무형 

       유형 엔티티 - 물리적인 형태 존재, 안정적, 지속적  (ex) 상품, 회원 등 

       개념 엔티티 - 물리적인 형태 없음 개념적                (ex) 부서, 학과 등

       사건 엔티티 - 행위를 함으로 써 발생. 빈번함. 통계 자료로 이용 가능 (ex) 주문, 이벤트 응모 등

 

   2) 발생시점 

       기본 엔티티 - 업무에 원래 존재하는 정보 

                           - 독립적으로 생성되며, 자식 엔티티를 가질 수 있음

                             ex) 상품, 회원, 사원, 부서 등

 

       중심 엔티티 - 기본 엔티티로부터 파생되고 행위 엔티티 생성 

                           - 업무에 있어서 중심적인 역할을 하며 데이터의 양이 많이 발생 

                             ex) 주문, 매출, 계약 등 

 

       행위 엔티티 - 2개 이상의 엔티티로부터 파생

                           - 데이터가 자주 변경되거나 증가할 수 있음 

                              ex) 주문 내역, 이벤트 응모 이력 등 

  

---

 

속성 (Attribute)

(1) 속성이란 ? 

   - 사람이나 사물을 정의할 때 보통 여러가지 특징들이 수식어로 붙게 되는 것을 볼 수 있다. 

     사물이나 개념의 특징을 설명해줄 수 있는 항목들을 속성이라고 부른다. 

       - 속성은 엔티티의 특징을 나타내는 최소의 데이터 단위 

       - 속성은 의미상 더이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목 이어야 한다. 

       - 업무상 불피요한 데이터라고 판단되면 그 속성은 삭제하는 것이 바람직하다.

 

(2) 속성값 

  - 각각의 속성은 속성값을 가지며 속성값은 엔티티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터라고 

    볼 수 있다.

  - 하나의 속성은 한 개의 속성값을 가질 수 있다. 만약 하나의 속성이 여러개의 속성 값을 갖는 경우

    별도의 엔티티로 분리하는 것이 바람직하다. 

 

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

  - 한 개의 엔티티는 두 개 이상의 인스턴스를 갖는다.

  - 한  개의 인스턴스는 두 개 이상의 속성을 갖는다.

  - 한 개의 속성은 하나의 속성값을 갖는다.

 

(4) 분류

  1) 특성에 따른 분류 

     - 기본속성 - 업무 프로세스 분석을 통해 바로 정의가 가능한 속성

     - 설계속성 - 업무에 존재하지는 않지만 설게하다보니 필요하다고 판단되어 도출해낸 속성

     - 파생속성 - 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성

 

    기본속성 : 엔티티의 가장 일반적인 속성으로 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이 여기에 속한다. 

           엔티티의 가장 많은 퍼센티지를차지하는 속성이며 일부 설계속성과 파생속성을 제외한 모든 속성이 기본속성에 해

           당한다고 보면 된다.

 

    설계속성 : 업무에 존재하지는 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성이다. 

            예를 들어 '학생'이라는 엔티티에 이름, 학과, 학년이라는 속성이 존재한다고 가정했을 때 이 속성들의 속성값은

            다른 인스턴스의 속성값과 중복될 수 있고 이런 이유로 유니크함을 보장하지 못한다.  이 때 학번이라는

            설계속성을 만들어서 학생 개개인에 고유번호를 할당함으로써 인스턴스에 유니크함을 부여하는 것이다. 

 

    파생속성 : 다른 속성으로부터 파생된 속성을 의미하는 것으로 계산된 값이나 가공된 값이 이에 속한다. 

           파생속성을 설계할 경우 반드시 데이터의 정합성이 고려되어야 하고 계산 과정에서 누락되는 데이터가 생기는 경우

         결과값이 엉터리가 될 수 있는 위험 요소가 존재하기 대문에 불가피하게 필요한 경우에만 정의하는 것이 바람직하다.

 

2) 구성방식에 따른 분류 

      PK(Primary Key) 속성 : 엔티티의 인스턴스들을 식별할 수 있는 속성 

      FK(Foreign Key) 속성 : 다른 엔티티의 속성에서 가져온 속성 

      일반 속성 : PK, FK를 제외한 나머지 속성 

 

    1) PK 속성 : 엔티티에 속한 각 인스턴스에 유니크함을 부여하는 속성이다. 상품 엔티티의 상품 코드, 학생 엔티티의

          학번 엔티티의 학번, 직원 엔티티의 사번 등이 이에 속한다.

 

     2) FK 속성 : 다른 엔티티와 관계를 맺게 해주는 매개체 역할을 하는 속성이다. 직원 엔티티의 부서코드, 학생 엔티티의

          학과 코드, 회원 엔티티의 회원등급코드 등이 이에 속한다. 

 

     3) 일반속성 : PK, FK를 제외한 나머지 속성을 일반속성이라고 부른다. 상품 엔티티의 상품명, 가격, 학생, 엔티티의 이

          름, 생년월일 등이 이에 속한다.

 

(5) 도메인 

   - 속성이 가질 수 있는 속성값의 범위를 도메인이라고 한다. 예를 들면 우편번호는 다섯자리의 숫자라는 범위를 가지고

     있고 이것은 엔티티를 정의할 때 데이터 타입과 크기로 나타낼 수 있다.