Synch.modul Datenbanken

Synchronisationsmodul Informatik
Teil-Modul „Datenbanken“
Kapitel 2: Semantische Datenmodellierung
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 1
Semantische Datenmodellierung
Inhalte des Kapitels
• Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen
• Das erweiterte Entity-Relationship Modell (eERM)
• Unterschiedliche Nomenklaturen für ER-Diagramme
Lernziele
• Verständnis für den strategischen Stellenwert der semantischen
Datenmodellierung mit Hilfe von ER-Diagrammen in der Analyse-Phase
• Analogien und Unterschiede zum OOA-Klassendiagramm kennen
• Sensibilisierung für unterschiedliche Nomenklaturen und die damit
zusammenhängende Änderung der semantischen Aussage
 Unter Semantik (gr. σημαίνειν sēmainein „bezeichnen“) versteht man die Lehre über die
Bedeutung von Zeichen, also im Speziellen von allen sprachlichen Äußerungen.
Insbesondere in der Analysephase ist es wichtig, bei der Beschreibung der Anforderungen, der
Wahl der Bezeichner etc. vollständige semantische Klarheit zu erreichen!
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 2
Die Rolle der Datenmodellierung …
…im Lifecycle von Informationssystemen
•
Vor der Einführung der OOA / OOD, mit UML als standardisierter Beschreibungssprache ab 1997, war die Sicht auf Daten und Prozesse getrennt – auch hinsichtlich
der eingesetzten Methodiken:
James Martin, 1982
eER-Modell
strukturierte Analyse
de Marco 1979
ER Diagramme, Chen 1976
Relationenmodell
strukturierter Entwurf
Constantine, Jackson 1974/75
(für RDBMS, Codd 1970)
SQL (für RDBMS,
strukturierte Programmierung
Dijkstra 1970
Codd 1970)
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 3
Lifecycle von Informationssystemen
•
Evolutionäre Vorgehensmodelle entsprechen einem zyklischen, iterativen Durchlaufen der einzelnen Phasen Jede Phase liefert Ergebnisse, die als Input für die
darauf folgende Phase Verwendung finden:
Planungsphase
Der Informationsbedarf der zu untersuchenden Organisation wird ermittelt und eine
Informationsstrategie erarbeitet.
Beispiel: CRUD-Matrix (Create – Read – Update – Delete)
 Ergebnis: ”Informations-Projekte” (=Zusammenfassung von Funktionen, die die
gleichen Informationsobjekte verwenden) und “Funktionsbereiche” sind definiert,
um den vorgegebenen Organisationsbereich zu strukturieren.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 4
K
un
Planungsphase
de
n
Fu
nk
tio
ne
n
Ausschnitt aus einer
CRUD-Matrix
ve
A
uf
rw
tr
al
ag
te
n
ab
A
w
uf
ic
tr
ke
ag
ln
a
Li
br
ef
ec
er
hn
an
en
t
en
B
es
ve
te
rw
llu
al
n
B
te
g
es
n
er
te
s
t
llu
el
le
ng
W
n
ar
ab
en
re
ei
ch
n
…
ne
ga
n
ng
üb
er
…
w
ac
he
n
Lifecycle von Informationssystemen
Entitäten
Kundenaufträge
Kunde
CRUD
Beschaffung
R
R
…
Auftrag
CRUD
R
…
Auftragsposition
CRUD
R
…
CRU
…
CRUD
…
Kundenrechnung
Kundenrechnungsposition
Artikel
R
R
R
R
R
…
R
R
R
…
L-Bestellung
CRUD
R
R
…
L-Bestellungsposition
CRUD
R
R
…
Lieferant
CRUD
L-Rechnung
L-Rechnungsposition
CRU
…
CRUD
…
Wareneingangbuch
…
Schestag
…
…
…
…
Synchronisationsmodul DB (Master DS)
…
…
…
CRU
…
…
…
Kapitel 2 - 5
Lifecycle von Informationssystemen
Analysephase
Die “Informations-Projekte” aus der Planung werden sowohl aus Daten- als auch
aus Prozess-Sicht weiter detailliert. Zu jedem Zeitpunkt der Analyse- und auch der
darauf folgenden Designphase muss darauf geachtet werden, dass Daten- und
Prozessmodell zueinander konsistent sind.
 Ergebnis: Datenmodell (eER-Diagramm) und Prozessmodell (Analysesicht) liegen vor.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 6
