Ansichten (InterBase und Firebird)

Alexey Kovyazin, letzte Aktualisierung 13. April 2012

Diejenigen, die mit der SQL-Sprache vertraut sind, benötigen keine detaillierten Erklärungen zu diesem Thema, aber um die Reihenfolge der Darstellung beizubehalten, werden wir eine kurze Definition von Views einführen.

VIEW ist eine virtuelle Tabelle, die auf der Grundlage einer Abfrage an normale Tabellen erstellt wird. Ein View wird als Abfrage implementiert, die auf dem Server gespeichert und bei jedem Zugriff auf den View ausgeführt wird.

Betrachten wir verschiedene Varianten der Verwendung von Views. Views ermöglichen es, Ebenen der Datenstruktur zu erstellen, die es erlauben, die Implementierung der Datenspeicherung von ihrer Art zu trennen. Zum Beispiel können wir einen View erstellen, der Daten aus mehreren Tabellen auswählt. Wenn die Clients diesen View anstelle eines direkten Zugriffs auf die zugrunde liegenden Tabellen verwenden, kann der Datenbankentwickler die dem View zugrunde liegende Abfrage ändern, um sie zu verändern (z. B. zu optimieren), und der Client wird nichts bemerken - es bleibt für ihn derselbe View. Abgesehen davon, dass sie die Implementierung der Datenspeicherung vom Benutzer isolieren, ermöglichen Views, die Daten bequemer und einfacher zu organisieren. Das Problem der “Vereinfachung” der Datenstruktur entsteht, wenn die Anzahl der Tabellen in einer Datenbank groß genug wird und die Beziehungen zwischen ihnen kompliziert sind. Ein View ermöglicht es, einen Teil der Daten zu eliminieren (oder im Gegenteil hinzuzufügen), der für den konkreten Datenbank-Client nicht notwendig ist (oder - notwendig).

Darüber hinaus ermöglichen Views, die Sicherheit in der InterBase-Datenbank einfacher zu organisieren. Einige Benutzer können nur Rechte zum Lesen / Aktualisieren der Daten im View haben, aber keine Rechte (und nicht einmal eine Ahnung) über die dem View zugrunde liegenden Tabellen! Weitere Details zur Sicherheit in InterBase finden Sie im Kapitel “Sicherheit in InterBase: Benutzer, ihre Funktionen und Rechte” (Teil 4).

DDL-Syntax für die Arbeit mit Views

Nun betrachten wir die Befehle zum Erstellen und Löschen von Views, die durch DDL (Data Definition Language - SQL-Teilmenge, siehe Glossar) definiert sind. Um einen View in InterBase zu erstellen, sollten wir den Satz mit der folgenden Syntax verwenden:

CREATE VIEW viewname [(view_column[, view_column…])] AS [WITH CHECK OPTION]; Hier ist viewname der Name des Views, der innerhalb einer Datenbank eindeutig sein muss, und danach folgt eine Gruppe von nicht immer obligatorischen Namen der im View enthaltenen Felder: [(view_column [, view_column …])]. Es ist wesentlich, die Anweisung zu definieren, die die im View enthaltenen Daten auswählt. Wir werden den optionalen Parameter WITH CHECK OPTION etwas später im Teil “Modifizierte Views” besprechen.

Um den View zu ändern, müssen wir ihn neu erstellen, d. h. löschen und wieder neu anlegen. Beim Löschen des Views ist es notwendig, auch alle abhängigen Objekte zu löschen - die Trigger, gespeicherten Prozeduren und andere Views. Dies ist eine der Hauptunannehmlichkeiten bei der Arbeit mit Views: die Notwendigkeit, den Baum der Objekte, die den View verwenden, neu zu erstellen (es gibt Dienstprogramme, die dies erleichtern, z. B. IBAlterView, siehe die Anwendung “Administrator- und InterBase-Designer-Tools”). Wir sollten den folgenden DDL-Befehl verwenden, wenn wir den View löschen möchten:

DROP VIEW viewname;

Beispiele für Views

Hier ist ein Beispiel für einen einfachen View:

CREATE VIEW MyView AS SELECT NAME, PRICE_1 FROM Table_example;

