Datenbank - WINFOR

2 Datenbanksysteme 

Im Folgenden werden wir einige grundlegende 

Eigenschaften von Datenbanksystemen kennen lernen 

Datenbanken sind Bestandteil vieler 

Anwendungssysteme; sie stellen die dort benötigten 

Daten bereit 

Aufbau des Abschnitts 

Definition grundlegender Begriffe 

Datenmodelle 

Relationale Datenmodelle 

Entwurf einer Datenbank 

Wirtschaftsinformatik und Operations Research 40 

2.1 Grundlegende Begriffe 

Eine Datenbank ist eine Ansammlung verwandter 

Fakten, die Bedeutung haben und gespeichert werden 

können; dies sind die Daten 

Die Daten sind zusammenhängend und haben 

anhaltend Bedeutung 

Die Daten werden angelegt, gepflegt und in einer 

speziellen Struktur gehalten 

Die Daten dienen bestimmten Anwendungen und 

besitzen so eine Gruppe von gezielten Benutzern 

Dies ist allerdings keine eindeutige Definition sondern 

lediglich eine charakterisierende Beschreibung von 

bestimmten Eigenschaften 

Wirtschaftsinformatik und Operations Research 41

Schemata und Instanzen 

Unter einem Schema (oder auch Meta Daten) einer 

Datenbank versteht man die Beschreibung der 

Struktur der dort zu speichernden Daten 

Unter den Ausprägungen dieser Datenbank versteht 

man die konkreten Datenbestände, die in der 

Datenbank gespeichert sind 

Die konkreten Datenbestände werden auch Zustand 

einer Datenbank genannt 

Somit führen offensichtlich Veränderungen dieser 

Datenbestände zu neuen Zuständen der Datenbank 


Datenbank Management System 

Sammlung von Programmen, die es ermöglichen eine Datenbank zu erstellen und 

aufrecht zu erhalten 

DB Sprache für Operationen auf Datenbeständen 

Universell und anwendungsunabhängig 

Sichert Konsistenz der Daten 

Sichert Synchronisation 

Bietet standardisierte Schnittstelle 

Dabei wird unterstützt 

Definition der Datenbank 

Festlegung der Datenstrukturen und 

Bedingungen der Datenspeicherung 

Manipulation der Datenbank 

Auslesen und 

Veränderung der Datenbestände 

Konstruktion der Datenbank 

Abspeicherung der Datenbestände 

Allgemein dienliche und einsetzbare Software 

Sie ist nicht erforderlich, um eine Datenbank zu verwalten, sondern man kann auch 

eigen entwickelte Software benutzen 


Datenbank 

Die Datenbank besteht aus 

Datenausprägungen (den eigentlichen Daten) 

und Datenbeschreibungen (den Meta Daten, d.h. dem 

Datenbank Schema) 

Sie stellt den integrierten Datenbestand anhand eines 

einheitlichen Datenmodells geordnet dar 

Das heißt man unterscheidet 

Die Datenbank Definition 

und die dort gespeicherten eigentlichen Daten 


Datenbanksystem 

Besteht aus einem Datenbankmanagementsystem und der Datenbank 

Schematisch 

Datenbanksystem 

Benutzer / Programmierer 

Programme 

/ Anfragen 

DBMS 

Verwaltet Programme und Anfragen und greift auf Daten zu 

Dazu unterscheidet man Software zur Anfragebearbeitung und zum 

eigentlichen Zugriff auf die Daten 


Daten und Meta Daten 


Warum gibt es Datenbanksysteme? 

Für die Beantwortung dieser wichtigen zentralen 

Frage wollen wir im Folgenden einen kurzen Einblick 

in die Entwicklungsgeschichte von 

Datenbanksystemen erarbeiten 

Hieraus wird schnell deutlich, 

welche Vorteile Datenbanksysteme dem Nutzer 

bereitstellen 

und welche Nachteile vorangegangener Systeme zu 

ihrer Entwicklung geführt haben 


2.1.1 Entwicklungsgeschichte I 

Stufe 1: Elementare Dateien 

