Advertisement

Datenbankarchitekturen in der Unternehmung

  • Hans-Jürgen König
Part of the DUV Wirtschaftsinformatik book series (WI)

Zusammenfassung

Die Gestaltung von Datenbankarchitekturen in der Unternehmung setzt ein Basisverständnis in den Gebieten Datenbanksysteme, Datenbanksprachen, Datenmodellierung und Rechnervernetzung voraus. Soweit es für das Verständnis dieser Arbeit erforderlich ist, wird in Abschnitt 2.1 in die Grundlagen von Datenbanksystemen und Datenbanksprachen, wie auch in die Grundlagen der Datenmodellierung 236 eingeführt. Aus einer Informatik-Perspektive heraus erlaubt diese Einführung eine Fundierung einiger Aussagen aus Kapitel 1237 und bildet die Grundlage für einige der nachfolgenden Abschnitte und Kapitel238. In Abschnitt 2.2 werden Probleme und zugehörige Lösungsmethoden einer Adaption der logischen Struktur der Unternehmungsdaten an sich verändernde Anforderungen an die Informationsversorgung vorgestellt. Diese Ausführungen vertiefen insbesondere das Verständnis der Probleme einer logischen Integration dezentraler Datenbanken und verdeutlichen die Potentiale und Restriktionen einer veränderlichen, virtuellen Integration zur flexiblen und bedarfsorientierten Informationsversorgung. Abschnitt 2.3 führt in knapper Weise in die logischen und technischen Grundlagen der Rechnervernetzung ein. In Abschnitt 2.4 wird das Client-Server-Konzept dargestellt und seine betriebswirtschaftliche Relevanz für die Bereiche Geschäftsprozeßgestaltung und -automation durch flexible Integrierbarkeit elektronischer Aufgabenträger in betriebswirtschaftliche Prozeßketten diskutiert.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 236.
    Eine Übersicht findet man auch in [Nava92].Google Scholar
  2. 237.
    Beispiele sind Datenbankentwurf, Untemehmungsdatenmodellierung, Qualitätsmanagement, Zugriffsbereiche, Integritätsbereiche, Transaktionsbereiche oder die Modellierung von Datenbedarfsmodellen.Google Scholar
  3. 238.
    Der “Datenbankprofi” mag diesen Abschnitt 2.1 “diagonal” lesen.Google Scholar
  4. 239.
    Vgl. [Wied89],[Stah89].Google Scholar
  5. 240.
    Vgl. [ScSt83, S. 255ff.].Google Scholar
  6. 241.
    Festplatte, Hauptspeicher und Cache [Hans92, S. 230ff.].Google Scholar
  7. 242.
    Vgl. [IBM].Google Scholar
  8. 243.
    Vgl. auch Abschnitt 1.2.Google Scholar
  9. 244.
    Vgl. [LoSc87, S. 88ff.],[Voss87, S. 28ff.],[Date90, S. 399ff.].Google Scholar
  10. 245.
    Vgl. [ElNa89, S. 133ff.].Google Scholar
  11. 246.
    Dieses sind z.B. Zahlen oder (kurze) Zeichenketten einer begrenzten Länge.Google Scholar
  12. 247.
    Dieses sind z.B. elektronische Dokumente (Formulare) oder multimediale Daten, wie z.B. elektronisch repräsentierte Bilder oder “Sound-Files” (z.B. Musik).Google Scholar
  13. 248.
    Z.B. Binary Large Objects (BLOB) [OrHa92, S. 543ff.].Google Scholar
  14. 249.
    Vgl.[SaMc87]. Ein klassisches Informationswiedergewinnungssystem ist STAIRS (Storage and Information Retrieval System). Zeitgemäße Informationswiedergewinnungssysteme, wie z.B. das System “Lotus Notes”, basieren als Dokumenten-Server auf dem Client-Server-Konzept (vgl. Abschnitt 2.4) und sind aufgrund ihrer Mehrbenutzerfähigkeit, wie auch aufgrund erweiterter Funktionalitäten und Kommunikationsmöglichkeiten dem Bereich der Groupware [Hans92, S. 860ff.] zuzurechnen.Google Scholar
  15. 250.
    Neuerdings werden auch Werkzeuge und Schnittstellen (z.B. das Produkt “SQL-Partner”) angeboten, die die Entwicklung von Anwendungen unterstützen, welche (jedoch nicht innerhalb von einem Zugriff) sowohl auf formatierte Daten in Datenbanken als auch auf unformatierte Daten in Dokumenten-Server zugreifen können. Hierdurch wird eine engere Integration der Nutzung beider Arten von Datenverwaltungssystemen unterstützt.Google Scholar
  16. 251.
    ANSI/SPARC steht für American National Standards Institute/Standards Planning and Requirements Committee.Google Scholar
  17. 252.
    Vgl. [ANSI75], [Hahn94, S. 806],[ScSt83, S. 26ff.],[Voss87, S. 18ff.].Google Scholar
  18. 253.
    Interne Schemata sind für die vorliegende Arbeit von untergeordneter Bedeutung.Google Scholar
  19. 254.
    Logische Schemata als bestehende Integrationsbereiche einer gewachsenen Datenbankarchitektur sind als Grundlage für eine Gestaltung unternehmungsweiter Datenbankarchitekturen von großer Bedeutung.Google Scholar
  20. 255.
    Vgl. auch Abschnitt 2.2.1, das View-Update-Problem.Google Scholar
  21. 256.
    Der Datenbank-Designer implementiert das logische Schema einer Datenbank. Dessen Übersetzung in ein zugehöriges internes Schema erfolgt in zeitgemäßen Systemen i.d.R. automatisch durch das DBMS.Google Scholar
  22. 257.
    Unabhängigkeit der Daten vom Anwendungsprogramm bedeutet eine Datenspeicherung, die unabhängig vom erzeugenden oder benutzenden Anwendungsprogramm erfolgt [Hahn94, S. 807].Google Scholar
  23. 258.
    Dieses gilt auch für elektronische Aufgabenträger im Rechnernetz der Unternehmung, wie auch für die Unterstützbarkeit der Datenbedarfsmodelle einzelner Aufgabenträger oder organisatorischer Einheiten.Google Scholar
  24. 259.
    Vgl. die Abschnitte 2.7 und 2.8.Google Scholar
  25. 260.
    Vgl. [LoSc87, S. 88ff.],[Voss87, S. 28ff.],[Date90, S. 399ff.].Google Scholar
  26. 261.
    Ein Data Dictionary im hier vorliegenden Sinne enthält nur die Metadaten der zugehörigen Datenbank. Die Zwecksetzung eines Data Dictionaries im Sinne von [Ortn91b] (z.B. IRDS) ist sehr viel weitgehender, da sie sich auf die gesamte (System-) Datenbankarchitektur einer Unternehmung bezieht.Google Scholar
  27. 262.
    Die Meta-Daten einer Datenbank können je nach DBMS als geschützte Bereiche in der zugrundeliegenden operativen Datenbank mit abgelegt sein.Google Scholar
  28. 263.
    Ein Query-Prozessor ist ein softwareseitig realisiertes Modul eines DBMS.Google Scholar
  29. 264.
    Vgl. [AlOt86],[Hero92].Google Scholar
  30. 265.
    Vgl. [Pear84].Google Scholar
  31. 266.
    Vgl. [Ullm89, S. 633ff.LGoogle Scholar
  32. 267.
    Vgl. die Abschnitte 2.8.2 und 2.8.3.Google Scholar
  33. 268.
    Die genannten Funktionen können auch als getrennte Module eines DBMS realisiert sein.Google Scholar
  34. 269.
    Vgl. Abschnitt 1.3.Google Scholar
  35. 270.
    [ScSt83, S. 294ff.],[Date90, S. 401ff.],[Voss87, S. 368ff.]. [Hahn94, S. 807] spricht von Vielfachzugriff.Google Scholar
  36. 271.
    Eine diesbezüglich relevante Transaktion enthält mindestens eine schreibende Datenbankoperation, da rein lesende Zugriffe den Zustand der Datenbank nicht verändern.Google Scholar
  37. 272.
    Vgl. [BeHa87],[Jabl903],[JaRu91].Google Scholar
  38. 273.
    Das bekannteste Beispiel ist das 2-Phasen-Sperrprotokoll, gemäß dem eine Transaktion erst Sperren auf Daten freigeben darf, wenn von ihr keine weiteren Sperren nachgefordert werden. Andere Klassen von Synchronisationsverfahren basieren auf dem Prinzip der optimistischen Synchronisation oder benutzen Zeitstempel. Google Scholar
  39. 274.
    Vgl. [ScSt83, S. 325ff.].Google Scholar
  40. 275.
    Ein partiell integrierter Integrationsbereich umfaßt nur eine Teilmenge der Unternehmungsdaten in ihrer Gesamtheit.Google Scholar
  41. 276.
    In diesem Fall sind nur lesende Zugriffe erforderlich.Google Scholar
  42. 277.
    In einigen Fällen sind bereits Modellierungswerkzeuge am Markt verfügbar, die ein semantisches Datenmodell eines Realweltausschnitts, wie z.B. eine ERM-Spezifikation, in ein relationales Datenbankschema übersetzen. Jedoch erkauft man sich i.d.R. diese Automation mit Einschränkungen der Freiheitsgrade beim Design des relationalen Datenbankschemas. Derartige Werkzeuge werden z.T. als 4GL-(Generation Language) Tools von DBMS-Herstellern angeboten.Google Scholar
  43. 278.
    Vgl. [chen76]. In der Literatur sind eine Vielzahl von Erweiterungen und Varianten des ERM anzutreffen. Siehe in diesem Zusammenhang auch SERM (Strukturiertes ERM) [Sinz88],[Sinz90]. In der betriebswirtschaftlichen Praxis weniger bedeutende semantische Datenmodelle sind das Functional Data Modell (FDM) [SiKe77], das Semantic Data Model (SDM) [HaMc90], wie auch das Generic Semantic Model (GSM) [HuKi87]. Eine Übersicht weiterer semantischer Datenmodelle findet man in [PeMa88]. Aufgeführt sind TAXIS [BoMy84], RM/T [Codd791, SAM* [Su83], The Event Model [KiMc84] und SHM [Brod84].Google Scholar
  44. 279.
    Vgl. Abschnitt 1.5.3.Google Scholar
  45. 280.
    Vgl. Abschnitt 2.6.2.Google Scholar
  46. 281.
    Vgl. auch [Hahn94, S. 806].Google Scholar
  47. 282.
    So beschreibt z.B. der Objekttyp MITARBEITER bestehend aus den Attributen MitarbeiterNummer. MitarbeiterName und MitarbeiterFamilienstand konkrete Mitarbeiter einer Unternehmung als Objekte dieses Objekttyps. Ein konkreter Mitarbeiter kann hier durch das Tripel von Attributwerten (Daten) (z.B. <1,Kunz,’ledig’>) repräsentiert werden.Google Scholar
  48. 283.
    Vgl. [ElNa89, S. 141].Google Scholar
  49. 284.
    Primärschlüssel werden im folgenden unterstrichen dargestellt.Google Scholar
  50. 285.
    Vgl. [Masu891,[KhCo90]. Surrogate sind in objektorientierten DBMS anzutreffen. Sie unterstützen Objekt-Identität, d.h. die Unterscheidbarkeit unterschiedlicher, jedoch in ihrer Beschreibung völlig identischer Objekte durch das DBMS.Google Scholar
  51. 286.
    Vgl. [ElNa89, S. 28f.].Google Scholar
  52. 287.
    Vgl. [Date90, S. 753ff.],[Gill90, S. 261ff.].Google Scholar
  53. 288.
    Im wesentlichen das Produkt IMS (Information Management System), welches in späteren Releases auch Konstrukte unterstützte, die ein Durchbrechen der strengen hierarchischen Realweltmodellierung ermöglichen.Google Scholar
  54. 289.
    Siehe “relationales Datenmodell” in Abschnitt 2.1.6.Google Scholar
  55. 290.
    Vgl. [ScSt83, S. 92ff.].Google Scholar
  56. 291.
    Vgl. [CODA71],[CODA73],[CODA78].Google Scholar
  57. 292.
    Anstatt einer Menge von Bäumen.Google Scholar
  58. 293.
    Vgl. [Codd70].Google Scholar
  59. 294.
    Eine explizite Unterscheidung von Objekttypen und Beziehungstypen existiert nicht.Google Scholar
  60. 295.
    Vgl. [IBM91a].Google Scholar
  61. 296.
    Vgl. [AtDe93].Google Scholar
  62. 297.
    Vgl. [DuHa89].Google Scholar
  63. 298.
    Vgl. [Date90, S. 295ff.].Google Scholar
  64. 299.
    Vgl. [Codd71].Google Scholar
  65. 300.
    So wird z.B. die Formulierung einer Query der folgenden Art unterstützt: Finde alle Mitarbeiter, die in Hessen wohnen und die mehr als 6.000 DM verdienen. Dem System muß u.a. nicht mehr mitgeteilt werden, ob ein bestimmter Index für den Zugriff zu verwenden ist.Google Scholar
  66. 301.
    Vgl. [Codd72].Google Scholar
  67. 302.
    Vgl. [DaDa93].Google Scholar
  68. 303.
    Vgl. [ISO87],[ISO89],[ISO92].Google Scholar
  69. 304.
    D.h. ein Nachteil gegenüber objektorientierten Datenmodellen.Google Scholar
  70. 305.
    Vgl. [DaKü88].Google Scholar
  71. 306.
    Vgl. [2dMa90, S. 3f.].Google Scholar
  72. 307.
    Vgl. [HoUl79, S. 146ff.].Google Scholar
  73. 308.
    Eine Umfrage bei 200 deutschen Großanwendern erbrachte, daß fast zwei Drittel (73,3 Prozent) bereits mit relationalen Datenbanksystemen arbeiten oder sie zumindest in den kommenden zwei Jahren zum Einsatz bringen wollen [oV93a, S. 6].Google Scholar
  74. 309.
    Vgl. [KiLo89],[ZdMa90],[Heue92].Google Scholar
  75. 310.
    Vgl. [UnSc90, S. 163ff.].Google Scholar
  76. 311.
    Von struktureller Objekt-Orientierung spricht man, wenn ein Konzept für komplexe Objekte (natürlich samt der zugehörigen genetischen Operationen) vorhanden ist; Objektidentität und strukturelle Vererbung können hinzukommen [Ditt91, S. 151.Google Scholar
  77. 312.
    im RDM ist die Menge verwendbarer Datentypen vom DBMS vorgegeben und nicht veränderbar.Google Scholar
  78. 313.
    Vgl. 2.B. [LeRi90]. Typkonstruktoren erlauben benutzerseitige Erweiterungen im Typsystem, so daß aus einfachen Datentypen (z.B. INTEGER, REAL, STRING) oder aus bereits existenten komplexen Datentypen komplexe Datentypen zur Repräsentation komplex strukturierter Objekte definiert werden können.Google Scholar
  79. 314.
    Verhaltensmäßige Objekt-Orientierung liegt vor, wenn zwar komplexe Objekte nicht (ausreichend) unterstützt werden, aber ein Konzept zur Definition neuer Datentypen durch den Benutzer vorhanden ist [Ditt91, S. 15].Google Scholar
  80. 315.
    Die Hersteller relationaler DBMS neigen dazu, den ISO-SQL-Standard zwar zu unterstützen, jedoch darüber hinaus auch herstellerspezifische Erweiterungen anzubieten. Heterogenität liegt auch hier vor, sobald eine betreibende Unternehmung von diesen Erweiterungen Gebrauch macht.Google Scholar
  81. 316.
    So besitzt z.B. das DBMS O2 ein produktspezifisches objektorientiertes Datenmodell [LeRi90]. Anders formuliert ist O2 die Umsetzung des zugrundeliegenden, theoretisch entworfenen Datenmodells in ein kommerzielles DBMS.Google Scholar
  82. 317.
    Z.B. für Kontokorrent oder Depotverwaltung.Google Scholar
  83. 318.
    Vgl. [Codd70].Google Scholar
  84. 319.
    Vgl. auch [Voss87, S. 95ff.]. Eine detaillierte Abgrenzung des relationalen Datenmodells zu (damals) gängigen Paradigmen der Datenhaltung findet man bei [Date86b].Google Scholar
  85. 320.
    Wertebereiche sind Mengen von potentiellen Attributwerten.Google Scholar
  86. 324.
    Vgl. [GrAp93].Google Scholar
  87. 325.
    Vgl. [ElNa89, S. 142ff.].Google Scholar
  88. 326.
    Vgl. [ElNa89, S. 142ff.].Google Scholar
  89. 327.
    Vgl. [AtDe93, S. 115f.].Google Scholar
  90. 328.
    Vgl. [AtDe93, S. 152ff.].Google Scholar
  91. 329.
    Vgl. [AtDe93, S. 205ff.].Google Scholar
  92. 330.
    Auch spielen Inklnsionsabhängigkeiten (inclusion dependencies) [AtDe93, S. 205ffJ in der Praxis des Datenbankentwurfs relationaler Datenbanken nur eine untergeordnete Rolle.Google Scholar
  93. 331.
    Vgl. die Erfordernis der Ausführbarkeit verknüpfender Queries über flexibel gestalteten Zugriffsbereichen einer dezentralen Datenbankarchitektur (Abschnitt 1.3, Integrationsmanagement) .Google Scholar
  94. 332.
    Von Spezialfällen, wie der schwachen vierten Normalform [ScSt83, S. 208] oder der Domain Key Normal Form [AtDe93, S. 208] wird hier abgesehen.Google Scholar
  95. 333.
    Höhere Normalformen bedingen natürlich auch Mengen von Tabellen, da eine Relation in 2NF etc. automatisch in INF ist.Google Scholar
  96. 334.
    Dieses gilt auch für höhere Normalformen.Google Scholar
  97. 335.
    Vgl. Abschnitt 2.1.8.Google Scholar
  98. 336.
    Ein Beispiel ist der 3NF-Synthesealgorithmus [ScSt83, S. 215f.].Google Scholar
  99. 337.
    Vgl. [ElNa89, S. 148ff.].Google Scholar
  100. 338.
    Die Datentypen INTEGER für ganze Zahlen und STRING für Zeichenketten sind z.B. nicht typkompatibel. So besitzt z.B. die Zahl 15 eine andere Bedeutung als die Zeichenkette ‘15’. Insbesondere ist es u.a. nicht möglich, die Zeichenkette ‘15’ als Operand für Rechenoperationen zu verwenden oder 15 und ‘15’ auf Gleichheit zu überprüfen.Google Scholar
  101. 339.
    Dieses stellt eine Verletzung der im zugehörigen ERM (vgl. Abb. 5) spezifizierten Integritätsbedingung dar, gemäß welcher jeder Kunde mindestens in einen Kontrakt involviert sein muß. Die Gewährleistung dieser Integritätsbedingung müßte durch eine referentielle Integritätsbedingung zwischen KundenNr aus KUNDE (abhängige Seite) und KundenNr aus KONTRAKT (unabhängige Seite) zu implementieren sein. Dieses ist jedoch im Falle des vorliegenden relationalen Datenbankschemas nicht möglich, da KundenNr nur ein Bestandteil des Primärschlüssels (KundenNr, GattungsNr) in KONTRAKT ist.Google Scholar
  102. 340.
    In diesem Fall würde in RESULT1 die Spalte “KundenNr” zweimal auftreten.Google Scholar
  103. 341.
    (7) bzw. RESULTl liegt ein Natural Join zugrunde.Google Scholar
  104. 343.
    Diese Eigenschaft wird im Design von FDS-System explizit nutzbar gemacht. Vgl. Abschnitt 2.8.Google Scholar
  105. 344.
    Vgl. [IBM91a].Google Scholar
  106. 345.
    Vgl. [Lock93].Google Scholar
  107. 346.
    Vgl. [LiKü91].Google Scholar
  108. 347.
    Vgl. [DyTo91].Google Scholar
  109. 348.
    Wie z.B. AIM-P (Advanced Information Management Prototype) [Pist87] und Starburst [LoLi9l].Google Scholar
  110. 349.
    Vgl.[CeGo90],[Mink88],[KiGü90]. Vgl. auch Kapitel 4.Google Scholar
  111. 350.
    Vgl. [ClMe87].Google Scholar
  112. 351.
    Vgl. [CeGo90, S. 75ff.].Google Scholar
  113. 352.
    Vgl. [BuKö92a].Google Scholar
  114. 353.
    Ein Beispiel ist das System DECLARE (Declarative Reasoning).Google Scholar
  115. 354.
    Vgl. [McSn91]. Vgl. u.a. auch [Aria86],[SnAh85].Google Scholar
  116. 355.
    Valid time concerns modeling a time-varying reality. The valid time of, say, an event is the clock-time, at which the event occured in the real world, independent of recording that event in some database [McSn91, S. 505].Google Scholar
  117. 356.
    Transaction time, on the other hand, concerns the storage of information in the database. The transaction time of an event (perhaps represented as an integer) identifies the transaction that stored the information about the event in the database [McSn91, S. 5051.Google Scholar
  118. 357.
    User-defined time is an uninterpreted domain for which the data model supports the operations of input, output, an perhaps comparison. As its name implies, the semantics of user-defined time is provided by the user or application program. The relational algebra already supports user-defined time because it is simply another domain, such as integer or character string [McSn91, S. 505f.].Google Scholar
  119. 358.
    User-defined time z.B. unter Verwendung des Datentyps INTEGER oder STRING ist grundsätzlich immer möglich.Google Scholar
  120. 359.
    Der NF2-Prototyp A1M-P besitzt eine temporale Erweiterung.Google Scholar
  121. 360.
    Hiermit ist im Sinne von Kapitel 1 ein Träger eines Datenbedarfs gemeint.Google Scholar
  122. 36.
    36l Die zugehörigen Daten (Attributwerte) sind ihm natürlich nicht zugänglich.Google Scholar
  123. 362.
    Vgl. [Date86a, S. 366] und die dort referenzierte Literatur.Google Scholar
  124. 363.
    In “SELECT *” steht “*” für “alle Attribute”, d.h. hier für KundenName und Standing.Google Scholar
  125. 364.
    Einrichtung von externen Schemata über einzelnen bestehenden Datenbanken. Vgl. auch Abschnitt 1.4.Google Scholar
  126. 365.
    Logische Restrukturierungen einzelner Datenbanken. Vgl. auch Abschnitt 1.4.Google Scholar
  127. 366.
    Hier ist in der Literatur ein anderer View-Begriff als im Kontext des View-Update-Problems anzutreffen. Ein View ist hier keine Relation eines externen Schemas, sondern eine Art konzeptionelles Realweltmodell, das mit anderen konzeptionellen Realweltmodellen zu vereinigen ist. Es kann aufzufassen sein als eine Sichtweise auf Ausschnitte einer Datenbank, die es derzeit noch nicht gibt, sondern die erst auf Basis des Ergebnisses des konzeptionellen Integrationsschrittes angelegt wird.Google Scholar
  128. 367.
    View integration (in database design) produces a global conceptual description of a proposed database [BaLe86, S. 324].Google Scholar
  129. 368.
    Database integration (in distributed database management) produces the global schema of a collection of databases. This global schema is a virtual view of all databases taken together in a distributed database environment [BaLe86, S. 324].Google Scholar
  130. 369.
    Aus diesem Grund wird in Abschnitt 3.4 im Kontext beziebungserhaltender Alloka-Honen gefordert, daß jeder Beziehungstyp eines ERM als eigene Relation des fiktiven logischen Schemas abzubilden ist.Google Scholar
  131. 370.
    Vgl. [BaLe86, S. 343L Binäre Integrationsstrategien integrieren paarweise je zwei Datenbedarfsmodelle. Im Falle der Leiter wird sukzessive je ein weiteres Datenbedarfsmodell hinzuintegriert. Im Falle eines balancierten Baums werden im ersten Schritt jeweils Paare von Datenbedarfsmodellen integriert. Im zweiten Schritt werden wiederum Paare der Ergebnisse des ersten Schritts integriert usw. One-shot ist der Versuch einer Integration aller Datenbedarfsmodelle “auf einen Schlag”. Iterative Integrationsstrategien sind mehrstufig und integrieren auf jeder Integrationsstufe u.U. mehr als zwei Datenbedarfsmodelle.Google Scholar
  132. 371.
    [BaLe86] ist folgende Taxonomie zu finden. Es wird davon ausgegangen, daß für ein Konzept in unterschiedlichen Datenbedarfsmodellen die Repräsentationen R1 und R2 anzutreffen sind:Google Scholar
  133. Identität: R1 und R2 sind exakt gleich.Google Scholar
  134. Äquivalenz: R1 und R2 sind nicht exakt gleich, da z.B. unterschiedliche Konstrukte des Datenmodells zur Modellierung herangezogen wurden. Man kann drei Arten von Äquivalenz unterscheiden:Google Scholar
  135. (a) Verhalten: R1 ist äquivalent zu R2, wenn für jede Belegung von R1 mit konkreten Daten eine Belegung von R2 mit konkreten Daten existiert (und umgekehrt), so daß eine beliebige Query in beiden Fällen dasselbe Ergebnis produziert.Google Scholar
  136. (b) Abbildung: R1 und R2 sind äquivalent, wenn ihre Instanzen (z.B. Objekte, Tupel) eine “eins-zu-eins”-Korrespondenz besitzen.Google Scholar
  137. (c) Transformation: R1 ist äquivalent zu R2, wenn R2 aus R1 durch Anwendung einer bestimmten Menge atomarer und äquivalenzerhaltender Transformationsoperationen erzeugt werden kann.Google Scholar
  138. Kompatibilität: R1 und R2 sind weder identisch noch äquivalent. Sie sind andererseits auch nicht widersprüchlich.Google Scholar
  139. Inkompatibilität: R1 und R2 sind widersprüchlich und schließen sich wechselseitig aus.Google Scholar
  140. Äquivalenz, Kompatibilität und Inkompatibilität stellen Konflikte dar.Google Scholar
  141. 372.
    Vgl. [AlSc81],[BaLe84],[CaVi83],[DaHw84],[ElLa87],[Kahn79J,[MaEf84], [MoBu81],[NaGa82],[TeFr82],[WiEl79],[YaWa82].Google Scholar
  142. 373.
    Datenmodellierung hat sich als Methode zur Spezifikation betrieblicher Informationssysteme durchgesetzt. Die Größe und Komplexität der entstehenden Datenmodelle behindert jedoch ihre adäquate Verwendung bei der Darstellung globaler Informationszusammenhänge und bei der Anwendungsintegration [Mist9l, S. 289]. Vgl. auch [TeWe89].Google Scholar
  143. 374.
    Es zeigen sich jedoch auch sehr deutlich die Grenzen der Verwendbarkeit von Basisdatenmodellen dieser Größe: Google Scholar
  144. Sie sind aufgrund ihrer Komplexität für Außenstehende zunächst unverständlich und werden deshalb abgelehnt. Google Scholar
  145. • Die Redundanzfreiheit und Konsistenz des Datenmodells kann nur mit sehr großem Aufwand bei hohem Sachverstand sichergestellt werden. Google Scholar
  146. • Der Abgleich überlappender Modellbereiche zwischen unterschiedlichen Projektteams ist extrem schwierig [Mist91, S. 298].Google Scholar
  147. 375.
    Vgl. hierzu auch [HeKr93].Google Scholar
  148. 376.
    So werden hohe Erwartungen bezüglich der Verfügbarkeit eines Untemehmungsda-tenmodells gehegt: Das Datenmodell ist hier eine Art “Lexikon” der gültigen Fachterminologie in Unternehmen. Es dient damit der verständlichen Kommunikation zwischen den Fachabteilungen, zwischen Fachabteilung und DV-Bereich sowie dem Unternehmen und externen Stellen wie Kunden, Lieferanten, Behörden, Soßware-Unternehmen etc. [Ortn91c, S. 274]. Es eröffnet sich scheinbar die “Chance”, daß eine Unternehmung im Innenverhältnis wie im Außenverhältnis in Kategorien von Attributen, Beziehungen und Komplexitätsgraden kommuniziert. Im Falle einer Beschränkung der Benennungen auf 8 Stellen, wie sie z.T. durch DBMS determiniert ist (ein Unternehmungsdatenmodell sollte keine anderen Benennungen für Attribute besitzen als zugehörige Namen in Schemata), könnte eine “natürliche” wie “innovative” Kommunikation zwischen Menschen z.B. am Telefon wie folgt ablaufen: Das Angebot bezieht sich natürlich nur auf Ihre GutBonKd ihrer InlTochG, für die es gemäß KdGesLf mindestens drei LiefNr mit jeweils LfVol von mindestens 1000 und deren KdWoOrt auch in BerVAntw mit Bereich203’ korrespondiert. Google Scholar
  149. 377.
    Vgl. Abschnitt 2.6.2.Google Scholar
  150. 378.
    Ein Datenmodell ist letztlich eine Datenbeschreibungssprache. Wie im Falle einer Übersetzung eines Textes vom Deutschen ins Französische, können nicht immer alle semantischen Feinheiten korrekt und eindeutig übersetzt werden.Google Scholar
  151. 379.
    Dieser Fall tritt z.B. auf, wenn ein (umfangreiches) objektorientiertes Schema in ein relationales Schema zu übersetzen ist.Google Scholar
  152. 380.
    Ist ein komplexes Objekt im Sinne der Objektorientierung über mehrere “flache” Relationen unnatürlich, jedoch relational, modelliert, ziehen i.d.R. strukturelle Anpassungen in der Objektstruktur in der relationalen Repräsentation unnötig komplexe Änderungen nach sich. Vgl. hierzu das Roboterbeispiel im R2D2-Projekt [DaSü89].Google Scholar
  153. 381.
    Hierunter ist ein allgemeines Verfahren zu verstehen, das für ein beliebiges Schema auf Basis eines Datenmodells ein semantisch (möglichst) äquivalentes Schema auf Basis eines anderen Datenmodells generiert.Google Scholar
  154. 382.
    Verbreitet sind 4GL-Tools, die z.B. ein als Entity-Relationship-Modell formuliertes semantisches Modell in ein relationales Schema übersetzen. Auch können “Migrationswerkzeuge” (z.B. aus IMS in das relationale DB2) derartige Features enthalten.Google Scholar
  155. 383.
    Vgl. [Hans92, S. 375f.].Google Scholar
  156. 384.
    Ein Beispiel ist die AS/400.Google Scholar
  157. 385.
    In den Bereichen Multi-Tasking, Protected Mode, Interprozeßkommunikation, Netzwerkfähigkeit, Semaphoren, Threads, Hauptspeicherlimitierung, etc.Google Scholar
  158. 386.
    Die Hardware-Preise wiesen in den letzten Jahren eine stark fallende Tendenz auf, insbesondere bei den Hauptspeichern und bei den Zentralprozessoren. ...Eine gewisse Hilfestellung für Grundsatzentscheidungen, beispielsweise, ob man vorzuhaltende Rechenleistung (gemessen in MIPS), auf einen einzigen Rechner konzentrieren oder auf mehrere Rechner verteilen soll, bietet das Grosch’sche Gesetz. Während früher zwischen Verarbeitungsgeschwindigkeit und Kaufpreis ungefähr ein quadratischer Zusammenhang bestand, resultiert heute aus der Preispolitik der Hersteller annähernd eine lineare Abhängigkeit der Form v = a + bP (v = Anzahl MIPS, P = Kaufpreis) [Stah89, S. 33f.].Google Scholar
  159. 387.
    Vgl. [OrHa92, S. 6ff.].Google Scholar
  160. 388.
    Diese kann z.B. in MIPS (Million Instructions per Second) zu messen sein.Google Scholar
  161. 389.
    Dieses entspricht dem Peer-to-Peer-Konzept [OrHa92, S. 100].Google Scholar
  162. 390.
    Vgl. Abschnitt 2.5.Google Scholar
  163. 391.
    Vgl. z.B. [Kauf89),[DuGi90].Google Scholar
  164. 392.
    Auch hier ist eine Schichtenarchitektur anzutreffen. Die Ebenen sind:Google Scholar
  165. Die physikalische Ebene (Physical): Sie ist die logisch unterste Ebene. Sie definiert die Kommunikationsverbindung zwischen einem Rechner und dem Kommunikationssystem des Netzes. Sie betrifft Hardware-Einheiten, wie Kabel, Stecker, Transceiver, elektrische Aspekte der Frequenz- oder Amplitudenmodulation, sowie topologische Aspekte des Netzes.Google Scholar
  166. Die Datenverbindungsebene (Data Link): Diese Ebene setzt logisch auf der physikalischen Ebene auf. Sie definiert das Format zu übertragender Datenpakete, die Kollisionsbehandlung von Datenpaketen im Netz, sowie den Mechanismus des Sendens und Empfangens von Datenpaketen. Physikalische Ebene und Datenverbindungsebene bilden die Hardwareebene mit zugehörigen Hardwareprotokollen.Google Scholar
  167. Die Netzebene (Network): Diese Ebene setzt logisch auf der Datenverbindungsebene auf. Sie realisiert die Funktion des Routing, d.h. sie ist die Vermittlungszentrale einer Weitervermittlung von Datenpaketen von einem sendenden Rechner zu einem empfangenden Rechner gegebenenfalls über einige Zwischenknoten. In komplexen Netzen kann es mehrere Wege von einem Sender zu einem Empfänger geben. Routingprotokolle erkennen verfügbare bzw. nicht stark belastete Wege und leiten die Daten zu ihrem Empfänger.Google Scholar
  168. Die Transportebene (Transport): Diese Ebene setzt logisch auf der Netzebene auf. Sie definiert logische Ende-zu-Ende-Verbindungen zwischen Rechnern und kontrolliert den Verbindungsaufbau und den Verbindungsabbau. Diese Ebene abstrahiert von der Topologie des physischen Übertragungssystems. Weiterhin wird garantiert, daß einzelne Pakete nicht verlorengehen, nicht mehrfach beim Empfänger ankommen und daß die Reihenfolge der Pakete beim Empfang der des Absendens entspricht (Sequencing).Google Scholar
  169. Die Steuerungsebene (Session): Diese Ebene setzt logisch auf der Transportebene auf. Sie realisiert logische Ende-zu-Ende-Verbindungen zwischen Softwareprozessen beteiligter Rechner. Sie übersetzt weiterhin darunterliegende physische Namen und Adressen in in höheren Protokollschichten verwendete logische Namen und Adressen. Netzebene, Transportebene und Steuerungsebene werden insgesamt auch als Transportebene mit zugehörigen Transportprotokollen bezeichnet.Google Scholar
  170. Darstellungsebene (Presentation): Diese Ebene setzt logisch auf der Steuerungsebene auf. Sie legt die Konventionen einer Übersetzung von Übertragungsbefehlen höherer Programmiersprachen, welche einem Entwickler verteilter Anwendungen bereitzustellen sind, in Details der Transportebene fest.Google Scholar
  171. Die Anwendungsebene (Application): Diese Ebene setzt logisch auf der Darstellungsebene auf. Sie beinhaltet anwendungsunterstützende Dienste und Funktionen des Netzmanagements. Sie definiert Schnittstellen zwischen dem netzwerkfahigen Betriebssystem und Anwendungsprogrammen.Google Scholar
  172. 393.
    Gängige Standards für die Hardware-Ebene sind Ethernet, Token Ring, X.25, SDLC oder ARPANET. Gängige Standards für die Transportebene sind IPS/SPX, TCP/IP, UDP/IP, APPN/APPC oder NetBIOS. Verfügbare einfache Produkte auf Anwendungsebene und Präsentationsebene sind z.B. SMTP oder TELNET auf Basis der TCP/IP Protokollfamilie und X.400, FTAM oder ASN.1 gemäß dem OSI-Standard.Google Scholar
  173. 394.
    So können Rechner auf Basis von Ethernet vernetzt sein. Hierauf können alternativ oder gemeinsam z.B. die Transportprotokolle IPX/SPX, TCP/IP, NetBIOS oder APPN/APPC aufgesetzt werden.Google Scholar
  174. 395.
    So erfordert Token Ring eine Ringtopologie und Ethernet eine Bustopologie.Google Scholar
  175. 396.
    Inkompatibilität liegt z.B. vor, wenn zwei Teilnetze auf Basis unterschiedlicher Protokollstacks nicht oder nicht hinreichend stabil kommunizieren können. Koexistenz ist hingegen nicht gewährleistet, wenn unterschiedliche Protokolle nicht gleichzeitig auf einem Rechner betrieben werden können, und z.B. jeweils ein “booten” des Rechners mit einer veränderten Konfiguration erfordern. Auch muß hier die Netzwerkadapterkarte multiprotokollfahig sein.Google Scholar
  176. 397.
    D.h. Übertragungskapazität.Google Scholar
  177. 398.
    Vgl. [OrHa92],[Sinh92],[PeSc93].Google Scholar
  178. 399.
    Hierunter fallen verteilte Anwendungen [MüSc92], wie auch Anwendungen der verteilten künstlichen Intelligenz [BoGa88] oder verteilte Betriebssysteme [Mull91].Google Scholar
  179. 400.
    Er ist kein Rechner, wie oftmals fälschlicherweise gemeint wird.Google Scholar
  180. 401.
    Dient z.B. ein Rechner ausschließlich der Erbringung einer Server-Leistung, spricht man von einem dedizierten Server. Gegenwärtig sind Bestrebungen zu erkennen, dedizierte Server durch spezialisierte Hardware explizit zu unterstützen.Google Scholar
  181. 402.
    Datensichtgerät ohne eigene Rechenleistung.Google Scholar
  182. 405.
    Datenbank-Server sind typische Ressoucenverwalter.Google Scholar
  183. 404.
    Vgl. [OrHa92, S. 199ff.].Google Scholar
  184. 405.
    Andere Arten von informationstechnischen Diensten sind Print-Server-Dienste, Kommunikations-Server-Dienste, File-Server-Dienste oder Directory-Server-Dienste. Auch kann z.B. ein betriebswirtschaftlicher elektronischer Aufgabenträger “Bonitätsprüfung” als Server-Prozeß realisiert sein.Google Scholar
  185. 406.
    Je nach Funktionalität der System- und Kommunikationssoftware können Mainframes grundsätzlich natürlich auch Clients oder Server darstellen, da diese Fähigkeit nicht hardwarebedingt ist.Google Scholar
  186. 407.
    Voraussetzung ist eine asynchrone Verarbeitung, in der der Client nicht auf den Server wartet.Google Scholar
  187. 408.
    Eine unmittelbare logische Verbindung zwischen zwei Rechnern kann auch dann bestehen, wenn diese verkabelungsseitig nur mittelbar über andere Rechner vernetzt sind. Andererseits kann eine eventuelle Inkompatibilität der Kommunikationsprotokolle eine logische Verbindung zweier verkabelungsseitig vemetzter Rechner unmöglich machen.Google Scholar
  188. 409.
    Vgl. [Köni93a, S. 48].Google Scholar
  189. 410.
    Das dargestellte Szenario erscheint gemessen am Ist-Zustand vieler Unternehmungen visionär. Die gegenwärtig verfügbare Informationstechnologie eröffnet jedoch derartige Gestaltungen einer hohen informationstechnischen Durchdringung und einer hohen Automation durch den Einsatz elektronischer Aufgabenträger.Google Scholar
  190. 411.
    Z.B. Remote Named Pipes, Sockets. Vgl. [OrHa92, S. 373ff., S. 433ff.],[DeKo92, S. 197ff.].Google Scholar
  191. 412.
    Z.B. Remote Procedure Call (RPC). Vgl. [MuSc92, S. 71ff.].Google Scholar
  192. 413.
    Dieses Konzept ist z.B. im Distributed Computing Environment (DCE) der Open Software Foundation (OSF) realisiert [Schi93, S. 18ff.]. Hier bezieht sich das Directory-Server-Konzept primär auf Systemressourcen im Netz. Im o.g. Szenario sollte es auf betriebswirtschaftliche Server-Prozesse zu erweitern sein.Google Scholar
  193. 414.
    Konfigurationsverwaltung in verteilten Systemen [MüSc92, S. 181ff.]. Dieser aus der Sicht der Praxis sehr visionäre Ansatz geht über eine dezentrale Gestaltung der Datenbankarchitektur hinaus und wird den Einsatz verteilter Betriebssysteme (ein Betriebssystem über mehreren Rechnern) und verteilter Programmiersprachen erfordern.Google Scholar
  194. 415.
    Der Begriff IDBA wurde vom Autor der vorliegenden Arbeit geprägt. Der Begriff “individuell” wurde der sogenannten “individuellen Datenverarbeitung” i.d.R. auf Basis unvernetzter Personal Computer entlehnt. Der Begriff Architektur ist in diesem Zusammenhang in einem weit gefaßten Sinne zu verstehen.Google Scholar
  195. 416.
    Ein entferntes Binden einer Anwendung an eine Mainframe-Datenbank ist in der ZDBA nicht möglich, da die Systemsoftware klassischer Mainframes nicht auf das Client-Server-Konzept ausgelegt ist.Google Scholar
  196. 417.
    Formen des Copy- und Extrakt-Managements [Rohr87l, in denen in regelmäßigen zeitlichen Abständen Datenbestände einer operativen Datenbank i.d.R. auf einem Mainframe auf PCs oder Workstations für Auswertungen repliziert werden, werden aufgrund ihrer Unterlegenheit gegenüber dezentralen Datenbankarchitekturen mit der Möglichkeit entfernter Online-Zugriffe in dieser Arbeit nicht weiter betrachtet.Google Scholar
  197. 418.
    Eine Thematisierung vernetzter Datenbankarchitekturen findet man auch bei [ChSt93].Google Scholar
  198. 419.
    Vgl. in kürzerer Fassung auch [Köni93a, S. 51ff.].Google Scholar
  199. 420.
    Dieses schließt nicht aus, daß mehrere lokale Softwareprozesse eine lokale Datenbank gleichzeitig gemeinsam nutzen können.Google Scholar
  200. 421.
    (De-) Zentralität ist ein klassisches Thema des Informationsmanagements. Eine allgemeine Analyse, die sich jedoch nicht auf die Gestaltung der Datenhaltung konzentriert, findet man in [King83]. Managers of computing have confronted decisions about centralizing or decentralizing computing ever since the computer proved to be more than just another piece of office equipment [King83, S. 319].. The dilemma for the organization, however, is that there are high costs from either careful control or no control [King83, S. 335]. ...the major options managers have in arranging for the three major aspects of computing: control, location, and function. Each is presented as a continuum between extreme centralization and decentralization strategies [King83, S. 338].Google Scholar
  201. 422.
    Aufgrund einer Reihe präventiver Maßnahmen tritt dieser Worst-Case-Fall in der Praxis zugegebenermaßen selten auf.Google Scholar
  202. 423.
    Vgl. [Hans92, 733ff.].Google Scholar
  203. 424.
    Vgl. z.B. die Standards CUA ’89 (Common User Access) für graphische und CUA ’91 für objektorientierte Benutzeroberflächen.Google Scholar
  204. 425.
    Vgl. z.B. it+ti, Nr. 2, 1993 mit Schwerpunktthema Multimedia/Hypermedia.Google Scholar
  205. 426.
    Eine Betreuung kann durch sogenannte Information Center erfolgen (vgl. [MoWi93]).Google Scholar
  206. 427.
    Dabei wird es im Falle heterogener Server-DBMS erforderlich sein, daß auf den Arbeitsplatzrechnem unterschiedliche und wechselseitig koexistente DBMS-spezifische Datenbank-Clients bereitzustellen sind. Es besteht hier normalerweise die Einschränkung, daß ein einzelner Anwendungsprozeß nicht in der Lage sein dürfte, sukzessive heterogene Server-Datenbanken zu binden. So besitzt i.d.R. jedes DBMS einen spezifischen Precompiler zur Vorab-Übersetzung von in die verwendete Prograrnmiersprache (z.B. C, Pascal oder COBOL) eingebetteter Statements einer Datenbanksprache. Da pro Compiliervorgang nur ein Precompiler verwendet werden kann, kann ein Programm-Modul nicht gleichzeitig Queries gegen unterschiedliche heterogene DBMS beinhalten. Zur Realisierung einer Anwendung, die auf Daten mehrerer heterogener Server-Datenbanken im Netzwerk zugreifen muß, ist eine differenzierte Softwarepro zeßarchitektur bestehend aus mehreren kommunizierenden Softwareprozessen zu entwerfen.Google Scholar
  207. 428.
    Vgl. Abschnitt 1.2.Google Scholar
  208. 429.
    Vgl. [BeGr92, S. 54].Google Scholar
  209. 430.
    Vgl. [BeGr92, S. 45]. Eine FMDBSA ist eine spezielle Form eines verteilten Datensystems. Eine Taxonomie in Literatur und Praxis anzutreffender verteilter Datensysteme findet man in Anlehnung an [BeGr92] in Abschnitt 2.7.1.Google Scholar
  210. 431.
    Vgl. z.B. [IBM90, S. 91.Google Scholar
  211. 432.
    Jeweils lokale Datenbanken sind hier und nachfolgend natürlich eingeschlossen.Google Scholar
  212. 433.
    Vgl. Abschnitt 2.1.3.Google Scholar
  213. 434.
    Vgl. [Papp91, S. 104ff.].Google Scholar
  214. 435.
    Dieses Protokoll verhindert Situationen, in denen eine Teiltransaktion scheitert und andere Teiltransaktionen ein Commit erhalten, d.h. zugehörige, nun global inkonsistente Änderungen dauerhaft in unterschiedlichen Datenbanken (auf unterschiedlichen Rechnern) gespeichert werden.Google Scholar
  215. 436.
    Neben der Unwirtschaftlichkeit einer Manipulation des DBMS-Codes ist dieses Vorhaben i.d.R. bereits technisch unmöglich, da ein DBMS seitens des Herstellers nicht als Quellcode, sondern als Binärcode ausgeliefert wird.Google Scholar
  216. 437.
    Vgl. Abschnitt 2.5.Google Scholar
  217. 438.
    So stellen objektorientierte, deduktive oder temporale Datenmodelle spezifische Anforderungen an eine Transaktionsverarbeitung.Google Scholar
  218. 439.
    Ein Steckenpferd von Informatikern sind verteilte Datenbanken, und viel Forscherund Entwicklerschweiß ist auf diesem Gebiet geflossen, auch verursacht durch DV-Verantwortliche, die von einem neuen DB-System verlangen, daß es verteilt arbeiten kann, und das Zwei-Phasen-Commit-Protokoll beherrscht, auch wenn sie diese Fähigkeit nie nutzen werden. Wozu denn auch? [Dene93, S. 297].Google Scholar
  219. 440.
    Manchmal geht es auch ohne Zweiphasen-Commit-Protokoll: Synchron oder nicht -das hängt von der Anforderung ab. ...Der klassische Fall verteilter Verarbeitung wird heute mit einer Technologie beschrieben, die ab Zwei-Phasen-Commit bekannt ist. Ich sage bewußt “beschrieben” und nicht “realisiert”. Denn zum einen ist diese Technologie noch keineswegs durchgängig in allen DBMS-Produkten verfügbar bzw. ist ihre Verfügbarkeit oft unnötigerweise mit anderen Betriebsystemkomponenten (beispielsweise mit einem bestimmten TP-Monitor) verknüpft. Zum anderen stellt ihr produktiver Einsatz wegen der mit diesem Konzept verbundenen Randbedingungen noch eine große Ausnahme dar [Enge92, S. 44].Google Scholar
  220. 441.
    Vgl. die Anforderungen aus Abschnitt 1.5.3.Google Scholar
  221. 442.
    Vgl. Abschnitt 1.5.3.Google Scholar
  222. 443.
    Vgl. Abschnitt 2.1.4.Google Scholar
  223. 444.
    Vgl. die Liste der potentiellen Träger von Datenbedarfen in Abschnitt 1.5.3.Google Scholar
  224. 445.
    Von Server-Datenbank-übergreifenden Zugriffsbereichen wird vorerst abgesehen.Google Scholar
  225. 446.
    u.U. durch die Einrichtung externer Schemata.Google Scholar
  226. 447.
    Dieser Fall wird bei einer bestehenden MDBSA der Normalfall sein.Google Scholar
  227. 448.
    So ist z.B. ein Join über zwei Relationen der zugrundeliegenden logischen Schemata nicht möglich, wenn die beiden Relationen ausschließlich in unterschiedlichen DVM des Trägers repräsentiert sind. Integrationskonflikte treten hier nur dann nicht auf, wenn ein DBM eines Trägers intern aus mehreren isolierten Integrations-(teil)bereichen besteht, und jeder Teilbereich unifassend durch eines der bereitgestellten bzw. bereitstellbaren DVM unterstützt werden kann.Google Scholar
  228. 449.
    Vgl. Abschnitt 2.1.3.Google Scholar
  229. 450.
    Wie z.B. referentielle Integrität. Vgl. Abschnitt 2.1.6.Google Scholar
  230. 451.
    Eine derartige Funktionalität wird derzeit für FDS-System in Form einer vom Autor betreuten Diplomarbeit implementiert.Google Scholar
  231. 452.
    View-Update-Problem, Schema-Integrationsproblem und Schema-Transformationsproblem, vgl. Abschnitt 2.2.Google Scholar
  232. 453.
    Leider hat sich im Bereich verteilter Datensysteme in der Literatur noch kein einheitlicher terminologischer Standard durchgesetzt, was beim Studium von Originalliteratur zu Verwirrung führen kann.Google Scholar
  233. 454.
    Vgl. Abschnitt 2.6.1.Google Scholar
  234. 455.
    Vgl. Abschnitt 2.7.3.Google Scholar
  235. 456.
    Vgl. Abschnitt 2.1.2.Google Scholar
  236. 457.
    Wie in Abschnitt 2.7.3. dargestellt, eignet sich das relationale Datenmodell aufgrund seiner deklarativen Sprachen in besonderer Weise als Datenbankdatenmodell für verteilte DBMS.Google Scholar
  237. 458.
    Verteilte DBMS können auch heterogene verteilte Datensysteme mit voller DBMS-Funktiotialität (Full DBMS Functionality, vgl. Abb. 14) sein. Dieser technisch sehr aufwendige Ansatz ist derzeit jedoch von untergeordneter Praxisrelevanz, da keine derartigen heterogenen Produkte mit Single-System-Image verfügbar sind.Google Scholar
  238. 459.
    Vgl. Abschnitt 2.1.5.Google Scholar
  239. 460.
    Integration fully within the system [BeGr92, S. 48].Google Scholar
  240. 461.
    Diese Variante zielt auf eine umfassende Integration heterogener DBMS im Hinblick auf die Bereitstellung eines verteilten DBMS. Dieses erfordert jedoch i.d.R. ein abgestimmtes Neudesign aller heterogenen Teil-DBMS auf unterschiedlichen Rechnern (Top-Down-Ansatz). Eine Integration bestehender heterogener DBMS unterschiedlicher Hersteller, die in ihrem Design nicht für eine Partizipation in einem verteilten Datensystem ausgelegt sind, führt i.d.R. maximal zu einem verteilten Datensystem mit partieller DBMS-Funktionalität. Zu beobachtende Forschungsanstrengungen, wie z.B. der Entwurf globaler Transaktionskonzepte für heterogene Multidatenbanksysteme, verdeutlichen die Zielsetzung der Informatik, ein höchstmögliches Maß an Integration bereitzustellen.Google Scholar
  241. 462.
    Vgl. [LiAb87l.Google Scholar
  242. 463.
    Die Literatur zur Informatik läßt jedoch erkennen, daß auch hier wiederum eine möglichst hohe systemseitige Integration in Gestalt verteilter Transaktionskonzepte im Vordergrund steht. So werden z.B. in [ScWe91] globale Transaktionen der Föderation und lokale Transaktionen einzelner Komponentendatenbanken unterschieden. Es stellt sich die Frage nach dem warum. Wenn eine Unternehmung ein derartig hohes Maß an Integration unbedingt will, kann sie gleich auf verteilte Datenbanken setzen, denn sowohl verteilte Datenbanken, als auch derartig hochintegrierte Datenbankföderationen, erfordern letztlich einen weitgehenden Austausch der bestehenden Datenbankarchitektur. Es stellt sich bei dem hier zu erwartenden Overhead (vgl. Abschnitt 2.7.3) sogar die Frage, ob nicht die klassische, zentralistische Datenbankarchitektur die wirtschaftlichere Lösung darstellt.Google Scholar
  243. 464.
    Vgl. [ShLa90].Google Scholar
  244. 465.
    Vgl. Abschnitt 2.2.3, Datenmodell-Transformationsproblem.Google Scholar
  245. 466.
    Vgl. Abschnitt 2.2.2, Datenbank-Integrationsproblem.Google Scholar
  246. 467.
    Vgl. [LaRo82].Google Scholar
  247. 468.
    Vgl. [TeBr87].Google Scholar
  248. 469.
    Vgl. [LiBo82].Google Scholar
  249. 470.
    Vgl. [SpDe82].Google Scholar
  250. 471.
    Vgl. [BrOl86].Google Scholar
  251. 472.
    Vgl. [JaPi88].Google Scholar
  252. 473.
    Eine entsprechende Übersicht ist in [ShLa90] zu finden.Google Scholar
  253. 474.
    Vgl. [Date90]. Die Regeln sind hier sinngemäß wiedergegeben.Google Scholar
  254. 475.
    Die Anforderungen sind relational geprägt. Im Gegensatz zu klassischen DBMS-Paradigmen (hierarchisch, netzwerkorientiert) bieten sich auch objektorientierte DBMS für verteilte Datenbankarchitekturen an. Vgl. hierzu auch [Fran92, S. 48f.].Google Scholar
  255. 476.
    Ein verteiltes System ist eines, das dich am Arbeiten hindert, weil ein Rechnerknoten, von dem du noch nie was gehört hast, ausgefallen ist. (Leslie Lamport) in: [Reut92, S.12].Google Scholar
  256. 477.
    Vgl. [Aper88].Google Scholar
  257. 478.
    Vgl. Abschnitt 2.1.7.Google Scholar
  258. 479.
    Vgl. Abschnitt 2.6.1.Google Scholar
  259. 480.
    Vgl. Abschnitt 2.1.3.Google Scholar
  260. 481.
    Vgl. die Diskussion in Abschnitt 2.6.1.Google Scholar
  261. 482.
    Vgl. Abschnitt 2.3.Google Scholar
  262. 483.
    Vgl. Abschnitt 2.3.Google Scholar
  263. 484.
    Man muß sich aber darüber im klaren sein, daß alle (Hersteller, d.V.) noch relativ weit von völliger Verteilungstransparenz entfernt sind[Reut92, S. 13].Google Scholar
  264. 485.
    Vgl. die Abschnitte 1.5.2 und 2.5.Google Scholar
  265. 486.
    Die Datenleitung als Flaschenhals: Die Übertragungsgeschwindigkeit der Daten über die Verbindungsleitung zwischen den Rechnern beeinßußt in starkem Maße das Zeitverhalten von verteilten Datenbanksystemen. Der Transfer über Leitungen dauert im allgemeinen um ein Vielfaches länger und verursacht zudem höhere Kosten als die Abarbeitung eines Auftrags in einer Datenbank. Dieses Problem ist neben den funktionalen Einschränkungen vieler verteilter Datenbanksysteme der zweite Faktor, der die Einsatzmöglichkeiten und die größere Verbreitung von verteilten Datenbanksystemen behindert [Ott92, S. 391].Google Scholar
  266. 487.
    Vgl. Abschnitt 1.5.2.Google Scholar
  267. 488.
    Verteilte Datenbanken zwischen Wunschtraum und Wirklichkeit [Jenz92].Google Scholar
  268. 489.
    Vgl. [Buhl92],[BuKö92b],[BuWi93]. Vgl. auch Abschnitt 4.4.Google Scholar
  269. 490.
    “FDS” steht für Fachdomänenschema. Diese Bezeichnung für ein virtuelles Schema einer FMDBSA entstammt dem Anwendungskontext von ALLFIWIB. Fachdomänenschemata dienen dort der integrierten Informationsversorgung von finanzwirtschaftlichen Fachagenten einzelner finanzwirtschaftlicher Fachdomänen, wie z.B. Leasing oder Lebensversicherung.Google Scholar
  270. 491.
    Vgl. Abschnitt 2.6.1.Google Scholar
  271. 492.
    In Abgrenzung zu Abschnitt 2.7.2 wird hier anstatt von Föderationsschemata einheitlich von virtuellen Schemata einer FMDBSA gesprochen.Google Scholar
  272. 493.
    Server-Datenbank-übergreifende Fragmentierung von Relationen im Sinne von Abschnitt 2.7.3 ist in einer MDBSA kein Thema, da nur völlig autonome Server-DBMS vorliegen.Google Scholar
  273. 494.
    Der unterstützte Sprachumfang ist [KöKu93b, S. 114ff.] zu entnehmen.Google Scholar
  274. 495.
    Die Datenbank-Server sind nicht dediziert.Google Scholar
  275. 496.
    Vgl. [OrHa92, S. 157ff.],[ChSt93, S. 201ff.].Google Scholar
  276. 497.
    So können durch virtuelle Schemata relationale Datenbanken unter DB2 auf MVS, SQI/400 auf AS/400, DB2/6000 auf RS/6000 und Database Manager auf OS/2 integriert werden. Auch ist grundsätzlich jede Plattform integrierbar, die eine DRDA-Schnittstelle besitzt.Google Scholar
  277. 498.
    Eine ausführliche Dokumentation von FDS-System findet man bei [KöKu93b].Google Scholar
  278. 499.
    Hierbei ist anzumerken, daß für FDS-System die jeweilige Meta-Datenbank lokal auf jedem Datenbank-Client unter dem einheitlichen Namen FDS_DD (FDS Data Dictionary) katalogisiert sein muß.Google Scholar
  279. 500.
    FDS-System liegt derzeit sowohl als Dynamic Link Library (DLL), wie auch als interaktive Version mit graphischer Benutzerschnittstelle auf Basis von Presentation Manager vor.Google Scholar
  280. 501.
    Diese Datenstrukturen sind in [KöKu93b] detailliert dargestellt und erläutert.Google Scholar
  281. 502.
    Schlüsselworte, Bezeichner, Operatoren, etc.Google Scholar
  282. 503.
    Eine derartige Eigenschaft würde eine Philosophie implizieren, gemäß welcher die logischen Schemata der Server-Datenbanken Fragmente der (eigendichen) virtuellen Relationen des virtuellen Schemas enthalten. Im Gegensatz zu verteilten Datenbanken mit globalem Schema ist eine derartige Fragmentierung hier jedoch wenig sinnvoll, da das Hauptaugenmerk des Schema-Designs in einer durch FDS-System integrierten MDBSA auf der Gestaltung der logischen Schemata der Server-Datenbanken der MDBSA zu liegen hat. Diese sind als stabiler Bezugspunkt aufzufassen und nicht die virtuellen Schemata.Google Scholar
  283. 504.
    Vgl. Abschnitt 2.2.1.Google Scholar
  284. 505.
    Siehe View-Update-Problem (Abschnitt 2.2.1).Google Scholar
  285. 506.
    Kartesische Produkte von Relationen sind praktisch wenig relevant sowie ressourcenintensiv. Sie werden aus diesem Grund aktuell von FDSSystem nicht unterstützt und mit einer Fehlermeldung zurückgewiesen.Google Scholar
  286. 507.
    Vgl. [KöKu93a].Google Scholar
  287. 508.
    Performance ist generell ein Problem in verteilten Datensystemen. 509 Die anderen Komponenten von FDS-System sind ausführlich in [KöKu93b] beschrieben.Google Scholar
  288. 510.
    Siehe Abschnitt 2.1.7.Google Scholar
  289. 511.
    Vgl. [Pear84].Google Scholar
  290. 512.
    Die Gestalt des ICDS-Graphen hängt dabei nicht nur von der vorliegenden virtuellen SQL-Query, sondern insbesondere auch von der Allokation der Daten über die Server-Datenbanken der MDBSA ab.Google Scholar
  291. 513.
    Standardmäßig ist FDS-System mit p = 0,5 (Quadratwurzel) konfiguriert. Der Wert ist in FDS-System veränderbar. Je nach Anwendungsgebiet liegen individuelle Attribut-wertverteilungen vor. Der “optimale” Parameter ist anwendungsspezifisch durch explorative Analyse einzugrenzen.Google Scholar
  292. 514.
    Im schlimmsten Fall stößt man in Falle einer ungeschickten Vorgehensweise an die Grenzen der verfügbaren informationstechnischen Ressourcen (z.B. Hauptspeicher), obwohl die letztlich zu generierende Ergebnisrelation relativ klein sein kann.Google Scholar
  293. 515.
    Ein VTab (virtuelle Relation) des virtuellen Schemas korrespondiert mit Tab eines logischen Schemas der MDBSA. Dieses gilt analog für das Verhältnis von VAtt zu Att. Tabl (Tab2, Tab3) residiert hier in Server-Datenbank DB1 (DB2, DB3).Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 1994

Authors and Affiliations

  • Hans-Jürgen König

There are no affiliations available

Personalised recommendations