Diskussion:Temporale Datenhaltung

Temporale Datenbank oder Temporale Datenhaltung

Habe lange überlegt, unter welchem Lemma ich diesen Artikel einstellen soll. Habe mich für letztere Variante entschieden, da aus meiner Sicht eine temporale Datenbank eine Datenbanksystem ist, das eine gewisse Unterstützung für temporale Daten bietet. Und da ich in diesem Artikel aber insbesondere die herkömmlichen relationalen Datenbanken betrachten wollte, habe ich mich für "temporale Datenhaltung" entschieden. Das wird nicht grundsätzlich so gesehen, z.B. wird in der englischen WP das Thema unter Temporal Database behandelt.--Cactus26 09:55, 7. Mär. 2007 (CET)

In den EDV-Projekten bei Banken und Versicherungen, in denen ich in den letzten Jahren mitgearbeitet habe, wird nur der Begriff Historie verwendet. Daher wäre die Artikelbezeichnung Historie (Datenverwaltung) mE ein geeigneterer.

Ich habe diesen Artikel in die Begriffsklärung für Historie aufgenommen. Siehe dazu auch die Diskussion in Historie (Transaktionsverarbeitung). -- 82.135.37.138 11:10, 7. Mär. 2007 (CET)

Danke für Deinen BKL-Eintrag. Mir bekannt war eher der Begriff Historisierung. Dort hatte ich den BKL bereits ergänzt. Allerdings hat sowohl der Begriff "Historie" als auch "Historisierung" das Problem, dass damit sich zukünftige Daten schlecht vereinbaren lassen, die aber beim Thema temporale Daten auch, wenn auch selten, relevant sind. Im "offiziellen" Sprachgebrauch hat sich deshalb wohl der Begriff "Temporalität" durchgesetzt (siehe auch Literatur), auch wenn er ugs. kaum verwendet wird.--Cactus26 11:25, 7. Mär. 2007 (CET)

Dir auch danke für den Hinweis. Mir ist gar nicht aufgefallen, dass es auch noch den Begriff Historisierung gibt. Die beiden Begriffsklätungen sollten miteinander verbunden oder verschmolzen werden, denn das eine bezeichnet den Vorgang und das andere eine Fragment der Daten. Ich habe einen Hinweis in die Diskussuin der beiden Artikel aufgenommen. -- 82.135.37.138 10:23, 8. Mär. 2007 (CET)

Im Hinblick auf die Verarbeitung und das Vorhalten von Daten dürfte 'Temporale Datenhaltung' als Lemma geeigneter sein. Temporale Datenbanken bzw. DBMS sind Produkte, welche die Datenhaltung spezifisch unterstützen. Nun gibt es mit dem Lemma aber dennoch ein paar Probleme: 1. Bis heute ist die Verlinkung zu Datenhaltung 'rot' - es gibt also noch keinen Artikel zu dem übergeordneten Begriff, von welchem 'Temporale Datenhaltung' dann als eine besondere Ausprägung hier gesondert beschrieben werden würde. 2. Die Annahme, dass es entsprechend dem Lemma auch eine 'Nicht-Temporale Datenhaltung' gibt, ist in sich selbst falsch, denn jede Datenhaltung findet in dem Kontinuum statt, welches wir Zeit nennen. Die Daten werden in der Zeit mindestens geschrieben, eventuell auch gelesen, überschrieben oder gelöscht. 3. Die Differenzierung der unterschiedlichen Zeit-Bezüge der Datenhaltung wird nicht grundlegend und vollständig so herausgearbeitet, dass die Abgrenzung zu anderen Datenhaltungskonzepten analytisch sauber gelingt. Wenn man von 'Temporale Datenhaltung' im Engeren sprechen will, sollte zumindest eine Abgrenzung über die Unterschiede bezüglich 'Transaction/Declaration- (Write), Valid-, Evaluated- und Reporting- (Read) -Time' vorliegen. --Piusbmaier (Diskussion) 15:30, 16. Nov. 2023 (CET)

Einfache und doppelte Historisierung

In dem Artikel wird nur die einfache Historisierung beschrieben. Es gibt auch noch eine doppelte Historisierung. Dabei wird nicht nur das Änderungsdatum, sondern auch noch das Gültigkeits-Datum im Schlüssel gespeichert. Ich habe vor, diesen Artikel beizeiten entsprechend zu ergänzen. -- 82.135.37.138 11:10, 7. Mär. 2007 (CET)

Das stimmt nicht ganz. Genau das ist mit Gültigkeits- und Transaktionszeit bzw. bitemporal gemeint. Allerdings bezieht sich keines der später detaillierten Beispiele tatsächlich auf bitemporale Fälle, das ist wohl das, was du vermisst. Allerdings halte ich das für zu komplex, um es in den Beispielen weiter auszuführen. Ich würde Dich auch bitten, Dich vor einer Ergänzung mit mir abzustimmen.--Cactus26 11:18, 7. Mär. 2007 (CET)

Einverstanden. Ich werde den Text erst mal hier eintragen. -- 82.135.37.138 10:24, 8. Mär. 2007 (CET)

Hier eine Anmerkung zu dem SQL-Statement: Ich finde die Formulierung schöner, wenn man die Prädikalt möglichst in der Form <Tabellenspalte> <Operator> <Expression> schreibt. Daher würde ich das SQL-Statement so formulieren:

Hast Du völlig Recht, keine Ahnung warum ich es so herum ausgedrückt habe, vermutl. weil ich mit dem auf meinem Browser nicht dargestellten Underscore bei CURRENT_DATE experimentiert habe, habe es angepasst.--Cactus26 07:18, 14. Mär. 2007 (CET)

 SELECT ArtNr, Preis 
   FROM Artikel AS a
  WHERE a.GueltigAb  <= :Abfrage_Gültigkeit 
    AND a.UngueltigAb > :Abfrage_Gültigkeit

Analog würde ein SQL-Statement für die bitemporale Datenhaltung aussehen:

 SELECT ArtNr, Preis 
   FROM Artikel AS a
  WHERE a.GueltigAb   <= :Abfrage_Gültigkeit 
    AND a.UngueltigAb  > :Abfrage_Gültigkeit
    AND a.geändertAm         <= :Abfrage_Änderung 
    AND a.naechste_ÄnderungAm > :Abfrage_Änderung

Ich kämpfe noch ein wenig mit mir, ob wir das noch ergänzen sollen. Dann müsste eigentlich auch noch die Variante für die Point-Representation dargestellt werden und dann wird es schon sehr viel SQL. Auch mit einer aussagekräftigen Benennung der das TZ-Intervall definierenden Spalten, insbesondere dem Ende, habe ich (wie du wohl auch) ein bisschen ein Problem. Vielleicht besser "GeloeschtAm"? In "wirklichen" Projekten sind die Spalten ja meist technischer benannt, aber das wollte ich hier vermeiden. --Cactus26 07:19, 14. Mär. 2007 (CET)

Manche Autoren, die Vorträge auf Tagungen und Kongressen halten, haben den folgenden Maßstab: Ein Drittel muss für fachfremde Zuhörer eine leicht verständliche Einführung in das Thema sein. Das zweite Drittel gibt Fachleuten wichtige und neue Erkenntnisse. Das dritte Drittel muss man selber nicht 100% verstehen. Das ist vielleicht etwas überspitzt, doch finde ich es einen guten Maßstab für Wikipedia-Artikel. Ich finde, hier sollten ruhig auch alle möglichen komplizierten Begriffe und Sachverhalte erläutert werden. Es ist schließlich ein Lexikon. (JM) -- 82.135.37.138 17:04, 14. Mär. 2007 (CET)

Ok überredet, habe die Beispiele für den bitemporalen Fall ergänzt. Prüfe sie bitte.

Nettes Beispiel mit den drei Dritteln bei Vorträgen. Hoffe nur, dass Fachfremde hier tatsächlich auf ihr Drittel kommen und auch, dass der Anteil, den ich selbst nicht so richtig verstehe, nicht ganz ein Drittel ist.--Cactus26 15:49, 16. Mär. 2007 (CET)

Horizontale Fragmentierung (Partitionierung)

Im Artikel selbst habe ich schon mal == Siehe auch == zu den verwandten Artikeln eingetragen, auch wenn zwei der Begriffe als Link schon im Text enthalten sind. Fragmentierung habe ich deswegen aufgenommen, weil bei der Datenspeicherung oft zwischen aktuell gültigen und früher mal gültigen Daten getrennt wird. Diese Bereiche können auf unterschiedlichen Speichermedien abgelegt werden. Ich glaube, im Artikel wird darauf noch nicht explizit eingegangen. Sollte vielleicht noch ergänzt werden. -- 82.135.37.138 10:24, 8. Mär. 2007 (CET)

Kennst Du einen solchen Zusammenhang zur Fragmentierung aus der Praxis? Ich halte das für schwierig, da dann ja bei Erfassung neuerer Daten die bisher gültigen von einem Fragment ins andere umgezogen werden müssten. Oder wie stellst Du Dir die Verwendung der Fragmentierung im Zusammenhang mit temporalen Daten vor?--Cactus26 11:04, 8. Mär. 2007 (CET)

Das Partitionierungskonzept vom DB2 zOS ist speziell darauf ausgerichtet. Hier kann man z.B. je eine Partition für die Daten eines Monats einrichten. Die Partitionen können dann rotieren (die älteste wird gelöscht und eine neue für den kommenden Monat wird angelegt) und unabhängig voneinander administriert (Backup, Recover, Reorg) werden. Auf der einen Partition können Programme lesen und schreiben, während andere Partitionen reorganisiert werden. Wenn die Daten der letzten 3 Jahre aufgehoben werden müssen, dann wäre das eine Einteilung in 36 Fragmente.

Dieses Verfahren ist, wenn ich es richtig verstehe, auf eine zyklische Historisierung zugeschnitten. Habe ich unter vereinfachende Abbildungen kurz erwähnt. Dort habe ich einen Hinweis auf Partitionierung ergänzt. Schau das dir mal an.--Cactus26 07:12, 9. Mär. 2007 (CET)

Ein weiteres Beispiel wäre die Duplizierung aller Tabellen eines Datenmodells. In dem einen Set von Tabellen werden die aktuellen Daten gespeichert und in dem anderen die nicht mehr aktuellen. Das hat den Vorteil, dass 99% aller Daten in den Historien-Tabellen liegen (Zugriffszeiten bis zu einer Minute), während 99% aller Zugriffe nur auf die Tabellen mit den aktuellen Daten (nur 1% des Datenvolumens) zugreifen (Zugriffszeit < 1 Sek). Bei dieser Variante müssen Programme die Daten bei Schreib-Zugriffen vom einen Fragment ins andere übertragen. Das kann man gut durch Trigger lösen. In diesem Fall würde man jede Tabelle in zwei Fragmente unterteilen. Eine Dreiteilung wird auch manchmal gewählt. Dann werden die "ganz alten" Daten auf Magnetkassetten geschrieben und im Tresor aufbewahrt. In einem Projekt wurde das so gelöst, dass zu Beginn eines Monats die Daten, die von vor x Monaten von der DB in Dateien exportiert wurden. Die Sätze in der DB wurden dann gelöscht und die Export-Dateien auf Magnetbänger gebracht. In diesem Zustand mussten die Daten dann noch weitere 20 Jahre aufgehoben werden wegen gesetzlicher Vorschriften. -- 77.176.0.198 20:52, 8. Mär. 2007 (CET)

Dieses Vorgehen entspricht im Prinzip wohl dem, was ich bei vereinfachende Abbildungen unter Auslagerung der Historie erwähnt habe. Auch dort könnte man vielleicht noch etwas aus Deinen Angaben ergänzen. Auf jeden Fall vielen Dank für diese detaillierten Angaben!--Cactus26 07:12, 9. Mär. 2007 (CET)

Grundsätzlich frage ich mich, warum der Artikel zu diesem Thema horizontale Fragmentierung und nicht Partitionierung (Datenbanken) heißt. Dann hätte ich schneller verstanden, was Du meinst.--Cactus26 11:52, 9. Mär. 2007 (CET)

Horizontale Fragmentierung kann man als Partitionierung realisieren. Es gibt aber auch andere Realisierungsmöglichkeiten. Daher ist das nicht dasselbe. Siehe Horizontale Fragmentierung # Horizontale Fragmentierung beim Datenbankdesign. Im Übrigen ist Partitionierung auch ein Begriff, dem jedes DBMS eine geringfügig andere Gestaltung verleiht. Ich schreibe gerade an einer Erweiterung für den Artikel DB2. Hier sieht die Partitionierung für DB2 z/OS ganz anders aus, als die Partitionierung für DB2 LUW. Aus diesem Grund fänfe ich einen allgemeinen Artikel Partitionierung (Datenbanken) nicht sinnvoll. Die P. sollte in den einzelnen Artikeln zu den Datenbank-Produkten, DB2, Oracle, Microsoft SQL Server erläutert werden.

