Aufgabe: Datenbankdesign
Diese Aufgabe beschreibt, wie eine Datenbank entworfen wird, um Persistenz in einer Anwendung zu implementieren.
Disziplinen: Analyse und Design
Zweck
  • Sicherstellen, dass persistente Daten konsistent und effizient gespeichert werden.
  • Verhalten definieren, das in der Datenbank implementiert werden muss.
Beziehungen
RollenPrimärer Ausführender: Zusätzliche Ausführende:
EingabenVerbindlich: Optional:
Ausgaben
Prozessverwendung
Hauptbeschreibung

Die in dieser Aufgabe beschriebenen Schritte setzen voraus, dass das persistente Datendesign der Anwendung mit einem Managementsystem für relationale Datenbanken (RDBMS) implementiert wird. Es wird vorausgesetzt, dass Sie mit Datenbankkonzepten, einschließlich Normalisierung und Denormalisierung, sowie mit Datenbankterminologie, die in Referenzen wie [DAT99] beschrieben ist, vertraut sind.  

Die Schritte in dieser Aufgabe verweisen auch auf das UML-Profil für Datenbankmodellierung, das in [NBG01] beschrieben ist. [NBG01] enthält außerdem eine allgemeine Beschreibung des Prozesses für die Modellierung und das Design relationaler Datenbanken mit UML. Hintergrundinformationen zur Beziehung zwischen relationalen Datenmodellen und Objektmodellen finden Sie im Abschnitt Konzept: Relationale Datenbanken und Objektorientierung.

Schritte
Logisches Datenmodell entwickeln (optional)
Zweck Ein Modell des logischen Designs der Datenbank definieren.

Das logische Datenmodell ist eine idealisierte Sicht der wichtigsten logischen Datenentitäten und ihrer Beziehungen, die von spezifischer Software und Datenbankimplementierungen unabhängig ist. Es liegt im Allgemeinen in der dritten Normalform vor (siehe Konzept: Normalisierung), einer Datenmodellierungsform, die Redundanzen minimiert und sicherstellt, dass keine transitiven Abhängigkeiten vorliegen. Ein solches Modell beschäftigt sich mit der Frage, wie die Datenbank aussieht, wenn Daten erfasst werden, und nicht mit den Anwendungen, die die Daten verwenden, und deren Leistung. Ein logisches Datenmodell ist Teil des Datenmodells und kein separates RUP-Arbeitsergebnis. Häufig ist jedoch empfehlenswert, einzelne logische Datenmodelle zu definieren, und zwar

  • für Projekte, in denen Datenbank- und Anwendungsdesigns von unterschiedlichen Teams entwickelt werden,
  • für Projekte, in denen mehrere Anwendungen eine gemeinsame Datenbank verwenden.

Wenn Sie ein logisches Datenmodell erstellen, können Sie ganz von vorn beginnen und die Modellelemente verwenden, die unter Richtlinie für Arbeitsergebnis: Datenmodell beschrieben sind, oder Sie können mit Entitäten für jede persistente Klasse im Analysemodell oder Designmodell beginnen.

Wenn Sie eine Datenbank entwerfen, die nur eine einzige Anwendung bedient, müssen Sie nicht unbedingt ein gesondertes logisches Datenmodell erstellen. In diesem Fall entwickelt der Datenbankdesigner das physische Datenmodell basierend auf den persistenten Klassen und ihren Zuordnungen im Designmodell.

Für beide Ansätze ist es von Bedeutung, dass Datenbankdesigner und Designer während Analyse und Design zusammenarbeiten, um die Klassen im Designmodell zu ermitteln, die Informationen in einer Datenbank speichern müssen. Wie im Schritt "Persistente Klassen des Klassendesigns" beschrieben, ermittelt der Datenbankdesigner zusammen mit dem Designer die Designklassen im Designmodell, die persistent und potenzielle Kandidaten für Tabellen in der Datenbank sind.

Physisches Datenbankdesign entwickeln
Zweck Das detaillierte physische Design der Datenbank definieren.

Das physische Datenbankdesign enthält Modellelemente (z. B. Tabellen, Sichten und gespeicherte Prozeduren), die die detaillierte physische Struktur der Datenbank- und Modellelemente (z. B. Schemata und Tabellenbereiche) für das zugrunde liegende Datenspeicherdesign der Datenbank darstellen. Zusammen bilden diese Modellelemente das physische Datenmodell der Datenbank. Dieses physische Datenmodell ist im Datenmodell enthalten und kein separates Arbeitsergebnis des Modells.

