Ochrona integralności danych

1. dwie podstawowe formy zabezpieczenia w RBD:

1. mechanizm transakcji

2. więzy integralności

Co to są transakcje

Pojęcie transakcji może być kojarzone z pojęciem transakcji kupna-sprzedaży z normalnego życia.

Transakcje w SBD gwarantują, że działania skończą się powodzeniem lub niepowodzeniem w całości

Rodzaje transakcji

1. Transakcje jawne - konfigurowane przez użytkownika

2. Transakcje niejawne i automatyczne

Transakcje jawne

BEGIN TRANSACTION

Treść transakcji

Wykonanie zakończone powodzeniem

COMMIT TRANSACTION (potwierdzenie zakończenia transakcji)

Wykonanie zakończone niepowodzeniem

ROLLBACK TRANSACTION (wycofanie transakcji i cofnięcie bazy do stanu sprzed jej rozpoczęcia)

Begin transaction

Update cena = cena *1.1 -podniesienie cen wszystkich towarów o 10%

IF @error >0

Rollback transaction

Else

Commit transaction

Możliwe jest także etapowanie transakcji przy pomocy tzw. Savepoints

Po utworzeniu takich punktów można wtedy wycofać transakcję do ustalonego punktu

Begin transaction

Update towary set cena = cena *1.1 where cena <100 -podniesienie cen towarów tańszych niż 100 o 10%

SAVE transaction po_aktualizacji_1

Update towary set cena = cena *0.9 where cena >110 - obniżenie cen wszystkich towarów droższych niż 110 o 10%

IF @error >0

Rollback transaction po_aktualizacji_1

Else

Commit transaction

Transakcje niejawne i automatyczne tworzy SZBD w celu wykonania niektórych operacji np. operacji DELETE lub UPDATE. Przed rozpoczęciem wykonywania tych poleceń automatycznie otwierane są transakcje. W przypadku przerwania tych operacji BD powraca do stanu sprzed rozpoczęcia wykonywania polecenia.

UTRZYMANIE BAZY DANYCH

W odniesieniu do obiektów zmianie może ulegać m.in.:

• wartość atrybutu - jest to najczęściej spotykany w praktyce przypadek zmiany (modyfikacji) opisu obiektu. Zmianom ulegają wartości większości atrybutów obiektu - cena towaru, stanowisko zajmowane przez pracownika, jego płaca, adres itd. Stosunkowo rzadko spotyka się atrybuty których wartości nie ulegają zmianie lub ulegają zmianie tylko na skutek stwierdzenia błędu w poprzednim zapisie i mają charakter korekty. Należą do nich np. data urodzenia, miejsce urodzenia, płeć, cena zakupu towaru w konkretnej dostawie. Czasami można spotkać sytuacje wyjątkowe, kiedy atrybut, o którym zasadniczo przyjmuje się, że nie powinien ulegać zmianie przyjmuje inną wartość np. zmiana nazwy państwa (PRL - Rzeczpospolita Polska), miasta (Stalinogród - Katowice), ulicy itp. W takiej sytuacji, aby uniknąć komplikacji modelu zwykle nie modyfikuje się struktury bazy, a jedynie nadpisuje się stare wartości nowymi. Ponieważ sytuacje takie zwykle traktuje się jako wyjątkowe, dla zachowania ciągłości tworzone są odpowiednie procedury, w których zapamiętywany jest związek między starą wartością a nową.

• dziedzina atrybutu - zmianę dziedziny atrybutu można rozpatrywać w trzech aspektach:

• rozszerzenia,

• zawężenia,

• zastąpienia czyli całkowitej lub częściowej zmiany. Przykładem tego typu zmian może być zmiana stopni policyjnych w naszym kraju, powstanie nowych jednostek terytorialnych czy zmiana nazw województw. Zmiana ta wymaga często zmian reguł integralności SZBD, lecz nie wymaga zmiany struktury samej bazy.

• zbiór atrybutów obiektu - tę zmianę można skategoryzować podobnie jak zmianę dziedziny atrybutu. Z tym typem zmian mamy do czynienia najczęściej w przypadku zmian w opisie obiektu. Operacja ta wymaga w systemach relacyjnych BD zmiany szerokości tablicy (rozszerzenia o dodatkowe kolumny lub usunięcia zbędnych), a czasem także utworzenia nowych relacji i reguł integralności.

