데이터 모델링 (2)

Entity란?

데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 것이 엔티티(Entity)이다.

 

실무에서는 오브젝트 또는 엔티티라고 부른다.

 

정의는 여러 가지가 존재하지만 하나만 뽑자면 "업무에서 이용되는 정보를 저장하고 관리하기 위한 집합 단위의 것(THING)이다.

 

엔티티는 자신의 집합에 속하는 개체들의 특성을 설명할 수 있는 속성을 갖는다.

예를 들어 행위 엔티티인 주문은 주문번호, 고객 , 주문 날짜, 입금 상태 등 여러 속성을 가질 수 있다.

 

속성들에서는 엔티티 개체들이 전부 공유하는 전역속성도 있을 수 있고, 일부 엔티티 인스턴스들만 사용하는 개별속성이 존재할 수도 있다.

 

엔티티라면 단순히 눈에 보이는 것들로 한정할 수 없다. 실제 업무에서는 "주문"과 같이 눈에 보이지 않는 것도 엔티티로 도출되기 때문이다.

 

 

엔티티의 특징

엔티티라면 다음과 같은 특징이 존재해야하며 그렇지 않다면 잘못 도출되거나 비즈니스의 프로세스에 누락된 것이 존재하는 것이다.

 

1. 반드시 업무에서 활용되거나 관리되어야 하는 정보

이 경우는 Business Boundary에 대한 확고한 인식이 필요하다. 정의되어 있지만 사용되지 않는다면 엔티티는 잘못 선정되었거나, 프로세스가 누락된 것이다.

 

2. 유일한 식별자에 의해 식별이 가능해야만한다.

 이때 식별자는 논리적 데이터 모델링에서 사용되는 고유한 식별자이다. Key랑 혼동하는 경우가 존재하는데 Key는 물리적 데이터 모델링에서 나오는 개념이다. 또한 유일하게 만드는 것이 중요하지 않고 업무적으로 사용 시 그 인스턴스가 한 개만 도출되는지 확인이 필요하다.

 

3. 영속적으로 존재하는 집합이어야만 한다.

정보의 관리와 누적되었을 때 활용의 가치가 있는 엔티티 집합이여야만 비즈니스에서 활용가치가 있다.

 

4. 속성이 반드시 존재해야 한다.

엔티티 이름만 가지고 있다는 것은 관계가 생략되었거나, 업무 분석이 미진하여 속성정보가 누락되는 경우이다. 다만 관계 엔티티 경우 주식 별자만 존재해도 엔티티 로취 급한다.

 

5. 다른 엔티티와 최소 한 개 이상 관계가 있어야 한다. 

기본적으로 엔티티가 도출되었다는 것은 해당 업무 내에서 업무적인 연관성을 가지고 다른 엔티티의 연관성을 가지고 있다는 것을 내포하고 있다. 단 데이터 모델링을 하면서 관계를 생략한다는 것은 통계성 , 코드성, 시스템 처리 내부에 필요한 엔티티들인 경우이다.

 

 1) 통계성 엔티티라는 것은 업무 진행 엔티티로부터 통계업무만을 위해 별도로 재정의하는 경우이다.

 

 2) 코드 엔티티라는 것은 너무 많은 엔티티와 관계 설정으로 인해 읽기 효율성이 저하되는 경우 코드를 정의해 관계를 풀어내기 위해 사용한다.

 

 3) 시스템 내부 처리를 위한 엔티티는 로그 처리 같은 엔티티가 있다. 업무적으로 연관된 테이블과 관계 설정이 필요하지만 이건 시스템 내부적인 필요에 의해 생성된 엔티티이기 때문에 관계를 생략해도 된다.

 

 

Entity 도출

엔티티를 도출할 때 일정한 그룹에 의해 그룹화 시 도출을 쉽게 할 수 있다.

 

그중 한 가지는 발생 시점에 따른 그룹 분류이다.

 

 1. 기본 Entity (Fundamental Entity) 

 - 원래 업무에 존재하는 정보로써 독립적으로 생성이 가능하며 타 엔티티의 부모역할을 한다. ex) 사원, 고객, 상품

 

2. 중심 Entity (Main Entity)

 - 기본 Entity로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다. 데이터 양이 많고 다른 엔티티와 관계를 통해 많은 행위 Entity를 생성한다. ex) 사고, 계약, 주문

 

3. 행위 Entity

 - 두 개 이상의 부모 엔티티로부터 발생되고 자주 내용이 변경되고 데이터량이 증가된다. 보통 M:N 관계를 풀어내면서 연결 테이블이 생기고 이 연결 테이블에 속성이 추가되면서 행위 엔티티로 변환된다.  초기에 바로 찾기는 힘들고 설계 단계나 프로세스와 상관 모델링을 진행하면서 도출되기도 한다. ex) 주문 상품 , 주문 목록 

 

 

