Temporal databas

En tidsdatabas lagrar data som hänför sig till tidsinstanser. Den erbjuder temporära datatyper och lagrar information om tidigare, nuvarande och framtida tider. Temporala databaser kan vara uni-temporala, bi-temporala eller tri-temporala.

Mer specifikt inkluderar de tidsmässiga aspekterna vanligtvis giltig tid , transaktionstid eller beslutstid.

  • Giltig tid är den tidsperiod under eller händelsetid då ett faktum är sant i den verkliga världen.
  • Transaktionstid är den tidpunkt då ett faktum registrerades i databasen.
  • Beslutstid är den tidpunkt då beslut fattades om faktum.

Uni-temporal

En entidsdatabas har en tidsaxel, antingen giltighetsintervallet eller systemets tidsintervall.

Bi-temporal

En bi-temporal databas har två tidsaxlar:

  • giltig tid
  • transaktionstid eller beslutstid

Tri-temporal

En tri-temporal databas har tre tidsaxlar:

  • giltig tid
  • transaktionstid
  • beslutstid

Detta tillvägagångssätt introducerar ytterligare komplexitet.

Temporala databaser står i motsats till nuvarande databaser (inte att förväxla med för närvarande tillgängliga databaser), som endast lagrar fakta som tros vara sanna vid den aktuella tidpunkten.

Funktioner

Temporala databaser stöder hantering och åtkomst av tidsdata genom att tillhandahålla en eller flera av följande funktioner:

  • En tidsperioddatatyp, inklusive möjligheten att representera tidsperioder utan slut (oändlighet eller för alltid)
  • Förmågan att definiera giltiga attribut och tidsperiodattribut för transaktioner och bitemporala relationer
  • Systemunderhållen transaktionstid
  • Temporala primärnycklar , inklusive icke-överlappande periodbegränsningar
  • Tidsmässiga begränsningar, inklusive icke-överlappande unikhet och referensintegritet
  • Uppdatering och radering av tidsposter med automatisk uppdelning och sammanslagning av tidsperioder
  • Temporala frågor vid aktuell tidpunkt, tidpunkter i det förflutna eller framtiden, eller över varaktigheter
  • Predikat för sökning av tidsperioder, ofta baserade på Allens intervallrelationer

Historia

Med utvecklingen av SQL och dess åtföljande användning i verkliga applikationer insåg databasanvändare att när de lade till datumkolumner till nyckelfält, uppstod vissa problem. Till exempel, om en tabell har en primärnyckel och vissa attribut, kan det leda till att fler rader skapas än vad som är avsett att lägga till ett datum till den primära nyckeln för att spåra historiska ändringar. Borttagningar måste också hanteras annorlunda när rader spåras på detta sätt. År 1992 uppmärksammades detta problem men standarddatabasteorin var ännu inte i stånd att lösa detta problem, och inte heller den då nyligen formaliserade standarden.

Richard Snodgrass föreslog 1992 att tidsmässiga tillägg till SQL skulle utvecklas av den temporala databasgemenskapen. Som svar på detta förslag bildades en kommitté för att utforma tillägg till 1992 års upplaga av SQL-standarden (ANSI X3.135.-1992 och ISO/IEC 9075:1992); dessa tillägg, kända som TSQL2, utvecklades under 1993 av denna kommitté. I slutet av 1993 presenterade Snodgrass detta arbete för den grupp som ansvarar för American National Standard for Database Language SQL, ANSI Technical Committee X3H2 (nu känd som NCITS H2). Den preliminära språkspecifikationen fanns i mars 1994 ACM SIGMOD Record. Baserat på svaren på den specifikationen gjordes ändringar i språket och den definitiva versionen av TSQL2-språkspecifikationen publicerades i september 1994

Ett försök gjordes att införliva delar av TSQL2 i den nya SQL-standarden SQL:1999, kallad SQL3. Delar av TSQL2 ingick i en ny understandard till SQL3, ISO/IEC 9075-7, kallad SQL/Temporal. TSQL2-metoden kritiserades hårt av Chris Date och Hugh Darwen . ISO-projektet med ansvar för tidsmässigt stöd avbröts i slutet av 2001.

