릴레이션 (r1)

릴레이션은 집합론에 기반한 수학적 개념으로, 관계형 데이터베이스에서 테이블 형태로 구현된다. 하나의 릴레이션은 기본적으로 속성, 튜플, 도메인이라는 세 가지 핵심 구성 요소로 이루어져 있다.

속성은 릴레이션의 열(Column)에 해당하며, 데이터의 특성이나 종류를 정의한다. 예를 들어, '학생' 릴레이션은 '학번', '이름', '학과' 등의 속성을 가질 수 있다. 각 속성은 허용되는 값의 집합인 도메인을 가지며, 도메인은 속성에 저장될 수 있는 데이터의 타입과 범위를 규정한다. '학번' 속성의 도메인은 정수형 숫자 집합이 될 수 있다.

튜플은 릴레이션의 행(Row)을 의미하며, 속성들의 모임으로 구성된 하나의 레코드이다. 각 튜플은 릴레이션이 표현하는 실세계 객체나 사건에 대한 구체적인 정보를 담고 있다. 릴레이션 내 튜플의 총 수를 카디널리티라고 하며, 속성의 총 수는 차수라고 부른다. 따라서 카디널리티는 행의 개수, 차수는 열의 개수에 해당하는 개념이다.

릴레이션을 구성하는 각 열은 속성이라고 부른다. 속성은 릴레이션이 표현하는 객체나 개념의 특성이나 성질을 정의하며, 데이터베이스 테이블의 열 헤더에 해당한다. 예를 들어, '학생' 릴레이션은 학번, 이름, 학과, 학년 등의 속성으로 구성될 수 있다.

각 속성은 허용되는 값의 집합인 도메인을 가진다. 도메인은 속성에 저장될 수 있는 모든 가능한 값의 타입과 범위를 정의한다. 예를 들어, '학년' 속성의 도메인은 {1, 2, 3, 4}와 같은 정수 집합이 될 수 있고, '이름' 속성의 도메인은 문자열의 집합이 된다. 도메인 정의는 데이터의 무결성을 보장하는 데 중요한 역할을 한다.

릴레이션에서 속성의 개수를 차수라고 한다. 하나의 릴레이션은 고정된 수의 속성을 가지며, 각 튜플은 정확히 그 수만큼의 값을 가져야 한다. 모든 속성은 서로 다른 이름을 가지며, 각 튜플의 값은 해당 속성의 도메인에 속해야 한다는 제약이 있다.

속성과 도메인의 개념은 관계형 데이터 모델의 핵심이며, 이를 통해 데이터의 구조와 의미를 명확히 정의할 수 있다. 이는 이후 관계 대수나 SQL을 이용한 데이터 조작의 기초가 된다.

튜플은 릴레이션을 구성하는 개별적인 행을 의미한다. 각 튜플은 속성에 해당하는 값들의 순서쌍으로 이루어져 있으며, 릴레이션 내에서 하나의 완전한 레코드나 항목을 나타낸다. 예를 들어, '학생' 릴레이션에서 학번, 이름, 학과 등의 속성에 대한 구체적인 값(예: '20230001', '홍길동', '컴퓨터공학과')을 가진 하나의 행이 곧 하나의 튜플에 해당한다. 튜플은 집합론의 원소에 대응되는 개념이다.

카디널리티는 하나의 릴레이션이 포함하고 있는 튜플의 총 개수, 즉 행의 수를 의미한다. 이는 릴레이션의 크기를 나타내는 척도가 된다. 예를 들어, 100명의 학생 정보를 담고 있는 '학생' 릴레이션의 카디널리티는 100이다. 카디널리티는 시간에 따라 변할 수 있으며, 데이터의 삽입, 삭제, 갱신 연산이 수행될 때마다 그 값이 바뀔 수 있다.

튜플과 카디널리티는 릴레이션의 데이터 내용을 기술하는 핵심 요소이다. 차수가 릴레이션의 수직적 구조(열의 수)를 나타낸다면, 카디널리티는 수평적 구조(행의 수)를 나타낸다고 볼 수 있다. 따라서 하나의 릴레이션은 고정된 차수와 변동 가능한 카디널리티를 가지는 튜플들의 집합으로 정의된다.

릴레이션의 가장 기본적인 특성 중 하나는 중복되는 튜플을 포함하지 않는다는 점이다. 이는 릴레이션이 수학적 개념인 집합론의 집합을 기반으로 하기 때문이다. 집합은 동일한 원소를 중복하여 가질 수 없듯이, 릴레이션도 완전히 동일한 값을 가진 행, 즉 튜플을 두 개 이상 가질 수 없다.