Die einzelnen Schritte für die Entwicklung des physischen Datenbankdesigns sind im Folgenden aufgeführt:

Domänen definieren

Zweck Definition wiederverwendbarer benutzerdefinierter Typen.  

Der Datenbankdesigner kann mit Domänen Typenstandards für das Datenbankdesign umsetzen. Domänen sind benutzerdefinierte Datentypen, die auf eine Spalte in einer Tabelle angewendet werden können. Mit Ausnahme des Namens haben Domänen die Eigenschaften einer Spalte.  

Erste physische Datenbankdesignelemente erstellen

Zweck Erste Datenbanktabellen und Beziehungen erstellen.

Der Datenbankdesigner modelliert die physischen Datenmodellelemente mit Tabellen und Spalten in Tabellen. Lesen Sie hierzu die Beschreibung im Abschnitt Richtlinie für Arbeitsergebnis: Datenmodell

Wenn ein logisches Datenmodell erstellt wurde, können dessen logische Entitäten als Basis für eine erste Gruppe von Tabellen verwendet werden.

Für einen Schnelleinstieg kann der Datenbankdesigner alternativ die persistenten Klassen im Designmodell als Ausgangspunkt für Tabellen im physischen Datenmodell verwenden. Der Datenbankdesigner modelliert die persistenten Klassen und ihre Attribute als Tabellen bzw. Spalten. Außerdem muss der Datenbankdesigner die Beziehungen zwischen den Tabellen basierend auf den Assoziationen zwischen den persistenten Klassen im Designmodell definieren. Wie die Designmodellelemente und Beziehungen den Datenmodellelementen und Beziehungen zugeordnet sind, können Sie dem Abschnitt Richtlinie für Arbeitsergebnis: Relationale Datenbanken entwickeln entnehmen.

Wenn Sie das Modell auf der Basis der persistenten Klassen und nicht auf einem normalisierten logischen Datenmodell erstellen, müssen Sie generell eine gewisse Normalisierung anwenden, um Datenredundanzen und Abhängigkeiten zwischen Feldern, die keine Schlüsselfelder sind, zu vermeiden. Weitere Informationen zur Normalisierung der Datenbank finden Sie im Abschnitt Konzept: Normalisierung.

Referenztabellen definieren

Zweck Definition von Standardreferenztabellen für das Projekt.

Häufig werden im Projekt Suchtabellen, Validierungstabellen oder Referenztabellen verwendet, die als Standardtabellen definiert sind. Den Daten in diesen Tabellen sollte besondere Aufmerksamkeit geschenkt werden, da im Allgemeinen zwar häufig auf diese Daten zugegriffen wird, diese Daten sich aber nur selten ändern. Im Designmodell können diese Tabellen Standardproduktschlüssel, Länderkürzel, Postleitzahlen, Steuertabellen, Validierungstabellen für Ortsnetzkennzahlen oder andere häufig verwendete Informationen enthalten. In Finanzsystemen können diese Tabellen Listen mit Policenkürzeln, Bewertungskategorien für Versicherungspolicen oder Umrechnungskurse enthalten. Suchen Sie im Designmodell nach Klassen, die schreibgeschützt sind und Validierungsinformationen für eine große Anzahl von Clients enthalten.

Wenn die Referenztabelle klein ist, brauchen Sie sie nicht zu indexieren. Durch Indexierung könnten Sie sogar unnötigen zusätzlichen Aufwand für kleine Tabellen erzeugen. In der Regel werden kleine Tabellen, auf die oft zugegriffen wird, durch die Caching-Algorithmen häufig im Daten-Cache (Hauptspeicher) gehalten.

Stellen Sie, sofern möglich, sicher, dass der Datenbank-Cache ausreicht, um alle Referenztabellen zusammen mit dem normalen Arbeitsbereich für Abfragen und Transaktionen im Hauptspeicher zu halten. Häufig ist der Schlüssel für die Steigerung der Datenbankleistung eine Reduzierung der Platten-E/A.

Sobald die Strukturen für die Referenztabellen definiert sind, müssen Sie eine Strategie für das Füllen der Referenztabellen festlegen. Da der Zugriff auf diese Tabellen schon zu Beginn des Projekts erfolgt, müssen die Bestimmung der Referenzwerte und das Laden der Tabellen häufig relativ früh zur Anwendungslaufzeit durchgeführt werden. Der Datenbankdesigner ist zwar nicht für das Abrufen der Daten verantwortlich, muss jedoch festlegen, wie und wann die Referenztabellen aktualisiert werden.

