This service will soon be decomissioned on 2024-05-22. Please copy all content you still need to padlite.spline.de

SplinePad
Full screen

Server Notice:

hide

Public Pad Latest text of pad dbs Saved June 28, 2010

 

Datenbanksysteme

Datenbanken lassen sich mittels verschiedenen Abstraktionsschichten beschreiben: Conceptual, Logical und Physical. Sprachen zur Beschreibung nennt mensch auch DDL ("data definition language"). Um Daten abzufragen oder zu manipulieren benutzt man eine DML ("data manipulatiion languge").
 

Conceptual

In der Entwufsschicht wird versucht Daten einer Applikation in einem sogenannten Schema zu strukturieren. Hierbei werden sogenannten Entitäten mit Attributen verwendet. Entitäten haben keine, eine oder viele Beziehungen zu sich selbst (Rekursion) oder anderen Entitäten. Die Anzahl der möglichen teilnehmenden Entitäten in einer Beziehungsrelation wird Kardinalität genannt. Ähnlich der Objektorientierung können Entitäten von anderen erben. Eingesetzt wirds dies bei der Generalisierung (generalization) und Spezialisierung (specialization). Hier wird versucht  Redundanz (Überschneidung von Informationen) möglichst zu vermeiden.
 
  • Modeliere nicht mehr als ein Objekt aus der Realität in eine Entität/Relation
 

Logical

In der Logikschicht wird das Entwufsmuster, zum Beispiel in UML oder ERM vorliegend, in eine logische Form gebracht. Das Ergebnis ist meist ein relationales Datenmodel (RDM).
 

Physical

 
 

Basic modeling primitives

  • Entity (Typ)
  • Weak entity: Eine schwache Entität ist ein Typ, der  durch seine Attribute und der Beziehung zu einer anderen Entität identifizierbar ist. Sie kann nicht ohne der Beziehung existieren.
  • Aggregation: verschiedene Entitäten formen zusammen eine neue Entität
  • Komposition: Ist ein Verschärfung der  Aggregation. Sie beschreibt die Beziehung zwischen einem Ganzen (Entität  A) und seinen Teilen (Entität B). Entität B kann ohne A nicht  existieren. Desweiteren muss A sich um die Integrität von beiden  Entitäten kümmern.
  • Attribute (Eigenschaft)
  • Relationship (Beziehung)
  • besitzen immer einen Namen
  • haben keine Richtung (immer bidirektional)
  • können Attribute besitzen
  • besitzen keine Schlüsselattribute  (zur Identifizierung von Einträgen)
  • n-ary Relationship: mehr als 2 Entitäten sind mit einbezogen
  • Cardinality constraints: Legt fest wieviele Beziehungen eine Entität zu anderen (einschließlich sich selbst) haben   kann.
  • Notationsmöglichten:   (min, max)-, 1:N- oder UML+-Notation
  • Kardinalitäten lassen sich Mittels   Relationen mathematisch ausdrücken
 

Graphische Modellierungssprachen

Entity-Relationship-Model (ERM)

ERM ist ein Daten orientiertes Model. Es wurde 1976 von P. P. Chen vorgestellt. Aufgrund der fehlenden Unterstützung von Operationen wird es als ein statisches Model angesehen. Die graphischen Notationen sind Rechtecke für Typen (Entities), Ellipsen für Attribute und Rauten für Beziehungen zwischen Typen. Anzumerken ist, dass Beziehungen immer bidirektional (beide Richtungen) sind.
 

Unified modeling language (UML)

UML unterstützt die Modellierung von Daten und Operationen. Es wird nach einem objektorientierten Stil modelliert. Uni- sowie bidirektionale Beziehungen werden unterstützt. Beziehungsrichtungen besitzen Namen (sogenannte Rollen). Kardinaltitätsbedingungen werden "multiplicity" genannt. Jeder Typ hat eine einzigartige Adresse (pointer) und somit können Typen mit gleichen Attributen im Gegensatz zum ERM unterschieden werden. Aufgrund der einzigartigen Adressen gibt es keine Schlüssel und somit können "weak entities" nicht modelliert werden.
 
Begriffsdefinitionen
  • Klasse = Entitätstyp
  • Objekt = Entität
  • Assoziation = Beziehung
 

Relationales Datenmodel 

In einem Relationale Datenmodel werden die Relationen in Form von Tabellen dargestellt. Jeder Spaltenname steht für Attribut. Die Zeilen sind die Relationstupel.
 
Eigenschaften:
  • Doppeleinträge sind nicht erlaubt
  • Es gibt keine Tupel-Reihenfolge
  • Attribute haben einen primitiven Datentyp. Sie müssen nicht unbedingt einen Wert haben (null Wert)
  • single-valued
  • eindeutige Namen
 