이 특성은 데이터의 무결성을 보장하는 데 중요한 역할을 한다. 예를 들어, 한 학생에 대한 정보가 동일한 테이블 내에 여러 번 기록된다면, 정보 갱신 시 일관성을 유지하기 어렵고 저장 공간도 낭비하게 된다. 따라서 모든 튜플은 적어도 하나의 속성 값에서 차이가 나야 하며, 이를 통해 각 튜플을 고유하게 식별할 수 있는 기반이 마련된다.

실제 관계형 데이터베이스에서는 이 특성을 유지하기 위해 기본 키와 같은 제약 조건을 사용한다. 기본 키로 지정된 속성 또는 속성들의 조합은 그 값이 릴레이션 내에서 절대 중복될 수 없으며, 이를 통해 각 튜플의 유일성이 강제된다. 결과적으로 릴레이션은 항상 정규화된 데이터의 집합체로서 기능하게 된다.

릴레이션에서 튜플의 무순서성은 릴레이션이 수학적 집합론에 기반한다는 점에서 비롯된 근본적인 특성이다. 집합의 원소에는 순서가 없듯이, 릴레이션을 구성하는 튜플들 사이에도 특정한 순서가 존재하지 않는다. 이는 릴레이션을 물리적으로 저장하거나 화면에 표시할 때는 특정 순서(예: 입력된 순서, 정렬된 순서)로 나타날 수 있지만, 그 순서는 릴레이션의 논리적 정의나 의미의 일부가 아니라는 것을 의미한다.

예를 들어, 학생 정보를 담은 릴레이션에서 튜플들을 학번 순으로 정렬하여 보여주거나, 이름 순으로 정렬하여 보여주는 것은 가능하다. 그러나 이는 단지 데이터를 조회하는 데 편의를 제공하기 위한 물리적 표현 방식일 뿐이며, 릴레이션 자체는 이러한 순서와 무관하게 동일한 데이터 집합으로 간주된다. 이 특성으로 인해 관계 대수 연산의 결과는 항상 순서가 없는 릴레이션이 되며, 동일한 튜플들을 포함하는 두 릴레이션은 순서가 다르더라도 논리적으로 완전히 동일한 것으로 판단한다.

튜플의 무순서성은 데이터베이스 관리 시스템이 데이터를 물리적으로 저장하고 관리하는 방식에 유연성을 제공한다. 시스템은 성능 최적화를 위해 내부적으로 데이터를 재배열하거나 다른 인덱스 구조를 사용할 수 있으며, 이러한 물리적 변경이 사용자에게 보이는 논리적 데이터 모델에는 영향을 미치지 않도록 보장한다. 이는 데이터의 논리적 독립성을 유지하는 중요한 기반이 된다.

릴레이션에서 속성의 무순서성은 릴레이션을 구성하는 열, 즉 속성들의 순서가 의미를 갖지 않는다는 특성이다. 이는 릴레이션을 수학적 집합론의 개념으로 정의한 결과로, 관계형 데이터 모델의 핵심 원칙 중 하나이다.

구체적으로, 하나의 릴레이션은 속성 이름과 그에 대응하는 도메인의 쌍으로 정의된다. 따라서 릴레이션의 구조는 속성 이름의 집합에 의해 결정되며, 이 속성들을 어떤 순서로 나열하더라도 동일한 릴레이션으로 간주한다. 예를 들어 '학번', '이름', '학과'라는 세 속성으로 이루어진 릴레이션이 있을 때, 열의 순서가 ('학번', '이름', '학과')이든 ('이름', '학과', '학번')이든 그 안에 담긴 데이터의 논리적 의미는 변하지 않는다.

이러한 특성은 RDBMS가 물리적으로 데이터를 저장하거나 사용자에게 표시할 때는 특정 순서를 가질 수 있지만, 논리적 수준에서는 순서에 무관하게 데이터를 조작할 수 있음을 의미한다. 관계 대수 연산 역시 속성의 이름을 기준으로 수행되므로, 속성의 물리적 배열 순서는 연산 결과에 영향을 미치지 않는다. 이는 데이터의 논리적 독립성을 보장하고, 데이터 접근 및 조작의 유연성을 높이는 데 기여한다.