Integritätsbedingungen über Primärschlüssel und eindeutigen Schlüssel erstellen

Zweck Definition einer oder mehrerer Spalten, die eine Zeile in der Tabelle eindeutig identifizieren.
Definition von Spaltenvorgaben, die die Eindeutigkeit der Daten bzw. Datensammlung gewährleisten.

Ein Primärschlüssel besteht aus einer oder mehreren Spalten, die Zeilen in einer Tabelle eindeutig kennzeichnen. Eine Tabelle hat einen einzigen Primärschlüssel. Es gibt häufig einen "natürlichen" Schlüssel, der verwendet werden kann, um eine Datenzeile eindeutig zu identifizieren (z. B. die Postleitzahl in einer Referenztabelle). Der Primärschlüssel darf keine Daten enthalten, die sich mit der Geschäftsumgebung ändern können. Wenn der "natürliche" Schlüssel ein Wert ist, der sich ändern kann (z. B. der Name einer Person), empfiehlt es sich, dass der Datenbankdesigner beim Erstellen eines Primärschlüssels eine einzelne Spalte erstellt, die keine Bedeutung hat und die nicht vom Benutzer angegeben wird. Damit wird eine Datenstruktur erstellt, die sich leichter an geänderte Geschäftsstrukturen, Regeln oder Umgebungen anpassen lässt.

Die Verwendung einer Spalte als Primärschlüssel, die keine Bedeutung hat und nicht vom Benutzer angegeben wird, ist ein wesentliches Konzept beim Entwurf eines Data-Warehouse. Transaktionssysteme wählen häufig einen "natürlichen" Primärschlüssel, der über eine Spalte, die keine Bedeutung hat und nicht vom Benutzer angegeben wird, geringfügig geändert werden kann.

Eine eindeutige Integritätsbedingung legt fest, dass die Daten in der Spalte bzw. Spaltensammlung pro Zeile eindeutig ist. Wenn die eindeutige Integritätsbedingung für eine Spalte gilt, müssen die Daten in einer bestimmten Zeile in der angegebenen Spalte eindeutig sein und sich von den Daten in einer anderen Zeile in derselben Spalte unterscheiden.  

Wenn eine eindeutige Integritätsbedingung für eine Gruppe von Spalten definiert ist, basiert die Eindeutigkeit auf der kollektiven Gesamtheit der Daten in den Spalten, für die diese eindeutige Integritätsbedingung gilt. Die Daten in einer bestimmten Zeile in einer bestimmten Spalte können durchaus mit den Daten in einer anderen Zeile derselben Spalte identisch sein. Der Datenbankdesigner verwendet die eindeutige Integritätsbedingung, um die Eindeutigkeit von Geschäftsdaten sicherzustellen.

Regeln für die Umsetzung der Daten- und referenziellen Integrität definieren

Zweck Gewährleistung der Datenbankintegrität.

Regeln für Datenintegrität, auch Integritätsbedingungen genannt, stellen sicher, dass Datenwerte in einem definierten Bereich liegen. Wenn diese Bereiche benannt werden können, kann die Datenbank die Einhaltung der Bereiche erzwingen. (Das soll nicht bedeuten, dass in der Anwendung keine Validierung der Daten vorgenommen werden sollte, sondern nur, dass die Datenbank als "Prüfer in letzter Instanz" dienen kann, falls die Anwendung nicht ordnungsgemäß funktioniert.) Wenn Regeln für die Datenvalidierung existieren, müssen die Datenbankprüfregeln so entworfen werden, dass diese Regeln umgesetzt werden.

Ein Fremdschlüssel besteht aus einer oder mehreren Spalten in einer Tabelle, die dem primären Schlüssel in einer anderen Tabelle zugeordnet sind. Eine Tabelle kann mehrere Fremdschlüssel haben, und jeder Fremdschlüssel stellte eine Zuordnung zu einer anderen Tabelle dar. Diese Zuordnung oder Beziehung zwischen Tabellen wird häufig als Eltern-Kind-Beziehung bezeichnet. Das Kind, die untergeordnete Tabelle, enthält den Fremdschlüssel, der dem Primärschlüssel in der übergeordneten Tabelle zugeordnet ist.  

Die Definition der Integritätsbedingung über Fremdschlüssel wird auch häufig vom Abfrageoptimierungsprogramm verwendet, um die Abfrageleistung zu verbessern. In vielen Fällen verwenden die Umsetzungsregeln für Fremdschlüssel Referenztabellen.

