IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

Transkript

1 IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

2 Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank File Server Datenbank (z.b. Access): Hier kann von außen immer nur auf die Datenbankdatei zugegriffen werden. Außerdem werden hier grundsätzlich alle Daten übertragen und erst der Empfänger ist in der Lage, die Daten zu selektieren. Server Datenbank: Auf dieser läuft nach dem Hochfahren ein Datenbankprozess, der Anforderungen in Empfang nehmen und den entsprechenden Dienst ausführen kann, z.b. das Ausführen eines Selects mit Where-Bedingung. Hier werden also nur die benötigten Daten übergeben. Daraus ergibt sich auch ein nicht zu verachtender Geschwindigkeitsvorteil. Auf den ersten Blick wäre die Arbeit mit größeren (Server Datenbank) daher also besser. Aber diese sind sehr viel teurer, Auswertungen sind in der Regel nicht so einfach zu erstellen und verlangen mehr administrativen Aufwand. Weiterhin ist jedoch zu beachten, dass ACCESS (als typischer Vertreter einer File-Server Datenbank) bei sehr großen Datenmengen (mehrere GB) nicht mehr verwendet werden kann. Höchstens 255 Anwender können gleichzeitig mit einer ACCESS-Datenbank arbeiten. Nach einem Absturz von ACCESS gibt es außerdem keine Wiederherstellungsroutine. Weiterhin werden im Netz immer alle Daten übertragen ohne Berücksichtigung von WHERE-Kriterien. Und nicht zu vergessen, ist das Sicherheitskonzept von ACCESS nicht sehr mächtig. Doch es stellt sich nun die Frage, ob die Vorzüge von ACCESS (die ACCESS-Oberfläche ist sehr bedienerfreundlich, Formulare und Berichte sind sehr einfach grafisch zu erstellen) nicht durch Kopplung mit einer größeren Datenbank beibehalten werden können.. ACCESS bietet sich als Frontend-Tool an, mit Zugriff auf die Daten einer Backend-Datenbank, z.b. ORACLE, SQL SERVER. Dabei gibt es zwei Möglichkeiten, File Server oder Client Server. Aber beginnen wir von vorne. Was bedeutet eigentlich Client Server im DV-Bereich? Client Server bedeutet, dass ein Objekt für ein anderes Objekt auf dessen Anfrage hin einen Dienst ausführt (siehe Folie 2). Beispiel : Denken Sie z.b. an einen Rechner, an den ein Drucker angeschlossen ist, und der für andere Rechner als Druckerserver Druckaufträge verwaltet und ausdruckt. Der Vorteil wäre also, daß nicht an jedem PC ein Drucker angeschlossen sein muss und man trotzdem relativ schnell seine Ausdrucke erhält. Man hat also geringere Kosten, da wenige Drucker eine gute Auslastung aufweisen, d.h. über eine bessere Auslastung erreicht man einen Kostenvorteil. Ein zweiter Grund für eine Auslagerung eines Dienstes ist, dass ein Dienstanbieter spezialisiert ist hinsichtlich seines Dienstes und damit diesen zu besserer Qualität, kürzeren Ausführungszeiten, mehr Flexibilität und geringeren Kosten anbieten kann Dies sind gleichzeitig auch die üblichen Zielen, warum es in Organisationen zu Spezialisierung von Abteilungen kommt. Seite 2