Från och med december 2011, ISO/IEC 9075, Databas Language SQL:2011 Del 2: SQL/Foundation inkluderade satser i tabelldefinitioner för att definiera "applikationstidsperiodtabeller" ( giltiga tidtabeller ), "systemversionsbaserade tabeller" ( transaktionstid) tabeller) och "systemversionsbaserade applikationstidsperiodtabeller" ( bitemporala tabeller). En väsentlig skillnad mellan TSQL2-förslaget och det som antogs i SQL:2011 är att det inte finns några dolda kolumner i SQL:2011-behandlingen, och inte heller har den en ny datatyp för intervall; istället kan två datum- eller tidsstämpelkolumner bindas samman med en PERIOD FOR- deklaration. En annan skillnad är att byta ut de kontroversiella (prefix) satsmodifierarna från TSQL2 med en uppsättning temporala predikat.

Andra funktioner i SQL:2011- standarden relaterade till temporala databaser är automatisk tidsperioddelning, temporala primärnycklar, temporal referensintegritet, temporala predikat med Allens intervallalgebra och tidsdelade och sekvenserade frågor.

Exempel

Som illustration, överväg följande korta biografi om en fiktiv man, John Doe:

John Doe föddes den 3 april 1975 på Kids Hospital of Medicine County, som son till Jack Doe och Jane Doe som bodde i Smallville. Jack Doe registrerade stolt födelsen av sin förstfödda den 4 april 1975 i Smallville City Hall. John växte upp som en glad pojke, visade sig vara en lysande student och tog examen med utmärkelser 1993. Efter examen gick han för att bo på egen hand i Bigtown. Trots att han flyttade ut den 26 augusti 1994 glömde han att registrera adressändringen officiellt. Det var först vid säsongsskiftet som hans mamma påminde honom om att han var tvungen att registrera sig, vilket han gjorde några dagar senare den 27 december 1994. Även om John hade en lovande framtid, slutar hans historia tragiskt. John Doe blev av misstag påkörd av en lastbil den 1 april 2001. Rättsläkaren rapporterade sitt dödsdatum samma dag.

Använda en icke-tidsdatabas

För att lagra John Does liv i en aktuell (icke-temporär) databas använder vi en tabell Person (namn, adress) . (För att förenkla namn definieras som primärnyckeln för Person .)

Johns far rapporterade officiellt sin födelse den 4 april 1975. På detta datum infogade en Smallville-tjänsteman följande post i databasen: Person(John Doe, Smallville) . Observera att själva datumet inte lagras i databasen.

Efter examen flyttar John ut, men glömmer att registrera sin nya adress. Johns post i databasen ändras inte förrän den 27 december 1994, då han slutligen rapporterar det. En tjänsteman i Bigtown uppdaterar sin adress i databasen. Tabellen Person innehåller nu Person(John Doe, Bigtown) . Observera att informationen om John som bor i Smallville har skrivits över, så det är inte längre möjligt att hämta den informationen från databasen. En tjänsteman som fick tillgång till databasen den 28 december 1994 skulle få veta att John bor i Bigtown. Mer tekniskt: om en databasadministratör körde frågan VÄLJ ADDRESS FRÅN PERSON WHERE NAME = 'John Doe' den 26 december 1994, skulle resultatet bli Smallville . Att köra samma fråga två dagar senare skulle resultera i Bigtown .

Fram till sin död skulle det i databasen stå att han bodde i Bigtown. Den 1 april 2001 raderar rättsläkaren John Doe-posten från databasen. Efter detta skulle körning av ovanstående fråga inte ge något resultat alls.

