Verteiltes DBMS - Kurzanleitung

Für das ordnungsgemäße Funktionieren einer Organisation ist eine gut gepflegte Datenbank erforderlich. In der jüngeren Vergangenheit waren Datenbanken zentraler Natur. Mit der zunehmenden Globalisierung sind Unternehmen jedoch weltweit tendenziell diversifiziert. Sie können Daten anstelle einer zentralen Datenbank auf lokale Server verteilen. So kam das Konzept vonDistributed Databases.

Dieses Kapitel gibt einen Überblick über Datenbanken und Datenbankverwaltungssysteme (DBMS). Eine Datenbank ist eine geordnete Sammlung verwandter Daten. Ein DBMS ist ein Softwarepaket zur Bearbeitung einer Datenbank. Eine detaillierte Studie zu DBMS finden Sie in unserem Tutorial mit dem Titel „Learn DBMS“. In diesem Kapitel überarbeiten wir die Hauptkonzepte, damit das Studium von DDBMS problemlos durchgeführt werden kann. Die drei behandelten Themen sind Datenbankschemata, Datenbanktypen und Operationen an Datenbanken.

Datenbank und Datenbankverwaltungssystem

EIN databaseist eine geordnete Sammlung verwandter Daten, die für einen bestimmten Zweck erstellt wurden. Eine Datenbank kann als Sammlung mehrerer Tabellen organisiert sein, wobei eine Tabelle ein Element oder eine Entität der realen Welt darstellt. Jede Tabelle verfügt über mehrere verschiedene Felder, die die charakteristischen Merkmale der Entität darstellen.

Beispielsweise kann eine Unternehmensdatenbank Tabellen für Projekte, Mitarbeiter, Abteilungen, Produkte und Finanzaufzeichnungen enthalten. Die Felder in der Employee-Tabelle können Name, Company_Id, Date_of_Joining usw. sein.

EIN database management systemist eine Sammlung von Programmen, die die Erstellung und Pflege einer Datenbank ermöglichen. DBMS ist als Softwarepaket verfügbar, das die Definition, Erstellung, Bearbeitung und gemeinsame Nutzung von Daten in einer Datenbank erleichtert. Die Definition einer Datenbank enthält eine Beschreibung der Struktur einer Datenbank. Beim Aufbau einer Datenbank werden die Daten tatsächlich auf einem beliebigen Speichermedium gespeichert. Manipulation bezieht sich auf das Abrufen von Informationen aus der Datenbank, das Aktualisieren der Datenbank und das Generieren von Berichten. Durch die gemeinsame Nutzung von Daten können verschiedene Benutzer oder Programme auf Daten zugreifen.

Beispiele für DBMS-Anwendungsbereiche

• Geldautomaten
• Zugreservierungssystem
• Mitarbeiter-Management-System
• Studenteninformationssystem

Beispiele für DBMS-Pakete

• MySQL
• Oracle
• SQL Server
• dBASE
• FoxPro
• PostgreSQL usw.

Datenbankschemata

Ein Datenbankschema ist eine Beschreibung der Datenbank, die während des Datenbankdesigns angegeben wird und nur selten geändert wird. Es definiert die Organisation der Daten, die Beziehungen zwischen ihnen und die damit verbundenen Einschränkungen.

Datenbanken werden häufig durch die dargestellt three-schema architecture oder ANSISPARC architecture. Ziel dieser Architektur ist es, die Benutzeranwendung von der physischen Datenbank zu trennen. Die drei Ebenen sind -

• Internal Level having Internal Schema - Es beschreibt die physische Struktur, Details des internen Speichers und Zugriffspfade für die Datenbank.

• Conceptual Level having Conceptual Schema- Es beschreibt die Struktur der gesamten Datenbank, während die Details der physischen Speicherung von Daten ausgeblendet werden. Dies zeigt die Entitäten, Attribute mit ihren Datentypen und Einschränkungen, Benutzeroperationen und Beziehungen.

• External or View Level having External Schemas or Views - Es beschreibt den Teil einer Datenbank, der für einen bestimmten Benutzer oder eine Gruppe von Benutzern relevant ist, während der Rest der Datenbank ausgeblendet wird.

Arten von DBMS

Es gibt vier Arten von DBMS.

Hierarchisches DBMS

Im hierarchischen DBMS werden die Beziehungen zwischen Daten in der Datenbank so hergestellt, dass ein Datenelement als Untergebenes eines anderen existiert. Die Datenelemente haben Eltern-Kind-Beziehungen und werden mithilfe der Baumstruktur „Baum“ modelliert. Diese sind sehr schnell und einfach.

Netzwerk-DBMS

Netzwerk-DBMS in einem, bei dem die Beziehungen zwischen Daten in der Datenbank vom Typ Viele-zu-Viele in Form eines Netzwerks sind. Die Struktur ist im Allgemeinen kompliziert, da zahlreiche Viele-zu-Viele-Beziehungen bestehen. Das Netzwerk-DBMS wird mithilfe der Diagrammstruktur „Graph“ modelliert.

Relationales DBMS

In relationalen Datenbanken wird die Datenbank in Form von Beziehungen dargestellt. Jede Beziehung modelliert eine Entität und wird als Wertetabelle dargestellt. In der Beziehung oder Tabelle wird eine Zeile als Tupel bezeichnet und bezeichnet einen einzelnen Datensatz. Eine Spalte wird als Feld oder Attribut bezeichnet und bezeichnet eine charakteristische Eigenschaft der Entität. RDBMS ist das beliebteste Datenbankverwaltungssystem.

Zum Beispiel - Eine Studentenbeziehung -

Objektorientiertes DBMS

Objektorientiertes DBMS wird aus dem Modell des objektorientierten Programmierparadigmas abgeleitet. Sie sind hilfreich bei der Darstellung sowohl konsistenter Daten, wie sie in Datenbanken gespeichert sind, als auch vorübergehender Daten, wie sie bei der Ausführung von Programmen zu finden sind. Sie verwenden kleine, wiederverwendbare Elemente, die als Objekte bezeichnet werden. Jedes Objekt enthält einen Datenteil und eine Reihe von Operationen, die mit den Daten arbeiten. Auf das Objekt und seine Attribute wird über Zeiger zugegriffen, anstatt in relationalen Tabellenmodellen gespeichert zu werden.

Zum Beispiel - Eine vereinfachte objektorientierte Datenbank für Bankkonten -

Verteiltes DBMS

Eine verteilte Datenbank ist eine Reihe miteinander verbundener Datenbanken, die über das Computernetzwerk oder das Internet verteilt sind. Ein verteiltes Datenbankverwaltungssystem (DDBMS) verwaltet die verteilte Datenbank und stellt Mechanismen bereit, um die Datenbanken für die Benutzer transparent zu machen. In diesen Systemen werden Daten absichtlich auf mehrere Knoten verteilt, sodass alle Computerressourcen der Organisation optimal genutzt werden können.

Operationen auf DBMS

Die vier grundlegenden Vorgänge in einer Datenbank sind Erstellen, Abrufen, Aktualisieren und Löschen.

• CREATE Datenbankstruktur und Auffüllen mit Daten - Zum Erstellen einer Datenbankbeziehung müssen die Datenstrukturen, Datentypen und Einschränkungen der zu speichernden Daten angegeben werden.

  Example - SQL-Befehl zum Erstellen einer Schülertabelle -

CREATE TABLE STUDENT ( 
   ROLL INTEGER PRIMARY KEY, 
   NAME VARCHAR2(25), 
   YEAR INTEGER, 
   STREAM VARCHAR2(10) 
);

• Sobald das Datenformat definiert ist, werden die tatsächlichen Daten gemäß dem Format auf einem Speichermedium gespeichert.

  Example SQL-Befehl zum Einfügen eines einzelnen Tupels in die Schülertabelle -

INSERT INTO STUDENT ( ROLL, NAME, YEAR, STREAM) 
VALUES ( 1, 'ANKIT JHA', 1, 'COMPUTER SCIENCE');

• RETRIEVEInformationen aus der Datenbank - Das Abrufen von Informationen umfasst im Allgemeinen das Auswählen einer Teilmenge einer Tabelle oder das Anzeigen von Daten aus der Tabelle, nachdem einige Berechnungen durchgeführt wurden. Dies geschieht durch Abfragen auf dem Tisch.

  Example - Um die Namen aller Schüler des Informatik-Streams abzurufen, muss die folgende SQL-Abfrage ausgeführt werden: -

SELECT NAME FROM STUDENT 
WHERE STREAM = 'COMPUTER SCIENCE';

• UPDATE Gespeicherte Informationen und Ändern der Datenbankstruktur - Beim Aktualisieren einer Tabelle werden alte Werte in den Zeilen der vorhandenen Tabelle durch neue Werte geändert.

  Example - SQL-Befehl zum Ändern des Streams von Elektronik zu Elektronik und Kommunikation -

UPDATE STUDENT 
SET STREAM = 'ELECTRONICS AND COMMUNICATIONS' 
WHERE STREAM = 'ELECTRONICS';

• Ändern der Datenbank bedeutet, die Struktur der Tabelle zu ändern. Die Änderung der Tabelle unterliegt jedoch einer Reihe von Einschränkungen.

  Example - Um ein neues Feld oder eine neue Spalte hinzuzufügen, z. B. Adresse zur Student-Tabelle, verwenden wir den folgenden SQL-Befehl: -

ALTER TABLE STUDENT 
ADD ( ADDRESS VARCHAR2(50) );

• DELETE gespeicherte Informationen oder Löschen einer Tabelle als Ganzes - Beim Löschen bestimmter Informationen werden ausgewählte Zeilen aus der Tabelle entfernt, die bestimmte Bedingungen erfüllen.

  Example- Um alle Schüler zu löschen , die in 4 ^th Jahr zur Zeit , wenn sie heraus überschreiten, verwenden wir den SQL - Befehl -

DELETE FROM STUDENT 
WHERE YEAR = 4;

• Alternativ kann die gesamte Tabelle aus der Datenbank entfernt werden.

  Example - Um die Schülertabelle vollständig zu entfernen, wird folgender SQL-Befehl verwendet:

DROP TABLE STUDENT;

In diesem Kapitel wird das Konzept von DDBMS vorgestellt. In einer verteilten Datenbank gibt es eine Reihe von Datenbanken, die möglicherweise geografisch auf der ganzen Welt verteilt sind. Ein verteiltes DBMS verwaltet die verteilte Datenbank so, dass sie den Benutzern als eine einzige Datenbank angezeigt wird. Im späteren Teil des Kapitels untersuchen wir die Faktoren, die zu verteilten Datenbanken führen, sowie deren Vor- und Nachteile.

EIN distributed database ist eine Sammlung mehrerer miteinander verbundener Datenbanken, die physisch über verschiedene Standorte verteilt sind, die über ein Computernetzwerk kommunizieren.

Eigenschaften

• Datenbanken in der Sammlung sind logisch miteinander verknüpft. Oft repräsentieren sie eine einzelne logische Datenbank.

• Daten werden physisch an mehreren Standorten gespeichert. Daten an jedem Standort können von einem DBMS unabhängig von den anderen Standorten verwaltet werden.

• Die Prozessoren an den Standorten sind über ein Netzwerk verbunden. Sie haben keine Multiprozessorkonfiguration.

• Eine verteilte Datenbank ist kein lose verbundenes Dateisystem.

• Eine verteilte Datenbank enthält eine Transaktionsverarbeitung, ist jedoch nicht gleichbedeutend mit einem Transaktionsverarbeitungssystem.

Verteiltes Datenbankverwaltungssystem

Ein verteiltes Datenbankverwaltungssystem (DDBMS) ist ein zentrales Softwaresystem, das eine verteilte Datenbank so verwaltet, als ob alles an einem einzigen Ort gespeichert wäre.

Eigenschaften

• Es wird zum Erstellen, Abrufen, Aktualisieren und Löschen verteilter Datenbanken verwendet.

• Es synchronisiert die Datenbank regelmäßig und bietet Zugriffsmechanismen, durch die die Verteilung für die Benutzer transparent wird.

• Es stellt sicher, dass die an jedem Standort geänderten Daten universell aktualisiert werden.

• Es wird in Anwendungsbereichen verwendet, in denen große Datenmengen von zahlreichen Benutzern gleichzeitig verarbeitet und abgerufen werden.

• Es ist für heterogene Datenbankplattformen konzipiert.

• Es bewahrt die Vertraulichkeit und Datenintegrität der Datenbanken.

Faktoren, die DDBMS fördern

Die folgenden Faktoren fördern die Umstellung auf DDBMS:

• Distributed Nature of Organizational Units- Die meisten Organisationen in der heutigen Zeit sind in mehrere Einheiten unterteilt, die physisch über den Globus verteilt sind. Jede Einheit benötigt einen eigenen Satz lokaler Daten. Somit wird die Gesamtdatenbank der Organisation verteilt.

• Need for Sharing of Data- Die mehreren Organisationseinheiten müssen häufig miteinander kommunizieren und ihre Daten und Ressourcen gemeinsam nutzen. Dies erfordert gemeinsame Datenbanken oder replizierte Datenbanken, die synchron verwendet werden sollten.

• Support for Both OLTP and OLAP- Online Transaction Processing (OLTP) und Online Analytical Processing (OLAP) arbeiten mit diversifizierten Systemen, die möglicherweise gemeinsame Daten haben. Verteilte Datenbanksysteme unterstützen beide Verarbeitungen, indem sie synchronisierte Daten bereitstellen.

• Database Recovery- Eine der in DDBMS gebräuchlichen Techniken ist die Replikation von Daten über verschiedene Standorte hinweg. Die Replikation von Daten hilft automatisch bei der Datenwiederherstellung, wenn die Datenbank an einem Standort beschädigt ist. Benutzer können auf Daten von anderen Sites zugreifen, während die beschädigte Site rekonstruiert wird. Daher kann ein Datenbankfehler für Benutzer fast unauffällig werden.

• Support for Multiple Application Software- Die meisten Organisationen verwenden eine Vielzahl von Anwendungssoftware mit jeweils spezifischer Datenbankunterstützung. DDBMS bietet eine einheitliche Funktionalität für die Verwendung derselben Daten auf verschiedenen Plattformen.

Vorteile verteilter Datenbanken

Im Folgenden sind die Vorteile verteilter Datenbanken gegenüber zentralisierten Datenbanken aufgeführt.

Modular Development- Wenn das System in zentralisierten Datenbanksystemen auf neue Standorte oder neue Einheiten erweitert werden muss, erfordert die Aktion erhebliche Anstrengungen und Störungen in der bestehenden Funktionsweise. In verteilten Datenbanken müssen für die Arbeit lediglich neue Computer und lokale Daten zum neuen Standort hinzugefügt und schließlich mit dem verteilten System verbunden werden, ohne dass die aktuellen Funktionen unterbrochen werden.

More Reliable- Bei Datenbankfehlern kommt das Gesamtsystem der zentralisierten Datenbanken zum Stillstand. In verteilten Systemen kann es jedoch zu einer verminderten Leistung kommen, wenn eine Komponente ausfällt. Daher ist DDBMS zuverlässiger.

Better Response- Wenn Daten auf effiziente Weise verteilt werden, können Benutzeranforderungen von lokalen Daten selbst erfüllt werden, wodurch eine schnellere Antwort ermöglicht wird. Andererseits müssen in zentralisierten Systemen alle Abfragen zur Verarbeitung durch den Zentralcomputer geleitet werden, was die Antwortzeit verlängert.

Lower Communication Cost- Wenn sich Daten in verteilten Datenbanksystemen lokal dort befinden, wo sie hauptsächlich verwendet werden, können die Kommunikationskosten für die Datenmanipulation minimiert werden. Dies ist in zentralisierten Systemen nicht möglich.

Widrigkeiten verteilter Datenbanken

Im Folgenden sind einige der mit verteilten Datenbanken verbundenen Widrigkeiten aufgeführt.

• Need for complex and expensive software - DDBMS erfordert komplexe und oft teure Software, um Datentransparenz und -koordination über die verschiedenen Standorte hinweg zu gewährleisten.

• Processing overhead - Selbst einfache Vorgänge erfordern möglicherweise eine große Anzahl von Kommunikationen und zusätzlichen Berechnungen, um eine einheitliche Datenverteilung über die Standorte hinweg zu gewährleisten.

• Data integrity - Die Notwendigkeit, Daten an mehreren Standorten zu aktualisieren, wirft Probleme mit der Datenintegrität auf.

• Overheads for improper data distribution- Die Reaktionsfähigkeit von Anfragen hängt weitgehend von der richtigen Datenverteilung ab. Eine unsachgemäße Datenverteilung führt häufig zu einer sehr langsamen Reaktion auf Benutzeranforderungen.

In diesem Teil des Tutorials werden wir die verschiedenen Aspekte untersuchen, die beim Entwerfen verteilter Datenbankumgebungen hilfreich sind. Dieses Kapitel beginnt mit den Arten verteilter Datenbanken. Verteilte Datenbanken können in homogene und heterogene Datenbanken mit weiteren Unterteilungen eingeteilt werden. Im nächsten Abschnitt dieses Kapitels werden die verteilten Architekturen Client-Server, Peer-to-Peer und Multi-DBMS erläutert. Schließlich werden die verschiedenen Entwurfsalternativen wie Replikation und Fragmentierung vorgestellt.

Arten verteilter Datenbanken

Verteilte Datenbanken können grob in homogene und heterogene verteilte Datenbankumgebungen mit jeweils weiteren Unterteilungen unterteilt werden, wie in der folgenden Abbildung dargestellt.

Homogene verteilte Datenbanken

In einer homogen verteilten Datenbank verwenden alle Standorte identische DBMS- und Betriebssysteme. Seine Eigenschaften sind -

• Die Websites verwenden sehr ähnliche Software.

• Die Sites verwenden identisches DBMS oder DBMS desselben Herstellers.

• Jede Site kennt alle anderen Sites und arbeitet mit anderen Sites zusammen, um Benutzeranforderungen zu verarbeiten.

• Der Zugriff auf die Datenbank erfolgt über eine einzelne Schnittstelle, als wäre es eine einzelne Datenbank.

Arten von homogenen verteilten Datenbanken

Es gibt zwei Arten von homogenen verteilten Datenbanken:

• Autonomous- Jede Datenbank ist unabhängig und funktioniert für sich. Sie werden von einer steuernden Anwendung integriert und verwenden die Nachrichtenübermittlung, um Datenaktualisierungen gemeinsam zu nutzen.

• Non-autonomous - Die Daten werden auf die homogenen Knoten verteilt, und ein zentrales oder Master-DBMS koordiniert die Datenaktualisierungen über die Standorte hinweg.

Heterogene verteilte Datenbanken

