[DB] 관계 데이터 모델이란?
관계 데이터 모델 (Relationl Data Model)
개요
릴레이션(Relation)
- 행과 열로 구성된 테이블(Table)을 의미
특성
- 튜플의 유일성: 각 튜플은 고유해야 하며, 동일한 튜플이 두번 나타날 수 없음
- 튜플의 무순서: 릴레이션 내 튜플은 순서가 존재하지 않음 (순서는 중요하지 않음)
- 속성의 무순서: 릴레이션의 속성도 순서가 존재하지 않음
- 속성의 원자성: 각 속성이 더 이상 분해될 수 없는 최소 단위의 값만을 가져야함
관계(Relationship)
- 서로 다른 릴레이션간의 연관성을 나타냄
- 관계형 데이터베이스에서 테이블 간의 관계는 주로 외래키(Foreign Key)를 통해 표현
- 릴레이션 내에서 생성되는 관계: 릴레이션 내 데이터들의 관계
- 릴레이션 간에 생성되는 관계: 릴레이션 간의 관계
릴레이션의 구조
릴레이션 스키마 (Relation Schema)
- 관계형 데이터베이스에서 릴레이션의 구조를 정의
- 릴레이션에 포함될 어트리뷰트와 각 어트리뷰트의 데이터 타입, 어트리뷰트 간의 제약 조건 명시
- 데이터 무결성 유지
- 릴레이션 내포(Relation intension)이라고도 부름
- 정적인 특징
스키마의 요소
- 속성(Attribute): 릴레이션 스키마의 열
- 도메인(Domain): 속성이 가질 수 있는 값의 집합
- 차수(Degree): 속성의 개수
릴레이션 인스턴스 (Relation Instance)
- 특정 시점에 릴레이션에 저장된 데이터의 집합
- 릴레이션 인스턴스는 실제 데이터를 포함
- 데이터에 포함된 모든 튜플의 모음을 나타냄
- 간단히 릴레이션이라 부르거나 릴레이션 외연(Relation Extension)이라고도 부름
- 동적인 특징
인스턴스의 요소
- 튜플(Tuple): 릴레이션의 행
- 카디날리티(Cardinality): 튜플의 수
※ 두 개의 차이점은 릴레이션 스키마는 변하지 않지만, 릴레이션 인스턴스는 삽입,삭제,갱신 등의 조작에 의해 변경될 수 있음
관계 데이터 모델
- 데이터를 2차원 테이블 형태인 릴레이션으로 표현
- 릴레이션에 대한 제약조건(Constraints)과 관계 연산을 위한 관계대수(Relational Algebra)를 정의
무결성 제약
키(Key)
- 특정 튜플을 식별할 때 사용하는 속성 혹은 속성의 집합
- 릴레이션은 중복된 튜플을 허용하지 않기 때문에 각각의 튜플에 포함된 속성들 중 어느하나는 값이 달라야함
- 키가 되는 속성(혹은 속성의 집합)은 반드시 값이 달라서 튜플들을 서로 구별할 수 있어야함
- 키는 릴레이션 간의 관계를 맺는 데도 사용
※ 위 DB를 참조해 Key의 예시를 보시면 이해가 빠릅니다.
슈퍼키(Super Key)
- 튜플을 유일하게 식별할 수 있는 하나의 속성 혹은 속성의 집합
- 튜플을 유일하게 식별할 수 있는 값이면 모두 슈퍼키가 될 수 있음
- 즉 유일성(Uniqueness)의 특성을 만족해야함
고객 릴레이션 예
- 고객번호: 고객별로 유일한 값이 부여되어 있기 때문에 튜플 식별 가능
- 이름: 동명이인이 존재할 경우 튜플을 유일하게 튜플 식별 불가
- 주민번호: 개인별로 갖는 유일한 값이기 때문에 튜플 식별 가능
- 주소: 가족끼리는 같은 정보를 공유하기 하기 때문에 튜플 식별 불가
- 핸드폰: 한 사람이 여러 개의 핸드폰을 사용할 수 있고, 반대로 사용하지 않은 경우도 존재해 튜플 식별 불가
후보키(Candidate Key)
- 튜플을 유일하게 식별할 수 있는 속성의 최소 집합
- 즉 유일성과 최소성(Minimality)을 만족해야함
- 2개 이상의 속성으로 이루어진 키를 복합키(Composite Key)라고 함
주문 릴레이션 예
- 고객번호: 한 명의 고객이 여러 권의 도서를 구입할 수 있으므로 후보키가 될 수 없음
- 도서번호: 도서번호가 2인 '축구아는 여자'는 두 번의 주문 기록이 있으므로 튜플을 유일하게 식별할 수 없음
기본키(Primary Key)
- 여러 후보키 중 하나를 선정하여 대표로 삼는 키
- 후보키가 하나뿐이라면 그 후보키를 기본키로 사용, 여러 개일시 릴레이션의 특성을 반영하여 하나를 선택
기본키 선정 시 고려사항
- 릴레이션 내 튜플을 식별할 수 있는 고유한 값을 가져야 함
- NULL 값은 허용하지 않음
- 키 값의 변동이 일어나지 않아야 함
- 최대한 적은 수의 속성을 가진 것이여야 함
- 향후 키를 사용하는 데 있어서 문제 발생 소지가 없어야 함
※ 릴레이션 스키마를 표현할 때 기본키는 밑줄을 그어 표시
ex) 릴레이션 이름 (속성1, 속성2, ..., 속성N)
대체키(Alternate Key)
- 기본키로 선정되지 않은 후보키
- 위 고객 릴레이션에서는 고객번호와 주민번호 중 고객번호를 기본키로 정하면 주민번호는 대체키가 됨
- 기본키와 동일한 유일성과 최소성의 특성을 가짐
외래키(Foreign Key)
- 다른 릴레이션의 기본키를 참조하는 속성을 의미
- 다른 릴레이션의 기본키를 참조하여 관계 데이터 모델의 특징인 릴레이션 간의 관계(Relationship)를 표현
- 테이블간의 관계를 정의 및 데이터의 일관성과 무결성을 유지
외래키의 특징
- 관계 데이터 모델의 릴레이션 간의 관계를 표현
- 다른 릴레이션의 기본키를 참조하는 속성
- 참조하고(외래키), 참조되는(기본키) 양쪽 릴레이션의 도메인은 서로 같아야함
- 참조되는 값이 변경되는 참조하는 값도 변경됨
- NULL 값과 중복 값 등이 허용됨
- 자기 자신의 기본키를 참조하는 외래키도 가능
- 외래키가 기본키의 일부가 될 수 있음
데이터 무결성(Integrity)
- 데이터베이스에 저장된 데이터의 일관성과 정확성을 지키는것
[표 1] 제약조건의 정리
구분 | 도메인 | 키 | |
도메인 무결성 제약조건 | 개체 무결성 제약조건 | 참조 무결성 제약조건 | |
제약 대상 | 속성 | 튜플 | 속성과 튜플 |
같은 용어 | 도메인 제약 | 기본키 제약 | 외래키 제약 |
해당되는 키 | - | 기본키 | 외래키 |
NULL 값 허용 여부 | 허용 | 불가 | 허용 |
릴레이션 내 제약조건의 개수 |
속성의 개수와 동일 | 1개 | 0 ~ 여러 개 |
기타 | 튜플 삽입/수정 시 제약 사항 우선 확인 | 튜플 삽입/수정 시 제약 사항 우선 확인 | 튜블 삽입/수정 시 제약 사항 우선 확인 부모 릴레이션의 튜플 수정/삭제 시 제약 사항 우선 확인 |
도메인 무결성 (Domain Inegrity Constraint)
- 도메인 제약(Domain Constraint)이라고도 하며, 릴레이션 내의 튜플들이 각 속성의 도메인에 지정된 값만을 가져야 한다는 조건
- SQL 문에서 데이터 형식(Type), 널(NULL), 기본 값(Default), 체크(Check) 등을 사용해 지정
개체 무결성 (Entity Inegrity Constraint)
- 기본키 제약(Primary Key Constraint)이라고도 함
- 릴레이션은 기본키를 지정하고 그에 따른 무결성 원칙 즉, 기본키는 NULL 값을 가져서는 안되며 릴레이션 내에 오직 하나의 값만 존재해야 한다는 조건
개체 무결성 제약조건
- 삽입: 기본키 값이 같으면 삽입이 금지됨
- 수정: 기본키 값이 같거나 NULL로도 수정 금지
- 삭제: 특별한 확인이 필요하지 않으며 즉시 수행
참조 무결성 (Referential Inegrity Constraint)
- 외래키 제약(Foreign Key Constraint)이라고도 함
- 릴레이션 간의 참조 관계를 선언하는 제약조건
- 자식 릴레이션의 외래키는 부모 릴레이션의 기본키와 도메인이 동일해야 함
- 자식 릴레이션의 값이 변경될 때 부모 릴레이션의 제약을 받음
참조 무결성 제약조건
삽입
- 부모 릴레이션: 튜플 삽입 후 수행하면 정상적으로 진행
- 자식 릴레이션: 참조받는 테이블에 외래키 값이 없으므로 삽입이 금지
삭제
- 부모 릴레이션: 참조하는 테이블을 같이 삭제할 수 있어서 금지하거나 다른 추가 작업이 필요
- 자식 릴레이션: 바로 삭제 가능
※ 부모 릴레이션에서 튜플을 삭제할 경우 참조 무결성 조건을 수행하기 위한 고려사항
1. 즉시 작업을 중지
2. 자식 릴레이션의 관련 튜플을 삭제
3. 초기에 설정된 다른 어떤 값으로 변경
4. NULL 값으로 설정
수정
- 삭제와 삽입 명령이 연속해서 수행됨
- 부모 릴레이션의 수정이 일어날 경우 삭제 옵션에 따라 처리된 후 문제가 없으면 다시 삽입 제약조건에 따라 처리됨