Propozycja doktoratu

1. Propozycja doktoratu Promotor: Kazimierz Subieta Doktorantka: Hanna Kozankiewicz Temat: Aktualizowalne perspektywy obiektowych baz danych Alternatywnie: Aktualizowalne widoki dla XML

2. Krótka charakterystyka tematu (1) • Temat aktualizowalnych perspektyw dla relacyjnych baz danych został sformułowany przez E.Codda w 1974 roku • Od mniej więcej 28 lat nad tym tematem pracowało setki wybitnych naukowców, • ... których dokonania można podsumować jako mało satysfakcjonujące (bardziej dobitnie: jako zero). • Trochę zrobiono w ramach systemów relacyjnych, ale proponowane rozwiązania są ograniczone. • Temat zyskał sobie sławę arcy-trudnego. • Zadaniem doktoratu jest pokazanie, że temat ten jest jak najbardziej do opanowania, • ... jeżeli założy się dobre podejście. Takim podejściem będzie oczywiście Stack-Based Approach (SBA).

3. Krótka charakterystyka tematu (2) • Istotą niepowodzeń innych autorów pracujących nad tym tematem są błędne założenia: • Formalizacja: logika i algebra nie wprowadzają pojęcia stanu i operacji aktualizacji stanu. Jak mówić o aktualizacji perspektyw bez wprowadzania formalnego pojęcia aktualizacji? • Sprowadzanie perspektywy do funkcji matematycznej na danych, z założeniem, że aktualizacja perspektywy będzie (auto-magicznym) efektem ubocznym takiej definicji. • Konsekwencja: całkowity brak środków dla definiującego perspektywę dla określania intencji jej aktualizacji. • Eklektyczne definicje, brak tendencji do uogólnień, zmieszanie cech pierwszorzędnych z drugorzędnymi. • Nie przestrzeganie zasad budowy języków programowania, szczególnie zasady relatywizmu, zasady pełnej wewnętrznej identyfikacji i zasady rekurencji.

4. Krótka charakterystyka tematu (3) • Założenie podstawowe: jeżeli perspektywa ma być aktualizowalna, to wszelkie konsekwencje dowolnej aktualizacji perspektywy muszą być w rękach osoby definiującej perspektywę. • Nie ma jakichkolwiek aktualizacji perspektywy, które nie byłyby objęte tą kontrolą. • Np. nie ma aktualizacji perspektywy implicite poprzez referencję zwróconą przez perspektywę. To musi być zaprogramowane explicite. • Osoba definiująca perspektywę ma do dyspozycji algorytmicznie kompletne środki do określania intencji aktualizacji • Zastosowane środki określania intencji aktualizacji perspektywy są inherentną składową definicji perspektywy. • Pełna przezroczystość: po zdefiniowaniu perspektywy wraz z jej aktualizacjami użytkownik nie może odczuć jakichkolwiek różnic w operowaniu rzeczywistymi i wirtualnymi obiektami.

5. Czy obiektowe bazy danych czy raczej XML? • XML jest ograniczonym przypadkiem obiektowych baz danych, i prawdopodobnie jego długofalowy rozwój będzie owocował wprowadzeniem do niego klasycznych cech obiektowości. • Na dzisiaj termin "obiektowe bazy danych" jest odbierany nie najlepiej z powodu nieprzyjaznego stosunku wielkich korporacji softwerowych. • ...lansowany jest raczej (bzdurny) termin "obiektowo-relacyjny". • XML jest w tej chwili nagłośniony - z koniunkturalnego punktu widzenia dobrze jest wiązać się z tym terminem. • Z punktu widzenia koncepcji doktoratu jest prawie bez znaczenia czy XML czy obiektowe bazy danych. • Na pewno nie obiektowo-relacyjne bazy danych.Nie wiadomo co ten termin znaczy (poza mętnym skojarzeniem ze starymi "relacyjnymi" bazami danych + kikutowate cechy obiektowości).

6. Architektura (1) • Skład obiektów - klasyczny skład podejścia stosowego w wariancie M1 lub M2 • Na początek M0 - przykrywa XML. • Definicje perspektyw są obiektami przechowywanymi w składzie jako obiekty "korzeniowe". • Możliwe jest rozpatrzenie przypadku gdy perspektywy są metodami przechowywanymi w ramach klas. • Trzeba będzie odróżniać perspektywę jako tekst i perspektywę jako element metamodelu. • Perspektywy są pierwszej kategorii programistycznej.

