Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 2: Aktualizowalne perspektywy (1)

Temat wirtualnych perspektyw Temat wirtualnych perspektyw dla relacyjnych baz danych został sformułowany przez E.Codda w 1974 roku. Jest to zagadnienie o ogromnej wadze praktycznej, gdyż wirtualne perspektywy są ważne dla wielu zastosowań baz danych. Temat ten jest znany z SQL i został doceniony przez twórców obiektowo-relacyjnego manifestu baz danych. Od nieomal 30 lat nad tym tematem pracowało dziesiątki lub setki specjalistów. Powstało na ten temat setki publikacji i praktycznych implementacji, w prototypowych i komercyjnych systemach. Najbardziej istotnym problemem jest aktualizacja wirtualnych danych (obiektów). Problem nie doczekał się dostatecznie uniwersalnego rozwiązania na gruncie systemów relacyjnych i  zyskał sobie sławę „arcytrudnego”. Klasyczne rozwiązania w systemach relacyjnych są ograniczone i nie są w stanie spełnić tych oczekiwań, które są często przedstawiane jako motywacja dla podjęcia tego tematu.

Rozwiązanie arcytrudnego tematu Stosunkowo najbardziej zaawansowane są rozwiązania oparte na tzw. instead of trigger (tryger „zrób zamiast”) w systemach Oracle i MS SQL Server. To rozwiązanie wskazuje kierunek, w którym powinny pójść badania. Rozwiązanie objaśnione w tym wykładzie idzie dokładnie w tym kierunku, ale jest oparte na innym, znacznie bardziej uniwersalnym mechanizmie. Pokażemy, że ten „arcytrudny” temat jest jak najbardziej do opanowania, jeżeli założy się dobre podejście. Jest nim podejście stosowe do języków zapytań.

Co to jest perspektywa? - pogląd 1 view, database view W literaturze funkcjonują dwa różne (zbliżone) znaczenia. 1. Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych (określającego zapamiętane zasoby danych) na schemat “zewnętrzny”, przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika. Użytkownik 1 Użytkownik 2 Użytkownik 3 Architektura ANSI/SPARC: Schematy “zewnętrzne” Perspektywa 1 Perspektywa 2 Perspektywa 3 Projektant BD Administrator BD Schemat globalny Poziom fizyczny bazy danych Administrator BD

Co to jest perspektywa? - pogląd 2 2.Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne. Matematycznie, perspektywa jest funkcją określoną na danych. Ten punkt widzenia nie jest precyzyjny, gdyż nie uwzględnia mechanizmów nazywania, wiązania i zakresu. Nie uwzględnia także kwestii aktualizacji perspektyw. Nieco bardziej precyzyjny punkt widzenia (systemy relacyjne): Perspektywa jest procedurą funkcyjną, która zwraca wynik będący tabelą. Taki wynik jest wyposażony w dodatkowe nazwy (nazwy atrybutów wirtualnych tabel zwracanych przez perspektywę). Perspektywy SQL są uproszczonymi procedurami funkcyjnymi. Ten punkt widzenia również nie uwzględnia kwestii aktualizacji perspektyw

Po co są perspektywy? Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich bardzo aktualny temat. Uproszczenie modeli pojęciowych dla poszczególnych użytkowników. Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki. Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań. Ograniczenie dostępu do obiektów, ochrona prywatności. Ograniczenie dostępu w systemach rozproszonych federacyjnych BD. Logiczna niezależność obiektów i aplikacji działający na obiektach. Współdziałanie systemów heterogenicznych (wspólny schemat). Przystosowanie systemów spadkowych (legacy) do nowszych technologii i wymagań. Hurtownie danych: analiza informacji gromadzonych z heterogenicznych źródeł.

