J zyki i rodowiska programowania system w rozproszonych
This presentation is the property of its rightful owner.
Sponsored Links
1 / 20

Języki i środowiska programowania systemów rozproszonych PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

Języki i środowiska programowania systemów rozproszonych. Wykład 12 Reguły zakresu Procedury rekurencyjne Optymalizacja poprzez modyfikację zapytań. Wykładowca : Tomasz Kowalski Wykłady przygotowane na podstawie materiałów prof. Kazimierza Subiety. Reguły zakresu.

Download Presentation

Języki i środowiska programowania systemów rozproszonych

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


J zyki i rodowiska programowania system w rozproszonych

Języki i środowiska programowania systemów rozproszonych

Wykład 12

Reguły zakresu

Procedury rekurencyjne

Optymalizacja poprzez modyfikację zapytań

Wykładowca: Tomasz Kowalski

Wykłady przygotowane na podstawie materiałów

prof. Kazimierza Subiety


Regu y zakresu

Reguły zakresu

  • Reguły zakresu są wyznaczone przez kolejność ustawienia sekcji ENVS oraz regułami ich przesłaniania - powinny być naturalne i logiczne dla programistów.

  • Nie zawsze jest to oczywiste.

    • Np. dlaczego podczas wiązania nazwy występującej w ciele metody najpierw jest odwiedzana sekcja z prywatnymi własnościami klasy/obiektu, a dopiero później z publicznymi? Dlaczego nie odwrotnie?

    • Gdyby ta kolejność została zmieniona, własności semantyczne języka również uległyby zmianie, gdyż różne sekcje mogą posiadać bindery z tymi samymi nazwami.

  • W obiektowości jest kilka sytuacji, gdy nie da się uniknąć binderów z tymi samymi nazwami na stosie środowiskowy.

  • Istotą koncepcji stosu środowiskowego jest to, aby nie dopuszczać do wiązania, które nie jest oczekiwane przez programistę.

  • Regułami zakresu rządzi zdrowy rozsadek oraz dwie zasady:

    • zasada priorytetu lokalnego środowiska

    • zasada leksykalnego zakresu.


Zasady rz dz ce regu ami zakresu

Zasady rządzące regułami zakresu

  • Zasada priorytetu lokalnego środowiska:

    Przy wiązaniu nazw lokalne środowisko ma priorytet przed dowolnym środowiskiem bardziej globalnym.

    • Na mocy tej zasady na samej górze stosu ENVS znajduje się lokalne środowisko metody, niżej jest środowisko przetwarzanego obiektu, jeszcze niżej środowisko sesji, potem środowisko bazy danych, wreszcie środowisko całego systemu komputerowego.

    • Zasada ta jest podstawą zagnieżdżania operatorów nie-algebraicznych.

  • Zasada leksykalnego zakresu (lexical scoping):

    Nazwa nie może być wiązana do bytu, którego nie mógł być świadomy programista w momencie pisania zapytania lub programu.

    • Dotyczy to: lokalnych środowisk innych procedur,

    • wszelkich własności prywatnych (obiektów, klas, modułów),

    • kodów, które pojawią się niezależnie i później niż moment pisania danego zapytania lub programu.


Przyk ad skutk w regu zakresu

Przykład skutków reguł zakresu

Kolejność wiązania nazw występujących w ciele m1

Sekcje wywołania m1dla ri

Sekcje indukowane przez q2, w którym znajduje się wołanie metody m1

Sekcje indukowane przez  dla ri

Sekcje indukowane przez wywołanie m2

Sekcje indukowane przez wywołanie p

.........

Sekcje bazowe ENVS

  • Rozpatrzmy zapytanie q1 q2 i załóżmy, że aktualnie wykonywana jest metoda m1występująca w q2 i przetwarzająca referencję ri . Niech powyższe zapytanie występuje wewnątrz ciała metody m2, która została wywołana z procedury p.

  • Sytuacja na stosie środowiskowym:

  • Zilustrowana jest zasada leksykalnego zakresu: programista piszący metodę m1nie znał środowisk zaznaczonych na rysunku na czarno, wobec czego nazwy występujące w m1nie mogą być w nich wiązane.


Cis e wo anie przez warto strict call by value