Datenbankdesign zur Leistungsoptimierung denormalisieren

Zweck Optimierung der Datenbankstrukturen im Hinblick auf die Leistung.

In einem relationalen Datenmodell ergibt die Anfangszuordnung im Allgemeinen eine einfache Klassen/Tabellen-Zuordnung. Wenn zur selben Zeit Objekte aus unterschiedlichen Klassen abgerufen werden müssen, verwendet das RDBMS eine Operation mit dem Namen "Tabellenverknüpfung", um die Zeilen für die Objekte von Interesse abzurufen. Bei Daten, auf die häufig zugegriffen wird, können Verknüpfungsoperationen sehr rechenintensiv sein. Zur Minimierung der Kosten, die im Zusammenhang mit Verknüpfungsoperationen stehen, wird häufig eine relationale Standardtechnik angewendet, die "Denormalisierung".

Bei der Denormalisierung werden Spalten aus zwei oder mehr unterschiedlichen Tabellen zu einer Tabelle kombiniert, womit die Informationen effektiv vorab verknüpft werden. Die Denormalisierung ist eine Entscheidung zu Gunsten der weniger kostenintensiven Abrufoperationen gegenüber den kostenintensiven Aktualisierungsoperationen. Diese Technik verringert außerdem die Leistung des Systems in Abfragen, die nur an den Attributen eines der Objekte interessiert sind, die in der denormalisierten Tabelle verknüpft sind, da normalerweise mit jeder Abfrage alle Attribute abgerufen werden. In Fällen, in denen die Anwendung normalerweise alle Attribute benötigt, kann eine signifikante Leistungsverbesserung erzielt werden.

Es werden selten mehr als zwei Tabellen denormalisiert, weil dies die Kosten für Einfügungen und Aktualisierungen sowie für nicht verknüpfte Abfragen erhöhen würde. Die Einschränkung der Denormalisierung auf zwei Tabellen ist ein vernünftiger Ansatz, sofern keine starken und überzeugenden Beweise für die Vorteile einer anderen Vorgehensweise vorliegen.

Denormalisierung kann über die Designklassen eingebracht werden, wenn die Klassen verschachtelt sind. Verschachtelte Klassen können einer denormalisierten Tabelle zugeordnet werden.

Eine Objektdatenbanken unterstützen ein der Denormalisierung ähnliches Konzept, bei dem zusammengehörige Objekte auf der Platte zusammengefasst und in Einzeloperationen abgerufen werden. Das Konzept ist ähnlich: Zeit für das Abrufen von Objekten verringern, indem der Aufwand des Systems für den Abruf zusammengehöriger Objekte aus der Datenbank verringert wird.

Manchmal können bei der Optimierung des Datenmodells Probleme im Designmodell aufgedeckt werden, z. B. Leistungsengpässe, schlechte Modellierung oder unvollständige Designs. In diesem Fall müssen Sie die Probleme mit dem Designer der Klasse besprechen und gegebenenfalls Änderungsanfragen einreichen.

Datenzugriff optimieren

Zweck Ermöglichen eines effizienten Datenzugriffs durch Indexierung.
Ermöglichen eines effizienten Datenzugriffs durch Datenbanksichten.

Nachdem die Tabellenstruktur entworfen wurde, müssen Sie die Typen der Abfragen bestimmen, die für die Daten ausgeführt werden. Die Datenbank verwendet Indexierung, um den Zugriff zu beschleunigen. Indexierung ist sehr effektiv, wenn die Datenwerte in der zu indexierenden Spalte relativ eindeutig sind.

