• ER 데이터 모델
    • 데이터베이스 설계 시 가장 많이 사용되는 방법
    • 1976년 P. Chen 제안
    • 객체지향 요소 지원

10.1 Entity and Relationship

Entity-Relationship Data Model

  • 데이터베이스를 개체-관계로 모델링
  • modeling primitive : 객체(object)만 존재
  • 객체가 가질 수 있는 특성 : attribute, relationship, method
  • class : 동일한 특성을 가지는 객체 모임

Entity, Entity Set

  • 개체

    • 구별 가능한 객체
    • 개체의 속성 : 개체의 특성을 나타내는 역할
  • 개체 타입(개체 집합)

    • 개체 중에서 같은 속성을 가지는 개체의 모임
    • 속성이 동일한(속성값은 다른) 다수 개의 개체

Relationship, Relationship Set

  • Relationship 관계성

    • 개체집합 내 개체 ← (연관) → 다른 개체집합 내 개체
    • 각 개체 집합에 속하는 개체의 나열
    • ex. ‘수강하다’
  • 관계성 타입(관계성 집합)

    • 관계성 중에서 같은 속성을 가지는 관계성
  • 관계성 집합 속성

Degree of a Relationship Set

  • 관계성 집합 차수 : 관련되는 개체의 개수
  • binary relationship : 가장 흔하게 사용
  • ternary(3진) / quaternary(4진) / quinary(5진) relationship도 가능

Attributes

  • 속성 : 개체 또는 관계성이 가지는 특성
    1. simple attribute 단순 속성

    2. composite attribute 복합 속성
      - 이름 : First_name, Middle_name, Last_name


    3. single-valued attribute 단일값 속성

    4. multivalued attribute 다수값 속성

  • derived attribute 유도된 속성
    • 다른 속성을 이용하여 속성 값을 구할 수 있는 속성
    • ex. 주어진 생년월일 속성 활용 → 나이 (유도된 속성)

Cardinality Constraints

  • 이진 관계성 집합에서 유용

  1. One to one
  2. One to many
  3. Many to one
  4. Many to many

Keys

  • superkey, candidate key, primary key는 테이블과 동일
  • superkey
    • 관련되는 개체 집합의 primary key 합성
    • 개체 간의 관계는 반드시 하나이다.
  • 참여하는 entity set의 primary key조합 → relationship set의 superkey 형성
    • 특정 relationship set에서 최대 하나의 관계만 가질 수 있음을 의미
  • 후보키, 주키 결정 시, relationship set의 cardinality/participation constraint 고려 필요

10.2 E-R Diagram

2023.11.06

ER Diagrams

  • ER model의 결과물

  • 사각형 : 개체 집합

    마름모형 : 관계성 집합

    밑줄 : primary key

  • complex attributes

    • name, address, street : 복합 속성
    • phoneNumber : 하나 이상의 값을 가진 다수값 속성
    • age : dateOfBirth로부터 유도된 속성

Relationship Sets with Attributes

  • 속성을 가진 관계성 집합
    • date : 관계성 집합 속성

M:1/M:N Relationship Set

  • Cardinality Constraints

    • directed line(→) : one 의미
    • undirected line(—) : many 의미
  • Many-to-one

    • professor : 최대 한 명의 student만
    • student : 여러명(0명 포함) professor 가능
  • Many-to-many

  • Participation Constraints

    • total participation(==) : 모든 인스턴스가 관계에 참여해야함

      → 어떤 인스턴스도 관계없이 존재 X

    • partial participation(—) : 일부 인스턴스만 관계에 참여 가능

      → 관련없이 존재 O

      → 수강하지 않는 학생 존재 O

      → 학생이 수강하지 않는 과목 존재 X

ER Diagram with a Ternary Relationship

  • 3진 관계성 ER 다이어그램

    • 학생과 교수 간의 관계 : 과제와 관련 X
    • 교수와 과제 간의 관계 : 학생과 관련 X
    • 과제와 학생 간의 관계 : 교수와 관련 X
  • Cardinality Constraints

    • professor : student = 1 : M
    • project : student = M : N
    • project : professor = M : 1

Roles

  • 개체 집합이 반드시 distinct할 필요 X
  • 동일 개체 집합이 두 번 이상 관계성 집합에 참여하는 경우
    • role 표시 필요 !

    • 참여에 대한 의미를 구분하기 위해

