[Database] 5. 관계형 데이터모델과 관계형데이터베이스 제약

REF: fundamentals of database systems 7th edition

Relational Model Concepts

• ERD로 작성한 개념적 모델을 관계형 모델로 매핑한다.

Domain, Attribute, Tuple, Relation

Domain

• 정의 : ⭐️분리 불가능한 atomic value의 집합
• 정의 방법
  1. name : domain의 이름
  2. data type : 데이터 형
  3. format : 데이터 포맷
  4. additional information : 단위

Relation Schema

• Relation Schema R
  • ⭐️relation의 구조를 의미한다.
• R(A1, A2, … An)
  • R : relation의 이름
  • Ai : relation을 구성하는 attribute의 이름
  • dom(Ai) : domain of Ai, Ai attibute의 domain
  • degree of relation : attribute의 개수
• STUDENT의 relation schema
  • STUDENT(Name, SSN, HomePhone, Address, OfficePhone, Age, GPA)
  • relation name : STUDENT
  • degree : 7
  • dom(Name) : 학생이름 집합
  • dom(SSN) : 주민번호 집합
  • dom(HomePhone) : 전화번호집합
  • dom(OfficePhone) : 전화번호집합
• !HomePhone, OfficePhone
  • ⭐️동일 Domain, 다른 role을 할 수 있다.

Relation

• relation : r(R)
  • relation schema R(A1, A2, ... An)의 relation, relation instance
  • r = {t1, t2, ... tn}
    • n개의 tuple(row, record)의 집합
  • t = <v1, v2, ... vn>
    • v1은 dom(A1), v2는 dom(A2)…에 속한다.
• ⭐️relation intension
  • Relation Schema R