Rodzaje perspektyw Wirtualne perspektywy Zmaterializowane perspektywy Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury funkc.). Wyliczenie (materializacja) następuje w momencie użycia perspektywy. Wynik jest “konsumowany” i następnie kasowany. Zalety: nie ma dublowania danych, nie ma problemu aktualizacji wyliczonych danych, nie ma problemów z przetwarzaniem transakcji. Wada: czas ewaluacji perspektyw + czas ewaluacji zapytań używających perspektyw bez optymalizacji często nieakceptowalny. Zmaterializowane perspektywy Perspektywa jest wyliczona “na zapas”, jej wynik jest przechowywany w bazie danych na normalnych zasadach. Aktualizacja danych stanowiących podstawę wyliczenia pociąga za sobą aktualizację zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie). Zalety: szybki dostęp, łatwa implementacja. Wady: zapotrzebowanie na pamięć, możliwość utraty spójności z bazą danych, koszt aktualizacji zmaterializowanych perspektyw (prowadzący do problemów koncepcyjnych i realizacyjnych), wąskie gardło dla transakcji, niejasny koncepcyjnie problem aktualizacji perspektyw.

Zasada przezroczystości perspektyw view transparency Z punkty widzenia użytkownika/programisty dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. Np. jeżeli w sfederowanej bazie danych administrator udostępnia tylko część danych poprzez perspektywę, wówczas użytkownik lub programista końcowy nie powinien być zmuszany do modyfikacji swoich programów działających na zapamiętanych danych z tego powodu, że mają one teraz działać na perspektywach. Podobnie, jeżeli “obca” baza danych jest widziana poprzez perspektywę w formacie “naszej” bazy danych, wówczas na “obcej” bazie danych powinny działać wszystkie aplikacje, które działają na “naszej”. Warunek przezroczystości perspektyw jest trudny do spełnienia: Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające. Problem aktualizacji perspektyw. Pewne dane mogą być manipulowane wyłącznie przez przypisane im interfejsy, a nie przez języki zapytań. Powstają problemy z wydajnością.

Aktualizacja perspektyw view updating Najpoważniejszym problemem jest aktualizacja perspektyw. Aktualizacja „wirtualnych” danych jest oczywiście niemożliwa, wobec czego należy w jakiś sposób zamienić tę aktualizację na aktualizację zapamiętanych danych. Aktualizacja Dane wirtualne Perspektywa Baza danych Dane zapamiętane Na ogół odwzorowanie odwrotne, danych wirtualnych w dane zapamiętane, nie jest jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje danych zapamiętanych można zrobić na wiele sposobów.

Przykład aktualizacji perspektyw (1) Dane rzeczywiste Dane wirtualne Dział Nazwa Pracownik Nazwisko Zarobek /MojeDziały ŚredniZarobek zatrudnia * Podwyższ średni zarobek w dziale „Serwis” o 500 zł: ? update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500 where Nazwa = ‘Serwis’; Zlecenie jest błędne. (1) Nie ma danej o nazwie ŚredniZarobek. (2) Nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy do wyboru nieskończenie wiele sposobów. Prawdopodobnie tylko jeden z nich satysfakcjonowałby osobę, która wydała takie polecenie. Który?

Przykład aktualizacji perspektyw (2) Dane rzeczywiste Dane wirtualne Dział Nazwa Pracownik Nazwisko Zarobek /MoiPracownicy NazwiskoPrac NazwiskoSzefa zatrudnia szef * 0..1 Technika implementacyjna: po wyliczeniu perspektywy MoiPracownicy zwraca ona referencje do nazwiska pracownika i nazwiska jego szefa. Czy problem aktualizacji został rozwiązany? Pracownik Kowalski, pracujący dla Styki, ma mieć nowego szefa Nowaka. ? update MoiPracownicy set NazwiskoSzefa = ‘Nowak’ where NazwiskoPrac = ‘Kowalski’; Aktualizację można wykonać, zaś nowym szefem Kowalskiego będzie Nowak. Niestety, zlecenie zmieniło nazwisko „Styka” na nazwisko „Nowak”, a chodziło o przeniesienie Kowalskiego do innego działu. Intencja tego zlecenia została poważnie zniekształcona.

Ograniczenia w aktualizacji perspektyw (Oracle) W klauzuli SELECT nie ma słowa DISTINCT W klauzuli FROM jest tylko jedna nazwa tabeli lub tylko jedna nazwa - tabeli lub aktualizowalnej perspektywy Na liście SELECT (wynikowej) znajduja się tylko nazwy kolumn W klauzuli WHERE nie ma podzapytania W zapytaniu nie mogą występować klauzule GROUP BY i HAVING Dodatkowo, Oracle wprowadza tzw. opcję sprawdzania (check option), która oznacza, że nie można aktualizować perspektyw w takich sytuacjach, w których skutki tej aktualizacji będą wykraczały poza to, co użytkownik widzi poprzez tę perspektywę. Np. jeżeli dla perspektywy BiednyPracownik (Nazwisko, Zarobek) wyliczanej na podstawie Zarobek < 1000 zwiększymy zarobek Kowalskiego o 1000, to zniknie on z perspektywy, co może zaskoczyć programistę.

