시간 데이터베이스

임시 데이터베이스는 시간 인스턴스와 관련된 데이터를 저장한다. 그것은 일시적 데이터 유형을 제공하고 과거, 현재 및 미래 시간과 관련된 정보를 저장한다. 임시 데이터베이스는 단임시, 2임시 또는 3임시일 수 있다.

좀 더 구체적으로 시간적 측면에는 일반적으로 유효한 시간, 거래 시간 또는 의사결정 시간이 포함된다.

• 유효시간은 실생활에서 사실이 사실인 기간이다.
• 거래 시간은 사실이 데이터베이스에 기록된 시간이다.
• 결정 시간은 그 사실에 대한 결정이 내려진 시간이다.

유니임템포럴

단일 임시 데이터베이스는 유효 범위 또는 시스템 시간 범위 중 한 축을 가진다.

양임시

2-임시 데이터베이스는 두 개의 시간 축을 가진다.

• 유효 시간
• 거래 시간 또는 결정 시간

트리임시탈

3개의 임시 데이터베이스는 세 개의 시간 축을 가진다.

• 유효 시간
• 거래시간
• 결정 시간

이 접근법은 추가적인 복잡성을 도입한다.

시간 데이터베이스는 현재 사용 가능한 데이터베이스와 대조적이다(현재 사용 가능한 데이터베이스와 혼동되지 않음). 이 데이터베이스는 현재 시간에 사실이라고 여겨지는 사실만 저장한다.

특징들

임시 데이터베이스는 다음 기능 중 하나 이상을 제공하여 임시 데이터 관리 및 액세스를 지원한다.^[1][2]

• 종료되지 않은 기간(인피니트 또는 영구)을 표시하는 기능을 포함하는 기간 데이터 유형
• 유효 기간 속성 및 트랜잭션 기간 속성 및 비트포털 관계를 정의하는 기능
• 시스템 유지 트랜잭션 시간
• 오버랩되지 않는 기간 제약 조건을 포함한 임시 기본 키
• 오버랩되지 않는 고유성 및 참조 무결성을 포함한 시간적 제약 조건
• 기간 자동 분할 및 병합으로 임시 레코드 업데이트 및 삭제
• 현재 시간, 과거 또는 미래의 시점 또는 시간 초과 쿼리
• 알렌의 간격 관계에 기초한 시간 쿼리 술어

역사

실제 애플리케이션에서 SQL과 그 참여자 사용이 발달하면서 데이터베이스 사용자들은 핵심 필드에 날짜 열을 추가했을 때 일부 문제가 발생한다는 것을 깨달았다. 예를 들어 테이블에 기본 키와 일부 속성이 있는 경우, 기본 키에 날짜를 추가하여 과거 변경 내용을 추적하면 의도한 것보다 더 많은 행이 생성될 수 있다. 또한 행이 이러한 방식으로 추적될 때 삭제는 다르게 처리되어야 한다. 1992년, 이 문제는 인정되었지만 표준 데이터베이스 이론은 아직 이 문제를 해결할 수 없었고, 당시 새로 공식화된 표준도 아니었다.

Richard Snodgrass는 1992년에 시간적 데이터베이스 커뮤니티에 의해 SQL에 대한 시간적 확장이 개발될 것을 제안했다. 이 제안에 대응하여 1992년판 SQL 표준(ANSI X3.135.195-1992 및 ISO/IEC 9075:1992)의 확장을 설계하기 위한 위원회가 구성되었고, TSQL2로 알려진 확장들은 1993년 동안 이 위원회가 개발하였다.^[3] 1993년 말, Snodgrass는 미국 국립 데이터베이스 언어 SQL 표준, ANSI 기술 위원회 X3H2(현재 NCITS H2로 알려져 있음)를 책임지는 그룹에 이 작업을 제시했다. 예비 언어 규격은 1994년 3월 ACM SGIMOD 레코드에 등장했다. 그 규격에 대한 응답을 바탕으로 언어에 대한 변경이 이루어졌으며, TSQL2 언어 규격의 최종 버전은^[4] 1994년 9월에 발표되었다.

