관계형 데이터베이스(relational database)

1. relational data model

relational data model

  relational data model을 이해하기 위해서는 먼저 relation에 대해서 이해할 필요가 있다. 그리고 사전 지식으로 set에 대한 개념도 필요하다.*set: 서로 다른 elements(중복허용X)를 가지는 collection이며, 하나의 set에서 elements의 순서는 중요하지 않다. e.g. {1, 3, 11, 17}

또한 수학에서의 relation에 대해 먼저 배경지식이 있으면 이해하기 쉽다. 결론만 말하면 수학에서의 relation은 Cartesian product의 부분집합을 의미하고 튜플의 집합을 뜻한다. (set of tuples) 이 배경지식을 바탕으로 수학에서의 relation을 relational data model에 적용해 보면 set 즉, 값들의 집합을 domain이라고 하고 더 유니크한 값으로 나눈것을 필드라고 한다. 결국에 relation의 튜플(레코드)을 테이블이라고 칭한다. -> relation == set of tuple

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM, 쉬운코드

• relation schema: relation 스키마란 relatoin의 구조를 나타낸다. 예를들어 relation의 이름과 attributes 리스트를 표기하면 STUDENT(id, name, grade, major, phone_num, emer_phone_num)과 같이 표현할 수 있고, 따로 표기는 하지 않지만 attributes와 관련된 constraints도 포함한다.
• degree of a relation: relation 스키마에서 attributes의 수를 나타낸다. 즉 위 사진에서는 총 6개임을 알 수 있다. 

또한 relation이 relation state를 뜻하는 경우도 있다. 즉 실제 튜플들의 집합을 relation이라 할 때도 있기 때문에 문서나 책을 읽을 때 문맥을 통해 파악하면 된다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM, 쉬운코드

2. relational database

  relational database는 위에서 설명했듯이 relational data model에 기반하여 구조화된 database라고 생각하면 된다. relational database는 여러 개의 relations로 구성된다.

3. relation의 특징들

  먼저 relation의 특징들에 대해서 알아보면, relation은 중복된 tuple을 가질 수 없다. 왜냐하면 relation is set of tuples

출처:https://www.youtube.com/watch?v=gjcbqZjlXjM, 쉬운코드

그리고 relation의 tuple을 식별하기 위해서 attribute의 부분 집합을 key로 설정한다.

출처:https://www.youtube.com/watch?v=gjcbqZjlXjM, 쉬운코드

또한, relation에서 tuple의 순서는 중요하지 않다.

출처:https://www.youtube.com/watch?v=gjcbqZjlXjM, 쉬운코드

하나의 relation에서 attribute의 이름은 중복되면 안되고 attribute의 순서역시 중요하지 않다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

attribute는 atomic 즉 더 이상 나눠질 수 없는 형태로 해야한다. 즉 composite or multivalued attribute 허용안된다. ❗️즉, 아래 사진에서 address에서 서울특별시, 강남구, 청담동을 모두 나눠줘야지 함께 사용하면 안된다. major에서도 컴공과 디자인을 나눠줘야한다. 

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

• NULL의 의미: NULL란 저장 공간은 주어졌는데, 값이 할당되지 않은 상태를 의미한다. 즉 값이 존재하지 않는다. 해당 사항과 관련 없다 아직 업데이트 되지 않았다는 뜻이다. 종종 중의적인 의미를 갖기 때문에 자주 사용하지 않는 것이 좋다.

4. Key

superkey

수퍼 키는 relation에서 tuples를 unique하게 식별할 수 있는 attributes set을 의미한다. superkey는 유니크한 식별을 만족한다면 여러가지가 될 수 있다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

candidate key

어느 한 attribute 라도 제거하면 unique하게 튜플들을 식별할 수 없는 superkey -> key or minimal superkey

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

primary key

relation에서 tuples를 유니크하게 식별하기 위해 선택된 candidate key를 의미한다. 그리고 Primary Key는 한 테이블(Table)의 각 로우(Row)를 유일하게 식별해주는 컬럼(Column)으로, 각 테이블마다 Primary Key가 존재해야 하며, NULL 값을 허용하지 않고, 각 로우(Row)마다 유일한 값이어야 한다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

위 예시에서 id를 갖고 튜플들을 식별하고자 한다면 id가 프라이머리 키가 되는것이고 그게 아니라 팀 아이디와 등 번호로 튜플들을 식별하고자 한다면 이 두 개가 프라이머리 키가 된다!