Dodatkowe możliwości aktualizacji perspektyw W Oracle można aktualizować perspektywy powstające w wyniku złączenia, ale tylko atrybuty relacji znajdujące się po stronie “klucza obcego”: CREATE VIEW MoiLudzie( IdPracownika, Nazwisko, IdDziału, NazwaDziału, Zarobek) AS SELECT p.Id_pracownika, p.Nazwisko, p.Id_działu, d.Nazwa, p.Zarobek FROM Pracownicy AS p, Działy AS d WHERE p.Id_działu = d.Id_działu AND p.Stanowisko = ‘programista’; Podwyższyć o 500 zarobki wszystkim programistom z działu Serwis : UPDATE MoiLudzie SET Zarobek = Zarobek + 500 WHERE NazwaDziału = ‘Serwis’ OK. UPDATE MoiLudzie SET NazwaDziału = ‘Magazyn’ WHERE Nazwisko = ‘Nowak’ Przenieść programistę Nowaka do działu Magazyn: Źle!

Kryteria aktualizowalności perspektyw Brak nadmiarowej akualizacji. Aktualizacja pewnego elementu perspektywy nie powinna bezwiednie powodować aktualizacji innego. Brak niedostatecznej/błędnej aktualizacji - wynik aktualizacji nie powinien odbiegać od intencji użytkownika. Np. użytkownik aktualizuje zarobek netto o 100, tymczasem faktyczna aktualizacja wyniosła 91,50. Brak efektów ubocznych aktualizacji. Np. takim efektem jest zniknięcie krotki z perspektywy BiednyPracownik po zaktualizowaniu tego zarobku. Brak spontanicznej aktualizacji bazy danych poza fragmentem widocznym poprzez perspektywę. Zdeterminowany translator aktualizacji perspektywy - dla każdego stanu bazy danych powinien działać tak samo. Podane kryteria są spekulatywnym stereotypem i dotyczą sytuacji, kiedy translacja aktualizacji perspektyw jest dokonywana w pewien automagiczny sposób. Przestają mieć sens, jeżeli pełna kontrola nad aktualizacją perspektyw jest w rękach definiującego perspektywę.

Krytyka dotychczasowych podejść (1) W większości, perspektywy są ograniczone do wyszukiwania. Dla wielu zastosowań jest to za mało. Przezroczystość perspektyw wymaga rozwiązania problemu aktualizacji danych wirtualnych, wymagającego spójnego odwzorowania tych aktualizacji na aktualizacje danych zapamiętanych. Ten warunek nie jest spełniony dla wszystkich znanych nam propozycji perspektyw (z wyjątkiem perspektyw opartych na trygerze instead of, które spełniają go częściowo). Wszystkie znane nam koncepcje aktualizowalnych perspektyw opierają się na aktualizacji poprzez wynik wywołania perspektywy. Ten sposób myślenia o perspektywach stał się przyczyną powstania tzw. kryteriów aktualizowalności perspektyw. Z reguły zapytanie wywołujące perspektywę zwraca referencje do zapamiętanych danych, np. wartość klucza głównego relacji, identyfikator obiektu, itp. Jeżeli zapytanie nie zwraca referencji, lecz wartość, wówczas aktualizacja takiej danej wirtualnej jest uważana za niemożliwą. Tę tezę przyjmuje się jak aksjomat. Ta teza jest błędna i prowadzi do niepotrzebnych ograniczeń w aktualizacji perspektyw, czyli złamania zasady przezroczystości.

