Welcome Guest Search | Active Topics | Members | Log In

Modelowanie związków klucz główny - klucz obcy przy pomocy wirtualnych pointerów Options · View
radamus
Posted: Wednesday, May 18, 2005 7:04:49 AM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Postanowiłem po raz pierwszy utworzyć nowy wątek.
Podsumuje tu naszą dyskusję przy tablicy i podam trochę pomysłów będących integracją dyskusji na forum w przeróznych wątkach. Przepraszam, że tak długo to trwało.

Najpierw przykład:
Model a'la relacyjny


I zdefiniowany przez perspektywy model obiektowy


Problem, na który napotkaliśmy polega na tym, że jakkolwiek nawigacja po pointerach nie sprawia na już problemu, tak zacieliśmy się przy problemie aktualizacji. Model obiektowy nie zawiera informacji o kluczach głównych bez których aktualizacja jest niemożliwa. A chcielibyśmy:
Zmieniać miejsce pracy Kowalskiemu
Code:
(Emp where name = "Kowalski").worksIn = ref(Comp where name = "IBM");

Albo tak:
Code:
(Comp where name = "IBM") <: create ref(Emp where name = "Kowalski") as employs;


Dodawać poprzednie miejsce pracy Kowalskiemu
Code:
(Emp where name = "Kowalski") <: create ref(Comp where name = "IBM") as PrevJob;




Wyszło, że w pewnych przypadkach należy dać dostęp do seed'a. Tylko jak? Czy dla wszystkich?

Otóż wydaje mi się, że da się jednak problem rozwiązać przez parametryzację perspektyw. Trochę czasu zajeło mi doprecyzowanie w jaki sposób, ale w końcu, dzisiaj rano, chyba uchwyciłem...

Ale po kolei - definicje perspektyw (tylko interesujące fragmenty - pomijam lastName):

Code:
create view EmpDef {
  virtual_objects Emp {return Prac.id_prac as p; }
  virtual_objects Emp(id) {return Prac where id_prac == id).id_prac as p; }

create view id_pracDef {
  virtual_objects id_prac(showId) { mamy tylko parametryzowany sack
           if(showId)
             return p.id_prac as id;
    }
    on_retrieve { return deref(id); }
         
  }


  create view worksInDef {
    virtual_objects worksIn { return (Prac where id_prac = p).id_firmy as f; }
   on_navigate { return Company(f); } //sparametryzowana perspektywa jednak wydaje mi się lepsza od mijego wcześniejszego pomysłu z operatorem "rzutowania". Musiałem do tego dojrzeć  (czyli zaimplementować parametryzację) :)

  //on_update potrzebuje id_firma inaczej nic nie zrobi. więc wołamy 'ukrytą' perspektywę.
    on_update(someCompany) { (Prac where id_prac = p).id_firmy := someCompany.id_firma(true); }
  }
  create view prevJobDef {
    virtual_objects prevJob {return (PrevJob where id_prac = p).id_firmy as f; }
    on_navigate { return Company(f); } //wołamy sparametryzowaną perspektywę
   
   //tutaj też potrzebujemy id_firmy, którego w ibezpośrednio nterfejsie obiektu wirtualnego nie ma (on_insert jest on_new - macie racje!! Jeżeli będzie działać tak jak profesor opisal w swoim poście to będzie wszystko ok.)
    on_insert(newPrevJob) { create permanent (p as id_prac, newPrevJob.Company.id_firma(true) as id_firmy) as PrevJob; }
  }
}


Teraz definicja Comp (pomijam definicje name)

Code:
create view CompDef {
  virtual_objects Comp {return Firma.id_firmy as f; }
  virtual_objects Comp(id) {return (iFirma where id_firmy == d).id_firmy as f; } 
   
  create view id_firmyDef{
   virtual_objects id_firmy(showId) { mamy tylko parametryzowany sack
           if(showId)
             return f.id_firmy as id;
    }
    on_retrieve { return deref(id); }
  }


  create view employsDef { //na razie bez update
    virtual_objects employs { return (Prac where id_firmy == f).id_prac as e; }
   on_navigate { return Emp(e); } //sparametryzowana perspektywa
   on_insert(refNewEmp) {refNewEmp.Emp.worksIn == Company(f);} //aktualizacja jest po stronie pracownika
  }

  create view bossDef {
     virtual_objects boss { return (Prac where id_firmy == (Firma where id_firmy == seed.f).id_szef).id_prac as b; }
     on_navigate {return Emp(b);}

   //przy aktualizacji musimy mieć perspektywę z id_prac,
    on_update(newBoss) { (Firma where id_firmy == seed.f).id_szef = newBoss.id_prac(true); }
  } 
}


