[데이터베이스 04] Relational Data Model

Informal	Formal
Table	Relation
Column Header	Attribute
All possible Column values	Domain
Row	Tuple
Table Definition	Schema ( of Relation )
Populated Table	State ( of Relation )

 

Relation

Informal

값들을 모아둔 테이블에 대응되며, row의 집합으로, Set(집합) 이라는 수학적 개념에 기반을 두고 있다.

• Row 에 포함된 데이터 원소들은 Real-World(혹은 Mini-World) 의 Entity 또는 Relationship에 대응된다.
• Column 은 해당 컬럼에 속한 데이터들의 속성을 의미한다.

• Key of Relation
   : 각각의 row는 아이템의 ( 혹은 아이템의 집합의 ) 값을 가지는데, 어떤 값이 테이블 내의 row을 유일하게 식별하는 경우, 이를 Key 라고 부른다.
  • ex ) 학생은 학번을 통해 식별될 수 있다.
  • Artificial Key / Surrogate Key
    : 시스템 상에서 각 row에 대해 자동적으로 생성해주는 임의의 키로, 테이블의 각 row을 식별하는데 사용된다. auto-increment 옵션을 이용했을 때 만들어지는 키가 여기에 속한다.
    
    • ex)  위 테이블의 id 영역.

Formal

• Relation Schema
  : 특정 관계에서 Relation이 수행하는 역할을 정의하거나 묘사해둔 것.
  
  • R(A1, A2, A3 ... , An) 형식으로 나타낸다.
    • R : relation의 이름
    • A1 ~ An : R의 어트리뷰트(속성). 각 속성들은 유효한 값에 대한 Domain을 가지고 있다.
      • Domain : 특정 속성(attribute)이 가질 수 있는 값의 집합. ex) 주민등록번호 : 13자리의 숫자
    •  ex ) PERSON( id ,name, age, mobile_no )
• Tuple
  : 순서 있는 값들의 집합으로, < ... > 형태로 나타나며, 튜플의 각 값들은 대응되는 어트리뷰트에 대한 적절한 도메인으로부터 생성된다. relation이 이러한 튜플(row) 들의 집합(set)을 명심하자.
  • ex ) PERSON에 대한 row은 4-tuple 이며, 다음과 같이 나타날 수 있다.
          : < 13, "Blaxsior", 43, "010-0000-0000" >
          위 튜플은 PERSON relation에 대한 튜플이다.
• Domain
  : mini-world 상에서 정의된 논리적 정의, 데이터 타입이나 포맷.
  • ex1 ) 한국의 휴대전화번호는 10자리 정수로 이루어진다.
  • ex2 ) 날짜는 year, month, date 등으로 구성되며, yyyy-mm-dd 꼴로 나타낼 수 있다. 
• Attribute Name
  |: relation 에서 도메인에 의해 특정 속성이 수행하는 역할에 대응되는 이름. 쉽게 말해 속성의 이름.
  
  • 동일 도메인이라도, 해당 어트리뷰트가 수행하는 역할에 따라 완전히 다른 성격을 지닐 수 있으므로, Attribute name을 지을 때는 신중해야 한다.
  • ex ) "시작일" 과 "만기일" 은 Date 라는 동일한 도메인을 이용하지만, 완전히 다른 성격을 지닌다.
• Relation State
  : Attribute에 속한 Domain에 대한 Cartesian product의 부분 집합(Subset).
   각각의 Domain들은 특정 Attribute가 가질 수 있는 모든 가능한 값들의 집합을 가진다.
  • r(R) relation R 에 대한 특정한 state( value, population ). relation state을 의미하는 표기.
  • ex 1) A { a1, a2 }, B { b1, b2, b3 } => AxB = { <a1,b1>, <a1,b2>, <a1,b3>, <a2,b1>, <a2,b2>, <a2,b3> }
  • ex 2) { <a1,b1>, <a2,b1> } 은 AxB의 부분집합이므로 r(R) 이 될 수 있다. ( two 2-tuple )

