Datenbanken 1 - Uni Salzburg · 2020-03-24 · Organisation der Lehrveranstaltung Inhalt 1 Organisation der Lehrveranstaltung 2 Motivation und Fachgebiet Warum Datenbanksysteme? Das
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Redundanz: ein Fakt ist mehrmals gespeichertbei Anderungen mussen alle Kopien geandert werdenInkonsistenz: nicht alle Kopien wurden geandert, d.h., es existierenwiderspruchliche Datenisolierte Dateien: habe ich alle relevanten Dateien geandert?Bespiel: Adresse wurde nur im Fachbereich geandert, aufUniversitatsebene hingegen nicht.Ziel: Redundanz kontrollieren und Inkonsistenz vermeiden.
Beschrankte Zugriffsmoglichkeiten
Verknupfungen logisch verwandter Daten erzeugt deutlichen Mehrwertisolierte Dateien: verschiedene Verwalter und Formate, eigenesProgramm fur jede VerknupfungBespiel: freien Horsaal fur Datenbank-Vorlesung finden (Horsale mitKapazitat, Veranstaltungskalender, Teilnehmerzahl der Vorlesung)Ziel: Alle Daten im System lassen sich flexibel miteinander verknupfen.
Anderungen konnen zu unerlaubten Zustanden (aus der Sicht derAnwendung) fuhrenoft sind Verknupfungen zwischen Daten erforderlich, umIntegritatsverletzungen zu entdeckenBeispiel: Student schreibt sich in Bachelor-Projekt ein, bevor er genugKreditpunkte gesammelt hat.Ziel: Integritatsregeln formulieren und Verletzungen nicht zulassen.
Sicherheitsprobleme
Nicht alle Benutzer sollen alle Daten sehen.Nur ausgewahlte Benutzer sollen bestimmte Daten andern durfen.Granularitat: Informationsteil, auf den sich der Zugang bezieht, z.B.ganzes Objekt, gewisse Eigenschaften des ObjektesBeispiel: Studenten durfen ihre eigenen Noten sehen, aber nicht dieanderer. Eigene Noten durfen nicht verandert werden.Ziel: Lese- und Schreibrechte flexibel und in feiner Granularitat anBenutzer vergeben.
Viele Anwender greifen zugleich auf Daten zu.Beispiel: FlugreservierungssystemKeine Kontrolle: Unerwunschte Anomalien, z.B. “lost updates” =meine Anderungen werden von einem anderen Benutzer uberschriebenDateisysteme bieten nur sehr rudimentare Kontrollmechanismen, z.B.,Sperren auf DateiebeneRudimentare Kontrolle: Ineffizient, ein einziger Benutzter kann Dateiblockieren.Ziel: Effizienter Mehrbenutzerbetrieb ohne Anomalien.
Umgang mit Fehlern / Datenverlust
Verlust von Daten kann fur Unternehmen existenzbedrohend sein.Dateisysteme bieten Backups, aber alles nach Backup geht verloren.isolierte Dateien: Konsistenz zwischen Dateien ist im Fehlerfall nichtgarantiert, da sich Dateien unabhangig andern konnenBeispiel: Stromausfall oder Systemabsturz wahrend BankomatbehebungZiel: Garantien gegen Datenverlust auch im Fehlerfall
Große Datenmengen erfordern effiziente Algorithmen fur Suche,Verknupfung und Anderung.isolierte Dateien erfordern individuelle Programme fur einzelneAnfragen und/oder Datentypen.sehr aufwandig und moglicherweise ineffizient, da die Wahl derAlgorithmen von den Daten abhangt, die sich andern konnenZiel: Automatisch effiziente Algorithmen in Abhangigkeit von Anfrageund Daten wahlen.
Hohe Entwicklungskosten
Zumindest einem Teil oben genannter Probleme muss sich jederAnwendungsentwickler stellen.Rad standig neu erfinden ist zeit- und kostenintensivZiel: Komfortable Schnittstelle, die Datenverwaltungsproblemetransparent lost.
hohe Anfangsinvestition und moglicherweise zusatzlicherHardware-BedarfOverhead fur Allgemeinheit, Sicherheit, Mehrbenutzerkontrolle,Recovery, Integrationskontrolle
DBMS moglicherweise nicht notig, wenn:
einfache Datenbank und Anwendung, die klar definiert ist und sichvoraussichtlich nicht andern wirdkein Mehrbenutzerbetrieb
DBMS nicht geeignet:
zwingende Echtzeitanforderungen, die DBMS nicht garantieren kannDaten konnen aufgrund ihrer Komplexitat nicht (nur schwer)modelliert werdenspezielle Operationen, die von DBMS nicht unterstutzt werden
SIGMOD – seit 1975VLDB – seit 1975ICDE – seit 1985EDBT – seit 1988
Zeitschriften
ACM Trans. on Database System (TODS) – seit 1976The VLDB Journal (VLDBJ) – seit 1992IEEE Trans. on Knowledge and Data Engineering (TKDE) – seit 1989Information Systems (IS) – seit 1975
DBLP Bibliographie (Michael Ley, Uni Trier, Germany)
Grundlagen von Datenbanken Datenmodelle und Sprachen
DDL und Schema
Datendefinitionssprache (DDL, data definition language) beschreibt:
Schema: Struktur der Datenobjekte (Typen, Gruppierung elementarerTypen) und Beziehung zwischen den DatenobjektenIntegritatsbedingungen: Einschrankung der zulassigen Daten; mussenzu jedem Zeitpunkt erfullt sein
Grundlagen von Datenbanken Datenmodelle und Sprachen
Anfragesprachen
Sprache um Information aus der Datenbank zu holen
Kategorien von Sprachen:
Imperativ1: spezifiziert wie etwas gemacht wird; kann als Grundlagefur die Anfrageoptimierung verwendet werden (weil das Vorgehen bzw.die Reihenfolge angegeben wird)Deklarativ: spezifiziert was gemacht wird; nicht geeignet fur dieAnfrageoptimierung
Grundlagen von Datenbanken Datenmodelle und Sprachen
Schema vs. Instanz/3
Datenbankinstanz:
Daten die zu einem gegebenen Zeitpunkt in der Datenbank gespeichertsindauch Datenbankauspragung, Datenbankzustand oder extensionaleEbene genanntDer Begriff “Instanz” wird auch fur einzelne Komponenten verwendet(Instanz eines Tupels, Instanz einer Tabelle)
Gultige Datenbankinstanz: Eine Instanz die samtliche Strukturen undIntegritatsbedingungen erfullt.
Eine Datenbankinstanz andert sich jedesmal wenn die Datenbankgeandert wird.
85 MATH2410 Fall 04 King92 CS1310 Fall 04 Anderson102 CS3320 Spring 05 Knuth112 MATH2410 Fall 05 Chang119 CS1310 Fall 05 Anderson135 CS3380 Fall 05 Stone
Grundlagen von Datenbanken Datenmodelle und Sprachen
Einordnung der Datenmodelle
Konzeptionelle Datenmodelle (high-level)
Konzepte moglichst nahe an der Benutzersichtkeine Datenmainpulationssprache, da nur Schema beschrieben wird,keine InstanzenBeispiele: Entity-Relationship-Modell (ER), Unified Modeling Language(UML)
Logische Datenmodelle
konzentriert sich auf Darstellung der Instanzengeeignet zur Implementierung der DatenbankBeispiele: relationales Modell, objektorientiertes Modell
Physische Datenmodelle (low-level)
Konzepte moglichst nahe an internen Datenstrukturenabhangig von internem Design der Datenbanksystemspezifisch, in Handbuch beschrieben
Grundlagen von Datenbanken Datenmodelle und Sprachen
Logische Datenmodelle
Satzorientierte Datenmodelle: Netzwerkmodell, hierarchisches Modell
hauptsachlich historische Bedeutunginteressant fur Legacy-Systeme (z.B. hierarchisch: IMS von IBM,Netzwerk: UDS von Siemens)
Relationales Modell:
speichert Daten in Tabellenelegantes mathematisches Modelldeklarative und imperative Abfragesprachen
Objektorientiertes und objekt-relationales Modell:
Antwort auf Anwendungen mit komplexen Datentypen undObjektorientierung der Programmiersprachenobjektorientierte Datenbanken weniger verbreitet, aber Aspekte lebenin objekt-relationalen Datenbanken weiter (z.B. PostgreSQL)
Grundlagen von Datenbanken Datenabstraktion und Datenunabhangigkeit
Datenbankbenutzer/2
Endbenutzer: Verwenden die Datenbank fur Anfragen, Berichte, undAnderungen.
Endbenutzer konnen wie folgt kategorisiert werden:
naive Benutzer: umfasst den Grossteil der Endbenutzer
Verwenden genau definierte Funtionen in der Form von vorgefertigtenTransaktionen auf der DatenbankBeispiele: Bankomaten, Reservierungssyteme, Webformulare
fortgeschrittene Benutzer:
Analysten, Wissenschaftler und Ingenieure die vertraut mit denFahigkeiten des Systems sindSchreiben keine Programme, formulieren jedoch Anfragen anhand einerAnfragesprache
Grundlagen von Datenbanken Datenabstraktion und Datenunabhangigkeit
Datenbankbenutzer/3
Anwendungsprogrammierer: Betten die Anfragesprache in eineProgrammiersprache ein und stellen Endbenutzern einfach zubedienende Programme zur Verfugung, welche komplexe Anfragenbewaltigen.
erstellen von Webanwendungenerstellen von Anwendungssoftware mit Datenbankzugriff
Datenbankdesigner:
Verantwortlich fur den Inhalt, die Strukturen, dieIntegritatsbedingungen, die Funktionen und Transaktionen.Datenbankdesigner mussen mit Endbenutzern kommunizieren undderen Bedurfnisse kennen.
Datenbankadministratoren:
Verantwortlich fur die Autorisierung des Datenbankzugriffs, derKoordination und Uberwachung der Benutzung, der Beschaffung vonSoft- und Hardware, Backup, Kontrolle der Effizienz der Operationen
Grundlagen von Datenbanken Datenabstraktion und Datenunabhangigkeit
Die ANSI/SPARC Drei-Ebenen Architektur/1
Die ANSI/SPARC Architektur wurde vorgeschlagen um folgendeCharakteristiken einer Datenbank zu unterstutzen:
Unterschiedliche Sichten auf die DatenDatenunabhangigkeit
Definiert ein Datenbankschema auf drei Ebenen:Physische Ebene: beschreibt die physischen Speicherstrukturen (z.B.Tabellen) und Zugriffspfade (z.B. Indizes).
verwendet typischerweise ein physisches Datenmodell
Logische Ebene: beschreibt die Strukturen und Integritatsbedingungenfur die gesamte Datenbank und deren Benutzer
verwendet ein konzeptionelles oder logisches Datenmodell
Externe Sicht: beschreibt unterschiedliche Sichten (views) auf dieDatenbank.
verwendet oft das gleiche Datenmodell wie die logische Ebene
Grundlagen von Datenbanken Datenabstraktion und Datenunabhangigkeit
Die ANSI/SPARC Drei-Ebenen Architektur/2
Abbildungen zwischen den verschiedenen Ebenen sind notwendig umAnfragen und Daten transformieren zu konnen.
Anwendungen beziehen sich auf die externe Sicht und werden durchdas Datenbanksystem auf die logische und physische Ebene abgebildetum ausgewertet zu werden.Daten die aus der physischen/logischen Ebene kommen werdenumformatiert, damit sie der externen Sicht des Benutzers entsprechen.
Grundlagen von Datenbanken Datenabstraktion und Datenunabhangigkeit
Datenunabhangigkeit
Logische Datenunabhangigkeit:
Die Moglichkeit das logische Schema zu andern ohne die externenSichten und zugehorigen Anwendungen andern zu mussen.Beispiel: Objekte und deren Eigenschaften umbenennen, neueEigenschaften hinzufugen
Physische Datenunahangigkeit:
Die Moglichkeit die physische Ebene zu andern, ohne die logischeEbene andern zu mussen.Beispiel: Speicherstruktur andern oder neue Indices erstellen um dieEffizienz zu verbessern.
Vorteile der Datenunabhangigkeit:
nach der Anderung einer tieferen Ebene mussen nur die Beziehungenzwischen dieser und der daruberliegenden Ebene nachgefuhrt werdendie weiter daruberliegenden Ebenen werden nicht geandertAnwendungsprogramme mussen nicht geandert werden, da sie auf dieoberste Ebene zugreifen