Kategorie: SQL

Veröffentlicht am

Datenbank Modelle ACID und BASE im Vergleich

Datenbanksysteme

In der Welt der Datenbanktechnologien sind zwei zentrale Konzepte weit verbreitet: das ACID-Modell, das typischerweise mit relationalen (SQL) Datenbanken assoziiert wird. Das BASE-Modell wird oft mit NoSQL-Datenbanken in Verbindung gebracht. Diese Modelle definieren die grundlegenden Eigenschaften, die von den jeweiligen Datenbanksystemen erwartet werden.

ACID-Modell

ACID steht für Atomicity, Consistency, Isolation und Durability. Dieses Modell wird in relationalen Datenbankmanagementsystemen (RDBMS) eingesetzt, um die Zuverlässigkeit und Genauigkeit von Transaktionen zu gewährleisten.

  • Atomicity (Atomarität): Jede Transaktion wird als eine einzelne Einheit betrachtet, die entweder vollständig erfolgreich ist oder gar nicht ausgeführt wird.
  • Consistency (Konsistenz): Transaktionen führen eine Datenbank von einem konsistenten Zustand in einen anderen über, ohne die Datenintegrität zu verletzen.
  • Isolation (Isolierung): Gleichzeitig ausgeführte Transaktionen beeinflussen sich nicht gegenseitig.
  • Durability (Dauerhaftigkeit): Sobald eine Transaktion abgeschlossen ist, bleiben die Änderungen dauerhaft erhalten, auch im Falle eines Systemausfalls.

BASE-Modell

BASE steht für Basically Available, Soft State und Eventually Consistent. Dieses Modell wird in NoSQL-Datenbanksystemen verwendet, um Flexibilität, Skalierbarkeit und Verfügbarkeit in verteilten Systemen zu gewährleisten.

  • Basically Available (Grundsätzlich verfügbar): Das System garantiert die Verfügbarkeit von Daten, auch wenn einige Teile des Systems ausgefallen sind.
  • Soft State (Weicher Zustand): Der Zustand des Systems kann sich mit der Zeit ändern, auch ohne Benutzereingriffe.
  • Eventually Consistent (Schließlich konsistent): Das System stellt sicher, dass, wenn keine neuen Updates mehr erfolgen, alle Replikationen der Datenbank nach einiger Zeit konsistent sind.

Vergleichstabelle

Eigenschaft ACID-Modell BASE-Modell
Datenintegrität Hoch Variabel
Flexibilität Gering Hoch
Skalierbarkeit Vertikal Horizontal
Konsistenz Strenge Konsistenz Eventuelle Konsistenz
Transaktionsmanagement Strikt und zuverlässig Locker und anpassungsfähig
Einsatzgebiet Traditionelle Unternehmensanwendungen Verteilte, skalierende Anwendungen

Fazit

Das ACID-Modell bietet hohe Datenintegrität und Zuverlässigkeit, was es ideal für Anwendungen macht, die strenge Konsistenz und Transaktionssicherheit erfordern, wie z.B. Bankensysteme. Allerdings kann es aufgrund seiner strengen Regeln zu Einschränkungen in Bezug auf Flexibilität und Skalierbarkeit kommen.

Im Gegensatz dazu bietet das BASE-Modell eine hohe Flexibilität und Skalierbarkeit, was es ideal für verteilte Systeme und Anwendungen mit großem Datenvolumen und hohen Benutzerzahlen macht, wie soziale Netzwerke oder Echtzeit-Analysen. Die eventuelle Konsistenz kann jedoch zu Herausforderungen in Anwendungen führen, die eine sofortige Datenkonsistenz erfordern.

Letztendlich hängt die Wahl zwischen ACID- und BASE-Modellen von den spezifischen Anforderungen und dem Kontext der jeweiligen Anwendung ab. Beide Modelle haben ihre Berechtigung und bieten unterschiedliche Vorteile, die je nach Einsatzgebiet entscheidend sein können.

 

Veröffentlicht am

Normalisierung bei relationalen Datenbanken

Für die Nutzung und Wartung eines relationalen Datenbanksystems (DBS) sind sauber strukturierte Daten von Vorteil.

