24.11.

2014

Vorlesung Informationssysteme

Dr. Thomas Bode

Institut fr Informatik III
Universitt Bonn
Wintersemester 2014

Wo sind wir?
Kapitel 0: Vorbemerkung
Kapitel 1: Einleitung und Motivation
Kapitel 2: Relationale Datenbanken:
Eine anwendungsorientierte Einfhrung
Kapitel 3: Datendefinition und manipulation in SQL
Kapitel 4: Datenbankentwurf

2013 Manthey, Bode, Behrend

Informationssysteme

DB-Entwurf: Motivation

Insbesondere fr "groe" (kommerzielle) Datenbankentwicklungsprojekte

ist ein systematischer, grndlicher Entwurf von immenser Bedeutung.

Auch fr "kleine" Datenbanken (etwa unsere SLF-DB) lohnen sich einige

tiefergehende berlegungen vor dem Erstellen der Tabellen.

Ziel des DB-Entwurfs: Erstellung eines "guten" DB-Schemas

Kriterien fr die Bewertung eines Entwurfsresultats (u.a.):

in diesem Kapitel: Beschftigung mit "logischen" Aspekten des Entwurfs

(anwendungsbezogen, keine Kenntnis der implementierten
Datenstrukturen und Zugriffsmethoden vorausgesetzt, fr Access-Nutzer
geeignet)

Literatur: im wesentlichen Kemper/Eickler Kapitel 2 (3.1) und 6 (3.2)

Speicherplatzbedarf
Zugriffseffizienz (bei Formulierung, Anfragen, nderungen)
nderungsfreundlichkeit

2013 Manthey, Bode, Behrend

Informationssysteme

Phasen der DB-Entwicklung

relativer Kostenfaktor fr
die Behebung von Fehlern:
Datenbankentwicklung
1

Anforderungsanalyse

10

Entwurf

100

Realisierung

100

2013 Manthey, Bode, Behrend

Nutzung

Informationssysteme

Thema dieses
Kapitels

Anforderungsanalyse

Die Anforderungsanalyse . . .

Es gibt diverse methodische "Schulen" fr die Durchfhrung der

Anforderungsanalyse (hnlich den Anstzen des Software Engineering).
Details sollen hier nicht diskutiert werden.

Wichtig ist stets eine genaue Erhebung der jeweiligen

Unternehmensstrukturen und der Verarbeitungsablufe, in die die
knftige DB eingebettet werden soll.

Ergebnis der Anforderungsanalyse: umfangreiche Dokumentation, die

alle Anforderungen und "Befunde" enthlt

... ist meist die zeitlich umfangreichste und finanziell aufwndigste Phase der
DB-Entwicklung.
... wird durchgefhrt in enger Kooperation mit spteren Nutzern der neuen
Datenbank von Systemanalytikern.
... wird in vielen Quellen bereits als zum Entwurf gehrig betrachtet (hier:
Vorplanungsphase).
... kann von entscheidender Bedeutung fr die sptere Akzeptanz der
Neuentwicklung im Unternehmen sein.

"Pflichtenheft"

2013 Manthey, Bode, Behrend

Informationssysteme

3-Schema-Ansatz
"klassischer" Ansatz des DB-Entwurfs:
3-Schema-Architektur
auch "externe Sichten" genannt
(Begriffskonflikt mglich!)

externes
Subschema1

externes
Subschema2

2013 Manthey, Bode, Behrend

....

externes
Subscheman

logisches Schema

konzeptuelle o.
logische Ebene

internes Schema

physische Ebene

Informationssysteme

Datenunabhngigkeit

Motivation der Aufteilung in drei Ebenen:

Isolation von den Details tieferer Ebenen
dadurch Unabhngigkeit von nderungen auf tieferen Ebenen

Bezeichnung fr diese Form von Abstraktion:

Datenunabhngigkeit

Unterscheidung von zwei Formen der Datenunabhngigkeit:

logische Datenunabhngigkeit:
Externe Subschemata sind abgeschirmt von nderungen des konzeptuellen
Schemas.
physische Datenunabhngigkeit:
Konzeptuelles Schema ist abgeschirmt von nderungen des internen Schemas.

Organisatorische Folge der D.unabhngigkeit in einem Unternehmen:

Verschiedene Personengruppen "kennen" verschiedene Ebenen.

externe Subschemata: DB-Nutzer in Fachabteilungen
konzeptuelles Schema: DB-Designer und DB-Administrator
internes Schema: DB-Administrator

2013 Manthey, Bode, Behrend

Informationssysteme

DB-Entwurf: Prinzip
Anwendungsgebiet
in der "realen Welt"
konzeptueller
Entwurf

Entwurfsdokumentation

logische Strukturen
(beschrieben durch
Konzepte des
Datenmodells)
physische Strukturen
im Rechner
(Ziel: Performanz)
2013 Manthey, Bode, Behrend

konzeptuelles Schema
logischer
Entwurf

logisches Schema
physischer
Entwurf

physisches Schema

Informationssysteme

Wo sind wir?
Kapitel 0: Vorbemerkung
Kapitel 1: Einleitung und Motivation
Kapitel 2: Relationale Datenbanken:
Eine anwendungsorientierte Einfhrung
Kapitel 3: Datendefinition und manipulation in SQL
Kapitel 4: Datenbankentwurf
4.1 Konzeptueller Entwurf

2013 Manthey, Bode, Behrend

Informationssysteme

10

Konzeptueller Entwurf: bersicht

1. Phase des "eigentlichen" Entwurfsprozesses:

Umsetzen der
Strukturanforderungen und der Gesetzmigkeiten des
Anwendungsbereichs in eine formale Darstellung

konzeptuelles Schema

Statt "konzeptuell" wird oft auch das Adjektiv "konzeptionell" verwendet.

Einmal stehen die 'Konzepte' der Anwendung, einmal die 'Konzeption' der
Datenbank im Vordergrund - gemeint ist letztlich dasselbe. Im englischen
Sprachraum: "conceptual modeling" (daher in dieser Vorlesung
"konzeptuell").

Charakteristisch fr die konzeptuelle Modellierung (KM) ist der enge

Bezug der Modellierungskonzepte zur realen Welt statt zum Rechner.

Bei der KM spielen die spter zu entwerfenden Datenstrukturen noch

keine Rolle! Im Vordergrund steht stets noch der Dialog mit dem
Fachanwender.

In der kommerziellen Welt werden derzeit zwei Datenmodelle

berwiegend fr den DB-Entwurf verwendet, die auch in dieser Vorlesung
genutzt werden:
konzeptueller Entwurf:
logischer Entwurf:
2013 Manthey, Bode, Behrend

Entity-Relationship(ER)-Modell
Relationenmodell
Informationssysteme

11

Das Entity-Relationship-Modell

"Entity-Relationship"-Datenmodell (ER-Modell):
vorgeschlagen in einer Arbeit aus dem Jahre 1976 von Peter Chen
graphische Notation fr Anwendungsmodellierung
eigenstndiges semantisches Datenmodell
(an der Bedeutung der Konzepte in der realen Welt orientiert)
Vorlufer der heutigen objektorientierten Datenmodelle
uerst erfolgreich als Mittel zum "Vorentwurf" relationaler DB
seit vielen Jahren: sogar eigene Konferenzreihe (ER Conferences)

Das ER-Modell bietet wenige sehr einfache und grundlegende Konzepte:

"Entities" (Gegenstnde), charakterisiert durch Attribute (Eigenschaften)
2- oder mehrstellige "relationships" (Beziehungen) zwischen Entities, ggf.
ebenfalls charakterisiert durch Attribute
oft nicht explizit erwhnt, aber wichtig und elementar:
"values" (Werte); druckbare Zeichen als Werte von Attributen von
untergeordnetem Rang (charakterisieren Gegenstnde)
"roles" (Rollen): Bezeichner fr die spezielle Bedeutung, die einem Gegenstand
im Rahmen einer Beziehung zukommt
2013 Manthey, Bode, Behrend

Informationssysteme

12

Entity ???
Was ist das: ein Entity ?

engl. "entity" (Plural: "entities"):

being, person, creature, individual, organism, object, article, thing,
substance, quantity (Synonyme nach Oxford Thesaurus)

dt. "Entitt":
"[lat.] die bestimmte Seinsverfassung eines Seienden, auch dieses selbst
( Ens)" (dtv-Lexikon, Bd. 5)

dt. "Ens":
"[lat.] scholastische Philosophie: das Seiende oder etwas, das dem Sein
zukommt, urspr. das wirklich Seiende, i.w.S. alles, das ist oder sein kann,
insgesamt das real Seiende (ens reale), i. Ggs. Zum Gedankending (ens
rationis). . ." (dtv-Lexikon Bd. 5)

im Buch von Kemper:

"Gegenstnde (bzw. Entities) sind wohlunterscheidbare physisch oder
gedanklich existierende Konzepte der zu modellierenden Welt."

2013 Manthey, Bode, Behrend

Informationssysteme

13

ein Entity
Jedes Entity ist durch die Angabe der Werte aller seiner Attribute
vollstndig charakterisiert.
ein Entity

seine Attribute

765

PersNr Vorname
BesGrp
Name Alter Fach
"Rainer"

"Manthey"

53

"Informatik"

"C3"

deren Werte

2013 Manthey, Bode, Behrend

Informationssysteme

14

zwei gleichartige Entities

PersNr

765

Vorname Name Alter Fach

"Rainer"

"Manthey"

53

BesGrp

"Informatik"

"C3"

ein anderes Entity

gleiche Attribute

PersNr

Fach
Vorname
Vorname
Name
Alter Fach
Name Alter

"Armin B."

"Cremers"

60

BesGrp

"Informatik"

z.T. andere Werte

2013 Manthey, Bode, Behrend

Informationssysteme

"C4"

15

Entity-Typen

Gleichartige Entities knnen zu Entity-Typen zusammengefasst werden.

"Gleichartigkeit" setzt zumindest identische Attributstruktur voraus.

(Attributnamen und zugehrige Wertebereiche sind gleich)

Entity-Typen werden in der graphischen Notation des ER-Modells durch

Rechtecke dargestellt. Attribute markieren die Verbindung zwischen den
Entity-Typen und Wertebereichen (meist als Oval dargestellt):

professor

PersNr
Int

Name des Typs

Vorname Name Alter Fach

String

2013 Manthey, Bode, Behrend

String

Int

Informationssysteme

BesGrp

String

String

16

Entity-Typen: alternative Darstellungsweisen

Wertebereichsnamen werden oft weggelassen (sofern sie offensichtlich

oder irrelevant sind) und stattdessen nur die Attribute in die Ovale
geschrieben:

professor

PersNr

Vorname

Name

Alter

Fach

BesGrp

In grsseren Diagrammen fllt die Attributstruktur meistens ganz weg,

um Platz zu sparen (oder wird nur abkrzend bzw. separat notiert):

professor
PersNr, Vorname, Name, . . .
2013 Manthey, Bode, Behrend

Informationssysteme

17

Instanzen und Population eines Entity-Typs

Jedes Entity "gehrt zu" mindestens einem Entity-Typ:

Es wird dann Instanz dieses Typs genannt.

eine Instanz von

professor

Die Menge aller aktuellen Instanzen eines Entity-Typs heit

dessen Population.

professor
eine Population von

2013 Manthey, Bode, Behrend

Informationssysteme

18

Mehrfachklassifizierung