Ich fände es wichtig, dass der Link auf die horizontale Fragmentierung irgendwo in dem Artikel Temporale Datenhaltung vorkommt. Ein bloßes Einfügen unter Siehe auch war vielleicht keine so gute Idee. Sicher wäre ein erläuternder Satz dazu noch angebracht. Ein Verweis auf einen Artikel Partitionierung (Datenbanken), den es gar nicht gibt, und wo nochnicht einmal feststeht, dass es diesen Artikel zukünftig einmal geben wird, finde ich nicht besonders sinnvoll. -- 77.176.45.241 18:30, 10. Mär. 2007 (CET)

Danke für Deine ausführliche Erläuterung. Hatte im Artikel bereits einen Link auf horizontale Fragmentierung ergänzt, unter der bezeichnung "Partitionierung". Wenn ich es richtig sehe, ist es also bereits so, wie Du es für sinnvoll hältst. Sehe ich das richtig? --Cactus26 09:01, 11. Mär. 2007 (CET)

Einleitung

Entschuldige, ich weiß, Du meinst es gut. Aber ich habe meine Einleitung des Artikels im wesentlichen wiederhergestellt. Ich finde meine einfacher. Sage mir bitte, was Dir an meiner nicht gefällt. Liebe Grüße--Cactus26 18:05, 9. Mär. 2007 (CET)

1. Satz:
   1. Speicherung von Daten != Speicherung von Daten in einer Datenbank
2. Satz:
   1. Datenverlust wird nicht explizit genannt.
   2. Es wird nicht darauf hingewiesen, dass eben dieser Datenverlust je nach Szenario akzeptabel oder nicht akzeptabel sein kann.

Derart wesentliches darf man mE in der Einl. nicht unterschlagen, auch wenn dir deine Version durch die genannten Auslassungen "einfacher" erscheinen mag. Die Welt ist eben nicht einfach ;-). Und allgemeinverständlich ist die neue Formulierung obendrein. Gruß, --Contributor 18:23, 9. Mär. 2007 (CET)

Mal im Ernst, findest du folgenden Satz einfach:

Um diesen Datenverlust zu verhindern, wird bei der temporalen Datenhaltung sämtliche relevanten Werte fortlaufend gespeichert, insbesondere damit man später rekonstruieren kann, welcher Wert zu welchem Zeitpunkt gültig war oder - in weniger häufigen Fällen - auch gültig werden wird.

Außerdem ist dir da wohl ein grammatikalischer Fehler unterlaufen.

Du solltest respektieren, dass ich mir bei diesem Artikel viel Mühe gegeben habe und das auch, was die Einleitung anbelangt. Ich werden Deine Anregungen aufnehmen und die Einleitung nochmals überarbeiten. Ich möchte Dich aber jetzt schon bitten, meine Überarbeitung dann nicht mehr zu revertieren. --Cactus26 18:35, 9. Mär. 2007 (CET)

Hmm, ich kann mich mit der Aenderung von Contributor auch nicht so recht anfreunden. Zum einen finde den Stil nicht besonders gelungen zum anderen kann man wohlkaum von Datenverlust reden. Bei operationalen Daten werden diese vielmer bewusst geloescht, was dann ja kein Verlust mehr ist. Waere ja so, also ob ich einen Verlust haetten, wenn ich meinen Muell entsorge. -- sparti 18:45, 9. Mär. 2007 (CET)

@Cactus: Mein zweiter Satz ist in der Tat kein Glanzstück, wichtiger war mir inhaltlich aber jener davor. Die jetzige Fassung gefällt mir zwar schon besser. Die Formulierung "normalerweise" ist mir jedoch nach wie vor ein Dorn im Auge. Es geht eben nicht darum, was normal ist und was nicht, sondern was im Einzelfall entsprechend der Anforderungen benötigt wird und was nicht.

@sparti: Auch die Frage, ob ein Datenverlust vorläge, ist idR an die Anf. gekoppelt. --Contributor 19:10, 9. Mär. 2007 (CET)

Die Einleitung finde ich zu lang und auch einige Formulierungen gefallen mir nicht. Meine Kommentare habe ich mit (JM:) gekennzeichnet:

Unter temporaler Datenhaltung (auch Historisierung genannt) versteht man im Zusammenhang mit die zeitabhängige Speicherung in einer Datenbank.

(JM):Ich bin der Meinung, dass temporale Datenhaltung nicht an die Speicherung in einer Datenbank geknüpft ist. Die Daten können auch in Dateien gespeichert werden und vom Betriebssystem verwaltet werden. Gerade die alten Daten, die nur noch für Revisionen oder zur Erfüllung der gesetzlichen Vorschriften aufbewahrt werden, werden sogar in den meisten Fällen nicht mehr in Datenbanken gespeichert. Hier werden oft Magnetbänder oder Mikrofiche eingesetzt.

Normalerweise wird in einer Datenbank nur der jeweils aktuell (heute) gültige Wert gespeichert, bei einer Änderung wird der alte Datenwert einfach überschrieben. Hierdurch ist der alte Inhalt verloren und kann nicht mehr so ohne weiteres rekonstruiert werden. Falls dies nicht akzeptabel ist, ist eine temporale Datenhaltung erforderlich. Diese ermöglicht zu rekonstruieren, welcher Wert zu welchem Zeitpunkt gültig war oder - in weniger häufigen Fällen - auch gültig werden wird.

(JM):Ich finde Ausdrücke wie "Normalerweise" oder "wenn es nicht akzeptabel ist" für eine Einleitung nicht passend. Besser fände ich die folgende Formulierung:

(JM):Wenn die Forderung besteht, dass nicht nur die aktuell gültigen Daten gespeichert werden sollen, sondern auch alle bisher durchgeführten Änderungen dokumentiert werden müssen, dann muss die Temporale Datenhaltung eingesetzt werden.

Bezüglich temporaler Datenhaltung sind zwei Arten der zeitlichen Betrachtung relevant:

• Gültigkeitszeit: Der Zeitraum, in der ein Datenelement in der realen Welt gültig ist.
  Beispiel: Ein Artikel zum Preis von 1,95 € verteuert sich am 01. Juni 2006 auf 2,25 €.
• Transaktionszeit (auch Bearbeitungszeit): Der Zeitpunkt, an dem ein Datenelement im Datenbestand gespeichert wurde.
  Beispiel: Obige Preisanpassung des Artikels wurde am 25. Mai 2006 bearbeitet und in den Datenbestand aufgenommen.

In manchen Fällen sind dabei tatsächlich beide Arten relevant, hierfür verwendet man auch den Ausdruck „bitemporal“.

(JM):Hier würde ich die Einleitung erst mal beenden. Den nächsten Satz und die Abbildung würde ich irgendwo später einbauen. Eine Einleitung sollte so kurz wie möglich sein und doch die wesentlichen Aspekte im Überblick kurz erwähnen. Eine Erläuterung der Details (und auch Abbildungen) gehören hier nicht hin.

Dies gilt z.B. bei Beantwortung folgender auf obige Beispiele bezogenen Frage: Welcher Preis wurde einem Kunden am 20. Mai 2006 für den Kauf des Artikels genannt, wobei der Kauf erst am 15. Juni 2006 stattfinden sollte?

-- 77.176.45.241 18:04, 10. Mär. 2007 (CET)

Hallo JM,

dein Vorschlag gefaellt mir gut und auf jedenfall besser als die jetzige Version. Allerdings muss ich Dir im Punkt widersprechen, wo Du sagst, dass nicht immer eine Datenbank benoetigt wird. Es handelt sich durchaus immer um eine Datenbank. Die Defintion einer Datenbank sieht die Faelle oben alle vor. Richtig ist aber, dass fuer temporale Datenhaltung kein Datenbankmanagementsystem benoetigt wird. Aber das wurde ja auch nicht behauptet. -- sparti 19:05, 10. Mär. 2007 (CET)

Kritik angenommen. Da hast du 100% Recht. Diese Unterscheidung sollte auch aus dem Artikel deutlich werden. (JM) -- 77.176.45.241 22:12, 10. Mär. 2007 (CET)

Ich danke Euch für Euere Anregungen! Und vor allem auch dafür, dass ihr mir hier auf der Diskussionsseite die Chance gebt, direkt Stellung zu nehmen. Also:

• Datenbank/ohne Datenbank
  Ich denke, der Begriff "temporale Datenhaltung" besitzt (bislang) keine so offizielle Bedeutung, so dass beide Interpretationen möglich sind. Da sich in diesem Artikel dieser Begriff aber ausschließlich auf Datenbanken bezieht, sollte das aus der Einleitung auch so hervorgehen.
• Normalerweise/akzeptabel
  Diese Begriffe finde ich auch nicht besonders gelungen. Mit "Normalerweise" will ich aber zum Ausdruck bringen, dass es einfach nicht der Standardfall im Bereich Datenbanken ist, historisiert zu speichern. Und das ist auch richtig so, wenn man es nicht anders braucht. Deine (JM) Einleitung finde ich auch ganz gut, habe versucht Teile davon zu integrieren. Schwierig ist aber bei Deiner Variante, die Kurve zu den zukünftigen Daten zu bekommen, da Deine Version m.E. zu TZ-lastig ist.
• Länge der Einleitung
  Finde ich nicht problematisch. Für einen Nicht IT-ler ist das das einzige, was er kriegt, deshalb finde ich hier eine gewisse "epische Breite" auch nicht nachteilig. Der erste Satz sagt grob um was es geht. Der nächste Abschnitt detailliert es noch ein bisschen. Dann die Fallunterscheidung GZ/TZ, verzahnt mit dem Beispiel. Das halte ich für absolut wichtig, auch das Beispiel in der Einleitung! Mein Ziel ist, dass auch ein Nicht-Insider in dieser Einleitung den Unterschied zwischen GZ und TZ versteht. Der Rest dürfte dann unverdaulich sein.

Natürlich ist das alles auch subjektiv. Ich denke auch, dass jeder ein etwas anderen Fokus auf das Thema hat, abhängig davon, aus welcher Ecke er kommt. Ich habe versucht, bevor ich diesen Artikel geschrieben habe, meine Kenntnisse und praktischen Erfahrungen um weitere theoretisch Grundlagen und Erfahrungsberichte zu erweitern, um einen möglichst objektiven Blickpunkt auf dieses Thema zu bekommen. So ganz geht das natürlich nie. Es freut mich aber, dass ihr das honoriert und mir die Chance gebt, über Eure Anregungen redaktionell zu entscheiden.--Cactus26 09:33, 11. Mär. 2007 (CET)

Jetzt gefällt mir die Einleitung viel besser. Noch eine Anmerkung: "In manchen Fällen sind dabei tatsächlich beide Arten relevant". Hier würde ich die beiden Begriffe "einfache Historisierung" und "doppelte Historisierung" noch reinbringen, da Wikipedia ja den Anspruch eines Lexikons hat und vielen Leuten einfach diese (bzw. nur diese) Begriffe geläufig sind. Schade finde ich, dass du die Auslagerung der Daten auf Magnetbänder oder Mikrofiche noch nicht erwähnst (nicht in der Einleitung, sondern im nachfolgenden Artikel) Das scheint mir ein sehr wichtiger Aspekt dieses Themas zu sein. (JM) -- 82.135.37.138 09:26, 12. Mär. 2007 (CET)

Der letzte Punkt faellt fuer mich unter Archivierung und gehört in meinen Augen in den Datenbankartikel. -- sparti 11:13, 12. Mär. 2007 (CET)

Archivierung: Ich könnte mir schon vorstellen, das Thema hier zu behandeln. Bisher habe ich nur einen Hinweis auf diese Problematik in der Einleitung zur Abbildung in rel. DB ergänzt. Ich denke aber, dass eine Bereinigung bzw. Archivierung durchaus ein Thema ist, was bei temporaler Datenhaltung grundsätzlich relevant ist, also auch bei echten temporalen Datenbanken. Möglicherweise ist ein separates Kapitel zu diesem Thema sinnvoll, derzeit habe ich aber zu wenig Quellen zu diesem Thema, um hier fundiert Stellung nehmen zu können. Werde den Punkt aber in jedem Fall im Auge behalten.

"Doppele Historisierung": Konnte bisher keine Quellen finden, die diesen Begriff auch verwenden würden. Er scheint eher bei der Bedeutung Historisierung=Geschichtswerdung verwendet zu werden, nicht im Kontext mit Datenbanken (@JM: Kennst Du Quellen oder ist das bei Euch vielleicht ein projekt-interner Slang?).

--Cactus26 14:30, 12. Mär. 2007 (CET)

Ich kenne diesen Begriff nicht aus der Literatur, sondern nur aus den Projekten, in denen ich bisher mitgearbeitet habe. Zugegebenermassen habe ich bisher fast nur in der Banken-Branche gearbeitet und bin daher vielleicht etwas einseitig geprägt. Aber bei der Dresdner Bank, der HypoVersinsbank und bei der IZB-Soft, dem RZ der bayerischen Sparkassen wurden diese Begriffe von allen Beteiligten so verwendet. Eigentlich ist das doch Legitimation genug, um so einen Begriff ins Wikipedia aufzunehmen. (JM) -- 82.135.37.138 17:16, 14. Mär. 2007 (CET)

