Konstrukcja system w obiektowych i rozproszonych
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Konstrukcja systemów obiektowych i rozproszonych PowerPoint PPT Presentation


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

Konstrukcja systemów obiektowych i rozproszonych. Wykład 2: Aktualizowalne perspektywy (1). Wykładowca : Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa [email protected] Instytut Podstaw Informatyki PAN, Warszawa [email protected]

Download Presentation

Konstrukcja systemów obiektowych i 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


Konstrukcja system w obiektowych i rozproszonych

Konstrukcja systemów obiektowych i rozproszonych

Wykład 2:

Aktualizowalne perspektywy

(1)

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa Szkoła

Technik Komputerowych, Warszawa

[email protected]

Instytut Podstaw Informatyki PAN,

Warszawa

[email protected]


Temat wirtualnych perspektyw

Temat wirtualnych perspektyw

  • Temat wirtualnych perspektyw dla relacyjnych baz danych został sformułowany przez E.Codda w 1974 roku.

  • Jest to zagadnienie o ogromnej wadze praktycznej, gdyż wirtualne perspektywy są ważne dla wielu zastosowań baz danych.

  • Temat ten jest znany z SQL i został doceniony przez twórców obiektowo-relacyjnego manifestu baz danych.

  • Od nieomal 30 lat nad tym tematem pracowało dziesiątki lub setki specjalistów.

  • Powstało na ten temat setki publikacji i praktycznych implementacji, w prototypowych i komercyjnych systemach.

  • Najbardziej istotnym problemem jest aktualizacja wirtualnych danych (obiektów).

  • Problem nie doczekał się dostatecznie uniwersalnego rozwiązania na gruncie systemów relacyjnych i  zyskał sobie sławę „arcytrudnego”.

  • Klasyczne rozwiązania w systemach relacyjnych są ograniczone i nie są w stanie spełnić tych oczekiwań, które są często przedstawiane jako motywacja dla podjęcia tego tematu.


Rozwi zanie arcytrudnego tematu

Rozwiązanie arcytrudnego tematu

  • Stosunkowo najbardziej zaawansowane są rozwiązania oparte na tzw. instead of trigger (tryger „zrób zamiast”) w systemach Oracle i MS SQL Server.

  • To rozwiązanie wskazuje kierunek, w którym powinny pójść badania.

  • Rozwiązanie objaśnione w tym wykładzie idzie dokładnie w tym kierunku, ale jest oparte na innym, znacznie bardziej uniwersalnym mechanizmie.

  • Pokażemy, że ten „arcytrudny” temat jest jak najbardziej do opanowania, jeżeli założy się dobre podejście.

  • Jest nim podejście stosowe do języków zapytań.


Co to jest perspektywa pogl d 1

Co to jest perspektywa? - pogląd 1

view, database view

W literaturze funkcjonują dwa różne (zbliżone) znaczenia.

1. Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych (określającego zapamiętane zasoby danych) na schemat “zewnętrzny”, przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika.

Użytkownik 1

Użytkownik 2

Użytkownik 3

Architektura

ANSI/SPARC:

Schematy

“zewnętrzne”

Perspektywa 1

Perspektywa 2

Perspektywa 3

Projektant BD

Administrator BD

Schemat globalny

Poziom fizyczny

bazy danych

Administrator BD


Co to jest perspektywa pogl d 2

Co to jest perspektywa? - pogląd 2

2.Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne.

Matematycznie, perspektywa jest funkcją określoną na danych.

Ten punkt widzenia nie jest precyzyjny, gdyż nie uwzględnia mechanizmów nazywania, wiązania i zakresu.

Nie uwzględnia także kwestii aktualizacji perspektyw.

Nieco bardziej precyzyjny punkt widzenia (systemy relacyjne):

Perspektywa jest procedurą funkcyjną, która zwraca wynik będący tabelą. Taki wynik jest wyposażony w dodatkowe nazwy (nazwy atrybutów wirtualnych tabel zwracanych przez perspektywę).

Perspektywy SQL są uproszczonymi procedurami funkcyjnymi.

Ten punkt widzenia również nie uwzględnia kwestii aktualizacji perspektyw


