Baza danych czasowych - Temporal database

A czasowe bazy danych przechowuje dane dotyczące przypadków czas. Oferuje czasowe typy danych i przechowuje informacje dotyczące czasu przeszłego, teraźniejszego i przyszłego. Bazy danych czasowych mogą być jednoczasowe, dwuczasowe lub trójczasowe.

Dokładniej aspekty czasowe zazwyczaj zawierają ważny czas , czas transakcji lub czas decyzji .

  • Ważny czas to okres, w którym fakt jest prawdziwy w świecie rzeczywistym.
  • Czas transakcji to czas, w którym zarejestrowano fakt w bazie danych.
  • Czas decyzji to czas, w którym została podjęta decyzja o fakcie.

Jednoczasowy

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

Dwuczasowy

Dwuczasowa baza danych ma dwie osie czasu:

  • czas ważności
  • czas transakcji lub czas decyzji

Trójczasowy

Trójczasowa baza danych ma trzy osie czasu:

  • czas ważności
  • czas transakcji
  • czas decyzji

Takie podejście wprowadza dodatkowe komplikacje.

Tymczasowe bazy danych różnią się od aktualnych baz danych (nie mylić z aktualnie dostępnymi bazami danych), które przechowują tylko fakty, które uważa się za prawdziwe w danym momencie.

Cechy

Tymczasowe bazy danych obsługują zarządzanie danymi tymczasowymi i uzyskiwanie do nich dostępu, zapewniają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 na zawsze)
  • Możliwość definiowania atrybutów ważności i okresu czasu transakcji oraz relacji bitemporalnych
  • Utrzymywany przez system czas transakcji
  • Czasowe klucze podstawowe , w tym nienakładające się ograniczenia okresu
  • Ograniczenia czasowe, w tym niepokrywająca się wyjątkowość i integralność referencyjna
  • Aktualizacja i usuwanie rekordów czasowych z automatycznym dzieleniem i łączeniem okresów czasu
  • Zapytania czasowe w bieżącym czasie, punkty czasowe w przeszłości lub przyszłości lub w czasie trwania
  • Predykaty do odpytywania okresów czasu, często oparte na relacjach interwałowych Allena

Historia

Wraz z rozwojem SQL i jego towarzyszącym zastosowaniem w rzeczywistych aplikacjach, użytkownicy baz danych zdali sobie sprawę, że kiedy dodawali kolumny dat do kluczowych pól, pojawiał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 prowadzić do utworzenia większej liczby wierszy niż zamierzono. Usuwanie musi być również obsługiwane inaczej, gdy wiersze są śledzone w ten sposób. W 1992 r. problem ten został rozpoznany, ale standardowa teoria baz danych nie była jeszcze w stanie rozwiązać tego problemu, podobnie jak nowo sformalizowany wówczas standard.

Richard Snodgrass zaproponował w 1992 roku, aby tymczasowe rozszerzenia SQL były opracowywane przez społeczność temporalnych baz danych. W odpowiedzi na tę propozycję utworzono komisję do projektowania rozszerzeń do edycji standardu SQL z 1992 roku (ANSI X3.135.-1992 i ISO/IEC 9075:1992); te rozszerzenia, znane jako TSQL2, zostały opracowane w 1993 roku przez ten komitet. Pod koniec 1993 roku Snodgrass zaprezentował tę pracę grupie odpowiedzialnej za amerykański Narodowy Standard Języka Bazy Danych SQL, ANSI Technical Committee X3H2 (obecnie znany jako NCITS H2). Wstępna specyfikacja języka pojawiła się w ACM SIGMOD Record z marca 1994 roku. Na podstawie odpowiedzi na tę specyfikację wprowadzono zmiany w języku, a ostateczna wersja specyfikacji języka TSQL2 została opublikowana we wrześniu 1994 r.

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

Od grudnia 2011 r. ISO/IEC 9075, Język bazy danych SQL: 2011 Część 2: SQL/Fundacja zawiera klauzule w definicjach tabel w celu zdefiniowania „tablic okresów czasu aplikacji” ( prawidłowe tabele czasu ), „tabele wersjonowane przez system” ( czas transakcji tabele) i „systemowe tabele okresów czasu aplikacji” ( tabele dwuczasowe ). Zasadnicza różnica między propozycją TSQL2 a tym, co zostało przyjęte w SQL:2011, polega na tym, że w SQL:2011 nie ma ukrytych kolumn, ani nie ma nowego typu danych dla interwałów; zamiast tego dwie kolumny daty lub sygnatury czasowej można połączyć ze sobą za pomocą PERIOD FORdeklaracji. Kolejną różnicą jest zastąpienie kontrowersyjnych (prefiksowych) modyfikatorów instrukcji z TSQL2 zestawem predykatów czasowych.

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

