[데이터베이스] Relational Database

📌목차

➤ Relational database 개념

➤ Relational database 스키마 기반 제약 조건

➤ Domain constraint

➤ NULL constraint

➤ Key constraint

➤ Entity integrity constraint

➤ Referentional integrity constraint

 

Relational database

Relational database(관계형 데이터베이스)는 데이터들 사이에 정의된 관계가 있는 데이터베이스를 의미한다. Relational database에 대해 이해하기 위해 relation에 대해 먼저 알아보자.

📝 Relation(Table)

🔍개체를 표현하기 위한 데이터 구조

🔍2차원 테이블로 표현

▶행(row, tuple): 개체를 표현. 관련된 데이터 값들의 모임.

▶열(column, attribute): 각 행의 값들의 의미를 해석하는 데 사용.

🔍Relation은 tuple들의 집합

 

간단한 예제를 하나 확인해보자.

Movie라는 relation(table)은 2차원 테이블 형태로 구성되어 있으며, 각 행은 객체로써 tuple이라고 부른다. 이 tuple들의 집합이 해당 relation에 대한 relation status(relation extension)이다. 각 열은 해당 열에 대한 값들의 의미를 뜻하며 attribute라고 부른다. 이 attribute들의 집합이 해당 relation에 대한 relation schema(relation intension)이다. 위 relation에서 relation schema는 "Movie(movieId, title, genre, length, rating)"으로 표기한다.

 

 

Relational database 스키마 기반 제약 조건

Schema는 stored database의 structure + constraints로 이루어져있다. 이전 목차에서 relational database의 structure에 대해 알아보았다면, 이번 목차에서는 constraint에 대해 알아볼 예정이다. Constraint는 relational database의 특정 attribute에 값이나 타입 등의 제한을 두거나 relation 사이에 지켜져야 하는 규칙 등을 의미한다. 하나하나 알아보도록 한자.

📝 Relational database의 스키마 기반 제약 조건들

🔍도메인 제약 조건(Domain constraints)

🔍널 제약 조건(Null constraints)

🔍키 제약 조건(Key constraints)

🔍엔티티 무결성 제약 조건(Entity Integrity Constraints)

🔍참조 무결성 제약 조건(Referential Integrity Constraints)

 

 

Domain constraints

Domain constraints는 각각의 tuple내에서 각각의 attribute A에 대하여 A의 값이 A의 도메인에 속하는 원자값이어야 함을 의미한다. 말이 어렵지만 예시를 들어 생각해보자.

 

Relation Avitivity에 'weather'이라는 attribute가 있다고 가정하자. 'weather' 는 'sunny, rainy, ...' 등의 날씨와 관련된 문자열만을 도메인으로 갖는다. 이러한 경우, 그 어떤 tuple이든 'weather'이라는 attribute에 대해서는 위에서 언급한 'sunny, rainy ...' 등의 날씨와 관련한 문자열 집합의 원소를 가져야 한다는 뜻이다. 'weather'이라는 attribute에 대해 뜬금없이 'football'이라는 값을 가지는 건 허용하지 않는다.

 

아래는 SQL로 domain constraints을 명시한 예제이다.

