[DB 이론] 관계 데이터 모델

이 글은 데이터베이스 개론 (저자 김연희)의 내용을 개인적으로 정리하는 글임을 알립니다.

---

관계 데이터 모델의 개념

관계 데이터 모델의 기본 용어

Entiti, Table, Relation

엔터티 = 테이블 = 릴레이션으로 통칭해서 사용되기도 한다.

DB의 설계 단계에서는 엔터티(Entity), DBMS로 구현되는 단계에서는 테이블(Table), 개념 단계에서 엔터티 간 연관관계를 릴레이션(Relation)이라고 한다.

엔티티 > 테이블 > 릴레이션 순으로 보면된다.
모든 릴레이션은 테이블이지만, 모든 테이블이 릴레이션인 것은 아니다.
모든 테이블은 엔티티이지만, 모든 엔티티가 테이블인것은 아니다.

관계 데이터 모델에서는 하나의 개체에 관한 데이터를 릴레이션(relation) 하나에 담아 데이터 베이스에 저장한다.

관계형 데이터베이스에서의 "릴레이션"은 데이터베이스 테이블의 구조를 설명하는 데 사용되는 개념이다.
릴레이션 (Relation): 관계형 데이터베이스에서 릴레이션은 테이블을 나타낸다.
테이블은 행과 열로 이루어진 데이터 구조이다. 각 테이블은 여러 개의 열(속성 또는 필드)과 이에 해당하는 데이터 레코드(행)로 구성된다.
이러한 행과 열의 집합은 릴레이션으로 간주된다.

 

Attribute (열)

릴레이션의 열(column)을 속성 또는 애트리뷰트(attribute)라고 부른다.

각 속성은 서로 다른 이름을 이용해 구별한다.

릴레이션은 파일 시스템에서의 파일, 속성은 해당 파일의 필드(field)에 대응하는 개념이다.

 

Tuple (행)

릴레이션의 행을 튜플(tuple)이라 부른다.

튜플은 개체의 인스턴스다.

튜플은 파일 시스템에서의 파일의 레코드(record)에 대응하는 개념이다.

 

Domain

속성 하나가 가질 수 있는 모든 값의 집합을 해당 속성의 도메인(domain)이라 한다.

예를 들어 학년 속성의 데이터 타입이 정수형이고 해당 속성에서 취할 수 있는 값의 범위가 1~4까지 라면, 1~4라는 범위는 해당 속성에 지정된 정수형의 모든 범위가 아니라 일부분이므로 사용자는 1~4까지의 범위를 해당 속성의 도메인으로 정의해서 사용할 수 있다는 의미이다.

즉, 도메인은 각 속성이 가질 수 있도록 허용된 값들의 집합이다.

테이블의 컬럼 값을 구성할 때 값의 범위, 데이터타입, 제약사항 등을 설정하는데 그 범위 값의 설정을 도메인이라 생각하면 된다.

 

NULL 값

릴레이션에 있는 특정 튜플의 속성 값을 모르거나, 적합한 값이 없는 경우에는 널이라는 특별한 값을 사용할 수 있다.

널 값은 특정 속성에 해당되는 값이 없음을 나타내므로 숫자 0이나 공백 문자와는 다르다.

 

Degree (차수)

하나의 릴레이션에서 속성의 전체 개수를 릴레이션의 차수라고 한다.

모든 릴레이션은 최소 1 이상의 차수를 유지해야 한다.

릴레이션의 차수는 일반적으로 자주 변하지 않는다는 정적인 특징이 있다.

 

Cardnality(카디널리티)

하나의 릴레이션에서 튜플의 전체 개수를 릴레이션의 카디널리티라고 한다.

튜플이 없는 릴레이션이 존재할 수도 있다.

릴레이션의 카디널리티는 일반적으로 자주 변한다는 동적인 특징이 있다.

 

릴레이션과 데이터베이스의 구성

관계 데이터 모델에서 릴레이션은 릴레이션 스키마와 릴레이션 인스턴스로 구성되어 있다.

릴레이션 스키마

릴레이션 스키마(relation schema)는 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조다.

릴레이션 스키마는 DBMS가 내부적으로 데이터 정의어를 이용해 정의하지만, 일반적으로는 아래와 같은 형태로 쉽게 표현한다.

릴레이션 스키마는 릴레이션 내포(relation intension)라고 부른다.

 

릴레이션 인스턴스

릴레이션 인스턴스(relation instance)는 어느 한 시점에 릴레이션에 존재하는 튜플들의 집합이다.

릴레이션 인스턴스에 포함된 튜플은 릴레이션 스키마에서 정의하는 각 속성에 대응하는 실제 값으로 구성되어 있다.

릴레이션 인스턴스를 보면 현재 릴레이션의 실제 내용을 쉽게 파악할 수 있다.

릴레이션 인스턴스는 간단히 릴레이션이라 부르기도 하고 릴레이션 외연(relation extension)이라고도 부른다.

 

데이터베이스 스키마와 데이터베이스 인스턴스

