관계형 모델

3. 개념

3. 1. 기본 개념

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

만약 ID가 ''123''인 새로운 고객을 ''삽입''하려고 시도한다면, 이는 관계형 변수의 설계를 위반하게 된다. 왜냐하면 '''고객 ID'''는 ''기본 키''이고, 이미 고객 ''123''이 있기 때문이다. DBMS는 이러한 유형의 트랜잭션을 거부해야 한다. 이는 데이터베이스를 무결성 제약 조건 위반으로 일관성이 없게 만들기 때문이다. 하지만, 새로운 고객이 고유한 ID를 가지고 있다면, 이름 필드는 기본 키의 일부가 아니므로, ''앨리스''라는 다른 고객을 삽입하는 것은 가능하다.

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

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

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

데이터베이스 릴레이션 변수(relation variable)는 일반적으로 기본 테이블로 알려져 있다. 언제든지 할당된 값의 헤더는 테이블 선언에 지정된 대로이며 본문은 업데이트 연산자(일반적으로 INSERT, UPDATE 또는 DELETE)에 의해 가장 최근에 할당된 값이다. 쿼리를 평가하여 생성된 테이블의 헤더와 본문은 해당 쿼리에 사용된 연산자의 정의에 의해 결정된다.

관계형 모델의 기본 개념은 관계 이름과 속성 이름이다. 이를 "Person"과 "name"과 같은 문자열로 나타낸다. 또 다른 기본 개념은 숫자와 문자열과 같은 값을 포함하는 원자 값의 집합이다.

테이블의 행 또는 레코드 개념을 공식화하는 튜플의 개념과 관련된 정의는 다음과 같다.

• 튜플: 튜플은 속성 이름에서 원자 값으로의 부분 함수이다.
• 헤더: 헤더는 속성 이름의 유한 집합이다.
• 프로젝션: 속성 $A$의 유한 집합에 대한 튜플 $t$의 프로젝션은 $t[A]\; =\; \backslash \{\; (a,\; v)\; :\; (a,\; v)\; \backslash in\; t,\; a\; \backslash in\; A\; \backslash \}$이다.

• 관계: 관계는 헤더 $H$와 본체 $B$를 가진 튜플 $(H,\; B)$로, 본체는 모두 도메인 $H$를 가진 튜플 집합이다.
• 관계 유니버스: 헤더 $H$에 대한 관계 유니버스 $U$는 헤더 $H$를 가진 관계의 공집합이 아닌 집합이다.
• 관계 스키마: 관계 스키마 $(H,\; C)$는 헤더 $H$와 헤더 $H$를 가진 모든 관계 $R$에 대해 정의된 술어 $C(R)$로 구성된다. 관계는 헤더 $H$를 가지고 $C$를 만족시키면 관계 스키마 $(H,\; C)$를 만족시킨다.

3. 2. 제약 조건

• 키(Key): 각 튜플을 고유하게 식별하는 속성 집합이다. 관계에서 각 튜플은 고유해야 하므로 모든 관계는 반드시 키를 가지며, 이는 전체 속성 집합일 수 있다.^[8] 관계는 여러 튜플을 고유하게 구별하는 방법이 여러 가지일 수 있으므로 여러 개의 키를 가질 수 있다.^[8]
• 후보 키: 관계에서 각 튜플을 고유하게 구별하는 데 보장되는 가장 작은 속성의 부분 집합이다.
• 기본 키(Primary Key): 여러 후보 키 중에서 선택된 하나의 키로, 다른 후보 키보다 선호되어 사용된다.
• 대체 키(Alternate Key): 기본 키로 선택되지 않은 나머지 후보 키이다.
• 외래 키: 다른 관계의 기본 키를 참조하는 속성 집합으로, 관계 간의 참조 무결성을 보장한다.^[8] 즉, ''R₁''의 튜플이 외래 키에 대한 값을 포함하는 경우, 해당 키에 대해 동일한 값을 포함하는 해당 튜플이 ''R₂''에 있어야 한다.^[8]

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

3. 3. 관계 연산

