3. 데이터 모델링 요소

3.1. 엔터티 (Entity)

엔터티의 개념

엔터티의 개념

엔터티는 데이터 모델의 핵심 구성 요소이기 때문에 이에 대한 이해가 필수적입니다. 엔터티는 개체라고 표현하며 정보의 세계에서 의미 있는 하나의 정보 단위를 뜻합니다. 사물의 본질적인 성질을 '속성'이라고 하며, 관련 있는 속성들이 모여서 의미 있는 하나의 정보 단위를 이룬 것이 바로 개체에 해당합니다. 데이터베이스에서 레코드가 개체에 해당합니다. 개체 사이의 연관성을 관계라고 하며, 개체와 관계를 나타낸 모델을 개체 관계 모델(Entity-Relationship model)이라고 합니다. 엔터티의 사전적 의미는 ‘독립체’이며 쉽게 말해 업무에서 쓰이는 데이터들을 분류한 그룹이라고 할 수 있습니다.

엔터티와 인스턴스

엔터티와 인스턴스의 관계는 여러 가지 방법으로 표현할 수 있습니다. 아래의 왼쪽 그림처럼 ERD로 표현할 수도 있고 오른쪽 그림처럼 표로 표현할 수도 있습니다. 표현하고자 하는 바는 같지만 다른 형태로 표현 했음을 알 수 있습니다.

조금 더 구체적인 예시를 살펴보겠습니다. 아래와 같이 '사원' 정보를 담고 있는 테이블이 있다고 가정해 봅시다. 여기서 Entity는 바로 테이블에 해당합니다. 엔터티는 업무에서 필요로 하는 정보를 저장하기 위한 무언가를 의미한다고 했습니다. 사원에 대한 정보를 행과 열을 2차원 구조로 저장하여 관리하고 이는 업무에서 활용 가능하기 때문에 엔터티라고 할 수 있습니다. 그렇다면 인스턴스는 무엇을 의미할까요? 인스턴스는 데이터베이스 테이블에 저장된 특정한 데이터 내용의 전체 집합 즉, 하나의 row(행)를 의미합니다. 아래 테이블에서는 한 명의 사원이 가질 수 있는 모든 내용을 포함한 요소가 인스턴스가 되겠죠. 뒤쪽 레슨에서 등장하겠지만 하나의 인스턴스가 갖는 각각의 특징을 속성(attribute)이라고 하고 이는 테이블의 세로(column) 영역에 해당합니다.

위의 표를 통해서 살펴볼 수 있듯 하나의 엔터티(사원 테이블)는 여러 인스턴스(하나의 행)를 가질 수 있고 하나의 인스턴스는 1개 이상의 속성(이름, 사번, 부서, 직책)을 가질 수 있습니다.

엔터티의 특징

엔터티는 여러 특징을 갖는데, 그중에서 핵심적으로 다뤄지는 6가지 특징에 대해 먼저 살펴보겠습니다

업무에서 필요로 하는 정보

• 엔터티는 특정한 업무에서 필요로 하는지를 파악하는 것이 중요합니다.
• 데이터를 수집하고 관리하는 목적은 기본적으로 업무에서 활용하기 위해서이기 때문입니다.

식별 가능 여부

• 엔터티를 도출하는 경우에는 업무적으로 의미를 갖는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증해야 합니다.

인스턴스의 집합

엔터티는 기본적으로 2개 이상의 인스턴스로 구성되어 있어야 합니다.

• 인스턴스가 한 개 밖에 없는 엔터티는 집합이 아니기 때문에 엔터티가 아닙니다.

업무 프로세스에 의해 활용되어야 함

엔터티는 업무 프로세스에 활용되어야 합니다.

• 만약 활용되지 않는 엔터티가 있을 경우에는 해당 엔터티를 제거하거나 프로세스에서 놓치고 있는 부분은 없는지 확인해야 합니다.

속성을 포함해야 함

주식별자만 존재하고 일반 속성은 전혀 없는 경우 엔터티가 아닙니다.

• 엔터티는 엔터티를 설명할 수 있는 속성이 존재해야 의미를 갖습니다.

관계의 존재

엔터티가 도출되었다는 것은 해당 업무에서 어떠한 연관성을 갖고 다른 엔터티와의 연관성이 있음을 나타냅니다.

• 관계가 설정되지 않은 엔터티는 부적절한 엔터티가 도출되었거나 아니면 다른 엔터티와의 직접적인 연결 관계를 찾지 못했을 수 있습니다.

엔터티의 분류

유/무형에 따른 분류

유형 엔터티,개념 엔터티,사건 엔터티

발생 시점에 따른 분류

기본/키 엔터티, 중심 엔터티, 행위 엔터티

엔터티 분류 방법의 예시

유/무형에 따라 : 유형, 개념, 사건
발생시점에 따라 : 기본키, 중심, 행위

엔터티의 이름짓기 방식