unique key

유니크 키는 primary key가 아닌 candidate keys를 의미한다 즉, alternative key! {id}를 제외하고

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

foreign key

다른 relation의 PK(Primary Key)를 참조하는 attributes set 을의미한다. 아래 예시에서 PLAYER relation의 team_id는 TEAM relation의 프라이머키인 id를 참조하기 때문에 forein key라고 한다. 즉 Foreign Key는 한 테이블의 필드(Attribute) 중 다른 테이블의 행(Row)을 식별할 수 있는 키

constraints

relational database의 relation들이 언제나 항상 지켜줘야하는 제약사항을 뜻한다. 예들들어, implicit constraints를 살펴보면, relational data model 자체가 가지는 constraints는 relation은 중복되는 튜플(레코드)를 가질 수 없고 relation 내에서는 같은 이름의 attribute(필드)를 가질 수 없다.

schema-based constraints

explicit constraints라고도 하며, 주로 DDL을 통해 schema에 직접 명시할 수 있는 constraints를 의미한다. 여기에는 여러 종류가있다.

• domain constraints: 필드의 value는 해당 필드의 domain에 속한 값이어야한다. 예를들어, 학년에는 보통 1~6학년이지 100학년은 없기 때문에 아래와 같이 작성하면 안된다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

• key constraints: 서로 다른 튜플은 같은 값의 key를 가질 수 없다. 아래와 같인 홍진호와 손흥민은 서로 다른 튜플인데 키값이 같기 때문에 제약사항을 지키지 못한 예이다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

• NULL value constraint: 필드가 NOT NULL로 명시됐다면 NULL을 값으로 가질 수 없다. 아래와 같이 최민정 선수가 null 값을 갖고 있기 때문에 제약사항을 어긴것이다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

• entity integrity constraint: primary key는 value에 null을 가질 수 없다. 왜냐하면 프라이머리 키는 튜플을 유니크하게 만들기 위함인데 값이 null이면 더 이상 튜플을 유니크하게 식별할 수 없다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

• referential integrity constraint: FK(Foreign Key)와 PK는 도메인이 같아야하고 PK에 없는 값들을 FK가 값으로 가질 수 없다. 아래는 TEAM relaion의 프라이머리 키인 id에 없는 값인 team_023을 FK인 PLAYER relation의 team_id가 가지고 있기 때문에 제약사항을 어긴것이다.

출처: https://www.youtube.com/watch?v=gjcbqZjlXjM

더 나은 이해를 돕기 위해 key 개념에 대해서 추가로 공부해 보겠습니다.

Superkey, Candidate key, Primary key,  Foreign key

출처: https://yusang.tistory.com/98

위와 같은 테이블이 있다고 해볼게요!

출처: https://yusang.tistory.com/98

위 사진처럼 테이블에 있는 각각의 튜플들을 구분할 수 있는 K를 Super key라고 합니다. 즉, {ID} , {ID, name} 위 값들을 통해 테이블에서 저 값에 해당하는 특정한 튜플이 무엇인지 알 수 있기 때문에 Super key라고 할 수 있겠죠. 이때, {name} 같은 경우는 Super key가 아닙니다. {name}은 동명이인이 있을 수 있기 때문입니다. 그래서 name 단독으로는 수퍼 키가 될 수 없고, ID와 함께 묶여있을 때 수퍼키가 될 수 있습니다.

출처: https://yusang.tistory.com/98

Super key가 가져야 되는 최소한의 값만 가진 것을 Candidate key라고 합니다.

Candidate key는 여러 개 있을 수 있습니다.

{ID} - Candidate key라고 할 수 있습니다. {ID, name} - 각 튜플들을 식별하는데 불필요한 name이 있기 때문에 Candidate key가 아닙니다.

출처: https://yusang.tistory.com/98

Candidate key 중 하나를 선택하여 Primary key라고 부르게 됩니다.  Foreign key는 다른 테이블에 존재하는 column의 값이어야 합니다.

예를 들면 강사 테이블에서 학과 column에 학과 이름을 저장할 때 아무 이름이나 저장해서는 안되고

DB에 학과 테이블에 존재하는 학과 중 하나를 값으로 사용해야 한다는 말입니다.

 

이번 시간에는 relational data model과 relational database에 대해 알아보았습니다. 감사합니다.