RELATIONALES DATENBANKMODELL: ELEMENTE, WIE ES GEHT, BEISPIEL - TECHNOLOGIE - 2025

Das relationale Datenbankmodell ist eine Methode zur Strukturierung von Daten mithilfe von Beziehungen unter Verwendung gitterartiger Strukturen, die aus Spalten und Zeilen bestehen. Es ist das konzeptionelle Prinzip relationaler Datenbanken. Es wurde 1969 von Edgar F. Codd vorgeschlagen.

Im Vergleich zu anderen Datenbankmodellen wie Hierarchie, Netzwerk und Objekt ist es seitdem das dominierende Datenbankmodell für Geschäftsanwendungen.

Quelle: pixabay.com

Codd hatte keine Ahnung, wie wichtig und einflussreich seine Arbeit als Plattform für relationale Datenbanken sein würde. Die meisten Menschen sind mit dem physischen Ausdruck einer Beziehung in einer Datenbank sehr vertraut: der Tabelle.

Das relationale Modell ist als die Datenbank definiert, die es ermöglicht, seine Datenelemente in einer oder mehreren unabhängigen Tabellen zu gruppieren, die durch die Verwendung von Feldern, die jeder verwandten Tabelle gemeinsam sind, miteinander verknüpft werden können.

Datenbankmanagement

Eine Datenbanktabelle ähnelt einer Tabelle. Die Beziehungen, die zwischen den Tabellen erstellt werden können, ermöglichen es einer relationalen Datenbank jedoch, eine große Datenmenge effizient zu speichern, die effektiv abgerufen werden kann.

Der Zweck des relationalen Modells besteht darin, eine deklarative Methode zum Angeben von Daten und Abfragen bereitzustellen: Benutzer deklarieren direkt, welche Informationen die Datenbank enthält und welche Informationen sie von ihr wünschen.

Andererseits überlassen sie es der Software des Datenbankverwaltungssystems, die Datenstrukturen für die Speicherung und das Abrufverfahren zur Beantwortung der Fragen zu beschreiben.

Die meisten relationalen Datenbanken verwenden die SQL-Sprache zum Abfragen und Definieren der Daten. Derzeit gibt es viele relationale Datenbankverwaltungssysteme oder RDBMS (Relational Data Base Management System) wie Oracle, IBM DB2 und Microsoft SQL Server.

Funktionen und Elemente

- Alle Daten werden konzeptionell als geordnete Anordnung von Daten in Zeilen und Spalten dargestellt, die als Relation oder Tabelle bezeichnet werden.

- Jede Tabelle muss einen Header und einen Body haben. Der Header ist einfach die Liste der Spalten. Der Body ist der Datensatz, der die Tabelle füllt und in Zeilen angeordnet ist.

- Alle Werte sind Skalare. Das heißt, an einer bestimmten Zeilen- / Spaltenposition in der Tabelle gibt es nur einen einzigen Wert.

-Elemente

Die folgende Abbildung zeigt eine Tabelle mit den Namen der Grundelemente, die eine vollständige Struktur bilden.

Tupel

Jede Datenzeile ist ein Tupel, das auch als Datensatz bezeichnet wird. Jede Zeile ist ein n-Tupel, aber das "n-" wird im Allgemeinen verworfen.

Säule

Jede Spalte in einem Tupel wird als Attribut oder Feld bezeichnet. Die Spalte stellt die Werte dar, die ein bestimmtes Attribut haben kann.

Schlüssel

Jede Zeile enthält eine oder mehrere Spalten, die als Tabellenschlüssel bezeichnet werden. Dieser kombinierte Wert ist für alle Zeilen in einer Tabelle eindeutig. Mit diesem Schlüssel wird jedes Tupel eindeutig identifiziert. Das heißt, der Schlüssel kann nicht dupliziert werden. Es wird als Primärschlüssel bezeichnet.

Andererseits ist ein Fremd- oder Sekundärschlüssel das Feld in einer Tabelle, das sich auf den Primärschlüssel einer anderen Tabelle bezieht. Es wird verwendet, um auf die Primärtabelle zu verweisen.

-Regeln der Integrität

Beim Entwerfen des relationalen Modells definieren Sie einige Bedingungen, die in der Datenbank erfüllt sein müssen, sogenannte Integritätsregeln.

