[데이터베이스] 3. ER-Model (Entity, Relationship, Key)

데이터베이스 설계

데이터베이스를 설계하는 과정은 크게 3단계가 있다.

 

1. 요구사항 분석 (requirement analysis)

정말 장인 급으로 프로그래밍을 잘하지 않는 이상, 우리는 설계를 잘 할 수 있어야 한다.

설계를 잘하려면 먼저 고객이 자연어로 말하는 요구사항을 잘 분석해서 이를 토대로 데이터베이스를 설계할 수 있어야 한다.

 

2. 개념적 데이터베이스 설계 (conceptual database design)

고객의 요구사항을 분석했다면, 그 결과를 토대로 먼저 개념적으로 데이터베이스를 설계한다.

이때 UML, ERD 등을 사용하여 데이터베이스를 설계할 수 있다.

 

3. 논리적 데이터베이스 설계 (logical database design)

데이터베이스 설계가 끝났다면, 실제로 사용할 데이터베이스를 선택하고, 데이터베이스의 스키마를 설계한다.

 

이후에는 설계한 스키마를 정제하면서 정규화를 적용하고, 물리적 데이터베이스를 디자인하면서 인덱싱과 클러스터링 문제를 다룬다.

 

 

ER-Model

요구사항 분석은 뒤에 예시에서 보기로 하고, 개념적 데이터베이스 설계를 하는데 사용하는 ER 모델에 대해 먼저 정리해보자.

ER-Model은 문제 상황을 구성하는 데이터들을 엔티티와 엔티티 사이의 관계로 모델링하는 방법이다.

(즉, 개체와 개체의 관계를 논리적, 개념적으로 표현한 것이다.)

 

ER-Model 은 Entity와 Relationship 으로 구성된다.

엔티티는 그 뜻 그대로, 실세계를 구성하는 오브젝트를 구분할 수 있는 하나의 '개체' 이다.

예를 들어 학교에는 여러 학생 오브젝트가 있고, 각각의 학생 한 명 한 명은 '개체'로서 구분될 수 있다.

 

데이터베이스에서 하나의 엔티티는 속성(attribute)의 집합으로 묘사된다.

예를 들어 학생 개체 하나 하나는 (학번, 이름, 나이, 학과) 등의 속성을 가질 수 있다.

 

그리고 같은 속성들을 갖는 엔티티들은 Entity Set 으로 표현될 수 있다.

(학번, 이름, 나이, 학과) 를 갖는 개체들을 모아 '학생' 이라는 집합으로 표현하는 것이다.

이때 각 엔티티 셋은 key를 갖고, 엔티티 하나를 구성하는 각 속성들은 domain을 갖는다.

 

Domain

도메인은 모든 속성값들을 나타낼 수 있는 '집합' 이다.

이 'domain' 이라는 단어를 놓고 살펴보면, 도메인은 이산수학에서 함수 '정의역'을 나타낸다.

즉, 도메인은 각 속성이 가질 수 있는 값의 형태를 정의한 것이고, 그 형태의 결과로 나타난 값 하나가 속성 값이 된다.

쉽게 이야기하면 domain은 속성 하나의 데이터 타입이다.

 

예를 들어, 학생의 이름 attribute의 domain이 '길이가 최대 20인 문자열'이라면, 학생의 이름이 될 수 있는 값들은 'kim', 'alice', 'bob', 'park' 와 같이 20이하의 길이를 갖는 문자열들이 속성값이 될 수 있다.

 

 

Key

키는 엔티티 셋에서 엔티티를 유일하게 식별하는 identifier를 말하며,

데이터베이스 기준으로는 하나의 엔티티를 식별하는 최소한의 attribute의 집합을 말한다.

 

예를 들어, 학생 엔티티 셋에서 한 명의 학생 개체를 식별하고자 한다면, (학과, 이름, 나이) 등을 조합해서 식별하고자 할 수 있다.

물론 실제로는 같은 학과에 같은 이름, 나이를 가진 사람이 존재할 수 있어서 저렇게 할 수 없지만, 설사 저렇게 식별이 가능하다고 하더라도 이 속성값 집합은 '키'가 될 수는 없다.

