1.7 Architekturen im DB-Umfeld Wozu Architekturen?

1.7 Architekturen im DB-Umfeld
 Wozu Architekturen?
- Allgemein zur "Strukturierung des Chaos" (beispielsweise eines
konkreten, komplexen Softwaresystems)
- Unterscheidung zwischen verschiedenen Sichtweisen eines Systems
• Benutzersicht
• Administratorsicht, ...
- Festlegung einer Systemstruktur
• Komponenten
• Ebenen
• Schnittstellen
- Speziell bei Datenbanksystemen zusätzlich: Architekturen als ein Mittel
zur Realisierung eines möglichst hohen Grades an Datenunabhängigkeit
durch Separierung verschiedener Ebenen/Komponenten
 Bedeutende Architekturen
- ANSI/SPARC
- DIAM
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 32
1.7.1 ANSI/SPARC-Architektur
 Entstanden in den 1970er Jahren
- ANSI = American National Standards Institute
- SPARC = Standards Planning and Requirements Committee
 Unterscheidung zwischen drei Ebenen:
- Externes Schema:
• Wie werden die Daten dem Benutzer präsentiert?
• (Teil-)Sichten auf den Datenbestand je nach Anforderung, in
relationalen DBS als View realisierbar (Bsp: Sicht auf Personaldaten
für Management / Personalabteilung / Mitarbeiter)
- Konzeptuelles Schema:
• Welche Daten werden beschrieben?
• Gesamtdarstellung des Datenmodells auf logischer, (möglichst)
system- und anwendungsunabhängiger Ebene, beispielsweise in
relationaler Darstellung oder im Entity-Relationship-Modell
- Internes Schema:
• Wie werden die Daten persistiert?
• Beschreibt (DBVS-spezifisch) die interne, physische Darstellung der
Daten: wie und wo genau abgelegt, internes Satzformat, Zugriffspfade
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 33
1.7.1 ANSI/SPARC-Architektur
 Bildliche Darstellung:
Anw./Benutzer
Anw./Benutzer
externes
Schema 1
externes
Schema n
Externe
Sichten
...
Externe
Ebene
Konzeptuelle
Sicht
konzeptuelles
Schema
Konzeptuelle
Ebene
Interne
Sicht
internes
Schema
Interne
Ebene
 Bemerkung zu ANSI/SPARC:
- Unterscheidung zwischen verschiedenen Betrachtungsweisen/-ebenen
einer Datenbank mit Datenbanksprach-Äquivalenten (SQL)
- Kein Mittel zur Strukturierung/Ebenenunterteilung eines DBVS ( DIAM)
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 34
1.7.1 ANSI/SPARC-Architektur
 Zuständigkeiten
- Datenbankadministrator
• Legt konzeptuelles Schema mit Anwendungsadministratoren fest
• Legt internes Schema fest
• Kennt nicht unbedingt externe Schemata
- Anwendungsadministrator
• Legt konzeptuelles Schema mit Datenbankadministrator fest
• Legt externe Schemata fest
• Kennt internes Schema nicht
- Benutzer / Anwendung
• Kennt "sein/ihr" externes Schema und stellt Datenbankanfragen
"gegen" dieses Schema
• Kennt sonst nichts weiter
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 35
1.7.1 ANSI/SPARC-Architektur
 Physische Datenunabhängigkeit: Änderungen am internen Schema einer
Datenbank haben keine Auswirkungen auf konzeptuelles/externe Schemata
- Beispiel: neue Platzierung der Daten, andere Speichermedien, neue
Zugriffspfade (z.B. Hash  Baum)
- Vor allem die Anwendungen mit Bezug auf ein externes Schema bleiben
unbeeinflusst
 Logische Datenunabhängigkeit: Änderungen am konzeptuellen Schema
können gegenüber externen Schemata verborgen werden
- Beispiel: Definition neuer Tabellen, zusätzliche Attribute, neuer
Beziehungen, Neuzuordnungen von Attributen zu Tabellen
- Nur Anpassung der Sicht-Definition vom Anwendungsadministrator
- Teilweise kann sogar das Wegfallen eines Attributs nach oben "maskiert
werden" (Stichwort berechnete/virtuelle Attribute)
- Transparenz hat aber Grenzen
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 36
1.7.1 ANSI/SPARC-Architektur
 Datenbanksystemunabhängigkeit