TSQL2의 일부를 SQL3라고 하는 새로운 SQL 표준 SQL:1999에 통합하려는 시도가 있었다. TSQL2의 일부는 SQL/Temporal이라고 불리는 SQL3, ISO/IEC 9075-7의 새로운 하위 표준에 포함되었다.^[3] Chris Date와 Hugh Darwen에 의해 TSQL2 접근방식은 심한 비난을 받았다.^[5] 시간적 지원을 담당하는 ISO 프로젝트는 2001년 말경에 취소되었다.

2011년 12월 현재 ISO/IEC 9075, Database Language SQL:2011 제2부: SQL/Foundation은 "응용프로그램 시간표"(유효한 시간표), "시스템 버전 시간표"(거래 시간표) 및 "시스템 버전 애플리케이션 시간표"(두 번째 표)를 정의하기 위한 조항을 표 정의에 포함시켰다. TSQL2 제안과 SQL:2011에서 채택된 제안 사이의 실질적인 차이는 SQL:2011 처리에는 숨겨진 열이 없으며, 간격에 대한 새로운 데이터 유형도 없다는 것이다. 대신, 두 개의 날짜 또는 타임스탬프 열을 다음을 사용하여 함께 바인딩할 수 있다. PERIOD FOR 신고서 또 다른 차이점은 TSQL2에서 논란이 되는 (사전 수정) 문 수식어를 시간 술어 집합으로 대체하는 것이다.^[1]

임시 데이터베이스와 관련된 SQL:2011 표준의 다른 특징으로는 자동 시간 간격 분할, 임시 기본 키, 임시 참조 무결성, 알렌의 간격 대수를 포함한 임시 술어 및 시간 사용 및 순서 지정 쿼리가 있다.

예

예를 들어, 가상의 인물인 John Doe의 다음과 같은 짧은 전기를 생각해 보자.

존 도는 1975년 4월 3일 약국 키즈 병원에서 스몰빌에 사는 잭 도와 제인 도의 아들로 태어났다. 잭 도는 1975년 4월 4일 스몰빌 시청에 첫아이의 출생신고를 자랑스럽게 했다. 존은 즐거운 소년으로 자랐고, 훌륭한 학생으로 판명되어 1993년에 우등으로 졸업했다. 졸업 후, 그는 빅타운에 혼자 살기 위해 갔다. 1994년 8월 26일 이사했지만 주소변경등록을 공식적으로 잊어버렸다. 그의 어머니가 그에게 등록해야 한다는 것을 상기시킨 것은 계절이 바뀔 무렵이었는데, 며칠 후인 1994년 12월 27일 그렇게 했다. 존은 전도유망한 미래를 가졌음에도 불구하고 그의 이야기는 비극적으로 끝난다. John Doe는 2001년 4월 1일에 우연히 트럭에 치였다. 검시관은 바로 이날 그의 사망 날짜를 보고했다.

비임시 데이터베이스 사용

현재(비임시) 데이터베이스에 John Doe의 수명을 저장하려면 테이블을 사용하십시오. Person (Name, Address). (이름을 단순화하기 위해서는 Person의 기본 키로 정의된다.)

존의 아버지는 1975년 4월 4일 그의 탄생을 공식적으로 보고했다. 이 날짜에 Smallville 관계자는 데이터베이스에 다음과 같은 항목을 삽입했다. Person(John Doe, Smallville). 날짜 자체는 데이터베이스에 저장되지 않는다는 점에 유의하십시오.

졸업 후, 존은 이사하지만, 그의 새 주소를 등록하는 것을 잊는다. John의 데이터베이스 입력은 그가 마침내 그것을 보고하는 1994년 12월 27일까지 변경되지 않는다. 빅타운의 한 공무원이 그의 주소를 데이터베이스로 업데이트한다. 이제 사용자 테이블에 다음이 포함됨 Person(John Doe, Bigtown). 스몰빌에 살고 있는 존의 정보를 덮어쓰게 되었으므로 더 이상 데이터베이스에서 그 정보를 검색할 수 없다는 점에 유의한다. 1994년 12월 28일에 데이터베이스에 접속한 한 공무원은 존이 빅타운에 살고 있다는 말을 듣게 될 것이다. 보다 기술적으로: 데이터베이스 관리자가 쿼리를 실행한 경우 SELECT ADDRESS FROM PERSON WHERE NAME='John Doe' 1994년 12월 26일 그 결과는 Smallville. 동일한 쿼리를 이틀 후에 실행하면 Bigtown.