Datenhaltung um 1960 

Anwendungen halten eigene Daten in Dateiform mit individueller 

Struktur 

Anwendungssysteme führen den Datenzugriff bis ins kleinste 

Detail selbst durch 

(Schwacher) Vorteil 

Schnelle Speziallösungen sind möglich 

Nachteile 

Inkonsistenz der Datenbestände kann durch unterschiedliche 

Dateien und ihrer Modifikation entstehen 

Redundanz 

Geräteabhängigkeit der Anwendungssysteme 

„Extreme Expertenmacht“ kann entstehen 


Entwicklungsgeschichte II 

Stufe 2: Dateiverwaltungssysteme 

Datenhaltung um 1965 

Anwendungen halten auch hier eigene Daten in Dateien mit individueller 

Struktur 

Anwendungssysteme führen den Datenzugriff einheitlich mit Hilfe bestehender 

Betriebssystemroutinen durch 

Erreichter Vorteil 

Geräteunabhängigkeit wird nun erreicht 

Nachteile 

Abhängigkeit von den Speicherstrukturen 

Betriebssystem liefert lediglich unspezifizierte Sätze zurück 

Genaue Formatierung der Sätze muss das Anwendungssystem, d.h. der 

Anwender/Programmierer übernehmen 

Inkonsistenz der Datenbestände kann durch unterschiedliche Dateien und ihrer 

Modifikation entstehen 

Redundanz 

Alle Update Operationen muss das Anwendungssystem in ihrem 

Funktionsumfang und zeitlichen Verhalten selbst individuell festlegen 

Bei Strukturanpassungen sind diese Operationen mit zu ändern 


Entwicklungsgeschichte III 

Stufe 3: Datenbanksysteme 

Datenhaltung ab 1975 

Anwendungssysteme führen den Datenzugriff über Datenbanksysteme 

durch 

Dabei entsteht eine einheitliche Benutzungsschnittstelle zwischen 

Anwendung und dem Datenbankmanagementsystem 

Erreichter Vorteil 

Keine oder nur gewollte Redundanz 

Zentrale Kontrolle der Benutzung und Art der Veränderung 

Anwendung arbeitet Datenunabhängigkeit, d.h. es erfolgt kein direkter 

Zugriff mehr auf untere Schichten (direkt auf die Daten und ihre 

Strukturen) 

Nachteile 

Durch zentrale Datenhaltung rückt das Thema „Datenschutz“ als neues 

Problem in den Mittelpunkt der Betrachtung 

Durch zentrale Datenhaltung sind spezielle Probleme bei erforderlichen 

Zugriffsgeschwindigkeiten zu berücksichtigen 


Leistungen von Datenbanksystemen 

Integration der Datenbestände 

Alle Daten werden zentral an einer Stelle einheitlich abgelegt und 

verwaltet 

Angebot an vordefinierten standardisierten Operationen zur 

Datenvisualisierung und ‐verarbeitung 

Beschreibung von Datenbeständen (Definition der 

Datenbestände sind ebenfalls veränderbar) 

Benutzersichten 

Jeder Benutzer kann eine eigene Sicht auf Daten erhalten 

D.h. er erhält als Mitglied einer Gruppe Zugriff auf bestimmte 

Teile der gesamten Datenbank 

Konsistenz und Integritätsüberwachung 

Korrekte Datenbank Inhalte und Veränderungen werden 

ermöglicht 

Keine Überprüfung durch Anwendungen notwendig 


Leistungen von Datenbanksystemen 

Datenschutz durch die Verwaltung von Zugriffsrechten 

Transaktionsmanagement 

Zusammenfassung von zusammengehörigen Aktionen zu einer 

unteilbaren Einheit 

Ermöglicht eindeutige Ergebnisse von Update Operationen 

Synchronisation 

Koordination von konkurrierenden Zugriffen 

D.h. Verwaltung gleichzeitiger Transaktionen mehrerer Benutzer 

auf die vorhandenen Datenbestände 

Datensicherung 

Laufende Datensicherung 

