Datenbanken » Datenbank Grundlagen » Datenbankarchitektur

Datenbankarchitektur

Die Datenbankarchitektur richtet sich je nach Projektart, das heißt ob ein Datenbanksystem für einen einzelnen Rechner konzipiert wird oder für einen ganz Verbund von Rechner(Netzwerk). Des Weiteren ist ein wichtiger Faktor zu beachten. Der Kostenfaktor entscheidet erheblich über die Qualität und Quantität der Funktionalitäten und Sicherheiten im Datenbanksystem.

Stand-alone

Die Standalone Variante wird dann gewählt, wenn ein Programm mit einer Datenbank z.B. im Einzelhandel vertrieben werden soll oder wenn ein Datenbanksystem für einen Nutzer erstellt werden soll.

Bei Standalone System sind besonders kleine Datenbanken sehr effektiv, da ein servergestütztes System hier keinen Sinn ergeben würde. Ein weiterer Punkt, der wegfällt und die Arbeit erheblich vereinfacht, ist die Ausarbeitung von Konkurrenzsituationen, die in der Einzelplatzanwendung nicht stattfinden wird.

Multi User

Die Multi-User Variante ist erheblich kompliziert als die Standalone Variante. Hier wird nicht nur der Kostenfaktor sehr schnell ansteigen, sondern auch die Berechtigungsgvergabe und Konkurrenzsituation muss sehr effektiv gestaltet und konfiguriert werden.

Ein Multi-User System wird meistens als Client/server-Anwendung programmiert und über dem Netzwerkprotokoll TCP/IP realisiert. Bei der Erstellung einer Client/server-Anwendung muss eine über eine Grundsatzfrage entschieden werden, die das Projekt maßgeblich überall beeinflussen wird:

Wie soll die Zugriffsvergabe unter den einzelnen Benutzer realisiert werden?

Es gibt 3 sehr häufige Varianten, die eingesetzt werden können:

Optimistic Locking: Alle Benutzer können alle Aktionen ausführen und das DBMS muss entscheiden an Hand der ROWID, welche Dateien welchem Benutzer zur Verfügung gestellt werden.

Pessimistic Locking: Alle Benutzer können alle Aktionen ausführen, wobei das DBMS die Datensätze beim Zugriff sperrt und für andere Benutzer nicht zugänglich macht.

Bei der pessimistischen Variante sinkt die Produktivität der Datenbankanwendung, da die Benutzer warten müssen, bis die Datensätze wieder freigegeben werden.

Im Kontrast dazu ist die optimistische Variante sehr produktiv, muss aber auch sehr genau konzeptioniert und entwickelt werden, da alle möglichen Fallunterscheidungen berücksichtigt werden.

Realease Lock: Alle Freiheit den Benutzer und der Entwickler muss per Quellcode für die Restriktionen sorgen