[1 ] [2 ] [3 ]

Tabelleneigenschaften

Die im vorigen Abschnitt besprochenen Eigenschaften können für das einzelne Tabellenfeld im DBC hinterlegt werden. Ebenso können aber auch Eigenschaften angegeben werden, die für die ganze Tabelle gelten. Diese sind:

• Gültigkeitsregel auf Satzebene: Ähnlich wie die Gültigkeit eines Feldwertes kann auch die Gültigkeit des ganzen Satzes überprüft werden, bevor dieser in die Datenbank geschrieben wird. Das ermöglicht die Überprüfung von Feldern, die voneinander abhängig sind. Eine solche Überprüfung von abhängigen Feldern ist auf Feldebene schwer zu machen, da die Prüfung erst sinnvoll durchgeführt werden kann, wenn alle Werte angegeben sind. Dank GUI und Mausbedienung wissen Sie als Entwickler aber nie, wann das der Fall ist - es sei denn, der/die Anwender/in will den gerade bearbeiteten Satz speichern. Deshalb führt Visual FoxPro die Prüfung der Gültigkeitsregel auf Satzebene direkt vor dem Speichern aus.
• Hierbei ist jetzt aber die Frage der Pufferung wichtig. Wenn Sie, wie bisher unter FoxPro 2.6, mit einer ungepufferten Tabelle arbeiten, wird die Gültigkeitsregel auf Satzebene sofort nach einer Änderung an einem Tabellenfeld überprüft. Dies führt unter Umständen zu einem Konflikt, da eine solche Regel ja voneinander abhängige Felder überprüft, die alle erst mit den richtigen Werten versorgt werden müßen. Ein satzweises Puffern ist also in den meisten Fällen erforderlich, wenn Sie eine Gültigkeitsregel auf Satzebene verwenden wollen.
• Gültigkeitstext: Auch für die Gültigkeitsregel auf Satzebene ist ein Text hinterlegbar, der ausgegeben wird, wenn die Regel verletzt wird. Dieser Text wird allerdings nur vom BROWSE-Befehl ausgegeben. Wenn Sie den Text auch aus Ihren Ein-/Ausgabeformularen heraus ausgeben wollen, müssen Sie ihn zunächst mit DBGETPROP() aus dem DBC in eine Variable auslesen.
• Trigger: Zu den Tabelleneigenschaften gehören auch die INSERT-, UPDATE- und DELETE-Trigger. Dies sind Ausdrücke, die jedesmal ausgewertet werden, wenn ein Datensatz angehängt, verändert oder gelöscht wird. Die Trigger-Ausdrücke müssen .T. oder .F. zurückgeben. Abhängig vom Rückgabewert wird der Befehl, der den Trigger ausgelöst hat, durchgeführt (bei Rückgabe .T.) oder nicht (Rückgabe .F.). Triggerausdrücke rufen im allgemeinen in der Datenbank gespeicherte Prozeduren auf, die zum einen prüfen, ob die auslösende Aktion ausgeführt werden darf und zum anderen notwendige Folgeaktionen durchführen.

Trigger benutzt man häufig dazu, die referentielle Integrität (RI) sicherzustellen. Ein solcher Trigger verhindert zum Beispiel, daß ein Lagerteil gelöscht wird, für das noch Bestellungen gespeichert sind. Derselbe Trigger sorgt auch dafür, daß beim Löschen eines Lagerteils alle Bewegungsdaten ebenfalls gelöscht werden und so weiter. RI-Trigger aufzubauen, ist nicht trivial. Visual FoxPro bietet einen Assistenten für referentielle Integrität an, der den erzeugten Code in Form von gespeicherten Prozeduren in der Datenbank ablegt und im Trigger-Ausdruck der jeweiligen Tabelle diesen Code aufruft. Der von diesem Assistenten generierte Code ist ausreichend, wenn a) keine zusammengesetzten Schlüssel verwendet werden und b) die Triggeraktionen auf Kaskadierung (Weitergeben einer Lösch- oder Änderungsaktion an die untergeordnete Tabelle), Restriktion (Verhindern der Aktion) und Ignorieren beschränkt werden können. Zusatztools zu Visual FoxPro, wie das E-R??? Modelling Tool xCase bieten weitergehende Möglichkeiten an. So können von xCase erzeugte Trigger mit zusammengesetzten Schlüsseln umgehen. xCase bietet beim Löschen eines Satzes der übergeordneten Tabelle auch die Triggeraktion Nullify an, also das automatische Leeren des Fremdschlüssels in der untergeordneten Tabelle.

Indexarten

