148
Ein Beitrag zum Entwurf industrieller Datenbanksysteme Von der Fakultät für Maschinenbau, Verfahrens- und Energietechnik der Technischen Universität Bergakademie Freiberg genehmigte DISSERTATION zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) vorgelegt von: Dipl.-Ing. Mike Rössel geboren am: 3. April 1968 in Karl-Marx-Stadt Gutachter: Prof. Dr.-Ing. habil. Peter Löber (Freiberg) Prof. Dr.-Ing. habil. Joachim Lippold, (Oelsnitz) Prof. Dr.-Ing. habil. Karl Hess, (Chemnitz) Tag der Verleihung: 10.10.2003

Ein Beitrag zum Entwurf industrieller Datenbanksysteme

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Von der Fakultät für Maschinenbau, Verfahrens- und Energietechnik

der Technischen Universität Bergakademie Freiberg

genehmigte

DISSERTATION

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

(Dr.-Ing.)

vorgelegt von: Dipl.-Ing. Mike Rössel geboren am: 3. April 1968 in Karl-Marx-Stadt Gutachter: Prof. Dr.-Ing. habil. Peter Löber (Freiberg) Prof. Dr.-Ing. habil. Joachim Lippold, (Oelsnitz) Prof. Dr.-Ing. habil. Karl Hess, (Chemnitz) Tag der Verleihung: 10.10.2003

Page 2: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Inhaltsverzeichnis Seite II

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Danksagung Die vorliegende Dissertation entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Institut für Automatisierungstechnik an der Technischen Universität Bergaka-demie Freiberg und in unzähligen Stunden meiner Freizeit. Mein besonderer Dank gilt an dieser Stelle dem Gutachter Herr Prof. Dr.-Ing. habil. Karl Hess für das dieser Arbeit entgegengebrachte Interesse. Herrn Prof. Dr.-Ing. habil. Peter Löber und Herrn Prof. Dr.-Ing. habil. Joachim Lippold danke ich für die wertvollen Hinweise während der Arbeit sowie die Erstellung der Gutachten. Mein Dank richtet sich auch an Herrn Dr.-Ing. Rolf Fischer für die langjährige Zusammenar-beit und die konstruktiven und hilfreichen Beratungen und fachlichen Diskussionen. Nicht zuletzt richtet sich mein Dank an alle, welche mich bei der schriftlichen Erstellung der Dissertation unterstützt haben. Insbesondere möchte ich hier Frau Eva Espig, Frau Daniela Grau und Frau Elke Rössel erwähnen. Lichtenau, im Oktober 2003 Mike Rössel

Page 3: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Inhaltsverzeichnis Seite I

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

I Inhaltsverzeichnis

I Inhaltsverzeichnis.................................................................................................I

II Verzeichnis der verwendeten Abkürzungen.................................................... IV

III Verzeichnis der Formelzeichen und Symbole................................................ VII

IV Verzeichnis der Abbildungen............................................................................. X

V Verzeichnis der Tabellen................................................................................... XI

VI Weitere Hinweise zur Gestaltung der Arbeit .................................................. XII

1 Einleitung..............................................................................................................1 1.1 Vorwort..............................................................................................................1 1.2 Einführung.........................................................................................................1 1.3 Ziele und Aufgabenstellung ..............................................................................3 1.4 Abgrenzung.......................................................................................................4 1.5 Inhalt der Dissertationsschrift............................................................................4

2 Wissensstand.......................................................................................................5 2.1 Datenbanken.....................................................................................................5 2.1.1 Anforderungen an ein DBS ...............................................................................5 2.1.2 Vorteile von Datenbanken gegenüber konventionellen Dateisystemen............6 2.1.3 Betrachtungsweisen..........................................................................................7 2.1.4 Komponenten eines DBMS...............................................................................8 2.2 Data Dictionary System ....................................................................................9 2.3 Prozess-Manager............................................................................................11 2.4 File-Manager...................................................................................................12 2.5 Puffer-Manager ...............................................................................................14 2.6 Datensatz-Manager ........................................................................................15 2.7 Transaktions-Manager ....................................................................................15 2.7.1 Transaktionen .................................................................................................15 2.7.1.1 Serielle Transaktionen ....................................................................................17 2.7.1.2 Parallele Transaktionen ..................................................................................18 2.7.2 Interferenz zwischen konkurrierenden Transaktionen ....................................18 2.7.3 Konkurrenzsteuerung (Concurrency control techniques) .......................................18 2.7.3.1 Sperr-Methoden (Locking methods) ...................................................................19 2.7.3.1.1 Verklemmungen (Dead-Lock)............................................................................20 2.7.3.2 Zeitstempel-Methoden (Timestamp methods) .....................................................20 2.7.3.3 Optimistische Methoden (Optimistic methods)....................................................21 2.8 Recovery-Manager .........................................................................................21 2.8.1 Fehlermöglichkeiten........................................................................................22 2.8.2 LOG ................................................................................................................24 2.8.3 Checkpunkte ...................................................................................................25 2.8.4 Lokale Recovery-Protokolle ............................................................................27 2.8.4.1 Undo/redo - Funktionalität...............................................................................28 2.8.4.2 Undo/no-redo - Funktionalität .........................................................................28

Page 4: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Inhaltsverzeichnis Seite II

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.8.4.3 No-undo/redo - Funktionalität .........................................................................29 2.8.4.4 No-undo/no-redo - Funktionalität ....................................................................30 2.9 Zugriffsmethoden auf Daten ...........................................................................31 2.9.1 Sequentielle Zugriffsmethoden .......................................................................32 2.9.2 Einstufige Indexdatei.......................................................................................34 2.9.3 Inverse Datei ...................................................................................................35 2.9.4 Multilistendateiorganisation.............................................................................35 2.9.5 Hash................................................................................................................35 2.9.6 ISAM ...............................................................................................................36 2.9.7 B-Baum ...........................................................................................................37 2.9.8 B+-Baum..........................................................................................................41 2.9.9 Zusammenfassung .........................................................................................42

3 Lösungskonzepte ..............................................................................................43 3.1 Wahl des Betriebssystems..............................................................................43 3.2 Fileorganisation des DBS ...............................................................................44 3.3 Redundanz......................................................................................................45 3.3.1 Zeiger und Schlüssel ......................................................................................45 3.4 Trigger.............................................................................................................48 3.5 Problem der eindeutigen Zeiten......................................................................48 3.5.1 Algorithmus von Cristian .................................................................................49 3.5.2 Berkeley-Algorithmus......................................................................................49 3.6 Realzeitbetrachtungen ....................................................................................49 3.6.1 Realzeit in DBS...............................................................................................52 3.6.1.1 Netzwerk .........................................................................................................54 3.6.1.1.1 RS232C ..........................................................................................................55 3.6.1.1.2 CAN ................................................................................................................56 3.6.1.1.3 TCP-IP/UDP-IP ...............................................................................................59 3.6.1.1.4 Zusammenfassung .........................................................................................59 3.6.1.2 DBS.................................................................................................................60 3.6.1.2.1 Initialisierungszeit............................................................................................61 3.6.1.2.2 Deinitialisierungszeit .......................................................................................64 3.6.1.2.3 Prozessbearbeitungszeit.................................................................................65 3.6.1.2.4 Zusammenfassung .........................................................................................70

4 Implementierungskonzept ................................................................................74 4.1 Festlegungen ..................................................................................................74 4.2 Generelle Betrachtungen ................................................................................75 4.3 RZ-DBMS – „MRDB“.......................................................................................76 4.3.1 DDS ................................................................................................................77 4.3.1.1 Stufe 1: DDS für Verwaltung der DB...............................................................78 4.3.1.2 Stufe 2: Integration von Triggern ....................................................................80 4.3.1.3 Stufe 3: Integration einer Programmverwaltung..............................................80 4.3.1.4 Stufe 4: Integration von Views ........................................................................80 4.3.1.4.1 Stufe 5: Realzeit..............................................................................................81 4.3.1.5 Stufe 6: Weitere Ergänzungen........................................................................81 4.3.2 Prozess-Manager............................................................................................82

Page 5: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Inhaltsverzeichnis Seite III

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.3.3 File-Manager...................................................................................................83 4.3.4 Puffer-Manager ...............................................................................................85 4.3.5 Datensatz-Manager ........................................................................................88 4.3.6 Transaktions-Manager ....................................................................................91 4.3.7 Zugriffsverfahren.............................................................................................91 4.3.8 Realzeit-Manager............................................................................................94 4.3.9 Kommunikations-Manager ..............................................................................94 4.3.10 Gesamtstruktur der Datenbank-Engine ..........................................................95 4.4 Technische Daten des „MRDB“-Systems ......................................................96

5 Prototyperprobung in einem Industrieunternehmen......................................97 5.1 Server .............................................................................................................97 5.1.1 Hardware ........................................................................................................97 5.1.2 Software..........................................................................................................99 5.1.3 Fehlerdiagnose und Fehlerbehebung .............................................................99 5.2 Clients ...........................................................................................................100 5.2.1 Hardware ......................................................................................................100 5.2.2 Software........................................................................................................100

6 Experimentelle Ergebnisse und Zusammenfassung....................................101 6.1 Dauerbetriebsfähigkeit ..................................................................................101 6.2 Realzeitfähigkeit............................................................................................101 6.3 Portabilitätsproblematik.................................................................................101 6.4 Bedienung.....................................................................................................103 6.5 Zusammenfassung und Ausblick ..................................................................103

VII Literaturverzeichnis.............................................................................................1

VIII Quellenauszug ...................................................................................................20

Page 6: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der verwendeten Abkürzungen Seite IV

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

II Verzeichnis der verwendeten Abkürzungen1

2PC Zwei-Phasen-Commit (two phase commit) - ein Recoveryprotokoll

2PL Zwei-Phasen-Sperre (two phase locking) - eine Konkurrenzsteuerungsme-thode

3PC Drei-Phasen-Commit (three phase commit) - ein Recoveryprotokoll

3PL Drei-Phasen-Sperre (three phase locking) - eine Konkurrenzsteuerungs-methode

ANSI American National Standards Institute

API Application Programming Interface

ASCII American Standard Code for Information Interchange

AT Automatisierungstechnik

ATS Automatisierungssystem

BAF Bergakademie Freiberg

Baudrate Bezeichnung für die Geschwindigkeit, mit der serielle Daten übertragen werden

BDE Betriebsdatenerfassung

CAD Computergestützter Entwurf (computer aided design)

CAN Bussystem (controller area network)

CPU Central Processing Unit

CRC Cyclic Redundancy Check

CSMA Carrier Sense Multible Access (Multi-Master Bus-Zugriffsverfahren)

CSMA/CA CSMA / Collision Avoidance

CSMA/CD CSMA / Collision Detection

DAS Data Striping without Parity (RAID-0)

DB Datenbank (database)

DBMS Datenbank-Management-System (database management system)

DBS Datenbanksystem (database system)

DCL Data Control Language

DD Data Dictionary

DDBMS verteiltes DBMS (distributed database management system)

DDL Datendefinitionssprache (Data Definition Language)

DDMS Data Dictionary Management System

DDS Data Dictionary System

1 Die Begriffe sind alphabetisch sortiert, Abkürzungen, welche in Formeln verwendet werden, sind im

Verzeichnis der Formelzeichen und Symbole aufgelistet.

Page 7: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der verwendeten Abkürzungen Seite V

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

DIN Deutsches Institut für Normung

DLL Dynamic Link Library

DM Datensatz-Manger

DML Datenmanipulationssprache (Data Manipulation Language)

DSDL Data Storage Definition Language

EDO-RAM extended data output - RAM

FAQ Frequently Asked Questions

FBS Feldbussystem

FIFO Speicherzugriffsprinzip (First In - First Out)

FIPS Federal Information Processing Standards Publication

FIPS PUBS Federal Information Processing Standards Publications

FM File-Manager

FPM-RAM Fast Page Mode – RAM

FSF Free Software Foundation

GMT Greenwich Meridian Time

GNU freie Software, Unix-artiges Betriebssystem (siehe auch FSF)

ID Identifikator

IDA Independent Disk Array (RAID-4, RAID-5)

IEEE The Institute of Electrical and Electronics Engineers, Inc.

IfAT Institut für Automatisierungstechnik, TU BAF

IP Internet Protokoll

IPC Interprocess Communication

ISAM Index Sequential Access Method

ISO International Standards Organisation

LALR-Parser Look-Ahead, Left-to-right scanning of the input, Rightmost derivation

LDP Linux Documentation Project

LFU least frequently used

LM Lock-Manager

LRU least recently used

LSN Unique Log Sequence Number

MDA Mirrored Disk Array (RAID-1)

MDE Maschinendatenerfassung

MZV Medienzugangsverfahren bzw. Medienzugriffsverfahren

OLTP Online Transaction Processing

OODBS objektorientiertes Datenbanksystem

Page 8: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der verwendeten Abkürzungen Seite VI

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

PCI Personal Computer Interface

PDA Parallel Disk Array (RAID-3)

PFN Page Frame Number

PM Puffer-Manager

PPS Produktionsplanung und -steuerung

PZE Personalzeiterfassung

QDE Qualitätsdatenerfassung

RAID Redundant Array of Independent (Inexpensive) Disk Drives

RAM Random Acess Memory

RDBMS relationales Datenbankmanagementsystem

RFC Requests for Comments

RM Recovery-Manager

RPC Remote Procedure Call

RS232 Kommunikationsschnittstelle

RZ-DB Realzeitfähige DB

RZ-DBMS Realzeitfähiges DBMS

RZ-DBS Realzeitfähiges DBS

SCSI Small Computer System Interface

SDRAM synchrones DRAM

SMP Symmetrisches Multiprozessor-System

SPARC Standards Planning And Requirements Comittee

SPX Kommunikationsprotokoll

SQL Structured Query Language

TCP Transmission Control Protokoll

TLI Transport Layer Interface

TM Transaktions-Manager

TNR Transaktionsnummer

TU BAF Technische Universität Bergakademie Freiberg

UDP User Datagram Protokoll

USV Unterbrechungsfreie Stromversorgung

UTC Coordinated Universal Time (Internationaler Zeitstandard) entspricht GMT (0 Uhr entspricht Mitternacht in Greenwich, England). UTC basiert auf einer 24-Stunden-Uhr

VDL Viewdefinitionssprache

YACC Yet Another Compiler-Compiler

Page 9: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der Formelzeichen und Symbole Seite VII

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

III Verzeichnis der Formelzeichen und Symbole

Symbole

{ }... Menge

[ ]... Folge

DIV DIV (ganzzahlige Division) Allgemein AI After Image B Randbedingungen, Betriebsbedingungen BF Blockungsfaktor BI Before Image CUTC Zeit im UTC-Format CP Checkpunkt D Datenobjekt DB Datenbank DS Datensatz DT Datentyp h Tiefe (Höhe) eines Baumes HD Anzahl Festplattenzugriffe HDL Anzahl Festplattenzugriffe lesend HDS Anzahl Festplattenzugriffe schreibend K Anzahl der Knoten (Blätter) Key Datentyp für Schlüssel L Lesen LOG Logbuch M Ordnung eines Baumes m Framegröße in Bit, Anzahl Elemente im Node n Anzahl nBT Anzahl Bits nDS Anzahl der Datensätze nKF zu sendende Datenmenge nKW zu empfangende Datenmenge Op Operation (Schreib- oder Leseoperation) P Wahrscheinlichkeit Ptr Zeiger S Schreiben, Schedule s Schlüssel

Page 10: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der Formelzeichen und Symbole Seite VIII

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Allgemein SDS Stammdatensatz sof() Funktion zur Ermittlung der Größe eines Items (sizeof) t Zeitpunkt oder Zeitspanne tCP Zeitpunkt des letzten CP tF Zeitpunkt des Fehlerauftrittes tT Zeitpunkt der Transaktion T Transaktion x Größe eines Schlüssels y Anzahl der Schlüssel λ Ankunftsrate µ Bedienrate

Realzeit BF Benchmark-Faktor der CPU gegenüber einem Norm-Wert SI Größe eines Puffereintrages SRB Größe des BI Puffers t1 Zeitpunkt, an dem ein bestimmtes Ereignis stattfindet tA Antwortzeit tAI Zeit zu Bearbeiten des AI-Files tAT Zeit zum Abbrechen von Transaktionen tB Bearbeitungszeit tBI Zeit zum Bearbeiten des BI-Files tBT Zeit zum Start einer neuen Transaktion tCPU Rechenzeit der CPU tD Deinitialisierungszeit tDauer Ausführungszeit der Aufgabe tDBS Zeit, die das DBS für die Bearbeitung einer Aufgabe benötigt tDS Zugriffszeit auf einen Datensatz tHD Festplattenzugriffszeit tI Initialisierungszeit (Zeit, um DB in konsistenten Zustand zu bringen) tIND Zugriffszeit für Suchoperation im Index tKF Kommunikationszeit für Anfrage tKW Kommunikationszeit für Antwort tL Latenzzeit tLOG Zeit zum Bearbeiten des LOG-Files tMI Zeit zum Bearbeiten des MI-Files tP Prozesszeit

Page 11: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der Formelzeichen und Symbole Seite IX

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Realzeit tR Reaktionszeit tRB Zeit für undo der aktiven Transaktionen tRP Reaktionszeit des Prozesssystems tS Stellzeit tv Verwaltungszeit twbBI Zeit zum Rückschreiben in das BI-File tZ zulässige Antwortzeit

Page 12: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der Abbildungen Seite X

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

IV Verzeichnis der Abbildungen

Bild 2.1: ANSI-X3-SPARC 3-Ebenen-Architekturvorschlag........................................7 Bild 2.2: Klassifikation von DDS nach /GaRö94/ .......................................................10 Bild 2.3: Serielle Transaktionsausführung ................................................................17 Bild 2.4: Parallele Transaktionsausführung ..............................................................18 Bild 2.5: Einfluss der Sperrgranulatgröße /Ku92/ .....................................................19 Bild 2.6: synchroner Checkpunkt ..............................................................................26 Bild 2.7: asynchroner Checkpunkt ............................................................................26 Bild 3.1: Einteilung von Realzeitbedingungen ..........................................................50 Bild 3.2: Prozessaktivitäten.......................................................................................51 Bild 3.3: Rechneraktivitäten ......................................................................................51 Bild 3.4: CAN-2.0A-Frame ........................................................................................57 Bild 4.1: Struktur des minimalen DDS ......................................................................79 Bild 4.2: Objektstruktur File-Manager .......................................................................83 Bild 4.3: Objektstruktur Puffermanager.....................................................................85 Bild 4.4: Zugriff auf einen Datensatz.........................................................................86 Bild 4.5: Algorithmus für 2-Phasen-Commit..............................................................90 Bild 4.6: Objektstruktur des abstrakten Indizes ........................................................92 Bild 4.7: Objektstruktur des abstrakten Indexiterators ..............................................92 Bild 4.8: Objektstruktur der Engine ...........................................................................95

Page 13: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Verzeichnis der Tabellen Seite XI

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

V Verzeichnis der Tabellen

Tabelle 2.1: Komponenten eines DBMS ..........................................................................9 Tabelle 2.2: Grundlegende Eigenschaften von Transaktionen.......................................16 Tabelle 2.3: Zugriff über Heap........................................................................................34 Tabelle 2.4: Zugriff über einstufige Indexdatei ...............................................................34 Tabelle 2.5: Zugriff über inverse Datei ...........................................................................35 Tabelle 2.6: Zugriff mittels Multilistendateiorganisation..................................................35 Tabelle 2.7: Zugriff über Hash-Verfahren .......................................................................36 Tabelle 2.8: Zugriff über ISAM........................................................................................37 Tabelle 2.9: Zugriff mit B-Baum-Verfahren.....................................................................39 Tabelle 2.10: Zugriff mit B+-Baum-Verfahren....................................................................42 Tabelle 3.1: Betrachtungen zu Zeit- und Speicherbedarf ...............................................48 Tabelle 3.2: Gegenüberstellung der Funktionen bei commit und abort..........................65 Tabelle 3.3: Voraussetzungen zur Erfüllung von Realzeit-Forderungen ........................72 Tabelle 3.4: Anforderungen an Realzeit-Manager..........................................................72 Tabelle 3.5: Parameter, welche der Sprachcompiler ermitteln muss .............................73 Tabelle 3.6: dynamische Steuerungsmöglichkeiten für den Realzeit-Manager..............73 Tabelle 4.1: Stufe 1 des DD-Entwurfs ............................................................................79 Tabelle 4.2: Stufe 2 des DD-Entwurfs ............................................................................80 Tabelle 4.3: Stufe 3 des DD-Entwurfs ............................................................................80 Tabelle 4.4: Stufe 4 des DD-Entwurfs ............................................................................81 Tabelle 4.5: Stufe 5 des DD-Entwurfs ............................................................................81 Tabelle 4.6: Stufe 6 des DD-Entwurfs ............................................................................81 Tabelle 4.7: Aufbau LOG für „MRDB“.............................................................................84 Tabelle 4.8: Zugriffsverfahren.........................................................................................93 Tabelle 4.9: Technische Daten.......................................................................................96 Tabelle 5.1: Festplattenaufteilung ..................................................................................99 Tabelle 5.2: Fehlerbehandlung.....................................................................................100

Page 14: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Weitere Hinweise zur Gestaltung der Arbeit Seite XII

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

VI Weitere Hinweise zur Gestaltung der Arbeit

Um die Arbeit übersichtlich zu gestalten, werden die folgenden Hervorhebungen und Markie-rungen verwendet: S 1: Schlussfolgerungen (Ergebnisse) der Arbeit

F 1: Festlegungen für die vorliegende Arbeit2

+ Darstellung einer vorteilhaften Eigenschaft

­ Darstellung einer nachteiligen Eigenschaft • o

Darstellung von Listen in verschiedenen Ebenen3

Englisch Darstellung englischer Begriffe4

[xxx] Hochgestellte Angaben in Klammern charakterisieren die Formelzeichen genauer

z.B.: Formelzeichen t für Zeit [ ]Bitt für die (Übertragungs-)Zeit eines Bits.

x durchschnittlicher Wert

minx minimaler Wert

maxx maximaler Wert

x normierter Wert

2 Dies sind keine Definitionen im mathematischen Sinne, sondern Richtlinien für den weiteren Verlauf der

Arbeit. 3 Listen werden nicht durch Nummern gegliedert, da dies automatisch eine Reihenfolge vorgibt. Da

Reihenfolgen nicht immer darstellbar sind, wird auf eine Nummerierung verzichtet. 4 Es wird (soweit üblich und möglich) versucht, deutsche Begriffe zu verwenden.

Page 15: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Einleitung Seite 1

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

1 Einleitung

1.1 Vorwort

In den Jahren 1992-1995 führte ich Untersuchungen zu Lernalgorithmen auf dem Gebiet der ‚Künstlichen Intelligenz’ durch. Ziel war eine Dissertation in diesem Fachgebiet. Die For-schungen führten schnell zur Notwendigkeit der Verwendung eines Datenbanksystems zum Sammeln der umfangreichen Informationen. Die finanziellen Beschränkungen sowie die zwingende Tätigkeit an einem Industrieprojekt führten ab 1996 dazu, das Forschungsgebiet zu wechseln. So entstand die vorliegende Arbeit. Die Datenbankkenntnisse aus früheren Tätigkeiten und der KI-Forschung konnten mit eingebracht werden. Forschung und Entwicklung am Industrieprojekt nahmen fast die komplette Arbeitszeit und einen großen Teil der Freizeit in Anspruch. Deshalb konnte die Dissertation während der Assistentenzeit an der TU BAF nicht fertiggestellt werden. Bis heute wurde das Projekt intensiv weiterentwickelt. In der Dissertation können sich dadurch Differenzen zwischen dem heutigen Stand des Projektes und dem Stand ergeben, zu dem ich die TU BAF verließ. Die vorliegende Arbeit bezieht sich (auch aus rechtlichen Gründen) immer auf diesen Zeitpunkt (Ende 1998).

1.2 Einführung

In der Prozessautomatisierung ist in den letzten Jahren die Menge der zu verarbeitenden Daten rapide angestiegen. Diese Daten müssen erfasst, transportiert, verarbeitet und ausgewertet werden. Oftmals sind diese Aufgaben in Realzeit zu erledigen. In herkömmli-chen Systemen werden die Daten in jedem Teilsystem wieder neu erfasst. Neben der Fehleranfälligkeit, vor allem bei manueller Neueingabe, gibt es eine Reihe weiterer Nachtei-le, wie z.B. den unnützen Zeit- und Personalaufwand. Ein Ziel der Automatisierungstechnik ist die Kopplung einzelner Prozesse zu einem Gesamt-system. Hierbei können Daten maschinell weitergeleitet werden. Des Weiteren ist es durch diese Kopplung möglich, eine Vielzahl zusätzlicher Daten zu übermitteln, welche bisher aus Effektivitäts- und Kostengründen (bei der Neuerfassung) nicht berücksichtigt wurden. Als Beispiele seien hier die Kopplungen von PPS-Systemen bzw. Leitständen mit CAD-, BDE-, MDE- und QDE-Systemen genannt. Oftmals existieren für diese Kopplungen spezielle Lösungen. Anforderungen der Industrie an ein ATS:

• Schnittstellen Die Kommunikation ist für die Synchronisierung von Prozessen untereinander unbe-dingt notwendig. Die Kommunikation sollte über die verschiedensten Medien und mit den verschiedensten Standards funktionieren.

Page 16: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Einleitung Seite 2

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• skalierbar in Größe und Leistung, modular, anpassungsfähig Eine begrenzte Leistungsfähigkeit der Hardware muss berücksichtigt werden, um den Einsatz möglichst kostengünstiger Mikrokontroller oder PCs zu unterstützen. Es sollte mit wenig Aufwand möglich sein, das System an neue Bedingungen anzu-passen bzw. nicht benötigte Module zu entfernen, um Ressourcen zu sparen.

• Ein Dauerbetrieb ist fast immer notwendig. Dies stellt besonders hohe Anforderungen

an die Verfügbarkeit und an das Sicherheitssystem.

• bestimmte Sonderfunktionen (sind notwendig bzw. hilfreich):

o Realzeit5 Die Antwort- bzw. Reaktionszeiten des ATS müssen den Anforderungen der Automatisierungsanlage entsprechen.

o Timer Damit kann das ATS z.B. automatisch wiederkehrende Funktionen durchfüh-ren, z.B. eine Messwerterfassung zu bestimmten Zeiten.

o …

• synchrone und asynchrone Arbeitsweisen (Reaktionsfähigkeit) Da die Daten in der Regel stochastisch geliefert werden, ist die Verwendung von Pol-ling-Verfahren sehr uneffektiv.

• Sicherheit des Datenbestandes

Der Verlust von Daten ist nicht akzeptabel.

• Transparenz, Bedienerfreundlichkeit Es sollte davon ausgegangen werden, dass die Bediener des Systems keine EDV-Fachleute sind. Trotzdem müssen sie in der Lage sein, das System komplett zu handhaben. Der Bedienaufwand sollte so gering wie möglich gehalten werden. Ein transparentes System ist Voraussetzung für das Verständnis. Des Weiteren sollte so viel wie möglich Funktionalität automatisch arbeiten. Durch eine Lastverteilung ist ei-nerseits eine optimale Auslastung zu gewährleisten, andererseits soll die Bedienung nicht durch Überlastung gestört oder behindert werden.

• portabel

Da in vielen Fällen keine Automatisierungslösung komplett neu aufgebaut wird, muss aus Kostengründen versucht werden, vorhandene Teillösungen zu integrieren.

5 Nach /DIN 44300/ ist der Begriff Realzeitverarbeitung dem Begriff Echtzeitverarbeitung vorzuziehen, da

Echtzeitverarbeitung in der Analogrechentechnik und Simulationstechnik eine andere Bedeutung besitzt.

Page 17: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Einleitung Seite 3

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• unabhängig von Betriebssystemen Da z.B. auf Mikrokontrollern im Normalfall kein Betriebssystem existiert, muss das ATS ohne dessen Unterstützung auskommen. Die Schnittstellen der verschiedenen Betriebssysteme sind zu unterschiedlich, um einen gemeinsam verwendbaren Nen-ner zu finden.

• preiswert

Vergleicht man die Anforderungen an ein ATS mit der Funktionalität von DBS, so scheint es, dass ein modernes DBS viele der Anforderungen des ATS standardmäßig unterstützt. Aber auch neuere Normen und Vorschriften wie z.B. die EG-Richtlinie für Produkthaftung, welche die Beweislast auf den Produzenten verlagert6, verlangen die Speicherung von immer mehr Daten. Daher beschäftigt sich die vorliegende Arbeit mit Untersuchungen zum Einsatz von DBS in der Industrie.

1.3 Ziele und Aufgabenstellung

