요구사항 분석 → 설계 (design) → 구현/개발 → 평가/검증 → 유지보수
E-R 다이어그램 (→ 1차 설계) ▶ table로 생성 ▶ 문제가 없는지 확인 (→ 정규화) ▶ 최종 DB
관계형 DB 설계의 목표: 스키마의 완성
- 두 개의 작은 스키마를 결합(combine)하여 하나의 큰 스키마로 재구성
- 하나의 큰 스키마를 분할(decompose)하여 두 개 이상의 작은 스키마로 재구성
대체로 더 작은 스키마일수록 유리함
Good Combined Schema
- 정보의 중복이 발생 (X)
Bad Combined Schema
- 정보의 중복이 발생 (O)
Good Decomposed Schema
- natural join을 진행하였을때 원본 relation을 복구할 수 있음
Bad Decomposed Schema
- 분할 후 정보 손실 (O)
- natural join으로 원본 relation을 복구하기 어려움
- 스키마를 결합하는 것이 좋은가? 분할하는 것이 좋은가?
- 정보의 손실없이 스키마를 분할하는 방법은?
함수종속과 정규화개념이 해결책
DB에 중복된 (or 불필요한) 정보가 있을 경우
- 저장 공간의 낭비
- DB의 여러가지 이상 문제(anomaly)를 야기
- 삽입 이상 (insertion anomaly)
- 삭제 이상 (deletion anomaly)
- 갱신 이상 (update anomaly)
why?
함수 종속; 하나의 relation에 속성 간의 의존성이 존재
삭제 이상
- 연쇄적 삭제로 인한 정보의 손실
삽입 이상
- primary key가 null값을 허용하지 않아 특정 어트리뷰트 없이 일부 정보만 삽입 불가능
갱신 이상
- 여러개의 튜플을 동시에 갱신해야함
Functional Dependency
- X 속성의 값에 따라 Y속성의 값이 결정됨 = "X 속성이 Y 속성을 함수적으로 결정한다"
- X: 결정자 (determinant) / Y: X에 종속됨 (Y is dependent on X)
- 이 관계를 "X→Y"로 표기 (Y is functionally dependent on X)
- X의 값이 동일하면 Y의 값도 동일해야함
- 만약 X가 key라면, X는 이 relation의 다른 속성을 함수적으로 결정함
Functional Dependency Diagram
1. functional dependency를 찾는다
- {sno, cno} → grade ⓐ
- {sno, cno} → year ⓑ
- sno → year ⓒ
- key를 가운데에 배치 → {sno, cno}
- functional dependency diagram을 그린다. (ⓑ는 따로 안 적어줘도 된다)
![](https://velog.velcdn.com/images/jongbeen_song/post/b1144432-3707-4fe5-ada1-9974356dcda9/image.png
Full FD & Partial FD
완전 함수 종속 (Full functional dependency)
- X가 두 개 이상의 속성으로 구성되어 있고, X'가 X의 하위 속성일때, X' → Y가 성립하지 않는 경우
- 즉, X → Y만 성립
- X가 한개의 속성이고, X → Y가 성립하면, X와 Y는 완전 함수 종속
부분 함수 종속 (Partial functional dependency)
- X의 하위 속성 X'에 대해 X' → Y가 성립하는 경우
DB에서 발생하는 anomaly 해결 방법
- 함수 종속을 줄임 → relation의 분할(decomposition) → 정규화(Normalization)
도부이결다조
도메인 원자값 (비정규 ->1)
부분 함수 종속 제거 (1->2)
이행 함수 종속 제거 (2->3)
결정자인데 후보키아닌거 제거 (3->B)
다치종속 제거(B->4)
조인종속성(4->5)
"한 칸엔 하나의 데이터만"
다음 속성이 있다면 1NF에 해당하지 않음
- composite attributes
- multi-valued attributes
- Tuple 단위의 수평적 분할 & Attribute 단위의 수직적 분할
"현재 테이블의 주제와 관련없는 column은 다른 테이블로 분리"
=> prime attribute를 제외한 모든 어트리뷰트에서 partial dependency를 제거한 테이블prime attribute: 기본키를 구성하는 attribute
"일반 컬럼에만 종속된 컬럼은 다른 테이블로 빼기"
=> Transitive FD (이행적 함수 종속) 제거transitive FD: "if X → Y, Y →Z, then X → Z"
- attribute의 수가 두개인 binary relation은 3NF
if "X → Y, Y →Z, and X is the primary key, & Y is candidate key" → anomaly가 발생하지 않음
Anomaly exists only if Y is not a candidate key
=> X → A 관계에 있는 모든 X가 relation의 수퍼키인 상태
=> 즉, relation에 존재하는 모든 결정자(determinant)가 수퍼키가 되도록 함현재 relation에서 결정자를 찾고, 결정자 중에 수퍼키가 아닌 것을 분리해내면 된다
"다치 종속 제거"
다치 종속: 1:다 대응 ex) 아이디 → 수강과목 (하나의 ID가 여러개 수강 가능)
"조인 종속성 이용"