관계형 모델

관계형 모델(relational model, RM)은 1차 술어 논리와 일치하는 구조 및 언어를 사용하여 데이터를 관리하는 접근 방식이다. 1969년 영국의 컴퓨터 과학자 에드거 F. 코드가 처음으로 기술하였으며,^[1]^[2] 모든 데이터는 튜플의 관점에서 표현되고 관계(릴레이션)로 그룹화된다. 관계형 모델에 따라 구성된 데이터베이스를 관계형 데이터베이스라고 한다.

관계형 모델의 목적은 데이터와 질의를 지정하기 위한 선언적 방법을 제공하는 것이다. 사용자는 데이터베이스에 어떤 정보가 포함되어 있는지, 그리고 데이터베이스에서 어떤 정보를 원하는지 직접 기술하며, 데이터를 저장하기 위한 데이터 구조를 기술하고 질의에 응답하기 위한 검색 절차를 처리하는 일은 데이터베이스 관리 시스템 소프트웨어가 맡는다.

대부분의 관계형 데이터베이스는 SQL 데이터 정의 및 질의 언어를 사용하며, 이러한 시스템은 관계형 모델에 대한 공학적 근사치로 간주될 수 있는 것을 구현한다. SQL 데이터베이스 스키마의 테이블은 술어 변수에 해당하고, 테이블의 내용은 관계에 해당하며, 키 제약 조건, 기타 제약 조건 및 SQL 질의는 술어에 해당한다. 그러나 SQL 데이터베이스는 여러 세부 사항에서 관계형 모델을 벗어나며, 에드거 F. 코드는 원래의 원칙을 훼손하는 일탈에 대해 격렬하게 반대했다.^[3]

역사

관계형 모델은 에드거 F. 코드에 의해 데이터의 일반 모델로 개발되었으며, 이후 크리스토퍼 J. 데이트와 휴 다르웬 등에 의해 홍보되었다. 1995년 발행된 《제3의 매니페스토》(The Third Manifesto)에서 데이트와 다르웬은 관계형 모델이 특정 "바람직한" 객체 지향 기능을 어떻게 수용할 수 있는지 입증하려고 시도했다.^[4]

확장

1970년 모델을 발표한 지 몇 년 후, 코드는 누락된 정보를 처리하기 위해 3치 논리(참, 거짓, 누락/NULL) 버전을 제안했으며, 1990년 저서 《관계형 데이터베이스 관리를 위한 모델 버전 2》(The Relational Model for Database Management Version 2)에서는 4치 논리(참, 거짓, 누락되었으나 적용 가능함, 누락되었으며 적용 불가능함) 버전으로 한 단계 더 나아갔다.^[5]

개념화

기본 개념

관계는 헤딩(heading)과 바디(body)로 구성된다. 헤딩은 이름과 데이터 유형(때로는 도메인이라고 함)을 가진 속성 집합을 정의한다. 이 집합의 속성 개수는 관계의 차수이다. 바디는 튜플의 집합이다. 튜플은 n개 값의 모음이며, 여기서 n은 관계의 차수이고 튜플의 각 값은 고유한 속성에 대응한다.^[6] 이 집합에 포함된 튜플의 개수는 관계의 카디널리티이다.^[7]^: 17–22

관계는 재할당이 가능한 관계 변수 또는 릴바(relvar)로 표현된다.^[7]^: 22–24 데이터베이스는 릴바의 집합이다.^[7]^{: 112–113}

이 모델에서 데이터베이스는 정보 원칙을 따른다. 즉, 특정 시점에 데이터베이스의 모든 정보는 오직 릴바에 의해 식별되는 관계 내에서 속성에 대응하는 튜플 내부의 값으로만 표현된다.^[7]^: 111

제약 조건

데이터베이스는 임의의 부울 식을 제약 조건으로 정의할 수 있다. 모든 제약 조건이 참으로 평가되면 데이터베이스는 일관성이 있는 상태이며, 그렇지 않으면 일관성이 없는 상태이다. 데이터베이스 릴바의 변경이 데이터베이스를 일관성이 없는 상태로 남겨둔다면, 그 변경은 유효하지 않으며 성공해서는 안 된다.^[7]^: 91

