(1) Relationale Datenbanken

(1.) Einführung

Warum sind Datenbanken überhaupt notwendig?

Auch wenn Daten mit herkömmlichen Programmen effizient verwaltet werden können, stoßen diese bei großen Datenmengen und Mehrbenutzerzugriffen schnell an ihre Grenzen. Bei einer Flugbuchung müssen z.B. viele Nutzer gleichzeitig auf dieselben Daten zugreifen und Änderungen dauerhaft speichern können.

Ein Hauptproblem: Programme müssen die physische Datenstruktur genau kennen, was zu:

• hoher Komplexität,
• großem Anpassungsaufwand bei Änderungen,
• erhöhter Fehleranfälligkeit,
• hohen Einarbeitungskosten

führt.

Da sich Hardware, Speicherformate und Schnittstellen im Laufe der Zeit ändern, müssen Programme ständig angepasst werden.

Datenbanken lösen diese Probleme, indem sie, den Datenzugriff zentral verwalten, Strukturunabhängigkeit bieten, parallelen Zugriff sicher und konsistent ermöglichen.

Fazit: Bei komplexen und langfristigen Anwendungen sind Datenbanken unverzichtbar.

Definition

Was ist eine Datenbank?

Eine Datenbank ist eine Sammlung von Daten, die untereinander in einer logischen Beziehung stehen und von einem eigenen Datenbankverwaltungssystem (Database Management System, DBMS) verwaltet werden.

Was ist ein DMBS und was ist sein Zweck?

Das Datenbankverwaltungssystem (DBMS) schottet die Daten vollständig ab. Dieses DBMS besitzt eine von der Hardware unabhängige logische Schnittstelle nach außen. Alle Benutzer und damit auch alle Anwendungsprogramme greifen ausschließlich über diese Schnittstelle auf die Daten zu.

Das DBMS setzt diese logischen Zugriffe in physische um und liest und schreibt letztlich die Daten selbst vom bzw. auf das Speichermedium. Diese logische Schnittstelle wird vom Datenbankhersteller exakt definiert. Damit entfallen komplexe physische Zugriffsbefehle auf die Datenbestände. Änderungen an der Datenstruktur ist nach außen nicht sichtbar.

Ein DBMS bietet viele Vorteile gegenüber anderen Speicheformen:

• es die Daten sehr performant bereitstellen
• es kann Zugriffsrechte verwalten
• es prüft die Konsistenz der Daten
• es erlaubt den parallelen Zugriff mehrerer Benutzer
• es ermöglicht eine Transaktionslogik
• Backup und Recovery möglich

Nachteile:

• Kosten (Lizenzen, spezialisiertes Personal)
• Komplexität (Implementierung und Wartung)
• GGf. hohe Hardware Anforderungen

SQL

Die heute mit Abstand wichtigste und weit verbreitete Datenbankschnittstelle ist SQL. SQL steht für Structured Query Language und ist eine Zugriffssprache auf relationale Datenbanken. Sie wurde von E. F. Codd ab 1970 bei IBM entwickelt, hieß zunächst SEQUEL und wurde 1979 von Oracle bei der Einführung des allerersten kommerziellen DBMS Oracle V2 unter dem heutigen Namen SQL vorgestellt.

tipp

MERKE - Auf die Daten einer Datenbank greifen Anwendungsprogramme und Endbenutzer über eine komfortable, mächtige und normierte Schnittstelle des DBMS (zum Beispiel über die normierte Sprache SQL) zu. Kenntnisse über die innere physische Struktur der Daten innerhalb der Datenbank sind nicht erforderlich. Die Umsetzung der logischen in physische Zugriffe übernimmt das DBMS.

Anforderungen an einer Datenbank

Moderne Datenbanksysteme sollen vielfältige Anforderungen erfüllen, um große Datenmengen effizient zu verwalten. Die wichtigsten Anforderungen sind:

• Logisch verbundene Datensammlung: Nur zusammengehörige Daten sollten gemeinsam gespeichert werden. Unabhängige Daten sind getrennt zu verwalten, was die Struktur vereinfacht.
• Möglichst geringe Redundanz: Doppelte Datenspeicherung (Redundanz) ist speicherintensiv und fehleranfällig. Eine Datenbank sollte redundanzarme Speicherung ermöglichen und bei unvermeidbarer Redundanz für automatische Konsistenz sorgen.
• Abfrage- und Änderbarkeit: Daten müssen schnell und zuverlässig abfragbar und änderbar sein – idealerweise innerhalb weniger Sekunden. Auch komplexe Abfragen über mehrere Tabellen und Speicherorte hinweg müssen effizient möglich sein.

Die physische Speicherung und Verteilung der Daten (z. B. über mehrere Rechner oder in der Cloud) soll für den Nutzer transparent sein. Die Verwaltung dieser technischen Details übernimmt das Datenbankmanagementsystem (DBMS).

Aufgabenverteilung in der Datenbank

Die Aufgaben eines DBMS lassen sich in drei Teile zerlegen:

• DDL (Data Description Language)
• DCL (Data Control Language, oft in DDL integriert)
• DML (Data Manipulation Language)

DDL und DCL sind vor allem für Datenbank-Administratoren relevant. Sie dienen der Beschreibung (DDL) und Kontrolle (DCL) der Datenbank.