Im Folgenden werden einige Prinzipien für die Indexierung beschrieben:

  • Die Primärschlüsselspalte der Tabelle muss immer indexiert werden. Primärschlüsselspalten werden häufig als Suchkriterien und für Verknüpfungsoperationen verwendet.
  • Tabellen mit weniger als 100 Zeilen und nur wenigen Spalten profitieren relativ wenig von einer Indexierung. Kleine Tabellen passen im Allgemeinen problemlos in den Datenbank-Cache.
  • Indizes sollten auch für häufig ausgeführte Abfragen oder Abfragen definiert werden, die Daten schnell abrufen müssen (z. B. Suchoperationen, auf die eine Person wartet). Ein Index muss für jede Gruppe von Attributen definiert werden, die gemeinsam als Suchkriterium verwendet werden. Wenn das System beispielsweise alle Aufträge finden muss, in denen ein bestimmtes Produkt bestellt wird, müssten Sie einen Index in der Tabelle "Artikel" der Spalte "Produktnummer" erstellen.
  • Indizes sollten im Allgemeinen nur für Spalten definiert werden, die als Kennungen verwendet werden, und nicht für numerische Werte wie Kontostände oder Textinformationen wie Auftragskommentare. Werte in Kennungsspalten werden in der Regel zugeordnet, wenn das Objekt erstellt wird, und bleiben für die Lebensdauer des Objekts unverändert.
  • Indizes für einfache Zahlen (Datentypen integer und number) sind wesentlich einfacher und schneller als Indizes für Zeichenfolgen. In Anbetracht der großen Datenvolumen, die in einer Abfrage oder einer komplexen Verknüpfung verarbeitet werden, summieren sich kleine Einsparungen schnell. Indizes für numerische Spalten verbrauchen in der Regel erheblich weniger Speicherplatz als Indizes für Zeichen.

Die Verwendung von Indizes hat jedoch auch ihren Preis: je mehr Indizes eine Tabelle enthält, desto dauert die Verarbeitung von Einfügungen und Aktualisierungen. Wenn Sie die Verwendung von Indizes in Erwägung ziehen, treffen Sie die folgenden Vorkehrungen:

  • Verwenden Sie keine Indizes, um selten ausgeführte Abfragen zu beschleunigen, es sei denn, diese Abfrage wird zu einem kritischen Zeitpunkt ausgeführt, zu dem eine maximale Geschwindigkeit von entscheidender Bedeutung ist.
  • In einigen Systemen ist die Leistung bei Aktualisierungen und Einfügungen wesentlich wichtiger als die Abfrageleistung. Ein gutes Beispiel sind Daten-Factory-Anwendungen, in denen Qualitätsdaten in Echtzeit erfasst werden. In diesen Systemen werden nur gelegentlich Onlineabfragen durchgeführt, und die meisten Daten werden regelmäßig von Stapelberichtsanwendungen analysiert, die statistische Analysen durchführen. Für Datenerfassungssysteme sollten Sie alle Indizes entfernen, um einen maximalen Durchsatz zu erzielen. Wenn Indizes erforderlich sind, können sie direkt vor der Ausführung von Stapelberichtsanwendungen und Analyseanwendungen erneut erstellt und nach deren Ausführung wieder gelöscht werden.
  • Denken Sie immer daran, dass mit Indizes verdeckte Kosten verbunden sind. Es braucht beispielsweise Zeit, um sie zu aktualisieren (es fallen Kosten für jedes Einfügen, Aktualisieren und Löschen an), und sie belegen Plattenspeicherplatz. Vergewissern Sie sich eingehend, dass die Verwendung von Indizes nutzbringend ist.

Viele Datenbanken bieten mehrere Indextypen zur Auswahl an. Die gebräuchlichsten Indextypen sind:

  • B-Tree-Indizes: Diese Indizes werden am häufigsten verwendet und basieren auf symmetrischen Baumdatenstrukturen. Sie sind hilfreich, wenn die Indexschlüsselwerte zufällig verteilt werden und in der Regel sehr stark variieren. Wenn die zu indexierenden Daten bereits sequenziell geordnet sind, bietet dieser Indextyp eine eher schwache Leistung.
  • Hash-Indizes: Diese Indizes werden weniger häufig verwendet. Das Hash-Verfahren bietet eine bessere Leistung, wenn der Bereich der Indexschlüsselwerte bekannt ist, sich selten ändert und eindeutig ist. Diese Technik verwendet den Schlüsselwert, um die Adresse der gesuchten Daten zu berechnen. Aufgrund des Bedarfs an Vorhersagbarkeit sind Hash-Indizes in der Regel nur für Referenztabellen mittlerer Größe hilfreich, die sich selten ändern.

Die Wahl der Indexierungsstrategie und das Timing bei der Indexerstellung können einen großen Einfluss auf die Leistung haben. Das Laden von Massendaten sollte ohne Indizes durchgeführt werden (hierfür können Sie den Index löschen, die Daten laden und anschließend den Index erneut erstellen). Der Grund hierfür ist, dass die Symmetrie der Indexstruktur beim Hinzufügen einer Zeile jedes mal hergestellt werden muss. Da nachfolgende Zeilen die optimale Indexstruktur stören, ist es verschwendete Zeit, die Symmetrie nach jeder eingefügten Zeile wieder und wieder herzustellen. Es ist schneller und effizienter, die Daten ohne Indizes zu laden und den Index nach Abschluss des Ladevorgangs erneut zu erstellen. Einige Datenbanken unterstützen Ladeprogramme für Massendaten, die diese Arbeiten automatisch erledigen.