In einer heterogenen verteilten Datenbank haben verschiedene Standorte unterschiedliche Betriebssysteme, DBMS-Produkte und Datenmodelle. Seine Eigenschaften sind -

• Verschiedene Sites verwenden unterschiedliche Schemata und Software.

• Das System kann aus einer Vielzahl von DBMS bestehen, z. B. relational, netzwerk-, hierarchisch oder objektorientiert.

• Die Abfrageverarbeitung ist aufgrund unterschiedlicher Schemata komplex.

• Die Transaktionsverarbeitung ist aufgrund unterschiedlicher Software komplex.

• Eine Site kennt möglicherweise keine anderen Sites und daher besteht eine eingeschränkte Zusammenarbeit bei der Verarbeitung von Benutzeranforderungen.

Arten heterogen verteilter Datenbanken

• Federated - Die heterogenen Datenbanksysteme sind von Natur aus unabhängig und so integriert, dass sie als ein einziges Datenbanksystem fungieren.

• Un-federated - Die Datenbanksysteme verwenden ein zentrales Koordinierungsmodul, über das auf die Datenbanken zugegriffen wird.

Verteilte DBMS-Architekturen

DDBMS-Architekturen werden im Allgemeinen in Abhängigkeit von drei Parametern entwickelt:

• Distribution - Es gibt die physische Verteilung der Daten auf die verschiedenen Standorte an.

• Autonomy - Es gibt die Verteilung der Kontrolle über das Datenbanksystem und den Grad an, in dem jeder DBMS-Bestandteil unabhängig arbeiten kann.

• Heterogeneity - Es bezieht sich auf die Einheitlichkeit oder Unähnlichkeit der Datenmodelle, Systemkomponenten und Datenbanken.

Architekturmodelle

Einige der gängigen Architekturmodelle sind -

• Client-Server-Architektur für DDBMS
• Peer-to-Peer-Architektur für DDBMS
• Multi-DBMS-Architektur

Client-Server-Architektur für DDBMS

Dies ist eine zweistufige Architektur, bei der die Funktionalität in Server und Clients unterteilt ist. Die Serverfunktionen umfassen hauptsächlich Datenverwaltung, Abfrageverarbeitung, Optimierung und Transaktionsverwaltung. Client-Funktionen umfassen hauptsächlich Benutzeroberfläche. Sie verfügen jedoch über einige Funktionen wie Konsistenzprüfung und Transaktionsverwaltung.

Die zwei verschiedenen Client-Server-Architekturen sind:

• Single Server Multiple Client
• Multiple Server Multiple Client (in der folgenden Abbildung dargestellt)

Peer-to-Peer-Architektur für DDBMS

In diesen Systemen fungiert jeder Peer sowohl als Client als auch als Server für die Vermittlung von Datenbankdiensten. Die Peers teilen ihre Ressourcen mit anderen Peers und koordinieren ihre Aktivitäten.

Diese Architektur hat im Allgemeinen vier Ebenen von Schemata -

• Global Conceptual Schema - Zeigt die globale logische Ansicht von Daten.

• Local Conceptual Schema - Zeigt die logische Datenorganisation an jedem Standort.

• Local Internal Schema - Zeigt die physische Datenorganisation an jedem Standort an.

• External Schema - Zeigt die Benutzeransicht von Daten.

Multi-DBMS-Architekturen

Dies ist ein integriertes Datenbanksystem, das aus einer Sammlung von zwei oder mehr autonomen Datenbanksystemen besteht.

Multi-DBMS kann durch sechs Schemaebenen ausgedrückt werden -

• Multi-database View Level - Zeigt mehrere Benutzeransichten, die aus Teilmengen der integrierten verteilten Datenbank bestehen.

• Multi-database Conceptual Level - Zeigt eine integrierte Multi-Datenbank, die globale logische Multi-Datenbank-Strukturdefinitionen enthält.

• Multi-database Internal Level - Zeigt die Datenverteilung über verschiedene Standorte und die Zuordnung mehrerer Datenbanken zu lokalen Daten.

• Local database View Level - Zeigt die öffentliche Ansicht lokaler Daten.

• Local database Conceptual Level - Zeigt die lokale Datenorganisation an jedem Standort.

• Local database Internal Level - Zeigt die physische Datenorganisation an jedem Standort an.

Es gibt zwei Entwurfsalternativen für Multi-DBMS:

• Modell mit konzeptioneller Ebene für mehrere Datenbanken.
• Modell ohne konzeptionelle Ebene mit mehreren Datenbanken.

Designalternativen

Die Verteilungsentwurfsalternativen für die Tabellen in einem DDBMS lauten wie folgt:

• Nicht repliziert und nicht fragmentiert
• Vollständig repliziert
• Teilweise repliziert
• Fragmented
• Mixed

Nicht repliziert und nicht fragmentiert

Bei dieser Entwurfsalternative werden verschiedene Tabellen an verschiedenen Standorten platziert. Die Daten werden so platziert, dass sie sich in unmittelbarer Nähe des Standorts befinden, an dem sie am häufigsten verwendet werden. Es eignet sich am besten für Datenbanksysteme, bei denen der Prozentsatz der Abfragen, die zum Verknüpfen von Informationen in Tabellen an verschiedenen Standorten erforderlich sind, gering ist. Wenn eine geeignete Verteilungsstrategie angewendet wird, hilft diese Entwurfsalternative, die Kommunikationskosten während der Datenverarbeitung zu reduzieren.

Vollständig repliziert

Bei dieser Entwurfsalternative wird an jedem Standort eine Kopie aller Datenbanktabellen gespeichert. Da jeder Standort über eine eigene Kopie der gesamten Datenbank verfügt, sind Abfragen sehr schnell und erfordern vernachlässigbare Kommunikationskosten. Im Gegenteil, die massive Redundanz der Daten erfordert enorme Kosten bei Aktualisierungsvorgängen. Dies ist daher für Systeme geeignet, bei denen eine große Anzahl von Abfragen bearbeitet werden muss, während die Anzahl der Datenbankaktualisierungen gering ist.

Teilweise repliziert

Kopien von Tabellen oder Teilen von Tabellen werden an verschiedenen Standorten gespeichert. Die Verteilung der Tabellen erfolgt entsprechend der Zugriffshäufigkeit. Dies berücksichtigt die Tatsache, dass die Häufigkeit des Zugriffs auf die Tabellen von Standort zu Standort erheblich variiert. Die Anzahl der Kopien der Tabellen (oder Teile) hängt davon ab, wie häufig die Zugriffsabfragen ausgeführt werden und von welcher Site die Zugriffsabfragen generiert werden.

Fragmentiert

Bei diesem Entwurf ist eine Tabelle in zwei oder mehr Teile unterteilt, die als Fragmente oder Partitionen bezeichnet werden, und jedes Fragment kann an verschiedenen Orten gespeichert werden. Dies berücksichtigt die Tatsache, dass es selten vorkommt, dass alle in einer Tabelle gespeicherten Daten an einem bestimmten Standort erforderlich sind. Darüber hinaus erhöht die Fragmentierung die Parallelität und bietet eine bessere Notfallwiederherstellung. Hier gibt es nur eine Kopie jedes Fragments im System, dh keine redundanten Daten.

Die drei Fragmentierungstechniken sind -

• Vertikale Fragmentierung
• Horizontale Fragmentierung
• Hybridfragmentierung

Gemischte Verteilung

Dies ist eine Kombination aus Fragmentierung und Teilreplikationen. Hier werden die Tabellen zunächst in irgendeiner Form (horizontal oder vertikal) fragmentiert, und dann werden diese Fragmente je nach Häufigkeit des Zugriffs auf die Fragmente teilweise über die verschiedenen Standorte hinweg repliziert.

Im letzten Kapitel hatten wir verschiedene Designalternativen vorgestellt. In diesem Kapitel werden wir die Strategien untersuchen, die bei der Übernahme der Entwürfe helfen. Die Strategien können grob in Replikation und Fragmentierung unterteilt werden. In den meisten Fällen wird jedoch eine Kombination aus beiden verwendet.

Datenreplikation

Bei der Datenreplikation werden separate Kopien der Datenbank an zwei oder mehr Standorten gespeichert. Es ist eine beliebte Fehlertoleranztechnik für verteilte Datenbanken.

Vorteile der Datenreplikation

• Reliability - Bei Ausfall eines Standorts funktioniert das Datenbanksystem weiter, da eine Kopie an einem anderen Standort verfügbar ist.

• Reduction in Network Load- Da lokale Kopien von Daten verfügbar sind, kann die Abfrageverarbeitung mit reduzierter Netzwerknutzung durchgeführt werden, insbesondere während der Hauptverkehrszeiten. Die Datenaktualisierung kann außerhalb der Hauptverkehrszeiten erfolgen.

• Quicker Response - Die Verfügbarkeit lokaler Kopien von Daten gewährleistet eine schnelle Abfrageverarbeitung und folglich eine schnelle Antwortzeit.

• Simpler Transactions- Transaktionen erfordern weniger Verknüpfungen von Tabellen an verschiedenen Standorten und minimale Koordination im gesamten Netzwerk. Dadurch werden sie einfacher.

Nachteile der Datenreplikation

• Increased Storage Requirements- Das Verwalten mehrerer Kopien von Daten ist mit erhöhten Speicherkosten verbunden. Der erforderliche Speicherplatz entspricht einem Vielfachen des für ein zentrales System erforderlichen Speichers.

• Increased Cost and Complexity of Data Updating- Jedes Mal, wenn ein Datenelement aktualisiert wird, muss das Update in allen Kopien der Daten an den verschiedenen Standorten berücksichtigt werden. Dies erfordert komplexe Synchronisationstechniken und -protokolle.

• Undesirable Application – Database coupling- Wenn keine komplexen Aktualisierungsmechanismen verwendet werden, erfordert das Entfernen von Dateninkonsistenzen eine komplexe Koordination auf Anwendungsebene. Dies führt zu einer unerwünschten Kopplung zwischen Anwendung und Datenbank.

Einige häufig verwendete Replikationstechniken sind:

• Snapshot-Replikation
• Echtzeit-Replikation
• Replikation ziehen

Zersplitterung

Fragmentierung ist die Aufgabe, eine Tabelle in eine Reihe kleinerer Tabellen zu unterteilen. Die Teilmengen der Tabelle werden aufgerufenfragments. Es gibt drei Arten der Fragmentierung: horizontal, vertikal und hybrid (Kombination aus horizontal und vertikal). Die horizontale Fragmentierung kann ferner in zwei Techniken eingeteilt werden: primäre horizontale Fragmentierung und abgeleitete horizontale Fragmentierung.

Die Fragmentierung sollte so erfolgen, dass die ursprüngliche Tabelle aus den Fragmenten rekonstruiert werden kann. Dies ist erforderlich, damit die ursprüngliche Tabelle bei Bedarf aus den Fragmenten rekonstruiert werden kann. Diese Anforderung wird als "Rekonstruktivität" bezeichnet.

Vorteile der Fragmentierung

• Da Daten in der Nähe des Verwendungsorts gespeichert werden, wird die Effizienz des Datenbanksystems erhöht.

• Lokale Abfrageoptimierungstechniken sind für die meisten Abfragen ausreichend, da Daten lokal verfügbar sind.

• Da an den Standorten keine irrelevanten Daten verfügbar sind, können Sicherheit und Datenschutz des Datenbanksystems gewahrt werden.

Nachteile der Fragmentierung

• Wenn Daten aus verschiedenen Fragmenten benötigt werden, können die Zugriffsgeschwindigkeiten sehr hoch sein.

• Im Falle rekursiver Fragmentierungen erfordert die Rekonstruktion teure Techniken.

• Das Fehlen von Sicherungskopien von Daten an verschiedenen Standorten kann die Datenbank im Falle eines Ausfalls eines Standorts unwirksam machen.

Vertikale Fragmentierung

Bei der vertikalen Fragmentierung werden die Felder oder Spalten einer Tabelle in Fragmente gruppiert. Um die Rekonstruktivität aufrechtzuerhalten, sollte jedes Fragment die Primärschlüsselfelder der Tabelle enthalten. Die vertikale Fragmentierung kann verwendet werden, um den Datenschutz von Daten zu erzwingen.

Angenommen, eine Universitätsdatenbank enthält Aufzeichnungen aller registrierten Studenten in einer Studententabelle mit dem folgenden Schema.

STUDENT

Regd_No

Name

Kurs

Adresse

Semester

Gebühren

Markierungen

Jetzt werden die Gebührendetails im Kontenbereich verwaltet. In diesem Fall fragmentiert der Designer die Datenbank wie folgt:

CREATE TABLE STD_FEES AS 
   SELECT Regd_No, Fees 
   FROM STUDENT;

Horizontale Fragmentierung

Durch horizontale Fragmentierung werden die Tupel einer Tabelle gemäß den Werten eines oder mehrerer Felder gruppiert. Die horizontale Fragmentierung sollte auch die Regel der Rekonstruktivität bestätigen. Jedes horizontale Fragment muss alle Spalten der ursprünglichen Basistabelle enthalten.

Wenn im Studentenschema beispielsweise die Details aller Studenten des Informatikkurses an der Fakultät für Informatik gepflegt werden müssen, fragmentiert der Designer die Datenbank horizontal wie folgt:

CREATE COMP_STD AS 
   SELECT * FROM STUDENT  
   WHERE COURSE = "Computer Science";

Hybridfragmentierung

Bei der Hybridfragmentierung wird eine Kombination aus horizontalen und vertikalen Fragmentierungstechniken verwendet. Dies ist die flexibelste Fragmentierungstechnik, da Fragmente mit minimaler Fremdinformation erzeugt werden. Die Rekonstruktion der ursprünglichen Tabelle ist jedoch häufig eine teure Aufgabe.

Die Hybridfragmentierung kann auf zwei alternative Arten erfolgen:

• Generieren Sie zunächst eine Reihe horizontaler Fragmente. Erzeugen Sie dann vertikale Fragmente aus einem oder mehreren der horizontalen Fragmente.

• Generieren Sie zunächst eine Reihe vertikaler Fragmente. Erzeugen Sie dann horizontale Fragmente aus einem oder mehreren der vertikalen Fragmente.

Verteilungstransparenz ist die Eigenschaft verteilter Datenbanken, durch die die internen Details der Verteilung vor den Benutzern verborgen werden. Der DDBMS-Designer kann Tabellen fragmentieren, die Fragmente replizieren und an verschiedenen Standorten speichern. Da Benutzer diese Details jedoch nicht kennen, ist die verteilte Datenbank wie jede zentralisierte Datenbank einfach zu verwenden.

Die drei Dimensionen der Verteilungstransparenz sind -

• Standorttransparenz
• Fragmentierungstransparenz
• Replikationstransparenz

Standorttransparenz

Durch die Standorttransparenz wird sichergestellt, dass der Benutzer alle Tabellen oder Fragmente einer Tabelle abfragen kann, als ob sie lokal auf der Site des Benutzers gespeichert wären. Die Tatsache, dass die Tabelle oder ihre Fragmente an einem entfernten Standort im verteilten Datenbanksystem gespeichert sind, sollte für den Endbenutzer völlig unberücksichtigt bleiben. Die Adresse der Remote-Site (s) und die Zugriffsmechanismen sind vollständig ausgeblendet.

Um die Standorttransparenz zu gewährleisten, sollte DDBMS Zugriff auf ein aktualisiertes und genaues Datenwörterbuch und ein DDBMS-Verzeichnis haben, das die Details der Speicherorte der Daten enthält.

Fragmentierungstransparenz

Durch die Fragmentierungstransparenz können Benutzer jede Tabelle abfragen, als wäre sie nicht fragmentiert. Somit wird die Tatsache ausgeblendet, dass die Tabelle, die der Benutzer abfragt, tatsächlich ein Fragment oder eine Vereinigung einiger Fragmente ist. Es verbirgt auch die Tatsache, dass sich die Fragmente an verschiedenen Orten befinden.

Dies ähnelt Benutzern von SQL-Ansichten, bei denen der Benutzer möglicherweise nicht weiß, dass er eine Ansicht einer Tabelle anstelle der Tabelle selbst verwendet.

Replikationstransparenz

Die Replikationstransparenz stellt sicher, dass die Replikation von Datenbanken vor den Benutzern verborgen bleibt. Benutzer können eine Tabelle abfragen, als ob nur eine einzige Kopie der Tabelle vorhanden wäre.

Replikationstransparenz ist mit Parallelitätstransparenz und Fehlertransparenz verbunden. Wenn ein Benutzer ein Datenelement aktualisiert, wird die Aktualisierung in allen Kopien der Tabelle angezeigt. Dieser Vorgang sollte dem Benutzer jedoch nicht bekannt sein. Dies ist Parallelitätstransparenz. Im Falle eines Ausfalls einer Site kann der Benutzer seine Abfragen weiterhin mit replizierten Kopien fortsetzen, ohne dass ein Fehler bekannt ist. Dies ist Fehlertransparenz.

Kombination von Folien

In jedem verteilten Datenbanksystem sollte der Designer sicherstellen, dass alle angegebenen Transparentfolien in erheblichem Maße erhalten bleiben. Der Designer kann Tabellen fragmentieren, replizieren und an verschiedenen Standorten speichern. alles ohne Rücksicht auf den Endbenutzer. Eine vollständige Verteilungstransparenz ist jedoch eine schwierige Aufgabe und erfordert erhebliche Designanstrengungen.

Die Datenbanksteuerung bezieht sich auf die Aufgabe, Vorschriften durchzusetzen, um authentischen Benutzern und Anwendungen einer Datenbank korrekte Daten bereitzustellen. Damit den Benutzern korrekte Daten zur Verfügung stehen, sollten alle Daten den in der Datenbank definierten Integritätsbeschränkungen entsprechen. Außerdem sollten Daten von nicht autorisierten Benutzern ferngehalten werden, um die Sicherheit und den Datenschutz der Datenbank zu gewährleisten. Die Datenbanksteuerung ist eine der Hauptaufgaben des Datenbankadministrators (DBA).

Die drei Dimensionen der Datenbanksteuerung sind -

• Authentication
• Zugangsrechte
• Integritätsbedingungen

Authentifizierung

In einem verteilten Datenbanksystem ist die Authentifizierung der Prozess, durch den nur legitime Benutzer Zugriff auf die Datenressourcen erhalten.

Die Authentifizierung kann auf zwei Ebenen erzwungen werden:

• Controlling Access to Client Computer- Auf dieser Ebene ist der Benutzerzugriff eingeschränkt, während Sie sich beim Client-Computer anmelden, der dem Datenbankserver eine Benutzeroberfläche bietet. Die häufigste Methode ist eine Kombination aus Benutzername und Passwort. Für hochsichere Daten können jedoch komplexere Methoden wie die biometrische Authentifizierung verwendet werden.