In diesem Beispiel erstellen wir einen View basierend auf einer Abfrage an die Tabelle Table_example, die wir im Kapitel “Tabellen. Primärschlüssel und Generatoren” betrachtet haben. In diesem Fall besteht der View aus zwei Feldern - NAME und PRICE_1, die ohne Bedingungen aus der Tabelle Table_example ausgewählt werden, d. h. die Anzahl der Datensätze im View MyView entspricht der Anzahl der Datensätze in Table_example. Allerdings sind Views nicht immer so einfach. Sie können auf Daten aus mehreren Tabellen und sogar auf der Grundlage anderer Views basieren. Darüber hinaus können Views Daten enthalten, die auf der Grundlage verschiedener Ausdrücke erhalten wurden - einschließlich auf der Grundlage von Aggregatfunktionen. Um die Verwendung dieser View-Anwendung genauer zu betrachten, erstellen wir zwei Tabellen, die durch eine Eins-zu-Viele-Beziehung verbunden sind (eine solche Beziehung wird oft als Master-Detail bezeichnet). Hier ist das DDL-Skript zum Erstellen dieser Tabellen:

/\* Tabelle: WISEMEN */

CREATE TABLE WISEMEN ( ID_WISEMAN INTEGER NOT NULL, WISEMAN_NAME VARCHAR(80));

/\* Definition der Primärschlüssel */

ALTER TABLE WISEMEN ADD CONSTRAINT PK_WISEMEN PRIMARY KEY (ID_WISEMAN);

/\* Tabelle: WISEBOOK */

CREATE TABLE WISEBOOK ( ID_BOOK INTEGER NOT NULL, ID_WISEMAN INTEGER, BOOK VARCHAR(80));

/\* Definition der Primärschlüssel */

ALTER TABLE WISEBOOK ADD CONSTRAINT PK_WISEBOOK PRIMARY KEY (ID_BOOK);

/\* Definition der Fremdschlüssel */

ALTER TABLE WISEBOOK ADD CONSTRAINT FK_WISEBOOK FOREIGN KEY (ID_WISEMAN) REFERENCES WISEMEN (ID_WISEMAN);

Wir haben also zwei Tabellen erstellt - WISEMEN und WISEBOOK, die durch eine Master-Detail-Beziehung über eine Fremdschlüssel-Constraint - FOREIGN KEY - verbunden sind. Nehmen wir an, diese Tabellen speichern Informationen über die großen chinesischen Weisen und ihre Werke. Jetzt können wir ein paar Views basierend auf diesen Tabellen erstellen. Zum Beispiel erstellen wir einen View, der anzeigt, wie viele Werke jeder Weise hat:

CREATE VIEW WiseBookCount (WISEMAN, HOW_WISEBOOKS) AS SELECT M.WISEMAN_NAME, COUNT(B.BOOK) FROM WISEMEN M, WISEBOOK B WHERE (M.ID_WISEMAN = B.ID_WISEMAN) GROUP BY M.WISEMAN_NAME

Beachten Sie, dass bei der Verwendung von berechneten Ausdrücken wie Aggregatfunktionen COUNT (), SUM (), MAX () usw. die Verwendung bestimmter Namen der View-Felder wesentlich ist, d. h. allen von der Abfrage zurückgegebenen Feldern müssen Namen gegeben werden. Wie aus diesem Beispiel ersichtlich ist, müssen diese Namen nicht unbedingt mit den Namen der Abfragefelder übereinstimmen, aber ihre Anzahl muss mit der Anzahl der von der Abfrage zurückgegebenen Felder übereinstimmen. Die Zuordnung, welches von der Abfrage zurückgegebene Feld welchem Feld des Views entspricht, erfolgt durch eine Seriennummer - das erste Abfragefeld wird im ersten Feld des Views widergespiegelt, das zweite im zweiten usw.

Und wenn wir wissen möchten, welcher der Weisen die meisten Bücher geschrieben hat? Wir werden versuchen, den Ausdruck zum Sortieren - ORDER BY - zur dem View zugrunde liegenden Abfrage hinzuzufügen. Dieser Versuch wird jedoch erfolglos sein: Die Verwendung der Sortierung ORDER BY in Views ist nicht erlaubt, und beim Versuch, einen View mit einer Abfrage zu erstellen, die ORDER BY enthält, wird ein Fehler auftreten. Wenn wir die vom View zurückgegebenen Ergebnisse sortieren möchten, müssen wir dies im Namen des Clients tun:

SELECT * FROM WiseBookCount ORDER BY HOW_WISEBOOKS

Die Ausführung dieser SQL-Abfrage führt zu einem wünschenswerten Ergebnis. Abgesehen von der Einschränkung für die Verwendung des Ausdrucks ORDER BY in Views können wir auch keinen Datensatz, der als Ergebnis der Ausführung gespeicherter Prozeduren erhalten wurde, als Datenquelle verwenden (siehe Kapitel “Gespeicherte Prozeduren” weiter unten).

Vielleicht lohnt es sich, ein weiteres Beispiel zur Veranschaulichung der Anwendung von Views zu geben. Nehmen wir an, wir müssen eine Liste von Weisen ausgeben, deren Name mit dem Buchstaben “K” beginnt. In diesem Fall verwenden wir den View mit Bedingungen:

CREATE VIEW WiseMen2 (WISEMAN) AS SELECT M.WISEMAN_NAME FROM WISEMEN M WHERE M.WISEMAN_NAME LIKE ‘K%’

So ist es einfach, Views zu erstellen, die eine Rolle als ständig aktualisierbare Datenlieferanten spielen, indem sie Daten aus einer Datenbank gemäß bestimmten Bedingungen auswählen.

Modifizierte Views

Wir haben oben erwähnt, dass es eine Möglichkeit gibt, modifizierte Daten-Views zu erstellen. Es ist wirklich so - es gibt eine Möglichkeit, nicht nur Daten aus dem View zu lesen, sondern sie auch zu modifizieren!

Es gibt zwei Möglichkeiten, den View modifiziert zu machen. Der erste Weg wird angewendet, wenn der View auf der Grundlage einer einzigen Tabelle (oder eines anderen modifizierten Views) erstellt wird, und alle Spalten der gegebenen Tabelle das Vorhandensein von NULL erlauben müssen. Somit darf die Abfrage, auf der der View basiert, keine Unterabfragen, Aggregatfunktionen, UDF, gespeicherten Prozeduren, DISTINCT- und HAVING-Anweisungen enthalten. Wenn alle diese Bedingungen erfüllt sind, wird der View automatisch modifiziert, d. h. wir können die Abfragen DELETE, INSERT und UPDATE für ihn ausführen, die die Daten in einer Quelltabelle ändern.

Die Liste der Bedingungen ist ziemlich beeindruckend und schränkt die Anwendung solcher modifizierten Views stark ein, folglich werden sie ziemlich selten verwendet.

Um einen modifizierten View zu erstellen, der eine der oben genannten Bedingungen verletzt, wird der Mechanismus der Trigger angewendet. Weitere Details zum Trigger finden Sie im Kapitel “Trigger” (Teil 1). Jetzt betrachten wir nur allgemeine Prinzipien der Organisation der Datenänderung in VIEW.

Für die Implementierung eines aktualisierten Views mithilfe von Triggern muss Folgendes getan werden. Erstellen Sie 3 Trigger für den gegebenen View für Ereignisse: BEFORE DELETE, BEFORE UPDATE und BEFORE INSERT. Beschreiben Sie in diesen Triggern, was mit den Daten beim Löschen, Aktualisieren und Einfügen geschehen soll.

Dann sollten wir den gegebenen View in Modifikationsabfragen verwenden - DELETE, INSERT oder UPDATE. Wenn InterBase diese Abfrage erhält, prüft es, ob geeignete Trigger für den gegebenen View vorhanden sind, d. h. BEFORE DELETE/INSERT/UPDATE. Wenn der Trigger für die ausführbare Aktion existiert, ruft InterBase ihn zur Modifikation der realen Daten in den dem View zugrunde liegenden Tabellen auf (obwohl es auch andere Daten sein können - es gibt keine Textbeschränkungen für diese Trigger) und liest dann die Zeile (oder Zeilen), über die die Modifikation durchgeführt wurde, erneut.

Somit gibt es eine Möglichkeit, komplexe Ketten der Datenaktualisierung in Views zu realisieren.

Die Option WITH CHECK OPTION wurde in der Beschreibung der Syntax zum Erstellen von Views erwähnt. Wenn diese Option beim Erstellen eines modifizierten Views gesetzt ist, wird jede in diesen View eingefügte oder geänderte Datenzeile auf eine Bedingung des Erreichens des Views geprüft. Es kann so erklärt werden: Wenn ein neuer Datensatz, der vom Benutzer eingefügt oder als Ergebnis der Aktualisierung des vorhandenen Datensatzes erhalten wurde, die Bedingungen der Abfrage, die der Datenlieferant für VIEW ist, nicht erfüllt, wird das Einfügen dieses Datensatzes abgebrochen und ein Fehler tritt auf.

Fazit

Trotz der scheinbaren Einfachheit des Erstellens und Verwendens von Views bieten sie große Möglichkeiten zur Verbesserung der Datenorganisation in einer Datenbank und ermöglichen die Erstellung einer Hierarchie der Datenorganisation.

Einige Designer von Datenbankanwendungen verwenden Views sehr oft in ihrer Arbeit, andere vermeiden ihre Anwendung und begründen dies mit einer Komplexität der Modifikation von Views und der Tendenz, das Datenbankschema so einfach und effektiv wie möglich zu halten. Es liegt an Ihnen, wie Sie Views in Ihrer Arbeit anwenden. Das Wichtigste ist, sich an die Existenz eines so leistungsfähigen Werkzeugs wie View zu erinnern und zu wissen, wie man es verwendet.