[데이터베이스] 2장 - 관계형 데이터베이스 개념과 relation, primary key, foreign key, constraints

✅ relational 이 수학적으로 어떤 의미일까? 

: subset of Cartesian Product - 카테시안 곱(곱집합)의 부분집합이다. - CROSS JOIN

: set of tuples - 튜플의 집합이다.

 

✅ 그럼 데이터모델에서 relational 하다는 어떤 의미일까?

: student relation을 예를 들어 relational data model을 이해해보자!

 

step 1 )  도메인(domain) 정의하기

• students_ids : 학번 집합, 7자리 정수
• human_names : 사람 이름 집합, 문자열
• university_grades : 대학교 학년 집합. {1,2,3,4}
• major_names : 대학교에서 배우는 전공 이름 집합
• phone_numbers : 핸드폰 번호 집합 or 비상연락망
  
  

step 2 )  도메인(domain) 정의하기

• 학생의 연락처말고 비상연락망도 사용하려고 할 때, 동일한 도메인이 같은 relation 에서 중복되어 사용된다. 하지만, 목적(역할)이 다른 것이다. 
• 여기서 attribute(속성)라는 개념이 등장한다.
• 즉, 각각의 도메인들이 이 relation 에서 어떤 역할을 수행하는지 이름을 붙여주는 것이 attribute 이다.

• 이제 각각의 도메인에 해당하는 속성이 정해졌다. 
• phone_numbers 라는 도메인에 대해서 '학생의 전화번호를 나타내는 역할'로서 'phone_num' 이라는 attribute 가 부여됐고,
• '학생의 비상연락망을 나타내는 역할'로서 'emer_phone_num' 이 부여가 된 것이다.
  
  

이제, student relaionship에서 도메인이들이 다 정해졌고, 도메인은 어떤 값들로 이루어진 집합이니까 각 도메인마다 값들이 있을 것이다. 

각 도메인마다 값들을 연결시킨 데이터의 집합들이 하나의 튜플이고 튜플들의 모음이 바로 테이블이 되는 것이다.

그래서 relation을 우린 table 이라고 말하는 것이다.

✅  relational data model

주요 개념	설명
도메인(domain)	set of atomic values (*atomic : 원자성 = 더 이상 나눠질 수 없는)
도메인 이름(domain name)	domain 이름
속성(attribute)	domain 이 relation 에서 맡은 역할 이름
tuple	각 attribute의 값으로 이루어진 리스트, 일부 값은 NULL 일 수 있다.
relation	set of tuples (=테이블의 일부) 혹은 table 전체
relation name	relation의 이름

✅  relational schema

• relation 의 구조를 나타낸다.
• relation 이름과 attributes 리스트로 표기된다.

'STUDENT' 라는 이름의 릴레이션이 있을 때, 아래와 같이 표현할 수 있다.

→ STUDENT(id, name, grade, major, phone_num, emer_phone_num) 

• 여기서 attributes 와 관련된 constraints(제약조건)도 릴레이션 스키마에 포함한다.

※ 제약조건 : varchar, integer ... 등등의 속성마다의 제약조건

✅  degree of a relation

• relation schema 에서 attribute의 수 = (속성의 수)
• STUDENT(id, name, grade, major, phone_num, emer_phone_num) → degree(차수)가 6 이다.

✅ 그럼 relational  database 가 뭐다?

• relational data model 에 기반하여 구조화된 데이터베이스
• relational database 는 여러 개의 relations 로 구성된다! (= 데이터베이스에는 여러가지 테이블이 존재한다~)

---

✅  relation 의 특징들

1. relation은 중복된 tuple을 가질 수 없다. (relation is set of tuples)

2. relation 의 tuple을 식별하기 위해 attribute 의 부분집합을 Key 로 설정한다.

3. relation에서 tuple의 순서는 중요하지 않다.

4. 하나의 relation 에서 attribute의 이름은 중복되면 안된다. (속성이름 중복 x)

5. 하나의 tuple에서 attribute의 순서는 중요하지 않다. 

6. attribute는 atomic 해야 한다. (composite or multivalued attribute 허용 x)

(ex. address 하나의 속성에 "서울특별시 강남구 청담동 "... 이 아니라 다 나눠서 속성값을 줘야 한다.)

---

✅  Null의 의미 

• 값이 존재하지 않는다.
• 값이 존재하나 아직 그 값이 무엇인지 알지 못한다.
• 해당 사항과 관련이 없다.