create table Movie( 
	movieId varchar(10) primary key,
	title varchar(100) unique,
	genre varchar(32),
	rating varchar(5), 
    	check (rating in(‘G’, ‘PG’, ‘PG-13’, ‘R’, ‘NC-17’)
    …
)

create table Rental( 
	accountId int,
	videoId varchar(10),
	dateRented datetime,
	dateDue datetime,
	…
	check (dateRented <= dateDue)
 )

Relation Movie의 'rating'은 시청 등급이라는 뜻이며, 이에 대한 명확한 표준 등급이 있으므로 해당 집합을 명시해주었다. Relation Rental의 'dateRented'는 대출 날짜를 의미하며 'dateDue'는 반납 날짜를 의미한다. 반납 날짜는 대출 날짜 뒤의 날이므로 이에 대한 domain constraints를 명시해주었다.

 

 

Null constraints

Attribute는 그 의미에 따라 Null값이 필요할 수도, 필요하지 않을 수도 있다. 아래 코드를 예제로 생각해보자.

create table VideoTape (
	videoId varchar(10) primary key,
	movieId varchar(10) not null default ‘000-00-000’
	references Movie,
	storeId int references Store 
)

Relation VideoTape의 'movieId'는 절대로 Null 값이 될 수 없다. VideoTape의 'movieId'가 relation Movie의 'movieId'를 참조하고 있기 때문이다. 또한 상식적으로 현실세계에서 비디오테이프에 저장된 영화에 대해 고유 식별 번호를 정의하지 않는 것도 말이 안된다.

 

Key constraints

Key constraints는 relation에서 특정 attribute에 대해 각 tuple을 고유하게 식별해야 함을 의미한다. 즉, key로 지정된 attribute에는 중복된 값도 존재할 수 없다. Super key는 1개 이상의 attribute를 집합으로 했을 때 유일성을 만족하는 attribute 집합이다. 예를 들어 생각해보자.

 

Relation R에 대해 'SSN'이라는 key가 있고, 'name', 'age'라는 attribute가 있다고 가정하자. 'SSN'은 그 자체로 각 tuple을 구별할 수 있는 유일성을 지니고 있다. 따라서 'SSN'은 key인 동시에 super key이다.

 

{'SSN', 'name'} 또한 각 tuple을 구별할 수 있는 유일성을 지니고 있다. 따라서 super key에 해당한다.

{'SSN', 'age'}와 {'SSN', 'age', 'name'} 또한 super key에 해당한다.

 

만일 relation schema가 하나 이상의 key를 가질 경우, 각 키를 'candidate key'라고 한다. 그리고 candidate key 중 하나를 'primary key'로 지정한다. Primary key를 지정하면, 이 primary key로 각 tuple들을 식별한다. Primary key이외의 다른 candidate key는 'unique key'라고 부른다. 이를 정리하면 아래와 같다.

📝 Key

🔍Key

▶각 tuple을 고유하게 식별할 수 있는 attribute

🔍Super key

▶각 tuple을 고유하게 식별할 수 있는 attribute 집합

🔍Candidate key

▶해당 relation schema가 하나 이상의 key를 가질 때, 각 key = candidate key

🔍Primary key

▶Candidate key 중 개발자가 지정한 하나의 key로, 해당 key로 각 tuple을 식별하게 됨

🔍Unique key

▶Primary key를 제외한 다른 Candidate key

 

 

Entity Integrity Constraints

EIC(Entity Integrity Constraints)는 어떠한 primary key 값도 Null 값이 될 수 없음을 의미한다. Primary key로 각 tuple을 식별하므로 primary key 값이 Null이 되면 튜플을 식별할 수 없기 때문이다.

 

 

Reference Integrity Constraints

RIC(Reference Integrity Constraints)를 이해하기 위해선 foreign key에 대해 먼저 알아야 한다. Foreign key의 조건은 아래와 같다.

📝 Foreign key

Rleation schema R1의 어떤 attribute 집합 FK가 아래 규칙을 만족하면, FK는 relation R2를 참조하는 R1의 foreign key이다.( R1 : 참조한 relation, R2 : 참조된 relation )

🔍FK의 attribute는 R2의 primary key, PK의 attribute와 동일한 domain을 가진다.

🔍현재 상태 R1의 한 tuple t1의 FK값은 현재 상태 R2의 어떤 tuple t2내의 PK값과 일치하거나 Null값을 가진다.

 

아래는 예제이다.

create table VideoTape (
	videoId varchar(10) primary key,
	movieId varchar(10) not null default ‘000-00-000’
	references Movie,
	storeId int references Store 
)

create table Store (
	storeId int(10) primary key,
    	street varchar(20) not null,
    	city varchar(20) not null,
    	manager varchar(12) not null,
)

코드를 보면, VideoTape의 'storeId'가 Store의 primary key인 'storeId'를 참조하는 것을 확인할 수 있다.

 

이를 Schema 다이어그램으로 표시하면 다음과 같다.

밑줄이 쳐진 attribute는 primary key를 의미한다.

 

만약 RIC가 위반된 경우에는 참조하는 혹은 참조되는 relation의 각 attribute의 값을 확인해보자.