W ekosystemie bazy danych funkcjonuje 9 ról, które mają bezpośredni wpływ na jakość i wydajną dostępność danych. Część jest odpowiedzialna za tworzenie bazy danych. Część za jej utrzymanie. Dziewiąta może nie istnieć w Twoim przedsiębiorstwie. Daj znać w komentarzu czy powinna.

Administrator baz danych

Administratorzy baz danych są strażnikami najcennieszego zasobu organizacji: jej danych

Larry Ellison

Administrator baz danych określany jest angielskim akronimem DBA. Co znaczy DataBase Administrator. Osobę pracująca na tym stanowisku możesz wyobrażać sobie jako strażnika dbającego o bezpieczeństwo i dostępność danych.

W materiale o zasobach wspominałem o kluczowej roli administratora bazy danych. Wiesz z niego, że ściśle współpracuje ze specjalistami z innych obszarów infrastruktury IT. Ścisła współpraca jest niezbędna ponieważ najważniejszymi zadaniami są zapewnienie:

• spójności
• bezpieczeństwa
• dostępności danych

Możemy podyskutować o kolejności. Ja widzę to tak: dane, które nie są spójne nie mają wartości. Są bezużyteczne. Mając spójne dane nie chcesz aby zostały uszkodzone ani wykradzione. To może wiązać się ze stratami finansowymi. Najłatwiej jest zapewnić dostępność. Wystarczy kupić więcej mocy obliczeniowej lub lepszych programistów.

Spójność danych oznacza ich zgodność z faktami świata rzeczywistego. O spójność danych ekosystem bazy danych dba na 2poziomach.

• Pierwszy można określić jako fizyczny. Jest to poziom bazy danych jako całości. Czyli spójna baza danych to taka, której każdy zmieniony blok został, przez instancję, z sukcesem przepisany z pamięci na nośnik. Na tym poziomie niespójna baza danych w ogóle nie może być udostępniona. Motor bazy danych jej nie udostępni. Twórcy motorów zdają sobie sprawę, że spójność danych jest najbardziej istotną ich cechą. Dlatego dostarczają odpowiednich mechanizmów wbudowanych w jądro systemu zarządzania bazą danych. Na przykład kontrola zapisu na nośnik, zarządzanie współbieżnością transakcji, poziomy izolacji czy właściwości ACID. Wszystkie popularne motory baz danych dysponują tymi mechanizmami. Zarządzanie nimi leży głównie w gestii administratora baz danych i odbywa się na poziomie instancji bazy danych.

• Drugi poziom spójności to dane w bazie danych. Tutaj odpowiedzialność za spójność współdzielona jest z architektami bazy danych i programistami. O tych rolach szerzej w dalszej części. Mechanizmy, które dbają o spójność danych w bazie danych nazywają się więzami integralności. Aby mogły wykonywać swoje zadanie muszą zostać zaprojektowane przez architekta, zaimplementowane przez programistę oraz wdrożone przez administratora baz danych.

Współpracę mechanizmów motoru i więzów integralności oraz podział odpowiedzialności pomiędzy role możesz wyobrazić sobie tak: transakcja przeprowadza bazę danych z jednego spójnego stanu w drugi. Motor bazy danych dba aby transakcja wykonała się w całości lub w całości nie wykonała. Nie ma stanu pośredniego. Motor dba aby wynik transakcji został utrwalony na nośniku.

To co transakcja zawiera czyli komendy modyfikujące dane w bazie danych są odpowiedzialnością programisty. Mogą zmodyfikować za dużo lub za mało i z punktu widzenia użytkowników dane stracą spójność. Aby transakcje modyfikowały dokładnie ile i jak trzeba baza danych powinna zawierać więzy integralności, które projektuje architekt, implementuje programista, a wdraża administrator. Innymi słowy baza danych może być spójna, ale zawierać niespójne dane.

Podobnie podzielone są kompetencje jeśli chodzi o bezpieczeństwo danych. Także można wyróżnić 2 poziomy.

