[Data 모델링] 엔티티(Entity), 애트리뷰(Attribute)

[Data 모델링] 엔티티, 애트리뷰

엔티티(Entity) 

현실 세계에서 다른 모든 것들과 구분되는 유형, 무형의 것을 엔티티라고 정의하며 업무 수행을 위해서 알아야 될 대상이 되는 것들을 엔티티로 정의한다. - 무지 어렵다. 엔티티라는 것을 도출해 내는 일이 쉬운일이 아니기 때문이다.  

가장 쉬운 말로 관리 되어야 하는 단위 라고 표현하는 것리 나의 생각이다.

예) 사원, 부서, 회사 등등

엔터티 선정시 유의사항

엔터티 후보의 선택은 데이터 모델링의 시작 부분이다. 

엔터티 후보를 선정하는 동안에 아래와 같은 몇 가지의 유의사항을 염두에 두어야 한다.

1. 프로세스(업무 흐름)은 머리에서 지우자. 

모든 개발자 혹은 설계자들이 흔히 하는 실수다.

엔티티를 찾아 내는 일은 업무의 흐름(일의 진행)등에 대해서 먼저 기본 베이스를 깔아두고 고민한다. 

예를들어 

자동차를 조립하는 완성차 공장의 생산관리 프로젝트에서 A부품은 전체 공정에서 제일 중요 해서 이 부품이 없으면 다른 부품도 필요없고, 단가도 제일 비싸고, 중요하게 관리되어야 학,  물론 실시간으로 체크 되어야 하고 등등 

이런 중요한 부품은 따로 관리 해야지 하는 생각을 하지 말라...

* 그냥 업무/프로세스와는 한발 떨어져서 그냥 부품일 뿐이라고 생각해야 한다. 

  많은 사람들이 범하는 실수다. 

2. 모호한 개념을 유의미하게 만들자.

실무에서는 많이 통용되고 중요한 개념인데 실제 구체적으로 명시되지 않는 것들이 있다.

예를 들어 실제 생산라인에서는 작업자들간에 통용되어 사용되지만 실제 서류나 문건에는 공식적으로 나타나지 않는 것들이 있다.

이런 부분들을 구체화/명확하게 하여 유의미한 개념으로 정리하자

* 이런 부분은 많은 경험에서 나올수 있는 노하우이며, 이런 부분들이 많을 수록 인정 받고 믿음을 줄 수 있는 Data Modeling (설계자) 전문가가 된다. 

3. 예외 경우에 너무 집착하지마라

초보자들에게 많이 나타난다. 어디든 어떤일이든 예외는 존재 한다.

설계 초기부터 모든 예외를 처리하고 감안 할 수 없다.

예외는 차차 Data Modeling을 구체화 하면서 처리 하는 것이다.

* 100층 고층 빌딩을 만드는데 화장실 문은 회전문읹지 자동문인지 고민 할 필요가 있을까?

  예외들을 고민에 고민해서 잘되는 Project 못 본것 같다. 

애트리뷰(attribute) 

엔티티를 선정하고 뽑아 냈다면 엔티티에 포함될 수 있는 속성들을 기록해보자. 

애트리뷰 유의사항

엔터티에 비해서 애트리뷰는 쉬워 보인다.

각 애트리뷰에 포함될 속성들을 나열 하면 된다. 

아래와 같은 몇 가지의 유의사항을 염두에 두고 생각해보자. 

1. 특정 애트리뷰가 너무 많은 엔티티에 포함된다. 

엄격하게 data Modeling 에서는 원칙적으로 중복된 애트리뷰가 있어서는 안된다.

그러나 이론은 이론일뿐 실전/실무는 다르다. 

특정 애트리뷰가 너무 많은 엔티티에 포함된다면 해당 애트리뷰가 엔티티가 될 가능성은 없는지 고민해볼만하다.  

* 특정 컬럼이 대부분의 테이블에 들어 있어서 당황스러운 경우가 많다.  

2. 필요한 애트리뷰들은 모두 고려하자.

간혹 애트리뷰들을 합치는 경우 한번더 고민하자 a와 b을 합쳐서 c로 만들지 , a를 나누어서 a1, a2로 만들지?

* 시각(YYY-MM-DD HH:MI:SS)을 YYYY, MM, DD, HH, MI, SS 등의 조합으로 나누는 경우 정말 맞는지? 고려하자

3. 시스템 관점의 애트리뷰를 만들때 고민하자

어느정도 경험이 생기면 흔하게 나타난다. 

나중에 조회시 혹은 집계/통계를 위해서 애트리뷰를 추가 하는 경우다.

의외로 경험이 어느 정도 생기면 설계시에 이런 애트리뷰들을 추가 하는 것을 상당히 많이 목격하게 된다.

* 실무에서 많이 보게되는 현상이다. 

---