Lifecycle von Informationssystemen
Designphase
Während man sich in der Analysephase ausschließlich mit einer logischen Sicht auf
die Daten beschäftigt, wird diese während der Designphase sowohl durch die Berücksichtigung des Datenbankmodells als auch der Implementierungsplattform (DBMS) ergänzt:
•Implementierung der Beziehungen durch Definition von Referenzen
•Festlegung der Datentypen (DBMS-spezifisch)
Mit Hilfe von CASE-Tools *) können Datenmodelle der Designsicht aus Datenmodellen
der Analysesicht generiert werden (und umgekehrt: Round-Trip-Engineering).
 Ergebnis: Datenmodell (z.B. Relationenmodell, ergänzt um Datentypen des ZielDBMS beim Einsatz von RDBMS) und Prozessmodell der Designsicht liegen vor.
*) CASE = computer aided software engineering
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 7
Lifecycle von Informationssystemen
Implementierungsphase
Die Güte von Analyse und Design zeigen sich in einer relativ problemlosen
Implementierung.
Im Falle eines RDBMS erfolgt die Implementierung eines Datenbankschemas
durch die deklarative Sprachkomponente von SQL (SQL DDL).
Beim Einsatz von CASE-Tools ist es möglich, das SQL-Skript für ein spezifisches
RDBMS direkt aus den Informationen des Relationenmodells zu generieren.
 Welche Diagrammtypen der UML können Sie im Fall eines
objektorientierten Systems den einzelnen Phasen zuordnen?
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 8
Semantische Datenmodellierung
 Die Rolle der Datenmodellierung im Lifecycle von Informationssystemen
•
Das erweiterte Entity-Relationship Modell (eERM)
•
Unterschiedliche Nomenklaturen für ER-Diagramme
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 9
Das Entity-Relationship Modell ERM
Das Entity-Relationship Modell wurde von Chen*) erstmals 1976 vorgestellt.
Oracle
(1979)
CODASYL
System R (1977)
 DB2
(1983 unter MVS)
IMS/VS seit
1968 (IBM)
1960
Hierarchisches
Datenbankmodell
1970
1976 1980
1990
Netzwerk
Datenbankmodell
(1971, Data Base Task Group)
Relationales
Datenbankmodell
(1970, Edgar F. Codd)
Schestag
1997 2000
2010
UML – Unified Modeling
Language
wird 1997 von der OMG als
Standard akzeptiert
*) Chen P. P-S. The Entity-Relationship Model – Towards a Unified View of Data.
ACM Transactions of Database Systems (March 1976), 1(1):9-36
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 10
Das Entity-Relationship Modell ERM
„A data model, called the entity-relationship model, is proposed. This
model incorporates some of the important semantic information about
the real world. A special diagrammatic technique is introduced as a
tool for database design. An example of database design and description
using the model and the diagrammatic technique is given. Some implications for data integrity, information retrieval, and data manipulation are
discussed.
The entity-relationship model can be used as a basis for unification of
different views of data: the network model, the relational model, and the
entity set model. Semantic ambiguities in these models are analyzed.
Possible ways to derive their views of data from the entity-relationship
model are presented. …“
Anfang des Abstracts zu o.g. Artikel von P.P-S. Chen, 1976
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 11
Das Entity-Relationship Modell ERM
Ziele des von Chen 1976 vorgestellten ERM:
• Modellierbarkeit semantischer Informationen aus der realen Welt
• Schaffung einer Grundlage zur Analyse von
– Netzwerkmodell
– Relationenmodell und
– Entity-Set Model.
•
Das ERM von Chen zeichnet sich aus durch seine Unabhängigkeit von
spezifischen Datenbankmodellen.
 Der Entwurf eines ER-Modells findet in der Analysephase des SW-Lifecycle
