Baza danych czasowych

Tymczasowa baza danych przechowuje dane dotyczące instancji czasowych. Oferuje tymczasowe typy danych i przechowuje informacje dotyczące czasu przeszłego, teraźniejszego i przyszłego. Bazy danych czasowych mogą być jednookresowe, dwuokresowe lub trójokresowe.

Dokładniej, aspekty czasowe zwykle obejmują ważny czas , czas transakcji lub czas decyzji.

Ważny czas to okres czasu lub czas zdarzenia, w którym fakt jest prawdziwy w świecie rzeczywistym.
Czas transakcji to czas, w którym fakt został odnotowany w bazie danych.
Czas decyzji to czas, w którym zapadła decyzja o fakcie.

Jednoczasowy

Jednoczasowa baza danych ma jedną oś czasu, albo zakres ważności, albo zakres czasu systemowego.

Dwuczasowy

Dwuokresowa baza danych ma dwie osie czasu:

czas ważności
czas transakcji lub czas decyzji

Trójczasowy

Trójokresowa baza danych ma trzy osie czasu:

czas ważności
czas transakcji
czas decyzji

Takie podejście wprowadza dodatkowe komplikacje.

Tymczasowe bazy danych są w przeciwieństwie do aktualnych baz danych (nie mylić z obecnie dostępnymi bazami danych), które przechowują tylko fakty, które są uważane za prawdziwe w danym momencie.

Cechy

Tymczasowe bazy danych obsługują zarządzanie danymi czasowymi i uzyskiwanie do nich dostępu, udostępniając co najmniej jedną z następujących funkcji:

Typ danych okresu czasu, w tym możliwość reprezentowania okresów czasu bez końca (nieskończoność lub wieczność)
Możliwość definiowania atrybutów okresu ważności i okresu transakcji oraz relacji bitokresowych
Czas transakcji utrzymywany przez system
Czasowe klucze podstawowe , w tym nienakładające się ograniczenia okresowe
Ograniczenia czasowe, w tym nienakładająca się na siebie wyjątkowość i integralność referencyjna
Aktualizuj i usuwaj rekordy czasowe z automatycznym dzieleniem i łączeniem okresów
Zapytania czasowe w bieżącym czasie, punktach czasowych w przeszłości lub przyszłości lub w czasie trwania
Predykaty dla zapytań o okresy czasu, często oparte na relacjach interwałowych Allena

Historia

Wraz z rozwojem języka SQL i towarzyszącym mu zastosowaniem w rzeczywistych aplikacjach użytkownicy baz danych zdali sobie sprawę, że po dodaniu kolumn dat do kluczowych pól pojawiły się pewne problemy. Na przykład, jeśli tabela ma klucz podstawowy i niektóre atrybuty, dodanie daty do klucza podstawowego w celu śledzenia zmian historycznych może spowodować utworzenie większej liczby wierszy niż zamierzono. Usunięcia muszą być również obsługiwane inaczej, gdy wiersze są śledzone w ten sposób. W 1992 roku problem ten został rozpoznany, ale standardowa teoria baz danych nie była jeszcze gotowa do rozwiązania tego problemu, podobnie jak nowo sformalizowany standard.

Richard Snodgrass zaproponował w 1992 r., aby czasowe rozszerzenia języka SQL były opracowywane przez społeczność tymczasowych baz danych. W odpowiedzi na tę propozycję powołano komitet do zaprojektowania rozszerzeń do wydania standardu SQL z 1992 r. (ANSI X3.135.-1992 i ISO/IEC 9075:1992); te rozszerzenia, znane jako TSQL2, zostały opracowane przez tę komisję w 1993 roku. Pod koniec 1993 roku Snodgrass przedstawił tę pracę grupie odpowiedzialnej za American National Standard for Database Language SQL, Komitetowi Technicznemu ANSI X3H2 (obecnie znanemu jako NCITS H2). Wstępna specyfikacja językowa pojawiła się w ACM SIGMOD Record z marca 1994 roku. Na podstawie odpowiedzi na tę specyfikację dokonano zmian w języku i ostateczna wersja specyfikacji językowej TSQL2 została opublikowana we wrześniu 1994 r.