• Pierwszy to dostęp do instancji bazy danych, uprawnienia pozwalające na modyfikację struktury bazy danych oraz wykorzystanie funkcjonalności motoru. Tym poziomem zarządza administrator bazy danych. To DBA na poziomie instancji tworzy konta dla użytkowników oraz konfiguruje politykę haseł. Może także ustalać dla kont limity na zasoby instancji. Nie można ignorować drugiej strony medalu czyli odbierania niepotrzebnych uprawnień i dostępów. Na przykład gdy człowiek zmieni stanowisko lub przestanie być pracownikiem. Czasem takie informacje nie docierają do DBA. Niektóre firmy integrują instancje bazy danych z centralnymi systemami jak LDAP. Co ułatwia zarządzanie kontami.

• Uprawnienia do danych są drugim poziomem bezpieczeństwa. Powinny być zaprojektowane przez architekta i zaprogramowane przez programistę. Tylko osoby znające specyfikę działania aplikacji wiedzą kto, jaki i do jakich danych powinien mieć dostęp. Na tym etapie istnieje pokusa aby dawać szerokie uprawnienia. W firmach nie posiadających sztywnej, wymuszanej procedurami i automatami, polityki zarządzania dostępem do danych mogą pojawić się naciski aby administrator baz danych nadawał bardzo szerokie uprawnienia dla konta aplikacji. Nawet porównywalne z administracyjnymi. Wtedy dużo zależy od zasad i asertywności administratora baz danych. Trzeba pamiętać, że aplikacja jest najsłabszym ogniwem w systemie zabezpieczeń. Czasem twórcy aplikacji poświęcają bezpieczeństwo na rzecz szybkości wdrożenia oprogramowania. Czasem brak dbałości o bezpieczeństwo danych wynika z nieznajomości funkcjonalności motoru bazy danych. Jakby nie było to brak właściwej dbałości o bezpieczeństwo danych mści się kosztownymi wyciekami danych lub okupem za ich odszyfrowanie. Skomentuj czy chcesz więcej materiałów na temat zabezpieczania danych przy pomocy mechanizmów bazodanowych.

To co najbardziej dotyka użytkownika danych to ich dostępność. Termin ten obejmuje nie tylko samą możliwość uzyskania dostępu do danych, ale także czas w jakim to nastąpi. Bez dostępnych danych użytkownik nie może wykonać swojego zadania. Dlatego bardzo popularnym opisem awarii systemu informatycznego jest 'baza danych nie działa’. Awarie typu działa/nie działa są stosunkowo łatwe do namierzenia. Dużym wsparciem jest wspomniany w materiale o zasobach system monitorujący. Przykładem może być działająca lub nie instancja bazy danych czy połączenie sieciowe do niej. W tę kategorię wpisują się także brakujące uprawnienia. Czyli brak uprawnień do podłączenia do instancji czy brak uprawnień do dostępu do danych. Do tej kategorii należy również uszkodzenie bazy danych. Utrata spójności fizycznej czyli brak lub uszkodzone pliki. Albo uszkodzenie logiczne czyli brak lub uszkodzone dane. W takiej sytuacji często jedynym ratunkiem jest odtworzenie backupu.

Trudniejsze w diagnozie są awarie typu 'działa tak wolno, że dla mnie nie działa’. Te można podzielić na dwie kategorie.

• Pierwsza to wyczerpanie zasobów instancji bazy danych. Część zasobów do których instancja ma dostęp jest konfigurowana w momencie jej startu na podstawie parameterów inicjalizacyjnych. Najważniejszy z nich to rozmiar pamięci podręcznej. O pamięci podręcznej mówiłem w materiałach o terminach i zasobach. Jeśli pamięć podręczna będzie zbyt mała to instancja bazy danych będzie więcej danych czytać z dysków. Pamięć RAM jest wielokrotnie szybsza i ma mniejsze ograniczenia jeśli chodzi o dostęp losowy niż dyski twarde. Motory bazy danych dysponują bogatym instrumentarium pozwalającym diagnozować wąskie gardła instancji. Odpowiednio skonfigurowane systemy monitorujące są w stanie powiadomić o sytuacjach alarmowych zanim zrobi to użytkownik.

