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 FOR
deklaracji. 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
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ż
- Modelowanie kotwic
- Teoria baz danych
- Sklep imprezowy
- Baza czasoprzestrzenna
- Baza danych szeregów czasowych
Bibliografia
Zewnętrzne linki
- "TimeCenter Strona główna" . Centrum czasu . Informatyka Uniwersytetu Arizony. Zarchiwizowane od oryginału 24 lutego 2020 r.
- Relacje czasowe w RDF
- Zakres czasowy dla trójek RDF
- IBM DB2 10 dla systemu z/OS
- Time and Time Again seria artykułów Randy'ego Weisa i Toma Johnstona
- Wzory czasowe autorstwa Martina Fowlera