Konstrukcja systemów obiektowych i rozproszonych

1. Konstrukcja systemów obiektowych i rozproszonych Wykład 3: Aktualizowalne perspektywy(2) 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

2. 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. 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. 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. Składnia instrukcji tworzenia perspektywy create viewNazwaZarządczaPerspektywy { virtual objectsNazwaObiektó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. 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. 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. Poglądowy obraz definicji perspektywy BogatyPracDef (flaga: perspektywa) BogatyPrac (flagi: procedura, generator ziaren) on_retrieve (flaga:procedura) on_update (flaga:procedura) on_delete (flaga:procedura) on_insert (flaga:procedura) NazwiskoDef (flaga: perspektywa) ZarobekDef (flaga: perspektywa) ..... ..... ..... ..... ..... ..... ..... proc1 (flaga:procedura) proc2 (flaga:procedura) ..... obiekt1 (flaga:obiekt) obiekt2 (flaga:obiekt) .....

9. 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. Przetwarzanie identyfikatorów wirtualnych przez operatory niealgebraiczne • Jeżeli przetwarzany jest identyfikator wirtualny <flagaJestemWirtualny, nazwaZarządcza, ziarno> (lub <flagaJestemWirtualny, referencjaDoPerspektywy, ziarno>), 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. Sytuacja na stosie ENVS • 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. Bindery do procedur virtual objects wszystkich pod-perspektyw zawartych w perspektywie nazwaZarządcza nested(ziarno) ...poprzednia zawartość stosu... Operator nie-algebraiczny przetwarza identyfikator wirtualny < flagaJestemWirtualny, nazwaZarządcza, ziarno> ...poprzednia zawartość stosu...

12. 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. Przetwarzanie identyfikatora wirtualnego dla podperspektywy przez operator niealgebraiczny 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... ...poprzednia zawartość stosu...

14. Wywołanie procedury aktualizującej podperspektywę 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... ...poprzednia zawartość stosu...

15. Przykłady perspektyw – schemat bazy danych (M0) Prac[0..*] NrP Nazwisko Stan Zar Ocena Opinia Email Dział [0..*] NrD Nazwa Lokacja[1..*] Zatrudnia[1..*] PracujeW Kieruje[0..1] Szef

16. 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. Przykład 1: Kod create viewPracSzefDef{ virtual objectsPracSzef{returnPrac asp }; on_delete do {deletep}; create viewNazwPracDef{ virtual objectsNazwPrac{returnp.Nazwisko asnp}; on_retrieve do{ returnderef( np ) } } create viewNazwSzefaDef{ virtual objects NazwSzefa{ returnp.PracujeW.Dział.Szef.Prac.Nazwisko asns}; on_retrieve do{ returnderef( ns ) }; on_update(NowySzef)do { p.PracujeW := refDział where (Szef.Prac.Nazwisko) = NowySzef; } } }

18. Przykład 1: zastosowania perspektywy Wydrukuj nazwiska wszystkich pracowników zatrudnionych w dziale kierowanym przez Kowalskiego: print(( PracSzef whereNazwSzefa = „Kowalski”).NazwPrac); Wydrukuj całą informację o pracownikach zatrudnionych w dziale kierowanym przez Kowalskiego: Zlecenie jest niepoprawne, gdyż dla ziaren zwracanych przez PracSzef nie zdefiniowano operatora dereferencji. print( PracSzef whereNazwSzefa = „Kowalski”); Przenieś wszystkich pracowników o nazwisku Głąb do działu kierowanego przez Kowalskiego: for eachPracSzef whereNazwPrac = “Głąb”doNazwSzefa := „Kowalski”; Zwolnij z pracy pracowników o nazwisku Głąb: deletePracSzef whereNazwPrac = „Głąb”;

19. 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. 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. Przykład 2: Kod perspektywy create viewDziałŚrZarDef{ virtual objectsDziałŚrZar{ return (Działwhere “Radom” inLokacja) asd }; create viewNazwaDef{ virtual objectsNazwa{ returnd.Nazwaasn}; on_retrieve do{returnderef( n ) } } create viewŚrZarDef{ virtual objectsŚrZar{ returnavg(d.Zatrudnia.Prac.Zar) ass}; on_retrieve do {returns}; on_update(NowaŚrednia) do { ifNowaŚrednia < sthendisplay( ”Obniżka zarobków jest niedozwolona”) else { create sum(d.Zatrudnia.Prac.(Zar * Ocena)) as ZarOcena; create ((NowaŚrednia – s) * count(d.Zatrudnia) / ZarOcena) asWspółczPodwyż; for eachd.Zatrudnia.Pracdo Zar := Zar + WspółczPodwyż * Zar * Ocena;}}}}

22. 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 eachDziałŚrZarwhereNazwa = „Lalki Barbie” do ŚrZar := ŚrZar + 200;

23. 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. Przykład 3: kod perspektywy create viewMójDziałDef { virtual objectsMójDział{ returnDział }; create viewNrDDef { virtual objectsNrD { returnNrDasdno }; on_retrieve do { returndno } } create viewNazwaDef { virtual objectsNazwa { returnNazwaasdn }; on_retrieve do { returndn } } create viewLokacjaDef { virtual objectsLokacja{ returnLokacjagroupaslo }; on_retrieve do { ifDostępJestAutoryzowany() thenreturnlo else { create sequence{“Plewki”,“Janów”,“Morgi”} asFałszLok; return FałszLok[LosowaLiczbaNaturalna() modulo 3] } } } }

25. 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. 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. Przykład 4: kod create viewPracPrzeglądDef { virtual objectsPracPrzegląd{ returnPrac asp wherep  (PracPrzeglądDef.Przejrzany.Prac) }; create viewNazwiskoDef { virtual objectsNazwisko{returnp.Nazwisko as n }; on_retrieve do { returnderef( n ) } }; create viewOpiniaDef { virtual objectsOpinia { returnp.Opinia asop }; on_retrieve do { returnderef( op ) } }; create view AdnotacjaDef { virtual objectsAdnotacja{return (PracPrzeglądDef.Adnwhere p = (dotyczy.Prac))as a }; on_retrieve do { returnif exists( a )thenderef( a.tekst )else “”}; on_update ( nowyTekst )do { if exists( a )thena.text := nowyTekst else { create (refp asdotyczy, nowyText astekst) asAdn; PracPrzeglądDef :< Adn } } }; create viewJużOcenionyDef { virtual objectsJużOceniony{returnfalse}; on_update ( dec ) do { ifdec then { create (ref p) as Przejrzany; PracPrzeglądDef :< Przejrzany; createref(PracPrzeglądDef.Adn wheredotyczy.Prac = p)asa; 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. 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 deletePracPrzeglądDef.Przejrzany

29. 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. 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.