Visual FoxPro kennt vier Arten von Indizes: Primärindex, potentielle Primärindizes, eindeutige und einfache Indizes. Ein einfacher Index ist ein Index, wie er bisher aus FoxPro 2.6 bekannt war. Für einen einfachen Index wird keine Prüfung auf Eindeutigkeit vorgenommen. Einfache Indizes dienen hauptsächlich zur Unterstützung der Zugriffsoptimierung durch das Rushmore-Verfahren und zur Anzeige der Tabelleninhalte in bestimmten Sortierungen. Auch der "eindeutige" Index, bisher als "unique" bekannt und zur Sicherstellung der Abwärtskompatibilität unterstützt, wird nicht eigentlich auf Eindeutigkeit überprüft. Es wird lediglich bei mehrfachem Vorkommen eines Indexwertes nur das erste Vorkommen gespeichert und die weiteren ignoriert - ein Verfahren, dessen tieferer Sinn mir bisher verborgen geblieben ist.

Neu und wichtig sind die potentiellen Primärindizes. Diese werden jetzt nämlich tatsächlich auf Eindeutigkeit geprüft, und Visual FoxPro weigert sich, einen Datensatz in einer Tabelle abzulegen, der die Eindeutigkeit eines potentiellen Primärindex verletzen würde. Der als tatsächlicher Primärindex ausgewiesene Index ist also nur primus inter pares, jeder potentielle Primärindex kann zum tatsächlichen Primärindex gemacht werden.

Persistente Beziehungen

Beziehungen zwischen DBC-gebundenen Tabellen können im Datenbankdesigner bereits festgelegt und im DBC gespeichert werden. Beim Öffnen einer Datenbank werden diese Beziehungen aber nicht automatisch aufgebaut. Dies ist nämlich die Aufgabe eines Datenumgebungs-Objektes, das jeder Ein-/Ausgabemaske und jedem Report zugeordnet werden kann. Beim Eintrag von Tabellen in einem Datenumgebungs-Objekt werden die zwischen den Tabellen bestehenden und im DBC gespeicherten Beziehungen übernommen. Auch der unten beschriebene Ansichtsdesigner nutzt die im DBC gespeicherten Informationen und baut die Beziehungen zwischen den gewählten Tabellen automatisch auf. Neben den persistenten, also dauerhaften Beziehungen besteht nach wie vor die Möglichkeit, temporäre Beziehungen mit SET RELATION TO ... INTO ... aufzubauen.

DBC-gebundene und freie Tabellen

Die oben beschriebenen Feld- und Tabelleneigenschaften gelten komplett nur für DBC-gebundene Tabellen. Tabellen, die nicht an einen DBC gebunden sind, werden freie Tabellen genannt. Visual FoxPro kann solche freien Tabellen sowohl im alten, d.h. FoxPro 2.x-kompatiblen Format, als auch im neuen Format verarbeiten. Für freie Tabellen im alten Format gelten natürlich die neuen Feldformate, die längeren Feldnamen und anderen Eigenschaften nicht. Freie Tabellen im neuen Format können jedoch die neuen Feldtypen beinhalten. Lange Feldnamen, Gültigkeitsregeln, Feldbezeichnungen, Primärkeys und Trigger werden aber im DBC abgespeichert und stehen von daher für freie Tabellen nicht zur Verfügung. Sollte dies einmal erforderlich werden, helfen auch hier Zusatztools von Drittanbietern weiter. In dem oben bereits erwähnten E-R Modelling Tool xCase können freie Tabellen und DBC-gebundene Tabellen in einem Modell zusammengeführt werden, wobei RI-Code momentan??? ebenfalls nur für die DBC-gebundenen Tabellen generiert wird. In der für Juni '96 angekündigten??? Professional-Version soll RI-Code auch für die freien Tabellen generiert werden. Bei den für FoxPro verfügbaren Applikations-Generatoren, die ein eigenes Data-Dictionary mitführen, ist das seit jeher so und gilt auch für die Visual FoxPro Versionen. In Visual ProMatrix zum Beispiel, einem Applikations-Generator für Visual FoxPro, werden freie und DBC-gebundene Tabellen gleichberechtigt mit allen Eigenschaften und eigenem Integritätscode im eigenen DD geführt. Dafür hapert es hier noch!!! mit der Integration zwischen DBC und Data-Dictionary, da für die Arbeit mit Visual ProMatrix ein DBC eigentlich gar nicht gebraucht wird.

Ansichten (Views)

Eine Ansicht, oder View, ist eine virtuelle Tabelle, in der Daten aus einer oder mehreren anderen Tabellen zusammengefaßt sind. Eine Ansicht enthält nur die Felder der Basistabellen, die in der Definition der Ansicht vorgesehen sind. Datensätze der Basistabellen können zu einem Datensatz in der Ansicht gruppiert sein; ebenso ist es möglich, daß die Ansicht die Daten der Basistabellen in einer anderen Sortierung ausgibt. Die Basistabellen einer Ansicht können lokale, das heißt FoxPro-eigene Tabellen, oder entfernte, über eine ODBC-Verbindung erreichte Tabellen eines Datenbankservers sein. Eine vorher erstellte Ansicht kann selbst wieder Basistabelle einer weiteren Ansicht sein.

Bild 2: Der Ansichtsdesigner von Visual FoxPro

Zum Erstellen von Ansichten bietet Visual FoxPro einen Ansichtsdesigner an. Dort werden zunächst die Tabellen angegeben, die in die Ansicht einbezogen werden sollen. Aus diesen Tabellen können dann die benötigten Felder ausgewählt werden. Auf weiteren Seiten des Ansichtsdesigners können Sortierung und Gruppierung der abzurufenden Daten festgelegt werden. Auf der letzten, im Bild dargestellten Seite wird bestimmt, wie die Aktualisierung der Basisdaten durchgeführt werden soll. Aktualisierungen werden grundsätzlich nur gesendet, wenn das dafür vorgesehene Kontrollkästchen angekreuzt ist. Um Aktualisierungen senden zu können, muß für jede zu aktualisierende Tabelle ein Schlüsselfeld angegeben werden. Dieses Schlüsselfeld muß nicht unbedingt mit einem Index belegt sein (was sich aus Gründen der Zugriffsoptimierung aber anbietet) und muß nicht eindeutig sein. Die zu aktualisierenden Felder können ebenfalls einzeln angegeben werden.

Aktualisierungen werden wahlweise über einen SQL-UPDATE Befehl oder über einen SQL-DELETE mit anschließendem SQL-INSERT durchgeführt. Der Aktualisierungsbefehl kann vor dem Aktualisieren abprüfen, ob die Basisdaten zwischenzeitlich von anderen Anwendern verändert wurden. Diese Abprüfung erstreckt sich wahlweise a) nur auf die als Schlüsselfelder markierten Felder, b) auf die Schlüsselfelder und alle aktualisierbaren Felder oder c) auf die Schlüsselfelder und die tatsächlich geänderten Felder. Die Option, daß die Schlüsselfelder und ein Zeitstempel des jeweiligen Basisdatensatzes überprüft werden, ist nur bei Remote Views, also bei Ansichten von Daten eines über OBDC verbundenen Datenbankservers verfügbar.

Aus den Angaben im Ansichtsdesigner generiert Visual FoxPro das benötigte SQL-Statement, das zur Kontrolle auch angezeigt werden kann. Programmgesteuert kann eine Ansicht mit dem Befehl CREATE SQL VIEW <Name der Ansicht> AS SELECT ... FROM ... aufgebaut werden.

Client/Server-Programmierung

Ansichten werden vom Programm wie FoxPro-eigene Tabellen behandelt. Alle xBase-Befehle zum Navigieren innerhalb einer Tabelle, Ändern von Daten in einer Tabelle und Anhängen neuer Datensätze an eine Tabelle funktionieren auch für Ansichten. Es ist also ohne weiteres möglich, über eine Ansicht die Daten eines Datenbankservers mit xBase-Befehlen zu manipulieren. Allerdings sollte man dabei immer im Auge behalten, daß diese Daten auf anderen Wegen zur Verfügung gestellt werden als Daten aus lokalen Tabellen. Die Erstellung einer Client/Server-Anwendung mit Hilfe von Ansichten benötigt daher noch ein gehöriges Maß an Feineinstellungen, um zum Beispiel zu verhindern, daß mehrere Millionen Datensätze über das Netz geschickt werden, obwohl nur einige wenige gebraucht werden. Visual FoxPro bietet dazu unterschiedliche Hilfsmittel an. Das erste und wichtigste ist, daß Ansichten parametrisiert werden können. Mit vorangestelltem Fragezeichen können Speichervariablen in die Auswahlkriterien aufgenommen werden. "?KundenNr" veranlaßt Visual FoxPro vor dem Senden des Abruf-Statements an den Datenbankserver, die Variable "KundenNr" auszuwerten und deren aktuellen Inhalt in das zu sendende Statement einzufügen. Wenn die Variable "KundenNr" nicht definiert ist, fordert Visual FoxPro den Anwender vor dem Senden des SQL-SELECTs auf, einen Wert für "KundenNr" einzugeben. Normalerweise bestückt jedoch das Anwendungsprogramm die als Ansichtsparameter verwendeten Variablen, um nur eine begrenzte Auswahl an Daten abzurufen. Wenn sich der Wert für den Ansichtsparameter ändert, weil der Anwender nun zum Beispiel die Daten eines anderen Kunden sehen will, reicht ein Aufruf der REQUERY()-Funktion, um die Ansicht mit dem aktuellen Parameterwert neu erstellen zu lassen.

[1 ] [2 ] [3 ]