[DB] 엔터티, 속성, 관계, 식별자

안녕하세요. 바른호랑이입니다.

이번 게시글에서는 엔터티(Entity), 속성(Attribute), 관계(Relationship), 식별자(Identifier)에 대해서 알아볼 예정입니다.

엔터티, 속성, 관계, 식별자는 데이터 모델을 구성하는 핵심요소들로 데이터 모델에 대해 보다 정확하고 깊이있는 이해를 위해서는 반드시 이해하고 넘어가야하는 개념들입니다. 이와 관련된 세부적인 내용은 아래와 같습니다.

 

1. 엔터티(Entity)

① 개념

ㆍ 변별할 수 있는 사물 - Peter Chen / 1976
ㆍ DB내에서 변별 가능한 객체 - C. J Date / 1986
ㆍ 정보를 저장할 수 있는 어떤 것 - James Martin / 1989
ㆍ 정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 - Thomas Bruce / 1992
ㆍ 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것으로 개체들의 특성을 설명할 수 있는 속성을 가짐.
ㆍ 엔터티는 인스턴스들의 집합으로 눈에 보이지 않는 개념적인 형태로 존재할 수 있기에 유의할 필요가 있음.

엔터티(Entity), 속성(Attribute), 인스턴스(Instance)

 

② 특징

ㆍ 업무에 필요하고 관리하고자하는 정보이어야 하며, 유일한 식별자로 식별이 가능해야함.
ㆍ 영속적으로 존재하는 인스턴스의 집합이어야 하며, 업무 프로세스에 의해 이용되어야 함.
ㆍ 반드시 속성이 존재해야하고 다른 엔터티와 최소 한 개 이상의 관계가 있어야함.
ㆍ 통계용 엔터티 도출, 코드성 엔터티 도출, 내부 필요에 의한 엔터티(예 : 트랜잭션 로그)도출 시에는 관계를 생략할 수 있음.

 

③ 분류

ㆍ 형태에 따른 분류
- 유형 엔터티(Tangible Entity) : 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티(예 : 사원, 강사, 물품)
- 개념 엔터티(Conceptual Entity) : 관리해야할 개념적인 정보로 구분이 되는 엔터티(예 : 조직, 보험상품)
- 사건 엔터티(Event Entity) : 업무를 수행함에 따라 발생되는 엔터티로 발생량이 많고 통계자료에 이용됨(예 : 주문, 청구, 미납)

 

ㆍ 발생시점에 따른 분류
- 기본/키 엔터티(Fundamental/Key Entity)
: 독립적으로 생성이 가능하고, 타 엔터티의 부모역할을 하며 고유한 주식별자를 가지는 엔터티(예 : 사원, 부서, 고객, 상품, 자재)
- 중심 엔터티(Main Entity)
: 기본엔터티로부터 발생되고 업무에 있어서 중심적인 역할을 하는 엔터티(계약, 사고, 예금원장, 청구, 주문, 매출)
- 행위 엔터티(Active Entity)
: 2개 이상의 부모 엔터티로부터 발생되고 내용이 자주 바뀌거나 데이터량이 증가함. 분석 초기단계에서는 잘 나타나지 않으며 상세 설계 단계나 프로세스와의 상관모델링 과정에서 도출될 수 있음.(예 : 주문목록, 사원변경이력)

 

④ 명명

ㆍ 현업업무에서 사용하는 용어를 사용해야하며, 약어를 사용하지 않아야 함.

ㆍ 단수명사를 사용하여 유일한 이름이 부여되어야 하고 이름의 의미는 엔터티 생성의 의미를 명확하게 나타내야함.

 

2. 속성(Attribute)

① 개념

ㆍ 업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위(원자성)

ㆍ 생년월일을 생년, 생월, 생일로 분리한다고해도 이는 하나의 속성을 관리목적에 따라 구분했다라고 이해할 수 있으나 이름주소와 같은 속성처럼 이름과 주소라는 2개의 속성이 합쳐져서 2개 이상의 의미를 가진다면 기본속성으로는 성립할 수 없음.

