Vorlesung DBMS - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

Vorlesung DBMS

Description:

Title: Seminar RObotik WS02/03 Subject: Thema Author: Autor Keywords: Seminar Robotik WS02/03 Last modified by: Michael Created Date: 5/21/2002 1:06:02 PM – PowerPoint PPT presentation

Number of Views:124
Avg rating:3.0/5.0
Slides: 39
Provided by: Auto83
Category:

less

Transcript and Presenter's Notes

Title: Vorlesung DBMS


1
Vorlesung DBMS
  • Thema Datenbanktechnologie
  • - Von der Realwelt zur Datenbank -
  • Michael Andriczka
  • Sommersemester 2003

2
Inhalt
  • Einleitung
  • 1.1 Charakteristika
  • 1.2 Vergleich Datenredundanz vs. Datenintegrität
  • 1.3 Prinzipien
  • 1.4 Eigenschaften aktueller DBS
  • 1.5 Einige konkrete Systeme
  • 1.6 Datenbankgrößen
  • 1.7 Gegenwärtiger Entwicklungsstand
  • Von der Realwelt zum ER-Modell
  • 2.1 Die sogenannte Miniwelt (1)
  • 2.2 Entität
  • 2.3 Attribute
  • 2.4 Schlüssel
  • 2.5 Beziehungen
  • 2.6 Die sogenannte Miniwelt (2)

3
Inhalt
  • 3. Vom Modell zur Datenbank
  • 3.1 Umsetzung des ER-Modells in das relationale
    Datenbankschema
  • 3.2 Normalisierung
  • 4. Schlussbetrachtung

4
1. Einleitung
  • 1.1 Charakteristika von Datenbanken
  • Eine Datenbank hat die langfristige Aufbewahrung
  • von Daten als Aufgabe
  • Die Sicherheit vor Verlusten ist eine
    Hauptmotivation,
  • etwas auf die Bank zu bringen.
  • Eine Bank bietet Dienstleistungen für mehrere
    Kunden
  • an, um effizient arbeiten zu können.

5
1. Einleitung
  • 1.2 Datenredundanz vs. Datenintegration
  • Ohne Datenbanken Datenredundanz
  • Basis- oder Anwendungssoftware verwaltet ihre
    eigenen
  • Daten in ihren (eigenen) Dateiformaten
  • - Textverarbeitung Texte, Artikel und Adressen
  • - Buchhaltung Artikel, Adressen
  • - Lagerverwaltung Artikel, Aufträge
  • - Auftragsverwaltung Aufträge, Artikel,
    Adressen
  • - CAD-System Artikel, Technische Bausteine
  • Daten sind redundant mehrfach gespeichert
  • Probleme Verschwendung von Speicherplatz,
  • Vergessen von Änderungen keine zentrale,
  • genormte Datenhaltung

6
1. Einleitung
  • Mehrere Benutzer oder Anwendungen können nicht
    parallel
  • auf den gleichen Daten arbeiten, ohne sich zu
    stören
  • Anwendungsprogrammierer/Benutzer können
    Anwendungen nicht programmieren/benutzen, ohne
  • - interne Darstellung der Daten
  • - Speichermedien oder Rechner
  • zu kennen (Datenunabhängigkeit nicht
    gewährleistet)
  • Datenschutz und Sicherheit sind nicht
    gewährleistet

7
1. Einleitung
  • 1.2 Datenredundanz vs. Datenintegration
  • Mit Datenbanken Datenintegration
  • Die gesamte Basis- und Anwendungssoftware
    arbeitet auf
  • den selben Daten, z.B. Adressen und Artikel
    werden nur einmal gespeichert
  • - Datenbanksysteme können große Mengen an Daten
  • effizient verwalten (Anfragesprachen)
  • - Benutzer können parallel auf Datenbanken
    arbeiten
  • (Transaktionskonzept)
  • - Datenschutz (kein unbefugter Zugriff) und
    Datensicherheit
  • (kein ungewollter Datenverlust) werden vom
    System
  • gewährleistet