• Controlling Access to the Database Software- Auf dieser Ebene weist die Datenbanksoftware / der Administrator dem Benutzer einige Anmeldeinformationen zu. Mit diesen Anmeldeinformationen erhält der Benutzer Zugriff auf die Datenbank. Eine der Methoden besteht darin, ein Anmeldekonto auf dem Datenbankserver zu erstellen.

Zugangsrechte

Die Zugriffsrechte eines Benutzers beziehen sich auf die Berechtigungen, die dem Benutzer für DBMS-Vorgänge gewährt werden, z. B. die Rechte zum Erstellen einer Tabelle, Löschen einer Tabelle, Hinzufügen / Löschen / Aktualisieren von Tupeln in einer Tabelle oder Abfragen der Tabelle.

In verteilten Umgebungen ist es nicht möglich, Benutzern individuelle Zugriffsrechte zuzuweisen, da es eine große Anzahl von Tabellen und dennoch eine größere Anzahl von Benutzern gibt. DDBMS definiert also bestimmte Rollen. Eine Rolle ist ein Konstrukt mit bestimmten Berechtigungen innerhalb eines Datenbanksystems. Sobald die verschiedenen Rollen definiert sind, wird den einzelnen Benutzern eine dieser Rollen zugewiesen. Oft wird eine Hierarchie von Rollen gemäß der Hierarchie der Autorität und Verantwortung der Organisation definiert.

Die folgenden SQL-Anweisungen erstellen beispielsweise eine Rolle "Accountant" und weisen diese Rolle dann dem Benutzer "ABC" zu.

CREATE ROLE ACCOUNTANT; 
GRANT SELECT, INSERT, UPDATE ON EMP_SAL TO ACCOUNTANT; 
GRANT INSERT, UPDATE, DELETE ON TENDER TO ACCOUNTANT; 
GRANT INSERT, SELECT ON EXPENSE TO ACCOUNTANT; 
COMMIT; 
GRANT ACCOUNTANT TO ABC; 
COMMIT;

Semantische Integritätskontrolle

Die semantische Integritätskontrolle definiert und erzwingt die Integritätsbeschränkungen des Datenbanksystems.

Die Integritätsbeschränkungen sind wie folgt:

• Integritätsbeschränkung für Datentypen
• Integritätsbeschränkung für Entitäten
• Einschränkung der referenziellen Integrität

Datentyp-Integritätsbeschränkung

Eine Datentypeinschränkung schränkt den Wertebereich und die Art der Operationen ein, die auf das Feld mit dem angegebenen Datentyp angewendet werden können.

Nehmen wir zum Beispiel an, dass eine Tabelle "HOSTEL" drei Felder enthält - die Hostelnummer, den Hostelnamen und die Kapazität. Die Hostel-Nummer sollte mit dem Großbuchstaben "H" beginnen und darf nicht NULL sein. Die Kapazität sollte nicht mehr als 150 betragen. Der folgende SQL-Befehl kann zur Datendefinition verwendet werden:

CREATE TABLE HOSTEL ( 
   H_NO VARCHAR2(5) NOT NULL, 
   H_NAME VARCHAR2(15), 
   CAPACITY INTEGER, 
   CHECK ( H_NO LIKE 'H%'), 
   CHECK ( CAPACITY <= 150) 
);

Entity Integrity Control

Die Entitätsintegritätskontrolle erzwingt die Regeln, sodass jedes Tupel von anderen Tupeln eindeutig identifiziert werden kann. Hierzu wird ein Primärschlüssel definiert. Ein Primärschlüssel ist eine Reihe von Minimalfeldern, mit denen ein Tupel eindeutig identifiziert werden kann. Die Integritätsbedingung für Entitäten besagt, dass keine zwei Tupel in einer Tabelle identische Werte für Primärschlüssel haben dürfen und dass kein Feld, das Teil des Primärschlüssels ist, den Wert NULL haben darf.

In der obigen Hosteltabelle kann beispielsweise die Hostelnummer über die folgende SQL-Anweisung (ohne Berücksichtigung der Überprüfungen) als Primärschlüssel zugewiesen werden.

CREATE TABLE HOSTEL ( 
   H_NO VARCHAR2(5) PRIMARY KEY, 
   H_NAME VARCHAR2(15), 
   CAPACITY INTEGER 
);

Referenzielle Integritätsbeschränkung

Die Einschränkung der referenziellen Integrität legt die Regeln für Fremdschlüssel fest. Ein Fremdschlüssel ist ein Feld in einer Datentabelle, das der Primärschlüssel einer verwandten Tabelle ist. Die referenzielle Integritätsbeschränkung legt die Regel fest, dass der Wert des Fremdschlüsselfelds entweder zu den Werten des Primärschlüssels der referenzierten Tabelle gehören oder vollständig NULL sein sollte.

Betrachten wir zum Beispiel einen Schülertisch, an dem sich ein Schüler für ein Hostel entscheiden kann. Um dies einzuschließen, sollte der Primärschlüssel der Hosteltabelle als Fremdschlüssel in die Schülertabelle aufgenommen werden. Die folgende SQL-Anweisung enthält Folgendes:

CREATE TABLE STUDENT (  
   S_ROLL INTEGER PRIMARY KEY, 
   S_NAME VARCHAR2(25) NOT NULL, 
   S_COURSE VARCHAR2(10), 
   S_HOSTEL VARCHAR2(5) REFERENCES HOSTEL 
);

Wenn eine Abfrage gestellt wird, wird sie zuerst gescannt, analysiert und validiert. Anschließend wird eine interne Darstellung der Abfrage erstellt, z. B. ein Abfragebaum oder ein Abfragediagramm. Anschließend werden alternative Ausführungsstrategien entwickelt, um Ergebnisse aus den Datenbanktabellen abzurufen. Der Prozess der Auswahl der am besten geeigneten Ausführungsstrategie für die Abfrageverarbeitung wird als Abfrageoptimierung bezeichnet.

Probleme bei der Abfrageoptimierung in DDBMS

In DDBMS ist die Abfrageoptimierung eine wichtige Aufgabe. Die Komplexität ist hoch, da die Anzahl alternativer Strategien aufgrund der folgenden Faktoren exponentiell zunehmen kann:

• Das Vorhandensein einer Reihe von Fragmenten.
• Verteilung der Fragmente oder Tabellen auf verschiedene Standorte.
• Die Geschwindigkeit der Kommunikationsverbindungen.
• Unterschiede in den lokalen Verarbeitungsfunktionen.

In einem verteilten System besteht das Ziel häufig darin, eine gute Ausführungsstrategie für die Abfrageverarbeitung zu finden und nicht die beste. Die Zeit zum Ausführen einer Abfrage ist die Summe der folgenden Werte:

• Zeit für die Übermittlung von Abfragen an Datenbanken.
• Zeit zum Ausführen lokaler Abfragefragmente.
• Zeit, Daten von verschiedenen Standorten zusammenzustellen.
• Zeit, um der Anwendung Ergebnisse anzuzeigen.

Abfrageverarbeitung

Die Abfrageverarbeitung besteht aus allen Aktivitäten, angefangen von der Platzierung der Abfrage bis hin zur Anzeige der Ergebnisse der Abfrage. Die Schritte sind wie in der folgenden Abbildung dargestellt -

Relationale Algebra

Die relationale Algebra definiert die grundlegenden Operationen des relationalen Datenbankmodells. Eine Folge von relationalen Algebraoperationen bildet einen relationalen Algebraausdruck. Das Ergebnis dieses Ausdrucks repräsentiert das Ergebnis einer Datenbankabfrage.

Die Grundoperationen sind -

• Projection
• Selection
• Union
• Intersection
• Minus
• Join

Projektion

Die Projektionsoperation zeigt eine Teilmenge der Felder einer Tabelle an. Dies ergibt eine vertikale Partition der Tabelle.

Syntax in Relational Algebra

$$ \ pi _ {<{AttributeList}>} {(<{Tabellenname}>)} $$

Betrachten wir zum Beispiel die folgende Studentendatenbank:

STUDENT
Roll_No	Name	Course	Semester	Gender
2	Amit Prasad	BCA	1	Männlich
4	Varsha Tiwari	BCA	1	Weiblich
5	Asif Ali	MCA	2	Männlich
6	Joe Wallace	MCA	1	Männlich
8	Shivani Iyengar	BCA	1	Weiblich

Wenn wir die Namen und Kurse aller Schüler anzeigen möchten, verwenden wir den folgenden relationalen Algebra-Ausdruck:

$$\pi_{Name,Course}{(STUDENT)}$$

Auswahl

Die Auswahloperation zeigt eine Teilmenge von Tupeln einer Tabelle an, die bestimmte Bedingungen erfüllen. Dies ergibt eine horizontale Aufteilung der Tabelle.

Syntax in Relational Algebra

$$ \ sigma _ {<{Bedingungen}>} {(<{Tabellenname}>)} $$

Wenn wir beispielsweise in der Schülertabelle die Details aller Schüler anzeigen möchten, die sich für den MCA-Kurs entschieden haben, verwenden wir den folgenden relationalen Algebra-Ausdruck:

$$\sigma_{Course} = {\small "BCA"}^{(STUDENT)}$$

Kombination von Projektions- und Auswahloperationen

Für die meisten Abfragen benötigen wir eine Kombination aus Projektions- und Auswahloperationen. Es gibt zwei Möglichkeiten, diese Ausdrücke zu schreiben:

• Verwenden der Abfolge von Projektions- und Auswahlvorgängen.
• Verwenden der Umbenennungsoperation zum Generieren von Zwischenergebnissen.

Zum Beispiel, um Namen aller Studentinnen des BCA-Kurses anzuzeigen -

• Relationaler Algebra-Ausdruck unter Verwendung einer Folge von Projektions- und Auswahloperationen

$$\pi_{Name}(\sigma_{Gender = \small "Female" AND \: Course = \small "BCA"}{(STUDENT)})$$

• Relationaler Algebra-Ausdruck unter Verwendung einer Umbenennungsoperation, um Zwischenergebnisse zu generieren

$$FemaleBCAStudent \leftarrow \sigma_{Gender = \small "Female" AND \: Course = \small "BCA"} {(STUDENT)}$$

$$Result \leftarrow \pi_{Name}{(FemaleBCAStudent)}$$

Union

Wenn P ein Ergebnis einer Operation ist und Q ein Ergebnis einer anderen Operation ist, ist die Vereinigung von P und Q ($p \cup Q$) ist die Menge aller Tupel, die entweder in P oder in Q oder in beiden ohne Duplikate ist.

Zum Beispiel, um alle Studenten anzuzeigen, die entweder im 1. Semester oder im BCA-Kurs sind -

$$Sem1Student \leftarrow \sigma_{Semester = 1}{(STUDENT)}$$

$$BCAStudent \leftarrow \sigma_{Course = \small "BCA"}{(STUDENT)}$$

$$Result \leftarrow Sem1Student \cup BCAStudent$$

Überschneidung

Wenn P ein Ergebnis einer Operation ist und Q ein Ergebnis einer anderen Operation ist, ist der Schnittpunkt von P und Q ( $p \cap Q$ ) ist die Menge aller Tupel, die beide in P und Q sind.

Zum Beispiel unter Berücksichtigung der folgenden zwei Schemata:

EMPLOYEE

EmpID

Name

Stadt

Abteilung

Gehalt

PROJECT

PId

Stadt

Abteilung

Status

So zeigen Sie die Namen aller Städte an, in denen sich ein Projekt befindet und in denen sich auch ein Mitarbeiter befindet -

$$CityEmp \leftarrow \pi_{City}{(EMPLOYEE)}$$

$$CityProject \leftarrow \pi_{City}{(PROJECT)}$$

$$Result \leftarrow CityEmp \cap CityProject$$

Minus

Wenn P ein Ergebnis einer Operation und Q ein Ergebnis einer anderen Operation ist, ist P - Q die Menge aller Tupel, die in P und nicht in Q sind.

Zum Beispiel, um alle Abteilungen aufzulisten, die kein laufendes Projekt haben (Projekte mit Status = laufend) -

$$AllDept \leftarrow \pi_{Department}{(EMPLOYEE)}$$

$$ProjectDept \leftarrow \pi_{Department} (\sigma_{Status = \small "ongoing"}{(PROJECT)})$$

$$Result \leftarrow AllDept - ProjectDept$$

Beitreten

Die Verknüpfungsoperation kombiniert verwandte Tupel zweier verschiedener Tabellen (Ergebnisse von Abfragen) in einer einzigen Tabelle.

Betrachten Sie beispielsweise zwei Schemata, Kunde und Filiale, in einer Bankdatenbank wie folgt:

CUSTOMER

CustID

AccNo

TypeOfAc

BranchID

DateOfOpening

BRANCH

BranchID

Zweigname

IFSCcode

Adresse

So listen Sie die Mitarbeiterdetails zusammen mit den Filialdetails auf:

$$Result \leftarrow CUSTOMER \bowtie_{Customer.BranchID=Branch.BranchID}{BRANCH}$$

SQL-Abfragen in relationale Algebra übersetzen

SQL-Abfragen werden vor der Optimierung in äquivalente relationale Algebra-Ausdrücke übersetzt. Eine Abfrage wird zunächst in kleinere Abfrageblöcke zerlegt. Diese Blöcke werden in äquivalente relationale Algebraausdrücke übersetzt. Die Optimierung umfasst die Optimierung jedes Blocks und anschließend die Optimierung der gesamten Abfrage.

Beispiele

Betrachten wir die folgenden Schemata:

MITARBEITER

EmpID

Name

Stadt

Abteilung

Gehalt

PROJEKT

PId

Stadt

Abteilung

Status

WERKE

EmpID

PID

Std

Beispiel 1

Um die Details aller Mitarbeiter anzuzeigen, die ein Gehalt verdienen, das WENIGER als das Durchschnittsgehalt ist, schreiben wir die SQL-Abfrage -

SELECT * FROM EMPLOYEE 
WHERE SALARY < ( SELECT AVERAGE(SALARY) FROM EMPLOYEE ) ;

Diese Abfrage enthält eine verschachtelte Unterabfrage. Dies kann also in zwei Blöcke unterteilt werden.

Der innere Block ist -

SELECT AVERAGE(SALARY)FROM EMPLOYEE ;

Wenn das Ergebnis dieser Abfrage AvgSal ist, lautet der äußere Block -

SELECT * FROM EMPLOYEE WHERE SALARY < AvgSal;

Relationaler Algebra-Ausdruck für inneren Block -

$$AvgSal \leftarrow \Im_{AVERAGE(Salary)}{EMPLOYEE}$$

Relationaler Algebra-Ausdruck für äußeren Block -

$$ \ sigma_ {Gehalt <{AvgSal}>} {MITARBEITER} $$

Beispiel 2

Um die Projekt-ID und den Status aller Projekte des Mitarbeiters 'Arun Kumar' anzuzeigen, schreiben wir die SQL-Abfrage -

SELECT PID, STATUS FROM PROJECT 
WHERE PID = ( SELECT FROM WORKS  WHERE EMPID = ( SELECT EMPID FROM EMPLOYEE 
            WHERE NAME = 'ARUN KUMAR'));

Diese Abfrage enthält zwei verschachtelte Unterabfragen. Somit kann wie folgt in drei Blöcke unterteilt werden -

SELECT EMPID FROM EMPLOYEE WHERE NAME = 'ARUN KUMAR'; 
SELECT PID FROM WORKS WHERE EMPID = ArunEmpID; 
SELECT PID, STATUS FROM PROJECT WHERE PID = ArunPID;

(Hier sind ArunEmpID und ArunPID die Ergebnisse innerer Abfragen)

Relationale Algebraausdrücke für die drei Blöcke sind -

$$ArunEmpID \leftarrow \pi_{EmpID}(\sigma_{Name = \small "Arun Kumar"} {(EMPLOYEE)})$$

$$ArunPID \leftarrow \pi_{PID}(\sigma_{EmpID = \small "ArunEmpID"} {(WORKS)})$$

$$Result \leftarrow \pi_{PID, Status}(\sigma_{PID = \small "ArunPID"} {(PROJECT)})$$

Berechnung relationaler Algebraoperatoren

Die Berechnung relationaler Algebraoperatoren kann auf viele verschiedene Arten erfolgen, und jede Alternative wird als bezeichnet access path.

Die Berechnungsalternative hängt von drei Hauptfaktoren ab:

• Bedienertyp
• Verfügbare Erinnerung
• Plattenstrukturen

Die Zeit für die Ausführung einer relationalen Algebraoperation ist die Summe von -

• Zeit, die Tupel zu verarbeiten.
• Zeit, um die Tupel der Tabelle von der Festplatte in den Speicher zu holen.

Da die Zeit zum Verarbeiten eines Tupels sehr viel kürzer ist als die Zeit zum Abrufen des Tupels aus dem Speicher, insbesondere in einem verteilten System, wird der Festplattenzugriff sehr häufig als Metrik für die Berechnung der Kosten des relationalen Ausdrucks angesehen.

Berechnung der Auswahl

Die Berechnung der Auswahloperation hängt von der Komplexität der Auswahlbedingung und der Verfügbarkeit von Indizes für die Attribute der Tabelle ab.

Nachfolgend sind die Berechnungsalternativen in Abhängigkeit von den Indizes aufgeführt:

• No Index- Wenn die Tabelle unsortiert ist und keine Indizes enthält, werden bei der Auswahl alle Plattenblöcke der Tabelle gescannt. Jeder Block wird in den Speicher gebracht und jedes Tupel im Block wird untersucht, um festzustellen, ob es die Auswahlbedingung erfüllt. Wenn die Bedingung erfüllt ist, wird sie als Ausgabe angezeigt. Dies ist der teuerste Ansatz, da jedes Tupel in den Speicher gebracht und jedes Tupel verarbeitet wird.

• B+ Tree Index- Die meisten Datenbanksysteme basieren auf dem B + Tree-Index. Wenn die Auswahlbedingung auf dem Feld basiert, das der Schlüssel dieses B + Tree-Index ist, wird dieser Index zum Abrufen der Ergebnisse verwendet. Die Verarbeitung von Auswahlanweisungen mit komplexen Bedingungen kann jedoch eine größere Anzahl von Plattenblockzugriffen und in einigen Fällen ein vollständiges Scannen der Tabelle beinhalten.

