데이터베이스 설계
사용자의 요구사항으로부터 현실세계를 반영한 데이터베이스 구조를 도출해내는 과정
1. 요구사항 분석
-> DB의 사용환경, 대상, 제한 조건(제약 조건) 도출
2. 개념적 설계
-> 개념적 스키마(ER) 생성
3. 논리적 설계
-> 논리적 스키마 생성 (특정 DBMS 구조에 맞는 스키마 생성, ex) MySQL에 맞는 스키마 생성)
4. 물리적 설계
-> 물리적 스키마 생성 (storage관점)
5. 구현
-> 목표 DBMS의 DDL(정의 언어)로 데이터베이스 생성, 트랜잭션 작성
<고려 사항>
- 충실성: 필요로 하는 모든 데이터를 표현해야 함
- 단순성: 단순하고 이해하기 쉬운 구조로 표현해야 함
- 중복의 최소화: 데이터의 중복을 최소화하고 데이터 일관성을 유지해야 됨
(A,B,C릴레이션에 a라는 튜플이 있다면, a라는 튜플을 수정할 때도 모든 릴레이션에서 수정해야 됨) - 제약조건의 표현: 데이터가 갖추어야 할 조건을 표현해야 됨
(기본키 제약조건, 외래키 제약 조건 등)
ER to Relational
(개체를 테이블로 만들기)
개체의 속성을 테이블로 만든다.
(관계를 테이블로 만들기)
관계에 참여하는 두 개체의 기본키 + 관계의 속성을 테이블로 만든다.
기본키: 관계에 참여하는 두 개체의 기본키를 합한 것
외래키: 관계에 참여하는 두 개체의 기본키 각각
Relationship Sets to Tables 1:1
방법1 – E2개체와 R관계를 하나의 릴레이션으로 표현함
방법2 – E1개체와 R관계를 하나의 릴레이션으로 표현함
방법3 – E1개체와 R관계와 E2객체를 각 릴레이션으로 표현함
방법4 – 관계를 릴레이션으로 표현하지 않음
(예시)
방법1- 부서 개체와 부서장 관계를 하나의 테이블로 만듦
-> 모든 부서에 부서장이 있으니 NULL값이 존재하지 않음 (ssn에 NULL이 존재 X)
방법2- 사원 개체와 부서장 개체를 하나의 테이블로 만듦
-> did속성에 NULL값이 많이 생겨서 공간 낭비가 심하게 됨 (사원들은 부서장이 아니기 때문)
=> (방법1)이 더 좋은 방법이다.
방법3은 필요 이상으로 릴레이션 수를 늘려서 검색할 때 조인이 필수적임 (비효율적)
방법4는 E1과 E2 모두 전체 참여일 때 좋음
(예를 들어 관계에 ‘아내’가 있는데 E1개체와 E2개체 모두 ‘아내’가 존재한 경우)
Relationship Sets to Tables 1:N
E1과 E2를 ‘교수’와 ‘학생’으로 생각해보자. R은 ‘지도’라고 생각하자.
방법1의 E2릴레이션은 아래와 같을 것이다.
(PK2: 학번, A2: 이름, FK1: 지도 교수 번호)
방법2의 E1릴레이션은 아래와 같을 것이다.
(PK1: 지도 교수 번호, A1: 지도 교수 이름, FK2: 지도 학생 번호)
즉 방법1의 E2 기본키는 중복이 일어날 일이 없다.
(같은 학번이 나올 일이 없기 때문)
하지만 방법2의 E1 기본키는 중복이 일어나게 된다.
(한 교수당 여러 학생을 지도한다는 것을 나타내야 되기 때문)
따라서 [방법1]을 사용해야 된다.
Relationship Sets to Tables N:M
E1을 ‘학생’, E2를 ‘과목’이라고 생각할 수 있다.
이런 경우 방법1을 사용하든 방법2를 사용하든 많은 중복이 발생한다.
조인을 감안하고 [방법3]을 사용하는 것이 가장 효율적이다.
키 제약조건을 나타내는 DDL
[방법1 -> E1과 E2의 기본키를 모두 속성으로 주고 E1의 기본키를 외래키, E2의 기본키를 기본키로 설정한다. ]
전체 참여 조건을 나타낼 때는 NOT NULL을 사용한다.
-> 모든 부서에 부서장이 존재한다.
Weak Entity Sets
사원과 부양가족 (사원이 있어서 사원의 부양가족도 있음) -> Dependents가 약한 개체
부양 가족 이름[부분키](pname), 피부양자의 번호[기본키], age, sex가 Dep_Policy의 속성이 됨
기본키는 (ssn,pname)이 되고 외래키는 ssn이 됨
ISA Hierachies
시간제 사원(Hourly Emps) is a 사원(Employees)
계약직 사원(Contract_Emps) is a 사원(Employees)이다.
모든 사원은 (ssn,name,lot)을 속성으로 가진다.
=> 두 개의 릴레이션으로 만드는 방법
[Employees+Hourly_Emps], [Employees+Contract_Emps]
장점: 조인을 하지 않아도 된다. / 단점: 중복이 많아진다. (ssn,name,lot)
=> 세 개의 릴레이션으로 만드는 방법
[Employees], [Hourly_Emps], [Contracy_Emps] — ssn만 추가
장점: 중복이 적어진다. / 단점: 조인을 많이 해야 된다.