Daten- und Informationsmodellierung · Datenmodellierung Thomas Gottron GLDB 2012/13 47 UML: Is-A...

Institute for Web Science & Technologies – WeST

Daten- und Informationsmodellierung

Dr. Thomas Gottron

Wintersemester 2012/13

Grundlagen der Datenbanken

Thomas Gottron GLDB 2012/13 2 Datenmodellierung

Lernziele

Kenntnis der Vorgehensweise beim DB-Entwurf

Grundkonzepte von ER Modell und UML

Klassendiagrammen für Datenmodellierung

Kenntnis der Abstraktionskonzepte (Generalisierung,

Aggregation)

Fähigkeit zur praktischen Anwendung der Konzepte

– Erstellung von Modellen für gegebene

Anwendungsszenarien

– Festlegung der Primärschlüssel, Beziehungstypen,

Kardinalitäten, Existenzabhängigkeiten etc.

– Interpretation gegebener Modelle


Wiederholung: Abstraktionsebenen des Datenbankentwurfs

Physische Ebene

Logische Ebene

Konzeptuelle Ebene Wie sieht die Welt aus ?

Welche Strukturen

werden von der

Anwendung

manipuliert?

Wie wird gespeichert ?

Abstraktion


Datenbankentwurf


Allgemeine Vorgehensweise

reales System

Anforderungsermittlung und Analyse

Konzeptioneller Entwurf (Informationsmodellierung)

Logischer Entwurf (DB-Schema, externe Schema)

physischer Entwurf (internes Schema)

Anwendungserstellung, Systemintegration

Informationssystem

Verwendung

En

twu

rf

Imp

lem

en

tieru

ng

Tests

Evaluationen

Auswertungen

Modifikationen


Informationsmodellierung

Darstellungselemente + Regeln: - Objekte und Beziehungen (Relationships)

- Klassen von Objekten / Beziehungen

- Eigenschaften (Attribute)

Informationen über Objekte und Beziehungen nur wenn:

- relevant

- unterscheidbar und identifizierbar, selektiv beschreibbar

Zusammenhänge

Sachverhalte Gegenstände

Informationen

Personen Tatsachen

Formalisierung

Objekte

Beziehungen

Attribute

Vorgänge,

Veränderungen..

" Miniwelt "


Beispielszenario – SUNRISE

Universität

Angestellte

Professoren

Assistenten

Studenten

Vorlesungen

Räume

Bibliothek

Prüfungen

Zeugnisse

...

Welche Objekte?

Welche Eigenschaften?

Welche Beziehungen?

Welche Prozesse?

SUNRISE

(Schönes UNiveRsitäres Informations SystEm)


Objektbeschreibung

Uni-Angestellte

- Anzahl: 1000

- Attribute

PersonalNummer

– Typ: char

– Länge: 9

– Wertebereich:

0...999.999.999

– Anzahl Wiederholungen:

0

– Definiertheit: 100%

– Identifizierend: ja

Gehalt

– Typ: dezimal

– Länge: (8,2)

– Anzahl Wiederholung: 0


– Identifizierend: nein

Rang

– Typ: String

– Länge: 4

– Anzahl Wiederholung: 0


– Identifizierend: nein


Beziehungsbeschreibung: prüfen

Beteiligte Objekte:

- Professor als Prüfer

- Student als Prüfling

- Vorlesung als Prüfungsstoff

Attribute der Beziehung:

- Datum

- Uhrzeit

- Note

Anzahl: 100 000 pro Jahr


Prozeßbeschreibungen: Zeugnisausstellung

Häufigkeit: halbjährlich

benötigte Daten

Prüfungen

Studienordnungen

Studenteninformation

...

Priorität: hoch

Zu verarbeitende Datenmenge

500 Studenten

3000 Prüfungen

10 Studienordnungen


Abstraktionskonzepte

Informations- und Datenmodelle basieren auf drei

grundlegenden Abstraktionskonzepten:

Klassifikation: fasst Objekte (Entities, Instanzen)

mit gemeinsamen Eigenschaften zu einem neuen (Mengen-)

Objekt (Entity-Menge, Klasse, Objekttyp) zusammen.

– Instanzen/Objekten einer Klasse unterliegen gleicher Struktur (Attribute),

gleichen Integritätsbedingungen, gleichen Operationen

– mathematisch: Mengenbildung

Aggregation: Zusammenfassung potentiell unterschiedlicher

Teilobjekte (Komponenten) zu neuem Objekt

– mathematisch: Bildung von kartesischen Produkten

Generalisierung: Teilmengenbeziehungen

zwischen Elementen verschiedener Klassen

– mathematisch: Bildung von Potenzmengen (bzw. Teilmengen)