→ NULL 하나로써 중의적인 의미가 될 수 있기 때문에, null 사용을 지양하는게 좋다.

---

✅  superKey(슈퍼키)

• relation에서 tuples 를 unique 하게 식별할 수 있는 attributes set

예를 들어, PLAYER(id, name, team_id, back_number, birth_date)의 superkey는 {id, name, team_id, back_number, birth_date}, {id, name}, {name, team_id, back_number}, {id, back_number, birth_date}... 등등이 될 수 있다.

 

→ 즉, 테이블에서 고유하게 식별할 수 있는 속성집합들은 다 superKey 라고 할 수 있다.

 

✅  candidate Key(후보키)

• 어느 한 attribute 라도 제거하면, unique하게 tuples 를 식별할 수 없는 superKey
• (= key or minimal superKey)

예를 들어, PLAYER(id, name, team_id, back_number, birth_date)의 candidate Key 는 {id}, {team_id,back_number} 이다.

 

→ 즉, 테이블에서 각 행을 고유하게 식별할 수 있는 속성이나 속성의 조합을 candidate Key 라고 할 수 있다.

✅  Primary Key(기본키)

• relation에서 tuples 를 unique 하게 식별하기 위해 선택된 candidate Key

예를 들어, PLAYER(id, name, team_id, back_number, birth_date)의 primary Key 는 {id}, {team_id,back_number} 이다.

하지만, 보통 기본키는 안정성 이유로 복합키로 구성하지 않는다. 일반적으로 기본키로는 attributes 가 적은 것을 고른다. 

 

→ 즉, 해당 테이블의 각 행을 고유하게 식별할 수 있는 속성을 찾아야 한다. 기본키는 테이블의 모든 행을 유일하게 식별할 수 있어야 하며, NULL 값을 가질 수 없다. 보통 pk는 _(언더바)로 표시한다.

✅  Unique Key(고유키)

• primary Key 가 아닌 candidate Keys들
• (= alternate key, 대체키)

예를 들어, PLAYER(id, name, team_id, back_number, birth_date)의 primary Key 가 {id} 로 선택됐다면, 고유키는 {team_id,back_number} 라고 할 수 있다.

 

→ 즉, 테이블의 모든 행에 대해 중복되지 않는 값을 가지는 속성이나 속성의 조합이다. 고유키는 NULL 값을 포함할 수 있으며, 테이블에서 여러 개가 존재할 수 있다.

✅  Foreign Key(외래키)

• 다른 relation의 PK를 참조하는 attributes set

예를 들어, PLAYER(id, name, team_id, back_number, birth_date)에서 Foreign Key 는 {team_id} 일 가능성이 높다. 이는 다른 테이블에서 팀을 식별하는 기본키나 고유키에 해당할 수 있기 때문이다. 예를 들어, TEAM table 이 있고 그 테이블의 'id' 속성이 팀을 식별한다면, 'Player' 테이블의 'team_id'는 'TEAM' 테이블의 'id' 에 대한 외래키로 작용할 수 있다.

 

→ 즉, 한 테이블의 속성(또는 속성 조합)이 다른 테이블의 기본키나 고유키와 연결되어 있는 관계에 있는 key

✅  Constraints(제약조건)

: relational database 에서 relations 들이 언제나 항상 지켜줘야 하는 제약 사항

 

implicit constraints(암시적 제약조건)

• relational data model 자체가 가지는 제약조건
• relation은 중복되는 튜플을 가질 수 없다.
• relation 내에서는 같은 이름의 attribute를 가질 수 없다.

 

explicit constraints(schema-based constraints) : 주로 DDL 을 통해 schema 에 직접 명시할 수 있는 constraints

• domain 제약조건 - attribute의 value는 해당 attribute의 domain에 속한 value 여야 한다.
• key 제약조건 - 서로 다른 tuples 는 같은 value의 key 를 가질 수 없다.
• Null value 제약조건 - attributes 가 NOT NULL 로 명시됐다면, NULL 을 값으로 가질 수 없다.
• entity integrity 제약조건 - primary key 는 NULL 값을 가질 수 없다.
• referential integrity 제약조건 - FK 와 PK 와 도메인이 같아야 하고 FK는 다른 테이블의 PK 에 없는 values 를  값으로 가질 수 없다.

---

참고자료

- 유튜브 쉬운코드