statt.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 12
ERM – Der Entity-Typ (Entity-Type)
•
Zur visuellen Beschreibung der Struktur von Objekten der realen Welt und
der Beziehungen dieser Objekte untereinander verwendet man Diagramme,
in denen die entsprechenden Komponenten graphisch dargestellt werden:
– Eine Entität (entity) ist ein Objekt der realen Welt.
– Der Entity-Typ (entity type) ist der Repräsentant aller Objekte
gleichen Typs.
 Grafische Notation: Rechteck, das den Namen des Entity-Typs enthält:
Produkt
Produkte
 Der Name eines Entity-Typs ist stets ein Substantiv, das im Singular
verwendet wird. Ein Entity-Typ, der die Struktur einer Produkt-Instanz
repräsentieren soll, erhält also den Namen Produkt (und nicht Produkte!).
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 13
ERM – Der Entity-Typ (Entity-Type)
•
Hinweis: Der Begriff Entity-Typ entspricht der Schemadeklaration einer
Klasse in der UML und wird bei der Datenmodellierung, auch bei CASETools, häufig dem Begriff Entität (Entity) gleichgesetzt.
Genau genommen entspricht der Begriff der Entität jedoch einer einzelnen
Instanz eines Enitity-Typs, so wie ein Objekt einer einzelnen Instanz einer
Klasse entspricht.
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 14
ERM – Der Beziehungstyp (Relationship-Type)
•
•
Eine Beziehung (Relationship, Assoziation) beschreibt, ob und wie
Entitäten untereinander assoziiert sind.
Der Beziehungstyp (relationship type) ist der Repräsentant aller
Beziehungen gleichen Typs.
 Grafische Notation (in CASE-Tools eher selten unterstützt): Raute, die den
Namen des Beziehungstyps oder eine (numerische) Referenz auf den
Bezeichnertext enthält.
Bestellung
Produkt
Schestag
oder
1
1 = Bestellung
Bestellung
Synchronisationsmodul DB (Master DS)
Kunde
Kapitel 2 - 15
ERM – Der Beziehungstyp (Relationship-Type)
•
•
Hinweis: Der Begriff Beziehungstyp entspricht dem Begriff der Beziehung
zwischen Klassen in der UML und wird bei der Datenmodellierung, auch bei
CASE-Tools, häufig dem Begriff Beziehung (Relationship bzw. Association)
gleichgesetzt.
Im allgemeinen Fall wird eine Beziehung in den meisten CASE-Tools
zunächst als Verbindungslinie zwischen zwei Entity-Typen dargestellt.
Produkt
Bestellung
Kunde
Toolbar und Zeichencanvas zur Modellierung eines konzeptionellen Datenmodells
Power Designer 12.5
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 16
ERM – Attribute
•
Attribute beschreiben die Eigenschaften von Entity- oder Beziehungstypen.
 Grafische Notation: Abgerundetes Rechteck oder Oval, das den
Attributnamen enthält.
Produkt
…
•
Bestellung
Kunde
Vorname
Bestelldatum
Nachname
…
Attribute, die in dieser Form in ER-Diagrammen dargestellt werden, zeigt
man aus Übersichtlichkeitsgründen oft nur optional mit an.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 17
ERM – n-äre Beziehungen
•
•
•
Entsprechend der Anzahl n der an einer Beziehung beteiligten Entity-Typen
spricht man von n-stelligen oder auch n-ären Beziehungen, n  2.
Im Fall n = 2 nennt man die Beziehung 2-stellig oder auch binäre Beziehung und spezialisiert den Fall, dass die Beziehung rekursiv sein kann.
3-stellige Beziehungen nennt man auch ternäre Beziehungen.
 Die Raute als Symbol für eine Beziehung ist besonders gut geeignet, n-äre