Schlüsselintegrität

Der Primärschlüssel muss für alle Tupel eindeutig sein und darf nicht null (NULL) sein. Andernfalls können Sie die Zeile nicht eindeutig identifizieren.

Bei einem mehrspaltigen Schlüssel darf keine dieser Spalten NULL enthalten.

Referenzielle Integrität

Jeder Wert eines Fremdschlüssels muss mit einem Wert des Primärschlüssels der referenzierten oder primären Tabelle übereinstimmen.

Eine Zeile mit einem Fremdschlüssel kann nur in die Sekundärtabelle eingefügt werden, wenn dieser Wert in einer Primärtabelle vorhanden ist.

Wenn sich der Wert des Schlüssels in der Primärtabelle aufgrund der Aktualisierung oder Löschung der Zeile ändert, sollten alle Zeilen in den Sekundärtabellen mit diesem Fremdschlüssel entsprechend aktualisiert oder gelöscht werden.

Wie erstelle ich ein relationales Modell?

-Daten sammeln

Die erforderlichen Daten müssen gesammelt werden, um in der Datenbank gespeichert zu werden. Diese Daten sind in verschiedene Tabellen unterteilt.

Für jede Spalte muss ein geeigneter Datentyp ausgewählt werden. Zum Beispiel: ganze Zahlen, Gleitkommazahlen, Text, Datum usw.

-Definieren Sie Primärschlüssel

Für jede Tabelle muss eine Spalte (oder wenige Spalten) als Primärschlüssel ausgewählt werden, die jede Zeile in der Tabelle eindeutig identifiziert. Der Primärschlüssel wird auch verwendet, um auf andere Tabellen zu verweisen.

- Erstellen Sie Beziehungen zwischen Tabellen

Eine Datenbank, die aus unabhängigen, nicht verwandten Tabellen besteht, hat wenig Zweck.

Der wichtigste Aspekt beim Entwerfen einer relationalen Datenbank ist die Identifizierung der Beziehungen zwischen den Tabellen. Die Beziehungstypen sind:

Eins zu viele

In einer "Class Listing" -Datenbank kann ein Lehrer null oder mehr Klassen unterrichten, während eine Klasse von einem einzelnen Lehrer unterrichtet wird. Diese Art von Beziehung wird als Eins-zu-Viele bezeichnet.

Diese Beziehung kann nicht in einer einzelnen Tabelle dargestellt werden. In der Datenbank «Liste der Klassen» können Sie eine Tabelle namens Lehrer haben, in der Informationen über Lehrer gespeichert sind.

Um die von jedem Lehrer unterrichteten Klassen zu speichern, können Sie zusätzliche Spalten erstellen, es tritt jedoch ein Problem auf: Wie viele Spalten müssen erstellt werden?

Wenn Sie jedoch eine Tabelle mit dem Namen Klassen haben, in der Informationen zu einer Klasse gespeichert sind, können Sie zusätzliche Spalten zum Speichern von Informationen zum Lehrer erstellen.

Da ein Lehrer jedoch viele Klassen unterrichten kann, werden seine Daten in vielen Zeilen in der Klassentabelle dupliziert.

Entwerfen Sie zwei Tabellen

Daher müssen Sie zwei Tabellen entwerfen: eine Klassentabelle zum Speichern von Informationen zu den Klassen mit Class_Id als Primärschlüssel und eine Teachers-Tabelle zum Speichern von Informationen zu den Lehrern mit Teacher_Id als Primärschlüssel.

Die Eins-zu-Viele-Beziehung kann dann erstellt werden, indem der Primärschlüssel aus der Master-Tabelle (Master_Id) in der Classes-Tabelle gespeichert wird, wie unten dargestellt.

Die Spalte Master_Id in der Tabelle Classes wird als Fremdschlüssel oder Sekundärschlüssel bezeichnet.

Für jeden Master_Id-Wert in der Master-Tabelle können null oder mehr Zeilen in der Classes-Tabelle enthalten sein. Für jeden Class_Id-Wert in der Classes-Tabelle gibt es nur eine Zeile in der Teachers-Tabelle.

Viel zu viel

In einer "Produktverkauf" -Datenbank kann eine Kundenbestellung mehrere Produkte enthalten, und ein Produkt kann in mehreren Bestellungen enthalten sein. Diese Art von Beziehung ist als viele zu viele bekannt.