Podjęto próbę włączenia części TSQL2 do nowego standardu SQL SQL:1999 , nazwanego SQL3. Części TSQL2 zostały uwzględnione w nowym podstandardzie SQL3, ISO/IEC 9075-7, zwanym SQL/Temporal. Podejście TSQL2 było mocno krytykowane przez Chrisa Date'a i Hugh Darwena . Projekt ISO odpowiedzialny za wsparcie czasowe został odwołany pod koniec 2001 roku.

Od grudnia 2011 r. Norma ISO / IEC 9075, Database Language SQL: 2011 Part 2: SQL / Foundation zawierała w definicjach tabel klauzule definiujące „tabele okresu czasu aplikacji” ( tabele ważnego czasu ), „tabele z wersjami systemu” ( czas transakcji table) i „tabele okresów czasu aplikacji z wersjonowanymi systemami” ( bitemporal stoły). Zasadnicza różnica między propozycją TSQL2 a tym, co przyjęto w SQL:2011, polega na tym, że w traktowaniu SQL:2011 nie ma ukrytych kolumn ani nie ma nowego typu danych dla przedziałów; zamiast tego dwie kolumny daty lub sygnatury czasowej można połączyć razem za pomocą PERIOD FOR . Kolejną różnicą jest zastąpienie kontrowersyjnych modyfikatorów instrukcji (przedrostków) z TSQL2 zestawem predykatów czasowych.

Inne funkcje standardu SQL:2011 związane z tymczasowymi bazami danych to automatyczne dzielenie okresów, czasowe klucze podstawowe, czasowa integralność referencyjna, czasowe predykaty z algebrą przedziałów Allena oraz zapytania z podziałem czasu i sekwencjonowaniem.

Przykład

Dla ilustracji rozważmy następującą krótką biografię fikcyjnego mężczyzny, Johna Doe:

John Doe urodził się 3 kwietnia 1975 roku w Kids Hospital of Medicine County jako syn Jacka Doe i Jane Doe, którzy mieszkali w Smallville. Jack Doe z dumą zarejestrował narodziny swojego pierworodnego 4 kwietnia 1975 roku w ratuszu w Smallville. John dorastał jako radosny chłopiec, okazał się błyskotliwym uczniem i ukończył studia z wyróżnieniem w 1993 roku. Po maturze zamieszkał sam w Bigtown. Choć wyprowadził się 26 sierpnia 1994 r., zapomniał oficjalnie zarejestrować zmianę adresu. Dopiero na przełomie pór roku matka przypomniała mu, że musi się zarejestrować, co uczynił kilka dni później, 27 grudnia 1994 roku. Choć John miał obiecującą przyszłość, jego historia kończy się tragicznie. John Doe został przypadkowo potrącony przez ciężarówkę 1 kwietnia 2001 roku. Koroner podał datę jego śmierci tego samego dnia.

Korzystanie z nieczasowej bazy danych

Aby zapisać życie Johna Doe w aktualnej (nieczasowej) bazie danych, używamy tabeli Person (Nazwisko, Adres) . (Dla uproszczenia Nazwa jest zdefiniowana jako klucz podstawowy Person .)

Ojciec Johna oficjalnie zgłosił jego narodziny 4 kwietnia 1975 r. W tym dniu urzędnik Smallville wprowadził do bazy danych następujący wpis: Person(John Doe, Smallville) . Należy pamiętać, że sama data nie jest przechowywana w bazie danych.

