Myślisz o projekcie bazy danych do rejestrowania audytu? Przypomnij sobie, co stało się z Jaśem i Małgonią:uważali, że pozostawienie prostego śladu okruchów chleba to dobry sposób na śledzenie ich kroków.
Kiedy projektujemy model danych, uczymy się stosować filozofię, że teraz jest wszystkim, co istnieje . Na przykład, jeśli zaprojektujemy schemat do przechowywania cen dla katalogu produktów, możemy pomyśleć, że baza danych musi tylko podać nam cenę każdego produktu w chwili obecnej. Ale gdybyśmy chcieli wiedzieć, czy ceny zostały zmodyfikowane, a jeśli tak, to kiedy i jak te modyfikacje miały miejsce, mielibyśmy kłopoty. Oczywiście możemy zaprojektować bazę danych specjalnie do przechowywania chronologicznego zapisu zmian – powszechnie znanego jako ścieżka audytu lub dziennik audytu.
Rejestrowanie audytów pozwala bazie danych mieć „pamięć” przeszłych zdarzeń. Kontynuując przykład z cennikiem, odpowiedni dziennik audytu pozwoli nam dokładnie określić, kiedy cena została zaktualizowana, jaka była przed aktualizacją, kto ją zaktualizował i skąd.
Rozwiązania do rejestrowania audytu bazy danych
Byłoby wspaniale, gdyby baza danych mogła przechowywać migawkę swojego stanu dla każdej zmiany zachodzącej w jej danych. W ten sposób możesz cofnąć się do dowolnego punktu w czasie i zobaczyć, jak dane były w tym konkretnym momencie, tak jakbyś przewijał film. Ale ten sposób generowania dzienników kontrolnych jest oczywiście niemożliwy; wynikowa ilość informacji i czas potrzebny na wygenerowanie logów byłby zbyt wysoki.
Strategie rejestrowania audytu opierają się na generowaniu śladów audytu tylko dla danych, które można usunąć lub zmodyfikować. Wszelkie zmiany w nich muszą zostać poddane audytowi, aby cofnąć zmiany, przeszukać dane w tabelach historii lub śledzić podejrzaną aktywność.
Istnieje kilka popularnych technik rejestrowania audytu, ale żadna z nich nie służy każdemu celowi. Te najskuteczniejsze są często drogie, wymagające dużej ilości zasobów lub obniżające wydajność. Inne są tańsze pod względem zasobów, ale są albo niekompletne, niewygodne w utrzymaniu, albo wymagają poświęcenia jakości projektu. Wybrana strategia będzie zależeć od wymagań aplikacji oraz ograniczeń wydajności, zasobów i zasad projektowania, których należy przestrzegać.
Niestandardowe rozwiązania do rejestrowania
Te rozwiązania do rejestrowania kontroli działają poprzez przechwytywanie wszystkich poleceń wysyłanych do bazy danych i generowanie dziennika zmian w osobnym repozytorium. Takie programy oferują wiele opcji konfiguracji i raportowania do śledzenia działań użytkownika. Mogą rejestrować wszystkie akcje i zapytania wysyłane do bazy danych, nawet jeśli pochodzą od użytkowników o najwyższych uprawnieniach. Narzędzia te są zoptymalizowane pod kątem minimalizacji wpływu na wydajność, ale często wiąże się to z kosztami finansowymi.
Cena dedykowanych rozwiązań ścieżki audytu może być uzasadniona, jeśli masz do czynienia z bardzo wrażliwymi informacjami (takimi jak dokumentacja medyczna), w których każda zmiana danych musi być doskonale monitorowana i możliwa do audytu, a ścieżka audytu musi być niezmienna. Ale gdy wymagania dotyczące ścieżki audytu nie są tak rygorystyczne, koszt dedykowanego rozwiązania do rejestrowania może być nadmierny.
Natywne narzędzia monitorowania oferowane przez systemy relacyjnych baz danych (RDBMS) mogą być również wykorzystywane do generowania ścieżek audytu. Opcje dostosowywania pozwalają filtrować, które zdarzenia są rejestrowane, aby nie generować zbędnych informacji lub przeciążać silnika bazy danych operacjami rejestrowania, które nie będą później wykorzystywane. Wygenerowane w ten sposób logi pozwalają na szczegółowe śledzenie operacji wykonywanych na tabelach. Jednak nie są one przydatne do odpytywania tabel historii, ponieważ rejestrują tylko zdarzenia.
Najbardziej ekonomiczną opcją utrzymania ścieżki audytu jest specjalne zaprojektowanie bazy danych do rejestrowania audytu. Ta technika opiera się na tabelach dzienników, które są wypełniane przez wyzwalacze lub mechanizmy specyficzne dla aplikacji, która aktualizuje bazę danych. Nie ma powszechnie akceptowanego podejścia do projektowania bazy danych rejestrowania kontroli, ale istnieje kilka powszechnie stosowanych strategii, z których każda ma swoje wady i zalety.
Techniki projektowania rejestrowania audytu bazy danych
Wersjonowanie wierszy na potrzeby logowania kontrolnego w miejscu
Jednym ze sposobów utrzymania ścieżki audytu dla tabeli jest dodanie pola, które wskazuje numer wersji każdego rekordu. Wstawki do tabeli są zapisywane z początkowym numerem wersji. Wszelkie modyfikacje lub usunięcia w rzeczywistości stają się operacjami wstawiania, w których generowane są nowe rekordy ze zaktualizowanymi danymi, a numer wersji jest zwiększany o jeden. Poniżej możesz zobaczyć przykład tego projektu logowania w miejscu audytu:
Uwaga:projektów tabel z osadzonymi wersjami wierszy nie można łączyć za pomocą relacji kluczy obcych.
Oprócz numeru wersji do tabeli należy dodać kilka dodatkowych pól, aby określić pochodzenie i przyczynę każdej zmiany dokonanej w rekordzie:
- Data/godzina zarejestrowania zmiany.
- Użytkownik i aplikacja.
- Wykonana czynność (wstawianie, aktualizacja, usuwanie) itp. Aby ścieżka audytu była skuteczna, tabela musi obsługiwać tylko wstawianie (aktualizacje i usuwanie nie powinny być dozwolone). Tabela również koniecznie wymaga zastępczego klucza podstawowego, ponieważ każda inna kombinacja pól będzie podlegać powtórzeniu.
Aby uzyskać dostęp do zaktualizowanych danych tabeli za pomocą zapytań, należy utworzyć widok, który zwraca tylko najnowszą wersję każdego rekordu. Następnie musisz zastąpić nazwę tabeli nazwą widoku we wszystkich zapytaniach z wyjątkiem tych, które mają na celu wyświetlenie chronologii rekordów.
Zaletą tej opcji wersjonowania jest to, że nie wymaga używania dodatkowych tabel do generowania ścieżki audytu. Ponadto tylko kilka pól jest dodawanych do kontrolowanych tabel. Ma jednak ogromną wadę:zmusi cię do popełnienia niektórych z najczęstszych błędów projektowych bazy danych. Obejmują one nieużywanie integralności referencyjnej lub naturalnych kluczy podstawowych, gdy jest to konieczne, co uniemożliwia zastosowanie podstawowych zasad projektowania diagramów encji. Możesz odwiedzić te przydatne zasoby dotyczące błędów projektowania bazy danych, dzięki czemu otrzymasz ostrzeżenie, jakich innych praktyk należy unikać.
Tabele cieni
Inną opcją ścieżki audytu jest wygenerowanie tabeli cieni dla każdej tabeli, która wymaga audytu. Tabele cienia zawierają te same pola, co kontrolowane przez nie tabele, plus określone pola audytu (te same, o których mowa w technice wersjonowania wierszy).
Tabele cienia replikują te same pola, co kontrolowane przez nie tabele, a także pola przeznaczone do celów kontrolnych.
Aby wygenerować ślady audytu w tabelach cieni, najbezpieczniejszą opcją jest utworzenie wyzwalaczy wstawiania, aktualizowania i usuwania, które dla każdego dotkniętego rekordu w oryginalnej tabeli generują rekord w tabeli audytu. Wyzwalacze powinny mieć dostęp do wszystkich informacji kontrolnych, które musisz zarejestrować w tabeli cieni. Będziesz musiał użyć specyficznej funkcjonalności silnika bazy danych, aby uzyskać dane, takie jak aktualna data i godzina, zalogowany użytkownik, nazwa aplikacji i lokalizacja (adres sieciowy lub nazwa komputera), z którego operacja się rozpoczęła.
Jeśli użycie wyzwalaczy nie jest opcją, logika generowania śladów audytu powinna być częścią stosu aplikacji, w warstwie idealnie zlokalizowanej tuż przed warstwą utrwalania danych, aby mogła przechwycić wszystkie operacje skierowane do bazy danych.
Ten rodzaj tabeli dziennika powinien umożliwiać tylko wstawianie rekordów; jeśli pozwalają na modyfikowanie lub usuwanie, ścieżka audytu nie spełniałaby już swojej funkcji. Tabele muszą również używać zastępczych kluczy podstawowych, ponieważ zależności i relacje oryginalnych tabel nie mogą być do nich stosowane.
Jeśli tabela, dla której utworzyłeś ścieżkę audytu, zawiera tabele, od których zależy, powinny one również mieć odpowiednie tabele cieni. Dzieje się tak, aby ścieżka audytu nie została osierocona, jeśli w innych tabelach zostaną wprowadzone zmiany.
Tabele cieni są wygodne ze względu na swoją prostotę i ponieważ nie wpływają na integralność modelu danych; ścieżki audytu pozostają w osobnych tabelach i są łatwe do wyszukania. Wadą jest to, że schemat nie jest elastyczny:wszelkie zmiany w strukturze głównej tabeli muszą być odzwierciedlone w odpowiedniej tabeli cieni, co utrudnia utrzymanie modelu. Ponadto, jeśli logowanie kontrolne musi być zastosowane do dużej liczby tabel, liczba tabel cieni również będzie wysoka, co jeszcze bardziej utrudni utrzymanie schematu.
Tabele ogólne do rejestrowania kontroli
Trzecią opcją jest utworzenie ogólnych tabel dla dzienników kontrolnych. Takie tabele umożliwiają logowanie dowolnej innej tabeli w schemacie. Ta technika wymaga tylko dwóch tabel:
Tabela nagłówków, która rejestruje:
- Data i godzina zmiany.
- Nazwa tabeli.
- Klucz danego wiersza.
- Dane użytkownika.
- Rodzaj wykonywanej operacji.
Tabela szczegółów, która rejestruje:
- Nazwy każdego pola, którego dotyczy problem.
- Wartości pola przed modyfikacją.
- Wartości pola po modyfikacji. (Możesz to pominąć, jeśli to konieczne, ponieważ można je uzyskać, sprawdzając następujący rekord w ścieżce audytu lub odpowiedni rekord w audytowanej tabeli.)
Korzystanie z ogólnych tabel dziennika kontroli nakłada ograniczenia na typy danych, które można kontrolować.
Zaletą tej strategii rejestrowania audytu jest to, że nie wymaga żadnych tabel innych niż dwie wymienione powyżej. Ponadto przechowywane są w nim rekordy tylko dla pól, na które ma wpływ operacja. Oznacza to, że nie ma potrzeby replikowania całego wiersza tabeli, gdy modyfikowane jest tylko jedno pole. Ponadto ta technika umożliwia prowadzenie dziennika dowolnej liczby tabel – bez zaśmiecania schematu dużą liczbą dodatkowych tabel.
Wadą jest to, że pola przechowujące wartości muszą być jednego typu – i wystarczająco szerokie, aby pomieścić nawet największe z pól tabel, dla których chcesz wygenerować dziennik kontroli. Najczęściej używa się pól typu VARCHAR, które akceptują dużą liczbę znaków.
Jeśli na przykład musisz wygenerować dziennik audytu dla tabeli, która ma jedno pole VARCHAR o długości 8000 znaków, pole przechowujące wartości w tabeli audytu musi mieć również 8000 znaków. Dzieje się tak, nawet jeśli w tym polu zapiszesz tylko jedną liczbę całkowitą. Z drugiej strony, jeśli twoja tabela zawiera pola złożonego typu danych, takie jak obrazy, dane binarne, obiekty BLOB itp., będziesz musiał serializować ich zawartość, aby mogły być przechowywane w polach VARCHAR tabel dziennika.
Mądrze wybierz projekt dziennika audytu bazy danych
Widzieliśmy kilka alternatyw dla generowania dzienników kontrolnych, ale żadna z nich nie jest tak naprawdę optymalna. Należy przyjąć strategię rejestrowania, która nie wpływa znacząco na wydajność bazy danych, nie powoduje jej nadmiernego wzrostu i spełnia wymagania dotyczące identyfikowalności. Jeśli chcesz przechowywać dzienniki tylko dla kilku tabel, najwygodniejszą opcją mogą być tabele w tle. Jeśli chcesz mieć swobodę rejestrowania dowolnej tabeli, najlepsze mogą być ogólne tabele rejestrowania.
Czy odkryłeś inny sposób na prowadzenie dziennika kontroli swoich baz danych? Udostępnij to w sekcji komentarzy poniżej – twoi koledzy projektanci baz danych będą bardzo wdzięczni!