일반적으로 제약 조건은 관계 비교 연산자를 사용하여 표현되며, 이론적으로는 "부분집합이다"(⊆) 하나만으로도 충분하다.^[8]

제약 조건의 두 가지 특수한 사례는 키와 외래 키로 표현된다.

키

후보 키, 또는 간단히 키는 관계의 각 튜플을 고유하게 구별할 수 있도록 보장하는 속성의 가장 작은 부분집합이다. 관계의 각 튜플은 고유해야 하므로 모든 관계는 반드시 키를 가지며, 이는 속성의 전체 집합이 될 수도 있다. 각 튜플을 고유하게 구별하는 방법이 여러 가지가 있을 수 있으므로 하나의 관계는 여러 개의 키를 가질 수 있다.^[7]^: 31–33

속성이 키가 아니더라도 튜플 간에 고유할 수 있다. 예를 들어, 회사의 직원을 설명하는 관계에 ID와 이름이라는 두 가지 속성이 있을 수 있다. 현재 이름이 같은 직원이 없더라도 나중에 현재 직원과 같은 이름을 가진 새 직원을 고용할 가능성이 있다면 속성 부분집합 {이름}은 키가 아니다. 반대로 부분집합 {ID}가 키라면, 이는 현재 직원 중에 ID를 공유하는 사람이 없을 뿐만 아니라 앞으로도 ID를 공유할 직원이 없을 것임을 의미한다.^[7]^: 31–33

외래 키

외래 키는 관계 R₁의 속성 부분집합 A로서 다른 관계 R₂의 키에 대응하며, A에 대한 R₁의 투영이 A에 대한 R₂의 투영의 부분집합인 특성을 가진다. 즉, R₁의 튜플이 외래 키에 대한 값을 포함하고 있다면, 해당 키에 대해 동일한 값을 포함하는 대응 튜플이 R₂에 반드시 존재해야 한다.^[7]^: 34

관계 연산

사용자(또는 프로그램)는 질의를 보내 관계형 데이터베이스에 데이터를 요청한다. 질의에 대한 응답으로 데이터베이스는 결과 집합을 반환한다.

종종 조인을 수행하여 여러 테이블의 데이터를 하나로 결합한다. 개념적으로 이는 모든 가능한 행의 조합(곱집합)을 취한 다음, 정답을 제외한 나머지를 걸러내는 방식으로 수행된다.

조인 외에도 여러 가지 관계 연산이 있다. 여기에는 투영(일부 컬럼을 제거하는 과정), 선택/제한(일부 로우를 제거하는 과정), 합집합(구조가 유사한 두 테이블을 결합하는 방법), 차집합(한 테이블에는 있지만 다른 테이블에는 없는 행을 나열), 교집합(두 테이블 모두에 있는 행을 나열), 그리고 위에서 언급한 곱집합(한 테이블의 각 행을 다른 테이블의 각 행과 결합)이 포함된다. 참고하는 자료에 따라 세미 조인, 외부 조인 및 외부 합집합과 같은 외부 연산자, 그리고 다양한 형태의 나눗셈 등 많은 다른 연산자가 존재할 수 있다. 또한 컬럼 이름을 바꾸는 연산자, 요약 또는 집계 연산자가 있으며, 관계 값을 속성으로 허용하는 경우(관계값 속성) 그룹화 및 그룹 해제와 같은 연산자도 있다.

관계형 데이터베이스의 유연성 덕분에 프로그래머는 데이터베이스 설계자가 예상하지 못한 질의를 작성할 수 있다. 결과적으로 관계형 데이터베이스는 원래 설계자가 예견하지 못한 방식으로 여러 애플리케이션에서 사용될 수 있으며, 이는 오랜 기간(수십 년) 동안 사용될 수 있는 데이터베이스에 특히 중요하다. 이러한 점 때문에 관계형 데이터베이스의 개념과 구현은 기업들 사이에서 매우 인기를 끌게 되었다.

데이터베이스 정규화

