Skip to main content

Part of the book series: Teubner-Reihe Wirtschaftsinformatik ((TRWI))

  • 575 Accesses

Zusammenfassung

Herkömmliche Datenmodelle und damit auch Datenbanksysteme sehen keine systematische Unterstützung der Zeitdimension im Sinne einer temporalen Datenverwaltung vor. Die durch sie verwalteten Datenbanken geben vor allem die Diskurs-welt zu einem bestimmten Zeitpunkt wieder. Im Konsens-Glossar werden sie dementsprechend in Abgrenzung von temporalen Datenbanken als Schnappschuss-Datenbanken bezeichnet.136 Oftmals liegt dabei eine implizite Gegenwartsbezogenheit vor. In diesem Fall zeigt eine Datenbank jeweils einen aktuellen Schnappschuss der Diskurswelt.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 89.00
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. Bewegungsdaten drücken Veränderungen von Bestandsdaten aus; vgl. z. B. Stahlknecht/ Hasenkamp (1999), S. 160: „Stamm-und Bestandsdaten beschreiben Zustände, Bewegungs-und Änderungsdaten Ereignisse.“ (Hervorhebungen im Original).

    Google Scholar 

  2. Dieses Datenmodell geht zurück auf Codd (1970). Es wird praktisch in jedem einschlägigem Lehrbuch zum Thema Datenbanken ausführlich behandelt; vgl. z. B. Ullman (1982), S. 145 ff; Schlageter/Stucky (1983), S. 80 ff; Elmasri/Navathe (1994), S. 137 ff. Ausschließlich behandeln das relationale Datenmodell etwa Kandzia/Klein (1993); Meier (1998).

    Google Scholar 

  3. Vgl. z. B. Orfali/Harkey/Edwards (1996), S. 161 ff. Siehe Abschnitt 3.1. 3.

    Google Scholar 

  4. Vgl. z. B. Rose/Segev (1991); Cheng/Gadia (1993); Dayal/Wuu (1993); Edelweiss/de Oliveira/Pemici (1993); Pissinou/Makki/Yesha (1993a) und (1993b); Peressi/Montanari/Pernici (1994).

    Google Scholar 

  5. Für formale Definitionen vgl. z. B. Ullman (1982), S. 19 f; Schlageter/Stucky (1983), S. 81 f; Kandzia/Klein (1993), S. 35 ff.

    Google Scholar 

  6. Vgl. Kandzia/Klein (1993), S. 39: „Die elementaren Operationen des relationalen Datenmodells sind einstellige und zweistellige Operationen, die DB-Relationen als Operanden haben und DB-Relationen als Ergebnisse liefern.“

    Google Scholar 

  7. Vgl. Schlageter/Stucky (1983), S. 139 ff; Kandzia/Klein (1993), S. 39 ff.

    Google Scholar 

  8. Zum Begriff der Datenunabhängigkeit vgl. z.B. Elmasri/Navathe (1994), S. 28: „… the concept of data independence… can be defined as the capacity to change the schema at one level of a database system without having to change the schema at the next higher level.“

    Google Scholar 

  9. Vgl. Entitätsintegrität z. B. Elmasri/Navathe (1994), S. 147.

    Google Scholar 

  10. Vgl. Datenbank-Literatur, z.B. Melton/Simon (1993), S. 217 ff; Elmasri/Navathe (1994), S. 147 ff.

    Google Scholar 

  11. Vgl. zur Kritik am Akronym auch Melton/Simon (1993), S. 4: „The letters [SQL], by the way, don’t stand for anything at all.“; Lusti (1997), S. 166: „Ironisierend sagt man, SQL sei eine Abkürzung fir “Scarcely Qualifies as Language„.“

    Google Scholar 

  12. Vgl. hierzu etwa Melton/Simon (2001). Den aktuellen Stand gibt auch sehr kurz Date/Darwen/Lorentzos (2003), Referenz 52, S. 398 f, wieder.

    Google Scholar 

  13. Eine allgemeine Darstellung von SQL wird in zahlreichen Büchern gegeben. Speziell mit SQL-92 beschäftigt sich z.B. Melton/Simon (1993); Darwen/Date (1997). SQL:1999 wird dargestellt in Melton/Simon (2001).

    Google Scholar 

  14. Vgl. Melton/Simon (1993), S. 211: „We strongly recommend that constraint names always be used, even though they are optional. Applications can then report more complete information when constraint violations occur, because they can get the name of the violated constraint out of the diagnostics area, thereby helping with the problem analysis process.… If you don’t give names to your constraints, the DBMS will assign them for you — but they will probably be less meaningful and less mnemonic than those you have chosen yourself.“

    Google Scholar 

  15. Eine entsprechende Unterteilung von Datenmanipulationsoperationen erfolgt verschiedentlich, wobei allerdings die Klassen unterschiedlich benannt sein können. Bei Elmasri/Navathe (1994), S. 149 ff, werden unter dem Titel „Update Operations on Relations“ die drei Operationen Insert, Delete und Modify gefasst; da in SQL ein Befehl Update existiert, sind die Begriffe hier vertauscht. Der hier verwendete Modifikationsbegriff findet sich auch bei Snodgrass (1999), S. 14.

    Google Scholar 

  16. Vgl. z. B. Melton/Simon (1993), S. 181 ff bzw. 49 f. 10 Vgl. Melton/Simon (1993), S. 201 ff.

    Google Scholar 

  17. Vgl. z. B. Elmasri/Navathe (1994), S. 220; Orfali/Harkey/Edwards (1996), S. 161 ff. 13 Vgl. Knolmayer/Schlesinger (1996a); Knolmayer/Schlesinger (1996b).

    Google Scholar 

  18. Vgl. Dayal (1988). Eine einfach verständliche Übersicht geben Dittrich/Gatziu (1996), S. 15 ff.

    Google Scholar 

  19. Gemäß dem gregorianischen Kalender ist das Jahr 2000 ein Schaltjahr, nicht jedoch das Jahr 1900; siehe auch Abschnitt 2.1.2.

    Google Scholar 

  20. Vgl. Konsens-Glossar (Jensen/Dyreson (1998), S. 376 f). Die Abgrenzung in TSQL2 wird in Snodgrass (1995), S. 127 ff, erläutert.

    Google Scholar 

  21. Vgl. Date (1988), S. 58; dort wird von einen Fall aus der IBM–Welt berichtet: Die Operation DATE(’1987–3–31’) + 1 MONTH —1 MONTH führt zum Datumswert ‘1987–3–30’.

    Google Scholar 

  22. Vgl. Koch/Muller (1993), S. 504; an jener Stelle wird auch gezeigt, wie sich die Funktionalität eines INTERvAL-Datentyps über Stored Procedures realisieren lässt.

    Google Scholar 

  23. Vgl. z. B. Ariav (1991), S. 453; siehe auch Tansel (1986), der diesbezüglich von einer point representation spricht.

    Google Scholar 

  24. Vgl. auch Tansel (1986), S. 345: „… this approach splits the time interval between two successive pairs. Hence, to determine the time duration over which a a value is valid, the successor pair has to be examined. This creates complications in expressing and interpreting the relational algebra operations.“

    Google Scholar 

  25. Vgl. Celko (1995), S. 72; Snodgrass (1999), S. 120.

    Google Scholar 

  26. Dies ist etwa beim SQL-Server von Microsoft mit den Datentypen DATE und SMALLDATE der Fall; vgl. z. B. Snodgrass (1999), S. 50 ff.

    Google Scholar 

  27. Vgl. auch Snodgrass (1999), S. 91. 2°4 Vgl. Melton/Simon (1993), S. 139 f.

    Google Scholar 

  28. Vgl. z. B. die anschaulichen Erläuterungen bei Celko (1995), S. 148 ff.

    Google Scholar 

  29. Da für den nicht-temporalen Teil des Schlüssels oftmals unterstellt wird, dass er sich in der Zeit nicht ändert, wird er auch als zeitinvariabler Schlüssel bezeichnet; vgl. z. B. Navathe/Ahmed (1993), S. 93: „A time-invariant key (TIK) normally serves as the primary key of a static version of a time-varying relation.“

    Google Scholar 

  30. Vgl. dazu auch die Ausführungen bei Snodgrass (1999), S. 117 f.

    Google Scholar 

  31. Date/Darwen/Lorentzos (2003), S. 194 ff, sprechen hier vom Widerspruchsproblem

    Google Scholar 

  32. Contradiction Problem). Daneben erwähnen sie im Zusammenhang mit einem temporalen Schlüssel auch das Redundanzproblem (Redundancy Problem) und das Umschreibungsproblem (Circumlocution Problem), auf die hier nicht eingegangen wird.

    Google Scholar 

  33. Vgl. für derartige Unterabfragen in einer CHEcK-Klausel Melton/Simon (1993), S. 211 ff, wo auch die Zweckmäßigkeit der Verwendung von CONSTRAINTS oder ASSERTIONS ausgeführt wird.

    Google Scholar 

  34. Vgl. dazu Elmasri/Navathe (1994), S. 151: „Modifying a primary key value is similar to deleting one tuple and inserting another in its place, because we use the primary key to identify tuples.“

    Google Scholar 

  35. Vgl. z. B. Melton/Simon (1993), S. 221 ff.

    Google Scholar 

  36. Vgl. z. B. Elmasri/Navathe (1994), S. 527 ff.

    Google Scholar 

  37. Vgl. z. B. Melton/Simon (1993), S. 259 ff.; auch Elmasri/Navathe (1994), S. 223 f.

    Google Scholar 

  38. Vgl. zu den folgenden Ausführungen auch Böhlen/Snodgrass/Soo (1996).

    Google Scholar 

  39. Siehe Abschnitt 2.3.2.1. Dies wird von Date/Darwen/Lorentzos (2003), S. 187 ff, sogar als integraler Bestandteil einer temporalen Schlüsselintegrität angesehen.

    Google Scholar 

  40. Zum Begriff vgl. Konsens-Glossar (Jensen/Dyreson (1998), S. 386 f); vgl. auch den Exkurs bei Kaiser (2000), S. 94 ff. Eine formale Definition für bitemporale Relationen gibt Snodgrass (1995), S. 235 ff. Die Notwendigkeit eines Coalescing stellt für Clifford et al. (1995), S. 207 f, einen Kritikpunkt am tupel-orientierten Ansatz dar.

    Google Scholar 

  41. Snodgrass (1999), S. 168, gibt eine entsprechende Routine im PL/SQL von ORACLE an, mit der sich ein Coalescing im Zuge einer Projektion durchfiihren lässt. Anders als die hier angegebene Routine werden keine Tupel zwischenspeichert. Stattdessen sind in den Vergleich bis zu drei verschiedene Tupel einbezogen.

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 2005 B. G. Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden

About this chapter

Cite this chapter

Myrach, T. (2005). Temporale Daten in herkömmlichen Datenbanksystemen. In: Temporale Datenbanken in betrieblichen Informationssystemen. Teubner-Reihe Wirtschaftsinformatik. Vieweg+Teubner Verlag. https://doi.org/10.1007/978-3-322-80059-6_3

Download citation

Publish with us

Policies and ethics