– wesentlich: Vererbung von Eigenschaften an Teilmengen


Entity-Relationship-Modell


ER-Modell

Peter P-S. Chen (1976) „The Entity-Relationship Model –

Toward a Unified View of Data“, ACM TODS

Elemente:

Entity: Gegenstände / Objekte

Relationship: Beziehungen zwischen Entities

Attribute: Eigenschaften

Rollen: von Entities in Relationships

Entität Entitätstyp

Beziehung Beziehungstyp


Grundlagen ER-Modell

Entity

Relationship

Attribute

Verbindungen

Studenten Vorlesungen Dozent

liest hört

MatrNr Titel Name

Studenten Vorlesungen hört

MatrNr Titel Name VorlNr

Raum


Schlüssel

Minimale Menge von identifizierenden Attributen

{Matrikelnummer}

{Vorname, Nachname, Geburtsdatum, Geburtsort}

Oft künstlicher Schlüssel bestehend aus einem Attribut

(Vorlesungsnummer, Kundennummer,

Personalausweisnummer,…)

Mehrere Schlüssel möglich; dann Auswahl eines

Primärschlüssel


Relationships

Binär:

Mehrstellig:

Mit Eigenschaften:


Studenten Vorlesungen prüft

Dozent


Dozent

Note


Relationships – Rollen

Manchmal notwendig zur Klärung von Sachverhalten:


Dozent

Note

Prüfer

Prüfling Thema

Vorlesungen

voraus

setzen Vorgänger Nachfolger


Beispiel

Bibliothek

Bücher

Standort

Nutzer

Ausleihe

...

Entitäten, Beziehungen, Attribute, Rollen?


Beispiel Bibliothek (ein Ansatz)

Nutzer

Name

Bücher

Signatur

Titel

Autor

steht Standort

RegalNr Ort

NutzerId

entleihen Fälligkeit

zitiert

Quelle Referenzierendes

Werk


Relationships – Formal

𝐸 Menge aller Entity(typen)

Ein n-stelliger Beziehungstyp 𝑅 kann als Relation definiert

werden:

𝑅 ⊆ 𝐸1 × 𝐸2 × ⋯ × 𝐸𝑛

• Wobei 𝐸𝑖 ∈ 𝐸

Rollen: Gilt 𝐸𝑖 = 𝐸𝑗 in einer Beziehung, so charakterisiert

man die Entitäten durch Rollen:

Vorgänger:𝑣1, Nachfolger:𝑣2

Vorlesungen

voraus

setzen Vorgänger Nachfolger


Funktionalität von Beziehungen

Einschränkung der Zahl von Beziehungen eines

Beziehungstyps, an der eine Entität beteiligt sein kann.

(Funktions-)Eigenschaften der Relation

𝑅 ⊆ 𝐸1 × 𝐸2

𝑅: 𝐸1 → 𝐸2

Total partiell

Rechtseindeutig (sonst keine Funktion)

Linkseindeutig (injektiv)

Inverse (𝑅−1)


1:1 Beziehungen

Jedes Element aus 𝐸1 ist höchstens einem Element aus 𝐸2

zugeordnet und umgekehrt

rechtseindeutig, linkseindeutig, partiell

Beispiel-Beziehungen

hatPass

Studenten Reisepass

Studenten

Reisepass hatPass

1

1


1:N Beziehungen

Jedes Element aus 𝐸1 kann beliebig vielen Element aus 𝐸2

zugeordnet sein, aber jedes Element in 𝐸2 nur einem

Element aus 𝐸1

(keine Funktion), linkseindeutig, partiell


Buchausleihe

Studenten Buch

Studenten

Buch leiht

1

N


N:1 Beziehungen

Umgekehrter Fall zu 1:N

rechtseindeutig, partiell


Übungsgruppen

Studenten Gruppe

Studenten

Gruppe gehörtZu

N

1


N:M Beziehungen

Keine Einschränkung


Hört (Vorlesung)

Liest (Vorlesung)

Studenten Vorlesung

Studenten

Vorlesung hört

N

M


Funktionalität Mehrstelliger Beziehungen

n-Stellige Beziehung:

𝑅 ⊆ 𝐸1 × 𝐸2 × ⋯ × 𝐸𝑛

Steht an 𝐸𝑖 eine 1, so ist

𝑅: 𝐸1 × ⋯ × 𝐸𝑖−1 × 𝐸𝑖+1 × ⋯ × 𝐸𝑛 → 𝐸𝑖

eine partielle Funktion, d.h. die Relation ist rechtseindeutig

• Dies gilt für alle Entitytypen mit einer 1


Beispiel 1

Bedeutung?

Funktionen

(Student, Vorlesung) Dozent