관계는 취약한 이상 현상의 유형에 따라 분류된다. 제1정규형인 데이터베이스는 모든 유형의 이상 현상에 취약한 반면, 도메인/키 정규형인 데이터베이스는 수정 이상 현상이 없다. 정규형은 본질적으로 계층적이다. 즉, 가장 낮은 단계는 제1정규형이며, 데이터베이스는 하위 단계 정규형의 요구 사항을 먼저 충족하지 않고는 상위 단계 정규형의 요구 사항을 충족할 수 없다.^[9]

논리적 해석

관계형 모델은 형식 체계이다. 관계의 속성은 일련의 논리적 명제를 정의한다. 각 명제는 튜플로 표현될 수 있다. 관계의 바디는 이러한 튜플들의 부분집합으로, 어떤 명제가 참인지를 나타낸다. 제약 조건은 마찬가지로 참이어야 하는 추가 명제를 나타낸다. 관계대수는 이러한 명제들로부터 결론을 타당하게 추론할 수 있는 일련의 논리 규칙이다.^[7]^: 95–101

튜플의 정의는 값이 없는 고유한 빈 튜플을 허용하며, 이는 속성의 공집합에 대응한다. 관계의 차수가 0이면(즉, 헤딩에 속성이 없으면), 카디널리티가 0(튜플이 없는 바디)이거나 카디널리티가 1(단일 빈 튜플을 포함하는 바디)일 수 있다. 이러한 관계는 부울 진릿값을 나타낸다. 차수가 0이고 카디널리티가 0인 관계는 거짓(False)이며, 차수가 0이고 카디널리티가 1인 관계는 참(True)이다.^[7]^{: 221–223}

예시

직원(Employees) 관계가 {이름, ID} 속성을 포함한다면, 튜플 {앨리스, 1}은 "ID가 1인 앨리스라는 직원이 존재한다"는 명제를 나타낸다. 이 명제는 참일 수도 있고 거짓일 수도 있다. 이 튜플이 관계의 바디에 존재한다면 명제는 참이다(그러한 직원이 있다). 이 튜플이 관계의 바디에 없다면 명제는 거짓이다(그러한 직원이 없다).^[7]^: 96–97

나아가 {ID}가 키라면, {앨리스, 1}과 {밥, 1}이라는 튜플을 포함하는 관계는 다음과 같은 모순을 나타내게 된다.

이름이 앨리스이고 ID가 1인 직원이 존재한다.
이름이 밥이고 ID가 1인 직원이 존재한다.
동일한 ID를 가진 여러 직원은 존재하지 않는다.

폭발 원리에 따라 이러한 모순은 시스템이 임의의 명제가 참임을 증명할 수 있게 허용한다. 데이터베이스는 이를 방지하기 위해 키 제약 조건을 강제해야 한다.^[7]^: 104

예시

데이터베이스

몇몇 릴바(관계 변수)와 그 속성에 대한 기술의 이상화되고 매우 단순한 예시:

고객 (고객 ID, 이름)
주문 (주문 ID, 고객 ID, 송장 ID, 날짜)
송장 (송장 ID, 고객 ID, 주문 ID, 상태)

이 디자인에는 고객, 주문, 송장의 세 가지 릴바가 있다. 굵게 표시되고 밑줄이 그어진 속성은 후보 키이다. 굵지 않고 밑줄만 그어진 속성은 외래 키이다.

보통 하나의 후보 키를 선택하여 기본 키라고 부르며, 다른 후보 키들보다 우선적으로(선호) 사용한다. 이때 나머지 후보 키들은 대체키라고 불린다.

후보 키는 튜플이 중복되지 않도록 강제하는 고유한 식별자이다. 중복을 허용하면 집합의 기본 정의를 위반하여 관계가 아닌 다른 것(즉, 백/멀티셋)이 되어버린다. 외래 키와 슈퍼 키(후보 키 포함)는 모두 여러 속성으로 구성된 복합 키일 수 있다. 아래는 예시인 고객 릴바의 관계를 표로 나타낸 것이다. 관계는 릴바에 할당될 수 있는 값으로 생각할 수 있다.

고객 관계

