Welcome Guest Search | Active Topics | Members | Log In

Trigery Options · View
piotr.skwarski
Posted: Thursday, December 16, 2004 7:21:27 PM
Rank: Newbie

Joined: 12/16/2004
Posts: 1
Points: 0
stencel
Posted: Monday, December 20, 2004 4:34:20 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
W ogole ani slowa?

Szczerze mowiac w wypadku postu otwierajacego oczekiwalbym bardziej wyczerpujacego raportu.

1. Co juz jest zrobione?
2. Co jeszcze ma byc dorobione?
3. Skad moge sciagnac aktualna wersje do testowania?

Wazne jest, zeby na poczatku raport byl bardziej szczegolowy. Pozniejsze aktualizacje moga byc krotsze i odnosic sie do listy z punktow 1, 2 inicjalnego postu.

Wazne jest tez zeby dostepne byly kolejne testowalne wersje. To naprawde jest dla dobra magistranta, bo pobudza jego inicjatywe, a promotorowi i obserwatorom daje oręż do kontroli postepow i motywowania. Warto poddac sie temu mechanizmowi, zeby nie powtarzac roku, bo to slono kosztuje.
subieta
Posted: Tuesday, April 22, 2008 1:37:25 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Wracam do tematu trygerów (trigerów?)

Semantycznie, trygery nie powinny niczym roznic sie od procedur, z tym, ze raczej nie powinny byc to procedury funkcyjne (poniewaz wynik trygera nie moze byc skonsumowany, ale moze znajdze sie jakies zastosowanie dla takich procedur?). Trygery znane z SQL tez sa w istocie procedurami. Gdyby bylo inaczej (czyli gdyby wywolanie trygera odbywalo sie na zasadzie goto), to powstawaloby pytanie dokad ma wrocic sterowanie po zakonczeniu dzialania trygera. Dzieki temu, ze jest to procedura wiadomo, ze sterowanie powinno wrocic tam, gdzie powstala przyczyna wywolania trygera. Wewnatrz ciala procedury/tyggera moga zachodzi rozne rzeczy, np. moze byc rzucony wyjatek, ktory programista ma obowiazek sprawdzic, moze byc wykonane zerwanie transakcji, itp. Tym co dzieje sie wewnatrz procedury nie bedziemy sie zajmowac, przyjmujac, ze wszystko to, co jest dostepne dla normalnej procedury powinno byc takze dostepne dla tryggera.

Miejscem przechowywania trygerow jest sklad danych, zwykle przyjmujemy , ze jest to trwala czesc tego skladu, ale niekoniecznie. Ulokowanie trygera powinno byc podobne do ulokowania zapamietanej procedury. Procedury te maja nazwy wybrane przez uzytkownika, ale sa oflagowane tak, aby nie mozna bylo ich uzyc jak normalnej procedury. Syntaktycznie, trygery sa oznaczone tak, aby nie mozna bylo ich pomylic z procedura. Trygery moze wstawiac aplikacja (dowolna) lub tez moga one byc powolywane przez specjalny modul administracyjny.

Najbardziej istotne jest to, kiedy i jak takie procedury sie wywoluje. Jest tu analogia z wyjatkami (ktora byc moze warto wykorzystac dla unifikacji), ale tez zachodza pewne roznice. Glownym powodem istnienia trygerow jest wywolywanie ich w sytuacji, kiedy chcemy przejac kontrole nad jakas generyczna operacja w bazie danych, w szczegolnosci, nad operacja aktualizacji, usuwania, wstawiania, tworzenia, czytania, nawigowania, odpalenia procedury, itp. Rodzaj operacji zalezy od tego, ktory takie trygery projektuje, nie ma tu reguly. W SQL zdecydowano, ze moga byc trzy takie operacje: update, delete oraz insert. W ktoryms z systemow (nie pamietam juz nazwy, chyba Netul) implementowalem trygery dla wiekszej liczby operacji.

Trzeba wiec dac mozliwosc wywolania okreslonego trygera w sytuacji zajscia okreslonej operacji. Odbywa sie to przy pomocy flag zawieszonych na okreslonych danych, ktore (dawno temu) nazywalem 'bitami uczulajacymi". Chodzi o to, aby uczulic system na okreslona operacje. W wyniku deklaracji tryggera jego kod wstawia sie do skladu danych, zas okreslone bity uczulajace ustawia sie na "zapalony" przy okreslonych danych. Wyrzucenie tryggera oznacza ustawienie odpowiedniego bitu uczulajacego na "zgaszony".

Bity uczulajace sa predefiniowane (wszyte), nie mozna ich zestawu zmieniac. Jak latwo sie domyslec, w SQL powinno byc 3 bity uczulajace: na update, na insert i na delete. To nalezy pomnozyc przez 2, gdyz uczulenie moze dotyczyc wywolania trygera przed operacja lub po operacji.

Kolejna kwestia jest granularnosc uczulenia. Oczywiscie, mozna sobie wyobrazic, ze granularnosc ta dotyczy wszystkich obiektow, wlaczajac atomowe. Jezeli tak zrobimy to bedzie dosc fajnie i zupelne inaczej niz w SQL. Niestety, z takim podejsciem wiaza sie dosc znaczne straty pamieci na bity uczulajace oraz znacznie wieksze utrudnienia przy administrowaniu. Wracajac do SQL tam uczulenie dotyczy calej tabeli lub kolumny tabeli. Biorac to jako analogie, my mozemy na poczatek uczulac klasy oraz dowolne elementy danej klasy.

