Unterabfragen und mehrfache Tabelleninstanzen (QUERY, ALIAS)

Unter Umständen stellt sich bei der Konzeption einer Virtab das Problem, dass eine beteiligte Tabelle mehrfach von verschiedenen anderen Tabellen referenziert wird. Solch eine Tabelle liefert mehrere Records, wobei gleiche Felder verschiedneer Records unter je naderem Namen in der Virtab veröffentlicht sind.
Zur Illustration ist das Beispiel 7, Virtab letter_data heranzuziehen, in dem sowohl DEPARTMENTS als auch CUSTOMER auf ADDRESS verweisen, es also pro Virtab-Datensatz zwei Fremdschlüsselreferenzen auf ADDRESS. Somit müssen pro Virtab-Operation zwei aktuelle Zeilen in der Tabelle ADDRESS verwaltet werden  (zwei "Queries" bzw. Teilabfragen). Die verschiedenen Queries werden durch Bezeichner (hier: 'q_customer' und 'q_employee') voneinander unterschieden. Tabellen, für die keine Query angegeben ist, werden einer Default-Query 'A' zugeordnet.

Die Definitionsdatei für diese Situation sieht so aus:

VIRTUALTABLE letter_data /* ein CUSTOMER und sein ADDRESS      werden als Query Q_CUSTOMER angesprochen,    ein EMPLOYEE, sein DEPARTMENT und ADDRESS des Departments      werden als Query Q_EMPLOYEE angesprochen    Query Q_MAIN buendelt Q_CUSTOMER und Q_EMPLOYEE */ TABLE address    QUERY q_customer ALIAS cust_address TABLE customer   QUERY q_customer, q_main TABLE address    QUERY q_employee ALIAS emp_address  NOCHANGE TABLE department QUERY q_employee    NOCHANGE TABLE location   QUERY q_employee    NOCHANGE TABLE employee   QUERY q_employee, q_main    FOREIGNKEY customer.salesperson_id NOCHANGE // Spalten der Q_CUSTOMER-Query COLUMN cust_name     = customer.name COLUMN cust_street   = cust_address.street COLUMN cust_city     = cust_address.city COLUMN cust_state    = cust_address.state COLUMN cust_zip_code = cust_address.zip_code // Spalten der Q_EMPLOYEE-Query COLUMN emp_first_name = employee.first_name COLUMN emp_last_name = employee.last_name COLUMN emp_street    = emp_address.street COLUMN emp_city      = emp_address.city COLUMN emp_state     = emp_address.state COLUMN emp_zip_code  = emp_address.zip_code COLUMN emp_department = department.name COLUMN emp_loc       = location.regional_group

In diesem Beispiel wird ADDRESS einerseits unter dem Alias “cust_address” mit CUSTOMER verknüpft (Query “q_customer”), andererseits unter dem Alias “emp_address” mit DEPARTMENT (Query “q_employee”). Diese beiden Queries haben zunächst untereinander noch keinen gemeinsamen Berührungspunkt. Beide Teilabfragen werden daher durch die Query “q_main” miteinander verknüpft. Über die FOREIGNKEY-Anweisung wird die zu benutzende Verknüpfungsstruktur spezifiziert, da es zwei mögliche Fremdschlüsselverweise auf EMPLOYEE gibt (employee.manager_id und customer .salesperson_id).

Datensätze in Query “Q_Employee”

Datensätze in Query “Q_Customer”

Mehrfachzugriffe auf eine Tabelle innerhalb einer Abfrage führt ER2SQL so durch, als gäbe es die entsprechende Tabelle mehrfach, nämlich einmal pro Query. Dabei werden die verschiedenen Queries durch Bezeichner voneinander unterschieden. Es werden mehrere Pseudonyme mit den Namen <table>_<nr> (also z.B. ADDRESS_1) für die entsprechende Tabelle angelegt und zwar in Form von Views (CREATE VIEW address_1 AS SELECT * FROM address). Alle diese Pseudonyme sprechen aber dieselbe Datenbank-Tabelle an.

Innerhalb der Virtab-Definition werden die verschiedenen Pseudonyme über den Alias-Namen unterschieden und angesprochen. Fehlt die Alias-Definition, wird der Name der Datenbanktabelle dafür angenommen.

Die verschiedenen Unterabfragen in einer Virtab werden dadurch miteinander verknüpft, dass immer mindestens eine Tabelle zu mehreren Queries gehört. Diese Tabelle(n) kann/können nur einen aktuellen Datensatz pro Virtab-Record haben. Dieser muss für alle beteiligten Queries der gleiche sein. Im Beispiel muss z.B. EMPLOYEE zu den Queries “q_employee” und “q_main” gehören, und CUSTOMER zu den Queries “q_customer” und “q_main”, um alle Unterabfragen der Virtab zusammenzuführen.

Datensätze in Query “Q_Main”

Um einen (Gesamt-)Virtab-Record zu bilden, muss zunächst in jeder beteiligten Tabellen -Instanz ein Teil-Record lokalisiert werden (hier also 4 aus 3 physikalischen Tabellen). Innerhalb der Teil-Queries läuft das Raussuchen über die beschriebenen Mechanismen. Untereinander sind die Teil-Queries dann noch zu 'synchronisieren'. Dies geschieht über die Ermittlung identischer Inhalte von Spalten der gleichen Tabelleninstanzen, die als Schnittmenge jeweils in den Teil-Queries vorkommen (hier: EMPLOYEE und CUSTOMER).

Datensätze in der Virtab “VT_Letter_Data”:

Im Diagramm ist folgendes dargestellt:

• Ein einzelner Record aus Tabelle EMPLOYEE  kommt in den Queries Q_Employee (blau) und Q_Main (grün) vor und synchronisiert so Q_Employee und Q_Main.
• Ein einzelner Record aus Tabelle CUSTOMER  kommt in den Queries  Q_Main (grün) und Q_Customer (rot) vor und synchronisiert so Q_Main und Q_Customer.
• Auf Tabelle ADDRESS wird zweimal zugegriffen.
  Ein Record stammt aus dem Table-Alias “emp_address”  = “Table ADDRESS, Query Q_Emp” (blaue Query),
  ein weitere Record kommt aus Table-Alias “custaddress” = “Table ADDRESS, Query Q_Customer” (rote Query).