Po co s perspektywy

Po co są perspektywy?

Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich bardzo aktualny temat.

  • Uproszczenie modeli pojęciowych dla poszczególnych użytkowników.

  • Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki.

  • Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań.

  • Ograniczenie dostępu do obiektów, ochrona prywatności.

  • Ograniczenie dostępu w systemach rozproszonych federacyjnych BD.

  • Logiczna niezależność obiektów i aplikacji działający na obiektach.

  • Współdziałanie systemów heterogenicznych (wspólny schemat).

  • Przystosowanie systemów spadkowych (legacy) do nowszych technologii i wymagań.

  • Hurtownie danych: analiza informacji gromadzonych z heterogenicznych źródeł.


Rodzaje perspektyw

Rodzaje perspektyw

  • Wirtualne perspektywy

    • Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury funkc.). Wyliczenie (materializacja) następuje w momencie użycia perspektywy. Wynik jest “konsumowany” i następnie kasowany.

    • Zalety: nie ma dublowania danych, nie ma problemu aktualizacji wyliczonych danych, nie ma problemów z przetwarzaniem transakcji.

    • Wada: czas ewaluacji perspektyw + czas ewaluacji zapytań używających perspektyw bez optymalizacji często nieakceptowalny.

  • Zmaterializowane perspektywy

    • Perspektywa jest wyliczona “na zapas”, jej wynik jest przechowywany w bazie danych na normalnych zasadach. Aktualizacja danych stanowiących podstawę wyliczenia pociąga za sobą aktualizację zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie).

    • Zalety: szybki dostęp, łatwa implementacja.

    • Wady: zapotrzebowanie na pamięć, możliwość utraty spójności z bazą danych, koszt aktualizacji zmaterializowanych perspektyw (prowadzący do problemów koncepcyjnych i realizacyjnych), wąskie gardło dla transakcji, niejasny koncepcyjnie problem aktualizacji perspektyw.


Zasada przezroczysto ci perspektyw

Zasada przezroczystości perspektyw

view transparency

  • Z punkty widzenia użytkownika/programisty dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych.

    • Np. jeżeli w sfederowanej bazie danych administrator udostępnia tylko część danych poprzez perspektywę, wówczas użytkownik lub programista końcowy nie powinien być zmuszany do modyfikacji swoich programów działających na zapamiętanych danych z tego powodu, że mają one teraz działać na perspektywach.

    • Podobnie, jeżeli “obca” baza danych jest widziana poprzez perspektywę w formacie “naszej” bazy danych, wówczas na “obcej” bazie danych powinny działać wszystkie aplikacje, które działają na “naszej”.

  • Warunek przezroczystości perspektyw jest trudny do spełnienia:

    • Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające.

    • Problem aktualizacji perspektyw.

    • Pewne dane mogą być manipulowane wyłącznie przez przypisane im interfejsy, a nie przez języki zapytań.

    • Powstają problemy z wydajnością.


Aktualizacja perspektyw

Aktualizacja perspektyw

view updating

Najpoważniejszym problemem jest aktualizacja perspektyw. Aktualizacja „wirtualnych” danych jest oczywiście niemożliwa, wobec czego należy w jakiś sposób zamienić tę aktualizację na aktualizację zapamiętanych danych.

Aktualizacja

Dane wirtualne

Perspektywa

Baza danych

Dane zapamiętane

Na ogół odwzorowanie odwrotne, danych wirtualnych w dane zapamiętane, nie jest jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje danych zapamiętanych można zrobić na wiele sposobów.


Przyk ad aktualizacji perspektyw 1

Przykład aktualizacji perspektyw (1)

Dane rzeczywiste

Dane wirtualne

/MojeDziały

Nazwa

ŚredniZarobek

Dział

Nazwa

Pracownik

Nazwisko

Zarobek

zatrudnia

*

Podwyższ średni zarobek w dziale „Serwis” o 500 zł:

?

update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500

where Nazwa = ‘Serwis’;

Zlecenie jest błędne.

(1) Nie ma danej o nazwie ŚredniZarobek.

(2) Nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy do wyboru nieskończenie wiele sposobów. Prawdopodobnie tylko jeden z nich satysfakcjonowałby osobę, która wydała takie polecenie. Który?