• Druga kategoria dotyczy zbyt wolnego dostępu do danych. Czyli komendy dostępu do danych wykonywane są przez instancję bazy danych nieakceptowalnie długo dla użytkownika. W tym przypadku administrator baz danych często bazuje na subiektywnym odczuciu użytkownika. Nie każda aplikacja zaopatrzona jest w stosowne instrumentarium pozwalające na spojrzenie na aktualną wydajność z historycznej perspektywy. Nie każde przedsiębiorstwo zatroszczyło się o skwantyfikowanie parametrów wydajnościowych aplikacji w postaci KPI. W analizie DBA posiłkuje się narzędziami dostarczanymi przez producenta motoru bazy danych. Trzeba pamiętać, że administrator baz danych posługuje się terminami bazodanowymi natomiast użytkownik terminami określającymi funkcjonalność aplikacji. Aby się dogadali czasem potrzebne jest wsparcie twórcy aplikacji.

Architekt

Architekci są patrzącymi na dane z szerokiej perspektywy wizjonerami, których zadaniem jest zaprojektowanie systemów urzeczywistniających wizję

W procesie tworzenia aplikacji bazodanowej udział biorą 4 role. Rolami o których czasem się zapomina są architekt danych i architekt bazy danych. Architekt danych opracowuje strategię zarządzania danymi dla całej organizacji. Jego zadaniem jest ścisła współpraca z interesariuszami aby sposób przetwarzania danych wspierał działalność przedsiębiorstwa i proces decyzyjny kierownictwa. W zakresie jego zainteresowań znajdują się wszystkie dane gromadzone przez firmę. Także te nie znajdujące się w bazach danych.

Architekt bazy danych opracowuje strukturę bazy danych realizującą strategię opracowaną przez architekta danych. Jego zadaniem jest przełożenie wymagań strategicznych na funkcjonalności konkretnego motoru bazy danych. Ma przy tym na względzie jakość i bezpieczeństwo danych oraz wydajność ich przetwarzania. Ściśle współpracuje z programistami i administratorami baz danych. Trzeba pamiętać, że motory baz danych różnią się funkcjonalnością. Warto aby architekt baz danych dobrze znał specyfikę motoru dla którego projektuje bazę danych.

Można spotkać się z opiniami jakoby przeniesienie aplikacji i bazy danych do chmury było panaceum na problemy wydajnościowe. Wg mnie, problemy wydajnościowe wynikają z nieoptymalnej architektury i nieznajomości baz danych wśród programistów. Przeniesienie złej architektury i kiepskiej aplikacji do chmury zaowocuje złą architekturą i kiepską aplikacją tylko w chmurze. Dobry projekt jest kluczowy dla jakości nie tylko w świecie IT. Rola architekta jest trudna do przecenienia.

Programista

Praca programisty baz danych polega na zamianie logiki biznesowej w operacje bazodanowe

Programista, w ekosystemie bazy danych zwany programistą baz danych lub deweloperem baz danych, ma za zadanie napisać kod zrozumiały dla wybranego przez architekta baz danych motoru. Najpopularniejszym językiem służącym do manipulowania strukturą bazy danych i danymi jest SQL. Jest ustandaryzowany przez instytucje ANSI i ISO niemniej twórcy motorów baz danych nie trzymają się standardu w 100%. Warto aby programista znał specyfikę motoru bazy danych dla którego koduje. Warto także aby pamiętał, że jego kod będzie wykonywany na maszynie o wielu procesorach. Trzeba też pamiętać, że deweloper pisze kod korzystając ze środowiska deweloperskiego. Zawierającego wycinek, najlepiej zanonimizowanych, danych produkcyjnych. Więcej na temat języka SQL w następnym materiale.

Oprócz samego dostępu do danych realizowanego poprzez użycie języka SQL motory baz danych umożliwiają zaszycie w bazie danych tzw. logiki biznesowej. Czyli fragmentów kodu, wykonującego bardziej skomplikowane operacje, napisanych w unikalnym dla danego motoru języku proceduralnym. Rozwiązanie historycznie bardzo cenione ze względu na wydajność i przenaszalność obecnie przeżywa spadek popularności. Niemniej warto aby programista baz danych wykazał się znajomością także tego języka proceduralnego.

Kod napisany przez programistę, a przeznaczony dla bazy danych, zazwyczaj wdrażany jest przez administratora baz danych. Nie musi tak jednak być. Wdrażać może ktokolwiek mający stosowne uprawnienia. Niemniej zazwyczaj administrator baz danych najlepiej zna środowisko i mechanikę motoru baz danych. Dzięki temu jest w stanie wprowadzić zmiany najbardziej efektywnie.