Zur Bemerkung von Sparti: Man könnte diesen Punkt auch in dem Artikel Temporale Datenbank beschreiben. Denn der Datenbank-Artikel ist eher algemein gehalten und auch gesperrt für Änderungen. Frank Roeing (EFR), der diesen Artikel bearbeiten kann, ist der Meinung, dass nicht alle Details in diesen Artikel reingehören. Vielleicht wäre es auch sinnvoll, für die Archivierung einen ganz neuen Artikel anzufangen, auf den dann im Datenbank-Artikel und von hier verwiesen wird. Ich hätte noch weiteres Material für so einen Artikel. (JM) -- 82.135.37.138 17:16, 14. Mär. 2007 (CET)

Archivierung

Anfängliche Diskussionsbeiträge (leicht modifiziert) extrahiert aus Einleitung.--Cactus26 07:13, 16. Mär. 2007 (CET)

Schade finde ich, dass du die Auslagerung der Daten auf Magnetbänder oder Mikrofiche noch nicht erwähnst (nicht in der Einleitung, sondern im nachfolgenden Artikel) Das scheint mir ein sehr wichtiger Aspekt dieses Themas zu sein. (JM) -- 82.135.37.138 09:26, 12. Mär. 2007 (CET)

Dieser Punkt faellt fuer mich unter Archivierung und gehört in meinen Augen in den Datenbankartikel. -- sparti 11:13, 12. Mär. 2007 (CET)

Archivierung: Ich könnte mir schon vorstellen, das Thema hier zu behandeln. Bisher habe ich nur einen Hinweis auf diese Problematik in der Einleitung zur Abbildung in rel. DB ergänzt. Ich denke aber, dass eine Bereinigung bzw. Archivierung durchaus ein Thema ist, was bei temporaler Datenhaltung grundsätzlich relevant ist, also auch bei echten temporalen Datenbanken. Möglicherweise ist ein separates Kapitel zu diesem Thema sinnvoll, derzeit habe ich aber zu wenig Quellen zu diesem Thema, um hier fundiert Stellung nehmen zu können. Werde den Punkt aber in jedem Fall im Auge behalten.--Cactus26 14:30, 12. Mär. 2007 (CET)

Zur Bemerkung von Sparti: Man könnte diesen Punkt auch in dem Artikel Temporale Datenbank beschreiben. Denn der Datenbank-Artikel ist eher allgemein gehalten und auch gesperrt für Änderungen. Frank Roeing (EFR), der diesen Artikel bearbeiten kann, ist der Meinung, dass nicht alle Details in diesen Artikel reingehören. Vielleicht wäre es auch sinnvoll, für die Archivierung einen ganz neuen Artikel anzufangen, auf den dann im Datenbank-Artikel und von hier verwiesen wird. Ich hätte noch weiteres Material für so einen Artikel. (JM) -- 82.135.37.138 17:16, 14. Mär. 2007 (CET)

Hallo JM, Du kannst den Artikel auch bearbeiten, wenn Du Dir einen Account zulegst. Deine Anonymitaet verlierst Du dadurch nicht. Im Uebrigen gibt es schon einen Artikel Archivierung. Natuerlich gibts auch Argumente dafuer, das Thema hier zu behandeln. -- sparti 21:16, 14. Mär. 2007 (CET)

Es gibt sogar elektronische Archivierung, einen sehr umfassenden Artikel zu diesem Thema. Vielleicht fehlt dort noch etwas. Im Artikel temporale Datenhaltung wäre in diesem Zusammenhang eher von Bedeutung, nach welchen Kriterien man entscheidet, Daten zu archivieren bzw. zu bereinigen und welche Konsequenzen das hat.--Cactus26 07:01, 15. Mär. 2007 (CET)

Dem kann ich nur zustimmen. Die Beschreibung der Speichermedien z.B. Mikrofiche gehört in den Artikel elektronische Archivierung. Nimm doch einen Link zu dem Artikel elektronische Archivierung in den Artikel Temporale Datenbank auf.

Zu den Kriterien, nach denen das Speichermedium gewählt wird, gibt es diese drei: 1. Müssen die Daten veränderbar sein? (Wenn nein, dann können sie z.B. auf WORM-Medien gespeichert werden) 2. wie schnell muss ein Lesezugriff ausführbar sein? (Sekundenschnell, mehrere Minuten oder mehrere Stunden Vorlaufzeit) und 3 der Preis. Evtl. auch noch 4. der Umfang der Daten, denn einige 100 MB kann man gut auf CD- oder DVD-Rohlinge brennen aber bei einen Datenbestand von 100 Terabyte macht dieses Medium wohl keinen Sinn.

Diese Kriterienliste könnte man auch in den Artikel Temporale Datenbank aufnehmen. Vielleicht findet jemand noch weitere Kriterien. (JM) -- 77.176.23.202 21:55, 15. Mär. 2007 (CET)

Habe da auch eine recht vielversprechende Quelle entdeckt. Wird aber ein bisschen dauern...--Cactus26 07:50, 16. Mär. 2007 (CET)

Die Quelle sieht ganz interessant aus. Was hier aber sicherlich nicht rein gehört sind Hardwarebetrachtungen. Die Auswahl der Geraete ist voellig unabhaengig vom temporalen Aspekt und treffen auf alle Archivierungsprobleme zu, also bitte auch in einem allgemeinen Artikel behandeln. -- sparti 08:16, 16. Mär. 2007 (CET)

Sehe ich - und wenn ich JM richtig verstehe nun auch er - exakt genauso.--Cactus26 08:26, 16. Mär. 2007 (CET)

Ok, hab ich offensichtlich missverstanden :) -- sparti 09:18, 16. Mär. 2007 (CET)

---

Habe nun einen Abschnitt "Archivierung und Bereinigung" ergänzt, werde diesem insbesondere zum Thema "Zerschneiden" zumindest noch ein Beispiel spendieren, damit das ganze hoffentlich verständlich wird.

Dabei bin ich nun zur Auffassung gelangt, dass ein Artikel Datenbankarchivierung neben den bestehenden Artikeln Datensicherung (enthält zwar Hinweis auf Datenbanken, das reicht aber m.E. nicht) und Elektronische Archivierung unbedingt noch nötig ist. Halte das Thema auch für sehr zukunftsträchtig, es gibt derzeit noch erstaunlich wenig Quellen dazu, vermutlich, weil das "hardwaremäßige Aufrüsten" bisher die Steigerung des Datenvolumens kompensieren konnte und kein ausreichender Leidensdruck besteht. Habe einen solchen hypothetischen Artikel bereits in diesem Artikel rotverlinkt. Folgendes Stichworte hätte ich dafür:

• Abgrenzung zu Backup-Verfahren
• Anwendungsorientierte Datenbankarchivierung, Klassifizierung der Verfahren (aus Pfister 2005, S. 22 bzw. Herbst 1997, S. 47)
• Der Standard ASQL
• IBM DB2 Data Archive Expert
• Literatur
  • Axel Herbst: Anwendungsorientiertes DB-Archivieren; Spinger; Berlin 1997; ISBN 3540632093
  • Ralf Schaarschmidt: Archivierung in Datenbanksystemen.: Konzept und Sprache; Teubner 2001; ISBN 3519003252

Werde möglicherweise einen Stub für diesen Artikel demnächst selber anlegen, obwohl das sicher nicht mein Spezialgebiet ist (@JM: das wäre doch was für Dich, wenn Du angemeldet wärst, könnte ich Dir diesen Hinweis auf deiner Diskussionsseite platzieren).

--Cactus26 10:52, 23. Mär. 2007 (CET)

Reviewprozess vom 7. März 2007

Hier geht es um die Speicherung von zeitabhängigen Informationen in Datenbanken. Ich habe bei dem Artikel primär an Leute gedacht, die sich mit Datenmodellierung auseinandersetzen (müssen) und dabei mit der Problematik zeitabhängiger Daten ("Historisierung") konfrontiert werden. Auch habe ich einen sehr starken Fokus auf die Abbildung in relationalen Datenbanken gelegt, weil dies am meisten relevant sein dürfte. Ziel war aber auch, dass auch Nicht-Insider mit dem Artikel was anfangen können, zumindest sollte die Problemstellung in der Einleitung für alle verständlich sein. Da bisher das Feedback für diesen Artikel sehr spärlich war, bitte ich nun hier um Kritik und Anregungen.--Cactus26 10:30, 7. Mär. 2007 (CET)

Spartis Review

• Also mal ganz schnell, vielleicht später noch mehr: Der Artikel ist schon recht gut und interessant geschrieben. Trotzdem hier ein Liste von Dingen die man noch verbessern kann: Erster Punkt der mich manchmal verwirrt ist, daß mal temporale Datenhaltung mittels Relationaler Datenbanken erläutert wird, mal nicht. Es wäre schön das klar zu trennen und einen eigenen Absatz dafür einzurichten. Alles andere sollte unabhängig vom Datenbankmodell erklärt werden. Was ich außerdem vermisse ist ein Hinweis auf Data Warehouse bzw. auf die Speicherung von historischen Daten in einem solchen. Es gibt dort bestimmt einiges an Überschneidung. Im Artikel steht zum Beispiel auch, dass alte Daten archiviert werden. Aber gibt es auch sowas wie Aggregation von Fakten über die Zeit, wie bei OLAP? Weiterhin finde ich es schade, dass nur sehr wenig über Temporale Datenbanken zu finden ist. Dein Artikel weckt automatisch Interesse an Datenbanken selbst. Kannst Du dazu auch noch was schreiben? Weiterhin fänd ich es recht wichtig auf die konsumierenden Anwendungen einzugehen, welche Anforderungen an die Temporale Datenhaltung gibt es? Abschließend noch ein paar Verständnisprobleme: Zu 2.3 Zeitstempelung: Wer ergänzt den Zeitstempel? Das DBMS oder die Anwendung? Dann finde ich das Beispiel über Coalescing noch nicht optimal. Das Attribut Ziellgrbst verschwindet einfach. Es wäre hilfreich auch dieses Attribut in einer normalisierten Tabelle wiederzufinden. Außerdem fänd ich es hilfreich eine formale Beschreibung zum Coalescing zu erhalten. Ok, trotzdem ist der Artikel auf dem richtigen Weg. Gruss -- sparti 12:35, 7. Mär. 2007 (CET)

Vielen Dank für Dein superschnelles Feedback! Ich versuche es mit einer ähnlich schnellen Antwort:

• Mal relationale Datenbanken, mal nicht
  Ich habe versucht, den 1. und 2. Abschnitt allgemein zu halten, diese sollten also grundsätzlich für alle Datenbanksysteme gelten. Erst der 3. Abschnitt ist speziell auf rel. DB bezogen. Wenn Du das anderes empfunden hast, kannst Du mit Stellen nennen, an denen ich diese Struktur durchbreche?

Hmm, das war mehr ein Eindruck. Wenn ich jetzt mal nachsehe, dann sprichst Du in 2.2 und 2.3 ueber SQL und Tupel. Wobei ich bei Tupel hier vielleicht garnicht das relationale Modell meint. Ist wohl nicht so schlimm :) -- sparti 01:41, 8. Mär. 2007 (CET)

• Hinweis Data-Warehouse
  Da hast Du absolut Recht. Beim Data-Warehouse spielen temporale Daten eine große Rolle, manchmal wird die Historie ja erst beim (periodischen) Import in ein Data-Warehouse erstellt und ist in der liefernden operativen DB gar nicht vorhanden. Werde mir Gedanken machen, wie ich hierzu was ergänzen kann.
• Überschneidungen mit OLAP
  Hier sehe ich nicht unbedingt Überschneidungen, da OLAP sich "nur" auf die Auswertung der Daten bezieht, kenne mich da aber nicht so sonderlich aus. Der Hinweis auf die Archivierung älterer Daten ist in meinem Artikel nur als (selbst zu implementierender) Optimierungsvorschlag bei einer Abbildung in rel. DBs gemeint. Dass temporale Datenbanken hier einen Automatismus bieten, ist mir zumindest nicht bekannt.

Ja, das stimmt schon. Ich meinte zwar eigentlich die OLAP-Cube Berechnung. Aber der Vergleich passt nicht so gut. Besser waere also ein Vergleich mit Aggregationstabellen, die aeltere Daten verdichtet. -- sparti 01:41, 8. Mär. 2007 (CET)

• "Echte" temporale Datenbanken
  Leider weiß ich über diese auch sehr wenig, mein Wissen stammt größtenteils aus Dem Buch von T. Myrach. Lt. dessen Aussage gibt es im Moment aber auch keine kommerziellen derartigen Produkte sondern nur Prototypen. Ich könnte hierzu aber ggf. noch was im Artikel Temporale Datenbanken ergänzen.