엔터티는 고유한 이름을 갖게 되는데, 이때 특징한 규칙을 기반으로 이름 짓기(네이밍)를 합니다

1. 가능하면 업무에서 사용하는 용어를 사용합니다.
2. (가능하면) 축약어(shortcut)를 사용하지 않습니다.
   • 의미가 온전하게 드러날 수 있도록 작성합니다.
3. 단수 명사를 사용하고 띄어쓰기를 하지 않습니다.
4. 모든 엔터티에서 유일한 이름이 부여되어야 합니다.
   • 즉, 엔터티 이름은 중복되지 않아야 합니다.
5. 엔터티 생성 의미대로 이름을 부여합니다.

연습문제

1번

Q. 문제	다음 중 키 엔터티로 볼 수 없는 것은?
A. (1)	고객
A. (2)	상품
A. (3)	회원
A. (4)	배송

정답
주문한 내역에 대해서 배송을 하는 것이므로 배송은 행위 엔터티라고 할 수 있다.

2번

Q. 문제	다음 중 엔터티의 특징으로 옳지 않은 것은?
A. (1)	1개 이상의 인스턴스를 가지고 있어야 한다
A. (2)	주식별자만 존재하고, 일반 속성은 전혀 없는 경우 엔터티가 아니다
A. (3)	업무에서 관리하고자 하는 정보여야 한다
A. (4)	엔터티는 엔터티를 설명할 수 있는 속성이 존재해야 의미를 갖는다

정답
엔터티는 2개 이상의 인스턴스를 가지고 있어야 한다.

3번

Q. 문제	다음 중 엔터티명으로 옳은 것은?
A. (1)	고객들
A. (2)	주문
A. (3)	회원 탈퇴
A. (4)	배송지주소

정답

• 답지 (1) : 단수로 명명해야 한다.
• 답지 (3) : 띄어쓰기를 하지 않는다.
• 답지 (4) : 배송지주소는 속성이라고 하는 것이 더 타당하다.

3.1. 속성 (Attribute)

속성의 개념

속성의 개념

속성은 인스턴스가 가진 어떠한 성질(성격)입니다. 엔터티 파트를 학습하면서 정리를 했었죠? 엔터티가 테이블 전체를 의미하면 테이블에서 하나의 데이터 집합을 의미하는 행(row) 하나하나가 개별 인스턴스였고 이런 인스턴스가 갖는 개별 특징을 속성(attribute)이라고 불렀습니다. 하나의 인스턴스는 최소 하나 이상의 속성을 갖습니다. 정리하면 속성은 '업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위'라고 할 수 있습니다

엔터티의 개념 정리
1. 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당
2. 엔터티는 업무상 관리가 필요한 관심사에 해당
3. 엔터티는 저장이 되기 위한 어떤 것(Thing)

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

• 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 합니다.
• 한 개의 엔터티는 두 개 이상의 속성으로 구성됩니다.
• 한 개의 속성은 한 개의 속성값을 갖습니다.

속성의 표기법

IE 표기, Barker 표기

속성의 특징 및 분류

속성의 특징

1. 속성은 업무에서 필요로 합니다.
   아무 요소나 모두 속성이 되지 않고 업무에 관련된 어떤 특징이 속성이 될 수 있다.(해당 업무에서 관리하고자 하는 정보여야 함)

2. 속성은 의미상 더 이상 분리되지 않는, 그 자체로 독립성을 유지합니다. (가장 작은 단위로 의미를 지닙니다.)

3. 엔터티를 설명하고 인스턴스의 구성요소가 됩니다.
   속성을 통해 인스턴스가 구성되며 인스턴스가 모여 엔터티가 되기 때문에 결과적으로 엔터티를 설명한다고 볼 수 있다.

4. 정규화 이론에 기반을 두고 정해진 주식별자에 함수적 종속성을 가져야 합니다.
   

함수적 종속성 (Functional Dependency)
X → Y (X: 결정자, Y: 종속자)
X의 값을 알면 Y의 값을 바로 알 수 있고 X 값에 의해 Y 값이 달라질 때, 이를 Y는 X에 함수적 종속이라고 함

• 예시) Q) 학생 테이블에서 학번과 이름은 함수적 종속이 있을까?
• X → Y / 학번을 알면 이름을 알 수 있고, 학번이 달라지면 이름도 달라지므로 이름은 학번에 함수적인 종속 관계가 있음.
  

함수적 종속의 종류
- 완전 함수 종속
- 부분 함수 종속
- 이행 함수 종속

5. 하나의 속성은 한 개의 값만 갖습니다.

• 하나의 속성에 여러 개의 값이 있는 다중 값의 형태는 별도의 엔터티로 분류하여 관리합니다.

속성의 분류

속성의 특징에 따른 분류 (기본 속성 / 설계 속성 / 파생 속성)