Ścisłe wołanie przez wartość (strict-call-by-value)

  • Zróżnicowanie na wołanie przez wartość i wołanie przez referencję nie zawsze jest korzystne.

    • Wymaga odrębnej składni oraz powoduje ograniczenia jeżeli chodzi o rodzaj komunikowanej wartości.

  • W języku C takie zróżnicowanie nie występuje: parametr pointerowy jest przekazywany do ciała procedury bez zmian.

  • W systemie Loqis zdecydowaliśmy się wprowadzić tę metodę w wariancie Pascala, tj. bez tworzenia lokalnego obiektu.

    • Składnia deklaracji procedury z takim parametrem będzie następująca:

      procedureNazwaProcedury( ...; NazwaParam; ...){...ciało...}

    • Składnia wywołania, jak poprzednio:

      NazwaProcedury( ...; zapytanie; ...)

  • Powyższe zapytanie może zwrócić dowolny rezultat r  Rezultat zbudowany z referencji, wartości, nazw i konstruktorów struktur i kolekcji.

    • Rezultat ten jest bez zmian przekazywany do ciała procedury w ten sposób, że do jej zapisu aktywacyjnego wstawia się pojedynczy binder NazwaParam( r ).

  • W ten sposób metoda ta łączy wołanie przez wartość z wołaniem przez referencję oraz posiada dalsze możliwości, niedostępne w tych metodach.


Przyk ad cis ego wo ania przez warto

Przykład ścisłego wołania przez wartość

  • Parametrem komuIle procedury ZmieńZarobek jest bag struktur

    struct{ komu(r), ile(w) },

    gdzie r jest referencją do obiektu pracownika, w jest jego nowym zarobkiem.

  • Procedura przyznaje ten nowy zarobek tym pracownikom, dla których jest on większy od ich aktualnego zarobku. W razie konfliktu (jeżeli referencja danego pracownika wystąpi wielokrotnie), wybiera maksymalną z możliwych nowych wartości zarobku.

    procedureZmieńZarobek ( komuIle ) {

    for each distinct( komuIle.komu ) aspdo

    p.Zar := max( bag( p.Zar, (komuIlewherekomu = p). ile))}

  • Pracownikom z Radomia udziel podwyżki w wysokości 100, pracownikom po 40-tce udziel podwyżki w wysokości 200, zaś wszystkim sekretarkom ustal zarobek na 1000 (z uwzględnieniem ew. innych kryteriów dających więcej).

    ZmieńZarobek ( bag(

    ((Pracwhere ”Radom” PracujeW.Dział.Lokacja) askomu

    join (komu.zar + 100) asile),

    ((PracwhereWiek > 40) askomujoin (komu.zar + 200) asile),

    ((PracwhereStan = ”sekretarka”) askomu, 1000 asile)))


Procedury rekurencyjne

Procedury rekurencyjne

  • Podejście stosowe zakłada rekurencję jako własność oczywistą.

  • Umożliwienie określania parametrów procedur w postaci zapytań oraz zwracania wyniku procedur w postaci dowolnej wartości dziedziny Rezultat stwarza nową jakość, która dotychczas była kwalifikowana jako własność „inteligentna”, specyficzna dla dedukcyjnych baz danych.

  • Przy pomocy rekurencyjnych procedur można bez trudu osiągnąć efekty tranzytywnych domknięć oraz równań stało-punktowych.

  • Mimo różnic składniowych i semantycznych, są to mechanizmy porównywalne pragmatycznie.

  • Z doświadczeń autora wynika, że procedury rekurencyjne są bardziej zrozumiałe dla powszechnego programisty, być może wskutek praktyki edukacyjnej.


Schemat struktury hierarchicznej cz ci wyrobu

Schemat struktury hierarchicznej części wyrobu

Część[0..*]

nazwa

rodzaj

kosztDet[0..1]

masaDet[0..1]

kosztMont[0..1]

masaMont[0..1]

składnik[0..*]

ilość

prowadziDo

”detal”, ”agregat”


Przyk ad funkcji rekurencyjnej

Przykład funkcji rekurencyjnej

  • Procedura Podczęści ma parametr mojeCzęści bedącego bagiem referencji do części.

    • Procedura zwraca bag z referencjami do wszystkich pod-części części wymienionych w parametrze.

    • Duplikaty w wyniku nie są usuwane.

    • Przy transmisji parametrów przyjmujemy metodę ścisłego wołania przez wartość.

      procedurePodczęści(mojeCzęści) {

      return if not exists(mojeCzęści) then bag{}

      else bag(mojeCzęści,

      Podczęści(mojeCzęści.składnik.prowadziDo.Część))}

  • Podaj nazwy wszystkich części detalicznych składających się na samolot Boeing 767:

    distinct( Podczęści( Część where nazwa = ”Boeing 767” )

    whererodzaj = ”detal”).nazwa


