Grundlagen von Datenbanken

Datenbanken bilden die Grundlage für die systematische Speicherung und Verwaltung von Daten.

Zentrale Konzepte:

• Ein Primärschlüssel ist ein einzelnes Feld oder eine Kombination von Feldern, dessen Werte innerhalb einer Tabelle einzigartig sind und somit eine bestimmte Zeile eindeutig identifizieren können.
• Der Fremdschlüssel ist ein Attribut einer Tabelle, das auf einen Primärschlüssel in einer anderen Tabelle verweist und dadurch Beziehungen zwischen Tabellen herstellt.

ANSI/SPARC-Modell:

• Bildet die Grundlage moderner Datenbanksysteme
• Beschreibt die Trennung verschiedener Beschreibungsebenen für Datenbankschemata
• Gewährleistet Unabhängigkeit von der Programmiersprache und Hardware

Das 3-Ebenen-Modell:

• Externe Ebene: Stellt unterschiedliche Sichten für verschiedene Benutzer bereit, sodass jeder nur die Daten sehen kann, die für ihn relevant sind.
• Konzeptionelle Ebene: Stellt die logische Struktur der Daten dar und sorgt für Unabhängigkeit zwischen externer und interner Ebene.
• Interne Ebene: Implementiert ein Schema zur physischen Speicherung und Verwaltung von Daten.

Anwendungsbeispiel: In einem Online-Shop könnte ein Artikel-Datensatz den Primärschlüssel "ArtikelID" haben. In der Bestellungstabelle würde dieser als Fremdschlüssel verwendet, um zu speichern, welche Artikel bestellt wurden, ohne alle Artikelinformationen zu duplizieren.

Datenmodelle

Datenmodelle bilden die konzeptionelle Grundlage für die Struktur und Organisation einer Datenbank.

Relationales Modell:

• Verknüpfung durch Primär- und Fremdschlüssel
• Verwendung der Abfragesprache SQL
• Dateneingabe auf Tabellen beschränkt, keine Reihenfolge festgelegt

Hierarchisches Datenmodell:

• Aufgebaut wie ein Baumdiagramm
• Ältestes Datenbankmodell
• Einfacher Zugriff auf zusammengehörige Daten
• Gut für die Verarbeitung von Stücklisten
• Nachteil: Keine n:m-Beziehungen möglich

Netzwerkmodell:

• Bietet mehr Suchwege als das hierarchische Modell
• Die Datenstruktur bestimmt den Aufbau

Objektorientiertes Datenmodell:

• Daten sind nicht in Tabellen aufgeteilt, sondern als Objekte gebündelt
• Jeder Datensatz wird mit allen Attributen gespeichert

Beispiele für Datenmodelle:

• Fahrrad als Oberklasse mit Unterklassen Rennrad, Trekkingbike, Citybike
• Studentenverwaltung mit Tabellen für Studenten und Versicherungen

Praxisbeispiel: In einem Gesundheitssystem wäre das relationale Modell sinnvoll: Eine Tabelle für Studenten $mit ID, Name$, eine für Versicherungen $mit Provider-ID, Name$ und eine Verbindungstabelle, die die Beziehung zwischen Student und Versicherung dokumentiert $mit Student-ID, Provider-ID, Plan-Typ, Startdatum$.

Entity-Relationship-Modell (ER-Modell)

Das Entity-Relationship-Modell $ER-Modell$ ist ein gängiger Standard für die Datenmodellierung und zeigt die Beziehungen zwischen Menschen, Objekten oder anderen Dingen.

Grundelemente des ER-Modells:

• Entitäten: Individuell identifizierbare Objekte der Wirklichkeit, wie z.B. "Spender" mit einem eindeutigen Attribut "Spender-Nr."
• Attribute: Eigenschaften, die im Kontext zu einer Entität stehen, wie etwa "Name", "Vorname", "Straße" für einen Spender
• Beziehungen: Verknüpfungen zwischen zwei oder mehreren Entitäten, wie "hat" zwischen Spender und Spende

Beispiel: Stiftung

In einem ER-Modell für eine Stiftung könnten folgende Elemente enthalten sein:

• Entität "Spender" mit Attributen: Name, Vorname, Straße, PLZ, Ort, IBAN, Spender-Nr.
• Entität "Spende" mit Attributen: Datum, Spender-Nr., Zweck-Nr., Betrag
• Entität "Spendenzweck" mit Attribut: Zweck-Nr.
• Beziehung "hat" zwischen Spender und Spende
• Beziehung "zugewiesen" zwischen Spende und Spendenzweck

Erweitertes ER-Modell: Das erweiterte ER-Modell $EER$ fügt dem Basis-ER-Modell Konzepte wie Vererbung, Spezialisierung und Generalisierung hinzu. So könnte man z.B. "Privatspender" und "Firmenspender" als Spezialisierungen von "Spender" mit jeweils eigenen spezifischen Attributen modellieren.

Datenbankarchitekturen

Verschiedene Arten von Datenbankarchitekturen ermöglichen unterschiedliche Zugriffsmodelle und Anwendungsbereiche.

Stand-Alone-Datenbank:

• Keine Mehrfachzugriffe möglich
• Ein Benutzer, immer für das gleiche Programm
• Beispiel: Adresskarteien
• Sowohl die Datenbank als auch das Datenbankprogramm befinden sich auf einer Workstation

File-Share-Datenbank:

• Datenbankzugriff erfolgt über ein Programmmodul
• Die Datenbank befindet sich auf einem Server
• Das Datenbankprogramm läuft auf jedem einzelnen Client

Client-Server-Datenbank:

• Kern ist der Datenbankserver $Softwaresystem$
• Aufgaben und Dienstleistungen werden innerhalb des Netzwerkes verteilt
• Vorteile: Höhere Sicherheit und bessere Leistung
• Läuft innerhalb des Netzwerks auf einer bestimmten Maschine

ACID-Prinzip:

• Beschreibt Regeln zum effektiven und effizienten Umgang mit Datenbanktransaktionen in relationalen Datenbanksystemen

Wichtige Begriffe:

• Datenbanksystem: System zur elektronischen Datenverwaltung, kapselt die Datenverwaltung
• Datenbankmanagementsystem: Kontrolliert und verwaltet den Datenbestand
• Datenredundanz: Wenn dieselbe Information mehrfach in einer Datenbank vorhanden ist

Leistungsaspekt: In einer Client-Server-Architektur können Anfragen effizienter verarbeitet werden als bei File-Share-Datenbanken, da der Server für Datenbankoperationen optimiert ist und nur die Ergebnisse über das Netzwerk übertragen werden müssen, nicht die gesamten Daten.

Kardinalitäten in Datenbankbeziehungen

Kardinalitäten beschreiben die Anzahl der möglichen Beziehungen zwischen Datensätzen verschiedener Tabellen.

1:1-Beziehung $eins zu eins$:

• Jedem Datensatz der ersten Tabelle ist genau ein Datensatz der zweiten Tabelle zugeordnet.
• Beispiel: Jeder Mitarbeiter hat genau ein Gehalt und jedes Gehalt gehört zu genau einem Mitarbeiter.

Beispieltabellen für 1:1-Beziehung:

• Tabelle "Mitarbeiter" mit Primärschlüssel "MitarbeiterNr" und Fremdschlüssel "GehaltsNr"
• Tabelle "Gehalt" mit Primärschlüssel "GehaltsNr" und Attribut "Betrag"

1:n-Beziehung $eins zu viele$:

• Ein Datensatz der ersten Tabelle kann mit keinem, einem oder mehreren Datensätzen der zweiten Tabelle in Beziehung stehen.
• Beispiel: Jeder Mitarbeiter gehört genau einer Abteilung, aber eine Abteilung kann mehrere Mitarbeiter haben.

Beispieltabellen für 1:n-Beziehung:

• Tabelle "Mitarbeiter" mit Primärschlüssel "MitarbeiterNr", Attribut "Name" und Fremdschlüssel "AbteilungsNr"
• Tabelle "Abteilung" mit Primärschlüssel "AbteilungsNr" und Attribut "Name"

Optionalität: Bei der Definition von Beziehungen kann auch die Optionalität festgelegt werden – ob eine Beziehung verpflichtend oder optional ist. Zum Beispiel könnte ein Mitarbeiter zwingend einer Abteilung zugeordnet sein $NOT NULL-Constraint für AbteilungsNr$, oder es könnte optional sein $NULL erlaubt für AbteilungsNr$.