Przyk ad aktualizacji perspektyw 2

Przykład aktualizacji perspektyw (2)

Dane rzeczywiste

Dane wirtualne

Dział

Nazwa

zatrudnia

Pracownik

Nazwisko

Zarobek

/MoiPracownicy

NazwiskoPrac

NazwiskoSzefa

*

szef

0..1

Technika implementacyjna: po wyliczeniu perspektywy MoiPracownicy zwraca ona referencje do nazwiska pracownika i nazwiska jego szefa.

Czy problem aktualizacji został rozwiązany?

Pracownik Kowalski, pracujący dla Styki, ma mieć nowego szefa Nowaka.

?

update MoiPracownicy set NazwiskoSzefa = ‘Nowak’

where NazwiskoPrac = ‘Kowalski’;

Aktualizację można wykonać, zaś nowym szefem Kowalskiego będzie Nowak. Niestety, zlecenie zmieniło nazwisko „Styka” na nazwisko „Nowak”, a chodziło o przeniesienie Kowalskiego do innego działu.

Intencja tego zlecenia została poważnie zniekształcona.


Ograniczenia w aktualizacji perspektyw oracle

Ograniczenia w aktualizacji perspektyw (Oracle)

  • W klauzuli SELECT nie ma słowa DISTINCT

  • W klauzuli FROM jest tylko jedna nazwa tabeli lub tylko jedna nazwa - tabeli lub aktualizowalnej perspektywy

  • Na liście SELECT (wynikowej) znajduja się tylko nazwy kolumn

  • W klauzuli WHERE nie ma podzapytania

  • W zapytaniu nie mogą występować klauzule GROUP BY i HAVING

  • Dodatkowo, Oracle wprowadza tzw. opcję sprawdzania (check option), która oznacza, że nie można aktualizować perspektyw w takich sytuacjach, w których skutki tej aktualizacji będą wykraczały poza to, co użytkownik widzi poprzez tę perspektywę.

    • Np. jeżeli dla perspektywy BiednyPracownik(Nazwisko, Zarobek) wyliczanej na podstawie Zarobek < 1000 zwiększymy zarobek Kowalskiego o 1000, to zniknie on z perspektywy, co może zaskoczyć programistę.


Dodatkowe mo liwo ci aktualizacji perspektyw

Dodatkowe możliwości aktualizacji perspektyw

W Oracle można aktualizować perspektywy powstające w wyniku złączenia, ale tylko atrybuty relacji znajdujące się po stronie “klucza obcego”:

CREATE VIEW MoiLudzie( IdPracownika, Nazwisko, IdDziału, NazwaDziału, Zarobek) AS

SELECT p.Id_pracownika, p.Nazwisko, p.Id_działu, d.Nazwa, p.Zarobek

FROM Pracownicy AS p, Działy AS d

WHERE p.Id_działu = d.Id_działu AND p.Stanowisko = ‘programista’;

UPDATE MoiLudzie

SET Zarobek = Zarobek + 500

WHERE NazwaDziału = ‘Serwis’

Podwyższyć o 500 zarobki wszystkim programistom z działu Serwis:

OK.

UPDATE MoiLudzie

SET NazwaDziału = ‘Magazyn’

WHERE Nazwisko = ‘Nowak’

Przenieść programistę Nowaka do działu Magazyn:

Źle!


Kryteria aktualizowalno ci perspektyw

Kryteria aktualizowalności perspektyw

  • Brak nadmiarowej akualizacji. Aktualizacja pewnego elementu perspektywy nie powinna bezwiednie powodować aktualizacji innego.

  • Brak niedostatecznej/błędnej aktualizacji - wynik aktualizacji nie powinien odbiegać od intencji użytkownika. Np. użytkownik aktualizuje zarobek netto o 100, tymczasem faktyczna aktualizacja wyniosła 91,50.

  • Brak efektów ubocznych aktualizacji. Np. takim efektem jest zniknięcie krotki z perspektywy BiednyPracownik po zaktualizowaniu tego zarobku.

  • Brak spontanicznej aktualizacji bazy danych poza fragmentem widocznym poprzez perspektywę.

  • Zdeterminowany translator aktualizacji perspektywy - dla każdego stanu bazy danych powinien działać tak samo.

