Ch 03. Entity-Relationship(ER) 모델을 사용한 데이터 모델링

개념 데이터 모델링은 성공적인 데이터 설계에 있어서 매우 중요한 과정임

Entity-Relationship(ER) model은 인기있는 고수준 개념 데이터 모델임(개념 스키마를 만듦)

 

 

1. 데이터베이스 설계와 기능적 설계

데이터 모델 설계는 데이터 설계와 데이터베이스 응용 설계로 나뉨. 서로 상호작용을 하여 응용이 일어남

 

1. 데이터베이스 설계

- 데이터 설계

- 논리 설계

- 물리적 설계

 

데이터베이스 요구사항들을 받아 개념적 설계를 하고

고수준의 데이터 모델로 개념 스키마를 만들어 논리 설계를 함

논리 설계는 논리적 스키마를 만들어서 물리적 설계를 하게 됨(특정 DBMS의 데이터 모델로 표현됨)

 

• 논리적 설계를 기준으로 윗 부분은 DBMS에 상관없이 독립적으로 설계하고, 이후엔 DBMS에 기능에 맞게 설계함

 

2. 기능적 설계

기능적 분석을 통해 고수준의 트랜잭션을 명세함

이 트랜잭션을 이용하여 응용 프로그램 설계를 함

최종적으로 트랜잭션을 구현

 

- 1번과 2번은 서로 상호작용을 함

-> 논리적 스키마가 응용 프로그램 설계의 입력으로 사용됨

-> 고수준 트랜잭션이 물리적 설계에 영향을 줌

-> 내부 스키마는 트랜잭션 구현에 영향을 줌

 

 

 

 

2. 엔티티 타입, 엔티티 집합, 애트리뷰트, 키

ER모델은 데이터를 엔티티, 관계, 애트리뷰트로 기술함

 

• 엔티티(개체, Entity)
  • ER 모델을 표현하는 기본 객체
  • 실세계에서 독립적으로 존재하는 실체임
  • 실제로 존재하는 객체(사람, 차, 집)이거나 개념적(회사, 직업)으로 존재하는 객체임
• 애트리뷰트(속성, Attribute)
  • 각 엔티티를 기술하는 속성(직원의 이름, 나이, 주소, 급여 등)
  • 속성의 종류
    • simple(단순) / composite(복합)
    • single-valued(속성의 값이 하나냐) / multivalued(속성의 값이 여러개냐)
    • stored(저장되는) / derived(유도되는)
• 엔티티 타입
  • 동일한 애트리뷰트를 갖는 엔티티들의 집합
  • 각 엔티티 타입은 이름과 애트리뷰트들로 이루어져 있음
  • 엔티티 집합에 대한 스키마나 내포(intension)을 나타냄
  • ERD(ER-Diagram): 엔티티 타입의 이름을 기술한 사각형 박스
• 엔티티 집합
  • 임의의 시점에 데이터베이스 내의 특정 엔티티 타입의 모든 에티티의 모임을 엔티티 집합이라고 부름
  • 보통 엔티티 집합은 엔티티 타입과 같은 이름을 사용하여 부름
  • 엔티티 타입의 외연(extension)임
• 키 애트리뷰트
  • 서로 구별해줄 수 있는 속성(COMPANY: NAME, EMPLOYEE: SSN 같은 것)
  • 키가 여러 개의 속성으로 구성되어 있으면 이것을 복합 키(composite key)라고 부름 - 최소성을 만족해야함
  • 엔티티는 여러 개의 키를 가질 수 있음
  • 키가 없는 엔티티는 약간 엔티티 타입(weak entity type)이라고 부름

 

3. 관계(Relationships), 관계 타입, 역할, 구조적 제약 조건

• 어떤 엔티티 타입의 한 애트리뷰트가 다른 엔티티 타입을 참조할 때, 두 엔티티 간에는 관계가 성립함
  • ex) DEPARTMENT의 Manager 애트리뷰트는 그 부서를 관리하는 사원을 참조함
  • ex) EMPLOYEE의 Supervisor 애트리뷰트는 또 다른 EMPLOYEE를 참조함
