wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
527a62f6e3
Informatik/Datenbanksysteme.md
Robert Jeutter f0d7c7ca0a DBS Kapitel 4
2020-11-19 09:39:29 +01:00

24 KiB
Raw Blame History

title date author
Datenbanksysteme Wintersemester 20/21 Robert Jeutter

Was sind Datenbanken - Grundlegende Konzepte

Überblick

  • Daten = logisch gruppierte Informationseinheiten
  • Bank = Sicherheit vor Verlust, Dienstleistung für mehrere Kunden, (langfristige) Aufbewahrung

Ohne Datenbanken:

  • jedes Anwendungssystem verwaltet seine eigenen Daten
  • Daten sind (redundant) mehrfach gespeichert
  • Probleme
    • Verschwenden von Speicherplatz
    • "vergessen" von Änderungen
    • keine zentrale "genormte" Datenerhaltung
  • größere Mengen von Daten nicht effizient verarbeitet
  • mehrere Benutzer können nicht parallel auf den gleichen Daten arbeiten, ohne sich zu stören
  • Anwendungsprogrammierer/Benutzer können Anwendungen nicht programmieren/benutzen ohne ... zu kennen (keine Datenunabhängigkeit)
    • interne Dartstellung der Daten
    • Speichermedien oder Rechner
  • Datenschutz und Datensicherheit

Datenintegration durch Datenbanksystem

Anwendungen greifen über Datenbankmanagementsystem auf Datenbank zu.

Datenbankmanagementsystem (DBMS): Software zur Verwaltung von Datenbanken

Datenbank (DB): strukturierter, von DBMS verwalteter Datenbestand

Datenbanksystem (DBS) = DBMS + DB

Architekturen

die neun Codd'schen Regeln

  1. Integration: einheitliche, nichtredundante Datenverwaltung
  2. Operationen: Speichern, Suchen, Ändern
  3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary
  4. Benutzersichten
  5. Integritätssicherung: Korrektheit des Datenbankinhalts
  6. Datenschutz: Ausschluss unauthorisierter Zugriffe
  7. Transaktionen: mehrere DB-Operationen als Funktionseinheit
  8. Synchronisation: parallele Transaktionen koordinieren
  9. Datensicherung: Wiederherstellung von Daten nach Systemfehlern

Ziele:

  • Trennung von Modellierungssicht und interner Speicherung
  • Portierbarkeit
  • Tuning vereinfachen
  • standardisierte Schnittstellen

Schemata:

  • Konzeptuelles Schema (Ergebnis der Dateidefinition)

  • Internes Schema (Festlegung der Dateiorganisation und Zugriffspfade = Index)

  • Externes Schema (Ergebnis der Sichtdefinition)

  • Anwendungsprogramm (Ergebnis der Anwendungsprogrammierung)

  • Trennung Schema-Instanz

    • Schema: Metadaten, Datenbeschreibung
    • Instanz: Anwenderdaten, Datenbankzustand

Datenunabhängigkeit:

  • Stabilität der Benutzerschnittstelle gegen Änderungen
  • physisch: Änderung der Dateiorganisation und Zugriffspfade haben keinen Einfluss auf das konzeptuelle Schema
  • logisch: Änderung am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme

Aufteilung der Funktionalitäten einer Anwendung

  • Präsentation und Benutzerinteraktion
  • Anwendungslogik („Business“-Logik)
  • Datenmanagementfunktionen (Speichern, Anfragen, ...).

Architektur von Datenbankanwendungen typischerweise auf Basis des Client-Server-Modells (Server=Datenbanksystem).

3 Schichten Architektur (ANSI-SPARC-Architektur)

Klassifizierung der Komponenten

  • Definitionskomponenten: Datendefinition, Dateiorganisation, Sichtdefinition
  • Programmierkomponenten: DB-Programmierung mit eingebetteten DB-Operationen
  • Benutzerkomponenten: Anwendungsprogramme, Anfrage und Update interaktiv
  • Transformationskomponenten: Optimierer, Auswertung, Plattenzugriffssteuerung
  • Data Dictionary (Datenwörterbuch): Aufnahme der Daten aus Definitionskomponenten, Versorgung der anderen Komponenten

