[데이터베이스 정리] ch.3 관계형 모델, 관계형 데이터베이스 구조 RDB

The Concept of Relational Model ⭐

• 관계 모델에서 데이터베이스는 릴레이션 ( 테이블 ) 들의 모임으로 표현됨
• 릴레이션은 투플 ( 행 , 레코드 ) 들의 집합으로 표현됨
• 투플은 애트리뷰트 ( 컬럼 , 필드 , 혹은 속성 ) 들로 구성됨

관계 모델의 용어

• 행 : 투플 = row, record, occurence
• 열 : 애트리뷰트 ( 속성 ) = field, column, domain(type 중심) => 열 전체를 잡아 schema
• 테이블 : 릴레이션 = entity, instance

 

---

 

Domain, Tuple, Attribute, Relation

릴레이션과 연관된 용어들 ⭐

• 도메인(domain): 원자 값들(atomic values)의 집합
  -USA_phone_numbers : 미국에서 사용하는 10 자리 전화번호들의 집합
  -Names : 개인의 이름들의 집합
  -Age : 16~60 사이의 사원들의 나이 ( 정수 )
  -도메인은 실제 데이터 타입으로 명시함 (int, char(10), ...)
• 릴레이션 스키마 (Relation schema)
  -릴레이션 이름 'R' 과 애트리뷰트 'A' 들의 집합으로 R(A1, A2, A3..., An)로 표기함
  예 : STUDENT(Name,SSN,BirthDate,Addr)
  -릴레이션의 차수 (degree): 릴레이션의 애트리뷰트 갯수 (n)
  -릴레이션 R(A1, A2, A3..., An)의 투플 t : n-투플이라고 부름
  -값들의 ( 순서화된 ) 집합 t=< v1, v2, v3, ... , vn> ; 값 vi 는 dom(Ai) 의 한 원소임 ;
  => t는 하나의 tuple이고 생각하면 되며 v의 순서는 중요하다!
  -R에 대한 릴레이션 혹은 릴레이션 인스턴스 (Relation instance) r(R)
• 투플의 집합 ;
  - r(R) ⊆ dom(A1)×. . . ×dom(An) : r(R) 은 실세계의 특정 상태를 반영

 

---

 

The Propoerties of Relation ⭐

• 릴레이션에서 투플의 순서는 의미가 없음
  -집합에서 원소의 순서가 무의미한 것과 마찬가지 임
• 각 투플 내에서의 값들의 순서
  -n-투플은 n 개 값으로 구성된 리스트이며, 한 투플 내에서 값들의 순서는 중요함 (리스트에서 원소의 순서는 중요한 의미를 가짐)
• 투플 내의 필드값
  -나눌 수 없는 원자 값들 (atomic values) 임
  -값을 알 수 없거나 해당되는 값이 없을 때에는 null 이라는 특수 값을 사용함
  -ER 모델에서의 다치(multi-valued) 애트리뷰트나 복합(composite) 애트리뷰트는 관계모델에서는 허용되지 않음
  => 다치 애트리뷰트: attribute가 여러개로 이루어진, 복합 애트리뷰트: attribute에 여러 원소가 함께 존재하는

 

---

 

Relational Model Notations(표기법)

• 차수가 n인 릴레이션 스키마 R은 R(A1, A2, A3, ... , An) 으로 표기한다 .
• 릴레이션 r(R)의 n-투플 t는 t=<v1, v2, v3..., vn>으로 표기한다 . 여기서 vi는 애트리뷰트 Ai의 값이다.
• 투플 t의 구성 요소 값(component value)을 t[Ai]=vi (투플 에 대한 애트리뷰트 의 값)로 표기한다.
  마찬가지로, t[Au, Av, ..., Aw]는 애트리뷰트 Au, Av, ..., Aw 의 값을 포함하는 부(sub)-투플을 가리킨다.
• 대문자 Q, R, S 등은 릴레이션 이름을 나타낸다.
• 소문자 q, r, s 등은 릴레이션 상태를 나타낸다.
• 소문자 t, u, v 등은 투플을 나타낸다.
• 일반적으로, STUDENT 처럼 릴레이션 스키마의 이름은 릴레이션의 현재 투플들의 집합, 즉, 현재의 릴레이션 상태를 가리키고, 반면에 STUDENT(Name, SSN, ...)는 릴레이션 스키마를 가리킨다.
  서로 다른 릴레이션에서 동일한 이름의 애트리뷰트를 사용할 수 있으며, 이 경우 애트리뷰트 이름 앞에 릴레이션 이름을 붙여서 서로를 구분한다.

 

---

 

Relational Model Constraints and Relational Database Schema

제약조건은 모든 릴레이션 인스턴스들이 만족해야 하는 조건임 
-주요 제약조건 ⭐

• 도메인 제약 조건 (domain constraints) 
• 키 제약조건 (key constraints) 
• 엔티티 무결성 제약조건 (entity integrity constraints) 
• 참조 무결성 제약조건 (referential integrity constraints) 

 

Domain Constraints (도메인 제약조건) ⭐

각 애트리뷰트 A의 값은 반드시 A의 도메인 dom(A)에 속하는 원자값이어야 함
도메인과 관련된 데이터 타입

=> domain의 제약조건에 준하는 데이터가 기입되어야 한다는 의미

• 정수, 실수와 같은 표준 숫자형
• 문자, 고정길이 문자열 , 가변길이 문자열
• 날짜, 시간
• 화폐단위\
• 메모 등

Key Constraints (키 제약조건) ⭐

