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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
|