Podane kryteria są spekulatywnym stereotypem i dotyczą sytuacji, kiedy translacja aktualizacji perspektyw jest dokonywana w pewien automagiczny sposób. Przestają mieć sens, jeżeli pełna kontrola nad aktualizacją perspektyw jest w rękach definiującego perspektywę.


Krytyka dotychczasowych podej 1

Krytyka dotychczasowych podejść (1)

  • W większości, perspektywy są ograniczone do wyszukiwania. Dla wielu zastosowań jest to za mało.

  • Przezroczystość perspektyw wymaga rozwiązania problemu aktualizacji danych wirtualnych, wymagającego spójnego odwzorowania tych aktualizacji na aktualizacje danych zapamiętanych. Ten warunek nie jest spełniony dla wszystkich znanych nam propozycji perspektyw (z wyjątkiem perspektyw opartych na trygerze instead of, które spełniają go częściowo).

  • Wszystkie znane nam koncepcje aktualizowalnych perspektyw opierają się na aktualizacji poprzez wynik wywołania perspektywy.

    • Ten sposób myślenia o perspektywach stał się przyczyną powstania tzw. kryteriów aktualizowalności perspektyw.

    • Z reguły zapytanie wywołujące perspektywę zwraca referencje do zapamiętanych danych, np. wartość klucza głównego relacji, identyfikator obiektu, itp.

    • Jeżeli zapytanie nie zwraca referencji, lecz wartość, wówczas aktualizacja takiej danej wirtualnej jest uważana za niemożliwą. Tę tezę przyjmuje się jak aksjomat.

  • Ta teza jest błędna i prowadzi do niepotrzebnych ograniczeń w aktualizacji perspektyw, czyli złamania zasady przezroczystości.


Krytyka dotychczasowych podej 2

Krytyka dotychczasowych podejść (2)

  • Badania dotyczące aktualizowalności perspektyw zostały zepchnięte na fałszywy tor: badano, jak zapobiec niepożądanym aktualizacjom (setki artykułów), a nie jak zapewnić pełną przezroczystość.

  • Problem aktualizowalnych perspektyw dla obiektowych, obiektowo-relacyjnych i XML-owych baz danych znajduje się w stanie niemowlęcym.

  • Typowe podejścia do obiektowych języków zapytań i perspektyw dzielą je na „zachowujące obiekty” i „generujące obiekty”. Tylko perspektywy „zachowujące obiekty” mogą być aktualizowalne.

    • To powoduje, że większość użytecznych perspektyw staje się nieaktualizowalna.

  • Inne podejście zakłada ortodoksyjną hermetyzację: każdy atrybut A jest związany z metodami getA oraz setA.

    • Problem aktualizowalnych perspektyw znika. Po zdefiniowaniu wirtualnych obiektów wystarczy napisać metody getA i setA dla wszystkich atrybutów A wprowadzonych w definicji perspektywy.

    • W ten sposób otrzymujemy magiczne rozwiązanie poważnego problemu poprzez prostą sztuczkę związaną z definicją hermetyzacji.

  • Życie nie znosi jednak takich cudów i magii, zatem problem pozostaje.

    • Nieadekwatność, koncepcyjne wady ortodoksyjnej hermetyzacji były dyskutowane na wykładzie JPS w poprzednim semestrze.


Rewolucyjna koncepcja