• 선택(Selection): 특정 조건을 만족하는 튜플(행)들을 추출한다. 예를 들어, "나이가 20세 이상인 고객"과 같은 조건을 사용하여 해당 고객들의 정보를 선택할 수 있다.
• 투영(Projection): 지정된 속성(열)들만 추출한다. 예를 들어, "고객 이름과 전화번호"만 보고 싶을 때 이 두 속성만 투영하여 결과를 얻을 수 있다.
• 합집합(Union): 두 관계(테이블)의 튜플들을 합친다. 이때 중복되는 튜플은 제거된다. 예를 들어, "서울에 사는 고객"과 "부산에 사는 고객" 정보를 합쳐 전체 고객 목록을 만들 수 있다.
• 교집합(Intersection): 두 관계에 모두 존재하는 튜플들만 추출한다. 예를 들어, "서울에 살면서 나이가 20세 이상인 고객"처럼 두 조건을 모두 만족하는 고객을 찾을 때 사용한다.
• 차집합(Difference): 한 관계에는 존재하지만 다른 관계에는 없는 튜플들을 추출한다. 예를 들어, "서울에 사는 고객" 중에서 "20세 미만인 고객"을 제외한 나머지 고객들을 찾을 때 사용한다.
• 조인(Join): 공통 속성을 기준으로 두 관계의 튜플들을 결합한다. 예를 들어, 고객 테이블과 주문 테이블을 "고객 ID"를 기준으로 조인하여 각 고객의 주문 정보를 함께 볼 수 있다.
• 카티션 곱(Cartesian Product): 두 관계의 모든 가능한 튜플 조합을 생성한다. 예를 들어, "색상" 테이블(빨강, 파랑, 노랑)과 "크기" 테이블(소, 중, 대)의 카티션 곱은 (빨강-소, 빨강-중, 빨강-대, 파랑-소, ...)와 같이 9개의 튜플을 생성한다.

3. 4. 데이터베이스 정규화

4. 논리적 해석

관계형 모델은 술어 논리를 사용하여 해석할 수 있다.^[13] 관계 변수는 술어와 연결되며, 각 튜플은 참으로 평가되는 명제를 나타낸다. 관계의 본체에 튜플이 존재하면 명제는 참이고, 존재하지 않으면 거짓이다. 이러한 가정은 폐쇄 세계 가정으로 알려져 있다.^[13]

예를 들어, 직원 관계에 ''{이름, ID}'' 속성이 있고, 튜플 ''{앨리스, 1}''이 존재한다면, "ID가 1이고 이름이 앨리스인 직원이 존재한다"는 명제는 참이다. 만약 ''{ID}''가 키라면, ''{앨리스, 1}''과 ''{밥, 1}'' 튜플이 동시에 존재하는 것은 모순이다. 폭발 원리에 따라, 이러한 모순은 시스템이 임의의 명제가 참임을 증명할 수 있게 하므로, 데이터베이스는 키 제약 조건을 적용하여 이를 방지해야 한다.^[8]

관계의 본체는 술어 논리에서 "외연"이라고 불리며, 관계 변수 술어의 외연으로 해석될 수 있다.^[13]

5. SQL과의 관계

SQL(Structured Query Language)은 관계형 데이터베이스를 조작하기 위한 표준 언어이지만, 여러 부분에서 에드거 F. 코드가 제시한 관계형 모델과 차이를 보인다. 현재 ISO SQL 표준은 관계형 모델을 언급하지 않으며, 관계형 용어나 개념을 사용하지 않는다.^[8]

관계형 모델에서 관계의 속성과 튜플은 순서가 없고 고유한 집합으로 정의되지만, SQL 테이블의 행과 열은 중복될 수 있으며, 열은 명시적으로 정렬된다. 또한 SQL은 누락된 데이터를 나타내기 위해 NULL 값을 사용하는데, 이는 관계형 모델에 없는 개념이다. 이러한 특징 때문에 SQL은 관계형 모델의 '정보 원칙'을 따르지 않는다는 비판을 받는다.^[8]

관계형 모델에서는 이항 관계를 넘어 n개의 항으로 확장된 관계 개념을 사용하며, 관계 대수 또는 관계 논리를 사용하여 데이터를 연산한다. 이 둘은 동등한 연산 능력을 가진다. 관계형 모델에서는 이진 논리가 중요하지만, 삼진 논리의 허용 여부에 대해서는 연구자들 사이에 의견이 갈린다.

관계형 모델을 활용하면 데이터베이스 설계 시 정보의 정합성을 논리적으로 표현할 수 있다. 관계의 정규화를 통해 데이터베이스 설계를 개선할 수 있지만, 실제 데이터 연산은 관계형 데이터베이스 관리 시스템(RDBMS) 엔진에 의해 제어되므로 논리 설계는 관여하지 않는다.

SQL은 처음에 관계형 데이터베이스의 표준 언어로 추진되었지만, 관계형 모델에서 벗어난 부분이 있어 비판받기도 한다.

다음은 SQL 용어와 관계형 모델 용어의 대응 관계이다.

SQL 표준이 관계형 모델에서 벗어난 주요 내용은 다음과 같다.

• 행의 중복: SQL 테이블은 같은 행이 여러 번 나타날 수 있지만, 관계형 모델에서는 튜플 중복이 허용되지 않는다.
• 이름 없는 열: SQL 테이블에는 이름 없는 열이 존재할 수 있어 참조가 불가능하지만, 관계형 모델에서는 모든 속성에 이름이 있어야 하고 참조 가능해야 한다.
• 열 이름 중복: SQL 테이블에서는 여러 열에 같은 이름을 붙일 수 있어 모호성이 발생하지만, 관계형 모델에서는 모든 속성 이름이 고유해야 한다.
• 열 순서 지정: SQL 테이블에서는 열 순서가 중요하지만, 관계형 모델에서는 열 순서가 없다.
• CHECK OPTION이 없는 뷰: SQL에서는 CHECK OPTION 없이 정의된 뷰에 대한 업데이트가 뷰에 반영되지 않을 수 있지만, 관계형 모델에서는 뷰 업데이트가 기본 관계 변수 업데이트와 동일한 결과를 가져야 한다.
• 테이블의 최소 열 개수: SQL 테이블은 최소 1개의 열을 가져야 하지만, 관계형 모델에서는 속성이 0개인 관계도 존재한다.
• NULL: SQL에서 NULL은 특별한 표시로 사용되며 삼치 논리와 관련되어 있지만, 관계형 모델은 배중률에 의존하며 모든 속성에 값이 할당되어야 한다.

6. 다른 데이터 모델과의 비교

데이터베이스 모델로는 계층형 데이터베이스 모델과 네트워크 모델이 있다. 이러한 구형 아키텍처를 사용하는 일부 시스템은 오늘날에도 높은 데이터 볼륨이 필요하거나, 기존 시스템이 매우 복잡하고 추상적이어서 관계형 모델을 사용하는 시스템으로 마이그레이션하는 데 비용이 많이 드는 데이터 센터에서 사용되고 있다.^[9] 또한 주목할 만한 것으로는 새로운 객체 데이터베이스가 있다.^[9]

관계형 모델 이외의 데이터베이스 모델로는 계층형 데이터 모델과 네트워크형 데이터 모델이 있다. 이러한 구형 아키텍처를 사용한 몇몇 시스템이 현재도 데이터 센터에서 사용되고 있으며, 대용량 데이터를 처리해야 하는 경우나, 기존 시스템이 매우 복잡하여 관계형 모델을 채택한 시스템으로 이관하는 데 막대한 비용이 소요되는 경우 등에 사용된다.