I mamy to czego potrzebowaliśmy. Z jednej strony programista piszący perspektywę zakłada, że interfejs musi być uzupełniony o pewne elementy konieczne dla innych programistów definiujących inne perspektywy. Ale nie daje dostepu do seed'a bo to byłoby karkołomne, struktura seed'a może być dowolnie złożona i tylko programista danej perspektywy wie co tam jest.
Zamiast więc dawać dostęp do seed'a daje sparametryzowane procedury virtual objects. A właściwie w pewnych przypadkach tylko sparametryzowane (patrz id_prac i id_firma). Programista piszący wirtualne pointery musi oczywiście wiedzieć o istnieniu takich 'ukrytych' perspektyw (pozostaje oczywiście do rozważenia kwestia jak je naprawdę ukryć dla końcowego użytkownika).

Ergo:
1. uważam, że do ziarna dostępu z zewnątrz być nie powinno.
2. proponuje wykorzystanie mechanizmu parametryzacji perspektyw.
habela
Posted: Wednesday, May 18, 2005 4:46:34 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
radamus wrote:
Problem, na który napotkaliśmy polega na tym, że jakkolwiek nawigacja po pointerach nie sprawia na już problemu, tak zacieliśmy się przy problemie aktualizacji.

Gwoli ścisłości - parametryzacja niezbędna staje się chyba już dla samego nawigowania? (wszak w definicji wskaźnika użyłeś: on_navigate { return Company(f); } )

radamus wrote:
I mamy to czego potrzebowaliśmy. Z jednej strony programista piszący perspektywę zakłada, że interfejs musi być uzupełniony o pewne elementy konieczne dla innych programistów definiujących inne perspektywy. Ale nie daje dostepu do seed'a bo to byłoby karkołomne, struktura seed'a może być dowolnie złożona i tylko programista danej perspektywy wie co tam jest. Zamiast więc dawać dostęp do seed'a daje sparametryzowane procedury virtual objects.


Generalnie - chyba na całej linii się zgadzamy. Z jednym zastrzeżeniem, że jeszcze sprawa on_new (konkretnie - stosunku jej parametru do sprawy hermetyzacji i wynikłych z tego utrudnień) nie jest dla mnie w pełni wyjaśniona.

radamus wrote:
A właściwie w pewnych przypadkach tylko sparametryzowane (patrz id_prac i id_firma).

Tej sytuacji "tylko sparametryzowane" na razie pewien nie jestem.
Jak pokazałeś, problem wypływa z powyżej wspomnianej sprawy on_new.
Pamiętam, że starałem się uniknąć sytuacji, gdzie np. obiekt Zatrudnienie nie był widoczny w bazie a osiągalny tylko przez asocjacje z Pracownik i Firma. I to w artkule o rolach doprowadziło mnie do założenia, że bazowa bezparamatrowa definicja będzie zawsze obecna.
Ale nie ma nic rozstrzygającego.

radamus wrote:
Programista piszący wirtualne pointery musi oczywiście wiedzieć o istnieniu takich 'ukrytych' perspektyw (pozostaje oczywiście do rozważenia kwestia jak je naprawdę ukryć dla końcowego użytkownika).

Co do ukrywania, to z tego względu wydało mi się, że potrzebne jest ich odróżnienie słowem kluczowym (stąd te słówka "referrer" w przykładach).
Ale tak jak zrobiłeś (deklaracja identyczna z głównym "virtual objects") jest ładniej, bo sama obecność parametru (niedozwolonego w normalnych obiektach) jest wyróżnikiem.

subieta
Posted: Wednesday, May 18, 2005 8:40:01 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
radamus wrote:

Ergo:
1. uważam, że do ziarna dostępu z zewnątrz być nie powinno.


Hmmmm..... to zdanie mnie zaniepokoilo, bo nie rozumiem w ogole, ze moglaby byc taka alternatywa. Co to znaczy "z zewnatrz"? Ziarno (ziarna) pojawiaja sie na chwile i potem sa konsumowane. I ich na zewnatrz w ogole nie ma. Chyba, ze wirtualny identyfikator zostal zakomunikowany jako parameter lub gdzies zapamietany. W pierwszym przypadku dostep do seeda moglby sie przydac dla piszacego procedure, wiec nie przesadzalbym, ze do niego nie moze byc dostepu. Drugi przypadek jest dla mnie na razie trudny do strawienia.
radamus
Posted: Thursday, May 19, 2005 10:15:05 AM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Być może jest to czysto akademickie rozważanie...