Denn bei der Nutzung können Schwächen, also Anomalien auftreten, die es zu verhindern gilt. Das wären zum Beispiel

  • Die Einfügeanomalie tritt auf, wenn es aufgrund von fehlenden Attributwerten nicht möglich ist, neue Daten in die Tabelle einzufügen.
  • Die Änderungsanomalie tritt auf, wenn Änderungen an einem Attributwert in einer Zeile zu Inkonsistenzen in anderen Zeilen führen.
  • Die Löschungsanomalie tritt auf, wenn das Löschen von Daten in einer Tabelle versehentlich auch andere, relevante Daten löscht oder wenn das Löschen von Daten zu einer fehlenden Information führt.

Um die oben genannten Anomalien zu verhindern, wird der Normalisierungsprozess eingesetzt.

Normalisierung der 1. Normalform

Eine Relation ist in der 1. Normalform, wenn jeder Wert in jeder Spalte des Tabellenentwurfs atomar ist, d.h. keine mehrwertigen Attribute enthält. Es dürfen also keine Spalten mit mehreren Werten in einer Zeile vorhanden sein.

Normalisierung der 2. Normalform

Eine Relation ist in der 2. Normalform, wenn sie bereits in der 1. Normalform ist und kein Teil der Primärschlüssel-Funktionsabhängigkeit von einer Teilmenge der Attribute abhängt. Das bedeutet, dass jede Nichtschlüssel-Spalte von der gesamten Primärschlüssel abhängt, nicht von einem Teil davon.

Normalisierung der 3. Normalform

Eine Relation ist in der 3. Normalform, wenn sie bereits in der 2. Normalform ist und keine transitive Abhängigkeiten existieren. Das bedeutet, dass eine Nichtschlüsselspalte nicht von einer anderen Nichtschlüsselspalte abhängen kann, sondern nur von der Primärschlüsselspalte.

Die Normalformen sind wichtig, um Datenredundanz und -inkonsistenzen zu vermeiden und die Datenkonsistenz und -integrität sicherzustellen.

Beispiel zur Normalisierung

Angenommen, wir haben eine Tabelle „Studenten“ mit den folgenden Spalten:

  • Matrikelnummer (Primärschlüssel)
  • Name
  • Geburtsdatum
  • Studienfach
  • Modul1-Name
  • Modul1-Note
  • Modul2-Name
  • Modul2-Note
  • Modul3-Name
  • Modul3-Note

Diese Tabelle ist nicht in der 1. Normalform, da die Spalten „Modul1-Name“, „Modul1-Note“, „Modul2-Name“, „Modul2-Note“, „Modul3-Name“ und „Modul3-Note“ mehrwertige Attribute enthalten. Wir können die Tabelle in zwei separate Tabellen aufteilen: eine für die Studenteninformationen und eine für die Modulinformationen.

  • Tabelle „Studenten“ (Primärschlüssel: Matrikelnummer)
    • Matrikelnummer (Primärschlüssel)
    • Name
    • Geburtsdatum
    • Studienfach
  • Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
    • Modul-ID (Primärschlüssel)
    • Matrikelnummer (Fremdschlüssel)
    • Modul-Name
    • Modul-Note

Jetzt befindet sich die Tabelle „Studenten“ in der 1. Normalform, da alle Spalten atomar sind. Die Tabelle „Module“ ist in der 2. Normalform, da alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID“ abhängig sind.

Die Tabelle „Module“ ist jedoch noch nicht in der 3. Normalform, da die Spalte „Modul-Name“ und „Modul-Note“ von der Teilmenge der Spalte „Modul-ID“ und „Matrikelnummer“ abhängen, anstatt von der gesamten Primärschlüsselspalte „Modul-ID“ abhängig zu sein. Wir können die Tabelle erneut aufteilen:

  • Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
    • Modul-ID (Primärschlüssel)
    • Modul-Name
  • Tabelle „Noten“ (Primärschlüssel: Modul-ID, Matrikelnummer)
    • Modul-ID (Primärschlüssel, Fremdschlüssel)
    • Matrikelnummer (Primärschlüssel, Fremdschlüssel)
    • Modul-Note

Jetzt hängen alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID, Matrikelnummer“ ab, und die Tabelle „Module“ und „Noten“ befinden sich in der 3. Normalform.

 

 

Veröffentlicht am

Die Kardinalität bei dem ER Modell mit SQL