Rewolucyjna koncepcja

  • Załóżmy, że perspektywa MoiPracownicy w wyniku aktualizacji nazwiska szefa rzeczywiście przenosiłaby pracownika do innego działu.

  • Czy byłoby coś złego w takiej perspektywie? Odpowiedź: nie, taka perspektywa jest rozsądna. Jest ona jednak zabroniona przez kryteria aktualizowalności perspektyw.

  • Wniosek: Kryteria aktualizowalności są koncepcyjną bzdurą.

  • Razem z odrzuceniem tych kryteriów trzeba również odrzucić pomysł aktualizacji perspektyw poprzez efekty uboczne, czyli poprzez referencje zwracane przez wywołanie perspektywy.

  • Nasza koncepcja polega na tym, aby wewnątrz definicji perspektywy jej twórca mógł wyrazić intencję każdej aktualizacji tej perspektywy.

  • Intencję tę wyraża w postaci procedur, które są wywoływane w odpowiedzi na aktualizację danych wirtualnych.

  • Takie właśnie podejście zostało zrealizowane (niezależnie) w koncepcjach perspektyw opartych na trygerach instead of.

  • Nasze rozwiązanie jest bardziej eleganckie i bardziej uniwersalne. Pasuje do dowolnych baz danych: relacyjnych, obiektowych, XML-owych, itd.


  • Za o enia metody aktualizacji perspektyw

    Założenia metody aktualizacji perspektyw

    • Odrzucamy wszystkie pseudo-teorie posiadające swoje korzenie w modelu relacyjnym i opieramy rozwiązanie na SBA.

    • Wszelkie konsekwencje aktualizacji perspektywy muszą być określone przez osobę definiującą perspektywę.

      • Nie dopuszczamy aktualizacji perspektywy poprzez referencje zwrócone przez perspektywę.

    • Definiujący perspektywę ma do dyspozycji algorytmicznie kompletne środki do określania intencji aktualizacji.

      • Środki określania tej intencji są inherentną składową definicji perspektywy.

    • Istotą podejścia jest przeciążanie generycznych operatorów imperatywnych zastosowanych do wirtualnych obiektów przez procedury. Procedury te wyrażają intencję aktualizacji.

    • Po zdefiniowaniu perspektywy użytkownik nie może odczuć jakichkolwiek różnic w operowaniu rzeczywistymi i wirtualnymi obiektami.

    • Perspektywy mogą być rekurencyjnie i mogą posiadać parametry.

    • Zakładamy zachowanie zasady relatywizmu, pełnej wewnętrznej identyfikacji, kontrolowania zakresów nazw, formalnej semantyki całego mechanizmu.


    Zasada relatywizmu

    Zasada relatywizmu

    • Definicja perspektyw będzie podlegać zasadzie relatywizmu.

      • Oznacza ona m.in., że perspektywa może mieć podperspektywy.

      • Jeżeli obiekt wirtualny ma atrybuty, to każdy z nich musi być zdefiniowany jako podperspektywa.

      • Liczba poziomów hierarchii podperspektyw jest nieograniczona.

      • Każda perspektywa i podperspektywa ma identyczną składnię, semantykę i pragmatykę, w szczególności, w zakresie aktualizacji.

    • Jeżeli np. BogatyPracownik jest perspektywą, to podperspektywą może być Zarobek.

      • Wynika stąd, że obiekty wirtualne mogą być również atomowe (nie muszą zawierać „atrybutów”).

      • Jest to oczywiste dla zwolenników relatywizmu (i podejścia stosowego), natomiast jest pewną nowością dla społeczności baz danych.

    • Hierarchia perspektyw/podperspektyw odpowiada hierarchii obiektów wirtualnych.


    Zagnie d anie perspektyw i obiekt w wirtualnych

    Zagnieżdżanie perspektyw i obiektów wirtualnych

    Definicja zagnieżdżonych perspektyw

    Obiekty wirtualne

    P

    Perspektywa P

    A

    A

    C

    Perspektywa A

    B

    Perspektywa B

    X

    Y

    Perspektywa

    Y

    Perspektywa

    X

    P

    Perspektywa C

    A

    B

    X

    Y

    X

    X


    Zapamietanie definicji perspektywy i operacje administracyjne nad zapami tanymi definicjami

    Zapamietanie definicji perspektywy i operacje administracyjne nad zapamiętanymi definicjami

    • W odróżnieniu od SQL, nazwa obiektów wirtualnych dostarczanych przez perspektywę jest różna od nazwy zarządczej definicji perspektywy.

      • Nasza perspektywa posiada strukturę, którą należy zarządzać.

      • Nazwa zarządcza jest potrzebna aby wstawić, usunąć, zmienić, odpytać definicję.

    • Definicje perspektyw są złożonymi obiektami zapamiętanymi w składzie.

    • Definicje perspektyw, jako złożone obiekty, mogą być odpytywane i aktualizowane przez SBQL.

    • Operacje administracyjne na definicjach perspektyw:

      • kompilacja kodu źródłowego perspektywy,

      • wstawienie kodu wynikowego nowej perspektywy w odpowiednie miejsce składu,

      • zmiana i usunięcie definicji perspektywy.

    • Operacje te może wykonywać administrator bazy danych lub programista za pomocą operacji wbudowanych w środowisko programistyczne

    • Operacje są ograniczone regułami dostępu i bezpieczeństwa.


    Ziarna obiekt w wirtualnych 1

    Ziarna obiektów wirtualnych (1)

    • Dotychczas definicja perspektywy była określona przez jedno zapytanie (SQL).

    • W takim przypadku występują jednak trudności z odtworzeniem informacji semantycznej niezbędnej do aktualizacji obiektów wirtualnych.

      • Np. perspektywa zwraca nazwisko kierownika działu jako string oraz lokację tego działu również jako string. Jeżeli za pomocą tej perspektywy chcielibyśmy zmienić lokację działu, to potrzebna jest referencja do tego działu.

      • Odzyskanie tej referencji jest utrudnieniem dla programisty.

    • Definicja perspektywy powinna więc w takim przypadku składać się z dwóch lub więcej zapytań.

      • Pierwsze z nich zwracałoby referencje do działów,

      • Drugie na podstawie tych referencji zwracałoby nazwiska kierowników działów jako stringi,

      • Trzecie na podstawie tych referencji zwracałoby lokalizacje działów jako stringi.


    Ziarna obiekt w wirtualnych 2

    Ziarna obiektów wirtualnych (2)

    • Elementy zwracane przez pierwsze zapytanie będziemy nazywać „ziarnami”, z których „wyrastają” obiekty wirtualne.

    • Ziarna są następnie używane przez dalsze składowe definicji perspektywy.

    • Ziarna mogą być proste (pojedyncze wartości lub referencje) lub dowolnie złożone.

    • Na ogół ziarno będzie binderem, ale nie jest to wymagane.

    • Istotne jest natomiast, aby funkcja nested działająca na ziarnie zwróciła niepustą wartość.

    • Przyjęliśmy, że ziarna są wyznaczane przez procedurę funkcyjną o dowolnej złożoności. W stosunku do SQL jest to istotna generalizacja.

    ziarna

    obiekty wirtualne


    Przyk adowe definicje ziaren

    Przykładowe definicje ziaren

    PracwhereZar > 10000

    distinct( Prac.Stan ) ass

    bag(„analityk”, „programista”, „inżynier”) asz

    Pracasp

    Ziarna wyznaczają wirtualne obiekty dobrze zarabiających pracowników.

    Ziarna (nazwane s) wyznaczają wirtualne obiekty dla stanowisk

    Trzy ziarna (nazwane z) wyznaczają trzy wirtualne obiekty dla wymienionych stanowisk.

    Ziaren jest tyle, ile pracowników; każde z nich jest referencją do obiektu Prac, nazwaną p


    Definicja perspektywy tekstowa i w wersji obiektu bazy danych

    Definicja perspektywy: tekstowa i w wersji obiektu bazy danych

    • Przyjmujemy, że perspektywa po kompilacji jest obiektem bazy danych.

    • Obiekt ten ma budowę hierarchiczną.

    BogatyPracDef

    create viewBogatyPracDef {

    virtual objectsBogatyPrac {

    return

    (PracwhereZar > 10000) asp

    }

    on_delete { ... }

    ...

    create viewZarobekDef {

    virtual objectsZarobek {

    returnp.Zar as z}

    on_update( nowyZar ) do {...}

    ...

    }

    .... //dalsze elementy definicji

    }

    BogatyPrac

    .........

    on_delete

    Kompilacja

    ZarobekDef

    .....

    Zarobek

    on_update

    Hierarchię tę można odpytywać i aktualizować przy pomocy SBQL.


    Identyfikatory wirtualne 1

    Identyfikatory wirtualne (1)

    • Podstawowym problemem, który został rozwiązany w prezentowanej metodzie, jest wynalezienie sposobu przekazania informacji o aktualizacji obiektu wirtualnego do odpowiedniej procedury.

    • Po wykonaniu funkcji definiującej obiekty wirtualne zostają zwrócone wyniki zapytania, ale zgubiona jest informacja, że wyniki pochodzą z perspektywy, a nie ze zwyczajnego zapytania.

    • Powstaje problem, w jaki sposób w np. zleceniu:

      for eachBogatyPracwhereZarobek < 20000 doZarobek := Zarobek +1000

      system ma się dowiedzieć, że aktualizacja dotyczy wirtualnego obiektu i w związku z tym, wywołać odpowiednią procedurę przeciążającą będącą składnikiem definicji perspektywy? Której perspektywy? W jaki sposób ma przekazać parametry tej aktualizacji do wnętrza tej procedury?

    • Problem ten jest rozwiązany przez identyfikator wirtualny.

      • Jest on odpowiednikiem lub substytutem identyfikatora obiektu zapamiętanego.


    Identyfikatory wirtualne 2

    Identyfikatory wirtualne (2)

    • W zapytaniach odwołujemy się do perspektywy poprzez nazwę obiektów wirtualnych.

      • np. BogatyPrac where Nazw = "Kowalski"

    • Dla celów zarządczych można użyć nazwy zarządczej.

      • Uprawnienia mogą być zróżnicowane, np. programista może używać wyłącznie nazwy obiektów wirtualnych, natomiast administrator - wyłącznie nazwy zarządczej.

    • Wywołanie perspektywy powoduje wykonanie procedury definiującej ziarna.

    • Wynikiem wywołania nie są same ziarna, lecz identyfikatory wirtualne.

    • Identyfikator wirtualny jest trójką:

      <flagaJestemWirtualny,NazwaZarządcza, Ziarno>

      lub równoważnie:

      < flagaJestemWirtualny,ReferencjaDoPerspektywy, Ziarno>


    Rola identyfikator w wirtualnych

    Rola identyfikatorów wirtualnych

    • Są odpowiednikiem identyfikatorów zapamiętanych obiektów.

    • Na podstawie flagi wiadomo, że jest to identyfikator wirtualny, z którym interpreter SBQL musi postępować inaczej niż ze zwykłym identyfikatorem.

    • Na podstawie nazwy zarządczej (lub referencji do perspektywy) wiadomo o którą perspektywę chodzi.

    • Poprzez ziarno wyznaczają obiekt wirtualny w sposób jednoznaczny.

    • 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

      • operatory podstawienia (update), usunięcia (delete) i wstawiania (insert) działające na takim identyfikatorze interpretowanym jako l-value

    • Typowe operacje na identyfikatorze wirtualnym pozostają nie zmienione (np. zakomunikowanie go jako parametru, zwrócenie jako wyniku procedury funkcyjnej, uczestniczenie w operatorach algebraicznych)


    Przep yw sterowania pomi dzy elementami mechanizmu aktualizacji perspektyw

    Przepływ sterowania pomiędzy elementami mechanizmu aktualizacji perspektyw

    Program

    użytkownika

    Definicja

    perspektywy

    Zapytanie wywołujące perspektywę

    Identyfikatory wirtualne

    Procedura wewnątrz definicji perspektywy przeciążająca danego konsumenta

    Konsument wyniku zapytania (np. operator podstawienia)

    Interpreter zapytań

    oraz zleceń

    aktualizacyjnych

    Fragment interpretera implementujący danego konsumenta


    C d n

    C.D.N.

    • Operatory „konsumujące” identyfikatory wirtualne

    • Składnia definicji perspektywy i pod-perspektywy

    • Wirtualny identyfikator dla perspektyw

    • Co się dzieje na stosie ENVS w momencie wywołania perspektywy i w momencie aktualizacji obiektów wirtualnych?

    • Przykłady zastosowania aktualizowalnych perspektyw.

      • Przykłady te ilustrują moc mechanizmu, o której nie śniło się nawet tysiącom wybitnych specjalistów, którzy przez ostatnie 30 lat pracowali nad tym tematem.


  • Login