Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- q2:einfuehrung_und_geschichte [2017/07/13 06:26] – admin03
+++ q2:einfuehrung_und_geschichte [2017/07/13 16:21] (aktuell) – [Die Ebenen eines Datenbankmanagement-Systems] admin03
@@ Zeile 56: / Zeile 56: @@
 Im Idealfall sind die drei Ebenen völlig unabhängig voneinander, d.h. dass z.B. eine andere interne Organisation der Daten nichts am konzeptuellen Modell ändern sollte. Die Ver-bindungen werden durch Transformationen geschaffen, die natürlich bei Änderungen auf einer Ebene anders gestaltet werden müssten.
-In einer ANSI-Definition dieses 3-Ebenen-Modells werden auch drei Instanzen (event. Personen) unterschieden, die für die einzelnen Ebenen zuständig sind : Anwendungsadministrator, Unter-nehmens¬administrator und Datenbankadministrator. Inwieweit eine solche strenge Diffe-renzierung sinnvoll ist und tatsächlich praktiziert wird, sei dahingestellt. Wichtig ist aber, dass es Benutzer gibt, die auf der externen Ebene Zugang zur Datenbank haben, und eine Instanz, die ein konzeptuelles Modell des Unternehmens erstellt und eine, die sich um die interne Organisation der Daten kümmert.
+In einer ANSI-Definition dieses 3-Ebenen-Modells werden auch drei Instanzen (event. Personen) unterschieden, die für die einzelnen Ebenen zuständig sind : Anwendungsadministrator, Unternehmensadministrator und Datenbankadministrator. Inwieweit eine solche strenge Differenzierung sinnvoll ist und tatsächlich praktiziert wird, sei dahingestellt. Wichtig ist aber, dass es Benutzer gibt, die auf der externen Ebene Zugang zur Datenbank haben, und eine Instanz, die ein konzeptuelles Modell des Unternehmens erstellt und eine, die sich um die interne Organisation der Daten kümmert.
-Im vorliegenden Skript soll auf das interne Modell zunächst nicht weiter eingegangen werden. Das passt auch zur Realisierung des hier vorgestellten, konkreten Problems mit einem Standard-DB-Programm wie ACCESS, das vor dem Benutzer die interne Organisation der Daten weit-gehend verbirgt.
-Eine letzte Anmerkung zu DBMS. In einem Unternehmen können solche Systeme nur sinnvoll in einer vernetzten Umgebung ablaufen, d.h. das DBMS muss im Regelfall mehrere von außen angeforderte Operationen quasi-gleichzeitig bearbeiten können. Dabei bedeutet quasi-gleichzeitig, dass es dem einzelnen Benutzer so erscheint, als würde er allein mit dem System arbeiten. Dabei müssen spezielle Sicherheitsmaßnahmen beachtet werden. So könnte z.B. der Versuch des gleichzeitigen Eintragens der Noten für ein- und denselben Schüler an zwei verschiedenen Stellen eine Verletzung der Datenintegrität hervorrufen. Ein eigenes Subprogramm des DBMS, der sogenannte Transaktionsmanager, soll das verhindern.
-Dabei sind die verschiedensten Architekturen denkbar. So könnte ein Zentralgerät (Server) nicht nur die Daten, sondern auch die wesentlichen Teile des DBMS enthalten, auf den angeschlossenen Arbeitsstationen (Clients) müsste dann lediglich ein Programm für Anfragen an die DB ablaufen. Umgekehrt wäre es denkbar, dass auf jedem Client ein DBMS arbeitet und der Server nur als zentraler Datenspeicher dient. Prinzipiell wäre auch eine nahezu beliebige Verteilung von Daten und DBMS über die Clients ohne speziellen Server möglich (verteilte Systeme), wobei dem Benutzer allerdings das Ganze weiterhin als zentrale DB erscheint. Die Realisierung, sowie die Vor- und Nachteile dieser verschiedenen Architekturen ist wieder ein eigenes Kapitel der Informatik.
-Es sei jedoch nur angemerkt, dass ACCESS in lokalen Netzen jeweils auf den Clients läuft und den Server nur als Datenspeicher benötigt, wobei allerdings eine gewisse Transaktions-überwachung, das sogenannte „Record-Locking“, stattfindet. Es gibt aber auch die Möglichkeit, dass ACCESS über eine normierte Abfragesprache auf bestimmte zentralisierte DBMS (sogenannte SQL-Server) zugreifen kann.