W mniejszych organizacjach role architektów i programisty mogą być pełnione przez jedną osobę. Wtedy rozłożenie ciężaru przetwarzania danych pomiędzy aplikację, a instancję bazy danych zależy od indywidualnych upodobań, doświadczenia i umiejętności tego człowieka. W większych organizacjach programista może nie być świadomy strategii przetwarzania danych. Może świetnie napisać potrzebny kod, ale powielić dane lub nie zadbać należycie o ich powiązania z istniejącymi. Część kompetencji ról administratora, architekta i programisty się pokrywa. Niemniej każda z ról wymaga unikalnej wiedzy i umiejętności. Ta unikalność nabiera tym większego znaczenia im większy jest projekt i organizacja. Skomentuj jakie jest Twoje zdanie na temat firm poszukujących omnibusów.

Tester

W świecie baz danych testerzy sa jak detektywi odkrywający ukryte błędy i słabości

Osobnym tematem jest weryfikacja jakości pracy architektów i programistów. Z jednej strony taka weryfikacja dokonywana jest przez administratora baz danych przed wdrożeniem. Z drugiej strony przez testera po wdrożeniu w środowisku testowym. Bo przecież Twoja firma testuje w środowisku testowym, prawda?

Jak wspomniałem wcześniej środowisko w którym programista tworzy kod zazwyczaj zawiera ułamek danych produkcyjnych. Na dodatek nie są to dane prawdziwe tylko zanonimizowane. W takim środowisku trudno napisać kod nie działający wydajnie. Zatem nie zawsze można dostrzec potrzebę optymalizacji. Dlatego kod po fazie dewelopmentu trafia do testerów. Ludzie pełniący tę rolę tworzą szczegółowy plan testów. Zależy on od potrzeby. Mogą to być testy funkcjonalności, bezpieczeństwa, wydajności czy integralności.

Testy często odbywają się w środowisku maksymalnie zbliżonym do produkcyjnego. Czyli wolumen danych jest podobny, ale niekoniecznie wydajność sprzętu.

Istotną częścią testów są tzw. testy regresyjne. Czyli weryfikacja czy część kodu nie podlegająca zmianom dalej działa jak się oczekuje.

Ostatnią fazą testów są testy UAT. Czyli User Acceptance Testing. W które zaangażowani są użytkownicy oraz interesariusze.

Użytkownik

Baza danych bez użytkowników jest jak biblioteka bez czytelników

Role, które uzasadniają istnienie systemów informatycznych można podzielić na 3 grupy. Są to tzw. użytkownicy końcowi. Pierwsza to użytkownicy wprowadzający i modyfikujący dane. Czasem nie muszą być ludźmi. Moga to być urządzenia, czujniki zbierające dane i zapisujące je w bazie danych. Niemniej ich zadanie polega na wprowadzaniu, czytaniu i modyfikowaniu niewielkich porcji danych. Korzystają oni z systemów nazywanych OLTP. Z angielska OnLine Transaction Processing. Dla takich użytkowników bardzo ważna jest responsywność systemu. W tym instancji bazy danych.

Analityk

Analiza danych jest interpretacją i przedstawianiem odkrytych w nich wzorców

Terrance D. Wilson

Drugą grupą użytkowników są analitycy danych. Używam tej nazwy dla wszystkich ludzi, których praca polega na agregowaniu danych w celu zamiany ich w informacje. Oczywiście im także zależy na jak najszybszym otrzymaniu odpowiedzi z bazy danych. Niemniej są świadomi, że obróbka olbrzymiej ilości danych musi potrwać. Korzystają z systemów nazywanych OLAP. Czyli OnLine Analytical Processing. Dane często pochodzą z różnych źródeł. Nie wszystkie muszą należeć do organizacji i nie wszystkie są bazami danych. Niemniej wyniki pracy analityków zapisywane są w jakiejś bazie danych.

Manager

Podejmowanie decyzji w oparciu o dane to przyszłość, a przyszłość już nadeszła

Mathangi Sri

