PHP

Die Basics beherrschen

Grundlagen des relationalen Datenbankdesigns – kompakt und klar
Keine Kommentare

PHP kann gut mit Datenbanken. Das ist eine altbekannte Weisheit. Gelegentlich muss bei einer neuen Businessapplikation auch die Datenwelt konzipiert und erstellt werden. Voraussetzung ist, dass man die Grundlagen des Datenbankentwurfs beherrscht. Sie denken, das sei ein alter Hut. Vielleicht, sofern Sie mit der dritten Normalform und transitiven Abhängigkeiten bestens vertraut sind. Alle anderen lesen jetzt weiter.

Datenbanken spielen insbesondere bei betrieblichen Anwendungssystemen eine wichtige Rolle. Im Idealfall existiert die Datenbank schon und man muss sich nur um die Ankopplung aus einem neuen Anwendungssystem kümmern. Dynamische Webapplikationen auf der Basis von PHP arbeiten sehr häufig mit relationalen Datenbanken zusammen. Unzählige Geschäftsanwendungen basieren auf der Architektur einer serverseitigen dynamischen Webapplikation, die ihrerseits auf eine Datenbank zugreift. Gelegentlich ist man als Entwickler auch gefordert, eine neue Datenbank zu entwerfen und umzusetzen. Hat man das sehr lange nicht gemacht, muss man sich oft erst wieder mit den Basics beschäftigen. Diese sind zunächst weniger technischer Natur, sondern mehr konzeptionell. Genau hier setzt dieser Artikel an und frischt die Grundlagen des relationalen Datenbankentwurfs und -designs auf. Beginnen wir mit wichtigen Begriffen, die auch in Fachkreisen immer wieder durcheinandergewürfelt werden.

Begriffe rund um die Datenwelt

Beantworten wir zunächst die Frage: Was ist eine Datenbank? Die korrekte Antwort könnte wie folgt lauten: Eine Datenbank ist eine Sammlung von Daten, die von einem Datenbankmanagementsystem (DBMS) verwaltet wird. Dazu betrachten wir Abbildung 1.

Abb. 1: Komponenten eines Datenbanksystems

Abb. 1: Komponenten eines Datenbanksystems

Der Ort, an dem die eigentlichen Daten gesammelt werden, wird als Datenbank bezeichnet. Eine solche Datenbank kann zum Beispiel aus einzelnen Tabellen bestehen, in diesem Fall handelt es sich um eine relationale Datenbank. In welcher Form die Daten in der Datenbank abgelegt werden, muss auch definiert und beschrieben werden. Es handelt sich um die Metadaten. Die Metadaten sind also die Datenbank zur Datenbank. Auf die Datenbank selbst wird durch die Anwendungsprogramme zugegriffen. Das geschieht ausschließlich über das so genannte Datenbankmanagementsystem (DBMS). Das DBMS stellt gewissermaßen die Schnittstelle zwischen den Anwendungsprogrammen und der Datenbank dar. Auf Seiten der Datenbank erfolgt der Zugriff über standardisierte Schnittstellen, zum Beispiel mit Hilfe der Abfragesprache SQL. Die Anwendungsprogramme senden ihrerseits ihre Anfragen an das DBMS, und diese werden dann an die Datenbank weitergeleitet. So entsteht eine maximale Entkopplung von Anwendungssoftware und Datenbank, d. h. man kann sowohl die Datenbank oder auch die Anwendungssoftware verändern, aktualisieren oder sogar austauschen. Das Gesamtsystem ist das Datenbanksystem.

Anforderungen an eine Datenbank