Given R(A1, A2, A3 ... , An)
r(R) ⊂ dom (A1) X dom (A2) X ....X dom(An)
where R(A1,A2,A3...) : Schema of Relation
      R : Relation Name
      A1,A2 ... An : Attributes of Relation

r(R) = { t1, t2, t3 ... tn } : n-tuple
ti = <v1, v2, v3, ... vn> : vj element of dom(Aj)

• Relational Database Schema
  : 동일 데이터베이스 상에 속한 Relation Schema 들의 집합.
  
  • S = { R1, R2, R3 ..., Rn } 일때,
    • S : 전체 데이터베이스 스키마의 이름
    • S에 속한 Relation R1, R2 ... 는 Integrity Constraint을 만족한다.
• Relational Database State
  : Relational Database Schema S = { R1, R2, R3 ... , Rn } 에 대해 각각의 Relation Schema 에 대응되는 Relation State을 r1, r2, r3 ... rn 이라고 할때, Integrity Constraint을 만족하는 r(R)의 집합 { r1, r2, r3 ... , rn } 
   즉, 전체 데이터베이스에 대한 Relation State의 집합 ( 개개 state의 union ) 을 의미한다.
  • 경우에 따라 Relational Database Snapshot / Instance로 불리기도 하나, Instance의 경우 단일 튜플에도 적용되는 용어이므로, 사용을 자제해야 한다.
  • Invalid State : 데이터베이스의 state 가 제약조건을 만족하지 못하는 경우

Relation의 특성

r(R) (Relation state) 의 튜플들의 순서

기본적으로 relation state은 카르테시안 곱의 부분 "집합" 이다. 집합은 통상 집합 내 원소에 대해 순서를 부여하지 않는데, 이로 인해 r(R) 에도 순서가 없다.

 예를 들어 A = { a, b } , B = { b, a } 라는 집합이 있다고 하자. 수학에서는 두 집합 A 및 B를 동일하다고 판단한다. 이는 집합에 순서가 존재하지 않기 때문인데, r(R) 역시 집합이므로 원소의 위치 변경과 무 무관하다는 특징을 가진다.

R(A1,A2 ... An) (Relation) 의 Attribute 와 튜플의 데이터 순서

 Relation 자체는 attribute의 순서와 큰 관계 없이 동일한 대상을 가리킨다. 예를 들어 PERSON(name, age, phone_num) 의 Attribute 중 name 과 age의 위치가 변경되어 PERSON(name, age, phone_num) 이 된다고 해서 mini-world의 다른 객체를 가리키는 것은 아니다.

 그런데, Relation이 Tuple과 연관되기 시작하면, 순서가 중요해진다. PERSON(name, age, phone_num) 의 스키마에 대해 만들어진 tuple <"blaxsior", 24, "010-0000-0000"> 은 PERSON(age, name, phone_num) 스키마를 이용하면 완전히 다른 의미가 된다. 기존 스키마에서는 "blaxsior" 이 이름이었던 것에 비해, 변경된 스키마에서는 24 가 이름이 된다.

 기본적으로 SQL 계열 DBMS에서는 메타 데이터인 schema와 데이터인 row 가 따로 저장된다. 따라서 특정 row을 해석하기 위해서는 해당 row을 설명하는 메타 데이터인 특정 schema가 필요하다. 즉 스스로 설명이 가능한 모델에 기반한 DBMS가 아니라면 Relation의 Attribute 순서에 따라 데이터의 해석이 달라지므로, 순서가 매우 중요하다.

 반면 self-describing 인 NoSQL을 사용하는 경우 attribute가 데이터와 함께 저장되므로, 튜플 내에서 attribute 및 data의 순서가 크게 중요하지 않다. 예를 들어 어떤 튜플 { <name, blaxsior>, <age, 24> } 이 { <age, 24> , <name, blaxsior> } 이 된다고 해도 데이터와 메타 데이터가 함께 존재하므로, 순서가 크게 중요하지는 않다.

튜플의 값

• atomic (indivisible)
  : 더이상 나눌 수 없는 값이다. { a1, a2 } 는 튜플의 값이 될 수 없다.
