© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 1 październik 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca:

Prezentacja na temat: "© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 1 październik 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca:"— Zapis prezentacji:

1 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 1 październik 2004 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 3: (2) Aktualizowalne perspektywy (2)

2 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 2 październik 2004 Perspektywa jako obiekt bazy danych Z punktu widzenia organizacji składu obiektów oraz stosu ENVS wprowadzenie takiej definicji jako struktury danych powoduje następujące skutki: W składzie, w obszarze trwałych danych, pojawia się obiekt złożony o nazwie BogatyPracDef, z odpowiednimi podobiektami. Na stosie ENVS, w sekcji trwałych danych pojawiają się dwa nowe bindery: BogatyPracDef(r1), z referencją r1 do obiektu definicji perspektywy oraz binder BogatyPrac(r2), z referencją r2 do podobiektu tego obiektu. Pierwszy binder będzie używany dla zarządzania perspektywą, np. dla jej usunięcia lub modyfikacji. Drugi binder będzie służył do wiązania nazwy obiektów wirtualnych występującej w zapytaniach. Wiązanie będzie automatycznie powodowało wywołanie procedury BogatyPrac.

3 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 3 październik 2004 Operatory konsumujące identyfikatory wirtualne Każdy z generycznych operatorów działających na obiektach wirtualnych będzie przeciążany przez procedury napisane przez definiującego perspektywę. Wyróżniamy cztery takie operatory: Dereferencja (retrieve). Podobnie jak dla zwyczajnej dereferencji, operator musi być zastosowany wszędzie tam, gdzie identyfikator obiektu wirtualnego musi zmienić się na wartość; np. operacja print, operatory +, <, parametr wołany przez wartość (call-by-value) itd.; Podstawienie (update). Operator posiada jako dodatkowy parametr podstawianą wartość (r-value); Usunięcie (delete); Wstawianie (insert). Operator powoduje wstawienie pewnego obiektu (być może też wirtualnego) do środka obiektu wirtualnego. Dodatkowym parametrem operatora jest referencja do wstawianego obiektu.

4 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 4 październik 2004 Tworzenie obiektów wirtualnych Powyższa koncepcja nie przykrywa tworzenia nowych obiektów wirtualnych. Operator tworzenia nie może działać na identyfikatorze wirtualnym, wobec czego musi być zdefiniowany w inny sposób. Jednym z takich sposobów jest napisanie explicite procedury tworzenia obiektu wirtualnego (dokonującej odpowiednich aktualizacji obiektów rzeczywistych). Więcej możliwości związanych z definicją procedury automatycznie przeciążającej operator tworzenia obiektu wirtualnego może dać wprowadzenie specjalnej klasy dla obiektów wirtualnych i parametryzowanie instrukcji tworzenia obiektów tą klasą. Innym sposobem jest wykorzystanie operatora on_insert, poprzez utworzenie nadperspektywy nad daną perspektywą i następnie wstawianie fizycznego (czasowego) obiektu do takiej nadperspektywy. Z dokładnością do pojęć i terminologii takie rozwiązanie jest zastosowane w relacyjnych perspektywach opartych na trygerze instead of.

5 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 5 październik 2004 Składnia instrukcji tworzenia perspektywy create view NazwaZarządczaPerspektywy { virtual objects NazwaObiektówWirtualnych{ Definicja ziaren perspektywy }; on_retrieve do { Definicja akcji przeciążających operator dereferencji}; on_update( NazwaParametruPodstawianejWartości ) do { Definicja akcji przeciążających operator podstawienia }; on_delete do { Definicja akcji przeciążających operator usuwania }; on_insert( NazwaParametruReferencjiDoObiektu ) do { Definicja akcji przeciążających operator wstawiania }; definicja podperspektywy 1; definicja podperspektywy 2; definicja podperspektywy 3;... }

