A-K-3 - Eltviller.de

Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-1
(bisher)
1
Anforderungen
 Bestimmung des „Informationsbedürfnisses“
 Analyse der Geschäftsprozesse
 Operativ
 strategisch
 Anforderungen an das Informationssystem
2
Berichtgestaltung, Datenbasis, Verdichtung
(weiter mit)
3
Daten- und Datenbank- Design
Datenstrukturierung
 Modellierung in einem „Entity-Relationship-Model“ (E-R Modell)
E-R Modell:
Ein E-R Modell ist eine (graphische) Methode zur Darstellung komplexer Beziehungsgebilde
der Realität, die gleichzeitig Grundlage für die logischen Beziehungen der entsprechenden
Daten in einem relationalen Datenbanksystems ist.
In einem ER - Modell werden die „Objekte“ der „realen Welt“ und ihre Beziehungen
untereinander beschrieben.
Aus dem ER - Modell wird die Datenbankstruktur abgeleitet, d.h. wie die Information über
die „Objekte“ in der Datenbank abgespeichert werden.
Datenbankdefinition
 Erzeugung der Datenbank im Rechner (aus E-R Modell)
Prof. Dr. J. Weinberg
3.1
IuK-Systeme A - SS 2000
Seite 3-2
Modell
Modell:
 Darstellung eines Teiles (Ausschnittes) der „Welt“
Welt (“Realität”)
Modell (Datenbank)
Ausschnitt “Miniwelt”
Beschränkung auf einen Ausschnitt aus Kosten/Nutzen Aspekten:
 Informationsgewinnung , Pflege und Speicherung ist aufwendig
(nur) interessante Teil
 Information ist nicht / sehr schwer erhältlich
 Restriktionen durch den Datenschutz
zB
Schuhgröße des Hausmeisters?
Absatz-/Umsatzzahlen der Konkurrenz?
... ?
 Die Frage welcher Ausschnitt realisiert wird ergibt sich aus
 Was wird benötigt? ( Kapitel 1 und 2)
 Was ist erhältlich?
 Welche Kosten entstehen?
 Was darf gespeichert werden? (Datenschutzgesetz)
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-3
Beispiele:
 Kunden- und Produktdaten sind unverzichtbar.
 Daten über alle Konsumenten der Zielgruppe sind i.d.R nicht oder mit einem nicht
vertretbaren Aufwand zu erhalten und zu pflegen ( Direktmarketing Agenturen
mit Adresspools,  Marktforschungsunternehmen mit statistischen Daten)
 Die Absatz- und Umsatzzahlen der Konkurrenz sind i.d.R. nicht oder nur
rudimentär im Informations- und Kommunikationssystem des Unternehmens zu
finden, weil diese Daten kaum zu beschaffen sind.
 Personenbezogene Daten dürfen nur mit Zustimmung für einen bestimmten
Zweck gespeichert werden. Ein anderer Einsatz oder gar „Verkauf“ der Daten
(z.B. zu Direkt-Mailing Aktionen) ist nicht erlaubt.
Bemerkung:
Die Betrachtung des Ausschnittes erfolgt nicht mit dem Anspruch, hieraus auf den Rest der
Welt schließen zu können. (Im Gegensatz zu anderen Modellen, wie z.B. in der
Marktforschung, deren Zweck es ist, aus den Erkenntnissen über die „Mini-Welt“ auf die
Gesamtheit zu schließen)
Beispiel: Geburtsdatum - Wenn es nicht gespeichert ist z. B. folgendes nicht möglich:
 Sortierung nach Alter
 Berechnung von Pensionsrückstellungen
 Erreichen der Altersgrenze
 Geburtstagsliste
Beispiel: Schuhgröße des Hausmeisters?
Prof. Dr. J. Weinberg
3.2
IuK-Systeme A - SS 2000
Seite 3-4
Objekt (Entität, Entity)
Objekte sind „Gegenstände der realen Welt oder der Vorstellung“
 Personen, Mitarbeiter, Studenten, ...
 Hunde, Katzen, Kühe, Elefanten, ...
 Kunden, Lieferanten, Mitarbeiter, Banken, ...
 Produkte, Maschinen, Häuser, Studiengänge, ...
 Produktgruppen, Aufträge, Mietverträge, Freundschaften, Stücklisten, ...
 ...