- Ziel: Gar keine / möglichst wenig Änderungen notwendig beim Übergang
von DBVS-Produkt x zu DBVS-Produkt y
- Betrachtung hier für den relationalen Fall
• internes Schema (Zugriffspfad definieren, Festlegung des Ortes der
Datenabspeicherung etc.) muss angepasst werden, da Systemspezifika nicht genügend von der SQL-Norm erfasst werden (können)
• konzeptuelles Schema und externe Schemata können – falls
"normkonform" entwickelt – unverändert bleiben
- Bemerkung zur "Normkonformität":
• heißt Verzicht auf die Benutzung herstellerspezifischer SQLErweiterungen und -Spezialitäten
• erfordert Programmier-/Entwicklungsrichtlinien im Unternehmen
bzw. Vorgaben an den SQL-Compiler im DBVS für Programme mit
eingebetteten SQL-Anweisungen
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 37
1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS
 Beispiel: Informationen über Bücher und Autoren
 Konzeptuelles Schema = relationales DB-Schema
- Basistabellen BUCH und AUTOR
- Unterstrichene Attribute sind Schlüssel in der Tabelle
- BUCH
BuchId
4242
3745
...
Titel
Jahr
ADAxx
1956
Hundezucht 1995
...
...
ISBN
3-452-12
1-424-11
...
- AUTOR (Schlüssel über BuchID+Nr wegen Co-Autoren)
BuchId
Nr
4242
3745
3745
...
1
1
2
...
Name
Winkler
Küspert
Beckstein
...
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 38
1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS
 Externes Schema = relationale Sicht
- Realisierung über eine View ("Virtuelle Tabelle")
- TITEL
Name
Nr
Winkler
Küspert
Beckstein
...
1
1
2
...
Titel
ADAxx
Hundezucht
Hundezucht
...
Jahr
1956
1995
1995
...
ISBN
3-452-12
1-424-11
1-424-11
...
- SQL-Definition obiger View
CREATE VIEW TITEL AS
SELECT Name, Nr, Titel, Jahr, ISBN
FROM
BUCH, AUTOR
WHERE BUCH.BuchID = AUTOR.BuchID
- Erläuterungen zu Datenunabhängigkeit auf nächster Folie
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 39
1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS
- Benutzer kann mit Sicht/View TITEL transparent arbeiten
• Ohne Kenntnis über deren Entstehung (BUCH + AUTOR)
• Ohne Kenntnis über die Namen/Schemata der Basistabellen
• Tatsache, dass er mit einer Sicht und nicht mit einer Basistabelle
arbeitet, kann ihm sogar verborgen bleiben / egal sein
- Basistabellen können sich strukturell ändern
• Ohne Beeinflussung der Sicht und damit des Benutzers
• Lediglich Sichtdefinition (CREATE VIEW ...) muss eventuell vom
Anwendungsadministrator angepasst werden
- Kritisch ist das allerdings das View-Update-Problem
• Änderung der in Sichten enthaltenen Daten
• Semantik bzw. Rückabbildung auf Basistabellen teilweise unklar oder
sogar unmöglich
• Beispiel: Änderung berechneter Attribute ("Durchschnittsgehalt")
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 40
1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS
 Internes Schema = physische Realisierung
- Schneller wahlfreier und auch sortierter Zugriff auf AUTOR über
Spalte/Attribute "Name" erforderlich
• Realisierung über B*-Baum
• SQL-Anweisung:
CREATE INDEX Beppo
ON AUTOR (Name)
Beckstein
4242
1
Winkler
Küspert
Winkler
3745
3745
1
2
Beckstein
Küspert
- Schneller wahlfreier Zugriff auf BUCH über "ISBN" erforderlich
• Realisierung über B*-Baum oder Hashtabelle (nur wahlfrei nötig)
• SQL-Anweisung:
1. Ich brauche
CREATE UNIQUE INDEX Hugo
schnellen Zugriff ...
2. ISBNs auf BUCH
ON BUCH(ISBN)
eindeutig
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 41
1.7.3 DIAM-Modell
 DIAM = Data Independent Accessing Model