• 각 튜플의 값은 attribute의 domain의 정의를 잘 준수해야 한다.
  ex) t = <v1, v2, ..., vn>에서의 vj 는 R(A1, A2, ..., An) 의 Aj 와 대응되며, dom(Aj) 에 속한다.
• null : unknown, not available or inapplicable 한 값을 가리킨다.
• 표현 방식 : t[Ai] , t.Ai 형식으로 나타내며, 튜플 t의 Attribute Ai 에 대응 되는 값을 나타낸다.
• 서브 튜플 : t[Au, Av ... ] 는 subtuple을 의미하며, Au, Av ... 에 대응되는 값(value) 을 의미한다.

제약조건(Constraints)

Relation 에서의 제약조건은 특정 값이 데이터베이스에 들어갈 수 있는지 여부를 결정하는데 사용된다.

1. Inherit or Implicit Contraints
   : 특정 데이터 모델 자체가 가지고 있는 제약 조건을 의미한다. 이 제약조건을 만족하지 못하면 데이터베이스 내에 정보를 저장하는 것 자체가 불가능하며, 특정 데이터 모델에 속하지 못하게 된다.
   • ex) Relation Model에서 모든 값들은 대응되는 Attribute을 따라야 한다. Attribute을 따르지 않으면, 해당 값은 데이터 베이스 내에 저장되지 않는다. ( 데이터 무결성 )
2. Schema-based or Explicit Constraints 
   : 스키마를 이용하여 나타내는 제약조건. 보통 SQL 수준에서 이루어지는 제약조건이 여기에 속한다.
   
   • ex ) Cardinality Ratio, Key, Domain ...
3. Application based or Semantic Constraints
   : 스키마/SQL 수준에서 제약할 수 없는 영역의 조건. 모델 수준이 아니라, 어플리케이션 수준에서 정의되고, 해당 영역에서 수행되는 제약 조건이다.
   • ex ) 학생이 한 학기에 수강 가능한 수업 시수는 최대 18학점인데, 해당 제약조건은 데이터베이스가 아니라 수강신청 어플리케이션 시스템에서 관리한다.

Relational Integrity Constraints

 데이터베이스 내 모든 relation state ( 즉, 데이터들 ) 은 제약조건에 기반한 무결성을 지닌다. 이때 Relational Model에서는 다음과 같은 제약조건들이 주로 표현된다.

• Key Constraints
• Entity integrity Constraints
• Referential integrity Constraints 
• Domain Constraints

Key Constraints

• Key ( UNIQUENESS, MINIMALITY )
  : 특정 튜플을 유일하게 식별하는 Attribute의 최소 집합.
  • ex ) 학생( 학번, 나이, 전화번호 ) 은 학번이라는 최소 단위의 속성에 의해 서로 구분될 수 있다.
• Super Key ( UNIQUENESS | Super Set of Key ) 
  : 특정 튜플을 유일하게 식별하는 Attribute의 집합으로, Key + other Attributes 형태가 된다.
  • r(R) (relation state) 의 어떤 튜플도 동일한 SK(Super Key) 를 가지지 않는다.
    => if t1 and t2 are distinct tuples, then t1[SK] != t2[SK]
  • Super Key는 Key의 Super Set이므로, Key는 Super Key가 될 수 있지만, 반대는 성립하지 않는다.
  • ex ) 학생은 학번 + 나이 조합으로도 구분될 수 있다. 그러나, 이 조합이 학생을 구분하는 최소 단위는 아니다.

 

• Primary Key
  : Relation에서 각 튜플을 유일하게 식별하는데 실제로 사용되는 키. 밑줄을 그어 표현한다.
• Candidate Key
  : Primary Key로 사용할 수 있는 후보가 되는 키. 
• Secondary Key
  : Primary Key로 선택되지 않은 Candidate Key

 일반적으로 Primary Key는 Candidate Key 중 가장 길이가 짧은 것을 선택하며, 한번 정해지면 변경할 수 없다. 차 번호판, 주민등록번호, 사원 번호, 학번 등은 보통 한번 정해지면 변경하기 매우 어렵거나 불가능하다.

Entity Integrity Constraints

 각각의 Relation Schema에 대해 Relation State에 속한 모든 튜플들은 Primary Key의 값으로 Null을 가져서는 안된다는 제약조건이다. Primary Key는 동일한 Relation State에 있는 튜플들을 유일하게 식별하는데 실제로 사용되는 키인데, 해당 키가 존재하지 않으면 해당 튜플들을 식별할 수 없어 데이터 무결성을 잃게 된다.

 따라서 모든 Primary Key Attribute는 반드시 NOT NULL 제약 조건을 가져야 한다.

Referential Integrity Constraint

 참조 무결성은 2개의 relation 사이에서 발생하는 관계와 관련된 무결성이다. 관계된 2개의 튜플 사이에서 참조 관계가 존재하는 경우, 참조하는 측 튜플은 FOREIGN KEY를 이용하여 참조되는 튜플의 PRIMARY KEY를 가리키게 된다.

• referencing relation : 참조하는 측의 relation 
• referenced relation : 참조되는 측의 relation
• Foreign Key : referencing relation이 referenced relation을 참조할 때, 해당 relation 의 Primary Key를 가리키는 키.
  
  • t1이 t2를 참조하는 경우, t1[FK] = t2[PK] 가 된다.

ex ) STUDENT( id, Name, Dept_Id ) 은 Dept_Id 을 통해 Dept( Dept_Id, Name, Loc ) 을 참조할 수 있다. 이때 STUDENT는 referencing relation, Dept는 referenced relation 이며 STUDENT의 Foreign Key Dept_Id 는 Dept의 Primary Key Dept_Id를 가리키게 된다.

참조 무결성에 대한 제약조건은 다음과 같다.

1. referencing relation 인 R1의 인스턴스 r1이 R2을 참조하여 Foreign Key의 값을 가지면 (Null 이 아니면), r(R2) 의 튜플 중 r1의 FK에 대응되는 Primary Key를 가진 튜플 r2가 반드시 존재해야 한다.
   즉, r1이 r2를 Foreign Key를 이용하여 참조하기 위해서는 r2의 Primary Key 와 반드시 대응해야 한다.
   • ex) 학생이 컴퓨터 학과에 속하기 위해서는 반드시 컴퓨터 학과가 존재해야 한다.
2. Foreign Key는 NULL 일 수 있다.
   
   • ex) 입학 시점에 정해진 학과가 없는 경우, 학생의 학과는 NULL로 처리될 수 있다.
3. Foreign Key가 Primary Key를 구성하는 부분 중 하나라면, NULL이 허용되지 않는다.
   • ex) 회사원에 대한 부양 가족 정보에는 반드시 특정 회사원 정보가 포함된다. 어떤 회사원도 부양하지 않는 부양가족이 회사 데이터베이스 내에 저장될 필요는 없다.

 Foreign Key는 보통 화살표로 나타낸다. 화살표가 출발하는 attribute가 Foreign Key, 도착하는 attribute가 referenced relation의 Primary Key를 의미한다.

Domain Constraints

 데이터베이스 내에서 Relation Schema R에 대한 인스턴스인 튜플 t의 각 값 v1, v2, v3 ... 은 대응되는 Attribute A1, A2, A3 ... 에 대한 도메인 ( Attribute가 가질 수 있는 값 ) 범위 안에서 정의되어야 한다. 즉, 튜플의 각 값은 대응되는 스키마 상의 속성이 가질 수 있는 값만 할당될 수 있다.

ex) "주민등록번호" 라는 속성은 일련의 13자리 정수형 숫자를 가질 수 있다. 이러한 도메인을 가진 속성에 "홍길동" 같은 문자열을 대입하는 행위는 허용되지 않는다.

다른 타입의 제약조건들 ...

Semantic Integrity Constraints

 모델 수준에서 표현할 수 없어 어플리케이션 레벨로 표현해야 하는 제약조건들을 의미한다. 예를 들어, 학생과 수업 사이의 관계는 모델을 통해 표현할 수 있지만, 한 학기에 이수해야 하는 최소 학점 및 최대 학점과 같은 제약조건은 모델 수준에서 처리할 방법이 없다. 

 이러한 문제를 해결하기 위해 Constraint Specification Language을 사용할 수 있다. 예를 들어 SQL-99 부터 CREATE TRIGGER( 이벤트 기반 프로시저 ), CREATE ASSERTION( 각 값의 조건을 검사, 만족하면 생성 )  을 지원한다. 다양한 제약조건 ( 키, 참조 무결성 등 ) 은 CREATE TABLE로 정의 가능하다.

Update Operation on Relation

• INSERT : 삽입
• DELETE : 삭제
• MODIFY / UPDATE  : 수정

 

• UPDATE 연산은 Integrity Constraint을 위반할 수 없다.
• 다양한 UPDATE 연산이 트랜잭션의 형태로 한번에 수행될 수 있다.
• 특정한 값의 업데이트는 Integrity Constraint을 보장하기 위해 관련된 Relation의 값들을 업데이트 할 수 있다.
  • ex) 컴퓨터 학과에 대한 학과 코드가 'CE' 에서 'CSE'로 변경되는 경우, 모든 컴퓨터 학과 학생들의 학과 코드 역시 CSE로 변경된다. 이는 DEPT에서의 학과 코드 변경이 STUDENT의 학과 코드 변경으로 전파된 것이다. 
  • 특히 변경하고자 하는 키가 Primary Key라면, 변경시 Reference Integrity를 위반할 수 있으므로 관련된 Foreign Key도 변경되도록 변경을 전파하는 것이 좋을 것이다.
• UPDATE에 의해 무결성이 손상되는 경우에 대비하여 다음 동작을 지정해둘 수 있다.
  • RESTRICT / REJECT
    : 무결성을 위반하는 UPDATE 동작 자체를 취소한다.
    • ex ) 학과 코드를 변경할 수 없게 지정한다.
  • CASCADE
    : UPDATE 동작을 전파하여 무결성을 위반하는 부분을 자동적으로 수정하게 만든다.
    • ex ) 학과 코드를 변경하면 연관된 학생들의 학과 코드도 자동으로 수정된다.
  • SET NULL
    : 변경한 Key와 관련된 Foreign Key를 NULL로 처리한다.
    • ex ) 학과를 없애는 경우, 해당 학과 학생들을 학과가 없다는 의미로 NULL로 처리한다.
  • 동작 수행 후, 에러를 알린다

각 Operation에 대한 고려 사항

• INSERT : 삽입
  
  • Domain Constraints : 새로 삽입하는 튜플의 값들이 attribute의 도메인을 준수하도록 제어해야 한다.
  • Key Constraint : 다른 튜플에서 사용하고 잇는 키를 중복해서 사용하면 안된다.
  • Referential Integrity : 존재하지 않는 Primary Key를 참조하게 만들면 안된다.
  • Entity Integrity : Primary Key는 반드시 값을 가져야 한다.
• DELETE : 삭제
  • Primary Key가 삭제되는 경우, Referencial Integrity에 문제가 발생할 수 있으므로, 조치를 취한다. 
    • RESTRICT : 키를 삭제할 수 없도록 만든다.
    • CASCADE : 키의 삭제를 전파, 연관된 튜플들을 제거하거나, 새로운 Primary Key로 대체한다.
    • SET NULL : 관련된 Foreign Key들을 NULL로 설정한다.
• MODIFY / UPDATE  : 수정
  • MODIFY는 기본적으로 1) 기존 값을 삭제(DELETE) 하고, 2) 새로운 값을 삽입(INSERT) 하는 과정이므로, 위에서 언급한 조건들을 모두 만족해야 한다.
    • Primary Key : INSERT 및 DELETE 조건을 모두 고려한다.
    • Foreign Key : Referential Integrity을 고려한다.
    • 일반적인 속성 : INSERT시 Domain Constraint 만 고려해도 된다. ( 제대로 값을 넣었는지만 고려해도 OK )