Einige typisch DDL-Befehle in SQL sind:

• CREATE TABLE zum Erzeugen einer Tabelle,
• DROP TABLE zum Löschen einer Tabelle

DCL-Befehle:

• CREATE VIEW zum Erzeugen einer Sicht,
• GRANT zum Gewähren von Zugriffsrechten

Mittels DML-Befehlen werden Daten manipuliert, also gespeichert, gelesen, geändert und gelöscht. Die vier DML-Befehle von SQL haben heißen:

• SELECT zum Abfragen,
• UPDATE zum Ändern,
• DELETE zum Löschen und
• INSERT zum Einfügen von Daten in eine Datenbank.

info

Genauer gesagt gehört der SELECT-Befehl zur DQL (Data Query Language) denn damit werden Daten nicht manipuliert, sondern einfach nur abgefragt.

(2.) Kurze Geschichte der Datenbanken

The untold story of databases 15-minütiges Video über die Geschichte der Datenbanken

• Punch cards
• Vector embeddings (interessant für die Verarbeitung von Firmendaten)
• Mainframes: extrem leistungsfähige Großcomputer für kritische Aufgaben wie Massendatenverarbeitung, die von großen Unternehmen für ihre essenziellen Anwendungen eingesetzt werden. Sie zeichnen sich durch hohe Zuverlässigkeit, Sicherheit und Geschwindigkeit aus und können Milliarden von Transaktionen gleichzeitig verarbeiten. Der Begriff leitet sich vom ursprünglichen Gehäuse ab, das die zentrale Einheit enthielt, und heute dienen sie oft als zentrale „Hubs“ für die Vernetzung von Systemen in Unternehmen.
• Quantum Storage

Die unterschätzte Macht der Datenbanken

Entwickler fokussieren sich oft auf Frameworks und Code, doch die Datenbank ist das eigentliche Fundament. Datenbanken organisieren Realität, nicht nur Daten: Flüge, Banküberweisungen, Streaming. Alles läuft über Datenbanken.

Frühe Anfänge (1801–1950er)

• 1801 nutz Joseph Jacquard Lochkarten zur Steuerung von Webstühlen: frühes Beispiel speicherbarer Logik.
• 1880 entwickelt Herman Hollerith eine elektromechanische Zählmaschine (tabulating machine) für die US-Volkszählung. Das war die Grundlage für IBM.

Problem der Zeit: Daten sind physisch, schwer zu verwalten, Suche dauert extrem lange.

In den 1950er-Jahren ersetzen magnetische Bänder und erste elektronische Computer die Lochkarten. Daten werden nun unsichtbar als magnetische Muster gespeichert. Doch das Auffinden einzelner Informationen bleibt mühsam, da man genau wissen muss, wo sie liegen; das Durchsuchen der Bänder kann Stunden oder sogar Tage dauern.

Wie funktionieren Magnetbänder?

Erste Datenbankkonzepte (1960er)

Charles Bachman entwickelt das erste echte Datenbank-Management-System mit Netzwerkmodell (IDS). Der Hintergrund ist, dass in dieser Zeit die Entwickler viel Zeit mit der Suche von Daten verschwendet haben. Daten können nun verknüpft werden, damit entsteht eine Struktur.

Sabre-System (1964) – Datenbanken als Waffe

American Airlines und IBM entwickeln Sabre: ein kontinentweites Reservierungssystem. Das revolutioniert den Luftverkehr und zeigt die Macht von Datenbank-Kontrolle. Sabre wird später manipuliert, um American Airlines zu bevorzugen, was politische Folgen hatte.

Die relationale Revolution (1970er)

Datenbanken waren bisher hierarchisch organisiert. Edgar F. Codd (IBM) schlägt ein relationales Datenmodell vor: Daten in Tabellen (Zeilen/Spalten) organisieren. Nutzer geben an, was sie wollen, nicht wie es gefunden werden soll. Das stellt die Grundlage von SQL dar.

Berkeley-Initiative (Ingres): Akademisches Projekt zur praktischen Umsetzung von Codds Modell.

IBM startet auch ein Projekt in die Richtung (System R). Der Fokus liegt hier auf echten Anwendungsfälle. Um nicht-Programmierer die Arbeit mit Daten zu ermöglichen, wird SQL entwickelt (Chamberlin und Boyce). IBM kommerzialisiert das System aber nicht.

Kommerzialisierung & Datenbankkriege (1980er)

Larry Ellison (Gründer von Oracle): Baut das erste kommerzielle SQL-DBMS (Oracle V2), schlägt IBM um Jahre.

IBM antwortet mit DB2; der Datenbankmarkt wird hart umkämpft.

1986: SQL wird offizieller Standard (ANSI) Interoperabilität und Entwicklerfreundlichkeit

ANSI X3.135-1986: Der erste offizielle Standard für SQL.

ISO/IEC 9075: Internationale Normenreihe für SQL, beginnend ab 1987 und laufend aktualisiert (z. B. SQL:1999, SQL:2011, SQL:2023 usw.).

1990er: Datenbanken kommen an ihre Grenzen

