데이터 모델링의 중요 개념

1. 엔터티(Entity)

1) 개념

- 사람, 장소, 물건, 사건, 개념 등의 명사

- 업무상 관리가 필요한 관심사

- 저장이 되기 위한 어떤 것

 

2) 특징

① 업무에서 필요로 하는 정보여야 한다.

② 유일한 식별자가 있어야 한다. ex) 회원 ID, 계좌번호 등

③ 두 개 이상의 인스턴스의 집합이어야 한다.

④ 업무 프로세스에 의해 이용되어야 한다.

⑤ 한 개 이상의 속성을 포함해야 한다.

⑥ 다른 엔터티와 관계를 가져야 한다.

 

3) 분류

① 유무형에 따른 분류 - 물리적 형태가 존재하는가?

- 유형 엔터티 : 업무에서 도출되며 지속적으로 사용되는 엔터티 ex) 고객, 강사, 사원 등

- 개념 엔터티 : 물리적 형태 없이 개념적으로 사용되는 엔터티 ex) 거래소 종목, 코스닥 종목, 생명보험 상품 등

- 사건 엔터티 : 비즈니스 프로세스를 실행하면서 생성되는 엔터티 ex) 주문, 체결, 취소주문, 수수료 청구 등

 

② 발생 시점에 따른 분류 - 언제 발생되는가?

- 기본 엔터티 : 다른 엔터티로부터 영향을 받지 않고 독립적으로 생성되는 엔터티 ex) 고객, 상품, 부서 등

- 중심 엔터티 : 기본 엔터티로부터 발생되고 행위 엔터티를 생성하는 것 ex) 계좌, 주문, 취소, 체결 등

- 행위 엔터티 : 2개 이상의 엔터티로부터 발생됨 ex) 주문 이력, 체결 이력 등

 

4) 엔터티의 명명법

① 현업 업무에서 사용하는 용어를 사용한다.

② 약어를 사용하지 않는다.

③ 단수 명사를 사용한다.

④ 모든 엔터티에서 유일한 이름을 부여한다.

⑤ 엔터티 생성 의미에 맞는 이름을 부여한다.

 

 

2. 속성(Attribute) 

1) 개념

- 업무에서 필요로 함

- 의미상 더 이상 분리되지 않음

- 엔터티를 설명하고 인스턴스의 구성 요소가 됨

 

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

- 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.

- 한 개의 엔터티는 두 개 이상의 속성을 갖는다.

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

 

3) 속성 설계 시 고려사항

① 엔터티에 필요한 속성인가?

② 속성이 하나의 값만을 가지고 있는가?

③ 속성이 하나의 의미만 가지고 있는가?

④ 동일한 의미를 가지는 속성이 하나만 존재하는가?

 

4) 분류

① 특성에 따른 분류

- 기본속성 : 업무분석을 통해 바로 정의한 속성

- 설계속성 : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성

- 파생속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성

 

② 엔터티 구성방식에 따른 분류

- PK 속성 : 엔터티를 식별할 수 있는 속성

- FK 속성 : 다른 엔터티와의 관계에서 포함된 속성

- 일반속성 : PK, FK에 포함되지 않은 속성

 

5) 도메인

- 각 속성은 가질 수 있는 값의 범위가 있는데, 이를 속성의 도메인이라고 함

- ex) 학생이라는 엔터티가 있을 때 학점 속성의 도메인은 0.0~4.5 사이의 실수 값

 

6) 속성의 명명법

① 해당 업무에서 사용하는 이름을 부여한다.

② 서술식 속성명은 가급적 사용하지 않는다.

③ 약어 사용은 가급적 제한한다.

④ 전체 데이터모델에서 유일성을 확보하는 것이 좋다.

 

 

3. 관계(Relationship)

1) 개념

- 엔터티들이 서로 상호 연관성을 가지고 있는 상태

- 강사와 수강생은 서로 논리적으로 연관성이 부여된 상태, 해당 관계는 '강의한다'라는 관계로 명명 가능