- Entwickelt von Michael Senko, IBM San Jose/Californien, 1973
 Ursprünglicher Ansatz umfasst 4 Ebenen (später erweitert):
- Entity set model: logische anwendungsneutrale Datenstrukturen
- "String model": logische Zugriffspfade (Indexe)
- Encoding model: Speicherungsstrukturen, physische Zugriffspfade
- Physical device model: Speicherzuordnungsstrukturen
 Erläuterungen zu den einzelnen Ebenen
- Entity set model
• Entität ist ein Ding/Objekt der realen Welt, das es in der Datenbank
darzustellen/zu verwalten gilt (zu modellierende Informationseinheit)
• Auf oberster Ebene des 4-Schichten-Modells werden also
"Objektmengen" (Entitätsmengen) dargestellt und vom DBVS
verwaltet
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 42
1.7.3 DIAM-Modell
- String model (nicht so arg „treffender Begriff“)
• DBVS kennt hier logische Zugriffspfade; Bsp: Index auf Attribut
PNR, die Datensätze sind intern nach ANR sortiert abgelegt, ...
• Realisierung der Zugriffspfade/exakte Datensatzformate dagegen
hierbei uninteressant
- Encoding model
• Art, wie die Daten "kodiert" sind, d.h. physische Speicherdarstellung
• Bsp: Index auf PNR ist B*-Baum mit fest langen Einträgen zu jeweils 4
Bytes, die Felder eines Datensatzes sind fortlaufend gespeichert,
variabel langen Feldern geht jeweils ein 2-Byte-Längenfeld voran, ...
- Physical device model
• Datenzuordnung zum Dateisystem/Magnetplatte
• Bsp: Tabelle Personal steht in Datei xyz auf Platte D001, Index
Personal PNR ebenso, ...
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 43
1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur)
WIE
prozedural
deskriptive, mengenorientierte Schnittstelle
(z.B. SQL)
Anfrageübersetzung/-optimierung
Query Optimizer
Zugriffspfadauswahl
Zugriffskontrolle/Integritätskontrolle
FINDE nächsten Satz
SPEICHERE Satz (log.)
Zugriffssystem
satzorientierte
Schnittstelle (log.)
Katalogverwaltung
Sortierkomponente
Sperrverwaltung
SPEICHERE internen Satz
FÜGE Eintrag im B*-Baum ein
Speichersystem
interne Satzschnittstelle (phys.)
Record Manager
Zugriffspfadverwaltung
Logging/Recovery (Fehlerbeh.komp.)
BEREITSTELLEN Seite j
FREIGEBEN Seite j
Pufferverwaltung
Systempufferschnittstelle
Systempufferverwaltung (Buffer Manager)
Betriebssystem/
Dateiverwaltung
Dateischnittstelle
LIES Block k
SCHREIBE Block k
Externspeicherverwaltung/Dateiverwaltung
Härder/Rahm 2001
Datenbanken und Informationssysteme
DB
Friedrich-Schiller-Universität Jena
Datenbank-Verwaltungssystem
SELECT . . .
FROM . . . WHERE
Datensystem
Betriebssystem/
Dateisystem
Anwendungsprogramme/Benutzer
deskriptiv
WAS
Anwendung
 Weiterentwicklung von DIAM am Beispiel eines relationalen DBS
Seite 44
1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur)
 Die vorgenannte Architektur ist eine mögliche Architektur für rel. DBS
- So oder in ähnlicher Form in den meisten Produkten anzutreffen
- "Erfunden“ worden im System R Projekt (IBM San Jose, 70er Jahre)
 Datensystem
- "Übersetzung" (Kompilation oder Interpretation) der deskriptiven,
mengenorientierten Datenbankanweisung in einen prozedural
abzuarbeitenden Ablaufplan
- Bestimmung des optimalen Ablaufplans, Gesamtkosten = f (CPU-ZeitBedarf + E/A-Aufwand) unter Einbeziehung von Zugriffspfaden
- Zugriffs- und Integritätskontrolle (soweit ohne Datenzugriff machbar)
 Zugriffssystem