Inny przyk ad na rekurencj

Inny przykład na rekurencję

  • Obiekty Osoba mają atrybuty nazwisko, rokUr (rok urodzenia), żyje (z wartością boolowską), oraz są powiązane związkami rodzinnymi matka, ojciec, syn, córka, zaimplementowanymi jako obiekty pointerowe umieszczone wewnątrz obiektów Osoba.

  • Procedura Przodek zwraca wszystkich przodków osób zakomunikowanych jako parametr. Procedura Następca zwraca wszystkich następców osób zakomunikowanych jako parametr.

    procedurePrzodek( mojeOsoby) { return if not exists(mojeOsoby) then bag{}

    else distinct( bag(mojeOsoby, Przodek(mojeOsoby.(matka ojciec).Osoba)))}

    procedureNastępca( mojeOsoby) {return if not exists(mojeOsoby) then bag{}

    else distinct( bag(mojeOsoby, Następca (mojeOsoby.(syn córka).Osoba)))}

  • Podaj nazwisko i rok urodzenia wszystkich żyjących kuzynów Kowalskiego, którzy są od niego młodsi:

    (((Osobawherenazwisko = ”Kowalski”) askow)

    join (Następca(Przodek( kow )) askuzyn)

    where (kow.rokUr < kuzyn.rokUr and kuzyn.żyje)).(kuzyn.(nazwisko, rokUr))


Modyfikacja zapyta

Modyfikacja zapytań

  • Modyfikacja zapytań jest podstawową metodą optymalizacji zapytań używających perspektyw.

    • Jest stosowana we wszystkich systemach relacyjnych.

    • Ponieważ pojęcie perspektywy, tak jak jest ono wprowadzone w systemach relacyjnych, jest równoważne procedurze funkcyjnej, w istocie metoda modyfikacji zapytań dotyczy tych ostatnich.

    • Pokażemy jednak dalej, że ma ona zastosowanie również dla aktualizowalnych perspektyw.

  • Metoda została sformułowana przez M.Stonebrakera w 1975 roku, ale wskutek braku ortogonalności ówczesnych języków zapytań (w szczególności QUEL i SQL) sformułowanie jest bardzo złożone i niejasne.

    • Wydawało się wówczas, że jest ona całkowicie oryginalnym wynalazkiem.

  • Okazało się, że przy założeniu pełnej ortogonalności języka (cecha SBQL) i przy przyjęciu tezy, że perspektywa jest procedurą funkcyjną, metoda ta jest wariantem metody, która była znana już w latach 60-tych i powszechnie stosowana w optymalizacji programów.


Modyfikacja zapyta makro substytucja

Modyfikacja zapytań = makro-substytucja

  • Metoda modyfikacji zapytań polega na tym, że definicję funkcji traktuje się jako makro-definicję.

    • Wszędzie tam, gdzie w zapytaniach występuje nazwa funkcji, zastępuje się tę nazwę poprzez tekst będący definicją tej nazwy (pomijając nieistotne elementy leksykalne). Po tym zabiegu uzyskuje się zapytanie bez odwołań do funkcji.

    • Poddaje się go następnie innym metodom optymalizacyjnych.

  • Aby metoda ta prowadziła do semantycznie poprawnych konstrukcji i nie zmieniała znaczenia zapytania, jej zastosowanie wymaga wprowadzenia ograniczeń na postać deklaracji funkcji:

    • Funkcja nie może mieć lokalnego środowiska, w szczególności, nie może mieć parametrów.

    • Funkcja nie może być także rekurencyjna, pośrednio lub bezpośrednio, gdyż prowadziłoby to do nieskończonej pętli stosowania makro-definicji.

    • Środowisko w którym wywoływana jest funkcja jest takie samo jak środowisko, w którym ewaluowane jest zapytanie wewnątrz tej funkcji.

    • Funkcja powinna mieć postać procedureNazwaFunkcji { returnzapytanie}

      równoważną pojedynczemu zapytaniu.


Dlaczego w sql jest to skomplikowane