Wiederherstellung der Datenbestände nach Systemfehlern 

Unabhängigkeit zwischen Daten und Programmen (Bei OO 

Datenbanken zudem Programm und Methoden) 


2.1.2 Datenbankbenutzer 

Datenbank Administrator (DBA) 

Verantwortlich für Entwurf, Überwachung und Anpassung eines 

Datenbanksystems 

Damit ergeben sich die grundlegenden Aufgaben 

Definition der konzeptionellen / externen / internen Schemata 

(siehe unten) 

Datenschutz 

Leistungsüberwachung (ggf. Änderungen des internen Schemas) 

Überwachung der Anforderungen (ggf. Änderungen des externen 

Schemas) 

Betreuung/Verwaltung von Benutzern 

Datenbank Designer (DBD) 

Sammelt bei der Entwicklung der erforderlichen Schemata 

Informationen 

Unterstützt den Datenbank Administrator 


Datenbankbenutzer – Fortsetzung 

System Analyst 

Analyse von Anforderungen der Anwendungsseite 

Bereitet Spezifikation für Anwendungsprogramme vor 

Anwendungsprogrammierer 

Entwickeln Anwendungsprogramme mit Datenbank Zugriffen 

Nutzt Spezifikation der System Analysten 

Hardware/Software Spezialisten 

Sorgen für lauffähige Gesamtsysteme 

Haben aber keine direkten Datenbankaufgaben 

End Benutzer 

Gehobene 

Datenbank Anfragen auf der Basis prozeduraler Sprachen 

Ggf. mit Sonderrechten 

Einfache Benutzer 

Tätigen meist Standardanfragen 

Nutzen ggf. als valide eingestufte Standardprogramme 


2.1.3 Drei Schemata Architektur 

Ziel: Strikte Trennung der Anforderungen und 

Anwendungen der Benutzer von der physikalischen 


Daher finden sich Schemata auf insgesamt drei 

verschiedenen Ebenen 

Man unterscheidet 

Das interne Level (mit dem internen Schema) 

Das konzeptionelle Level (mit dem konzeptionellen 

Schema) 

Das externe Level (mit den externen Schemata (auch 

externe Sichten Views genannt)) 

Endbenutzer 

Externes Level 

Konzeptionelles 

Level 

Internes Level 

Physische 

Hardwareebene 

Benutzergruppe 1 

Externe Sicht 1 

Bei Anfragen 

erfolgt durch 

das DBMS eine 

schrittweise 

Umsetzung 

in das jeweils 

tiefere Schema 


Gesamtaufbau 

Konzeptionelles 

Schema 

Internes 

Schema 


Benutzergruppe n 

Externe Sicht n 

Bei Antworten 

erfolgt durch 

das DBMS eine 

schrittweise 

Umsetzung 

in das jeweils 

höhere Schema 


Datenunabhängigkeit 

Prinzip besteht darin, jeden Benutzer bei Veränderungen nur 

minimale Auswirkungen spüren zu lassen, d.h., Auswirkungen 

tieferer Ebenen, die ihn/sie im Prinzip auch betreffen würden, 

sollen nicht weitergegeben werden 

Wir unterscheiden im Folgenden 

Physische Datenunabhängigkeit 

Stabilität der konzeptionellen Ebene gegenüber Änderungen der 

Dateiorganisation oder der angewendeten Zugriffsverfahren, 

d.h. eine Veränderung im internen Schema hat keine Auswirkungen 

auf die konzeptionelle Ebene 

Logische Datenunabhängigkeit 

Stabilität der Benutzungsschnittstelle gegenüber Veränderungen 

der Datenstrukturen auf der konzeptionellen Ebene 

D.h. eine Veränderung im konzeptionellen Schema hat keine 

Auswirkungen auf die externen Sichten (Ausnahme sind allerdings 

z.B. Löschungen) 


Datenbank Sprachen 

DDL=Data Definition Language 

Konzeptionelles Schema wird hierdurch festgelegt 

Schnittstellen zum Internen Level 

SDL=Storage Definition Language 

Definiert internes Level 