• Hash Index- Wenn Hash-Indizes verwendet werden und das Schlüsselfeld in der Auswahlbedingung verwendet wird, wird das Abrufen von Tupeln mithilfe des Hash-Index zu einem einfachen Vorgang. Ein Hash-Index verwendet eine Hash-Funktion, um die Adresse eines Buckets zu ermitteln, in dem der dem Hash-Wert entsprechende Schlüsselwert gespeichert ist. Um einen Schlüsselwert im Index zu finden, wird die Hash-Funktion ausgeführt und die Bucket-Adresse gefunden. Die Schlüsselwerte im Bucket werden durchsucht. Wenn eine Übereinstimmung gefunden wird, wird das tatsächliche Tupel vom Plattenblock in den Speicher abgerufen.

Berechnung von Joins

Wenn wir zwei Tabellen verbinden möchten, z. B. P und Q, muss jedes Tupel in P mit jedem Tupel in Q verglichen werden, um zu testen, ob die Verknüpfungsbedingung erfüllt ist. Wenn die Bedingung erfüllt ist, werden die entsprechenden Tupel verkettet, wodurch doppelte Felder entfernt und an die Ergebnisbeziehung angehängt werden. Folglich ist dies die teuerste Operation.

Die gängigen Ansätze für die Berechnung von Joins sind:

Nested-Loop-Ansatz

Dies ist der herkömmliche Join-Ansatz. Dies kann durch den folgenden Pseudocode veranschaulicht werden (Tabellen P und Q mit den Tupeln tuple_p und tuple_q und dem Verbindungsattribut a) -

For each tuple_p in P 
For each tuple_q in Q
If tuple_p.a = tuple_q.a Then 
   Concatenate tuple_p and tuple_q and append to Result 
End If 
Next tuple_q 
Next tuple-p

Sort-Merge-Ansatz

Bei diesem Ansatz werden die beiden Tabellen basierend auf dem Verknüpfungsattribut einzeln sortiert und anschließend die sortierten Tabellen zusammengeführt. Externe Sortiertechniken werden angewendet, da die Anzahl der Datensätze sehr hoch ist und nicht im Speicher gespeichert werden kann. Sobald die einzelnen Tabellen sortiert sind, wird jeweils eine Seite der sortierten Tabellen in den Speicher gebracht, basierend auf dem Verknüpfungsattribut zusammengeführt und die verknüpften Tupel ausgeschrieben.

Hash-Join-Ansatz

Dieser Ansatz besteht aus zwei Phasen: Partitionierungsphase und Prüfphase. In der Partitionierungsphase werden die Tabellen P und Q in zwei Sätze disjunkter Partitionen aufgeteilt. Eine gemeinsame Hash-Funktion wird festgelegt. Diese Hash-Funktion wird verwendet, um Partitionen Tupel zuzuweisen. In der Prüfphase werden Tupel in einer Partition von P mit den Tupeln der entsprechenden Partition von Q verglichen. Wenn sie übereinstimmen, werden sie ausgeschrieben.

Sobald die alternativen Zugriffspfade zur Berechnung eines relationalen Algebraausdrucks abgeleitet sind, wird der optimale Zugriffspfad bestimmt. In diesem Kapitel werden wir uns mit der Abfrageoptimierung in einem zentralisierten System befassen, während wir im nächsten Kapitel die Abfrageoptimierung in einem verteilten System untersuchen werden.

In einem zentralisierten System erfolgt die Abfrageverarbeitung mit dem folgenden Ziel:

• Minimierung der Antwortzeit der Abfrage (Zeit, die benötigt wird, um die Ergebnisse für die Benutzerabfrage zu erstellen).

• Maximieren Sie den Systemdurchsatz (die Anzahl der Anforderungen, die in einem bestimmten Zeitraum verarbeitet werden).

• Reduzieren Sie den für die Verarbeitung erforderlichen Speicherplatz.

• Erhöhen Sie die Parallelität.

Analyse und Übersetzung von Abfragen

Zunächst wird die SQL-Abfrage gescannt. Anschließend wird analysiert, ob syntaktische Fehler und die Richtigkeit der Datentypen vorliegen. Wenn die Abfrage diesen Schritt besteht, wird die Abfrage in kleinere Abfrageblöcke zerlegt. Jeder Block wird dann in einen äquivalenten Ausdruck der relationalen Algebra übersetzt.

Schritte zur Abfrageoptimierung

Die Abfrageoptimierung umfasst drei Schritte: Abfragebaumgenerierung, Plangenerierung und Abfrageplancodegenerierung.

Step 1 − Query Tree Generation

Ein Abfragebaum ist eine Baumdatenstruktur, die einen relationalen Algebraausdruck darstellt. Die Tabellen der Abfrage werden als Blattknoten dargestellt. Die relationalen Algebraoperationen werden als interne Knoten dargestellt. Die Wurzel repräsentiert die Abfrage als Ganzes.

Während der Ausführung wird ein interner Knoten ausgeführt, wenn seine Operandentabellen verfügbar sind. Der Knoten wird dann durch die Ergebnistabelle ersetzt. Dieser Prozess wird für alle internen Knoten fortgesetzt, bis der Stammknoten ausgeführt und durch die Ergebnistabelle ersetzt wird.

Betrachten wir zum Beispiel die folgenden Schemata:

MITARBEITER

EmpID

EName

Gehalt

DeptNo

Beitrittsdatum

ABTEILUNG

DNo

DName

Ort

Beispiel 1

Betrachten wir die Abfrage wie folgt.

$$\pi_{EmpID} (\sigma_{EName = \small "ArunKumar"} {(EMPLOYEE)})$$

Der entsprechende Abfragebaum lautet -

Beispiel 2

Betrachten wir eine weitere Abfrage mit einem Join.

$\pi_{EName, Salary} (\sigma_{DName = \small "Marketing"} {(DEPARTMENT)}) \bowtie_{DNo=DeptNo}{(EMPLOYEE)}$

Es folgt der Abfragebaum für die obige Abfrage.

Step 2 − Query Plan Generation

Nachdem der Abfragebaum generiert wurde, wird ein Abfrageplan erstellt. Ein Abfrageplan ist ein erweiterter Abfragebaum, der Zugriffspfade für alle Vorgänge im Abfragebaum enthält. Zugriffspfade geben an, wie die relationalen Operationen in der Baumstruktur ausgeführt werden sollen. Beispielsweise kann eine Auswahloperation einen Zugriffspfad haben, der Details zur Verwendung des B + -Baumindex für die Auswahl enthält.

Außerdem gibt ein Abfrageplan auch an, wie die Zwischentabellen von einem Operator zum nächsten übergeben werden sollen, wie temporäre Tabellen verwendet werden sollen und wie Operationen per Pipeline verbunden / kombiniert werden sollen.

Step 3− Code Generation

Die Codegenerierung ist der letzte Schritt bei der Abfrageoptimierung. Dies ist die ausführbare Form der Abfrage, deren Form vom Typ des zugrunde liegenden Betriebssystems abhängt. Sobald der Abfragecode generiert wurde, führt ihn der Ausführungsmanager aus und erstellt die Ergebnisse.

Ansätze zur Abfrageoptimierung

Unter den Ansätzen zur Abfrageoptimierung werden hauptsächlich umfassende Such- und heuristikbasierte Algorithmen verwendet.

Umfassende Suchoptimierung

Bei diesen Techniken werden für eine Abfrage zunächst alle möglichen Abfragepläne generiert und dann der beste Plan ausgewählt. Obwohl diese Techniken die beste Lösung bieten, weist sie aufgrund des großen Lösungsraums eine exponentielle zeitliche und räumliche Komplexität auf. Zum Beispiel dynamische Programmiertechnik.

Heuristische Optimierung

Die heuristische Optimierung verwendet regelbasierte Optimierungsansätze für die Abfrageoptimierung. Diese Algorithmen weisen eine polynomielle zeitliche und räumliche Komplexität auf, die geringer ist als die exponentielle Komplexität erschöpfender suchbasierter Algorithmen. Diese Algorithmen erzeugen jedoch nicht unbedingt den besten Abfrageplan.

Einige der gängigen heuristischen Regeln sind:

• Führen Sie Auswahl- und Projektvorgänge aus, bevor Sie Verknüpfungsvorgänge ausführen. Dies erfolgt durch Verschieben der Auswahl- und Projektoperationen im Abfragebaum. Dies reduziert die Anzahl der Tupel, die zum Verbinden verfügbar sind.

• Führen Sie zuerst die restriktivsten Auswahl- / Projektvorgänge vor den anderen Vorgängen aus.

• Vermeiden Sie produktübergreifende Operationen, da diese zu sehr großen Zwischentabellen führen.

In diesem Kapitel wird die Abfrageoptimierung im verteilten Datenbanksystem erläutert.

Verteilte Abfrageverarbeitungsarchitektur

In einem verteilten Datenbanksystem umfasst die Verarbeitung einer Abfrage die Optimierung sowohl auf globaler als auch auf lokaler Ebene. Die Abfrage wird auf dem Client- oder Controlling-Standort in das Datenbanksystem eingegeben. Hier wird der Benutzer validiert, die Abfrage wird auf globaler Ebene geprüft, übersetzt und optimiert.

Die Architektur kann dargestellt werden als -

Zuordnen globaler Abfragen zu lokalen Abfragen

Der Prozess der Zuordnung globaler Abfragen zu lokalen Abfragen kann wie folgt realisiert werden:

• Die in einer globalen Abfrage erforderlichen Tabellen enthalten Fragmente, die auf mehrere Standorte verteilt sind. Die lokalen Datenbanken enthalten nur Informationen zu lokalen Daten. Die steuernde Site verwendet das globale Datenwörterbuch, um Informationen über die Verteilung zu sammeln und die globale Ansicht aus den Fragmenten zu rekonstruieren.

• Wenn keine Replikation vorhanden ist, führt das globale Optimierungsprogramm lokale Abfragen an den Standorten aus, an denen die Fragmente gespeichert sind. Wenn eine Replikation stattfindet, wählt der globale Optimierer den Standort basierend auf Kommunikationskosten, Arbeitslast und Servergeschwindigkeit aus.

• Das globale Optimierungsprogramm generiert einen verteilten Ausführungsplan, sodass die Datenübertragung über die Standorte hinweg am geringsten ist. Der Plan gibt die Position der Fragmente, die Reihenfolge, in der Abfrageschritte ausgeführt werden müssen, und die Prozesse an, die bei der Übertragung von Zwischenergebnissen beteiligt sind.

• Die lokalen Abfragen werden von den lokalen Datenbankservern optimiert. Schließlich werden die lokalen Abfrageergebnisse bei horizontalen Fragmenten durch Vereinigungsoperation und bei vertikalen Fragmenten durch Verknüpfungsoperation zusammengeführt.

Nehmen wir zum Beispiel an, dass das folgende Projektschema horizontal nach Stadt fragmentiert ist, wobei die Städte Neu-Delhi, Kolkata und Hyderabad sind.

PROJEKT

PId

Stadt

Abteilung

Status

Angenommen, es gibt eine Abfrage zum Abrufen von Details aller Projekte mit dem Status "Laufend".

Die globale Abfrage lautet & inus;

$$\sigma_{status} = {\small "ongoing"}^{(PROJECT)}$$

Die Abfrage auf dem Server von New Delhi lautet:

$$\sigma_{status} = {\small "ongoing"}^{({NewD}_-{PROJECT})}$$

Die Abfrage auf dem Server von Kolkata lautet:

$$\sigma_{status} = {\small "ongoing"}^{({Kol}_-{PROJECT})}$$

Abfrage in Hyderabad Server wird sein -

$$\sigma_{status} = {\small "ongoing"}^{({Hyd}_-{PROJECT})}$$

Um das Gesamtergebnis zu erhalten, müssen wir die Ergebnisse der drei Abfragen wie folgt zusammenfassen:

$\sigma_{status} = {\small "ongoing"}^{({NewD}_-{PROJECT})} \cup \sigma_{status} = {\small "ongoing"}^{({kol}_-{PROJECT})} \cup \sigma_{status} = {\small "ongoing"}^{({Hyd}_-{PROJECT})}$

Optimierung verteilter Abfragen

Die verteilte Abfrageoptimierung erfordert die Auswertung einer großen Anzahl von Abfragebäumen, von denen jeder die erforderlichen Ergebnisse einer Abfrage liefert. Dies ist hauptsächlich auf das Vorhandensein einer großen Menge replizierter und fragmentierter Daten zurückzuführen. Daher ist das Ziel, eine optimale Lösung anstelle der besten Lösung zu finden.

Die Hauptprobleme bei der Optimierung verteilter Abfragen sind:

• Optimale Ressourcennutzung im verteilten System.
• Abfragehandel.
• Reduzierung des Lösungsraums der Abfrage.

Optimale Ressourcennutzung im verteilten System

Ein verteiltes System verfügt über eine Reihe von Datenbankservern an den verschiedenen Standorten, um die mit einer Abfrage verbundenen Vorgänge auszuführen. Es folgen die Ansätze für eine optimale Ressourcennutzung -

Operation Shipping- Beim Versand von Vorgängen wird der Vorgang an dem Ort ausgeführt, an dem die Daten gespeichert sind, und nicht am Standort des Kunden. Die Ergebnisse werden dann an den Kundenstandort übertragen. Dies ist für Operationen geeignet, bei denen die Operanden am selben Standort verfügbar sind. Beispiel: Operationen auswählen und projizieren.

Data Shipping- Beim Datenversand werden die Datenfragmente an den Datenbankserver übertragen, wo die Operationen ausgeführt werden. Dies wird in Operationen verwendet, bei denen die Operanden an verschiedenen Standorten verteilt sind. Dies ist auch in Systemen angebracht, in denen die Kommunikationskosten niedrig sind und lokale Prozessoren viel langsamer als der Client-Server sind.

Hybrid Shipping- Dies ist eine Kombination aus Daten- und Betriebsversand. Hier werden Datenfragmente an die Hochgeschwindigkeitsprozessoren übertragen, auf denen die Operation ausgeführt wird. Die Ergebnisse werden dann an den Client-Standort gesendet.

Abfragehandel

Beim Abfragehandelsalgorithmus für verteilte Datenbanksysteme wird die Controlling- / Client-Site für eine verteilte Abfrage als Käufer bezeichnet, und die Sites, an denen die lokalen Abfragen ausgeführt werden, werden als Verkäufer bezeichnet. Der Käufer formuliert eine Reihe von Alternativen zur Auswahl der Verkäufer und zur Rekonstruktion der globalen Ergebnisse. Ziel des Käufers ist es, die optimalen Kosten zu erzielen.

Der Algorithmus beginnt damit, dass der Käufer den Verkäuferseiten Unterabfragen zuweist. Der optimale Plan wird aus lokal optimierten Abfrageplänen erstellt, die von den Verkäufern vorgeschlagen wurden, kombiniert mit den Kommunikationskosten für die Rekonstruktion des Endergebnisses. Sobald der globale optimale Plan formuliert ist, wird die Abfrage ausgeführt.

Reduzierung des Lösungsraums der Abfrage

Bei einer optimalen Lösung wird im Allgemeinen der Lösungsraum reduziert, sodass die Kosten für Abfrage und Datenübertragung reduziert werden. Dies kann durch eine Reihe heuristischer Regeln erreicht werden, ebenso wie Heuristiken in zentralisierten Systemen.

Im Folgenden sind einige der Regeln aufgeführt:

• Führen Sie Auswahl- und Projektionsvorgänge so früh wie möglich durch. Dies reduziert den Datenfluss über das Kommunikationsnetzwerk.

• Vereinfachen Sie Operationen an horizontalen Fragmenten, indem Sie Auswahlbedingungen eliminieren, die für einen bestimmten Standort nicht relevant sind.

• Übertragen Sie bei Verknüpfungs- und Vereinigungsoperationen, die aus Fragmenten bestehen, die sich an mehreren Standorten befinden, fragmentierte Daten an den Standort, an dem die meisten Daten vorhanden sind, und führen Sie dort eine Operation aus.

• Verwenden Sie die Semi-Join-Operation, um Tupel zu qualifizieren, die verbunden werden sollen. Dies reduziert den Umfang der Datenübertragung, was wiederum die Kommunikationskosten senkt.

• Führen Sie die allgemeinen Blätter und Unterbäume in einem verteilten Abfragebaum zusammen.

In diesem Kapitel werden die verschiedenen Aspekte der Transaktionsverarbeitung erläutert. Wir werden auch die in einer Transaktion enthaltenen Aufgaben auf niedriger Ebene, die Transaktionszustände und Eigenschaften einer Transaktion untersuchen. Im letzten Teil werden wir uns mit Zeitplänen und der Serialisierbarkeit von Zeitplänen befassen.

Transaktionen

Eine Transaktion ist ein Programm mit einer Sammlung von Datenbankoperationen, die als logische Einheit der Datenverarbeitung ausgeführt werden. Die in einer Transaktion ausgeführten Vorgänge umfassen einen oder mehrere Datenbankvorgänge wie das Einfügen, Löschen, Aktualisieren oder Abrufen von Daten. Es ist ein atomarer Prozess, der entweder vollständig oder gar nicht ausgeführt wird. Eine Transaktion, bei der nur Daten ohne Datenaktualisierung abgerufen werden, wird als schreibgeschützte Transaktion bezeichnet.

Jede Operation auf hoher Ebene kann in eine Reihe von Aufgaben oder Operationen auf niedriger Ebene unterteilt werden. Beispielsweise kann eine Datenaktualisierungsoperation in drei Aufgaben unterteilt werden:

• read_item() - Liest das Datenelement aus dem Speicher in den Hauptspeicher.

• modify_item() - Wert des Elements im Hauptspeicher ändern.

• write_item() - Schreiben Sie den geänderten Wert aus dem Hauptspeicher in den Speicher.

Der Datenbankzugriff ist auf die Operationen read_item () und write_item () beschränkt. Ebenso bilden Lese- und Schreibvorgänge für alle Transaktionen die grundlegenden Datenbankoperationen.

Transaktionsvorgänge

Die in einer Transaktion ausgeführten Operationen auf niedriger Ebene sind -

• begin_transaction - Eine Markierung, die den Beginn der Transaktionsausführung angibt.

• read_item or write_item - Datenbankoperationen, die als Teil der Transaktion mit Hauptspeicheroperationen verschachtelt sein können.

• end_transaction - Eine Markierung, die das Ende der Transaktion angibt.

• commit - Ein Signal zur Angabe, dass die Transaktion vollständig erfolgreich abgeschlossen wurde und nicht rückgängig gemacht wird.

• rollback- Ein Signal, das angibt, dass die Transaktion nicht erfolgreich war und daher alle temporären Änderungen in der Datenbank rückgängig gemacht werden. Eine festgeschriebene Transaktion kann nicht zurückgesetzt werden.

Transaktionszustände

Eine Transaktion kann eine Teilmenge von fünf Zuständen durchlaufen, die aktiv, teilweise festgeschrieben, festgeschrieben, fehlgeschlagen und abgebrochen sind.