Po ukończeniu studiów John się wyprowadza, ale zapomina zarejestrować swój nowy adres. Wpis Johna w bazie danych nie zmienia się aż do 27 grudnia 1994 roku, kiedy to w końcu zgłasza. Urzędnik z Bigtown aktualizuje swój adres w bazie danych. Tabela Person zawiera teraz Person(John Doe, Bigtown) . Należy zauważyć, że informacje o Johnie mieszkającym w Smallville zostały nadpisane, więc nie jest już możliwe ich odzyskanie z bazy danych. Urzędnik uzyskujący dostęp do bazy danych 28 grudnia 1994 r. dowiedziałby się, że John mieszka w Bigtown. Bardziej technicznie: jeśli administrator bazy danych uruchomił zapytanie WYBIERZ ADRES OD OSOBY , W KTÓREJ NAZWA = „John Doe” w dniu 26 grudnia 1994 r. wynikiem byłoby Smallville . Uruchomienie tego samego zapytania 2 dni później spowodowałoby Bigtown .

Aż do śmierci baza danych wskazywałaby, że mieszkał w Bigtown. 1 kwietnia 2001 r. koroner usuwa wpis Johna Doe z bazy danych. Następnie uruchomienie powyższego zapytania nie zwróci żadnego wyniku.

Data	Prawdziwe wydarzenie na świecie	Akcja bazy danych	Co pokazuje baza danych
3 kwietnia 1975	Rodzi się Jan	Nic	Nie ma osoby o imieniu John Doe
4 kwietnia 1975	Ojciec Johna oficjalnie donosi o narodzinach Johna	Wstawiono:Osoba (John Doe, Smallville)	John Doe mieszka w Smallville
26 sierpnia 1994	Po ukończeniu studiów John przeprowadza się do Bigtown, ale zapomina zarejestrować swój nowy adres	Nic	John Doe mieszka w Smallville
26 grudnia 1994	Nic	Nic	John Doe mieszka w Smallville
27 grudnia 1994	John rejestruje swój nowy adres	Zaktualizowano:Osoba (John Doe, Bigtown)	John Doe mieszka w Bigtown
1 kwietnia 2001 r	Jan umiera	Usunięto: Osoba (John Doe)	Nie ma osoby o imieniu John Doe

Używanie jednej osi: ważny czas lub czas transakcji

Ważny czas to czas, w którym fakt jest prawdziwy w świecie rzeczywistym. Prawidłowy okres może przypadać w przeszłości, obejmować bieżący czas lub wystąpić w przyszłości.

W powyższym przykładzie, aby zarejestrować prawidłowy czas, do tabeli Person dodano dwa pola, Valid-From i Valid-To . Określają one okres, przez jaki adres danej osoby jest ważny w świecie rzeczywistym. 4 kwietnia 1975 roku ojciec Johna zarejestrował narodziny syna. Następnie urzędnik wprowadza nowy wpis do bazy danych, stwierdzając, że John mieszka w Smallville od 3 kwietnia. Należy zauważyć, że chociaż dane zostały wprowadzone czwartego, w bazie danych stwierdza się, że informacje są ważne od trzeciego. Urzędnik jeszcze nie wie, czy i kiedy Janek przeniesie się w inne miejsce, więc Valid-To pole jest ustawione na nieskończoność (∞). Wpis w bazie danych to:

Osoba (John Doe, Smallville, 3 kwietnia 1975, ∞).

27 grudnia 1994 r. John zgłasza swój nowy adres w Bigtown, gdzie mieszka od 26 sierpnia 1994 r. Dokonywany jest nowy wpis w bazie danych, aby odnotować ten fakt:

Osoba (John Doe, Bigtown, 26 sierpnia 1994, ∞).

Oryginalny wpis Osoba (John Doe, Smallville, 3-Apr-1975, ∞) nie został usunięty, ale ma zaktualizowany atrybut Ważny-do , aby odzwierciedlić, że obecnie wiadomo, że John przestał mieszkać w Smallville 26 sierpnia 1994 r. baza danych zawiera teraz dwa wpisy dla Johna Doe

Osoba (John Doe, Smallville, 3 kwietnia 1975, 26 sierpnia 1994). Osoba (John Doe, Bigtown, 26 sierpnia 1994, ∞).