Jeder „Gegenstand“, der „informationsmäßig verwaltet“ werden soll, wird in einem E-RModell als Objekt bezeichnet. Welche Objekte modelliert werden, hängt von der
Aufgabenstellung ab: Information über Elefanten wird bei vielen Unternehmen nicht benötigt,
bei Tierhändlern schon eher. Für einen Zoo müssen IuK-Systeme auch exotische Tiere
verwalten können.
Ein Objekt wird beschrieben durch seine Eigenschaften und Beziehungen zu anderen
Objekten:
 Attribut (Eigenschaft)
 Relation (Relationship, Beziehung)
Beispiel Mitarbeiter
Attribut
in Datenbank?
Name

Vorname

Geb.-Datum

Straße

PLZ

Ort

Größe
?

Haarfarbe
?

Augenfarbe
?

Model-Agentur
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-5
Beziehungen zu anderen Objekten:
 Arbeitsplatz
 Gehaltsklasse
 Gehaltskonto
Die Beziehung wird als Referenz auf ein anderes Objekt dargestellt:
Arbeitsplatz:
MA Müller
ist beschäftigt in
Schlosserei
(Objekt MA)
(Beziehung)
(Objekt Arbeitsplatz)
MA Müller
gehört zu
Tarifgruppe T4
(Objekt MA)
(Beziehung)
(Objekt Gehaltsklasse)
MA Müller
besitzt
Konto 4711 bei Voba
(Objekt MA)
(Beziehung)
(Objekt Gehaltskonto)
Gehalt:
Gehaltskonto.:
Die Beziehungen des E-R-Modells werden grafisch dargestellt:
1. Schritt:
Mitarbeiter
n
n
„gehört zu”
1
Tarifgruppe
1
„besitzt”
„hat”
1
Arbeitsplatz
Kardinalität:
 1:1
 1:n
 n:m
1
Gehaltskonto
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-6
2. Schritt:
Weitere Objekte „ableiten”
z.B.
Gehaltskonto
n
Konto
1
Bank
E-R - Modell
„hat”
Mitarbeiter
1
„bei”
Konto
1
n
Bank
1

Name

Konto - Nr.

BLZ

Vorname

BLZ

Bankname

...

ab

Adresse

bis

...

…
In dieser Konstellation ( 1 : 1 ) kann auf das Objekt “Konto” verzichtet werden, wenn das
Konto in den Mitarbeiter integriert wird.
Mitarbeiter
„hat Gehaltskonto bei”
Bank

Personal-Nr

BLZ

…

…

Gehaltskonto - Nr.

…

Gehalts - BLZ

…
 1:1-Beziehungen können ein E-R-Modell unnötig verkomplizieren und werden ggf.
vermieden. Dies ist jedoch nicht immer möglich, da bei der Integration einer 1:1Beziehung ein Objekt „verschwindet“.
 Stehen beide Objekte in Beziehungen zu anderen Objekten, müssen beide Objekte
modelliert werden
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-7
 „Löschdefekt“: Wenn ein Objekt nur als „Teil“ eines anderen Objektes modelliert
wurde, wird das Teilobjekt bei Löschung des „Haupt“-Objektes auch gelöscht.
( „Normalisierung“, „1. - 3. Normalform“)
 „Ehe“ ist in der BRD gesetzlich eine 1:1-Beziehung. Im E-R Modell müssen
jedoch beide Partner als „Objekt“ modelliert werden
„ist verheiratet mit”
Mann
Frau
1
1
1
1
„ist Vater von”
„ist Mutter von”
n
Kind
n
Beispiel einen n:m Beziehung: „Freundschaften“
0
„ist befreundet mit”
Mädchen
m
Junge
n
 Simone
 Jens
 Petra
 Oliver
 Iris
 Peter
 Nina
 Paul
Prof. Dr. J. Weinberg
3.3
IuK-Systeme A - SS 2000
Seite 3-8
Primärschlüssel
Jedes Objekt muß eindeutig identifizierbar sein.
Ein oder mehrere Attribute, die das Objekt eindeutig identifizieren, werden
 Primärschlüssel
genannt.
In der Praxis haben sich die folgenden Designregeln bewährt:
Designregeln für Primärschlüssel:
 „nicht sprechende“ Zählnummer („laufende Nummer“)
zB
 Matrikelnummer
 Kundennummer
 Personalnummer
 Artikelnummer
 ...
Gründe:
 Sicherheit: eindeutige Identifikation ist gesichert. Jede Kombination von
Attributen birgt die Gefahr von „Doubletten“
 Flexibilität: alle Attribute können geändert werden, ohne daß der Primärschlüssel
verändert wird ( Datenkonsistenz, s.u. „referentielle Integrität“)
 Speicherplatz/Performance: kurze Primärschlüssel, effizienter Index (technischer
Vorteil)
 Datenschutz: aus dem Primärschlüssel kann keine Information gezogen werden,
Daten können „anonym“ unter dem Primärschlüssel veröffentlicht werden
Beispiele sprechender Schlüssel: Rentenversicherungsnr, „Bundeswehrnr.“
Ausnahmen:
 Hierarchische Beziehungen der Art „gehört zu“ (nicht änderbar!)
Hier kann der Primärschlüssel aus zwei Teilen bestehen
 (Primär-) Schlüssel des „übergeordneten“ Objektes +
 lfd. Nummer für das Objekt
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-9
Beispiele:
Mandantenfähige Systeme: Jedes Objekt „gehört“ zu einer Firma, die Firmennr. wird Teil des
Primärschlüssels (bei SAP „Buchungskreis“) ( Berechtigungsprüfungen, Datenschutz): zB
Fimennr/Personalnr - bei einem Firmenwechsel wird eine neue Personalnr. vergeben.
Extern vergebenen Nummernkreisen: BLZ/Kontonummer  Eindeutigkeit
Aufträge, Rechnungen, etc.: Bestehen aus „Kopf“ und zugehörigen Positionssätzen (genaueres
s.u.).
3.4
Darstellung der Referenzen der Form 1:n und 1:1
Objekt A bezieht sich auf Objekt B in der Form n:1
OBJEKT A
n
„Semantik”
1
1
OBJEKT B

Primärschlüssel A

Primärschlüssel B

Attribut A1

Attribut B1

Attribut A2

Attribut B2

Attribut A3

...

Primärschlüssel B

Attribut By

...

Attribut Ax
Der Primärschlüssel des bezogenen „Fremdobjektes“ wird beim Objekt A hinterlegt und
 Fremdschlüssel
genannt.
Der Fremdschlüssel wird beim Objekt „gegenüber“ der „1“ abgelegt.
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-10
Beispiel Artikel / Warengruppe
Übung: Die Kunden werden von einem Vertreter betreut. Stellen Sie ein ER-Modell für
Kunden/Vertreter auf. Welche Probleme treten auf, wenn (fälschlicherweise) versucht wird,
die Kunden beim Vertreter zu hinterlegen?
 Eine falsche Modellierung (mehrere Attribute Kunde1, Kunde2, ... , KundeM) führt
zu Problemen beim Datenretrieval ( SQL-Abfragen s.u.), verschwendet ggf. Platz
(ungenutzte Attribute / Datenfelder) und führt ggf. zwangsläufig zu
Strukturveränderungen, wenn die Anzahl überschritten wird.
 Strukturänderungen sind später nur mit großem Aufwand zu realisieren, da
Programme und Formate des IuK-Systems an die neue Struktur angepaßt werden
müssen
Beispiel:
Jahr 2000 - Problematik (in vielen Datenbanken ist das Jahr nur 2-stellig abgelegt 
Jahr 2000 = „00“ und wird wie 1900 verarbeitet)
 Datenbanken müssen umdefiniert werden.  enormer Arbeitsaufwand, da auch
sämtliche Programme geändert werden.
Beispiel:
Einfügen eines neuen Attributes ( Feld in der Datenbank). Die Programme müssen das
Attribut verarbeiten. Bildschirm- und Druck-Layouts müssen angepaßt werden.
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-11
Objekt A bezieht sich auf Objekt B in der Form 1:1
Der Primärschlüssel des bezogenen „Fremdobjektes“ wird beim Objekt A oder Objekt B
hinterlegt (jedoch nur eine der beiden Möglichkeiten, um Redundanz zu vermeiden!)
entweder:
Alternative 1
1
OBJEKT A
„Semantik”
1
1
OBJEKT B

Primärschlüssel A

Primärschlüssel B

Attribut A1

Attribut B1

Attribut A2

Attribut B2

Attribut A3

Primärschlüssel A

...

...

Attribut Ax

Attribut By
oder
Alternative 2
OBJEKT A
1
„Semantik”
1
1
OBJEKT B

Primärschlüssel A

Primärschlüssel B

Attribut A1

Attribut B1

Attribut A2

Attribut B2

Attribut A3

...

Primärschlüssel B

Attribut By

...

Attribut Ax
 Alternative 1 kann problemlos in eine 1:n - Beziehung erweitert werden.
 Alternative 2 kann zu einer n:1 - Beziehung werden
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-12
 Bei der Wahl der Modellierung sollten mögliche künftige Entwicklungen
berücksichtigt werden. (zB heute Region-Vertreter 1:1 ggf später Region-Vertreter
n:1)
Beispiel: Ehe
entweder:
„ist verheiratet mit”
Mann
1
Frau
1

Mann - Nr.

Frau - Nr.

Name

Name

Adresse

Adresse

…

…

Mann - Nr.
oder:
„ist verheiratet mit”
Mann
1
Frau
1

Mann - Nr.

Frau - Nr.

Name

Name

Adresse

Adresse

…

…

Frau - Nr.
Welche Modellierung sollte gewählt werden, wenn nicht auszuschließen ist, daß die
Datenbank auch bei ausländischen Tochtergesellschaften eingesetzt wird (z.B. im Nahen
Osten)?
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-13
Übungsbeispiele:
a) Stellen Sie die folgende Situation in einem E-R Modell dar: Skizzieren Sie die Objekte,
Attribute, Referenzen und geben Sie die „Semantiken“ und „Kardinalitäten“ an:
Produkthierarchie:
Produkt - Produktgruppe - Produkthauptgruppe - Produktgeneralgruppe
Produkt
“gehört zu”
Produktgruppe






Produkt - Nr.
Produkt-Bezeichnung
Preis
...
PG - Kürzel
...




PG - Kürzel
PG-Bezeichnung
PHG - Nr.
…




PHG - Nr.
PHG-Bezeichnung
PGG - Nr.
…



PGG - Nr.
PGG-Bezeichnung
…
“gehört zu”
Produkthauptgruppe
“gehört zu”
Produktgeneralgruppe
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-14
b) Stellen Sie die folgende Situation in einem E-R Modell dar: Skizzieren Sie die Objekte,
Attribute, Referenzen und geben Sie die „Semantiken“ und „Kardinalitäten“ an.
Ein Unternehmen („Bitburger“) verkauft Produkte an Kunden. Die Kunden werden von
Vertretern betreut. Die Zuordnung der Kunden zu Vertretern findet nach Vertriebsgebieten
(„Regionen“) statt.
„kauft”
Produkt
m
„betreut“
n
„ist ansässig in”
n 





Kunden - Nr.
Name
Adresse
...
Region - Nr.
...
1
Vertreter
1



Kunde
„betreut”
1
Region
Name
Personal - Nr.
Region - Nr.





Region - Nr.
Region-Bezeichnung
Größe in qkm
Bevölkerungsanzahl
…
Alternativ könnte auch eine Beziehung „betreut“ zwischen Vertreter und Kunde modelliert
werden (im Diagramm rot und gestrichelt dargestellt). Da hierdurch ein „logischer Zirkel“
entstände, muß in diesem Fall auf eine der anderen Beziehungen (Kunde-Region oder
Vertreter-Region) verzichtet werden, um eine Redundanz zu vermeiden.
Bemerkung: Im Beispiel „Vater, Mutter, Kind“ (s.o.) liegt kein „logischer Zirkel“ vor. Weder
kann aus der Tatsache einer Ehe auf die Vater- oder Mutterschaft geschlossen werden, noch
müssen der Vater und die Mutter eines Kindes verheiratet sein. In diesem Fall müssen alle
Beziehungen modelliert werden:
Prof. Dr. J. Weinberg
3.5
IuK-Systeme A - SS 2000
Seite 3-15
Darstellung der Referenzen der Form n:m
Objekt A bezieht sich auf Objekt B in der Form n:m
„ist befreundet mit”
Mädchen
m
Junge
n
 Simone
 Jens
 Petra
 Oliver
 Iris
 Peter
 Nina
 Paul
(Skizze 10)
Hier entsteht das Problem, daß beide Objekte „viele“ Beziehungen haben können, und somit
nicht wie bei 1:1 - oder 1:n - Beziehungen ein Fremdschlüssel zur Beschreibung der
Beziehungen ausreicht.
Die Lösung besteht darin ein
 eigenes Objekt
für die Beziehung zu modellieren:
Durch das „Beziehungsobjekt“ Paar wird die n:m-Beziehung in zwei 1:n-Beziehungen
aufgelöst und kann (wie oben bei der 1:n Beziehung beschrieben ) dargestellt werden.
Beziehungsobjekte werden mit einer Raute dargestellt
In der Praxis finden sich selten „reine“ Beziehungsobjekte wie im oben dargestellten Beispiel.
Oft sind weitere Eigenschaften der Beziehung von Interesse, z. B. „besteht seit“, etc.
In solchen Fällen verwischt die Abgrenzung zwischen „echten“ Objekten und
„Beziehungsobjekten“. Statt der Darstellung mit einer „Raute“ kann in diesen Fällen auch ein
„Rechteck“ gewählt werden.
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-16
Beispiel Freundschaft
Mädchen
1

Mädchen - Nr.

Name

Adresse

…
n
Freundschaft
n
Junge
1

Jungs - Nr.

Freundschafts - Nr.


Name
Mädchen - Nr.


Adresse
Jungs - Nr.

…
(Skizze 11 „Freundschaften“)
Beispiel Mietwagen
Mietwagen
„gehört zu”
1
„schließt“
Mietvertrag
n
n
”
Kunde
1

Kunden - Nr.
Vertrags - Nr.

Name

Wagen - Nr.

Adresse
Typ

Kunden - Nr.

…

Farbe

Datum Mietbeginn

…

Datum Mietende

„Preis / Konditionen“

Wagen - Nr.

Marke


Modell

(Skizze 12 „Mietwagen“)
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-17
Beispiel: Ehe
“schließt
Mann
”1
n

Mann - Nr.

Geburtsdatum


Geburtsname

…
“schließt
Ehe
n
Frau
1

Frau - Nr.
Ehe - Nr.

Geburtsdatum

Mann - Nr.

Geburtsname

Frau - Nr.

…

Heiratsdatum

Ehenamen

Scheidungsdatum

…
(Skizze 13 „Ehe“)
Auch bei „Beziehungsobjekten“ sollte i.d.R. ein „nicht sprechender“ Primärschlüssel
verwendet werden (Ausnahmen s.u.).
Übung:
Gelegentlich wird die Ansicht vertreten, daß es bei „Beziehungsobjekten“ ausreichend (und
sinnvoll) sei, einen „sprechenden“ Primärschlüssel zu verwenden, der sich aus den beiden
Fremdschlüsseln der beiden Objekte der Beziehung zusammensetzt. (z.B. Ehe: Mann-Nr und
Frau-Nr.) Diskutieren Sie die Problematik.
Prof. Dr. J. Weinberg
3.6
IuK-Systeme A - SS 2000
Seite 3-18
Spezialfall: Hierarchische Beziehungen - Kopf/Positionssätze
Beispiel: Verkaufsartikel setzen sich aus einem oder mehreren Produkten zusammen, die ggf.
auch einzeln verkauft werden können:
 „Verkaufsartikel“
 „Sets“
 „Verkaufsstückliste“
 „Package“
z.B.:
 1 Kasten 20x0,5l Pils
 1 Kasten 20x0,5l Pils + 1 Glas („Tulpe 0,2 Dekor 4711) + 20 Bierdeckel
 1 Stereoanlage (= 1 Receiver, 1 CD-Player, 2 Boxen)
 ...
“besteht aus”
Verkaufsartikel
m
Produkt
n
Modellierung als Kopf - / Positionssatz
Kopfsatz = übergeordnetes Element
Verkaufsartikel

VA - Nr.

VA - Bezeichnung

VA - Preis

…
„besteht aus“
VA - Position
Primärschlüssel
„besteht aus“
Produkt

VA - Nr.

Produkt - Nr.

Positions - Nr.

…

Produkt - Nr.

Menge
(Skizze 14 „Verkaufsstückliste“) 
…
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-19
Verkaufsstückliste: Beispiel Werbepaket „1 Kasten Pils mit Glas und Bierdeckel“
besteht aus einem Kopfsatz, der die gemeinsamen Informationen enthält und drei Positionen
(je eine für jeden Artikel des „Sets“):
Kopf:
 VA - Nr.:
4711
 VA - Bezeichnung:
Werbepaket 20 x 0,5 l Pils mit Glas und Bierdeckel
 VK - Preis:
23,99 DM
Positionen:
 VA - Nr.:
4711
 Positionsnr.:
01
 Produkt - Nr.:
8580 (20 x 0,5 l Pils)
 Menge:
01
 VA - Nr.:
4711
 Positionsnr.:
02
 Produkt - Nr.:
1312 (Glas)
 Menge:
1
 VA - Nr.:
4711
 Positionsnr.:
03
 Produkt - Nr.:
4939 (Bierdeckel)
 Menge:
20
Bei diesen (nicht änderbaren) hierarchischen Beziehungen wird in der Regel der
Primärschlüssel des „Positionssatzes“ durch den Schlüssel des „übergeordneten“
Objektes („Kopfsatz“) und einer „Positionsnummer“ gebildet.
Primärschlüssel der Positionssätze: VA-Nr + Positionsnr.
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-20
Standard - Beispiel im Vertrieb: Kundenauftrag
Stufe 1:
“bestellt”
Kunde
Artikel
n
m
Stufe 2:
“erteilt”
Kunde
“besteht aus”
Auftrag
1
m
n
Artikel
n
Stufe 3:
Kunde
1
“erteilt”


Kunden - Nr.
Kunden - Name

…






Auftrags - Nr.
Kunden - Nr.
Bestelldatum
Bestellnr. des Kunden
Lieferdatum
Rechnungsrabatt






Auftragsnr.
Positionsnr.
Artikelnr.
Menge
Preis
Positionsrabatt

Artikel - Nr.



Artikel - Bezeichnung
Warengruppe
…
n
Auftrag (Kopf)
1
“besteht aus”
n
Auftragsposition
n
“beinhaltet”
Primärschlüssel
1
Artikel
(Skizze 15 „Auftrag“)
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-21
Beispiel Auftrag ( ACCESS Datenbank Auftrag.mdb in ...\WI-A\Uebung\Uebung7)
Beispiel der Tabellen
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Auftragsbestätigung über eine virtuelle Tabelle („View“, Abfrage“ s.u.)
Seite 3-22
Prof. Dr. J. Weinberg
3.7
IuK-Systeme A - SS 2000
Seite 3-23
Erweiterte Notation: Bedingte Kardinalitäten
Bislang wurde bei den „Kardinalitäten“ nur die maximal mögliche Anzahl der Beziehungen
betrachtet, nicht jedoch ob mindestens eine Beziehung bestehen muß (minimale Anzahl).
Beispiel:
 „Ehe“: nicht verheiratete Personen kommen vor
 „Mitarbeiter“: Mitarbeiter ohne Arbeitsplatz?
 „Auftrag“: muß (mindestens) eine Position enthalten
Diese Frage wird entweder bei den „Gültigkeitsregeln“ ( Integrität) behandelt oder mittels
einer Erweiterung der x:y Notation:
1. Alternative: Integritätsregel („Muß-Feld“, „Gültigkeitsregel“)
 1:1, 1:n, n:m keine Auskunft über Mindestzahl, „kein Eintrag“ ist zulässig
 „Eintrag erforderlich“ wird als „Gültigkeitsregel“ formuliert
2. Alternative 1, C, M - Notation
 1:1, 1:n, n:m bedeuten „mindestens“ eine Beziehung
 ist keine Beziehung notwendig wird dies durch ein c (=“conditional“, bedingt)
angezeigt: c:1, c:c, c:n, 1:nc, c:nc, nc:nc
Beispiele:
 Kunden/Vertreter
 Mitarbeiter/Gehaltskonto
 Produkt/Gebinde
Achtung:
Der Rechner läßt keine Ausnahmen zu. Wenn Ausnahmen möglich sein sollen, darf
keine (strenge) Gültigkeitsregel formuliert werden. In diesen Fällen kommen „Hinweis“Regeln zum Einsatz, die Ausnahmen zulassen, jedoch eine Bestätigung anfordern.
 Da „Hinweis“-Regeln in der 1,C,M-Notation (Alternative 2) nicht vorgesehen sind, ist
die 1. Alternative „praxisnäher“.
Wird kein Eintrag vorgenommen bleibt das Attribut oder der Verweis „leer“. In der
Datenbank wird dies durch einen „Null-Wert“ gekennzeichnet.
 Null-Wert bedeutet „kein Eintrag“=“N/V“=“Nicht vorhanden“ (engl. null=ungültig sprich „nall“) und muß von der Zahl 0 unterschieden werden! (Beispiel: Preis=0)
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-24
Konventionen (für den Kurs):
 Objekte werden in Rechtecken dargestellt
 Beziehungsobjekte werden durch Rauten dargestellt
 Attribute werden unter den Objekten aufgelistet
 Primärschlüssel werden unterstrichen
 Fremdschlüssel werden „gepunktet“ unterstrichen weisen mit Pfeil auf den
bezogen (Teil-) Primärschlüssel
 Beziehungen werden durch Pfeile dargestellt
 „Semantiken“ werden über die Beziehungspfeile geschrieben
 „Kardinalitäten“ werden an den „Endpunkte“ der Pfeile angegeben
 Es muß vermerkt werden ob „erweiterte“ Kardinalitäten 1,n,c, (c=conditional 
„Null-Wert“ erlaubt) oder entsprechende „Gültigkeitsregeln“ („Eingabe
erforderlich“) verwendet werden.
Hinweis:
Null-Wert bedeutet „kein Eintrag“=“N/V“=“Nicht vorhanden“ (engl. null=ungültig - sprich
„nall“) und muß von der Zahl 0 unterschieden werden!
Ausnahmen:
Zur besseren Übersicht werden ggf. manche Teile nur angedeutet (insbesondere werden oft
nicht alle Attribute dargestellt) oder nur ein Ausschnitt des Modells („Fenster“) betrachtet.
Prof. Dr. J. Weinberg
3.8
IuK-Systeme A - SS 2000
Seite 3-25
Übergang Entity-Relationship Modell  Datenbank
„Wie werden die Objekte im Rechner gespeichert?“
Aus der E-R Modell wird die Struktur der Datenbank abgeleitet:
 Objekt
Datei (Tabelle)
 Primärschlüssel
 Attribut
Feld
 Fremdschlüssel
 Formaler Aufbau der Datei: Dateibeschreibung (in ACCESS: „Entwurf“)
In der Datei werden die „konkret existierenden“ Objekte gespeichert
 Datensätze
Bemerkung:
In der Terminologie wird in der Praxis i.d.R. nicht zwischen der
 formalen Beschreibung der Objekte
 den konkreten Objekten
unterschieden.
Beispiel:
Das Objekt Student ist beschrieben durch die Attribute und Schlüssel (Felder):
Die „konkreten Objekte“ (gespeicherten Studenten) sind:
Hinweis:
Beim Erstellen der Datenbank sind ergänzende Festlegungen erforderlich
 formale Feldbeschreibungen (s.u.)
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-26
 Integritätsregeln („Gültigkeitsprüfungen“, s.u.)
3.9
Relationale Datenbanken
Bemerkung: Es gibt weitere „Typen“ von Datenbanken: z.B. „hierarchische Datenbanken“
oder „Netzwerk Datenbanken“, die jedoch zunehmend auf relationale Datenbanken umgestellt
werden. In der Praxis handelt es sich dabei entweder um „Altlasten“ oder es gibt im Einzelfall
technische Gründe („Performance“ = „Zugriffsgeschwindigkeit“) für diese speziellen
Lösungen. Die Verwaltung und der Zugriff auf die Daten erfordert bei diesen Datenbanken
i.d.R „Spezialwissen“ und ist „EDV-Technikern“ vorbehalten.
Eine relationale Datenbank wird durch „Tabellen“ (Dateien) gebildet, die „normalisiert“ sind,
d.h. folgenden Regeln entsprechen:
 redundanzfrei
(keine mehrfache Speicherung gleicher Information)
 keine „Defekte“ (Anomalien) bei Speichern, Löschen und Verändern der
Datensätze
 „korrekte“ Beschreibung des Ausschnitts der Realität
 Diese Anforderungen werden „automatisch“ erfüllt, wenn der Datenbank ein
korrektes Entity-Relationship Modell zugrunde liegt! (inhaltlicher Ansatz)
 In der Praxis werden aus „Performance“ - Gründen im Einzelfall gezielt redundante
Daten gespeichert ( „Vorverdichtung“)
 In der Literatur findet sich i.d.R. ein theoretischer Ansatz: „1. - 5. Normalform“, der
eine mathematisch formale Methode darstellt, die Anforderungen zu erfüllen.
 Eine Weiterentwicklung der relationalen Datenbanken sind „Objektorientierte
Datenbanken“, die sich bislang in der Praxis nur selten finden.
(siehe z.B. A. Maier, Wüst, Th: Objektorientierte Datenbanken)
 Speziell für den Einsatz als () Data-Warehouse wurden „Multidimensionale
Datenbanken“ entwickelt, die vorverdichte Summen (redundant) abspeichern und
für einen schnellen flexiblen Zugriff optimiert wurden ( OLAP).
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-27
Formal besteht eine relationale Datenbank aus folgenden Elementen.
 Datenbank
(Database, Zusammenfassung aller Dateien eines Systems)
 Datei (Tabelle)
(file, Zusammenfassung aller gleichartigen Datensätze)
 Datensatz (record, logische Einheit = „konkretes Obekt“
 Datenfeld (kleinste Informationseinheit)
(Skizze 16)
Felder entsprechen Attributen, Primär- und Fremdschlüsseln des E-R Modells. Sie werden
durch folgende Angaben festgelegt (Feldbeschreibung):
 Feldname ( Attribut)
 Typ
 Länge
 Integritätsregeln
Typ (Bsp):
 Zeichen („Character“)
 Zahl (Ganzzahl (Integer), Dezimalzahl, Fließkomma, ..)
 Objekt (Graphik, Audio, Video, ...)
Länge:
 Zeichen: (max) Anzahl Zeichen
 Ganzzahl (Integer). (max) Anzahl Stellen
 Dezimalzahl: Anzahl Vor-, Nachkommastellen
 Fließkommazahl: Anzahl „signifikanter Stellen“
Integritätsregeln (Auswahl)
 Zweck: Eingabe- oder Verarbeitungsfehler automatisch entdecken
 Abhängig vom Feld, anderen Feldern, anderen Dateien, ...
 werden automatisch vom Datenbank Verwaltungsprogramm überprüft
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-28
Abhängig vom Feld
 Wertebereich
 Eingabe erforderlich: „Muß-Feld“ ( Fehler), „ Soll-Feld“ ( Hinweis)
Beispiele Wertebereich:
 von - bis: Preis zwischen 1,00 und 20,00 DM, Gewicht > 50, ...
 zulässige Werte: Haarfarbe blond, braun, schwarz, grün, ...
 Formel
Beispiele „Eingabe erforderlich“:
 Kundenname muß eingegeben werden
 Vertreternummer „soll“ eingegeben werden, wenn nicht  Hinweis, der bestätigt
werden muß
Abhängig von anderen Felder (der selben Datei)
 Wertebereich
 Eingabe erforderlich: „Muß-Feld“ ( Fehler), „ Soll-Feld“ ( Hinweis)
Beispiele:
 Wenn Preis < 100 dann Rabatt < 3 %, sonst < 5 %
 Wenn Warengruppe = ABC dann Preis zwischen 50 und 500 DM
 Wenn Vertreter zugeordnet  Provisionssatz erforderlich
Abhängig von Datensätzen und Feldern anderer Dateien
 Wertebereich
 Eingabe erforderlich: „Muß-Feld“ ( Fehler), „ Soll-Feld“ ( Hinweis)
 referentielle Integrität (s.u.)
Beispiele:
 Personalstamm. Wenn Ehegatte berufstätig dann Steuerklasse III, IV, V oder VI
 Auftrag: Wenn Kunde im „feindlichen“ Ausland und Produkt „Kriegswaffe“ (zB
Verschlüsselungssoftware) dann Ausfuhrgenehmigung erforderlich
Prof. Dr. J. Weinberg
IuK-Systeme A - SS 2000
Seite 3-29
3.10 Referentielle Integrität
Bei einer Referenz muß das bezogene Objekt vorhanden sein:
 „gültiger Fremdschlüssel“
(Skizze 16 Vertreter - Kunde:
Der durch die Vertreter Nr eindeutig bestimmte Vertreter muß existieren)
Die referentielle Integrität kann durch folgende Aktionen verletzt werden:
 falsche Eingabe ( Prüfung)
 Löschen des bezogen Objektes
 Verändern des Primärschlüssels des bezogen Objektes ( falsche Modellierung!)
Beispiel:
Welche Konsequenz hat das Ausscheiden des Vertreters Maier (Vertreternr. 4711)?
 Löschen des Vertreters: (Stammsatz) „hartes“ / „weiches“ Löschen
 Was geschieht mit den (ehemaligen) Kunden von „4711“
 Möglichkeiten:
 Ersatz: Müller (4813) statt Maier  (immer?) automatisch / manuell
 vorläufig kein Vertreter  „Null-Wert“ (n/a, n/v, nicht zugeordnet)
Hinweis: Unterschied „Null-Wert“ von Wert=0 (Beispiel: Preis!)
Hinweis: „Trigger“ können ggf. die referentielle Integrität „überwachen“ und je nach
„Entscheidungsregel“ Warnungen oder Hinweise geben, automatische Aktionen veranlassen
oder im „Extremfall“ eine „Rückabwicklung“ (Roll-Back“) durchführen.