ㆍ 한 개의 엔터티는 2개 이상의 인스턴스의 집합이면서 2개 이상의 속성을 가져야하고 한 개의 인스턴스는 한 개의 속성값을 가져야함.

 

② 특징

ㆍ 업무에서 필요하고 관리하고자하는 정보이어야 하며, 정규화 이론에 근간하여 주식별자에 함수적 종속성을 가져야 함.

ㆍ 하나의 속성에는 한 개의 값만을 가지며 하나의 속성에 여러개의 값이 있는 다중값일 경우 별도의 엔터티로 분리해야함.

 

③ 분류

ㆍ 특성에 따른 분류

- 기본속성(Basic Attribute)

: 업무 분석을 통해 추출한 모든 속성으로 가장 일반적이 다수를 차지하며, 코드성 데이터, 엔터티 식별을 위한 일련번호 등 대부분의 속성이 기본 속성임.

- 설계속성(Designed Attribute)

: 데이터 모델링 및 업무의 규칙화를 위해 새로 만들거나 변형하여 정의하는 속성들로 코드성 속성, 일련번호 같이 유일한 식별자를 부여하기 위해 모델 상에서 새롭게 정의하는 속성들이 설계 속성임.

- 파생속성(Derived Attribute) 

: 다른 속성에 영향을 받아 발생하는 속성으로 프로세스 설계시 정합성 유지를 위해 유의해야할 점이 많고 가능한 적게 만드는 것이 좋음.

 

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

- 기본 키(Primary Key) : 엔터티를 식별할 수 있는 속성

- 외래 키(Foregin Key) : 다른 엔터티와의 관계에서 포함된 속성

- 일반속성 : PK, FK에 해당되지 않는 속성

 

ㆍ 의미 분할가능여부에 따른 분류

- 복합속성(Composite Attribute) : 시, 구, 동, 번지 등으로 이루어져 여러 세부속성으로 분류할 수 있는 주소와 같은 속성

- 단순속성(Simple Attribute) : 나이, 성별 등 더 이상 다른 속성들로 분할할 수 없는 속성들

 

ㆍ 가질 수 있는 값의 개수차이에 따른 분류

- 다중값 속성(Multi Value Attribute) : 전화번호와 같이 집, 휴대전화, 회사 전화같은 여러 개의 값을 가질 수 있는 속성

- 단일값 속성(Single Value Attribute) : 주민등록번호와 같이 하나의 값만 존재하는 속성

 

④ 명명

ㆍ 도메인(Domain) : 각 속성이 가질 수 있는 범위로 엔터티 내에서 속성에 대한 데이터 타입, 크기, 제약사항을 지정하는 것(예 : 학점의 도메인은 0.0~4.0사이의 실수 값, 주소의 도메인은 n자리 이내의 문자열)

ㆍ 해당업무에서 사용하는 이름을 부여하고 서술식 속성명은 사용하지 않아야함.

ㆍ 약어사용은 가급적 제한하고 전체 데이터 모델에서 유일성을 확보해야함.

 

3. 관계(Relationship)

① 개념

ㆍ 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태

ㆍ 엔터티의 정의 및 속성 정의, 관계 정의에 따라서 다양한 형태로 나타날 수 있음.

ㆍ 인스턴스가 개별적으로 관계를 가지는 것을 페어링(Pairing)이라고 부르고, 페어링의 집합을 관계로 표현함. 만약 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있으면 두 엔터티 사이에 2개 이상의 관계가 형성될 수 있음.

 

② 분류

ㆍ 연결목적에 따른 분류

- 존재에 의한 관계 : 부서-사원과 같이 존재의 형태에 따라 관계가 형성되는 관계(UML에서의 연관관계와 유사)

- 행위에 의한 관계 : 고객-주문과 같이 행위의 발생여부에 따라 관계가 형성되는 관계(UML에서의 의존관계와 유사)

관계

 

③ 표기법

ㆍ 관계명(Membership)

- 엔터티가 관계에 참여하는 형태를 지칭하며, 관계가 시작되는 관계시작점(The Beginning)과 부르고 받는 관계끝점(The End)로 구분됨

