Historische Entwicklung von Datenbanken
Werbung
FACHHOCHSCHULE HEILBRONN Hochschule für Technik und Wirtschaft Studiengang Electronic Business (EB) Handout Historische Entwicklung von Datenbanken von Jochen Löhl Mario Lörcher Ingo Sahm im SOMMERSEMESTER 2005 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken Inhaltsverzeichnis 1. Einführung............................................................................................................... 1 1.1 Historische Entwicklung..................................................................................... 1 1.2 Motivation für Datenbanken............................................................................... 1 1.2.1 Historisches................................................................................................. 1 1.2.2 Erreichte Ziele ............................................................................................. 2 2. Datenmodelle .......................................................................................................... 3 2.1 Allgemein........................................................................................................... 3 2.1.1 Definition ..................................................................................................... 3 2.1.2 Datenmodelle – Ein Überblick..................................................................... 3 2.2 Hierarchisches Datenmodell.............................................................................. 4 2.2.1 Entwicklung und Struktur ............................................................................ 4 2.2.2 Der Wurzelbaum ......................................................................................... 5 2.2.3 Die hierarchische Ordnung ......................................................................... 5 2.2.4 Die Beziehungen......................................................................................... 6 2.2.5 Redundanz.................................................................................................. 6 2.3 Netzwerk-Datenmodell ...................................................................................... 7 2.3.1 Entwicklung................................................................................................. 7 2.3.2 Strukturelemente des Netzwerk-Datenmodells ........................................... 8 2.3.3 Darstellung von Strukturen im NDM............................................................ 8 2.3.4 Bewertung des Netzwerkdatenmodells ....................................................... 9 2.4 Das CODASYL/DBTG-Konzept....................................................................... 10 2.4.1 CODASYL ................................................................................................. 10 2.4.2 Entwicklung des CODASYL/DBTG-Konzepts ........................................... 10 2.4.3 Aufbau eines DBS nach dem CODASYL/DBTG-Konzept......................... 12 2.5 Das ANSI/X3/SPARC-Konzept ........................................................................ 13 II Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 1. Einführung 1.1 Historische Entwicklung Kleiner Zeitlicher Überblick über die historische Entwicklung: • Ab 18. Jhd.: Lochkarten • 1956: Erfindung der Festplatte • 1968 – 1975: Hierarchisches Datenmodell • 1975 – 1980: Netzwerkdatenmodell • Ab 1980: Relationales Datenmodell 1.2 Motivation für Datenbanken 1.2.1 Historisches Klassische Programmiersprachen wie FORTRAN, ALGOL, Pascal, etc. hatten lediglich primitive Dateimanipulations-Anweisungen. Diese waren mehr auf Verarbeitung als auf Strukturierung des Datenbestandes ausgerichtet. Es existierte keine Beschreibung der Beziehungen der Daten untereinander. Somit war es nur mit großem Aufwand möglich die Daten zu pflegen. Zwischen Dateien und Programmen bestand eine starre Kopplung. Erschwerend kam hinzu, dass Änderungen in der Datenstruktur auch Änderungen in Programmen und umgekehrt (keine Datenunabhängigkeit) bedingten. Ein koordinierter Zugriff durch mehrere Programme war nicht möglich und jedes Programm war zuständig für Datenschutz und –sicherheit der Daten. Daraus ergaben sich folgende Prinzipien: 1. Organisatorisch zentrale Betreuung von Daten 2. Trennung von Daten und Programmen Abbildung 1 verdeutlicht die Trennung von Daten und Programmen und stellt auch das Datenbanksystem (DBS) sowie die Kommunikation zwischen dem Datenbankmanagementsystem (DBMS) und der Datenbank (DB) dar. 1 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken Abbildung 1: Trennung von Programmen und Daten 1.2.2 Erreichte Ziele Folgende Ziele konnten durch den Einsatz von Datenbanken erreicht werden: • Datenunabhängigkeit • Benutzerorientierte Sicht der Daten • Datenintegrität • Vermeidung von Redundanz • Unterstützung der Datenmanipulation • Koordinierung des Mehrbenutzerbetriebs • Datenneutralität • Flexibilität • Effizienz 2 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2. Datenmodelle 2.1 Allgemein 2.1.1 Definition Datenstrukturen, die zur Beschreibung von Daten und deren Beziehung untereinander zur Verfügung stehen, bezeichnet man als Datenmodell. 2.1.2 Datenmodelle – Ein Überblick Hierarchisches Datenmodell: ältestes Datenmodell, bei dem ein Datensatz mit allen hierarchisch von ihm abhängigen Datensätzen als Einheit betrachtet wird. Dieses Konzept eignet sich für Beziehungen, bei denen sich aus einem Oberbegriff viele Unterbegriffe ableiten lassen (1:n-Beziehungen). Eine Beziehung zwischen einzelnen, in verschiedenen Ebenen abgespeicherten Datensätzen ist nicht möglich, was bei komplexen Beziehungen eine hohe Redundanz der Daten zur Folge hat. Ein Zugriff kann nur über den Suchschlüssel des Objekts der obersten Ebene erfolgen, wobei der Anwender den Pfad zum gesuchten Datensatz kennen muss. Netzwerkmodell: Im Gegensatz zum hierarchischen Ansatz kann beim Netzwerkmodell ein Datensatz eine beliebige Anzahl übergeordneter Datensätze aufweisen (n:m-Beziehungen). Das Netzwerkmodell eignet sich zum Beispiel für die Modellierung einer Stückliste, da ein Bauteil aus mehreren untergeordneten Teilen bestehen und zum anderen in mehrere übergeordnete Baugruppen eingehen kann. Bezüglich der Daten besteht Redundanzfreiheit, da sich überschneidende Beziehungen nicht durch mehrmalige physische Speicherung, sondern durch Verkettungen realisiert werden. Der Zugriff kann über beliebige Datensätze erfolgen, allerdings muss wiederum ein möglicher Pfad zum gewünschten Datensatz bekannt sein. Relationales Datenmodell: Beim relationalen Datenmodell stehen als Strukturelemente ausschließlich Relationen, die sich durch Tabellen darstellen lassen, zur Verfügung. Die Datensätze bilden die Zeilen, und die Merkmale des Objekts bzw. die Datenfelder entsprechen den Spalten der Tabelle. Beziehungen zwischen beliebigen Datensätzen werden über gleiche Feldinhalte hergestellt. Der Zugriff auf bestimmte Datensätze wird über die Feldinhalte ermöglicht. Dementsprechend arbeitet der Benutzer nur mit logischen, mengenorientierten Abfragen, wobei die physische Speicherung und der Datenzugriff für ihn im Hintergrund bleiben. Während sich beim Relationenmodell im Vergleich zu den oben beschriebenen Konzepten der Handha3 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken bungskomfort erhöht, steigen die Anforderungen im Hinblick auf die Rechengeschwindigkeit und die Zugriffsgeschwindigkeit auf die Speichermedien des Computers in erheblichem Maße, denn ein über die Angabe von Datenwerten definierter Zugriff kann die Durchsuchung sämtlicher Tabellen erforderlich machen. Objektorientiertes Datenmodell: Das objektorientierte Datenmodell beinhaltet eine Kombination von Ansätzen der klassischen Datenmodelle, der objektorientierten Programmierung und der Wissensrepräsentation. Ziel ist es, die Struktur und das Verhalten komplexer Objekte 1:1 in der Datenbank abzubilden. Insgesamt läßt sich feststellen, dass sich vollständig objektorientierte Datenbanken derzeit (1995) noch weitgehend im Entwicklungs- bzw. Erprobungsstadium befinden. Für den Anwender ist derzeit - bei entsprechenden Herstellerangaben - im Hinblick auf die Erfüllung dieses Kriteriums besondere Vorsicht angebracht. 2.2 Hierarchisches Datenmodell 2.2.1 Entwicklung und Struktur Das hierarchische Datenmodell ist das älteste Datenmodell. Es geht aus Informationsmanagementsystemen (IMS) der 50er und 60er Jahre hervor. Eingesetzt wurde es häufig in Banken und Versicherungsunternehmen. Das Model bildet die Entitätstypen/Klassen in einer streng hierarchischen Ordnung (Vater - Sohn) ab, bei der im Prinzip nur 1:1- und 1:n-Assoziationen möglich sind. Ein untergeordneter Entitätstyp (eine Subklasse) kann also nur zu einem einzigen VaterTyp (Oberklasse) gehören. So eignet es sich für Beziehungen, bei denen sich aus einem Oberbegriff viele Unterbegriffe ableiten lassen (1:n-Beziehungen). Ein Zugriff ist lediglich über den Suchschlüssel des Objekts der obersten Ebene möglich, deshalb muss der Anwender den Pfad zum gesuchten Datensatz genau kennen. Beispiel: Aufbau der Verzeichnisse im Betriebssystem DOS C:\Studium\EB8\Daba\Präsi.ppt Strukturelemente des hierarchischen Modells sind: 1. Objekttypen und 2. unbenannte hierarchische Beziehungen 4 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken „unbenannt“: Kanten haben keine Bezeichnungen für die Beziehung (Gegensatz dazu: Entity-Relationship-Modell) 2.2.2 Der Wurzelbaum Unter einem Wurzelbaum versteht man den Graph des Modells. Dieser besteht aus Knoten [Objekttypen] und Kanten [Beziehungen]. Abbildung 2: Wurzelbaum 2.2.3 Die hierarchische Ordnung Abbildung 3: Hierarchische Ordnung 5 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2.2.4 Die Beziehungen Abbildung 4: Beziehungen 2.2.5 Redundanz Abbildung 5: Darstellung der Redundanz bei n:m-Beziehungen 6 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2.3 Netzwerk-Datenmodell 2.3.1 Entwicklung Das Netzwerkdatenmodell wurde 1971 von der Database Task Group des Committee in Data Systems Languages (CODASYL/DBTG) als Standard publiziert; es wird daher auch als CODASYL/DBTG-Modell bezeichnet. Hinter der Entwicklung dieses Standards stand der Versuch, die Inflexibilität des Hierarchischen Datenmodells (Vermischung von interner und externer Ebene, nur 1:n-Beziehungen, Abhängigkeit der Performance vom jeweiligen Datenmodell, Zugriff nur durch Anwendungsprogramme) zu beseitigen. Das Netzwerkdatenbankmodell verkörpert ein heute nicht mehr besonders verbreitetes Datenbankmodell. Hierbei kann ein Datensatz mehrere Vorgänger haben. Im Gegensatz zum hierarchischen Datenmodell lassen sich im NetzwerkDatenmodell ohne zusätzliche Konzepte netzwerkartige Beziehungen definieren. Allerdings werden hier auch strukturbezogene Information durch die Definition von „Verbindungen“ zwischen Objekttypen dargestellt und wird damit wiederum eine prozedurale Datenverarbeitung induziert. Hier wurde der erfolgreiche Versuch unternommen, einen Standard für Datenbanksysteme zu schaffen. Es existieren meist unterschiedliche Suchwege um zu einem bestimmten Datensatz zu kommen. Das Netzwerkdatenbankmodell hat sich aus dem hierarchischen Datenbankmodell entwickelt und wurde hauptsächlich auf Großrechnern eingesetzt. Seit den 90er Jahren wird das Netzwerkdatenbankmodell vom relationalen Datenbankmodell mehr und mehr verdrängt. Der CODASYL-Standard wurde nach seiner Veröffentlichung als wesentliche Verbesserung gegenüber dem Hierarchischen Datenmodell begrüßt; führende Datenbankhersteller wie Siemens, Unisys, Honeywell oder DEC boten umgehend darauf basierende Datenbankmanagementsysteme an. Dass diese Systeme jedoch nie die Verbreitung und Akzeptanz erfuhren, die ihnen vorausgesagt wurde, lag daran, dass 1970 Codd sein Relationales Datenmodell veröffentlichte; dieses Modell ging hinsichtlich der Flexibilität und Einfachheit in der Modellierung weit über den CODASYL-Standard hinaus. Mit der Idee des Semantic Web gewinnt das Netzwerkdatenbankmodell allerdings wieder mehr an Bedeutung. 7 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2.3.2 Strukturelemente des Netzwerk-Datenmodells Strukturelemente des Netzwerk-Datenmodells sind, wie beim hierarchischen Modell, wiederum Objekttypen und hierarchische Beziehungen (1:mc-Beziehungen), die hier Set-Typen genannt werden, wobei der Begriff „Set“ in diesem Zusammenhang nicht der üblichen mathematischen Bedeutung (i.S.e. Menge) zu tun hat. Im NetzwerkDatenmodell können nur binäre many-one- (bzw. one-many)-Beziehungen dargestellt werden. Im Unterschied zum hierarchischen Modell können im Netzwerkmodell a priori mit Set-Typen netzwerkartige Strukturen definiert werden. Ein weiterer Unterschied besteht darin, dass Set-Typen benannte Beziehungen sind, d.h. sie tragen einen Namen. Ihnen können allerdings ebenfalls keine Attribute zugeordnet werden. Kurzgefasst ist ein Set-Typ also eine benannte hierarchische Beziehung ohne Attribute. E1 Owner-Typ b: Benennung eines Set-Typs b E2 Member-Typ Einem Set-Typ entsprechen auf der Objekt-Ebene mehrere Sets. Jedes Set besteht aus genau einem Owner und 0, 1 oder mehreren Membern. Ein Objekt kann in den Sets eines Set-Typs höchstens einmal als Owner und/oder höchstens einmal als Member auftreten (aber durchaus in mehreren Sets verschiedenen Typs). 2.3.3 Darstellung von Strukturen im NDM Die Darstellung einer 1:m-Beziehung ist im Netzwerk-Datenmodell natürlich nicht trivial, sie wird durch einen Set-Typ dargestellt. Die Darstellung einer m:n-Beziehung wird durch einen einfachen Trick erreicht (das uns übrigens auch im RelationenModell wieder begegnen wird). Zwischen die beiden Objekttypen der m:n-Beziehung wird ein Kett-Objekttyp (link entity type) eingefügt, der mit den beiden anderen Objekten je ein Set-Typ bildet. Die beiden Objekttypen sind darin jeweils die Owner. 8 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken Bauteil Lieferant geht über in: Bauteil B-L Lieferant Objekttypen können auch mit sich selbst in einer Beziehung stehen. Z.B. kann ein Bauteil Teil eines anderen Bauteils sein. Strukturell spricht man dabei von einer Schleife. Beziehungen dieser Art lassen sich ebenfalls mit Hilfe von Kett-EntityTypen darstellen. 2.3.4 Bewertung des Netzwerkdatenmodells Vorteile: • Die Vorteile des Netzwerkmodells beseitigen gerade etwa die Nachteile des relationalen Datenmodells. • Die Beziehungen zwischen Daten sind gut ersichtlich, im Konzept wie auch fallspezifisch. Nachteile: • Das Modellieren einer Netzwerkdatenbasis ist anspruchsvoller, da komplexere Beziehungen, die nicht ins hierarchische Schema passen, über mehrere Set-Typen und so genannte Kettrecords "aufgebaut" werden müssen. • Die explizite Speicherung der Beziehungen zwischen Daten kann mitunter viel Speicherplatz beanspruchen. • Wartung ist schwierig und aufwändig • kaum physische Datenunabhängigkeit Wie beim Hierarchischen Datenmodell wird auch hier beim Anwender sehr viel vorausgesetzt: • Er muss die Struktur der gesamten Datenbank kennen, um den Zugriffspfad zusammenstellen zu können. 9 Jochen Löhl, Mario Lörcher, Ingo Sahm • Historische Entwicklung von Datenanken Er muss Zugriffs-Algorithmen formulieren können, d.h. er muss nicht nur wissen, was er als Ergebnis haben will, sondern zusätzlich, wie man zu diesen Daten gelangt. Damit ist der Datenbankzugriff für Programmier-Laien immer noch zu schwierig und umständlich. 2.4 Das CODASYL/DBTG-Konzept 2.4.1 CODASYL CODASYL (COnference on DAta SYstems Languages) wurde im Rahmen eines Treffens von 40 Fachleuten aus Herstellerbranche, Rüstungsindustrie sowie staatlichen und militärischen Computerzentren am 28. und 29. Mai 1959 gegründet. Hintergrund des Treffens waren Probleme des US-Militärs im IT-Bereich, die durch die zunehmende Rechnervielfalt und die verwaltungstechnische Expansion hervorgerufen wurden. Diese sollten durch eine maschinen- und herstellerunabhängige Programmiersprache für Verwaltungsanwendungen gelöst werden, der Entwicklung das vorrangige Ziel von CODASYL war. Nur sechs Monate später, Anfang 1960, kam es zur Spezifikation und Veröffentlichung der Programmiersprache COBOL (COmmon Business Oriented Language). 1975 wurde schließlich Enhanced COBOL veröffentlicht, das COBOL um Datenbankmanipulationen erweiterte. Wenngleich einige Ausschüsse noch arbeiten, existiert CODASYL heute nicht mehr. Die erarbeiteten Dokumente wurden Charles Babbage Institute der University of Minnesota in den USA übergeben. 2.4.2 Entwicklung des CODASYL/DBTG-Konzepts 1967 wurde ein Untergremium von CODASYL, die Data Base Task Group (DBTG) gegründet, das die Entwicklung eines Datenmodells zur Aufgabe hatte, das die Inflexibilität und die Unzulänglichkeiten des hierarchischen Datenmodells beseitigen sollte: • Vermischung von interner und externer Ebene • nur 1:n-Beziehungen 10 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken • Abhängigkeit der Performance vom jeweiligen Datenmodell • Zugriff nur durch Anwendungsprogramme Das entwickelte Modell, das nach seiner Herkunft als CODASYL/DBTG-Konzept bekannt ist, ist ein Netzwerkdatenmodell und stellt einen ersten Vorschlag zur Standardisierung von Datenbanksystemen dar. Einen ersten Bericht legte die DBTG 1969 vor, eine überarbeitete Version folgte 1971. Das CODASYL/DBTG-Konzept besteht grundsätzlich aus zwei Ebenen der Datenbeschreibung: dem Schema und dem Subschema. Das Schema beschreibt dabei die logische Datenstruktur einschließlich der logischen Zugriffspfade einer Datenbank insgesamt. Dazu stellt das Datenmodell eine Data Definition Language (DDL) zur Verfügung. Das Subschema hingegen beschreibt die logische Datenstruktur aus der Sicht eines Anwendungsprogramms und stellt jeder Anwendung die von ihr benötigten Daten zur Verfügung. Dabei darf das Subschema jedoch nicht in Widerspruch mit dem Schema stehen. Die formale Beschreibung erfolgt mittels einer SubschemaBeschreibungssprache. Die Datenmanipulation des CODASYL/DBTG-Konzepts erfolgt mittels einer Data Manipulation Language (DML), die COBOL als Wirtssprache verwendet. Ursprünglich wurde eine Device Media Control Language für die Beschreibung der physischen Speicherorganisation geplant. Diese wurde jedoch nie spezifiziert. Eine Beschreibung der physischen Speicherschicht wurde erst 1978 mit der Veröffentlichung der Data Storage Description Language (DSDL) möglich. Das CODASYL/DBTG-Konzept wurde nach seiner Veröffentlichung als Verbesserung gegenüber dem hierarchischen Datenmodell begrüßt. Führende Datenbankhersteller boten darauf basierende Datenbankmanagementsysteme an. So gab es UDS von Siemens, Unisys veröffentlichte DMS-1100, Honeywell IDS und DEC das DBMS 10. Dennoch erreichte das CODASYL/DBTG-Konzept nie die vorhergesagte Akzeptanz und Verbreitung. Das lag unter anderem daran, dass das Datenmodell von IBM nicht unterstützt wurde und somit nicht zu einem Standard werden konnte. Zudem veröffentlichte Ted Codd 1970 das relationale Datenmodell, das einfacher und flexibler und noch heute gebräuchlich ist. 11 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2.4.3 Aufbau eines DBS nach dem CODASYL/DBTG-Konzept Abbildung 6: Aufbau eines DBS nach dem CODASYL/DBTG-Konzepf 1. 2. 3. 4. 5. 6. 7. 8. 9. Die Anwendung fordert Daten vom DBMS an. Das DBMS wertet die Anforderung, das Schema und das Subschema aus. Das DBMS fordert Input- und Output-Operationen vom Betriebssystem an. Das Betriebssystem greift auf den Speicher zu. Es findet ein Datentransfer zwischen dem Speicher und den Systempuffern statt. Die Daten werden entsprechend der Anforderung und dem Subschema der Anwendung in den Arbeitsbereich der Anwendung transferiert. Vom DBMS werden der Anwendung Statusinformationen (z. B. Fehlermeldungen) zur Verfügung gestellt. Das Anwendungsprogramm verarbeitet die erhaltenen Daten. Das DBMS verwaltet die System-Puffer für mehrere Anwendungen. 12 Jochen Löhl, Mario Lörcher, Ingo Sahm Historische Entwicklung von Datenanken 2.5 Das ANSI/X3/SPARC-Konzept Das ANSI/X3/SPARC-Konzept wurde 1975 von einer Arbeitsgruppe des American National Standards Institute (ANSI) entwickelt (ANSI/X3/SPARC = ANS Committee on Computers / Standards Planung and Requirement Committee. Im Gegensatz zu CODASYL besteht es aus drei Ebenen: Dem externen Schema, das für die Darstellung der Daten für einzelne Anwendungen zuständig ist (CODASYL: Subschema), dem konzeptionellen Schema für die logische Verwaltung der Daten innerhalb des Datenbanksystems (CODASYL: Schema) und zusätzlich dem internen Schema für die physische Organisation der Daten. Bis heute hat sich dieses Konzept als Entwurfskonzept und in der Terminologie zu Datenbanksystemen weitgehend durchgesetzt. Abbildung 7: Das ANSI/X3/SPARC-Konzept 13
