Datenmodellierung und Datenbanksysteme

Ein Primärschlüssel ist ein Attribut (oder eine Kombination aus Attributen), das jeden Datensatz eindeutig identifiziert. Es darf keine doppelten oder Null-Werte enthalten.

1. Entität: Ein reales „Ding“ (z. B. ein Student).

2. Objekt: In der Datenbank oft gleichbedeutend mit Entität.

3. Datensatz (Tupel): Technische Darstellung einer Entität in der Tabelle.

4. Relation: Theoretischer Begriff – Menge von Tupeln mit gleichem Schema.

5. Tabelle: Praktische Umsetzung der Relation.

6. Entitätsmenge: Gesamtheit gleichartiger Entitäten – entspricht einer Tabelle.

1:1 (Martin / UML / Chen)

Einem Kunden ist genau ein Artikel zugeordnet, jeder Artikel gehört zu genau einem Kunden.

1:C (Martin /UML)

Jedem Kunde ist kein oder genau ein Artikel zugeordnet, jeder Artikel gehört genau zu einem Kunden.

C:C (Martin /UML)

Jedem Kunde ist kein oder genau ein Artikel zugeordnet, jeder Artikel ist keinem oder genau einem Kunden zugeordnet.

1:N (Martin/UML/Chen)

Einem Kunden gehören ein oder mehrere Artikel und jeder Artikel gehört zu genau einem Kunden.

C:CN (Martin/UML)

Einem Kunden gehören beliebig viele (insbesondere auch null!) Artikel und jeder Artikel gehört zu keinem oder genau zu einem Kunden.

1:CN (Martin/UML)

Einem Kunden gehören beliebig viele (insbesondere auch null!) Artikel und jeder Artikel gehört genau zu einem Kunden.

C:N (Martin/UML)

Einem Kunden gehört mindestens ein Artikel und jeder Artikel gehört zu keinem oder genau zu einem Kunden.

N:M (Martin/UML/Chen)

Einem Kunden gehört mindestens ein Artikel und jeder Artikel gehört zu mindestens einem Kunden.

N:CM (Martin/UML)

Einem Kunden gehören beliebig viele (insbesondere auch null!) Artikel und jeder Artikel gehört zu mindestens einem Kunden.

CN:CM (Martin/UML)

Einem Kunden gehören beliebig viele (insbesondere auch null!) Artikel und jeder Artikel gehört zu beliebig vielen Kunden.

Ganz allgemein erfolgt das Eintragen von Datensätzen in relationale Datenbanken nach folgendem Schema:

1. Auswahl der gesuchten Relationen (Tabellen), in denen die gewünschte Information eingetragen werden soll;

2. Einfügen des Objektes (Datensatz) mit den entsprechenden Attributwerten; dabei

3. darauf achten, dass die Primärschlüssel eindeutig gesetzt werden und keine Fremdschlüssel ohne dazugehörigen Primärschlüssel entstehen.

1. Bestimmen der Relationen (Tabellen) in der Datenbank, in denen die gesuchte Information abgelegt ist. Das schließt ebenso alle Tabellen ein, die ggf. die gesuchte Information nicht direkt enthalten, jedoch zur Identifikation der konkreten Datensätze benötigt werden. Beziehungstabellen sind dafür ein typisches Beispiel.

2. Als nächstes müssen die konkreten Attribute in den in Schritt 1 gewählten Relationen identifiziert werden, die als Ergebnis zurückgegeben werden sollen.

3. Häufig sollen nicht alle Datensätze mit den gesuchten Attributen ausgegeben werden, sondern nur gezielt die Datensätze, deren Attributwerte vorher festgelegte Kriterien erfüllen. Daher muss in Schritt 3 die in Schritt 2 identifizierte Wertemenge unter Umständen eingeschränkt werden.

4. Je nach Bedarf wird die in Schritt 3 ermittelte Ergebnismenge nach festgelegten Kriterien sortiert.

1. Auswählen der Relationen (Tabellen) in der Datenbank, in denen die zu löschenden Objekte abgelegt sind. Das schließt ebenso alle Tabellen ein, die ggf. die gesuchte Information nicht direkt enthalten, jedoch zur Identifikation der konkreten Datensätze benötigt werden. Beziehungstabellen sind dafür ein typisches Beispiel.

2. Identifikation der zu löschenden Datensätze anhand der in der Löschanfrage formulierten Kriterien.