- 참여자의 관점에 따라 관계이름은 능동적(Active)이거나 수동적(Passive)으로 명명됨.

- 애마한 동사를 피하고 현재형으로 표현해야함.

 

ㆍ 관계차수(Degree/Cardinality)

- 엔터티 간 관계에서 참여자의 수를 표현하는 것을 지칭하며, 1:1, 1:M, M:N와 같은 관계 표현방법이 있음.

- M:N관계의 경우 이후에 2개의 주식별자를 상속받은 관계엔터티를 활용하여 3개의 엔터티로 구분하여 표현함.

 

ㆍ 관계선택사항(Optionality)

- 필수참여(Mandatory Membership) : 엔터티 간의 관계가 반드시 성립해야하는 관계로 주문서와 주문목록의 관계가 이에 해당함.

- 선택참여(Optional Membership) : 엔터티 간의 관계가 선택적으로 성립하는 관계로 목록과 주문목록의 관계가 이에 해당하며, 물리속성에서 FK로 연결될 경우 Null을 허용할 수 있음.

 

④ 관계 정의시 유의사항

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

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

ㆍ 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

ㆍ 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

 

4. 식별자(Identifier)

① 개념

ㆍ 하나의 엔터티 내에 구성되어 있는 여러 속성들 중에 엔터티를 대표할 수 있는 속성을 지칭하며, 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야하며, 엔터티 내의 인스턴스들을 구분할 수 있는 구분자임.

ㆍ 식별자와 키는 거의 유사한 개념이나, 식별자는 논리 데이터 모델링에서 업무적으로 구분이 되는 정보로 사용하고, 키는 물리 데이터 모델링에서 DB 테이블에 접근을 위한 매개체로 사용함.

식별자

 

② 분류 

ㆍ 대표성의 여부에 따른 분류

- 주식별자(Primary Identifier) 와 보조 식별자(Alternate Identifier / 대체식별자 또는 후보식별자라고 부르기도 함.)

특 징	내 용	비 고
대표성	엔터티 내의 각 인스턴스들을 구분할 수 있는 구분자이며, 타 엔터티와 참조관계를 연결할 수 있는 식별자여야함.	주식별자는 대표성을 가지며, 보조 식별자는 대표성만 없고 하기 4가지의 특성을 가지는 후보식별자임.
유일성	주식별자에 의해 엔터티 내의 모든 인스턴스들을 유일하기 구분할 수 있어야 함.	사원번호는 모든 직원들에 대해 개인별로 고유하게 부여됨.
최소성	주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함.	생년월일과 이름을 합쳐서 만든 식별자와 같이 여러개의 속성을 합쳐서 만든 식별자는 부적절한 주식별자임.
불변성	주식별자가 한 번 지정되면 그 식별자의 값은 변하지 않아야 함.	사원번호의 값이 변한다는 것은 이전 기록이 말소되고 새로운 기록이 발생되는 개념임.
존재성	주식별자가 지정되면 반드시 데이터 값이 존재해야함.(NOT NULL)	모든 사원은 사원번호를 가져야함.

ㆍ 독립적으로 생성이 가능한가에 따른 분류

항 목	설 명
내부식별자	엔터티 내부에서 스스로 만들어지는 식별자
외부식별자 (Foreign Identifier)	타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자

ㆍ 속성의 수에 따른 분류

항 목	설 명
단일식별자 (SIngle Identifier)	하나의 속성으로 구성된 식별자
복합식별자 (Composite Identifier)	둘 이상의 속성으로 구성된 식별자

ㆍ 기존의 식별자 속성을 대체하여 만든지에 따른 분류

항 목	설 명
본질식별자	업무에 의해 자연적으로 생성되는 식별자
인조식별자	원조식별자가 복잡한 구성을 가지고 있어 편의성을 위해 인위적으로 만든 식별자

 

③ 주식별자 도출기준