- 강사 인스턴스 하나가 여러 수강생 인스턴스들과 관계를 가지고 있기 때문에 이러한 관계를 일대다 관계라고 부름

 

2) 분류

① 존재에 의한 관계 : ex) 단지 사원이 부서에 소속되어 있기 때문에 나타나는 관계

② 행위에 의한 관계 : ex) 고객이 주문이라는 행위를 하여 발생되는 관계

 

3) 표기법

① 관계명(Membership) : 관계의 이름

- 엔터티가 관계에 참여하는 형태를 지칭

- 각각의 관계는 두 개의 관계명을 가짐

 

② 관계차수(Cardinality) : 일대일, 일대다, 다대다

 

③ 관계선택사양(Optionality) : 필수관계, 선택관계

- 고객은 여러 번 주문할 수도 있고, 한 번도 주문하지 않을 수도 있음 (선택관계)

- 주문은 반드시 고객이 있어야 함 (필수관계)

 

 

4. 식별자

1) 개념

- 엔터티 내에서 각각의 인스턴스들을 구분할 수 있는 속성

- ex) 웹사이트에서 특정 회원을 구분하기 위해 계정명이나 이메일을 사용하는 것

 

2) 특징

① 유일성 : 엔터티 내의 모든 인스턴스들을 유일하게 구분할 수 있어야 함

② 최소성 : 식별자의 개수는 유일성을 만족하는 최소의 수를 가져야 함

③ 불변성 : 식별자의 값은 정해지면 변하면 안됨

④ 존재성 : 식별자의 값은 null이 될 수 없음

 

3) 분류

① 대표성 여부

- 주식별자 : 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자, 다른 엔터티와 관계를 연결할 수 있는 식별자 ex) 주문번호, 사원번호

- 보조식별자 : 엔터티 내에서 각 인스턴스들을 구분할 수 있는 구분자이나 대표성을 가지지 못해 관계연결을 못하는 식별자 ex) 전화번호

 

② 스스로 생성 여부 

- 내부식별자 : 엔터티 내부에서 스스로 생성되는 식별자 ex) 게시판 글 번호

- 외부식별자 : 타 엔터티와의 관계를 통해 들어오는 식별자 ex) 댓글 엔터티의 원본 게시물 번호

 

③ 속성의 수

- 단일식별자 : 하나의 속성만으로 구성된 식별자 ex) 사원엔터티의 사원번호

- 복합식별자 : 둘 이상의 속성 조합으로 구성된 식별자 ex) 주문엔터티의 고객번호와 주문번호

 

④ 대체가능 여부

- 본질식별자 : 업무에 의해 만들어지는 가공되지 않는 원래의 식별자 ex) 사원엔터티의 사원번호

- 인조식별자 : 주 식별자의 속성이 두 개 이상인 경우 속성들을 하나의 속성으로 묶어 사용하는 식별자 ex) 제품엔터티의 시리얼번호

 

4) 식별자 관계와 비식별자 관계

① 식별자 관계

- 부모 엔터티로부터 속성을 받아 자식엔티티의 주식별자로 사용하는 경우

- 1:1 관계 : 부모로부터 받은 속성을 자식엔티티가 모두 사용하고 그것만을 주식별자로 사용

- 1:M 관계 : 부모로부터 받은 속성 이외에 다른 부모로부터 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성

- 식별자 관계로만 관계 구성 시 조인조건의 개수가 많아져 개발자 복잡성과 오류가능성을 유발

- 표기 : 실선으로 표현

 

② 비식별자 관계

- 부모 엔티티로부터 속성을 받았지만 자식엔티티의 주식별자로 사용하지 않고, 일반적인 속성으로 사용하는 경우

- 약한 종속관계

- 자식 주식별자 구성을 독립적으로 구성

- 상속받은 주식별자 속성을 타 엔터티에 차단 필요

- 부모쪽의 관계참여가 선택관계

- 비식별자 관계로만 관계 구성 시 많은 조인이 걸리게 되고, 복잡성이 증가하며 성능이 저하됨

- 표기 : 점선으로 표현