관계형 DB
전 글에서 DB가 무엇인지 배워보았다. 그럼 다음 스텝으로 실질적으로 요즘 사용하는 관계형(relational) DB와 relational data model이 무엇인지 알아보자.
relation in mathematics
relational data model에 대해 알아보기 전 relational에 대한 설명이 필요하다.
relation이란 수학에서 나온 개념이다.
이 개념을 설명하기 앞서 set에 대한 배경 지식이 필요하다.
set(집합)
- 서로 다른 elements를 가지는 collection
- 하나의 set에서 elements의 순서는 중요하지 않음
- ex) {1, 3, 11, 4, 7}
이제 본격적으로 수학에서의 relation에 대해 알아보자.
relation in mathematics
1
2
3
set A = {1, 2}
set B = {p, q, r}
위와 같은 2개의 set이 있다고 가정해보자.
그럼 위 두 set에서 나올 수 있는 모두 페어를 계산해보자.
1
{1, p}, {1, q}, {1, r}, {2, p}, {2, q}, {2, r}
위와 같은 페어들을 만들 수 있다.
이것을 수학에서는 다음과 같이 표현한다.
Cartesian product A * B = {(a, b) | a ∈ A and b ∈ B}
이와 같이 표현하는 것을 Cartesian product라고 부른다.
이 cartesian product는 수학에서 말하는 relation이란 밀접한 관련이 있다.
우리의 예제처럼 set A, set B와 같이 2개의 set을 가진 것을 binary relation이라 부른다.
이 binary relation은 A와 B (A * B)의 cartesian product의 부분집합을 의미한다.
이 그림은 binary relation이고 3개의 페어를 가지고 있다. 이 3개의 페어를 가지는 집합은 A * B의 cartesian prouduct의 부분집합이 되는 것이다.
만약 여기서 확장되어 set이 두개가 아니라 여러개가 있다면 어떻게 될까?
바뀐 것은 binary가 아닌 n-ary가 되고, set의 갯수 곱한 cartesian product의 부분 집합이 된다는 것이다.
또 그림을 자세히 보면 set 사이의 선들이 이어진 것을 볼 수 있다.
이런 선을 몇개의 elements들로 이루어진 리스트로 tuple이라고 부른다. 그림에서는 이런 tuple이 여러개 있기 때문에 n-tuple이라고 부른다.
정리
relation in mathematice은 다음과 같이 정리할 수 있다.
- subset of Cartesian product
- set of tuples
relational data model
relational data model에서는 우리가 알아봤던 relation의 set을 domain(도메인)이라고 칭한다.
relational data model에서의 domain은 set 안에 있는 elements, value라고도 불리는 값들의 집합을 의미한다.
student relation 예제를 통해 알아보자.
student relation을 표현하기 위해 domain을 정의해줘야한다. 다음과 같이 말이다.
- students_ids : 학번 집합, 7자리 integer
- human_names : 사람 이름 집합, 문자열
- university_grades : 대학교 학년 집합, {1, 2, 3, 4}
- major_names : 대학교 전공명 집합
- phone_numbers : 핸드폰 번호 집합
근데 우리가 위와 같이 domain을 정의하다보니 phone_numbers 이외에도 같은 핸드폰 번호지만 다른 용도로 쓸 비상연락망 번호가 필요하다고 느꼈다.
그러다보니 phone_numbers의 도메인이 student relation에서 두번 필요하게 되고, 각 도메인이 어떤 역할을 하는지 알기 어렵게 되었다.
이런 문제를 해결하기 위해 relational data model에서는 attribute라는 개념이 등장한다.
attribute는 각 도메인이 어떤 역할을 하는지 표시해주는 것, 이름을 붙여주는 것을 의미한다.
그럼 위에서 정의한 domain에 attribute를 지정해보자.
- students_ids = id
- human_names = name
- university_grades = grade
- major_names = major
- phone_numbers = phone_num (본인 번호)
- phone_numbers = emer_phone_num (비상 연락망 번호)
다음으로 student relation에는 tuple들이 존재한다.
relational data model에서 tuple들을 가장 잘 표현할 수 있는 것이 바로 table이다.
그래서 우리가 relation을 table이라고 많이 설명한다.
그림으로 보면 relational data model은 다음과 같은 구조를 가지고 있다.
정리
주요 개념을 살펴보면 다음과 같다.
relation 관련 개념정리
relation schema
- relation의 구조를 나타낸다.
- relation 이름과 attrubutes 리스트로 표기된다.
- ex) STUDENT(id, name, grade, major, phone_num, emmer_phone_num)
- attributes와 관련된 constraints도 포함된다.
degree of a relation
- relation schema에서 attributes의 수
- ex) STUDENT(id, name, grade, major, phone_num, emmer_phone_num) -> degree 6
relation (or relaton state)
relation은 table, 데이터 전체를 뜻하기도 하지만 relation state를 뜻하는 의미에서도 쓰인다.
relation state는 set of tuples를 뜻한다. 즉, 특정 시점에서의 tuples의 집합을 의미한다.
따라서 만약 관련 문서를 읽거나 api 문서를 찾아볼 때 추상적인 의미에서의 relation이냐 아니면 tuples의 집합을 의미하는지 잘 파악해야한다.
relational database
- relational data model에 기반하여 구조화된 database
- relational database는 여러 개의 relations로 구성된다
relational database schema
relational database는 여러 개의 relations으로 구성될 수 있기 때문에 이 schema에는 relation schemas set + integrity constraints set으로 구성된다.
relation의 특징들
- relation은 중복된 tuple을 가질 수 없다 (relation is set of tuples)
- set은 중복을 허용하지 않는 특성을 가지기 때문이다
- relation의 tuple을 식별하기 위해 attributu의 부분 집합을 key로 설정한다
- relation에서 tuple의 순서는 중요하지 않다 (정렬할 때 여러 방법으로 가능)
- 하나의 relation에서 attribute의 이름은 중복되면 안된다
- 하나의 tuple에서 attribute의 순서는 중요하지 않다
- attribute는
atomic (원자적인, 더 이상 나누어 질 수 없는)해야한다 (composite or multivalued attribute 허용 안됨)- 예를 들어 주소를 DB에 저장할 때 서울특별시 강남구 청담동을 저장했다고 하자. 위 주소는 사실 서울특별시, 강남구, 청담동과 같이 나눌 수 있기 때문에 atomic 하지 않다고 볼 수 있다. (composite attribute라고 부름)
- 또 다른 예로 전공(major)을 attribute로 설정했을 때, 만약 해당 학생이 복수 전공으로 디자인을 전공했다고 치면 그 학생의 전공은 디자인 + 컴공과 같을 것이다. 이 또한 atomic하지 않기 때문에 허용되지 않는다. (multivalued attribute라고 함)
NULL의 의미
- 값이 존재하지 않음
- 값이 존재하나 하직 그 값이 무엇인지 알지 못함
- 해당 사항과 관련이 없음
NULL은 DB를 설정할 때 최대한 쓰지 않는 것이 좋다. 그 이유는 예를 들어 알아보자.
만약 STUDENT relation에 토익 점수를 기입하는 attribute가 있다고 가정하자. 그때 NULL 값이 들어간다면 어떨까?
우리는 위에서 NULL이 가지는 의미인 3가지를 알아봤다. 그렇다면 어떤 학생의 토익 점수가 NULL 값일 때 가지는 의미 여러가지가 된다.
아직 시험을 안본 경우, 시험을 봤으나 아직 점수를 기입하지 않은 경우, 제출을 했는데 어떤 오류로 인해 데이터가 누락이 된 경우 등 NULL인 데이터에 다양한 의미가 부여된다.
이렇듯 NULL은 여러가지 의미로 표현이 될 수 있기 때문에 데이터가 명확히 무엇을 의미하는지 알기 힘들다. 이런 이유에서 NULL 사용을 지양하는 것이 좋다.
key의 종류
superkey
relation에서 tuples를 unique하게 식별할 수 있는 attributes set
ex) PLAYER(id, name, team_id, back_number, birth_data)의 슈퍼키는
{id, name, team_id, back_number, birth_data}, {id, name}, {name, team_id, back_number} …. etc
candidate key
어느 한 attribute라도 제거하면 unique하게 tuples를 식별할 수 있는 super key
key or minimal superkey
ex) PLAYER(id, name, team_id, back_number, birth_data)의 candidate key는
{id}, {team_id, back_number}
primary key
relation에서 tuples를 unique하게 식별하기 위한 선택된 candidate key
ex) PLAYER(id, name, team_id, back_number, birth_data)의 primary key는
{id} or {team_id, back_number}
보통 attribute 수가 적은 것을 primary key로 설정한다. 위의 예의 경우 {id}
unique key
primary key가 아닌 candidate keys
alternate key
ex) PLAYER(id, name, team_id, back_number, birth_data)의 unique key는
{team_id, back_number}
foreign key
다른 relation의 PK를 참조하는 attributes set
ex) PLAYER(id, name, team_id, back_number, birth_data)와 TEAM(id, name, manager)가 있을 때
foreign key는 PLAYER의 {team_id} (PLAYER의 {team_id}는 TEAM의 {id}를 참조)
constraints의 종류
constraints란
- relational database의 relations들이 언제나 항상 지켜줘야하는 제약 사항
implicit constraints
relational data model 자체가 가지는 constraints
relation은 중복되는 tuple을 가질 수 없음
relation 내에서는 같은 이름의 attribute를 가질 수 없다
schema-based constraints
- 주로 DDL을 통해 schema에 직접 명시할 수 있는 constraints
- explicit constraints라고도 함
schema-based constraints에는 다양한 종류가 있고 어떤 것들이 있는지 알아보자.
domain constraints
- attribute의 value는 해당 attribute의 domain에 속한 value여야 한다.
- ex) STUDENT의 grade는 {1, 2, 3, 4}로 설정했으면, 그 외의 값은 들어 올 수 없음
key constraints
- 서로 다른 tuples는 같은 value의 key를 가질 수 없다
NULL value constraint
- attribute가 NOT NULL로 명시됐다면 NULL을 값으로 가질 수 없다
entity integrity constraint
- primary key는 value에 NULL을 가질 수 없다
referential integrity constraint
- FK와 PK와 도메인이 같아야 하고 PK에 없는 values를 FK가 값으로 가질 수 없다.
- ex) PLAYER와 TEAM relation이 있다고 했을 때, PLAYER의 {team_id}는 TEAM의 {id}를 FK로 가졌다. 그때 PLAYER의 team_id에는 TEAM의 id 안에 존재하는 값이 들어가야한다는 의미이다.
이런 다양한 constraint는 데이터베이스가 일치된 형태로, 데이터의 일관성을 보장하기 위해서 사용된다.
만약 서비스를 구현하다 constraint를 위반했을 때 어떤 constraint를 위반했는지 알려주는 역할이다.
출처)