5 Schichten Architektur

Verfeinerung der Transformation

  • Datensystem: Übersetzung, Zugriffspfadwahl
  • Zugriffssystem: Logische Zugriffspfade, Schemakatalog, Sortierung, Transaktionsverwaltung
  • Speichersystem Speicherungsstrukturen, Zugriffspfadverwaltung, Sperrverwaltung, Logging, Recovery
  • Pufferverwaltung: Systempufferverwaltung, Seitenersetzung, Seitenzuordnung
  • Betriebssystem: Externspeicherverwaltung, Speicherzuordnung

Einsatzgebiete

  • Klassische Einsatzgebiete:
    • viele Objekte (15000 Bücher, 300 Benutzer, 100 Ausleihvorgänge pro Woche, ...)
    • wenige Objekttypen (BUCH, BENUTZER, AUSLEIHUNG)
    • etwa Buchhaltungssysteme, Auftragserfassungssysteme, Bibliothekssysteme, ...
  • Aktuelle Anwendungen: E-Commerce, entscheidungsunterstützende Systeme (Data Warehouses, OLAP), NASA’s Earth Observation System (Petabyte-Datenbanken), Data Mining

Datenbankgrößen:

  • eBay Data Warehouse: 10PB
    • Teradata DBMS, 72 Knoten, 10.000 Nutzer,
    • mehrere Millionen Anfragen/Tag
  • WalMart Data Warehouse: 2,5PB
    • Teradata DBMS, NCR MPP-Hardware;
    • Produktinfos (Verkäufe etc.) von 2.900 Märkten;
    • 50.000 Anfragen/Woche
  • Facebook: 400TB
    • x.000 MySQL-Server
    • Hadoop/Hive, 610 Knoten, 15 TB/Tag
  • US Library of Congress 10-20TB
    • nicht digitalisiert

Historisches

  • Wissensbanksysteme

    • Daten in Tabellenstrukturen
    • Stark deklarative DML, integrierte Datenbankprogrammiersprache

  • Objektorientierte Datenbanksysteme

    • Daten in komplexeren Objektstrukturen (Trennung Objekt und seine Daten)
    • Deklarative oder navigierende DML
    • Oft integrierte Datenbankprogrammiersprache
    • Oft keine vollständige Ebenentrennung

  • Neue Hardwarearchitekturen

    • Multicore-Prozessoren, Hauptspeicher im TB-Bereich: In-Memory-Datenbanksysteme (z.B. SAP HANA)

  • Unterstützung für spezielle Anwendungen

    • Cloud-Datenbanken: Hosting von Datenbanken, Skalierbare Datenmanagementlösungen (Amazon RDS, Microsoft Azure) • Datenstromverarbeitung: Online-Verarbeitung von Live-Daten, z.B. Börseninfos, Sensordaten, RFID-Daten, ...(StreamBase, MS StreamInsight, IBM Infosphere Streams)
    • Big Data: Umgang mit Datenmengen im PB-Bereich durch hochskalierbare, parallele Verarbeitung, Datenanalyse (Hadoop, Hive, Google Spanner & F1, ...)

  • NoSQL-Datenbanken („Not only SQL“):

    • nicht-relationale Datenbanken, flexibles Schema (dokumentenzentriert)
    • „leichtgewichtig“ durch Weglassen von SQL-Funktionalitäten wie Transaktionen, mächtige deklarative Anfragesprachen mit Verbunden etc.
    • Beispiele: CouchDB, MongoDB, Cassandra, ...

Relationale Datenbanken - Daten als Tabellen

Relationen für tabellarische Daten

Konzeptuell: Datenbank = Menge von Tabellen (= Relationen)

  • „Tabellenkopf“: Relationenschema
  • Eine Zeile der Tabelle: Tupel; Menge aller Einträge: Relation
  • Eine Spaltenüberschrift: Attribut
  • Ein Eintrag: Attributwert