Kiedy John umiera, jego aktualny wpis w bazie danych zostaje zaktualizowany, stwierdzając, że John nie mieszka już w Bigtown. Baza danych wygląda teraz tak

Osoba (John Doe, Smallville, 3 kwietnia 1975, 26 sierpnia 1994). Osoba (John Doe, Bigtown, 26 sierpnia 1994, 1 kwietnia 2001).

Używanie dwóch osi: ważnego czasu i czasu transakcji

Czas transakcji rejestruje okres, w którym wpis bazy danych jest akceptowany jako poprawny. Umożliwia to wykonywanie zapytań, które pokazują stan bazy danych w danym momencie. Okresy transakcji mogą mieć miejsce tylko w przeszłości lub do chwili obecnej. W tabeli czasu transakcji rekordy nigdy nie są usuwane. Można wstawiać tylko nowe rekordy, a istniejące aktualizować, ustawiając czas zakończenia transakcji, aby pokazać, że nie są już aktualne.

Aby włączyć czas transakcji w powyższym przykładzie, do tabeli Osoba dodano dwa dodatkowe pola: Transaction-From i Transaction-To . Transaction-From to czas, w którym transakcja została wykonana, a Transaction-To to czas, w którym transakcja została zastąpiona (która może być nieskończona, jeśli nie została jeszcze zastąpiona). To sprawia, że tabela staje się tabelą bitokresową .

Co się stanie, jeśli adres osoby przechowywany w bazie danych jest nieprawidłowy? Załóżmy, że urzędnik przypadkowo wpisał zły adres lub datę? Albo załóżmy, że osoba z jakiegoś powodu skłamała na temat swojego adresu. Po wykryciu błędu urzędnicy aktualizują bazę danych, aby poprawić zapisane informacje.

Na przykład od 1 czerwca 1995 do 3 września 2000 John Doe przeprowadził się do Beachy. Ale aby uniknąć płacenia wygórowanego podatku mieszkaniowego Beachy, nigdy nie zgłosił tego władzom. Później, podczas dochodzenia podatkowego, odkryto 2 lutego 2001 r., że faktycznie przebywał w Beachy w tych dniach. Aby odnotować ten fakt, istniejący wpis o Johnie mieszkającym w Bigtown musi zostać podzielony na dwa osobne rekordy i wstawiony nowy rekord rejestrujący jego miejsce zamieszkania w Beachy. Baza danych wyglądałaby wówczas następująco:

Osoba (John Doe, Smallville, 3 kwietnia 1975, 26 sierpnia 1994). Osoba (John Doe, Bigtown, 26 sierpnia 1994, 1 czerwca 1995). Osoba (John Doe, Beachy, 1 czerwca 1995, 3 września 2000). Osoba (John Doe, Bigtown, 3 września 2000 r., 1 kwietnia 2001 r.).

Jednak nie pozostawia to żadnego zapisu, że baza danych kiedykolwiek twierdziła, że mieszkał w Bigtown w okresie od 1 czerwca 1995 do 3 września 2000. Wiedza o tym może być ważna ze względów kontrolnych lub do wykorzystania jako dowód w dochodzeniu podatkowym urzędnika. Czas transakcji pozwala uchwycić tę zmieniającą się wiedzę w bazie danych, ponieważ wpisy nigdy nie są bezpośrednio modyfikowane ani usuwane. Zamiast tego każdy wpis rejestruje, kiedy został wprowadzony i kiedy został zastąpiony (lub logicznie usunięty). Zawartość bazy danych wygląda wtedy następująco:

 Imię i nazwisko, miasto, ważne od, ważne do, wprowadzone,

 osoba zastąpiona (John Doe, Smallville, 3 kwietnia 1975 r., ∞, 4 kwietnia 1975 r., 27 grudnia 1994 r.). Osoba (John Doe, Smallville, 3 kwietnia 1975, 26 sierpnia 1994, 27 grudnia 1994, ∞).  Osoba (John Doe, Bigtown, 26 sierpnia 1994, ∞, 27 grudnia 1994, 2 lutego 2001).  Osoba (John Doe, Bigtown, 26 sierpnia 1994, 1 czerwca 1995, 2 lutego 2001, ∞).  Osoba (John Doe, Beachy, 1 czerwca 1995, 3 września 2000, 2 lutego 2001, ∞).  Osoba (John Doe, Bigtown, 3 września 2000 r., ∞, 2 lutego 2001 r., 1 kwietnia 2001 r.).  Osoba (John Doe, Bigtown, 3 września 2000, 1 kwietnia 2001, 1 kwietnia 2001, ∞ ).