Im Mittelpunkt der Arbeit wird ein Konzept für ein durchgängig objektorientiert programmier-tes, verteiltes, hart realzeitfähiges Client-Server DBS vorgestellt. Insbesondere die hart-realzeitfähige Eigenschaft des DBS stellt eine wesentliche Neuerung gegenüber bisherigen DB-Systemen dar. Weiterhin wird besonderer Wert auf die besonderen Anforderungen der AT an DBS gelegt. Als Voraussetzungen werden UNIX- oder DOS/Windows-Betriebssysteme bzw. kompatible Systeme (z.B. Linux), ein YACC (kompatibler) Compiler-Compiler (YACC, Bison, ... oder der im IfAT der TU BAF entwickelte Compiler-Compiler (Wiesel) für jedes System und ein C++ Compiler erwartet. Die bereits vorhandene bzw. neu zu erwerbende Hardware muss über Ethernet, bzw. CAN-Bus vernetzt werden. Um die Arbeit einheitlich zu gestalten, werden für Begriffe (soweit üblich) die deutschen Bezeichnungen vorgezogen. Auf das Gebiet der DBS haben stets zahlreiche andere Disziplinen Einfluss genommen. Dazu zählen z.B. die Informatik mit Datenstrukturen und Betriebssystemen, Multiprozessing und Multiprogramming, die Mathematik mit Graphentheorie, Logik und Übersetzung von Programmiersprachen (Syntaxanalyse), die Theorie der Synchronisierung paralleler Prozes-se, aber auch die Entwicklung der Hardware mit schnellen sekundären Speichern. Daher stellt die vorliegende Arbeit den Versuch der Transformation verschiedener interdiszi-plinärer Bereiche (AT, Informatik, Prozessmesstechnik) ineinander dar.

6 Danach müssen Hersteller sicherheitsrelevanter Teile alle wichtigen Prozess- und Produktionsdaten in

Echtzeit erfassen und 10 Jahre lang mit 100% iger Datensicherheit archivieren.

Page 18: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Einleitung Seite 4

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

1.4 Abgrenzung

Aufgrund der umfangreichen Literaturstudien und der eigenen mehrjährigen praktischen Erfahrung mit DBS, insbesondere des DBS Progress /Pro/, kann an dieser Stelle bereits eine Abgrenzung der Arbeit zu folgenden Schwerpunkten erfolgen:

• Die vorliegende Arbeit behandelt den Entwurf eines DBMS. Es wird in keiner Form ein DB-Entwurf behandelt. Dieser kann u.a. in /GaRö96/ nachgelesen werden.

• Der Beitrag berücksichtigt im Wesentlichen nur die Belange der Automatisierungs-technik bzw. der Industrie.

• Der Beitrag beschränkt sich auf das relationale Datenmodell /Vo85/, es wird keine Stellungnahme zu anderen, z.B. objektorientierten, wissensbasierten, temporalen bzw. verteilten DBS genommen.

• Es wird sich auf das Client-Server-Modell beschränkt. • Es wird kein verteiltes DBS behandelt. Es wird jedoch versucht, alle Komponenten für

diese Erweiterung offen zu halten. • Es werden keine Abfragesprachen (z.B. SQL) und die eventuell zugehörigen Optimie-

rer behandelt. • Es wird keinerlei Sicherheitskonzept betrachtet, das System ist jedoch offen für die

Erweiterung. • Es werden nur die für die Arbeit notwendigen Grundlagen erläutert. Es ist kein um-

fassendes allgemeines DBS-Buch. • Teilweise werden Alternativen aufgezählt. Diese erheben keinen Anspruch auf Voll-

ständigkeit, sondern sind nur beispielhaft.

1.5 Inhalt der Dissertationsschrift

Nach der allgemeinen Einleitung mit Zielstellung und Abgrenzung erfolgt in Abschnitt 2.1 eine genauere Betrachtung zu DBS. Insbesondere die Tabelle 2.1 auf Seite 9 soll als Leitfaden und Übersicht über die Struktur der vorliegenden Arbeit dienen. Anschließend werden in Kapitel 2 die für die Arbeit grundlegenden Prinzipien und Methoden beschrieben. Dieses Kapitel erläutert im Wesentlichen Entwicklungsstände gegenwärtiger Systeme. In Kapitel 3 werden, aufbauend auf Kapitel 2, Lösungsmöglichkeiten und Konzepte betrach-tet. Als Schwerpunkt dieses Kapitels ist der Abschnitt 3.7 zu sehen, in dem ausführliche Realzeitbetrachtungen erfolgen. Unter Zuhilfenahme der theoretischen Grundlagen aus Kapitel 2 und der Konzepte aus Kapitel 3 wird in Kapitel 4 die praktische Realisierung des DBMS „MRDB“ beschrieben. Die Ergebnisse dieser Realisierung konnten in einem praktischen Einsatz in der Industrie getestet werden. Eine Übersicht des Prototypeinsatzes ist in Kapitel 5 nachzulesen. Kapitel 6 fasst die erreichten Ergebnisse zusammen und gibt einen weiterführenden Aus-blick.

Page 19: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 5

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2 Wissensstand

2.1 Datenbanken

Eine Datenbank (DB) ist ein integrierter Bestand persistenter7 Daten /We95/. Diese Daten gehören zu einer zusammenhängenden Anwendung. Den Nutzern werden dabei verschie-dene Sichten auf die Daten gegeben /Vo87/. Der Begriff Datenbanksystem (DBS) bezeichnet heute im Allgemeinen relationale DBS. Diese haben aufgrund ihrer leichten Verständlichkeit und einfachen Abfragesprachen das hierarchische und das Netzwerkmodell abgelöst. Leider lassen sich Daten komplexer Anwendungen nicht realitätsnah modellieren8. Zur Behebung dieser Nachteile wurden die so genannten semantischen Modelle entwickelt. Gleichzeitig begann die Entwicklung der objektorientierten Programmiersprachen. Beides zusammen führte zur Entwicklung der objektorientierten DBS (OODBS). Seit 1975 existiert die 4. Generation von DBS, die sich durch eine klare Trennung zwischen logischem und physischem Modell auszeichnen. Ein DBS besteht aus dem Datenbankmanagementsystem (DBMS) und einer Anzahl von DBs.

DBS DBMS n * DB= + (2.1)

Das DBMS stellt dabei aus technischer Sicht ein reentrant9 realisiertes Programm dar.

2.1.1 Anforderungen an ein DBS

Die folgenden Anforderungen entsprechen der Einteilung nach /GaRö94/.

• grundlegende o Speicherung der Daten o Verwaltung und Kontrolle der Daten

• notwendige o Redundanzfreiheit der Daten (zumindest redundanzarm) o Daten- und Programmunabhängigkeit o Datenintegrität

• wünschenswerte o allgemeine

Leistungsfähigkeit (Performance) Flexibilität (flexibility) Benutzerfreundlichkeit (human engineering)

7 persistent (hartnäckig): Für eine lange Zeit oder ununterbrochen bestehen, Ausdauer haben.

8 Wenn z.B. zu einem Buch neben ISBN und Titel auch noch mehrere Autoren zu speichern sind, dann ist dies nur mit Datenredundanz oder mit Relationen lösbar.

9 reentrant (wiedereintrittsfähig): Ein Prozess kann unterbrochen und jederzeit weiterbearbeitet werden, ohne dass es zu Inkonsistenzen kommt.

Page 20: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 6

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Portabilität (portability) der Software Wartbarkeit (maintainability) der Software Testbarkeit (testability) der Software Verständlichkeit (understandability) der Software Änderbarkeit (modifiability) der Software Brauchbarkeit (usability) der Software Effizienz (efficiency) Zuverlässigkeit (reliability) Genauigkeit (accuray) Vollständigkeit (completeness) Robustheit (robustness) Konsistenz (consistency)

o anwendungsbezogene z.B. Auslösen von Ereignissen bei bestimmten Betriebsbedingungen

2.1.2 Vorteile von Datenbanken gegenüber konventionellen Datei-systemen10

/Vo87/

+ Alle Daten einer bestimmten Anwendung werden in einem integrierten Bestand je-weils einmal gespeichert. Dieser Bestand ist weitgehend frei von Redundanzen und Widersprüchen und ist einheitlich formatiert.

+ Die Verwaltung der Daten erfolgt durch eine zentrale Instanz. Diese kann Änderun-gen durchführen und muss dabei Inkonsistenzen vermeiden.

+ Alle Benutzer arbeiten auf physischer Ebene mit dem gleichen Datenbestand. Damit sind auch einheitliche Integritätskontrollen, Schutz- und Sicherungsmechanismen anwendbar.

+ Es ist möglich, einzelnen Nutzern oder Nutzergruppen eine unterschiedliche logische Sicht auf den Datenbestand zu ermöglichen.

+ Die Unterstützung bzw. Einhaltung von Standards wird erleichtert, da die Einmalspei-cherung und einheitliche Formate gewährleistet werden können.

+ Die Daten sind flexibel für Änderungen in der Anwendung. + Auf die Daten kann einfach, standardisiert zugegriffen werden. + Es wird eine hohe Produktivität bei der Programmierung und Programmwartung er-

reicht. + Die Durchsetzung bzw. Einhaltung von Standards wird wesentlich erleichtert.

10 Es wird an dieser Stelle von konventionellen Dateisystemen gesprochen, da es mittlerweile auch

protokollierende Dateisysteme gibt. (z.B. ReiserFS: Dabei handelt es sich um ein weiterentwickeltes Da-teisystem für Linux mit Journal. Dieses protokolliert jede Änderung der Datenstrukturen im Dateisystem und ermöglicht so eine schnelle Wiederherstellung des Systems (z. B. bei Stromausfall).

Page 21: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 7

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.1.3 Betrachtungsweisen

Zur Gewährleistung der Vorteile eines DBS, insbesondere der logischen und physischen Datenunabhängigkeit, ist eine Sicht der Daten auf 3 Ebenen naheliegend. Daher beruhen die meisten der heute angebotenen DBS auf dem ANSI-X3-SPARC Architekturvorschlag von 1975 /Be92/. F 1: Die Ebenen werden in der Literatur auch als Schema oder Schicht bezeichnet. In der

vorliegenden Arbeit wird der Begriff Ebene verwendet.

DB

User-Language

DB

User-Language

Interne Ebene

Konzeptionelle Ebene

Externe Ebene Externe Ebene

DB

Bild 2.1: ANSI-X3-SPARC 3-Ebenen-Architekturvorschlag

Diese Trennung ermöglicht es, die verschiedenen Nutzer mit genau den von ihnen benötig-ten Daten und Datenstrukturen zu versorgen und sie gleichzeitig von Detailkenntnissen der Implementierung des DBS zu entlasten.

• Interne Ebene Die interne Ebene beschreibt die physische Datenorganisation. Sie liegt dem phy-sikalischen Speicher am nächsten. Sie unterscheidet sich von ihm jedoch, da die physisch gespeicherten Daten nicht als Seiten oder Blöcke, sondern als Datensätze betrachtet werden.

• Konzeptionelle Ebene

Auf der konzeptionellen Ebene wird die logische Gesamtsicht der Daten in der DB (und ihrer Beziehungen) repräsentiert. Dazu bedient man sich eines Datenmodells, welches insbesondere von der internen Ebene abstrahiert. Für die Sichtweise einer DB ist die konzeptionelle Ebene und ihr Datenmodell zentral /Vo95/.

Page 22: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 8

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• Externe Ebene Die externe Ebene umfasst alle individuellen Sichten der einzelnen Nutzer oder Nut-zergruppen. Diese Sichten (Views) werden jeweils in einer eigenen externen Ebene beschrieben. Wenn genau eine externe Ebene existiert, dann ist die Differenzierung von konzeptioneller Ebene und externer Ebene als künstlich anzusehen.

Die 3-Ebenen-Architektur unterstützt die effiziente Realisierung der Datenunabhängigkeit von Nutzeranforderungen /We95/:

• physische Datenunabhängigkeit Die Notationen von Nutzeranforderungen bleiben gültig bei Änderungen der physi-schen DB-Strukturen, z.B. bei Veränderung der Speicherallokation.

• logische Datenunabhängigkeit

Die Notationen von Nutzeranforderungen bleiben gültig bei Änderungen der logi-schen DB-Strukturen, z.B. bei Veränderung der logischen Zugriffspfade.

• Ebenenunabhängigkeit

Die anhand von externen Ebenen formulierten Nutzeranforderungen sind unempfind-lich gegen Änderungen der konzeptionellen Ebene (z.B. durch Entfernen oder Hinzu-fügen von Strukturkomponenten oder Integritätsbedingungen).

Die konsequente Durchsetzung der 3-Ebenen-Architektur verlangt, dass die 3 Ebenen bei der DB-Definition getrennt behandelt werden (ANSI) /We95/. An erster Stelle steht die Definition der konzeptionellen Ebene. Die Implementierung ist eine logisch nachgeordnete Aufgabe, ebenso wie die Definition von Nutzersichten (externe Ebene). In der Theorie werden deshalb den 3 Ebenen eigene Definitionsteilsprachen zugeordnet. Für die konzepti-onelle Ebene existiert die DDL (Data Definition Language). Daneben existieren eine DSDL (Data Storage Definition Language) für die interne Ebene und eine VDL (View Definition Language) für die externe Ebene11. Die DDL ist üblicherweise nur bestimmten Nutzern (Administratoren) zugänglich.

2.1.4 Komponenten eines DBMS

Im Folgenden soll eine Übersicht über die Komponenten eines DBMS und ein Verweis zur Beschreibung der Realisierung gegeben werden. Gegenüber der allgemeingültigen Eintei-lung wurde die Tabelle um die Komponenten, welche in der Arbeit von Bedeutung sind, erweitert. Nicht behandelte Komponenten wurden weggelassen.

11 Nach /Vo87/ wird die Sprache auf konzeptioneller Ebene auch als Schema-DDL, die Sprache auf externer

Ebene als Subschema-DDL bezeichnet.

Page 23: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 9

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Komponente Beschreibung Realisierungsvorschlag

Data Dictionary System12 S. 9 S. 77

Prozess-Manager S. 11 S. 82

File-Manager S. 12 S. 83

Puffer-Manager S. 14 S. 85

Datensatz-Manager S. 15 S. 88

Transaktions-Manager S. 15 S. 91

Lock-Manager S. 18 S. 88

Recovery-Manager S. 21 S. 83

Log-Manager S. 24 S. 24

Zugriffsmethoden S. 31 S. 91

Realzeit-Manager13 - S. 94

Kommunikationsmanager14 - S. 94 Tabelle 2.1: Komponenten eines DBMS

2.2 Data Dictionary System

In der Praxis aufgestellte Daten sind häufig sehr umfangreich. Deshalb ist eine Beschreibung der Daten und eine Übersicht über die Daten und deren Beziehungen, Verknüpfungen sehr wünschenswert. Diese Funktion kann durch ein Data Dictionary System (im Folgenden als DDS bezeichnet) erfüllt werden, da es als Metadatensystem Daten über Daten enthält. Häufig werden auch die Begriffe Datenkatalog, Datenwörterbuch oder Datenlexikon verwen-det. Die Funktionalität bekannter DDS ist sehr unterschiedlich. Dadurch fällt eine Beurteilung recht schwer. Eine Beurteilungsmöglichkeit ist z.B., wie es die Nutzung der in /DIN 66232/ beschriebenen Metadaten unterstützt. Des Weiteren gehört heute aber auch die Speicherung und Benutzung aller vom Nutzer gewünschten Objektklassen, Attribute und Beziehungen dazu. Ein DDS besteht im Allgemeinen aus einer Datenbasis DD (Data Dictionary) und einem Pro-grammsystem zur Verwaltung der Datenbasis DDMS (Data Dictionary Management System).

DDS DDMS DD= + (2.2)

12 Vielfach werden andere Begriffe verwendet, z.B. Information Ressource Dictionary von ANSI und ISO,

Repository von IBM oder Systemkatalog. 13 Es kann keine Beschreibung erfolgen, da dies eine wesentliche Neuerung gegenüber anderen Quellen ist.

(siehe Beispielhaft /Vo87/, /Vo95/, /Ull88/, /Si91/, ...) 14 Eine Kommunikation ist zwar in allen Client-Server-Systemen vorhanden, sie ist jedoch meist nicht mit

Hilfe eines Managers implementiert bzw. nicht konsequent beschrieben und implementiert. Daher erfolgt keine Beschreibung.

Page 24: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 10

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Teilweise erfolgt eine Trennung des DD in:

• Data Dictionary: logische, benutzerorientierte Attribute (was?) • Data Directory: physische, maschinenorientierte Attribute (wo?)

Eine saubere Trennung ist jedoch nicht möglich /GaRö94/. Klassifikation der DDS:

Bild 2.2: Klassifikation von DDS nach /GaRö94/

Anforderungen an ein DDS:

• Objekt- (Daten-) Beschreibungsfunktion • DB-Designfunktion (Daten, Applikationen, Programme, Nutzer, Nutzersichten, ...) • Datenübertragungsfunktion15, Schnittstellen • Qualitätssicherungsfunktion • Generierungsfunktion für Datenbeschreibungen, Testdaten, Programmteile • Versionsverwaltungsfunktionen • Zugriffsberechtigungsfunktionen, Eigentumsverhältnisse, Integritätsregeln • Berichtsfunktionen, statistische Funktionen • Nutzungsfunktionen für Stapelprozesse

Eine Beschreibung ist u.a. in /Be92/, /GaRö94/, /Ko01/ zu finden. Das DD „SQL Data System“ wird in /Vo87/ erläutert.

15 Problem ist z.B. die Übertragung der DB zwischen verschiedenen Betriebssystemen. Die einfachste

Möglichkeit ist dabei der Export und Import der Daten und Datenstrukturen im Textformat. Aber auch dabei sind Sonderzeichen und (Datei-)Namenskonventionen zu beachten.

Page 25: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 11

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.3 Prozess-Manager

Um auf einer einzelnen CPU mit eigentlich sequentieller Befehlsabarbeitung eine für den Nutzer scheinbare parallele Abarbeitung der Aufgaben zu ermöglichen, ist das Softwaresys-tem in mehrere Prozesse zu teilen. Während unter dem Betriebssystem DOS kein Prozess-system existiert, ist dieses z.B. unter UNIX im Kern des Betriebssystems implementiert. Man unterscheidet zwischen nicht unterbrechbaren (non preemptive) und unterbrechbaren (preemptive) Prozessen. Des Weiteren werden leichtgewichtige Prozesse (Threads) und schwergewichti-ge Prozesse unterschieden. Grundsätzlicher Engpass ist die Prozessumschaltung (context switch). Dabei rettet der System-kern alle wichtigen Informationen des aktuellen Prozesses. Danach wird der nächste Pro-zess gestartet. Die Prozessumschaltung unter UNIX wird durch unterschiedliche Prioritäten und Ablauf von Zeitscheiben ausgelöst. Sie berücksichtigt nicht den Zustand des Prozesses, wie z.B. gemeinsam benutzte Betriebsmittel16. Die Umschaltung der Prozesse geschieht nach einem Plan (schedule) durch den Scheduler. Dieser hält sich eine Liste aller Prozesse in einer Warteschlange. Trotzdem ist zu beachten, dass n kleine Betriebsmittel nicht die Leistung eines großen Betriebsmittels mit n-facher Leistung bringen, insbesondere, da zur Koordinierung der Betriebsmittel Verwaltungsaufwand notwendig ist. Dieses Ergebnis wird u.a. in /Ta94/ bewiesen:

1tλ µ

∆ =−

(2.3)

• t∆ : mittlere Zeit zwischen Auftragserteilung und Beendigung • λ : Ankunftsrate, der Kehrwert wird als mittlerer Ankunftszeitabstand bezeichnet • µ : Bedienrate

1n V V

tt t tn n nλ µ

∆∆ = + = +

− (2.4)

• vt : Verwaltungszeit Dieses Ergebnis spricht eigentlich gegen verteilte Systeme. Die Kosten, die Zuverlässigkeit und die Fehlertoleranz sprechen jedoch dafür /Ta94/. Um die Anzahl der aufwändigen Prozessumschaltungen zu vermindern, existieren folgende Möglichkeiten:

• Ein- und Ausgaben werden minimiert und liegen zeitlich auseinander • Es gibt keine Sperren auf Betriebsmittel • die Anzahl der freiwilligen Umschaltungen wird minimiert

Eine Lösung der nahen Zukunft sind Multi-Prozessor-Systeme oder Intels Hyperthreading-Technologie, bei denen die Prozessumschaltung an Bedeutung verliert. 16 Als Betriebsmittel bezeichnet man dabei Hard- oder Software, deren Zugriff exklusiv erfolgen muss /Da91/.

Page 26: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 12

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Gegenüber den Prozessen arbeiten alle Threads im selben Adressraum. Sie können daher konkurrierend auf die Daten zugreifen. Die aufwändige Interprozesskommunikation entfällt. Threads werden im Wesentlichen aus 2 Gründen verwendet:

• Sie erlauben es, Multi-Prozessor-Maschinen auszunutzen. Das Programm wird durch die Threads auf die einzelnen Prozessoren aufgeteilt und kann damit wesentlich schneller ablaufen als auf einem einzelnen Prozessor.

• Einige Programme sind durch mehrere Threads, welche miteinander kommunizieren, besser darstellbar als ein großes monolithisches sequentielles Programm. Dazu zäh-len z.B. Serverprogramme und graphische Nutzerinterface /Xa97-1/.

Die API für Multi-Threaded-Programmierung ist im /Posix-Standard 1003.1c/ durch die IEEE genormt. Die meisten UNIX-Anbieter unterstützen diesen Standard (Sun Solaris 2.5, Digital Unix 4.0, Silicon Graphics IRIX 6, bald auch HP und IBM) /Xa97-1/. Als Implementie-rungsmodelle sind die folgenden Modelle gängig:

• das „one-to-one”-Modell Jeder Thread ist ein eigener Prozess im Kernel mit folgenden Eigenschaften:

+ minimaler Overhead an CPU-intensivem Multiprozessing + minimaler Overhead an I/O-Operationen + simple und robuste Implementierung ­ aufwändige Prozessumschaltung, da immer über Kernel notwendig

• das „many-to-one”-Modell

Diese Modell beruht auf einem User-Level-Scheduler. Für den Kern existiert nur ein Prozess.

• das „many-to-many”-Modell

Dieses Modell kombiniert Kernel-Level- und User-Level-Scheduling und versucht damit, die Vorteile beider Modelle zu nutzen.

Eine ausführliche Beschreibung zu Prozessen, Prozesssystemen, ... kann u.a. in /Ru97/, /Ta94/, /Da91/, /ReLe94/, /Wa97/, /Xa97/, /Xa97-1/ nachgelesen werden.

2.4 File-Manager

Entscheidend für die Geschwindigkeit des DBS ist die Arbeitsweise des File-Managers. Dabei muss in der Regel davon ausgegangen werden, dass die DB im Allgemeinen zu groß für den Hauptspeicher ist und in Form von (RAW-)Files auf einem Sekundärspeicher (Mag-netplatte, Festplatte oder im Folgenden kurz Platte) gespeichert wird. Platten sind durch wahlfreien Zugriff gekennzeichnet. Eine Platte ist üblicherweise in Blöcke (Pages) fester Länge, welche einzeln adressierbar sind und welche die „Einheit” des Datentransfers zwischen Sekundär- und Hauptspeicher darstellen, unterteilt. Die Bedeutung des Arbeitsweise des File-Managers für die Geschwindigkeit des DBS

Page 27: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 13

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

begründet sich in der wesentlich größeren Zugriffszeit von Platten gegenüber dem RAM. Prinzipiell können die DB-Files im normalen Filesystem des jeweiligen Betriebssystems abgelegt werden. Diese Filesysteme sind jedoch üblicherweise so ausgelegt, dass sie optimal mit vielen kleinen Files arbeiten. Ein DBS arbeitet jedoch mit wenigen großen Files. So bereiten unter DOS Dateigrößen ab 8MB Performance-Probleme /Pro/. Obwohl die UNIX-Filesysteme wesentlich effektiver als das DOS-FAT-System sind, sind auch sie problematisch. Das UNIX-Filesystem geht von einer invertierten Baumstruktur aus, in der die Wurzel das oberste Verzeichnis bildet. Der Zugriff auf die Daten erfolgt indirekt über die Knoten des Baumes. Die Baumstruktur erlaubt die maximale Ausnutzung des Plattenspeichers, da die Daten stark fragmentiert abgelegt werden können. Dies geht jedoch auf Kosten der Zugriffs-geschwindigkeit. Beim UNIX-System V sind dadurch bei einer 50MB-Datei schon 3 Plattenzugriffe notwendig. Eine typische OLTP-Anwendung (online transaction processing) fordert eine mittlere Antwortzeit von 2 Sekunden für 10 - 20 Platten Ein- und Ausgaben in die DB /Froe94/. Bei einer nach Stand der Technik durchschnittlichen Zugriffszeit von ca. 10-20 ms /Schwi92/ ergibt diese Forderung, dass bei Vernachlässigung der Rechenzeiten maximal 10 Plattenzugriffe für eine Ein- oder Ausgabe möglich sind. Da mehrere DB-Files geschrieben werden müssen, sind die harten Grenzen sichtbar. Ein schwerwiegendes Problem unter UNIX ist es weiterhin, dass der Zeitpunkt, zu dem eine Datei auf die Platte geschrieben wird, vollkommen undefiniert ist. Damit ist es nicht möglich, ein Transaktionskonzept zu implementieren. Dies liegt am Puffer-Cache. Der UNIX-Puffer-Cache ist ein Systempuffer, welcher RAM belegt. Er dient der Beschleunigung des Daten-transfers zwischen Platte und Hauptspeicher. Datenblöcke werden erst in den Cache gelesen und dann in den Anwendungsbereich kopiert. Dies geschieht auch umgekehrt und birgt die folgenden Nachteile:

­ Die Datenintegrität kann nicht garantiert werden, da die Daten in den Cache ge-schrieben werden und nicht bekannt ist, wann sie auf der Platte sind.

­ Die Sicherheit ist gefährdet, da der Inhalt des Cache auch von Nicht-DBS-Benutzern geschrieben werden kann.

Um diese Nachteile zu umgehen, existieren im Wesentlichen zwei Möglichkeiten:

• Write-Through-Cache-Option Falls das UNIX-System diese Option ermöglicht, wird ein Prozess erst weiterbearbei-tet, wenn die Daten wirklich auf die Platte geschrieben sind.

• RAW-Device Mit diesen Devices ist ein effektiver DMA-Blocktransfer möglich. Des Weiteren wird ein Plattenbereich zur Verfügung gestellt, der vom DBMS und nicht vom UNIX-System verwaltet wird. Es ist eine größere Anzahl von Blöcken pro Ein- und Ausga-beoperation möglich. Durch den Einsatz von RAW-Devices sind Leistungssteigerun-gen von 15-20% möglich /Wi91/, da bei Verwendung eines Zeichen-Treibers der Sys-tempuffer (Puffer-Cache) und das Vorauslesen (pre-fetch) erfolgreich umgangen wer-den.

Page 28: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 14

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Unter Linux ist es weiterhin möglich, mit Hilfe der Befehle fsync bzw. fdatasync ein Schreiben auf die Platte zu erzwingen. Da diese Befehle über den Betriebssystemkernel laufen, sind sie jedoch sehr langsam. Grundlagen zu diesem Thema können u.a. in /Ta94/, /Ko01/ und /Wi91/ nachgelesen werden.

2.5 Puffer-Manager

Ausgangspunkt für die Einführung eines Puffer-Managers ist der Zustand, dass eine DB im Allgemeinen so groß ist, dass sie nicht in den Arbeitsspeicher des Rechners passt. Die Geschwindigkeit des DBS lässt sich erhöhen, wenn es gelingt, die Anzahl der Plattenzugriffe zu minimieren. Deshalb sollten die am häufigsten benötigten Daten im RAM gehalten werden. Genau diese Aufgabe wird durch den Puffer-Manager erledigt. Die Puffer besitzen alle eine einheitliche Blockgröße. Bei der Ermittlung der Puffergröße ist zu beachten, dass von den meisten Massenspeichern nur Blöcke gelesen werden können. Es ist also sinnvoll, die Puffergröße an diese Blockgröße anzupassen. Beispiel 2.1:

Die Größenordnungen zeigen, dass es schwer ist, selbst die Verwaltungsinformationen der Puffer komplett im RAM zu halten. Zu diesen Informationen gehören u.a.:

• Ist der Puffer im RAM? • Wann wurde er das letzte Mal benutzt? • Wie oft wurde er benutzt?

Die Verwaltung der DB-Puffer entspricht üblicherweise der von Cache-Systemen. Benötigte Daten werden in die Puffer geladen, um bei der Widerverwendung nicht mehr auf die Platte zugreifen zu müssen. Falls alle Puffer belegt sind, muss ein Puffer gelöscht werden. Daher ist eine Strategie notwendig, nach der bestimmt wird, welcher Puffer geleert wird. Falls Datensätze über mehrere Blöcke verteilt sind, so spricht man von Fragmentierung (spanned), ansonsten von (unspanned). Da beim Lesen eines solchen Datensatzes auf mehrere Blöcke zugegriffen werden muss, erhöht sich die Zugriffszeit. Daher wird bei den meisten DBS ein Datensatz immer in max. einem Block gespeichert. Es existiert dann jedoch ein Zusammenhang zwischen Blockgröße und maximaler Datensatzgröße. Die Blockgröße ist prinzipiell beliebig, jedoch sind nicht alle Größen sinnvoll. Die Bestim-mung der optimalen Blockgröße ist ein Balancieren von verschiedenen konkurrierenden Faktoren. Beschreibungen zu diesem Thema sind u.a. in /Rus97/, /Ta94/, /ReLe94/, /Ko01/ zu finden.

DB-Größe: 1GB (230 Byte) Puffergröße: 512 (29) Byte 2.097.152 (221) Puffer theoretisch notwendig 1024 (210) Byte 1.048.576 (220) Puffer theoretisch notwendig

Page 29: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 15

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.6 Datensatz-Manager

Da auf logischer Ebene mit Datensätzen gearbeitet werden soll, ist eine Umwandlung der physischen Puffer in logische Datensätze notwendig. Diese Aufgabe übernimmt der Daten-satz-Manager. Der Datensatz-Manager speichert die Informationen aller aktuell verwendeten Datensätze. Damit sind aktuell bearbeitete Daten einerseits in der Pufferverwaltung, andererseits in der Datensatzverwaltung vorhanden. Diese doppelte Datenhaltung ist notwendig, um den Urzustand der Daten beim Starten einer Transaktion zu bewahren und u.U. wieder herzustel-len. Die genaue Beschreibung dieser Notwendigkeit erfolgt im nächsten Abschnitt. Prinzipiell können die BI-Daten von beiden Managern verwaltet werden. Je nach Variante ist beim commiten17 oder beim aborten17 der Datensatz in den Pufferbereich zurückzuschreiben.

2.7 Transaktions-Manager

2.7.1 Transaktionen

Die wesentliche Idee des Transaktionskonzeptes ist, dass einem Programm, welches auf die DB zugreift, die DB als scheinbar exklusives Betriebsmittel zur Verfügung steht, die Konsis-tenz der DB durch das Programm nicht gefährdet werden darf und erzeugte Effekte in der DB durch nachfolgende Fehler nicht beeinflusst werden. Daraus resultieren die Probleme der Konkurrenzsteuerung und des Recovery /Vo85/. Transaktionen überführen eine DB von einem konsistenten Zustand in den nächsten konsi-stenten Zustand. Erst sie ermöglichen konkurrierenden Prozessen den Zugriff auf eine DB, ohne die Integrität der Daten zu zerstören. Im Falle eines Fehlers ist es die Aufgabe des Recovery-Managers den konsistenten Ausgangszustand wieder herzustellen (undo, Roll-back). Die 4 grundlegenden Eigenschaften (A.C.I.D.) einer Transaktion sind die folgenden: Eigenschaft Beschreibung

• Atomizität (atomicity)

Eine Transaktion ist eine unteilbare Einheit. Dies bedeutet, dass entweder alle Aktionen oder keine Aktion der Transaktion durchgeführt werden müssen. Dieses Verfahren bietet Schutz vor allen erwarteten Fehlern, da beim Auftreten eines Fehlers die Teil-resultate rückgängig gemacht werden können.

• Konsistenz (consistency)

Eine Transaktion führt eine DB von einem konsisten-ten Zustand in den nächsten über.

• Serialisierbarkeit (isolation) (independence)

Transaktionen werden unabhängig von anderen Transaktionen ausgeführt.

17 Begriffsdefinition: siehe F2 Seite 17

Page 30: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 16

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Eigenschaft Beschreibung • Dauerhaftigkeit

(durability) (permanenz) (persistenz)

Eine erfolgreich abgeschlossene Transaktion wird in die DB geschrieben und kann nicht rückgängig gemacht werden. Mit dem Schreiben in die DB können die Ergebnisse der Transaktion bei folgenden Fehlern nicht mehr verloren gehen.

Tabelle 2.2: Grundlegende Eigenschaften von Transaktionen Das Modul, welches für die Konkurrenzsteuerung (Eigenschaft Serialisierbarkeit) mehrerer Transaktionen verantwortlich ist, wird als Scheduler bezeichnet (siehe auch Abschnitt 2.3). Ziel des Schedulers ist es, die Anzahl der gleichzeitigen Zugriffe zu maximieren, ohne dass sich die einzelnen Zugriffe gegenseitig stören und die Konsistenz der Daten gefährden. Die Kommunikation des Programms und des Schedulers erfolgt über den Transaktions-Manager. Die Theorie der Serialisierung bemüht sich um das korrekte Arbeiten des Schedulers. Sie basiert auf einen Berechnungsmodell /Vo87/. Bekanntestes Transaktionsmodell für zentrale Systeme ist das Read-Write Modell /Vo85/. Die Ausführung einer Applikation in einer DB-Umgebung kann dabei als eine Serie von Transaktionen betrachtet werden. Die DB selbst wird als abzählbare Menge von Datenobjekten ( D ) betrachtet.

{ }1 2 3, , , ...=DB D D D (2.5)

Eine Transaktion (T ) ist eine Folge von Operationen (Op ).

[ ]1 2, , ...,= nT Op Op Op (2.6)

Im Read-Write Modell werden lediglich Lese- ( L ) oder Schreiboperationen ( S ) auf Datenob-jekte als relevante Operationen betrachtet. Von allen anderen Verarbeitungsschritten und Operationen wird abstrahiert. Sie sind nicht von Bedeutung.

( ) ( ){ },Op S x L x x DB= ∈ (2.7)

Weiterhin gilt, dass 1Op vor 2Op ... stattfindet, da eine Abhängigkeit der Werte voneinander angenommen wird. Des Weiteren wird angenommen, dass die Operationen atomisch sind.

1 2...< < <

nOp Op Opt t t (2.8)

Die gesamte Menge der Operationen der Transaktionen 1T , ..., nT wird als vollständiger

Schedule S bezeichnet.

[ ]1 2, , ... ,= nS Op Op Op (2.9)

Zusätzlich wird für jede Transaktion nach deren letzter Operation ein Pseudoschritt einge-fügt, welcher angibt, wie die Transaktion endet (erfolgreich oder nicht).

Page 31: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 17

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

F2: Aufgrund der unterschiedlichen Bezeichnungen in der Literatur werden die Operatio-nen für die Zustandsänderung einer Transaktion im Weiteren wie folgt bezeichnet:

• begin eine neue Transaktion wird gestartet • commit eine laufende Transaktion wird erfolgreich beendet • abort eine laufende Transaktion wird abgebrochen

Wenn eine Transaktion aborted, wird die Ausführung beendet und alle bisherigen Aktionen durch ein undo in den Ausgangszustand gebracht. Dies wird auch als Rollback bezeichnet. Ein Schedule ist lediglich ein Prefix eines vollständigen Schedules /Vo85/. Die tiefere Theorie dazu kann unter anderem in /Be92/, /Vo85/ nachgelesen werden. Transaktionen können grundsätzlich in zwei Gruppen unterteilt werden. Diese werden in den nächsten beiden Unterabschnitten erläutert.

2.7.1.1 Serielle Transaktionen

Hintergrund dieses Verfahrens ist, dass zu einem Zeitpunkt immer nur eine Transaktion aktiv sein darf. Dadurch ist dieses Verfahren sehr einfach handhabbar, jedoch langsam und uneffektiv. Da die einzelnen Transaktionen streng seriell abgearbeitet werden, sind automatisch alle Probleme bei konkurrierenden Transaktionen ausgeschaltet.

Bild 2.3: Serielle Transaktionsausführung

Page 32: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 18

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.7.1.2 Parallele Transaktionen

Dieses Verfahren erlaubt mehreren Transaktionen, zu einem Zeitpunkt aktiv zu sein. Dadurch wird es kompliziert handhabbar. Es kann jedoch in der Bearbeitung wesentlich schneller sein.

Bild 2.4: Parallele Transaktionsausführung

2.7.2 Interferenz zwischen konkurrierenden Transaktionen

Wenn Transaktionen parallel zueinander ausgeführt werden, dann besteht die Möglichkeit, dass sie sich gegenseitig beeinflussen. Dabei unterscheidet man grundsätzlich 3 Varianten /Be97/:

• Verlorengegangene Änderungen (Lost update) Eine offenbar erfolgreiche Änderungs-Operation eines Nutzers kann von einem ande-rem Nutzer überschrieben werden.

• Integritätsverletzungen (Violation of integrity constraints)

Dieses Problem tritt bei Transaktionen, welche nicht synchronisiert (koordiniert) sind, auf.

• Inkonsistente Daten (dirty read, unrepeatable read, inconsistent retrieval problem)

Die hauptsächliche Arbeit der Konkurrenzkontrolle konzentriert sich auf Transaktio-nen, welche Daten ändern, da die Interferenz der Transaktionen die DB zerstören kann. Aber auch Transaktionen, welche nur lesend auf Daten zugreifen, können falsche Werte liefern, wenn sie die Daten nur teilweise auslesen und diese gleichzeitig in ei-ner anderen Transaktion geändert werden.

2.7.3 Konkurrenzsteuerung (Concurrency control techniques)

Da die gegenseitige Beeinflussung von Transaktionen unerwünscht ist, muss versucht werden, diese gegenseitigen Einflüsse zu verhindern. Dies ist die Aufgabe der Konkurrenz-steuerung. Im Folgenden werden die 3 prinzipiellen Methoden der Konkurrenzsteuerung vorgestellt /Be92/, /Be97/, /Ko01/.

Page 33: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 19

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.7.3.1 Sperr-Methoden (Locking methods)

Die Sperr-Methoden zählen zu den am meisten genutzten Methoden bei der Kon-kurrenzsteuerung von DBs. Gemeinsamer Hintergrund aller Verfahren ist, dass eine Transaktion anmelden muss, ob sie auf die Daten lesend oder schreibend zugreifen möchte. Da bei Leseoperationen kein Konflikt auftreten kann, dürfen mehrere Transaktionen gleichzeitig zugreifen. Im Gegensatz dazu ist bei einem schreibenden Zugriff der Datensatz für alle anderen Transaktionen gesperrt (zumindest für alle anderen schreibenden Transaktionen). Die Sperre gilt, bis die schreibende Transaktion den Datensatz wieder freigibt. Einige Systeme erlauben upgrading und downgrading der Sperren. Dies bedeutet, dass eine lesende Transaktion ihren Status in eine schreibende Transaktion wandeln kann. Dies darf aber nur geschehen, wenn sie die einzige lesende Transaktion ist. Dadurch wird es dem System ermöglicht, die Daten erst einmal zu lesen und dann, abhängig vom Wert der Daten, zu entscheiden, ob ein schreibender Zugriff erforderlich ist. Aber auch eine schreibende Transaktion kann, nachdem sie die Daten geschrieben hat, ihren Status in eine lesende Transaktion umwandeln. Die Feinheit (granularity) des Items, welches gesperrt werden kann, hat besonderen Einfluss auf die Performance der Konkurrenzsteuerungsalgorithmen. So kann beim Zugriff auf einen Datensatz der Datensatz gesperrt werden, oder im Extremfall wird die ganze DB gesperrt. Wenn aber eine Transaktion 90% aller Datensätze verändern will, ist es sicherlich effektiver, die ganze Tabelle zu sperren, als jeden Datensatz einzeln. Ein ideales System sollte daher an dieser Stelle flexibel arbeiten und mehrere Möglichkeiten beherrschen.

Sperrgranulat

SynchronisationsaufwandParallelität

hoch

niedrig

klein groß

klein

groß

Bild 2.5: Einfluss der Sperrgranulatgröße /Ku92/

Das übliche Sperr-Protokoll wird als Zwei-Phasen Sperre (two phase locking, 2PL) bezeichnet. Dabei wird die Transaktion in 2 getrennte Phasen aufgeteilt, die growing-Phase und die shrinking-Phase. Transaktionen, welche nach dem 2PL arbeiten, müssen folgenden Regeln gehorchen:

• Transaktionen müssen eine Sperre anmelden, bevor sie mit den Daten arbeiten, und

Page 34: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 20

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

die Transaktion muss nach der Arbeit mit diesen Daten die Sperre wieder freigeben. • Kompatibilitätsregeln für die Sperren müssen beobachtbar sein, damit keine konkur-

rierenden Sperren auftreten. • Nachdem eine Transaktion eine Sperre freigegeben hat, darf sie nicht wieder sper-

ren. • Alle schreibenden Sperren werden gleichzeitig freigegeben, wenn die Transaktion

beendet wird. Die letzte Bedingung ist notwendig, um die Atomizität einer Transaktion zu gewährleisten. Trotzdem ist up- und downgrading in 2PL möglich, mit der Beschränkung, dass downgrading nur während der shrinking-Phase erlaubt ist. Eine formale Beschreibung für 2PL kann in /Be84/ gefunden werden. Für verteilte Systeme ist das 2PL nicht mehr ausreichend. Hier wird üblicherweise zu einem 3PL übergegangen.

2.7.3.1.1 Verklemmungen (Dead-Lock)

Verklemmungen entstehen bei der Belegung eines Betriebsmittels durch mehrere Prozesse. /Da91/. Es ist ein Zustand in einem Prozesssystem, in dem mehrere Prozesse auf ein oder mehrere Ereignisse warten, die auf keinen Fall eintreten können. /We92/ Im Bereich der DBS sind Verklemmungen bei Transaktionen von Bedeutung. Falls einer Transaktion, welche auf die Freigabe einer Sperre einer anderen Transaktion wartet erlaubt ist, all ihre Sperren zu behalten, kann dies zu einer Verklemmung führen. Eine Beschreibung ist u.a. in /Ta94/ zu finden. Prinzipiell können gegen Verklemmungen die folgenden Maßnahmen durchgeführt werden /We93/:

• Vermeidung (avoidance), z.B. Bankers Algorithmus • Entdeckung (detection) • Verhinderung (prevention)

Allgemeine Beschreibungen sind u.a. in /Ta94/, /Be92/ zu finden. Eine gründliche mathema-tische Analyse ist u.a. in /We92/ nachzulesen.

2.7.3.2 Zeitstempel-Methoden (Timestamp methods)

Zeitstempel-Methoden unterscheiden sich grundlegend von Sperr-Methoden. Da keine Sperren auftreten, kann auch keine Verklemmungs-Situation auftreten. Während Sperr-Methoden sich beeinflussende Transaktionen verbieten, werden bei Zeitstempel-Methoden sich beeinflussende Transaktionen einfach zurückgesetzt.

Page 35: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 21

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.7.3.3 Optimistische Methoden (Optimistic methods)

Optimistische Methoden gehen von der Prämisse aus, dass Konflikte selten auftreten. Deshalb wird allen Transaktionen prinzipiell erst einmal ihre Arbeit erlaubt. Wenn die Trans-aktion den commit wünscht, prüft das System auf Konflikte und führt im Fall eines solchen die Transaktion noch einmal neu aus. Die Theorie der Transaktionen wird u.a. in /GaRö94/, /Vo95/, /Be92/, /Ch98/, /Gu96/, /Gu97/, /Ko01/ vertieft vorgestellt.

2.8 Recovery-Manager

Entscheidender Punkt aller Recovery-Verfahren muss sein, dass es keine Fehlersituation geben darf, bei der es zum Verlust von Daten kommt. Funktion des Recovery-Managers ist es, 2 der 4 A.C.I.D. Eigenschaften von Transaktionen einzuhalten (Dauerhaftigkeit, Atomizität). Dies geschieht mit Hilfe eines Recovery-Protokolls. Es existiert eine große Vielfalt solcher Protokolle. Prinzipiell kann man diese Protokolle in 2 große Kategorien einteilen /Be92/:

• Logging Protokolle Alle Veränderungen an der DB werden in einem separaten File (LOG) protokolliert. Dieses File wird im Falle eines Crashes zur Wiederherstellung der Konsistenz der DB verwendet. Diese Protokolle können noch einmal unterteilt werden:

o Wie werden die Informationen protokolliert?

physisch logisch

o Wie oft wird protokolliert?

before-image (BI)

Die Daten werden vor einer Veränderung protokolliert. In diesem Fall sind ausreichend Informationen vorhanden, um ein UNDO durchzuführen. Es sind jedoch nicht genügend Informationen für ein REDO vorhanden. Damit ist ein Schutz vor Systemfehlern vorhanden. Es ist kein Schutz vor Ver-lust oder Zerstörung der DB vorhanden.

after-image (AI) Die Daten werden nach einer Veränderung protokolliert. In diesem Fall sind ausreichend Informationen vorhanden, um ein REDO durchzuführen. Es sind jedoch nicht genügend Informationen für ein UNDO vorhanden.

Page 36: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 22

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Damit ist ein Schutz vor Media-Fehlern vorhanden. before-image und after-image (AI + BI)

Beide oben beschriebenen Verfahren werden mit allen Vor- und Nachteilen kombiniert.

• non-logging Protokolle

Diese Protokolle umgehen das Führen eines separaten LOG, indem sie sorgfältig die Daten kontrollieren, wenn sie geschrieben werden.

2.8.1 Fehlermöglichkeiten

Die vielen Fälle und Varianten von Fehlern können prinzipiell in 4 Kategorien eingeteilt werden /Be92/:

• lokale Transaktions-Fehler Dies sind Fehler, welche nur die einzelne Transaktion betreffen. Es existieren ver-schiedene Möglichkeiten:

o in der Transaktion veranlasster abort

Dieser Abbruch kann z.B durch den Programmierer direkt veranlasst werden. Der Recovery-Manager erhält direkt eine Anweisung, die Transaktion zurück-zusetzen.

o unvorhersehbarer Transaktionsfehler Er resultiert aus Fehlern in der Applikation (z.B. Division durch 0). In diesem Fall muss das System den Fehler entdecken und den Recovery-Manager ver-anlassen, die Transaktion rückgängig zu machen.

o durch das System veranlasster abort Dies geschieht, wenn der Transaktions-Manager eine Transaktion abbricht, z.B. bei einem Konflikt oder bei einer Verklemmung. Der Abbruch wird dem Recovery-Manager explizit mitgeteilt, es sind keine anderen Transaktionen betroffen (es sei denn, es wird eine Blockierung beseitigt).

In einem zentralen DBMS sind dies relativ simple Fehler. Die Fehlerbehebung erfolgt durch Rückspeichern der BIs der betroffenen Daten.

• Node-Fehler

Diese Fehler entstehen durch einen Fehler der lokalen CPU oder einen Fehler bei der Stromversorgung. Dadurch entsteht ein abnormales Ende des DBS (Absturz) und/oder des Betriebssystems. Alle Transaktionen auf diesem Node sind betroffen. Der Inhalt des Hauptspeichers (einschließlich aller Puffer) ist komplett verloren. Bei der weiteren Betrachtung wird davon ausgegangen, dass die DB auf der Festplat-te und die LOGs in Ordnung sind. Um einen konsistenten Zustand zu erreichen, muss mit Hilfe der AIs und BIs ein undo bzw. redo für die betroffenen Transaktionen durchgeführt werden. Der letzte bekann-te Zustand ist im letzten Checkpunkt festgehalten. Bei synchronen Checkpunkten ist

Page 37: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 23

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

dieser Zustand ein konsistenter Zustand. Bei asynchronen Checkpunkten muss die-ser Zustand nicht unbedingt konsistent sein. Nachdem die Funktionsfähigkeit nach einem Fehler wieder hergestellt ist, wird die Kontrolle an den Recovery-Manager übergeben, um die Recovery- oder Restart-Prozedur auszuführen. Während dieser Zeit werden keine neuen Transaktionen ak-zeptiert. Erste Aufgabe des Recovery-Managers ist es, den letzten Checkpunkt zu finden. Nach Abarbeitung der Liste der aktiven Transaktionen kann er entscheiden, für welche Transaktionen ein undo bzw. ein redo durchgeführt werden muss. Diese Art des Restarts wird auch als Notfall-Restart bezeichnet. Der Restart ist notwendig, wenn der Fehler ohne Warnung auftritt. Ein Kaltstart ist notwendig, wenn das System vom Archiv neu gestartet werden muss. Dies wird notwendig, wenn das LOG fehlerhaft ist. Da das LOG teilweise 2- oder 3-fach existiert, tritt dieser Fall sehr selten auf. Alle Änderungen nach der Archivierung sind verloren. Ein Kaltstart ist ebenfalls notwendig, wenn das System initialisiert wird. Ein Warmstart ist nach einem kontrollierten Shutdown notwendig. Nach dem Shut-down-Befehl wird keine neue Transaktion mehr gestartet. Das System wartet auf den Abschluss aller offenen Transaktionen. Danach werden alle Puffer auf die Festplatte geschrieben und das System beendet. Da beim Abschluss keine Aktivitäten mehr of-fen sind, besteht beim Neustart keine Aufgabe für den Recovery-Manager.

• Medium-Fehler

Verlust von DB-Files aufgrund von Plattenfehlern. Zur Vermeidung dieser Fehler hat man 2 Möglichkeiten zur Auswahl:

o Archivierung

Bei der Archivierung werden regelmäßige Backups der DB angelegt. Diese Backups bilden das Archiv. Wünschenswert ist es, das Archiv anzulegen, während das System steht. Ansonsten sind im Backup teilweise Änderungen enthalten. Dies erschwert das Recovery. Um ein Recovery durchzuführen, wird das aktuellste Archiv zurückgeladen. Danach werden alle bestätigten Transaktionen anhand des LOG und des AI nachvollzogen. Um die Archivierungszeit zu verkürzen, werden teilweise inkrementelle Archi-vierungsverfahren verwendet.

o Spiegelung

Spiegelung wird vor allem verwendet, wenn das System für eine Archivierung nicht gestoppt werden kann. Dabei existieren 2 komplette Kopien der DB auf der/den Festplatte(n). Um die Sicherheit zu erhöhen, sollten die 2 Kopien auf verschieden Festplatten mit separaten Festplatten-Kontrollern sein. Noch besser ist die Unterbringung in verschiedenen Räumlichkeiten. Lesezugriffe können auf einer von beiden Platten erfolgen. Schreibzugriffe müssen auf beiden Platten erfolgen. Wenn eine Platte einen Fehler aufweist, wird mit der anderen Platte weitergearbeitet. Wenn der Fehler behoben wur-de, wird die DB komplett auf die reparierte Platte kopiert und der alte Zustand ist damit wieder hergestellt /Beu96/.

Page 38: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 24

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• Netzwerk-Fehler Die korrekte Arbeitsweise von DDBMS oder Client-Server-Systemen ist davon ab-hängig, dass die Nodes miteinander kommunizieren können. Die meisten Netzwerke sind heute recht zuverlässig. Die Protokolle sorgen für das richtige Aussenden und die richtige Reihefolge der Daten. Im Fehlerfall sorgen viele Netzwerke für das auto-matische Re-Routing der Nachrichten. Hauptschwierigkeit des Systems ist es, zu erkennen, wann und wo ein Fehler aufge-treten ist. Mit Hilfe eines Timeouts kann man immerhin feststellen, ob das andere System in dieser Zeit antwortet. Wenn es nicht antwortet, ist immer noch unbekannt, ob die eigene Nachricht nicht angekommen ist, oder ob das andere System nicht antworten kann. Schwierig ist die richtige Zeitwahl des Timeouts. Sie muss mindes-tens der Zeit für die Übermittlung der Nachrichten plus der Zeit für das Bearbeiten der Anforderung entsprechen. Wenn die Agenten einer globalen Transaktion auf unterschiedlichen Nodes sind, bei denen ein Fehler auftritt und ein Agent ein commit, der andere ein abort auslöst, kann die Atomizität der globalen Transaktion zerstört werden. Grundsätzlich ist es nicht möglich, ein nichtblockierendes18 atomisches Commit-Protokoll für willkürlich partitionierte Netzwerke zu entwerfen /Be92/. Die Methoden der Protokolle können eingeteilt werden in:

o optimistische commit Protokolle o pessimistische merge Protokolle

2.8.2 LOG

Wenn ein Logging-Protokoll verwendet wird, dann werden Operationen, welche durch Transaktionen ausgeführt werden, im LOG vermerkt. Ein Eintrag wird mindestens bei folgenden Aktionen geschrieben:

• begin Transaktion • write (einfügen, löschen, ändern) • commit Transaktion bzw. abort Transaktion

Jeder Datensatz im LOG enthält die folgenden Informationen:

• Transaktions-Identifier alle Operationen

• Typ des Datensatzes alle Operationen

• Identifier des Datenobjekts, welches durch die DB-Aktion verändert wurde

einfügen, löschen, ändern

18 Ein nichtblockierendes Protokoll ist ein Protokoll, welches andere Nodes im Falle eines Fehlers nicht

blockiert.

Page 39: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 25

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• BI des Datenobjektes ändern, löschen

• AI des Datenobjektes ändern, einfügen

• Log-Management-Informationen (z.B. Pointer zum vorigen Datensatz)

alle Operationen

Oftmals wird das LOG auch zu anderen Zwecken als dem Recovery verwendet (z.B. für Performance-Anzeigen und Prüfungen). Da das LOG lebenswichtig für das DBS ist, wird es gewöhnlich dupliziert. Das Schreiben in das LOG kann mit zwei verschiedenen Methoden erfolgen:

• synchrones Schreiben: Es wird immer, wenn etwas in das LOG geschrieben wird, auch der richtige Datensatz geschrieben.

• asynchrones Schreiben: Es wird nur periodisch geschrieben, z.B. bei einem commit oder wenn die Puffer voll sind.

Es ist wesentlich, immer zuerst in das LOG zu schreiben und danach die eigentliche Schreiboperation in der DB auszuführen (write-ahead log protocol). Ansonsten können im Falle eines ungünstigen Absturzes Daten nicht mehr rekonstruiert werden.

2.8.3 Checkpunkte19

Eine der Schwierigkeiten des Recovery-Managers ist es zu entscheiden, wie weit im Falle eines Fehlers im LOG zurückgegangen werden muss. Um diese Suche zu beschränken, führt der Recovery-Manager zyklische Checkpunkte (CP) durch. Dadurch wird erreicht, dass ein eventuelles Recovery nur bis zum letzten CP durchgeführt werden muss. Der CP-Eintrag im LOG enthält alle notwendigen Informationen für das Recovery. Es existieren 2 Varianten:

• synchrone CP Während der Durchführung darf keine Transaktion aktiv sein. Bei serieller Transakti-onsausführung stellt das kein größeres Problem dar. Bei paralleler Transaktionsaus-führung ist es jedoch damit verbunden, dass entweder ein CP nicht durchgeführt werden kann (wenn gerade Transaktionen aktiv sind), oder der Start neuer Transak-tionen blockiert werden muss. Beides schränkt die Transaktionsausführung ein und bewirkt Performance-Nachteile.

19 Es existieren unterschiedliche Bezeichnungen. In Oracle werden die Checkpunkte z.B. als Savepoints

bezeichnet.

Page 40: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 26

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

t tCP F

T3

T2

T1

t

t

Bild 2.6: synchroner Checkpunkt

Die folgenden Aktionen werden ausgeführt:

o Die Adresse des CP-Datensatzes wird z.B. in ein spezielles File (restart-File) ge-

schrieben. o Alle Puffer werden in das LOG und in die DB geschrieben.

• asynchrone CP Der CP kann jederzeit durchgeführt werden. Der Vorteil, dass die Transaktionsaus-führung nicht beeinflusst wird, erkauft sich mit dem Nachteil, zusätzliche Informatio-nen über alle offenen Transaktionen zu sichern.

t tCP F

T1

T2

T3

T4

T5

Bild 2.7: asynchroner Checkpunkt

Page 41: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 27

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Die folgenden Aktionen werden ausgeführt: o Eine Liste aller aktiven Transaktionen wird in das LOG geschrieben. o Die Adresse des CP-Datensatzes wird z.B. in ein spezielles File geschrieben. o Alle Puffer werden in das LOG und in die DB geschrieben.

An Stelle des separaten restart-Files ist es auch möglich, z.B. im LOG selbst feste Adressen zu verwenden.

2.8.4 Lokale Recovery-Protokolle

Es existieren grundsätzlich 5 Varianten, wann ein CP und ein Fehler während der Transakti-onsabarbeitung auftreten können (siehe dazu auch Bilder Seite 26):

• Fall 1:

< <start endT T CPt t t (2.10)

Der CP sichert, dass alle Aktionen in der DB sind. (Dauerhaftigkeit)

• Fall 2:

< <start endT CP T Ft t UND t t (2.11)

Die Transaktion ist komplett, aber es muss ein redo ausgeführt werden (z.B. wenn die Objekte noch im Puffer sein müssten und eventuell verloren sind). Das redo nutzt das AI.

• Fall 3:

?< =start endT CP Tt t UND t (2.12)

Die Transaktion ist nicht beendet worden. Es muss ein undo durchgeführt werden. Dazu wird das BI verwendet.

• Fall 4:

< <start endCP T T Ft t UND t t (2.13)

Behandlung wie Fall 2.

• Fall 5:

?< =start endCP T Tt t UND t (2.14)

Behandlung wie Fall 3.

Page 42: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 28

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.8.4.1 Undo/redo - Funktionalität

Recovery-Manager, welche nach diesem Algorithmus arbeiten, sind am komplexesten, da sie undoing und redoing unterstützen. Der Vorteil dieses Verfahrens ist, dass der Puffer-Manager in der Lage ist zu entscheiden, wann er den Puffer frei gibt und wann nicht. Daher kann der I/O-Aufwand reduziert werden. Der Recovery-Manager führt auf folgende Aktionen die folgenden Antworten aus:

• begin Transaktion: Transaktion in die Liste der aktiven Transaktionen eintragen. Es wird ein Eintrag in das LOG vorgenommen.20

• read: Das Datenobjekt wird entweder aus dem DB-Puffer oder aus der DB in den Puffer gelesen. Ein Eintrag ins LOG ist nicht unbedingt notwendig.

• write: Das Datenobjekt wird geändert. In das LOG wird das BI ge-schrieben. Das AI kann geschrieben werden.

• commit: Es wird ein commit in das LOG geschrieben. Das AI wird nun unbedingt geschrieben, falls dies nicht schon bei write erfolgte.

• abort: Der Recovery-Manager muss ein undo ausführen21. Dazu muss er die geänderten Daten in den DB-Puffer lesen und die originalen Werte vom BI aus dem LOG eintragen. In das LOG wird der Abort eingetragen.

• restart: Der Recovery-Manager führt ein redo für alle Transaktionen, welche committet wurden, aus. Für die anderen Transaktio-nen wird ein undo ausgeführt. Prinzipiell kann hier das gesamte LOG durchgearbeitet werden. Bei der Verwendung von CPs wird jedoch der Aufwand enorm vermindert, da am letzten CP angesetzt werden kann.

Es ist möglich, eine active-Liste, abort-Liste und commit-Liste zu halten. Bei einem Restart ist es einfach zu entscheiden, ob ein undo (abort-Liste) oder ein redo (commit-Liste) -notwendig ist.

2.8.4.2 Undo/no-redo - Funktionalität

Bei Verwendung dieses Algorithmus werden die DB-Puffer bei einem commit geleert. Deshalb ist ein redo niemals notwendig. Daher entfallen ebenfalls die AI. Der Recovery-Manager muss nicht die Fälle 3 und 5 behandeln.

20 Effiziente Systeme schreiben erst, wenn die Transaktion ihren ersten Schreibvorgang ausführt. Dies sollte

eine eigene Lösung natürlich beachten. 21 Das undo ist nur bei in-place updating notwendig.

Page 43: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 29

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

­ Es müssen alle veränderten Daten im RAM gehalten werden. Damit ist die Transakti-onsgröße beschränkt.

­ Da die Puffer bei einem commit geleert werden müssen, können Performance-Nachteile entstehen.

­ Plattenfehler sind nicht behebbar.

• begin Transaktion: Transaktion in die Liste der aktiven Transaktionen eintragen. Es wird ein Eintrag in das LOG vorgenommen.22

• read: Das Datenobjekt wird entweder aus dem DB-Puffer oder aus der DB in den Puffer gelesen. Ein Eintrag ins LOG ist nicht unbedingt notwendig.

• write: Das Datenobjekt wird geändert. In das LOG wird das BI ge-schrieben.

• commit: Alle DB-Puffer werden geleert und ein commit-Datensatz wird in das LOG geschrieben. Wenn alternativ eine commit-Liste geführt wird, dann wird der Transaktion-Identifier nur in die Liste eingefügt.

• abort: Der Recovery-Manager muss ein undo ausführen. Dazu muss er die geänderten Daten in den DB-Puffer lesen und die originalen Werte vom BI aus dem LOG eintragen. Eintrag des abort-Datensatzes ins LOG.

• restart: Der Recovery-Manager führt ein globales undo aus.

2.8.4.3 No-undo/redo - Funktionalität

Bei Verwendung diese Algorithmus werden keine uncomitted Transaktionen in die DB geschrieben. Der Puffer-Manager muss alle Datensätze im RAM halten, bis ein commit kommt. Dies wird auch als pinning der Puffer bezeichnet. Alternativ können die Daten in das LOG geschrieben werden oder es wird shadowing verwendet. Der Recovery-Manager hat nur die Fälle 2 und 4 zu behandeln.

­ Es müssen alle veränderten Daten im RAM gehalten werden. Damit ist die Transakti-onsgröße beschränkt.

• begin Transaktion:

Transaktion in die Liste der aktiven Transaktionen eintragen. Es wird ein Eintrag in das LOG vorgenommen.23

• read: Das Datenobjekt wird entweder aus dem DB-Puffer oder aus der DB in den Puffer gelesen. Ein Eintrag ins LOG ist nicht unbedingt notwendig.

22 Effiziente Systeme schreiben erst, wenn die Transaktion ihren ersten Schreibvorgang ausführt. 23 Effiziente Systeme schreiben erst, wenn die Transaktion ihren ersten Schreibvorgang ausführt.

Page 44: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 30

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• write: Wenn das LOG für Änderungen verwendet wird, dann wird das AI vom Datensatz oder vom Puffer in das LOG einge-fügt.

• commit: Entweder hat der Puffer-Manager seine Puffer zu leeren oder, wenn Änderungen in das LOG geschrieben werden, dann müssen die AIs der geänderten Daten über die Puffer in die DB geschrieben werden. Der commit-Datensatz muss in das LOG geschrieben oder in die commit-Liste eingefügt werden.

• abort: Wenn Änderungen in das LOG geschrieben werden, dann wird ein abort-Identifier in das LOG oder in die abort-Liste geschrieben. Wenn die Änderungen im Puffer durchgeführt werden, dann werden sie gelöscht und ein abort-Datensatz in das LOG oder die abort-Liste geschrieben.

• restart: Es muss ein globales undo durchgeführt werden.

2.8.4.4 No-undo/no-redo - Funktionalität

Um das undo von Transaktionen zu vermeiden, muss der Recovery-Manager dafür sorgen, dass keine Änderung vor einem commit in die DB geschrieben wird. Um das zu erledigen, ist shadowing notwendig. Änderungen werden in neue Bereiche der DB geschrieben und die Adressen in einer Shadow-Liste vermerkt. Bei einem commit sind lediglich die Adressen der Indizes auf die neuen Adressen zu setzen. Für einen Restart ist nichts notwendig. Die BIs und AIs werden in der DB selber gespeichert. Ein separater LOG-Eintrag ist eigentlich nicht notwendig.

­ Die DB wird sehr fragmentiert. Sie wächst physisch immer mehr an. Dadurch können die Zugriffszeiten immer länger werden. Um diese Nachteile zu beheben, müssen Defragmentierer implementiert werden.

• begin Transaktion: Transaktion in die Liste der aktiven Transaktionen eintragen.

Es wird ein Eintrag in das LOG vorgenommen.24 • read: Das Datenobjekt wird entweder aus dem DB-Puffer oder aus

der DB in den Puffer gelesen. Ein Eintrag ins LOG ist nicht unbedingt notwendig.

• write: Änderungen werden über die Puffer in einen ungenutzten Bereich der DB geschrieben und die Adressen in der Shadow-Adressliste gespeichert.

24 Effiziente System schreiben erst, wenn die Transaktion ihren ersten Schreibvorgang ausführt.

Page 45: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 31

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• commit: Die DB-Puffer werden in den Shadow-Bereich gespielt. Die Indizes werden auf den Shadow-Bereich gesetzt und ein commit-Datensatz wird in das LOG geschrieben oder der Transaktion Identifier in die commit-Liste eingefügt.

• abort: Die Transaktion wird von der Shadow-Adressliste entfernt. Ein abort-Datensatz wird in das LOG oder in die abort-Liste eingefügt.

• restart: Die Shadow-Adress-Liste wird komplett verworfen.

Eine Beschreibung verteilter Recovery-Protokolle (2PC, 3PC) kann u.a. in /Be92/, /Be94/ gefunden werden. Als weiterführende Literatur ist u.a. /Be97/, /Ko01/ zu empfehlen.

2.9 Zugriffsmethoden auf Daten

Für das DBS und insbesondere den Nutzer des DBS ist es wesentlich, dass die vorhande-nen Daten und Files so organisiert sind, dass die Operationen auf das DBS effizient durch-geführt werden können. Die Operationen, die ein Nutzer am DBS vornimmt, können auf die DBS-Grundoperationen Suchen, Einfügen, Löschen und Ändern (Ändern kann durch Löschen und Einfügen ersetzt werden, eine direkte Implementierung ist jedoch effektiver) transformiert werden. Dabei ist zu beachten, dass das Einfügen, Löschen und Ändern immer auf einem Suchen aufbaut. Aus Gründen der Übersichtlichkeit wird dies aber in den folgen-den Formeln nicht berücksichtigt. Die genannten DBS-Grundoperationen basieren wiederum auf den aus Abschnitt 2.7 (Seite 16) bekannten Grundoperationen Lesen und Schreiben. Grundsätzlich können die Zugriffsverfahren in mehrere Kategorien eingeteilt werden. Diese Verfahren können in allen Informatik-Grundlagenbüchern, z.B. /Se92/, nachgelesen werden. Bei sehr großen Datenmengen ist es nicht mehr möglich, alle Daten im Hauptspeicher des Rechners zu halten. Hier müssen die Daten auf anderen (langsameren) Speichermedien gehalten werden. Da die Geschwindigkeitsdifferenzen zwischen RAM und Festplatte sehr groß sind25, bieten sich hier Suchverfahren an, welche mit möglichst wenig Zugriffen auf die Festplatte auskommen. Verfahren, welche dieses Prinzip beachten, werden externe Such-verfahren genannt. Eine ausführliche Beschreibung der Suchstrategien ist u.a. in /Se92/, /We80/ zu finden. Bei der Auswahl der Zugriffverfahren besteht generell die Möglichkeit, zwischen Indexing und Hashing zu unterscheiden. Im Folgenden wird für einige ausgewählte Zugriffsverfahren eine Angabe über die Häufigkeit der externen Zugriffe gegeben. Die Angabe dieser Zahlen spielt eine wesentliche Rolle für die weitere Arbeit. Es ist jedoch Folgendes zu beachten:

25 Zugriffszeiten von guten Festplatten ca. 7ms (zur Zeit der Realisierung der vorliegenden Arbeit ca. 10 ms)

FPM-RAM 60-70ns, 40ns; EDO-RAM 60-70ns, 25ns; SDRAM 60-70ns, 8ns (Bei Intel x86 Boards zur Zeit der Realisierung max. 133MHz Systemtakt, 8ns erst mit 125MHz nutzbar) /CHIP/.

Page 46: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 32

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Ein Zugriff kann nicht unbedingt mit einem Festplattenzugriff in Übereinstimmung gebracht werden. Die Anzahl der exakten Festplattenzugriffe hängt unmittelbar von der Größe des angeforderten Blockes (Datensatzes) und der Größe der einzelnen Puffer ab:

( ) ( )( )( )max 2* 1 1 *2= − +HD sof DS DIV sof Puffer (2.15)

Da ein Datensatz genau über die Puffergrenze hinausgehen kann, ist jeweils 1 zu addieren. Um die Puffer von der Platte zu laden ist u.U. ein Puffer freizugeben und damit auf Platte zu sichern. Für die folgenden Angaben gelten daher in diesem Abschnitt Einschränkungen: F 3: Für lesende Zugriffe ist immer ein freier Puffer vorhanden. F 4: Ein Block ist immer in maximal einem Puffer. Die Festplattenzugriffe sind immer Zugriffe auf die DB. Lesende oder schreibende Zugriffe auf LOG, BI und AI sind nicht notwendig. Sie werden daher alle zu Null gesetzt. Eine Trennung in lesende und schreibende Zugriffe ist sinnvoll, da Caches oder RAID-Systeme lesende Zugriffe im Allgemeinen schneller ausführen als schreibende Zugriffe /Ic97/.

0= = =AI BI LOGHD HD HD (2.16)

Für die nächsten Abschnitte werden die folgenden Symbole definiert: F 5: DSn : Anzahl der Datensätze BF : Blockungsfaktor (Datensätze pro Block)

2.9.1 Sequentielle Zugriffsmethoden

Die einfachste Speicherungsform für ein File ist die sequentielle Organisation. Dabei erfolgt ein Einfügen von Daten immer am Ende der Datei. Diese Organisation ist gleichzeitig auch die einzige Methode, welche auf sequentiellen Speichern möglich ist.

, 2= DS

L DBnHD (2.17)

Die Formel (2.17) gilt jedoch nur bei gleichhäufigem Suchen von jedem Schlüssel. Mit iP als

Wahrscheinlichkeit für das Aufsuchen des Schlüssels is auf der Position i gilt:

,1

DSn

L DB ii

HD i P=

= ∑ (2.18)

min, 1L DBHD = (2.19)

Page 47: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 33

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

max,L DB DSHD n= (2.20)

Da die Datensätze üblicherweise in Gruppen (Blöcken) zusammengefasst werden, gilt weiterhin Folgendes:

, 2= DS

L DBnHDBF

(2.21)

Die physisch sequentielle Organisation wird in der Literatur auch als HEAP-Methode be-zeichnet. F 6: alle Blöcke sind gleichmäßig mit 0M Datensätzen belegt

Zugriffsart je Satz keine logisch sequentielle Verarbeitung

Speicherökonomie anfangs fast 100%; Falls der Platz von gelöschten Datensät-zen nicht wiederverwendet wird, sinkt die Effizienz allmählich.

Reorganisation ist notwendig, wenn nicht schon beim Löschen implementiert oder der Platz der gelöschten Datensätze wiederverwendet wird.

Suchen Datensatz für Datensatz bis zum Treffer

min, 1L DBHD = (2.22)

max,0

1 1DSL DB

nHDM

⎡ ⎤−= +⎢ ⎥⎣ ⎦

(2.23)

,02

DSL DB

nHDM

= (2.24)

Anlegen im letzten Block am Ende des Bestandes; Es ist vorher keine Suche erforderlich, da nicht sortiert wird. Bei Überlauf ( 0 1m M= + ) wird neuer freier Block angekettet.

min, 1S DBHD = (2.25)

max, 2S DBHD = (2.26)

Page 48: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 34

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Löschen logisches Löschen: Der Datensatz erhält nur eine Löschkennung. Er muss vorher gesucht werden.

min, 1=S DBHD (2.27)

max, 1=S DBHD (2.28)

physisches Löschen: Block wird mit Leerzeichen überschrieben oder die Datensätze werden verschoben. Der DS muss vorher gesucht werden.

min, 1=S DBHD (2.29)

max,0

1 1⎡ ⎤−

= +⎢ ⎥⎣ ⎦

DSS DB

nHDM

(2.30)

Tabelle 2.3: Zugriff über Heap

2.9.2 Einstufige Indexdatei

Eine Verbesserung des Suchaufwandes kann man erreichen, wenn ein Index (zusätzliches Inhaltsverzeichnis) mit Schlüssel und Adresse des Datensatzes angelegt wird. Man unter-scheidet dichte (dense) und dünne (sparse) Indizes. In dichten Indizes ist für jeden Datensatz genau ein Wert abgelegt (auch bei identischem Schlüssel). Zugriffsfunktion Satz über Hauptschlüsselwert

Zugriffsart je Satz sequentiell oder wahlfrei

Anzahl von Blocktransfers max: 1ld n +

Speicherökonomie sehr gut

Änderungsaufwand befriedigend Tabelle 2.4: Zugriff über einstufige Indexdatei Beim binären Suchen sind dann nur noch:

, 2log DSL DB

nHDB

= (2.31)

Zugriffe notwendig.

Page 49: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 35

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.9.3 Inverse Datei

Bei einer inversen Datei (oft auch als invertierte Liste bezeichnet), werden für Werte eines Attributes, welches kein Schlüssel ist, nicht nur eine, sondern alle Adressen gespeichert. Man spricht daher auch von einem „vervollständigten” Index. Zugriffsfunktion Satzmenge über logischen Ausdruck

Zugriffsart je Satz mengenweise

Anzahl von Blocktransfers abhängig vom Indexsuchaufwand

Speicherökonomie gut

Änderungsaufwand befriedigend Tabelle 2.5: Zugriff über inverse Datei

2.9.4 Multilistendateiorganisation

Zugriffsfunktion Satzfolge

Zugriffsart je Satz listenweise

Anzahl von Blocktransfers maximal 1 + Satzanzahl

Speicherökonomie sehr gut

Änderungsaufwand hoch Tabelle 2.6: Zugriff mittels Multilistendateiorganisation

2.9.5 Hash

Hash-Verfahren versuchen, die Datensatz-Adressen anhand der Schlüssel zu errechnen. Es existiert eine Vielzahl von Varianten /Vo87/, /Vo95/. Zugriffsfunktion Satz über Hauptschlüsselwert

Zugriffsart je Satz wahlfrei logisch sequentiell wird nicht unterstützt

Anzahl von Blocktransfers minimal 2

Speicherökonomie gut (befriedigend)

Änderungsaufwand gering

statische HASH-Organisation mit Divisionsrest-Methode: Suchen

min, 1=L DBHD (2.32)

Page 50: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 36

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

max, ?=S DBHD (2.33)

Anlegen min, 1=S DBHD (2.34)

max, 2=S DBHD (2.35)

Löschen , 1=L DBHD (2.36)

Extendible Hashing: Suchen

, 2=L DBHD (2.37)

Anlegen min, 1=S DBHD (2.38)

max, ?=S DBHD (2.39)

Löschen min, 1=S DBHD (2.40)

max, ?=S DBHD (2.41)

Tabelle 2.7: Zugriff über Hash-Verfahren

2.9.6 ISAM26

Unter ISAM versteht man eine Klasse von Organisationsmethoden, welche logisch sequen-tielle Verarbeitung genauso unterstützen wie schnelle Lese-Zugriffe über Index. Es wird Organisation mit statischem Index betrachtet. F 7: Stufen: i kleinster Schlüsselwert im Wurzel-Index: mins aufsteigende Sortierreihenfolge statischer Bestand (Wurzel-Index im Hauptspeicher) Zugriffsart je Satz Logisch sequentiell wird unterstützt

Speicherökonomie Zusätzlicher Platz wird für mehrstufigen Index benötigt. Die Blöcke sind meist nur zu 50% belegt. Bei großen statischen Beständen effizient, dynamische Bestände besser mit B+-Bäumen

Suchen , =L DBHD i (2.42)

26 ISAM: Indexed-Sequential Access Method

Page 51: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 37

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Anlegen , =L DBHD i (2.43)

min, 1=S DBHD (2.44)

max, 2=S DBHD (2.45)

Löschen , 1=S DBHD (2.46)

Tabelle 2.8: Zugriff über ISAM

2.9.7 B-Baum

Die Baum-Verfahren sind heute der de facto Standard bei externen Suchverfahren. Sie wurden von R. Bayer und E. McCreight 1972 vorgestellt. Ein B-Baum (balanced sort tree) besitzt immer eine Ordnung (order). Die Ordnung ist die Anzahl der Schlüssel (keys) in jedem Knoten (node). F 8: In der Literatur ist diese Festlegung nicht einheitlich. Es existieren auch Festlegun-

gen, dass die Ordnung der halben Anzahl Keys im Node entspricht. Im Folgenden wird jedoch von einer maximalen Belegung von M Schlüsseln ausgegangen.

Die Gruppierung wird verwendet, um die Zugriffszeiten auf die Festplatte zu minimieren. Der oberste Knoten in der Hierarchie ist der Wurzel-Knoten (root-Node). Knoten, welche keine Zeiger auf weitere Knoten enthalten, heißen leaf-Knoten. F 9: Ordnung: M 0>M Tiefe: h 1≤ ≤ ∞h Anzahl zufälliger Daten im Node: n Gesamtzahl der Datensätze: DSn Ein B-Baum ist durch folgende Eigenschaften charakterisiert:

• Der Weg vom Wurzel-Knoten zu einem beliebigem leaf-Knoten ist immer gleich lang. • Jeder Knoten besitzt höchstens 1M + Kind-Knoten (child-Node).

• Jeder Knoten (außer dem Wurzel-Knoten) besitzt mindestens 2M

Kind-Knoten.

• Der Wurzel-Knoten besitzt entweder keinen Kind-Knoten oder mindestens 2.

• In jedem Knoten (außer dem Wurzel-Knoten) befinden sich immer zwischen 2M

und

M Schlüssel.

Page 52: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 38

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Zugriffsart je Satz logisch sequentiell nur bedingt unterstützt (Die Blöcke in den höheren Ebenen müssen dazu u.U. mehrfach angepackt werden.)

Reorganisation nicht notwendig

Suchen min, 1=L DBHD (2.47)

max, =L DBHD h (2.48)

max, logL DB M DSHD n< (2.49)

Anlegen27 Einfügen

Fall 1: 0n M M< = Der Datensatz kann sofort eingefügt werden

, 1=S DBHD (2.50)

Fall 2: n M= (Überlauf) Die Anzahl der Datensätze sprengt den Block, es muss Block-splitting durchgeführt werden.

Die ersten 2M

Datensätze bleiben im aktuellen Block, die letz-

ten 2M

Datensätze kommen in einen neu anzufordernden

Block. Der verbleibende mittlere Datensatz wird zusammen mit den Adressen der beiden Blöcke in den parent eingefügt. Dies kann wiederum zu einem Überlauf führen. Im ungünstigsten Fall muss ein neuer root-Knoten angelegt werden.

min, 1=L DBHD (2.51)

max, =L DBHD h (2.52)

min, 1=S DBHD (2.53)

max, 2 1= +S DBHD h (2.54)

27 n ist die Anzahl vor dem Einfügen

Page 53: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 39

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Löschen28 Fall 1:

2Mn ≥

min, 1=S DBHD (2.55)

max, 2=S DBHD (2.56)

, =L DBHD h (2.57)

Fall 2: 12Mn = −

Ballance-Kriterium verletzt, der Block wird mit einem seiner beiden Nachbarn und dem Schlüssel aus dem parent ver-knüpft. Die Anzahl n′ der zusammengefassten Schlüssel genügt der Abschätzung:

1 1 1 12 2 2

1.5

M M Mn M

M n M

⎛ ⎞ ⎛ ⎞′− + + ≤ ≤ − + +⎜ ⎟ ⎜ ⎟⎝ ⎠ ⎝ ⎠

′→ ≤ ≤

Fall 2.1: n M′ > Die n′ Schlüssel werden in die beiden Knoten verteilt. Der mittlere Schlüssel wird in den parent anstelle des ursprüngli-chen eingetragen.

, 3=S DBHD (2.58)

Fall 2.2: n M′ = Ein Block wird eliminiert. Der parent muss ebenfalls auf Fall 2 geprüft werden.

[ ], 2 3

1

= − +

= +S DBHD h

h (2.59)

, 2 1= −L DBHD h (2.60)

Tabelle 2.9: Zugriff mit B-Baum-Verfahren

28 n ist die Anzahl nach dem Löschen

Page 54: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 40

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Die Anzahl der Einträge in einem B-Baum kann mit den folgenden Formeln berechnet werden:

( )

( )

,max1

* 1

1 1

hi

DSi

h

n M M

M=

= +

= + −

∑ (2.61)

( )1

,min1 1

2

h

DSMn

−+⎛ ⎞= −⎜ ⎟⎝ ⎠

(2.62)

Entsprechend lassen sich auch Werte für die Anzahl der Nodes angeben:

( )

( )

max1

1

1 1 1

ni

i

h

K M

MM

=

= +

= + −

∑ (2.63)

min1

2 1 11 2

ni

i

h

K M

MM

=

=

⎡ ⎤+⎛ ⎞= −⎢ ⎥⎜ ⎟− ⎝ ⎠⎢ ⎥⎣ ⎦

∑ (2.64)

2 DSnKM

⎛ ⎞= ⎜ ⎟⎝ ⎠

(2.65)

Umgekehrt lässt sich aus der Anzahl der Einträge im B-Baum dessen Tiefe ermitteln:

( ) ( )( )

( )( )

,maxmin

,max

1 21

1

11

DS

DS

ln n lnh

ln M

ld nld M

⎡ ⎤+ −= +⎢ ⎥

+⎢ ⎥⎣ ⎦

+=

+

(2.66)

( )( )max

12 1

+=

+ln n

hln M

(2.67)

( )( )min 12 1

DSln nh

ln M⎡ ⎤

= +⎢ ⎥+⎣ ⎦ (2.68)

( ) ( )( )max

1 21

1DSln n ln

hln M

⎡ ⎤+ −= +⎢ ⎥+⎣ ⎦

(2.69)

Page 55: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 41

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

2.9.8 B+-Baum

B+-Bäume sind eine Weiterentwicklung der B-Bäume. Sie sind heute die am weitesten verbreiteten Indizes in DBs. Während in den normalen B-Bäumen jeder Schlüssel nur einmal vorkommen kann, sind in einem B+-Baum alle Schlüssel in den Leaf-Nodes. In den Inner-Nodes befinden sich Kopien der Schlüssel. Der Overhead beim Speichern und beim Einfü-gen und Löschen von Schlüsseln bringt dafür Vorteile beim Ändern von Daten. weitere Eigenschaften:

+ Leaf- und Inner-Nodes haben die gleiche Größe (in einem B-Baum sind die Inner-Nodes größer). Das vereinfacht die Programme.

+ Das Löschen in einem B-Baum ist komplizierter, da sich der Schlüssel in einem In-ner-Node befinden kann.

Zugriffsfunktion Satz über Hauptschlüsselwert Zugriffsart je Satz sequentiell oder wahlfrei

logisch sequentiell wird voll unterstützt Anzahl von Blocktransfers

2DSnlde

ld d+ 29 (2.70)

Speicherökonomie befriedigend Änderungsaufwand gering Reorganisation nicht notwendig Suchen

,L DBHD h= (2.71)

Anlegen min, 1S DBHD = (2.72)

max, 2 1S DBHD h= + (2.73)

29 Blockungsfaktor für Blattknoten (mit Datensätzen): 2d-1; Blockungsfaktor für innere Knoten (mit Indexein-

trägen): 2e-1

Page 56: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Wissensstand Seite 42

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Löschen min,L DBHD h= (2.74)

max, 2 1S DBHD h= − (2.75)

min, 1S DBHD = (2.76)

max, 1S DBHD h= + (2.77)

Tabelle 2.10: Zugriff mit B+-Baum-Verfahren

2.9.9 Zusammenfassung

Anhand der aufgelisteten und bei weitem nicht vollständigen Beispiele ist ersichtlich, dass die unterschiedlichsten Organisationen existieren. Jede Organisation besitzt Stärken und Schwächen. Einige Methoden lassen keine maximalen Aussagen über Zugriffe zu und sind daher für Echtzeitsysteme nicht geeignet, obwohl sie in den meisten Fällen sehr schnell sind. Fast alle Methoden lassen sich verändern, um gewünschte Eigenschaften besser zu erzie-len. Die verschiedenen Zugriffsmethoden sind u.a. in /We95/, /GaRö96/ und /Vo87/ vorgestellt.

Page 57: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 43

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

3 Lösungskonzepte

3.1 Wahl des Betriebssystems

In den Vorüberlegungen der Einleitung wurde u.a. bemerkt, dass das System portabel sein sollte. Dies bedeutet, dass möglichst keine Festlegung auf ein bestimmtes Betriebssystem erfolgt. Trotzdem soll dieser Punkt an dieser Stelle näher betrachtet werden. Da für ein verteiltes Automatisierungssystem automatisch auch ein verteiltes oder Client-Server-DBS gegeben ist, muss generell zwischen Betriebssystem für Clients und Betriebs-system für Server unterschieden werden. Eine Analyse der Funktionalitäten von Clients und Server führt zu dem Schluss, dass ein Client nicht unbedingt ein Betriebssystem benötigt. Als wesentliche Aufgabe ist nur die Kommunikation mit dem Automatisierungssystem und die Kommunikation mit dem DBS-Server vorhanden. Dies kommt auch der in der Einleitung gestellten Anforderung entgegen, das DBS auf Mikrokontrollern zu implementieren. Es erfolgt lediglich die Einschränkung, dass nur der Client auf dem Mikrokontroller implementiert wird. Es ist daher keine Wahl eines speziellen Betriebssystems notwendig. Da der Server u.a. die Aufgabe der Speicherung der Daten besitzt, ist auf jeden Fall eine Hardware mit genügend Speicher notwendig. Aus Kostengründen empfiehlt sich hier die Nutzung eines PC oder einer Workstation, wobei bei Betrachtung der Kosten, der Verbrei-tung und der Verfügbarkeit ein PC sicherlich die bessere Wahl darstellt /Ep97/. Für PCs existieren nun die verschiedensten Betriebsysteme. Die Wahl des richtigen Be-triebssystems ist wieder ein Kompromiss zwischen Kosten, Leistungsfähigkeit, Funktionalität und Sicherheit. Realzeit-Systeme besitzen heute fast alle notwendigen Funktionalitäten wie Netzwerkanbin-dungen und grafische Nutzerschnittstellen. Diese Systeme sind jedoch meist sehr teuer. MS-Windows besitzt zwar fast jede erdenkliche Funktionalität, es ist jedoch nicht realzeitfä-hig. Des Weiteren wird dieses System als nicht sehr stabil eingestuft (außer NT, 2000) und ist daher nicht für Dauerbetrieb geeignet. Für DOS existiert bereits heute kaum noch Unter-stützung. Eine Sonderrolle spielt hier das in Quellen frei verfügbare Betriebssystem Linux. Es ist kostenlos verfügbar, besitzt alle Stabilitätsvorteile eines UNIX-Systems und unterstützt die verschiedenste Hardware und Features (bereits heute direkte Java-Unterstützung durch den Kernel, Realzeit-Funktionalitäten, RAID, ...). Die verschiedensten Entwicklungswerkzeuge sind vorhanden. Die rasante Entwicklung dieses Systems in den letzten Jahren führt trotz des Widerstandes der Konkurrenz zu immer mehr Akzeptanz. Immer weitere große Firmen setzen Linux als Alternative ein (z.B. IBM, Corel, Siemens, ...). Aufgrund der genannten Vorteile wird Linux im Folgenden als Basis-Betriebssystem für das zu entwickelnde DBS bevorzugt. Trotzdem wird, sofern möglich, die Kompatibilität zu anderen Betriebssystemen gewahrt.

Page 58: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 44

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

3.2 Fileorganisation des DBS

Da ein Einfügen in eine Datei recht aufwändig und langsam ist, sollte dies vermieden werden. Man kann dies verhindern, indem man neue Datensätze immer am Ende der Datei anhängt. In diesem Fall ist aber eine Indexverwaltung oder Verzeigerung erforderlich, da die einzelnen Datensätze kreuz und quer verteilt sind. Wenn man davon ausgeht, dass für jede Datei ein Index existiert und im Index die Adresse des Datensatzes steht, dann kann mit einer Datendatei gearbeitet werden und alle neuen Datensätze werden am Ende angehängt. Problem: Beim Löschen von Datensätzen entstehen Lücken und die Datei wird immer

größer. Lösung: Es muss von Zeit zu Zeit ein Reorganisationslauf über die DB durchgeführt

werden. Vorteile einer einzelnen Datei:

+ Die Übersichtlichkeit im Betriebsystem ist gegeben. + Es existiert nur eine Datenstruktur für Dateiverwaltung. + Es muss nur eine Datei geöffnet und geschlossen werden. + Es können keine Inkonsistenzen durch Verändern einzelner Dateien auftreten. + Es können Betriebssystembefehle für Aufgaben wie Backup, ... verwendet werden. + Da viele Betriebssysteme nur eine bestimmte Anzahl von Dateien gleichzeitig öffnen

können, kann man schnell an Systemgrenzen geraten. Nachteile:

­ Einfügen in eine Datei ist recht aufwändig, da der komplette Rest nach hinten ver-schoben werden muss. Hier hat man bei Verwendung von mehreren Dateien u.U. Vorteile.

­ Es kann nur mit Hilfe von Verwaltungen auf die einzelnen Datensätze zugegriffen werden.

­ Die Datei ist unübersichtlicher als mehrere kleine Dateien. ­ Der Zugriff auf einzelne Datensätze ist komplizierter (bei einzelnen Dateien mit fester

Datensatzgröße ist die Positionsbestimmung eines Datensatzes einfach).

Page 59: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 45

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

3.3 Redundanz

3.3.1 Zeiger und Schlüssel30

In der praktischen Arbeit spielt besonders das Problem der Zeiger eine große Rolle. Obwohl es theoretisch günstig ist, mit Zeigern zu arbeiten, ist es in der Praxis sehr unhandlich, über mehrere Zeiger auf eine andere Tabelle zu gelangen, sofern das vom System nicht automa-tisch unterstützt wird. Allgemeines Ziel sollte es sein, so viel wie möglich an Aufgaben durch das System zu erledigen. Nur so ist es möglich, manuelle Fehler zu eliminieren. Für ein komfortables Arbeiten sollte der Benutzer nach der Definition der Zeiger von ihnen nichts mehr bemerken. Dies kann durch folgende Implementierungen erreicht werden: Es existieren 2 Arten von Tabellen: Stammdatentabellen und Listentabellen. In den Stammdatentabellen werden die eigentlichen Daten gehalten. Diese Daten sind eindeutig. Jeder Datensatz kann damit über eine eindeutige Zuordnung (Datensatznummer oder ID) angesprochen werden. In den Listentabellen erfolgen die Zuordnungen. In den Zuordnungsfeldern (Join) existieren Zeiger auf die Beziehungstabelle (Zeiger auf Datensatz). Für die Listentabellen können nun eigene Zugriffsfunktionen geschrieben werden. So wird z.B. bei einem DISPLAY nicht der Zeigerwert angezeigt, sondern direkt der Stammdaten-satz. Falls ein Zeiger auf eine weitere Listentabelle zeigt, so muss der Zeiger verfolgt werden, bis ein Zeiger auf Stammdaten vorhanden ist.

30 Die Begriffe Zeiger und Schlüssel werden bei DBS meist vermischt und bedeuten das selbe. Im eigentli-

chen Sinn enthalten Zeiger die genaue Adresse, während Schlüssel eine Kennnummer enthalten. (Der Zeiger ist im relationalen Modell kein Zeiger mit einer physischen Adresse, sondern ein Schlüssel.)

Page 60: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 46

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Im Folgenden wird dies am Beispiel einer Stückliste gezeigt: Beispiel 3.1:

Komplexe DB-Strukturen enthalten sehr viele Beziehungen der Tabellen untereinander. Zum Aufbau einer solchen Beziehung zwischen 2 oder mehreren Tabellen muss ein Beziehungs-feld in jeder Tabelle erstellt werden. Dies geschieht im Allgemeinen durch die Definition des gleichen Wertes für jede Tabelle. Damit ist man an einem Konfliktfall angelangt. Man kann als Beziehungsfeld entweder direkt den Datenwert speichern oder man benutzt Zeiger. Im ersten Fall baut man damit Redundanzen auf. Unter Umständen (bei falscher Verwaltung) können damit in den verschiedenen Tabellen verschiedene Werte stehen (z.B. bei einem Absturz während einer Änderung oder einem fehlerhaften Programm, welches nicht alle Daten aktualisiert). Des Weiteren muss bei einer Änderung der Daten diese in allen Tabellen erfolgen. Vorteil ist, dass in einem Datensatz alle notwendigen Daten vorhanden sind. Im zweiten Fall werden Redundanzen verhindert, dafür muss beim Zugriff auf die Daten erst über die Zeiger auf die andere Tabelle positioniert werden. Dadurch können Probleme in der Zugriffsgeschwindigkeit entstehen. Weiterhin müssen komplizierte Algorithmen (u.U. rekursi-ve Algorithmen) entwickelt werden, um die Zeiger zu verfolgen. In der folgenden Tabelle erfolgt eine Gegenüberstellung der Vor- und Nachteile.

Es existieren 3 Tabellen:

• der Artikelstamm (Stammdaten) • der Stücklistenkopf (Liste) • die Stücklistenpositionen (Liste)

Stücklistenköpfe

Stücklistenpositionen

Artikel-stamm

Im Stücklistenkopf wird ein Zeiger auf den Artikelstamm angelegt. In den Stücklistenpositionen wird je ein Zeiger auf den Stücklistenkopf und ein Zeiger auf den Artikelstamm angelegt. Damit erreicht man über den ersten Zeiger und den Zeiger des Kopfes auf den Artikel-stamm den Artikel, welcher die Baugruppe kennzeichnet. Über den zweiten Zeiger erreicht man den Artikel, welcher die Stücklistenposition charakterisiert.

Page 61: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 47

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Aktion Datenwert Zeiger Der Wert muss in allen Tabellen ge-

ändert werden. Der Wert muss nur in Stammtabelle geändert werden.

1*n t (3.1) 1t (3.2) Zeitbe-darf

Die Verwendung von Zeigern ist in jedem Fall günstiger.

( )*n sof DT (3.3) ( ) ( ) ( )1 *sof DT n sof Ptr+ − (3.4)

Änd

ern

eine

s D

aten

wer

tes

Spei-cher-bedarf

Wenn der Speicherbedarf des Datentyps größer als der eines Zeigers ist, dann ist die Verwendung von Zeigern immer günstiger.

Ist sofort mit Datensatz vorhanden. Es ist ein zweiter Zugriff auf den Stammdatensatz erforderlich.31

1t (3.5) 1 2t t+ (3.6) Zeitbe-darf

Die Verwendung der Datenwerte ist immer günstiger.

Es wird Speicher (RAM32) für diesen Datensatz benötigt.

( )( )

sof DS

sof DT x= + (3.7)

Es wird Speicher (RAM) für den Datensatz und den Stammdatensatz benötigt.

( ) ( )( ) ( )2*

sof DS sof SDS

sof Key x sof DT

+

= + + (3.8)

Zugr

iff a

uf D

aten

wer

t

Spei-cher-bedarf

Die Verwendung der Datenwerte ist immer günstiger.

Bei internen Operationen ist oftmals nicht der eigentliche Wert interessant. Daher existieren Zugriffe, bei denen der Zeigerwert ausreicht.

1t (3.9) 2t (3.10) Zeitbe-darf

Die Zeit ist nicht direkt von der Methode abhängig, sondern nur vom eigentlichen Zugriffsverfahren. Im Zugriffsverfahren kann allerdings die Größe eine Rolle spielen.

( )( )

sof DS

sof DT x= + (3.11)

( )( )

sof DS

sof Ptr x= + (3.12)

Zugr

iff a

uf D

aten

satz

Spei-cher-bedarf

Der Speicherbedarf ist direkt abhängig von der Größe des Datentyps und der Größe von Zeigern.

31 Der Zugriff auf den Stammdatensatz ist meist nur bei Visualisierungen notwendig! Für internes Arbeiten

reichen oft die Zeigerwerte. Deshalb wird bei Zugriffen ohne Visualisierung die Zugriffszeit für nur einen Datensatz benötigt. Die gleichen Anmerkungen gelten für den Speicherbedarf.

32 In einer Client-Server Umgebung wird nicht nur der RAM benötigt, sondern dieser Datensatz wird auch über das Netz übertragen. D.h. wenig benötigter Speicher, weniger Belastung des Netzes.

Page 62: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 48

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Das Format muss in allen Tabellen geändert werden.

Das Format muss nur in der Stamm-tabelle geändert werden.

*n t (3.13) t (3.14) Zeitbe-darf:

Die Verwendung von Zeigern ist immer günstiger.

Änd

ern

des

Form

ates

für

den

Dat

enw

ert

Spei-cher-bedarf

nicht von Bedeutung nicht von Bedeutung

Tabelle 3.1: Betrachtungen zu Zeit- und Speicherbedarf Wenn mit Zeigern (IDs) gearbeitet wird, bereitet das Sortieren über einen Index Probleme, wenn dieser nicht über das Originalfeld definiert werden kann. Wenn nur die ID in den Index einbezogen ist, dann wird natürlich die ID sortiert. Dies ist vollkommen unabhängig vom eigentlichen Datenwert.

3.4 Trigger

Mit Hilfe von Triggern kann bei Eintreffen eines bestimmten (Trigger-) Ereignisses eine Aktion ausgelöst werden. Ziel dieser Triggersignale ist es, bestehende Abhängigkeiten automatisch durchzuführen. So kann z.B. eine Berechtigungsregelung hinter bestimmten Triggersignalen implementiert werden. Der Vorteil dieses Verfahrens ist, dass es nach der Definition automatisch funktioniert. Trigger sind spezielle Stored Procedures. Bei der Löschung eines Datensatzes ist es z.B. erforderlich, auch alle abhängigen Daten-sätze zu löschen oder zu ändern. Falls dies nicht erfolgt, kommt es im einfachsten Fall zu einem Aufblähen der DB mit nicht genutzten Datensätzen (verwaiste Datensätze), im schlimmsten Fall kommt es zu Inkonsistenten in der DB. Bei herkömmlicher Programmierung ohne Trigger liegt es in der Verantwortung des Programmierers, an jeder Stelle des Lö-schens auch die Folgedatensätze zu bearbeiten. Bei der Verwendung von Triggern braucht sich ein Programmierer nach einmaliger Definition nicht mehr um diese Aufgaben zu küm-mern. Trigger können prinzipiell nach und/oder vor jeder DB-Aktion ausgelöst werden.

3.5 Problem der eindeutigen Zeiten

Während in einem zentralen System die Zeit immer eindeutig ist, ist das Problem der eindeutigen Zeiten in einem verteilten System nicht trivial33. Die Notwendigkeit der eindeutigen Zeiten begründet sich in der Zeitabhängigkeit vieler Daten. Daher ist es besonders wichtig, die Systemzeiten zu synchronisieren. Es ist zu

33 Ausnahme: Wenn auf allen System Funkuhren eingesetzt werden und diese immer ausreichend Funk-

empfang haben, dann ist eine genügende Genauigkeit gegeben.

Page 63: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 49

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

beachten, dass bestimmte Komponenten die Uhrzeit benötigen und durch ein Verändern der Zeit gestört werden können. Für die meisten Zwecke ist es vollkommen ausreichend, die Uhrzeit abzustimmen. Es ist dabei nicht wesentlich, dass diese Zeit mit der realen Zeit übereinstimmt. Es ist jedoch zu beachten, dass Zeiten niemals rückwärts laufen sollten! Ansonsten kann die Koordinierung vieler Programme durcheinander geraten und zu schwerwiegenden Proble-men führen. Zur Synchronisation logischer Algorithmen wird oft der Algorithmus von Lamport verwendet. Es existiert jedoch eine Vielzahl weiterer Algorithmen.

3.5.1 Algorithmus von Cristian

Es existiert ein Zeitserver (z.B. mit Echtzeituhr ausgestatteter Rechner). Die zu synchronisie-renden Rechner (Zeitclients) senden regelmäßig eine Anfrage nach der aktuellen Zeit an den Server. Dieser antwortet so schnell wie möglich mit der aktuellen Zeit UTCC . Der Sender setzt

in erster Näherung seine Zeit auf UTCC . Da die Uhrzeit jedoch nicht rückwärts laufen darf, ist die Zeit in diesem Falle systematisch anzupassen. Das zweite Problem besteht in der Laufzeit der Nachrichten. Die einfachste Lösung besteht darin, dass der Sender die Laufzeit

t∆ misst und die halbierte Laufzeit 2t∆

zu UTCC addiert. Diese Schätzung kann durch

verschiedene Methoden verbessert werden /Ta94/.

3.5.2 Berkeley-Algorithmus

In Berkeley-UNIX wurde gegenüber dem Algorithmus von Cristian der umgekehrte Ansatz gewählt, indem der Zeit-Server (Dämon) aktiv arbeitet. Der Zeit-Dämon fragt zyklisch die Clients nach deren Zeit und teilt den Rechnern nach der Auswertung mit, ihre Uhr auf die neue Zeit zu erhöhen oder die Uhr zu verlangsamen /Ta94/.

3.6 Realzeitbetrachtungen34

Nach /DIN 44300/ ist Realzeitbetrieb (real time) der Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Realzeiterweiterungen für UNIX sind u.a. im POSIX-Standard 1003.4 , /ISO/IEC9945-1/ zu finden (Arbeitsgruppen POSIX.4, POSIX.21) /ZöAl95/. Dieser Standard kann den zeitlichen Determinismus jedoch nicht garantieren /Si98/. Eine allgemeine mathematische Beschreibung von Realzeit kann durch die folgende Formel erfolgen:

34 Bei allen betrachteten Daten wird von worst-case Fällen ausgegangen.

Page 64: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 50

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

( )1 2 1+ ∆ ≤ =P t t t B (3.15)

D.h., die Wahrscheinlichkeit ( P ), dass eine Aufgabe rechtzeitig erledigt ist, vorausgesetzt die Randbedingungen ( B ) sind günstig, ist 1. Entsprechend der jeweiligen Aufgabenstellung steht B dafür, dass weder Ausfälle auftreten noch wichtigere Aufgaben in der Zeitspanne von 1t bis 2t anfallen /ZöAl95/. Maßnahmen zur Fehlertoleranz können die Einhaltung der Bedingungen verbessern, jedoch nicht das Unmögliche möglich machen. Bedingung für ein Realzeitsystem ist es, die Zeit t∆ für die Ausführung einer Aufgabe angeben zu können. Es kann zwischen weichen und harten Realzeitbedingungen unterschieden werden /Lau99/.

Bild 3.1: Einteilung von Realzeitbedingungen

• Weiche Bedingungen:

Die Bedingungen sind überwiegend einzuhalten. Geringfügige Überschreitungen können toleriert werden. Die Realzeiterweiterungen der /ISO/IEC9945-1/ garantieren lediglich weiche Bedingungen.

• Harte Bedingungen:

Die Bedingungen sind unter allen Umständen einzuhalten. Zeitüberschreitungen sind nicht zulässig.

2 1t t t∆ ≤ − (3.16)

Besondere Situationen werden an ein Alarmsystem geleitet und können den Regelfall jederzeit verdrängen.

Aufgabe der Realzeitsysteme ist es im Wesentlichen, Schäden durch Nichteinhaltung von Zeitbedingungen zu verhindern. Dazu zählen z.B.:

• Schäden an Lebewesen • Finanzielle Schäden • Qualitative Schäden

Page 65: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 51

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Die auftretenden Ereignisse und vorhandene Zeitbegriffe verdeutlichen die folgenden beiden Abbildungen:

t

Prozess-aktivität

Ereignis 1 Ereignis 2

tP

tZ tS

Bild 3.2: Prozessaktivitäten

• Pt : Die Prozesszeit ist der mittlere Abstand zwischen zwei Ereignissen, mit denen

eine Änderung des Prozesszustandes gemeldet wird. Der Kehrwert wird als Ereignisrate oder -häufigkeit bezeichnet.

• St : Die Stellzeit ist die Zeit, die der Prozess benötigt, um auf neue Ausgabewerte seiner Steuerung zu reagieren.

• Zt : Als zulässige Antwortzeit bezeichnet man die Zeit, innerhalb der ein Prozess auf eine Zustandsänderung antworten muss.

t

Rechner-aktivität

Ereignis

tA

tR tB

Bild 3.3: Rechneraktivitäten

• Rt : Die Reaktionszeit ist die Zeitspanne zwischen dem Eintreten des Ereignisses

und dem Beginn der Verarbeitung. • At : Die benötigte Antwortzeit vom Eintreten des Ereignisses bis zur Reaktion des

Rechners. • Bt : Die Bearbeitungszeit des Rechners (einschl. Einlesen und Ausschreiben).

Page 66: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 52

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Allgemein gelten für harte Realzeitanforderungen die folgenden Regeln:

A R Bt t t≤ + (3.17)

A Zt t≤ (3.18)

1BB P

P

tt tt

≤ → ≤ (3.19)

3.6.1 Realzeit in DBS

DBS, welche spezielle Eigenschaften von Realzeit-Systemen nicht unterlaufen, sondern unterstützen:

• Multitasking (-threading) mit Prioritäten • Unterbrechungsmöglichkeit, preemptive scheduling • garantierte Zugriffszeiten • reorganisationsfreier Lauf rund um die Uhr (Dauerbetrieb)

können als Realzeit-DBS bezeichnet werden. F 10: Realzeitfähige DBS werden im Folgenden als RZ-DBS bezeichnet35. Es ist zu vermerken, dass in den letzten Jahren immer mehr „RZ-DBS” auf dem Markt erscheinen. Dabei ist jedoch festzustellen, dass kein bekanntes System harte Realzeitanfor-derungen unterstützt. Viele Hersteller der angebotenen Systeme können noch nicht einmal Reaktionszeiten angeben, sondern versuchen mit dem Begriff „Realzeit” lediglich auszudrü-cken, dass sie ein schnelles System besitzen. Typische Vertreter dieser Kategorie sind z.B. Wonderwares Industrial SQL36 /Wo98/ oder Aspentechs InfoPlus.21-Datenbank mit dem Untertitel „The Real-Time-Database“. In den Beschreibungen von Aspentech /As99/ wird Real-Time dann mit „high speed data storage and retrieval“ begründet. Das am weitesten entwickelte RZ-DBS ist sicherlich das System BABAS-DB der Firma Werum. Es unterstützt zwar Realzeit-Konzepte weitestgehend, jedoch sind in den Beschrei-bungen /We97/ auch Schwachstellen zu erkennen. So werden z.B. konfliktbehaftete Transak-tionen nicht nach Prioritäten behandelt37 oder es wird zur Erreichung der Realzeitforderun-gen vom relationalen Modell abgewichen. Es ist des Weiteren nicht ersichtlich, ob und wie Realzeit im Netzwerk unterstützt wird, wie die Realzeitanforderung und die Realisierung in Übereinstimmung gebracht werden. Einige der angebotenen Zugriffsverfahren sind für harte 35 Es erfolgt hier keine Trennung in harte und weiche Echtzeit. 36 Neben dem eigentlichen MS-SQL-Server, auf den aufgesetzt wird, existieren zwar weitere Komponenten

für die schnelle Speicherung von (Prozess-)Daten, es ist jedoch keine exakte Bestimmung der Geschwin-digkeit möglich.

37 Es wird lediglich das Prozesssystem des zugrundeliegenden Echtzeit-Betriebssystems verwendet. Im Falle eines Konfliktes wird immer die Transaktion zurückgesetzt, welche am wenigsten Datensätze modifi-ziert hat.

Page 67: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 53

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Realzeit-Bestimmung überhaupt nicht geeignet (siehe Seite 31 ff). Im Folgenden soll nun der Versuch unternommen werden, ein Konzept für ein echtes Hart-Realzeitfähiges DBS zu entwerfen. Es wurde keine Literatur gefunden, welche dieses Konzept in der Gesamtheit darstellt. Einzelne Komponenten wurden u.a. in /Gu96/, /Gu97/, /Ha94/, /Ha00/ untersucht. Ziel muss es sein, die Antwortzeit (response time) At für das DBS zu berechnen. Diese Reakti-

onszeit entspricht dem t∆ aus dem allgemeinen Ansatz (3.15). Die Antwortzeit eines beliebigen Prozesses x kann allgemein durch folgende Formel berech-net werden:

, xA RP A Pt t t= + (3.20)

• RPt : Die Realzeitanforderungen erfolgen typischerweise über asynchrone Ereig-nisse an das Prozesssystem. Dieses hat die Aufgabe, die Anforderung an den richtigen Prozess weiterzuleiten. Daher sind eventuell laufende Prozesse zu stoppen und der richtige Prozess zu aktivieren (context-switch). Die Reaktionszeit des Prozesssystems ist eine bekannte Größe in Realzeit-Betriebssystemen. Damit wird aber auch vorausgesetzt, dass das Prozess-system des Wirts-Betriebssystems realzeitfähig ist.

S 1: Für ein RZ-DBS ist ein realzeitfähiges Prozesssystem erforderlich (Das Pro-

zesssystem muss deterministisches Zeitverhalten besitzen!) F 11: Die Reaktionszeiten des Prozesssystems werden als bekannt vorausgesetzt.

Wenn man nun davon ausgeht, dass die auszuführende DBS-Aufgabe als Prozess im Prozesssystem läuft, dann entspricht ,A Pt der Antwortzeit des DBS ,A DBSt .

1 ,A RP A DBSt t t= + (3.21)

Bei der Antwortzeit des DBS ist zu unterscheiden, ob es sich um ein lokales DBS handelt oder nicht. In einem nicht-lokalen System sind zur eigentlichen Bearbeitungs-zeit durch das DBS noch die Kommunikationszeiten für Anforderung und Ergebnisse zu addieren.

, , ,A DBS KF A DBS Server KWt t t t= + + (3.22)

• ,KF KWt t : Die Kommunikationszeit für Anfrage- und Antwort muss durch Untersu-

chungen zum Netzwerk ermittelt werden. Nicht für jedes Netzwerk ist eine Zeitangabe möglich. Zwei beispielhafte Rechnungen werden in Abschnitt 3.7.1.1 ab Seite 54 vorgestellt.

Aus Formel (3.22) ist ersichtlich, dass in einem nicht-lokalen DBS die Kommunikati-

Page 68: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 54

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

onszeiten des DBS in die Realzeit-Berechnungen eingehen. Daher ist ein realzeitfä-higes Netzwerk notwendig.

S 2: In einem nicht-lokalen RZ-DBS muss auch das Netzwerk realzeitfähig sein.

In einem lokalen DBS entfällt der Kommunikationsaufwand. Daher können die Kom-munikationszeiten zu Null gesetzt werden:

00

==

KF

KW

tt

(3.23)

Bei Zusammenfassung der bisherigen Betrachtungen setzt sich daher die Anfragezeit aus folgenden Summanden zusammen:

1 , ,A RP KF A DBS Server KWt t t t t= + + + (3.24)

Die einzelnen Summanden werden in den Abschnitten ab 3.7.1.2 genauer betrachtet.

3.6.1.1 Netzwerk

Realzeitverhalten und Ausfallsicherheit werden nach /Stau96/ von der Organisation des Zugriffs auf das Übertragungsmedium entscheidend beeinflusst. Die Medienzugangsverfah-ren (MZV) lassen sich grundsätzlich in deterministische und stochastische Verfahren einteilen. Während deterministische Verfahren eine Berechnung harter Realzeitanforderun-gen ermöglichen, ist dies bei den stochastischen Verfahren nicht möglich. Das eigentliche Problem ist das gleichzeitige Senden mehrerer Stationen (Multi-Master), bei dem ein Konflikt auftreten kann. Es wird angenommen, dass die Übertragungszeiten im Wesentlichen von der Menge der zu übertragenden Daten, dem konkreten Netzwerktyp und dessen Einstellungen (z.B. Baudrate) abhängen. Für die in der Arbeit verwendeten Netzwerke und Protokolle kann nun folgende allgemeine Betrachtung erfolgen:

Die Kommunikation erfolgt üblicherweise über Betriebsmittel des Rechners. Deshalb sind in jedem Fall wieder die Reaktionszeiten der Prozesssysteme von Bedeutung. Da sowohl der Sender als auch der Empfänger auf unterschiedlichen Prozesssyste-men laufen können, sind der Allgemeinheit wegen 2 verschiedene Zeiten anzusetzen. Eine der beiden Zeiten stimmt dabei mit der in Gleichung (3.21) genannten Zeit über-ein. Die eigentliche Übertragungszeit ist das Produkt der Übertragungszeit eines ein-zelnen Bits und der Anzahl der zu übertragenden Bits.

[ ]

[ ]2

3

*

*

BITKF RP L BIT KF

BITKW RP L BIT KW

t t t t n

t t t t n

= + +

= + + (3.25)

Lt bezeichnet man auch als Latenzzeit. Das ist die maximale Zeit, die notwendig ist, bis auf dem Netzwerk gesendet werden kann (Zugangsverzögerungszeit).

Page 69: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 55

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Anstelle der Übertragungszeit für ein Bit wird üblicherweise die Baudrate angegeben:

1BITt

Baudrate= (3.26)

Die Anzahl der übertragenen Bits ist wiederum von mehreren Faktoren abhängig. Fast alle Netzwerke können nur bestimmte Blockgrößen übertragen. Diese Blöcke werden auch als Frames bezeichnet.

[ ] [ ]*=BIT BITBIT FRAMEn n m (3.27)

m charakterisiert die Framegröße in Bits. Ein Frame enthält wiederum eine Anzahl von Nutzdaten und Verwaltungsdaten. Zwi-schen den Frames können u.U. Pausen notwendig werden.

[ ] [ ] [ ]= +BIT BIT BITN Vm n n (3.28)

Um nun genaue Angaben für die Übertragungszeiten zu erhalten, sind Untersuchungen zu den einzelnen Netzwerken erforderlich. Diese müssen Angaben zu:

• Baudrate • Framegröße • Anzahl der Nutzdaten pro Frame • Anzahl der Verwaltungsdaten pro Frame • Zeit, die zwischen 2 Frames liegen muss und Latenzzeit

zulassen. Nur wenn alle Angaben erfolgen, ist eine Berechnung harter Realzeitanforderungen möglich. Da an dieser Stelle keine Berechnung für alle möglichen Netzwerktypen möglich ist, wird sich beispielhaft auf RS232C (aufgrund der Einfachheit), CAN (aufgrund der Verfügbarkeit und der Erfahrungen am IfAT), und IP (aufgrund der weiten Verbreitung) beschränkt. F 12: Es wird im Folgenden davon ausgegangen, dass das Netzwerk für Anforderungen

und für Antworten jeweils das gleiche ist38.

3.6.1.1.1 RS232C

Die Punkt zu Punkt Schnittstelle RS232C zählt im eigentlichen Sinne nicht zu den Netzwer-ken. Es ist jeweils nur ein Master und ein Slave vorhanden. Daher kann kein Sendekonflikt wie bei Multi-Master-Systemen auftreten.

38 Unterschiedliche Netzwerke stellen grundsätzlich kein Problem dar, müssen jedoch mit teilweise anderen

Formeln berücksichtigt werden.

Page 70: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 56

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Bei mehreren Schnittstellen am Server ist jedoch eine Client-Server-Konfiguration möglich. Aufgrund der Punkt zu Punkt Verbindung können keine Konflikte mit anderen Teilnehmern auftreten. Daher kann die Latenzzeit zu Null gesetzt werden.

0Lt = (3.29)

Die Berechnung für harte Realzeit-Anforderungen ist möglich. Die maximale Übertragungs-zeit eines Frames berechnet sich wie folgt:

[ ] [ ]max *FRAME BIT

BIT FRAMEt t n≤ (3.30)

[ ] [ ] [ ]BIT BIT BITFRAME N Vn n n= + (3.31)

Standard-Frames unterstützen zwischen 5 und 8 Datenbits /DIN66022/:

[ ]5 8BITNn≤ ≤ (3.32)

Zu einem Frame gehören immer 1 Start-Bit, 1, 1.5 oder 2 Stopp-Bits und eventuell 1 Pari-tätsbit:

[ ]2 4BITVn≤ ≤ (3.33)

Die Baudrate wird fest vorgegeben und muss bei Sender und Empfänger dieselbe sein. Möglich sind: 75, 110, 150, 200, 300, 600, 1200, 2400, 4800, 9600, 19200 Baud /DIN 66022/. Teilweise werden jedoch auch andere, insbesondere höhere Baudraten verwendet.

Bei Verwendung von 8 Datenbits, 1 Startbit, 1 Paritätsbit und 2 Stopp-Bits sind damit bei einer Standard-Baudrate von 9600 Baud folgende Transferzeiten erreichbar:

[ ] 4 8 1,2519600

FRAMEMAXt ms

s

+≤ = 39 (3.34)

Beschreibungen zur RS232C-Schnittstelle sind u.a. in /DIN 66020/, /DIN 66021/, /DIN 66259/, /DIN 66022/ und /ISO 2110/ zu finden.

3.6.1.1.2 CAN

Ursprünglich für die Automobilindustrie entwickelt, ist CAN heute in zahlreichen industriellen Anwendungen eingesetzt /Et94/, /La94/. Der Bus ist durch seine Robustheit und kostengünstige Anschaffung als Feldbus ideal geeignet. Aufgrund des deterministischen CSMA/CA MZV ist eine Berechnung für harte Realzeit-Anforderungen möglich. Die Priorität der Nachricht wird im Identifier des Frames angegeben. 39 Bei nur 7 Datenbits, 1 Start- und 1 Stoppbit, keiner Parität und einer Baudrate von 115200 sind ca. 78µs

erreichbar.

Page 71: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 57

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Bei gleichzeitiger Belegung des Busses setzt sich immer die Nachricht mit der höchsten Priorität durch. Latenzzeitberechnung (Wartezeit) /PHI96/: Die angegebenen Werte gelten für Basic-CAN (11 Bit Identifier). Zum besseren Verständnis der folgenden Formeln wird zunächst der Aufbau eines CAN-Telegramms dargestellt:

dominant

rezessiv

DatenfeldInterframe-SpaceStart-of-Frame

Objekt-identifier

Arbitrierungsfeld

Steuerfeld

Datenfeld

CRC-Segment

CRC-Feld

Acknowledge-Feld

Acknowledge-Slot

End-of-Frame

1 11 1 6 0 .. 64 15 1 1 1 7 3

Bild 3.4: CAN-2.0A-Frame

[ ] [ ] [ ]( )*FRAME BIT BITMAX BIT MAX LATENZ MESSAGEt t n n≤ + (3.35)

• [ ]BIT

MAX LATENZn : maximale Latenzzeit (vom aktuellen CAN-Status abhängig)

• [ ]BITMESSAGEn : Anzahl der Message-Bits (abängig von Anzahl der Datenbytes und der

Stuffbits40) Die Anzahl der Message-Bits ist eine Summe aus den eigentlichen Datenbits und den zusätzlichen Verwaltungsbits in jedem Frame. Bild 3.4 zeigt den Aufbau eines CAN-2.0A Frames. Ein Frame besteht daher aus mindestens 44 Verwaltungsbits und zwischen 0 und 8 Datenbytes.

[ ] [ ]44 8*BIT BYTEMESSAGE DATAn n≥ + (3.36)

Da beim CAN-Protokoll zur Synchronisation nach jeweils 5 Bits mit gleichem Pegel ein Stuff-Bit eingefügt wird, kann sich die Anzahl der Bits um den Faktor 1,2 erhöhen.

[ ] [ ]( )1,2 44 8*BIT BYTEMESSAGE DATAn n≤ + (3.37)

40 Nach 5 gleichen Bitpegeln wird vom Sender ein Synchronisationsbit eingeschoben. Der Empfänger

entfernt dieses Bit wieder.

Page 72: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 58

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Der ungünstigste Fall (worst case) tritt unter folgenden Bedingungen auf:

• Eine Bit-Zeit zuvor hat ein anderer CAN-Kontroller mit Senden begonnen. Dadurch ist der Bus belegt und es kann erst gesendet werden, wenn diese Nachricht fertig über-tragen ist.

• Ein Fehler tritt bei dieser Nachricht auf, sodass noch ein Fehler-Frame gesendet werden muss. Dieser Fehler-Frame verlängert den eigentlichen Datenframe.

Es wird weiterhin angenommen, dass die eigene Nachricht die höchste Priorität besitzt. Dadurch setzt sie sich immer durch, falls mehrere Nachrichten gleichzeitig auf den Bus gelegt werden. Die maximale Latenzzeit ist daher das Produkt der Bitzeit und der Summe der maximalen Bitanzahl eines Frames und der Bitanzahl eines Fehler-Frames. Im Fehler-Frame werden u.a. sechs Bits gleicher Polarität übertragen. Damit wird eine Codeverletzung provoziert. Der Fehler-Frame besteht insgesamt aus maximal 18 Bits. Zwischen zwei Frames liegt immer ein Zwischenraum von drei rezessiven Bits.

[ ] [ ]44 8* 1 18 3BIT BYTEMAX LATENZ DATA WORST CASEn n≥ + − + + (3.38)

Die Bitzahl im Datenframe kann sich durch die Stuffbits wieder um den Faktor 1.2 erhöhen.

[ ] [ ]( )1,2 44 8* 1 18 3BIT BYTEMAX LATENZ DATA WORST CASEn n≤ + − + + (3.39)

Bei Verwendung der maximal möglichen 8 Datenbytes in einer Message des Netzwerkes erhält man die folgenden Werte:

[ ]

( )[ ]

44 64 1 18 3

1,2 44 64 1 18 3

120 150

BITMAX LATENZ

BITMAX LATENZ

n

n

≥ + − + +

≤ + − + +

≤ ≤

(3.40)

Unter der Annahme, dass die eigene Nachricht ebenfalls 8 Datenbytes enthält, ergibt sich die Transfer-Zeit wie folgt:

[ ]

[ ] ( )[ ]

44 64

1,2 44 64

108 130

BITMESSAGE

BITMESSAGE

BITMESSAGE

n

n

n

≥ +

≤ +

≤ ≤

(3.41)

[ ] ( )* 150 130FRAMEMAX TRANSFER BITt t≤ + (3.42)

Die Bit-Zeit wiederum ist eine Konstante im Netzwerk. Sie ist u.a. von der max. Übertra-gungslänge abhängig. Alle Kontroller im Netz müssen mit der selben Bit-Zeit arbeiten. Bei einer Übertragungsrate von 50 kHz gelten die folgenden Werte:

Page 73: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 59

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

[ ] 150 130 280 5,61 150000 50000

FRAMEMAX TRANSFERt ms

s s

+≤ = = 41 (3.43)

Beschreibungen über CAN sind u.a. in /PHI96/, /Stau96/ und /Et94/ zu finden.

3.6.1.1.3 TCP-IP/UDP-IP

TCP (Transmission Control Protocol) bzw. UDP (User Datagram Protocol) sind heute durch UNIX und das Internet bei den Netzwerkprotokollen der Standard. Das IP-Protokoll definiert den Aufbau der IP-Pakete /Co88/. Aufgrund des konfliktbehafteten Zugriffsprinzips (CSMA/CD, stochastisches MZV (IEEE802.3)) ist jedoch keine Berechnung harter Realzeit möglich. Die Berechnung weicher Realzeit ist grundsätzlich möglich. Sie ist jedoch kompliziert und dynamisch von der Belastung des Netzwerkes abhängig. An dieser Stelle soll nur auf die Arbeiten der Firma Port Automation GmbH verwiesen werden /Pi97/. Eine allgemeine Protokollbeschreibung ist u.a. in /Blo91/, /Co88/, /FiMü96/, /Go95/, /Ki94/, /RFC 793/ nachzulesen.

3.6.1.1.4 Zusammenfassung

Wie gezeigt wurde, kann keine pauschale Aussage über die Übertragungszeiten getroffen werden. Nicht alle Netzwerke und Protokolle sind realzeitfähig. Es ist Aufgabe des jeweiligen Kommunikations-Managers, die richtigen Daten für Baudrate, Framegröße, Anzahl der Nutzdaten pro Frame, Anzahl der Verwaltungsdaten pro Frame, Zeit, die zwischen 2 Frames liegen muss und die Latenzzeit zu liefern. S 3: Die Ergebnisse der letzten Abschnitte begründen die Einführung und die Notwendig-

keit eines Kommunikationsmanagers in einem RZ-DBS. Zu beachten ist, dass die bisher angegebenen Transferzeiten sich jeweils auf einen einzel-nen Frame beziehen. Die maximale Anfrage- bzw. Sendezeit ist damit abhängig von der Anzahl der zu übertragenden Frames (wie in Formel (3.25) bereits vermutet):

[ ] [ ]( )2 1 2*FRAME FRAME

KF RP KF MAX TRANSFER P Pt t n t t t= + + + (3.44)

[ ] [ ]( )3 3 4*FRAME FRAME

KW RP KW MAX TRANSFER P Pt t n t t t= + + + (3.45)

Die Prozesszeit Pt ist die notwendige Zeit, um die zu übertragenden Informationen zu erzeugen. Die komplette Zeit ist z.B. die Zeit von der Programmierung des Transmission-Request-Bits bis zum Erhalten des Interrupts im empfangenden Gerät. Die Prozessbearbei-

41 Bei Verwendung der maximal mögliche Baudrate von 1 MBit sind pro Frame max. 280 µs notwendig.

Werden im Netzwerk Nachrichten mit max. 1 Byte übertragen, sind bei 1MBit max. 146 µs erreichbar.

Page 74: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 60

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

tungszeit setzt sich aus der Menge der abzuarbeitenden Befehle in der CPU und den Hauptspeicherzugriffszeiten zusammen. Da zum großen Teil Speicherzugriffe erforderlich sind und auf den Speicher im Normalfall nicht mit voller Taktfrequenz zugegriffen werden kann, ist eine exakte Berechnung äußerst kompliziert. Die Zeit ist außerdem abhängig von der eingesetzten Hardware. Da damit die Prozessbear-beitungszeit erst zur Laufzeit bekannt ist, bietet es sich zumindest an, sie zur Compilierungs-zeit als normalisierten Wert zu ermitteln. Zur Laufzeit ist nur noch eine Multiplikation mit einem Benchmark-Faktor notwendig.

,*X XP P CPU RAMt t BF= (3.46)

F 13: Das System muss beim Start einen Benchmark-Faktor für die Rechenleistung (CPU

und Speicherzugriffe) ermitteln. Eine Einführung in die Netzwerke und Busse ist u.a. in /ReLe94/ zu finden. Eine genauere Betrachtung für CSMA/CA ist in u.a. /Stau96/ und /Phi96/ nachzulesen. Eine Betrachtung für TCP/IP ist durch die Firma Port GmbH /Po97/ realisiert.

3.6.1.2 DBS

Grundsätzlich ist bei DBS mit folgenden Schwierigkeiten zu rechnen:

• Bedingt durch das Wesen der Transaktionen können jederzeit Ressourcen blockiert sein. Zeitliche Aussagen sind im Normalfall nicht möglich.

• Der Zustand der DB und damit die Zugriffszeiten auf bestimmte Elemente können sich dynamisch ändern.

Schon die erste Schwierigkeit verhindert jede zeitlich determinierte Aussage zu DBS. Eine Transaktion, die z.B. auf die Eingabe eines Bedieners wartet, lässt sich nicht zeitlich bewer-ten. Eine Lösung findet man jedoch leicht mit einem Ansatz aus anderen Realzeitsystemen: F 14: Die Transaktionen erhalten neben ihrer Transaktionsnummer eine Priorität. Es setzt

sich immer die Transaktion mit der höchsten Priorität durch. Transaktionen mit niede-ren Prioritäten müssen nachgeben und werden abgebrochen. Danach kann die höher priorisierte Transaktion abgearbeitet werden. Die abgebrochenen Transaktionen müssen später wiederholt werden.42

Eine andere Lösungsvariante wäre z.B. die zeitliche Beschränkung von Transaktionen /We96/. Auf diese Variante soll an dieser Stelle nicht näher eingegangen werden /LeKiSo/. 42 Das Abbrechen und Wiederstarten von Transaktionen sind Funktionalitäten, die jedes DBS unterstützt. Es

ist dafür keine Änderung des Systems notwendig.

Page 75: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 61

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Mit Hilfe von F 14 kann man nun allgemein die Berechnung der RZ-DBS-Bearbeitungszeit formulieren:

, ,A DBS lokal I EPX Dt t t t= + + (3.47)

• It : Initialisierungszeit

• EPXt : Prozessbearbeitungszeit der abzuarbeitenden Realzeit-Aufgabe

• Dt : Deinitialisierungszeit

3.6.1.2.1 Initialisierungszeit

F 15: Die auszuführende Aufgabe ist immer in eine Transaktion eingeschlossen. Die Initialisierungszeit ist die Zeit, die notwendig ist, um das RZ-DBS auf die Ausführung der geforderten Aufgabe vorzubereiten. (Sie entspricht der Reaktionszeit beim Prozesssystem.)

I AT BTt t t= + (3.48)

Sie kann unterteilt werden in die Zeit, um alte Transaktionen abzubrechen ( ATt ) und die Zeit,

um die neue Transaktion zu starten ( BTt ).

• ATt :

1=

= ∑BT

i

n

AT ATi

t t (3.49)

Die Abbruchzeit ist die Summe der Abbruchzeiten aller beteiligten Transaktionen. Be-teiligte Transaktionen sind Transaktionen, welche Ressourcen blockieren, die durch die geforderte Aufgabe ebenfalls benötigt werden.

Grundsätzlich muss dabei das lokale Recovery-Protokoll unterschieden werden:

o no-undo/redo: o no-undo/no-redo:

Da keine unbestätigten Transaktionen in die Datenbank zurückgeschrieben werden, müssen nur die veränderten Puffer gelöscht werden. Die Abbruchzei-ten sind reine Prozesszeiten.

5

5

1

*

Pufferi

i

i

n

AT Pj

Puffer P

t t

n t=

=

=

∑ (3.50)

Damit kann die gesamte Initialisierungszeit auf folgendes beschränkt werden:

Page 76: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 62

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

( )5

5

1

1

*

* *

BT

i

BT

i

n

AT Puffer Pi

n

BT P Pufferi

t n t

n t n

=

=

=

=

∑ (3.51)

Der komplette Abbruch der alten Transaktionen ist reine Prozesszeit. Es sind keinerlei Festplattenzugriffe notwendig. Er geschieht daher äußerst schnell. Da es schwer fällt, die Anzahl der beteiligten Transaktionen zu bestimmen, muss man zur Vereinfachung folgenden ungünstigsten Fall (worst case) anneh-men:

F 16: Als beteiligte Transaktionen werden alle offenen schreibenden Trans-

aktionen bezeichnet.

Die Anzahl der beteiligten Puffer hängt davon ab, ob die Puffer schon verän-dert worden sind oder nicht. U. U. kann ein Puffer auch durch mehrere Trans-aktionen verändert worden sein. Insgesamt können jedoch maximal alle vorhandenen Puffer gelöscht werden:

max 5*AT Puffer Pt n t= (3.52)

Das Löschverfahren kann noch optimiert werden, indem die Puffer noch nicht als gelöscht markiert werden, sondern nur als zu löschend. Falls nun der Puf-fer benötigt wird, wird er wirklich gelöscht. Für den Fall, dass er nicht benötigt wird, kann nach Ausführung der Echtzeitaufgabe geprüft werden, ob er ge-löscht wird oder wieder als gültig markiert wird.

F 17: Durch Einführung eines neuen Zustandes für die Puffer und die Transaktionen kann das System optimiert werden.

o undo/redo: o undo/no-redo:

Da die BIs explizit angelegt werden, sind diese bei Bedarf zurückzuladen. Das Verfahren wird damit komplexer.

Üblicherweise wird direkt in den Puffern gearbeitet (in-place updating), das BI wird explizit angelegt. Diese Variante kann sehr schnell Transaktionen bestätigen, ein Abbruch einer Transaktion dauert etwas länger, da die BI-Daten in die Puffer zurückkopiert werden müssen.

1 61

Item

i

n

AT wbBI Pi

t t t=

= +∑ (3.53)

Das Zurückschreiben ist nun noch abhängig von der Lage der BI-Daten. Falls

Page 77: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 63

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

sie im RAM vorhanden sind, ist es eine reine Prozesszeit:

1 7wbBI Pt t= (3.54)

Falls sich die BI-Daten auf der Festplatte befinden, sind Festplatten-Lesezugriffe notwendig:

1 8BIwbBI L Pt t t= + (3.55)

Entscheidend ist in jedem Fall, ob die BIs überhaupt existieren oder ob sich die Daten noch in ihrem originalen Zustand befinden. Dies ist daran ersicht-lich, ob die Puffer vor einem commit in die DB zurückgeschrieben werden.

Die beschriebene Variante besitzt den entscheidenden Nachteil, dass Fest-plattenzugriffe notwendig werden können. Dies lässt sich u.U. umgehen:

Es wird in Kopien der Daten aus den Puffern gearbeitet (diferential file), das BI

befindet sich bis zum Abschluss der Transaktion direkt im Puffer bzw. in der DB. Bei dieser Variante dauert die Bestätigung einer Transaktion etwas länger, da die Daten zurückkopiert werden müssen, ein Abbruch einer Transaktion geht jedoch schnell, da sich die Daten noch in den Puffern befinden. Eine Be-schreibung dieser Variante ist u.a. in /Sto75/ zu finden.

2 91

Item

i

n

AT wbBI Pi

t t t=

= +∑ (3.56)

Es spielt keine Rolle, ob der Puffer noch vorhanden ist oder nicht. Es sind in jedem Fall die (veränderten) Kopien der Puffer zu löschen.

2 10wbBI Pt t= (3.57)

Das Löschen der Puffer wurde schon einmal behandelt. Daher gilt:

10 5P Pt t= (3.58)

Diese Variante setzt voraus, dass die Kopien der Daten immer im RAM sind. Damit steht die Summe der zu bearbeitenden Daten in direkter Abhängigkeit zum Speicherausbau des Rechners.

Um die Reaktionszeit des RZ-DBS zu erhöhen, bietet es sich an, die zweite Variante zu verwenden. Damit können „störende“ Transaktionen recht schnell beseitigt werden. Ein intelligentes System könnte u.U. auch erst die Realzeit-anforderung erfüllen und im Anschluss alle Transaktionen, welche im Konflikt zur Realzeitanforderung standen, zurücksetzen. Damit könnte

iATt zu 0 ge-

setzt werden. Es ist jedoch zu beachten, dass auch die „Intelligenz” Rechen-zeit benötigt.

Page 78: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 64

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• BTt :

11BT Pt t= 43 (3.59)

Der Start einer neuen Transaktion ist im Wesentlichen nur Rechenzeit der CPU. Der Start muss noch nicht in das Logbuch geschrieben werden. Daher fallen noch keine Festplattenzugriffszeiten an.

Bei der Zusammenfassung der Formeln dieses Abschnittes und der Annahme der Verwen-dung eines undo-Protokolls und der günstigeren Variante 2 bei diesen Protokollen gelangt man zu folgender Formel:

10 9 111 1

ItemBT nn

I P P Pi j

t t t t= =

⎛ ⎞= + +⎜ ⎟

⎝ ⎠∑ ∑ (3.60)

Es ist der günstige Zustand zu vermerken, dass keine Festplattenzugriffe ins Gewicht fallen.

3.6.1.2.2 Deinitialisierungszeit

Diese Zeit ist ebenfalls stark abhängig vom eingestellten Recoveryprotokoll und der Arbeits-weise des Recovery-Managers. Im Wesentlichen sind nur die Transaktionen zu beenden. Für ein herkömmliches System mit BI und AI gilt folgendes:

12, , , , , ,* * *D S DB S DB S LOG S LOG S AI S AI Pt HD t HD t HD t t= + + + (3.61)

Für ein System mit Spiegelung würde folgendes gelten:

12, , , , , ,* * *D S DB S DB S LOG S LOG S MI S MI Pt HD t HD t HD t t= + + + (3.62)

• Bei lesenden Transaktion sind keinerlei Schreibzugriffe notwendig:

, , , , 0S DB S LOG S AI S MIHD HD HD HD= = = = (3.63)

• Bei schreibenden Transaktionen müssen die veränderten Daten zurückgeschrieben

werden:

43 Es wird davon ausgegangen, dass der Eintrag im LB noch nicht auf die Festplatte geschrieben wird.

Page 79: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 65

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

,

,

,

,

?

?

?

?

S DB

S LOG

S AI

S MI

HD

HD

HD

HD

=

=

=

=

(3.64)

Es ist in jedem Fall ein commit bzw. abort in das LOG einzutragen. Bei der konzipier-ten Variante mit Spiegelung sind 2 Einträge in das LOG notwendig

commit abort

undo/redo AI schreiben Werte aus BI zurückladen

undo/no-redo alle Puffer in DB Werte aus BI zurückladen

No-undo/redo AI schreiben Puffer löschen

No-undo/no-redo alle Puffer in DB Zeiger auf neue Puffer setzen Puffer löschen

Tabelle 3.2: Gegenüberstellung der Funktionen bei commit und abort Es ist zu sehen, dass sowohl die Anzahl der Festplattenzugriffe als auch die Festplatten-zugriffszeit benötigt werden. Da die Festplattenzugriffszeiten keine Konstanten sind, sondern von der jeweiligen Rechne-hardware abhängen, ist folgender Ansatz notwendig: F 18: Das System muss beim Start die maximalen Zugriffszeiten auf die einzelnen DB-Files

ermitteln. Falls alle DB-Files auf einer Platte sind, ist auch nur eine Zugriffszeit erforderlich. Aus beschriebenen Sicherheits- und Performancegründen sollten die Files jedoch auf verschie-denen Platten liegen. Die Anzahl der schreibenden Festplattenzugriffe hängt vom Typ und der Anzahl der Transak-tionen ab. Des Weiteren ist sie stark vom verwendeten Recoveryprotokoll abhängig.

3.6.1.2.3 Prozessbearbeitungszeit

Die Realzeit-Aufgabe wird immer Datensätze der DB lesen oder bearbeiten wollen. F 19: Die notwendige Zeit für die entsprechende Operation wird im Folgenden als Bearbei-

tungszeit bezeichnet. Daher kann die Prozessbearbeitungszeit wie folgt angegeben werden:

131

DS

i

n

EPX P DSi

t t t=

= +∑ (3.65)

• DSn : Anzahl der beteiligten Datensätze. Auch diese Größe ist nicht bekannt.

Page 80: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 66

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

?iDSt = (3.66)

Die Bearbeitungszeit eines Datensatzes ist eine Funktion von der Operation auf diesen Datensatz. Die verschiedenen Möglichkeiten der Bearbeitung (Einfügen, Ändern, Löschen und Suchen) mit ihren entsprechenden Bearbeitungszeiten wurden im vorherigen Kapitel erläutert. Nicht unter allen Umständen ist eine Angabe der Bearbeitungszeit möglich. Im vorigen Kapitel wurde jedoch gezeigt, dass diese Zeiten fast immer dynamisch vom aktuellen Zustand der DB abhängig sind. Eine statische pauschale Angabe über die Zugriffe ist also nicht möglich. Da die Bearbeitungszeit keine Konstante mehr ist, sondern sich dynamisch ändern kann, sind dynamisch im Prozess Prüfungen auf Einhaltung der geforderten Realzeitbedingungen notwendig. Um Bedingungen einhalten zu können, müssen diese dem System auch bekannt sein. Dazu bietet sich das DD an. F 20: Realzeitanforderungen müssen in der DB gespeichert werden. Damit ist in der DB

das Anforderungsmodell enthalten. Bei Zusammenfassung der bisherigen Formeln gelangt man zu folgender Gesamtformel für die Antwortzeit:

[ ] [ ]( )[ ] [ ]( )

1

2 1 2

3 3 4

10 9 11

13

12

1 1

1

, , , , , ,

*

*

* * *

ItemBT

DS

i

A RP

FRAME FRAMERP KF MAX TRANSFER P P

FRAME FRAMERP KW MAX TRANSFER P P

nn

P P Pi j

n

DS Pi

S DB S DB S LOG S LOG S AI S AI P

t t

t n t t t

t n t t t

t t t

t t

HD t HD t HD t t

= =

=

=

+ + + +

+ + + +

⎛ ⎞+ + +⎜ ⎟

⎝ ⎠

+ +

+ + + +

∑ ∑

(3.67)

Die Größen:

1RPt , 2RPt ,

3RPt werden als bekannt vorausgesetzt.

Die maximalen Transferzeiten pro Frame: [ ]FRAME

MAX TRANSFERt können, wie ab Seite 54 beispielhaft

beschrieben, ermittelt werden. Die Größen ,S DBt , ,S LOGt , ,S AIt müssen nach F 18 beim Start des RZ-DBS ermittelt werden.

Page 81: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 67

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Es existieren bisher die folgenden noch unbekannten Größen:

[ ] [ ], , , ,FRAME FRAMEKF KW BT Item DSn n n n n

, , ,, ,S DB S LOG S AIHD HD HD

,XDS Pt t

Zur Minimierung dieser unbekannten Größen aus Gleichung (3.67) wird folgender Ansatz vorgeschlagen: S 4: Stored Procedures werden als compilierte Programme hinterlegt. Damit hat mindes-

tens ein Compilerlauf stattgefunden. Die Rechenzeit des Programms kann durch den Compiler ermittelt werden.

F 21: Zu startende Realzeit-Aufgaben sind grundsätzlich als gespeicherte Funktionen

(Stored Procedures) in der DB zu hinterlegen. Mit Hilfe von F 21 ist man in der Lage, die Anfrage- und Sendemenge ( KFn , KWn ) näher zu

spezifizieren:

F 22: Die Anfragemenge ist die Summe der Daten, welche zum Start der gespei-cherten Funktion notwendig ist (Funktionsaufruf und Parameter):

[ ]FRAME S PKF

F

s sns+

= (3.68)

• ss : Die Menge der Daten zum Starten der Funktion ist eine Konstante, welche

vom RZ-DBMS festgelegt ist. Die Parameter werden in der Funktion angege-ben.

• ps : Die Menge der Übergabeparameter an die gespeicherte Funktion. Sie ist in

der Funktion bekannt und hängt vom RZ-DBMS und vom Betriebssystem ab.

• Fs : Größe eines Frames. Dies ist eine Variable (teilweise auch Konstante), wel-che dem speziellen Kommunikations-Manager bekannt ist.

[ ]FRAME RKW

F

sns

= (3.69)

• Rs : Menge der Rückgabewerte. Diese Menge hängt von der Funktion ab.

Page 82: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 68

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

F 23: Die Sendemenge ist die Menge der Rückgabewerte der gespeicherten Funk-

tion.

Bei eindeutigen Operationen kann hier auch max. 1 Ergebnis zurückgegeben werden. Problematisch sind mehrdeutige Operationen, da hier damit gerech-net werden muss, dass u.U. alle vorhandenen Daten zurückgeliefert werden müssen.

Um nun weitere Unbekannte zu eliminieren, sind zwei weitere Ansätze erforderlich: F 24: Es ist mindestens eine Abfragesprache notwendig. Realzeitfähige gespeicherte

Funktionen müssen in dieser Sprache erstellt werden. F 25: Die Übersetzung der Abfragesprache muss mit einem Sprachübersetzer geschehen,

der zusätzlich zu seiner normalen Funktionalität in der Lage ist, weitere notwendige Angaben für den Realzeit-Manager zu ermitteln und auszugeben.

Durch den folgenden Ansatz erhält man diese notwendigen Daten rechtzeitig: F 26: Die gespeicherte Funktion muss vor der Ausführung übersetzt sein. Dadurch ist vorgegeben, dass der Sprachübersetzer ein Compiler sein muss und kein Interpreter sein darf. Eine Gegenüberstellung der Vor- und Nachteile ist u.a. in /RöAus98/ nachzulesen. Da der Sprachübersetzer die Funktion übersetzt, ist er in der Lage, die Summe der Überga-beparameter an die Prozedur und der Rückgabeparameter anzugeben. Die F 25 ermöglicht außerdem die Ermittlung der Prozesszeiten, indem der Sprachüberset-zer eine Abschätzung über die Rechenzeit der gespeicherten Funktion ablegen kann. Mit Hilfe der letzten Festlegungen kann der Sprachübersetzer nun die folgenden Werte ermitteln: ,R Ps s . Durch Einsetzen in die Gleichungen (3.68) und (3.69) sind damit die bisher Unbekannten

[ ] [ ],FRAME FRAMEKF KWn n berechenbar.

Eine Angabe über den Typ und die Anzahl der Transaktionen in der gespeicherten Funktion ist ebenfalls möglich. Dadurch werden die Variablen , , ,, ,S DB S LOG S AIHD HD HD bekannt.

Des Weiteren kann der Übersetzer genau ermitteln, auf welche Datensätze, auf wie viel Datensätze und mit welchen Zugriffsverfahren zugegriffen wird. Damit sind Informationen über ,DS DSt n vorhanden.

Page 83: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 69

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

1 1 1

Lesen Anlegen LöschenDS DS DS

DS DS DS

R A L

n n n

DS Lesen Anlegen Löscheni i i

t t t t= = =

= + +∑ ∑ ∑ 44 (3.70)

Aufgabe des Sprachübersetzers ist es nun, zu speichern, auf welchen Datensatz wie oft über welches Zugriffsverfahren zugegriffen wird und welche Operationen auf den Datensatz angewendet werden. Damit sind direkte Angaben über Prozesszeiten und Festplatten-zugriffszeiten möglich. Bei lesenden Zugriffen wird ein Zugriffsverfahren oder eine sequentielle Methode verwendet. Zugriffsverfahren:

2LHD siehe Abschnitt→ (3.71)

Sequentiell:

MAXLHD DS= (3.72)

Beim Anlegen von Datensätzen ist der eigentliche Datensatz anzulegen. Des Weiteren ist er in jedem Index der zugehörigen Tabelle einzufügen. Beim Löschen von Datensätzen ist der eigentliche Datensatz zu löschen. Des Weiteren ist er in jedem Index der zugehörigen Tabelle zu löschen. Damit wird deutlich sichtlich, dass die Verwendung von mehreren Zugriffsverfahren zwar bei Suchoperationen deutliche Geschwindigkeitsvorteile bringen kann, jedoch beim Anlegen und Löschen von Datensätzen einen enormen Mehraufwand bedeutet. Von der speziellen Implementierung abhängig ist, ob die Datensätze direkt mit den Index-Daten verfügbar sind oder ob ein weiterer lesender Zugriff auf den Datensatz berücksichtigt werden muss. Des Weiteren ist die Anzahl der Zugriffe von den vorhergehenden Operationen abhängig.

14, , , ,* *Operation L DB L DB S DB S DB Pt HD t HD t t= + + (3.73)

Damit ist er in der Lage alle fehlenden Parameter zu ermitteln. Im ungünstigsten Fall ist eine bestimmte Komponente nicht berechenbar. Aber auch dazu kann der Übersetzer exakte Angaben geben. Die entsprechende Komponente muss dann durch eine realzeitfähige ersetzt werden oder es wird eine Umorganisation notwendig.

44 Es wird sich auf die 3 Grundoperationen Lesen, Anlegen, Löschen beschränkt. Die Operation Ändern kann

durch aufeinanderfolgende Grundoperationen Löschen und Anlegen modelliert werden. Bei Einsatz spe-zieller Änderungsalgorithmen können jedoch effektivere Zugriffe implementiert werden.

Page 84: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 70

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Vereinfachung: Die RAM-Zugriffszeiten werden im Vergleich zu den Festplattenzugriffszei-ten kaum ins Gewicht fallen. (Siehe auch Anmerkungen auf S. 31: Verhält-nis von > 150000.)

RAM HDt t (3.74)

• 5Pt besteht aus wenigen CPU-Befehlen und wenigen Hauptspeicherzugriffen. Aus

diesem Grund kann es näherungsweise zu Null gesetzt werden. Daraus ergibt sich auch, dass ,maxATt zu Null wird.

• 10Pt entspricht wie beschrieben 5Pt und ist damit ebenfalls Null.

• Für 11Pt gelten die gleichen Bemerkungen wie für 5Pt .

3.6.1.2.4 Zusammenfassung

Bei Verknüpfung der bisherigen Formeln erhält man folgende Gesamtformel für die Antwort-zeit des DBS:

[ ]( )[ ]( )

1

2 1 2

3 3 4

10 9 111 1

1 1 1

*

*

ItemBT

Lesen Anlegen LöschenDS DS DS

DS DS DS

R A L

A RP

FRAMES PRP MAX TRANSFER P P

F

FRAMERRP MAX TRANSFER P P

F

nn

P P Pi j

n n n

Lesen Anlegen Löscheni i i

t t

s st t t ts

st t t ts

t t t

t t t

= =

= = =

=

++ + + +

+ + + +

⎛ ⎞+ + +⎜ ⎟

⎝ ⎠⎛ ⎞

+ + +⎜ ⎟⎜ ⎟⎝ ⎠

∑ ∑

∑ ∑ ∑ 13

12

1

, , , , , ,* * *

DSn

Pi

S DB S DB S LOG S LOG S AI S AI P

t

HD t HD t HD t t=

+

+ + + +

(3.75)

Unter Berücksichtigung der Betrachtungen zur Vereinfachung und der Verwendung der normierten Werte entsteht der folgende Ausdruck:

Page 85: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 71

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

[ ]( )[ ]( )

1

2 1 2

3 3 4

91

1 1 1

*

*

BT

Lesen Anlegen LöschenDS DS DS

DS DS DS

R A L

A RP

FRAMES PRP MAX TRANSFER P CPU P CPU

F

FRAMERRP MAX TRANSFER P CPU P CPU

Fn

P CPUi

n n n

Lesen Anlegen Löscheni i i

t t

s st t t BF t BFs

st t t BF t BFs

t BF

t t t

=

= = =

=

++ + + +

+ + + +

+

⎛ ⎞+ + +⎜ ⎟⎜ ⎟

⎝ ⎠

∑ ∑ ∑ 13

12

1

, , , , , ,* * *

DSn

P CPUi

S DB S DB S LOG S LOG S AI S AI P CPU

t BF

HD t HD t HD t t BF

=

+

+ + + +

(3.76)

Die Antwortzeit des Systems hängt sehr stark von der Größe und Struktur der DB ab. Da hier keine pauschalen Angaben bereitstellbar sind, muss das System seine Antwortzeit selbst-ständig berechnen können. Diese muss mit den Anforderungen des Nutzers (zulässige Antwortzeit) verglichen werden. Deshalb bietet es sich an, die Realzeitbedingungen im DDS zu speichern. Im DDS ist damit sowohl das Anforderungsmodell als auch das Prozessmodell vorhanden. Aufgabe des Realzeit-Managers ist es nun, die Modelle auf Einhaltung der Randbedingun-gen zu überwachen und eventuell steuernd in das Prozessmodell einzugreifen. Die Forderungen nach Realzeit können umso besser unterstützt werden, je höher die Verfügbarkeit der Daten ist. Dies bedeutet, dass insbesondere die Sperren so viel wie möglich beschränkt werden müssen. In den Formeln ist bisher nur die Anzahl der maximalen Festplattenzugriffe berücksichtigt worden. Es ist jedoch zu beachten, dass diese ermittelte theoretische maximale Anzahl verringert werden kann, wenn es gelingt, die Zugriffe zu ermitteln, für die die Daten schon im Puffer sind. U.U. ist es auch möglich, bei gespeicherten Funktionen eine optimale Strategie für die Pufferverwaltung festzulegen. Die wesentlichen Zeiten entstehen durch die Festplattenzugriffe. Daher können bei großen Datenbanken die Antwortzeiten in den Bereich von Sekunden geraten. Ein schnelles Fest-plattensystem bzw. eine RAM-Disk oder mehr RAM für weitere Puffer können wesentlich zur Verbesserung der Antwortzeit beitragen. Es lässt sich abschätzen, dass die maximalen Zugriffszeiten wesentlich höher liegen werden als die durchschnittlichen Zeiten. Aus diesem Grund können für weiche Realzeitanforderun-gen auch wesentlich günstigere Zeiten geboten werden als für harte Anforderungen. Das System sollte daher auch weiche Anforderungen unterstützen.

Page 86: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 72

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Voraussetzungen zur Erfüllung von Realzeit-Forderungen:

• Bekannte Reaktionszeit des Prozesssystems des Rechners. • In einer Client-Server-Umgebung bekannte Reaktionszeit des Prozesssystems der

Clients. • In einer Client-Server-Umgebung berechenbare Übertragungszeit der Daten über

das Netzwerk. • Die entsprechende Anforderung muss in der RZ-DB gespeichert sein. • Erweiterter Sprachübersetzer zur Übersetzung der Realzeit-Aufgabe in das interne

RZ-DBS-Format und Ablage der notwendigen Daten in der RZ-DB. • Das RZ-DBS muss gespeicherte Funktionen unterstützen. • Bei Verwendung von Triggern müssen auch die Trigger-Funktionen als gespeicher-

te Funktionen vorhanden sein. • Alle genutzten Algorithmen und Ressourcen müssen berechenbar sein. Dies über-

prüft der Sprachübersetzer. Tabelle 3.3: Voraussetzungen zur Erfüllung von Realzeit-Forderungen Anforderungen an Realzeit-Manager:

• Eine bekannte Reaktionszeit des Prozesssystems des DBS-Servers ist notwendig. • Ein Benchmark-Faktor für CPU-Leistung muss ermitteln werden (für jeden beteilig-

ten Rechner).

iCPUBF

• Die maximalen Zugriffszeiten (lesend und schreibend) für verwendete Festplatten müssen ermitteln werden (nur am Server notwendig).

iHDt

• Die Realzeit-Anforderungen müssen mit realen Verhältnissen verglichen werden und u.U. muss der DB-Status so geändert werden, dass die Realzeitanforderungen jederzeit garantiert werden können.

• Anforderungen und Ressourcen müssen dazu in der RZ-DB gespeichert sein. (DDS).

• Die Realzeit-Funktionen müssen in der RZ-DB gespeichert sein (Stored Procedu-res).

• Bei Verwendung von Triggern gelten für die Trigger-Funktionalitäten die gleichen Bemerkungen wie für die Realzeit-Funktionen.

• Alarm-Handling bei Fehlern und Problemen aufgrund der Bemerkungen von Seite 50 ist notwendig.

• Einzelne DBMS-Komponenten müssen ihren aktuellen Status und ihren Typ mittei-len können.

Tabelle 3.4: Anforderungen an Realzeit-Manager

Page 87: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Lösungskonzepte Seite 73

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Parameter, welche der Sprachcompiler ermitteln muss:

Ps Summe der Bytes der Parameter an die gespeicherte Funktion. Diese ist direkt aus Funktion ablesbar.

Rs Summe der Bytes der Rückgabewerte der gespeicherten Funktion. Ist nur mit einer Analyse der Funktion und deren Operationen möglich.

Pt Normierte Prozesszeiten der einzelnen Operationen. Die reellen Zeiten sind nur durch eine Analyse und Multiplikation mit einem Benchmarkfaktor ermittelbar.

DSn Anzahl der verwendeten Datensätze.

DSOperationn Die Anzahl der verschiedenen Operationen, welche auf die verwendeten Datensätze angewendet werden.

Tabelle 3.5: Parameter, welche der Sprachcompiler ermitteln muss dynamische Steuerungsmöglichkeiten für den Realzeit-Manager:

• Kommunikationsprotokoll

• Zugriffsverfahren auf Tabelle

• Optimierungen innerhalb eines Zugriffsverfahrens

• Puffer-Ersetzungs-Strategie

• Haltung bestimmter Puffer im RAM

• Haltung bestimmter Objekte (Tabellen, Indizes, ...) im RAM

• Beschränkung der Anzahl der gleichzeitig schreibenden Transaktionen

• Einschränkung der Abarbeitung kritischer Transaktionen Tabelle 3.6: dynamische Steuerungsmöglichkeiten für den Realzeit-Manager

Page 88: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 74

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4 Implementierungskonzept Die Auswertung der Kapitel 2 und 3 erfordert nun ein DBS mit mindestens folgenden Merk-malen:

• Ein DDS muss implementiert werden. • Gespeicherte Funktionen sind für die Realzeitaufgaben erforderlich. Dazu muss das

DBS mit gespeicherten Funktionen umgehen können. • Für die gespeicherten Funktionen existiert ein Sprachübersetzer und Realzeit-

Analysator. • Ein Realzeit-Manager muss implementiert werden. • Die einzelnen Komponenten sind in der Lage, Aussagen über ihren aktuellen Zustand

zu treffen, um es dem Realzeit-Manager zu ermöglichen, die Bedingungen zu prüfen. • Zur Erfüllung der Realzeitanforderungen ist unbedingt ein Dauerbetrieb des DBS

notwendig. • Die maximalen Festplattenzugriffszeiten müssen dynamisch ermittelt werden. • Es ist ein Benchmarkfaktor für die Rechenleistung des Computers zu ermitteln. • Es ist ein berechenbares Netzwerk vorhanden. • Die Verwendung von Triggern ist hilfreich, jedoch nicht unbedingt notwendig.

Da für ein industrielles DBS kein Betriebssystem vorausgesetzt werden kann45, ist bei der Implementierung zu beachten, dass keine Funktionalität von Betriebssystemen verwendet wird. Dies betrifft insbesondere das bei anderen DBMS verwendete Prozessmanagement von UNIX-Betriebssystemen. Für die Implementierung wird ein C++ Compiler vorausgesetzt. Die Parser werden mit YACC, Bison bzw. RF-Wiesel erzeugt. Da sie Quellcode erzeugen, sind sie nicht für jede Plattform unbedingt erforderlich. Auf RPC wird verzichtet46. Statt dessen wird die Netzwerk-funktionalität, so weit möglich, auf Sockets zurückgeführt. Momentan nicht implementiert ist der Query-Prozessor. Siehe auch /Ut97/.

4.1 Festlegungen

Namensgebung: globale Objekte:

• K Klassen • DB Datenbank

• K0 abstrakte Klassen • TM Transaktions-Manager

• KM Modulklassen • DM Datensatz-Manager

• KL lokale Klassen • PM Puffer-Manager

45 Für die meisten Mikrokontroller existiert kein Betriebssystem. 46 Es wird auf existierende RPC-Funktionalitäten verzichtet. Dies heißt nicht, dass im System kein RPC

vorhanden ist.

Page 89: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 75

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Namensgebung: globale Objekte:

• KN Netzwerkklassen • FM File-Manager

• KDT Klassen für Datentypen • KM Kommunikations-Manager

• K_I Klassen für Indextypen

• K_IB Klassen für Indextypen mit Block für Datensätze

Typen47: __ADRESSE, __FELD, __INDEX, __INDEXFELD, __RESTRIKTION, __TABELLE, __TNR

4.2 Generelle Betrachtungen

Moderne DBS stellen heute zahlreiche Mechanismen zur Verfügung, die einen effizienten DB-Einsatz ermöglichen. Moderne Systeme sollten den Anwender jedoch so weit unterstüt-zen, dass „natürliche“ Schwächen so weit wie möglich behoben werden. Für die Implementierung sind universelle Objekte zu schaffen, welche prinzipiell auf ver-schiedene DBs zugreifen können. Im Rahmen einer Standardisierung und Vereinheitlichung sind SQL- oder ähnliche Befehle zu verwenden. Es existieren DBs, bei denen jede Tabelle und jeder Index eigene Dateien sind und es existieren andere, wo alle Tabellen und Indizes in einer Datei zusammengefasst sind. Dies ist bei der Programmierung zu berücksichtigen und flexibel zu handhaben. Da sowohl DB-Name als auch Tabellenname mit dem Dateinamen identisch sein können, gelten für die Namensgebung die Beschränkungen für Dateinamen (Schnittmenge von UNIX und DOS, kleinstes gemeinsames Vielfaches). DOS: maximal 8 Zeichen

Sonderzeichen nicht erlaubt Dateigrößen ab 8MB bereiten Performance-Probleme (siehe Progress-Hand-buch)

UNIX: da zwischen Groß- und Kleinschreibung unterschieden wird und bei einer Portie-rung von DOS im UNIX (im Normalfall) alles klein angelegt wird, sind die Namen klein zu schreiben.

Die Menge der Datentypen ist zu prüfen und so weit wie möglich zu vereinfachen. Prinzipiell lassen sich alle Daten in alphanumerischen Feldern darstellen. Eine Minimalkon-figuration würde also mit diesem einen Feldtyp auskommen. Aus den folgenden Gründen sollten jedoch weitere Datentypen implementiert werden:

47 Jeder Typ kann ein „C“ am Anfang enthalten und bezeichnet damit Konstanten.

Page 90: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 76

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• bessere Syntaxprüfung • bessere Hilfestellung durch das System bei der Datenerfassung • automatische Berechnung von Werten • automatische Darstellung von Werten

Die Datenbankschnittstelle ist möglichst mit einer virtuellen Datenbank zu realisieren. Damit wird es ermöglicht, beliebige Fremddatenbanken anzusprechen.

4.3 RZ-DBMS – „MRDB“

Das RZ-DBMS wurde so implementiert, dass es nur jeweils eine DB verwalten kann. Diese Beschränkung spielt nach Meinung des Autors für industrielle Datenbanken keine Rolle, da die DB nicht zur Massendatenverarbeitung dient. Es wurde jedoch darauf geachtet, dass es möglich ist, mehrere RZ-DBMS gleichzeitig auf einem Rechner laufen zu lassen.

• Client-Server Das Client-Server-Konzept wurde entwickelt. Zur Compilierungszeit des Programms ist eine Skalierung des Gesamtsystems möglich. Damit lassen sich bestimmte Funk-tionen sowohl auf Client-Seite als auch auf Server-Seite einsetzen. Im einfachsten Fall arbeitet der Client als Terminal bzw. besitzt nur die Kommunikationsfähigkeit mit dem Server. Die konkrete Realisierung erfolgte durch die Verwendung abstrakter Klassen. Der Server läuft als oberflächenloser Prozess. Dies bedeutet, dass zur Bearbeitung immer ein Client erforderlich ist.

• Realzeit Um die Realzeitanforderungen zu erfüllen, wurde laut beschriebenem Lösungsweg folgende Implementierung gewählt: Die Realzeitkriterien, Bedingungen und Daten werden im DD gespeichert. Dazu zäh-len:

Realzeitanforderung: Zeit, Prozedur Prozedur: Tabelle, Anzahl Zugriffe Indextyp: Berechnungsformeln für Zugriff Systemdaten: Festplattenzugriffszeit, ...

Damit ist gegenüber der üblichen DB-Arbeit folgende Vorgehensweise erforderlich:

o Anlegen eines Datensatzes für die Anforderung mit Prozedurangabe und

Zeitangabe o Der Sprachcompiler ermittelt die Anzahl der Tabellenzugriffe und trägt dies in

die Prozedurtabelle ein.

Page 91: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 77

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

o Anhand der Kenntnisse über Indextypen, Tabellenzugriffe und Systemdaten kann der Realzeit-Manager jederzeit dafür sorgen, dass die Anforderungen erfüllt werden können.

Das UI ist mit Hilfe der KDesktop-Bibliothek von Dipl. Ing. Rolf Fischer /Fi97D/ implementiert. Als Parser für eingebundene Grammatiken wird ebenfalls eine Implementierung von Dipl. Ing. Rolf Fischer verwendet /Fi97P/.

4.3.1 DDS

Wie in Kapitel 2 beschrieben, hat die Verwendung eines DDS sehr viele Vorteile. Nach den Erläuterungen von Kapitel 3 ist es für die Bearbeitung von Realzeitanforderungen notwendig. Deshalb soll ein solches System hier entworfen werden. Der Entwurf aus dem SQL-Standard wird nicht verwendet, da er nach Meinung des Autors für ein minimales DBS zu umfangreich ist. Des Weiteren ist keine Realzeitfähigkeit imple-mentiert. Die Benutzung eines DDS hat zur Folge, dass eine „leere" DB in Wirklichkeit schon Struktu-ren und Daten enthält (die des DDS). Da die Menge der Funktionen eines DDS nicht eindeutig definiert ist, soll hier in mehreren Stufen die Entwicklung von einem einfachen zu einem komplexen DDS erläutert werden. Während in den einfacheren Stufen „nur“ Informationen über die Daten enthalten sind, können mit den komplexeren Stufen auch automatisch Verwaltungsfunktionen integriert werden. Da das DDS zur Referenzierung der DBs, Tabellen und Felder benötigt wird, sollte es komplett im RAM gehalten werden. Dies könnte entfallen, wenn mit einem RUN-TIME-System gearbeitet wird48. Hier sind die Namen durch die entsprechenden Adressen komplett aufgelöst und das System wird nur noch für einige Spezialfunktionen benötigt. Die Funktio-nen für die Arbeit mit dem DDS im RAM sollten so universell ausgelegt werden, dass die Behandlung des DDS wie die Behandlung von Workfiles erfolgt. Im einfachsten Fall werden die Listen in einem Array gehalten. Eine Indizierung ist nicht möglich. Angefügt wird immer am Ende. Der Entwurf wird aus den bisherigen Betrachtungen abgeleitet, in ihn fließen eigene Entwick-lungserfahrungen (3 Jahre Progress + Applikationen):

48 In diesem Fall liegen alle Programme in kompilierter Form vor. Die Namen von Tabellen und Feldern

werden nicht mehr benötigt, da sie intern durch Adressen abgebildet sind.

Page 92: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 78

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.3.1.1 Stufe 1: DDS für Verwaltung der DB

Tabelle „Tabellen“

• ID eindeutige Nummer der Tabelle in der DB

• Name (23 Zeichen + \0) Name der Tabelle

• Leseberechtigung ID der Gruppe

• Schreibberechtigung ID der Gruppe

• Dumpname (8 Zeichen + \0) Name der Tabelle beim Dumpen

Tabelle „Felder“

• ID eindeutige Feldnummer in DB

• Name (23 Zeichen + \0) Name der Tabelle

• Tabelle Verweis auf eigene Tabelle

• Typ

• Parameter Formatkennzeichen für Typ (bei Strings auch groß/-klein)

• Parameter1

• Format

• Initialisierungswert

Unter Umständen ist es sinnvoll, Felder mit bestimmten Werten zu initialisieren. Da das Feldformat hier nicht global festgelegt werden kann, wird beim Anlegen einer jeden Tabelle ein Datensatz „0“ angelegt. Dieser ist für den Benutzer nicht vorhanden. Er enthält die Initialisie-rungswerte der einzelnen Felder. In diesem Feld wird lediglich angegeben, ob der Datensatz 0 verwendet wird oder nicht.

Tabelle „Indizes“

• ID eindeutige Indexnummer in der DB

• Tabelle Verweis auf eigene Tabelle

• Nummer

Nummer innerhalb der Tabelle 0 - Primärindex Indizes, die zur gleiche Tabelle gehören und die gleiche Nummer besitzen, werden als mehrdimensio-nale Indizes angelegt

• Name (23 Zeichen + \0)

• Typ

• Ordnung Um das System flexibel zu gestalten, sollte jeder Index eine eigene (optimale) Ordnung besitzen.

Page 93: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 79

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• ADR_root Adresse des ersten Index-Items

• eindeutig / mehrdeutig

• gesperrt

Hiermit kann die automatische Aktualisierung eines Indizes verhindert oder erlaubt werden. Das Verhindern spart einerseits Zeit und erlaubt des Weiteren bis zum nächsten Aktivieren, die Datensätze unvollständig zu lassen. Von dieser Möglichkeit sollten nur erfahrene Nutzer Gebrauch machen. Die Performance des Systems kann bei Verwendung erheblich verbessert werden. Beispiel: Index für Jahresabrechnungen (wird 364 Tage nicht benötigt)

Tabelle „Indexfelder“49

• ID

• Index

• Feldnummer

• Sortierordnung Tabelle 4.1: Stufe 1 des DD-Entwurfs

Tabelle

Index

Feld

Index-feld

ID1

ID-Tabellen

ID1

ID-Indexn

ID1

ID-Tabellen

ID1

ID-Feld1

Bild 4.1: Struktur des minimalen DDS

49 Ob Groß- bzw. Kleinschreibung beachtet wird, ist im Feld angegeben.

Page 94: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 80

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.3.1.2 Stufe 2: Integration von Triggern

Tabelle „Trigger”

• ID (Nummer) des Triggersignals

• Tabellennummer

• Typ

• Name (23 + ´\0´) Tabelle 4.2: Stufe 2 des DD-Entwurfs

4.3.1.3 Stufe 3: Integration einer Programmverwaltung

Wenn alle Programme automatisch verwaltet werden, so ist z.B. ein automatisches compilie-ren aller Programme möglich (z.B. nach einer Änderung der DB-Struktur). Des Weiteren kann in Prüfläufen getestet werden, ob im Projekt ungenutzte Felder, Tabellen oder DBs existieren. Tabelle „gespeicherte Funktionen”

• Programmnummer

• Name

• Datum

• Prozedur

• Quelle Tabelle 4.3: Stufe 3 des DD-Entwurfs

4.3.1.4 Stufe 4: Integration von Views

Es werden Sichten auf die DB(s) definiert. Dies entspricht der externen Ebene in der 3-Level-Architektur. Die Displayfunktion der DB kann soweit vereinfacht werden, dass als einziger Parameter ein Viewname erforderlich ist. Die Views sollten in jedem Fall die Flexibilität der Formulare von Paradox umfassen. Views werden auch als virtuelle Tabellen bezeichnet. Tabelle „Views”

• Nummer

• Name

Tabelle „Viewfelder”

• Nummer

• Name

Page 95: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 81

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

• Viewnummer

• Feldnummer

• x-Position

• y-Position Tabelle 4.4: Stufe 4 des DD-Entwurfs

4.3.1.4.1 Stufe 5: Realzeit

Tabelle „Realzeit”

• Nummer

• Prozedur

• Priorität

• Reaktionszeit

• Reserve

• aktuelle Zeit

Tabelle „Ressourcen”

• Anforderung

• Tabelle

• Index

• Zugriffstyp

• Anzahl Tabelle 4.5: Stufe 5 des DD-Entwurfs

4.3.1.5 Stufe 6: Weitere Ergänzungen

Da kurze Namen nur sehr wenig zum Ausdruck bringen, sollte eine Arbeit mit Synonymen möglich sein. Dazu ist die folgende Tabelle anzulegen: Tabelle „Synonyme”

• ID

• Name (richtig oder Synonym)

• Name (Synonym) Tabelle 4.6: Stufe 6 des DD-Entwurfs Unter verschiedenen Umständen wird Speicherplatz in der DB freigegeben (z.B. no-undo/no-redo - Protokoll). Da die DB nicht jedesmal reorganisiert werden kann, ist es u.U. sinnvoll, sich freie Speicherbereiche zu merken und eventuell bei Bedarf wieder zu verwenden. Dies

Page 96: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 82

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

ist vor allem bei Systemen erforderlich, welche im Dauerbetrieb arbeiten, da hier keine Zeit für eine Reorganisation der DB vorhanden ist. Zusammenfassung: Die Untergliederung zeigt, dass ein DDS in vielen Varianten und Stufen ausgebaut werden kann. Dies ist u.a. deshalb der Fall, da, wie in Kapitel 2 beschrieben, keine exakte Definition für ein DDS gegeben ist. Ein Ausbau empfiehlt sich aber schon deshalb, weil sich wesentli-che Funktionalitäten mit Hilfe des DDS automatisieren lassen bzw. durch die Informationen des DDS überhaupt erst möglich werden.

4.3.2 Prozess-Manager

Wie in Kapitel 3 definiert, ist für ein RZ-DBS auch ein realzeitfähiges Prozesssystem not-wendig. Das RZ-DBMS arbeitet momentan nur mit dem Prozesssystem des jeweiligen Wirts-Betriebssystems (Standard Linux). Linux bietet sich aus mehreren Gründen an:

• In den Linux-Scheduler wurde sehr viel Aufwand investiert, um mit Linux Symmetri-sche Multiprozessor-Systeme (SMP) zu unterstützen (Intel-, Sparc-, Alpha- und Po-werPC-Prozessoren).

• Im Betriebssystem Linux wird zwischen normalen und realzeitfähigen Prozessen

unterschieden. Realzeitprozesse besitzen die höheren Prioritäten gegenüber anderen Prozessen. Der Scheduler kann sie mit einem Round-Robin- oder einem First-In-First-Out-Algorithmus bedienen /Ru97/. Insgesamt kann Linux jedoch trotzdem nicht als realzeitfähig bezeichnet werden, da der Kern jederzeit Interrupts sperren kann. Dadurch können keine Zeiten garantiert werden. Trotzdem existieren einige vielversprechende Ansätze, um Linux realzeitfähig zu ma-chen (RT-Linux, KU Real-Time Linux, Mikrokern L4-Linux). Der vielversprechendste ist sicherlich RT-Linux. Bei diesem Konzept wurde ein neuer minimaler, aber realzeit-fähiger Kernel geschrieben. Der eigentliche Linux-Kernel läuft als Task mit niedrigster Priorität im RT-Linux. Die Kommunikation untereinander geschieht mit RT-FIFOs. /Yo97/, /Si98/, /Ba97/, /YoBa96/, /YoBa97/ RT-Linux ist damit ein eigenes, dediziertes Realzeit-Betriebssystem, in welchem Li-nux als Gast-Betriebssystem eingebettet ist. Der Kern von RT-Linux ist minimal und hat nur Schnittstellen zur Abarbeitung harter Realzeitbedingungen implementiert. Die wesentlichen Module von RT-Linux sind:

o RT-Linux Kern o Scheduler o Kommunikationsmodul o Synchronisations- und Interprozesskommunikationsprimitive o Modul zur Veränderung ausgewählter Parameter aus dem Gast-

Betriebssystem heraus

Page 97: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 83

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Es werden sporadische und zyklische Tasks unterstützt.

• Linux unterstützt seit Version 2.0 das Threadkonzept. Die Linux-Implementierung ist kompatibel zum POSIX 1003.1c-Standard. Als Implementierungsmodell wurde das „one-to-one”-Modell gewählt. Der Nachteil dieses Modells (siehe Seite ) relativiert sich unter Linux, da die Prozessumschaltung hier besonders effizient gelöst ist /Xa97/. Linux-Threads sind als Kernel-Level-Threads implementiert.

4.3.3 File-Manager

Klasse: K_FM Instanz: FM Laufzeit-Parameter: Filereserve Sicherheitslevel

Bild 4.2: Objektstruktur File-Manager

Der File-Manager wurde ursprünglich für die Arbeit mit normalen Betriebssystemfiles implementiert. Aufgrund der bekannten Problematik erfolgt momentan eine Implementierung mit RAW-Files. Bei der bisherigen Implementierung erfolgt eine ständige Überwachung des verfügbaren Speicherplatzes, um rechtzeitig notwendige Maßnahmen ergreifen zu können. Durch eine „File-Reserve” ist es möglich, sich Speicherplatz vorab zu reservieren. Sehr effektiv wird die Dateiarbeit sicherlich, wenn man die Dateien in den Speicherbereich einblendet (Mapping). Dies ist z.B. unter Linux möglich. Das Linux 2. erweiterte Filesystem zählt z.B. momentan mit zu den schnellsten Filesystemen /Chip/. Der Recovery-Manager ist für das korrekte Recovery der DB zuständig. Da er dabei mit den Betriebssystemfiles arbeiten muss, ist er nicht als eigenständiger Manager implementiert, sondern in das komplexere File-Manager-Objekt integriert. Der Log-Manager ist ebenfalls nicht als eigenständige Klasse implementiert, sondern seine Funktionalität ist in die des File-Managers integriert.

Page 98: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 84

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Er erzwingt das write-ahead logging-Protokoll. Um undo und redo durchführen zu können, wird AI und BI durchgeführt. LOG: Das LOG war ursprünglich als ASCII-Datei implementiert. Dadurch war es möglich, den Ablauf der DB-Arbeit von Hand zu verfolgen. Durch die größere Datenmenge ist es aber nicht so effektiv wie bei einer Speicherung von Binärdaten. Daher wurde es auf Binär-Daten umgestellt. Um den CP-Aufwand so gering wie möglich zu halten, befindet sich am Anfang des LOGs (auf fester Adresse 0) die Adresse des letzten CP-Satzes. Diese Adresse wird binär gespei-chert. Damit hat sie eine feste Größe von 4 Byte. Des Weiteren wird gleich beim Anlegen des LOGs ein CP-Satz geschrieben. Damit muss am Anfang nicht getestet werden, ob überhaupt schon ein CP existiert. Adresse Inhalt Eintrag Funktion

0 Adresse des letzten CP-Satzes

5 Logbucheinträge 'CP' Nummer Checkpunkt

'LI' Nummer Datum Login

'LO' Nummer Datum Logout

'TB' Nummer begin Transaktion

'TW' Nummer write Transaktion

'TC' Nummer commit Transaktion

'TA' Nummer abort Transaktion

'LRU ', ‘LFU’ Hinweis auf LRU- oder LFU-Reorganisation (Statistik)

'MEM' Hinweis auf Speicherreorganisation (Statistik)

Tabelle 4.7: Aufbau LOG für „MRDB“ Beim Herunterfahren des DBS wird generell noch einmal ein CP geschrieben. Damit steht am Ende des LOGs immer ein CP-Satz. Beim nächsten Hochfahren des DBS vereinfacht sich die Startprozedur. Da die Praxis zeigte, dass das LOG in dieser Implementierung recht schnell wächst, wurde es konfigurierbar gestaltet, ob statistische Funktionen mit im LOG protokolliert werden oder nicht.

Page 99: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 85

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.3.4 Puffer-Manager

Klasse: K_PM Instanz: K_PM::PM Laufzeit-Parameter: Anzahl DB-Puffer Anzahl BI-Puffer Auslagerungsstrategie Item komplett in einem Puffer? Compiler-Parameter: Puffergröße

Bild 4.3: Objektstruktur Puffermanager

Im Linux-Systemen ist der physische Speicher in ein abstraktes virtuelles Speichermodell umgesetzt. Dabei wird der physische Speicher in handliche Größen (chunks), genannt Seiten (pages), geteilt50. Jede dieser Seiten besitzt eine eindeutige Identifikationsnummer (Page Frame Number) PFN. Um den Speicher effektiv nutzen zu können, werden Methoden wie Demand Paging oder Swapping verwendet. Im System sind bereits mehrere Caches vorhanden:

• Puffer-Cache (durch die Block-Gerätetreiber verwendet) • Seiten-Cache (Cache um die Zugriffe auf Files zu erhöhen) • Swap-Cache (veränderte Speicherseiten können hier abgelegt werden) • Hardware-Caches (in Intel Systemen z.B. L1 und L2, aber auch auf Festplatte, ...)

Der Puffermanager repräsentiert die eigentliche Datenschnittstelle für das gesamte DBMS.

50 Auf Alpha AXP Systemen 8 KByte-, auf Intel x86 Systemen 4 KByte-Seiten.

Page 100: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 86

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Das Lesen und Schreiben der Daten in die eigentlichen Files geschieht transparent im Hintergrund in Zusammenarbeit mit dem File-Manager. Die Puffergröße ist während der Programmcompilierung einstellbar. Die Anzahl der Puffer ist eine Abhängigkeit von Puffer-größe und Speicherausbau des Rechners. Sie ist in der *.INI-Datei konfigurierbar. Der Puffermanager verwaltet Puffer für die DB, das AI, das BI und das LOG. In der aktuellen Realisierung können bei Speichermangel vorhandene Puffer nach 3 Metho-den behandelt werden. Die Methode wird in der Konfiguration ausgewählt:

• einer LRU-Methode (least recently used) • einer LFU-Methode (least frequently used) • einem Aging-Algorithmus51 /Ru97/

einen Puffer auf Disk schreiben

Puffer einlesen Datensatz bearbeiten

Puffer gefunden?

freier Puffer verfügbar?

Puffer im Pool suchen

DatensatzZugriff

Start

Ende

ja

nein

ja

nein

Bild 4.4: Zugriff auf einen Datensatz

51 Jeder Puffer erhält einen Zähler. Dieser Zähler wird bei bestimmten Ereignissen erhöht oder vermindert.

Der Puffer ist “alt”, wenn er den Wert 0 enthält.

Page 101: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 87

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Der Algorithmus kann dynamisch ausgetauscht werden. Damit ist eine Erweiterung der Algorithmen jederzeit möglich (z.B. optimale Strategie für Realzeit). Für Realzeit-Anwendungen ist es möglich, den Puffer-Manager so zu konfigurieren, dass die Datensätze immer in nur einem Puffer abgelegt werden (siehe Realzeitbetrachtungen). Die damit gewonnene wesentliche Geschwindigkeitssteigerung begrenzt jedoch die Größe von Datensätzen auf die Puffergröße. Des Weiteren wird der Speicherplatz nicht optimal genutzt. Bei der Implementierung ist zu entscheiden, ob die Puffer-Verwaltungsstrukturen statisch oder dynamisch angelegt werden. Aufgrund der Realzeit-Betrachtungen wurde die statische Variante bevorzugt. Besondere Beachtung ist dem Puffer-Manager bei Systemen mit sehr wenig Speicher, z.B. Mikrokontroller oder PCs mit DOS als Betriebssystem, zu schenken. Die Problematik ergibt sich aus folgendem Problem:

Alle dynamischen Objekte müssen sich ihren Speicher auf dem Heap reservieren. Bei der Reservierung erhält man einen Zeiger auf den Speicherbereich, mit dem ge-arbeitet werden kann. Da der Speicherverwaltung nicht bekannt ist, wie viel Zeiger benutzt werden und wo sich diese befinden, ist es ihr auch nicht möglich, den reser-vierten Bereich umzusortieren52. Des Weiteren ist es nicht möglich, die Speicherre-servierung zu steuern, d.h. anzugeben, wo Speicher reserviert werden soll. Da nun die Speicherbereiche nicht hintereinander angelegt und freigegeben werden, sondern dies durcheinander erfolgt, kommt es mit der Zeit zu einer Fragmentierung des Spei-chers. Falls nun ein größerer Speicherbereich benötigt wird, kann es passieren, dass dieser Bereich nicht zusammenhängend zur Verfügung steht.

Eine Lösung ist die Verwendung von Garbage-Collections. Diese Methoden besitzen jedoch Nachteile bei zeitkritischen Anwendungen. Aus diesem Grund wird in der Ar-beit eine individuelle Methode vorgezogen.

Lösung53:

Es wird grundsätzlich getrennt zwischen normalen Heap-Objekten und Puffer-Objekten. Für normale Heap-Objekte wird die standardmäßige Speicherverwaltung verwendet. Für die Puffer ist es üblich, große Speicherbereiche zu reservieren. Bei Speichermangel können diese großen Bereiche jedoch nur komplett gelöscht wer-den, eine Veränderung der Größe ist kaum möglich. Ziel ist es, die Bereiche der Puf-fer zusammenzuhalten, die Gesamtgröße jedoch variieren zu können. Durch den Puf-fer-Manager ist garantiert, dass sich ein Puffer nur jeweils einmal im RAM befindet. Damit ist gesichert, dass nur ein Zeiger auf den Speicherbereich vorhanden ist und die Adressen der Zeiger dem Puffer-Manager bekannt sind. Damit sind alle Voraus-setzungen gegeben, um die Speicherbereiche umzusortieren. Es muss lediglich noch

52 Die Angaben beziehen sich auf die Speicherreservierung in der verwendeten Programmiersprache 'C'. 53 Die Lösung ist auf Systeme mit direkter Speicheradressierung beschränkt (z.B. real-adress-Mode im PC).

Sie ist nicht gültig für Systeme mit protected-virtual-adress-Mode.

Page 102: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 88

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

ein System geschaffen werden, um die Pufferbereiche zusammenzuhalten54. Dies er-reicht man, indem man folgende Festlegungen trifft:

F 27: Im Speicher wird eine Adresse festgelegt. Oberhalb dieser Adresse befinden

sich die Pufferbereiche, unterhalb normale Heap-Objekte. Die Adresse ist je-derzeit nach oben verschiebbar. Nach unten kann sie verschoben werden, wenn freier Speicher existiert.

Die standardmäßige Speicherverwaltung wird durch Überlagerung von new geringfü-gig modifiziert. Dies hat den Vorteil, dass alle Programme und -komponenten bleiben können, wie sie sind. Sie verwenden weiterhin den operator new.

F 28: Die Verwendung von anderen Speicherreservierungsfunktionen ist untersagt,

da sie den Mechanismus umgehen.

Der Operator muss nun zusätzlich prüfen, ob der reservierte Speicher unterhalb der festgelegten Grenze ist. Falls dies nicht so ist, muss die Grenze nach oben verscho-ben werden, um Platz für den angeforderten Speicher zu schaffen.

Für die Reservierung von Pufferspeicher wird eine weitere Funktion eingeführt. Diese prüft im Gegenzug, ob der reservierte Speicher oberhalb der festgesetzten Grenze ist. Falls dies nicht der Fall ist, muss dies ermöglicht werden.

4.3.5 Datensatz-Manager

Klasse: K_DM Instanz: DM Neben den Puffern, die durch den Puffer-Manager verwaltet werden und außerhalb seines Gültigkeitsbereiches nicht sichtbar sind, ist die eigentliche Verarbeitungseinheit im DBMS der Datensatz. Alle Daten in der DB basieren auf Datensätzen (auch Indizes, ...). Für ihre effektive Verwaltung existiert der Datensatz-Manager. Wie die Realzeit-Betrachtungen zeigen, sollten sich möglichst alle notwendigen Daten im RAM befinden. Dazu zählen u.a. auch die BI-Daten, welche bei einem Abbruch der Transak-tion benötigt werden. Daher wurde bei der Implementierung eine Variante gewählt, bei der der Datensatz-Manager eine Kopie des Datensatzes aus dem (den) Puffer(n) anlegt. Bei dieser Variante befindet sich damit im Datensatz-Manager der aktuelle Datensatz und im Puffer das BI. Der Nachteil dieser Variante ist, dass die Größe einer Transaktion beschränkt wird, da sich nun alle Daten im RAM befinden müssen. Der Datensatz-Manager verwaltet die Datensätze in einer zweidimensionalen Liste mit 54 Wie in den Vorbemerkungen angegeben, muss die Methode natürlich flexibel und portierbar sein. Da die

Speicherreservierung jedoch sehr hardwarenah ist, sind in jedem Fall Standardfunktionen zu verwenden.

Page 103: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 89

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

folgender Organisation: 1. Dimension: Transaktionsnummer 2. Dimension: Datensatzliste der zugehörigen Transaktion Da das bisherige Konzept nicht sehr ausgereift ist, erfolgt momentan eine Umstellung. Hintergrund ist die Idee, dass eine lesende Transaktion den Datensatz nicht verändert. Daher können alle lesenden Transaktionen auf einen Datensatz zugreifen. Da es zur gleichen Zeit nur eine schreibende Transaktion auf einen Datensatz geben kann, ist damit die Anzahl der Kopien eines Datensatzes im DM auf maximal 2 beschränkt. Um die Fragmentierung und Belastung der DB so gering wie möglich zu halten, werden die Datensätze immer erst beim (pre-)commit in die DB (Puffer) geschrieben. Damit belasten Datensätze von abgebrochenen Transaktionen nicht unnötig die DB. Es ist einstellbar, ob er mit direkter oder relativer Adressierung arbeitet. Er arbeitet zur Zeit mit 2PL und high-concurrency-B-Baum-Sperren. Im Moment können nur Datensätze gesperrt werden. Deshalb ist der Manager im Programm nicht als eigenständiger Manager implementiert, sondern in den Datensatz-Manager eingebaut. In Zukunft wird zur Ermöglichung echter verteilter DBs 3PL mit 2-Phasen commit verwendet.

Page 104: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 90

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

alleDBS ready to

commit?

Start

Ende

ja

nein

Zuweisung DBS und Transaktionsnummer

an Koordinator

Anweisung an alle DBS (außer Koordinator), Commit vorzubereiten

DBS liefern commit zurück

DBS schreiben ready-to-commit in BI

(Koordinator, TNR)

Koordinatorcommit o.k.?

abnormaler Abbruch

neinnein

andere DBS müssen Transaktion abbrechen und dies in BI schreiben

Koordinator-commit und schreiben in BI und LOG

andere DBS müssen Transaktion abbrechen und dies in BI schreiben

andere DBS sollen commit ausführen und

Änderungen im BI speichern

ja

nein

commitder anderen DBS

o.k.?

ja

habenandere DBS

Abbruch durchgeführt?

ja

Bild 4.5: Algorithmus für 2-Phasen-Commit

Page 105: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 91

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.3.6 Transaktions-Manager

Klasse: K_TM (K0_TM, KL_TM, KN_TM) Instanz: TM Laufzeit-Parameter: Log-Modus Jeder Transaktion wird ein eindeutiger Identifier zugeordnet (Datentyp: __TNR). Operationen:

• __C_TNR begin(__LOCK, __PRIO) Ordnet den nächsten freien Identifier zu, legt eine Struktur an, erhöht die Zahl der ak-tiven Transaktionen und gibt den Identifier an den aufrufenden Prozess zurück.

• void commit(__C_TNR) Versucht, eine Transaktion erfolgreich zu beenden.

• void abort(__C_TNR) Bricht eine Transaktion ab.

Zur Zeit existiert die Beschränkung, dass sich die Puffer von offenen Transaktionen im RAM befinden müssen. Diese Beschränkung kann bei Verwendung komplexerer Algorithmen jederzeit aufgehoben werden. Im Moment war die Implementierung dieser Algorithmen aus Zeitgründen nicht möglich. Nachteil dieser Beschränkung ist, dass die Transaktionsgröße beschränkt wird und nicht beliebig groß sein kann.55

4.3.7 Zugriffsverfahren

Klasse: K0_Index (KI_... verschiedenen Ableitungen) Instanz: - Eine gutes DBS sollte sicherlich mehrere Verfahren anbieten. Dabei hängt das Verfahren von folgenden Punkte ab:

• Sind die Kosten der periodischen Reorganisation des Index oder der Hash-Struktur akzeptabel?

• Wie häufig wird eingefügt bzw. gelöscht? • Ist es besser, die durchschnittliche Zugriffszeit auf Kosten der worst-case Zeit zu

verbessern? • Welche Anfrageprinzipien werden gewöhnlich verwendet?

55 Eine beschränkte Transaktionsgröße ist z.B auch in professionellen Systemen, wie z.B. Progress

vorhanden.

Page 106: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 92

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Bild 4.6: Objektstruktur des abstrakten Indizes

Bild 4.7: Objektstruktur des abstrakten Indexiterators

Aktuell sind nur Indexverfahren (keine Hashing-Verfahren) implementiert, um harte Realzeit-fähigkeiten implementieren zu können56. 56 Mit einer Hash-Struktur hat man die bekannten Probleme bei der worst-case Berechnung.

Page 107: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 93

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Aus Gründen der Speicherökonomie wurde ein B-Baum dem B+-Baum bevorzugt. Die ursprünglich eindimensionalen Indizes wurden aufgrund einer konkreten Anforderung zu mehrdimensionalen Indizes erweitert. Dabei ist es möglich, die verschiedenen Verfahren beliebig zu mischen. Zugriffsverfahren

B-Baum übliche B-Baum-Funktionalität

feste Liste Liste mit einer festen vorgegebenen Anzahl von Elementen

Flexible Liste

Liste, die jeweils um weitere Blöcke erweitert werden kann. Es kann eine maximale Anzahl von Blöcken angegeben werden. Beim Über-schreiten dieser maximalen Anzahl wird der älteste Block gelöscht (Ringliste)

Ringliste wie feste Liste, beim Überlauf wird jedoch das älteste Element ge-löscht

Tabelle 4.8: Zugriffsverfahren Jedes der angegebenen Zugriffsverfahren ist in 3 Varianten verfügbar:

• Jeder Schlüssel besitzt eigenen Datensatzzeiger. • Jeder Block besitzt einen Zeiger auf einen Block von Datensätzen. • Der Datensatz ist komplett im Schlüssel enthalten, es existieren keine Zeiger.

Unter Berücksichtigung der Betrachtungen von Seite 69 ist es möglich, jeden Index während der Laufzeit an- und abzuschalten. Während das Abschalten nur einen schreibenden Festplattenzugriff erfordert, ist beim Anschalten zu beachten, dass der Index anhand eines anderen komplett neu aufgebaut werden muss. Dies kann einige Zeit in Anspruch nehmen, ist jedoch wesentlich effektiver, als jeden Wert einzeln in den Index einzutragen, da schnelle-re Algorithmen verwendet werden können. Die Zugriffsverfahren können beliebig mehrdimensional geschachtelt werden. Der erste Index einer jeden Tabelle ist der Primärindex. Eigene Arbeiten mit DBS haben folgendes ergeben: Oft existieren Tabellen, welche gleichartig aufgebaut sind. Z.B. kann in einem PPS-System eine Tabelle existieren, welche Stücklisten enthält. Um die praktische Arbeit zu beschleuni-gen, kann eine zweite Tabelle angelegt werden, welche aufgelöste Stücklisten enthält. Um sich bei Strukturänderungen den Aufwand zu ersparen, beide Tabellen zu ändern, reicht es aber auch, eine Tabelle anzulegen und in ihr ein Flag unterzubringen, welche die eigentliche Tabelle selektiert. Im Beispiel wäre dies ein Flag aufgelöst oder nicht. In der praktischen Arbeit wird nun aber im Prinzip nur mit der einen oder anderen Tabelle gearbeitet. Hier bietet es sich an, die Daten vorzuselektieren. Dies könnte so aussehen, dass durch einen speziellen Befehl erst einmal vorgegeben wird, dass ab jetzt nur mit der aufgelö-sten Variante der Stückliste gearbeitet wird. Falls die Vorselektion eine bestimmte Index-

Page 108: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 94

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

größe nicht überschreitet, kann der komplette Index im RAM gehalten werden, und das System wird sehr schnell. U.U. ist hier kein B-Baum, sondern ein anderes Suchverfahren zu verwenden. (B-Bäume sind speziell auf externes Suchen optimiert, deshalb existieren im RAM schnellere Suchverfahren.)

4.3.8 Realzeit-Manager

Klasse: K_EM Instanz: K_EM::EM Aufgrund seiner Komplexität und der zeitlichen Beschränkungen ist er nicht mit aller Funktio-nalität implementiert. Es ist jedoch die Voraussetzung dafür geschaffen worden. Folgende Module existieren:

• Berechnung von Zeiten einzelner Objekte • Dictionary-Tabellen • Bearbeitung kontrollierter Redundanzen (Redundanzen sind dem System bekannt

und werden automatisch aktualisiert.) Der Realzeit-Manager besitzt Zugriffsrechte auf alle anderen Manager. Damit ist es möglich, Funktionalitäten, wie CP oder Backup, zu blockieren.

4.3.9 Kommunikations-Manager

Klasse: K0M_Kommunikation Instanz: Kommunikation Als Kommunikations-Manager wird eine Implementierung in Zusammenarbeit mit Dipl. Ing. Rolf Fischer verwendet. Er ist die Basiskomponente für die Kommunikation über die momen-tan implementierten Protokolle:

• RS232 • UDP • CAN • RS232-CAN-1 • RS232-CAN-2 • TLI57

Jedes dieser Protokolle besitzt eine eigene Ableitung des Kommunikations-Managers. Zur gleichzeitigen Verwendung von mehreren Protokollen wird eine Verteilung über statische Funktionen an die entsprechenden Manager vorgenommen. Der Kommunikations-Manager besitzt eine Schnittstelle für den Realzeit-Manager. 57 Das Transportunabhängige Protokoll TLI (arbeitet mit TCP oder SPX) ist in Vorbereitung.

Page 109: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 95

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Zur Verminderung von Datenmengen soll zukünftig eine Datenkomprimierung integriert werden.

4.3.10 Gesamtstruktur der Datenbank-Engine

Bild 4.8: Objektstruktur der Engine

Page 110: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Implementierungskonzept Seite 96

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4.4 Technische Daten des „MRDB“-Systems 58

Technische Daten Datentypen:59 _INTEGER_

_FLOAT_ _CHAR_ _BOOL_ _VARCHAR_ _TIMESTAMP_

Indextypen:60 B-Baum Liste Ringliste Flexliste

Anzahl Tabellen: 231 (2.147.483.648) __TABELLE

Anzahl Spalten pro Tabelle: 231, jedoch ist die Datensatzlänge auf 64kByte beschränkt __FELD

Anzahl Datensätze pro Tabelle 231 (2.147.483.648) Anzahl Indizes pro Tabelle 231 (2.147.483.648)

__INDEX Anzahl Felder im Index 231 (2.147.483.648)

__INDEXFELD DB-Größe __ADRESSE physische Adressen 231 (2GB) logische Adressen 231 * Mindestgröße61 (>16GB)

Tabelle 4.9: Technische Daten These: Bei Verwendung eines kompletten aktiven DDS ist keine DDL notwendig, da die

Funktionen mit der DML auf Dictionary-Tabellen (und damit verbundener Prozeduren) ausgelöst werden.

Der dritte Sprachbestandteil ist die sogenannte DCL (Data Control Language). Hiermit werden Informationen zum Umfeld der DB gewartet. Dies betrifft vor allem Benutzer- und Sperrmechanismen.

58 Obwohl versucht wurde, das DBMS möglichst hardwareneutral zu programmieren, sind einige Parameter

in manchen Systemen beschränkt. In den Daten werden Mindestparameter angegeben, welche bei allen Systemen garantiert werden können. Sie können teilweise wesentlich günstiger liegen.

59 Die Datentypen sind aufgrund der objektorientierten Programmierung beliebig erweiterbar. 60 Die Indextypen sind aufgrund der objektorientierten Programmierung beliebig erweiterbar. Alle Indizes sind

mehrdimensional gestaltbar und können dabei beliebig gemischt werden. Für alle Indizes existiert eine Va-riante mit einzelner Datensatzhaltung bzw. Datensatzhaltung in Blöcken.

61 Der kleinste Datenwert ist bei der Linux Implementierung 4 Byte groß. Da ein Datensatz jedoch mehrere Felder enthält, bzw. bei nur einem Feld komplett im Index gehalten werden kann und nicht als Datensatz existieren muss kann die kleinste Einheit ohne Einschränkungen auf 8 Byte gesetzt werden.

Page 111: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Prototyperprobung in einem Industrieunternehmen Seite 97

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

5 Prototyperprobung in einem Industrieunternehmen62 Das implementierte RZ-DBS wird seit 1996 in einer Testumgebung eingesetzt. Es ist Kernstück eines kombinierten BDE- (PZE-) und MDE-Systems, das an einen Ferti-gungsleitstand und ein PPS-System angeschlossen ist. In der ersten Etappe wurde seit Mai 1997 bis September 1997 eine lokale DBS-Version getestet. In der zweiten Etappe wird seit September 1997 eine Client-Server-Kombination verwendet. Dabei sind 6 DB-Clients an den Server angeschlossen. In der dritten Etappe wurden ab Sommer 1998 24 Clients an den Server angeschlossen. Seit Januar 1999 läuft das System im Dauereinsatz.

5.1 Server

5.1.1 Hardware

Hardware in Testumgebung:

• PC mit Intel Pentium Prozessor 133 MHz • 32 MB RAM • 14” monochrom Monitor • Modem für Fernwartung • 2 Netzwerkkarten (Trennung der Netze von Büro und Werkhalle) • (Echtzeituhr) • USV seit April 1998 • 1 Festplattenkontroller SCSI/PCI (Adapdec 1640W) • 3 Festplatten a 2GB

o 1 Festplatte: Betriebssystem, Remote-System für Terminals o 2 Festplatten für DBS

Platte 1: DB, BI Platte 2: LOG, AI

o Normalerweise werden noch 2 Festplatten für das Online-Backup benötigt. Im Moment geschieht das Backup über Kreuz mit den schon vorhandenen 2 DBS-Festplatten.

Da das System im Dauereinsatz laufen muss, muss neben der ständigen Verfügbarkeit der Daten durch die Software auch eine ständig verfügbare Hardware vorhanden sein. Dafür bieten sich redundante Hardwaresysteme an. Aus Kostengründen konnte ein solches System jedoch nicht verwendet werden. Daher wurde zur Sicherung der Festplatteninhalte

62 Wie im Vorwort, Seite 1 beschrieben, bezieht sich die Beschreibung auf den Stand Ende 1998. Die

Software wurde mittlerweile einem kompletten Redesign unterworfen. Dabei stand die Dauerbetriebsfähig-keit im Fordergrund. Gegenüber dem beschriebenen Konzept wird nun ein Spiegelungsverfahren in Ver-bindung mit redundanter Hardware (3 redundante Server) eingesetzt.

Page 112: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Prototyperprobung in einem Industrieunternehmen Seite 98

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

ein RAID-Controller eingesetzt. Die Festplatten befinden sich in einem externem Gehäuse. Der eigentliche PC ist doppelt vorhanden. Bei einem Ausfall des PCs werden die Festplatten einfach an den zweiten PC angeschlossen und die Arbeit kann weitergehen. Hardware in Endversion63:

• 2 PC mit Intel Pentium Celeron Prozessor 333 MHz • Mainboard ASUS P2BS 440 BX mit 100 MHz Frontsidebus • 64 MB DIMM RAM • Grafikkarte: ATI 4MB AGP • 14“ monochrom Monitor • 1 Festplattenkontroller SCSI-UW/U2 (Adapdec 27xx) Onboard • 1 RAID-Controller ICP Vortex GDT 6117 RP • Modem für Fernwartung • 2 Netzwerkkarten (Intel EtherPro) 10/100MBit/s (Trennung der Netze von Büro und

Werkhalle), 1* OnBoard, 1*PCI • (Echtzeituhr) • APC-USV Smart UPS 1000 • 6 Festplatten IBM DEAS 32160, 2,06GB UW-SCSI • Streamer HP 35480A 2/4 GB SCSI-DAT mit Adapter von SCSI-UW-SCSI

Schwachpunkt in der aktuellen Konfiguration ist sicherlich das Netzteil im externen SCSI-Gehäuse. Festplattenaufteilung: Die Festplattenaufteilung wurde der Einfachheit halber recht simpel gestaltet. Hier ist sicher noch ein weiter Spielraum in Bezug auf Performance und Sicherheit möglich. Physikalisches Device

Plattenpaar (RAID 1)

Logisches Device

Größe Mountpunkt Files

0

1

1 /dev/sda1 /dev/sda2 /dev/sda3

450 MB 50 MB 1,5 GB

/ swap /usr/kids

2

3

2 /dev/sdb1 2 GB /mrdb1 shdb.ini shdb.res shdb.log shdb.mr

63 siehe Anmerkungen auf Seite 1.

Page 113: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Prototyperprobung in einem Industrieunternehmen Seite 99

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Physikalisches Device

Plattenpaar (RAID 1)

Logisches Device

Größe Mountpunkt Files

4

5

3 /dev/sdc1 2 GB /mrdb2 shdb.ai shdb.bi

Tabelle 5.1: Festplattenaufteilung

5.1.2 Software

Als Betriebssystem wurden die Linux Versionen 1.1.36, 2.0.0 und 2.0.36 installiert. Aktuell ist die Version 2.0.36 in der SuSe Distribution 6.0 installiert. Zusätzlich ist der Boot-Dämon für das remote Booten der Clients aktiviert. Als Applikation ist das in der Arbeit vorgestellte RZ-DBS installiert. Es wird der Server des RZ-DBS in der Version 1.4 verwendet.

5.1.3 Fehlerdiagnose und Fehlerbehebung

Hardwarefehler Fehlerbehebung Fehlerrate

• Festplatten-Kontroller de-fekt

Kontroller wechseln. Bis zum Wechseln ist keine Weiterarbeit möglich.

0%

• 1. Platte defekt Neue Platte einbauen. Bis zum Einbau der neuen Platte ist keine Arbeit möglich. Leere DB anlegen, anhand von Backup, LB und AI die neue DB mit Daten füllen.

0%

• 2. Platte defekt Neue Platte einbauen. Bis zum Einbau der neuen Platte ist keine Arbeit möglich. Nun existieren 2 Varianten: 1. Backup anlegen, dadurch werden LB und AI automatisch initialisiert. 2. Anhand eines alten Backups die LB- und AI- Fi-les neu anlegen.

0%

• beide Platten defekt

Im Normalfall sind alle Daten verloren Eine eventuelle Rettung der Daten ist nur durch Spezialfirmen möglich.

100%

• andere Hard-waredefekte

Sie betreffen die DB nicht direkt. Nach Reparatur der entsprechenden Hardware kann ohne weiteres gearbei-tet werden.

0%

Page 114: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Prototyperprobung in einem Industrieunternehmen Seite 100

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

Softwarefehler Fehlerbehebung Fehlerrate

• DB defekt Alte DB aus Backup rücksichern. Anhand von LB und AI die DB auf den aktuellen Stand bringen.

0%

• LB defekt Backup anlegen. 0%

• BI defekt Wird nur während laufendem Betrieb benötigt. 0%

• AI defekt Backup anlegen. 0%

Tabelle 5.2: Fehlerbehandlung

5.2 Clients

5.2.1 Hardware

Industrie PCs der Firma Delog.

• PC 486DX4/75 / P133 • 8 MB RAM / 16 MB RAM • Netzwerkkarte (3-Com on Board) mit Boot-Prom (32k) • LCD-VGA-Farbdisplay (640 * 480 Pixel) • Touchscreen (digital)

5.2.2 Software

Betriebssystem: Linux Version 2.0.0 mit an der TU BAF, IfAT entwickelten Modulen für CAN-Bus und Touch-Screen, gpm 1.09, ncurses 3.0.0

DB: MRDB-Client 1.4

Page 115: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Experimentelle Ergebnisse und Zusammenfassung Seite 101

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

6 Experimentelle Ergebnisse und Zusammenfassung

6.1 Dauerbetriebsfähigkeit

Die Dauerbetriebsfähigkeit wurde durch Implementierung zusätzlicher Komponenten und Berücksichtigung des Problems bei der Konzipierung des DBMS ermöglicht. Sie kann durch einfache Tests nachgewiesen werden. Die Implementierung ist nur eine minimale Implemen-tierung. Es wurde jedoch gezeigt, dass bessere Varianten (Spiegelung) teilweise durch Betriebssystemkomponenten und/oder Hardware realisiert werden können. Es ist geplant, eine Spiegelung direkt in das RDBS zu integrieren, da dadurch Performancevorteile entste-hen (U.a. kann durch die Integration der Spiegelung die Arbeit mit den AI- und BI-Files verbessert werden). In der aktuell laufenden Version ist die Umstellung nun erfolgt.

6.2 Realzeitfähigkeit

Die Realzeitfähigkeit wurde im Zentrum der Arbeit konzeptionell bearbeitet. Die Funktionalität ist jedoch nur temporär implementiert. Es wurde gezeigt, dass eine Implementierung der Realzeitfähigkeit im Wesentlichen durch einen erweiterten Sprachcompiler möglich ist. Alle anderen Komponenten des DBMS sollten jedoch optimal mit dem Realzeit-Manager zusammenarbeiten. In erster Abschätzung kann jedoch angemerkt werden, dass die maximalen Antwortzeiten wesentlich größer als die durchschnittlichen Antwortzeiten sind. Daher ist streng zu prüfen, ob für den entsprechenden Einsatzfall ein RZ-DBMS für weiche Anforderungen genügt. Die Antwortzeiten setzen sich im Wesentlichen aus Festplattenzugriffen zusammen. Daher sind bei großen Datenbanken Antwort-Zeiten bis in den Sekundenbereich möglich. Für DBMS der AT müssen alle Komponenten eines herkömmlichen DBMS vorhanden sein. Es sollten noch einige zusätzliche implementiert werden. Die Festplattenzugriffszeiten sind für alle DB-Files (AI,BI,DB,LOG) zu ermitteln. Die Prioritäten der Anforderungen sind in DB-Tabellen abzulegen Auch Triggerfunktionen sind als Stored Procedures abzulegen, damit sie berechenbar sind. (Sie erhöhen das Zeitverhalten für create, update, delete.)

6.3 Portabilitätsproblematik

Die Portabilität wurde für unterschiedliche Betriebssysteme und C-Compiler nachgewiesen.

• Betriebssystem DOS Das Betriebsystem wurden in den Versionen MS-DOS 6.0, MS-DOS 6.2 und MS-DOS 7.0 (Windows 95) verwendet. Die Compilation erfolgte mit: o Borland C++ 3.1

Diese Version verfügt standardmäßig nicht über eine Schnittstelle zur Anbin-dung von DLLs. Deshalb ist kein TCP mit Standardkomponenten möglich

Page 116: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Experimentelle Ergebnisse und Zusammenfassung Seite 102

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

(winsock.dll). Eine eigene Implementierung von TCP bzw. UDP schied aus verschiedensten Gründen aus. Im Verlauf der Entwicklung wurden 4 Compi-ler-Fehler entdeckt: (Speicher-Fehler bei der Funktion „stat” (hinterlässt 32 Byte auf Heap); teilweise fehlerhafte Segmentadressen bei Einbindung von Assembler-Quellen; teilweise Rechenfehler bei Potenzierung (nicht genauer untersucht), logischer Fehler bei 32-bit Vergleichen (intern mit 16 bit und OR))

o Borland C++ 4.0 Es erfolgten keine Laufzeit-Tests. Das Programmsystem ließ sich jedoch komplett übersetzen.

o Borland C++ 4.5 Es erfolgten keine Laufzeit-Tests. Das Programmsystem ließ sich jedoch komplett übersetzen.

• Betriebssystem Windows 95, Windows 98, Windows NT

Momentan erfolgt eine Anpassung an MS-VC++ 6.0 Eine Übersetzung ist komplett möglich, es sind noch kleinere Laufzeitfehler in der Client-Server Umgebung zu prüfen.

• Betriebsystem Linux

Die rasante Entwicklung von Linux hatte zur Folge, dass mehrere Versionen zum Einsatz kamen. Als aktuelle Version wird 2.0.29 verwendet. Es kann jedoch festge-stellt werden, dass durch das Betriebssystem keine wesentlichen Probleme entstan-den sind. Die Compilation erfolgte mit: o GNU-C 2.6.3 mit Patch für Templates

Es stellten sich gewisse Inkompatibilitäten zur Template-Behandlung bei Bor-land-C heraus. Diese konnten jedoch durch Umgehen bestimmter Konstellati-onen umgangen werden.

o GNU-C 2.7.2 Die Template-Behandlung ist wie bei Version 2.6.3 geschildert. Es trat ein Fehler bei der Formatierung von Streams auf, welcher unter Borland-C und unter Version 2.6.3 nicht beobachtet wurde. Dieser Fehler konnte durch Um-stellung der Befehle behoben werden. In Zusammenhang mit der Umstellung auf diese C-Version wurde das RZ-DBMS auf Shared Libraries umgestellt.

• HP-UX Version A.09.01 auf Workstation A9000/730

o GNU-C 2.6.3 Da nur Programmteile erprobt wurden, war der Patch für die Template Be-handlung nicht notwendig. Es traten keine Probleme auf.

Die Ergänzung um verschiedene Index- und Datentypen hat gezeigt, dass das objektorien-tierte Programmkonzept offen für derartige Ergänzungen des Systems ist. Die Implementierung und Anwendung spezieller Indextypen zeigt den Vorteil des DBS gegenüber herkömmlichen DBS bei der Prototypanlage.

Page 117: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Experimentelle Ergebnisse und Zusammenfassung Seite 103

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

6.4 Bedienung

Die Bedienung ist durch eine auf den Datenbank-Kern aufgesetzte Oberfläche sehr einfach. Es ist möglich, das System komplett ohne Tastatur mit Maus oder Touchscreen zu bedienen. Der eigentliche DB-Entwurf kann jederzeit verändert werden und muss anfangs auch nicht optimal sein. Durch eine Beratungskomponente und automatisch kontrollierte Redundanz werden Schwachstellen erkannt und können jederzeit beseitigt werden.

6.5 Zusammenfassung und Ausblick

Zielstellung der Dissertation ist der Entwurf eines industriellen Datenbanksystems. Industriell eingesetzte DBS benötigen im Wesentlichen nur 2 Eigenschaften, welche durch herkömmliche DBS unzureichend unterstützt werden. Dazu zählen die Realzeitfähigkeit und die Dauerbetriebsfähigkeit. Die Dauerbetriebsfähigkeit sollte nach der Theorie der DBS kein Problem darstellen, wenn man Mirroring-Verfahren verwendet. Diese sind zwar nicht sehr üblich, von der Theorie jedoch ausreichend entwickelt. Zentrales Kernelement der vorliegenden Arbeit sind daher die Betrachtungen zur Realzeitfä-higkeit des DBS. Die Untersuchungen gelangten zu der nicht erwarteten Erkenntnis, dass für die Realisierung dieser Eigenschaft in DBS keine neuartigen Konzepte, Programme oder Algorithmen notwendig sind. Die Realzeitfähigkeit wird lediglich durch eine Erweiterung der bisher bekannten und vorhan-den Funktionalitäten erreicht und erfordert nur wenige Voraussetzungen, wie in Kapitel 3 beschrieben. Weiterhin wurde nachgewiesen, dass sie von der konkreten Implementierung des DBMS abhängt. Da sich Datenbestände dynamisch entwickeln, ist es notwendig, alle Realzeitanforderungen und -bedingungen im DBS zu speichern. Dazu bietet sich das Data Dictionary und das Konzept der Stored Procedures an. Ein Sprachcompiler muss neben seiner eigentlichen Übersetzungsaufgabe sämtliche relevante Daten der Procedur ermitteln und speichern. Daher ist der größte Erweiterungs-aufwand gegenüber herkömmlichen DBS sicherlich beim Sprachcompiler. Das RZ-DBS ist, sofern es vollständig implementiert ist, selbstständig in der Lage, die Einhaltung der Realzeitanforderungen zu gewährleisten. Im Ergebnis der theoretischen Untersuchungen und der praktischen Implementierungsarbeit ist ein RZ-DBS mit folgenden Eigenschaften entstanden:

• echtes aktives DDS • modular, flexibel und portabel • skalierbar • besonders auf die Anforderungen der Industrie abgestimmt • unter gegebenen Randbedingungen realzeitfähig (ohne experimentellen Nachweis) • transparent und damit einfach zu nutzen • kontrollierte Redundanz zur einfachen und sicheren Verwaltung der Daten vorhanden • u.a. mit Hilfe der kontrollierten Redundanz ist ein automatisches Re-Design der DB

Page 118: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Experimentelle Ergebnisse und Zusammenfassung Seite 104

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

möglich • komplett objektorientiert programmiert • extrem flexible Datenformatierung (auch zur Laufzeit) • Client-Server-Kommunikationsaufwand wurde minimal gehalten64 • Sequenzen, Trigger, gespeicherte Funktionen, vordefinierte Initialwerte implementiert • mehrdimensionale Indizes sind möglich • die Domain-, Relation- und referentielle Integrität wird durch das gewählte Modell

abgedeckt • eine explizite Integrität kann durch Trigger erreicht werden

Das DBS wurde teilweise in der Industrie erprobt. Mittlerweile erfolgte ein komplettes Redesign des DBS. Dabei wurden die folgenden Funktio-nalitäten überarbeitet bzw. ergänzt:

• Dauerbetriebsfähigkeit durch Mirroring • Ausfallsicherheit durch redundante Server • 4GL mit speziellen Ausdrucksmitteln und separater Anwendungsbeschreibungsspra-

che • Möglichkeit von Softwareupdates im laufenden Betrieb

Trotzdem sind für die vollständige Implementierung des RZ-DBMS noch Ergänzungen und Überlegungen erforderlich, deshalb ist eine Weiterführung der Arbeit zu empfehlen. Im Zusammenhang mit der Fortsetzung ist eine optimale Strategie für Pufferverwaltung unter Beachtung der Realzeitanforderungen (bekannte Prozeduren und (zeitliche) Anforderungen) zu untersuchen. Aber auch die Berechnung der Realzeitfähigkeit unter dem Ansatz, dass Transaktionen zeitlich beschränkt werden sowie ein Vergleich zum Vorschlag dieser Arbeit ist wünschens-wert. Die vorliegende Arbeit geht von der ursprünglichen Realisierung mit BI- und AI-Files aus. Da durch das Software-Redesign eine Umstellung auf Mirroring erfolgte, sind die entsprechen-den Formeln aus der vorliegenden Arbeit für diese Implementierung abzuleiten.

64 Selbst bei Kommunikation über RS232 mit 9600 Baud sind keine Geschwindigkeitseinbußen spürbar.

Page 119: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A1

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

VII Literaturverzeichnis65

/Ag85/ ............................................................................................................................... (DBS) AGRAWAL R.; DEWITT D.J. Integrated concurrency control and recovery mechanism: design and performance evalua-tion. ACM TODS; 1985; 10 (4); 529-64 /As99/ ............................................................................................................................... (DBS) ASPENTECH InfoPlus.21 - The Real Time Database http://www.aspentech.com/ /Ba97/ ......................................................................................................................... (Realzeit) BARABANOV, VICTOR Real-Time features in Linux, A Real-Time Scheduler, RT-FIFOs, Time-related functions in RT-Linux 1996, 1997 http://luz.cs.nmt.edu/~rtlinux/source/current/doc/ /BaHa97/........................................................................................................................... (DBS) BARUAH, SANJOY K.; HARITSA, JAYNAT R. Scheduling for Overload in Real-Time Systems IEEE Transaction on Computers, Vol. 46, No. 9, September 1997 http://www.cs.unc.edu/~baruah/Papers/baruahHaritsa1997.pdf /Be92/ ............................................................................................................................... (DBS) BELL, DAVID; GRIMSON, JANE Distributed Database Systems Addison-Wesley Publishing Company; 1992; ISBN 0-201-54400-8 /Be97/ ............................................................................................................................... (DBS) BERNSTEIN, P. A.; HADZILACOS; GOODMAN, N. Concurrency Control and Recovery in Database Systems Addison-Wesley Publishing Company; 1987; ISBN

65 Da die vorliegende Arbeit fachgebietsübergreifend ist, wird zur klareren Trennung am rechten Rand das

Fachgebiet der entsprechenden Literaturquelle angegeben. Es wird unterteilt in: DBS, Programmierung, Realzeit und Norm.

Page 120: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A2

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Be94/ ............................................................................................................................... (DBS) BERNSTEIN, P.A.; GOODMAN, N. An algorithm for concurrency control and recovery in replicated distributed databases. ACM TODS; 1984; 9 (4); 596-615 /Beu96/ ............................................................................................................................. (DBS) BEUTER, T.; DADAM P. Prinzipien der Replikationskontrolle in verteilten Datenbanksystemen GI Informatik Forschung und Entwicklung 1996, 11, 4, 203-212 /Bi97/ ................................................................................................................................ (DBS) BINTO, GEORGE; HARITSA, JAYNAT Secure Transaction Processing in Firm Real-Time Database Systems International Conference on Management of Data, May 13-15, 1997, Tucson, Arizona, USA. ACM Press 1997 /Bi90/ .............................................................................................................(Programmierung) BIC, LUBOMIR; SHAW, ALAN C. Betriebssysteme - Eine moderne Einführung Carl-Hanser Verlag, Prentice-Hall International; 2. Auflage, 1990; ISBN 3-446-15573-2 /Blo91/ ...........................................................................................................(Programmierung) BLOMER, JOHN Power Programming with RPC O´Reilly & Associates Inc.; 1991; ISBN 0-937175-77-3 /Bo97/ ............................................................................................................(Programmierung) BORLAND GMBH Programmierhandbücher C++ Versionen 3, 3.1 und 4 Monzastr. 4c, 63225 Langen 1993 - 1997 /Bo92/ ............................................................................................................(Programmierung) BORLAND GMBH Programmierhandbücher Paradox-Engine 3.0 Monzastr. 4c, 63225 Langen 1990, 1991, 1992 /Bo90/ ............................................................................................................(Programmierung) BORLAND GMBH Programmierhandbücher dBASE IV V2.0 Monzastr. 4c, 63225 Langen 1990

Page 121: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A3

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Bo93/ ............................................................................................................................... (DBS) BOWMAN, JUDITH S.; EMERSON, SANDRA L.; DARNOVSKY, MARCY The Practical SQL-Handbook Second Edition Addison-Wesley Publishing Company; 1993; ISBN 0-201-62623-3 /Ca94/ ............................................................................................................................... (DBS) CASTANO, SILVANA; FUGINI, MARIAGRAZIA; MARTELLA, GIANCARLO; SAMARATI, PIERANGELA Database Security Addison-Wesley Publishing Company; 1994; ACM PRESS; ISBN 0-201-59375-0 /Ch98/. .............................................................................................................................. (DBS) CHAKRAVARTHY, S.; HONG D.; JOHNSON T Real-Time Transaction Scheduling: A Framework for Synthesizing Static and Dynamic Factors Database Systems Research and Development Center, Computer and Information Sciences Department, University of Florida, Gainsville, FL 32611 Real-Time Systems, Volume 14, Number 2, March 1998 http://www.informatik.uni-trier.de/~ley/db/journals/rts/rts14.html /CHIP/ ............................................................................................................(Programmierung) CHIP - DAS COMPUTERMAGAZIN Zeitschrift Vogel-Verlag & Druck GmbH & Co. KG; 97064 Würzburg Jahrgänge 1995-2002 /Chip89/ ............................................................................................................................ (DBS) CHIP SPEZIAL INGRES - Datenbankmanagement der Zukunft Vogel-Verlag, Würzburg; 1989; ISBN 3-8023-1012-8 /Co70/ ............................................................................................................................... (DBS) CODD, E.F. A relational Modell of data for large shared databanks. Communications of the ACM; Volume 13, Number 6, S. 377-387, June 1970 /Co86/ ............................................................................................................................... (DBS) CODD, E. F. The Twelve Rules for Relational DBMS in: Report EFC-4; The Relational Institute, San Jose, CA; 1986 /Co90/ ............................................................................................................................... (DBS) CODD, E. F. The Relational Model for Database Management; Version 2 Addison-Wesley Publishing Company; 1990; ISBN 0-201-14192-2

Page 122: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A4

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Co88/ ............................................................................................................(Programmierung) COMER, D. Internetworking with TCP/IP Principles, Protocols and Architecture; 4th edition Prentice-Hall, Englewood Cliffs, NJ; 2000; ISBN 0-13-01830-6 /Da91/ ............................................................................................................(Programmierung) DANNEGGER, CHRISTIAN; GEUGELIN-DANNEGGER, PATRICIA Parallele Prozesse unter UNIX Carl-Hanser Verlag; München, Wien; 1991; ISBN 3-446-15911-8 /Da84/ ............................................................................................................................... (DBS) DATE, C.J. A Guide to THE SQL STANDARD (second edition) Addison-Wesley Publishing Company; 1984; ISBN 0-201-50209-7 /Da93/ ............................................................................................................................... (DBS) DATE, C. J. An Introduction to Database Systems Vol II Addison-Wesley Publishing Company; 1993; ISBN 0-13-015157-2 /Da86/ ............................................................................................................................... (DBS) DATE, C. J. An Introduction to Database Systems Vol I; 4th edition Addison-Wesley Publishing Company; 1986; ISBN 0-201-14201-5 /Da87/ ............................................................................................................................... (DBS) DATE, C. J. What is a Distributed Database System Codd and Date Consulting Group (C&DCG); Febr. 1987 /DIN 44300/ .....................................................................................................................(Norm) DIN 44300 TEIL 1-9 Informationsverarbeitung; Begriffe Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Nov. 1980, Nov. 1988, Mär. 1995 /DIN 44301/ .....................................................................................................................(Norm) DIN 44301 Informationsverarbeitung; Begriffe Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Nov. 1984

Page 123: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A5

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/DIN 66001/ .....................................................................................................................(Norm) DIN 66001 Informationsverarbeitung; Sinnbilder und ihre Anwendung Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Dez. 1983 /DIN 66020/ .....................................................................................................................(Norm) DIN 66020 Funktionale Anordnung an die Schnittstelle zwischen DEE und DÜE (V.24) Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Mai 1981 /DIN 66021/ .....................................................................................................................(Norm) DIN 66021 TEIL 1-12 Schnittstellen-Protokolle zwischen DEE und DÜE Deutsches Institut für Normung e.V. Beuth Verlag GmbH; April 1983 /DIN 66232/ .....................................................................................................................(Norm) DIN 66232 Informationsverarbeitung; Datendokumentation Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Aug. 1985 /DIN 66259/ .....................................................................................................................(Norm) DIN 66259 TEIL 1-4 elektrische Eigenschaften der Schnittstellenleitungen (V.28) Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Mai 1981, Mär. 1983, Sept. 1983 /DIN ISO 1177/ ................................................................................................................(Norm) DIN ISO 1177 Datenkommunikation; Zeichendarstellung bei Serienübergabe Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Nov. 1989 /DIN ISO/IEC 9579/ .........................................................................................................(Norm) DIN ISO/IEC 9579 Informationstechnik; Kommunikation offener Systeme; Fernzugriff auf Datenbanken Teil 2: SQL-Spezialisierung Deutsches Institut für Normung e.V. Beuth Verlag GmbH; Nov. 1994

Page 124: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A6

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Do94/ ............................................................................................................(Programmierung) DOHMEN, WILFRIED Kooperative Systeme - Techniken und Chancen Carl-Hanser Verlag, München, Wien; 1994; ISBN 3-446-17631-4 /El99/ ................................................................................................................................ (DBS) ELMASRI, RAMEZ; NAVATHE, SHAMKANT B. Fundamentals of Database Systems, 3th Edition Addison-Wesley Publishing Company; 1999; ISBN 0-8053-1748-1 /Ep97/ ............................................................................................................(Programmierung) EPLIN, JERRY Linux as an Embedded Operating System Oktober 1997 http://www.embedded.com/97/fe39710.html /Et94/ .............................................................................................................(Programmierung) ETSCHENBERGER, KONRAD CAN Controller-Area-Network Carl-Hanser Verlag, München, Wien; 1994; ISBN 3-446-17596-2 /FI127-2/ ..........................................................................................................................(Norm) FIPS-PUB 127-2 Announcing the Standard for Database Language SQL Final Draft 25. Jan. 1993 /Fi97D/ ...........................................................................................................(Programmierung) FISCHER, ROLF Dokumentation Programmentwicklungssystemsystem ‘KDesktop’ TU BAF, IfAT; 1996-1997 /Fi97P/ ...........................................................................................................(Programmierung) FISCHER, ROLF Dokumentation zum Parser ‘Wiesel’ TU BAF, IfAT; 1997-1998 /FiMü96/.........................................................................................................(Programmierung) FISCHER, STEFAN; MÜLLER, WALTHER Netzwerkprogrammierung unter Linux und Unix Carl-Hanser Verlag, München, Wien; 1996; ISBN 3-446-18677-8 /Fr88/ ................................................................................................................................ (DBS) FRANK, LARS Database Theory and Practice Addison-Wesley Publishing Company; 1988; ISBN: 0-201-18041

Page 125: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A7

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Froe94/ ............................................................................................................................ (DBS) FROESE, JÜRGEN; MOAZZAMI MAHMOUD; RAUTENSTRAUCH CLAUS; WELTER HEINRICH Effiziente Systementwicklung mit Oracle7 Addison-Wesley Publishing Company; 1994; ISBN 3-89319-525-4 /GaRö94/ .......................................................................................................................... (DBS) GABRIEL, ROLAND; RÖHRS, HEINZ-PETER Datenbanksysteme Konzeptionelle Datenmodellierung und Datenbankarchitekturen Springer-Verlag, Berlin, Heidelberg, N. York, London, Paris; 1994; ISBN 3-540-57695-9 /Go95/............................................................................................................(Programmierung) GOLDT, SVEN; VAN DER MEER, SVEN; BURKETT, SCOTT; WELSH, MATT The LinuX Programmer´s Guide Version 0.4 March 1996 http://sunsite.unc.edu/LDP/ /Gu96/............................................................................................................................... (DBS) GUPTA, RAMESH; HARITSA, JAYNAT; RAMAMRITHAM, KRITHI; SESHADRI, S. Commit Processing in Distributed Real-Time Database Systems Indian Institute of Science, Bangalore 560 012, India 17th IEEE Real-Time Systems Symposium (RTSS '96) 04. - 06. Dezember 1996 Washington D.C. http://www.computer.org/proceedings/rtss/7689/76890220abs.htm /Gu97/............................................................................................................................... (DBS) GUPTA, RAMESH; HARITSA JAYANT; RAMAMRITHAM, KRITHI More Optimism about Real-Time Distributed Commit Processing Indian Institute of Science, Bangalore 560 012, India 18th IEEE Real-Time Systems Symposium (RTSS '97) 03. - 05. Dezember 1997 San Francisco, CA http://www.computer.org/proceedings/rtss/8268/82680123abs.htm /Ha94/ ............................................................................................................................... (DBS) HARITSA, JAYNAT R. Approximate Analysis of Real-Time Database Systems Supercomputer Education and Research Centre Indian Institute of Science, Bangalore 560 012, India, 1994

Page 126: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A8

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Ha00/ ............................................................................................................................... (DBS) HARITSA, JAYNAT R.; SESHADRI, S. Real-Time Index Concurrency Control SERC, Indian Institute of Science, Bangalore 560 012, India CSE, Indian Institute of Technology, Bombay 400 076, India IEEE Mai/Juni 2000 (Vol. 12, No. 3, S. 429-447) http://www.computer.org/tkde/tk2000/k0429abs.htm /HaPi93/...................................................................................................................... (Realzeit) HATLEY, DEREK J.; PIRBHAI, IMTIAZ A. Strategien für die Echtzeitprogrammierung Carl-Hanser Verlag; München, Wien; 1993; ISBN 3-446-16288-7 /He92/ ............................................................................................................(Programmierung) HEROLD, HELMUT lex und yacc (lexikalische und syntaktische Analyse) in: UNIX und seine Werkzeuge Addison-Wesley Publishing Company; 1992; ISBN 3-89319-382-0 /He97/ ............................................................................................................(Programmierung) HETZE, SEBASTIAN; HOHNDEL, DIRK; MÜLLER, MARTIN; KIRCH, OLAF U.A. Linux Anwenderhandbuch und Leitfaden für die Systemverwaltung 7. erweiterte und aktualisierte Auflage LunetIX Softfair; 1997; ISBN 3-929764-02-4 http://www.linux-ag.de/linux/LHB/ /He94/ ............................................................................................................(Programmierung) HETZE, SEBASTIAN; HOHNDEL, DIRK Linux Anwenderhandbuch - Ergänzung für die 3. erweiterte und aktualisierte Auflage LunetIX Softfair; 1994 http://www.linux-ag.de/linux/LHB/ /Ic97/..............................................................................................................(Programmierung) ICAZA MIGUEL DE; MOLNAR, INGO; OXMAN, GADI The Linux RAID-2, 4, 5 code 26. Februar 1997 http://www.nuclecu.unam.mx/miguel/raid/ /IEEE 1003.1/ ..................................................................................................................(Norm) IEEE Posix-Standard 1003.1c; Threads /IEEE1003.4/ ...................................................................................................................(Norm) IEEE Posix-Standard 1003.4; realtime extentions for UNIX

Page 127: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A9

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/IEEE95/ ..........................................................................................................................(Norm) IEEE Interface Requirements for Realtime Distributed Systems Communication Technical Paper; July 1995 /In87/..............................................................................................................(Programmierung) INFORMIX SOFTWARE, INC. C-ISAM (Version 3.10) Programmer´s Manual Informix Software, Inc., 4100 Bohannon Drive, Menio Park, CA 94025; Juni 1987 /ISO 2110/ .......................................................................................................................(Norm) ISO 2110 UND ISO 2110 AMD1 Informationstechnik; Datenkommunikation; 25-poliger Steckverbinder und Stiftbelegung Okt. 1989; Sept. 1991 /ISO/IEC 9075/ ................................................................................................................(Norm) ISO/IEC 9075; KORREKTUR 1 (DIN 66315 entsprechend) Informationstechnik; Datenbanksprache; SQL 30. July 1992; Nov. 1992; Aug. 1996 /ISO/IEC 9075-3/ .............................................................................................................(Norm) ISO/IEC 9075-3 Informationstechnik; SQL; SQL-Anbindung über Funktionsaufrufe Dez. 1995 /ISO/IEC 9075-4/ .............................................................................................................(Norm) ISO/IEC 9075-4 Informationstechnik; SQL; Beständige Speichermodule Dez. 1996 /ISO/IEC 9945/ ................................................................................................................(Norm) ISO/IEC 9945 Informationstechnik; Betriebssystemschnittstelle für die Austauschbarkeit von Systemen (POSIX) /ISO/IEC 9945-1/ .............................................................................................................(Norm) ISO/IEC 9945-1 Schnittstelle zwischen System und Anwendungsprogramm (API) (Sprache C) Juli 1996

Page 128: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A10

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/ISO/IEC 9945-1/ .............................................................................................................(Norm) ISO/IEC 9945-1 DAM 4 Änderung 4: Protokollunabhängige Schnittstelle (PII) Okt. 1997 /ISO/IEC 9945-2/ .............................................................................................................(Norm) ISO/IEC 9945-2 Befehlssprache und Dienstprogramme Dez. 1993 /ISO/IEC 9945-2/ .............................................................................................................(Norm) ISO/IEC 9945-2 DAM 1 Änderung 1: Erweiterungen für die Portabilität von Anwendungsprogrammen März 1996 /ISO/IEC TR 14252/.........................................................................................................(Norm) ISO/IEC TR 14252 Informationstechnik; Leitfaden zur offenen Systemumgebung von POSIX Dez. 1996 /Ja89/.......................................................................................................................... (Realzeit) JACOBSON, ERIK Einführung in die Prozeßdatenverarbeitung Carl-Hanser Verlag; München, Wien; 1989; ISBN 3-446-15531-7 /Ji95/ ................................................................................................................................. (DBS) JILG, GÜNTHER; BROCKHAUS, DIRK Rangordnung - Modellierung komplexer Datenstrukturen mit relationalen Datenbanken in: iX 9/95 /Jo98/.............................................................................................................(Programmierung) JOHNSON, MICHAEL K. Linux Kernel Hackers´ Guide V0.7 1992, 1993, 1998 http://sunsite.unc.edu/LDP/ /Kä90/ ............................................................................................................................... (DBS) KÄHLER, WOLF-MICHAEL SQL-Bearbeitung relationaler Datenbanken Vieweg-Verlag; 1990; ISBN 3-528-04786-0

Page 129: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A11

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Ki95/ ................................................................................................................................ (DBS) KIM, YOUNG-KUK; LEHR, MATTHEW R.; GEORGE, DAVID W.; SON, SANG H. A Database Server for Distributed Real-Time Systems: Issues and Experiences u.a. in: Proceedings of the 2nd Workshop on Parallel and Distributed Real-Time Systems 1995 /Ki94/ .............................................................................................................(Programmierung) KIRCH, OLAF The Linux Network Administrators Guide V1.0 1992-1996 http://sunsite.unc.edu/LDP/ /Ko01/ ............................................................................................................................... (DBS) KORTH, HENRY F; SILBERSCHATZ, ABRAHAM Database System Concepts; 4th edition McGraw-Hill International Editions; 2001; ISBN 0-07-228363-7 /Kr89/ .............................................................................................................(Programmierung) KRISHNAMURTHY, E.V. Parallel processing: principles and practice Addison-Wesley Publishing Company; 1989; ISBN 0-201-17532 /Kr93/ ................................................................................................................................ (DBS) KRÜGER, HANS-JOACHIM; SIEBERICHS, DAGMAR ACCESS sofort einsetzen Sybex; 1993; ISBN 3-8155-1508-4 /Ku92/ ............................................................................................................................... (DBS) KUDLICH, HERMANN Verteilte Datenbanken, Systemkonzepte und Produkte Siemens Nixdorf Informationssysteme AG; 1992; ISBN 3-8009-1589-8 /LaSch94/ ............................................................................................(Programmierung)(DBS) LANGENDÖRFER, HORST; SCHNOR, BETTINA Verteilte Systeme Carl-Hanser Verlag; Müchen, Wien; 1994; ISBN 3-446-17468-0 /Lau99/........................................................................................................................ (Realzeit) LAUBER R.; GÖHNER P. Prozessautomatisierung Springer-Verlag, Berlin, Heidelberg, New York; 3. Auflage 1999; ISBN 3-540-65318-8

Page 130: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A12

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Lau95/.............................................................................................................................. (DBS) LAUSEN, G. Datenbanksysteme in Büro, Technik und Wissenschaft GI-Fachtagung Dresden, 22. - 24. März 1995 Springer-Verlag; 1995; ISBN 3-540-59095-1 /La94/.............................................................................................................(Programmierung) LAWRENZ, WOLFHARD CAN - Controller Area Network - Grundlagen und Praxis Hüthig Buch Verlag Heidelberg; 1994; ISBN 3-7785-2263-7 /Le95/................................................................................................................................ (DBS) LEHR, METTHEW R.; KIM, YOUNG-KUK, SON, SANG H. Managing Contention and Timing Constraints in a Real-Time Database System 16th IEEE Real-Time Systems Symposium (RTSS '95), 5. - 7. Dezember 1995, Pisa, ITALY http://www.computer.org/proceedings/rtss/7337/7337toc.htm /LiJ/ ................................................................................................................(Programmierung) LINUX JOURNAL - THE PREMIER MAGAZINE OF THE LINUX COMMUNITY Jahrgänge 1996, 2002 PO Box 55549 Seattle, WA 98155-0549 http://www.linuxjournal.com/ /LiM/...............................................................................................................(Programmierung) LINUX MAGAZIN Jahrgänge 1996, 2002 Linux New Media AG, Stefan-George-Ring 24, 81929 München http://www.linux-magazin.de/ /Li90/................................................................................................................................. (DBS) LIPPOLD, JOACHIM Skripten zu Datenbanken FH Mittweida, 1990 /Ma92/............................................................................................................................... (DBS) MARTIN, JAMES Einführung in die Datenbanktechnik Carl-Hanser Verlag; München, Wien; 1992; ISBN 3-446-12929-4 /Ma92/............................................................................................................(Programmierung) MASON, LEVIN; BROWN Lex & Yacc, 2nd Edition O`Reilly, Nutshell; 1992; ISBN 1-56592-000-7

Page 131: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A13

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Me92/............................................................................................................................... (DBS) MEIER, ANDREAS Relationale Datenbanken Eine Einführung in die Praxis Springer-Verlag; Berlin Heidelberg; 1992; ISBN 3-540-54814-9 /Mi95/................................................................................................................................ (DBS) MISGELD, WOLFGANG SQL - Einstieg und Anwendung 2. überarbeitete und aktualisierte Auflage Carl-Hanser Verlag; München Wien; 1995; ISBN 3-446-18260-8 /Mü92/............................................................................................................................... (DBS) MÜHLHAUSER, M.; SCHILL, A. Software Engineering für verteilte Anwendungen Springer Verlag; Berlin, Heidelberg; 1992; ISBN 3-540-55412-2 /Neu96/ ............................................................................................................................. (DBS) NEUMANN, KARL Datenbanktechnik für Anwender Carl-Hanser Verlag; München Wien; 1996; ISBN 3-446-18401-5 /ÖzVa91/........................................................................................................................... (DBS) ÖZSU, M. TAMER; VALDURIEZ, PATRICK Principles of Distributed Database Systems Prentice Hall; Englewood Cliffs, New Jersey; 1991; ISBN 0-13-691643-0 /PaVa91/........................................................................................................................... (DBS) PAPAZOGLOU, MIKE; VALDER, WILHELM Entwurf relationaler Datenbanken in C Carl-Hanser Verlag; Prentice Hall; 1991; ISBN 3-446-16191-0 /PHI96/...........................................................................................................(Programmierung) PHILLIPS SEMICONDUCTORS DATA SHEET, P8xC592 8-bit microcontroller with on-chip CAN 27. Juni 1996 http://www-us.semiconductors.phillips.com/ /Pi97/ .......................................................................................................................... (Realzeit) PISARZ, JÜRGEN Port Automation GmbH Scripten zu Realtime mit TCP/IP

Page 132: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A14

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Pro/ .................................................................................................................................. (DBS) PROGRESS SOFTWARE CORPORATION Handbücher zum DBS Version 6 Progress Software Corporation, 14 Oak Park, Bedford, MA 01730, USA; 1995 /ReLe94/ ..................................................................................................................... (Realzeit) REMBOLD, ULRICH; LEVI, PAUL Realzeitsysteme zur Prozeßautomatisierung Carl-Hanser Verlag; München, Wien; 1994; ISBN 3-446-15713-1 /RFC 793/ ........................................................................................................................(Norm) Requests for Comments 793 http://www.cis.ohio-state.edu/cs/Services/rfc/index.html /Rö96/ ............................................................................................................................... (DBS) RÖSSEL, MIKE Abfrageoptimierung in Datenbanken Skripten zur Vorlesung Fabrikautomatisierung/Fabrikinformationssysteme an der TU BAF, IfAT; 1996 /RöGei96/ ......................................................................................................(Programmierung) RÖSSEL, MIKE; GEILER, IMMO Methoden der Programmierung Skripten zur Vorlesung Fabrikautomatisierung/Fabrikinformationssysteme an der TU BAF, IfAT, 1996 /Rus97/ ..........................................................................................................(Programmierung) RUSLING, DAVID A. The LinuX Kernel Draft; Version 0.1-13(19); 1996-1997 http://www.sunsite.unc.edu/LDP/ /Sa94/ ............................................................................................................................... (DBS) SAUER, HERMANN Relationale Datenbanken, Theorie und Praxis inclusive SQL-2 Addison-Wesley Publishing Company; 3. Auflage 1994; ISBN 3-89319-821-0 /Schwi92/ .......................................................................................................................... (DBS) SCHWINN, HANS Relationale Datenbanksysteme Hanser-Studienbücher der Informatik; 1992; ISBN 3-446-15782-4

Page 133: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A15

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Se91/ ............................................................................................................(Programmierung) SELTZER, MARGO; OZAN, YIGIT A New Hashing Package for UNIX USENIX - the Winter USENIX Conference, January 1991 - Dallas, TX http://citeseer.nj.nec.com/seltzer91new.html /SeOl92/.........................................................................................................(Programmierung) SELTZER, MARGO; OLSON, MICHAEL LIBTP: Portable, Modular transactions for UNIX University of California, Berkeley, 1992 http://s2k-ftp.cs.berkeley.edu:8000/postgres/papers/ERL-M92-02.pdf /Se94/ ............................................................................................................(Programmierung) SENGUPTA, SAUMYENDRA; KOROBKIN, KARL PHILLIP C++ - Objekt-Oriented data Structures Springer Verlag; 1994; ISBN 0-387-94194-0 (New York), ISBN 3-540-94194-0 (Berlin) /Se92/ ............................................................................................................(Programmierung) SEDGEWICK, ROBERT Algorithmen (in C(++)) Addison-Wesley Publishing Company; 1992; ISBN 3-89319-462-2 /Sh96/ ............................................................................................................................... (DBS) SHIBY, THOMAS; SESHADRI, S.; HARISTA, JAYNAT R. Integrating Standard Transactions in Real-Time Database Systems CSE, Indian Institute of Technology, Bombay 400 076, INDIA SERC, Indian Institute of Scince, Bangalore 560 012, INDIA; 1996 /Si91/ ................................................................................................................................ (DBS) SILBERSCHATZ, ABRAHAM; KORTH, HENRY F. Database System Concepts, Second Edition McGrawn-Hill, Inc (Computer Science Series); 1991; ISBN 0-07-100804-7 /So93/ ............................................................................................................................... (DBS) SON, SANG H.; GEORGE, DAVID W.; KIM, YOUNG-KUK Developing a Database System for Time-Critical Applications IEEE International Conference on Database and Expert Systems Applications (DEXA'93), Prag, September 1993, Lecture Notes in Computer Science #720, Seiten 313-324. /So94/ ............................................................................................................................... (DBS) SON, SANG H.; KIM, YOUNG-KUK; BECKINGER, ROBERT C. MRDB: A Multi-User Real-Time Database Testbed 27st Hawaii International Conference on System Sciences, Maui, Hawai, Januar 1994, Seiten 543-552.

Page 134: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A16

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/St92/ .............................................................................................................(Programmierung) STEVENS, W. RICHARD Programmierung von UNIX-Netzen Grundlagen, Programmierung, Anwendung Carl-Hanser Verlag und Prentice-Hall International; 1992; ISBN 3-446-16318-2 /Sto75/ .............................................................................................................................. (DBS) STONEBRAKER, M.R. Implementation of integrity constraints and views by query modification ACM SIGMOD Conference; San Jose, California; 1975; S. 65-78 /St93/ ................................................................................................................................ (DBS) STÜRMER, GÜNTHER Oracle7, Die verteilte semantische Datenbank dbms publishing; 1993; ISBN 3-930124-00-9 /Ta94/ ............................................................................................................(Programmierung) TANNENBAUM, ANDREW S. Moderne Betriebssysteme Carl-Hanser Verlag; Prentice Hall Int.; ISBN 3-446-17472-9 /Th94/ ......................................................................................................................... (Realzeit) THIES, KLAUS-DIETER Multitasking Carl-Hanser Verlag; München, Wien; 1994; ISBN 3-446-17506-7 /Stau96/ ...................................................................................................................... (Realzeit) STAUB, MATTHIAS Untersuchungen zum Echtzeitverhalten von Feldbussystemen mit Zugriffsverfahren CSMA/CA unter besonderer Berücksichtigung des CAN-Protokolls Dissertation; TU Chemnitz-Zwickau; 1996 /Si98/ .......................................................................................................................... (Realzeit) SIERING, TILL CHRISTIAN Einführung in die Echtzeiterweiterung RT-Linux http://sokrates.ipk.fhg.de/Archiv/rtlinux /OMG92.11.1/ ...................................................................................................................(DBS) THE OBJECT MANAGEMENT GROUP Object Management Architecture Guide Richard Mark Soley, Ph. D. (ed.) OMG TC Document 92.11.1 John Wiley & Sons, Inc.; Revision 2.0, Second Edition, 1.9.1992; ISBN 0-471-58563-7

Page 135: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A17

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/OMG94.1.1/ ..................................................................................................................... (DBS) THE OBJECT MANAGEMENT GROUP Common Object Services Specification, Volume 1 Jon Siegel, Ph. D. (ed.) OMG Document Number 94.1.1 John Wiley & Sons, Inc.; , Revision 1.0, First Edition, 1.3.1994; ISBN 0-471-07684-8 /Ull88/ ............................................................................................................................... (DBS) ULLMANN, J.D. Principles of Database and Knowledge-base Systems Computer Science Press; 1988; ISBN 0-7167-8158-1 /Un95/ ............................................................................................................................... (DBS) UNLAND, RAINER Objektorientierte Datenbanken - Konzepte und Modelle Internat. Thomson Publ. (Thomson´s Aktuelle Tutorien 4); 1995; ISBN 3-929821-82-6 /Ut97/ ................................................................................................................................ (DBS) DIPL. ING. M. UTESCH Ein Beitrag zur Anfrageoptimierung in Datenbanken mit Genetischen Algorithmen Dissertation, TU BAF, IfAT /Ve98/ ............................................................................................................(Programmierung) VEPSTAS, LINAS Software-RAID mini-HOWTO v0.39, 4 January 1998 http://linas.org/linux/Software-RAID /Vo95/ ............................................................................................................................... (DBS) VOSSEN, GOTTFRIED Datenbanktheorie International Thomson Publishing GmbH; 1995; ISBN 3-8266-0126-2 /Vo87/ ............................................................................................................................... (DBS) VOSSEN, GOTTFRIED Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme Addison-Wesley Publishing Company; Bonn; 1987/1991; ISBN 3-925118-64-0

Page 136: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A18

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Wa97/ ........................................................................................................................ (Realzeit) WAGNER, TOM; TOWSLEY, DON Getting Started With POSIX Threads Department of Computer Science, University of Massachusetts at Amherst http://centaurus.cs.umass.edu/~wagner /WaMe91/ ................................................................................................................... (Realzeit) WARD, PAUL T.; MELLOR STEPHEN J. Strukturierte Systemanalyse von Echtzeit-Systemen Carl-Hanser Verlag; Prentice-Hall; 1991; ISBN 3-446-16198-8 /Weg93/ .........................................................................................................(Programmierung) WEGENER, INGO Theoretische Informatik - Eine algorithmenorientierte Einführung B.G. Teubner Stuttgart; 1993; ISBN 3-519-02123-4 /We95/ ...........................................................................................................(Programmierung) WERNER, DIETER Taschenbuch der Informatik Fachbuchverlag Leipzig; 2. Auflage 1995; ISBN 3-343-00892-3 /We92/ ...........................................................................................................(Programmierung) WERNER, DIETER Theorie der Betriebssysteme Carl-Hanser Verlag; 1992; ISBN 3-446-16547-9 /We96/ .............................................................................................................................. (DBS) WERUM BAPAS-DB Das Echtzeit-Datenbanksystem - Leistungsbeschreibung; V3.2 1996 http://www.werum.de /We93/ ...........................................................................................................(Programmierung) WETTSTEIN, HORST Systemarchitektur Carl-Hanser Verlag; 1993; ISBN 3-446-17517-2 /We80/ ...........................................................................................................(Programmierung) WETTSTEIN, HORST Systemprogrammierung Carl-Hanser Verlag; München, Wien; 2. Auflage 1980; ISBN 3-446-13217-1

Page 137: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Literaturverzeichnis Seite A19

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/Wi91/ ............................................................................................................................... (DBS) WILKE, HANS D. ORACLE Datenbankmanagement professional, Design, Realisierung und Optimierung Addison-Wesley Publishing Company; 1991; 2. Überarb. Auflage, ISBN 3-89319-352-1 /Wo98/ .............................................................................................................................. (DBS) WONDERWARE CORPORATION Prospekte und Datenblätter Factory Suite http://www.wonderware.com /Xa97-1/ ...................................................................................................................... (Realzeit) XAVIER, LEROY Linuxthreads-FAQ http://pauillac.inria.fr/~xleroy /Xa97/ ......................................................................................................................... (Realzeit) XAVIER, LEROY Linuxthreads-README http://pauillac.inria.fr/~xleroy /YoBa96/..................................................................................................................... (Realzeit) YODAIKEN, VICTOR; BARABANOV, MICHAEL Real-Time Linux March 3, 1996 http://liz.nmt.edu/~rtlinux /Yo97/ ......................................................................................................................... (Realzeit) YODAIKEN, VICTOR RT-Linux Whitepaper 6. Oktober 1997 http://liz.nmt.edu/~rtlinux /YoBa97/..................................................................................................................... (Realzeit) YODAIKEN, VICTOR; BARABANOV, MICHAEL A Real-Time Linux http://liz.nmt.edu/~rtlinux /ZöAl95/ ...................................................................................................................... (Realzeit) ZÖBEL, DIETER; ALBRECHT, WOLFGANG Echtzeitsysteme, Grundlagen und Techniken International Thomson Publishing; 1995; ISBN 3-8266-0150-5

Page 138: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A20

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

VIII Quellenauszug66

DATENTYP.H67 /*************************************************************************** datentyp.h - description ***************************************************************************/ /*************************************************************************** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * ***************************************************************************/ // Definition der Datentypen fuer die Datenbank #ifndef __datentyp_h #define __datentyp_h #include <time.h> #include <engine/engine.h> //#include <engine/eparser.h> #include <engine/db_objek.h> //-- Deklaration externer Klassen ------------------------------------------- class KDatensatz; class KTabelle; //--------------------------------------------------------------------------- #define __C_BASIS const char* //--------------------------------------------------------------------------- /// abstrakte Basisklasse aller Datentypen class K0_DATENTYP : public K0_DB_Objekt { /// Das FeldTabellenObjekt static KTabelle* eigene_Tabelle; protected: /// Offset des Feldes zur Basisadresse des Datensatzes long Offset; static char TextPuffer[]; public: _INTEGER_ Parameter; public:

66 Die eingebundenen Quellen sind nicht vollständig und nur beispielhaft zu verstehen. Da sie teilweise

entwicklungsbedingt durch dritte Personen überarbeitet und weiterentwickelt wurden, ist eine Genehmi-gung zum Abdruck eingeholt worden. Siehe auch Bemerkungen Seite 1.

67 Datentypen als Beispiel für die Flexibilität des DBS bei Verwendung objektorientierter Programmiermetho-den.

Page 139: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A21

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/// K0_DATENTYP(long); /// virtual ~K0_DATENTYP(); /// virtual void* copy(long) = 0; /// virtual void init(__C_BASIS) = 0; /// fuer CHAR und VARCHAR virtual KDatensatz* anlegen(__C_TNR, st_Feld*); /// virtual void oeffnen(__C_TNR, __C_ADRESSE Adr); /// bool update_from_DB(__C_TNR); protected: /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN) = 0; /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN) = 0; public: /// Groesze des Datentyps im RAM und auf der HD virtual long get_m_size() = 0; /// __OPERAT compare(__C_BASIS, __C_DATEN, bool=true); /// virtual __C_DATEN get_bin(__C_BASIS B) { return B+Offset; } /// Kopfzeile void get_text(__C_TNR, NCore::KString&, int); /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long) = 0; /// virtual fuer VARCHAR virtual void set_bin(__C_BASIS, __C_DATEN, __C_TNR = 0); /// virtual void set_text(__C_TNR, __C_BASIS, __DATEN&); /// virtual __DATENTYP get_Typ() = 0; protected: /// void print(__C_TNR, NCore::KString&, int, unsigned long); friend class KTabelle; friend class KFeldTabelle; friend class KDatensatzbeschreibung; friend class KTabellenTabelle; }; inline K0_DATENTYP::~K0_DATENTYP() { } //--------------------------------------------------------------------------- /// Datentyp INTEGER class K_DT_INTEGER : public K0_DATENTYP { protected:

Page 140: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A22

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); public: /// K_DT_INTEGER(long o) : K0_DATENTYP(o) {;} /// virtual void* copy(long); /// virtual void init(__C_BASIS B) { *(_INTEGER_*)(B + Offset) = 0; } /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN); /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN); /// virtual long get_m_size() { return sizeof(_INTEGER_); }; /// virtual __DATENTYP get_Typ() { return _INTEGER; } /// }; //--------------------------------------------------------------------------- /// Datentyp FLOAT class K_DT_FLOAT : public K0_DATENTYP { protected: /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); public: /// K_DT_FLOAT(long o) : K0_DATENTYP(o) {;} /// virtual void* copy(long); /// virtual void init(__C_BASIS B) { *(_FLOAT_*)(B+Offset) = 0; } /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN); /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN); /// virtual long get_m_size() { return sizeof(_FLOAT_); }; /// virtual __DATENTYP get_Typ() { return _FLOAT; } }; //--------------------------------------------------------------------------- // Parameter 1: #define _char_crypt 1 #define _char_size 2 /// Datentyp CHAR class K_DT_CHAR : public K0_DATENTYP { protected: /// int m_size; /// int P1;

Page 141: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A23

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

protected: /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); /// virtual KDatensatz* anlegen(__C_TNR, st_Feld*); /// bool update_from_DB(__C_TNR); public: /// K_DT_CHAR(long o) : K0_DATENTYP(o) { m_size = 0; } /// virtual void* copy(long); /// virtual void init(__C_BASIS B) { *(int*)(B+Offset) = 0; } /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN); /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN); /// virtual long get_m_size() { return m_size; } /// virtual void set_bin(__C_BASIS, __C_DATEN, __C_TNR = 0); /// virtual void set_text(__C_TNR, __C_BASIS, __DATEN&); /// virtual __DATENTYP get_Typ() { return _CHAR; } }; //--------------------------------------------------------------------------- /// Datentyp bool class K_DT_BOOL : public K0_DATENTYP { /// char* Wert_true; /// char* Wert_false; protected: /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); public: /// K_DT_BOOL(long o); /// ~K_DT_BOOL(); /// virtual void* copy(long); /// virtual void init(__C_BASIS B) { (*(_BOOL_*)(B+Offset)) = 0; } /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN); /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN); /// virtual long get_m_size() { return 1; } /// virtual __DATENTYP get_Typ() { return _BOOL; } }; //---------------------------------------------------------------------------

Page 142: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A24

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

// KEYs koennen nicht vom Nutzer beinfluszt werden, das System verwaltet // sie automatisch /// Datentyp KEY class K_DT_KEY : public K_DT_INTEGER { public: /// K_DT_KEY(long o) : K_DT_INTEGER(o) {;} /// virtual __DATENTYP get_Typ() { return _KEY; } }; //--------------------------------------------------------------------------- // Klasse fuer die Behandlung von foreign-Keys // Es ist zu beachten, dasz Ringe zu Endlosschleifen im Programm werden /** Datentyp FOREIGNKEY */ class K_DT_FOREIGNKEY : public K_DT_INTEGER { public: /** Konstruktor */ K_DT_FOREIGNKEY(long o) : K_DT_INTEGER(o) {;} /** Typ identifizieren */ virtual __DATENTYP get_Typ() { return _FOREIGNKEY; } }; //--------------------------------------------------------------------------- /** Datentyp ADDRESS*/ class K_DT_ADDRESS : public K_DT_INTEGER { public: /** Konstruktor */ K_DT_ADDRESS(long o) : K_DT_INTEGER(o) {;} /** Typ identifizieren */ virtual __DATENTYP get_Typ() { return _ADDRESS; } }; //--------------------------------------------------------------------------- // Klasse fuer die Behandlung von Zeichenketten mit variabler Laenge // ACHTUNG!!! Wert musz unbedingt initialisiert werden /// Datentyp VARCHAR class K_DT_VARCHAR : public K0_DATENTYP { /// static KDatensatzbeschreibung VARCHAR_Beschreibung; protected: /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); /// void set_bin_raw(__C_TNR, __C_BASIS, __C_DATEN, long); public: /// K_DT_VARCHAR(long o) : K0_DATENTYP(o) {;}

Page 143: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A25

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

/// virtual void* copy(long); /// virtual void init(__C_BASIS B) { *(_INTEGER_*)(B+Offset) = 0; } /// virtual void set_text(__C_TNR, __C_BASIS, __DATEN&); /// virtual void set_bin(__C_BASIS b, __C_DATEN d, __C_TNR t); /// virtual const __DATEN get_bin(__C_BASIS); /// virtual long get_m_size() { return 2 * sizeof(_VARCHAR); } /// virtual bool ist_Gleich(__C_BASIS, __C_DATEN) { return false; } /// virtual bool ist_Groesser(__C_BASIS, __C_DATEN) { return false; } /// virtual __DATENTYP get_Typ() { return _VARCHAR; } friend class KDBEngine; }; //--------------------------------------------------------------------------- /// Datentyp TIMESTAMP class K_DT_TIMESTAMP : public K_DT_INTEGER { /// int Variante; protected: /// virtual void get_text(__C_TNR, NCore::KString&, __C_BASIS, unsigned long); public: /// K_DT_TIMESTAMP(long o) : K_DT_INTEGER(o) {;} /// virtual void* copy(long); /// virtual __DATENTYP get_Typ() { return _TIMESTAMP; } friend class KDBEngine; }; #endif

Page 144: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A26

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

4GL.Y68 //============================================================================ // Extension for 4th Generation Language (4GL) // // Grammatik der 4GL in MRDB //============================================================================ _4GL_Anweisung: ScriptAnweisung | ExecAnweisung | KillAnweisung | ProzedurAnweisung | DropProzedurAnweisung | ShowAnweisung | LoginAnweisung | AliveMeldung | InstallTrigger | DropTrigger | StopAnweisung ; %int VarType Variable %type "KTerm*" _Konstante; //---------------------------------------------------------------------------- // SCRIPT //---------------------------------------------------------------------------- <r>script SCRIPT ScriptAnweisung: SCRIPT STRING { script($2, 0, yyAddress); }; //---------------------------------------------------------------------------- // eine Variable //---------------------------------------------------------------------------- Variable: NAME { $$ = get_Var($1); if($$ < 0) throw eParseError(eERROR, this, i18n("No var %s found"), $1); }; //---------------------------------------------------------------------------- // Variablen, (deklarieren und ggf. definieren) //---------------------------------------------------------------------------- VarAnweisung: VarType NAME _Konstante { if($1 == T_CHAR) { if($3) add_Var($2, new KT_StringVar(*$3, this)); else add_Var($2, new KT_StringVar()); } else

68 4GL-Grammatik als Basis für einen Sprachübersetzer mit erweiterten Realzeitfähigkeiten.

Page 145: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A27

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

{ if($3) add_Var($2, new KT_Var($1, *$3, this)); else add_Var($2, new KT_Var($1)); } } ; VarType: T_INTEGER { $$ = T_INTEGER; } | T_FLOAT { $$ = T_FLOAT; } | T_BOOL { $$ = T_BOOL; } | T_CHAR { $$ = T_CHAR; } ; _Konstante: /* nichts */ | '=' Term { $$ = $2; } ; //---------------------------------------------------------------------------- // PROC, REAL TIME PROC, TRIGGER //---------------------------------------------------------------------------- <r>real REAL <r>time TIME <r>proc PROC <r>trigger TRIGGER <r>begin BEGIN <r>end END ProzedurAnweisung: ProzedurKopf _ProzedurParameter ProzedurRumpf | TriggerKopf DML_Block { end_table(); end_proc(); } ; ProzedurKopf: PROC NAME { begin_proc($2, false); } | REAL TIME PROC NAME { begin_proc($4, true); } ; TriggerKopf: TRIGGER NAME ON NAME { begin_proc($2, false); yyProzedur->trigger_tab = Tabellen[begin_table($4)]->ID; } ; _ProzedurParameter: /* keine Parameter */ | '(' ProzedurParameterListe ')' { yyProzedur->end_of_parameters(); } ; ProzedurParameterListe: ProzedurParameter | ProzedurParameterListe ',' ProzedurParameter;