• Active- Der Ausgangszustand, in den die Transaktion eintritt, ist der aktive Zustand. Die Transaktion bleibt in diesem Zustand, während Lese-, Schreib- oder andere Vorgänge ausgeführt werden.

• Partially Committed - Die Transaktion tritt in diesen Zustand ein, nachdem die letzte Anweisung der Transaktion ausgeführt wurde.

• Committed - Die Transaktion tritt nach erfolgreichem Abschluss der Transaktion in diesen Status ein und die Systemprüfungen haben ein Festschreibungssignal ausgegeben.

• Failed - Die Transaktion wechselt vom teilweise festgeschriebenen oder aktiven Status in den Status "Fehlgeschlagen", wenn festgestellt wird, dass die normale Ausführung nicht mehr fortgesetzt werden kann oder Systemprüfungen fehlschlagen.

• Aborted - Dies ist der Status, nachdem die Transaktion nach einem Fehler zurückgesetzt und die Datenbank auf den Status vor Beginn der Transaktion zurückgesetzt wurde.

Das folgende Zustandsübergangsdiagramm zeigt die Zustände in der Transaktion und die Transaktionsoperationen auf niedriger Ebene, die eine Änderung der Zustände verursachen.

Wünschenswerte Eigenschaften von Transaktionen

Jede Transaktion muss die ACID-Eigenschaften beibehalten, d. H. Atomizität, Konsistenz, Isolation und Haltbarkeit.

• Atomicity- Diese Eigenschaft besagt, dass eine Transaktion eine atomare Verarbeitungseinheit ist, dh entweder vollständig oder gar nicht ausgeführt wird. Es sollte keine teilweise Aktualisierung vorhanden sein.

• Consistency- Eine Transaktion sollte die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand versetzen. Es sollte kein Datenelement in der Datenbank nachteilig beeinflussen.

• Isolation- Eine Transaktion sollte so ausgeführt werden, als wäre sie die einzige im System. Es sollte keine Störung durch die anderen gleichzeitigen Transaktionen geben, die gleichzeitig ausgeführt werden.

• Durability - Wenn eine festgeschriebene Transaktion eine Änderung bewirkt, sollte diese Änderung in der Datenbank dauerhaft sein und im Falle eines Fehlers nicht verloren gehen.

Zeitpläne und Konflikte

In einem System mit mehreren gleichzeitigen Transaktionen a scheduleist die Gesamtreihenfolge der Ausführung von Operationen. Bei einem Zeitplan S, der n Transaktionen umfasst, sagen wir T1, T2, T3 ……… ..Tn; Für jede Transaktion Ti müssen die Operationen in Ti wie im Zeitplan S festgelegt ausgeführt werden.

Arten von Zeitplänen

Es gibt zwei Arten von Zeitplänen:

• Serial Schedules- In einem seriellen Zeitplan ist zu jedem Zeitpunkt nur eine Transaktion aktiv, dh es gibt keine Überlappung von Transaktionen. Dies ist in der folgenden Grafik dargestellt -

• Parallel Schedules- In parallelen Zeitplänen sind mehrere Transaktionen gleichzeitig aktiv, dh die Transaktionen enthalten Operationen, die sich zu einem bestimmten Zeitpunkt überschneiden. Dies ist in der folgenden Grafik dargestellt -

Konflikte in Zeitplänen

In einem Zeitplan, der mehrere Transaktionen umfasst, a conflicttritt auf, wenn zwei aktive Transaktionen nicht kompatible Vorgänge ausführen. Zwei Operationen sollen in Konflikt stehen, wenn alle folgenden drei Bedingungen gleichzeitig vorliegen -

• Die beiden Operationen sind Teile verschiedener Transaktionen.

• Beide Vorgänge greifen auf dasselbe Datenelement zu.

• Mindestens eine der Operationen ist eine write_item () -Operation, dh sie versucht, das Datenelement zu ändern.

Serialisierbarkeit

EIN serializable schedulevon 'n' Transaktionen ist ein paralleler Zeitplan, der einem seriellen Zeitplan entspricht, der aus denselben 'n' Transaktionen besteht. Ein serialisierbarer Zeitplan enthält die Richtigkeit des seriellen Zeitplans und stellt gleichzeitig eine bessere CPU-Auslastung des parallelen Zeitplans sicher.

Gleichwertigkeit von Zeitplänen

Die Äquivalenz zweier Zeitpläne kann wie folgt sein:

• Result equivalence - Zwei Zeitpläne mit identischen Ergebnissen gelten als ergebnisäquivalent.

• View equivalence - Zwei Zeitpläne, die ähnliche Aktionen auf ähnliche Weise ausführen, werden als Ansichtsäquivalent bezeichnet.

• Conflict equivalence - Zwei Zeitpläne gelten als konfliktäquivalent, wenn beide denselben Satz von Transaktionen enthalten und dieselbe Reihenfolge widersprüchlicher Operationspaare aufweisen.

Parallelitätssteuerungstechniken stellen sicher, dass mehrere Transaktionen gleichzeitig ausgeführt werden, während die ACID-Eigenschaften der Transaktionen und die Serialisierbarkeit in den Zeitplänen beibehalten werden.

In diesem Kapitel werden die verschiedenen Ansätze zur Parallelitätskontrolle untersucht.

Sperrbasierte Parallelitätssteuerungsprotokolle

Sperrbasierte Parallelitätssteuerungsprotokolle verwenden das Konzept des Sperrens von Datenelementen. EINlockist eine einem Datenelement zugeordnete Variable, die bestimmt, ob Lese- / Schreibvorgänge für dieses Datenelement ausgeführt werden können. Im Allgemeinen wird eine Sperrkompatibilitätsmatrix verwendet, die angibt, ob ein Datenelement durch zwei Transaktionen gleichzeitig gesperrt werden kann.

Auf Sperren basierende Parallelitätskontrollsysteme können entweder einphasige oder zweiphasige Sperrprotokolle verwenden.

Einphasen-Sperrprotokoll

Bei dieser Methode sperrt jede Transaktion ein Element vor der Verwendung und gibt die Sperre frei, sobald die Verwendung beendet ist. Diese Sperrmethode sorgt für maximale Parallelität, erzwingt jedoch nicht immer die Serialisierbarkeit.

Zweiphasen-Sperrprotokoll

Bei dieser Methode gehen alle Sperrvorgänge dem ersten Sperr- oder Entsperrvorgang voraus. Die Transaktion besteht aus zwei Phasen. In der ersten Phase erhält eine Transaktion nur alle erforderlichen Sperren und gibt keine Sperre frei. Dies nennt man das Erweitern oder dasgrowing phase. In der zweiten Phase gibt die Transaktion die Sperren frei und kann keine neuen Sperren anfordern. Dies nennt man dasshrinking phase.

Jede Transaktion, die dem Zwei-Phasen-Sperrprotokoll folgt, ist garantiert serialisierbar. Dieser Ansatz bietet jedoch eine geringe Parallelität zwischen zwei widersprüchlichen Transaktionen.

Zeitstempel-Parallelitätssteuerungsalgorithmen

Auf Zeitstempeln basierende Algorithmen zur Steuerung der Parallelität verwenden den Zeitstempel einer Transaktion, um den gleichzeitigen Zugriff auf ein Datenelement zu koordinieren und die Serialisierbarkeit sicherzustellen. Ein Zeitstempel ist eine eindeutige Kennung, die DBMS einer Transaktion gibt, die die Startzeit der Transaktion darstellt.

Diese Algorithmen stellen sicher, dass Transaktionen in der durch ihre Zeitstempel vorgegebenen Reihenfolge festgeschrieben werden. Eine ältere Transaktion sollte vor einer jüngeren Transaktion festgeschrieben werden, da die ältere Transaktion vor der jüngeren in das System eingeht.

Zeitstempel-basierte Parallelitätssteuerungstechniken generieren serialisierbare Zeitpläne, sodass der entsprechende serielle Zeitplan in der Reihenfolge des Alters der teilnehmenden Transaktionen angeordnet ist.

Einige der auf Zeitstempeln basierenden Algorithmen zur Steuerung der Parallelität sind:

• Grundlegender Algorithmus für die Reihenfolge von Zeitstempeln.
• Bestimmungsalgorithmus für konservative Zeitstempel.
• Multiversionsalgorithmus basierend auf der Reihenfolge der Zeitstempel.

Die zeitstempelbasierte Bestellung folgt drei Regeln, um die Serialisierbarkeit zu erzwingen:

• Access Rule- Wenn zwei Transaktionen gleichzeitig versuchen, auf dasselbe Datenelement zuzugreifen, wird bei widersprüchlichen Vorgängen der älteren Transaktion Vorrang eingeräumt. Dies führt dazu, dass die jüngere Transaktion darauf wartet, dass die ältere Transaktion zuerst festgeschrieben wird.

• Late Transaction Rule- Wenn eine jüngere Transaktion ein Datenelement geschrieben hat, darf eine ältere Transaktion dieses Datenelement nicht lesen oder schreiben. Diese Regel verhindert, dass die ältere Transaktion festgeschrieben wird, nachdem die jüngere Transaktion bereits festgeschrieben wurde.

• Younger Transaction Rule - Eine jüngere Transaktion kann ein Datenelement lesen oder schreiben, das bereits von einer älteren Transaktion geschrieben wurde.

Optimistischer Parallelitätskontrollalgorithmus

In Systemen mit niedrigen Konfliktraten kann die Aufgabe, jede Transaktion auf Serialisierbarkeit zu überprüfen, die Leistung beeinträchtigen. In diesen Fällen wird der Test auf Serialisierbarkeit auf kurz vor dem Festschreiben verschoben. Da die Konfliktrate niedrig ist, ist auch die Wahrscheinlichkeit gering, Transaktionen abzubrechen, die nicht serialisierbar sind. Dieser Ansatz wird als optimistische Parallelitätssteuerungstechnik bezeichnet.

Bei diesem Ansatz ist der Lebenszyklus einer Transaktion in die folgenden drei Phasen unterteilt:

• Execution Phase - Eine Transaktion ruft Datenelemente in den Speicher ab und führt Operationen an ihnen aus.

• Validation Phase - Eine Transaktion führt Überprüfungen durch, um sicherzustellen, dass das Festschreiben ihrer Änderungen an der Datenbank den Serialisierbarkeitstest besteht.

• Commit Phase - Eine Transaktion schreibt ein geändertes Datenelement im Speicher auf die Festplatte zurück.

Dieser Algorithmus verwendet drei Regeln, um die Serialisierbarkeit in der Validierungsphase zu erzwingen:

Rule 1- zwei Transaktionen T Da _i und T _j , wenn T _i wird das Datenelement zu lesen , die T _j , dann T schreibt _i ‚s Ausführungsphase nicht überlappen kann mit T _j ‚s Festschreibungsphase. T _j kann erst _{festgeschrieben} werden, nachdem T _i die Ausführung beendet hat.

Rule 2- zwei Transaktionen T Da _i und T _j , wenn T _i wird das Datenelement zu schreiben , dass T _j liest, dann T _i ‚s Phasen - Commit nicht überlappen kann mit T _j ‚Ausführungsphase s. T _j kann erst ausgeführt werden, nachdem T _i bereits festgeschrieben hat.

Rule 3- Wenn bei zwei Transaktionen T _i und T _j T _i das Datenelement schreibt, das T _j auch schreibt, kann sich die Festschreibungsphase von T _i nicht mit der Festschreibungsphase von T _j überschneiden . T _j kann erst mit dem Festschreiben beginnen, nachdem T _i bereits festgeschrieben hat.

Parallelitätskontrolle in verteilten Systemen

In diesem Abschnitt werden wir sehen, wie die oben genannten Techniken in einem verteilten Datenbanksystem implementiert werden.

Verteilter Zwei-Phasen-Verriegelungsalgorithmus

Das Grundprinzip der verteilten Zweiphasenverriegelung ist dasselbe wie das Grundprotokoll der Zweiphasenverriegelung. In einem verteilten System gibt es jedoch Sites, die als Sperrmanager bezeichnet werden. Ein Sperrmanager steuert Sperrerfassungsanforderungen von Transaktionsmonitoren. Um die Koordination zwischen den Sperrmanagern an verschiedenen Standorten zu erzwingen, erhält mindestens ein Standort die Berechtigung, alle Transaktionen anzuzeigen und Sperrenkonflikte zu erkennen.

Abhängig von der Anzahl der Standorte, die Sperrkonflikte erkennen können, gibt es drei Arten von verteilten Zweiphasen-Sperransätzen:

• Centralized two-phase locking- Bei diesem Ansatz wird ein Standort als Zentralschlosermanager festgelegt. Alle Standorte in der Umgebung kennen den Standort des Zentralschlosermanagers und erhalten bei Transaktionen eine Sperre von diesem.

• Primary copy two-phase locking- Bei diesem Ansatz werden mehrere Standorte als Schleusenkontrollzentren ausgewiesen. Jeder dieser Standorte ist für die Verwaltung eines definierten Satzes von Sperren verantwortlich. Alle Standorte wissen, welches Sperrkontrollzentrum für die Verwaltung der Sperrung welcher Datentabelle / welchen Fragmentelements verantwortlich ist.

• Distributed two-phase locking- Bei diesem Ansatz gibt es eine Reihe von Sperrmanagern, bei denen jeder Sperrmanager Sperren von Datenelementen steuert, die an seinem lokalen Standort gespeichert sind. Der Speicherort des Sperrmanagers basiert auf der Datenverteilung und -replikation.

Verteilte Zeitstempel-Parallelitätskontrolle

In einem zentralisierten System wird der Zeitstempel einer Transaktion durch das Lesen der physischen Uhr bestimmt. In einem verteilten System können die lokalen physischen / logischen Taktwerte eines Standorts jedoch nicht als globale Zeitstempel verwendet werden, da sie nicht global eindeutig sind. Ein Zeitstempel besteht also aus einer Kombination der Site-ID und dem Uhrwert dieser Site.

Für die Implementierung von Zeitstempel-Bestellalgorithmen verfügt jeder Standort über einen Scheduler, der für jeden Transaktionsmanager eine separate Warteschlange verwaltet. Während der Transaktion sendet ein Transaktionsmanager eine Sperranforderung an den Scheduler der Site. Der Scheduler stellt die Anforderung in aufsteigender Zeitstempelreihenfolge in die entsprechende Warteschlange. Anfragen werden von der Vorderseite der Warteschlangen in der Reihenfolge ihrer Zeitstempel verarbeitet, dh der ältesten zuerst.

Konfliktdiagramme

Eine andere Methode besteht darin, Konfliktdiagramme zu erstellen. Hierzu werden Transaktionsklassen definiert. Eine Transaktionsklasse enthält zwei Datenelemente, die als Lesesatz und Schreibsatz bezeichnet werden. Eine Transaktion gehört zu einer bestimmten Klasse, wenn der Lesesatz der Transaktion eine Teilmenge des Lesesatzes der Klasse und der Schreibsatz der Transaktion eine Teilmenge des Schreibsatzes der Klasse ist. In der Lesephase gibt jede Transaktion ihre Leseanforderungen für die Datenelemente in ihrem Lesesatz aus. In der Schreibphase gibt jede Transaktion ihre Schreibanforderungen aus.

Für die Klassen, zu denen aktive Transaktionen gehören, wird ein Konfliktdiagramm erstellt. Diese enthält eine Reihe vertikaler, horizontaler und diagonaler Kanten. Eine vertikale Kante verbindet zwei Knoten innerhalb einer Klasse und kennzeichnet Konflikte innerhalb der Klasse. Eine horizontale Kante verbindet zwei Knoten über zwei Klassen und kennzeichnet einen Schreib-Schreib-Konflikt zwischen verschiedenen Klassen. Eine diagonale Kante verbindet zwei Knoten über zwei Klassen und bezeichnet einen Schreib-Lese- oder einen Lese-Schreib-Konflikt zwischen zwei Klassen.

Die Konfliktdiagramme werden analysiert, um festzustellen, ob zwei Transaktionen innerhalb derselben Klasse oder über zwei verschiedene Klassen hinweg parallel ausgeführt werden können.

Verteilter optimistischer Algorithmus zur Steuerung der Parallelität

Der verteilte optimistische Parallelitätskontrollalgorithmus erweitert den optimistischen Parallelitätskontrollalgorithmus. Für diese Erweiterung werden zwei Regeln angewendet -

Rule 1- Nach dieser Regel muss eine Transaktion bei ihrer Ausführung an allen Standorten lokal validiert werden. Wenn festgestellt wird, dass eine Transaktion an einem Standort ungültig ist, wird sie abgebrochen. Die lokale Validierung garantiert, dass die Transaktion an den Standorten, an denen sie ausgeführt wurde, seriell bleibt. Nachdem eine Transaktion den lokalen Validierungstest bestanden hat, wird sie global validiert.

Rule 2- Nach dieser Regel sollte eine Transaktion, nachdem sie den lokalen Validierungstest bestanden hat, global validiert werden. Durch die globale Validierung wird sichergestellt, dass zwei widersprüchliche Transaktionen, die an mehr als einem Standort zusammen ausgeführt werden, an allen Standorten, an denen sie zusammen ausgeführt werden, in derselben relativen Reihenfolge festgeschrieben werden. Dies kann erfordern, dass eine Transaktion nach der Validierung vor dem Festschreiben auf die andere widersprüchliche Transaktion wartet. Diese Anforderung macht den Algorithmus weniger optimistisch, da eine Transaktion möglicherweise nicht festgeschrieben werden kann, sobald sie an einem Standort validiert wird.

In diesem Kapitel werden die Mechanismen zur Behandlung von Deadlocks in Datenbanksystemen beschrieben. Wir werden die Mechanismen zur Behandlung von Deadlocks sowohl in zentralisierten als auch in verteilten Datenbanksystemen untersuchen.

Was sind Deadlocks?

Deadlock ist ein Status eines Datenbanksystems mit zwei oder mehr Transaktionen, wenn jede Transaktion auf ein Datenelement wartet, das von einer anderen Transaktion gesperrt wird. Ein Deadlock kann durch einen Zyklus im Wartediagramm angezeigt werden. Dies ist ein gerichteter Graph, in dem die Eckpunkte Transaktionen und die Kanten das Warten auf Datenelemente bezeichnen.

Beispielsweise wartet im folgenden Wartediagramm die Transaktion T1 auf das Datenelement X, das von T3 gesperrt wird. T3 wartet auf Y, das durch T2 gesperrt ist, und T2 wartet auf Z, das durch T1 gesperrt ist. Daher wird ein Wartezyklus gebildet, und keine der Transaktionen kann mit der Ausführung fortfahren.

Deadlock-Behandlung in zentralisierten Systemen

