Ein Beitrag zum Entwurf industrieller Datenbanksysteme

Microsoft Word - pflichtexemplar.docVon der Fakultät für Maschinenbau, Verfahrens- und Energietechnik
der Technischen Universität Bergakademie Freiberg
genehmigte
DISSERTATION
Doktor der Ingenieurwissenschaften
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
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
Inhaltsverzeichnis Seite I
I Inhaltsverzeichnis
IV Verzeichnis der Abbildungen............................................................................. X
V Verzeichnis der Tabellen................................................................................... XI
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.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
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
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
AT Automatisierungstechnik
ATS Automatisierungssystem
Baudrate Bezeichnung für die Geschwindigkeit, mit der serielle Daten übertragen werden
BDE Betriebsdatenerfassung
CAN Bussystem (controller area network)
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CSMA/CA CSMA / Collision Avoidance
CSMA/CD CSMA / Collision Detection
DB Datenbank (database)
DBS Datenbanksystem (database system)
DCL Data Control Language
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.
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
FAQ Frequently Asked Questions
FIPS PUBS Federal Information Processing Standards Publications
FM File-Manager
FSF Free Software Foundation
GMT Greenwich Meridian Time
ID Identifikator
IEEE The Institute of Electrical and Electronics Engineers, Inc.
IfAT Institut für Automatisierungstechnik, TU BAF
IP Internet Protokoll
IPC Interprocess Communication
ISO International Standards Organisation
LDP Linux Documentation Project
LFU least frequently used
MDE Maschinendatenerfassung
Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel
PCI Personal Computer Interface
PFN Page Frame Number
RAM Random Acess Memory
SDRAM synchrones DRAM
SMP Symmetrisches Multiprozessor-System
SPX Kommunikationsprotokoll
UDP User Datagram Protokoll
UTC Coordinated Universal Time (Internationaler Zeitstandard) entspricht GMT (0 Uhr entspricht Mitternacht in Greenwich, England). UTC basiert auf einer 24-Stunden-Uhr
VDL Viewdefinitionssprache
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
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
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
Verzeichnis der Abbildungen Seite X
Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel
IV Verzeichnis der Abbildungen
Ein Beitrag zum Entwurf industrieller Datenbanksysteme - Dissertation M. Rössel
V Verzeichnis der Tabellen
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 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.
Einleitung Seite 1
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.
Einleitung Seite 2
• 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.
Einleitung Seite 3
• 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.
Einleitung Seite 4
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.
Wissensstand Seite 5
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
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.
Wissensstand Seite 6
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).
Wissensstand Seite 7
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
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/.
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…