Już wyjaśniam o co mi chodziło.
Powiedzmy mamy perspektywę:

Code:
view WybitnyAktorFilmyDef
{
  virtual objects WybitnyAktor {return (Aktor where count(grałW) > 50).(nazwisko as n, grałW.Film.tytuł group as t) as af; }
    view nazwiskoDef{
        virtual objects nazwisko {...} //tylko retrieve
    }
                   view filmDef{
        virtual objects film {...} //tylko retrieve
    }


}


W momencie kiedy operator niealgebraiczny przetwarza wirtualny identyfikator na stos wrzucane jest m.in. nested(seed). Jest to potrzebne, bo dzięki temu komunikujemy ziarna do procedur virtual objects podpespektyw. W powyższym przykładzie będzie to binder af. Jednak potencjalnie użytkownik tej perspektywy może napisać:

Code:
(WybitnyAktorFilmy where nazwisko == "Wayne").af.n = "Brzęczyszczykiewicz";


A nie powinien tego zrobić przecież.
Czyli ziarno nie powinno być w normalny sposób zewnętrznie wiązalne na stosie, tylko w procedurach virtual objects podperspektyw.

radamus
Posted: Thursday, May 19, 2005 11:11:40 AM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Czyli gdy operator niealgebraiczny przetwarza wirtualny identyfikator na stosie pojawia się:

Code:
sekcja z binderami do procedur virtual objects z podperspektyw
----------------------------------------------------------------------------------------------------
sekcja z nested(seed)
----------------------------------------------------------------------------------------------------
poprzedni stan stosu


Sekcja nested(seed) powinna być niewidoczna dla wiązania, jeżeli nie jest wykonywana procedura virtual_objects z podperspektywy.
Tak to rozumiem.
radamus
Posted: Thursday, May 19, 2005 5:13:40 PM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
I jeszcze jedno pytanie, moje i Piotrka.
Jeżeli mamy perspektywy z parametrami to trzeba jakoś rozgraniczyć kto może wywołać procedurę virtual objects z parametrami a kto nie. Zakładamy, że końcowy użytkownik ma przezroczystość i dla niego perspektywa serwuje obiekty, (więc nie ma parametrów). Ale w pewnych przypadkach, np. gdy definiujemy inne perspektywy istnieje potrzeba wołania perspektyw z parametrami (patrz pierwszy post w temacie).
Pytanie:
Jak okreslić kto jest uprzywilejowany do parametryzowanego wołania perspektywy?
subieta
Posted: Friday, May 20, 2005 7:19:19 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
radamus wrote:

Jak okreslić kto jest uprzywilejowany do parametryzowanego wołania perspektywy?

Moim zdaniem, sprawa jest uboczna i zwiazana generalnie z przywilejami nadawanymi uzytkownikom i sposobami przekazywania tych przywilejow. Koncepcja perspektyw z parametrami niejawnie zaklada, że sa uzytkownicy, ktorzy moga je tworzyc i uzywac w definiowanych przez nich perspektywach, zas inni uzytkownicy maja to zabronione, moga tylko uzywac perspektyw bez parametrow (ktore ewentualnie wywoluja te z parametrami).
subieta
Posted: Friday, May 20, 2005 7:33:46 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
radamus wrote:
Być może jest to czysto akademickie rozważanie...

Już wyjaśniam o co mi chodziło.
Powiedzmy mamy perspektywę:

Code:
view WybitnyAktorFilmyDef
{
  virtual objects WybitnyAktor {return (Aktor where count(grałW) > 50).(nazwisko as n, grałW.Film.tytuł group as t) as af; }
    view nazwiskoDef{
        virtual objects nazwisko {...} //tylko retrieve
    }
                   view filmDef{
        virtual objects film {...} //tylko retrieve
    }


}


W momencie kiedy operator niealgebraiczny przetwarza wirtualny identyfikator na stos wrzucane jest m.in. nested(seed). Jest to potrzebne, bo dzięki temu komunikujemy ziarna do procedur virtual objects podpespektyw. W powyższym przykładzie będzie to binder af. Jednak potencjalnie użytkownik tej perspektywy może napisać:

Code:
(WybitnyAktorFilmy where nazwisko == "Wayne").af.n = "Brzęczyszczykiewicz";


A nie powinien tego zrobić przecież.
Czyli ziarno nie powinno być w normalny sposób zewnętrznie wiązalne na stosie, tylko w procedurach virtual objects podperspektyw.


Można zabronić wiązania w innych sytuacjach. Mozna sobie wyobrazic jak to zrobic (obok ziarna na stosie trzeba trzymac flage z nazwa zarzadcza perspektywy). To wprowadziloby pelna hermetyzacje pomocniczych nazw uzytych przez definiujacego ziarna. Hermetyzacja jest oczywiscie bardzo wazna.
stencel
Posted: Tuesday, May 24, 2005 1:33:01 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
subieta wrote:
Można zabronić wiązania w innych sytuacjach. Mozna sobie wyobrazic jak to zrobic (obok ziarna na stosie trzeba trzymac flage z nazwa zarzadcza perspektywy). To wprowadziloby pelna hermetyzacje pomocniczych nazw uzytych przez definiujacego ziarna. Hermetyzacja jest oczywiscie bardzo wazna.


Uwazam, ze sekcja z ziarnem nalezy do lokalnego srodowiska wywolania procedur przeciazajacych (on_*) i jako taka nie jest widoczna w innych miejscach. Dokladnie tak jak w ksiazce na stronach 177 i 178 na rysunkach 33 i 34: lokalne srodowisko procedury p1 i (ewentualnie) modulu m1 nie jest dostepne poza trescia procedury p1 i modulu m1.
stencel
Posted: Tuesday, May 24, 2005 1:46:20 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Mam troche watpliwosci co do kodu przedstawionego w pierwszym liscie Radka.

Code:
virtual_objects Emp(id) {return Prac where id_prac == id).id_prac as p; }


Tu oczywiscie brakuje nawiasu otwierajacego przed Prac, ale zastanawia mnie, czy uzycie tu == zamiast =, ma jakies znaczenie? Bo pozniej uzywamy juz rownosci pojedynczej.

Code:
virtual_objects id_prac(showId) {
  if(showId)
    return p.id_prac as id;
}


Tego nie rozumiem. Po co ten argument, skoro zawsze wolamy te perspektywe z wartoscia parametru true? Moim zdaniem nie ma to sensu.

Co wiecej, ta procedura ma wade pod nazwa control reaches end of a non-void function. Trzeba by conajmniej tak to poprawic:

Code:
virtual_objects id_prac(showId) {
  if(showId)
    return p.id_prac as id;
  else
    return bag();
}

subieta
Posted: Tuesday, May 24, 2005 10:09:29 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
subieta wrote:
Można zabronić wiązania w innych sytuacjach. Mozna sobie wyobrazic jak to zrobic (obok ziarna na stosie trzeba trzymac flage z nazwa zarzadcza perspektywy). To wprowadziloby pelna hermetyzacje pomocniczych nazw uzytych przez definiujacego ziarna. Hermetyzacja jest oczywiscie bardzo wazna.


Uwazam, ze sekcja z ziarnem nalezy do lokalnego srodowiska wywolania procedur przeciazajacych (on_*) i jako taka nie jest widoczna w innych miejscach. Dokladnie tak jak w ksiazce na stronach 177 i 178 na rysunkach 33 i 34: lokalne srodowisko procedury p1 i (ewentualnie) modulu m1 nie jest dostepne poza trescia procedury p1 i modulu m1.


To jest bardzo dobre zalozenie, ale dotyczy nieco innego przypadku. Pytanie dotyczylo sytuacji, kiedy nie jest wolana na wirtualnym identyfikatorze funkcja on_*, ale kiedy stosowany jest do niego operator niealgebraiczny. Niestety, wydaje sie, ze nie mozna wtedy uniknac upublicznienia tego ziarna, bo przeciez te podperspektywy (tez wrzucane na stos) musza na czyms dzialac. Trzeba wiec jakos tak chytrze zrobic, aby to ziarno stalo sie widoczne dopiero z wnetrza podperspektyw, a normalnie nie jest widoczne, np. dla operatora kropki. Wydaje sie, ze jest to do zrobienia, ale konkretny sposob nalezaloby przecwiczyc w implementacji.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.157 seconds.