2024. 9. 23. 08:00ㆍCS/Database System
데이터베이스를 설계할 때 테이블을 바로 만드는 것이 아니고, 테이블을 설계할 때부터 근거가 있어야 한다.
그 첫 단계가 바로 ER 다이어그램이다.
데이터베이스의 설계 과정은 다음과 같다.
- 인터뷰나 업무에 대한 문서를 보고 분석한다.
- 요구사항 수집
- 이 단계에서 요구사항이 무슨 엔티티, 테이블이 필요하고 그런 형태가 아니라 학생들은 무슨 과목을 수강할 수 있어야 한다. 와 같은 방식이다.
- 요구사항은 굉장히 일반적인 단어 예를 들어 학생, 필수 과목, 이런식으로 일반인들이 사용하는 일반적인 단어로 구성된다.
- 요구사항을 바탕으로 ER 다이어그램 모델링
- ER 다이어그램으로 테이블 구성
- 만들어진 테이블의 중복성을 제거하기 위해 normalization 수행
- 정규화의 핵심은 테이블을 분리시켜서 중복성을 제거하는 것이다.
- 정규화된 테이블을 역정규화
- 역정규화는 다시 일부 테이블을 원상복구시키는 것인데, 역정규화를 하는 이유는 속도를 보장하기 위해서이다.
- 테이블이 다 분리되어서 JOIN이 너무 많으면 검색 속도가 느리기에 중복성을 어느 정도 감수하고 테이블을 붙이는 경우도 있다.
이번 챕터에서는 1~3의 내용만 다룬다.
중요한 것은 ER 다이어그램을 그릴 수 있어야 하고, 다이어그램을 보고 테이블을 만들 수 있어야 한다. 3 정규화 단계까지도 꼭 할 수 있어야 한다.
역정규화는 현업에서 많이 사용하고 학부생 수준에서는 요구되지 않는다.
1. Using High-Level Conceptual Data Models for Database Design
용어부터 짚고 넘어가자.
| 릴레이션 용어 | 같은 의미로 통용되는 용어 | 파일 시스템 용어 |
| 릴레이션(relation) | 테이블 | 파일 |
| 스키마(schema) | 내포(intension) | 헤더 |
| 인스턴스(instance) | 외연(extentsion) | 데이터 |
| 튜플(tuple) | 행 | 레코드 |
| 속성(attribute) | 열 | 필드 |
수집한 요구사항은 일반적인 단어로 되어있다. 요구사항에서 테이블을 추출해야 한다.
예를 들어 생각해보자.
위의 요구사항을 보고 분석해 보면 다음과 같은 사실을 얻을 수 있다.
- 데이터베이스는 직원들의 주민번호, 주소, 급여, 성별, 생년월일을 저장해야 한다.
- 각 직원은 한 부서 혹은 여러 부서에서 일을 할 수 있다.
- DB는 직원이 각 프로젝트에서 한 주에 몇 시간 일을 했는지 track 해야 한다.
- 각 직원의 supervisor가 있는데, supervisor도 track 할 수 있어야 한다.
- 각 직원은 부양가족을 가지고 있다.
- 각 부양가족에 대한 이름, 성별, 생년월일, 직원과의 관계를 저장해야 한다.
요구사항만 보고서는 데이터베이스 설계를 위해 어떤 엔티티나 테이블이 필요한지 가시적으로 알 수 없다. 따라서 ER 다이어그램을 그려야 하고, 위의 요구사항을 그려보면 아래와 같다.
2. Entity Types, Entity Sets, Attributes, and Keys - ER Model
Entities and Attributes
- Entity는 ER 모델의 기본 개념으로 mini-world의 개체를 의미한다.
- 예를 들어 학생 A, 학생 B는 각각 하나의 엔티티가 된다.
- Attributes는 엔티티를 설명하기 위해 부여하는 속성으로 값을 갖는다.
- 학생의 이름, 성별, 학번 등 엔티티를 설명하기 위해 부여하는 것이 Attribute가 된다.
- 각 속성은 아무 값이나 갖는 것이 아니라 BirthDate는 09-JAN-55와 같은 날짜 형식이 되어야 하는 것처럼 data type이 정해져야 한다.
Types of Attributes
Simple
- atomic value, 즉 더 이상 분리가 되지 않는 값이다.
- 예를 들어 SSN, Sex 등이 된다.
Composite
- 몇 개의 컴포넌트로 구성되어 있는 값이다.
- 예를 들어 Address는 Street, City, State, Zip으로 구성되어 있다.
Multi-valued
- two tone car를 생각해 보면 color 속성이 balck, white 두 개의 값을 가져야 한다.
ER 다이어그램에서는 Composite, Multi-value를 허용하지만 실제로 잘 사용되지는 않는다. 실제 테이블로 구성하게 되면 두 타입은 모두 허용되지 않기 때문이다. 나중에 정규화 과정에서 이런 타입들은 다 걸러지게 된다.
예를 들어 아래의 테이블을 생각해 보자.
| name | phone | previous major |
| A | 010-1111 | CS |
| A | 010-1111 | economy |
Multi value를 허용한 값이기 때문에 위의 테이블처럼 구성된다.
만약 학생의 전화번호가 바뀌면 엔티티 두 개의 전화번호를 바꿔줘야 한다. 이는 일관성 문제의 위험성을 안고 있다. 둘 중 하나만 바뀐다면 일관성이 깨지게 되고 데이터 중복이 발생했기에 이런 문제가 생긴다.
그래서 나중에 테이블을 만들 때 composite, multi-valued 타입은 다 걸러지지만 ER 다이어그램에서만 허용되는 것이다.
Entity Types and Key Attributes
entity를 모아놓은 것에 대해 이름을 부여할 수 있는데 그게 Entity type이다.
즉, entity를 모아놓은 집합에 대해 EMPLOYEE, COMPANY와 같이 이름을 붙일 수 있다.
같은 속성을 갖는(값이 같다는 게 아님) entity 집합이 entity set이 되고 집합에 대한 이름이 entity type name이 된다.
EMPLOYEE라 하면 Entity Type Name, ENtity Set 둘 다를 의미한다.
unique 한 속성은 엔티티 간의 구별이 가능하므로 entity의 key가 될 수 있다.
- key attribute는 composite가 될 수 있다. 이름 + 학과가 unique 하다면 이름 + 학과를 key로 설정할 수 있는 것이다.
- 예를 들어 미국의 자동차 번호는 (Number, State)로 구성된다. 이 두 값을 조합해서 차량을 unique 하게 구분할 수 있다.
- ER 다이어그램에서 각각의 key는 underline을 긋는다. 실제 ralational schema에서 테이블로 만들 때는 primary key 하나만 underline을 긋지만 ER 다이어그램에서는 모든 key에 underline을 긋는다.
위의 ER 다이어그램에서 Registration이 composite key, Vechicle_id는 key, Color은 multi-valued를 의미한다.
위의 다이어그램에서 실제 들어가는 entity는 다음과 같다.
ER다이어그램에서 entity라 부르는 것이 relational data model에서는 tuple이 되고, 실제 table에서 구현하면 record가 된다.
Entity Set
- 각 entity type은 entities의 집합을 가진다. 이를 entity set이라 부른다.
- entity type name은 entity type, entity set 둘 다를 지칭한다.
- 그 둘을 구별하고 싶다면 다른 이름을 줄 수 있다.
- Entity set은 엔티티의 현재 상태이다. 인스턴스가 변경될 수 있는 것처럼 확장 가능하다는 의미에서 extension이라 불린다.
Value Sets of Attributes
- 각 simple 속성은 value set(domain)과 연관되어 있다. domain은 값이 가질 수 있는 한계를 의미하는데 예를 들어 last name은 15자 이하, 날짜라면 MM-DD-YYYY 형태 이런 게 다 domain이다.
- value set은 domain of values를 의미한다.
Displaying an Entity type
entitty type은 사각형 box로 그린다. 속성은 타원형으로 그린다.
- 각 속성은 entity type으로 연결된다.
- composite 속성의 컴포넌트는 타원으로 그리고 composite 속성과 연결한다.
- 각 key 속성은 underlined 된다.
- multivalued 속성은 double 타원으로 그린다.
Initial Conceptual Design of Entity Types for the COMPANY Database Schema
- 요구사항에 근거해서 initial entity type을 식별할 수 있다.
- DEPARTMENT
- PROJECT
- EMPLOYEE
- DEPENDENT
- initial attributes는 요구사항 설명에서 보인다. 예를 들어 EMPLOYEE는 뭐가 필요하고, 뭐가 필요하고 등이다.
요구사항을 보고 위의 ER 다이어그램을 그릴 수 있어야 한다. 요구사항을 보고 뭐가 key가 될 수 있는지, 뭐가 composite, multi-valued인지 잘 구분해 보자.
여기까지만 그리고 테이블을 만들어서는 안 된다. ER 다이어그램은 아직 끝이 아니다. Relationship에 대한 이야기가 빠져있다.