7. Architektura (2) • Możliwa jest także sytuacja gdy perspektywa jest trzymana w na dowolnym poziomie hierarchii obiektów, np. jako element modułu. • Dla celów zarządczych (tworzenie, modyfikacja, usuwanie) perspektywa jest identyfikowana przez nazwę, która nie będzie tożsama z nazwą obiektów wirtualnych tej perspektywy. Skład Perspektywa Obiekt Obiekt Klasa Perspektywa Obiekt Obiekt Klasa Perspektywa

8. Relatywizm (1) • Definicja perspektywy będzie podlegać zasadzie relatywizmu. • Każda perspektywa może mieć pod-perspektywy • Jeżeli obiekt wirtualny ma mieć atrybuty, to każdy z nich musi być zdefiniowany jako pod-perspektywa. • Liczba poziomów hierarchii pod-perspektyw jest nieograniczona • Każda perspektywa i pod-perspektywa ma identyczną składnię, semantykę i pragmatykę, w szczególności w zakresie aktualizacji. • Jeżeli np. BogatyPracownik jest perspektywą, to pod-perspektywą może być Zarobek. • Wynika stąd, że obiekty wirtualne mogą być atomowe, nie muszą zawierać "atrybutów", • ... co jest oczywiste dla zwolenników relatywizmu (i podejścia stosowego), natomiast jest nowością dla społeczności baz danych. • Hierarchia perspektyw/pod-perspektyw odpowiada hierarchii obiektów wirtualnych.

9. Relatywizm (2) P A A B C Perspektywa A Perspektywa B Perspektywa C X Y Perspektywa X Perspektywa Y P A B X X X Y Obiekty wirtualne (hierarchia) Perspektywa P

10. Nazwa zarządcza perspektywy i nazwa obiektów wirtualnych • W relacyjnych bazach danych nie ma różnicy: nazwa zarządcza perspektywy (służąca do jej tworzenia, aktualizacji i usuwania) jest tożsama z nazwą tabeli wirtualnej definiowanej przez tę perspektywę. • W naszym przypadku rozróżnienie jest istotne, np. w sytuacji, gdy definicja perspektywy jest modyfikowana np. poprzez wstawienie do jej wnętrza nowych obiektów. • Ta sytuacja powinna być rozwiązana przez konwencję nazwowo-składniową, • np. BogatyPracDef (nazwa definicji) vs. BogatyPrac (nazwa obiektu wirtualnego) • Ta konwencja nazwowo-składniowa jest sprawą drugorzędną dla doktoratu.

11. Rekurencja i parametry • Powinna być zapewniona jako efekt uboczny, analogicznie do procedur i funkcji w SBQL. • Wynika stąd, że wszelkie ulotne struktury danych deklarowane lub tworzone przez perspektywę powinny być odkładane na stosie środowiskowym (ENVS). • Przy programowaniu trzeba uważać, aby nie było jakichkolwiek wspólnych (statycznych, globalnych) własności aktualizowanych przez poszczególne wywołania rekurencyjne. • Kolejne wołanie w rekurencji nie powinno "zamazywać" rezultatów poprzednich wołań. • Parametry - klasyczne call-by-value i call-by-reference, z zapytaniami jako parametrami. • Reguły zakresu - jak dla procedur/funkcji. • Wywołanie perspektywy - tworzona jest sekcja na ENVS analogicznie do procedur.

12. Definicja perspektywy • Ponieważ musimy włożyć do definicji perspektywy wiele informacji, utożsamianie perspektywy z procedurą funkcyjnej jest oczywiście nieadekwatne. • Perspektywą będziemy nazywać wyróżniony moduł składu (obiektpierwszej kategorii) składający się z: • Definicji osi (pivot) obiektów wirtualnych. • Kilku definicji reakcji na operacje zachodzące na osi. • Opcyjnie - definicji pod-perspektyw (sub-views). • Opcyjnie - elementów wspomagających, w szczególności funkcji, klas, połączeń do klas, obiektów (dla perspektyw z trwałym stanem) • Nie wszystkie te opcje muszą być objęte doktoratem