- Verwaltung des Datenbankkatalogs ( Metadaten), Ausführung von
Sortiervorgängen (falls in Anfrage gefordert oder intern empfehlenswert)
- Kontrolle des Mehrbenutzerbetriebs (Sperrverwaltung, „concurrency
control“)
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 45
1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur)
 Speichersystem
- Verwaltung von Datensätzen mit Abbildung in "Container" (sogenannte
DB-Seiten) sowie von Zugriffspfaden (B*-Bäume, Hashtabellen)
ebenfalls mit Abbildung in DB-Seiten
- Treffen von Vorkehrungen für den Fehlerfall / Ermöglichen des
Wiederanlaufs unter Konsistenzgesichtspunkten (Logging/Recovery)
 Systempufferverwaltung
- Realisierung eines Datenpuffers (Systempuffer, Cache) im Speicher des
Verarbeitungsrechner
- Ziel: Plattenzugriffe möglichst zu vermeiden (Zeit für Plattenzugriffe liegt
im ms-Bereich  4-5 Zehnerpotenzen teurer/langsamer als Datenzugriffe
im internen Speicher)
- Schreiben von Daten auf die Platte via Dateisystem veranlassen
 Externspeicher-/Dateiverwaltung
- Teil des Betriebssystems, Funktionalität bekannt
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 46
2. Datenmodellierung mit ERM
 Motivation für Datenmodellierung
 Begriffsklärung
 Kardinalität/Komplexität von Beziehungstypen
 Erweiterungen des E/R-Modells
 Darstellung von Attributen/Beziehungen als Entitytypen
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 47
2.1 Motivation für Datenmodellierung
 Zielsetzung dieses Kapitels:
- Einführung von Begriffen wie Entity, Entitytyp, Wertebereich, Attribut,
Schlüssel(-kandidat), Beziehung, Beziehungstyp, Kardinalität von
Beziehungstypen
- Einführung von E/R-Diagramm, d.h. der graphischen Darstellungsform
von E/R-Modellen: Verstehen/Lesen von Syntax und Semantik
- Verdeutlichung anderer E/R-Modellierungsmethodiken (erweiterte E/RModelle, semantische Datenmodelle)
 Literatur zur Modellierungsmethodik:
- P.P.Chen: The Entity-Relationship Model - Toward a Unified View of Data.
ACM Transactions on Database Systems (TODS), Bd. 1, Nr. 1, März
1976, S. 9-36 (Original vom "Erfinder" der Modellierungsmethodik, auf
DBIS-Website verlinkt)
- Praktisch in jedem Datenbanklehrbuch, "Urschleim" der DB-Forschung
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 48
2.1 Motivation für Datenmodellierung

Wozu Modellierung auf abstrakter Ebene statt direkt in der Datenbank?

E/R-Modellierung vs. relationale Tabellendarstellung
- E/R-Modell unabhängig von späterer Umsetzung im konkreten
Datenbankmodell (relational, hierarchisch, ...) und erst recht konkreten
Datenbanksystem (DB2, Oracle, ...)  Flexibilität/Portabilität
- E/R-Modell leichter verständlich/übersichtlicher, auch wegen
graphischer Notation, als z.B. relationale (tabellarische) Darstellung
- Mehr Semantik in offensichtlicher Weise im E/R-Modell darstellbar
(Entity-Typen, Beziehungstypen, Kardinalitäten ...), in relationalem
Modell teils nur "auf Umwegen" möglich (siehe auch nächste Folie)
- E/R-Modell kann viel besser als relationales Modell ("Tabellensammlung") Gesprächsgrundlage zwischen Anwendern/Fachabteilung
und Informatikern bilden
• "anwendungsnah und trotzdem schon nah an der Datenbank"
• hängt natürlich mit vorangegangenen Eigenschaften zusammen
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 49
2.1 Motivation für Datenmodellierung
 Beispiel für ein E/R-Modell, Ausschnitt aus der realen Mini-Welt
