[Database Systems] Database Design Process, Entity-Relationship model, Conceptual Data Modeling

Database Design Process

Database의 설계 과정은 다음과 같다.

1. Miniworld 정의
2. System analyst가 사용자와의 인터뷰 등을 통해 requirement를 분석하고 수집
3. → Data requirement를 얻는다.
4. Data requirement를 통해 Conceptual Design
   • Conceptual Design: 사람이 본 수준에서의 high level schema를 정의
     • Entity Diagram model과 같은 Conceptual data model을 이용해 스키마를 정의한다.→ Conceptual schema를 얻는다.
5. Logical Design
   • Conceptual schema는 사람들이 이해하는 수준에서의(high level) 골격이므로 DBMS는 이해할 수 없다. DBMS에게 골격을 이해시키려면 Logical Design을 해야한다.
   • Logical Design: DBMS가 제공하는 model을 통해서 schema를 설계
     • Relational model과 같은 Representational data model을 이용해 스키마를 정의한다.→ Logical Schema를 얻는다.
6. Physical Design
   • Logical schema가 결정되면 DBMS가 그 골격을 이해할 수 있으므로 원하는 DB를 운영할 수 있다.
   • 그러나 performance issue가 발생할 수 있다.
   • 따라서 data 양이 많아지면 물리적으로 DB를 어떻게 구성할 것인지를 DBMS에게 알려줘야 한다.
   • ex) index 사용 여부, B tree를 어떻게 구성할지? 어떻게 데이터를 모아서 구성할지?

1~3번 과정까지는 DBMS independent하다.

• DBMS를 염두에 하고 하는 과정이 아니다.

4~5번 과정은 DBMS-specific하다.

• logical design을 위해서는 어떤 DBMS를 통해 DB를 관리할 것인지 정해져야 한다.

앞으로는 다음 COMPANY Database 예제를 기반으로 설명을 이어나갈 것이다.

COMPANY Database의 requirements는 다음과 같다.

주요 엔티티: Employee, Department, Project, Dependent

Company는 여러개의 Department로 구성되어 있다.

Department
unique name, unique number, locations,
manager and start date when manager began managing the department를 갖는다.
Department는 Project들을 컨트롤한다.

Project
unique name, unique number, location

Employee
name, Social Security number(SSN), address, salary, sex, birth date
Employee는 하나의 Department에 배정된다.
Employee는 여러개의 Project에 참여할 수 있다.
각 Project에서 몇 시간을 일 했는지 여부를 저장한다.
Supervisor를 저장한다.
Dependent(부양가족)을 저장한다.

Dependent
first name, sex, birth date, and relationship to the employee

Entities and Attributes

• Entity: 실세계에 존재하는 어떤 것
• Attribute: Entity를 설명하는 특성

Attribute의 종류

• Category 1
  • Simple(atomic) attributes
    • 더 이상 나눌 수 없는 attribute
  • Composite attributes
    • 여러개의 subpart로 나눌 수 있는 attribute
    • hierarchy를 구성할 수 있다.
  • ex) 사원의 이름을 simple attribute 또는 composite attribute로 모델링 할 수 있다.이름을 simple attribute로 표현하면 홍길동을 더 나눌 수 없으므로 찾을 수 없다.
  • 이름을 composite attribute로 표현하면 이름을 성, 이름으로 나눌 수 있으므로 성이 홍씨인 사람을 찾을 수 있다.
  • 홍길동이라는 이름을 가지는 사원이 있다. “성이 홍씨인 사원을 찾아라” 라는 명령어를 수행할 수 있는가?
• Category 2
  • Single-values attributes
    • 특정 엔티티에 하나의 값만 존재 가능한 attribute
    • ex) age
  • Multivalues attributes (set attributes)
    • 특정 엔티티에 여러개의 값이 존재 가능한 attribute
    • ex) phone number
• Category 3
  • Stored attributes
    • 실제로 DB에 저장되어 있는 attribute
  • Dervied attributes
    • DB에는 저장되어있지 않지만 DB에 저장되어 있는 attribute로부터 유추 가능한 attribute
    • ex) DB에 저장되어 있는 BirthDate라는 attribute로부터 Age라는 attribute를 유추할 수 있다.

Entity Type

• Entity Type: 같은 attribute set을 갖는 entity들의 집합
• schema를 나타낸다.
• Entity type name과 attribute로 정의된다.

Entity Type Name: EMPLOYEE

Entity Type: EMPLOYEE + Name, Age, Salary (entity name + attributes)

Entity Set 내의 객체 하나하나가 entity이다.

• Domain: entity의 attribute가 가질 수 있는 값의 범위

Key Attribute

• 모든 엔티티가 다른 값을 가지는 attribute
• 각 엔티티를 식별하는 데에 사용된다.
• ex) STUDENT entity의 student number

Key Attribute의 특성

1. 여러 attribute로 key를 구성할 수 있다.
2. 하나의 entity type이 두 개 이상의 key를 가질 수 있다.
3. uniqueness를 우선시 해야한다.어떤 attribute를 key로 설정하면 entity들이 그 attribute는 같은 값을 갖지 못하도록 enforce되는 것이다.
4. : 어떤 entity들이 모두 다른 값을 갖는 attribute가 있으니 그 attribute를 key로 설정하는 것이 아니라,

Q.

DB과목을 수강하는 학생들 중 동명이인이 없다면, 이름은 key가 될 수 있는가?

A.

아니다, entity들의 attribute중 중복값이 없다 → key

이런 식으로 key를 정하는게 아니다.

DB designer가 어떤 attribute가 key라고 미리 결정하면 서로 다른 entity들이 같은 값을 갖지 못하도록 하는 것이다.

2번 특성에 따르면, Registration(Number, State), Vehicle_id 모두 CAR entity type의 key가 될 수 있다.

1번 특성에 따르면, Number, State라는 여러개의 특성으로 Registration이라는 하나의 key를 구성할 수 있다.

ER model은 Entity + Relation 모두 갖지만 현재까지 공부한 것으로 Entity만 이용해 COMPANY database를 설계하면 다음과 같아진다.

DEPARTMENT
Name, Number, {Locations}, Manager, ManagerStartDate

PROJECT
Name, Number, Location, ControllingDepartment

EMPLOYEE
Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate, Department, Supervisor, {WorksOn (Project, Hours)}

DEPENDENT
Employee, DependentName, Sex, BirthDate, Relationship{}: multivalued attribute, 

{}: multivalued attribute
(): composite attribute

Relationship

• Relationship instances: entity set들간의 연관성을 나타낸 것
• Relationship type: Relationship instance들의 set

EMPLOYEE, DEPARTMENT: Entity type

WORKS_FOR: Relationship type

r1, r2, … , rn: Relationship instances

• Relationship degree: Relationship type에 참여하는 entity type의 개수
• Binary relationship: Relationship type에 참여하는 entity type이 2개
  • 위의 사진이 binary relationship이다.
• Ternary relationship: Relationship type에 참여하는 entity type이 3개
  

  

  • 누가 어떤 프로젝트에 어느 부품을 공급했는지에 대한 정보를 표현한다.
    • Q. 위의 ternary relationship을 SUPPLIER-PROJECT, SUPPLIER-PART, PART-PROJECT 3개의 binary relationship으로 표현 가능한가?
    • A. 표현할 수 없다. SUPPLIER가 여러개의 PROJECT에 여러개의 PART를 공급할 수 있으므로 어느 SUPPLIER가 어느 PART들을 공급하는지, 어떤 PROJECT들에 공급하는지는 알 수 있어도 어느 PROJECT에 어떤 PART를 공급했는지는 알 수 없다.
• Recursive Relationship Type: 같은 entity type이 하나의 relationship type에 두 번 이상 참여하는데 그 역할이 다른 것
  • 하나의 entity type 내에 있는 entity들이 엮이는 것이므로 어느 역할을 하는지 명시해주어야 한다.
  • 서로 다른 entity가 relationship에 참여할 때는 명시할 필요가 없지만, recursive relationship type에서는 role name을 명시해야 한다.
  • Role name: 참여하는 entity type이 각각의 relationship instance에서 어떤 역할을 하는지 명시한 것

 

• EMPLOYEE type이 relationship type SUPERVISION type에 두 번 이상 참여하는데 참여하는 entity들의 역할이 다르므로 recursive relationship이다. recursive relationship이므로 role name을 부여한다.
  • 1: 상사, 2: 부하직원
  • r1: e1과 e5를 연결해주는 relationship instance. e5가 상사고 e1이 부하이다.