Page 146: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A28

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

ProzedurParameter: VarAnweisung | VarType '&' NAME { add_Var($3, new KT_IndirectVar($1)); } ; ProzedurRumpf: DML_Block { end_proc(); }; //---------------------------------------------------------------------------- // DROP PROC //---------------------------------------------------------------------------- <r>drop DROP DropProzedurAnweisung: DROP PROC NAME { delProzedur($3); } ; //---------------------------------------------------------------------------- // EXEC //---------------------------------------------------------------------------- <r>exec EXEC ExecAnweisung: ExecKopf '(' ExecParameterListe ')' { yyProzess = 0; } | ExecKopf { yyProzess = 0; } ; ExecKopf: EXEC NAME { if(runlevel != RL_MASTER_UP) break; yyProzess = new KProzess(this, *(findProzedur($2)), yyAddress); } ; // Parameterliste an stored procedure übergeben // setz voraus, dass yyProzess auf aktuellem Prozess steht! ExecParameterListe: ExecParameter | ExecParameterListe ',' ExecParameter; ExecParameter: Term { if(runlevel != RL_MASTER_UP) break; if(!$1->konstant) throw eParseError(eERROR, this, i18n("Parameter must be constant")); yyProzess->init_Var($1); } ; //---------------------------------------------------------------------------- // KILL //---------------------------------------------------------------------------- <r>kill KILL KillAnweisung: KILL ZAHL { kill($2); }