고객 ID	이름
123	앨리스
456	밥
789	캐럴

만약 ID가 123인 새 고객을 삽입하려고 하면, 고객 ID가 기본 키이고 이미 고객 123이 존재하므로 릴바의 설계를 위반하게 된다. DBMS는 무결성 제약 조건 위반으로 데이터베이스를 일관성 없게 만드는 이와 같은 트랜잭션을 거부해야 한다. 그러나 이름 필드는 기본 키의 일부가 아니므로, 고유한 ID를 가지고 있다면 앨리스라는 이름의 다른 고객을 삽입하는 것은 가능하다.

외래 키는 속성 집합의 값이 다른 관계의 후보 키에서 가져와야 함을 강제하는 무결성 제약 조건이다. 예를 들어, 주문 관계에서 고객 ID 속성은 외래 키이다. 조인은 한 번에 여러 관계의 정보를 끌어오는 연산이다. 위 예시의 릴바들을 조인함으로써 데이터베이스에서 모든 고객, 주문, 송장에 대해 질의할 수 있다. 특정 고객에 대한 튜플만 원한다면 제한 조건을 사용하여 이를 지정할 수 있다. 고객 123에 대한 모든 주문을 검색하려면, 주문 테이블에서 고객 ID가 123인 모든 행을 반환하도록 데이터베이스에 질의할 수 있다.

위의 데이터베이스 설계에는 결함이 있다. 송장 릴바가 주문 ID 속성을 포함하고 있다. 따라서 송장 릴바의 각 튜플은 하나의 주문 ID를 갖게 되며, 이는 각 송장에 대해 정확히 하나의 주문이 있음을 의미한다. 그러나 실제로는 하나의 송장이 여러 주문에 대해 발행될 수 있고, 특정 주문 없이 발행될 수도 있다. 또한 주문 릴바는 송장 ID 속성을 포함하고 있어 각 주문에 대응하는 송장이 있음을 시사한다. 하지만 이 역시 현실 세계에서 항상 참은 아니다. 주문은 때때로 여러 송장을 통해 결제되기도 하고, 송장 없이 결제되기도 한다. 즉, 주문당 여러 송장이 있을 수 있고 송장당 여러 주문이 있을 수 있다. 이것은 주문과 송장 사이의 다대다 관계(비특정 관계라고도 함)이다. 데이터베이스에서 이 관계를 표현하려면 주문과 송장 사이의 대응 관계를 지정하는 역할을 하는 새로운 릴바를 도입해야 한다.

주문송장 (주문 ID, 송장 ID)

이제 주문 릴바는 주문송장 테이블과 일대다 관계를 가지며, 송장 릴바도 마찬가지이다. 특정 주문에 대한 모든 송장을 검색하려면, 주문 관계의 주문 ID가 주문송장의 주문 ID와 같고, 주문송장의 송장 ID가 송장의 송장 ID와 같은 모든 주문을 질의할 수 있다.

관계형 데이터베이스로의 적용

관계형 데이터베이스의 데이터 유형은 정수 집합, 문자열 집합, 날짜 집합 등이 될 수 있다. 관계형 모델은 어떤 유형을 지원해야 하는지 규정하지 않는다.

속성은 일반적으로 컬럼으로, 튜플은 로우로, 관계는 테이블로 표현된다. 테이블은 컬럼 정의의 목록으로 지정되며, 각 정의는 고유한 컬럼 이름과 해당 컬럼에 허용되는 값의 유형을 지정한다. 속성 값은 특정 컬럼과 로우의 항목이다.

데이터베이스 릴바(관계 변수)는 흔히 기본 테이블로 알려져 있다. 특정 시점에 할당된 값의 헤딩은 테이블 선언에 지정된 대로이며, 바디는 가장 최근에 업데이트 연산자(일반적으로 INSERT, UPDATE, DELETE)에 의해 할당된 것이다. 질의를 평가한 결과인 테이블의 헤딩과 바디는 해당 질의에 사용된 연산자의 정의에 의해 결정된다.

SQL과 관계형 모델

초기에 관계형 데이터베이스를 위한 표준화 언어로 밀어붙여진 SQL은 여러 곳에서 관계형 모델을 벗어난다. 현재의 ISO SQL 표준은 관계형 모델을 언급하거나 관계형 용어 또는 개념을 사용하지 않는다.

관계형 모델에 따르면 관계의 속성과 튜플은 수학적 집합이며, 이는 순서가 없고 고유함을 의미한다. SQL 테이블에서 행과 열은 엄밀한 의미의 집합이 아니다. 테이블은 중복된 행과 중복된 열을 모두 포함할 수 있으며, 테이블의 열은 명시적으로 정렬되어 있다. SQL은 누락된 데이터를 나타내기 위해 Null 값을 사용하는데, 이는 관계형 모델에서 상응하는 것이 없다. 행이 알 수 없는 정보를 나타낼 수 있기 때문에, SQL은 관계형 모델의 '정보 원칙'을 준수하지 않는다.^[7]^{: 153–155, 162}

집합론적 공식화

관계형 모델의 기본 개념은 '관계 이름'과 '속성 이름'이다. 우리는 이를 "Person"이나 "name"과 같은 문자열로 표현할 것이며, 대개 변수 $r,s,t,\ldots$ 와 $a,b,c$ 를 사용하여 이를 나타낼 것이다. 또 다른 기본 개념은 숫자와 문자열 같은 값을 포함하는 '원자 값'(atomic values)의 집합이다.

첫 번째 정의는 테이블의 행이나 레코드 개념을 형식화한 '튜플'에 관한 것이다.

튜플: 튜플은 속성 이름에서 원자 값으로 가는 부분 정의 함수이다.
헤더 (Header): 헤더는 속성 이름의 유한 집합이다.
투영: 속성들의 유한 집합 $A$ 에 대한 튜플 $t$ 의 투영은 $t[A]=\{(a,v):(a,v)\in t,a\in A\}$ 이다.

다음 정의는 관계형 모델에서 정의된 테이블의 내용을 형식화한 '관계'를 정의한다.

관계: 관계는 헤더 $H$ 와 바디 $B$ 로 이루어진 튜플 $(H,B)$ 이다. 여기서 바디 $B$ 는 모두 도메인 $H$ 를 가진 튜플들의 집합이다.

이러한 관계는 1차 논리에서 술어의 외연(extension)이라고 부르는 것과 밀접하게 대응한다. 단, 여기서는 술어의 자리를 속성 이름과 동일시한다. 일반적으로 관계형 모델에서 데이터베이스 스키마는 관계 이름의 집합, 이 이름들과 연관된 헤더, 그리고 데이터베이스 스키마의 모든 인스턴스에 대해 유지되어야 하는 제약 조건들로 구성된다고 한다.

관계 유니버스 (Relation universe): 헤더 $H$ 에 대한 관계 유니버스 $U$ 는 헤더 $H$ 를 가진 관계들의 공집합이 아닌 집합이다.
관계 스키마 (Relation schema): 관계 스키마 $(H,C)$ 는 헤더 $H$ 와 헤더 $H$ 를 가진 모든 관계 $R$ 에 대해 정의된 술어 $C(R)$ 로 구성된다. 관계가 헤더 $H$ 를 가지고 $C$ 를 만족하면 관계 스키마 $(H,C)$ 를 만족한다고 한다.

키 제약 조건과 함수 종속

관계 제약 조건의 가장 단순하고 중요한 유형 중 하나는 '키 제약 조건'이다. 이는 특정 관계 스키마의 모든 인스턴스에서 튜플이 특정 속성값에 의해 식별될 수 있음을 알려준다.

슈퍼 키

슈퍼 키는 해당 열의 값들을 연결했을 때 모든 행에서 고유함이 보장되는 열 헤더의 집합이다. 형식적으로:

슈퍼 키는 속성 이름의 유한 집합으로 작성된다.

관계

(H,B)

에서 다음과 같은 경우 슈퍼 키

K

가 성립한다.

$K\subseteq H$ 이고
$t_{1}[K]=t_{2}[K]$ 를 만족하는 서로 다른 두 튜플 $t_{1},t_{2}\in B$ 가 존재하지 않는다.