In den 1990er-Jahren stießen relationale Datenbanken zunehmend an ihre Grenzen, da sie sich nur schwer mit der aufkommenden objektorientierten Programmierung vereinen ließen. Entwickler arbeiteten in Objekten, während relationale Systeme in Tabellen dachten. Als Reaktion entstanden objektorientierte Datenbanken wie Versant und Objectivity, die Daten in ihrer nativen Objektstruktur speichern sollten. Trotz anfänglicher Hoffnungen konnten sie sich jedoch nicht durchsetzen: SQL (relationale Datenbanken) war zu weit verbreitet, zu standardisiert und zu fest im Markt etabliert.

2000er: Fokus auf Verfügbarkeit

In den 2000er-Jahren verschoben sich die Herausforderungen: Unternehmen wie Google und Amazon sahen sich mit Datenmengen konfrontiert, die die Kapazitäten klassischer relationaler Datenbanken sprengten. Um diese enormen Skalierungsprobleme zu lösen, entwickelten sie neue, verteilte Datenbanksysteme.

Google veröffentlichte 2006 das BigTable-Paper, Amazon folgte 2007 mit dem Dynamo-Paper. Diese Systeme legten weniger Wert auf vollständige Konsistenz, sondern setzten auf hohe Verfügbarkeit und Fehlertoleranz: Eine bewusste Abkehr von den klassischen ACID-Prinzipien hin zum BASE-Modell („Basically Available, Soft state, Eventual consistency“).

Die NoSQL-Bewegung entstand und brachte neue Datenbankmodelle wie Cassandra, MongoDB oder CouchDB hervor, die speziell für webbasierte, verteilte und hochskalierbare Anwendungen konzipiert wurden.

2010er: Fokus auf Skalierbarkeit und Cloud-Lösungen

Mit dem Aufstieg der Cloud in den 2010er-Jahren veränderte sich der Umgang mit Datenbanken erneut grundlegend. Datenbanken wurden zunehmend als Dienste angeboten, die sich automatisch skalieren, selbst reparieren und nach Verbrauch abgerechnet werden konnten.

Anbieter wie Amazon (DynamoDB), Google (Firestore) und Microsoft (Cosmos DB) ermöglichten es Unternehmen, komplexe Datenbankinfrastrukturen ohne eigene Server zu betreiben.

Gleichzeitig setzte sich der Ansatz durch, verschiedene Datenbanktypen je nach Anwendungsfall zu kombinieren: klassische relationale Datenbanken wie PostgreSQL für Transaktionen, Redis für schnelle Zwischenspeicherung, Elasticsearch für performante Volltextsuchen oder Neo4j für die Analyse von Beziehungsnetzwerken. Entwickler wurden zunehmend zu Datenarchitekten, die aus einer Vielzahl spezialisierter Systeme die optimale Kombination für ihre Anforderungen zusammenstellten.

2020er: KI Revolution

In den 2020er-Jahren steht die nächste große Datenbankrevolution im Zeichen der künstlichen Intelligenz. Mit dem Aufkommen von KI-Anwendungen und generativen Modellen wächst der Bedarf an Systemen, die nicht nur Daten, sondern auch Bedeutungen speichern können. Vektor-Datenbanken wie Pinecone oder Milvus ermöglichen genau das: Sie speichern hochdimensionale Repräsentationen von Text, Bildern oder Ton und ermöglichen so semantische Suche und AI-gesteuerte Verarbeitung. Der Fokus verschiebt sich auf neue Anforderungen wie Echtzeitverarbeitung, Edge-Computing, die Integration von IoT-Geräten und die nahtlose Anbindung an KI-Systeme. Datenbanken entwickeln sich damit weiter zur kognitiven Infrastruktur der digitalen Welt.

(3.) Datenbankentypen

Hierarchische und netzwerkartige Datenbanken

Hierarchische Datenbanken wurden ab etwa 1960 als erste Datenbanken überhaupt eingesetzt.

Der logische Aufbau dieser Datenbanken entspricht einer Baumstruktur. Der Zugriff erfolgt immer über die Wurzel (oberster Knoten) in Richtung des gewünschten Knotens. Dies gewährleistet geringste Redundanz und garantiert kürzeste Zugriffszeiten, da direkt über die Baumstruktur zugegriffen wird. Der Nachteil ist eine hohe Inflexibilität gegenüber Änderungen in der Datenbankstruktur.

Aus diesem Grund wurde dieses Modell sehr schnell durch die netzwerkartigen Datenbanken ergänzt. Die hierarchische Baumstruktur wurde aufgegeben, zugunsten einer wesentlich flexibleren Netzstruktur. Damit lassen sich Anwendungen viel einfacher modellieren, allerdings auf Kosten einer etwas höheren Komplexität des Aufbaus.

Beide Modelle sind heute irrelevant, da Strukturänderungen aufwendig und Zugriffe komplex sind. Der wichtigste Vertreter hierarchischer Datenbanken ist IMS von IBM, netzwerkartige Datenbanken sind IDMS (Computer Associates) und UDS (Fujitsu).

Objektorientierte Datenbanken