Eine weitere Strategie für die Optimierung der Datenbankzugriffe ist die Verwendung von Sichten. Datenbanksichten sind virtuelle Tabellen, die keinen eigenen Speicher haben. Für das aufrufende Programm (oder den Benutzer) verhält sich eine Sicht jedoch wie eine Tabelle. Eine Sicht unterstützt den Abruf von Daten und kann (je nach Datenbankstruktur und Datenbankanbieter) auch verwendet werden, um Daten zu aktualisieren. Die Sicht enthält Daten aus einer oder mehreren Tabellen, auf die mit einer einzigen select-Anweisung zugegriffen werden kann. Der Leistungsgewinn wird bei der Auswahl der Daten erzielt, insbesondere in häufig abgefragten Tabellen. Die Daten werden von einer einzigen Position - der Sicht - und nicht durch Durchsuchen mehrerer großer Tabellen in der Datenbank abgerufen.

Sichten spielen auch eine bedeutende Rolle für die Datenbanksicherheit. Eine Sicht, die Teile einer Tabelle enthält, kann den Zugriff auf sensible Daten in der Basistabelle einschränken.

Speichermerkmale definieren

Zweck Design der Speicherplatzzuordnung und Organisation der Plattenseiten für die Datenbank

Ein Datenbankdesigner verwendet Tabellenbereiche, um den Speicherplatz darzustellen, der Tabellen, Indizes, gespeicherten Prozeduren usw. zugeordnet wird. Eine oder mehrere Tabellenbereiche werden einer Datenbank zugeordnet. Der Datenbankdesigner muss die Tabellen im Datenmodell analysieren, um festzustellen, wie sie und andere Unterstützungselemente für die Datenbank auf den Speicherplatz in der Datenbank verteilt werden.

Denken Sie beim Bestimmen der Tabellenbereichsstrukturen für die Datenbank daran, dass Datenbanken keine Ein-/Ausgaben für Zeilen, Datensätze oder vollständige Tabellen durchführen. Sie führen Ein-/Ausgaben für Plattenblöcke durch. Der Grund hierfür ist simpel: Blockorientierte Ein-/Ausgabeoperationen werden normalerweise in der Software und Hardware des Systems optimiert. Deshalb kann die physische Organisation der Tabellen und Indizes in der Datenbank dramatische Auswirkungen auf die Leistung des Systems haben.

Beachten Sie bei der Planung der Speicherplatzzuordnung und der Organisation der Plattenseiten für die Datenbank folgende Faktoren:

  • Dichte der Informationen in den Plattenseiten
  • Position der Plattenseiten auf der Platten bzw. auf mehreren Platten
  • Plattenspeicherplatz für die Tabelle

Diese Faktoren werden in den folgenden Abschnitten erläutert.

Dichte der Informationen in den Plattenseiten

Die Dichte der Informationen in den Plattenseiten richtet sich nach dem Umfang der Änderungen, die für die Daten im Laufe der Zeit zu erwarten sind. Im Wesentlichen können Seiten mit einer geringeren Dichte Änderungen von Werten oder zusätzliche Daten leichter bewältigen, wohingegen Daten mit einer höheren Informationsdichte eine bessere Leistung von Leseoperationen unterstützen, da mehr Daten pro Block gelesen werden können.

Zur Vereinfachung der Plattenverwaltung kann der Datenbankdesigner Tabellen basierend auf dem Umfang der erwarteten Änderungen gruppieren. Die folgenden drei Gruppen stellen einen guten Ausgangspunkt für diese Art der Organisation dar:

  • Tabellen mit hoher Dynamik
  • Tabellen mit geringer Dynamik
  • Tabellen mit eher statischem Charakter

Die Tabellen mit hoher Dynamik sollten Plattenseiten zugeordnet werden, die viel leeren Speicherplatz haben (ca. 30 %), die Tabellen mit geringer Dynamik Plattenseiten mit weniger leerem Speicherplatz (ca 15 %) und die eher statischen Tabellen Plattenseiten mit sehr wenig leerem Speicherplatz. Die Indizes für die Tabellen müssen ähnlich zugeordnet werden.

Position der Plattenseiten