VDL=View Definition Language 

Definiert externe Sichten für bestimmte Benutzergruppen 

Schnittstellen zum konzeptionellen Level 

DML=Data Manipulation Language 

Dient zur Formulierung von Benutzeranfragen 


Low level prozedural 

– Diese Sprachen greifen nur einzeln auf Einträge in der Datenbank zu (record at a time) 

– Müssen für aufwändigere Operationen in Hochsprachen eingebunden werden 

High level prozedural 

– Können bereits komplexere Auswertungen (set at a time) (z.B. SQL) 

– Brauchen nicht eingebunden zu werden 


Folgerung 

Datenbank Administratoren nutzen spezielle Arten 

von 

DDL 

SDL 

VDL 

End Benutzer nutzen spezielle Arten von 

DML 


2.1.4 Design Prozess der Datenbank 

Phase 1 

Anforderungsanalyse 

Hieraus entstehen Anforderungen an die Daten und ihren Aufbau 

Anforderungen hinsichtlich der Zugriffe 

Phase 2 

Entwicklung des konzeptionellen Designs mit Hilfe eines Meta 

Datenmodells 

Dieses ist DBMS unabhängig 

Zudem gilt, dass das konzeptionelle Design ungleich dem 

konzeptionellen Schema ist 

DBMS unabhängige Beschreibung der Zugriffe der 

Anwendungsprogramme 

Phase 3 

Wahl des Datenbanksystems (DBMS+DB) 

D.h. Datenbanktyp (Relational, OO, …), Wahl der Query Language, Wahl 

der zusätzlichen Software 

Beachte: Alle bisherigen Schritte (1‐3) waren DBMS unabhängig 


DBMS abhängige Phasen 

Phase 4 

Entwicklung des logischen Designs 

Bestimmung des konzeptionellen und des externen Schemas 

Phase 5 

Festlegung des physikalischen Designs 

Ermittlung des internen Schemas 

Phase 6 

Implementierung des Systems 

SDL+VDL+DDL Statements für die Festlegung des konzeptionellen, des externen 

und des internen Schemas 

Für die Anwendungssysteme werden zur Ausgestaltung der Anfrageroutinen 

Hilfsprogramme in DML + Host Language implementiert 

Phase 7 

Laufender Betrieb 

Überwachung & Anpassung 

Performancemessungen & Befragungen von Mitarbeitern 

Diese Schritte sind nun abhängig von einem gewählten Datenbanksystem 


2.2 Datenmodelle 

Dienen zur Beschreibung von Daten und ihrer Strukturen 

Sie bestimmen 

Die Syntax (d.h. den Aufbau) und 

Die Semantik (d.h. die Interpretation) 

von Datenbank Schemata 

Wir vereinbaren 

μ: 

Menge aller möglichen Objekte und Wertebereiche, die die 

im Schema angegebenen Objekte und Datentypen annehmen 

können 

Σ: 

Menge von passenden DB Zuständen (d.h. gültigen Ausprägungen) 

σ∈Σ ist ein passender 

DB Zustand 


2.2.1 Ein Meta Modell: Das ER Modell 

Das ER heißt Entity Relationship Model 

Modellierungskonzepte 

Entitäten 

Das ER Modell geht von Entitäten aus, die die Basis des Modells 

darstellen 

Entitäten besitzen Eigenschaften (Attribute), die es beschreiben 

Attribute 

Eigenschaften die Entitäten beschreiben 

Eine einzelne Entität hat eine bestimmte Ausprägung für alle 

diese Attribute 


Einfache/zusammengesetzte Attribute 

Einwertige/mehrwertige Attribute 

Gespeicherte/ableitbare Attribute 


Objekttypen 

Ist ein Schema für Entitäten, d.h. es legt die Struktur von einer 

Gruppe von Entitäten fest 

D.h. die Entitäten haben dann eine bestimmte Struktur in Form 

von identischen Attributen (d.h. natürlich nicht, dass die Werte 

identisch sind) 

Für einen Objekttyp E gilt dann allgemein 

