Ein Datenmodell ist ein Gestaltungsrahmen (Meta
Werbung
Ein Datenmodell ist ein Gestaltungsrahmen (Meta-Modell) zur Modellierung konkreter Schemata. Es legt fest: - die verfügbaren Arten von Objekttypen (Gegenstands-Objekttypen und BeziehungsObjektypen) - die verfügbaren Arten von Beziehungen zwischen Objekttypen - die Semantik von Objekttypen und Beziehungen - syntaktische Regeln für die Kombination von Objekttypen durch Beziehungen - die verfügbaren modellspezifischen sowie die Arten von schemaspezifischen Integritätsbedingungen Ein Datenbankmodell ist ein Datenmodell zur Modellierung konkreter Datenbankschemata, welches von Datenbankverwaltungssystemen unterstütz wird. Das Relationenmodell ist ein Referenzmodell für theoretische Untersuchungen. Es ist geeignet zur Modellierung konzeptueller Datenbankschemata sowie externer Datenbankschemata. Durch das Relationenmodell ist eine hohe Datenunabhängigkeit erreichbar. Der Datentyp Relation besteht aus dem Datenobjekttyp und den darauf definierten Operatoren. Er besteht aus: - Typvereinbarungen o Attribut o Attributmenge o Relationstyp - Wertebereiche o Wertebereiche des Attribut o Attributwert eines Attributs o Wertebereich der Attributmenge o Wertebereich eines Relationstyps - Datenobjekte o Relationsvariable Ein Datenbankschema ist gemäß dem Relationenmodell beschrieben, wenn - Das Schema besteht aus einer Menge benannter Relationstypen RT(A) in erster Normalform - Zu jedem Relationstyp RT(A) existiert genau eine Relationsvariable RV(A), deren Wert eine zeitlich veränderliche Relation R(A) ist - Zu jedem Relationstyp RT(A) existieren ein oder mehrere Schlüssel K. Einer der Schlüssel wird als Primärschlüssel PK ausgezeichnet. - Entity integrity rule: Für die Attributwerte eines Schlüssels ist der Nullwert nicht zugelassen. - Beziehungen zwischen Relationstypen werden mit Hilfe von Fremdschlüsseln realisiert - Auf dem Schema sind die Operatoren der Relationenalgebra definiert. o Vereinigung o Differenz o Projektion o Selektion o Kartesisches Produkt Relation KUNDE(Nr,Name,PLZ,Ort) Eigenschaften von Relationen: - Mengeneigenschaft von Relationen: Relationen sind Mengen. Jedes Element einer Relation ist anhand seiner Attributwerte identifizierbar. - Mathematische Zugänglichkeit: durch die Operatoren auf Relationen entsteht eine Relationenalgebra, mit deren Hilfe präzise Aussagen über die Datenmodellierung mit Relationen abgeleitet werden können. - Vertauschbarkeit von Zeilen, da diese Elemente einer Menge sind - Vertauschbarkeit von Spalten, da jede Spalte über ihren eindeutigen Attributnamen identifizierbar ist - Beliebige Vorgänger-/ Nachfolgerbeziehungen - Datenunabhängigkeit - Datenverwaltung Funktionen eines DBVS: 1. Datenbankmanipulation: Einfügen, Löschen, Ändern, Auffinden in einer Datenmanipulationssprache DML 2. Strukturdefinition: Beschreibungselemente für Datenobjekttypen, Beziehungen zwischen diesen, Konsistenzbedingungen in einer Datendefinitionssprache DDL 3. Sicherung der Unverletzlichkeit der Datenbasis a. Datensicherung: physische Zerstörung, Möglichkeit der Rekonstruktion b. Transaktionsverwaltung: i. Schutz der Datenbasis vor Inkonsistenz ii. Transaktionskonzept ACID: 1. Atomarität: bis zum erfolgreichen Abschluß keine Wirkung nach Außen 2. Konsistenz: garantiert die Konsistenz der Datenbasis 3. Persistenz: Wirkung einer erfolgreich abgeschlossenen Transaktion ist dauerhaft c. Datenschutz vor missbräuchlicher Verwendung, Verwaltung von Zugriffsrechten 4. Organisation des Mehrbenutzerbetriebs 5. Leistungssteuerung, anpassbar bezüglich: a. Antwortzeitverhalten b. Größe der Datenbasis c. Arten von Transaktionen d. Anzahl paralleler Benutzer e. Ausfallsicherheit Maßnahmen: a. Anlegen von Zugriffspfaden b. Verteilung der Datenbasis auf Datenträger c. Datensicherungsstrategien d. Speicherungsverfahren 6. Realisierung von Benutzerschnittstellen für a. Datenbankadministrator b. Sachbearbeiter c. Programmierer Bearbeitung der Anfrage SELECT Titel FROM Buch WHERE Autor=Date - Überprüfung der Syntax Feststellen, ob Buch definiert ist in der DB, bestehen Leserechte Welche Operationen zur Beantwortung der Anfrage Erstellen eines Programms zur Berechnung Zugriff auf den Operanden in der DB Selektion der spezifizierten Informationen Sicherstellen, dass nicht durch einen anderen Nutzerauftrag verändert wird Funktionsmodell eines DBVS: 1. Ebene: a. b. c. d. 2. Ebene: a. b. c. d. e. 3. Ebene: a. 4. Ebene: a. b. c. 5. Ebene: a. b. Input/ Output-Prozessor Parser (Syntaxanalyse) Precompiler (Vorübersetzen) Autorisierungskontrolle Update Prozessor Query Prozessor Integritätsprüfung Zugriffsplanerstellung Optimierer Code Erzeugung Transaktionsverwaltung Scheduler Recovery-Manager Buffer-Manager Data-Manager Ein Datenbankverwaltungssystem beschreibt das System der abstrakten Maschine (Benutzer- Basismaschine), jede Maschine bietet dabei eine Schnittstelle in Form einer Menge von Funktionen an. Es gibt dabei zwei verschiedene Architekturmodelle. Ziele sind: - Datenunabhängigkeit - Strukturierung - Anpassbarkeit - Portierbarkeit 3-Ebenen-Architekturmodell beschreibt die Benutzersicht des DBVS: 1. Externe Ebene: Anwendungsspezifische Benutzersichten => externe Schemata (View-Schemata) 2. Konzeptuelle Ebene: Integrierte Gesamtsicht => Ebene des Datenbankschemas 3. Interne Ebene: Implementierungssicht => Ebene des internen Datenschemas Aufgabe der einzelnen Schichten ist die Transformation zwischen benachbarten Ebenen. 5-Schichten-Architekturmodell beschreibt die Entwicklersicht eines DBVS: Schichten 1: - Schnittstelle Mengenorientierte Schnittstelle: Was statt wie Es werden stets Mengen von Objekten betrachtet, nicht einzelne Objekte Nichtprozedurale Hochsprachenschnittstelle Zugriffsabbildung Zugriffsoptimierung Satzorientierte Schnittstelle: Prozedurale Programmiersprachenschnittstelle Zu jedem Zeitpunkt wird genau ein Objekt betrachtet 2: - Satzgruppierung Wahl der Zugriffsmethode Interne Satzschnittstelle: Kein Bezug zu Datenbankmodellen vorhanden Gruppierung von Sätzen Zugriffspfade zu den einzelnen Sätzen 3: - Satzspeicherung Realisierung der Zugriffspfade Segmentschnittstelle: Realisierung eines virtuellen, homogenen und linearen Speichers (virtuell, feste Größe, linearer Adressraum) 4: - Systempufferverwaltung Seitenadressierung Dateischnittstelle: Geräteorientierte Speichereinheiten: Blöcke und Dateien 5: - Dateiverwaltung Speicherabzug Geräteschnittstelle: vorgegeben durch die verwendeten physischen Geräte Die Aufgaben der 5 Schichten bestehen in der Transformation zwischen der eigenen und der höheren Schnittstelle. ADK ó 3 Ebenen Modell: - A setzen auf 3. Ebene auf - 3 Ebenen ist komplett im D-Teil ADK ó 5 Schichten Modell: - jede Schicht ist Nutzer-Basis-Darstellung - tritt nur im D-Teil auf Architektur verteilter Datenbankgestützter Anwendungssysteme Kommunikation Anwendungsteil Systemsoftware Datenverwaltung Nutzermaschinen Basismaschinen Zusätzliche Einbindung des C-S-Prinzips: K A SQL-Anfrage Datenverwaltungsteil Cursorverwaltung Ergebnis SQL-Maschine Client Server Client-Server-Architekur: Ein oder mehrere Server erbringen Leistungen (Dienste) für einen oder mehrere Clients. 1. K-Client mit AD-Server: Kommunikation der Clients führt über Kommunikationssystem zu Anwendungsfunktionen und Datenverwaltung auf den Servern. 2. KA-Client mit D-Server: Kommunikation und Anweungsfunktionen bei Clienten führen über Kommunikationssystem zu Datenverwaltung bei Servern 3. KA-Client mit AD-Server: Kommunikation und Anwendungsfunktionen bei Client führt über Kommunikationssystem zu lernendem Server mit Anwendungsfunktionen und Datenverwaltung. 4. Client Interface und dedizierte Server: Das Client Interface arbeitet allein auf dem Kommunikationssystem und führt auf den Servern alle 3 Kommunikation, Anwendungsfkt. Und Datenverwaltung aus. K: UIMS A: AppLib D: DBVS Die Relationenalgebra (ist prozedural) besteht aus folgenden Operatoren: - Mengenoperationen - Selektion - Projektion - Verbund Relationenkalkül: - Anfrage besteht in der Definition einer Relation , abgeleitet aus den vorhandenen Basisrelationen - Relation wird mit Hilfe der Prädikatenlogik 1.Stufe über Attributen beschrieben Modellspezifische Integritätbedingungen: Entityintegrität: CREATE TABLE HAUS (NAME CHAR(8) NOT NULL, NUMMER SMALLINT NOT NULL, … PRIMARY KEY (NUMMER)); Referenzintegrität wird durch FOREIGN KEY realisiert: ... (s.o.) FOREIGN KEY (STR) REFERENCES TELBUCH); Relation: Haus (Name,Nr., Anschrift, Lage) Auswahl: SELECT FROM WHERE Name Haus Lage=gut; Wertebereich Definitionsbereich Änderung von Basistabellen: ALTER TABLE HAUS MODIFY (NAME CHAR(5)); Oder: ALTER TABLE HAUS ADD (SALE CHAR(1)); DDL: Datendefinitionssprache DML: Datenmanipulationssprache SQL: - Abbildungsorientiert: f:x => y (Abbildungsvorschrift: Definitionsbereich auf Wertebereich - Spalten: zeitlich veränderliche Multimenge von Werten, alle Werte einer Spalte sind Elemente einer Domain - Tabellen: zeitlich veränderliche Multimenge von Zeilen, z.B. Viewtabelle Tabellen (Relationen) sind zeitlich veränderliche Multimengen von Zeilen. Es gibt: - Basistabellen (persistente Basistabelle) - Viewtabellen (Viewdefinition) - Abgeleitete Tebellen (durch Auswertung erzeugt) Integritätsbedingungen dienen der Definition gültiger Datenbankzustände durch Einschränkung der möglichen Datenbankzustände. Überprüfung der Ibedigungen findet: - Immediate (nach jedem SQL-Statement) - Deferred (nach jeder SQL-Transaktion) Statt. Es gibt folgende Formen der Ib: - table constraint - domain constraint - assertion Die Integritätsbedingungen sind: - schemaspezifisch - syntaktisch und semantisch (korrekte Daten eingegeben) - statische und dynamische - operationale (Synchronisation der Transaktionen) - operative: Zugriffssteuerung und Konsistenzerhaltung der Datenbasis (recovery) Die Entity-Integrität wird durch die PK-Beziehung (ungleich 0, Eindeutigkeit), die referenzielle Integrität durch die FK-Beziehung (Einschätzung des Wertebereiches) gegeben. SQL-Transaktionen sind Folgen von Operationen, welche eine constraint mode, access mode und ein initiierendes SQL-Statement besitzen. Externe Schemata im Relationenmodell werden mit Views realisiert. Dies ist eine virtuelle Tabelle, die aus Basistabellen abgeleitet ist. Das DBVS speichert lediglich die Definition des View und erzeugt die Tabelle erst nach einem DML-Kommando. CREATE VIEW ABT30 (NAME, VORNAME) AS (SELECT NAME,VORNAME FROM ABT WHERE ABT=30); Anforderungen an Übersetzungen: - Integritätsbedingungen - Freiheit von Seiteneffekten - Zu jedem u existiert eine Umkehrung w Redundanzen und Anomalien: - Redundanz: eine Aussage ist mehrfach vorhanden - Einfügeanomalie: Ein Sachgebiet kann erst dann eingetragen werde, wenn das erste Buch vorliegt - Löschanomalie: Mit dem Löschen des letzten Buches zu einem Sachgebiet verschwindet auch das Sachgebiet selbst Abhängigkeiten: - funktionale Abhängigkeit: o zu jedem Attributwert von gibt es genau ein Attributwert von B., o Beziehungen zwischen den einzelnen Attributen o Y heißt funktional abhängig von X in R X=>Y, wenn es in keiner Relation des Typs R zwei Tupel gibt, die in ihrem Wert zu X, aber nicht in ihrem Wert zu Y übereinstimmen. - volle Abhängigkeit: B ist nur von A abhängig, nicht jedoch von einem Teil der Attributkombination A - transitive Abhängigkeit: Attribut C ist von A transitiv abhängig, wenn das Attribut B von A und das Attribut C von B funktional abhängig ist, aber A nicht von C. Schlüsselkandidat: - ist die minimale Attributmenge, die alle Attribute eines Relationstyps determiniert - ein einzelnes Attribut kann auch durch eine echte Teilmenge von X determiniert sein - Aufgrund der stets gültigen trivialen funktionalen Abhängigkeiten determiniert jeder Schlüssel auch seine eigenen Attributein Attribut, das Bestandteil eines Schlüssels ist, heiß Schlüsselattribut Fremdschlüssel: - der Primärschlüssel eines Relationstyps wird in die Attributmenge eines anderen Relationstyps aufgenommen Buch(Sign,Titel,Jahr,SID) Sachgebiet(SID,Sachgebiet) => SID in Sachgebiet ist Fremdschlüssel 1NF: Eine Relation des Typs R ist in erster Normalform, wenn die Wertebereiche aller Attribute elementar sind aus sich des konzeptuellen Datenschemas. (alle Attributwerte nur einfache Werte, also bei Meier nur Opel, nicht Opel und Golf) 2NF nach Date: Eine Relation des Typs R ist in zweiter Normalform, wenn sie in 1NF ist und jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist. (jedes nicht zum ID-Schlüssel gehörende Attribut muss voll funktional abhängig sein, also Auto direkt zu Anr) 3NF: Eine Relation des Typs R ist in dritter Normalform, wenn sie in 2 NF ist und kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidaten abhängt. (Es darf also nicht vor dem Verkäufer noch in der selben Tabelle seine Nr stehen) BCNF: Eine Relation des Typs R ist in Boyce-Codd-Normalform (BCNF), wenn für jede voll funktionale Abhängigkeit X•=>Y in R gilt: X ist Schlüsselkandidat. Die BNCF stellt eine Verschärfung von 3NF und gleichzeitig die höchste Normalform auf der Grundlage funktionaler Abhängigkeiten dar. 2NF, 3NF und BCNF verfolgen das Ziel funktionale Abhängigkeiten innerhalb von Relationstypen zu isolieren, Im Gegensatz dazu verfolgt 4NF das Ziel mehrwertige Abhängigkeiten zu vermeiden. 4NF: Eine Relation des Typs R ist in vierter Normalform, wenn sie in BCNF ist und außer funktionalen Abhängigkeiten keine mehrwertigen Abhängigkeiten enthält. Transformation von Erm in relationale Datenbankschemata: - jeder Entity-Typ wird in einen eigenen Relationstyp abgebildet - Jeder Relationship-Typ einer M:N-Beziehung wird in einen eigenen Relationstyp abgebildet. - Relationship-Typen in 1:N und 1:1-Beziehungen werden nicht in einen eigenen Relationstyp abgebildet. Ihre Attribute werden in einem der einen Entity-Typ abbildenden Relatinstypen zugeordnet. CREATE TABLE HAUS( NR SMALLINT NOTNULL UNIQUE, TELENR CHAR NOT NULL, … PRIMARY KEY (PTR_NUM) FOREIGN KEY (TELENR) REFERENCES TELEBUCH); Transformation von Serm in relationale Datenbankschemata: - jeder E, ER und R-Typ wird in einen zugehörigen Relationstyp abgebildet - im Serm werden Existenzabhängigkeiten von links nach rechts dargestellt - Fremdschlüssel werden stets dem rechtsstehenden, existenzabhängigen Datenobjekttyp zugeordnet - Durch das Konzept des ER-Typs werden alle SERM-Datenobjekttypen 1:1 auf Relationstypen abgebildet Probleme des DBMS: - mehrere Benutzer, die unabhängig voneinander und parallel lesen, schreiben auf Datenbasis wollen - Aufgabe des DBMS ist es die Zugriffe so zu synchronisieren, dass die Integrität der Datenbasis gewahrt bleibt. ð wechselseitiger Ausschluß Transaktion ist eine Folge von Datenbankoperationen, die einen konsistenten Datenbankzustand in einen wiederum konsistenten Datenbankzustand überführt. Eigenschaften von T: - geschlossener Benutzerauftrag - Semantische Integrität - ACID-Prinzip: T nicht unterbrechbar, konsistenzerhaltend bezüglich der semantischen Integritätsbedingungen, laufen ohne gegenseitige Beeinflussung ab, Wirkung ist dauerhaft) BOT: Begin of Transaktion EOT: End of Transaktion Probleme bei parallelem Zugriff: - lost update - inkonsistente Sicht - Inkonsistenz der DB - Phantom-Problem Ein paralleles System von Transaktionen ist dann korrekt synchronisiert, wenn es serialisierbar ist, d.h. wenn es mindestens eine serielle Ausführung dieser Transaktionen gibt, die den gleichen Datenbankzustand und die gleichen Ausgabedaten der Transaktionen liefert. T ist dann serialisierbar, wenn eine totale Ordnung S für T existiert, die mit der Reihenfolge aller konfliktären Operationen in L verträglich ist. Nach der 2. Form ist ein Transaktionssystem dann serialisierbar, wenn G zyklenfrei ist. Jede Transaktion sperrt exklusiv den benötigten Teil der Datenbank. Die Verwaltung von Sperren ist Aufgabe des lock managers des DBMS. Der Sperrverwalter führt eine lock table mit allen aktuell vergebenen Sperren. Der Ablaufüberwacher des DBMS realisiert das 2-Phasen-Sperrprotokoll durch Anhalten und Abbrechen einer Transaktion. - Durch das Sperren eines Objektes werden alle unteren Ebenen mitgesperrt Beim sperren wird auch ein intention lock auf die obigen Ebenen gegeben, so dass dort das Objekt nicht mehr gesperrt werden kann Lesesperren und Schreibsperren Ablaufüberwacher: 2-Phasen-Sperrprotokoll: hinreichende und notwendige Bedingung - jedes Objekt, dass von einer Transaktion benutzt werden soll, muß vorher gesperrt werden. - Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an - Eine Transaktion muß die Sperren anderer Transaktionen beachten - Wachstumsphase: Anforderung neuer Sperren - Schrumpfphase: Freigabe der erworbenen Sperren und keine neue Anforderung von Sperren - Bei EOT muss Transaktion alle Sperren abgeben Anzahl der Sperren Locked point Wachstum Schrumpf Zeit Sperren bis EOT: - reduziert Parallelität der Transaktionen - garantiert atomare Transaktionen: jede Transaktion t kann vor EOT abgebrochen werden und rückgesetzt werden, da keine andere Transaktion t´Daten gesehen hat. Notwendige und hinreichende Bedingung für Deadlocks: - mehrer Transaktionen konkurrieren - jede Transaktion fordert die notwendigen Betriebsmittel mit Sperren an - Transaktionen besitzen bereits gesperrte Betriebsmittel und fordern weitere an - Es existiert eine zyklische Wartebeziehung - Den Transaktionen werden keine Betriebsmittel vorzeitig entzogen Zeitstempelverfahren: - TS Zeitmarken bezüglich schreiben, lesen - Jede Operation einer Transaktion benutzt die Zeitmarke der Transaktion - Jedes Objekt bekommt die Zeitmarke der letzten read/write Operation Sperrobjekte: - logische Sicht: Prädikate - physische Sicht: Datenbank Sicherung der Unverletzlichkeit der Datenbasis: - es gibt logische und physische Fehler - Transaktionsfehler: Fehler im Anwendungsprogramm des Benutzer: ð Rollback: Wirkung der Transaktion muss in DB rückgängig gemacht werden - Systemfehler: DBMS fällt aus: Neustart - Speicherfehler: Daten auf Massenspeicher sind nicht mehr verfügbar: Rekonstruktion - Logfile: bei Veränderung eines Objektes Kopie des Originals in Logfile, BOT-Marke und EOT-Marke für jede Transaktion o Neustart: lies logfile bis zum jüngsten checkpoint, bestimme Menge der offenen Transaktionen, setze die Transaktionen mit Hilfe der Before-Images zurück - Update auf Medien, mit diesen wird gearbeitet o Rekonstruktion: After Images Zugriffskontrolle in DBMS: - nur von berechtigten Usern - in der jeweils zulässigen Form gelesen und geändert - und nur auf den vorgesehenen Wegen transportiert und weiterverarbeitet werden Begriffe: - Identifikation - Authentisierung - Autorisierung - Zugriffsmatrix Anwendungsfunktionen, Datenverwaltung, Kommunikationsteil Kommunikation gliedert sich in Mensch-Mensch und Mensch-Maschine-Kommunkation K: - K in UIMS verwendet Die Datentypen sind entweder in der Hostsprache implementiert oder bieten eine definierte Schnittstelle zur Hostsprache - Datentypen der A-Komponente bestehen typischerweise aus strukturierten Hostvariablen der Hostsprache und den darauf definierten Funktionen Die Hostvariablen sind in der Hostsprache definiert und können unter Verwendung des Standard-Zuweisungsoperators := auf die Datenobjekttypen der K-schicht abgebildet werden. A: - D: - im Relationenmodell steht nur der Datentyp Relation zur Verfügung. Der Datentyp Relation ist mengenwertig Datenbank API (Application Programming Interface) - über diese Programmierschnittstelle ist es möglich, Datenbankadministrationsaufgaben durchzuführen. - Auslesen von internen Fehlernachrichten und Fehlercodes - Vorteil: o Ausnutzung aller vom DBVS zur Verfügung gestellten Features o Sehr performant - Nachteil: o Unabhängigkeit vom DBMS ist nicht gewährleistet Embedded static and dynamic SQL: - Einbettung von SQL Befehlen in eine höhere Programmiersprache - Vorteile von SQL nicht nur bei Verwendung interaktiver Nutzerschnittstellen, sondern auch beim Datenbankzugriff aus einer Applikation heraus nutzen Embedded static SQL: - vor dem Compilieren der Datenbankanwendung der SQL-Befehl bekannt Embedded dynamic SQL: - im Gegensatz zu static SQL werden die Befehle erst zur Laufzeit erstellt und ausgeführt - Änderungen des zugrundeliegenden Datenbankschemas haben bei Embedded dynamic SQL keine Auswirkungen auf die Datenbankanwendung Folgende Schritte müssen nach Fertigstellung des Quellcodes durchgeführt werden, wenn embedded sql verwendet wurde: - verbinden der DB und vorcompilieren - compilieren - Zusammenführen der Objekt-Dateien - Start der Anwendung Call Level Interface: - Schnittstelle für C-Applikationen basierend auf der Open Database Connectivity (ODBC) - Nicht notwendig Applikationen mit dem Präcompiler zu compilieren, da bei CLI allgemeine Zugriffspläne verfügbar sind - Vorteile: o Weniger Aufwand o Einheitliche Schnittstelle o Alle Ergebnistupel auf einmal verarbeitet o Automatische Datentypkonvertierung - Nachteile: o Nur C-Unterstützung Java Database Connectivity (JDBC): - Herstellerunabhängiger Standard - Standardisierter Datenzugriff über Java-Methoden - Präcompilung nicht notwendig - Verwendet nur dynamic SQL - Plattformunabhängig (WWW) - Nachteil: o Keine reine java-Lösung - Vorteile: o Viele odbc-Treiber sind bereits verfügbar a. Lieferant LiNr, Name, Adresse Bestellkopf LiNr, BestellNr, Datum, MA Bestellposition BestellposNr, LiNr, ArtikelNr, MA, Anzahl Artikel ArtNr, Groesse, Anzahl b. Create table Lieferant (int LiNr, varchar Name, varchar Adresse); Create table Bestellkopf (int BestellNr, int LiNr, date Datum, varchar MA); Create table Bestellposition (int BestposNr, int ArtikelNr, int LiNr, varchar MA); Create table Artikel (int ArtNr, int Groesse, int Anzahl); c. Alter table Lieferant add constraint pk_LiNr primary key (LiNr); Alter table Bestellkopf add constraint pk_BestNr primary key (BestNr), Add constraint fk_LiNr foreign key (LiNr) references Lieferant (LiNr); Alter table Bestellposition add constraint pk_BestellposNr primary key (BestellposNr), Add constraint fk_LiNr foreign key (LiNr) references Lieferant (LiNr), Add constraint fk_ArtNr foreign key (ArtNr references Artikel (ArtNr); Alter table Artikel add constraint pk_ArtNr primary key (ArtNr); d. Select Artikelname, LiNr from Artikel, Lieferant Where Artikel.ArtNr = Bestellpos.ArtNr ans Bestellpos.BestellkopfNr = Bestellkopf.Bestellkopfnr. and Bestellkopf.lieferantenNr = Lieferant.LiNr and LiNr = 001 Group by Artname, LieferantenNr;