Ein und dasselbe Entity kann Instanz verschiedener Entity-Typen

sein.

professor
Instanz von
Instanz von
werder
Bremen-fan

Dabei kann die Attributstruktur der beiden Typen durchaus

verschieden sein.
2013 Manthey, Bode, Behrend

Informationssysteme

19

Klassifizierung bei gleicher Attributstruktur

Entities mit gleicher Attributstruktur mssen keineswegs

desselben Typs sein !
Instanz von

esel
name, vorname, alter

Instanz von

werder
Bremen-fan

name, vorname, alter

Fast immer muss es noch zustzliche Klassifizierungsmerkmale

geben, die man an der Attributstruktur nicht ablesen kann.
2013 Manthey, Bode, Behrend

Informationssysteme

20

Schlsselattribute

Es gibt in der Regel stets ein oder mehrere Attribute pro Entity-Typ, deren
Werte ausreichen, um die einzelnen Instanzen eindeutig zu identifizieren:

professor

PersNr

Vorname

Name

Alter

Fach

BesGrp

(Primr-)Schlsselattribute werden meist durch unterstreichen im ERDiagramm gekennzeichnet.

Schlssel sollten stets "minimal" sein (kein Attribut kann weggelassen
werden).
Eine Unterscheidung von Primrschlsseln und anderen Schlsselkandidaten ist im ER-Modell nicht vorgesehen, ist aber sinnvoll.

2013 Manthey, Bode, Behrend

Informationssysteme

21

SLF-Datenbank: Entity-Typen und Attribute

Stadt

Attribut

Land

Name
Kfz
Einwohner
Flche

Entity-Typ

Name
Kurzform
Einwohner
Flche

Fluss

Schlsselattribut

Bezirk

Name
LngeInD
Gesamtlnge

2013 Manthey, Bode, Behrend

Nachbarstaat
Staat
Kennzeichen
Vorwahl
GrenzlngeMitD

Informationssysteme

Name
Einwohner
Flche

22

Relationships

2. Grundkonzept des ER-Modells: elementare Beziehungen zwischen

zwei oder mehr Entities (ggf. mit eigenen Attributwerten)

PersNr

Berufungsjahr

765

1992

Bezeichnung
Universitt Bonn

Jede Relationship ist durch die Schlsselwerte der beteiligten Entities

und die Werte aller Relationship-Attribute eindeutig charakterisiert.

Es kann allerdings keine eigenen Schlsselattribute fr Relationships

geben, da stets die Schlssel der beteiligten Entity-Typen zum
eindeutigen Identifizieren dienen (ihre Kombination ist also Schlssel des
R.typs).
2013 Manthey, Bode, Behrend

Informationssysteme

23

Mehrfache Beziehungen
Entitites knnen an mehreren Relationships (auch an gleichartigen)
beteiligt sein.

Berufungsjahr
1992

Berufungsjahr
1999

2013 Manthey, Bode, Behrend

Informationssysteme

24

Relationship-Typen

Gleichartige Relationships knnen zu Relationship-Typen

zusammengefasst werden.

"Gleichartigkeit" setzt zumindest identische Attributstruktur und

identische Typen (und Anzahl) der beteiligten Entities voraus.

Relationship-Typen werden in der graphischen Notation des ER-Modells

durch Rauten dargestellt. Attribute werden wie bei Entity-Typen notiert.

berufen_an
professor
PersNr, ...

universitt
Bezeichnung, ...

Berufungsjahr

Int
2013 Manthey, Bode, Behrend

Informationssysteme

25

Instanzbeziehungen bei Relationship-Typen

berufen_an
professor
PersNr, ...

universitt
Bezeichnung, ...
Berufungsjahr

Int
Auch bei Relationship-Typen gibt es den Begriff der 'Instanz': Einzelne
Relationships zwischen einzelnen Entities lassen sich analog als Instanzen
der R-Typen auffassen.

berufen_an
PersNr,

