Konstrukcja systemów obiektowych i rozproszonych (KOR)

Aktualizowalne perspektywy (2): Perspektywa jako obiekt bazy danych"; Operatory "konsumujące" identyfikatory wirtualne; Tworzenie obiektów wirtualnych; Podperspektywy; Optymalizacja; Porównanie z trygerami "instead of"
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
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: pokaż animację
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
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.
Przetwarzanie identyfikatora wirtualnego dla podperspektywy przez operator niealgebraiczny
Wywołanie procedury aktualizującej podperspektywę
Przykłady perspektyw - schemat bazy danych (M0)
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
Przykład 1: zastosowania perspektywy
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
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":
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
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 atrybutAdnotacja 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: kod
Przykład 4: użycie perspektywy
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.

Aktualizowalne perspektywy (2)