• skład obiektów złożonych, Operacja zmiany składu obiektu wymaga daleko idącej ingerencji w strukturę BD. W przypadku stopniowego przechodzenia z jednego opisu na drugi konieczne jest przechowywanie w osobnych tabelach obiektów starych i nowych. Sytuacja może być jeszcze bardziej skomplikowana, gdy obiekty mogą istnieć jednocześnie w obu postaciach.

• przynależność obiektu do klasy, powstanie nowych klas. Zmiana ta jest określana także jako przejście obiektu z klasy do klasy np. przejście osoby z klasy pracowników do klasy emerytów, osoby z klasy bezrobotnych do klasy pracowników itp. Operacja ta nie wymaga żadnych zmian w SBD (szczególnie w obiektowych BD jest zupełnie naturalna w RBD jest często tożsama z dopisaniem nowego rekordu do odpowiedniej tablicy i usunięciem lub zdeaktywowaniem w innej) jeśli odbywa się to zgodnie z nałożonymi wcześniej regułami. Jeśli jednak na skutek zmian wywołanych czynnikami zewnętrznymi (najczęściej zmianą prawa) operacja ta może wymagać daleko idących zmian zarówno w opisach obiektów, regułach i procedurach. Np. wprowadzenie klasy pracownik_w_okresie_przedemerytalnym obiektu pracownik pociąga za sobą zbudowanie nowych metod (procedur obliczania przynależności do klasy), wprowadzenia nowych atrybutów itp.

• typy powiązań pomiędzy obiektami lub ich klasami - czasami występuje potrzeba zmiany krotności relacji (np. kiedyś jedna osoba mogła być właścicielem lub współwłaścicielem jednego mieszkania - czyli obiekt Osoba tworzył z obiektem Mieszkanie relację 1:m - obecnie ograniczenie to zostało zniesione i jest to relacja m:n).

• zbiór metod opisujących zachowanie się (działanie) obiektu - przykładem tego typu zmiany jest konieczność wprowadzenia metody nalicz_skladke_zdrowotna wykonywanej na obiekcie pracownik (atrybucie płaca), która jest wykonywana dopiero po wprowadzeniu reformy ZUS - od roku 1999. (dodanie metody).

• sposób realizacji metod, zmiana procedury - zwykle pociąga konieczność modyfikacji kodu programu lub wzorów obliczeń.

Bardzo często wszystkie wymienione muszą występować łącznie. Przykładowo utworzenie nowego atrybutu wymaga określenia jego dziedziny i zbudowania procedur (metod) jego obsługi a zmiana krotności relacji wymaga często również sposobu realizacji metod. W tablicy 3 wskazano na typowe zmiany składników BD w reakcji na zmianę zaistniałą w dziedzinie przedmiotowej. Pamiętać jednak należy, że odpowiedzi w każdym konkretnym przypadku mogą być inne w zależności od przyjętego sposobu implementacji.

Zmiany składników bazy danych

Rodzaj zmiany	Co wymaga zmiany
		Reguły	Struktura	Procedury
Wartość atrybutu	Nie	Nie	Nie
Dziedzina atrybutu	Tak	Nie	Nie
Zbiór atrybutów	Tak	Tak	Tak
Skład obiektów złożonych	Tak	Tak	Tak
Zbiór metod	Nie	Nie	Tak
Powiązania pomiędzy obiektami lub ich klasami,	Tak	Tak	Tak
Przynależność obiektu do klasy, nowa klasa	Tak	Tak	Tak
Sposób realizacji metod	Nie	Nie	Tak

Pytania:

na ile z tych zmian BD jest przygotowana?

co zrobić aby uczynić BD mniej wrażliwą na te zmiany?

jak powinna baza wyglądać, aby przeprowadzenie tych zmian było możliwie najprostsze?

Jak skonstruować bazę, aby historie tych wszystkich zmian można było przechować w samej BD?

jak je odczytać oraz przetworzyć uzyskując dodatkowe informacje o rozwoju samej dziedziny, która jest odzwierciedlana w BD?

W praktyce programiści podejmują próby zabezpieczenia się przed zmianami w przyszłości poprzez dokładanie do tabel pól rezerwowych lub oprogramowując możliwość dynamicznej zmiany reguł przetwarzania.

podejmuje się próby określenia standardów postępowania w przypadku dokonywania zmian w strukturze bazy danych.

Zarządzanie zmianami w SBD obejmuje określenie zbioru oraz kolejności operacji potrzebnych do prawidłowego ukompletowania zmian takich jak dodanie atrybutu, tablicy, relacji, rozszerzenie dziedziny i gwarantujących zachowanie logicznej spójności bazy danych oraz możliwość odtwarzania informacji sprzed wprowadzonych zmian.