Objektorientierte Datenbanken speichern Daten in Form von Objekten (z. B. Personen, Bücher, Rechnungen) und nutzen Techniken aus der objektorientierten Programmierung wie Klassen, Vererbung und Datenkapselung. Sie bilden komplexe, reale Strukturen direkt ab und eignen sich besonders für technische und multimediale Anwendungen.

Da viele Objekte auch tabellarisch gespeichert werden können, gelten objektorientierte Datenbanken oft als Erweiterung relationaler Systeme. In der Praxis dominieren objektrelationale Datenbanken wie Oracle, DB2 oder PostgreSQL, die eine Mischform darstellen.

Vorteile:

• Realitätstreuer Aufbau
• Universell einsetzbar
• (Teilweise) kompatibel mit relationalen Datenbanken

Nachteile:

• Hoher Aufwand bei Entwurf, Programmierung und Verwaltung
• Viele Ein-/Ausgaben
• Höherer Ressourcenbedarf
• Komplexer als rein relationale Systeme

Relationale Datenbanken

Relationale Datenbanken bestehen ausschließlich aus Tabellen (Relationen), die flexibel ergänzt, verändert oder gelöscht werden können. Datenzugriffe erfolgen immer über diese Tabellen, was die Programmierung erleichtert und zur weiten Verbreitung dieses Modells im kommerziellen Bereich geführt hat. Tabellen sind über Beziehungen miteinander verknüpft.

Vorteile:

• Flexibler Aufbau
• Einfache Erweiterbarkeit
• Weit verbreitet und gut unterstützt

Nachteile:

• Häufige Verknüpfungen zwischen Tabellen führen zu hohen Laufzeiten
• Potenzielle Datenredundanz

Moderne Datenbankentypen

Relationale Datenbanken stoßen an ihre Grenzen, wenn sehr viele oder sehr umfangreiche Anfragen gleichzeitig verarbeitet werden müssen, etwa bei großen Internetdiensten. Sie sind stark auf Datenkonsistenz und Transaktionssicherheit ausgelegt: Änderungen an Daten werden sofort sichtbar, und selbst bei einem Systemabsturz bleibt die Datenintegrität gewahrt. Dieses Verhalten ist zwar zuverlässig, benötigt jedoch viel Rechenleistung und langsame Speicherzugriffe, was die Performance beeinträchtigen kann.

Für viele Internetanwendungen ist es jedoch nicht entscheidend, ob Informationen in Echtzeit verfügbar sind. Es reicht oft, wenn der Datenstand wenige Sekunden oder Minuten alt ist. D. h., wenn man auf die sofortige Korrektheit verzichtet, kann man das System deutlich vereinfachen und besser skalieren. Daten werden auf mehrere Server verteilt, und bei Anfragen greift das System auf den jeweils verfügbaren Server zu, auch wenn dessen Daten noch nicht ganz aktuell sind. Ein internes Verwaltungssystem sorgt dafür, dass die Daten im Hintergrund nach und nach abgeglichen werden.

Diese neuen Ansätze werden unter den Begriffen NoSQL und Big Data zusammengefasst. Der Begriff NoSQL steht dabei nicht für ein völliges „Nein zu SQL“, sondern eher für Not Only SQL.

Moderne NoSQL-Datenbanken lassen sich in vier Kategorien unterteilen:

• Key/Value-Datenbanken
• Dokumentenbasierte Datenbanken
• Spaltenorientierte Datenbanken
• Graphen-Datenbanken

Key/Value-Datenbanken

Die Idee der Key/Value-Datenbanken ist einfach: Wir speichern die einzelnen Datensätze zusammen mit dem Schlüssel ab. Ein Datensatz ist meist eine Zeichenkette, kann aber auch aus einer komplexen Struktur bestehen. Key/Value-Datenbanken sind sehr einfach zu skalieren und daher im Cloud-Computing weit verbreitet.

Beispiele:

• Dynamo (von Amazon, aktuell beliebt)
• Riak (Open Source)

Dokumentbasierte Datenbanken

In dokumentenbasierten Datenbanken werden alle Daten als Dokumente abgelegt. Diese Datenbanken haben ihren Ursprung in Lotus Notes. In diesen Datenbanken gibt es keine fest vorgeschriebenen Strukturen, da sich praktisch alle Daten als Dokumente definieren und speichern lassen. Dies ist vor allem bei WEB-Anwendungen von großem Vorteil. Die beiden mit Abstand wichtigsten Vertreter sind MongoDB und CouchDB.

Spaltenorientierte Datenbanken

Spaltenorientierte Datenbanken speichern die Daten nicht zeilen- sondern spaltenweise. In der Praxis werden heute nur selten reine spaltenorientierte Modelle eingesetzt. Vielmehr orientieren sich die meisten dieser Datenbanken am Big-Table-Konzept von Google. Es handelt sich um eine Mischform von Key-Value- und Spalten-Datenbanken. Eine Big-Table wird beispielsweise sowohl durch einen Zeilen- als auch einen Spaltenindex indiziert. Zusätzlich wird mit den Daten ein Zeitstempel abgespeichert.

Da in einer Big-Table keine Daten gelöscht werden, erfolgt der Zugriff auf gültige Daten immer mittels des Tripels Zeilenindex, Spaltenindex und Zeitstempel.

Beispiele:

• Google Big-Table
• Microsoft HBase
• Apache Cassandra