Krytyka dotychczasowych podejść (2) Badania dotyczące aktualizowalności perspektyw zostały zepchnięte na fałszywy tor: badano, jak zapobiec niepożądanym aktualizacjom (setki artykułów), a nie jak zapewnić pełną przezroczystość. Problem aktualizowalnych perspektyw dla obiektowych, obiektowo-relacyjnych i XML-owych baz danych znajduje się w stanie niemowlęcym. Typowe podejścia do obiektowych języków zapytań i perspektyw dzielą je na „zachowujące obiekty” i „generujące obiekty”. Tylko perspektywy „zachowujące obiekty” mogą być aktualizowalne. To powoduje, że większość użytecznych perspektyw staje się nieaktualizowalna. Inne podejście zakłada ortodoksyjną hermetyzację: każdy atrybut A jest związany z metodami getA oraz setA. Problem aktualizowalnych perspektyw znika. Po zdefiniowaniu wirtualnych obiektów wystarczy napisać metody getA i setA dla wszystkich atrybutów A wprowadzonych w definicji perspektywy. W ten sposób otrzymujemy magiczne rozwiązanie poważnego problemu poprzez prostą sztuczkę związaną z definicją hermetyzacji. Życie nie znosi jednak takich cudów i magii, zatem problem pozostaje. Nieadekwatność, koncepcyjne wady ortodoksyjnej hermetyzacji były dyskutowane na wykładzie JPS w poprzednim semestrze.

Rewolucyjna koncepcja Załóżmy, że perspektywa MoiPracownicy w wyniku aktualizacji nazwiska szefa rzeczywiście przenosiłaby pracownika do innego działu. Czy byłoby coś złego w takiej perspektywie? Odpowiedź: nie, taka perspektywa jest rozsądna. Jest ona jednak zabroniona przez kryteria aktualizowalności perspektyw. Wniosek: Kryteria aktualizowalności są koncepcyjną bzdurą. Razem z odrzuceniem tych kryteriów trzeba również odrzucić pomysł aktualizacji perspektyw poprzez efekty uboczne, czyli poprzez referencje zwracane przez wywołanie perspektywy. Nasza koncepcja polega na tym, aby wewnątrz definicji perspektywy jej twórca mógł wyrazić intencję każdej aktualizacji tej perspektywy. Intencję tę wyraża w postaci procedur, które są wywoływane w odpowiedzi na aktualizację danych wirtualnych. Takie właśnie podejście zostało zrealizowane (niezależnie) w koncepcjach perspektyw opartych na trygerach instead of. Nasze rozwiązanie jest bardziej eleganckie i bardziej uniwersalne. Pasuje do dowolnych baz danych: relacyjnych, obiektowych, XML-owych, itd.

Założenia metody aktualizacji perspektyw Odrzucamy wszystkie pseudo-teorie posiadające swoje korzenie w modelu relacyjnym i opieramy rozwiązanie na SBA. Wszelkie konsekwencje aktualizacji perspektywy muszą być określone przez osobę definiującą perspektywę. Nie dopuszczamy aktualizacji perspektywy poprzez referencje zwrócone przez perspektywę. Definiujący perspektywę ma do dyspozycji algorytmicznie kompletne środki do określania intencji aktualizacji. Środki określania tej intencji są inherentną składową definicji perspektywy. Istotą podejścia jest przeciążanie generycznych operatorów imperatywnych zastosowanych do wirtualnych obiektów przez procedury. Procedury te wyrażają intencję aktualizacji. Po zdefiniowaniu perspektywy użytkownik nie może odczuć jakichkolwiek różnic w operowaniu rzeczywistymi i wirtualnymi obiektami. Perspektywy mogą być rekurencyjnie i mogą posiadać parametry. Zakładamy zachowanie zasady relatywizmu, pełnej wewnętrznej identyfikacji, kontrolowania zakresów nazw, formalnej semantyki całego mechanizmu.

Zasada relatywizmu Definicja perspektyw będzie podlegać zasadzie relatywizmu. Oznacza ona m.in., że perspektywa może mieć podperspektywy. Jeżeli obiekt wirtualny ma atrybuty, to każdy z nich musi być zdefiniowany jako podperspektywa. Liczba poziomów hierarchii podperspektyw jest nieograniczona. Każda perspektywa i podperspektywa ma identyczną składnię, semantykę i pragmatykę, w szczególności, w zakresie aktualizacji. Jeżeli np. BogatyPracownik jest perspektywą, to podperspektywą może być Zarobek. Wynika stąd, że obiekty wirtualne mogą być również atomowe (nie muszą zawierać „atrybutów”). Jest to oczywiste dla zwolenników relatywizmu (i podejścia stosowego), natomiast jest pewną nowością dla społeczności baz danych. Hierarchia perspektyw/podperspektyw odpowiada hierarchii obiektów wirtualnych.