Weak Entity Sets

  • Strong entity set : 모두 자체적으로 primary key 소유

  • Weak entity set : primary key가 없는 개체 집합

    • strong entity(구분하는 개체 identifying entity)에 의존적
    • 강한 개체 존재 없이 존재 X
  • Identifying relationship

    • Strong, Weak 간에 존재하는 관계성
    • weak entity : 전체 참여, many
    • strong entity : one
  • Keys of Weak Entity Sets

    • partial key 존재 가능
    • strong entity set의 primary key + weak entity set의 partial key = weak entity set의 primary key
  • Example>

    • 분반 : 과목 하나에서는 유일하지만 분반 전체에서는 유일 X → 전체 참여 제약
    • cID가 section 속성이면 → course와 section 간 관계성은 불필요

  • E-R Diagram for a University 과목은 반드시 한 학과에서 개설되어야 하며, 두 개 학과 이상이 공통으로 과목 개설을 할 수 없다.
    분반(section)은 다수명의 강사가 강의할 수 있다.
    time_slot 개체는 요일, 시작시간, 종료시간 속성을 가지고 있는데, 하나의 시간대에 다수개의 분반이 배정되며 모든 시간대에 분반이 배정되지 않을 수도 있다.
    학생 중에서는 상담(advise)을 받지 않은 학생도 있다.

10.3 Reduction to Relation Schemas

2023.11.09

Entity Sets, Relationship Sets

  • 사용자 요구사항을 반영하는 ER 다이어그램 작성 → 관계형 스키마로 변환
  • DB 설계 목적 : 좋은 관계형 스키마 구하기
  • 개체 집합, 관계성 집합 : 각각 테이블로 속성과 함께 변환
  • 개체 속성 타입에 따라 변환 상이할 수 있다.

Strong/Weak Entity Sets

  • 강한 개체 : 관계로 변환
  • 약한 개체 : 관계로 변환
  • identifying 관계성 : 테이블로 변환 X → 약한 개체를 변환할 때 강한 개체의 주 키를 이미 포함

Relationship Sets

  1. M:N Relationship Sets

    • 반드시 독립적인 테이블로 변환
    • 속성 : 관여하는 개체집합의 주키 포함
  2. N:1 Relationship Sets

    • 독립적인 테이블로 변환 가능
    • many측 개체로 병합하여 테이블 변환도 가능

    people(pID, name, address, age)
    own(pID, vehicleID, registrationDate)
    //many측 주키가 own의 주키가 된다.
    car(vehicleID, make, model, year, color)
    people(pID, name, address, age)
    car(vehicleID, make, model, year, color, registrationDate, pID)
    //관계성에 참여하지 않는 car 터플의 pID = NULL
  3. 1:1 Relationship Sets

    people(pID, name, address, age)
    own(pID, vehicleID, registrationDate)
    // 주키는 pID 또는 vehicleID
    car(vehicleID, make, model, year, color)
    people(pID, name, address, age)
    car(vehicleID, make, model, year, color, registrationDate, pID)
    people(pID, name, address, age, registrationDate, vehicleID)
    car(vehicleID, make, model, year, color)

Composite Attributes

Employee(ID, firstName, middleNameInitial, lastName,
				streetNumber, streetName, aptNumber, city, state, zipCode,
				dateOfBirth, age)
  • 복합 속성 : flatten out → 테이블 속성으로 변환
  • phoneNumber : 다수값
    • 결과 테이블 스키마에 포함 X
    • 독립 테이블로 변환
      employeePhone(ID, phoneNumber)
    • 관련 개체의 주키 속성 포함
    • 모든값이 원자값
    • 데이터 모델이 속성값으로 집합 값 허용 시 독립적 테이블로 변환 X → 객체 관계형 데이터 모델 : 속성 값으로 집합 허용
  • 유도된 속성 age() : 명시적으로 포함
    • 객체지향, 객체 관계형 데이터 모델 : method로 변환 가능

10.4 Database Design Issues

2023.11.13

attribute vs. entity set

  • attribute : 엔티티의 특성, 세부사항 ex) 전화번호 : 사람 개체의 속성으로
  • entity set : 유사한 속성을 공유하는 엔티티 집합 ex) 전화번호에 대한 다양한 정보가 함께 저장 → 독립적 관계 생성 고려

entity set vs. relationship set

  • entity set : 객체의 그룹

  • relationship set : 이러한 엔티티들 간의 관계

  • Redundant Attributes

    • deptName 속성과 belongs 관계성 집합 중복
    • deptName 제거 필요

Binary vs. Non-binary relationships

  • 다진 관계성
    • 다수 개체간의 관계 명확히 표현
  • 다진 관계성 → 다수 개의 이진 관계성 변환 가능
    • 변환 시 모든 정보가 완전히 변환 X
    • 일부 정보 유실 가능성

