관계형 데이터 모델
관계형 데이터 모델
관계형 데이터 모델
- 데이터 베이스를 여러개의 관계(Relation) 집합으로 표현하는 모델
- 관계(Relation)는 표(table) 형태로 표현되고, 각 행은 관련된 데이터 값의 모음을 표현함
- 한 열의 값들은 모두 같은 데이터 타입을 가짐
- 용어:
- 튜플(Tuple): 테이블의 한 행을 나타냄
- 속성(Attribute): 테이블의 열을 나타냄
- 도메인(Domain): 속성이 가질 수 있는 값의 범위
- 스키마(Schema): 데이터베이스의 구조와 제약 조건을 정의
- 키(Key): 테이블에서 각 튜플을 고유하게 식별하기 위한 속성 또는 속성의 집합
- 관계(Relation): 테이블 자체를 의미
Domain, Attribute, Tuple, Relation
Domain
- 원자값(Atomic values, 더이상 쪼개질 수 없는 값)의 집합
- 각 도메인은 데이터타입을 이용해 정의됨
- 이름, 데이터타입, 포맷으로 특정됨
- 예시: GPA
Relation Schema
- $R(A_1, \dots, A_n)$
- Relation의 이름 $R$과 Attribute의 목록 $A_1, \dots, A_n$
- 속성 $A_i$ : 특정 도메인 $D$가 $R$ 내에서 수행하는 역할의 이름
- $D$ : $A_i$의 속성, $dom(A_i)$로 표현
- 관계 스키마(Relation Schema)의 속성 개수 $n$을 관계의 차수(degree of relation)라 함
- 예시: 학생(이름, 학번, 나이, 전화번호, GPA)
Relation
- 관계 $r(R)$은 관계 스키마 $R(A_1, \dots ,A_n)$에 따른 튜플(tuple)들의 집합으로 표현
- 각 n-tuple $t$는 각 Attribute의 원소들의 ordered-list(순서가 의미분별적)
- 테이블에서 튜플은 각 행(row), 특성은 각 열(column)
- 특정 튜플 t의 i번째 값은 $t[A_i]$로 표기함
- cartesian product로 수학적 정의 가능
\(r(R) \subseteq dom(A_1) \times \cdots \times dom(A_n)\)
Charicteristics of Relations
- Relation은 집합이기 때문에, 다음과 같은 속성을 가짐
- Distinct Tuples: 모든 튜플은 서로 구별되어야 함 (중복 허용되지 않음).
- Tuple Order Irrelevance: 튜플의 순서는 중요하지 않음.
- 튜플은 속성과 값을 대응시키는 매핑(mapping)으로 표현 가능
- $D = dom(A_i) \cup \dots \cup dom(A_n)$
- $t[A_i]$는 반드시 $dom(A_i)$ 내에 존재
- 따라서 (<속성>, <값>)의 집합으로 볼 수도 있음
- Null 값은 알려지지 않은 값, 적용 불가능한 값 등등 다양한 의미가 있을 수 있음.
- 관계 스키마(Relation schema)는 데이터베이스 내에서 어떤 사실(fact)이 표현될 것인지에 대한 선언(declaration)
- 학생(이름, 학번, GPA) - entity에 대한 사실, 전공(학번, 과) - relation에 대한 사실
Relational Model Constraints
- DB State
- 데이터베이스에 실제로 저장되어 있는 모든 데이터 값의 집합
- DB State에 따라 다양한 제약이 있음
- Model-based Constraints: 모델 자체에 내재한 제약(e.g. 중복 튜플 불허)
- Schema-based Constraints: 데이터 모델 스키마에 명시적으로 기술되는 제약조건
예:- Domain Constraints: 각 속성의 값은 해당 속성의 도메인에 속해야 함.
- Key Constraints: 각 테이블에는 고유한 키가 존재해야 하며, 키는 중복될 수 없음.
- Entity Integrity Constraints: 기본 키(primary key)는 Null 값을 가질 수 없음.
- Referential Integrity Constraints: 외래 키(foreign key)는 참조하는 테이블의 기본 키와 일치하거나 Null이어야 함.
- User-defined Constraints: 사용자가 정의한 추가적인 제약 조건 (e.g., 특정 속성 값의 범위 제한).
- Constraints on Null values: Null값 허용 여부
- Application-based Constraints: 응용 프로그램으로 인한 제약
Key Constraints
- Superkey$(SK)$: 각 튜플을 구별하는 중복되지 않는 속성들의 집합.
- i.e. $t_i[SK] \neq t_j[SK], \forall i,j$
- 예: 학생 테이블에서 {학번}, {이름, 학번}, {이름, 학번, GPA} 등
- Key($K$): Superkey의 최소, $K$에서 하나의 속성이라도 제외한다면, 더이상 Superkey로서의 역할을 할 수 없는 최소집합.
- cf) Key Attribute $\rightarrow$ 키를 구별하는 개별 속성(Key 자체가 아님)
- Candidate Keys: 테이블에서 key가 여러개라면, 각 key는 Candidate가 됨
- 예: “자동차” Relation에서, {번호판 번호}와 {자동차 등록번호} 모두 key가 될 수 있음
- Primary Key: 여러 Candidate Keys 중 하나를 Primary Key로 지정할 수 있음
Relational DB Schema
- 관계형 DB 스키마는 관계 스키마(Relation Schema)들의 집합과 무결성 제약조건(Integrity constraints)을 포함함
- Relational DB Schema $S$
- Relation Schema의 집합 $S = {R_1, \dots R_m}$
- Integrity constraints의 집합 $IC$
- Relational State $D$ of $S$
- 데이터베이스 스키마 $S$에 따라 데이터베이스 상태 $D$는 관계 스키마 $R_1, \dots, R_m$ 각각에 대해 관계 상태 $r_1, \dots, r_m$의 집합으로 정의됨
- $D = {r_1, \dots, r_m}$, 여기서 각 $r_i$는 $R_i$의 관계 상태
- 데이터베이스 상태는 시간에 따라 변경될 수 있음 (삽입, 삭제, 갱신 등)
- 데이터베이스 상태는 항상 무결성 제약 조건을 만족해야 하고, 그렇지 않다면 invalid state로 표현
- Relation에 따라 같은 개념을 설명하는 특성이라도 다른 이름을 가질 수 있고 다른 개념을 설명하는 특성이라도 같은 이름을 가질 수 있음
- 예: 회사(이름, …) 직원(이름, …) - 다른 개념을 설명하는 같은 특성 이름
Entity Integrity & Referential Integrity
Entity Integrity
- Entity Integrity Constraint: 기본 키(primary key)는 Null 값을 가질 수 없음.
- 기본 키는 각 튜플을 고유하게 식별하기 위해 반드시 값이 존재해야 함.
- Null 값은 “알 수 없음” 또는 “적용 불가능”을 의미하므로 기본 키에 허용되지 않음.
Referential Integrity
- Foreign Key(FK)
외래 키(Foreign Key)는 수학적으로 다음과 같이 정의될 수 있음:- 두 관계 $R_1$과 $R_2$가 있을 때, $R_1$의 속성 집합 $FK$가 $R_2$의 기본 키 $PK$를 참조한다고 가정.
- $FK$는 $R_1$의 속성들의 부분 집합이고, $PK$는 $R_2$의 속성들의 부분 집합.
- $FK$가 외래 키가 되기 위한 조건:
- $\forall t_1 \in r(R_1), \exists t_2 \in r(R_2)$ such that $t_1[FK] = t_2[PK]$ or $t_1[FK]$ is NULL.
- 즉, $R_1$의 각 튜플 $t_1$에서 $FK$ 값은 $R_2$의 $PK$ 값과 일치하거나 NULL이어야 함.
- Referential Integrity Constraint: 외래 키(foreign key)는 참조하는 테이블의 기본 키와 일치하거나 Null이어야 함.
- 예를 들어, 학생 테이블의 “학과 코드”가 학과 테이블의 “학과 코드”를 참조하는 경우:
- 학생 테이블의 “학과 코드” 값은 학과 테이블의 “학과 코드” 값 중 하나이거나 NULL이어야 함.
- 외래 키 값이 Null인 경우, 참조 무결성 제약 조건은 적용되지 않음.
- 외래 키 값이 Null이 아닌 경우, 반드시 참조하는 테이블의 기본 키 값과 일치해야 함.
Other types of constraints
- Semantic Integrity constraints
- 데이터의 의미와 관련된 제약 조건으로, 데이터베이스의 논리적 일관성을 유지하기 위해 사용됨.
- 예:
- 특정 속성 값의 범위 제한 (e.g., 나이는 0 이상이어야 함).
- 특정 속성 간의 관계 (e.g., 종료 날짜는 시작 날짜 이후여야 함).
- 특정 조건을 만족해야 하는 데이터 (e.g., 직원의 급여는 최소 임금 이상이어야 함).
- 이러한 제약 조건은 응용 프로그램에서 구현될 수 있음.
- Functional Dependency constraints
- 관계(Relation) 내에서 특정 속성 집합이 다른 속성 집합을 고유하게 결정하는 제약 조건.
- $X \rightarrow Y$: 속성 집합 $X$가 속성 집합 $Y$를 함수적으로 결정한다.
- 즉, $X$의 값이 동일하면 $Y$의 값도 동일해야 함.
- 예: 학생(학번, 이름, GPA)에서 학번 $\rightarrow$ 이름, GPA
- Transition constraints
- 데이터베이스 상태가 한 상태에서 다른 상태로 전환될 때 적용되는 제약 조건.
- 예:
- 계좌 잔액은 음수가 될 수 없음 (출금 시 잔액 확인).
- 주문 상태는 “처리 중”에서 “완료”로만 변경 가능.
- 직원의 직급은 강등될 수 없음.
Dealing with constraints violation
관계형 데이터베이스의 연산에 따라 위반할 수 있는 제약조건이 있음
Insert
- 삽입된 튜플이 모든 제약 조건(Domain Constraints, Key Constraints, Entity Integrity, Referential Integrity)을 만족해야 함.
- Key Constraint 위반: 삽입된 튜플의 기본 키 값이 이미 존재하는 경우, 삽입 거부.
- 예: 학생 테이블에 학번이 123인 학생이 이미 존재하는데, 학번이 123인 새로운 학생을 삽입하려고 할 때.
- Entity Integrity Constraint 위반: 삽입된 튜플의 기본 키 값이 Null인 경우, 삽입 거부.
- 예: 학번이 Null인 학생 데이터를 삽입하려고 할 때.
- Referential Integrity Constraint 위반: 삽입된 튜플의 외래 키 값이 참조하는 테이블의 기본 키 값과 일치하지 않는 경우, 삽입 거부.
- 예: 학생 테이블에 학과 코드가 “CS101”인 데이터를 삽입하려고 하지만, 학과 테이블에 “CS101”이 존재하지 않을 때.
- Domain Constraint 위반: 삽입된 튜플의 속성 값이 해당 속성의 도메인에 속하지 않는 경우, 삽입 거부.
- 예: GPA 속성의 값이 4.3을 초과하거나 음수일 때.
Delete
- 삭제된 튜플이 참조 무결성 제약 조건을 위반할 수 있음.
- Referential Integrity Constraint 위반: 삭제된 튜플이 다른 테이블에서 외래 키로 참조되고 있는 경우, 삭제 거부.
- 예: 학과 테이블에서 “CS101” 학과를 삭제하려고 하지만, 학생 테이블에서 “CS101”을 참조하는 튜플이 존재할 때.
Update
일반 속성을 갱신할 경우
일반 속성(주 키 및 외래 키가 아닌 속성)의 갱신은 제약조건 문제를 일으키지 않음주 키(Primary Key)를 갱신할 경우
주 키의 값 변경은 기존 튜플을 삭제한 후 새로운 튜플을 삽입하는 것과 동일하게 처리해야 함외래 키(Foreign Key)를 갱신할 경우
새로운 외래 키 값이 참조하는 튜플이 반드시 존재하거나 null이어야 함 (참조 무결성 준수 필요)
해당 포스트는 서울대학교 산업공학과 박종헌 교수님의 데이터관리와 분석 25-1학기 강의를 정리한 내용입니다.
This post is licensed under CC BY 4.0 by the author.