Graphendatenbanken

Graphdatenbanken werden vor allem in Navigationsgeräten eingesetzt. Sie finden aber auch in Geodatenbanken und in sozialen Netzwerken breite Anwendung. Grundlage dieser Datenbanken ist die Graphentheorie. Diese Datenbanken sind hervorragend geeignet, um Graphen zu durchsuchen. Sie ermöglichen eine schnelle rekursive Suche ohne aufwendige Verbund-Operationen. Dabei sind die gespeicherten Daten in der Regel unstrukturiert.

Beispiele:

• Neo4J und OrientDB (Open Source)
• GraphDB (Fa. Sones)

(4.) Das Entity-Relation-Modell (ERM)

Das Design einer kompletten Datenbank umfasst das Erstellen vieler Relationen. Gute Handhabung und minimale Redundanz ist ein Ziel beim Aufbau großer Datenbanken mit zahlreichen Relationen. Eine von uns erzeugte Datenbank sollte gut anwendbar und bis auf die Beziehungen zwischen Primär- und Fremdschlüsseln redundanzfrei sein. Der Entwurf einer Datenbank ist anspruchsvoll und wird umso aufwendiger, je mehr Relationen wir benötigen.

Das Entity-Relationship-Modell, kurz ERM genannt, unterstützt beim Entwurf der Datenbank. Dieses Modell wurde von P. P. Chen vorgestellt (1976) und hat sich in der Praxis insbesondere bei relationalen Datenbanken vielfach bewährt.

Die Normalisierung der Relationen beseitigt Redundanzen innerhalb einer Relation. Das Entity-Relationship-Modell, konsequent angewendet, verhindert Redundanzen bis auf Fremdschlüssel auch über die Grenzen einzelner Relationen hinweg.

Das Entity-Relationship-Modell (ERM) ist eine zentrale Methode im Datenbankdesign, um die Struktur und Zusammenhänge von Daten aus der realen Welt systematisch in einer Datenbank abzubilden. Dabei steht das Modell auf zwei wesentlichen Säulen: den Entitäten und ihren Beziehungen. Das ERM stellt somit eine Grundlage dar, um komplexe Zusammenhänge der realen Welt in strukturierte Datenbankmodelle zu überführen. Es ermöglicht eine klare Trennung und Zuordnung von Daten, stellt Beziehungen transparent dar und bildet die Basis für eine effiziente und konsistente Implementierung relationaler Datenbanken.

Entitäten

Eine Entität ist ein eindeutig identifizierbares Objekt, etwa eine Person, ein Produkt oder eine Rechnung. Diese Objekte existieren tatsächlich in der realen Welt.

Jede Entität besitzt bestimmte Eigenschaften, also Merkmale, die sie näher beschreiben. Eine Person hat etwa einen Namen, eine Adresse oder eine Personalnummer. Diese Eigenschaften helfen uns, das Objekt differenziert zu erfassen und von anderen Objekten zu unterscheiden.

In der grafischen Darstellung des ER-Modells werden Entitäten als Rechtecke dargestellt, Eigenschaften hingegen als Ellipsen.

info

Aus praktischen Gründen – etwa bei komplexen Modellen mit vielen Entitäten – werden Eigenschaften häufig direkt innerhalb des Rechtecks der Entität aufgeführt, ähnlich wie bei UML-Diagrammen.

Beziehungen

Kaum ein Objekt in der realen Welt existiert völlig losgelöst von anderen. Personen arbeiten in Abteilungen, Verkäufer verkaufen Produkte, Rechnungen werden für bestimmte Kunden erstellt. Solche Zusammenhänge modellieren wir durch Beziehungen, die im ER-Diagramm als Rauten dargestellt werden, verbunden mit den beteiligten Entitäten.

Kardinalitäten

Eine besondere Rolle spielen dabei die sogenannten Kardinalitäten, mit denen wir angeben, wie viele Objekte einer Entität mit wie vielen Objekten einer anderen in Beziehung stehen. Beispielsweise kann eine Abteilung mehrere Mitarbeiter haben (1:n), während ein Mitarbeiter immer nur einer Abteilung zugeordnet ist.

Subtyp und Supertyp

Innerhalb des Modells begegnen uns auch Subtypen und Supertypen. Diese Konzepte helfen, Entitäten hierarchisch zu strukturieren. Ein Subtyp ist eine spezielle Ausprägung einer allgemeineren Entität. So ist beispielsweise ein Verkäufer ein Subtyp von Mitarbeiter. Er gehört zur Gesamtgruppe, besitzt aber zusätzliche, spezifische Eigenschaften wie Verkaufszahlen oder Provisionsregelungen, die für andere Mitarbeiter nicht relevant sind. Der übergeordnete Typ, der alle Varianten umfasst, wird als Supertyp bezeichnet. Die saubere Trennung von Subtypen und Supertypen macht das Modell flexibel und klar erweiterbar.

Starke und schwache Entitäten