MODEL SI I BD

1. Schemat odwzorowania dziedziny przedmiotowej w system informatyczny
   Źródło: [Louc92]

Poziomy modelowania:

• konceptualny - na którym dokonuje się opisu zjawisk gospodarczych w kate­goriach stosowanych przez użytkowników baz danych (MK),

• logiczny (zwany także modelem danych) - na którym formułuje się rozwiązania problemu reprezentacji dziedziny przedmiotowej w wybranym języku bazy danych oraz definiuje struktury danych i na którym bierze się pod uwagę wszystkie warunki użytkowania danych (ML),

• fizyczny - na którym następuje odwzorowanie procesów na działanie maszyny, definiowanie i rozmieszczenie zbiorów na nośnikach oraz specyfikacja wykony­wanych operacji na plikach (MF).

REGUŁY I WIĘZY INTEGRALNOŚCI

Dla zapewnienia zgodności zawartości bazy z rzeczywistością oraz jej funkcjonowania zgodnie z przebiegającymi w rzeczywistości procesami należy na BD nałożyć określone prawa.

Integralność BD to bowiem jej własność bycia dokładnym odbiciem modelowanej rzeczywistości

Prawa, które muszą być przestrzegane podczas użytkowania BD nazywamy więzami integralności lub regułami.

Niektóre z reguł zawarte są w samej strukturze bazy danych (np. już określenie typu atrybutu jest ograniczeniem), inne zapisujemy w postaci procedur.

Wartość atrybutu też często nie może być dowolna. Może być ona ustalona w postaci reguły odwołującej się do konkretnych wartości lub do wartości innych atrybutów.

Również działania na BD podlegają regułom: tworzenie nowych krotek, modyfikacja istniejących a nawet działania nie zmieniające stanu bazy (raporty) mogą być wykonane tylko w określonych warunkach.

Odpowiedzialnością za przestrzeganie reguł można obciążyć:

użytkownika,

programistę

SZBD.

Najwygodniejszym sposobem jest zdefiniowanie odpowiednich reguł na etapie budowy SBD i przerzucenie obowiązku ich przestrzegania na SZBD.

Kontrola więzów polega na wyliczeniu wartości formuł dla bie­żącego stanu bazy i historii stanów poprzednich. Jeśli warto­ścią formuły dla któregoś z więzów jest FAŁSZ, to bieżący stan nie zachowuje więzów integralności. Jeśli natomiast formuły od­powiadające wszystkim więzom są prawdziwe, to stan bieżący jest poprawny

Próba wykonania transakcji na BD pociąga za sobą sprawdzenie więzów integralności.

Jeżeli więzy są spełnione, to nowa historia stanów jest zapamiętywana. W przeciwnym wypadku transakcja jest odrzucana. Transakcja, w wyniku której ma powstać nowy stan bazy danych, jest wypełniana tylko wtedy, gdy utworzony przez nią stan spełnia więzy integralności.

We współczesnych BD więzy integralności kontrolowane przez SZBD dotyczyć mogą jedynie pojedynczych stanów bazy lub przejść z jednego stanu do drugiego. Pozostałe więzy trzeba implementować w postaci procedur.

Można więc łatwo formułować więzy odnoszące się do bieżącego stanu bazy i do nowego stanu, dla którego są sprawdzane więzy integralności. Umożliwia to formułowanie warunków typu:

Reguły statyczne:

Cena_towaru >=0

Cena_towaru + podatek <=1 000

Reguły przejścia:

cena towaru nie może zmienić się jednorazowo bardziej niż o 15%.

Stawka pracownika nie może spadać

sprawdzenie takich warunków polega na porównaniu wartości w stanie bieżącym z wartością proponowaną w nowym stanie bazy.

Niemożliwe jest natomiast zdefiniowanie warunku:

w2: cena towaru nie może się zmienić o więcej niż 30% w trzech kolejnych operacjach zmiany ceny.

Sprawdzenie warunku w2 wymagałoby porównania ceny w nowym stanie z cenami z dwóch poprzednich stanów. Specyfikowanie więzów takich, jak w2, wymaga więc przechowywa­nia informacji o poprzednich stanach bazy.

Rodzaje reguł:

• reguły ograniczające (constrains rules) - pozwalające wyspecyfikować warunki integralności (spójności logicznej) BD. Dzielą się one na:

• więzy statyczne (static constrains rules), które muszą być spełnione w każdym z istniejących stanów bazy danych np. cena towaru nie może być mniejsza od zera, płaca pracownika nie może być mniejsza niż płaca minimalna, pojemność silnika samochodu osobowego jest zawsze z przedziału [500, 5000], nie można przypisać pojazdowi marki nie wpisanej do słownika marek, itp.,