Przykład

Dla ilustracji rozważmy poniższą 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ę genialnym uczniem i ukończył studia z wyróżnieniem w 1993 roku. Po studiach zamieszkał sam w Bigtown. Chociaż wyprowadził się 26 sierpnia 1994 roku, zapomniał oficjalnie zarejestrować zmianę adresu. Dopiero na przełomie pór roku matka przypomniała mu, że musi się zarejestrować, co zrobił 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 r. Koroner podał datę śmierci tego samego dnia.

Korzystanie z nieczasowej bazy danych

Do przechowywania życia Jana Kowala w bieżącej (nie tymczasowej) bazie danych używamy tabeli Osoba (Nazwa, Adres) . (W celu uproszczenia Nazwa jest zdefiniowany jako klucz podstawowy z osób ).

Ojciec Johna oficjalnie zgłosił jego narodziny 4 kwietnia 1975 roku. W tym dniu urzędnik Smallville umieścił w bazie danych następujący wpis: Person(John Doe, Smallville). Zauważ, że sama data nie jest przechowywana w bazie danych.

Po ukończeniu szkoły John się wyprowadza, ale zapomina zarejestrować swój nowy adres. Wpis Johna w bazie danych zmienił się dopiero 27 grudnia 1994 roku, kiedy to w końcu to zgłosił. Urzędnik z Bigtown aktualizuje swój adres w bazie danych. Person tabela zawiera teraz Person(John Doe, Bigtown). Zauważ, że informacje o Johnie mieszkającym w Smallville zostały nadpisane, więc nie jest już możliwe odzyskanie tych informacji z bazy danych. Urzędnikowi uzyskującemu dostęp do bazy danych 28 grudnia 1994 r. powiedziano, że John mieszka w Bigtown. Mówiąc bardziej technicznie: jeśli administrator bazy danych uruchomiłby zapytanie SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'26 grudnia 1994 r., wynikiem byłoby Smallville. Uruchomienie tego samego zapytania 2 dni później spowodowałoby Bigtown.

Do jego śmierci baza podawała, że ​​mieszkał w Bigtown. 1 kwietnia 2001 r. koroner usuwa wpis John Doe z bazy danych. Po tym, uruchomienie powyższego zapytania nie zwróci żadnego wyniku.

Data Wydarzenie w świecie rzeczywistym Akcja bazy danych Co pokazuje baza danych
3 kwietnia 1975 r. Narodziny Jana Nic Nie ma osoby o imieniu John Doe
4 kwietnia 1975 r. Ojciec Johna oficjalnie zgłasza narodziny Johna Wstawiono: osoba (John Doe, Smallville) John Doe mieszka w Smallville
26 sierpnia 1994 Po ukończeniu studiów John przenosi 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 Jan rejestruje swój nowy adres Zaktualizowano:Osoba (John Doe, Bigtown) John Doe mieszka w Bigtown
1 kwietnia 2001 Jan umiera Usunięto:Osoba (Jan Kowalski) Nie ma osoby o imieniu John Doe

Korzystanie z 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 przypadać w przyszłości.

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

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

27 grudnia 1994 r. John zgłasza swój nowy adres w Bigtown, gdzie mieszka od 26 sierpnia 1994 r. W celu odnotowania tego faktu dodawany jest nowy wpis w bazie danych:

Person(John Doe, Bigtown, 26-Aug-1994, ∞).

Oryginalny wpis Person (John Doe, Smallville, 3-Apr-1975, ∞)nie jest usuwany, ale ma zaktualizowany atrybut Valid-To, aby odzwierciedlić, że obecnie wiadomo, że John przestał mieszkać w Smallville 26 sierpnia 1994 roku. Baza danych zawiera teraz dwa wpisy dotyczące Johna Doe

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, ∞).

Kiedy John umiera, jego aktualny wpis w bazie danych jest aktualizowany z informacją, że John nie mieszka już w Bigtown. Baza danych wygląda teraz tak

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Apr-2001).

Korzystanie z dwóch osi: prawidłowego czasu i czasu transakcji

Czas transakcji rejestruje okres, w którym wpis w bazie danych jest akceptowany jako poprawny. Umożliwia to wykonywanie zapytań, które pokazują stan bazy danych w określonym czasie. Okresy transakcji mogą przypadać 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 jeszcze dwa pola: Transakcja-Od i Transakcja-Do . Transaction-From to czas wykonania transakcji, a Transaction-To to czas zastąpienia transakcji (która może być nieskończonością, jeśli jeszcze nie została zastąpiona). To sprawia, że ​​stół staje się tabelą dwuczasową .

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