Baza danych rejestruje nie tylko to, co wydarzyło się w realnym świecie, ale także to, co zostało oficjalnie zarejestrowane w różnych momentach.

Korzystanie z trzech osi: ważny czas, czas decyzji i czas transakcji

Czas decyzji jest alternatywą dla okresu czasu transakcji dla rejestracji czasu, w którym wpis bazy danych może zostać uznany za poprawny. Pozwala to na zapytania, które pokazują oficjalnie uznane fakty w danym czasie, nawet jeśli wystąpiło opóźnienie w zapisaniu tych faktów do bazy danych. Obsługa czasu decyzji zachowuje całą historię i zapobiega utracie informacji podczas aktualizacji.

Okresy czasu decyzji mogą mieć miejsce tylko w przeszłości lub do czasu transakcji. Podobnie jak w przypadku harmonogramu transakcji, rekordy nigdy nie są usuwane. Można wstawiać tylko nowe rekordy, a istniejące aktualizować, ustawiając czas zakończenia decyzji, aby pokazać, że nie są już aktualne.

Aby umożliwić podjęcie decyzji, do tabeli bazy danych dodano dwa dodatkowe pola: Decyzja od i Decyzja do . Decyzja od to czas, w którym decyzja została podjęta, a decyzja-do to czas, w którym decyzja została zastąpiona (może to być nieskończoność, jeśli nie została jeszcze zastąpiona). W połączeniu z czasem transakcji sprawia to, że tabela staje się tabelą trójokresową .

Poniżej znajduje się lista rzeczywistych wydarzeń, które miały miejsce między wyborami prezydenckimi w Stanach Zjednoczonych w latach 1964 i 1976:

Data	Podejmujący decyzję	Prawdziwe wydarzenie na świecie
3 listopada 1964	Kolegium Elektorów	Wybory 1964 r
5 listopada 1968	Kolegium Elektorów	Wybory 1968 r
7 listopada 1972	Kolegium Elektorów	Wybory 1972 r
10 października 1973	Spiro Agnew	Agnew rezygnuje
12 października 1973	Richarda Nixona	Nixon nominuje Forda
6 grudnia 1973	Kongres	Kongres potwierdza Forda
9 sierpnia 1974	Richarda Nixona	Nixon rezygnuje
20 sierpnia 1974	Geralda Forda	Ford nominuje Rockefellera
19 grudnia 1974	Kongres	Kongres potwierdza Rockefellera
2 listopada 1976	Kolegium Elektorów	Wybory 1976 r

Załóżmy, że istnieje stałe 7-dniowe opóźnienie między czasem decyzji a czasem transakcji zadeklarowanej w bazie danych. Następnie po wyborach w 1976 r. zawartość bazy danych wyglądałaby następująco:

Prezes, Wiceprezes, Ważny od, Ważny do, Decyzja od, Decyzja do, Transakcja od, Transakcja do ------------- -------------------------------------------------- -------------------------------------------------- -- Administracja (Lyndon Johnson, Hubert Humphrey, 20 stycznia 1965 r., 20 stycznia 1969 r., 3 listopada 1964 r., ∞, 10 listopada 1964 r., ∞) Administracja ( Richard Nixon, Spiro Agnew, 20 stycznia 1964 r.) 1969, 20 stycznia 1973, 5 listopada 1968, ∞, 12 listopada 1968, ∞) Administracja ( Richard Nixon, Spiro Agnew, 20 stycznia 1973, 20 stycznia 1977, 7 listopada 1972, ∞, 14 listopada 1972, 17 października 1973) Administracja ( Richard Nixon, Spiro Agnew, 20 stycznia 1973, 20 stycznia 1977, 7 listopada 1972, 10 października 1973, 17 października 1973, ∞) Administracja ( Richard Nixon, Spiro Agnew, 20 stycznia 1973, 10 października 1973, 10 października 1973, ∞, 17 października 1973, ∞) Administracja ( Richard Nixon, (wolne), 10 -Październik-1973, 20-Sty-1977, 10-Październik-1973, ∞, 17-Październik-1973, 13-Gru-1973) Administracja ( Richard Nixon, Gerald Ford, ∞, 20-Sty-1977, 12-Październik -1973, ∞, 19 października 1973, 13 grudnia 1973) Administracja ( Richard Nixon, (wolne), 10 października 1973, 20 stycznia 1977, 10 października 1973, 6 grudnia 1973, 13 grudnia 1973, ∞) Administracja ( Richard Nixon, (wolne), 10 października 1973, 6 grudnia 1973, 6 grudnia 1973, ∞, 13 grudnia 1973, ∞) Administracja ( Richard Nixon, Gerald Ford, ∞, 20 stycznia 1977, 12 października 1973, 6 grudnia 1973, 13 grudnia 1973, ∞) Administracja ( Richard Nixon, Gerald Ford, 6 grudnia 1973, 20 stycznia 1977) , 6 grudnia 1973, ∞, 13 grudnia 1973, 15 sierpnia 1974) Administracja ( Richard Nixon, Gerald Ford, 6 grudnia 1973, 20 stycznia 1977, 6 grudnia 1973, 8 sierpnia -1974, 15 sierpnia 1974, ∞) Administracja ( Richard Nixon, Gerald Ford, 6 grudnia 1973, 9 sierpnia 1974, 8 sierpnia 1974, ∞, 15 sierpnia 1974, ∞) Administracja ( Gerald Ford, (wolne), 9 sierpnia 1974, 20 stycznia 1977, 8 sierpnia 1974, ∞, 15 sierpnia 1974, 26 grudnia 1974) Administracja ( Gerald Ford, Nelson Rockefeller, ∞, 20- Styczeń 1977, 20 sierpnia 1974, ∞, 27 sierpnia 1974, 26 grudnia 1974) Administracja ( Gerald Ford, (wolne), 9 sierpnia 1974, 20 stycznia 1977, 8 sierpnia 1974 , 19-gru-1974, 26-gru-1974, ∞) Administracja ( Gerald Ford, (wolne), 9-sie-1974, 19-gru-1974, 19-gru-1974, ∞, 26-gru-1974, ∞) Administracja (Gerald Ford, Nelson Rockefeller, ∞, 20 stycznia 1977, 20 sierpnia 1974, 19 grudnia 1974, 26 grudnia 1974, ∞) Administracja ( Gerald Ford, Nelson Rockefeller, 19 grudnia- 1974, 20 stycznia 1977, 19 grudnia 1974, ∞, 26 grudnia 1974, ∞) Administracja ( Jimmy Carter, Walter Mondale, 20 stycznia 1977, 20 stycznia 1981, 2 listopada 1976, ∞, 9-listopad-1976, ∞)

Rozważmy pytanie, kto byłby prezydentem i wiceprezydentem na ważny okres 1 stycznia 1977 r.:

Nixon/Agnew przy użyciu czasu decyzji i czasu transakcji z dnia 14 listopada 1972 r
Nixon/(wolne) przy użyciu czasu decyzji i czasu transakcji z dnia 17 października 1973 r.
Nixon/Ford przy użyciu czasu decyzji i czasu transakcji z dnia 8 sierpnia 1974 r
Ford/(wolne) przy użyciu czasu decyzji 8 sierpnia 1974 i czasu transakcji bieżącego
Ford/Rockefeller przy użyciu czasu decyzji i czasu transakcji prądu

Modelowanie dwutemporalne

Model bitokresowy zawiera zarówno czas ważny, jak i czas transakcji. Zapewnia to zarówno informacje historyczne , jak i wycofane . Informacje historyczne (np.: „Gdzie Jan mieszkał w 1992 roku?”) są podawane według aktualnego czasu. Wycofanie (np.: „W 1992 r., gdzie według bazy danych mieszkał John?”) jest zapewniane przez czas transakcji. Odpowiedzi na te przykładowe pytania mogą nie być takie same — baza danych mogła zostać zmieniona od 1992 r., co spowodowało, że zapytania dawały różne wyniki.

Ważny czas i czas transakcji nie muszą być takie same dla jednego faktu. Rozważmy na przykład czasową bazę danych przechowującą dane dotyczące XVIII wieku. Ważny czas tych faktów przypada na okres między 1701 a 1800. Czas transakcji wskazywałby, kiedy fakty zostały wprowadzone do bazy danych (na przykład 21 stycznia 1998 r.).

Ewolucja schematu

Wyzwaniem jest obsługa zapytań czasowych w bazie danych czasu transakcji w zmieniającym się schemacie . W celu uzyskania doskonałej jakości archiwizacji kluczowe jest przechowywanie danych w takiej wersji schematu, w jakiej się pojawiły. Jednak nawet najprostsze zapytanie temporalne przepisujące historię wartości atrybutu wymagałoby ręcznego przepisania każdej z wersji schematu, potencjalnie setek, jak w przypadku MediaWiki [1] . Proces ten byłby szczególnie obciążający dla użytkowników. Proponowanym rozwiązaniem jest zapewnienie automatycznego przepisywania zapytań, chociaż nie jest to częścią SQL ani podobnych standardów.

Podejścia do zminimalizowania złożoności ewolucji schematu to:

korzystać z częściowo ustrukturyzowanej bazy danych/bazy danych NoSQL, która zmniejsza złożoność modelowania danych atrybutów, ale nie zapewnia funkcji obsługi wielu osi czasu.
korzystać z bazy danych zdolnej do przechowywania zarówno danych częściowo ustrukturyzowanych dla atrybutów, jak i danych ustrukturyzowanych dla osi czasu (np. SnowflakeDB , PostgreSQL)

Wdrożenia w godnych uwagi produktach

Następujące implementacje zapewniają funkcje czasowe w systemie zarządzania relacyjnymi bazami danych (RDBMS).

MariaDB w wersji 10.3.4 dodała obsługę standardu SQL: 2011 jako „tabele z wersjami systemowymi”.
Oracle Database – Oracle Workspace Manager to funkcja Oracle Database, która umożliwia twórcom aplikacji i administratorom baz danych zarządzanie bieżącymi, proponowanymi i historycznymi wersjami danych w tej samej bazie danych.
PostgreSQL w wersji 9.2 dodał natywne typy danych dystansowych, które są w stanie zaimplementować wszystkie funkcje tymczasowego rozszerzenia pgFoundry. Typy zakresów PostgreSQL są obsługiwane przez liczne natywne operatory i funkcje.
Teradata dostarcza dwa produkty. Teradata w wersji 13.10 i Teradata w wersji 14 mają funkcje czasowe oparte na TSQL2 wbudowanym w bazę danych.
IBM Db2 w wersji 10 dodał funkcję o nazwie „zapytanie o podróż w czasie”, która jest oparta na możliwościach czasowych standardu SQL: 2011 .
Microsoft SQL Server wprowadził Tabele Temporal jako funkcję dla SQL Server 2016. Ta funkcja jest opisana w filmie wideo w witrynie internetowej „Channel 9” firmy Microsoft.

Nierelacyjne systemy zarządzania bazami danych NoSQL, które zapewniają tymczasowe funkcje, w tym następujące:

TerminusDB to w pełni funkcjonalna baza danych wykresów typu open source , która natywnie obsługuje kontrolę wersji, zapytania dotyczące podróży w czasie i funkcje różnicujące. Ma niezmienną architekturę warstw opartą na kodowaniu delta i zwięzłych strukturach danych .
MarkLogic wprowadził obsługę danych bitokresowych w wersji 8.0. Sygnatury czasowe dla czasu ważnego i systemowego są przechowywane w dokumentach JSON lub XML.
SirixDB bardzo wydajnie przechowuje migawki (obecnie) dokumentów XML i JSON w formacie binarnym dzięki nowatorskiemu algorytmowi wersjonowania zwanemu przesuwaną migawką, który równoważy wydajność odczytu/zapisu i nigdy nie tworzy pików zapisu. Zapytania dotyczące podróży w czasie są obsługiwane natywnie, a także funkcje różnicujące.
XTDB (wcześniej Crux) zapewnia dwuokresowe zapytania Datalog dotyczące transakcji i dokumentów pozyskiwanych z pół-niezmiennych dzienników Kafka. Dokumenty są automatycznie indeksowane w celu utworzenia modelu Entity-atrybut-wartość bez konieczności definiowania schematu. Operacje transakcyjne określają efektywne czasy ważności. Czasy transakcji są przypisywane przez Kafkę i umożliwiają skalowalność poziomą dzięki spójnym odczytom.
RecallGraph to jednookresowa baza danych wykresów z punktu w czasie (czasu transakcji), zbudowana na bazie ArangoDB . Działa na podsystemie Foxx Microservice firmy ArangoDB. Zawiera semantykę podobną do VCS w wielu częściach interfejsu i jest wspierany przez transakcyjne narzędzie do śledzenia zdarzeń. Bittemporalność jest wymieniona jako jeden z elementów planu rozwoju .

Temporalne bazy danych były jedną z najwcześniejszych form kontroli wersji danych i wpłynęły na rozwój nowoczesnych systemów wersjonowania danych.

Alternatywy

Przykład wolno zmieniającego się modelu wymiarowego (SCD) (kliknij na obrazek, aby zobaczyć)

Powoli zmieniające się wymiary mogą służyć do modelowania relacji czasowych.

Dalsza lektura

CJ Data , Hugh Darwen , Nikos Lorentzos (2002). Dane czasowe i model relacyjny, wydanie pierwsze (seria Morgana Kaufmanna w systemach zarządzania danymi); Morgana Kaufmanna; 1. wydanie; 422 strony. ISBN 1-55860-855-9 .
Joe Celko (2014). Joe Celko's SQL for Smarties: Advanced SQL Programming (Seria Morgana Kaufmanna w zarządzaniu danymi); Morgana Kaufmanna; 5. edycja. ISBN 978-0-12-800761-7 .—W szczególności rozdziały 12 i 35 omawiają kwestie doczesne.
Snodgrass, Richard T. (1999). „ Tworzenie zorientowanych czasowo aplikacji bazodanowych w języku SQL ” (PDF) . (4,77 MiB ) (Seria Morgana Kaufmanna w systemach zarządzania danymi); Morgana Kaufmanna; 504 strony; ISBN 1-55860-436-7

Zobacz też

Linki zewnętrzne

„Strona główna centrum czasu” . Centrum czasu . Informatyka Uniwersytetu Arizony. Zarchiwizowane od oryginału w dniu 24 lutego 2020 r.
Relacje czasowe w RDF
Zakres czasowy dla trójek RDF
IBM DB2 10 dla systemu z/OS
Raz za razem seria artykułów autorstwa Randy'ego Weisa i Toma Johnstona
Temporal Patterns autorstwa Martina Fowlera