• "konsumierende" Anwendungen
  Da hast Du recht, wäre interessant. Aber um hier einen repräsentativen Querschnitt bieten zu können (und nicht nur meine eigene Erfahrung) müsste ich ein wenig forschen.
• Wer ergänzet den Zeitstempel?
  Das kommt drauf an. Bei "normalen" rel. DB ist es das Anwendungsprogramm (oder ein zur Entwicklung verwendetes Framework). Bei temporalen DB gibt es implizite und explizite Zeitstempelung. Bei der Gültigkeitszeit müssen die eigentlichen Zeitangaben aber in jedem Fall (in welcher Form auch immer) vom Anwendungsprogramm kommen. Wie könnte ich das im Artikel klarer ausdrücken?

Genau so :) -- sparti 01:41, 8. Mär. 2007 (CET)

• Beispiel Coalescing
  Würde es dir besser gefallen, wenn einmal eine normaliserte Darstellung für den Preis und einmal eine für den Ziellagerbestand erfolgen würde?

Ja. -- sparti 01:41, 8. Mär. 2007 (CET)

• Formale Definition für Coalescing
  Über den Einzelnachweis bei Coalescing kann man eine Definition erhalten. Sollte ich noch zusätzlich im Artikel etwas ergänzen?

Ja, das faend ich interessant. -- sparti 01:41, 8. Mär. 2007 (CET)

--Cactus26 14:43, 7. Mär. 2007 (CET)

Habe folgendes ergänzt/angepasst:

• Wer ergänzt den Zeitstempel? in Zeitstempelung
• Formale Definition und Beispiel in Temporale Normalisierung (Coalescing)

Schau Dir's mal an, wenn Du Zeit hast. Deine restlichen Anmerkungen habe ich nicht vergessen, aber das dauert etwas länger...--Cactus26 11:20, 9. Mär. 2007 (CET)

Habe mittlerweile auch Typische Anwendungsgebiete ergänzt und dort auch das Data-Warehouse untergebracht. Schau Dir's mal an.--Cactus26 17:53, 9. Mär. 2007 (CET)

Kurts Kommentar

Hallo Cactus, erst was technisches: fette Hervorhebungen sind in der WP komplett verpönt, kursive sparsam anzuwenden. Ich hab da mal im Artikel gewütet und die Hervorhebungen reduziert. Inhaltlich: Ich hab den Artikel leider nicht komplett gelesen, bin grad im Stress. Ein paar Punkte trotzdem:

• wie funktionieren nicht-relationale Implementierungen temporaler DB?
• wer hat den Begriff (wann) geprägt, in welchem Zusammenhang wird er eingesetzt. So wie es hier aussieht, ist ja fast jede DB eine temporale DB, wenn sie Tabellen mit Zeitstempeln benutzt. Wie kann man den Begriff sauber abgrenzen?

Ich hoffe, ich werd später (Ende nächster Woche) mehr Zeit zum Lesen finden und noch ein paar Anregungen bringen. Viele Grüße, Kurt Seebauer 13:53, 9. Mär. 2007 (CET)

Danke für Dein Feedback (nicht ganz ohne Hintergedanken fett ;-) ). Ich halte herkömmliche relationale Datenbanken nicht für temporale Datenbanken, da sie keine über temporale Datentypen hinausgehende Unterstützung der Zeitabhängigkeit bieten (siehe auch separater Artikel und auch Diskussion). Dennoch kann man in diesen Datenbanken temporale Daten abbilden, muss dann aber alles selber machen. Vor anderen Datenbanken als relationalen habe ich mich ja ein wenig gedrückt (siehe Hinweis bei objektorientierten Datenbanken), da ich behaupte (wozu ich stehe), dass zu diesen keine einheitlichen Aussagen möglich sind. Ein Teil der Aussagen dieses Artikels wird aber dennoch auch auf diese Datenbanken zutreffen. Allerdings fehlen mir da die praktischen Erfahrungen.

Was die Namensherkunft betrifft: Hier bin ich bisher auf Vermutungen angeweisen. Ich denke, es kommt aus dem Englischen (temporal database, ein heißer Tipp für die Urheberschaft wäre Snodgrass). Unter "Praktikern" wird dieser Ausdruck im deutschsprachigen Raum aber so gut wie nicht verwendet. Da spricht man meist von "Historisierung". --Cactus26 15:04, 9. Mär. 2007 (CET)

Ich glaube Kurt meinte weniger, wie der Name entstanden ist, als vielmehr wer den Namen etabliert hat. Das heisst gibt es eine allgemein anerkannte Quelle, die diesen Begriff verwendet? -- sparti 18:48, 9. Mär. 2007 (CET)

Im Englischen ist es eindeutig, in jedem Fachartikel wird m.E. immer "temporal Database" verwendet. Im Deutschen ist in Fachartikeln "temporale Datenbanken/Datenhaltung" für dieses Thema üblich, der ugs. übliche Ausdruck "Historisierung" wird im "offiziellen" Sprachgebrauch eigentlich nie verwendet, bestenfalls erwähnt. Kämen wir wieder zum Problem "Datenbank/Datenhaltung", dass ich ja auch schon auf der Diskussionsseite aufgerollt habe. T. Myrach verwendet "Datenbanken", A.Demelt "Datenhaltung". Eine Google Suche hilft hier nicht bzgl der Entscheidung, "Temporale Datenbanken" wird zwar häufiger gefunden, man kann aber nicht so ohne weiteres erkennen, ob der Begriff für "echte" temporale Datenbanken verwendet wird. Ich denke, die Entscheidung, ob man herkömmliche Datenbanken, die temporale Daten abbilden, auch als "temporale Datenbanken" bezeichnet, hängt damit zusammen, ob man den Begriff "Datenbank" als Typ (Klasse) oder Instanz interpretiert. Die gesprochene Sprache ist da ja im Ggs. zu Programmiersprachen ungenau. Wenn man unter "Datenbank" die Klasse, also das Datenbanksystem sieht, kann man herkömmliche Datenbanken nicht als temporal bezeichnen. Wenn man hingegen "Datenbank" als Instanz deutet, also als eine konkrete Datenbankinstallation, kann man das. Für mich ist die Klassen-Interpretation intuitiv einleuchtender, deshalb habe ich mich so entschieden.--Cactus26 10:12, 11. Mär. 2007 (CET)

Kurts Review

So, ich hab den Artikel jetzt auch gelesen. Ich finde ihn ganz gelungen, aber einige Verbesserungsvorschläge/Kommentare hab ich noch:

GZ und TZ in der Einleitung

• Der Abschnitt "Gültigkeitszeit und Transaktionszeit" wiederholt im Wesentlichen einen Teil der Einleitung. Würde ich deswegen aus der Einleitung streichen, sonst haben wir die Info zweimal.

Hm. Mir ist die Einführung von GZ und TZ in der Einleitung schon sehr wichtig, da ich es dort auch für einen Nicht IT-ler verständlich erklären will. Ich fand auch die Wiederholung nicht so verkehrt, da dies ja ein sehr zentraler Punkt dieses Themas ist. Eher würde ich im zweiten Teil etwas "abspecken". Was schlägst Du vor?--Cactus26 08:38, 19. Mär. 2007 (CET)

die ausführliche Erklärung sollte schon im Hauptteil erfolgen. Die in der Einleitung sagt aber schon fast alles. Vielleicht kann man die noch ein bisschen abspecken und das Beispiel rausnehmen?

Halte das Beispiel in der Einleitung gerade für so wichtig. Meine Erfahrung ist, dass man ohne ein Beispiel ewig versuchen kann, den Unterschied zwischen GZ und TZ zu erklären, ohne dass was ankommen würde. Und meine Erfahrung bei Vorträgen ist auch, je früher ein praktisches Beispiel, um so besser. Das motiviert folgende Theorie überhaupt aufzunhemen.--Cactus26 08:01, 20. Mär. 2007 (CET)

Also ich finde Redundanz hier durchaus hilfreich. Allerdings finde ich auch, dass das Beispiel die Einleitung ueberlaedt. Daher wuerde ich das Beispiel in den Hauptteil ziehen. -- sparti 09:23, 20. Mär. 2007 (CET)

Nehme das alles erst einmal zur Kenntnis, möchte aber noch abwarten, bis sich ein echter Laie mal hierzu äußert.--Cactus26 12:01, 20. Mär. 2007 (CET)

Attribut- versus Tupel-Zeitstempelung und Normalisierung

• Ab Abschnitt Temporale Normalisierung (Coalescing): Es wird immer angenommen, dass das temporale Attribut (Preis) in der gleichen Tabelle wie das Entity (Artikel) gespeichert wird, aber das verstößt doch gegen die 2NF. So macht man das sicher nicht. Angenommen ein Artikel hat auch noch eine "Beschreibung", dann würde die doch bei jeder Preisänderung redundant gespeichert.

Die Problematik habe ich wohl nicht ganz rübergebracht. Der letzte Satz in "Tupel- versus Attribut-Zeitstempelung" sollte diese andeuten: Typischerweise wird man Attribute mit hoher Änderungshäufigkeit eher für sich alleine, hingegen Attribute mit geringer Änderungshäufigkeit gemeinsam versionieren. Ob das auf pedantischer Ebene wirklich gegen die 2NF verstößt, sei mal dahingestellt, da der PK ja um GültigAb ergänzt wird. Aus logischer Sicht gebe ich dir Recht, verstößt es dagegen. Jedenfalls erzeugt es Redundanz. Aber ich kann Dir versichern: Man macht das so. Häufig hat man zu einer Entität zwei Tabellen, eine statische und eine historisierte. Nur selten lagert man ein einzelnes Attribut nochmals aus und versioniert dies für sich allein. Der Preis hierfür ist hoch. Ich denke, Du unterschätzt das.--Cactus26 08:38, 19. Mär. 2007 (CET)

Hmm, hier kann ich gerade garnicht folgen. Da der Zeitraum ein Teil des Schlüssels ist, liegt meiner Ansicht nach durchaus 2NF vor. Oder hab ich da was falsch verstanden? Abgesehen davon, wird in der Praxis durchaus bewusst auf Normalisierung verzichtet, wenn dadurch die Performance gesteigert werden kann - siehe Sternschema. -- sparti 09:27, 19. Mär. 2007 (CET)

Kann sein, dass ich schon wieder die Normalformen verwechsle. Aber wenn ich eine Tabelle Artikel:{ArtNr, Beschreibung, Preis, gültigAb} mit PK (ArtNr, gültigAb) habe, dann ist die Beschreibung doch nicht voll funktional abhängig vom PK, sondern bereits von ArtNr alleine. D.h. wenn ich die Beschreibung ändern will, dann muss ich das für alle (durch die verschiedenen gültigAb-Werte) Einträge machen. Das will man sicherlich nicht. Die Praxislösung wäre IMO eine Tabelle Preishistorie:{ArtNr (FK), Preis, gültigAb} (evtl. mit Surrogatschlüssel) und in der Artikel-Tabelle ein Attribut "aktuellerPreis" (redundant aber performant).

Du verwechselst die Normalformen nicht. In deinem Beispiel verstößt die Sache nur dann gegen die 2NF, wenn die Beschreibung nicht zeithängig gespeichert wird. Sonst nicht. Ggf. können wir das auf der Diskussionsseite des Artikels ("Tupel-Zeitstempelung und 2NF") noch detaillierter diskutieren, wenn ihr wollt.

Mit Deiner Praxislösung schießt Du Dich auf eine mögliche Abbildung temporaler Daten ein, die es tatsächlich so gibt und die auch ihre Berechtigung hat. Aber auch ihre Nachteile. Sei ein wenig offener für die anderen Varianten. Glaube mir, auch die haben in der Praxis auch ihre Berechtigung. Es kommt eben auf den Anwendungsfall an. Wie gesagt: Es gibt kein Patentrezept.

Interessant ist auch der Surrogatschlüssel, den Du der Tabelle Preishistorie verpassen willst. Das habe ich im Artikel bei "Bestimmen des PK" bisher unterschlagen, das wird hin und wieder gemacht. Ich bin kein so großer Freund davon, aber z.B. Wikimedia tut es ja auch (siehe [1]), dort scheint mir der PK aber rein aus Performance-Aspekten designed zu sein.--Cactus26 08:56, 20. Mär. 2007 (CET)

• "Das Datenvolumen steigt beträchtlich" -> nicht bei Normalisierung, also Auslagerung in eine eigene ArtikelPreis-Relation.

Doch, teilweise sogar mehr, da Du ja dann extra Zeitstempel in der Zusatztabelle brauchst.--Cactus26 08:38, 19. Mär. 2007 (CET)

aber dafür in der Haupttabelle doch nicht mehr? Die Redundanz ist durch die Zusatztabelle doch beseitigt, habe ich da nicht grundsätzlich weniger Datenvolumen?