An eine Datenbank werden üblicherweise die folgenden Anforderungen gestellt:

  • Datenunabhängigkeit: Die Anwendungsprogramme und das System zur Datenhaltung sollen voneinander unabhängig sein. Beide Systeme werden separat entwickelt und gewartet. Programme können ausgetauscht werden, ohne dass es Auswirkungen auf die Datenbank hat. Ebenso kann man das System zur Datenhaltung anpassen. Sofern die Schnittstellen identisch sind, hat es keine Auswirkungen auf die Programme.
  • Effizienter Zugriff: Die Daten müssen so in der Datenbank abgelegt werden, dass man damit effizient arbeiten kann. Mit anderen Worten: Eine Datenbank, die Millionen von Kundendaten enthält, braucht ein durchdachtes System zur Datenablage. Zum Beispiel können die Datensätze nach dem Namen sortiert gespeichert werden. Nur dann gelingt es dem DBMS, die relevanten Informationen schnell zu finden.
  • Gemeinsame Datenbasis: Alle Daten innerhalb einer Datenbank werden zentral abgelegt.
  • Paralleler Zugriff: Mehrere Benutzer oder Programme sollen parallel mit der Datenbank bzw. den darin gespeicherten Daten arbeiten können. Das DBMS muss in der Lage sein, mit diesen parallelen Zugriffen umzugehen. Ein Beispiel: Sowohl Programm A als auch Programm B wollen den Datensatz des Kunden Müller anpassen.
  • Datensicherheit: Ein DBMS muss regeln, welche Programme und Nutzer auf welche Daten zugreifen können. Dazu muss es dezidierte Rechte zuteilen können. Grundlegende Rechte sind beispielsweise Leserecht, Schreibrecht oder Löschrecht. Noch weitergehende Berechtigungen erlauben das Ändern der Datenstruktur.
  • Datenkonsistenz/Datenintegrität: Die Datenbank muss stets in einem gültigen Zustand sein. Verweise innerhalb der Datenbank dürfen nicht ins Leere zeigen. Das DBMS muss sicherstellen, dass Transaktionen, wie das Löschen eines Datensatzes, nicht dazu führen, dass die Datenbank danach Fehler aufweist.
  • Kontrollierte Redundanz: Grundsätzlich ist die mehrfache Speicherung von Informationen nicht wünschenswert, da zum Beispiel Änderungen der Daten an mehreren Stellen gleichzeitig vorgenommen werden müssen. Ein bestimmtes Maß an Redundanz kann jedoch für eine höhere Verarbeitungsgeschwindigkeit zugelassen werden.
  • Wiederherstellung: Das DBMS muss nach einem Fehler ein Back-up- oder ein Rücksetzungsverfahren zur Wiederherstellung einer konsistenten Datenbank anbieten.
  • Abfragesprache: Es muss eine Möglichkeit für die Datenmanipulation existieren. Bei relationalen DBMS ist das meist eine Form der Sprache SQL.

Wie gesagt, handelt es sich um die wesentlichen Anforderungen an eine Datenbank. Für die Erfüllung dieser Anforderungen ist das DBMS zuständig. Es gibt nicht nur einen Ansatz, um eine Datenbank umzusetzen. Die verschiedenen Arten von Datenbanken sind das Thema des nächsten Abschnitts.

Arten von Datenbanken

Ausgangspunkt war das hierarchische Datenmodell, das heute wegen seiner beschränkten Anwendbarkeit kaum noch verwendet wird. Das Netzwerkmodell findet für umfangreiche Datenmengen im Großrechnerbereich seine Anwendung. Am häufigsten wird das relationale Datenmodell eingesetzt. Es ist die Grundlage für die Modellierung fast aller Datenstrukturen im betrieblichen Umfeld. Dass man dieses Datenbankmodell beherrscht, ist ein absolutes Muss. In der jüngeren Vergangenheit wurde oft für die Verwaltung von unstrukturierten Daten auf eine andere Datenstruktur gesetzt. Dafür haben sich die Begriffe objektbasierte Datenbanken oder NoSQL-Datenbanken etabliert. Diese Entwicklungen spielen gerade im Zeitalter der Massendatenverarbeitung und Big Data eine enorme Rolle. Da das relationale Datenbankmodell weiterhin für ein Großteil der Line-of-Business-Applikationen die zentrale Rolle spielt, also die Daten in miteinander verbunden Tabellen gehalten werden, werden wir auf dieses Datenbankmodell gleich näher eingehen. Egal welches Datenbankmodell angewendet wird: Vor der technischen Umsetzung wird ein Konzept benötigt.

Zum Konzept: Schritt für Schritt

