[Database System] The Relational Data Model and Relational Database Constraints

이제 위에서 만든 ER 다이어그램을 테이블로 만들기 전에 Relational Data Model과 RDB가 가지고 있는 제약사항을 알아야 한다.

1. Relational Model Concepts

Relation에 대한 개념부터 짚고 넘어가자. Relation을 원래 table로 생각을 했지만 이해를 쉽게 하기 위해 table로 생각한 것이지 원래 Relation은 집합을 근본으로 한다. 집합을 근본으로 하는 만큼 정교한 수학을 기반으로 하기에 Relation 개념은 견고하다.

Relational Model Concepts은 Dr.E.F.Codd에 의해 집합을 근거로 고안된 수학적인 컨셉이다. 이 컨셉은 구현에 관해서는 전혀 신경쓰지 않고, 이 컨셉을 구현할 때 table을 이용해서 구현하게 된 것이다.

Informal 용어 정의

• relation은 table의 값들이다.
• relation은 행들의 집합, 즉 record(tuple)의 집합이다.
• record은 entity를 말하는데 relational model에서는 tuple이라 부른다.
• column header는 relational model에서 attribute name이라 부른다.

STUDENT가 집합이 된다.

중요한 건 Relation은 집합이고 STUDENT 집합의 학생 Benjamin entity(tuple, record)는 attributes(field)로 구성되어 있다는 것이다.

Key of a Relation

• unique하게 테이블의 row를 구별할 수 있으면 된다.
  • 위의 사진에서 SSN이 key가 된다.
• single key가 존재하지 않고 여러 attribute를 결합해야 key를 만들 수 있을 때 임의의 sequential 번호를 부여할 수 있다.
  • 이런 경우를 artificial key 혹은 surrogate key라 한다.

Formal 용어 정의

Schema

• Schema of a Relation:
  • R(A1, A2, … An)
  • R이 relation의 이름이다.
  • A1, A2, … An은 attribute이다.