13. Co to jest oś? Termin jest ad hoc i nie ma żadnych zaszłości. Może być zmieniony na inny, np. sack (worek), który zawiera seeds (ziarna). • Oś definiuje elementy, które jednoznacznie, na podstawie składu, wyznaczają obiekty wirtualne. Przykłady: • Prac where Zar > 10000 - oś wyznaczająca wszystkich dobrze zarabiających pracowników • distinct(Prac.Zawód) - oś wyznaczająca wszystkie zawody pracowników zapisane w bazie danych • bag("analityk","programista","inżynier") as z - oś wyznaczająca 3 bindery ze stringami • Prac as p - oś złożona z binderów nazwanych p z referencjami do pracowników • Element osi może być dowolny, prosty lub dowolnie złożony. Być może powinien być binderem, ale to nie jest pewne. • Prawie na pewno funkcja nested powinna coś dla niego zwrócić • Element osi jest ziarnem, z którego wyrasta obiekt wirtualny. • Definicja osi jest dowolnie złożoną procedurą funkcyjną.

14. Po co jest oś? • Dotychczasowe naiwne wyobrażenia były oparte na założeniu, że definicja perspektywy jest określona przez pojedyncze zapytanie. • Bardzo dawno temu doszedłem do wniosku, że w takim przypadku gubiona jest informacja semantyczna niezbędna do aktualizacji perspektywy (przykład w jednej z moich starych prac i nieco dalej w tej prezentacji). • Dlatego definicja perspektywy rozpada się na wiele zapytań. • Na podstawie osi definiuje się kolejne zapytania (pod-perspektywy), i dopiero wszystkie razem tworzą definicję perspektywy. obiekty wirtualne ziarna oś