μ(E): Menge aller möglichen Objekte vom Typ E 

σ(E): Menge der aktuellen Objekte vom Typ E im Zustand σ 

⊆ 

(d.h. σ(E) μ(E)) 

Falls also e ein Objekt vom Typ E im Zustand σ ist, dann gilt 

e ist Element von σ(E) 

Ein Objekttyp E kann ein Schlüsselattribut besitzen, 

welches einen unterschiedlichen Wert für alle Entities 

vom Typ E besitzt und somit das einzelne Objekt 

eindeutig identifiziert 

Es können auch mehrere Schlüsselattribute sein 


Attributstypen 

Ein Attributstyp A ist eine Abbildung von einem dazugehörigen 

Entitätstyp E in einen dazugehörigen Datentyp D (bei 

mehrwertigen in die Potenzmenge von D) 

Beispiel: 

Entitätstyp: Angestellter 

Attributstyp: Name 

Abbildung für jede zugehörige Entität in den Datentyp D 

Wertebereich ist damit der Datentyp String 

Statt A 1:E→D 1, …, A n:E→D n 

schreiben wir einfach E(A 1 ,…,A n ) 

Die Datentypen D 1 ,…,D n sind dabei entweder 

Mengen 

Potenzmengen oder 

Kartesische Produkte von Mengen und/oder Potenzmengen 


n stelliger Beziehungstyp 

Ein n stelliger Beziehungstyp R von n Objekttypen E 1,…,E n ist eine Relation 

über E 1,…,E n 

Es gilt somit 

( ) 

R E ,...,E ⊆ E × E × ... × E 

1 n 1 2 

n 

d.h. für einen konkreten Zustand σ 

( R) ( E ) ( E ) ... ( E ) 

σ ⊆σ ×σ × ×σ 

1 2 

Gibt es innerhalb eines Beziehungstyps Entitäten, die mehrfach 

vorkommen, nennt man diesen Beziehungstyp rekursiv 

Die Kardinalität eines Objekttyps innerhalb eines Beziehungstyps ist die 

Anzahl von Beziehungen dieses Beziehungstyps in der ein Objekt des 

betrachteten Objekttyps stehen kann 


1: Kann nur in einer Beziehung dieses Typs stehen 

N: Kann in mehreren Beziehungen dieses Typs stehen 

n 


Beispiel 

Miniwelt: Schule 

Objekttyp 1: Schulklasse 

Objekttyp 2: Schüler 

Beziehungstyp B: „Ist_in_Klasse“ 

Offensichtlich gilt 

Objekttyp 2 (Schüler) hat beim Beziehungstyp B die Kardinalität 

1 

Dies wird daraus deutlich, dass ein Schüler jeweils eindeutig 

einer Klasse zugeordnet ist 

Damit gilt, dass für den Beziehungstyp „Ist_in_Klasse“ jedes 

Element des Objekttyps 2 in maximal einem Element des 

Beziehungstyps B steht 


Weitere Vereinbarungen 

Sei B Beziehungstyp über die Objekttypen E 1 ,…,E n 

Dann heißt die Partizipation von E i in B 

total, falls alle Objekte vom Typ E i in B auftauchen, sonst 

partial 

Schwache Entitätstypen 

Sind Objekttypen ohne Schlüsselattribut 

Sie sind somit nicht identifizierbar 

Es existiert eine totale Partizipation dieses Objekttyps über einen 

anderen Entitätstyp 

Dieser andere Entitätstyp wird als Besitzer charakterisiert 

Zwei nicht unterscheidbare Objekte des schwachen Objekttyps 

können nicht dem gleichen Entitätstyp zugeordnet werden 

Hier gibt es eine 1:X Beziehung 


1:N 

Person 

Darstellungen 

Entitätstyp 

Schwacher Entitätstyp 

Relationstyp 

Identifizierender Relationstyp 

Attribut 

Schlüsselattribut 

Mehrwertiges Attribut 

Zusammengesetztes Attribut 

Totalität 

Kardinalität 

Name Adresse 

Ort Straße 