Der Aufbau der Datenbank ist nicht in einem Schritt erledigt. Es sind mehrere aufeinanderfolgende Phasen (Abb. 2) zu durchlaufen:

  • Externe Phase: Zunächst geht es um die Ermittlung der Informationsstruktur. Die Datenbank soll einen Ausschnitt aus der realen Welt abbilden. Das erfolgt durch die Beschreibung der Daten. Dazu ist der Informationsbedarf der Benutzer zu ermitteln und zu strukturieren. Das Ergebnis dieses ersten Schritts wird als Spezifikations- und Anforderungsanalyse bezeichnet. Es ist eine informelle Beschreibung des Fachproblems. Mit anderen Worten: Welche Daten sollen in der Datenbank verwaltet werden? Zum Beispiel: Daten von Projekten und Daten von Mitarbeitern. Welche Attribute umfassen diese Daten genau? Zum Beispiel: Für die Mitarbeiterdaten müssen der Name, der Vorname, die Personalnummer und die Anzahl der Arbeitsstunden gespeichert werden. Es gilt, den darzustellenden Ausschnitt aus der realen Welt möglichst exakt zu beschreiben. In der externen Phase werden die konkreten Anforderungen an die Datenbank zusammengetragen.
  • Konzeptionelle Phase: In diesem Schritt wird ein systematisches Modell zur Datenbank aufgestellt. Dabei handelt es sich um eine formalisierte Darstellung, zum Beispiel in grafischer Form. Es existieren verschiedene Ansätze zur Erzeugung einer solchen Gesamtsicht. Das bekannteste Modell ist das so genannte Entity-Relationship-(ER-)Modell. Ergebnis dieses Schritts ist das Fachkonzept der Datenbank, das die Beziehungen zwischen den Datenelementen abbildet. Zum Beispiel kann man in einem solchen ER-Modell erkennen, dass es Daten für Mitarbeiter und Daten für Projekte gibt. Die Verbindung dazwischen wird über die Daten zu den einzelnen Projekten realisiert.
  • Logische Phase: Im Vordergrund steht die Erstellung des logischen Datenmodells, zum Beispiel ein relationales Datenmodell (Tabellenform). Ausgangspunkt ist das zuvor erstellte konzeptionelle Schema. Der Übergang vom ER-Modell in die Tabellenform kann teilweise automatisiert werden. Das Ergebnis muss dann in der Regel noch optimiert werden, zum Beispiel durch Normalisierung der Datenbank. Auf das Thema Normalisierung kommen wir später nochmals zurück.
  • Physische Phase: Erst nach diesen vorbereitenden Maßnahmen geht es darum, die Datenbank zu implementieren. Am Ende dieser Phase sollte die leere Datenbank existieren. Dazu sollte das logische Modell unter Verwendung einer Datendefinitionssprache in ein konkretes Datenbankschema übersetzt werden. Es müssen Datentypen, Wertebereiche, Relationen usw. festgelegt werden.

Natürlich kann man bei einfachen Datenstrukturen die theoretischen Schritte (externe, konzeptionelle und logische Phase) zusammenfassen und schneller zur technischen Umsetzung voranschreiten. Das wird in der Praxis auch gemacht. Einfache Datenbanken kann man mit einem Werkzeug direkt in eine passende Tabellenstruktur pressen. Wichtig ist jedoch zu wissen, dass spätere Änderungen in der Struktur der Datenbank nur mit viel Aufwand vorgenommen werden können. Es lohnt sich also, die vorbereitenden Maßnahmen sorgfältig abzuarbeiten.

Abb. 2: Phasen des Datenbankentwurfs

Abb. 2: Phasen des Datenbankentwurfs

 

Daten in Tabellen

Denkt man an Datenbanken, assoziiert man meist die Ablage der Daten in Tabellen. Diese Form der Datenspeicherung ist für viele Einsatzgebiete passend und war auch schon im vordigitalen Zeitalter gebräuchlich. Denken Sie in diesem Zusammenhang zum Beispiel an die sortierte Datenablage in Form von Karteikarten. Eine Karteikarte ist dabei nichts anders als ein Datensatz. Das relationale Modell basiert auf den folgenden Elementen:

  • Relationen, was hier gleichbedeutend mit Tabellen ist
  • Operatoren, d. h. Rechenoperationen für Tabellen
  • Regeln, d. h. Bedingungen für die Werte bestimmter Spalten

Der allgemeine Aufbau einer Tabelle für eine relationale Datenbank ist in Abbildung 3 zu sehen.

Abb. 3: Aufbau einer Tabelle für ein relationales Datenbankmodell

Abb. 3: Aufbau einer Tabelle für ein relationales Datenbankmodell

Auch eine Tabelle für das relationale Datenbankmodell besteht aus Zeilen und Spalten. Eine Tabelle bezeichnet man auch als Relation, daher der Name relationales Datenbanksystem. Eine relationale Datenbank enthält mindestens eine Tabelle, in der Regel jedoch mehrere, die untereinander in Beziehung stehen. Datensätze sind in Zeilen angeordnet. Ein Datensatz bezeichnet man als Tupel. Für eine Relation (Tabelle) gelten die folgenden Bedingungen, damit die Datenstruktur gültig ist:

  • keine doppelten Datensätze
  • beliebige Reihenfolge der Datensätze
  • beliebige Reihenfolge der Attribute
  • Attributwerte sind atomar, das heißt, es steht in jeder Spalte nur ein Wert.