Nach der Zuordnung der Tabellengruppen muss der Datenbankdesigner die Position für die Plattenseiten festlegen. Das Ziel ist hier, die Last gleichmäßig auf die verschiedenen Laufwerke und Lese-/Schreibköpfe zu verteilen, um Engpässe zu reduzieren bzw. zu eliminieren. Halten Sie sich an die folgenden Richtlinien:

  • Speichern Sie Daten niemals auf derselben Platte wie das Betriebssystem, die temporären Dateien des Betriebssystems oder Auslagerungseinheiten. Diese Laufwerke sind auch ohne weitere Last schon genug ausgelastet.
  • Speichern Sie Daten, auf die parallel zugegriffen wird, auf mehreren Laufwerken, um die Last gleichmäßig zu verteilen. Einige Systeme unterstützen parallele E/A-Kanäle. In einem solchen Fall können Sie die Daten auf die verschiedenen Kanäle verteilen.
  • Speichern Sie die Indizes auf einem anderen Laufwerk als die indexierten Daten, um die Last zu verteilen.
  • Lesen Sie die Richtlinien in der Dokumentation des Datenbankanbieters.
  • Der Typ des verwendeten Speichers (z. B. RAID-5, RAID-10, SAN, NAS oder über Kanäle angebunden) wirkt sich auf die Datenbankleistung aus. Machen Sie sich mit den Leistungsrichtlinien vertraut, die vom Speicheranbieter bereitgestellt werden.

Datenbank-E/A ist im Allgemeinen der Drosselungsfaktor für die Datenbankleistung. Die gleichmäßige Verteilung von Ein- und Ausgaben ist ein iterativer und experimenteller Prozess. Durch die Erstellung eines Prototyps für Datenbankzugriffe in der Ausarbeitungsphase und entsprechende Instrumentierung für die Überwachung der physischen und logischen Ein- und Ausgaben können Sie Leistungsprobleme schon sehr früh feststellen, wenn noch genug Zeit ist, das Datenbankdesign anzupassen.

Zuordnung von Plattenspeicherplatz

Schätzen Sie anhand der Kenndaten des Persistenzdesignmechanismus die Anzahl der Objekte, die gespeichert werden müssen. Der für das Speichern der Objekte erforderliche Plattenspeicherplatz ist von RDBMS zu RDBMS verschieden. Planen Sie bei der Berechnung des Plattenspeicherplatzes unbedingt das Wachstum der Daten ein. Wenn Sie den Plattenspeicherplatz für eine Datenbank schätzen, müssen Sie zuerst den für jede einzelne Tabelle erforderlichen Plattenspeicherplatz schätzen und diese Werte dann addieren. Im Handbuch für Datenbankadministratoren zu Ihrem RDBMS-Produkt können Sie die Formel für eine präzise Schätzung der Größe nachschlagen. Im Folgenden sind einige allgemeine Schritte für das Schätzen des Platzbedarfs für eine Tabelle erläutert:

  • Berechnen Sie die durchschnittliche Zeilengröße. Diese Berechnung muss alle Steuerinformationen auf Datensatzebene sowie alle Steuerinformationen für Spalten variabler Länge beinhalten.
  • Berechnen Sie die Anzahl der Spalten, die in eine Seite bzw. einen E/A-Block passen. Da die meisten Datenbanken nur vollständige Datensätze in einer Seite bzw. einem E/A-Block speichern, sollte dies eine ganzzahlige Anzahl von Zeilen sein.
  • Berechnen Sie die Anzahl der Seiten bzw. E/A-Blöcke, die erforderlich sind, um die geschätzte Anzahl von Datensätzen in der Datenbank zu speichern. Die geschätzte Anzahl der Datensätze muss alle Auslastungsfaktoren berücksichtigen.
  • Multiplizieren Sie die Anzahl der erforderlichen Seiten bzw. E/A-Blöcke mit der Größe der Seite bzw. des E/A-Blocks.
  • Addieren Sie die Kosten für Zusatzindizes.
  • Fügen Sie alle festen Kosten für die Tabelle hinzu.

Nachdem Sie den Speicherbedarf für die Tabellen berechnet haben, gehen Sie wie folgt vor:

  • Bilden Sie die Summe aus den für die einzelnen Tabellen berechneten Werten.
  • Addieren Sie den festen erforderlichen Wert für die Datenbankverwaltung.
  • Addieren Sie den erforderlichen Plattenspeicherplatz für Transaktionsprotokolle und Prüfprotokolle.  