Du musst das so sehen: Jede synchrone Änderung der Attribute ist für die Tupel-Zeitstempelung eine Ersparnis gegenüber der Attr.-Zeitstemeplung, jede asynchrone ein Verlust. Nun gibt es grundsätzlich schon mal zwei Fälle, bei der alle Attr. sich synchron ändern müssen, das ist beim Anlegen oder Abschaffen des Artikels. Den Vorsprung muss die Attr.-Zeitstemeplung erst mal aufholen. Wir sollten die Diskussion hier aber nicht übertreiben, ich glaube der Speicherbedarf ist bei hier nicht der entscheidende Punkt.--Cactus26 08:56, 20. Mär. 2007 (CET)

• Die Sache mit den komplizierten Primärschlüsseln löst sich damit auch.

Nein. Die wäre dann auf die Relation ArtikelPreis anzuwenden.--Cactus26

stimmt. Aber zumindest kann ich mit der Haupttabelle sauber hantieren. Würde ich für leicht besser halten.

stimmt bedingt, oft wird man zumindest die separaten Tabelle Artikel und ArtikelHistorie machen, wobei erstgenannte nur zeitinvariante (bzw. nicht zeitabh. gespeicherte) Attribute enthält. Aber in meinem Beispiel soll ja die Existenz des Artikels auch historisiert werden.--Cactus26 12:01, 20. Mär. 2007 (CET)

• referentielle Integrität ist damit auch simpel.

Na ja. Ich habe bei dem Beispiel wohl bisher sträflich unterschlagen, dass die Zeitstemeplung der Tabelle Artikel neben der Versionierung der Attrubute auch die Existenz des Artikels definiert. Wenn Du alles für sich allein versionieren würdest, bräuchtest Du somit im Grunde drei Zeitstempelungen. Für die Existenz des Artikels, für den Preis und für den Solllagerbestand. Aber auch dann wäre das RI-Problem nicht vom Tisch, denn es wäre auf die Artikel-Existenz-Zeitstempelung anzuwenden.--Cactus26 08:38, 19. Mär. 2007 (CET)

Die PreisHistorie hat einen FK, der auf Artikel (mit einfachem Schlüssel ArtNr) verweist, ebenso Sollbestand. Ich brauche also für jedes temporale Attribut eine Zusatztabelle mit eigener Zeitstempelung. Dass diese Zusatztabellen einen zusammengesetzten Schlüssel haben, stört nicht so sehr, da hierher kaum was verweist.

Stimmt schon. Aber wenn die Artikelexistenz auch zu historisieren ist, hilft eine "nackte" Artikeltabelle nicht viel weiter, da eine historisch korrekte Konsistenz der RI die Gültigkeitszeiträume von Katalogeintrag und Artikel beinhalten sollte, d.h. ein Katalogeintrag darf nie einen zur entsprechenden Zeit nicht existierenden Artikel referenzieren.--Cactus26 12:01, 20. Mär. 2007 (CET)

• Abschnitt "Vereinfachende Abbildungen", letzter Absatz: hier kommt der Vorschlag doch noch. Würde ich als Standardmethode empfehlen und dementsprechend prominent oben platzieren. Der "Preis" dieser Methode ist auch nicht so hoch, denn nicht alle Tabellen werden temporale Attribute haben und entsprechend dupliziert werden müssen. Außerdem kosten Tabellen ja nicht viel, allenfalls die Joins. Man könnte Performance für Redundanz in Kauf nehmen und den aktuellen Preis in der Artikel-Tabelle speichern und die historischen nur in ArtikelPreis. Bei der Auslagerung stellt sich überhaupt die Frage, ob wir ein OLTP oder OLAP-System haben, d.h. die Redundanz evtl. in Kauf genommen werden kann.

Der hier gemachte Vorschlag ist nicht unbedingt dasselbe, wie die obige Fallunterschiedung zwischen Attribut- und Tupel-Zeitstempelung. Hier geht es ja darum, den aktuellen Preis sowohl beim Artikel direkt, als auch in einer separaten Tabelle zu speichern.

genau, ich bin ja für die separate Tabelle.

Diese Variante scheint Dein absoluter Favorit zu sein. Ich würde sie nicht unbedingt allen anderen bedingungslos vorziehen, wie gesagt: Es kommt auf die Situation an.--Cactus26 12:01, 20. Mär. 2007 (CET)

Deine Frage, für welchen "Typ" von DB (operativ, OLAP) ist berechtigt und spielt sicher bei allen Designentscheidungen eine Rolle. Primär habe ich mich an operativen DBs ausgerichtet und auch bei diesen halte ich die bei der Tupel-Zeitstempelung in Kauf genommene Redundanz in vielen Fällen für gerechtfertigt. Ich denke, Du unterschätzt den Preis einer spearaten Versionierung, Du darfst auch nicht vergessen, dass jeder Join kein normaler Join ist sondern immer eine "Nebenbedinung" mit dem Vergleich auf den entsprechenden Zeitraum enthält.--Cactus26 08:38, 19. Mär. 2007 (CET)

Man könnte eine View über die beiden Tabellen legen. Performance-technisch könnte man die noch materialisieren oder durch einen join-index tunen. Mir würde niemals eine Tabelle mit Redundanz in eine DB kommen. ;-) --Kurt Seebauer 00:20, 20.

Wow, ich dachte ich sei schon ein Redendanzfreiheits-Fetischist. Da habe ich wohl meinen Meister gefunden. Nun, mal im Ernst: Du solltest die Komplexität nicht unterschätzen, Views können diese nur bedingt kaschieren, oft (wenn sie nicht systematisch sind) machen sie alles nur noch schlimmer, da man dann die SQL-Fragmente auch noch zusammenklauben muss, wenn man eine Abfrage verstehen will. Häufig werden Views zur Ermittlung der aktuell gültigen Daten verwendet. Aber wehe, man will den Stand zu einem anderen Zeitpunkt wissen. Ich habe schon einmal eine DB mit Temporalität erlebt, bei der massiv Views eingesetzt wurden, aber praktisch jede Abfrage, die sich nicht auf den aktuellen Zeitpunkt bezog, mindestens einen logischen Fehler hatte. Die Sache war für die Entwickler einfach zu komplex.--Cactus26 12:01, 20. Mär. 2007 (CET)

Sonstiges

• Für welche Anwendungen (Beispiele) werden spatio-temporale DB eingesetzt?

Klassische Anwendungsfälle sind wohl die Verkehrstelematik und "Wetterdatenbanken". Würdest Du einen solchen Hinweis aufnehmen?--Cactus26 08:38, 19. Mär. 2007 (CET)

Ja, würde ich einen Halbsatz dazuschreiben, mir sind beim Lesen keine Anwendungsfälle eingefallen. Ok, erledigt.--Cactus26 08:01, 20. Mär. 2007 (CET)

• wie würde eine rein temporale DB aussehen? Braucht man nicht immer noch ein zugrundeliegendes Datenmodell wie das relationale. Temporalität ist doch IMO nur ein Aspekt der Datenhaltung und reicht alleine nicht aus.

So ist es. Dennoch ist der Begriff "temporale Datenbank" üblich, obwohl die Temporalität nur ein Aspekt der Datenbank sein kann. Eine "rein temporale Datenbank" in dem Sinne gibt es nicht. Eine (wenn auch schlechte) Analogie ist vielleicht "verteilte Datenbank".--Cactus26 08:38, 19. Mär. 2007 (CET)

Ok, dann sollte man vielleicht "Datenbanken mit temporalen Erweiterungen" schreiben.

Hast schon Recht, aber der Begriff ist nun mal nicht auf meinem Mist gewachsen und wird so verwendet.--Cactus26 08:01, 20. Mär. 2007 (CET)

Ich finde die Namensgebung schon ok. So ist der Name eben. Ausserdem ist es ja nicht verboten, dass Datenbankmodelle aufeinander aufbauen. -- sparti 09:23, 20. Mär. 2007 (CET)

• wieso verlinkt Datenbanksystem auf Kategorie:DBMS? Ich mag diese fehlende Unterscheidung zwischen DBMS und DBS (in der ganzen WP) nicht.

Muss gestehen, dass ich auch einer der Sünder bin und diese Begriffe immer synonym verwende. Mir war der Bedeutungsunterschied bisher nicht so ganz klar, habe ihn aber jetzt Datenbanksystem entnommen. Habe den Link im Artikel angepasst.--Cactus26 08:38, 19. Mär. 2007 (CET)

• Die Unterscheidung Zeitintervall/-dauer ist nicht gut gelungen, das muss man zweimal lesen, um es zu verstehen. Eine verankerte Zeitangabe bezieht sich auf einen konkreten Zeitpunkt, ... oder auf ein konkretes Zeitintervall

Habe den Hinweis auf das Intervall ergänzt. Ist es so besser?--Cactus26 08:38, 19. Mär. 2007 (CET)

yep, ist besser.

Mär. 2007 (CET) Ich hoffe, die Kommentare helfen ein bisschen. Der Artikel ist sicherlich nicht leicht zu schreiben, weil er ein "querschnittliches Thema" beinhaltet und viele Aspekte zu berücksichtigen sind. Viele Grüße, Kurt Seebauer 23:22, 18. Mär. 2007 (CET)

Deine Kommentare helfen sogar sehr viel. Vor allem wird mir bei der Zeitstempelung klar, dass ich noch einiges nicht rübergebracht habe. Bin gespannt auf Dein Feedback auf meine Anmerkungen. Bin mir aber jetzt schon sicher, dass ich noch einiges im Artikel anpassen muss. Vielen Dank und auch viele Grüße--Cactus26 08:38, 19. Mär. 2007 (CET)

Surrogatschlüssel

(hierherkopiert von meiner Benutzerdiskussionsseite):

Zu einer Sache hätte ich gerne noch Deine Meinung. Und zwar der Sache mit dem Surrogartschlüssel als PK. Du hattest im Review einen vorgeschlagen (als Ersatz für Artikelnummer/GültigAb). Was genau ist Deine Motivation für diesen PK (Performance,  ?). Wie gesagt, Du bist mit diesem Ansatz nicht allein. Würdest Du eine Erwähnung dieser Variante im Artikel für sinnvoll halten?--Cactus26 09:37, 30. Mär. 2007 (CEST)

da will ich mich nicht unbedingt festlegen. Ich finde einerseits zusammengesetzte Schlüssel grundsätzlich hässlich, andererseits macht das aber in so Nebentabellen nichts, weil kaum was dorthin verweist. Perfocmancetechnisch ist die Methode mit Surrogatschlüssel wohl schneller. Muss man wohl im Einzelfall abwägen. Es lohnt sich sicherlich, im Artikel zu erwähnen, dass beide Methoden möglich sind. --Kurt Seebauer 15:01, 1. Apr. 2007 (CEST)

Werde ich demnächst einbauen, danke.--Cactus26 18:18, 1. Apr. 2007 (CEST)

Temporale Datenhaltung und Datawarehouse

Hallo Cactus, eine Sache die mir noch aufgefallen ist, ist, daß bei einem Data Warehouse separate Zeittabellen verwendet werden. Einmal, da dies hilft, Zeiträume zu definieren, aber auch um Suchanfragen zu beschleunigen. Wird bei temporalen Datenbanken nicht ein ähnliches Konzept verwendet? Das könnte auch helfen die Datenintegrität zu vereinfachen, da für einen Zeitraum nur noch ein Schlüssel verwendet wird, statt der Timestamps? -- sparti 09:18, 19. Mär. 2007 (CET)

Ich weiß nicht genau, was mit "separate Zeittabellen" gemeint ist. Meinst Du damit eine Entität Zeit, bei der z.B. zum Surrogatschlüssel "1" der Zeitraum von 01.01.2001-31.03.2001 gespeichert wird, der dann von anderen Tabellen referenziert wird, um den Zeitraum zu definieren?--Cactus26 10:53, 19. Mär. 2007 (CET)

So ähnlich. Ich sehe darin allerdings verschiedene Aspekte. Also zunächst wäre es doch sinnvoll eine Zeit und Datums Tabelle einzuführen, so wie man es in einem Data Warehouse machen wuerde. Zusätzlich könnte man eine Zeitraumtabelle einfügen. Diese Tabelle würde dem entsprechen, was Du beschrieben hast, aber statt der tatsächlichen Zeitangaben lediglich auf die Zeittabellen verweisen. Keine Ahnung, ob das sinnvoll ist, mir ist nur die Analogie zum DW aufgefallen. -- sparti 11:13, 19. Mär. 2007 (CET)