엔터티 구성 방식에 따른 분류 (PK 속성 / FK 속성 / 일반 속성)

도메인 및 속성의 명명

도메인

각 속성이 가질 수 있는 값의 범위를 의미합니다.

• 엔터티 내에서 속성에 대한 데이터 타입과 크기, 제약 사항 등을 지정합니다.

속성의 명명

속성은 고유한 이름을 갖게 되는데, 이때 특정한 규칙을 기반으로 속성을 명명해야 합니다.

1. 가능하면 업무에서 사용하는 용어를 사용합니다.
2. 가능하면 축약어(shortcut)를 사용하지 않고 의미가 온전하게 드러날 수 있도록 작성합니다.
3. 서술형보다는 명사형을 사용합니다.
4. 수식어가 많이 붙지 않고 명확하게 의미를 파악할 수 있어야 합니다.

• 명시적인 형태로 의미 전달을 할 수 있어야 합니다.

5. 전체 데이터 모델에서 유일하게 작성해야 합니다.

• 이는 데이터 정합성 유지와 반정규화 작업을 수행할 때 속성의 충돌을 해결하는 데 도움이 됩니다.

연습문제

1번

Q. 문제	엔터티, 인스턴스, 속성, 속성값의 관계에 대한 설명으로 옳지 않은 것은?
A. (1)	한 개의 엔터티는 두 개 이상의 속성으로 구성된다
A. (2)	한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다
A. (3)	한 개의 인스턴스는 여러개의 속성값을 갖는다
A. (4)	한 개의 속성은 한 개 이상의 속성값을 갖는다

정답
한 개의 속성은 한 개의 속성값을 갖습니다

2번

Q. 문제	속성의 특징에 따른 분류로 옳지 않은 것은?
A. (1)	설계 속성
A. (2)	파생 속성
A. (3)	일반 속성
A. (4)	기본 속성

정답
속성의 특징에 따른 분류 : 기본속성, 설계속성, 파생속성

3번

Q. 문제	엔터티를 식별할 수 있는 ‘PK 속성’의 예시로 옳지 않은 것은?
A. (1)	회원명
A. (2)	직원 사번
A. (3)	학생 학번
A. (4)	상품 코드

정답
회원명은 PK, FK를 제외한 나머지 속성 ‘일반속성’에 해당한다

3.1. 관계 (Relationship)

관계의 개념

관계의 정의

관계(Relationship)를 사전적으로 정의하면 '상호 연관성이 있는 상태'라고 할 수 있습니다. 상호 연관성이 있다는 것은 무엇을 의미할까요? 데이터 모델에 대입하여 정의해 보면 '엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태'라고 할 수 있습니다. 관계는 엔터티와 엔터티 간 연관성을 표현하기 때문에 엔터티의 정의에 따라 영향을 받기도 하고 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있습니다.
예를 들어보겠습니다. '선생님'이라는 엔터티가 존재하고 '학생'이라는 엔터티가 존재할 때 각 인스턴스는 어떠한 관계로 연결될 수 있습니다. '가르친다', '배운다'라는 관계로 정의할 수 있는데, 이는 두 엔터티 사이의 상호 연관성이 있는 상태로 볼 수 있습니다. 선생님이라는 엔터티가 학생 엔터티와 맺는 관계는 데이터베이스 상에서 표현할 때 엔터티와 엔터티의 관계 맺음이라고 표현할 수 있습니다. 이때 학생 엔터티 입장에서 선생님 엔터티와 맺는 반대 관계도 마찬가지의 결과를 얻어낼 수 있습니다.
관계에 대한 정의를 다시 정리해 보면 '엔터티와 인스턴스 사이의 논리적인 연관성으로서 존재의 형태 행위로서 서로에게 연관성이 부여된 상태'로 볼 수 있습니다.

관계의 페어링

관계는 엔터티 안에 인스턴스가 개별적으로 연결되어 있는 구조이며 이러한 관계를 '페어링'이라고 부릅니다. 이러한 연결 관계의 집합을 관계로 표현할 수 있습니다. 개별 인스턴스가 각각 다른 종류의 관계를 가진다면 두 엔터티 사이에 두 개 이상의 관계 형성도 가능하다고 볼 수 있습니다.

각 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계 페어링(Relationship Paring)이라고 합니다.

위의 그림에서 오른쪽에 있는 개별 인스턴스들은 개별 연관성을 지니며 이 개념을 하나로 모아서 '강의'라는 관계를 도출해낼 수 있습니다. 강사는 수강생에게 강의를 하는데, 이러한 관계를 통해 '강의'라는 관계를 도출할 수 있습니다.

관계의 분류

관계는 크게 어떤 목적으로 연결 지어졌는지에 따라서 '존재에 의한 관계'와 '행위에 의한 관계' 2가지로 분류할 수 있습니다.

관계의 종류