3 Client Server Architekturen bieten weiterhin eine einfachere Erweiterbarkeit von Informationssystemen, wenn weitere Benutzer hinzukommen. Prinzipiell besteht jedes Informationssystem aus drei Ebenen: 1. die Datenbankebene zur Speicherung von Daten 2. die Applikationsebene, d.h. die Programme, die die Geschäftsprozesse realisieren 3. und die Präsentationsebene zur Darstellung der Daten in den Client-Masken. Eine Nicht-Client-Server-Architektur im Bereich Informationssysteme würde so aussehen, dass alle drei Komponenten auf jedem Rechner realisiert sind (siehe Folie 3). Man redet auch von Client Server, wenn eine der Komponenten auf einem bestimmten Rechner installiert ist und für andere Rechner diese Komponente zur Verfügung steht Im Zusammenhang mit Informationssystemen ist dabei häufig die Datenbank auf einem eigenen Rechner installiert, die Applikation zusammen mit der Präsentation jeweils auf allen Clients (thick client / siehe Folie 4). File Server Architektur (siehe Folie 5) Eine File Server Architektur kann man mit ACCESS realisieren, indem man zwei ACCESS- erstellt. In einer Datenbank die Tabellen (wir nennen Sie in Zukunft Daten- Datenbank ), in der anderen Datenbank die Abfragen, die Formulare und die Berichte (diese nennen wir in Zukunft Programm-Datenbank ). Die Verknüpfung geschieht in der Programm- Datenbank, indem man die Tabellen der Daten-Datenbank über ODBC einbindet. ODBC ist eine Standardschnittstelle zum Zugriff auf relationale Datenstrukturen. Die Programm- Datenbank wird auf jedem Client installiert, die Daten-Datenbank nur auf einem über das Netz erreichbaren Server-Rechner. Vorgehensweise: Zunächst erstellt man eine ACCESS-Datenbank mit allen Komponenten. Das Auslagern der Tabellen in eine neue Datenbank und die Verknüpfung mit ODBC geschieht dann über einen Assistenten (siehe Folie 6) Vorteile einer solchen File Server Architektur sind dabei (siehe Folie 7): - Zugriff von mehreren Anwendern auf Daten - Client-mdb updatebar ohne Daten zu ändern - Client-Programme lokal vorhanden Angesichts dieser Vorteile könnte man sich nun jedoch die Frage stellen, wozu man überhaupt noch eine Client Server Architektur braucht (siehe Folie 8). Nun eine File Server Datenbank verfügt über keinen eigenen Datenbankprozess, der bestimmte Dienste ausführen kann. Es können somit keine Daten auf dem Server selektiert werden, sondern es wird die Datenbank File an sich übergeben. Das führt zu langen Zugriffszeiten insbesondere wegen des großen Datentransfers im Netz. Schauen wir uns zunächst einmal an, was mächtigere als ACCESS können und hier als Beispiel die SQL Server Datenbank. Ein wesentlicher Unterschied ist dabei das Vorhandensein eines Transaktionsprotokolls (siehe Folie 9) Seite 3

4 Das sehen wir hier bei der Datenbank ProjekteSQL, eine der, die auf dem SQL Server vorhanden ist. Sie erkennen, dass es ein Logfile gibt, die die Transaktionen für Änderungen von Datenbankinhalten aufnimmt. Damit kann das DBMS nach einem Absturz, Daten die noch im Puffer stehen auf die Datenbank schreiben (Rollforward) bzw nicht vollständig durchgeführte Transaktionen wieder zurücknehmen (Rollback). Außerdem kann man nach einem Plattencrash über das Einspielen der letzten Sicherung mit Hilfe der Logfile auch alle seitdem durchgeführten Datenbankänderungen nachvollziehen. Das Log File sollte dabei nie auf der Platte gespeichert werden wo die Datenbank liegt, denn nach einem Plattencrash könnte die Logfile ansonsten nicht mehr verwendbar sein. Was versteht man eigentlich unter dem bereits oben erwähnten Zurücknehmen von Transaktionen? Angenommen es erfolgte eine Warenauslieferung durch den Anwender. Dazu erfolgt in der Datenbank innerhalb einer Transaktion sowohl die Erhöhung der Liefermenge im Kundenauftrag, als auch die Reduzierung des Lagerbestands. Angenommen die Erhöhung der Liefermenge erfolgte noch, danach kam es zum Datenbankabsturz. Die Transaktion wurde nicht vollständig durchgeführt. Man muss also die Transaktion wieder zurücknehmen, denn das manuelle reduzieren des Lagerbestandes durch den Anwender nach dem Neustart der Datenbank ist problematisch, da der Anwender nur ganze Geschäftsprozesse aufrufen darf, aber keine einzelnen Änderungen von Datenbankinhalten. Das wäre viel zu fehleranfällig. Deshalb werden die Datenbankaktualisierungen wieder zurückgenommen, die innerhalb einer nicht vollständig durchgeführten Transaktion bereits schon realisiert wurden. In unserem Fall wird somit die Liefermenge wieder reduziert, um auf den Stand zu kommen, den die Datenbank vor dem Beginn der Transaktion aufwies. Eine weitere Möglichkeit ist die Definition von Triggern. Damit kann ich auf bestimmte Ereignisse von Datenbankänderungen reagieren, um diese z.b. nicht zuzulassen (siehe Folie 10) Einen Trigger kann ich direkt bei der Datenbanktabelle formulieren, z.b. bei einer Mitarbeitertabelle. Der trigger wird aufgerufen, wenn z.b. der Familienstand bei einem Mitarbeiter geändert wird und zwar von ledig auf verwitwet. Es wird dann eine Fehlermeldung ausgegeben und Seite 4