- Darstellung von Entitytypen, Attributen und Beziehungen
- Unvollständige Beziehungstypen (fehlende Kardinalitäten)
Titel
Professor
liest/wird
gelesen
Zeitplan
Vorlesung
Name
Fach
Telefon#
Semester
empfiehlt/wird
empfohlen zu
Autor
Titel
Buch
ISBN
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 50
2.1 Motivation für Datenmodellierung
 Hinweis für die Verwendung:
- E/R-Modell in Realität andere Dimensionen ("Tapeten")
- Datenbanksysteme unterstützen in aller das Regel E/R-Modell nicht
direkt ("E/R-Sprache" als Datenbanksprache)
- Umsetzung des E/R-Modell in konkretes Datenbankmodell erforderlich
 Relationales Modell "war schon da", als das E/R-Modell Mitte der 1970er
erfunden wurde
 "E/R-Sprache" unter Umständen schwierig zu erlernen, da komplex
 Allerdings: Forschung hat in vielfältiger Weise "E/R-Sprachen" vorgeschlagen
(meist sogar für erweitertes E/R-Modell)
- selten (prototypisch) implementiert
- noch seltener in Produkten realisiert
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 51
2.2 Begriffsklärung
 Entity / Entitytyp
- Attribute
- Attributwerte/Domänen
 Schlüssel
- Schlüsselkandidaten
- Künstliche Schlüssel
 Beziehung / Beziehungstyp
- Kardinalität/Komplexität
- Notationsformen
 E/R-Diagramm
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 52
2.2.1 Entity/Entitytyp
 Definition nach A. Meier [Relationale Datenbanken (1995), S. 14]:
- "Unter Entität (engl. entity) versteht man ein bestimmtes, d.h. von
anderen wohlunterscheidbares Objekt der realen Welt oder unserer
Vorstellung. Dabei kann es sich um ein Individuum, einen Gegenstand,
um einen abstrakten Begriff oder um ein Ereignis handeln."
- Entitäten werden zu Entitätstypen (entity types) zusammengefasst
- Entitytyp E = Menge aller möglichen Entities e mit gleichen
charakteristischen Merkmalen
 Beispiele:
- Angestellter Meier und Müller sind Entities mit gleichen Merkmalen (PNr,
Name, Vorname, Anschrift, ...)  Entitytyp ANGEST für die Menge aller
möglichen Angestellten (Individuen)
- Entitytypen ABTEILUNG (Abstrakter Begriff), GEBÄUDE (Gegenstand)
 Verschiedene Entitytypen müssen inhaltlich nicht unbedingt disjunkt sein
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 53
2.2.1 Entity/Entitytyp
 Entitytypen besitzen Attribute, d.h. dem Entitytyp E wird eine nichtleere,
endliche Attributmenge A zugeordnet (E:A)
- Allgemein: A = {a1, a2, a3 ..., an}, n endlich (n1), ai sind die Attribute
- Bsp: ANGEST:{PNR, NAME, VORNAME, GEHALT, ANR ...}
 Einzelnem Entity e sind entsprechende Attributwerte zugeordnet
- Auf der Entityebene (Ausprägungsebene) beschreiben die Attributwerte
das Entity
- Bsp: Meier:{17, Meier, Alfons, 5000, 4 ...}
 Jedem Attribut a ist ein Wertebereich (Domain, Domäne) zugeordnet, der als
dom(a) bezeichnet wird
- Wertebereichsdefinitionen stellen (einfache) semantische
Integritätsbedingungen dar
- Bsp: dom(PNR) = INTEGER; dom(GEHALT) = {g | 1000g10000}
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 54
2.2.2 Schlüssel
 Ziel: Eindeutige Identifizierung eines Entity e innerhalb seines Entitytyps E,
also innerhalb der möglichen Entities gleichen Typs
- Allgemein:
• Gegeben ist E:A
• Gesucht ist Schlüssel KA, K nicht leer, so dass die Schlüsselattributwerte ein Entity eindeutig identifizieren
- Beispiel:
• ANGEST:{PNR, NAME, VORNAME, GEHALT, ANR}
• K={PNR} d.h. Personalnummer identifiziert ein Entity, wenn die
Personalnummer eindeutig im gesamten Unternehmen ist!
• K={PNR, ANR} als zweiattributiger Schlüssel, wenn Personalnummer
nicht unternehmensweit eindeutig ist, aber innerhalb einer Abteilung
 Schlüsseleigenschaft für eine Attributmenge
- Entscheidung darf nicht aufgrund konkreter Entities getroffen werden
- Festlegung "zukunftssicher" anhand der Semantik des Entitytyps
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 55
2.2.2 Schlüssel
 Forderung nach Schlüsselminimalität, d.h. K'K : K' Schlüssel
- Schlüsselkandidaten = alle Schlüssel mit dieser Eigenschaft
- Primärschlüssel = Festlegung auf einen der Schlüsselkandidaten,
beispielsweise aufgrund der Bedeutung (Bsp: PNr vs. SVNr)
 Verwendung künstlicher Primärschlüssel häufig anzutreffen
- Sind keine "natürlichen Attribute" von Entitytypen
- Beispiel: Personalnummer, Auftragsnummer, Teilenummer
- Gründe für die Einführung:
• "natürlicher" Schlüssel existiert nicht oder setzt sich aus sehr vielen
Attributen zusammen, Kompaktheit und "Handlichkeit" erwünscht,
Bsp: {NAME, VORNAME, GEBURTSDATUM, GEBURTSORT ...}
• "natürlicher" Schlüssel existiert aus heutiger Sicht, aber es fehlt die
Zukunftssicherheit, Bsp: {NAME, VORNAME} in "5-Mann-Firma"
• Schlüssel soll auch als Medium für Referenzierung zwischen Entities
benutzt werden  kompakter Schlüssel wichtig
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 56
2.2.3 Beziehungstypen
 Definition:
- Beziehungen r (relationships) bestehen zwischen einzelnen Entities e
und e' verschiedener oder gleicher Entitytypen E und E'
- Beziehungstyp R (relationship type) ist die Menge aller möglichen
Beziehungen r zwischen je einem Entity ei der Entitytypen Ei (i = 1,...,k)
• R = E1 × E2 × ... × Ek (kartesisches Produkt)
• R = {r = (e1, e2,...,ek) | e1є E1,...,ekєEk }
- Beziehungstypen können k-stellig sein (k2), Stelligkeit heißt grad(R)
- Beziehungstypen/Beziehungen können Attribute/Attributwerte besitzen
 Hinweis für die Ablage in der Datenbank
- Nur die tatsächlich vorhandenen Entitymengen (ES = entity set) und
Beziehungsmengen (RS = relationship set) sind von Interesse
- ES und RS sind endliche Untermengen von E bzw. R:
• entity set:
ES  E
• relationship set: RS  R
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 57
2.2.3 Beziehungstypen
 Beispiel:
- Menge der Entitytypen
• ANGEST (Angestellte)
• PROJ (Projekte)
• MATERIAL (Materialien)
• LIEFERANT (Lieferanten)
- Mögliche 2-stellige Beziehungstypen:
• Beziehung r1, wenn ein Angestellter a an einem Projekt p arbeitet:
r1 = ARBEITET_AN = ANGEST × PROJ
• Beziehung r2, wenn ein Angestellter a Chef von Angestelltem a' ist:
r2 = IST_CHEF = ANGEST × ANGEST
- Möglicher 3-stelliger Beziehungstyp:
• Beziehung r3, wenn ein Lieferant l ein Material m zum Projekt p liefert:
r3 = LIEFERT = LIEFERANT × MATERIAL × PROJ
- Mögliche Attribute an Beziehungstypen:
• ARBEITET_AN (r1): ZEITLICHER_ANTEIL
• IST_CHEF (r2): SEIT
• LIEFERT (r3): MENGE, PREIS (z.B. für konkrete Lieferung)
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 58
2.2.3 Beziehungstypen
 1:1-Beziehungstyp (1:1 relationship type)