Jedes Attribut einer Datenbanktabelle muss einen Datentyp (Text, Zahl, …) aufweisen. Die möglichen Datentypen unterscheiden sich von System zu System. Daher kann eine vollständige Kompatibilität der Datenbanken untereinander nicht gewährleistet werden. Das ist insbesondere bei einem Wechsel der Datenbank und beim Import von Daten aus einem anderen System zu beachten. Die Tabellen einer relationalen Datenbank stehen untereinander in Beziehung. Es existieren folgende Beziehungstypen: (1:1), (1:n) und (n:m). Sehen wir uns diese nacheinander an:

  • 1:1-Beziehung: Es existiert für jeden Datensatz in Tabelle 1 genau ein Datensatz in Tabelle 2. Eigentlich weist diese Art von Beziehung darauf hin, dass die Tabellen zusammengeführt werden können. Wir könnten die Spalten von Tabelle 2 neben den Spalten von Tabelle 1 notieren und würden eine große Tabelle erhalten. Dennoch können Gründe existieren, die eine 1:1-Beziehung rechtfertigen, beispielsweise Sicherheit und Performance. Sollen bestimmte Daten besonders vor dem Zugriff geschützt werden, können sie in eine eigene Tabelle ausgelagert werden. Ganze Tabellen lassen sich bezüglich der Benutzerrechte besser schützen als einzelne Tabellenspalten. Bei sehr großen Datenbanken kann es sinnvoll sein, weniger benutzte Daten auszulagern. Das steigert die Zugriffsgeschwindigkeit auf die restlichen Daten. Das DBMS muss dann nur mit den betreffenden Datenausschnitt arbeiten. Zusammengefasst: Eine 1:1 Beziehung macht aus Sicht der Datenbanktheorie keinen Sinn, sie kann jedoch aus praktischen Erwägungen angezeigt sein.
  • 1:n-Beziehung: Diese ist dadurch gekennzeichnet, dass zu einem Datensatz in der einen Tabelle beliebig viele Datensätze in der anderen Tabelle existieren. Nehmen wir an, wir modellieren die Beziehung zwischen Kunden (Tabelle: Kunde) und Bestellungen (Tabelle: Bestellung). Dabei kann ein Kunde keine, eine oder mehrere Bestellungen auslösen.
  • n:m-Beziehung: Jedem Datensatz aus Tabelle 1 sind null bis beliebig viele Datensätze in Tabelle 2 zugeordnet. Andererseits sind auch jedem Datensatz aus Tabelle 2 null bis beliebig viele Datensätze in Tabelle 1 zugeordnet. Auch dazu ein Beispiel: Tabelle 1 umfasst die Angaben zu den Studierenden und Tabelle 2 die Angaben zu den Kursen einer Universität. Jeder Studierende kann seinerseits keinen, einen oder mehrere Kurse belegen. Andererseits können einem Kurs kein, ein oder mehrere Studierende zugeordnet sein. Für die Modellierung in einer Datenbank ist diese Art von Beziehung zu komplex, als dass wir sie direkt mit Hilfe von zwei Tabellen abbilden könnten. Derartige Beziehungen gilt es unter Inanspruchnahme einer Hilfstabelle aufzulösen. Aus einer n:m-Beziehung werden in diesem Sinne zwei 1:n-Beziehungen.

Grundsätzlich gilt, dass jeder Datensatz (jede Zeile) einer Tabelle eindeutig zu identifizieren sein muss. Das geschieht über einen eindeutigen Schlüssel.

Schlüsselfragen

Über Schlüssel werden Datensätze identifiziert. Darüber kann man Suchabfragen erledigen und Beziehungen zwischen Tabellen herstellen. Man unterscheidet Primär-, Sekundär- und Fremdschlüssel. Mit Hilfe des Primärschlüssels kann ein Datensatz eindeutig identifiziert werden. Es gibt natürliche und künstliche Primärschlüssel. Ein natürlicher Primärschlüssel ist bereits Bestandteil des Datensatzes. Es handelt sich um ein Attribut oder um eine Attributkombination. Ein Attribut, zum Beispiel die Spalte Name der Tabelle Kunde, ist oft nicht ausreichend für eine eindeutige Identifikation. Der Grund: Viele Namen treten mehrfach auf. Damit die Eindeutigkeit sichergestellt ist, kann man mehrere Attribute zu einem Primärschlüssel kombinieren. Für die Tabelle Kunde könnte man zum Beispiel die Attribute Name, Vorname und Geburtsdatum kombinieren. Hier steigt die Wahrscheinlichkeit, dass jeder Datensatz der Tabelle über diesen kombinierten Schlüssel eindeutig identifizierbar ist. Eine Garantie ist aber nicht möglich. Ebenso sind Primärschlüssel, die aus der Kombination mehrerer Attribute bestehen, in der praktischen Verarbeitung nicht sehr einfach. Um diesen Nachteilen entgegenzuwirken, verwendet man meist einen künstlichen Schlüssel. Dieser wird oft in Form eines numerischen oder alphanumerischen Werts als zusätzliches Attribut in die Tabelle eingefügt. Der wichtigste Vorteil besteht darin, dass man die Einmaligkeit für jeden Datensatz und damit dessen eindeutige Identifizierung sicherstellen kann. Typische Beispiele solcher künstlichen Primärschlüssel sind die KundenNummer oder ArtikelNummer.