Datum Händelse i verkligheten Databasåtgärd Vad databasen visar
3 april 1975 John är född Ingenting Det finns ingen som heter John Doe
4 april 1975 Johns far rapporterar officiellt om Johns födelse Infogat:Person (John Doe, Smallville) John Doe bor i Smallville
26 augusti 1994 Efter examen flyttar John till Bigtown, men glömmer att registrera sin nya adress Ingenting John Doe bor i Smallville
26 december 1994 Ingenting Ingenting John Doe bor i Smallville
27 december 1994 John registrerar sin nya adress Uppdaterad:Person (John Doe, Bigtown) John Doe bor i Bigtown
1 april 2001 John dör Raderad:Person (John Doe) Det finns ingen som heter John Doe

Med en enda axel: giltig tid eller transaktionstid

Huvudartikel: Giltig tid

Giltig tid är den tid för vilken ett faktum är sant i den verkliga världen. En giltig tidsperiod kan ligga i det förflutna, sträcka sig över den aktuella tiden eller inträffa i framtiden.

För exemplet ovan, för att registrera giltig tid, har tabellen Person två fält tillagda, Giltig-Från och Giltig-Till . Dessa anger den period då en persons adress är giltig i den verkliga världen. Den 4 april 1975 registrerade Johns far sin sons födelse. En tjänsteman infogar sedan en ny post i databasen där det står att John bor i Smallville från den 3 april. Observera att även om uppgifterna infogades den fjärde så anger databasen att informationen är giltig sedan den tredje. Tjänstemannen vet ännu inte om eller när John kommer att flytta till en annan plats, så Giltig till är inställt på oändligt (∞). Posten i databasen är: 

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

Den 27 december 1994 rapporterar John sin nya adress i Bigtown där han har bott sedan den 26 augusti 1994. En ny databaspost görs för att registrera detta:

Person (John Doe, Bigtown, 26 augusti 1994, ∞).

Den ursprungliga posten Person (John Doe, Smallville, 3-apr-1975, ∞) har inte tagits bort, men har attributet Valid-To uppdaterat för att återspegla att det nu är känt att John slutade bo i Smallville den 26 augusti 1994. Databasen innehåller nu två poster för John Doe 

Person (John Doe, Smallville, 3-apr-1975, 26-aug-1994). Person (John Doe, Bigtown, 26 augusti 1994, ∞).

När John dör uppdateras hans nuvarande post i databasen och säger att John inte bor i Bigtown längre. Databasen ser nu ut så här

Person (John Doe, Smallville, 3-apr-1975, 26-aug-1994). Person (John Doe, Bigtown, 26 augusti 1994, 1 april 2001).

Använder två axlar: giltig tid och transaktionstid

Huvudartikel: Transaktionstid

Transaktionstid registrerar den tidsperiod under vilken en databaspost accepteras som korrekt. Detta möjliggör frågor som visar tillståndet för databasen vid en given tidpunkt. Transaktionsperioder kan endast inträffa i det förflutna eller fram till den aktuella tiden. I en transaktionstidtabell raderas aldrig poster. Endast nya poster kan infogas och befintliga uppdateras genom att ställa in deras transaktionssluttid för att visa att de inte längre är aktuella.

För att aktivera transaktionstid i exemplet ovan läggs ytterligare två fält till i tabellen Person: Transaktion-Från och Transaktion-Till . Transaktion-Från är tidpunkten då en transaktion gjordes, och Transaktion-Till är tiden då transaktionen ersattes (vilket kan vara oändligt om den ännu inte har ersatts). Detta gör bordet till ett bitemporalt bord .

Vad händer om personens adress som lagras i databasen är felaktig? Anta att en tjänsteman av misstag angett fel adress eller datum? Eller anta att personen ljög om sin adress av någon anledning. Efter upptäckten av felet uppdaterar tjänstemännen databasen för att korrigera den registrerade informationen.

Till exempel, från 1 juni 1995 till 3 september 2000 flyttade John Doe till Beachy. Men för att slippa betala Beachys orimliga bostadsskatt anmälde han det aldrig till myndigheterna. Senare under en skatteutredning upptäcks det den 2 februari 2001 att han faktiskt var i Beachy under dessa datum. För att registrera detta måste den befintliga posten om John som bor i Bigtown delas upp i två separata skivor, och en ny skiva infogas som spelar in hans bostad i Beachy. Databasen skulle då se ut enligt följande:

