1 Datenmodellierung

1 Datenmodellierung 

Inhalt 

1 Datenmodellierung ............................................................................................................1 

1.1 Einführung in Datenbanksysteme ..............................................................................3 

1.1.1 Definition Datenbank ..........................................................................................3 

1.1.2 Generationen der Entwicklung von Datenbanken ..............................................3 

1.1.3 Nachteile von Dateien und Vorteile von Datenbanken .......................................5 

1.1.4 Datenbankarchitektur..........................................................................................6 

1.2 Begriffe der rationalen Algebra ..................................................................................7 

1.3 Drei Ebenen Architektur nach ANSI/SPARC .............................................................8 

1.4 Definition Datenbank Management System...............................................................9 

1.5 Definition Datenmodelle...........................................................................................10 

1.5.1 Übersicht der Datenmodelle .............................................................................10 

1.5.2 Darstellung von Beziehungen im ERM .............................................................12 

2 Einführung in Relationale Datenmodelle.........................................................................20 

2.1 Relationales Datenmodell ........................................................................................20 

2.2 Der Begriff der Relation ...........................................................................................22 

2.3 Ein einfaches Beispiel..............................................................................................23 

2.4 Schlüssel einer Relation ..........................................................................................24 

2.5 Relationale Integritätsregeln ....................................................................................24 

2.6 Abbildung Entitätstypen/Beziehungen & Entitätstypen/Relationen..........................24 

2.7 Übersicht der Kardinalitäten.....................................................................................25 

2.8 Datenbankentwurf für 1 zu 1 -Beziehungen des ERM.............................................25 

2.8.1 Möglichkeit 1: Entwurf von 2 Relationen...........................................................26 

2.8.2 Möglichkeit 2: Entwurf von 1 Relation...............................................................27 

2.8.3 Datenbankentwurf für 1 zu n -Beziehungen des ERM......................................27 

2.8.4 Datenbankentwurf für m zu n -Beziehungen des ERM.....................................30 

2.9 Normalisierung.........................................................................................................32 

2.9.1 Wozu Normalisierung .......................................................................................32 

2.9.2 Beispiel 1 ..........................................................................................................32 

2.9.3 Beispiel 2 ..........................................................................................................37 

3 Modellierung....................................................................................................................41 

3.1 Vergleich der Methoden...........................................................................................43 

3.1.1 Modellierung impliziert Normalisierung.............................................................43 

3.2 Zusammenfassung ..................................................................................................44 

4 Quellen............................................................................................................................45 

5 Information über Dokument.............................................................................................45

Abbildungen 

Abbildung 1-1: Beispiel Datenbanken Zeitraum der 50iger Jahre............................................3 

Abbildung 1-2: Beispiel Bibliothekssystem...............................................................................4 

Abbildung 1-3: Beispiel – Ein Nutzer leiht mehrere Bücher aus...............................................5 

Abbildung 1-4: ANSI/SPARC Architektur .................................................................................8 

Abbildung 1-5: Einfache Beziehung .......................................................................................12 

Abbildung 1-6: Konditionelle Beziehung.................................................................................13 

Abbildung 1-7: Komplexe Beziehung .....................................................................................13 

Abbildung 1-8: Spezialfälle: 1 Mann hat 0 oder 1 Frau, 1 Frau hat 0 oder 1 Mann................14 

Abbildung 1-9: Symbole in ER Diagrammen..........................................................................15 

Abbildung 1-10: Vergleich Pfeil und „1n“-Notation .................................................................15 

Abbildung 1-11: Beispiel.........................................................................................................16 

Abbildung 1-12: ER-Diagramm mit Link-Attribut. Mehrere Personen (Familie oder...............16 

Abbildung 1-13: Reflexive Beziehungen mit Rollen ...............................................................17 

Abbildung 1-14: Vererbungsbeziehung ..................................................................................18 

Abbildung 2-1: Relationales Datenbankmodell in Tabellenform, Relation: Mitarbeiter...........20 

Abbildung 2-2: Datenstruktur mit einer Periodengruppe (Projekt)..........................................22 

Abbildung 2-3: Relation Angestellter ......................................................................................23 

Abbildung 2-4: Domänen........................................................................................................23 

Abbildung 2-5: ERM ...............................................................................................................25 

Abbildung 2-6: Relationales Modell........................................................................................26 

Abbildung 2-7: Relationales Modell........................................................................................27 

Abbildung 2-8: ERM ...............................................................................................................27 

Abbildung 2-9: Entwurf mit Periodengruppen.........................................................................28 

Abbildung 2-10: Relationales Modell......................................................................................28 

Abbildung 2-11: Beispiel.........................................................................................................29 

Abbildung 2-12: Allgemeine m zu n Beziehung......................................................................30 

Abbildung 2-13: ERM .............................................................................................................30 

Abbildung 2-14: Relationales Modell......................................................................................31 

Abbildung 3-1: Objekte...........................................................................................................41 

Abbildung 3-2: Relationale Darstellungsform .........................................................................41 

Abbildung 3-3: Modellierung und Normalisierung – Methoden ..............................................43 

Abbildung 3-4: Darstellung der ersten drei Normalformen .....................................................44 

Tabellen 

Tabelle 1-1: Begriffe der rationalen Algebra.............................................................................7 

Tabelle 1-2: Übersicht der Datenmodelle...............................................................................10 

Tabelle 1-3: Beschriftung der wichtigsten Begriffe im ERM ...................................................14 

Tabelle 2-1: Übersicht der Notationstypen und Kardinalitäten ...............................................25 

Tabelle 2-2: Relationen Schemata zu Beispiel.......................................................................31 

Tabelle 2-3: Beispiel Dozenten ..............................................................................................32 

Tabelle 2-4: Übersicht Normalformen ....................................................................................33 

Tabelle 2-5: Beispiel Hochschulbetrieb ..................................................................................33 

Tabelle 2-6: Beispiel Hochschulbetrieb 2 ...............................................................................34 

Tabelle 2-7: Hochschulbetrieb 3 – 1. Tabelle.........................................................................34 



Tabelle 2-10: Beispiel Hochschulbetrieb 4 – 3. Normalform ..................................................36 

Tabelle 2-11: Beispiel 2 – Nicht normalisierte Tabelle ...........................................................37 

Tabelle 2-12: Beispiel 2 – 1. Normalform ...............................................................................38 

Tabelle 2-13: Beispiel 2 – 2. Normalform ...............................................................................39 

Tabelle 2-14: Beispiel 2 - Redundanzfreiheit .........................................................................40 

Tabelle 3-1: Tabellen nach Normalisierung............................................................................42

1.1 Einführung in Datenbanksysteme 

1.1.1 Definition Datenbank 

Eine Datenbank ist die Integrierte Speicherung unterschiedlicher Daten mit einer 

programmunabhängigen Verwaltung (und vielfältigen Verarbeitungsmöglichkeiten). 

1.1.2 Generationen der Entwicklung von Datenbanken 

1. Generation 

• Zeitraum der fünfziger Jahre 

• Filesysteme auf Band 

• Stapelverarbeitung 

Abbildung 1-1: Beispiel Datenbanken Zeitraum der 50iger Jahre

2. Generation 

• Zeitraum der sechziger Jahre 

• Filesysteme auf Platte 

• Direktzugriff 

Abbildung 1-2: Beispiel Bibliothekssystem 

Aus der mit der Dateiverarbeitung resultierende Probleme: 

• Hohe Redundanz 

• Gefahr von Inkonsistenzen 

• Geringe Produktivität der Programmierer

3. Generation 

Zeitraum der siebziger Jahre 

Einheitliche Strukturierungsprinzipien der Daten: sog. Datenmodelle 

• Hierarchisches Modell 

• Netzwerkmodell 

• Objekte und Beziehungen zwischen Objekten eines Anwendungsbereichs werden in 

Datensätze und physische Links zwischen den Datensätzen in den Rechner (Speicher) 

abgebildet 

Abbildung 1-3: Beispiel – Ein Nutzer leiht mehrere Bücher aus 

4. Generation 

Zeitraum der achtziger Jahre 

• Relationales Datenmodell 

• strikte Trennung von log. Modell und phys. Speicherung 

1.1.3 Nachteile von Dateien und Vorteile von Datenbanken 

Hält ein Programm sich diejenigen Daten in Dateien, die es braucht, so führt dies in der 

Praxis oftmals dazu, dass Daten redundant gespeichert werden. Dadurch wird eine 

Aktualisierung der Daten sehr aufwendig. Ausserdem muss jedes Programm gleiche 

Funktionen für das Lesen, Schreiben, Aktualisieren, Suchen und vor allem für die 

Behandlung von Fehlerfällen beinhalten. Jeder einzelne Programmierer bestimmt hierbei das 

Ausmass der Integritätskontrollen und der Vorsorgemassnahmen im Fehlerfall. 

Integrität bedeutet z.B., dass wenn ein Mitarbeiter aus dem Datenbestand "Mitarbeiter" 

verschwindet, dass er dann auch aus dem Datenbestand "Firmenkreditkarte" verschwinden 

muss. Ein weiterer Nachteil ist, dass ein jedes Programm genau wissen muss, wie die Daten 

physikalisch gespeichert sind. Ändert man die Datenstrukturen der Dateien, so muss man 

auch die Programme abändern. Isolierte Anwendungen mit Hilfe des Dateikonzeptes 

beruhen auf der Annahme, dass stets alles gut geht und alles stabil bleibt. 

Was man aber haben will, ist dass die Programme unabhängig von der physikalischen 

Speicherung der Daten sind, ja - wenn es geht - sogar unabhängig von der logischen 

Speicherung der Daten. Das Datenbankkonzept beinhaltet die Datenbank als die Menge der 

zentral gespeicherten Daten und das Datenbankverwaltungssystem (DBMS = Data Base 

Management System) als Zusammenfassung aller Funktionen zu ihrer Handhabung.

Das Datenbankkonzept zielt darauf ab: 

• alle Daten nur einmal zu halten und zwar zentral 

• alle Funktionen zum Lesen, Schreiben, Aktualisieren, Suchen nur einmal zentral 

• zu haben 

• alle erforderlichen Funktionen zur Integritätskontrolle und Fehlerbehandlung in der 

erforderlichen Qualität zentral zu halten 

• die Programme von den Daten zu entkoppeln (Erhöhung der Datenunabhängigkeit der 

Programme) 

• Sprachen zur leichteren und flexiblen Handhabung der Daten bereitzustellen 

• Es gibt verschiedene Grade der Datenunabhängigkeit. Hier sei die Einteilung sehr grob 

gemacht: Relationale Datenbanken weisen keine physische Datenabhängigkeit mehr 

auf. Hier ist die physikalische Speicherung dem Anwendungsprogramm verborgen. Der 

Benutzer kennt nur noch die logische Beschreibung der Daten. 

1.1.4 Datenbankarchitektur 

Ziel einer DB-Anwendung: Abbildung eines für eine Anwendung relevanten 

Realitätsausschnittes 

(UoD = Universe of Discourse, Diskursbereich) in einen Rechner und Recherche/ 

Manipulation in diesem Modell 

Datenbanksystem (DBS) = Datenbank (DB) + Datenbankbetriebssystem (DBMS) 

DBMS 

Menge von Programmen (Programmsystem) zur Verwaltung, Strukturierung, Manipulation 

und zum Auffinden von Daten 

DB 

Menge von Daten, die Objekte eines UoD abbilden, die logisch untereinander in 

Beziehungen stehen. Die Daten werden nach einem einheitlichen Verfahren (Datenmodell) 

strukturiert. 

Anforderungen an ein Datenbanksystem 

• (weitestgehende) Redundanzfreiheit 

• Integritätserhaltung durch das System 

• Vermeidung von Inkonsistenzen 

• Zugriffsschutz 

Datenunabhängigkeit 

• physische Datenunabhängigkeit 

• logische Datenunabhängigkeit [1]

1.2 Begriffe der rationalen Algebra 

Selektion Projektion Vereinigung Differenz Durchschnitt 

A 

B 

A 

B 

A 

B 

Selektieren 

bestimmter Tupel 

Selektieren bestimmter 

Spalten (ohne Duplikat.) 

Zwei Tabellen 

verbinden 

z.B. Suchen “Müller” Alle, ohne Duplikation Alle „A“ und „B“ 

Kartesisches Prod. Verbund (Join) Division 

Zwei Tabellen 

vergleichen 

Alle „A“ die nicht in 

„B“ enthalten sind 

Zwei Tabellen 

vergleichen 

Alle „A“, die auch in „B“ 

enthalten sind 

A 

C 

B 

Verbinden alle “A” mit 

allen “B” zu “C” 

A B C 

D 

Verbinden von einzelnen 

Tabellen “A” und “B” und 

“C” zu einer Tabelle “D” 

über Primär-/Sekundärkey 

A B C 

“C” enthält alle “A” und 

“B” die mit einander in 

Beziehung stehen 

Tabelle 1-1: Begriffe der rationalen Algebra 

!!! Vereinigung, Durchschnitt und 

Differenz ist nur möglich wenn 

teilnehmende Relationen 

„vereinigungsverträglich“ sind. 

D.h. wenn diese die gleiche Anzahl an 

Merkmalen und diese identische 

Merkmalswerte aufweisen 

• Selektion σ 

Bestimmte Tupel (Zeilen) einer Relation werden ausgeblendet (Filter) 

• Projektion ∏ 

Bestimmte Merkmale (Spalten) einer Relation werden ausgeblendet. Im Resultat sind 

immer alle Zeilen der Tabelle enthalten mit Ausnahme derjenigen welche identische 

Attributswerte haben. 

• Vereinigung ∪ 

A ∪ B => Kumulation (vertikal) aller Datensätze zweier Tabellen 

• Differenz \ 

A \ B = Ergebnis enthält alle Datensätze aus Tabelle A welche nicht in Tabelle B 

enthalten sind 

• Durchschnitt ∩ 

Das Ergebnis des Durchschnitt A B enthält alle Datensätze aus A welche gleichzeitig 

auch in B enthalten sind. 

• Kartesisches Produkt ⊗ 

Das Kartesische Produkt A ⊗ B verknüpft (horizontal) alle Datensätze aus A mit allen 

Datensätzen aus B Das Ergebnis enthält daher alle Merkmale der teilnehmenden 

Tabellen. D.H. kein grosser Informationswert. 

• Verbund (Join) X 

Die nutzlosen Info des Kartesischen Produkt werden durch das verbinden über Primärund 

Fremdschlüssel ausgefiltert. 

• Division ÷ 

A÷B = alle Zeilen aus A welche mit allen Zeilen aus B in Beziehung stehen. (kann nicht 

SQL formuliert werden) Bsp: An welchem Tag sind alle Lastwagen im Einsatz

1.3 Drei Ebenen Architektur nach ANSI/SPARC 

Die Drei Ebenen Architektur nach ANSI/SPARC bezeichnet man auch als semantisches 

Datenmodell oder ganz simpel als drei Ebenen Modell. 

Die Ebenen werden angewendet, damit nicht schon zu detailliert in die Tiefe gegangen wird 

und die Lösung möglichst HW- / SW- neutral bleibt. 

Gründe welche für diese Modell sprechen: 

• Unabhängigkeit der physischen Speicherung von der Benutzersicht 

• Flexibilität für Änderungen / Anpassungen 

Alle Daten, die auf den ersten Blick zusammengehören werden in der konzeptionellen Ebene 

gesammelt. So entsteht ein Datenmodell, aus dem beliebig viele Benutzersichten (externe 

Ebene) und beliebig viele Speicherarten (interne Ebene) abgeleitet werden können. 

Abbildung 1-4: ANSI/SPARC Architektur 

Interne Ebene 

Beschreibt, wie die Daten auf den externen Speichermedien zu speichern sind. 

Konzeptionelle Ebene 

Zeigt die umfassende hardware- und softwareneutrale Beschreibung der Daten. Sie dient als 

Basis für die Umsetzung des Datenmodells auf die externe Ebene. 

Externe Ebene 

Beschreibt die Sicht der Daten einzelner Benutzer oder Benutzergruppen

1.4 Definition Datenbank Management System 

Ein Datenbank Management System ist ein Programm, welches zwei Hauptkomponenten 

enthält; die erste dient der Speicherung von Daten und die zweite ihre Verwaltung 

• Die Speicherung der Daten erfolgt entsprechend der Struktur des Datenmodells, auf 

welchem die Datenbank basiert. 

• Die Verwaltung von Daten enthält Aufgaben zur Verwaltung von Datenstrukturen, 

Verwaltung von Daten (z.B. Zugriff im Mehrbenutzerbetrieb), Reorganisation, 

Realisierung von Datenschutz und Datensicherheit der Datenbankmodelle.

1.5 Definition Datenmodelle 

Modelle sind reale oder irreale Systeme, die andere Systeme so darstellen, dass eine 

experimentelle Manipulation der abgebildeten Strukturen oder Zustände möglich wird. 

Datenmodelle dienen zur abstrakten Beschreibung von Aspekten der realen Welt. Wichtige 

Mechanismen sind die Klassifikation, die Agregation und die Generalisierung. 

1.5.1 Übersicht der Datenmodelle 

Hierarchisches Modell (K1) Netzwerk-Datenmodell (K1) Relationales Datenmodell (K2) 

A1 

A2 

Root 

Meier 

Hans 

49BF .. 

Jenny Fritz .. 

Twin 

Parent Berger Peter .. 

C2 

B1 

C1 

... ... .. 

3C49 

Mitarbeiter 

Arbeitet in 

Abteilung 

Child 

Buha ... 

G1 

49BF 

D1 E1 F1 G1 

Verkauf ... 

3091 

Einkauf ... 

Hauptmerkmal 

Baumstruktur 

Vorteile 

Hauptmerkmal 

Statische Verknüpfung der Datensätze 

Vorteile 

Hauptmerkmal 

Ansammlung von zwei dimensionalen 

Tabellen 

Vorteile 

• Gute Performance bei Batch 

• Existenz bewährter DBMS 

• Einfachheit 

Nachteile 

• Regeln & Navigation 

(Read,Del,Ins,Upd) 

• Änderungen sind schwierig 

• Redundanzen 

• Komplexe Löschaktionen 

(Elternsatz löscht auch Kindsatz) 

• Aufwendige Änderungsaktionen 

• Gute Performance, da Direktzugriff 

• Existenz bewährter DBMS 

• Leichte Implementierung von 

komplexen Beziehungen 

Nachteile 

• Hohe Komplexität 

• Komplizierte Änderungen des DB- 

Schemas und Adressierung. 

Firma 

- IMS (IBM) - IMAGE/3000 (HP) 

- DBMS-10 (DEC) 

- DMS1100 (UNISYS) 

- UDS (SIEMENS) 

Bedeutung 

- Grossunternehmen 

- Grosse Datenmengen 

• Starre Verkettung und strenge 

Strukturen werden vermieden. 

• Unterstützung des Standard-SQL 

• Transaktionssteuerungs-Konzept 

• Datensicherheit/Datenschutz 

• Portierbarkeit/Skalierbarkeit 

• Werkzeuge und Tools 

- DB2 (IBM) 

- ORACLE 

- INFORMIX 

- RDBMS (DEC) 

- SYBASE 

- DBASE 

- Keine grosse Bedeutung mehr - RDBMS ist heute DIE Technologie 

Tabelle 1-2: Übersicht der Datenmodelle

1.5.1.1 Hierarchisches Modell 

Das hierarchische Datenmodell ist eines der ältesten in Datenbanken verwendeten 

Datenmodelle, es entstand aus Dateien, die eine variable Anzahl von geschachtelten 

Wiederholungsgruppen ermöglichen. Das bekannteste System, das mit dem hierarchischen 

Modell arbeitet, ist IMS (Information Management System) von IBM. 

Das hierarchische Datenmodell kennt Records (Sätze) und physisch realisierte Vater-Sohn- 

Beziehungen (1:n), ausserdem sind virtuelle Vater-Sohn-Beziehungen möglich. 

1.5.1.2 Netzwerkmodell 

Für das Netzwerkmodell gibt es einen Standard der Data Base Task Group der Conference 

on Data System Languages (CODASYL DBTG). Das Netzwerkmodell kennt Record- und 

Set-Typen. Die Set-Typen beschreiben 1:n-Beziehungen zwischen dem Owner-Record-Typ 

und dem Member-Record-Typ. Die 1:n Beziehungen müssen hier jedoch keine Hierarchie 

bilden, durch sie darf ein beliebiges Netzwerk aufgebaut werden. 

Das Netzwerkmodell besitzt eine grössere physische Datenunabhängigkeit als das 

hierarchische Modell, da hier auf der konzeptuellen Ebene nicht festgelegt werden muss, 

welche 1:n-Beziehungen als "virtuelle Beziehungen" realisiert werden sollen. Sowohl das 

hierarchische Modell, als auch das Netzwerkmodell sind relativ implementierungsnah. Beide 

Modelle erfordern das Navigieren in oft komplexen Datenstrukturen. 

1.5.1.3 Das Entity-Relationship-Modell 

Entities sind wohlunterscheidbare Dinge und Konzepte der realen Welt. Ähnliche Entities 

werden in Entity-Sets zusammengefasst. Entities haben Werte, Werte sind Elemente von 

Wertebereichen (Domains). Werte beschreiben Eigenschaften. Auf der Ebene von Entity- 

Sets werden die Eigenschaften auch Attribute genannt. 

Die Namen von Entity-Sets sowie die Attribute werden meistens als zeitinvariant angesehen, 

der Inhalt der Entity-Sets ist dagegen in der Zeit veränderlich. 

Relationships dienen zur Modellierung von Beziehungen zwischen Entities. Relationships 

können Attribute besitzen. Auch bei Relationships kann man zwischen dem zeitinvarianten 

Typ und den veränderlichen Ausprägungen unterscheiden. 

Das Entity-Relationship Modell (ERM) stellt das älteste und allgemeinste Modell zur 

strukturierten Modellierung von Daten dar. Es wurde 1970-76 von Chen definiert und später 

vielfach weiterentwickelt. Viele neue Ansätze, wie das relationale Datenmodell oder die 

Objektorientierte Datenmodellierung haben immer noch viel mit dem ursprünglichen ERM 

gemeinsam. Wegen ihrer Bedeutung für die Modellierung von Daten wurde die Entity- 

Relationship Modellierung nachträglich in die Strukturierte Analyse aufgenommen. 

Der zentrale Begriff in diesem Modell ist die Entität (entity). Damit sind eindeutig 

identifizierbare1 Objekte der realen Welt gemeint. Dies können sowohl konkrete Objekte wie 

Gegenstände, Gebäude oder Personen als auch abstrakte Konzepte wie Verträge, Gesetze 

oder Ideen sein. Alle diese Entitäten haben Eigenschaften. Diese werden als Attribute 

(attribute) bezeichnet. Jedem der Attribute ist eine Domäne (domain) zugeordnet. Diese 

enthält alle Werte, die das Attribut annehmen kann. Ein solcher Wert heisst dann 

Ausprägung des Attributs. Damit repräsentiert die Domäne den Wertebereich des Attributs.

Zwischen Entitäten bestehen Beziehungen (relations). Sie werden nach ihrer Komplexität 

unterschieden. Je nachdem, wieviele Entitäten an der Beziehung beteiligt sind, unterscheidet 

man 3 Fälle: 

1.5.2 Darstellung von Beziehungen im ERM 

1.5.2.1 1 zu 1, einfache Beziehung 

Ein Ehemann hat - in unserer Kultur - genau eine Ehefrau und umgekehrt. 

Abbildung 1-5: Einfache Beziehung

1.5.2.2 1 zu n, konditionelle Beziehung 

Ein Paar kann mehrere Kinder haben, ein Kind jedoch nur einen Vater und eine Mutter. 

Abbildung 1-6: Konditionelle Beziehung 

1.5.2.3 n zu m, komplexe Beziehung 

Eine Person kann mehrere Telefonnummern haben, unter einer Telefonnummer können 

mehrere Personen erreichbar sein. 

Abbildung 1-7: Komplexe Beziehung

Beachten Sie, dass in der Notation mit Pfeilen ein Doppelpfeil von Paar auf Kind zeigt, wenn 

ein Paar 1-n Kinder hat. Streng genommen müsste man noch solche Beziehungen 

unterscheiden, bei denen ein Partner nicht zwingend vorhanden ist (Ein Mann kann 

verheiratet sein, er muss es nicht sein, dasselbe gilt natürlich auch für eine Frau). Diese 

"kann"-Beziehungen werden jedoch im Allgemeinen als Sonderfälle der obigen Fälle 

("muss"-Beziehungen) betrachtet; aus „1 zu“ wird dann „0 oder 1 zu“ aus „genau 1“ wird 

„höchstens 1“. 

Abbildung 1-8: Spezialfälle: 1 Mann hat 0 oder 1 Frau, 1 Frau hat 0 oder 1 Mann 

Zu einem Kind gehört 1 Paar, zu einem Paar gehören 0 bis n Kinder. 

Auch Beziehungen können Eigenschaften besitzen. Diese werden dann Link Attribute 

genannt. Ein Beispiel hierfür wäre das Datum und der Gegenstand eines Kaufs, der über die 

Beziehung „kauft“ zwischen Kunde und Verkäufer modelliert wird. Auch wenn es bei 

einfacher (1-zu-1) und konditioneller Beziehung (1-zu-n) noch möglich wäre, die Link- 

Attribute einer der einfach an der Beziehung beteiligten Entitäten zuzuordnen (z.B. dem 

Kunden, wenn der Verkäufer mehrere Kunden hat, der Kunde aber nur einmal und bei einem 

Verkäufer einkauft), macht doch meist die separate Modellierung über die Beziehung im 

Hinblick auf Verständlichkeit des Modells und zukünftige Erweiterungen (1-zu-n auf m-zu-n, 

ein Kunde darf verschiedene Dinge bei mehreren Verkäufern einkaufen) mehr Sinn. 

Gleichartige Entitäten und Beziehungen kann man unter übergeordneten Entitätstypen bzw. 

Beziehungstypen zusammenfassen. Beispiel: Der Entitätstyp „Kunde“ statt „Herr Müller“, 

„Frau Meier“, etc. 

Tabelle 1-3: Beschriftung der wichtigsten Begriffe im ERM 

Bei der praktischen Modellierung arbeitet man natürlich nicht direkt textuell mit diesen 

Begriffen, sondern - wie bei vielen anderen Verfahren auch - grafisch. Dies kommt der 

Übersicht und dem schnellen Verständnis sehr entgegen. Die dabei verwendeten Symbole 

finden Sie im Folgenden dargestellt. Wie Sie sehen, werden für Entitäten und Beziehungen 

dieselben Symbole wie für die zugehörigen Typen verwendet. Dies rührt daher, dass man im 

Modell weniger mit konkreten Entitäten als vielmehr stellvertretend für ihre Gesamtheit mit 

den Typen modelliert. Das Modell gestattet jedoch auch die Darstellung von Einzelfällen.

Abbildung 1-9: Symbole in ER Diagrammen 

Ein jedes dieser Rechtecke der Grafik, d.h. ein jeder Entitätstyp (ein jeder Objekttyp), 

entspricht einem Datenspeicher in einem DFD. Wenn es im Entity-Relationship Diagramm 

den Objekttyp „Kunde“ gibt, so ist im Datenflussdiagramm der Datenspeicher „Kunde“ 

enthalten. 

1.5.2.4 Regeln zum Aufbau eines ER Diagramms 

Jede Entität wird durch ein oder mehrere Datenelemente - Attribute genannt - beschrieben. 

Entitäten werden mit ihren Attributen durch ungerichtete Kanten verbunden. 

Die Symbole für Beziehungen stehen zwischen den Entitäten, die sie verbinden, und sind mit 

beiden Entitäten durch gerichtete Kanten verbunden. 

Die Komplexität von Beziehungen kann durch die Anzahl der Pfeilspitzen, die stets an der 

Beziehung ansetzen, ausgedrückt werden. Eine Pfeilspitze bedeutet „1“, zwei Pfeilspitzen 

bedeuten „n“ bzw. „m“ bezüglich derjenigen Entität am anderen Ende der Beziehung. Um 

auszudrücken, dass auch die Null mit eingeschlossen ist, können die Pfeilspitzen um eine „0“ 

ergänzt werden. Um beispielsweise zu modellieren, dass ein Paar mehrere Kinder haben 

oder auch kinderlos sein kann, verbindet man die Entität „Paar“ über eine Linie mit 2 

Pfeilspitzen mit der Beziehung „hat“. Hinter der zweiten Pfeilspitze wird eine „0“ eingefügt. 

Von der anderen Seite verbindet man dann die Entität „Kind“ über einen einfachen Pfeil mit 

der Beziehung. Will man ausserdem noch die Möglichkeit von Waisenkindern 

berücksichtigen, kann man auch hier die Pfeilspitze durch eine „0“ ergänzen (vgl. Beispiele 

oben). Eine alternative Notation mit Komplexitätsangaben „1,n“ wurde bereits beschrieben. 

In der Literatur existieren weitere alternative Notationen. 

Abbildung 1-10: Vergleich Pfeil und „1n“-Notation 

Alle Elemente werden entweder direkt im Diagramm beschriftet oder mit einer Nummer 

versehen und extern erklärt (letzteres Verfahren wird häufig für Beziehungen angewandt). 

Dabei gilt die Empfehlung, Beziehungen so zu beschriften, dass sie von oben nach unten 

oder von links nach rechts gelesen werden können. Ist dies nicht möglich und ist die 

Leserichtung nicht aufgrund der Namensgebung offensichtlich, so ist die Leserichtung durch 

kleine Richtungspfeile neben dem Beziehungssymbol zu kennzeichnen. Alle Namen sollen

kurz, prägnant und vielsagend sein. Für Entitäten und Attribute sind Substantive (Person, 

Adresse, Alter, Name), für Beziehungen Verben (hat, ist, wohnt) zu bevorzugen. 

Abbildung 1-11: Beispiel 

Abbildung 1-12: ER-Diagramm mit Link-Attribut. Mehrere Personen (Familie oder 

Wohngemeinschaft) mieten eine Wohnung. Zum Mietvorgang gehört 

die Miete. Miete ist also ein Linkattribut.

1.5.2.4.1 Modellerstellung 

Wie geht man nun bei der Modellerstellung vor Oftmals wird man als Vorlage eine textuelle 

Beschreibung einer Aufgabe oder eines Vorgangs haben. Um aus ihr ein erstes Modell zu 

extrahieren, müssen zunächst Entitäten, Attribute und Beziehungen identifiziert werden. 

Dabei sind Substantive Kandidaten für Entitäten, Adjektive Kandidaten für Attribute und 

Verben Kandidaten für Beziehungen. Es ist jedoch Sorgfalt angebracht, denn auch Attribute 

können durch Substantive bezeichnet sein. Entitäten, die aus einer solchen Betrachtung 

entstehen, müssen verifiziert werden. Besitzen sie keine Eigenschaften oder gehen sie keine 

Beziehungen ein, sind sie vermutlich überflüssig. Umgekehrt ist es oft sinnvoll, eine Gruppe 

zusammengehöriger Attribute als eigenen Entitätstyp zu realisieren, wenn dieser für sich 

einen Sinn macht, Beziehungen eingehen kann und somit an mehreren Stellen benutzt 

werden kann (Zum Beispiel haben Personen und Firmen eine Adresse mit PLZ, Ort, Strasse 

und Hausnummer. Diese wird als eigener Entitätstyp realisiert). Für die Attribute müssen die 

Domänen definiert werden (z.B. Entität Datum, Attribut Monat: 1..12). An dieser Stelle 

werden auch Überlegungen zu Integritätskriterien angestellt. Ein Wert kleiner 1 oder grösser 

12 beim Monat ist offensichtlich ungültig. Schwieriger ist da schon die Entdeckung von 

Fehlern wie "31.2." . Hier muss der Wertebereich des Tages (1..31) abhängig vom Monat 

eingeschränkt werden. Schliesslich ist noch zu prüfen, ob das Modell alle Anfragen, die sich 

aus der Aufgabenstellung ableiten lassen, befriedigen kann (einfache Beziehungen können 

in beiden Richtungen eindeutig durchlaufen werden, konditionale nur in einer und komplexe 

gar nicht). Vor der Implementierung des Modells kann es dann noch nötig sein, das 

Datenmodell zu normalisieren. Damit wollen wir uns später in diesem Dokument 

beschäftigen. 

1.5.2.4.2 Reflexive Beziehungen/Vergabe von Rollen 

Reflexive Beziehungen bestehen nicht zwischen Entitäten verschiedener Entitätstypen, 

sondern zwischen Entitäten desselben Typs. Ein Beispiel hierfür ist die Beziehung „ist Vater 

von“ zwischen Entitäten des Typs Person. Im Diagramm sind demzufolge beide Seiten der 

Beziehung mit demselben Entitätstyp verbunden. Die Entitäten treten jedoch in 

verschiedenen Rollen auf. In unserem Beispiel als Vater und Kind. Diesem Umstand trägt 

man durch Beschriftung der beiden Seiten der Beziehung mit dem Rollennamen Rechnung. 

Man beachte, wie mit Hilfe der Beziehungen ausgedrückt werden kann, dass zwar ein Kind 

nur einen Vater, ein Vater jedoch durchaus mehrere Kinder haben kann. 

Abbildung 1-13: Reflexive Beziehungen mit Rollen

1.5.2.4.3 Vererbungsbeziehung 

Vererbung wird verwendet, um auszudrücken, dass Gemeinsamkeiten (d.h. gemeinsame 

Attribute) von Entitätstypen in einem separaten, übergeordneten Entitätstyp untergebracht 

sind, mit dem die ursprünglichen Entitätstypen eine besondere Beziehung eingehen. 

Dadurch wird die redundante Modellierung in beiden Entitätstypen vermieden und 

gleichzeitig ihre Gemeinsamkeit explizit im Modell deutlich gemacht. 

Abbildung 1-14: Vererbungsbeziehung 

Das obige Beispiel drückt aus, dass sowohl Angestellte als auch Arbeiter Personen mit 

Name, Vorname und Geburtsdatum sind. Jeder Arbeiter/Angestellte ist mit einer Entität des 

Typs Person verbunden, welche die gemeinsamen Attribute aufnimmt. Zusätzlich ist es mit 

diesem Mechanismus möglich, dass eine Person ein Arbeitsverhältnis als Angestellter und 

gleichzeitig eines als Arbeiter hat (auch bei verschiedenen Firmen), ohne dass seine 

Stammdaten doppelt gespeichert werden: Der Arbeiter und der Angestellte referenzieren 

einfach dieselbe Person. Eine Vererbungsbeziehung ist also (von unten nach oben) 

entweder 1-zu-1 oder n-zu-1. Mehrfachvererbung kann durch mehrere 

Vererbungsbeziehungen ausgedrückt werden. 

Die Vererbungsbeziehung drückt die is-a (ist) Beziehung aus (z.B. Ein Angestellter ist eine 

Person). Sie ist zu unterscheiden von der has-a (hat) Beziehung (z.B. eine Person hat eine 

Adresse). Die has-a Beziehung ist eine Beziehung zu einem anderen Entitätstyp, der quasi 

ein indirektes Attribut des Ursprungstyps darstellt. Die besondere Darstellungsform der is-a 

Beziehung ist eine Erweiterung des ERM nach Chen. Die ursprüngliche Darstellung macht 

nochmals deutlich, dass es sich bei is-a lediglich um eine spezielle Beziehung handelt. 

Mit Hilfe der Vererbungsbeziehung können auch mehrstufige Hierarchien aufgebaut werden. 

Es ist jedoch zu beachten, dass eine Entität der untersten Hierarchiestufe zum Zugriff auf

Attribute die es von ganz oben „geerbt“ hat sämtliche Beziehungen durchlaufen muss. Dies 

kann bei der Implementierung u.U. lange dauern. Demnach sollte man den Gebrauch der 

Vererbung auf ein vernünftiges Mass beschränken. 

1.5.2.4.4 Umwandlung in ein relationales Modell 

Das ERM ist ein allgemeines Modell zur Modellierung von Daten, mit der Implementierung 

(z.B. von Beziehungen) und den Beschränkungen, die dabei möglicherweise beachtet 

werden müssen, befasst es sich nicht. Dieser Unterschied besteht generell zwischen 

Modellen und Implementierungen. Modelle sind allgemein und gehen von einer „idealen 

Welt“ aus, die Implementierung ist jedoch immer gewissen Beschränkungen unterworfen. 

Standard zur Implementierung von Datenbanken sind heute Relationale DBMS. Sie beruhen 

auf dem relationalen Datenmodell. Zur Implementierung eines ERM mit Hilfe einer solchen 

Datenbank muss dieses zunächst in ein Relationales Modell konvertiert werden. Obwohl 

diese Konvertierung über weite Strecken keine Änderung des eigentlichen Modells 

notwendig macht, sondern eher einem simplen Wechsel der Notation gleichkommt gibt es 

hier und da Dinge, die man beachten muss. So kennt zum Beispiel das relationale Modell 

keine m-zu-n Beziehungen. [3]

2 Einführung in Relationale Datenmodelle 

2.1 Relationales Datenmodell 

Das relationale Datenmodell kennt nur Tabellen, auch Relationen genannt. Auf der Schema- 

Ebene werden die Formate der Tabellen beschrieben. Die Tabellen haben eindeutige 

Namen. Jede Tabelle hat eine feste Anzahl eindeutig benannter Spalten. Für jede dieser 

Spalten muss ein Wertebereich angegeben werden. Die in den Ausprägungen der Tabellen 

stehenden Zeilen (Tupel) müssen stets der Schemadefinition entsprechen. 

Weitere Forderungen des relationalen Modells: 

• Erste Normalform - in den Spalten dürfen nur atomare Werte stehen, 

Wiederholungsgruppen sind nicht erlaubt. 

• Zeilen können nur durch ihren Inhalt identifiziert werden, d.h. die Tabelle ist eine Menge 

von Tupeln (duplikatfrei). Es gibt keine vom Modell vorgeschriebenen Tupel-IDs. [2] 

Das relationale Datenbankmodell verwendet zweidimensionale Tabellen (oder alternativ eine 

auf der Relationenalgebra beruhende mathematisch-formale Schreibweise, siehe bspw. das 

Buch von Vetter) zur Darstellung des Realitätsausschnittes. Alle Gegenstände der 

Diskurswelt können durch zweidimensionale Tabellen anschaulich und vollständig 

beschrieben werden. Der theoretisch-mathematische Hintergrund ist sehr anspruchsvoll und 

begründet die Leistungsfähigkeit des Modelles. 

Beim relationalen Datenbankmodell sind einige Begriffe wichtig, die durch nachstehende 

Abbildung erläutert werden: 

Entity 

Abbildung 2-1: Relationales Datenbankmodell in Tabellenform, Relation: Mitarbeiter 

ist ein Objekt im ERM, das im Relationenmodell als Zeile mit all seinen Eigenschaften 

umgesetzt wird (entspricht Tupel). 

Tupel 

sind die einzelnen Zeilen in der Tabelle, also die konkreten Objekte (entspricht Entity). 

Entity-Typ 

ist die Relation, also die gesamte Tabelle.

Attribute 

sind die Spaltenüberschriften in der Tabelle. Das unterstrichene Attribut ist das 

Schlüsselattribut. In der Abbildung oben ist das Schlüsselattribut die Pers-Nr. Es ist nicht 

unterstrichen, weil ACCESS eine Unterstreichung der Schlüsselattribute in der vorgestellten 

Ansicht nicht vornimmt. Eigentlich ist das nur eine Kleinigkeit, sie kann dennoch 

verdeutlichen, dass Software aus betriebswirtschaftlicher Sicht i.P. immer 

verbesserungsfähig ist. 

Wertebereich 

ist der zulässige Variableninhalt, also die Domänen der einzelnen Attribute. 

Attributwert 

ist der Inhalt einer Zelle innerhalb der Tabelle. 

Das Relationale Daten-Modell, kurz Relationen-Modell genannt, wurde 1970 von E.F. Codd 

entwickelt. Das Relationen-Modell besteht wie bereits vorher geschrieben aus 3 Teilen: 

Objekten: 

Die folgenden Objekte müssen definiert werden: 

• Relationen (oder Tabellen). Sie entsprechen den Entitätstypen des Entity-Relationship 

Modells 

• Tuple (oder Datensatz oder Record). Ein Tuple entspricht einer konkreten Entität des 

Entity-Relationship Modells 

• Attribut (Spalte). Ein Attribut eines Entitätstyps entspricht einem Attribut einer Relation 

und stellt eine Spalte einer Tabelle dar 

• Domain (Wertebereich). Der Wertebereich eines Attributs muss festgelegt werden, 

damit bei Änderungen der Attributwerte Syntaxprüfungen durchgeführt werden können 

• Schlüssel. Schlüssel erlauben den Zugriff auf Tuples. Von Bedeutung sind Candidate- 

Keys (eindeutige Schlüssel), Primary Keys (Primärschlüssel, Hauptschlüssel), 

Alternate Keys (Sekundärschlüssel, Zweit-Schlüssel), Foreign-Keys 

(Fremdschlüssel). Die Bedeutung der einzelnen Schlüssel wird im folgenden noch 

erläutert werden 

Operationen: 

Abfrage- und Update-Operationen auf den Relationen, sowie zum Anlegen und 

Löschen von Relationen 

Regeln: 

Diese dienen zur Gewährleistung der Konsistenz der Daten. Hierbei geht es um die Entity- 

Integrität und referentielle Integrität. Beide Integritätsregeln müssen im Folgenden noch 

erklärt werden

2.2 Der Begriff der Relation 

In diesem Kapitel sollen die grundlegenden Begriffe, die im Zusammenhang mit Relationalen 

Daten-Modellen gebraucht werden, erläutert werden. Da die Basis des Relationalen Daten- 

Modells das 1970 von Codd entwickelte Relationen-Modell (Codd 70) darstellt, soll dieses 

nun kurz charakterisiert werden. Als Relation (dt. Beziehung) bezeichnet man eine logisch 

zusammenhängende Einheit von Informationen. Eine Relation entspricht einem Entitätstyp. 

Eine Relation stellt eine zweidimensionale Tabelle mit einer festen Anzahl von Spalten 

(Attributen) und einer variablen Anzahl von Tupeln (Zeilen) dar. Eine Relation ist durch ihren 

Namen und die Namen der Attribute eindeutig beschrieben. Die Anzahl der Attribute einer 

Relation heisst Degree (Ausdehnungsgrad). Die Anzahl der Zeilen einer Relation - diese 

Anzahl kann sich dynamisch ändern und kann auch Null werden - heisst Kardinalität der 

Relation. 

Eine Relation hat die folgenden Eigenschaften: 

Es gibt keine zwei Tupel, die in ihren Attributwerten übereinstimmen. Die Reihenfolge, 

in der die Tupel einer Relation gespeichert werden, ist nicht definiert, d.h. es gibt keine 

Reihenfolge der Tupel. Genauso wenig ist die Reihenfolge, in der die Attribute einer Relation 

gespeichert werden, definiert. Macht man den Übergang von dem Entity-Relationship Modell 

zum Relationalen Datenbank-Entwurf, so werden Beziehungs-Typen zwischen Entitätstypen 

(Relationen) im Relationalen Modell abgebildet auf Relationen oder auf Attribute einer 

Relation. Die Entitäten als konkrete Objekte werden als Tupel (Datensatz) bezeichnet. Sie 

bilden die Zeilen einer Tabelle. 

Die Struktur einer Relation wird auch als Relationen-Schema bezeichnet. Das Relationen- 

Schema beschreibt den Aufbau der Tupel einer Relation, nicht aber die einzelnen Tupel- 

Ausprägungen (Werte). Jedes Tupel einer Relation setzt sich aus den gleichen Relations- 

Attributen zusammen. Die Attribute der Relation bilden die Spaltenüberschriften einer 

Tabelle. In einer Spalte stehen verschiedene oder gleiche Attributwerte, die alle einer 

Domäne angehören. 

Atomare Werte der Attribute: 

Die Attribute bestehen nur aus einem Wert pro Tupel, nicht aus mehreren Werten. Sie sind 

„atomar“. 

Abbildung 2-2: Datenstruktur mit einer Periodengruppe (Projekt) 

Im Beispiel der Abbildung kann ein Firmen-Mitarbeiter in mehreren Projekten mitarbeiten. 

Dies kann durch eine Periodengruppe ausgedrückt werden. Das Feld Projekt kann dabei 

mehrere Werte annehmen. Solche Periodengruppen sind aber nicht „atomar“, da mehrere 

Werte für ein Attribut existieren. Sie sind also im Rahmen der Relationen nicht zulässig.

2.3 Ein einfaches Beispiel 

Ein Relationen-Modell beschreibt Objekte der realen Welt durch eine Menge von Attributen, 

die die gemeinsamen Eigenschaften der Objekte repräsentieren. Nachfolgende Abbildung 

zeigt ein Beispiel für eine Relation. 

Abbildung 2-3: Relation Angestellter 

Das Beispiel hat 5 Tupel. Jedes Tupel setzt sich aus 3 Attributen zusammen, von denen 

jeder Attributwert einer anderen Domäne entstammt. Die Reihenfolge der Attribute in den 

Tupeln muss eingehalten werden. Mit anderen Worten, Attribute müssen immer unter den 

dazugehörigen Attributnamen stehen. Eine andere Geschichte ist, dass die Reihenfolge, in 

der die Attribute einer Relation gespeichert werden, nicht definiert ist. 

Abbildung 2-4: Domänen

2.4 Schlüssel einer Relation 

Eine Zusammenstellung von Attributwerten heisst Candidate-Key (Schlüssel- Kandidat), 

wenn die Werte, die diese Attribute annehmen, stets ein Tupel eindeutig identifizieren. Ein 

Candidate-Key kann aus einem oder mehreren Attributnamen bestehen. Eine Relation kann 

einen oder mehrere Candidate-Keys besitzen. Da in einer Relation keine zwei identischen 

Tupel existieren, muss es immer mindestens einen Candidate Key - nämlich die 

Zusammenstellung aller Attributnamen - geben. Ein Candidate-Key darf keine überflüssigen 

Attributnamen enthalten. Diese müssen entfernt werden, jedoch darf keines der Schlüssel- 

Attribute vernachlässigt werden, damit die eindeutige Identifizierbarkeit nicht verloren geht. 

Mit anderen Worten, ein Candidate-Key umfasst soviel Attributnamen wie nötig und sowenig 

wie möglich. 

Ein Primary-Key ist ein Candidate-Key, der zum Primary-Key erklärt wird oder der als neues 

Attribut (z.B. Personal-Nummer) speziell zu diesem Zweck eingeführt wird. Eine Relation 

besitzt genau einen Primärschlüssel. Um auf ein Tupel zugreifen zu können oder ein neues 

Tupel einzufügen zu können, ist die Angabe des jeweiligen Primärschlüssels erforderlich. 

Fremdschlüssel dienen dazu, um Relationen zu verknüpfen und um die referentielle Integrität 

der Datenbank (siehe später) zu gewährleisten. Ein Fremdschlüssel einer Relation muss 

dabei immer Primärschlüssel einer anderen Relation sein. Der Fremdschlüssel referenziert 

auf ein Tupel der Relation, in der er Primärschlüssel ist. Das Tupel der Relation ist mit dem 

Fremdschlüssel und das Tupel der Relation mit dem entsprechenden Primärschlüssel 

miteinander durch eine 1 zu n Beziehung verknüpft. Dies wird als Primärschlüssel- 

Fremdschlüssel-Prinzip bezeichnet. Um Fremdschlüssel zu kennzeichnen, wird ihnen ein # 

Zeichen nachgestellt. 

2.5 Relationale Integritätsregeln 

Mit der Entity-Integrität wird sichergestellt, dass jedes Tupel (Entity) in einer Relation einen 

eindeutigen Schlüssel besitzt. Da NULL-Werte nicht eindeutig sind, darf der Primary-Key 

keinen NULL-Wert enthalten. Durch die referentielle Integrität wird sichergestellt, dass jedem 

Wert eines Foreign-Keys in einer Relation R2 gleich ist einem Wert des Primary-Keys in 

einer Relation R1 oder dass der Wert des Foreign-Keys ein NULL-Wert ist. Referentielle 

Integrität bedeutet z.B. dass wenn ein Mitarbeiter aus dem Datenbestand "Mitarbeiter" 

verschwindet, dass er dann auch aus dem Datenbestand "Firmenkreditkarte" verschwinden 

muss. 

2.6 Abbildung Entitätstypen/Beziehungen & 

Entitätstypen/Relationen 

Nachdem in vorigen Kapitel die Grundlagen des Relationalen Daten-Modells erörtert wurden, 

soll nun in diesem Kapitel der Datenbankentwurf im Vordergrund stehen. Auszugehen ist 

vom logischen Datenmodell, welches mit Hilfe der Entity- Relationship-Modellierung erstellt 

wurde. Die Fragestellung ist nun, wie die Entitätstypen und ihre Beziehungen umzusetzen 

sind in Datenbank-Tabellen. Beginnen wir zunächst mit dem einfachsten, der Abbildung von 

1 zu 1-Beziehungen. Es folgt dann die Umsetzung von 1 zu n-Beziehungen und last not least 

die Abbildung von n zu m-Beziehungen auf Tabellen.

2.7 Übersicht der Kardinalitäten 

Eine Kardinalität dient einer genauen Bestimmung einer Beziehung zwischen Entitätstypen. 

Sie legt für jede Richtung fest, wieviele Entitäten an einer Beziehung teilnehmen. Dies 

geschieht über die Angabe eines Minimum ( 0 oder 1) und eines Maximum ( 1 oder N ). 

Notation nach : 

Bachmann 

1; Genau ein: 

(einfache 

Assoziation) 

C; kein oder ein: 

(konditionelle 

Assoziation) 

M; ein oder mehrere: 

(komplexe Assoziation 

MC; kein, ein oder mehrere: 

Konditionell-komplexe 

Assoziation) 

Vetter 

IEM (James 

Martin) 

SSADM 

Zehnder 1 C m mc 

Chen 1:1 0:1 1:N 0:N 

Tabelle 2-1: Übersicht der Notationstypen und Kardinalitäten 

2.8 Datenbankentwurf für 1 zu 1 -Beziehungen des ERM 

Anhand eines Beispiels wird die Modellierung einer 1 zu 1-Beziehung gezeigt. Es werden 

zwei Möglichkeiten des Entwurfs vorgestellt. Bei der ersten Möglichkeit werden 2 Relationen 

entworfen, bei der anderen nur eine einzige Relation. Den Ausgangspunkt für den Entwurf 

stellt das folgende Entity-Relationship-Diagramm dar. 

Abbildung 2-5: ERM 

Es gibt die Entitätstypen "Mitarbeiter" und "Abteilung", sowie die Beziehung "leitet". Jede 

Abteilung wird von einem Mitarbeiter geleitet. Jeder Mitarbeiter kann keine oder maximal 1 

Abteilung leiten.

2.8.1 Möglichkeit 1: Entwurf von 2 Relationen 

Jeder Entitätstyp wird durch eine eigene Relation dargestellt. Die Beziehung zwischen 

beiden Relationen wird hergestellt durch einen Fremdschlüssel in einer der beiden oder in 

beiden Relationen. Der Fremdschlüssel entspricht dann dem Primärschlüssel der 

verbundenen Relation. Eventuell vorhandene Link-Attribute (hier keine vorhanden) werden 

als Attribute in einer der beiden Relationen abgebildet. 

In unserem Beispiel leitet ein Mitarbeiter entweder eine oder keine Abteilung (0,1). Würde 

man den Fremdschlüssel bei der Relation Mitarbeiter modellieren, hätte man folgendes 

Problem: Alle Mitarbeiter, die keine Abteilung leiten, müssten NULL als Attributwert bei dem 

Fremdschlüssel (abtlgNr#) haben. Deshalb wird hier entschieden in der Relation 

ABTEILUNG mit dem Fremdschlüssel PersNr# den Bezug zwischen beiden Tabellen 

herzustellen. 

Der Datenbankentwurf sieht dann folgendermassen aus: 

Relation (Entitätstyp) MITARBEITER (persNr, name, vorname) 

Relation (Entitätstyp) ABTEILUNG (abtlgNr, name, persNr# ... ) 

Abbildung 2-6: Relationales Modell

2.8.2 Möglichkeit 2: Entwurf von 1 Relation 

Abbildung der Entitätstypen auf Attribute dieser Relation 

Bei jeder 1 zu 1 Beziehung können die Attribute beider Entitätstypen in einer Relation 

zusammengefasst werden, hier in der Relation ABTEILUNG. Dies ist allerdings nur sinnvoll, 

wenn der Entitätstyp ANGESTELLTER keine weiteren Beziehungen eingeht und deshalb 

nicht eigenständig modelliert wird. Ein Fremdschlüssel ist hier natürlich nicht notwendig. 


Relation (Entitätstyp) ABTEILUNG (persNr, name, vorname, abtlgNr, name, leiternr... ) 

Abbildung 2-7: Relationales Modell 

2.8.3 Datenbankentwurf für 1 zu n -Beziehungen des ERM 

Anhand eines Beispiels soll die Abbildung auf Relationen für 1 zu n-Beziehungen erläutert 

werden. In diesem Beispiel arbeiten in einer Abteilung mehrere Mitarbeiter, mindestens 

jedoch 1 Mitarbeiter. Jeder Mitarbeiter arbeitet in genau einer Abteilung. Zur Beziehung 

gehören 2 Attribute: Eintrittsdatum in die Abteilung und Aufgabe in der Abteilung. 

Abbildung 2-8: ERM

Zunächst wäre man versucht, eine Periodengruppe zu entwerfen: 

Abbildung 2-9: Entwurf mit Periodengruppen 

Periodengruppen sind jedoch - wie Sie bereits wissen - nicht zulässig. Also muss man 

anders vorgehen: Ein Entwurf mit nur 1 Relation geht also nicht, man muss 2 Relationen 

entwerfen. Jede 1 zu n Beziehung kann durch 2 Relationen definiert werden. Die Beziehung 

wird als Fremdschlüssel in der Relation modelliert, deren Tupel n-fach in der Beziehung 

auftreten (siehe Modellierungsvergleich auf der nächsten Seite). Der Fremdschlüssel 

entspricht dem Primärschlüssel in der 1-fach auftretenden Relation. Würde man den 

Fremdschlüssel in der Relation angeben wollen, deren Tupel einfach in der Beziehung 

auftreten, so hätte man wieder das Problem der Periodengruppe. 

Die Link-Attribute werden in der n-fachen Relation modelliert (im folgenden fett dargestellt). 


Relation (Entitätstyp) MITARBEITER (persNr, name, vorname, abtlgNr #, eintritt, aufgabe) 

Relation (Entitätstyp) ABTEILUNG (abtlgNr, name, leiter, ...) 

Abbildung 2-10: Relationales Modell

2.8.3.1 Modellierungsvergleich 

Beispiel: 8 Mitarbeiter arbeiten in jeweils einer, von insgesamt 3 Abteilungen. 

Abbildung 2-11: Beispiel

Bei der Möglichkeit 2 werden Name und Budget der Abteilung redundant gespeichert, zudem 

wird dadurch mehr Speicherplatz benötigt. Deshalb ist Möglichkeit 1 vorzuziehen. Bei einer 

1 zu n Beziehung wird also die Beziehung als Fremdschlüssel in der Relation modelliert (hier 

Relation Mitarbeiter), deren Tupel n-fach in der Beziehung auftreten. 

2.8.4 Datenbankentwurf für m zu n -Beziehungen des ERM 

• Zwischen den Entitäten1 und 2 existiert ein Beziehungs-Typ. 

• Jeweils m Tupel der Entität 1 können mit n Tupeln der Entität 2 in Beziehung stehen. 

• Jede Beziehung hat i Attribute. 

Abbildung 2-12: Allgemeine m zu n Beziehung 

2.8.4.1 Entwurf für allgemeine m zu n-Beziehungen (n > 1, m > 1) 

Die beiden Entitäten werden direkt in zwei Relationen 1 und 2 überführt. Die Beziehung 

zwischen der Relation 1 und der Relation 2 wird durch eine neue dritte Relation ausgedrückt. 

Der Primärschlüssel der dritten Relation setzt sich aus den Primärschlüssel-Attributen der 

Relation 1 und aus den Primärschlüssel-Attributen der Relation 2 zusammen. 

Um die obigen Sachverhalte noch etwas zu verdeutlichen, sollen diese anhand eines 

Beispiels erläutert werden. Im Beispiel gibt es Projekte, an denen mehrere Mitarbeiter 

arbeiten. Ein Mitarbeiter kann in keinem, einem oder mehreren Projekten mitarbeiten. 

In den Bildern unten ist der Übergang vom Entity-Relationship-Modell zum Relationalen 

Modell zu sehen. Der Entitätstyp Mitarbeiter des ERM wird zur Relation MITARBEITER im 

Relationalen Modell, aus dem Entitätstyp Projekt wird die Relation PROJEKT und aus der 

Beziehung "arbeitet mit an" wird die Relation MA_PROJEKT. Zur Beziehung gehören zwei 

Attribute: 

Abbildung 2-13: ERM


• Relation MITARBEITER (persNr, name, vorname, abtlgNr, ... ) 

• Relation PROJEKT (projektNr, name, leiter, ... ) 

• Relation MA_PROJEKT (persNr#, projektNr#, aufgabe, dauer ) 

Abbildung 2-14: Relationales Modell 

Im Folgenden werden die Relationen-Schemata dargestellt: 

Tabelle 2-2: Relationen Schemata zu Beispiel

2.9 Normalisierung 

2.9.1 Wozu Normalisierung 

Die Normalisierung hilft uns beim fachgerechten Entwurf von relationalen Datenmodellen. 

Bei Beachtung der Normalisierungsregeln werden Redundanzen beseitigt und 

Updateanomalien vermieden. 

Eine Normalisierung findet stets aufgrund bereits bestehender Tabellen statt. Ist die Aufgabe 

in Textform gegeben, müssen die Tabellen zuerst erzeugt werden. Dafür werden geeignete 

Testdaten benötigt, die den Wertebereich der Aufgabenstellung abdecken. Die 

Normalisierung kann nur bezogen auf diese Daten stattfinden. Mit anderen Daten ergibt sich 

eine andere Normalisierung. Anhand eines hier durchgeführten Beispiels sollen nun die 

Grundlagen und Regeln der Normalisierung bekannt gemacht werden. 

2.9.2 Beispiel 1 

An einer Fachhochschule für Technik werden Vorlesungen von Dozenten gehalten. Die 

Dozenten gehören zu einem Fachbereich, welcher von einem Dekan geleitet wird. Die 

Verwaltung erfolgt in einer relationalen Datenbank. Dann könnte ein Eintrag in der 

Datenbank wie folgt aussehen: 

Tabelle 2-3: Beispiel Dozenten 

Als ein Pflegeproblem dieses Beispiels (weitere folgen später), sei hier das folgende 

erwähnt: 

• Ändert sich die maximale Anzahl der Studenten in einem Semester, so muss in jedem 

Eintrag in der Datenbank, in dem die Anzahl Studenten vorkommt, die maximale Anzahl 

der Studenten geändert werden 

• Wird ein Eintrag vergessen, kommt es zu Inkonsistenzen Abhilfe schafft die 

Normalisierung. Dann genügt ein Zugriff auf ein Tupel. Inhaltliche widersprüchliche 

Datensätze kommen somit nicht vor. Zudem werden die Updates sehr 

änderungsfreundlich (Minimalisierung der Anzahl der Updates). 

Wie die Übersicht zeigt, gibt es viele verschiedene Normalformen. In der Praxis 

beschränkt man sich jedoch auf die dritte Normalform.

Tabelle 2-4: Übersicht Normalformen 

Jede Normalform enthält implizit die vorgehende Normalform (die 3. Normalform enthält die 

zweite und damit die erste Normalform). Um auf eine Normalform zu kommen, müssen nicht 

zwangsweise die vorgehenden Normalformen durchlaufen werden ( d.h. man kann z.B. mit 

etwas Übung direkt auf die 3. NF kommen). 

2.9.2.1 Unnormalisierte Relationen 

Eine Relation heisst unnormalisiert, wenn die Attribute nicht atomare Werte enthalten, 

gegenseitig Beziehungen eingehen oder nicht funktionell abhängig vom eindeutigen 

Primärschlüssel sind. 

Tabelle 2-5: Beispiel Hochschulbetrieb 

Wie in diesem Beispiel (Hochschulbetrieb 1) zu sehen ist, werden alle 3 Normalformen 

verletzt.

2.9.2.2 Erste Normalform 

Eine Relation befindet sich in der 1. Normalform, wenn alle zugrunde liegenden 

Wertebereiche nur atomare Werte enthalten. Vor der Überführung in die zweite Normalform 

ist die Einführung des Primärschlüssels von Bedeutung. Der Primärschlüssel muss so 

gewählt werden, dass jede Zeile eindeutig ist. In diesem Beispiel wählen wir Dozent_Nr, 

Semester und Fach als Primärschlüssel aus. 

Wir sehen hier die Relation, in der die 1. NF erfüllt ist, aber die 2. und die 3. NF verletzt sind. 

Tabelle 2-6: Beispiel Hochschulbetrieb 2 

2.9.2.3 Zweite Normalform 

Eine Relation ist in 2. Normalform, wenn sie in 1. Normalform ist und wenn jedes 

Nichtschlüsselattribut voll funktional abhängig ist vom Primärschlüssel. Felder, die nur von 

einem Schlüsselteil abhängen, werden separat modelliert. Die zweite Normalform kann somit 

nur verletzt werden, wenn der Primärschlüssel aus mehr als einem Attribut 

zusammengesetzt ist. 

In diesem Beispiel ist die 1. und 2. Normalform erfüllt. Aus einer Tabelle entstehen 3 

Tabellen (separate Modellierung). Das ist notwendig, da 

• die Anzahl der Stunden nur vom jeweiligen Semester abhängt 

• und da Anz_Stud/Fachbereich/Dekan_Nr nicht voll funktional abhängig sind von 

Semester/Dozent-Nr/Fach (Primärschlüssel) 

Tabelle 2-7: Hochschulbetrieb 3 – 1. Tabelle

Tabelle 2-8: Hochschulbetrieb 3 – 2. Tabelle 

Tabelle 2-9: Hochschulbetrieb 3 – 3. Tabelle 

Beachten Sie, dass die Relation Dozent/Vorlesung den zusammengesetzten Primärschlüssel 

Semester/Dozent-Nr/Fach besitzt. 

Vorteil: Ändert sich die max. Anzahl der Studenten eines Semesters, so genügt jetzt das 

Updaten eines Tupels.

2.9.2.4 Dritte Normalform 

Eine Relation ist genau dann in der 3. Normalform, wenn sie in 1. und 2. NF ist und wenn 

alle Nichtschlüsselattribute gegenseitig unabhängig, aber voll funktional abhängig vom 

gesamten Primärschlüssel sind. 

Im Beispiel Hochschulbetrieb 3 ist Dozent_Nr der Primärschlüssel der Relation Dozent. Die 

Attribute Fachbereich/Dekan_Nr sind Nichtschlüsselattribute. Da sie gegenseitig abhängig 

sind (zu einem Fachbereich gehört der entsprechende Dekan) ist die dritte Normalform 

verletzt. Dies ist im Beispiel Hochschulbetrieb 4 korrigiert: es entsteht eine weitere Tabelle 

(Dekan). 

Tabelle 2-10: Beispiel Hochschulbetrieb 4 – 3. Normalform

Vorteil: Wechselt jetzt ein Dozent den Fachbereich oder ändert sich der Dekan in einem 

Fachbereich, so genügt jetzt das Updaten eines einzigen Attributes. 

Mit der Modellierung in 4 Tabellen erreichen wir in diesem Beispiel die Einhaltung aller 3 

Normalformen. 

2.9.3 Beispiel 2 

Nicht normalisierte Tabelle: 

Tabelle 2-11: Beispiel 2 – Nicht normalisierte Tabelle

2.9.3.1 Erste Normalform 

Die erste Normalform beinhaltet nur atomare Feldinhalte. In jedem Feld darf nur ein Wert 

stehen. Überzählige Werte führen zu neuen Zeilen. 

Tabelle 2-12: Beispiel 2 – 1. Normalform 

Vor der zweiten Normalform führen wir den Primärschlüssel ein. In diesem Beispiel handelt 

es sich um einen aus drei Attributen zusammengesetzten Primärschlüssel. 

Primärschlüsselattribute werden unterstrichen dargestellt. Es wäre hier auch möglich 

gewesen, den Primärschlüssel aus anderen Schlüsseln zusammenzusetzen. Es wäre 

möglich statt der Matrikelnummer den Studentennamen und statt der Vorlesungsnummer 

den Vorlesungstitel zu verwenden. Die Möglichkeit wie der Schlüssel gesetzt werden kann, 

wird durch die verwendeten Testdaten bestimmt

2.9.3.2 Zweite Normalform 

Bei der Überführung in die zweite Normalform werden die Nichtschlüsselattribute betrachtet. 

Sie dürfen nur vom Gesamtschlüssel abhängen, nicht von Teilschlüsseln. Dies wird als 

funktionale Abhängigkeit bezeichnet. In unserem Beispiel ist der Student von der 

Matrikelnummer und die Vorlesung von der Vorlesungsnummer abhängig. Beide sind jedoch 

nur vom Teilschlüssel abhängig. Deshalb werden zwei neue Tabellen gebildet. 

Tabelle 2-13: Beispiel 2 – 2. Normalform

2.9.3.3 Dritte Normalform 

In der dritten Normalform darf es keine funktionalen Abhängigkeiten geben zwischen 

Attributen, die nicht zum Schlüssel gehören. Durch geeignete Wahl der Testdaten und des 

Primärschlüssels bei der 1. Normalform befindet sich dieses Beispiel bereits in der dritten 

Normalform. 

2.9.3.4 Redundanzfreiheit 

Die Tabelle oben dargestellte Tabelle weist jedoch immer noch redundante Information auf. 

Es handelt sich um die Verschmelzung zweier einfacherer Relationen. Durch eine 

Normalisierung bis zur 5. Normalform zerfällt diese Tabelle in zwei Tabellen: 

Tabelle 2-14: Beispiel 2 - Redundanzfreiheit 

Es ist nicht erforderlich, dass nur zwei Spalten pro Tabelle übrig bleiben! Dies ergibt sich 

lediglich durch unser einfach gewähltes Beispiel.

3 Modellierung 

Aufgabenstellung: 

Für eine Modellierung wird meist eine Beschreibung der Aufgabe als Ausgangspunkt 

verwendet: 

Für eine Fachhochschule soll ein Verwaltungsprogramm für Professoren, Studenten und 

Vorlesungen erstellt werden. Professoren besitzen einen Namen. Studenten besitzen einen 

Namen und eine Matrikelnummer. Jede Vorlesung hat ihre eigene Vorlesungsnummer und 

einen Vorlesungstitel. Jeder Student kann mehrere Vorlesungen besuchen. Ein Professor 

kann mehrere Vorlesungen halten. In einer Vorlesung können mehrere Studenten sein. Eine 

Vorlesung kann von mehreren Professoren gehalten werden. 

Je nach Modellierungsart entstehen aus dem Text Entitäten, Relationen oder Objekte. Diese 

enthalten verschiedene Attribute und sind untereinander mit Beziehungen verknüpft. 

Objekt-Darstellungsform: 

Abbildung 2-15: Objekte 

Ein solches Modell lässt sich einfach in relationale Tabellen umwandeln. Die hier 

dargestellten m:n Verknüpfungen müssen aufgelöst werden, indem Zwischentabellen 

(Zwischenrelationen) erzeugt werden. 

Relationale Darstellungsform: 

Jeder Relation wird ein eindeutiger Primärschlüssel hinzugefügt. Die Beziehungen werden 

über Fremdschlüssel aufgelöst. Die Trennung zwischen fachlichen Attributen und 

Beziehungsattributen erleichtert die Arbeit mit den Tabellen. Die Beziehungsattribute sind in 

der unteren Grafik mit Grossbuchstaben abgekürzt. Primärschlüssel sind wieder 

unterstrichen, Fremdschlüsseln folgt das Zeichen ‘#’. 

Abbildung 2-16: Relationale Darstellungsform

Tabellen: 

Mit den Beispieldaten der Normalisierung ergeben sich folgende Tabellen. Es sind in diesem 

Beispiel relationale Tabellen entstanden, die der dritten Normalform genügen. Es ist 

ausserdem leicht ersichtlich, dass diese Tabellen redundanzfrei sind. 

Tabelle 2-15: Tabellen nach Normalisierung

3.1 Vergleich der Methoden 

Nachfolgendes Schema zeigt den Zusammenhang zwischen Modellierung und 

Normalisierung. Bei einer Aufgabenstellung in Form einer nicht normalisierten Tabelle ist nur 

der Schritt der Normalisierung notwendig. Dieser ist jedoch äusserst schwierig. Diese 

Aufgabenstellung kommt in der Praxis auch kaum vor. Weit häufiger hat man zum Beispiel 

nach einer Besprechung eine Aufgabenstellung in textueller Form vorliegen. Bei dieser sind 

bei beiden Wegen zwei Schritte notwendig. Bei der Erstellung einer Tabelle aus einer 

Textaufgabe ergibt sich das Problem die richtigen Testdaten zu finden. Diese sollen 

möglichst alle auftretenden Möglichkeiten abdecken. 

Abbildung 2-17: Modellierung und Normalisierung – Methoden 

3.1.1 Modellierung impliziert Normalisierung 

Mit einer sachgerechten Modellierung kann man sich die schwierige Normalisierung 

ersparen. Die einzelnen Schritte der Normalisierung werden implizit bei der Modellierung 

durchgeführt: 

• Normalform Atomare Werte - Die Attribute der verschiedenen Modellierungsverfahren 

sind per Definition bereits atomar. Es können nicht zwei Werte in einem Attribut 

gespeichert werden. Werte von Attributen sind nicht teilbar. 

• Normalform funktionale Abhängigkeit 

• Normalform transitive Abhängigkeit 

Durch die fachliche Modellierung werden die Attribute den Objekten zugeordnet. Sie sind 

somit stets vom Objekt funktional abhängig. Für alle nicht fachlichen Abhängigkeiten 

zwischen Relationen, die bei der Auflösung von Vererbung, usw. entstehen, gibt es feste 

Umwandlungsregeln.

Über die oben beschriebene dritte Normalform hinaus wird mit einer Modellierung meist eine 

Redundanzfreiheit erreicht, die beim Normalisierungsverfahren erst in der 5. Normalform 

erreicht wird. Die Modellierung mit modernen Verfahren bietet darüber hinaus die Möglichkeit 

komplexere Konstrukte wie Vererbung (Generalisierung -Spezialisierung) und Aggregation 

zu verwenden. Für die Umwandlung eines Modells in konkrete Datenbanktabellen gibt es 

bereits Softwarewerkzeuge. 

3.2 Zusammenfassung 

Im folgenden Bilde werden die ersten drei Normalformen noch einmal zusammengestellt: 

Abbildung 2-18: Darstellung der ersten drei Normalformen 

Werden die Daten von Programmsystemen in Dateien gespeichert, so führt dies in der 

Praxis oft zur redundanten Speicherung der Daten und damit auch zu inkonsistenten 

Datenbeständen. Ein Programm muss die physikalische Speicherung der Daten kennen, 

sowie Routinen für das Lesen, Schreiben, Aktualisieren, Suchen vor allem für das 

Fehlerhandling beinhalten. Was man aber haben will, ist dass Programme unabhängig von 

der physikalischen Speicherung sind (Datenunabhängigkeit der Programme), und dass die 

Routinen für das Lesen, Schreiben, Aktualisieren, Suchen und Fehlerhandling nur einmal 

zentral vorhanden sein müssen. Solche Vorteile werden von 

Datenbankmanagementsystemen geboten. Beim Zugriff auf Datenbanken gibt es interne 

Satzschnittstellen, logische Satzschnittstellen und mengenorientierte Schnittstellen. 

Relationale Datenbanken besitzen eine mengenorientierte Schnittstelle. Relationale 

Datenbanken enthalten Relationen, die in Form von Tabellen dargestellt werden. Die 

Relationen entsprechen den Entitätstypen des Entity-Relationship Modells. Ein Attribut eines 

Entitätstyps entspricht einem Attribut einer Relation und stellt eine Spalte einer Tabelle dar. 

Eine Zeile (Tupel) entspricht einer konkreten Entität des Entitättyps. Die Attribute bestehen 

nur aus einem Wert pro Tupel, nicht aus mehreren Werten. Sie sind „atomar“. Eine 

Zusammenstellung von Attributwerten heisst Candidate-Key, wenn die Werte, die diese 

Attribute annehmen, stets ein Tupel eindeutig identifizieren. Eine Relation kann einen oder 

mehrere Candidate-Keys besitzen. Ein Primary-Key ist ein Candidate-Key, der zum Primary- 

Key erklärt wird oder der als neues Attribut speziell zu diesem Zweck eingeführt wird. 

Fremdschlüssel dienen dazu, um Relationen zu verknüpfen und um die referentielle Integrität 

zu gewährleisten. Durch die referentielle Integrität wird sichergestellt, dass jedem Wert eines 

Foreign-Keys in einer Relation R2 gleich ist einem Wert des Primary-Keys in einer Relation 

R1 oder dass der Wert des Foreign-Keys ein NULLWert ist. Referentielle Integrität bedeutet

z.B., dass wenn ein Mitarbeiter aus dem Datenbestand "Mitarbeiter" verschwindet, er dann 

auch aus dem Datenbestand "Firmenkreditkarte" verschwinden muss. 

Für den Datenbankentwurf müssen nun die Entitätstypen und die Beziehungen zwischen 

Entitätstypen abgebildet werden auf Relationen. Eine 1 zu 1 –Beziehung kann dabei auf 2 

Relationen oder auf 1 Relation abgebildet werden. Im zweiten Fall werden die Entitätstypen 

auf Attribute dieser Relation abgebildet. Eine 1 zu n Beziehung wird auf 2 Relationen 

abgebildet, eine n zu m Beziehung auf 3 Relationen. 

Um Redundanzen zu beseitigen und Update-Anomalien zu vermeiden, werden die 

Relationen normalisiert. In der Praxis geht man bis zur 3. Normalform. Da die Normalisierung 

aber die Zahl der Tabellen erhöht, gibt es in der Praxis auch Fälle, wo man aus 

Performance-Gründen auch nicht normalisierte Relationen verwendet. Jede Normalform 

enthält implizit die vorhergehende Normalform (die 3. Normalform enthält die 2. und damit 

die 1. Normalform). Eine Relation befindet sich in der ersten Normalform, wenn alle Attribute 

nur atomare Werte enthalten. Eine Relation ist in der 2. Normalform, wenn sie in 1. 

Normalform ist und wenn jedes Nichtschlüsselattribut voll funktional abhängig ist vom 

Primärschlüssel. Felder, die nur von einem Schlüsselteil abhängen, werden separat 

modelliert. Die zweite Normalform kann somit nur verletzt werden, wenn der Primärschlüssel 

aus mehr als einem Attribut zusammengesetzt ist. Eine Relation ist genau dann in der 3. 

Normalform, wenn sie in 1. und 2. Normalform ist und wenn alle Nichtschlüsselattribute 

gegenseitig unabhängig sind, aber voll funktional abhängig vom gesamten Primärschlüssel 

sind. Wenn Attribute gegenseitig abhängig sind, entsteht eine weitere Tabelle. [3] 

4 Quellen 

Nr. Quelle Abbildungen/Text 

[1] Fachhochschule Stralsund – Prof. Dr. Text/Abbildungen 

Uwe Hartmann 

[2] Uni Trier – Michael Ley Text 

[3] Steinbeiss Transferzentrum Text/Abbildungen 

5 Information über Dokument 

Version 1.0 

Letzte Änderung 30. April 2003 

Copyright 

Für Copyrightinformationen bitte 

die Anmerkungen/Fussnoten 

beachten, alles übrige Roland 

Lenz 

Homepage 

http://www.2cool4u.ch/ 

Historie Version Datum 

Dokument erstellt 1.0 30. April 2003

1 Datenmodellierung

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

Template löschen?

Als Template speichern?