In einer Umgebung, die häufig aktualisiert wird, erfordern die Sicherungsanforderungen für das Prüfprotokoll erhebliche Mengen von Speicher. Die Dokumentation für die gängigsten kommerziellen Datenbankverwaltungssysteme enthält normalerweise detaillierte Anweisungen zur Berechnung der Größe. Ziehen Sie diese Anweisungen unbedingt heran, wenn Sie den erforderlichen Plattenspeicherplatz für Ihre Datenbank schätzen.

Gespeicherte Prozeduren entwerfen, um Klassenverhalten an die Datenbank zu verteilten

Zweck Feststellen, ob gespeicherte Prozeduren oder Auslöser für die Implementierung von Klassenoperationen für Datenzugriffe verwendet werden sollen

Die meisten Datenbanken unterstützen gespeicherte Prozeduren. Eine gespeicherte Prozedur ist ausführbarer Code, der im Prozessraum des Datenbankverwaltungssystems ausgeführt wird. Mit einer gespeicherten Prozedur können datenbankbezogene Aktionen auf dem Server ausgeführt werden, ohne Daten über ein Netz übertragen zu müssen. Durch einen vernünftigen Einsatz gespeicherter Prozeduren kann die Leistung des Systems verbessert werden.

Gespeicherte Prozeduren können normalerweise in zwei Typen eingeteilt werden: echte Prozeduren und Auslöser. Prozeduren werden explizit von einer Anwendung ausgeführt werden, haben im Allgemeinen Parameter und liefern einen expliziten Rückgabewert. Auslöser hingegen werden implizit aufgerufen, wenn ein Datenbankereignis auftritt (z. B. Zeile einfügen, Zeile aktualisieren oder Zeile löschen), haben keine Parameter außer der zu ändernden Zeile (da sie implizit aufgerufen werden) und liefern keinen expliziten Rückgabewert.

In Datenbanksystemen ohne Integritätsbedingungen werden Auslöser häufig für die Einhaltung referenzieller Integrität und Datenintegrität eingesetzt. Ansonsten werden sie im Allgemeinen eingesetzt, wenn ein Ereignis ein anderes Ereignis auslösen (oder bewirken) muss. Auslöser werden außerdem häufig für Sicherheitszwecke verwendet, indem das Auslöseereignis überwacht wird.

Die Designklassen im Designmodell müssen untersucht werden, um festzustellen, ob sie Operationen enthalten, die mit gespeicherten Prozeduren oder Auslösern implementiert werden sollten. Kandidaten hierfür sind:

  • Operationen, die primär mit persistenten Daten arbeiten (diese erstellen, aktualisieren, abrufen oder löschen),
  • Operationen, die eine Abfrage in einer Berechnung enthalten (z. B. Berechnung der durchschnittlichen Menge und des Preises eines Produkts im Bestand),
  • Operationen, die zur Validierung von Daten auf die Datenbank zugreifen müssen.

Denken Sie daran, dass eine Verbesserung der Datenbankleistung normalerweise eine Verringerung der Ein-/Ausgaben bedeutet. Wenn sich beispielsweise durch die Durchführung einer Berechnung auf dem DBMS-Server die Menge der Daten, die über das Netz übertragen werden, verringert, sollte diese Berechnung eher auf dem Server durchgeführt werden.

Besprechen Sie mit dem Designer der Designklasse, wie die Datenbank zur Verbesserung der Leistung eingesetzt werden kann. Der Designer aktualisiert die Operationsmethode, um anzuzeigen, ob die Operation mit einer oder mehreren gespeicherten Prozeduren implementiert werden kann.

Ergebnisse prüfen
Zweck Qualität und Integrität des Datenmodells sicherstellen

Im Verlauf dieser Aufgabe müssen Sie anhand des Datenmodells fortlaufend die Vollständigkeit und Qualität der Arbeit bewerten. Außerdem muss der Datenbankdesigner die implementierte Struktur der Datenbank regelmäßig prüfen, um sicherzustellen, dass das Datenmodell mit den Änderungen synchronisiert ist, die direkt in der Datenbank vorgenommen wurden. Wenn das Projekt Tools für die Datenmodellierung verwendet, die die Synchronisation des Datenmodells mit der physischen Struktur der Datenbank unterstützen, muss der Datenbankdesigner in regelmäßigen Abständen den Zustand des Datenmodells mit der Datenbank abgleichen und bei Bedarf Anpassungen vornehmen.  

Identifizierte Mängel, die nicht sofort behoben werden, müssen in Änderungsanfragen dokumentiert und einem Mitarbeiter zur Behebung übertragen werden.

Weitere Informationen