Person (John Doe, Smallville, 3-apr-1975, 26-aug-1994). Person (John Doe, Bigtown, 26 augusti 1994, 1 juni 1995). Person (John Doe, Beachy, 1-juni-1995, 3-sep-2000). Person (John Doe, Bigtown, 3-sep-2000, 1-apr-2001).

Detta lämnar dock inga uppgifter om att databasen någonsin hävdade att han bodde i Bigtown under 1-juni-1995 till 3-sep-2000. Detta kan vara viktigt att veta av revisionsskäl eller för att använda som bevis i tjänstemannens skatteutredning. Transaktionstiden gör det möjligt att fånga denna föränderliga kunskap i databasen, eftersom poster aldrig direkt ändras eller raderas. Istället registrerar varje post när den matades in och när den ersattes (eller logiskt togs bort). Databasinnehållet ser då ut så här:

 Namn, stad, giltig från, giltig till, införd, ersatt 
 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 augusti 1994, 1 juni 1995, 2 februari 2001, ∞ ).  Person (John Doe, Beachy, 1-juni-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, ∞ ).

Databasen registrerar inte bara vad som hände i den verkliga världen, utan också vad som officiellt registrerades vid olika tidpunkter.

Använder tre axlar: giltig tid, beslutstid och transaktionstid

Beslutstid är ett alternativ till transaktionstidsperioden för att registrera den tid då en databaspost kan accepteras som korrekt. Detta möjliggör förfrågningar som visar officiellt erkända fakta vid en given tidpunkt, även om det var en fördröjning med att överföra dessa fakta till databasen. Stöd för beslutstid bevarar hela historiken och förhindrar förlust av information under uppdateringar.

Beslutsperioder kan bara inträffa i det förflutna eller fram till transaktionstiden. Som i en transaktionstidtabell raderas aldrig poster. Endast nya poster kan infogas och befintliga uppdateras genom att ställa in deras beslutssluttid för att visa att de inte längre är aktuella.

För att möjliggöra beslutstid läggs ytterligare två fält till i en databastabell: Beslut från och Beslut till . Beslut från är den tid då ett beslut fattades, och Beslut-Till är tiden då beslutet ersattes (vilket kan vara oändligt om det ännu inte har ersatts). I kombination med transaktionstid gör detta tabellen till en tritemporal tabell .

Följande är en lista över verkliga händelser som inträffade mellan USA:s presidentval 1964 och 1976:

Datum Beslutstagare Händelse i verkligheten
3 november 1964 Elektorskollegium Valet 1964
5 november 1968 Elektorskollegium Valet 1968
7 november 1972 Elektorskollegium Valet 1972
10 oktober 1973 Spiro Agnew Agnew avgår
12 oktober 1973 Richard Nixon Nixon nominerar Ford
6 december 1973 kongressen Kongressen bekräftar Ford
9 augusti 1974 Richard Nixon Nixon avgår
20 augusti 1974 Gerald Ford Ford nominerar Rockefeller
19 december 1974 kongressen Kongressen bekräftar Rockefeller
2 november 1976 Elektorskollegium Valet 1976

Antag att det finns en konstant 7-dagars fördröjning mellan beslutstiden och transaktionstiden som är ansluten till databasen. Sedan efter valet 1976 skulle databasens innehåll vara:

President, Vice President, Giltigt från, Giltigt till, beslut från, beslut till, transaktion från, transaktion till ---------------------------- -------------------------------------------------- -------------------------------------------------- -- Administration (Lyndon Johnson, Hubert Humphrey, 20 januari-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-okt-1973) Administration( Richard Nixon, Spiro Agnew, 20-jan-1973, 20-jan-1977, 7-nov-1972, 10-okt-1973, 17-okt. 1973, ∞) Administration( Richard Nixon, Spiro Agnew, 20-jan-1973, 10-okt-1973, 10-okt-1973, ∞, 17-okt-1973, ∞) Administration (Richard Nixon, (Ledig), 10 -okt-1973, 20-jan-1977, 10-okt-1973, ∞, 17-okt-1973, 13-dec-1973) Administration( Richard Nixon, Gerald Ford, ∞, 20-jan-1977, 12-okt. -1973, ∞, 19-okt-1973, 13-dec-1973) Administration (Richard Nixon, (vakant), 10-okt-1973, 20-jan-1977, 10-okt-1973, 6-dec-1973, 13 dec-1973, ∞) Administration( Richard Nixon, (vakant), 10-okt-1973, 6-dec-1973, 6-dec-1973, ∞, 13-dec-1973, ∞) Administration( Richard Nixon, Gerald Ford, ∞, 20-jan-1977, 12-okt-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, (Ledig), 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, (vakant), 9-aug-1974, 20-jan-1977, 8-aug-1974 , 19-dec-1974, 26-dec-1974, ∞) Administration( Gerald Ford, (vakant), 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 november 1976, ∞)

Fundera på frågan om vem som skulle vara president och vicepresident för en giltig tid 1-jan-1977:

  • Nixon/Agnew när beslutstid och transaktionstid används 14 november 1972
  • Nixon/(Vacant) när man använder beslutstid och transaktionstid 17-okt-1973
  • Nixon/Ford när man använder beslutstid och transaktionstid 8-aug-1974
  • Ford/(Ledig) vid användning av en beslutstid på 8-aug-1974 och transaktionstid för nuvarande
  • Ford/Rockefeller när man använder en beslutstid och transaktionstid av nuvarande

Bitemporal modellering

Huvudartikel: Bitemporal modellering

En bitemporal modell innehåller både giltig tid och transaktionstid. Detta ger både historisk information och återställningsinformation . Historisk information (t.ex.: "Var bodde John 1992?") tillhandahålls av den giltiga tiden. Återställning (t.ex.: "År 1992, var trodde databasen att John bodde?") tillhandahålls av transaktionstiden. Svaren på dessa exempelfrågor kanske inte är desamma – databasen kan ha ändrats sedan 1992, vilket gör att frågorna ger olika resultat.

Den giltiga tiden och transaktionstiden behöver inte vara densamma för ett enda faktum. Tänk till exempel på en tidsdatabas som lagrar data om 1700-talet. Den giltiga tiden för dessa fakta är någonstans mellan 1701 och 1800. Transaktionstiden skulle visa när fakta infogades i databasen (till exempel 21 januari 1998).

Schema evolution

Huvudartikel: Schema evolution

En utmanande fråga är stödet för tidsmässiga frågor i en transaktionstiddatabas under ett schema som utvecklas . För att uppnå perfekt arkivkvalitet är det av största vikt att lagra data under den schemaversion under vilken de först dök upp. Men även den enklaste tidsfrågan som skriver om historien för ett attributvärde skulle behöva skrivas om manuellt under var och en av schemaversionerna, potentiellt hundratals som i fallet med MediaWiki [1 ] . Denna process skulle vara särskilt belastande för användarna. En föreslagen lösning är att tillhandahålla automatisk omskrivning av frågor, även om detta inte är en del av SQL eller liknande standarder.

Metoder för att minimera komplexiteten i schemautveckling är:

  • att använda en semistrukturerad databas/NoSQL-databas som minskar komplexiteten i modellering av attributdata men ger inga funktioner för att hantera flera tidsaxlar.
  • att använda en databas som kan lagra både semistrukturerad data för attribut och strukturerad data för tidsaxlar (t.ex. SnowflakeDB , PostgreSQL)

Implementeringar i framstående produkter