ternary relationship vs. a pair of binary relationships

  • ternary relationship : 3개의 엔티티 세트가 한 번에 관련
  • a pair of binary relationships : 2개의 엔티티 세트간의 관계

  • parenthood 관계성

    • father/mother/child에 대한 정보가 정확히 기록되어야 함
    • 반드시 함께 기록
    • fatherhood 관계성, motherhood 관계성 동시에 표현
  • fatherhood 관계성

    • motherhood관계성과 관련 X
    • father 정보만도 기록 가능
    • parenthood 삼진 관계성을 반드시 표현 X
  • Converting Non-binary relationships

    • 다수 개의 이진 관계성으로 변환 가능

    • 새로운 객체 집합 생성 후 다진 관계성 집합에 속하는 관계성에 대응하는 개체 및 관계성 생성

    • R (ai, bi, ci)

      → RA 에 (ei, ai) 추가

      → RB 에 (ei, bi) 추가

      → RC 에 (ei, ci) 추가

    • 원래의 관계 완전히 표현 X

Strong vs. weak entity set

  • Strong entity set : 자체적으로 고유한 식별자 존재
  • Weak entity set : 다른 entity 식별자에 의존하여 식별

10.5 Extended E-R Features

specialization/generalization 사용

  • Top-down design process
    • specialization(특수화) : 일반적인 엔티티에서 더 구체적인 엔티티로의 분류
  • Bottom-up design process
    • generalization : 여러 특수한 엔티티들을 공통된 일반적인 엔티티로 결합

  • people : 3개의 속성
    • 최상위 엔티티
    • 모든 개체의 공통 속성 : ID, name, address
  • employee
    • 4개의 속성 : ID, name, address, salary
    • 속성 상속
  • overlapping specialization
    • people의 하위 개체 employee, student
    • 한 people 인스턴스가 동시에 employee, student 역할 가질 수 있음
  • disjoint specialization
    • employee의 하위 개체 professor, secretary
    • employee 엔티티의 하위 엔티티 간의 관계
    • 한 employee 인스턴스가 professor, secretary 중 하나만 될 수 있음

Multiple Specialization

  • 상위 개체와 하위 개체 간 다수개의 특수화/일반화 가능

Constraints on Specialization/Generalization

  • 상위 개체 : 하위개체가 속하는 기준에 대한 조건 정의
    • Condition-defined
  • 하위 개체 : 상위개체가 속하는 방식에 대한 제약
    1. disjoint

      상위 개체가 하위 개체 하나에만 속함

    2. overlapping

      상위 개체가 다수 개의 하위 개체에 속함

  • 완전 제약 조건 (completeness constraints) 상위 개체가 하위 개체에 반드시 속해야하는지 정의
    1. Total

      모든 상위 수준 엔티티가 반드시 하나 이상의 하위 수준 엔티티에 속함

      모든 인스턴스는 특정 하위 분류에 포함

    2. Partial

      모든 상위 개체 인스턴스가 하위 개체에 속할 필요 X (defualt)

      어떤 인스턴스는 하위 분류에 포함되지 않을 수 있음

Representing Specialization as Schemas

스키마로 변환하는 방법

  1. 하위 개체 = 하위 개체에만 속하는 속성 + 상위 개체의 주 키

    • 하위 관계에 대한 모든 속성을 검색 시, 하위, 상위 관계 모두 접근 필요
    people(ID, name, address)
    student(ID, totalCredit)
    employee(ID, salary)
  2. 하위 개체 = 상속받은 모든 속성 + 해당 개체에만 적용되는 속성

    • total 제약 : 상위 개체만을 위한 테이블 생성 필요 X
    • 단점 : 중복 저장
    people(ID, name, address)
    student(ID, name, address, totalCredit)
    employee(ID, name, address, salary)

10.6 Notations

Symbols in E-R Diagram

→ total 참여조건 명시 필요

Alternative ER Notation (by P.Chen)

Crow’s foot notation

  • 까마귀 발 표기 (IE 표기법, Martin 표기법)
  • 관계 타입 : 직선 표기 → 직선 옆에 관계 타입 이름(동사형) 표기
  • cardinality(multiplicity) : 직선 바깥쪽 끝 부분
    • 까마귀 발 모양 : many
    • 수직 바 : one
  • participation : 직선 안쪽 부분
    • 작은원 zero : optional, partial participation
    • 수직 바 one : mandatory, total participation

Chen’s notation vs. IDEF1X

(min, max) notation

  • 각 개체 타입 기준으로 관계 개체에 관여하는 횟수의 최소/최대값 표시
  • 0 ..* : partial participation
  • 1 .. 1 : total participation

Equivalent notations

UML

  • OMG에 의해 제정된 표준
  • 소프트웨어 구성 요소를 명세하는 언어
  • class diagram : ER모델과 유사
  • ER diagram vs. class diagram
  • min/max 표기법 위치 반대
  • UML 객체 : 메소드 가질 수 있음
    • 메소드 속성 : private, public, protected
    • private : 해당 객체의 메소드에서만 접근 가능
    • protected : 해당 객체와 서브 객체에서만 접근 가능
  • UML 속성 : 복합 속성, 다수값 속성 지원 X
profile
숭실대학교 컴퓨터학부 21

0개의 댓글