Sie können die Datenbank "Produktverkäufe" mit zwei Tabellen starten: Produkte und Bestellungen. Die Tabelle "Produkte" enthält Informationen zu den Produkten mit der Produkt-ID als Primärschlüssel.

Andererseits enthält die Tabelle "Bestellungen" die Bestellungen des Kunden mit der Bestell-ID als Primärschlüssel.

Sie können die bestellten Produkte nicht in der Tabelle "Bestellungen" speichern, da Sie nicht wissen, wie viele Spalten für die Produkte reserviert werden sollen. Aus dem gleichen Grund können Bestellungen auch nicht in der Produkttabelle gespeichert werden.

Um eine Viele-zu-Viele-Beziehung zu unterstützen, müssen Sie eine dritte Tabelle erstellen, die als Join-Tabelle (OrderDetails) bezeichnet wird und in der jede Zeile ein Element in einer bestimmten Reihenfolge darstellt.

Für die OrderDetails-Tabelle besteht der Primärschlüssel aus zwei Spalten: orderID und productID, die jede Zeile eindeutig identifizieren.

Die Spalten orderID und productID in der Tabelle OrderDetails werden verwendet, um auf die Tabellen Orders and Products zu verweisen. Daher sind sie auch Fremdschlüssel in der OrderDetails-Tabelle.

Einer nach dem anderen

In der Datenbank "Verkauf von Produkten" kann ein Produkt optionale Informationen enthalten, z. B. eine zusätzliche Beschreibung und sein Bild. Wenn Sie es in der Produkttabelle belassen, werden viele Leerzeichen generiert.

Daher kann eine andere Tabelle (ProductExtras) erstellt werden, um die optionalen Daten zu speichern. Für Produkte mit optionalen Daten wird nur ein Datensatz erstellt.

Die beiden Tabellen Products und ProductExtras haben eine Eins-zu-Eins-Beziehung. Für jede Zeile in der Tabelle "Produkte" gibt es maximal eine Zeile in der Tabelle "ProductExtras". Für beide Tabellen muss dieselbe Produkt-ID als Primärschlüssel verwendet werden.

Vorteil

Strukturelle Unabhängigkeit

Im relationalen Datenbankmodell wirken sich Änderungen an der Struktur der Datenbank nicht auf den Zugriff auf die Daten aus.

Wenn es möglich ist, Änderungen an der Struktur der Datenbank vorzunehmen, ohne die Fähigkeit des DBMS zu beeinträchtigen, auf die Daten zuzugreifen, kann gesagt werden, dass strukturelle Unabhängigkeit erreicht wurde.

Konzeptionelle Einfachheit

Das relationale Datenbankmodell ist konzeptionell noch einfacher als das hierarchische oder Netzwerkdatenbankmodell.

Da das relationale Datenbankmodell den Designer von den Details der physischen Speicherung der Daten befreit, können sich Designer auf die logische Ansicht der Datenbank konzentrieren.

Einfaches Design, Implementierung, Wartung und Verwendung

Das relationale Datenbankmodell erreicht sowohl Datenunabhängigkeit als auch Strukturunabhängigkeit, wodurch das Entwerfen, Verwalten, Verwalten und Verwenden der Datenbank viel einfacher ist als bei anderen Modellen.

Ad-hoc-Abfragekapazität

Das Vorhandensein einer sehr leistungsfähigen, flexiblen und benutzerfreundlichen Abfragefunktion ist einer der Hauptgründe für die immense Popularität des relationalen Datenbankmodells.

Die Abfragesprache des relationalen Datenbankmodells, die als strukturierte Abfragesprache oder SQL bezeichnet wird, verwirklicht Ad-hoc-Abfragen. SQL ist eine Sprache der vierten Generation (4GL).

Mit einer 4GL kann der Benutzer festlegen, was getan werden soll, ohne anzugeben, wie es getan werden soll. Mit SQL können Benutzer daher angeben, welche Informationen sie möchten, und die Details zum Abrufen der Informationen in die Datenbank belassen.

Nachteile

Hardwarekosten

Das relationale Datenbankmodell verbirgt die Komplexität seiner Implementierung und die Details der physischen Speicherung von Benutzerdaten.

