Datenbankarchitektur
Die Datenbankarchitektur richtet sich nach der Projektart aus, das heißt, ob ein Datenbanksystem für einen einzelnen Rechner oder für einen ganzen Verbund aus Rechnern (Netzwerk) konzipiert wird.
"Was muss bei einer Datenbankarchitektur beachten werden?"Einer der wichtigsten Faktoren bei der Planung der Datenbankarchitektur ist der Kostenfaktor.
Der Kostenfaktor entscheidet erheblich über die Qualität und Quantität der Funktionalitäten und Sicherheiten im Datenbanksystem.
Die Wahl der richtigen Datenbankarchitektur ist entscheidend für ein erfolgreiches Datenbankdesign.
Stand-Alone-Datenbanksystem
Die Stand-Alone-Datenbank wird dann gewählt, wenn ein Programm mit einer Datenbank, z.B. im Einzelhandel, vertrieben oder wenn ein Datenbanksystem für einen Nutzer erstellt werden soll.
Bei einem Stand-Alone-Datenbanksystem 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 einer Einzelplatzanwendung nicht stattfinden.
Multi-User-Datenbanksystem
Ein Multi-User-Datenbanksystem ist erheblich komplizierter als eine Stand-Alone-Variante. Hier wird nicht nur der Kostenfaktor sehr schnell ansteigen, sondern auch die Berechtigungsvergaben und Konkurrenzsituation müssen 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 über eine Grundsatzfrage entschieden werden, die das Projekt maßgeblich beeinflussen wird: "Wie werden Konkurrenzsituation behandelt?"
Optimistic vs. Pessimistic Locking vs. Release Lock
Es gibt bei Multi-User-Datenbanksystemen drei Varianten, die eingesetzt werden können:
Optimistic Locking: Alle Benutzer können alle Aktionen ausführen und das DBMS muss anhand einer Unique Identification Number entscheiden, 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 unzugä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 müssen.
Realease Lock: Alle Benutzer können alle Aktionen ausführen und der Entwickler muss per Quellcode für die Restriktionen sorgen.