* DB 모델링의 목적
## 주요 용어
- table(relation; entity; file)
- intension(schema; header) => 데이터 구조 설계도
- extension(instance; data) => 데이터
- row(tuple; record) => 데이터(여러 컬럼으로 이루어진) 한 개. 예) 학생
- column(attribute; field) => 데이터의 한 항목. 예) 이름, 학번, 전화번호
* key
## 키(key)
- 데이터를 구분할 때 사용할 식별자.
- "수퍼 키(super key)"라 부르기도 한다.
- 식별자?
- 데이터를 구분할 때 사용하는 값.
- 한 개 이상의 컬럼으로 구성된다.
- 식별자를 key라고 부른다.
- 예) 학생(학번, 이름, 전화, 이메일, 학과, 우편번호, 주소, 주민등록번호)
- 학번 (O)
- 주민등록번호 (O)
- 이메일 (O)
- 전화 (X)
- 이름 (X)
- (이름,전화) (O)
- (이메일,이름) (O)
- (이름,학과,학번) (O)
- (이름,학과,전화) (O)
### 후보키(candidate key) 선정
- super key 들 중에서 선별된 최소키를 가리킨다.
- 최소키? 최소한의 컬럼 값 만으로 식별이 가능한 key.
- 수퍼 키 예)
- 학번 (O)
- 주민등록번호 (O)
- 이메일 (O)
- (이름,전화) (O) => 이름과 전화 값을 묶은 것 보다 적은 개 수의 후보 키가 있다면 가능한 제외하라!
- (이메일,이름) (X) => 이메일 만으로 식별 가능
- (이름,학과,학번) (X) => 학번 만으로 식별 가능
- (이름,학과,전화) (x) => 이름과 학과, 전화 보다 더 적은 컬럼의 후보 키가 있기 때문에 가능한 제외한다.
### 기본 키/주 키(primary key; PK)
- 후보키 중에서 데이터 식별자로 사용하기 위해 선정된 키.
- 예) 학번
- 나머지 후보키는 대안키(alternate key)라 부른다.
- 예) 주민등록번호, 이메일, (이름,전화)
- 왜? 비록 PK는 아니지만 PK와 마찬가지로 데이터 식별자로 대체하여 사용할 수 있기 때문이다.
### 대리 키(surrogate key)/인공 키(artificial key)
- 주 키의 컬럼의 개수가 많거나 주 키로 사용할 적절한 컬럼이 없는 경우,
일련번호와 같은 임의의 컬럼을 추가하여 PK로 만든다.
- 예1) 게시물 첨부파일(파일명, 등록일)
- 파일명이 중복될 수 있다.
- 파일명과 등록일을 묶어서 PK로 사용하기에는 적절하지 않다.
- 이런 경우 "첨부파일번호" 컬럼을 임의로 추가하여 PK로 설정한다.
- 결론) 게시물 첨부파일(파일번호, 파일명, 등록일)
- 예2) 수강신청(수강생이름, 수강생전화, 수강생이메일, 과목명, 결제여부, 결제유형)
- 주 키로 사용할만한 적절한 컬럼이 없다.
- 여러 개의 컬럼을 묶어서 주 키로 사용하자니 너무 복잡하다.
- 이런 경우에도 "수강신청번호"와 같은 임의의 컬럼을 추가하여 PK로 선정하는 것이 좋다.
- 주 키로 선정된 컬럼의 값은 변경될 수 없기 때문에,
일련번호와 같은 임의의 컬럼을 pk로 사용한다.
- pk가 아닌 컬럼은 언제든 값을 변경할 수 있다.
- 예1) 수강생(이름, 나이, 핸드폰, 이메일, 우편번호, 주소, 은행명, 계좌번호, 최종학력, 전공)
- 핸드폰이나 이메일은 PK로 사용할 수 있다.
- 그러나 핸드폰이나 이메일은 가끔 변경될 수 있다.
- 문제는 PK로 지정된 컬럼은 한 번 사용되면 변경할 수 없다는 것이다.
- 핸드폰과 이메일처럼 나중에 변경될 수 있는 컬럼인 경우 PK로 지정하지 않는 것이 좋다.
- 그럼 PK 컬럼은 무엇을 사용하는가?
- 이런 경우 "수강생번호"와 같은 임의의 컬럼을 만들어 PK로 사용한다.
- 예2) 페이스북에 로그인할 때 이메일이나 전화번호를 사용하지만,
실제 주키로 사용하는 것은 사용자 일련번호이다.
# 요약 및 정리
(수퍼키) 데이터를 구분할 때 사용하는 키가 수퍼키이다.
- 예) 학생(학번, 이름, 전화, 이메일, 학과, 우편번호, 주소, 주민등록번호)
(후보키) 수퍼키들 중에서 최소한의 데이터 구분/식별이 가능한 키가 후보키이다.
- 예) - 학번 (O) - 주민등록번호 (O) - 이메일 (O) (사용자들을 컬럼 조합 없이 최소한으로 식별 가능한 키)
- (PK), 즉 주키는 후보키 중에서 데이터 식별자로 사용하기 위해 선정된 키이다.
- 예) 학번
- (대안키) 나머지 후보키는 대안키(alternate key)라 부른다.
- 예) 주민등록번호, 이메일, (이름,전화)
- (대리키/인공키) 주 키의 컬럼의 개수가 많거나 주 키로 사용할 적절한 컬럼이 없는 경우,
일련번호와 같은 임의의 컬럼을 추가하여 PK로 만든다.
- 예1) 게시물 첨부파일(파일명, 등록일)
- 파일명이 중복될 수 있다.
- 파일명과 등록일을 묶어서 PK로 사용하기에는 적절하지 않다.
- 이런 경우 "첨부파일번호" 컬럼을 임의로 추가하여 PK로 설정한다.
- 결론) 게시물 첨부파일(파일번호, 파일명, 등록일)
- 예2) 수강신청(수강생이름, 수강생전화, 수강생이메일, 과목명, 결제여부, 결제유형)
- 주 키로 사용할만한 적절한 컬럼이 없다.
- 여러 개의 컬럼을 묶어서 주 키로 사용하자니 너무 복잡하다.
- 이런 경우에도 "수강신청번호"와 같은 임의의 컬럼을 추가하여 PK로 선정하는 것이 좋다.
즉, 이러한 데이터가 형성될 수 있다.
* DB 모델링 절차
* ERD 관계도 ?
테이블과 테이블의 관계가 아니라 테이블 내부의 데이터와 데이터 간의 관계에 따라
1대다, 1대1, 다대다 관계가 성립하는 것이다.
# 제 1정규화 (원자성 만족)
- 정규화? 데이터 중복을 찾아내어 별도의 테이블로 데이터를 분리시키는 것.
- 중복 데이터 또는 중복 컬럼을 별도의 테이블로 분리하여 부모-자식 관계를 맺는다.
- 데이터를 참조 하는 테이블이 자식테이블이고, 데이터를 갖고 있는 테이블이 부모 테이블이다.
- 자식 테이블에서는 부모 테이블의 데이터를 가리키기 위해 그 데이터의 pk값을 보관해야 한다.
- 부모-자식 테이블을 식별하기 애매할 때 1 : 다 관계에서 1 쪽이 부모 테이블이다.
- 이렇게 부모 테이블의 데이터에 대해 PK값을 저장하는 컬럼을 외부키(FK)라 부른다.
- 중복 컬럼? 사진1, 사진2, 사진3
- 중복 데이터? 교육센터명, 부서명, 은행명, ...
<기존>
<제1정규화 과정>
제 3정규화 (이행적 함수 종속 제거)
- 어떤 컬럼이 PK가 아닌 다른 일반 컬럼에 종속되는 경우가 있다면,
별도 테이블로 분리하여 부모-자식 관계를 맺는다.
- 예) 우편번호와 기본 주소
<기존>
<제3정규화 과정>
"강의배정"의 "강의번호"는 "강의"의 FK가 PK가 된 것이다.
"강의배정"의 "강사번호"는 "강의"의 FK가 PK가 된 것이다.
즉, FK 가 PK로 지정되면 식별키로 지정된다.
* 비식별관계와 식별관계란 ?
* FK(외래키) = PK(주요키)인 관계를 식별 관계라고한다.
* 유니크(Unique) 컬럼 지정
- PK는 아니지만 PK처럼 중복되어서는 안되는 컬럼이다.
- 대체 키(alternate key) 컬럼이 유니크 컬럼이 된다.
- 즉 PK로 선정되지 않은 나머지 후보 키는 유니크 컬럼으로 지정하여 데이터가 중복되지 않도록 한다.
<기존>
<유니크 컬럼 지정>
* ull 허용 여부 지정
- 필수 입력 컬럼인지 선택 입력 컬럼인지 지정한다.
<기존>
<ull 허용>
* 인덱스 컬럼
- 데이터를 찾을 때 검색 조건으로 사용할 컬럼을 지정한다.
- 조회 컬럼으로 지정하면 그 컬럼의 값으로 색인표가 자동으로 생성되어
데이터를 찾는 속도가 빨라진다.
- 장점: select 속도가 빨라진다.
단점: insert,update,delete 할 때 마다 색인표를 갱신해야하므로 속도가 느리다.
<기존>
<인덱스 컬럼>
* 포함관계와 배타적 관계 식별
- 테이블의 공통 컬럼을 추출하여 수퍼 타입 테이블을 정의한다.
- 부모(수퍼타입 테이블)-자식(서비타입 테이블) 관계를 맺는다.
- DBMS의 문법으로는 포함 관계와 배타적 관계를 구분할 수 없다
<기존>
<포함관계와 배타적 관계>