1. 존재에 의한 관계
   존재에 의한 관계를 기준으로 인스턴스 간의 관계를 살펴보면 소속/포함의 형태로 볼 수 있습니다.

• 회사에서 사원이 언제나 특정한 부서에 속해있는 것은 존재에 의한 관계로 볼 수 있습니다.

2. 행위에 의한 관계
   행위에 의한 관계를 기준으로 인스턴스 간의 관계를 살펴보면 행동/행위의 결과로 나타납니다.

• 어떤 서비스를 제공할 때 고객이 주문을 하는 경우에 '주문'이라는 행동은 고객이 직접 행해야 발생하기 때문에 행위에 의한 관계로 볼 수 있습니다.
  

UML(Unified Modeling Language) - 통합 모델링 언어

통합 모델링 언어는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어입니다. 추상화된 시스템을 특정한 모델로 표현해 주는 언어를 의미합니다. 여러 종류의 UML 다이어그램을 통해 시각화된 형태의 모델링 된 결과를 살펴볼 수 있습니다.

UML을 사용하는 목적
1. 의사소통 및 시스템 설계를 논의하기 위해 사용합니다.
2. 전체 시스템의 구조 및 클래스의 의존성 관계를 쉽게 파악하기 위해 사용합니다.
3. 시스템의 유지 보수를 위한 설계 등의 문서 제작을 위해 사용합니다.

UML의 '클래스 다이어그램'은 정적 다이어그램으로 클래스의 구성요소 및 클래스 간의 관계를 표현하는 대표적인 UML입니다. 시스템의 일부 혹은 전체 구조를 보여주며 의존 관계를 명확하게 보여줍니다. 클래스 다이어그램의 주된 목적은 클래스 간의 관계를 한눈에 보기 쉽게 만드는 것입니다. 따라서 클래스 간의 관계를 명확하게 표현하는 것이 핵심입니다. 아래 그림처럼 특정한 표기법을 통해 클래스 간의 관계를 나타낼 수 있습니다.

클래스 다이어그램의 관계는 연관관계(Association)과 의존관계(Dependency)가 있습니다. 연관관계(실선)는 항상 이용하는 관계로 존재적 관계에 해당합니다. 의존관계(점선)는 상대방 클래스에 의해 관계가 형성될 때를 구분하여 표현합니다. ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표현했다면 클래스 다이어그램에서는 이를 구분하여 연관 및 의존 관계로 표현합니다.

관계의 표기법

관계명 (Membership)

관계의 이름이 어떻게 설정되는지 명명할 수 있습니다. 관계명은 엔터티가 관계에 참여하는 형태를 지칭하는데, 각 관계는 두 개의 관계명을 갖게 됩니다. 관계가 시작되는 쪽을 ‘관계시작점’이라 칭하며 받는 쪽을 ‘관계끝점’이라고 칭합니다. 또한 각각의 관계명에 대해 두 가지 관점으로 표현하는 것이 가능합니다.
아래의 예시를 생각해 보면 부서의 입장에서 사원은 '포함하는' 관계로 볼 수 있습니다. 반대로 사원의 입장에서 부서는 '소속되는 대상'의 관계로 볼 수 있습니다. 이처럼 엔터티가 참여하는 형태는 어떤 관계를 맺고 있느냐가 결정한다고 볼 수 있습니다.

관계 표기법

IE 표기 기준

관계차수 (Degree / Cardinality)

두 개의 엔터티 간의 관계에서 참여자의 수를 표현하는 것을 관계차수(Cardinality)라고 합니다. 가장 일반적인 관계 표현 방식은 1:1, 1:M, M:M이 있습니다. 관계 차수를 표현하는 방법은 여러 가지가 있지만 까마귀 발 모델을 가장 많이 사용하고 선을 이용하여 표현합니다. 한 개가 참여하는 경우는 실선을 그대로 유지하고 다수가 참여하는 경우는 까마귀발 모양으로 그려주면 됩니다.

1. 1:1 (ONE TO ONE) 관계 표시

• 관계에 참여하는 각 엔터티는 관계를 맺는 다른 엔터티에 대해 하나의 관계로 연결됩니다.
• A Entity에 존재하는 데이터 1개와 관계되는 B Entity에 존재하는 데이터의 개수도 1개인 Entity 간의 관계를 1:1 관계라고 합니다.
• 예를 들면, 웹 서비스에서 유저와 프로필 간의 관계를 생각해 볼 수 있습니다. 하나의 유저는 하나의 프로필을 갖습니다. 프로필 입장에서는 유저와 직접 연결되고 유저의 입장에서도 프로필과 대응하기 때문에 이 관계는 1:1 관계라고 할 수 있습니다.
  

2. 1:M (ONE TO MANY) 관계 표시