Bin nicht gerade Spezialist in Bezug auf Datawarehouse und habe ein wenig recherchiert ([2]) und ich glaube, ich weiß jetzt was gemeint ist. M.E. macht eine solche Zeittabelle nur dann Sinn, wenn man eine zyklische Änderung abbildet. Im Abschnitt "Vereinfachende Abbildungen" habe dazu bisher folgendes: Bei der Gültigkeitszeitstempelung ist es für den Fall zyklischer Datenänderungen sinnvoll, statt der üblicherweise verwendeten Intervalle zur Zeitstempelung direkt die Identifikation der Gültigkeitsperiode zu verwenden. Die Identifikation der Gültigkeitsperiode kann dann auch ein Verweis (Fremdschlüssel) auf eine Zeittabelle sein. Das könnte man dort noch erwähnen. In operativen Datenbanken sind derartige Zeittabellen aber wohl eher selten, da alle dort enthaltenen Attribute ja ermittelbar sind und so ja eigentlich redundant sind. Zudem müsste man sich immer um das passende Einfügen zusätzlicher Zeilen in die Zeittabelle kümmern. Begegnet ist mir dieser Ansatz auch schon mal bei der Modellierung, bei der man manchmal eine Entität Zeit als Hilfskonstruktion einführt, diese aber nicht wirklich als Tabelle implementiert. Bei der Verwendung von Intervallen zur Zeitstempelung halte ich auch eine Verwendung einer solchen Zeittabelle nicht für sinnvoll bzw. hilfreich.--Cactus26 12:00, 19. Mär. 2007 (CET)

Beim DW einigt man sich auch in der Regel auf global gültige Zeitgranularitäten, z.B. Tage, da macht eine solche Tabelle evtl. Sinn. Bei operativen DB eher nicht. --Kurt Seebauer 00:20, 20. Mär. 2007 (CET)

Ja, das stimmt. Diese Unterscheidung koennte bei den Anwendungen nochmal erwaehenen. -- sparti 09:23, 20. Mär. 2007 (CET)

Ok, werde es probieren.--Cactus26 12:01, 20. Mär. 2007 (CET)

Habe einen Absatz bei Data-Warehouse ergänzt. Wäre nett, wenn ihr drüberschauen könntet, ist ja wie gesagt nicht mein Spezialgebiet.--Cactus26 14:19, 20. Mär. 2007 (CET)

Vielen Dank für die Verbesserungen, sparti! --Cactus26 10:28, 21. Mär. 2007 (CET)

Ich habe eine Referenz auf diesen Artikel in Slowly Changing Dimensions#Typ 2 eingetragen, denn genau das ist einer der Punkte, an dem Historisierung im DWH zur Anwendung kommt. --Julius-m 22:46, 26. Dez. 2008 (CET)

Danke. Werde mir diese Thematik bei Gelegenheit mal genauer ansehen.--Cactus26 12:52, 27. Dez. 2008 (CET)

Bitberts Artikelbesprechung

Hallo, Cactus26 hat mich um eine Besprechung des Artikels gebeten. Ich bin Diplom Informatiker und beschäftige mich zur Zeit hauptsächlich mit Sensornetzen, kenne mich jedoch auch mit relationaler Datenbankhaltung, Data Warehousing, OLAP und ähnlichen Themen theoretisch und praktisch aus.

Die Definition der temporalen Datenhaltung erscheint mir richtig, aber leicht unsauber formuliert. Erwähnt werden sollte, was gespeichert wird, nämlich Daten. Der Begriff temporal sollte kurz erläutert und verlinkt werden, um Verwechslungen mit temporär auszuschließen. Zeitabhängig ist unglücklich gewählt, da nichtssagend; besser etwas wie unter Einbeziehung zusätzlicher zeitlicher Informationen. Der Verweis auf Informationstechnologie sollte umgebogen werden, der Artikel heißt Informationstechnik. Sind Historisierung und temporale Datenhaltung wirklich völlig gleichwertig?

Die Gliederung finde ich unglücklich. Anwendungsgebiete sollten ganz vorne geschildert werden, so dass der unbedarfte Leser sofort eine Vorstellung von Sinnhaftigkeit und Verbreitung bekommt. Einen vorgelagerten Abschnitt mit Begriffserklärungen finde ich in einem Lexikonartikel witzlos; die Begriffe sollten nach und nach zusammen mit den Konzepten eingeführt werden. In der Tat ist der Abschnitt auch weit mehr als eine Begriffserklärung und erklärt zum Beispiel die temporale Datenhaltung ausführlich. Die einseitige Versteifung auf das relationale Modell finde ich unangemessen. Klar, da ist der Verweis auf den Artikel Temporale Datenbanken, aber ich würde mir schon ein, zwei Sätze wünschen, wie die temporale Datenhaltung systemseitig gelöst wird.

Beispiele finde ich in Lexikonartikeln eher fehl am Platz; aber das ist nur meine persönliche Meinung. Die relationalen Beispieldatenbanken jedenfalls sind falsch eingeordnet. Sie werden im Abschnitt zur temporalen Normalisierung vorgestellt; dort werden laut Überabschnitt aber nur allgemeingültige Konzepte erläutert, während relationale Spezialisierungen später folgen. Ungünstig ist auch, dass man beim Nachvollziehen der SQL-Abfragen weiter unten immer wieder nach oben zurückblättern muss.

Die Bilder haben durchweg das falsche Format und wirken dadurch unsauber. Das verwendete Kompressionsverfahren JPEG ist für schematische Zeichnungen gänzlich ungeeignet, weil es Kanten verwischt. Angemessen wäre das Vektorformat SVG. Falls sich bei euch niemand damit auskennt, kann sicher die Wikipedia:Grafikwerkstatt helfen.

Sprachlich ist einiges zu tun. Bezüglich und hinsichtlich stellen stilistisch in der Regel einen saftigen Griff ins Klo dar; weg damit! Auf Bemessungen wie häufig und oft würde ich soweit als möglich verzichten; selbst solche unscharfen Mengenangaben wollen im Prinzip immer mit Quellen belegt sein. Nur auf inhaltlich relevante Artikel verweisen, niemals auf Floskeln wie Patenrezept.

Schließlich hier noch einige Detailfragen, in Klammern die Artikelabschnitte:

• Ich bin mir nicht sicher, wie festgetreten diese Begriffe sind, aber sprachlich eindeutig müsste es Gültigkeitszeitraum und Transaktionszeitpunkt heißen. (Gültigkeitszeit und Transaktionszeit)
• … in der modellierten realen Welt … (Gültigkeitszeit und Transaktionszeit) Schlecht formuliert, klingt als sei die Welt gleichzeitig modelliert und real.
  Ok, angepasst--Cactus26 08:16, 5. Apr. 2007 (CEST)
• Bei einer Zeitdauer handelt es sich somit um ein unverankertes Zeitintervall. (Zeitpunkte, Zeitintervalle und Zeitdauern) Der Begriff Zeitdauer ist damit nicht hinreichend erklärt. Es fehlt der Hinweis, dass Zeitdauer und Intervall gleichbedeutend sind.
• … die Ergänzung eines Zeitbezugs zu einem Datenattribut oder einer Datenzeile … (Zeitstempelung) Zeilen sind meines Wissens Microsoft-spezifisch. Allgemeingültiger ist Datensatz.
• … bzw. durch die bei verwendete Architektur, z.B. einem Datenbanktrigger … (Zeitstemeplung) Der Satz ist unvollständig.
  Ok, habe bei entfernt.--Cactus26 19:26, 4. Apr. 2007 (CEST)
• Mit der Tupel-Zeitstempelung handelt man sich aber zwangsläufig das Problem ein, dass man bei Auswertung nur eines der gemeinsam versionierten Attribute aufeinander folgende Zeiträume erhält, bei denen sich die Attributwerte nicht unterschieden. (Temporale Normalisierung (Coalescing)) Grammatisch falsch, enthüllt seine Aussage nicht.
  Ok, Satz umformuliert.--Cactus26 19:26, 4. Apr. 2007 (CEST)
• Surrogatschlüssel sollte kurz erklärt werden, selbst praktische Datenbankprogrammierer sind nicht immer mit den Fachbegriffen vertraut. (Bestimmen des Primärschlüssels)
• Der Primärschlüssel einer temporalen Relation beinhaltet zunächst einmal auch die eindeutige Identifikation der Zeile ohne Berücksichtigung der für die temporale Speicherung erforderlichen Zeitstempelung (also die Primärschlüsselspalten, die die Relation ohne temporale Abbildung hätte). (Bestimmen des Primärschlüssels) Ich weiß, was dieser Satz ausdrücken sollte. Aber verstehen tue ich ihn trotzdem nicht.
• Ich habe zweimal das nicht existierende Wort umfänglich gefunden. Wahrscheinlich war umfangreich oder umfassend gemeint.
  Ok, angepasst.--Cactus26 19:26, 4. Apr. 2007 (CEST)

Fazit: Ich konnte keine inhaltlichen Fehler finden, alle Anmerkungen sind sprachlicher Natur. Das ist eine sehr gute Ausgangsbasis. Wichtig ist vor allem, den Artikelaufbau anzupassen: Es fehlt der rote Faden, der den fachfremden Leser durch den Text führt. --Bitbert ^-?- 12:06, 2. Apr. 2007 (CEST)

Hallo Bitbert,

Ich stimme Deiner Kritik im Wesentlich zu. Insbesondere die Stelle mit dem Primärschlüssel wird mir auch nicht klar. Ich bin noch nichtmal sicher, ob das ganze inhaltlich korrekt ist. Aber das klärt sich vielleicht, wenn es verständlicher wird.

Auch denke ich, daß die Gliederung etwas überarbeitet werden kann. Z.B. kann Abschnitt 1 und 3 zusammengelegt werden.

Anderer Meinung bin ich was Beispiele und Anwendungsfälle anbelangt. Beispiele dienen immer dem Verständnis - Enzyklopädie hin oder her. Anwendungsfälle sind in meinen Augen eher Anhänge und dienen dem Laien nicht notwendigerweise zum Verständnis.

Mein Vorschlag wäre daher einen eigenen Abschnitt mit einer anschaulichen Erläuterung einzufügen.

Dann hätte ich noch eine Frage zu den Worten bezüglich und hinsichtlich. Was ist daran schlechter Stil und wo kann man das nachlesen?

Gruss -- sparti 12:50, 2. Apr. 2007 (CEST)

Beispiele, die über einen kurzen Nebensatz oder ein Bild hinausgehen, haben für mich in einem Lexikon prinzipiell nichts zu suchen. Schildert etwa der Artikel Braunbär die Lebensweise der Braunbären anhand eines „fiktiven Beispielbären Bruno“? Oder seziert der Artikel Literatur demonstrativ ein Werk von Goethe? Ganze Beispielszenarien gehören für mich in Lehrbücher, nicht in Lexikonartikel.

Anwendungsgebiete sind alles andere als Anhänge und gehören nach vorne, wenn nicht gar bereits in die Einleitung. Hier erfährt der Leser, wie verbreitet und relevant das Thema tatsächlich ist. Diese Dinge interessieren ihn, bevor er in die technischen Untiefen abtaucht. „Typische Anwendungsgebiete“ würde ich allerdings nicht beibehalten, das sind wieder Beispiele statt genereller Erklärungen.

Der schlechte Stil von bezüglich und hinsichtlich ergibt sich indirekt aus Wikipedia:Wie schreibe ich gute Artikel, denn sie erzwingen eine unnötige Verkomplizierung der Satzstruktur. Entscheide selbst:

• Im folgenden werden zunächst verschiedene konzeptionelle Aspekte bezüglich einer vollwertigen Abbildung temporalen Daten dargelegt. / Im Folgenden werden zunächst verschiedene konzeptionelle Aspekte bei einer vollwertigen Abbildung temporaler Daten dargelegt.
• Hinsichtlich der Befüllung des Zeitstempels wird explizite und implizite Zeitstempelung unterschieden. / Bei der Befüllung von Zeitstempeln unterscheidet man explizite und implizite Zeitstempelung. --Bitbert ^-?- 15:04, 2. Apr. 2007 (CEST)

Also bei den Beispielen bin ich noch immer gänzlich anderer Ansicht. Zum einen lassen sich Artikel über Goethe und Bären nicht auf Artikel mit abstrakten Inhalten übertragen. Zum anderen finde ich das Sezieren eines Goethe Textes sehr lesenswert. Warum sollen wir das auch nicht tun? Nur weil der Brockhaus das nicht getan hat?

Auch wegen der Anwendungsfälle bin nicht überzeugt. Ich glaube nicht, daß sie dem Verständnis dienen, wenn jemand das Lemma selbst noch nicht verstanden hat. Ein Leser, der gerade versucht zu erfahren, was Temporale Daten sind und auch nicht weiß was ein Data Warehouse ist, wird durch ein solches Beispiel erstrecht irritiert.

Was spricht gegen einen Absatz der sehr anschaulich das Problem erläutert?

Ok, bei der Stilfrage gebe ich dir aber recht :) Die Alternativen lassen sich tatsächlich leichter lesen. Aber ich kann mir auch Fälle vorstellen, bei denen sie hilfreich sind. Zum Beispiel, wenn ich mich auf anderen Absatz weiter vorne im Artikel beziehe, ist ein bezüglich durchaus hilfreich, oder kann man das auch anders lösen? -- sparti 18:32, 2. Apr. 2007 (CEST)