Zagnieżdżanie perspektyw i obiektów wirtualnych Perspektywa P Perspektywa A Perspektywa C Perspektywa B Perspektywa Y X Definicja zagnieżdżonych perspektyw Obiekty wirtualne A C P B

Zapamietanie definicji perspektywy i operacje administracyjne nad zapamiętanymi definicjami W odróżnieniu od SQL, nazwa obiektów wirtualnych dostarczanych przez perspektywę jest różna od nazwy zarządczej definicji perspektywy. Nasza perspektywa posiada strukturę, którą należy zarządzać. Nazwa zarządcza jest potrzebna aby wstawić, usunąć, zmienić, odpytać definicję. Definicje perspektyw są złożonymi obiektami zapamiętanymi w składzie. Definicje perspektyw, jako złożone obiekty, mogą być odpytywane i aktualizowane przez SBQL. Operacje administracyjne na definicjach perspektyw: kompilacja kodu źródłowego perspektywy, wstawienie kodu wynikowego nowej perspektywy w odpowiednie miejsce składu, zmiana i usunięcie definicji perspektywy. Operacje te może wykonywać administrator bazy danych lub programista za pomocą operacji wbudowanych w środowisko programistyczne Operacje są ograniczone regułami dostępu i bezpieczeństwa.

Ziarna obiektów wirtualnych (1) Dotychczas definicja perspektywy była określona przez jedno zapytanie (SQL). W takim przypadku występują jednak trudności z odtworzeniem informacji semantycznej niezbędnej do aktualizacji obiektów wirtualnych. Np. perspektywa zwraca nazwisko kierownika działu jako string oraz lokację tego działu również jako string. Jeżeli za pomocą tej perspektywy chcielibyśmy zmienić lokację działu, to potrzebna jest referencja do tego działu. Odzyskanie tej referencji jest utrudnieniem dla programisty. Definicja perspektywy powinna więc w takim przypadku składać się z dwóch lub więcej zapytań. Pierwsze z nich zwracałoby referencje do działów, Drugie na podstawie tych referencji zwracałoby nazwiska kierowników działów jako stringi, Trzecie na podstawie tych referencji zwracałoby lokalizacje działów jako stringi.

Ziarna obiektów wirtualnych (2) Elementy zwracane przez pierwsze zapytanie będziemy nazywać „ziarnami”, z których „wyrastają” obiekty wirtualne. Ziarna są następnie używane przez dalsze składowe definicji perspektywy. Ziarna mogą być proste (pojedyncze wartości lub referencje) lub dowolnie złożone. Na ogół ziarno będzie binderem, ale nie jest to wymagane. Istotne jest natomiast, aby funkcja nested działająca na ziarnie zwróciła niepustą wartość. Przyjęliśmy, że ziarna są wyznaczane przez procedurę funkcyjną o dowolnej złożoności. W stosunku do SQL jest to istotna generalizacja. ziarna obiekty wirtualne

Przykładowe definicje ziaren Prac where Zar > 10000 distinct( Prac.Stan ) as s bag(„analityk”, „programista”, „inżynier”) as z Prac as p Ziarna wyznaczają wirtualne obiekty dobrze zarabiających pracowników. Ziarna (nazwane s) wyznaczają wirtualne obiekty dla stanowisk Trzy ziarna (nazwane z) wyznaczają trzy wirtualne obiekty dla wymienionych stanowisk. Ziaren jest tyle, ile pracowników; każde z nich jest referencją do obiektu Prac, nazwaną p

