Vorlesung

Vorlesung
Grundlagen betrieblicher
Informationssysteme
y
Prof. Dr. Hans Czap
p
Lehrstuhl für Wirtschaftsinformatik I
Email: [email protected]
Lehrstuhl für
Wirtschaftsinformatik I
- II - 1 -
Inhalt
Kap. 1 Ziele der Datenbanktheorie
Kap. 2 Datenmodellierung und Datenbankentwurf
K
Kap.
3D
Datenbankarchitektur
t b k hit kt
Kap. 4 Die Datenbanksprache SQL
Kap 5 Konzepte für Objektorientierte Datenbanken
Kap.
Kap. 6 Objektrelationale Datenbanken
Kap.
p 7 Datenbankentwurf: Funktionale Abhängigkeiten
gg
und
Normalisierung
Kap. 8 Datenintegrität
• Sperrprotokolle
• Recovery
Kap 9 Data-Warehouse-Konzept
Kap.
Data Warehouse Konzept
Kap. 10 Data Mining und Knowledge Discovery
Lehrstuhl für
Wirtschaftsinformatik I
- II - 2 -
3. Datenbankarchitektur
3.1 Das klassische Modell: Die drei Ebenen nach
ANSI/SPARC
3.2 Functional Layers
3 3 Client-Server-Konzept
3.3
Cli t S
K
t
– DBS als Client-Server-Konzept
– Transaction Server
– Anwendungsarchitektur
•
•
3-Tier Architecture
2-Tier Architecture
Lehrstuhl für
Wirtschaftsinformatik I
- II - 3 -
3.1 Das klassische Modell: ANSI/SPARC
• Beim Schichtenmodell nach ANSI/SPARC werden
f l
folgende
d Ebenen(Schichten)
Eb
(S hi ht ) unterschieden:
t
hi d
–
–
–
–
Benutzerebene - externe Sicht (externes Modell)
Datenschemaebene - konzeptionelle Sicht (konzeptuelles Modell)
Zugriffspfadebene - internes Schema (internes Modell)
Physische
y
Geräteebene ((Hardwareebene))
• Jede Schichtenarchitektur verfolgt das Ziel, pro Schicht
spezifische Aufgaben zusammenzufassen, die als
Umsetzung von Anfragen der übergeordneten Schicht
verstanden werden. Umgekehrt begreift sie die darunter
liegende Schicht als Dienstleister (Client Server Konzept)
Konzept).
Lehrstuhl für
Wirtschaftsinformatik I
- II - 4 -
Benutzerebene - externe Sicht (externes Modell)
• beschreibt die auf einen individuellen Benutzer oder ein
Anwendungsprogramm zugeschnittene Datensicht (View)
• die formale Beschreibung dieser Informationsstruktur wird
als SubSchema ((Datenteilschema)) bezeichnet
• verschiedene Benutzersprachen (DML= Data Manipulation
Language)
– SQL Structured Query Language (Select … from … where …)
– QBE Query by Example (Formulierung von Anfragen mittels
grafischer Oberfläche,, die die Struktur der DB zeigt.
g
g Vgl.
g z.B. MSAccess)
• Zugriffsrechte können im Subschema festgelegt werden
• Externe
E t
Namen
N
von Tabellen
T b ll oder
d Att
Attributen
ib t müssen
ü
nicht mit den Namen der Schemaebene übereinstimmen
Lehrstuhl für
Wirtschaftsinformatik I
- II - 5 -
Datenschemaebene (konzeptuelles Modell)
•
•
Beschreibung der gesamten Daten auf logischer Ebene
E t ll
Erstellung
eines
i
kkonzeptuellen
t ll S
Schemas
h
mit
it Hilf
Hilfe einer
i
geeigneten
i
t
Datenbeschreibungssprache (DDL-data definition language)
SQL umfasst auch Befehle zur Erstellung des Schemas und der
Subschemata.
•
•
alle externen Sichten müssen auf dem (Gesamt-) Schema abbildbar
sein!
Inhalt eines konzeptuellen Schemas:
–
–
–
Definition der Tabellen (Relationen) und Ihrer Beziehungen
einschließlich
i
hli ßli h sämtlicher
ä tli h Att
Attribute
ib t
Definition von Integritätsbedingungen (Constraints, Assertions,
referentielle Integrität (Fremdschlüsselbeziehung))
Definition von Zugriffsrechten (DCL = Data Control Language. Ebenfalls
in SQL enthalten)
Lehrstuhl für
Wirtschaftsinformatik I
- II - 6 -
Zugriffspfadebene - internes Schema/internes Modell
Im internen Schema wird die physische Datenorganisation
f t l t Inhalte:
festgelegt.
I h lt
– Information über Aufbau und Struktur der abgespeicherten Daten
(physische Datenspeicherung), z.B. Folge der Felder in einem
Datenbanksatz, Länge der Felder, Position von Zeigern und
Schlüsseln
– Informationen über die Speicher
Speicherungsform
ngsform der Daten
Daten, z.B.
B
Speicherung, möglichst nahe bei einem bestimmten anderen Satz
(Clusterungen).
– Informationen über die Zugriffspfade. z.B.: sekundäre Indizes
(Indextechniken), Verkettungen durch Zeiger (Kettungstechniken,
Baumstrukturen)
Lehrstuhl für
Wirtschaftsinformatik I
- II - 7 -
Architekturübersicht eines DBMS
„Naive“
Benutzer
An end ng
Anwendung
Fortgeschrittene
Benutzer
AnwendungsProgrammierer
Datenbankadministratoren
Interaktive
Anfrage
Präcompiler
Verwaltungsg
werkzeug
DML-Compiler
DDL-Compiler
A f
Anfragebearbeitung
b b i
Mehrbenutzersynchr.
Mehrbenutzersynchr
Fehlerbehandlung
Datenbankmanager
DBMS
Schemaverwaltung
D t i
Dateiverwaltung
lt
Logdateien
Lehrstuhl für
Wirtschaftsinformatik I
Indexe
Datenbasis
- II - 8 Hintergrundspeicher
Datenwörterbuch
3.2 Functional Layers
y
Client
Client
Client
Client
Language and API laver
Query processing and optimization layer
Transaction management layer
Query excecution layer
A
Acess
layer
l
Storage layer
Database
Lehrstuhl für
Wirtschaftsinformatik I
- II - 9 -
Zugriffe
3.3 Client-Server Konzept
p
Cli t
Client
….
Cli t
Client
Cli t
Client
network
Server
Die Clients stellen Requests
Requests, die der Server bedient
bedient.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 10 -
DBS als Client-Server Konzept
Die Funktionalität eines DBS wird unterteilt in Back
Back-end
end (server) und
Front-end (Clients)
SQL user interface
Forms interface
Report writer
Front-end
Graphical interface
I t f
Interface:
SQL/API
Back-end
SQL Engine
•Font-end: Bereitstellung von Tools
Tools, wie Maskengenerator (Forms) ,
Report-generator, graphisches Benutzer-Interface, DML etc.
•Back end: eigentlichen Datenbankoperationen, wie Übersetzung der
A f
Anfrage,
Optimierung
O i i
des
d Zugriffspfades,
Z iff f d
Transaktionskontrolle,
T
ki
k
ll
recovery.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 11 -
Transaction Server
• Transaction Server sind Basis eines DBMS:
– Synonym: Query Server
– Anforderungen der Clients werden bearbeitet, die Ergebnisse an die
Clients zurückgeschickt
– Clients können auch übers Web oder allgemein „remote“ zugreifen
Verwendeter Mechanismus: RPC (remote procedure call)
– Der Zugriff aus Programmiersprachen erfolgt über standardisierte
Interface-Vereinbarungen (unabhängig vom jeweiligen DBS)
• ODBC = Open
p Database Connectivity
y ermöglicht
g
den Zugriff
g aus C und
Abkömmlingen von C.
• JDBC = Java Database Connectivity ermöglicht den Zugriff aus Java.
– Ermöglichen das gleichzeitige Abarbeiten mehrerer Prozesse und
sind zuständig für Recovery, log-writing etc.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 12 -
Anwendungs-Architektur
g
User
U
User
Client
A li ti Cli
Application
Clientt
Anwendung
middleware
network
network
Application Server
D t b k
Datenbanksystem
t
Server
Datenbanksystem
2-Tier-Architektur: Client bedient sich
3-Tier-Architektur: Client hat z.B.
ODBC/JDBC um mit DBMS zu
kommunizieren
eine web-basierte Anwendung. Er
verwendet eine „middleware“ als
Anwendungs-Server,
S
die mit dem
DBMS zusammenarbeitet.
Lehrstuhl für
Wirtschaftsinformatik I
- II - 13 -
3-Tier System-Architektur
y
•
Clients
– Präsentationsebene (GUI graphical user interface, Internet browser)
•
Application Server
– Anwendungsprogramme (Anwendungskomponenten, Servlets)
– Request Brokering (z.B. ORB object request broker, Web Server)
– Benötigte
B öti t K
Kommunikatonsebene
ik t
b
h
heisst
i t „middleware“
iddl
“
• Z.B. CORBA (Common Object Request Broker) , EJB (Enterprise Java Beans),
SOAP Simple Object Access Protocoll etc.
•
Data Server
– Datanbankserver und (klassische) Datenserver
•
Spezialisierung der 3-Tier-System Architektur zur 2-Tier Client-ServerArchitektur :
– Client-Server mit „fat“ clients (Client + Applikation +ODBC)
– Client-Server mit „thin“ clients (Applikation befindet sich auf dem
Applikations-Server)
Lehrstuhl für
Wirtschaftsinformatik I
- II - 14 -