만약 '학번'이라는 속성값을 사용한다면 더 적은 1개의 속성값만으로 1명의 학생 개체를 식별할 수 있기 때문이다.

 

그렇다고 꼭 키가 반드시 1개의 속성값으로만 구성될 필요는 없다. (최소 크기의 '집합' 이므로)

만약 학생이 수업을 듣는 관계를 유일하게 식별하고자 한다면, 그때는 (학생, 수업) 쌍으로만 식별이 될 것이다.

따라서 키는 경우에 따라 2개 이상의 속성으로 구성될 수도 있다.

 

 

Candidate Key (후보키)

엔티티를 식별할 수 있는 최소 개수의 속성값을 갖는 집합은 여러개가 있을 수 있는데, 그 모든 키들이 후보키이다.

이름 그대로 후보인 키이다. 그리고 이 키들 중에 하나를 선택해서 엔티티를 식별하기 위해 기본적으로 사용하는 키를 정한다.

 

Primary Key (기본키)

기본키는 후보키 중에서 엔티티를 식별하는데 기본적으로 사용하는 키이다.

 

Super Key (슈퍼키)

슈퍼키는 슈퍼셋과 비슷하게 기존의 키를 포함하는 개념이라고 생각할 수 있다. (후보키도 슈퍼키이다.)

엔티티 하나를 식별할 수 있다는 점에서 키로서 기능할 수는 있지만, 최소 크기 집합은 아닌 키를 슈퍼키라고 한다.

 

 

ER 모델을 도식으로 표현할 때는 네모로 엔티티 셋을 나타내고, 각 엔티티의 속성을 동그라미로 표현한다.

이때 각 속성 중에서 기본키로 사용하는 속성 이름에는 밑줄로 표시한다.

위 그림에서는 직원 개체 하나를 식별하는 기본키로 ssn (사회보장번호) 를 사용하는 것을 알 수 있다.

 

 

Relationship

Relationship는 2개 이상의 엔티티 사이의 연관성을 나타낸다.

이 관계들 중에서 같은 관계들을 모으면 Relationship Set 이 된다.

따라서 관계 역시 이 셋을 데이터베이스에서 테이블로 구현할 수 있다.

 

 

ER-Model에서는 관계를 위 그림과 같이 마름모로 표현한다.

관계도 엔티티와 마찬가지로 속성을 가질 수 있고, 관계의 속성도 똑같이 동그라미로 표현한다.

이 그림에서는 직원 엔티티 셋과 부서 엔티티 셋을 '일한다' 라는 관계 셋으로 묶어서 표현하고 있다.

 

이제부터는 엔티티 셋과, 관계 셋을 편하게 '엔티티'와 '관계'라고 표현하려고 한다.

만약 그 안에 속한 단일 엔티티, 관계를 나타내는 경우엔 '엔티티 하나', '관계 하나'와 같이 명시적으로 표현하겠다.

 

부서 엔티티도 각 엔티티 하나 하나를 구분하기 위해 기본키가 필요하며, 그 기본키로 did (department id) 를 사용하고 있다.

works_in 이라는 관계는 그림 상으로는 since 라는 속성을 하나만 갖고 있는 것으로 나타냈으나,

실제 테이블로 나타낼 때는 직원과 부서를 식별할 수 있는 ssn, did 를 외래키로 가져, 두 외래키쌍을 기본키로 하나의 관계를 식별할 것이다. (즉, 다이어그램 상에서 ssn, did 는 생략한 것이다.)

 

이때, 당연히 한명의 직원은 하나의 부서에서만 일하니 직원 ssn 만으로도 관계를 식별할 수 있지 않느냐고 물어볼 수도 있다.

히지만 뒤에서 설명하겠지만 이 그림 상으로는 한명의 직원이 여러 부서에서 일할 수도, 심지어 일하지 않을 수도 있다.

따라서 이 그림 상에서 works_in 관계 하나를 유일하게 식별하려면 (ssn, did) 조합으로 식별해야만 한다.