[데이터베이스] 5.2. ER 모델

경희대학교 이영구 교수님의 데이터베이스 수업 복습용 게시물입니다.

 

 

ER 모델

• 데이터베이스 설계를 용이하게 하기 위해 P.P. Chen이 1976년에 제안
• 현재는 EER(Enhanced Entity Relationship) 모델이 데이터베이스 설계 과정에 널리 사용됨
• 개념적 설계를 위한 인기 있는 모델, 많은 CASE 도구들에서 지원됨
• 실세계 -> 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현
• 쉽게 관계 데이터 모델로 사상됨
• 기본적 구문: 엔티티, 관계, 애트리뷰트
• 기타 구문: 카디날리티 비율, 참여 제약조건 등
• 적은 노력으로 쉽게 배울 수 있고, 전문가가 아니어도 이해하기 쉬움
• 자연어보다 좀 더 정형적이고, 구현에 독립적 -> 데이터베이스 설계자들이 최종 사용자들과 의사 소통을 하는데 적합
• ER 모델을 기반으로 만들어진 다수의 CASE 도구(ex: ERWin 등)들이 존재 -> 이런 도구들은 ER 설계를 자동적으로 오라클, SQL Server, 사이베이스 등의 데이터 정의어로 변환(어떤 도구는 XML로 변환)
• 현재는 데이터베이스 설계를 위한 다소 구형 그래픽 표기법

 

엔티티

• 엔티티: 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체
• 사원처럼 실체가 있는 것도 있지만, 생각이나 개념과 같이 추상적인 것도 존재

 

엔티티 타입

• 엔티티들은 엔티티 타입(혹은 엔티티 집합)들로 분류됨
• 엔티티 타입: 동일한 애트리뷰트들을 가진 엔티티들의 틀 -> 관계 모델 릴레이션의 내포
• 엔티티 집합: 동일한 애트리뷰트들을 가진 엔티티들의 모임 -> 관계 모델 릴레이션의 외연
• 하나의 엔티티는 한 개 이상의 엔티티 집합에 속할 수 있음 . ex) 홍길동 -> 학생, 조교 등 여러 엔티티 집합에 속함
• 엔티티 집합과 엔티티 타입을 엄격하게 구분할 필요는 X 
• ER 다이어그램에서 엔티티 타입은 직사각형

홍길동, 김철수, 박영수 -> 엔티티 집합

학생 -> 엔티티들의 공통 특지을 뽑아서 엔티티 타입으로

 

강한 엔티티 타입

• 독자적으로 존재
• 엔티티 타입 내에 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입

약한 엔티티 타입

• 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
• 이 엔티티 타입이 존재하려면 소유 엔티티 타입이 있어야 함
• 소유 엔티티 타입의 키 애트리뷰트를 결합해야만 -> 고유하게 약한 엔티티 타입의 엔티티들을 식별할 수 있음

 

애트리뷰트

• 엔티티: 연관된 애트리뷰트들의 집합
• ex) 사원 엔티티 -> 사원 번호, 이름, 직책, 급여 등의 애트리뷰트 가짐
• 도메인: 그 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합
• ex) 사원번호는 1000부터 9999까지의 값을 가짐
• 여러 애트리뷰트가 동일한 도메인을 공유할 수 있음
• ex) 사원번호와 부서번호가 네 자리 정수를 가질 수 있음
• 요구사항 명세에서 명사나 형용사로 표현됨
• 엔티티는 독립적인 의미를 가짐 -> 애트리뷰트는 독립적 의미 X
• ER 다이어그램에서 타원형으로 나타냄
• 애트리뷰트와 엔티티 타입은 실선으로 연결

 

단순 애트리뷰트(simple attribute)

• 더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰트
• ER 다이어그램에서 실선 타원으로 표현

복합 애트리뷰트(composite attribute)

• 두 개 이상의 애트리뷰트로 이루어진 애트리뷰트
• 동일한 엔티티 타입이나 관계 타입에 속하는 애트리뷰트들 중에서 밀접하게 연관된 것을 모아놓은 것

단일 값 애트리뷰트(single-valued attribute)