3. Sicherstellen, dass es nach dem Löschen der Objekte aus der Datenbank keine Fremdschlüssel gibt, die nicht aufgelöst werden können (referentielle Integrität).

Das sind unerwünschte Effekte, die bei der gleichzeitigen Ausführung mehrerer Transaktionen auf denselben Datensätzen auftreten können.

Die Umwandlung erfolgt unter Umständen verlustbehaftet, sprich es können Informationen beim Einfügen verloren gehen.

Alternativ:

Will man das vermeiden, muss die Typprüfung in der Geschäftsanwendung erfolgen, sprich bevor die Werte dem DBMS übergeben werden.

In Datenbankmanagementsystemen, insbesondere bei relationalen Datenbanken, bezeichnet Datenintegrität die Korrektheit, Konsistenz und Zuverlässigkeit der gespeicherten Daten. Sie stellt sicher, dass die Daten den definierten Regeln und Erwartungen entsprechen und nicht durch fehlerhafte Eingaben, Systemfehler oder unerlaubte Änderungen verfälscht werden.

Es gibt mehrere Arten von Datenintegrität:

1. Entity-Integrität

   • Jede Tabelle hat einen eindeutigen Primärschlüssel.

   • Kein Datensatz darf einen NULL-Wert im Primärschlüssel haben.

2. Referentielle Integrität

   • Beziehungen zwischen Tabellen bleiben konsistent.

   • Ein Fremdschlüssel muss entweder auf einen gültigen Primärschlüssel verweisen oder NULL sein.

3. Domänenintegrität

   • Werte in einer Spalte müssen einem bestimmten Datentyp und Format entsprechen.

   • Beispiel: Eine Spalte für das Geburtsdatum darf keine Texte enthalten.

4. Benutzerdefinierte Integrität

   • Regeln, die durch Geschäftslogik definiert sind, z. B. „Rabatt darf nicht über 50 % liegen“.

Diese Integritätsregeln werden oft durch Constraints (z. B. PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL) in SQL umgesetzt.

Konzeptionelles Datenmodell

1. Entitäten identifizieren

2. Beziehungen festlegen

3. Primärschlüssel festlegen

____________________________________________________________________________

Physikalisches Datenmodell

1. Umwandlung in physikalisches Datenmodell

2. Attribute festlegen und normalisieren

3. Konsistenzbedingung festlegen

4. Transaktionen formulieren

Das konzeptionelle Datenmodell beschreibt die möglichen Beziehungen zwischen den Entitäten. Dabei wird noch nicht berücksichtigt, wie diese Beziehungen später zwischen den Tabellen effektiv umgesetzt werden und aus welchen Attributen die Tabellen bestehen.

Fachliches Datenmodell

Das physische Datenmodell beschreibt die Umsetzung des konzeptionellen Datenmodells auf Datenbankebene. Aus den Entitäten werden Tabellen mit Attributen, und die Beziehungen werden mit Hilfe von Primär- und Fremdschlüsseln definiert.

Umsetzung auf dem DB-Server

(In einer relationalen Datenbank können nicht alle Beziehungen direkt abgebildet werden, daher werden Zwischentabellen benötigt.)

Eine relationale Datenbank speichert Daten in Tabellen (Relationen), wobei jede Zeile einen Datensatz (Entität) und jede Spalte ein Attribut darstellt. Beziehungen zwischen Tabellen werden durch Schlüssel (Primär- und Fremdschlüssel) abgebildet.

Ein Fremdschlüssel ist ein Attribut in einer Tabelle, das auf den Primärschlüssel einer anderen Tabelle verweist und so Beziehungen zwischen Tabellen herstellt.

Referenzielle Integrität bedeutet, das jeder Fremdschlüsselwert in einer Tabelle auf einen existierenden Primärschlüsselwert in der referenzierten Tabelle verweist.

SQL (Structured Query Language) ist eine standardisierte Sprache zur Verwaltung und Abfrage relationaler Datenbanken. Sie umfasst Befehle zur Datenmanipulation (DML), Definition (DDL), Kontrolle (DCL) und Transaktionssteuerung (TCL).

Können alle ER-Modelle dastellen

• 1:1 Ein Datensatz in Tabelle A ist genau mit einem in Tabelle B verbunden.

• 1:N Ein Datensatz in Tabelle A ist mit mehreren in Tabelle B verbunden.

