[DB] 2. 관계 데이터 모델

벌써 취업한지 2달이 지나갑니다! 프론트엔드 개발자로 입사했는데, Django도 함께 개발하고 있어서 백엔드에 대한 경험이 부족하다보니 개발하는데 어려움을 느끼고 있습니다. 그래서 당분간 1일 1블로그를 하면서 백엔드 개발 지식을 넓혀나가기로 했습니다.

현재 게시글은 위 블로그의 글을 요약한 것입니다.

1. 관계 데이터 모델의 개념

[릴레이션]

릴레이션 : 행과 열로 구성된 테이블
속성(Attribute) : 세로 값으로 열(Column)이라고도 한다
튜플(Tuple): 가로 값으로 행(Row)이라고도 한다
차수: 속성의 수
카디날리티: 튜플의 수
인스턴스: 정의된 스키마에 따라 테이블에 실제 저장된 데이터의 집합
스키마: 릴레이션이 어떻게 구성되는지 어떤 정보를 담고있는지에 대한 기본적 구조 (첫 행의 헤더)

[스키마의 구성요소]

속성(Attribute): 릴레이션 스키마의 열
도메인(Domain): 속성이 가질 수 있는 값의 집합
차수(Degree): 속성의 개수

그림에서 속성은 도서번호, 도서이름, 출판사, 가격

차수는 4

도메인은 Interger, Varchar(10)과 같은 값이 가질 수 있는 범위 및 집합을 의미한다

(속성1: 도메인1, 속성2: 도메인2...) 이런식으로 표기하지만 일반적으로는 릴레이션 이름과 속성만 적어서 도서(도서번호, 도서이름, 출판사, 가격)과 같이 표현

[인스턴스의 구성요소]

튜플(Tuple): 릴레이션의 행
카디날리티(Cardinality): 튜플의 수

튜플이 가지는 속성의 개수는 릴레이션 스키마의 차수와 동일하다

릴레이션 내의 모든 튜플은 서로 중복되지 않아야한다

ex) 튜플이 이름: '홍길동', 성별: '남자', 연락처: '010-1234-5678'과 같이 3개의 속성을 가지면 릴레이션 스키마 역시도 3개의 차수를 가져야 하며, 한 릴레이션 내에서 '홍길동', 성별: '남자', 연락처: '010-1234-5678'이 같은 내용으로 두번 나오면 안된다

[릴레이션 특징]

속성은 단일 값을 가진다
속성은 서로 다른 이름을 가진다
한 속성의 값은 모두 같은 도메인 값을 가진다
속성의 순서는 상관 없다
릴레이션 내의 중복된 튜플은 허용하지 않는다
튜플의 순서는 상관없다

위 릴레이션에서 하나의 책은 하나의 가격을 가져야지, 7000, 8000 과 같이 2개 값을 동시에 가질 수 없습니다

이것을 쪼개지지 않는 하나의 값만 가진다 하여 원자값을 가진다고도 얘기합니다

또한 한 릴레이션 내에서 이름, 이름, 이름과 같이 동일한 속성이름은 올 수 없고

가격이 정수의 값을 가진다면 가격에는 '칠천원'같이 VARCHAR형태 값이 올 수는 없습니다.

속성의 순서나 튜플의 순서는 무관하고 금림에서 보이듯 모든 속성의 값이 동일한 튜플은 한 릴레이션내에 존재할 수 없습니다.

[관계 데이터 모델]

릴레이션
제약조건
관계대수

관계 데이터 모델은 데이터를 2차원 테이블 형태인 릴레이션으로 표현한 것으로 릴레이션에 대한 제약조건(Constraints)와 관계 연산을 위한 관계대수(Algerbra)를 정의했습니다.

이런 관계 데이터 모델을 컴퓨터에 구현하면 관계 데이터베이스 시스템이 됩니다.

2. 무결성 제약조건

[키(Key)]

특정 튜플을 식별할 떄 사용하는 속성 혹은 속성의 집합
키가 되는 속성(혹은 속성의 집합)은 값이 반드시 달라 튜플들을 구별할 수 있어야한다
키는 릴레이션간의 관계를 맺는데 사용됨

한 릴레이션에서 중복되는 튜플들은 존재할 수 없다. 그러므로 각각의 튜플에 포함된 속성들 중 어느 하나(혹은 하나이상)은 값이 달라져야하고, 각가의 튜플을 식별하는 역할을 키(Key)가 담당한다

키는 단일 속성으로 지정하지만 아래 그림처럼 그렇지 못한경우 두개 이상의 속성을 묶어 키로 사용하기도 한다

(고객번호, 도서번소) or (고객번호, 주문일자)와 같은 집합을 키로 사용할 수 있다

[슈퍼키]

튜플을 유일하게 식별할 수 있는 하나 속성 혹은 속성의 집합

튜플을 식별할 수 있으면 모두 슈퍼키가 될 수 있다.

아래는 고객번호 혹은 주민번호를 포함한 모든 속성의 집합이 슈퍼키가 될 수 있다.

(주민번호), (주민번호, 이름), (고객번호, 이름, 주민번호, 주소, 핸드폰) 등 여러개가 슈퍼키가 될 수 있다

[후보키]

튜플을 유일하게 식별할 수 있는 속성의 최소 집합

아래는 단일 속성으로는 튜플을 유일하게 식별하는 것이 불가능하므로 2개 속성을 합한(고객번호, 도서번호)가 후보키가 되며, 이렇게 2개 이상의 속성으로 이루어진 키를 복합키(Composite Key) 라고 한다

[기본키]

여러 후보키들 중 하나 선정해 대표로 삼는 키

후보키가 하나뿐이라면 그 후보키를 기본키(Primary Key)로 사용하면되고,

후보키가 여러개라면 릴레이션의 특성을 반영해 하나를 선택하면 된다

아래 그림에서 도서번호 혹은 도서 이름이 후보키가 되고 두 속성 중 하나의 속성을 기본키로 선정 (도서 이름 중복되지 않는다 가정)

릴레이션 스키마 표현할 때 기본키는 밑줄을 그어 표시한다

도서 릴레이션의 경우 도서(도서번호, 도서이름, 출판사, 가격) 으로 표시

[기본키 선정시 고려사항]

릴레이션 내 튜플을 식별할 수 있는 고유한 값을 가져야함
NULL값은 허용안함
키 값의 변동이 일어나지 않아야함
최대한 적은 수의 속성을 가진것이어야함
향후 키를 사용하는데 있어 문제 발생 소지가 없어야함

[대체키]

기본키로 선정되지 않은 후보키

대체키 (Alternate Key)는 기본키로 선정되지 않은 후보키로 고객 릴레이션에서 고객번호와 주민번호 중 고객 번호를 기본키로 정하면 주민번호가 대체키가 된다

[외래키]

다른 릴레이션의 기본키를 참조하는 속성

키는 관게를 맺는데 활용될 수 있다 했는데, 외래키(Foreign Key)가 바로 그런 경우다

주문 릴레이션에서 우리는 고객 릴레이션의 기본키인 고객번호와 도서 릴레이션의 기본키인 도서 번호를 참조하여 쓰는데, 주문 릴레이션에서는 고객번호와 도서번호가 외래키가 되고 주문번호가 기본키가 됩니다.

외래키를 사용할 때 참조하는 릴레이션과 참조되는 릴레이션이 다를 필요는 없다

즉, 한 릴레이션에서 자기 자신의 기본키를 외래키로도 가질 수 있다.

아래 그림에서 선수번호라는 기본키를 가진 자기 자신의 릴레이션에서 멘토번호로 참조하고 있다

멘토 릴레이션에는 이미 선수번호라는 기본키가 존재하기 때문에 외래키는 NULL값이 되어도 상관없다

[요약]

[무결성 제약조건]

데이터 무결성(Integrity)은 데이터베이스에 저장된 데이터의 일관성과 정확성을 지키는 것을 말한다
도메인 무결성 제약조건
1. 도메인 제약(Domain Constraint)라고도 함
2. 릴레이션 내의 튜플들이 각 속성의 도메인에 지정된 값만을 가져야한다는 조건
개체 무결성 제약조건
참조 무결성 제약조건