해당 글은 데이터베이스 첫걸음, 관계형 데이터베이스 실전 입문을 정리한 내용입니다.
제 테이블에 셀에 복합적인 값을 포함하지 않는다.
관계형 데이터베이스에서는 이 정의에 반하는 테이블을 작성하는 것이 기술적으로 불가능 하기 때문에 관계형 데이터베이스의 테이블은 전부 제 1정규형을 자동으로 만족합니다.
| 사원ID | 이름 | 피부양자 |
|---|---|---|
| S001 | 박미경 | 박초롱 |
| S002 | 박유안 | 박안나 |
| S003 | 이관식 | [이수빈, 이수인] |
- 이관식 씨는 아이가 2명이여서 비부양자 칸에 이수빈, 이수인 2명의 이름을 배열로 적었습니다.
- 이런 구조는 1NF 위반이며 테이블을 분리 해야합니다.
| 사원ID | 이름 |
|---|---|
| S001 | 박미경 |
| S002 | 박유안 |
| S003 | 이관식 |
| 사원ID | 피부양자 번호 | 비부양자 이름 |
|---|---|---|
| S001 | 1 | 박초롱 |
| S002 | 1 | 박안나 |
| S003 | 1 | 이수빈 |
| S003 | 2 | 이수인 |
부분함수 종속성이 존재하지 않아야 한다.
부분함수 종속성 이란?
기본키를 구성하는 열의 일부에만 함수 종속성이 존재하는 것
| 고객기업ID | 주문번호 | 고객기업명 | 고객기업 규모 |
|---|---|---|---|
| CA | 001 | A 상사 | 대규모 |
| CA | 002 | A 상사 | 대규모 |
| CB | 003 | A 건설 | 중규모 |
- 1NF는 충족하고 있습니다.
- 2NF는 충족하지 못하고 있습니다.
| 고객기업ID | 주문번호 |
|---|---|
| CA | 001 |
| CA | 002 |
| CB | 003 |
| 고객기업ID | 고객기업명 | 고객기업 규모 |
|---|---|---|
| CA | A 상사 | 대규모 |
| CB |
건설 | 중규묘 |
- 전체 열이 기본키만으로도 함수 종속을 가지고 있이며 기본키의 일부에만 종속하지 않은 열이 없습니다.
테이블은 집합이다라는 관점에서 고객기업 주문 테이블과 고객기업 테이블은 각각 확살하게주문,고객이라는 집합에 대응하고 있습니다.
| 고객기업ID | 고객기업명 | 고객기업규모 | 업계코드 | 업계명 |
|---|---|---|---|---|
| CA | A상사 | 대규모 | D001 | 석유 |
| CB | B건설 | 중규모 | D002 | 건설 |
| CC | C호확 | 소규모 | D003 | 바이오 |
- 고객기업 ID 한 개의 열이라서 2제 정규형도 만족합니다.
- 하지만 테이블 갱신 이상이 존재합니다.
- 테이블에 업계를 등록할 방법이 없습니다.
- 테이블에는
기업이라는 단위의 집합을 반영할수 있어도유통업계를 속한 기업과 거래하지 않은 이상 해당 업계 코드를 만들수 없습니다.
| 고객기업ID | 고객기업명 | 고객기업 규모 | 업체코드(FK) |
|---|---|---|---|
| CA | A상사 | 대규모 | D001 |
| CB | B건설 | 중규모 | D002 |
| CC | C호확 | 소규모 | D003 |
| 업계코드 | 업계명 |
|---|---|
| D001 | 석유 |
| D002 | 건설 |
| D003 | 바이오 |
- 업계 테이블에 원하는 만큼 새로운 업계를 추가할 수 있습니다. (아직 거래가 없는 업체라 할지라도)
- 제3정규형을 다시 집합 관점에서 보면 비정구형 테이블은
기업,업계라는 명백히 계층이 다른 집합들을 하나의 테이블에서 관리하려 했던 것을 알 수 있습니다. - 이것을 간단하게 나누어서 관리하려고 하면 제 3정규형에 준수하게 됩니다.
2NF는 후보키의 진부분집합에서 키가 아닌 속성에 대한 함수 종석성을 제거 했다. 3NF는 키가 아닌 속성에서 다른 키가 아닌 속성에 대한 함수종속성을 제거했다. 남아 있는 패턴은 키가 아닌 속성에서 후보키의 진부분집합에 대한 함수종속성이다.
| 학생 | 과목 | 교수 | 학점 |
|---|---|---|---|
| 김석준 | Java | 이동준 | A |
| 박성준 | OOP | 이강준 | A |
| 이성태 | OOP | 이강준 | A |
후보키는 슈퍼키 중에서 최소성을 만족하는 건데. 이 경우 {학생, 과목} 입니다. 교수가 정해지면 과목이 결정됩니다. 함수 종속성이 존재하기 때문에 BCNF를 만족못합니다(교수는 후보키가 아니기 때문에).
3NF를 만족하면서 BCNF를 만족하지 못하는 경우는 일반 커럼이 후보키를 결정하는 경우입니다. 교수라는 일반 칼럼이 과목이라는 후보키를 결정하고 있습니다.
| 교수 | 과목 |
|---|---|
| 이동준 | Java |
| 이강준 | OOP |
| 학생 | 과목 | 학점 |
|---|---|---|
| 김석준 | Java | A |
| 박성준 | OOP | A |
| 이성태 | OOP | A |
| 이름 | 학과 | 연구실 |
|---|---|---|
| 정은오 | 컴퓨터 아키텍처 | 장치 드라이버 |
| 횽윤서 | 컴파일러 | 최적화 |
| 오민혁 | 데이터베이스 | 관계형 데이터베이스 |
이 릴레이션에서 연구실 쪽이 학과보다 자세한 정보라는 점이다. 연구실을 알면 학과를 알 수 있는 관계성을 가진다 즉 {연구실} -> {학과}라는 함수종석성이 존재한다. 이 릴레이션은 보면 {이름, 연구실}을 후보키로 하는 것이 가능하다. 그런데 마찬가지로 {이름, 학과}라는 속성의 집합도 후보키가 될 수 있다.
이처럼 3NF 이긴 하지만 BCNF가 될 수 없는 릴레이션은 후보키가 되는 속성의 조합이 여러 개 존재한다. 함수 족성성의 관계성을 생각하면 {연구실} -> {학과} 라는 함수 종속성이 존재 하므로 {이름, 연구실}의 값을 알면 {학과}의 값도 알수 있으므로 {이름, 연구실}을 키로 사용하는 편이 좋을 지도 모른다.
따라서 이 릴레이션은 2NF와 마찬가지로 {이름, 연구실}, {연구실, 학과}로 프로젝션해 무손실 분해가 가능하다.