6 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 6 październik 2004 Komentarz do składni Składnia ta dotyczy momentu tworzenia nowej perspektywy. Po utworzeniu perspektywa istnieje jako struktura danych, która może podlegać aktualizacjom za pomocą innej składni. Nie będziemy tutaj zajmować się taką dodatkową składnią. Słowa virtual objects, on_retrieve, on_update, on_delete, on_insert są zarezerwowane i identyczne dla wszystkich definicji perspektyw. Każde z nich jest traktowane jako nazwa procedury, zaś każdy fragment definicji oznaczony takim słowem jest traktowany tak jak procedura. W przypadku virtual objects jest to procedura funkcyjna zwracająca ziarna obiektów wirtualnych. Każda procedura on_ retrieve, on_update, on_delete, on_insert może być pominięta, co oznacza, że dla definiowanych obiektów wirtualnych odpowiednia operacja jest niedozwolona. Nazwy NazwaZarządczaPerspektywy, NazwaObiektówWirtualnych oraz nazwy parametrów procedur on_update i on_insert wybiera definiujący.

7 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 7 październik 2004 Dalsze elementy definicji perspektywy Klasy obiektów wirtualnych. Jeżeli obiekty wirtualne potrzebują metod, wówczas należy je podłączyć do klasy. Podłączenie perspektywy do klasy oznacza konieczność wprowadzenia specjalnej klauzuli. Jej wynikiem będzie to, że wraz z otwarciem sekcji zapisu aktywacyjnego na ENVS dla dowolnej z procedur przeciążających sekcja z binderami do wnętrza tej klasy oraz sekcje jej nadklas są wstawiane do ENVS. Powiązania obiektów wirtualnych z innymi obiektami, zapamiętanymi lub wirtualnymi. Może być konieczna specjalna składnia. Pomocnicze procedury i funkcje, będące składnikiem definicji perspektywy. Trwałe lub lokalne dane używane przez perspektywę. Dane te są zapamiętane wewnątrz perspektywy na ogólnie przyjętych zasadach dla danych trwałych lub lokalnych danych sesji użytkownika. Są one konieczne dla perspektyw ze stanem (stateful views, capacity- augmented views).

8 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 8 październik 2004 Poglądowy obraz definicji perspektywy BogatyPracDef (flaga: perspektywa) BogatyPrac (flagi: procedura, generator ziaren) on_retrieve (flaga:procedura) on_insert (flaga:procedura) on_delete (flaga:procedura) on_update (flaga:procedura) proc1 (flaga:procedura) proc2 (flaga:procedura)..... obiekt2 (flaga:obiekt) obiekt1 (flaga:obiekt)..... NazwiskoDef (flaga: perspektywa)..... ZarobekDef (flaga: perspektywa).....

9 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 9 październik 2004 Podperspektywy Zgodnie z zasadą relatywizmu semantycznego, każda podperspektywa jest z syntaktycznego, semantycznego i pragmatycznego punktu widzenia perspektywą, tj. ma podobną budowę i własności. Liczba poziomów hierarchii perspektyw nie jest ograniczona. Dla celów administracyjnych podperspektywy są identyfikowane jako obiekty podrzędne perspektywy w sposób specyficzny dla modelu M0. Mechanizm podejścia stosowego musi podjąć odpowiednią akcję, jeżeli identyfikator wirtualny jest przetwarzany przez dowolny operator niealgebraiczny lub operator for each. Zgodnie z podejściem stosowym w modelu składu M0, na identyfikatorze wykonywana jest funkcja nested; następnie jej rezultat jest wkładany na wierzchołek ENVS. Dla modeli M1, M2, i M3 jest to dodatkowo powiązane z wkładaniem na stos ENVS sekcji z binderami do własności klas i/lub nadról.

10 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 10 październik 2004 Przetwarzanie identyfikatorów wirtualnych przez operatory niealgebraiczne Jeżeli przetwarzany jest identyfikator wirtualny (lub ), to na wierzchołek ENVS wkładana jest sekcja z nested(ziarno). Następnie wkładana jest na wierzchołek ENVS sekcja z binderami do wszystkich podperspektyw danej perspektywy. W takiej sytuacji wewnętrzne procedury i dane nie są widoczne. W ten sposób na wierzchołku ENVS będą bindery indukowane przez ziarno obiektu wirtualnego, co umożliwi definiującemu perspektywę odwołanie się do niego podczas definicji podperspektyw. Bindery do wszystkich procedur oznaczonych virtual objects znajdujących się wewnątrz jej podperspektyw będą także obecne na stosie, co umożliwia ich użycie jako atrybutów obiektów wirtualnych. W takiej sytuacji nie jest celowe wkładanie na stos ENVS binderów z nazwami zarządczymi podperspektyw.