Eine weitere wichtige Unterscheidung ist die zwischen starken und schwachen Entitäten. Starke Entitäten können unabhängig von anderen bestehen, während schwache Entitäten vollständig von einer anderen Entität abhängen. Diese Abhängigkeit zeigt sich auch in der Datenstruktur: Eine schwache Entität kann ohne die Existenz ihrer "starken" Bezugseinheit nicht sinnvoll existieren. So ergibt zum Beispiel eine Fehlerliste in einer Produktionsdatenbank nur dann Sinn, wenn das zugehörige Produkt ebenfalls existiert. Wird das Produkt gelöscht, ist die Fehlerliste überflüssig und muss mit entfernt werden. In ER-Diagrammen werden schwache Entitäten häufig durch Doppellinien kenntlich gemacht.

Vorgehen

1. Der Modellierungsprozess beginnt mit der sorgfältigen Erfassung aller relevanten Entitäten und ihrer Eigenschaften. Dieser Schritt setzt ein tiefes Verständnis des abzubildenden Fachbereichs voraus, denn nur wer die realen Anforderungen kennt, kann die passende Datenstruktur entwerfen. Häufig ist der Prozess iterativ: Erst durch wiederholte Überprüfung und Anpassung entsteht ein vollständiges und konsistentes Modell.

2. Sind alle Entitäten und deren Eigenschaften definiert, folgt die zweite Phase der Modellierung: die Bestimmung der Beziehungen zwischen den Entitäten. Diese Beziehungen stellen oft den komplexesten Teil des Modells dar, da hier auch Abhängigkeiten, Kardinalitäten und Mehrdeutigkeiten korrekt abgebildet werden müssen.

3. Abschließend wird aus dem ER-Modell eine relationale Struktur für die Datenbank abgeleitet. Jede Entität wird dabei zu einer Tabelle (Relation) in der Datenbank. Die einzelnen Eigenschaften der Entitäten entsprechen den Spalten dieser Tabellen. Beziehungen werden über sogenannte Fremdschlüssel dargestellt. Wenn das Modell gut durchdacht ist, erfüllen die daraus erzeugten Tabellen häufig bereits wichtige Anforderungen der sogenannten dritten Normalform, eine Regel im Datenbankdesign, die Redundanzen vermeidet und die Datenkonsistenz erhöht.

Beziehungen

Beziehungen zwischen Entitäten lassen sich grundsätzlich in drei Hauptkategorien unterteilen:

• 1 zu 1 (eins zu eins) Beziehungen
• m zu 1 (viele zu eins) Beziehungen
• m zu n (viele zu viele) Beziehungen

Eine 1 zu 1 Beziehung besteht, wenn jeder Eintrag in Entität A genau mit einem Eintrag in Entität B verknüpft ist und umgekehrt. In der m zu 1 Beziehung ist es möglich, dass mehrere Einträge in Entität A mit einem einzigen Eintrag in Entität B verbunden sind. Im Gegensatz dazu bedeutet m zu n: Jeder Eintrag in Entität A kann mit mehreren Einträgen in Entität B und umgekehrt verbunden sein.

Ein Beispiel für eine m zu 1 Beziehung findet sich in der Beziehung zwischen den Entitäten "Abteilung" und "Person". Jeder Mitarbeiter (Person) gehört genau einer Abteilung, aber jede Abteilung kann mehrere Mitarbeiter haben. In diesem Fall kann es jedoch auch vorkommen, dass eine Abteilung noch keine Mitarbeiter hat, etwa wenn sie neu gegründet wurde.

Unterschiedliche Beziehungstypen und deren Bedeutung

Es gibt jedoch noch feinere Unterschiede, die bei der Modellierung berücksichtigt werden müssen. Zum Beispiel ist es in manchen Fällen notwendig, Nullwerte zuzulassen, was zu einer m zu c (viele zu null oder eins) Beziehung führen kann. Das bedeutet, dass ein Mitarbeiter keiner Abteilung zugeordnet sein könnte, etwa bei Sonderfunktionen oder Umstrukturierungen innerhalb eines Unternehmens.

Beziehungen zwischen Entitäten können auch 0, 1 oder m als mögliche Kardinalitäten beinhalten. Dies führt zu einer erweiterten Kategorisierung der Beziehungen, die insgesamt neun verschiedene Typen umfasst, von denen einige in der Praxis selten oder schwer realisierbar sind, wie die 1 zu 1 Beziehung, die in relationalen Datenbanken wenig Anwendung findet.

Praktische Beispiele für Beziehungstypen

• 1 zu c Beziehungen: Diese Art der Beziehung tritt häufig auf, wenn Entitäten Subtypen haben, wie im Beispiel "Mitarbeiter" und "Verkäufer". Jeder Verkäufer ist ein Mitarbeiter, aber nicht jeder Mitarbeiter ist ein Verkäufer. Hier werden Zusatzinformationen in Subtypen ausgelagert, was es ermöglicht, dass jeder Verkäufer genau einen Eintrag in der Entität "Mitarbeiter" hat, aber umgekehrt nur maximal einen "Verkäufer"-Eintrag existiert.

• m zu 1 Beziehungen: Ein häufig vorkommender Fall, bei dem mehrere Entitäten der ersten Entität auf eine einzelne Entität der zweiten Entität verweisen. Ein Beispiel ist die Beziehung zwischen "Abteilung" und "Person", bei der jeder Mitarbeiter einer bestimmten Abteilung zugeordnet ist, aber eine Abteilung mehrere Mitarbeiter haben kann.