그가 죽을 때까지 데이터베이스는 그가 빅타운에 살았다고 진술했다. 2001년 4월 1일 검시관은 데이터베이스에서 John Doe 항목을 삭제한다. 이 후 위의 쿼리를 실행하면 결과가 전혀 반환되지 않는다.

날짜	리얼 월드 이벤트	데이터베이스 작업	데이터베이스에 표시되는 내용
1975년 4월 3일	존은 태어났다.	아무 것도 없어요.	John Doe라고 불리는 사람은 없다.
1975년 4월 4일	존의 아버지는 존의 출생 사실을 공식적으로 보고한다.	삽입됨:Person(John Doe, Smallville)	존 도우는 스몰빌에 산다.
1994년 8월 26일	졸업 후 존은 빅타운으로 이사하지만, 그의 새 주소를 등록하는 것을 잊는다.	아무 것도 없어요.	존 도우는 스몰빌에 산다.
1994년 12월 26일	아무 것도 없어요.	아무 것도 없어요.	존 도우는 스몰빌에 산다.
1994년 12월 27일	존은 그의 새 주소를 등록한다.	업데이트됨:Person(John Doe, Bigtown)	존 도우는 빅타운에 산다.
2001년 4월 1일	존이 죽다	삭제됨:Person(John Doe)	John Doe라고 불리는 사람은 없다.

단일 축 사용: 유효한 시간 또는 트랜잭션 시간

유효한 시간은 현실에서 사실이 진실인 시간이다. 유효한 기간은 과거일 수도 있고 현재 시간에 걸쳐 있거나 미래에 발생할 수도 있다.