11 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 11 październik 2004 Sytuacja na stosie ENVS...poprzednia zawartość stosu... Operator nie-algebraiczny przetwarza identyfikator wirtualny Bindery do procedur virtual objects wszystkich pod-perspektyw zawartych w perspektywie nazwaZarządcza nested(ziarno)...poprzednia zawartość stosu... Dzięki zastosowaniu stosu środowiskowego całość tego objaśnienia obowiązuje także podperspektywy. Jeżeli perspektywa jest podłączona do klasy (w modelu M1), to na ENVS wkłada się także odpowiednio sekcję z binderami do jej własności oraz sekcje jej nadklas. Podobnie z rolami w modelu M2 i z własnościami publicznymi/prywatnymi w modelu M3.

12 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 12 październik 2004 Wirtualny identyfikator dla podperspektyw Dotychczasowa konstrukcja identyfikatora wirtualnego jest niewystarczająca dla podperspektyw. Przy pisaniu procedur aktualizacyjnych dla podperspektywy programista może mieć potrzebę odwołania się do wszystkich jej nadperspektyw. Identyfikator wirtualny jest jedynym sposobem zakomunikowania informacji o nad-perspektywach, co powoduje konieczność rozszerzenia go do następującej postaci: gdzie referencjaDoPerspektywy_1 odnosi się do najbardziej zewnętrznej perspektywy, referencjaDoPerspektywy_2 odnosi się do jej podperspektywy itd.; referencjaDoPerspektywy_n odnosi się do aktualnie przetwarzanej perspektywy. <flagaJestemWirtualny, (referencjaDoPerspektywy_1, ziarno_1), (referencjaDoPerspektywy_2, ziarno_2),... (referencjaDoPerspektywy_n, ziarno_n) >

13 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 13 październik 2004 Przetwarzanie identyfikatora wirtualnego dla podperspektywy przez operator niealgebraiczny...poprzednia zawartość stosu... Bindery do procedur virtual objects wszystkich pod-pod-perspektyw zawartych w pod-perspektywie referencjaDoPerspektywy_n nested(ziarno_n)... nested(ziarno_2) nested(ziarno_1)...poprzednia zawartość stosu...

14 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 14 październik 2004 Wywołanie procedury aktualizującej podperspektywę...poprzednia zawartość stosu... Zapis aktywacyjny wywoływanej procedury on_ retrieve, on_update, on_delete lub on_insert nested(ziarno_n)... nested(ziarno_2) nested(ziarno_1)...poprzednia zawartość stosu...

15 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 15 październik 2004 Przykłady perspektyw – schemat bazy danych (M0) Dział [0..*] NrD Nazwa Lokacja[1..*] PracujeW Zatrudnia [1..*] Prac[0..*] NrP Nazwisko Stan Zar Ocena Opinia Email Kieruje [0..1] Szef

16 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 16 październik 2004 Przykład 1: Aktualizacja nazwiska szefa Perspektywa PracSzef dla wszystkich pracowników zwraca nazwisko pracownika (NazwPrac) i nazwisko szefa (NazwSzefa) jako stringi. Podstawienie stringu na nazwisko szefa powoduje przeniesienie pracownika do działu, którego szef ma to nazwisko, które zostało użyte w podstawieniu. Nie rozpatrujemy błędnego nazwiska szefa. Usunięcie obiektu wirtualnego powoduje usunięcie odpowiedniego obiektu pracownika. Zakładamy automatyczną aktualizację pointerów Zatrudnia bliźniaczych w stosunku do PracujeW. Perspektywa zwraca tyle ziaren, ilu jest pracowników. Każde ziarno ma postać bindera p(iPrac), gdzie iPrac jest referencją do obiektu Prac.