• reguły przejścia (transitions constrains rules), które określają warunki dokonania zmiany stanu bazy np. stawka za roboczominutę nie może spadać. Mogą one wyrażać również bardziej złożone zależności (zob. niżej).

• reguły wyprowadzania (derivation rules) - są wyrażeniami, które definiują własności nie zapisane wprost w bazie, ale które mogą być z niej wywiedzione. Musi istnieć dokładnie jedna reguła wnioskowania dla każdej takiej własności. Podobnie jak reguły ograniczające, także i reguły wnioskowania dzielą się na:

• statyczne reguły wyprowadzania - pozwalają na wyprowadzenie (wyliczenie) wartości atrybutów z wartości istniejących np. wartość brutto towaru jest iloczynem jego aktualnej ilości, ceny sprzedaży oraz podatku VAT,

• dynamiczne (temporalne) reguły wyprowadzenia - umożliwiające wyliczanie wartości z co najmniej dwóch różnych stanów bazy np. cena sprzedaży promocyjnej to średnia z trzech ostatnich zakupów klienta powyżej 10 sztuk towaru

• reguły działania (aktywacji) tzw. reguły wyzwalaczy, określające warunki uruchomienia odpowiednich procedur. Reguły wyzwalaczy zawierają zbiór warunków, w tym warunków temporalnych, które muszą być spełnione, aby dana procedura mogła być uruchomiona. Przykład: Jeśli ilość materiału X jest mniejsza niż Y uruchom procedurę tworzenia zamówienia na ten materiał.

Implementacja reguł:

Statyczne ograniczające - wszystkie

Dynamiczne ograniczające:

W SZBD ORACLE w wyzwalaczach związanych z operacjami INSERT i UPDATE można odwołać się do wartości istniejącej w bazie poprzez prefix :OLD, natomiast do wartości wprowadzanej poprzez prefix :NEW.

W MS SQL Server możliwe jest wykorzystanie dwóch wartości, ponieważ w czasie wykonywania transakcji przechowywane są one w dwóch specjalnych tabelach. Tabela DELETED przechowuje wartości już istniejące w bazie natomiast tabela INSERTED zawiera wartości proponowane.

Cechy systemów transakcyjnych

Systemy MRP, ERP (Material Requirement Planning - Enterprise Requirement Planning)

• planowania i zarządzania procesami technologicznymi według zasady Just in Time, a w tym:

• planowania dostaw i zużycia materiałów,

• kontroli zabezpieczenia potrzeb materiałowych produkcji,

• automatycznego regulowania poziomu zapasów, łącznie z wystawianiem zamówień i zgłaszaniem upłynnienia,

• sterowania zaopatrzeniem, zapasami i dostawami, a w tym:

• kontroli realizacji i rozliczania dostaw,

• rozliczania inwentaryzacji,

• limitowania zużycia materiałów,

• sygnalizowania zużycia ponadnormatywnego,

• racjonalizacji transportu i składowania materiałów,

• wsparcia wszechstronnej analizy gospodarki materiałowej,

• planowania i sterowania wykorzystaniem zdolności produkcyjnych,

• bieżącego zarządzania finansami w przedsiębiorstwie.

Budując nowoczesne systemy transakcyjne uwzględnia się również zagadnienia:

• działań w grupie,

• grupowego podejmowania decyzji,

• interakcji człowieka z komputerem,

• automatyzacji biura,

• wizualizacji i automaty­cznego przetwarzania dokumentów,

• organizacji obiegu dokumentów,

• nowoczesnych środków wymiany informacji itp.

W ten sposób zakres działania systemów transakcyjnych został rozszerzo­ny na wspomaganie zespołów ludzkich poprzez porządkowanie, organizowanie, automatyzowanie, przekazywanie i śledzenie prac realizowanych przez zespół.

• Ważne jest jedynie aby transakcja rozpoczęła się w spójnym stanie bazy i takim stanie ją pozostawiła.

• Celem działania systemów transakcyjnych jest rejestrowanie zdarzeń lub wspoma­ganie terminowej reakcji na zdarzenia występujące w otoczeniu oraz ich terminowe przygotowanie i generowanie.

• Systemy transakcyjnych baz danych wspomagają zatem zmianę bieżącego stanu organizacji na nowy, zgodny z wymuszeniem wygenerowa­nym przez zdarzenie.