• N:M Mehrere Datensätze in Tabelle A sind mit mehreren in Tabelle B verbunden

___________________________________________________________________

Kann Chen Notation nicht darstellen

• 1:C Jeden Kunden ist kein oder genau 1 Artikel zugeordnet, jeder Artikel gehört genau zu 1 Kunden.

• C:C Jeden Kunden ist kein oder genau 1 Artikel zugeordnet, jeder Artikel ist kein oder genau 1 Kunden zugeordnet.

• 1:CN Einem Kunden gehören beliebig viele Artikel und jeder Artikel gehört genau zu einem Kunden

• C:CN Einem Kunden gehören beliebig viele Artikel und jeder Artikel gehört zu keinen oder genau einem Kunden.

• N:CM Einem Kunden gehören beliebig viele Artikel und jeder Artikel gehört mindestens einem Kunden

• CN:CM Einem Kunden gehören beliebig viele Artikel und jeder Artikel gehört zu beliebig vielen Kunden.

Eine Transaktion ist eine Folge von Datenbankoperationen, die als eine Einheit ausgeführt werden. Sie wird entweder vollständig durchgeführt oder gar nicht (alles-oder-nichts-Prinzip). Sie erfüllen die ACID-Eigenschaften: Atomatität, Konsistenz, Isolation, Dauerhaftigkeit

• Atomarität: Die Transaktion wird ganz oder gar nicht ausgeführt.

• Consistency (Konsistenz): Die Datenbank bleibt vor und nach der Transaktion in einem konsistenten Zustand.

• Isolation: Gleichzeitige Transaktionen beeinflussen sich nicht gegenseitig.

• Dauerhaftigkeit (Durability): Nach Abschluss der Transaktion bleiben die Änderungen dauerhaft gespeichert, auch bei Systemabsturz.

Isolationsebenen legen fest, wie stark Transaktionen voneinander abgeschirmt werden.

Typische Levels sind:

• Read Uncommitted (niedrigste Isolation, „Dirty Reads“ möglich)

• Read Committed (nur bestätigte Daten werden gelesen)

• Repeatable Read (wiederholte Leseoperationen liefern gleiche Ergebnisse)

• Serializable (höchste Isolation, vollständige Abschirmung)

• Lost Update: Zwei Transaktionen überschreiben sich gegenseitig.

• Dirty Read: Eine Transaktion liest nicht bestätigte Änderungen einer anderen.

• Non-repeatable Read: Ein Wert ändert sich zwischen zwei Lesevorgängen innerhalb einer Transaktion.

• Phantom Read: Neue Datensätze erscheinen oder verschwinden bei wiederholten Abfragen.

Mehrere SQL-Befehle werden zwischen START TRANSACTION und COMMIT/ROLLBACK ausgeführt, um sicherzustellen, dass sie als Einheit behandelt werden.

Sie sichern die Datenintegrität und verhindern Inkonsistenzen, besonders bei gleichzeitigen Zugriffen mehrerer Nutzer auf die Datenbank.

Im Autocommit-Modus wird jede einzelne SQL-Anweisung automatisch als eigene Transaktion behandelt und sofort bestätigt.

Ein ER-Modell ist ein konzeptionelles Datenmodell, das die Struktur von Daten durch Entitäten (Objekte), deren Attribute (Eigenschaften) und Beziehungen zwischen den Entitäten beschreibt.

Eine Entität ist ein eindeutig identifizierbares Objekt oder Konzept der realen Welt, das in der Datenbank gespeichert werden soll (z. B. Kunde, Artikel).

Eine Entitätsmenge ist die Gesamtheit aller Entitäten des gleichen Typs (z. B. alle Kunden).

Ein Attribut ist eine Eigenschaft oder ein Merkmal einer Entität (z. B. Name, Geburtsdatum eines Kunden).

Ein Schlüsselattribut (Primärschlüssel) ist ein Attribut, das eine Entität eindeutig identifiziert (z. B. Kundennummer).

Eine Beziehung beschreibt, wie zwei oder mehr Entitäten miteinander in Verbindung stehen (z. B. „Kunde bestellt Artikel“).

Die Kardinalität gibt an, wie viele Entitäten einer Entitätsmenge mit wie vielen Entitäten einer anderen Entitätsmenge in Beziehung stehen können (z. B. 1:1, 1:N, N:M).

Ein Fremdschlüssel ist ein Attribut, das auf den Primärschlüssel einer anderen Entität verweist und so Beziehungen zwischen Tabellen herstellt.

• Chen-Notation: Entitäten als Rechtecke, Attribute als Ovale (Primärschlüssel unterstrichen), Beziehungen als Rauten. (1:1 /1:N/ N:M) 0 oder 1 bei 1 / Kann keine C Beziehungen darstellen

• Krähenfußnotation (Martin-Notation): Entitäten als Rechtecke (Primärschlüssel oberhalb der Tabelle und unterstrichen), Beziehungen als Linien mit „Krähenfüßen“ für die Kardinalität. Null, eins oder beliebig viele können dargestellt werden. 0, I (II) oder Krähenfuß

• UML-Klassendiagramm (Struktur-Diagramm): Entitäten als Klassen, Attribute als Eigenschaften, Beziehungen als Linien zwischen Klassen, Primärschlüssel in einer geschweiften Klammmer am Anfang der Tabelle / 1= genau 1 Stern=viele Beziehungen 0..1= 0 oder eine Beziehung 1..Stern= Eine oder mehrere Beziehungen

Eine schwache Entität ist eine Entität, die nur durch die Beziehung zu einer anderen Entität eindeutig identifiziert werden kann und keinen eigenen Primärschlüssel besitzt.

Ein Attribut einer Beziehung beschreibt eine Eigenschaft, die speziell für die Beziehung zwischen Entitäten gilt (z. B. Bestelldatum bei „Kunde bestellt Artikel“).

Ein mehrwertiges Attribut kann mehrere Werte für eine Entität annehmen (z. B. Telefonnummern eines Kunden).

Ein zusammengesetztes Attribut besteht aus mehreren Teilattributen (z. B. Adresse = Straße, PLZ, Ort).

Ein ER-Diagramm ist die grafische Darstellung eines ER-Modells mit allen Entitäten, Attributen und Beziehungen.

Das ER-Modell dient als Grundlage für die Erstellung eines Datenbankschemas und hilft, die Anforderungen an die Datenbank strukturiert zu erfassen und zu visualisieren.

Eine Normalform ist ein Kriterium, das die Struktur einer Datenbanktabelle beschreibt. Sie gibt an, wie gut Redundanzen und Anomalien vermieden werden. Ziel ist es, die Datenbankstruktur zu optimieren und Inkonsistenzen zu verhindern. Wichtig sind die 1.,2. Und 3. Normalform

Durch Normalisierung werden Redundanzen (mehrfache Speicherung gleicher Informationen) und Anomalien (Fehler beim Einfügen, Ändern oder Löschen von Daten) vermieden. Die Datenbank bleibt konsistent und effizient verwaltbar.

Redundanz bedeutet, dass Informationen mehrfach gespeichert werden. Das erhöht das Risiko von Inkonsistenzen und sollte durch Normalisierung minimiert werden.

• Alle Attribute enthalten nur atomare (unteilbare) Werte, keine Listen oder zusammengesetzten Werte. Zu jedem Attribut ist ein Wert gespeichert.

• Jeder Datensatz ist eindeutig identifizierbar (Primärschlüssel).

• Beispiel: Eine Tabelle, in der in einer Zelle mehrere Artikel stehen, ist nicht in 1NF.

• Die Tabelle ist in 1NF.

• Jedes Nichtschlüsselattribut ist vom gesamten (ggf. zusammengesetzten) Primärschlüssel abhängig, nicht nur von einem Teil davon.

• Gilt nur für Tabellen mit zusammengesetzten Schlüsseln.

• Beispiel: Wenn der Name eines Kunden nur von der Kundennummer (Teil des Schlüssels) abhängt, muss diese Information in eine eigene Tabelle ausgelagert werden.

• Die Tabelle ist in 1NF oder 2NF erfüllt.

• Jedes Nichtschlüsselattribut ist immer direkt vom Schlüsselattribut abhängig.

• Alle Attribute müssen atomare Werte enthalten. Zusammengesetzte Werte sind nicht erlaubt. Zu jedem Attribut muss genau ein Wert gespeichert werden. Jeder einzelne Datensatz ist eindeutig über einen Primäschlüssel identifizierbar. (1NF)

• Es gibt keine funktionalen Abhänigkeiten zwischen Attributen, die nicht Primärschlüssel sind