8
1. Einleitung
1.3 Prinzipien Datenbank-Management-System Unter
einem Datenbank-Management-System (DBMS) versteht
man ein Softwarepaket, welches in der Lage ist,
(Anwender-) Daten in einem Computersystem zu
verwalten. Spricht man von einem relationalen
Datenbank-Management-System, meint man damit,
dass dieses DBMS für die Verwaltung der Daten
intern eine bestimmte Technologie benutzt und
dass es bestimmten Anforderungen
genügt. Datenbank-System Unter einem
Datenbank-System versteht man ein DBMS mit
zusätzlich einer oder mehreren Datenbanken zur
Sammlung von nicht redundanten Daten, die von
mehreren Applikationen benutzt werden.
9
1. Einleitung
DB Strukturierter, von DBMS verwalteter
Datenbestand DBS Datenbanksystem (DBMS
Datenbank) DBMS Datenbank-Management-System
10
1. Einleitung
  • Grundmerkmale von DBMS
  • - verwalten persistente (langfristig zu
    haltende) Daten
  • - verwalten große Datenmengen effizient
  • - Datenmodell, mit dessen Konzepten alle Daten
    einheitlich
  • beschrieben werden (Integration)
  • - Transaktionskonzept
  • - Datenschutz, Datenintegrität (Konsistenz),
    Datensicherheit
  • Grundprinzip moderner DBS
  • - 3-Ebenen-Architektur
  • - Trennung zwischen Schema (Tabellenstruktur)
  • und Instanz (etwa Tabelleninhalt)

11
1. Einleitung
  • 1.4 Eigenschaften aktueller Datenbanksysteme
  • 3-Ebenen-Architektur nach ANSI-SPARC
  • Externe Ebene (Benutzersichten)
  • Konzeptionelle Ebene (Logische Gesamtsicht)
  • Interne Ebene (Physische Schicht)
  • Einheitliche Datenbankanfragesprache SQL
  • Einbettung dieser Sprache in kommerzielle
    Programmier-
  • sprachen
  • Diverse Werkzeuge für die Definition, Anfrage und
    Darstellung von Daten und den Entwurf von
    Datenbankanwendungsprogrammen und der
    Benutzer-Interaktion, sowie
  • Kontrollierter Mehrbenutzerbetrieb,
    Zugriffskontrolle und Datensicherheitsmechanismen

12
1. Einleitung
  • 1.5 Einige konkrete Systeme
  • (Objekt-)Relationale DBMS
  • - Oracle 9i, DB2 V.8, Microsoft SQL-Server 2000
  • - MySQL, PostgreSQL, FireBird
  • Pseudo DBMS
  • - MS Access
  • Objektorientierte DBMS
  • - Poet, Versant, ObjectStore
  • XML-DBMS
  • - Tamino, eXcelon

13
1. Einleitung
  • 1.6 Datenbankgrößen
  • Slolan Digital Sky Survey 40 TB
  • Himmelsdaten (Bilder und Objektinformationen)
  • WalMart Data WareHouse 24 TB
  • Produktinfos (Verkäufe, etc.) von 2900 Märkten
  • 50.000 Anfragen pro Wochen
  • US Libary of Congress 10-20 TB
  • nicht digitalisiert
  • Indexierbares WWW (1999) 6 TB
  • ca. 800 Millionen Dokumente
  • Microsofts TerraServer 3,5 TB
  • unkomprimierte Bilder und Daten (komprimiert
    ca. 1 TB)

14
1. Einleitung
  • SAP R/3-Installation der Deutschen Telekom AG
    (1998)
  • Financial Accounting Rechnungen, Lastschriften
  • Zahlungsaufforderung, Mahnungen, etc.
  • 15 SAP R/3-Systeme jedes
  • - verarbeitet 200.000 Rechnungen, 12.000
    Mahnungen,
  • 10.000 Änderungen von Kundendaten pro Tag
  • - bis zu jeweils 1000 Nutzer gleichzeitig
  • Ãœber 13.000 Datenbanktabellen

15
1. Einleitung
  • 1.7 Gegenwärtiger Entwicklungsstand
  • Unterstützung für spezielle Anwendungen
  • - Multimedia-Datenbanken Verwaltung
    multimedialer
  • Objekte (Bilder, Audio, Video)
  • - XML-Datenbanken Verwalten semistrukturierter
    Daten
  • - Verteilte Datenbanken Verteilung von Daten
    auf
  • verschiedenen Rechnerknoten
  • - Förderierte Datenbanken Multimedia-Datenbanken
  • - Mobile Datenbanken Datenverwaltung auf
    Kleinstgeräten
  • (PDA, Handy)