Dlaczego w SQL jest to skomplikowane?

  • Brak ortogonalności, chaotyczność konstrukcji SQL powoduje powstanie w tej materii skomplikowanych algorytmów.

  • Jedną z przyczyn skomplikowania metody modyfikacji zapytań w systemach relacyjnych jest brak formalnej semantyki pomocniczych nazw.

    • Jest ona niewyrażalna w algebrze relacji, rachunku relacyjnym i stosowanych w tym celu logikach, zatem oparcie semantyki języka zapytań na tych formalizmach powoduje poważne ograniczenia.

    • Definicje perspektyw w SQL określają w nagłówku nazwy wirtualnych atrybutów, zatem wstawienie ciała definicji jako fragmentu zapytania wymaga odpowiednich operacji na tych nazwach.

Schemat relacyjny

Adres

NrP

Miasto

Ulica

NrDomu

Prac

NrP

Nazwisko

Stan

Zar

PracujeW

Dział

NrD

Nazwa

Szef

Lokacje

NrD

Lokacja


Przyk ad w sql

Przykład w SQL

  • Definicja perspektywy w SQL ma postać:

    create viewPracSzef( Naz, NazD, NazSzefa) as

    selectp.Nazwisko, d.Nazwa, s.Nazwisko

    fromPrac p, Dział d, Prac s wherep.PracujeW = d.NrDandd.Szef = s.NrP

    • Nowe nazwy Naz, NazD, NazSzefa są nazwami kolumn wirtualnej tabeli, które można używać w zapytaniach, np.:

    • Podaj nazwiska i nazwy działów pracowników nazywających się tak samo jak ich szef):

      selectp.Naz, p.NazDfromPracSzef r wherer.Naz = r.NazSzefa

  • Jeżeli w powyższym zapytaniu podstawilibyśmy na PracSzef tekst z definicji perspektywy znajdujący się po as, to otrzymalibyśmy niepoprawne zapytanie.

    • W systemach relacyjnych podmiana ta następuje na poziomie drzew syntaktycznych zapytania i definicji perspektywy.

    • Należy jeszcze dokonać odpowiedniej transformacji nazw Naz, NazD, NazSzefa występujących w tak przekształconym zapytaniu na nazwy atrybutów z zapamiętanych tabel, a to prowadzi do złożonych i niejasnych semantycznie algorytmów.


Dlaczego w sbql jest to banalnie proste

Dlaczego w SBQL jest to banalnie proste?

  • Pełna ortogonalność.

  • Pomocnicze nazwy są objęte semantyką języka.

    • Ten sam przykład w SBQL:

    • Jak widać, nazwy „wirtualnych kolumn” tej perspektywy są standardowymi nazwami powoływanymi przez operator as.

    • Dzięki temu nie ma problemów koncepcyjnych z modyfikacją zapytań.

    • Sprowadza się ona do prostej operacji zastąpienia nazwy PracSzef występującej w zapytaniu przez tekst zapytania znajdującego się po słowie return.

procedure PracSzef {

return (Prac as p, Działas d, Prac as s)

where (p.PracujeW = d.NrD and d.Szef = s.NrP).

(p.Nazwisko as Naz, d.Nazwa as NazD, s.Nazwisko as NazSzefa )}


Co si dzieje z zapytaniem w sbql

Co się dzieje z zapytaniem w SBQL?

  • Zapytanie równoważne podanemu poprzednio zapytaniu SQL ma w SBQL następującą postać:

  • Jeżeli zamiast PracSzef podstawimy tekst zapytania z ciała definicji funkcji PracSzef, to otrzymamy następujące poprawne zapytanie w SBQL:

  • Zapytanie to nie ma już odwołań do funkcji PracSzef. Wynik tego zapytania będzie identyczny z wynikiem oryginalnego zapytania. Zapytanie to może być następnie optymalizowane przy pomocy metod, które będą objaśnione w przyszłym semestrze (i w książce).

(PracSzef asrwherer.Naz = r.NazSzefa). (r.Naz, r.NazD)

(((Prac as p, Działas d, Prac as s)

where (p.PracujeW = d.NrD and d.Szef = s.NrP).

(p.Nazwisko as Naz, d.Nazwa as NazD, s.Nazwisko as NazSzefa )) asrwherer.Naz = r.NazSzefa). (r.Naz, r.NazD)