• Beispiel: Wenn in einer Tabelle sowohl die Kundennummer als auch der Kundenname und die Stadt stehen, und die Stadt nur vom Kundennamen abhängt, muss die Stadt in eine eigene Tabelle ausgelagert werden.

Eine transitive Abhängigkeit liegt vor, wenn ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängt, das wiederum vom Primärschlüssel abhängt.

• Eine Verschärfung der 3NF.

• Jede Determinante ist ein Kandidatenschlüssel.

• Wird angewendet, wenn trotz 3NF noch funktionale Abhängigkeiten bestehen, die nicht durch einen Schlüssel abgedeckt sind.

• Schrittweise Analyse der Tabellenstruktur.

• Zerlegung der Tabellen, um die Bedingungen der jeweiligen Normalform zu erfüllen.

• Ziel: Möglichst geringe Redundanz und hohe Datenintegrität.

• Vermeidung von Redundanzen und Anomalien.

• Erhöhung der Datenkonsistenz.

• Bessere Wartbarkeit und Erweiterbarkeit der Datenbank.

• Zu starke Normalisierung kann zu vielen Tabellen und komplexen Abfragen führen.

• In der Praxis wird oft ein Kompromiss zwischen Redundanzfreiheit und Performance gewählt.

NoSQL steht für „Not only SQL“. Es bezeichnet Datenbanksysteme, die nicht (nur) auf dem relationalen Modell und der Abfragesprache SQL basieren. Der Begriff ist nicht standardisiert, sondern wurde von der Community geprägt.

NoSQL-Systeme wurden entwickelt, um die Anforderungen moderner, schnell wachsender Webanwendungen zu erfüllen: hohe Verfügbarkeit, einfache horizontale Skalierbarkeit und die Verarbeitung großer Datenmengen.

• Nicht-relationales Datenmodell (z. B. Key-Value, Wide Column, Document, Graph)

• Schemafreiheit oder schwache Schemarestriktionen

• Verteilte und horizontale Skalierbarkeit (Scale-out)

• Einfache Datenreplikation

• Oft Open Source

• Häufig ein anderes Konsistenzmodell (BASE statt ACID)

• Hohe Skalierbarkeit und Verfügbarkeit

• Flexibles Schema, einfache Anpassung an neue Anforderungen

• Geeignet für große, verteilte Datenmengen und Big Data-Anwendungen

• Schwächere Konsistenzgarantien (eventual consistency)

• Oft keine Unterstützung für komplexe Abfragen oder Transaktionen wie bei relationalen Datenbanken

• Verantwortung für Datenintegrität und Schemadefinition liegt oft bei der Anwendungslogik

• Anwendungen mit schnell wachsenden Datenmengen (z. B. soziale Netzwerke, IoT)

• Webanwendungen mit vielen gleichzeitigen Nutzern

• Szenarien, in denen Flexibilität und Skalierbarkeit wichtiger sind als strikte Konsistenz

NoSQL-Datenbanken verzichten auf das starre relationale Modell und ermöglichen flexiblere Datenstrukturen, verzichten aber oft auf SQL als Abfragesprache und auf strikte Konsistenzmodelle.

Normalformen sind Regeln zur Strukturierung von Tabellen, um Redundanzen und Anomalien zu vermeiden. Je höher die Normalform, desto weniger Redundanz und bessere Datenintegrität.

• 1. Normalform: Alle Attribute sind atomar (unzerlegbar).

• 2. Normalform: Alle Nichtschlüsselattribute sind voll funktional abhängig vom gesamten Primärschlüssel.

• 3. Normalform: Keine indirekten Abhängigkeiten zwischen Nichtschlüsselattributen.

SQL (Structured Query Language) ist die Standardsprache für relationale Datenbanken. Hauptbestandteile:

• DML (Data Manipulation Language): SELECT, INSERT, UPDATE, DELETE

• DDL (Data Definition Language): CREATE, ALTER, DROP

• DCL (Data Control Language): GRANT, REVOKE

• TCL (Transaction Control Language): COMMIT, ROLLBACK

Eine Transaktion ist eine Folge von Datenbankoperationen, die als Einheit ausgeführt werden. ACID steht für:

• Atomarität

• Consistenz

• Isoliertheit

• Dauerhaftigkeit (Durability)