• 각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트
• ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨
• ex) 사원의 사원 번호 애트리뷰트 -> 두 개 이상의 사원번호 불가능

다치 애트리뷰트(multi-valued attribute)

• 각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트
• ER 다이어그램에서 이중선 타원으로 표현
• ex) 취미 -> 독서, 축구, ..

저장된 애트리뷰트(stored attribute)

• 다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트
• ER 다이어그램에서 단순 애트리뷰트와 동일 표현
• ex) 사원 엔티티 타입에서 사원 이름, 급여는 다른 애트리뷰트와 독립적으로 존재
• 데이터베이스에 저장된 나이 -> 연도가 바뀔때마다 갱신됨 -> 대신 birth date를 저장

유도된 애트리뷰트(derived attribute)

• 다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트
• 관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋음
• ER 다이어그램에서 점선 타원으로 표현

 

 

약한 엔티티 타입

• 소유 엔티티 타입(owner entity type) 혹은 식별 엔티티 타입(identifying entity type): 약한 엔티티 타입에 키 애트리뷰트를 제공하는 엔티티 타입
• ER 다이어그램에서 이중선 직사각형으로 표기
• 약한 엔티티 타입의 부분 키는 점선 밑줄을 그어 표시
• 부분 키(partial key): 부양가족의 이름처럼 한 사원에 속한 부양가족 내에서는 서로 다르지만, 회사 전체 사원들의 부양 가족들 전체에서는 같은 경우가 생길 수 있는 애트리뷰트

 

관계와 관계 타입

• 관계: 엔티티들 사이에 존재하는 연관이나 연결 -> 두 개 이상의 엔티티 타입들 사이의 사상
• 관계 집합: 동질의 관계들의 집합
• 관계 타입: 동질의 관계들의 틀
• 요구사항 명세에서 동사 -> ER 다이어그램에서 관계로 흔히 표현됨
• ER 다이어그램에서 다이아몬드로 표기
• 관계 타입이 서로 연관시키는 엔티티 타입들을 관계 타입에 실선으로 연결

 

관계의 애트리뷰트

• 관계 타입은 관계의 특징을 기술하는 애트리뷰트들을 가질 수 있음
• 관계 타입은 키 애트리뷰트들 갖지 않음

 

차수(degree)

• 관계로 연결된 엔티티 타입들의 개수
• 가장 흔한 관계 -> 두 개의 엔티티 타입을 연결하는 2진 관계

카디날리티 비율

• 한 엔티티가 참여할 수 있는 관계의 수
• 관계 타입에 참여하는 엔티티들의 가능한 조합을 제한
• 흔히 1:1, 1:N, M:N으로 구분
• 카디날리티 비율에 관한 정보 -> 간선 위에 나타냄

 

1:1 관계

• E1의 엔티티가 정확하게 E2의 한 엔티티와 연관 & E2의 엔티티가 정확하게 E1의 한 엔티티와 연관된 관계
• ex) 각 사원에 대해 최대 한 개의 PC, 각 PC에 대해 최대한 한 명의 사원

1:N 관계

• E1의 각 엔티티가 E2의 임의의 개수의 엔티티와 연관되고, E2의 각 엔티티는 정확하게 E1의 한 엔티티와 연관된 관계
• ex) 각 사원에 대해 최대 한 대의 PC, 각 PC에 대해 여러 명의 사원들 -> PC와 사원은 1:N 관계

M:N 관계

• 한 엔티티 타입에 속하는 임의의 개수의 엔티티가 다른 엔티티 타입에 속하는 임의의 개수의 엔티티와 연관된 관계
• ex) 각 사원에 대해 여러 대의 PC, 각 PC에 대해 여러 명의 사원

 

카디날리티 비율의 최소값과 최대값

• ER 다이어그램에서 관계 타입과 엔티티 타입을 연결하는 실선 위에 min, max 형태로 표기
• min: 각 엔티티는 적어도 min번 관계에 참여함
• max: 각 엔티티는 최대한 max번 관계에 참여함을 의미
• min = 0 -> 반드시 관계에 참여해야 할 필요는 없음
• max = * -> 관계에 임의의 수만큼 참여할 수 있음

 

 

