Przykłady zastosowań

Jeśli administrator systemu musi od czasu do czasu wykonywać prace wymagające przejęcia bazy danych na wyłączność, wówczas występują dwa problemy. Pierwszy z nich to poinformowanie wszystkich użytkowników systemu o takim zamiarze, drugi to techniczna strona przejścia w tryb jednoużytkownikowy. Jeśli jednak założymy, że wystarczy programowo "odciąć" dostęp do bazy danych, co oznacza, że żadna aplikacja AM nie będzie mogła w tym czasie nawiązać kontaktu z bazą danych, wówczas problem wydaje się rozwiązany. Warto zauważyć, co jest oczywiście minusem tego rozwiązania, że tylko programy badające stan dostępności bazy danych na tym poziomie wykryją, że nie mają uprawnień do korzystania z niej. Inne niezależne programy, np. narzędziowe, nie będą oczywiście w żaden sposób sprawdzać ustawionych przez nas flag dostępności. Niemniej w warunkach klasycznego przetwarzania w niezbyt rozbudowanym środowisku wielodostępnym nie powinno być problemów wynikających z nakładania się kompetencji administracyjnych.

Aby programowo przejść w tryb jednoużytkownikowy, wystarczy wprowadzić jedno pole bitowe we wspólnej tabeli TFB (TFB - Tabela Flagowa Bazy), które informuje, czy baza jest dostępna. Wartość tego pola może być ustawiana przez akcję wyzwalaną przyciskiem na pulpicie administracyjnym. Jeśli więc administrator zechce zablokować dostęp do bazy, wówczas naciskając przycisk blokady:

1. ustawi wskaźnik blokady w tabeli TFB;
2. roześle do wszystkich aktywnych stacji monit, informujący, że należy zakończyć pracę z programem.

Monit do użytkowników komputerów można programowo wygenerować do wszystkich stacji odnotowanych aktualnie w tabeli TM, wykorzystując stosowną funkcję systemową (np. net send środowiska Windows), korzystając z powłoki poleceń systemu, zazwyczaj dostępnej w większości środowisk programowania. Oczywiście rozesłanie monitu ani też ustawienie wskaźnika blokady bazy danych nie gwarantują, że baza natychmiast będzie dostępna na wyłączność. Aby było to możliwe, praca wszystkich aplikacje typu AM musi być zakończona przez użytkowników. Dopóki w tabeli TM będą istniały jakiekolwiek wpisy poza RMK stacji administrującej, dopóty z punktu widzenia aplikacji AM baza nie pracuje w trybie wyłączności. Jednak każda aplikacja AM na starcie sprawdza stan tabeli TFB i jeśli znajduje tam ustawiony wskaźnik zajętości, nie pozwala na samouruchomienie, sygnalizując to użytkownikowi.

Procedury sprawdzające i monitorujące stan wyłączności mogą być implementowane na różne sposoby. Na przykład zamiast rozsyłać monity o konieczności zakończenia pracy, można tak skonstruować aplikację AM, że będzie sama okresowo kontrolować tabelę TFB i automatycznie kończyć pracę, gdy sytuacja tego wymaga. Wybór rozwiązania zależy od tego, jakie nakłady na tworzone oprogramowanie możemy ponieść i jakie są wymagania ze strony użytkowników systemu. Niemniej najprostsze i najmniej konfliktowe wydaje się programowe poinformowanie użytkowników.