관계 유니버스

U

의 모든 관계에서 슈퍼 키가 성립하면, 그 유니버스에서 슈퍼 키

K

가 성립한다고 한다.

정리:

H

에 대한 관계 유니버스

U

에서 슈퍼 키

K

가 성립할 필요충분조건은

K\subseteq H

이고

U

에서

K\rightarrow H

가 성립하는 것이다.

후보 키

후보 키는 다른 슈퍼 키를 형성하기 위해 더 이상 세분화될 수 없는 슈퍼 키이다.

관계 유니버스 $U$ 에 대해 슈퍼 키 $K$ 가 성립하고, $K$ 의 어떠한 진부분집합도 $U$ 에 대해 슈퍼 키로 성립하지 않으면 $K$ 는 후보 키가 된다.
함수 종속

함수 종속은 튜플의 어떤 값이 동일한 튜플 내의 다른 값으로부터 유도될 수 있는 성질이다.

함수 종속(FD)은 속성 이름의 유한 집합

X,Y

에 대해

X\rightarrow Y

로 작성된다.

관계

(H,B)

에서 다음과 같은 경우 함수 종속

X\rightarrow Y

가 성립한다.

$X,Y\subseteq H$ 이고
모든 튜플 $t_{1},t_{2}\in B$ 에 대해, $t_{1}[X]=t_{2}[X]~\Rightarrow ~t_{1}[Y]=t_{2}[Y]$

관계 유니버스

U

의 모든 관계에서 성립하면 함수 종속

X\rightarrow Y

가

U

에서 성립한다고 한다.

자명한 함수 종속

헤더

H

에 대한 모든 관계 유니버스에서 성립하는 함수 종속을 자명하다고 한다.

정리: 헤더

H

아래에서 FD

X\rightarrow Y

가 자명할 필요충분조건은

Y\subseteq X\subseteq H

이다.

폐쇄 (Closure)

암스트롱의 공리: 헤더

H

아래에서 FD 집합

S

의 폐쇄

S^{+}

는 다음을 만족하는

S

의 가장 작은 상위 집합이다.

$Y\subseteq X\subseteq H~\Rightarrow ~X\rightarrow Y\in S^{+}$ (반사성)
$X\rightarrow Y\in S^{+}\land Y\rightarrow Z\in S^{+}~\Rightarrow ~X\rightarrow Z\in S^{+}$ (이행성)
$X\rightarrow Y\in S^{+}\land Z\subseteq H~\Rightarrow ~(X\cup Z)\rightarrow (Y\cup Z)\in S^{+}$ (첨가성)

정리: 암스트롱의 공리는 건전하고 완전하다. 헤더

H

와

H

의 부분집합들만 포함하는 FD 집합

S

가 주어졌을 때,

X\rightarrow Y\in S^{+}

일 필요충분조건은

S

의 모든 FD가 성립하는

H

에 대한 모든 관계 유니버스에서

X\rightarrow Y

가 성립하는 것이다.

완료 (Completion)

유한한 FD 집합

S

아래에서 속성들의 유한 집합

X

의 완료

X^{+}

는 다음을 만족하는

X

의 가장 작은 상위 집합이다.

$Y\rightarrow Z\in S\land Y\subseteq X^{+}~\Rightarrow ~Z\subseteq X^{+}$

속성 집합의 완료는 특정 종속성이 FD 집합의 폐쇄에 속하는지 계산하는 데 사용될 수 있다.

정리: FD 집합

S

가 주어졌을 때,

X\rightarrow Y\in S^{+}

일 필요충분조건은

Y\subseteq X^{+}

이다.

기약 커버 (Irreducible cover)

FD 집합

S

의 기약 커버는 다음을 만족하는 FD 집합

T

이다.

$S^{+}=T^{+}$
$S^{+}=U^{+}$ 를 만족하는 $U\subset T$ 가 존재하지 않는다.
$X\rightarrow Y\in T~\Rightarrow Y$ 는 단일 원소 집합이다.
$X\rightarrow Y\in T\land Z\subset X~\Rightarrow ~Z\rightarrow Y\notin S^{+}$ .