일반적으로 데이터베이스는 릴레이션 여러 개로 구성된다.

데이터베이스의 전체 구조를 의미하는 데이터베이스 스키마는 데이터베이스를 구성하는 릴레이션의 스키마를 모아놓은 것이다.

즉, 특정 데이터베이스 스키마를 설계한다는 것은 모든 필요한 릴레이션의 스키마를 모두 정의한다는 뜻이다.

데이터베이스 인스턴스는 어느 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합을 의미한다.

즉, 데이터베이스를 구성하는 모든 릴레이션의 인스턴스를 모아놓은 것이다.

 

릴레이션의 특성

튜플의 유일성

하나의 릴레이션에는 동일한 튜플이 존재할 수 없다.

하나의 릴레이션에 똑같은 튜플이 있으면 안 되고, 모든 튜플에는 다른 튜플과 구별되는 유일한 특성이 있어야 한다.

릴레이션을 튜플의 모임인 집합의 개념으로 이해한다면, 하나의 집합에 동일한 원소가 존재할 수 없다는 특성과 연관 지어 생각할 수 있다.

튜플을 유일하게 구별하기 위해 선정하는 속성(또는 속성들의 모임)을 키(key)라고 부른다.

 

튜플의 무순서

하나의 릴레이션에서 튜플 사이의 순서는 무의미하다.

튜플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 튜플 내용이 같아야 같은 릴레이션이다.

데이터베이스는 위치가 아닌 내용으로 검색되므로 튜플의 순서는 중요하지 않다.

릴레이션에는 튜플이 삽입 순서에 따라 저장되지만, 효율적인 처리를 위해 튜플의 순서를 임의로 바꾸기도 한다.

 

속성의 무순서

하나의 릴레이션에서 속성 사이의 순서는 무의미하다.

속성은 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어 있어야 같은 릴레이션이다.

 

속성의 원자성

모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있다.

하나의 속성은 여러 개의 값, 즉 다중 값을 가질 수 없다.

위와 그림과 같은 고객 릴레이션은 회사원, 학생과 같이 값이 여러 개인 직업 속성을 포함하므로 관계 데이터 모델의 릴레이션으로 적합하지 않다.

물론 현실에서는 직업이 둘 이상인 고객이 존재할 수 있지만, 관계 데이터 모델은 이런 복잡한 개념을 배제하고 릴레이션을 단순한 구조로 정의하고자 하는 특징이 있어 다중 값을 허용하지 않는다.

 

키의 종류

튜플을 유일하게 구별하기 위해 모든 속성을 이용하는 것보다 일부 속성만 이용하는 것이 효율성을 높일 수 있다.

릴레이션에 포함된 튜플들을 유일하게 구별해주는 역할은 속성 또는 속성들의 집합인 키가 담당한다.

키는 관계 데이터 모델에서 중요한 제약조건을 정의한다.

• 유일성 : 하나의 릴레이션에서 키로 지정된 속성 값은 튜플마다 달라야 한다는 특성
• 최소성 : 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성

 

관계 데이터 모델에서는 키를 아래와 같이 슈퍼키, 후보키, 기본키, 대체키, 외래키의 다섯 가지로 분류할 수 있다.

 

슈퍼키(Super Key)

슈퍼키는 유일한 특성을 만족하는 속성 또는 속성들의 집합이다.

유일성은 키가 갖추어야 하는 기본 특성으로, 하나의 릴레이션에서 키로 지정된 속성 값은 튜플마다 달라야 한다는 의미다.

즉, 키 값이 같은 튜플은 존재할 수 없다.

 

후보키(Candidate Key)

후보키는 유일성과 최소성을 만족하는 속성 또는 속성들의 집합이다.

최소성은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이다.

그러므로 하나의 속성으로 구성된 키는 당연히 최소성을 만족한다.

 

기본키(Primary Key)

릴레이션에서 튜플을 구별하기 위해 여러 개의 후보키를 모두 사용할 필요는 없다.

데이터베이스 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 하는 데 이것이 기본 키다.

만약, 후보키가 1개만 존재한다면 당연히 해당 후보키를 기본키로 선택해야 하겠지만 여러 개일 경우에는 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 된다.

선택한 기본키는 속성 이름에 밑줄을 그어 표현한다.

후보키 중에서 기본키를 선택하는 기준은 아래와 같다.

• 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
• 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
• 단순한 후보키를 기본키로 선택한다.

 

대체키(Alternate Key)

대체키는 기본키로 선택되지 못한 후보키다.

대체키는 기본키를 대신할 수 있지만 기본 키가 되지 못하고 탈락한 이유가 있을 수 있다.

 

외래키(Foreign Key)

외래키는 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키다.

즉, 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키다.

외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요하다.

외래키가 다른 테이블의 대체키를 참조하는 것도 가능하다.
기본키로 선택받지 못했지만 유일성과 최소성을 만족하는 대체키를 참조하더라도 관련 있는 튜플을 구분할 수 있기 때문이다.

 

하나의 릴레이션에는 외래키가 여러 개 존재할 수도 있다.