• Example
  • CUSTOMER (Cust-id, Cust-name, Address, Phone#)
• 각 속성은 값의 범위인 domain을 가진다.
  • 예를 들어 Cust-id의 domain은 6자리 정수이다.

Tuple

• tuple은 순서가 있는 값의 집합이다.
  • entity, record, row와 같은 말이지만 Relational Modeld에서는 tuple이라 한다.
  • 순서가 있다는 말은 어떤 tuple은 name이 먼저오고, 어떤 tuple은 Cust-id가 먼저 오면 안된다.
  • <…>로 표시한다.
• tuple이 갖는 값은 attribute의 값인데, 그 값은 domain을 가진다.
• CUSTOMER relation의 row는 4개의 attribute를 가진다. 이를 a 4-tuple 이라 부른다.
  • 4-tuple은 tuple이 4개라는 것이 아니라 4개의 attribute를 갖는다는 것이다.
  • <63215, “John”, “101 Main St”, “9326-2000”>
• Relation은 tuple들의 집합이다.

Domain

• domain은 logical하게 정의할 수 있다.
  • 예를 들어 “USA_phone_numbers”는 10자리 정수로 제한할 수 있다.
• domain은 data-type 혹은 format 형태로 만들 수 있다.
  • 예를 들어 날짜를 yyyy-mm-dd와 같이 format을 제한할 수 있다.
• attribute name은 역할을 나타낸다.
  • 날짜 필드가 두 개 있으면 day1, day2 보다 invoice-date, payment-date가 더 좋다.

State

• relation state는 Cartesian product의 subset이다.
  • relation state r(R)은 다음과 같다.

이 state, R이 relation을 의미하고 dom(A)는 domain 즉 A가 가질 수 있는 값을 의미한다.

• dom(A)는 예를 들어, A가 10자리 정수라면 10자리 정수의 가능한 모든 경우의 수가 dom(A)가 된다.
• relation state는 subset이라는 말을 예를 들어서 이해해보자.r(R)은 (1, 1), (1, 2), (2, 1), (2, 2), (3, 1), (3, 2) 와 같다. cardinality는 그 개수가 되므로 각 domain의 개수를 다 곱하면 된다.
• dom(A)가 [1, 2, 3] dom(B)가 [1, 2]라면
• cardinality는 max가 된다. 즉, 현재 상태는 항상 cardinality 안에 속해있게 된다.A domain 개수가 2, B domain 개수가 3, C domain 개수가 4라면 cardinality는 234 = 24가 되고 현재 상태가 24개라면 가질 수 있는 subset을 다 가진 것이다. 이런 의미에서 cardinality가 max가 되는 것이다.
• cardinality 또한 예를 들어 생각해보자.
• r(R)은 R의 현재 상태(state = value = population)를 말한다.
  • **r(R)**은 순서가 없으므로 집합이다.
  • $t_i$ tuple은 순서가 존재하므로 집합이 아니다.

예를 들어 생각해보자.

• dom($A_1$) = {0, 1}
• dom($A_2$) = {a, b, c}
• dom($A_1$), dom($A_2$)의 Cartesian product
  • {<0,a>, <0,b> , <0,c>, <1,a>, <1,b>, <1,c>}
• relation state r(R) 은 dom($A_1$) X dom($A_2$)에 속해있다.
• r(R)을 {<0,a> , <0,b> , <1,c> } 이라 하자.
  • r은 현재 상태를 의미하고 population, extension과 같은 의미이다.
  • R은 three 2-tuples을 가진다.

용어 정리를 요약해보면 다음과 같다.

Characteristics of Relations

r(R)은 tuple의 집합이다.

• Relation 안에 있는 tuple은 Relation이 집합을 근거로 하기에 순서가 중요하지 않다.
• 예를 들어 A={a, b}, B={b, a}라면 둘은 같은 집합, 같은 Relation이다.

튜플의 attribute는 순서가 있어야 한다.

• t = <v1, v2, ..., vn> 형태의 tuple에 속해 있는 attribute는 순서가 있어야 한다.
• 그런데 만약 attribute의 이름과 값을 같이 적어준다면 순서가 필요하지 않다.
  • 예를 들어 t = { <name, “John”>, <SSN, 123456789> }

tuple의 attribute는 순서가 있어야 하지만, Relation의 tuple은 순서가 없어도 된다. 사진의 두 Relation은 tuple의 순서가 다르지만 같은 Relation이다.

Values in a tuple

• 모든 값은 atomic하다. 쪼개지지 않는다.
  • 모든 값이 atomic 하다는건 모델 자체의 제약 사항이 된다.
• 각 값은 domain에 속하는 값이어야 한다.
• null value는 많은 의미가 있다.
  1. unknown
  2. not available
  3. inapplicable
• tuple notation은 t = <$v_1, v_2, ..., v_n$>이렇게 표현한다.
  • $t[A_i]\ or \ t.A_i$ 이렇게 특정 속성만 표현할 수 있다.
• 일부 attribute만 가지고 있는 subtuple은 t[Au, Av, …, Aw]로 표현할 수 있다.

---

2. Relational Model Constraints and Relational Database Schemas

CONSTRAINTS

Reltional Data Model 뿐 아니라 전체 DBMS에는 크게 세 가지 제약사항이 존재한다.

1. Inherent or Implicit Constraints : 모델 자체가 가지고 있는 제약사항이다.
   • 예를 들어 relational model은 list 형태의 값을 가질 수 없다. 값들이 atomic 해야 한다는 뜻이다.
   • 모델을 선택할 때 이미 정해져 있다.
2. Schema-based or Explicit Constraints : 명시적으로 스키마를 디자인할 때 표기해둔 제약사항이다.
   • 예를 들어 ER model의 max cardinality ratio가 있다.
   • 이 제약사항은 테이블을 설계할 때 우리가 고민해야하는 부분이다.
3. Application based of semantic Constraints : 애플리케이션 도메인에서 요구하는 제약사항이다.
   • 예를 들어 데이터베이스 교과목 선수과목이 자료구조라는 제약사항은 애플리케이션에서 요구하는 것이다.
   • 애플리케이션마다 요구하는 제약사항이 다르고 우리가 고민할 수 없는 문제이다.

Relational Integrity Constraints (Relation의 무결성 제약)

• 특정 시간의 relation의 상태가 항상 유효해야 한다.
  • 상태가 유효하다는 말은 explicit 제약사항을 위반해서는 안된다는 말이다.
• explicit 제약사항은 보통 네 가지로 나뉜다.
  1. Key constraints
  2. Entity integrity constraints (개체 무결성 제약)
  3. Referential intergrity constraints (참조 무결성 제약)
  4. domain constraints

하나씩 알아보자.

Key constraints

• Superkey of R
  • Tuple을 unique하게 구별할 수 있는 Attribute 집합이다.
  • 즉, t1[SK] ≠ t2[SK] notation을 만족해야 한다.
  • Superkey 집합 전체를 가지고 구별하는 것이지, 집합의 subset으로 구별할 수 있다는 뜻이 아니다.
• Key of R
  • minimal superkey
  • minimal 하다는 뜻은 Key의 어떤 속성을 빼면 반드시 Key의 역할을 못하는 집합을 말한다.
• 모든 Key는 Superkey지만 역은 성립하지 않는다.
• key를 포함한 모든 속성의 집합은 superkey이다.
• minimal superkey 또한 key이다.
• relation이 몇 가지 candidate key를 가지고 있다면 그 중 하나의 키가 primary key가 된다.
  • candidate key는 key가 될 수 있는 집합이다.
  • primary key에는 underlined 된다. ER 다이어그램에서는 모든 key를 underline 했지만 스키마를 디자인 할 때는 primary key에만 underline 한다.
• Example : CAR relation schema
  • CAR(State, Reg#, SerialNo, Make, Model, Year)
  • We chose SerialNo as the primary key
• primary key는 각 tuple을 unique하게 구분할 수 있다.
• primary key는 다른 튜플에서 참조할 때 사용된다.
  • 다른 튜플에서 참조할 때 하나의 키를 참조하는게 더 좋으므로 primary는 candidate key 중 가장 작은걸 선택하는게 일반적으로 좋다.

Key, SuperKey, Primary Key, Candidate Key를 잘 구분하자.

 

Relational Database Schema

• Relational database 스키마는 relation 스키마(table)의 집합이 된다.
• Relatoinal database Schema S = {R1, R2, ..., Rn}로 표현할 수 있고 S는 무결성 제약사항을 만족해야 한다.
• R1, R2, …, Rn은 relation schema이다.

Company의 Relational Database Schema는 다음과 같다.

Relational Database State

• 어떤 특정 시점의 relation의 상태 집합 DB = {r1, r2, …, rm} 이 database state가 된다.
• database state(relation의 집합)는 모든 시점에서 valid 해야 한다. valid 하다는 말은 다음의 제약 사항을 만족하는 것을 말한다.
  • key, entity integrity, referential intergrity, domain
• Database state는 database snapshot, instance 라 한다.
• 제약 사항을 만족하지 못하는 상태를 invalid state라 한다.

Populated database state

• database에 record가 들어가 있는 상태이다.
• 데이터베이스가 바뀐다는 말은 relation이 바뀐다는 말이고, relation이 바뀐다는 말은 tuple이 바뀐다는 말이다. 데이터베이스가 바뀌게 되면 새로운 상태가 된다.
• 데이터베이스는 항상 valid 상태를 유지해야 한다.
• 데이터베이스가 변하는 basic operation은 다음과 같다.
  • INSERT a new tuple in a relation
  • DELETE an existing tuple from a relation
  • MODIFY an attribute of an existing tuple

Entity Integrity

• S의 relation schema R의 primary key attributes는 r(R)의 어떤 튜플에서도 null 값을 가져서는 안된다.
  • PK가 각 튜플을 구분하기 위해 사용하기 때문이다.
  • 만약 PK가 multi value라면 하나의 속성이라도 null이어선 안된다.
• PK 외에도 다른 attribute를 null 값을 가져선 안된다고 지정할 수 있다.

Referential Integrity

• 두 개의 relation이 참여하는 제약사항이다.
• A가 B를 참조하고 있는, A → B와 같은 상황이면 A가 referencing, B가 referenced relation이다.
• referencing relation R1의 tuple은 referenced relation R2의 PK를 참조하는 FK를 가진다.
  • R1의 t1 tuple이 R2의 t2 tuple을 참조하고 있다면, t1[FK] = t2[PK]이다.
• 사진으로 보면, 아래의 DEPARTMENT Relation이 EMPLOYEE Relation을 참조하고 있고, DEPARTMENT의 Mgr_ssn이 foreign key, EMPLOYEE의 Ssn primary key를 참조하고 있다.
• relational database schema에서는 directed arc로 나타난다.

referencing relation T1의 FK의 값은 다음과 같다.

1. 참조되는 Relation R2의 primary key의 state 중 하나여야 한다.
2. null이 될 수 있다.

FK가 null이 되는 경우에 FK는 R1의 PK가 되어서는 안된다.

Displaying a relational database schema and its constraints

• 각 relation 스키마는 attribute 이름의 행으로 나타난다.
• relation의 이름은 attribute 이름 위에 나타나야 한다.
• primary key는 밑줄을 그어야 한다.
  • DEPT_LOCATIONS를 보면 두 개의 key가 있는데, key가 두 개가 아니라 두 개의 조합이 key라는 것이다.
• FK는 directed arrow로 나타난다. 방향은 FK에서 referenced table 방향이다. 화살표의 끝은 참조하고 있는 primary key를 point 하고 있을 수 있다.

Other Types of Constraints

• Semantic Integrity Constraints
  • application의 의미적인 제약 사항이다.
  • 데이터베이스 시스템에서 표현할 수 있다면 표현하는게 좋다. 그만큼 어플리케이션이 가벼워지기 때문이다.
• 위와 같은 제약 조건을 표현하기 위해 제약조건 명세 언어를 사용할 수 있다.
  • CREATE TRIGGER, CREATE ASSERTTION이 대표적이다.
  • TRIGGER는 어떤 동작이 발생했을 때 TRIGGER를 취하라는 뜻이다. 특정 행이 삭제되었을 때 뭘 해라 그런것이다.
  • ASSERTTION은 어떤 문제가 발생했을 때 어떤 동작을 취하라는 뜻이다.
  • Key, 어떤 값에 Null 허용, Candidate Key, Foreign Key, Referential Integrity 등이다.

---

3. Update Operations, Transactions, and Dealing with Constraint Violations

Update Operation은 크게 다음과 같다.

• INSERT a tuple
• DELETE a tuple
• MODIFY a tuple

위와 같은 업데이트가 발생했을 때 Integrity 제약사항을 위반해서는 안된다. valid 상태가 되어야 한다는 것이다.

Update 연산은 그루핑해서 실행할 수 있고 이를 transaction이라 한다.

transaction은 atomic operation의 집합이다. all or nothing 이라고도 하는데, 하나라도 안되면 아예 실패(nothing)이고 혹은 전부 다 성공해야 하는 연산의 집합인 것이다.

update를 하게되면 update한 relation에 대해 다른 relation에 영향을 주게 할 수 있다. 예를 들어, 학과의 번호가 바뀌었다면 학생의 학과 번호도 바뀌어야 한다. 이를 propagate라 한다.

만약 operation이 integrity를 violation 한다면, 어떤 action을 취할 수 있을까?

1. 그 operation을 취소시킨다.
   • RESTRICT or REJECT option을 주면, 어떤 operation이 무결성을 침해했을 때 그 operation을 취소시킨다.
2. operation을 수행하고 사용자에게 위반했다고 알려준다.
3. 적절하게 Trigger를 수행해서 additional update를 시켜준다.
   • 예를 들어 지도 교수가 퇴직을 해서 어떤 학생의 지도 교수가 사라진다면 Triggering을 해서 default 값 혹은 null로 세팅해둘 수 있다. 물론 primary key의 일부라면 null로 세팅하면 안된다.
   • CASCADE option, SET NULL option을 사용하면 된다.
   • CASCADE option은 앞에서 말한 propagate와 유사하다.
4. user-specified error-correction routine을 실행한다.

1, 3번이 DBMS에서 주로 다루게 된다. 2, 4번은 어플리케이션에서 처리해야 할 일이다.

tuple을 INSERT 했을 때 어떤 제약사항을 위반할 수 있을까?

1. Domain constraint
   • 새로운 tuple의 속성이 domain을 만족하지 않을 수 있다.
2. Key constraint
   • Key는 구별이 되어야 하는데, 이미 존재하는 Key 값으로 tuple을 삽입하면 해당 제약사항을 위반할 수 있다.
3. Referential integrity
   • 삽입된 tuple의 FK가 referenced relation의 존재하지 않는 PK를 참조하는 경우
4. Entity integrity
   • primary key가 null일 수 있다.

DELETE도 생각해보자.

삭제된 tuple이 어느 relation이 참조하고 있을 수 있다. 이런 경우 참조하고 있는 relation의 foreign key에 이상한 값이 들어가있게 된다. 이런 상황에서 DBMS가 취할 수 있는 조치는 다음과 같다.

• RESTRICT : reject the option
• CASCADE : propagate the new primary key value into the foreign key of the referencing tuples
  • 사진과 같은 예시를 생각해보자. Manager가 퇴사를 한다면 DEPARTMENT의 Mgr_ssn은 EMPLOYEE의 Ssn이 삭제되었으므로 이상한 값을 가리키고 있다. 이때 다른 부서장을 넣어주는 방식이 CASCADE이다.

• SET NULL : foreign key를 NULL로 만들어 준다. 위의 예시에서 Mgr_ssn을 NULL로 만들어 주는 것이다.

이런 설계는 데이터베이스 설계 과정에서 같이 포함되어야 한다.

UPDATE도 생각해보자.

UPDATE는 기본적으로 domain 제약사항을 위반할 가능성이 높다. 그러나 NOT NULL filed를 UPDATE 할 때도 조심해야 한다. 자세히 생각해보자.

primary key를 UPDATE하는 경우

• PK를 UPDATE하는 것은 원래 있던 PK를 삭제하고 새로운 PK를 삽입하는 것과 유사한 문제가 생길 수 있다.
• PK가 다른 테이블의 FK로 부터 참조되고 있는 경우를 생각해보면 된다.
• DELETE에서 고려한 option을 똑같이 고민해야 한다.

foreign key를 UPDATE하는 경우

• referential integrity를 위반할 수 있다.
• 새롭게 업데이트된 값이 참조하는 테이블 PK의 state에 존재하지 않는 경우를 생각해보면 된다.

PK도 아니고 FK도 아닌 경우

• domain 제약사항을 위반할 가능성이 높다.