Am Beispiel 

besitzt 

N 1 

PKW 

Seriennummer Typ 

Leistung 


2.2.2 Erweitertes Meta Modell: EER Modell 

Das ER Modell leistet wertvolle Dienste für die Entwicklung von 

konzeptionellen Datenbankmodellen 

Es ist leicht verständlich und sehr anschaulich 

Allerdings sind die einzelnen Konstrukte nicht sehr mächtig 

Hierdurch werden entsprechende Entwürfe sehr schnell sehr 

groß 

Dies widerspricht der Grundidee des Meta Modells 

So soll durch dessen Einsatz ja gerade die Anschaulichkeit des 

Entwurfs gesichert werden 

Anschließend ist dann eine Umsetzung in das Datenmodell des 

Datenbanksystems vorzunehmen 

Daher betrachten wir nun ein erweitertes Meta Modell 


EER Modell 

EER = „Enhanced Entity Relationship Model“ 

Beinhaltet erweiterte Konzepte 

Es gibt nicht das EER Modell sondern viele 

unterschiedliche Standards 

Im Folgenden wird daraus das Modell nach RONDO 

exemplarisch vorgestellt 

Es gibt keine Attribute oder Werte 

Man kennt nur noch Entitätstypen 

Man unterscheidet allerdings zwischen 

Atomaren Entitätstypen 

Abstrakten Entitätstypen 


Atomare Entitätstypen 

2.2.2.1 Entitätstypen 

Werden nicht definiert, sondern lediglich verwendet 

Können nur auf der untersten Ebene auftreten 

Gehen somit nicht aus einem Abstraktionsmechanismus hervor 

Abstrakte Entitätstypen 

Diese werden gesondert definiert und gehen aus den 

Abstraktionsmechanismen 

Attributsaggregation 

Beziehungsaggregation 

Generalisierung 

Gruppierung 

hervor 

Hierzu definiert man 

Definitionsebene 


Abstrakter Entitätstyp 

Hier wird der abstrakte Entitätstyp durch andere 

Entitätstypen (die so genannten Konstituenten) 

festgelegt 

Hierdurch entsteht die Struktur des Entitätstyps 

Verwendungsebene 

Auf dieser Ebene wird der Entitätstyp eingesetzt, d.h. 

verwendet 


Abstrakter Entitätstyp 

Atomarer Entitätstyp 

Schematische Darstellung 

Name 

Name 


2.2.2.2 Abstraktionsmechanismen 

Attribut‐Aggregation 



Gruppierung 


Attribut‐Aggregation 

Fasst eine Menge von abstrakten und/oder atomaren 

Entitätstypen zu einem neuen abstrakten 

Entitätstypen zusammen 

Gegenüber standardisierten ER Modellen ist die 

Verknüpfung über abstrakte Entitätstypen möglich, 

d.h. hierdurch sind rekursive Strukturen abbildbar 


Attribut‐Aggregation –Beispiel 

Postfach Straße 

Anschrift 

Ort 

PLZ Stadtname 


Eigenschaften der Konstituenten 

NICHT NULL 

Für jede Konstituente kann angegeben werden, ob dieser 

Bestandteil obligatorisch oder optional ist 

Eine NICHT NULL Markierung zeigt eine totale Beziehung seitens 

der Konstituente auf 

Gemeinsames Objekt 

Für jede Konstituente kann angegeben werden, ob eine Entität 

gemeinsam von mehreren Entitäten des aggregierten Typs 

verwendet werden kann 

Die Markierung „gemeinsames Objekt“ legt fest, dass die 

Beziehung zwischen aggregierten abstrakten Entität und ihren 

Konstituenten auf der Seite der aggregierten Entität eine „zu n“ 

Kardinalität hat 

Schlüsseleigenschaft 

Zusätzlich kann angegeben werden, welche Konstituenten den 

Schlüssel der aggregierten Entität bilden. Schlüssel müssen 

obligatorisch sein, d.h. die NICHT NULL Eigenschaften besitzen 



Die Beziehungsaggregation hebt eine Beziehung 