외래키를 기본키로 사용할 수도 있고 외래키를 포함하여 기본키를 구성할 수도 있다.

외래키가 다른 릴레이션의 기본키를 참조하는 키라고 정의했지만 반드시 다른 릴레이션을 참조할 필요는 없다.

참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있다.

즉, 외래키 자신이 속한 릴레이션의 기본키를 참조하도록 외래키를 정의할 수도 있다.

외래키는 다른 릴레이션의 기본키를 참조하지만 이 릴레이션에서는 기본키가 아니기 때문에 널 값을 가질 수 있다.

 

관계 데이터 모델의 제약 

관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건이다.

무결성은 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태를 말한다.

무결성 제약조건의 주요 목적은 데이터 베이스에 저장된 데이터의 무결성을 보장하고, 데이터베이스의 상태를 일관되게 유지하는 것이다.

데이터베이스가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.

 

관계 데이터 모델이 기본으로 포함하고 있는 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있다.

데이터 베이스의 상태를 일관성 있게 유지하기 위해서는 두 가지를 모두 만족시켜야 한다.

 

개체 무결성 제약조건(Entity Integrity Constraint)

개체 무결성 제약 조건은 기본키를 구성하는 모든 속성은 널 값을 가지면 안 된다는 규칙이다.

아래의 고객 릴레이션은 개체 무결성 제약조건을 위반한 예가 된다.

그러므로 이 상태의 릴레이션은 실제로 존재할 수 없다.

개체 무결성 제약조건을 만족시키려면 새로운 튜플이 삽입되는 연산과 기존의 튜플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부하면 된다.

새로운 튜플(레코드)이 삽입되는 경우
기본키 속성에 널(null) 값이 포함된 새로운 행을 추가하려고 할 때, 데이터베이스는 이 작업을 거부해야 한다.
즉, 기본키는 널 값을 허용하지 않으므로 새로운 레코드가 추가될 때 기본키 속성에는 반드시 유효한 값이 포함되어야 한다.

기존의 튜플(레코드)의 기본키 속성 값이 변경되는 경우
이미 존재하는 레코드의 기본키 속성 값이 널(null)이거나 변경될 때, 이 변경 작업은 거부되어야 한다.
기본키는 해당 레코드를 고유하게 식별하는 데 사용되므로, 기본키 속성은 항상 유효한 값을 가져야 하며, 변경되는 과정에서 널 값이 들어가면 안 된다.

즉, 개체 무결성을 유지하기 위해서는 기본키 속성에 널(null) 값을 허용하지 않고, 새로운 레코드 삽입 또는 기존 레코드의 기본키 속성 값 변경 시에 이를 감지하고 거부하는 것이 중요하다.

이것은 일반 사용자가 직접 수행하기보다는 DBMS가 자동으로 수행하므로 새로운 릴레이션을 생성할 때마다 기본키를 어떤 속성들로 구성할 것인지 DBMS에게 알려주면 된다.

 

참조 무결성 제약조건(Referential Integrity Constraint)

개체 무결성 제약조건이 기본키에 대한 규칙으로 각 릴레이션마다 적용된다면, 참조 무결성 제약조건은 외래키에 대한 규칙으로 연관된 릴레이션들에 적용된다.

참조 무결성 제약조건이란 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙이다.

외래키는 다른 릴레이션의 기본키를 참조하는 속성이고 릴레이션 간의 관계를 표현하는 역할을 한다.

그런데 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어진다.

그러므로 외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.

아래의 그림은 참조 무결성 제약조건을 위반한 예이다.

 

외래키가 널 값을 가진다고 해서 참조 무결성 제약조건을 위반했다고 말할 수 없다.

위 그림에서 주문고객 속성 값이 널이라는 것은 주문한 고객이 누구인지 모를 뿐, 고객 릴레이션에 존재하지 않는 고객이 주문한 것으로 판단하기는 어렵기 때문이다.

 

또한 참조 릴레이션에 존재하는 튜플을 삭제하는 연산은 참조 무결성 제약 조건을 위반하지 않는 경우에만 수행한다.

위 그림을 예로 들면, 고객 릴레이션의 apple이라는 아이디를 가진 고객을 삭제해 버리면 주문 릴레이션의 주문고객의 apple가 null로 바뀌어 버린다. 이는 참조 무결성 제약조건을 위반한 것이다.

 

마지막으로 참조 릴레이션에 존재하는 기본키의 속성 값이 변경될 때 참조 무결성 제약 조건을 위반하지 않는지 확인해야 한다.

위 그림을 예로 들면, 고객 릴레이션의 기본키인 고객 아이디 속성의 값을 바꾸면 주문 릴레이션에 원래의 속성 값으로 남아 있게 된다. 이는 참조 무결성 제약조건을 위반한 것이다.

이럴 때는 변경 연산을 수행하지 않거나, 주문 릴레이션에 남아 있는 관련 튜플에서 주문고객 속성의 값을 새로운 값으로 함께 변경해야 참조 무결성 제약조건을 만족시킬 수 있다.