Dass Beispiele und weitschweifende Veranschaulichungen nichts in Wikipedia-Artikeln verloren haben, ist nicht bloß eine Privatmeinung, sondern ein wesentlicher Grundsatz des Wikipedia-Projektes (WP:WWNI #9). --Contributor 21:29, 2. Apr. 2007 (CEST)

Niemand möchte hier weitschweifende Veranschaulichungen. Es geht darum ein komplexes Thema anschaulich darzustellen. Das ist was anderes. Denn sonst kommt nämlich der nächste Schlauberger mit Wikipedia:Oma-Test. Ausserdem bin ich fuer Wikipedia:Ignoriere_alle_Regeln. Und im uebrigen finde ich, Dein Beirag verstoesst gegen Wikipedia:Geh_von_guten_Absichten_aus. Ja, ja, gut dass wir diese schlauen Seiten haben. -- sparti 22:02, 2. Apr. 2007 (CEST)

Ja es ist gut, dass diese Seiten existieren. Man sollte sie nicht nur kennen sondern auch gelesen haben. 1. Auf WP:IAR steht explizit, dass der Enziklopädiebegriff einer der vier Grundsätze ist, die eben nicht ignoriert werden dürfen. 2. WP:OMA bedeutet lediglich, dass sprachlich allgemeinverständliche Formulierungen und passende weiterführende Verweise zu verwenden sind, nicht aber, dass Beispiele das Mittel der Wahl sind. Und gerade weil ich von guten Absichten ausgehe, habe ich nicht brachial am Artikel herumgefuhrwerkt sondern hier sachlich auf den geltenden Grundkonsens verwiesen, damit dieser entsprechende Berücksichtigung erfährt. --Contributor 22:43, 2. Apr. 2007 (CEST)

Ok, welche Beispiele stoeren Dich denn ganz konkret. Und wie glaubst Du koennte man den Artikel trotzem verstaendlich halten, wenn man sie entfernt? Ich habe ehrliche Zweifel, dass es moeglich ist, aber lasse mich gerne vom Gegenteil überzeugen. -- sparti 23:27, 2. Apr. 2007 (CEST)

Hi Bitbert, Du hast der Artikeldiskussion hier ja wieder richtig Leben eingehaucht. Danke für Dein Review. habe im Moment leider wenig Zeit, am Donnerstag hoffentlich wieder mehr. Ein paar Anmerkungen mal vorab:

• Gliederung, Anwendungsgebiete
  Anwendungsgebiete vorn halte ich (entsprechend sparti) für falsch, da die Erläuterung der Anwendungsgebiete auf dem vorigen aufbauen und ohne dies nicht verständlich sind. Bestenfalls wäre die beispielhafte (?!) Nennung eines Anwendungsbeispiels in der Einleitung möglich.
• Gliederung, Begriffserklärungen
  Dass Du diesen Aufbau für schlecht hälst, trifft mich hart. Ich habe diesen sehr bewusst gewählt und stehe auch heute noch dazu. Aber die Bezeichnung "Begriffserklärungen" ist sicherlich irreführend, besser wäre vielleicht "Allgemeine Aspekte einer temporalen Datenhaltung" (andere Vorschläge?). Die Idee dieses Abschnitts ist auch, die allgemeinen Dinge zu erläutern, die sowohl in "echten" temporalen Datenbanken als auch bei der Abbildung in RDBMS relevant sind. Zudem schafft der Abschnitt die Grundlage, damit der folgende Abschnitt überhaupt verständlich wird.
• Einseitige Versteifung auf das rel. Modell
  Die Quellenlage ist hier eindeutig, es gibt derzeit noch keine kommerziell verfügbaren "echten" temporalen Datenbanken, deshalb kann man auch wenig drüber sagen. Praktisch alle verfügbaren Quellen beschränken sich aufs relationale Modell. Gleiches gilt auch für meine persönlichen Erfahrungen.
• Beispiele in Lexikonartikeln
  Wie auch immer die Richtlinien hier sein mögen, hier liegen die Gegner falsch. Der Grundsatz mag für ein Konversationslexikon richtig sein, nicht aber für ein Informatik-Lexikon und wird dort auch in den gedruckten Exemplaren keineswegs so gehandhabt. Und die Wikipedia ist eben mehr. Beispielsweise gibt es im Artikel Alpha-Beta-Suche, immerhin lesenswert, selbstverständlich Beispiele. Ich denke, in der IT (und auch anderen Bereichen) gibt es einfach Sachverhalte, die keine bloße Nennung von Fakten sein können und deren Komplexität für Normalsterbliche ohne Beispiele nicht mehr verständlich ist. Und dies trifft, was meine Erfahrung anbelangt, auch für die temporale Datenhaltung zu. Also: Wenn man Beispiele verdammen möchte, muss man auf Artikel verzichten, die Zusammenhänge darstellen wollen und ein gewisses Komplexitätsniveau übersteigen.
• Bezüglich und Hinsichtlich
  Ich denke, dass Deine Formulierung ein wenig zu drastisch ist. Was mich ein wenig beruhigt, ist, dass ich beim ins Klo greifen ja nicht ganz alleine bin, habe mir diesen Stil ja irgendwo abgeschaut. Auch denke ich bezüglich der Einfachheit, dass diese erst an Stellen, die hinsichtlich Komplexität (pitsch, patsch, spritz,...) ein gewisses Niveau übersteigen und dann zu kompliziert werden, wirklich von Bedeutung ist.
  Aber das alles ändert nichts daran, dass Du in der Sache recht hast. Werde den Artikel demnächst durchforsten.

--Cactus26 07:45, 3. Apr. 2007 (CEST)

Oje, da habe ich Esel ja wieder was losgetreten. :-X Vorweg mal dies: Ich finde den Artikel nicht schlecht. Ziel einer Besprechung ist es, Schwachstellen aufzudecken. Dementsprechend ist meine Besprechung einseitig und klingt negativer als sie gemeint ist. Der Artikel weist jedoch keine inhaltlichen Fehler auf, was ihn an sich schon einmal als gut qualifiziert.

Reden wir bei den Anwendungsgebieten aneinander vorbei? Ich meine einen Abschnitt in dieser Art: Temporale Datenhaltung spielt eine wichtige Rolle in vielen Anwendungsbereichen, insbesondere bei der Verwaltung zeitlich geordneter finanzieller Daten wie sie etwa in Kreditinstituten, Warenhäusern und Personalabteilungen anfallen. Also eine Einordnung ohne technische Details.

Die Gliederung hier ist grob gesprochen: Definition, Ausarbeitung, Anwendung. Das ist die typische Gliederung einer wissenschaftlichen Arbeit. Diese Gliederung ist nicht an sich schlecht, aber in einem Lexikon unangebracht. Lexikonleser möchten sofort ins Thema eingeführt werden, statt sich erst mit Definitionen befassen zu müssen. Nennt den Abschnitt „Grundbegriffe“ und macht einen Fließtext daraus, der den Leser an der Hand nimmt statt ihm die Begriffe nacheinander in Form eines Glossars vorzuführen.

Die richtigen temporalen Datenbanken haben mich weniger umgetrieben, die haben einen eigenen Artikel. Was mich interessiert, ist die Umsetzung in objektorientierten Datenbanken. Wenn es dazu aber überhaupt keine Informationen gibt, ist der Aufbau nachvollziehbar. Druckst dann aber im Abschnitt „Abbildung temporaler Daten in Datenbanksystemen“ nicht so herum, sondern schreibt klipp und klar, dass dazu keine Informationen vorliegen.

Ihr steht nicht alleine da mit eurer Meinung über Beispiele. Der Artikel Topologische Sortierung ist sogar exzellent, obwohl er ein einzelnes Beispiel in epischer Breite durchexerziert. Sicher, er erklärt den Sachverhalt vorbildlich, aber in dieser Form gehört er für mich in ein Lehrbuch, nicht in ein Lexikon. Besonders störend ist, dass die Beispiele dort nicht kostenloser Bonus sind, sondern fest mit dem Artikeltext verschmolzen wurden. Einen abstrakten Sachverhalt ohne Beispiele verständlich darzustellen ist eine Kunst, die kaum jemand beherrscht und die ich darum um so mehr schätze. Aber wir schweifen ab, ich wollte euch ja hier nicht den Mund verbieten, sondern anregen, die Beispiele so knapp wie möglich und weiter unten zu konzentrieren.

Bezüglich und hinsichtlich sind klassische Fälle von Beamtendeutsch: Beide Wörter zwingen Satzteile aus dem pöbelhaften Akkusativ oder bäurischen Dativ in den höchstbeamtlichen Genitiv. Du greifst nicht nur zusammen mit zig tausenden Beamten ins Klo, sondern auch mit Millionen von Leuten, die sich diese vermurkste Sprechweise aus offiziellen Schreiben abgeguckt haben. ;-) Beide Ausdrucksweisen entstehen übrigens auch gerne bei Laienübersetzungen aus dem Englischen (in terms of). Verweise auf vorher gesagtes setzt man am besten mit „s. o. …“ oder „vgl. …“. --Bitbert ^-?- 11:20, 3. Apr. 2007 (CEST)

Hi Bitbert, nun endlich das vollständige Feedback. Du musst hier auch kein schlechtes Gewissen haben, natürlich tut berechtigte Kritik immer etwas weh und ein bisschen beleidigt spielen tut hin und wieder auch mal gut. Auch dass die Diskussion hier wieder belebt wurde, ist zwar anstrengend, aber konstruktiv (Danke an sparti und contributor), auch wenn wir keinen Konsens erzielen (sollten) bringt es weiter. bei den einfachen Punkten habe ich meinen Kommentar direkt oben eingetragen. Nun die restlichen aus meiner Sicht noch offenen Punkte:

• Beispiele im Artikel, Gliederung Definition/Ausarbeitung/Anwendung
  Stimmt schon, diese Gliederung ist eher für einen Fachartikel bzw. eine wissenschaftl. Arbeit passend als für einen klassischen Lexikonartikel. Und in der WP existieren mittlerweile viele Artikel, die den Rahmen eines klassischen Lexikonartikels klar sprengen und eher zum Fachartikel tendieren, hierzu würde ich auch Temporale Datenhaltung und Topologische Sortierung zählen. Aber: Ist das schlimm? Mein Standpunkt ist, wenn die Artikel in ihrer Einleitung einen kurzen Überblick über das Thema bieten und damit auch die Rolle des Lexikoneintrags erfüllen, ist das eher ein Gewinn.
  Meine Hauptintention bei diesem Artikel war einem Datenbankentwickler, der sich mit rel. DB auskennt und erstmals mit dem Problem temporaler Daten konfrontiert wird, einen Überblick zu geben, was es da alles gibt und was man dabei alles beachten muss, da ich einige Entwickler kenne, die so etwas gerne gehabt hätten. Daneben wollte ich den Artikel, zumindest den Anfang, so gestalten, dass auch ein Laie etwas damit anfangen kann und weiß, um was es dabei geht (deshalb auch das Beispiel in der Einleitung). Schade, wenn mir das nicht gelungen ist.
• Einleitung, Definition
  • temporal verlinken hier (derzeit) relativ nutzlos, da rekursiver Link via BKL. Die BKL enthält derzeit zudem keine allgemeine Beschreibung der Bedeutung des Worts. Vielleicht auch explizite Erwähnung im Artikel, dass temporal nicht mit temporär zu verwechseln ist?
  • Informationstechnik vs. Informationstechnologie: Hier bin ich verblüfft, dass die WP Informationstechnik bevorzugt. Trage ich nicht unbedingt mit, habe den leisen Verdacht, dass das in der WP eher in Produkt der Versionshistorie ist, da die Artikel eine zeitlang parallel existierten und es diese Spezialbedeutung in Österreich gibt. Würde ich gern so belassen, in der Hoffnung, dass irgendwann wer das (aus meiner subjektiven Sicht) richtigstellt.
  • Begriff "Historisierung" vs. "temporale Datenhaltung"
    Umgangssprachlich (unter IT-lern) wird fast ausschließlich "Historisierung" verwendet, in der Fachliteratur fast ausschließlich "Temporale Datenhaltung/Datenbanken". Ein Grund hierfür ist wohl, dass Historisierung sich nur schwer die (seltener benötigten) zukünftigen Daten einbeziehen kann. Deshalb meiden Fachartikel letzteren Begriff, da sie meist einen allgemeineren Anspruch haben. Es gibt kein Indiz, dass eine wirklicher Bedeutungsunterschied existiert.
  • "zeitabhängig unglücklich gewählt", Erwähnung "Daten"
    Ok. Neuer Versuch: ....versteht man in der Informationstechnologie das Festhalten der zeitlichen Entwicklung der Daten bei Speicherung in einer Datenbank. (siehe Artikel). Weitere Anregungen?
• Umsetzung temporaler Datenbanken in objektorientierten DBs
  Der Artikel "drückt" sich ja mit der Aussage, dass mangels Einheitlichkeit hier keine generelle Aussage möglich ist. Das stimmt so und lässt sich auch belegen (siehe Riedel 1998). Meine persönlichen Kenntnisse in diesem Bereich sind wohl zu gering und auch zu alt (1996) um dort detailliertere Aussagen manchen zu können. Ich vermute jedoch stark, dass sich vieles, was in diesem Artikel dargelegt wird, auf OODBMS übertragen lässt. Möglicherweise kann sich ja auch jemand anderes an diesem Thema versuchen.
• Falsches Bildformat (jpeg -> svg): Werde mich drum kümmern
• Begriffe "Gültigkeitszeit und Transaktionszeit" statt sprachlich korrekterem "Gültigkeitszeitraum" und "Transaktionszeitpunkt"
  Sind in der Fachliteratur sehr etabliert, vermutlich aus der englischen übernommen (transaction-time und valid-time). Manchmal wird sogar vom "Transaktionszeitraum" gesprochen. Die vermeintlich sprachlich korrekten Varianten wären auch problematisch, da die Begriffe hier mehr zur Bezeichnung einer separaten Zeitachse oder Zeitdimension verwendet werden, also müssten sie korrekt vielleicht eher ein an letzteres angelehnten Suffix bekommen.
• Zeitdauer und Intervall gleichbedeutend
  Gleichbedeutend sind sie nicht, eine Zeitdauer ist immer unverankert, ein Intervall kann verankert oder unverankert sein. Habe aus dem Satz Bei einer Zeitdauer handelt es sich somit um ein unverankertes Zeitintervall das somit entfernt, da es unlogisch ist. Macht es das besser oder hast Du Vorschläge?
• "Zeilen" microsoftspezifisch für "Datensatz"
  Stimmt sicher nicht, man sprach bereist von Zeilen bei rel. DB, als es bei Microsoft noch gar keine DB gab. Die Formulierung ist vielleicht etwas unsauber, aber anschaulich. Zudem assoziiere ich Datensatz eher mit Dateiverarbeitung, nicht mit Datenbanken. Würde ich gerne so belassen.
• Bestimmen des Primärschlüssels, "Surrogatschlüssel" sollte erklärt werden
  Habe den Abschnitt überarbeitet, der Einleitungssatz war wirklich nicht sonderlich gelungen. Allerdings ist mir nicht klar geworden, ob die Probleme hier an der unklaren Formulierung oder am Sachverhalt an sich liegen.
  Zur vollständigen Verwirrung habe ich nun den Hinweis auf Surrogatschlüssel in der ursprünglichen Bedeutung entfernt (obwohl es natürlich weiterhin stimmt, dass im Falle temporaler Datenhaltung ein PK unveränderlich sein muss, nur ist dies vielleicht auch ohne Temporalität schon erstrebenswert genug).
  Der Surrogatschlüssel taucht dafür an anderer Stelle wieder auf. Teilweise wird aus Performancegründen statt des aus mehreren Spalten bestehenden PK eine automatisch inkrementierter Kunstschlüssel verwendet. Der Hinweis war eine Anregung von Kurt, zudem findet sich so was auch bei Wikimedia (siehe [3]).

--Cactus26 08:16, 5. Apr. 2007 (CEST)

Weitere Reviewanmerkungen

Ich finde den Link zu http://de.wikipedia.org/w/index.php?title=Temporale_Datenhaltung&action=history zwar eine anschauliche Idee, aber ich glaube der normale Leser klickt da nicht drauf weil er es nicht so erkennt. Sollte irgendwie noch als Beispiel gekennzeichnet werden.--Tookentry 01:15, 18. Apr. 2007 (CEST)

Wie könnte man das offensichtlicher machen?--Cactus26 07:17, 18. Apr. 2007 (CEST)

Habe versucht, es offensichtliche zu machen. Besser so?--Cactus26 07:26, 18. Apr. 2007 (CEST)

Archivierung der erfolgreichen Lesenswert-Kandidatur vom 4. bis zum 11. Mai 2007

Unter temporaler Datenhaltung versteht man in der Informationstechnologie das Festhalten der zeitlichen Entwicklung der Daten bei Speicherung in einer Datenbank.

Die primäre Intention dieses Artikels ist, Datenbankentwicklern oder -modellierern, die sich mit Datenbanken auskennen, einen Überblick über die Aspekte und Varianten einer temporalen Datenhaltung zu geben. Ziel ist aber auch, dass Laien zumindest verstehen, um was es dabei geht, also sollte zumindest die Einleitung für Laien auch verständlich sein. Der Artikel wurde einem sehr ausgedehnten Review unterzogen, mit einer kontroversen, aber auch konstruktiven Diskussion. Das Feedback eines wirklich blutigen Laien steht aber noch aus. --Cactus26 17:14, 4. Mai 2007 (CEST)

• pro: Der Artikel ist interessant und bietet einen umfassenden Ueberblick auf das Thema. -- sparti 17:31, 4. Mai 2007 (CEST)

• pro: Der Artikel arbeitet ein Thema der Datenverarbeitung auf und erfaßt den Kern der Problematik richtig. Er spricht auch den Hasenfuß der Methodik an, daß die Realisierung allein durch Programme erreicht wird, diese bergen allerdings Risiken, die ich im Artikel nicht angesprochen finde. Deswegen mein Urteil: Lesenswert Ja, Zu mehr reicht es (noch) nicht. --SonniWP 17:42, 4. Mai 2007 (CEST)

•  Pro auch von mir. Ich habe schon einmal eine ausführliche Artikelbesprechung abgeliefert und die meisten meiner Kritikpunkte wurden zum Vorteil des Artikels genutzt. Viele Abschnitte lesen sich für mich jetzt deutlich leichter, auch der Surrogatschlüssel dürfte den Laien nun nicht mehr abschrecken. Folgende Dinge tun der Lesenswertigkeit keinen Abbruch, ich möchte sie aber für die weitere Arbeit in Richtung Exzellenz noch mit auf den Weg geben: 1) In der Einleitung muss es Informationstechnik heißen, ich habe das erneut geprüft, vgl. Technologie. 2) Die Bilder sollten zu Vektorgrafiken konvertiert werden. 3) Ich halte die Gliederung weiterhin für ungeeignet: Die blockweise Einführung von Fachbegriffen am Anfang und die Konzentrierung der Anwendungsbeispiele am Schluss wollen mir auch beim zweiten Durcharbeiten nicht zu einem Enzyklopädieartikel passen. 4) Die Quellenbelege sollten geprüft werden; für gewöhnlich genügt die einmalige Erwähnung einer Quelle, mehrfache Erwähnung mit Seitenangaben blähen die Quellenangaben unnötig auf. 5) Der Abschnitt Siehe auch erscheint mir überflüssig, da alle genannten Begriffe im Text verlinkt sind, vgl. Tätigkeit von Benutzer:Siehe-auch-Löscher. --Bitbert ^-?- 16:55, 8. Mai 2007 (CEST)

Danke für's Feedback.

• Zu (1): Ok, angepasst, mein Sprachgebrauch ist hier lt. Informationstechnik wohl falsch
• Zu (4): Habe die EInzelnachweise geprüft, halte eine weitere Zusammenfassung für nicht sinnvoll (natürlich nur für jemanden hilfreich, der das Buch Myrach2005 hat, für diesen aber sehr)
• zu (5): Vollkommen richtig, "siehe auch" war hier völlig überflüssig

Die restlichen Punkte nehme ich als langfristigere Anregungen auf.--Cactus26 07:32, 9. Mai 2007 (CEST)

•  Pro Vollständig und gut lesbar. Guter Überblick.--Jörg 12:34, 9. Mai 2007 (CEST)
•  Pro --Musbay 00:02, 11. Mai 2007 (CEST)

Version des Artikels zum Auswertzeitpunkt: 22:13, 9. Mai 2007

Übertreibungen

Zumindest im Abschnitt Temporale Datenhaltung#Abbildung in herkömmlichen relationalen Datenbanksystemen#Abbildung in herkömmlichen relationalen Datenbanksystemen befinden sich fürchterliche Übertreibungen: "Der Zugriff auf den aktuellen Wert wird wesentlich komplexer ..." und ähnliches. "Wesentlich" etc. ist einfach falsch -- Tomdo08 00:30, 16. Sep. 2010 (CEST)

Danke für Dein Feedback. Wesentlich komplizierter wird es dann, wenn der aktuelle Wert zu zwei oder mehreren getrennt voneindander histrisierten Attributen ermittelt werden soll. Das wird oft unterschätzt und Tabellen pauschal historisiert, selbst wenn es nicht nötig ist. "Einfach falsch" ist übrigens fürchterlich übertrieben.--Cactus26 09:01, 20. Sep. 2010 (CEST)

Schatten-Tabelle

Es scheint mir als wurde in dem Artikel in keinster Weise auf die Verwendung von Schattentabellen eingegangen. D.h. Trennung der Daten in alte (versionierte) Daten und aktuelle (quasi-unversionierte) Daten.

Besonders die Vorteile im Lookup sollten dargestellt werden.

• queries und indizes müssen die Zeitstempel nicht berücksichtigen wenn auf aktuellen Daten gearbeitet wird
• die Datenbank hat dadurch deutliche performance-Vorteile
• Änderung an der Struktur müssen nicht durchgeführt werden.

wobei diese Vorteile natürlich nur bei entsprechender Selektivität und natürlich bestenfalls nur linearer performancezuwachs. (nicht signierter Beitrag von 94.101.33.114 (Diskussion) 12:35, 18. Okt. 2012 (CEST))

Es stimmt, dass der Artikel kaum auf Optimierungen eingeht. Natürlich wäre dann auch zu erwähnen, dass es möglich ist, die aktuellen Daten separat zu speichern. Die nächste Frage ist dann, ob der versionierte Bestand die aktuellen Daten auch enthält. In den meisten Fällen würde ich das so sehen, das hängt aber sicherlich auch vom Anwendungsfall ab. Problematisch bei diesem Verfahren wäre, wenn es zukünftige Daten gibt (was im Falle der Gültigkeitszeit mgl. wäre). Unglücklich finde ich allerdings den Begriff "Schattentabelle". Wer ist denn der Schatten von wem? Wer nennt dieses Verfahren so?--Cactus26 (Diskussion) 10:13, 19. Okt. 2012 (CEST)

Kommerzielle Anbieter

Der Stand von 2005, dass es keine kommerziellen anbieter von Datenbanksoftware gibt, die temporale Datenhaltung ermoeglicht duerfte nicht mehr aktuell sein - zumindest in der Feature-Liste von DB2 (Version 10, also Stand 2012) taucht das auf. Eine kurze Einfuehrung bietet unter anderem dieser Artikel: https://entwickler.de/online/datenbanken/mit-der-datenbank-auf-zeitreise-116337.html (nicht signierter Beitrag von Martinalex000 (Diskussion | Beiträge) 10:02, 18. Sep. 2015 (CEST))

Zeitstempelung bitemporal

Überführung von Point-Repräsentation zur Intervall-Repräsentation

Im Abschnitt "Zeitstempelung" heißt es für den bitemporalen Fall:

"Bei der Point Repräsentation ist zu beachten, dass es nicht möglich ist, auch für die Transaktionszeit lediglich den Beginn des Intervalls als Attribut zu ergänzen, hier muss dann zumindest bei der Transaktionszeit ein Intervall verwendet werden, damit eine sinnvolle Interpretation möglich ist."

Eine Interpretation einer bitemporale Point Repräsentation ist ebenfalls möglich, da auf ihr eine View gebildet werden kann, die deren bitemporale Intervall Repräsentation ist.
Voraussetzung ist, das eine zu einem Transaktionszeitpunkt neu hinzugekommene Gültigkeit nicht von vornherein auf ein spezielles Gültigkeitsende beschränkt ist.
Das funktioniert, wenn zum Beispiel der 31.12.9999 implizit das Ende einer neuen Gültigkeit ist (die in spätere Transaktionen ungültig werden kann).
Beispiel:

   SQL für bitemporale View 

Die View "TimeSlices" in dieser SQL ist die bitemporale Intervall Repräsentation der Tabelle "Artikel", wobei "Artikel" noch eine bitemporale Point Repräsentation aufweist.
Jeder bitemporale Point Repräsentation lässt sich also in seine bitemporale Intervall Repräsentation überführen, so dass die grundsätzliche Interpretierbarkeit die gleiche ist. Das bedeutet, das Tabellen, deren Daten beide Zeitpunkte beinhalten, jederzeit zu Tabellen mit bitemporaler Intervalldarstellung migriert werden können. Soll das anfängliche Ende der Gültigkeit bei einer neuen Transaktion nicht der 31.12.9999 sein, muss zusätzlich zu der Pointpräsentation das Endedatum angegeben werden. Die SQL zur Erzeugung der bitemporalen View funktioniert dann ähnlich, jedoch muss das anfängliche Endedatum mit berücksichtigt werden.