17 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 17 październik 2004 Przykład 1: Kod create view PracSzefDef { virtual objects PracSzef { return Prac as p }; on_delete do { delete p }; create view NazwPracDef{ virtual objects NazwPrac{ return p.Nazwisko as np}; on_retrieve do{ return deref( np ) } } create view NazwSzefaDef{ virtual objects NazwSzefa{ return p.PracujeW.Dział.Szef.Prac.Nazwisko as ns}; on_retrieve do{ return deref( ns ) }; on_update(NowySzef) do { p.PracujeW := ref Dział where (Szef.Prac.Nazwisko) = NowySzef; } } }

18 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 18 październik 2004 Przykład 1: zastosowania perspektywy Wydrukuj nazwiska wszystkich pracowników zatrudnionych w dziale kierowanym przez Kowalskiego: print(( PracSzef where NazwSzefa = Kowalski).NazwPrac); Wydrukuj całą informację o pracownikach zatrudnionych w dziale kierowanym przez Kowalskiego: print( PracSzef where NazwSzefa = Kowalski); Zlecenie jest niepoprawne, gdyż dla ziaren zwracanych przez PracSzef nie zdefiniowano operatora dereferencji. Zwolnij z pracy pracowników o nazwisku Głąb: delete PracSzef where NazwPrac = Głąb; Przenieś wszystkich pracowników o nazwisku Głąb do działu kierowanego przez Kowalskiego: for each PracSzef where NazwPrac = Głąb do NazwSzefa := Kowalski;

19 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 19 październik 2004 Przykład 1: komentarz Powyższa perspektywa ilustruje sytuację zabronioną przez kryteria aktualizowalności perspektyw podane w literaturze. Sytuacja taka jest także zabroniona w istniejących systemach komercyjnych, które nie zezwalają na aktualizację perspektyw powstałych w wyniku złączenia, jeżeli dotyczy ona atrybutu relacji znajdującej się po stronie klucza głównego w złączanych relacjach. Nasz przykład jest całkowicie rozsądny, z jasną logiką biznesową. Pokazujemy przez to, że wspomniane kryteria aktualizowalności perspektyw są nonsensem, konsekwencją błędnych założeń i spekulacyjnych teorii.

20 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 20 październik 2004 Przykład 2: Aktualizacja średniego zarobku Perspektywa DziałŚrZar dotyczy działów zlokalizowanych w Radomiu i zwraca nazwę działu (Nazwa) i średnią zarobków (ŚrZar) pracowników w tym dziale. Podstawienie na średnią zarobków powoduje podwyżkę zarobków pracowników w tym dziale proporcjonalną do ich aktualnych zarobków i do ich oceny wyrażonej w skali 0..10 (atrybut Ocena).

21 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 21 październik 2004 Przykład 2: Kod perspektywy create view DziałŚrZarDef{ virtual objects DziałŚrZar{ return (Dział where Radom in Lokacja) as d }; create view NazwaDef{ virtual objects Nazwa{ return d.Nazwa as n}; on_retrieve do{return deref( n ) } } create view ŚrZarDef{ virtual objects ŚrZar{ return avg(d.Zatrudnia.Prac.Zar) as s}; on_retrieve do {return s}; on_update(NowaŚrednia) do { if NowaŚrednia < s then display( Obniżka zarobków jest niedozwolona) else { create sum(d.Zatrudnia.Prac.(Zar * Ocena)) as ZarOcena; create ((NowaŚrednia – s) * count(d.Zatrudnia) / ZarOcena) as WspółczPodwyż; for each d.Zatrudnia.Prac do Zar := Zar + WspółczPodwyż * Zar * Ocena;}}}}