Musi byc jeszcze rejestr trygerow, ktory wiaze uczulenia z nazwa konkretnego ciala procedury/tryggera. Dalej jest juz prosto: jezeli wykonywana jest pewna operacja, to zaglada sie do odpowiedniej klasy aby sprawdzic, czy bit uczulajacy dla tej operacji jest zapalony dla okreslonej danej podlegajacej tej operacji. Oczywiscie uczulenia moga dotyczyc przed i po operacji. Jezeli dany bit jest zapalony, to w tym momencie siega sie do rejestru trygerow, znajduje odpowiednia procedure i ja sie odpala.

Taka procedura moze wymagac parametrow, czyli id obiektu na ktorym zachodzi operacja oraz parametrow tej operacji (np. podstawianej wartosci). Parametry te komunikuje sie normalnie przez stos, kazda procedura/trygger ma okreslony zestaw parametrow. Np. dla aktualizacji wartosci parametry zawieraja wartosc przed i wartosc po. Komunikacja parametrow moze powodowac jakies problemy typologiczne. Na dzien dzisiejszy mozemy przyjac, ze liczba zdefiniowanych sygnatur trygerow (ale bez ich nazwy) jest taka, jak liczba operacji objetych trygerami, razy dwa (przed i po), razy liczbe kombinacji typow parametrow. Byc moze to takze mozna zrobic inaczej.

Nie wiem jak dzisiaj, ale w moich czasach SQL nie zezwalal na posadzenie na jednej kolumnie kilku (dowolnej liczby) trygerow, z ktorych kazdy bylby powolany z innego powodu i robilby co innego. My tez mozemy tak zrobic, ale bedzie to malo elegancko. Brdziej elegancko jest zrobic uczulenie wspolne dla dowolnej liczby tryggerow. Jezeli nastapi operacja, to wszystkie je wywoluje sie po kolei (byc moze lepiej byloby rownolegle, ale to prowadzi do dalszych problemow) Oznacza to, ze rejestr trygerow moze zawierac dowolna liczbe trygerow przypisanych do danego bitu uczulajacego. Bit uczulajacy ustawia sie na "zgaszony" dopiero wtedy, gdy nie ma w rejestrze zadnego trygera, ktory go obsluguje.

To tyle w telegraficznym skrocie (wygrzebane z mojej pamieci sprzed ho, ho) Zapraszam do dyskusji i uwag, szczegolnie w kontekscie systemu ODRA.
subieta
Posted: Tuesday, April 22, 2008 2:04:21 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Jeszcze tylko dodam, ze jest rowniez opcja, ze w ramach powolania jednego tryggera mozemy zapalic dowolna liczbe bitow uczulajacych. Daloby to mozliwosc np. mozliwosc reagowania na zmiane wartosci nie jednego, ale kilku atrybutow. To jednak wymaga przemyslenia ze wzgledu na komunikowanie parametrow i ich typowanie.

Jeszcze bardziej wyrafinowany system trygerow otrzymamy wtedy, gdy bedziemy mogli uczulac nie tylko zapamietane dane, ale rowniez dane wirtualne osiagane przez perspektywy. Nioe jestem jedna pewien, czy bedzie to jakosciowa nowosc, jezeli bylaby mozliwosc podlaczania perspektyw do klas - wtedy, celem uczulenia perspektywy, nalezaloby powolac odpowiednia klase. Zostawiam to do rozwazenia jako glos w dyskusji.
subieta
Posted: Wednesday, April 23, 2008 5:42:04 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Dosc podobne do trygerow ale o nieco innym zabarwieniu sa tzw. wiezy integralnosci lub reguly biznesowe. Wiezy integralnosci (integrity constraints) roznia sie tylko sposobem wywolania. O ile w przypadku trygerow o wywolaniu trygera decyduje fakt wykonywania pewnej operacji na uczulonym na te operacje obiekcie, o tyle w wiezach integralnosci wywolanie trygera nastepuje w wyniku spelnienia badz nie spelnienia pewnego warunku. Ten warunek moze miec postac dowolnego zapytania, w naszym przypadku SBQL. Np. zapytania ustalajacego, ze kazdy pracownik musi miec zarobek mniejszy od zarobku swojego szefa, albo ze suma wszystkich zarobkow nie moze przekraczac budzetu firmy przeznaczonego na zarobki. Wiezy integralnosci moga byc statyczne lub dynamiczne. Statyczne dzialaja na jednym stanie bazy danych, zas dynamiczne dzialaja na dwoch kolejnych stanach bazy danych. Przykladem wiezu dynamicznego jest "zarobek nie moze sie zmniejszyc". Wyrazenie tego w SBQL jest juz pewnym problemem wymagajacym od SBQL znacznej poprawki. Zarown statyczne jak i dynamiczne wiezy integralnosci moga odpwolywac sie do zegara lub do budzikow, co powoduje dalsze poprawki. Np. takim wiezem odwolujacym sie do zegara jest "po uplywie 5 lat pracownik musi dostac podwyzke".

Pomiedzy wiezami integralnosci i regulami biznesowymi jest rowniez roznica, ale raczej intencyjna niz techniczna. W regulach biznesowych chodzi o to, aby nastapily pewne efekty uboczne zwiazane ze spelnieniem lub niespelnieniem warunku. Np. spelnienie warunku powoduje wyslanie maila, a spelnienie innego warunku oznacza okreslona zmiane w bazie danych. Np. "jezeli w ciagu 3 dni od nadeslania faktury nie zostala ona rozliczona, wyslij zawiadomienie do glownego ksiegowego". Na terenie systemu ODRA nie bedziemy jednak rozrozniac wiezow integralnosci od regul biznesowych (bo rozroznienie jest zbyt chybotliwe), zas rozroznienie pomiedzy trygerem a wiezem polega tylko na odmiennym mechanizmie wywolania.

Osoby, ktore chca cos z tego realizowac, prosze o odzew.
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.085 seconds.