Definicja perspektywy: tekstowa i w wersji obiektu bazy danych Przyjmujemy, że perspektywa po kompilacji jest obiektem bazy danych. Obiekt ten ma budowę hierarchiczną. create view BogatyPracDef { virtual objects BogatyPrac { return (Prac where Zar > 10000) as p } on_delete { ... } ... create view ZarobekDef { virtual objects Zarobek { return p.Zar as z} on_update( nowyZar ) do {...} .... //dalsze elementy definicji BogatyPracDef BogatyPrac ......... on_delete Kompilacja ZarobekDef Zarobek on_update ..... Hierarchię tę można odpytywać i aktualizować przy pomocy SBQL.

Identyfikatory wirtualne (1) Podstawowym problemem, który został rozwiązany w prezentowanej metodzie, jest wynalezienie sposobu przekazania informacji o aktualizacji obiektu wirtualnego do odpowiedniej procedury. Po wykonaniu funkcji definiującej obiekty wirtualne zostają zwrócone wyniki zapytania, ale zgubiona jest informacja, że wyniki pochodzą z perspektywy, a nie ze zwyczajnego zapytania. Powstaje problem, w jaki sposób w np. zleceniu: for each BogatyPrac where Zarobek < 20000 do Zarobek := Zarobek +1000 system ma się dowiedzieć, że aktualizacja dotyczy wirtualnego obiektu i w związku z tym, wywołać odpowiednią procedurę przeciążającą będącą składnikiem definicji perspektywy? Której perspektywy? W jaki sposób ma przekazać parametry tej aktualizacji do wnętrza tej procedury? Problem ten jest rozwiązany przez identyfikator wirtualny. Jest on odpowiednikiem lub substytutem identyfikatora obiektu zapamiętanego.

Identyfikatory wirtualne (2) W zapytaniach odwołujemy się do perspektywy poprzez nazwę obiektów wirtualnych. np. BogatyPrac where Nazw = "Kowalski" Dla celów zarządczych można użyć nazwy zarządczej. Uprawnienia mogą być zróżnicowane, np. programista może używać wyłącznie nazwy obiektów wirtualnych, natomiast administrator - wyłącznie nazwy zarządczej. Wywołanie perspektywy powoduje wykonanie procedury definiującej ziarna. Wynikiem wywołania nie są same ziarna, lecz identyfikatory wirtualne. Identyfikator wirtualny jest trójką: <flagaJestemWirtualny, NazwaZarządcza, Ziarno> lub równoważnie: < flagaJestemWirtualny, ReferencjaDoPerspektywy, Ziarno>

Rola identyfikatorów wirtualnych Są odpowiednikiem identyfikatorów zapamiętanych obiektów. Na podstawie flagi wiadomo, że jest to identyfikator wirtualny, z którym interpreter SBQL musi postępować inaczej niż ze zwykłym identyfikatorem. Na podstawie nazwy zarządczej (lub referencji do perspektywy) wiadomo o którą perspektywę chodzi. Poprzez ziarno wyznaczają obiekt wirtualny w sposób jednoznaczny. Wszelkie operacje w podejściu stosowym zostaną zmodyfikowane w taki sposób, aby uwzględnić identyfikatory wirtualne; w szczególności: operator dereferencji funkcja nested i sposób wkładania nowych sekcji na stos ENVS operatory podstawienia (update), usunięcia (delete) i wstawiania (insert) działające na takim identyfikatorze interpretowanym jako l-value Typowe operacje na identyfikatorze wirtualnym pozostają nie zmienione (np. zakomunikowanie go jako parametru, zwrócenie jako wyniku procedury funkcyjnej, uczestniczenie w operatorach algebraicznych)

Przepływ sterowania pomiędzy elementami mechanizmu aktualizacji perspektyw Program użytkownika Zapytanie wywołujące perspektywę Konsument wyniku zapytania (np. operator podstawienia) Definicja perspektywy Procedura wewnątrz definicji perspektywy przeciążająca danego konsumenta Identyfikatory wirtualne Interpreter zapytań oraz zleceń aktualizacyjnych Fragment interpretera implementujący danego konsumenta

C.D.N. Operatory „konsumujące” identyfikatory wirtualne Składnia definicji perspektywy i pod-perspektywy Wirtualny identyfikator dla perspektyw Co się dzieje na stosie ENVS w momencie wywołania perspektywy i w momencie aktualizacji obiektów wirtualnych? Przykłady zastosowania aktualizowalnych perspektyw. Przykłady te ilustrują moc mechanizmu, o której nie śniło się nawet tysiącom wybitnych specjalistów, którzy przez ostatnie 30 lat pracowali nad tym tematem.