• ER모델에서는 이런 참조들을 애트리뷰트들로서 표현하지 않고 관계(relationship)로 명시해야 한다.
  • 엔티티 타입들의 초기 설계에서 관계는 일반적으로 애트리뷰트들의 형태로 표현이 되지만
  • 설계가 개선됨에 따라 이런 애트리뷰트들은 엔티티 타입들 간의 관계로 변환된다.
• 관계 타입의 차수(degree)
  • 관계에 참여하고 있는 엔티티 타입들의 개수를 뜻함(ex WORKS_FOR는 차수가 2임)
  • 일반적으로 가장 흔한 것이 이진 관계임
  • 고차수 관계는 일반적으로 이진 관계보다 훨씬 더 복잡함(그래서 가능하면 이진 관계로)
• 관계 타입의 제약조건
  • 관계 타입은 보통 제약 조건을 가지고 있음
    • 해당 관계에 참여할 수 있는 실제 가능한 조합을 제한함
    • ex) WORKS_FOR에서 한 직원은 하나의 부서에서만 근무함
  • 관계 제약 조건의 종류
    • cardinality ratio (대응 수, 카디날리티 비율)
    • participation(참여 제약 조건)
  • 이진 관계의 카디날리티 비율
    • 엔티티가 참여할 수 있는 최대 관계 인스턴스들의 수를 명시함
    • 1:1, 1:N, N:1, M:N 여러가지 방법이 있음
      • ex) EMPLOYEE와 DEPARTMENT 사이의 Manage는 한 사원이 한 부서만 관리할 수 있으므로 1:1 관계
      • ex) EMPLOYEE와 DEPARTMENT 사이의 WORKS_FOR은 여러 직원이 한 부서에 속할 수 있으므로 N:1
      • ex) EMPLOYEE와 PROJECT사이의 WORKS_ON은 여러 직원이 여러 프로젝트에 참여할 수 있으니 M:N
      • 읽는 방법은 반대쪽에 속한 값을 읽으면 됨. ex2로 보면 직원은 하나의 부서에서 일하지만 부서 입장에서는 N명의 직원이 근무하므로 N:1임
  • 참여 제약 조건과 존재 종속성(Participation Constraints and Existence Dependencies)
    • 참여 제약 조건
      • 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부를 명시
      • 전체 참여(TOTAL, double line) 혹은 부분 참여(PARTIAL, single line in ERD) 두가지 유형이 있음
      • ex) EMPLOYEE는 부서를 관리하거나 안해도 되므로 부분 참여. DEPARTMENT는 무조건 관리 받아야하므로 전체 참여임(자기와 연결된 선을 보고 해석함)
  • 관계 타입의 애트리뷰트
    • 1:1 혹은 1:N 관계 타입은 참여하고 있는 엔티티 타입들 중의 하나로 통합될 수 있음

 

4. 약한 엔티티 타입(weak entity types)

• 자신의 키 애트리뷰트가 없는 엔티티 타입을 약한 엔티티 타입이라고 부름(키가 있는 엔티티 타입은 Regular/strong entity type이라함)
• 식별 엔티티 타입(identifying/owner entity type)
  • 약한 엔티티 타입에 있는 애트리뷰트를 다른 엔티티 타입과 연계하여 식별할 수 있는 방법
• 식별 관계(identifying relationship)
  • 약한 엔티티는 소유 엔티티 없이는 식별될 수 없기 때문에 약한 엔티티 타입은 식별 관계에 대해 항상 전체 참여 제약 조건(존재 종속성)을 가짐
• 약한 엔티티 타입은 기본적으로 부분 키(partial key)를 가지고 있음

 

 

5. ER 다이어그램의 대안 표기법

• min/max 표기법(notation)
  • 관계에 대한 구조적 제약 조건을 (min, max)로 연계시키는 방법임
  • min과 max는 0 <= min <= max, max >= 1의 조건을 만족함
  • min = 0이면 부분 참여를 의미하고, min > 0이면 전체 참여를 의미함
• ex) EMPLOYEE - (1, 1) - WORKS_FOR - (1, N) - DEPARTMENT
  •  EMPLOYEE는 자기가 참여하는 부서가 최소 1개, 최대 1개 있어야함
  •  DEPARTMENT는 부서안의 직원이 최소 1명, 최대 N명 있어야함
• Universal Modeling Language(UML)도 대안 표기법으로 사용하고 있음
  • 이 내용은 소프트웨어 공학이나 데이터베이스 스튜디오에서 다룸