Ohne Datenbanken:
Datenredundanz
Daten sind redundant: Mehrfach gespeichert; Probleme: Verschwendung von Speicherplatz, „Vergessen“ von Änderungen, Inkonsistenzen; keine zentrale, „genormte“ Datenhaltung.
Redundanz lässt sich zwar auch ohne Datenbanken vermeiden, Datenbanken unterstützen dies aber gut.
Auch Funktionalität ist redundant, d. h. kommt in den unterschiedlichen Anwendungen wiederholt vor.
Redundanz kann durchaus vorteilhaft sein, wegen Performance.
Hier eher nicht Thema, s. b. entsprechende weiterführende Vorlesung.
Entscheidungen, welche Daten wo abgelegt werden, obliegen i. d. R. aber nicht den Anwendungen. Vielmehr für alle Anwendungen einheitliche Lösung.
bspw.
Weitere Probleme
Keine physische Datenunabhängigkeit
Physische Datenunabhängigkeit := Programme bzw. Informationsbedürfnisse formulierbar, ohne physische Eigenschaften der Daten kennen zu müssen.
Datenschutz und Datensicherheit sind nicht gewährleistet
Atomarität
Atomarität := Programm wird entweder ganz oder gar nicht ausgeführt
Von Dateien zu Datenbanken
Datenbanktechnologie
DBMS vs. DBS
Konzeptuelle Ebene: Relationenmodell
Anfragesprachen
Anfrageoptimierung
Physische Datenunabhängigkeit
Die neun Coddschen Regeln
Bedeutungstreue
Schemakonsistenz
Aspekte von SQL
Relationales Modell: SQL-DDL
SQL als Definitionssprache
create table
Erlaubte Wertebereiche in create table
Table ist Relation
Data Dictionary
Schlüssel
Integritätsbedingungen
Wir unterscheiden zwischen Relationenschemata und Datenbankschema. Ein Relationenschema gibt an, wie eine einzelne Relation aufgebaut ist, mit all ihren Attributen. Ein Datenbankschema ist eine Menge solcher Relationenschemata. Es gibt Konsistenzbedingungen, die sich nur auf eine Relation beziehen, zum Beispiel die Schlüsseleigenschaft (dass Schlüssel einen Tupel eindeutig identifiziert). Sie ist ein Beispiel für eine lokale Integritätsbedingung. Eine globale Integritätsbedingung ist eine, die auf mehrere Relationen Bezug nimmt, wie zum Beispiel die Fremdschlüsselbedingung.
Integritätsbedingungen mit check
Definition eines Wertebereichs
alter table
Wir können das Schema einer bestehenden Relation ändern mithilfe von alter table. Eine einfache Form des Änderns ist das Hinzufügen eines Attributs zu einem Relationenschema. Die Auswirkung auf die Relation ist zunächst einmal das Einfügen einer leeren Spalte. (Die interne Repräsentation dieser neuen Spalte hängt von DBMS ab.) Ferner muss im Data Dictionary die Relation ATTR einen zusätzlichen Eintrag erhalten.
drop table
Speicherhierarchie
Index
Ein Index hilft uns, genau die Tupel zu finden, die zu unserem Informationsbedürfnis passen. Oben in weiß schematisch dargestellt ist ein Ausschnitt eines Index über das Attribut Durchschnittsnote. Die Struktur ist die (hoffentlich bekannte) Suchbaumstruktur.
Verschiedene Indizes sind möglich, und es kommt auf die Reihenfolge der Attribute an
Indices und physische Datenunabhängigkeit
create index
Simulierte Schlüsselbedingung
Entity-Relationship-Modelle Besics
ER Werte
ER Entities
ER Beziehungen
ER Attribute
Beziehungsattribute
Semantik eines ER-Schemas
ER Funktionale Beziehungen
ER Identifizierung durch Schlüssel
Abhängige Entity-Typen
Name der funktionalen Beziehung muss nicht unterstrichen sein
IST-Beziehung
Mengenwertiges Attribut
Wir benutzen hier ein sogenanntes mengenwertiges Attribut: Die Bedeutung hier ist, dass ein Prüfer nicht nur ein einzelnes Fach, sondern eine Menge von Fächern prüft.
ER Kardinalität
Zwei alternative Notationen: Standardkardinalität, Teilnehmerkardinalität
Teilnehmerkardinalität
Standardkardinalität
ER Optionalität von Attributen
Spezialisierung und Generalisierung
ER Komplexe Objekte
ER Beziehungen höheren Typs
Erweitertes ER-Modell
EER Typkonstruktor
Mehrfachspezialisierung ER
Last changeda year ago