릴레이션에서 원자값이란 더 이상 분해할 수 없는 단일 값을 의미한다. 이는 릴레이션을 구성하는 각 튜플이 각 속성에 대해 오직 하나의 값만을 가져야 함을 규정하는 중요한 특성이다. 예를 들어, '주소' 속성에 '서울시 강남구 역삼동 123'이라는 값이 저장되어 있다면, 이는 '서울시', '강남구', '역삼동', '123'으로 분리되지 않은 하나의 원자값으로 취급된다.

이 원자성은 관계형 데이터베이스 설계의 기본 원리 중 하나로, 데이터의 중복을 방지하고 무결성을 유지하며, 데이터 조작을 명확하게 하는 데 기여한다. 만약 하나의 속성에 여러 값이 저장되면, 데이터 검색이나 갱신 시 복잡성이 증가하고 논리적 오류가 발생할 가능성이 높아진다. 따라서 정규화 과정을 통해 모든 릴레이션이 원자값을 갖도록 구조를 조정하는 것이 일반적이다.

원자값의 개념은 집합론에 기반한 릴레이션의 수학적 정의와도 일치한다. 릴레이션은 튜플의 집합이며, 각 튜플은 순서쌍으로 표현되는데, 이때 각 구성 요소는 나눌 수 없는 단일 값이어야 한다. 이 원칙은 관계 대수 연산이 명확하게 정의되고 효율적으로 수행될 수 있는 토대를 마련해준다.

기본 릴레이션은 관계형 데이터베이스에서 실제로 데이터가 저장되는 물리적인 구조를 가진 릴레이션이다. 이는 사용자가 직접 데이터를 삽입, 수정, 삭제할 수 있는 독립적인 테이블에 해당하며, 데이터베이스의 근간을 이루는 핵심 저장소 역할을 한다. 모든 데이터 조작과 질의는 궁극적으로 이러한 기본 릴레이션에 저장된 데이터를 대상으로 이루어진다.

기본 릴레이션은 일반적으로 데이터 정의 언어를 사용하여 생성되며, 그 구조는 속성의 이름과 도메인으로 정의된 스키마에 의해 결정된다. 데이터는 이 스키마에 따라 튜플의 형태로 지속적으로 저장된다. 시스템 카탈로그에 그 정의가 기록되어 관리되며, 데이터베이스 관리 시스템은 이러한 기본 릴레이션들을 디스크와 같은 저장 장치에 물리적으로 유지한다.

이와 대비되는 개념은 뷰나 스냅샷과 같은 유도된 릴레이션이다. 기본 릴레이션은 이러한 유도 릴레이션의 기반이 되며, 관계 대수 연산을 통한 질의 처리 시 가장 기본적인 피연산자가 된다. 따라서 데이터의 무결성과 성능 최적화를 위한 인덱스는 주로 기본 릴레이션에 적용된다.

뷰 릴레이션은 하나 이상의 기본 릴레이션이나 다른 뷰 릴레이션으로부터 유도된 가상의 릴레이션이다. 이는 실제 데이터를 물리적으로 저장하지 않고, 데이터베이스 관리 시스템이 질의어를 통해 필요한 시점에 동적으로 데이터를 생성하여 보여주는 논리적인 테이블이다. 사용자나 응용 프로그램은 뷰 릴레이션을 마치 실제 테이블처럼 조회하거나, 제한적으로 갱신할 수 있다.

뷰 릴레이션을 생성하는 주요 목적은 데이터 접근을 단순화하고 보안을 강화하는 데 있다. 복잡한 조인이나 선택 연산이 필요한 데이터 조회를 미리 정의된 뷰로 제공함으로써 사용자는 간단한 질의만으로 원하는 결과를 얻을 수 있다. 또한, 기본 릴레이션의 특정 속성이나 튜플만을 포함하는 뷰를 정의하여 민감한 데이터에 대한 접근을 제한할 수 있다. 이는 데이터 무결성과 보안 정책을 구현하는 효과적인 수단이 된다.

뷰는 저장된 데이터가 아니라 질의 정의만을 저장하므로, 기본 릴레이션의 데이터가 변경되면 뷰를 통해 조회할 때마다 최신의 데이터를 반영한다. 그러나 이 특성 때문에 성능상의 고려가 필요할 수 있으며, 일부 관계형 데이터베이스 관리 시스템은 자주 사용되는 뷰의 결과를 물리적으로 저장하는 물리화된 뷰 기능을 제공하기도 한다. 뷰를 통한 데이터 갱신(삽입, 삭제, 수정)은 제한적일 수 있으며, 시스템과 뷰의 정의에 따라 가능 여부가 결정된다.