Beziehungen für n ≥ 3 darzustellen.
Produkt
1
1 = Komponentenbeziehung
Bestellung
Kunde
Lieferung
 Wie stellen Sie ternäre Beziehungen in der UML dar?
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 18
ERM – Kardinalitäten
•
•
•
Mit der Kardinalität*) min:max kennzeichnet man die minimal und maximal
mögliche Anzahl von Instanzen eines Entity-Typ, die mit einer bestimmten
Instanz eines anderen Entity-Typ in Beziehung stehen.
Als Wert für „beliebig viele“ verwendet man Buchstaben wie m und n.
Ursprünglich verwendete Chen in seinen Diagrammen bei der Angabe von
Kardinalitäten nur die Obergrenze!
1 Kunde bestellt mindestens 1, aber beliebig viele Produkte
Produkt
N
oder 1:N
Bestellung
0:M oder
M
Kunde
1 Produkt wird von möglicherweise keinem aber beliebig vielen Kunden bestellt.
*) Die Zuordnung der Kardinalitäten (in der UML auch Multiplizitäten genannt) zu den Entitäten wird
u. U. auch in umgekehrter Reihenfolge vorgenommen.
Vgl. hierzu den Abschnitt Unterschiedliche Nomenklaturen zu ER-Diagrammen.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 19
ERM – Kardinalitäten
•
Hinweis: In vielen CASE-Tools zur ER-Modellierung werden die
Kardinalitäten mit der Krähenfuß-Nomenklatur nach James Martin
bezeichnet (engl. crawfood-Darstellung):
Entität
= maximal ein
Entität
kein oder
ein
Entität
= beliebig viele
ein und
nur ein
Entität
kein oder
mehrere
Schestag
= genau ein
Synchronisationsmodul DB (Master DS)
= mindestens ein
ein oder
mehrere
Kapitel 2 - 20
ERM – Kardinalitäten im Power Designer
 In vielen CASE-Tools wird die binäre Darstellung zwischen zwei EntityTypen ohne ein explizites Assoziationssymbol dargestellt.
Die Kardinalitäten werden häufig mit der Krähenfuß-Notation angezeigt:
Im Power Designer wird bei
der 0:1-Notation auf die
Darstellung der 1 verzichtet!
 Haben Assoziationen eigene Attribute, so werden sie als eigene (schwache)
Entity-Typen dargestellt (s. 2/23).
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 21
ERM – schwache Entitäten
•
Entitäten, die nicht alleine, sondern nur in Abhängigkeit von der Existenz
anderer Entitäten existieren können, nennt man schwache Entitäten –
weak entities und spricht auch von abhängigen Beziehungen – dependent
Relationships.
•
Die Entity-Typen schwacher Entitäten werden in der Nomenklatur nach
Chen durch ein Rechteck mit doppelter Linie gezeichnet. Von der Raute auf
den schwachen Entity-Typ deutet ein Pfeil:
Student
1
Student
Nachweis
Nachweis
Im Power Designer ändert sich bei
Abhängigkeit (= Dependency) die grafische
Darstellung der entsprechenden Kardinalität!
Schestag
Bewertung
Bewertung
Analogie zu schwachen Entitäten im
UML-Klassendiagramm (Analysesicht)?
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 22
Assoziationen mit eigenen Attributen
•
Assoziationen, die selbst Attribute besitzen oder Beziehungen zu anderen
Entity-Typen haben, werden als schwache Entitäten dargestellt:
Produkt
ProduktNr
<pi> I
ProduktBezeichner
VA20
Preis
MN8,2
...
ProduktToBestellung
Kunde
KundenNr
<pi> I
KundenNachname
VA20
...
Bestellung
BestellDatum D
KundeToBestellung
 Wie nennt man die Analogie hierzu im UML-Klassendiagramm (Analysesicht)?
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 23
ERM – Hörsaalübung
•
Zeichnen Sie ein ER-Diagramm, das die angegebenen Entity-Typen und
deren Beziehungen untereinander darstellt. Verwenden Sie zur Darstellung
der Beziehungstypen das Rautensymbol.
Entity-Typen – Klassen
• Mitarbeiter
• Abteilung
• Projekt
Beziehungstypen – Beziehungen
• Jeder Mitarbeiter arbeitet in genau einer Abteilung, in jeder Abteilung arbeiten mehrere Mitarbeiter.
• Jede Abteilung hat genau einen Mitarbeiter, der der Leiter dieser Abteilung ist.
• Jeder Mitarbeiter arbeitet in keinem, einen oder mehreren Projekten mit.
• Für einen Mitarbeiter ist seine Rolle in jedem Projekt bekannt, an dem er beteiligt ist.
• Jedes Projekt ist genau einer Abteilung zugeordnet.
 Gibt es Unterschiede zur objekt-orientierten Modellierung von Klassen und
