Konstrukcja systemów obiektowych i rozproszonych

© 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łaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 3: Aktualizowalne perspektywy (2)(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.


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.


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.


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;



...

}


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.


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


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)

.......... ..... .....


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.


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.


Sytuacja na stosie ENVS

...poprzednia zawartość stosu...

Operator nie-algebraiczny przetwarza identyfikator wirtualny< flagaJestemWirtualny, nazwaZarządcza, ziarno>

Bindery do procedur virtual objects wszystkich

pod-perspektyw zawartych w perspektywie nazwaZarządcza

nested(ziarno)


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.


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) >


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)



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)



Przykłady perspektyw – schemat bazy danych (M0)

Dział [0..*]NrDNazwaLokacja[1..*]

PracujeW Zatrudnia[1..*]Prac[0..*]NrPNazwiskoStanZarOcenaOpiniaEmail

Kieruje[0..1] Szef


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.


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; } } }


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”;


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.


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


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;}}}}


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;

Nazwisko Zar Ocena Nowy Zarobek

Malinowski 1000 6 1211.76

Kowalski 2000 1 2070.59

Nowak 3000 3 3317.65

Suma 6000 6600.00


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


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]} } } }


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.


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


Przykład 4: kodcreate 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 } } } }


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


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.


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.

Documents

Konstrukcja systemów obiektowych i rozproszonych