Na przykład od 1 czerwca 1995 do 3 września 2000 John Doe przeniósł się do Beachy. Ale żeby uniknąć płacenia wygórowanego podatku rezydencjalnego Beachy'ego, nigdy nie zgłosił tego władzom. Później, podczas dochodzenia podatkowego, 2 lutego 2001 r. odkryto, ż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 wstawić nowy rekord, który opisuje jego pobyt w Beachy. Baza danych wyglądałaby wtedy w następujący sposób:

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001).

Jednak nie pozostawia to żadnych zapisów, że baza danych kiedykolwiek twierdziła, że ​​mieszkał w Bigtown od 1 czerwca 1995 do 3 września 2000. Może to być ważne ze względów kontrolnych lub jako dowód w dochodzeniu podatkowym urzędnika. Czas transakcji pozwala na uchwycenie tej zmieniającej się wiedzy 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 tak:

Name, City, Valid From, Valid Till, Entered, Superseded
Person(John Doe, Smallville, 3-Apr-1975,  ∞,           4-Apr-1975,  27-Dec-1994).
Person(John Doe, Smallville, 3-Apr-1975,  26-Aug-1994, 27-Dec-1994, ∞          ).
Person(John Doe, Bigtown,    26-Aug-1994, ∞,           27-Dec-1994, 2-Feb-2001 ).
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,  ∞          ).

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

Korzystanie z trzech osi: czasu ważności, czasu decyzji i czasu transakcji

Czas decyzji jest alternatywą dla okresu czasu transakcji do rejestrowania czasu, w którym wpis do bazy danych może zostać zaakceptowany jako poprawny. Umożliwia to zapytania, które pokazują oficjalnie uznane fakty w danym momencie, nawet jeśli nastąpiło opóźnienie w ich zapisaniu do bazy danych. Obsługa czasu decyzji zachowuje całą historię i zapobiega utracie informacji podczas aktualizacji.

Okresy podejmowania decyzji mogą wystąpić tylko w przeszłości lub do czasu transakcji. Podobnie jak w tabeli czasu 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 włączyć czas decyzji, do tabeli bazy danych dodawane są dwa dodatkowe pola: Decyzja od i Decyzja do . Decyzja od to czas, w którym podjęto decyzję, a Decyzja-do to czas, w którym decyzja została zastąpiona (która może być nieskończonością, jeśli jeszcze nie została zastąpiona). W połączeniu z czasem transakcji powoduje to, że tabela staje się tabelą trójczasową .

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

Data Podejmujący decyzję Wydarzenie w świecie rzeczywistym
3 listopada 1964 Kolegium Elektorów Wybory 1964
5 listopada 1968 Kolegium Elektorów Wybory 1968
7 listopada 1972 r Kolegium Elektorów Wybory 1972
10 października 1973 r. Spiro Agnew Ponowna rezygnacja
12 października 1973 Richard Nixon Nixon nominuje Forda
6 grudnia 1973 Kongres Kongres potwierdza Ford
9 sierpnia 1974 Richard Nixon Nixon rezygnuje
20 sierpnia 1974 Geralda Forda Ford nominuje Rockefellera
19 grudnia 1974 Kongres Kongres potwierdza Rockefeller
2 listopada 1976 Kolegium Elektorów Wybory 1976

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

                   President, Vice President, Valid From, Valid Till, Decision From, Decision To, Transaction From, Transaction To
---------------------------------------------------------------------------------------------------------------------------------- 
Administration(Lyndon Johnson,    Hubert Humphrey, 20-Jan-1965, 20-Jan-1969,  3-Nov-1964,           ∞, 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-Nov-1976,           ∞)

Zastanówmy się nad pytaniem, kto będzie prezydentem i wiceprezydentem w ważnym okresie 1 stycznia 1977 r.:

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

Modelowanie dwuczasowe

Bitemporal Model zawiera zarówno ważny i czas transakcji. Zapewnia to zarówno informacje historyczne, jak i informacje o wycofaniu . Informacje historyczne (np.: „Gdzie Jan mieszkał w 1992 roku?”) podaje obowiązujący czas. Cofanie zmian (np.: „Gdzie w 1992 r. według bazy danych mieszkał Jan?”) określa 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 generowały różne wyniki.

Ważny czas i czas transakcji nie muszą być takie same dla pojedynczego faktu. Rozważmy na przykład czasową bazę danych przechowującą dane dotyczące XVIII wieku. Prawidłowy czas tych faktów mieści się w przedziale od 1701 do 1800. Czas transakcji pokaże, kiedy fakty zostały wprowadzone do bazy danych (na przykład 21 stycznia 1998).

Ewolucja schematu

