Datenbankpraxis mit Microsoft Access. Datenbankpraxis mit Microsoft Access

Transkript

1 Datenbankpraxis mit Microsoft Access Grundlegende Konzepte und ihre Umsetzung in Microsoft Access Vorlesung Januar 2006 Ingo Scholtes Organisatorisches (1/2) Praktische Gruppenarbeit geplant Nächste Vorlesung im Rechnerpool in H423 (Campus II, Hochtrakt, 4. Stock) Vorlesungen heute und am ich Vorlesungen am und Daniel Görgen Klausur , 8:30 12:45 Uhr Tutorium zur Klausur am und

2 Organisatorisches (2/2) Versuch so viele praktische Access Beispiele einzuflechten wie möglich Symbole Wenn s grün wird, wird s praktisch ;-); Vorgefertige Lösung in Access Interaktive Lösung in Access Gruppenübung Jederzeit offen für Kritik und Anregungen Skript der Vorlesung jeweils im Anschluss im Netz verfügbar trier.de/~scholtes Vorlesungsinhalt Grundlagen Flache Datenbanken und ihre Probleme Relationales Datenbankmodell Entity-Relationship Modell Implementierung von E/R Diagrammen Normalformen Referentielle Integrität Access Datentypen Access Feldeigenschaften Access: Datenbanken, Tabellen und Beziehungen 2

3 Literaturhinweise Access Database Design & Programming, 2002, Steven Roman, O REILLY In englischer Sprache Programming Microsoft ACCESS Version 2002, Rick Dobson, Microsoft Press In englischer Sprache Microsoft Access Hilfe Was ist eine Datenbank Eine Datenbank ist eine Menge zusammengehöriger und persistenter Daten 3

4 Was ist ein DBMS? DBMS = DataBase ase Management System Erlaubt Operationen auf Daten Hinzufügen (Insertion) Löschen (Deletion) Ändern (Update) Bietet verschiedene Sichten (Views) auf die Daten an Verfügt über eine möglichst einfache Aufrufschnittstelle für Programme und Menschen Microsoft Access Beispiele für DBMS Microsoft SQL Server mysql Oracle 10g PostgreSQL DB2 Interbase 4

5 Datenbankdesign Frage Wie organisiert man Daten in einer Datenbank? Einfachste Form einer Datenbank Eine einzelne Tabelle Bestehend aus Zeilen und Spalten Benötigt kein spezielles Wissen! einfach zu implementieren flache Datenbank Aber das führt zu verschiedensten Problemen! Flache Datenbanken (1/4) Betrachten sie folgendes Beispiel einer Literaturdatenbank in Microsoft Access Speichern von ISBN, Buchtitel, Klappentext, Erscheinungsdatum, Verlag, Ort des Verlags, Autor, Geburtsort des Autors, Preis, Lieferbarkeit, Gattung Dieses Beispiel wird uns durch die gesamte Vorlesung begleiten 5

6 Flache Datenbanken (2/4) Redundanzproblem Wiederholungen vermeiden Speicherplatzverschwendung Multiple-Value Problem Mehrere Autoren pro Buch? Pro Buch mehrere identische Zeilen mit verschiedenen Autoren Redundanz Mehrere Spalten für f r die verschiedenen Autoren Wieviele Autoren kann es maximal geben? Zum Zeitpunkt des Datenbankdesigns für f r alle Zeiten festgelegt Alle Autoren in einer Zelle Ineffizientes Suchen Aufwendiges Retrieval Flache Datenbanken (3/4) Update Anomalien Mehrere Zeilen für ein Objekt Beim Update müssen alle zugehörigen Zeilen geändert werden Ansonsten Inkonsistenzen Insertion Anomalien Nur Verlag einfügen Noch kein entsprechendes Buch bekannt Was wird dann aus dem Key ISBN? 6

7 Flache Datenbanken (4/4) Deletion Anomalien Alle Bücher eines Verlags löschen? Auch Informationen über den Verlag selbst gehen verloren Nur bestimmte Werte erlauben Nur die Eingabe bestimmter festgelegter Gattungen erlauben? Woraus resultieren diese Probleme? Wir ordnen einem Objekt der realen Welt mehrere Objekte in der Datenbank zu Es gibt nur EINEN Verlag Reclam Redundanz und Update Anomalien Wir ordnen einigen Objekten der realen Welt kein eigenständiges Objekt in der Datenbank zu Verlag existiert nur als Zusatzinformation zu einzelnen Büchern Insertion und Deletion Anomalien 7

8 Zusammenfassung Wir wissen nun allgemein was eine flache Datenbank ist welche Probleme flache Datenbanken mit sich bringen woraus diese Probleme resultieren Für unser Beispiel wissen wir nun, wie wir es NICHT machen sollten! warum wir Access und nicht eine flache Datenbank in Form einer Excel-Tabelle verwenden sollten! Was nun? Wie machen wir es stattdessen? Relationales Datenbankmodell Vorgeschlagen durch Edgar F. Codd im Jahr 1969/1970 Datenbank besteht aus Zweidimensionalen Feldern (Tabellen) Felder bestehen aus Attributen und Tupeln Relationen Beziehungen zwischen Tabellen Werden selbst in Tabellen gespeichert 8

9 Das Entity-Relationship Modell Abstraktes Modell zum Entwurf relationaler Datenbanken Durch E-R-Diagramme E visualisierbar Durch relationale Datenbank implementierbar Es folgen einige Begriffsdefinitionen Begriffsglossar (1/5) Entity Ding/Gebilde der realen Welt Im Beispiel? Konkrete Ausgabe eines Buches Faust Die Person Johann Wolfgang von Goethe Der Verlag Reclam Die Gattung Roman Entity-Klasse Abstrakte Gruppe aller möglichen Entities Im Beispiel? Bücher, Autoren, Verlage, Gattungen Entity ist konkrete Ausprägung einer Entity-Klasse 9

10 Attribut Begriffsglossar (2/5) Eigenschaft die eine Entity entweder teilweise oder vollständig beschreibt Im Beispiel? Name eines Autors Titel eines Buchs Name eines Verlags Eine Entity Klasse die ist abstrakte Beschreibung aller Attribute Begriffsglossar (3/5) Entity-Set Menge von Entities einer gegebenen Entity-Klasse, die sich aktuell in der Datenbank befinden Superkey Beliebige Menge von Attributen einer Entity-Klasse, die eine Entity eindeutig identifiziert Wichtig: Gegenüber ALLEN möglichen Entities einer Entity-Klasse (nicht nur des Entity-Sets) Key Minimaler Superkey Im Beispiel? ISBN identifiziert eindeutig ein Buch Primary Key Tatsächlich benutzter Key, falls mehrere zur Auswahl stehen 10

11 Begriffsglossar (4/5) Tabelle Zweidimensionales Feld von Attributwerten Spalte ist eine Menge von Werten für ein vorgegebenes Attribut Zeile ist Menge von Attributwerten für eine bestimmte Entity Tabellenschema Menge aller Attributnamen für eine Entity-Klasse Im Beispiel: (ISBN, Autor, Titel, Klappentext, Geburtsort, ) Relationale Datenbank Endliche Menge von Tabellen Begriffsglossar (5/5) Relationship Beziehung zwischen Entity-Klassen Verschiedene Relationship-Typen 1-to-11 (1:1) 1-to-Many (1:n) Many-to to-many (n:m) isa (ähnlich 1:1) 11

12 Beispiele für Relationships (1/2) 1-to-Many (1:n) Ein einzelner Mitarbeiter kann mehrere Projekte leiten aber jedes Projekt hat nur einen Projektleiter Many-to to-many (n:m) Ein einzelner Mitarbeiter kann an vielen Projekten arbeiten und an einem einzelnen Projekt können viele Mitarbeiter arbeiten Beispiele für Relationships (2/2) 1-to-11 (1:1) Ein Projektleiter hat genau einen Dienstwagen Jeder Dienstwagen wird von genau einem Projektleiter gefahren Sehr selten isa Projektleiter ist ein Mitarbeiter, erbt also alle Mitarbeiter-Attribute, hat aber zusätzlich ein Dienstwagenattribut Spezialfall von 1-to1 to-1 Im Datenbankdesign ebenfalls sehr selten 12

13 E-R-Diagramme Visuelle Darstellung eines E/R Modells 1976 von Peter Chen entwickelt Verschiedene Notationen Wir verwenden hier die sogenannte Chen-Notation Symbole (Many-to to-many und 1-to1 to-1 Relationship analog) Ort 1 wurde geboren in/ Ist Geburtsort von Mitarbeiter 1 isa 1 Projektleiter Entity-Klasse Person Land Name Einwohner Key Attribut Vorname Ausweisnr. Nachname Gruppenübung: Entity-Relationship Diagramm Erstellen sie ein Entity-Relationship Relationship- Diagramm für unser Literaturverwaltungs- beispiel, damit wir dieses anschließend in Access implementieren können! 13

14 Zur Erinnerung Mitarbeiter 1 isa 1 Projektleiter Relationship Entity-Klasse Ort 1 wurde geboren in/ Ist Geburtsort von Person Land Einwohner Attribut Vorname Nachname Name Key Ausweisnr. Ort VerlagID Verlage Lösungsvorschlag Name gehört zu/ enthält 1 Literaturgattungen 1 verlegt/ wird verlegt von GattungID Gattung Bücher geschrieben von/schreibt Autoren ISBN Erscheinungsdatum Klappentext Preis AutorID Name Titel Geburtsort 14

15 Zusammenfassung Wir wissen nun allgemein wie man E-R-Modelle E nutzen kann um eine Datenbank sorgfältig zu planen wie man diese Modelle mit E-R-Diagrammen E anschaulich machen kann Für unser Beispiel haben wir ein gutes Datenbankdesign mit Hilfe eines E-R-Diagramms E erreicht Was nun? Wie setzen wir ein solches E-R-Diagramm E in eine relationale Datenbank um? Implementierung von E-R E Diagrammen Verläuft ähnlich einem Kochrezept Ist daher einfach und immer wieder gleich anwendbar auf beliebiges E-R E R Diagramm Entity-Klasse Entwurf einer Tabelle Definition der zugehörigen Attribute als Felder/Spalten der Tabelle 15

16 Implementierung 1-to1 to-many Relationship Durch sogenannte Foreign Keys Füge Key fremder Entity Klasse zu Tabellenschema hinzu Eindeutigkeit des Keys spezifiziert eindeutig eine Entity in fremder Tabelle Wert eines Foreign Keys ist eindeutige Referenz zu einem Eintrag in fremder Tabelle Key Attribut A B C Foreign Key Key 1 2 Attribut X Y Implementierung: 1-to1 to-1 Relationship Im Kontext von Datenbanken wie gesagt eher selten Spezialfall von 1-to1 to-many Implementierung ebenfalls mit Foreign Key Gilt natürlich auch für isa Relationships 16

17 Implementierung Many-to to-many Relationship (1/3) Erste (schlechte!) Idee Einfaches Einfügen von Foreign Keys wie bei One-to to-many Beispiel: Relationship Autoren und Bücher Dank Foreign Key kann wie bei der 1:n Beziehung Verlag Bücher ein Autor viele Bücher referenzieren Nun muss aber zusätzlich ein Buch viele Autoren referenzieren! Dazu benötigt man wieder mehrere Zeilen Probleme: Wiederum Redundanz Update Anomalie Tabelle Bücher (mit Foreign Key AutorID) ISBN kla1 str1 kla1 AutorID Titel Unser Leben Unser Leben Mein Leben Tabelle Autoren AutorID kla1 str1 Autor Klawuppke Strunz kla1 Str1 Implementierung von Many-to to- Many Relationships (2/3) Lösung Aufbrechen einer Many-to to-many in zwei 1-to1 to-many Relationships Definition einer neuen Entity-Klasse Autoren/Bücher In der Implementierung entsteht dadurch eine neue Tabelle Tabelle Autoren AutorID Name Strunz Klawuppke ISBN Tabelle Bücher Titel Unser Leben Mein Leben Tabelle Autoren/Bücher (Foreign Keys AutorID und ISBN) AutorID kla1 kla1 str1 ISBN

18 Implementierung von Many-to to- Many Relationships (3/3) Im Diagramm A B A 1 1 A/B B Üblicherweise wird im Diagramm aber trotzdem eine Many-to to-many Beziehung verwendet! Ein anschauliches Beispiel 18

19 Daraus wird dann Dummy-Entity-Klasse 1 1 Exkurs: Normalformen (1/5) Ziel: Redundanz wann immer möglich vermeiden Leider nicht immer so einfach wie im Beispiel Einteilung von Attributen: Reine Identifikation Tauchen nur im Key auf und tragen ansonsten keine Information Z.B. AutorID Reine Information Tauchen nicht im Key auf Z.B. Titel Mischformen Z.B. ISBN 19

20 Exkurs: Normalformen (2/5) Verschiedene Normalformen Eigentlich nicht Teil dieser Vorlesung! Erste Normalform (1NF) Zweite Normalform (2NF) Dritte Normalform (3NF) Boyce Codd Normalform (BCNF) Vierte Normalform (4NF) Fünfte Normalform (5NF) Zunehmend schärfere Bedingungen 3NF ist immer erreichbar Es folgt ein kleiner Exkurs Exkurs: Normalformen (3/5) Erste Normalform Tabellenschema ist in 1NF, falls ein Attributwert untrennbar ist Gegenbeispiel: Mehrere Autoren in einer Zelle! Unsere erste flache Lösung ist bereits in 1NF, da wir mehrere Zeilen für mehrere Autoren verwendet haben Hätten wir nur eine Zeile pro Autor verwendet wäre dies nicht der Fall! 20

21 Exkurs: Normalformen (4/5) Zweite Normalform (2NF) Tabellenschema ist in 2NF, falls alle Attribute mit reinem Informationscharakter zur Entity des entsprechenden Tabellenschemas gehören Gegenbeispiel Tabellenschema mit: (ISBN, Titel, Autor, Geburtsort Autor) ISBN, Titel gehören zu Buch Entity Geburtsort Autor gehört zu Autor Entity und hat reinen Informationscharakter Dadurch enstehen wieder Redundanzen! Exkurs: Normalformen (5/5) Dritte Normalform (3NF) Tabellenschema ist in 2NF und zusätzlich gibt es keine sogenannten transitiven Abhängigkeiten, d.h. Attribute mit reinem Informationscharakter hängen nur von Superkey ab! Gegenbeispiel: Preis eines Buches hänge nun nur vom Verlag und von der Seitenzahl des Buchs ab! Tabellenschema mit (ISBN, VerlagID, Seitenzahl, Preis) Preis ist transitiv (über VerlagID) von Seitenzahl abhängig, d..h h es gilt nicht ISBN Preis sondern (Seitenzahl, VerlagID) Preis Erzeugt wieder Redundanz! Attribut Preis hängt nicht nur von Superkey (ISBN) ab, sondern auch von Seitenzahl! Weiterführende Informationen zu weiteren NF (nicht relevant für diese Vorlesung) siehe z.b. _%28Datenbank%29%29 21

22 Probleme relationaler Datenbanken Kein Modell ist perfekt Auch relationale Datenbanksysteme haben ihre Probleme Referentielle Integrität Löschen z.b. eines Verlags? Dieser wird aber in Tabelle Bücher noch referenziert Dangling Reference Zerstückelung von Daten Um zum Beispiel alle Dramen des Reclam-Verlags unter 5 Euro zu finden müssen Daten aus verschiedenen Tabellen zusammengeführt werden Nämlich aus den Tabellen Bücher, Verlage und Gattungen Referentielle Integrität Wie kann man referentielle Integrität erhalten? Dangling References bei Updates, Deletes und Insertions Lösungsvorschläge? Datenbank kann bei Insert prüfen ob Foreign Key existiert Updates / Deletions verbieten Cascading Updates Bei Änderung des Foreign Keys ändere automatisch referenzierten Key Cascading Deletions Bei Löschung einer Entity lösche automatisch alle Entities die diese referenzieren 22

23 Gruppenübung: Implementierung eines E-R E R Diagramms Geben Sie nun zum in der vorherigen Aufgabe erstellten E-R E R Diagramm eine Implementierung in Form von Tabellenschemata an! Verwenden Sie dazu die eben besprochenen Strategien für die verschiedenen Formen von Relationships! Hier nochmal das E-R E R Diagramm Ort VerlagID Verlage 1 veröffentlicht Bücher Name geschrieben von enthält 1 GattungID Literaturgattungen Autoren Gattung ISBN Erscheinungsdatum Klappentext Titel Preis AutorID Geburtsort Name 23

24 Lösungsvorschlag Tabelle Bücher (ISBN,, Titel, Klappentext, VerlagID, Preis, GattungsID) VerlagID und GattungsID sind Foreign Keys Tabelle Verlage (VerlagID,, Name, Ort) Tabelle Autoren (AutorID,, Name, Geburtsort) Tabelle Autoren/Bücher (AutorID, ISBN) Zum Aufbrechen der Many-to to-many Relationship Tabelle Gattungen (GattungsID,, Gattung) Zusammenfassung Wir wissen nun allgemein wie man Entities und die verschiedenen Relationships in relationalen Datenbanken umsetzt welche Probleme relationale Datenbanken haben wie man mit diesen Problemen umgeht Für unser Beispiel haben wir eine Implementierung in Form eines relationalen Datenbankmodells gefunden Was nun? Wie setzen wir dieses nun konkret in Access um? 24

25 Microsoft Access Wir haben alle theoretischen Grundlagen beisammen Relationales Datenbankmodell ist fertig Nun geht s an die Umsetzung unserer Vorarbeiten mit Microsoft Access Dazu zunächst eine kurze grundlegende Einführung MS Access: Grundlagen Access ist Datenbanksystem zur Verwaltung und Entwicklung von Datenbankanwendungen Unterstützt das ausführlich besprochene relationale Datenbankmodell Die Grundkonzepte relationaler Datenbanken lassen sich einfach wiederfinden Datenbank Tabelle Beziehungen 25

26 MS Access: Grundlagen MS Access: Einfache Datentypen Jedes Attribut ist als string (Zeichenkette, Text) serialisierbar Warum also weitere Datentypen? Rechnen mit Zahlen Datumsangaben mit einheitlichem Format Effizienz Beispiel: Speichern der Zahl 255 Komfort als string bytes als byte nur 1 byte 26

27 Anwendung Datentyp: Text Atttribute die keine Berechnung erfordern Text, Titel, Kombination aus Text und Zahlen Bspw. auch Telefonnummern und PLZ Speicherplatz Der durch Feldgröße festgelegte Wert, maximal aber 255 Zeichen Anwendung Längere Texte Speicherplatz Datentyp: Memo Maximal Bytes (64KB (64KB-11 Byte = Bytes) 27

28 Anwendung Datentyp: Zahl Numerische Werte, die für mathematische Berechnungen genutzt werden Je nach Feldgröße unterschiedlicher Wertebereich (byte, smallint, int, largeint) Speicherplatz 1,2,4 oder 8 Bytes je nach Feldgröße Datentyp: Datum und Uhrzeit Anwendung Datum und Zeit für die Jahre Speicherplatz 8 Byte 28

29 Anwendung Datentyp: Währung Währungswerte, auf bis zu 15 Stellen links und 4 Stellen rechts vom Komma genau Kann automatisch Währungssymbol enthalten Speicherplatz 8 Byte Anwendung Datentyp: Autowert Fortlaufende ganze Zahl, die mit jedem neuen Datensatz um 1 erhöht wird Ist garantiert eindeutig Besonders geeignet für Keys Speicherplatz 4 Byte 29

30 Anwendung Datentyp: Ja/Nein Äquivalent zu boolean-typ in Programmiersprachen alles was entweder wahr/falsch, ja/nein, an/aus sein kann Speicherplatz 1 Bit NULL Werte NULL ist spezieller Wert der angibt, dass Ein Wert fehlt oder unbekannt ist Sinnvolle Richtlinen Entity Integrität Keine NULL Werte in Primary Keys! Referentielle Integrität NULL Werte als Foreign Key erlaubt Jeder von NULL verschiedene Wert eines Foreign Keys muss aber in referenzierter Tabelle existieren 30

31 MS Access: Feldeigenschaften Zu jedem Attribut/Feld können abhängig vom Datentyp zusätzliche Eigenschaften festgelegt werden Feldgröße Gültig für Datentypen Text, Zahl, AutoWert Text Legt Anzahl der Zeichen fest Zahl, AutoWert Bytegröße 31

32 Eingabeformat (1/2) Gültig für Datentypen Text, Zahl, Datum/Uhrzeit, Währung Muster für alle Eingaben die in Feld eingegeben werden Vorgegebene Eingabeformate Eingabeformat (2/2) Manuelle Definition Syntax wird in Access Hilfe erklärt Beispiele Telefon, PLZ, KFZ-Kennzeichen, Kennzeichen, E 32

33 Format Gültig für alle Datentypen außer OLE-Objekt Objekt Format im Sinne von Ausgabeformat Vordefinierte Formate Währung Verschiedene Datumsformate Zahlformate Ja/Nein, Ein/Aus Selbstdefinierte als Platzhalter für Zeichen des Datenfelds Genaue Syntax in Access Hilfe Dezimalstellenanzeige Gültig für Datentypen Zahl, Währung Anzahl der Dezimalstellen die rechts vom Trennzeichen angezeigt werden Wert vorgeben Automatisch 33

34 Beschriftung Gültig für alle Datentypen Zusätzliche Bezeichnung für Attribut Standardmäßig wird Attributname verwendet Tipp Kurze Attributnamen Ausführlichere Beschriftungen Standardwert Gültig für Datentypen Text, Memo, Zahl, Währung, Datum/Uhrzeit, Ja/Nein, Hyperlink Der Wert den ein Attribut standardmäßig haben soll falls kein Wert eingegeben wird 34

35 Gültigkeitsregel Gültig für Datentypen Text, Memo, Zahl, Währung, Datum/Uhrzeit, Ja/Nein, Hyperlink Der eingegebene Wert eines Attributs muss dieser Regel genügen Definition mittels Ausdrucksgenerator Funktionen Konstanten Operatoren Gültigkeitsmeldung Gültig für Datentypen Text, Memo, Zahl, Währung, Datum/Uhrzeit, Ja/Nein, Hyperlink Meldung die gezeigt wird, falls Gültigkeitsregel verletzt wird 35

36 Eingabe erforderlich Gültig für alle Datentypen, außer AutoWert Falls Ja erzwingt Access die Eingabe eines Werts für dieses Feld Indiziert Gültig für alle Datentypen außer OLE- Objekt Falls Ja werden Abfragen und Sortierungen nach diesem Attribut beschleunigt Updates werden allerdings langsamer! 36

37 Exkurs: Indizes (1/2) Wozu Indizierung? Wie sucht ein DBMS nach Daten? Sequentiell? Suchen Sie die Zahl 42!! Wo fällt Ihnen das leichter? oder DBMS hält eine sortierte Teilmenge der Daten (den Index) im (schnellen) RAM und kann sich dadurch sequentielle Suche auf (langsamer) Platte ersparen! Exkurs: Indizes (2/2) Sortierung und Suche sehr schnell dafür werden Updates aufwendiger Denn: Wo können Sie die 43 einfacher einfügen? oder

38 Smarttags Neu in Microsoft Office XP Ermöglicht Einbindung von zusätzlicher Funktionalität von Drittanbietern Beispiel gefällig? MS Access: Komplexe Datentypen Neben den bereits besprochenen einfachen Datentypen gibt es auch noch komplexere 38

39 Exkurs: OLE OLE = Object Linking and Embedding Objektverbindung und einbettung Microsoft Standard zum Austausch von Objekten in Dokumenten Beispiel Bilddatei aus Paint in Word Excel-Sheet in Word Word-Dokument in Access Einfügen als Referenz auf Originaldatei (Linking) Kopie (Embedding) Anwendung OLE Dokumente aus anderen Anwendungen in Access Datenbanken Speicherplatz Variabel Bis maximal 1 GB 39

40 Anwendung Hyperlink Text mit Zusatzinformation, dass es sich dabei um einen Hyperlink handelt. Besteht aus drei Teilen Angezeigter Text Hyperlink Unterlink Speicherplatz Bis zu 2048 Bytes pro Teil Anwendung statisch dynamisch Nachschlageassistent Vereinfachung einer 1:n Beziehung Erzeugt ein neues Feld mit Foreign Key Erstellt die entsprechende Beziehung Beispiel: Berufsbezeichnungen aus separater Tabelle Speicherplatz Je nach Anwendung Normaler Foreign Key (Zahl-Attribut) 40

41 Gruppenübung: Datentypen Bestimmen Sie für alle Attribute unserer Beispieldatenbank den korrekten Felddatentyp in Microsoft Access. Überlegen Sie sich auch, welche Feldeigenschaften (z.b. Gültigkeitswerte, Standardwert und Gültigkeitsmeldungen) definiert werden sollten. Nutzen sie (wo sinnvoll) auch komplexe Datentypen! Hier nochmal die Tabellenschemata Tabelle Bücher (ISBN,, Titel, Klappentext, VerlagID, Preis, GattungsID) VerlagID und GattungsID sind Foreign Keys Tabelle Verlage (VerlagID,, Name, Ort) Tabelle Autoren (AutorID,, Name, Geburtsort) Tabelle Autoren/Bücher (AutorID, ISBN) Zum Aufbrechen der Many-to to-many Relationship Tabelle Gattungen (GattungsID,, Gattung) 41

42 ISBN (Key) Text, Eingabe erforderlich Titel Text, Eingabe erforderlich Gattung Nachschlageassistent, separate Tabelle Gattungen Klappentext Memo VerlagID Nachschlageassistent, separate Tabelle Verlage Preis Währung, >0 und <1000 Verfügbarkeit Ja/Nein Lösungsvorschlag Autorname GattungsID (Key) Text, Eingabe AutoWert erforderlich Gattung AutorID (Key) Text Autowert Geburtsort Text, Standard NULL Verlagsname Text, Eingabe erforderlich Verlagsort Text, Standard NULL VerlagID (Key) AutoWert Zusammenfassung Wir wissen nun allgemein welche Felddatentypen und Feldeigenschaften es gibt wie und wozu man diese verwenden kann Für unser Beispiel haben wir für unser relationales Datenbankmodell alle Felddatentypen und eigenschaften bestimmt Was nun? Wie erzeugen wir nun konkret die Datenbanken und Tabellen? 42

43 Das war s für heute Danke für Ihre Aufmerksamkeit! Nächste Vorlesung am 13. Januar :15 Uhr in H423 H-Gebäude an Campus II Vorlesungsskript und Beispiele trier.de/~scholtes 43