5주차. Relational Data Model

1. 개요

1) 관련 용어

Real World에서 Row, Column, Table이라고 부르는 요소를, Relational Data Model에서는 Tuple, Attribute, Relation이라고 바꾸어 부른다. 즉, Attribute로 구성된 Tuple의 집합으로 Relation을 표현하고, 이러한 Relation들이 모여 Database를 이루는 것이다. ER 모델링 이후에 Relational Model로 변환되며, 이 때 attribute의 수를 degree, tuple의 수를 cardinality라고 한다. 참고로 Relation은 대문자로, Attribute는 Camel Case로 표기하는 것이 관례이다.

Relation은 Relation Schema를 따라 구성되며, 이 때
Relation Schema에는 attribute, data type, constraints, primary key, foreign key, default value 등이 포함될 수 있다.

2) Relation의 특성

① Tuple randomness(무순서성)

• Relation은 tuple의 집합이므로, 집합에서 원소의 순서가 무의미한 것처럼 tuple의 순서도 의미가 없다.

② Attribute randomness

• Attribute의 순서도 마찬가지로 의미가 없다.

③ Attribute의 원자성

• 각 tuple이 지닌 attribute는 더 이상 나눌 수 없는 atomic value여야 한다.
• 즉, 다치 속성이나 복합 속성을 허용하지 않는다. (다치 속성이나 복합 속성은 별도의 relation으로 표현해야 한다.)
• null은 atomic value로 취급되므로, 값을 알 수 없거나 해당되는 값이 없다면, null이라는 특수 값을 사용할 수 있다.

2. 제약조건

데이터 모델의 스키마에서 DDL로 표현되는 제약 조건을 스키마 기반 제약조건이라 부른다. 이 제약조건은 모든 relation 인스턴스들이 반드시 만족해야 한다. 이러한 이유로 Relational Database의 스키마를 S + IC(Schema + Integrity Constraints) 구조라고 말하기도 한다.

※ Relational Database Schema와 Relation Schema
두 용어가 비슷하게 생기긴 했지만, 실상은 완전히 다른 개념이다. 말 그대로, 데이터베이스와 테이블의 차이이다. 즉, Relational Database Schema는 전체 데이터베이스의 설계 및 구조를 나타내는 것이며, Relation Schema는 개별 테이블의 설계와 구조를 나타내는 것이다.

1) Domain Constraints

• 각 attribute는 해당하는 data type의 도메인 내의 값이어야 한다.
• 즉, VARCHAR형의 Name 변수에 Integer를 할당할 수 없다.

2) Key Constraints

① relation은 집합이므로, 중복을 허용하지 않는다.

• 각 tuple을 유일하게 식별할 수 있는 attribute set이 필요하다.
• 우리는 이 attribute set을 key라고 한다.

② key의 종류

• candidate key: 유일성과 최소성을 만족하는 키
• super key: 유일성은 만족하지만, 최소성을 만족하지 않는 키
• primary key
  • candidate key 중에서 DB 설계자가 지정한 하나의 key
  • 두 개 이상의 속성이 최소성을 만족하면, 복합키가 기본 키가 될 수도 있다.
  • 반드시 유효한(non-null) 값이어야 한다.
• alternate key: 후보 키 중에서 기본 키를 제외한 나머지 후보 키
  

3) Null Constraints

Attribute는 null을 허용하거나 허용하지 않을 수 있다. 만약, null이 허용되지 않는 경우 attribute는 null 값을 가질 수 없다. 아래와 같은 DDL이 있다고 가정해보자.

CREATE TABLE DEPARTMENT
	(DNAME         VARCHAR(15)   NOT NULL,
     DNUMBER       INT,           
     MGRSSN        CHAR(9)       NOT NULL,
     MGRSTARTDATE  DATE,
     PRIMARY KEY(DNUMBER),
     UNIQUE(DNAME)
     FOREIGN KEY(MGRSSN) REFERENCES EMPLOYEE(SSN));

DNAME(부서명) 필드는 NOT NULL로 제한된다. 이 때 DNUMBER는 pk이므로, NOT NULL을 명시하지 않아도 NOT NULL로 제한되며, NULL에 대한 조건이 명시되어 있지 않은 MGRSTARTDATE는 기본 값인 NULL(nullable)이 적용된다.

참고로 Null 허용 여부는 해당 attribute가 mandatory인지, optional인지로 결정할 수 있다.

4) Entity Integrity Constraints

• 삽입: pk가 중복되면 삽입할 수 없다.
• 수정: pk를 null 또는 이미 존재하는 값으로 수정할 수 없다.
• 단, 삭제에 대해서는 별도의 제약이 존재하지 않으며, 즉시 수행된다.

5) Referential Integrity Constraints

참조 무결성 제약조건은 Relation 생성과 Tuple 추가에 순서가 필요함을 의미한다.

① 개념

• 한 relation에 있는 tuple이 다른 relation에 있는 tuple을 참조하려면, 반드시 참조되는 tuple이 그 relation 내에 존재해야 한다.
• 하나의 relation에서 다른 relation의 pk를 참조하는 경우 두 relation은 참조 무결성 제약조건을 갖는다고 한다.
• 이 때 참조되는 pk를 fk라 하며, fk는 얼마든지 null일 수 있다.
• 다른 제약조건들과 달리 참조 무결성은 두 relation에 적용되는 조건이다.

② 활용 예시

• 다른 필드를 전혀 참조하지 않는 University 테이블을 가장 먼저 생성한 후 Tuple을 삽입
  → 정상적으로 진행된다.
• UnivName 필드를 참조해야 하는 Student 테이블을 가장 먼저 생성
  → 참조할 테이블이 존재하지 않아 생성되지 않는다.
• University 테이블은 존재하나 아무런 Tuple이 없을 때, Student 테이블에 Tuple을 삽입
  → 참조되는 테이블에 외래키 값이 존재하지 않으므로 삽입되지 않는다.
• 소속된 Student가 있는 University 테이블의 Tuple을 삭제
  → 이 Tuple을 참조하고 있는 값이 있어 삭제되지 않는다.
• 어떤 University에 소속된 Student 테이블의 Tuple을 삭제
  → 정상적으로 진행된다.