[강의 정리] Relational Database, KEY, Constraints

 

출처 - 쉬운코드 Youtube

---

✅ 수학에서의 Relation?

 - 여러 개의 set의 원소들의 모든 가능한 조합으로 이루어진 새로운 set을 Cartesian product라고 한다.

 - 이 cartesian product의 부분집합을 또는 튜플들의 집합을 relation이라고 한다.

 

✅ 관계형 데이터 모델에서의 relation?

 - 여러 개의 도메인(set)의 값들로 만들 수 있는 조합들의 집합

 

✅ 관계형 데이터 모델 주요 개념 (용어 정리)

 - domain : Atomic한 값들의 집합

 - attribute : domain이 relation에서 맡은 역할 이름
 - tuple : 각 attribute의 값으로 이루어진 리스트 (일부 값은 NULL일 수 있다.)

 - relation : 튜플들의 집합

 - relation name : relation의 이름

 

 

✅ 예시 - Student relation

 🐥 Student domain 정의하기

    - student_ids : 7자리 integer

    - human_names : 문자열

    - university_grades : {1,2,3,4} 중 하나

    - major_names : 전공이름 집합

    - phone_numbers : 전화번호

 

 🐥 Relation 만들기

 - Relation을 만드려다보니, phone_numbers 도메인이 2개 필요할 것 같다. (1. 본인번호 저장 목적, 2. 비상연락망 저장 목적)

      --> 하나의 릴레이션 안에서 같은 도메인이 다른 목적(역할)을 가지고 2번 사용된다

      --> 이 도메인들의 역할을 정의해주기 위해서, 각 도메인에 속성(attribute)을 부여한다.

 

 - 그림에서 첫 번째 행은 domain 이름, 두 번째 행은 attribute 이름

 

 

 - 각 도메인의 값들로 이루어진 튜플로 Relation을 만들 수 있고, 이 릴레이션을 보기 좋게 테이블 형태로 나타낼 수 있다.

 

 - 릴레이션(테이블)의 각 행은 튜플, 각 열은 attribute 이다.

 

 

 

✅ Relation schema

 - Relation의 구조를 나타낸다.

 - Relation이름(attribute 리스트) 로 표기된다.

 - 예시: STUDENT(id, name, grade, major, phone_num, emer_phone_num)

 

 - Relation schema는 attribute뿐만아니라 attributes와 관련된 constraints도 포함한다.

 

 

✅ Degree of a relation

 - Relation schema에서 attributes의 개수

 - 예시: 위 릴레이션의 degree는 6

 

 

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

 - Relational data model에 기반하여 구조화된 데이터베이스

 - Relational database는 여러 개의 릴레이션으로 구성된다.

 

🐥 Relational database schema?

 - Relation schema들의 집합 + integrity constraints set

 

 

✅ Relation의 특징

 - 중복된 튜플을 가질 수 없다. (릴레이션은 정의부터 튜플들의 "집합"이기 때문)

 - 릴레이션에서 튜플의 순서와 attribute의 순서는 중요하지 않다. (집합이니까!)

 - 릴레이션의 튜플을 unique하게 식별하기 위해, attribute의 부분집합을 key로 설정한다.

 - 하나의 릴레이션에서 attribute의 이름은 중복될 수 없고, atomic해야한다.

 - Attribute가 atomic해야한다 => 하나의 attribute가 나눠질 수 있는 여러 정보를 담고 있는 composite(or multivalued) attribute가 되면 안 된다

 

✅ Null은 언제 사용되는가

 - 값이 존재하지 않을 때

 - 값이 존재하지만, 아직 그 값이 무엇인지 모를 때

 - 해당 사항과 관련 없을 때

 

 - Null은 중의적인 의미를 가질 수 있기 때문에 되도록 사용하지 않는 것이 좋다 .

 

 

✅ KEY

🔑 Super Key (슈퍼키)

 - 릴레이션에서 튜플을 unique하게 식별할 수 있는 attribute의 부분집합

 

🔑 Candidate Key (후보키)

 - 어느 한 attribute라도 제거하면 super key가 아니게 되는 super key

 - key 또는 minimal superkey라고 부르기도 한다.

 

🔑 Primary Key (기본키)

 - 릴레이션에서 튜플을 unique하게 식별하기 위해 선택된 candidate key

 - 보통 attribute 수가 가장 적은 키를 primary key로 선택한다. (편하니까!)

 

🔑 Unique Key 또는 Alternate Key (대체키)

 - Primary key가 아닌 candidate key

 

🔑 Foreign Key (외래키)

 - 다른 릴레이션의 Primary Key를 참조하는 attribute의 부분집합

 

 

 

✅ Constraints

 - Relational database의 릴레이션들이 언제나 항상 지켜줘야 하는 제약사항

 

🐥 Implicit Constraints

 - Relation data model 자체가 가지는 constraints

 - 예시 ) Relation은 중복되는 튜플을 가질 수 없다, 릴레이션 내에서는 같은 이름의 attribute를 가질 수 없다

 

🐥 Schema-based Constraints

 - Explicit constraints라고도 한다

 - 주로 DDL을 통해 스키마에 직접 명시할 수 있는 constraints

 - 종류

    - Domain constraints : Attribute의 value는 해당 attribute의 도메인에 속한 value여야 한다.

    - Key constraints : 서로 다른 튜플들은 같은 value의 key를 가질 수 없다.

    - Null value constraints : Attribute가 NOT NULL로 명시되었다면, value로 null을 가질 수 없다.

    - Entity integrity constraints : Primary key는 value로 null을 가질 수 없다.

    - Referential integrity constraints : FK와 PK의 도메인이 같아야 하고, FK는 value로 PK에 없는 value를 가질 수 없다.