zwischen zwei Entitätstypen in den Stand eines 

Entitätstyps 

Dieser Entitätstyp wird als beziehungsaggregierter Typ 

bezeichnet 

Beziehungen können zwischen zwei abstrakten 

Entitätstypen definiert werden 


Beziehungsaggregation –Beispiel 

Vermietung 

Dauer 

Verleihobjekt Mietvertrag 

Wenn gemeinsames Objekt 

NICHT NULL Eigenschaft 


Zum Beispiel 

Eine Vermietung besteht aus einem Verleihobjekt und 

einem Mietvertrag 

Jede Vermietung geht über eine festgelegte Anzahl 

von Tagen 

Nicht jedes Verleihobjekt muss aber an einer 

Vermietung beteiligt sein 

Ein Verleihobjekt kann an verschiedenen 

Vermietungen beteiligt sein 


Unterschiede zur Attribut‐Aggregation 

Bei einer Attribut‐Aggregation oder kurz Aggregation 

ist die Beziehung von der Seite der Konstituente 

immer total, d.h. es ist eine „ist Teil von“‐Aussage 

Allgemein gilt, dass die Beziehungen zwischen dem 

neuen, beziehungsaggregierten Typ und seinen 

Konstituenten durch deren Beziehungen 

untereinander determiniert wird 

Das heißt die Eigenschaften NICHT NULL, 

gemeinsames Objekt und Schlüsseleigenschaft sind 

somit für den Beziehungstyp nicht mehr frei wählbar, 

sondern leiten sich strikt aus der Beziehung ab 


Konsequenzen für den beziehungsaggregierten Typ 

NICHT NULL 

Konstituenten an einer Beziehungsaggregation haben grundsätzlich die 

NICHT NULL Eigenschaft, da an einer Beziehung immer zwei Partner 

beteiligt sind. Also ist immer eine totale Beziehung auf der Seite des 

beziehungsaggregierten Typs gegeben 

Gemeinsames Objekt 

Die Eigenschaft gemeinsames Objekt wird durch die Kardinalität der 

Beziehung bestimmt, über welche aggregiert wurde. Wenn zu dem 

Partner in der Beziehung eine „zu n“ Beziehung besteht, muss diese 

Konstituente die Eigenschaft gemeinsames Objekt besitzen 

Schlüsseleigenschaft 

Der Schlüssel für den beziehungsaggregierten Typ ergibt sich ebenfalls 

aus der Art der aggregierten Beziehung. Im Fall „n zu m“ Beziehung 

müssen beide Konstituenten gemeinsam Schlüssel sein. Ansonsten 

reicht die Konstituente aus, auf deren Seite die „zu n“ Beziehung 

besteht 


Am Beispiel Vermietung 

Da ein Mietvertrag über mindestens ein Verleihobjekt 

gehen muss, muss jeder Mietvertrag auch Teil einer 

Vermietung sein 

Da in einem Mietvertrag mehrere Objekte auftauchen 

können („zu n“ Beziehung) ist der Mietvertrag ein 

gemeinsames Objekt 


Für unser Beispiel gilt somit 

Vermietung 

gilt immer 

Verleihobjekt Mietvertrag 



Objektorientierte Modellierungstechnik 

Es werden gleiche Eigenschaften ähnlicher Entitätstypen zu 

einem neuen Typ zusammengefasst 

Es entsteht hierdurch ein generalisierter neuer Entitätstyp 

Die ursprünglichen Entitätstypen werden als spezialisierte 

Entitätstypen bezeichnet 

Die Generalisierung wird oft auch als eine „ist ein“ ‐ Beziehung 

bezeichnet 

Ein Beispiel für eine Generalisierung findet sich auf der 

nächsten Folie 

Hier haben wir die Entitätstypen CD und DVD, die viele 

Eigenschaften gemein haben 

Diese Eigenschaften finden sich im generalisierten Entitätstypen 

Verleihobjekt wieder und werden entsprechend vererbt 



Jeder generalisierte Entitätstyp erhält zusätzlich ein 

obligatorisches Klassifizierungsattribut 

Dieses Attribut gibt an, von welchem speziellen Typ 

eine Entität ist 

Im folgenden Fall gibt ObjektArt für jedes 

Verleihobjekt an, ob es sich um eine DVD oder um 

eine CD handelt 

Die Generalisierung führt zu einer 1:1 Beziehung 

Totale Beziehung auf der Seite des spezialisierten Typs 

Exklusiver Charakter auf der Seite des generalisierten 

Typs 


ObjektArt 

CD 

CD 

Generalisierung –Beispiel 

Verleihobjekt 

ID Nummer 

DVD 


Generalisierung –Semantik 

Verleihobjekt 

exklusiv total, 

d.h. entweder oder 

DVD 


Gruppierung 

Der Abstraktionsmechanismus Gruppierung 

beschreibt eine Entität als Menge von Entitäten eines 

zweiten Entitätstypen 

In jedem Fall kann nur genau über einen abstrakten 

Entitätstypen gruppiert werden 

So kann etwa die Entität „Vereinmitglieder“ als 

Gruppierung über die Entität „Person“ definiert 

werden 

Ein Beispiel hierzu findet sich auf der folgenden Folie 


Gruppierung –Beispiel 

{ } 

Anschriften 

Anschrift 


Gruppierung –Semantik 

Aufbau einer einseitigen totalen „zu n“ Beziehung zwischen 

dem gruppierten Entitätstypen und seinen Konstituenten 

Dies bedeutet, dass alle Konstituenten mindestens einer 

Menge angehören müssen 

Bei der Menge selbst ist immer die Bezeichnung gemeinsames 

Objekt einzutragen, da es Mengen geben kann, die mehr als 

ein Element besitzen 

Falls NICHT NULL auf Seiten der Gruppierung gewählt wurde, 

kann es keine leeren Mengen geben 

Falls bei der Gruppierung die Option „gemeinsames Objekt“ 

gewählt wurde, gibt es die Möglichkeit, dass eine Konstituente 

in verschiedenen Gruppen auftaucht 

Bei Wahl „gemeinsames Objekt“ 

Gilt immer, da eine Gruppe immer 

mehr als ein Element beinhalten kann 


Gruppierung –Semantik 

{ } 

Anschriften 

Anschrift 

Bei Wahl „NICHT NULL“ 

Immer eine totale Beziehung 


Abstrakter 

Entitätstyp 

Konstituente 

Zusammenfassung –Semantik 

Zu n 

Total 

Zu n 

Total 

Aggregation 

Wahlfrei 

Wahlfrei 

Nein 

Ja 

Beziehungs‐ 

aggregation 

Vorbestimmt 

Ja 

Nein 

Vorbestimmt 

Generali‐ 

sierung 

Nein 

Ja (aber 

exklusiv) 

Nein 


2.2.2.3 Verwendungen und Rollen 

Ja 

Gruppierung 

Wahlfrei 

Wahlfrei 

In einem Schema gibt es unter Umständen unterschiedliche 

Verwendungen von Entitätstypen 

So erfolgt an einer Stelle zunächst die Definition dieses Typs 

Dies wird als dominierendes Auftreten bezeichnet 

Hier erfolgt die genaue Festlegung der Struktur dieses 

Entitätstyps, d.h. es wird definiert, welche elementaren 

Entitätstypen hierfür verwendet werden 

Allerdings kann ein Entitätstyp auch nur einfach verwendet 

werden, d.h. es erfolgt die Nutzung dieses Typs an einer 

bestimmten Stelle der Struktur 

Verbessert die Übersichtlichkeit der Darstellung 

Diese Verwendung kann gedanklich durch die eigentliche 

Definition durch das dominierende Auftreten ersetzt werden 


Ja 

Ja

Verwendungen und Rollen 

Durch Rollen kann auch Teilen von 

Entitätsausprägungen etwas zuordnen 

D.h. man definiert Teilmengen eines Entitätstypen als 

Rolle, die eine bestimmte Verwendung findet

Datenbank - WINFOR

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?