• Studenten werden für eine Vorlesung nur von einem

Dozenten geprüft


Dozent

Note

1

N M


Beispiel 2

Bedeutung?

Funktionen:

(Student, Dozent) Vorlesung

• Dozent prüft ein Studenten in höchstens einer Vorlesung


Dozent

Note

M

N 1


Beispiel 3

Bedeutung?

Funktionen:



• Studenten werden von einem Dozenten nur einmal und für

nur eine Vorlesung geprüft


Dozent

Note

1

N 1


Beispiel 4

Bedeutung?

Funktionen:



(Dozent, Vorlesung) Student

• Ein Dozent prüft eine Vorlesung für höchstens einen

Studenten


Dozent

Note

1

1 1


Min-Max Notation

Genauere Spezifikation, wieviele Entitäten an einer

Beziehung mindestens / höchstens teilnehmen dürfen

0 : keine Entität erforderlich

1,2,3,4, ... : Zahlwert vorgegeben

* : keine Einschränkung

Studenten Vorlesungen hört (0,*) (1,*)


ERM Beispiel: Begrenzungsflächendarstellung

Polyeder

Hülle

Flächen

Begrenzung

Kanten

StartEnde

Punkte

PolyID

FlächenID

KantenID

X

Y

Z

1

N

N

M

N

M

(4, )

(1,1)

(3, )

(2, 2)

(2, 2)

(3, )

Beispiel-

Polyeder


Existenzabhängige Entitäten

Entitäten, die in ihrer Existenz von einer

anderen Entität abhängig sind

(Oft) nur zusammen mit Schlüssel der

anderen Entität identifzierbar

Kunde Bestellung 1 M

umfasst

Artikel

N

M

KundenNr Datum

beauftragt


Darstellung Aggregation (part-of)

Buch

Inhaltsverzeichnis Kapitel Index

part-of part-of part-of

Überschrift Absatz Abbildung

part-of part-of part-of


Darstellung Generalisierung (is-a)

Studenten

Menschen

Angestellte

Wiss. Mitarbeiter Professoren Nichtwiss. MA

is-a

is-a

Name

MatrNr.

PersNr.


Arten von Spezialisierungen

X

Y Z

disjunkte Spezialisierungen

(Partitionierung)

Subklassen

überlappende

Spezialisierungen

vollständig, disjunkt (complete, disjoint)

Y Z

X

Y Z

X

vollständig, überlappend (complete, overlapping)

partiell, disjunkt (incomplete, disjoint)

Y

Z

X

Y Z

X

partiell, überlappend (incomplete, overlapping)

Superklasse

is-a


ER-Modell

Ein ER-Modell für alles – oft zu komplex

Einzelne Sichten des Szenarios modellieren und dann

schrittweise integrieren.

Entfernung von Redundanzen

Entfernung von Widersprüchen

Behandlung von Synonymen (Dozent, Lehrender) oder

Homonymen (betreut – Diplomarbeit, Doktorarbeit)


UML


Unified Modeling Language (UML)

standardisierte graphische Notation / Sprache zur

Beschreibung objektorientierter Software-Entwicklung

Kombination unterschiedlicher Modelle bzw. Notationen,

u.a.

– Booch

– Rumbaugh (OMT)

– Jacobson (Use Cases)

Standardisierung durch Herstellervereinigung OMG

(Object Management Group):

– 1997: UML 1.1

– 2001: UML 1.4

– 2003: UML 2.0

Infos: www.uml.org J. Rumbaugh, I. Jacobson, Grady Booch:

The Unified Modeling Language Reference Manual (2nd Edition) Addison-Wesley, 2004


UML: Bestandteile

UML umfasst

Modellelemente (Klassen, Interfaces, Anwendungsfälle ...)

Beziehungen (Assoziationen, Generalisierung, Abhängigkeiten ...) und

Diagramme

Anforderungen

Analyse

Entwurf

Implementierung

Software-Entwicklung

Anwendungsfälle

Klassendiagramme

Modularisierung

Klassendiagramme

verfeinert

Komponentendiagramme

Code (Klassendefinition)

Aktivitäten

Szenarien

Sequenzdiagramme

Kooperations-,

Zustandsdiagramme

Verteilungsdiagramme,

Code (Methoden)

Objektstruktur Objektverhalten

Für uns

wichtig


UML: Darstellung von Klassen und Objekten

Klassensymbol: Angabe von Klassenname, Attribute (optional),

Methoden (optional)

i. a. werden nur relevante Details gezeigt

Sichtbarkeit

i.d.R. Alles sichtbar beim Entwurf.

Student Student

+MatrNr: int

+Name: String

Student

+semester(): int

+sumSWS(): short

Student

+semester(): int

+sumSWS(): short