Modyfikacja zapyta dla struktur obiektowych 1

Modyfikacja zapytań dla struktur obiektowych (1)

Schemat obiektowy (diagram klas)

Prac [0..*]

NrP

Nazwisko

Stan

Zar

Zatrudnia[1..*]

PracujeW

Dział [0..*]

NrD

Nazwa

Lokacja[1..*]

Kieruje[0..1]

Szef

Adres [0..1]

Miasto

Ulica

NrDomu

  • W SBQL mogą być modyfikowane zapytania odwołujące się do dowolnych obiektowych struktur danych.

    Funkcja MałoZarabiający zwraca bag { struct{ N(iNazwisko), Z(iZar), D(iNazwa)}}

procedure MałoZarabiający {

return (Prac where Zar < 0.5 * avg( Prac.Zar ) ) .

( Nazwisko as N, Zar as Z, (PracujeW.Dział.Nazwa) as D) };


Modyfikacja zapyta dla struktur obiektowych 2

Modyfikacja zapytań dla struktur obiektowych (2)

  • Funkcja ta może być użyta w następującym zapytaniu:

    (MałoZarabiającywhereN = „Bilski”).Z

    • Załóżmy, że w bazie danych dostęp poprzez atrybut Nazwisko jest wspomagany indeksem IndeksPracNazwisko( nazw ), który zwraca referencję do obiektów Prac dla stringowego parametru nazw będącego nazwiskiem.

  • Zauważmy następujące okoliczności:

    • Zmaterializowanie wyniku procedury będzie czasochłonne.

    • Indeks IndeksPracNazwisko, zapewniający szybki dostęp do obiektów wg nazwisk, w powyższym zapytaniu nie może być wykorzystany.

    • Zwracanie przez funkcję nazwy działu jest niepotrzebne, bo tej danej zapytanie nie wykorzystuje.

  • Modyfikacja zapytań usuwa te problemy.

    • Dzięki niej nie trzeba będzie liczyć wszystkich elementów tej perspektywy, w szczególności jej niepotrzebnych członów.

    • Można będzie również wykorzystać indeks.

    • Prześledźmy to na kolejnych krokach.


Kroki modyfikacji i optymalizacji 1

Kroki modyfikacji i optymalizacji (1)

  • Po makro-substytucji:

    (( (PracwhereZar < 0.5 * avg( Prac.Zar )).

    (NazwiskoasN, ZarasZ, (PracujeW.Dział.Nazwa) asD) )

    whereN = „Bilski”) . Z

  • Pod-zapytanie (PracujeW.Dział.Nazwa)as D nie jest używane (jest „martwe”); może być więc usunięte.

    (( (PracwhereZar < 0.5 * avg( Prac.Zar ) ).

    (NazwiskoasN, ZarasZ) )

    whereN = „Bilski”).Z

  • Rezultat pod-zapytania 0.5 * avg( Prac.Zar ) jest identyczny dla wszystkich pracowników; pod-zapytanie to może być zatem wyciągnięte przed pętlę implikowaną przez pierwszy operator where:

    (((0.5 * avg(Prac.Zar )) group asx).(PracwhereZar < x ).

    (NazwiskoasN, ZarasZ)

    whereN = „Bilski”) . Z


Kroki modyfikacji i optymalizacji 2

Kroki modyfikacji i optymalizacji (2)

  • Definicje pomocniczych nazw N i Z stają się zbędne; można je usunąć, zastępując oryginalnymi nazwami Nazwisko i Zar:

    (((0.5 * avg(Prac.Zar )) group asx).

    (PracwhereZar < x )whereNazwisko = „Bilski”) . Zar

  • Warunki w dwóch następujące po sobie operatorach where łączymy w jeden warunek połączony operatorem and:

    ((0.5 * avg(Prac.Zar )) group asx).(PracwhereZar < x

    andNazwisko = „Bilski”) . Zar

  • W tej chwili można wykorzystać indeks IndeksPracNazwisko, którego wywołanie zastępuje zapytanie PracwhereNazwisko = ”Bilski” :

    ((0.5 * avg(Prac.Zar )) group asx).

    (IndeksPracNazwisko( „Bilski” ) whereZar < x ). Zar

  • Zapytanie jest ostatecznie zoptymalizowane. Optymalizacja odbywała się na podstawie reguł, które można sformalizować i zaimplementować.


  • Login