• 관계에 참여하는 각 엔터티는 관계를 맺는 다른 엔터티에 하나 혹은 그 이상의 관계를 맺고 있습니다. 다만, 이 방향은 한쪽 방향에만 해당되며 반대 방향은 오직 하나의 관계만 갖습니다.
• A Entity에 존재하는 데이터 1개와 관계되는 B Entity에 존재하는 데이터의 개수가 여러 개인 엔터티 간의 관계를 1:M 관계라고 합니다.
• 예를 들면, 웹 서비스에서 댓글과 게시글의 관계를 생각해 볼 수 있습니다. 하나의 게시글에는 여러 개의 댓글이 달릴 수 있습니다. 게시글은 댓글이 있어도 되고 없어도 되지만 댓글은 반드시 게시글이 있어야 합니다. 이러한 관계를 1:N 관계라고 합니다.
  

3. M:N(MANY TO MANY) 관계 표시

• 1:M 관계가 양방향에서 모두 발생하는 경우를 의미합니다. 이렇게 M:N 관계로 표현된 데이터 모델은 이후에 두 개의 주식별자를 상속받은 관계 엔터티를 이용하여 3개의 엔터티로 구분하여 표현합니다.

• A Entity에 존재하는 데이터 1개와 관계되는 B Entity에 존재하는 데이터의 개수가 여러 개이며, B Entity에 존재하는 데이터 1개와 관계되는 A Entity에 존재하는 데이터의 개수도 여러 개인 Entity 간의 관계를 M:N 관계라고 합니다.

• 예를 들면, 웹 서비스에서 좋아요 기능을 생각해볼 수 있습니다. 좋아요 기능은 게시글과 유저간의 관계로 구현됩니다. 하나의 게시글에는 여러 명의 유저가 '좋아요'를 누를 수 있습니다. 이 관계는 1:N 관계로 볼 수 있습니다. 이번에는 반대로 생각해 볼까요? 하나의 유저 입장에서는 본인이 누른 여러 개의 좋아요 게시글이 존재합니다. 이 관계 또한 1:N이라고 할 수 있습니다. 결국, 서로가 서로에게 1:N의 관계를 갖는 형태를 M:N 관계라고 합니다.
  

관계선택사양 (Optionality)

데이터 모델 관계에서는 '선택참여관계(Optional)'가 핵심입니다. 참여하는 엔터티가 항상 참여하는지 아니면 참여할 수도 있는지를 나타내는 방법으로 필수(Mandatory Membership)와 선택참여(Optional Membership)가 있습니다.

필수 조건
필수 사항은 실선으로 표시하고 상대 Entity에 대한 해당 조건을 만족하는 Entity가 반드시 존재할 경우에 표시합니다.

• 예를 들어, 게시글과 댓글의 관계에서 하나의 댓글은 게시글 없이는 존재할 수 없기 때문에 게시글은 반드시 존재해야 합니다.
• |로 표현합니다 (IE)

선택 조건

• 선택 사항은 점선으로 표시하고 상대 Entity에 대한 해당 조건을 만족하는 Entity가 존재할 수도 혹은 하지 않을 수도 있는 경우 표시합니다.
• 예를 들어, 게시글에는 댓글의 관계에서 하나의 게시글에는 댓글이 달릴 수도 있고 달리지 않을 수도 있습니다.
• O로 표현합니다 (IE)
  

관계선택사양을 IE와 Barker 표기법을 통해 나타내면 아래와 같습니다.

관계의 정의 및 읽는 방법

관계 정의 시 체크 사항

두 엔터티 사이의 관계를 정의할 때 체크 사항

• 두 엔터티 사이에는 관심 있는 연관 규칙이 존재하는지 여부
• 두 개의 엔터티 사이에 정보의 조합이 발생하는지 여부
• 업무 기술서, 장표에 관계 연결에 대한 규칙이 있는지 여부
• 업무 기술서, 장표에 관계 연결을 가능하게 하는 동사(Verb)가 있는지 여부

하나의 Entity는 적어도 두 개 이상의 Attribute를 갖고 Entity끼리는 어떠한 Relationship을 갖는 구조로 되어있다고 정리할 수 있습니다.

관계 읽기

데이터 모델을 읽는 방법은 관계에 참여하는 기준 엔터티를 하나 또는 각(Each)으로 읽고 대상 엔터티의 개수를 읽고(하나하나씩) 관계 선택 사양과 관계의 이름을 읽습니다.

'관계'를 읽는 방법

• 기준(Source) 엔터티를 한 개(One) 혹은 각(Each)으로 읽습니다.
• 대상(Target) 엔터티의 관계 참여도 개수(하나, 하나 이상)로 읽습니다.
• 관계 선택 사양과 관계 이름을 읽습니다.

관계 읽기 연습

연습문제

1번

Q. 문제	관계의 분류에 대한 설명으로 옳지 않은 것은?
A. (1)	존재에 의한 관계 : 고객이 배송지 주소를 입력한다
A. (2)	존재에 의한 관계 : 사원은 부서에 속해있다
A. (3)	행위에 의한 관계 : 고객이 주문을 한다
A. (4)	행위에 의한 관계 : 고객이 리뷰를 작성한다