NoSQL steht für „Not only SQL“ und bezeichnet Datenbanksysteme, die nicht (nur) auf dem relationalen Modell basieren. Sie bieten oft mehr Flexibilität, Skalierbarkeit und verschiedene Datenmodelle (Key-Value, Dokument, Spalten, Graph)

Ein JOIN verbindet Datensätze aus zwei oder mehr Tabellen basierend auf einer logischen Beziehung zwischen ihnen (z.B. INNER JOIN, LEFT JOIN, RIGHT JOIN, NATURAL JOIN)

Eine View ist eine virtuelle Tabelle, die auf dem Ergebnis einer SELECT-Abfrage basiert. Sie speichert keine eigenen Daten, sondern stellt eine gespeicherte Abfrage dar.

Ein natürlicher Schlüssel ist ein Attribut, das bereits in der realen Welt eindeutig ist (z.B. ISBN). Ein künstlicher Schlüssel (Surrogat-Schlüssel) wird nur zur eindeutigen Identifikation in der Datenbank eingeführt (z.B. laufende Nummer).

Rekursive Beziehungen in physikalischen Datenbank Modellen sind Beziehungen, bei denen eine Entität auf sich selbst verweist. Dies wird häufig durch einen Fremdschlüssel implementiert, der auf die Primärschlüsselsäule derselben Tabelle zeigt. Ein Beispiel könnte eine Artikel Tabelle sein, die eine Spalte hat, die auf die ID eines verwandten Artikels verweist, was eine rekursive Beziehung schafft.

Nutzen von rekursiven Beziehungen:

Organisation von Hierarchien: Sie eignen sich hervorragend zur Darstellung von Hierarchien in Daten. Ein klassisches Beispiel ist eine Unternehmensstruktur, in der jede Abteilung wiederum anderen Abteilungen untergeordnet sein kann.

Verwaltung von Faden: Sie ermöglichen es, Farbe oder Sequenzen innerhalb der Daten zu verfolgen, was besonders in Lagerhaltung oder bei produktionskategorien nützlich ist.

Diese Art der Modellierung hilft, komplexe Datenstrukturen übersichtlich und effizient zu verwalten.

Alle Objekte zu allen Klassen in der Vererbungshierarchie werden in genau einer Tabelle gespeichert.

Vorteil:

• Sehr schnell lesender und schreibender Zugriff auf Daten, da nur eine Tabelle gelesen werden muss.

• Für das Lesen und Schreiben auf der Datenbank reicht jeweils genau ein SQL Statement aus

• Effizienter Zugriff auf Beziehungen zwischen Klassen der Vererbungshierarchie

Nachteil:

• Je komplexer die Vererbungshierarchie ist, desto größer wird eine einzelne Tabelle. Das führt bei großen Datenmengen ggf. zu deutlichen Performanceverlusten.

• In komplexen Vererbungshierarchie wird die Tabelle sehr viele Null Elemente enthalten. Der reservierte Speicherplatz wird damit nicht effizient genutzt.

In der Joined Subclass Tabletin Strategie wird jede Klasse der Vererbungshierarchie in einer eigenen Tabelle gespeichert. Das geht auch für abstrakte Klassen, also Klassen, die selbst keine Instanzen haben dürfen, sondern nur für deren Unterklassen. Jede Unterklasse enthält einen Fremdschlüssel zu den Datensätzen der Attribute ihrer Oberklasse. Um alle Attribute einer Klasse aus der Datenbank zu lesen bzw zu schreiben, müssen daher die Daten aus allen Tabellen aller Oberklassen ebenfalls ausgelesen bzw geschrieben werden.

Vorteil:

• Strategie mit der geringsten Redundanz in den gespeicherten Daten

• Einfaches hinzufügen von weiteren Unterklassen sehr leicht möglich. Bereits bestehende Tabellen müssen dabei nicht in ihrer Struktur verändert werden

• Die Daten aus Oberklassen können mit einfachen Datenbankmitteln (Fremdschlüssel und join) geladen werden

Nachteil:

• Verglichen mit den anderen Strategien die langsamste Abbildung von Vererbung.

• Und Daten zu lesen und zu schreiben, müssen immer mehrere Tabellen angefragt werden. Daher besteht die Anfrage aus mehreren SQL Statements

• Ausnahme: Zugriffe auf die oberste Oberklasse erfolgt sehr schnell.