위의 예에서, 유효한 시간을 기록하기 위해, 사용자 테이블에 Valid-From 및 Valid-To 필드가 추가된다. 이것들은 사람의 주소가 실제 세계에서 유효한 기간을 명시한다. 1975년 4월 4일 존의 아버지는 아들의 출생신고를 했다. 그러자 한 관계자는 4월 3일부터 존이 스몰빌에 산다는 내용의 새로운 항목을 데이터베이스에 삽입했다. 4일에 데이터를 삽입했지만, 데이터베이스에는 3일 이후 정보가 유효하다고 기재되어 있다. 관리는 아직 존이 다른 곳으로 이동할 것인지, 언제 이동할 것인지 알 수 없으므로, Valid-To 필드는 무한대( ()로 설정되어 있다. 데이터베이스의 항목:

Person(John Doe, Smallville, 3-Afr-1975, ∞).  

1994년 12월 27일, 존은 자신이 1994년 8월 26일부터 살고 있는 빅타운에서 새로운 주소를 보고한다. 이 사실을 기록하기 위해 새로운 데이터베이스 항목이 작성됨:

Person (John Doe, Bigtown, 1994년 8월 26일, ∞.  

원본 항목 Person (John Doe, Smallville, 3-Apr-1975, ∞) 삭제된 것은 아니지만, John이 1994년 8월 26일에 스몰빌에 사는 것을 중단한 것이 현재 알려져 있다는 것을 반영하기 위해 Valid-To 속성이 업데이트되었다. 이제 데이터베이스에 John Doe에 대한 두 개의 항목이 포함됨

Person(John Doe, Smallville, 1975년 3월 3일, 1994년 8월 26일). Person (John Doe, Bigtown, 1994년 8월 26일, ∞.  

존이 죽었을 때, 그의 현재 데이터베이스 항목은 존이 더 이상 빅타운에 살지 않는다는 내용으로 업데이트된다. 이제 데이터베이스는 다음과 같다.

Person(John Doe, Smallville, 1975년 3월 3일, 1994년 8월 26일). Person(John Doe, Bigtown, 1994년 8월 26일, 2001년 4월 1일)  

두 축 사용: 유효 시간 및 트랜잭션 시간

트랜잭션 시간은 데이터베이스 항목이 올바른 것으로 받아들여지는 기간을 기록한다. 이것은 주어진 시간의 데이터베이스 상태를 보여주는 쿼리를 가능하게 한다. 거래 기간은 과거 또는 현재 시간까지만 발생할 수 있다. 거래 시간표에서는 기록을 삭제하지 않는다. 새 레코드만 삽입할 수 있고, 기존 레코드는 거래 종료 시간을 설정하여 업데이트하여 더 이상 최신 상태가 아니라는 것을 보여줄 수 있다.

위의 예에서 트랜잭션 시간을 사용 가능으로 설정하려면 사용자 테이블에 두 개의 필드를 추가하십시오. Transaction-From 및 Transaction-To. Transaction-From은 트랜잭션이 이루어진 시간이며, Transaction-To는 트랜잭션이 대체된 시간(아직 대체되지 않았다면 무한대가 될 수도 있음)이다. 이것은 탁자를 작은 테이블로 만든다.

데이터베이스에 저장된 사용자의 주소가 올바르지 않으면 어떻게 되는가? 관리가 실수로 잘못된 주소나 날짜를 입력했다고 가정해 보십시오. 아니면, 그 사람이 어떤 이유로 그들의 주소를 속였다고 가정해보자. 오류가 발견되면, 관계자들은 기록된 정보를 수정하기 위해 데이터베이스를 업데이트한다.

예를 들어, 1995년 1월 6일부터 2000년 3월 3일까지, John Doe는 Beachy로 이사했다. 그러나 비치의 터무니없는 거주세를 내지 않으려고 당국에 신고한 적은 없었다. 나중에 세무 조사 중에, 그가 실제로 그 날짜 동안 비치에서 있었다는 것이 2001년 2월 2일에 밝혀졌다. 이 사실을 기록하기 위해서는 빅타운에 살고 있는 존에 대한 기존 엔트리를 두 개의 별도 기록으로 나눠야 하고, 비치 거주지를 기록하는 새로운 레코드를 삽입해야 한다. 그러면 데이터베이스는 다음과 같이 나타날 것이다.

Person(John Doe, Smallville, 1975년 3월 3일, 1994년 8월 26일). Person(John Doe, Bigtown, 1994년 8월 26일, 6월 1일-1995년). Person(John Doe, Beachy, 1-6월-1995, 3월 3일-Sep-2000). Person(John Doe, Bigtown, 3-Sep-2000, 1-apr-2001)  

그러나 이는 그가 1995년 6월 3일부터 2000년 3월 3일까지 빅타운에 살았다고 데이터베이스는 주장했다는 기록을 남기지 않는다. 이는 감사상의 이유로 알거나 공직자의 세무조사에서 증거로 사용하는 것이 중요할 수 있다. 트랜잭션 시간은 항목이 직접 수정되거나 삭제되지 않기 때문에 데이터베이스에서 변화하는 지식을 캡처할 수 있다. 대신, 각 항목은 입력된 시간과 대체된 시간(또는 논리적으로 삭제된 시간)을 기록한다. 데이터베이스 내용은 다음과 같다.

이름, 도시, 유효 시작, 유효 기간, 입력, 대체 

Person(John Doe, Smallville, 3-Afr-1975, 4, 4-Afr-1975, 27-12-1994). Person(John Doe, Smallville, 3-Afr-1975, 26-1994, 27-1994, ∞). Person(John Doe, Bigtown, 26-1994, 27, 27-Dec-1994, 2001년 2월 2일). Person(John Doe, Bigtown,    26-Aug-1994, 1-Jun-1995,  2-Feb-2001,  ∞          ). Person(John Doe, Beachy,     1-Jun-1995,  3-Sep-2000,  2-Feb-2001,  ∞          ). Person(John Doe, Bigtown,    3-Sep-2000,  ∞,           2-Feb-2001,  1-Apr-2001 ). Person(John Doe, Bigtown, 3-Sep-2000, 1-apr-2001, 1-apr-2001, 2001). 

데이터베이스는 현실에서 일어난 일뿐만 아니라 다른 시기에 공식적으로 기록된 일도 기록한다.

세 축 사용: 유효 시간, 결정 시간, 트랜잭션 시간

의사결정 시간은 데이터베이스 항목이 올바른 것으로 받아들여질 수 있는 시간을 기록하기 위한 거래 시간의 대안이다. 이를 통해 데이터베이스에 해당 사실을 커밋하는 데 지연이 있었더라도 주어진 시간에 공식적으로 인정된 사실을 보여주는 쿼리를 할 수 있다. 의사결정 시간 지원은 전체 기록을 보존하고 업데이트 중 정보 손실을 방지한다.^[6]

의사결정 기간은 과거 또는 거래시간까지만 발생할 수 있다. 거래 시간표에서와 같이 레코드는 절대 삭제되지 않는다. 새 레코드만 삽입할 수 있고, 기존 레코드는 더 이상 최신 상태가 아니라는 것을 보여주기 위해 의사결정 종료 시간을 설정하여 업데이트할 수 있다.

결정 시간을 사용하려면 데이터베이스 테이블에 다음 두 개의 필드를 추가하십시오. Decision From 및 Decision To. Decision From은 결정이 내려진 시간이고, Decision-To는 결정이 대체된 시간이다(아직 대체되지 않았다면 무한일 수도 있다). 거래 시간과 결합하면, 이것은 표를 삼중수소 표로 만든다.

다음은 1964년과 1976년 미국 대통령 선거 사이에 발생한 실제 사건 목록이다.

날짜	의사 결정자	리얼 월드 이벤트
1964년 11월 3일	선거 위원회	1964년 선거
1968년 11월 5일	선거 위원회	1968년 선거
1972년 11월 7일	선거 위원회	1972년 선거
1973년 10월 10일	스피로 애그뉴	애그뉴는 사임한다.
1973년 10월 12일	리처드 닉슨	닉슨은 포드를 지명한다.
1973년 12월 6일	의회	의회는 포드를 승인했다.
1974년 8월 9일	리처드 닉슨	닉슨이 사임하다
1974년 8월 20일	제럴드 포드	포드가 록펠러를 지명하다
1974년 12월 19일	의회	의회는 록펠러를 승인했다.
1976년 11월 2일	선거 위원회	1976년 선거

데이터베이스에 커밋된 트랜잭션 시간과 결정 시간 사이에 7일 지연이 있다고 가정해 보십시오. 1976년 선출 이후 데이터베이스 내용은 다음과 같다.

                   대통령, 부통령, 유효 기간, 유효 기간, 유효 기간, 결정 위치, 거래 위치, 거래 위치 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------4,           ∞, 10-Nov-1964,           ∞) Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1969, 20-Jan-1973,  5-Nov-1968,           ∞, 12-Nov-1968,           ∞) Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 20-Jan-1977,  7-Nov-1972,           ∞, 14-Nov-1972, 17-Oct-1973) Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 20-Jan-1977,  7-Nov-1972, 10-Oct-1973, 17-Oct-1973,           ∞) Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 10-Oct-1973, 10-Oct-1973,           ∞, 17-Oct-1973,           ∞) Administration( Richard Nixon,           (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973,           ∞, 17-Oct-1973, 13-Dec-1973) Administration( Richard Nixon,        Gerald Ford,           ∞, 20-Jan-1977, 12-Oct-1973,           ∞, 19-Oct-1973, 13-Dec-1973) Administration( Richard Nixon,           (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973,  6-Dec-1973, 13-Dec-1973,           ∞) Administration( Richard Nixon,           (Vacant), 10-Oct-1973,  6-Dec-1973,  6-Dec-1973,           ∞, 13-Dec-1973,           ∞) Administration( Richard Nixon,        Gerald Ford,           ∞, 20-Jan-1977, 12-Oct-1973,  6-Dec-1973, 13-Dec-1973,           ∞) Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973, 20-Jan-1977,  6-Dec-1973,           ∞, 13-Dec-1973, 15-Aug-1974) Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973, 20-Jan-1977,  6-Dec-1973,  8-Aug-1974, 15-Aug-1974,           ∞) Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973,  9-Aug-1974,  8-Aug-1974,           ∞, 15-Aug-1974,           ∞) Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 20-Jan-1977,  8-Aug-1974,           ∞, 15-Aug-1974, 26-Dec-1974) Administration(   Gerald Ford, Nelson Rockefeller,           ∞, 20-Jan-1977, 20-Aug-1974,           ∞, 27-Aug-1974, 26-Dec-1974) Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 20-Jan-1977,  8-Aug-1974, 19-Dec-1974, 26-Dec-1974,           ∞) Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 19-Dec-1974, 19-Dec-1974,           ∞, 26-Dec-1974,           ∞) Administration(   Gerald Ford, Nelson Rockefeller,           ∞, 20-Jan-1977, 20-Aug-1974, 19-Dec-1974, 26-Dec-1974,           ∞) Administration(   Gerald Ford, Nelson Rockefeller, 19-Dec-1974, 20-Jan-1977, 19-Dec-1974,           ∞, 26-Dec-1974,           ∞) Administration(  Jimmy Carter,     Walter Mondale, 20-Jan-1977, 20-Jan-1981,  2-Nov-1976, ∞, 9-1976, )) 

