Datenbankeinführung - Beuth Hochschule für Technik Berlin

Einführung in Datenbanksysteme
EINFÜHRUNG IN DATENBANKSYSTEME
F. Steyer
Einsatz, Nutzen von Datenbanksystemen
Entwicklung von Datenbanksystemen
Entwicklung von relationalen Datenbanksystemen
Architektur eines Datenbanksystems
Architektur eines Anwendungsystems
Architektur eines Datenbanksystems im Client/Server-Verbund
Architektur eines Anwendungsystems im Rechnernetz
Architektur eines Anwendungsystems lokal und im Internet
Bereiche
Benutzungsbereich
Operationsbereich
Datenbereich
Technikbereich
Sonstiges
Datenunabhängigkeit, Datenintegrität
Dateien
Datenbanklebenszyklus
Big Data
Daten in der Cloud
Datenbankliteratur
19.11.2015
Fehler und Wünsche bitte an den Autor.
BEUTH/Steyer
Einführung in Datenbanksysteme
Einsatz, Nutzen von Datenbanksystemen
Technische Argumente
-
Permanente Datenhaltung
-
Integrierte Datenhaltung
-
Standardisierung (Daten/Funktionen/Schnittstellen/Architektur)
-
Endbenutzerwerkzeuge und Anwendungsgeneratoren
-
Prototyping von Anwendungen
Betriebswirtschaftliche Argumente
-
Erhöhung der Produktivität in der Entwicklung von Anwendungssoftware
-
Verbesserung der Qualität der Anwendungssoftware
-
Effizientere und flexiblere Wartung der Anwendungssoftware
-
Datenaustausch
Einsatzgebiete von Anwendungen
-
Es gibt zwei Benutzungsarten von Datenbanksystemen
DB als genaues Abbild der Wirklichkeit (Modell, OLTP)
DB als Datenspeicher (Archiv, OLAP)
-
breites Spektrum kommerzieller Anwendungen
(Banken, Versicherungen, Kommunalverwaltungen)
-
zunehmende Akzeptanz in technischen Anwendungen
(Buchungssysteme, Leitsysteme, Lagerverwaltung, CIM, FM)
-
Zentrale Rolle bei der Bürointegration
(Text- und Dokumentenverwaltung, DTP)
-
Neue Einsatzgebiete bei Software Engineering
-
Künstliche Intelligenz und CAD
BEUTH/Steyer
Einführung in Datenbanksysteme
Entwicklung von Datenbanksystemen
JAHR
TECHNIK
EIGENSCHAFTEN
konventionelle
Dateiverarbeitung
starre Satzstruktur
pro Satz ein Schlüssel
Vorläufer
bis 1968
Vorläufer bei den Datenmodellen
1968-1975 erste DBS verschiedener Struktur:
(Bäume, Netze)
batchorientierte DBS
wenige Benutzerhilfen
nur für Grossrechner
Codasyl-Normung
1975-1980
verbesserte Netzwerkmodelle
erste relationale
Systeme
dialogorientierte DBS
Mehrbenutzerfähigkeit
DBS für Minis
ANSI/SPARC-Norm
Relationale Systeme
1980-1985
verbesserte relationale Systeme
Erweiterung der Toolumgebung von DBS
portable DBS
Data Dictionary Systeme
SQL-Normung
DBMS für Micros und PCs
Endbenutzerunterstützung
ausfallsichere DBVS
Datenbankmaschinen
Weiterentwicklungen
1985-heute verteilte DBS
objektorientierte DBS
Non-Standard-DBMS
1990-heute Datenbankmaschinen
getrennt von den
Datenbankoberflächen
Datenbank im Internet
BEUTH/Steyer
neue Anwendungsgebiete,
z.B. SW-Entwicklung,
Büroautomation,CAD/CAM/CIM
Kombinierbarkeit von
Datenbankmaschinen und
-oberflächen verschiedener
Hersteller über eine
Standardschnittstelle ODBC
Einführung in Datenbanksysteme
Entwicklung der relationalen Datenbanksysteme
Theorie/Forschung
1970
E.F. Codd bei IBM San Jose
'A Relational Model of Data for Large Shared Data Banks',
wird veröffentlicht (Comm. ACM, 13/6, June 1970)
1974
D.O. Chamberlin et al. bei IBM San Jose,
'Structured Query Language (SEQUEL)'
1977
Forschungssystem System R lauffähig
ORACLE von Relational Software Inc.
Erste Produkte
1981
SQL/DS und DB2 von IBM
1985
SQL-Schnittstelle für Ingres von Relational Technology Inc. und IDM von Britton Lee Inc.
1986
SYBASE von Sybase Inc.
Normierung
1986
American National Standards Institute (ANSI)
International Standards Organization (ISO) und Deutsche Industrie Norm (DIN) übernehmen SQL
Anwendungen
Vielzahl an DB-Softwareprodukten mit SQL-Schnittstelle, z.B. Oracle
Einschätzung
Internationale Standardisierungen durch ANSI, ISO, DIN, X/OPEN
Industriestandardisierung durch Software-Produkte wie DB2, Oracle, MS SQL Server
SQL als Datenbankstandard wird die nächsten Jahre dominieren, Nachfolgesysteme werden wenigstens
SQL beherrschen (Aufwärtskompatibilität).
Die Anwendungsprogrammierung wurde durch die ODBC-Normierung stark vereinfacht.
Anwender wollen ihre Investitionen schützen bzgl. Anwendungssoftware, Schulung und Personalmarkt.
SQL verschwindet aber zunehmend in der Tiefe der Systeme (im DB-Server, unter Window-Oberflächen),
hat sich aber als funktionaler DB-Standard für Programmierer und Toolentwickler etabliert.
BEUTH/Steyer
Einführung in Datenbanksysteme
Architektur eines Datenbanksystems
Dialog
Anwendungsprogramme
Dienstprogramme
XML
Netzserverfähigkeit
Mehrbenutzerfähigkeit
Zugriffsschutz
Transaktionsschutz
Leistung
Speicherfunktionen
Benutzerdaten
Data Dictionary
Logdaten
BEUTH/Steyer
ODBC
Internet
Einführung in Datenbanksysteme
Architektur eines Anwendungssystems
Oberfläche
Anwendungsprogramm
Datenverwaltung
BEUTH/Steyer
Einführung in Datenbanksysteme
Datenbanken im Client/Server-Verbund
mit Frontend- und Backend-Systemen
Backend-DBS: z.B. SQL Server Fertige Tools
(z.B. Enterprise Manager,
Query Analyser, bcp)
Programme (z.B. VB, Java)
Frontend-DBS
Access
Internet
BEUTH/Steyer
Einführung in Datenbanksysteme
Datenbanksysteme im Rechnernetz
am Anfang: monolithisches System
bald: Client-Server-System (n Clients, 1 Server)
heute : Service-orientierte Architektur (n Clients, m Servers)
BEUTH/Steyer
Einführung in Datenbanksysteme
SW-Architektur mit Datenbank lokal
Oberfläche
Programme
Datenbank
SW-Architektur mit Datenbank im Internet
Browser
BEUTH/Steyer
Server
Einführung in Datenbanksysteme
Benutzungsbereich: Benutzertypen
Ein Benutzer ist jeder, der etwas mit der Datenbank zu tun hat: Endbenutzer, Entwickler, Administrator
traditionell drei Gruppen:
Endbenutzer: gelegentlich, einfache Oberfläche, kleinere Aufgaben
Anwendungsentwickler: Entwicklung von Anwendngssystemen
Administratoren: systemnahe oder anwendungsnahe Verwalter, Operatoren
SQL-artig (Oracle)
- create user, change user, drop user
- grant { connect | resource | dba } to meier identified by z97d
- grant select on person to meier
Ablauf: - Superuser wird bei Installation festgelegt.
- Superuser legt Datenbankadministratoren an.
- Jeder Datenbankadministrator legt seine Mitarbeiter-User an (resource, connect).
(2) Windows like (Access) visuell mit Menü, Tabelle, Ankreuzen:
->Menü->Zugriffsrechte->neu: Name, Passwort, Gruppe
->Menü->Zugriffsrechte->Gruppe: neu
->Menü->Zugriffsrechte->Berechtigungen
Die Benutzer eines Datenbanksystems befinden sich in dem Bereich zwischen EDV-Abteilung und
Anwender-/Fachabteilung. Sie unterscheiden sich nach Breite und Tiefe.
EDV-Abteilung
Fachabteilung
Endbenutzer
(Betriebsphase)
Benutzerservice
(Betriebsphase)
Anwendungsprogrammierer
(Einführungsphase, Betriebsphase, Änderungsphase)
Systemanalytiker
(Planungsphase)
Datenbankadministrator
(Einführungsphase, Betriebsphase, Änderungsphase)
DB-Operating
(Betriebsphase)
BEUTH/Steyer
Einführung in Datenbanksysteme
Benutzungsbereich: Benutzersicht (VIEW)
Es soll jeder nur das sehen, was er braucht und darf.
Definition : benutzerdefiniertes Fenster, spaltenweise, zeilenweise, virtuell, joined
Zweck
: Datenschutz und Übersichtlichkeit
Realisierung: Speicherung der Definition, Und-Verknüpfung mit jedem Befehl, der den Benutzersichtnamen
verwendet
Probleme : kostet das System etwas Mehrarbeit, bringt manchmal kryptische Fehlermeldungen
Beispiel
fremdsprachige Benutzersicht
deutsche Basistabelle
Benutzungsbereich: Privilegien
Es darf nicht jeder alles überall sehen und tun.
Definition : permanente (längerdauernde) Zugriffskontrolle bzgl. - welche Aktion auf welchem Objekt wer
Zweck
: Zugriffsschutz, Datensicherheit
Realisierung
: Planung in der Zeit der Systemanalyse, Schulung
Privilegientabelle, die als Filter für jedes Kommando fungiert
Probleme : kleine Verzögerung immer
Die Oberflächen werden immer "höher", d.h. entfernen sich immer mehr vom DBMS. Die
Benutzer werden immer datenbankunausgebildeter. SQL verschwindet in den Tiefen der
Systeme, bleibt aber als funktionaler Standard erhalten.
meier
Tab1
form1
BEUTH/Steyer
Operationen (select, insert, update, delete, definieren, benutzen)
x
x
Einführung in Datenbanksysteme
Benutzungsbereich: Sperren
Es dürfen nicht alle alles gleichzeitig machen.
Es gibt zwei Arten: exclusive: verbietet anderen Lesen und Schreiben,
shared: erlaubt wenigstens paralleles Lesen
SQL-artig (Oracle, 1989) einzeln:
lock table person in share mode
lock row with pid = 4711 in person in exclusive mode
oder neuer (1992): isolation levels
0 read uncommitted (ungesperrt)
1 read committed (1 Zeile kurz gesperrt, Beispiel Umbuchung)
2 repeatable read (1 Zeile länger gesperrt, Beispiel Gehaltserhöhung)
3 cursor stability (Ergebnismenge gesperrt)
entscheidend sind also die Sperrbereiche und die Sperrdauer
Windows like (Access):
Beim Öffnen schon ist ankreuzbar: gemeinsam oder exklusiv. Sperrstrategie kann eingestellt werden:
Aber die Granularität ist grob.
Definition
Zweck
Realisierung
: temporäre (kürzerdauernde) Zugriffskontrolle
- "exclusive" verbietet anderen Lesen und Schreiben
- "shared" erlaubt wenigstens paralleles Lesen
: operationale Datensicherheit
: Sperrliste, die als Filter für jedes Kommando fungiert
Probleme
: langes Warten evtl. oder gar Deadlock
BEUTH/Steyer
Einführung in Datenbanksysteme
Operationsbereich: Zugriffssprache
SQL – Vorläufer
Dateien und Programme
Bäume
Graphen
schliesslich
Tabellen
SQL – Generationen
ANSI oder ISO SQL (1983-1986)
DDL (CREATE SCHEMA, CREATE TABLE, CREATE VIEW, GRANT)
DML (DECLARE CURSOR, OPEN, FETCH, CLOSE, DELETE, UPDATE,
SELECT, INSERT, UPDATE, DELETE, COMMIT, ROLLBACK)
DModL (MODULE, PROCEDURE)
Cobol, Fortran, Pascal, PL/1
SQL/89
Integritätserweiterungen (DEFAULT, UNIQUE, NOT NULL,
CHECK, PRIMARY KEYS, referential integrity:u.a.
Ada, C, embedded SQL
SQL/92
Standardkataloge, neue Datentypen, mehr Orthogonalität,
neue Join-Typen, Isolation levels, Cursor,
dynamisches SQL, SQLSTATE
(in kleinerem Umfang z.Zt. existierender Standard)
SQL/99
Triggers, Call level interface, Prozedursprache, loop, for,
ADTs mit Funktionen, Dot Notation, ADT-Privilegien,
Roles, Typensystem, Zeilentypen, Client-Module, Server-Module,
Ausnahmebehandlung (undo, redo, continue), Savepoints, Rekursion,
Cursor-Erweiterungen, referentielle Integrität
Ergebnis: Tabellensprache
SQL = DDL union DML union DCL union ProzL
DDL =
{create database, drop database,
create table, drop table,
create view, drop view,
create index, drop index}
DML =
{insert, update, delete, select}
DCL =
{create user, drop user, grant, revoke}
ProzL =
{create trigger, drop trigger, create procedure, drop procedure,
execute}
BEUTH/Steyer
Einführung in Datenbanksysteme
Operationsbereich: SQL und Dialekte
IBM SQL
Oracle - SQL
SQL Kern
MS - SQL
BEUTH/Steyer
Einführung in Datenbanksysteme
Datenbereich: TABELLE, VIEW und materialisierte VIEW
(„OLAP“: online analytic processing)
Tabelle: Daten und Definition sind gespeichert
View: nur Definition ist gespeichert, Daten werden jedesmal aus der Tabelle geholt oder abgeleitet
Materialisierte View: Daten sind doch (in die Nähe) gespeichert.
Zweck: schnellerer Aufbau
SQL: statt CREATE VIEW ... nun CREATE TABLE … und INSERT SELECT …
Notwendig ist ein periodischer Update.
Realisierung einer Tabelle oft mit dynamischen Baumstrukturen.
Beispiel für das Verhältnis Tabelle – Views:
- Tabelle mit Daten liegt in der Zentrale
- Views mit besonderen Darstellungen liegen in den Filialen (englisch, französisch)
Datenbereich: INDEX
Umorganisierte Hilfsdatei zu einer Tabelle beschleunigt das Lesen.
Tabelle
Indexdatei
einfach zu finden
x
y
y
x
aufwendig zu finden
lesefreundlich, änderungsunfreundlich
SQL: CREATE INDEX <indexname> ON <tabellenname>(<tabellenspalte>)
Indexe über mehrere Tabellenspalten sind möglich.
BEUTH/Steyer
Einführung in Datenbanksysteme
Technikbereich: Transaktion
benutzerdefinierte Befehlsfolge, die ganz oder garnicht ausgeführt wird, auch wenns länger dauert
impliziter Beginn am Anfang der Sitzung
implizites Ende am Ende der Sitzung
dazwischen mit "commit" Ende und Anfang zugleich (früher mal begin transaction, end transaction)
Zweck
: Realisierungsgarantie auch längerer Abläufe
Realisierung: Im Log-Protokoll werden alle Datenänderungen (kein Lesen) schnell parallel notiert und bei
Bedarf nachgearbeitet oder rückgängig gemacht ("rollback, undo").
SQL
Probleme
: COMMIT, ROLLBACK
: Je weiter zurück die Dinge liegen, die man ungeschehen machen will, desto mehr Platz für das
Protokoll braucht man.
ACID-Eigenschaften:
A (atomicity):
C (consistency):
I (isolation):
D (durability):
Eine Transaktion ist unteilbar, wird also ganz oder gar nicht ausgeführt.
VOR und NACH der Transaktion ist der Datenbestand konsistent.
Die Einzelaktionen können ungestörte durchgeführt werden.
Die Ergebnisse werden dauerhaft/permanente gespeichert.
Beispiel: Eine Geldüberweisung ist eine Transaktion.
Sie besteht aus zwei Datenbankoperationen, der Operation auf einer Zeile (Reduzierung des
Kontostandes), der Operation auf der anderen Zeile (Erhöhung des Kontostandes). Beide Operationen
müssen gemeinsam oder gar nicht stattfinden.:
BEUTH/Steyer
Einführung in Datenbanksysteme
Technikbereich: Operationale Sicherheit
Bei gleichzeitiger Mehrfachbenutzung tritt evtl. lost update auf (Die spätere Änderung überschreibt die
frühere.) oder inconsistent analysis (Lesen und Ändern passieren gleichzeitig.) Abhilfe für beides ist sperren.
1. Problem: Lost update
in der Datenbank:
meier 500
user 1
user 2
meier +100
meier -100
Ablauf: - user1 holt den Satz mit 500
- user2 holt den Satz mit 500
- user1 addiert 100: 600
- user2 subtrahiert 100: 400
- user1 schreibt zurück: 600
- user2 schreibt zurück: 400
Ergebnis: Die Änderung des user1 (+100) geht verloren.
Abhilfe: user1 müsste den Satz während der ganzen Zeit sperren.
2. Problem: Inconsistent analysis
user1
user2:
adam
berta
cäsar
dora
emil
fritz
400
700
200
900
100
100
Addition von
oben nach unten
Änderungen von
unten nach oben
Ergebnis: Die Summanden haben verschiedene Änderungszustände.
Abhilfe: user1 müsste die Tabelle während der ganzen Zeit sperren.
BEUTH/Steyer
Einführung in Datenbanksysteme
Sonstiges: Datenunabhängigkeit
Zwischenschichten machen unabhängig.
Logische Datenunabhängigkeit: Benutzersichten sind invariant gegenüber Änderungen oder Ergänzungen
der Logik
Beispiel: zusätzlich Telefonnummer für Kunde (Auswirkungen auf existierende externe Schemata: keine)
Beispiel: Preis_einzel, Preis_doppel statt Preis (Auswirkung: Änderung nur der Anwendungen, die dieses
Datum verwenden)
Physische Datenunabhängigkeit: Invarianz aller Benutzersichten und Anwendungsprogramme
gegenüber der internen Speicherungstechnik
Beispiel: Entfernen eines Index (Auswirkung: Laufzeit von Anwendungen evtl. grösser, sonst keine)
Beispiel: Wechsel der Platten (Auswirkung: z.B. grössere Datenmengen speicherbar, sonst keine)
Sonstiges: Datenintegrität
Das System prüft gewisse Regeln bereits bei der Dateneingabe und bei Datenveränderungen
(einzelwertorientiert bei Aufzählungen, mengenorientiert bei Berücksichtigung aller Werte,
beziehungsorientiert bei Berücksichtigung anderer Tabellen:referentielle Integrität)
Unterstützung durch: Auswahlmenüs, Verbot des 35.Februar, einzige Werte sind männlich-weiblich,
eindeutiger Primärschlüssel für Zeilen, Datentypen
BEUTH/Steyer
Einführung in Datenbanksysteme
Sonstiges: Dateien
(vor den Datenbanksystemen)
Die Datenverarbeitung mit Dateien war und ist immer noch gekennzeichnet durch die Probleme Redundanz,
mögliche inkonsistente Daten, Abhängigkeit der Programme von der Datenorganisation, individuelle
Speziallösungen, Mehrfacharbeit.
Daten
Daten
Anwendung
Anwendung
Anwendung
Daten
Daten
Daten
Bei der Datenübernahme von Anwendung zu Anwendung muss meist explizit konvertiert werden.
Probleme:
-
Redundanz
Gleiche Daten werden z.B. aus Effizienzgründen mehrfach gespeichert
-
Mögliche Inkonsistenzen
Änderung eines redundanten Datums, Transfer Utilities
-
Abhängigkeit der Programme von der Datenorganisation
Jedes Programm enthält die Beschreibung der benutzten Daten
-
individuelle Speziallösungen
Selbstverständliche Datenbankfunktionalitäten (z.B. Schutz, Sicherheit, Schnelligkeit auch bei
grösseren Datenmengen, generelle Benutzbarkeit) fehlen oft oder müssen von Hand
nachgestrickt werden.
-
Mehrfacharbeit
Die Entwickler wissen oft nicht voneinander und erfinden das Rad doppelt.
BEUTH/Steyer
Einführung in Datenbanksysteme
Sonstiges: Datenbanklebenszyklus (Kreis, eigentlich Spirale)
Änderung und
Anpassung
Datenbankentwurf
Betrieb und
Überwachung
Installation
Anwendungsprogramme
Daten
definieren
und laden
DATENBANKENTWURF
Benutzeranforderungen
konzeptionelles Modell
logisches, externes, internes DB-Schema
INSTALLATION
Einlesen des Installationsbandes
Setzen der Umgebung, Initialisierung der Datenbereiche
Hochfahren des Datenbanksystems, Laden der Systemtabellen
Probebetrieb, Sicherung
DATEN DEFINIEREN UND LADEN
Laden des Datenbankschemas, Probebetrieb
Laden der Daten mit Sicherungen
ANWENDUNGSPROGRAMME
- Subsysteme, Pflichtenheft, Tools, Testfälle, Dokumentation
Aus Sicht der Datenbank achten auf Mehrbenutzerproblematik, Datenabsicherung, Datenintegrität, Laufzeit,
Blockaden, Sicherung
BETRIEB UND ÜBERWACHUNG
Sicherungskonzept, Wiederherstellverfahren
Tagesaktivitäten (interaktiver Betrieb), Nachtaktivitäten ( Stapelläufe, Druck, Sicherungen)
Bedienerausbildung
Monitoring für die Leistungsbewertung (für kritische Bereiche, Lastspitzen)
Notfallplanung (Bereitschaft, Notbetrieb)
ÄNDERUNG UND ANPASSUNG
Anpassung an neue Anforderungen (logische Änderungen)
Optimierung (physische Änderungen bei Hardware, Betriebssystem, Datenbank und Programmierung)
BEUTH/Steyer
Einführung in Datenbanksysteme
Sonstiges: Big Data
Volume
Velocity
Variety
Veracity
Tabellengrösse berechnen, Datenmassen werden heute überall produziert
durch Parallelverarbeitung, Hauptspeicherresidenz, werteorentierte Speicherung (~Index)
sehr heterogen
verschiedene und unbekannte Vertrauenswürdigkeiten
Übung: Tabellengrösse berechnen:
create table - Befehlnn
Speichergrösse jedes Datentyps
Grösse einer Zeile
Multiplikation mit Anzahl der Zeilen
Systeminformation einer Tabellendefinition dazuzählen
evl. Inizes berücksichtigen
Verifikation durch unload-table in BS, dort Grösse ablesen
Die Datenmassen werden heutzutage von Messgeräten produziert (things).
Schnelligkeit kann erreicht werden durch Parallelverarbeitung in arithm. Ausdrücken (AND, OR im select).
Schnelligkeit kann erreicht werden durch Hauptsichergrössen.
Schnelligkeit kann erreicht werden durch werteorientierte Speicherung (~Index).
Zahlendefinitionen von 'Big Data':
Byte
Kilobyte
Megabyte
Gigabyte
Terabyte
Petabyte
Exabyte
Zetabyte
Yotabyte
=
=
=
=
210 B
220 B
230 B
240 B
=
=
=
=
1 024 B
1 048 576 B
1 073 741 824 B
1 080 184 287 776 B
Anwendungsprinzip:
Aus Vergangenheitsdaten auf die Zukunft schliessen.
Z.B. Unfallschwerpunkt → Tempo 30.
Datenbankbeispiele:
kleine Tabelle
grosse Tabelle
Bild in Tabelle
Übungsdatenbank
Datenbank einer kleinen Firma
Datenbank einer grossen Firma
BEUTH/Steyer
Einführung in Datenbanksysteme
Sonstiges: Daten in der Cloud
Verschiedene Architekturen von Datenbanksystemen:
Datei-DBS
lokal, im Betriebsystem, nur ein Benutzer, nicht parallel benutzbar
Client/Server-DBS
ohne Betriebsystem, mehrere Benutzer möglich, parallel benutzbar
Netz-DBS
Speicherort ist ein Knoten im Rechnernetz
Cloud-DBS
ungeschützt, nicht lokalisierbar
Datei-DBS
Client/Server-DBS
Netz-DBS
für die Cloud:
- Datenverschlüsselung ist nötig
- Provider ist nötig.
- Nur Cloud-Befehle sind nötig (write-to-cloud, read-from-cloud)
- Eigener Speicherplatz ist nicht nötig.
Überlegungen, welches System man wählen soll:
- Grösse
- Parallelbenutzung
- Kosten
- Sicherheit
BEUTH/Steyer
Cloud-DBS
Einführung in Datenbanksysteme
Sonstiges: Datenbank-Literatur
Grundlagen:
Saake/Sattler: Algorithmen und Datenstrukturen, dpunkt verlag 2006
Sortieren, Suchen, Eigenschaften, Datentypen, Bäume, Graphen
Architektur:
Härder, Rahm: Datenbanksysteme, Springer 1999
Die untersten Datenbanksystemschichten (Speicherung, Transaktionen, Schnelligkeit) mit
Konzepten, ca. 40 €
Konzepte:
Heuer/Saake: Datenbanken, International Thomson Publishing 1997
Modelle, Entwurf, SQL, Anwendungsprogrammierung, weitere Konzepte (Sichten, Schutz,
Trigger), ca. 30 €
Kemper/Eickler: Datenbanksysteme, Oldenbourg 2001
Modelle, Entwurf, SQL, weitere Konzepte (Integrität, Schutz, Transaktionen, Mehrbenutzer)
objektorientierte, objektrelationale, Internetdatenbanken
Riccardi: Datenbanksysteme, Addison Wesley 2001
Modelle, Entwurf, SQL, weitere Konzepte (Speicherverwaltung, Schutz, Transaktionen,
Mehrbenutzer), objektrelationale Datenbanken, Anwendungen mit Java, ca. 60 €
Stonebraker/Moore: Objektrelationale Datenbanken, Hanser 1999
Die nächste grosse Welle
Vossen: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme, Oldenbourg 2008
Fast alles: Geschichte, Datenbankentwurf, Theorie, SQL, Objekte, XML, Konzepte
ca. 50 €
Programmieren:
Saake/Sattler: Datenbankenn & Java, dpunkt.verlag 2000
JDBC, SQLJ und ODMG, ca. 40 €
Dehnhardt: Anwendungsprogrammierung mit JDBC, Hanser 1999
Datenbanken – Java – Client/Server, ca. 25 €
Sonderthemen:
Bauer/Günzel: Data Warehouse Systeme, dpunkt verlag 2004
Architektur, Entwicklung, Anwendung
BEUTH/Steyer