정답
고객이 배송지에 주소를 입력하는 것은 ‘입력’이라는 행동을 직접 행해야 발생하므로 행위에 의한 관계로 볼 수 있다

2번

Q. 문제	두 엔터티 사이의 관계를 정의할 때 체크 사항으로 옳지 않은 것은?
A. (1)	두 엔터티 사이에는 관심 있는 연관 규칙이 존재하는지 여부
A. (2)	업무 기술서, 장표에 관계 연결을 가능하게 하는 명사가 있는지 여부
A. (3)	업무 기술서, 장표에 관계 연결에 대한 규칙이 있는지 여부
A. (4)	두 개의 엔터티 사이에 정보의 조합이 발생하는지 여부

정답
업무 기술서, 장표에 관계 연결을 가능하게 하는 동사가 있는지 여부

3.1. 식별자 (Identifier)

식별자의 개념 및 특징

식별자의 개념

이전 레슨에서 엔터티는 인스턴스들의 집합임을 학습했습니다. 엔터티가 테이블을 의미한다면 행 한 줄은 인스턴스로 표현되며 엔터티는 인스턴스들의 집합이었습니다. 하나의 엔터티와 여러 개의 인스턴스로 구성된 이러한 그룹은 여러 개의 집합체를 담고 있는 하나의 그룹에서 각각을 구분할 수 있는 논리적인 이름이 필요합니다. 그런 이름이 없다면 구분 자체가 어렵습니다. 이렇게 집합체를 구분할 수 있는 구분자를 식별자(Identifiers)라고 합니다. 식별자란 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에서 엔터티를 대표할 수 있는 속성을 의미합니다. 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 합니다.

주식별자의 특징

유일성/최소성/불변성/존재성

대체 식별자의 특징은 주식별자의 특징과 일치하지만 외부 식별자는 별도의 특징이 있습니다. 외부 식별자의 경우, 참조 무결성(Referential Integrity) 제약 조건에 따른 특징을 갖고 있습니다. 이 부분에 대해서 조금 더 자세하게 알아보겠습니다.

식별자 분류 및 표기법

식별자 분류

식별자의 종류는 자신의 엔터티 내에서 대표성을 갖는지에 따라 주식별자(Primary Identifier)와 보조식별자(Alternate Identifier)로 구분합니다. 엔터티 내에서 스스로 생성되었는지에 따라 내부 식별자와 외부 식별자로 구분할 수도 있습니다. 만약 속성의 개수를 기준으로 구분을 한다면 단일 속성으로 식별되는지의 여부에 따라서 단일 식별자(Single identifier)와 복합 식별자(Composite Identifier)로 구분할 수도 있습니다.

대표성 여부 / 스스로 생성 여부 / 단일속성 여부 / 대체 여부

참고 - 어커런스(Occurence)
인스턴스(Instance)와 같은 의미로 정의된 레코드의 구조에 따라 데이터베이스에 구체적이고 실제적인 정보를 담고 있는 실제 데이터를 의미합니다. 엔터티를 구성하고 있는 각 속성값들이 각각 값을 가지고 있는 상태이기 때문에 데이터베이스에서 값이 있는 테이블의 '행(row)'을 의미한다고 볼 수 있습니다.

대표성 여부

식별자 종류	설명
주식별자 (Primary Identifier)	엔터티 내에서 각 인스턴스를 구분할 수 있는 구분자이며 다른 엔터티와 참조 관계를 연결할 수 있는 식별자입니다.
보조 식별자 (Alternate Identifier)	엔터티 내에서 각 인스턴스를 구분할 수 있는 구분자이나 대표성을 갖지 못해 참조 관계 연결을 하지 못합니다.

스스로 생성 여부
| 식별자 종류 | 설명 |
| --- | --- |
| 내부 식별자 | 엔터티 내부에서 정의되는 식별자입니다. |
| 외부 식별자 | 다른 엔터티와의 관계를 통해 다른 엔터티로부터 받아오는 식별자입니다. |

속성의 수
| 식별자 종류 | 설명 |
| --- | --- |
| 단일 식별자 | 하나의 속성으로 구성된 식별자입니다. |
| 복합 식별자 | 둘 이상의 속성으로 구성된 식별자입니다. |

대체 여부
| 식별자 종류 | 설명 |
| --- | --- |
| 본질 식별자 | 업무에 의해 만들어지는 식별자입니다. |
| 인조 식별자 | 업무적으로 만들어지지는 않지만 원조 식별자가 복잡한 구성을 갖고 있기 때문에 인위적으로 만든 식별자입니다. |