• Systemy te muszą (i to niemal natychmiast) odpowiadać na pytania dotyczące aktualnego stanu rzeczywistości, gdyż od otrzymanej informacji zależy możliwość realizacji ewentualnej transakcji.

Systemy takie z punktu widzenia związków ze zmiennością dziedziny przedmiotowej charakteryzują się tym, że:

• są zdolne do reakcji na sygnały zachodzące w otoczeniu, ale w bardzo ograniczonym zakresie posiadają zdolności do operowania informacją historyczną,

• ze względu na odgrywaną w przedsiębiorstwie rolę można je określić jako systemy odpowiedzialne za reakcję na zdarzenia lub systemy obsługi zdarzeń. Dlatego określane są również jako systemy sterowane zdarzeniami (event-driven). Podejście to jest zgodne z rozwijanym paradygmatem traktowania systemów wspomagających działalność gospodarczą w kategoriach systemów czasu rzeczywistego - wobec coraz burzliwszego otoczenia, w jakim muszą one pracować,

• pamięć takiego systemu może zostać ograniczona do historii realizacji konkretnej transakcji (sprzedaży, produkcji, montażu itp.).

• do utrzymania bazy w stanie spójności logicznej wystarczają wyłącznie statyczne reguły integralności.

W toku wspomagania bieżących zadań w systemach transakcyjnych powstają duże zbiory danych dokumentujących przebieg wykonania poszczególnych transakcji. Jednakże koncentracja na wspomaganiu (optymalizacji, usprawnianiu, doskonaleniu) działalności operacyjnej często ogranicza ich użyteczność w prowadzeniu pogłębionych analiz przedsiębiors­twa i jego otoczenia. Przez wiele lat zbiory danych historycznych miały charakter archiwalny przede wszystkim dlatego, że:

• nie dostrzegano możliwości ich spożytkowania w procesach analizy rzeczywistości gospodarczej i podejmowania decyzji,

• nie dysponowano narzędziami potrzebnym do ich analizy,

• nie dysponowano odpowiednią technologią niezbędną od operowania na dużych ilościach danych,

• sposób ich przechowywania w bazach danych utrudniał zastosowanie zestandaryzowanych sposobów ich obróbki.

Zainteresowanie możliwością wykorzystania danych historycznych wzrasta wraz z technicznymi możliwościami przechowywania dużych ilości danych.

Z punktu widzenia użytkownika końcowego odpowiedzialnego za wykonanie transakcji (sprzedawca, wypożyczający, urzędnik) istotne jest jedynie uzyskanie szybkiej odpowiedzi na zadane pytanie co do informacji jakiej domaga się klient. Inne informacje są dla niego nieistotne chociaż mogą być ważne dla innych użytkowników systemu

Przykład z dziedziny sprzedaży

Z punktu widzenia użytkownika końcowego istotne jest jedynie czy dostępna jest taka ilość towaru, jakiej domaga się klient. Nie jest ważne jakie były w przeszłości ceny sprzedaży tego towaru a jedynie, po jakiej cenie ma być dokonana aktualna transakcja. Odpowiedzi na inne pytania: Jak zmieniały się ceny towaru?, Jaki jest przewidywany kierunek tych zmian? Jakie ceny oferował poprzedni dostawca?, Dlaczego towaru jest tak mało/dużo?, Jaka jest średnia wielkość zakupu towaru? - są z punktu widzenia realizacji kolejnych transakcji nieistotne. Całość funkcjonuje zgodnie ze schematem z rysunku.

Zegar	Wpłata klienta A	Wpłata klienta B	Stan konta A	Stan konta B
1	Odczyt stanu konta = 100	-	100	-
2		Odczyt stanu konta = 100	100	100
3	Wpłata = 10		110	100
4		Wpłata = 20	110	120
5	Zapis stanu konta = 110		110	120
6		Zapis stanu konta = 120	-	120

Zegar	Zakup klienta A	Zakup klienta B
1	Odczyt stanu magazynu = 100	-
2	Klient się zastanawia	Odczyt stanu magazynu = 100
3	Klient zamawia 70 sztuk	Klient zamawia 50 sztuk
4	Zapis nowego stanu =30	Zapis nowego stanu =50

Przykre konsekwencje:

1. Klienci mogą nie otrzymać towaru bo go zabraknie w magazynie

2. Stan magazynowy jest fałszywy i następni klienci dalej wykonują zakupy

1

zdarzenie

BD

Sprawdzenie możliwości obsługi zdarzenia

Wykonanie działań

Odrzucenie żądania

BD w nowym stanie

---