Hier werden für jede Klasse Vererbungshierarchie eine eigene Tabelle erstellen. Dies gilt nur für konkrete, also nicht abstrakte, Klassen. Die eigene Tabelle pro Klasse enthält jedoch im Unterschied zur Strategie Join Subclass Table alle Attribute, die zu konkreten Objekten dieser Klasse gespeichert werden um einen Datensatz einer bestimmten Klasse zu laden, reicht ein Zugriff auf die korrespondierende Tabelle aus.

Vorteil:

• Falls der Klassenname bekannt ist, sind sehr effiziente Zugriffe auf die Datenbank möglich, da alle benötigten Informationen in einer Tabelle gespeichert sind.

• Einfaches Hinzufügen von weiteren Klassen ist sehr leicht möglich. Bereits bestehende Tabellen müssen dabei nicht in ihrer Struktur verändert werden.

Nachteil:

• Beziehungen zu Objekten in einer Oberklasse, bei denen nicht eindeutig erkennbar ist, in welcher Unterklasse sich das einzelne Objekt befindet, sind sehr schwierig und aufwendig umzusetzten.

• Falls die konkrete Unterklasse nicht bekannt ist, kann auch die Tabelle nicht gefunden werden, in der der betreffende Datensatz gespeichert ist.

• Auswertungen über die gesamte Oberklasse benötigen eine Vielzahl von SQL-Befehlen, da die Objekte der Oberklasse über verschiedene Unterklassen verteilt sind.

Beispiel für ein Constrain: Fremdschlüssel

Diese ist eine Relation, die aus bereits bestehenden Relationen zusammengesetzt wird. Man nennt es auch Verbundmengen (engl. join)

Verbindet Datensätze aus mehreren Tabellen.

Beispiel

SELECT (Namen und Reihenfolgen der Spalten)

FROM (Tabellenname) INNER JOIN (Tabellenname)

ON (Tabellenname.Primäschlüssel)=(Tabellenname.Primärschlüssel) ;

Verbundtypen

INNER JOIN inneren Verbund

LEFT JOIN Linke Verbund

RIGHT JOIN Rechte Verbund

NATURAL JOIN natürliche Verbund

Duplikatfreie Vereinigungsmenge lautet UNION

Vereinigung Dublikate nicht elemeniert lautet UNION ALL

Schnittmenge INERSECT

Differenzmenge MINUS oder EXCEPT

AUTO_INCREMENT

Der Wert des Attributeswird durch das DBMS erzeugt und bei künstlichen Schlüsseln eingesetzt.

DEFAULT-Wert

Wurde für dieses Attribut ein Default Wert definiert, wird dieser Wert für den neuen Datensatz gespeichert.

NULL Wert

Wurde kein Default Wert festgelegt, speichert das DBMS einen NULL Wert für diese Spalte.

Hinweis Manche DBMS erzeugen statt null auch einen Standard DEFAULT Wert

Fehlermeldung

Wurde kein default Wert angegeben und ist diese Spalte mit NOT NULL definiert, wird eine Fehlermeldung ausgegeben und die Ausführung von INSERT ohne Änderung in der DB abgebrochen.

Das sind unerwünschte Effekte, die bei der gleichzeitigen Ausführung mehrere Transaktionen auf denselben Datensatz auftreten können. (Lost Update,Dirty Read, Non-Repetable Read, Phantom Read).

Dieses bezeichnet den in einem DBMS eingestellten Kompromiss zwischen Datenkonsistenz und Mehrbenutzerbetrieb. Dabei wird der Grad der gleichzeitigen Ausführung von Transaktionen gezielt konfiguriert.

Read Uncommitted

Niedrigstes Isolationslevel, bei dem auch nicht durch COMMIT bestätigte Änderungen gelesen werden können.

Read Committed

Erlaubt das Lesen nur von bereits durch COMMIT bestätigte Daten, verhindert jedoch keine inkonsistenten bei mehrfachen lesen.

Repeatable Read

Stellt sicher, das bei mehrfachen lesen des gleichen Datensatz die gleichen Daten zur Verfügung stehen. Verhindert jedoch keine Abweichungen durch einfügen oder löschen.

Serialize

Stellt sicher, dass bei mehrfachen lesen innerhalb einer Transaktion jeweils immer die gleichen Datenmengen zur Verfügung stehen, verhindert somit alle Isolationphänomene