1 / 40

Historische Entwicklung von Datenbanken

Historische Entwicklung von Datenbanken. Agenda. Einführung 1.1 Historische Entwicklung 1.2 Motivation für Datenbanken Datenmodelle 2.1 Hierarchisches Datenmodell 2.2 Netzwerk-Datenmodell 2.3 Das CODASYL/DTBTG-Konzept 2.4 Das ANSI/X3/SPARC-Konzept. 1. Einführung.

laken
Download Presentation

Historische Entwicklung von Datenbanken

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Historische Entwicklung von Datenbanken

  2. Agenda • Einführung 1.1 Historische Entwicklung 1.2 Motivation für Datenbanken • Datenmodelle 2.1 Hierarchisches Datenmodell 2.2 Netzwerk-Datenmodell 2.3 Das CODASYL/DTBTG-Konzept 2.4 Das ANSI/X3/SPARC-Konzept Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  3. 1. Einführung 1.1 Historische Entwicklung • Ab 18. Jhd.: Lochkarten • 1956: Erfindung der Festplatte • 1968 – 1975: Hierarchisches Datenmodell • 1975 – 1980: Netzwerkdatenmodell • Ab 1980: Relationales Datenmodell Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  4. 1. Einführung 1.2 Motivation für Datenbanken • Mehr auf Verarbeitung als auf Strukturierung des Datenbestandes ausgerichtet • Keine Beschreibung der Beziehungen der Daten untereinander • Schwierige Pflege der Daten • Starre Kopplung zwischen Datein und Programmen Klassische Programmiersprachen (FORTRAN, ALGOL, Pascal) hatten lediglich primitive Dateimanipulations- Anweisungen Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  5. 1. Einführung 1.2 Motivation für Datenbanken • Änderungen in der Datenstruktur bedingen Änderungen in Programmen und umgekehrt (keine Datenunabhängigkeit) • Kein koordinierter Zugriff durch mehrere Programme • Jedes Programm war zuständig für Datenschutz und –sicherheit Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  6. 1. Einführung 1.2 Motivation für Datenbanken Daraus ergaben sich folgende Prinzipien: • Organisatorisch zentrale Betreuung von Daten • Trennung von Daten und Programmen DBS Programm A DBMS DB Programm B Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  7. 1. Einführung 1.2 Motivation für Datenbanken Erreichte Ziele durch Einsatz von Datenbanken • Datenunabhängigkeit • Benutzerorientierte Sicht der Daten • Datenintegrität • Vermeidung von Redundanz • Unterstützung der Datenmanipulation • Koordinierung des Mehrbenutzerbetriebs • Datenneutralität • Flexibilität • Effizienz Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  8. Agenda • Einführung 1.1 Historische Entwicklung 1.2 Motivation für Datenbanken • Datenmodelle 2.1 Hierarchisches Datenmodell 2.2 Netzwerk-Datenmodell 2.3 Das CODASYL/DTBTG-Konzept 2.4 Das ANSI/X3/SPARC-Konzept Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  9. 2. Datenmodelle Definition: Datenstrukturen, die zur Beschreibung von Daten und deren Beziehung untereinander zur Verfügung stehen, bezeichnet man als Datenmodell. [Stegemann, 1993] Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  10. 2. Datenmodelle Es gibt drei „klassische“ Datenmodelle: • Das hierarchische Modell • Das Netzwerkmodell • Das relationale Modell Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  11. 2. Datenmodelle 2.1 hierarchisches Datenmodell • Ältestes Datenmodell • Geht aus Informationsmanagementsystemen (IMS) der 50er und 60er Jahre hervor (Einsatzgebiete: Banken und Versicherungsunternehmen) • Eignet sich für Beziehungen, bei denen sich aus einem Oberbegriff viele Unterbegriffe ableiten lassen (1:n-Beziehungen) • Zugriff nur über den Suchschlüssel des Objekts der obersten Ebene möglich (die anderen entlang der hierarchischen Ordnung) • Anwender muss den Pfad zum gesuchten Datensatz kennenBeispiel: Aufbau der Verzeichnisse im Betriebssystem DOS C:\Studium\EB8\Daba\Präsi.ppt Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  12. 2. Datenmodelle 2.1 hierarchisches Datenmodell • Strukturelemente sind: Objekttypen und unbenannte hierarchische Beziehungen • „unbenannt“: keine Bezeichnungen für die Beziehung (Gegensatz dazu: Entity-Relationship-Modell) • Wurzelbaum (Graph ausObjekttypen [Knoten] undBeziehungen [Kanten]) Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  13. 2. Datenmodelle 2.1 hierarchisches Datenmodell Pfad Wurzel (root) Pfadlänge: hier Länge = 2 Niveau eines Knoten =Pfadlänge des Knoten von der Wurzel + 1 Kante Höhe eines Wurzelbaums =max. Pfadlänge innere Knoten Nachbarn Blätter Wurzelbaum-Typ / Hierarchie-Typ Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  14. 2. Datenmodelle 2.1 hierarchisches Datenmodell Hierarchische Ordnung a1 a2 b11 b12 b13 b14 b15 b21 b22 b23 c121 c122 C141 c211 c212 c142 Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  15. 2. Datenmodelle 2.1 hierarchisches Datenmodell Darstellung von Beziehungen: NICHTMÖGLICH !! Vater Student Tochter Sohn Matrikelnr. 1:n - Beziehung 1:1 - Beziehung m:n - Beziehung Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  16. 2. Datenmodelle 2.1 hierarchisches Datenmodell • Darstellungsversuch einer m:n-Beziehung m n Lieferant Bauteil L1 L2 BT1 BT2 BT3 BT1 BT2 BT1 L1 L2 BT3 L1 L2 ERHEBLICHE REDUNDANZ !!!!! Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  17. 2. Datenmodelle 2.1 hierarchisches Datenmodell • Redundanzdarstellung: [Bill/Fritsch, 1991] Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  18. 2. Datenmodelle 2.1 hierarchisches Datenmodell PRO • Werden Daten in Richtung der Hierarchie gesucht, so ist der Zugriff sehr schnell CONTRA • Werden Daten gegen die Richtung der Hierarchie gesucht, muss ggf. die gesamt Datenbank durchsucht werden. In diesem Falle sehr langsam • Unflexibel • Bei komplexen Umgebungen schwierig zu modellieren Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  19. 2.2 Netzwerkdatenmodell • Entwicklung • 1971 von der Database Task Group des CODASYL als Standard publiziert • Versuch, die Inflexibilität des Hierarchischen Datenmodells (Vermischung von interner und externer Ebene, nur 1:n-Beziehungen, Abhängigkeit der Performance vom jeweiligen Datenbestand, Zugriff nur durch Anwendungsprogramm) zu beseitigen • Netzwerkartige Beziehungen lassen sich ohne zusätzliche Konzepte definieren Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  20. 2.2 Netzwerkdatenmodell • Entwicklung • Das NDM erfuhr nie die Verbreitung und Akzeptanz, da Codd 1970 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 wieder mehr an Bedeutung Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  21. E1 E2 2.2 Netzwerkdatenmodell • Strukturelemente Member-Typ b b: Benennung eines Set-Typs Rekord-Typ Owner-Typ Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  22. 2.2 Netzwerkdatenmodell • Strukturelemente • Wie beim Hierarchischen Datenmodell bereits erwähnt: Objekttypen und hierarchische Beziehungen (1:mc-Beziehungen), die hier Set-Typen genannt werden • Im Netzwerkdatenmodell können nur binäre many-one (bzw. one-many)-Beziehungen dargestellt werden • Set-Typen sind benannte Beziehungen; d.h. sie tragen einen Namen • Ihnen können allerdings keine Attribute zugeordnet werden • Ein Set-Typ ist also eine benannte hierarchische Beziehung ohne Attribute Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  23. 2.2 Netzwerkdatenmodell • Darstellung von Strukturen • Die Darstellung einer 1:m-Beziehung wird durch einen Set-Typ dargestellt • Die Darstellung von m:n-Beziehungen wird durch einen einfachen Trick ermöglicht: • Zwischen den beiden Objekttypen wird ein Kett-Objekttyp eingefügt, der mit den beiden anderen Objekttypen je einen Set-Typ darstellt • Die beiden Objekttypen sind darin jeweils die Owner Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  24. Bauteil Lieferant Bauteil B-L Lieferant 2.2 Netzwerkdatenmodell • Darstellung von Strukturen Kett-Typ „Bauteil-Lieferant“ Geht über in: Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  25. B1 B2 B3 L1 L2 B1 B2 B3 B1 L1 B1 L2 B2 L2 B3 L1 B3 L2 L1 L2 2.2 Netzwerkdatenmodell • Darstellung von Strukturen Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  26. 2.2 Netzwerkdatenmodell • Stärken • Normierter Zugriff und Modellierung. • Sehr effizient, wenn die Verarbeitung der physischen Organisation entspricht • Keine strenge Hierarchie durch Abbildung von m:n-Beziehungen • Schwächen • Mangelhafte Datenunabhängigkeit: • Kleine Änderungen an der Datenorganisation haben gewaltige Auswirkungen auf die Programme. • Komplexe Modellierung, da nur eingeschränkte Mechanismen verfügbar. • Anwendungsprogramme sind sehr komplex und schwer wartbar Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  27. 2.3 Das CODASYL/DBTG-Konzept CODASYL (Conference on Data Systems Languages) • Gründung im Rahmen eines Treffens von 40 Fachleuten aus Herstellerbranche, Rüstungsindustrie, staatlichen und militärischen Computerzentren am 28. und 29. Mai 1959 • Bedarf nach einer maschinen- und herstellerunabhängigen Programmiersprache für Verwaltungsanwendungen • Probleme des Militärs durch Rechnervielfalt und verwaltungstechnische Expansion • Nach sechs Monaten Spezifikation und Veröffentlichung der Programmiersprache COBOL (COmmon Business Oriented Language) Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  28. 2.3 Das CODASYL/DBTG-Konzept CODASYL (Conference on Data Systems Languages) • 1969: DBTG-Report (DBTG: Data Base Task Group) • 1971: Überarbeitete Version des DBTG-Reports  Vorstellung des CODASYL/DBTG-Konzepts • 1975: Enhanced Cobol  Cobol erweitert um DB-Manipulationen • CODASYL als solches exisitert heute nicht mehr  einige Ausschüsse arbeiten jedoch noch • Archivierte Dokumente im Charles Babbage Institute, University of Minnesota Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  29. 2.3 Das CODASYL/DBTG-Konzept Entwicklung des CODASYL/DBTG-Konzepts • 1967 Gründung der Database Task Group (DBTG) Ziel: Entwicklung eines Datenmodells um die Inflexibilität des hierarchischen Datenmodells zu beseitigen Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  30. 2.3 Das CODASYL/DBTG-Konzept Entwicklung des CODASYL/DBTG-Konzepts Unzulänglichkeiten des hierarchischen Datenmodells: • Vermischung von interner und externer Ebene • nur 1:n-Beziehungen • Abhängigkeit der Performance vom jeweiligen Datenmodell • Zugriff nur durch Anwendungsprogramme Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  31. 2.3 Das CODASYL/DBTG-Konzept Entwicklung des CODASYL/DBTG-Konzepts • Deshalb Entwicklung des CODASYL/DBTG-Konzepts durch die Data Base Task Group (DBTG) • Netzwerkdatenmodell • Erster Vorschlag zur Standardisierung von Datenbanksystemen  vorgestellt 1971 • Zunächst nur zwei Ebenen der Datenbeschreibung: • Schema • Subschema Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  32. 2.3 Das CODASYL/DBTG-Konzept • Beschreibt die logische Datenstruktur einschließlich der logischen Zugriffspfade einer Datenbank insgesamt • Formale Beschreibung durch Data Definition Language (DDL) Schema Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  33. 2.3 Das CODASYL/DBTG-Konzept Subschema • Beschreibt die logische Datenstruktur aus der Sicht eines Anwendungsprogramms • Von einer Anwendung benötigte Datenmenge  In der Regel Teilmenge aller Daten der Datenbank (kann strukturell anders zusammengestellt sein) • Darf jedoch nicht im Widerspruch zum Schema stehen • Formale Beschreibung durch Subschema-Beschreibungssprache Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  34. 2.3 Das CODASYL/DBTG-Konzept • Datenmanipulation durch DML (Data Manipulation Language)  benutzt COBOL als Wirtssprache • Device Media Control Language für die Beschreibung der physischen Speicherorganisation vorgesehen, jedoch nicht spezifiziert • Beschreibung der physischen Speicherschicht erst 1978 als Data Storage Description Language (DSDL) Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  35. 2.3 Das CODASYL/DBTG-Konzept • CODASYL/DBTG-Konzept wurde nach seiner Veröffentlichung als Verbesserung gegenüber dem hierarchischen Datenmodell begrüßt • Führende Datenbankhersteller boten darauf basierende DBMS an: • Siemens: UDS • Unisys: DMS-1100 • Honeywell: IDS • DEC: DBMS 10 Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  36. 2.3 Das CODASYL/DBTG-Konzept • Allerdings erreichte das CODASYL/DBTG-Konzept nie die vorhergesagte Akzeptanz und Verbreitung • Gründe: • keine Unterstützung durch IBM (Verhinderung der Entstehung eines Standards) • Veröffentlichung des relationalen Datenbankmodells durch Ted Codd 1970 • Modellierung einfacher und flexibler • noch heute gebräuchlich Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  37. 2.3 Das CODASYL/DBTG-Konzept 2. DBMS wertet Anforder- ung, Subschema und Schema aus 3. DBMS fordert I/O-Opera- tionen vom OS an 4. OS greift auf Speicher zu 5. Datentransfers zwischen Speichern und System- Puffern 9. DBMS verwaltet System- Puffer für verschiedene Anwenderprogramme 6. Datentransfer zwischen System-Puffern und Ar- beitsbereich der Anwen- dung entsprechend Sub- schema und Anforderung 7. DBMS stellt dem Anwen- derprogramm Status- informationen zur Verfü- gung (z. B. Fehlermeld.) 8. Anwenderprogramm ver- arbeitet die Daten • Anforderung der Datenvom DBMS Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  38. 2.4 Das ANSI/X3/SPARC-Konzept • 1975 entwickelt von einer Arbeitsgruppe des American National Standards Institute (ANSI) • ANSI/X3/SPARC = ANS Committee on Computers / Standards Planung and Requirement Committee • Besteht aus drei Ebenen:  Externes Schema (bei CODASYL Subschema) • Konzeptionelles Schema (bei CODASYL Schema) • Internes Schema (physische Organisation der Daten) • Als Entwurfskonzept und in der Terminologie zu Datenbanksystemen weitgehend durchgesetzt Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  39. 2.4 Das ANSI/X3/SPARC-Konzept Verarbeitet das konzeptionelle Schema Enthält die Metadaten (Beschreibung der Daten, logische Datenorganisation, Zugriffsrechte,...) Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

  40. Vielen Dank für die Aufmerksamkeit! Fragen? Historische Entwicklung von Datenbanken Jochen Löhl Mario Lörcher Ingo Sahm

More Related