함수 종속으로부터 후보 키를 도출하는 알고리즘

알고리즘 함수 종속으로부터 후보 키 도출 은 다음과 같다
    입력: 헤더 H의 부분집합들만 포함하는 FD 집합 S
    출력: S의 모든 FD가 성립하는 H에 대한 모든 관계 유니버스에서
            후보 키로 성립하는 슈퍼 키의 집합 C

    C := ∅         // 발견된 후보 키
    Q := { H }      // 후보 키를 포함하는 슈퍼 키
    while Q <> ∅ do
        Q에서 임의의 원소 K를 가져온다.
        Q := Q – { K }
        minimal := true
        for each X->Y in S do
            K'  := (K – Y) ∪ X   // 새로운 슈퍼 키 도출
            if K'  ⊂ K then
                minimal := false
                Q := Q ∪ { K'  }
            end if
        end for
        if minimal 이고 C에 K의 부분집합이 존재하지 않는다면 then
            C에서 K의 모든 상위 집합을 제거한다.
            C := C ∪ { K }
        end if
    end while

대안

다른 데이터베이스 모델로는 계층형 모델과 네트워크 모델이 있다. 이러한 오래된 아키텍처를 사용하는 일부 시스템은 데이터 용량 요구 사항이 매우 높은 데이터 센터나, 기존 시스템이 너무 복잡하고 추상적이어서 관계형 모델을 사용하는 시스템으로 마이그레이션하는 비용이 엄청난 곳에서 오늘날에도 여전히 사용되고 있다. 또한 최신 객체 지향 데이터베이스^[10]와 Datalog도 주목할 만하다.^[11]

Datalog는 데이터베이스 정의 언어로, 관계형 모델과 같은 데이터의 관계형 관점과 논리형 프로그래밍과 같은 논리적 관점을 결합한다. 관계형 데이터베이스가 질의를 지정하기 위해 합집합, 교집합, 차집합, 곱집합과 같은 관계 연산과 함께 관계 논리 또는 관계대수를 사용하는 반면, Datalog는 if, or, and, not과 같은 논리 연결사를 사용하여 관계를 데이터베이스 자체의 일부로 정의한다.

최소 고정 소수점(least-fixed-point) 연산자를 도입하지 않고는 재귀적 질의를 표현할 수 없는 관계형 모델과 달리,^[12] Datalog에서는 새로운 논리 연결사나 연산자를 도입하지 않고도 재귀 관계를 정의할 수 있다.

같이 보기

질의 언어
- 데이터베이스 질의 언어

참고 자료

Codd, E. F. (1970년). "A relational model of data for large shared data banks". Communications of the ACM, 13(6):377–387. (Retrieved from ACM, September 4, 2004.)
Date, C. J., Darwen, H. (2000). Foundation for Future Database Systems: The Third Manifesto, 2nd edition, Addison-Wesley Professional. ISBN 0-201-70928-7.
Date, C. J. (2003년). Introduction to Database Systems. 8th edition, Addison-Wesley. ISBN 0-321-19784-4.

각주

↑ Codd, E.F (1969), 《Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks》, Research Report, IBM .
↑ Codd, E.F (1970). 《A Relational Model of Data for Large Shared Data Banks》. 《Communications of the ACM》. Classics 13. 377–87쪽. doi:10.1145/362384.362685. S2CID 207549016.
↑ Codd, E. F (1990), 《The Relational Model for Database Management》, Addison-Wesley, 371–388쪽, ISBN 978-0-201-14192-4 .
↑ “Did Date and Darwen's "Third Manifesto" have a lasting impact?” (영어). 《Computer Science Stack Exchange》. 2024년 8월 3일에 확인함.
↑ Date, Christopher J. (2006). 〈18. Why Three- and Four-Valued Logic Don't Work〉. 《Date on Database: Writings 2000–2006》. Apress. 329–41쪽. ISBN 978-1-59059-746-0.
↑ “Tuple in DBMS” (미국 영어). 《GeeksforGeeks》. 2023년 2월 12일. 2024년 8월 3일에 확인함.
1 2 3 4 5 6 7 8 9 10 11 12 13 Date, Chris J. (2013). 《Relational Theory for Computer Professionals: What Relational Databases are Really All About》 1.판. Sebastopol, Calif: O'Reilly Media. ISBN 978-1-449-36943-9.
↑ “Relational Model | PDF | Relational Model | Relational Database” (영어). 《Scribd》. 2025년 9월 27일에 확인함.
↑ David M. Kroenke, Database Processing: Fundamentals, Design, and Implementation (1997), Prentice-Hall, Inc., pages 130–144
↑ Atkinson, M., Dewitt, D., Maier, D., Bancilhon, F., Dittrich, K. and Zdonik, S., 1990. The object-oriented database system manifesto. In Deductive and object-oriented databases (pp. 223-240). North-Holland.
↑ Maier, D., Tekle, K.T., Kifer, M. and Warren, D.S., 2018. Datalog: concepts, history, and outlook. In Declarative Logic Programming: Theory, Systems, and Applications (pp. 3-100).
↑ Aho, A.V. and Ullman, J.D., 1979, January. Universality of data retrieval languages. In Proceedings of the 6th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (pp. 110-119).

외부 링크

(영어) 관계형 모델

[1] Codd, E.F (1969), 《Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks》, Research Report, IBM .

[codd1970-2] Codd, E.F (1970). 《A Relational Model of Data for Large Shared Data Banks》. 《Communications of the ACM》. Classics 13. 377–87쪽. doi:10.1145/362384.362685. S2CID 207549016.

[3] Codd, E. F (1990), 《The Relational Model for Database Management》, Addison-Wesley, 371–388쪽, ISBN 978-0-201-14192-4 .

[4] “Did Date and Darwen's "Third Manifesto" have a lasting impact?” (영어). 《Computer Science Stack Exchange》. 2024년 8월 3일에 확인함.

[5] Date, Christopher J. (2006). 〈18. Why Three- and Four-Valued Logic Don't Work〉. 《Date on Database: Writings 2000–2006》. Apress. 329–41쪽. ISBN 978-1-59059-746-0.

[6] “Tuple in DBMS” (미국 영어). 《GeeksforGeeks》. 2023년 2월 12일. 2024년 8월 3일에 확인함.

[professionals-7] 1 2 3 4 5 6 7 8 9 10 11 12 13 Date, Chris J. (2013). 《Relational Theory for Computer Professionals: What Relational Databases are Really All About》 1.판. Sebastopol, Calif: O'Reilly Media. ISBN 978-1-449-36943-9.

[8] “Relational Model | PDF | Relational Model | Relational Database” (영어). 《Scribd》. 2025년 9월 27일에 확인함.

[Normalization-9] David M. Kroenke, Database Processing: Fundamentals, Design, and Implementation (1997), Prentice-Hall, Inc., pages 130–144

[10] Atkinson, M., Dewitt, D., Maier, D., Bancilhon, F., Dittrich, K. and Zdonik, S., 1990. The object-oriented database system manifesto. In Deductive and object-oriented databases (pp. 223-240). North-Holland.

[11] Maier, D., Tekle, K.T., Kifer, M. and Warren, D.S., 2018. Datalog: concepts, history, and outlook. In Declarative Logic Programming: Theory, Systems, and Applications (pp. 3-100).

[12] Aho, A.V. and Ullman, J.D., 1979, January. Universality of data retrieval languages. In Proceedings of the 6th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (pp. 110-119).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

v t e 데이터 모델
기본	아키텍처 모델링 구조
스키마	개념 논리 물리
유형	데이터베이스 자료 구조 다이어그램 개체-관계 모델 지질학 제네릭 시맨틱
관련 모델	데이터 흐름도 정보 모델 객체 모델 객체 역할 모델링 통합 모델링 언어
같이 보기	데이터베이스 설계 비즈니스 프로세스 모델링 코어 아키텍처 데이터 모델 엔터프라이즈 모델링 기능 모델 프로세스 모델링 XML 스키마 데이터 포맷 기술 언어