Skriptum ADAT Datenmodellierung

Datenmodellierung
Haas, Resch
Skriptum ADAT
Datenmodellierung
August 2003
Resch Andreas
1. EINLEITUNG ............................................................................................................................ 3
2. DREI SCHICHTENMODELL EINES DATENBANKS YSTEMS ..................................................... 5
2.1. LOGISCHE S CHICHT ( EXTERNES S CHEMA ).................................................................................. 5
2.2. KONZEPTIONELLE S CHICHT (KONZEPTIONELLES SCHEMA ) ............................................................ 6
2.3. PHYSISCHE SCHICHT ( INTERNES S CHEMA ) ................................................................................. 7
3. HISTORISCHER ÜBERBLICK DATENBANKSYSTEME............................................................. 8
3.1. DATEIEN .............................................................................................................................. 8
3.1.a. sequentielle Datenträger ................................................................................................ 9
3.1.a. Datenträger mit direktem Zugriff (ab 1958) ...................................................................... 9
3.1.c. VSAM (erweitertes Dateisystem) .................................................................................... 9
3.2. DATENBANKSYSTEME ............................................................................................................. 9
3.2.a. hierarchische Datenbanken (1960)................................................................................10
3.2.b. Netzwerkdatenbank ......................................................................................................11
3.2.c. relationale Datenbanken ...............................................................................................11
3.2.d. objektorientierte Datenbanken (OODB)..........................................................................11
3.2.e. Textdatenbanken .........................................................................................................12
3.2.f. XML / XSLT ..................................................................................................................12
4. EINFÜHRUNG IN DIE DATENMODELLIERUNG.......................................................................13
4.1. GRUNDLEGENDE B EGRIFFE....................................................................................................13
4.2. BEZIEHUNGEN (R ELATIONEN ) .................................................................................................14
4.3. PRIMARY KEY (P RIMÄRSCHLÜSSEL ).........................................................................................14
4.4. SECONDARY KEY (F REMDSCHLÜSSEL ) .....................................................................................15
4.5. GRAD (K ARDINALITÄT) EINER B EZIEHUNG .................................................................................17
4.5.1. Kardinalität 1:1.............................................................................................................17
4.5.2. Kardinalität 1:N ............................................................................................................17
4.5.3. Kardinalität M:N ...........................................................................................................18
5. NOTATIONSFORMEN EINES DATENMODELLS ......................................................................18
5.1. CHEN D IAGRAMME................................................................................................................18
6. VORGEHENSWEISEN BEI DER DATENMODELLIERUNG .......................................................20
6.1. DISZIPLINIERTES TOP / DOWN.................................................................................................20
6.2. "JOJO TECHNIK " ...................................................................................................................20
7. NORMALFORMEN ..................................................................................................................21
7.1. INTEGRITÄTSBEDINGUNGEN....................................................................................................21
7.1.1. Semantische Integrität ..................................................................................................22
-1-
Datenmodellierung
Haas, Resch
7.1.2. referentielle Integrität ....................................................................................................22
7.1.3. operationale Integrität ...................................................................................................23
7.2. UNNORMALISIERT (N ULLTE N ORMALFORM) ...............................................................................23
7.3. DIE 1. NORMALFORM ............................................................................................................24
7.4. DIE 2. NORMALFORM ............................................................................................................25
7.4.1. Funktionale Abhängigkeit (ein Attribut)...........................................................................25
7.4.2. Funktionale Abhängigkeit (mehrere Attribute).................................................................26
7.4.3. Vorgehensweise:..........................................................................................................26
7.5. DIE 3. NORMALFORM ............................................................................................................27
7.5.1. transitive Abhängigkeit..................................................................................................27
8. UMSETZUNG VON ER MODELLEN IN RELATIONALE MODELLE (NACH DER KARDINALITÄT)
29
8.1. 1:N BEZIEHUNG ...................................................................................................................29
8.2. 1:1 BEZIEHUNG ....................................................................................................................29
8.3. M:N BEZIEHUNG ...................................................................................................................30
9. NULL / FAKTUM "LEER".........................................................................................................31
10. GENERALISIERUNG (SUPER / SUBTYP) ..............................................................................32
11. TEXTANALYSE.....................................................................................................................32
11. TEXTANALYSE.....................................................................................................................33
11.1. DAS R EGELWERK DER TEXTANALYSE.....................................................................................33
11.2. EIN EINFACHES B EISPIEL ......................................................................................................39
12. DATENMODELLIERUNG MIT ERWIN ....................................................................................41
13. BÄUME IN TABELLEN ..........................................................................................................42
-2-
Datenmodellierung
Haas, Resch
1. Einleitung
Überall dort, wo es um die Aufbewahrung oder Verarbeitung von großen Datenmengen geht, sind
Datenbanksysteme im Spiel. Diese "Informations - Lager" sind darauf spezialisiert, den Umgang mit
großen Datenmengen zu vereinfachen. Dazu wird meist eine standardisierte Schnittstelle (SQL, ...)
zur Verfügung gestellt.
Folie: (Datenmodellierung) Datenbanksystem
Was versteht man eigentlich unter einem Datenbanksystem ?
Es gibt keine klare Definition - Es ist ein System zur Beschreibung, Speicherung und
Wiedergewinnung von Daten.
Ein Beispiel für ein solches Datenbanksystem ist etwa Microsoft Access.
Ein Datenbanksystem besteht also aus zwei Komponenten: Der Datenbasis und dem
Datenbankmanagementsystem.
Ein Datenbankmanagementsystem ist für die Verarbeitung der Daten und die Wartung der
Datenstrukturen zuständig.
Was ist eine Datenbasis bzw. Datenbank ?
Eine Datenbank ist eine Ansammlung von Daten, zum Beispiel im betrieblichem Umfeld.
Die zu Grunde liegende Datenstruktur muss ausreichend gut an das Problem (Aufgabenstellung) des
Benutzers angepasst sein.
Beispiel:
Die Bibliothekarin verwaltet die Aus - und Rückgabe von Büchern in der Schul-Bibliothek. Die
tägliche Arbeit (Anforderung) und Realisierung (Abbildung) in der Datenbank müssen
übereinstimmen!
- Wer darf Bücher entlehnen?
- gibt es eine maximale Bücheranzahl?
- darf ein Buch entliehen werden, wenn noch viele ausständig sind?
- werden Gebühren verrechnet?
- werden die Adressen und Telefonnummern erfasst?
- darf ein Entlehner mehr als eine Adresse oder Telefonnummer haben?
....
Der Prozeß, indem diese ausreichend passende Datenstruktur entworfen wird nennt man
Datenmodellierung - oder etwas theoretischer:
Das Abbilden eines relevanten Ausschnitts der Umwelt in einem technischen System.
-3-
Datenmodellierung
Haas, Resch
Um eine benutzbare Anwendung zu realisieren sind aber folgende Schritte notwendig:
Folie: (Datenmodellierung) Schritte zur Realisierung
N
Analyse:
- Anforderungsanalyse (-> Projektentwicklung)
Die Anforderungsanalyse ist eine Art Brainstorming, indem wir den gesamten für uns relevanten
Wirklichkeitsausschnitt genau ansehen.
•
•
•
•
Dazu holen wir alle nötigen Informationen über die Anforderungen ein
informieren uns über Randbedingungen auf deren Gestaltung wir keinen Einfluß haben
(langsames Netzwerk, Technik der PC`s, Firmen Logos, ...)
bestimmen die Grenzen des Systems und
seine geplante Funktionalität.
Die Anforderungsanalyse ist in der Regel durch die Angabe des Übungsbeispiels vorweg genommen.
- ER - Modelle
Die Anforderungsanalyse wird zumeist in (technischer) Umgangssprache niedergeschrieben. In dieser
Form können wir aber keine exakten Aussagen über den Umfang und die Leistungsfähigkeit treffen.
Wir benötigen eine exakte Notationsform, die zum einen für die Kunden und Entwickler verständlich ist
und auf der anderen Seite so genau ist, dass wir daraus ein konkretes Syste, implementieren können.
Mit diesen beiden Schritten werden wir uns zu Beginn beschäftigen!
N
Design
- Umsetzung des ER Modells in Relationen.
Diese kann man sofort als Tabelle realisieren, wenn da nicht noch eine Kleinigkeit wäre:
- Normalisierung
Die Normalisierung ist eine Optimierung und ein entfernen von Anomalien.
N
Implementierung
Nun bewegen wir uns in einem konkreten Datenbanksystem und erstellen dort Tabellen bzw. ändern
den Inhalt der Tabellen.
-4-
Datenmodellierung
Haas, Resch
2. Drei Schichtenmodell eines Datenbanksystems
Sehen wir uns nun den Aufbau bzw. die Vorgehensweise zum Arbeiten mit Datenbanksystemen vo n
einer anderen Seite an. Wir gehen nun auf eine Sichtweise die auf unterschiedliche
Abstraktionsebenen bzw. Anwendungsschichten zielt.
Das drei Schichtenmodell (oder auch oft Drei-Schema-Konzept) wurde 1975 vom Standard Planing
and Requirements Comitee (SPARC) und dem American Standards Comite on Computers and
Information Processing (ANSI/X3) als Vorschlag für die Standardisierung von Datenbankarchitekturen
entwickelt.
Folie: (Datenmodellierung) Drei Schichtenmodell
Die Beschreibung der Daten erfolgt auf drei verschiedenen Ebenen, die unterschiedliche Sichtweisen
auf die Daten ermöglichen und gleichzeitig für Datenunabhängigkeit sorgen.
2.1. logische Schicht (externes Schema)
Das externe Schema ist die Sicht des Benutzers auf die Daten. Unter einem externen Schema
versteht man anwendungsbezogene Sichten auf Teilbereiche des konzeptionellen Schemas. Dem
Benutzer werden dabei die Daten in einer für ihn geeigneten Form zur Verfügung gestellt.
Beispiel:
In einer Datenbank sind Personaldaten gespeichert. Bestimmten Mitarbeitern darf man nur den
Name und die Anschrift der Personaldaten zugänglich machen, während anderen Mitarbeitern der
Zugriff auf die gesamten Personaldaten möglich sein muss.
Das externe Schema wird unter Zuhilfenahme von einer Datenmanipulationssprache (DML), die vom
Datenbanksystem zur Verfügung gestellt wird, aus dem konzeptionellen Schema abgeleitet.
Dem Benutzer werden mittels DML Sprachelemente zur Kommunikation mit dem Datenbanksystem
zur Verfügung gestellt, die ihm das Wiederauffinden und Ändern von Daten, d.h. die
Datenmanipulation, ermöglichen.
Der Benutzer muss keine Kenntnisse über den internen Aufbau einer Datenbank besitzen. Für ihn ist
es unerheblich, welche Daten in welchen Tabellen abgespeichert werden.
Beispiel:
Wenn man eine Reise - über das Internet - buchen will, können wir, in diesem Beispiel, über die
Eingabefelder: Erwachsene, Abreise ab, Reisedauer, Reiseart, Nur Schnäppchen und Preis in DM
unseren Reisewunsch spezifizieren.
Das Buchungssystem listet eine Auswahl aller möglichen Reiseangebote auf.
-5-
Datenmodellierung
Haas, Resch
Um eine Reise zu buchen müssen wir nicht wissen wie die Datenbank intern aufgebaut ist,
sondern nur das Buchungssystem bedienen können.
Folie: (Datenmodellierung) logische Schicht
2.2. konzeptionelle Schicht (konzeptionelles Schema)
Die konzeptionelle Schicht nimmt im 3-Schichtenmodell eine zentrale Stellung ein.
Es wird jener Teil der realen Welt, der für eine Anwendung relevant ist, abgebildet. Das konzeptionelle
Schicht stellt eine Gesamtsicht auf die Daten eines Unternehmens auf logischer Ebene dar, ohne
darauf Rücksicht zu nehmen, wie die Anwendung später realisiert wird und welches
Datenbankmanagementsystem zum Einsatz kommt.
Auf konzeptioneller Ebene wird festgelegt, was in der Datenbank gespeichert werden soll, d.h. welche
Daten gespeichert werden sollen, wie diese genau aussehen und wie die Daten untereinander in
Beziehung stehen.
Folie: (Datenmodellierung) konzeptionelle Schicht
Beispiel:
Beim Entwurf des konzeptionellen Schemas eines Flugbuchungssystems wird festgelegt, dass es
einen Entitätstypen KUNDE mit den Attributen "Kundennummer", "Name", "Vorname" gibt.
Außerdem besteht zwischen den Entitätstypen KUNDE und FLUGBUCHUNG eine Beziehung.
Die Attribute "Haarfarbe" oder "Körpergewicht" des Entitätstypen KUNDE sind hingegen für die
Erstellung eines Flugbuchungssystems nicht relevant und werden daher auch nicht beim Entwurf
des konzeptionellen Schemas berücksichtigt.
-6-
Datenmodellierung
Haas, Resch
Charakteristisch für das konzeptionelle Schema ist, dass es einen relativ stabilen Bezugspunkt im
gesamten Unternehmensmodell darstellt. Änderungen der externen Sicht wie beispielsweise die
Entwicklung neuer Anwendungsprogramme, berühren das konzeptionelle Schema nicht.
Das ist also unser das Hauptthema für die nächste Zeit!
2.3. physische Schicht (internes Schema)
Das interne Schema ist die physikalische Speicherung der Daten auf den Datenträgern.
Es wird der mögliche Zugriff auf die Daten, d.h. wie und wo die Daten gespeichert werden, definiert.
Neben der Speicherung der Daten in einer zentralen Datenbank ist auch der Einsatz verteilter
Datenbanken möglich. Vom internen Schema ist die Performance einer Datenbank sehr stark
abhängig.
Beispiel:
Auf dieser Ebene wird festgelegt, in welcher Reihenfolge die Felder "Kundennummer", "Vorname",
"Name" und "Ort" gespeichert werden und wie die Dateiorganisation aussieht.
•
•
•
•
Wie ist die Datenbank (Dateiorganisationsformen, ...) realisiert?
Wie werden die Daten auf einem Datenträger gespeichert?
Welches Betriebssystem wird verwendet?
Wie kann eine Abfrage möglichst schnell bearbeitet werden?
Ein wichtiger Aspekt der Relationalen Datenbanken ist, daß die physische und die konzeptionelle
Schicht NICHT von einander abhängen dürfen:
Der Zugriff auf die Daten erfolgt nur mit Bordmitteln des Datenbanksystems, ein direkter Zugriff (von
aussen ist NICHT möglich!).
Wenn die physische Schicht ausgewechselt wird (SAP: unterschiedliche Datenbanksysteme erlaubt),
dann funktioneren alle Abfragen etc. ohne Änderung - die konzeptionelle und externe Schicht sind
davon NICHT betroffen!
Mit diesen Aufgabenstellungen werden wir uns bei den Datenträgern und der
Datenspeicherung beschäftigen!
-7-
Datenmodellierung
Haas, Resch
3. Historischer Überblick Datenbanksysteme
3.1. Dateien
Bis Ende der 70iger Jahre war die klassische, dateiorientierte Datenhaltung vorherrschend.
Charakteristisches Merkmal der Dateiorientierung ist, dass für jede Anwendung die Daten in
separaten Dateien gespeichert werden (siehe Abb. 1). Dies führt dazu, dass eine erhebliche Anzahl
von Insellösungen entsteht und viele Daten redundant gespeichert werden.
Beispiel:
In Unternehmen A sind 200 Mitarbeiter beschäftigt.
Personaldatei
Jeder Mitarbeiter erhält monatlich ein bestimmtes Gehalt.
Die monatliche Gehaltsabrechnung erfolgt über ein Lohnverrechnungsprogramm, welches als
Datenbasis eine Personaldatei verwendet. In dieser sind neben der Mitarbeiternummer der Name des
Mitarbeiters, die Abteilungsnummer, die Bezeichnung der Abteilung und Angaben zum Gehalt des
Mitarbeiters gespeichert.
Mitarbeiter
nummer
1
2
3
Name
Vorname
MUELLER HANS
MAIER
PETER
MUELLER FRANZ
Abteilungs
nummer
IV
IV
V
Abteilungsname
Gehalt
MARKETING
MARKETING
VERKAUF
23990
23990
25987
Projektdatei
Das Unternehmen ist in mehrere Abteilungen gegliedert, wobei jede dieser Abteilungen ein oder
mehrere Projekte bearbeitet.
Jeder Mitarbeiter ist an ein oder mehreren Projekten im Unternehmen beteiligt. In einer Projektdatei
sind sämtliche relevanten Informationen zur Projektverwaltung gespeichert. Zu jedem Mitarbeiter gibt
es neben den Mitarbeiterdaten, Informationen zur Abteilung sowie zu sämtlichen Projekten, an denen
ein Mitarbeiter beteiligt ist.
Mitarbeiter
nummer
1
2
3
Name
Vorname
MUELLER HANS
MAIER
PETER
MUELLER FRANZ
Abteilungs
nummer
IV
IV
V
Abteilungsname
MARKETING
MARKETING
VERKAUF
Projektnummer
A
A
B
Projektname
E-COMMERCE
E-COMMERCE
INTERNET
-8-
Datenmodellierung
Haas, Resch
Nehmen wir an, Herr Müller Hans wird befördert und wechselt in die Finanzabteilung. Dies erfordert
von der Personalabteilung eine Aktualisierung der Daten. Aufgrund der redundanten Datenhaltung,
muss die Projektdatei ebenfalls verändert werden, da sonst inkonsistente Daten die Folge sind.
3.1.a. sequentielle Datenträger
Zunächst gab es nur Magnetbänder (sequentielle Organisation der Daten - Satz für Satz in
vorgegebener Reihenfolge verarbeitbar).
Ändern der Reihenfolge (sortieren) erfordert ein Umschreiben / Neuschreiben der Daten!
z.B.: Daten nach Sozialversicherungsnummer sortiert - Daten nach Postleitzahlen sortieren erfordert
das Umschreiben der Daten.
-> Nun haben wir aber den gleichen Datenbestand gleich zweimal - der Unterschied ist nur die
Sortierung!
Um Probleme bei der Bearbeitung zu vermeiden dürfen aber keine Redundanzen vorhanden sein.
Dann ist nämlich die Datenintegrität gewährleistet.
z.B.: Mitarbeiter
Zwei Personen heiraten -> ein Familienname muß geändert werden!
Wenn wir aber auf eine Kopie vergessen, dann hat eine Person zwei unterschiedliche Namen.
Analog beim Löschen - in einem Datenbestand Datenbestand gelöscht, in einem anderen aber nicht.
3.1.a. Datenträger mit direktem Zugriff (ab 1958)
Daten nach einem Kriterium sortiert speichern, aber wahlfrei auf diese Daten zugreifen.
Sozialversicherungsnummer ist Schlüssel - direkt über diesen Begriff auf die Daten zugreifen!
(indexsequentielle Organisation).
-> ohne Duplizieren von Daten Zugriff möglich, aber der direkte Zugriff ist nur über einen Schlüssel
möglich
3.1.c. VSAM (erweitertes Dateisystem)
Wie Datenträger mit direktem Zugriff, aber Zugriff über mehrere Schlüsselbegriffe. Teil des
Betriebssystems.
-> Eine Datenbasis, aber Zugriff über mehrere Schlüsselbegriff
3.2. Datenbanksysteme
Erst durch die Entwicklung von Datenbanksystemen wurde die anwendungsübergreifende Nutzung
von Daten ermöglicht. Es kam zu einer Datenintegration. Allmählich erkannte man die Notwendigkeit
der zentralen Sicht auf die Unternehmensdaten.
-9-
Datenmodellierung
Haas, Resch
Vorteile der zentralen Datenhaltung:
•
Verringerung von Datenredundanzen
Der Einsatz eines Datenbankmanagementsystems ermöglicht die Haltung integrierter
Datenbestände, d.h. das Zusammenfassen aller in einem Unternehmen relevanten Daten.
Durch die zentrale Datenhaltung kann die Mehrfachspeicherung von Daten weitgehend
verhindert werden.
•
Datenintegrität
Der Begriff "Datenintegrität" ist eine zusammenfassende Bezeichnung für Datenkonsistenz,
Datensicherheit und Datenschutz. Datenintegrität ist dann gegeben, wenn die Daten in einer
Datenbank korrekt und vollständig sind. Dazu werden wir noch einiges mehr höhren!
Mögliche Gründe für Verletzungen der Datenintegrität können fehlerhafte Benutzereingaben,
aber auch Hard- beziehungsweise Softwarefehler sein. Beispielsweise kann in einer
Datenbank einer Abteilung kein Mitarbeiter zugeordnet sein oder es ist für einen bestimmten
Mitarbeiter eine wöchentliche Arbeitszeit von 400 Stunden anstelle von 40 Stunden
gespeichert.
Durch eine zentrale Datenhaltung wird die Überprüfung des Datenbestandes erheblich
erleichtert.
•
Datenunabhängigkeit
Ein entscheidender Vorteil, der durch den Einsatz von Datenbanksystemen erzielt werden
kann, ist die Datenunabhängigkeit. Von Datenunabhängigkeit spricht man dann, wenn eine
Trennung zwischen der logischen Datenstruktur und ihrer physischen Realisierung erfolgt.
•
Flexibler Gebrauch der Daten
Durch die Integration sämtlicher für ein Unternehmen relevanter Daten können diese relativ
einfach nach unterschiedlichen Gesichtspunkten verknüpft werden.
3.2.a. hierarchische Datenbanken (1960)
Auf Großrechnern realisiert.
Vertreter:
DL1 (Data Language 1 - IBM), IMS (Information Management System - IBM)
Sehr schnell im Zugriff (noch heute), aber ein sehr starrer Aufbau. Fixe Verweise (Adressen!) auf
vordefinierte Beziehungen.
Erweiterung der Beziehungen etc. sind nicht einfach realisierbar.
Noch Verbreitung in Banken und Versicherungen - keine Neuentwicklungen, aber Bedarf an Wartung!
- 10 -
Datenmodellierung
Haas, Resch
3.2.b. Netzwerkdatenbank
Vertreter:
Codasyl, IDS, UDS
Bei den hierarchischen Datenbanken kann es zu Duplikaten kommen, wenn die Daten nicht
hierarchisch organisiert sind! In Netzwerkdatenbanken sind auch solche Daten darstellbar geworden,
aber unübersichtlich und schwierig.
3.2.c. relationale Datenbanken
Edgar F. Codd (70-er Jahre - IBM) erkannte die Limitationen bestehender Datenbanksysteme.
1975 Formulierung der 12 Codd`schen Regeln (und 3 Integritätsregeln) und Entwicklung eines
Prototypen "System R" (Daraus hat sich später ORACLE entwickelt). Die Abfragesprache hieß Sequel
(Vorläufer von SQL) und eine Abfrage Oberfläche QBE (Query by Example).
Diese Gruppe hat sich getrennt in Oracle und IBM (DB2).
DB2 erste SQL Datenbank (speichert Daten in VSAM Dateien - Filehandlingsystem)
Es wesentlicher Unterschied zu den beiden vorigen Datenbanksystemen ist, daß bei den Relationalen
Datenbanken Beziehungen durch den Wert einen Attributes, und nicht durch eine fixe, physische
Adresse dargestellt werden. Als Beispiel wird noch später das Konzept des Fremdschlüssels erläutert.
Weitere Vertreter:
ACCESS (entspricht nicht allen Codd' schen Regeln), SQL Server, Informix, Ingres, Progres, dBase,
mySQL, Gupta
C.J.Date: 12 Regeln für verteilte Datenbanksysteme
Hinweis:
SQL (Structered Query Language) ist eine genormte Zugriffssprache, allerdings versteht jedes
Datenbanksystem einen eigenen Dialekt!
Eigenschaften einer relationalen Datenbank sind:
•
•
kompakte Speicherung (kein unnützes Belegen von Speicherplatz)
keine Redundanz (ein und das selbe Faktum sind mehr als einmal gespeichert) und damit
garantierte Integrität der Daten
Beispiel:
Mitarbeiterdaten, Abteilungsnummer und -Bezeichnung kommt bei jedem Mitarbeiter vor. Wenn
die Bezeichnung der Abteilung geändert wird, dann müssen alle Datensätze durchsucht und die
Abteilung geändert werden
•
•
•
•
Ein und die selbe Entität darf nicht zweimal gespeichert werden (laufende Nummer beim
Schlüssel!)
Alle Teilschritte einer Änderungen müssen zu einem Zeitpunkt vollständig oder überhaupt
nicht durchgeführt werden (Transaktion) - Beispiel Abbuchung von einem Konto auf ein
anderes: TAN (Transaktionsnummer beim TeleBanking)
Kein Zugriff auf Daten außer durch "Bordmittel" des Datenbanksystems
Integrität:
3.2.d. objektorientierte Datenbanken (OODB)
Derzeit noch keine etablierte Systeme im betrieblichem Umfeld. Zumeist findet man hybride
Datenbanksysteme (Beispiel Caché).
- 11 -
Datenmodellierung
Haas, Resch
3.2.e. Textdatenbanken
Unterschied Text / strukturierte (formatierte) Daten:
Bei strukturierten Daten ist der Aufbau ganz exakt definiert. Für jeden Datensatz ist genau bekannt
welche Felder mit welchem Typ zu welcher Länge und welchem Namen vorhanden sind. Die kleinste
Einheit, auf die zugegriffen werden kann heißt Feld.
Eine Textdatenbank hat keine definierte Struktur, der ganze Text muß jedes mal wieder analysiert
werden (Wort für Wort).
Die kleinsten ansprechbare Einheit ist ein Dokument! Innerhalb eines Dokumentes kann man
sequentiell nach Zeichenfolgen suchen.
Beispiel:
Internet Suchmaschinen, Juridische Datenbank, Krankengeschichten.
Dabei treten verschiedenste Probleme (außer der Laufzeit auf):
•
•
•
•
•
man sucht nach "ien" und bekommt Treffer mit "Wien" und "Yugoslavien"
Thesaurus:
Schlüsselworte werden aus dem Text herausgehoben und getrennt gespeichert. Typische
Anwendung ist die Verschlagwortung - händischer Vorgang!
Homonyme (ein Wort mehrere Bedeutungen):
Leiter: Steighilfe, Vorgesetzter, ...
Synonyme (mehrere Worte für ein Ding):
Rechner, Computer, ...
Vermeiden von Mehrzahlen, Fällen, usw.
Beschlagwortung:
KWIC (Keyword in Context)
Beschlagwortung von Wörtern (manuell gekennzeichnete Wörter in einem Dokument)
KWOC (Keyword out of Context)
fertige Liste von Schlüsselwörtern wird dem Textteil zugeordnet
Vertreter:
Golem, Stairs, F&A, Lotus Notes
3.2.f. XML / XSLT
Wir werden uns später mit XML und XSLT beschäftigen. Eine XML Datei ist eigentlich eine Textdatei,
nur enthält diese Datei Informationen, welche Daten in der Datei zu finden sind.
- 12 -
Datenmodellierung
Haas, Resch
4. Einführung in die Datenmodellierung
Bis jetzt haben wir und auf einer sehr informellen, nicht exakten Ebene bei der Beschreibung eines
Systems bewegt.
Jetzt ist es Zeit uns mit einer formalen Methode zur Beschreibung unserer Sachverhalte zu
beschäftigen: mit dem Entity - Relationship Modell. Eigentlich müssten wir vom EER - dem
"Erweiterten ER" Modell sprechen, da wir uns auch das Konzept der Generalisierung ansehen
werden.
4.1. Grundlegende Begriffe
Folie: (Datenmodellierung) Begriffe zur Datenmodellierung
Die Datenmodellierung beschäftigt sich mit "Entitäten".
Eine Entität ist ein individuelles, wohl unterscheidbares "Irgendwas" (Objekte, Individuen, Sachen,
Begriffe, Ereignisse, ...) aus der realen Welt, das für eine konkrete Problemstellung relevant ist.
Entitäten werden durch Attribute (Eigenschaften) beschrieben und in Tabellenform notiert. Jede
solche Tabelle hat einen Namen, der links oben bei der Tabelle steht.
Eine der möglichen Notation (Schreibweisen) ist das Relationenmodell:
Beispiel:
Personen
SozVersNr
L01
L02
L03
…
•
•
•
•
•
•
Name
Eva
Peter
Susan
GebDat
1.1.82
13.5.85
8.9.91
Geschlecht
f
m
f
In den Zeilen stehen die einzelnen, genau unterscheidbaren Entitäten
Die Spalten führen die Eigenschaften (Attribute) auf
Die konkreten Werte eines Attributes zu einer Entität werden Attributswert genannt
Faktum: Zuordnung eines Attributswertes zu einem Attribut einer ganz bestimmten Entität
Die Menge aller Spalten (Attribute) einer Entität wird Relationenschema genannt und mit
einem Namen versehen
Die Tabelle mit allen Zeilen (und Spalten) wird Entitätsmenge genannt.
- 13 -
Datenmodellierung
Haas, Resch
Achtung:
Das Relationenmodell ist ein mengentheoretisches Konstrukt - die Reihenfolge der Attribute ist
irrelevant. Es ist natürlich übersichtlicher, wenn die Schlüsselfelder zu Beginn aufgeführt werden.
Typische Operationen (Damit werden wir uns bei SQL beschäftigen!)
Selektion:
Aus einer beliebigen Anzahl von Tupeln (Entitäten, Zeilen) werden ganz bestimmte Tupel selektiert.
Die Anzahl der Treffer ist nicht vorhersehbar - die Anzahl ändert sich durch neue Daten auch dauernd.
Projektion:
Auswahl der Attribute (nicht alle Attribute als Ergebnis ausgeben!)
Bemerkung:
Modellieren ist wie Aufsatzschreiben, es gibt unterschiedlichste Ansätze keiner ist ganz richtig oder
falsch - alles hängt vom persönlichen Blickwinkel, was einem wichtig ist, ab.
4.2. Beziehungen (Relationen)
Mit einer Entitätsmenge kann man sicherlich keinen brauchbaren Ausschnitt aus dem Realen Leben
beschreiben. Im wirklichen Leben gibt es immer Abhängigkeiten und Zusammenhänge.
Eine Entitätsmengen kann einen Zusammenhang zu einer oder mehreren Entitätsmengen haben. Wir
sprechen von einer Beziehung oder Relation.
Sehen wir uns ein Beispiel an:
•
•
Ein Arzt behandelt einen Patienten.
Ein Gärtner besitzt mehrere Gewächshäuser. In jedem Gewächshaus werden
unterschiedliche Pflanzen kultiviert.
4.3. Primary Key (Primärschlüssel)
Folie: (Datenmodellierung) Begriffe zur Datenmodellierung 2
Die Entitäten einer Entitätsmenge müssen eindeutig unterscheidbar sein.
Zu diesem Zweck ist in jedem Relationenschema ein eindeutiger Schlüssel (Primary Key) zu
definieren. Dieser Schlüssel wird in der Tabelle unterstrichen dargestellt.
Ein Schlüssel kann auch aus mehreren Attributen bestehen.
Eigenschaften eines Schlüssels:
- 14 -
Datenmodellierung
•
•
•
•
•
•
Haas, Resch
obligatorisch (muß immer einen Wert haben - nicht NULL)
prägnant (so kurz wie möglich um dennoch aussagekräftig zu sein)
unveränderbar
umkehrbar eineindeutig
In einer Entitätsmenge sind genau solche Entitäten enthalten, die von ihrem Schlüssel
funktional abhängig sind (dazu noch mehr bei den Normalformen)
ein Schlüssel sollte sprechend sein (vorhanden Attribute verwenden, wenn möglich ->
"natürlicher Schlüssel") - bei laufenden Nummern besteht Gefahr ein und die selbe Entität
mehrfach zu speichern!
Überlegungen zu Primärschlüsseln:
A. Ein Buch wird genau ein einziges mal ausgeborgt.
Bibliothek
ISBN
3-783499-600630
3-783499-212212
Leser#
220
341
Es ist also nicht möglich, dass das gleiche Buch von einem andern Leser entlehnt wird. Wenn das
dennoch gehen soll, dann muß die Leser# geändert werden - die vorherige Entlehnung ist dann aber
verschwunden!
Bibliothek
ISBN
3-783499-600630
3-783499-212212
Leser#
43
341
B. Ein Buch kann an unterschiedliche Leser verborgt werden
Bibliothek
ISBN
3-783499-600630
3-783499-212212
3-783499-600630
Leser#
220
341
341
Jetzt haben wir aber das Problem, das eine Person ein Buch nur genau einmal entlehnen kann!
C. Ein Bucht an unterschiedliche Leser, mehrmals
Bibliothek
ISBN
3-783499-600630
3-783499-212212
3-783499-600630
3-783499-600630
Leser#
220
341
341
220
Entlehndatum
1.1.2001
3.1.2001
3.1.2001
2.6.2002
4.4. Secondary Key (Fremdschlüssel)
Ein Secondary Key (Fremdschlüssel) ist eine Beziehung von einem Attribut zu einem Primary Key
einer anderen Entitätsmenge. Alle Beziehungen in einer relationalen Datenbank werden über solche
Fremdschlüssel realisiert. Es handelt sich also nicht um Pointer, denen gefolgt wird, sondern
Beziehungen werden immer über Suchprozesse realisiert.
Achtung:
- 15 -
Datenmodellierung
Haas, Resch
Es darf keinen Fremdschlüssel geben, der nicht als Primary Key vorkommt (Referentielle Integrität).
Nun wissen wir bereits genug, um zu verstehen was Anomalien beim Löschen, Eintragen oder Ändern
sind und warum wir Fremdschlüssel verwenden werden:
Abteilungsnamen mit Redundanz: Datenredundanz ist das mehrfache Speichern eines Faktums - das
ist zu vermeiden, da dadurch Anomalien auftreten können!
Mitarbeiter
SozVersNr
L01
L02
L03
L04
Name
Eva
Peter
Susanne
Klaus
AbtNr
A1
A2
A2
A3
AbtName
EDV
Einkauf
Einkauf
Verkauf
(Änderungs-) Anomalie: Das Änderungsprogramm hat nicht alle Vorkommnisse der Abteilung
gefunden und geändert.
Mitarbeiter
SozVersNr
L01
L02
L03
L04
Name
Eva
Peter
Susanne
Klaus
AbtNr
A1
A2
A2
A3
AbtName
EDV
Einkauf
Buchhaltung
Verkauf
(Lösch-) Anomalie: mit dem Löschen der Mitarbeiter L02 und L03 ist auch die Abteilung A2
verschwunden. Es kann ja durchaus sein, dass neue Mitarbeiter im Anschluss zugeordnet werden
sollen!
Mitarbeiter
SozVersNr
L01
L04
Name
Eva
Klaus
AbtNr
A1
A3
AbtName
EDV
Verkauf
(Einfüge-) Anomalie: Es ist nicht möglich eine Abteilung A4 anzulegen, in der zur Zeit keine
Mitarbeiter vorhanden sind.
Mitarbeiter
SozVersNr
L01
L04
Name
Eva
Klaus
AbtNr
A1
A3
AbtName
EDV
Verkauf
?? A4
Ein Beispiel für die Verwendung eines Fremdschlüssels ist die Abbildung des Abteilungsnamens zu
einem Mitarbeiter ohne Redundanz:
- 16 -
Datenmodellierung
Mitarbeiter
SozVersNr
L01
L02
L03
L04
Haas, Resch
Name
Eva
Peter
Susanne
Klaus
AbtNr
A1
A2
A2
A3
Abteilungen
AbtNr
AbtName
A1
EDV
A2
Einkauf
A3
Verkauf
Den Pfeil nennen wir Beziehung oder Relation. Den Beziehungen geben wir sprechende Namen.
Beispiel zu obiger Beziehung: "gehört zu"
4.5. Grad (Kardinalität) einer Beziehung
4.5.1. Kardinalität 1:1
Eine Entität der einen Seite wird genau einer Entität der anderen Seite zugeordnet und umgekehrt.
Beispiel: Standort eines Buchexemplares (In Regalen gibt es Fächer für genau ein Buch)
Ein Exemplar eines Buches (auf die Entiät Standort schauen) steht genau an einem
bestimmten Standort,
Standort ist "1" Seite
An einem bestimmten Standort (auf die Entität Bücher schauen) steht genau ein Exemplar
eines Buches
Bücher ist "1" Seite
Bücher
ISBN
3-783499-600630
3-783499-600630
Exemplar
1
2
Standorte
Zimmer
B404
B405
Regal
1
4
Fach
B
12
Platz
21
5
4.5.2. Kardinalität 1:N
Einer Entität der einen Seite können mehrere Entitäten der anderen Seite zugeordnet werden,
umgekehrt aber höchstens eine Entität.
Beispiel: Mitarbeiter einer Abteilung
Ein Mitarbeiter (auf die Entität Abteilung schauen) gehört zu genau einer Abteilung,
Abteilung ist"1" Seite
In einer Abteilung (auf die Entität Mitarbeiter schauen) sind mehrere Mitarbeiter
"
Mitarbeiter ist N" Seite
Abteilung
Abteilungs# AbtName
EINK
Einkauf
BUCHH
Buchhaltung
Mitarbeiter
SozVers#
2111230765
1231010182
4321230376
MitName
Resch
Meier
Müller
Abteilungs#
EINK
EINK
BUCHH
- 17 -
Datenmodellierung
Haas, Resch
4.5.3. Kardinalität M:N
Einer Entität der einen Seite können mehrere Entitäten der anderen Seite zugeordnet werden und
umgekehrt.
Wenn M:N Beziehungen auftreten, dann müssen im Datenmodell in eine 1:N und eine 1:M Beziehung
aufgelöst werden. Aber dazu noch später - Stichwort "Assoziationstabelle".
Ein Buch (auf die Entität Autor schauen) kann mehrere Autoren haben,
Autor ist "M" Seite
Ein Autor (auf die Entität Bücher schauen) kann mehrere Bücher schreiben
Buch ist "N" Seite
Bücher
ISBN
3-783499-600630
3-783499-600630
3-783499-212121
Author
4
5
4
Authoren
Author
4
5
Name
Resch
Müller
Die Modellierung der Bücher wird in Wirklichkeit NICHT so vorgenommen - wir werden diesen
Sachverhalt mit einer zusätzlichen Tabelle abbilden! (Assoziationstabelle)
Wir sehen, dass wir im Relationenmodell KEINE Kardinalitäten hinterlegen können. Wir benötigen
daher eine bessere Notationsform!
5. Notationsformen eines Datenmodells
Die Datenmodellierung liefert als Ergebnis folgendes:
•
•
•
Welche Entitäten sind relevant?
Welche Attribute beschreiben die Entitäten?
Welche Beziehungen herrschen unter den Entitäten?
Diese Informationen müssen nicht nur aus der Wirklichkeit abgeleitet werden, sondern zur
Dokumentation und Transport an andere niedergeschrieben werden. Zu diesem Zweck gibt es
unterschiedliche Methoden und Werkzeuge:
•
•
•
•
•
•
Relationenmodell (schon behandelt)
Chen Diagramme
Entity - Relation Diagramme (Werkzeug: ERWIN - Entity Relation Diagrams for Windows)
XML
UML
...
Die Modellierungswerkzeuge sind in der Regel auch fähig die Tabellen in einem Datenbanksystem,
laut Datenmodellierung, anzulegen.
5.1. Chen Diagramme
Entitätsmenge:
Bücher
- 18 -
Datenmodellierung
Haas, Resch
Attribute:
p_name
an eine Entität oder Beziehung gebunden
- 19 -
Datenmodellierung
Haas, Resch
6. Vorgehensweisen bei der Datenmodellierung
6.1. diszipliniertes Top / Down
a. alle Entitäten
b. alle Attribute zu den Entitäten
c. alle Beziehungen
Dieses Vorgehen ist in der Praxis schwer einzuhalten, obwohl es sicherlich sehr gut wäre. Wir werden
diesen Ansatz bei der Textanalyse verwenden.
6.2. "Jojo Technik"
Je nach Bedarf werden die hierarchischen Ebenen gewechselt. Das Vorgehen ist situationsabhängig.
- 20 -
Datenmodellierung
Haas, Resch
7. Normalformen
Folie: (Datenmodellierung) Kriterien eines optimalen Datenmodells
Ziel der Anwendung der Normalformen:
Datenmodell ist kompakt, integer und redundanzfrei.
Kompakt
integer
Redundanzfrei
Nicht mehr Speicherplatz / Tabellen / Felder als unbedingt nötig
(Name1, Name2, Name3, usw.)
einhalten der Integritätsbedingungen
Ein und dasselbe Faktum darf nur einmal gespeichert werden
Um dieses Ziel zu erreichen gibt es ein Verfahren, das von Codd erfunden wurde: die Normalisierung
bzw. die Normalformen.
Diese hat die Zerlegung von Datenstrukturen ohne Informationsverluste in mehrere einfachere und
redundanzärmere Strukturen zum Inhalt. Durch den Prozess der Normalisierung können
Datenredundanzen vermieden und die daraus resultierenden Speicheranomalien verhindert werden.
Folgende Arten von Speicheranomalien lassen sich unterscheiden, wie wir ja schon gesehen haben.
•
•
•
Einfügeanomalien
Löschanomalien
Änderungsanomalien
7.1. Integritätsbedingungen
Folie: (Datenmodellierung) Kriterien eines optimalen Datenmodells
- 21 -
Datenmodellierung
Haas, Resch
7.1.1. Semantische Integrität
Die semantische Integrität steht für die Korrektheit der Datenbankinhalte. Dabei gilt es falsche
Eingaben oder unzulässige Änderungen abzufangen.
Zum Zeitpunkt der Datendefinition müssen dem Datenbanksystem die Integritätsregeln mitgeteilt
werden. Daneben besteht aber auch noch die Möglichkeit im Anwendungsprogramm bestimmte
Kontrollen einzubauen. So können für einzelne Attribute ein bestimmter Wertebereich angegeben
werden.
In MS ACCESS haben Sie im Tabellenentwurf durch die Wahl eines passenden Felddatentyps, durch
die Festlegung von Gültigkeitsregeln sowie die Verwendung von Nachschlageassistenten die
Möglichkeit anzugeben, welche Anforderungen die Eingabedaten erfüllen müssen.
Folie: (Datenmodellierung) semantische Integrität
Für die Erhaltung der Korrektheit der Beziehungen zwischen Attributen einer Relation ist es wichtig,
dass der Schlüssel eindeutig ist (Verwendung eines Primärschlüssels). Nur so ist es möglich, einen
Datensatz eindeutig zu identifizieren.
7.1.2. referentielle Integrität
Die referentielle Integrität befasst sich mit der Korrektheit von Beziehungen und stellt sicher, dass
Änderungen in der Datenbank nicht dazu führen, dass Fremdschlüssel auf nicht mehr vorhandene
Datensätze verweisen.
Folie: (Datenmodellierung) referentielle Integrität
- 22 -
Datenmodellierung
Haas, Resch
7.1.3. operationale Integrität
Folie: (Datenmodellierung) operationale Integrität
Die operationale Integrität bezieht sich auf das korrekte Verhalten der Anwendung. Um zu
verhindern, dass Datenbankinhalte durch systembedingte Fehler verfälscht werden, wurden
sogenannte Transaktionen eingeführt.
Benutzerzugriffe auf die Datenbank erfolgen über Transaktionen, die einerseits nur Daten abfragen,
andererseits aber auch Daten ändern beziehungsweise löschen können. Transaktionen sind eine
logische Folge von Datenbankoperationen, die in Gesamtheit die gültigen Konsistenzbedingungen
erfüllen.
Transaktionen, die Änderungen in der Datenbank bewirken dürfen nur in Gesamtheit durchgeführt
werden oder gar nicht. Daher werden diese auch als atomar bezeichnet. Kommt es während der
Durchführung einer Transaktion zu einem Systemfehler, muss der Zustand der Transaktion auf den
Beginn zurückgesetzt werden. Die Transaktionsverarbeitung ist heute bereits fester Bestandteil von
Datenbanksystemen. Greifen mehrere Benutzer zugleich auf eine Datenbank zu ist die
Konsistenzsicherung jedoch wesentlich komplexer als oben beschrieben. Sperrmechanismen sind
eine Möglichkeit Zugriffskonflikte zu vermeiden.
Beispiel:
Überweisung auf ein Konto.
7.2. Unnormalisiert (Nullte Normalform)
Die Abbildung zeigt ein Formular, welches Daten zur Projektabrechnung enthält. Aus dem Formular
geht hervor, welcher Mitarbeiter an einem bestimmten Projekt mitgewirkt hat.
- 23 -
Datenmodellierung
Haas, Resch
Folie: (Datenmodellierung) Projektabrechnung
Die Informationen aus dem Formular können in Form einer unnormalisierten Relationmodell
dargestellt werden (Wir haben diese bis jetzt Realitätsbeobachtungen genannt).
Personal# Name
1
2
Vorname Abteilungs# Abteilung
Winkler Ursula
Maier
Peter
1
1
Marketing
Marketing
Projekt#
Projektname
Stunden
A
A, B
E-Commerce
E-Commerce,
Internet
60
100, 75
Eine unnormalisierte Relation ist dadurch gekennzeichnet, dass sie Attribute mit Attributwerten
aufweist, welche sich aus mehreren Elementen (einer Liste - nicht ein einzelner Wert!)
zusammensetzen.
Beispielsweise sind in der Tabelle zu Mitarbeiter 2 (Herr Maier) zwei Projekte gespeichert. Aufgrund
der redundanten Datenhaltung können mehrere Speicheranomalien beobachtet werden:
•
•
•
Beispielsweise kann eine neue Abteilung nur dann hinzugefügt werden, wenn diese einem
Mitarbeiter zugeordnet wird (Einfügeanomalie).
Werden alle Mitarbeiterinformationen gelöscht, gehen auch die Informationen über die
Projekte und über die Abteilungen verloren (Löschanomalie).
Wird beispielsweise bei Mitarbeiter 1 der Name der Abteilung von Marketing in Finanzierung
umgeändert, dann muss diese Änderung bei allen Mitarbeitern, die ebenfalls in dieser
Abteilung arbeiten, gemacht werden. Ansonsten führt dies zu inkonsistenten Daten
(Änderungsanomalie).
7.3. Die 1. Normalform
Durch den Normalisierungsprozess kann eine unnormalisierte Relation in die erste Normalform
überführt werden.
Eine Relation befindet sich in der ersten Normalform, wenn sie nur einfache Attribute enthält .
Man sagt auch, dass die Attribute nur atomare Werte (Keine Listen) annehmen dürfen.
Unser Beispieldatenmodell hat aber genau so ein Attribut, das nicht atomar ist:
Der Mitarbeiter 2 (Herr Maier) hat eine Liste von Projekten im Attribut Projekt# und Projekt
eingetragen.
Wir müssen unser Datenmodell daher ändern, um die erste Normalform nicht zu verletzten! Die
einfachste Methode ist einen zusätzliches Attribut (Projekt#) in den Primärschlüssel aufzunehmen. Wir
- 24 -
Datenmodellierung
Haas, Resch
können dann die beiden Projekte von Herrn Maier (Mitarbeiter 2) in zwei Entitäten (Datensätzen)
abspeichern.
Folie: (Datenmodellierung) 1. Normalform
Personal#
1
2
2
Name
Winkler
Maier
Maier
Vorname
Ursula
Peter
Peter
Abteilungs#
1
1
1
Abteilung
Marketing
Marketing
Marketing
Projekt#
A
A
B
Projektname
E-Commerce
E-Commerce
Internet
Stunden
60
100
75
Weil wir sofort sehen, dass das Datenmodell noch nicht ideal ist (Redundanz, ...) gibt es natürlich
noch weitere Normalformen:
7.4. Die 2. Normalform
Eine Relation ist in der 2. Normalform, wenn sie
•
•
in der 1. Normalform ist und
wenn jedes Attribut, das zu keiner Schlüsselkombination gehört, nur von der gesamten
Schlüsselkombination, nicht aber von einem Teil, funktional abhängig ist.
Die 2. Normalform richtet sich an zusammengesetzte Schlüssel:
•
•
Wenn also nur ein Attribut zum Primärschlüssel gehört, dann ist die 2. Normalform erfüllt
Wenn es zusammengesetzte Schlüssel gibt, dann dürfen alle Attribute nur vom gesamten
Schlüssel funktional abhängig sein - nicht nur von einem Teil des Schlüssels
7.4.1. Funktionale Abhängigkeit (ein Attribut)
Um diese Definition etwas genauer analysieren zu können, müssen wir uns mit dem Begriff der
funktionalen Abhängigkeit beschäftigen!
Beispiel:
r3
Entität
r
s
R
a1
a2
a3
...
amax
s2
Ein Attribut ai eines Relationenschemas R heißt funktional abhängig von einem Attribut ak , falls für
alle Entitäten r,s aus der Entitätsmenge R (Entitätsmenge und Relationenschema mit dem gleichen
Namen bezeichnet) und 0 <= i,k <= maximale Anzahl der Entitäten in R, gilt:
rk = sk => ri = s i
Wir schreiben kurz: ak -> ai
Anders formuliert:
• Jedes Auftreten eines Attributwertes im Attribut ak zeigt an, dass es sich um eine
unterscheidbare Entität handelt.
• Alle anderen Attributwerte können nur dann andere Werte annehmen, wenn sich auch das
Attribut ak ändert.
- 25 -
Datenmodellierung
Haas, Resch
Beispiel:
Personal#
1
2
Name
Resch
Meier
Also:
Personalnummer 1 bedeutet immer Resch, 2 immer Meier!
Hinweis:
Das kennen wir doch schon, das war die Geschichte mit dem Primärschlüssel!
7.4.2. Funktionale Abhängigkeit (mehrere Attribute)
Der Primärschlüssel ist aber schon längst für uns erledigt, die Definition der 2. Normalform bezieht
sicht auf zusammengesetzte Primärschlüssel!
Das Attribut ai heißt funktional abhängig von ak und am (ak am -> ai), wenn gilt:
rk = sk und rm = sm => ri = s i
Wieder in anderen Worten:
Das Attribut ai darf sich also nur dann ändern, wenn sich auch die Attribute ak und/oder am ändern!
7.4.3. Vorgehensweise:
Alle Attribute, die zum Schlüssel gehören werden - einzeln - untersucht, ob es funktionale
Abhängigkeiten gibt!
Genau das ist aber unser Problem:
Personal#
1
2
2
Name
Winkler
Maier
Maier
Vorname
Ursula
Peter
Peter
Abteilungs#
1
1
1
Abteilung
Marketing
Marketing
Marketing
Projekt#
A
A
B
Projektname
E-Commerce
E-Commerce
Internet
Stunden
60
100
75
Die Schlüsselattribute sind Personal# und Projekt#.
Folgende Verletzungen der 2. Normalform sind festzustellen:
•
•
Personal#
Name, Vorname, Abteilungsnummer und Abteilung sind vom Schlüsselteil Personal#
funktional abhängig
Projekt#
Das Attribut Projektname ist vom Schlüsselteil Projekt# funktional abhängig
Hinweis:
Wir sehen, dass es noch weitere funktionale Abhängigkeiten gibt (Abteilungs# -> Abteilung). Das ist
aber jetzt noch nicht interessant, wir sehen uns nur die Attribute im Schlüssel, mit deren
Abhängigkeiten an!
Wie gehen wir nun vor, um das Datenmodell in 2. Normalform zu erreichen? Wir müssen das
bestehende Relationsschema aufspalten. Die Attribute mit den kritischen Abhängigkeiten werden
dabei als neuer Schlüssel verwendet.
- 26 -
Datenmodellierung
Haas, Resch
Folie: (Datenmodellierung) 2. Normalform
7.5. Die 3. Normalform
Das sieht schon sehr gut, aus. Es gibt aber noch einen Schönheitsfehler:
Eine Relation ist in der 3. Normalform, wenn die zweite Normalform erfüllt ist und kein Attribut, das
nicht zum Identifikationsschlüssel gehört, transitiv von diesem abhängig ist.
7.5.1. transitive Abhängigkeit
Das Attribut "Abteilung" wird vom Nicht-Schlüsselattribut "Abteilungs#" identifiziert. Andererseits aber
auch vom Attribut "Mitarbeiter#".
Aus der Sicht der funktionalen Abhängigkeit gilt hier also:
Mitarbeiter# -> Abteilungs# -> Abteilung
Die Eigenschaft der Transitivität bedeutet dann:
Mitarbeiter# -> Abteilungs# -> Abteilung => Mitarbeiter# -> Abteilung
Also:
•
•
Abteilungs# -> Abteilung und
Mitarbeiter# -> Abteilung
Diese mehrfachen Abhängigkeiten, die einen Verstoß gegen die 3. Normalform darstellen, müssen
durch das Aufsplitten der Relation beseitigt werden. Die neu entstandenen Relationen werden durch
einen Fremdschlüssel in Beziehung gebracht.
- 27 -
Datenmodellierung
Haas, Resch
Folie: (Datenmodellierung) 3. Normalform
Das ist für uns ausreichend perfekt!
- 28 -
Datenmodellierung
Haas, Resch
8. Umsetzung von ER Modellen in relationale Modelle (nach der
Kardinalität)
Zusammenfassung Vorgehensweise:
1:1
1:N
N:M
gleiche Tabelle
Fremdschlüssel mitnehmen
Assoziationstabelle (Primärschlüssel der beteiligten Entitäten sind Fremdschlüssel)
Folie: (Datenmodellierung) ER - Diagramm nach relationales Modell
8.1. 1:N Beziehung
Der Primärschlüssel der Prüftabelle (Fremdschlüsselbeziehung) wird als Attribut in die Tabelle
aufgenommen:
Tabelle Mitarbeiter
Personal#
...
Raum#
...
Tabelle Räume
Raum#
Standort#
...
8.2. 1:1 Beziehung
1:1 Bezieungen sind nur Sonderfälle der 1:N Beziehung. Diese sind auch in einer Tabelle abbildbar:
Wir erinnern uns an das Beispiel mit der Firma eConsult - In einem Raum sitzt genau ein Mitarbeiter.
Ein Mitarbeiter sitzt in genau einem Raum.
Tabelle Mitarbeiter
Personal# ...
Raum#
Standort#
Wir werden also nur dann auf die Methode der Attribute zurückgreifen, wenn wir ganz sicher sind,
dass wir niemals eine 1:N Beziehung abbilden werden müssen. Wenn diese Annahme nicht hält
werden wir unsere Datenmodell, unsere Datenbank und die Daten in der Datenbank ändern müssen!
- 29 -
Datenmodellierung
Haas, Resch
Ein anderes Beispiel - Prüfungsgeschehen:
Zwischen Fach und Prüfer herrscht eine 1:1 Beziehung, diese sind mit Vorsicht als Attribut (in einer
Tabelle) auffassbar!
Pr#
BF
RI
MU
GR
Pr Name
Berger
Riese
Muth
Groß
F#
GEDV
PR
MAM
LÜK
F_Bez
Grundlagen
Programmieren
Mathematik
Leibesübungen
Wir sprechen in diesem Fall von einer 1:1 Beziehung mit obligatorischer Teilnahme beider
Entitäten: Es gibt keine Entität, die nicht an der Relation teilnimmt.
•
•
jedes Fach wird geprüft
jeder Prüfer hat ein Fach
=> Dann können die Attribute der einen Entität als Attribute der anderen Eintität angesehen werden
(Schlüssel oder Attribute gehen mit, sonst NF verletzt!)
In unserm Beispiel wird das Fachkürzel mitgenommen
8.3. M:N Beziehung
Eine M:N Beziehungen ist nicht direkt darstellbar - diese wird in zwei 1:N Beziehungen aufgelöst! Die
Methode hierzu heißt "Assoziationstabelle". Dieses kann auch nur aus Schlüsseln (ohne Attribute)
bestehen (All Key Table)!
Beispiel der Bibliothek:
Notation im Relationenmodell:
Entlehner(Leser#, Adresse, ...)
Buch(ISBN, Titel, ...)
entleiht(Leser#, ISBN, Datum) <= Assoziationstabelle
- 30 -
Datenmodellierung
Haas, Resch
9. NULL / Faktum "Leer"
In einer Tabelle muß man unterscheiden zwischen:
•
NULL
es ist kein Datum als Attributwert vorhanden (Wert ist derzeit noch nicht bekannt)
Ein Beispiel ist das Rückgabedatum bei unserer Bibliothek. Zu dem Zeitpunkt, wo ein Buch
entlehnt wird, ist auch das Attribut "Rückgabedatum" vorhanden. Dieses Attribut ist aber so
lange nicht gefüllt, bis das Buch zurückgebracht wird.
ACHTUNG:
Die Attribute, die zum Primärschlüssel gehören DÜRFEN KEINE NULL Werte enthalten!
•
Leer oder Wert 0
Der Wert eines Attributes ist mit Absicht auf "Leer" oder 0 gesetzt.
Ein Beispiel ist unsere Stadtbibliothek: Dort kann man auch Getränke zu sich nehmen. Die
muß man natürlich auch bezahlen. Wenn man will kann man diese Beträge gemeinsam mit
den Bibliotheksbeiträgen verrechnen lassen. Wenn ich aber keine Getränke konsumiert habe,
dann ist der Wert - im zugehörigen Attribut - 0.
Ein Datenbanksystem geht bei dem Auftreten von NULL Werten wie folgt vor:
•
•
Wahr und NULL => NULL
Wahr oder NULL => Wahr
Hinweis:
Wenn es Attribute gibt, die fast nur NULL-Werte enthalten - dann ist das Datenmodell nicht
ausreichend geplant.
Hinweis:
Ein Datenbanksystem unterscheidet auf Grund des Wertes zwischen NULL und Leer: Ein NULL Wert
wird anders dargestellt, zum Beispiel durch einen Wert, den ein normales Datum nicht annehmen darf
(-32767, ...)
Hinweis:
Im SQL werden wir auch nach diesen NULL Werten abfragen können!
- 31 -
Datenmodellierung
Haas, Resch
10. Generalisierung (Super / Subtyp)
Supertyp:
Subtyp:
alle gemeinsamen Attribute
spezielle Attribute
Diese Idee kennen wir auch aus der objektorientierten Programmierung: Hier sprechen wir von einer
Basisklasse (=Supertyp) und der abgeleiteten Klasse (=Subtyp).
Beispiel:
"Ein Arzt ist eine Person"
"Ein Patient ist eine Person"
Folie: (Datenmodellierung) Generalisierung
- 32 -
Datenmodellierung
Haas, Resch
11. Textanalyse
Die Zerlegung des Datenmodells über die Normalformen (Normalisierung) ist nur bei sehr einfachen
Modellen möglich, wegen:
- der Komplexität von großen Datenmodellen
- es keine Algorithmus zur Normalisierung gibt (wir kennen zwar die Kriterien, haben aber keinen
allgemeingültigen Weg zur Erreichung der Normalformen)
Zum Einsatz in der Praxis kann man daher Regelwerke zur Optimierung des Datenmodells einsetzten.
Ein Beispiel für ein solches Regelwerk ist die Textanalyse:
•
•
•
•
•
•
Entitäten und die Beziehungen werden zunächst im Text der Aufgabenstellung mit
unterschiedlichen Farben zu markieren
Anschließend notiert man die Beziehungen zwischen den Entitätsmengen und deren Grade
dann ergänzt man die Attribute zu den Entitätsmengen.
mit den acht Regeln zur Textanalyse wird das Datenmodell optimiert
prüfen, ob der Primärschlüssel aus der minimalen Attributskombination besteht (unter
Einhaltung der Eindeutigkeit!). Es kann also passieren, dass Schlüsselattribute zu Attributen
werden oder umgekehrt
Zuletzt wird geprüft, ob die Tabellen der 3. Normalform genügen
11.1. Das Regelwerk der Textanalyse
Das Regelwerk verwendet oft den Begriff "obligatorisch". Damit ist gemeint:
•
•
dass der Wert eines Attributes immer gefüllt sein muß - also nicht NULL sein darf.
Im Sinne einer Beziehung muß eine Entität vorhanden sein
Regel 1) Grad 1 : 1 - Generalisierung
1: 1 Beziehungen treten meist nur in Generalisierungen auf, wobei der Supertyp mit dem Subtyp in
dieser Beziehung steht; der Primärschlüssel des Supertypen wird als Primärschlüssel des Subtypen
mitgenommen.
Beispiel:
"Ein Arzt ist eine Person"
"Ein Patient ist eine Person"
Notation im Relationenmodell:
Ausgangsbasis:
Person
Pers#
P1
P2
P3
(Supertyp ...allgemeinerer Begriff)
Name
Meier
Müller
Bürger
Name ist ein gemeinsames Attribut!
- 33 -
Datenmodellierung
Haas, Resch
Arzt (Subtyp ... speziellerer Begriff)
Arzt#
Fachgebiet
A
B
Chirurgie
Unfall
Patient (Subtyp ... speziellerer Begriff)
Pat#
Zimmer
0001
B404
Also, der Primärschlüssel des Supertypen (Pers#) wird als Primärschlüssel des Subtypen
mitgenommen:
Person
Pers#
P1
P2
P3
(Supertyp ...allgemeinerer Begriff)
Name
Meier
Müller
Bürger
Arzt (Subtyp ... speziellerer Begriff)
Arzt#
Pers#
Fachgebiet
A
P2
Chirurgie
B
P1
Unfall
Patient (Subtyp ... speziellerer Begriff)
Pat#
Pers#
Zimmer
00001
P3
B404
Regel 2) 1 : 1 Beziehungen, obligatorische Teilnahme beider Entitätsmengen
Es wird nur eine Entitätsmenge benötigt, wobei die Attribute der einen Entitätsmenge als Attribute der
anderen Entitätsmenge (ev. ohne Primärschlüssel) aufscheinen.
Also aus beiden Relationenschematas (oder Entitätsmengen) muß genau ein Vertreter vorhanden
sein!
Beispiel:
"Jeder Mitarbeiter hat ein eigenes Zimmer"
"In jedem Zimmer sitzt nur ein Mitarbeiter"
Ausgangsbasis:
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
- 34 -
Datenmodellierung
Zimmer
Zi#
B403
B404
B405
Haas, Resch
Teppichfarbe
braun
braun
grau
Also, die beiden Relationenschematas werden zu Einem zusammengezogen:
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
Zi#
B404
B403
B405
Teppichfarbe
grau
braun
grau
Regel 3) 1 : 1 Beziehung, eine Entitätsmenge obligatorisch, die andere nicht obligatorisch
Es werden 2 Entitätsmengen benötigt. Der Entitätsschlüssel der nichtobligatorischen Seite ist Attribut
der obligatorischen.
Beispiel:
"Ein Mitarbeiter kann einen fix zugeordneten PC haben"
"Ein PC muß genau einem Mitarbeiter fix zugeordnet werden"
Mitarbeiter:
PC:
obligatorisch (immer vorhanden)
nicht obligatorische (Es kann ja auch Mitarbeiter ohne PCs geben)
Ausgangsbasis:
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
PC
PC#
565
677
CPU
Pentium1G7
Duron1G7
Also, der Entitätsschlüssel der nichtobligatorischen Seite (PC#) ist Attribut der obligatorischen.
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
PC
PC#
565
677
PC#
677
NULL
565
CPU
Pentium1G7
Duron1G7
- 35 -
Datenmodellierung
Haas, Resch
Regel 4) 1 : 1 Beziehung, beide Entität nichtobligatorisch
Es werden 3 Entitätsmengen benötigt: Die beiden ursächlichen Entität und eine Entitätsmenge für die
Beziehung, die die Entitätsschlüssel beider Entitätsmengen enthält.
Beispiel:
"Ein Mitarbeiter kann einen fix zugeordneten PC haben"
"Ein PC kann einem Mitarbeiter fix zugeordnet werden"
Ausgangsbasis:
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
PC
PC#
412
542
565
677
CPU
I386
Celeron766
Pentium1G7
Duron1G7
Also, eine Entitätsmenge für die Beziehung, die die Entitätsschlüssel beider Entitätsmengen enthält,
zusätzlich zu den beiden bestehenden Entitätsmengen.
Mitarbeiter
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
PC
PC#
412
542
565
677
CPU
I386
Celeron766
Pentium1G7
Duron1G7
Zugeordneter PC
Pers# PC
P1
677
P2
542
P3
565
Den PC mit der Inventarnummer 412 will (aus verständlichen Gründen) niemand haben!
Hinweis:
Wir können uns in diesem Fall aussuchen, welches Attribut wir in der Entitätsmenge "Zugeordneter
PC als Schlüsselattribut verwenden wollen!
- 36 -
Datenmodellierung
Haas, Resch
Regel 5) 1 : n Beziehung, n- Seite obligatorisch (Fremdschlüssel)
Es werden zwei Entitätsmengen benötigt. Der Entitätsschlüssel der 1 -Seite ist Attribut der
Entitätsmenge der n -Seite.
Beispiel:
"Eine Person kann mehrer Bücher entlehnen"
"Ein Buch kann nur von einer Personen entlehnt werden (es gibt also immer nur ein Exemplar)"
Ausgangsbasis:
Person ist die 1-Seite
Buch ist die N-Seite (obligatorisch)
Personen
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
Bücher
ISBN#
1212
1213
1214
1215
Titel
SQL
ACCESS
ORACLE
Datenmodellierung
Hinweis:
Was muß mit jedem Buch sein (Es muß an eine Person verliehen sein!)
Also, der Entitätsschlüssel der 1 -Seite wird Attribut der Entitätsmenge der n -Seite.
Personen
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
Bücher
ISBN#
1212
1213
1214
1215
Titel
SQL
ACCESS
ORACLE
Datenmodellierung
Pers#
P1
P3
P2
P1
Regel 6) 1 : n Beziehung, beide Seite nichtobligatorisch
Es werden drei Entitätsmengen benötigt - eine zusätzliche für die Entitätsmenge, die die
Entitätsschlüssel beider Entitätsmengen enthält.
- 37 -
Datenmodellierung
Haas, Resch
Beispiel:
"Eine Person kann beliebig viele Bücher entlehnen (also auch gar keine)"
"Ein Buch kann von höchstens einer Personen entlehnt werden"
Ausgangsbasis:
Person ist die 1-Seite
Buch ist die N-Seite
Personen
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
Bücher
ISBN#
1212
1213
1214
1215
Titel
SQL
ACCESS
ORACLE
Datenmodellierung
Also, eine zusätzliche für die Entitätsmenge, die die Entitätsschlüssel beider Entitätsmengen enthält.
Personen
Pers# Name
P1
Meier
P2
Müller
P3
Bürger
Bücher
ISBN#
1212
1213
1214
1215
Titel
SQL
ACCESS
ORACLE
Datenmodellierung
entlehnt
ISBN# Pers#
1212
P2
1215
P1
Es gibt also Bücher, die nicht entlehnt sind und Personen, die keine Bücher ausgeborgt haben.
- 38 -
Datenmodellierung
Haas, Resch
Hinweis:
Wozu gibt es diese beiden Unterscheidungen?
Bei der Regel 5) könnten dann Zeilen mit vielen NULL Werten entstehen:
ISBN#
1212
1213
1214
1215
Titel
SQL
ACCESS
ORACLE
Datenmodellierung
Pers#
P2
NULL
NULL
P1
Das ist ein Zeichen von schlechtem Datenbankdesign, da Speicherplatz verschwendet wird!
Regel 7) n : m Beziehung
Es werden drei Entitätsmengen benötigt - eine Zusätzliche für die Beziehung, die die Entitätsschlüssel
beider Entitätenmengen (meist als gemeinsamen Primärschlüssel- 'All Keyed' Relation -) enthält.
Beispiel:
Verkäufer (Verk#, Name)
Käufer (K #, Name)
Verkauf(Verk#, K#, Menge)
Regel 8) m: n : o Beziehung (tenäre oder mehrwertige Beziehung)
Es werden Anzahl der Entitätsmengen + eine zusätzliche Entitätsmenge benötigt, sonst wie Regel 7.
Beispiel:
Verkäufer (Verk#, Name)
Käufer (K #, Name)
Artikel (Art#, Name, Preis)
Verkauf(Verk#, K#, A#, Menge)
11.2. ein einfaches Beispiel
In einem Betrieb arbeiten Personen (Mitarbeiter) in Abteilungen an Produkten.
Folgende Feststellungen können getroffen werden:
§
§
§
§
§
§
ein Mitarbeiter hat einen Namen sowie einen Wohnort
Er ist in einer Abteilung tätig und arbeitet an mehreren Produkten jeweils eine vorbestimmte Zeit.
Jede Abteilung weist einen Namen auf.
Desgleichen ist jedem Produkt ein Name zugeordnet
In einer Abteilung sind mehrere Personen tätig
an einem Produkt arbeiten meist mehrere Personen
- 39 -
Datenmodellierung
Haas, Resch
Entitätsmengen
Beziehung
Grad
Personen
Name,
Wohnort
arbeitet_in
1:N
arbeitet_an
Zeit
N:M
Abteilungen
Name
Produkte
Name
Person arbeitet_in Abteilung
N
:
1
Regel 5)
N Seite obligatorisch (muß vorhanden sein!) - OK gilt, in einer Abteilung muß also immer
mindestens ein Mitarbeiter sein.
Also: Zwei Relationen (eine je Entität). Der Entitätsschlüssel der 1-Seite ist Attribut der Relation
der N Seite (Fremdschlüssel!)
Regel 6)
Beide Seiten sind Nicht - obligatorisch (beide Seiten brauchen nicht vorhanden zu sein!) - Gilt
NICHT, da eine Person zu einer Abteilung gehört und eine Abteilung mindestens einen
Mitarbeiter haben soll
Personen arbeiten_an Produkten
M
:
N
Regel 7)
N:M Beziehung, Produkt-Per# <-N:M-> Person_Abt-Per#. Dies kann in einem relationalen
Datenbanksystem nur über eine zusätzliche Tabelle ("Produktion" - Assoziationstabelle)
dargestellt werden.
- 40 -
Datenmodellierung
Haas, Resch
12. Datenmodellierung mit ERWIN
Wir habe bis jetzt schon sehr viele Dinge über Datenmodellierung gelernt:
Wir kenne die Grundbegriffe (Entität, Attribut, Beziehung, Kardinalität, Primary Key, Sekundary Key,
Normalformen, usw.)
Wir kennen bereits zwei unterschiedliche Notationsformen:
•
•
Relationenmodell
Chen Diagramme
Nun beginnen wir uns in eine andere Notationsform einzuarbeiten: ERWIN - Entity Realtion Diagrams
for Windows.
Bis jetzt haben wir uns nur sehr theoretisch mit unseren Datenmodellen befasst - nun werden wir am
Computer unsere Datenmodelle entwickeln und Skripts zum Erzeugen der Tabellen daraus ableiten
lassen.
- 41 -
Datenmodellierung
Haas, Resch
13. Bäume in Tabellen
Beispiel Diensthierarchie
Kriterien für einen echten Baum:
- ein Knoten hat beliebig viele Nachfolger
- ein Knoten hat genau einen Vorgänger
Stappler (SP)
Hickel (HI)
Berger (BF)
Lederbauer (LB)
Figl (FI)
Mitmannsgr. (MI)
Behringer (BE)
Haas (HS)
Sina (SI)
Preissl (PR)
Krieger (KR)
Halbritter (HA)
Wie in eine Tabelle abbilden?
Zwischenschritt:
Lehrer
L#
HI
BF
SP
LB
...
LName
VLName
NULL
HI
HI
HI
Vorgesetzte
VL#
LName
HI
BF
SP
LB
...
Das ist eine 1:N Beziehung mit Auflösung als Non - Key -> "Self Join" oder laut Erwin "Fisher Hook".
Hinweis:
In Erwin über Rollennamen zu lösen!
Also: Eine Tabelle genügt, der Vorgesetzte kommt selbst in der Tabelle vor!
L#
HI
BF
SP
LB
FI
MI
BE
...
VL#
NULL
HI
HI
HI
SP
SP
SP
LName
- 42 -
Datenmodellierung
Haas, Resch
Achtung, KEIN Baum ist etwa eine Stückliste:
Rad
Fahrrad
Speichen
Nabe
Felgen
Rahmen
Lenker
Muttern
Muttern hat mehr wie einen Vorgänger!
Weitere Beispiele für KEINE Bäume:
Stammbaum (ein Kind hat zwei Eltern)
...
Artikel:
Ein Artikel kann aus mehreren Bestandteilen bestehen
ein Artikel kann Bestandteil von mehreren Artikeln sein
Artikel
Artikel
Fahrrad
Rad
Rahmen
Lenker
Speichen
Nabe
Felge
Lenker
1:N
1:N
Stückliste
oben
Fahrrad
Fahrrad
Fahrrad
Rad
Rad
Rad
Rahmen
Nabe
Lenker
unten
Rad
Rahmen
Lenker
Speichen
Nabe
Felgen
Mutter
Muttern
Muttern
Anzahl
2
1
1
26
1
1
5
2
1
N:M
Es werden hier aber nur zwei Tabellen benötigt, da "oben" und "unten" gleiches "Ding", nämlich Artikel
oben: besteht aus
unten: enthalten in
- 43 -