Database Reference
In-Depth Information
4.12.5
Die Wahl der Systemarchitektur
Jede Systemarchitektur hat ihre Vor- und Nachteile, wie in den
vorherigen Abschnitten beschrieben. Um nun für eine be-
stimmte Anforderung die beste Architektur auszuwählen, sind
folgende Sachverhalte zu ermitteln:
Datenmenge
Bei sehr großen Datenbanken muss die Datenschicht even-
tuell auf mehrere Datenbankserver aufgeteilt werden. Dabei
kämen verteilte Datenbanken mit serverübergreifenden
Transaktionen zum Einsatz.
Komplexität der Geschäftslogik
Eine komplexe Geschäftslogik oder eine wachsende Anzahl
an Geschäftsregeln kann dazu führen, dass die Algorithmen
nicht mehr mit den datenbankspezifischen Programmier-
sprachen umgesetzt werden können, weil der Programmier-
aufwand zu groß würde. In so einem Fall käme eine Multi-
tier-Architektur mit Verwendung eines Applikationsservers
zum Einsatz.
Wiederverwendbarkeit des Programmkodes
Wenn gewisse Teile der Geschäftslogik in verschiedenen
Präsentationsschichten (Front-Ends) verwendet werden sol-
len, kann es sinnvoll sein, diese mit einem Applikationsser-
ver zur Verfügung zu stellen. Dabei können Technologien
wie z. B. DCOM und CORBA zum Einsatz kommen.
Netzwerkbelastung
Bei verteilten Systemen kann die Netzwerkbelastung stark
ansteigen, weil die verschiedenen Schichten über das Netz-
werk miteinander kommunizieren. Das Problem kann ent-
schärft werden, wenn die Geschäftslogik als eigener Prozess
auf dem Datenbankserver ausgeführt wird.
Reaktionszeiten
Am Einfachsten wäre es, wenn alle Benutzer mit einer ein-
zigen, zentralen Datenbank arbeiten könnten, weil dann alle
Benutzereingaben immer sofort für andere Benutzer sichtbar
sind. Wenn aber viele Benutzer gleichzeitig mit der Appli-
kation arbeiten oder langsame WAN-Verbindungen (Wide
Area Network) zwischen dem Standort des Benutzers und
dem Standort der Datenbank existieren, kann es notwendig
werden, die Datenbank zu dezentralisieren. Dabei werden
mehrere Kopien der Original-Datenbank verwendet, die mit