하나의 엔터티 내에서 식별자로 사용할 수 있는 하나 이상의 키를 후보 식별자라고 합니다. 그 중에서 엔터티의 대표성을 나타내는 유일한 식별자를 주식별자라고하며 나머지를 보조식별자라고 표현합니다. 물리 모델에서 주식별자는 PK(Primary Key) 역할을 하고 보조 식별자는 Unique Index로 지정하여 관리합니다.

• 예를 들어, 학번 엔터티에서 학생의 이름, 학번, 주민번호 등이 있다고 생각해볼 때 3가지 모두 후보 식별자입니다. 그 중에서 엔터티의 대표성을 나타낼 수 있는 학번은 주식별자, Unique 인덱스로 지정 할 수 있는 주민 번호는 보조 식별자로 볼 수 있습니다.

식별자 표기법

식별자에 대한 분류 방법을 데이터 모델을 통해서 표현하면 아래와 같습니다.

주식별자 도출 기준

데이터 모델링을 하는 과정에서 중요한 작업 중 하나는 주식별자를 도출하는 작업입니다. 주식별자는 엔터티를 대표하는 속성을 갖고 있기 때문에 여러 가지 조건을 만족해야 합니다. 도출 과정에서 생각해야 하는 기준을 나열해 보면 다음과 같습니다.

해당 업무에서 자주 이용되는 속성으로 설정합니다.

'학생' 엔터티가 있을 때 유일하게 식별 가능한 속성은 주민등록번호와 학번이 있습니다. 학번이 학교에서 학생을 관리할 때 사용하는 일반적인 식별자이기 때문에 학번을 주식별자로 지정하고 주민번호는 보조 식별자로 활용 가능합니다.

명칭, 내역 등과 같이 특정한 이름으로 기술되는 것은 가능하면 주식별자로 사용하지 않습니다.

한 회사에 부서 이름이 50개 있다면 각 부서 이름은 유일하게 구분되기 때문에 주식별자로 사용하고 싶을 수 있습니다. 하지만 부서 이름이 주식별자가 된 상황에서 물리 데이터베이스로 테이블을 생성하여 데이터를 읽는 경우 부서를 찾기 위해 항상 맞는지 여부를 검사해야 합니다. 부서 이름이 길어지는 경우 이에 대한 대응을하는 것도 쉽지 않습니다.
만약 부서 이름을 제외하고 주식별자로 선택 할만한 것이 없다면 어떻게 해야 할까요? 이런 경우는 새로운 식별자를 만들어 주식별자로 생성하면 됩니다. 보통은 일련 번호 혹은 특정한 코드를 생성하여 해결합니다.

복합으로 주식별자를 구성하는 경우 너무 많은 속성이 포함되지 않도록 해야합니다.

주식별자로 선정하기 위한 속성이 복합으로 구성되어 주식별자가 될 수 있을 때 가능하면 주식별자를 선정하기 위한 속성의 수를 많이 두지 않는 것이 좋습니다. 속성의 수가 많으면 데이터 모델을 복잡하기 만들고 추후 SQL문의 복잡도를 증가시킬 수 있습니다. 만약 주식별자로 설정하기 위해 속성의 수를 늘려야 하는 경우라면 새로운 인조 식별자(Artificial Identifier)를 생성하여 데이터 모델을 구성하는 것이 좋습니다. 인조 식별자의 경우 해당 엔터티에서 사용하는 식별자는 아니지만 주식별자 속성 설정 등을 위해 임의로 만들어 부여하는 식별자를 의미합니다.

왼쪽 그림에서 '접수' 엔터티에서 특정 접수 방법에 대해서 특정한 날짜에 여러 번 신청하는 상황을 가정해봅시다. 접수의 주식별자로 사용할 수 있는 것이 사실상 표기된 모든 식별자이기 때문에 실제 테이블에는 PK가 7개 생성될 수 있습니다. 만약 이상태에서 계약금에 대한 데이터를 조회해야 한다면 특정한 식별자의 속성에 맞는 값을 가져오기 위해 많은 조건 체크가 필요합니다.

만약 이 상황에서 인조 식별자를 활용하면 어떨까요? 계약금을 조회할 때 접수 일자의 인조 식별자를 통해 조회하면 원하는 데이터를 가져올 수 있습니다. 모든 데이터의 식별자를 필요로 하지 않기 때문에 간결하게 SQL문을 구성할 수 있고 속성에 대한 성능적인 부분을 고민하지 않아도 됩니다.이렇게 데이터 모델 상에 표현하는 문장의 편리함과 성능을 위해서 과도한 복합키의 사용은 지양해야 합니다.

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

식별자 관계와 비식별자 관계의 결정 요인

외부 식별자(Foreign Identifier)는 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽 엔터티에 생성되는 속성을 의미합니다. 데이터베이스를 생성할 때 Foreign Key 역할을 하게 됩니다.
관계와 속성을 정의하고 주식별자를 결정하면 논리적인 관계에 의해 자연스럽게 외부식별자가 도출됩니다. 이 과정에서 고려해야 하는 사항이 있습니다. 엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모 쪽의 주식별자를 자식 엔터티의 속성으로 보내게 됩니다. 이때 자식 엔터티에서 부모 엔터티로부터 받은 외부 식별자를 주식별자로 쓸 것인지 혹은 부모와 연결된 속성(Foreign Key)으로만 이용 할 것인지 결정해야 합니다.