22 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 22 październik 2004 Przyklad 2: Podstawienie na średnią zarobków Teraz oczywiście można podstawiać na średnią zarobków: Podnieś o 200 średni zarobek w dziale Lalki Barbie: Procedura on_update wyraża jedną z intencji biznesowych takiej aktualizacji. Efektem będzie zwiększenie średniej zarobków o 200 zł, ale dystrybucja indywidualnych podwyżek jest proporcjonalna do zarobku i oceny, np.: for each DziałŚrZar where Nazwa = Lalki Barbie do ŚrZar := ŚrZar + 200; NazwiskoZarOcenaNowy Zarobek Malinowski100061211.76 Kowalski200012070.59 Nowak300033317.65 Suma60006600.00

23 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 23 październik 2004 Przyklad 3: Ochrona danych poprzez zmylenie hakerów Zdefiniujemy perspektywę MójDział z atrybutami NrD, Nazwa i Lokacja. Zapytanie MójDział dla autoryzowanych użytkowników zwraca te same informacje, które zwraca zapytanie Dział. Atrybut Lokacja jest zabezpieczony przed nieautoryzowanym dostępem (lokacje objęte są tajemnicą wojskową). Zabezpieczenie polega na zmyleniu hakera próbującego dostać się do tej informacji. Jeżeli dostęp jest nieautoryzowany, to nie zabraniamy go, ale perspektywa zwraca fałszywy rezultat, o czym haker nie wie