International PHP Conference

Entwickler – das verlorene Handbuch

by Stefan Priebsch (thePHP.cc)

My browser does what?

by Joel Lord (Red Hat OpenShift)

JavaScript Days 2019

Einführung in Node.js

mit Golo Roden (the native web)

Concepts of the modern Web

mit Sven Kölpin (OPEN KNOWLEDGE)


Beim Einfügen eines neuen Datensatzes wird vom DBMS automatisch ein neuer Wert für den Primärschlüssel vergeben. Indem man die Werte der Primärschlüssel über alle neuen Datensätze zum Beispiel fortlaufend vergibt, kann man sicherstellen, dass der aktuelle Wert noch nicht existiert. Ein künstlicher Primärschlüssel bietet noch einen weiteren Vorteil: Er kann so aufgebaut werden, dass man inhaltliche Informationen im Aufbau des Schlüssels integriert, die für den menschlichen Leser interessant sind. Zum Beispiel kann man beim Schlüssel RechnungsNummer das aktuelle Jahr integrieren. Für die Tabelle Rechnung wurde ein künstlicher Primärschlüssel der folgenden Form verwendet: JJJJMMXXXX. Erst erfolgen die vierstellige Angabe des Jahres und die zweistellige Bezeichnung des Monats, dann folgt die Nummer der Rechnung. Eine RechnungsNummer = 2019030207 sagt also Folgendes aus: Die Rechnung wurde im März gestellt, und es handelt sich um die Rechnung Nummer 207 des Jahres 2019.

Um Beziehungen zwischen Tabellen herzustellen, benötigt man Fremdschlüssel. Es handelt sich ebenso um ein Attribut der Tabelle (nicht der Primärschlüssel) und verweist auf eine zweite Tabelle. In der zweiten Tabelle fungiert das Attribut dann als Primärschlüssel. Auch dazu ein Beispiel: Unsere Datenbank besteht aus den beiden Tabellen Künstler und Bild. Zwischen den beiden Tabellen besteht eine (1:N)-Beziehung, ein Künstler kann also ein oder mehrere Bilder geschaffen haben. Im Fall einer Schaffenskrise hat er vielleicht aktuell kein Bild gemalt. Die Tabelle Künstler enthält als Attribute die persönlichen Angaben der Person (Name, Adresse, …) und als künstlicher Primärschlüssel fungiert das Attribut KünstlerID. Die Tabelle Bild enthält die Rahmendaten der Kunstwerke (Titel, Preis, …). Das Attribut BildNr ist in dieser Tabelle der Primärschlüssel. Die Beziehung zwischen beiden Tabellen wird über das gemeinsam verwendete Attribut KünstlerID hergestellt. Dazu wird der Primärschlüssel aus der Tabelle Künstler als Fremdschlüssel in die Tabelle Bild importiert. Wir können es auch so sagen: Einträge in der Spalte KünstlerID der Tabelle Bild verweisen auf die Tabelle Künstler.

Ein Fremdschlüssel ist demnach ein Attribut, das sich auf einen Wert des Primärschlüssels einer anderen Relation bezieht. Die Relation mit dem Primärschlüssel bezeichnet man als Masterrelation. Die Relation mit dem Fremdschlüssel ist Detailrelation. Sie ist von der Masterrelation abhängig. Diese Abhängigkeit hat eine besondere Bedeutung, und zwar muss gelten: Für jeden Wert des Fremdschlüssels muss auch ein Wert in der Masterrelation bestehen. Ist das nicht der Fall, ist die Datenbank fehlerhaft, also in einem inkonsistenten Zustand. Das könnte passieren, wenn es möglich wäre, einen Datensatz aus der Masterrelation zu löschen, ohne zu prüfen, ob mit diesem Datensatz weitere Datensätze in einer oder mehreren Detailrelationen verbunden sind. Dieser gültige Zustand einer relationalen Datenbank wird als referenzielle Integrität bezeichnet.

