Diskussion:Temporale Datenhaltung

message: * 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)
replies: text:  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)
replies: text:  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)

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

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

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

message: 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)
replies: text:  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)
replies: text:  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)
thread_title:  Kurts Kommentar 

message: (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)
replies: text: 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)
replies: text: Werde ich demnächst einbauen, danke.--Cactus26 18:18, 1. Apr. 2007 (CEST)
thread_title:  Surrogatschlüssel 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: Bin nicht gerade Spezialist in Bezug auf Datawarehouse und habe ein wenig recherchiert () 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)
replies: text:  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)
replies: text:  Ja, das stimmt. Diese Unterscheidung koennte bei den Anwendungen nochmal erwaehenen. -- sparti 09:23, 20. Mär. 2007 (CET)
replies: text: Ok, werde es probieren.--Cactus26 12:01, 20. Mär. 2007 (CET)

text: 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)
replies: text: Vielen Dank für die Verbesserungen, sparti! --Cactus26 10:28, 21. Mär. 2007 (CET)
replies: text: 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)
replies: text: Danke. Werde mir diese Thematik bei Gelegenheit mal genauer ansehen.--Cactus26 12:52, 27. Dez. 2008 (CET)
thread_title: Temporale Datenhaltung und Datawarehouse

message: 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)
replies: text: Wie könnte man das offensichtlicher machen?--Cactus26 07:17, 18. Apr. 2007 (CEST)

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

message: 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)
replies: text: 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)
thread_title:  Übertreibungen 

message: 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)
replies: text: 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)
thread_title:  Schatten-Tabelle  

message: 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)
thread_title:  Kommerzielle Anbieter