Zu diesem Zweck benötigen relationale Datenbanksysteme Computer mit leistungsfähigerer Hardware und Datenspeichergeräten.

Daher benötigt das RDBMS leistungsstarke Maschinen, um reibungslos zu funktionieren. Da jedoch die Verarbeitungsleistung moderner Computer exponentiell zunimmt, ist der Bedarf an mehr Verarbeitungsleistung im heutigen Szenario kein großes Problem mehr.

Einfaches Design kann zu schlechtem Design führen

Die relationale Datenbank ist einfach zu entwerfen und zu verwenden. Benutzer müssen die komplexen Details der physischen Speicherung von Daten nicht kennen. Sie müssen nicht wissen, wie die Daten tatsächlich gespeichert sind, um darauf zugreifen zu können.

Diese einfache Gestaltung und Verwendung kann zur Entwicklung und Implementierung schlecht gestalteter Datenbankverwaltungssysteme führen. Da die Datenbank effizient ist, werden diese Ineffizienzen beim Entwurf nicht sichtbar, wenn die Datenbank entworfen wird und wenn nur eine geringe Datenmenge vorhanden ist.

Wenn die Datenbank wächst, verlangsamen schlecht gestaltete Datenbanken das System und führen zu Leistungseinbußen und Datenkorruption.

Phänomen der «Informationsinseln»

Wie bereits erwähnt, sind relationale Datenbanksysteme einfach zu implementieren und zu verwenden. Dies führt dazu, dass zu viele Personen oder Abteilungen ihre eigenen Datenbanken und Anwendungen erstellen.

Diese Informationsinseln verhindern die Integration von Informationen, die für das reibungslose und effiziente Funktionieren der Organisation von wesentlicher Bedeutung sind.

Diese einzelnen Datenbanken verursachen auch Probleme wie Dateninkonsistenz, Datenverdoppelung, Datenredundanz usw.

Beispiel

Angenommen, eine Datenbank besteht aus den Tabellen Lieferanten, Teile und Sendungen. Die Struktur der Tabellen und einiger Beispieldatensätze ist wie folgt:

Jede Zeile in der Lieferantentabelle wird durch eine eindeutige Lieferantennummer (SNo) identifiziert, die jede Zeile in der Tabelle eindeutig identifiziert. Ebenso hat jedes Teil eine eindeutige Teilenummer (PNo).

Darüber hinaus kann die Tabelle "Sendungen" nicht mehr als eine Sendung für eine bestimmte Kombination aus Lieferant und Teil enthalten, da diese Kombination der Primärschlüssel von Sendungen ist, der als Vereinigungstabelle dient, da es sich um eine Viele-zu-Viele-Beziehung handelt.

Die Beziehung zwischen den Tabellen Teile und Sendungen wird angegeben, indem das Feld PNo (Teilenummer) gemeinsam verwendet wird, und die Beziehung zwischen Lieferanten und Sendungen entsteht, wenn das Feld SNo (Lieferantennummer) gemeinsam verwendet wird.

Aus der Analyse der Sendetabelle geht hervor, dass insgesamt 500 Nüsse von Suneet- und Ankit-Lieferanten mit jeweils 250 gesendet werden.

Ebenso wurden insgesamt 1.100 Schrauben von drei verschiedenen Lieferanten verschickt. 500 blaue Schrauben wurden vom Suneet-Lieferanten geliefert. Es gibt keine Lieferungen von roten Schrauben.

Verweise

1. Wikipedia, die freie Enzyklopädie (2019). Relationales Modell. Entnommen aus: en.wikipedia.org.
2. Techopedia (2019). Relationales Modell. Entnommen aus: deckenpedia.com.
3. Dinesh Thakur (2019). Relationales Modell. Hinweise zum Computer. Entnommen aus: ecomputernotes.com.
4. Geeks for Geeks (2019). Relationales Modell. Entnommen aus: geeksforgeeks.org.
5. Nanyang Technological University (2019). Ein Schnellstart-Tutorial zum relationalen Datenbankdesign. Entnommen aus: ntu.edu.sg.
6. Adrienne Watt (2019). Kapitel 7 Das relationale Datenmodell. BC Open Lehrbücher. Entnommen aus: opentextbc.ca.
7. Toppr (2019). Relationale Datenbanken und Schemata. Entnommen aus: toppr.com.