Informatik (Fach) / Datenbanksysteme1 (Lektion)

Kapitel 2 Dar Relationale Modell

Diese Lektion wurde von daschinka erstellt.

Lektion lernen

Diese Lektion ist leider nicht zum lernen freigegeben.

zurück  |  weiter 1 / 1

• Domain ein Wertebereich oder Typ Logisch zusammengehörige Menge von Werten Beispiele: D=Integer D=Date D=String D={rot, gelb, grün, blau} Kann endliche oder unenliche Kardinalität haben
• Relation in der Mathematik Die einzelnen Domains lassen sich als Spalten einer Tabelle versehen, und werden als Atributte bezeichnet Für R(echte Teilmenge)D1×...×Dk ist k der Grad (Stelligkeit) Die Elemente der Relation heißen Tupel: (1,a),(2,a),(3,a) sind drei Tupel von Grad k=2 Die Relation ist Menge von Tupeln, d.h. die Reihenfolge der Tupel spielt keine Rolle Die Reihenfolge der Atributte ist von Bedeutung
• Relationen-Schema Alternative Definition in DBS: Relation ist Ausprägung eines Relationen-Schemas. • Geordnetes Relationenschema: – k-Tupel aus Domains (Attribute) – Attribute werden anhand ihrer Position im Tupel referenziert – Attribute können zusätzlich einen Attributnamen haben R = (A1: D1, ... Ak: Dk) • Domänen-Abbildung (ungeordnetes Rel.-Sch.): – Relationenschema R ist Menge von Attributnamen: – Jedem Attributnamen Ai ist Domäne Di zugeordnet: – Attribute werden anhand ihres Namensreferenziert R = {A1, .... Ak} mit dom(Ai) = Di, 1 ≤ i ≤ k
• Relationen- Schema Beispiel Städte-Relation - Als geordnetes Relationenschema: Schema: R=(Name:String, Einwohner: Integer, Land:String)                         Ausprägung: r={(München,1211617,Bayern),(Bremen,535058,Bremen),                                  (Passau, 49800,Bayern)} - Als Relationenschema mit Domainabbildung: Schema: R={Name,Einwohner,Land}                                                                                   mit dom(Name)=String, dom(Einwohner)=Integer, .... Ausprägung: r={t1,t2,t3}                                                                                                                 mit t1(Name)=München, t1(Einwohner)=1211617,....
• Diskussion Vorteil und Nachteil von geordenetem Schema • Vorteil von geordnetem Relationenschema: – Prägnanter aufzuschreiben. Wichtig z.B. beim Einfügen neuer Tupel: t3 = (Passau, 49.800, Bayern) vergleiche: t3 (Name) = Passau; t3 (Einwohner) = ... • Nachteil von geordnetem Relationenschema: – Einschränkungen bei logischer Datenunabhängigkeit: Applikationen sensibel bzgl. Einfügung neuer Attribute (nur am  Ende!) • Definitionen prinzipiell gleichwertig   
• Begriffe: Relation Datenbankschema Datenbak • Relation: Ausprägung eines Relationenschemas • Datenbankschema: Menge von Relationenschemata • Datenbank: Menge von Relationen (Ausprägungen)
• Duplikate • Relationen sind Mengen von Tupeln. Konsequenzen: – Reihenfolge der Tupel irrelevant (wie bei math. Def) – Es gibt keine Duplikate (gleiche Tupel) in Relationen: {(0,a), (0,a), (0,a), (1,b)} = {(0,a), (1,b)} • Frage: Gilt dies auch für die Spalten beim ungeordneten  Relationenschema R = {A1,...,Ak} ? – Reihenfolge der Spalten ist irrelevant (das ist gerade das besondere am ungeordneten RS) – Duplikate treten nicht auf, weil alle Attribut-Namen  verschieden sein müssen
• Schlüssel • Tupel müssen eindeutig identifiziert werden Warum? Z.B. für Verweise • Objektidentifikation in Java: Mit Referenz (Adresse im Speicher) • Im relationalen Modell werden Tupel anhand von  Attributwerten identifiziert • Ein/mehrere Attribute als Schlüssel kennzeichnen • Konvention: Schlüsselattribut(e) unterstreichen!    
• Zusammengesetzter Schlüssel • Oft ist ein einzelnes Attribut nicht ausreichend,  um die Tupel eindeutig zu identifizieren  Z.B.: Schlüssel: (Vnr, Semester)
• Schlüssel: Formale Definition Definition: • Eine Teilmenge S der Attribute eines Relationenschemas R (S ⊆ R) heißt Schlüssel, wenn gilt: 1) Eindeutigkeit: Keine Ausprägung von R kann zwei verschiedene  Tupel enthalten, die sich in allen Attributen von S gleichen. ∀ möglichen Ausprägungen r und Tupel t1, t2∈r gilt: t1 ≠ t2 ⇒ t1[S]≠ t2[S]. 2) Minimalität: Es existiert keine echte Teilmenge T ⊂ S , die bereits  die Bedingung der Eindeutigkeit erfüllt. ∀ Attributmengen T, die (1) erfüllen, gilt: T ⊆ S ⇒ T = S. t[S] -> Tupel eingeschränkt auf die Attribute aus S (Später πs(t)für t[S])
• Superschlüssel/Minimale Menge  Eine Menge S ⊆ R heißt Superschlüssel (oder Oberschlüssel, engl. Superkey), wenn sie die Eindeutigkeitseigenschaft erfüllt Der Begriff des Superschlüssels impliziert keine Aussage über die Minimalität In der Mathematik wird allgemein eine Menge M als minimale Menge bezüglich einer Eigenschaft B bezeichnet, wenn es keine echte Teilmenge von M gibt, die ebenfalls B erfüllt. Damit können wir auch definieren: Ein Schlüssel ist ein minimaler Superschlüssel (minimale Menge S ⊆ R mit Eindeutigkeits-Eigenschaft)
• Primärschlüssel Keine überflüssigen Attribute sind enthalten Manchmal gibt es mehrere verschiedene Schlüssel – {LNr} – {VNr, Semester} -> Schlüsselkandidat (SQL: unique) Man wählt einen dieser Kandidaten aus als sogenannter Primärschlüssel (SQL: primary key) Attribut(e) das auf einen Schlüssel einer anderen Relation verweist, heißt Fremdschlüssel(SQL: foreign key)
• Schlüssel: Semantische Eigenschaften Die Eindeutigkeit bezieht sich nicht auf die aktuelle Ausprägung einer Relation r , sondern immer auf die Semantik der realen Welt Z.B.: können Name und Gehälter gleich sein, anders die Pnr.
• Tabellendefintion in SQL Definition eines Relationenschemas: CREATE TABLE n  <- n Name der Relation ( a1,d1,c1, <- Definition des ersten Attributs   a2,d2,c2,    .....   ak,dk,ck <-Definition des Attributs Nr. k ) - hierbei bedeuten... ai der Name des Attributs Nr. i di der Typ (die Domain) des Attributs ci ein optimaler Constraint für das Attribut - Wirkung: Definition eines Relationenschemas mit einer leeren Relation      als Ausprägung.   
• Basis-Typen in SQL Der SQL-Standard kennt u.a folgende Datentypen: integer oder auch integer4, int smallint oder auch integer2 float(p) oder auch float decimal(p,q) und nemeric(p,q) mit p Stellen, davon q Nachkommast. charakter(n), char(n) für Strings fester Länge n charakter varying(n), varchar(n): variable Strings date, time, timespamp für Datum und Zeit
• Basis-Typen in SQL Der SQL-Standard kennt u.a folgende Datentypen:   integer oder auch integer4, int smallint oder auch integer2 float(p) oder auch float decimal(p,q) und nemeric(p,q) mit p Stellen, davon q Nachkommast. charakter(n), char(n) für Strings fester Länge n charakter varying(n), varchar(n): variable Strings date, time, timespamp für Datum und Zeit  
• Zusätze bei Attributdefinitionen Einfache Zusätze (Integritätsbedingungen) können unmittelbar hinter einer Attributdefinition stehen: – not null: Das Attribut darf nicht undefiniert sein in DBS: undefinierte Werte heissen null-Werte – primary key: Das Attribut ist Primärschlüssel (nicht bei zusammengesetzten Schlüsseln) – unique: Das Attribut ist Schlüsselkandidat – references t1 (a1): Ein Verweis auf Attribut a1 von Tabelle t1 – default w1: Wert w1 ist Default, wenn unbesetzt. – check f: Die Formel f wird bei jeder Einfügung überprüft, z.B.: check A <= 100
• Intergritätsbedingungen • Zusätze, die keinem einzelnen Attribut zugeordnet sind, stehen mit Komma abgetrennt in extra Zeilen – primary key (A1, A2, ...): Zusammengesetzter Primärschlüssel – unique (A1, A2, ...): Zusammengesetzter Schlüsselkandidat – foreign key (A1, A2, ...) referencest1 (B1, B2, ...)                               Verweis auf zusammengesetzten Schlüssel in Rel. T1                  Anmerkung: Fehlt die Angabe (B1, B2, ...) hinter t1 so wird automatisch (A1, A2, ...) eingesetzt. – check f
• Schlüssel Definitonen • primary key (a1,a2), definiert den Primärschlüssel. • unique (a3,a4), definiert einen weiteren Schlüsselkandidaten. • foreign key (a5,a6) referencesB (b1,b2) definiert einen Fremdschlüssel. – Tupel in A ohne gültigen Partner in B nicht erlaubt – Ohne weiteren Zusatz nicht möglich, Tupel in B, auf die durch in Tupel in A verwiesen wird, zu löschen oder die Werte von b1,b2 zu verändern
• Schlüssel-Definitionen Löschen eines Tupels in B mit Referenzen nicht möglich. Es gibt aber verschiedene Zusätze: • foreign key (a5,a6) referencesB (b1,b2)    on delete cascade -Löschen eines Tupels in B führt auch zum Löschen der entsprechenden Tupel in A • on update cascade -Verändern eines Tupels in B führt zum Verändern in A • on delete set null „hängende Verweise“ werden ggf. auf null gesetzt.
• Tabellendefinition • Das Schlüsselwort on delete cascade in Haelt führt dazu, dass bei  Löschen eines Dozenten auch entsprechende Tupel  in Haelt gelöscht  werden • Weitere Konstrukte der Data Definition Language:                                    – drop table n1                                                                                         Relationen-Schema n1 wird mit allen evtl. vorhandenen Tupeln               gelöscht. – alter table n1 add (a1 d1 c1, a2 d2 c2, ...) • Zusätzliche Attribute oder Integritätsbedingungen werden (rechts) an die Tabelle angehängt • Bei allen vorhandenen Tupeln Null-Werte – alter table n1 drop (a1 , a2 , ...) – alter table n1 modify (a1 d1 c1, a2 d2 c2, ...)
• Wiederholung Relation als ausschließliches Strukturelement – Darstellung der Relationen durch Tabellen – Datensätze = Zeilen der Tabelle (Tupel) ¨ – Merkmale des Objekts = Spalten der Tabelle (Attribute)
• Query By Example (QBE) • Beruht auf dem Bereichskalkül • Ausdrücke nicht wie in SQL als Text • Dem Benutzer wird am Bildschirm ein Tabellen-Gerüst  angeboten, das mit Spezial-Editor bearbeitet werden kann • Nach Eintrag von Werten in das Tabellengerüst (Anfrage)  füllt das System die Tabelle • Zielgruppe: Gelegentliche Benutzer
• Architektur eines DBS Drei-Ebenen-Architektur zur Realisierung von – physischer – und logischer Datenunabhängigkeit (nach ANSI/SPARC)
• Externe Ebene • Gesamt-Datenbestand ist angepasst, so dass jede Anwendungsgruppe nur die Daten sieht, die sie... – sehen will (Übersichtlichkeit) – sehen soll (Datenschutz) • Logische Datenunabhängigkeit • In SQL: Realisiert mit dem Konzept der Sicht(View)
• Was ist eine Sicht (View)? • Virtuelle Relation • Was bedeutet virtuell? – Die View sieht für den Benutzer aus wie eine Relation:  select ... from View1, Relation2, ... where ...  mit Einschränkung auch: insert, delete und update – Aber die Relation ist nicht real existent/gespeichert; Inhalt ergibt sich durch Berechnung aus anderen Relationen • Besteht aus zwei Teilen: – Relationenschema für die View (nur rudimentär) – Berechnungsvorschrift, die den Inhalt festlegt: SQL-Anfrage mit select... from ... where
• Viewdefintion in SQL • Das folgende DDL-Kommando erzeugt eine View create [or replace] view VName [(A1, A2, ...)]* as select...  
• Konsequenzen • Automatisch sind in dieser View alle Tupel der Basisrelation, die die Selektionsbedingung erfüllen • An diese können beliebige Anfragen gestellt werden, auch in Kombination mit anderen Tabellen (Join) etc: select * from Buchhalter where Name like ‘B%‘ • In Wirklichkeit wird lediglich die View-Definition in die Anfrage eingesetzt und dann ausgewertet: Buchhalter: select PNr,Name,Gehalt  from Mitarbeiter whereANr=01 → select * from Buchhalter where Name like ‘B%‘ → select * from ( select PNr, Name, Gehalt  from Mitarbeiter where ANr=01 ) where Name like ‘B%‘

zurück  |  weiter 1 / 1