Wyzwaniem jest obsługa zapytań czasowych w bazie danych czasu transakcji w ramach ewoluującego schematu . W celu uzyskania doskonałej jakości archiwalnej kluczowe znaczenie ma przechowywanie danych pod wersją schematu, w której pojawiły się po raz pierwszy. Jednak nawet najprostsze tymczasowe zapytanie przepisywania historii wartości atrybutu wymagałoby ręcznego przepisania w każdej 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 minimalizacji złożoności ewolucji schematów to:

  • do korzystania 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.
  • używać bazy danych zdolnej do przechowywania zarówno częściowo ustrukturyzowanych danych dla atrybutów, jak i ustrukturyzowanych danych dla osi czasu (np. SnowflakeDB , PostgreSQL)

Wdrożenia w godnych uwagi produktach

Poniższe implementacje zapewniają funkcje tymczasowe w systemie zarządzania relacyjnymi bazami danych (RDBMS).

  • MariaDB w wersji 10.3.4 dodała obsługę standardu SQL:2011 jako „Tabele systemowe”.
  • Oracle Database  – Oracle Workspace Manager to funkcja Oracle Database, która umożliwia programistom 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 z zakresem, które są w stanie zaimplementować wszystkie funkcje rozszerzenia temporal pgFoundry. Typy zakresu PostgreSQL są obsługiwane przez wiele natywnych operatorów i funkcji.
  • Teradata dostarcza dwa produkty. Teradata w wersji 13.10 i Teradata w wersji 14 mają funkcje tymczasowe oparte na TSQL2 wbudowane w bazę danych.
  • IBM DB2 w wersji 10 dodał funkcję o nazwie „zapytanie o podróż w czasie”, która jest oparta na tymczasowych możliwościach standardu SQL:2011 .
  • Microsoft SQL Server wprowadził tabele czasowe jako funkcję programu SQL Server 2016. Ta funkcja jest opisana w wideo w witrynie sieci Web firmy Microsoft „Channel 9”.

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

  • TerminusDB to w pełni funkcjonalna baza danych o otwartym kodzie źródłowym, która natywnie obsługuje kontrolę wersji, zapytania dotyczące podróży w czasie i funkcje porównywania. Posiada niezmienną architekturę warstwową opartą na kodowaniu delta i zwięzłych strukturach danych .
  • MarkLogic wprowadził obsługę danych dwuczasowych w wersji 8.0. Znaczniki czasu dla czasu prawidłowego i systemowego są przechowywane w dokumentach JSON lub XML.
  • SirixDB przechowuje migawki (obecnie) dokumentów XML i JSON bardzo wydajnie w formacie binarnym dzięki nowatorskiemu algorytmowi wersjonowania zwanemu migawką przesuwną, który równoważy wydajność odczytu/zapisu i nigdy nie tworzy szczytów zapisu. Zapytania dotyczące podróży w czasie są obsługiwane natywnie, a także funkcje różnicujące.
  • XTDB (dawniej Crux) zapewnia dwuczasowe zapytania Datalog do punktu w czasie dotyczące transakcji i dokumentów pozyskiwanych z częściowo niezmiennych dzienników Kafki. Dokumenty są automatycznie indeksowane w celu tworzenia indeksów modelu encja-atrybut-wartość bez konieczności definiowania schematu. Operacje transakcyjne określają obowiązujące czasy ważności. Czasy transakcji są przydzielane przez Kafkę i umożliwiają skalowanie poziome poprzez spójne odczyty.
  • RecallGraph jest grafową bazą danych z punktu w czasie, jednoczasową (czas transakcji), zbudowaną na bazie ArangoDB . Działa na podsystemie Foxx Microservice ArangoDB . Zawiera semantykę podobną do VCS w wielu częściach interfejsu i jest wspierany przez śledzenie zdarzeń transakcyjnych . Bittemporalność jest wymieniona jako jedna z pozycji na mapie drogowej jej rozwoju .

Alternatywy

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

Wolno zmieniające się wymiary można wykorzystać do modelowania relacji czasowych.

Dalsza lektura

  • CJ Date , Hugh Darwen , Nikos Lorentzos (2002). Dane czasowe i model relacyjny, wydanie pierwsze (seria Morgana Kaufmanna w systemach zarządzania danymi); Morgana Kaufmanna; Wydanie I; 422 strony. ISBN  1-55860-855-9 .
  • Joe Celko (2014). SQL Joe Celko dla Smarties: Zaawansowane programowanie SQL (seria Morgan Kaufmann w zarządzaniu danymi); Morgana Kaufmanna; Wydanie piąte. ISBN  978-0-12-800761-7 . — Rozdziały 12 i 35 w szczególności omawiają kwestie doczesne.
  • Snodgrass, Richard T. (1999). " Tworzenie aplikacji bazodanowych zorientowanych na czas w SQL " (PDF) . (4,77  MiB ) (seria Morgan Kaufmann w systemach zarządzania danymi); Morgana Kaufmanna; 504 strony; ISBN  1-55860-436-7

Zobacz też

Bibliografia

Zewnętrzne linki