24 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 24 październik 2004 Przykład 3: kod perspektywy create view MójDziałDef { virtual objects MójDział{ return Dział }; create view NrDDef { virtual objects NrD { return NrD as dno }; on_retrieve do { return dno } } create view NazwaDef { virtual objects Nazwa { return Nazwa as dn }; on_retrieve do { return dn } } create view LokacjaDef { virtual objects Lokacja{ return Lokacja group as lo }; on_retrieve do { if DostępJestAutoryzowany() then return lo else { create sequence{Plewki,Janów,Morgi} as FałszLok; return FałszLok[LosowaLiczbaNaturalna() modulo 3] } }

25 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 25 październik 2004 Przykład 3: komentarz Pokazujemy, że dzięki wprowadzonym przez nas perspektywom osoba definiująca perspektywę ma możliwość przejęcia pełnej kontroli nad wszystkim, co może zdarzyć się w stosunku do wirtualnych obiektów. Kontrolować może nie tylko operacje aktualizacyjne, lecz dzięki operatorowi dereferencji (on_retrieve) może także kontrolować operacje wyszukiwawcze. Zwykle taka funkcjonalność jest wiązana z regułami zdarzeniowymi (ECA, Event-Condition-Action), inaczej trygerami. W ogólnym przypadku mechanizm trygerów jest trudny: Zmusza do wprowadzania nowych bytów programistycznych, takich jak zdarzenia, bloki obsługi zdarzeń, rejestry zdarzeń itd. Prowadzi do licznych opcji dodatkowych, m.in. związanych z przetwarzaniem transakcji. Trygery nie mogą być ustawione na operacje wyszukiwawcze, czyli podany przez nas przykład jest w takich systemach nierealizowalny. Te problemy nie występują w naszym podejściu.

26 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 26 październik 2004 Przykład 4: Przegląd pracowników (perspektywa ze stanem) Szef firmy dokonuje okresowego przeglądu wszystkich pracowników. W tym celu ma perspektywę PracPrzegląd, która ma 4 atrybuty: Nazwisko, Opinia, Adnotacja i JużOceniony. Nazwisko i Opinia pochodzą z obiektu pracownika, natomiast atrybuty Adnotacja i JużOceniony są lokalne dla tej perspektywy. Szef może podstawić na atrybut Adnotacja dowolny tekst, który może wielokrotnie zmieniać bez skutków dla bazy danych. Każda osoba nowo przyjęta do pracy pojawi się automatycznie w tej perspektywie. Podstawienie na atrybut JużOceniony wartości true oznacza usunięcie informacji na temat tego pracownika z perspektywy PracPrzegląd (bez usuwania z bazy danych). Osoba ta nie pojawi się więcej w tej perspektywie, aż do zresetowania tej perspektywy np. przez administratora. Jeżeli w międzyczasie szef zapełnił dla tego pracownika atrybut Adnotacja, wówczas znajdujący się tam tekst uzupełnia opinię o pracowniku oraz wysyłany jest email do szefa tego pracownika zawierający nazwisko pracownika oraz tekst adnotacji. Perspektywa, po jej skompilowaniu, jest traktowana jako obiekt bazy danych. Wewnątrz zawiera dane pointerowe o nazwie Przejrzany, których wartością jest referencja do obiektów Prac (które wskutek tego nie pojawią się w perspektywie).

27 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 27 październik 2004 Przykład 4: kod create view PracPrzeglądDef { virtual objects PracPrzegląd{ return Prac as p where p (PracPrzeglądDef.Przejrzany.Prac) }; create view NazwiskoDef { virtual objects Nazwisko{ return p.Nazwisko as n }; on_retrieve do { return deref( n ) } }; create view OpiniaDef { virtual objects Opinia { return p.Opinia as op }; on_retrieve do { return deref( op ) } }; create view AdnotacjaDef { virtual objects Adnotacja{ return (PracPrzeglądDef.Adn where p = (dotyczy.Prac)) as a }; on_retrieve do { return if exists( a ) then deref( a.tekst ) else }; on_update ( nowyTekst ) do { if exists( a ) then a.text := nowyTekst else { create (ref p as dotyczy, nowyText as tekst) as Adn; PracPrzeglądDef :< Adn } } }; create view JużOcenionyDef { virtual objects JużOceniony{ return false}; on_update ( dec ) do { if dec then { create (ref p) as Przejrzany; PracPrzeglądDef :< Przejrzany; create ref(PracPrzeglądDef.Adn where dotyczy.Prac = p) as a; if exists (a) then { p.Opinia := p.Opinia a.text; wyślijEmail( doKogo: p.PracujeW.Dział.Szef.Prac.Email; treść: ( Prac: p.Nazwisko Adnotacja: a.tekst)); delete a } } } }

28 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 28 październik 2004 Przykład 4: użycie perspektywy Przeglądanie informacji z perspektywy: Wstawienie adnotacji o Nowaku Usunięcie informacji o Nowaku z perspektywy i wysłanie maila do jego szefa: Zresetowanie perspektywy (czyli uwidocznienie informacji o wszystkich obiektach Prac); informacje Adn nie są gubione: Zwrócimy uwagę, że obiekty Przejrzany i Adn są trwałe, lecz lokalne w stosunku do tej perspektywy. Usunięcie tej perspektywy jako obiektu powoduje usunięcie również obiektów Przejrzany i Adn. (PracPrzegląd where Nazwisko = Kowalski). (Opinia Adnotacja) (PracPrzegląd where Nazwisko = Nowak). Adnotacja := Wzorowy - nagrodzić (PracPrzegląd where Nazwisko=Nowak).JużOceniony := true delete PracPrzeglądDef.Przejrzany

29 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 29 październik 2004 Optymalizacje Jeżeli perspektywy używa się wyłącznie w wyszukiwaniu, to stosowną techniką jest modyfikacja zapytań (objaśniona w poprzednim semestrze). Dla zapytań użytych w definicji perspektywy można oczywiście stosować dowolne zaimplementowane techniki optymalizacyjne (przepisywanie, indeksy). Dla operacji aktualizaujących obiekty wirtualne konieczne jest wynalezienie nowych metod optymalizacyjnych, w szczególności takich, które identyfikator wirtualny zamienią na zwykły OID.

30 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 30 październik 2004 Porównanie z trygerami instead of Trygery instead of działają tylko na relacyjnych bazach danych. Jest dość trudno stwierdzić, czy ta koncepcja jest rozszerzalna na inne medele danych. Nasze perspektywy są zdefiniowane dla dowolnego modelu danych. Trygery instead of wymagają mechanizmu zdarzeniowego, który stanowi dodatkową komplikację środowiska programistycznego. Nie jest jasny stopień algorytmicznej uniwersalności trygerów instead of. W przypadku perspektyw nie ma ograniczeń uniwersalności. W sumie jednak koncepcje te są dość zbliżone.