Datenbanken WS 01/02
Werbung
WI II WS 03/04 Seite 1 WS 03/04 Wirtschaftsinformatik II Teil I: Datenbanken René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Organisatorisches Kontakt Ablauf der Veranstaltung [email protected] 45 min. Theorie, 45 min. Übungen Klausur: 12.02.04, 10.15 Uhr; NHK: 15.04.04, 10.15 Uhr 45 min. Datenbanken / Programmierung René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 2 Literatur Steiner, R. (2003): Grundkurs Relationale Datenbanken, 5. Aufl., Braunschweig/Wiesbaden. Sauer, H. (1994): Relationale Datenbanken, 3. Aufl., Bonn. Hald, A.; Nevermann, W. (1995): Datenbank-Engineering für Wirtschaftsinformatiker, Braunschweig. Stickel, E. (1991): Datenbankdesign, Wiesbaden. Meier, A. (1992): Relationale Datenbanken, Berlin. Niedereichholz, J.; Kaucky, G. (1992): Datenbanksysteme, Heidelberg. Chen, P.; Knöll, H.-D. (1991): Der Entity-Relationship-Ansatz zum logischen Systementwurf, Mannheim. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 3 Gliederung 1. Grundlagen 2. Relationales Datenmodell 3. Datenbank-Design 1: Normalisierung 4. Datenbank-Design 2: ERM 5. MS Access Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 4 WI II WS 03/04 Seite 5 Verbreitung von Datenbanken CIM SCM Fertigung Materialwirtschaft ERP BWLVerwaltung CRM Kundenbeziehung EC ... E-Commerce Datenbanken sind unverzichtbarer Bestandteil unserer heutigen Wirtschaft und Verwaltung! René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt ... ... Begriffshierarchie „Signale“ Zeichenvorrat Signal Turbulenzen auf Absatzmärkten Syntax Zeichen „1“, „7“, „0“, „,“ Semantik Daten 17,0 WI II WS 03/04 Seite 6 „Wissen“ Pragmatik Information Marktanteil 17,0% Wissen Marktmechanismen des Absatzmarkts Datenbanken als Ausgangspunkt zur Generierung von Informationen und Wissen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Wozu Datenbanksysteme? Aufgabe von EDV-Systemen Bereitstellung von Daten und zwar Problem Ohne Datenbanksysteme zu jeder Zeit, schnell und aktuell, gleichzeitig für verschiedene Nutzer, bedarfsgerecht aufbereitet. Unüberschaubare Zahl an Insellösungen, bei denen enge Abhängigkeiten zwischen Programm- und Datenstrukturen bestehen. Redundante Speicherung identischer Daten. Daraus resultiert hohe Fehleranfälligkeit, hoher Wartungs- und Änderungsaufwand. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 7 Aufbau von Datenbanksystemen 2 Hauptkomponenten Die Datenbank besteht aus einer Sammlung von inhaltlich zusammenhängenden Daten. Dies umfasst eigentliche Nutzdaten sowie Daten zur Verwaltung und Steuerung des Systems. Das Datenbankmanagementsystem (DBMS) stellt Funktionalitäten zur Organisation und Bearbeitung (Lesen, Ändern, Einfügen, Löschen von Daten) zur Verfügung. Datenbanksystem Aufbau Datenbanken Anwendung 1 DBMS Anwendung 2 Anwendung 3 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 8 Aufbau von Datenbanksystemen Access Tabellen Sammeln von Daten Formulare Abfragen Berichte Eingeben von Daten Auswerten von Daten Ausgeben von Daten René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 9 WI II WS 03/04 Seite 10 Architektur von Datenbanksystemen 3-SchichtenModell nach ANSI/SPARC Externes Externes Schema Schema11 Externes Externes Schema Schema22 Externes Externes Schema Schema33 Externes Externes Schema Schema... ... Konzeptionelles Konzeptionelles Schema Schema Internes Internes Schema Schema René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Architektur von Datenbanksystemen Konzeptionelle Ebene zentrale Ebene logische Datenbeschreibung, die sich aus der Problemstellung ergibt gemeinsame Sicht aller Anwendungen auf die Struktur der Datenbasis Externe Ebene Beschreibung der Daten und ihrer Beziehungen aus der Sicht des Anwenders („Views“) normalerweise nur Teilausschnitte aus dem konzeptionellen Datenschema externe Datenschemata unterschiedlicher Anwender können sich im konzeptionellen Datenschema überlappen Interne Ebene i.d.R. durch ein konkretes DB-System realisiert beschreibt die physikalische Struktur der Datenbank; formale Beschreibung, wie die Daten auf einen Datenträger gespeichert werden (Zugriffspfade, Zugriffsoperationen, ...) i.a. besteht auf dieser Ebene selbst für den Datenbankadministrator kein direkter Zugriff René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 11 Architektur von Datenbanksystemen Vorteile Vermeidung von nicht integrierten und damit redundanten Datenbeständen Abstraktionsebenen dienen der Komplexitätsreduktion und führen somit zu einer besseren Verständlichkeit konzeptionelles Schema als gemeinsame Diskussionsgrundlage René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 12 WI II WS 03/04 Seite 13 Überblick Realsphäre Claudia Martin Fliederweg 8 96842 Ahorn 90-60-90 brünett Martin Stephan Auf der Frilis 4 12345 Singen unverheiratet 3 Kinder Marcy Melanich Schwedenalm 2 85051 Ingolstadt 2 Hunde 4 Katzen Fa. Leberbräu Hopfenweg 14 56789 Kuhdorf 27 Mitarbeiter 10 Mio. Umsatz Zielgerichte Abstraktion durch - Abgrenzung eines relevanten Ausschnitts der Realsphäre - Typmäßige Klassifikation von Objekten und Beziehungen - Abgrenzung relevanter Eigenschaften von Obj. und Bez. Konzeptionelles Schema Kunde KdNr. Name Straße PLZ relativ konstant Ort Konkretisierung durch Aufnahme relevanter Obj./Bez. (z.B. ist Objekt „Martin Stephan“ kein Kunde des Unternehmens) Datenbank Kunde KdNr. 1001 1002 1003 Name Straße Claudia Martin Marcy Melanich Fa. Leberbräu Fliederweg 8 Schwedenalm 2 Hopfenweg 14 PLZ 96482 85051 56789 Ort Ahorn Ingolstadt Kuhdorf Zeilenzahl und Werte variabel René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Von der Realwelt zum Modell Beispiel Die Firma XYZ und Partner handelt mit PCs und Zubehör. Sie kauft die Geräte bei verschiedenen Lieferanten und verkauft sie nach einer Bestellung an Einzelhändler, von denen diese PCs an Endkunden weiterverkauft werden. Vorgehen Um eine Datenbank aufzubauen, muss zunächst ein konzeptionelles Schema definiert werden, dass ein möglichst exaktes Bild der realen Welt präsentiert. Zunächst wird durch Analyse der Realwelt ein zu modellierender Ausschnitt der Realwelt (Miniwelt) definiert. Beim Betrachten der Miniwelt erkannt man gewisse Objekte (Entities) wie Artikelnamen, Kundennamen, Kundenadressen etc. Zwischen diesen Objekten bestehen Beziehungen (Relationships). Um zu einem Datenmodell zu kommen, fasst man gleichartige Objekte und gleichartige Beziehungen zu Typen zusammen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 14 WI II WS 03/04 Seite 15 Von der Realwelt zum Modell Beispiel (vereinfacht) Objekttypen Artikel Lieferanten Kunden Beziehungstypen Bestellungen (welcher Kunde bestellt welchen Artikel) Artikel Artikel werden geliefert von Lieferanten Lieferanten bilden (bzw. bestehen aus) Bestellungen Bestellungen enthalten Artikel von Kunden Kunden René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 16 Von der Realwelt zum Modell Beispiel (vereinfacht) Aus dieser grafischen Übersicht (Grundform eines ER-Modells) lassen sich z.B. folgende Tabellen ableiten: Lieferanten Artikel LiefNr LiefName ArtNr ArtBez ArtArt LiefNr 1 2 3 4 5 NEC Audio Master Thomson Easyprint Sharp 1 2 3 4 5 6 7 8 Multisync II Multisync I Herkules Thomson Flat 14‘ P6 + P7 + Laser Printer Monitor Monitor Grafikkarte Monitor Monitor Drucker Drucker Drucker 1 2 1 3 2 4 4 4 Bestellungen Kunden KNr ArtNr Menge 1 1 4 2 3 3 3 2 3 2 8 1 8 3 1 3 2 1 1 1 1 KNr KName KStraße KHsnr KPLZ KOrt 1 2 3 4 5 FAMA GSA Klöckner RADOVA Göhler Goethestr. Hoebergstr. Paradiesweg Im Sand Schmalweg 19 2a 7 45 11 60701 62456 34890 10000 69045 Langen Oberursel Pinneberg Berlin Heidelberg René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Vom Modell zur Datenbank Relationale DBMS In relationalen DBMS werden die Daten in Form von Tabellen abgespeichert. Eine solche Tabelle, in der z.B. die Daten von Mitarbeitern gespeichert werden, könnte folgenden Aufbau besitzen: Angestellte ANr Name Anschrift Beruf 1 Eckstein Lotterstr. 1 Masseuse 2 Hinz Am Weiher 8 Physiker 3 Kunz Bahnhofsstr. 1 Programmierer ... Müller Hauptstr. 1 Programmierer 99 ... ... ... Fischer Hintern Zaun Informatiker René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 17 Vom Modell zur Datenbank SQL Um mit solchen Tabellen zu arbeiten, greift man auf „DatenbankSprachen“ zurück. Die wichtigste ist SQL, die gewöhnlich in drei Klassen unterteilt wird: DDL-Befehle (Data-Definition-Language) Mit den Befehlen dieser Klasse werden Datenstrukturen (Tabellen, Indices, ...) erzeugt, verändert oder gelöscht. DCL-Befehle (Data-Control-Language) DCL-Befehle dienen der Vergabe von Zugriffsrechten in einer Datenbank mit mehreren Benutzern (Lese-/Schreibrechte). DML-Befehle (Data-Manipulation-Language) Mit diesen Befehlen werden Abfragen und Veränderungen der Datenbank durchgeführt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 18 Vom Modell zur Datenbank DDL create table Tabellen erzeugen alter table Tabellenaufbau ändern drop table Tabellen löschen create index Index für Tabellen anlegen DCL grant Zugriffsrechte gewähren revoke Zugriffsrechte entziehen DML select Tabellen abfragen delete Tabellenzeilen löschen insert Tabellenzeilen hinzufügen update Daten einer Tabelle verändern create view Erzeugen einer virtuellen Tabelle rename Tabellen, Spalten umbenennen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 19 Weiteres Vorgehen Theorie Relationales Datenmodell Datenbankdesign Normalisierung ERM René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 20 Gliederung 1. Grundlagen 2. Relationales Datenmodell 3. Datenbank-Design 1: Normalisierung 4. Datenbank-Design 2: ERM 5. MS Access Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 21 Relationale Datenbanken Relationale DB Heutzutage werden üblicherweise relationale Datenbanken (z.B. Access) eingesetzt. Diese Datenbanken basieren auf einem relationalen Datenbankmodell. In einer relationalen Datenbank stellen Tabellen „Dinge“ der realen Welt dar. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 22 Relationale Datenbanken Relationale DB Üblicherweise besteht eine einzelne Datenbank nicht nur aus einer Tabelle, sondern aus mehreren. Diese stehen zueinander in Beziehungen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 23 Grundlagen des relationalen Datenmodells Grundlagen Erstmals 1970 von Codd formuliert das Relationenmodell dient derzeit als Grundlage für die meisten Datenbanksysteme Basis ist die mathematische Relationentheorie einzig benötigtes Strukturelement ist die Relation (hier im Sinne einer zweidimensionalen Tabelle) durch hohe Flexibilität und Einfachheit für betriebswirtschaftliche Anwendungen besonders geeignet ERM kann leicht ins Relationenmodell überführt werden René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 24 Grundlagen des relationalen Datenmodells Relation Tupel Relationen sind Mengen (wie aus der Schulmathematik bekannt). Diese Mengen können anschaulich als zweidimensionale Tabellen dargestellt werden (z.B. Lieferanten) Ein Element aus der Menge; Zeile der Tabelle (z.B. Lieferant Fa. Meyer). Die Kardinalität beschreibt die Anzahl der Tupel einer Relation. Attribute Spalten der Tabelle; beschreiben die Eigenschaften der Tupel (z.B. LNr, Name, Adresse, ...). Die Anzahl der Attribute heißt Grad der Relation. Der Wertebereich eines Attributs heißt Domäne des Attributs. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 25 WI II WS 03/04 Seite 26 Grundlagen des relationalen Datenmodells Relation Attribut Grad = 5 Tupel Kardinalität Domäne (0 <= X < 1000) René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Eigenschaften von Relationen Definition Es gibt keine zwei Tupel in einer Relation, die völlig identisch sind (d.h. es existieren keine Duplikate). Alle Werte sind elementar. Da die Zeilen (Tupel) Elemente einer Menge sind, ist ihre Reihenfolge ohne Bedeutung, d.h. die Zeilen können beliebig vertauscht werden (z.B. für Sortierungen nach PLZ, Namen, ...). Es existiert folglich keine Ordnung zwischen den Tupeln. Da jede Spalte über ihren eindeutigen Attributnamen identifiziert wird, ist die Reihenfolge der Spalten ohne Bedeutung, d.h. die Spalten können beliebig vertauscht werden. Alle Werte innerhalb einer Spalte besitzen den gleichen Datentyp. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 27 Schlüssel Schlüssel Unter einem Schlüssel versteht man ein Attribut oder eine Attributkombination, durch die jedes Tupel einer Relation eindeutig identifiziert wird. Zusätzlich wird die Minimaleigenschaft eines Schlüssels gefordert, d.h. eine Attributkombination ist nur dann ein Schlüssel, wenn bei der Wegnahme eines Attributs aus dem Schlüssel die Schlüsseleigenschaft verloren geht. Schlüsselattribut Jedes Attribut, das zu einem Schlüssel gehört, heißt Schlüsselattribut. Jedes Attribut, das nicht zu einem Schlüssel gehört, heißt Nichtschlüsselattribut. Schlüsselkandidat Häufig existieren zu einem Relationstyp mehrere Schlüssel. Alle möglichen Schlüssel heißen Schlüsselkandidaten. Zusammengesetzter Schlüssel Ein Schlüssel, der aus mehreren Attributen besteht (Attributkombination), heißt zusammengesetzter Schlüssel. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 28 Schlüssel Primärschlüssel Der Schlüsselkandidat, der zur eindeutigen Identifikation der Tupel einer Relation verwendet wird, heißt Primärschlüssel. Häufig besteht dieser aus einem künstlich eingeführten Attribut, z.B. Kundennummer. In einer Relation existieren keine zwei Tupel mit der gleichen Primärschlüsselausprägung (z.B. keine zwei identischen Matrikelnummern). Sein Wert identifiziert ein Tupel über dessen gesamte Lebensdauer und darf nicht abgeändert werden (s.a. Verwendung als Fremdschlüssel). Die Attribute des Primärschlüssels werden durch Unterstreichung (z.B. KundNr) hervorgehoben. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 29 Schlüssel Primärschlüssel Bei mehreren Schlüsselkandidaten wird i.a. der kürzeste als Primärschlüssel ausgewählt. Im Falle eines zusammengesetzten Schlüssels sollte über die Einführung eines künstlichen Attributs zu Identifizierungszwecken nachgedacht werden (Klarheit vs. Speicherbedarf). Jeder Primärschlüssel ist ein Schlüsselkandidat, aber nur ein Schlüsselkandidat ist Primärschlüssel. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 30 Schlüssel Fremdschlüssel Besteht eine Datenbank aus mehreren Relationen, dann werden die Beziehungen zwischen den einzelnen Relationen dadurch hergestellt, dass der Primärschlüssel einer Relation in die Attributmenge einer anderen Relation aufgenommen wird. Der Schlüssel dient dort der Identifizierung von Tupeln einer „fremden“ Relation und wird als Fremdschlüssel bezeichnet. Primärschlüssel Fremdschlüssel René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 31 Schlüssel Beispiele Relation: Studenten Attribute: Name, Vname, Gdatum, Straße, TelNum, MatNum Primärschlüssel: MatNum Relation: Abteilung Attribute: AbtNum, AbtName, AbtLeiter, ... Primärschlüssel: AbtNum oder AbtName René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 32 Relationale Integritätsregeln Definition Unter dem Begriff Integrität bzw. Konsistenz versteht man die Widerspruchsfreiheit von Datenbanken. Eine Datenbank ist integer bzw. konsistent, wenn die gespeicherten Daten fehlerfrei erfasst sind und den gewünschten Informationsgehalt korrekt wiedergeben. Relationale Integritätsregeln dienen der Gewährleistung der Integrität und werden durch das Datenbankschema umgesetzt. Bei relationalen Datenbanken existieren zwei Integritätsregeln bzw. –bedingungen: Entity Integrität Referentielle Integrität René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 33 Entity Integrität - Eindeutigkeit Eindeutigkeitsbedingung Jede Relation besitzt einen Identifikationsschlüssel (Attribut oder Attributskombination), der jedes Tupel der Relation eindeutig bestimmt. Für jede Relation wird ein Schlüssel zwingend verlangt. Falls mehrere Schlüsselkandidaten vorkommen, muss ein Schlüssel als Primärschlüssel definiert werden. Wenn ein Attribut die Komponente eines Primärschlüssels ist, dann darf dieses Attribut zu keinem Zeitpunkt einen NULL-Wert enthalten. Das Prüfen der Eindeutigkeit von Primärschlüsselinhalten wird dabei vom Datenbanksystem vorgenommen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 34 Entity Integrität - Wertebereich Wertebereichsbedingung Die Attribute einer Relation können nur Werte aus einem vordefinierten Wertebereich annehmen. Dies kann nicht durch das Datenbanksystem gewährleistet werden, die Validierung bleibt weitestgehend dem Anwender überlassen. Eine Unterstützungsmöglichkeit bilden Eingabemasken, welche bei der Datenerfassung dem Anwender fest definierte Attributwerte für die Attribute vorgeben (Listenfelder, Radio-Buttons, etc...). René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 35 Entity Integrität - Wertebereich Beispiel 1 Wenn ein Anrufer dem Call Center Agent sein Geburtsdatum nicht nennen will, dieses aber für das Schließen der Maske benötigt wird, geben die Agents z.B. 11.11.11 ein. Beispiel 2 Außendienstmitarbeiter geben z.T. bewusst falsche Angaben über das Potenzial von Kunden an, wenn beim Kunden eine schlecht Parkplatzsituation vorliegt. Beispiel 3 In einer Mitarbeiterrelation kann in einem Attribut Familienstand auf die Ausprägung „ledig“ nicht die Ausprägung „geschieden“ bzw. auf „verheiratet“ nicht „ledig“ folgen. Korrektheit wird nicht durch DBMS vorgegeben, sondern muss aus der Realität abgeleitet werden. Ein DBMS kann niemals exakt prüfen, ob derartige Eingaben korrekt sind, es kann allenfalls grob falsche Angaben abweisen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 36 WI II WS 03/04 Seite 37 Referentielle Integrität Definition Jeder Wert eines Fremdschlüssels muss als Schlüsselwert in der referenzierten Relation existieren (dort bestimmbar über Primärschlüssel) oder der Fremdschlüsselwert ist ein NULL-Wert. Crew-Nr. Name Unterkunft Tät.-Nr. M1 Picard 12/1 1 M9 Data 12/45 1 M6 Troy 10/9 6 M8 Warf 11/67 5 Fremdschlüssel Primärschlüssel Tät.-Nr. Tätigkeit 1 Führung 5 Consulting 6 Sicherheit Die Fremdschlüssel-Primärschlüssel-Beziehung im Beispiel erfüllt die referentielle Integrität, da jeder Wert eines Fremdschlüssels beim zugehörigen Primärschlüssel vorkommt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Anomalien Definition Werden Daten verändert (Ändern, Löschen und Einfügen), können die Integritätsbedingungen verletzt werden. In diesem Fall spricht man von Datenbankanomalien, da die Daten in sich widersprüchlich sind. Man unterscheidet 3 Arten von Anomalien: Einfügeanomalie (Insert) Ein Sachverhalt kann nur dann eingefügt werden, wenn ein anderer Sachverhalt ebenfalls aufgenommen wird: Zum zweiten Sachverhalt stehen entweder noch keine Daten zur Verfügung, oder es wird die Erfassung nicht gewünscht. Löschanomalie (Delete) Ein Sachverhalt geht ungewollt verloren. Änderungsanomalie (Update) Ein einziger Sachverhalt wird geändert, die Relation muss deshalb aber an mehreren Stellen angepasst werden. Unvollständige Anpassung führt zu inkonsistenten Datenbeständen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 38 Anomalien (schlechtes) Beispiel LIEFERANT (LiefNr, NameL, AnschriftL) ARTIKEL (ArtNr, Bezeich, VKPreis, EKPreis, Bestand) BESTELLPOS (LiefNr, ArtNr, BestNr, Menge, TelNr) Einfügeanomalie Beim Aufnehmen eines neuen Lieferanten kann dessen Telefonnummer noch nicht gespeichert werden. Dies ist erst möglich, wenn eine Bestellung für diesen Lieferanten angelegt wird. Löschanomalie Mit der Löschung der letzten Bestellposition eines Lieferanten ist auch dessen Telefonnummer nicht mehr verfügbar. Änderungsanomalie Ändert sich die Telefonnummer eines Lieferanten, für den mehrere Bestellpositionen existieren, so muss die Änderung der Telefonnummer mehrfach durchgeführt werden. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 39 Verfahren zur Gewährleistung der ref. Integrität Grundsätzlich beste Lösung Einfügeanomalien können durch ein verändertes Datenbankschema aufgelöst werden (z.B. Aufnahme von TelNr in Relation Lieferant) Restriktive Löschung Eine Löschoperation wird nicht ausgeführt, solange das zu löschende Tupel auch nur von einem Tupel aus einer anderen Relation referenziert wird. Fortgesetzte Löschregel Hierbei wird eine Spezifikation der beiden Relationen verlangt; bei der Löschung eines referenzierten Tupels werden alle referenzierenden Tupel entfernt. NULL-Setzen Fremdschlüsselwerte in der referenzierenden Relation werden beim Löschen der referenzierten Relation auf NULL gesetzt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 40 Verfahren zur Gewährleistung der ref. Integrität Beispiel Crew-Nr. Name Unterkunft Tät.-Nr. Tät.-Nr. Tätigkeit M1 Picard 12/1 1 1 Führung M9 Data 12/45 1 5 Consulting M6 Troy 10/9 6 6 Sicherheit M8 Warf 11/67 5 Restriktive Löschung Es ist nicht möglich das Tupel „6";„Sicherheit" aus der Relation "Tätigkeiten" zu löschen, solange das Tupel "M6";"Troy";"10/9";„6" in der Relation "Crew" existiert. Fortgesetzte Löschregel Bei Löschung des Tupels "5";"Consulting" aus der Relation "Tätigkeiten", wird das Tupel "M8";„Warf";"11/67"; "5" aus der Relation "Crew" ebenfalls entfernt. NULL-Setzen Bei Löschung des Tupels "5";"Consulting" aus der Relation "Tätigkeiten", wird beim Tupel "M8";„Warf";"11/67"; "5" aus der Relation "Crew" der Attributwert "5" auf NULL gesetzt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 41 WI II WS 03/04 Seite 42 Redundanz Beispiel Definition Crew-Nr. Name Unterkunft Tät.-Nr. Tätigkeit M1 Picard 12/1 1 Führung M9 Data 12/45 1 Führung M6 Troy 10/9 6 Consulting M8 Warf 11/67 5 Sicherheit Unter (Daten-)Redundanz wird das mehrfache Aufführen einer Aussage in einer Relation verstanden. Diese Redundanz führt zu Änderungsanomalien (s.o.) und ist durch geeignete Gestaltung der Relationstypen zu vermeiden. Die mehrfache Nennung eines Eigenschaftswertes (z.B. mehrere Kunden mit Namen „Müller“) stellt hingegen keine Redundanz im obigen Sinne dar. Gleiches gilt für die Schlüsselredundanz bei der Darstellung von Beziehungen zwischen Relationstypen (z.B. kann der Kunde „Meier“ mehrere Bestellungen aufgegeben haben). René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Relationale Algebra Durch das Anwenden der nachfolgenden Operatoren auf eine oder mehrere Relationen entsteht eine neue Relation. Verschachtelungen sind möglich. Man unterscheidet folgende Operatoren: Operatoren Restriction Projection Product Union Intersection Difference Join René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 43 WI II WS 03/04 Seite 44 Relationale Algebra Restriction (Selektion) Extrahiert aufgrund einer Bedingung Tupel aus einer Relation. Syntax: Rest (relation, bedingung) r1 Rest(r1,attribut2=”A”) attribut1 attribut2 attribut1 attribut2 1 A 1 A 2 B René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Relationale Algebra Projection Extrahiert Attribute aus einer Relation. Syntax: Proj (relation, <attribut1, ..., attributn>) r1 Pro(r1,<attribut1>) attribut1 attribut2 attribut1 1 A 1 2 B 2 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 45 WI II WS 03/04 Seite 46 Relationale Algebra Product Bildet das kartesische Produkt aus zwei Relationen, indem es jedes Tupel der ersten Relation mit jedem Tupel aus der zweiten Relation kombiniert (=alle kombinatorischen Möglichkeiten). Product kann auch auf mehr als zwei Relationen angewandt werden. Syntax: Product (relation1, relation2) r1 r2 Product(r1,r2) a1 a2 a1 a2 A 1 A 1 B 2 A 2 B 1 B 2 C 1 C 2 C René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 47 Relationale Algebra Union Erweitert die Menge der Tupel der ersten Relation um die Menge der Tupel der zweiten Relation (Vereinigungsmenge). Die Ergebnisrelation enthält gleiche Tupel der ersten und zweiten Relation nur einmal. Die Verknüpfung zweier Relationen mit Union ist nur erlaubt, wenn beide Relationen den gleichen Grad besitzen und jedes Attribut der ersten Relation mit dem korrespondierenden Attribut der zweiten Relation kompatibel ist (Union-Kompatibilität). Syntax: Union (relation1, relation2) r1 r2 Union(r1,r2) a1 a2 a3 A D A B E B C C D E René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Relationale Algebra Intersection Ermittelt gleiche Tupel aus zwei Relationen (Schnittmenge). Die Relationen müssen Union-kompatibel sein. Syntax: Intersection (relation1, relation2) r1 r2 Intersection(r1,r2) a1 a2 a3 A A A B D C René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 48 Relationale Algebra Difference Bildet eine Relation, die alle Tupel der ersten Relation abzüglich der Tupel der zweiten Relation enthält. Die Relationen müssen Union-kompatibel sein. Syntax: Difference (relation1, relation2) r1 r2 Difference(r1,r2) a1 a2 a3 A A B B D C C René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 49 Relationale Algebra Join Der Join verbindet zwei Relationen ähnlich wie das kartesische Produkt, allerdings nur für solche Tupel, in der zwei bestimmte Attributwerte in einer gewissen Beziehung zueinander stehen. Man kann auch eine Relation mit sich selbst verknüpfen (Auto-Join oder Self-Join). Anmerkungen Die Attribute, über die der Join ausgeführt wird, müssen keine Schlüsselattribute sein. Die Join-Attribute müssen nicht den selben Namen besitzen. Die Domänen der Join-Attribute müssen gleich sein. Normalerweise ist mit „Join“ der „natürliche“ Join gemeint. Auf den nächsten Folien werden mögliche Joins dargestellt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 50 WI II WS 03/04 Seite 51 Relationale Algebra Theta Join Allgemeinste Form des Joins. Die Beziehung, die die Join-Attribute genügen müssen, stellt einen der Vergleichsoperatoren =, >, <, <=, >=, <> dar. Als Platzhalter wird der griechische Buchstabe Θ (Theta) verwendet. Beide Join-Attribute werden in die Ergebnisrelation mit aufgenommen. Syntax: Join (r1, attributx Θ attributy, r2) r1 r2 Product Join(r1,a2<>a4,r2) a1 a2 a3 a4 a1 a2 a3 a4 a1 a2 a3 a4 A w C y A w C y A w C y B x D z A w D z A w D z C y B x C y B x C y B x D z B x D z C y C y C y D z C y D z René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 52 Relationale Algebra Equi Join Spezialfall des Theta-Join mit dem Vergleichsoperator „=“. Beide Join-Attribute werden in die Ergebnisrelation mit aufgenommen. Syntax: Join (r1, attributx = attributy, r2) r1 r2 Product Join(r1,a2=a4,r2) a1 a2 a3 a4 a1 a2 a3 a4 a1 a2 a3 a4 A w C y A w C y C y C y B x D z A w D z C y B x C y B x D z C y C y C y D z René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 53 Relationale Algebra Natürlicher Join Ein Equi-Join, dessen Ergebnisrelation die beiden Join-Attribute nur einmal beinhaltet. Syntax: Join (r1, attributx = attributy, r2) r1 r2 Product Join(r1,a2=a4,r2) a1 a2 a3 a4 a1 a2 a3 a4 a1 a2 a3 A w C y A w C y C y C B x D z A w D z C y B x C y B x D z C y C y C y D z René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 54 Relationale Algebra Inner Join Die bis hier durchgeführten Joins enthielten nur die Tupel in der Ergebnisrelation, für die ein passender Wert für die JoinBedingung in beiden Relationen vorhanden war. Man spricht hier von Inner Joins. Outer Join Im Gegensatz dazu erzeugt ein Outer Join in der Ergebnisrelation zumindest alle Tupel einer der beiden Relationen. Man unterscheidet Left- und Right-Joins, je nachdem, ob alle Tupel der “linken” bzw. “rechten” Relation aufgenommen werden sollen. Syntax Right-Join: Join (r1, attributx =* attributy, r2) Syntax Left-Join: Join (r1, attributx *= attributy, r2) r1 r2 Join(r1,a2=*a4,r2) a1 a2 a3 a4 a1 a2 a3 a4 A w C y C y C y B x D z ? ? D z C y René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Gliederung 1. Grundlagen 2. Relationales Datenmodell 3. Datenbank-Design 1: Normalisierung 4. Datenbank-Design 2: ERM 5. MS Access Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 55 Datenbankdesign Unter Datenbankdesign versteht man das Aufteilen der Daten in getrennte Relationen, um damit Daten über die reale Welt zu sammeln. Dies erfolgt in zwei Schritten: Logisches Design Definieren der konzeptionellen und externen Ebene des ANSIModells: Logisches Aufteilen der relevanten Attribute in unterschiedliche Relationen. Ziel: Korrektheit der Datenbankoperationen Physisches Design Definieren der internen Ebene des ANSI-Modells: z.B. Auswahl des Datenbanksystems, Aufteilen auf verschiedene Speichermedien. Ziel: Performance und Sicherheit vor Datenverlust Im Weiteren: Logisches Design mit zwei Hilfsmitteln: Normalisierung Entity Relationship Modelling René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 56 Normalisierung Definition Unter Normalisierung wird der Prozess verstanden, der komplexe Beziehungen der Realität in einfache, widerspruchs- und anomaliefreie Relationen überführt. oder Aufteilen der Daten (interessierende Attribute der realen Welt) in Relationen in der Art und Weise, dass sie am Ende den Normalisierungsregeln entsprechen. Wesentliche Ziele Vermeidung von Anomalien Eliminierung von Redundanzen Aufbau eines verständlichen Datenmodells Systematische und intensive Beschäftigung mit Problem René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 57 Normalisierung Unnormalisierte Form (UF) 1. Normalform (1NF) 2. Normalform (2NF) 3. Normalform (3NF) Boyce-Codd-Normalform (BCNF) 4. Normalform (4NF) 5. Normalform (5NF) Anmerkung In der Praxis ist der Normalisierungsprozess meist nur bis zur 3. Ebene relevant. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 58 WI II WS 03/04 Seite 59 Unnormalisierte Form Beispiel Vorgehen Kundenname Adresse Automarke Typ Seriennummer Verkäufer Datum Meier Mondstr. 9 VW Golf 123456 Hansen 02.05.2002 Saturnweg 10 Mini BMW Cooper Z4 789654 456789 Berger Uhlmann 19.06.2003 10.09.2003 Müller Fraunhofer Jupiterstr. 11 VW Golf 321654 Berger 08.03.2003 Fraunhofer Sternenweg 15 Audi A4 258741 Hansen 10.07.2003 Es werden alle problemrelevanten Attribute und Eigenschaften festgestellt und in Tabellenform dargestellt. Eine Relation wird dann als unnormalisiert bezeichnet, wenn in einer Zelle mehr als ein Wert vorkommen kann. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 60 1. Normalform (1NF) Beispiel Definition GESCHÄFTSDATEN KNr Kundenname Adresse ANr Automarke Typ Seriennummer VNr Verkäufer Datum 1 Meier Mondstr. 9 1 VW Golf 123456 1 Hansen 02.05.2002 1 Meier Mondstr. 9 2 2 Müller Saturnweg 10 3 Mini BMW Cooper Z4 789654 456789 2 3 Berger Uhlmann 19.06.2003 10.09.2003 3 Fraunhofer Jupiterstr. 11 4 VW Golf 321654 2 Berger 08.03.2003 4 Fraunhofer Sternenweg 15 5 Audi A4 258741 1 Hansen 10.07.2003 Eine Normalform befindet sich in 1. Normalform (1NF), wenn für jedes Attribut die zugehörige Domäne eine einfache Menge, d.h. eine Menge von atomaren Werten ist. Dies bedeutet, dass sich in jeder Zelle nur ein Wert befinden darf. Es gibt somit keine Wiederholungsgruppen mehr. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt 1. Normalform (1NF) Die Attribute „KNr“, „ANr“ und „VNr“ wurden neu eingeführt, um die Kunden, Autos und Verkäufer klar zu identifizieren. Probleme: Redundanz: Der Kundenname sollte nicht für jeden Zweitwagen nochmals aufgeführt werden müssen. Änderungsanomalie: Zieht der Kunde Meier in eine andere Straße, so sind die Änderungen in mehreren Tupeln durchzuführen. Einfügeanomalie: Ein neuer Verkäufer kann erst dann eingetragen werden, sobald er ein Auto verkauft hat. Es ist ersichtlich, dass es innerhalb der Tabelle verschiedene Sachgebiete gibt, welche unabhängig voneinander existieren können. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 61 2. Normalform (2NF) Definition Eine Relation ist in zweiter Normalform (2NF), wenn sie in 1NF ist und jedes Nichtschlüsselattribut voll vom Primärschlüssel abhängig ist (Volle funktionale Abhängigkeit). Ein Nichtschlüsselattribut darf sich also nicht durch nur einen Teil des Primärschlüssels erklären lassen. Falls ein Primärschlüssel nur aus einem Attribut besteht ist eine Relation in 1NF auch in 2NF. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 62 2. Normalform (2NF) Beispiel Kundenname und Adresse hängen nur von einem Teil des Primärschlüssels ab (KNr). Auch Automarke, Typ und Seriennummer hängen nur von ANr ab und nicht vom ganzen Primärschlüssel. Daher wird der Relationstyp GESCHÄFTSDATEN zur Erreichung von 2NF zerlegt: KUNDEN (KNr, Kundenname, Adresse) AUTOS (ANr, Automarke, Typ, Seriennummer) VERKÄUFE (KNr, ANr, Datum, VNr, Verkäufer) René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 63 WI II WS 03/04 Seite 64 2. Normalform (2NF) Volle funktionale Abhängigkeit GESCHÄFTSDATEN KNr Kundenname Adresse ANr Automarke Typ Seriennummer VNr Verkäufer Datum 1 Meier Mondstr. 9 1 VW Golf 123456 1 Hansen 02.05.2002 1 Meier Mondstr. 9 2 2 Müller Saturnweg 10 3 Mini BMW Cooper Z4 789654 456789 2 3 Berger Uhlmann 19.06.2003 10.09.2003 3 Fraunhofer Jupiterstr. 11 4 VW Golf 321654 2 Berger 08.03.2003 4 Fraunhofer Sternenweg 15 5 Audi A4 258741 1 Hansen 10.07.2003 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 65 2. Normalform (2NF) Beispiel AUTOS ANr KUNDEN Automarke Typ Seriennummer 1 VW Golf 123456 Mondstr. 9 2 Müller Saturnweg 10 3 Mini BMW Cooper Z4 789654 456789 3 Fraunhofer Jupiterstr. 11 4 VW Golf 321654 4 Fraunhofer Sternenweg 15 5 Audi A4 258741 Kundenname Adresse 1 Meier Mondstr. 9 1 Meier 2 KNr Beziehung über Fremdschlüssel VERKÄUFE ANr KNr Datum VNr Verkäufer 1 1 02.05.2002 1 Hansen 1 2 2 3 19.06.2003 10.09.2003 2 3 Berger Uhlmann 3 4 08.03.2003 2 Berger 4 5 10.07.2003 1 Hansen Die Relation VERKÄUFE enthält weitere Redundanzen und Anomalien. Zum Beispiel ist die Aussage, dass „1“ die Nummer von Verkäufer Hansen ist, mehrfach aufgeführt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt 3. Normalform (3NF) Definition Eine Relation ist in dritter Normalform (3NF), wenn sie in 2NF ist und kein Nichtschlüsselattribut transitiv von einem Schlüsselattribut abhängt (Transitive Unabhängigkeit). Alle Nichtschlüsselattribute müssen also wechselseitig voneinander unabhängig sein. Eine Relation in 2NF, die nur ein Nichtschlüsselattribut besitzt, ist somit automatisch auch in 3NF. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 66 WI II WS 03/04 Seite 67 3. Normalform (3NF) Beispiel AUTOS ANr KUNDEN Automarke Typ Seriennummer 1 VW Golf 123456 Mondstr. 9 2 Müller Saturnweg 10 3 Mini BMW Cooper Z4 789654 456789 3 Fraunhofer Jupiterstr. 11 4 VW Golf 321654 4 Fraunhofer Sternenweg 15 5 Audi A4 258741 Kundenname Adresse 1 Meier Mondstr. 9 1 Meier 2 KNr Transitive Abhängigkeit VERKÄUFE ANr KNr Datum VNr Verkäufer 1 1 02.05.2002 1 Hansen 1 2 2 3 19.06.2003 10.09.2003 2 3 Berger Uhlmann 3 4 08.03.2003 2 Berger 4 5 10.07.2003 1 Hansen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 68 3. Normalform (3NF) Beispiel AUTOS ANr KUNDEN Automarke Typ Seriennummer 1 VW Golf 123456 Mondstr. 9 2 Müller Saturnweg 10 3 Mini BMW Cooper Z4 789654 456789 3 Fraunhofer Jupiterstr. 11 4 VW Golf 321654 4 Fraunhofer Sternenweg 15 5 Audi A4 258741 Kundenname Adresse 1 Meier Mondstr. 9 1 Meier 2 KNr Beziehung über Fremdschlüssel VERKÄUFE KNr ANr Datum VNr VERKÄUFER VNr Verkäufer 1 1 02.05.2002 1 1 Hansen 1 2 2 3 19.06.2003 10.09.2003 2 3 2 3 Berger Uhlmann 3 4 08.03.2003 2 4 Kemper 4 5 10.07.2003 1 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Gliederung 1. Grundlagen 2. Relationales Datenmodell 3. Datenbank-Design 1: Normalisierung 4. Datenbank-Design 2: ERM 5. MS Access Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 69 Datenbank-Design Bottom-Up Bis jetzt im Rahmen der Datenmodellierung (so nennt man das logische Datenbank-Design auch) immer zwei Schritte: Auswahl der interessanten Attribute aus Realwelt Kombination der Attribute anhand Normalisierungsregeln zu Relationen Dieses Vorgehen wird Bottom-Up genannt, da man vom elementarsten Level (Attribute) beginnt und bei fertigen Relationen landet. Dieses Vorgehen ist nur dann praktikabel, wenn Attribute und Zusammenhänge sehr genau bekannt sind und eine überschaubare Anzahl an Attributen vorliegt. Dies ist allerdings in der Praxis nur selten der Fall. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 70 Datenbank-Design Top-Down Insbesondere wenn sehr viele Attribute vorliegen, ist es sinnvoller, diese zunächst zu Hauptgruppen wie MITARBEITER, KUNDEN etc. zusammenzufassen (Entitytypen). Im zweiten Schritt werden dann die Beziehungen zwischen diesen festgelegt (Relationshiptypen). Hierbei wird also ein Top-Down-Vorgehen verfolgt, mit den Schritten Festlegen der Entitytypen und Relationshiptypen Definieren der Attribute und der Relationen in der Art, dass sie den Normalisierungsregeln entsprechen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 71 ERM Grundlagen Das Entity-Relationship-Modell wurde in seiner Grundform 1976 von CHEN entwickelt. Es ist ein semantisches Datenmodell, das zur Modellierung konzeptueller Schemata verwendet wird. sehr verbreitet graphische Repräsentation des Schemas René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 72 Begriffe des ERM Entity Ein abgrenzbares und zu beschreibendes Objekt der Miniwelt (z.B. Fa. Meier KG, Schraube_M6*40, Harald Schmidt, ...). Entity-Typ Gleichartige Entities werden zu einem Entity-Typ (Objekttyp) zusammengefasst (z.B. die Lieferanten, die Artikel, die Studenten, ...). Attribute Eigenschaften des Entity-Typs (z.B. besitzt Lieferant die Eigenschaften LiefNr, Name, Anschrift, ...). Entity-Typen werden durch die Zuordnung von Attributen detailliert beschrieben. Attributwerte Mögliche Ausprägungen der Attribute. Die vollständige Menge aller möglichen Werte eines Attributs kann mit einer Wertemenge verglichen werden (z.B. besitzt das Entity Fa. Meier KG die Attributwerte 1, Meier KG, Ingolstadt, ...) René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 73 Begriffe des ERM Relationship Beziehungen (Relations) zwischen Entities, d.h. Verknüpfung von zwei oder mehreren Entities. Z.B. Relation „liefert“: der Entity „Fa. Meier KG“ vom Entity-Typ „Lieferant“ „liefert“ den Entity „Schraube_M6*40“ vom Entity-Typ „Artikel“ (bzw. liefert(Fa. Meier KG, Schraube_M6*40)). Relationship-Typ Gleichartige Beziehungen werden zu Beziehungstypen (Relationship Sets) zusammengefasst. Auch Beziehungen besitzen Attribute (z.B. Attribut „Anzahl der Liefermenge“ der Beziehung „liefert“). Achtung: Einem Entity-Typ müssen, einem Relationship-Typ können Attribute zugeordnet werden. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 74 Richtlinien des ERM Definition Die Struktur aus Entity-Typen, Relationship-Typen und Attributen wird in einem Entity-Relationship-Diagramm (ERDiagramm) graphisch dargestellt. Entity-Typen werden durch Rechtecke, Relationship-Typen durch Rauten, Attribute durch Kreise oder Ellipsen symbolisiert. Die Symbole werden durch ungerichtete Kanten verbunden. Dabei wird jedes Attribut genau einem Entity- bzw. RelationshipTyp zugeordnet. Ein Relationship-Typ wird mit den zugehörigen Entity-Typen verbunden. Aus der Sicht des ER-Diagramms realisiert ein Relationship-Typ eine Beziehung zwischen Entity-Typen. Eine Kante verbindet stets ein Rechteck und eine Raute. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 75 Kardinalität von Beziehungen Kardinalität Gehört zu einem Problemkreis mehr als ein Entity bzw. EntityTyp (und das dürfte in der Realität meist der Fall sein), so sind diese nicht isoliert voneinander zu betrachten, sondern treten zueinander in Beziehung. Beziehungen können zwischen unterschiedlichen Entity-Typen („Lieferant“ „liefert an“ „Kunde“) oder zwischen Entities gleichen Typs bestehen („Person“ „mag“ „Person“). Die Kardinalität (bzw. Komplexität) eines Relationship-Typs gibt an, in welchem Verhältnis die Entities der beteiligten EntityTypen zueinander in Beziehung stehen. Die Kardinalität wird durch Beschriftung der Kanten mit 1, m und n ausgedrückt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 76 Kardinalität von Beziehungen Beziehungstyp (1:1)-Beziehung Beschreibung Einem Entity wir genau ein anderes Entity zugeordnet. Einem Entity werden kein, ein (1:n)-Beziehung oder mehrere andere Entities zugeordnet. n verschiedene Entities werden (n:m)-Beziehung jeweils bis zu m anderen Entities zugeordnet und umgekehrt. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 77 WI II WS 03/04 Seite 78 Grafische Präsentation im ERM Kardinalität RelationshipTyp Entitiy-Typ Angestellte AnNr Name n arbeiten an m Abt Projekte PrNr AnNr Zeit Bez PrNr Attribute René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Dauer Top-Down WI II WS 03/04 Seite 79 Grobes ER-Diagramm Quelle: Stahlknecht, Einführung in die Wirtschaftsinformatik 6.A., S. 199 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Top-Down WI II WS 03/04 Seite 80 Verfeinertes ER-Diagramm Quelle: Stahlknecht, Einführung in die Wirtschaftsinformatik 6.A., S. 199 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 81 ERM - Beispiel 1. Schritt Analyse der Realwelt Die Mitarbeiter eines Unternehmens sind einzelnen Abteilungen zugeordnet, wobei keine Mehrfachzuordnungen vorkommen. Mitarbeiter können gleichzeitig an mehreren Projekten arbeiten, wobei jeweils die prozentuale Arbeitszeit mit erfasst wird. In einem Projekt können auch mehrere Mitarbeiter involviert sein. Jede Abteilung hat genau einen Abteilungsleiter, der sich aus den Mitarbeitern rekrutiert. 2. Schritt ER-Diagramm Entity-Typen: Abteilung, Mitarbeiter, Projekt Relationship-Typen: ist Leiter von (Mitarbeiter arbeitet in (Mitarbeiter Abteilung) Abteilung) ist zugeordnet zu (Mitarbeiter Projekt) Quelle: in Anlehnung an Präsentation von W.-F. Riekert, FH Stuttgart René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 82 ERM - Beispiel 2. Schritt ER-Diagramm Etwas unglücklich n steht für „kein“, „ein“ oder „mehrere“. Abteilung n 1 AbtLeiter Unterstellung 1 n Mitarbeiter n Zugehörigkeit m Projekt René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Ableiten von Tabellen aus ERM 3. Schritt Ableiten von Relationen Als nächster Schritt muss das ER-Diagramm in konkrete Relationen überführt werden (Datendefinition). Aufgabe: Festlegen der einzelnen Tabellen und ihrer Felder Bei der Überführung des ER-Modells in Relationen kann man sich an folgenden Regeln orientieren. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 83 Ableiten von Tabellen aus ERM Regel 1: Jeder Entity-Typ muss durch eine eigenständige Relation (Tabelle) abgebildet werden. Die Attribute des Entity-Typs werden zu Feldern der Tabelle. Primärschlüssel aus Entity-Typ übernehmen. Regel 2: Jeder Relationship-Typ kann durch eine eigenständige Relation (Tabelle) abgebildet werden. Dies hängt von der jeweiligen Kardinalität ab. Die Attribute des Relationship-Typs werden zu Feldern der Tabelle. Primärschlüssel des Relationship-Typs ist oft die Kombination der Fremdschlüssel der zugehörigen Entity-Typen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 84 WI II WS 03/04 Seite 85 Abteilung n 1 AbtLeiter Unterstellung 1 n Mitarbeiter Abteilung AbtNr n Zugehörigkeit Mitarbeiter AbtBez MitNr m Projekt Projekt Name Straße Ort ProNr Inhalt Regel 1: Jeder Entity-Typ muss durch eine eigenständige Relation (Tabelle) abgebildet werden. Ableiten von Tabellen aus ERM René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 86 Abteilung n 1 AbtLeiter Unterstellung 1 n Mitarbeiter AbtLeiter AbtNr Zugehörigkeit n Unterstellung MitNr MitNr AbtNr Projekt m Zugehörigkeit MitNr ProNr %-Zeit Regel 2: Jeder Relationship-Typ kann durch eine eigenständige Relation (Tabelle) abgebildet werden. Ableiten von Tabellen aus ERM René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 87 Ableiten von Tabellen aus ERM Abteilung AbtNr Mitarbeiter AbtBez AbtLeiter AbtNr Konsequenzen MitNr Projekt Name Straße Unterstellung MitNr MitNr AbtNr Ort ProNr Inhalt Zugehörigkeit MitNr ProNr %-Zeit Wenn jeder Relationship-Typ durch eigene Tabelle modelliert wird, ergibt sich daraus eine große Zahl an Tabellen. Es ist jedoch möglich, auf einige Relationship-Typen bei der Datendefinition zu verzichten. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 88 Ableiten von Tabellen aus ERM Regel 3: 1-n-Beziehungen können ohne eigenständige Tabelle modelliert werden. Hierfür wird der Primärschlüssel der Tabelle mit Kardinalität 1 als Fremdschlüssel in die verbundene Tabelle mit aufgenommen. Auch 1-1-Beziehungen können ohne eigenständige Tabelle modelliert werden. Abteilung 1 Unterstellung n Mitarbeiter Beziehung über Fremdschlüssel Abteilung AbtNr AbtBez Mitarbeiter MitNr Name Straße Ort AbtUnter René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 89 Ableiten von Tabellen aus ERM Regel 4: n-m-Beziehungen müssen als eigenständige Tabelle modelliert werden. Primärschlüssel der Relationship-Tabelle ist i.a. die Kombination der beiden Fremdschlüssel. Mitarbeiter n Zugehörigkeit m Projekt Zugehörigkeit MitNr ProNr Mitarbeiter MitNr Name Straße Ort %-Zeit Projekt Beziehung über Fremdschlüssel ProNr Inhalt René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 90 Ableiten von Tabellen aus ERM Ergebnis Mitarbeiter Abteilung AbtNr AbtBez AbtLeiter MitNr Beziehung über Fremdschlüssel Name Straße Ort AbtUnter Projekt Zugehörigkeit MitNr ProNr %-Zeit ProNr Inhalt René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Beziehungen in Access René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 91 Beziehungen in Access René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 92 Gliederung 1. Grundlagen 2. Relationales Datenmodell 3. Datenbank-Design 1: Normalisierung 4. Datenbank-Design 2: ERM 5. MS Access Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 93 Erstellen einer Tabelle Meist: Tabellendefinition in Entwurfsansicht René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 94 Erstellen einer Tabelle René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 95 Felddatentypen Grundsätzlich: Es existiert nicht DER universelle Datentyp. Wahl des Datentyps abhängig vom Zweck. TEXT: Alphanumerische Zeichen (max. 255) Beispiele: Name Telefonnummer (wg. Klammern, führenden Nullen) Postleitzahlen (z.B. D-85049, CH-2345) MEMO: Alphanumerische Zeichen (max. 64.000) Für Bemerkungen, Notizen etc. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 96 Felddatentypen ZAHL: Numerische Werte Feldgröße: Byte (0...256) Integer (-32786...32767) Long Integer (ca. –2 Mrd bis +2 Mrd) Single (–3,4*1038... 3,4*1038, 7 Dezimalstellen) Double (–1,797*10308... 1,797*10308, 15 Dezimalstellen) Beispiele: „normale“ Zahlen Währungen (unterschiedlicher Art) Prozentzahlen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 97 Felddatentypen DATUM/ UHRZEIT: Datum und/oder Uhrzeiten WÄHRUNG Währungsangaben Beispiel: 11.11.2001 14:05:57 Sonderform von Zahl, wird mit Währungszeichen versehen Beispiel: 3.000,47 € AUTOWERT Numerischer, eindeutiger Wert, der von ACCESS automatisch für jeden neuen Datensatz vergeben wird = Automatischer Schlüssel JA/NEIN Boolsche Werte Ja/Nein, Wahr/Falsch René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 98 Felddatentypen OLE-Objekt: Object Linking and Embedding - eine von Microsoft entwickelte Technik, die es erlaubt, Daten aus einem anderen Programm aktiv zu importieren Beispiele: EXCEL-Tabellen, WORD-Briefe, Klänge, Videos etc. Nett, aber oft langsam. HYPERLINK Querverweis zu einer Internet-Adresse oder zu einer Datei NachschlageAssistent Kein Felddatentyp – hiermit wird der Assistent zur Gestaltung von Nachschlagefeldern aufgerufen. Dient zum Erstellen von Feldern, deren Ausprägungen nur bestimmte Werte annehmen können (z.B. Zahlungsart Einzug, Rechnung, Bar) Möglichkeit, Auswahlelemente aus eigener Tabelle/Abfrage zu extrahieren oder als eigene Liste zu definieren Sauberer über Tabelle René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 99 Felddatentypen 1. Schritt Tabelle mit Auswahlelementen definieren 2. Schritt In Basistabelle NachschlagAssistenten aufrufen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 100 Felddatentypen 3. Schritt Der Assistent fragt die Auswahltabelle ab und – falls noch nicht passiert – erstellt automatisch eine Verknüpfung. 4. Schritt Bei der Dateneingabe wird nun in der Datenblattansicht im entsprechenden Feld ein Pull-Down-Menü erzeugt, dass die angegebenen Auswahlelemente umfasst. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 101 Ausgewählte Feldeigenschaften Grundsätzlich: In Abhängigkeit vom ausgewählten Felddatentyp können die Eigenschaften des Feldes festgelegt werden Feldgröße: Legt für Textfelder deren Größe (max. 255 Zeichen) und für Zahlen den erlaubten Wertebereich (z.B. Integer) fest. Format: Mit der Eigenschaft Format können Sie die Darstellung von Zahlen, Datumsangaben, Zeitangaben und Text auf dem Bildschirm und im Ausdruck anpassen. Vordefinierte Formate: z.B. best. Währungen, Prozentzahl, best. Datumstypen Benutzerdefinierte Formate: z.B. können über Platzhalter bestimmte Eingaben erzwungen werden. Dezimalstellen: Legt für Zahlenformate die Anzahl der Nachkommastellen fest. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 102 Ausgewählte Feldeigenschaften Eingabeformat: Definiert Formate, die das Eingeben von bestimmten Werten unterstützen sollen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 103 Ausgewählte Feldeigenschaften Beschriftung: Wird verwendet, falls die Spaltenüberschrift bzw. die Bezeichnungen im Formular von Feldname abweichen sollen. Standardwert: Werte oder Texte, die als Vorgabe in ein best. Feld eingetragen werden. Diese können nachträglich in Tabelle oder Formular verändert werden. Bsp.: Berufsbezeichnung „Student“ bei Nutzerverwaltung der Unibibliothek Gültigkeitsregel: Legt fest, welche Eingaben in ein best. Feld erlaubt sind und welche nicht. z.B.: „>= 0“ bei Zahl der Kinder Gültigkeitsmeldung: Die Fehlermeldung, die erscheint, wenn Werte eingegeben werden, wenn die Gültigkeitsregel nicht eingehalten wird. z.B.: „Sie können nicht weniger als kein Kind haben!“ René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 104 Ausgewählte Feldeigenschaften Eingabe erforderlich: Ist die Eingabe für diese Feld erforderlich? Leere Zeichenfolge: Vereinbart, ob bei Feldern vom Felddatentyp TEXT eine leere Zeichenfolge zulässig ist. Neue Werte: Legt die Art des Felddatentyps AUTOWERT fest, der entweder als augsteigende Nummerierung (Inkrement) oder als zufällige Zahlenfolge (Zufall) definiert werden kann. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 105 Primärschlüssel Generell: Möglichkeiten: Für jede Tabelle muss ein Primärschlüssel definiert werden. Markieren des Felds, dann Über Schaltfläche in Symbolleiste. Über rechte Maustaste. Über Menü „Bearbeiten“ Primärschlüssel René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 106 Dateneingabe Eingabe: Entwurfsfenster schließen. Eingabe entweder über Formulare (kommt später noch) oder über Datenblattansicht. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 107 Tabelleneigenschaften Ergänzung: Auch Tabellen weisen Eigenschaften auf, die spezifisch definiert werden können (z.B. Gültigkeitsregeln). René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 108 WI II WS 03/04 Seite 109 Nacharbeiten LESEN Tabellen Kapitel 9 - 11 René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt Beziehungen zwischen Tabellen Öffnen des Beziehungsfensters Öffnen des Fensters „Tabelle anzeigen“ durch rechten Mausklick im Beziehungsfenster René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 110 Beziehungen zwischen Tabellen Beziehungen herstellen: Um eine Beziehung aufzubauen, klickt man mit der Maus auf das gewünschte Feld der einen Tabelle und zieht bei gedrückter Maustaste zum gewünschten Feld der zweiten Tabelle. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 111 Beziehungen zwischen Tabellen René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 112 Beziehungen zwischen Tabellen Erinnerung Beziehungen zwischen einzelnen Tabellen werden dadurch hergestellt, dass der Primärschlüssel einer Tabelle in die Attributmenge einer anderen Tabellen aufgenommen wird. Der Schlüssel dient dort der Identifizierung von Datensätzen einer „fremden“ Tabelle und wird als Fremdschlüssel bezeichnet. ACCESS ACCESS legt die Beziehungen automatisch fest: Bei 1:n-Beziehungen wird der Tabelle mit dem Primärschlüssel der „1-Teil“ zugewiesen (Mastertabelle), der Tabelle mit dem Fremdschlüssel der „n-Teil“ (Detailtabelle). 1:1-Beziehungen (sehr selten) werden dadurch hergestellt, dass eine Beziehung zwischen zwei Primärschlüsseln definiert wird. m:n-Beziehungen können in ACCESS nicht definiert werden. Auflösung durch zwei 1:n-Beziehungen mit einer dritten Tabelle (siehe Regel 4 in ERM-Kapitel). René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 113 Beziehungen bearbeiten Referentielle Integrität Wenn zwischen zwei Tabellen die „referentielle Integrität“ aktiviert wird, ändert sich das Verhalten der Tabelle beim Löschen und Ändern von Datensätzen. Bei referentieller Integrität können keine Datensätze in die Detailtabelle eingegeben werden, wenn kein entsprechender Datensatz in der Mastertabelle existiert. Auch darf das Feld in der Mastertabelle nicht verändert werden, wenn dadurch in der Detailtabelle „verwaiste“ Datensätze entstehen. René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 114 Beziehungen bearbeiten Referentielle Integrität Mastertabelle Detailtabelle René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 115 Beziehungen bearbeiten Aktualisierungsweitergabe: Eine Änderung des verknüpften Felds in der Mastertabelle wird automatisch für alle verknüpften Datensätze der Detailtabelle weitergegeben. Änderung Mastertabelle Resultat Detailtabelle René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 116 Beziehungen bearbeiten Löschweitergabe: Hierbei werden alle verknüpften Datensätze der Detailtabelle gelöscht, wenn ein Datensatz in der Mastertabelle gelöscht wird. Änderung Mastertabelle Resultat Detailtabelle René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt WI II WS 03/04 Seite 117 WI II WS 03/04 Seite 118 ENDE Viel Erfolg bei den Klausuren! ☺ René Rentzmann, Lehrstuhl für ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt
