* 10.07 업데이트
해당 게시물은 한양대학교 컴퓨터소프트웨어학부 김상욱 교수님 데이터베이스시스템 온라인 강의를 듣고 정리한 자료입니다.
오류가 있다면 언제든 알려주세요!
● 해당 강의의 학습 목표
1. Conceptual design을 하는 Conceptual model을 Entity-Relationship model(ER)으로 배운다.
- Database design process
- Entity-relationship model
- Conceptual data modeling
◆ Database Design Process
오른쪽 Miniworld에 있는 세로 줄은 Database Design Process이고 왼쪽 줄은 Software Design Process인데 해당 과목에서는 오른쪽 라인만 다룬다.
1) Miniworld
Real world에서 자신이 원하는 일부 관점에서만 바라본 정보
ex) Real world인 한양대학교에서 대학을 운영하는데 필요한 정보만 바라본 것이 miniworld이다.
2) Requirements collection and analysis
요구사항을 모으고 분석하는 것이다. System analyst가 실제 database를 구축하기 위해 application 사용자들과 인터뷰를 통해 어떤 요구사항이 있는지 모으고 분석한다. 이를 바탕으로 data requirements가 나온다. 즉, 어떤 데이터가 저장되어야하고 이에 대한 constraints 등이 모아진다.
* Conceptual Desgin -> Logical Desgin(Data Model Mapping) -> Physical Design : 모두 Database Designer들이 한다.
3) Conceptual Design
얻어진 Data Requirements를 가지고 conceptual desgin을 한다. design은 database의 골격을 결정한다는 뜻이다. 즉, conceptual design은 사용자의 requirement를 보고 사람이 이해할 수 있는 선에서 database의 구조를 설계하는 과정이다. 이를 마치면 사람들이 이해할 만한 수준에서의 골격 즉, Conceptual Schema가 도출된다. 이는 high-level data model로 구성이 되고 가장 대표적인 model이 ER model이다. 한마디로 정리해보자면 conceptual design을 통해 ER model로 구성된 conceptual schema가 도출된다.
Conceptual Schema는 high-level model로 구성되어있기 때문에 DBMS가 이해하지 못한다. DBMS에게 골격을 정해서 알려주기 위해서는 DBMS가 제공하는 model을 통해서 스키마가 디자인되어야 한다. 따라서 해당 단계까지는 DBMS와 관계가 없기 때문에 DBMS-independent이다.
4) Logical Design (Data Model Mapping)
Logical model을 통해서 Logical Schema를 만들어내는 과정이다. Logical Schema는 우리가 데이터베이스를 운영하고자하는 특정 DBMS에서 제공하는 logical model을 가지고 만들어낸 스키마이다. 이 단계부터는 어떤 DBMS를 통해서 데이터베이스를 관리할 것인지 정해줘야한다. 따라서 이는 DBMS-specific하다라고 한다.
logical design을 하는 logical model의 대표적인 예는 relational model이다. 이 결과 logical schema를 얻게 된다. 이를 통해 DBMS에게 골격을 정해서 알려면 database를 돌릴 수 있다. 하지만 performance가 좋지는 않다.
5) Physical design
Database가 적으면 logical design까지만 진행해도 database를 돌릴 수 있다. 하지만 데이터가 많아지면 물리적으로 어떻게 구성할 것인지까지 DBMS에 알려주어야한다. 따라서 해당 단계는 logical schema를 가지고 물리적으로 어떤 식으로 구조화해야 하는지 결정하고 DBMS에게 알려주는 과정이다. 이 부분은 index를 쓰는 등의 (BTREE) 방법을 취한다. 이 결과로 Internal Schema(Physical Schema)가 도출된다.
◆ Example: COMPANY Database (완전히 숙지하기!)
회사 운용을 위한 database이다. 해당 예시로 이후 수업을 계속 진행할 예정이니 완전히 숙지해야한다.
· Requirements (System analyst가 제공)
- Employees, departments(부서), and projects
- Company is organized into departments 회사는 여러개의 부서로 구성되어있다.
- Department: has unique name(key), unique number(key), {locations}, manager and start date when manager began managing the department 부서의 이름, 부서의 ID, 하나의 부서는 여러 위치에 위치할 수도 있다. 부서에 대한 manager 정보, 매니저의 부서 managment start date
- Department controls a number of projects 각 부서가 책임지고 진행하는 여러 프로젝트들이 있다.
- Project: has unique name(key), unique number(key), and location
- Employee: store each employee's name, Social Security number(key), address, salary, sex(gender), and birth date(자동적으로 정년 파악)
- Employee is assigned to one department 소속 부서와의 관계 설명(제한)
- Employee may work on several projects
- Keep track of number of hours per week that employee work on each project 각각의 프로젝트에 얼마만큼 참여했는지 인센티브 계산 가능
- Keep track of the direct supervisor 바로 위에 있는 상사도 바로 추적할 것.
- Keep track of the dependents of each employee 부양 가족 파악
- Dependent: dependent's first name, sex, birth date, and relationship to the employee
◆ Entities and Attributes
· Entity (개체)
- 독립적으로 존재할 수 있는 어떠한 것.
- EX) 사람, 차, 집, 학생, 사원
· Attributes
- 어떠한 특정한 entity를 설명해주는 특성
- EX) 이름, 나이, 주소, 직업, 핸드폰 번호 / 홍길동, 40: attribute value
즉, entity는 실세계에 존재하는 어떠한 것이고 attribute은 그 것을 설명하는 속성들이다.
용어가 나오면 그 용어에 대해 설명하고 예시를 들 수 있어야한다!
· Types of Attributes
- Category 1
1) Simple (atomic) attributes : 원자성을 가지는 속성
- Attributes that are not divisible 속성 값들을 더 나눌 수 없다.
2) Composite attributes
- Can be divided into smaller subparts 작은 subpart로 나눠서 생각할 수 있다.
- Can form a hierarchy
ex) 사원의 이름을 simple/composite attribute로 설명할 수 있다. 이름을 simple attribute로 했다면 홍길동을 찾아라(가능), 성이 홍인 사람을 찾아라(불가능) 이름을 성과 이름으로 분리하면 composite attribute가 된다.
- Category 2
1) Single-valued attribute
- Have a single value for a particular attribute 하나의 attribute에 대해서 하나의 값만 들어갈 수 있다.
- Example: age를 single valued attribute으로 정했다면 age는 하나의 값만 가질 수 있다. 홍길동: 55세 / 옛날 사람들을 호적 언제 등록했느냐에 따라 나이가 두 개인 사람들이 있었다. 그러한 사람들은 대표값으로 넣어야한다.
2) Multivalued attributes (set attributes)
- Have a set of values for the same entity entity의 attribute이 두 개 이상의 value를 가질 수 있다.
- Example: 한 사람이 phone number를 두 개 이상 집어넣을 수 있다.
- Category 3
1) Stored attributes
- 실질적으로 물리적인 데이터베이스에 저장이 된다.
- Example: birth date
2) Derived attributes (별로 신경쓰지는 않음!)
- 실제로 저장되어 있지 않은데 저장되어있는 다른 attribute로부터 유추해서 만들 수 있다.
- Example: age (can be derived from birth date)
· Entity Type
- 같은 attributes set을 가지고 있는 entity의 집합
ex) 사원 집합에 속하는 entity들은 같은 attribute 집합을 가진다. 사원 하에는 Alex, 홍길동, Smith 등이 있다. 그들은 같은 set의 attribute를 공유한다. 홍길동은 entity고 사원은 entity type이 될 것이다.
- entity type은 schema에 해당되는 것이고 entity들은 Instance에 해당된다.
- described by its name and attributes 사원이름, 사원나이, 사원주소, 사원성별...
e1, e2, e3 하나하나를 entity라고 부르고 그들을 합해 놓은 것을 entity set이라 한다. 그 entity set이 공통으로 가지고 있는 속성과 entity type의 이름을 묶어서 entity type이라고 부른다. 위에 있는 entity type은 Schema에 해당되는 것이고 밑에 있는 entity set은 instance에 해당되는 것이다.
· Domains
- 특정한 attribute에 할당될 수 있는 값들의 집합
- ex) Domain for AGE attribute of EMPLOYEE entity: 20 ~ 70
· Key Attribute
- attribute인데 각 entity에 따라서 distinct하다. 즉, 서로 다른 entity는 서로 다른 attribute value을 갖는다.
- ex) 학번. 학번은 고유하다.
- key attribute의 값은 각각의 entity를 유일하게 식별하는데 사용된다.
- multiple attributes can form a key 두 개 이상의 attribute가 합쳐져서 key의 역할을 할 수 있다.
- A entity type can have more than two keys 하나의 entity type에는 두 개 이상의 key를 가질 수 있다.
- key는 유일하게 존재해야하는데 이는 key가 선정이 되어있으면 모든 entity set이 key라는 조건을 만족하도록 enforce되도록 한다.
Q) 한 class에 이름이 같은 사람이 한 명도 없다면 이름이라는 attribute이 학생을 식별하는 역할을 할 수 있다. 이러한 상황에서 이름이라는 속성은 key일까?
A) No. 현재 존재하는 entity set을 보고 해당 속성의 값이 중복되지 않는구나. 하고 key를 정하지 않는다. database designer가 A는 key야! 라고 미리 정하는 것이다. key에 대해서는 모든 entity가 다른 값을 가지도록 enforce한다.
vehicle_id가 key이다. 뉴욕에서 첫 번째로 등록된 차는 하나 밖에 없다. number, state가 합쳐졌을 때만 key가 되는 것이다.
하나의 entity type내에 registration과 vehicle_id 두 개가 key이다.
make가 ford, nissan, chrysler인데 현재 상황에서는 각 entity를 유일하게 결정될 수 있다. 하지만 이걸보고 key를 정하는게 아니라 key는 이미 정해져있다.
◆ Initial Conceptual Design of COMPANY Database
4개의 entity로 구조화하였다. 보통은 single valued attribute!
employee name을 composite attribute로 한 이유는 나중에 FName이 뭐인 사람을 찾거나 이런 것이 일어날 수 있는 것을 염두해 둔 것이다. workson은 composite attribute이면서 multivalued attribute이다.
◆ Relationship
· Relationship instances
- entity sets에서 entity끼리의 관계를 나타낸 것 ex) 홍길동이 임꺽정을 가르친다. teaches(Relationship instance)가 된다.
· Relationship type(마름모로 표현된다.)
- 홍길동은 교수, 임꺽정은 학생일 때, processor라는 entity type과 student라는 entity type(네모로 표현) 간의 관계 타입을 나타낸다. entity type끼리의 관계 타입. 해당 경우에서는 teaches가 된다.
- 참여하는 entity type과 같이 표현된다.
연결 선이 relationship instance
relationship instance의 전체 집합: relationship type
· Relationship Degree
- relationship type의 degree
- relationship type에 참여하는 entity type의 수
ex) works_for라는 relationship type의 degree는 얼마? 2 (employee, department) -> binary 보통은 이거!/ 3개면 ternary relationship type라 한다.
· Binary Relationship
- degree가 2인 relationship type이다. 참여하는 entity type이 2개!
- 가장 흔하게 사용된다.
Ternary relationship type
- degree가 3인 relationship type이다. 참여하는 entity type이 3개!
- ex) Supply relation type has SUPPLIER, PART, PROJECT as participating entity types
r1 : s1이라는 공급자가 p1이라는 부품을 j1이라는 프로젝트에 공급하고 있다는 것을 나타내는 relationship instance
Q) binary relationship type 3개로 ternary relationship type 표현가능?
A) 가능은 하지만 등가는 아닐 수 있음. supply와 같은 경우는 표현 불가능함.
· Recursive Relationships
- role name
- 참여하는 entity type이 각각의 relationship instance에서 어떤 역할을 하는지 명시한 것
- ex) EMPLOYEE and DEPARTMENT in WORKS_FOR relation type
employee-> 일한다.
department -> 일하게 하는 장소의 역할
두 개의 서로 다른 entity type이 하나의 relationship type에 참여할 때는 굳이 role name을 명확히 써주지 않아도 된다. 역할이 너무 분명하기 때문이다.
하지만 recursive에서는 필요하다.
· Recursive Relationships type
- 같은 entity type이 그 Relationship type에 두 번 이상 참여하는데 각각 참여하는게 역할이 다른 경우이다. 서로 다른 entity type은 롤의 이름이 너무 분명하기 때문에 명시하지 않아도 된다. 근데 이와 같은 경우는 하나의 entity type에서 서로 다른 entity가 엮이는 것이기 때문에 역할을 명시해줄 필요가 있다.
1번: 상사, 2번: 부하
e1이 상사 e2가 부하
e5가 상사 e1가 부하
binary relationship이다.
참여하는 entity type은 하나고 하나의 entity type이 relationship type에 대해 두 번 참여하기 때문에 role name을 붙여줘야한다.
Summary
- Database design process
- Basic ER model concepts of entities and their attributes
Different types of attributes
Structural constaints on relationships
'3-2 > 데이터베이스시스템' 카테고리의 다른 글
| [DB05] Relational data model 이해하기 (1) | 2024.10.04 |
|---|---|
| [DB04] ER model (1) | 2024.09.30 |
| [DB02] Database system에서 사용되는 개념들 (3) | 2024.09.22 |
| [DB01] 데이터베이스의 이해, 용어, 장점 (2) | 2024.09.12 |
| B+ Tree 이해하기 (1) | 2024.09.12 |