Ein Schlüssel ist eine minimale Untermenge seiner Attribute, mit denen eine Zeile (Tupel) einer Tabelle (Relation) eindeutig indentifizierbar ist. Es ist durchaus möglich, dass es mehrere Schlüsselkandidaten gibt. Jeder einzelne Schlüsselkandidat kann als Primärschlüssel fungieren.
 
Ein Fremdschlüssel ist ein Attribut mit denen Relationen zwischen Entitäten realisiert werden. Der Fremdschlüssel zeigt immer auf den Primärschlüssel der in relationstehenden Entität. Er muss einen Wert oder null besitzen.
 
Multi-valued Attribute werden mit HIlfe von Weak Entities realisiert. Die Entität A hat ein multi-value Attribut C. C ist ein Fremdschlüssel auf eine eigene Entität C'. 
 

Beziehungen

1:N - One to Many - Entität A steht zu Entität B in einer 1:N Beziehung
Entität A muss als Attribut einen Fremdschlüssel auf den Primärschlüssel von Entität B besitzen.
 
N:M - Many to Many - Entität A steht zu Entität B in einer N:N Beziehung
Um eine N:M-Relation zu realisieren braucht man eine separate Relationstabelle. In dieser werden jedem Primärschlüssel von A ein Primärschlüssel von B zugeordnet. Es handelt sich hierbei um eine "N-ary relationship".
 

Consolidation

Um ein Datenbankschema zu vereinfachen können Tabellen mit dem gleichen Primärschlüsseln in eine neue Tabelle zusammengefasst werden. Diesen Vorgang nenntn man Konsolidierung (Consolidation) oder auch Vereinfachung (simplification).
 
Bsp: R(k1,..,kn, a1,...an), S(k1,...,kn, b1,...bm) ⇒ RS(k1,...,kn, a1,...an,b1,...,bm)
 
Nichtkonsolidierung von 1:N-Beziehungen
  • Wenn viele NULL-Werte erwartet werden
  • Wenn gewisse Attribute selten genutzt werden
 
N:M-Beziehungen sollten niemals zusammengeführt werden!
 

Simple Query Langauge - SQL

Beschreibung ... Definition
 

Datentypen

SQL2
  • NUMERIC (p,s)
  • DECIMAL (p,s)
  • INTEGER
  • SMALLINT
  • FLOAT (p,s)
  • REAL
  • DOUBLE PRECISION
  • CHARACTER [(n)] CHAR
  • CHARACTER VARYING (n) = VARCHAR (n)
  • NATIONAL CHARACTER (n) | NCHAR (n)
  • NCHAR VARYING (n)
  • BIT [(n)], BIT VARYING , BOOLEAN
  • DATE (DATE '2001-5-2')
  • TIME (TIME '01:00:05.011')
  • TIMESTAMP
  • INTERVAL
 
SQL99
  • CHARACTER LARGE OBJECT = CLOB
  • NATIONAL CHARACTER LARGE OBJECT = NCLOB
  • BINARY LARGE OBJECT = BLOB
 

Löschen von Tabellen/Datenbanken

Schemainformationen werden mittels DROP-Statement gelöscht.
 
DROP TABLE <name> [restrict|cascade]
DROP DATABASE <name>
 
restrict = Löscht zuerst die Referenzen
cascade = Löscht Tabelle und Referenzen
 

Contraints / Bedinungen

Wertbedingungen (value constraings) schränken mögliche Werte eines Attributs ein (Bsp: not NULL)
Integritätsbedingungen (integrity constraints) sind Invarianten einer Datenbank.In jedem möglichen gültigen Zustand der Datenbank sind diese erfüllt. Sie  schränken somit den Zustand  der Datenbank ein.
 
Syntax: CONSTRAINT <name> <def> [ON DELETE/UPDATE <option>] [DEFERED|IMMEDIATE]
 
Constraintarten:
  • UNIQUE (<attribute1>,...,<attributeN>)
  • PRIMARY KEY (<key1>,..,<keyN>)
  • CHECK(<bedingung>)
  • FOREIGN KEY (<key>) REFERENCES (<Table>.<key>)
 
Um die Integrität einer Datenbank bei Schlüsselveränderung weiterhin zu garantieren gibt es die die ON DELETE- und ON UPDATE-Statements.
Mögliche Optionen sind CASCADE (alle referenzierte Tupel), SET NULL oder DEFAULT.
 
Um Kreisbedingungen (Huhn-Ei-Problem) zu ermöglichen, können Constraints auch nach der Tabellenerstellung mit TABLE ALTER <Tabellenname> ADD|MODIFY ... hinzugefügt werden. 
 
CREATE TABLE chicken(cID INT PRIMARY KEY,
                     eID INT);
CREATE TABLE egg(eID INT PRIMARY KEY,
                 cID INT);
 
ALTER TABLE chicken
    ADD CONSTRAINT chickenREFegg
    FOREIGN KEY (eID) REFERENCES egg(eID);
ALTER TABLE egg
    ADD CONSTRAINT eggREFchicken
    FOREIGN KEY (cID) REFERENCES chicken(cID) ;
 
Probleme treten hier nun aber beim Einfügen von Daten auf. Abhilfe kann hier die DEFERRABLE-Option sein. Damit lassen sich sogenannte Transaktionen ermöglichen. Eine Transaktion kann mehrere SQL-Statements beinhalten. Die Constraints werden erst aber nach dem ausführen aller SQL-Statements überprüft. Transaktionen müssen immer mit dem COMMIT; abgeschloßen werden.
 
Variante:
  • INITIALLY DEFERRED DEFERRABLE
  • INITIALLY IMMEDIATE DEFERRABLE
 

Assertions / Annahmen

 

Trigger / Auslöser

 

Metadata

 

Virtual Tables / Views

Views sind ein Konstrukt um virtuelle Tabellen zu ermöglichen. Nützlich können Views sein um bessere Performance bei vielen Lesevorgängen zu erzielen.
View integration: Integration of  Conceptual models, which are related but have been designed separately,  into one single mod
 

Funktionale Eigenschaften

Funktionale Abhängigkeiten generalisieren das Schlüsselkonzept. Sie können zur Formalisierung von Integritätsbedingung von Attributen und Beziehungen benutzt werden.
 
Formale Notation
  • Relation: R ⊆ dom(a1) x dom(a2) x ... x dom(an)
  • Attribute set: Σ(R) = {a1, a2, ..., an} = RA , signature
  • Tuple: r ∈ R
  • Degree of R: number of attributes
  • Relation Schema: R(a1, a2, ..., an)
  • Database schema: set of relation schemas
 
Begriffsdefinition
  • Relation = table ( file) (relations are sets, tables may have duplicate entries)
  • Tuple = row, record
  • Attribute = field (component)
 
Def.: Functional Dependencies (FDs)
Let A = Σ(R)* = {a,b,c,...ai,..} be the attribute set of a relation Rand X, Y ⊆ A , r, r' ∈ R, r ≠ r'
Y is functionally dependent on X ( written: X → Y)
 :⇔ (∀ xi ∈ X ) r.xi = r’.xi ⇒ (∀ yi ∈ Y ) r.yi = r’.yi
 
A functional dependency Y → Z is called implied by a set
   F= {F1, ... , Fn} of functional dependencies, if Y → Z can be proven from F.
   
A functional dependency Y → Z can be inferred (¢ )by a set of inference rules R = {r1,...rm} from set F = {F1, ... , Fn} of functional dependencies
if Y → Z can be constructed by a finite number of syntactic transformations of F according to rules ri
 
Types of functional dependencies:
1. Key dependencies
2. Partial dependencies on one of the candidate keys
   expl.: {p#} -> {name}
       // R(p#,name,qualification, ...)
           since key is {p#,qualification}
3.  Dependencies among non-key attributes
    expl.: {responsible_Scientist} -> {institute}
4. Dependencies among attributes of different candidate keys
 
 

Normalformen

erste Normalform - 1NF
Eine Relation liegt in der 1NF vor, wenn jedes Attribut nur einen atomaren Wertebereich hat. Das heißt, dass zusammengesetzte (Name = Vorname + Nachname), mengenwertige (Telefonnummer={123,456,789} oder geschachtelte Attributwerte nicht erlaubt sind.
 
A relation is in 1NF :⇔ all attributes are single valued and atomic
 
zweite Normalform - 2NF
Eine Relation liegt in der 2NF vor, wenn es die Bedingungen der 1NF erfüllt und dazu weiter kein Attribut von einer Untermenge der Schlüsselkandidaten funktional abhängt. Hierdurch werden Teilabhängigkeiten vermieden.
 
R is in Second Normal Form (2NF), :⇔ ∀X ⊆Σ(R),∀a∈Σ(R): 
    a ∉ X ∧ a is not a prime attribute ∧ X -> a ⇒ X is a key or a superset of a key but not a proper subset of any key of R
 
dritte Normalform - 3NF
Eine Relation liegt in der 3NF vor, wenn es die 2NF erfüllt, sowie kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidat abhängt. Das heißt, dass kein Attribut nur von Schlüsselattributen abhängen darf.
 
R is in third normal form (3NF) :⇔ R is in 3NF :⇔ no non-prime attribute depends transitively on a key.
 
Boyce-Codd-Normalform
Every non-trivial functional dependency in the table is a dependency on a  superkey
 
vierte Normalform - 4NF
Every non-trivial multivalued dependency in the table is a dependency on a superkey
 

algebraische Operationen

Projektion (Projection)
 
Selektion (Selection)
 
Vereinigung (Union)
 
Unterschied (Difference)
 
Kreuzprodukt (Cross product)