누가 대통령 및 부통령이 될 것인가에 대한 질문을 고려해 보십시오.

• Nixon/Agnew(Nixon/Agnew) 1972년 11월 14일-11월 14일-거래 시간 사용
• 닉슨/(Vacant) 17-1973년 10월 17일의 결정 시간과 거래 시간을 사용할 때
• 닉슨/포드(Nixon/Ford)가 1974년 8월 8일(현지시간)의 결정 시간과 거래 시간을 사용할 때
• Ford/(Vacant) 1974년 8월 8일 결정 시간 및 현재 거래 시간 사용 시
• 현재 결정 시간 및 거래 시간 사용 시 Ford/Rockefeller

비트스포럴 모델링

비트모형은 유효시간과 거래시간을 모두 포함한다. 이것은 과거 정보와 롤백 정보를 모두 제공한다. 역사적 정보(예: "1992년 존은 어디에 살았는가?")는 유효한 시간에 의해 제공된다. 롤백(예: "1992년, 데이터베이스는 존이 어디에 살고 있다고 믿었는가?")은 거래 시간에 의해 제공된다. 이러한 예시 질문에 대한 답변은 같지 않을 수 있다. 1992년 이후 데이터베이스가 변경되어 질의 결과가 다르게 나올 수 있다.

하나의 사실에 대해 유효한 시간과 거래 시간이 같을 필요는 없다. 예를 들어, 18세기에 대한 데이터를 저장하는 임시 데이터베이스를 생각해 보십시오. 이러한 사실의 유효시점은 1701년에서 1800년사이에 있다. 거래 시간은 언제 사실이 데이터베이스에 삽입되었는지 보여줄 것이다(예: 1998년 1월 21일).

스키마 진화

도전적인 문제는 진화하는 스키마 아래 트랜잭션 시간 데이터베이스에서 일시적 질의를 지원하는 것이다. 완벽한 보관 품질을 달성하기 위해서는 데이터가 처음 등장한 스키마 버전에 데이터를 저장하는 것이 중요하다. 그러나 속성 값의 이력을 다시 쓰는 가장 단순한 일시적 쿼리라도 각 스키마 버전에서 수동으로 다시 작성해야 하며, MediaWiki[1]의 경우와 같이 잠재적으로 수백 개일 수 있다. 이 과정은 사용자들에게 특히 부담이 될 것이다. 제안된 해결책은 SQL이나 유사한 표준의 일부는 아니지만,^[7][8] 자동 질의 재작성을 제공하는 것이다.

스키마 진화의 복잡성을 최소화하기 위한 접근법은 다음과 같다.

• 속성 데이터 모델링의 복잡성은 줄이되 다중 시간 축을 처리할 수 있는 기능은 제공하지 않는 반구조 데이터베이스/NoSQL 데이터베이스를 사용한다.^[9]
• 속성에 대한 반구조적 데이터와 시간 축에 대한 구조화된 데이터(예: SnowflakeDB, Postgre)를 모두 저장할 수 있는 데이터베이스를 사용SQL)

주요 제품에 구현

다음의 구현은 관계형 데이터베이스 관리 시스템(RDBMS)에서 일시적 기능을 제공한다.