Mit Hilfe eines Sekundärschlüssels, auch als Sekundärindex bezeichnet, werden Datensätze in einer Tabelle schneller gefunden. Wird kein Sekundärschlüssel angelegt und muss innerhalb einer Tabelle nach einem bestimmten Attributwert gesucht werden, sind alle Datensätze der Reihe nach zu durchsuchen. Bei großen Datenbeständen kann das eine sehr lange Antwortzeit bedeuten. Wird ein Sekundärschlüssel angelegt, erstellt das Datenbanksystem dazu eine neue Indextabelle, die nach dem gewünschten Kriterium sortiert ist. Bei einer Suche genügt ein Zugriff auf diese Indextabelle, wo wiederum mit einem Querverweis auf den eigentlichen Datensatz in der Haupttabelle verwiesen wird. Sekundärschlüssel werden für häufig vorkommende Suchanfragen eingerichtet, die über die Primärschlüssel nicht bedient werden können.

Normalisierung

Ein wesentlicher Schritt bei der Festlegung der Datenbankstruktur ist die Normalisierung. Damit sollen hauptsächlich Redundanzen in den Daten beseitigt werden. Nachfolgend beschreiben wir diesen Prozess mit Hilfe eines einfachen Beispiels. Das Prinzip ist jedoch auf komplexere Zusammenhänge übertragbar. Lediglich die Zahl der Attribute und Tabellen steigt. Im Beispiel geht es um die Zuordnung von Mitarbeitern zu Projekten und die zugehörigen Arbeitsstunden. Die Daten liegen zunächst in der so genannten Rohform vor (Tabelle 1).

P# P_Name Abt# Abt-Name Pj# Pj-Name Pj-Std
101 Müller 1 Motoren 11, 12 A, B 60, 40
102 Meier 2 Karosserie 13 C 100
103 Krause 2 Karosserie 11, 12, 13 A, B, C 20, 50, 30
104 Schmidt 1 Motoren 11, 13 A, c 80, 20

Tabelle 1: Die Ausgangsdaten zur Projektverwaltung

Das liest sich wie folgt (Zeile 1, Tabelle 1): Herr Müller mit der Personalnummer P# = 101 arbeitet in der Abteilung Motoren. Es ist die Abteilung mit der Nummer Abt# = 1. Er ist den Projekten A und B mit den Projektnummern P# = 11 und P# = 12 mit jeweils 60 bzw. 40 Stunden zugeordnet.

Typisch für unbearbeitete Daten ist zum Beispiel, dass die Einträge in den Spalten mehrere Werte enthalten, zum Beispiel Spalte Pj# mit den Werten 11 und 12. Als Erstes gilt es, das zu beseitigen. In jeder Zeile (Datensatz) sollte in jeder Spalte nur jeweils ein Eintrag stehen. Man sagt auch, die Attribute müssen atomar sein. Ist das erreicht, liegt die erste Normalform (1NF) vor (Tabelle 2).

P# P_Name Abt# Abt-Name Pj# Pj-Name Pj-Std
101 Müller 1 Motoren 11 A 60
101 Müller 1 Motoren 12 B 40
102 Meier 2 Karosserie 13 C 100
103 Krause 2 Karosserie 11 A 20
103 Krause 2 Karosserie 12 B 50
103 Krause 2 Karosserie 13 C 30
104 Schmidt 1 Motoren 11 A 80
104 Schmidt 1 Motoren 13 C 20

Tabelle 2: Die erste Normalform (1NF)

Ein erstes Problem in der Datenbankstruktur wurde beseitigt, dennoch sind noch einige Nachteile vorhanden: Die Redundanz hat zugenommen, beispielsweise weist die Tabelle zu P# = 101 (Müller) nun drei Datensätze auf, die sich nur in wenigen Eigenschaften unterscheiden. Weiterhin genügt der bisherige Primärschlüssel (P#) nicht mehr zur eindeutigen Identifizierung. Er muss erweitert werden. Ein neues Ziel ist das Erreichen der zweiten Normalform, die wie folgt definiert ist: Eine Relation befindet sich in der zweiten Normalform (2NF), wenn sie in der ersten Normalform ist und jedes Nichtschlüsselattribut vom Primärschlüssel voll funktional abhängig ist.

Wie kann man nun feststellen, ob diese Bedingung verletzt wurde? Wenn ein Attribut, das nicht zum Schlüssel gehört, eindeutig durch einen Teil des Schlüssels identifiziert wird, liegt keine 2NF vor. Das Ergebnis des zweiten Schritts der Normalisierung sehen Sie in den Tabellen 3, 4 und 5.

P# P-Name Abt# Abt-Name
101 Müller 1 Motoren
102 Maier 2 Karosserie
103 Krause 2 Karosserie
104 Schmidt 1 Motoren

Tabelle 3: Zweite Normalform (2NF), Tabelle: Personal

Pj# Pj-Name
11 A
12 B
13 C

Tabelle 4: Zweite Normalform (2NF), Tabelle: Projekt

P# Pj# Pj-Std
101 11 60
101 12 40
102 13 100
103 11 20
103 12 50
103 13 30
104 11 80
104 13 20

Tabelle 5: Zweite Normalform (2NF), Tabelle: Personal-Projekt

Die zweite Normalform weist nun mehrere Relationen (Tabellen) auf. Wir haben die Tabellen Personal und Projekt. Die Verbindung zwischen diesen Objekten wird über die Relation Personal-Projekt (Tabelle 5) hergestellt. Die Qualität ist gestiegen, dennoch sind wir noch nicht zufrieden. Auch jetzt haben wir noch nicht alle Redundanzen beseitigt. Ein Blick in die Relation Personal bestätigt dies. Mehrfach kommt die gleiche Kombination aus Abt# und Abt.-Name (zum Beispiel 1, Motoren) vor. Um das zu verhindern, ist der Übergang zur dritten Normalform durchzuführen. Diese ist wie folgt definiert: Die Relation befindet sich in der dritten Normalform (3NF), wenn sie sich in der 2NF befindet und jedes Nichtschlüsselattribut nichttransitiv vom Primärschlüssel abhängig ist, d. h. aus keinem Nichtschlüsselattribut folgt ein anderes Nichtschlüsselattribut. In Bezug auf unser Beispiel und die Relation Personal (Tabelle 3) gilt:

  • aus P# folgt P-Name
  • aus P# folgt Abt#
  • aus P# folgt Abt.Name

Das bedeutet, aus dem Primärschlüssel folgen sämtliche anderen Attribute. Jedoch gilt auch zusätzlich:

  • Abt# folgt Abt.Name

Es liegt eine so genannte transitive Abhängigkeit vor, d. h. der Name der Abteilung (Abt.Name) kann direkt aus dem Primärschlüssel (P#) geschlossen werden bzw. alternativ aus dem Attribut Abt#. Das führt zu einer Redundanz in der Datenstruktur, die zu beseitigen ist. Das Ziel der dritten Normalform erreichen wir mittels einer weiteren Relation (Tabellen 6, 7, 8 und 9).

P# P-Name Abt#
101 Müller 1
102 Maier 2
103 Krause 2
104 Schmidt 1

Tabelle 6: Dritte Normalform, Tabelle: Personal

Abt# Abt-Name
1 Motoren
2 Karosserie

Tabelle 7: Dritte Normalform, Tabelle: Abteilung

Pj# Pj-Name
11 A
12 B
13 C

Tabelle 8: Dritte Normalform, Tabelle: Projekt

P# Pj# Pj-Std
 101 11 60
 101 12 40
 102 13 100
 103 11 20
 103 12 50
 103 13 30
 104 11 80
104 13 20

Tabelle 9: Dritte Normalform, Tabelle: Personal-Projekt

Mit dem Erreichen der dritten Normalform sagt man auch: Die Datenbasis ist normalisiert. In der Theorie existieren noch Definitionen für Normalformen höherer Ordnung. Für die meisten Einsatzfälle dürfte jedoch das Erreichen der dritten Normalform ausreichend sein. Wird der Vorgang der Normalisierung zu weit fortgesetzt (Übernormalisierung) so steigt die Komplexität unnötigerweise. Auch das Antwortverhalten kann sich verschlechtern, da bei Abfragen erst eine Vielzahl von Schlüsselverweisen (Primärschlüssel – Fremdschlüssel) ausgewertet werden müssen und die eigentlichen Informationen auf zu viele Tabellen verstreut sind. Daher gilt: Mit Hilfe der Normalisierung sollte ein guter Kompromiss zwischen Systemleistung und Redundanzfreiheit angestrebt werden. Der Einsatz von Werkzeugen aus Datenbanksystemen führt gelegentlich auch zu dieser Übernormalisierung. Es ist Aufgabe des Datenbankdesigners, das zu erkennen und die Arbeit dieser Tools zu bremsen.

Zusammengefasst: Der Prozess der Normalisierung dient dazu, die Konsistenz der Daten zu gewährleisten. Muss man dazu alle beschriebenen Schritte zur Normalisierung durchlaufen? Je nach Qualität der Ausgangsdaten, Komplexität der Datenstruktur und der Erfahrung des Entwicklers kann man die dritte Normalform auch in einem Rutsch erreichen. Ist man jedoch unsicher, ist das schrittweise Vorgehen ein gutes Hilfsmittel.

Datenbanken und PHP

Sie sehen, erst jetzt kommt man zur eigentlichen Implementierung. Nach wie vor wird oft viel zu schnell mit der praktischen Umsetzung gestartet. Die Möglichkeiten der Datenbankanbindung an Webapplikationen in PHP skizziert dieser Abschnitt. PHP bietet bekannterweise mehrere Optionen, um mit Datenbanken zu arbeiten. Bei Verwendung einer MySQL-Datenbank wählt man üblicherweise die Schnittstelle mysqli. Steht also fest, dass mit dem PHP-Programm auch in der Zukunft eine MySQL-Datenbank angesprochen wird, brauchen Sie sich über weitere Schnittstellen keine Gedanken zu machen. Sofern man aber einen Wechsel der Datenbank nicht grundsätzlich ausschließen kann, hat die Festlegung einer spezifizierten Schnittstelle einige Nachteile. Wird auf ein anderes Datenbanksystem gewechselt, müssen die betreffenden Stellen im Quellcode angepasst werden, die für den Datenbankzugriff verantwortlich sind. Um das zu vermeiden, setzt man Abstraktionsklassen ein. Eine solche Abstraktionsklasse sorgt dafür, dass die Programmierung des Datenbankzugriffs grundsätzlich unabhängig von der letztendlich eingesetzten Datenbank erfolgt (Abb. 4).

Abb. 4: Datenbankabstraktion in PHP durch PHP Data Objects [3]

Abb. 4: Datenbankabstraktion in PHP durch PHP Data Objects

Ehrlicherweise muss hinzugefügt werden, dass es auch beim Einsatz einer Abstraktionsklasse notwendig sein kann, beim Wechsel des Datenbanksystems Anpassungen am Quellcode vorzunehmen. Der Grund liegt darin, dass die verschiedenen relationalen Datenbanksysteme zwar grundsätzlich über SQL abgefragt werden, sich jedoch in der Verwendung unterschiedlicher SQL-Dialekte unterscheiden. Dennoch wird der Anpassungsbedarf minimiert. Ebenso sind Abstraktionsklassen stets der kleinste gemeinsame Nenner, um unterschiedliche Datenbanken einheitlich anzusprechen. Ab PHP Version 5.1 gehört PHP Data Objects (PDO) per Standard zur Installation. Um auf die Datenbank zuzugreifen, muss man zum Beispiel in PHP wie folgt vorgehen:

$user = 'root';
  $pass = '';
$db = new PDO('mysql:host=localhost;dbname=meineDatenbank', $user, $pass );

Man instanziiert das PDO-Objekt dann mit der konkreten Datenbankschnittstelle, in diesem Fall mit der mysqli-Schnittstelle. PDO vereinheitlicht dann die Arbeit, also die Abfragen mit der Datenbank. Dabei wird SQL eingesetzt. Das ist jedoch nicht mehr Thema dieses Artikels, denn im Fokus stand die Datenbankkonzeption.

Fazit

Datenbanken bleiben das A und O einer Businessanwendung. Dynamische, serverseitige Webapplikationen auf der Basis von PHP haben vielfältige technische Möglichkeiten, auf Datenbanken zuzugreifen. Existiert noch keine Datenbank, muss in einem ersten Schritt das Konzept dazu entworfen werden. Nach der Ermittlung der Anforderungen ist in der konzeptionellen und logischen Phase die Datenstruktur festzulegen und zu optimieren. Im Fall einer relationalen Datenbank ist die Normalisierung der Tabellenstruktur wichtig. Am Ende wird mit Hilfe von Tools die Datenbank auf dem Server angelegt. Zusammenfassend kann man sagen, dass ein sauberes Konzept für die Datenhaltung für eine Datenbankapplikation essenziell ist. Diese Basics muss man beherrschen, egal ob man fertige Datenbanken anzapft oder ganz von vorn beginnt.

Links & Literatur

[1] Wenz, C.; Hauser, T.: „PHP 7 und MySQL. Das umfassende Handbuch“, Rheinwerk Computing, 2019.

 

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -