STP095: Datenbank-Schemadesign

<p>Es hat nur 83 Folgen gedauert, bis wir wieder auf das Thema kommen. Diesmal soll es nun um Überlegungen zur tatsächlichen Umsetzung von Datenbanken gehen, und auch Tücken im Detail kommen zur Sprache.</p><h2>Shownotes</h2><ul>
<li>
<p>Rückbezug STP012: <a href="de.wikipedia.org/w/index.php?title=Relationale… Datenbanken (RDBMS)</a></p>
<ul>
<li>RDBMS sind <strong>tabellenbasiert</strong>: gleichartige Objekte als <strong>Zeilen</strong> in <strong>Tabellen</strong> abgelegt, deren <strong>Spalten</strong> im Voraus definiert sind -> Zeilen werden auch <strong>Records</strong> (Datensätze) genannt</li>
<li>Rückbezug STP071/072: Tabelle ist eine Liste von Datensätzen, Datensatz ist ein Produkttyp (siehe STP072) von Einzelwerten pro Spalte</li>
<li>RDBMS sind <strong>relational</strong>: Kreuzreferenzen zwischen Tabellen (z.B. Datensatz für Mitarbeiter enthält eine Abteilungsnummer, damit eine Referenz in den entsprechenden Datensatz der Abteilung)</li>
<li>wie in STP012 schon erwähnt: der Entwurf eines guten Datenbankschemas ist eine Kunst (vgl. den Abendgedanken in STP072: Datenstrukturen und Datenfluss als Fundament des Programmentwurfs)</li>
</ul>
</li>
<li>
<p><a href="de.wikipedia.org/w/index.php?title=Normalisier…)&oldid=264921953">Normalisierung</a>: Strukturierung von Datenbankschemata in einer Art und Weise, die Redundanzen reduziert</p>
<ul>
<li>Ziel: keine redundante Speicherung von Informationen (um Platz zu sparen, und um Inkonsistenzen zu vermeiden)</li>
<li>der theoretische Kanon kennt eine Reihe zunehmend strikterer Normalformen: 1NF -> 2NF -> 3NF -> BCNF -> 4NF -> 5NF</li>
<li>Diskussion anhand der Beispiele aus dem verlinkten Wikipedia-Artikel</li>
<li>übergreifendes Motiv: sollte man sich mal klar machen, aber Xyrill wird (anders als der Wikipedia-Artikel) an einigen Stellen Gegenrede leisten</li>
</ul>
</li>
<li>
<p>erste Normalform (1NF): einzelne Tabellenspalten dürfen nur atomare Werte enthalten, keine strukturierten Datensätze</p>
<ul>
<li>siehe Beispiel: Tabelle "CD-Lieder" mit Spalte "Album", die sowohl Künstler als auch Albumtitel enthält -> in zwei Spalten aufteilen</li>
<li>außerdem: Spalte "Titelliste" enthält eine Liste von Titelnamen -> aufteilen in Spalten "Track" und "Titel", ein Datensatz pro Titel</li>
<li>Begründung in der reinen Lehre: Abfragen nach Teilwerten eines nichtatomaren Attributes werden erschwert</li>
<li>Xyrills Gegenreden:
<ul>
<li>moderne Datenbanken ermöglichen auch ergonomischen Zugriff in strukturierte Spalten (vgl. z.B. <a href="postgresql.org/docs/18/functions-json.html&quo… JSON-Spaltentyp in PostgreSQL</a>)</li>
<li>Denormalisierung kann das Leben einfacher machen, wenn man keine strukturierte Abfrage in die Spalte hinein benötigt (Beispiel: GC-Policies in Keppel)</li>
</ul>
</li>
<li>Xyrills Anekdote: unerwartete Probleme mit numerischen IDs beim Umstieg von MaxDB auf PostgreSQL</li>
</ul>
</li>
<li>
<p>zweite Normalform (2NF): 1NF + keine Spalte außerhalb eines Schlüsselkandidaten hängt funktional von einer echten Teilmenge des Schlüsselkandidaten ab</p>
<ul>
<li>hierbei <strong>Schlüsselkandidat</strong>: ein Satz von Spalten, deren Werte Datensätze eindeutig identifizieren (z.B. bei der Tabelle "CD-Lieder" die Spalten "CD-ID" und "Track") -> beim Schemadesign wird hieraus (meist) ein Kandidat zum <strong>Primärschlüssel</strong> gewählt (Beispiel: in Dateisystemen ist der vollständige Pfad ein Schlüsselkandidat, aber in der Praxis ist meist die Inode-Nummer der bevorzugte Schlüssel)</li>
<li>siehe Beispiel: Tabelle "CD-Lieder" mit Spalte "CD-ID" und "Track", aber Spalten mit Informationen zum Album (z.B. "Interpret" und "Albumtitel") hängen nur von der CD-ID ab, nicht vom Track</li>
<li>damit unnötige Duplikation in diesen Spalten zwischen Datensätzen betreffend dieselbe CD, sowie Risiko von Inkonsistenz zwischen diesen Datensätzen</li>
<li>Lösung: Aufspaltung in zwei Tabellen "CDs" und "Lieder", letzteres mit Bezug auf die CD-ID</li>
</ul>
</li>
<li>
<p>dritte Normalform (3NF): 2NF + keine Nichtschlüsselspalten hängen untereinander funktional ab</p>
<ul>
<li>siehe Beispiel: Tabelle "CD" mit Spalten "Interpret" und "Gründungsjahr", aber das Gründungsjahr hängt vom Interpreten ab -> wiederum unnötige Duplikation und Risiko von Inkonsistenzen</li>
<li>Lösung: Abspaltung in eine separate Tabelle "Künstler", möglicherweise unter Einführung eines neuen synthetischen Schlüssels</li>
</ul>
</li>
<li>
<p>weitere Normalformen: Boyce-Codd-Normalform (BCNF), 4. Normalform (4NF), 5. Normalform (5NF)</p>
<ul>
<li>Xyrills Gegenrede: die Beispiel werden zunehmend esoterisch und es sieht danach aus, dass hier vor allem akademische Probleme gelöst werden</li>
<li>ttimeless's Gegenrede: nicht die Kreativität der Nutzer:innen unterschätzen</li>
<li>vielleicht als allgemeines Prinzip: beim Design immer erst einen Primärschlüssel wählen und sich dann bei jedem neuen Attribut fragen, zu welchem Schlüssel dieses gehört -> wenn keine eindeutige Antwort möglich, ist wohl eine neue Tabelle erforderlich (z.B. häufig für M:N-Relationen)</li>
</ul>
</li>
</ul>