새로운 데이터 모델로는 객체 지향 데이터 모델이 있으며, 최근에는 객체 지향 데이터베이스를 사용할 수 있게 되었다. 2009년 현재, 관계형 데이터베이스에 비해 사용 사례는 적지만, 조금씩 채택되기 시작했다. 객체 지향 데이터베이스의 유용성에 대해서는 견해가 갈리고 있다. 객체 지향 데이터베이스는 객체 지향 프로그래밍 언어와의 친화성이 높다는 특징이 있다. 반면 일부에서는 객체 지향 데이터베이스 관리 시스템(ODBMS)의 대부분이 정통 DBMS(데이터베이스 관리 시스템)라기보다는 DBMS 구축 키트이며, 그다지 유용한 기술로 인식하지 않는다.

관계형 모델은 형식화된 최초의 데이터 모델이다. 관계형 모델이 정의된 후, 비형식적인 데이터 모델이 계층형 데이터베이스나 네트워크형 데이터베이스를 기술하기 위해 만들어졌다. 계층형 데이터베이스와 네트워크형 데이터베이스는 관계형 데이터베이스 이전에 이미 존재했다. 그러나 그것들이 모델로 기술된 것은 관계형 모델이 정의된 후였으며, 그 목적은 데이터 모델 간의 비교를 위한 기초를 확립하기 위해서였다.

7. 비판 및 논쟁

관계형 모델은 데이터의 유연성이 부족하다는 비판을 받기도 한다.^[12] NoSQL 등 새로운 데이터 모델이 등장하면서, 관계형 모델의 한계와 대안에 대한 논의가 활발하게 이루어지고 있다.

계층형 데이터 모델과 네트워크형 데이터 모델은 관계형 모델 이전에 이미 존재했지만, 관계형 모델이 형식화된 최초의 데이터 모델이기 때문에 이들과의 비교를 위해 관계형 모델이 정의된 후에 비형식적인 모델로 기술되었다.

에드거 F. 코드는 결손 정보를 처리하기 위해 관계형 모델의 삼치 논리 버전을 제안하기도 했지만, 구현의 복잡성 때문에 널리 사용되지는 않았다.

객체 지향 데이터 모델은 새로운 데이터 모델로, 객체 지향 데이터베이스를 통해 사용될 수 있다. 2009년 현재, 관계형 데이터베이스에 비해 사용 사례는 적지만, 객체 지향 프로그래밍 언어와의 친화성이 높아 점차 채택되고 있다. 그러나 객체 지향 데이터베이스 관리 시스템(ODBMS)의 유용성에 대해서는 의견이 분분하다.

기존의 계층형 데이터 모델과 네트워크형 데이터 모델을 사용하는 시스템은 여전히 일부 데이터 센터에서 사용되고 있는데, 이는 대용량 데이터 처리 또는 기존 시스템의 복잡성으로 인해 관계형 모델로의 전환 비용이 크기 때문이다.

8. 결론 및 전망

관계형 모델은 오랜 기간 동안 데이터베이스 분야에서 주류로 자리매김해 왔다. 빅데이터, 인공지능과 같은 새로운 기술 환경에 발맞춰 관계형 모델 역시 지속적으로 발전하고 있으며, 다른 데이터 모델과의 융합 또한 활발하게 이루어질 것으로 전망된다.

참조

_[1] 논문 Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks IBM
_[2] 논문 A Relational Model of Data for Large Shared Data Banks https://web.archive.[...]
_[3] 서적 The Relational Model for Database Management Addison-Wesley
_[4] 웹사이트 Did Date and Darwen's "Third Manifesto" have a lasting impact? https://cs.stackexch[...] 2024-08-03
_[5] 서적 Date on Database: Writings 2000–2006 Apress 2006
_[6] 웹사이트 Tuple in DBMS https://www.geeksfor[...] 2024-08-03
_[7] 서적 Database Processing: Fundamentals, Design, and Implementation Prentice-Hall, Inc.
_[8] 서적 Relational Theory for Computer Professionals: What Relational Databases are Really All About O'Reilly Media 2013
_[9] 논문 The object-oriented database system manifesto North-Holland
_[10] 논문 Datalog: concepts, history, and outlook
_[11] 논문 Universality of data retrieval languages
_[12] 논문 A Relational Model of Data for Large Shared Data Banks http://www.acm.org/c[...]
_[13] 서적