Entity 속성

 

속성의 사전적인 정의는 사물이나 개념이 어떤 것인지 표현하고 그것을 다른 것과 구별하는 성질이다. 

데이터 모델링을 할 때는 업무에서 필요로 하는 인스턴스로 관리하고자 의미상 가장 작은 단위라고 할 수 있다.

 

 

속성은 다음과 같은 특징이 존재한다.

 

1) 업무에서 필요하고 관리하고자 하는 정보

2) 정규화 이론에 근간하여 정해진 주식 별자에 함수적 종속성을 가져야 함

3) 하나에 속성에는 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 경우 별도의 엔티티를 이용해 분리한다.

 

속성 하나에 여러 개의 값을 가지는 경우 다중 값 속성이라 한다.  예로 전화번호라는 속성은 집, 휴대전화, 회사 전화 등 여러 개의 값을 지정할 수 있다. 이 경우는 하나의 엔티티에 포함될 수 없음으로 1차 정규화를 진행하거나 별도의 엔티티를 만들어 연결해야 한다.

 

 

속성 도메인

각 속성은 가질 수 있는 값의 범위가 있는데 이를 그 속성의 도메인이라고 한다. 즉 속성에 대한 데이터 타입과 크기 그리고 제약사항을 지정하는 것이다.

 

이러한 타입과 크기는 제공되는 데이터베이스마다 타입이 다르기 때문에 사용하고자 하는 데이터베이스를 공부해야 한다.

 

속성을 생성할 때 속성명을 지정해야 한다. 다음과 같은 전략을 참고하자.

 

1. 업무에서 사용하는 이름

2. 서술식 속성명을 사용하지 않는다.

3. 약어는 최대한 자제하자.

4. 유일한 속성 명일 수록 유지보수가 편해진다.

 

 

Entity 관계

관계 또한 엔티티에서 빠질 수 없는 요소로 직접적으로 비즈니스와 연관성이 많다.

엔티티의 인스턴스 사이의 논리적인 연관성으로서  존재 자체 혹은 행위로 서로의 연관성이 부여돼 상태이다.

 

 * 인스턴스가 개별적으로 관계를 가지는 것(페어링)이고 이것의 집합을 관계로 표현한다.

무슨 말이냐면 인스턴스가 각각 다른 종류의 관계가 있다면 두 개 이상의 관계가 형성될 수 있다는 이야기다.

 

관계가 왜 존재나 행위로 구분될 수 있냐면 어떤 목적으로 연결되었느냐에 따라서 분류될 수 있기 때문이다.

 

다음은 존재 자체로 관계가 정의되는 것을 의미한다.

 

 

부서와 사원의 존재 자체로 속한다는 관계가 정의된다.

 

다음은 행위를 통한 관계의 정의이다.

행위를 목적으로 관계가 만들어진다.

 

관계 표기법을 이해하기 전에 3가지를 먼저 이해하자.

관계명은 바로 관계에 부여된 이름이다. 관계 차수는 1:N , M:N, 1:1 이존재하며, 관계 선택사항은 필수 및 선택 사항이 존재한다.

 

관계명

 - 엔티티가 관계의 참여하는 형태를 지칭합니다. 각각 관계는 2개의 관계명으로 2가지 관점을 가집니다.

보통 관점에 따를 때는 능동적 / 수동적으로 명명합니다.

 

관계차수

 - 두 개의 엔티티 간 관계에서 참여자 수를 표현하는 것입니다.

가장 중요한 것은 한 개의 관계가 존재하느냐 아니면 두 개 이상의 관계가 존재하는지 파악하는 것입니다.

 

관계 선택사항

 

필수적(Mandatory)적 참여 관계와 선택적인(Optional) 관계가 존재합니다. 선택적 참여의 FK는 NULL을 허용할 수 있음을 뜻합니다. 이 경우는 업무 로직과 밀접한 관계가 있기 때문에 반드시 신중하게 고려해야 합니다.

 

ERD에서는 Optional 관계에서는 o를 사용하여 표시합니다.

 

관계를 정의했다면 다음 사항을 확인해 보아야 합니다.

 

1. 두 개의 엔티티 사이에 관심 있는 연관 규칙이 존재하는가?

2. 두 개의 엔티티 사이에 정보의 조합이 발생되는가?

3. 비즈니스 아키텍처에 관계 연결에 대한 규칙이 존재하는가?

4. BA에 관계 연결을 가능하게 하는 동사가 있는가?

 

 

이제 엔티티와 관계가 정의됐다면 읽는 방법이 존재한다. 이 방법은 이해를 쉽게 도와줄 수 있다.

 

 

정말 좋은 방법이기 때문에 연습하는 것을 추천합니다.