Der logische Datenbankentwurf mit dem Relationenmodell

Im logischen Modell legen wir uns fest, wie die logische Verknüpfung der Daten untereinander umgesetzt werden soll. Im Relationenmodell erfolgt dies über Schlüsselattribute. Dieser Artikel erklärt die unterschiedlichen Wege, Schlüsselattribute zu bestimmen, die Transformationsregeln, um die Beziehungstypen des Entity-Relationship-Modells in Schlüsselbeziehungen umzusetzen, führt Constraints ein, die Attributen im logischen Modell zugeordnet werden, und zeigt an Beispielen, wie man aus einem Anforderungstext oder einem Beleg ein Relationenmodell in der dritten Normalform entwickelt.

Anomalien und deren Vermeidung durch Normalisierung eines Relationenschemas

Bei einem schlechten Design einer Datenbank werden Informationen mehrfach gespeichert (Redundanz) – und es ergeben sich schnell Inkonsistenzen beim Einfügen, Aktualisieren und Löschen von Daten – die „Anomalien“. Eine Best-Practice-Sammlung, um dies durch Design zu verhindern, stellen die Normalformen dar. Dieser Artikel beschreibt die erste (1NF, Atomarität), zweite (2NF, Unabhängigkeit der Attribute von Teilschlüsseln) und dritte (3NF, Unabhängigkeit von Nichtschlüsselattributen) Normalform und die Schritte, wie man ein Relationenschema entsprechend umwandelt.

Metrik der Komplexität eines Algorithmus: Die McCabe-Zahl (Zyklomatische Komplexität)

Die Zyklomatische Komplexität (McCabe-Zahl) gibt ein Maß für die Wartbarkeit von Code an. Sie kann auf verschiedene Arten bestimmt werden (binäre Verzweigungen, Anzahl Pfade, Anzahl Knoten und Kanten). Sie kann als Indikator für zu hohe Komplexität innerhalb von Methoden genutzt werden, kann aber objektorientierte Komplexität nicht detektieren.

Algorithmen mit Pseudocode dokumentieren

Die Dokumentation oder der Entwurf von Algorithmen soll häufig unabhängig von einer spezifischen Programmiersprache erfolgen. Eine Möglichkeit ist es, Pseudocode zu verwenden. Vier verbreitete Pseudocode-Notationen werden hier dargestellt: JANA, Pseudo-Pascal, eine deutsche Variante von Pseudo-Pascal und Pseudo-Python. Eine Schnellübersicht stellt die Schlüsselwörter gegenüber, die Beispiele lassen sich über Registerkarten zwischen den Notationen umschalten. Zum Schluss geht es um alternative Schreibweisen und typische Fehler beim Lesen von Pseudocode.

UML Anwendungsfalldiagramm (Use Case Diagram)

Mit UML-Anwendungsfall-Diagrammen können Übersichten erstellt werden, welchen Nutzen ein System den Benutzer*innen zur Verfügung stellt. Das einfache Diagramm bietet wenig Notationsmittel, mithilfe derer Beziehungen dargestellt werden: zwischen Nutzergruppen, zwischen Anwendungsfällen und von Nutzenden zu Anwendungsfällen. Dieser Artikel stellt diese UML-Notationen vor, zeigt, wie Du aus einem Anforderungstext Schritt für Schritt ein Diagramm entwickelst, und sammelt typische Fehler.

Anwendungsfall (Use Case)

Anwendungsfälle stellen den Nutzen, den ein System für Benutzer*innen bereitstellt, in das Zentrum der Betrachtung. Mit ihnen können Anforderungen identifiziert und (tabellarisch oder als Diagramm) dokumentiert werden.

Anforderungsanalyse (requirement engineering)

Viele Projekte scheitern daran, dass nie hinreichend definiert wurde, was eigentlich die Ziele sein sollen. Wie kann eine systematische Anforderungsanalyse aussehen? Der Artikel erklärt, was Anforderungen sind, wie Du funktionale und nichtfunktionale Anforderungen (Qualitätsanforderungen und Randbedingungen) sicher unterscheidest, wie Du sie mit Bezug zur Situation beschreibst und prüfbar formulierst und welche typischen Fehler Du dabei vermeiden solltest.

Kategorien