• R의 수퍼키(superkey SK) : 유일성 제약(uniqueness constraint) 조건 만족
  -R의 애트리뷰트 집합 SK로서 다음의 성질을 만족해야 함.
  -모든 유효한 릴레이션 인스턴스 r(R)에서 어떠한 두 투플도 동일한 SK 값을 갖지 않아야 함; 즉,
  내의 임의의 서로 다른 두 투플 t1과 t2에 대해 t1[SK] ≠ t2[SK] 이어야 함
• R의 키(key) 또는 후보키(Candidate key CK)
  -“최소” 수퍼키; 즉, 수퍼키들 중에서 수퍼키 를 구성하는 어느 한 애트리뷰트라도 빠지면 수퍼키
  가 될 수 없는 수퍼키 K를 의미함
  -예제: CAR 릴레이션 스키마 CAR(State, Reg#, SerialNo, Make, Model, Year)는 두개의 키
  Key1 = {State, Reg#}, Key2 = {SerialNo}를 가지며, 이들은 동시에 수퍼키이다. {SerialNo,
  Make}는 수퍼키이나 키는 아니다.
• 기본 키(primary key) 릴레이션이 여러 개의 후보키(CK: candidate key)를 가지면 이중 하나를 임의로 선택
  하여 기본키(PK: primary key)로 지정함. 기본키를 구성하는 애트리뷰트는 밑줄로 표시함.
• 애트리뷰트의 값으로 널의 허용 여부도 중요한 제약 조건임
  
  

Relational Database and Relational Database Schema 

• 관계 데이타베이스 스키마
  -동일한 데이타베이스에 속하는 릴레이션 스키마들의 집합 S와 무결성 제약조건 IC로 구성됨
  -릴레이션 스키마 집합 S를 데이타베이스 이름이라고 정의함: S = {R1, R2, ..., Rn}
• 데이타베이스 스키마 S의 관계 데이타베이스 상태 (혹은 인스턴스)
  -릴레이션 상태들의 집합
  -예제: Company = {Employee, Department, Dept_locations, Projects, Works_On,
  Dependent}는 관계 데이타베이스 스키마이고 (그림 3.5), 그림 3.6은 Company 스키마에 해당하
  는 관계 데이타베이스 상태를 보여준다
  
  

Entity Integrity Constraints, Referential Integrity Constraints (엔티티 무결성 제약조건, 참조 무결성 제약조건)⭐

• 엔티티 무결성 제약 조건 (Entity Integrity Constraints)
  -어떠한 기본 키 값도 널 값을 가질 수 없다는 제약 조건임
  -기본키가 각 투플들을 식별하는 데에 이용되기 때문임
  -참고 : R의 기본키에 속하지 않는 애트리뷰트들도 null 값을 가질 수 없도록 제한할 수 있음; 릴레이션의 속성을 정의할 때 not null 임을 명시
• 참조 무결성 제약 조건 (Referential Integrity Constraints)
  -하나의 릴레이션 R에서 속성 FK의 값으로 다른 릴레이션 S의 기본 키 PK값을 참조하는 경우에 R과 S는 참조 무결성 제약 조건을 가진다고 함; 이 때 FK의 값은 널(null)을 가질 수 있음
  - t1[FK] = t2[PK] 이면 R의 투플 t1이 S의 투플 t2를 참조한다(reference)고 하며 , FK를 외래키(Foreign Key)라고 부름; R을 참조한 (referencing) 릴레이션 , S를 참조된 (referenced) 릴레이션이라고 부름
  -앞의 제약조건들은 하나의 릴레이션에 대한 제약 조건이지만, 참조 무결성은 두 릴레이션에 대한 제약조건임을 유의해야 함
  -관계형 데이타베이스 스키마에서 참조 무결성 제약조건은 R1.FK에서 R2로의 화살표로 표시함

 

참조 무결성 제약조건을 따르는 DB

 

---

 

Update Operations, Transaction, and Handling Violations of Constraints⭐

• 릴레이션에 대한 기본 갱신 연산들
  삽입, 삭제, 수정
• 갱신 연산을 실행하는 경우 스키마에 정의된 무결성 제약 조건을 위반하지 않아야 함
  => 연산과정에서 pk가 null이 되는 경우 X
• 삽입연산 : 네가지 제약 조건을 위반할 수 있는 가능성이 있음
  1. 삽입되는 투플 t에서 애트리뷰트의 값이 도메인에 없으면 도메인 제약 조건을 위반함
  2. t에서 기본 키의 값이 다른 투플에서 이미 존재한다면 키 제약 조건을 위반하며, 널이면 엔티티 제약 조건을 위반함
  3. t에서 외래 키의 값이 참조되는 릴레이션의 키 값으로 존재하지 않는다면 참조 제약 조건을 위반함
  4. 제약 조건을 위반하면 그 삽입을 거부하거나 그 위반 사실을 사용자에게 알려야 함
• 삭제연산
  -투플이 삭제되는 경우 다른 테이블에서 참조하고 있는지 검사하여 그렇지 않는 경우에만 삭제함 (참조 무결성)
  -삭제 연산이 참조 무결성 제약 조건을 위반하는 경우 취할 수 있는 세가지 옵션
  1. 삭제를 거부
  2. 삭제되는 투플을 참조하는 투플들까지 모두 삭제 (연쇄 삭제(on delete cascade))
  3. 삭제되는 투플을 참조하는 투플에서 외래키 값을 널로 바꾸거나 다른 유효한 투플을 참조하도록 변경 (on delete set null)
• 위의 세가지 옵션 중 사용자가 응용의 특성에 적합한 것을 선택하도록 하는 것이 바람직함
• 수정연산
  -수정 연산은 기본적으로 “삭제 후 삽입” 연산으로 간주할 수 있으므로 삽입과 삭제시의 문제점이 모두 나타남
  -기본 키나 외래키가 아닌 애트리뷰트 값의 변경은 문제가 없음