Beziehungen (UML-Klassendiagramm)?
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 24
Das erweiterte ER Modell – eERM – Vererbung
•
Die spezielle Beziehungsstruktur einer Vererbungshierarchie –
Inheritance wurde als Erweiterung der ursprünglichen ERM in Anlehnung
an entsprechende objektorientierte Konzepte ergänzt.
•
Man spricht auch von Generalisierung / Spezialisierung oder von „ist-ein
Beziehung“
•
Ein Wurzel-Entity-Typ stellt jeweils den Supertyp dar, der diejenigen
Attribute und Beziehungen enthält, die alle seine Subtypen (Spezialisierungen) gemeinsam haben.
•
Alle Subtypen werden dann nur noch durch spezifische Attribute oder auch
durch spezifische Beziehungen zu anderen Entity-Typen beschrieben, die
sie von den anderen Subtypen unterscheiden.
 Welche constraints der UML kennen Sie im Zusammenhang mit der
Darstellung von Vererbungshierarchien?
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 25
eERM – Vererbung
Geschäftspartner
Händler
Spediteur
Kunde
Veranstalter
• Man unterscheidet zwischen den folgenden Spezialisierungsformen:
 Totale Spezialisierung: Jede Instanz des Supertyps entspricht mindestens
einem Subtyp. Insbesondere überdeckt die Menge aller Subtypen alle
Instanzen des Supertyps (Darstellung: „Doppelstrich“, s.o.).
 Partielle Spezialisierung: Nicht jede Ausprägung des
Supertyps wird notwendig spezialisiert
(Darstellung: „einfacher Strich“).
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 26
eERM – Vererbung
 Disjunkte Spezialisierung: Die Teilmengen der Instanzen aller
