[Lecture 03] DB design process, Entity-relationship model

Objectives

• Database design process
• Entity-relationship model

---

Database Design Process

Miniworld

real world에서 자신이 원하는 부분의 일부 관점에서 바라본 것이다.

모든 DB는 전체 real world를 다루지 않는다.

Requirements collection and analysis

요구사항을 모으고 분석한다. 누가? system analyst가.

Data requirements

바로 전 단계인 Requirements collection and analysis 의 결과를 의미한다.

어떤 데이터가 저장되어야 하는지, 그 데이터에 대한 constraints 이 무엇인지를 알 수 있다.

Conceptual Design

여기서부터 DB designer가 하게 되는 부분이다.

data requirements를 가지고 concpetual design을 하는데, 이때 high-level model로 디자인을 하게 되는 것이다. (가장 대표적인게 ER model)

Conceptual Schema

conceptual design의 결과로 conceptual schema를 얻을 수 있다.

Logical Design

conceptual schema는 '사람들이 보기에' 라는 컨셉으로 디자인 된 결과다.

따라서 DBMS가 이해하지 못하기 때문에 이 과정이 별도로 필요하다.

즉, DBMS가 제공하는 모델을 통해서 schema가 제공되어야 하고, 이 과정이 그렇게 바꿔주는 과정인 것이다.

이 단계에서는 가장 대표적으로 relational model이 사용된다.(대부분의 DBMS가 사용하는 모델이라서)

그림에서는 Logical(Conceptual) 이렇게 나와있어서 헷갈릴 수 있는데, 나는 logical == representational 이라고  이해했다.

Logical Schema

Logical design의 결과로 logical schema를 얻을 수 있다. 

Physical Design

이 단계는 없어도 사실 프로그램이 돌아갈 수는 있다.

다만, 데이터 양이 많아지면 성능 이슈가 생기기 때문에 그런 점을 고려하는 부분이다.

따라서 데이터의 양이 많아질 때 물리적으로 어떻게 구성할지 알려주는 파트라고 할 수 있다.

Internal schema

physical design의 결과로 internal schema를 얻을 수 있다.

---

COMPANY Database (완전히 숙지할 것!! 집중!!)

회사 DB는 왜 필요한가?

회사의 운영을 위해 필요한 정보들을 저장하고 관리해야 한다. (miniworld)

 

Requirements

• Employees, departments, and projects
• company는 여러 department들로 구성된다.
• Department: unique name, unique number, locations, manager and start date 를 가진다.
  • Department는 여러 위치에 존재할 수 있다. 예를 들면 서울, 대전, 부산에 하나씩 존재할 수 있다.
  • start date은 매니저가 매니지먼트를 시작한 날짜를 의미한다.
• Department는 여러 개의 project를 control한다.
• Project: unique name, unique number and location
  • project는 여러 개의 위치에 존재할 수 없다. 
• Employee: name, SSN(Social Security Number), address, salary, sex(gender), and birthdate
  • 같은이름을 허용한다.
  • SSN은 주민번호를 의미한다.
  • birth date은 정년 계산 등에 이용할 것이다.
• Employee는 하나의 department에 배정된다.
• Employee는 여러 개의 project에서 일할 수 있다.
• Employee가 각 project에서 몇 시간 일했는지 tracking한다.
• Direct supervisor가 누군지 tracking한다.
• 각 employee의 dependent들을 tracking한다.
• Dependent: (dependent's first?) name, sex, birthdate and relationship 
  • 여기서 왜 dependent's first name인지 모르겠다..
  • 뒤에서는 그냥 Name이라고 나옴.

---

COMPANY Database

 

이것이 ER model을 활용해서 conceptual design한 결과인 conceptual schema이다.

자세한 symbol은 다음 포스팅에서 다루겠다.

---

Entities and Attributes

Entity

real world에서 독립적으로 존재할 수 있는 것을 의미한다.

ex) person, car, house, student, employee, ...

Attribute

특정 entity를 기술하는 특성을 의미한다.

ex) name, age, address, job, phone number, ...

Entity: e1, c1

Attribute: Name, Address, Age, Home_phone, Name, Headquarters, President

Attribute Value: attribute에 해당하는 실제 value들

---

Types of Attrubutes

Category 1

Simple(atomic) attributes

• 나뉠 수 없는 attribute
• ex) 성이 '홍'인 사람을 찾으려고 할 때, 이름이 simple attribute로 저장되면 찾을 수 없다. '홍길동'에서 '홍' '길동' 으로 쪼개질 수 없기 때문이다.

Composite attributes

• 나뉠 수 있는 attribute
• ex) 성이 '홍'인 사람을 찾으려고 할 때, 이름이 composite attribute로 저장되면 찾을 수 있다.
• hierarchy를 형성할 수 있다.

 

Category 2

Single-valued attributes

• 하나의 값만 가질 수 있는 attribute
• ex) age: age에는 하나의 값만 가질 수 있다.

Multivalued attributes(set attributes)

• 여러 value를 가질 수 있다.
• ex) phone-number

Category 3

Stored attributes

• 물리적으로 DB에 저장된 attribute
• ex) birth date

Derived attributes

• 실제 DB에 저장된 데이터로부터 유추해서 만들어 낸 attribute
• ex) age: birth date로 부터 유추할 수 있음

---

Entity Type

같은 attiribute set을 가지는 entity들의 집합을 정의하는 것을 의미한다.

schema를 나타내며, 대표적인 entity type이 'EMPLOYEE' 이다.

Entity type은 그것의 이름과 attribute들을 기술한다.

파란색으로 네모 친 부분을 Entity type이라고 한다.

 

 

Domains

attribute에 할당될 수 있는 value들의 set.

attribute A의 domain으로 정의할 수 있다.

ex) attribute Age의 domain (EMPLOYEE entity에서) : 20~70

---

Key Attribute

각 individual entity를 구별할 수 있는 attributes 를 의미한다.

key attribute의 values는 각 entity를 유일하게 식별하는 데 사용될 수 있다.

ex) student number of STUDENT entity

 

• 두 개 이상의 attribute들이 합쳐져서 key의 역할을 할 수 있다.
• 한 entity type은 두 개 이상의 key attribute을 가질 수 있다.
  • 이 두 가지는 다른 의미니까 확실히 구분하도록 하자.
• Key 인지 아닌지는 DB를 디자인하는 단계에서 정해지는 것이다. 즉, 특정 시점의 DB상태를 보고 판단할 수 있는 것이 아니다.

 

Registration(Number, State)를 보면 composite attribute이자 key attribute 이다.

즉, 두 개 이상의 attribute가 합쳐져서 key의 역할을 하고 있다.

Vehicle_id 역시 key attribute이다.

한 entity type내에 두 개 이상의 key attribute이 존재할 수 있음을 알 수 있다.

---

Initial Conceptual Design of the COMPANY Database

Name, Number : 밑줄 표시는 unique 즉, key attribute임을 의미한다.

아무 표시가 없는 것은 simple attribute를 의미한다.

{}: multivaled attribute, (): composite attribute를 의미한다.

---

Concepts of Relationship

Relationship instance

entity-entity 간의 association을 의미한다.

 

Relationship type

relationship instance 들의 set을 나타낸다.

 

ex) PROFESSOR, STUDENT entity가 있고, TEACHES라는 relationship type이 있다고 할 때, 홍길동이 교수, 임꺽정이 학생이라면 홍길동, 임꺽정은 각 entity type의 instance이고, 홍길동이 임꺽정을 'teaches'하는 것이 relationship type의 instance가 된다.

그래도 이해가 안된다면 아래의 그림을 보도록 하자.

 

r1,r2, ... 가 relationship instance가 되는 것이다.

---

Relationship Degree

relationship type의 degree로, 관계에 참여하는 entity type의 수를 의미한다.

두 개면 binary, 세개면 tenary, ...

 

Binary Relationship

degree가 2인 relationship type을 의미한다.

가장 많이 사용되는 타입이다.

Ternary Relationship

degree가 3인 relationship type을 의미한다.

 

누가 어떤 부품을 누구에게 제공하는지를 나타낸다.

---

Recursive Relationships

같은 entity type이 한 relationship type에 서로 다른 역할로 두 번이상 참여할 때를 말한다.

이때는 반드시 role name을 명시해줘야 한다.

 

Role name

각 entity의 역할을 나타낸다. 

1은 상사, 2는 부하직원을 의미한다. 즉 역할을 명시한 것이다.

 

EMPOLYEE는 entity type이고, SUPERVISON은 relationship type이다.

Tip) entity type은 주로 명사로, relationship type은 주로 동사로 이름 붙이는 것이 좋다. 따라서 SUPERVISON보다 SUPERVISES가 더 좋은 방법이다.