• ⭐️relation extension
  • Relation Instance r(R)
  • r(R
• degree n의 relation instance r(R)의 수학적 표현
  • r(R) ⊂ |dom(A1)| x |dom(A2)| x ... x |dom(An)|

  • dom(A1)

    : domain(A1)에서 유효한 값의 개수

  • ⭐️r(R)은 모든 attribute domain cardinality의 cartesian product의 부분집합.
• ⭐️current relation state
  • 특정 시간의 relation state를 의미
  • miniworld의 특정 상태를 나타내는 유효한 tuple의 모임
  • relation : ⭐️dynamic, 계속 상태가 바뀐다.
  • relation schema : ⭐️almost static, 매우 가끔 바뀐다.

Relation 특성

Ordering of Tuples

• relation (instance)는 tuple의 ⭐️집합이므로, ⭐️수학적으로는 순서가 존재하지 않는다.
  • but file 단계에서는 물리적 순서가 존재한다.
  • RDBMS의 table과 헷갈리면 안되는게, table은 집합이 아니므로 중복되는 tuple을 있는 그대로 표현한다.

Ordering of values within a tuple

• n-tuple은 n개의 값의 순서있는 리스트이다.
• 하지만, attribute와 value간 관련성이 유지되는 한, 순서는 중요치 않다.

Interpretation of relation

• relation은 ⭐️fact와 relationship의 통합된 표현이다.
  • entity에 대한 fact와 개체간 relationship을 표현한다.

• relation schema는 주장, 혹은 선언으로 해석될 수 있다.
  • relation의 tuple은 사실, 혹은 주장의 사례로 해석될 수 있다.

relational model notation

• n degree의 relation schema R
  • R(A1, A2, ..., An)
• relation instance r(R)의 n-tuple t
  • t = <v1, v2, v3, ..., vn>
  • vi는 attribute Ai에 대응되어 dom(Ai)에 속한다.
• t의 Ai 속성값
  • t[Ai] = t.Ai = t의 vi 값
  • 여러개(subtuple) 가져올수도 있다.
  • t[Au, Aw, ... , Az], t.(Au, Aw, ... , Az) = <vu, vw, ..., vz>

example

t = <’Barbara Benson’, ‘533-69-1238’, ‘(817)839-8461’, ‘7384 Fontana Lane’, NULL, 19, 3.25>

• t[Name] = <‘Barbara Benson’>
• t[Ssn, Gpa, Age] = <‘533-69-1238’, 3.25, 19>

Relational Model Constraints and Relational Database Schemas

Domain Constraint

• 정의 : 각 tuple에서 각 attribute A의 value는 dom(A)의 atomic value여야한다는 것이다.
• 이미, name, type, format, additional information 에 대해 이야기를 나누었다.

Key Constraint

• relation -> tuple의 집합 -> 집합은 중복되는 값이 없어야한다.

Superkey

• 정의 : ⭐️tuple을 구분할 수 있는 속성의 부분집합
  • 모든 relation은 최소 1개 이상의 Superkey를 가진다.
  • superiority key의 약자.
• 하지만 Superkey는 ⭐️유일성은 만족하나 최소성을 만족하지는 못한다.
  • 튜플을 유일하게 식별할 수는 있으나, 유일성을 만족하면서도 속성을 더 제거할 수 있다.
  • 따라서 더 중요한 개념은 Key의 개념이다.

Key

• ⭐️superkey 중, attribute를 하나라도 제거하면 더이상 superkey가 되지못하는(tuple을 구분하지 못하는) key이다.
• key는 2가지 속성을 가진다.
  • 유일성 : superkey도 만족하는 속성, tuple을 구분할 수 있는 속성
  • 최소성 : minimal superkey, superkey 중에서 attribute를 더 삭제하면 유일성이 깨지는(superkey를 만족하지 못하는) 속성이다.
• 따라서, key는 superkey이지만, superkey는 key가 아닐수도 있다.

• ⭐️time-invariant
  • schema의 valid 모든 ⭐️valid state에서 항상 유지되어야한다.
  • relation에 새로운 tuple을 삽입해도 계속 key 속성을 유지해야한다.

Candidate Key, Primary Key

• Candidate Key : relation에서 존재하는 각 Key를 의미.
• Primary Key : DB Designer에 의해 Candidate Key 중 선택된 Key
  • 단순 속성(simple attribute)또는 적은 수의 composite attribute를 선택한다.

Relational Databases and Relational Database Schemas

정의

• Relational Database
  • 여러개의 relation으로 구성되는데, 이 relation들은 서로 다양한 방법으로 관계를 가지는 tuple로 이뤄진다.

• Relational Database Schema(관계형 DB 스키마)
  • 관계형 DB 스키마는 2가지 구성요소로 이뤄진다.
  • S =
    • ⭐️{R1, R2, ... Rm}(각 relation schema의 집합)
    • + ⭐️Integrity Constraint(IC)(integrity constraints의 집합)

• Relational Database Instance DB
  • integrity constraint를 만족하는 relation instance의 집합

• ⭐️relational db = relational database ⭐️schema + ⭐️instance

속성이름 제약

• 같은 relation 내에서 동일한 개념(직원번호 - 상사의 직원번호)의 속성이름을 지정할때에는
  • 역할구분을 위해 다른 이름을 사용해야한다.(동일개념->다른이름)
• 다른 relation에서는 완전히 다른 개념일지라도 동일한 이름을 사용할 수 있다.

Enity Integrity, Referential Integrity

• RDBMS에서 확인하는 제약은 아래 4가지이다.

1. 개체무결성제약(entity constraint) : key는 null이어서는 안된다.
2. 참조무결성제약(referential constraint) : 참조하는 fk는 다른 테이블에 존재해야한다.
3. 도메인 제약(domain constraint) : 속성 값은 Domain내에 있어야한다.
4. 키값 제약(key constraint) : key는 중복되어선 안된다.

• DDL에 포함되어있는 무결성 제약에는
  1. 개체무결성제약
  2. 참조무결성제약 가 있고, 아래에서 이에대해 다룬다.

entity integrity constraint(DDL)

• 주키(primary key)는 NULL이되어선 안된다.
• 주키가 NULL이면, tuple을 구분할 수 없게된다.

⭐️referential integrity constraint(DDL)

• 한 relation의 tuple에서 다른 relation을 참조할때는 항상 참조되는 tuple이 존재한다.
• 2개 relation에 존재하는 tuple의 일관성을 유지하는데에 사용된다.

• 참조 무결성 제약은 다른 relation의 tuple을 참조하는 tuple의 값은 항상 다른 relation에 존재하는 tuple이어야한다는 것이다.

• entity간의 relationship을 식별할 수 있다.

⭐️Foreign Key(DDL)

• 참조무결성 제약을 더욱 정형화하게 정의하기 위해선 Foreign key(외래키)를 이해해야한다.

• R1이 R2의 PK를 참조하는 FK를 정의하고 있다고 가정하자.
• R2가 다음 규칙을 충족할 경우 이 키는 관계 R2를 참조한다.
  • 1. R1(FK)와 R2(PK)의 domain이 같아야한다.
    2. R1(FK)의 값은 R2(PK)값과 같거나, NULL값이어야한다.
       • 있거나, 아예 없거나로 정의된다.

semantic integrity constraint(⭐️NOT DDL)

• Mini-world의 제약을 반영한다.
  • 직원의 월급은 그 직원의 관리자보다 많으면 안된다 등의 의미론적 제약
  • DDL의 영역이 아니기에, 다른 방식으로 적용되게된다.
    • 어플리케이션이나, 범용목적 제약 정의 언어(constraint specification language)를 사용해 정의된다.
    • 보통, ⭐️CREATE ASSERTION, CREATE TRIGGER로 사용된다.

Update Operation, Transaction, Constraint violation

• 관계대수 연산은 검색retrieval을 정의하는데에 사용된다.

• 받아올 정보를 존재하는 relation집합에서 받아오기위해 사용되는데, 이 결과로 나타나는 relation을 result relation이라고 한다.

• database에는 relation의 state를 변경하는 3가지의 기본연산이 있는데, Insert, Delete, Update가 그 예이다.

INSERT

• relation에 새로운 튜플 t를 추가한다.

constraint checking(4)

INSERT는 4 종류의 constraint를 위반할 수 있다.

1. domain constraint
   • 첨가되는 tuple의 속성의 값이 속성의 Domain을 벗어남
2. key constraint
   • 첨가되는 tuple의 key가 이미 relation의 다른 tuple에 있을때
3. entity constraint
   • 첨가되는 tuple의 key값이 null일때
4. referential constraint
   • 첨가되는 tuple의 fk가 참조되는 relation에 없는 경우

constraint check fail option(2)

• 위의 제약을 어길때 INSERT operation을 어떻게 처리해야하는지 선택할 수 있다.

1. reject
   • insertion 자체를 거부
2. correct insertion with user interactively
   • db user와 상호작용하면서 insert를 할 수 있도록 db를 수정해나간다.

DELETE

• DELETE연산은 tuple을 relation에서 삭제한다.

constraint checking(1)

• DELETE는 Tuple을 삭제하므로, referential constraint만 확인한다.
  • domain, key, entity constraint는 고려되지 않는다.

constraint check fail option(4)

• tuple을 삭제할때 옵션을 지정해줘야 한다.
• 해당 tuple의 값을 참조하고있는 자식 relation이 있을수도 있기 때문에, 참조 무결성 제약(referential integrity constraint)를 어기게된다.

1. restrict
   • DELETE를 거부한다.
2. cascade(propagate)
   • 삭제되는 tuple을 참조하는 자식 relation의 tuple도 삭제한다.
3. set null
   • 삭제되는 tuple을 참조하는 자식 relation의 tuple의 값을 NULL로 바꾼다.
4. set default
   • 삭제되는 tuple을 참조하는 자식 relation의 tuple의 값을 DEFAULT로 바꾼다.

• 보통은 위의 방법을 섞어서 사용한다.

UPDATE(MODIFY)

• tuple의 값을 수정한다.
  • 수정하다 = DELETE -> INSERT
• PK도, FK도 아닌 값을 수정하는 것은 아무런 문제를 일으키지 않는다.

constraint checking(4)

• UPDATE(MODIFY)는 tuple을 ⭐️DELETE한 후, INSERT하는 것과 같다.
• 따라서, constraint check도 DELETE와 INSERT를 모두 고려한다.

constraint check fail option(4)

• DELETE에서 사용한 옵션 중 하나를 선택할 수 있다.

Transaction

• DB 어플리케이션은 1개 이상의 transaction을 수행한다.
• 이 transaction은 database를 읽어오고, 수정하는 연산을 포함한다.
• transaction 1개가 끝나면 DB는 ⭐️valid한 상태로 있어야한다.

Defining Relation

• 설계된 DB를 DBMS에 이식해야한다.

1. Relational DBMS의 DDL(SQL)을 사용한다.
2. Relational DB Schema를 정의한다.:Declare schema COMPANY
3. Domain을 정의한다.
4. Relation을 정의한다.:Relation name, attribute name, domain, PK, FK, Keys