식별자 관계

부모로부터 받은 식별자를 자식 엔터티의 주식별자로 이용하는 경우는 비어있는 값이 있으면 안 됩니다. 부모와 자식의 관계를 연결 함에 있어 어떻게 연결할 것인지에 대한 대상이 없다면 연결할 수 없는 건 당연하다고 할 수 있습니다.
부모로부터 받은 속성을 자식 엔터티가 주식별자로 이용하면 부모 엔터티와 자식 엔터티의 관계는 1:1 관계가 됩니다. 만약 부모로부터 받은 속성을 포함하여 다른 부모 엔터티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성되는 경우는 1:M의 관계가 됩니다.

식별자 관계를 IE 표기법에서는 점선과 실선으로, Barker 표기법에서는 | 의 유무로 표기합니다.

자식 엔터티의 주식별자로 부모 주식별자가 상속되는 경우를 식별자 관계(Identifying Relationship)라고 합니다. 위의 표에서 사원과 임시직사원의 관계와 주식별자를 보면 임시직사원의 주식별자는 사원의 주식별자와 동일하게 사용되기 때문에 이 경우는 1:1 관계라고 볼 수 있습니다. 반면에 사원 엔터티와 발령 엔터티의 관계를 보면 발령 엔터티는 반드시 사원 엔터티가 존재해야 의미가 있고 발령 엔터티의 주식별자도 부모 엔터티의 외부 식별자인 사원번호와 자신의 속성인 발령일자로 구성되어 있음을 알 수 있습니다. 이를 통해서 사원 엔터티와 발령 엔터티의 관계는 1:M의 관계를 이룬다고 말할 수 있습니다.

비식별자 관계

부모 엔터티로부터 속성을 받았지만 자식 엔터티의 주식별자로 사용하지 않고 일반 속성으로만 사용하는 경우를 비식별자 관계(Non-identifying Relationship)라고 하며 다음 네 가지 경우에 비식별자 관계에 의한 외부 속성을 생성합니다.
1. 받은 속성이 필수가 아니어도 무방하기 때문에 부모 식별자가 없는 자식 식별자로 생성되는 경우
2. 엔터티 별로 데이터의 생명 주기를 다르게 관리할 경우
3. 여러 개의 엔터티가 하나로 통합되어 표현되었는데, 각 엔터티가 별도의 관계를 갖는 경우
4. 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단할 경우

식별자 관계로만 설정할 경우의 문제점

식별자 관계로만 연결한 데이터 모델의 PK 속성의 수는 데이터 모델의 흐름이 길어지고 많아질수록 증가할 수밖에 없는 구조를 갖습니다. 이런 과정은 개발 복잡성을 증가시킬 뿐만 아니라 오류를 발생시킬 가능성이 높아지기 때문에 유의해야 합니다.

식별자 관계와 비식별자 관계의 모델링

1. 식별자 관계를 선택하는 프로세스
   

2. 식별자와 비식별자 관계의 비교
   
   목적, 자식 주식별자 영향, 표기법, 연결 고려사항

연습문제

1번

Q. 문제	주식별자로 판단하기에 가장 적절하지 않은 것은?
A. (1)	부서 엔터티의 부서코드
A. (2)	주문 엔터티의 주문번호
A. (3)	학생 엔터티의 학번
A. (4)	사원 엔터티의 사원명

정답
사원 엔터티의 사원명은 특정 고객을 구분할 수 없으므로 주식자별로 적합하지 않다

2번

Q. 문제	주식별자의 특징으로 옳지 않은 것은?
A. (1)	주식별자에 의해 엔터티 내 모든 인스턴스들을 유일하게 구분한다
A. (2)	주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다
A. (3)	특정 엔터티에 지정되면 그 식별자의 값은 변할 수 있다
A. (4)	주식별자가 지정되면 반드시 데이터 값이 존재해야 한다

정답
주식별자의 특징 ‘불변성’에 의해 한 번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 한다

3번

Q. 문제	비식별자 관계에 대한 설명으로 옳지 않은 것은?
A. (1)	자식 엔터티의 주식별자로 부모 주식별자가 상속되는 경우
A. (2)	엔터티 별로 데이터의 생명 주기를 다르게 관리할 경우
A. (3)	여러 개의 엔터티가 하나로 통합되어 표현되었는데, 각 엔터티가 별도의 관계를 갖는 경우
A. (4)	자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단할 경우

정답
자식 엔터티의 주식별자로 부모 주식별자가 상속되는 경우 식별자 관계에 대한 설명이다