3. 관계형 DB의 데이터 모델 및 제약

관계형 데이터베이스(Relational Database)란

데이터를 테이블 형태로 저장한다.

각 행은 서로를 구분해주는 식별자를 가지고 있다.

각 항목은 행(row)에 저장되고, 항목의 속성은 열(column)으로 구분된다.

여기서 행(row)은 tuple로 불리기도 하고, 열(column)은 attribute라고 불리기도 한다.

여제부터 행은 tuple로, 열은 attribute라고 한다.

 

차수(Relation)

attribute의 개수는 해당 Relation의 차수를 결정

Ex) 다음 테이블은 4차 Relation을 가짐

(Dname, Dnumber, Mgr_ssn, Mgr_start_date 총 4개)

Department 테이블

 

Relation 스키마

테이블을 정의해주는 부분이라 보면 된다.

R(A1, A2, A3, ... ,An)

A : R에서 도메인 D가 적용된 이름 (그냥 Attribute이름이다.)

D는 D : domain of A = dom(A)로도 표현

위의 Deparment 테이블을 Relation schema 로 표현하면

Department(Dname, Dnumber, Mgr_ssn, Mgr_start_date) 형식이 된다.

 

Relation State

R구조를 갖는 Relation의 state는 다음과 같이 표시한다.

state는 소문자를 쓰고, 스키마는 대문자를 쓴다.

r(R) , rti : r= {t1, t2, ... , tm}

튜플들이 모여있는 집합이 Relation의 인스턴스이다.

각각의 튜플들은 attribute 값들의 순서 리스트이다.

t = <v1, v2, ... , vn>

t[Ai] = t.Ai = vi 는 dom(Ai)의 부분집합이거나, null이다.

=> 이말이 무슨 말이냐면, 위의 Department 테이블에서

각각의 부서 정보들(튜플) 보여주는 순서는 다를 수 있어도,

attribute 들Dname, Dnumber, Mgr_ssn, Mgr_start_date은 순서가 바뀌지 않는다.

 

 

도메인(Domain)

attribute의 데이터 타입을 정의

Ex) Dnumber: an integer 1 and 10 : Dnumber attribute는 1에서 10까지 값만 가질 수 있다.

도메인 이름은 속성 이름과 같을 수 있고,

여러 attribute이 하나의 도메인을 쓸 수 있다.

 

Cartesian product

Relation R이 주어진다면, R(A1, A2, ... An)

r(R)은 각각의 Attribute들의 합집합의 부분집합이다.

Ex)

S1 = { 0, 1}, S2 = { a, b, c } 일 때,

S1 * S2 = <0, a>, <0, b>, <0, c>, <1, a>, <1, b>, <1, c>

r(R) = <0, a>, <1, b>

즉, r(R)은 S1*S2의 부분집합이다.

 

Relations의 특징

튜플끼리는 집합은 고려되지 않는다. (동일한 테이블 연산도 튜플 순서가 다르게 나옴)

attribute간의 순서도 의미가 없다.

-> 등록된 이름 순으로만 보여줌

 

Relation 스키마 R {A1, A2, ... , An} 이 있을 때,

튜플은 <attribute, value> 쌍으로 이루어진 집합이다.

모든 값들은 반드시 원자적이어야 한다.(성공 아니면 실패만.)

null 값도 값이다.

-> 1NF 정규형 만족시켜야 함

 

제약 조건

스키마 기반 제약

1. 키 제약

2. null에 대한 제약

3. 개체 무결성

4. 참조 무결성

도메인 제약

1. 각각의 attribute들은 원자값을 가져야 함

2. 데이터 타입

3. 변수의 범위

4. 데이터 타입 열거 (ex 월~일로할지, 일~월로 할지)

 

키 제약

슈퍼키

SK라고도 하며, 튜플마다 이들의 슈퍼키 값을 다르다.

슈퍼키끼리 조합해 새로운 슈퍼키를 만들 수 있다.

유일성(unique)

-> 중복되는 attribute를 포함해도 조회를 하면, 결국 하나의 튜플만 남게 된다.

 

최소성(minimal)

슈퍼키는 유일성은 만족하지만, 최소성은 만족하지 않는다.

즉, 최소한의 attribute로만 구성을 해야 최소성을 만족한다.

Ex) 다음 department 테이블에서 슈퍼키를 {Dname, Dnumber} 로 했을 때,

Dname에 중복값이 발생하더라도, 2차에서 고유한 값을 가지는 Dnumber가 걸러준다.

하지만, Dname은 없어도 상관이 없기 때문에 저 슈퍼키는 최소성을 만족하지 않는다.

 

그럼 Dnumber로만 슈퍼키를 잡으면 최소성과 유일성을 만족하고, 이걸 키(Key)라고 부른다.

 

후보키

최소성과 유일성을 만족하는 키들은 후보키라고 불린다.

이들 중에서 하나의 키만 relation을 대표할 수 있는 키가 되는데

이것이 바로 기본키이다.(Primary Key, PK)

기본키는 가능한 적게 잡는게 좋다.

여기서 기본키가 못된 후보키들을 대체키라고 한다.

 

정리하면 이런식이다.

 

 

복합키(Composite Key)

만약, 임의의 테이블이 다음 state를 가질 때

과목마다 여러 학생이 수강할 수 있다.

하지만, 학번이나 과목번호 단독으로는 각 튜플을 고유하게 식별 할 수 없다.

이렇게 되면 2NF 정규화를 위반하게 된다. (부분적 종속이 없어야함)

학번	과목번호	학점
2014	AA	A
2015	BB	B
2016	CC	C
2016	AA	D

 

외래 키

 

개체 무결성

기본 키(Primary Key)는 null 값을 가질 수 없다.

참조 무결성

두 relation간에 관계가 있을 때 FK가 가리키는 테이블의 PK는 서로 같아야 한다.

Ex) 테이블 R1 과 R2가 있을 때 R1이 R2를 참조한다고 하면

R1을 referencing relation

R2을 referenced relation 이라 한다.

즉, R2의 PK를 R1이 FK로 가지고 있단 것이고,

R1이 이 FK를가지고 R2로 접근하려면

R2의 PK와 R1의 FK가 맞아야 한다.

 

즉, R1[FK] = R2[PK]