|
/////////////////////////////////////////////////////////////////////
// Beispiel 7:
// QUERIES und FOREIGNKEY.
// Anschrift eines Customers zusammen mit der Anschrift
// der SALES_PERSON darstellen.
// Customer-ddresse und Customer als Query Q_CUSTOMER
// Customer kann manipuliert werden, EMP ist fest (NOCHANGE)
VIRTUALTABLE letter_data
TABLE address QUERY q_customer ALIAS cust_address
TABLE customer QUERY q_main,q_customer
// EMPLOYEE, sein DEPARTMENT und Adresse des Departments als
// Query Q_EMPLOYEE
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
// 1. FOREIGNKEY wurde als Reaktion auf die Fehlermeldung
// ##0064ausgewaehlt
// "mehrere FOREIGNKEYs auf Table EMPLOYEE in Query Q_MAIN,
// Q_EMPLOYEE moeglich:
// CUSTOMER.SALESPERSON_ID EMPLOYEE.MANAGER_ID , bitte einzeln
// angeben"
//
// 2. Bedeutung des NOCHANGE: Soll in EMPLOYEE eingefuegt werden,
// Muss auch der Manager des EMPLOYEE mit angegeben werden.
// -> Lieber NOCHANGE, Employees nicht uber VT LETTER_DATA pflegen
// 3. Table LOCATION muss dazu genommen werden, da DEPARTMENT nur
// in Verbindung mit einer REGIONAL_GROUP identifiziert ist
// (SALES in Boston, SALES in New York).
// Die stored procedures wollen DEPARTMENT genau lokalisieren.
// Es ware ja denkbar, dass in einer UPDATE-Procedure EMPLOYEE
// mit einem anderen DEPARTMENT verbunden wird (hier nicht moegl,
// da EMPLOYEE selbst auch NOCHANGE.)
// Query Q_MAIN buendelt Q_CUSTOMER und Q_EMPLOYEE
// 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
// 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
;
// 1. Schritt: TABLE Anweisungen zum Festlegen der Abfragestruktur
// 2. Schritt COLUMN Anweisungen zur Spaltenauswahl
// 3. Schritt CONSTRAINT Anweisungen zur Zeilenauswahl
// 4. Schritt Debugging:
// TABLE ... FOREIGNKEY ergaenzen.
// 5. Sicherheitscheck: Text der VIEW VT_... verifizieren.
VIRTUALTABLE letter_data_emp NOCHANGE
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
NOFOREIGNKEYS // Damit manager_id ignoriert wird
// 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
;
VIRTUALTABLE letter_data_cust NOCHANGE
TABLE address QUERY q_customer ALIAS cust_address
TABLE customer QUERY q_customer
// EMPLOYEE, sein DEPARTMENT und Adresse des Departments als
// Query Q_EMPLOYEE
// 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
;
// Customer-ddresse und Customer als Query Q_CUSTOMER
// Customer kann manipuliert werden, EMP ist fest (NOCHANGE)
VIRTUALTABLE letter_data_main NOCHANGE
TABLE customer QUERY q_main
TABLE EMPLOYEE QUERY Q_MAIN
FOREIGNKEY CUSTOMER.SALESPERSON_ID
NOCHANGE
// Query Q_MAIN buendelt Q_CUSTOMER und Q_EMPLOYEE
// Spalten der Q_EMPLOYEE-Query
COLUMN emp_first_name = EMPLOYEE.first_name
COLUMN emp_last_name = EMPLOYEE.last_name
// Spalten der Q_CUSTOMER-Query
COLUMN cust_name = customer.name
;
|