스냅샷 릴레이션은 특정 시점의 기본 릴레이션의 상태를 고정하여 저장한 릴레이션이다. 이는 데이터베이스의 내용이 시간에 따라 변하더라도, 과거의 특정 순간에 존재했던 데이터의 정적인 복사본을 유지하고자 할 때 사용된다. 주로 데이터 웨어하우스나 데이터 마이닝과 같은 분석 작업에서, 분석의 기준이 되는 시점의 데이터를 일관되게 참조해야 하는 경우에 활용된다.

스냅샷 릴레이션은 생성된 이후로는 일반적으로 갱신되지 않으며, 원본 기본 릴레이션의 변경과 무관하게 자신이 포착한 시점의 데이터를 그대로 유지한다. 이는 뷰 릴레이션이 질의 시점마다 기본 릴레이션으로부터 데이터를 실시간으로 가져오는 가상 테이블인 것과 대비되는 특징이다. 스냅샷은 주기적으로 또는 특정 이벤트 발생 시에 새로 생성되어 갱신될 수 있다.

따라서 스냅샷 릴레이션은 데이터의 역사적 기록을 보존하거나, 자주 변경되는 기본 릴레이션에 대한 복잡한 질의의 성능을 향상시키기 위한 정적 캐시 역할을 하기도 한다. 이는 데이터베이스 관리 시스템이 제공하는 중요한 기능 중 하나로, 데이터의 시간적 추이 분석이나 보고서 생성에 필수적이다.

릴레이션은 관계형 데이터 모델의 핵심적인 구성 요소이다. 이 모델은 데이터베이스를 하나 이상의 릴레이션, 즉 테이블의 집합으로 정의한다. 각 릴레이션은 집합론에 기반한 수학적 개념으로, 데이터를 구조화하고 표현하는 표준화된 방법을 제공한다. 따라서 관계형 데이터 모델에서 모든 데이터는 궁극적으로 릴레이션이라는 형태로 저장되고 관리된다.

릴레이션은 관계형 데이터베이스의 논리적 구조를 형성하는 기본 단위이다. 데이터베이스 설계자는 현실 세계의 정보를 추상화하여 여러 개의 릴레이션으로 나누고, 이들 간의 관계를 정의함으로써 복잡한 데이터를 체계적으로 구성한다. 이렇게 구성된 릴레이션들은 관계 대수나 관계 해석과 같은 연산을 통해 질의되고 조작될 수 있다.

실제 물리적 저장 장치에서는 이러한 논리적 릴레이션이 테이블로 구현된다. 하나의 데이터베이스는 여러 개의 테이블로 구성되며, 각 테이블은 릴레이션의 정의를 충실히 따르는 구조를 가진다. 이는 사용자나 응용 프로그램이 복잡한 저장 구조를 직접 다루지 않고, 일관된 테이블 형태의 인터페이스를 통해 데이터에 접근할 수 있게 해준다.

릴레이션은 관계형 데이터 모델에서 데이터 구조를 정의하는 핵심 개념이다. 이 모델에서는 데이터를 구조적으로 이해하기 위해 스키마와 인스턴스라는 두 가지 수준으로 구분한다.

스키마는 데이터베이스의 청사진 또는 정적 정의에 해당한다. 이는 릴레이션의 이름, 각 속성의 이름, 각 속성이 가질 수 있는 값의 범위인 도메인, 그리고 무결성 제약 조건 등의 정보로 구성된다. 예를 들어, '학생' 릴레이션의 스키마는 학생번호, 이름, 학과 등의 속성과 그들의 데이터 타입을 정의한다. 스키마는 시간이 지나도 변하지 않는 비교적 안정적인 구조를 나타낸다.

반면, 인스턴스는 특정 시점에 릴레이션에 실제로 저장되어 있는 데이터의 집합, 즉 튜플들의 모음을 의미한다. 이는 스키마에 정의된 구조에 따라 채워진 구체적인 데이터 값들로 구성되며, 데이터의 삽입, 삭제, 갱신에 따라 지속적으로 변동된다. 동일한 '학생' 스키마를 가진 릴레이션이라도 현재 시점의 인스턴스와 한 달 후의 인스턴스는 포함된 튜플의 수나 내용이 다를 수 있다.