Z tych wyników korzysta trzecia grupa użytkowników. Są to osoby podejmujące decyzje w oparciu o informacje uzyskane przez analityków. Osoby te zazwyczaj zajmują kierownicze stanowiska w firmie. Oni bardzo cenią swój czas.

Ujmując przepływ danych obrazowo. Użytkownikami wprowadzającymi dane mogą być na przykład sprzedawcy. Wprowadzają jedną fakturę na raz. Może być ich bardzo wielu. Z danych o fakturach analitycy danych wyciągają informacje. Na przykład jak wygląda sprzedaż w dni powszednie, a jak w wolne w roku bieżącym. Na podstawie tych informacji kierownictwo firmy może decydować o godzinach otwarcia sklepów w roku przyszłym. Czyli nie otwierać sklepów gdy nie ma sprzedaży.

Audytor

Audytorzy są jak wartownicy ochraniający dane przed niepowołanym dostępem

Dziewiątym VIPem w ekosystemie baz danych jest audytor. Potocznie zwany bezpiecznikiem. Zadaniem osoby pełniącej tę rolę jest przeglądanie logów audytowych z instancji bazy danych oraz raportowanie niedozwolonych zachowań. Nie wszystkie zachowania można uregulować mechanizmami bazodanowymi. Na przykład administrator baz danych posiada praktycznie nieograniczone uprawnienia w bazie danych. Nie wszystkie motory baz danych dostarczają odpowiednich mechanizmów ograniczających uprawnienia administracyjne. Na przykład do czytania danych. Firma może nie dozwalać aby DBA korzystał ze swoich uprawnień bez nadzoru. Oczywiście audyt można skonfigurować dla wszystkich użytkowników. Trzeba jednak pamiętać, że audyt tylko rejestruje zachowania, a nie chroni przed nimi. Dodatkowo logi audytu przechowywane są w systemie operacyjnym i bazie danych gdzie administrator może je zmodyfikować. Niemniej używanie audytu może być wymagane przed audytorów zewnętrznych i regulatorów.

Aby ograniczyć nieograniczone uprawnienia administratorów część firm przyznaje je jedynie na określony czas i z precyzyjnie określonych powodów. W takich firmach DBA nie może podłączyć się do instancji bazy danych z uprawnieniami administracyjnymi kiedy chce.

W przypadku odkrycia przez audytora niedozwolonego zachowania w bazie danych następuje uruchomienie procedury wyjaśniającej. Na przykład prośba o wyjaśnienia wysłana do zainteresowanego. Następnie eskalacja do przełożonego.

Co sądzisz o ograniczniu uprawnień administratora baz danych?

W przypadku wspomnianych wcześniej architektów i programistów oraz testerów jak również w przypadku administratorów i audytorów występuje konflikt interesów. Czyli programista może chcieć jak najszybciej wdrożyć swój kod. Jeśli jest także testerem może nie dołożyć należytej staranności do testów. W przypadku administratorów może zaistnieć chęć wprowadzenia modyfikacji, które mają coś poprawić aczkolwiek nie sa wymagane ani zaakceptowane przez właściciela danych. Jeśli administrator ma ciągły dostęp do wysokich uprawnień albo jest także audytorem może przymknąć na to oko. Aby uniknąć konfliktu interesów warto rozważyć rozdział ról pomiędzy różne osoby i działy.

Podsumowanie

W ekosystemie bazy danych funkcjonuje 9 ról:

• Administrator baz danych – zarządza instancją bazy danych, współpracuje z innymi specjalistami w celu zapewnienia wydajnego dostępu do danych oraz ich bezpieczeństwa
• Architekt danych – pracuje nad strategią zarządzania danymi w przedsiębiorstwie
• Architekt bazy danych – opracowuje strukturę bazy danych wg strategii opracowanej przez architekta danych
• Programista – programuje kod dla motoru bazy danych obsługujący strukturę bazy danych opracowaną przez architekta bazy danych
• Tester – przeprowadza testy kodu napisanego przez programistę
• Użytkownik operacyjny – manipuluje niewielkimi ilościami danych
• Analityk danych – przetwarza duże ilości danych w celu wydobycia z nich informacji
• Osoba zarządzająca – podejmuje decyzje na podstawie informacji przygotowanych przez analityka danych
• Audytor – weryfikuje czy działania podjęte w bazie danych sa zgodne z procedurami firmy