Miniwelt E/R-Diagramm Hier. DB- Schema Netzwerk-DB
Werbung
Anforderungsanalyse und -spezifikation Miniwelt Konzeptioneller Entwurf E/R-Diagramm (E/R-Modell Logischer Entwurf Hier. DBSchema (HDM Datendefinition Durch Wahl eines Produkts Datenbanksysteme 1 Kapitel 3) In Vorlesung am Beispiel IMS Kapitel 2) Netzwerk-DB-Schema / Bachman-Diagramm (NDM Kapitel 4) In Vorlesung nicht betrachtet 03.12.2012 Rel. DBSchema (RDM Kapitel 5) Entsprechend der SQL-Norm (Übung: DB2) 111 3. Das hierarchische Daten(bank)modell Zielsetzung des Kapitels: • (Modellierungs-)Möglichkeiten mit dem hierarchischen Datenbankmodell (HDM) • Zusammenhang E/R-Modell HDM, Hierarchien in Dateistrukturen HDM • Erweiterung reiner Hierarchien in Richtung auf vernetzte Strukturen mittels sog. virtueller Satztypen • Datendefinition und –beschreibung für das HDM am Beispiel des Systems IMS (Information Management System) • Datenmanipulation (Datenbanksprache) bei IMS mittels navigierender Operationen (Programmierspracheneinbettung) Datenbanksysteme 1 03.12.2012 112 Hinweis/Bemerkungen: • Kap. 3 über das HDM (und ebenso Kap. 4 über das Netzwerk-Daten(bank)modell (NDM)) hat nicht zum Ziel, die Teilnehmer unmittelbar in die Lage zu versetzen, mit einem entsprechenden Datenbanksystem à la IMS umzugehen wären viele weitere Details nötig zum kompletten Durchdringen! • Aber: Es sollte verstanden werden, was die Möglichkeiten des HDM und konkret von IMS sind in bezug auf Modellierung/Datenmanipulation und welche Probleme/Limitationen existieren; die Teilnehmer sollten zudem anschließend in der Lage sein, IMSDatenbankdefinitionen zu lesen und zum Teil zu verstehen, ebenso „ein wenig“ Anwendungsprogramme mit eingebetteten IMS-Datenbanksprachanweisungen (Sprache DL/1 (Data Language / One)) ! • Merke: Die Zahl der IMS-Datenbanken in der Praxis ist groß, wenngleich neue Datenbanken heute weitgehend in relationaler Technologie erstellt werden Datenbanksysteme 1 03.12.2012 113 Hierarchien in Dateiinhalten sowie in E/R-Diagrammen Bsp.: Verwaltung von Informationen über Kunden, Aufträge und Auftragspositionen a) Datei(struktur) Auftrag 1 ... Auftragsnummer Auftragsdatum Besteller Kundennummer Kundenname Adresse AU-Kopf Auftrag 2 AU-Rumpf AU-Pos 1 ... ... AU-Pos 2 Artikelnummer Menge Farbe Kundex Artikelnummer Menge Farbe ... ... ... ... typische Dateistruktur bei Vorliegen von variabel langen Datensätzen (Wiederholungsgruppen in Datensätzen), in der „kommerziellen Datenverarbeitung“ in betriebswirtschaftlichen Anwendungen Zugriff auf die Daten geht hierarchisch „top-down“ und i.d.R. „von links nach rechts“ Datenbanksysteme 1 03.12.2012 114 b) Entity-Relationship-Modell Kardinalitäten in 1:n-Notation KUNDE 1 n Kardinalitäten in (min,max)-Notation (0,*) ERTEILT (1,1) also Waisenkinder nicht erlaubt AUFTRAG 1 n unterspez. (1,*) ENTHÄLT also Waisenkinder nicht erlaubt (1,1) AU-POS c) Darstellung im HDM KUNDE Kanten im HDM stehen implizit für (hierarchische) Beziehungstypen AUFTRAG AU-POS Kante hat implizit (0,*) und (1,1) Semantik dass es sich dabei um 1:n-Beziehungen (hierarchische Beziehungen) handelt, ist implizit klar und wird deshalb bei HDM-Datenbankschemata nicht explizit notiert Datenbanksysteme 1 03.12.2012 115 Bsp.: Erweiterung des zu modellierenden Miniweltausschnitts um Informationen über Rechnungen und Rechnungsposten Darstellung im HDM • Typebene KUNDE AUFTRAG RECHNUNG AU-POS RE-POS Baum • Ausprägungsebene (Instanzenebene, Satzebene) (Entity-Ebene) Lüdenscheid Einstiegspunkte Müller Meyer Wald A1 AU-Pos11 AU-Pos12 A2 AU-Pos21 A3 AU-Pos11 Jeder untergeordnete Satz (Sohn, Kind) ist genau einem übergeordneten Satz (Vater) zugeordnet; keine Waisenkinder [zum untergeordneten Satz greift man über den übergeordneten Satz zu] Datenbanksysteme 1 03.12.2012 116 Hierarchisches Daten(bank)modell HDM Datenbankmodell, bei dem zu modellierende Miniwelt ausschließlich mit Hierarchien dargestellt wird Nicht notwendigerweise nur eine Hierarchie, sondern „Sammlung“ von Hierarchien, z.B. KUNDE AUFT KUNDE 5 Hierarchien („Datenbanken“) HDM-Datenmodell (Datenbankschema) dargestellt sind Entitytypen sowie hierarchische Beziehungen zwischen Entitytypen, wichtig: jeder Entitytyp kommt im Datenmodell (Datenbankschema) nur einmal vor (sonst läge keine rein hierarchische Beziehungsstruktur vor*) Eindeutige Entitytypnamen innerhalb eines DB-Schemas * auf die Frage des Umgang mit „Nicht-Hierarchien“ s.u. Datenbanksysteme 1 03.12.2012 117 Bestandteile / Eigenschaften einer Hierarchischen Datenbank Daten Datenbankschema Bestandteile: Schema (Typ) • Menge von Entitytypen (benannt) Daten • Menge von (benannten) Hierarchien („Bäumen à la Folie 114) (mit einer Hierarchieordnung versehen) über den Entitytypen • Menge von Entities, die auf der Ausprägungsebene – entsprechend der Typhierarchie – untereinander in Beziehung stehen können • Ordnungsreihenfolge innerhalb eines jeden Entity Set Hierarchieordnung drückt aus, dass die Reihenfolge des Auftretens von Kindern eines Vaters von Bedeutung ist: A Typebene B C A C B Grund: Reihenfolge auf der Typebene („linker Sohn, rechter Sohn“) bestimmt Abarbeitungsreihenfolge auf der Instanzebene (Entityebene) Datenbanksysteme 1 03.12.2012 118 Instanzebene betrachtet für Hierarchie (Typebene) A Entitytypen B C D a1 a2 1 9 b11 2 b12 b13 7 c11 8 c12 10 b21 ... Entities 3 d111 4 6 d121 d122 5 : Abarbeitungsreihenfolge „von oben nach unten, links nach rechts“ (präorder) Hierarchieordnung auf Typebene und Ordnungsreihenfolge auf Entity Set Ebene müssen gegeben sein zur Festlegung einer eindeutigen Abarbeitungsreihenfolge Datenbanksysteme 1 03.12.2012 119 Eigenschaften/Bezeichnungen: • Jeder Entitytyp einer Hierarchischen Datenbank gehört zu genau einer Hierarchie • Der oberste Entitytyp einer Hierarchie wird auch als Wurzeltyp bezeichnet • Für den Wurzeltyp existiert ein Primärschlüssel, der die direkte Auswahl (eindeutige Identifizierung) eines Entity aus dem zugehörigen Entity Set erlaubt gibt einen Einstiegspunkt über die Wurzel in den zugehörigen Baum auf Instanzenebene skizziert: 1 a1 a2 a3 ... 3 Hierarchieausprägungen auf der Instanzenebene präorder-Abarbeitung Entity a2 wurde über seinen Primärschlüsselwert identifiziert, anschließend wird der zugehörige Instanzenbaum abgearbeitet gemäß Hierarchieordnung auf Typebene + Ordnungsreihenfolge auf Entity Set Ebene Datenbanksysteme 1 03.12.2012 120 alle Bäume Abarbeitung kann aber auch so erfolgen, dass auch auf oberster Ebene die Instanzen gemäß Ordnungsreihenfolge auf Entity Set Ebene abgearbeitet werden und von jeder Instanz aus (wie gehabt) der Unterbaum abgearbeitet wird erstes Entity innerhalb der Ausprägungen des Wurzeltyps bildet Einstiegspunkt 1 a1 a2 a3 Durchlaufen des gesamten Waldes mit GET NEXT m-1 entities n-1 entities vollständiges Durchlaufen aller Entities auf der Ausprägungsebene innerhalb einer Typhierarchie • Erreichbarkeit Jedes Entity einer Hierarchischen Datenbank ist erreichbar auf einem der folgenden Wege: - Wurzelentities über Primärschlüsselwert oder in Ordnungsreihenfolge auf Entity Set Ebene - Nichtwurzelentities nur über das jeweilige Vaterentity Datenbanksysteme 1 03.12.2012 121 Konsequenzen aus bisheriger Diskussion: • Ein direkter Zugriff (Einstieg) auf ein beliebiges Entity auf Ausprägungsebene ist im hierarchischen Datenmodell nicht möglich, sondern lediglich auf der Wurzelebene des Baums vorgesehen • Dies entspricht genau Verarbeitungsmodell auf Dateiebene (vgl. Folie 111), auch dort kann nicht einfach von außen in irgendeine Wiederholungsgruppe „reingesprungen“ werden; dass man auf der Wurzelebene einer Hierarchie beim Hierarchischen Datenmodell direkt „reinspringen“ kann, ist aber gegenüber Dateiverwendung bereits ein Gewinn, wo dies nicht in allen Fällen möglich ist (rein sequentielle Dateiorganisationsform ermöglicht überhaupt kein „Reinspringen“) • Eine Operation der Art „gehe (navigiere) zum Vater“ wird im Hierarchischen Datenmodell nicht benötigt, weil aufgrund der TopDown-Vorgehensweise der Vater ohnehin stets vorher besucht worden war und somit bekannt ist ( vollständigen hierarchischen Pfad ) [Wir werden später sehen: Das Netzwerk-Datenmodell, wo Einstiegspunkte beliebig in der vernetzten Struktur sich befinden können, braucht hingegen Navigation zum Vater.] ! Datenbanksysteme 1 03.12.2012 122 • Thema Zugriffsunterstützung (Anmerkungen) KUNDE Wurzelentitytyp AUFTRAG - Gib mir den Kunden mit Namen ´Willi Winzig´: Möglich und geht schnell (Zugriffspfad à la B*-Baum oder Hashtabelle kann vereinbart werden) - Gib mir den Auftrag vom 12.11.05 des Kunden mit Namen ´Willi Winzig´ (angenommen, für den Kunden existieren Tausende von Aufträgen): Es kann ebenfalls Zugriffspfad vereinbart werden, um auf bestimmtes Kind (Auftrag vom 12.12.95) eines zuvor lokalisierten Vaters schnell zuzugreifen, aber: Einstieg von außen zunächst zum Vater (Wurzelentity ´Willi Winzig´), dann zum qualifizierten Kindentity (Auftrag vom 12.11.05) Datenbanksysteme 1 03.12.2012 123 Erweiterung des hierarchischen Datenmodells zur Erfassung nichthierarchischer Sachverhalte Problem: Entitytyp müsste eigentlich mehrfach, d.h. in verschiedenen Hierarchien, auftreten im Hierarchischen Datenmodell verboten! (vgl. Folie 117) Beispiel: ABTEILUNG ANGEST POSITION ANGEST Position soll im Entity für jede Ebene im Unternehmen beinhalten(„Indianer“, „Unterhäuptling“ ...); zu jeder Position möchte man als Kinder die Angestellten, die dieser Position angehören Datenbanksysteme 1 03.12.2012 124 Lösungsvarianten: 1. Einführung von (unkontrollierter) Redundanz ABTEILUNG ANGEST POSITION zulässig ANGEST´ Bewertung: • Aus Sicht des Datenbanksystems sind ANGEST und ANGEST´ unterschiedliche Entitytypen • Entities der modellierten Miniwelt (Angestellten) sind jeweils zweimal vorhanden, einmal im Entity Set von ANGEST, einmal im Entity Set von ANGEST´ Diskrepanz zwischen Miniwelt und Darstellung der Miniwelt in der Datenbank • Datenbanksystem kann Redundanz (Konsistenz!) nicht überwachen, sondern dies muss durch den Benutzer / die Anwendung geschehen keine akzeptable Lösung abzulehnen!! Datenbanksysteme 1 03.12.2012 125 2. Einführung von sog. virtuellen Entity(Satz)typen 1. Beispiel ABTEILUNG ANGEST POSITION Zeiger virtueller ANGEST oder: ABTEILUNG virtueller ANGEST POSITION Zeiger ANGEST Idee: • Nur in einer Hierarchie existieren die ANGEST-Entities physisch (d.h. sind sie tatsächlich gespeichert) • Aus anderen Hierarchien heraus wird auf diese Entities per Zeiger verwiesen • Die Benutzer sehen diese Form der unterschiedlichen Realisierung (mal physisch direkt gespeichert, mal nur über Zeiger referenziert) nicht! (lediglich der Datenbankadministrator/Anwendungsadministrator bekommt sie zu sehen bzw. muss sie definieren) ! Datenbanksysteme 1 03.12.2012 126 Zur Beurteilung (anhand obigen Beispiels) ABTEILUNG POSITION ANGEST virtueller ANGEST Anfragen • Finde alle Angestellten einer best. Abteilung effizient möglich • Finde alle Angestellten mit einer best. Position effizient möglich • Finde die Abteilung eines best. Angestellten ineffizient* • Finde die Position eines best. Angestellten ineffizient* * da kein Einstieg in die Hierarchie über Angestellte möglich Datenbanksysteme 1 03.12.2012 127 2. Beispiel für virtuelle Entity(Satz)typen Gegeben sei n:m-Beziehung LIEFERANT (0,*) n LIEFERT (0,*) m ARTIKEL Gesucht: HDM-Repräsentation mit - Einstiegsmöglichkeit sowohl über Lieferanten als auch über Artikel - Gleichberechtigter Darstellung von Lieferanten und Artikeln Lösung im HDM: LIEFERANT virtueller ARTIKEL ARTIKEL Zeiger virtueller LIEFERANT Was geschieht, wenn Beziehungstyp LIEFERT Attribute besitzt? (Bsp.: MENGE) Werte werden (zusammen mit den Zeigern) in den Ausprägungen der virtuellen Entity(Satz)typen vARTIKEL und vLIEFERANT gespeichert Redundanz Datenbanksysteme 1 03.12.2012 128 IMS als das Beispiel eines „hierarchischen“ Datenbanksystems • Information Management System, IBM • „Das“ Datenbanksystem schlechthin auf Grundlage des (erweiterten) hierarchischen Daten(bank)modells • Produkteinführung schon seit Ende der 1960er Jahre • Status: - Auch heute noch weite Verbreitung in der Praxis, Ablösung durch relationale DBSe erfolgt nur langsam; Unternehmen setzen eher (zumindest für gewissen (teils langen) Zeitraum) auf Koexistenz zwischen hier. DBS und rel. DBS - hohe Stabilität des Systems, hohe Performance - Aber: Daten(bank)modell und Datenbanksprache nicht sehr flexibel; Sprache „low level“, schwer zu beherrschen (s.u.) Datenbanksysteme 1 03.12.2012 129 IMS-Notation und -Terminologie Bildliche Darstellung einer IMS-Typhierarchie ... Kurs-DB Kurs KursNr Titel Vorauss ... Angebot VorNr AngNr Datum Ort Teilnehmer PersNr Name ... TnNr Name Ort ... Struktur einer IMS-Datenbank ... und der zugehörigen Satzausprägungen 4711 Datenb. I ... Kurs 0815 KI ... Angebot Vorauss 4711 3 007 2 1 290296 080196 181295 München Hamburg Jena ... ... Teilnehmer Kursleiter 059906 ... Müller-Meer. ... 192 174 165 Datenbanksysteme 1 03.12.2012 Zell Coy Bosse Coburg Kiel Rostock ... Satzausprägungen einer IMS-Datenbank Kursleiter ... ... ... 130 Begriffe und Eigenschaften • Die Knoten in der Typhierarchie (bislang als Entitytypen bezeichnet) werden in IMS Segmente (segments) genannt; jedes Segment besteht aus Feldern (fields) • Die Segmente einer Typhierarchie (IMS-Datenbank) werden in Präorder-Reihenfolge als geordnet betrachtet, im obigen Beispiel: 1. Kurs 2. Vorauss IMS-Segmente 3. Angebot 4. Kursleiter 5. Teilnehmer • Es gibt in der IMS-Datenbank jeweils ein ausgezeichnetes (unabhängiges) Wurzel-Segment (root segment), die anderen Segmente sind somit abhängige Segmente (dependent segments) • Weitere Begriffe: Vater-Segment (parent segment), Kind-Segment (child segment), Geschwister-Segmente (siblings) • Die Knoten im Instanzenbaum (Ausprägungsebene); bislang als Entities bezeichnet, werden im IMS Sätze (records) genannt; die Sätze enthalten Feldausprägungen (field occurrences) Datenbanksysteme 1 03.12.2012 131 • Entsprechend gibt es auf der Ausprägungsebene root records, dependent records, parent/child records, siblings (Übertragung der Bedeutung, die die Begriffe auf der Typ-(Segment-)Ebene haben) • Zu den Beziehungen in der Ausprägungshierarchie: - Ein child record kann nur existieren, wenn und solange der zugehörige parent record existiert (keine „Waisenkinder“ erlaubt) - Die Zuordnung von child records zum parent record erfolgt ! explizit durch den Anwendungsprogrammierer beim Einfügen des child record (d.h. das Anwendungsprogramm entscheidet, wo – an welchen parent record – ein neuer child record „angehängt“ wird es gibt keine automatische, werteabhängige Zuordnung von child records zu einem parent! D.h. Konsistenzwahrung erfolgt durch AP Datenbanksysteme 1 03.12.2012 132 Schemadefinition in IMS DDL a) Konzeptuelles (und internes) Schema • Die Struktur einer IMS-Datenbank (IMS-Typhierarchie) wird auch als Physical Database Record Type bezeichnet (Folie 127 obere Hälfte) • Die Festlegung der Struktur (Segmente, (hierarchische) Beziehungen, Felder (Namen, Längen ...) erfolgt durch die sog. Database Definition (DBD) Die Database Definition (DBD) beschreibt einen wesentlichen Teil des konzeptuellen (und einige Aspekte des internen) Schemas einer IMSDatenbank IMS bietet keine klare Trennung zwischen Beschreibung der konzeptuellen und der internen Ebene! unschön, unsauber In der DBD können nur 1:n-Beziehungstypen modelliert werden, also Hierarchien Datenbanksysteme 1 03.12.2012 133 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 DBD SEGM FIELD FIELD SEGM FIELD SEGM FIELD FIELD FIELD SEGM FIELD FIELD SEGM FIELD FIELD FIELD END NAME=KursDB NAME=Kurs, BYTES=36 NAME=(KursNr,SEQ), BYTES=3, START=1 NAME=Titel, BYTES=33, START=4 NAME=Vorauss, PARENT=Kurs, BYTES=3 NAME=(VorNr,SEQ), BYTES=3, START=1 NAME=Angebot, PARENT=Kurs, BYTES=21 NAME=(AngNr,SEQ), BYTES=3, START=1 NAME=DATUM, BYTES=6, START=4 NAME=Ort, BYTES=12, START=10 NAME=Kursleiter, PARENT=Angebot, BYTES=23 NAME=(PersNr,SEQ), BYTES=5, START=1 NAME=Name, BYTES=18, START=6 NAME=Teilnehmer, PARENT=Angebot, BYTES=41 NAME=(TnNr,SEQ), BYTES=3 , START=1 NAME=Name, BYTES=18, START=4 NAME =Ort, BYTES=20, START=22 Definition des Physical Database Record Type (IMS-Datenbankstruktur) für die KursDB von Folie 127 (die mittels geeigneter START- und BYTES-Festlegungen möglichen „Overlay-Strukturen“ auf Feldebene innerhalb von Segmenten sind natürlich, konzeptuell betrachtet, problematisch (fehleranfällig, versteckte Semantik ...)) Datenbanksysteme 1 03.12.2012 134 Erläuterungen zur DBD der KursDB • Die Reihenfolge der Segmentdefinitionen (SEGM ...) bestimmt die (Präorder-)Reihenfolge der Segmente in der IMS-Typhierarchie, d.h. Folie 131 spezifiziert genau Typhierarchie von Folie 127 obere Hälfte Aus IMS-Sicht sind alle Felder Bytestrings, d.h. untypisiert und besitzen feste Länge • Die SEQ-Angabe legt fest, dass die Segmentausprägungen (Sätze) nach diesen Feldwerten aufsteigend sortiert sind; die mit SEQ- Angabe versehenen Felder sind damit auch gleichzeitig Schlüsselfelder Datenbanksysteme 1 03.12.2012 135 b) Externe Schemata • Zugriff auf die IMS-Datenbank nur über Anwendungsprogramme (Möglichkeiten zum Ad-hoc-Zugriff „im Prinzip“ nicht vorhanden) • Anwendungsprogramme sehen nicht die Physische Datenbank (Physical Database Record Type), sondern bekommen sog. Program Communication Block (PCB) zu sehen • Genaugenommen, kann ein Programm mehrere PCBs verwenden; die verwendeten PCBs bilden den sog. Program Specification Block (PSB) = externes Schema • Möglichkeiten bei der PCB-Definition: Auswahl eines Teilbaums aus der DBD-Spezifikation: - Jedes Feld kann weggelassen werden („ausgeblendet“) - Jedes Segment kann weggelassen werden, mit Ausnahme des Wurzelsegments - Wird ein Segment weggelassen, so entfallen auch alle davon abhängigen Segmente Datenbanksysteme 1 03.12.2012 136 Definition ext. Schema für PS 1 2 3 4 5 6 7 8 PCB SENSEG SENSEG SENFLD SENFLD SENSEG PSBGEN END DBDNAME=KursDB, KEYLEN=9 NAME=Kurs, PROCOPT=G NAME=Angebot, PARENT=Kurs, PROCOPT=G NAME=(AngNr,SEQ), START=1 NAME=DATUM, START=4 NAME=Teilnehmer, PARENT=Angebot, PROCOPT=GID LANG=COBOL, PSBNAME=KursMaint Definition eines Teils eines externen Schemas auf der IMS-Datenbank KursDB (vgl. DBD-Definition Folie 131) keine werteabhängige Auswahl möglich bei Definition des externen Schemas Verständnis von IMS bzgl. Sichtdefinition (vgl. relationale VIEWS) Datenbanksysteme 1 03.12.2012 137 Erläuterungen zur PCB-Definition (Folie 134) • Definition eines externen Schemas der Struktur Kurs KursNr Titel Angebot AngNr Datum Teilnehmer TnNr Name Ort • Die in SENSEG-Anweisungen aufgeführten Segmente („sensibilisierte“/ “sensitive“ Segmente) werden auf diese Weise „sichtbar“ gemacht, sind also damit Teil des externen Schemas und vom Programm, das den PCB nutzt, aus ansprechbar • SENFLD „sensibilisiert“ dementsprechend Felder in Segmenten (N.B.: Wenn auf ein SENSEG kein SENFLD folgt, gelten alle Felder des Segments als „sensibilisiert“) • PROCOPT (Processing Options) definiert Zugriffsrechte zu den Sätzen eines Segments (G=Get, I=Insert, D=Delete) Datenbanksysteme 1 03.12.2012 138 • PSBGEN LANG=COBOL legt fest, dass Datenstrukturen (Datenübergabebereiche, Kontrollblöcke) für eine Verwendung des externen Schemas aus COBOL-Programmen heraus generiert werden sollen • KEYLEN=9 legt Länge der key feedback area fest; enthält nach jedem Zugriff auf die Datenbank die konkatenierten Schlüsselwerte entlang des hierarchischen Pfads, in unserem Bsp.: 3 Bytes KursNr + 3 Bytes AngNr + 3 Bytes TnNr, also etwa (vgl. Folie 127) zur eindeutigen Identifizierung 0815 1 174 des Teilnehmers Bosse aus Rostock Datenbanksysteme 1 03.12.2012 139 Zugriff auf IMS-Datenbanken mit DL/1 (Data Language / One) • DL/1 ausschließlich zum Datenbankzugriff (Einfügen, Lesen, Ändern, Löschen) aus Anwendungsprogrammen heraus gedacht (COBOL*, PL/1*, Assembler etc.) stellt keine Ad-hoc-Anfragesprache dar für den „Endbenutzer“ (wie bei SQL der Fall)! • Aufrufe aus Datenbank-Verwaltungssystem im Programm wie „normale“ Unterprogramm-/Prozeduraufrufe geschrieben (Compiler der Programmiersprache braucht für IMS-Datenbankanschluss somit nicht erweitert werden) auch kein Pre-Compiler (Vorübersetzer) nötig im Gegensatz zu anderen Einbettungsvarianten, die wir später kennen lernen werden. * als die „klassischen“ Programmiersprachen in vielen betriebswirtschaftlichen Anwendungen Datenbanksysteme 1 03.12.2012 140 Kommunikationsstruktur Anwendung-IMS Anwendung(z.B. in PL/1 programmiert oder COBOL ...) hier „PL/1 to DL/1“ ... CALL PL1TDL1 (parameterliste) ... IMS (DatenbankVerwaltungssystem) 2 6 1 5 3 4 IMS-Anschlussmodul Betriebssystemprozess i Betriebssystemprozess j Client-Server-Architektur Abläufe: Wir betrachten als Bsp. eine Datenbankanfrage (lesender Zugriff, Query). Die oben skizzierten Abläufe sind weitgehend unabhängig von der konkreten DBVS-Technologie, gelten also i.w. gleichermaßen bei hierarchischen, netzwerkorientierten, relationalen Datenbanksystemen. Datenbanksysteme 1 03.12.2012 141 1 2 3 4 5 6 Anwendung ruft Anschlussmodul mittels, Unterprogramm-/Prozeduraufruf und übergibt Datenbankanfrage in Parameterliste* Anschlussmodell reicht Datenbankanfrage aus DatenbankVerwaltungssystem weiter (per Interprozess-Kommunikation); Anwendung wird „schlafen gelegt“ (wartet auf Anfrageergebnis) Datenbank-Verwaltungssystem bearbeitet Anfrage und stellt Ergebnis (Treffer, Fehlermeldung (Return Code)) bereit Ergebnis wird per Interprozess-Kommunikation zum Anschlussmodul zurückgereicht; Anschlussmodul/Anwendung wird dadurch wieder „aufgeweckt“ Kontrolle wird aus Anwendungsprogramm hinter Anrufstelle zurückgegeben Anwendungsprogramm analysiert Return Code und greift, falls Datenbankanfrage erfolgreich verlaufen, auf Treffer (gelesenes Datenelement) zu * hier liegen Unterschiede zum Ablauf bei relat./netzwerkor. DBVSen Datenbanksysteme 1 03.12.2012 142 DL/1-Operationsvorrat (Auswahl, Überblick) Op-Code • GET UNIQUE (GU): Direktes Positionieren auf eine bestimmte Segment-Ausprägung (record) und Lesen dieser Segment-Ausprägung; Einstieg erfolgt „von außen“ mittels Prädikat (hier. Pfad beachten!!) • GET NEXT (GN): Zugriff auf nächste Segment-Ausprägung (Positionieren, Lesen) ausgehend von aktueller Position; in PräOrder Reihenfolge (sequentiell) • GET NEXT WITHIN PARENT (GNP): wie bei GET NEXT, aber nur X typisch!! innerhalb der aktuellen Vater-Segment-Ausprägung • GET HOLD (GHU, GHN, GHNP): wie bei GU/GN/GNP, aber die Segment-Ausprägung, auf die positioniert wurde, kann anschließend geändert werden (DLET/REPL s.u.) • INSERT (INSRT): Einfügen einer neuen Segment-Ausprägung bei „one record vollständig spezifiziertem zugehörigem hierarchischen Pfad (Vaterat a time“ Semantik Segment-Ausprägung, Großvater- ...) • DELETE (DLET): Löschen einer Segment-Ausprägung, die zuvor mittels mengenorientiert GET HOLD fixiert wurde, sowie aller Kinder, Kindeskinder ... • REPLACE (REPL): Ändern ..., die zuvor mittels GET HOLD ... Datenbanksysteme 1 03.12.2012 143 Zusammenfassung / ´Hilites´ zu Kap. 3 • Hierarchisches Datenbankmodell als eine Möglichkeit der „Zielplattform“ bei der Umsetzung von (konzeptuellem) Datenmodell (etwa: E/R-Diagramm) in Datenbankmodell • Historisch erstes (sehr bekanntes, verbreitetes) Datenbankmodell, Realisierung so nur in DBMS IMS (IBM), heute noch große Marktbedeutung(aber insgesamt doch abnehmend), Großrechnerwelt/Mainframes • Datendarstellung prinzipiell in Typ-Hierarchien (sog. IMS-Datenbanken) Bäume, Wald • Nur mit Klimmzügen Darstellung nichthierarchischer Sachverhalte (vernetzter Strukturen) • Datenmanipulation (lesen, einfügen, ändern, löschen) nur via in Programmiersprache eingebettete Datenbanksprachanweisungen (Datenbanksprache DL/1) • Einbettung via Unterprogrammaufrufe (Prozeduraufrufe ans DBMS: Call Level Interface (CLI)), insb. keine Pre-compilation. kein Ad-hoc-Zugriff zur Datenbank! • Verarbeitungslogik unter Berücksichtigung der hier. Strukturen (des Waldes): navigierend, satzorientiert („one record at a time“). Typisch: Get Next, Get Next within Parent Datenbanksysteme 1 03.12.2012 144 • Trennung zwischen den drei Ebenen (konzept., externe, interne) teils vorhanden – DBD vs. PCB/PSB*-aber nicht konsequent (Aspekte der internen und der konzept. Ebene in DBD vermischt) • Mangel an Datenunabhängigkeit. Bsp.: Änderung an Sortierordnung der Daten (SEQ) „schlägt durch“ in Anwendung • „Programmer as Navigator“(obwohl diese Charakterisierung speziell auf NetzwerkAnsatz (Kap. 4) ausgerichtet ist) • Vergleichsweise niedrige, wenig benutzerfreundliche DB-Schnittstelle (nicht nahe am Endbenutzer)! * dürftig (nicht werteabhängige externe „Sichten“) Warum wird dieses „komische“Datenbankmodell heute noch verwendet? 1. Vorhandene, sehr große Anwendungen in der Praxis, die das hier. DM (IMS) nutzen. Mit IMS wird nach wie vor sehr viel Geld verdient. 2. Performance-Argument: Niedrige DB-Schnittstelle (einfache Operationen) erlaubt u.U. hoch effiziente Anwendungen durch Navigation „zu Fuß“ beim erfahrenen IMSAnwender Datenbanksysteme 1 03.12.2012 145