이러한 구분은 데이터의 논리적 구조와 물리적 내용을 명확히 분리하여, 데이터 독립성을 보장하고 데이터베이스 시스템의 유지보수와 확장을 용이하게 한다. 데이터베이스 관리 시스템은 사용자가 스키마를 통해 데이터에 접근하고 조작할 수 있도록 하며, 내부적으로는 인스턴스를 효율적으로 저장 및 관리한다.

관계 대수는 관계형 데이터베이스에서 릴레이션을 처리하기 위한 이론적 기초를 제공하는 절차적 질의 언어이다. 이는 하나 이상의 릴레이션을 입력으로 받아 새로운 릴레이션을 결과로 출력하는 일련의 연산자들로 구성된다. 관계 대수의 연산은 크게 집합 연산과 순수 관계 연산으로 구분된다. 집합 연산은 합집합, 교집합, 차집합, 카티전 프로덕트와 같이 집합론에서 유래한 연산이며, 순수 관계 연산은 릴레이션의 구조에 특화된 셀렉트, 프로젝트, 조인, 디비전 등의 연산을 포함한다.

관계 대수의 가장 큰 특징은 폐쇄성을 가진다는 점이다. 이는 모든 연산의 입력과 출력이 모두 릴레이션이므로, 연산 결과에 대해 다시 다른 연산을 적용하는 것이 가능함을 의미한다. 이러한 특성 덕분에 복잡한 질의도 여러 기본 연산을 조합하여 표현할 수 있다. 예를 들어, 특정 조건을 만족하는 튜플을 추출하는 셀렉트 연산과 원하는 속성만을 선택하는 프로젝트 연산을 결합하여 필요한 데이터를 구성할 수 있다.

실제 데이터베이스 관리 시스템에서 사용되는 SQL과 같은 질의 언어는 관계 대수(및 관계 해석)의 개념 위에 구축되어 있다. 사용자가 작성한 SQL 문은 내부적으로 관계 대수의 연산들로 변환되어 최적화되고 실행된다. 따라서 관계 대수를 이해하는 것은 데이터베이스의 질의 처리 원리를 파악하고 효율적인 질의를 작성하는 데 필수적인 기초 지식이 된다.

관계 해석은 관계형 데이터베이스에서 원하는 데이터를 선언적으로 기술하는 비절차적 질의 언어의 수학적 기초이다. 관계 대수가 연산자(셀렉트, 프로젝트, 조인 등)를 조합하여 결과를 얻는 방법을 명시하는 절차적 방식이라면, 관계 해석은 결과 릴레이션에 포함될 튜플이 만족해야 하는 조건(술어)을 논리식으로 표현하는 선언적 방식이다. 사용자는 '무엇(What)'을 원하는지만 기술하면 되며, 시스템이 '어떻게(How)' 그 결과를 얻을지는 결정한다. 관계 해석은 튜플 관계 해석과 도메인 관계 해석으로 크게 구분된다.

튜플 관계 해석은 튜플 변수를 사용하여 질의를 표현한다. 예를 들어, '급여가 5000 이상인 모든 사원의 이름을 찾아라'라는 질의는 { t.이름 | 사원(t) AND t.급여 >= 5000 }과 같은 형태로 표현할 수 있다. 여기서 t는 사원 릴레이션의 튜플을 나타내는 변수이며, | 기호 오른쪽의 조건을 만족하는 튜플 t의 이름 속성 값들로 구성된 집합이 결과가 된다. 이때 존재 한정자나 전칭 한정자 같은 술어 논리의 개념을 활용해 복잡한 조건을 표현할 수 있다.

도메인 관계 해석은 튜플 변수 대신 도메인 변수를 사용한다. 동일한 질의를 도메인 관계 해석으로 표현하면 { <이름> | ∃ 급여 ( 사원(이름, 급여, ...) AND 급여 >= 5000 ) }과 같은 형태가 될 수 있다. 이는 속성 값 자체를 변수로 다루며, 때로는 표현이 더 직관적일 수 있다. 관계 해석의 표현력은 관계 대수와 동등하며, 이는 코드의 정리에 의해 증명되었다. 대부분의 현대 SQL은 관계 해석의 선언적 특성을 강하게 반영하고 있어, 사용자가 복잡한 데이터 접근 경로를 고려하지 않고도 직관적으로 질의를 작성할 수 있게 한다.