Bei der Entwicklung mit dem ER- Modell ist nicht ersichtlich, in welcher Beziehung die Entitäten stehen. Die (min, max)-Notation wird genutzt, um die Beziehungen zwischen Entitäten zu definieren. Die Notation gibt an, wie viele Instanzen einer Entität in Beziehung zu einer bestimmten Anzahl von Instanzen einer anderen Entität stehen können.

  • Die „min“ – Zahl gibt an, wie viele minimale Instanzen einer Entität in Beziehung zu einer anderen Entität stehen müssen.
  • Die „max“ – Zahl gibt an, wie viele maximale Instanzen einer Entität in Beziehung zu einer anderen Entität stehen können.

Die 1:1 Kardinalität bedeutet beispielsweise, dass es nur eine Instanz der Entität auf der einen Seite und eine Instanz der Entität auf der anderen Seite geben kann.

Die 0:1 Kardinalität bedeutet hingegen, dass es eine oder keine Instanz einer Entität auf der einen Seite geben kann, aber maximal eine Instanz auf der anderen Seite.

Die 1:n Kardinalität beschreibt eine Beziehung zwischen Entitäten, bei der eine Instanz einer Entität mit vielen Instanzen einer anderen Entität in Beziehung steht. Dies wird oft durch die Verwendung von Fremdschlüsseln realisiert, die auf den Primärschlüssel der anderen Entität verweisen.

Die n:m Kardinalität beschreibt eine Beziehung zwischen Entitäten, bei der viele Instanzen einer Entität mit vielen Instanzen einer anderen Entität in Beziehung stehen. Die Beziehung wird über eine Zuordnungstabelle (Zwischentabelle) realisiert, die eine Verbindung zwischen den beiden Entitäten herstellt.

Die Kardinalität der (min, max) – Notation ist ein wichtiger Aspekt bei der Datenmodellierung, da sie die Beziehungen zwischen den Entitäten genau beschreibt. Sie hilft bei der Identifizierung von Datenintegritätsproblemen, indem sie sicherstellt, dass die Daten in einer bestimmten Beziehung konsistent bleiben.

Es ist wichtig zu beachten, dass die (min, max) – Notation nicht immer ausreichend ist, um komplexe Beziehungen zwischen Entitäten zu beschreiben. In solchen Fällen können zusätzliche Regeln und Einschränkungen erforderlich sein, um sicherzustellen, dass die Daten konsistent und korrekt sind. Sie hilft bei der Identifizierung von Integritätsproblemen von Daten und stellt sicher, dass die Daten in einer bestimmten Beziehung konsistent bleiben.

 

Veröffentlicht am

Übersicht der Elemente beim ER Modell

Das ER-Modell (Entity-Relationship-Modell) ist eine Methode zur Modellierung von Datenbanken. Es besteht aus drei Grundkonzepten: Entitäten (Objekte), Beziehungen (Verbindungen zwischen Objekten) und Attributen (Eigenschaften von Objekten).

Das ER-Modell hilft bei der klaren und einheitlichen Darstellung von Datenbankstrukturen und unterstützt bei der Planung, Umsetzung und Wartung von Datenbanken.

Entität Eine Entität ist ein Ding oder Objekt der realen Welt.
Attribut Attribute sind Eigenschaften von Entitäten und besitzen einen Wert.
Primärschlüssel Attribute sind durch die Unterstreichung  als Primärschlüssel gekennzeichnet.
Beziehung Beziehungen zeigen die Kommunikation und Abhängigkeiten von Entitäten auf.
Ist-ein oder Is-a Die Ist-ein oder Is-a Beziehung entspricht einer Generalisierung oder Verallgemeinerung. Zum Beispiel ist ein Fahrzeug ein PKW oder ein Motorrad.
Teil-von oder Part-of Die Teil-von oder Part-of Beziehung entspricht einer Aggregation. Zum Beispiel besteht ein Smartphone aus einem Akku, einem Display …

Besonderheit bei der Ist-ein oder Is-a Beziehungen

Disjunkt

Wenn sich zwei Entitätsmengen in der Datenbank nicht überlappen, wird dies „disjunkt“bezeichnet. Das heißt, es gibt keine Entitäten, die gleichzeitig in beiden Entitätsmengen vorkommen.

Nicht Disjunkt

„Nicht disjunkt“ hingegen bedeutet, dass sich zwei Entitätsmengen in der Datenbank überlappen können. Das bedeutet, dass es Entitäten geben kann, die in beiden Entitätsmengen vorkommen können.