Es gibt drei klassische Ansätze für die Behandlung von Deadlocks:

• Deadlock-Prävention.
• Vermeidung von Deadlocks.
• Deadlock-Erkennung und -Entfernung.

Alle drei Ansätze können sowohl in ein zentrales als auch in ein verteiltes Datenbanksystem integriert werden.

Deadlock-Prävention

Der Deadlock-Verhinderungsansatz ermöglicht es keiner Transaktion, Sperren zu erwerben, die zu Deadlocks führen. Die Konvention lautet, dass, wenn mehr als eine Transaktion das Sperren desselben Datenelements anfordert, nur einer von ihnen die Sperre gewährt wird.

Eine der beliebtesten Methoden zur Verhinderung von Deadlocks ist die Vorerfassung aller Schlösser. Bei dieser Methode erfasst eine Transaktion alle Sperren, bevor mit der Ausführung begonnen wird, und behält die Sperren für die gesamte Dauer der Transaktion bei. Wenn eine andere Transaktion eine der bereits erworbenen Sperren benötigt, muss sie warten, bis alle benötigten Sperren verfügbar sind. Mit diesem Ansatz wird verhindert, dass das System blockiert wird, da keine der wartenden Transaktionen eine Sperre enthält.

Deadlock-Vermeidung

Der Deadlock-Vermeidungsansatz behandelt Deadlocks, bevor sie auftreten. Es analysiert die Transaktionen und die Sperren, um festzustellen, ob das Warten zu einem Deadlock führt oder nicht.

Das Verfahren kann kurz wie folgt angegeben werden. Transaktionen werden ausgeführt und fordern Datenelemente an, die gesperrt werden müssen. Der Sperrmanager prüft, ob die Sperre verfügbar ist. Wenn es verfügbar ist, weist der Sperrmanager das Datenelement zu und die Transaktion erwirbt die Sperre. Wenn das Element jedoch von einer anderen Transaktion im inkompatiblen Modus gesperrt wird, führt der Sperrmanager einen Algorithmus aus, um zu testen, ob das Halten der Transaktion im Wartezustand zu einem Deadlock führt oder nicht. Dementsprechend entscheidet der Algorithmus, ob die Transaktion warten kann oder eine der Transaktionen abgebrochen werden soll.

Zu diesem Zweck gibt es zwei Algorithmen, nämlich wait-die und wound-wait. Nehmen wir an, dass es zwei Transaktionen gibt, T1 und T2, bei denen T1 versucht, ein Datenelement zu sperren, das bereits von T2 gesperrt ist. Die Algorithmen sind wie folgt:

• Wait-Die- Wenn T1 älter als T2 ist, darf T1 warten. Wenn T1 jünger als T2 ist, wird T1 abgebrochen und später neu gestartet.

• Wound-Wait- Wenn T1 älter als T2 ist, wird T2 abgebrochen und später neu gestartet. Andernfalls darf T1 warten, wenn T1 jünger als T2 ist.

Deadlock-Erkennung und -Entfernung

Der Ansatz zur Erkennung und Entfernung von Deadlocks führt regelmäßig einen Algorithmus zur Erkennung von Deadlocks aus und entfernt Deadlocks, falls es einen gibt. Es wird nicht auf Deadlock geprüft, wenn eine Transaktion eine Anforderung für eine Sperre stellt. Wenn eine Transaktion eine Sperre anfordert, prüft der Sperrenmanager, ob diese verfügbar ist. Wenn es verfügbar ist, kann die Transaktion das Datenelement sperren. Andernfalls darf die Transaktion warten.

Da beim Gewähren von Sperranforderungen keine Vorsichtsmaßnahmen getroffen werden, sind einige Transaktionen möglicherweise blockiert. Um Deadlocks zu erkennen, überprüft der Sperrmanager regelmäßig, ob der Wartegraph Zyklen aufweist. Wenn das System blockiert ist, wählt der Sperrmanager aus jedem Zyklus eine Opfertransaktion aus. Das Opfer wird abgebrochen und zurückgerollt; und später neu gestartet. Einige der Methoden zur Opferauswahl sind:

• Wählen Sie die jüngste Transaktion.
• Wählen Sie die Transaktion mit den wenigsten Datenelementen.
• Wählen Sie die Transaktion aus, die am wenigsten aktualisiert wurde.
• Wählen Sie die Transaktion mit dem geringsten Neustartaufwand.
• Wählen Sie die Transaktion, die zwei oder mehr Zyklen gemeinsam ist.

Dieser Ansatz eignet sich hauptsächlich für Systeme mit geringen Transaktionen, bei denen eine schnelle Antwort auf Sperranforderungen erforderlich ist.

Deadlock-Behandlung in verteilten Systemen

Die Transaktionsverarbeitung in einem verteilten Datenbanksystem wird ebenfalls verteilt, dh dieselbe Transaktion kann an mehr als einem Standort verarbeitet werden. Die beiden Hauptprobleme bei der Behandlung von Deadlocks in einem verteilten Datenbanksystem, die in einem zentralisierten System nicht vorhanden sind, sind:transaction location und transaction control. Sobald diese Bedenken ausgeräumt sind, werden Deadlocks durch Deadlock-Verhinderung, Deadlock-Vermeidung oder Deadlock-Erkennung und -Entfernung behandelt.

Transaktionsort

Transaktionen in einem verteilten Datenbanksystem werden an mehreren Standorten verarbeitet und verwenden Datenelemente an mehreren Standorten. Der Umfang der Datenverarbeitung ist nicht gleichmäßig auf diese Standorte verteilt. Der Verarbeitungszeitraum variiert ebenfalls. Daher kann dieselbe Transaktion an einigen Standorten aktiv und an anderen inaktiv sein. Wenn sich zwei widersprüchliche Transaktionen an einem Standort befinden, kann es vorkommen, dass sich eine davon inaktiv befindet. Dieser Zustand tritt in einem zentralisierten System nicht auf. Dieses Problem wird als Transaktionsspeicherortproblem bezeichnet.

Dieses Problem kann durch das Daisy-Chain-Modell behoben werden. In diesem Modell enthält eine Transaktion bestimmte Details, wenn sie von einem Standort zu einem anderen verschoben wird. Einige der Details sind die Liste der erforderlichen Tabellen, die Liste der erforderlichen Sites, die Liste der besuchten Tabellen und Sites, die Liste der Tabellen und Sites, die noch besucht werden müssen, und die Liste der erworbenen Sperren mit Typen. Nachdem eine Transaktion entweder durch Festschreiben oder Abbrechen beendet wurde, sollten die Informationen an alle betroffenen Sites gesendet werden.

Transaktionskontrolle

Die Transaktionssteuerung befasst sich mit der Bestimmung und Steuerung der Standorte, die für die Verarbeitung einer Transaktion in einem verteilten Datenbanksystem erforderlich sind. Es gibt viele Optionen hinsichtlich der Wahl, wo die Transaktion verarbeitet werden soll und wie das Kontrollzentrum festgelegt werden soll, wie z.

• Ein Server kann als Kontrollzentrum ausgewählt werden.
• Das Kontrollzentrum kann von einem Server zum anderen wechseln.
• Die Verantwortung für die Steuerung kann von mehreren Servern geteilt werden.

Verteilte Deadlock-Prävention

Genau wie bei der zentralisierten Deadlock-Verhinderung sollte eine Transaktion beim verteilten Deadlock-Verhinderungsansatz alle Sperren erwerben, bevor mit der Ausführung begonnen wird. Dies verhindert Deadlocks.

Der Standort, an dem die Transaktion eingeht, wird als steuernder Standort bezeichnet. Die steuernde Site sendet Nachrichten an die Sites, an denen sich die Datenelemente befinden, um die Elemente zu sperren. Dann wartet es auf Bestätigung. Wenn alle Sites bestätigt haben, dass sie die Datenelemente gesperrt haben, wird die Transaktion gestartet. Wenn eine Site oder Kommunikationsverbindung ausfällt, muss die Transaktion warten, bis sie repariert wurde.

Obwohl die Implementierung einfach ist, weist dieser Ansatz einige Nachteile auf -

• Die Vorerfassung von Sperren erfordert eine lange Zeit für Kommunikationsverzögerungen. Dies erhöht die für die Transaktion erforderliche Zeit.

• Bei einem Site- oder Linkfehler muss eine Transaktion lange warten, damit sich die Sites erholen. Währenddessen sind die Elemente auf den laufenden Websites gesperrt. Dies kann die Ausführung anderer Transaktionen verhindern.

• Wenn der steuernde Standort ausfällt, kann er nicht mit den anderen Standorten kommunizieren. Diese Sites halten die gesperrten Datenelemente weiterhin in ihrem gesperrten Zustand, was zu einer Blockierung führt.

Verteilte Deadlock-Vermeidung

Wie im zentralisierten System behandelt die Vermeidung verteilter Deadlocks Deadlocks vor dem Auftreten. Darüber hinaus müssen in verteilten Systemen Probleme mit dem Transaktionsort und der Transaktionssteuerung behoben werden. Aufgrund der Verteilung der Transaktion können die folgenden Konflikte auftreten:

• Konflikt zwischen zwei Transaktionen auf derselben Site.
• Konflikt zwischen zwei Transaktionen an verschiedenen Standorten.

Im Konfliktfall kann eine der Transaktionen abgebrochen werden oder gemäß den Algorithmen für verteiltes Warten oder Warten warten.

Nehmen wir an, dass es zwei Transaktionen gibt, T1 und T2. T1 kommt an Standort P an und versucht, ein Datenelement zu sperren, das an diesem Standort bereits von T2 gesperrt wurde. Daher gibt es an Standort P einen Konflikt. Die Algorithmen sind wie folgt:

• Distributed Wound-Die

  • Wenn T1 älter als T2 ist, darf T1 warten. T1 kann die Ausführung fortsetzen, nachdem Standort P eine Nachricht erhalten hat, dass T2 an allen Standorten entweder festgeschrieben oder erfolgreich abgebrochen wurde.

  • Wenn T1 jünger als T2 ist, wird T1 abgebrochen. Die Parallelitätskontrolle an Standort P sendet eine Nachricht an alle Standorte, die T1 besucht hat, um T1 abzubrechen. Die steuernde Site benachrichtigt den Benutzer, wenn T1 an allen Sites erfolgreich abgebrochen wurde.

• Distributed Wait-Wait

  • Wenn T1 älter als T2 ist, muss T2 abgebrochen werden. Wenn T2 an Standort P aktiv ist, bricht Standort P T2 ab und setzt es zurück. Anschließend wird diese Nachricht an andere relevante Standorte gesendet. Wenn T2 Standort P verlassen hat, aber an Standort Q aktiv ist, sendet Standort P, dass T2 abgebrochen wurde. Site L bricht dann T2 ab und setzt es zurück und sendet diese Nachricht an alle Sites.

  • Wenn T1 jünger als T1 ist, darf T1 warten. T1 kann die Ausführung fortsetzen, nachdem Standort P eine Nachricht erhalten hat, dass T2 die Verarbeitung abgeschlossen hat.

Verteilte Deadlock-Erkennung

Genau wie bei der zentralisierten Deadlock-Erkennung können Deadlocks auftreten und werden entfernt, wenn sie erkannt werden. Das System führt keine Überprüfungen durch, wenn eine Transaktion eine Sperranforderung stellt. Zur Implementierung werden globale Wartediagramme erstellt. Das Vorhandensein eines Zyklus im globalen Wartediagramm zeigt Deadlocks an. Es ist jedoch schwierig, Deadlocks zu erkennen, da die Transaktion im gesamten Netzwerk auf Ressourcen wartet.

Alternativ können Deadlock-Erkennungsalgorithmen Timer verwenden. Jede Transaktion ist einem Timer zugeordnet, der auf einen Zeitraum eingestellt ist, in dem der Abschluss einer Transaktion erwartet wird. Wenn eine Transaktion nicht innerhalb dieses Zeitraums abgeschlossen wird, läuft der Timer ab und zeigt einen möglichen Deadlock an.

Ein weiteres Werkzeug für die Handhabung von Deadlocks ist ein Deadlock-Detektor. In einem zentralen System gibt es einen Deadlock-Detektor. In einem verteilten System kann es mehr als einen Deadlock-Detektor geben. Ein Deadlock-Detektor kann Deadlocks für die von ihm kontrollierten Standorte finden. Es gibt drei Alternativen für die Deadlock-Erkennung in einem verteilten System, nämlich.

• Centralized Deadlock Detector - Ein Standort wird als zentraler Deadlock-Detektor bezeichnet.

• Hierarchical Deadlock Detector - Eine Reihe von Deadlock-Detektoren sind hierarchisch angeordnet.

• Distributed Deadlock Detector - Alle Sites sind daran beteiligt, Deadlocks zu erkennen und zu entfernen.

Dieses Kapitel befasst sich mit der Replikationssteuerung, die erforderlich ist, um an allen Standorten konsistente Daten zu erhalten. Wir werden die Replikationssteuerungstechniken und die für die Replikationssteuerung erforderlichen Algorithmen untersuchen.

Wie vorhin besprochen, replicationist eine Technik, die in verteilten Datenbanken verwendet wird, um mehrere Kopien einer Datentabelle an verschiedenen Standorten zu speichern. Das Problem bei mehreren Kopien an mehreren Standorten ist der Aufwand für die Aufrechterhaltung der Datenkonsistenz, insbesondere bei Aktualisierungsvorgängen.

Um an allen Standorten konsistente Daten zu erhalten, müssen Replikationssteuerungstechniken angewendet werden. Es gibt zwei Ansätze zur Replikationssteuerung:

• Synchrone Replikationssteuerung
• Asynchrone Replikationssteuerung

Synchrone Replikationssteuerung

Beim synchronen Replikationsansatz wird die Datenbank synchronisiert, sodass alle Replikationen immer den gleichen Wert haben. Eine Transaktion, die ein Datenelement anfordert, hat an allen Standorten Zugriff auf denselben Wert. Um diese Einheitlichkeit sicherzustellen, wird eine Transaktion, die ein Datenelement aktualisiert, erweitert, sodass die Aktualisierung in allen Kopien des Datenelements erfolgt. Im Allgemeinen wird zu diesem Zweck ein zweiphasiges Festschreibungsprotokoll verwendet.

Betrachten wir zum Beispiel eine Datentabelle PROJECT (PId, PName, PLocation). Wir müssen eine Transaktion T1 ausführen, die PLocation auf 'Mumbai' aktualisiert, wenn PLocation 'Bombay' ist. Wenn keine Replikationen vorhanden sind, lauten die Operationen in Transaktion T1 -

Begin T1: 
   Update PROJECT Set PLocation = 'Mumbai' 
   Where PLocation = 'Bombay'; 
End T1;

Wenn die Datentabelle zwei Replikate an Standort A und Standort B enthält, muss T1 zwei untergeordnete Knoten T1A und T1B erzeugen, die den beiden Standorten entsprechen. Die erweiterte Transaktion T1 lautet -

Begin T1: 
   Begin T1A : 
      Update PROJECT Set PLocation = 'Mumbai' 
      Where PLocation = 'Bombay'; 
   End T1A;  
	
   Begin T2A : 
      Update PROJECT Set PLocation = 'Mumbai'
      Where PLocation = 'Bombay'; 
   End T2A; 
	
End T1;

Asynchrone Replikationssteuerung

Beim asynchronen Replikationsansatz behalten die Replikate nicht immer den gleichen Wert bei. Ein oder mehrere Replikate können einen veralteten Wert speichern, und eine Transaktion kann die verschiedenen Werte anzeigen. Der Vorgang, bei dem alle Replikate auf den aktuellen Wert gebracht werden, wird aufgerufensynchronization.

Eine beliebte Synchronisationsmethode ist die Store-and-Forward-Methode. Bei dieser Methode wird ein Standort als primärer Standort festgelegt, und die anderen Standorte sind sekundäre Standorte. Die primäre Site enthält immer aktualisierte Werte. Alle Transaktionen werden zuerst am primären Standort eingegeben. Diese Transaktionen werden dann für die Anwendung an den sekundären Standorten in die Warteschlange gestellt. Die sekundären Standorte werden mithilfe der Rollout-Methode nur aktualisiert, wenn eine Transaktion für die Ausführung geplant ist.

Replikationssteuerungsalgorithmen

Einige der Replikationssteuerungsalgorithmen sind -

• Master-Slave-Replikationssteuerungsalgorithmus.
• Verteilter Abstimmungsalgorithmus.
• Mehrheitskonsensalgorithmus.
• Zirkulierender Token-Algorithmus.

Algorithmus zur Steuerung der Master-Slave-Replikation

Es gibt eine Master-Site und 'N' Slave-Sites. Am Master-Standort wird ein Master-Algorithmus ausgeführt, um Konflikte zu erkennen. An jedem Slave-Standort wird eine Kopie des Slave-Algorithmus ausgeführt. Der Gesamtalgorithmus wird in den folgenden zwei Phasen ausgeführt:

• Transaction acceptance/rejection phase- Wenn eine Transaktion in den Transaktionsmonitor eines Slave-Standorts eingeht, sendet der Slave-Standort eine Anforderung an den Master-Standort. Die Master-Site sucht nach Konflikten. Wenn keine Konflikte vorliegen, sendet der Master eine ACK + -Nachricht an den Slave-Standort, der dann die Transaktionsanwendungsphase startet. Andernfalls sendet der Master eine "ACK-" Nachricht an den Slave, der die Transaktion dann ablehnt.

• Transaction application phase- Beim Eintritt in diese Phase sendet die Slave-Site, an der die Transaktion eingegeben wurde, eine Anfrage an alle Slaves zur Ausführung der Transaktion. Beim Empfang der Anforderungen führen die Peer-Slaves die Transaktion aus und senden nach Abschluss eine „ACK“ an den anfordernden Slave. Nachdem der anfordernde Slave von allen Peers "ACK" -Nachrichten erhalten hat, sendet er eine "DONE" -Nachricht an die Master-Site. Der Master versteht, dass die Transaktion abgeschlossen wurde, und entfernt sie aus der ausstehenden Warteschlange.

Verteilter Abstimmungsalgorithmus

Dies umfasst 'N' Peer-Sites, die alle eine Transaktion "OK" machen müssen, bevor sie ausgeführt werden kann. Es folgen die beiden Phasen dieses Algorithmus:

• Distributed transaction acceptance phase- Wenn eine Transaktion in den Transaktionsmanager einer Site eingeht, sendet sie eine Transaktionsanforderung an alle anderen Sites. Beim Empfang einer Anfrage löst eine Peer-Site Konflikte mithilfe prioritätsbasierter Abstimmungsregeln. Wenn alle Peer-Sites mit der Transaktion „OK“ sind, startet die anfordernde Site die Anwendungsphase. Wenn eine der Peer-Sites eine Transaktion nicht „OK“ macht, lehnt die anfordernde Site die Transaktion ab.