765,
2013 Manthey, Bode, Behrend

Berufungsjahr

1992
Informationssysteme

Bezeichnung,

Universitt Bonn,

26

Typ vs. Instanz

berufen_an
professor

universitt

PersNr, ...

Bezeichnung, ...

Berufungsjahr

Entity-Typ

Relationship-Typ

Int

Die Unterscheidung zwischen Typen und Instanzen fllt vielen (gerade auch)
Fachleuten erstaunlicherweise schwer: Gewhnen Sie sich gleich Przision
dabei an!

berufen_an
Berufungsjahr

PersNr

765

...

Entity

2013 Manthey, Bode, Behrend

1992

Relationship

Informationssysteme

Bezeichnung

...

Universitt Bonn

27

Mehrfache Beteiligung an Relationship-Typen und Rollen

Ein und derselbe Entity-Typ kann an einem Relationship-Typ auch

mehrfach beteiligt sein, z.B.:
mutter

abkmmling_von
person
kind

Zur (syntaktischen) Unterscheidung zwischen den verschiedenen

"Formen der Beteiligung" sollte man in solchen Situationen
gesonderte Bezeichner, genannt Rollen, verwenden, die als
Markierungen an den jeweiligen Kanten zwischen Entity- und
Relationship-Symbol notiert werden.
2013 Manthey, Bode, Behrend

Informationssysteme

28

Rollen bei Relationships ohne Mehrfachbezug

Rollen drfen auch dann eingesetzt werden, wenn keine Mehrdeutigkeit

auf Grund von mehrfacher Beteiligung desselben Entity-Typs vorliegt. Sie
dienen dann als semantisch begrndete zustzliche Informationen im
Schema.

geprft_von
professor

prfling

prfer

student
MatrNr, ...

PersNr, ...

Werden bei einem Relationship-Typ nur einzelne beteiligte Entity-Typen

mit expliziten Rollen versehen, dann kann man fr die brigen E-Typen
deren Namen stets als implizite Rolle annehmen.

Wrde also im obigen Beispiel nur die Rolle 'prfer' explizit genannt, dann
knnte man 'student' als implizite Rolle an der anderen Kante annehmen.
2013 Manthey, Bode, Behrend

Informationssysteme

29

Namenskonventionen

Die Wahl der Bezeichner fr Typen und Attribute muss stets so gewhlt
sein, dass innerhalb desselben Schemas klar ist, welches Konzept gerade
gemeint ist.

Das bedeutet:
Jeder Name eines Entity-Typs darf im Schema nur einmal vorkommen.
Jeder Name eines Relationship-Typs darf im Schema nur einmal vorkommen.
Jedes Attribut und jede Rolle muss innerhalb des Schemas des jeweiligen
Entity- oder Relationship-Typs eindeutig gewhlt sein.
Attribute und Rollen drfen aber in anderen Typen wieder verwendet werden.

Globale Bezeichungskonflikte bei Attributen oder Rollen lassen sich durch

Verwendung des jeweiligen Typs als Prfix lsen, z.B. professor.Name
versus universitt.Name.
2013 Manthey, Bode, Behrend

Informationssysteme

30

SLF-Datenbank: Relationship-Typen (1)

Hauptstadt

nachbarland_von
hauptstadt_von_land

Land 1

Land

Stadt

Land 2

stadt_in_land
stadt_an_fluss

bezirk_
in_land
fluss_
durch_
land

Fluss

Bezirk

Relationship-Typ
Quellfluss

quellfluss_von
2013 Manthey, Bode, Behrend

Rolle
Informationssysteme

31

SLF-Datenbank: Relationship-Typen (2)

fluss_entspringt_
in_land
Ursprungsland
Land 1
Land 2

grenzfluss_national

Fluss
grenzfluss_international

Nebenfluss
nebenfluss_von

2013 Manthey, Bode, Behrend

Nachbarstaat

Informationssysteme

Land