Integritätsbedingungen: Schlüssel

  • Attribute einer Spalte identifizieren eindeutig gespeicherte Tupel: Schlüsseleigenschaft
  • auch Attributkombinationen können Schlüssel sein!
  • Schlüssel können durch Unterstreichen gekennzeichnet werden
  • Schlüssel einer Tabelle können in einer anderen (oder derselben!) Tabelle als eindeutige Verweise genutzt werden:
    • Fremdschlüssel, referenzielle Integrität
  • ein Fremdschlüssel ist ein Schlüssel in einer „fremden“ Tabelle

SQL-Datendefinition

CREATE table

Wirkung dieses Kommandos ist sowohl

  • die Ablage des Relationenschemas im Data Dictionary, als auch
  • die Vorbereitung einer „leeren Basisrelation“ in der Datenbank

DROP table

komplettes Löschen einer Tabelle (Inhalt und Eintrag im Data Dictionary)

Mögliche Wertebereiche in SQL

  • integer (oder auch integer4, int),
  • smallint (oder auch integer2),
  • float(p) (oder auch kurz float),
  • decimal(p,q) und numeric(p,q) mit jeweils q Nachkommastellen,
  • character(n) (oder kurz char(n), bei n = 1 auch char) für Zeichenketten (Strings) fester Länge n,
  • character varying(n) (oder kurz varchar(n) für Strings variabler Länge bis zur Maximallänge n,
  • bit(n) oder bit varying(n) analog für Bitfolgen, und
  • date, time bzw. datetime für Datums-, Zeit- und kombinierte Datums-Zeit-Angaben

Beispiel:

create table WEINE (
  WeinID int,
  Name varchar(20) not null,
  Farbe varchar(10),
  Jahrgang int,
  Weingut varchar(20),
  primary key(WeinID),
  foreign key(Weingut) references ERZEUGER(Weingut))
  • primary key kennzeichnet Spalte als Schlüsselattribut
  • foreign key kennzeichnet Spalte als Fremdschlüssel
  • not null schließt in bestimmten Spalten Nullwerte als Attributwerte aus
  • null repräsentiert die Bedeutung „Wert unbekannt“, „Wert nicht anwendbar“ oder „Wert existiert nicht“, gehört aber zu keinem Wertebereich
  • null kann in allen Spalten auftauchen, außer in Schlüsselattributen und den mit not null gekennzeichneten

Grundoperationen: Die Relationenalgebra

  • Anfrageoperationen auf Tabellen

    • Basisoperationen auf Tabellen, die die Berechnung von neuen Ergebnistabellen aus gespeicherten Datenbanktabellen erlauben
    • Operationen werden zur sogenannten Relationenalgebra zusammengefasst
    • Mathematik: Algebra ist definiert durch Wertebereich sowie darauf definierten Operationen
      • für Datenbankanfragen entsprechen die Inhalte der Datenbank den Werten, Operationen sind dagegen Funktionen zum Berechnen der Anfrageergebnisse
    • Anfrageoperationen sind beliebig kombinierbar und bilden eine Algebra zum „Rechnen mit Tabellen“ – die Relationenalgebra

  • Selektion \sigma: Auswahl von Zeilen einer Tabelle anhand eines Selektionsprädikats

  • Projektion \pi: Auswahl von Spalten durch Angabe einer Attributliste

    • Die Projektion entfernt doppelte Tupel

  • Verbund \bowtie (engl. join): verknüpft Tabellen über gleichbenannte Spalten, indem er jeweils zwei Tupel verschmilzt, falls sie dort gleiche Werte aufweisen

    • Tupel, die keinen Partner finden (dangling tuples), werden eliminiert

  • Umbenennung \beta: Anpassung von Attributnamen mittels Umbenennung

  • Vereinigung r_1 \cup r_2 von zwei Relationen r_1 und r_2:

    • Gesamtheit der beiden Tupelmengen
    • Attributmengen beider Relationen müssen identisch sein

  • Differenz r_1 − r_2 eliminiert die Tupel aus der ersten Relation, die auch in der zweiten Relation vorkommen

  • Durchschnitt r_1 \cap r_2: ergibt die Tupel, die in beiden Relationen gemeinsam vorkommen

SQL als Anfragesprache

SELECT farbe FROM weine WHERE Jahrgang = 2002
  • SQL hat Multimengensemantik — Duplikate in Tabellen werden in SQL nicht automatisch unterdrückt!
    • Mengensemantik durch distinct
  • Verknüpfung von Tabellen
    • Kreuzprodukt: select * from Weine, Erzeuger
    • Verbund: select * from Weine natural join Erzeuger
    • Verbund mit Bedingung: select * from Weine, Erzeuger where Weine.Weingut = Erzeuger.Weingut
  • Kombination von Bedingungen
  • Vereinigung in SQL explizit mit union

Änderungsoperationen in SQL

  • insert: Einfügen eines oder mehrerer Tupel in eine Basisrelation oder Sicht
    • INSERT INTO table (attribut) VALUE (ausdruck)
    • optionale Attributliste ermöglicht das Einfügen von unvollständigen Tupeln
    • nicht alle Attribute angegeben ⇝ Wert des fehlenden Attribut Land wird null
  • update: Ändern von einem oder mehreren Tupel in einer Basisrelation oder Sicht
    • UPDATE relation SET attribut=ausdruck
  • delete: Löschen eines oder mehrerer Tupel aus einer Basisrelation oder Sicht
    • DELETE FROM table WHERE id=123
    • Löschoperationen können zur Verletzung von Integritätsbedingungen führen!

Lokale und globale Integritätsbedingungen müssen bei Änderungsoperationen automatisch vom System überprüft werden

Datenbankentwurf im ER-Modell

Datenbankmodelle

Datenbankmodell: Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest.

Datenbankbeschreibungen = Datenbankschemata

  1. statische Eigenschaften
  2. Objekte
  3. Beziehungen
  • inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können,
  1. dynamische Eigenschaften wie
  2. Operationen
  3. Beziehungen zwischen Operationen,
  4. Integritätsbedingungen an
  5. Objekte
  6. Operationen

Datenbankmodelle im Überblick

  • HM: hierarchisches Modell, NWM: Netzwerkmodell, RM: Relationenmodell
  • NF 2 : Modell der geschachtelten (Non-First-Normal-Form = NF 2 ) Relationen, eNF 2 : erweitertes NF 2 -Modell
  • ER: Entity-Relationship-Modell, SDM: semantische Datenmodelle
  • OODM / C++: objektorientierte Datenmodelle auf Basis objektorientierter Programmiersprachen wie C++,
    • OEM: objektorientierte Entwurfsmodelle (etwa UML),
    • ORDM: objektrelationale Datenmodelle

ER Modell

  • Entity: Objekt der realen oder der Vorstellungswelt, über das Informationen zu speichern sind, z.B. Produkte (Wein, Katalog), Winzer oder Kritiker; aber auch Informationen über Ereignisse, wie z.B. Bestellungen
  • Relationship: beschreibt eine Beziehung zwischen Entities, z.B. ein Kunde bestellt einen Wein oder ein Wein wird von einem Winzer angeboten
  • Attribut: repräsentiert eine Eigenschaft von Entities oder Beziehungen, z.B. Name eines Kunden, Farbe eines Weines oder Datum einer Bestellung
    • Attribute modellieren Eigenschaften von Entities oder auch Beziehungen
    • alle Entities eines Entity-Typs haben dieselben Arten von Eigenschaften; Attribute werden somit für Entity-Typen deklariert
  • Werte: primitive Datenelemente, die direkt darstellbar sind
    • Wertemengen sind beschrieben durch Datentypen, die neben einer Wertemenge auch die Grundoperationen auf diesen Werten charakterisieren
    • ER-Modell: vorgegebene Standard-Datentypen, etwa die ganzen Zahlen int, die Zeichenketten string, Datumswerte date etc.
    • jeder Datentyp stellt Wertebereich mit Operationen und Prädikaten dar
  • Entities sind die in einer Datenbank zu repräsentierenden Informationseinheiten
    • im Gegensatz zu Werten nicht direkt darstellbar, sondern nur über ihre Eigenschaften beobachtbar
    • Entities sind eingeteilt in Entity-Typen, etwa E_1 , E_2,...
  • Schlüsselattribute: Teilmenge der gesamten Attribute eines Entity-Typs E(A_1,... , A_m)
    • in jedem Datenbankzustand identifizieren die aktuellen Werte der Schlüsselattribute eindeutig Instanzen des Entity-Typs E
    • bei mehreren möglichen Schlüsselkandidaten: Auswahl eines Primärschlüssels
  • Beziehungstypen: Beziehungen zwischen Entities werden zu Beziehungstypen zusammengefasst
    • Beziehungen können ebenfalls Attribute besitzen

Merkmale von Beziehungen

  • Stelligkeit oder Grad:

    • Anzahl der beteiligten Entity-Typen
    • häufig: binär
    • Beispiel: Lieferant liefert Produkt

  • Kardinalität oder Funktionalität:

    • Anzahl der eingehenden Instanzen eines Entity-Typs
    • Formen: 1:1, 1:n, m:n
    • stellt Integritätsbedingung dar
    • Beispiel: maximal 5 Produkte pro Bestellung

  • 1:1 Beziehung

    • jedem Entity e_1 vom Entity-Typ E_1 ist maximal ein Entity e_2 aus E_2 zugeordnet und umgekehrt
    • Bsp: Prospekt beschreibt Produkt

  • 1:N Beziehung

    • jedem Entity e_1 aus E_1 sind beliebig viele Entities E_2 zugeordnet, aber zu jedem Entity e_2 gibt es maximal ein e_1 aus E_1
    • Bsp: Lieferant liefert Produkte, Mutter hat Kinder

  • N:1 Beziehung

    • invers zu 1:N, auf funktionale Beziehung

  • M:N Bezeihung

    • keine Restriktionen
    • Bsp: Bestellung umfasst Produkte

[min,max]-Notation

  • schränkt die möglichen Teilnahmen von Instanzen der beteiligten Entity-Typen an der Beziehung ein, indem ein minimaler und ein maximaler Wert vorgegeben wird
  • Spezielle Wertangabe für max_i ist ∗

Kardinalitätsangaben

  • [0, ∗] legt keine Einschränkung fest (default)
  • R(E_1 [0, 1], E_2 ) entspricht einer (partiellen) funktionalen Beziehung R : E_1 \rightarrow E_2 , da jede Instanz aus E_1 maximal einer Instanz aus E_2 zugeordnet ist
  • totale funktionale Beziehung wird durch R(E_1 [1, 1], E_2 ) modelliert
  • Beispiele:
    • partielle funktionale Beziehung: lagert_in(Produkt[0,1],Fach[0,3])
    • totale funktionale Beziehung: liefert(Lieferant[0,*],Produkt[1,1])

Weitere Konzepte im ER Modell

  • abhängiger Entity-Typ: Identifikation über funktionale Beziehungen (Bsp x "gehört zu" y)
  • Spezialisierungs-/Generalisierungsbeziehung oder auch IST-Beziehung
    • E1 IST E2
    • entspricht semantisch einer injektiven funktionalen Beziehung
    • Attribute des Entity-Typs E2 treffen auch auf E1 zu: "vererbte" Attribute
    • nicht nur Atrributsdeklarationen vererben sich, sondern auch jeweils die aktuellen Werte für eine Instanz
    • Kardinalitätsangabe immer: IST(E_1[1,1], E_2[0,1])
    • Jede Instanz von E1 nimmt genau einmal an der Ist-Beziehung teil, während Instanzen des Obertyps E2 nicht teilnehmen müssen

Die Konzepte im Überblick:

Begriff Informale Bedeutung
Entity zu repräsentierende Informationseinheit
Entity Typ Gruppierung von Entitys mit gleichen Eigenschaften
Beziehungstyp Gruppierung von Beziehungen zwischen Entitys
Attribut datenwertige Eigenschaft eines Entitys oder einer Beziehung
Schlüssel identifizierende Eigenschaft von Entitys
Kardinalitäten Einschränkung von Beziehungstypen bezüglich der mehrfachen Teilnahme von Entitys an der Beziehung
Stelligkeit Anzahl der an einem Beziehungstyp beteiligten Entity Typen
funktionale Beziehungen Beziehungstyp mit Funktionseigenschaften
abhängige Entitys Entitys, die nur abhängig von anderen Entitys existieren können
IST Beziehung Spezialisierung von Entity Typen
Optionalität Attribute oder Funktionale Beziehungen als partielle Funktionen

Relationaler DB-Entwurf

Phasen des Datenbankentwurfs

  • Datenerhaltung für mehrere Anwendungssysteme und mehrere Jahre
  • Anforderungen an Entwurf:
    • Anwendungsdaten jeder Anwendung sollen aus Daten der Datenbank ableitbar sein (mögl effizient)
    • nur "vernünftige" Daten sollen gespeichert werden
    • nicht-redundante Speicherung

Phasenmodell

Anforderungsanalyse \leftrightarrow Konzeptioneller Entwurf \leftrightarrow Verteilungsentwurf \leftrightarrow Logischer Entwurf \leftrightarrow Datendefinition \leftrightarrow Physischer Entwurf \leftrightarrow Implementierung & Wartung

Anforderungsanalyse

  • Vorgehensweise: Sammeln des Informationsbedarfs in den Fachabteilungen
  • Ergebnis:
    • informale Beschreibung des Fachproblems (Texte, Tabellen, Formblätter,...)
    • Trennen der Informationen über Daten (Datenanalyse) von den Informationen über Funktionen (Funktionsanalyse)
  • "Klassischer" Entwurf: nur Datenanalyse und Folgeschritte
  • Funktionsentwurf: siehe Methoden des Software Engineering

Konzeptioneller Entwurf

  • erste Formale Beschreibung des Fachproblems
  • Sprachmittel: semantisches Datenmodell
  • Vorgehensweise:
    • Modellierung von Sichen z.B. für verschiedene Fachabteilungen
    • Analyse der vorliegenden Sichten in Bezug auf Konflikte
    • Integration der Sichten in ein Gesamtschema
  • Phasen:
    • Sichtentwurf
    • Sichtanalyse
    • Sichtintegration
  • Ergebnis: konzeptionelles Gesamtschema (z.B. ER Schema)

weiteres Vorgehen beim Entwurf

  • ER-Modellierung von verschiedenen Sichten auf Gesamtinformation, z.B. für verschiedene Fachabteilungen eines Unternehmens -> konzeptueller Entwurf
  • Verteilungsentwurf bei verteilter Speicherung
  • Abbildung auf konkretes Implementierungsmodell -> logischer Entwurf
  • Datendefinition, Implementierung und Wartung -> physischer Entwurf

Sichtintegration

  • Analyse der vorliegenden Sichten in Bezug auf Konflikte
  • Integration der Sichten in ein Gesamtschema

Integrationskonflikte

  • Namenskonflikte: Homonyme/Synonyme
  • Typkonflikte: verschiedene Strukturen für das gleiche Element
  • Wertebereichskonflikte: verschiedene Wertebereiche für ein Element
  • Bedingungskonflikte: z.B. verschiedene Schlüssel für ein Element
  • Strukturkonflikte: gleicher Sachverhalt durch unterschiedliche Konstrukte ausgedrückt

Verteilungsentwurf

  • sollen Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteilten Speicherung festgelegt werden
    • horizontale Verteilung z.B. Kunden 1-1000 und Kunden 10001-20000
    • vertikale Verteilung z.B. Adresse in DB1, Konto in DB2

Logischer Entwurf

  • Sprachmittel: Datenmodell des ausgewählten "Realisierungs"DBMS
  • Vorgehensweise
    1. (automatische) Transformation des konzeptionellen Schemas z.B. ER -> relationales Modell
    2. Verbesserung des relationalen Schemas anhand von Gütekriterien
  • Ergebnis: logisches Schema

Datendefinition

  • Umsetzung des logischen Schemas in ein konkretes Schema
  • Sprachmittel: DDL und DML eines DBMS
    • Datenbankdeklaration in der DDL des DBMS
    • Realisierung der Integritätssicherung
    • Definition der Benutzersichten

Physischer Entwurf

  • Ergänzen des physischen Entwurfs um Zugriffsunterstützung bzgl Effizienzverbesserung, z.B. Definition von Indexen
  • Index:
    • Zugriffspfad: Datenstruktur für zusätzlichen, schlüsselbasierten Zugriff auf Tupel
    • meist als B*-Baum realisiert
  • Sprachmittel: Speicherstruktursprache SSL

Indexe in SQL, z.B.: create index WeinIdx on WEINE (Name)

Notwendigkeit für Zugriffspfade:

  • Beispiel: Tabelle mit 100GB Daten, Festplattentransferrate ca 50MB/s
  • Operation: Suchen eines Tupels (Selektion)
  • Implementierung: sequentielles Durchsuchen
  • Aufwand: 102.500/50 = 2048 sec ~ 34 Minuten

Implementierung & Wartung

  • Wartung
  • weitere Optimierung der physischen Ebene
  • Anpassung an neue Anforderungen und Systemplattformen
  • Portierung auf neue Datenbankmanagementsysteme
  • etc

Kapazitätserhaltende Abbildungen

Umsetzung des konzeptionellen Schemas

  • Umsetzung auf logisches Schema
  • Erhaltung der Informationskapazität
  • Kapazitätserhöhende Abbildung: Abbildung auf R mit genau einem Schlüssel K ( K={{A},{B}} )
  • Kapazitätsvermindernde Abbildung: Relationsschema mit einem Schlüssel
  • Kapazitätserhaltende Abbildung: kapazitätserhaltend mit Schlüssel beider Entity Typen im Relationsschema als neuer Schlüssel

ER-auf-RM Abbildung

ER Abbildung auf Relationen

  • Entity-Typen und Beziehungstypen: jeweils auf Relationenschemata
  • Attribute: Attribute des Relationenschemas, Schlüssel werden übernommen
  • Kardinalitäten der Beziehungen: durch Wahl der Schlüssel bei den zugehörigen Relationenschemata ausgedrückt
  • in einigen Fällen: Verschmelzen der Relationenschemata von Entity- und Beziehungstypen
  • zwischen den verbleibenden Relationenschemata diverse Fremdschlüsselbedingungen einführen

Abbildung von Beziehungstypen

  • neues Relationenschema mit allen Attributen des Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der beteiligten Entity-Typen
  • Festlegung der Schlüssel:
    • m:n-Beziehung: beide Primärschlüssel zusammen werden Schlüssel im neuen Relationenschema
    • 1:n-Beziehung: Primärschlüssel der n-Seite (bei der funktionalen Notation die Seite ohne Pfeilspitze) wird Schlüssel im neuen Relationenschema
    • 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel im neuen Relationenschema, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt
  • optionale Beziehungen ([0,1] oder [0,n]) werden nicht verschmolzen
  • bei Kardinalitäten [1,1] oder [1,n] (zwingende Beziehungen) Verschmelzung möglich:
    • 1:n-Beziehung: das Entity-Relationenschema der n-Seite kann in das Relationenschema der Beziehung integriert werden
    • 1:1-Beziehung: beide Entity-Relationenschemata können in das Relationenschema der Beziehung integriert werden

Übersicht über Transformationen

ER Konzept wird abgebildet auf relationales Konzept
Entity Typ E_i Relationsenschema R_i
Attribute von E_i Attribute von R_i
Primärschlüssel P_i Primärschlüssel P_i
Beziehungstyp Relationenschema, Attribute P_1,P_2
dessen Attribute weitere Attribute
1:n P_2 wird Primärschlüssel der Beziehung
1:1 P_1 und P_2 werden Schlüssel der Beziehung
m:n P_1 \cup P_2 wird Primärschlüssel der Beziehung
IST Beziehung R_1 erhält zusätzlichen Schlüssel P_2

Relationale Entwurfstheorie

die Datenbanksprache SQL

Grundlagen von Anfragen: Algebra & Kalkül

Transaktionen, Integrität und Trigger

Sichten und Zugriffskontrolle

NoSQL Datenbanken