• m zu c Beziehungen: Diese treten auf, wenn ein Mitarbeiter entweder keiner oder einer Abteilung zugeordnet ist. In diesem Fall kann eine Abteilung auch vorübergehend keine Mitarbeiter haben.

• c zu c Beziehungen: Selten, aber existent, zum Beispiel zwischen einem Abteilungsleiter (der maximal eine Abteilung leitet) und der Abteilung selbst. Hierbei geht es um eine sehr spezifische Beziehung, die in bestimmten Unternehmensstrukturen vorkommt.

• m zu n Beziehungen: Diese treten auf, wenn beide Entitäten viele Beziehungen miteinander haben. Ein Beispiel aus der Praxis ist die Beziehung zwischen "Verkäufer" und "Produkt", bei der ein Verkäufer mehrere Produkte verkaufen kann und ein Produkt von mehreren Verkäufern angeboten werden kann.

Zusammenfassung der fünf wesentlichen Beziehungstypen

• 1 zu c Beziehungen (mit c ∈ 1): Diese Beziehungen entstehen häufig, wenn zusätzliche Eigenschaften von Entitäten in Subtypen ausgelagert werden.
• m zu 1 Beziehungen: Eine der häufigsten Beziehungstypen, bei denen mehrere Einträge einer Entität auf einen einzigen Eintrag einer anderen Entität verweisen.
• m zu c Beziehungen: Eine Beziehung, bei der Entitäten entweder null oder einmalig miteinander verbunden sind.
• c zu c Beziehungen: Spezialfall der m zu c Beziehung, bei dem jede Entität höchstens mit einer Entität der anderen Seite verknüpft ist.
• m zu n Beziehungen: Hier handelt es sich um eine viele-zu-viele Beziehung, bei der mehrere Entitäten auf mehrere Einträge der jeweils anderen Entität verweisen.

(5.) Relationale Datenbanken

Relationale Datenstrukturen

Primärschlüssel

Relationale Integritätsregeln (nur zusammenfassung)

Transformationsregeln vom ERD zu Relationen

Die Transformationsregeln beschreiben, wie man ein ER-Diagramm (Entity-Relationship-Diagramm) in relationale Tabellen umwandelt. Hier sind die wichtigsten Regeln zusammengefasst:

Regel 1: Entitätstypen zu Tabellen

Jeder Entitätstyp (z.B. Kurs, Schüler) wird als Tabelle dargestellt.

Jede Tabelle benötigt einen Primärschlüssel, der für die eindeutige Identifikation der Datensätze in der Tabelle sorgt.

Regel 2: n:m-Beziehungen

n:m-Beziehungen (z.B. viele Schüler besuchen viele Kurse) werden durch eine eigene Tabelle dargestellt.

Diese Tabelle enthält:

Die Primärschlüssel der beiden Entitätstypen als Fremdschlüssel.

Eventuell auch eigene Attribute, die für die Beziehung relevant sind (z.B. Fehlstunden).

Beispiel:

Kurs: KNR, Name

Schüler: SNR, Name, Vorname

besucht (Beziehungstabelle): KNR, SNR, Fehlstunden

Hier stellt die Tabelle besucht eine n:m-Beziehung zwischen Kurs und Schüler dar.

Regel 3: 1:n- und 1:1-Beziehungen mit eigenen Attributen

1:n- und 1:1-Beziehungen mit eigenen Attributen (z.B. eine Beziehung, die zusätzliche Informationen wie Fehlstunden enthält) werden durch eine eigene Tabelle dargestellt.

Diese Tabelle enthält:

Die Primärschlüssel der beiden Entitätstypen als Fremdschlüssel.

Die zusätzlichen Attribute der Beziehung.

Regel 4: 1:n- und 1:1-Beziehungen ohne eigene Attribute

Regel 4a: 1:n-Beziehung ohne eigene Attribute

Der Primärschlüssel des Entitätstyps auf der 1-Seite wird als Fremdschlüssel in der Tabelle des Entitätstyps auf der n-Seite gespeichert.

Beispiel:

Klasse: KlBez, KlRaum, LNR

Schüler: SNR, Name, Vorname, KlBez

In der Tabelle Schüler wird KlBez als Fremdschlüssel gespeichert, um die 1:n-Beziehung zwischen Klasse und Schüler darzustellen.

Regel 4b: 1:1-Beziehung ohne eigene Attribute

Der Primärschlüssel des ersten Entitätstyps wird gleichzeitig als Primär- und Fremdschlüssel im zweiten Entitätstyp gespeichert.

Beispiel:

Schüler: SNR, Name, Vorname, KlBez

SchülerPrivat: SNR, Konfession, Herkunft

SNR ist hier der Primär- und Fremdschlüssel, der die 1:1-Beziehung zwischen den beiden Tabellen beschreibt.

Regel 4c: Wenn 4a oder 4b nicht anwendbar sind

Wenn keine der beiden Regeln (4a oder 4b) anwendbar ist, wird für die Beziehung eine eigene Tabelle erstellt.

Beispiel:

Eine Ehe zwischen zwei Entitäten wie Männer und Frauen: Da nicht jeder verheiratet sein muss, werden leere Felder in den Tabellen vermieden, indem eine separate Tabelle Ehe erstellt wird, die beide Fremdschlüssel (Ehemann, Ehefrau) enthält.

Richtige Lösung:

Männer: Name, Frauen: Name -> Ehe: Ehemann, Ehefrau

Zusammengefasst:

• 1:n-Beziehung ohne eigene Attribute: Primärschlüssel der „1“-Seite als Fremdschlüssel in der „n“-Seite.
• 1:1-Beziehung ohne eigene Attribute: Primärschlüssel des ersten Entitätstyps als Primär- und Fremdschlüssel im zweiten Entitätstyp.
• n:m-Beziehung: Eigene Tabelle mit den Fremdschlüsseln beider Entitätstypen und eigenen Attributen.
• Beziehungen mit eigenen Attributen: Eigene Tabelle für jede Beziehung.

Diese Regeln sorgen dafür, dass das ER-Modell in eine relationale Datenbankstruktur umgewandelt wird, die effektiv und effizient mit den Daten arbeiten kann.

Der Fremdschlüssel steht immer auf der n-Seite der Beziehung. Zum Beispiel 1 Klasse hat n Schüler. In der Schülertabelle steht der Fremschlüssel (KlassenNr = Primärschlüssel von Schule)

• Referenzielle Integrität

Referenzielle Integrität ist eine Regel in relationalen Datenbanken, die sicherstellt, dass Beziehungen zwischen Tabellen konsistent bleiben.

Konkret bedeutet das: Ein Fremdschlüssel (Foreign Key) in einer Tabelle muss immer auf einen gültigen Primärschlüssel in einer anderen (oder derselben) Tabelle verweisen.

For example, if an orders table has a customer_id foreign key, referential integrity ensures that every customer_id exists in the customers table — you can't insert an order for a non-existent customer, and you can't delete a customer that's still referenced in orders (unless handled explicitly).

Normalisierung (erste 3 Normalformen):

Erste Normalform (1NF)

info

Definition: Eine Relation ist in der ersten Normalform, wenn alle Attribute nur atomare Werte enthalten.

Diese Definition besagt, dass alle Attribute nur einfache Attributwerte enthalten dürfen. Dies wird wir aber bereits bei der Definition einer (normalisierten) Relation gefordert. Damit sind alle Relationen automatisch in der ersten Normalform!

info

Die Definition der ersten Normalform ist historisch bedingt, da E. F. Codd in der Originaldefinition einer Relation erlaubt hatte, dass eine Relation auch nicht atomare Attribute enthalten darf.

Funktionale Abhängigkeit

Die Qualität einer Relation hängt wesentlich von den internen Zusammenhängen zwischen den einzelnen Attributen ab. Wir befassen uns daher mit diesen Zusammenhängen, um daraus weitere Normalformen abzuleiten. Folgende Definition beschreibt die Abhängigkeiten der einzelnen Attribute untereinander und ist daher besonders wichtig:

hinweis

Definition: Ein Attribut Y einer Relation R heißt funktional abhängig vom Attribut X derselben Relation, wenn zu jedem X-Wert höchstens ein Y-Wert möglich ist.

Die Definition beschränkt sich nicht auf einzelne singuläre Attribute. X und Y können auch zusammengesetzte Attribute sein. Ist Y von X funktional abhängig, so folgt aus einem X-Wert höchstens ein Y-Wert, und wir schreiben: X->Y

Beispiel:

StudentID und KursID sind der zusammengesetzte Primärschlüssel.

• Note ist vollständig abhängig von beiden Primärschlüsseln, weil man beide braucht, um die Note zu kennen
• Kursnameist nicht vollständig abhängig von beiden Primärschlüssel, weil wir den Kursnamen auch kennen, wenn wir nur die KursID kennen.

Zweite Normalform (2NF)

info

Definition: Eine Relation ist in der zweiten Normalform, wenn sie in der ersten Normalform ist, und jedes Nichtschlüsselattribut voll funktional vom Primärschlüssel abhängt.

3NF: 2NF ist erfüllt und kein Attribut ...Westermann ab S. 591

Definition: Erste Normalform Eine Relation ist in der ersten Normalform, wenn alle zugrunde liegenden Gebiete nur atomare Werte enthalten

Kontrollfragen

• Normalisierung üben.

Welche Aussagen sind richtig und warum?

• Das relationale Datenmodell ist nicht weitverbreitet.

• Die Werte eines Primärschlüssels müssen immer eindeutig sein.

• m:n- Beziehungen erfordern immer eine Kreuztabelle.

• Dateninkonsistenz ist ein gewollter Zustand der Datenbank.

• Ein Primärschlüssel besteht immer nur aus einem Attribut.

• Jede Tabelle muss mindestens einen Fremdschlüssel enthalten.

• Änderungsanomalien können durch Datenredundanz entstehen.

• Was ist referenzielle Integrität und wie wird diese erfüllt?

• Wozu dient ein Fremdschlüssel?

Er sichert die referenzielle Integrität der Daten. Er stellt sicher, dass ein Wert in einer Tabelle nur dann verwendet werden darf, wenn er in einer anderen Tabelle als Primärschlüssel (oder Unique Key) existiert.