• MariaDB 버전 10.3.4는 SQL:2011 표준에 대한 지원을 "System-Versioned Tables"^[10]로 추가했다.
• Oracle Database – Oracle Workspace Manager는 Oracle Database의 기능으로, 애플리케이션 개발자와 DBA가 동일한 데이터베이스에 있는 현재, 제안된, 이전 버전의 데이터를 관리할 수 있다.
• PostgreSQL 버전 9.2는 pgFoundry 시간적 기여 확장의 모든 기능을 구현할 수 있는 기본 범위 데이터 유형을 추가했다.^[11][12] 더 포스트그레SQL 범위 유형은 수많은 네이티브 연산자와 함수에 의해 지원된다.
• Teradata는 두 가지 제품을 제공한다. Teradata 버전 13.10과 Teradata 버전 14는 데이터베이스에 내장된 TSQL2를^[13] 기반으로 하는 임시 기능을 가지고 있다.
• IBM DB2 버전 10은 SQL:2011 표준의 시간적 기능을 기반으로 하는 "시간 여행 쿼리"^[2]라는 기능을 추가했다.^[1]
• Microsoft SQL Server는 SQL Server 2016의 기능으로 Temporary Tables를 도입했다. 이 기능은 마이크로소프트의 "채널 9" 웹사이트의 비디오에 설명되어 있다.^[14]

다음을 포함한 임시 기능을 제공하는 비 관계형 NoSQL 데이터베이스 관리 시스템:

• 터미네이터스DB는 버전 제어, 시간 이동 쿼리 및 분산 기능을 기본적으로 지원하는 완전한 오픈 소스 그래프 데이터베이스다. 델타 인코딩과 간결한 데이터 구조를 기반으로 하는 불변 계층 아키텍처를 가지고 있다.^[15]
• MarkLogic은 버전 8.0에서 비트포털 데이터 지원을 도입했다. 유효 시간 및 시스템 시간에 대한 타임스탬프는 JSON 또는 XML 문서에 저장된다.^[16]
• SirixDB는 (현재) XML- 및 JSON-문서의 스냅샷을 매우 효율적으로 바이너리 형식으로 저장하는데, 슬라이딩 스냅샷이라는 새로운 버전 알고리즘이 있어 읽기/쓰기 성능의 균형을 맞추고 쓰기 피크를 만들지 않는다. 시간 여행 질의는 분산 기능뿐만 아니라 기본적으로 지원된다.
• XTDB(이전의 Crux)는 반불가능한 Kafka 로그에서 수집된 트랜잭션 및 문서에 대한 시점 단위 비트모사 데이터로그 쿼리를 제공한다. 스키마를 정의할 필요 없이 문서는 자동으로 색인화되어 엔티티-속성-가치 모델 색인을 만든다. 트랜잭션 작업은 유효한 유효 시간을 지정한다. 거래 시간은 Kafka가 할당하고 일관된 읽기를 통해 수평적 확장성을 가능하게 한다.
• RememberGraph는 ArangoDB 위에 구축된 시점 단위(transaction time) 그래프 데이터베이스다. 아랑고DB의 Foxx Microservice 하위 시스템에서 운영된다. 그것은 그것의 인터페이스의 많은 부분에서 VCS와 같은 의미론을 특징으로 하며, 트랜잭션 이벤트 추적기가 뒷받침한다. 비트엠포럴리티는 개발 로드맵의 항목 중 하나로 등재돼 있다.

대안

천천히 변화하는 치수는 시간적 관계를 모형화하는 데 사용될 수 있다.

추가 읽기

참고 항목

• 앵커 모델링
• 데이터베이스 이론
• 이벤트 스토어
• Spatiotemporal 데이터베이스
• 시계열 데이터베이스

참조

외부 링크

위키미디어 커먼즈에는 타임라디오 데이터베이스와 관련된 미디어가 있다.

• "TimeCenter Home". TimeCenter. University of Arizona Computer Science. Archived from the original on Feb 24, 2020.
• RDF의 시간적 관계
• RDF 3중시범위에 관한 연구
• z/OS용 IBM DB2 10
• 랜디 와이스와 톰 존스턴의 Time and Time Again 시리즈 기사
• 마틴 파울러의 시간적 패턴