• Distributed transaction application phase- Beim Eintritt in diese Phase sendet die Site, an der die Transaktion eingegeben wurde, eine Anfrage an alle Slaves zur Ausführung der Transaktion. Beim Empfang der Anforderungen führen die Peer-Slaves die Transaktion aus und senden nach Abschluss eine "ACK" -Nachricht an den anfordernden Slave. Nachdem der anfordernde Slave von allen Peers "ACK" -Nachrichten erhalten hat, teilt er dem Transaktionsmanager mit, dass die Transaktion abgeschlossen wurde.

Mehrheitskonsensalgorithmus

Dies ist eine Abweichung vom verteilten Abstimmungsalgorithmus, bei dem eine Transaktion ausgeführt werden darf, wenn eine Mehrheit der Peers eine Transaktion „OK“ macht. Dies ist in drei Phasen unterteilt -

• Voting phase- Wenn eine Transaktion in den Transaktionsmanager einer Site eingeht, sendet sie eine Transaktionsanforderung an alle anderen Sites. Beim Empfang einer Anforderung testet eine Peer-Site mithilfe von Abstimmungsregeln auf Konflikte und hält die in Konflikt stehenden Transaktionen, falls vorhanden, in der ausstehenden Warteschlange. Dann sendet es entweder eine "OK" - oder eine "NICHT OK" -Nachricht.

• Transaction acceptance/rejection phase- Wenn die anfordernde Site bei der Transaktion die Mehrheit "OK" erhält, akzeptiert sie die Transaktion und sendet "ACCEPT" an alle Sites. Andernfalls wird "REJECT" an alle Sites gesendet und die Transaktion abgelehnt.

• Transaction application phase- Wenn eine Peer-Site eine "REJECT" -Nachricht empfängt, entfernt sie diese Transaktion aus ihrer ausstehenden Liste und überprüft alle zurückgestellten Transaktionen erneut. Wenn eine Peer-Site eine "ACCEPT" -Nachricht empfängt, wendet sie die Transaktion an und lehnt alle zurückgestellten Transaktionen in der ausstehenden Warteschlange ab, die mit dieser Transaktion in Konflikt stehen. Nach Abschluss sendet es eine „ACK“ an den anfordernden Slave.

Zirkulierender Token-Algorithmus

Bei diesem Ansatz werden die Transaktionen im System unter Verwendung eines zirkulierenden Tokens serialisiert und entsprechend für jedes Replikat der Datenbank ausgeführt. Somit werden alle Transaktionen akzeptiert, dh keine wird abgelehnt. Dies hat zwei Phasen -

• Transaction serialization phase- In dieser Phase sollen alle Transaktionen in einer Serialisierungsreihenfolge ausgeführt werden. Jeder Transaktion an jedem Standort wird ein eindeutiges Ticket aus einer sequentiellen Serie zugewiesen, das die Reihenfolge der Transaktion angibt. Sobald einer Transaktion ein Ticket zugewiesen wurde, wird es an alle Standorte gesendet.

• Transaction application phase- Wenn eine Site eine Transaktion zusammen mit ihrem Ticket empfängt, platziert sie die Transaktion gemäß ihrem Ticket zur Ausführung. Nach Abschluss der Transaktion sendet diese Site eine entsprechende Nachricht. Eine Transaktion endet, wenn die Ausführung an allen Standorten abgeschlossen ist.

Ein Datenbankverwaltungssystem ist anfällig für eine Reihe von Fehlern. In diesem Kapitel werden die Fehlertypen und Festschreibungsprotokolle untersucht. In einem verteilten Datenbanksystem können Fehler grob in weiche Fehler, harte Fehler und Netzwerkfehler unterteilt werden.

Soft Failure

Soft Failure ist die Art von Fehler, die den Verlust des flüchtigen Speichers des Computers und nicht des dauerhaften Speichers verursacht. Hier gehen die im nicht persistenten Speicher gespeicherten Informationen wie Hauptspeicher, Puffer, Caches oder Register verloren. Sie werden auch als Systemabsturz bezeichnet. Die verschiedenen Arten von weichen Fehlern sind wie folgt:

• Betriebssystemfehler.
• Hauptspeicherabsturz.
• Transaktionsfehler oder Abtreibung.
• Systemgenerierter Fehler wie ganzzahliger Überlauf oder Fehler beim Teilen durch Null.
• Fehler bei der Unterstützung der Software.
• Stromausfall.

Harter Fehler

Ein schwerer Fehler ist die Art des Fehlers, der zu Datenverlust im dauerhaften oder nichtflüchtigen Speicher wie der Festplatte führt. Ein Festplattenfehler kann zu einer Beschädigung der Daten in einigen Festplattenblöcken oder zu einem Ausfall der gesamten Festplatte führen. Die Ursachen für einen schweren Ausfall sind -

• Stromausfall.
• Medienfehler.
• Lese- / Schreibstörung.
• Beschädigung von Informationen auf der Festplatte.
• Lese- / Schreibkopfabsturz der Festplatte.

Die Wiederherstellung nach Festplattenfehlern kann kurz sein, wenn eine neue, formatierte und gebrauchsfertige Festplatte in Reserve ist. Andernfalls umfasst die Dauer die Zeit, die erforderlich ist, um eine Bestellung zu erhalten, die Festplatte zu kaufen und vorzubereiten.

Netzwerkfehler

Netzwerkfehler sind in verteilten oder Netzwerkdatenbanken weit verbreitet. Diese umfassen die Fehler, die im Datenbanksystem aufgrund der verteilten Natur der Daten und der Datenübertragung über das Netzwerk verursacht werden. Die Ursachen für Netzwerkfehler sind folgende:

• Kommunikationsverbindungsfehler.
• Netzüberlastung.
• Informationsbeschädigung während der Übertragung.
• Site-Fehler.
• Netzwerkpartitionierung.

Protokolle festschreiben

Jedes Datenbanksystem sollte sicherstellen, dass die gewünschten Eigenschaften einer Transaktion auch nach Fehlern erhalten bleiben. Wenn während der Ausführung einer Transaktion ein Fehler auftritt, können alle durch die Transaktion hervorgerufenen Änderungen nicht festgeschrieben werden. Dies macht die Datenbank inkonsistent. Commit-Protokolle verhindern dieses Szenario, indem sie entweder die Transaktion rückgängig machen (Rollback) oder die Transaktion wiederholen (Roll Forward).

Commit Point

Der Zeitpunkt, zu dem die Entscheidung getroffen wird, ob eine Transaktion festgeschrieben oder abgebrochen werden soll, wird als Festschreibungspunkt bezeichnet. Im Folgenden sind die Eigenschaften eines Festschreibungspunkts aufgeführt.

• Es ist ein Zeitpunkt, an dem die Datenbank konsistent ist.

• Zu diesem Zeitpunkt können die durch die Datenbank hervorgerufenen Änderungen von den anderen Transaktionen gesehen werden. Alle Transaktionen können eine konsistente Ansicht der Datenbank haben.

• Zu diesem Zeitpunkt wurden alle Vorgänge der Transaktion erfolgreich ausgeführt und ihre Auswirkungen wurden im Transaktionsprotokoll aufgezeichnet.

• Zu diesem Zeitpunkt kann eine Transaktion bei Bedarf sicher rückgängig gemacht werden.

• Zu diesem Zeitpunkt gibt eine Transaktion alle von ihr gehaltenen Sperren frei.

Transaktion rückgängig machen

Das Rückgängigmachen aller von einer Transaktion an einer Datenbank vorgenommenen Änderungen wird als Rückgängigmachen der Transaktion oder Zurücksetzen der Transaktion bezeichnet. Dies gilt hauptsächlich für den Fall eines weichen Ausfalls.

Transaktion wiederholen

Das erneute Anwenden der von einer Transaktion an einer Datenbank vorgenommenen Änderungen wird als Transaktionswiederholung oder Transaktions-Rollforward bezeichnet. Dies wird hauptsächlich zur Wiederherstellung nach einem schweren Fehler angewendet.

Transaktionsprotokoll

Ein Transaktionsprotokoll ist eine sequentielle Datei, die Transaktionsvorgänge für Datenbankelemente verfolgt. Da das Protokoll sequentieller Natur ist, wird es entweder von Anfang an oder von Ende an sequentiell verarbeitet.

Zweck eines Transaktionsprotokolls -

• Unterstützung von Festschreibungsprotokollen zum Festschreiben oder Unterstützen von Transaktionen.
• Unterstützung der Datenbankwiederherstellung nach einem Fehler.

Ein Transaktionsprotokoll wird normalerweise auf der Festplatte gespeichert, damit es nicht von Softfehlern betroffen ist. Darüber hinaus wird das Protokoll regelmäßig in einem Archivspeicher wie einem Magnetband gesichert, um es auch vor Festplattenfehlern zu schützen.

Listen in Transaktionsprotokollen

Das Transaktionsprotokoll verwaltet je nach Status der Transaktion fünf Arten von Listen. Diese Liste hilft dem Wiederherstellungsmanager, den Status einer Transaktion zu ermitteln. Der Status und die entsprechenden Listen lauten wie folgt:

• Eine Transaktion mit einem Transaktionsstartdatensatz und einem Transaktions-Commit-Datensatz ist eine festgeschriebene Transaktion, die in der Commit-Liste verwaltet wird.

• Eine Transaktion mit einem Transaktionsstartdatensatz und einem Transaktionsfehlerdatensatz, jedoch keinem Transaktionsabbruchdatensatz, ist eine fehlgeschlagene Transaktion, die in der Liste der fehlgeschlagenen Transaktionen verwaltet wird.

• Eine Transaktion mit einem Transaktionsstartdatensatz und einem Transaktionsabbruchdatensatz ist eine abgebrochene Transaktion, die in der Abbruchliste verwaltet wird.

• Eine Transaktion mit einem Transaktionsstartdatensatz und einem Transaktions-Vor-Festschreibungs-Datensatz ist eine Vor-Festschreibungs-Transaktion, dh eine Transaktion, bei der alle Vorgänge ausgeführt, aber nicht festgeschrieben wurden - und in der Vor-Festschreibungsliste verwaltet wird.

• Eine Transaktion mit einem Transaktionsstartdatensatz, aber keinen Datensätzen von Vor-Festschreiben, Festschreiben, Abbrechen oder Fehlschlagen ist eine aktive Transaktion, die in der aktiven Liste verwaltet wird.

Sofortiges Update und verzögertes Update

Sofortiges Update und verzögertes Update sind zwei Methoden zum Verwalten von Transaktionsprotokollen.

Im immediate updateWenn eine Transaktion ausgeführt wird, werden die von der Transaktion vorgenommenen Aktualisierungen direkt auf die Festplatte geschrieben. Die alten Werte und die Aktualisierungswerte werden in das Protokoll geschrieben, bevor in die Datenbank auf der Festplatte geschrieben wird. Beim Festschreiben werden die auf der Festplatte vorgenommenen Änderungen dauerhaft übernommen. Beim Rollback werden die von der Transaktion in der Datenbank vorgenommenen Änderungen verworfen und die alten Werte aus den im Protokoll gespeicherten alten Werten in der Datenbank wiederhergestellt.

Im deferred updateWenn eine Transaktion ausgeführt wird, werden die von der Transaktion an der Datenbank vorgenommenen Aktualisierungen in der Protokolldatei aufgezeichnet. Beim Festschreiben werden die Änderungen im Protokoll auf die Festplatte geschrieben. Beim Rollback werden die Änderungen im Protokoll verworfen und es werden keine Änderungen auf die Datenbank angewendet.

Um sich von Datenbankfehlern zu erholen, greifen Datenbankverwaltungssysteme auf eine Reihe von Wiederherstellungsverwaltungstechniken zurück. In diesem Kapitel werden die verschiedenen Ansätze für die Datenbankwiederherstellung untersucht.

Die typischen Strategien für die Datenbankwiederherstellung sind -

• Bei weichen Fehlern, die zu einer Inkonsistenz der Datenbank führen, umfasst die Wiederherstellungsstrategie das Rückgängigmachen oder Zurücksetzen von Transaktionen. Manchmal kann jedoch auch eine Transaktionswiederholung angewendet werden, um einen konsistenten Status der Transaktion wiederherzustellen.

• Bei schwerwiegenden Fehlern, die zu erheblichen Schäden an der Datenbank führen, umfassen Wiederherstellungsstrategien das Wiederherstellen einer früheren Kopie der Datenbank aus der Archivsicherung. Ein aktuellerer Status der Datenbank wird durch Wiederherstellen von Vorgängen festgeschriebener Transaktionen aus dem Transaktionsprotokoll erhalten.

Wiederherstellung nach einem Stromausfall

Ein Stromausfall führt zu einem Informationsverlust im nicht persistenten Speicher. Wenn die Stromversorgung wiederhergestellt ist, werden das Betriebssystem und das Datenbankverwaltungssystem neu gestartet. Der Wiederherstellungsmanager initiiert die Wiederherstellung aus den Transaktionsprotokollen.

Im Falle eines sofortigen Aktualisierungsmodus führt der Wiederherstellungsmanager die folgenden Aktionen aus:

• Transaktionen, die sich in der aktiven Liste und der fehlgeschlagenen Liste befinden, werden rückgängig gemacht und in die Abbruchliste geschrieben.

• Transaktionen, die sich in der Liste vor dem Festschreiben befinden, werden wiederholt.

• Für Transaktionen in Festschreibungs- oder Abbruchlisten werden keine Maßnahmen ergriffen.

Im Falle eines verzögerten Aktualisierungsmodus führt der Wiederherstellungsmanager die folgenden Aktionen aus:

• Transaktionen, die sich in der aktiven Liste und der fehlgeschlagenen Liste befinden, werden in die Abbruchliste geschrieben. Es sind keine Rückgängig-Vorgänge erforderlich, da die Änderungen noch nicht auf die Festplatte geschrieben wurden.

• Transaktionen, die sich in der Liste vor dem Festschreiben befinden, werden wiederholt.

• Für Transaktionen in Festschreibungs- oder Abbruchlisten werden keine Maßnahmen ergriffen.

Wiederherstellung nach einem Festplattenfehler

Ein Festplattenfehler oder ein harter Absturz führt zu einem vollständigen Datenbankverlust. Um diesen schweren Absturz wiederherzustellen, wird eine neue Festplatte vorbereitet, das Betriebssystem wiederhergestellt und schließlich die Datenbank mithilfe der Datenbanksicherung und des Transaktionsprotokolls wiederhergestellt. Die Wiederherstellungsmethode ist für den sofortigen und den verzögerten Aktualisierungsmodus gleich.

Der Wiederherstellungsmanager führt die folgenden Aktionen aus:

• Die Transaktionen in der Festschreibungsliste und der Vor-Festschreibungsliste werden wiederholt und in die Festschreibungsliste im Transaktionsprotokoll geschrieben.

• Die Transaktionen in der aktiven Liste und der fehlgeschlagenen Liste werden rückgängig gemacht und in die Abbruchliste im Transaktionsprotokoll geschrieben.

Checkpointing

Checkpointist ein Zeitpunkt, zu dem ein Datensatz aus den Puffern in die Datenbank geschrieben wird. Infolgedessen muss der Wiederherstellungsmanager im Falle eines Systemabsturzes die Transaktionen, die vor dem Checkpoint festgeschrieben wurden, nicht wiederholen. Regelmäßiges Checkpointing verkürzt den Wiederherstellungsprozess.

Die zwei Arten von Checkpointing-Techniken sind:

• Konsistentes Checkpointing
• Fuzzy Checkpointing

Konsistentes Checkpointing

Durch konsistentes Checkpointing wird ein konsistentes Image der Datenbank am Checkpoint erstellt. Während der Wiederherstellung werden nur die Transaktionen rückgängig gemacht oder wiederholt, die sich auf der rechten Seite des letzten Prüfpunkts befinden. Die Transaktionen auf der linken Seite des letzten konsistenten Prüfpunkts sind bereits festgeschrieben und müssen nicht erneut verarbeitet werden. Die zum Checkpointing ergriffenen Maßnahmen sind:

• Die aktiven Transaktionen werden vorübergehend ausgesetzt.
• Alle Änderungen in den Hauptspeicherpuffern werden auf die Festplatte geschrieben.
• Ein "Checkpoint" -Datensatz wird in das Transaktionsprotokoll geschrieben.
• Das Transaktionsprotokoll wird auf die Festplatte geschrieben.
• Die angehaltenen Transaktionen werden fortgesetzt.

Wenn in Schritt 4 auch das Transaktionsprotokoll archiviert wird, hilft dieser Prüfpunkt bei der Wiederherstellung nach Festplatten- und Stromausfällen, andernfalls hilft er nur bei der Wiederherstellung nach Stromausfällen.

Fuzzy Checkpointing

Beim Fuzzy-Checkpointing werden zum Zeitpunkt des Checkpoints alle aktiven Transaktionen in das Protokoll geschrieben. Bei einem Stromausfall verarbeitet der Wiederherstellungsmanager nur die Transaktionen, die während des Prüfpunkts und später aktiv waren. Die Transaktionen, die vor dem Checkpoint festgeschrieben wurden, werden auf die Festplatte geschrieben und müssen daher nicht erneut ausgeführt werden.

Beispiel für Checkpointing

Nehmen wir an, dass im System die Zeit des Checkpointing tcheck und die Zeit des Systemabsturzes tfail ist. Es gebe vier Transaktionen T _a , T _b , T _c und T _d, so dass -

• T _a legt vor dem Checkpoint fest.

• T _b startet vor dem Checkpoint und wird vor dem Systemabsturz festgeschrieben.

• T _c startet nach dem Checkpoint und wird vor dem Systemabsturz festgeschrieben.

• T _d startet nach dem Checkpoint und war zum Zeitpunkt des Systemabsturzes aktiv.

Die Situation ist in der folgenden Abbildung dargestellt -

Die vom Wiederherstellungsmanager ausgeführten Aktionen sind:

• Mit T _{a wird} nichts gemacht .
• Die Transaktionswiederholung wird für T _b und T _{c durchgeführt} .
• Das Rückgängigmachen der Transaktion wird für T _{d durchgeführt} .

Transaktionswiederherstellung mit UNDO / REDO

Die Wiederherstellung von Transaktionen wird durchgeführt, um die nachteiligen Auswirkungen fehlerhafter Transaktionen zu beseitigen, anstatt sich von einem Fehler zu erholen. Zu den fehlerhaften Transaktionen gehören alle Transaktionen, die die Datenbank in einen unerwünschten Zustand versetzt haben, sowie die Transaktionen, bei denen Werte verwendet wurden, die von den fehlerhaften Transaktionen geschrieben wurden.