Följande implementeringar tillhandahåller tidsmässiga funktioner i ett relationsdatabashanteringssystem (RDBMS).

  • MariaDB version 10.3.4 lade till stöd för SQL:2011- standarden som "System-Versioned Tables".
  • Oracle Database – Oracle Workspace Manager är en funktion i Oracle Database som gör det möjligt för applikationsutvecklare och DBA:er att hantera aktuella, föreslagna och historiska versioner av data i samma databas.
  • PostgreSQL version 9.2 lade till infödda datatyper med avstånd som kan implementera alla funktioner i pgFoundry-tillägget med temporalt bidrag. PostgreSQL-serietyperna stöds av många inbyggda operatörer och funktioner.
  • Teradata tillhandahåller två produkter. Teradata version 13.10 och Teradata version 14 har tidsfunktioner baserade på TSQL2 inbyggd i databasen.
  • IBM Db2 version 10 lade till en funktion som heter "time travel query" som är baserad på de tidsmässiga funktionerna i SQL:2011- standarden.
  • Microsoft SQL Server introducerade Temporal Tables som en funktion för SQL Server 2016. Funktionen beskrivs i en video på Microsofts "Channel 9"-webbplats.

Icke-relationella, NoSQL-databashanteringssystem som tillhandahåller tidsmässiga funktioner, inklusive följande:

  • TerminusDB är en fullt utrustad grafdatabas med öppen källkod som inbyggt stöder versionskontroll, tidsresorsfrågor och olika funktioner. Den har en oföränderlig lagerarkitektur baserad på deltakodning och kortfattade datastrukturer .
  • MarkLogic introducerade stöd för bitemporal data i version 8.0. Tidsstämplar för Giltig och Systemtid lagras i JSON- eller XML-dokument.
  • SirixDB lagrar ögonblicksbilder av (för närvarande) XML- och JSON-dokument mycket effektivt i binärt format tack vare en ny versionsalgoritm som kallas glidande snapshot, som balanserar läs-/skrivprestanda och aldrig skapar skrivtoppar. Tidsresorsfrågor stöds inbyggt såväl som olika funktioner.
  • XTDB (tidigare Crux) tillhandahåller punkt-i-tid bitemporala Datalog- förfrågningar över transaktioner och dokument som tas in från semi-oföränderliga Kafka-loggar. Dokument indexeras automatiskt för att skapa Entitet–attribut–värde modellindex utan något krav på att definiera ett schema. Transaktionsoperationer anger de effektiva Giltiga tiderna. Transaktionstider tilldelas av Kafka och möjliggör horisontell skalbarhet via konsekventa läsningar.
  • RecallGraph är en punkt-i-tid, unittemporal (transaktionstid) grafdatabas, byggd ovanpå ArangoDB . Det körs på ArangoDB:s Foxx Microservice- undersystem. Den har VCS -liknande semantik i många delar av sitt gränssnitt och stöds av en transaktionshändelsespårare . Bitemporalitet är listad som en av punkterna i dess utvecklingsfärdplan .

Temporala databaser var en av de tidigaste formerna av dataversionskontroll och påverkade utvecklingen av moderna dataversionssystem.

Alternativ


Exempel på modell med långsamt föränderlig dimension (SCD) ( klicka på bilden för att se)

Långsamt föränderliga dimensioner kan användas för att modellera tidsmässiga relationer.

Vidare läsning

  •   CJ Date , Hugh Darwen , Nikos Lorentzos (2002). Temporal Data & the Relational Model, första upplagan (Morgan Kaufmann-serien i datahanteringssystem); Morgan Kaufmann; 1:a upplagan; 422 sidor. ISBN 1-55860-855-9 .
  •   Joe Celko (2014). Joe Celkos SQL för Smarties: Avancerad SQL-programmering (Morgan Kaufmann-serien i datahantering); Morgan Kaufmann; 5:e upplagan. ISBN 978-0-12-800761-7 .—Särskilt kapitel 12 och 35 diskuterar tidsmässiga frågor.
  •     Snodgrass, Richard T. (1999). " Utveckla tidsorienterade databasapplikationer i SQL " (PDF) . (4,77 MiB ) (Morgan Kaufmann-serien i datahanteringssystem); Morgan Kaufmann; 504 sidor; ISBN 1-55860-436-7

Se även

externa länkar

Hämtad från " https://sv.wikipedia.org/w/index.php?title=Temporal_database&oldid=1144913228 "