16
2. Von der Realwelt zum ER-Modell
2.1 Die sogenannte Miniwelt (1) Um zu einem
geeigneten Modell zu gelangen, muss zunächst
durch eine Analyse der realen Welt ein zu
modellierender Teilausschnitt dieser realen Welt
definiert werden. Diesen Teilausschnitt nennt man
auch Miniwelt. Beispiel Die Firma Mustermann
handelt mit PCs und Zubehör. Aus dem
Produktkatalog der Firma Mustermann können
Kunden per Telefon oder per Bestellkarte ein
oder mehrere Artikel zur Bestellung
aufgeben. Aufgrund der enormen Nachfrage nach PCs
und Zubehör kann das Geschäftsaufkommen
mittlerweile nicht mehr über Karteikarten
abgewickelt werden. Somit entschließt man sich
zur Einführung eines relationalen DBS und der
dazu gehörigen Anwendungsprogramme. Beim
Betrachten dieser Miniwelt erkennt man gewisse
Objekte (sog. Entities) wie Artikelnamen,
Kundennamen, Bestellungen usw. Zwischen diesen
Objekten existieren Beziehungen (sog.
Relationships), die bestimmte Abläufe oder
Abhängigkeiten in der Miniwelt darstellen.
17
2. Von der Realwelt zum ER-Modell
  • Um zu einem Datenmodell zu gelangen, fasst man
    gleichartige Objekte und
  • gleichartige Beziehungen zu Klassen zusammen.
    Somit ergeben sich
  • Objekttypen wie Artikel, Bestellung, Kunden und
  • Beziehungstypen wie Bestellposition, welche die
    Objekte in eine
  • gewisse Beziehung bringen.
  • Jedem Objekttyp oder Beziehungstyp sind gewisse
    Eigenschaften zu-
  • geordnet, wie z.B. dem Objekttyp Artikel die
    Eigenschaften Bezeichnung und
  • Preis. Man nennt diese Eigenschaften eines
    Objekttyps oder Beziehungstyps
  • auch Attribute.
  • Zur Darstellung von Objekten (Entities) und vor
    allem der Beziehungen
  • zwischen den Objekten dienen die sogenannten
    ER-Diagramme.

18
2. Von der Realwelt zum ER-Modell
  • 2.2 Entität
  • Ausgangspunkt des ER-Modells ist der Begriff der
    Entität. Eine Entität ist
  • ein individuelles und identifizierbares Exemplar
    von Dingen, Personen oder
  • Begriffen der realen oder der Vorstellungswelt.
    Die Entität wird durch
  • Attribute näher beschrieben.
  • Die Entitätsmenge (auch Entitytyp genannt) wird
    im ER-Modell durch ein
  • Rechteck dargestellt. In dem Rechteck steht der
    Name der Entität. Der
  • Name beschreibt die Entitätsmenge und steht im
    Singular.
  • Die Entität (Entity) ist also das konkrete,
    individuell identifizierbare Objekt
  • bzw. Exemplar von Dingen, Personen oder Begriffen
    der realen oder
  • der Vorstellungswelt.

KUNDE
19
2. Von der Realwelt zum ER-Modell
  • Beispiele
  • Individuen Mitarbeiterin Brecht, Student Weber,
    Kunde Meier
  • Reales Objekt Maschine 2, Raum 7, Artikel
    4711....
  • Ereignis Zahlung, Buchung, Mahnung, Start,
    Landung.....
  • Abstraktes Unterricht, Dienstleistung,
    Verarbeitungsart, Zahlungsart....
  •  
  • Der Kunde Meier ist also ein konkretes
    individuell identifizierbares Objekt, über
  • den Informationen abgespeichert werden müssen. Er
    gehört zur Gruppe der
  • Kunden. Man kann auch sagen, er ist vom
    Entitätstyp Kunde. Alle
  • Informationen, die über Kunden abgespeichert
    werden, sind von der Struktur
  • her gleich.

20
2. Von der Realwelt zum ER-Modell
  • 2.3 Attribute
  • Attribute beschreiben die Entitäten.
  • Beispiel Kunde (KdNr, KName, KAdresse,...)
  •  
  • Man unterscheidet zwischen
  • identifizierenden Attributen, sog. Schlüssel
    (z.B. KdNr, FirmenNr, PersNr...)
  • beschreibenden Attributen (z.B. KName,
    MitarbeiterName, ArtikelBez, ... )