Die Wiederherstellung von Transaktionen ist in diesen Fällen ein zweistufiger Prozess -

• Machen Sie alle fehlerhaften Transaktionen und Transaktionen, die von den fehlerhaften Transaktionen betroffen sein können, rückgängig.

• REDO alle Transaktionen, die nicht fehlerhaft sind, aber aufgrund der fehlerhaften Transaktionen rückgängig gemacht wurden.

Schritte für die UNDO-Operation sind -

• Wenn die fehlerhafte Transaktion INSERT ausgeführt hat, löscht der Wiederherstellungsmanager die eingefügten Datenelemente.

• Wenn die fehlerhafte Transaktion DELETE ausgeführt hat, fügt der Wiederherstellungsmanager die gelöschten Datenelemente aus dem Protokoll ein.

• Wenn die fehlerhafte Transaktion UPDATE ausgeführt hat, entfernt der Wiederherstellungsmanager den Wert, indem er den Wert vor der Aktualisierung aus dem Protokoll schreibt.

Schritte für die REDO-Operation sind -

• Wenn die Transaktion INSERT ausgeführt hat, generiert der Wiederherstellungsmanager eine Einfügung aus dem Protokoll.

• Wenn die Transaktion DELETE ausgeführt hat, generiert der Wiederherstellungsmanager ein Löschen aus dem Protokoll.

• Wenn die Transaktion UPDATE ausgeführt hat, generiert der Wiederherstellungsmanager eine Aktualisierung aus dem Protokoll.

In einem lokalen Datenbanksystem muss der Transaktionsmanager zum Festschreiben einer Transaktion nur die Entscheidung zum Festschreiben an den Wiederherstellungsmanager übermitteln. In einem verteilten System sollte der Transaktionsmanager jedoch die Entscheidung übermitteln, alle Server an den verschiedenen Standorten, an denen die Transaktion ausgeführt wird, festzuschreiben, und die Entscheidung einheitlich durchsetzen. Wenn die Verarbeitung an jedem Standort abgeschlossen ist, erreicht sie den teilweise festgeschriebenen Transaktionsstatus und wartet, bis alle anderen Transaktionen ihren teilweise festgeschriebenen Status erreicht haben. Wenn die Nachricht empfangen wird, dass alle Sites zum Festschreiben bereit sind, beginnt das Festschreiben. In einem verteilten System werden entweder alle Sites festgeschrieben oder keiner von ihnen.

Die verschiedenen verteilten Festschreibungsprotokolle sind -

• Einphasiges Commit
• Zwei-Phasen-Commit
• Dreiphasiges Commit

Verteiltes einphasiges Commit

Das verteilte einphasige Festschreiben ist das einfachste Festschreibungsprotokoll. Nehmen wir an, es gibt eine steuernde Site und eine Reihe von Slave-Sites, an denen die Transaktion ausgeführt wird. Die Schritte beim verteilten Festschreiben sind:

• Nachdem jeder Slave seine Transaktion lokal abgeschlossen hat, sendet er eine "FERTIG" -Nachricht an die steuernde Site.

• Die Slaves warten auf die Nachricht "Commit" oder "Abort" von der steuernden Site. Diese Wartezeit wird aufgerufenwindow of vulnerability.

• Wenn die steuernde Site von jedem Slave die Nachricht "FERTIG" empfängt, trifft sie eine Entscheidung zum Festschreiben oder Abbrechen. Dies wird als Festschreibungspunkt bezeichnet. Dann sendet es diese Nachricht an alle Slaves.

• Beim Empfang dieser Nachricht legt ein Slave entweder fest oder bricht ab und sendet dann eine Bestätigungsnachricht an die steuernde Stelle.

Verteiltes zweiphasiges Commit

Das verteilte zweiphasige Festschreiben verringert die Anfälligkeit von einphasigen Festschreibungsprotokollen. Die in den beiden Phasen ausgeführten Schritte sind wie folgt:

Phase 1: Prepare Phase

• Nachdem jeder Slave seine Transaktion lokal abgeschlossen hat, sendet er eine "FERTIG" -Nachricht an die steuernde Site. Wenn die steuernde Site von allen Slaves die Nachricht "FERTIG" erhalten hat, sendet sie eine Nachricht "Vorbereiten" an die Slaves.

• Die Sklaven stimmen darüber ab, ob sie noch etwas begehen wollen oder nicht. Wenn ein Slave ein Commit durchführen möchte, sendet er eine "Bereit" -Nachricht.

• Ein Slave, der kein Commit durchführen möchte, sendet eine Nachricht "Nicht bereit". Dies kann passieren, wenn der Slave widersprüchliche gleichzeitige Transaktionen hat oder eine Zeitüberschreitung vorliegt.

Phase 2: Commit/Abort Phase

• Nachdem die steuernde Site von allen Slaves die Nachricht "Bereit" erhalten hat -

  • Die steuernde Site sendet eine "Global Commit" -Nachricht an die Slaves.

  • Die Slaves wenden die Transaktion an und senden eine "Commit ACK" -Nachricht an die steuernde Site.

  • Wenn die steuernde Site von allen Slaves die Nachricht "Commit ACK" erhält, wird die Transaktion als festgeschrieben betrachtet.

• Nachdem der kontrollierende Standort die erste Nachricht "Nicht bereit" von einem Slave erhalten hat -

  • Die steuernde Site sendet eine "Global Abort" -Nachricht an die Slaves.

  • Die Slaves brechen die Transaktion ab und senden eine "Abort ACK" -Nachricht an die steuernde Site.

  • Wenn die steuernde Site von allen Slaves die Nachricht "ACK abbrechen" empfängt, wird die Transaktion als abgebrochen betrachtet.

Verteiltes dreiphasiges Commit

Die Schritte beim verteilten dreiphasigen Festschreiben sind wie folgt:

Phase 1: Prepare Phase

Die Schritte sind die gleichen wie beim verteilten zweiphasigen Festschreiben.

Phase 2: Prepare to Commit Phase

• Die steuernde Site gibt eine Broadcast-Nachricht "Enter Prepared State" aus.
• Die Slave-Sites stimmen als Antwort mit „OK“ ab.

Phase 3: Commit / Abort Phase

Die Schritte sind die gleichen wie beim zweiphasigen Festschreiben, außer dass die Meldung "ACK festschreiben" / "ACK abbrechen" nicht erforderlich ist.

In diesem Kapitel werden die Bedrohungen, denen ein Datenbanksystem ausgesetzt ist, und die Kontrollmaßnahmen untersucht. Wir werden auch Kryptographie als Sicherheitsinstrument untersuchen.

Datenbanksicherheit und Bedrohungen

Datensicherheit ist ein wesentlicher Aspekt jedes Datenbanksystems. In verteilten Systemen ist dies aufgrund der großen Anzahl von Benutzern, der fragmentierten und replizierten Daten, mehrerer Standorte und der verteilten Steuerung von besonderer Bedeutung.

Bedrohungen in einer Datenbank

• Availability loss - Der Verfügbarkeitsverlust bezieht sich auf die Nichtverfügbarkeit von Datenbankobjekten durch legitime Benutzer.

• Integrity loss- Integritätsverlust tritt auf, wenn inakzeptable Vorgänge an der Datenbank versehentlich oder böswillig ausgeführt werden. Dies kann beim Erstellen, Einfügen, Aktualisieren oder Löschen von Daten geschehen. Dies führt zu beschädigten Daten, was zu falschen Entscheidungen führt.

• Confidentiality loss- Ein Vertraulichkeitsverlust entsteht durch unbefugte oder unbeabsichtigte Offenlegung vertraulicher Informationen. Dies kann zu illegalen Handlungen, Sicherheitsbedrohungen und Vertrauensverlust in der Öffentlichkeit führen.

Kontrollmaßnahmen

Die Kontrollmaßnahmen lassen sich grob in folgende Kategorien einteilen:

• Access Control- Die Zugriffskontrolle umfasst Sicherheitsmechanismen in einem Datenbankverwaltungssystem zum Schutz vor unbefugtem Zugriff. Ein Benutzer kann auf die Datenbank zugreifen, nachdem er den Anmeldevorgang nur über gültige Benutzerkonten abgeschlossen hat. Jedes Benutzerkonto ist passwortgeschützt.

• Flow Control- Verteilte Systeme umfassen einen großen Datenfluss von einem Standort zum anderen und auch innerhalb eines Standorts. Die Flusskontrolle verhindert, dass Daten so übertragen werden, dass nicht autorisierte Agenten darauf zugreifen können. Eine Flussrichtlinie listet die Kanäle auf, über die Informationen fließen können. Außerdem werden Sicherheitsklassen für Daten und Transaktionen definiert.

• Data Encryption- Datenverschlüsselung bezieht sich auf die Codierung von Daten, wenn sensible Daten über öffentliche Kanäle übertragen werden sollen. Selbst wenn ein nicht autorisierter Agent Zugriff auf die Daten erhält, kann er diese nicht verstehen, da sie in einem unverständlichen Format vorliegen.

Was ist Kryptographie?

Cryptography ist die Wissenschaft des Codierens von Informationen vor dem Senden über unzuverlässige Kommunikationspfade, so dass nur ein autorisierter Empfänger sie decodieren und verwenden kann.

Die codierte Nachricht wird aufgerufen cipher text und die ursprüngliche Nachricht wird aufgerufen plain text. Der Prozess der Konvertierung von Klartext in Chiffretext durch den Absender wird als Codierung oder bezeichnetencryption. Der Vorgang des Konvertierens von Chiffretext in Klartext durch den Empfänger wird als Decodieren oder bezeichnetdecryption.

Der gesamte Vorgang der Kommunikation mithilfe der Kryptografie kann anhand des folgenden Diagramms veranschaulicht werden:

Herkömmliche Verschlüsselungsmethoden

Bei der herkömmlichen Kryptographie erfolgt die Ver- und Entschlüsselung mit demselben geheimen Schlüssel. Hier verschlüsselt der Absender die Nachricht mit einem Verschlüsselungsalgorithmus unter Verwendung einer Kopie des geheimen Schlüssels. Die verschlüsselte Nachricht wird dann über öffentliche Kommunikationskanäle gesendet. Beim Empfang der verschlüsselten Nachricht entschlüsselt der Empfänger sie mit einem entsprechenden Entschlüsselungsalgorithmus unter Verwendung des gleichen geheimen Schlüssels.

Die Sicherheit in der konventionellen Kryptographie hängt von zwei Faktoren ab:

• Ein Soundalgorithmus, der allen bekannt ist.

• Ein zufällig erzeugter, vorzugsweise langer geheimer Schlüssel, der nur dem Sender und dem Empfänger bekannt ist.

Der bekannteste konventionelle Kryptographiealgorithmus ist Data Encryption Standard oder DES.

Der Vorteil dieser Methode ist ihre einfache Anwendbarkeit. Das größte Problem der herkömmlichen Kryptographie besteht jedoch darin, den geheimen Schlüssel zwischen den kommunizierenden Parteien zu teilen. Die Art und Weise, den Schlüssel zu senden, ist umständlich und sehr anfällig für Abhören.

Kryptographie mit öffentlichen Schlüsseln

Im Gegensatz zur herkömmlichen Kryptografie werden bei der Kryptografie mit öffentlichen Schlüsseln zwei verschiedene Schlüssel verwendet, die als öffentlicher Schlüssel und als privater Schlüssel bezeichnet werden. Jeder Benutzer generiert das Paar aus öffentlichem und privatem Schlüssel. Der Benutzer legt dann den öffentlichen Schlüssel an einem zugänglichen Ort ab. Wenn ein Absender eine Nachricht senden möchte, verschlüsselt er sie mit dem öffentlichen Schlüssel des Empfängers. Beim Empfang der verschlüsselten Nachricht entschlüsselt der Empfänger sie mit seinem privaten Schlüssel. Da der private Schlüssel nur dem Empfänger bekannt ist, kann keine andere Person, die die Nachricht empfängt, sie entschlüsseln.

Die beliebtesten Kryptografiealgorithmen mit öffentlichem Schlüssel sind RSA Algorithmus und Diffie– HellmanAlgorithmus. Diese Methode ist sehr sicher, um private Nachrichten zu senden. Das Problem ist jedoch, dass es viele Berechnungen erfordert und sich daher für lange Nachrichten als ineffizient erweist.

Die Lösung besteht darin, eine Kombination aus konventioneller Kryptographie und Kryptographie mit öffentlichem Schlüssel zu verwenden. Der geheime Schlüssel wird mithilfe der Kryptografie mit öffentlichen Schlüsseln verschlüsselt, bevor er zwischen den kommunizierenden Parteien geteilt wird. Dann wird die Nachricht unter Verwendung herkömmlicher Kryptographie mit Hilfe des gemeinsam genutzten geheimen Schlüssels gesendet.

Digitale Signaturen

Eine digitale Signatur (DS) ist eine Authentifizierungstechnik, die auf der Kryptografie mit öffentlichem Schlüssel basiert und in E-Commerce-Anwendungen verwendet wird. Es ordnet einem Individuum innerhalb des Körpers seiner Botschaft eine eindeutige Marke zu. Dies hilft anderen, gültige Absender von Nachrichten zu authentifizieren.

In der Regel variiert die digitale Signatur eines Benutzers von Nachricht zu Nachricht, um Sicherheit gegen Fälschungen zu bieten. Die Methode ist wie folgt -

• Der Absender nimmt eine Nachricht entgegen, berechnet den Nachrichtenauszug der Nachricht und signiert sie mit einem privaten Schlüssel.

• Der Absender hängt dann den signierten Digest zusammen mit der Klartextnachricht an.

• Die Nachricht wird über den Kommunikationskanal gesendet.

• Der Empfänger entfernt den angehängten signierten Digest und überprüft den Digest mit dem entsprechenden öffentlichen Schlüssel.

• Der Empfänger nimmt dann die Klartextnachricht und führt sie durch denselben Nachrichtenverdauungsalgorithmus.

• Wenn die Ergebnisse von Schritt 4 und Schritt 5 übereinstimmen, weiß der Empfänger, dass die Nachricht integer und authentisch ist.

Ein verteiltes System benötigt zusätzliche Sicherheitsmaßnahmen als ein zentrales System, da es viele Benutzer, diversifizierte Daten, mehrere Standorte und verteilte Kontrolle gibt. In diesem Kapitel werden die verschiedenen Facetten der verteilten Datenbanksicherheit untersucht.

In verteilten Kommunikationssystemen gibt es zwei Arten von Eindringlingen:

• Passive eavesdroppers - Sie überwachen die Nachrichten und erhalten private Informationen.

• Active attackers - Sie überwachen nicht nur die Nachrichten, sondern beschädigen auch Daten, indem sie neue Daten einfügen oder vorhandene Daten ändern.

Sicherheitsmaßnahmen umfassen Sicherheit in der Kommunikation, Sicherheit in Daten und Datenprüfung.

Kommunikationssicherheit

In einer verteilten Datenbank findet aufgrund des diversifizierten Standorts von Daten, Benutzern und Transaktionen viel Datenkommunikation statt. Daher ist eine sichere Kommunikation zwischen Benutzern und Datenbanken sowie zwischen den verschiedenen Datenbankumgebungen erforderlich.

Sicherheit in der Kommunikation umfasst Folgendes:

• Daten sollten während der Übertragung nicht beschädigt werden.

• Der Kommunikationskanal sollte sowohl vor passiven Lauschern als auch vor aktiven Angreifern geschützt sein.

• Um die oben genannten Anforderungen zu erfüllen, sollten genau definierte Sicherheitsalgorithmen und -protokolle angewendet werden.

Zwei beliebte, konsistente Technologien für eine durchgängige sichere Kommunikation sind:

• Secure Socket Layer Protocol oder Transport Layer Security Protocol.
• Virtuelle private Netzwerke (VPN).

Datensicherheit

In verteilten Systemen müssen unbedingt Maßnahmen zur Sicherung von Daten außerhalb der Kommunikation getroffen werden. Die Datensicherheitsmaßnahmen sind -

• Authentication and authorization- Dies sind die Maßnahmen zur Zugriffskontrolle, mit denen sichergestellt wird, dass nur authentische Benutzer die Datenbank verwenden können. Zur Bereitstellung der Authentifizierung werden digitale Zertifikate verwendet. Außerdem ist die Anmeldung durch die Kombination aus Benutzername und Passwort eingeschränkt.

• Data encryption - Die beiden Ansätze zur Datenverschlüsselung in verteilten Systemen sind:

  • Interner bis verteilter Datenbankansatz: Die Benutzeranwendungen verschlüsseln die Daten und speichern die verschlüsselten Daten in der Datenbank. Zur Verwendung der gespeicherten Daten rufen die Anwendungen die verschlüsselten Daten aus der Datenbank ab und entschlüsseln sie anschließend.

  • Externe zu verteilter Datenbank: Das verteilte Datenbanksystem verfügt über eigene Verschlüsselungsfunktionen. Die Benutzeranwendungen speichern Daten und rufen sie ab, ohne zu bemerken, dass die Daten in verschlüsselter Form in der Datenbank gespeichert sind.

• Validated input- Bei dieser Sicherheitsmaßnahme überprüft die Benutzeranwendung jede Eingabe, bevor sie zum Aktualisieren der Datenbank verwendet werden kann. Eine nicht validierte Eingabe kann eine Vielzahl von Exploits verursachen, z. B. Pufferüberlauf, Befehlsinjektion, Cross-Site-Scripting und Beschädigung von Daten.

Datenprüfung

Ein Datenbanksicherheitssystem muss Sicherheitsverletzungen erkennen und überwachen, um die Sicherheitsmaßnahmen zu ermitteln, die es ergreifen sollte. Es ist oft sehr schwierig, Sicherheitsverletzungen zum Zeitpunkt des Auftretens zu erkennen. Eine Methode zum Identifizieren von Sicherheitsverletzungen besteht darin, Überwachungsprotokolle zu untersuchen. Überwachungsprotokolle enthalten Informationen wie -

• Datum, Uhrzeit und Ort fehlgeschlagener Zugriffsversuche.
• Details zu erfolgreichen Zugriffsversuchen.
• Wichtige Änderungen im Datenbanksystem.
• Zugriff auf große Datenmengen, insbesondere aus Datenbanken an mehreren Standorten.

Alle oben genannten Informationen geben einen Einblick in die Aktivitäten in der Datenbank. Eine regelmäßige Analyse des Protokolls hilft dabei, unnatürliche Aktivitäten zusammen mit dem Ort und dem Zeitpunkt des Auftretens zu identifizieren. Dieses Protokoll wird idealerweise auf einem separaten Server gespeichert, sodass Angreifer nicht darauf zugreifen können.