Lehrbuch - DieBirne-Verlag
Lehrbuch - DieBirne-Verlag
Lehrbuch - DieBirne-Verlag
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
B 13 Informations- und Datenbankmanagement<br />
<strong>Lehrbuch</strong><br />
Informationsund<br />
Datenbankmanagement<br />
Praxisbeispiele, lehrreiche Abbildungen, Tabellen und ein Glossar<br />
Autor: Thomas Grosser; IT-Projektleiter, Dozent und Lehrmittelautor<br />
Copyright:<br />
Copyright © 2010<br />
<strong>DieBirne</strong> Bildungsmedien AG<br />
Zugerstrasse 47<br />
6312 Steinhausen<br />
www.diebirne.ch<br />
Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der<br />
Übersetzung, vorbehalten. Kein Teil des Werks darf in irgendeiner Form (durch Fotokopie,<br />
Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des<br />
<strong>Verlag</strong>s reproduziert oder unter Verwendung elektronischer Systeme gespeichert,<br />
verarbeitet, vervielfältigt oder verbreitet werden.<br />
3. Auflage 2010<br />
Layout und Satz: <strong>DieBirne</strong>-<strong>Verlag</strong><br />
Druck: Pentagraph, Berlin<br />
ISBN für das Lehrmittel (Lehr- und Übungsbuch): 978-3-905797-27-5<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
1
B 13 Informations- und Datenbankmanagement<br />
<strong>DieBirne</strong>-Bücher<br />
Lehrmittel aus dem <strong>DieBirne</strong>-<strong>Verlag</strong> sind klar strukturiert und verständlich aufgebaut.<br />
Die Kombination von <strong>Lehrbuch</strong> und Übungsbuch ergibt ein methodisch-didaktisches<br />
Konzept, das aufgrund von Beispielen einem starken Praxisbezug entspricht. Im <strong>Lehrbuch</strong><br />
weisen präzis gesetzte Symbole auf weiterführende Informationen hin (Literatur,<br />
Internet-Surf-Tipps, Gesetzestexte usw.). Ein Glossar erleichtert das selbständige<br />
Arbeiten. Das Übungsbuch korrespondiert optimal mit dem <strong>Lehrbuch</strong>. Die zu lösenden<br />
Aufgaben spiegeln den Wissensstand und unterstützen somit den Lernprozess.<br />
Auf diese Weise wird der Lehrstoff nach dem Prinzip «Learning by doing» vermittelt.<br />
Die <strong>DieBirne</strong>-Lehrmittel enthalten prüfungsrelevante Themen, die von erfahrenen<br />
Dozenten zusammengestellt wurden.<br />
Nach konsequenter Arbeit mit dem Buch sollten die Kursteilnehmer in der Lage sein,<br />
den Lehrgang erfolgreich abzuschliessen bzw. das Thema umfassend zu verstehen.<br />
Das <strong>DieBirne</strong>-Lehrmittel kann genutzt werden:<br />
• Als Grundlage für den selbstgesteuerten Lernprozess und vor allem<br />
• in Kombination mit dem Unterricht sowie den Hilfestellungen der Dozenten<br />
www.diebirne.ch<br />
2<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Symbollegende<br />
Praxisbezug<br />
Korrespondenzsignal:<br />
1.) vom <strong>Lehrbuch</strong> zum Übungsbuch<br />
2.) vom Übungsbuch zum <strong>Lehrbuch</strong><br />
Surf-Tipp<br />
Literaturhinweis<br />
Gesetzestext<br />
Definition<br />
Wegweiser nach oben<br />
Wegweiser nach unten<br />
Hinweis<br />
Bitte lächeln!<br />
Formel<br />
Zeit<br />
Primär- und Fremdschlüssel<br />
Alle Bezeichnungen schliessen sowohl die männliche als auch die weibliche Form ein,<br />
auch wenn vornehmlich die männliche Form gebraucht wird. Das kann man schon<br />
daran erkennen, dass der <strong>Verlag</strong> den Namen einer weiblich besetzten Frucht <strong>DieBirne</strong><br />
trägt.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
3
B 13 Informations- und Datenbankmanagement<br />
Inhalt<br />
Abkürzungsverzeichnis 9<br />
Aufbau des <strong>Lehrbuch</strong>s 11<br />
Inhalt und Aufbau dieses <strong>Lehrbuch</strong>s 11<br />
Teil A Grundlagen 12<br />
1 Einführung 13<br />
1.1 Nachrichten 13<br />
1.2 Informationen 13<br />
1.3 Redundanz 14<br />
1.4 Daten 14<br />
1.5 Semantische und syntaktische Fehler 15<br />
1.6 Datenbanksystem, Datenbank und Datenbankmanagementsystem 16<br />
1.6.1 Datenbanksystem (DBS) 16<br />
1.6.2 Datenbank (DB) 16<br />
1.6.3 Datenbankmanagementsystem (DBMS) 17<br />
2 Aufbau eines Datenbanksystems 18<br />
2.1 Aufbau der 3-Ebenen-Architektur 18<br />
2.1.1 Externe Ebene 19<br />
2.1.2 Konzeptionelle Ebene 19<br />
2.1.3 Interne Ebene 19<br />
2.2 Der Nutzen einer 3-Ebenen-Architektur 19<br />
3 Grundlagen der Datenmodellierung 20<br />
3.1 Entität 20<br />
3.2 Entitätsmenge 21<br />
3.2.1 Kernentitätsmenge 21<br />
3.3 Eigenschaft 21<br />
3.4 Domäne 21<br />
3.5 Faktum 22<br />
3.6 Entitätsattribut 22<br />
3.7 Beziehung 22<br />
3.8 Assoziationen 23<br />
3.8.1 Einfache Assoziation (Typ 1) 23<br />
3.8.2 Konditionelle Assoziation (Typ C) 23<br />
3.8.3 Komplexe Assoziation (Typ M) 24<br />
3.8.4 Abbildung/Darstellung 25<br />
3.9 Superentität und Subentität 26<br />
3.9.1 Superentität 26<br />
3.9.2 Subentität 26<br />
Teil B Datenmodellierung 27<br />
4 Einführung in die Datenmodellierung 28<br />
4.1 Relationale Datenbanken 29<br />
4.2 Beziehungen zwischen Entitätsmengen 29<br />
4.2.1 Notationen 30<br />
4.3 Realisierung 31<br />
5 Erstellung einfacher Datenmodelle 32<br />
5.1 ERM (Entity-Relationship-Modell) 32<br />
5.2 ERD (Entity-Relationship-Diagramm) 32<br />
5.3 Das Relationenmodell 33<br />
4<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
5.4 Festlegung der Schlüssel 33<br />
5.4.1 Primärschlüssel 33<br />
5.4.2 Fremdschlüssel 34<br />
5.4.3 Referentielle Integrität 34<br />
5.5 Korrekte Umsetzung der Anforderungen 35<br />
5.5.1 Erstellen eines ERDs 35<br />
5.5.2 Aufbau eines Relationenmodells 36<br />
6 Komplexe Datenmodelle 38<br />
6.1 1:m-Beziehung 38<br />
6.2 Auflösung komplexer Beziehungen 38<br />
6.3 Generalisierung und Spezialisierung 40<br />
6.4 Doppelte Beziehungen 41<br />
6.5 Rekursive Beziehungen 42<br />
6.5.1 Die c-mc-Rekursion 42<br />
6.5.2 Die mc-mc-Rekursion 43<br />
7 Das Normalisieren von Daten 45<br />
7.1 Unnormalisierte Form 45<br />
7.2 Erzeugung einer Normalform (1. Schritt) 46<br />
7.3 Erzeugung einer Normalform (2. Schritt) 46<br />
7.4 Erzeugung einer Normalform (3. Schritt) 48<br />
8 Das Historisieren von Daten 49<br />
8.1 Historisieren von Entitäten 50<br />
8.2 Historisieren von Beziehungen 52<br />
8.2.1 Historisierung einer Beziehung mittels Zwischentabelle 53<br />
8.2.2 Historisierung einer Beziehung ohne Zwischentabelle 53<br />
8.3 Auswirkung der Historisierungsvorgänge auf eine Datenbank 54<br />
Teil C Data-Mapping 55<br />
9 Einführung 56<br />
9.1 Einsatz einer neuen Datenbank 56<br />
9.2 Mappingformen/-arten 57<br />
9.3 Problemfelder 58<br />
9.3.1 Datenstruktur 58<br />
9.3.2 Semantik 58<br />
9.3.3 Datenreinheit 58<br />
9.3.4 Dokumentation 58<br />
9.3.5 Technologie 58<br />
9.3.6 Know How der Mitarbeiter 58<br />
10 Planung des Mappings 59<br />
10.1 Ziel analysieren 59<br />
10.2 Quelle analysieren 60<br />
10.3 Konversionsregeln 60<br />
10.3.1 Überblick über die Konversionsregeln 61<br />
10.3.2 Einsatz von Zwischentabellen 63<br />
10.4 Berechnungen 64<br />
10.5 Nachfragen 64<br />
10.6 Schlüsselvererbung 65<br />
10.6.1 Problematik mit der Schlüsselvererbung 65<br />
10.6.2 Schlüsselverwaltung 66<br />
Teil D Beschaffung von Managementinformationen 68<br />
11 Management-Support-Systeme (MSS) 69<br />
11.1 Operative Systeme 70<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
5
B 13 Informations- und Datenbankmanagement<br />
11.2 Data-Warehouse 70<br />
11.3 Management-Information-System (MIS) 70<br />
11.4 Decision-Support-System (DSS) 70<br />
11.5 Executive-Information-System (EIS) 70<br />
12 Data-Warehouse im Detail 71<br />
12.1 Das Data-Warehouse-System 71<br />
12.1.1 Operative Systeme innerhalb eines Data-Warehouses 72<br />
12.1.2 Mapping innerhalb eines Data-Warehouses 73<br />
12.1.3 Die Data-Warehouse-Datenbank 73<br />
12.1.4 Data-Mart 73<br />
12.1.5 OLAP - OnLine-Analytical-Processing 74<br />
12.1.6 Data-Mining 75<br />
12.1.7 Auswertung 76<br />
12.2 Zur Data-Warehouse-Architektur 78<br />
12.2.1 Ein unternehmenstaugliches Data-Warehouse 78<br />
12.2.2 Mehrschichtiges Data-Warehouse 79<br />
13 Modellierung eines Data-Warehouses 80<br />
13.1 Dimensionen und Fakten 80<br />
13.1.1 Festlegung der Fakten 80<br />
13.1.2 Dimensionen 81<br />
13.2 Mapping von Fakten und Dimensionen 82<br />
13.2.1 Dimensionstabelle «Kunde» 82<br />
13.2.2 Faktentabelle «Verkauf» 83<br />
13.3 Das Star-Schema 84<br />
13.4 Das Snowflake-Schema 85<br />
13.5 Abfragemöglichkeiten in der Praxis 86<br />
Teil E Datensicherung 87<br />
14 Beweggründe für eine professionelle Datensicherung<br />
88<br />
14.1 Gefahrenpotenzial für jede Unternehmung 88<br />
14.2 Bedrohungen im Einzelnen 88<br />
14.2.1 Höhere Gewalt 88<br />
14.2.2 Menschliches Versagen 88<br />
14.2.3 Kriminelle Aktivitäten 88<br />
14.3 Schutzmassnahmen 89<br />
14.3.1 Technische Massnahmen 89<br />
14.3.2 Bautechnische Massnahmen 89<br />
14.3.3 Organisatorische Massnahmen 89<br />
15 Sicherheitsbegriffe 90<br />
15.1 Datenschutz 91<br />
15.2 Sicherheit der Daten 91<br />
15.3 Sicherung der Daten 92<br />
15.4 Backup und Archivierung 92<br />
15.4.1 Backup 92<br />
15.4.2 Archivierung 92<br />
15.4.3 Backup und Archiv im Vergleich 93<br />
15.5 Restore 93<br />
15.6 Disaster Recovery 93<br />
16 Speichermedien 94<br />
16.1 Die magnetischen Speichermedien 94<br />
16.1.1 Disketten 94<br />
16.1.2 ZIP-Disketten 95<br />
16.1.3 Festplatten/Wechselfestplatten 95<br />
16.1.4 Magnetbänder 96<br />
6<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
16.2 Optische Speichermedien 97<br />
16.2.1 CD-Rom 97<br />
16.2.2 DVD 97<br />
16.3 Elektronische Speichermedien 97<br />
16.3.1 Flash-Speicher 97<br />
16.4 Kombinierte Speichermedien 98<br />
16.4.1 Die Magneto-Optical-Disk (MOD) 98<br />
17 Auswahl des richtigen Speichermediums 99<br />
17.1 Das passende Speichermedium für die erforderliche 100<br />
Datenmenge 100<br />
17.2 Dauer des Speichervorgangs 101<br />
17.3 Zeitaufwand für ein Restore 102<br />
17.4 Kosten für die Speichermedien (im Detail) 103<br />
17.5 Wiederherstellung nach einem Technikwechsel 103<br />
17.5.1 Zur Problematik langer Aufbewahrungszeiten 104<br />
17.5.2 Schutz vor Negativauswirkungen des Fortschritts 104<br />
17.6 Haltbarkeit der Daten auf Speichermedien 104<br />
17.7 Erweiterbare und multiple Suchmöglichkeiten 105<br />
18 Datensicherung im Detail 106<br />
18.1 Backuparten 106<br />
18.1.1 Das Einzelplatz-Backup 107<br />
18.1.2 Das automatische Backup 108<br />
18.1.3 Das LAN-Backup 109<br />
18.1.4 Das Storage-Area-Network (SAN) 110<br />
18.1.5 Das Backup über ein Network-Attached-Storage (NAS) 111<br />
18.1.6 Das Backup via Internet 111<br />
18.2 Sicherung grosser Datenmengen 111<br />
18.2.1 Vollständige Datensicherung 111<br />
18.2.2 Differentielle Datensicherung 112<br />
18.2.3 Inkrementelle Datensicherung 112<br />
18.2.4 Unterschied zwischen differentiellen und inkrementellen<br />
Backups 113<br />
18.3 Redundante Sicherungsformen 113<br />
18.3.1 RAID – Redundant Array of Independent Disks 113<br />
18.3.2 RAID-Arten 114<br />
18.4 Störungsfreie Stromversorgung 118<br />
18.4.1 Offline-USV-Anlagen (Mitlaufbetrieb) 119<br />
18.4.2 Online-USV-Anlagen (Dauerbetrieb) 119<br />
Teil F Dokumentenmanagement 120<br />
19 Einführung 121<br />
19.1 Rechtliche Aspekte 121<br />
19.2 Dateigrösse und Platzbedarf 123<br />
19.3 Dokumenten-Management-Systeme (DMS) 123<br />
19.3.1 Scannen 125<br />
19.3.2 Suchergebnis 126<br />
20 Einsatz «papierloser» Systeme 128<br />
20.1 Groupware-Systeme 128<br />
20.2 Workflow-Management-Systeme (WFMS) 128<br />
Teil G Knowledge-Management 131<br />
21 Wissen 132<br />
21.1 Wissen als vernetzte Information 132<br />
21.2 Wissen als Fähigkeit zu beobachten 133<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
7
B 13 Informations- und Datenbankmanagement<br />
21.3 Implizites Wissen 133<br />
21.4 Explizites Wissen 133<br />
21.5 Aufgaben und Ziele des Knowledge-Managements 133<br />
21.6 Wissenstransfer 134<br />
21.6.1 Initiierung 134<br />
21.6.2 Wissensfluss 135<br />
22 Abbildung und Bereitstellung von Wissen 137<br />
22.1 Methoden des Knowledge-Managements 137<br />
22.2 Gruppenorganisationsformen 138<br />
22.3 Netzwerkmodelle und Computer gestützte Anwendungen 139<br />
22.3.1 Wissensbaum 140<br />
22.3.2 Wissenslandkarte 141<br />
22.3.3 Yellow Pages 143<br />
22.3.4 Knowledge-Management-System 143<br />
Ergänzungen 144<br />
23 Datenbanken und Tabellen erstellen 144<br />
23.1 Erstellen einer Datenbank 144<br />
23.2 Tabellen erstellen 145<br />
23.2.1 Attribute festlegen 146<br />
23.2.2 Primärschlüssel festlegen 147<br />
23.3 Beziehung erstellen 148<br />
23.4 Abfragen erstellen 150<br />
23.5 Abfragen mit Kennzahlen ausführen 151<br />
24 Literatur- und Quellenverzeichnis 153<br />
24.1 Literatur und Quellen 153<br />
24.2 Nützliche Links 154<br />
25 Glossar 154<br />
26 Tabellenverzeichnis 162<br />
27 Abbildungsverzeichnis 164<br />
28 Index 166<br />
8<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Abkürzungsverzeichnis<br />
Abk<br />
AIT<br />
bspw.<br />
bzw.<br />
CD<br />
DAT<br />
DB<br />
DBMS<br />
DBS<br />
DCL<br />
DDL<br />
DDS<br />
DML<br />
DMS<br />
DQL<br />
DSS<br />
dt.<br />
DVD<br />
EIS<br />
engl.<br />
ERD<br />
ERM<br />
etc<br />
ETL<br />
GUI<br />
Id -<br />
ICT<br />
IT<br />
ital.<br />
LAN<br />
Begriff<br />
Advanced Intellegent Type<br />
beispielsweise<br />
beziehungsweise<br />
Compact-Disc<br />
Digital-Audio-Tape<br />
Datenbank<br />
Datenbankmanagementsystem<br />
Datenbankensystem<br />
Data-Control-Language<br />
Data-Definition-Language<br />
Data-Dictionary-System<br />
Data-Manipulation-Language<br />
Dokumenten-Management-System<br />
Data-Query-Language<br />
Decision-Support-System<br />
deutsch<br />
Digital-Versatile-Disc<br />
Executive-Information-System<br />
englisch<br />
Entinity-Relationship-Diagramm<br />
Entinity-Relationship-Modell<br />
et cetera<br />
extract, transform, load<br />
Grafical User Interface<br />
wird wegen der Einheitlichkeit ausschliesslich verwendet<br />
(jedoch viele andere möglich: ID, id oder nr.,<br />
Nr. ...)<br />
Informations- und Kommunikationstechnologie<br />
Informationstechnologie<br />
italienisch<br />
Local-Area-Network<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
9
B 13 Informations- und Datenbankmanagement<br />
Abk<br />
MIS<br />
MOD<br />
MSS<br />
NAS<br />
OLA<br />
RAID<br />
SAN<br />
SQL<br />
z.B.<br />
Begriff<br />
Management-Information-System<br />
Magneto-Optical-Disk<br />
Management-Support-System<br />
Network-Attached-Storage<br />
OnLine-Analytical-Processing<br />
Redundant Array of Independent Disks<br />
Storage-Area-Network<br />
Structured-Query-Language<br />
zum Beispiel<br />
10<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Aufbau des <strong>Lehrbuch</strong>s<br />
Grundlagen<br />
Datenmodellierung<br />
Data-Mapping<br />
Beschaffung<br />
von Managementinformationen<br />
Datensicherung<br />
Dokumenten-<br />
Management<br />
Knowledge-<br />
Management<br />
Überblick über Ihre Lernziele<br />
Inhalt und Aufbau dieses <strong>Lehrbuch</strong>s<br />
Die richtigen Informationen entscheiden über den Erfolg oder den Misserfolg eines<br />
Projekts bzw. eines Unternehmens. Die korrekte Erstellung und Analyse von Informationen<br />
ist deshalb als überaus bedeutsame Aufgabe eines Unternehmens zu betrachten.<br />
In diesem <strong>Lehrbuch</strong> erhalten Sie einen kompletten Überblick über die Handhabung<br />
von Informationen. Sie erarbeiten sich darüber hinaus ein Konzept, mit dem Sie<br />
in der Lage sind, sowohl eine Datenbank zu erstellen als auch bestehende Datenbestände<br />
zu mappen. Zusätzlich erfahren Sie, wie Sie Daten mit Hilfe eines Data-Warehouses<br />
analysieren.<br />
Teil A verschafft Ihnen einen Überblick über Fachbegriffe und Grundlagen zum Thema<br />
Datenbanken.<br />
In Teil B erstellen Sie das Konzept für Datenbankmodelle. Ausserdem lernen Sie Ihre<br />
Datenbank zu historisieren.<br />
Teil C konzentriert sich auf die Migration der Daten von einer Datenbank in eine andere.<br />
Sie erwerben die Fähigkeit, Daten zu mappen.<br />
In Teil D erhalten Sie einen Überblick über die unterschiedlichen Techniken der Informationsanalyse.<br />
Zudem machen Sie sich mit der Modellierung eines Data-Warehouses<br />
vertraut.<br />
Teil E beihaltet die Sicherung von Daten. Sie erfahren, wie ein Backup-Konzept umgesetzt<br />
wird und auf welche Kriterien Sie dabei achten müssen.<br />
In Teil F wird Ihnen erläutert, wie ein Dokumenten-Management-System (DMS) in die<br />
Prozessabläufe eines Unternehmens hilfreich integriert werden kann.<br />
Teil G zeigt Ihnen die Vorteile von Knowledge-Management auf. Nach Bearbeitung<br />
des Kapitelkomplexes G wissen Sie, wie Knowledge-Management in einem Unternehmen<br />
gewinnbringend eingesetzt werden kann.<br />
Im Anhang finden Sie ein Glossar sowie ein Stichwort-, Tabellen- und Abbildungsverzeichnis.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
11
B 13 Informations- und Datenbankmanagement<br />
Teil A Grundlagen<br />
Grundlagen<br />
Datenmodellierung<br />
Data-Mapping<br />
Beschaffung<br />
von Managementinformationen<br />
Datensicherung<br />
Dokumenten-<br />
Management<br />
Knowledge-<br />
Management<br />
Lernziele>>Lerneffekt>>Lernerfolg<br />
Da die zu verwendenden Begriffe hinsichtlich Informationen und Datenbanken vom<br />
allgemeinen Sprachgebrauch abweichen, verfolgt dieses Grundlagenkapitel das Ziel,<br />
die wichtigsten Grundbegriffe aus den oben genannten Bereichen zu erklären. Es<br />
werden Ihnen Unterschiede zwischen Schlüsselbegriffen wie Nachrichten, Informationen<br />
und Redundanzen aufgezeigt. Darüber hinaus macht Sie dieser einführende<br />
Kapitelkomplex mit dem Aufbau von Datenbanken vertraut und verdeutlicht Ihnen,<br />
aus welchen Elementen eine Datenbank besteht.<br />
Wir können keine konkreten Angaben über die Zeit machen, die Sie für die erfolgreiche<br />
Bearbeitung der einzelnen Kapitel benötigen. Allerdings werden Sie zu Beginn<br />
jedes Kapitelkomplexes darüber informiert, wie viel Zeit im Lehrgang dafür eingeplant<br />
ist. Es versteht sich von selbst, dass Sie ohne Unterstützung von Dozenten erheblich<br />
mehr Zeit einplanen sollten, falls Sie das Buch gekauft haben, jedoch keinen<br />
Kurs besuchen. Hinzu kommt, dass beinahe jeder Lerner ein anderes Lerntempo hat.<br />
Lernende, die keinen Kurs besuchen, sollten deshalb mehr Zeit einplanen.<br />
Kapitel im Kapitelkomplex<br />
Grundlagen<br />
Veranschlagte Zeit im Kurs in<br />
Minuten<br />
(ohne Aufgaben)<br />
Empfohlene Zeit für die<br />
Arbeit mit dem Buch in<br />
Minuten<br />
(ohne Aufgaben)<br />
1 Einführung mind. 60 60 + x<br />
2 Aufbau eines Datenbank<br />
systems<br />
3 Grundlagen der Datenmodellierung<br />
mind. 60<br />
mind. 60<br />
60 + x<br />
60 + x<br />
Die Zeiten, die Sie für die Erledigung der Übungen benötigen, finden Sie im Übungsbuch.<br />
12<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
1 Einführung<br />
Sie arbeiten bei der GOURMEX AG als ICT-Spezialist. Die GOURMEX AG ist im Lebensmittelhandel<br />
tätig. Seit vielen Jahren nimmt die GOURMEX AG Bestellungen von Privatpersonen<br />
entgegen. Ihr Chef, Herr Müller, möchte nun wissen, wie viele Kunden<br />
die GOURMEX AG vorzuweisen hat. Nach kurzer Auswertungszeit übergeben Sie ihm<br />
bereits die gewünschte Aufstellung in tabellarischer Form. Sie haben die Daten wesentlich<br />
detaillierter aufgegliedert als ursprünglich gefordert war.<br />
Kunden<br />
Anzahl<br />
Damen 600<br />
Herren 700<br />
Total 1300<br />
Tabelle 1: Kundenübersicht<br />
Was findet Herr Müller hier vor? Er hat Informationen angefordert. Doch hat er auch<br />
tatsächlich Informationen erhalten?<br />
1.1 Nachrichten<br />
Herrn Müller wurden in erster Linie Nachrichten übermittelt. Die obige Tabelle mit<br />
der Abonnentenübersicht ist demnach eine Nachricht und keine Information. Alle<br />
Meldungen, die von uns wahrgenommen werden, können somit als Nachrichten bezeichnet<br />
werden.<br />
Wenn Sie also Zeitungen oder ein Buch lesen bzw. Nachrichtensendungen schauen,<br />
erhalten Sie ständig Nachrichten.<br />
1.2 Informationen<br />
Für Herrn Müller müssen Nachrichten einen Neuigkeitswert besitzen, um eine Information<br />
darzustellen. Es sollte demnach etwas sein, was sowohl nützlich als auch umsetzbar<br />
ist. Im konkreten Fall ist die Auskunft über die Anzahl der Kunden (1300) neu.<br />
Zudem wird diese Zahl für die weitere Planung benötigt.<br />
Informationen können daher als zweckbezogene und nützliche Nachrichten bezeichnet<br />
werden, die für einen bestimmten Empfänger einen Neuigkeitswert besitzen.<br />
Nachrichten<br />
Informationen<br />
Kunden<br />
Anzahl<br />
Damen 600<br />
Herren 700<br />
Total 1300<br />
in unserem Beispiel ist dies<br />
die Information<br />
Tabelle 2: Informationen<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
13
B 13 Informations- und Datenbankmanagement<br />
Redundanz<br />
1.3 Redundanz<br />
Die Aufteilung nach Damen und Herren war als Bestandteil der Fragestellung von<br />
Herrn Müller nicht gefordert und ausserdem unerheblich für die weitere Planung.<br />
Dieser Teil der Nachricht kann als Redundanz bezeichnet werden.<br />
Für Herrn Meier, der als Mitarbeiter innerhalb der GOURMEX AG für das Lebensmittelsortiment<br />
zuständig ist, könnte die Aufteilung in Damen und Herren wiederum<br />
einen hohen Informationswert haben.<br />
Redundanz ist der Teil einer Nachricht, der für den Empfänger keinen unmittelbaren<br />
Neuigkeitswert darstellt und somit auch nicht unbedingt nützlich ist.<br />
Grundsätzlich sollte der Anteil an Redundanzen so klein wie möglich gehalten werden,<br />
weil Redundanzen den Informationsempfänger nur unnötig belasten. Unter<br />
Umständen können Redundanzen eine sehr wichtige Rolle spielen. Gehen nämlich<br />
Teile einer Nachricht verloren, kann über eine geschickt aufgebaute Redundanz der<br />
Verlust wieder ausgeglichen werden. Je störanfälliger die Übermittlung ist, desto gezielter<br />
müssen redundante Nachrichtenteile eingebaut werden. Geht bspw. bei der<br />
Übergabe die Gesamtzahl der Daten verloren, können diese durch Addition der Anzahl<br />
Herren und Damen wieder hergestellt werden.<br />
Nachrichten<br />
Neuigkeitswert<br />
nein<br />
ja<br />
Informationen<br />
Redundanz<br />
Abb. 1: Unterschied zwischen Redundanz, Information und Nachricht<br />
Daten<br />
1.4 Daten<br />
Im so genannten digitalen Zeitalter ist es überaus wichtig, Nachrichten und Informationen<br />
auf einem Computer speichern und weiterverarbeiten zu können. Es gibt allerdings<br />
Dinge wie Mimik/Gestik und Gerüche, deren maschinelle Verarbeitung heute<br />
noch an gewisse Grenzen stösst. So unterschiedliche Informationen wie Texte, Bilder,<br />
Musik und Filme können heutzutage in Form von Dateien problemlos auf einem Computer<br />
gespeichert werden. Diese Dateien nennt man auch Daten.<br />
Daten sind also Nachrichten, die maschinell verarbeitet und gespeichert werden können.<br />
14<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Aus dieser Definition ist ersichtlich, dass es sowohl maschinell verarbeitete Informationen<br />
als auch maschinell verarbeitete Redundanzen gibt. Was eine Information und<br />
was eine Redundanz ist, bestimmt der Empfänger. Daten können für einen Empfänger<br />
Informationen und für einen anderen Redundanzen darstellen.<br />
1.5 Semantische und syntaktische Fehler<br />
Jede Datensammlung ist innerhalb kürzester Zeit unbrauchbar, wenn ihre Integrität<br />
bzw. Richtigkeit nicht gewährleistet ist. Was «richtig» ist, muss natürlich zuerst festgelegt<br />
werden. Hierin liegt der logische Ausgangspunkt einer Datenbank und damit<br />
einer konzeptionellen Ebene.<br />
So ist es zum Beispiel technisch möglich, in einer Tabelle die folgenden Werte einzugeben:<br />
Semantische<br />
und syntaktische<br />
Fehler<br />
Nr. Anrede Nachname Vorname Geschlecht<br />
1 Herr Muster Hans weiblich<br />
2 Frau Mutser<br />
Isabelle weiblich<br />
Tabelle 3: Tabelle mit Widersprüchen<br />
semantischer Fehler<br />
syntaktischer Fehler<br />
Haben Sie den Fehler in der ersten Zeile bemerkt? Zwischen den Inhalten der Spalte<br />
Geschlecht («weiblich») und der Spalte Anrede («Herr») besteht ein Widerspruch. Bei<br />
diesem Widerspruch handelt es sich um einen semantischen Fehler. Fehler werden<br />
grundsätzlich nach Semantik und Syntax unterschieden.<br />
Semantik: Semantische Fehler sind Widersprüche in Daten und ergeben damit einen<br />
unlogischen Inhalt.<br />
Auch in die zweite Spalte hat sich ein Fehler eingeschlichen. Haben Sie ihn entdeckt?<br />
In der zweiten Zeile wurde der Nachname «Muster» falsch geschrieben.<br />
Syntax: Bei syntaktischen Fehlern handelt es sich um Schreibfehler in einzelnen Feldern.<br />
Die Datenkonsistenz befasst sich also primär mit semantischen und inhaltlichen Fragen<br />
der Datenbank und kann im Wesentlichen als Widerspruchsfreiheit der Daten<br />
definiert werden.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
15
B 13 Informations- und Datenbankmanagement<br />
Datenbank<br />
1.6 Datenbanksystem, Datenbank und Datenbankmanagementsystem<br />
Bisher tauchte der Begriff Datenbank sehr häufig auf. Doch was genau ist eigentlich<br />
unter einer Datenbank zu verstehen?<br />
In der GOURMEX AG werden die persönlichen Adressen der Kunden noch handschriftlich<br />
notiert. Innerhalb der letzten Jahre sind immer mehr Adressen hinzugekommen.<br />
Zu einigen Kunden unterhält die GOURMEX AG gar keine Geschäftsbeziehungen<br />
mehr. Um den Überblick nicht zu verlieren, möchten Sie nun dazu übergehen, diese<br />
Adressen elektronisch zu verwalten.<br />
Um dies technisch umzusetzen, benötigen Sie ein Datenbanksystem. In einem Datenbanksystem<br />
(DBS) werden die Daten in einer Datenbank (DB) aufbewahrt, die ausschliesslich<br />
vom Datenbankmanagementsystem (DBMS) verwaltet werden.<br />
Abb. 2: Datenbanksystem, Datenbank und Datenbankmanagementsystem<br />
1.6.1 Datenbanksystem (DBS)<br />
Ein Datenbanksystem (DBS) besteht aus der Datenbank (DB) und einem Datenbankmanagementsystem<br />
(DBMS). In einem Datenbanksystem können Daten in einer Datenbank<br />
erstellt, mutiert und gelöscht werden. Für die Ausführung dieser Vorgänge<br />
ist das Datenbankmanagementsystem (DBMS) zuständig.<br />
1.6.2 Datenbank (DB)<br />
Die Datenbank ist der eigentliche Aufbewahrungsort für die Daten. Es handelt sich<br />
um eine Art Topf, der mit Daten gefüllt wird. Bezogen auf ein Adressbuch sind hier<br />
die einzelnen Seiten mit den Adressangaben anzuführen. Datenbanken werden individuell<br />
auf die Bedürfnisse der Benutzer und deren Informationsbedarf abgestimmt.<br />
Eine Bank verwaltet in einer Datenbank die Angaben ihrer Kunden und deren Konti.<br />
Ein Telekommunikationsanbieter ist mit Hilfe einer solchen Datenbank in der Lage,<br />
die einzelnen Telefongespräche zu speichern.<br />
16<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
1.6.3 Datenbankmanagementsystem (DBMS)<br />
Daten in einer Datenbank (DB) haben für die Benutzer nur einen Wert, wenn sie damit<br />
arbeiten können. Das Datenbankmanagementsystem (DBMS) bildet die Schnittstelle<br />
zwischen den Benutzern und der Datenbank (DB). Es gewährt einen effizienten<br />
Zugriff auf die Daten und sorgt dabei für eine zentrale Steuerung und Kontrolle.<br />
Ausserdem wird durch das DBMS ein Schutz vor Hard- und Softwarefehlern gewährleistet,<br />
so dass beispielsweise bei Programm- oder Systemabstürzen die Daten nicht<br />
verloren gehen bzw. wiederhergestellt werden können.<br />
Viele DBMS arbeiten mit der Norm-Datenbanksprache Structured Query Language<br />
(SQL). Mit Hilfe von SQL können Daten erstellt, verwaltet, gelöscht und sogar geschützt<br />
werden. Folglich kann SQL auch ein Bestandteil eines DBMS sein. SQL besteht<br />
aus verschiedenen Sprachschichten.<br />
Sprachschicht<br />
Data-Control-<br />
Language (DCL)<br />
Data-Definition-<br />
Language (DDL)<br />
Data-Manipulation-<br />
Language (DML)<br />
Data-Query-<br />
Language (DQL)<br />
Beschreibung<br />
Die Sprachschicht Data-Control-Language (DCL) stellt Funktionen<br />
zur Verfügung, mit denen die Daten geschützt werden können. So<br />
lassen sich bspw. Benutzerrechte verwalten.<br />
Mit DDL-Befehlen kann man auf einer Datenbank Datenstrukturen<br />
neu definieren, ändern oder löschen.<br />
Hiermit kann man Daten in der Datenbank manipulieren. Das<br />
schliesst Vorgänge wie das Einfügen, Verändern und Löschen ein.<br />
Data-Query-Language (DQL) ermöglicht es, SQL-Auswertungen<br />
durchzuführen.<br />
Tabelle 4: Übersicht Sprachschichten<br />
Selbst ein Adressbuch verfügt über ein Datenbankmanagementsystem. Durch alphabetische<br />
Laschen können Inhalte bspw. schneller gefunden werden.<br />
Aufgabe 1<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
17
B 13 Informations- und Datenbankmanagement<br />
Datenbank<br />
Um einen solchen Computerwechsel ohne grossen Aufwand zu gewährleisten, wurde<br />
von ANSI (1975) eine 3-Ebenen-Architektur für Datenbankmanagementsysteme konzipiert.<br />
3-Ebenen-<br />
Architektur<br />
2 Aufbau eines Datenbanksystems<br />
Im vorherigen Kapitel haben Sie sich mit den Bestandteilen eines Datenbanksystems,<br />
der Datenbank und dem Datenbankmanagementsystem vertraut gemacht. Dies diente<br />
vor allem dazu, Sie auf die künftige Arbeit mit vorhandenen Daten sowie der Erfassung<br />
neuer Daten vorzubereiten. Ihre Datenbank (DB) ist vom Datenbankmanagementsystem<br />
(DBMS) abhängig. Wie gehen Sie nun in folgendem Fall vor? Aufgrund<br />
eines Computerwechsels ist auf dem Gerät ein anderes DBMS installiert worden. Können<br />
Sie Ihre «alte» Datenbank überhaupt noch nutzen?<br />
2.1 Aufbau der 3-Ebenen-Architektur<br />
Logische<br />
Datenstruktur<br />
Externe<br />
Sicht 1<br />
Externe<br />
Sicht 2<br />
Externe<br />
Sicht 3<br />
- Sicht der Benutzer/Benutzergruppen<br />
auf die Daten<br />
Externe Ebene<br />
Entity-<br />
Relationship-<br />
Modelling<br />
Relational<br />
Relationship<br />
Datadictionary<br />
Konzeptionelle<br />
Datenstruktur<br />
- Beschreibung der Gesamtheit<br />
aller Daten<br />
Konzeptionelle Ebene<br />
Hierarchische Ebene<br />
Netzwerk-Ebene<br />
Relationale Ebene<br />
DB-Manager<br />
Physische<br />
Datenstrukturen<br />
- Informationen über Art<br />
und Aufbau der Datenstrukturen<br />
- Zugriffsmechanismen,<br />
Indizes<br />
Interne Ebene<br />
Abb. 3: 3-Ebenen-Architektur<br />
18<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
2.1.1 Externe Ebene<br />
Bei der externen Ebene wird die Perspektive der Benutzer berücksichtigt. Der Benutzer<br />
sieht in seiner Anwendung keine Datenbank, sondern lediglich eine Maske (GUI),<br />
in welcher die Datenbankinhalte in Form von Ein- bzw. Ausgabefeldern angezeigt<br />
werden.<br />
2.1.2 Konzeptionelle Ebene<br />
In der konzeptionellen Ebene ist das konzeptionelle Datenmodell enthalten. Dieses<br />
Konzept schliesst die Eigenschaften der Tabellen sowie deren Daten und Beziehungen<br />
ein.<br />
2.1.3 Interne Ebene<br />
Die interne Ebene beschreibt, wie die Daten auf den externen Speichermedien zu<br />
speichern sind. Hier wird festgehalten, wie die Einteilung in physische Records (Blöcke),<br />
die Bildung von Indizes und das Verhalten im Recovery-Fall gestaltet wird.<br />
Aufgabe 2 a<br />
2.2 Der Nutzen einer 3-Ebenen-Architektur<br />
Die Gültigkeit der einzelnen Ebenen variiert stark. Der Benutzer ändert fast täglich<br />
seine Meinung bzw. entwickelt neue Bedürfnisse an seine Masken. Die durchschnittliche<br />
Lebensdauer der Technik (interne Ebene) liegt bei ca. 3 Jahren, während die konzeptionelle<br />
Sicht der Daten oft 15 Jahre und länger bestehen bleibt.<br />
Externe<br />
Ebene<br />
kurzfristig<br />
Interne Ebene<br />
ca. 3 Jahre<br />
Konzeptionelle Ebene<br />
15 Jahre und länger<br />
Abb. 4: Gültigkeit der Ebenen<br />
Der grosse Vorteil der 3-Ebenen-Architektur besteht in der individuellen und unabhängigen<br />
Anpassung der drei Ebenen. Somit ist der Benutzer flexibler hinsichtlich<br />
jeglicher Änderungen. Er kann zum Beispiel das Datenbankprogramm (bspw. von MS<br />
Access auf Oracle) von der internen Ebene austauschen, ohne die konzeptionelle bzw.<br />
externe Ebene zu ändern.<br />
Der Fokus dieses <strong>Lehrbuch</strong>s liegt überwiegend auf der Betrachtung der konzeptionellen<br />
Ebene.<br />
Ebene wird innerhalb dieses <strong>Lehrbuch</strong>ss mit dem Begriff Schema gleichgesetzt.<br />
Aufgaben<br />
2 b, c<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
19
B 13 Informations- und Datenbankmanagement<br />
3 Grundlagen der Datenmodellierung<br />
Eine Datenbank besteht aus vielen kleinen Teilen, welche auch Konstruktionselemente<br />
genannt werden. Nachfolgend erhalten Sie einen Überblick über diese Konstruktionselemente.<br />
In der Fachsprache existieren für jedes Konstruktionselement verschiedene<br />
Ausdrücke, die unter Umständen verwirrend sein können.<br />
Begriffsüberblick<br />
Begriff<br />
Synonyme<br />
Entität: Datensatz, Record, Row (Zeile), Tuple (Tupel) <br />
Entitätsmenge: Tabelle, Relation <br />
Attribut: Spalte, Kolonne <br />
Aufgaben<br />
3 a, b<br />
Eigenschaft: Feld, Zelle <br />
Domäne:<br />
Wertebereich<br />
Kunde <br />
Kundennummer<br />
Name<br />
33 Kuhn<br />
44 Schmid<br />
55 von Rohr <br />
<br />
Abb. 5: Begriffsüberblick Konstruktionselemente<br />
Entität<br />
3.1 Entität<br />
Eine Entität ist ein individuelles und identifizierbares Exemplar einer Sache, einer<br />
Person oder eines Begriffs aus der realen oder der gedachten Welt, das abgebildet<br />
werden soll.<br />
Eine Entität kann demnach für fast alles stehen, wie bspw. für einen einzelnen Kunden,<br />
ein Auto, einen Vergütungsauftrag, aber auch einen bestimmten Bestellvorgang<br />
innerhalb eines Unternehmens. Wichtige Eigenschaften der Entität sind Individualität<br />
und Identifizierbarkeit.<br />
In einer Tabelle werden die Entitäten waagerecht dargestellt. Eine Entität kann bspw.<br />
die kompletten Kundeninformationen bestehend aus Kundennummer, Vorname,<br />
Nachname, Strasse etc. eines bestimmten Kunden enthalten. Eine Entität wird somit<br />
auch als Einheit bezeichnet, für die Informationen gesammelt werden. Für Sie als<br />
Einsteiger dürfte es anfänglich ziemlich verwirrend sein, dass für Entität eine ganze<br />
Reihe Synonyme wie Datensatz, Record (dt. Datensatz), Row (dt. Zeile) oder Tuple (dt.<br />
das Tupel: Begriff aus der Mathematik steht innerhalb der Informatik ebenfalls für<br />
Datensatz) existieren.<br />
Die GOURMEX AG verfügt über einen grossen Kundenstamm. Dabei stellt der individuelle<br />
Kunde «Kuhn», der durch die Kundennummer 33 identifizierbar ist, eine Entität<br />
dar.<br />
20<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
3.2 Entitätsmenge<br />
Bei einer Entität handelt es sich um einen Einzelfall. Im Hinblick auf die Modellierung<br />
von Daten besteht die Option, diese Einzelfälle, die gleichartige Eigenschaften aufweisen,<br />
in einer bestimmten Menge zusammenzufassen.<br />
Eine Ansammlung von Entitäten des gleichen Typs wird daher als Entitätsmenge bezeichnet.<br />
Dementsprechend lässt sich bei der GOURMEX AG aus mehreren Entitäten «Kunden»<br />
die Entitätsmenge «Kunde» zusammenfassen. Dies entspricht der Tabelle «Kunde».<br />
Entitätsmenge<br />
3.2.1 Kernentitätsmenge<br />
Eine Entitätsmenge ist eine Kernentitätsmenge, wenn es möglich ist, Entitäten hinzuzufügen,<br />
ohne dass auf andere Entitätsmengen geachtet werden muss. Demzufolge<br />
darf die Entitätsmenge kein Fremdschlüsselattribut enthalten.<br />
3.3 Eigenschaft<br />
Der Schnittpunkt zwischen einer Zeile und einer Spalte wird Eigenschaft, Feld oder<br />
Zelle genannt. In einem Feld werden Werte eingegeben wie bspw. der Name eines<br />
Kunden.<br />
Eine Eigenschaft wird Entitäten zugeordnet und ermöglicht deren Identifizierung<br />
und Charakterisierung. Den Wert einer bestimmten Eigenschaft nennt man Eigenschaftswert.<br />
Bezogen auf unser GOURMEX-Beispiel könnte als Eigenschaft der Bestellung, die Herr<br />
Meier vorgenommen hat, die Anzahl der bisher bestellten Caterings angeführt werden.<br />
3.4 Domäne<br />
Oftmals dürfen Felder nur bestimmte Werte annehmen. Hierfür wird dem Benutzer<br />
ein Wertebereich vorgegeben, der in der Fachsprache als Domäne bezeichnet wird. So<br />
kann zum Beispiel im Feld Anrede lediglich zwischen «Herr» und «Frau» ausgewählt<br />
werden.<br />
Eine Domäne stellt eine eindeutig benannte Zusammenstellung der zulässigen Eigenschaftswerte<br />
einer Eigenschaft dar (Wertebereich).<br />
Für ein Luxus-Catering, wie es der Kunde Meier bei der GOURMEX AG bestellt hat,<br />
könnten ebenfalls Domänen eingerichtet werden, die die Mengen bzw. die Preise für<br />
Lebensmittel eingrenzen.<br />
Eigenschaft<br />
Domäne<br />
Entitätsmenge Eigenschaft Domäne<br />
Brote Gewicht 500-750 g<br />
Weine Flaschenpreis 50-150 CHF<br />
Hummer Stückpreis 75-100 CHF<br />
Tabelle 5: Domäne<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
21
B 13 Informations- und Datenbankmanagement<br />
Faktum<br />
3.5 Faktum<br />
Ein Faktum ist eine Behauptung, der zufolge eine Entität für eine Eigenschaft einen<br />
bestimmten Eigenschaftswert aufweist. Ein Eigenschaftswert kann dabei mehreren<br />
Entitäten zugeordnet werden.<br />
Das Gewicht eines Klein-Brotes (250 g) könnte dem eines Hummers aus dem Luxus-<br />
Catering gleichen. Damit weisen beide Fakten den gleichen Eigenschaftswert auf, obwohl<br />
sie unterschiedlichen Entitäten/Entitätsmengen zuzuordnen sind.<br />
Entitätsattribut<br />
3.6 Entitätsattribut<br />
Die senkrecht untereinander stehenden Zellen in einer Tabelle werden Attribute genannt.<br />
Begriffe wie Spalten oder Kolonnen (engl. column) sind mit dem Begriff Attribut<br />
gleichzusetzen.<br />
Eine Entität kann aus vielen unterschiedlichen Informationen bestehen. Die Entität<br />
«Kunde» lässt sich bspw. in Vorname, Nachname und Adressinformationen unterteilen.<br />
Die Entität Kunde «Kuhn», der bei der GOURMEX AG unter der Kundennummer<br />
33 abgelegt ist, weist bspw. folgende Attribute auf:<br />
Vorname Nachname Adresse<br />
Hans Kuhn Hauptgasse 7, 4500 Solothurn<br />
Tabelle 6: Entitätsattribut<br />
Ein Entitätsattribut ist eine Auswahl von Fakten, die aufgrund von Eigenschaftswerten<br />
aus einer bestimmten Domäne zu den Entitäten einer Entitätsmenge zustande<br />
kommen. In Excel wäre ein Entitätsattribut eine Spalte.<br />
Beziehung<br />
3.7 Beziehung<br />
Eine Beziehung verbindet wechselseitig zwei (möglicherweise auch mehrere) Entitäten.<br />
Die Form der Beziehung wird in der Praxis leider allzu oft ungenau beschrieben. Meist<br />
findet man lediglich die Bezeichnung «hat» in den Entity-Relationship-Modellen. Die<br />
genaue Beschreibung der Beziehung ist aber sehr wichtig und hat Einfluss auf die<br />
Prozesse. Daher wollen wir mit einem Positivbeispiel vorangehen und betrachten wiederum<br />
die oben erwähnten Entitäten.<br />
Enität 1:<br />
Kunde Meier<br />
ist Besteller von<br />
gehört zu<br />
Enität 2:<br />
Bestellung Luxus-<br />
Catering<br />
Abb. 6: Beziehung<br />
Der Kunde Meier hat das Luxus-Catering gebucht und ist damit Besteller. Die Bestellung<br />
des Luxus-Caterings gehört dann wiederum zum Kunden Meier, der diese bei der<br />
GOURMEX AG aufgegeben hat.<br />
22<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
3.8 Assoziationen<br />
Die Elemente einer Entitätsmenge stehen, wie oben bereits erläutert, in einer ganz<br />
bestimmten Beziehung zu den Elementen einer anderen Entitätsmenge. Die einseitige<br />
Beziehung zwischen diesen Elementen wird Assoziation genannt. Daher besteht<br />
die wechselseitige Beziehung von A zu B und von B zu A aus zwei Assoziationen. Hierbei<br />
werden einfache, konditionelle und komplexe Assoziationstypen unterschieden.<br />
Assoziationen<br />
3.8.1 Einfache Assoziation (Typ 1)<br />
Bei der einfachen Assoziation hat jedes Element der Entitätsmenge A jederzeit mit<br />
nur einem Element der Entitätsmenge B eine Beziehung.<br />
Man könnte die Art der Beziehung auch wie folgt beschreiben: «Die Menge B ist von<br />
der Menge A funktional abhängig.» Jedes Element der Entitätsmenge A ist über eine<br />
Beziehung mit einem Element der Entitätsmenge B verknüpft. Allerdings ist hier vor<br />
allem zu beachten, dass es auf die Perspektive, aus der man die Beziehungen betrachtet,<br />
ankommt. Je nach Betrachtungsweise können die Verbindungen zwischen Entitätsmengen<br />
variieren, da die Entitätsmenge A zur Entitätsmenge B nicht die gleiche<br />
Beziehung aufweist. Dies gilt auch in umgekehrter Richtung.<br />
Entitätsmenge A Beziehung Entitätsmenge B<br />
Kunde a 1 hat ein Geburtsdatum b 4<br />
Tabelle 7: Einfache Assoziation<br />
Die Menge aller Entitäten Kunden a 1 - a 4 unterhält eine einfache Beziehung zur<br />
Menge Geburtsdatum, weil jedes Element der Menge A genau mit einem Element der<br />
Menge B unter der Bedingung «hat» verknüpft ist.<br />
b 1<br />
b 2<br />
a 1<br />
a 2<br />
b 4<br />
b 3<br />
b 6<br />
a 4<br />
a 3<br />
b 5<br />
Kunden a 1 - a 4<br />
Abb. 7: Einfache Assoziation<br />
Geburtsdatum<br />
Also hat der Kunde a 1 an einem bestimmten Tag im Jahr Geburtstag b 4, an welchem<br />
auch andere Kunden Geburtstag haben können.<br />
3.8.2 Konditionelle Assoziation (Typ C)<br />
Bei der konditionellen Assoziation steht ein Element der Entitätsmenge A höchstens<br />
zu einem (möglicherweise auch zu keinem) Element der Entitätsmenge B in Beziehung.<br />
Die Elemente a 1, a 3 und a 4 in der folgenden Abbildung haben genau zu einem<br />
Element der Menge B eine Beziehung. Zwischen dem Element a 2 der Menge A und<br />
der Menge B besteht keine Beziehung. Für die konzeptionelle Assoziation gilt es hinsichtlich<br />
der Perspektive des jeweiligen Nutzers bzw. Entwicklers wiederum darauf zu<br />
achten, dass sich die Beziehungen unterscheiden.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
23
B 13 Informations- und Datenbankmanagement<br />
Entitätsmenge A Beziehung Entitätsmenge B<br />
Kunde a 1 hat eine Faxnummer b 1<br />
Tabelle 8: Konditionelle Assoziation<br />
a 2<br />
a 1<br />
a 4<br />
a 3<br />
b 1<br />
b 2<br />
b 5<br />
b 3<br />
b 4<br />
b 6<br />
Kunden a 1 - a 4<br />
Faxnummer<br />
Abb. 8: Konditionelle Assoziation<br />
In unserem Beispiel hat der Kunde a 1 die Faxnummer b 1.<br />
3.8.3 Komplexe Assoziation (Typ M)<br />
Bei der komplexen Assoziation hat jedes Element der Entitätsmenge A jederzeit zu<br />
beliebig vielen (d.h. einem und mehr) Elementen der Entitätsmenge B eine Beziehung.<br />
Jedes Element der Entitätsmenge A weist mindestens zu einem Element der<br />
Menge B eine Beziehung auf. Zudem ergibt sich aus der umgekehrten Beziehung<br />
nicht dieselbe Beziehung der Menge B zur Menge A.<br />
Entitätsmenge A Beziehung Entitätsmenge B<br />
Kunde a 1 hat mehrfach bestellt Luxus-Catering b 1<br />
Tabelle 9: Komplexe Assoziation<br />
a 1<br />
b 1 b 2<br />
a 3<br />
a 2<br />
a 4<br />
b 5<br />
b 3<br />
b 4<br />
b 6<br />
Kunden a 1 - a 4<br />
Luxus-Caterings<br />
Abb. 9: Komplexe Assoziation<br />
Aus der obigeb Abbildung sowie oben stehender Tabelle ergibt sich, dass der Kunde<br />
a 1 bisher zweimal das Luxus-Catering b 1 gebucht hat.<br />
24<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
3.8.4 Abbildung/Darstellung<br />
Bei der Erstellung von Datenbanken kommt es nicht nur darauf an, die Beziehung<br />
von einer Menge A zu einer Menge B darzustellen, sondern auch die gegenseitige<br />
Beziehung auszudrücken. Eine Abbildung, die die Mengen A und B betrifft, besteht<br />
aus einer Assoziation der Menge A zur Menge B plus den dazu inversen Assoziationen<br />
und wird als Beziehung definiert.<br />
Die folgende Tabelle bildet den formalen Zusammenhang von Assoziation und Beziehung<br />
ab. .<br />
Assoziation M C 1<br />
M M : M M : C M : 1<br />
C C : M C : C C : 1<br />
1 1 : M 1 : C 1 : 1<br />
Tabelle 10: Übersicht über die Abbildungen<br />
Die grau, schwarz bzw. orange markierten Beziehungen in der obigen Tabelle sind reziprok,<br />
so dass sechs Beziehungstypen unterschieden werden können. Zusätzlich wird<br />
jedoch noch die komplex-konditionelle Beziehung unterschieden. Für die Darstellung<br />
von 0–n-Beziehungen muss daher das Zeichen MC verwendet werden.<br />
Die in der vorherigen Tabelle gezeigte Übersicht wird sowohl um eine Zeile als auch<br />
eine Spalte (vgl. Tabelle 4) ergänzt.<br />
Assoziation 1 C M MC<br />
1 1 - 1 1 - C 1 - M 1 - MC<br />
C C - 1 C - C C - M C - MC<br />
M M - 1 M - C M - M M - MC<br />
MC MC - 1 MC - C MC - M MC - MC<br />
Tabelle 11: Übersicht über die Abbildungen inklusive MC<br />
Legende:<br />
hierarchische Beziehung<br />
konditionelle Beziehung<br />
netzwerkförmige Beziehung<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
25
B 13 Informations- und Datenbankmanagement<br />
Superentität<br />
und Subentität<br />
3.9 Superentität und Subentität<br />
Daten, die bspw. zu einer Person gehören, können zwei bzw. mehreren Entitätsmengen<br />
zugeordnet werden. Das führt zu Überlappung innerhalb bestimmter Bereiche.<br />
3.9.1 Superentität<br />
Die Daten, die sich überlagern, werden mittels Superentität vereinfacht und komprimiert<br />
dargestellt. Daher bezeichnet man das Definieren einer Superentität als Generalisierung.<br />
Die Superentitätsmenge beinhaltet mindestens zwei Entitätsmengen sowie die<br />
Schnittmenge, in der sich die Entitätsmengen überlagern.<br />
Abb. 10: Entitäts- und Superentitätsmenge<br />
Unter der oben stehenden Abbildung könnten Sie als Mitarbeiter der GOURMEX AG<br />
dargestellt sein, der gelegentlich die Dienstleistungen des eigenen Unternehmens in<br />
Anspruch nimmt und beispielsweise für die Hochzeit seiner Kinder ein Luxus-Catering<br />
bestellt.<br />
3.9.2 Subentität<br />
Die Subentitätsmenge umfasst eine einzelne Entitätsmenge sowie die Menge, in der<br />
sie sich mit der anderen Entitätsmenge überschneidet.<br />
Der Kunde Meier ist ausschliesslich als Kunde der GOURMEX AG in Erscheinung getreten.<br />
Somit kann er lediglich in der Entitätsmenge «Kunde» erfasst sein.<br />
26<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Teil B<br />
Datenmodellierung<br />
Grundlagen<br />
Datenmodellierung<br />
Data-Mapping<br />
Beschaffung<br />
von Managementinformationen<br />
Datensicherung<br />
Dokumenten-<br />
Management<br />
Knowledge-<br />
Management<br />
Lernziele>>Lerneffekt>>Lernerfolg<br />
Nachdem Sie nun die grundlegenden Begriffe zum Thema Datenbanken kennen und<br />
deren Bedeutung und Funktion verstehen, gehen wir zur konzeptionellen Ebene über.<br />
Ein Lernziel dieses Kapitels besteht darin, eine relationale Datenbank zu modellieren.<br />
Sie sollen darüber hinaus die Fähigkeit erlangen, bestimmte Anforderungen bzw. bestehende<br />
Datentabellen entsprechend ihren Beziehungen untereinander zu definieren.<br />
Zusätzlich lernen Sie, eine Datenbank so aufzubauen, dass Informationen historisiert<br />
werden können.<br />
Wir können keine konkreten Angaben über die Zeit, die Sie für die erfolgreiche Bearbeitung<br />
der einzelnen Kapitel benötigen, machen. Allerdings werden Sie zu Beginn<br />
jedes Kapitelkomplexes darüber informiert, wie viel Zeit im Lehrgang dafür eingeplant<br />
wird. Es versteht sich von selbst, dass Sie ohne Unterstützung von Dozenten erheblich<br />
mehr Zeit einplanen sollten, falls Sie das Buch gekauft haben, jedoch keinen<br />
Kurs dazu besuchen. Hinzu kommt, dass beinahe jeder Lerner ein anderes Lerntempo<br />
aufweist. Lernende, die keinen Kurs zu dem Buch besuchen, sollten ein noch grösseres<br />
Zeitfenster einplanen.<br />
Kapitel im Kapitelkomplex<br />
Datenmodellierung<br />
4 Einführung in die<br />
Datenmodellierung<br />
5 Erstellen einfacher Datenmodelle<br />
6 Komplexe<br />
Datenmodelle<br />
7 Normalisieren von<br />
Daten<br />
Veranschlagte Zeit im Kurs in<br />
Minuten<br />
(ohne Aufgaben)<br />
mind. 60<br />
mind. 90<br />
mind. 120<br />
mind. 60<br />
Empfohlene Zeit für die<br />
Arbeit mit dem Buch in<br />
Minuten (ohne Aufgaben)<br />
60 + x<br />
90 + x<br />
120 + x<br />
60 + x<br />
8 Historisieren mind. 120 120 + x<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
27
B 13 Informations- und Datenbankmanagement<br />
Datenmodellierung<br />
4 Einführung in die Datenmodellierung<br />
Die Kunden der GOURMEX AG wurden bisher noch elektronisch in MS Access verwaltet.<br />
Herr Müller bittet Sie um eine aktuelle Aufstellung aller Kunden, die eine Unterteilung<br />
nach Anrede in «Frau» und «Herr» beinhaltet. Mit wenigen Klicks führen<br />
Sie die Abfrage aus. Sie erwarten lediglich zwei Zeilen mit der Anrede «Herr» oder<br />
«Frau» sowie deren Anzahl. Doch was ist das?<br />
Abb. 11: Abfrageergebnis<br />
Wie kommt ein derartiges Ergebnis zustande? Die von Ihnen getätigte Abfrage war<br />
korrekt. Das Problem in dieser Datenbank besteht darin, dass im Lauf der Zeit viele<br />
verschiedene Anredeformen manuell eingegeben wurden. Die Abfrage im Programm<br />
erkennt zwischen Herr, Hr. oder Herrn keine Beziehung und fasst diese Werte daher<br />
nicht zusammen.<br />
Auch das noch! Wie sollen Sie aussagekräftige Auswertungen erstellen, wenn die Inhalte<br />
der Tabelle nicht korrekt sind?<br />
Auch wenn die Bereinigung dieser wenigen Inhalte schnell durchgeführt ist, dürften<br />
Sie nicht sonderlich motiviert sein, falsche Dateninhalte auch zukünftig immer wieder<br />
berichtigen zu müssen.<br />
Sie schlagen deshalb eine Eingabemaske vor, bei der Ihre Arbeitskollegen lediglich in<br />
einem Pulldownmenü die entsprechende Anrede auswählen können. Dadurch kann<br />
ein Wert nur noch mittels Auswahl und nicht mehr manuell eingegeben werden.<br />
Abb. 12: Pulldownmenü<br />
Da diese Umstellung arbeitsintensiv ist, sollte diese Gelegenheit genutzt werden, um<br />
auch die komplette Adressentabelle neu zu entwickeln sowie relational aufzubauen.<br />
28<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
4.1 Relationale Datenbanken<br />
Unter einer relationalen Datenbank wird die Organisation einer Datenbank nach dem<br />
relationalen Modell verstanden. Die Informationen sind in verschiedenen Tabellen<br />
gespeichert und können flexibel den aktuellen Bedürfnissen entsprechend verknüpft<br />
werden.<br />
Dies hat zwei Vorteile:<br />
1. Falscheingaben kommen seltener vor, da nur Werte ausgewählt werden können,<br />
die in der verknüpften Tabelle enthalten sind (referentielle Integrität).<br />
2. Da lediglich die Primärschlüssel in der verknüpften Tabelle gespeichert sind, können<br />
redundante Daten vermindert werden. Das verringert wiederum den benötigten<br />
Speicherplatz.<br />
In relationalen Datenbanken werden die Daten in verschiedene Tabellen aufgeteilt<br />
und über Beziehungen miteinander verknüpft. Der Benutzer nimmt diese Aufteilung<br />
nicht wahr.<br />
Im GUI (Externe Ebene) der GOURMEX AG verfügt der Benutzer über die Möglichkeit,<br />
einen Kunden auf einer Maske zu verwalten. Sobald Sie als Benutzer eine Anrede auswählen,<br />
treten diese Informationen aus der Entitätsmenge «Anrede» und die übrigen<br />
Felder aus der Entitätsmenge «Kunde» hervor.<br />
Relationale<br />
Datenbanken<br />
Entitätsmenge<br />
Anrede<br />
Abb. 13: GUI und Datenherkunft<br />
Entitätsmenge<br />
Kunde<br />
4.2 Beziehungen zwischen Entitätsmengen<br />
Damit die oben stehende Maske funktioniert, müssen die aufgeteilten Entitätsmengen<br />
in einer Beziehung zueinander stehen. Die Beziehung ist wechselseitig. Das bedeutet,<br />
dass beide Entitätsmengen eine wechselseitige Beziehung aufbauen. In unserem<br />
Beispiel hat die Entitätsmenge «Kunde» eine Anrede. Diese Anrede gehört dann<br />
wiederum zu einem bestimmten Kunden. Zur Darstellung von relationalen Datenbanken<br />
eignet sich das Entity-Relationship-Diagramm.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
29
B 13 Informations- und Datenbankmanagement<br />
Abb. 14: Darstellung einer relationalen Datenbank<br />
Aufgaben<br />
4 a – 4 d<br />
4.2.1 Notationen<br />
Es stehen unterschiedliche Kennzeichnungen für die Darstellung der Beziehungslinien<br />
zur Verfügung. Innerhalb dieses <strong>Lehrbuch</strong>s wird mit der Notation nach IEM (Information-Engineering-Method)<br />
sowie nach C.A. Zehnder gearbeitet.<br />
IEM Zehnder Bedeutung Minimal Maximal Beispiel<br />
c<br />
keines oder<br />
eines<br />
kein 1<br />
Ein Kunde hat keine<br />
oder genau eine Anrede.<br />
1 genau eines 1 1<br />
Der Kunde besitzt<br />
immer genau eine<br />
Anrede.<br />
mc<br />
keines bis<br />
mehrere<br />
kein<br />
mehrere<br />
Der Kunde hat keine<br />
Anrede. Er kann<br />
aber auch eine Anrede<br />
oder sogar mehrere<br />
Anreden haben.<br />
m<br />
eines bis<br />
mehrere<br />
1 mehrere<br />
Der Kunde weist<br />
mindestens eine Anrede<br />
auf, kann aber<br />
auch mehrere Anreden<br />
haben.<br />
Tabelle 12: Notation<br />
In der Praxis wird die 1-Beziehung oftmals mit einem Strich dargestellt. Möglich ist<br />
auch die Darstellung mit 2 Strichen. Achten Sie daher während der Prüfung auf die<br />
Notationsvorgaben!!!<br />
Die Wahl der richtigen Beziehungsart hat einen grossen Einfluss auf die korrekte<br />
Funktionsweise der Datenbank. Das nachfolgende Beispiel verdeutlicht diesen Umstand.<br />
Sie beabsichtigen, von einem Kunden mehrere Adressarten wie Privat- und Rechnungsadresse<br />
zu speichern. Als Beziehungstyp haben Sie das Symbol gewählt.<br />
Dieses Symbol sagt aus, dass pro Kunde genau eine Adresse gespeichert werden kann.<br />
Folglich wird mit dieser Beziehungsart Ihrem Wunsch nicht entsprochen.<br />
30<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
4.3 Realisierung<br />
Ein Datenbankmodell kann entsprechend den vorhandenen Informationen auf zwei<br />
unterschiedliche Arten erstellt werden.<br />
Datenmodellierung<br />
Datennormalisierung<br />
Wenn keine Daten vorhanden sind, entwickelt<br />
man das Datenmodell anhand der Bedürfnisse<br />
und Anforderungen der zukünftigen<br />
Benutzer.<br />
In den nachfolgenden Kapiteln 5 und 6 wird<br />
dieses Vorgehen näher erläutert.<br />
Sind bereits Daten in einer anderen Form<br />
vorhanden, kann mit Hilfe der Normalisierung<br />
das Datenbankschema erarbeitet werden.<br />
Im Kapitel 7 erfahren Sie nähere Details<br />
über dieses Vorgehen.<br />
Tabelle 13: Datenmodellierung/Datennormalisierung<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
31
B 13 Informations- und Datenbankmanagement<br />
5 Erstellung einfacher Datenmodelle<br />
Sie werden als Informatiker der GOURMEX AG mit dem Auftrag betraut, eine Datenbank<br />
herzustellen, die bestimmte Funktionen einschliesst. Geplant ist eine Verkaufsdatenbank.<br />
Bevor Sie mit der Umsetzung beginnen, erstellen Sie das Konzept auf<br />
Papier. Die Planung bzw. der Entwurf einer Datenbank sollte mit Hilfe spezieller Darstellungstechniken<br />
erfolgen. Im Anschluss werden diese Techniken näher erläutert.<br />
ERM<br />
5.1 ERM (Entity-Relationship-Modell)<br />
Mittels ERM erhält man eine vollständige Übersicht über eine Datenbank. Ein ERM<br />
besteht aus einem ERD (Entity-Relationship-Diagramm) und dem Relationenmodell.<br />
ERM<br />
ERD<br />
Relationenmodell<br />
Abb. 15: ERM, ERD und Relationenmodell<br />
ERD<br />
5.2 ERD (Entity-Relationship-Diagramm)<br />
Das ERD bildet die Entitätsmengen und deren Beziehungen zueinander ab. Die Beziehungen<br />
können mit unterschiedlichen Notationen dargestellt werden. Dabei werden<br />
die Entitätsmengen als Rechtecke und die Beziehungen mit Verbindungslinien abgebildet.<br />
Die Endpunkte der Verbindungslinien sind mit speziellen Symbolen gekennzeichnet.<br />
Die im ERD enthaltenen Informationen über die Entitätsmengen und deren Beziehungen<br />
geben relativ schnell einen Überblick über die Datenbank. Auch sehr grosse<br />
und komplexe Datenbanksysteme können übersichtlich auf wenigen Seiten dargestellt<br />
werden.<br />
Anrede<br />
Kunde<br />
Abb. 16: Beispiel eines ERDs<br />
32<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
5.3 Das Relationenmodell<br />
Das ERD stellt die vorhanden Entitätsmengen und deren Beziehungen grafisch dar.<br />
Weitere Details zur Datenbank sind allerdings nicht vorhanden. Zusätzliche Informationen<br />
ergeben sich aus dem Relationenmodell, das zusätzlich Attribute, Primär- und<br />
Fremdschlüssel aufdeckt. Ein Relationenmodell lässt sich üblicherweise wie folgt darstellen.<br />
Zuerst wird die Entitätsmenge definiert. In Klammern sind die Attribute ergänzt.<br />
Primär- und Fremdschlüssel werden verschiedenartig hervorgehoben.<br />
Relationenmodell<br />
Kunde (Kunde_Id, Nachname, Vorname, Strasse, PLZ, Ort, Kundenrating, Anrede)<br />
Anrede (Anrede_Id, Anrede)<br />
Primärschlüssel/Fremdschlüssel<br />
Abb. 17: Relationenmodell<br />
Der Primärschlüssel wird beispielsweise fett oder rot markiert oder doppelt unterstrichen.<br />
Der Fremdschlüssel kann hingegen einfach unterstrichen sein oder kursiv dargestellt<br />
werden. Es empfiehlt sich, das Relationenmodell mit einer entsprechenden<br />
Legende zu ergänzen.<br />
Ersichtlich<br />
ERD<br />
Relationenmodell<br />
Was<br />
Entitätsmenge X X<br />
Beziehung<br />
X<br />
Primärschlüssel<br />
Fremdschlüssel<br />
Attribute<br />
X<br />
X<br />
X<br />
Tabelle 14: Unterschiede zwischen ERD und Relationenmodell<br />
Oft werden in der Praxis auch Kombinationen zwischen ERD und Relationenmodell<br />
durchgeführt. Bspw. können im ERD die Primärschlüssel ergänzt werden.<br />
5.4 Festlegung der Schlüssel<br />
Damit die Datensätze in Tabellen wieder gefunden werden, müssen diese über Primärschlüssel<br />
verfügen. Bei relationalen Datenbanken werden Beziehungen über Primär-<br />
und Fremdschlüssel erstellt. Nachfolgend erfahren Sie mehr über Primär- und<br />
Fremdschlüssel. Ausserdem erfahren Sie, wie eine bessere Datenqualität mit Hilfe der<br />
referentiellen Integrität erreicht werden kann.<br />
Schlüssel<br />
5.4.1 Primärschlüssel<br />
Jede Entität in einer Tabelle verfügt über einen Primärschlüssel. Der Primärschlüssel<br />
sollte folgende Eigenschaften besitzen:<br />
--<br />
Er muss eindeutig sein. Es darf keine zwei Datensätze mit demselben Primärschlüssel<br />
in der gleichen Tabelle geben.<br />
--<br />
Da Primärschlüssel an vielen Stellen in der Datenbank vorkommen und vom DBMS<br />
verwendet werden, sollten sie möglichst kurz sein, um die Performance des Systems<br />
und den Speicherbedarf zu optimieren.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
33
B 13 Informations- und Datenbankmanagement<br />
--<br />
Er muss unveränderlich sein. Fremdschlüssel zeigen oftmals an vielen Stellen in der<br />
Datenbank auf den referenzierenden Primärschlüssel. Wird dieser Primärschlüssel<br />
geändert, müssen sämtliche Referenzen ebenfalls geändert werden. Dies ist eine<br />
sehr aufwendige und vor allem extrem fehleranfällige Arbeit.<br />
--<br />
Beim Einfügen eines neuen Datensatzes muss es möglich sein, einen neuen Wert<br />
für den Primärschlüssel zu finden, so dass es zu keiner Kollision mit einem bereits<br />
bestehenden Wert kommt.<br />
Künstliche Primarschlüssel<br />
Um alle vier Forderungen zu erfüllen, sollten Sie einen Wert mit ganzen Zahlen als<br />
Primärschlüssel wählen, der keine weitere Bedeutung hat.<br />
Dabei handelt es sich in den meisten Fällen um eine fortlaufende Nummerierung der<br />
bestehenden Datensätze. Man spricht in einem solchen Fall auch von einem «künstlichen»<br />
oder «technischen» Schlüssel.<br />
Natürliche Primarschlüssel<br />
Sie können auch natürliche Schlüssel verwenden. Gemeint sind ein oder mehrere Attribute<br />
in einer Tabelle, die die Fähigkeit besitzen, einen Datensatz eindeutig zu identifizieren.<br />
Dies können natürliche Schlüssel wie zum Beispiel AHV-Nummern, Kontonummern,<br />
Postleitzahlen etc. sein.<br />
In unserem Beispiel könnte der Primärschlüssel der Tabelle «Kunde» eine künstliche<br />
Kundennummer sein. In der Tabelle Ort wird ein natürlicher Schlüssel in Form der<br />
«PLZ» mit 6 Stellen eingegeben. Die vierstelligen Postleitzahlen in der Schweiz sind<br />
nicht eindeutig.<br />
Fremdschlüssel<br />
5.4.2 Fremdschlüssel<br />
Der Fremdschlüssel ist ein Attribut oder eine Kombination von Attributen in einer<br />
Tabelle, die in einer anderen Tabelle als Primärschlüssel in Erscheinung treten kann.<br />
In der Tabelle «Kunde» muss ein Fremdschlüssel «Anrede» erstellt werden, der auf<br />
den Primärschlüssel «Anrede_Id» in der Tabelle «Anrede» verweist. Mit Hilfe dieser<br />
Beziehung lassen sich beide Tabellen miteinander verbinden.<br />
Kunde<br />
Anrede<br />
Kunde_Id Nachname Vorname Anrede Anrede_Id Anrede<br />
100 Muster Hans 1 1 Herr<br />
200 Muster Isabelle 2 2 Frau<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 15: Fremdschlüssel<br />
5.4.3 Referentielle Integrität<br />
Die referentielle Integrität in einem Datenbanksystem gewährleistet, dass nur Fremdschlüssel<br />
eingegeben werden können, welche in der verknüpften Tabelle als Primärschlüssel<br />
definiert sind.<br />
So kann zum Beispiel ein Kunde mit der Anrede «Herr Dr.» erst in die Tabelle «Kunde»<br />
eingetragen werden, wenn die Tabelle «Anrede» diese spezielle Anrede enthält.<br />
34<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Kunde<br />
Anrede<br />
Kunde_Id Nachname Vorname Anrede Anrede_Id Anrede<br />
100 Muster Hans 1 1 Herr<br />
200 Muster Isabelle 2 2 Frau<br />
300 Meier Kurt 3 3 Herr Dr.<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 16: Referentielle Integrität<br />
Die referentielle Integrität vermindert auf diese Weise Fehleingaben und liefert korrekte<br />
Daten. Ungeachtet dessen muss dem Datenbankmanagementsystem das Verhalten<br />
bei Verletzung der referentiellen Integrität mitgeteilt werden.<br />
Was soll zum Beispiel mit den Kunden der Tabelle «Kunde» geschehen, wenn Sie in<br />
der Tabelle «Anrede» die Entität «3; Herr Dr.» löschen?<br />
In einem DBMS können Sie unter anderem bestimmen, ob eine Fehlermeldung die<br />
Durchführung des Löschvorgangs unterbrechen soll oder ob die Datensätze in der<br />
Fremdschlüsseltabelle ebenfalls gelöscht werden sollen.<br />
5.5 Korrekte Umsetzung der Anforderungen<br />
Um ein Datenmodell mit den benötigten Entitätsmengen und den korrekten Beziehungen<br />
zu erstellen, benötigen Sie viele Angaben. An diese Informationen können<br />
Sie mit Hilfe von Erhebungstechniken, wie z.B. Interview, Dokumentenstudium etc.<br />
gelangen. Im nachfolgenden Beispiel erheben wir die Bedürfnisse einer Kundendatenbank<br />
mittels der Interview-Technik.<br />
Ein Kunde kann mehrere Aufträge erteilen. Ein Auftrag kann einen oder mehrere<br />
Artikel umfassen. Artikel können nicht, einmal oder mehrmals bestellt werden. Ein<br />
Kunde verfügt über eine Anrede und einen Ort. Die Aufträge werden von Verkäufern<br />
eingegeben, welche keinen, einen oder mehrere Aufträge erfassen.<br />
Der Begriff Artikel wird innerhalb dieses <strong>Lehrbuch</strong>s mit der Bezeichnung Produkt<br />
gleichgesetzt.<br />
5.5.1 Erstellen eines ERDs<br />
Aufgrund der Informationen, die sich mittels Interview-Technik ergeben haben, besteht<br />
nun die Möglichkeit, ein ERD zu erstellen. Dabei weichen die Vorgehensweisen<br />
unter Umständen voneinander ab.<br />
Suche nach Entitätsmengen<br />
Sehr geübte Datenbankdesigner erstellen das ERD während des Textlesens und zeichnen<br />
fortlaufend die Entitätsmengen und deren Beziehungen auf. Fehlt diese Routine,<br />
können in einem ersten Schritt alle Entitätsmengen aus dem Text herausgefiltert werden.<br />
In der Regel handelt es sich um Substantive.<br />
In unserem Beispiel sind dies im Einzelnen die Entitätsmengen Auftrag, Kunde, Artikel,<br />
Anrede, Ort sowie Sachbearbeiter.<br />
Tabellen werden übrigens niemals mit der Mehrzahlform betitelt.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
35
B 13 Informations- und Datenbankmanagement<br />
Bildung von Beziehungen<br />
Nachdem die Entitätsmengen ermittelt worden sind, geht es darum, die Beziehungen<br />
herzustellen. Die Art der Beziehungserstellung basiert auf der an das Datenmodell<br />
gestellten Anforderung.<br />
In unserem Beispiel soll ein Auftrag einen bzw. mehrere Artikel umfassen. Somit haben<br />
wir eine m-Beziehung «Auftrag» zu «Artikel». Im Gegenzug kann ein Artikel<br />
keinmal, einmal oder mehrmals in der Tabelle «Auftrag» vorkommen. Es besteht eine<br />
mc-Beziehung «Artikel» zu «Auftrag». Ein ERD der GOURMEX AG könnte wie folgt<br />
aussehen:<br />
Anrede<br />
Ort<br />
Kunde Auftrag Artikel<br />
Verkäufer<br />
Abb. 18: ERD der GOURMEX AG<br />
5.5.2 Aufbau eines Relationenmodells<br />
Das ERD gewährt bereits einen ersten Überblick über Entitätsmengen und deren Beziehungen.<br />
Um mit der Datenbank effizient arbeiten zu können, fehlen Informationen<br />
wie Attribute sowie Primär- und Fremdschlüssel. Diese Informationen sind im<br />
Relationenmodell festgehalten.<br />
Beim Relationenmodell werden alle Entitätsmengen aus dem ERD übernommen. Anschliessend<br />
können die benötigten Attribute definiert werden. Diese Felder werden<br />
auf der Grundlage der Benutzerbedürfnisse festgelegt.<br />
Jetzt fehlen nur noch die Primär- und Fremdschlüssel. Als Faustregel gilt, dass jede m-<br />
bzw. mc-Beziehung einen Fremdschlüssel beinhalten muss.<br />
Das Relationenmodell einer Verkaufsdatenbank könnte auszugsweise wie folgt aussehen.<br />
36<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Anrede<br />
Ort<br />
Kunde<br />
Verkäufer<br />
(Anrede_Id, Anrede)<br />
(PLZ, Ort)<br />
(Kunde_Id, Anrede_Id, Nachname, Vorname, Strasse, PLZ, Kundenrating)<br />
(Verkäufer_Id, Nachname, Vorname)<br />
.....<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 17: Auszug Relationenmodell<br />
In der Schweiz sind die vierstelligen PLZ nicht eindeutig. In diesem <strong>Lehrbuch</strong> wird zur<br />
Vereinfachung mit der vierstelligen PLZ gearbeitet.<br />
Aufgaben<br />
5 a – 5 f<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
37
B 13 Informations- und Datenbankmanagement<br />
Komplexe<br />
Datenmodelle<br />
6 Komplexe Datenmodelle<br />
Beim Erstellen eines ERDs gibt es einige Spezialfälle, mit welchen Sie innerhalb dieses<br />
Kapitels bekannt gemacht werden.<br />
Komplexe<br />
Datenmodelle<br />
1:m-<br />
Beziehung<br />
Auflösung<br />
komplexer<br />
Beziehungen<br />
Generalisierung<br />
und<br />
Spezialisierung<br />
Doppelte<br />
Beziehung<br />
Rekursive<br />
Beziehung<br />
Abb. 19: Komplexe Datenmodelle<br />
1:m-Beziehung<br />
6.1 1:m-Beziehung<br />
Die 1:m-Beziehung kann in konzeptionellen Datenmodellen vorkommen. Diese Beziehung<br />
hat allerdings den Nachteil, dass sie technisch in einigen Datenbanken (zum<br />
Beispiel MS Access) nicht umgesetzt werden kann. Im nachfolgenden Beispiel liegt<br />
ein Ort in genau einem Land. Ein Land hat mindestens einen oder aber mehrere Orte.<br />
Land<br />
Ort<br />
Abb. 20: Beispiel einer 1:m-Beziehung<br />
Die Problematik dieses Beispiels gründet sich darauf, dass ein neues Land erst erfasst<br />
werden kann, sofern für dieses Land ein Ort vorliegt. Der Ort ist jedoch erst erfassbar,<br />
wenn das entsprechende Land existiert. Es wird daher empfohlen, die 1:m-Beziehung<br />
nur in absolut eindeutigen Fällen zu verwenden. In Fällen, wie dem eben geschilderten<br />
ist die 1:mc-Beziehung zu benutzen. In der 1:mc-Beziehung ist die 1:m-Beziehung<br />
enthalten.<br />
Auflösung<br />
6.2 Auflösung komplexer Beziehungen<br />
Häufig kommt es bei der Erstellung einer Beziehung zwischen zwei Tabellen zu komplexen<br />
Beziehungen. Das heisst, dass an beiden Enden der Beziehung mehrere Einträge<br />
(m oder mc) möglich sind.<br />
Die Tabelle «Artikel» weist die Artikel «Gipfel» und «Brötchen» auf. In der Tabelle<br />
«Auftrag» sind die Bestellungen Nr. 4 und 9 eingetragen worden. Nun ist es möglich,<br />
dass Herr Müller mit der Bestellung Nr. 4 Brötchen und Gipfel zusammen aus der Tabelle<br />
«Artikel» bestellt. Das Brötchen hingegen kann in mehreren Bestellungen vorkommen.<br />
Eine genaue Zuteilung ist nicht möglich, da der Artikel Brötchen auf zwei<br />
Bestellungen hinzeigt.<br />
38<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Auftrag<br />
Artikel<br />
Bestellung 4<br />
von<br />
Herrn Müller<br />
Bestellung 9<br />
von<br />
Herrn Meier<br />
Abb. 21: Komplexe Beziehung (Beispiel)<br />
Mit der Notation nach IEM wird diese Bezeichnung wie folgt abgebildet.<br />
Auftrag<br />
Artikel<br />
Abb. 22: Komplexe Beziehung gemäss IEM<br />
In einem ersten konzeptionellen Entwurf können solche m(c):m(c)-Beziehungen bestehen<br />
bleiben. Komplexe Beziehungen sind allerdings in Datenbanken technisch<br />
nicht realisierbar.<br />
Aus diesem Grund muss diese Beziehungsart aufgelöst werden.<br />
Die Auflösung einer komplexen Beziehung erfolgt immer nach dem gleichen Muster.<br />
Zwischen den beiden existierenden Tabellen wird eine neue Tabelle eingeschoben.<br />
Diese Zwischentabelle kann mit einem entsprechenden Namen, wie bspw. «Position»,<br />
oder noch einfacher mit «Auftrag/Artikel» beschriftet werden. Anschliessend ist es<br />
möglich, die Beziehung erneut zu erzeugen.<br />
Ein Auftrag schliesst mindestens eine bis mehrere Positionen ein. Eine Position bezieht<br />
sich dabei lediglich auf einen Artikel. Ein Artikel hingegen kann innerhalb mehrerer<br />
Positionen vorkommen. Die neue Tabelle «Position» ist somit Bindeglied und<br />
ermöglicht eine genaue Zuteilung bzw. Vermittlung der beiden Tabellen «Auftrag»<br />
und «Artikel».<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
39
B 13 Informations- und Datenbankmanagement<br />
Auftrag Position Artikel<br />
Bestellung 4<br />
Brötchen<br />
Bestellung 4<br />
von<br />
Herrn Müller<br />
Bestellung 4<br />
Gipfel<br />
Bestellung 9<br />
von<br />
Herrn Meier<br />
Bestellung 9<br />
Brötchen<br />
Bestellung 9<br />
Gipfel<br />
Abb. 23: Auflösung einer komplexen Beziehung (Beispiel)<br />
Mit der Notation IEM bildet man die oben stehenden Tabellen und deren Beziehungen<br />
untereinander wie folgt ab:<br />
Aufgabe<br />
6 a<br />
Auftrag<br />
Position<br />
Artikel<br />
Abb. 24: Aufgelöste Beziehung nach IEM<br />
Generalisierung/<br />
Spezialisierung<br />
6.3 Generalisierung und Spezialisierung<br />
Als vorbildlicher Mitarbeiter kaufen Sie selbstverständlich auch ihre Lebensmittel<br />
bei der GOURMEX AG ein. Folglich sind Sie sowohl Mitarbeiter als auch Kunde der<br />
GOURMEX AG und werden dementsprechend in den Tabellen «Kunde» und «Mitarbeiter»<br />
geführt. Beide Tabellen weisen dabei die gleichen Attribute wie Nachname,<br />
Vorname, Strasse, PLZ etc. auf. Dies hat den grossen Nachteil, dass die gleichen Informationen<br />
in zwei verschiedenen Tabellen verwaltet werden müssen. Bei einer Änderung<br />
der Adresse ist man folglich dazu gezwungen, beide Tabellen nachzubearbeiten.<br />
Dies wird allerdings häufig vergessen und führt zu Diskrepanzen bzw. schlechter Datenqualität.<br />
Um den Verwaltungsaufwand beider Tabellen zu reduzieren, besteht die<br />
Möglichkeit, gemeinsame Werte in einer zentralen Tabelle zu verwalten.<br />
Im nachfolgenden Beispiel werden alle Informationen in der Tabelle «Partner» verwaltet.<br />
Ein Partner kann somit ein oder kein Kunde sein. Darüber hinaus gibt es aber<br />
auch Attribute, die nur zu Kunden (z.B. Bonität), Mitarbeitern (z.B. Gehalt) oder Lieferanten<br />
(z.B. Lieferkonditionen) gehören können. Diese werden den entsprechenden<br />
Subentitäten zugeordnet.<br />
40<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Abb. 25: Beispiel einer 1:c-Beziehung<br />
Die Superentität ist im konkreten Fall der Partner. Kunde, Mitarbeiter und Lieferant<br />
werden als Subentitäten der Superentität Partner dargestellt. Wenn sich zwei Entitätsmengen<br />
überlappen, können folgende Mengen definiert werden:<br />
Sie sind Kunde und Mitarbeiter der GOURMEX AG. Somit kommen sie in beiden Entitätsmengen<br />
vor. Der Kunde «Meier» ist kein Mitarbeiter der GOURMEX AG. Somit<br />
ist er nur in der Entitätsmenge «Kunde» erfasst (Vgl. hierzu Sub- bzw. Superentitätsmenge).<br />
6.4 Doppelte Beziehungen<br />
Die Verwendung einer doppelten Beziehung stellt einen Spezialfall dar, der aber<br />
durchaus vorkommen kann.<br />
Bei der GOURMEX AG sind alle Mitarbeiter des Unternehmens in der Tabelle «Partner»<br />
erfasst. Ebenfalls verfügt das Unternehmen über ein Auftragssystem, das Kundenbestellungen<br />
aufzeichnet und verwaltet. In der Regel bestellt der Kunde die Waren<br />
im Verkauf. Ein Lagermitarbeiter gibt die bestellten Artikel auf und schliesst die<br />
Bestellung damit ab. Im Auftragssystem werden nun der Name des Auftragserfassers<br />
(Erfasser) sowie der Name des Lagermitarbeiters (Erlediger) festgehalten. Beide Namen<br />
stammen aus der zentralen Partnertabelle.<br />
Doppelte<br />
Beziehungen<br />
Erfasser<br />
Partner<br />
Erlediger<br />
Auftrag<br />
Abb. 26: Doppelte Beziehung<br />
Partner<br />
Auftrag<br />
(Partner_Id, Nachname, Vorname, ….)<br />
(Auftrag_Id, Erfasser, Erlediger, Datum…..<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 18: Relationenmodell doppelte Beziehungen<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
41
B 13 Informations- und Datenbankmanagement<br />
Rekursive<br />
Beziehungen<br />
6.5 Rekursive Beziehungen<br />
Eine Beziehung ist rekursiv, wenn in einer Tabelle eine oder mehrere Beziehungen zur<br />
gleichen Tabelle bestehen. Die rekursive Beziehung einer Entität wird oft auch als pig<br />
ear (dt. Schweineohr) bezeichnet, da diese aufgrund ihrer Form eine gewisse Ähnlichkeit<br />
zu einem Schweineohr aufweist.<br />
Abb. 27: Grafische Darstellung einer rekursiven Beziehung (pig ear)<br />
Anhand der folgenden Beispiele soll deutlich gemacht werden, wie eine rekursive<br />
Beziehung als Datenmodell dargestellt und physisch in einer Tabelle umgesetzt wird.<br />
Hierbei ist zwischen einer c-mc- und einer mc-mc-Rekursion zu unterscheiden.<br />
c-mc-Rekursion<br />
6.5.1 Die c-mc-Rekursion<br />
Die GOURMEX AG besteht aus mehreren Abteilungen, denen Abteilungsleiter vorstehen.<br />
Es ist möglich, dass ein Abteilungsleiter keinen, einen oder mehrere Mitarbeiter<br />
leitet. Darüber hinaus ist ein Mitarbeiter kein bzw. ein Abteilungsleiter. Dieser Sachverhalt<br />
kann wie folgt in der Entitätsmenge «Mitarbeiter» festgehalten werden.<br />
Mitarbeiter<br />
Abb. 28: Rekursive c-mc-Beziehung<br />
Mitarbeiter 1 «Mike Chef» ist Abteilungsleiter und führt in seiner Funktion die Mitarbeiter<br />
2 und 3.<br />
Ma_Id Name Abteilungsleiter<br />
1 Mike Chef Null<br />
2 Karl Bürgin 1<br />
3 Georg Keller 1<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 19: Auflistung der Mitarbeiter<br />
42<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
6.5.2 Die mc-mc-Rekursion<br />
Die GOURMEX AG verkauft Geschenkkörbe. Die Käufer können zwischen verschiedenen<br />
Korbgrössen wählen und den Inhalt der Körbe selbst bestimmen. Dieser Inhalt<br />
stammt aus der Tabelle «Artikel».<br />
Komplexe rekursive Beziehungsmengen müssen durch gezieltes Einfügen von zusätzlichen<br />
Entitätsmengen eliminiert werden. Der obige Sachverhalt kann ebenfalls als<br />
komplexe Beziehung zwischen Artikel Korb und Artikel Champagner bezeichnet werden.<br />
mc-mc-<br />
Rekursion<br />
Artikel_Id<br />
Artikel<br />
1 Korb 1<br />
2 Korb 2<br />
3 Champagner<br />
4 Trauben<br />
....<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 20: Artikelauflistung<br />
Ein Korb kann keinen, einen oder mehrere Artikel fassen. Ein Inhalt, wie zum Beispiel<br />
eine Flasche Champagner, kann hingegen in keinem, einem oder mehreren Körben<br />
enthalten sein.<br />
Auf diese Weise entstehen komplexe Beziehungen einer Entität zu einer oder mehreren<br />
Entitäten in derselben Entitätsmenge.<br />
Artikel<br />
Abb. 29: Rekursive mc-mc-Beziehung<br />
Artikel<br />
enthält<br />
wird aufbewahrt in<br />
Artikel<br />
Abb. 30: Darstellung einer komplexen Beziehung<br />
Diese komplexe Beziehung muss aufgelöst werden, damit die Normalformen nicht<br />
verletzt werden.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
43
B 13 Informations- und Datenbankmanagement<br />
Artikel<br />
Artikel<br />
Geschenkkorb<br />
Abb. 31: Aufgelöste komplexe Beziehung<br />
Da die Entitätsmengen «Artikel» identisch sind, können diese wie folgt zusammengefasst<br />
werden. Das Problem mc-mc-Rekursion wäre damit gelöst.<br />
Artikel<br />
Geschenkkorb<br />
Abb. 32: Zusammengefasste komplexe Beziehung<br />
Das Relationenmodell der Tabelle «Geschenkkorb» könnte wie folgt aufgebaut sein.<br />
Korb<br />
Inhalt<br />
1 3<br />
1 4<br />
1 5<br />
2 3<br />
2 4<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 21: Relationenmodell Geschenkkorb<br />
Daraus ist ersichtlich, dass der Korb 2 eine Flasche Champagner und Trauben enthält.<br />
Aufgaben<br />
6 b – h<br />
44<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
7 Das Normalisieren von Daten<br />
Häufig existieren bereits Daten. Diese werden zum Beispiel in einem bestehenden Excel-File<br />
verwaltet. Sie verfügen damit bereits über die Attribute und deren Datentyp.<br />
Es fehlt jedoch allein das Wissen über die Tabellen und deren Beziehungen.<br />
Mit der Normalisierungstechnik kann man ein Datenbankschema erstellen. Dabei<br />
kommt ein so genanntes Bottom-up-Verfahren zum Einsatz. Ausgehend von Detailinformationen,<br />
die man vorab studiert hat, ist man darauf aufbauend in der Lage, ein<br />
Datenbankmodell zu erstellen. Im Zuge des Normalisierens werden Daten systematisch<br />
Schritt für Schritt umgeformt, bis letztlich das angestrebte Datenmodell besteht.<br />
Die einschlägige Literatur kennt mehrere Normalformen. Für die Praxis sind die Formen<br />
1 bis 3 relevant. Die Daten werden aus der unnormalisierten Form schrittweise in<br />
die 3. Normalform gebracht.<br />
7.1 Unnormalisierte Form<br />
Die GOURMEX AG verwaltet ihre Projekte in einem Excel-File, das wie folgt aufgebaut<br />
ist:<br />
Normalisieren<br />
MA_<br />
Id<br />
Nachname<br />
Vorname<br />
Abt_<br />
Id<br />
Abteilung Proj_Id Projektname<br />
Projektleitung<br />
Stunden<br />
1<br />
2<br />
3<br />
2<br />
3<br />
4<br />
Aalström<br />
Benz<br />
Cluster<br />
Benz<br />
Cluster<br />
Deisler<br />
Anton<br />
Bernhard<br />
Carlo<br />
Bernhard<br />
Carlo<br />
Daniel<br />
A<br />
B<br />
C<br />
B<br />
C<br />
A<br />
Einkauf<br />
Lager<br />
Verkauf<br />
Lager<br />
Verkauf<br />
Einkauf<br />
1<br />
Verkaufsdatenbank<br />
2 Webauftritt<br />
Benz<br />
Cluster<br />
40<br />
50<br />
60<br />
40<br />
50<br />
60<br />
Tabelle 22: Unnormalisierte Form<br />
Diese Tabelle ist problematisch, denn sie weist Redundanzen auf, die beim Hinzufügen<br />
oder Mutieren von Datensätzen zu Fehlern führen können. Daher soll diese Tabelle<br />
Schritt für Schritt zu einem relationalen Datenbankschema umgeformt werden<br />
.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
45
B 13 Informations- und Datenbankmanagement<br />
1. Normalform<br />
7.2 Erzeugung einer Normalform (1. Schritt)<br />
In der ersten Normalform ist pro Attribut nur ein Wert erlaubt. Im angeführten Beispiel<br />
kann dies bei fast allen Attributen nicht gewährleistet werden. Deshalb werden<br />
die Informationen der unnormalisierten Tabelle in eine Tabelle der 1. Normalform<br />
übertragen.<br />
Für jede Information wird ein separater Record verwendet.<br />
MA_<br />
Id<br />
Nachname<br />
Proj_<br />
Id<br />
Projektname<br />
Vorname Abt_Id Abteilung<br />
Projektleitung<br />
Stunden<br />
1 Aalström Anton A Einkauf 1<br />
Verkaufsdatenbank<br />
Benz<br />
40<br />
2 Benz Bernhard B Lager 1<br />
3 Cluster Carlo C Verkauf 1<br />
Verkaufsdatenbank<br />
Verkaufsdatenbank<br />
Benz 50<br />
Cluster 60<br />
4 Benz Bernhard B Lager 2 Webauftritt Cluster 40<br />
3 Cluster Carlo C Verkauf 2 Webauftritt Cluster 50<br />
4 Deisler Daniel A Einkauf 2 Webauftritt Cluster 60<br />
Tabelle 23: 1. Normalform<br />
In der 1. Normalform sind noch viele Redundanzen vorhanden, die es gilt, innerhalb<br />
der nächsten Schritte zu eliminieren.<br />
2. Normalform<br />
7.3 Erzeugung einer Normalform (2. Schritt)<br />
Eine weitere Aufgabe besteht nun darin, den Primärschlüssel zu finden. Mit welchem<br />
Schlüssel lässt sich ein Record in der obigen Tabelle eindeutig identifizieren?<br />
Ein Schlüssel kann auch aus mehreren Attributen, den so genannten Schlüsselattributen,<br />
bestehen. In unserem Beispiel setzt sich der Primärschlüssel aus den Attributen<br />
«MA_Id» sowie «Proj_Id» zusammen.<br />
Jedes dieser Attribute ist dabei ein Teilschlüssel vom gesamten Primärschlüssel.<br />
MA_Id<br />
Abt_Id Abteilung Proj_Id<br />
Nachname<br />
Vorname<br />
Projektname<br />
Projektleitung<br />
Stunden<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 24: Definition Primärschlüssel<br />
Nachdem für jedes Attribut nur ein Wert vorhanden und der Primärschlüssel bekannt<br />
ist, sollten die Abhängigkeiten der übrigen Attribute zum Primärschlüssel untersucht<br />
werden. Das Attribut «Nachname» ist abhängig vom Teilschlüssel «MA_Id».<br />
Das heisst, dass bei der MA_Id «1» immer der Nachname «Aalström» folgt. Das Attribut<br />
«Vorname» ist ebenfalls abhängig vom Attribut «MA_Id», da nach «1» immer der<br />
Eintrag «Anton» folgt. Für die nachfolgenden Attribute gilt exakt das gleiche Prozedere.<br />
Von speziellem Interesse sind die Stunden, die sich auf das Projekt und den jeweiligen<br />
Mitarbeiter beziehen.<br />
46<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
MA_Id<br />
Abt_Id<br />
Proj_Id<br />
Nachname<br />
Vorname<br />
Abteilung<br />
Projektname<br />
Projektleitung<br />
Stunden<br />
Primärschlüssel/Fremdschlüssel<br />
Abb. 33: Abhängigkeiten ermitteln<br />
Nur die vom einfachen Schlüssel abhängigen Attribute werden zusammen in eine<br />
neue Tabelle übertragen. Innerhalb dieses Schrittes sucht man die Felder, die nicht<br />
von einer Schlüsselkombination, sondern von Teilschlüsseln abhängig sind. In unserem<br />
Beispiel ergeben sich daraus die Tabellen «Mitarbeiter», «Projekt» sowie «Projektmitarbeit».<br />
Die Tabelle «Projektmitarbeit» beinhaltet die Attribute der Ursprungs tabelle,<br />
die sich auf den verknüpften Primärschlüssel beziehen.<br />
Mitarbeiter<br />
Projektmitarbeit<br />
MA_Id Nachname Vorname Abt_Id Abteilung MA_Id Proj_Id<br />
Stunden<br />
1 Aalström Anton A Einkauf 1 1 40<br />
2 Benz Bernhard B Lager 2 1 50<br />
3 Cluster Carlo C Verkauf 3 1 60<br />
4 Deisler Daniel A Einkauf 2 2 40<br />
3 2 50<br />
4 2 60<br />
Projekt<br />
Proj_Id Projektname Projektleitung<br />
1 Verkaufsdatenbank 2<br />
2 Webauftritt 3<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 25: 2. Normalform<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
47
B 13 Informations- und Datenbankmanagement<br />
3. Normalform<br />
7.4 Erzeugung einer Normalform (3. Schritt)<br />
Die Tabellen «Projekt» und «Projektmitarbeit» liegen bereits in der 3. Normalform<br />
vor, da die Attribute direkt abhängig vom Primärschlüssel der Tabelle sind.<br />
Die Tabelle «Mitarbeiter» hingegen enthält unter dem Attribut «Abteilung» immer<br />
noch Redundanzen, die zu Fehleingaben führen können.<br />
Beispielsweise könnte ein neuer Eintrag mit der Abt_Id «A» und der Abteilung «Buchhaltung»<br />
erfasst werden. Aus diesem Grund werden in der 3. Normalform auch diejenigen<br />
Attribute in eigene Tabellen ausgegliedert, die nicht direkt von den Teilschlüsseln<br />
abhängig sind.<br />
Mitarbeiter<br />
Projektmitarbeit<br />
MA_Id Nachname Vorname Abt_Id MA_Id Proj_Id Stunden<br />
1 Aalström Anton A 1 1 40<br />
2 Benz Bernhard B 2 1 50<br />
3 Cluster Carlo C 3 1 60<br />
4 Deisler Daniel A 2 2 40<br />
3 2 50<br />
4 2 60<br />
Projekt<br />
Abteilung<br />
Proj_Id Projektname Projektleitung Abt_Id Abteilung<br />
1<br />
Verkaufsdatenbank<br />
2 A Einkauf<br />
2 Webauftritt 3 B Lager<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 26: 3. Normalform<br />
C<br />
Verkauf<br />
Aufgaben<br />
7 a – c<br />
48<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
8 Das Historisieren von Daten<br />
In den vorherigen Kapiteln haben wir für die GOURMEX AG nachfolgendes Datenmodell<br />
für die neue Verkaufsdatenbank erstellt.<br />
Historisieren<br />
Anrede<br />
Ort<br />
Kunde<br />
Auftrag<br />
Position<br />
Artikel<br />
Verkäufer<br />
Anrede<br />
(Anrede_Id, Anrede)<br />
Ort<br />
(PLZ, Ort)<br />
Kunde<br />
(Kunde_Id, Anrede_Id, Nachname, Vorname, Strasse, PLZ, Kundenrating)<br />
Verkäufer (Verkäufer_Id, Nachname, Vorname)<br />
Auftrag<br />
Position<br />
Artikel<br />
(Auftrag_Id, Kunde_Id, Verkäufer_Id, Auftrag_vom)<br />
(Auftrag_Id, Artikel_Id, Menge)<br />
(Artikel_Id, Artikel, Preis)<br />
Primärschlüssel/Fremdschlüssel<br />
Abb. 34: Verkaufsdatenbank ohne Historisierung<br />
Mittels dieser Datenbank können Bestellungen von Kunden direkt in eine Verkaufsmaske<br />
eingetragen werden. Die Erstellung der entsprechenden Rechnungen erfolgt<br />
automatisch.<br />
Herr<br />
Hans Muster<br />
Auftragsnummer: 2334534<br />
Gemäss Ihrer Bestellung vom 02.07.2010 stellen wir Ihnen folgenden<br />
Betrag in Rechnung.<br />
Menge Artikel Preis Total<br />
10 Brot 2.00 20.00<br />
< Tabelle Anrede<br />
< Tabelle Kunde<br />
< Tabelle Auftrag<br />
< Tabelle Position und<br />
Artikel<br />
…<br />
Total 20.00<br />
Tabelle 27: Rechnungsbeispiel (Auszug)<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
49
B 13 Informations- und Datenbankmanagement<br />
Es kann immer wieder etwas Unerwartetes geschehen. Das muss bei der Erstellung<br />
des Datenmodells berücksichtigt werden. Unerwartet könnte es bspw. zu einer Preisänderung<br />
bei den Produkten kommen.<br />
Der Preis für Brot wird von CHF 2.00 auf CHF 3.00 erhöht. Hierfür wird lediglich in der<br />
Tabelle «Artikel» der Inhalt vom Attribut «Preis» angepasst. Sie gehen davon aus, dass<br />
kommende Rechnungen mit dem korrekten Preis ausgedruckt werden.<br />
Artikel_Id Artikel Preis<br />
1 Brot 2.00 3.00<br />
Tabelle 28: Tabelle Preisänderung<br />
Leider kommt es immer wieder vor, dass Kunden Ihre Rechnungen «nicht erhalten»<br />
haben. Folglich müssen Sie diese erneut ausdrucken. Aus dieser Verkettung ungünstiger<br />
Umstände ergibt sich folgendes Problem: Der Preis wird aus dem Attribut «Preis»<br />
bezogen, welcher stets aktuell ist. Die Preise vergangener Rechnungen sind demzufolge<br />
nicht mehr vorhanden. Alte Rechnungen werden nicht mit CHF 2.00, sondern<br />
mit dem neuen Preis von CHF 3.00 ausgewiesen und gedruckt. Daher ist jedes Unternehmen<br />
gezwungen, eine Historisierung der Datenbank vorab zu planen.<br />
Historisieren<br />
von Entitäten<br />
8.1 Historisieren von Entitäten<br />
Jeder Datensatz hat eine bestimmte Laufzeit bzw. Gültigkeit. Nach seiner Erstellung<br />
(create) können Mutationen (update) vorgenommen werden. Verliert der Datensatz<br />
innerhalb einer gewissen Zeit an Informationswert, kann er gelöscht (delete) werden.<br />
Die Preise der Artikel müssen historisiert werden, um solche Szenarien wie das oben<br />
stehende zu vermeiden.<br />
Ein Artikel verfügt in seiner Laufzeit über einen bis mehrere Preise. Die Beziehung<br />
Artikel zu Preis gleich 1:mc wird dabei sofort ersichtlich.<br />
Das Historisieren von Attributen findet immer nach dem gleichen Schema statt, das in<br />
3 Schritten erfolgt.<br />
1. Das Attribut, welches historisiert werden soll, wird einer neuen Tabelle zugeteilt.<br />
Die neue Tabelle wird in diesem Beispiel mit «Preis» definiert. Wichtiger Bestandteil<br />
dieser Tabelle sind Zeitattribute wie bspw. «Gültig_von» und «Gültig_bis».<br />
2. Die Beziehung zu dieser neuen Tabelle ist immer 1:mc. Ein Artikel kann demnach<br />
mehrere Preise haben, obgleich ein Preis zu genau einem Artikel gehört.<br />
3. Das historisierte Attribut muss in der «alten» Tabelle gelöscht werden. Somit wird<br />
das Attribut «Preis» aus der Tabelle «Artikel» entfernt.<br />
Im nachfolgenden ERD wurde die Historisierung unserer Datenbank bereits vorgenommen.<br />
50<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
Anrede<br />
Ort<br />
Kunde<br />
Auftrag<br />
Position<br />
Artikel<br />
Verkäufer<br />
Preis<br />
Anrede<br />
(Anrede_Id, Anrede)<br />
Ort<br />
Kunde<br />
Verkäufer<br />
Auftrag<br />
Position<br />
Artikel<br />
Preis<br />
(PLZ, Ort)<br />
(Kunde_Id, Anrede_Id, Nachname, Vorname, Strasse, PLZ, Kundenrating)<br />
(Verkäufer_Id, Nachname, Vorname)<br />
(Auftrag_Id, Kunde_Id, Verkäufer_Id, Auftrag_vom)<br />
(Auftrag_Id, Artikel_Id, Menge)<br />
(Artikel_Id, Artikel, Preis)<br />
(Preis_Id, Preis, Gültig_von, Gültig_bis, Artikel_Id)<br />
Primärschlüssel/Fremdschlüssel<br />
Abb. 35: Verkaufssystem mit Historisierung<br />
Mögliche Inhalte der Tabelle «Preis» und «Artikel» ergeben sich wie folgt.<br />
Artikel<br />
Preis<br />
Artikel_Id Artikel Preis_Id Preis Gültig_von Gültig_bis Artikel_Id<br />
1 Brot 1 2.00 01.01.2010 31.03.2010 1<br />
2 Gipfel 2 3.00 01.04.2010 1<br />
3 Schokolade …<br />
…<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 29: Tabellen: Artikel und Preis<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
51
B 13 Informations- und Datenbankmanagement<br />
8.2 Historisieren von Beziehungen<br />
Bei der GOURMEX AG wird Ihr Projekt «Erstellung einer neuen Verkaufsdatenbank»<br />
im Projektverwaltungssystem gespeichert. Sie selbst haben hierfür das Datenmodell<br />
im Kapitel «Normalisieren» erstellt. Der Ausschnitt des Datenmodells weist auf die<br />
Abhängigkeit zwischen den Tabellen Mitarbeiter und Projekte hin und deckt die folgenden<br />
Sachverhalte ab:<br />
- Mitarbeiter können in mehreren Projekten mitarbeiten.<br />
- Ein Projekt sollte von mehreren Mitarbeitern gleichzeitig bearbeitet werden können.<br />
- Jedes Projekt hat genau einen Projektleiter.<br />
- Ein Mitarbeiter kann innerhalb mehrerer Projekte die Funktion des Projektleiters<br />
übernehmen.<br />
Projektmitarbeit<br />
Mitarbeiter<br />
Projektleitung<br />
Projekt<br />
Abb. 36: Datenmodell Projektverwaltung<br />
Diese Datenbank hat sich bewährt. Eine Historisierung der Daten konnte jedoch bisher<br />
nicht vorgenommen werden.<br />
Sie, in Ihrer Funktion als Historisierungsexperte, erhalten deshalb den Auftrag, die<br />
Datenbank so umzugestalten, dass die nachfolgenden Anforderungen erfüllt werden<br />
können.<br />
1. Es ist ersichtlich, welche Mitarbeiter im Laufe der Zeit in welchen Projekten eingeteilt<br />
waren (Beispiel: Mitarbeiter Benz war von/bis im Projekt Verkaufsdatenbank<br />
und von/bis im Projekt Webauftritt)<br />
2. Es kann jederzeit eingesehen werden, welche Projektleiter in welcher Periode<br />
ein Projekt geleitet haben.<br />
Nachfolgend erfahren Sie, wie Sie Beziehungen sowohl mit bestehenden als auch<br />
ohne Zwischentabellen historisieren.<br />
52<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
B 13 Informations- und Datenbankmanagement<br />
8.2.1 Historisierung einer Beziehung mittels Zwischentabelle<br />
Die erste Anforderung ist rasch erfüllt. In der Zwischentabelle «Projektmitarbeit»<br />
müssen lediglich die Attribute «Datum_von» und «Datum_bis» hinzugefügt werden.<br />
Ist das «Datum_bis» leer, nimmt der Mitarbeiter noch aktiv am Projekt teil. Besteht<br />
also bereits eine Zwischentabelle zwischen zwei Tabellen, kann die Beziehung durch<br />
das Hinzufügen von Datumswerten (z.B. Datum_von/Datum_bis) historisiert werden.<br />
Ma_Id Projekt_Id Datum_von Datum_bis<br />
100 1000 01.01.2010 31.03.2010<br />
200 1000 01.01.2010 31.12.2010<br />
300 1000 01.04.2010 31.12.2010<br />
100 2000 01.03.2010 31.10.2010<br />
200 2000 01.03.2010 31.10.2010<br />
200 3000 01.07.2010 31.12.2010<br />
300 3000 01.09.2010 31.12.2010<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 30: Ergänzte Tabelle Projektmitarbeit mit Musterinhalt<br />
8.2.2 Historisierung einer Beziehung ohne Zwischentabelle<br />
Die zweite Anforderung lässt sich nicht so schnell erfüllen. Es soll möglich sein, dass<br />
ein Projekt in seiner Lebenszeit von mehreren Projektleitern geleitet wird. Darüber<br />
hinaus kann ein Projektleiter für mehrere Projekte verantwortlich sein. Infolgedessen<br />
entsteht zwischen «Mitarbeiter» und «Projekt» eine komplexe Beziehung, die mit der<br />
Zwischentabelle «Projektleitung» aufgelöst werden kann. Beim Historisieren einer<br />
Beziehung ohne eine bestehende Zwischentabelle muss deshalb eine Zwischentabelle<br />
neu erstellt werden. Anschliessend werden ebenfalls die Attribute «Datum_von»<br />
und «Datum_bis» benötigt. Daraus ergibt sich folgendes ERD.<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.<br />
53
B 13 Informations- und Datenbankmanagement<br />
Projektmitarbeit<br />
Mitarbeiter<br />
Projekt<br />
Projektleitung<br />
Abb. 37: Datenmodell Projektverwaltung (historisiert)<br />
Das Relationenmodell dieser neuen Tabelle «Projektleitung» könnte wir folgt aufgebaut<br />
sein.<br />
Projektleitung_Id Ma_Id Projekt_Id Datum_von Datum_bis<br />
1 100 1000 01.01.2010<br />
Primärschlüssel/Fremdschlüssel<br />
Tabelle 31: Relationenmodell Projektleitung (historisiert)<br />
Aufgaben<br />
8 a – b<br />
8.3 Auswirkung der Historisierungsvorgänge auf eine<br />
Datenbank<br />
Wie Sie selber festgestellt haben, ist das Historisieren von Daten mit erheblichem Aufwand<br />
verbunden. Die Modellierung temporaler Aspekte hat grosse Auswirkungen<br />
auf ein Informationssystem.<br />
••<br />
Komplexere Strukturen im Datenmodell aufgrund zusätzlich benötigter Tabellen<br />
••<br />
Grösseres Datenvolumen<br />
••<br />
Aufwändige Applikationsentwicklung<br />
••<br />
Performanceverlust bedingt durch Verteilung der Informationen auf mehrere Entitäten<br />
Daher werden typischerweise ausschliesslich diejenigen Daten historisiert, die für den<br />
Betrieb des Informationssystems notwendig sind, wie bspw. Preise, Salär eines Mitarbeiters,<br />
Zugehörigkeit zu einer Abteilung, Projektleitung usw.<br />
54<br />
2010 Copyright <strong>Verlag</strong> <strong>DieBirne</strong>.
Change language