ㆍ 업무에서 자주 이용되는 속성을 주식별자로 지정하고 명칭, 내역 등과 같이 이름으로 기술되는 것(데이터 양이 많을 확률이 높음.)을 피해야함.

ㆍ 속성의 수가 많아지지 않도록 해야함.(지나치게 많아지면 인조식별자를 생성하여 대체해야하는데 이는 PK의 길이가 길수록 복잡한 SQL 문을 사용해야하기 때문임.)

# 지나치게 긴 PK 사용의 나쁜 예시
SELECT 연봉
FROM ★★컴퍼니
WHERE 1=1
  AND 이름 = '홍길동'
  AND 생년월일 = '1992.10.25'
  AND 입사일 = '2020-01-08'
  AND 직급 = '대리'
  AND 부서 = 'QA Team'
  AND 인사고과 = 'A'

 

④ 식별자관계와 비식별자관계에 따른 식별자

ㆍ 식별자 관계(Identifying Relationship) : 상속받은 부모 엔터티의 식별자를 자식 엔터티의 주식별자로 이용하는 관계

ㆍ 비식별자 관계(Non-Identifying Relationship) : 상속받은 부모 엔터티의 식별자를 자식 엔터티의 일반 식별자로 사용하는 관계 

항 목	식별자 관계	비식별자 관계
목 적	강한 연결관계 표현	약한 연결관계 표현
자식 주식별자 영향	자식 주식별자 구성에 포함됨.	자식 일반속성에 포함됨.
표기법	실선	점선
연결 고려사항	반드시 부모엔터티에 종속 자식 주식별자 구성에 부모 주식별자 포함필요 상속받은 주식별자 속성을 타 엔터티에 이전 필요	약한 종속관계 자식 주식별자구성을 독립적으로 구성 자식 주식별자 구성에 부모 주식별자 부분 필요 상속받은 주식별자 속성을 타 엔터티에 차단 필요 부모쪽의 관계참여가 선택관계

ㆍ 식별자 관계로만 모델링을 진행할 경우의 문제

- 지속적으로 식별자 관계를 연결한 데이터 모델의 PK속성의 수가 데이터 모델 흐름이 길어질 수록 증가할 수밖에 없음.

# 식별관계로만 연결시 하위 엔터티에서 정보 조회시 발생하는 문제점
SELECT *
FROM 테이블1 AS A, 테이블2 AS B, 테이블3 AS C
WHERE 1=1
  AND A.PLANT = B.PLANT
  AND A.EQUIPMENT_ID = B.EQUIPMENT_ID
  AND A.STATUS_SEQ = B.STATUS_SEQ
  AND A.EVENT_ID = B.EVENT_ID
  AND A.TRANS_TIME = B.TRANS_TIME
  AND A.ITEM_CD = B.ITEM_CD
  AND A.PLANT = C.PLANT
  AND A.EQUIPMENT_ID = C.EQUIPMENT_ID
  AND A.STATUS_SEQ = C.STATUS_SEQ
  AND A.EVENT_ID = C.EVENT_ID
  AND A.TRANS_TIME = C.TRANS_TIME
  AND A.ITEM_CD = C.ITEM_CD

 

ㆍ 비식별자 관계로만 모델링을 진행할 경우 문제점

- 자식 엔터티가 부모 엔터리를 조회시 불필요한 JOIN들이 다량으로 유발되면서 SQL문도 길어지고 성능도 저하됨.

이력유형 데이터모델링의 A to Z 식별자관계와 비식별자관계 설정 이것만은 알고 하자

ㆍ 비식별자관계 선택 프로세스

관계분석	→	관계의 강약 분석	→	자식테이블 독립PK요구	→	SQL복잡도 증가, 개발생산성 저하
		↓	약한관계	↓	독립 PK구성	↓	PK속성 단순화
비식별자 관계 설정 고려

 

P.S 더 나은 개발자가 되기위해 공부중입니다. 잘못된 부분을 댓글로 남겨주시면 학습하는데 큰 도움이 될 거 같습니다.

+ 본 글은 「SQL 전문가 가이드, 한국 데이터베이스 진흥원」참고하여 작성하였습니다.