Inną cenną zaletą korzystania z samokontroli aplikacji typu AM jest możliwość blokowania dostępu do poszczególnych zasobów. Wyobraźmy sobie, że nie chcemy, aby dwóch (lub więcej) użytkowników jednocześnie edytowało te same zasoby informacyjne. O ile poleganie na blokadach jednoczesnego dostępu oferowanego w standardowych bazach danych działa poprawnie na poziomie logiki bazy (blokady tabel, stron, rekordów itd.), o tyle mechanizmy te nie czytają logiki obiektów reprezentowanych w naszym oprogramowaniu. Nie zawsze też jesteśmy w stanie cały cykl aktualizacyjny zawrzeć w jednej transakcji, co w sposób naturalny mogłoby izolować go od innych procesów. Dlatego też pożądanym podejściem jest programowa kontrola zdarzeń związanych z blokowaniem zasobów. Idealnie do tego celu nadaje się tabela TM, gdzie aplikacja AM na każdej stacji roboczej może w swoim rekordzie RMK wykonać wpis identyfikatora obiektu, który aktualnie podlega edycji z tej stacji (opieramy się na założeniu, że z jednego komputera w danym momencie nie można aktualizować jednocześnie więcej niż jednego zasobu). Z kolei aplikacja AM przed przejściem do trybu edycji zawsze sprawdza, czy w tabeli TM nie istnieje już wpis informujący, że obiekt o tym identyfikatorze jest aktualnie poprawiany przez innego użytkownika. Po zakończeniu trybu edycji wpis dotyczący identyfikatora obiektu w rekordzie RMK jest zerowany przez stację macierzystą (rekord MRK oczywiście pozostaje). W przypadku nie kontrolowanego wyłączenia komputera może zdarzyć się, że pozostanie w tabeli TM rekord RMK z odnotowanym identyfikatorem obiektu podlegającym edycji, uniemożliwiając innym użytkownikom wykonywanie poprawek na tym obiekcie. Procedura usuwania takich zakleszczeń podlega ogólnej zasadzie postępowania z rekordami "osieroconymi". Oczywiście, nic nie stoi na przeszkodzie projektowania własnego bardziej zaawansowanego rozwiązania pozwalającego na "ręczne" administrowanie zasobami tabeli TM, np. z poziomu konsoli administracyjnej.

Kontrolowanie blokad funkcjonalnych z poziomu programu użytkowego ma jedną niepodważalną zaletę, a mianowicie programista może panować nad ich strukturą. Jeśli np. mamy bazę danych klientów oraz ich zamówień i zakupów, gdzie każdy klient ma swój identyfikator, a zamówienia i zakupy są osobnymi tabelami powiązanymi z tabelą klientów poprzez identyfikator klienta, wówczas odpowiednio organizując aplikację, można wykonywać blokady na wielu poziomach:

• zaczynając od korzenia, czyli od klienta, wówczas nie jest możliwa równoczesna edycja jego danych osobowych oraz danych zawartych w tabelach hierarchicznie podległych, jakimi są zamówienia i zakupy

• blokując jedynie grupę rekordów podległych, np. tylko zamówienia tego klienta.

W tab. 1 przedstawiono zarys tabeli TM, gdzie blokowanie odbywa się tylko na szczycie hierarchii, co powoduje, że obiekt jest dla wszystkich pozostałych użytkowników niedostępny do edycji od najwyższego do najniższego poziomu. Natomiast w tab. 2 pokazano sposób fragmentacji blokad do poziomu konkretnych tabel, co oznacza np. że dane klienta o identyfikatorze 4567 z wyjątkiem jego zamówień mogą być poprawiane przez innych użytkowników.

Stosowanie różnorodnego podejścia do programowej kontroli blokad wynika głównie z architektury systemu i powiązań logicznych w bazie danych.

Można i bez tego

Bezwzględną zaletą monitorowania poczynań użytkowników aplikacji poprzez wspólną tabelę jest to, że rozwiązanie nie ogranicza wykorzystania konkretnych implementacji baz danych oraz środowiska systemowego, dając programistom możliwość kontrolowania, czego sobie życzą. Należy też zwracać uwagę, aby nie przeciążać systemu monitorowaniem mało istotnych działań użytkowników. Jeśli jednak ktoś się uprze, może za pomocą kroniki kontrolować manualną wydajność pracy poszczególnych użytkowników, gdy metody pomiaru efektywności polegają jedynie na zliczaniu częstotliwości wykonywania pewnych procedur.

Starając się odpowiedzieć na pytanie, czy warto stosować tego rodzaju mechanizmy samokontroli aplikacji, zapewne stwierdzimy, że bez nich można się obejść. Oczywiście, wiele programów nie zawiera tego typu elementów centralizujących "władzę" administracyjną i użytkownicy jakoś sobie z tym radzą, bo muszą, a wiele kwestii można załatwić przez telefon. Niemniej, czyż nie łatwiej przy użyciu jednego przycisku rozesłać informację do wszystkich, a za pomocą drugiego sprawdzić, kto jeszcze pracuje i czy w ogóle coś robi, czy też może zasnął za biurkiem.