1 / 19

Relationales Datenmodell und DDL

Relationales Datenmodell und DDL. A. Grundlagen des relationalen M odells Domänen mögliche Wertebereiche für die Attribute Relationen Tabelle eines Datenbanksystems - Attribute entsprechen den Spalten - Tupel entsprechen den Zeilen Tupel Relationen mit konkreten Attributwerten

jesse-levine
Download Presentation

Relationales Datenmodell und DDL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Relationales Datenmodell und DDL

  2. A. Grundlagen des relationalen Modells • Domänen mögliche Wertebereiche für die Attribute • Relationen Tabelle eines Datenbanksystems - Attribute entsprechen den Spalten - Tupel entsprechen den Zeilen • Tupel Relationen mit konkreten Attributwerten t = („Mickey Mouse“, „Main Street“, 4711) 4. Schema legt die Struktur einer Relation fest Telefonbuch: {[Name : string, Adresse : string, TelefonNr : integer]}

  3. A. Grundlagen des relationalen Modells 5. Ausprägung aktueller Zustand der Datenbasis 6. Schlüsselkandidaten minimale Anzahl der zur eindeutigen Identifikation eines Tupel nötigen Attribute • Primärschlüssel nur einer der Schlüssel wird zum Primärschlüssel wird zur Kennzeichnung unterstrichen

  4. A. Grundlagen des relationalen Modells 8. Relationale Darstellung von Entitymengen Studenten: {[MatrNr : integer, Name : string, Semester : integer]} 9. Relationale Darstellung von Beziehungen hören (N:M): {[MatrNr : integer, VorlNr : integer]} 10. Verfeinerte Abbildungsregeln für Beziehungen zwischen 2 Entities E und F 1:1-Beziehungen Primärschlüssel von E in Relation F schreiben oder Umgekehrt 1:N-Beziehungen Primärschlüssel von E in Relation F schreiben Attribute der Relation R ebenfalls in F übernehmen Vorlesungen: {[VorlNr, Titel, SWS, gelesenVon]} Professoren: {[PersNr, Name, Rang, Raum]}

  5. A. Grundlagen des relationalen Modells 11. Anomalien Update-Anomalie: was passiert wenn Sokrates einen anderen Raum bekommt? Lösch-Anomalie: was passiert wenn „Glaube und Wissen“ wegfällt? Einfügeanomalie: Curie ist neu und liest noch keine Vorlesungen

  6. A. Grundlagen des relationalen Modells 12. Relationale Modellierung der Generalisierung Angestellte: {[PersNr, Name]} Professoren: {[PersNr, Rang, Raum]} Assistent: {[PersNr, Fachgebiet]}

  7. B. SQL (Structured Query Language) 1. Allgemeines • Deklarative Anfragesprache • Mengenorientiert • In andere Programmiersprachen einbettbar • Vier große Teile • DRL (Data Retrieval Language) • Kommandos für Anfragen • DML (Data Manipulation Language) • Befehle, um Daten einzufügen, zu löschen und zu ändern (insert, delete, update) • DDL (Data Definition Language) • Definition des Schemas der Datenbank • Befehle, um den Zugriff auf Daten zu kontrollieren (createtable, alter table, createview, createindex, drop) • DCL (Data Control Language) • Befehle, um den Fluss von Transaktionen zu steuern

  8. B. SQL (Structured Query Language) 2. Varianten von SQL • Embedded SQL • SQL-Befehle werden direkt in die jeweilige Hostsprache eingebettet • SQL-Befehle werden durch ein vorangestelltes EXEC SQL markiert • sie werden vom Präprozessor durch Konstrukte der jeweiligen Sprache ersetzt • Dynamic SQL • Wird eingesetzt, wenn die Anfragen zur Übersetzungszeit des Programms noch nicht bekannt sind • Standardisierte Schnittstellen (ODBC, JDBC) • Flexibler, aber üblicherweise etwas langsamer als Embedded SQL

  9. B. SQL (Structured Query Language) 3. DDL: Create Table Statement CREATE TABLE Tabellenname ( Attribut_1 Datentyp_1 [NOT NULL], … … Attribut_n Datentyp_n [NOT NULL]);

  10. B. SQL (Structured Query Language) 4. DDL: Datentypen • Zeichenketten und Zahlen • VARCHAR (n) • CHAR[ACTER] • NUMERIC • DEC[IMAL] • INT[EGER] • SMALLINT • FLOAT • Datum und Zeit • DATE, TIME, TIMESTAMP • Zeichenketten, Binärdaten • LONG, CLOB, RAW (n), LONG RAW, BLOB, CFILE, BFILE, DATALINK, MONEY/SMALLMONEY, …

  11. C. Integritätsbedingungen • Definition Beschreibung der Eigenschaften der modellierten Miniwelt durch semantische Integritätsbedingungen • Ziel Sicherung der Konsistenz der Daten einer Datenbank • Überprüfung durch Constraints

  12. C. Integritätsbedingungen • Arten a. NOT NULL Bedingung i. erzwingt Definition von Attributwerten beim Einfügen von Tupeln -> zwingend erforderlich für Schlüssel ii. Formulierung: NOT NULL direkt hinter Attributdefinition -> Bsp.: PersNr INTEGER NOT NULL iii. Default-Angabe möglich, wo NOT NULL nicht eingesetzt wird -> ratsam, um Auftreten von NULL-Werten zu vermeiden -> Formulierung: DEFAULT ‘Attributwert‘ direkt hinter Attributdefinition -> Bsp.: Ort VARCHAR(80) DEFAULT ‘Garching‘

  13. C. Integritätsbedingungen b. Primärschlüssel Bedingung i. Primärschlüssel: Attribut(-kombination), die in jeder Ausprägung der Relation keinen Wert hat, der mehr als einmal vorkommt -> entsprechende Attribute müssen mit NOT NULL definiert sein! ii. Formulierung - Langform [CONSTRAINT constraintname_pk] PRIMARY KEY (Attribut_x,…,Attribut_z) -> Bsp.: PersNr INTEGER NOT NULL, …, PRIMARY KEY (PersNr) - Kurzform NOT NULL PRIMARY KEY direkt hinter entsprechende Schlüsseldefinition -> Bsp.: PersNr INTEGER NOT NULL PRIMARY KEY

  14. C. Integritätsbedingungen c. UNIQUE Bedingung i. stellt Schlüsseleigenschaft für Attribut sicher: kann nur einmal vorkommen ii. Formulierung: UNIQUE direkt hinter Attributdefinition -> Bsp.: PersNr INTEGER NOT NULL UNIQUE

  15. C. Integritätsbedingungen d. CHECK Klauseln i. Einschränkung des Wertebereiches für Attribute ii. Formulierung: CHECK (Wertebereichbedingung) -> Bsp.: CHECK (PersNr > 0 AND PersNr < 99999)

  16. C. Integritätsbedingungen e. Referentielle Integrität: Fremdschlüssel Bedingung i. Referenz von einer Kindtabelle auf eine Elterntabelle ii. Annahmen -> Relationen R und S mit Schemata R und S -> R hat Primärschlüssel k iii. Voraussetzungen für Fremdschlüssel f in S: für alle Tupel s in S gilt -> entweder Attribut f aus Tupel s enthält nur NULL-Wert -> oder Attribut f aus Tupel s enthält keine NULL-Werte und es existiert ein Tupel r aus R, dessen Attribut k gleich Attribut f aus Tupel s ist (r.k = s.f)

  17. C. Integritätsbedingungen e. Referentielle Integrität: Fremdschlüssel Bedingung iv. Formulierung - Langform [CONSTRAINT constraintname_fk] FOREIGN KEY (Attribut_x,…,Attribut_z) REFERENCES Elterntabellenname (Attribut_u,…,Attribut_w) -> Bsp.: gelesenVon INTEGER, …, FOREIGN KEY (gelesenVon) REFERENCES Professoren (PersNr) - Kurzform REFERENCES Elterntabellennamedirekt hinter entsprechende Schlüsseldefinition -> Bsp.: gelesenVon INTEGER REFERENCES Professoren

  18. C. Integritätsbedingungen e. Referentielle Integrität: Fremdschlüssel Bedingung v. Varianten: automatische Propagierung der Änderung von Schlüsselattributen -> Änderung der Fremdschlüsselwerte bei Änderung (ON UPDATE) oder Löschung (ON DELETE) der Schlüssel, auf die sie zeigen - SET NULL -> alle Fremdschlüsselwerte werden auf NULL gesetzt -> Formulierung: SET NULL nach Fremdschlüsseldefinition -> Bsp.: gelesenVon INTEGER REFERENCES Professoren ON DELETE SET NULL - CASCADE -> alle Fremdschlüsselwerte werden ebenfalls geändert oder gelöscht -> Formulierung: CASCADE nach Fremdschlüsseldefinition -> Bsp.: VorlNr INTEGER REFERENCES Vorlesungen ON DELETE CASCADE

  19. D. Beispielaufgabe Erstelle Tabelle Professoren mit folgenden Bedingungen: • PersNr ist Primärschlüssel • Name muss Wert erhalten, Rang nicht • Raumnummer hat höchstens fünf Stellen CREATE TABLE Professoren (PersNr INTEGER NOT NULL, Name VARCHAR(30) NOT NULL, Rang CHAR(2), Raum INTEGER CHECK (PersNr > 0 AND PersNr < 99999), PRIMARY KEY (PersNr));

More Related