204 lines
7.0 KiB
Markdown
Executable File
204 lines
7.0 KiB
Markdown
Executable File
# Klausurtalk
|
|
## Themen
|
|
- Beschreibung ER-Diagramm
|
|
- Diagramm ist gegeben: generierung der Tabellen
|
|
- Normalform ermitteln und konvertierung einer Tabelle in die Normlform des n-ten grades.
|
|
# Organisatorisches
|
|
## Überblick
|
|
- Entwurf von Datenbanken und
|
|
- Bewertung von DB
|
|
- SQL
|
|
- Anwendung identifizieren und bewerten
|
|
- Im Labor wird **SQLite** verwendet
|
|
## Orga
|
|
- Labor ist ein kleiner Übungszettel
|
|
- Klausur und elektronische Prüfung
|
|
- Elektronische Prüf.: mit SQL-Statements
|
|
- Klausur: Alle Themenblöcke, praktische Aufgaben und Multiple Choice
|
|
- Prüfungstermine
|
|
- 08.07 - 13 Uhr - 032a-c
|
|
- 16.09 - 9 Uhr - 122
|
|
## Motivation und Grundlagen
|
|
## Grundlagen
|
|
- Terminologie
|
|
- Datenmodelle und Sprachen
|
|
- Datenabstraktion und Datenunabhängigkeit
|
|
DB: System zur dauerhaften Speicherung und Verw. großer Datenmengen
|
|
Datenbank gemanaged durch ein Databank-Management-System
|
|
### Anforderungen
|
|
- Daten sollen (schnell) zugänglich sein
|
|
- Daten sollen verändert werden sollen
|
|
- Einzelne Fakten müssen verknüpft werden
|
|
- Gleichzeitiges Lesen und Schreiben möglich
|
|
- Daten sollen konsistent bleiben
|
|
- kein verlust von Daten
|
|
- schutz vor unberchtigten Zugriff
|
|
## Herausforderungen der Datenverwaltung
|
|
### Redundanz und Inkonsistenz
|
|
- Inkonsistenz: nicht alle Kopien eines Faktums wurden geändert (existenz widersprüchlicher Daten)
|
|
- Ziel: Red. und Ink. vermeiden
|
|
### Verknüpfungen ermöglichen
|
|
- deutlicher Mehrwert (Knowledge Discovery und Data Mining)
|
|
- Zielsetzung: Alle Daten im Sys. lassen sich flexibel temporär und unbefristet miteinander verknüpfen
|
|
### Integritätsverletzung
|
|
- Änderungen können zu unerlaubten Zuständen führen
|
|
- Oft Verkn. zwischen Daten erforderlich, um Integritätsverl. zu entdecken
|
|
- Zielsetzung: Integritätsreglen formulieren und Verletzung nich zulassen
|
|
### Mandanten und Sicherheit
|
|
- Veränderungsrechte
|
|
- Granularität: Informationsteil auf den sich der Zugan bezieht, z.B. ganzes Ibjetk, gewisse Eigenschaften des Objektes
|
|
- Zielsetzung: Lese- und Schreibrecht flexibel und in geeigneter Form
|
|
### Mehrbenutzerprinzip
|
|
- Viele Anwender greifen zugleich auf Daten zu
|
|
- Keine Kontrolle: unerwünschte Anomalien ("lost update")...
|
|
- Effizienter Mehrbenutzerbetrieb ohne Anomalien
|
|
### Umgang mit Fehlern / Datenverlust
|
|
- Verlust von Daten kann Unternehmen existenzbedrohend sein
|
|
- Backups
|
|
- Ziel: Garantien gegen Datenverlust auch im Fehlerfall
|
|
### Effizienz
|
|
- Große Datenmengen erfordern effiziente Algorithmen
|
|
### Hohe Entwicklungskosten
|
|
|
|
## Warum Datenbanksysteme
|
|
- Unkontrollierte Redundanz vermeiden
|
|
- Daten lassen sich flexibel miteinander verknüpfen
|
|
- Def. Integritätsreglen können definiert werden
|
|
### Hauptgründe gegen DBS
|
|
- Hohe Anfangsinvestition (Personal, Lizenzen...) und möglicherweise zusätzlicher Hardware-Bedarf
|
|
- Overhead für SIcherheit, Mehrbenutzerkontrolle & -rechte, Recovery, Integritätskontrolle
|
|
### DBS möglicherweise nicht nötig, wenn
|
|
- EInfache Datenbank mit wenigen Daten und Anwendung
|
|
- Kein Mehrbenutzerbetrieb
|
|
### DBS nicht geeignet
|
|
- Zwingende Echtzeitanforderungen, die DBMS nicht garantieren können
|
|
- Daten können aufgrund ihrer Kompl. nicht modelliert werden
|
|
|
|
|
|
# Grundlagen
|
|
## Grundlegende Definitionen
|
|
Daten: Fakten (Faktum), die gespeichert werden
|
|
Information: Daten + Bedeutung
|
|
Wissen: Information + Anwendung
|
|
|
|
|
|
Mini-Welt: Jener Teil der realen Welt der uns für unsere Anwendungsfälle interessiert
|
|
Daten (Erweiterung der Definition): Bekannte Fakten übe rdie Mini-Welt die gespeichert werden können
|
|
Metadaten: Informationen über die Struktur einer Datenbank
|
|
Datenbanksystem: DBMS+DB+Metadaten+Schnittstellen
|
|
|
|
|
|
## Datenmodell
|
|
- "Infrastruktur" zur modellierung des Mini-Welt-Ausschnittes der realen Welt:
|
|
- Datendefinitionssprache (DDL, data definition lang.)
|
|
- Schema: Struktur der Datenobj. und Beziehungen...
|
|
- Datenmanipulationssprache(DML, data manipulation lang.)
|
|
|
|
## Transaktionen
|
|
ACID -Eigenschaften
|
|
- Atomarität
|
|
- Konsistenzerhaltung
|
|
- Isolation
|
|
- Dauerhaftigkeit
|
|
## Einordnung der Datenmodelle
|
|
- Konzeptionelle Datenmodelle (high-lvl)
|
|
- Logische Datenmodelle
|
|
- Physische Datenmodelle (low-lvl)
|
|
___
|
|
- Satzorierntierte Datenmodelle
|
|
- Relationales Modell
|
|
- Objektorientiertes und objekt-relationales Modell
|
|
|
|
## Datenbankbenutzer
|
|
Unterscheidung in:
|
|
- Endbenutzer
|
|
- Datenbankdesigner
|
|
- Anwendungsprogrammierer
|
|
- Datenbankadministratoren
|
|
Naive Benutzer; umfasst den Großteil der Endbenutzer
|
|
Fortgeschrittene Benutzer: analystenm Wissenschaftler und Ingenieure ,die vertraut mit den Fähigkeiten...
|
|
|
|
## ANSI/SPARC Drei-Ebene-Architektur
|
|
unterstützung von:
|
|
- unterschiedliche Sichten auf die Daten (views)
|
|
- Datenunabhängigkeit
|
|
Definiert ein Datenbankschema auf drei Ebenen:
|
|
- Physische Ebene:
|
|
- Logische Ebene:
|
|
- Externe Sicht:
|
|
|
|
## Datenunabhängigkeit
|
|
Maß für die Isolation zwischen Anwendungsprogrammen und Daten.
|
|
Unabhängigkeiten:
|
|
- logische
|
|
- physische
|
|
## Erweiterung der DBS Darstellung
|
|
Auswendig lernen hehe ("Eine der Abildungen, die man sich gut einprägen sollte.")
|
|
## OLTP vs. OLAP
|
|
Online Transaction Processing vs. Online Analytical Processing
|
|
**TODO** Abbildung einfügen
|
|
|
|
# Entity Relationship Diagramme
|
|
nächste Woche: Relationale Algebra
|
|
__viel gerede, weniger Kontent__
|
|
- ER-Diagramm ist konzeptionell
|
|
## Entwurfsprozess
|
|
"lang, fehlerbehaftet und keiner hält sich dran" Draheim 15.04.24 9:13
|
|
TODO balancierte Bäume wiederholen
|
|
- Zwei Ebenen
|
|
- DBMS spezifisch
|
|
- Design von Anwendungsprogrammen
|
|
- Implementierung von Transaktionen
|
|
- Physisches Design
|
|
- DBMS Unabhängig
|
|
- Funktionale Analyse
|
|
- Konzeptionelles Design
|
|
- Anforderungsanalyse
|
|
- Performanz wird nicht betrachtet
|
|
### Das ER-Modell
|
|
- hohes Abstraktionsniveau
|
|
- Kunde soll das ebenfalls verstehen können
|
|
|
|
- Entität mit Rechteck
|
|
- Attribut mit Pille
|
|
- Beziehung mit Raute
|
|
## Entitäten und Attribute
|
|
|
|
|
|
## Beziehungen
|
|
|
|
## Generalisierung
|
|
____
|
|
# Das Relationale Modell
|
|
## Schema, Relation und Datenbank
|
|
- Mengen, ihre Operatoren und meist ausgedruckt als Teilmenge eines kartesischen Produktes
|
|
$\text{sch}(R) = [A_1, A_2, ... , A_n]$ ist Schema der Relation
|
|
### Attribute und Domäne
|
|
- Eine Domäne ist eine Menge von atomaren Werten
|
|
- zu jeder Domäne gehört ein Datentyp inkl. Format
|
|
- Eine Instanz ist eine Menge von Tupeln aus einer Domäne
|
|
### Zusammenhang von Rel. und der Datenbank
|
|
- Datenbank ist Menge von Relationen
|
|
|
|
## Integritätsbedingungen
|
|
- ... sind EInschränkungen auf den Daten, die alle Instanzen der DB erfüllen müssen
|
|
- Dre Klassen von Bedingungen
|
|
- Schlüssel
|
|
- Domänenintegrität
|
|
- garantie, dass alle Attribut-werte aus der entspr. Dom. stammen und des Primäschlüssel nicht null ist
|
|
- Referentielle Integrität
|
|
- Attrib. in Schema der Re., die Prim.Sch. einer anderen Rel. sind, werden Fremdschlüssel genannt
|
|
## Vom E/R-Modell zum relationalen Modell
|
|
- Alg. übersetzt ein konzept. ER Diag. in ein rel. Schema
|
|
- Übersetzung in 6 Schritte
|
|
- Unab. Entitätstypen
|
|
- Existenzbas. Entitätstypen
|
|
- Beziehungstyp.
|
|
- Mehrwertige Attribute
|
|
- N-wertige Beziehungstyp.
|
|
- Spez. ....
|
|
- Aus jeder Entität eine Tabelle und auch bei Relationen
|
|
-
|
|
Abschluss der relationalen Modelltheorie.
|
|
___
|