Godzina 16.30, już wychodziłeś z pracy, w planie było kino i kolacja – i stało się… Zgłoszenie produkcyjne z wysokim priorytetem zostaje przypisane do ciebie. Już po godzinie wiesz, że przyczyną jest pewien wpis w bazie danych w tabelce z transakcjami, ale skąd się ten wpis tam wziął? Godzina 18:00, na szybko korygujesz wpis i aktualizujesz dane ręcznie, żeby zamknąć zgłoszenie. Jest 18:15 i masz nadzieję, że już więcej się to nie zdarzy – bo gdybyś chciał dojść do tego, jak ten wpis powstał, to pewnie byłby godziny analizy i pracy z debuggerem. Wychodzisz o 18:30, jeszcze wyrobisz się do kina, ale co będzie jeżeli zadzwonią znowu z tym samym problemem za pół godziny?
W trakcie wytwarzania aplikacji rzadko poświęca się czas na takie zorganizowanie struktur danych, które pozwala na łatwe prześledzenie źródła, które spowodowało utworzenie i zmodyfikowanie zapisów czy też odszukanie ich autora. Przeważnie starając się ciąć koszty czy też koncentrując na jak najszybszym dostarczeniu tzw. wartości biznesowej dla użytkownika funkcje związane z późniejszym utrzymaniem systemu oddalane są na dalszy plan.
Poniżej przedstawiam garść dobrych praktyk przy tworzeniu modelu danych dla systemów transakcyjnych, które pozwalają na śledzenie modyfikacji i zapisów. Praktyki te wyniosłem z doświadczenia pracując na systemach pudełkowych (out of the shelf) takich jak PeopleSoft, jak również mając styczność z wytwarzanymi przez firmy na potrzeby własne.
1. Informacja audytowa
Wszystkie tabele konfiguracyjne i transakcyjne powinny zawierać w wierszu:
- data i czas utworzenia
- data i czas modyfikacji
- login użytkownika tworzącego wpis (może być login identyfikujący system zlecający lub nawet działanie wewnętrzne aplikacji)
- login użytkownika modyfikującego wpis
- znacznik wersji (uaktualniany z każdą kolejną modyfikacją)
Aplikacja musi obsługiwać wypełnianie ww. informacji dla tabel transakcyjnych.
Znając ostatnią datę modyfikacji i login zlecającego możemy łatwiej prześledzić źródło wpisu, to z kolei pozwala na identyfikację ewentualnej przyczyny problemu jako zewnętrznej lub wewnętrznej bez żmudnej analizy logów.
Znakowanie wiersza w tabeli przy jego modyfikacji, czy utworzeniu lub przez podnoszenie znacznika wersji bywa również stosowane na potrzeby mechanizmów ładowania danych do hurtowni danych. Działa to w prosty sposób, gdy weryfikowane są do załadunku sprawdzany jest poprzedni znacznik z ostatniego ładowania z tym obecnym w źródle danych i jeżeli jest on większy to znaczy, że rekord został zmodyfikowany.
Oracle wspiera tzw. metadane skojarzone z wierszem w tabeli, które pozwalają ustalić pewne fakty dotyczące danego wpisu (np. możemy ustalić datę i czas ostatniej modyfikacji wiersza na podstawie ORA_ROWSCN), ale niestety informacja ta jest dostępna tylko przez określony czas.
2. Wskazanie identyfikatora transakcji źródłowej
Każdy rekord powinien mieć wskazane id transakcji (transakcji lub obiektu), który pozwala znaleźć relację do danych lub operacji odpowiedzialnych za utworzenie lub uaktualnienie rekordu.
- id operacji tworzącej (np. numer zamówienia z systemu tworzenia zamówień)
- kod źródła operacji tworzącej (np. system zlecający CRM)
- id operacji uaktualniającej
- kod źródła operacji uaktualniającej
Wprowadzenia znaczników transakcji źródłowych pozwala na powiązanie danych między systemami umożliwiając weryfikację spójności danych i identyfikację źródła powstawania danych. Niejednokrotnie dane wędrują między systemami i podlegają modyfikacji (chociażby w wyniku transformacji na szynie integracyjnej) – dlatego umożliwienie powiązania danych przez identyfikator transakcji ułatwia prześledzenie poprawności danych pomiędzy źródłem a odbiorcą informacji.
3. Efektywne datowanie i znacznik aktywności
Absolutnie każdy wiersz konfiguracyjny w tabeli powinien być efektywnie datowany, tzn. powinien zawierać
- data i czas obowiązywania od lub datę efektywną
- data i czas obowiązywania do lub znacznik obowiązywania (aktywny, nieaktywny)
Efektywne datowanie pozwala pokazać, że dany wiersz obowiązywał w przeszłości, obowiązuje, albo będzie obowiązywał w przyszłości. Wyobraź sobie, że znowu zmieniana jest stawka podatku VAT na towary, którymi handlujesz i przetwarzasz informacje o tych transakcjach w twoim systemie, który odpowiada za wystawianie faktur sprzedażowych w sklepie internetowym on-line. Zmiana wchodzi z dniem 01.01.2017, nowa obowiązująca stawka VAT będzie miała wartość 25%. Co zrobisz? Zalogujesz się do bazy danych i wprowadzasz konfigurację, kiedy inni będą otwierali szampana?
Danych w systemach transakcyjnych się nie usuwa, co najwyżej archiwizuje – może ktoś mnie przekona, że to nie jest prawda. Dobrą praktyką jest znakowanie wpisów w tabeli jako już nie obowiązujących, ustawiając ich status jako nieaktywne (np. poprzez oznaczanie odpowiednią flagą). Taka praktyka przeciwdziała gubieniu danych przez błędy w aplikacji.
4. Podsumowanie
Powyżej przedstawiłem kilka dobrych rad, które można rozważyć podczas projektowania systemów transakcyjnych używających relacyjnych baz danych. Nie wgłębiałem się w niuanse działania dostępnych na rynku baz danych i tego co w tym zakresie oferują, mając na uwadze, że często budujemy systemy, które z założenia powinny działać na różnych silnikach.
Warto przemyśleć podczas wytwarzania oprogramowania, czy akurat w przypadku problemu, który rozwiązujemy nie powinniśmy poświęcając kilka dodatkowych godzin, aby zaoszczędzimy sobie i innym wielu godzin pracy (niekoniecznie ciekawych) w przyszłości.