Page 147: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A29

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

; //---------------------------------------------------------------------------- // LOGIN //---------------------------------------------------------------------------- <r>login LOGIN LoginAnweisung: LOGIN NAME '@' NAME { login($2, $4, yyAddress); } ; //---------------------------------------------------------------------------- // STILL ALIVE //---------------------------------------------------------------------------- <r>still STILL <r>alive ALIVE AliveMeldung: STILL ALIVE { findClient(yyAddress)->alive(this, yyAddress); }; //---------------------------------------------------------------------------- // INSTALL, DROP TRIGGERS //---------------------------------------------------------------------------- <r>install INSTALL <r>update UPDATE InstallTrigger: INSTALL Triggerart TRIGGER NAME ON NAME { KTabelle* t = Tabellen[get_Tabelle($6, true)]; IProzedur p = findProzedur($4); if(t->ID != (*p)->trigger_tab) throw eParseError(eERROR, this, i18n("Trigger %s was not defined for table %s"), $4, $6); t->install_Trigger((__TRIGGER_FUNC)$2, p); }; DropTrigger: DROP Triggerart TRIGGER ON NAME { Tabellen[get_Tabelle($5, true)]->deinstall_Trigger((__TRIGGER_FUNC)$2); } ; %int Triggerart; Triggerart: CREATE { $$ = _T_CREATE; } | UPDATE { $$ = _T_UPDATE; } | DELETE { $$ = _T_DELETE; }; //---------------------------------------------------------------------------- // SHOW //---------------------------------------------------------------------------- <r>show SHOW <r>in IN <r>jobs JOBS <r>clients CLIENTS

Page 148: Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Quellenauszug Seite A30

Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel

<r>procedures PROCEDURES <r>slaves SLAVES <r>statistics STATISTICS ShowAnweisung: SHOW NAME IN NAME { show($2, $4, yyAddress); } | SHOW NAME IN NAME AND EXEC STRING { show($2, $4, yyAddress, $7); } | SHOW JOBS IN NAME { show_list($4, yyAddress, 0); } | SHOW CLIENTS IN NAME { show_list($4, yyAddress, 1); } | SHOW PROCEDURES IN NAME { show_list($4, yyAddress, 2); } | SHOW SLAVES IN NAME { show_list($4, yyAddress, 3); } | SHOW STATISTICS IN NAME { show_list($4, yyAddress, 4); } ; <r>stop STOP StopAnweisung: STOP { Owner->terminate(); };