-> 하나의 car에 대해서 가능한 customer, salesperson 조합은 하나씩만 연결 가능 -> 어떤 salesperson에 의해 어떤 customer에 팔렸다? 다른 경우 불가능

-> 하나의 salesperson에 대해 customer, car 조합은 여러 개 연결 가능: 누구에게 어떤 차를 팔았느냐 -> 이 경우가 많음

-> 하나의 customer에 대해 car, salesperson은 salesperson 경우와 비슷

 

역할(role)

• 관계 타입의 의미를 명확하게 하기 위해 사용
• 특히 하나의 관계 타입에 하나의 엔티티 타입이 여러 번 나타나는 경우 -> 반드시 역할 표기
• 관계 타입의 간선 위에 표시

 

전체 참여와 부분 참여

• 전체 참여: 어떤 관계에 엔티티 타입 E1의 모든 엔티티들이 관계 타입 R에 의해 어떤 엔티티 타입 E2의 어떤 엔티티와 연관되는 것을 의미
• 부분 참여: 어떤 관계에 엔티티 타입 E1의 일부 엔티티만 참여하는 것을 의미
• 약한 엔티티 타입은 항상 관계에 전체 참여
• 전체 참여는 ER 다이어그램에서 이중 실선으로 표시

 

다중 관계

• 두 엔티티 타입 사이 두 개 이상의 관계 타입이 존재할 수 있음

순환적 관계

• 하나의 엔티티 타입이 동일한 관계 타입에 두 번 이상 참여하는 것

 

ER 스키마를 작성하기 위한 지침

• 엔티티: 키 애트리뷰트 이외에 설명 정보를 추가로 가짐
• 다치 애트리뷰트는 엔티티로 분류
• 가능한 복합 식별자 피함
• 어떤 개념 -> 엔티티 타입, 관계 타입 중 어느 것을 모델링할 것인지 절대적으로 구분하는 것이 어려움

 

애트리뷰트 vs. 엔티티

• 엔티티 타입과 애트리뷰트를 구분하는 절대적 기준 X
• ex) 공급자에 대한 정보 -> 공급자 번호, 공급자 이름, 신용, 공급자 도시

• 공급자가 엔티티인 것은 명확
• 공급자 도시 -> 엔티티 or 애트리뷰트: 공급자가 어느 도시에 위치하느냐만 궁금하면 애트리뷰트, 공급자 도시에 관한 정보(항구 시설, 도로망)를 유지해야 할 필요가 있다면 엔티티
• 고려 사항: 도시가 조직체에 관심이 있는 객체인가? 도시에 관한 애트리뷰트들을 유지할 필요가 있는가? 도시를 여러 엔티티 타입들이 공유하는가? -> 이 중 하나만 만족해도 엔티티, 아니라면 애트리뷰트

 

데이터베이스 설계 과정

• 응용의 요구사항을 수집하여 기술 -> 요구사항 명세
• 응용과 연관이 있는 엔티티 타입들을 식별 -> 조직체에서 관심있는 엔티티 타입들
• 응용과 연관이 있는 관계 타입들을 식별
• 카디날리티 비율(1:1, 1:N, 1:M) 결정
• 엔티티 타입과 관계 타입들에 필요한 애트리뷰트들을 식별, 각 애트리뷰트가 가질 수 있는 값들의 집합을 식별
• 엔티티 타입들을 위한 기본 키를 식별
• 응용을 위한 ER 스키마 다이어그램
• ER 스키마 다이어그램이 응용에 대한 요구사항과 부합되는지 검사(validation)
• ER 스키마 다이어그램을 DBMS에서 사용되는 데이터베이스 모델로 변환 -> 논리적 설계

 

ER 모델의 또 다른 표기법

• 수십 개 이상의 애트리뷰트가 엔티티 타입에 연결된 다이어그램 -> 매우 불편, 공간 많이 차지
• ERWin 등의 CASE 도구들에서는 새발(crow-feet) 표기법이 흔히 사용됨