5 die Transaktion wieder zurückgenommen. Ein wichtiger Einsatz von Triggern ist auch beim Löschen von Objekten, das ein Löschen von abhängigen Objekten erfordert. Als letztes Beispiel für die Möglichkeiten, die der SQL Server bietet, werden wir uns noch die gespeicherten Prozeduren ansehen (siehe Folie 11). Als Beispiel betrachten wir die Prozedur MitarbDV. In dieser wird ein Wert als Eingabeparameter übergeben und dann alle Mitarbeiternamen übergeben von Mitarbeitern, die zu dieser Abteilung gehören. Nach dem Ausführen der Prozedur wird zunächst die Abteilungsnummer angefordert und dann Huber und Franz ausgegeben. Client Server Architektur (siehe Folie 12) ACCESS nimmt hier als Frontendtool nur die Formulare und Berichte auf, der SQL Server auf dem Backend enthält die Tabellen, die Sichten (das sind Abfragen), die gespeicherten Prozeduren und die Trigger. ACCESS kann auf diese Objekte über OLE DB zugreifen, das ist gegenüber ODBC ein neuer Standard, über den man Objekte ansprechen kann. Vorgehensweise (siehe Folie 13): Man legt ein sog ACCESS-Projekt an. Damit wird danach angefordert, welche SQL Server Datenbank man dabei gleichzeitig anlegen will: Z.B. eine SQL Server Datenbank mit Namen ProjekteSQL (siehe Folie 14). Danach legt man dann in ACCESS Tabellen an, die aber tatsächlich in der SQL Server Datenbank aufgenommen werden. Das bedeutet also, dass man in der gewohnten ACCESS-Umgebung arbeiten kann, wenn man SQL Server Objekte erzeugt. Das ist ein enormer Vorteil. Es gibt aber leichte Abweichungen z.b. zu den ACCESS-Tabellen (siehe Folie 15). Man sieht dies vor allem anhand des Entwurfs der Tabelle Projekt. Über den Enterprise Manager (siehe Folie 16) kann man sich alle des SQL Servers anschauen. Und man erkennt dann z.b. in der Datenbank ProjekteSQL u.a. die vorher angelegte Projekt-Tabelle (siehe Folie 17). Seite 5

6 Abschließend betrachten wir nun noch einen Vorteil von Server im Gegensatz zu File Server. Dazu folgende Anwendung (siehe Folie 18). Ein Anwender soll zunächst zwischen den vorhanden Abteilungen auswählen können ( z.b. DV) und erhält dann die Mitarbeiter, in dieser Abteilung (z.b. Huber und Franz). Dabei handelt es sich um zwei Formulare in ACCESS, wobei das Abteilungsformular das Mitarbeiterformular aufruft. Die Daten werden natürlich aus der SQL Server Datenbank geholt. Um dies zu realisieren geht man wie folgt vor (siehe Folie 19): Man legt im Abteilungsformular ein VBA-Programm für das Ereignis Beim Klicken auf einen Eintrag in der Abteilungsliste an, in dem das Mitarbeiterformular geöffnet wird. Dieses Mitarbeiterformular hat als Datenherkunft MitarbDV. Es handelt sich dabei um den Namen der schon vorher angelegten gespeicherten Prozedur (siehe Folie 20). Deren Ausführung erfolgt beim SQL Server und überträgt damit an ACCESS über das Netz nur die für die entsprechende Abteilung gefundenen Mitarbeiter, siehe WHERE-Bedingung. Die Prozedur verlangt dabei die Abteilung als Eingabeparameter. Diese wird dabei an die Prozedur über das Feld Eingabeparameter (Formular) übergeben. Dort ist festgelegt, dass für die Abteilungsnummer der Prozedur die ausgewählte Abteilung aus dem Abteilungsformular verwendet wird. Seite 6