Anforderung an Datenbanken
Widerspruchsfreie, dauerhafte, effiziente und schnelle Süpreicherung von Daten jeder Art
Datensicherheit und Datenschutz
Mehrnutzbetrieb
Bedarfsgerechte und optimierte Bereitstellung von Daten
DBMS
Datenbankmanagementsystem
Software und Daten
Ein Datenbankmanagementsystem ist eine Software zur sicheren, konsistenten und persistenten Speicherung großer Datenmengen, mit dem Ziel mehreren Benutzern effizienten,zuverlässigen Zugriff aud Daten zu ermöglichen.
Besteht aus Komponenten zur Abfrage, Verwaltung und Administration der Daten.
RDBMS
relationale DBMS
SQL als Abfragesprache
Daten
Folgen von Zeichen oder strukturierte Objekte
Informationen
Aus Daten entstehen Informationen, wenn die Bedeutung bekannt ist.
Durch die Hinzunahme von Informationen kann das ursprüngliche Datum intepretiert werden
Wissen
Wissen entsteht durch systematische Verknüpfung von daten, Informationen und subjektiver Erfahrung
Redundanz und Konsistenz
Redundante Daten ermöglichen inkonsistente Daten und belegen Speicher
Integrität und Transaktion
Transaktionen sichern mehrer datenbewegungen als eine Aktion ab, die ganz oder gar nicht ausgeführt wird.
Fehlende Transaktionen ermöglichen korrupte Daten.
Relationen
In jeder ernsthaften Datenmenge gibt es abzubilkdende Beziehungen.
ORM
Object Relational Mapping
Object-Relational Mapping bzw. ORM ist eine Technik der Softwareentwicklung, mit der ein in einer objektorientierten Programmiersprache geschriebenes Anwendungsprogramm seine Objekte in einer relationalen Datenbank ablegen kann. Dem Programm erscheint die Datenbank dann als objektorientierte Datenbank, was die Programmierung erleichtert. Implementiert wird diese Technik normalerweise mit Klassenbibliotheken, wie beispielsweise Entity Framework für .NET-Programmiersprachen, Hibernate für Java. Man unterscheidet zwischen den Varianten: • Statisches Mapping – Klassen – Vererbung – Aggregation, Komposition, Assoziation • Dynamisches Mappinga – Constraints und Trigger – Performance: Dirty Checking, Lazy Fetching, Caching
Abbildung von Vererbungshierachien
• Tabelle pro Vererbungshierarchie bzw. Single Table: – alle Attribute der Basisklasse und aller abgeleiteten Klassen in gemeinsamer Tabelle – Diskriminator in weiterer Spalte abgelegt, der festlegt, welcher Klasse das in dieser Zeile gespeicherte Objekt angehört – Attribute von abgeleiteten Klassen dürfen den meisten Fällen nicht mit einem NOT-NULL-Constraint versehen werden
• Tabelle pro Unterklasse bzw. Joined : – eine Tabelle für die Basisklasse und für Unterklasse eine weitere Tabelle – Diskriminator wird nicht benötigt, weil Klasse eines Objekts durch 1:1-Beziehung festgelegt ist
• Table per Class: – Attribute der abstrakten Basisklasse in die Tabellen für die konkreten Unterklassen mit aufgenommen – Tabelle für Basisklasse entfällt – Nachteil besteht darin, dass es nicht möglich ist, mit einer Abfrage Instanzen verschiedener Klassen zu ermitteln
Transaktion im DBMS
ACID
Der Begriff ACID beschreibt Regeln und Eigenschaften zur Durchführung von Transaktionen in Datenbankmanagementsystemen. Dabei steht ACID für:
• Atomicity (Atomarität) – atomar in dem Sinne, dass entweder alle Operationen der Transaktion bedingten Änderungen in der Datenbank umgesetzt werden, oder gar keine
• Consistency (Konsistenz) – Ausgangspunkt ist konsistente Datenbank vor Beginn einer Transaktion – am Ende einer Transaktion ist Datenbank in konsistentem Zustand, d.h. * entweder jede Integritätsregel ist erfüllt(dann wieder von vorne)
• Isolation (Nebenläufigkeit) – parallele bzw. gleichzeitig ausgeführte Transaktionen beeinflussen sich nichtb – Locking (Lese- bzw. Schreibsperre)
• Durability) (Dauerhaftigkeit) – nach Abschluss einer Transaktion haben ausgeführte Änderungen dauerhaft Bestand ACID wird häufig zur Charakterisierung eines DBMS genannt, insbesondere auch für NichtRelationale DBMS.
Lost Update
Zwei Transaktionen modifizieren parallel denselben Datensatz und nach Ablauf dieser beiden Transaktionen wird nur die Änderung von einer von ihnen übernommen.
Dirty Read
Daten einer noch nicht abgeschlossenen Transaktion werden von einer anderen Transaktion gelesen
Locking
Unter Locking versteht man das Sperren des Zugriffs auf ein Betriebsmittel. Eine solche Sperre ermöglicht den exklusiven Zugriff eines Prozesses auf eine Ressource, d. h. mit der Garantie, dass kein anderer Prozess diese Ressource liest oder verändert, solange die Sperre besteht. Regeln beim Locking: • Jedes Objekt muss vor der Benutzung gesperrt werden. • Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an. • Eine Transaktion respektiert vorhandene Sperren und wird ggf. in eine Warteschlange eingereiht. • Jede Transaktion durchläuft zwei Phasen: – Wachstumsphase (nur Sperren anfordern) – Freigabephase (nur Sperren freigeben) • Spätestens bei Transaktionsende muss eine Transaktion all ihre Sperren zurückgeben.
Lesesperre
Besitzt eine Ressource eine Lesesperre („Shared Lock“), so möchte der Prozess, der diese Sperre gesetzt hat, von der Ressource nur lesen. Somit können auch andere Prozesse auf diese Ressource lesend zugreifen, dürfen diese aber nicht verändern. Bonus: Schreibsperre Besitzt eine Ressource eine
Schreibsperre
Besitzt eine Ressource eine Schreibsperre („Exclusive Lock“), wird verhindert, dass die Ressource von anderen Prozessen gelesen oder geschrieben wird, da der Prozess, der den Lock gesetzt hat, die Ressource verändern möchte. Es wird vorausgesetzt, dass keine Lesesperre auf die Ressource gesetzt ist.
Zusammenhang ORM
Idee
• Abbildung von Vererbungshirarchien.
• Je nach Anwendungsfall mehrere sinnvolle Möglichkeiten der Implementierung.
• Wer entscheidet, wie modelliert wird?
• Probleme erscheinen u.a. auch beim Weiterentwickeln der Software und der Synchronisation von Klassen und Daten im DBMS
Last changeda year ago