Spezialisierungen sind disjunkt (Darstellung: D = disjoint im
Dreickessymbol), andernfalls erlaubt man
 Überlappende Spezialisierung (Darstellung: O = overlapping im
Dreieckssymbol)
D
O
Toolbar und Zeichencanvas zur Modellierung einer
Vererbungshierarchie im konzeptionellen Datenmodell
Power Designer 12.5
Die Unterschiedung zwischen totaler und. partieller
Spezialisierung bzw. zwischen disjunkten und überlappenden Spezialisierungen ist hier möglich durch
Setzen der beiden folgenden Eigenschaften:
mutually exclusive ↔ disjoint
complete
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 27
Primärschlüssel
•
•
•
•
Um einzelne Entitäten voneinander unterscheiden und identifizieren zu
können, wird ein so genannter Primärschlüssel (Primary Key) eingeführt:
Ein Attribut oder eine Kombination von Attributen heißt Primärschlüssel
p, wenn gilt:
1. Der Wert von p definiert die Attributwerte aller anderen Attribute der
Entität eindeutig.
2. Man kann (im zusammengesetzten Fall) kein Attribut aus p entfernen,
ohne dass 1. verletzt wird.
Besteht der Schlüssel aus einer Kombination mehrerer Attribute, so
spricht man von einem zusammengesetzten Schlüssel - concatinated
key.
Graphische Notation: Der Primärschlüssel ist einfach (oder doppelt)
unterstrichen in der Attributliste:
…
Buch (ISBN, Titel, …)
Schestag
Buch
ISBN
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 28
Candidate Key
•
•
Gibt es in einem Entity-Typ mehrere Schlüssel, von denen jeder die Rolle
des Primärschlüssels übernehmen kann, so nennt man diese candidate
keys (alternative Primärschlüssel) und wählt einen von ihnen als Primärschlüssel des Entity-Typs aus.
Der Begriff „concatinated” gilt analog für candidate keys.
•
Beispiel: Personalstammdaten in einem Entity-Typ Person
Person
Sozialversicherungsnummer
Personalnummer
Gehalt
Steuerklasse
candidate key: Sozialversicherungsnummer
Schestag
Synchronisationsmodul DB (Master DS)
primary key: Personalnummer
Kapitel 2 - 29
Unterschiedliche Nomenklaturen …
… für ER-Diagramme
•
Erste Schema-Diagramme wurden in den 60er Jahren von Charles
Bachmann1) formalisiert:
– Er benutzte Rechtecke, um so genannte Record-Typen zu kennzeichnen, und Linien bzw. gerichtete Pfeile von einem Record-Typ zu
einem anderen, um eine 1:1- bzw. 1:N-Beziehung unter den Instanzen
des jeweiligen Typs zu kennzeichnen:
Bachmann-Notation
A
B
A
B
Vergleich: Chen-Notation
A
1) Bachmann,
Schestag
1
1
B
A
1
N
B
C.W. Data Structure Diagrams. Databases 1, 2 (1969), pp. 4-10
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 30
Unterschiedliche Nomenklaturen (2)
Bei jeder Schreibweise stellt sich die Frage nach
• Lesrichtung und
• Interpretation der Kardinalitäten (Multiplizitäten):
Chen-Notation (analog UML-Lesrichtung und -Interpretation)
Jede Instanz der Entität A
ist zu 1 Instanz der Entität
B assoziiert bzgl. R.
A
N
1
R
B
Jede Instanz der Entität B
ist zu N Instanzen der Entität
A assoziiert bzgl. R.
B
Jede Instanz der Entität B
ist in maximal n Beziehungen vom Typ R zu Instanzen der Entität A enthalten.
min,max-Notation
Jede Instanz der Entität A
ist in maximal 1 Beziehung
vom Typ R zu Instanzen
der Entität B enthalten.
A
(0,1)
R
(0,n)
 Während die erste Notation die Anzahl der bzgl. R assoziierten Entitäten
zählt, wird in der zweiten Notation die Anzahl der Beziehungen R gezählt, in
denen eine Entität enthalten ist.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 31
Zusammenfassung
•
Die ER-Modellierung legte bereits in den 60er Jahren die Grundlagen für
das UML-Klassendiagramm in der Analysesicht (OOA).
•
Neben zahlreichen Analogien zum UML-Klassendiagramm der OOA gibt es
neben Unterschieden in der Nomenklatur
– den Begriff der schwachen Entität, sowie
– den Begriff des Primärschlüssels und der Candidate Keys.
•
Das erweiterte ER-Modell – eERM ermöglicht es, analog zur UML,
Vererbungshierarchien zu beschreiben.
•
Im Gegensatz zur standardisierten UML findet man in Diagrammen zur
Datenmodellierung unterschiedliche Lesrichtungen bzgl. der Kardinalitäten.
Hier stehen im direkten Gegensatz die Lesrichtung von ER-Diagrammen
nach Chen und UML gegenüber der min,max-Notation.
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 32
Datenbanken

Einführung

Semantische Datenmodellierung
3.
Relationenmodell
4.
Interne Datenorganisation
5.
SQL - Structured Query Language
6.
Prozedurale Spracherweiterungen von SQL, Stored Procedure und
Trigger, JDBC
7.
Transaktionsmanagement
Schestag
Synchronisationsmodul DB (Master DS)
Kapitel 2 - 33