15. Jak mogłaby syntaktycznie wyglądać definicja perspektywy? • Musimy rozróżnić: • Utworzenie perspektywy • Usunięcie perspektywy • Metamodel dla perspektywy (jej organizację wewnątrz składu) • Ewentualnie "zarządczą" aktualizację perspektywy (zmianę jej wnętrza) create view BogatyPracDef { virtual objects BogatyPrac { return Prac where Zar > 10000 } .... //dalsze elementy definicji } Nazwa zarządcza Nazwa obiektów wirtualnych Definicja osi perspektywy delete BogatyPracDef; Usunięcie definicji perspektywy ze składu Usunięcie wszystkich obiektów wirtualnych (ale sama definicja perspektywy pozostaje) delete BogatyPrac;

16. Stan składu i stosu ENVS po zdefiniowaniu perspektywy Skład: Stos ENVS: BogatyPracDef ..... obiekty, klasy, inne perspektywy, ... BogatyPracDef(...) BogatyPrac(..) .... ...inne bindery... Musi być binder do definicji perspektywy (dla celów zarządczych), jak i binder do definicji osi (obiektów wirtualnych) umożliwiający zapytania i aktualizację obiektów wirtualnych.

17. Wywołanie perspektywy • W zapytaniach odwołujemy się do perspektywy poprzez nazwę obiektów wirtualnych. • np. BogatyPrac where Nazw = "Kowalski" • Dla celów zarządczych programista/administrator może użyć nazwy zarządczej. • Uprawnienia mogą być zróżnicowane, np. użytkownik może używać wyłącznie nazwy obiektów wirtualnych, natomiast administrator - wyłącznie nazwy zarządczej. • Wywołanie procedury powoduje wykonanie zapytania definiującego oś. Wynikiem takiego zapytania jest kolekcja bytów, które nazwiemy identyfikatorami wirtualnymi. • Identyfikator wirtualny jest trójką: <Flaga "jestem obiekt wirtualny", Nazwa zarządcza, Ziarno>

18. Rola identyfikatorów wirtualnych • Są odpowiednikiem identyfikatorów zapamiętanych obiektów. • Poprzez ziarno (element osi perspektywy) wyznaczają obiekt wirtualny w sposób jednoznaczny • Wiadomo z której perspektywy pochodzą. • Istotne jest to, że 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 • operator podstawienia (update) na l-value (wirtualną referencję) • operator usunięcia (delete) działający na l-value. • operator wstawiania (insert) działający na l-value

19. Sposób przetwarzania identyfikatorów wirtualnych Definicja perspektywy Fragment (procedura) zajmująca się danym "konsumentem", np. "delete" Program użytkownika zapytanie odwołujące się do perpektywy Identyfikatory wirtualne na stosie QRES "Konsument" wyniku zapytania, np. "delete" Interpreter zapytań i instrukcji Fragment interpretera obsługujący danego "konsumenta", np. "delete" ....... ...... Po rozpoznaniu przez interpreter, że ma on do czynienia z id.wirtualnym następuje wywołanie odpowiedniej procedury z definicji perspektywy Po powrocie z procedury interpreter kończy tę akcję (nie wykonuje żadnych operacji na danych - bo zrobiła je procedura)

20. Wywołanie odpowiedniej procedury z definicji perspektywy • Przy tym schemacie interpreter wie: • o jaką operację chodzi, np. jest to operacja delete, wobec czego wywoływana jest procedura dla delete. • O jaką perspektywę chodzi, bo identyfikator wirtualny zawiera nazwę zarządczą perspektywy. • O jaki obiekt wirtualny chodzi - bo id. wirtualny zawiera jego ziarno. • Ziarno jest przekazywane jako parameter wywoływanej procedury. • 1-szy sposób - umieścić nested(ziarno) na ENVS i następnie wywołać procedurę • Ten sposób jest preferowany, bo jest bardzo prosty • 2-gi sposób - wywołać procedurę z tym parametrem • Niektórzy "konsumenci' mogą mieć inne parametry; np. operacja podstawienia ma dodatkowy parametr w postaci r-value. • Do zakomunikowania tego parametru można wybrać pierwszy (IMHO gorszy) lub drugi (IMHO lepszy) sposób.

21. Jacy mogą być "konsumenci" identyfikatorów wirtualnych? • Nie jest ich dużo. Dokładnie 4. • Dereferencja - musi być zastosowana wszędzie tam, gdzie identyfikator musi zmienić się na wartość, np. print, +, <, parametr call-by-value, itd. • Update - podstawienie, r-value jako dodatkowy parametr • Delete - usunięcie • Insert - wstawienie obiektu "do środka" obiektu wirtualnego, jego referencja jako dodatkowy parametr • Nie wiem jak zrobić operację "create" dla obiektów wirtualnych - jej argumentem nie jest identyfikator wirtualny. • Jak tę operację powiązać z perspektywą? • Jedyne co mi przychodzi do głowy: definiujący perspektywę musi napisać specjalną procedurę lub metodę do tworzenia obiektów wirtualnych, która musi być wywołana explicite.

22. Nowe elementy w definicji perspektywy Nazwa zarządcza Nazwa obiektów wirtualnych Definicja osi perspektywy Definicja operacji dereferencji Definicja podstawienia Definicja usunięcia Definicja wstawienia create view BogatyPracDef { virtual objects BogatyPrac { return Prac where Zar > 10000 }; on_retrieve do {......}; on_update(rvalue)do{......}; on_delete do {......}; on_insert(objectref)do{...}; ...//dalsze elementy definicji } Słowa on_ retrieve, on_update, on_delete, on_insert są identyczne dla wszystkich definicji perspektyw. Niektóre mogą być pominięte, co oznacza, że definiujący nie przewiduje takiego konsumenta. Każdy taki fragment jest traktowany dokładnie tak procedura. Nazwy parametrów (np. rvalue, objectref) wybiera definiujący perspektywę.

23. Jak to będzie wyglądać w metamodelu? on_retrieve (flaga:procedura) on_update (flaga:procedura) on_delete (flaga:procedura) on_insert (flaga:procedura) BogatyPracDef (flaga: perspektywa) BogatyPrac (flagi: oś, procedura) Dalsze elementy definicji perspektywy

24. Pod-perspektywy i funkcja nested (1) • Pozostaje jeszcze pytanie: co się stanie jeżeli identyfikator wirtualny jest przetwarzany przez operator nie-algebraiczny (where, kropka, złączenie, kwantyfikator, etc.)? • Zgodnie z "klasyką" SBA w modelu składu M0, na identyfikatorze wykonywana jest funkcja nested; następnie jej rezultat jest wkładany na wierzch ENVS. • Dla modeli M1, M2, M3, itd. jest to dodatkowo powiązane z wkładaniem na stos ENVS sekcji z binderami do własności odpowiednich klas. • "Klasyka" SBA zostanie zastosowana dla perspektyw, z małą modyfikacją: • jeżeli przetwarzany jest id.virt. <fl, nz, ziarno>, to na czubek ENVS wkładana jest sekcja z nested(ziarno) • Następnie wkładana jest na wierzch ENVS sekcja z binderami do wszystkich pod-perspektyw danej perspektywy

25. Pod-perspektywy i funkcja nested (2) • W ten sposób na czubku ENVS będzie wnętrze "ziarna", co umożliwi pod-perspektywom potraktowanie go jako parametru. • Bindery do samych pod-perspektyw będą także obecne,czyli użytkownik będzie mógł ich ich używać jako "atrybutów" obiektów wirtualnych. • Czy wkładać na czubek ENVS bindery z nazwami zarządczymi pod-perspektyw? - wydaje się, że nie potrzeba. • Cała reszta jest pozostawiona relatywizmowi i rekurencji: jeżeli pod-perspektywa jest także perspektywą, to wszelkie jej własności zostały już wyjaśnione. • Natomiast pojawia się różnica w konstrukcji identyfikatora wirtualnego zwracanego przez pod-perspektywę.

26. Przetwarzanie identyfikatora wirt. przez operator nie-algebraiczny Stos ENVS bindery z nazwami i identyfikatorami osi wszystkich pod-perspektyw zawartych w nz Przetwarzany jest identyfikator wirt. <fl, nz, ziarno> nested(ziarno) ...poprzednia zawartość stosu... ...poprzednia zawartość stosu...

27. Identyfikator wirtualny dla pod-perspektyw • Dotychczasowa konstrukcja identyfikatora wirtualnego może być nie wystarczająca dla niektórych celów, gdyż nie uwzględnia ziaren nad-perspektyw, które mogą być niezbędne jako parametry niektórych aktualizacji obiektów wirtualnych. • W związku z tym należy uogólnić pojęcie identyfikatora wirtualnego do sekwencji dotychczas wprowadzonych identyfikatorów wirtualnych, czyli: <Flaga "jestem obiekt wirtualny", NazwaZarządcza1(Ziarno1), NazwaZarządcza2(Ziarno2), NazwaZarządcza3(Ziarno3), ... > • gdzie NazwaZarządcza1 jest nazwą zarządczą perspektywy najwyższego poziomu, Ziarno1 jest jej ziarnem, NazwaZarządcza2 jest nazwą zarządczą pod-perspektywy NazwaZarządcza1, Ziarno2 jest ziarnem perspektywy NazwaZarządcza2, itd.

28. Konsekwencje uogólnionego identyfikatora wirtualnego • Wołanie procedury "konsumenckiej" z podanych 4-ch: dotarcie do niej wymaga użycia kilku nazw zarządczych występujących w identyfikatorze wirtualnym, np. poprzez wyrażenie ścieżkowe NazwaZarządcza1.NazwaZarządcza2.NazwaZarządcza3.on_update • Na stos władamy bindery nested(Ziarno1), nested(Ziarno2), nested(Ziarno3), komunikując w ten sposób parametry do ewentualnego wykorzystania w procedurach konsumenckich. • Można również nieco chytrzej, aby uniknąć ewentualnej kolizji nazw, ale na razie chyba nie warto. • Funkcja nested: analogicznie wkładamy na ENVS nested od wszystkich ziaren występujących w identyfikatorze wirtualnym będącym argumentem funkcji nested.

29. Jak to będzie wyglądać w metamodelu? on_retrieve (flaga:procedura) ZarobekDef (flaga:perspektywa) NazwDef (flaga:perspektywa) NazwSzefaDef (flaga:perspektywa) on_update (flaga:procedura) on_delete (flaga:procedura) on_insert (flaga:procedura) BogatyPracDef (flaga: perspektywa) BogatyPrac (flagi: oś, procedura)

30. Podsumowanie • Podane założenia wydają się spójne i implementowalne. • Zrealizowanie ich nawet w modelu M0 (czyli dla XML) powinno być bardzo dobrze odebrane przez środowisko, zarówno internetowe jak i bazodanowe. Na pewno wystarczy jako teza doktoratu. • Tego rodzaju perspektywy będą w pełni realizować to, co Wiederhold nazywa "mediators", czyli będą mogły w "inteligentny" (tfu, nie lubię tego słowa) sposób przystosowywać dane np. w XML do zupełnie innego formatu. • Dla osób o nieograniczonej wyobraźni (niestety, nielicznych w społeczności baz danych) powinno być jasne jest jak to można rozszerzyć do modeli M1, M2, M3, itd. • wystarczy np. umieścić definicję klasy wewnątrz definicji perspektywy i wrzucić na ENVS w odpowiednich momentach bindery do jej wnętrza...

31. Przykłady - struktura bazy danych Adres [0..1] Miasto Ulica NrDomu Schemat obiektowy (diagram klas) Prac[0..*] NrP Nazwisko Stan Zar Ocena Zatrudnia[1..*] PracujeW Dział [0..*] NrD Nazwa Lokacja[1..*] Kieruje[0..1] Szef Asocjacje są zrealizowane jako (bliźniacze) obiekty pointerowe

32. Przykład 1 • Perspektywa PracSzef • Dla wszystkich pracowników zwraca nazwisko pracownika i nazwisko szefa jako stringi (dla wymuszenia dereferencji konkatenacja z pustym stringiem). • Podstawienie stringu na nazwisko szefa powoduje przeniesienie pracownika do działu, którego szef ma nazwisko użyte w podstawieniu. • Usunięcie obiektu wirtualnego powoduje usunięcie odpowiedniego obiektu pracownika. • Przykład ilustruje fakt, że pojęcie osi jest niezbędne • Schemat dla obiektów wirtualnych: PracSzef [0..*] NazwPrac: string NazwSzefa: string

33. Przykład 1 -cd. create view PracSzefDef{ virtual objects PracSzef{ return Prac as p }; on_delete do {delete p }; create viewNazwPracDef{ virtual objectsNazwPrac{ return p.Nazwisko as np}; on_retrieve do{return np & ""} } create viewNazwSzefaDef{ virtual objectsNazwSzefa{ return p.PracujeW.Dział. Szef.Prac.Nazwisko as ns}; on_retrieve do{return ns & ""}; on_update(NowySzef) do { p.PracujeW :=& Dział where (Szef.Prac.Nazwisko) = NowySzef; } } } Interpreter włożył na ENVS binder p( referencja do Prac ) Nie ma on_retrieve, bo nie zakładamy tu dereferencji. Interpreter włożył na ENVS bindery p( referencja do Prac ) np( referencja do Nazwisko) Interpreter włożył na ENVS bindery p( referencja do Prac ) ns( referencja do Nazwisko) Zakładamy automatyczną aktualizację bliźniaczych pointerów. Trochę jakby za dużo nazw ... może coś można uprościć.

34. Przykład 1 -Wykorzystanie perspektywy: Wydruk nazwisk wszystkich pracowników zatrudnionych w dziale kierowanym przez Kowalskiego: print (PracSzef where NazwSzefa = "Kowalski").NazwPrac; Wydruk całej informacji o pracownikach zatrudnionych w dziale kierowanym przez Kowalskiego: print PracSzef where NazwSzefa = "Kowalski"; Niepoprawne zdanie, bo dla obiektów wirtualnych PracSzef nie zdefiniowano dereferencji. Zwolnij z pracy pracownika 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"; Zmień nazwisko pracownika z Głąb na Gołąb: for each PracSzef where NazwPrac = "Głąb" do NazwPrac := "Gołąb"; Niepoprawne zdanie, bo dla obiektów wirtualnych NazwPrac nie zdefiniowano podstawienia.

35. Przykład 2 • Perspektywa DziałŚrZar - dotyczy działów zlokalizowanych w Radomiu i zwraca nazwę działu i średnią zarobków 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 ocen wyrażanych w skali 0..10. • Schemat dla obiektów wirtualnych DziałŚrZar [0..*] Nazwa: string ŚrZar: real

36. Przykład 2 - cd. create view DziałŚrZarDef{ virtual objects DziałŚrZar{ return (Dział where "Radom" in Lokacja) as d }; create viewNazwaDef{ virtual objectsNazwa{ return d.Nazwa as nd}; on_retrieve do{return nd & ""} } create viewŚrZarDef{ virtual objectsŚrZar{ return avg(d.Zatrudnia.Prac.Zar) as sreza }; on_retrieve do {return sreza}; on_update(Podwyżka) do { create local SumaWażona(sum(d.Zatrudnia.Prac.(Zar*Ocena))); create local Ratio(Podwyżka * count(d.Zatrudnia) / SumaWażona); for each d.Zatrudnia.Prac do Zar := Zar + Ratio*Zar*Ocena; } } }

37. Przykład 2 - cd. • Teraz oczywiście można podstawiać na średnią zarobków, • co powinno wzbudzić stan apopleksji u różnych "top-level professionals", którzy przez lata zarzekali się, że tego nigdy nie da się zrobić. Podnieś o 100 średnie pobory w dziale "Lalki Barbie": for each DziałŚrZar where Nazwa = "Lalki Barbie" do ŚrZar := ŚrZar + 100; Procedura on_update została napisana tak, że efekt będzie dokładnie zwiększeniem średniej zarobków o 100 zł. Natomiast dystrybucja indywidualnych podwyżek jest proporcjonalna do zarobku i oceny, np. Malinowski Kowalski Nowak Zarobek 100 200 300 Ocena 3 7 10 Podwyżka 19 zł 15 gr 89 zł 36 gr 191 zł 49 gr