Total

Eine „totale“ Beteiligung bedeutet, dass jede Entität in einer Entitätsmenge an einer Beziehung teilnehmen muss. Mit anderen Worten, eine Entität in der Entitätsmenge kann nicht existieren, ohne an der Beziehung teilzunehmen. Es gibt also keine weiteren Teilmengen.

Partiell

Eine „partielle“ Beteiligung bedeutet hingegen, dass nicht alle Entitäten in einer Entitätsmenge an einer Beziehung teilnehmen müssen. Mit anderen Worten, eine Entität in der Entitätsmenge kann existieren, ohne an der Beziehung teilzunehmen. Es gibt hier weitere Teilmengen.

 

Hier ein Beispiel: Ein Fahrzeug ist ein PKW oder ein LKW oder ein Motorrad. Die Beziehung ist damit disjunkt und partiell.

 

Veröffentlicht am

Relationale Datenbanken entwerfen

Der Entwurf relationaler Datenbanken spielt für Datenbankentwickler eine wichtige Rolle. Dabei wird das 3-Ebenen Modell eingesetzt. Das besteht aus drei Ebenen. Dies sind die externe-, die konzeptionelle- und die interne Ebene. Um die Entwicklung zu vereinfachen, wird häufig das Entity-Relationship Modell eingesetzt. Das wird auch ER-Modell oder ERM genannt.

Der Entwicklungsprozess

Der gesamte Entwicklungsprozess besteht aus mehreren Phasen.

AnforderungsanalyseDatenbank EntwicklungsprozessAnforderungsanalyse

Die Anforderungsanalyse beginnt damit, dass alle Anforderungen der Akteure gesammelt und ausgewertet werden. Dabei können die Akteure in Gruppen geordnet werden. Dabei stellen sich die W-Fragen:

  • Welche Daten werden verarbeitet?
  • Wie werden die Daten verarbeitet?
  • Was ist in der Datenbank abzulegen?
  • Welche Daten werden Wem zur Verfügung gestellt?
  • Wo werden die Daten verarbeitet und wo gespeichert?
  • Wann finden welche Prozesse statt?
  • Wer führt welche Tätigkeiten durch?
  • …

Konzeptioneller Entwurf

Beim konzeptionellen Entwurf gibt es verschiedene Vorgehensmodelle. Oft wird die Top-Down- oder die Bottom-Up Methode eingesetzt. Hier werden die Daten, die Prozesse, die Abhängigkeiten in Beziehung gebracht. Jetzt ist der richtige Moment zu entscheiden, welches Datenbank System (DBS) eingesetzt wird, außer die Anforderungen haben dies bereits festgelegt.

Logischer Entwurf

Beim logischen Entwurf findet die Umsetzung des konzeptionellen Schemas statt. Die häufigsten Abfragen sind auf Grund der Anforderungen bekannt und bereits beschrieben. Das Endergebnis ist eine normalisierte Tabellenstruktur, die keine Fehler und Redundanzen enthält.

Implementierung

Jetzt erfolgt die konkrete Umsetzung auf dem Datenbank System. Dabei wird auf ein gutes Laufzeitverhalten und auf Effizienz geachtet. Wichtig ist hier, dass nach den Regeln der KVP (Kontinuierlicher Verbesserung Prozess) die Datenbank optimiert wird. Es werden die Sichten, Relationen, Indizes und die Berechtigungen eingerichtet.

Test / Qualitätssicherung

Bei der Qualitätssicherung wird geprüft, ob die Anforderungen erfüllt sind. Zudem werden die während der Anforderungsanalyse festgestellten Kriterien geprüft. Optimal ist hier zusätzliches automatisiertes Testsystem zu nutzen, dass den ganzen Lebenszyklus des DBS genutzt wird. Das vermeidet wiederkehrende Fehler und optimiert die Qualitätssicherung.

Übergabe und Nutzung

Nach dem Abschluss der Qualitätssicherung findet die Übergabe des Systems statt. Dabei ist zu beachten, dass dies wie alle vorher beschriebenen Prozesse in schriftlicher Form dokumentiert sein soll. Das Übergabedokument wird nach erfolgreicher Abnahme durch den Auftraggeber unterzeichnet und damit ist der Leiter des Projekts entlastet.