KdNr
KUNDE
KName
21
2. Von der Realwelt zum ER-Modell
  • 2.4 Schlüssel
  • Eine minimale Menge von Attributen, deren Werte
    das zugeordnete Entity
  • eindeutig innerhalb aller Entities seines Typs
    identifiziert. Man unterscheidet
  • Primärschlüssel und Fremdschlüssel.
  • 2.4.1 Primärschlüssel Der Primärschlüssel wird
    benötigt, um Datensätze
  • eindeutig zu identifizieren, also der Datensatz
    darf nicht doppelt (z.B. in
  • einer Tabelle) vorkommen.
  • Der Primärschlüssel ist in einem ER-Modell anhand
    des unterstrichenem
  • Attributes zu erkennen.
  • Die Merkmale eines Feldes mit Primärschlüssel
    sind
  • Der Inhalt eines Feldes ist eindeutig
  • In jedem Datensatz müssen Daten stehen
  • Ein Primärschlüssel kann sich auch aus mehreren
    Feldern zusammensetzen

22
2. Von der Realwelt zum ER-Modell
  • 2.4.2 Fremdschlüssel Der Fremdschlüssel ist ein
    Attributwert, der einen
  • Schlüsselwert in einer anderen Tabelle darstellt
    und somit als eindeutiger
  • Verweis auf einen Datensatz in einer anderen
    Tabelle zeigt. Dies wird
  • auch als referentielle Integrität benannt.
  • Beispiel Fremdschlüssel
  • Fremdschlüssel Primärschlüssel
  • Referentielle Integrität

KNr PNr Kurs BereichsNr
44 15 D 1
45 15 G 2
47 6 M 6
48 6 I 6
49 6 E 1
BereichsNr Bereich
1 Sprache
2 Geisteswissenschaften
6 Naturwissenschaften
23
2. Von der Realwelt zum ER-Modell
  • 2.5 Beziehungen
  • Die Wechselwirkungen und Abhängigkeiten zwischen
    Entitäten werden
  • durch Beziehungen (relationship) dargestellt. Die
  • Zusammenfassung gleichartiger Beziehungen
    zwischen Entitäten
  • erfolgt durch Beziehungsmengen.
  •  
  • Eine Beziehung wird nach Chen graphisch durch
    eine Raute
  • dargestellt. In ihr steht der Name der Beziehung.
    Als Name sollte ein
  • Verb gewählt werden.

gibt auf
24
2. Von der Realwelt zum ER-Modell
  • Die Beziehung wird durch eine Verbindungslinie,
    zwischen der die
  • Raute steht, dargestellt.
  • Zwischen den Entitätstypen KUNDE und BESTELLUNG
    besteht ein
  • Beziehungstyp gibt auf. Wenn es einen solchen
    Beziehungstyp gibt,
  • so kann (muss) eine konkrete Beziehung zwischen
    einem Paar der
  • dazu gehörenden Entitäten bestehen
  • 1 n
  • Man liest KUNDE gibt auf Bestellungen bzw.
    Bestellungen werden
  • aufgegeben von Kunde.

gibt auf
KUNDE
BESTELLUNG
25
2. Von der Realwelt zum ER-Modell
2.6 Die sogenannte Miniwelt (2) Drei der
wichtigsten Objekttypen aus der Miniwelt der
Firma Mustermann werden nun mit den dazugehörigen
Attributen als Datenmodell dienen. Es handelt
sich hierbei um die Objekte Kunden alle
Kunden, die Bestellungen aufgeben Bestellung die
offenen Bestellungen der Kunden Artikel alle
lieferbaren Artikel
26
2. Von der Realwelt zum ER-Modell
ER-Modell
KUNDE
KName
KdNr
1
gibt auf
n
BestellNr
BESTELLUNG
Datum
n
Bestellposition
Menge
Bez
n
ARTIKEL
ArtikelNr
Preis
27
3. Vom Modell zur Datenbank
  • 3.1 Umsetzung des ER-Modells in das relationale
    Datenmodell
  • Das ER-Modell besitzt zwei grundlegende
    Strukturierungskonzepte
  • Entitytypen und
  • Beziehungstypen
  • Dem steht im relationalen Modell nur ein einziges
    Strukturierungskonzept
  • nämlich die Relation gegenüber. Also werden
    sowohl Entitytypen als auch
  • Beziehungstypen jeweils auf eine Relation
    (Tabelle) abgebildet.
  • Zu den Entitytypen als auch zu den
    Beziehungstypen aus dem vorherigen
  • ER-Modell werden nun Relationen gebildet.
  • Hierbei werden die Spalten als Attribute (Felder)
    bezeichnet. Die Attribute
  • müssen innerhalb einer Relation eindeutig benannt
    sein.
  • Die Zeilen der Tabelle entsprechen den Tupeln der
    Relation.

28
3. Vom Modell zur Datenbank
  • KUNDE KdNr, KName
  • BESTELLUNG BestellNr, Datum, KdNr
  • BESTELLPOSITION BestellNr, ArtikelNr, Menge
  • ARTIKEL ArtikelNr, Bez, Preis
  • ER-Modell Relationales Modell
  • Entity Objekt Relation zweidimensionale
  • Relationship Beziehung Tabelle
  • Entität Schlüsselattribut Schlüsselattribut
    Entität

KdNr
KUNDE KUNDE
KdNr KName
001112 Meier
001535 Schulz
KUNDE
KName
29
3. Vom Modell zur Datenbank
  • 3.2 Normalisierung
  • Unter Normalisierung versteht man das Aufteilen
    der Daten in Relationen
  • in der Art und Weise, dass sie am Ende den
    Normalisierungsregeln
  • entsprechen.
  • Normalisierungsgründe
  • Minimierung redundanter Daten
  • Vermeidung von Änderungsanomalien
  • Reduzierung inkonsistenter Daten
  • Entwerfen von Datenstrukturen, die eine einfache
    Pflege erlauben

30
3. Vom Modell zur Datenbank
  • 3.2.1 0.Normalform
  • Die Normalformenlehre von Codd besagt, dass sich
    eine Relation nur dann
  • in der ersten Normalform befindet, wenn der
    Wertebereich der Attribute
  • elementar ist.

PNr Vorname Name Straße PLZ Wohnort KNr Kurs
15 Hugo Meier Schulstr.1 10124 Berlin 44, 45 D, G
6 Detlef Euler Maiweg 5 54294 Trier 47, 48, 49 M, I, E
31
3. Vom Modell zur Datenbank
  • 3.2.2 1.Normalform
  • Eine Relation ist in der ersten Normalform, wenn
    alle Attribute nur atomare
  • Werte beinhalten.
  • Eindeutige Identifikation durch
    Primärschlüssel Redundanzfreiheit
  • Da hier Anomalien in der 1NF auftreten können,
    ist es sinnvoll, die Relation
  • in die 2NF zu überführen.

PNr Vorname Name Straße PLZ Wohnort KNr Kurs
15 Hugo Meier Schulstr.1 10124 Berlin 44 D
15 Hugo Meier Schulstr.1 10124 Berlin 45 G
6 Detlef Euler Maiweg 5 54294 Trier 47 M
6 Detlef Euler Maiweg 5 54294 Trier 48 I
6 Detlef Euler Maiweg 5 54294 Trier 49 E
32
3. Vom Modell zur Datenbank
  • 3.2.3 2.Normalform
  • Eine Relation ist in der zweiten Normalform, wenn
    sie sich in der ersten
  • Normalform befindet und jedes Nicht-Schlüssel-Attr
    ibut funktional vom
  • Gesamtschlüssel abhängig ist, nicht aber von
    einzelnen Schlüsselteilen.
  • Vermeidung der Anomalien der 1NF durch Aufteilung
    der Entitäten in
  • seperate Tabellen.

PNr Vorname Name Straße PLZ Wohnort KNr Kurs Bereich
15 Hugo Meier Schulstr.1 10124 Berlin 44 D Sprache
15 Hugo Meier Schulstr.1 10124 Berlin 45 G Geisteswissenschaften
6 Detlef Euler Maiweg 5 54294 Trier 47 M Naturwissenschaften
6 Detlef Euler Maiweg 5 54294 Trier 48 I Naturwissenschaften
6 Detlef Euler Maiweg 5 54294 Trier 49 E Sprache
33
3. Vom Modell zur Datenbank
  • Tabelle Lehrer
  • Wie man sieht, entfallen somit die Zeilen mit
    unterschiedlichen Kursen
  • derselben Lehrer. Die Kurse wurden in eine andere
    Tabelle ausgelagert, da
  • sie nicht voll funktional von dem
    Schlüsselattribut PNR abhängen.
  • Tabelle Kurse

PNr Vorname Name Straße PLZ Wohnort
15 Hugo Meier Schulstr.1 10124 Berlin
6 Detlef Euler Maiweg 5 54294 Trier
KNr Kurs Bereich
44 D Sprache
45 G Geisteswissenschaften
47 M Naturwissenschaften
48 I Naturwissenschaften
49 E Sprache
34
3. Vom Modell zur Datenbank
  • Mit den Tabellen Lehrer und Kurse besitzt man nun
    zwei Tabellen, die
  • nichts miteinander zu tun haben und somit nicht
    mehr den Zustand der
  • 1NF genügen. Es muss also eine Tabelle geschaffen
    werden, die beide
  • Tabellen verbindet, jedoch die Redundanzen der
    Tabelle in der 1NF
  • vermeidet.
  • PNr wurde zur Herstellung der referentiellen
    Integrität als Fremdschlüssel
  • in die Tabelle Kurse eingefügt.

KNr Kurs Bereich PNr
44 D Sprache 15
45 G Geisteswissenschaften 15
47 M Naturwissenschaften 6
48 I Naturwissenschaften 6
49 E Sprache 6
35
3. Vom Modell zur Datenbank
  • 3.2.4 3.Normalform
  • Beim Betrachten der Tabelle Kurse in der 2NF
    treten folgende Anomalien auf
  • Bereichsnummer hat mehrmals den selben Wert,
    während sich der Wert des Primärschlüssels ändert
  • Bereichsnamen treten mehrfach auf und müssten
    Änderungen in mehreren Datensätzen geändert
    werden
  • transitive Abhängigkeit
  • Transitive Abhängigkeit Abhängigkeit zwischen
    nicht Schlüsselattributen

KNr PNr Kurs Bereich BereichsNr
44 15 D Sprache 1
45 15 G Geisteswissenschaften 2
47 6 M Naturwissenschaften 6
48 6 I Naturwissenschaften 6
49 6 E Sprache 1
36
3. Vom Modell zur Datenbank
  • Codd erkannte das Problem oder möglichen
    Schwachpunkt der 2NF
  • und entwickelte die 3NF.
  • Eine Relation ist in der dritten Normalform, wenn
    sie sich in der ersten
  • und in der zweiten Normalform befindet. Ferner
    sind keine funktionalen
  • Abhängigkeiten zwischen Attributen erlaubt, die
    nicht als Schlüssel
  • definiert sind.

KNr PNr Kurs BereichsNr
44 15 D 1
45 15 G 2
47 6 M 6
48 6 I 6
49 6 E 1
BereichsNr Bereich
1 Sprache
2 Geisteswissenschaften
6 Naturwissenschaften
37
3. Vom Modell zur Datenbank
  • 3.2.5 Normalisierte Tabellen
  • Tabelle Lehrer
  • Tabelle Kurse
  • Tabelle Bereich

PNr Vorname Name Straße PLZ Wohnort
15 Hugo Meier Schulstr.1 10124 Berlin
6 Detlef Euler Maiweg 5 54294 Trier
KNr PNr Kurs BereichsNr
44 15 D 1
45 15 G 2
47 6 M 6
48 6 I 6
49 6 E 1
BereichsNr Bereich
1 Sprache
2 Geisteswissenschaften
6 Naturwissenschaften
38
4. Schlussbetrachtung
  • Jede in der Datenbank gespeicherte Information
    wird in solchen
  • einfachen Tabellen festgehalten. Eine Tabelle
    hat immer einen fest
  • strukturierten Aufbau aus Zeilen (Tupeln) und
    Spalten (Attributen), der
  • einmalig beim Anlegen der Tabelle definiert wird
    und sich während der
  • gesamten Lebensdauer der Tabelle nur mittels
    DDL-Befehlen ändern
  • kann.
  • Zur Kommunikation mit dem DBMS wird dem
    Endbenutzer in der Regel
  • ein Programm zur Verfügung gestellt, welches mit
    dem DBS
  • kommuniziert. Dieses Anwendungsprogramm bildet
    die Schnittstelle
  • zwischen dem Benutzer und dem DBMS.
Write a Comment
User Comments (0)
About PowerShow.com