- Jedem Entity aus Entitytyp E1 ist eineindeutig ein Entity aus Entitytyp E2
über den Beziehungstyp R zugeordnet
- Beispiel für E1 = ANGEST, E2 = PERSONALAKTE, R = HAT
ANGEST
Entities
a1
a2
a3
a4
a5
a6
HAT
r1
PERSONALAKTE
Beziehungen
r2
r3
r4
r5
Entities
p1
p2
p3
p4
p5
p6
r6
entity set
entity set
relationship set
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 59
2.2.3 Beziehungstypen
 n:1-Beziehungstyp (n:1 relationship type)
- Jedem Entity aus Entitytyp E1 ist eindeutig Entity aus Entitytyp E2 über
den Beziehungstyp R zugeordnet, Rückrichtung ist nicht eindeutig!
- Beispiel für E1 = ANGEST, E2 = ABTEILUNG, R = ARBEITET_IN
ANGEST
Entities
a1
a2
a3
a4
a5
a6
a7
entity set
Datenbanken und Informationssysteme
ARBEITET_IN
r1
ABTEILUNG
Beziehungen
r2
r3
r4
Entities
d1
d2
d3
d4
r5
r6
relationship set
Friedrich-Schiller-Universität Jena
entity set
Seite 60
2.2.3 Beziehungstypen
 n:m-Beziehungstyp (n:m relationship type, many-to-many relationship type)
- Jedes Entity aus Entitytyp E1 kann beliebig vielen (0,...,m) Entities aus
Entitytyp E2 über den Beziehungstyp R zugeordnet sein
- Beispiel für E1 = ANGEST, E2 = PROJ, R = ARBEITET_AN
ANGEST
Entities
a1
a2
a3
a4
a5
a6
a7
entity set
Datenbanken und Informationssysteme
ARBEITET_AN
r1
r2
r3
r4
r5
r6
r7
r8
r9
r10
PROJ
Entities
Beziehungen
relationship set
Friedrich-Schiller-Universität Jena
p1
p2
p3
p4
p5
entity set
Seite 61
2.2.3 Beziehungstypen

Integritätsregeln für Beziehungstypen/-mengen
- Von jeder Beziehung ri geht genau eine Kante aus beim 2-stelligen
Beziehungstyp "nach links und nach rechts", da ri = (ej, ek)
- Nicht von jedem Entity e muss eine Kante ausgehen innerhalb eines
bestimmten Beziehungstyps R, dann steht e aktuell (für diesen
Beziehungstyp R!) in keiner Beziehung r zu einem e'
• Bsp: Angestellter ai arbeitet an keinem Projekt
• Bsp: Projekt pi hat keine Mitarbeiter
- Mehrere Beziehungen ri innerhalb einer Beziehungsmenge RS zwischen
gleichen Entitäten in ES1 und ES2 sind verboten!
• Mengeneigenschaft von RS wäre verletzt, weil r1 = (e, e') = r2
• Sachverhalt wäre zweimal dargestellt (Redundanz unerwünscht!)
r1
e
r2
RS

e'
ok
r1´
RS'
r2 ´
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 62
2.2.3 Beziehungstypen
 Bemerkungen zu mehrstelligen Beziehungstypen (k 3)
- Bsp: Lieferant l1 liefert Artikel a1 für Projekt p1
LIEFERT
LIEFERANT
relationship set
Entities
l1
l2
l3
l4
entity set
r3
r1
r2
Beziehungen
PROJ
Entities
p1
p2
p3
unzulässig
Entities
a1 a2 a3
ARTIKEL
entity set
entity set
- Information, welche Artikel ein Lieferant liefert (projektübergreifend), ist
implizit enthalten und braucht nicht zusätzlich dargestellt werden
• LIEFERT' = ARTIKEL × LIEFERANT möglich, aber redundant
• LIEFERFÄHIGKEIT = ARTIKEL × LIEFERANT notwendig, um
anderen Sachverhalt darzustellen ("Artikelkatalog" eines Lieferants)
Datenbanken und Informationssysteme
Friedrich-Schiller-Universität Jena
Seite 63