+MatrNr: int

+Name: String


UML: Assoziationen

Entspricht Beziehungen (relationships) im ER-Modell

optional:

Assoziationsnamen

Leserichtung (bzw.)

Rollennamen

Sichtbarkeit von Rollen (+, -, #)

Kardinalitätsrestriktionen

hört

Assoziationsname Klasse 1 Klasse 2

Rolle 1 Rolle 2

Student Vorlesung +Hörer +Veranstaltung


Beispiel: ER vs. UML


MatrNr Titel Name VorlNr

Raum

M N

hört

Student Vorlesung

+MatrNr: int

+Name: String +Titel: String

+VorlNr: int

+Raum: String

0..* 0..*


UML: Kardinalitätsrestriktionen

Verfeinerung der Semantik eines Beziehungstyps durch

Kardinalitätsrestriktionen:

x .. y mindestens x, maximal y Objekte nehmen an der Beziehung teil

0 ..* optionale Teilnahme an der Beziehung (alternativ ' * ' = 'many')

1 ..* obligatorische teilnahme an der Beziehung

0 .. 1 "es kann nur einen geben" (oder keinen)

1 genau 1

für binäre Assoziation:

Multiplizität min1..max1 (min2..max2) bedeutet, dass zu jedem E2 (E1) - Element wenigstens min1 (min2) und höchstens max1 (max2) Instanzen von E1 (E2)

enthalten sein müssen (mit 0 <= mini <= maxi, maxi >= 1)

Bezugnahme zur „gegenüberliegenden“ Klasse

.. erlaubt Unterscheidung, ob Beziehungsteilnahme

optional (Mindestkardinalität = 0) oder

obligatorisch (Mindestkardinalität 1 ) ist

R

min2..max2 E1 E2

min1..max1

e1 nimmt an [min2, max2]

Beziehungen vom Typ R teil

e2 nimmt an [min1, max1]

Beziehungen vom Typ R teil


UML: Assoziations-Klassen

Notwendig für Beziehungen mit eigenen Attributen

gestrichelte Linie

Name der Assoziations-Klasse entspricht dem der Assoziation

alternativ:

Studenten Professoren

* * Prüfung

Studenten Professoren * * * *

Prüfung

Prüfung

+Note: float

+Note: float


UML: Part-Of Beziehungen

Part-of-Beziehung (Teil-von-Beziehung) zwischen

Komponenten und Aggregatobjekten

Elemente einer Subkomponente sind auch Elemente aller

Superkomponenten dieser Subkomponente

Referenzsemantik ermöglicht, dass ein Objekt gleichzeitig Elemente

verschiedener Komponenten bzw. Subkomponente von mehreren

Superkomponenten sein kann - Netzwerke, (n:m) Beziehungen möglich

Wertesemantik (Komposition): Teil-Objekt gehört genau zu einem

Aggregat-Objekt; Existenzabhängigkeit!

Aggregatklasse

Komp. Klasse 1 Komp. Klasse 1

Aggregatklasse

Komp. Klasse 1 Komp. Klasse 1

Aggregation Komposition


UML: Is-A Beziehungen

Is-A-Beziehung zwischen Klassen (Entity-Mengen)

E1 is-a E2 bedeutet, dass jedes Objekt aus E1 auch ein Objekt aus E2 ist,

jedoch mit zusätzlichen strukturellen Eigenschaften

Substitutionsprinzip: alle Instanzen einer Subklasse sind auch

Instanzen der Superklasse

Vererbung von Eigenschaften (Attribute, Integritätsbedingungen, Methoden

...) der Superklasse an alle Subklassen

Wiederverwendbarkeit, Erweiterbarkeit

keine Wiederholung von Beschreibungsinformation, Fehlervermeidung

Subklasse 1

Superklasse

Subklasse 1 Subklasse 1

Superklasse

Subklasse 1


Zusammenfassung

DB-Entwurf umfasst

Informationsanalyse

konzeptioneller Entwurf (-> Informationsmodell)

logischer Entwurf (-> logisches DB-Schema)

physischer Entwurf (-> physisches DB-Schema)

Formale Darstellung

ER-Modell

UML-Klassendiagramme

keine festen Regeln zur eigentlichen Informationsmodellierung

(i.A. mehrere Modellierungsmöglichkeiten einer Miniwelt)


Fragen ?

[email protected]

http://west.uni-koblenz.de/teaching/ws1213/datenbanken

Daten- und Informationsmodellierung · Datenmodellierung Thomas Gottron GLDB 2012/13 47 UML: Is-A...

Documents

Transcript of Daten- und Informationsmodellierung · Datenmodellierung Thomas Gottron GLDB 2012/13 47 UML: Is-A...